Fail2ban-filter for OpenVPN Access Server: real_ip og jails

Du kopierte en OpenVPN jail fra et innlegg i fellesskapet, restartet fail2ban, og ingen adresse blir noen gang sperret. Årsaken er nesten alltid loggformatet: Access Server skriver ikke de mislykkede påloggingslinjene som et standardfilter forventer. Før du rører filteret, bekreft at postene i det hele tatt finnes, for et mønster kan ikke matche det tjenesten aldri logget.

Dette er runbooken jeg følger på en Access Server-vert: bekreft postens form, skriv ett forankret uttrykk, test det mot den ekte loggen, del deretter jailene opp etter flaten som angripes, og kontroller at sperringen når brannmuren.

Bekreft at feilposten finnes

Access Server skriver sine egne strukturerte linjer til /var/log/openvpnas.log, og klientadressen ligger i et felt real_ip i anførselstegn, ikke i begynnelsen av en syslog-linje. Søk etter en mislykket pålogging du vet fant sted, før du skriver noe mønster:

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

Hvis ingenting dukker opp, er loggnivået den neste mistenkte. Access Server har en feilsøkingsbryter for loggdatabasen i /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), og tjenesten må restartes etter at den er endret. Behandle bryteren som en diagnostisk innstilling som skal skrus ned igjen når du har mønsteret ditt, ikke som en permanent konfigurasjon.

Mens du er i filen, legg merke til hvilke flater som skriver til den. Feil i klientportalen, administrasjonsgrensesnittet og tunnelautentisering ender i samme fil med ulike markører, og den detaljen avgjør senere jailenes oppsett.

Forankre ett filter på real_ip

Hold uttrykket smalt. Et filter som gjør krav på hver linje med en IP-adresse, sperrer folk for vanlige tilkoblingsbrudd, og på en travel server er det eneste symptomet at brukere klager over å være låst ute fordi de lukket en laptop. Gjør krav på feilposten og fang adressen i anførselstegn:

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

Det ledende mellomrommet er ikke kosmetikk. Access Server rykker inn postene sine, og forankring på det hindrer mønsteret i å gjøre krav på linjer som urelaterte tjenester skriver til samme fil. Hvis postene dine i stedet har et tidsstempel først, match det prefikset, men forankre på noe som virkelig finnes i hver post du har tenkt å gjøre krav på.

Når du trenger presisjon per flate, innsnevre ytterligere ved å kreve flatemarkøren (WEB_CLIENT, WEB_ADMIN eller VPN) på samme linje. Ett filter med tre mønstre er lettere å revidere enn tre filtre som skiller seg med ett ord.

Test uttrykket før du aktiverer en jail

Aktiver aldri et filter du ikke har kjørt mot produksjonsloggen. Den dokumenterte testen sender filteret gjennom to ganger, én gang for å laste og én gang for å bruke, og rapporten over oversette linjer er den delen som er verdt å lese:

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

Sammenlign antall treff med feilene du bekreftet i første trinn. Null treff betyr at mønsteret er feil; treff på linjer som ikke er autentiseringsfeil betyr at det er for bredt. Les missed.txt til du kan forklare hver linje du valgte å ikke gjøre krav på.

Gjør denne testen på en kopi hvis loggen er stor, og kjør den på nytt etter enhver oppgradering av Access Server. Loggformatet er grensesnittet du matcher mot, og det er ikke et stabilt API.

Del jails opp etter flate, ikke etter daemon

Én Access Server presenterer flere autentiseringsflater: klient- og adminnettsgrensesnitt på 943/tcp, og tunnelen på 1194/udp eller 443/tcp i de fleste installasjoner. Én jail som dekker dem alle lar gjetteforsøk på tunnelen sperre en adresse som også er adminveien din, og den skjuler hvilken flate som faktisk er under angrep. Gi hver flate sin egen jail med sin egen port og terskler:

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

Start med små tellere og en kort sperring, og hev dem når du har fulgt en uke med ekte trafikk. En raus terskel på en delt kontoradresse straffer hver bruker bak én NAT, og en aggressiv sperring på tunnelflaten kobler fra legitime klienter hvis lagrede påloggingsinformasjon utløp over natten.

Kontroller sperringen, backend og følgeskadene

Etter en restart er statusutskriften den raskeste bekreftelsen på at jailen finnes og teller:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Bekreft deretter at sperringen når brannmuren du faktisk kjører, for en jail satt opp for en backend som ingen håndhever, beskytter ingenting. Med iptables-handlingen vises adressene i en kjede oppkalt etter jailen (f2b-openvpnas-tunnel); med nftables-handlingen lander de i et sett i fail2bans egen tabell. Kontroller den verten din bruker i stedet for å anta.

To følgekontroller betyr mer enn selve sperringen. For det første, bekreft at real_ip er klientadressen og ikke en lastbalanserer eller omvendt proxy; bak en proxy lander hver sperring på proxyen og drar hele tjenesten med seg. For det andre, skriv ned prosedyren for å oppheve sperringen, for adressen som krysser terskelen kl. 02:00 tilhører vanligvis den vaktansvarlige ingeniøren: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Husk grensen mens du tuner. Fail2ban er en hastighetsbegrenser på én autentiseringsflate, ikke et tilgangskontrollag. Det erstatter ikke MFA, begrensninger per konto eller å holde administrasjonsgrensesnittet utenfor det offentlige internett, og Access Server har egne autoban-innstillinger som er verdt å sjekke før du stabler to hastighetsbegrensere på samme port.