O banaction, două transporturi: repararea unui jail fail2ban pentru VPN

Nimic din fail2ban nu aruncă un pachet de unul singur: apelează o acțiune, iar acea acțiune este cea care numește un protocol și un port. Când jail-ul raportează un ban în timp ce demonul continuă să accepte autentificări, banul este de obicei real și mai îngust decât sugerează jurnalul. Un client care se reconectează prin celălalt transport nu întâlnește niciodată regula instalată. Comparați ce a instalat acțiunea cu ceea ce ascultă demonul înainte de a schimba ceva, pentru că dovada se află în lanțul de firewall pe care l-a scris acțiunea, nu în lista jail-ului.

Citiți lanțul, nu rezumatul jail-ului

fail2ban inserează propriul lanț în fața lanțului serviciului, așa că o listă de contoare arată exact ce există. Un lanț numit după jail, care ține o singură regulă a cărei coloană de protocol citește udp, este o explicație completă pentru autentificările TCP care continuă să sosească. Sunt respinse doar pachetele UDP de la sursa blocată. Serviciul are un ascultător TCP, și nimic din acel lanț nu îl atinge.

Atenție și la efectul jail-ului vecin. O gazdă poate părea configurată perfect doar pentru că alt jail furnizează jumătatea care lipsește, iar aceeași compilare nu face nimic acolo unde acel jail nu este instalat.

Acțiunea numește un singur protocol, și exact acolo se rupe

Fiecare banaction este un șablon de comandă de firewall, iar protocolul stă într-unul dintre substituenții săi. Îngustimea este intenționată, pentru că un jail web și un jail DNS nu au nicio treabă cu blocarea unor porturi identice. Devine o capcană atunci când serviciul ascultă pe mai mult de un transport, ceea ce demonii VPN fac în mod obișnuit. Filtrul poate urmări autentificările eșuate din ambele transporturi în timp ce acțiunea acoperă unul.

Implementările SoftEther și OpenVPN ascultă de obicei pe UDP și TCP simultan, iar pentru că linia din jurnal arată la fel în ambele cazuri, filtrul le urmărește pe amândouă. Asimetria nu apare niciodată în raportul jail-ului însuși. fail2ban a numărat corect eșecurile și apoi a instalat o regulă care se aplică jumătății din traficul pe care au sosit acele eșecuri.

Faceți ca banul să acopere ambele transporturi

Corectați în definiția jail-ului; regulile scrise de mână vor fi amestecate la următoarea reîncărcare. Scrieți două acțiuni, una pentru fiecare protocol:

action = %(banaction)s[name=%(__name__)s-tcp, actionname=%(__name__)s-tcp, protocol="tcp", port="%(port)s", chain="%(chain)s"]
         %(banaction)s[name=%(__name__)s-udp, actionname=%(__name__)s-udp, protocol="udp", port="%(port)s", chain="%(chain)s"]

Nu încercați să scurtați asta cu protocol = all. banaction-ul implicit este o acțiune multiport, iar ea se extinde în -p <protocol> -m multiport --dports <port>; fără protocol L4 nu există nimic pentru potrivirea portului să testeze, așa că iptables respinge regula în timp ce jail-ul raportează în continuare un ban reușit. O acțiune pentru toate porturile, cum ar fi iptables-allports sau nftables-allports, acceptă o singură intrare, dar blochează fiecare port de pe acea sursă, ceea ce este o altă decizie și necesită propria justificare. Lăsați protocol pe tcp sau udp și acceptați cele două intrări.

Dovediți că regula există în loc să aveți încredere în setare, pentru că o setare descrie o intenție până când un lanț o susține:

iptables -S f2b-vpn-tcp
iptables -S f2b-vpn-udp

Fiecare lanț ar trebui să listeze o regulă, cu -p tcp în primul și -p udp în al doilea, ambele numind adresa blocată. Apoi confirmați că aceeași adresă este refuzată pe ambele transporturi. Un ban pe care nu l-ați văzut în lanț este o speranță, iar următorul raport despre același simptom va costa din nou aceeași oră.

Ce încă ratează un ban, și următorul caz

Ceea ce face acțiunea este să respingă o singură sursă, și doar pe porturile enumerate în ea. Nu face nimic împotriva unui atacator care rotește adrese, și nu poate separa o mașină ostilă de o ieșire NAT la nivel de operator partajată de sute de utilizatori, unde un singur ban blochează oameni care nu au făcut nimic. Asigurați-vă că filtrul citește adresa pe care clientul o are cu adevărat, nu un antet redirecționat sau o adresă de proxy. Țineți fereastra suficient de scurtă încât o greșeală să expire singură.

Nimic din toate acestea nu pledează pentru sărirea corectării protocolului; pledează pentru a ține două idei simultan. Banul este mai îngust decât sugerează rezumatul jail-ului, și chiar un ban complet este mai îngust decât amenințarea. Puneți lanțul de firewall lângă lista de ascultători a demonului și comparați protocol cu protocol, pentru că aceste două liste decid dacă un ban poate ajunge la serviciu.

Păstrați comanda de reîncărcare și lista lanțurilor în runbook lângă jail. Următoarea persoană va avea nevoie de amândouă, iar rezumatul jail-ului nu îi va spune niciunul.