14.9 Erweiterte ACL einfach erklärt

Erweiterte ACLs gehören zu den wichtigsten Werkzeugen in Cisco-Netzwerken, wenn Datenverkehr gezielt und präzise gefiltert werden soll. Während eine Standard ACL nur die Quell-IP-Adresse betrachtet, kann eine erweiterte ACL deutlich mehr: Sie prüft Quelle, Ziel, Protokoll und bei TCP oder UDP sogar Portnummern. Genau dadurch lassen sich sehr feingranulare Regeln erstellen, etwa um nur HTTP und HTTPS zu erlauben, Ping zu blockieren oder den Zugriff auf bestimmte Server einzuschränken. Für Network Engineers, CCNA- und CCNP-Lernende sowie Administratoren in der Praxis ist die Extended ACL deshalb ein zentrales Thema, weil sie Routing, Security und Traffic-Steuerung direkt miteinander verbindet.

Was ist eine erweiterte ACL?

Eine erweiterte ACL ist eine Access Control List, die Pakete anhand mehrerer Merkmale filtern kann. Im Gegensatz zur Standard ACL, die nur die Quell-IP betrachtet, erlaubt die erweiterte ACL eine deutlich genauere Steuerung des Verkehrs. Sie kann prüfen, von welcher Quelle ein Paket kommt, zu welchem Ziel es geht, welches Layer-3-Protokoll verwendet wird und bei TCP oder UDP auch, welche Ports angesprochen werden.

Dadurch lassen sich Regeln formulieren, die sehr nah an realen Anforderungen liegen. So kann etwa festgelegt werden, dass ein bestimmtes Client-Netz einen Webserver per HTTPS erreichen darf, aber keinen SSH-Zugriff erhält. Genau diese Präzision macht erweiterte ACLs in der Praxis so wertvoll.

Wichtige Merkmale einer erweiterten ACL

• Filterung nach Quell-IP-Adresse
• Filterung nach Ziel-IP-Adresse
• Unterscheidung nach Protokollen wie IP, TCP, UDP oder ICMP
• Filterung nach Ports wie 80, 443, 22 oder 53
• Geeignet für gezielte Policy-Steuerung im Netzwerk

Warum erweiterte ACLs so wichtig sind

In modernen Netzwerken reicht es selten aus, nur ganze Quellnetze pauschal zu erlauben oder zu blockieren. Meist geht es um viel konkretere Anforderungen: Ein Benutzer-VLAN soll auf einen Webserver zugreifen dürfen, aber nicht auf Management-Systeme. Ein Admin-Netz soll SSH nutzen dürfen, normale Clients aber nicht. Ein Gastnetz soll nur ins Internet, aber nicht zu internen Servern gelangen.

Genau dafür sind erweiterte ACLs gemacht. Sie schaffen Kontrolle über den Datenverkehr und erlauben eine differenzierte Trennung von Diensten und Segmenten. Damit sind sie nicht nur ein Sicherheitswerkzeug, sondern auch ein zentrales Instrument für sauberes Netzwerkdesign.

Typische Einsatzbereiche

• Filtern von HTTP, HTTPS, SSH, DNS oder ICMP
• Steuern des Zugriffs zwischen VLANs
• Schutz sensibler Servernetze
• Beschränkung von Management-Zugriffen
• Grundlegende Segmentierung ohne Firewall
• Traffic-Steuerung auf Cisco-Routern und Layer-3-Switches

Wie eine erweiterte ACL funktioniert

Wie jede Cisco-ACL arbeitet auch die erweiterte ACL nach einem einfachen, aber entscheidenden Prinzip: top-down, first match. Das bedeutet, dass ein Paket die ACL von oben nach unten durchläuft. Sobald eine Regel passt, wird die dort definierte Aktion sofort ausgeführt. Danach endet die Auswertung für dieses Paket.

Die Reihenfolge der Regeln ist deshalb besonders wichtig. Eine zu allgemeine Permit-Regel am Anfang kann spätere, spezifische Deny-Regeln wirkungslos machen. Umgekehrt kann eine zu früh platzierte Deny-Regel auch legitimen Traffic blockieren.

Verarbeitungslogik einer erweiterten ACL

• Ein Paket trifft auf die ACL
• Die Regeln werden von oben nach unten geprüft
• Die erste passende Regel entscheidet
• Nach der ersten Übereinstimmung wird nicht weiter geprüft

Wichtige Konsequenz für die Praxis

Bei erweiterten ACLs gilt ebenfalls das implizite deny. Alles, was nicht ausdrücklich erlaubt wird, wird am Ende verworfen.

Das implizite deny bei erweiterten ACLs

Jede ACL endet logisch mit einer unsichtbaren Verweigerungsregel. Bei erweiterten ACLs entspricht das sinngemäß einem deny ip any any. Dieser Eintrag ist meist nicht sichtbar in der Konfiguration, ist aber immer aktiv.

Das bedeutet: Wenn ein Paket auf keine Permit-Regel trifft, wird es automatisch blockiert. Gerade bei erweiterten ACLs ist das besonders relevant, weil Administratoren häufig nur einzelne Dienste freigeben und dabei vergessen, welchen übrigen Traffic sie noch zulassen müssen.

Warum das implizite deny wichtig ist

• Nicht erlaubter Traffic wird automatisch blockiert
• ACLs sind standardmäßig restriktiv
• Fehlende Permit-Regeln führen oft zu unerwarteten Ausfällen

Beispiel

access-list 101 permit tcp 192.168.10.0 0.0.0.255 any eq 80
access-list 101 permit tcp 192.168.10.0 0.0.0.255 any eq 443

Mit dieser ACL sind nur HTTP und HTTPS aus dem Netz 192.168.10.0/24 erlaubt. Jeder andere IP-Verkehr aus diesem Netz wird durch das implizite deny blockiert.

Welche Felder eine erweiterte ACL prüfen kann

Die Stärke der Extended ACL liegt in ihrer Detailtiefe. Eine Regel kann mehrere Felder auswerten und damit sehr präzise festlegen, welcher Traffic erlaubt oder blockiert werden soll.

Typische Prüfkriterien

• Quell-IP-Adresse oder Quellnetz
• Ziel-IP-Adresse oder Zielnetz
• Protokoll wie IP, TCP, UDP, ICMP
• Quellport oder Zielport
• Spezielle Parameter wie established bei TCP oder ICMP-Typen

Warum das in der Praxis nützlich ist

• Nur Webzugriffe können erlaubt werden
• SSH kann nur aus Admin-Netzen freigegeben werden
• DNS kann gezielt auf bestimmte Server beschränkt werden
• Ping oder Telnet können selektiv blockiert werden

Aufbau einer erweiterten ACL-Regel

Eine typische Extended-ACL-Regel besteht aus mehreren Bausteinen: Aktion, Protokoll, Quelle, Ziel und optional Portdefinitionen oder weitere Parameter. Genau dieser Aufbau macht sie flexibler, aber auch etwas komplexer als eine Standard ACL.

Allgemeines Schema

access-list NUMMER permit|deny PROTOKOLL QUELLE WILDCARD ZIEL WILDCARD [OPTIONEN]

Ein einfaches Beispiel

access-list 101 permit tcp 192.168.10.0 0.0.0.255 any eq 80

Diese Regel bedeutet:

• permit = Traffic erlauben
• tcp = nur TCP-Verkehr prüfen
• 192.168.10.0 0.0.0.255 = Quelle ist das Netz 192.168.10.0/24
• any = Ziel ist beliebig
• eq 80 = Zielport ist 80, also HTTP

Wichtige Protokolle in erweiterten ACLs

Eine Extended ACL kann verschiedene Layer-3- oder Layer-4-nahe Protokolle filtern. In der Praxis sind vor allem ip, tcp, udp und icmp relevant.

ip

Mit ip wird sämtlicher IP-Verkehr eines Pakets betrachtet, unabhängig davon, ob es sich um TCP, UDP oder ICMP handelt.

access-list 110 permit ip 192.168.10.0 0.0.0.255 any

tcp

Mit tcp können TCP-basierte Dienste wie HTTP, HTTPS oder SSH gezielt gefiltert werden.

udp

Mit udp lassen sich Dienste wie DNS, NTP oder DHCP-naher Verkehr gezielt betrachten.

icmp

Mit icmp kann beispielsweise Ping-Verkehr zugelassen oder blockiert werden.

access-list 120 deny icmp any any

Diese Regel blockiert ICMP-Verkehr zwischen beliebigen Quellen und Zielen.

Ports in erweiterten ACLs verstehen

Ein zentraler Vorteil erweiterter ACLs ist die Möglichkeit, Ports auszuwerten. Gerade bei TCP und UDP wird dadurch sichtbar, welcher Dienst angesprochen wird. Statt nur ein Zielnetz freizugeben, kann exakt definiert werden, welche Anwendung erlaubt ist.

Wichtige Operatoren

• eq = gleich
• neq = ungleich
• gt = größer als
• lt = kleiner als
• range = Bereich

Beispiele mit Ports

access-list 101 permit tcp any any eq 80
access-list 101 permit tcp any any eq 443
access-list 101 permit tcp any any eq 22

Diese Regeln erlauben HTTP, HTTPS und SSH.

Beispiel mit Portbereich

access-list 130 permit tcp 192.168.10.0 0.0.0.255 any range 20 21

Damit wird ein Portbereich erlaubt, hier beispielsweise für FTP-bezogene Ports.

Wildcard Masks in erweiterten ACLs

Wie bei Standard ACLs verwendet Cisco auch bei erweiterten ACLs Wildcard Masks statt normaler Subnetzmasken. Sie bestimmen, welche Teile einer Adresse exakt passen müssen und welche variieren dürfen.

Grundprinzip

• 0 = dieser Teil muss genau übereinstimmen
• 1 = dieser Teil darf variieren

Typische Beispiele

• 0.0.0.0 = exakter Host
• 0.0.0.255 = /24-Netz
• 255.255.255.255 in Kombination mit any = alles

Hilfreiche Cisco-Kürzel

• host 192.168.10.10 statt 192.168.10.10 0.0.0.0
• any statt 0.0.0.0 255.255.255.255

Nummerierte und benannte erweiterte ACLs

Erweiterte ACLs können wie Standard ACLs nummeriert oder benannt erstellt werden. Historisch wurden oft Nummern im Bereich 100 bis 199 oder 2000 bis 2699 verwendet. In modernen Konfigurationen sind benannte ACLs meist besser lesbar.

Nummerierte erweiterte ACL

access-list 101 permit tcp 192.168.10.0 0.0.0.255 any eq 80
access-list 101 permit tcp 192.168.10.0 0.0.0.255 any eq 443
access-list 101 deny ip any any

Benannte erweiterte ACL

ip access-list extended INTERNET-WEB
 permit tcp 192.168.10.0 0.0.0.255 any eq 80
 permit tcp 192.168.10.0 0.0.0.255 any eq 443
 deny ip any any

Vorteile benannter ACLs

• Bessere Lesbarkeit
• Klarer Bezug zum Einsatzzweck
• Einfachere Wartung
• Bessere Dokumentation in produktiven Netzen

Wo erweiterte ACLs angewendet werden

Eine ACL wirkt erst dann, wenn sie an einem Interface oder einem Dienst eingesetzt wird. Auf Routing-Interfaces geschieht das meist mit ip access-group, eingehend oder ausgehend.

Inbound und Outbound

• Inbound: Pakete werden beim Eintritt ins Interface geprüft
• Outbound: Pakete werden geprüft, bevor sie das Interface verlassen

Beispiel für die Anwendung auf einem Interface

interface GigabitEthernet0/0
 ip access-group 101 in

Hier wird ACL 101 eingehend auf GigabitEthernet0/0 angewendet.

Warum die Richtung entscheidend ist

Die gleiche ACL kann je nach Richtung völlig unterschiedliche Auswirkungen haben. Deshalb muss immer genau geplant werden, an welchem Punkt im Pfad der Traffic gefiltert werden soll.

Grundregel für die Platzierung erweiterter ACLs

Eine wichtige Cisco-Designregel lautet: Erweiterte ACLs möglichst nah an der Quelle platzieren. Der Grund ist einfach: Da Extended ACLs sehr präzise filtern können, ist es sinnvoll, unerwünschten Traffic früh im Pfad zu stoppen, statt ihn erst durch das Netzwerk zu transportieren.

Warum diese Regel sinnvoll ist

• Unerwünschter Traffic wird früh blockiert
• Bandbreite und Router-Ressourcen werden geschont
• Die Filterlogik bleibt meist übersichtlicher

Beispiel

Wenn ein Client-Netz keinen SSH-Zugriff auf Server aufbauen darf, ist es meist sinnvoll, diesen Traffic bereits nahe dem Quellnetz zu blockieren, statt erst in der Nähe des Zielservers.

Typische Praxisbeispiele für erweiterte ACLs

Nur HTTP und HTTPS ins Internet erlauben

ip access-list extended WEB-ONLY
 permit tcp 192.168.10.0 0.0.0.255 any eq 80
 permit tcp 192.168.10.0 0.0.0.255 any eq 443
 deny ip any any

Diese ACL erlaubt aus dem Netz 192.168.10.0/24 nur Webzugriffe per HTTP und HTTPS.

SSH nur aus dem Admin-Netz erlauben

ip access-list extended ADMIN-SSH
 permit tcp 10.10.10.0 0.0.0.255 host 192.168.100.10 eq 22
 deny tcp any host 192.168.100.10 eq 22
 permit ip any any

Damit darf nur das Netz 10.10.10.0/24 per SSH auf den Server 192.168.100.10 zugreifen.

ICMP blockieren, restlichen Verkehr erlauben

ip access-list extended NO-PING
 deny icmp any any
 permit ip any any

Diese ACL blockiert Ping-Verkehr, lässt aber übrigen IP-Verkehr zu.

Gastnetz vom internen Servernetz trennen

ip access-list extended GUEST-FILTER
 deny ip 192.168.50.0 0.0.0.255 192.168.100.0 0.0.0.255
 permit ip 192.168.50.0 0.0.0.255 any

Hier darf das Gastnetz 192.168.50.0/24 nicht auf das interne Servernetz 192.168.100.0/24 zugreifen, aber weiterhin andere Ziele erreichen.

Häufige Fehler bei erweiterten ACLs

Erweiterte ACLs sind leistungsfähig, aber dadurch auch fehleranfällig. Schon kleine Konfigurationsfehler können legitime Kommunikation blockieren oder unerwünschten Traffic erlauben.

Typische Fehlerquellen

• Reihenfolge der Regeln ist falsch
• Implizites deny wird vergessen
• Falsche Richtung am Interface gewählt
• ACL wurde auf falsches Interface angewendet
• Wildcard Mask ist fehlerhaft
• Quelle und Ziel wurden vertauscht
• Port bezieht sich auf die falsche Seite

Praxisbeispiel für falsche Reihenfolge

access-list 150 permit ip any any
access-list 150 deny tcp 192.168.10.0 0.0.0.255 any eq 23

Die zweite Regel ist wirkungslos, weil die erste Regel bereits sämtlichen IP-Verkehr erlaubt.

Praxisbeispiel für vertauschte Logik

Wenn eigentlich nur Web-Traffic erlaubt sein soll, aber stattdessen permit ip verwendet wird, ist die ACL viel zu offen. Eine präzise Protokoll- und Portauswahl ist bei Extended ACLs entscheidend.

Erweiterte ACLs überprüfen und verifizieren

Nach der Konfiguration sollte eine ACL immer geprüft werden. Cisco IOS stellt dafür mehrere Show-Befehle bereit, mit denen sich Inhalt, Anwendung und Trefferzahlen kontrollieren lassen.

Wichtige Show-Befehle

show access-lists
show ip interface
show running-config | section access-list
show running-config | section ip access-list

show access-lists

Dieser Befehl zeigt die ACL-Einträge und oft auch die Trefferzähler. Gerade diese Counter sind in der Praxis besonders hilfreich, weil sie zeigen, ob Pakete tatsächlich auf die erwarteten Regeln treffen.

show ip interface

Mit diesem Befehl lässt sich prüfen, ob eine ACL auf einem Interface aktiv ist und ob sie inbound oder outbound angewendet wird.

Wichtige Prüffragen

• Ist die ACL richtig geschrieben?
• Wurde sie auf das richtige Interface angewendet?
• Stimmt die Richtung?
• Treffen Pakete auf die erwarteten Zeilen?
• Blockiert das implizite deny unerwartet weiteren Traffic?

Erweiterte ACLs und Sicherheit richtig einordnen

Erweiterte ACLs sind ein starkes Werkzeug für Traffic-Kontrolle, aber sie ersetzen keine moderne Stateful Firewall. Eine klassische Cisco-ACL ist grundsätzlich zustandslos. Sie entscheidet auf Basis definierter Regeln, merkt sich aber nicht automatisch den Zustand einer Sitzung wie eine Firewall mit Stateful Inspection.

Trotzdem sind Extended ACLs im Netzwerkalltag extrem wertvoll. Sie bieten eine saubere und ressourcenschonende Möglichkeit, Verkehrsregeln direkt auf Routern und Layer-3-Switches durchzusetzen. Gerade für Segmentierung, Basis-Schutz und gezielte Zugriffsregeln sind sie sehr gut geeignet.

Was erweiterte ACLs gut können

• Gezielte Filterung nach Quelle, Ziel, Protokoll und Port
• Segmentierung zwischen Netzbereichen
• Schutz sensibler Systeme
• Steuerung von Management- und Client-Traffic

Was sie nicht ersetzen

• Stateful Firewall-Funktionen
• Tiefgehende Applikationsanalyse
• Komplexe Sicherheitsarchitekturen
• Next-Generation-Firewall-Policies

Warum erweiterte ACLs für CCNA, CCNP und Praxis unverzichtbar sind

Die erweiterte ACL ist eines der wichtigsten Themen in Cisco-Netzwerken, weil sie mehrere Grundlagen auf einmal verbindet: IP-Adressierung, Protokolle, Ports, Routing und Sicherheitslogik. Wer Extended ACLs sicher versteht, kann Datenverkehr nicht nur beobachten, sondern aktiv steuern.

Gerade in der Praxis ist das entscheidend. Viele Netzwerke benötigen keine große Firewall-Policy auf jedem Segment, wohl aber gezielte Regeln für Management, Benutzerzugriffe, Servertrennung oder Gastnetze. Erweiterte ACLs sind dafür oft das direkteste und effektivste Mittel. Genau deshalb gehören sie zu den Kernkompetenzen eines Network Engineers und zu den wichtigsten Bausteinen jeder fundierten Cisco-Ausbildung.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.