Én banaction, to transports: reparation af en fail2ban-VPN-jail

Intet i fail2ban dropper en pakke af sig selv: det kalder en handling, og netop den handling navngiver en protokol og en port. Når jailen rapporterer en ban, mens daemonen fortsat accepterer logins, er banen som regel reel og smallere, end loggen antyder. En klient, der genopretter forbindelsen over den anden transport, møder aldrig den regel, der blev installeret. Sammenlign det, handlingen installerede, med det, daemonen lytter på, før du ændrer noget, fordi beviset ligger i den firewallkæde, handlingen skrev, ikke i jailens liste.

Læs kæden, ikke jailens resumé

fail2ban indsætter sin egen kæde foran tjenestens kæde, så en tællerliste viser præcis, hvad der findes. En kæde opkaldt efter jailen, der indeholder én regel, hvis protokolkolonne viser udp, er en fuldstændig forklaring på TCP-logins, der fortsat ankommer. Kun UDP-pakker fra den bannede kilde afvises. Tjenesten har en TCP-lytter, og intet i den kæde rører ved den.

Hold også øje med nabo-jail-effekten. En vært kan se perfekt konfigureret ud, blot fordi en anden jail leverer den halvdel, der mangler, og det samme build gør intet der, hvor den jail ikke er installeret.

Handlingen navngiver én protokol, og det er der, det knækker

Hver banaction er en skabelon til en firewallkommando, og protokollen sidder i en af dens pladsholdere. Snæverheden er bevidst, for en web-jail og en DNS-jail har intet at gøre med at blokere identiske porte. Det bliver en fælde, når tjenesten lytter på mere end én transport, hvilket VPN-daemoner rutinemæssigt gør. Filteret kan overvåge mislykkede logins fra begge transporter, mens handlingen dækker én.

SoftEther- og OpenVPN-udrulninger lytter normalt på UDP og TCP samtidig, og fordi loglinjen ser ens ud i begge tilfælde, overvåger filteret begge. Asymmetrien vises aldrig i jailens egen rapport. fail2ban talte fejlene korrekt og installerede derefter en regel, der gælder for den halvdel af trafikken, som fejlene ankom på.

Lad banen dække begge transporter

Ret det i jaildefinitionen i stedet; håndskrevne regler bliver blandet rundt ved næste reload. Skriv to handlinger eksplicit, én for hver 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"]

Forsøg ikke at forkorte det med protocol = all. Standard-banaction er en multiport-handling, og den udvides til -p <protocol> -m multiport --dports <port>; uden en L4-protokol er der intet for portmatchningen at teste, så iptables afviser reglen, mens jailen stadig rapporterer en vellykket ban. En all-ports-handling som iptables-allports eller nftables-allports accepterer ganske vist én post, men den banner hver port på den kilde, hvilket er en anden beslutning og kræver sin egen begrundelse. Lad protocol stå på tcp eller udp og accepter de to poster.

Bevis, at reglen findes, i stedet for at stole på indstillingen, fordi en indstilling beskriver en hensigt, indtil en kæde holder den:

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

Hver kæde bør liste én regel, med -p tcp i den første og -p udp i den anden, og begge navngiver den bannede adresse. Bekræft derefter, at samme adresse afvises på begge transporter. En ban, du ikke har set i kæden, er et håb, og den næste rapport om samme symptom vil koste den samme time igen.

Hvad en ban stadig misser, og det næste tilfælde

Det, handlingen gør, er at afvise én kilde, og kun på de porte, der er nævnt i den. Den gør intet ved en angriber, der roterer adresser, og den kan ikke skelne en fjendtlig maskine fra en carrier-grade NAT-udgang, der deles af hundreder af brugere, hvor én ban udelukker folk, der ikke har gjort noget. Sørg for, at filteret læser den adresse, klienten faktisk har, ikke en videresendt header eller en proxyadresse. Hold vinduet kort nok til, at en fejl udløber af sig selv.

Intet af det taler for at springe protokolrettelsen over; det taler for at holde to idéer på én gang. Banen er smallere, end jailens resumé antyder, og selv en fuldstændig ban er smallere end truslen. Stil firewallkæden ved siden af daemonens lytterliste og sammenlign protokol for protokol, fordi de to lister afgør, om en ban overhovedet kan nå tjenesten.

Gem reload-kommandoen og kædelisten i runbooken ved siden af jailen. Den næste person skal bruge begge, og jailens resumé vil ikke fortælle noget om nogen af dem.