Eén banaction, twee transporten: een fail2ban-VPN-jail repareren

Niets in fail2ban laat zelfstandig een pakket vallen: het roept een actie aan, en die actie benoemt een protocol en een poort. Wanneer de jail een ban meldt terwijl de daemon aanmeldingen blijft accepteren, is de ban meestal echt en smaller dan de log doet vermoeden. Een client die via het andere transport opnieuw verbindt, komt nooit de regel tegen die is geïnstalleerd. Vergelijk wat de actie heeft geïnstalleerd met waarop de daemon luistert voordat u iets wijzigt, want het bewijs zit in de firewall-keten die de actie schreef, niet in de lijst van de jail.

Lees de keten, niet de samenvatting van de jail

fail2ban voegt zijn eigen keten vóór de dienstketen in, dus een tellerlijst toont precies wat er bestaat. Een keten die naar de jail is vernoemd en één regel bevat waarvan de protocolkolom udp leest, is een volledige verklaring voor TCP-aanmeldingen die blijven binnenkomen. Alleen UDP-pakketten van de gebande bron worden geweigerd. De dienst heeft een TCP-listener, en niets in die keten raakt hem aan.

Let ook op het effect van de naburige jail. Eén host kan perfect geconfigureerd lijken, alleen omdat een andere jail de ontbrekende helft levert, en dezelfde build doet niets waar die jail niet is geïnstalleerd.

De actie benoemt één protocol, en daar breekt het

Elke banaction is een sjabloon voor een firewallcommando, en het protocol zit in een van de plaatsaanduidingen. De smalheid is opzettelijk, want een web-jail en een DNS-jail hebben niets te maken met het blokkeren van identieke poorten. Het wordt een val wanneer de dienst op meer dan één transport luistert, wat VPN-daemons geregeld doen. Het filter kan mislukte aanmeldingen van beide transporten volgen terwijl de actie er één dekt.

SoftEther- en OpenVPN-implementaties luisteren meestal tegelijk op UDP en TCP, en omdat de logregel er in beide gevallen hetzelfde uitziet, volgt het filter beide. De asymmetrie komt nooit in het rapport van de jail zelf voor. fail2ban telde de fouten correct en installeerde daarna een regel die geldt voor de helft van het verkeer waarop die fouten binnenkwamen.

Laat de ban beide transporten dekken

Los het in plaats daarvan op in de definitie van de jail; handgeschreven regels worden bij de volgende herlaadbeurt door elkaar geschud. Schrijf twee acties uit, één per 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"]

Probeer dat niet in te korten met protocol = all. De standaard-banaction is een multiport-actie, en die breidt uit naar -p <protocol> -m multiport --dports <port>; zonder L4-protocol is er niets voor de poortmatch om te testen, dus iptables weigert de regel terwijl de jail nog steeds een geslaagde ban meldt. Een actie voor alle poorten zoals iptables-allports of nftables-allports accepteert één vermelding, maar blokkeert elke poort op die bron, wat een andere beslissing is en een eigen rechtvaardiging vraagt. Laat protocol op tcp of udp staan en accepteer de twee vermeldingen.

Bewijs dat de regel bestaat in plaats van de instelling te vertrouwen, want een instelling beschrijft een bedoeling tot een keten die vasthoudt:

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

Elke keten hoort één regel te tonen, met -p tcp in de eerste en -p udp in de tweede, en beide noemen het gebande adres. Bevestig daarna dat hetzelfde adres op beide transporten wordt geweigerd. Een ban die u niet in de keten hebt gezien, is hoop, en de volgende melding van hetzelfde symptoom kost weer hetzelfde uur.

Wat een ban nog mist, en het volgende geval

Wat de actie doet, is één bron weigeren, en alleen op de poorten die erin staan. Ze doet niets tegen een aanvaller die adressen roteert, en ze kan een vijandige machine niet scheiden van een carrier-grade NAT-uitgang die door honderden gebruikers wordt gedeeld, waar één ban mensen buitensluit die niets hebben gedaan. Zorg dat het filter het adres leest dat de client werkelijk heeft, niet een doorgestuurde header of een proxyadres. Houd het venster kort genoeg dat een fout vanzelf vervalt.

Niets daarvan pleit ervoor de protocolfix over te slaan; het pleit ervoor twee ideeën tegelijk vast te houden. De ban is smaller dan de samenvatting van de jail suggereert, en zelfs een volledige ban is smaller dan de dreiging. Zet de firewall-keten naast de listenerlijst van de daemon en vergelijk protocol voor protocol, want die twee lijsten bepalen of een ban de dienst überhaupt kan bereiken.

Houd het herlaadcommando en de ketenlijst in de runbook naast de jail. De volgende persoon heeft beide nodig, en de samenvatting van de jail vertelt hem geen van beide.