Fail2ban iragazkia OpenVPN Access Serverrerako: real_ip eta ziega

Access Serverrek bere log formatua idazten du, beraz iragazki estandarrek ez dute ezer aurkitzen. Egon real_ip-en ainguratuta, banatu ziega gainazalaren arabera eta egiaztatu helbidea ez dela proxy bat.

Komunitateko mezu batetik OpenVPN ziega bat kopiatu zenuen, fail2ban berrabiarazi zenuen eta inoiz ez da helbiderik blokeatzen. Arrazoia ia beti log formatua da: Access Serverrek ez ditu iragazki estandar batek espero dituen autentifikazio-hutsegiteen lerroak idazten. Iragazkia ukitu aurretik, egiaztatu erregistroak badirela behintzat, patroi batek ezin baitu zerbitzuak inoiz erregistratu ez zuenarekin bat egin.

Hona hemen Access Server ostalari batean jarraitzen dudan runbook-a: erregistroaren forma baieztatu, adierazpen ainguratu bat idatzi, benetako logaren aurka probatu, gero ziega gainazal erasotuaren arabera banatu eta blokeoak suebakira iristen dela egiaztatu.

Baieztatu hutsegite-erregistroa badagoela

Access Serverrek bere lerro egituratuak /var/log/openvpnas.log fitxategira idazten ditu, eta bezeroaren helbidea komatxoz inguratutako real_ip eremuan dago, ez syslog lerro baten hasieran. Bilatu gertatu zela dakizun saio-hasiera huts bat edozein patroi idatzi aurretik:

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

Ezer agertzen ez bada, log-maila da hurrengo susmagarria. Access Serverrek log-datu-basearen arazketa-etengailu bat du /usr/local/openvpn_as/etc/as.conf fitxategian (DEBUG_LOGDB=1), eta zerbitzua berrabiarazi behar da hura aldatu ondoren. Etengailu hori diagnostiko-ezarpen gisa hartu behar duzu, patroia lortu ondoren berriro jaitsiko dena, ez konfigurazio iraunkor gisa.

Fitxategian zauden bitartean, erreparatu zein gainazalek idazten duten bertan. Bezeroaren atariko hutsegiteak, administrazio-interfazekoak eta tuneleko autentifikaziokoak fitxategi berera iristen dira markatzaile ezberdinekin, eta xehetasun horrek erabakitzen du geroago ziegen diseinua.

Ainguratu iragazki bat real_ip-en

Eduki adierazpena estu. IP helbidea duen edozein lerro erreklamatzen duen iragazki batek jendea blokeatuko du deskonexio arruntengatik, eta zerbitzari lanpetu batean sintoma bakarra da erabiltzaileak kexatzea ordenagailu eramangarri bat itxi zutelako blokeatu zituztela. Erreklamatu errore-erregistroa eta harrapatu komatxoen arteko helbidea:

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

Hasierako zuriunea ez da kosmetikoa. Access Serverrek bere erregistroak kosk egiten ditu, eta horretan ainguratzeak eragozten dio patroiari fitxategi berera idazten duten zerbitzu erlazionatugabeen lerroak ere erreklamatzea. Zure erregistroek aurretik denbora-marka bat badute, lotu aurrizki hori, baina ainguratu erreklamatu nahi duzun erregistro bakoitzean benetan dagoen zerbaitetan.

Gainazal bakoitzeko zehaztasuna behar duzunean, estuago egin gainazal-markatzailea (WEB_CLIENT, WEB_ADMIN edo VPN) lerro berean eskatuz. Hiru patroiko iragazki bat errazago ikuskatzen da hitz batean desberdintzen diren hiru iragazki baino.

Probatu adierazpena ziega bat gaitzen hasi aurretik

Ez gaitu inoiz ekoizpen-logaren aurka exekutatu ez duzun iragazkirik. Dokumentatutako probak bi aldiz pasatzen du iragazkia, behin kargatzeko eta behin aplikatzeko, eta galdu diren lerroen txostena da irakurtzea merezi duen zatia:

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

Konparatu bat-etortze kopurua lehen urratsean egiaztatu zenituen hutsegiteekin. Zero bat-etortze esan nahi du patroia okerra dela; autentifikazio-hutsegiteak ez diren lerroetan bat-etortzeak esan nahi du zabalegia dela. Irakurri missed.txt erreklamatzeari uko egin zenion lerro bakoitza azaldu ahal izan arte.

Egin proba hau kopia baten gainean loga handia bada, eta errepikatu Access Serverren edozein eguneraketen ondoren. Log formatua bat etortzen ari zaren interfazea da, eta ez da API egonkorra.

Banatu ziega gainazalaren arabera, ez daemonaren arabera

Access Server batek hainbat autentifikazio-gainazal aurkezten ditu: bezeroaren eta administrazioaren web-interfazeak 943/tcp-n, eta tunela 1194/udp edo 443/tcp-n hedapen gehienetan. Guztiak estaltzen dituen ziega bakarra larrutu egiten du tunelean asmatzeko saiakerak zure administrazio-bidea ere baden helbide bat blokeatzea, eta ezkutatzen du zein gainazal dagoen benetan erasopean. Eman ziega propioa gainazal bakoitzari, bere portu eta atalaseekin:

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

Hasi kontagailu txikiekin eta blokeo labur batekin, eta igo itzazu astebeteko trafiko erreala behatu ondoren. Bulego-helbide partekatu batean atalase oparoa NAT baten atzeko erabiltzaile guztiak zigortzen ditu, eta tuneleko gainazalean blokeo oldarkorrak gauez iraungi ziren gordetako kredentzialak dituzten bezero legitimoak deskonektatzen ditu.

Egiaztatu blokeoa, backend-a eta kalte kolaterala

Berrabiarazi ondoren, egoera-irteera da ziega existitzen dela eta zenbatzen ari dela baieztatzeko modurik azkarrena:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Gero egiaztatu blokeoa benetan exekutatzen duzun suebakira iristen dela, inork aplikatzen ez duen backend baterako konfiguratutako ziega batek ez baitu ezer babesten. iptables ekintzarekin helbideak ziegaren izena duen kate batean agertzen dira (f2b-openvpnas-tunnel); nftables ekintzarekin fail2ban-en taula propioan multzo batean erortzen dira. Egiaztatu zure ostalariak erabiltzen duena suposatu beharrean.

Bi egiaztapen kolateral blokeoa bera baino garrantzitsuagoak dira. Lehenik, egiaztatu real_ip bezeroaren helbidea dela eta ez karga-balantzatzaile edo alderantzizko proxy bat; proxy baten atzean blokeo bakoitza proxyaren gainean erortzen da eta zerbitzu osoa eramatzen du. Bigarrenik, idatzi desblokeatzeko prozedura, 02:00etan atalasea gainditzen duen helbidea guardiako ingeniariarena izaten baita normalean: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Eduki muga gogoan doikuntza egiten duzun bitartean. Fail2ban autentifikazio-gainazal bateko abiadura-mugatzailea da, ez sarbide-kontrol geruza. Ez du MFA ordezkatzen, ez kontu bakoitzeko murrizketak, ez administrazio-interfazea internet publikotik kanpo edukitzea, eta Access Serverrek bere autoban ezarpenak ditu, merezi duenak berrikustea ataka berean bi abiadura-mugatzaile pilatu aurretik.

Erlazionatutako artikuluak