Firewall verstehen: Wie Regeln, Zonen und Filter Netzwerke schützen

Im Firmennetz hängen Arbeitsplätze, Server, Kameras, Drucker und ein Gäste-WLAN. Der Dateiserver darf von den Arbeitsplätzen erreicht werden, aber nicht von den Kameras. Die Gäste dürfen ins Internet, aber nirgends sonst hin. Und aus dem Internet soll niemand ins interne Netz kommen. Wer entscheidet das alles, und wie sieht so eine Entscheidung konkret aus?

Die Antwort ist die Firewall. Im Beitrag Switch, Router, Access Point und Firewall hast du das Prinzip schon kennengelernt: Regeln, die von oben nach unten abgearbeitet werden, am Ende Default Deny. Hier geht es um die Konzepte dahinter und darum, wie man ein Regelwerk für ein ganzes Netz entwirft.

Was eine Firewall tut

Eine Firewall kontrolliert den Datenverkehr zwischen Netzbereichen und lässt nur durch, was ausdrücklich erlaubt ist. Drei Grundgedanken gelten für fast jede Firewall:

• Erlaubnisliste statt Verbotsliste. Man legt fest, was erlaubt ist, und sperrt den Rest. Das nennt man Default Deny. Der Gegenentwurf, alles zu erlauben und nur Bekanntes zu sperren, vergisst immer etwas.
• Beide Richtungen beachten. Eingehender Verkehr (Ingress) ist der, der von außen kommt. Ausgehender Verkehr (Egress) wird oft vergessen, obwohl er genauso wichtig ist. Schadsoftware auf einem Rechner meldet sich nach außen bei ihrem Steuerserver. Wer ausgehend alles erlaubt, macht ihr das leicht.
• Jede Regel ist eine UND-Verknüpfung. Quelle, Ziel, Protokoll und Port müssen alle passen, wie im Beitrag UND, ODER, NICHT gezeigt. Erst dann greift die Aktion.

Das Zonenmodell

Eine Firewall wird erst richtig nützlich, wenn das Netz in Zonen aufgeteilt ist, also Bereichen mit ähnlichem Schutzbedarf und Vertrauensniveau. Die Aufteilung kennst du aus den Beiträgen zu Subnetting und VLAN: Jede Zone ist ein eigenes Netz, und der Verkehr zwischen den Zonen läuft zwangsläufig durch die Firewall.

Zone	Vertrauen	Beispiele
Internet (WAN)	Keines	Alles außerhalb des Firmennetzes
DMZ	Gering	Webserver und andere Dienste, die aus dem Internet erreichbar sind
Gäste	Gering	Gäste-WLAN
Geräte	Mittel	Kameras, Drucker, Telefone
Arbeitsplätze	Mittel	Notebooks und PCs der Mitarbeiter
Server	Hoch	Dateiserver, Verzeichnisdienst, Datenbanken
Verwaltung (Management)	Sehr hoch	Verwaltungszugänge von Switches, Servern und Firewall

Je höher das Vertrauen und der Schutzbedarf, desto strenger sind die Regeln für den Weg hinein. Die Verwaltungszone darf alle anderen erreichen, aber nicht umgekehrt.

Die Regelmatrix

Bevor man Regeln schreibt, plant man sie in einer Matrix: Von welcher Zone darf wohin, und was genau? Für die Firma aus den Beiträgen zu VLAN und Subnetting sieht ein erster Entwurf so aus:

Von \ Nach	Internet	Server	Geräte	Verwaltung
Arbeitsplätze	Web (80, 443) und DNS (53)	Dateizugriff (TCP 445), DNS, DHCP	Drucken	Gesperrt
Server	Nur Updates (443) an feste Ziele	Nur notwendige Verbindungen	Gesperrt	Gesperrt
Geräte	Gesperrt, höchstens Firmware-Updates	Nur zum Aufnahmeserver	Gesperrt	Gesperrt
Gäste	Web (80, 443) und DNS (53)	Gesperrt	Gesperrt	Gesperrt
Verwaltung	Nach Bedarf	Administration (SSH, RDP)	Administration	Intern frei

Alles, was nicht in der Matrix steht, bleibt gesperrt. Aus jeder erlaubten Zelle wird später eine Regel. Der Vorteil: Du siehst auf einen Blick, wo die Lücken oder Widersprüche sind, bevor du eine Zeile Konfiguration schreibst.

Stateful Inspection: Die Verbindungstabelle

Die meisten Firewalls arbeiten zustandsbehaftet (stateful). Sie merken sich in einer Verbindungstabelle, welche Verbindungen gerade bestehen. Das hat einen praktischen Grund: Wenn ein Arbeitsplatz eine Webseite aufruft, soll die Antwort des Servers zurückkommen dürfen. Eine eigene Regel für den Rückweg ist nicht nötig, die Firewall erkennt die Antwort als Teil einer bekannten Verbindung.

Quelle	Ziel	Protokoll	Zustand
192.168.10.77:50432	203.0.113.50:443	TCP	ESTABLISHED
192.168.10.78:51200	192.168.10.140:445	TCP	ESTABLISHED
192.168.10.77:53311	192.168.10.130:53	UDP	Kurz gültiger Eintrag

Typische Zustände sind NEW (erstes Paket einer Verbindung), ESTABLISHED (Teil einer bestehenden Verbindung), RELATED (gehört zu einer bestehenden Verbindung, etwa eine Fehlermeldung) und INVALID (passt zu nichts und wird meist verworfen). Die Ports und das Zusammenspiel von Client und Server kennst du aus dem Beitrag TCP/IP-Modell erklärt.

Eine Konsequenz: Die Tabelle hat eine Obergrenze. Ein Angreifer, der sie mit Verbindungen füllt, kann die Firewall lahmlegen. Unter Linux siehst du die Obergrenze und die aktuellen Einträge mit diesen Befehlen (das Paket conntrack muss installiert sein):

cat /proc/sys/net/netfilter/nf_conntrack_max
sudo conntrack -L

Der erste Befehl nennt die Höchstzahl der Einträge, der zweite listet die bestehenden Verbindungen auf. Im Monitoring gehört die Auslastung der Verbindungstabelle zu den Werten, die man im Auge behält, wie im Beitrag Monitoring verstehen beschrieben.

Die DMZ: Dienste für das Internet sicher platzieren

Manche Dienste müssen aus dem Internet erreichbar sein, etwa der Webserver der Firma. Wo stellt man ihn hin? Direkt ins interne Netz wäre fahrlässig: Wird er gehackt, steht dem Angreifer alles offen. Die Lösung heißt DMZ (demilitarisierte Zone), ein eigenes Netz zwischen Internet und internem Netz, das beide streng trennt.

Verbindung	Erlaubt?	Warum?
Internet → DMZ	Nur Web (TCP 80 und 443)	Der Dienst soll erreichbar sein
DMZ → Internet	Nur das Nötige (zum Beispiel Updates)	Ein gehackter Server darf nicht frei nach außen funken
DMZ → internes Netz	Gesperrt, höchstens ein einzelner, genau beschriebener Zugriff	Ein gehackter Server soll nicht ins LAN kommen
Internes Netz → DMZ	Nur Verwaltung (zum Beispiel SSH vom Verwaltungsnetz)	Administration
Internet → internes Netz	Gesperrt	Standardregel

Die Portweiterleitung aus dem Beitrag Private und öffentliche IP-Adressen führt dann nicht ins interne Netz, sondern in die DMZ. Das ist eine Anwendung des Prinzips Defense in Depth aus dem Beitrag IT-Sicherheit Grundlagen.

Netz-Firewall und Host-Firewall

Es gibt Firewalls an zwei Stellen, und sie ergänzen sich:

• Die Netz-Firewall sitzt zwischen den Zonen, meist am Router oder als eigenes Gerät. Sie schützt ganze Netze.
• Die Host-Firewall läuft auf dem einzelnen Rechner: die Windows-Firewall, nftables oder ufw unter Linux. Sie schützt auch dann, wenn ein Angreifer schon im selben Netz sitzt oder wenn das Notebook unterwegs ist.

Nur beides zusammen schließt die Lücke: Die Netz-Firewall hält Angriffe von außen ab, die Host-Firewall begrenzt den Schaden, wenn doch etwas im Netz landet.

Regeln in der Praxis

Beispiel: nftables auf einem Linux-Server

Moderne Linux-Systeme nutzen nftables. Dieses Beispiel schützt einen Server mit Default Deny: Eingehend ist nur SSH aus dem Verwaltungsnetz und HTTPS aus dem Netz erlaubt. Alle Adressen und Ports sind Beispiele:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 ip saddr 192.168.10.0/26 accept
    tcp dport 443 accept
  }
}

Die Zeile mit policy drop ist das Default Deny: Was keine Regel erlaubt, wird verworfen. ct state established,related accept lässt Antworten auf bestehende Verbindungen durch, das ist die Verbindungstabelle in Aktion. Die Schnittstelle lo ist die lokale Schleife, die der Rechner für sich selbst braucht. Die letzten beiden Regeln erlauben SSH nur aus dem Netz 192.168.10.0/26 (siehe Beitrag CIDR erklärt) und HTTPS von überall. Geladen und geprüft wird das so:

sudo nft -f /etc/nftables.conf
sudo nft list ruleset

Achtung: Wer per SSH auf dem Rechner arbeitet, muss die SSH-Regel vor dem Aktivieren von policy drop haben, sonst sperrt er sich selbst aus. Teste solche Regeln zuerst an einem Rechner, an dem du notfalls physisch ankommst.

Beispiel: Zonenregel am Router

Für den Verkehr zwischen Netzen ist nicht die Kette input, sondern forward zuständig. Die Regel „Arbeitsplätze dürfen auf den Dateiserver zugreifen“ könnte so aussehen, mit den VLAN-Schnittstellen als Beispiel:

chain forward {
  type filter hook forward priority 0; policy drop;
  ct state established,related accept
  iifname "vlan20" oifname "vlan30" ip daddr 192.168.10.140 tcp dport 445 accept
}

Die Regel erlaubt Verbindungen vom Arbeitsplatz-VLAN ins Server-VLAN nur zum Dateiserver 192.168.10.140 und nur auf Port 445. Alles andere wird durch policy drop gesperrt.

Beispiel: Die Windows-Firewall

Unter Windows steuerst du die Host-Firewall in der PowerShell. Mit diesem Befehl (Administratorrechte nötig) erlaubst du SSH nur aus dem Verwaltungsnetz:

New-NetFirewallRule -DisplayName "SSH nur Verwaltung" -Direction Inbound -Protocol TCP -LocalPort 22 -RemoteAddress 192.168.10.0/26 -Action Allow

Den Zustand der drei Profile (Domäne, Privat, Öffentlich) zeigt:

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction

Die Spalte DefaultInboundAction sollte bei Block stehen, das entspricht Default Deny. Ob eine Verbindung durchkommt, prüfst du von einem anderen Rechner mit Test-NetConnection 192.168.10.140 -Port 445 (Windows) oder nc -vz 192.168.10.140 445 (Linux), wie im Beitrag OSI-Modell erklärt gezeigt.

Next-Generation-Funktionen

Moderne Firewalls leisten mehr als Adressen und Ports zu prüfen:

Funktion	Was sie tut	Zu beachten
Anwendungserkennung	Erkennt Programme und Dienste unabhängig vom Port	Braucht aktuelle Signaturen
Intrusion Prevention (IPS)	Erkennt und blockt Angriffsmuster im Datenstrom	Fehlalarme möglich, muss gepflegt werden
URL- und Inhaltsfilter	Sperrt Kategorien von Webseiten oder bekannte Schadseiten	Abwägung mit Datenschutz und Arbeitsalltag
TLS-Inspektion	Entschlüsselt und prüft verschlüsselten Verkehr	Aufwendig, datenschutzrechtlich heikel, schwächt Ende-zu-Ende-Verschlüsselung
Benutzerbezogene Regeln	Regeln nach Benutzer oder Gruppe statt nur nach IP-Adresse	Braucht Anbindung an den Verzeichnisdienst

Diese Funktionen ergänzen die Grundregeln, sie ersetzen sie nicht. Ein sauberes Zonenmodell mit Default Deny ist weiter das Fundament.

Regelpflege: Eine Firewall veraltet

Ein Regelwerk wächst mit der Zeit. Jede „nur kurz“ eingerichtete Ausnahme bleibt, und nach Jahren versteht niemand mehr, wofür welche Regel gut ist. Gute Pflege sieht so aus:

• Jede Regel dokumentieren: Zweck, Auftraggeber, Datum und möglichst ein Ablaufdatum.
• Treffer zählen. Die meisten Firewalls zeigen, wie oft eine Regel gegriffen hat. Eine Regel ohne Treffer in 90 Tagen ist ein Kandidat zum Prüfen und Löschen.
• Überdeckte Regeln finden. Steht eine allgemeine Regel vor einer speziellen, kommt die spezielle nie zum Zug (englisch shadowed).
• Änderungen kontrolliert durchführen: Vier-Augen-Prinzip, Test, Dokumentation.
• Konfiguration sichern. Das Regelwerk gehört ins Backup, nach der 3-2-1-Regel aus dem Beitrag Die 3-2-1-Backup-Regel.
• Protokolle auswerten. Verworfene Pakete verraten Fehlkonfigurationen und Angriffsversuche. Die Meldungen sammelt man zentral, wie im Monitoring-Beitrag beschrieben.
• Regelmäßig überprüfen: Einmal im Jahr das gesamte Regelwerk prüfen.

Praxisbeispiel: Das Regelwerk der Firma

Aus der Matrix oben macht der Administrator ein Regelwerk am Router. Die Reihenfolge ist wichtig, die Zahlen sind die Regelnummern:

Nr.	Quelle	Ziel	Dienst	Aktion	Zweck
1	Alle	Alle	Bestehende Verbindungen	Erlauben	Antworten zulassen
2	Verwaltung (VLAN 10)	Server, Geräte	SSH, RDP	Erlauben	Administration
3	Arbeitsplätze (192.168.10.64/26)	192.168.10.140	TCP 445	Erlauben	Dateizugriff
4	Arbeitsplätze	192.168.10.130	UDP/TCP 53	Erlauben	Namensauflösung
5	Arbeitsplätze, Gäste	Internet	TCP 80, 443, UDP/TCP 53	Erlauben	Webzugriff
6	Geräte (192.168.10.192/26)	Aufnahmeserver	Festgelegter Port	Erlauben	Kameraaufnahmen
7	Gäste	Interne Netze	Alle	Sperren (mit Protokoll)	Gästetrennung
8	Alle	Alle	Alle	Sperren (mit Protokoll)	Default Deny

Die Regeln 7 und 8 schreiben Verworfenes ins Protokoll. Kommen in kurzer Zeit viele Treffer aus dem Gäste-WLAN auf interne Ziele, warnt das Monitoring. Zugriffe aus dem Internet auf das interne Netz sind durch Regel 8 gesperrt, und die Weiterleitung des Webservers führt in die DMZ.

Typische Fehler und Missverständnisse

• Eine Regel „Alle auf alle“ („Any-Any“). Das hebelt die Firewall aus. Oft entsteht sie als „vorübergehende“ Lösung und bleibt.
• Falsche Reihenfolge. Eine allgemeine Sperre vor einer speziellen Erlaubnis macht die Erlaubnis wirkungslos.
• Ausgehenden Verkehr nicht filtern. Dann hat Schadsoftware freie Bahn nach außen.
• Default Allow statt Default Deny. Man vergisst immer etwas.
• Flaches Netz ohne Zonen. Dann hat die Firewall nichts zu trennen. Zonen sind die Voraussetzung.
• ICMP komplett sperren. Das verhindert Fehlermeldungen, die Netze brauchen, etwa zur Anpassung der Paketgröße. Sperre gezielt, nicht pauschal.
• Regeln nie aufräumen. Das Regelwerk wird undurchschaubar und unsicher.
• Verwaltung der Firewall aus dem Internet erreichbar. Die Firewall muss sich selbst am strengsten schützen.
• Logging abschalten oder nie lesen. Die Protokolle zeigen die Wahrheit über den Verkehr.
• Die Firewall für ein Allheilmittel halten. Sie schützt Netze, nicht vor Phishing, schwachen Passwörtern oder Fehlern von Benutzern.

Zum Üben

1. Erkläre Default Deny und warum es sicherer ist als Default Allow.
2. Warum braucht eine zustandsbehaftete Firewall keine eigene Regel für die Antworten auf eine Anfrage?
3. Gegeben sind die Regeln: (1) erlaube TCP 443 von 192.168.10.64/26 nach überall, (2) sperre alles von 192.168.10.64/26 nach 192.168.10.128/26, (3) erlaube TCP 445 von 192.168.10.64/26 nach 192.168.10.128/26, (4) sperre alles. Wie wird ein Paket von 192.168.10.77 an 192.168.10.140 auf TCP 445 behandelt, und was stimmt mit den Regeln nicht?
4. Darf ein Gast-Gerät laut Regelmatrix auf den Dateiserver zugreifen?
5. Was ist eine DMZ, und warum steht der Webserver dort?
6. Welche nftables-Kette ist für Verkehr zuständig, der durch einen Router läuft?
7. Was ist eine überdeckte (shadowed) Regel?
8. Was prüfst du bei einer Regel, die seit 90 Tagen keinen Treffer hat?

Lösungen: (1) Default Deny sperrt alles, was nicht ausdrücklich erlaubt ist. Das ist sicherer, weil man nur das Nötige freigeben muss und nichts Vergessenes offen bleibt. (2) Sie merkt sich die Verbindung in der Verbindungstabelle und erkennt die Antwort als Teil davon. (3) Das Paket wird gesperrt, denn Regel 2 greift vor Regel 3. Die Erlaubnis in Regel 3 kommt nie zum Zug. Abhilfe: Regel 3 vor Regel 2 stellen. (4) Nein, die Regelmatrix sperrt Gäste bis auf Webzugriff ins Internet. (5) Eine eigene Zone zwischen Internet und internem Netz für Dienste, die von außen erreichbar sein müssen. Wird der Server gehackt, kommt der Angreifer nicht ins interne Netz. (6) Die Kette forward. (7) Eine Regel, die nie greift, weil eine weiter oben stehende allgemeinere Regel schon alle passenden Pakete behandelt. (8) Ob sie noch gebraucht wird, wer sie angefordert hat und ob sie sich löschen oder verschärfen lässt.

Das solltest du dir merken

• Eine Firewall kontrolliert den Verkehr zwischen Zonen nach Regeln. Grundsatz: Default Deny, beide Richtungen beachten.
• Plane zuerst eine Regelmatrix: Von welcher Zone wohin, womit.
• Stateful Firewalls merken sich Verbindungen und erlauben Antworten automatisch. Die Verbindungstabelle ist begrenzt.
• Dienste, die aus dem Internet erreichbar sein müssen, gehören in eine DMZ.
• Netz-Firewall und Host-Firewall ergänzen sich. Nur beides zusammen schützt gut.
• Die Reihenfolge der Regeln entscheidet. Dokumentiere, prüfe und räume das Regelwerk regelmäßig auf.
• Die Firewall ist ein Baustein und ersetzt weder Updates, starke Anmeldung noch Schulung.

Die stärkste Firewall hilft nicht, wenn ein Mensch freiwillig die Tür öffnet. Wie Betrüger genau das versuchen und woran du es erkennst, zeigt der nächste Beitrag: Phishing erkennen.