Ga naar de inhoud 
Firewall iptables en UFW bepalen welke verbindingen een webserver accepteert en welke ik blokkeer - dit bepaalt het aanvalsoppervlak en mislukkingen. In dit praktische artikel laat ik duidelijke regels, veilige standaardinstellingen en geteste commando's zien voor SSH, HTTP(S), databases, logging, IPv6 en Docker - direct toepasbaar op productieve hosts.
Centrale punten
De volgende belangrijke punten geven me een snelle oriëntatie voordat ik begin met de configuratie.
- Beperkend Start: Standaard weigeren voor inkomend, specifiek openen
- SSH Eerst toestaan: Geen risico op toegang
- UFW als interface: eenvoudige syntaxis, iptables op de achtergrond
- Loggen activeren: Regels controleren, aanvallen herkennen
- Volharding verzekeren: Handhaaf regels voor herstarts
Basis: iptables en UFW in een oogopslag
Ik vertrouw op iptablesals ik fijnmazige controle nodig heb over pakketten, ketens en overeenkomsten. Ik gebruik UFW als ik snel betrouwbare regels wil toepassen die intern eindigen als iptables regels [1]. Dit stelt me in staat om eenvoudige commando's te combineren met de kracht van het Linux netfilter zonder me te verliezen in de details. Voor webservers betekent dit: ik bouw een duidelijk filter voor Apache, Nginx of Node zodat alleen het gewenste verkeer aankomt [2]. Deze scheiding verkleint het aanvalsoppervlak en zorgt ervoor dat aanvallen vaker mislukken.
Beide tools vullen elkaar aan en ik beslis welke bij de situatie past. UFW scoort met schone leesbaarheid, vooral op Ubuntu en Debian [3]. iptables geeft me uitgebreide opties, bijvoorbeeld voor NAT, specifieke interfaces en complexe overeenkomsten. Belangrijk: ik documenteer mijn regels beknopt zodat onderhoud later eenvoudig is. Als je meer wilt weten over het beveiligingsconcept, kun je hier een duidelijke inleiding vinden: Firewall als beschermend schild.
Start configuratie: Stel standaard beleidsregels veilig in
Ik begin met Standaard-Policies: Inkomend blokkeren, uitgaand toestaan. Zo voorkom ik dat nieuwe diensten onbedoeld toegankelijk zijn. Ik sta altijd loopback toe zodat interne processen stabiel werken. Ik accepteer bestaande verbindingen om annuleringen te voorkomen. Deze volgorde minimaliseert fouten bij het activeren van de firewall [2][5].
Ik gebruik UFW om de basis met slechts een paar commando's in te stellen. Daarna controleer ik de status in detail om typefouten meteen op te merken. Voor bijzonder gevoelige hosts beperk ik ook de uitgaande poorten. Dit vermindert het risico op datalekken als een service gecompromitteerd is. Ik gebruik de volgende commando's vaak:
# UFW: Standaard regels
sudo ufw standaard inkomend weigeren
sudo ufw standaard uitgaand toestaan
# Alternatief strenger uitgaand beleid
sudo ufw standaard uitgaand weigeren
sudo ufw allow out 53
sudo ufw toestaan 80
sudo ufw toestaan 443
# Status controleren
sudo ufw status verbose
Stateful filtering: toestanden en volgorde
Een schone pakketstroom staat en valt met Conntrack stelt. Ik accepteer gevestigde verbindingen eerst, gooi ongeldige pakketten vroeg weg en laat loopback open. Dit vermindert de belasting en voorkomt bijwerkingen door late drops. Voor iptables stel ik bewust de volgorde in:
# iptables: solide basis
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Altijd loopback toestaan
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Bestaande/geassocieerde verbindingen toestaan
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Laat ongeldige pakketten vroegtijdig vallen
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Met UFW wordt intern al rekening gehouden met ESTABLISHED/RELATED. Ik let er ook op of ik de voorkeur geef aan DROP (stil) of AFWIJZEN (actief, snellere failover). Voor interne netwerken geef ik de voorkeur aan REJECT, in het openbare netwerk meestal aan DROP.
Essentiële regels voor webservers: SSH, HTTP en HTTPS
Ik schakel in SSH eerst, anders sluit ik mezelf gemakkelijk buiten. Daarna sta ik HTTP en HTTPS toe, zodat de webserver toegankelijk is. Ik stel alleen de poorten in die ik echt nodig heb. Later voeg ik optioneel rate limiting of Fail2ban toe om brute login pogingen te beteugelen. Ik controleer elke verandering onmiddellijk met status of list commando's.
Ik hou de commando's hiervoor eenvoudig. UFW biedt sprekende aliassen voor webpoorten, wat de leesbaarheid vergroot. Met iptables kan ik exacte poorten en protocollen instellen. Ik sla de iptables-regels achteraf op zodat ze de herstart overleven. Dit zijn de minimale stappen:
# SSH
sudo ufw toestaan 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# HTTP/HTTPS
sudo ufw toestaan http
sudo ufw toestaan https
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Beveiligde SSH: Selectief beperken en openen
Naast het loslaten demp ik aanvallen met Snelheidsbeperking of witte lijsten. UFW biedt eenvoudige bescherming:
# SSH-snelheidsbeperking (UFW)
sudo ufw limit 22/tcp commentaar "SSH-snelheidslimiet".
Ik stel fijnere limieten in met iptables. Dit voorkomt het massaal raden van wachtwoorden zonder legitieme beheerders uit te sluiten:
# SSH: Verbindingspogingen per bron beperken
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --update --seconden 60 --hitcount 10 -j DROP
Waar mogelijk sta ik alleen SSH toe van Beheer IP-adressen en werken met SSH-sleutels. Het veranderen van poorten is geen vervanging voor beveiliging, maar het kan ruis verminderen. Ik documenteer de uitzonderingen en controleer ze regelmatig.
Databases beveiligen en IP-bronnen beperken
Ik open nooit databasepoorten globaal, maar alleen lokale of voor gedefinieerde bron IP-adressen. Dit voorkomt dat scanners open MySQL, PostgreSQL of MongoDB poorten vinden. Voor lokale apps is 127.0.0.1 voldoende als doel; ik controleer externe beheerderstoegang strikt via IP. Ik documenteer wijzigingen kort, bijvoorbeeld in de serverwiki. Dit bespaart me tijd tijdens audits.
Ik gebruik de volgende voorbeelden vaak in projecten. Ik controleer vooraf de juistheid van elk toegestaan IP. UFW staat een schone "van-naar" notatie toe, iptables implementeert technisch dezelfde logica. Ik gebruik extra toestaan regels voor tijdelijke onderhoudsvensters en verwijder ze achteraf. Dit houdt de interface klein:
# Alleen lokaal: MySQL
sudo ufw toestaan van 127.0.0.1 naar elke poort 3306
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT
# Eén IP toestaan
sudo ufw toestaan van 203.0.113.10
iptables -A INPUT -s 203.0.113.10 -j ACCEPT
# Sta poort toe voor specifiek IP
sudo ufw allow van 10.1.2.3 naar elke poort 4444
iptables -A INPUT -p tcp -s 10.1.2.3 --dport 4444 -j ACCEPT
# Blokkeer bekende aanvallers
sudo ufw weigeren van 192.0.2.24
iptables -A INPUT -s 192.0.2.24 -j DROP
Schone afhandeling van logboekregistratie, interfaces en IPv6
Ik schakel in Loggen om regels te controleren en opvallend verkeer te herkennen. Niveau "on" in UFW is voldoende voor de meeste hosts, hogere niveaus gebruik ik alleen selectief. Ik analyseer logs met journalctl, fail2ban of SIEM tools. Hierdoor kan ik patronen herkennen van scans of brute force pogingen. Bij afwijkingen pas ik de regels direct aan [2].
Ik koppel regels vaak aan een specifieke Interfacezoals eth0 in openbare netwerken. Dit voorkomt dat interne netwerken onnodig worden beïnvloed. UFW kan "toelaten op eth0 op elke poort 80", iptables gebruikt -i voor invoerinterfaces. Voor IPv6 controleer ik de activering in /etc/default/ufw voor "IPV6=yes" en gebruik ik ip6tables voor native regels [2]. Deze scheiding voorkomt hiaten met dual-stack hosts.
ICMP en ICMPv6: Toegankelijkheid zonder hiaten
Ik laat noodzakelijke ICMP-types zodat pad MTU ontdekking, timeouts en diagnostiek werken. ICMP is geen vijand, maar de kern van het IP-protocol. Ik beperk alleen overmatige echo's.
# IPv4: Echo-request beperken, belangrijke ICMP-types toestaan
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/seconde --limit-burst 20 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
# UFW: ICMP in het algemeen toestaan (fijnafstelling in before.rules mogelijk)
sudo ufw toestaan in proto icmp
Op IPv6 ICMPv6 is absoluut noodzakelijk (Neighbour Discovery, Router Advertisement). Ik sta de core types toe en beperk echo requests:
# IPv6 (ip6tables)
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type router-advertising -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-solicitation -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type buren-aankondiging -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type echo-request -m limit --limit 5/seconde --limit-burst 20 -j ACCEPT
Uitgaande beperking en NAT/masquerading correct gebruiken
Ik beperk uitgaand verkeer wanneer ik Risicoprofiel en naleving. Ik sta DNS en HTTPS toe en blokkeer al het andere, behalve voor gedefinieerde doelen. Hierdoor worden minder gegevens ge-exfiltreerd als een service wordt gekaapt. Ik maak gedefinieerde uitzonderingen voor applicaties die updates of API's nodig hebben. Ik documenteer deze uitzonderingen duidelijk en controleer ze regelmatig.
Voor routeringsinstellingen gebruik ik NAT/Masquerading via UFW-Before-Rules of raw met iptables. Ik let op de volgorde van de ketens zodat pakketten correct worden herschreven. Na wijzigingen test ik de connectiviteit en latencies. Voor productiesystemen plan ik een onderhoudsvenster en maak ik een back-up van de configuratie. Hierdoor kan ik de netwerkpaden traceerbaar houden [7].
Uitgaande details: systeemservices en protocollen
Met een strikt uitgaand beleid sta ik specifiek het volgende toe DNS (53/udp), HTTPS (443/tcp) en indien nodig NTP (Voor mailservers voeg ik 25/tcp en 587/tcp toe. Ik los domein-gebaseerde uitzonderingen niet op pakketniveau op, maar via proxies of applicatielogica.
# UFW: typische systeemdiensten
sudo ufw allow out 123/udp # NTP
sudo ufw allow out 25/tcp # SMTP - alleen als mailserver
sudo ufw allow out 587/tcp # Submission - alleen indien nodig
# iptables: specifiek toestaan
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT
Docker en firewalls: valkuilen vermijden
Docker stelt zijn eigen iptables-regels die mijn beleid kunnen beïnvloeden. Daarom controleer ik de NAT en FORWARD ketens na elke compose of daemon start. Ik laat expres blootgestelde poorten vrij en vermijd "-p 0.0.0.0:PORT". In plaats daarvan bind ik ze aan het management IP of de reverse proxy. Dit houdt de aanvalsvector kleiner en zichtbaarder [1].
Ik houd host firewalls actief ondanks Docker. Ik controleer ook beveiligingsgroepen op infrastructuurniveau, indien beschikbaar. Bij conflicten tussen UFW en Docker gebruik ik gedocumenteerde workarounds of stel ik regels in DOCKER-USER. Het is belangrijk om duidelijke verantwoordelijkheden te hebben: host blokkeert altijd, containers openen alleen expliciet. Deze volgorde voorkomt onbewuste releases.
# DOCKER-USER: dwing globaal hostbeleid af vóór Docker-regels
iptables -N DOCKER-USER 2>/dev/null || true
iptables -I DOCKER-USER -s 192.0.2.24 -j DROP
iptables -A DOCKER-USER -j RETURN
Fijne instellingen voor UFW: Sequence, profielen en gerouteerd verkeer
Als precisie telt, gebruik ik "invoegen", "genummerd"en app-profielen. Zo houd ik de regelreeks schoon en gebruik ik geteste servicedefinities.
# Controlevolgorde
sudo ufw insert 1 deny in van 198.51.100.0/24
# Genummerde weergave en gerichte verwijdering
sudo ufw status genummerd
sudo ufw verwijderen 3
# App profielen (bijv. Nginx Full)
sudo ufw app lijst
sudo ufw app info "Nginx Full"
sudo ufw toestaan "Nginx Full"
# Standaard routed verkeer blokkeren (doorsturen)
sudo ufw standaard weigeren gerouteerd
Complexere uitzonderingen sla ik op in voor.regels respectievelijk na.regels. Daar kan ik ICMP finetuning of NAT precies plaatsen zonder de leesbaarheid van de standaardregels te verliezen.
Persistente regels: Opslaan en herstellen
Met UFW-regels zijn hardnekkig en automatisch herstarten overleven. Dit vereenvoudigt het beheer op Debian/Ubuntu hosts enorm. Met iptables sla ik de regels op na wijzigingen en herstel ze bij het opstarten. Ik gebruik hiervoor iptables-save/restore of netfilter-persistent. Zonder deze stappen verlies ik anders wijzigingen na een herstart [5].
Ik test de persistentie systematisch: plan een reboot en controleer dan de status. Als de tellers en ketens correct zijn, is de configuratie solide. Als er regels ontbreken, corrigeer ik het laadpad in de init of systemd context. Deze routine voorkomt verrassingen tijdens onderhoud. Documentatie en back-up van de regelbestanden ronden de procedure af.
# Debian/Ubuntu: Persistentie voor iptables
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent opslaan
# Handmatige backup
sudo iptables-save | sudo tee /etc/iptables/rules.v4
sudo ip6tables-save | sudo tee /etc/iptables/rules.v6
# Herstel (indien nodig)
sudo iptables-restore < /etc/iptables/rules.v4
sudo ip6tables-restore < /etc/iptables/rules.v6
Prestaties en bescherming: limieten, sets en kerneltuning
Als de belasting hoog is, verlaag ik het aantal besturingselementen en gebruik ik gerichte Tariefgrenzen. Voor grote bloklijsten werk ik met ipset om de zoektijd te verkorten. Ik gebruik ook systeemgebaseerde beschermingsmechanismen:
# Bevat SYN flood (kernel)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Beperk HTTP verbindingssnelheid per bron IP (voorbeeld)
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW
-m hashlimit --hashlimit-name http_rate --hashlimit-above 50/seconde
--hashlimit-burst 100 --hashlimit-mode srcip -j DROP
Ik houd de grootte van de Conntrack tafel in één oogopslag. Als er veel gelijktijdige verbindingen zijn, verhoog ik nf_conntrack_max, maar test de effecten op voorhand.
Beheer, tests en foutpreventie
Ik vertrek SSH voordat ik "inkomende weigeren" activeer. Vervolgens test ik vanuit een tweede sessie of de toegang stabiel blijft. Ik controleer elke nieuwe regel met "ufw status verbose" of "iptables -L -v". Hierdoor kan ik hit counters herkennen en zien of pakketten landen in de verwachte keten. Ik maak een back-up van de firewallbestanden voordat ik grote wijzigingen aanbreng.
Voor uitgebreide beveiliging combineer ik de firewall met hardening stappen op het systeem. Deze omvatten veilige SSH-instellingen, patchbeheer en minimale services. Ik gebruik graag een praktische gids als checklist: Server hardening voor Linux. Ik herhaal deze controles regelmatig en houd me aan vaste onderhoudsvensters. Dit houdt mijn servers betrouwbaar in vorm.
Geavanceerd testen en observeren
Ik controleer de externe impact met Poortscans van een extern netwerk en intern open sockets verifiëren. Ik controleer de logs in het begin nauwgezet om valse conclusies in een vroeg stadium te herkennen.
# Open contactdozen
ss -lntup
# iptables overzicht compact
sudo iptables -S
sudo iptables -L -v -n
# UFW: gedetailleerde status en logs
sudo ufw status verbose
journalctl -k | grep -i ufw
# Externe controle (vanaf een andere host/netwerk)
nmap -Pn -p 22,80,443
Voor wijzigingen met een hoog risico plan ik een Terugvalniveau aan. Ik werk in Screen/Tmux en stel indien nodig een tijdgestuurde reset in als ik mezelf buitensluit. Na een succesvolle test annuleer ik de terugvalactie weer.
# Voorbeeld: automatische deactivering als noodanker (voorzichtig gebruiken)
echo "ufw disable" | at now + 2 minuten
# Opnieuw verwijderen na succesvolle test: atrm
Vergelijking van hostingproviders: Focus op firewall-integratie
Voor hosting vertrouw ik op Beveiliging dicht bij het platform. Aangepaste beleidsregels, snelle regelimplementaties en goede monitoring betalen zich uit. In de huidige vergelijkingen maakt webhoster.de indruk met netjes geïntegreerde firewallopties en snelle ondersteuning. Degenen die de voorkeur geven aan paneelinstellingen profiteren van duidelijke instructies voor Plesk firewall. De volgende tabel categoriseert de belangrijkste criteria.
| Aanbieder | Firewall-integratie | Prestaties | Steun | Plaatsing |
|---|---|---|---|---|
| webhoster.de | individueel configureren. | Zeer hoog | top | 1 |
| Aanbieder B | Standaard | hoog | goed | 2 |
| Aanbieder C | Standaard | goed | Bevredigend | 3 |
Praktische voorbeelden: Van test naar productieregel
Ik begin elke regelset in de Scherm of in een tweede SSH-sessie. Op die manier kan ik mezelf nog redden in het geval van een bedieningsfout. Pas als een testhost goed draait, pas ik regels toe in productie. Terugkeerpadregels en een terugdraaiplan geven me extra zekerheid. Aan het einde documenteer ik wijzigingen beknopt in het change log.
Ik gebruik terugkerende bouwstenen voor webservers: SSH toestaan, HTTP/S vrijgeven, interne poorten lokaal binden, aanmelden, ICMP beperken, overbodige protocollen blokkeren. Daarna zorg ik voor IPv6-spiegelregels zodat er geen gaten overblijven. Docker-ketens controleer ik altijd apart omdat ze hun eigen paden instellen. Tot slot valideer ik de toegang via externe controles en monitoring. Dit houdt de interface schoon en traceerbaar [1][2].
Samenvatting voor admins
Met duidelijke Regels en een paar commando's, beveilig ik betrouwbaar webservers. Inkomende standaard weigeren, SSH eerst, HTTP/S vrijgeven - dit vormt de stabiele basis. Database poorten alleen lokaal of via whitelist, logging actief, IPv6 observeren, docker ketens controleren. Persistente opslag en regelmatige tests voorkomen vervelende verrassingen. Deze routine houdt services toegankelijk en vermindert risico's aanzienlijk.
Of ik UFW of direct iptables gebruik, een duidelijk, zuinig beleid is cruciaal. Ik documenteer kort, controleer regelmatig en beperk uitzonderingen tot een minimum. Uitgaande beperking houdt onnodige verbindingen tegen en beperkt de schade in geval van compromittering. Met een geoefend oog op logs herken ik afwijkingen sneller en reageer ik adequaat. Dit houdt de webserver veerkrachtig en het aanvalsoppervlak klein.
