Access Control Lists (ACL) konfigurieren: Cisco Standard ACL erklärt

Wer Netzwerke mit Cisco Routern oder Layer-3-Switches betreibt, kommt an Zugriffsregeln nicht vorbei. Eine der wichtigsten Grundlagen dafür ist das Thema „Access Control Lists (ACL) konfigurieren“. Gerade die Cisco Standard ACL ist häufig der erste Berührungspunkt, weil sie schnell eingerichtet ist und in vielen Alltagsszenarien genügt: Managementzugriffe auf SSH begrenzen, bestimmte Quellnetze von einem Interface ausschließen oder sensible Bereiche nur für definierte IPs öffnen. Gleichzeitig entstehen viele Störungen genau hier, weil Standard ACLs eine klare Einschränkung haben: Sie filtern ausschließlich nach der Quell-IP-Adresse und berücksichtigen weder Ziel-IP noch Protokoll oder Ports. Wer das nicht im Hinterkopf hat, blockiert im Zweifel zu viel oder schützt zu wenig. Dieser Artikel erklärt, wie Standard ACLs in Cisco IOS/IOS XE funktionieren, wie Wildcard-Masken korrekt eingesetzt werden, wie die Reihenfolge der Einträge wirkt, wo Standard ACLs im Netzwerkdesign sinnvoll platziert werden und wie Sie die Regeln sicher testen, dokumentieren und im Betrieb überwachen. Ziel ist, dass Sie Standard ACLs nicht nur „zum Laufen“ bringen, sondern sauber und nachvollziehbar einsetzen – ohne unnötige Ausfälle oder ungewollte Sicherheitslücken.

Was ist eine Cisco Standard ACL?

Eine Standard ACL ist eine Access Control List, die Pakete anhand der Quelladresse erlaubt oder verbietet. In Cisco IOS existieren Standard ACLs klassisch als nummerierte ACLs (z. B. 1–99 und 1300–1999) oder als benannte Standard ACLs (z. B. ip access-list standard MGMT-ACL). Technisch betrachtet arbeitet eine ACL wie eine sequenzielle Prüfliste: Das erste passende Statement entscheidet, danach wird nicht weiter geprüft.

• Standard ACL: matcht nur die Quell-IP (und optional Subnetz/Wildcard)
• Extended ACL: matcht zusätzlich Ziel-IP, Protokolle (TCP/UDP/ICMP) und Ports
• Implizites Deny: Am Ende jeder ACL steht gedanklich ein „deny all“, wenn nichts erlaubt wird

Eine gute Cisco-Referenz für ACL-Konzepte und Befehlsvarianten bietet der Anchor-Text Cisco ACL Grundlagen und Konfiguration. Für die genaue Syntax je IOS/IOS XE-Version ist die Cisco IOS Command Reference hilfreich.

Wie arbeitet eine Standard ACL?

Eine Standard ACL besteht aus Einträgen vom Typ permit oder deny, die gegen die Quell-IP-Adresse geprüft werden. Sobald ein Paket einen Eintrag matcht, wird es erlaubt oder verworfen. Wenn kein Eintrag matcht, greift das implizite Deny – das Paket wird verworfen.

• Top-down: Einträge werden von oben nach unten ausgewertet
• First match wins: Der erste Treffer entscheidet
• Implicit deny any: Am Ende wird alles verworfen, was nicht explizit erlaubt ist

Das macht Standard ACLs sehr vorhersehbar – und zugleich gefährlich, wenn man vergisst, dass man am Ende oft ein permit für „alles andere“ benötigt, sofern man nicht tatsächlich alles blocken möchte.

Wildcard-Masken verstehen: Das häufigste ACL-Missverständnis

Bei Cisco ACLs werden Subnetze mit einer Wildcard-Maske beschrieben, nicht mit der Subnetzmaske. Die Wildcard ist die inverse Maske: Bits mit 0 müssen exakt matchen, Bits mit 1 dürfen variieren. Ein einfaches Merkbild:

• Subnetzmaske: 1 = fest, 0 = Hostanteil
• Wildcard: 0 = fest, 1 = egal

Beispiele

• Host exakt: 192.168.10.50 0.0.0.0 (oder kurz host 192.168.10.50)
• /24 Netz: 192.168.10.0 0.0.0.255
• /16 Netz: 192.168.0.0 0.0.255.255

Wer die Wildcard falsch setzt, erzeugt oft entweder zu breite Matches (zu viel Traffic betroffen) oder zu enge Matches (Regel greift nicht). Im Zweifel ist es besser, zunächst mit einem einzelnen Host zu testen und dann kontrolliert zu erweitern.

Nummerierte vs. benannte Standard ACLs

Standard ACLs können nummeriert oder benannt sein. Für den Betrieb sind benannte ACLs meist besser, weil Namen selbsterklärend sind und die Pflege (Einfügen/Sequenzen) in der Praxis einfacher ist.

Nummerierte Standard ACL (Beispiel)

configure terminal
access-list 10 permit 192.168.10.0 0.0.0.255
access-list 10 deny any
end

Benannte Standard ACL (Beispiel)

configure terminal
ip access-list standard MGMT-ACL
permit 192.168.10.0 0.0.0.255
deny any
end

In benannten ACLs können Sie in vielen IOS/IOS XE-Varianten mit Sequenznummern arbeiten, was das Einfügen neuer Regeln ohne „alles neu schreiben“ erleichtert.

Der wichtigste Design-Grundsatz: Standard ACLs „nah am Ziel“ platzieren

Eine Standard ACL matcht nur die Quelle. Wenn Sie sie „nah an der Quelle“ einsetzen, riskieren Sie, dass Sie zu viel Traffic blockieren, weil Sie nicht nach Ziel unterscheiden können. Deshalb gilt als klassische Best Practice:

• Standard ACL: möglichst nah am Ziel platzieren
• Extended ACL: eher nah an der Quelle, weil sie granular filtern kann

Beispiel: Sie möchten verhindern, dass das Netz 10.20.20.0/24 einen bestimmten Server erreicht. Mit einer Standard ACL können Sie nicht sagen „nur zu diesem Server“, sondern nur „Quelle X“. Wenn Sie die ACL am falschen Ort platzieren, blockieren Sie womöglich auch berechtigte Ziele. In solchen Fällen ist eine Extended ACL oft die bessere Wahl.

Praxis-Use-Case 1: Managementzugriff auf SSH begrenzen

Einer der besten Einsatzzwecke für Standard ACLs ist das Begrenzen von Managementzugriffen. Sie möchten typischerweise nur aus einem Adminnetz per SSH auf Router/Switch zugreifen. Das erreichen Sie auf VTY-Lines über access-class.

Beispiel: SSH nur aus 10.100.0.0/16 erlauben

configure terminal
ip access-list standard MGMT-ONLY
permit 10.100.0.0 0.0.255.255
deny any
line vty 0 4
transport input ssh
access-class MGMT-ONLY in
end

Damit reduzieren Sie die Angriffsfläche erheblich: Selbst wenn Credentials kompromittiert wären, ist der Zugriff aus „irgendwelchen“ Netzen nicht möglich. In produktiven Umgebungen kombinieren viele Teams das zusätzlich mit AAA (z. B. TACACS+) und Logging, um Zugriffe nachvollziehbar zu machen.

Praxis-Use-Case 2: NAT- oder PBR-Quellnetze definieren

Standard ACLs werden häufig verwendet, um festzulegen, welche internen Netze NAT (PAT/Overload) nutzen dürfen. Auch bei Policy-Based Routing wird häufig nach Quellen klassifiziert. In solchen Fällen ist die Standard ACL besonders passend, weil genau die Quelle entscheidend ist.

Beispiel: PAT nur für 192.168.10.0/24 und 192.168.20.0/24

configure terminal
ip access-list standard NAT-INSIDE
permit 192.168.10.0 0.0.0.255
permit 192.168.20.0 0.0.0.255
deny any
ip nat inside source list NAT-INSIDE interface gigabitethernet0/0 overload
end

Best Practice: Halten Sie solche Listen bewusst klein und dokumentieren Sie, warum ein Netz NAT nutzen darf. Das erleichtert späteres Troubleshooting, insbesondere wenn „ein VLAN hat Internet, ein anderes nicht“.

Praxis-Use-Case 3: Zugriff auf Routing-Protokolle oder Management-Services einschränken

Standard ACLs können in einigen Szenarien auch genutzt werden, um bestimmte Verwaltungs- oder Protokollfunktionen nur für definierte Quellen zu erlauben. Beispiele sind Zugriffsbeschränkungen für SNMP-Manager oder die Begrenzung bestimmter Verwaltungszugriffe. Das konkrete Feature hängt von Plattform und IOS/IOS XE-Version ab, das Muster bleibt: Quelle definieren, Feature daran binden.

Reihenfolge und implizites Deny: So vermeiden Sie ungewollte Ausfälle

Die häufigste Ursache für „nach ACL-Änderung geht nichts mehr“ ist die Reihenfolge oder das vergessene implizite Deny. Zwei praktische Regeln helfen:

• Spezifisch vor allgemein: Einzelhosts oder kleine Netze zuerst, große Netze später
• Wenn nicht alles blockiert werden soll: am Ende ein bewusstes permit any setzen (oder zumindest erlaubende Regeln so gestalten, dass alles Gewünschte erfasst wird)

Beispiel: Nur ein Netz sperren, alles andere erlauben

Sie möchten 192.168.10.0/24 blockieren, aber alle anderen Quellen zulassen:

configure terminal
ip access-list standard BLOCK-ONE
deny 192.168.10.0 0.0.0.255
permit any
end

Ohne das permit any würden Sie am Ende alles blocken, weil das implizite Deny greift. Genau dieser Punkt macht ACLs zu einem häufigen Fehlerfeld für Einsteiger.

Standard ACL anwenden: Interface in vs. out verstehen

Eine ACL muss an einem Interface gebunden werden, typischerweise inbound (in) oder outbound (out). Bei Standard ACLs sollten Sie sehr bewusst wählen, weil Sie nur nach Quelle filtern können.

• in: Pakete werden gefiltert, wenn sie ins Interface hineinkommen
• out: Pakete werden gefiltert, bevor sie das Interface verlassen

Beispiel: Standard ACL inbound auf einem Interface

configure terminal
interface gigabitethernet0/1
ip access-group BLOCK-ONE in
end

Best Practice: Überlegen Sie, welche Verkehrsrichtung Sie wirklich kontrollieren möchten. Bei Management-ACLs ist access-class auf VTY oft der sauberste Weg. Bei Datenverkehrsfiltern müssen Sie sicherstellen, dass Sie nicht unbeabsichtigt Rückverkehr oder interne Kommunikation blockieren.

Logging und Zähler: ACLs im Betrieb verifizieren

Eine ACL ist nur dann gut, wenn Sie ihre Wirkung nachvollziehen können. Cisco bietet dafür vor allem zwei Hilfsmittel: Trefferzähler und optionales Logging.

• Trefferzähler: zeigen, welche Einträge tatsächlich matchen
• Logging: kann bei Deny-Regeln helfen, ist aber vorsichtig einzusetzen (Logflut)

ACL prüfen

• show ip access-lists
• show access-lists (plattformabhängig)

Best Practice: In produktiven Netzen Logging sparsam einsetzen, z. B. nur temporär bei Fehlersuche oder mit sehr gezielter Deny-Regel. Dauerhaftes Logging auf stark frequentierten Interfaces kann CPU und Logsysteme belasten.

Häufige Fehler bei Standard ACLs und wie Sie sie vermeiden

• Wildcard falsch: /24 vs. /16 verwechselt, Regel matcht zu breit oder gar nicht.
• Implizites Deny vergessen: Alles wird blockiert, weil kein abschließendes Permit existiert.
• Falsche Platzierung: Standard ACL wird zu nah an der Quelle angewendet und blockiert ungewollt mehrere Ziele.
• Falsche Richtung: ACL wird outbound statt inbound (oder umgekehrt) angewendet und greift nicht wie erwartet.
• Managementzugriff ausgesperrt: VTY-ACL zu restriktiv, keine Break-Glass-Option.
• Änderung ohne Test: Kein Pilot, keine zweite Session offen, kein Rollback-Plan.

Best Practices für saubere ACL-Administration

• Benannte ACLs bevorzugen: bessere Lesbarkeit und Wartbarkeit.
• Konventionen für Namen: z. B. MGMT-ONLY, NAT-INSIDE, BLOCK-GUEST.
• Dokumentation: Zweck, Scope, Interface-Bindung und Änderungsdatum festhalten.
• Stufenweise Änderungen: erst hinzufügen, verifizieren (Zähler), dann alte Regeln entfernen.
• Rollback-Plan: Console-Zugriff oder Out-of-Band-Management sichern.
• Least Privilege: lieber gezielt erlauben als pauschal öffnen.

Wenn Sie ACLs als Teil eines größeren Sicherheitskonzepts betrachten, sind die Anchor-Texte Cisco ACL Grundlagen und CIS Controls hilfreiche Orientierungspunkte für sichere Defaults, Change-Management und Monitoring.

Praxisbeispiel: Standard ACL als Management-Schutz mit klarer Struktur

Ein robustes Muster für viele Umgebungen ist: Nur Adminnetz darf per SSH rein, alles andere wird abgewiesen. Zusätzlich können Sie mehrere Adminnetze erlauben und den Rest blocken.

configure terminal
ip access-list standard MGMT-SSH
remark Erlaubt SSH nur aus Adminnetzen
permit 10.100.0.0 0.0.255.255
permit 10.200.10.0 0.0.0.255
deny any
line vty 0 4
transport input ssh
access-class MGMT-SSH in
end

Der remark-Eintrag ist im Betrieb sehr wertvoll, weil er die Intention der ACL dokumentiert. Das reduziert Fehlinterpretationen bei späteren Änderungen.

Konfiguration sicher anwenden und speichern

Wenn Sie eine ACL neu anwenden oder ändern, ist ein vorsichtiges Vorgehen empfehlenswert: Halten Sie eine zweite Session offen, testen Sie aus dem erlaubten Adminnetz und prüfen Sie Trefferzähler. Sobald die Wirkung bestätigt ist, speichern Sie die Konfiguration:

copy running-config startup-config

Für weiterführende Details zu Syntaxvarianten, Plattformunterschieden und erweiterten ACL-Mechanismen ist die Cisco IOS Command Reference eine verlässliche Quelle, um die passenden Befehle für Ihre IOS/IOS XE-Version nachzuschlagen.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.