Private VLANs
Private VLANs sind ein Feature, mit dem sich Geräte innerhalb einer geswitchten Umgebung separieren lassen:
Private VLANs (PVLANs) – Promiscuous, Isolated, Community
Configuring Isolated Private VLANs on Catalyst Switches
Catalyst 3560 Software Configuration Guide, Release 12.2(52)SE – Configuring Private VLANs
Zu dieser bisher Cisco-proprietären Technik ist jetzt ein RFC erschienen:
RFC 5517 – Cisco Systems’ Private VLANs: Scalable Security in a Multi-Client Environment
Cisco IOS: Vorbereitung einer DAI (Dynamic ARP Inspection) Implementierung
Dynamic ARP Inspection (DAI) ist ein Mechanismus in Cisco-Switchen (ab Catalyst 2960), der ARP-Pakete auf Fälschungen untersucht. Dadurch sollen beispielsweise ARP-Spoofing-Attacken verhindert werden, bei denen ein Angreifer ARP-Antworten sendet, in denen er eine fremde IP mit der eigenen MAC-Adresse verbindet, um sich in die Kommunikation einzuklinken.
Wenn DAI auf einem Cisco-Switch aktiviert wird, vergleicht der Switch bei den ARP-Paketen, ob die MAC-Adresse auch zu der IP-Adresse passt. Für diesen Vergleich muss der Switch natürlich die korrekte Zuordnung kennen. Diese lernt er normalerweise über DHCP-Snooping, bei dem die DHCP-Kommunikation beobachtet wird und der Switch “sieht”, welche IP einem Gerät mit einer bestimmten MAC-Adresse zugeordnet wurde.
Weitere Erklärungen zu DAI:
Cisco.com: Configuring Dynamic ARP Inspection
LAN Switch Security: What Hackers Know About Your Switches
Am einfachsten ist DAI zu implementieren, wenn alle Geräte in einem VLAN ihre IP per DHCP bekommen. In diesem Fall kann der Switch die IP-zu-MAC-Datenbank alleine aufbauen und benötigt keine statischen Einträge. Bei meinen letzten Implementierungen hat sich aber gezeigt, dass die Aussage der PC-Admins, dass in diesem Netz nur DHCP-Clients seien, nicht unbedingt heißen muss, dass nicht manche Geräte doch eine statische Konfiguration haben … 
Deshalb ist es sinnvoll, vorher ein paar Checks durchzuführen, um diese Geräte aufzuspüren. Eine Möglichkeit ist, die Einträge in der ARP-Tabelle des L3-Switches mit den Einträgen in der DHCP-Snooping-Tabelle zu vergleichen. Wenn in der ARP-Tabelle ein Eintrag vorhanden ist (und dies ist nicht das Gateway), es aber zu dieser IP keinen Eintrag in der DHCP-Tabelle gibt, dann besteht die Chance, dass dieser PC doch eine statische IP-Konfiguration hat.
Um diesen Vergleich zu erleichern, habe ich das folgende –sehr simpel gehaltene– Python-Script geschrieben.
Ein Beispiel zur Benutzung des Scriptes. Für das Vlan63 soll die ARP-Tabelle mit der DHCP-Snooping-Tabelle verglichen werden:
- Sicherstellen, dass die ARP-Tabelle des L3-Switches aktuell ist
- Ausgeben der ARP-Tabelle des Cisco-L3-Switches:
- Ausgeben der DHCP-Snooping-Tabelle des Cisco-Access-Switches, auf dem DAI konfiguriert werden soll:
- Auswerten der beiden Dateien mit dai-check.py:
Wenn Geräte dabei sind, die häufiger für ein paar Stunden inaktiv sind, dann könnte es sein, dass für diese kein Eintrag in der ARP-Tabelle enthalten sind. Deshalb pinge ich alle Geräte in dem Vlan einmal an:
karstens-macbook-pro:~ karsten$ nmap -sP 192.168.63.0/24
Starting Nmap 4.76 ( http://nmap.org ) at 2009-08-28 18:09 CEST
...
Host 192.168.63.201 appears to be up.
Host 192.168.63.254 appears to be up.
Nmap done: 256 IP addresses (174 hosts up) scanned in 48.12 seconds
karstens-macbook-pro:~ karsten$
L3-Switch>term len 0
L3-Switch>sh arp | i Vlan63
Internet 192.168.63.254 - 001a.b1f3.9ab2 ARPA Vlan63
Internet 192.168.63.201 137 001c.79a5.ad41 ARPA Vlan63
Internet 192.168.63.79 213 0022.63a9.6384 ARPA Vlan63
...
Diese Liste wird abgespeichert; z.B. als dai-arp.txt
Access-Switch>term len 0
Access-Switch>sh ip dhcp snooping binding vlan 63 | i dhcp-snooping
00:0F:FE:5C:E0:CF 192.168.63.83 223101 dhcp-snooping 63 FastEthernet2/0/28
00:1C:79:A5:AD:41 192.168.63.201 233322 dhcp-snooping 63 FastEthernet1/0/28
...
Auch diese Liste wird abgespeichert; z.B. als dai-dhcp.txt. Das “| i dhcp-snooping” ist deshalb wichtig, weil das Script nur die reine Tabelle ohne Header erwartet. Das könnte/sollte ich sicher einmal verbessern. Wenn das Vlan sich über mehrere Switche erstreckt, werden diese show-Ausgaben einfach in einer Datei gesammelt.
karstens-macbook-pro:~ karsten$ ./dai-check.py dai-arp.txt dai-dhcp.txt
['Internet', '192.168.63.254', '-', '001a.b1f3.9ab2', 'ARPA', 'Vlan63']
['Internet', '192.168.63.206', '137', '001c.79a4.af26', 'ARPA', 'Vlan63']
Das Script dai-check.py sucht jetzt zu jeder IP aus der ARP-Tabelle, ob es diese IP auch in der DHCP-Tabelle gibt. Am Ende wird eine Liste der Einträge aus der ARP-Tabelle ausgegeben, zu denen es keine Entsprechung in der DHCP-Tabelle gibt. Im obigen Beispiel war das die 192.168.63.254 (das Default-Gateway) und die 192.168.63.206, die tatsächlich eine statische Konfiguration hat.
Das Script ist sehr rudimentär, so gibt es beispielsweise keinerlei Checks, ob die Tabellen auch wirklich die richtigen Daten beinhalten. Wer falsche Daten eingibt, wird vermutlich auch ein falsches Ergebnis erhalten!
Der Cisco VPN-Client im MacOS X 10.6 Snow Leopard – Teil 2
In etlichen Mac-Online-Publikationen (u.a. maclife, Macbug) kann man lesen, dass der eingebaute VPN-Client nur IPSec over TCP, aber kein IPSec over UDP unterstützt.
Das ist in dieser Form aber falsch. Im Moment bin ich hinter einem NAT-Gateway und connecte mich mit dem SL-Client auf einen IOS-Router (12.4(15)T9) als IPSec-Gateway (die 89.246.26.242 ist dabei meine DSL-IP):
c2811>sh crypto session remote 89.246.26.242
Crypto session current status
Interface: Virtual-Access2
Username: karsten.iwen
Profile: vpn-ra
Group: VPN-RA
Assigned address: 10.10.10.1
Session status: UP-ACTIVE
Peer: 89.246.26.242 port 4500
IKE SA: local a.b.c.d/4500 remote 89.246.26.242/4500 Active
IPSEC FLOW: permit ip 10.10.0.0/255.255.0.0 host 10.10.10.1
Active SAs: 2, origin: crypto map
Deutlich ist zu erkennen, dass hier das standardkonforme IPSec over UDP (NAT-Traversal) verwendet wird. Ob das Cisco-proprietäre IPSec over UDP unterstützt wird kann ich nicht sagen. Aber wer das einsetzt lebt vermutlich sowieso noch im Jahr 1999 und glaubt immer noch, dass sich ATM nächstes Jahr durchsetzt …
Der Cisco VPN-Client im MacOS X 10.6 Snow Leopard
Das Update auf Mac OS X Snow Leopard wurde heute geliefert und die Installation war nach entspannten 45 Minuten ohne weitere Benutzereingriffe erledigt.
Auf den ersten Blick gab es eigentlich keine sichtbaren Änderungen, aber das war auch das was ich erwartet habe.
Mein erster Test galt dem eingebauten VPN-Client, der unter 10.6 neben dem schon vorher unterstützten PPTP und L2TPoverIPSec nun auch nativ das Cisco IPSec-VPN unterstützt. Das ist vor allem deshalb interessant, da Cisco den IPSec-Client nicht weiterentwickelt und deren Präferenz der AnyConnect-Client ist, der z.Zt. aber nur SSL-VPNs unterstützt.
Die Konfiguration ist recht einfach:
In den Netzwerk-Eigenschaften eine neue Verbindung anlegen Cisco VPN auswählen, VPN-Server-Adresse, Username konfigurieren und unter den Identifizierungseinstellungen die Gruppe mit PSK bzw. das Zertifikat konfigurieren:
Nachdem man das VPN verbunden hat bekommt man in der Menüleiste auf Wunsch ein Icon eingeblendet:
Ein paar Einschränkungen gegenüber dem Cisco VPN-Client sind mir aber aufgefallen:
- Es gibt keine Möglichkeit Backup-Server einzutragen.
- Keine eingebauten Statistiken
- Keine Mutual Group-Authentication
Auch mehrere Adressen im Feld “Serveradresse” gehen nicht.
Wenn die VPN-Gegenstelle eine Cisco ASA ist, dann ist diese Authentifizierung eine recht einfache Methode, um Man-in-the-Middle-feste VPNs hinzubekommen, was mit PSKs und digitalen Zertifikaten alleine etwas aufwendiger ist. Diese Einschränkung ist IMHO die wichtigste, die gegen den eingebauten Client spricht. Zumindest meine bevorzugte VPN-Art ist immer noch IPSec gegen die ASA wenn es um Remote-Access geht.
Glücklicherweise läuft der original Cisco-VPN-Client auch noch unter Snow Leopard, so dass man noch nicht auf den eingebauten Client wechseln muss.
Der IOS SCP-Server
Das Cisco IOS stellt schon seit geraumer Zeit einen SCP-Server zur Verfügung. Trotzdem beobachte ich immer wieder, daß IOS-Images standardmäßig per TFTP übertragen werden. Und das selbst dann, wenn die Client-Plattform “nativ” scp unterstützt.
Auch wenn die SCP-Server-Implementierung in meinen Augen suboptimal ist (was die Berechtigungen angeht), ist die Benutzung des Servers recht einfach:
- SSH konfigurieren
- Den SCP-Server einschalten
- Authentifizierung und Autorisierung konfigurieren
- Useraccounts anlegen
- Kopieren der Daten vom Client
SSH benötigt public/private keys. Für das Generieren der Keys muss man einen Host- und Domain-Namen konfigurieren. (Es gibt Tricks, ohne einen Domain-Namen auszukommen, aber der läuft nicht auf allen Plattformen). Die Key-Länge sollte mindestens 1024, besser 2048 Bit sein. Neuere IOS-Releases unterstützen sogar bis 4096 Bit. Weiterhin sollte man die Verwendung der älteren SSH-Version 1 verbieten:
hostname MyDevice
ip domain-name example.org
crypto key generate rsa general-keys modulus 2048
ip ssh version 2
ip scp server enable
Für SCP muss der Router so konfiguriert werden, dass der User direkt Lese- und Schreibrechte auf das Flash hat. Dies wird durch die Exec-Autorisierung gemacht:
aaa new-model
aaa authentication login default local
aaa authorization exec default local
Der Benutzer bekommt einen Privilege-Level von 15 per Exec-Autorisierung zugewiesen:
username Admin privilege 15 secret 0 My0wnV3ryS3cur3Passw0rd
Hierbei muss die Syntax genau beachtet werden. Der Speicher- bzw. der Quellort im Router muss komplett angegeben werden (hier “flash:/):
scp Quelldatei User@MyDevice.example.org:flash:/Zielname
Auch wenn ich in diesem Beitrag immer Router geschrieben habe, so gilt dasselbe auch für die Switche. Voraussetzung ist natürlich jeweils ein Crypto-fähiges Image.
Und natürlich gibt es auch bei Cisco eine SCP-Anleitung.
Network Security Baseline
Ein recht gut gelungenes Dokument zur Grund-Absicherung einer Cisco-basierten Infrastruktur:
Update der SAFE-Blueprints
Die SAFE-Dokumente von Cisco sind seit deren Erscheinen wichtige Informationsquellen für die Security-Belange des Netzwerk-Designs. Diese Dokumente liegen jetzt in aktualisierten Versionen vor und sind interessant wie eh und je: http://www.cisco.com/go/safe
Cisco ASA Software 8.2
Dem Cisco Security Monthly Newsletter nach ist die neue Version 8.2 jetzt verfügbar. Eben konnte ich sie im Download-Center zwar noch nicht herunterladen, aber jetzt kann es nicht mehr lange dauern.
Aus der Unmenge an Neuigkeiten, wobei vieles auch Voice betrifft, finde ich die folgenden neuen Funktionen am interessantesten:
- Ein Botnet-Filter, der infizierte Clients erkennen soll.
- IPv6 Support für das AIP SSM Modul.
- Eine Security Services Card (SSC) für die 5505. Jetzt kann auch auf der kleinen ASA Intrusion Prevention betrieben werden, auch wenn die Funktionalität dieses Moduls gegenüber der AIP-SSMs oder der 4200er Sensoren eingeschränkt ist. Mal sehen, wie teuer das Modul wird.
- Der AnyConnect-Client ist jetzt in einer “Essentials”- und in einer “Premium”-Version vorhanden.
- Ein Lizenz-Server, um SSL-Lizenzen auf eine größere Anzahl von ASAs aufzuteilen. Wie es aussieht, hilft es aber nicht gegen die Lizenz-Verschwendung beim Active/Standby Failover.
- SNMPv3
- Cisco NetFlow Secure Event Logging
- TCP state bypass
