Site icon bintorosoft.com

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

Red Snapper

Organized network. 3d render white isolated graphic background

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.

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.

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.

Merker: ZBF ist „Policy zwischen Zonen“

Zone A  →  Zone B  =>  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.

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.

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.

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

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

Sie erhalten

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.

Exit mobile version