Jedna banaction, dva transporty: oprava fail2ban VPN jailu

Nic ve fail2ban samo o sobě nezahazuje paket: spouští akci a právě tato akce určuje protokol a port. Když jail hlásí ban, zatímco démon dál přijímá přihlášení, je ban obvykle skutečný a užší, než naznačuje log. Klient, který se znovu připojí přes druhý transport, na instalované pravidlo nikdy nenarazí. Než cokoli změníte, porovnejte, co akce nainstalovala, s tím, na čem démon naslouchá, protože důkaz je ve firewallovém řetězci, který akce zapsala, ne v seznamu jailu.

Čtěte řetězec, ne shrnutí jailu

fail2ban vkládá svůj řetězec před řetězec služby, takže výpis čítačů ukazuje přesně to, co existuje. Řetězec pojmenovaný po jailu, který drží jediné pravidlo se sloupcem protokolu udp, je úplným vysvětlením pro přihlášení TCP, která stále přicházejí. Odmítány jsou jen pakety UDP ze zakázaného zdroje. Služba má naslouchač TCP a nic v tom řetězci se ho nedotýká.

Sledujte i efekt sousedního jailu. Jeden hostitel může vypadat dokonale nakonfigurovaný jen proto, že chybějící polovinu dodává jiný jail, a stejný build nedělá nic tam, kde tento jail není nainstalován.

Akce pojmenovává jeden protokol a právě tam se to láme

Každá banaction je šablona firewallového příkazu a protokol sedí v jednom z jejích zástupných symbolů. Úzkost je záměrná, protože webový jail a DNS jail nemají co do činění s blokováním stejných portů. Pastí se to stane, když služba naslouchá na více než jednom transportu, což démoni VPN běžně dělají. Filtr může sledovat neúspěšná přihlášení z obou transportů, zatímco akce pokrývá jeden.

Nasazení SoftEther a OpenVPN obvykle naslouchají na UDP i TCP zároveň, a protože řádek logu vypadá v obou případech stejně, filtr sleduje oba. Asymetrie se ve zprávě samotného jailu nikdy neprojeví. fail2ban selhání správně spočítal a pak nainstaloval pravidlo, které platí pro polovinu provozu, na kterém tato selhání přišla.

Zařiďte, aby ban pokryl oba transporty

Opravte to v definici jailu; ručně psaná pravidla další reload promíchá. Vypište dvě akce, jednu pro 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"]

Nezkracujte to pomocí protocol = all. Výchozí banaction je multiport akce a rozvine se na -p <protocol> -m multiport --dports <port>; bez protokolu L4 není co porovnání portu testovat, takže iptables pravidlo odmítne, zatímco jail stále hlásí úspěšný ban. Akce pro všechny porty, jako je iptables-allports nebo nftables-allports, jednu položku přijme, ale zablokuje každý port na tomto zdroji, což je jiné rozhodnutí a vyžaduje vlastní odůvodnění. Nechte protocol na tcp nebo udp a přijměte dvě položky.

Dokažte, že pravidlo existuje, místo abyste věřili nastavení, protože nastavení popisuje záměr, dokud ho řetězec nedrží:

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

Každý řetězec by měl uvádět jedno pravidlo, s -p tcp v prvním a -p udp ve druhém, oba se zakázanou adresou. Poté potvrďte, že stejná adresa je odmítnuta na obou transportech. Ban, který jste v řetězci neviděli, je naděje a další hlášení stejného symptomu bude znovu stát stejnou hodinu.

Co ban stále mine a další případ

Akce odmítá jediný zdroj, a to jen na portech v ní uvedených. Nedělá nic proti útočníkovi, který rotuje adresy, a nedokáže oddělit nepřátelský stroj od výstupu carrier-grade NAT sdíleného stovkami uživatelů, kde jeden ban vyřadí lidi, kteří nic neudělali. Ujistěte se, že filtr čte adresu, kterou klient skutečně má, ne přeposlanou hlavičku nebo adresu proxy. Držte okno dost krátké, aby chyba sama vypršela.

Nic z toho neargumentuje pro vynechání opravy protokolu; argumentuje pro držení dvou myšlenek najednou. Ban je užší, než naznačuje shrnutí jailu, a i úplný ban je užší než hrozba. Položte firewallový řetězec vedle seznamu naslouchačů démona a porovnávejte protokol po protokolu, protože tyto dva seznamy rozhodují, zda se ban vůbec může dostat ke službě.

Uchovejte příkaz pro reload a výpis řetězců v runbooku vedle jailu. Další člověk bude potřebovat obojí a shrnutí jailu mu neřekne ani jedno.