Een banaksie, twee transporte: 'n fail2ban-VPN-jail herstel

Niks in fail2ban laat op sigself 'n pakket val nie: dit voer 'n aksie uit, en daardie aksie is wat 'n protokol en 'n poort benoem. Wanneer die jail 'n ban rapporteer terwyl die daemon aanhou om aanmeldings te aanvaar, is die ban gewoonlik eg en smaller as wat die log aandui. 'n Kliënt wat oor die ander transport herverbind, kom nooit by die reël wat geïnstalleer is nie. Vergelyk wat die aksie geïnstalleer het met waarop die daemon luister voordat jy enigiets verander, want die bewyse lê in die firewall-ketting wat die aksie geskryf het, nie in die jail-lys nie.

Lees die ketting, nie die jail-opsomming nie

fail2ban voeg sy eie ketting voor die diensketting in, so 'n tellerlys wys presies wat bestaan. 'n Ketting wat na die jail vernoem is en een reël hou waarvan die protokolkolom udp lees, is 'n volledige verduideliking vir TCP-aanmeldings wat aanhou arriveer. Slegs UDP-pakkette van die verbande bron word verwerp. Die diens het 'n TCP-luisteraar, en niks in daardie ketting raak dit nie.

Let ook op die naburige-jail-effek. Een gasheer kan heeltemal gekonfigureer lyk bloot omdat 'n ander jail die helfte lewer wat ontbreek, en dieselfde bou doen niks waar daardie jail nie geïnstalleer is nie.

Die aksie benoem een protokol, en dit is waar dit breek

Elke banaction is 'n firewall-opdragsjabloon, en die protokol sit in een van sy plekhouers. Die engheid is opsetlik, want 'n web-jail en 'n DNS-jail het niks te doen met die blokkering van identiese poorte nie. Dit word 'n val wanneer die diens op meer as een transport luister, wat VPN-daemons gereeld doen. Die filter kan mislukte aanmeldings van albei transporte dophou terwyl die aksie een dek.

SoftEther- en OpenVPN-ontplooiings luister gewoonlik gelyktydig op UDP en TCP, en omdat die logreël in beide gevalle dieselfde lyk, hou die filter albei dop. Die asimmetrie wys nooit in die jail se eie verslag nie. fail2ban het die mislukkings korrek getel en toe 'n reël geïnstalleer wat op die helfte van die verkeer van toepassing is waarop daardie mislukkings aangekom het.

Laat die ban albei transporte dek

Maak dit eerder in die jail-definisie reg; handgeskrewe reëls sal deur die volgende herlaai geskommel word. Spel twee aksies uit, een vir elke protokol:

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"]

Moenie probeer om dit met protocol = all te verkort nie. Die verstek-banaction is 'n multiport-aksie, en dit brei uit na -p <protocol> -m multiport --dports <port>; sonder 'n L4-protokol is daar niks vir die poortpassing om te toets nie, so iptables verwerp die reël terwyl die jail steeds 'n suksesvolle ban rapporteer. 'n All-ports-aksie soos iptables-allports of nftables-allports aanvaar wel 'n enkele inskrywing, maar dit verban elke poort op daardie bron, wat 'n ander besluit is en sy eie regverdiging nodig het. Los protocol op tcp of udp en aanvaar die twee inskrywings.

Bewys dat die reël bestaan eerder as om die instelling te vertrou, want 'n instelling beskryf 'n bedoeling totdat 'n ketting dit hou:

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

Elke ketting moet een reël lys, met -p tcp in die eerste en -p udp in die tweede, albei met die verbande adres. Bevestig dan dat dieselfde adres op albei transporte geweier word. 'n Ban wat jy nie in die ketting gesien het nie, is 'n hoop, en die volgende rapport van dieselfde simptoom sal weer dieselfde uur kos.

Wat 'n ban steeds mis, en die volgende geval

Wat die aksie doen, is om 'n enkele bron te verwerp, en net op die poorte wat daarin gelys word. Dit doen niks aan 'n aanvaller wat adresse roteer nie, en dit kan nie 'n vyandige masjien skei van 'n carrier-grade NAT-uitgang wat deur honderde gebruikers gedeel word nie, waar een ban mense uitsluit wat niks gedoen het nie. Maak seker die filter lees die adres wat die kliënt werklik het, nie 'n deurgegee kop of 'n proxy-adres nie. Hou die venster kort genoeg dat 'n fout vanself verval.

Niks daarvan pleit om die protokoloplossing oor te slaan nie; dit pleit om twee idees tegelyk te hou. Die ban is smaller as wat die jail-opsomming suggereer, en selfs 'n volledige ban is smaller as die bedreiging. Sit die firewall-ketting langs die daemon se luisteraarlys en vergelyk protokol vir protokol, want daardie twee lyste besluit of 'n ban die diens hoegenaamd kan bereik.

Hou die herlaai-opdrag en die kettinglys in die runbook langs die jail. Die volgende persoon sal albei nodig hê, en die jail-opsomming sal hom nie een daarvan vertel nie.