lucadp - stock.adobe.com
Netzwerkverschlüsselung mit MACsec zwischen Switch und Endgerät
Sichere Verschlüsselung zwischen Switch und Client. Die wichtigsten Schritte für MACsec: vom Profil auf dem Server über Einstellungen am Switch bis hin zur Einrichtung am Client.
Wer Access-Ports auf kabelgebundenen Links absichern möchte, setzt auf MACsec. In diesem Serienteil konfigurieren wir ein Switch-zu-Client-Szenario im dynamischen CAK-Modus. Die Schlüssel entstehen dabei über 802.1X mit EAP-TLS und RADIUS. Das MKA leitet daraus die SAKs für den Datenverkehr ab. Wir zeigen praxisnah die Vorbereitung des Autorisierungsprofils auf Cisco ISE (Must-Secure/Should-Secure), die Umsetzung auf Aruba AOS-CX und Cisco Catalyst/IOS XE inklusive MKA-Parametern (Cipher, Confidentiality-Offset, Replay-Window) sowie die Einbindung der Supplicants unter Linux (wpa_supplicant) und Windows/macOS (Cisco Secure Client). Beispiel-Clients können etwa ein WLAN-Access-Point, ein Multifunktionsgerät oder ein PC im öffentlich zugängigen Bereich von Gebäuden sein – abgesichert wird dabei der Ethernet-Uplink, nicht das Funknetzwerk.
Die ersten beiden Teile der Artikelserie zu MACsec behandelten die Grundlagen und Szenarien sowie die Schlüsselverteilung und Verschlüsselung.
Dynamischer CAK-Modus
Die Konfiguration gliedert sich in drei Bestandteile: Parametrierung des Authentication-Servers (RADIUS), des Authenticators (Switches) und des Supplicants (Clients). Im konkreten Szenario zwischen Switch und Client werden keine statischen Schlüssel (PSK) auf beiden Geräten hinterlegt, sondern es kommt das IEEE-802.1X-Framework in Kombination mit IEEE 802.1AE für MACsec zum Einsatz. Dies wird genutzt, um einen dynamischen Connectivity Association Key (CAK) abzuleiten. Das Endgerät authentifiziert sich dabei über EAP-TLS und EAPoL-Frames und der Switch kapselt diese in RADIUS-Anfragen und sendet sie an den Authentifizierungsserver.
Der Authentifizierungsserver prüft die Zertifikatsinhalte des Endgeräts in der RADIUS-Anfrage. Falls die Authentifizierung erfolgreich war, sendet der Authentifzierungsserver ein RADIUS Access-Accept. Im Fall von MACsec erhält der Switch noch herstellerspezifische Erweiterungen im Access-Accept, die ihn veranlassen, MACsec auf dem Link zum Endgerät zu nutzen. Im Fall von Cisco Switches, wie es in Abbildung 1 dargestellt ist, findet dies über das Attribut/Wert-Paar cisco-av-pair = linksec-policy=must-secure statt. Alternativ wäre auch ein should-secure möglich, wobei dann MACsec nur zur Anwendung kommt, wenn dies auch das Endgerät unterstützt. Ansonsten würde keine Verschlüsselung stattfinden. Auf Basis der EAP-TLS-Authentifizierung steht ein Master Session Key (MSK) bereit. Dieser MSK wird zur Ableitung des CAK verwendet und der entsprechende Connectivity Association Key Name (CKN) wird aus der EAP-Session-ID abgeleitet. Auf Basis dieses CAK und dem MACsec Key Agreement (MKA) werden dann eindeutige Security Association Keys (SAK) abgeleitet, über die die eigentlichen Nutzdaten verschlüsselt werden.
Konfigurationsbeispiele
Die dargestellten Konfigurationsbestandteile basieren auf unterschiedlichen Plattformen. Die grundsätzlichen Terminologien lassen sich recht leicht auf andere Lösungen adaptieren. Es ist wichtig zu wissen, dass Microsoft Windows und macOS derzeit über keine integrierte MACsec-Funktionalität verfügen. Es braucht also einen Supplicant eines Drittanbieters, wie beispielsweise den Cisco Secure Client mit dem Network Authentication Modul (NAM), der nachinstalliert werden muss. Unter Linux unterstützt der wpa_supplicant, der vielen aus der 802.1X-Authentifizierung in Kombination mit WLAN bekannt ist, bereits MACsec.
Die Konfigurationen sind auf den MACsec-spezifischen Anteil mit IEEE 802.1X beschränkt. Die Konfigurationen können bei anderen Herstellern, Hardwaremodellen oder auch Softwareversionen abweichen.
Switch zu Endgerät mit dynamischer Schlüsselverteilung
Beginnen wir zunächst mit dem Authentication-Server. In diesem Fall nutzten wir dazu eine Cisco Identity Services Engine im Release 3.2. Auf diesem Server muss der Administrator zunächst, wie in Abbildung 1 dargestellt, ein Autorisierungsprofil mit dem MACsec-Attribut must-secure definieren.
Dies führt dazu, dass bei erfolgreicher Autorisierung mit diesem Profil das Attribut/Wert-Paar cisco-av-pair = linksec-policy=must-secure gesetzt würde, um dem Switch zu signalisieren, dass MACsec genutzt werden soll. Im Nachgang ist es wie in Abbildung 2 dargestellt nötig, auf Basis der Klassifizierung aus der Authentifizierungsrichtlinie den gewünschten Endgeräten das Autorisierungsprofil in einer Autorisierungsrichtlinie zuzuweisen. Konkret wertet der Authentifizierungsserver die Zertifikatsinhalte des Common Names aus und weist allen Geräten mit den Präfixen PC für PCs und Notebooks oder AP für WLAN-Access-Points die MACsec Richtlinie zu.
Auf Switch-Seite braucht es etwas mehr Handarbeit auf der Kommandozeile. Ein Beispiel für einen HPE-Aruba-AOS-CX-Switch haben wir in Listing 1 beigefügt. Zunächst legt der Admin einen RADIUS-Server auf dem Switch an und bindet diesen in eine AAA-Gruppe ein. Im Anschluss legt man eine MACsec-Richtlinie mit den gewünschten Cipher Suites für die Verschlüsselung an, also im Beispiel AES-GCM-256-XPN. Diese Richtlinie wird dann in einer Port-Acces- Rolle gebunden und mit der Authentifizierungsmethode device-mode für den Authenticator-Modus des Switches und verknüpft. Im Nachgang wird die IEEE-802.1X-Authentifizierung im Bereich aaa authentication port-access global auf dem Switch aktiviert und an die zuvor angelegte RADIUS-Server-Gruppe gebunden. Auf der gewünschten Schnittstelle, also im Beispiel Port 1/1/1, wird im Anschluss der Authenticator-Modus aktiviert und darin MACsec mit der CAK-Länge 16 aktiviert.
switch(config)# radius-server host 192.0.2.1 key ciphertext t0ps3cr3t vrf mgmt
switch(config)# aaa group server radius dot1x
switch(config-sg)# server 192.0.2.1 vrf mgmt
switch(config-sg)# exit
switch(config)# macsec policy mp1
switch(config-macsec-policy)# cipher-suite gcm-aes-xpn-256
switch(config)# port-access role AOSCX-Switch
switch(config-pa-role)# associate macsec-policy mp1
switch(config-pa-role)# auth-mode device-mode
switch(config)# aaa authentication port-access dot1x authenticator enable
switch(config)# aaa authentication port-access dot1x authenticator radius server-group dot1x
switch(config)# interface 1/1/1
switch(config-if)# no shutdown
switch(config-if)# no routing
switch(config-if)# vlan access 10
switch(config-if)# aaa authentication port-access dot1x authenticator
switch(config-if-dot1x-auth)# mka cak-length 16
switch(config-if-dot1x-auth)# macsec
switch(config-if-dot1x-auth)# enable
Listing 1: Beispielkonfiguration einer MACsec Verschlüsselung auf einem Downlink zu einem Endgerät basierend auf einem Aruba AOS-CX Switch.
Bei einem Cisco-Switch Catalyst 9300 in Listing 2 sieht es ähnlich aus. Zunächst braucht es eine Definition der RADIUS-Server mit IP-Adresse, Ports und Shared Secret. Im Nachgang referenziert der Administrator diese Definition in den AAA-Einstellungen für Authentifizierung, Autorisierung und Accounting und aktiviert IEEE 802.1X global. MACsec-spezifisch bedarf es zusätzlich einer MKA-Richtlinie. In dieser legt der Systemadministrator die Priorität für den Key Server auf dem Link fest, wobei niedrigere Werte präferiert werden. Zusätzlich noch den eingesetzten Verschlüsselungsalgorithmus passend zum Supplicant, also im Beispiel in Listing 2 AES-256-GCM. Den Confidentiality Offset setzt der Administrator in der MKA-Richtlinie auf 0 Byte. Hierdurch verschlüsselt MACsec den gesamten Frame. Im Fall von Switch-Kopplungen könnte man hierbei einen bestimmten Anteil des Frames unverschlüsselt lassen, um beispielsweise VLAN-Tags für Transitkomponenten auswertbar zu lassen. Über die Replay-Protection legt der Administrator fest, inwieweit die Frame-Reihenfolge von der regulären Reihenfolge abweichen darf.
Zu guter Letzt findet die Einrichtung des physischen Ports statt. Darin definiert der Integrator neben den klassischen 802.1X-Einstellungen eine Referenz auf die MKA-Richtlinie, eine Aktivierung von MACsec und eine Linksec-Richtlinie auf must-secure, um die Verschlüsselung zu erzwingen.
radius server macsec-rad
address ipv4 192.0.2.1 auth-port 1812 acct-port 1813
key t0ps3cr3t
!
aaa group server radius macsec
server name macsec-rad
!
aaa new-model
aaa authentication dot1x default group macsec
aaa authorization network default group macsec
aaa accounting dot1x default start-stop group macsec
!
dot1x system-auth-control
!
mka policy CW_MKA
key-server priority 100
macsec-cipher-suite gcm-aes-256
confidentiality-offset 0
replay-protection window-size 10
!
interface GigabitEthernet2/0/1
description CW_MACsec_Client
switchport mode access
switchport access vlan 10
macsec
authentication host-mode multi-auth
authentication order dot1x
authentication port-control auto
dot1x pae authenticator
authentication linksec policy must-secure
mka policy CW_MKA
spanning-tree portfast
Listing 2: Beispielkonfiguration einer MACsec Verschlüsselung auf einem Downlink zu einem Endgerät basierend auf einem Cisco Catalyst 9300 Switch in IOS-XE 17.12.
Zu guter Letzt geht es an den Supplicant. Im Fall von Linux also an den wpa_supplicant. MACsec wird seit dem 4.6er Kernel unterstützt, wobei jedoch beim Kompilieren das Argument CONFIG_MACSEC=m gesetzt sein muss. Im Nachgang muss der Admin wie in Listing 3 dargestellt noch eine dot1x.conf-Datei für den wpa_supplicant anlegen. Die Einstellungen können dann mit sudo wpa_supplicant -i eth0 -D macsec_linux -c dot1X.conf -ddd angewandt werden, um MACsec an die Schnittstelle eth0 zu binden. Im Fall von DHCP auf dem Client muss noch der DHCP-Prozess über sudo dhcpcd macsec0 an die macsec0-Schnittstelle gebunden werden. In Listing 3 erkennen wir, dass EAP-TLS auf Basis von IEEE 802.1X mit aktivierter MACsec-Policy und den entsprechend referenzierten Zertifikaten verwendet wird.
eapol_version=3
ap_scan=0
network={
key_mgmt=IEEE8021X
eap=TLS
identity="pc1234"
ca_cert="/etc/ssl/certs/radius_ca_chain.pem"
client_cert="/etc/ssl/client_certs/client.crt"
private_key="/etc/ssl/client_certs/client.key"
eapol_flags=0
macsec_policy=1
}
Listing 3: Beispielkonfiguration eines wpa_supplicants für MACsec auf Linux.
Im Falle eines Cisco Secure Clients mit NAM-Modul auf Windows oder macOS als Supplicant bedarf es eines MACsec-Profils. Der Administrator kann dies im zugehörigen Profil-Editor für den Cisco Secure Client anlegen. Dazu muss er, wie in Abbildung 3 ersichtlich, im Bereich Networks/Security als Schlüsselverwaltung MKA und zusätzlich den Verschlüsselungsalgorithmus für MACsec auswählen. Dieser muss mit dem Switch kompatibel und symmetrisch konfiguriert sein. In unserem Beispiel wählten wir AES-GCM mit 128 Bit. Der Administrator muss dieses Profil anschließend auf dem Client importieren.
