Site icon bintorosoft.com

ACL Reihenfolge & Logik: So vermeidest du Lockouts

Red Snapper

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.

Merker als Regel

Match in Zeile n  →  Stop ,   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.

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.

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.

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.

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.

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.

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

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