Fail2ban filtras OpenVPN Access Server: real_ip ir jail

Access Server rašo savo žurnalo formatą, todėl standartiniai filtrai nieko neranda. Užsifiksuokite ties real_ip, skirstykite jail pagal paviršių ir patikrinkite, ar adresas nėra tarpinė.

Jūs nukopijavote OpenVPN jail iš bendruomenės įrašo, paleidote fail2ban iš naujo, ir nė vienas adresas niekada neblokuojamas. Priežastis beveik visada yra žurnalo formatas: Access Server nerašo tų autentifikacijos nesėkmės eilučių, kurių tikisi standartinis filtras. Prieš liesdami filtrą, patikrinkite, ar įrašai apskritai yra, nes šablonas negali sutapti su tuo, ko paslauga niekada neužregistravo.

Tai procedūra, kurios laikausi Access Server hoste: patvirtinti įrašo formą, parašyti vieną užfiksuotą išraišką, išbandyti ją tikrame žurnale, tada suskirstyti jail pagal atakuojamą paviršių ir patikrinti, ar blokavimas pasiekia ugniasienę.

Patvirtinkite, kad nesėkmės įrašas egzistuoja

Access Server savo struktūruotas eilutes rašo į /var/log/openvpnas.log, o kliento adresas yra lauke real_ip kabutėse, o ne syslog eilutės pradžioje. Prieš rašydami bet kokį šabloną, suraskite nepavykusį prisijungimą, apie kurį žinote, kad jis įvyko:

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

Jei nieko nepasimato, kitas įtariamasis yra žurnalo lygis. Access Server turi žurnalo duomenų bazės derinimo jungiklį /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), ir paslaugą reikia paleisti iš naujo ją pakeitus. Laikykite tą jungiklį diagnostiniu nustatymu, kurį reikia vėl sumažinti, kai turėsite savo šabloną, o ne nuolatine konfigūracija.

Kol esate faile, atkreipkite dėmesį, kurie paviršiai į jį rašo. Kliento portalo, administravimo sąsajos ir tunelio autentifikacijos nesėkmės patenka į tą patį failą su skirtingais žymekliais, ir ši detalė vėliau nulemia jail išdėstymą.

Užfiksuokite vieną filtrą ties real_ip

Laikykite išraišką siaurą. Filtras, kuris pasisavina kiekvieną eilutę su IP adresu, blokuos žmones dėl įprastų atsijungimų, o užimtame serveryje vienintelis simptomas yra vartotojų skundai, kad juos užblokavo už nešiojamojo kompiuterio uždarymą. Pasisavinkite klaidos įrašą ir užfiksuokite adresą kabutėse:

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

Pradinis tarpas nėra kosmetika. Access Server įtraukia savo įrašus, o užsifiksavimas ties tuo neleidžia šablonui pasisavinti ir eilučių, kurias į tą patį failą rašo nesusijusios paslaugos. Jei jūsų įrašai vietoj to pradžioje turi laiko žymą, derinkite tą priešdėlį, bet užsifiksuokite ties tuo, kas tikrai yra kiekviename įraše, kurį ketinate pasisavinti.

Kai reikia tikslumo pagal paviršių, susiaurinkite dar labiau reikalaudami paviršiaus žymeklio (WEB_CLIENT, WEB_ADMIN arba VPN) toje pačioje eilutėje. Vieną filtrą su trimis šablonais lengviau audituoti nei tris filtrus, kurie skiriasi vienu žodžiu.

Išbandykite išraišką prieš įjungdami jail

Niekada neįjunkite filtro, kurio nepaleidote prieš produkcinį žurnalą. Dokumentuotas testas perduoda filtrą du kartus, vieną kartą įkėlimui ir vieną kartą taikymui, o praleistų eilučių ataskaita yra ta dalis, kurią verta perskaityti:

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

Palyginkite atitikimų skaičių su nesėkmėmis, kurias patvirtinote pirmame žingsnyje. Nulis atitikimų reiškia, kad šablonas neteisingas; atitikimai eilutėse, kurios nėra autentifikacijos nesėkmės, reiškia, kad jis per platus. Skaitykite missed.txt, kol galėsite paaiškinti kiekvieną eilutę, kurios nusprendėte nepasisavinti.

Atlikite šį testą su kopija, jei žurnalas didelis, ir pakartokite jį po kiekvieno Access Server atnaujinimo. Žurnalo formatas yra sąsaja, su kuria derinate, ir tai nėra stabili API.

Skirstykite jail pagal paviršių, o ne pagal tarnybą

Vienas Access Server teikia kelis autentifikacijos paviršius: kliento ir administravimo žiniatinklio sąsajas 943/tcp prievade, o tunelį 1194/udp arba 443/tcp prievade daugumoje diegimų. Vienas jail, apimantis juos visus, leidžia spėjimo bandymams tunelyje blokuoti adresą, kuris taip pat yra jūsų administravimo kelias, ir paslepia, kuris paviršius iš tikrųjų atakuojamas. Suteikite kiekvienam paviršiui atskirą jail su savo prievadu ir slenksčiais:

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

Pradėkite nuo mažų skaitiklių ir trumpo blokavimo, o pakelkite juos, kai stebėsite savaitę realaus srauto. Dosnus slenkstis bendrame biuro adrese baudžia kiekvieną vartotoją už vieno NAT, o agresyvus blokavimas tunelio paviršiuje atjungia teisėtus klientus, kurių saugomi prisijungimo duomenys per naktį baigėsi.

Patikrinkite blokavimą, backend ir šalutinę žalą

Po paleidimo iš naujo būsenos išvestis yra greičiausias patvirtinimas, kad jail egzistuoja ir skaičiuoja:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Tada patikrinkite, ar blokavimas pasiekia ugniasienę, kurią iš tikrųjų valdote, nes jail, sukonfigūruotas backend, kurio niekas nevykdo, nieko neapsaugo. Su iptables veiksmu adresai atsiranda grandinėje, pavadintoje jail vardu (f2b-openvpnas-tunnel); su nftables veiksmu jie patenka į rinkinį fail2ban nuosavoje lentelėje. Tikrinkite tą, kurią naudoja jūsų hostas, o ne darykite prielaidų.

Du šalutiniai patikrinimai svarbesni už patį blokavimą. Pirma, patikrinkite, ar real_ip yra kliento adresas, o ne apkrovos balansuotojas ar atvirkštinė tarpinė; už tarpinės kiekvienas blokavimas krenta ant tarpinės ir nusitempia visą paslaugą. Antra, užrašykite atblokavimo procedūrą, nes adresas, kuris 02:00 viršija slenkstį, paprastai priklauso budinčiam inžinieriui: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Reguliuodami atminkite ribą. Fail2ban yra greičio ribotuvas viename autentifikacijos paviršiuje, o ne prieigos valdymo sluoksnis. Jis nepakeičia MFA, apribojimų pagal paskyrą ar administravimo sąsajos laikymo už viešojo interneto ribų, o Access Server turi savo autoban nustatymus, kuriuos verta patikrinti prieš sukraunant du greičio ribotuvus tame pačiame prievade.

Susiję straipsniai