Fail2ban-filter for OpenVPN Access Server: real_ip og jail-ar

Du kopierte ein OpenVPN jail frå eit innlegg i fellesskapet, starta fail2ban på nytt, og inga adresse vert nokon gong sperra. Årsaka er nesten alltid loggformatet: Access Server skriv ikkje dei mislukka påloggingslinjene som eit standardfilter ventar. Før du rører filteret, stadfest at postane i det heile finst, for eit mønster kan ikkje matche det tenesta aldri logga.

Dette er runboka eg følgjer på ein Access Server-vert: stadfest forma på posten, skriv eitt forankra uttrykk, test det mot den ekte loggen, del deretter jail-ane etter flata som vert angripen, og kontroller at sperringa når brannmuren.

Stadfest at feilposten finst

Access Server skriv sine eigne strukturerte linjer til /var/log/openvpnas.log, og klientadressa ligg i eit felt real_ip i hermeteikn, ikkje i byrjinga av ei syslog-linje. Søk etter ei mislukka pålogging du veit fann stad, før du skriv noko mønster:

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

Viss ingenting dukkar opp, er loggnivået den neste mistenkte. Access Server har ein feilsøkingsbrytar for loggdatabasen i /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), og tenesta må startast på nytt etter at han er endra. Handsame brytaren som ei diagnostisk innstilling som skal skruast ned att når du har mønsteret ditt, ikkje som ein permanent konfigurasjon.

Medan du er i fila, legg merke til kva flater som skriv til henne. Feil i klientportalen, administrasjonsgrensesnittet og tunnelautentisering endar i same fil med ulike markørar, og den detaljen avgjer seinare oppsettet av jail-ane.

Forankre eitt filter på real_ip

Hald uttrykket smalt. Eit filter som gjer krav på kvar linje med ei IP-adresse, sperrar folk for vanlege tilkoplingsbrot, og på ein travel server er det einaste symptomet at brukarar klagar over å vere låste ute fordi dei lukka ein laptop. Gjer krav på feilposten og fang adressa i hermeteikn:

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

Det leiande mellomrommet er ikkje kosmetikk. Access Server rykkjer inn postane sine, og forankring på det hindrar mønsteret i å gjere krav på linjer som urelaterte tenester skriv til same fil. Viss postane dine i staden har eit tidsstempel først, match det prefikset, men forankre på noko som verkeleg finst i kvar post du har tenkt å gjere krav på.

Når du treng presisjon per flate, snevre ytterlegare inn ved å krevje flatemarkøren (WEB_CLIENT, WEB_ADMIN eller VPN) på same linje. Eitt filter med tre mønster er lettare å revidere enn tre filter som skil seg med eitt ord.

Test uttrykket før du aktiverer ein jail

Aktiver aldri eit filter du ikkje har køyrt mot produksjonsloggen. Den dokumenterte testen sender filteret gjennom to gonger, éin gong for å laste og éin gong for å bruke, og rapporten over oversette linjer er den delen som er verd å lese:

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

Samanlikn talet på treff med feila du stadfesta i første trinn. Null treff tyder at mønsteret er feil; treff på linjer som ikkje er autentiseringsfeil, tyder at det er for breitt. Les missed.txt til du kan forklare kvar linje du valde å ikkje gjere krav på.

Gjer denne testen på ein kopi viss loggen er stor, og køyr han på nytt etter kvar oppgradering av Access Server. Loggformatet er grensesnittet du matchar mot, og det er ikkje eit stabilt API.

Del jail-ane etter flate, ikkje etter daemon

Éin Access Server presenterer fleire autentiseringsflater: klient- og adminnettgrensesnitt på 943/tcp, og tunnelen på 1194/udp eller 443/tcp i dei fleste installasjonar. Éin jail som dekkjer dei alle, lèt gjetteforsøk på tunnelen sperre ei adresse som òg er adminvegen din, og han skjuler kva flate som faktisk er under åtak. Gje kvar flate sin eigen jail med sin eigen port og tersklar:

# /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å teljarar og ei kort sperring, og hev dei når du har følgt ei veke med ekte trafikk. Ein raus terskel på ei delt kontoradresse straffar kvar brukar bak éin NAT, og ei aggressiv sperring på tunnelflata koplar frå legitime klientar som fekk lagra påloggingsinformasjon utlopen over natta.

Kontroller sperringa, backend og følgjeskadane

Etter ein restart er statusutskrifta den raskaste stadfestinga på at jailen finst og tel:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Stadfest deretter at sperringa når brannmuren du faktisk køyrer, for ein jail sett opp for ein backend som ingen handhevar, vernar ingen ting. Med iptables-handlinga viser adressene seg i ei kjede kalla opp etter jailen (f2b-openvpnas-tunnel); med nftables-handlinga landar dei i eit sett i fail2ban sin eigen tabell. Kontroller den verten din brukar i staden for å gå ut frå det.

To følgjekontrollar tyder meir enn sjølve sperringa. For det første, stadfest at real_ip er klientadressa og ikkje ein lastbalansar eller omvend proxy; bak ein proxy landar kvar sperring på proxyen og dreg heile tenesta med seg. For det andre, skriv ned prosedyren for å oppheve sperringa, for adressa som kryssar terskelen kl. 02:00 høyrer vanlegvis til den vaktansvarlege ingeniøren: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Hugs grensa medan du tunar. Fail2ban er ein hastigheitsavgrensar på éi autentiseringsflate, ikkje eit tilgangskontrollag. Det erstattar ikkje MFA, avgrensingar per konto eller å halde administrasjonsgrensesnittet utanfor det offentlege internettet, og Access Server har eigne autoban-innstillingar som er verd å sjekke før du stablar to hastigheitsavgrensarar på same port.