Fail2ban-filter vir die OpenVPN Access Server: real_ip en tronke

Jy het ’n OpenVPN tronk uit ’n gemeenskapsplasing gekopieer, fail2ban herbegin, en geen adres word ooit verban nie. Die rede is byna altyd die logformaat: die Access Server skryf nie die verifikasiefoutlyne wat ’n standaardfilter verwag nie. Voordat jy aan die filter raak, bevestig eers of die rekords daar is, want ’n patroon kan nie pas wat die diens nooit gelog het nie.

Dit is die prosedure wat ek op ’n Access Server-gasheer volg: bevestig die vorm van die rekord, skryf een geankerder uitdrukking, toets dit teen die regte log, deel dan die tronke volgens die oppervlak wat aangeval word en kontroleer dat die verbod die firewall bereik.

Bevestig dat die foutrekord bestaan

Die Access Server skryf sy eie gestruktureerde lyne na /var/log/openvpnas.log, en die kliëntadres staan in ’n veld real_ip tussen aanhalingstekens, nie aan die begin van ’n syslog-lyn nie. Soek vir ’n mislukte aanmelding waarvan jy weet dit het gebeur voordat jy enige patroon skryf:

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

As niks opduik nie, is die logvlak die volgende verdagte. Die Access Server het ’n ontfoutskakelaar vir die logdatabasis in /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), en die diens moet herbegin word nadat dit verander is. Behandel daardie skakelaar as ’n diagnostiese instelling wat weer afgeskakel word sodra jy jou patroon het, nie as ’n permanente konfigurasie nie.

Let terwyl jy in die lêer is op watter oppervlaktes daarin skryf. Foute in die kliëntportaal, die administrasiekoppelvlak en die tonnelverifikasie beland in dieselfde lêer met verskillende merkers, en daardie detail bepaal later die uitleg van die tronke.

Anker een filter op real_ip

Hou die uitdrukking eng. ’n Filter wat enige lyn met ’n IP-adres opeis, verban mense vir gewone verbindingsonderbrekings, en op ’n besige bediener is die enigste simptoom dat gebruikers kla dat hulle uitgesluit is omdat hulle ’n skootrekenaar toegemaak het. Eis die foutrekord op en vang die adres tussen aanhalingstekens:

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

Die voorste spasie is nie cosmeties nie. Die Access Server merk sy rekords in, en om daarop te anker verhoed dat die patroon ook lyne opeis wat onverwante dienste in dieselfde lêer skryf. Dra jou rekords eerder ’n voorste tydstempel, pas op daardie voorvoegsel, maar anker op iets wat werklik in elke rekord voorkom wat jy wil opeis.

Wanneer jy akkuraatheid per oppervlak nodig het, vernou verder deur die oppervlakmerker (WEB_CLIENT, WEB_ADMIN of VPN) in dieselfde lyn te eis. Een filter met drie patrone is makliker om te oudit as drie filters wat in een woord verskil.

Toets die uitdrukking voordat jy ’n tronk aktiveer

Aktiveer nooit ’n filter wat jy nie teen die produksielog laat loop het nie. Die gedokumenteerde toets gee die filter twee keer deur, een keer om te laai en een keer om toe te pas, en die verslag oor gemiste lyne is die deel wat werd is om te lees:

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

Vergelyk die treftelling met die foute wat jy in stap een bevestig het. Nul treffers beteken die patroon is verkeerd; treffers op lyne wat nie verifikasiefoute is nie, beteken dit is te breed. Lees missed.txt totdat jy elke lyn kan verduidelik wat jy gekies het om nie te eis nie.

Doen hierdie toets op ’n kopie as die log groot is, en herhaal dit ná elke opgradering van die Access Server. Die logformaat is die koppelvlak waarteen jy pas, en dit is nie ’n stabiele API nie.

Deel tronke volgens oppervlak, nie volgens daemon nie

Een Access Server bied verskeie verifikasieoppervlakke: kliënt- en admin-webkoppelvlakke op 943/tcp, en die tonnel op 1194/udp of 443/tcp in die meeste ontplooiings. ’n Enkele tronk vir almal laat raaierye op die tonnel ’n adres verban wat ook jou admin-pad is, en dit verberg watter oppervlak werklik aangeval word. Gee elke oppervlak sy eie tronk met sy eie poort en drumpels:

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

Begin met klein tellers en ’n kort verbod, en verhoog dit eers nadat jy ’n week se regte verkeer dopgehou het. ’n Ruim drumpel op ’n gedeelde kantooradres straf elke gebruiker agter een NAT, en ’n aggressiewe verbod op die tonneloppervlak ontkoppel wettige kliënte wie se gestoorde geloofsbriewe oornag verval het.

Kontroleer die verbod, die backend en die kollaterale skade

Ná ’n herbegin is die statusuitset die vinnigste bevestiging dat die tronk bestaan en tel:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Bevestig dan dat die verbod die firewall bereik wat jy werklik bedryf, want ’n tronk wat vir ’n backend opgestel is wat niks afdwing nie, beskerm niks. Met die iptables-aksie verskyn die adresse in ’n ketting wat na die tronk vernoem is (f2b-openvpnas-tunnel); met die nftables-aksie beland hulle in ’n stel in die eie fail2ban-tabel. Kontroleer die een wat jou gasheer gebruik eerder as om dit aan te neem.

Twee kollaterale kontroles is belangriker as die verbod self. Eerstens, kontroleer dat real_ip die kliëntadres is en nie ’n lasbalanseerder of omgekeerde proxy nie; agter ’n proxy beland elke verbod op die proxy en sleep die hele diens saam. Tweedens, skryf die prosedure vir ontsperring neer, want die adres wat om 02:00 die drumpel oorskry, behoort gewoonlik aan die diensingenieur: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Hou die grens in gedagte terwyl jy instel. Fail2ban is ’n tempobeperker op een verifikasieoppervlak, nie ’n toegangsbeheermiddel nie. Dit vervang nie MFA nie, nie beperkings per rekening nie, en ook nie om die administrasiekoppelvlak van die publieke internet af te hou nie, en die Access Server het sy eie outoban-instellings wat die moeite werd is om na te gaan voordat jy twee tempobeperkers op dieselfde poort stapel.