Fail2ban-filter för OpenVPN Access Server: real_ip och jails

Du kopierade en OpenVPN jail från ett communityinlägg, startade om fail2ban och ingen adress blir någonsin blockerad. Orsaken är nästan alltid loggformatet: Access Server skriver inte de misslyckade inloggningsrader som ett standardfilter förväntar sig. Innan du rör filtret, bekräfta att posterna ens finns, för ett mönster kan inte matcha det som tjänsten aldrig loggade.

Det här är runbooken jag följer på en Access Server-värd: bekräfta postens form, skriv ett förankrat uttryck, testa det mot den riktiga loggen, dela sedan upp jailarna efter ytan som attackeras och kontrollera att blockeringen når brandväggen.

Bekräfta att felposten finns

Access Server skriver sina egna strukturerade rader till /var/log/openvpnas.log, och klientadressen ligger i ett fält real_ip inom citattecken, inte i början av en syslograd. Sök efter en misslyckad inloggning som du vet ägde rum innan du skriver något mönster:

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

Om inget dyker upp är loggnivån nästa misstänkta. Access Server har en felsökningsbrytare för loggdatabasen i /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), och tjänsten måste startas om efter att den ändrats. Behandla brytaren som en diagnostisk inställning som ska skruvas ned igen när du har ditt mönster, inte som en permanent konfiguration.

Medan du är i filen, notera vilka ytor som skriver till den. Fel i klientportalen, administrationsgränssnittet och tunnelautentiseringen hamnar i samma fil med olika markörer, och den detaljen avgör senare jailarnas layout.

Förankra ett filter på real_ip

Håll uttrycket smalt. Ett filter som gör anspråk på varje rad med en IP-adress blockerar folk för vanliga frånkopplingar, och på en upptagen server är det enda symptomet att användare klagar över att ha blivit utelåsta för att de stängde en laptop. Gör anspråk på felposten och fånga adressen inom citattecken:

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

Det inledande blanksteget är inte kosmetika. Access Server drar in sina poster, och förankring på det hindrar mönstret från att också göra anspråk på rader som orelaterade tjänster skriver till samma fil. Om dina poster i stället har en tidsstämpel först, matcha det prefixet, men förankra på något som verkligen finns i varje post du tänker göra anspråk på.

När du behöver precision per yta, snäva in ytterligare genom att kräva ytmarkören (WEB_CLIENT, WEB_ADMIN eller VPN) på samma rad. Ett filter med tre mönster är lättare att granska än tre filter som skiljer sig med ett ord.

Testa uttrycket innan du aktiverar en jail

Aktivera aldrig ett filter som du inte har kört mot produktionsloggen. Det dokumenterade testet skickar filtret igenom två gånger, en gång för att ladda och en gång för att tillämpa, och rapporten över missade rader är den del som är värd att läsa:

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

Jämför antalet träffar med de fel du bekräftade i första steget. Noll träffar betyder att mönstret är fel; träffar på rader som inte är autentiseringsfel betyder att det är för brett. Läs missed.txt tills du kan förklara varje rad du valde att inte göra anspråk på.

Gör det här testet på en kopia om loggen är stor, och kör om det efter varje uppgradering av Access Server. Loggformatet är gränssnittet du matchar mot, och det är inte ett stabilt API.

Dela upp jailarna efter yta, inte efter daemon

En Access Server presenterar flera autentiseringsytor: klient- och adminwebbgränssnitt på 943/tcp, och tunneln på 1194/udp eller 443/tcp i de flesta installationer. En enda jail som täcker alla låter gissningsförsök på tunneln blockera en adress som också är din adminväg, och den döljer vilken yta som faktiskt är under attack. Ge varje yta sin egen jail med egen port och egna trösklar:

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

Börja med små räknare och en kort blockering, och höj dem när du har följt en vecka av verklig trafik. En generös tröskel på en delad kontorsadress straffar varje användare bakom en NAT, och en aggressiv blockering på tunnelytan kopplar från legitima klienter vars sparade inloggningsuppgifter gick ut under natten.

Kontrollera blockeringen, backend och följdskadorna

Efter en omstart är statusutskriften den snabbaste bekräftelsen på att jailen finns och räknar:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Bekräfta sedan att blockeringen når den brandvägg du faktiskt kör, för en jail som är konfigurerad för en backend som ingen upprätthåller skyddar ingenting. Med iptables-åtgärden dyker adresserna upp i en kedja uppkallad efter jailen (f2b-openvpnas-tunnel); med nftables-åtgärden hamnar de i en mängd i fail2bans egen tabell. Kontrollera den som din värd använder i stället för att anta.

Två följdkontroller väger tyngre än själva blockeringen. För det första, bekräfta att real_ip är klientadressen och inte en lastbalanserare eller omvänd proxy; bakom en proxy hamnar varje blockering på proxyn och drar med sig hela tjänsten. För det andra, skriv ned proceduren för att häva blockeringen, för adressen som passerar tröskeln kl. 02:00 tillhör vanligtvis den jourhavande ingenjören: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Ha gränsen i minnet medan du justerar. Fail2ban är en hastighetsbegränsare på en autentiseringsyta, inte ett åtkomstkontrollager. Det ersätter inte MFA, begränsningar per konto eller att hålla administrationsgränssnittet utanför det publika internet, och Access Server har egna autoban-inställningar som är värda att kontrollera innan du staplar två hastighetsbegränsare på samma port.