Si funksionon Fail2Ban për të mbrojtur shërbimet në një server Linux
Prezantimi
SSH është metoda de fakto e lidhjes me një server cloud. Është i qëndrueshëm dhe është i zgjerueshëm – ndërsa zhvillohen standarde të reja të kriptimit, ato mund të përdoren për të gjeneruar çelësa të rinj SSH, duke siguruar që protokolli bazë të mbetet i sigurt. Megjithatë, asnjë protokoll ose grumbull softuerësh nuk është plotësisht i pagabueshëm dhe SSH duke qenë kaq i përhapur në internet do të thotë se ai përfaqëson një sipërfaqe sulmi ose vektor sulmi shumë të parashikueshëm nëpërmjet të cilit njerëzit mund të përpiquni të fitoni akses.
Çdo shërbim që është i ekspozuar ndaj rrjetit është një objektiv i mundshëm në këtë mënyrë. Nëse rishikoni regjistrat për shërbimin tuaj SSH që funksionon në çdo server të trafikuar gjerësisht, shpesh do të shihni përpjekje të përsëritura, sistematike për hyrje që përfaqësojnë sulme me forcë brutale nga përdoruesit dhe robotët njësoj. Edhe pse mund të bëni disa optimizime në shërbimin tuaj SSH për të ulur mundësinë e këtyre sulmeve të kenë sukses në afërsisht zero, të tilla si çaktivizimi i vërtetimit të fjalëkalimit në favor të çelësave SSH, ato ende mund të përbëjnë një përgjegjësi të vogël dhe të vazhdueshme.
Vendosjet e prodhimit në shkallë të gjerë për të cilët ky detyrim është plotësisht i papranueshëm zakonisht do të zbatojnë një VPN si WireGuard përpara shërbimit të tyre SSH, në mënyrë që të jetë e pamundur të lidheni drejtpërdrejt me portin e paracaktuar SSH 22 nga interneti i jashtëm pa abstraksion softueri shtesë ose portat hyrëse. Këto zgjidhje VPN janë gjerësisht të besueshme, por do të shtojnë kompleksitet dhe mund të thyejnë disa automatizime ose grepa të tjera të vogla softuerësh.
Përpara ose përveç angazhimit për një konfigurim të plotë VPN, mund të zbatoni një mjet të quajtur Fail2ban. Fail2ban mund të zbusë ndjeshëm sulmet e forcës brutale duke krijuar rregulla që ndryshojnë automatikisht konfigurimin e murit të zjarrit për të ndaluar IP-të specifike pas një numri të caktuar përpjekjesh të pasuksesshme për hyrje. Kjo do të lejojë serverin tuaj të forcohet kundër këtyre përpjekjeve për akses pa ndërhyrjen tuaj.
Në një tutorial tjetër, ne diskutuam Si të mbroni SSH me Fail2ban. Në këtë udhëzues, ne do të diskutojmë më në thellësi se si funksionon në të vërtetë Fail2ban dhe si mund ta përdorni këtë njohuri për të modifikuar ose zgjeruar sjelljen e këtij shërbimi.
Bazat e Fail2ban
Qëllimi i Fail2ban është të monitorojë regjistrat e shërbimeve të zakonshme për të dalluar modelet në dështimet e vërtetimit.
Kur fail2ban konfigurohet për të monitoruar regjistrat e një shërbimi, ai shikon një filtër që është konfiguruar specifik për atë shërbim. Filtri është krijuar për të identifikuar dështimet e vërtetimit për atë shërbim specifik përmes përdorimit të shprehjeve komplekse të rregullta. Shprehjet e rregullta janë një gjuhë e zakonshme modelimi që përdoret për përputhjen e modeleve. Ai përcakton këto modele të shprehjeve të rregullta në një variabël të brendshëm të quajtur failregex
.
Si parazgjedhje, Fail2ban përfshin skedarë filtri për shërbimet e zakonshme. Kur një regjistër nga ndonjë shërbim, si një server në internet, përputhet me failregex
në filtrin e tij, një veprim i paracaktuar ekzekutohet për atë shërbim. aksioni
është një variabël që mund të konfigurohet për të bërë shumë gjëra të ndryshme, në varësi të preferencave të administratorit.
Veprimi i parazgjedhur është ndalimi i hostit/adresës IP ofenduese duke modifikuar rregullat lokale të murit të zjarrit. Ju mund ta zgjeroni këtë veprim, për shembull, t'i dërgoni një email administratorit të sistemit tuaj.
Si parazgjedhje, veprimi do të ndërmerret kur të zbulohen tre dështime të vërtetimit në 10 minuta dhe koha e ndalimit të parazgjedhur është për 10 minuta. Kjo është e konfigurueshme.
Kur përdorni murin e zjarrit të paracaktuar iptables
, fail2ban
krijon një grup të ri rregullash të murit të zjarrit, i quajtur gjithashtu zinxhir, kur shërbimi niset. Ai shton një rregull të ri në zinxhirin INPUT që dërgon të gjithë trafikun TCP të drejtuar në portin 22 në zinxhirin e ri. Në zinxhirin e ri, ai fut një rregull të vetëm që kthehet në zinxhirin INPUT. Zinxhiri dhe rregullat e lidhura hiqen nëse shërbimi Fail2ban ndalet.
Eksplorimi i cilësimeve të shërbimit Fail2ban
Fail2ban konfigurohet përmes disa skedarëve të vendosur brenda një hierarkie nën drejtorinë /etc/fail2ban/
.
Skedari fail2ban.conf
konfiguron disa cilësime operacionale si mënyrën se si daemon regjistron informacionin dhe skedarin e folesë dhe pid që do të përdorë. Sidoqoftë, konfigurimi kryesor specifikohet në skedarët që përcaktojnë \burgët për aplikacion.
Si parazgjedhje, fail2ban dërgohet me një skedar jail.conf
. Megjithatë, kjo mund të mbishkruhet në përditësime, kështu që ju duhet ta kopjoni këtë skedar në një skedar jail.local
dhe të bëni rregullime atje.
Nëse tashmë keni një skedar jail.local
, hapeni duke përdorur nano
ose redaktuesin tuaj të preferuar të tekstit:
- sudo nano /etc/fail2ban/jail.local
Nëse nuk keni tashmë një skedar jail.local
ose skedari që hapët ishte bosh, kopjojeni mbi skedarin jail.conf
dhe më pas hapni skedarin e ri:
- sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
- sudo nano /etc/fail2ban/jail.local
Ne do t'i hedhim një vështrim opsioneve të disponueshme këtu dhe do të shohim se si ky skedar ndërvepron me skedarët e tjerë të konfigurimit në sistem.
Seksioni i parazgjedhur
Pjesa e parë e skedarit do të përcaktojë standardet për politikën fail2ban. Këto opsione mund të anashkalohen në seksionin e konfigurimit të secilit shërbim.
Me komentet e hequra, tërësia e seksionit të paracaktuar duket diçka si kjo:
[DEFAULT]
ignoreip = 127.0.0.1/8
bantime = 10m
findtime = 10m
maxretry = 3
backend = auto
usedns = warn
destemail = root@localhost
sendername = Fail2Ban
banaction = iptables-multiport
mta = sendmail
protocol = tcp
chain = INPUT
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s", sendername="%(sendername)s"]
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s", sendername="%(sendername)s"]
action = %(action_)s
Le të shohim se çfarë do të thotë disa nga këto:
- ignoreip: Ky parametër identifikon adresat IP që duhet të injorohen nga sistemi i ndalimit. Si parazgjedhje, kjo është vendosur vetëm për të injoruar trafikun që vjen nga vetë makina, në mënyrë që të mos mbushni regjistrat tuaj ose të mbyllni veten jashtë.
- bantime: Ky parametër cakton kohëzgjatjen e një ndalimi, në sekonda. Parazgjedhja është 10 minuta.
- findtime: Ky parametër cakton dritaren të cilës Fail2ban do t'i kushtojë vëmendje kur kërkon përpjekje të përsëritura të vërtetimit të dështuara. Parazgjedhja është vendosur në 10 minuta, që do të thotë se softueri do të numërojë numrin e përpjekjeve të dështuara në 10 minutat e fundit.
- maxretry: Kjo cakton numrin e përpjekjeve të dështuara që do të tolerohen brenda dritares findtime
përpara se të vendoset një ndalim.
- backend: Kjo hyrje specifikon se si Fail2ban do të monitorojë skedarët e regjistrit. Cilësimi i auto
do të thotë që fail2ban do të provojë pyinotify
, më pas gamin
dhe më pas një algoritëm votimi bazuar në atë që disponohet. inotify
është një veçori e integruar e kernelit Linux për gjurmimin kur aksesohen skedarët dhe pyinotify
është një ndërfaqe Python për inotify
, e përdorur nga Fail2ban.
- usedns: Kjo përcakton nëse DNS e kundërt përdoret për të ndihmuar në zbatimin e ndalimeve. Vendosja e kësaj në \jo do të ndalojë vetë IP-të në vend të emrave të hosteve të tyre të domenit. Cilësimi paralajmërim
do të përpiqet të kërkojë një emër hosti dhe të ndalojë në atë mënyrë, por do të regjistrojë aktivitetin për shqyrtim.
- destemail: Kjo është adresa që do t'i dërgohet postë njoftimi nëse konfiguroni veprimin tuaj për të postuar sinjalizime.
- emri i dërguesit: Kjo do të përdoret në fushën e email-it për emailet e njoftimeve të krijuara
- banaction: Kjo cakton veprimin që do të përdoret kur të arrihet pragu. Kjo është në fakt një shteg drejt një skedari të vendosur në /etc/fail2ban/action.d/
i quajtur iptables-multiport.conf
. Kjo trajton manipulimin aktual të murit të zjarrit iptables
për të ndaluar një adresë IP. Ne do ta shikojmë këtë më vonë.
- mta: Ky është agjenti i transferimit të postës që do të përdoret për të dërguar email njoftimesh.
- protokolli: Ky është lloji i trafikut që do të hiqet kur të zbatohet një ndalim IP. Ky është gjithashtu lloji i trafikut që dërgohet në zinxhirin e ri iptables.
- zinxhiri: Ky është zinxhiri që do të konfigurohet me një rregull kërcimi për të dërguar trafikun në gypin fail2ban.
Pjesa tjetër e parametrave përcaktojnë veprime të ndryshme që mund të specifikohen. Ata kalojnë në disa nga parametrat që kemi përcaktuar më sipër duke përdorur zëvendësimin e ndryshoreve brenda vargjeve të tekstit si kjo:
%(var_name)s
Rreshti i mësipërm do të zëvendësohet me përmbajtjen e var_name
. Duke përdorur këtë, ne mund të themi se ndryshorja action
është vendosur në përkufizimin action_
si parazgjedhje (vetëm ndalim, pa sinjalizime me postë).
Kjo, nga ana tjetër, konfigurohet duke thirrur veprimin iptables-multiport
me një listë parametrash (emri i shërbimit, porti, protokolli dhe zinxhiri) që nevojiten për të kryer ndalimin. __name__
zëvendësohet me emrin e shërbimit siç specifikohet nga titujt e seksionit më poshtë.
Seksionet specifike të shërbimit
Nën seksionin e paracaktuar, ka seksione për shërbime specifike që mund të përdoren për të anashkaluar cilësimet e paracaktuara. Kjo pason një konventë të modifikimit vetëm të parametrave që ndryshojnë nga vlerat normale (konvencioni mbi konfigurimin).
Çdo kokë seksioni specifikohet si kjo:
[emri_shërbimi]
Çdo seksion që ka rreshtin enabled=true
do të lexohet dhe aktivizohet.
Brenda çdo seksioni, konfigurohen parametrat, duke përfshirë skedarin e filtrit që duhet të përdoret për të analizuar regjistrat (minus shtesën e skedarit) dhe vendndodhjen e vetë skedarëve të regjistrit.
Duke pasur parasysh këtë, seksioni që specifikon veprimet për shërbimin SSH duket kështu:
[SSH]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
Kjo mundëson këtë seksion dhe vendos portin në portin e paracaktuar \ssh (porti 22). I thotë Fail2ban të shikojë regjistrin e vendosur në /var/log/auth.log
për këtë seksion dhe për të analizuar regjistrin duke përdorur mekanizmat e filtrimit të përcaktuar në drejtorinë /etc/fail2ban/filters.d
në një skedar të quajtur sshd.conf
.
Të gjitha pjesët e tjera të informacionit që i nevojiten janë marrë nga parametrat e përcaktuar në seksionin [DEFAULT]
. Për shembull, veprimi do të vendoset në action_
i cili do të ndalojë adresën IP ofenduese duke përdorur banaksionin iptables-multiport
, i cili i referohet një skedari të quajtur iptables-multiport. conf
gjendet në /etc/fail2ban/action.d
.
Siç mund ta shihni, veprimet në seksionin [DEFAULT]
duhet të jenë të përgjithshme dhe fleksibël. Përdorimi i zëvendësimit të parametrave së bashku me parametrat që ofrojnë parazgjedhje të ndjeshme do të bëjë të mundur që të anashkalohen përkufizimet kur është e nevojshme.
Ekzaminimi i skedarit të filtrit
Për të kuptuar se çfarë po ndodh në konfigurimin tonë, duhet të kuptojmë filtrat dhe skedarët e veprimit, të cilët bëjnë pjesën më të madhe të punës.
Skedari i filtrit do të përcaktojë linjat që fail2ban do të kërkojë në skedarët e regjistrit për të identifikuar karakteristikat ofenduese. Skedari i veprimit zbaton të gjitha veprimet e kërkuara, nga ndërtimi i një strukture të murit të zjarrit kur fillon shërbimi, tek shtimi dhe fshirja e rregullave dhe shembja e strukturës së murit të zjarrit kur shërbimi ndalon.
Le të shohim skedarin e filtrit që kërkoi shërbimi ynë SSH në konfigurimin e mësipërm:
- sudo nano /etc/fail2ban/filter.d/sshd.conf
[INCLUDES]
before = common.conf
[Definition]
_daemon = sshd
failregex = ^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error) for .* from <HOST>( via \S+)?\s*$
^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from <HOST>\s*$
^%(__prefix_line)sFailed \S+ for .*? from <HOST>(?: port \d*)?(?: ssh\d*)?(: (ruser .*|(\S+ ID \S+ \(serial \d+\) CA )?\S+ %(__md5hex)s(, client user ".*", client host ".*")?))?\s*$
^%(__prefix_line)sROOT LOGIN REFUSED.* FROM <HOST>\s*$
^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because not listed in AllowUsers\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because listed in DenyUsers\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because not in any group\s*$
^%(__prefix_line)srefused connect from \S+ \(<HOST>\)\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because a group is listed in DenyGroups\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because none of user's groups are listed in AllowGroups\s*$
ignoreregex =
Kreu i seksionit [INCLUDES]
specifikon skedarë të tjerë filtri që lexohen para ose pas këtij skedari. Në shembullin tonë, skedari common.conf
lexohet dhe vendoset përpara rreshtave të tjerë në këtë skedar. Kjo vendos disa parametra që do të përdorim në konfigurimin tonë.
Më pas, ne kemi një seksion [Përkufizim]
që përcakton rregullat aktuale për përputhjet tona të filtrit. Së pari, vendosim emrin e daemonit që po monitorojmë duke përdorur parametrin _daemon
.
Pas kësaj, kalojmë në përkufizimin aktual failregex
, i cili përcakton modelet që do të aktivizohen kur të gjendet një linjë që përputhet në skedarin e regjistrit. Këto janë shprehje të rregullta që përputhen bazuar në gabimet dhe dështimet e ndryshme që mund të hidhen kur një përdorues nuk vërteton saktë.
Pjesë të rreshtit si %(__prefix_line)s
do të zëvendësohen me vlerën e një konfigurimi parametri në skedarin common.conf
që kemi marrë. Kjo përdoret për të përputhur informacionet e ndryshme kryesore që sistemet operative shkruajnë në skedarët e regjistrit kur përdorin metoda standarde. Për shembull, disa rreshta nga /var/log/auth.log
mund të duken diçka si kjo:
May 6 18:18:52 localhost sshd[3534]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=101.79.130.213
May 6 18:18:54 localhost sshd[3534]: Failed password for invalid user phil from 101.79.130.213 port 38354 ssh2
May 6 18:18:54 localhost sshd[3534]: Received disconnect from 101.79.130.213: 11: Bye Bye [preauth]
Pjesa e theksuar është një model standard që sistemi operativ fut për të ofruar më shumë kontekst. Pas kësaj, ka shumë mënyra të ndryshme që shërbimi i murit të zjarrit iptables shkruan përpjekjet e dështimit në regjistër.
Ne shohim dy dështime të veçanta në dy rreshtat e parë të mësipërm (një gabim vërtetimi PAM dhe një gabim fjalëkalimi). Shprehjet e rregullta të përcaktuara në filtër janë krijuar që të përputhen me ndonjë nga linjat e mundshme të dështimit. Ju nuk duhet të rregulloni asnjë nga këto rreshta, por duhet të jeni të vetëdijshëm për nevojën për të kapur të gjitha shënimet e regjistrit që tregojnë një gabim përdorimi të paautorizuar për aplikacionin që po përpiqeni të mbroni nëse ndonjëherë duhet të krijoni vetë një skedar filtri .
Në fund, mund të shihni një parametër ignoreregex
, i cili aktualisht është bosh. Kjo mund të përdoret për të përjashtuar modele më specifike që zakonisht përputhen me një kusht dështimi në rast se dëshironi të mohoni shkasin e dështimit për fail2ban për skenarë të caktuar. Ne nuk do ta rregullojmë këtë.
Ruani dhe mbyllni skedarin kur të keni mbaruar shqyrtimin e tij.
Ekzaminimi i skedarit të veprimit
Tani, le të hedhim një vështrim në skedarin e veprimit. Ky skedar është përgjegjës për konfigurimin e murit të zjarrit me një strukturë që lejon modifikimet për ndalimin e hosteve me qëllim të keq dhe për shtimin dhe heqjen e atyre hosteve sipas nevojës.
Veprimi që thërret shërbimi ynë SSH quhet iptables-multiport
. Hapni skedarin e lidhur tani:
- sudo nano /etc/fail2ban/action.d/iptables-multiport.conf
Me komentet e hequra, ky skedar duket diçka si kjo:
[INCLUDES]
before = iptables-blocktype.conf
[Definition]
actionstart = iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
iptables -I <chain> -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
actionstop = iptables -D <chain> -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
actioncheck = iptables -n -L <chain> | grep -a 'fail2ban-<name>[ \t]'
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j <blocktype>
actionunban = iptables -D fail2ban-<name> -s <ip> -j <blocktype>
[Init]
name = default
port = ssh
protocol = tcp
chain = INPUT
Skedari fillon duke marrë një skedar tjetër veprimi të quajtur iptables-blocktype.conf
që përcakton parametrin blocktype
, i cili konfiguron kufizimin që do të vendoset kur një klient ndalohet. Si parazgjedhje, blocktype
është vendosur të refuzojë paketat dhe t'u përgjigjet ping-ve të dërguara nga klientët e ndaluar me një mesazh refuzimi se porti është i paarritshëm. Ne do ta përdorim këtë në rregullat tona të ndalimit më poshtë.
Më pas, arrijmë te vetë përkufizimet e rregullave. Veprimi actionstart
konfiguron murin e zjarrit iptables kur nis shërbimi fail2ban. Krijon një zinxhir të ri, shton një rregull në atë zinxhir për t'u kthyer në zinxhirin thirrës dhe më pas fut një rregull në fillim të zinxhirit INPUT që kalon trafikun që përputhet me protokollin e saktë dhe destinacionet e portit me zinxhirin e ri.
Këtë e bën duke përdorur vlerat që kemi kaluar me aksionin
që kemi përcaktuar në skedarin tonë jail.local
. emri
merret nga kreu i seksionit për çdo shërbim. zinxhiri
, protokolli
dhe porti
janë marrë nga vetë linja action
në atë skedar.
Këtu, të gjithë parametrat që janë caktuar nga skedari tjetër referohen duke përfshirë emrin e parametrit në kllapa këndore:
<emri_param>
Kur kalojmë te përkufizimi shoqërues actionstop
, mund të shohim se komandat e murit të zjarrit po zbatojnë një ndryshim të komandave actionstart
. Kur shërbimi Fail2ban ndalon, ai heq pastër çdo rregull të murit të zjarrit që ka shtuar.
Një veprim tjetër i quajtur actioncheck
siguron që zinxhiri i duhur është krijuar përpara përpjekjes për të shtuar rregullat e ndalimit.
Më pas, arrijmë te rregulli aktual i ndalimit, i quajtur actionban
. Ky rregull funksionon duke shtuar një rregull të ri në zinxhirin tonë të krijuar. Rregulli përputhet me adresën IP të burimit të klientit ofendues – ky parametër lexohet nga regjistrat e autorizimit kur arrihet kufiri maxretry
. Ai vendos bllokun e përcaktuar nga parametri blocktype
që e kemi marrë në seksionin [INCLUDE]
në krye të skedarit.
Rregulli actionunban
e heq këtë rregull. Kjo bëhet automatikisht nga fail2ban kur të ketë kaluar koha e ndalimit.
Më në fund, arrijmë te seksioni [Init]
. Kjo siguron vetëm disa parazgjedhje në rast se skedari i veprimit thirret pa kaluar të gjitha vlerat e duhura.
Si përpunon shërbimi Fail2ban skedarët e konfigurimit për të zbatuar ndalimet
Tani që kemi parë specifikat, le të kalojmë mbi procesin që ndodh kur fillon fail2ban.
Ngarkimi i skedarëve të konfigurimit fillestar
Së pari, skedari kryesor fail2ban.conf
lexohet për të përcaktuar kushtet në të cilat duhet të funksionojë procesi kryesor. Krijon skedarët fole, pid dhe log nëse është e nevojshme dhe fillon t'i përdorë ato.
Më pas, fail2ban lexon skedarin jail.conf
për detajet e konfigurimit. Kjo pason duke lexuar, sipas rendit alfabetik, çdo skedar të gjetur në drejtorinë jail.d
që përfundojnë në .conf
. Ai shton cilësimet e gjetura në këto skedarë në konfigurimin e tij të brendshëm, duke i dhënë përparësi vlerave të reja mbi vlerat e përshkruara në skedarin jail.conf
.
Më pas kërkon një skedar jail.local
dhe e përsërit këtë proces, duke përshtatur vlerat e reja. Më në fund, ai kërkon përsëri në direktorinë jail.d
, duke lexuar skedarët sipas rendit alfabetik që mbarojnë me .local
.
Në rastin tonë, ne kemi vetëm një skedar jail.conf
dhe një skedar jail.local
. Në skedarin tonë jail.local
, na duhet vetëm të përcaktojmë vlerat që ndryshojnë nga skedari jail.conf
. Procesi fail2ban tani ka një grup direktivash të ngarkuara në memorie që përfaqësojnë një kombinim të të gjithë skedarëve që gjeti.
Ai shqyrton çdo seksion dhe kërkon një direktivë enabled=true
. Nëse gjen një të tillë, përdor parametrat e përcaktuar në atë seksion për të ndërtuar një politikë dhe për të vendosur se çfarë veprimesh kërkohen. Çdo parametër që nuk gjendet në seksionin e shërbimit përdor parametrat e përcaktuar në seksionin [DEFAULT]
.
Analiza e skedarëve të veprimit për të përcaktuar veprimet fillestare
Fail2ban kërkon një direktivë veprim
për të kuptuar se çfarë skript veprimi duhet të thërrasë për të zbatuar politikat e ndalimit/çndalimit. Nëse një nuk gjendet, ai kthehet në veprimin e paracaktuar të përcaktuar më sipër.
Direktiva e veprimit përbëhet nga emri i skedarit(ve) të veprimit që do të lexohen, si dhe një fjalor me vlerë kyçe që kalon parametrat e nevojshëm për ata skedarë. Vlerat e tyre shpesh marrin formën e zëvendësimeve të parametrave duke iu referuar cilësimeve të konfiguruara në seksionin e shërbimit. Tastit \name zakonisht i jepet vlera e ndryshores speciale __name__
që do të vendoset në vlerën e kokës së seksionit.
Fail2ban më pas përdor këtë informacion për të gjetur skedarët e lidhur në drejtorinë action.d
. Fillimisht kërkon skedarin e veprimit të lidhur që përfundon në .conf
dhe më pas ndryshon informacionin e gjetur atje me çdo cilësim që gjendet në një skedar shoqërues .local
që gjendet gjithashtu në direktoria action.d
.
Ai analizon ato skedarë për të përcaktuar veprimet që duhet të ndërmarrë. Ai lexon vlerën actionstart
për të parë veprimet që duhet të ndërmarrë për të konfiguruar mjedisin. Kjo shpesh përfshin krijimin e një strukture firewall për të akomoduar rregullat e ndalimit në të ardhmen.
Veprimet e përcaktuara në këtë skedar përdorin parametrat që i kalojnë atij nga direktiva action
. Ai do t'i përdorë këto vlera për të krijuar në mënyrë dinamike rregullat e duhura. Nëse një variabël i caktuar nuk është vendosur, ai mund të shikojë vlerat e paracaktuara të vendosura në skedarin e veprimit për të mbushur boshllëqet.
Analiza e skedarëve të filtrit për të përcaktuar rregullat e filtrimit
Parametrat për shërbimin në skedarët jail.*
përfshijnë gjithashtu vendndodhjen e skedarit log si dhe mekanizmin e sondazhit që duhet të përdoret për të kontrolluar skedarin (kjo përcaktohet nga backend Parametri
). Ai gjithashtu përfshin një filtër që duhet të përdoret për të përcaktuar nëse një rresht në regjistër përfaqëson një dështim.
Fail2ban shikon në drejtorinë filter.d
për të gjetur skedarin e filtrit që përputhet me .conf
. Ai lexon këtë skedar për të përcaktuar modelet që mund të përdoren për të përputhur linjat ofenduese. Më pas kërkon një skedar filtri që përputhet me .local
për të parë nëse ndonjë nga parametrat e paracaktuar është mbishkruar.
Ai përdor shprehjet e rregullta të përcaktuara në këto skedarë ndërsa lexon skedarin e regjistrit të shërbimit. Ai provon çdo rresht failregex
të përcaktuar në skedarët filter.d
kundrejt çdo rreshti të ri të shkruar në skedarin e regjistrit të shërbimit.
Nëse shprehja e rregullt kthen një përputhje, ajo kontrollon rreshtin kundrejt shprehjeve të rregullta të përcaktuara nga ignoreregex
. Nëse kjo përputhet gjithashtu, fail2ban e injoron atë. Nëse rreshti përputhet me një shprehje në failregex
por nuk përputhet me një shprehje në ignoreregex
, një numërues i brendshëm rritet për klientin që ka shkaktuar linjën dhe një vulë kohore e lidhur është krijuar për ngjarjen.
Ndërsa dritarja e kohës e caktuar nga parametri findtime
në skedarët jail.*
arrihet (siç përcaktohet nga vula kohore e ngjarjes), numëruesi i brendshëm zvogëlohet përsëri dhe ngjarja nuk konsiderohet më e rëndësishme për politikën e ndalimit.
Nëse, me kalimin e kohës, regjistrohen dështime shtesë të vërtetimit, çdo përpjekje rrit numëruesin. Nëse numëruesi arrin vlerën e caktuar nga parametri maxretry
brenda dritares së konfiguruar kohore, fail2ban vendos një ndalim duke thirrur veprimin actioncheck
për shërbimin siç përcaktohet në action.d/
skedarë për shërbimin. Kjo është për të përcaktuar nëse veprimi actionstart
krijon strukturën e nevojshme. Më pas thërret veprimin actionban
për të ndaluar klientin ofendues. Ajo cakton një vulë kohore edhe për këtë ngjarje.
Kur të ketë kaluar koha e specifikuar nga parametri bantime
, fail2ban zhbllokon klientin duke thirrur veprimin actionunban
.
konkluzioni
Deri tani ju keni një kuptim mjaft të thellë se si funksionon fail2ban. Kur devijoni nga konfigurimi standard, është e dobishme të dini se si funksionon fail2ban në mënyrë që të manipuloni sjelljen e tij në një mënyrë të parashikueshme.
Për të mësuar se si të mbroni shërbimet e tjera me fail2ban, mund të lexoni Si të mbroni një server Nginx me Fail2Ban në Ubuntu 22.04.