Policy-Typen, NAT-Konzepte, Netzwerksegmentierung und Interface-Konfiguration der Firebox.
Policies sind das Herzstück der Firebox-Konfiguration. Sie legen fest, welcher Datenverkehr erlaubt oder blockiert wird – basierend auf Quelle, Ziel, Port und Protokoll.
Die Firebox unterscheidet grundsätzlich zwischen zwei Verarbeitungstiefen:
Paketfilter – prüft nur den Header eines Pakets (IP-Adressen, Ports, Protokoll). Schnell, aber ohne Inhaltsprüfung. Geeignet für unkritischen Traffic wie DNS oder NTP.
Proxy-Policy – öffnet jedes Paket, entfernt den Netzwerk-Header und untersucht den Inhalt (Application Layer Gateway). Ermöglicht den Einsatz von Security Services wie Gateway AntiVirus, IPS oder WebBlocker. Die Standardkonfiguration nutzt Proxy-Policies für HTTP, HTTPS und SMTP.
| Typ | Richtung | Anwendung |
|---|---|---|
| Outbound | Intern → Internet | Surfen, E-Mail senden, Cloud-Dienste |
| Inbound | Internet → Intern | Erreichbarkeit von Servern (Webserver, Mail) |
| Custom | Intern ↔ Intern | Traffic zwischen VLANs oder Standorten |
| First Run | Höchste Priorität | Ausnahmen, die immer greifen sollen |
| Last Run | Niedrigste Priorität | Auffang-Regeln für nicht gematchten Traffic |
Die Standardnamen der Policies (z.B. „HTTP-proxy-00") sind wenig aussagekräftig. Verwenden Sie beschreibende Namen, die den Zweck, die betroffene Benutzergruppe oder das Netzwerksegment widerspiegeln – z.B. „Outbound-Trusted-Web" oder „VPN-Vertrieb-zu-ERP".
NAT übersetzt IP-Adressen und Ports beim Durchgang durch die Firewall – unverzichtbar, wenn interne Geräte mit privaten IPs ins Internet kommunizieren oder externe Anfragen an interne Server weitergeleitet werden sollen.
Die häufigste NAT-Variante: Alle ausgehenden Verbindungen aus dem internen Netz werden hinter der externen IP-Adresse der Firebox „versteckt". Die Firebox merkt sich die Zuordnung und leitet Antworten zurück an den richtigen Client. Wird standardmäßig für Outbound-Traffic verwendet.
Leitet eingehenden Traffic an einem bestimmten Port an einen internen Server weiter. Typische Anwendung: Port 443 aus dem Internet soll an den internen Webserver 192.168.1.10:443 weitergeleitet werden. Wird in Inbound-Policies konfiguriert.
Bildet eine öffentliche IP-Adresse vollständig auf eine interne IP-Adresse ab – alle Ports inklusive. Nützlich, wenn ein Server unter einer eigenen öffentlichen IP erreichbar sein soll, ohne einzelne Port-Weiterleitungen konfigurieren zu müssen.
Die Firebox arbeitet mit Sicherheitszonen, die über physische oder virtuelle Interfaces definiert werden.
| Zone | Zweck | Sicherheitslevel |
|---|---|---|
| External | Internet-Anbindung (WAN) | Untrusted |
| Trusted | Internes LAN, Arbeitsplätze | Trusted |
| Optional | DMZ, Gast-WLAN, Server-Segment | Semi-Trusted |
| Custom | Frei definierbare Zone | Konfigurierbar |
Die Firebox bietet in der Regel mehrere physische Interfaces, die Sie für die Segmentierung Ihres Netzwerks nutzen sollten. Trennen Sie mindestens das interne LAN vom Gast-Netzwerk und stellen Sie öffentlich erreichbare Server (Webserver, Mail-Relay) in eine eigene DMZ (Optional-Zone). Für jedes Segment können unterschiedliche Security-Policies gelten.
Wenn physische Interfaces nicht ausreichen, können Sie VLANs auf einem Interface konfigurieren. Jedes VLAN erhält eine eigene Sicherheitszone und kann separat über Policies gesteuert werden. So lassen sich auch mit wenigen physischen Ports komplexe Netzwerktopologien abbilden.
Aliase fassen IP-Adressen, Netzwerke oder Benutzergruppen unter einem Namen zusammen – für übersichtlichere Policies.
Die Firebox liefert Standard-Aliase wie Any-Trusted, Any-Optional, Any-External und Any. Diese werden häufig in Standard-Policies verwendet, erlauben aber unter Umständen mehr Traffic als beabsichtigt.
Empfehlung: Ersetzen Sie in produktiven Policies die breiten Aliase wie „Any" durch spezifische Aliase, die nur die tatsächlich benötigten Quellen und Ziele enthalten.
Für wiederkehrende Gruppen (z.B. „Drucker-Netz", „Management-Server", „VPN-Benutzer") sollten Sie eigene Aliase anlegen. Damit bleiben Ihre Policies lesbar und Änderungen am Netzwerk müssen nur an einer Stelle gepflegt werden – nicht in jeder einzelnen Policy.