Kurz gesagt: Eine Firewall für Webserver lässt eingehend nur TCP 80 und 443 zu, bei HTTP/3 zusätzlich UDP 443, und SSH nur aus bekannten Netzen. Alles andere wird verworfen: Datenbanken, Caches, PHP-FPM und Verwaltungsoberflächen gehören nicht ins Internet. Prüfen Sie zuerst mit ss -tulpn, was lauscht, bauen Sie dann ein Regelwerk mit Standard „verwerfen“ und testen Sie das Ergebnis von außen. Ausgehende Verbindungen einzuschränken, begrenzt zusätzlich die Folgen eines Einbruchs.
Die vergessenen Türen neben der Haustür
Bei PHP2Shell richtete sich der Blick auf den Webserver selbst, auf die Ports 80 und 443. Die müssen offen sein, sonst gibt es keine Website. Bei Bestandsaufnahmen nach solchen Lücken fällt aber oft etwas anderes auf: Neben der Haustür stehen weitere Türen offen. Eine Datenbank lauscht auf allen Netzwerkschnittstellen, ein PHP-FPM-Pool auf Port 9000, ein Cache-Dienst ohne Passwort, eine Verwaltungsoberfläche aus der Einrichtungsphase.
Jede dieser Türen ist eine eigene Angriffsfläche mit eigenen Lücken. Eine Firewall, die nur das Nötige zulässt, schließt sie mit wenigen Regeln. Das ist eine der wirksamsten Maßnahmen beim Absichern eines eigenen Servers, wie sie auch die Seite Root-Server und vServer selbst absichern beschreibt.
Was gehört offen, was nicht?
Grundsatz ist eine Erlaubnisliste: Alles ist zu, und nur bewusst freigegebene Dienste sind erreichbar. Die folgende Übersicht hilft bei der Einordnung.
| Dienst | Typischer Port | Von außen erreichbar? |
|---|---|---|
| HTTP und HTTPS | TCP 80, TCP 443 | ja |
| HTTP/3 (QUIC) | UDP 443 | nur wenn genutzt |
| SSH | TCP 22 | nur aus bekannten Netzen oder per VPN |
| Hosting-Panel | je nach Produkt | nur aus bekannten Netzen |
| MySQL/MariaDB, PostgreSQL | TCP 3306, TCP 5432 | nein |
| Redis, Memcached | TCP 6379, TCP 11211 | nein |
| PHP-FPM | TCP 9000 oder Unix-Socket | nein, besser nur Socket |
| Mailserver | TCP 25, 465, 587, 993 | nur wenn der Server Mails empfängt oder bereitstellt |
Ein Dienst, der nicht nach außen muss, sollte zusätzlich nur auf 127.0.0.1 oder einem Unix-Socket lauschen. Dann bleibt er auch bei einer Panne in der Firewall unerreichbar. Für Verwaltungszugänge eignen sich IP-Freigaben oder ein VPN; Details stehen im Beitrag Admin-Bereiche per IP, VPN oder Zusatzschutz abschirmen.
Schritt 1: Feststellen, was lauscht
Bevor Sie Regeln schreiben, verschaffen Sie sich einen Überblick. Die folgenden Befehle lesen nur:
# Alle lauschenden TCP- und UDP-Ports mit Prozess
sudo ss -tulpn
# Aktuelles Regelwerk von nftables
sudo nft list ruleset
# Status von ufw, falls genutzt
sudo ufw status verbose
Achten Sie in der Ausgabe von ss auf die Adresse vor dem Port. 0.0.0.0 oder [::] bedeutet: Der Dienst lauscht auf allen Schnittstellen. 127.0.0.1 bedeutet: nur lokal. Notieren Sie für jeden Dienst, ob er von außen erreichbar sein muss. Diese Liste ist zugleich ein Stück Ihres Server-Inventars.
Firewall für Webserver mit nftables
nftables ist der aktuelle Paketfilter unter Linux. Das folgende Regelwerk orientiert sich am Beispiel im offiziellen nftables-Wiki und ergänzt eine Freigabe für SSH nur aus einem Verwaltungsnetz. Die Adressen sind Dokumentationsbeispiele und müssen ersetzt werden.
#!/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 braucht Nachbarschaftserkennung
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
# nur bei HTTP/3:
# udp dport 443 accept
# SSH nur aus dem Verwaltungsnetz
ip saddr @verwaltung_v4 tcp dport 22 accept
}
chain forward {
type filter hook forward priority 0; policy drop;
}
}
Prüfen Sie das Regelwerk vor dem Laden mit nft -c -f /etc/nftables.conf. Die erste Zeile flush ruleset löscht alle bestehenden Regeln, auch solche, die Docker oder Fail2ban eingetragen haben. Auf Servern mit Docker oder anderen Diensten, die eigene Regeln setzen, passen Sie das Regelwerk deshalb an, statt es pauschal zu ersetzen. Wie Fail2ban mit der Firewall zusammenarbeitet, steht unter Fail2ban für Webserver einrichten.
Wer es einfacher mag, nutzt unter Ubuntu ufw. Wichtig ist die Reihenfolge: zuerst die SSH-Freigabe, dann einschalten.
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
Ändern Sie Firewall-Regeln auf entfernten Servern nur mit einem zweiten Zugangsweg, etwa der Konsole Ihres Anbieters. Eine falsche SSH-Regel sperrt Sie sonst selbst aus.
Ausgehende Verbindungen: die unterschätzte Hälfte
Die meisten Firewalls erlauben ausgehend alles. Für einen Webserver ist das großzügig. Nach einem Einbruch nutzen Angreifer ausgehende Verbindungen, um Werkzeuge nachzuladen, Daten abzuziehen oder Befehle zu empfangen. Webserver- oder PHP-Prozesse, die unerwartete Verbindungen aufbauen, gelten deshalb als Warnsignal.
Eine Begrenzung ausgehender Verbindungen ist aufwendiger, weil jede legitime Verbindung bekannt sein muss: Paketquellen für Updates, Zahlungsdienste, Schnittstellen, Mailversand, Zeitserver. Ein pragmatischer Weg ist, zunächst ausgehende Verbindungen zu protokollieren, dann eine Erlaubnisliste zu bilden und erst danach zu sperren. Wie Sie bestehende Verbindungen prüfen, beschreibt Ausgehende Verbindungen eines Servers prüfen; welche Spuren sonst auf einen Einbruch hindeuten, steht unter Bin ich schon kompromittiert?.
Zum Abschluss testen Sie von außen, von einem anderen Rechner und nur gegen Ihre eigenen Systeme, welche Ports tatsächlich erreichbar sind. Erst dieser Test zeigt, ob Docker, Anbieter-Firewall und Serverregeln zusammen das gewünschte Bild ergeben.
Fazit: Wenige Regeln, große Wirkung
Eine Webserver-Firewall muss nicht kompliziert sein. Web-Ports offen, Verwaltung nur aus bekannten Netzen, alles andere verworfen: Mit diesen Grundregeln verschwinden Datenbanken, Caches und vergessene Dienste aus dem Internet. Das ist eine der Maßnahmen mit dem besten Verhältnis von Aufwand zu Nutzen.
Gegen Lücken im Webserver oder in PHP selbst hilft die Firewall nicht, denn genau diese Ports müssen offen bleiben. Ihre Stärke liegt darin, die übrige Angriffsfläche klein zu halten und mit einer Begrenzung ausgehender Verbindungen die Folgen eines Einbruchs einzudämmen.
Entscheidend ist die Pflege. Jeder neue Dienst, jeder Container und jede Änderung beim Anbieter kann das Bild verschieben. Wiederholen Sie die Prüfung von außen deshalb nach jeder größeren Änderung und in festen Abständen, etwa einmal im Quartal.
Wie hilft PHP SOS konkret?
- Bestand aufnehmen: Wir erfassen alle lauschenden Dienste und prüfen von außen, was tatsächlich erreichbar ist.
- Regelwerk aufbauen: Wir erstellen eine Erlaubnisliste für eingehende und, wo sinnvoll, ausgehende Verbindungen, abgestimmt auf Docker, Fail2ban und Anbieter-Firewall.
- Sicher umstellen: Änderungen setzen wir mit zweitem Zugangsweg und Rückfallplan um.
- Dokumentieren: Ports, Freigaben und Gründe halten wir im Rahmen der Server-Härtung fest.
Häufige Fragen
Welche Ports braucht ein Webserver?
Für Besucher in der Regel nur TCP 80 und 443, bei HTTP/3 zusätzlich UDP 443. SSH und Verwaltungsoberflächen sollten nur aus bekannten Netzen oder über VPN erreichbar sein. Datenbank-, Cache- und PHP-FPM-Ports gehören nicht ins Internet.
Schützt eine Firewall vor PHP2Shell?
Nein. PHP2Shell wird über den Webserver ausgenutzt, also über genau die Ports, die offen sein müssen. Die Firewall verkleinert aber die übrige Angriffsfläche, und eine Begrenzung ausgehender Verbindungen kann die Folgen eines Einbruchs eindämmen.
Warum zeigt ufw Ports als geschlossen, die trotzdem erreichbar sind?
Ein bekannter Fall sind Docker-Container: Docker trägt veröffentlichte Ports direkt in die Paketfilterregeln ein, an ufw vorbei. Prüfen Sie offene Ports deshalb immer zusätzlich von außen.
Reicht die Firewall meines Hosting-Anbieters?
Eine vorgelagerte Firewall des Anbieters ist eine gute zweite Schicht. Sie ersetzt die Firewall auf dem Server aber nicht, weil sie bei einem Fehler in der Anbieterkonfiguration oder bei internen Verbindungen nicht greift. Am besten nutzen Sie beide mit denselben Grundregeln.