Alternatieven voor Fail2Ban voor moderne Linux-servers

Controleer het aanvalsoppervlak voordat je gereedschap kiest

A Alternatief voor Fail2Ban kan pas zinvol worden geselecteerd als vaststaat welke diensten daadwerkelijk bereikbaar zijn. SSH, SMTP, IMAP en een HTTP-toepassing hebben verschillende aanmeldingsprocedures, logbronnen en schade patronen. Een openbaar toegankelijke databasedienst hoeft daarentegen in de regel niet te worden beschermd door een internetblokkeerlijst: de netwerktoegang ervan moet worden beperkt tot noodzakelijke toepassingen en betrouwbare netwerken.

Bij administratieve toevoegingen geldt dat Toegangsbeperking en een sterke aanmelding heeft voorrang boven geautomatiseerde IP-blokkades. Een SSH-dienst achter een VPN, bastionhost of vaste beheernetwerken biedt aanvallers een aanzienlijk kleiner aanvalsoppervlak dan een wereldwijd open poort. Actuele beveiligingsupdates, gescheiden geprivilegieerde accounts en zorgvuldig afgewogen wachtwoordaanmeldingen verminderen daarbij risico’s die een blokkeerlijst alleen niet wegneemt.

Als SSH bewust openbaar toegankelijk is, kunnen limieten en op logbestanden gebaseerde blokkades herhaalde wachtwoordpogingen beperken. Ze blijven echter een aanvulling: personen achter een gemeenschappelijke NAT-gateway kunnen hetzelfde bronadres gebruiken, terwijl gedistribueerde aanvallen gebruikmaken van veel verschillende adressen. Voor e-maildiensten is het bovendien van belang welke protocollen daadwerkelijk toegankelijk zijn voor externe gebruikers en welke mislukte inlogpogingen worden gelogd.

Bij webapplicaties moet onderscheid worden gemaakt tussen de bereikbaarheid van de reverse proxy en die van interne backend-diensten. Een openbare Nginx kan HTTP-verzoeken verwerken zonder dat de database, de cache of de beheerinterface via internet bereikbaar hoeven te zijn. Dat Beschermingsdoelstelling Het gaat dus niet om een algemene maatregel als „IP-adressen blokkeren“, maar om het per dienst beperken van onbevoegde toegang, het waarborgen van legitiem gebruik en het voorkomen van onnodige vrijgaven.

Vóór elke wijziging moeten de verantwoordelijken vastleggen welke toegangsroutes in geval van nood nodig zijn en welke bronnetwerken normaal gesproken toegang hebben. Deze inventarisatie voorkomt dat een te strenge firewallregel de eigen beheerderstoegang of geautomatiseerd onderhoud blokkeert. Pas daarna kan worden besloten of logboekanalyse, verbindingsbeperking of een meerlagig concept geschikt is.

Een blokkering geeft bovendien geen antwoord op de vraag of een dienst überhaupt openbaar moet zijn. Wie deze volgorde omdraait, pakt opvallende verbindingen aan, hoewel de fundamentele blootstelling ongewijzigd blijft. Vooral bij zelden gebruikte beheerinterfaces is een privétoegang vaak effectiever en eenvoudiger te beheren dan steeds complexere herkenningsregels.

Vier benaderingen in plaats van één alternatief voor Fail2Ban

In plaats van op zoek te gaan naar één enkele oplossing, loont het de moeite om detectie en reactie van elkaar te scheiden. CrowdSec verwerkt configureerbare logbronnen met parsers en scenario’s om reeksen gebeurtenissen te evalueren en beslissingen te genereren. De Security Engine voert deze beslissingen niet zelf uit; daarvoor moet een afzonderlijke Remediation Component zijn aangesloten en operationeel zijn.

Deze indeling is geschikt wanneer dezelfde detectie op verschillende plaatsen moet worden toegepast. Een firewallcomponent kan beslissingen toepassen op netwerkverbindingen, terwijl componenten voor webservers of reverse proxies zich richten op het HTTP-verkeer. Dit stelt echter ook hogere eisen: logboekverzameling, parsers, lokale API's, machtigingen en de daadwerkelijke handhaving moeten als een samenhangende keten worden gepland.

SSHGuard is bedoeld voor meer specifiek omschreven gevallen. De tool verzamelt systeemlogboeken en kan bronnen die herhaaldelijk opvallen via firewall-backends blokkeren; het is bedoeld om brute-force-aanvallen op SSH en andere diensten tegen te gaan. Het is daarom eerder geschikt voor traceerbare authenticatiefouten dan voor een uitgebreide analyse van webverzoeken.

Native nftables-snelheidsbeperking hanteert een andere aanpak. Dynamische sets en meters kunnen het aantal nieuwe TCP-verbindingen per bronadres beperken en vermeldingen met een time-out beheren. Dit remt snelle reeksen verbindingen vóór de authenticatie af, vereist geen logparser en beoordeelt tegelijkertijd niet of een aanmelding is mislukt of dat een HTTP-verzoek kwaadaardig was.

De richting van de regel is hierbij van belang: nftables maakt onderscheid tussen regels die verkeer tot een bepaalde snelheid toestaan, en uitdrukkingen met over, die verkeer boven een bepaalde drempelwaarde afwijzen. Een limiet moet daarom aansluiten bij de dienst, het verwachte gebruikersgedrag en gedeelde bronadressen. Het is geen betrouwbare classificatie van elke verdachte identiteit.

Voor een enkele server met een beperkt aantal duidelijke diensten kan een minimale logbescherming of een gematigde verbindingslimiet volstaan. Meerdere hosts, centrale logbronnen of de behoefte aan verschillende handhavingspunten pleiten eerder voor een modulaire architectuur. Geen van deze opties is een vervanging voor patches, sterke authenticatie of restrictieve netwerktoegang.

Het geschikte alternatief voor Fail2Ban hangt dus af van de vraag welke signalen beschikbaar zijn en waar er moet worden gereageerd. Logpatronen zijn nuttig bij herhaalde aanmeldingsfouten; pakketregels beperken de verbindingsfrequentie. Beide methoden herkennen alleen datgene waarvoor hun gegevensbron en hun regels zijn ontworpen.

Firewall en HTTP-beveiliging duidelijk van elkaar scheiden

Een Nginx-server of reverse proxy verbindt twee beveiligingslagen die niet met elkaar verward mogen worden. Een firewallblokkering weigert of staat verbindingen van een bronadres toe en kan daarmee tegelijkertijd van invloed zijn op SSH, SMTP of webtoegang. Ze beoordeelt echter geen afzonderlijke HTTP-paden, headers of de inhoud van verzoeken; deze informatie bevindt zich op applicatieniveau.

Bij CrowdSec zijn Opsporing en handhaving afzonderlijke taken. De Log Processor analyseert loggegevens en HTTP-verzoeken van compatibele webservers. AppSec maakt deel uit van deze Log Processor en filtert dergelijke HTTP-verzoeken. Remediation Components zijn daarentegen verantwoordelijk voor het doorvoeren van beslissingen op het gekozen niveau, bijvoorbeeld op een firewall, een webserver of een reverse proxy.

Voor bescherming tegen SQL-injectie, cross-site scripting of andere schadelijke inhoud in verzoeken volstaat een firewallcomponent op zich daarom niet. Er is een compatibele webserververbinding nodig, evenals een geschikte AppSec-configuratie met de juiste regels. De remedie moet hier technisch gescheiden van blijven: deze voert beslissingen uit op het geselecteerde handhavingspunt.

Beide niveaus kunnen naast elkaar zinvol zijn. Een netwerkbrede blokkering beperkt het verdere verbindingsverkeer van een bron, terwijl een HTTP-controle beoordeelt en filtert webservers die compatibel zijn met AppSec-verzoeken. Dat betekent niet dat een IP-blokkering automatisch bescherming biedt tegen SQL-injectie of cross-site scripting: zonder controle van de verzoeken herkent de firewall noch parameters, noch gebruiksgegevens.

Omgekeerd blijven ook AppSec- en IP-gebaseerde maatregelen beperkt. Trage pogingen onder de drempelwaarden, veel wisselende bronadressen of legitieme gebruikers achter hetzelfde NAT-adres bemoeilijken beslissingen op basis van het bron-IP-adres. Regels moeten daarom rekening houden met valse alarmen en de toegang tot normale formulieren, API’s en geautomatiseerde integraties niet zonder meer als een aanval behandelen.

Voor de planning is het handig om even de zaken op een rijtje te zetten: De Firewall-niveau stuurt netwerkverkeer op basis van adressen, poorten en verbindingskenmerken. AppSec verwerkt en filtert HTTP-verzoeken van compatibele webservers als onderdeel van de logprocessor. Remediation Components voeren beslissingen doelbewust uit op een gekozen niveau.

Een openbaar websysteem vereist bovendien een duidelijke scheiding van bevoegdheden. De reverse proxy mag alleen toegang hebben tot de benodigde backends, en administratieve eindpunten mogen niet alleen vanwege een filter ervoor openbaar blijven. Zo vullen netwerksegmentatie, beveiligde aanmelding en gerichte regels elkaar aan, zonder aan één enkele beveiligingstechniek meer bescherming toe te schrijven dan deze kan bieden.

Vergelijking van typische Linux-servers

Een alternatief voor Fail2Ban kan niet zinvol worden gekozen op basis van het aantal mogelijke blokkades alleen. Doorslaggevend zijn de signalen die worden geanalyseerd en de plaats waar de maatregelen worden toegepast. CrowdSec scheidt zijn beveiligingsengine van de component die beslissingen op de firewall, proxy of webserver afdwingt. SSHGuard analyseert daarentegen systeemprotocollen op herhaalde aanvalspogingen; nftables kan nieuwe verbindingen direct in het pakketpad beperken.

De tabel geeft geen rangorde weer. Voor een afzonderlijke dienst met duidelijk mislukte aanmeldingen is een eenvoudige loganalyse iets anders dan een limiet tegen verbindingsstormen. Voor een reverse proxy speelt bovendien een rol of HTTP-verzoeken door AppSec via een compatibele verbinding moeten worden gefilterd. Dat Handhavingspunt moet bij het te beveiligen object passen: een firewallregel beoordeelt de inhoud van verzoeken niet, terwijl remediation-componenten beslissingen op het gekozen niveau doorvoeren.

Ook centraal beheer is geen doel op zich. Het kan de besluitvorming en de analyse van logbestanden over meerdere hosts heen uniform maken, maar vereist wel een robuust concept voor toegang en uitvalbeheer. Voor een kleine, geïsoleerde server kan deze extra architectuur onder bepaalde omstandigheden meer onderhoudswerk met zich meebrengen dan dat het aan veiligheid oplevert. Omgekeerd kunnen identieke diensten op meerdere hosts profiteren van een bewust geplande centrale CrowdSec-installatie.

De configuratie zorgvuldig controleren en indelen

Voordat je de functie activeert, moet eerst vaststaan welke meldingen de dienst daadwerkelijk bereiken. Controleer bij een op logbestanden gebaseerde oplossing de logbron, de parser en het specifieke formaat van SSH-, e-mail- of proxy-gebeurtenissen. Bij CrowdSec is gedetecteerde activiteit niet voldoende: een geregistreerde en bereikbare remediatiecomponent moet beslissingen doorgeven aan de daarvoor bestemde firewall- of proxyverbinding.

De volgende commando's zijn uitsluitend bedoeld om de huidige status te controleren op een Linux-systeem waarop de betreffende tools mogelijk al aanwezig zijn. Ze wijzigen geen regels en installeren geen pakketten. Ze helpen je om de huidige set regels, geregistreerde CrowdSec-componenten en de voor Debian of Ubuntu beschikbare pakketkandidaten te bekijken.

nft list ruleset
sudo cscli bouncers list
apt-cache policy crowdsec

De uitvoer biedt nog geen bescherming. Controleer in nftables of de betreffende input-chain de verwachte hook en het juiste standaardbeleid heeft, en of er regels zijn voorzien voor bestaande verbindingen, loopback, IPv4 en IPv6, evenals voor de daadwerkelijke servicepoort. Een geregistreerd onderdeel kan bovendien voor het verkeerde handhavingspunt zijn geconfigureerd. Ook een zichtbaar pakketkandidaat zegt niets over de vraag of de versie, configuratie en parser ervan passen bij de distributie en bij de eigen dienst.

Drempelwaarden, blokkeringsduur en uitzonderingen mogen niet zonder controle uit voorbeelden in de productie worden overgenomen. Met name gedeelde NAT-adressen, mobiele verbindingen en geautomatiseerde taken kunnen anders tot valse alarmen leiden. Voor de analyse van netwerkgebeurtenissen en systeemgedrag kan aanvullend eBPF-tracing voor Linux-monitoring helpen; het vervangt echter noch de controle van de logketen, noch de inhoudelijke beslissing over een blokkering.

De juiste keuze voor vier bedrijfsscenario’s

Een enkele VPS met wereldwijd toegankelijke SSH heeft een duidelijk afgebakende beveiligingsbehoefte. SSHGuard kan herhaalde, in de betreffende logbestanden herkenbare mislukte pogingen melden aan een firewall-backend. Een gematigde nftables-limiet kan nieuwe verbindingen bovendien afremmen, maar houdt geen rekening met aanmeldingsfouten. Voorrang wordt gegeven aan beperkte beheerskanalen en sterke authenticatie; een IP-blokkering blijft een aanvulling.

Bij een mailserver hebben SMTP, IMAP en Submission te maken met verschillende authenticatie- en logtrajecten. Een gestroomlijnde, op logbestanden gebaseerde reactie is alleen zinvol als de relevante meldingen volledig worden vastgelegd. CrowdSec wordt een optie wanneer beslissingen of loganalyse over meerdere systemen moeten worden gebundeld. Zonder deze behoefte zou de centrale architectuur onevenredig zijn ten opzichte van een duidelijk afgebakende lokale oplossing.

Voor Nginx of Traefik vóór een webapplicatie volstaat een tool die uitsluitend op SSH is gericht niet. Hier maakt een meerlaagse beveiliging Netwerktoegang vanuit HTTP-controles: CrowdSec AppSec maakt deel uit van de Log Processor en kan verzoeken van compatibele webservers filteren. Remediation Components voeren daarentegen beslissingen door op het geselecteerde niveau, bijvoorbeeld op de webserver of de reverse proxy. Beide taken moeten op de juiste manier worden geïntegreerd en afzonderlijk worden gecontroleerd.

Een kleine omgeving met centrale logbestanden of Kubernetes kan profiteren van een centrale lokale API of gecentraliseerde logbestanden. Dit vereenvoudigt de bedrijfsvoering echter niet automatisch: er moet rekening worden gehouden met machtigingen, de bereikbaarheid van de interfaces, segmentatie en het uitvallen van een centrale component. Aspecten van pakketverwerking en lastverdeling in grotere Linux-netwerken komen ook aan bod in het artikel over Receive Side Scaling bij Linux-servernetwerken. Voor een klein aantal hosts zonder gemeenschappelijk bedrijfsproces is een lokale oplossing vaak overzichtelijker.

De logische beveiliging tijdens het bedrijf controleren

Een blokkeringslogica is alleen begrijpelijk als je drie fasen afzonderlijk controleert: de ontvangst van de loggegevens, de daaruit afgeleide beslissing en de technische uitvoering daarvan. Bij CrowdSec leest de Security Engine geconfigureerde logbronnen en genereert beslissingen op basis van parsers en scenario's; de blokkering zelf wordt echter uitgevoerd door een afzonderlijke remediatiecomponent.

Controleer eerst of de verwachte meldingen überhaupt binnenkomen. Voor een SSH-dienst zijn mislukte aanmeldingen relevant, voor een mailserver de betreffende authenticatieprotocollen en voor een proxy de toegangs- of beveiligingslogboeken. Zichtbare gebeurtenissen op zich zijn nog geen bewijs van een afwerend effect: pas de keten van logboekvermelding, herkende reeks, beslissing en effectieve regel maakt een betrouwbare diagnose mogelijk.

Controleer vervolgens de beslissingen en de geregistreerde component afzonderlijk. Als CrowdSec verdachte gebeurtenissen detecteert, maar er geen remedie-component is gekoppeld of deze niet functioneert, hebben de beslissingen geen gevolgen. In de officiële foutdocumentatie wordt precies dit patroon genoemd als oorzaak van het feit dat de Security Engine wel werkt, maar er geen blokkering plaatsvindt. Detectie is geen blokkering.

Bij webbeveiliging komt er nog een extra controle bij. AppSec maakt deel uit van de logprocessor en filtert HTTP-verzoeken van compatibele webservers. Remediation Components voeren beslissingen door op het gekozen niveau, bijvoorbeeld op de webserver of de reverse proxy. Tijdens het gebruik moet daarom duidelijk blijven of een afwijzing voortkomt uit de HTTP-controle of uit een reeds doorgevoerde beslissing, zodat fouten en valse alarmen gericht kunnen worden onderzocht.

Vals alarm heeft vooral ernstige gevolgen wanneer veel bevoegde personen hetzelfde openbare adres gebruiken. NAT-gateways, mobiele netwerken en CI-systemen kunnen talrijke legitieme inlogpogingen onder één bron-IP-adres bundelen. Kies daarom drempelwaarden, blokkeringsduur en uitzonderingen op basis van daadwerkelijke toegangswegen en zorg ervoor dat beslissingen, inclusief de aanleiding en de duur, traceerbaar zijn, in plaats van een lange blokkeringslijst als succes te beschouwen.

Test wijzigingen eerst met geanonimiseerde historische logbestanden of in een staging-omgeving. Zo kun je controleren of de parsers de beoogde patronen herkennen en of een remediatiemaatregel op het verwachte niveau reageert, zonder de beheerderstoegang in gevaar te brengen. SSHGuard verwerkt systeemlogs en kan communiceren met verschillende firewall-backends; daarom moeten de logbron en de backend in de geïnstalleerde omgeving samen worden bekeken.

Een gecontroleerd proces is geen vervanging voor een penetratietest op het productiesysteem. Documenteer verwachte gebeurtenissen, waargenomen beslissingen en het daaruit voortvloeiende effect van de regels; verwijder daarna testgegevens of laat tijdelijke vermeldingen op de gebruikelijke wijze verlopen. Zo blijven de beschermende werking en mogelijke nevenschade controleerbaar, zonder opzettelijk echte blokkades voor productieve gebruikers te activeren.

Foutopsporing in logbestanden en regels

Begin het opsporen van fouten altijd bij de logbron en werk vervolgens verder door tot aan de afhandeling. Als er geen passende meldingen zijn, kunnen noch een logparser, noch een scenario- of blokkeringslogica betrouwbaar reageren. Controleer daarom de service, de logreader en het daadwerkelijke formaat voordat je drempelwaarden wijzigt of firewallregels in twijfel trekt.

Bij CrowdSec is het foutpatroon duidelijk wanneer gebeurtenissen of beslissingen zichtbaar zijn, maar toegang nog steeds mogelijk blijft: een beslissing wordt niet automatisch door de engine afgedwongen. Controleer of een geschikte remedie-component is geregistreerd, bereikbaar is en daadwerkelijk is gekoppeld aan de firewall, webserver of proxy. Zonder deze component wordt er geen blokkeringsregel toegepast.

Bij SSHGuard ligt de oorzaak vaak hieraan. De tool verzamelt systeemlogs, maar een ongeschikte logreader of een serviceformaat dat afwijkt van het verwachte patroon levert geen bruikbare resultaten op. De voorbeeldconfiguratie in de repository toont mogelijke invoer en opties, maar is afkomstig uit de ontwikkelingsbranch; vergelijk deze met de pakketdocumentatie en de geïnstalleerde versie, in plaats van deze ongewijzigd over te nemen.

Bij nftables controleer je bovendien of de regel in de betreffende chain op de verwachte hook staat, de daadwerkelijke servicepoort omvat en van toepassing is op de benodigde protocolfamilies. De voorbeeldregels scheiden IPv4 en IPv6 via afzonderlijke chains en staan zowel gevestigde als bijbehorende verbindingen en loopback-verkeer toe vóór de poorttoegangen. Een beveiliging die uitsluitend voor IPv4 is geformuleerd, biedt geen dekking voor IPv6; evenzo kan een te strikte limiet legitieme parallelle verbindingen belemmeren.

Een meter beperkt nieuwe verbindingen op basis van een vastgestelde snelheid per bron en kan dynamische set-vermeldingen met een time-out beheren. Dit houdt echter geen rekening met mislukte inlogpogingen. Als een aanval onder de limiet blijft, is een ontbrekende treffer daarom niet per se een fout in de regel, maar kan het een beperking zijn van de gekozen aanpak. Haak, ketting en meetpunt moeten in overeenstemming zijn met het verwachte effect.

Breng wijzigingen één voor één aan en controleer na elke stap opnieuw de log-in, de beslissing en de implementatie. Zorg vóór aanpassingen aan de firewall voor een onafhankelijke noodtoegang, bijvoorbeeld via de console, een bastionhost of een apart beheernetwerk. Dit voorkomt dat een verkeerd geplaatste regel of een foutieve IPv6-toevoeging de enige toegang tot de server blokkeert.

Beslissing op basis van risico en inspanning

Het geschikte alternatief voor Fail2Ban hangt af van het blootgestelde aanvalsoppervlak, niet van een algemene ranglijst. Ga na welke diensten openbaar zijn, of ze aanmeldingen verwerken, welke logbestanden betrouwbaar beschikbaar zijn en wie de configuratie permanent beheert. Een databasedienst die niet openbaar toegankelijk is, heeft geen internetblokkeerlijst nodig; het openstellen van de dienst voor het netwerk blijft de belangrijkste veiligheidsbeslissing.

Voor een overzichtelijke enkele server met herhaaldelijke SSH- of e-mail-inlogfouten kan SSHGuard een gestroomlijnde, op logbestanden gebaseerde aanpak zijn. Het project is gericht op bescherming tegen brute-force-aanvallen op SSH en andere diensten en maakt daarvoor gebruik van systeemlogboeken en firewall-backends. De concrete logboekdekking en de blokkeringsparameters moeten echter wel aansluiten bij de geïnstalleerde distributie en het dienstformaat.

Als vooral snelle nieuwe verbindingen moeten worden afgeremd, is een gematigde nftables-ratelimiet een directe aanvulling. Meter-regels kunnen het aantal verbindingen per bronadres beperken; regels met over Verkeer boven de vastgestelde limiet wordt afgewezen. Dit gebeurt vóór het inloggen, maar geeft geen semantische indicatie of het inloggen is mislukt of dat een HTTP-verzoek kwaadaardig was.

CrowdSec is geschikt wanneer logboekanalyse en handhaving op meerdere niveaus of op meerdere hosts moeten worden gecoördineerd. De architectuur scheidt de engine en de remediatiecomponenten; gedistribueerde varianten met een centrale lokale API of gecentraliseerde logbestanden zijn mogelijk. Dit voordeel brengt extra eisen met zich mee op het gebied van machtigingen, bereikbaarheid, segmentatie en een plan voor storingen. Bedrijfsklaarheid is daarom een selectiecriterium naast de functionaliteit.

Bij openbare webtoepassingen volstaat een firewallblokkering niet voor de beoordeling van afzonderlijke HTTP-verzoeken. Hiervoor is een compatibele AppSec-koppeling met passende regels nodig. AppSec maakt deel uit van de Log Processor en filtert de HTTP-verzoeken van compatibele webservers; Remediation Components voeren beslissingen uit op het geselecteerde handhavingspunt. Het is van cruciaal belang of de beveiligingsbehoefte betrekking heeft op verbindingen, authenticatiegebeurtenissen of HTTP-inhoud.

Op IP gebaseerde maatregelen blijven beperkt: botnetten verspreiden pogingen over vele bronnen, langzame aanvallen kunnen onder een bepaalde drempelwaarde blijven, en bij het blokkeren van gedeelde adressen worden onschuldige gebruikers getroffen. Ze verminderen geautomatiseerde ruis, maar zijn geen vervanging voor tijdige patches, beperkte beheerderstoegang en sterke authenticatie. Met name bij SSH hebben op sleutels gebaseerde aanmeldingen en beperkte bereikbaarheid voorrang boven steeds agressievere blokkeringsdrempels.