Fail2ban-szűrő az OpenVPN Access Serverhez: real_ip és jail-ek

Egy OpenVPN jail-t másoltál egy közösségi bejegyzésből, újraindítottad a fail2ban-t, és soha egyetlen cím sincs tiltva. Az ok szinte mindig a naplóformátum: az Access Server nem írja azokat a sikertelen hitelesítési sorokat, amelyeket egy kész szűrő vár. Mielőtt hozzányúlsz a szűrőhöz, erősítsd meg, hogy a rekordok egyáltalán léteznek, mert egy minta nem tud egyezni azzal, amit a szolgáltatás soha nem naplózott.

Ez az a runbook, amelyet Access Server-gazdagépen követek: erősítsd meg a rekord alakját, írj egy horgonyzott kifejezést, teszteld a valódi naplón, majd bontsd fel a jail-eket a támadott felület szerint, és ellenőrizd, hogy a tiltás eléri a tűzfalat.

Erősítsd meg, hogy létezik a hiba rekordja

Az Access Server a saját strukturált sorait a /var/log/openvpnas.log fájlba írja, és az ügyfél címe egy idézőjelek közötti real_ip mezőben van, nem egy syslog-sor elején. Keress olyan sikertelen bejelentkezést, amelyről tudod, hogy megtörtént, mielőtt bármilyen mintát írnál:

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

Ha semmi nem jelenik meg, a következő gyanúsított a naplózási szint. Az Access Servernek van egy naplóadatbázis-hibakereső kapcsolója a /usr/local/openvpn_as/etc/as.conf fájlban (DEBUG_LOGDB=1), és a szolgáltatást a módosítás után újra kell indítani. Ezt a kapcsolót diagnosztikai beállításként kezeld, amelyet vissza kell venni, amint megvan a mintád, nem állandó konfigurációként.

Amíg a fájlban vagy, jegyezd meg, mely felületek írnak bele. Az ügyfélportál, a felügyeleti felület és az alagút hitelesítésének hibái ugyanabba a fájlba kerülnek, de különböző markerekkel, és ez a részlet később meghatározza a jail-ek elrendezését.

Horgonyozz egy szűrőt a real_ip mezőn

Tartsd szűken a kifejezést. Egy szűrő, amely minden IP-címet tartalmazó sort magáénak követel, embereket tilt ki hétköznapi kapcsolatbontások miatt, és egy forgalmas szerveren az egyetlen tünet az, hogy a felhasználók panaszkodnak, hogy kizárták őket, mert bezártak egy laptopot. Követeld a hiba rekordját, és fogd meg az idézőjelek közötti címet:

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

A vezető szóköz nem kozmetika. Az Access Server behúzza a rekordjait, és az erre való horgonyzás megakadályozza, hogy a minta olyan sorokat is magáénak követeljen, amelyeket nem kapcsolódó szolgáltatások írnak ugyanabba a fájlba. Ha a rekordjaid elején inkább időbélyeg van, ahhoz az előtaghoz illeszkedj, de olyasmire horgonyozz, ami valóban jelen van minden rekordban, amelyet magáénak akarsz követelni.

Amikor felületenkénti pontosságra van szükséged, szűkíts tovább azzal, hogy ugyanabban a sorban megköveteled a felület markert (WEB_CLIENT, WEB_ADMIN vagy VPN). Egy három mintás szűrőt könnyebb auditálni, mint három szűrőt, amelyek egy szóban különböznek.

Teszteld a kifejezést, mielőtt engedélyezed a jail-t

Soha ne engedélyezz olyan szűrőt, amelyet nem futtattál a termelési naplón. A dokumentált teszt kétszer adja át a szűrőt, egyszer betöltésre, egyszer alkalmazásra, és a kihagyott sorok jelentése az a rész, amelyet érdemes elolvasni:

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

Hasonlítsd össze a találatok számát az első lépésben ellenőrzött hibákkal. Nulla találat azt jelenti, hogy a minta rossz; a nem hitelesítési hibát jelentő sorokon lévő találatok azt, hogy túl széles. Olvasd a missed.txt fájlt, amíg minden olyan sort meg tudsz magyarázni, amelyet úgy döntöttél, hogy nem követelsz.

Nagy napló esetén másolaton végezd ezt a tesztet, és ismételd meg minden Access Server-frissítés után. A naplóformátum az a felület, amelyhez illeszkedsz, és ez nem stabil API.

Felület szerint bontsd fel a jail-eket, ne daemon szerint

Egy Access Server több hitelesítési felületet kínál: ügyfél- és felügyeleti webes felületet a 943/tcp porton, és az alagutat 1194/udp vagy 443/tcp porton a legtöbb telepítésben. Egyetlen jail mindegyiket lefedve lehetővé teszi, hogy az alagúton próbálkozó találgatások olyan címet tiltsanak, amely a felügyeleti útvonalad is, és elrejti, melyik felület van valójában támadás alatt. Adj minden felületnek saját jail-t a saját portjával és küszöbeivel:

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

Kezdd kis számlálókkal és rövid tiltással, és emeld meg őket, miután egy hét valódi forgalmat megfigyeltél. Egy megosztott irodai címre tett bőkezű küszöb minden felhasználót büntet egy NAT mögött, az alagút felületén pedig az agresszív tiltás azokat a legitim ügyfeleket kapcsolja le, akiknek a tárolt hitelesítő adatai éjszaka lejártak.

Ellenőrizd a tiltást, a backendet és a járulékos károkat

Újraindítás után a státuszkimenet a leggyorsabb megerősítés arra, hogy a jail létezik és számol:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Ezután erősítsd meg, hogy a tiltás eléri azt a tűzfalat, amelyet valóban futtatsz, mert egy olyan backendhez beállított jail, amelyet senki nem kényszerít ki, semmit nem véd. Az iptables művelettel a címek a jailről elnevezett láncban jelennek meg (f2b-openvpnas-tunnel); az nftables művelettel a fail2ban saját táblájában lévő halmazba kerülnek. Azt ellenőrizd, amelyet a gazdagéped használ, ne feltételezd.

Két járulékos ellenőrzés fontosabb magánál a tiltásnál. Először is erősítsd meg, hogy a real_ip az ügyfél címe, és nem terheléselosztó vagy fordított proxy; proxy mögött minden tiltás a proxyra esik, és magával rántja az egész szolgáltatást. Másodszor írd le a tiltás feloldásának eljárását, mert a 02:00-kor a küszöböt átlépő cím általában az ügyeletes mérnöké: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Tartsd szem előtt a határt a hangolás közben. A Fail2ban egyetlen hitelesítési felület sebességkorlátozója, nem hozzáférés-vezérlési réteg. Nem helyettesíti az MFA-t, a fiókonkénti korlátozásokat vagy a felügyeleti felület nyilvános internettől való távoltartását, és az Access Servernek saját autoban-beállításai vannak, amelyeket érdemes ellenőrizni, mielőtt két sebességkorlátozót pakolnál ugyanarra a portra.