Zone-Based Firewall (ZBFW) auf Cisco Routern: Policy-Design für Experten

Zone-Based Firewall (ZBFW) ist auf Cisco Routern das stateful Firewall-Framework, um Traffic nicht mehr „interface-by-interface“ mit ACLs zu filtern, sondern zonenbasiert nach Sicherheitsdomänen zu steuern. Für Experten ist ZBFW vor allem ein Policy-Design-Thema: Welche Zonen existieren, welche Flows sind erlaubt, wo wird inspiziert (stateful) vs. nur gefiltert (stateless), und wie vermeidest du Lockouts sowie Performance-Fallen? Ein sauberer ZBFW-Entwurf bringt Ordnung, Auditierbarkeit und bessere Betriebssicherheit – aber nur, wenn du Zonen, Zone-Pairs, Class-Maps, Policy-Maps und Logging bewusst modellierst. Dieser Artikel zeigt ein praxiserprobtes Designvorgehen inklusive Konfigurationspatterns.

Mentales Modell: Zonen, Zone-Pairs, Policies

ZBFW arbeitet nach dem Prinzip „Traffic zwischen Zonen ist nur erlaubt, wenn ein Zone-Pair mit Policy existiert“. Alles andere wird gedroppt. Das ist der häufigste Stolperstein – und gleichzeitig die wichtigste Sicherheitsgarantie.

• Zone: logische Sicherheitsdomäne (LAN, WAN, VPN, DMZ, MGMT)
• Zone-Pair: Richtungspaar (source-zone → destination-zone)
• Policy-Map: Aktion pro Traffic-Klasse (inspect / pass / drop)
• Class-Map: Matching (Protokoll, ACL, Ports)

Merker

$\text{Allow}\iff \text{Zone-Pair vorhanden}+\text{Policy erlaubt/inspects}$

Policy-Design: Zonenmodell zuerst, Regeln danach

Die häufigste Expertenfalle ist „Regeln schreiben, ohne Zonenmodell“. Das führt zu unübersichtlichen Policies und unklaren Trust-Boundaries. Sauber ist: Zonen definieren, Trust-Level festlegen, dann Flows pro Zone-Pair modellieren.

• Definiere wenige, klare Zonen (nicht 20 Mikro-Zonen ohne Governance)
• Definiere Trust-Level (z. B. LAN hoch, WAN niedrig)
• Definiere Standardprinzip: default drop, nur definierte Flows erlauben

Best-Practice Zonen im Enterprise Edge

Ein bewährtes Basisset ist: LAN, WAN, VPN, DMZ, MGMT. Optional kommen GUEST/IoT oder TRANSIT hinzu. Wichtig ist, dass jede Zone eine klare Bedeutung hat und die Zuordnung der Interfaces stabil bleibt.

• LAN: interne Clients/Server (hoher Trust)
• WAN: Internet/Provider (niedriger Trust)
• VPN: Remote Sites/Users (mittel bis hoch, je nach Modell)
• DMZ: exponierte Services (kontrolliert, segmentiert)
• MGMT: Managementplane (separat, stark eingeschränkt)

inspect vs. pass vs. drop: Die drei Kernaktionen

„inspect“ ist stateful: Rücktraffic wird automatisch erlaubt, solange er zum Zustand passt. „pass“ ist stateless allow (wie eine ACL permit). „drop“ blockt (optional mit Logging). Ein sauberes Design nutzt inspect für Client-initiierte Flows und pass nur gezielt.

• inspect: ideal für LAN→WAN, LAN→DMZ (Client-initiated)
• pass: für explizite statische Flows, wenn State nicht gewünscht ist
• drop: Default, optional log für Security/Forensik

Class-Maps: Match-Strategie für wartbare Policies

Für Experten-Design ist entscheidend, wie du matchst. „match protocol“ ist schnell, aber grob. „match access-group“ (ACL) ist präzise und auditierbar. Best Practice: wenige Class-Maps, die klare Service-Gruppen repräsentieren.

• Service-Klassen: DNS, NTP, Web, VPN, Admin
• Prinzip: „explicit allow“, keine catch-all permits
• ACLs als Dokumentation: Quelle/Ziel/Ports klar lesbar

Konfigurationspattern: Zonen und Interface-Zuordnung

Ordne Interfaces zuerst Zonen zu. Plane dabei Management separat (OOB, VRF, oder dediziertes Interface). Danach definierst du Zone-Pairs und Policies.

zone security Z_LAN
zone security Z_WAN
zone security Z_DMZ
zone security Z_VPN
zone security Z_MGMT

interface GigabitEthernet0/1
 description LAN
 zone-member security Z_LAN

interface GigabitEthernet0/0
 description WAN
 zone-member security Z_WAN

interface GigabitEthernet0/2
 description DMZ
 zone-member security Z_DMZ

Konfigurationspattern: LAN → WAN (stateful) mit Default Drop

Das typische Edge-Pattern ist: LAN darf definierte Services ins WAN (inspect), alles andere drop. Rücktraffic ist durch State erlaubt. So bekommst du ein sauberes Default-Deny-Verhalten am Perimeter.

ACLs für Services (Beispiel)

ip access-list extended ACL_LAN_TO_WAN_DNS
 permit udp 10.10.0.0 0.0.255.255 any eq 53
 permit tcp 10.10.0.0 0.0.255.255 any eq 53
ip access-list extended ACL_LAN_TO_WAN_WEB

permit tcp 10.10.0.0 0.0.255.255 any eq 80

permit tcp 10.10.0.0 0.0.255.255 any eq 443

Class-Maps

class-map type inspect match-any CM_DNS
 match access-group name ACL_LAN_TO_WAN_DNS
class-map type inspect match-any CM_WEB

match access-group name ACL_LAN_TO_WAN_WEB

Policy-Map

policy-map type inspect PM_LAN_TO_WAN
 class type inspect CM_DNS
  inspect
 class type inspect CM_WEB
  inspect
 class class-default
  drop log

Zone-Pair

zone-pair security ZP_LAN_WAN source Z_LAN destination Z_WAN
 service-policy type inspect PM_LAN_TO_WAN

DMZ-Design: Exponieren ohne „DMZ ist LAN“

Eine DMZ ist keine „zweite LAN-Zone“, sondern eine kontrollierte Zone mit minimalen Flows. Typisch sind inbound Services vom WAN zur DMZ (pass/inspect je nach Bedarf) und restriktive DMZ→LAN Regeln.

• WAN→DMZ: nur veröffentlichte Services (z. B. HTTPS)
• DMZ→LAN: nur notwendige Backend-Flows (z. B. DB/LDAP) und am besten explizit
• LAN→DMZ: Admin/Deploy Flows strikt begrenzen

WAN → DMZ (Beispiel, stateless allow)

ip access-list extended ACL_WAN_TO_DMZ_HTTPS
 permit tcp any host 192.0.2.10 eq 443
class-map type inspect match-any CM_WAN_TO_DMZ_HTTPS

match access-group name ACL_WAN_TO_DMZ_HTTPS
policy-map type inspect PM_WAN_TO_DMZ

class type inspect CM_WAN_TO_DMZ_HTTPS

pass

class class-default

drop log
zone-pair security ZP_WAN_DMZ source Z_WAN destination Z_DMZ

service-policy type inspect PM_WAN_TO_DMZ

VPN-Zone: Trust nicht pauschal übernehmen

Eine häufige Designfalle ist „VPN = LAN“. In vielen Umgebungen ist VPN ein eigener Trust-Level. Best Practice: Z_VPN als separate Zone und eigene Zone-Pairs LAN↔VPN, VPN↔WAN, VPN↔DMZ mit expliziten Flows.

• Remote Sites: oft höherer Trust als Remote Users
• Split Tunneling: WAN Zugriff vom VPN bewusst steuern
• Logging: VPN-Flows sind audit-relevant

Self-Zone und Managementplane: Lockouts vermeiden

Traffic zur Router-Control/Managementplane (SSH, SNMP, NTP) ist in ZBFW besonders kritisch. Falsche Policies können dich aussperren. Best Practice ist: Management in eigene Zone/VRF, plus sehr restriktive Self-Zone-Policies.

• MGMT getrennt (OOB oder VRF)
• Self-Zone Zugriffe nur von definierten Admin-IPs
• Timeouts, AAA, VTY ACL zusätzlich nutzen

Self-Zone Zugriff (Pattern)

ip access-list extended ACL_MGMT_TO_SELF
 permit tcp 10.99.0.0 0.0.0.255 host 10.10.10.1 eq 22
class-map type inspect match-any CM_MGMT_TO_SELF

match access-group name ACL_MGMT_TO_SELF
policy-map type inspect PM_MGMT_TO_SELF

class type inspect CM_MGMT_TO_SELF

pass

class class-default

drop log

Performance-Design: Was ZBFW teuer macht

ZBFW ist stateful und kostet Ressourcen. Teuer werden v. a. sehr viele Klassen, zu viel Logging und das Inspizieren von Traffic, der keine State-Mehrwerte hat. Experten-Design heißt: minimal notwendige inspect-Klassen, gezielte pass-Klassen, Logging nur dort, wo es operativ hilft.

• Logging sparsam (sonst CPU/IO und Log-Flood)
• Keine riesigen Match-ACLs ohne Struktur
• Inspect nur für relevante Protokolle
• Monitoring: Drops, CPU, Session-Counts

Troubleshooting: Warum wird etwas gedroppt?

ZBFW-Debugging ist am besten, wenn du von Zone-Pair nach Class-Map gehst: Trifft der Flow überhaupt das richtige Zone-Pair? Welche Class matcht? Wird er gedroppt in class-default? Zusätzlich brauchst du Session-Sicht für inspect.

Policy/Zone-Pair Checks

show zone security
show zone-pair security
show policy-map type inspect zone-pair

Sessions und Drops

show policy-map type inspect zone-pair sessions
show policy-map type inspect zone-pair statistics
show logging | include DROP|ZBFW

Best Practices: Experten-Patterns für wartbare ZBFW Policies

Diese Prinzipien sorgen dafür, dass ZBFW auch nach Jahren noch wartbar bleibt: klare Zonen, klare Service-Gruppen, konsequentes Default-Deny und standardisierte Templates.

• Wenige, stabile Zonen mit klarer Bedeutung
• Pro Zone-Pair eine Policy-Map, Service-Gruppen als Class-Maps
• class-default immer drop (optional log), keine „Any-Any pass“
• Management separat und explizit, Self-Zone minimal
• Änderungen mit Pre/Post Checks (Sessions, Drops, Counters)

Quick-Runbook: ZBFW Incident Isolation

Diese Sequenz hilft, in Minuten zu sehen, ob ein Flow durch falsches Zone-Pair, fehlendes Match oder class-default Drop fällt.

show zone security
show zone-pair security
show policy-map type inspect zone-pair
show policy-map type inspect zone-pair statistics
show policy-map type inspect zone-pair sessions
show access-lists

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.