Fail2ban-filter voor OpenVPN Access Server: real_ip en jails

Je hebt een OpenVPN jail uit een communitypost gekopieerd, fail2ban herstart, en geen enkel adres wordt ooit geblokkeerd. De oorzaak is bijna altijd het logformaat: de Access Server schrijft niet de regels over mislukte authenticatie die een standaardfilter verwacht. Voordat je het filter aanraakt, controleer of de records er überhaupt zijn, want een patroon kan niet matchen wat de dienst nooit heeft gelogd.

Dit is de runbook die ik op een Access Server-host volg: bevestig de vorm van het record, schrijf één verankerde expressie, test die tegen het echte log, splits daarna de jails op naar het aangevallen oppervlak en controleer dat de ban de firewall bereikt.

Bevestig dat het foutrecord bestaat

De Access Server schrijft zijn eigen gestructureerde regels naar /var/log/openvpnas.log, en het clientadres staat in een veld real_ip tussen aanhalingstekens, niet aan het begin van een syslogregel. Zoek een mislukte login waarvan je weet dat die plaatsvond voordat je een patroon schrijft:

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

Als er niets verschijnt, is het logniveau de volgende verdachte. De Access Server heeft een foutopsporingsschakelaar voor de logdatabase in /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), en de dienst moet na het wijzigen opnieuw worden gestart. Behandel die schakelaar als een diagnostische instelling die weer omlaag gaat zodra je je patroon hebt, niet als een permanente configuratie.

Let terwijl je in het bestand bent op welke oppervlakken erin schrijven. Fouten in het clientportaal, de beheerinterface en de tunnelauthenticatie belanden in hetzelfde bestand met verschillende markeringen, en dat detail bepaalt later de indeling van de jails.

Anker één filter op real_ip

Houd de expressie smal. Een filter dat elke regel met een IP-adres opeist, blokkeert mensen voor gewone verbindingsonderbrekingen, en op een drukke server is het enige symptoom dat gebruikers klagen dat ze buitengesloten zijn omdat ze een laptop dichtklapten. Eis het foutrecord op en vang het adres tussen aanhalingstekens:

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

De voorloopspatie is niet cosmetisch. De Access Server springt zijn records in, en verankering daarop voorkomt dat het patroon ook regels opeist die niet-gerelateerde diensten naar hetzelfde bestand schrijven. Als je records in plaats daarvan een tijdstempel vooraan hebben, match dat voorvoegsel, maar anker op iets dat werkelijk in elk record staat dat je wilt opeisen.

Als je precisie per oppervlak nodig hebt, vernauw verder door de oppervlakmarkering (WEB_CLIENT, WEB_ADMIN of VPN) op dezelfde regel te eisen. Eén filter met drie patronen is makkelijker te auditen dan drie filters die één woord verschillen.

Test de expressie voordat je een jail inschakelt

Schakel nooit een filter in dat je niet tegen het productielog hebt uitgevoerd. De gedocumenteerde test geeft het filter twee keer door, één keer om te laden en één keer om toe te passen, en het rapport over gemiste regels is het deel dat het lezen waard is:

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

Vergelijk het aantal treffers met de fouten die je in de eerste stap hebt geverifieerd. Nul treffers betekent dat het patroon verkeerd is; treffers op regels die geen authenticatiefouten zijn, betekenen dat het te breed is. Lees missed.txt tot je elke regel kunt uitleggen die je hebt besloten niet op te eisen.

Doe deze test op een kopie als het log groot is, en herhaal hem na elke upgrade van de Access Server. Het logformaat is de interface waar je tegen matcht, en het is geen stabiele API.

Splits jails per oppervlak, niet per daemon

Eén Access Server biedt verschillende authenticatieoppervlakken: client- en beheerwebinterfaces op 943/tcp, en de tunnel op 1194/udp of 443/tcp in de meeste implementaties. Eén jail die ze allemaal dekt, laat raadpogingen op de tunnel een adres blokkeren dat ook je beheerpad is, en verbergt welk oppervlak werkelijk wordt aangevallen. Geef elk oppervlak zijn eigen jail met eigen poort en drempels:

# /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 kleine tellers en een korte ban, en verhoog ze pas als je een week echt verkeer hebt bekeken. Een ruime drempel op een gedeeld kantooradres straft elke gebruiker achter één NAT, en een agressieve ban op het tunneloppervlak verbreekt legitieme clients wier opgeslagen inloggegevens 's nachts zijn verlopen.

Controleer de ban, de backend en de bijkomende schade

Na een herstart is de statusuitvoer de snelste bevestiging dat de jail bestaat en telt:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Bevestig daarna dat de ban de firewall bereikt die je daadwerkelijk draait, want een jail die is geconfigureerd voor een backend die niemand afdwingt, beschermt niets. Met de iptables-actie verschijnen de adressen in een keten die naar de jail is vernoemd (f2b-openvpnas-tunnel); met de nftables-actie belanden ze in een set in de eigen tabel van fail2ban. Controleer degene die jouw host gebruikt in plaats van ervan uit te gaan.

Twee bijkomende controles wegen zwaarder dan de ban zelf. Ten eerste: controleer dat real_ip het clientadres is en niet een loadbalancer of reverse proxy; achter een proxy belandt elke ban op de proxy en sleurt de hele dienst mee. Ten tweede: schrijf de procedure voor het opheffen van de ban op, want het adres dat om 02:00 de drempel overschrijdt, is meestal van de dienstdoende engineer: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Houd de grens in gedachten tijdens het afstellen. Fail2ban is een snelheidsbegrenzer op één authenticatieoppervlak, geen toegangsbeheerslaag. Het vervangt geen MFA, geen beperkingen per account en ook niet het buiten het publieke internet houden van de beheerinterface, en de Access Server heeft zijn eigen autoban-instellingen die het controleren waard zijn voordat je twee snelheidsbegrenzers op dezelfde poort stapelt.