Access Control Lists (ACLs) auf Cisco-Routern sind ein zentraler Baustein für Enterprise-Segmentierung: Sie definieren, welche Segmente miteinander sprechen dürfen, und verhindern unkontrollierte laterale Bewegung (z. B. Guest → Internal, IoT → Server). Ein professionelles ACL-Design ist dabei kein „Portliste-Gewürz“, sondern ein Policy-Modell mit klaren Rollen, Standardregeln, Logging-Strategie und Governance (Versionierung, Change Control, UAT). Dieser Leitfaden zeigt ein praxistaugliches Policy-Modell für Segmentierung, typische ACL-Bausteine und die wichtigsten Verifikationsschritte.
Policy-Modell: Von Segmentrollen zu ACL-Regeln
Starten Sie nicht mit Ports, sondern mit Rollen. Jede Rolle hat ein Vertrauensniveau und eine klar definierte Kommunikationsmatrix. Die ACLs sind die technische Umsetzung dieser Matrix.
- Segments (Beispiele): MGMT, USERS, SERVERS, VOICE, IOT, GUEST
- Trust Levels: MGMT (hoch), USERS (mittel), IOT (niedrig), GUEST (sehr niedrig)
- Prinzip: Default Deny zwischen Segmenten, Allow nur für definierte Use-Cases
- Ausnahmen: über Exception-Register (Owner, Grund, Ablaufdatum)
Enterprise-Baseline: Mindestregeln, die fast immer gelten
Diese Regeln sind in vielen Unternehmen Pflicht und bilden die Baseline. Sie sind bewusst generisch und werden über „Allow-Listen“ ergänzt.
- GUEST → RFC1918: deny (nur Internet)
- IOT → Internal: deny, nur Whitelist zu DNS/NTP/Cloud/Print/Payment
- USERS → MGMT: deny (Adminzugang nur aus MGMT)
- MGMT → Network Devices: allow (SSH/SNMP/NetFlow/Syslog nach Bedarf)
- Inter-Segment: deny by default, allow by policy
Platzierung: Wo ACLs auf Cisco-Routern wirken sollen
Die Platzierung entscheidet über Wirkung und Übersicht. In Segmentierungsdesigns werden ACLs typischerweise inbound am L3-Gateway des Segments gesetzt (SVI/Subinterface), weil dort die Rolle eindeutig ist.
- Inbound am Segment-Gateway: Standard für Segmentierung
- Outbound am WAN: eher für Egress-Filter oder NAT-Ownership, nicht für interne Segmentierung
- Regel: pro Segment eine zentrale „IN“-ACL, statt viele verstreute ACLs
Naming-Standard: Lesbarkeit und Governance
ACLs müssen im Incident lesbar sein. Ein konsistenter Naming-Standard reduziert Fehler und beschleunigt Reviews.
- ACL-<SEGMENT>-IN (z. B. ACL-GUEST-IN, ACL-IOT-IN)
- Objekte: SRV-DNS, SRV-NTP, SRV-AD (als Remarks/Struktur)
- Kommentar: Change-ID und Owner als remark in der ACL
CLI: ACL-Header mit Governance-Info
ip access-list extended ACL-IOT-IN
remark OWNER=NETOPS CHANGE-ID=CHG-2026-001234
remark PURPOSE=IOT allow-list to shared servicesPolicy-Template: Guest Segment (nur Internet)
Guest ist das einfachste Segment: alles interne RFC1918 blockieren, Rest erlauben. Optional loggen Sie nur die Denies zu internen Netzen (nicht „deny any any log“ im Dauerbetrieb).
CLI: ACL-GUEST-IN (Beispiel)
ip access-list extended ACL-GUEST-IN
remark Guest: deny RFC1918, allow Internet
deny ip 10.50.0.0 0.0.0.255 10.0.0.0 0.255.255.255 log
deny ip 10.50.0.0 0.0.0.255 172.16.0.0 0.15.255.255 log
deny ip 10.50.0.0 0.0.0.255 192.168.0.0 0.0.255.255 log
permit ip 10.50.0.0 0.0.0.255 anyACL am Gateway anwenden
interface GigabitEthernet0/1.50
description VLAN50-GUEST
ip access-group ACL-GUEST-IN inPolicy-Template: IoT/POS Segment (Whitelist)
IoT/POS ist typischerweise ein „least trust“-Segment. Das Modell ist: nur notwendige Ziele/Ports erlauben (DNS/NTP/Cloud/Payment), alles interne ansonsten blocken. Definieren Sie Ziele bevorzugt als Servernetze, nicht als einzelne Hosts.
CLI: ACL-IOT-IN (Beispiel, konzeptionell)
ip access-list extended ACL-IOT-IN
remark IoT: allow-list to shared services, deny internal by default
remark Allow DNS to enterprise resolvers
permit udp 10.40.0.0 0.0.0.63 10.1.1.10 0.0.0.0 eq 53
permit tcp 10.40.0.0 0.0.0.63 10.1.1.10 0.0.0.0 eq 53
remark Allow NTP
permit udp 10.40.0.0 0.0.0.63 10.1.1.20 0.0.0.0 eq 123
remark Deny access to RFC1918 (except explicit allows above)
deny ip 10.40.0.0 0.0.0.63 10.0.0.0 0.255.255.255 log
deny ip 10.40.0.0 0.0.0.63 172.16.0.0 0.15.255.255 log
deny ip 10.40.0.0 0.0.0.63 192.168.0.0 0.0.255.255 log
remark Allow Internet (if IoT needs it)
permit ip 10.40.0.0 0.0.0.63 any
Policy-Template: Management Segment (MGMT Only)
MGMT ist das vertrauenswürdigste Segment, aber auch das kritischste. Das Modell ist: nur Admin- und Monitoring-Traffic zu definierten Zielen erlauben. Kein generelles „MGMT darf alles“.
- Erlauben: SSH/SNMPv3/Syslog/NTP zu Netzwerkgeräten und zentralen Systemen
- Blockieren: MGMT → Users/Guest/IoT (außer definierte Use-Cases)
- Zusätzlich: VTY Access-Class nur aus MGMT-Netzen (separater Schutz)
Logging-Strategie: Loggen, ohne den Betrieb zu fluten
ACL-Logging ist wichtig für Audits und Fehlersuche, aber „deny any any log“ kann Log-Stürme erzeugen. Loggen Sie gezielt: Denies zu internen Netzen oder kritischen Zielen, und nutzen Sie zentrale Syslog-Korrelation.
- Loggen: policy-relevante Denies (Guest→RFC1918, IoT→Internal)
- Nicht loggen: generisches Default-Deny in sehr chatty Segmenten
- Pflicht: NTP synchronized + Syslog zentral, sonst sind Logs unbrauchbar
CLI: Log-Readiness (Pflicht)
show ntp status
show logging | last 50Governance: Policy-Matrix, Versionierung und Exceptions
ACLs sind „Policy as Code“. Ohne Governance entsteht Drift: Sonderregeln bleiben ewig, Änderungen sind nicht nachvollziehbar. Ein Enterprise-Modell braucht Policy-Matrix, Change Control und ein Exception-Register.
- Policy-Matrix: Quelle/Ziel/Ports/Owner/Logging
- Version Control: ACL-Änderungen nur via Change-ID, Peer-Review
- Exception-Register: Abweichung, Owner, Grund, Ablaufdatum, Rückbauplan
- UAT: Testfälle pro Segment (Guest-Isolation, IoT-Whitelist, Adminzugriff)
Abnahme/UAT: Tests, die Segmentierung belegen
Segmentierung ist nur abgenommen, wenn sie getestet wurde. Nutzen Sie definierte Testziele (interne RFC1918, DNS/NTP, zentrale Apps) und speichern Sie Evidence.
- Guest: Internet ok, interne Netze blockiert
- IoT: DNS/NTP ok, Zugriff nur auf Whitelist-Ziele, intern blockiert
- Users: Business-Apps ok, kein Zugriff auf MGMT
- MGMT: SSH/SNMP ok, Zugriff nur auf definierte Ziele
CLI: Verifikation der ACL-Wirkung
show access-lists
show running-config | include ip access-group|ip access-list
show ip interface brief
show logging | include ACL|DENYTypische Fehlerbilder (und wie Sie sie vermeiden)
Die häufigsten ACL-Probleme entstehen durch falsche Platzierung, fehlende Rückwege oder unvollständige Policies. Nutzen Sie diese Liste als Design-Review-Check.
- ACL am falschen Interface/Direction: Policy wirkt nicht oder blockt unerwartet
- Zu grobe Regeln: „permit ip any any“ untergräbt Segmentierung
- Kein DNS/NTP erlaubt: scheinbar „Internet kaputt“ in Segmenten
- Unkontrollierte Ausnahmen: Sonderregeln ohne Ablaufdatum
- Logging-Flut: unbrauchbare Logs, Performance-Impact
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.
