Extended ACL konfigurieren: Traffic gezielt filtern

Wer Cisco Router oder Layer-3-Switches betreibt, braucht früher oder später Regeln, die mehr können als „Quelle erlaubt/Quelle verboten“. Genau hier kommen Extended ACLs ins Spiel. Wenn Sie eine Extended ACL konfigurieren, können Sie Traffic sehr gezielt filtern: nach Quell- und Ziel-IP, nach Protokoll (TCP/UDP/ICMP) und – besonders wichtig – nach Ports und Services. Damit lassen sich typische Enterprise-Anforderungen umsetzen, ohne gleich eine Firewall in jeder Ecke zu benötigen: Zugriff auf Server nur über bestimmte Anwendungen, Trennung von Client- und Serversegmenten, Schutz von Management-Zugängen, Blockieren unerwünschter Protokolle (z. B. Telnet), oder das Einschränken von Gastnetzwerken. Gleichzeitig sind Extended ACLs ein häufiger Auslöser für Störungen, wenn Reihenfolge, Richtung (in/out), Wildcard-Masken oder Rückverkehr nicht sauber bedacht werden. Besonders tückisch ist das implizite „deny any“ am Ende: Was nicht explizit erlaubt ist, wird verworfen. Dieser Artikel erklärt praxisnah, wie Extended ACLs in Cisco IOS/IOS XE funktionieren, wie Sie Traffic gezielt filtern, welche Best Practices bei Platzierung und Pflege gelten und wie Sie Regeln sicher testen und verifizieren, damit aus einer Schutzmaßnahme kein ungeplanter Ausfall wird.

Was ist eine Extended ACL und was kann sie mehr als eine Standard ACL?

Eine Extended ACL ist eine Access Control List, die Pakete anhand mehrerer Merkmale matchen kann. Im Gegensatz zur Standard ACL, die nur die Quelladresse betrachtet, kann eine Extended ACL unter anderem:

• Quelle und Ziel prüfen (IP/Subnetz, Hosts)
• Protokolle unterscheiden (z. B. ip, tcp, udp, icmp)
• Ports/Services filtern (z. B. TCP/443, UDP/53)
• ICMP-Typen gezielt erlauben/verbieten (z. B. echo, time-exceeded)
• Optionen wie „established“ (klassisches Muster, um Rückverkehr bei TCP zu erlauben)

Damit sind Extended ACLs ideal, wenn Sie „nur diesen Traffic“ erlauben möchten, statt pauschal ganze Netze zu sperren. Als Cisco-Referenz eignet sich der Anchor-Text Cisco ACL Grundlagen und Konfiguration sowie für die Syntax je Plattform die Cisco IOS Command Reference.

So arbeitet eine ACL: Reihenfolge, First Match und implizites Deny

Extended ACLs werden sequenziell ausgewertet. Der erste Eintrag, der matcht, entscheidet. Danach wird nicht weiter geprüft. Wenn kein Eintrag matcht, greift am Ende das implizite „deny any“. Das hat drei praktische Konsequenzen:

• Reihenfolge ist entscheidend: Spezifische Regeln gehören vor allgemeine Regeln.
• „Permit“-Regeln müssen vollständig sein: Sonst blockieren Sie ungewollt legitimen Traffic.
• Ein abschließendes „permit ip any any“ ist nur sinnvoll, wenn Sie wirklich alles Übrige erlauben möchten (in Security-Designs oft nicht gewollt).

In produktiven Netzen ist es üblich, ACLs nach dem Prinzip „allow-list“ zu schreiben: Nur das, was notwendig ist, wird erlaubt; alles andere wird verworfen.

Wildcard-Masken korrekt einsetzen

Cisco ACLs verwenden Wildcard-Masken. Die Logik ist: 0 bedeutet „muss exakt matchen“, 1 bedeutet „egal“. Häufige Beispiele:

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

Ein sehr häufiger Fehler ist eine falsche Wildcard, die zu breit matcht. Das führt dann zu „zu viel“ Blockierung oder zu einem scheinbar nicht greifenden Filter.

Nummerierte vs. benannte Extended ACLs

Extended ACLs gibt es nummeriert (klassisch 100–199 und 2000–2699) oder benannt. Für die Praxis sind benannte ACLs meistens besser: Sie sind leichter zu lesen, lassen sich mit Sequenzen strukturieren und sind im Teambetrieb verständlicher.

Nummerierte Extended ACL (Beispiel)

configure terminal
access-list 110 permit tcp 10.10.10.0 0.0.0.255 host 10.10.20.10 eq 443
access-list 110 deny ip any any
end

Benannte Extended ACL (Beispiel)

configure terminal
ip access-list extended WEB-TO-APP
permit tcp 10.10.10.0 0.0.0.255 host 10.10.20.10 eq 443
deny ip any any
end

Benannte ACLs unterstützen häufig remark-Zeilen zur Dokumentation. Das ist im Betrieb extrem hilfreich.

Platzierung im Netzwerk: Extended ACLs „nah an der Quelle“

Ein klassischer Best-Practice-Grundsatz lautet: Extended ACLs platziert man möglichst nah an der Quelle. Der Grund: Da Extended ACLs sehr präzise filtern können, verhindern Sie unnötigen Transitverkehr durch das Netz. Gleichzeitig reduzieren Sie die Last auf zentralen Links und verhindern, dass „unerwünschter“ Traffic überhaupt weit gelangt.

• In einem Campus: häufig inbound auf dem SVI des Client-VLANs
• In einem WAN/Standort: häufig inbound am LAN-Interface oder am Tunnel-Interface (designabhängig)
• Für Managementzugang: häufig auf VTY (access-class) oder in einer dedizierten Management-VRF/Zone

Wichtig: Platzierung ist immer designabhängig. Entscheidend ist, dass Sie den Datenfluss verstehen: Wo kommt der Traffic her? Wo soll er hin? Wo ist der sinnvollste Kontrollpunkt?

Extended ACL Syntax: Protokolle, Ports und Operatoren

Extended ACLs nutzen je nach Protokoll unterschiedliche Syntax. Für TCP/UDP sind Ports zentral. Typische Operatoren:

• eq: exakt (z. B. eq 443)
• gt: größer als
• lt: kleiner als
• range: Bereich (z. B. range 1024 65535)

Bei ICMP können Sie Typen angeben, z. B. echo (Ping), echo-reply, time-exceeded (wichtig für Traceroute), unreachable. Diese Details sind hilfreich, wenn Sie Diagnose erlauben möchten, ohne ICMP komplett zu öffnen.

Praxis-Use-Case: Clients dürfen nur Web und DNS ins Internet

Ein sehr verbreitetes Szenario: Ein Gast- oder IoT-VLAN soll nur bestimmte Dienste nutzen dürfen, z. B. DNS und Web (HTTP/HTTPS). Alles andere wird blockiert.

Beispiel: VLAN 20 (10.20.20.0/24) nur DNS + HTTP/HTTPS nach außen

configure terminal
ip access-list extended GUEST-INTERNET
remark Erlaubt DNS zu internen Resolvern
permit udp 10.20.20.0 0.0.0.255 host 10.10.10.10 eq 53
permit tcp 10.20.20.0 0.0.0.255 host 10.10.10.10 eq 53
remark Erlaubt Web-Traffic ins Internet
permit tcp 10.20.20.0 0.0.0.255 any eq 80
permit tcp 10.20.20.0 0.0.0.255 any eq 443
remark Optional: ICMP für Basisdiagnose
permit icmp 10.20.20.0 0.0.0.255 any echo
permit icmp 10.20.20.0 0.0.0.255 any echo-reply
deny ip any any
end

Diese ACL würden Sie typischerweise inbound auf dem SVI oder Interface anwenden, über das der Traffic aus dem VLAN in das Routing gelangt:

configure terminal
interface vlan 20
ip access-group GUEST-INTERNET in
end

Praxis-Use-Case: Zugriff auf Server nur für bestimmte Applikationen

Ein typisches Enterprise-Muster ist Segmentierung: Clients dürfen einen Server nur über definierte Ports erreichen. Beispiel: Nur die Webserver-Zone darf den Appserver auf TCP/8443 erreichen.

Beispiel: WEB (10.10.10.0/24) → APP (10.10.20.10) nur TCP/8443

configure terminal
ip access-list extended WEB-TO-APP
remark Webserver dürfen Appserver-Port erreichen
permit tcp 10.10.10.0 0.0.0.255 host 10.10.20.10 eq 8443
remark Optional: Ping zwischen Zonen für Monitoring
permit icmp 10.10.10.0 0.0.0.255 host 10.10.20.10 echo
deny ip any host 10.10.20.10
permit ip any any
end

Wichtig: Das Beispiel zeigt bewusst die Logik „Deny nur zum Zielhost, dann permit any any“, damit nicht die gesamte Kommunikation blockiert wird. In vielen Sicherheitsdesigns wird statt „permit any any“ eine weitere allow-list verwendet, abhängig davon, wie strikt das VLAN segmentiert sein soll.

Rückverkehr beachten: „established“, Stateful Firewalls und typische Missverständnisse

ACLs sind grundsätzlich stateless: Sie prüfen jedes Paket für sich. Wenn Sie inbound auf einem Interface Traffic erlauben, müssen Sie oft auch den Rückverkehr berücksichtigen. Bei TCP gibt es das klassische Keyword established, das Rückverkehr (mit ACK/RST) erlauben kann. Das ist kein vollwertiger State, aber hilft in einfachen Szenarien.

Beispiel: Rückverkehr für TCP-Verbindungen erlauben

permit tcp any 10.20.20.0 0.0.0.255 established

In modernen Umgebungen ist für komplexere Szenarien häufig eine stateful Firewall oder Zone-Based Firewall die bessere Wahl. Dennoch bleiben ACLs für grundlegende Segmentierung und Zugriffsbeschränkung extrem relevant.

Management schützen: SSH nur aus Adminnetzen (Extended vs. Standard)

Für VTY-Zugriffe ist eine Standard ACL oft ausreichend, weil Sie nur Quellen erlauben möchten. Extended ACLs sind hier nicht zwingend nötig. Trotzdem können Extended ACLs in manchen Designs nützlich sein, wenn Sie sehr gezielt Management-Services steuern möchten (z. B. nur SSH, nicht SNMP, oder getrennte Managementpfade). In der Praxis ist die Kombination aus:

• SSH-only (Telnet aus)
• VTY access-class (Quelle begrenzen)
• AAA (RADIUS/TACACS+)
• Logging/Accounting

ein sehr robustes Grundmodell.

ACLs sicher ändern: Sequenzen, Remarks und Change-Disziplin

Extended ACLs sollten wartbar sein. Dazu gehören drei praktische Gewohnheiten:

• Benannte ACLs verwenden
• remarks nutzen, um Zweck und Besitzer zu dokumentieren
• Sequenznummern verwenden, um Regeln einzufügen, ohne alles neu zu schreiben

Beispiel: Regel mit Sequenz einfügen

configure terminal
ip access-list extended GUEST-INTERNET
5 remark Basisregeln fuer Guest VLAN
15 permit udp 10.20.20.0 0.0.0.255 host 10.10.10.10 eq 53
20 permit tcp 10.20.20.0 0.0.0.255 host 10.10.10.10 eq 53
end

Die genaue Sequenzsyntax kann je nach IOS/IOS XE-Version variieren, benannte ACLs unterstützen jedoch in vielen Umgebungen eine strukturierte Pflege deutlich besser als nummerierte.

Verifikation und Troubleshooting: So sehen Sie, ob die ACL wirklich wirkt

Nach dem Anwenden einer Extended ACL sollten Sie nicht „nach Gefühl“ arbeiten, sondern mit Zählern und Tests. Die wichtigsten Befehle:

• show ip access-lists (Einträge und Trefferzähler)
• show running-config interface <IF> (ist die ACL korrekt gebunden?)
• show ip interface <IF> (in/out ACLs, Status)

Trefferzähler sind oft der schnellste Hinweis: Wenn eine Regel niemals matcht, ist sie entweder falsch formuliert, an der falschen Stelle angewendet oder der Traffic läuft anders als erwartet. Logging (log am Ende einer deny-Regel) kann bei der Fehlersuche helfen, sollte aber vorsichtig eingesetzt werden, um keine Logflut zu erzeugen.

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

• Falsche Richtung (in/out): ACL wird am falschen Interface oder in der falschen Richtung angewendet.
• Wildcard-Maske falsch: Netz matcht nicht oder matcht zu breit.
• Rückverkehr vergessen: TCP/UDP-Verbindungen scheitern, weil Antworten geblockt werden.
• DNS übersehen: Web funktioniert nicht, weil DNS (UDP/TCP 53) nicht erlaubt ist.
• Implizites deny: Kein abschließendes Permit, obwohl man nur „ein bisschen“ blocken wollte.
• Zu breite „permit ip any any“: Sicherheitswirkung wird aufgehoben.
• Änderungen ohne Test/Rollback: besonders kritisch bei Remote-Geräten ohne Console-Zugriff.

Best Practices: Extended ACLs professionell einsetzen

• Allow-list statt Block-list: Nur notwendige Services erlauben.
• Segmentierung bewusst planen: VLANs/Zonen definieren, dann Regeln pro Fluss ableiten.
• Extended ACL nahe an der Quelle: minimiert unnötigen Transittraffic.
• Dokumentation per remark: Zweck, Ticket-ID, Owner, Datum.
• Stufenweise Änderungen: erst hinzufügen und verifizieren, dann alte Regeln entfernen.
• Monitoring: Zähler prüfen, Logging gezielt nutzen, bei Drops alarmieren.
• Management absichern: SSH only, VTY-Zugriff begrenzen, AAA und Accounting nutzen.

Für vertiefende Cisco-Beispiele und Syntaxdetails sind die Anchor-Texte Cisco ACL Grundlagen und Konfiguration und Cisco IOS Command Reference besonders hilfreich, da sie die verfügbaren Optionen je Plattform und Version konkret beschreiben.

Praxis-Checkliste: Extended ACL sicher ausrollen

• Ist klar dokumentiert, welcher Traffic erlaubt sein muss (Quelle, Ziel, Ports, Protokolle)?
• Ist die ACL als benannte ACL mit remarks und sinnvoller Reihenfolge aufgebaut?
• Ist die Platzierung korrekt (Interface/SVI, Richtung in/out)?
• Sind DNS, notwendige Rückwege und Diagnosepfade berücksichtigt?
• Wurden Tests durchgeführt (Ping/Traceroute/Applikationstest) und Zähler geprüft?
• Existiert ein Rollback-Plan (zweite Session, Console/OOB, Change-Fenster)?

Konfiguration speichern

Wenn die Extended ACL korrekt greift, die gewünschten Services funktionieren und die Zähler plausibel sind, speichern Sie die Konfiguration, damit sie nach einem Neustart erhalten bleibt:

copy running-config startup-config

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.