Jeden banaction, dwa transporty: naprawa jaila fail2ban dla VPN

Nic w fail2ban nie odrzuca pakietu samo z siebie: wywołuje akcję, a to właśnie ta akcja nazywa protokół i port. Gdy jail zgłasza ban, a demon nadal przyjmuje logowania, ban zwykle jest prawdziwy i węższy, niż sugeruje log. Klient, który łączy się ponownie przez drugi transport, nigdy nie napotyka zainstalowanej reguły. Zanim cokolwiek zmienisz, porównaj to, co zainstalowała akcja, z tym, czego słucha demon, bo dowód tkwi w łańcuchu firewalla zapisanym przez akcję, a nie na liście jaila.

Czytaj łańcuch, nie podsumowanie jaila

fail2ban wstawia swój łańcuch przed łańcuchem usługi, więc lista liczników pokazuje dokładnie to, co istnieje. Łańcuch nazwany po jailu, zawierający jedną regułę, której kolumna protokołu mówi udp, jest pełnym wyjaśnieniem logowań TCP, które wciąż przychodzą. Odrzucane są tylko pakiety UDP ze zablokowanego źródła. Usługa ma nasłuch TCP i nic w tym łańcuchu go nie dotyka.

Uważaj też na efekt sąsiedniego jaila. Jeden host może wyglądać na idealnie skonfigurowany tylko dlatego, że inny jail dostarcza brakującą połowę, a ten sam build nie robi nic tam, gdzie tamten jail nie jest zainstalowany.

Akcja nazywa jeden protokół i właśnie tam się to łamie

Każdy banaction to szablon polecenia firewalla, a protokół siedzi w jednym z jego symboli zastępczych. Wąskość jest zamierzona, bo jail WWW i jail DNS nie mają nic wspólnego z blokowaniem identycznych portów. Staje się pułapką, gdy usługa nasłuchuje na więcej niż jednym transporcie, co demony VPN robią rutynowo. Filtr może obserwować nieudane logowania z obu transportów, podczas gdy akcja pokrywa jeden.

Wdrożenia SoftEther i OpenVPN zwykle nasłuchują jednocześnie na UDP i TCP, a ponieważ linia logu wygląda w obu przypadkach tak samo, filtr obserwuje oba. Asymetria nigdy nie pojawia się w raporcie samego jaila. fail2ban policzył błędy poprawnie, a następnie zainstalował regułę, która dotyczy połowy ruchu, na którym te błędy przyszły.

Niech ban obejmie oba transporty

Popraw to w definicji jaila; reguły pisane ręcznie zostaną przemieszane przy następnym przeładowaniu. Wypisz dwie akcje, po jednej dla każdego protokołu:

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

Nie próbuj skracać tego przez protocol = all. Domyślny banaction to akcja multiport, która rozwija się do -p <protocol> -m multiport --dports <port>; bez protokołu L4 dopasowanie portu nie ma czego testować, więc iptables odrzuca regułę, podczas gdy jail nadal zgłasza udany ban. Akcja dla wszystkich portów, taka jak iptables-allports lub nftables-allports, przyjmuje jeden wpis, ale blokuje każdy port na tym źródle, co jest inną decyzją i wymaga własnego uzasadnienia. Zostaw protocol na tcp lub udp i przyjmij dwa wpisy.

Udowodnij, że reguła istnieje, zamiast ufać ustawieniu, bo ustawienie opisuje intencję, dopóki łańcuch jej nie utrzyma:

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

Każdy łańcuch powinien wymieniać jedną regułę, z -p tcp w pierwszym i -p udp w drugim, a oba nazywają zablokowany adres. Następnie potwierdź, że ten sam adres jest odrzucany na obu transportach. Ban, którego nie widziałeś w łańcuchu, jest nadzieją, a następny raport o tym samym objawie znów będzie kosztował tę samą godzinę.

Czego ban wciąż nie obejmuje, i następny przypadek

Akcja odrzuca jedno źródło i tylko na portach w niej wymienionych. Nie robi nic wobec atakującego, który rotuje adresy, i nie potrafi oddzielić wrogiej maszyny od wyjścia NAT klasy operatorskiej współdzielonego przez setki użytkowników, gdzie jeden ban blokuje ludzi, którzy nic nie zrobili. Upewnij się, że filtr czyta adres, który klient naprawdę ma, a nie przekazany nagłówek ani adres proxy. Utrzymuj okno na tyle krótkie, by błąd wygasł sam.

Nic z tego nie przemawia za pominięciem poprawki protokołu; przemawia za trzymaniem dwóch myśli naraz. Ban jest węższy, niż sugeruje podsumowanie jaila, a nawet pełny ban jest węższy niż zagrożenie. Postaw łańcuch firewalla obok listy nasłuchów demona i porównuj protokół po protokole, bo te dwie listy decydują, czy ban w ogóle może dotrzeć do usługi.

Trzymaj polecenie przeładowania i listę łańcuchów w runbooku obok jaila. Następna osoba będzie potrzebować obu, a podsumowanie jaila nie powie jej ani jednego.