Firewall voor webservers: alleen noodzakelijke poorten openen

Kort gezegd: Een firewall voor webservers laat inkomend alleen TCP 80 en 443 toe, bij HTTP/3 aanvullend UDP 443, en SSH alleen vanuit bekende netwerken. Al het andere wordt verworpen: databases, caches, PHP-FPM en beheeromgevingen horen niet op internet. Controleer eerst met ss -tulpn wat er luistert, bouw dan een regelwerk met standaard „verwerpen” en test het resultaat van buitenaf. Uitgaande verbindingen beperken beperkt bovendien de gevolgen van een inbraak.

De vergeten deuren naast de voordeur

Bij PHP2Shell richtte de blik zich op de webserver zelf, op de poorten 80 en 443. Die moeten open zijn, anders is er geen website. Bij inventarisaties na zulke kwetsbaarheden valt echter vaak iets anders op: naast de voordeur staan nog meer deuren open. Een database luistert op alle netwerkinterfaces, een PHP-FPM-pool op poort 9000, een cachedienst zonder wachtwoord, een beheeromgeving uit de inrichtingsfase.

Elk van deze deuren is een eigen aanvalsoppervlak met eigen kwetsbaarheden. Een firewall die alleen het noodzakelijke toelaat, sluit ze met enkele regels. Dat is een van de meest werkzame maatregelen bij het beveiligen van een eigen server, zoals ook de pagina Rootservers en vServers zelf beveiligen beschrijft.

Wat hoort open, wat niet?

Uitgangspunt is een toegestane lijst: alles is dicht en alleen bewust vrijgegeven diensten zijn bereikbaar. Het volgende overzicht helpt bij de indeling.

Een dienst die niet naar buiten hoeft, moet bovendien alleen op 127.0.0.1 of een Unix-socket luisteren. Dan blijft hij ook bij een storing in de firewall onbereikbaar. Voor beheertoegangen zijn IP-vrijgaven of een VPN geschikt; details staan in het artikel Beheeromgevingen afschermen via IP, VPN of extra bescherming.

Stap 1: vaststellen wat er luistert

Voordat u regels schrijft, verschaft u zich een overzicht. De volgende opdrachten lezen alleen:

# Alle luisterende TCP- en UDP-poorten met proces
sudo ss -tulpn
# Actueel regelwerk van nftables
sudo nft list ruleset
# Status van ufw, indien gebruikt
sudo ufw status verbose

Let in de uitvoer van ss op het adres vóór de poort. 0.0.0.0 of [::] betekent: de dienst luistert op alle interfaces. 127.0.0.1 betekent: alleen lokaal. Noteer voor elke dienst of hij van buitenaf bereikbaar moet zijn. Deze lijst is tegelijk een stuk van uw serverinventaris.

Firewall voor webservers met nftables

nftables is de actuele pakketfilter onder Linux. Het volgende regelwerk volgt het voorbeeld in de officiële nftables-wiki en voegt een vrijgave voor SSH alleen vanuit een beheernetwerk toe. De adressen zijn documentatievoorbeelden en moeten worden vervangen.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    set verwaltung_v4 {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.0/28 }
    }

    chain input {
        type filter hook input priority 0; policy drop;

        ct state vmap { established : accept, related : accept, invalid : drop }
        iifname lo accept

        # IPv6 heeft detectie van buren nodig
        icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
        icmp type echo-request limit rate 5/second accept
        icmpv6 type echo-request limit rate 5/second accept

        # Website
        tcp dport { 80, 443 } accept
        # alleen bij HTTP/3:
        # udp dport 443 accept

        # SSH alleen vanuit het beheernetwerk
        ip saddr @verwaltung_v4 tcp dport 22 accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}

Controleer het regelwerk vóór het laden met nft -c -f /etc/nftables.conf. De eerste regel flush ruleset wist alle bestaande regels, ook die Docker of Fail2ban hebben ingevoerd. Op servers met Docker of andere diensten die eigen regels instellen, past u het regelwerk daarom aan in plaats van het algemeen te vervangen. Hoe Fail2ban met de firewall samenwerkt, staat onder Fail2ban voor webservers instellen.

Wie het eenvoudiger wil, gebruikt onder Ubuntu ufw. Belangrijk is de volgorde: eerst de SSH-vrijgave, dan inschakelen.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow proto tcp from 203.0.113.0/28 to any port 22
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Uitgaande verbindingen: de onderschatte helft

De meeste firewalls staan uitgaand alles toe. Voor een webserver is dat ruimhartig. Na een inbraak gebruiken aanvallers uitgaande verbindingen om gereedschap na te laden, gegevens weg te sluizen of opdrachten te ontvangen. Webserver- of PHP-processen die onverwachte verbindingen opzetten, gelden daarom als waarschuwingssignaal.

Een beperking van uitgaande verbindingen is bewerkelijker, omdat elke legitieme verbinding bekend moet zijn: pakketbronnen voor updates, betaaldiensten, koppelingen, mailverzending, tijdservers. Een pragmatische weg is eerst uitgaande verbindingen te loggen, dan een toegestane lijst op te stellen en pas daarna te blokkeren. Hoe u bestaande verbindingen controleert, beschrijft Uitgaande verbindingen van een server controleren; welke sporen er verder op een inbraak wijzen, staat onder Ben ik al gecompromitteerd?.

Test ten slotte van buitenaf, vanaf een andere computer en alleen tegen uw eigen systemen, welke poorten werkelijk bereikbaar zijn. Pas deze test toont of Docker, aanbiederfirewall en serverregels samen het gewenste beeld opleveren.

Conclusie: weinig regels, grote werking

Een webserverfirewall hoeft niet ingewikkeld te zijn. Webpoorten open, beheer alleen vanuit bekende netwerken, al het andere verworpen: met deze basisregels verdwijnen databases, caches en vergeten diensten van internet. Dat is een van de maatregelen met de beste verhouding tussen inspanning en nut.

Tegen kwetsbaarheden in de webserver of in PHP zelf helpt de firewall niet, want precies deze poorten moeten open blijven. Haar kracht ligt in het klein houden van het overige aanvalsoppervlak en, met een beperking van uitgaande verbindingen, het indammen van de gevolgen van een inbraak.

Beslissend is het onderhoud. Elke nieuwe dienst, elke container en elke wijziging bij de aanbieder kan het beeld verschuiven. Herhaal de controle van buitenaf daarom na elke grotere wijziging en met vaste tussenpozen, bijvoorbeeld eens per kwartaal.

Hoe helpt PHP SOS concreet?

• Bestand opnemen: wij inventariseren alle luisterende diensten en controleren van buitenaf wat werkelijk bereikbaar is.
• Regelwerk opbouwen: wij stellen een toegestane lijst op voor inkomende en, waar zinvol, uitgaande verbindingen, afgestemd op Docker, Fail2ban en aanbiederfirewall.
• Veilig omschakelen: wijzigingen voeren wij door met een tweede toegangsweg en terugvalplan.
• Documenteren: poorten, vrijgaven en redenen leggen wij vast in het kader van de serverhardening.

Veelgestelde vragen

Bronnen

• nftables-wiki: eenvoudig regelwerk voor een server
• Ubuntu Server: firewall (ufw)
• BSI (Duitse federale dienst voor informatiebeveiliging): IT-Grundschutz
• CIS Benchmarks