Jeden banaction, dva transporty: oprava fail2ban VPN jailu
Ban je len tak široký, aký je protokol v jeho akcii. Porovnajte počítadlá reťazca s počúvačmi a potom pokryte oba transporty v samotnom jaili.
Nič vo fail2ban samo neodhodí paket: zavolá akciu a práve tá akcia pomenúva protokol a port. Keď jail hlási ban, kým démon ďalej prijíma prihlásenia, ban je zvyčajne skutočný a užší, než naznačuje log. Klient, ktorý sa znova pripojí cez druhý transport, nikdy nenarazí na nainštalované pravidlo. Predtým než čokoľvek zmeníte, porovnajte, čo akcia nainštalovala, s tým, na čom démon počúva, pretože dôkaz je vo firewallovom reťazci, ktorý akcia zapísala, nie v zozname jailu.
Čítajte reťazec, nie zhrnutie jailu
fail2ban vkladá svoj reťazec pred reťazec služby, takže výpis počítadiel ukazuje presne to, čo existuje. Reťazec pomenovaný po jaily, ktorý drží jediné pravidlo so stĺpcom protokolu udp, je úplným vysvetlením pre prihlásenia TCP, ktoré stále prichádzajú. Odmietajú sa iba pakety UDP zo zakázaného zdroja. Služba má počúvač TCP a nič v tom reťazci sa ho nedotýka.
Všímajte si aj efekt susedného jailu. Jeden hostiteľ môže vyzerať dokonale nakonfigurovaný len preto, že chýbajúcu polovicu dodáva iný jail, a ten istý build nerobí nič tam, kde ten jail nie je nainštalovaný.
Akcia pomenúva jeden protokol a práve tam sa to láme
Každý banaction je šablóna firewallového príkazu a protokol sedí v jednom z jeho zástupných znakov. Úzkosť je zámerná, keďže webový jail a DNS jail nemajú čo robiť s blokovaním rovnakých portov. Stane sa pascou, keď služba počúva na viac ako jednom transporte, čo démoni VPN bežne robia. Filter môže sledovať neúspešné prihlásenia z oboch transportov, kým akcia pokrýva jeden.
Nasadenia SoftEther a OpenVPN zvyčajne počúvajú na UDP aj TCP naraz, a keďže riadok logu vyzerá v oboch prípadoch rovnako, filter sleduje oba. Asymetria sa nikdy neprejaví v správe samotného jailu. fail2ban spočítal zlyhania správne a potom nainštaloval pravidlo, ktoré platí pre polovicu prevádzky, na ktorej tie zlyhania prišli.
Nech ban pokryje oba transporty
Opravte to v definícii jailu; ručne písané pravidlá ďalší reload premieša. Vypíšte dve akcie, jednu pre každý 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"]
Neskracujte to pomocou protocol = all. Predvolený banaction je multiport akcia a rozvíja sa na -p <protocol> -m multiport --dports <port>; bez protokolu L4 nie je čo porovnanie portu testovať, takže iptables pravidlo odmietne, kým jail stále hlási úspešný ban. Akcia pre všetky porty, ako je iptables-allports alebo nftables-allports, prijme jednu položku, ale zablokuje každý port na tomto zdroji, čo je iné rozhodnutie a vyžaduje vlastné odôvodnenie. Nechajte protocol na tcp alebo udp a prijmite dve položky.
Dokážte, že pravidlo existuje, namiesto toho, aby ste verili nastaveniu, pretože nastavenie opisuje zámer, kým ho reťazec nedrží:
iptables -S f2b-vpn-tcp
iptables -S f2b-vpn-udp
Každý reťazec by mal uviesť jedno pravidlo, s -p tcp v prvom a -p udp v druhom, obe menujú zakázanú adresu. Potom potvrďte, že tá istá adresa je odmietnutá na oboch transportoch. Ban, ktorý ste v reťazci nevideli, je nádej a ďalšie hlásenie toho istého symptómu bude opäť stáť rovnakú hodinu.
Čo ban stále prepúšťa, a ďalší prípad
Akcia odmieta jediný zdroj, a to len na portoch v nej uvedených. Nerobí nič proti útočníkovi, ktorý rotuje adresy, a nedokáže oddeliť nepriateľský stroj od výstupu carrier-grade NAT zdieľaného stovkami používateľov, kde jeden ban vyradí ľudí, ktorí nič neurobili. Uistite sa, že filter číta adresu, ktorú klient skutočne má, nie preposlanú hlavičku alebo adresu proxy. Držte okno dosť krátke, aby chyba sama vypršala.
Nič z toho neargumentuje za vynechanie opravy protokolu; argumentuje za držanie dvoch myšlienok naraz. Ban je užší, než naznačuje zhrnutie jailu, a aj úplný ban je užší než hrozba. Položte firewallový reťazec vedľa zoznamu počúvačov démona a porovnávajte protokol po protokole, pretože tieto dva zoznamy rozhodujú, či sa ban vôbec môže dostať k službe.
Uchovajte príkaz na reload a výpis reťazcov v runbooku vedľa jailu. Ďalší človek bude potrebovať oboje a zhrnutie jailu mu nepovie ani jedno.