Firewall-Grundlagen: Regeln, Zonen und Next-Gen-Features

Warum “Firewall” heute viel mehr meint als eine Portsperre

Wenn du im Support oder als Admin mit Firewalls arbeitest, reicht das Bild “die Kiste blockt böse Pakete” nicht mehr aus. Eine moderne Firewall im KMU ist gleichzeitig Zonenwächter, Layer-7-Traffic-Klassifizierer, TLS-Terminierungspunkt, IPS-Sensor und zentrale Log-Quelle für dein SIEM. Wer die Architektur dahinter nicht versteht, baut Regeln, die entweder zu offen (Sicherheitsrisiko) oder zu restriktiv (Ticketflut) sind.

Dieser Artikel geht auf Fortgeschrittenen-Niveau durch: wie Stateful Inspection technisch funktioniert, wie du ein sauberes Zonenkonzept aufbaust, wie ACLs und Regel-Reihenfolge wirklich ausgewertet werden, was NGFW-Features wie App-Control und SSL-Inspection konkret tun, wie IDS/IPS sich unterscheiden und wie du Regelwerke über Jahre hinweg wartbar hältst statt sie verkommen zu lassen.

Stateful Inspection: das Fundament

Vom zustandslosen Paketfilter zur Verbindungstabelle

Ein klassischer Paketfilter (wie frühe Router-ACLs) prüft jedes Paket isoliert: Quell-IP, Ziel-IP, Port, Protokoll - passt eine Regel, wird das Paket durchgelassen oder verworfen. Das Problem: Bei TCP muss die Firewall auch die Antwortpakete durchlassen, und dafür bräuchte man theoretisch für jede Verbindung eine Rückregel mit vertauschten Quell-/Zielangaben. Das ist fehleranfällig und öffnet unnötig viele Ports dauerhaft.

Stateful Inspection (auch SPI, Stateful Packet Inspection) löst das, indem die Firewall den Zustand jeder Verbindung in einer State-Tabelle (Connection Table) mitführt. Beim ersten Paket eines TCP-Handshakes (SYN) wird ein neuer State-Eintrag angelegt. Passende Antwortpakete (SYN-ACK, ACK, Payload) werden automatisch zugelassen, ohne dass dafür eine explizite Regel in die andere Richtung existieren muss.

Ein typischer State-Tabelleneintrag sieht konzeptionell so aus:

Proto  Quelle              Ziel                  Status        Timeout
TCP    192.168.10.15:51422 203.0.113.50:443      ESTABLISHED   3600s
UDP    192.168.10.20:33210 8.8.8.8:53            NEW           30s
TCP    192.168.10.15:51500 198.51.100.10:22      SYN_SENT      30s

Für UDP und ICMP, die keinen echten Verbindungsaufbau kennen, simuliert die Firewall einen “Pseudo-State” über kurze Timeouts - eine DNS-Antwort wird z.B. nur akzeptiert, wenn kurz zuvor eine passende Anfrage rausging.

Warum das für Regelwerke entscheidend ist

Weil die Firewall den Zustand kennt, brauchst du in der Regel nur eine Regel pro Richtung des Verbindungsaufbaus. Eine einzige Regel “LAN → WAN, Port 443, allow” reicht - die Rückantwort wird automatisch über die State-Tabelle erlaubt. Das ist der Grund, warum du in modernen Firewall-GUIs praktisch nie eine explizite “Antwort erlauben”-Regel siehst.

Auf einer FortiGate prüfst du die Session-Tabelle so:

# Anzahl aktiver Sessions
get system performance status

# Sessions nach Quelle filtern
diagnose sys session filter src 192.168.10.15
diagnose sys session list

Zonenkonzept: LAN, WAN, DMZ und mehr

Warum Zonen statt einzelner Interfaces?

Früher wurden Regeln oft pro physischem Interface definiert (“eth0 → eth1”). Moderne Firewalls arbeiten mit Sicherheitszonen: logischen Gruppen von Interfaces/Netzen mit gleichem Vertrauensniveau. Das macht Regelwerke lesbarer und skalierbarer, weil du nicht bei jedem neuen VLAN alle Regeln neu verdrahten musst - du hängst das Interface einfach in die passende Zone.

Die klassische Dreiteilung:

Das Prinzip der DMZ

Die DMZ (Demilitarisierte Zone) ist der zentrale Baustein, um Server, die von aussen erreichbar sein müssen, vom internen Netz zu trennen. Die Grundregel: Ein Angreifer, der einen DMZ-Server kompromittiert, darf nicht automatisch Zugriff auf das interne LAN bekommen.

Internet ── WAN-Zone ──► [Firewall] ──► DMZ-Zone ── Mailrelay, Reverse Proxy
                              │
                              └────────► LAN-Zone ── Clients, Fileserver, DC

Praktisch bedeutet das für dein Regelwerk:

• WAN → DMZ: erlaubt, aber nur auf die konkret benötigten Ports (z.B. 443 auf den Reverse Proxy)
• DMZ → LAN: standardmässig verboten, Ausnahmen nur explizit und minimal (z.B. Mailrelay darf auf Port 25/587 zum internen Exchange sprechen)
• LAN → DMZ: meist erlaubt, damit interne Nutzer die Dienste auch nutzen können
• DMZ → WAN: eingeschränkt auf das Nötige (Updates, DNS), kein freier Internetzugang für DMZ-Server

Zonen bei Next-Gen-Firewalls konkret konfigurieren

Bei FortiGate werden Zonen über Interface-Gruppen abgebildet:

config system zone
    edit "DMZ"
        set interface "port3" "port4"
    next
end

config firewall policy
    edit 0
        set name "WAN-to-DMZ-HTTPS"
        set srcintf "wan1"
        set dstintf "DMZ"
        set srcaddr "all"
        set dstaddr "dmz-webserver"
        set service "HTTPS"
        set action accept
        set schedule "always"
        set logtraffic all
    next
end

Bei einer klassischen ACL-basierten Firewall (z.B. Cisco ASA/ASAv) ist das Zonenkonzept über Security Levels pro Interface abgebildet (0-100), wobei Traffic von höherem zu niedrigerem Level standardmässig erlaubt ist und umgekehrt geblockt wird - auch hier greift Stateful Inspection für die Rückrichtung.

ACLs und Regel-Reihenfolge: das First-Match-Prinzip

Wie eine Regelkette wirklich ausgewertet wird

Das ist der Punkt, an dem die meisten Fehlkonfigurationen entstehen: Firewall-Regelwerke werden von oben nach unten ausgewertet, und die erste passende Regel gewinnt (First-Match-Prinzip). Alle danach folgenden Regeln werden für dieses Paket nicht mehr geprüft - auch wenn sie eigentlich spezifischer wären.

Regel 1: LAN → WAN, any, any        → ALLOW
Regel 2: LAN → WAN, 192.168.10.99, 443 → DENY   ← wird NIE erreicht!

In diesem Beispiel ist Regel 2 komplett wirkungslos, weil Regel 1 bereits alles durchlässt. Das nennt man Shadowing - eine Regel wird von einer davor liegenden, breiteren Regel “beschattet” und kommt nie zum Zug.

Implizites vs. explizites Deny

Jede vernünftige Firewall hat am Ende der Kette ein implizites Deny - Traffic, der zu keiner Regel passt, wird verworfen. Trotzdem ist es Best Practice, ein explizites “Deny All” mit Logging als letzte Regel zu setzen:

# Beispiel: explizite Abschlussregel (pseudo-Syntax, universell übertragbar)
Regel 999: any → any, any, any → DENY, log=yes, name="Default-Deny-Logged"

Der Grund: Das implizite Deny wird bei den meisten Systemen nicht oder nur rudimentär geloggt. Ein explizites, benanntes Deny-All macht im Log sofort sichtbar, welcher Traffic überhaupt an die Grenzen deines Regelwerks stösst - unverzichtbar für Troubleshooting und Security-Monitoring.

Klassische ACL-Syntax am Beispiel Cisco IOS

Auch wenn du primär mit GUI-basierten NGFWs arbeitest, begegnet dir klassische ACL-Syntax auf Routern und Switches noch oft:

! Erlaubt HTTPS von einem Management-Subnetz zu einem Server
access-list 101 permit tcp 192.168.99.0 0.0.0.255 host 10.0.0.50 eq 443

! Verbietet Telnet komplett (unverschlüsseltes Management-Protokoll)
access-list 101 deny tcp any any eq 23

! Erlaubt etablierte Rückverbindungen (bei zustandslosen Router-ACLs nötig!)
access-list 101 permit tcp any any established

! Abschluss: alles andere verwerfen und loggen
access-list 101 deny ip any any log

Beachte: Router-ACLs sind oft zustandslos - das Keyword established prüft nur, ob das ACK-Flag gesetzt ist, was durch Spoofing umgangen werden kann. Das ist ein wichtiger Unterschied zur echten Stateful Inspection auf einer dedizierten Firewall.

Regel-Auswertung als Entscheidungsbaum

Neues Paket kommt an
        │
        ▼
Existiert bereits ein State-Tabellen-Eintrag
für diese Verbindung?
        │
   ┌────┴─────┐
  JA          NEIN
   │            │
   ▼            ▼
Traffic     Regelwerk von oben nach unten durchgehen
zulassen         │
(State-Match)    ▼
            Regel 1 passt Quelle/Ziel/Port/Zone?
                 │
            ┌────┴─────┐
           JA          NEIN → nächste Regel prüfen
            │
            ▼
      Aktion ausführen (Allow/Deny)
      + optional: NGFW-Checks (App-ID, IPS, SSL-Inspection)
      + neuen State-Eintrag anlegen (falls Allow)

NGFW-Features: App-Control und SSL-Inspection

Application Control: mehr als Port-Filterung

Klassische Firewalls filtern nach Port und Protokoll - Port 443 ist “HTTPS”, fertig. Das Problem: Heute läuft praktisch alles über 443, egal ob es sich um normalen Webverkehr, Youtube, TikTok, Anydesk-Fernwartung oder eine Schatten-IT-Cloud-Anwendung handelt. Eine Portregel kann diese Anwendungen nicht unterscheiden.

App-Control (Application Control, App-ID) erkennt Anwendungen anhand von Signaturen, Verhaltensmustern und TLS-Metadaten (SNI, Zertifikats-Fingerprints) - unabhängig vom verwendeten Port. Damit kannst du Regeln formulieren wie:

• “Erlaube Microsoft Teams, aber blockiere generisches Filesharing wie WeTransfer”
• “Erlaube Youtube nur für die Marketing-Gruppe, blockiere es sonst”
• “Blockiere alle Fernwartungs-Tools ausser der von der IT freigegebenen Lösung”

Beispiel einer App-Control-Policy auf FortiGate:

config firewall policy
    edit 0
        set name "LAN-Internet-AppControl"
        set srcintf "lan"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set service "ALL"
        set action accept
        set application-list "block-remote-tools"
        set ssl-ssh-profile "deep-inspection"
        set av-profile "default"
        set ips-sensor "default"
        set logtraffic all
    next
end

SSL-Inspection: verschlüsselten Traffic prüfen

Über 90% des heutigen Webtraffics ist TLS-verschlüsselt. Ohne SSL-Inspection sieht die Firewall bei HTTPS nur den Ziel-Hostnamen aus dem TLS-SNI-Feld - der eigentliche Inhalt, verschlüsselte Payloads mit Malware oder Datenexfiltration, bleibt unsichtbar.

Funktionsprinzip (identisch zum SSL-Bumping bei Proxies):

1. Client baut eine TLS-Verbindung zur Firewall auf (der Zielhost wird über SNI erkannt)
2. Die Firewall baut selbst eine zweite, echte TLS-Verbindung zum Zielserver auf
3. Sie generiert dynamisch ein Zertifikat für die Ziel-Domain, signiert mit einer internen CA
4. Der Client muss dieser internen CA vertrauen (Root-Zertifikat per GPO verteilt)
5. Die Firewall kann jetzt beide Seiten im Klartext einsehen, prüfen (AV, IPS, DLP) und re-verschlüsseln

Client ◄──[Firewall-CA-Zert]──► Firewall ◄──[Echtes Zertifikat]──► Zielserver
         (verschlüsselt)                     (verschlüsselt)
                    ▲
              Klartext-Inspektion hier

Root-Zertifikat per GPO im Unternehmen verteilen:

# Zertifikat für alle Domain-Rechner verteilen (GPO: Computerkonfiguration >
# Windows-Einstellungen > Sicherheitseinstellungen > Richtlinien für
# öffentliche Schlüssel > Vertrauenswürdige Stammzertifizierungsstellen)

# Manueller Import zum Testen:
Import-Certificate -FilePath "C:\Certs\Firewall-CA.cer" `
    -CertStoreLocation Cert:\LocalMachine\Root

Zertifikats-Pinning ist ein praktisches Problem: Manche Apps (z.B. bestimmte Banking-Apps, Windows Update, Zertifikats-transparente Dienste) akzeptieren das dynamisch generierte Zertifikat nicht und brechen ab. Für solche Ziele musst du SSL-Inspection-Ausnahmen (“SSL Exemption List”) pflegen.

IDS und IPS: Erkennen vs. Verhindern

Der zentrale Unterschied

Die meisten NGFWs bringen eine integrierte IPS-Engine mit, die signaturbasiert (bekannte Exploit-Muster, CVEs) und teilweise anomaliebasiert arbeitet. Klassiker im Open-Source-Bereich sind Suricata und Snort, die z.B. auf pfSense/OPNsense als Paket nachgerüstet werden.

IPS-Signatur-Beispiel und Sensor-Konfiguration

Eine Suricata-Regel, die einen bekannten Exploit-Versuch gegen einen veralteten SMB-Dienst erkennt, sieht konzeptionell so aus:

alert tcp any any -> $HOME_NET 445 (msg:"ET EXPLOIT Possible ETERNALBLUE MS17-010 Probe";
    flow:to_server,established; content:"|00 00 00 00|"; depth:4;
    classtype:trojan-activity; sid:2024218; rev:3;)

Auf einer FortiGate aktivierst du IPS pro Policy über einen IPS-Sensor und wählst dabei üblicherweise ein vordefiniertes Profil, angepasst an Server- oder Client-Schutz:

config ips sensor
    edit "protect-servers"
        set comment "IPS-Schutz fuer Server-Segment"
        config entries
            edit 1
                set severity high critical
                set action block
                set log enable
            next
        end
    next
end

Regelmanagement und Cleanup: Disziplin über Jahre

Warum Regelwerke verwahrlosen

In der Praxis wächst ein Firewall-Regelwerk über Jahre organisch: neue Projekte, temporäre Ausnahmen “nur für den Test”, Mitarbeitende die kündigen und deren persönliche Regeln liegen bleiben. Nach 3-5 Jahren hat ein typisches KMU-Regelwerk hunderte Regeln, von denen ein erheblicher Teil nie mehr benötigt wird, aber trotzdem Angriffsfläche bietet und die Fehlersuche massiv erschwert.

Der Cleanup-Prozess Schritt für Schritt

1. Hit-Counter auswerten. Fast jede Firewall zeigt pro Regel, wann sie zuletzt getroffen wurde und wie oft. Regeln ohne Treffer seit 6-12 Monaten sind Kandidaten für die Entfernung.
2. Shadowing und Redundanzen identifizieren. Prüfe, ob Regeln von breiteren, weiter oben liegenden Regeln bereits abgedeckt sind.
3. Business-Owner ermitteln. Für jede fragliche Regel: Wer hat sie angefordert, wofür wird sie noch gebraucht? Ohne dokumentierten Owner ist eine Regel ein Cleanup-Kandidat.
4. Nicht sofort löschen - deaktivieren. Setze die Regel auf “disabled” statt sie zu löschen, dokumentiere Datum und Grund, warte eine definierte Frist (z.B. 4 Wochen) und beobachte, ob sich jemand meldet oder ein Fehler auftaucht.
5. Change-Management-Prozess einhalten. Jede Änderung (auch Deaktivierung) sollte durch ein Ticket/Change dokumentiert sein: betroffene Regel, Begründung, erwarteter Impact, Rollback-Schritt.
6. Erst nach der Wartefrist endgültig löschen und im Änderungsprotokoll referenzieren.

# Beispiel: Export des FortiGate-Regelwerks zur Offline-Analyse via API
$headers = @{ Authorization = "Bearer $apiToken" }
Invoke-RestMethod -Uri "https://firewall.firma.ch/api/v2/cmdb/firewall/policy" `
    -Headers $headers -Method Get | 
    Select-Object policyid, name, srcintf, dstintf, action, @{n='hitcount';e={$_.hit_count}} |
    Export-Csv -Path "C:\Audit\firewall-rules-export.csv" -NoTypeInformation

Namenskonventionen und Objektgruppen

Ein häufig unterschätzter Hebel: konsequente Namenskonventionen sparen Stunden bei jedem Audit.

Nutze wo möglich Objektgruppen statt Einzel-IPs in Regeln - wenn sich ein Server-Cluster ändert, passt du die Gruppe einmal an statt zehn Regeln einzeln zu bearbeiten.

Entscheidungshilfe: Welche Firewall-Klasse passt zum KMU?

Praxisszenario: Neue DMZ-Anwendung freischalten

Ein typisches Ticket: “Der neue Lieferanten-Webshop muss aus dem Internet erreichbar sein und mit unserem internen ERP-System sprechen können.” So gehst du strukturiert vor:

1. Zone bestimmen: Der Webshop-Server gehört in die DMZ, nicht ins LAN.
2. Exakten Bedarf klären: Welcher Port genau (443)? Welches ERP-Protokoll und welcher Port (z.B. SQL Server auf 1433, oder REST-API auf 8443)?
3. Regeln in der richtigen Reihenfolge anlegen:
   • WAN → DMZ, dst=webshop-srv, port=443, allow, log=yes
   • DMZ → LAN, src=webshop-srv, dst=erp-app-srv, port=8443, allow, log=yes (niemals any als Ziel!)
   • Kein DMZ → LAN any daneben bestehen lassen
4. NGFW-Layer aktivieren: SSL-Inspection auf der WAN→DMZ-Regel, IPS-Sensor mit Server-Profil, ggf. Web Application Firewall (WAF) vor dem Webshop.
5. Testen und Logs prüfen: Verbindung von aussen testen, Session- und IPS-Logs auf unerwartete Blocks prüfen.
6. Dokumentieren: Regelname, Ticketnummer, Owner, Review-Datum in die Firewall-Dokumentation eintragen.
7. Review-Termin setzen: Nach 3-6 Monaten prüfen, ob die Regel noch gebraucht wird.

Weiterlernen

• Cisco: Zone-Based Policy Firewall Design Guide
• Palo Alto Networks: Was ist eine Next-Generation Firewall (NGFW)?
• Fortinet FortiGate/FortiOS Dokumentation
• Suricata: offizielle Dokumentation
• OPNsense: offizielle Dokumentation
• EDÖB: Leitfaden zur Internet- und E-Mail-Überwachung am Arbeitsplatz

Verwandte Themen: Windows Firewall · VLAN-Grundlagen · Routing-Grundlagen · Proxy-Grundlagen · IT-Security Grundlagen KMU · Zero-Trust-Architektur KMU

Videos

YouTube