Sinnvolle Standard-Firewallregeln für einen Linux-Server

Die Antwort zuerst: die Drei-Regeln-Philosophie

Jede gute Server-Firewall basiert auf denselben drei Entscheidungen; sobald Sie diese verinnerlicht haben, ist der Rest Detail:

1. Default-deny inbound. Die Policy für eingehenden Verkehr ist drop. Alles, was nicht explizit erlaubt ist, erreicht niemals einen Dienst, auch nicht den Dienst, von dem Sie vergessen hatten, dass er läuft.
2. Lassen Sie established und related Traffic zu. Antworten auf Verbindungen, die Ihr Server selbst initiiert hat, sowie die Rückrichtung akzeptierter Verbindungen fließen ungehindert. Diese eine zustandsbehaftete Regel macht default-deny überhaupt erst praxistauglich.
3. Setzen Sie Ihre Dienste explizit auf die Allowlist. SSH, Ihre Web-Ports, und sonst nichts, bis etwas anderes tatsächlich erreichbar sein muss.

Ausgehender Traffic bleibt auf den meisten Servern default-allow; Outbound-Filterung hat durchaus ihren Nutzen, ist aber ein optionaler Härtungsschritt und kein Teil einer sinnvollen Grundkonfiguration (mehr dazu gegen Ende).

Das ist relevant, denn eine frische Installation bietet davon nichts. Debian und Ubuntu werden mit keiner einzigen aktiven Firewallregel ausgeliefert; jeder Daemon, der an 0.0.0.0 bindet, ist ab dem Moment seines Starts dem Internet ausgesetzt, und Honeypot-Studien zeigen, dass die ersten Probes innerhalb weniger Minuten eintreffen, nachdem eine IP live geht. Eine Baseline-Firewall ist eine Sache von zehn Minuten. Hier ist sie.

Das Basis-Regelwerk in nftables

nftables ist das native Firewall-Framework auf jeder aktuellen großen Distribution (der Befehl iptables ist auf einem modernen System tatsächlich eine Kompatibilitätsschicht über nftables), und eine einzige inet-Tabelle deckt IPv4 und IPv6 gemeinsam ab, was den häufigsten Firewallfehler auf der Stelle ausschließt. Speichern Sie dies als /etc/nftables.conf:

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

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;

    # 1. Loopback is always fine
    iif "lo" accept

    # 2. The stateful core: replies and related traffic
    ct state established,related accept
    ct state invalid drop

    # 3. ICMP — the minimum the internet needs to work
    icmp type { echo-request, destination-unreachable, time-exceeded, parameter-problem } accept
    icmpv6 type { echo-request, destination-unreachable, packet-too-big, time-exceeded, parameter-problem,
                  nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept

    # 4. Your services — the explicit allow-list
    tcp dport 22 accept comment "SSH"
    tcp dport { 80, 443 } accept comment "HTTP/HTTPS"
    udp dport 443 accept comment "HTTP/3 (remove if unused)"

    # 5. Optional: see what you're dropping, without flooding the log
    limit rate 5/minute log prefix "input drop: "
  }

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

  chain output {
    type filter hook output priority filter; policy accept;
  }
}

Wenden Sie es mit nft -f /etc/nftables.conf an und machen Sie es mit systemctl enable nftables dauerhaft. (Auf Debian und Ubuntu verdrahtet das nftables-Paket genau diese Datei mit diesem Dienst.)

Nun die Begründung, Regel für Regel.

Regel 1: Loopback

Unzählige Komponenten eines Linux-Systems sprechen über 127.0.0.1 und ::1 mit sich selbst: Resolver, Datenbanken, Metrics-Agents. lo bedingungslos zu akzeptieren ist unbedenklich (Loopback-Verkehr kommt nie über die Leitung), und wer es vergisst, bekommt unter einer Drop-Policy rätselhafte Ausfälle.

Regel 2: der zustandsbehaftete Kern

ct state established,related accept ist die Regel, die den Großteil der Arbeit erledigt. Connection Tracking (conntrack) merkt sich jeden Flow, den die Firewall genehmigt hat; diese Regel lässt den Rest jeder genehmigten Verbindung durch, ohne die Allowlist pro Paket neu auszuwerten. related deckt Protokolle ab, die legitim sekundäre Flows erzeugen (eine ICMP-Fehlermeldung zu Ihrer Verbindung, FTP-Datenkanäle).

ct state invalid drop verwirft Pakete, die zu keinem bekannten Flow gehören und auch keinen gültigen neuen Flow eröffnen können: verirrte ACKs außerhalb des Fensters, Datenmüll von Scannern mitten in einer Verbindung, Überbleibsel von Angriffen. Sie früh zu verwerfen ist kostenlose Hygiene.

Eine ehrliche Einschränkung: conntrack selbst ist Zustand, und Zustand lässt sich erschöpfen; genau darauf zielen DDoS-Angriffe auf Protokollfamilien ab. Für einen normalen Server reichen die Standardwerte plus SYN-Cookies aus; betreiben Sie einen Dienst mit sehr hoher Verbindungsrate, gehört das Erhöhen von net.netfilter.nf_conntrack_max auf Ihre Tuning-Liste.

Regel 3: ICMP richtig gemacht

Das hartnäckigste Stück Firewall-Folklore lautet: "Ping blockieren, ICMP blockieren, das ist sicherer." Ist es nicht; es zerstört die Control Plane des Internets:

• destination-unreachable (und darin, für IPv4, fragmentation-needed) ist die Funktionsweise von Path MTU Discovery. Verwerfen Sie es, hängen Verbindungen über jeden Pfad mit kleinerer MTU (VPNs, Tunnel, manche Transit-Strecken) bei großen Übertragungen auf mysteriöse Weise, der klassische Bug "SSH funktioniert, aber SCP stockt".
• packet-too-big ist das IPv6-Äquivalent, und IPv6 ist strenger: Router fragmentieren in IPv6 nie, weshalb PMTUD zwingend ist. ICMPv6 pauschal zu verwerfen zerstört IPv6, Punkt.
• Neighbour Discovery (nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert) ist das ARP von IPv6. Verwerfen Sie es, verliert Ihr Server sein Default-Gateway, sobald der Neighbour-Cache abläuft.
• echo-request (Ping) lohnt sich auf einem Server zuzulassen: Es kostet praktisch nichts (Ihre Adresse ist ohnehin für Scanner auffindbar), und Sie werden Ihre eigene Maschine beim Debugging anpingen wollen. Falls Ping-Floods Sie beunruhigen, begrenzen Sie die Rate (icmp type echo-request limit rate 10/second accept), statt es zu verwerfen.

Die Baseline oben lässt genau die Kontrollnachrichten zu, die die Protokolle benötigen, und sonst nichts: keine Timestamps, keine Redirects, keine Router Solicitations, die Sie inbound nicht brauchen.

Regel 4: die Allowlist

Dieser Abschnitt sollte ein genaues Inventar dessen sein, wofür der Server da ist. Zwei Gewohnheiten halten ihn ehrlich:

• Fügen Sie jeder Regel einen comment hinzu. In sechs Monaten ist tcp dport 8472 accept comment "flannel VXLAN" Dokumentation; eine nackte Portnummer ist Archäologie.
• Wenn ein Dienst intern ist, sagen Sie das auch in der Regel. Soll PostgreSQL nur von Ihren App-Servern in einem privaten Netz erreichbar sein, kodieren Sie das: ip saddr 10.0.0.0/24 tcp dport 5432 accept, kein nacktes Allow auf Port 5432. (Adressen hier und im Folgenden sind Dokumentationsbereiche; ersetzen Sie sie durch Ihre eigenen.)

Regel 5: die Drops loggen

Vollständiges Drop-Logging auf einem öffentlich erreichbaren Server ist eine Festplatten-Füllmaschine; Hintergrundscans laufen konstant. Die Stichprobe mit limit rate 5/minute gibt Ihnen genug in journalctl -k, um Muster zu erkennen (und um Momente wie "warum erreiche ich meinen neuen Dienst nicht" zu debuggen: Sehen Sie den Drop geloggt, ist die Firewall Ihr Problem) ohne das Rauschen.

Die vergessene Hälfte: IPv6-Parität

Das historische Fehlermuster: ein sorgfältiges iptables-Regelwerk für IPv4, während ip6tables nie angefasst wurde, wodurch jeder Dienst auf Dual-Stack-Maschinen über IPv6 weit offenstand. Untersuchungen aus jener Zeit fanden regelmäßig v6-Exposition, von der die Betroffenen nichts wussten.

Die Baseline oben ist durch ihre Konstruktion immun: Eine nftables-Tabelle vom Typ inet wendet jede Regel gleichzeitig auf beide Familien an, und die ICMPv6-Regeln geben v6 genau die Kontrollnachrichten, die es braucht. Nutzen Sie stattdessen ufw oder firewalld, verwalten beide standardmäßig ebenfalls v6 neben v4. Die Faustregel überlebt jede Werkzeugwahl: Jede Firewall-Entscheidung, die Sie treffen, muss für beide Adressfamilien gelten. Hat Ihr Server einen AAAA-Eintrag, testen Sie Ihre Dienste nach dem Anwenden der Regeln auch über v6, nicht nur über v4.

Rate-Limiting für SSH (und wo fail2ban ins Spiel kommt)

Port 22 wird auf ewig Brute-Force-Versuche empfangen; bei reiner Key-Authentifizierung sind diese Versuche nur Rauschen, aber sie günstig zu drosseln lohnt sich trotzdem. nftables kann Rate-Limiting pro Quelle nativ mit einem dynamischen Set umsetzen. Ersetzen Sie die einfache SSH-Regel durch:

    set ssh_ratelimit {
      type ipv4_addr
      flags dynamic
      timeout 10m
    }
    set ssh_ratelimit6 {
      type ipv6_addr
      flags dynamic
      timeout 10m
    }

    tcp dport 22 ct state new add @ssh_ratelimit { ip saddr limit rate 4/minute } accept comment "SSH v4, per-IP throttle"
    tcp dport 22 ct state new add @ssh_ratelimit6 { ip6 saddr limit rate 4/minute } accept comment "SSH v6, per-IP throttle"

Jede Quelladresse erhält vier neue SSH-Verbindungen pro Minute; die fünfte wird stillschweigend verworfen, bis die Rate wieder sinkt. Das ist blind gegenüber der Absicht (es unterscheidet nicht zwischen einem fehlgeschlagenen und einem erfolgreichen Login), weshalb fail2ban weiterhin eine sinnvolle Ergänzung ist: Es liest das Auth-Log und sperrt Adressen, die tatsächlich an der Authentifizierung scheitern. Rate-Limiting in der Firewall, Sperren anhand von Beweisen mit fail2ban, und Keys verlangen; diese Kombination beendet das SSH-Rauschproblem.

Dieselbe Baseline in ufw und firewalld

Wenn die Konvention Ihrer Distribution ein Frontend ist, nutzen Sie das Frontend; handgeschriebene Regeln mit den Regeln eines Frontends zu mischen ist genau der Punkt, an dem Firewalls zur Archäologie werden. Dieselbe Policy:

ufw (Ubuntus Standard-Frontend; es steuert unter der Haube iptables an, was über die Kompatibilitätsschicht letztlich in nftables landet):

ufw default deny incoming
ufw default allow outgoing
ufw limit 22/tcp comment 'SSH, rate-limited'
ufw allow 80/tcp
ufw allow 443
ufw enable

ufw limit wendet eine eingebaute Brute-Force-Drossel an (sechs Verbindungen in dreißig Sekunden pro Quelle). ufw übernimmt Loopback, conntrack und sinnvolle ICMP-Standardwerte für Sie.

firewalld (der Standard der RHEL-Familie, seit 2018 auf nftables basierend):

firewall-cmd --set-default-zone=public
firewall-cmd --permanent --zone=public --add-service=ssh
firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --reload

firewalld denkt in Zonen und Diensten statt in Regeln; die public-Zone ist default-deny mit den aufgeführten geöffneten Diensten, und ICMP wird von Haus aus sinnvoll gehandhabt.

Wie Sie sich nicht selbst aussperren

Firewalländerungen auf einem Remote-Server sind der klassische selbstverschuldete Ausfall. Diese Gewohnheiten machen sie langweilig:

• Syntax vor dem Anwenden prüfen: nft -c -f /etc/nftables.conf validiert die Datei, ohne sie zu laden.
• Planen Sie vor riskanten Änderungen einen automatischen Rollback, und brechen Sie ihn ab, sobald Sie bestätigt haben, dass Sie noch Zugriff haben:

# revert to the known-good ruleset in 3 minutes unless cancelled
systemd-run --on-active=3m --unit=fw-rollback nft -f /etc/nftables.known-good
# ...apply your change, confirm SSH still works, then cancel the rollback:
systemctl stop fw-rollback.timer

Und halten Sie währenddessen durchgehend eine zweite SSH-Sitzung offen; speichern Sie das neue Regelwerk erst dann als known-good, wenn eine frische Verbindung erfolgreich war.

• Testen Sie eine Änderung der default-drop-Policy nie ohne Out-of-Band-Zugriff. Bei einem dedizierten Server bedeutet das KVM-over-IP-/IPMI-Konsolenzugriff (in unseren Servern inbegriffen), der aus einer Aussperrung statt eines Vorfalls eine Zwei-Minuten-Korrektur macht.
• Die Reihenfolge spielt in nftables eine kleinere Rolle, als Sie befürchten, aber die accept-established-Regel muss vor Ihren Drops stehen, und die gesamte Datei wird von nft -f atomar angewendet, sodass ein halb geladenes Regelwerk Sie nicht so stranden kann, wie es aufeinanderfolgende iptables-Befehle historisch konnten.

Docker umgeht ufw und Ihre input-Chain

Betreiben Sie Docker mit veröffentlichten Ports (-p 8080:80), sollten Sie das wissen: Docker programmiert die NAT- und Forwarding-Regeln des Kernels direkt, und veröffentlichte Ports umgehen ufw und Ihre input-Chain vollständig. Ihre sorgfältig konfigurierte default-deny-Firewall gilt nicht für mit -p veröffentlichte Container; der Traffic wird umgeleitet, bevor ihn Ihre input-Chain überhaupt zu sehen bekommt. Das ist seit Langem bekanntes, dokumentiertes Verhalten, kein Bug, der im nächsten Release behoben wird (das native nftables-Backend von Docker Engine 29 ist experimentell und ändert an der Semantik nichts).

Die anerkannten Lösungen:

• Binden Sie Ports, die nicht öffentlich sein sollen, an localhost oder eine private Adresse: -p 127.0.0.1:8080:80 oder -p 10.0.0.5:5432:5432.
• Setzen Sie Einschränkungen in die DOCKER-USER-Chain, die Docker garantiert vor seinen eigenen Regeln auswertet: Das ist der unterstützte Hook für "meine Container firewallen".
• Behandeln Sie jedes -p mit einem nackten Port als "das steht jetzt im Internet", denn genau das ist der Fall.

Outbound-Filterung: wann sie sich lohnt

Eine default-accept-Output-Policy ist die richtige Grundeinstellung: Server sprechen legitim ausgehend mit Paket-Mirrors, DNS, NTP, APIs und Monitoring. Outbound-Filterung rechtfertigt ihre Komplexität in bestimmten Situationen: Compliance-Vorgaben, die Egress-Kontrolle verlangen, Server, die nicht vertrauenswürdige Eingaben verarbeiten und bei denen Sie Reverse Shells und Datenexfiltration eindämmen wollen, sowie Single-Purpose-Maschinen, deren komplettes Traffic-Profil bekannt ist (ein Datenbankserver hat keinen Grund, Verbindungen zu beliebigen Internet-Hosts zu öffnen).

Führen Sie es ein, gehen Sie genauso vor wie bei inbound: Listen Sie auf, was der Server braucht (DNS zu Ihren Resolvern, 80/443 zu Mirrors, Ihr Monitoring-Endpoint), lassen Sie das zu, default-droppen Sie den Rest, und loggen Sie die Drops eine Woche lang, bevor Sie durchsetzen; das Log zeigt Ihnen, was Sie vergessen haben.

Häufig gestellte Fragen

Sollte ich nftables direkt verwenden, oder lieber ufw oder firewalld?

Folgen Sie der Konvention Ihrer Distribution und den Gewohnheiten Ihrer Flotte. Auf Debian ist natives nftables sauber und erstklassig unterstützt; auf Ubuntu ist ufw der bewährte Weg; auf RHEL/AlmaLinux/Rocky ist firewalld die unterstützte Schnittstelle, und die Dokumentation setzt sie voraus. Alle drei erzeugen am Ende nftables-Regeln im Kernel. Das eine echte Antipattern ist das Mischen der Ebenen: Wer von Hand nft-Regeln auf einer Maschine hinzufügt, die firewalld verwaltet, bekommt Regeln, die beim Reload verschwinden.

Ist das Blockieren von Ping eine gute Sicherheitsmaßnahme?

Nein. Die Existenz Ihres Servers wird durch das Verwerfen von Echo-Requests nicht verborgen (Scanner finden aktive Hosts auf viele andere Arten), und Sie verlieren ein einfaches Diagnosewerkzeug, das Sie selbst brauchen werden. Schlimmer noch: Wer "Ping blockieren" will, blockiert dabei meist gleich das gesamte ICMP und bricht damit Path MTU Discovery und die IPv6-Neighbour-Discovery. Lassen Sie echo-request zu (bei Bedarf rate-limited) sowie die Fehler-/Kontrollmeldungen; verwerfen Sie den Rest.

Schützen mich diese Regeln vor DDoS-Angriffen?

Teilweise, und es ist wichtig, genau zu sein, welcher Teil. Ein default-deny Regelwerk verkleinert die Angriffsfläche (Datenmüll gegen geschlossene Ports stirbt billig) und Rate-Limits dämpfen kleine Connection-Floods. Aber keine Regel auf dem Host hilft mehr, sobald ein Angriff Ihren Uplink sättigt; die Pakete haben die Leitung hinter Ihren Regeln dann bereits passiert. Volumetrische Angriffe werden upstream gestoppt oder gar nicht, weshalb unser Netzwerk permanente DDoS-Mitigation und eine Self-Service-Firewall am Netzwerkrand vor Ihren Port stellt.

Ich habe eine Firewall angewendet und etwas ist kaputtgegangen. Wie debugge ich das?

Prüfen Sie zuerst das Drop-Log: journalctl -k | grep "input drop" (mit der Logging-Regel aus der Baseline). Taucht der blockierte Traffic dort auf, fehlt Ihnen eine Allow-Regel. Notieren Sie Port und Protokoll aus der Logzeile. Taucht nichts auf, ist die Firewall nicht Ihr Problem; prüfen Sie das Service-Binding (ss -tlnp) und bestätigen Sie bei über IPv6 erreichbaren Hosts, dass Sie dieselbe Adressfamilie getestet haben, die fehlschlägt.

Deployment bei Serverside

Auf unseren dedizierten Servern ist das Host-Regelwerk aus dieser Anleitung eine von zwei Firewall-Ebenen: Jeder Server erhält zusätzlich eine Self-Service-Firewall am Netzwerkrand, sodass Traffic zu Ports, die Sie nie bedienen, bereits upstream verworfen wird, bevor er Ihre Maschine erreicht, zusätzlich zur permanenten DDoS-Mitigation in unserem ASN-55285-Netzwerk. Und sollte eine Firewalländerung Sie doch einmal aussperren, bedeutet der inbegriffene KVM-over-IP-Konsolenzugriff, dass die Wiederherstellung Minuten dauert, kein Support-Ticket. Die Provisionierung dauert für Ubuntu, Debian, AlmaLinux/Rocky, RHEL und mehr weniger als eine Minute.

Als Nächstes in dieser Serie: die Wahl Ihres Regel-Tools in iptables vs. nftables, das größere Bedrohungsbild in DDoS-Angriffe erklärt, und wie Sie herausfinden, was tatsächlich auf Ihren Server einschlägt, in einen DDoS mit Wireshark erfassen und analysieren.