Fail2bani filter OpenVPN Access Serveri jaoks: real_ip ja jailid

Sa kopeerisid OpenVPN jaili kogukonna postitusest, taaskäivitasid fail2bani ja ükski aadress ei blokeerita kunagi. Põhjus on peaaegu alati logivorming: Access Server ei kirjuta autentimise ebaõnnestumise ridu, mida standardfilter ootab. Enne kui filtrit puutud, veendu, et kirjed üldse olemas on, sest muster ei saa sobituda millegagi, mida teenus kunagi ei logi.

See on runbook, mida ma Access Serveri hostis järgin: kinnita kirje kuju, kirjuta üks ankurdatud avaldis, testi seda päris logi vastu, seejärel jaga jailid rünnatava pinna järgi ja kontrolli, et blokeering jõuab tulemüüri.

Kinnita, et veakirje on olemas

Access Server kirjutab oma struktureeritud read faili /var/log/openvpnas.log ja kliendi aadress asub jutumärkides väljal real_ip, mitte syslogi rea alguses. Otsi ebaõnnestunud sisselogimist, mis sinu teada toimus, enne kui kirjutad ükskõik millise mustri:

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

Kui midagi ei ilmu, on järgmine kahtlane logitase. Access Serveril on logiandmebaasi silumislüliti failis /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), ja teenus tuleb pärast selle muutmist taaskäivitada. Käsitle seda lülitit diagnostikaseadena, mis keeratakse uuesti maha, kui muster käes, mitte püsiva konfiguratsioonina.

Kui oled failis, pane tähele, millised pinnad sinna kirjutavad. Kliendiportaali, haldusliidese ja tunneliautentimise vead maanduvad samasse faili, kuid erinevate markeritega, ja see detail määrab hiljem jailide paigutuse.

Ankru üks filter real_ip peale

Hoia avaldis kitsas. Filter, mis nõuab iga IP-aadressi sisaldavat rida, blokeerib inimesi tavaliste ühenduse katkemiste eest, ja koormatud serveris on ainus sümptom, et kasutajad kurdavad, et nad lukustati välja sülearvuti sulgemise tõttu. Nõua veakirjet ja püüa aadress jutumärkides:

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

Algnev tühik ei ole kosmeetika. Access Server taandab oma kirjed ja sellele ankurdamine takistab mustril nõuda ka ridu, mida samasse faili kirjutavad mitteseotud teenused. Kui sinu kirjetel on hoopis alguses ajatempel, sobita seda prefiksit, kuid ankru millegi peale, mis on tõesti olemas igas kirjes, mida kavatsed nõuda.

Kui vajad täpsust pinna kaupa, kitsenda veelgi, nõudes pinna markerit (WEB_CLIENT, WEB_ADMIN või VPN) samal real. Ühte kolme mustriga filtrit on lihtsam auditeerida kui kolme filtrit, mis erinevad ühe sõna võrra.

Testi avaldist enne jaili lubamist

Ära kunagi luba filtrit, mida sa ei ole tootmislogi vastu käivitanud. Dokumenteeritud test annab filtri kaks korda läbi, üks kord laadimiseks ja üks kord rakendamiseks, ja vahelejäänud ridade aruanne on see osa, mida tasub lugeda:

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

Võrdle vastete arvu nende ebaõnnestumistega, mille sa esimeses sammus kinnitasid. Null vastet tähendab, et muster on vale; vasted ridadel, mis ei ole autentimise ebaõnnestumised, tähendavad, et see on liiga lai. Loe missed.txt, kuni suudad selgitada iga rida, mille otsustasid mitte nõuda.

Tee seda testi koopial, kui logi on suur, ja korda seda pärast iga Access Serveri uuendust. Logivorming on liides, mille vastu sa sobitad, ja see ei ole stabiilne API.

Jaga jailid pinna, mitte deemonite järgi

Üks Access Server pakub mitut autentimispinda: kliendi- ja haldusveebiliidesed pordil 943/tcp ning tunnel pordil 1194/udp või 443/tcp enamikus paigaldustes. Üks kõiki kattev jail lubab tunnelil oletamiskatsetel blokeerida aadressi, mis on ka sinu haldustee, ja varjab, milline pind tegelikult rünnaku all on. Anna igale pinnale oma jail oma pordi ja lävenditega:

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

Alusta väikeste loenduritega ja lühikese blokeeringuga, seejärel tõsta neid, kui oled nädala päris liiklust jälginud. Suuremeelne lävend jagatud kontoriaadressil karistab iga kasutajat ühe NAT-i taga, ja agressiivne blokeering tunneli pinnal katkestab legitiimsed kliendid, kelle salvestatud volitused öö jooksul aegusid.

Kontrolli blokeeringut, backend'i ja kõrvalkahju

Pärast taaskäivitust on olekuväljund kiireim kinnitus, et jail on olemas ja loeb:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Seejärel kinnita, et blokeering jõuab tulemüüri, mida sa tegelikult jooksutad, sest backendile konfigureeritud jail, mida keegi ei rakenda, ei kaitse midagi. iptables'i tegevusega ilmuvad aadressid jaili järgi nimetatud ahelasse (f2b-openvpnas-tunnel); nftables'i tegevusega maanduvad need fail2bani enda tabelis olevasse hulka. Kontrolli seda, mida sinu host kasutab, selle asemel et eeldada.

Kaks kõrvakontrolli on tähtsamad kui blokeering ise. Esiteks kontrolli, et real_ip on kliendi aadress, mitte koormusjaotur või pöördpuhverserver; puhverserveri taga maandub iga blokeering puhverserverile ja tõmbab kogu teenuse endaga kaasa. Teiseks kirjuta üles blokeeringu tühistamise protseduur, sest aadress, mis ületab lävendi kell 02:00, kuulub tavaliselt valves olevale insenerile: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Pea piiri meeles häälestamise ajal. Fail2ban on kiirusepiiraja ühel autentimispinnal, mitte juurdepääsukontrolli kiht. See ei asenda MFA-d, kontopõhiseid piiranguid ega haldusliidese avalikust internetist eemal hoidmist, ja Access Serveril on oma autoban-seaded, mida tasub kontrollida enne, kui virnad samale pordile kaks kiirusepiirajat.