Site-to-Site Absicherung: Firewall-Zonen vs. ACL (Einordnung)

Bei Site-to-Site-Verbindungen (meist IPsec) reicht „Tunnel steht“ nicht aus: Du brauchst eine klare Security-Policy für den Verkehr zwischen lokalen und entfernten Netzen. Auf Cisco Routern wird diese Policy entweder klassisch mit ACLs umgesetzt (zustandslos, interface-basiert) oder moderner/strukturierter über Firewall-Zonen (Zone-Based Firewall, zustandsbehaftet). Welche Variante besser passt, hängt von Komplexität, Audit-Anforderungen, Troubleshooting und dem gewünschten Sicherheitsniveau ab.

Was genau muss bei Site-to-Site „abgesichert“ werden?

Ein Tunnel ist nur der Transport. Die eigentliche Sicherheitsfrage ist: Welche Protokolle/Ports dürfen zwischen Site A und Site B laufen? Ohne explizite Policy kann ein Tunnel schnell zu einer „flachen“ Verbindung werden, in der sich Malware oder Fehlkonfigurationen ungehindert ausbreiten.

• Segmentierung: nur benötigte Subnetze und Services erlauben
• Least Privilege: Ports/Protokolle minimal halten
• Monitoring: nachvollziehbare Regeln und Logs
• Resilienz: keine ungewollten Seiteneffekte auf Internet-Traffic

ACLs: Einfach, schnell, aber zustandslos

ACLs sind auf Routern der klassische Weg: Du filterst Traffic auf einem Interface (in/out) oder über spezielle Kontexte (z. B. crypto ACL ist jedoch keine Security-ACL). ACLs sind aber zustandslos: Rückverkehr wird nicht automatisch erlaubt, und komplexe Policies werden schnell unübersichtlich.

• Vorteile: schnell, transparent, wenig Overhead
• Nachteile: zustandslos, schwerer zu pflegen bei vielen Regeln
• Bestens geeignet: wenige, klare Freigaben (z. B. „nur RDP/SMB“)

Wichtige Klarstellung: Crypto ACL ≠ Firewall-Policy

Die Crypto ACL (interesting traffic) definiert, was verschlüsselt wird. Sie ist keine Zugriffskontrolle. Du brauchst zusätzlich ACL/ZBF, um Traffic zu erlauben oder zu blockieren.

Beispiel: ACL zwischen lokalen und Remote-Subnetzen (inbound am LAN)

ip access-list extended S2S_POLICY_IN
 permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 445
 permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 3389
 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
 permit ip any any
interface gigabitEthernet0/0

ip access-group S2S_POLICY_IN in

Firewall-Zonen (Zone-Based Firewall): Strukturierter und zustandsbehaftet

Zone-Based Firewall (ZBF) arbeitet mit Zonen und Policies zwischen Zonen. Der zentrale Vorteil ist Statefulness: Rückverkehr zu erlaubten Sessions wird automatisch zugelassen. Außerdem ist die Policy-Logik für Audits oft klarer, weil du „LAN → VPN“, „LAN → Internet“ usw. als Zonenbeziehungen modellierst.

• Vorteile: zustandsbehaftet, klare Zonenlogik, bessere Skalierung
• Nachteile: komplexer, mehr Konfig, mehr Betriebsdisziplin nötig
• Bestens geeignet: mehrere Zonen, viele Services, Audit/Compliance

Merker: ZBF ist „Policy zwischen Zonen“

$\text{Zone A} \to \text{Zone B} => \text{inspect / pass / drop}$

Beispiel: Zonen und Zone-Pair (Prinzip)

zone security Z_LAN
zone security Z_VPN
class-map type inspect match-any CM_S2S_ALLOWED

match protocol tcp

match protocol icmp
policy-map type inspect PM_LAN_TO_VPN

class type inspect CM_S2S_ALLOWED

inspect

class class-default

drop
zone-pair security ZP_LAN_VPN source Z_LAN destination Z_VPN

service-policy type inspect PM_LAN_TO_VPN

Einordnung: Wann ACLs reichen – und wann Zonen sinnvoll sind

In vielen kleinen Site-to-Site-Setups reichen ACLs aus, wenn du nur wenige, gut verstandene Freigaben brauchst. Sobald du aber mehrere Netze, unterschiedliche Trust-Zonen oder komplexe Protokolle hast, wird ZBF oft übersichtlicher und sicherer, weil sie zustandsbehaftet arbeitet.

• ACL: wenige Regeln, wenig Zonen, schnelle Umsetzung
• ZBF: mehrere Segmente (LAN/DMZ/VPN/Internet), viele Services
• ZBF: besser bei Statefulness-Anforderungen (weniger „Rücktraffic-Fallen“)

Typische Denkfehler in Site-to-Site-Policies

Viele Probleme entstehen durch falsche Zuständigkeiten: Crypto ACL wird als Security missverstanden, oder eine ACL wird am falschen Interface in falscher Richtung gesetzt. ZBF kann dagegen „alles blocken“, wenn Zone-Pairs fehlen.

• Crypto ACL als Firewall genutzt (falsch)
• ACL auf falscher Seite (LAN statt VPN/oder falsche Richtung)
• Zu breite Permits („permit ip any any“) innerhalb des Tunnels
• ZBF: fehlendes Zone-Pair → Traffic wird gedroppt
• ZBF: falsche Zone-Zuordnung am Interface

Praxis-Muster: Minimal sichere Site-to-Site Policy

Ein praxistauglicher Minimalstandard ist: nur definierte Subnetze in der Crypto ACL, zusätzlich eine Security-Policy (ACL oder ZBF), die nur benötigte Dienste erlaubt, und Logging/Verifikation der Counters.

• Crypto ACL: nur „interessante“ Subnetze (kein Wildcard-Overreach)
• Security Policy: Ports/Protokolle minimal, deny für Rest zwischen Sites
• Logging: Drops sichtbar machen, aber gezielt (nicht alles loggen)

Verifikation: Woran erkennst du, dass die Policy wirklich wirkt?

Nach dem Rollout prüfst du: Tunnel/SAs stehen, Counters steigen bei legitimen Verbindungen, und unerlaubter Traffic wird geblockt (mit Hits/Logs). Ohne Verifikation ist eine Policy nur Theorie.

IPsec Status prüfen

Router# show crypto isakmp sa
Router# show crypto ipsec sa

ACL-Hits oder ZBF-Counters prüfen

Router# show ip access-lists
Router# show policy-map type inspect zone-pair

Traffic-Tests (Beispiel)

Router# ping 192.168.20.10 source 192.168.10.1
Client$ nc -vz 192.168.20.10 445
Client$ nc -vz 192.168.20.10 3389

Quick-Reference: Entscheidungsfragen

• Brauchst du Statefulness und saubere Zonenmodelle? → ZBF
• Hast du nur wenige, klar definierte Freigaben? → ACL kann reichen
• Musst du Audits/Compliance sauber abbilden? → ZBF oft besser
• Willst du schnell und minimalistisch bleiben? → ACL

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.