Eine ACL-Zeile lesen, schreiben und richtig platzieren

Wildcard-Maske aus der Subnetzmaske ableiten

Die Wildcard-Maske ist für zusammenhängende Netze die Differenz zwischen 255.255.255.255 und der Subnetzmaske, Oktett für Oktett gerechnet. Für 255.255.255.192, ein /26, ergibt das 0.0.0.63. Für 255.255.240.0, ein /20, ergibt es 0.0.15.255. Wer diese Subtraktion verinnerlicht, braucht keine Tabelle mehr.

Wildcard-Masken müssen anders als Subnetzmasken nicht zusammenhängend sein. 10.10.0.10 0.0.255.0 trifft die Adresse .10 in jedem Netz von 10.10.0.0 bis 10.10.255.0, etwa alle Drucker, wenn jedes Standortnetz den Drucker auf .10 hat. Das ist erlaubt, aber schwer zu lesen, und gehört deshalb mit einem remark kommentiert.

Standard- gegen Extended-ACL und wo sie hingehört

Eine Standard-ACL prüft nur die Quelladresse. Sie kann also nicht unterscheiden, ob ein Client zum Webserver oder zum Domänencontroller will. Platzierst du sie nah an der Quelle, sperrst du den Client für alle Ziele. Deshalb gehört eine Standard-ACL möglichst nah an das Ziel, das sie schützen soll. Heute wird sie vor allem dort eingesetzt, wo ein Befehl nur eine Quellliste erwartet, etwa access-class auf den VTY-Leitungen oder in Route-Maps und NAT-Regeln.

Eine Extended-ACL prüft Quelle, Ziel, Protokoll und Ports. Weil sie genau beschreiben kann, welcher Verkehr gemeint ist, gehört sie möglichst nah an die Quelle. Unerwünschter Verkehr wird dann verworfen, bevor er Bandbreite auf weiteren Links verbraucht. Auf einem Layer-3-Switch heißt das in der Praxis: an das SVI des Quell-VLANs, Richtung in.

Nummerierte Listen gibt es weiterhin, Standard-ACLs mit 1 bis 99 und 1300 bis 1999, Extended mit 100 bis 199 und 2000 bis 2699. Benannte Listen sind trotzdem die bessere Wahl: Der Name erklärt den Zweck, und Zeilen lassen sich per Sequenznummer bearbeiten.

ip access-list extended ACL-VLAN20-IN
 remark Verwaltung darf HTTPS zum Intranet-Server
 10 permit tcp 10.10.20.0 0.0.0.255 host 10.10.50.10 eq 443
 remark DNS nur zum internen Resolver
 20 permit udp 10.10.20.0 0.0.0.255 host 10.10.50.53 eq domain
 30 permit tcp 10.10.20.0 0.0.0.255 host 10.10.50.53 eq domain
 remark keine anderen internen Netze
 40 deny ip 10.10.20.0 0.0.0.255 10.0.0.0 0.255.255.255 log
 remark Internet erlaubt
 50 permit ip 10.10.20.0 0.0.0.255 any
 60 deny ip any any log
!
interface Vlan20
 ip access-group ACL-VLAN20-IN in

Reihenfolge, implizites deny und Trefferzähler

Der Router vergleicht ein Paket mit der Liste von der kleinsten Sequenznummer an und hört bei der ersten passenden Zeile auf. Deshalb stehen spezifische Zeilen vor allgemeinen. Steht im Beispiel die Zeile 50 permit ip 10.10.20.0 0.0.0.255 any vor der Zeile 40, kommt die Sperre der internen Netze nie zum Zug, weil jedes Paket schon an der allgemeinen Erlaubnis hängen bleibt.

Am Ende jeder IPv4-ACL steht ein implizites deny ip any any, das in der Konfiguration nicht auftaucht und keinen eigenen Trefferzähler hat. Eine ausdrückliche letzte Zeile deny ip any any log macht sichtbar, was verworfen wird. Bei IPv6-ACLs stehen vor dem impliziten deny zusätzlich implizite Erlaubnisse für Neighbor Discovery, damit die Adressauflösung weiter funktioniert. Wer dort eine eigene letzte Zeile deny ipv6 any any setzt, überschreibt diese Erlaubnisse und muss Neighbor Discovery ausdrücklich zulassen.

show ip access-lists zeigt hinter jeder Zeile die Zahl der Treffer. Diese Zahlen sind das wichtigste Werkzeug der Fehlersuche: Eine Zeile, die nie trifft, ist entweder überflüssig oder falsch geschrieben. Vor einem Test setzt du die Zähler mit clear ip access-list counters und dem Listennamen zurück.

R1# show ip access-lists ACL-VLAN20-IN
Extended IP access list ACL-VLAN20-IN
    10 permit tcp 10.10.20.0 0.0.0.255 host 10.10.50.10 eq 443 (1843 matches)
    20 permit udp 10.10.20.0 0.0.0.255 host 10.10.50.53 eq domain (912 matches)
    30 permit tcp 10.10.20.0 0.0.0.255 host 10.10.50.53 eq domain
    40 deny ip 10.10.20.0 0.0.0.255 10.0.0.0 0.255.255.255 log (27 matches)
    50 permit ip 10.10.20.0 0.0.0.255 any (20511 matches)
    60 deny ip any any log
!
R1# clear ip access-list counters ACL-VLAN20-IN

Richtung in oder out am Interface

in prüft Pakete, die über dieses Interface in den Router hineinkommen, bevor er sie routet. out prüft Pakete, die das Interface verlassen, nachdem die Routing-Entscheidung gefallen ist. Pro Interface, Richtung und Protokollfamilie ist genau eine ACL möglich, also eine IPv4-Liste in, eine IPv4-Liste out und dasselbe noch einmal für IPv6 mit ipv6 traffic-filter.

Eine eingehende Liste spart Arbeit, weil verworfene Pakete gar nicht erst geroutet werden. Eine ausgehende Liste ist sinnvoll, wenn Verkehr aus mehreren Quell-Interfaces zu einem Ziel gefiltert werden soll, etwa alles, was in das Server-VLAN hineingeht. Dabei gilt eine Ausnahme: Ausgehende ACLs prüfen keinen Verkehr, den der Router selbst erzeugt, also keine eigenen Pings, Routing-Updates oder Syslog-Meldungen.

Den Zugang zur Managementoberfläche des Routers selbst schützt keine Interface-ACL zuverlässig, weil der Router auf jeder seiner Adressen erreichbar ist. Dafür gibt es access-class auf den VTY-Leitungen, das nur SSH-Verbindungen aus erlaubten Netzen annimmt.

ip access-list standard ACL-MGMT
 10 permit 10.10.99.0 0.0.0.255
 20 deny any log
!
line vty 0 15
 access-class ACL-MGMT in
 transport input ssh

Änderungen ohne Aussperren

Eine benannte ACL kannst du bearbeiten, während sie am Interface aktiv ist. Jede neue Zeile wirkt sofort. Das ist praktisch und zugleich das Risiko: Wer die Liste mit no ip access-list extended löscht und neu eingibt, hat für einige Sekunden eine leere Liste am Interface. Je nach Plattform heißt das, alles ist erlaubt oder alles ist gesperrt. Sicherer sind gezielte Änderungen per Sequenznummer.

Für größere Umbauten auf entfernten Geräten gibt es zwei bewährte Wege. Der erste ist reload in mit einer Frist: Sperrst du dich aus, startet der Router nach Ablauf mit der gespeicherten Konfiguration. Der zweite ist, die neue Liste unter neuem Namen vollständig anzulegen und erst dann mit einem einzigen ip access-group-Befehl am Interface auszutauschen. Die alte Liste bleibt als Rückweg bestehen, bis die neue sich bewährt hat.

R1# reload in 10
!
R1# configure terminal
R1(config)# ip access-list extended ACL-VLAN20-IN
R1(config-ext-nacl)# 35 permit tcp 10.10.20.0 0.0.0.255 host 10.10.50.20 eq 3389
R1(config-ext-nacl)# end
!
R1# reload cancel
R1# copy running-config startup-config

Object-Groups für wachsende Regelwerke

Sobald eine ACL dieselben Server oder Netze in vielen Zeilen nennt, werden Object-Groups lesbarer. Eine Netzwerk-Objektgruppe fasst Hosts und Netze unter einem Namen zusammen, und die ACL-Zeile verweist auf diesen Namen. Kommt ein Server hinzu, änderst du nur die Gruppe, nicht jede Zeile.

Object-Groups werden in show ip access-lists nicht aufgelöst angezeigt. Für die Fehlersuche brauchst du zusätzlich show object-group. Auf Switches, die ACLs in Hardware umsetzen, wird jede Kombination aus Quell- und Zielobjekt zu einem eigenen Eintrag. Zwei Gruppen mit je zwanzig Objekten ergeben so aus einer Zeile vierhundert Einträge, und die Hardware-Ressourcen füllen sich schneller, als die kurze Liste vermuten lässt.

object-group network OG-WEBSERVER
 host 10.10.50.10
 host 10.10.50.11
 10.10.51.0 255.255.255.0
!
object-group network OG-CLIENTS-VERWALTUNG
 10.10.20.0 255.255.255.0
 10.10.21.0 255.255.255.0
!
ip access-list extended ACL-WEB
 10 permit tcp object-group OG-CLIENTS-VERWALTUNG object-group OG-WEBSERVER eq 443

Eine ACL ist keine Firewall

Eine ACL betrachtet jedes Paket für sich. Sie weiß nicht, ob es zu einer bestehenden Verbindung gehört, und sie kann nicht prüfen, ob in Port 443 wirklich HTTPS steckt. Das Schlüsselwort established erlaubt TCP-Pakete mit gesetztem ACK- oder RST-Bit und wirkt wie eine Antwortprüfung, lässt sich aber mit gefälschten Flags umgehen und hilft bei UDP gar nicht.

ACLs sind deshalb das richtige Werkzeug für grobe Segmentierung zwischen internen Netzen, für den Schutz der Managementebene und für die Auswahl von Verkehr in QoS, NAT und Route-Maps. Am Übergang ins Internet, zwischen Sicherheitszonen mit unterschiedlichem Schutzbedarf und überall, wo Anwendungen erkannt werden sollen, gehört eine zustandsbehaftete Firewall davor. Auf IOS XE ist das die Zone-Based Firewall, sonst eine eigene Firewall-Appliance.