ACL Reihenfolge & Logik: So vermeidest du Lockouts

ACL-Lockouts passieren fast immer aus zwei Gründen: falsche Reihenfolge oder falsche Annahmen über die Logik. Cisco ACLs werden strikt von oben nach unten ausgewertet, die erste passende Regel gewinnt – und am Ende steht immer ein implizites deny. Wer diese Logik sauber versteht und Changes kontrolliert durchführt (Sequenzen, Test-Regeln, Logging), kann Lockouts zuverlässig vermeiden – selbst auf produktiven Routern.

Die Kernlogik: Top-down, First Match, implizites Deny

Eine ACL ist keine „Sammlung“ von Regeln, sondern eine Prioritätenliste. Sobald eine Zeile matcht, wird entschieden und die Auswertung stoppt. Wenn nichts matcht, wird das Paket verworfen.

• Auswertung: von oben nach unten
• Erste passende Zeile entscheidet (First Match)
• Am Ende: implizit deny ip any any

Merker als Regel

$\text{Match in Zeile n} \to \text{Stop}, \text{kein weiterer Check}$

Warum Reihenfolge so wichtig ist

Eine zu breite Deny-Regel oberhalb einer Permit-Regel macht die Permit-Regel wirkungslos. Das betrifft besonders Management-Zugriffe (SSH), weil du dich schnell selbst aussperrst.

• „deny any“ zu früh → alles wird blockiert
• Allgemeine Regeln müssen unter spezifischen Regeln stehen
• Spezifisch zuerst, allgemein zuletzt ist die sichere Reihenfolge

Beispiel: Falsche Reihenfolge (Lockout-Risiko)

ip access-list standard VTY_MGMT
 deny any
 permit 192.168.10.0 0.0.0.255

Beispiel: Richtige Reihenfolge

ip access-list standard VTY_MGMT
 permit 192.168.10.0 0.0.0.255
 deny any

Implizites Deny: der häufigste Denkfehler

Viele ACLs scheitern nicht an einem falschen Deny, sondern an fehlenden Permits. Wenn du z. B. nur HTTP erlaubst, aber DNS vergisst, „geht Internet nicht“, obwohl HTTPS/HTTP theoretisch erlaubt ist.

• Vergessene Protokolle werden implizit geblockt (DNS, NTP, ICMP)
• „permit ip …“ am Ende ist funktional, aber oft zu grob
• Besser: bewusst definieren, was nötig ist

Typischer Fall: DNS vergessen

ip access-list extended USERS_OUT
 permit tcp 192.168.10.0 0.0.0.255 any eq 443
 deny ip any any

Lockout-Prävention: Management-Zugriff immer zuerst absichern

Wenn du ACLs an Interfaces oder VTY-Lines änderst, musst du zuerst sicherstellen, dass dein aktueller Management-Pfad weiterhin erlaubt ist. Für SSH auf VTY ist die Standardlösung eine separate Standard-ACL als access-class.

SSH nur aus Management-Netz (bewährtes Muster)

Router# configure terminal
Router(config)# ip access-list standard VTY_MGMT
Router(config-std-nacl)# permit 192.168.10.0 0.0.0.255
Router(config-std-nacl)# deny any
Router(config-std-nacl)# end
Router(config)# line vty 0 4

Router(config-line)# access-class VTY_MGMT in

Router(config-line)# transport input ssh

Router(config-line)# end

Sequenznummern: Regeln sicher einfügen statt ACL „neu bauen“

Named ACLs unterstützen Sequenznummern. Damit kannst du Regeln einfügen, ohne die ACL zu löschen oder neu zu schreiben. Das reduziert Change-Risiko massiv.

ACL anzeigen (mit Sequenzen)

Router# show ip access-lists

Neue Permit-Regel sicher oben einfügen

Router# configure terminal
Router(config)# ip access-list extended OUTSIDE_IN
Router(config-ext-nacl)# 5 permit tcp 198.51.100.0 0.0.0.255 host 203.0.113.10 eq 443
Router(config-ext-nacl)# end

Test-Regel und „Safety Net“: kontrolliert deployen

Wenn du eine restriktive ACL neu einführst, ist ein kontrollierter Ansatz sicherer als ein „Big Bang“: erst eine eng begrenzte Permit-Regel für deinen Admin-Host, dann schrittweise weitere Regeln.

• Zuerst: Admin-Source-IP explizit erlauben
• Dann: notwendige Services ergänzen
• Zuletzt: deny/log am Ende setzen

Beispiel: Admin-Host als erstes Permit

ip access-list extended OUTSIDE_IN
 10 permit tcp host 198.51.100.10 host 203.0.113.2 eq 22
 20 deny ip any any

Richtung und Platzierung: in/out entscheidet über Wirkung

Viele Lockouts entstehen, weil eine ACL am richtigen Interface, aber in der falschen Richtung applied wird. Inbound filtert Pakete beim Eintritt ins Interface, outbound beim Verlassen.

• in: filtert bevor Routing-Entscheidung greift
• out: filtert nach Routing-Entscheidung
• Für Management-Zugriff: VTY-ACL ist oft sicherer als Interface-ACL

Interface-Bindung prüfen

Router# show ip interface gigabitEthernet0/0
Router# show running-config interface gigabitEthernet0/0

ACL und Rückverkehr: häufige Falle bei TCP/UDP

ACLs sind zustandslos. Wenn du ausgehend restriktiv filterst, musst du überlegen, ob Rückverkehr (z. B. DNS-Responses, TCP-ACKs) durch deine Regeln noch passt. Auf Routern wird das oft durch „Outbound erlauben, Inbound restriktiv“ oder durch stateful Firewall-Features gelöst.

• DNS: UDP/53 Query raus, UDP/53 Response zurück
• TCP: Rückverkehr kommt mit ephemeren Ports zurück
• ICMP: wird oft für PMTUD benötigt

Beispiel: DNS korrekt berücksichtigen

ip access-list extended USERS_OUT
 permit udp 192.168.10.0 0.0.0.255 any eq 53
 permit tcp 192.168.10.0 0.0.0.255 any eq 53
 permit tcp 192.168.10.0 0.0.0.255 any eq 443
 deny ip any any

Logging: hilfreich, aber mit Bedacht

log ist extrem nützlich, um zu sehen, welche Pakete geblockt werden. Aber zu viel Logging kann CPU belasten und Syslog fluten. Nutze Logging gezielt, vor allem auf deny-Regeln am Ende.

Deny mit Logging setzen

Router# configure terminal
Router(config)# ip access-list extended OUTSIDE_IN
Router(config-ext-nacl)# deny ip any any log
Router(config-ext-nacl)# end

Logs prüfen

Router# show logging | include ACL|ACCESSLIST|DENY

Verifikation: Trefferzähler sind deine Wahrheit

Nach jeder ACL-Änderung prüfst du die Hit-Counters. So siehst du sofort, ob Regeln matchen oder ob du Traffic ungewollt blockierst.

Router# show ip access-lists
Router# show access-lists
Router# show ip interface gigabitEthernet0/0

Praxis-Checkliste: So vermeidest du Lockouts bei ACL-Changes

Diese Reihenfolge ist praxiserprobt und reduziert Risiko deutlich.

• Aktuellen Management-Pfad identifizieren (Source-IP, Interface, Port)
• Admin-Source-IP als erste Permit-Regel hinzufügen
• Named ACL mit Sequenzen nutzen, keine „Copy/Paste-Rewrites“
• ACL erst binden, wenn Permits vollständig sind
• Hit-Counters prüfen, Logging nur gezielt aktivieren
• Fallback-Zugang bereit halten (Console/Out-of-Band)

Copy & Paste: Quick-Checks

show ip access-lists
show running-config | include access-group
show running-config | section line vty
show ip interface gigabitEthernet0/0
show logging | include ACL|ACCESSLIST|DENY

Konfiguration speichern

Wenn Management-Zugriff bestätigt ist und die ACL wie erwartet matcht, speichere die Konfiguration.

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.