Absicherung NFS: Difference between revisions

Latest revision as of 13:59, 8 November 2022

Grundlagen

802.1x

802.1x ist ein Standard zur Authentifizierung in Netzwerken. Ein Client (Supplicant), welcher sich physisch an einem Switchport (Authenticator) oder drahtlos mit einer SSID verbindet, wird über einen Server (Authentication Server, z.B. RADIUS) authentifiziert.

RADIUS

RADIUS (Remote Authentication Dial In User Service) ist ein Protokoll für zentrale Authentifizierung, Autorisierung und Accounting in Netzwerken. Das Protokoll arbeitet auf OSI Layer 7 (Anwendungsebene). Der Ablauf der 802.1x Authentifizierung unter Verwendung von RADIUS sieht wie folgt aus:

RADIUS als Protokoll wird hier zwischen dem Switch (Authenticator) und RADIUS Server (Authentication Server) gesprochen. In den RADIUS Paketen sind die unveränderten EAP Pakete des Clients (Supplicant) enthalten.

EAP

EAP steht für Extensible Authentication Protocol (RFC3748) und ist ein allgemeines Authentifizierungsprotokoll, welches mehere Authentifizierungsverfahren unterstützt. Das im nachfolgenden verwendete Verfahren EAP-TLS ist in RFC5216 definiert. Der Ablauf von EAP-TLS zusammen mit RADIUS als Authentication Server sieht folgendermaßen aus :

Kommunikation zwischen Supplicant und Authenticator:
1. Authenticator schickt ein EAP-Request/Identity Paket an den Supplicant
2. Supplicant antwortet mit EAP-Response/Identity an den Authenticator
Kommunikation zwischen RADIUS Server und Supplicant (der Authenticator tunnelt die EAP Pakete)
1. Der RADIUS Server schickt ein EAP-TLS/Start Paket an den Supplicant
2. Supplicant antwortet mit EAP/Reponse Paket und EAP-Type=EAP-TLS, TLS Records: client-hello, opt. cipher-spec ansonsten TLS_NULL_WITH_NULL_NULL
3. RADIUS Server antwortet mit EAP/Request und EAP-Type=EAP-TLS, TLS Records: server-hello und weitere TLS Records
4. Der TLS Handshake erfolgt durch EAP/Request und EAP/Response Pakete bei denen die Nutzdaten die TLS Records enthalten
5. Nach Empfang des TLS finished records verschickt der Supplicant eine weitere EAP/Response EAP-Type=EAP-TLS Nachricht
6. RADIUS Antwortet mit EAP-Success

Paketformat

Die EAPoL Nachrichten, welche zwischen Supplicant (Client) und Authenticator (Switch) ausgetauscht werden, sind Ethernet Frames, welche ein 802.1x Paket als Payload haben. Im 802.1x Paket ist wiederum der Payloadtype auf EAP gesetzt. Kommt ein solches Layer2 Paket am Authenticator an, entfernt dieser den Ethernet und 802.1x Header und verpackt das EAP Paket in ein RADIUS Paket, welches mittels UDP/IP an den RADIUS Server übertragen wird. Der Switch tunnelt also die EAP Pakete, welche er vom Client erhält, zum RADIUS Server. Durch dieses Prinzip muss der RADIUS Server weder Teil desselben Layer 2 Segments sein, noch eine IP Adresse im gleichen Subnetz wie Supplicant oder Authenticator besitzen. Dies erlaubt Unternehmensweit einen einzigen RADIUS Server zu betreiben. Aufgrund der Ausfallsicherheit sollte jedoch mindestens ein weiterer RADIUS Server zur Verfügung stehen.

Umsetzung

Plan

Step 1: Authentifizierung mit 802.1x. 1x Switch, 1x Client und 1x RADIUS Server

Step 2: CSR in TPM generieren oder Zertifikat und privaten Schlüssel importieren.

Step 3: Privaten Schlüssel (zum Zertifikat) aus TPM für 802.1x verwenden.

Step 1

FreeRADIUS Server aufsetzen und konfigurieren
1. FREERADIUS kann aus den apt Paketquellen installiert werden mit:
  sudo apt install freeradius
2. radtest ist ein Kommandozeilentool, mit welchem die Kommunikation mit einem RADIUS Server getestet werden kann. Mit folgendem Befehl kann die Erreichbarkeit des RADIUS Server auf localhost getestet werden:
  radtest {username} {password} {hostname} 10 {radius_secret}
3. hierfür muss ein Client in der config Datei clients.conf, mit dem entsprechenden RADIUS Secret und Hostname/IP, angelegt werden. Außerdem muss ein Benutzer angelegt werden in der users.conf mit {username} und {password}.

Switch mit 3 VLANs eingerichtet. VLAN 50 wurde für die "Infrastruktur" verwendet. In diesem VLAN besaßen der Switch und der RADIUS Server ihre IP Adressen. Darüber hinaus wurden VLAN 10 und VLAN 20 eingerichtet als Test VLANs für den Client. Die Einrichtung mit Netgear war etwas umständlich, weil die GUI teilweise unübersichtlich ist und gewöhnungsbedürftige Mechanismen zum Bearbeiten der Config hat. Die finale Switch-Config ist weiter unten zu sehen.

Damit der Switch sich mit dem RADIUS Server verbinden kann, muss er als Client in der clients.conf hinterlegt sein. Dort wird ein entsprechendes Secret festgelegt, welches im nächsten Schritt auf dem Switch hinterlegt werden muss.

Im Switch haben wir anschließend den RADIUS Server mit seinem Secret eingetragen. Leider bietet die Netgear GUI keinen Button, um die Verbindung zu testen. Da wir in einem Untermenü TODO vergessen haben, die Authentifizierungsmöglichkeit 802.1x allgemein zu aktivieren, blieben erste Verbindungsversuche mit einem Client am Switch erfolglos. Durch das starten von Freeradius im Debug Modus mit freeradius -X kann überprüft werden, ob die Daten vom Client am überhaupt am RADIUS Server ankommen. Nach dem tätigen der fehlenden Einstellung gelang eine erste Verbindung mit dem zuvor konfigurierten Username und "cleartext Password" mittels EAP-PWD. (Achtung unsicher!)

Auf dem Switch haben wir eingestellt, dass bei "Access-Accept" als Antwort VLAN10 und bei "Access-Reject", also standardmäßig, das VLAN 20 zugewiesen wird. Ein Test mit EAP-PWD war erfolgreich.

Um das Setup mobil zu gestalten, haben wir den RADIUS-Server auf einen Raspberry Pi migriert und ebenfalls die zwei Test VLANs 10 und 20 auf dem PI angelegt. So konnten wir mittels eines Pings überprüfen, ob der Client dem richtigen VLAN zugewiesen wurde und bei der Demo "beweisen", dass dies der Fall ist. Damit das ganze noch einfacher sichtbar wird, wurde ein DHCP-Server installiert, der unterschiedliche Adressen für VLAN 10 (192.168.10.0/24 und VLAN 20 192.168.20.0/24) vergibt.

Um eine Authentifizierung mit EAP-TLS zu demonstrieren, haben wir eine CA erstellt mit einem ROOT-, Server- und einem Client-Zertifikat. Dafür haben wir die im Verzeichnis certs liegenden openssl config templates von freeradius ausgefüllt und die Zertifikate mittels des Makefiles erstellen lassen. Das Makefile benutzt die entsprechenden openssl-Befehle mit der config als Parameter.

Das Client-Zertifikat inklusive private key haben wir im Anschluss auf den Test Laptop geladen und eine zertifikatsbasierte Authentifizierung unter Nutzung von EAP-TLS erfolgreich getestet. Dafür haben wir in der GUI des Clients die 802.1x Security für die drahtgebundene Verbindung aktiviert und das Client Zertifikat, inklusive private key und das ROOT CA Zertifikat, welches zur Überprüfung des Server Zertifikates benötigt wird, angegeben. Standardmäßig akzeptiert der freeradius RADIUS Server alle von der ROOT CA signierten Zertifikate. Die Verbindung gab erfolgreich ein "Access-Accept" zurück.

Um auch bei EAP-TLS in der RADIUS Antwort ein VLAN Tag mitzugeben haben wir die Datei mods-available/check-eap-tls bearbeitet.

update config {
   Access-Accept
}
update reply {
   Tunnel-Type = "VLAN",
   Tunnel-Medium-Type = "IEEE-802",
   Tunnel-Private-Group-Id = "10"
}

Step 2

Ziel in Step 2 ist die Erstellung eines private key im TPM 2.0 Chip, um mittels openssl einen zugehörigen CSR zu erstellen. Der TPM 2.0 Chip muss zunächst im BIOS aktiviert werden. Anschließend ist die Ausgabe von dmesg | grep -i tpm eine guter Indikator ob der TPM 2.0 Chip auch vom Betriebssystem erkannt wurde.

Für die Kommunikation mit dem TPM 2.0 Chip haben wir die tpm2-pksc11 Library verwendet. Da die Paketquellen der Library und der Abhängigkeiten je nach Betriebssystemversion unterschiedliche Versionen aufweisen, haben wir uns für eine Installation "from Source" entschieden. Ein Shell Skript mit unserer Installationsroutine sieht wie folgt aus:

#!/bin/bash 
### ATTENTION READ BEFORE STARTING THIS SCRIPT ###
### IF cffi version mismatch errors occures install python3-cffi WITH SYNAPTIC \(°~°)/ ###

set -euo pipefail

VERSION_LIMIT=4.12
CURRENT_VERSION=$(uname -r | cut -c1-3)
if (( $(echo "$CURRENT_VERSION > $VERSION_LIMIT" |bc -l) )); then
    echo "SUCCESS Kernel version: $CURRENT_VERSION > Version Limit: $VERSION_LIMIT "
else
    echo "FAILURE Kernel version: $CURRENT_VERSION < Version Limit: $VERSION_LIMIT "
    exit
fi

# in case one command has an error exit the script
sudo mkdir -p /etc/tpm2_pkcs11

sudo apt update -y
sudo apt upgrade -y
sudo apt install git -y
sudo apt install python3-pip -y 

# Install p11-kit from apt
sudo apt install p11-kit libp11-kit-dev -y 

# Install p11 tool from apt
sudo apt install gnutls-bin -y

# Install tpm2_pkcs11 from source
wget https://github.com/tpm2-software/tpm2-pkcs11/releases/download/1.8.0/tpm2-pkcs11-1.8.0.tar.gz
tar -xzf tpm2-pkcs11-1.8.0.tar.gz

# get prerequisites
sudo apt install -y automake autoconf make sqlite3 libsqlite3-dev libyaml-dev libglib2.0-dev uuid-dev pandoc python3-cffi 

# install tpm2-tss dependency
sudo apt -y install \
  autoconf-archive \
  libcmocka0 \
  libcmocka-dev \
  procps \
  iproute2 \
  build-essential \
  git \
  pkg-config \
  gcc \
  libtool \
  automake \
  libssl-dev \
  uthash-dev \
  autoconf \
  doxygen \
  libjson-c-dev \
  libini-config-dev \
  libcurl4-openssl-dev \
  libltdl-dev

# install python modules
pip install bcrypt cryptography pyyaml pyasn1 pyasn1_modules 


# install tpmp2-tss
wget https://github.com/tpm2-software/tpm2-tss/releases/download/3.2.0/tpm2-tss-3.2.0.tar.gz
tar -xzf tpm2-tss-3.2.0.tar.gz 

cd tpm2-tss-3.2.0
./configure
make -j$(nproc)
sudo make install
sudo udevadm control --reload-rules && sudo udevadm trigger
sudo ldconfig
cd ..

# install tpm2_pytss
pip install tpm2_pytss 

# install tpm2-tools
sudo apt install tpm2-tools -y
# install tpm2-abrmd
sudo apt install tpm2-abrmd -y 

# libengine-pkcs11-openssl needed for opennssl 3.0 communication with TPM 2.0 via wpa_supplicant
sudo apt install tpm2-openssl libengine-pkcs11-openssl -y

sudo apt install python3-stsci.distutils -y

cd tpm2-pkcs11-1.8.0
./configure
make
sudo make install

cd tools
pip install .
export PATH="/home/client/.local/bin:$PATH"
export PATH="$PWD:$PATH" 

cd ..
cd .. 

export PATH="$PWD:$PATH"

#export TPM2_PKCS11_STORE="/home/client/store"
export TPM2TOOLS_TCTI="device:/dev/tpmrm0"
export TPM2_PKCS11_TCTI="device:/dev/tpmrm0"

echo 'FINISHED SUCCESSFULLY'
echo 'FOR PERSISTENCE CHANGES ADD THE FOLLOWING TO YOU ENV IN BASHRC:'
echo 'export TPM2TOOLS_TCTI="device:/dev/tpmrm0"'
echo 'export TPM2_PKCS11_TCTI="device:/dev/tpmrm0"' 

echo 'ADD THE FOLLOWING CONFIG TO YOUR OPENNSL CONFIG AFTER STEP 2 IN /etc/ssl/openssl.cnf. IT IS IMPORTANT THAT THE CSR AND KEY ARE GENERATED BEFORE'
echo '[openssl_init]'
echo 'engines = engine_section'
echo 
echo '[engine_section]'
echo 'pkcs11 = pkcs11_section'
echo 
echo '[pkcs11_section]'
echo 'engine_id = pkcs11'
echo 'dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/libpkcs11.so'
echo 'MODULE_PATH = /usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so'
echo 'init = 0'

Dieses Skript kümmert sich um keinerlei Fehlererkennung oder Ähnliches und soll nur als Inspiration dienen. Es wird sehr wahrscheinlich nur auf dem von uns verwendetem Betriebssystem, Ubtuntu 22.04, funktionieren. Nachfolgend sind einige Webseiten/Blogeinträge verlinkt, die uns beim Troubleshooting während der Installation geholfen haben. ACHTUNG! Es ist äußert wichtig, dass bei der Installation von tpm2-tools p11-kit als installiert erkannt wird. Dies kann in den Installationslogs nachgelesen werden. Falls p11-kit nicht erkannt wurde, funktionieren die nachfolgenden Schritte nicht. Bei uns musste das Paket libp11-kit-dev nachinstalliert werden.

Für die Erstellung der CSR haben wir folgenden Code verwendet (Hinweis: da wir einige Probleme mit den Umgebungsvariablen hatten, haben wir bei sudo aufrufen -E zum beibehalten der user Umgebungsvariablen mitgegeben. Durch geschicktere Konfiguration kann dies vermieden werden. Zum Zugriff auf den TPM Chip werden standardmäßig root-Rechte benötigt, da auf Hardware Ressourcen zugegriffen wird.:

export TPM2TOOLS_TCTI="device:/dev/tpmrm0"
export TPM2_PKCS11_TCTI="device:/dev/tpmrm0" 

sudo -E tpm2_ptool init
sudo -E tpm2_ptool addtoken \
    --pid=1 \
    --sopin=sopin \
    --userpin=userpin \
    --label=label
sudo -E tpm2_ptool addkey \
    --algorithm=rsa2048 \
    --label=label \
    --userpin=userpin
sudo -E tpm2_ptool config \
    --key tcti \
    --value "device:/dev/tpmrm0" \
    --label label
TOKEN=`sudo -E p11tool --list-token-urls | grep "token=label"`
p11tool --login --list-all "${TOKEN}" --outfile p11tool.out
# Private key enthält die PKCS11 URI die später in der wpa_supplicant.conf angegeben werden muss
PRIVATE_KEY=`cat p11tool.out | grep private | awk '{ print $2 }'`

export GNUTLS_PIN=userpin
export GNUTLS_SO_PIN=sopin


SUBJ="/C=DE/ST=Berlin/L=Berlin/O=Rechnerbetriebsgruppe/OU=ProfessorIn/CN=Peter Meyer/emailAddress=peter.meyer@hu-berlin.example" 

yaml_rsa0=$(sudo -E tpm2_ptool export --label="label" --key-label="" --userpin="userpin")
auth_rsa0=$(echo "$yaml_rsa0" | grep "object-auth" | cut -d' ' -f2-)
# Hier muss noch -key angepasst werden, je nachdem welche Datei vom tpm2_ptool export ausgegeben wird
sudo openssl req -new -provider tpm2 -provider base -key 5.pem -passin "pass:$auth_rsa0" -subj "${SUBJ}" -out "$HOSTNAME".csr

Die durch diese Befehle erstellte CSR kann nun von der jeweiligen CA signiert werden.

Nützliche Links

https://github.com/tpm2-software/tpm2-pkcs11 von Source installiert, da dass Package aus den Packetmanager Quellen veraltet ist und für das Zusammenspiel mit openssl3 eine neuere Funktion benötigt wurde.

Folgende Artikel helfen bei allen möglichen Fehlern während der Installation:

Zusätzliche Dependency die benötigt wird: https://github.com/tpm2-software/tpm2-openssl

https://www.howtoinstall.me/ubuntu/18-04/libengine-pkcs11-openssl/

https://github.com/tpm2-software/tpm2-pkcs11/issues/766

https://stackoverflow.com/questions/43325110/exception-version-mismatchcffi

https://stackoverflow.com/questions/62154342/configure-error-package-requirements-sqlite3-3-7-4-were-not-met

https://askubuntu.com/questions/1403837/how-do-i-use-openssl-1-1-1-in-ubuntu-22-04

https://github.com/tpm2-software/tpm2-pkcs11/blob/master/docs/EAP-TLS.md

Die Zeilen für die Engine, die für Benutzung mit der wpa_supplicant benötigt werden dürfen bei Step 2 noch nicht in der config sein!

Step 3

Dann haben wir den generierten Client-CSR auf den Radius-Server geschickt, um es von unserer CA signieren zu lassen. Damit haben wir ein gültiges Zertifikat, welches wir zurück zum Client Laptop geschickt haben.

Um eine Authentisierung mit dem Radius-Server vorzunehmen brauchen wir eine wpa_supplicant.conf Datei, welche folgendermaßen aufgebaut sein muss:

#/etc/wpa_supplicant-wired-enx00e04c680106XXpZvOAl.conf

ctrl_interface=/run/wpa_supplicant
ap_scan=0
pkcs11_module_path=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
network={
        key_mgmt=IEEE8021X
        eap=TLS
        identity="client"
        ca_cert="/home/client/src/ca.pem"
        client_cert="/home/client/src/03.pem"
        private_key="pkcs11:model=NPCT75x%00%02%01%00%24rls%00;manufacturer=Nuvoton;serial=0000000000000000;token=label;id=%64%33%34%64%34%32%65%32%39%62%36%64%36%65%63%65;type=private;pin-value=userpin"
}

Hier wird unter private_key die PKCS11 URI aus Step 2 (Umgebungsvariable PRIVATE_KEY) angegeben. Es unterscheidet sich je nach Verwendung von WLAN oder wired, wir haben hier eine Konfiguration für wired verwendet.

wpa_supplicant benutzt openssl, um mit dem TPM kommunizieren zu können. Openssl benötigt dafür eine Engine. Wir haben libengine-pkcs11-openssl verwendet. Um OpenSSL mitzugeben welche PKCS11 Engine es benutzen soll habe wir folgende Änderungen in der OpenSSL.conf vorgenommen: /etc/ssl/openssl

[openssl_init]
engines = engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/libpkcs11.so
MODULE_PATH = /usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so
init = 0

Ergebnisse

Eine erfolgreiche Authentifizierung mit wpa_supplicant sieht wie folgt aus:

sudo -E wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant-wired-enx00e04c680106.conf -i enx00e04c680106 -D wired

Successfully initialized wpa_supplicant
enx00e04c680106: Associated with 01:80:c2:00:00:03
enx00e04c680106: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
enx00e04c680106: CTRL-EVENT-EAP-STARTED EAP authentication started
enx00e04c680106: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK
enx00e04c680106: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13
enx00e04c680106: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
enx00e04c680106: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=DE/ST=Berlin/L=Berlin/O=Rechnerbetriebsgruppe/emailAddress=admin@rbg.example/CN=Allm\xC3\x83\xC2\xA4chtige Rechnerbetriebgruppe ROOT'      hash=e058f4d62841026bda3814acaf39337fb2dc147456d6b45298d0472181b9f059
enx00e04c680106: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=DE/ST=Berlin/O=Rechnerbetriebsgruppe/CN=Allm\xC3\x83\xC2\xA4chtiger RADIUS/emailAddress=admin@rbg.example' hash=bf3be5e22ed92568dc215ada7a2e2babe8da4c9fb6fbf278f485669ad1161097 tod=2
enx00e04c680106: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
enx00e04c680106: CTRL-EVENT-CONNECTED - Connection to 01:80:c2:00:00:03 completed [id=0 id_str=]

Teilweise war es nötig den entsprechenden Ethernet Adapter (hier enx00e04c680106) vor der Ausführung von wpa_supplicant mit folgendem Befehl auf down zu setzen:

sudo ip link set enx00e04c680106 down

FreeRADIUS

RADIUS uses User Datagram Protocol (UDP) port 1812 for authentication and 1813 for accounting.

• radiusd.conf Defines the configuration parameters for the RADIUS server. It includes references to all of the other configuration files.

• clients.conf Defines information necessary to configure the RADIUS client, including IP addresses and shared secrets. This file is referenced from the radiusd.conf file.

• dictionary Defines local attributes for the RADIUS server. This file references the default dictionary files. The default dictionary files include thousands of attribute definitions for over one hundred vendors.

• proxy.conf Defines upstream home servers, including information on IP addresses and shared secrets. It also defines Realms. The radiusd.conf file references the proxy.conf file.

• sites-enabled/default This is the default virtual server. This file handles authentication and accounting requests. It contains a configuration designed to work with the largest number of authentication protocols. The radiusd.conf file references the sites-enable/default file.

• sites-enabled/inner-tunnel This virtual server handles authentication methods that are carried inside of a TLS tunnel, as part of PEAP or EAP-TTLS authentication. The radiusd.conf file references the sql.conf file.

• users The traditional RADIUS configuration file for users. This file format is similar to the format defined in 1993. The files file references the users file.

Folgende Attribute wurden aus unseren Zertifikaten geparsed und können z.B. als Unterscheidungsmerkmal für die Authentifizierung verwendet werden:

(7) eap_tls: TLS - Creating attributes from certificate OIDs
(7) eap_tls:   TLS-Cert-Serial := "1a61a1346f833e3fa509ce4aeb6a41039685a4ed"
(7) eap_tls:   TLS-Cert-Expiration := "221204131436Z"
(7) eap_tls:   TLS-Cert-Valid-Since := "221005131436Z"
(7) eap_tls:   TLS-Cert-Subject :=  "/C=DE/ST=Berlin/L=Berlin/O=Rechnerbetriebsgruppe/emailAddress=admin@rbg.example/CN=Allm\\xC3\\x83\\xC2\\xA4chtige Rechnerbetriebgruppe ROOT"
(7) eap_tls:   TLS-Cert-Issuer := "/C=DE/ST=Berlin/L=Berlin/O=Rechnerbetriebsgruppe/emailAddress=admin@rbg.example/CN=Allm\\xC3\\x83\\xC2\\xA4chtige Rechnerbetriebgruppe ROOT"
(7) eap_tls:   TLS-Cert-Common-Name := "AllmÃ¤chtige Rechnerbetriebgruppe ROOT"
(7) eap_tls: TLS - Creating attributes from certificate OIDs
(7) eap_tls:   TLS-Client-Cert-Serial := "03"
(7) eap_tls:   TLS-Client-Cert-Expiration := "231005204308Z"
(7) eap_tls:   TLS-Client-Cert-Valid-Since := "221005204308Z"
(7) eap_tls:   TLS-Client-Cert-Subject := "/C=FR/ST=Radius/O=Example  Inc./CN=testing/emailAddress=testing@test.com"
(7) eap_tls:   TLS-Client-Cert-Issuer :=  "/C=DE/ST=Berlin/L=Berlin/O=Rechnerbetriebsgruppe/emailAddress=admin@rbg.example/CN=Allm\\xC3\\x83\\xC2\\xA4chtige Rechnerbetriebgruppe ROOT"
(7) eap_tls:   TLS-Client-Cert-Common-Name := "testing"
(7) eap_tls:   TLS-Client-Cert-X509v3-Extended-Key-Usage += "TLS Web Client Authentication"
(7) eap_tls:   TLS-Client-Cert-X509v3-Extended-Key-Usage-OID += "1.3.6.1.5.5.7.3.2"

Switch Config

SYSTEM CONFIG FILE ::= BEGIN
! System Description: S350 Series 8-Port Gigabit Ethernet Smart Managed Pro Switch
! Firmware Version: 1.0.0.12 [Oct 03 2019 - 14:09:32]
! Loader Version: 1.0.0.1 [2018-05-18 10:58:12 UTC]
! System Name: 
! MAC Address: 44:A5:6E:57:D5:21
! Serial Number: 5GK3065NA0A89
! System Up Time: 0 days, 23 hours, 25 mins, 52 secs
!
ip address 192.168.50.51 mask 255.255.255.0
ip default-gateway 192.168.50.1
!
username "admin" secret encrypted +cx2Q0pSvEdQa+lYePLJiw==
!
!
vlan 2
name "Auto-VoIP"
vlan 10
 name "Test 1"
vlan 20
 name "Test 2"
vlan 50
 name "Management"
vlan 4089
 name "Auto-Video"
management-vlan vlan 50
!
spanning-tree mst configuration
 name "44-A5-6E-57-D5-21"
!
snmp user "admin" "AUTH" auth md5 encrypted +cx2Q0pSvEdQa+lYePLJiw== 
!
radius host 192.168.50.252 auth-port 1812 key uPIcRDkhpjhJoz0kHeLGZg== priority 0   type all msg-authen off
!
authentication dot1x
authentication vlan-assign
authentication method radius
!
logging buffered severity 7
logging file
!
!
interface g1
 switchport hybrid allowed vlan add 10,20,50 tagged
 authentication port-control force-auth
!
interface g2
!
interface g3
 switchport hybrid pvid 10
 switchport hybrid allowed vlan add 10 untagged
!
interface g4
 switchport hybrid pvid 10
 switchport hybrid allowed vlan add 10 untagged
 switchport hybrid allowed vlan remove 1
 authentication unauth-vlan 20
!
interface g5
 authentication unauth-vlan 20
!
interface g6
!
interface g7 
 switchport hybrid pvid 50
 switchport hybrid allowed vlan add 10,20 tagged
 switchport hybrid allowed vlan add 50 untagged
 switchport hybrid allowed vlan remove 1
 authentication port-control force-auth
!
interface g8
 switchport hybrid pvid 50
 switchport hybrid allowed vlan add 50 untagged
 switchport hybrid allowed vlan remove 1
 authentication port-control force-auth
!

Einsatz bei der Rechnerbetriebsgruppe

Im folgenden Abschnitt sollen noch einmal verschiedene Möglichkeiten einer Authentifizierung mittels 802.1x aufgelistet werden und Packetfence als OpenSource NAC vorgestellt werden. Packetfence basiert auf FreeRADIUS und bietet verschiedenste Integrations Möglichkeiten, unter anderem Authentifizierungsquellen wie OpenLDAP, Active Directory, Email, Facebook und Google an. Die graphische Oberfläche bietet die Option Live Logs anzusehen, wertet RADIUS Anfragen mit Diagrammen aus und bereitet die RADIUS Accounting Informationen auf.

Switche konfigurieren

Bei der Konfiguration der Switchports gibt es verschiedene Möglichkeiten, je nach gewünschtem verhalten. Auf unserem Testswitch konnten folgende Dinge eingestellt werden:

Eine Authentifizierung kann für jeden Port einzeln aktiviert werden
Zuweisung eines VLAN Tags je nach Authentifizierungs status (ACCESS-Accept oder ACCESS-Reject)
Dynamische Zuweisung eines VLANs durch RADIUS Attribute, durch die Option VLAN creation mode können auch VLANs assigned werden die bis dato noch nicht auf dem Switch angelegt wurden
Erneute Authentifizierung nach einer gewissen Zeit fordern
Einstellen einer Quiet Period: Nach einer fehlgeschlagenen Authentifizierung kann sich für die festgelegte Zeit nicht am Port authentifiziert werden (Schutz vor Brute Force / DoS)
MAC based mode: hier können sich mehrere supplicants über denselben Switchport authentifizieren. Jeder supplicant muss sich dabei einzeln authentifizieren um Netzwerkzugriff zu erhalten. Als Unterscheidungsmerkmal zwischen den Clients dient die MAC Adresse
Guest VLAN ID: wird vergeben für Clients die kein 802.1x konfiguriert haben (Authentifizierung timed out)
Unauthenticated VLAN ID: wird vergeben für Clients für die ein Access-Reject vom RADIUS Server zurückgegeben wurde

Packetfence Installation & Hardware Requirements

Packetfence kann mittels einer ISO Datei oder auf einem bestehenden Linux (Debian 11.x Bullseye) installiert werden. Die Hardware Empfehlungen sind:

Intel or AMD CPU 3GHz, 4 CPU Cores
16 GB of RAM
200 GB of disk space (RAID-1 recommended)
2 Network Cards

Es sollten möglichst zwei redundante RADIUS Server existieren die auf den Switches hinterlegt werden. Dadurch kann beim Ausfall des primären Servers auf den sekundären zurückgegriffen werden.

LDAP anbinden

Falls keine passende PKI zum Einsatz kommen soll kann auch eine Authentifizierung mit Nutzernamen und Passwort mittels EAP-TTLS passieren. Hierbei Authentifiziert sich lediglich der Server gegenüber dem Client mit einem Zertifikat, für den Aufbau der TLS Verbindung. Durch den TLS Tunnel wird werden dann Nutzername und Password übertragen. Als Authentifizierungquelle kann in Packetfence ein OpenLDAP Server hinterlegt werden. Die komplette Anleitung zur Einrichtung ist hier zu finden.

Authentifizierung mit Eduroam

Ein mögliches Szenario könnte der Kabelgebundene Netzwerkzugriff für Studenten oder Lehrpersonal sein. Dafür kann Packetfence als Authentifizierungsmethode eduroam benutzen. Unter dem Menüpunkt Configuration → Policies and Access Control → Authentication Sources -> New exclusive source -> Eduroam kann die entsprechende Konfiguration vorgenommen werden. Der genaue Weg ist hier beschrieben.

Packetfence Installationguide