Introductie
SSH is de facto de methode om verbinding te maken met een cloudserver. Het is duurzaam en het is uitbreidbaar – naarmate nieuwe versleutelingsstandaarden worden ontwikkeld, kunnen ze worden gebruikt om nieuwe SSH-sleutels te genereren, waardoor het kernprotocol veilig blijft. Echter, geen enkel protocol of softwarestack is volledig waterdicht, en SSH is zo wijdverbreid op het internet dat het een zeer voorspelbaar aanvalsoppervlak of aanvalsvector vertegenwoordigt waardoor mensen toegang kunnen proberen te verkrijgen.
Elke dienst die blootgesteld is aan het netwerk is op deze manier een potentieel doelwit. Als je de logs bekijkt van je SSH-dienst die draait op een druk bezochte server, zie je vaak herhaalde, systematische pogingen tot aanmelden die brute force-aanvallen door gebruikers en bots vertegenwoordigen. Hoewel je enkele optimalisaties kunt maken aan je SSH-dienst om de kans op het slagen van deze aanvallen tot bijna nul te verkleinen, zoals wachtwoordauthenticatie uitschakelen ten gunste van SSH-sleutels, kunnen ze toch een kleine, voortdurende aansprakelijkheid vormen.
Grootschalige productiedeployments waarvoor dit risico volledig onaanvaardbaar is, zullen meestal een VPN implementeren zoals WireGuard voor hun SSH-service, zodat het onmogelijk is om rechtstreeks verbinding te maken met de standaard SSH-poort 22 vanaf het externe internet zonder aanvullende software abstractie of gateways. Deze VPN-oplossingen worden algemeen vertrouwd, maar zullen complexiteit toevoegen en kunnen sommige automatiseringen of andere kleine softwarekoppelingen verbreken.
Voorafgaand aan of naast het toewijden aan een volledige VPN-opstelling, kunt u een tool implementeren genaamd Fail2ban. Fail2ban kan brute force-aanvallen aanzienlijk verminderen door regels te creëren die automatisch uw firewallconfiguratie wijzigen om specifieke IP-adressen te verbannen na een bepaald aantal mislukte inlogpogingen. Hierdoor kan uw server zichzelf versterken tegen deze toegangspogingen zonder tussenkomst van u.
In een andere tutorial bespraken we Hoe SSH te beschermen met Fail2ban. In deze gids zullen we dieper ingaan op hoe Fail2ban eigenlijk werkt en hoe u deze kennis kunt gebruiken om het gedrag van deze service aan te passen of uit te breiden.
De Fundamenten van Fail2ban
Het doel van Fail2ban is om de logs van veelgebruikte services te monitoren om patronen in mislukte authenticatiepogingen te detecteren.
Wanneer fail2ban is geconfigureerd om de logs van een service te controleren, kijkt het naar een filter die specifiek voor die service is geconfigureerd. De filter is ontworpen om verificatiefouten voor die specifieke service te identificeren door het gebruik van complexe reguliere expressies. Reguliere expressies zijn een veelvoorkomende sjabloontaal die wordt gebruikt voor patroonherkenning. Het definieert deze reguliere expressiepatronen in een interne variabele genaamd failregex.
Standaard bevat Fail2ban filterbestanden voor veelvoorkomende services. Wanneer een log van een willekeurige service, zoals een webserver, overeenkomt met de failregex in zijn filter, wordt een vooraf gedefinieerde actie uitgevoerd voor die service. De actie is een variabele die geconfigureerd kan worden om verschillende dingen te doen, afhankelijk van de voorkeuren van de beheerder.
De standaardactie is om het schuldige host/IP-adres te blokkeren door de lokale firewallregels aan te passen. Je kunt deze actie uitbreiden om bijvoorbeeld een e-mail te sturen naar je systeembeheerder.
Standaard wordt actie ondernomen wanneer drie verificatiefouten zijn gedetecteerd in 10 minuten, en de standaard blokkeertijd is 10 minuten. Dit is configureerbaar.
Wanneer de standaard iptables firewall wordt gebruikt, maakt fail2ban bij het starten van de service een nieuwe set firewallregels, ook wel een chain genoemd. Het voegt een nieuwe regel toe aan de INPUT chain die al het TCP-verkeer dat is gericht op poort 22 naar de nieuwe chain stuurt. In de nieuwe chain voegt het een enkele regel in die terugkeert naar de INPUT chain. De chain en bijbehorende regels worden verwijderd als de Fail2ban-service wordt gestopt.
Het verkennen van Fail2ban-service-instellingen
Fail2ban is geconfigureerd via verschillende bestanden die zich bevinden in een hiërarchie onder de /etc/fail2ban/-directory.
Het bestand fail2ban.conf configureert enkele operationele instellingen zoals de manier waarop de daemon informatie vastlegt, en de socket- en pid-bestanden die het zal gebruiken. De hoofdconfiguratie wordt echter gespecificeerd in de bestanden die de per-toepassing “jails” definiëren.
Standaard wordt fail2ban geleverd met een jail.conf-bestand. Dit kan echter worden overschreven bij updates, dus u moet dit bestand kopiëren naar een jail.local-bestand en daar aanpassingen maken.
Als u al een jail.local-bestand heeft, opent u het met nano of uw favoriete teksteditor:
Als u nog geen jail.local-bestand heeft, of als het geopende bestand leeg was, kopieert u het jail.conf-bestand en opent u vervolgens het nieuwe bestand:
We zullen kijken naar de beschikbare opties hier en zien hoe dit bestand interageert met andere configuratiebestanden op het systeem.
De Standaard Sectie
Het eerste gedeelte van het bestand zal de standaardinstellingen voor het fail2ban-beleid definiëren. Deze opties kunnen worden overschreven in de configuratiesectie van elke individuele service.
Zonder de opmerkingen ziet het gehele standaardgedeelte er als volgt uit:
[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
Laten we eens kijken wat dit betekent:
- ignoreip: Deze parameter identificeert IP-adressen die door het verbanningssysteem genegeerd moeten worden. Standaard is dit alleen ingesteld om verkeer van de eigen machine te negeren, zodat u uw eigen logs niet vult of uzelf buitensluit.
- bantime: Deze parameter stelt de duur van een verbanning in, in seconden. Standaard is dit 10 minuten.
- findtime: Deze parameter stelt het venster in waarop Fail2ban let bij het zoeken naar herhaalde mislukte authenticatiepogingen. Standaard is dit ingesteld op 10 minuten, wat betekent dat de software het aantal mislukte pogingen in de laatste 10 minuten zal tellen.
- maxretry: Dit stelt het aantal mislukte pogingen in dat wordt getolereerd binnen het
findtime-venster voordat een verbanning wordt ingesteld. - backend: Deze invoer specificeert hoe Fail2ban logbestanden zal monitoren. De instelling van
autobetekent dat fail2banpyinotifyzal proberen, vervolgensgamin, en dan een polling-algoritme op basis van wat beschikbaar is.inotifyis een ingebouwde functie van de Linux-kernel voor het volgen wanneer bestanden worden geopend, enpyinotifyis een Python-interface naarinotify, gebruikt door Fail2ban. - usedns: Dit bepaalt of omgekeerde DNS wordt gebruikt om verboden te implementeren. Het instellen hiervan op “nee” zal IP-adressen zelf verbieden in plaats van hun domeinhostnamen. De instelling
warnzal proberen om een hostnaam op te zoeken en op die manier te verbieden, maar zal de activiteit wel loggen voor controle. - destemail: Dit is het adres waarnaar meldingsmail wordt gestuurd als uw actie is geconfigureerd om waarschuwingen te mailen.
- sendername: Dit wordt gebruikt in het veld ‘Van’ van gegenereerde meldingsmails.
- banaction: Dit stelt de actie in die wordt gebruikt wanneer de drempel is bereikt. Dit is eigenlijk een pad naar een bestand in
/etc/fail2ban/action.d/genaamdiptables-multiport.conf. Dit behandelt de daadwerkelijke manipulatie van deiptables-firewall om een IP-adres te verbieden. We zullen hier later naar kijken. - mta: Dit is de mail transfer agent die wordt gebruikt om meldingsmails te verzenden.
- protocol: Dit is het type verkeer dat wordt verworpen wanneer een IP-verbod wordt geïmplementeerd. Dit is ook het type verkeer dat naar de nieuwe iptables-keten wordt gestuurd.
- chain: Dit is de keten die wordt geconfigureerd met een jump-regel om verkeer naar de fail2ban-trechter te sturen.
De rest van de parameters definiëren verschillende acties die kunnen worden gespecificeerd. Ze geven enkele van de bovenstaande parameters door met variabele substitutie binnen tekstsnoeren zoals dit:
%(var_name)s
De regel hierboven zou worden vervangen door de inhoud van var_name. Hierdoor kunnen we zien dat de variabele action standaard is ingesteld op de definitie van action_ (alleen ban, geen e-mailmeldingen).
Dit wordt op zijn beurt geconfigureerd door de iptables-multiport-actie aan te roepen met een lijst van parameters (servicenaam, poort, protocol en keten) die nodig zijn om de ban uit te voeren. De __name__ wordt vervangen door de naam van de service zoals gespecificeerd door de sectiekopteksten hieronder.
Service-specifieke secties
Onder de standaardsectie zijn er secties voor specifieke services die kunnen worden gebruikt om de standaardinstellingen te overschrijven. Dit volgt een conventie van alleen het wijzigen van de parameters die verschillen van de normale waarden (conventie boven configuratie).
Elke sectiekop wordt gespecificeerd als volgt:
[service_naam]
Elke sectie die de regel enabled = true heeft, wordt gelezen en ingeschakeld.
Binnen elke sectie worden de parameters geconfigureerd, inclusief het filterbestand dat moet worden gebruikt om de logs te parseren (zonder de bestandsextensie) en de locatie van de logbestanden zelf.
Met dit in gedachten ziet de sectie die de acties voor de SSH-service specificeert er als volgt uit:
[SSH]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
Dit maakt dit gedeelte mogelijk en stelt de poort in op de standaard “ssh”-poort (poort 22). Het vertelt Fail2ban om het logbestand op /var/log/auth.log voor dit gedeelte te bekijken en het logbestand te parseren met behulp van de filtermechanismen gedefinieerd in de map /etc/fail2ban/filters.d in een bestand genaamd sshd.conf.
Alle andere benodigde informatie wordt gehaald uit de parameters gedefinieerd in de [DEFAULT]-sectie. Bijvoorbeeld, de actie zal worden ingesteld op action_, die het IP-adres van de overtredende partij zal verbannen met behulp van de iptables-multiport banaction, die verwijst naar een bestand genaamd iptables-multiport.conf gevonden in /etc/fail2ban/action.d.
Zoals je kunt zien, moeten de acties in de [DEFAULT]-sectie algemeen en flexibel zijn. Het gebruik van parametervervanging samen met parameters die zinvolle standaardwaarden bieden, maakt het mogelijk om definities te overschrijven wanneer dat nodig is.
Het Filterbestand onderzoeken
Om te begrijpen wat er gebeurt in onze configuratie, moeten we de filter- en actiebestanden begrijpen, die het grootste deel van het werk doen.
Het filterbestand zal de regels bepalen waar Fail2ban naar zal zoeken in de logbestanden om overtredende kenmerken te identificeren. Het actiebestand implementeert alle vereiste acties, van het opbouwen van een firewallstructuur wanneer de service start, tot het toevoegen en verwijderen van regels, en het afbreken van de firewallstructuur wanneer de service stopt.
Laten we eens kijken naar het filterbestand dat onze SSH-service opvraagt in de bovenstaande configuratie:
[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 =
De [INCLUDES]-sectiekop specificeert andere filterbestanden die worden ingelezen voor of na dit bestand. In ons voorbeeld wordt het bestand common.conf ingelezen en geplaatst vóór de andere regels in dit bestand. Dit stelt enkele parameters in die we zullen gebruiken in onze configuratie.
Vervolgens hebben we een [Definition]-sectie die de daadwerkelijke regels definieert voor onze filtermatches. Eerst stellen we de naam in van de daemon die we bewaken door de parameter _daemon te gebruiken.
Daarna gaan we door met de daadwerkelijke definitie van failregex, die de patronen instelt die worden geactiveerd wanneer een overeenkomende regel in het logbestand wordt gevonden. Dit zijn reguliere expressies die overeenkomen op basis van de verschillende fouten en mislukkingen die kunnen optreden wanneer een gebruiker niet correct authenticeren.
Gedeelten van de regel zoals %(__prefix_line)s worden vervangen door de waarde van een parameter die is ingesteld in het bestand common.conf dat we hebben gebruikt. Dit wordt gebruikt om de verschillende leidende informatie te matchen die besturingssystemen schrijven naar logbestanden wanneer ze standaardmethoden gebruiken. Bijvoorbeeld, sommige regels uit het bestand /var/log/auth.log kunnen er als volgt uitzien:
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]
Het gemarkeerde gedeelte is een standaardpatroon dat het besturingssysteem invoegt om meer context te bieden. Daarna zijn er verschillende manieren waarop de iptables-firewall-service mislukte pogingen naar het logboek schrijft.
We zien twee afzonderlijke mislukkingen in de eerste twee regels hierboven (een PAM-authenticatiefout en een wachtwoordfout). De reguliere expressies gedefinieerd in de filter zijn ontworpen om te passen bij een van de mogelijke foutregels. U hoeft geen van deze regels aan te passen, maar u moet op de hoogte zijn van de noodzaak om alle logboekvermeldingen op te vangen die een ongeoorloofd gebruiksfout aangeven voor de toepassing die u probeert te beschermen als u ooit zelf een filterbestand moet maken.
Onderaan kunt u een ignoreregex-parameter zien, die momenteel leeg is. Deze kan worden gebruikt om meer specifieke patronen uit te sluiten die meestal overeenkomen met een foutconditie in geval u de fouttrigger voor fail2ban voor bepaalde scenario’s wilt negere. We zullen dit niet aanpassen.
Sla het bestand op en sluit het wanneer u klaar bent met het bekijken ervan.
Het Actiebestand onderzoeken
Laten we nu eens kijken naar het actiebestand. Dit bestand is verantwoordelijk voor het opzetten van de firewall met een structuur die wijzigingen mogelijk maakt voor het verbannen van kwaadwillende hosts, en voor het toevoegen en verwijderen van die hosts indien nodig.
De actie die onze SSH-service oproept, heet iptables-multiport. Open nu het bijbehorende bestand:
Met de opmerkingen verwijderd, ziet dit bestand er ongeveer zo uit:
[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
Het bestand begint met het sourcen van een ander actiebestand genaamd iptables-blocktype.conf dat de blocktype-parameter definieert, die de beperking configureert die wordt ingesteld wanneer een client verbannen wordt. Standaard is de blocktype ingesteld op het weigeren van pakketten en het antwoorden op pings verzonden door verbannen clients met een afwijzingsbericht dat de poort onbereikbaar is. We zullen dit gebruiken in onze verbanningsregels hieronder.
Vervolgens komen we bij de regeldefinities zelf. De actionstart-actie stelt de iptables-firewall in wanneer de fail2ban-service wordt gestart. Het maakt een nieuwe chain aan, voegt een regel toe aan die chain om terug te keren naar de aanroepende chain, en voegt vervolgens een regel toe aan het begin van de INPUT chain die verkeer doorstuurt dat overeenkomt met de juiste protocol- en poortbestemmingen naar de nieuwe chain.
Dit wordt gedaan door de waarden te gebruiken die we hebben doorgegeven met de action die we hebben gedefinieerd in ons jail.local-bestand. De name wordt overgenomen uit de sectiekop voor elke service. De chain, protocol en port worden overgenomen uit de action-regel zelf in dat bestand.
Hier worden alle parameters die zijn ingesteld door het andere bestand aangeduid door de parameter naam tussen hoekige haakjes op te nemen:
<param_name>
Wanneer we naar de bijbehorende definitie van actionstop gaan, kunnen we zien dat de firewall-opdrachten een omgekeerde uitvoering van de actionstart-opdrachten implementeren. Wanneer de Fail2ban-service stopt, verwijdert het op een schone manier eventuele firewallregels die het heeft toegevoegd.
Een andere actie genaamd actioncheck controleert of de juiste keten is aangemaakt voordat er pogingen worden ondernomen om banregels toe te voegen.
Vervolgens komen we bij de daadwerkelijke banregel, genaamd actionban. Deze regel werkt door een nieuwe regel toe te voegen aan onze aangemaakte keten. De regel komt overeen met het bron-IP-adres van de overtredende client – deze parameter wordt gelezen uit de autorisatielogs wanneer de maxretry limiet is bereikt. Het voert het blok uit dat is gedefinieerd door de blocktype parameter die we hebben opgehaald in de [INCLUDE] sectie bovenaan het bestand.
De actionunban regel verwijdert deze regel. Dit gebeurt automatisch door fail2ban wanneer de ban-tijd is verstreken.
Tenslotte komen we bij de [Init] sectie. Dit geeft alleen wat standaardwaarden voor het geval dat het actiebestand wordt aangeroepen zonder alle juiste waarden door te geven.
Hoe de Fail2ban Service Configuratiebestanden Verwerkt om Blokkades te Implementeren
Nu we de details hebben gezien, laten we eens kijken naar het proces dat plaatsvindt wanneer fail2ban wordt gestart.
Het Laden van de Initiële Configuratiebestanden
Eerst wordt het hoofdbestand fail2ban.conf gelezen om de voorwaarden te bepalen waaronder het hoofdproces moet werken. Het maakt de socket, pid en logbestanden indien nodig aan en begint ze te gebruiken.
Vervolgens leest fail2ban het bestand jail.conf voor configuratiedetails. Hierop volgend, in alfabetische volgorde, worden eventuele bestanden in de map jail.d die eindigen op .conf gelezen. De instellingen in deze bestanden worden toegevoegd aan de interne configuratie, waarbij nieuwe waarden voorrang krijgen boven de waarden beschreven in het bestand jail.conf.
Vervolgens wordt er gezocht naar een jail.local-bestand en wordt dit proces herhaald, waarbij nieuwe waarden worden aangepast. Ten slotte wordt opnieuw gezocht in de map jail.d, waarbij bestanden in alfabetische volgorde worden gelezen die eindigen op .local.
In ons geval hebben we alleen een jail.conf-bestand en een jail.local-bestand. In ons jail.local-bestand hoeven we alleen de waarden te definiëren die verschillen van het jail.conf-bestand. Het fail2ban-proces heeft nu een reeks geladen richtlijnen in het geheugen die een combinatie vormen van alle gevonden bestanden.
Het bekijkt elke sectie en zoekt naar een enabled = true directive. Als het er een vindt, gebruikt het de parameters gedefinieerd onder die sectie om een beleid op te bouwen en te beslissen welke acties vereist zijn. Eventuele parameters die niet worden gevonden in de sectie van de service, gebruiken de parameters gedefinieerd in de [DEFAULT] sectie.
Het parsen van de Actiebestanden om Startacties te bepalen
Fail2ban zoekt naar een action directive om te bepalen welk actiescript moet worden aangeroepen om de beleidsregels voor het blokkeren/ontgrendelen uit te voeren. Als deze niet wordt gevonden, valt het terug op de standaardactie die hierboven is bepaald.
De actiedirective bestaat uit de naam van het actiebestand(en) die worden gelezen, evenals een key-value-dictionary die de parameters doorgeeft die nodig zijn voor die bestanden. De waarden hiervan nemen vaak de vorm aan van parametervervangingen door verwijzing naar de instellingen geconfigureerd in de sectie van de service. De “name” key krijgt meestal de waarde van de speciale __name__ variabele die zal worden ingesteld op de waarde van de kop van de sectie.
Fail2ban gebruikt deze informatie vervolgens om de bijbehorende bestanden te vinden in de action.d directory. Het zoekt eerst naar het bijbehorende actiebestand eindigend op .conf en voegt dan de daar gevonden informatie aan met eventuele instellingen die zijn opgenomen in een bijbehorend .local bestand dat ook wordt gevonden in de action.d directory.
Het analyseert die bestanden om de acties te bepalen die het moet uitvoeren. Het leest de actionstart waarde om de acties te zien die het moet ondernemen om de omgeving op te zetten. Dit omvat vaak het creëren van een firewallstructuur om toekomstige blokkeringsregels mogelijk te maken.
De acties gedefinieerd in dit bestand gebruiken de parameters die eraan zijn doorgegeven vanuit de action richtlijn. Het zal deze waarden gebruiken om dynamisch de passende regels te creëren. Als een bepaalde variabele niet is ingesteld, kan het de standaardwaarden in het actiebestand bekijken om de lege plekken in te vullen.
Het Parsen van de Filterbestanden om Filterregels te Bepalen
De parameters voor de service in de jail.* bestanden omvatten ook de locatie van het logbestand evenals het polling mechanisme dat moet worden gebruikt om het bestand te controleren (dit wordt gedefinieerd door de backend parameter). Het omvat ook een filter die moet worden gebruikt om te bepalen of een regel in het logbestand een fout vertegenwoordigt.
Fail2ban kijkt in de filter.d directory om het overeenkomstige filterbestand te vinden dat eindigt op .conf. Het leest dit bestand om de patronen te definiëren die kunnen worden gebruikt om overtredende regels te matchen. Het zoekt vervolgens naar een overeenkomstig filterbestand dat eindigt op .local om te zien of een van de standaardparameters is overschreven.
Het gebruikt de reguliere expressies gedefinieerd in deze bestanden terwijl het het logbestand van de service leest. Het probeert elke failregex-regel gedefinieerd in de filter.d-bestanden tegen elke nieuwe regel die naar het logbestand van de service wordt geschreven.
Als de reguliere expressie een overeenkomst oplevert, controleert het de regel tegen de reguliere expressies gedefinieerd door de ignoreregex. Als dit ook overeenkomt, negeert fail2ban het. Als de regel overeenkomt met een expressie in de failregex maar niet overeenkomt met een expressie in de ignoreregex, wordt er een interne teller verhoogd voor de client die de regel heeft veroorzaakt en wordt er een bijbehorende tijdstempel gemaakt voor het evenement.
Wanneer het tijdsvenster ingesteld door de findtime-parameter in de jail.*-bestanden is bereikt (zoals bepaald door de gebeurtenistijdstempel), wordt de interne teller weer verlaagd en wordt het evenement niet langer als relevant beschouwd voor het banbeleid.
Als er in de loop van de tijd aanvullende authenticatiefouten worden geregistreerd, wordt elke poging de teller verhoogd. Als de teller binnen het geconfigureerde tijdsvenster de waarde bereikt die is ingesteld door de maxretry-parameter, voert fail2ban een ban in door de actioncheck-actie voor de service aan te roepen zoals gedefinieerd in de action.d/-bestanden voor de service. Dit is om te bepalen of de actionstart-actie de noodzakelijke structuur heeft ingesteld. Vervolgens roept het de actionban-actie aan om de overtredende client te verbannen. Het stelt ook een tijdstempel in voor dit evenement.
Wanneer de opgegeven tijd is verstreken die is gespecificeerd door de bantime-parameter, heft fail2ban het verbod van de client op door de actionunban-actie aan te roepen.
Conclusie
Op dit moment heb je een vrij diepgaand begrip van hoe fail2ban werkt. Wanneer je afwijkt van de standaardconfiguratie, is het handig om te weten hoe fail2ban functioneert om zijn gedrag op een voorspelbare manier te kunnen manipuleren.
Om te leren hoe je andere services kunt beschermen met fail2ban, kun je lezen Hoe je een Nginx-server beschermt met Fail2Ban op Ubuntu 22.04.