Fail2ban-filter foar OpenVPN Access Server: real_ip en jailen

Jo hawwe in OpenVPN jail kopiearre út in mienskipspost, fail2ban opnij starten, en gjin inkel adres wurdt ea ferbean. De reden is hast altyd it logformaet: de Access Server skriuwt net de rigels foar mislearre autentikaasje dy't in standertfilter ferwachtet. Foardat jo it filter oanreitsje, kontrolearje dat de records der oeral binne, want in patroan kin net oerienkomme mei wat de tsjinst nea logd hat.

Dit is de runbook dy't ik folgje op in Access Server-host: befêstigje de foarm fan it record, skriuw ien ankerde útdrukking, test dy op 'e echte log, diel dan de jailen op neffens it oerflak dat oanfallen wurdt en kontrolearje dat de blokkade de firewall berikt.

Befêstigje dat it flaterrecord bestiet

De Access Server skriuwt syn eigen strukturearre rigels nei /var/log/openvpnas.log, en it klientadres sit yn in fjild real_ip tusken oanhellingstekens, net oan it begjin fan in syslog-rigel. Sykje nei in mislearre oanmelding wêrfan jo witte dat dy barde foardat jo in patroan skriuwe:

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

As der neat ferskynt, is it lognivo de folgjende fertochte. De Access Server hat in debug-skeakel foar de logdatabase yn /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), en de tsjinst moat opnij starten wurde neidat dy feroare is. Behannelje dy skeakel as in diagnostyske ynstelling dy't wer omleech draaid wurdt as jo jo patroan hawwe, net as in permaninte konfiguraasje.

Wylst jo yn it bestân binne, merkjou op hokker oerflakken deryn skriuwe. Flaters fan it klientportaal, de behearderinterface en de tunnelautentikaasje lânje yn itselde bestân mei ferskate markers, en dat detail bepaalt letter de yndieling fan 'e jailen.

Ankerje ien filter op real_ip

Hâld de útdrukking smel. In filter dat elke rigel mei in IP-adres opeasket, ferbant minsken foar gewoane ferbiningen, en op in drokke server is it iennige symptoom dat brûkers kleie dat se bûten sletten binne om't se in laptop tichtdien hawwe. Eisje it flaterrecord op en fange it adres tusken oanhellingstekens:

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

It liedende romte is net kosmetysk. De Access Server springt syn records yn, en ankerje dêrop foarkomt dat it patroan ek rigels opeasket dy't net-relatearre tsjinsten yn itselde bestân skriuwe. As jo records ynstee in liedende tiidstimpel drage, oerienkomme dan dat foarheaksel, mar ankerje op eat dat wier yn elk record oanwêzich is dat jo fan plan binne op te eiskjen.

As jo presyzje per oerflak nedich hawwe, fernau dan fierder troch de oerflakmarker (WEB_CLIENT, WEB_ADMIN of VPN) yn deselde rigel te easkjen. Ien filter mei trije patroanen is makliker te auditearjen as trije filters dy't yn ien wurd ferskille.

Test de útdrukking foardat jo in jail ynskeakelje

Skeakelje nea in filter yn dat jo net tsjin 'e produksjelog draaid hawwe. De dokumintearre test jout it filter twa kear troch, ien kear om te laden en ien kear om ta te passen, en it rapport oer miste rigels is it part dat it lêzen wurdich is:

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

Fergelykje it oantal oerienkomsten mei de flaters dy't jo yn 'e earste stap befêstige hawwe. Nul oerienkomsten betsjutte dat it patroan ferkeard is; oerienkomsten op rigels dy't gjin autentikaasjeflaters binne betsjutte dat it te breed is. Lês missed.txt oant jo elke rigel ferklearje kinne dy't jo keazen hawwe net op te eiskjen.

Doch dizze test op in kopy as de log grut is, en werhelje him nei elke upgrade fan 'e Access Server. It logformaet is de interface dêr't jo tsjin oerienkomme, en it is gjin stabile API.

Diel jailen op neffens oerflak, net neffens daemon

Ien Access Server presintearret ferskate autentikaasje-oerflakken: klant- en behearderwebinterfaces op 943/tcp, en de tunnel op 1194/udp of 443/tcp yn 'e measte ymplemintaasjes. Ien jail dy't se allegear dekt lit riedpogingen op 'e tunnel in adres ferbanne dat ek jo behearderpaad is, en it ferberget hokker oerflak eins oanfallen wurdt. Jou elk oerflak syn eigen jail mei syn eigen poarte en drompels:

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

Begjin mei lytse tellers en in koarte blokkade, en ferheegje se as jo in wike echte ferkear sjoen hawwe. In romhertige drompel op in dield kantoaradres straft elke brûker efter ien NAT, en in agressive blokkade op it tunneloerflak ûntkeppele legitime klanten waans bewarre ynloggegevens nachts ferrûn binne.

Kontrolearje de blokkade, de backend en de kollaterale skea

Nei in werstart is de statusútfier de fluchste befêstiging dat de jail bestiet en telt:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Befêstigje dan dat de blokkade de firewall berikt dy't jo echt draaie, want in jail ynsteld foar in backend dy't nimmen hanthavent beskermet neat. Mei de iptables-aksje ferskine de adressen yn in keatling neamd nei de jail (f2b-openvpnas-tunnel); mei de nftables-aksje lânje se yn in set yn 'e eigen fail2ban-tabel. Kontrolearje dy't jo host brûkt ynstee fan oan te nimmen.

Twa kollaterale kontrôles binne wichtiger as de blokkade sels. Earst, kontrolearje dat real_ip it klientadres is en gjin load balancer of omkearde proxy; efter in proxy lânje alle blokkades op 'e proxy en sleepe de hiele tsjinst mei. Twadde, skriuw de proseduere foar it opheffen fan 'e blokkade op, want it adres dat om 02:00 de drompel oerstekt heart meastentiids ta de tsjinsthawwende yngenieur: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Hâld de grins yn 't each by it ôfstimmen. Fail2ban is in faasjebegrinzer op ien autentikaasje-oerflak, gjin tagongskontrôlelaach. It ferfangt gjin MFA, gjin beheiningen per akkount en ek net it bûten it iepenbiere ynternet hâlden fan 'e behearderinterface, en de Access Server hat syn eigen autoban-ynstellingen dy't it kontrolearjen wurdich binne foardat jo twa faasjebegrinzers op deselde poarte steapelje.