Filtru Fail2ban pentru OpenVPN Access Server: real_ip și jail

Access Server scrie propriul format de jurnal, așa că filtrele standard nu găsesc nimic. Ancorați pe real_ip, separați jail-urile pe suprafețe și verificați că adresa nu este un proxy.

Ați copiat un OpenVPN jail dintr-o postare a comunității, ați repornit fail2ban și nicio adresă nu este vreodată blocată. Cauza este aproape întotdeauna formatul jurnalului: Access Server nu scrie liniile de eșec al autentificării pe care le așteaptă un filtru standard. Înainte de a atinge filtrul, confirmați că înregistrările există, pentru că un model nu poate potrivi ce serviciul nu a jurnalizat niciodată.

Aceasta este procedura pe care o urmez pe un host Access Server: confirmați forma înregistrării, scrieți o expresie ancorată, testați-o pe jurnalul real, apoi separați jail-urile după suprafața atacată și verificați că blocarea ajunge la firewall.

Confirmați că înregistrarea de eșec există

Access Server scrie propriile linii structurate în /var/log/openvpnas.log, iar adresa clientului stă într-un câmp real_ip între ghilimele, nu la începutul unei linii syslog. Căutați o autentificare eșuată despre care știți că a avut loc înainte de a scrie vreun model:

grep -i 'LOG ERR' /var/log/openvpnas.log | tail -20

Dacă nu apare nimic, nivelul de jurnal este următorul suspect. Access Server are un comutator de depanare pentru baza de date de jurnal în /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), și serviciul trebuie repornit după ce îl modificați. Tratați acel comutator ca pe o setare de diagnostic ce se coboară din nou după ce aveți modelul, nu ca pe o configurație permanentă.

Cât timp sunteți în fișier, observați ce suprafețe scriu în el. Eșecurile portalului client, ale interfeței de administrare și ale autentificării tunelului ajung în același fișier cu markeri diferiți, iar acest detaliu decide mai târziu structura jail-urilor.

Ancorați un filtru pe real_ip

Păstrați expresia îngustă. Un filtru care revendică orice linie cu o adresă IP va bloca oameni pentru deconectări obișnuite, iar pe un server aglomerat singurul simptom este că utilizatorii se plâng că au fost blocați pentru că au închis un laptop. Revendicați înregistrarea de eroare și capturați adresa dintre ghilimele:

# /etc/fail2ban/filter.d/openvpnaccess.local
[Definition]
failregex = ^ .*LOG ERR.*"real_ip": "<HOST>".*
ignoreregex =

Spațiul de la început nu este cosmetic. Access Server își indentează înregistrările, iar ancorarea pe el împiedică modelul să revendice și linii pe care servicii nelegate le scriu în același fișier. Dacă înregistrările voastre au în schimb o marcă de timp la început, potriviți acel prefix, dar ancorați-vă pe ceva ce există cu adevărat în fiecare înregistrare pe care intenționați să o revendicați.

Când aveți nevoie de precizie pe suprafață, restrângeți mai mult cerând markerul suprafeței (WEB_CLIENT, WEB_ADMIN sau VPN) pe aceeași linie. Un filtru cu trei modele este mai ușor de auditat decât trei filtre care diferă printr-un cuvânt.

Testați expresia înainte de a activa un jail

Nu activați niciodată un filtru pe care nu l-ați rulat pe jurnalul de producție. Testul documentat trece filtrul de două ori, o dată pentru încărcare și o dată pentru aplicare, iar raportul liniilor ratate este partea care merită citită:

fail2ban-regex --print-all-missed /var/log/openvpnas.log \
  /etc/fail2ban/filter.d/openvpnaccess.local \
  /etc/fail2ban/filter.d/openvpnaccess.local > missed.txt

Comparați numărul de potriviri cu eșecurile pe care le-ați verificat la primul pas. Zero potriviri înseamnă că modelul este greșit; potrivirile pe linii care nu sunt eșecuri de autentificare înseamnă că este prea larg. Citiți missed.txt până când puteți explica fiecare linie pe care ați ales să nu o revendicați.

Faceți acest test pe o copie dacă jurnalul este mare și repetați-l după orice actualizare a Access Server. Formatul jurnalului este interfața față de care potriviți, și nu este un API stabil.

Separați jail-urile după suprafață, nu după demon

Un Access Server prezintă mai multe suprafețe de autentificare: interfețe web de client și de administrare pe 943/tcp, și tunelul pe 1194/udp sau 443/tcp în majoritatea implementărilor. Un singur jail care le acoperă pe toate permite încercărilor de ghicire pe tunel să blocheze o adresă care este și calea voastră de administrare, și ascunde care suprafață este de fapt atacată. Dați fiecărei suprafețe propriul jail cu propriul port și praguri:

# /etc/fail2ban/jail.d/openvpnaccess.local
[openvpnas-web-client]
enabled  = true
port     = 943
protocol = tcp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 3
findtime = 10m
bantime  = 1h
[openvpnas-tunnel]
enabled  = true
port     = 443
protocol = udp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 5
findtime = 10m
bantime  = 1h

Începeți cu contoare mici și o blocare scurtă, apoi ridicați-le după ce ați urmărit o săptămână de trafic real. Un prag generos pe o adresă de birou partajată pedepsește fiecare utilizator din spatele unui NAT, iar o blocare agresivă pe suprafața tunelului deconectează clienți legitimi ale căror credențiale stocate au expirat peste noapte.

Verificați blocarea, backendul și daunele colaterale

După o repornire, ieșirea de stare este cea mai rapidă confirmare că jail-ul există și numără:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Apoi confirmați că blocarea ajunge la firewall-ul pe care îl rulați efectiv, pentru că un jail configurat pentru un backend pe care nimeni nu îl aplică nu protejează nimic. Cu acțiunea iptables adresele apar într-un lanț numit după jail (f2b-openvpnas-tunnel); cu acțiunea nftables ajung într-un set din tabelul propriu al fail2ban. Verificați-l pe cel pe care îl folosește hostul vostru în loc să presupuneți.

Două verificări colaterale contează mai mult decât blocarea în sine. Întâi, verificați că real_ip este adresa clientului și nu un balanceator de încărcare sau un proxy invers; în spatele unui proxy fiecare blocare cade pe proxy și duce tot serviciul cu ea. În al doilea rând, scrieți procedura de deblocare, pentru că adresa care trece pragul la 02:00 aparține de obicei inginerului de gardă: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Țineți cont de limită în timp ce reglați. Fail2ban este un limitator de rată pe o singură suprafață de autentificare, nu un strat de control al accesului. Nu înlocuiește MFA, restricțiile pe cont sau ținerea interfeței de administrare în afara internetului public, iar Access Server are propriile setări autoban care merită verificate înainte de a stivui doi limitatori de rată pe același port.

Articole similare