Praxis-Lab: ACLs auf Cisco-Routern

Im Rahmen des Hardenings hat das Security-Team der NovaHealth entschieden, dass die Netzwerk-Komponenten ebenfalls gehärtet werden sollen. Dazu wird auf den Routern des Unternehmens eine ACL konfiguriert, die den Zugriff via SSH nur von bestimmten IP-Adressbereichen erlauben, die von den Admin-Workstations genutzt werden. Das verhindert, dass aus dem Internet oder von nicht autorisierten Systemen innerhalb des Unternehmensnetzwerks Verbindungen aufgebaut werden können.

Auch wenn wir uns aktuell mit dem Endpoint Hardening beschäftigen, sind Access Control Lists auf Cisco-Router ein schönes Beispiel für grundlegende ACLs. Wir schlagen hier den Bogen über einige Grundlagen zu ACLs im allgemeinen und betrachten anschließend den Router als Endgerät im Sinne einer Client-Server-Verbindung via SSH. In derselben Art und Weise, wie du es nachfolgend lernen wirst, können z.B. auch Managed Switches (von Cisco) gesichert werden.

In diesem Praxis-Lab lernst du:

• Wie ACLs auf Cisco-Routern und -Switches funktionieren
• Was der Unterschied zwischen Standard und Extended ACLs sind
• Wie du ACLs auf Cisco-Routern erstellst und Netzwerk-Traffic filtern kannst
• Wie du mit ACLs Client-IP-Adressen für den SSH-Zugriff einschränken kannst

Voraussetzungen

Für dieses Praxis-Lab benötigst du den Cisco Packet Tracer. Es ist kein Internetzugang oder anderes System erforderlich.

Aufbau der Laborumgebung

Erstelle im Packet Tracer die Umgebung folgendermaßen:

Du kannst dir dazu die fertige Packet Tracer-Datei hier herunterladen (erstellt mit Version 9.0.0). Die Geräte haben lediglich eine IP-Grundkonfiguration mit IP-Adresse und Gateway bzw. im Falle der Switches gar keine Konfiguration. Auf dem Server zudem ist der Webservice für HTTPS aktiviert. Das ist unsere Ausgangssituation.

ACL-Grundlagen auf Cisco-Routern

Während ACLs in Firewalls heutzutage dank der Stateful Inspection-Technologie nur noch die Richtung der initialen Verbindungsaufnahme filtern müssen, sind ACLs auf Cisco-Routern in ihrer grundlegenden Form nur statuslose Paketfilter. Dadurch eignen sie sich nur bedingt als Firewall-Ersatz, werden aber dennoch oft als Perimeterschutz bzw. First Line of Defense eingesetzt, um auf den Perimeter-Routern den Netzwerkverkehr grob zu filtern.

ACLs können auf Cisco-Routern für viele verschiedene Zwecke genutzt werden, insbesondere:

• Filtern von geroutetem Traffic (Perimeter-Schutz)
• Filtern von relevantem Traffic für
  • NAT-Regeln
  • IPsec-Regeln
  • Policy Routing
  • Quality of Service-Regeln
• Filtern von Traffic direkt zum Router (Telnet, SSH, HTTP, etc.)

Uns interessiert hier primär letzteres. Bevor wir jedoch in die Details gehen, noch ein paar weitere Informationen zu den ACLs auf Cisco-Routern. Wir unterscheiden hauptsächlich zwischen:

• Standard ACLs – Filterung nur nach Absenderadresse möglich
• Extended ACLs – Filterung nach Absender- und Zieladressen, Protokollen und ggf. TCP/UDP-Portnummern

In jedem Fall handelt es sich um eine geordnete Liste, die systematisch von oben nach unten abgearbeitet wird. Es wird nach dem Prinzip First Match entschieden und die Abarbeitung anschließend abgebrochen. Daher ist die Reihenfolge der ACEs entscheidend.

Am Ende jeder ACL existiert eine implizite Deny Any-Regel. Sie wird angewendet, wenn keine der expliziten Regeln (ACEs) passt.

Eine Besonderheit bei ACLs auf Cisco-Routern ist die Verwendung der sogenannten Wildcards Mask. Sie ist – vereinfacht gesagt – das Binärkomplement zur Subnetzmaske: Aus 255.255.255.0 wird z.B. 0.0.0.255 und aus 255.255.252.0 wird 0.0.3.255. Wir kommen in den Beispielen zu Extended ACLs darauf zurück.

Standard-ACLs

Prüfe zunächst via Ping, ob PC1 und PC2 den Server1 mit der IP 172.16.1.20 erreichen können – das sollte der Fall sein:

Nun wollen wir PC1 den Zugriff auf Server1 erlauben, PC2 jedoch nicht. Gehe dazu auf dem Cisco-Router in den Config-Mode und erstelle eine Standard-ACL in der folgenden Art:

R1#conf t
R1(config)#access-list 10 permit 10.1.1.101

Standard-ACLs erhalten eine ACL-Nummer zwischen 1 und 99, um auf sie zu referenzieren, hier 10. Die Aktion ist permit und die Hostadresse 10.1.1.101. Eine Subnetzmaske bzw. Wildcard Mask ist nicht erforderlich, da standardmäßig von einem einzelnen Host ausgegangen wird, wenn keine Wildcard Mask angegeben wird. Da am Ende der ACL ein implizites Deny Any steht, benötigen wir keinen zweiten ACE.

Um diese ACL anzuwenden, gehst du in das Interface, auf dem sie aktiviert werden soll und bindest sie mit dem Befehl ip access-group <Nummer> <in|out> an das Interface eingehend oder ausgehend – in unserem Fall eingehend, da wir das Interface Gi0/0/0 auswählen, auf dem die Kommunikation von PC1 und PC2 hereinkommt:

R1(config)#interface Gi0/0/0
R1(config-if)#ip access-group 10 in

Damit ist sämtliche Kommunikation von PC1 auf den Server1 möglich, während die ACL gar keine Kommunikation mehr von PC2 auf Server1 erlaubt. Teste nun erneut die Verbindung von PC1 und PC2 zu Server1 mit einem Ping. Während PC1 den Server nach wie vor erreichen kann, ist das von PC2 aus nicht mehr möglich, wie der nachfolgende Screenshot zeigt:

Entferne die aktive ACL-Bindung von Gi0/0/0 nun durch den Interface-Befehl:

R1(config-if)#no ip access-group 10 in
R1(config-if)#end
R1#

Der Ping von PC2 auf Server1 ist nun wieder möglich.

Extended ACLs

Standard-ACLs sind sehr einfach und grob. Extended ACLs ermöglichen eine feinere Filterung nach diversen Kriterien.

Standard-ACLs haben Nummern zwischen 1 und 99 und Extended-ACLs Nummern zwischen 100-199 (weitere Nummernbereiche existieren, sind hier aber nicht relevant). Um eine Extended-ACL zu definieren, nutzen wir also z.B. die Nummer 100. Damit können wir erweiterte Parameter festlegen. Lass uns wieder den Ping auf den Server ausschließlich für PC1 erlauben und auch den Zugriff via HTTPS, also Port 443/tcp. Dazu legst du eine ACL in der folgenden Art an:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 100 permit icmp host 10.1.1.101 host 172.16.1.20
R1(config)#access-list 100 permit tcp host 10.1.1.101 host 172.16.1.20 eq 443
R1(config)#int gi0/0/0
R1(config-if)#ip access-group 100 in

Von PC1 funktioniert nach wie vor der Ping auf Server1 und auch der Zugriff über die Anwendung Web Browser:

Andere Kommunikationsformen funktionieren jedoch nicht – von PC2 aus geht weder das eine noch das andere.

Dass es tatächlich auf die Reihenfolge der ACEs ankommt, testen wir im nächsten Schritt. Zuvor schauen wir uns jedoch die erstellte ACL einmal an. Gib den folgenden Befehl ein, um die ACL in der Running-Config anzuzeigen:

R1#sh run | include access-list
access-list 10 permit host 10.1.1.101
access-list 100 permit icmp host 10.1.1.101 host 172.16.1.20
access-list 100 permit tcp host 10.1.1.101 host 172.16.1.20 eq 443

Dies zeigt dir die Standard-ACL mit der Nummer 10 an, die wir anfangs erstellt haben, und die Extended-ACL mit der Nummer 100. Möchtest du eine ACL löschen, kannst du einfach die Nummer angeben. Löschen wir beide ACLs:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#no access-list 10
R1(config)#no access-list 100
R1(config)#exit
R1#
%SYS-5-CONFIG_I: Configured from console by console

R1#sh run | include access-list
R1#

Die Running-Config enthält anschließend keine ACL mehr. Allerdings gibt es noch immer den Verweis auf ACL 100 in der Interface-Konfiguration von Gi0/0/0, wie du dich mit dem Befehl sh run überzeugen kannst – du findest folgende Zeilen:

interface GigabitEthernet0/0/0
 ip address 10.1.1.1 255.255.255.0
 ip access-group 100 in
 duplex auto
 speed auto

Darauf musst du in der Praxis achten – sowohl die ACL, als auch die Verknüpfung mit einem Interface einzurichten bzw. zu entfernen. Gib nun also noch die folgenden Befehle ein, um die Verknüpfung zu entfernens:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int g0/0/0
R1(config-if)#no ip access-group 100 in
R1(config-if)#end
R1#

Doch jetzt wollten wir ja demonstrieren, warum es wichtig ist, die Reihenfolge zu beachten. Ein typisches Szenario ist das folgende:

access-list 100 deny ip 10.1.1.0 0.0.0.255 host 172.16.1.20
access-list 100 permit icmp host 10.1.1.101 host 172.16.1.20
access-list 100 permit tcp host 10.1.1.101 host 172.16.1.20 eq 443

In dieser ACL wird zunächst jeglicher Zugriff über beliebige IP-Protokolle (daher ip) aufServer1 vom gesamten Subnetz 10.1.1.0/24 verboten, bevor PC1 (10.1.1.101) bestimmte Kommunikationsformen erlaubt werden – das funktioniert jedoch nicht, da die erste Regel bereits alles blockiert und die darunter stehenden ACEs niemals zum Tragen kommen.

SSH-Zugriff auf den Router beschränken

Nun kommen wir zum eigentlichen Ziel dieses Praxis-Labs – dem Schutz des SSH-Zugangs. Der Zugriff auf den Router selbst geschieht über die virtuellen Terminals (VTY). Hiervon hat ein Cisco-Router mehrere, im Packet Tracer sind das die VTYs 0-15. Standardmäßig ist der Zugriff via Telnet möglich. Dieses Protokoll ist unsicher und sollte deaktiviert und durch SSH ersetzt werden. Zur Aktivierung von SSH sind einige Voraussetzungen erforderlich:

• ein Hostname
• ein Domainname
• ein RSA-Schlüsselpaar
• ein Benutzerkonto (ggf. mit Privilege Level 15 für administrativen Zugriff)
• aktivierte VTY-Lines mit SSH-Unterstützung (optional aber empfehlenswert: Telnet deaktivieren)

Den Hostname ist schon gesetzt. Die anderen Voraussetzungen schaffst du mit folgenden Befehlen:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip domain-name cybersec-lab.local
R1(config)#username admin privilege 15 secret Pa$$w0rd
R1(config)#crypto key generate rsa
The name for the keys will be: R1.cybersec-lab.local
Choose the size of the key modulus in the range of 360 to 4096 for your
  General Purpose Keys. Choosing a key modulus greater than 512 may take
  a few minutes.

How many bits in the modulus [512]: 2048
% Generating 2048 bit RSA keys, keys will be non-exportable...[OK]

R1(config)#ip ssh version 2
*Mar 1 4:7:27.962: %SSH-5-ENABLED: SSH 1.99 has been enabled
R1(config)#line vty 0 15
R1(config-line)#login local
R1(config-line)#transport input ssh
R1(config-line)#end

Wir legen einen User admin als Administrator an, erstellen hier einen 2048-Bit RSA-Schlüssel und mit transport input ssh aktivieren wir zum einen SSH und deaktivieren gleichzeitig Telnet. Teste nun die Verbindung von PC1 und PC2 via SSH zum Router R1, indem du auf den PCs unter Desktop die Anwendung Telnet / SSH Client öffnest und die entsprechenden Parameter auswählst bzw. eingibst, wie nachfolgend gezeigt:

Nach Klick auf Connect öffnet sich das SSH-Terminal. Nachdem du das Passwort eingegeben hast, erhältst du einen Prompt und eine CLI:

Aktuell funktioniert der Zugriff von beiden PCs. Lass uns nun eine passende ACL erstellen und den TTYs zuweisen, um ausschließlich PC1 den Zugriff zu erlauben. Hierzu benötigen wir nur eine Standard-ACL. Der Zuweisungsbefehl ist dieses Mal nicht ip access-group <ACL-Nr> sondern access-class <ACL-Nr>. Die erforderlichen Befehle sind nachfolgend dargestellt und im Anschluss lassen wir uns die VTY-Line-Konfiguration gleich noch anzeigen:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 10 permit 10.1.1.101
R1(config)#line vty 0 15
R1(config-line)#access-class 10 in
R1(config-line)#end
R1#
%SYS-5-CONFIG_I: Configured from console by console

R1#sh run | begin line vty
line vty 0 4
 access-class 10 in
 logging synchronous
 login local
 transport input ssh
line vty 5 15
 access-class 10 in
 logging synchronous
 login local
 transport input ssh
!
!
!
end

Testen wir es aus: Von PC1 funktioniert der Zugriff weiterhin, von PC2 nicht mehr:

Die Meldung Session Terminated auf PC2 ist im Packet Tracer etwas irreführend. Der SSH-Server auf dem Router hat die Verbindungsanfrage in Wirklichkeit einfach abgelehnt.

Damit sind wir am Ende dieses Praxis-Labs angelangt. Du hast nun gelernt, wie du ACLs auf Cisco-Router konfigurieren und einsetzen kannst, um Netzwerk-Traffic zu filtern und den SSH-Zugang zum Router selbst zu beschränken. ACLs auf Cisco-Routern sind sehr einfach gehalten und stellen ein gutes Beispiel für die Grundform dieser Zugriffskontrolle dar.