Fail2ban na filter para sa OpenVPN Access Server: real_ip at jail

Kinopya mo ang isang OpenVPN jail mula sa post ng komunidad, ni-restart ang fail2ban, at walang address na nabablock. Ang dahilan ay halos palaging format ng log: hindi isinusulat ng Access Server ang mga linyang may nabigong authentication na inaasahan ng stock na filter. Bago hawakan ang filter, tiyakin na may mga record, dahil hindi maaaring tumugma ang pattern sa hindi kailanman naitala ng serbisyo.

Ito ang runbook na sinusunod ko sa isang host ng Access Server: tiyakin ang hugis ng record, magsulat ng isang naka-angkla na expression, subukan ito sa tunay na log, pagkatapos paghiwalayin ang jail ayon sa ibabaw na inaatake at tiyakin na umaabot ang block sa firewall.

Tiyakin na may record ng nabigo

Nagsusulat ang Access Server ng sarili nitong nakaayos na mga linya sa /var/log/openvpnas.log, at ang address ng kliyente ay nasa field na real_ip sa loob ng panipi, hindi sa simula ng linyang syslog. Maghanap ng nabigong pag-login na alam mong nangyari bago magsulat ng anumang pattern:

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

Kung walang lumabas, ang antas ng log ang susunod na pinaghihinalaan. May switch ng debug ng database ng log ang Access Server sa /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), at kailangang i-restart ang serbisyo pagkatapos itong baguhin. Ituring ang switch na iyon na diagnostic na setting na ibababa muli kapag may pattern ka na, hindi bilang permanenteng configuration.

Habang nasa file ka, pansinin kung aling mga ibabaw ang nagsusulat dito. Ang mga nabigo sa portal ng kliyente, sa admin interface at sa authentication ng tunnel ay napupunta sa parehong file na may iba't ibang marker, at ang detalyeng iyon ang magtatakda ng layout ng jail mamaya.

I-angkla ang isang filter sa real_ip

Panatilihing makitid ang expression. Ang filter na nag-aangkin ng bawat linyang may address na IP ay magbablok ng mga tao dahil sa ordinaryong pagkadiskonekta, at sa abalang server ang tanging sintomas ay nagrereklamo ang mga user na na-lock sila dahil nagsara ng laptop. Angkinin ang record ng error at hulihin ang address sa loob ng panipi:

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

Ang puwang sa simula ay hindi palamuti. Nag-uuri ng indent ang Access Server sa mga record nito, at ang pag-angkla doon ay pumipigil sa pattern na mag-angkla rin sa mga linyang isinusulat ng walang kaugnayang serbisyo sa parehong file. Kung ang mga record mo ay may timestamp sa simula sa halip, itugma ang prefix na iyon, ngunit i-angkla sa isang bagay na tunay na naroroon sa bawat record na balak mong angkinin.

Kapag kailangan mo ng katumpakan ayon sa ibabaw, paliitin pa sa pamamagitan ng paghingi ng marker ng ibabaw (WEB_CLIENT, WEB_ADMIN o VPN) sa parehong linya. Ang isang filter na may tatlong pattern ay mas madaling i-audit kaysa tatlong filter na nagkakaiba sa isang salita.

Subukan ang expression bago paganahin ang jail

Huwag kailanman paganahin ang filter na hindi mo pa pinatakbo laban sa production log. Ang dokumentadong pagsubok ay nagpapadaan sa filter ng dalawang beses, isang beses para i-load at isang beses para ilapat, at ang ulat ng mga nalaktawang linya ang bahaging sulit basahin:

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

Ihambing ang bilang ng tugma sa mga nabigong tiniyak mo sa unang hakbang. Ang zero na tugma ay nangangahulugang mali ang pattern; ang mga tugma sa linyang hindi nabigong authentication ay nangangahulugang masyado itong malawak. Basahin ang missed.txt hanggang maipaliwanag mo ang bawat linyang pinili mong hindi angkinin.

Gawin ang pagsubok na ito sa isang kopya kung malaki ang log, at ulitin ito pagkatapos ng anumang upgrade ng Access Server. Ang format ng log ang interface na tinutugma mo, at hindi ito stable na API.

Paghiwalayin ang jail ayon sa ibabaw, hindi ayon sa daemon

Ang isang Access Server ay naghahatid ng ilang ibabaw ng authentication: mga web interface ng kliyente at admin sa 943/tcp, at ang tunnel sa 1194/udp o 443/tcp sa karamihan ng deployment. Ang isang jail na sumasaklaw sa lahat ay nagpapahintulot sa mga pagtatangkang manghula sa tunnel na i-block ang isang address na daan mo rin sa admin, at itinatago kung aling ibabaw ang tunay na inaatake. Bigyan ang bawat ibabaw ng sarili nitong jail na may sariling port at threshold:

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

Magsimula sa maliliit na counter at maikling block, pagkatapos itaas ang mga ito kapag napagmasdan mo ang isang linggong tunay na trapiko. Ang mapagbigay na threshold sa isang pinagsasaluhang address ng opisina ay nagpaparusa sa bawat user sa likod ng isang NAT, at ang agresibong block sa ibabaw ng tunnel ay nagdidisconnect sa mga lehitimong kliyente na ang nakaimbak na kredensyal ay nag-expire magdamag.

Tiyakin ang block, ang backend at ang collateral na pinsala

Pagkatapos ng restart, ang output ng status ang pinakamabilis na kumpirmasyon na umiiral at nagbibilang ang jail:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Pagkatapos tiyakin na umaabot ang block sa firewall na tunay mong pinapatakbo, dahil ang jail na naka-configure para sa backend na walang nagpapatupad ay walang pinoprotektahan. Sa aksyong iptables lumilitaw ang mga address sa isang chain na pinangalanan sa jail (f2b-openvpnas-tunnel); sa aksyong nftables napupunta sila sa isang set sa sariling table ng fail2ban. Suriin ang ginagamit ng host mo sa halip na ipalagay.

Dalawang collateral na pagsusuri ang mas mahalaga kaysa sa block mismo. Una, tiyakin na ang real_ip ay address ng kliyente at hindi load balancer o reverse proxy; sa likod ng proxy bawat block ay bumagsak sa proxy at hinihila ang buong serbisyo. Ikalawa, isulat ang pamamaraan ng pag-unblock, dahil ang address na lumalampas sa threshold sa 02:00 ay karaniwang pag-aari ng engineer na naka-duty: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Tandaan ang hangganan habang nag-tutune. Ang Fail2ban ay isang rate limiter sa isang ibabaw ng authentication, hindi isang layer ng access control. Hindi nito pinapalitan ang MFA, mga paghihigpit sa bawat account o ang pag-iingat sa admin interface sa labas ng pampublikong internet, at may sariling autoban settings ang Access Server na sulit suriin bago magpatong ng dalawang rate limiter sa parehong port.