Fail2ban-suodatin OpenVPN Access Serverille: real_ip ja jailit

Kopioit OpenVPN jailin yhteisön julkaisusta, käynnistit fail2banin uudelleen, eikä yhtään osoitetta koskaan estetä. Syy on lähes aina lokiformaatti: Access Server ei kirjoita niitä todennuksen epäonnistumisrivejä, joita vakiosuodatin odottaa. Ennen kuin kosket suodattimeen, varmista että tietueet ylipäätään ovat olemassa, sillä kuvio ei voi osua siihen, mitä palvelu ei koskaan kirjannut.

Tämä on runbook, jota noudatan Access Server -isännällä: vahvista tietueen muoto, kirjoita yksi ankkuroitu lauseke, testaa se oikeaa lokia vastaan, jaa sitten jailit hyökätyn pinnan mukaan ja varmista, että esto saavuttaa palomuurin.

Vahvista, että virhetietue on olemassa

Access Server kirjoittaa omat rakenteiset rivinsä tiedostoon /var/log/openvpnas.log, ja asiakkaan osoite on lainausmerkeissä olevassa kentässä real_ip, ei syslog-rivin alussa. Etsi epäonnistunut kirjautuminen, jonka tiedät tapahtuneen, ennen kuin kirjoitat mitään kuviota:

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

Jos mitään ei ilmesty, seuraava epäilty on lokitaso. Access Serverissä on lokitietokannan virheenjäljityskytkin tiedostossa /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), ja palvelu on käynnistettävä uudelleen sen muuttamisen jälkeen. Kohtele kytkintä diagnostiikka-asetuksena, joka lasketaan takaisin alas, kun kuviosi on valmis, ei pysyvänä konfiguraationa.

Kun olet tiedostossa, pane merkille, mitkä pinnat kirjoittavat siihen. Asiakasportaalin, hallintaliittymän ja tunnelin todennuksen virheet päätyvät samaan tiedostoon eri merkinnöillä, ja tämä yksityiskohta ratkaisee myöhemmin jailien asettelun.

Ankkuroi yksi suodatin real_ip-kenttään

Pidä lauseke kapeana. Suodatin, joka varaa jokaisen IP-osoitteen sisältävän rivin, estää ihmisiä tavallisista katkoksista, ja vilkkaalla palvelimella ainoa oire on käyttäjien valitus siitä, että heidät lukittiin ulos kannettavan sulkemisen takia. Varaa virhetietue ja kaappaa osoite lainausmerkeistä:

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

Alkutyhjä ei ole kosmeettinen. Access Server sisentää tietueensa, ja siihen ankkurointi estää kuviota varaamasta myös rivejä, joita samaan tiedostoon kirjoittavat asiaankuulumattomat palvelut. Jos tietueissasi on sen sijaan alussa aikaleima, sovita se etuliite, mutta ankkuroi johonkin, joka on todella läsnä jokaisessa tietueessa, jonka aiot varata.

Kun tarvitset tarkkuutta pinnan mukaan, kavenna edelleen vaatimalla pinnan merkintä (WEB_CLIENT, WEB_ADMIN tai VPN) samalla rivillä. Yksi suodatin, jossa on kolme kuviota, on helpompi auditoida kuin kolme suodatinta, jotka eroavat yhdellä sanalla.

Testaa lauseke ennen jailin käyttöönottoa

Älä koskaan ota käyttöön suodatinta, jota et ole ajanut tuotantolokia vastaan. Dokumentoitu testi antaa suodattimen läpi kahdesti, kerran lataamiseen ja kerran soveltamiseen, ja ohitettujen rivien raportti on se osa, joka kannattaa lukea:

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

Vertaa osumien määrää niihin virheisiin, jotka vahvistit ensimmäisessä vaiheessa. Nolla osumaa tarkoittaa, että kuvio on väärä; osumat riveillä, jotka eivät ole todennuksen virheitä, tarkoittavat, että se on liian leveä. Lue missed.txt, kunnes pystyt selittämään jokaisen rivin, jonka päätit jättää varaamatta.

Tee tämä testi kopiolle, jos loki on suuri, ja toista se jokaisen Access Server -päivityksen jälkeen. Lokiformaatti on rajapinta, jota vastaan sovitat, eikä se ole vakaa API.

Jaa jailit pinnan mukaan, ei daemonin

Yksi Access Server tarjoaa useita todennuspintoja: asiakas- ja hallintoverkkoliittymät portissa 943/tcp ja tunneli portissa 1194/udp tai 443/tcp useimmissa käyttöönotoissa. Yksi kaikki kattava jail sallii tunnelin arvausyritysten estää osoitteen, joka on myös hallintapolkusi, ja se kätkee, mikä pinta on todella hyökkäyksen kohteena. Anna jokaiselle pinnalle oma jail omalla portillaan ja kynnyksillään:

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

Aloita pienillä laskureilla ja lyhyellä estolla ja nosta niitä, kun olet seurannut viikon todellista liikennettä. Runsaskätinen kynnys jaetussa toimisto-osoitteessa rankaisee jokaista käyttäjää yhden NATin takana, ja aggressiivinen esto tunnelin pinnalla katkaisee laillisten asiakkaiden yhteydet, joiden tallennetut tunnistetiedot vanhentuivat yön aikana.

Vahvista esto, backend ja sivuvaikutukset

Uudelleenkäynnistyksen jälkeen tilarivi on nopein vahvistus siitä, että jail on olemassa ja laskee:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Vahvista sitten, että esto saavuttaa palomuurin, jota todella ajat, sillä jail, joka on määritetty backendille, jota kukaan ei pane täytäntöön, ei suojaa mitään. iptables-toiminnolla osoitteet ilmestyvät jailin mukaan nimettyyn ketjuun (f2b-openvpnas-tunnel); nftables-toiminnolla ne päätyvät fail2banin omaan tauluun kuuluvaan joukkoon. Tarkista se, jota isäntäsi käyttää, sen sijaan että olettaisit.

Kaksi sivuvaikutusten tarkistusta on tärkeämpiä kuin itse esto. Ensinnäkin varmista, että real_ip on asiakkaan osoite eikä kuormantasaaja tai käänteinen välityspalvelin; välityspalvelimen takana jokainen esto osuu välityspalvelimeen ja vetää koko palvelun mukanaan. Toiseksi kirjoita eston purkuohje ylös, sillä osoite, joka ylittää kynnyksen kello 02:00, kuuluu yleensä päivystävälle insinöörille: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Pidä raja mielessä säätäessäsi. Fail2ban on nopeudenrajoitin yhdellä todennuspinnalla, ei käytönvalvontakerros. Se ei korvaa MFA:ta, tileittäisiä rajoituksia tai hallintaliittymän pitämistä poissa julkisesta internetistä, ja Access Serverillä on omat autoban-asetuksensa, jotka kannattaa tarkistaa ennen kuin pinoat kaksi nopeudenrajoitinta samaan porttiin.