Serverfirewall instellen: je server beschermen tegen DDoS en schadelijke bots

Het instellen van een serverfirewall betekent dat je alleen de noodzakelijke poorten openlaat en alle andere toegang blokkeert; het vormt de eerste verdedigingslinie tegen DDoS-aanvallen, brute force pogingen en schadelijk botverkeer. In de praktijk is het doel om SSH-toegang te beperken, webdiensten gecontroleerd open te stellen, verdachte verzoeken te beperken via rate limiting, logs te monitoren en indien mogelijk het verkeer via hogere lagen zoals CDN of WAF te filteren voordat het de server bereikt.

Vanaf het moment dat je een webserver aan het internet koppelt, word je binnen enkele minuten geconfronteerd met portscans, SSH-probeerpogingen, kwetsbaarheidsbots en nep user agents. Vooral voor omgevingen met WordPress, e-commerce, panels, API’s of game-servers is een firewall geen luxe maar een vereiste om continuïteit te waarborgen. In deze gids bouwen we stap voor stap een firewall-architectuur voor Linux-servers; we behandelen UFW, firewalld, nftables, Fail2ban, webapplicatie-firewalls en methoden om DDoS-aanvallen te beperken.

We beginnen met een belangrijke waarheid: een lokale serverfirewall kan grootschalige DDoS-aanvallen niet volledig stoppen. Bij aanvallen van 20 Gbps, 80 Gbps of hoger kan de datacenter- of netwerkinfrastructuur al overbelast raken voordat pakketregels in het besturingssysteem worden verwerkt. Daarom is een gelaagde beveiligingsaanpak cruciaal: DDoS-bescherming op provider-niveau, CDN/WAF, besturingssysteem-firewall, applicatie-level rate limiting en regelmatige loganalyse moeten samenwerken. Meer informatie over geschikte infrastructuren vind je op de Hostragons VPS en VDS server oplossingen pagina, en voor veilige webhostingopties op de Hostragons web hosting pakketten pagina.

Wat doet een serverfirewall precies?

Een serverfirewall filtert netwerkverkeer op basis van bron-IP, doel-IP, poort, protocol, verbindingsstatus en soms pakketkenmerken. Simpel gezegd: voor je website moeten poorten 80 en 443 openstaan, maar de databasepoort 3306 mag niet publiek toegankelijk zijn. In plaats van iedereen toegang te geven tot poort 22 (SSH), is het veiliger alleen verbindingen vanaf het IP-adres van je kantoor of VPN toe te staan.

De primaire functie van een firewall is niet om alle aanvallen magisch te neutraliseren, maar om het aanvalsoppervlak zo klein mogelijk te houden. Hoe kleiner de aanvalsoppervlakte, hoe minder opties een aanvaller heeft. Een pas geïnstalleerde Linux-server kan bijvoorbeeld SSH, webpanel, mail, database, monitoring-agent en testservices tegelijk open hebben, elk met eigen risico’s. Een goed ingestelde firewall hanteert het principe “default deny, allow wat nodig is”.

DDoS en botverkeer begrijpen

Waarom zijn DDoS-aanvallen anders?

DDoS (Distributed Denial of Service) aanvallen proberen een dienst ontoegankelijk te maken door enorme hoeveelheden verkeer uit diverse bronnen te genereren. Dit kan netwerkbandbreedte vol laten lopen, server-CPU en RAM uitputten, of dure applicatieprocessen activeren. Bijvoorbeeld, een kleine applicatieserver die 50.000 HTTP-verzoeken per seconde ontvangt kan onbereikbaar worden door beperkte PHP-FPM, Node.js of database-connector capaciteiten, ook als de netwerkverbinding niet volloopt.

Zijn bots altijd kwaadwillend?

Nee. Googlebot, Bingbot en sommige monitoring bots zijn nuttig. Schadelijke bots voeren echter scans uit op beheerpanelen, zoeken naar open directories, spammen formulieren, kopiëren content, misbruiken XML-RPC, maken nepaccounts aan en proberen in te loggen. Botbeheer betekent dus niet alle bots blokkeren, maar gedrag analyseren en onderscheiden. Hoge foutpercentages, extreem veel verzoeken in korte tijd, niet-natuurlijke headers en verdachte URL-patronen zijn belangrijke signalen.

Checklist vóór je begint met de firewallconfiguratie

Je grootste risico bij het aanpassen van firewallregels op een live server is jezelf buitensluiten. Daarom is een goede voorbereiding essentieel. Deze checklist is een veilige basis voor productieomgevingen:

• Sluit je actieve SSH-sessie niet af; test met een tweede terminal.
• Zorg dat je via de console, VNC of recovery modus van je provider toegang hebt.
• Bekijk welke poorten openstaan met commando’s als ss -tulpn of netstat -tulpn.
• Noteer welke poorten web-, mail-, DNS-, database-, panel- en monitoringdiensten gebruiken.
• Gebruik je IPv6? Plan ook firewallregels voor IPv6.
• Voer eerst allow-regels in, daarna deny-regels.
• Zorg dat de regels persistent zijn en na herstart blijven bestaan.

Een typische webserver hoeft meestal alleen poorten 80, 443 en een beperkte SSH-poort open te hebben. Mailpoorten zoals 25, 465, 587 of 993 zijn niet nodig als je geen mailserver draait. Databasepoorten 3306 (MySQL/MariaDB) of 5432 (PostgreSQL) moeten gesloten zijn voor extern internet als de database alleen lokaal wordt gebruikt.

Welke firewalltool kies je?

In de Linux-wereld zijn er meerdere tools die grotendeels dezelfde kernel filtering gebruiken, maar elk met eigen gebruiksgemak. Voor beginners is UFW eenvoudig en snel. Op zakelijke systemen of Red Hat-achtige distributies is firewalld gangbaar. Voor geavanceerde scenario’s biedt nftables een modern, flexibel framework. Onderstaande tabel helpt bij de keuze.

Stap-voor-stap firewallconfiguratie

1. Identificeer open poorten en services

De eerste stap is inzicht krijgen in welke services openstaan. Met ss -tulpn zie je welke processen op welke poorten luisteren. Bijvoorbeeld als nginx op 0.0.0.0:80 en 0.0.0.0:443 luistert, accepteert de webserver verkeer op alle netwerkinterfaces. Als MariaDB op 0.0.0.0:3306 luistert is dat meestal een risico; databases horen idealiter op 127.0.0.1 te draaien.

De vuistregel: geen enkele service die niet publiek toegankelijk hoeft te zijn, mag op 0.0.0.0 luisteren. Pas eerst configuraties aan en sluit daarna met de firewall af. Zo blijft de service niet per ongeluk open staan als de firewall faalt.

2. Zet de standaard policy op “deny”

Veilige firewallregels blokkeren standaard binnenkomend verkeer, en laten uitgaand verkeer toe waar nodig. Dit voorkomt dat nieuwe of verkeerd geconfigureerde services onverwacht publiek komen te staan. Bij UFW op een Ubuntu-server is het patroon: eerst SSH toestaan, daarna poorten 80 en 443, dan standaard inkomend verkeer blokkeren en firewall activeren.

Voorbeeld: geef alleen je beheerders-IP toegang tot SSH, laat webverkeer toe, sluit onnodige poorten en activeer de firewall. SSH niet toestaan voordat de firewall actief is, is een veelgemaakte fout die kan leiden tot verlies van toegang.

3. Beperk SSH-toegang

SSH is een geliefd doelwit voor aanvallers. Een server met poort 22 open kan honderden tot duizenden wachtwoordpogingen per dag zien. De veiligste aanpak is SSH alleen toegankelijk maken vanaf specifieke IP-adressen. Gebruik je een vast IP? Sta alleen dat IP of je VPN toe. Zonder vast IP is het minimaal noodzakelijk om key-based authentication te gebruiken en wachtwoordtoegang uit te schakelen.

• Schakel directe root-login uit.
• Gebruik SSH-sleutels in plaats van wachtwoorden.
• Beperk gebruikers met AllowUsers of AllowGroups.
• Gebruik Fail2ban om mislukte pogingen automatisch te blokkeren.
• Beperk panelpoorten ook per IP als je een beheerinterface gebruikt.

Poort veranderen helpt bots verminderen, maar echte veiligheid bereik je met IP-limieten, sterke authenticatie en logmonitoring.

4. Open webpoorten gecontroleerd

Voor de meeste websites zijn poorten 80 en 443 nodig. Tegenwoordig is poort 443 (HTTPS) de hoofdpoort, terwijl 80 alleen gebruikt wordt om door te verwijzen naar HTTPS. Websites zonder SSL-certificaat verliezen vertrouwen en scoren lager in zoekmachines. Hier is een mooie gelegenheid voor een Hostragons SSL certificaten interne link naar een veilige HTTPS-configuratie.

Let bij het openstellen van webpoorten op echte IP-verkeer. Gebruik je een CDN of reverse proxy? Dan is het veiliger om poorten 80 en 443 alleen te openen voor de IP-ranges van het CDN, zodat aanvallers het echte serveradres niet direct kunnen bereiken.

5. Sluit database- en interne services af

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB en vergelijkbare diensten die publiekelijk bereikbaar zijn, vormen een groot beveiligingsrisico. Ontbrekende authenticatie bij Redis, onbevoegde toegang bij Elasticsearch of open beheerpoorten bij MongoDB hebben in het verleden tot datalekken geleid. Deze services moeten bij voorkeur alleen op localhost of een afgesloten netwerkinterface luisteren.

Bijvoorbeeld: een WordPress-site op dezelfde server heeft voldoende aan een databaseverbinding via 127.0.0.1. Bij gescheiden applicatie- en database-servers geef je alleen het interne IP van de app-server toegang. Poort 3306 of 5432 openzetten voor het internet is een bekende fout waar bots constant op scannen.

6. Gebruik Fail2ban tegen brute force

Fail2ban scant logbestanden en blokkeert IP's na meerdere mislukte inlogpogingen tijdelijk. Er zijn configuraties voor SSH, nginx, Apache, Postfix, Dovecot, WordPress login en paneldiensten. Een eenvoudige start is om IP’s die binnen 10 minuten 5 keer foutief inloggen op SSH een uur te blokkeren.

Wees voorzichtig met te strenge regels; onjuiste logpatronen kunnen legitieme gebruikers blokkeren. Begin met milde instellingen, monitor logs en verscherp de regels geleidelijk.

7. Voeg rate limiting en verbindinglimieten toe

Rate limiting op OS-niveau kan helpen bij DDoS- en botaanvallen. Bijvoorbeeld: beperk het aantal nieuwe verbindingen per seconde per IP. Webservers kunnen hiervoor functies gebruiken zoals nginx’s limit_req en limit_conn modules, Apache’s mod_evasive of soortgelijke tools. Applicaties moeten ook limieten hanteren voor loginpagina’s, zoekfuncties, winkelwagens, betalingen en API endpoints.

Een concreet voorbeeld: een loginpagina kan 10 pogingen per minuut per IP toestaan, terwijl een zoekfunctie 2 tot 5 verzoeken per seconde aankan. API’s gebruiken vaak tokens met gebruiker-gebaseerde limieten, IP-limieten en gedragsanalyse om te voorkomen dat een aanvaller met wisselende IP’s de limieten omzeilt.

Voorbeeld van een veilige UFW-configuratie

Op een Ubuntu- of Debian-webserver kun je eenvoudig starten door eerst open services te controleren, SSH alleen vanaf je beheerders-IP toe te staan, poorten 80 en 443 open te zetten, inkomend verkeer standaard te blokkeren en UFW te activeren. Als je geen statisch IP hebt, kun je tijdelijk SSH openzetten voor alle IP’s en later overstappen op VPN of een statisch IP.

Stel je beheerders-IP is 203.0.113.10. SSH mag alleen vanaf dit IP, webverkeer op poort 80 en 443 is voor iedereen toegankelijk, database, Redis, panel- en testpoorten zijn gesloten. Dit is een goede basis voor veel kleine tot middelgrote zakelijke websites. Voor correcte domein- en DNS-instellingen is er een handige Hostragons domeinnaam controle en registratie link.

firewalld en zonebeheer

Op AlmaLinux, Rocky Linux en RHEL-systemen is firewalld gebruikelijk. Het werkt met zones: public voor internettoegang, trusted voor betrouwbare netwerken, drop om ongewenst verkeer stilletjes te negeren. Belangrijk is het verschil tussen runtime en permanente regels. Runtime regels gelden direct maar verdwijnen na reboot, permanente regels blijven bewaard maar vereisen reload.

In zakelijke omgevingen maakt firewalld het makkelijk om services per zone toe te wijzen. Zo kun je http en https openzetten in public, en SSH alleen toestaan vanaf specifieke IP’s. Als beheer-, backup- en gebruikersnetwerken aparte interfaces gebruiken, verhogen zones overzicht en veiligheid.

CDN, WAF en DDoS-bescherming op provider-niveau

De lokale firewall beslist pas nadat pakketten de server bereiken. Bij grote DDoS-aanvallen is het doel om verkeer vóór de server te filteren. Daarom zijn CDN, WAF en provider-DDoS bescherming essentieel. Een CDN serveert statische content vanaf edge-locaties, een WAF filtert kwaadaardige applicatieverzoeken en de provider absorbeert of filtert volumineuze netwerk-aanvallen.

Het ideale scenario: je DNS wijst naar het CDN, je echte server-IP is verborgen, je firewall accepteert alleen verkeer van CDN-IP-ranges op poorten 80 en 443 en beheerpoorten zijn alleen bereikbaar via VPN of vast IP. Zo verminder je directe aanvallen op je server en filter je botverkeer al in de rand. Voor meer info over webbeveiliging en performance zijn er gidsen voor websiteversnelling en beveiliging beschikbaar.

Applicatielaagmaatregelen tegen bots

Botbestrijding is meer dan alleen IP-blokkades. Moderne bots gebruiken proxies, mobiele netwerken, datacenter-IP’s en wisselen user agents. Een gedragsgerichte aanpak is daarom noodzakelijk. Analyseer veelvuldige loginpogingen vanaf hetzelfde IP, scans die 404’s genereren, overmatig gebruik van wp-login.php of xmlrpc.php, afwijkende klikpatronen en verdachte headers.

• Gebruik rate limiting op login- en registratieformulieren.
• Beperk onnodige XML-RPC toegang.
• Bescherm beheerpanelen via aparte URL’s, IP-beperkingen en multi-factor authenticatie.
• Filter verdachte user-agents en referrers via WAF-regels.
• Gebruik CAPTCHA of onzichtbare botdetectie mechanismen met mate.
• Voeg API-endpoints beveiliging toe met sleutels, handtekeningen, quota en timestamps.

Botbeheer moet gebruikerservaring niet schaden. Te veel CAPTCHA’s, agressieve blokkades of foutieve landblokkades kunnen legitieme bezoekers afschrikken. Meten, testen en geleidelijke aanscherping is de beste aanpak.

Logmonitoring en alarmregels

Een firewall is geen set-and-forget systeem; het moet continu gemonitord worden. Controleer auth.log of secure op SSH-pogingen, nginx access logs op abnormale verzoeken, error logs op toegenomen 404 of 500 fouten, en houd CPU- en connectiestatistieken in de gaten. Een eenvoudige alarmregel kan je minuten extra geven bij een aanval.

Voorbeeld drempels: meer dan 100 404’s van hetzelfde IP in 5 minuten, meer dan 20 loginpogingen in 1 minuut, CPU langer dan 10 minuten boven 90%, connecties drie keer hoger dan normaal. Deze waarden verschillen per site, belangrijk is dat je je normale verkeer leert kennen.

Veelvoorkomende fouten en hoe ze te voorkomen

• Firewall activeren zonder SSH-toegang toe te staan: je raakt buitengesloten bij remote servers. Test altijd met een tweede sessie.
• IPv6 vergeten: IPv6 kan open blijven terwijl IPv4 dichtstaat.
• Database openstellen voor internet: poorten als 3306, 5432, 6379 en 9200 worden continu gescand door bots.
• CDN gebruiken maar echte IP open laten: aanvallers kunnen direct je server bereiken.
• Regels aanpassen zonder documentatie: het wordt lastig om bij problemen te achterhalen waarom iets is ingesteld.
• Geen noodtoegang regelen: bij verkeerde regels zonder consoletoegang kan downtime lang duren.

Praktisch voorbeeld van een firewallbeleid

Voor een kleine zakelijke website kan het beleid als volgt zijn: inkomend verkeer standaard geblokkeerd; poort 443 open voor alle bezoekers; poort 80 alleen voor HTTPS-redirect; SSH alleen via VPN of vast beheer-IP; database alleen lokaal of via intern netwerk; bij gebruik van CDN zijn poorten 80 en 443 enkel geopend voor CDN IP-ranges; Fail2ban monitort SSH en web loginpogingen; logs worden centraal verzameld en geanalyseerd.

Voor een middelgrote webshop komen daar bij: IP-whitelists voor betaalprovider callbacks, beheerpanel achter VPN, gebruikersquota op API’s, WAF-regels tegen SQL-injectie en XSS, tijdelijke filters op landen of ASN’s. Het is belangrijk dat zo’n plan schriftelijk is vastgelegd zodat je in een aanvalssituatie snel kunt handelen volgens vooraf bepaalde procedures.

Testen: werken de regels echt?

Na installatie moet je testen. Voer een portscan uit vanaf een ander netwerk, controleer dat SSH alleen werkt vanaf toegestane IP’s, kijk of de website via HTTPS bereikbaar is, en verifieer dat databasepoorten gesloten zijn. Gebruik je een CDN? Probeer dan direct het echte server-IP aan te spreken en controleer dat dat geblokkeerd wordt.

Vermijd agressieve scans die productie kunnen verstoren; het doel is veiligheid verifiëren. Maak ook altijd een back-up van je firewallregels na wijzigingen, zodat je bij problemen eenvoudig kunt terugkeren naar een werkende configuratie.

Onderhoud en updates

Serverbeveiliging is geen eenmalige klus maar een continu proces. Bij nieuwe services moet je poorten herzien, bij verwijderde services regels verwijderen, beveiligingsupdates tijdig doorvoeren en logs regelmatig beoordelen. Maandelijks een poortcontrole en elk kwartaal een review van firewallregels is een goede gewoonte.

Ook back-ups maken hoort bij een compleet beveiligingsplan. DDoS kan je verbinding verstoren, maar ransomware of ongeautoriseerde toegang kan data doen verdwijnen. Denk aan veilige hosting, SSL, domeinbeheer en back-ups als één geheel. Hier zijn ook Let op bij het kiezen van veilige hosting en hoe SSL certificaat installatie te doen handige vervolgartikelen.

Conclusie

Het instellen van een serverfirewall maakt je server niet volledig onzichtbaar voor DDoS en bots, maar verkleint het aanvalsoppervlak aanzienlijk, vermindert het risico op ongeautoriseerde toegang en geeft je meer controle bij incidenten. De beste resultaten krijg je met een combinatie van DDoS-bescherming op provider-niveau, CDN/WAF, strikte poortregels, SSH-beperkingen, Fail2ban, rate limiting en regelmatige logmonitoring.

Start je een nieuw project? Plan je firewallbeleid dan vanaf het begin; achteraf aanpassen is lastiger. Met Hostragons kun je server, hosting, domein en SSL combineren en zo een robuuste webomgeving bouwen. Begin met een eenvoudige checklist: sluit onnodige poorten, beperk SSH, verplicht HTTPS en controleer logs.

Veelgestelde vragen

Kan een serverfirewall DDoS-aanvallen volledig voorkomen?

Nee. Een lokale firewall kan kleine of protocol-gerichte aanvallen verminderen, maar bij grote DDoS-aanvallen is DDoS-bescherming via je provider, CDN en WAF noodzakelijk.

Welke poorten moeten openstaan op een webserver?

Meestal alleen poorten 80 en 443. SSH is alleen open voor beheerders-IP’s. Database- en interne servicepoorten moeten gesloten zijn voor het internet.

Moet ik UFW of firewalld gebruiken?

Voor Ubuntu en Debian is UFW eenvoudiger. Voor AlmaLinux, Rocky Linux en RHEL is firewalld gebruikelijk. Voor geavanceerde situaties is nftables een optie.

Volstaat IP-blokkade om botverkeer te stoppen?

Meestal niet. Moderne bots gebruiken wisselende IP’s en proxies. Naast IP-blokkades zijn rate limiting, WAF-regels, gedragsanalyse, CAPTCHA en applicatiequota nodig.

Wat is de grootste risico bij firewallconfiguratie?

Je eigen SSH-toegang verliezen door een foutieve regel. Daarom altijd eerst SSH-toegang toestaan, een tweede sessie testen en console toegang van je provider gereed hebben.