iptables Firewall: praktische gids voor Linux-servers

Als je een gameserver, een webapplicatie of een Discord-bot draait, wordt je machine gescand vanaf het moment dat je hem aan het internet blootstelt. Een iptables firewall laat je precies bepalen welk verkeer binnenkomt en naar buiten gaat door de pakketfilterlaag (Netfilter) in de Linux-kernel aan te sturen: je opent alleen de poorten die je nodig hebt en weigert al het andere stilletjes. In deze gids bouwen we stap voor stap een veilige set regels op, schrijven we poortregels en filteren we de meest voorkomende aanvallen.

Hoe iptables werkt: chains en tables

iptables ordent regels in tables en chains (ketens). Voor dagelijks firewallwerk volstaan de filter-tabel en drie chains:

• INPUT — pakketten die binnenkomen bij de server (hier zit onze bescherming).
• OUTPUT — pakketten die de server verlaten.
• FORWARD — pakketten die via de server naar een andere bestemming worden gerouteerd (router/Docker-scenario's).

Elk pakket loopt de chain van boven naar beneden door; het target van de eerste regel die matcht wint: ACCEPT (toestaan), DROP (stilletjes weggooien) of REJECT (weigeren en een fout teruggeven). Matcht er niets, dan geldt het standaardbeleid van de chain. Het kernprincipe van een degelijke firewall: zet het beleid op DROP en open daarna alleen wat je expliciet toestaat.

Sluit jezelf niet buiten: volgorde telt

De meest gemaakte fout is het beleid op DROP zetten voordat je de SSH-regel toevoegt, waardoor je je eigen sessie op afstand verbreekt. Dus schrijf eerst de toestaan-regels, verscherp het beleid als laatste. Geef ook loopback en bestaande verbindingen meteen bovenaan vrij:

# Laat reeds opgezette verbindingen doorgaan
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Blokkeer nooit loopback-verkeer (127.0.0.1)
iptables -A INPUT -i lo -j ACCEPT

# Gooi misvormde / ongeldige pakketten weg
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

Die eerste regel is cruciaal: dankzij de conntrack-module passeren antwoordpakketten van verbindingen die de server zelf startte of die al bestaan automatisch, zodat je geen aparte regels aan de OUTPUT-kant hoeft te schrijven.

Poortregels: open alleen wat je nodig hebt

Laten we nu poortregels per service toevoegen. Een typische opzet: SSH (22), HTTP (80), HTTPS (443) en een gameserverpoort. -p stelt het protocol in, --dport de bestemmingspoort:

# SSH (voeg dit eerst toe, daarna pas vergrendelen!)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Web
iptables -A INPUT -p tcp --dport 80  -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Voorbeeld gameserver (bijv. Metin2 TCP 13000)
iptables -A INPUT -p tcp --dport 13000 -j ACCEPT

Om meerdere poorten in één regel te openen gebruik je de multiport-module:

iptables -A INPUT -p tcp -m multiport --dport 80,443,13000 -j ACCEPT

Een poort alleen voor een specifiek IP openen (bijvoorbeeld SSH enkel vanaf je vaste IP) is veel veiliger:

iptables -A INPUT -p tcp -s 203.0.113.10 --dport 22 -j ACCEPT

Zodra alle toestaan-regels geschreven zijn, verscherp je het standaardbeleid:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Basisaanvallen filteren

Een blootgestelde server krijgt voortdurend poortscans, brute-force en vervalste-pakketpogingen over zich heen. Een paar gerichte regels gooien de meeste daarvan weg of vertragen ze.

SSH-brute-force afremmen: met de recent-module blokkeer je tijdelijk elk IP dat meer dan 4 nieuwe SSH-verbindingen in 60 seconden probeert:

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --update --seconds 60 --hitcount 5 --name SSH -j DROP

Poortscans / ongeldige flags: TCP-pakketten zonder flags (NULL) of met onzinnige flag-combinaties komen meestal van een scantool:

# NULL-pakketten
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# XMAS-scan
iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
# Nieuwe verbindingen die geen SYN zijn
iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP

ICMP (ping) rate-limiten: in plaats van ping helemaal uit te schakelen houdt het beperken van het aantal verzoeken per seconde de diagnostiek bruikbaar én stopt het floods:

iptables -A INPUT -p icmp --icmp-type echo-request \
  -m limit --limit 1/second -j ACCEPT

Onthoud: iptables alleen stopt geen echte DDoS (een verzadigde lijn ligt buiten de kernel), maar het vermindert scanning op applicatieniveau en ruis aanzienlijk.

Regels persistent maken

iptables-regels staan in het geheugen en gaan verloren bij een herstart. Op Debian/Ubuntu slaat het pakket iptables-persistent ze op en herstelt het ze bij het opstarten:

sudo apt install iptables-persistent
sudo netfilter-persistent save        # /etc/iptables/rules.v4

Je kunt ook handmatig opslaan en herstellen:

iptables-save  > /etc/iptables/rules.v4
iptables-restore < /etc/iptables/rules.v4

Om regels met regelnummers te bekijken en te verwijderen:

iptables -L INPUT -n -v --line-numbers
iptables -D INPUT 3        # verwijder regel nummer 3

Een opmerking over nftables en UFW

Op moderne distributies wordt het iptables-commando meestal achter de schermen doorgestuurd naar nftables (iptables-nft). De commandosyntaxis blijft hetzelfde, dus alles in deze gids werkt. Voor nieuwe projecten is het zinvol om direct nft te leren, maar talloze bestaande docs en scripts zijn nog iptables-gebaseerd. Wil je een eenvoudigere interface, dan verpakt UFW (Uncomplicated Firewall) iptables: one-liners als ufw allow 443/tcp doen hetzelfde werk. Maar om echt te begrijpen wat er gebeurt, is basiskennis van iptables onbetaalbaar.

Veelgestelde vragen

Moet ik DROP of REJECT gebruiken?

DROP gooit het pakket stilletjes weg; de afzender kan niet zien of de poort open, dicht of door een firewall beschermd is, wat scanners vertraagt. REJECT stuurt een "connection refused"-bericht terug en geeft snellere feedback. Op een internetgerichte INPUT-chain heeft DROP meestal de voorkeur; op een intern netwerk is REJECT handiger voor snelle fouten.

Waarom is de volgorde van regels zo belangrijk?

Omdat iptables stopt bij de eerste regel die matcht. Zet je bovenaan een brede DROP, dan worden de ACCEPT-regels daaronder nooit uitgevoerd. Zet smalle/specifieke toestaan-regels altijd bovenaan en algemene weigeringen/het beleid onderaan.

Heb ik aparte regels voor IPv6 nodig?

Ja. iptables beheert alleen IPv4; IPv6-verkeer configureer je apart met ip6tables. Heeft je server IPv6, dan is het ongefilterd laten een groot gat, dus schrijf met dezelfde logica bijbehorende ip6tables-regels.

Wil je je server veilig en robuust geconfigureerd hebben? Heb je hulp nodig met firewall, hardening en deployment voor een gameserver, VPS of webinfrastructuur, neem dan contact met me op.