Filtr Fail2ban pro OpenVPN Access Server: real_ip a jail

Zkopírovali jste OpenVPN jail z příspěvku komunity, restartovali fail2ban a žádná adresa se nikdy nezablokuje. Příčinou je téměř vždy formát logu: Access Server nepíše řádky o selhání autentizace, které standardní filtr očekává. Než na filtr sáhnete, ověřte, že záznamy vůbec existují, protože vzor nemůže odpovídat tomu, co služba nikdy nezalogovala.

Toto je runbook, který na hostu s Access Serverem dodržuji: potvrdit tvar záznamu, napsat jeden ukotvený výraz, otestovat ho proti skutečnému logu, potom rozdělit jail podle napadeného povrchu a ověřit, že blokace dorazí do firewallu.

Ověřte, že záznam o selhání existuje

Access Server píše své strukturované řádky do /var/log/openvpnas.log a adresa klienta žije v poli real_ip v uvozovkách, nikoli na začátku řádku syslogu. Hledejte neúspěšné přihlášení, o kterém víte, že proběhlo, než napíšete jakýkoli vzor:

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

Pokud se nic neobjeví, dalším podezřelým je úroveň logování. Access Server má debug přepínač pro logovací databázi v /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1) a službu je nutné po jeho změně restartovat. Berte tento přepínač jako diagnostické nastavení, které se má zase stáhnout, jakmile máte svůj vzor, ne jako trvalou konfiguraci.

Dokud jste v souboru, všimněte si, které povrchy do něj zapisují. Selhání klientského portálu, administrátorského rozhraní i autentizace tunelu končí ve stejném souboru, ale s různými markery, a tento detail později určuje uspořádání jailů.

Ukotvěte jeden filtr na real_ip

Držte výraz úzký. Filtr, který si nárokuje každý řádek s IP adresou, bude blokovat lidi kvůli běžnému odpojení, a na vytíženém serveru je jediným symptomem to, že si uživatelé stěžují, že je zablokovali kvůli zavření notebooku. Nárokujte si záznam o chybě a zachyťte adresu v uvozovkách:

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

Úvodní mezera není kosmetická. Access Server odsazuje své záznamy a ukotvení na ni brání vzoru nárokovat si i řádky, které do stejného souboru píší nesouvisející služby. Pokud vaše záznamy nesou místo toho úvodní časové razítko, přizpůsobte tento prefix, ale ukotvěte se na něco, co je skutečně přítomné v každém záznamu, který chcete nárokovat.

Když potřebujete přesnost po površích, zužte dál tím, že budete vyžadovat marker povrchu (WEB_CLIENT, WEB_ADMIN nebo VPN) na stejném řádku. Jeden filtr se třemi vzory se audituje snáz než tři filtry, které se liší jedním slovem.

Otestujte výraz, než zapnete jail

Nikdy nezapínejte filtr, který jste nespustili proti produkčnímu logu. Dokumentovaný test předá filtr dvakrát, jednou pro načtení a jednou pro aplikaci, a zpráva o vynechaných řádcích je ta část, která stojí za přečtení:

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

Porovnejte počet shod se selháními, která jste ověřili v prvním kroku. Nula shod znamená, že vzor je špatný; shody na řádcích, které nejsou selháním autentizace, znamenají, že je příliš široký. Čtěte missed.txt, dokud nedokážete vysvětlit každý řádek, který jste se rozhodli nenárokovat.

Dělejte tento test na kopii, pokud je log velký, a opakujte ho po každém upgradu Access Serveru. Formát logu je rozhraní, proti kterému porovnáváte, a není to stabilní API.

Rozdělte jail podle povrchu, ne podle daemonu

Jeden Access Server nabízí několik autentizačních povrchů: klientské a administrátorské webové rozhraní na 943/tcp a tunel na 1194/udp nebo 443/tcp ve většině nasazení. Jediný jail pro všechny dovolí pokusům o hádání na tunelu zablokovat adresu, která je zároveň vaše administrativní cesta, a skrývá, který povrch je vlastně napaden. Dejte každému povrchu vlastní jail s vlastním portem a prahy:

# /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

Začněte s malými počítadly a krátkou blokací, pak je zvyšte, až si týden prohlédnete skutečný provoz. Velkorysý práh na sdílené kancelářské adrese trestá každého uživatele za jedním NAT, a agresivní blokace na povrchu tunelu odpojí legitimní klienty, kterým přes noc vypršely uložené přihlašovací údaje.

Ověřte blokaci, backend i vedlejší škody

Po restartu je výstup stavu nejrychlejším potvrzením, že jail existuje a počítá:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Pak potvrďte, že blokace dorazí do firewallu, který skutečně provozujete, protože jail nastavený pro backend, který nikdo nevynucuje, nechrání nic. U akce iptables se adresy objeví v řetězu pojmenovaném po jailu (f2b-openvpnas-tunnel); u akce nftables skončí v sadě ve vlastní tabulce fail2ban. Zkontrolujte tu, kterou váš host používá, místo abyste to předpokládali.

Dvě vedlejší kontroly jsou důležitější než samotná blokace. Zaprvé ověřte, že real_ip je adresa klienta a ne load balancer nebo reverzní proxy; za proxy každá blokace dopadne na proxy a strhne s sebou celou službu. Zadruhé sepište postup odblokování, protože adresa, která v 02:00 překročí práh, obvykle patří pohotovostnímu inženýrovi: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Mějte při ladění na paměti hranici. Fail2ban je omezovač rychlosti na jednom autentizačním povrchu, ne vrstva řízení přístupu. Nenahrazuje MFA, omezení pro jednotlivé účty ani držení administrátorského rozhraní mimo veřejný internet a Access Server má vlastní nastavení autobanu, která stojí za kontrolu, než na stejný port naskládáte dva omezovače rychlosti.