Fail2ban-filter til OpenVPN Access Server: real_ip og jails
Access Server skriver sit eget logformat, så standardfiltre ikke matcher noget. Forankr på real_ip, del jails op pr. flade, og kontroller at adressen ikke er en proxy.
Du kopierede en OpenVPN jail fra et opslag i fællesskabet, genstartede fail2ban, og ingen adresse bliver nogensinde spærret. Årsagen er næsten altid logformatet: Access Server skriver ikke de mislykkede login-linjer, som et standardfilter forventer. Før du rører ved filteret, skal du bekræfte, at posterne overhovedet findes, for et mønster kan ikke matche det, tjenesten aldrig har logget.
Det er den runbook, jeg følger på en Access Server-vært: bekræft postens form, skriv ét forankret udtryk, test det mod den rigtige log, og del derefter jailene op efter den flade, der angribes, og kontroller, at spærringen når firewallen.
Bekræft, at fejlposten findes
Access Server skriver sine egne strukturerede linjer til /var/log/openvpnas.log, og klientadressen ligger i et felt real_ip i anførselstegn og ikke i begyndelsen af en syslog-linje. Søg efter et mislykket login, som du ved er sket, før du skriver et mønster:
grep -i 'LOG ERR' /var/log/openvpnas.log | tail -20Hvis der ikke dukker noget op, er logniveauet den næste mistænkte. Access Server har en fejlsøgningskontakt til logdatabasen i /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), og tjenesten skal genstartes, efter at den er ændret. Behandl den kontakt som en diagnostisk indstilling, der skal skrues ned igen, når du har dit mønster, ikke som en permanent konfiguration.
Mens du er i filen, skal du lægge mærke til, hvilke flader der skriver i den. Fejl i klientportalen, i administrationsgrænsefladen og ved tunnelgodkendelse lander i samme fil med forskellige markører, og den detalje afgør senere jailenes layout.
Forankr ét filter på real_ip
Hold udtrykket snævert. Et filter, der gør krav på enhver linje med en IP-adresse, spærrer folk for almindelige afbrydelser, og på en travl server er det eneste symptom, at brugerne klager over at være låst ude, fordi de lukkede en laptop. Gør krav på fejlposten, og fang adressen i anførselstegn:
# /etc/fail2ban/filter.d/openvpnaccess.local
[Definition]
failregex = ^ .*LOG ERR.*"real_ip": "<HOST>".*
ignoreregex =Det forreste mellemrum er ikke kosmetik. Access Server rykker sine poster ind, og forankring på det forhindrer mønsteret i også at gøre krav på linjer, som urelaterede tjenester skriver i samme fil. Hvis dine poster i stedet har et tidsstempel forrest, skal du matche det præfiks, men forankr på noget, der virkelig findes i hver post, du vil gøre krav på.
Når du har brug for præcision pr. flade, skal du indsnævre yderligere ved at kræve flademarkøren (WEB_CLIENT, WEB_ADMIN eller VPN) på samme linje. Ét filter med tre mønstre er lettere at revidere end tre filtre, der adskiller sig med ét ord.
Test udtrykket, før du aktiverer en jail
Aktivér aldrig et filter, du ikke har kørt mod produktionsloggen. Den dokumenterede test sender filteret igennem to gange, én gang for at indlæse og én gang for at anvende, og rapporten over forbigåede linjer er den del, der er værd at læse:
fail2ban-regex --print-all-missed /var/log/openvpnas.log \
/etc/fail2ban/filter.d/openvpnaccess.local \
/etc/fail2ban/filter.d/openvpnaccess.local > missed.txtSammenlign antallet af match med de fejl, du bekræftede i første trin. Nul match betyder, at mønsteret er forkert; match på linjer, der ikke er godkendelsesfejl, betyder, at det er for bredt. Læs missed.txt, indtil du kan forklare hver linje, du valgte ikke at gøre krav på.
Lav denne test på en kopi, hvis loggen er stor, og kør den igen efter enhver opgradering af Access Server. Logformatet er den grænseflade, du matcher mod, og det er ikke en stabil API.
Del jails op efter flade, ikke efter daemon
Én Access Server præsenterer flere godkendelsesflader: klient- og adminwebgrænseflader på 943/tcp og tunnelen på 1194/udp eller 443/tcp i de fleste installationer. Én jail, der dækker dem alle, lader gætteforsøg på tunnelen spærre en adresse, der også er din adminvej, og den skjuler, hvilken flade der faktisk er under angreb. Giv hver flade sin egen jail med sin egen port og tærskler:
# /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 = 1hStart med små tællere og en kort spærring, og hæv dem, når du har set en uges rigtig trafik. En rundhåndet tærskel på en delt kontoradresse straffer hver bruger bag én NAT, og en aggressiv spærring på tunnelfladen afbryder legitime klienter, hvis gemte legitimationsoplysninger udløb natten over.
Kontroller spærringen, backenden og følgeskaderne
Efter en genstart er statusoutputtet den hurtigste bekræftelse på, at jailen findes og tæller:
fail2ban-client status
fail2ban-client status openvpnas-tunnelBekræft derefter, at spærringen når den firewall, du faktisk kører, for en jail, der er konfigureret til en backend, som ingen håndhæver, beskytter intet. Med iptables-handlingen vises adresserne i en kæde opkaldt efter jailen (f2b-openvpnas-tunnel); med nftables-handlingen lander de i et sæt i fail2bans egen tabel. Kontroller den, din vært bruger, i stedet for at gå ud fra det.
To følgekontroller betyder mere end selve spærringen. For det første skal du bekræfte, at real_ip er klientadressen og ikke en load balancer eller omvendt proxy; bag en proxy lander hver spærring på proxyen og trækker hele tjenesten med ned. For det andet skal du skrive proceduren for ophævelse ned, for den adresse, der krydser tærsklen kl. 02:00, tilhører normalt den vagthavende ingeniør: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.
Husk grænsen, mens du tuner. Fail2ban er en hastighedsbegrænser på én godkendelsesflade, ikke et adgangskontrollag. Det erstatter ikke MFA, begrænsninger pr. konto eller at holde administrationsgrænsefladen uden for det offentlige internet, og Access Server har sine egne autoban-indstillinger, som er værd at kontrollere, før du stabler to hastighedsbegrænsere på samme port.