Filtr Fail2ban dla OpenVPN Access Server: real_ip i jail

Access Server zapisuje własny format logu, więc standardowe filtry niczego nie znajdują. Zakotwicz się na real_ip, rozdziel jail według powierzchni i sprawdź, czy adres nie jest proxy.

Skopiowałeś OpenVPN jail z wpisu społeczności, zrestartowałeś fail2ban i żaden adres nigdy nie zostaje zablokowany. Przyczyną jest prawie zawsze format logu: Access Server nie zapisuje linii nieudanej autoryzacji, których oczekuje standardowy filtr. Zanim dotkniesz filtra, potwierdź, że rekordy w ogóle istnieją, bo wzorzec nie może dopasować się do tego, czego usługa nigdy nie zapisała.

To procedura, której trzymam się na hoście z Access Serverem: potwierdź kształt rekordu, napisz jedno zakotwiczone wyrażenie, przetestuj je na prawdziwym logu, następnie rozdziel jail według atakowanej powierzchni i sprawdź, czy blokada dociera do zapory.

Potwierdź, że rekord błędu istnieje

Access Server zapisuje własne ustrukturyzowane linie do /var/log/openvpnas.log, a adres klienta znajduje się w polu real_ip w cudzysłowie, a nie na początku linii syslog. Zanim napiszesz jakikolwiek wzorzec, poszukaj nieudanego logowania, o którym wiesz, że wystąpiło:

grep -i 'LOG ERR' /var/log/openvpnas.log | tail -20

Jeśli nic się nie pojawi, następnym podejrzanym jest poziom logowania. Access Server ma przełącznik debugowania bazy logów w /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), i usługę trzeba zrestartować po jego zmianie. Traktuj ten przełącznik jako ustawienie diagnostyczne, które trzeba ponownie wyłączyć, gdy masz już swój wzorzec, a nie jako stałą konfigurację.

Będąc w pliku, zwróć uwagę, które powierzchnie do niego piszą. Błędy portalu klienta, interfejsu administracyjnego i uwierzytelniania tunelu trafiają do tego samego pliku z różnymi znacznikami, i ten szczegół decyduje później o układzie jail.

Zakotwicz jeden filtr na real_ip

Trzymaj wyrażenie wąskie. Filtr, który rości sobie prawo do każdej linii z adresem IP, będzie blokował ludzi za zwykłe rozłączenia, a na zajętym serwerze jedynym objawem są skargi użytkowników, że zostali zablokowani za zamknięcie laptopa. Rość sobie prawo do rekordu błędu i przechwyć adres w cudzysłowie:

# /etc/fail2ban/filter.d/openvpnaccess.local
[Definition]
failregex = ^ .*LOG ERR.*"real_ip": "<HOST>".*
ignoreregex =

Wiodąca spacja nie jest kosmetyczna. Access Server wcina swoje rekordy, a zakotwiczenie na niej nie pozwala wzorcowi rościć sobie prawa także do linii, które do tego samego pliku zapisują niepowiązane usługi. Jeśli twoje rekordy mają zamiast tego wiodący znacznik czasu, dopasuj ten prefiks, ale zakotwicz się na czymś, co naprawdę występuje w każdym rekordzie, który zamierzasz objąć.

Gdy potrzebujesz precyzji na powierzchnię, zawęź jeszcze bardziej, wymagając znacznika powierzchni (WEB_CLIENT, WEB_ADMIN lub VPN) w tej samej linii. Jeden filtr z trzema wzorcami łatwiej zaudytować niż trzy filtry różniące się jednym słowem.

Przetestuj wyrażenie, zanim włączysz jail

Nigdy nie włączaj filtra, którego nie uruchomiłeś na logu produkcyjnym. Udokumentowany test przepuszcza filtr dwa razy, raz w celu wczytania i raz w celu zastosowania, a raport pominiętych linii to ta część, którą warto przeczytać:

fail2ban-regex --print-all-missed /var/log/openvpnas.log \
  /etc/fail2ban/filter.d/openvpnaccess.local \
  /etc/fail2ban/filter.d/openvpnaccess.local > missed.txt

Porównaj liczbę dopasowań z błędami, które potwierdziłeś w pierwszym kroku. Zero dopasowań oznacza, że wzorzec jest błędny; dopasowania w liniach, które nie są błędami uwierzytelniania, oznaczają, że jest zbyt szeroki. Czytaj missed.txt, aż wyjaśnisz każdą linię, której postanowiłeś nie obejmować.

Wykonaj ten test na kopii, jeśli log jest duży, i powtarzaj go po każdej aktualizacji Access Server. Format logu to interfejs, względem którego dopasowujesz, i nie jest to stabilne API.

Rozdziel jail według powierzchni, a nie według demona

Jeden Access Server udostępnia kilka powierzchni uwierzytelniania: interfejsy webowe klienta i administracji na 943/tcp oraz tunel na 1194/udp lub 443/tcp w większości wdrożeń. Jeden jail obejmujący je wszystkie pozwala próbom zgadywania na tunelu zablokować adres, który jest także twoją ścieżką administracyjną, i ukrywa, która powierzchnia jest faktycznie atakowana. Daj każdej powierzchni własny jail z własnym portem i progami:

# /etc/fail2ban/jail.d/openvpnaccess.local
[openvpnas-web-client]
enabled  = true
port     = 943
protocol = tcp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 3
findtime = 10m
bantime  = 1h
[openvpnas-tunnel]
enabled  = true
port     = 443
protocol = udp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 5
findtime = 10m
bantime  = 1h

Zacznij od małych liczników i krótkiej blokady, a podnieś je, gdy obejrzysz tydzień prawdziwego ruchu. Szczodry próg na współdzielonym adresie biurowym karze każdego użytkownika za jednym NAT, a agresywna blokada na powierzchni tunelu odcina legalnych klientów, których zapisane dane logowania wygasły w nocy.

Sprawdź blokadę, backend i szkody uboczne

Po restarcie wynik statusu jest najszybszym potwierdzeniem, że jail istnieje i liczy:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Następnie potwierdź, że blokada dociera do zapory, którą naprawdę prowadzisz, bo jail skonfigurowany dla backendu, którego nikt nie egzekwuje, niczego nie chroni. Przy akcji iptables adresy pojawiają się w łańcuchu nazwanym od jail (f2b-openvpnas-tunnel); przy akcji nftables trafiają do zbioru we własnej tabeli fail2ban. Sprawdź ten, którego używa twój host, zamiast zakładać.

Dwa sprawdzenia uboczne ważą więcej niż sama blokada. Po pierwsze, potwierdź, że real_ip to adres klienta, a nie balanser obciążenia ani odwrotne proxy; za proxy każda blokada trafia w proxy i ciągnie za sobą całą usługę. Po drugie, zapisz procedurę odblokowania, bo adres, który o 02:00 przekracza próg, zwykle należy do inżyniera dyżurnego: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Miej granicę na uwadze podczas strojenia. Fail2ban to ogranicznik szybkości na jednej powierzchni uwierzytelniania, a nie warstwa kontroli dostępu. Nie zastępuje MFA, ograniczeń na konto ani trzymania interfejsu administracyjnego poza publicznym internetem, a Access Server ma własne ustawienia autoban, które warto sprawdzić, zanim nałożysz dwa ograniczniki szybkości na ten sam port.

Powiązane artykuły