Én banaction, to transportar: reparere en fail2ban-VPN-jail

Ingenting i fail2ban slipper et pakke av seg selv: det kaller på en handling, og det er handlingen som navngir protokoll og port. Når jailen rapporterer en ban mens daemonen fortsatt godtar pålogginger, er banen som regel ekte og smalere enn loggen antyder. En klient som kobler til på nytt over den andre transporten, møter aldri regelen som ble installert. Sammenlign det handlingen installerte med det daemonen lytter på før du endrer noe, fordi beviset ligger i brannmur-kjeden handlingen skrev, ikke i jailens liste.

Les kjeden, ikke jailens sammendrag

fail2ban setter inn sin egen kjede foran tjenestekjeden, så en tellerliste viser nøyaktig hva som finnes. En kjede oppkalt etter jailen, som holder én regel der protokollkolonnen leser udp, er en fullstendig forklaring på TCP-pålogginger som fortsatt kommer inn. Bare UDP-pakker fra den blokkerte kilden avvises. Tjenesten har en TCP-lytter, og ingenting i den kjeden berører den.

Se også etter nabo-jail-effekten. En vert kan se perfekt konfigurert ut bare fordi en annen jail leverer den halvdelen som mangler, og samme bygg gjør ingenting der den jailen ikke er installert.

Handlingen navngir én protokoll, og det er der det knekker

Hver banaction er en mal for en brannmurkommando, og protokollen sitter i en av plassholderne. Det trange omfanget er med vilje, siden en web-jail og en DNS-jail ikke har noe med å blokkere identiske porter å gjøre. Det blir en felle når tjenesten lytter på mer enn én transport, noe VPN-daemoner rutinemessig gjør. Filteret kan overvåke mislykkede pålogginger fra begge transporter mens handlingen dekker én.

SoftEther- og OpenVPN-utrullinger lytter vanligvis på UDP og TCP samtidig, og fordi logglinjen ser lik ut i begge tilfeller, overvåker filteret begge. Asymmetrien vises aldri i jailens egen rapport. fail2ban telte feilene riktig og installerte deretter en regel som gjelder for halvparten av trafikken feilene kom inn på.

La banen dekke begge transportene

Rett det i jaildefinisjonen i stedet; håndskrevne regler blir stokket om ved neste omlasting. Skriv ut to handlinger, én for hver protokoll:

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

Ikke prøv å forkorte det med protocol = all. Standard-banaction er en multiport-handling, og den utvides til -p <protocol> -m multiport --dports <port>; uten L4-protokoll er det ingenting for porttreffet å teste, så iptables avviser regelen mens jailen fortsatt rapporterer en vellykket ban. En handling for alle porter som iptables-allports eller nftables-allports godtar én oppføring, men blokkerer hver port på den kilden, noe som er en annen beslutning og trenger sin egen begrunnelse. La protocol stå på tcp eller udp og godta de to oppføringene.

Bevis at regelen finnes i stedet for å stole på innstillingen, fordi en innstilling beskriver en intensjon til en kjede holder den:

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

Hver kjede bør liste én regel, med -p tcp i den første og -p udp i den andre, og begge navngir den blokkerte adressen. Bekreft deretter at samme adresse avvises på begge transportene. En ban du ikke har sett i kjeden, er et håp, og neste rapport om samme symptom vil koste den samme timen igjen.

Hva en ban fortsatt går glipp av, og neste tilfelle

Det handlingen gjør, er å avvise én kilde, og bare på portene som er listet i den. Den gjør ingenting mot en angriper som roterer adresser, og den kan ikke skille en fiendtlig maskin fra en carrier-grade NAT-utgang som deles av hundrevis av brukere, der én ban stenger ute folk som ikke har gjort noe. Sørg for at filteret leser adressen klienten faktisk har, ikke en videresendt header eller en proxyadresse. Hold vinduet kort nok til at en feil utløper av seg selv.

Ingenting av dette taler for å hoppe over protokollrettelsen; det taler for å holde to ideer samtidig. Banen er smalere enn jailens sammendrag antyder, og selv en fullstendig ban er smalere enn trusselen. Sett brannmur-kjeden ved siden av daemonens lytterliste og sammenlign protokoll for protokoll, fordi de to listene avgjør om en ban i det hele tatt kan nå tjenesten.

Hold omlastingskommandoen og kjeldelisten i runbooken ved siden av jailen. Den neste personen trenger begge, og jailens sammendrag vil ikke fortelle dem noen av dem.