Absicherung NFS - Revision history

Wolfm: /* Step 3 */

2022-11-08T13:59:32Z

Step 3

← Older revision		Revision as of 13:59, 8 November 2022
Line 275:		Line 275:
	=== Step 3 ===		=== Step 3 ===

	Dann haben wir ~~das~~ ~~generierte~~ Client CSR auf den Radius Server geschickt, um es von unserer CA signieren zu lassen.		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.		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:		Um eine Authentisierung mit dem Radius-Server vorzunehmen brauchen wir eine <code>wpa_supplicant.conf</code> Datei, welche folgendermaßen aufgebaut sein muss:

	#/etc/wpa_supplicant-wired-enx00e04c680106XXpZvOAl.conf		#/etc/wpa_supplicant-wired-enx00e04c680106XXpZvOAl.conf

Wolfm: /* Step 2 */

2022-11-08T13:56:51Z

Step 2

← Older revision		Revision as of 13:56, 8 November 2022
Line 210:		Line 210:
	echo 'init = 0'		echo 'init = 0'

	~~Diese~~ 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.		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 ~~das~~ 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 <code>libp11-kit-dev</code> nachinstalliert werden.		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 <code>libp11-kit-dev</code> 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.):		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 TPM2TOOLS_TCTI="device:/dev/tpmrm0"

Wolfm: /* Step 2 */

2022-11-08T13:52:05Z

Step 2

← Older revision		Revision as of 13:52, 8 November 2022
Line 81:		Line 81:
	=== Step 2 ===		=== Step 2 ===

	Ziel in Step 2 ist die Erstellung eines private key im TPM 2.0 Chip um mittels openssl ~~eine~~ ~~zugehörige~~ CSR zu erstellen. Der TPM 2.0 Chip muss zunächst im BIOS aktiviert werden. Anschließend ist die Ausgabe von <code>dmesg \| grep -i tpm </code> eine guter Indikator ob der TPM 2.0 Chip auch vom Betriebssystem erkannt wurde.		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 <code>dmesg \| grep -i tpm </code> 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 [https://github.com/tpm2-software/tpm2-pkcs11 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:		Für die Kommunikation mit dem TPM 2.0 Chip haben wir die [https://github.com/tpm2-software/tpm2-pkcs11 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:

Wolfm: /* Step 1 */

2022-11-08T13:50:47Z

Step 1

← Older revision		Revision as of 13:50, 8 November 2022
Line 55:		Line 55:
	*# hierfür muss ein Client in der config Datei <code>clients.conf</code>, mit dem entsprechenden RADIUS Secret und Hostname/IP, angelegt werden. Außerdem muss ein Benutzer angelegt werden in der <code>users.conf</code> mit {username} und {password}.		*# hierfür muss ein Client in der config Datei <code>clients.conf</code>, mit dem entsprechenden RADIUS Secret und Hostname/IP, angelegt werden. Außerdem muss ein Benutzer angelegt werden in der <code>users.conf</code> 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.		* 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 <code>clients.conf</code> hinterlegt sein. Dort wird ~~eine~~ entsprechendes Secret festgelegt welches im nächsten Schritt auf dem Switch hinterlegt werden muss.		* Damit der Switch sich mit dem RADIUS Server verbinden kann, muss er als Client in der <code>clients.conf</code> 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 <code>freeradius -X</code> 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!)		* 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 <code>freeradius -X</code> 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.		* 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 ~~ist~~ wurde ein DHCP Server installiert, der Adressen für VLAN 10 (192.168.10.0/24 und VLAN 20 (192.168.20.0/24) vergibt.		* 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 <code>certs</code> 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.		* 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 <code>certs</code> 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.		* 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 <code>mods-available/check-eap-tls</code> bearbeitet.		* Um auch bei EAP-TLS in der RADIUS Antwort ein VLAN Tag mitzugeben haben wir die Datei <code>mods-available/check-eap-tls</code> bearbeitet.

Wolfm: /* Plan */

2022-11-08T13:40:52Z

Plan

← Older revision		Revision as of 13:40, 8 November 2022
Line 42:		Line 42:
	Step 1: Authentifizierung mit 802.1x. 1x Switch, 1x Client und 1x RADIUS Server		Step 1: Authentifizierung mit 802.1x. 1x Switch, 1x Client und 1x RADIUS Server

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

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

	=== Step 1 ===		=== Step 1 ===

Wolfm: /* EAP */

2022-11-08T13:37:31Z

EAP

← Older revision		Revision as of 13:37, 8 November 2022
Line 23:		Line 23:
	*# Der RADIUS Server schickt ein EAP-TLS/Start Paket an den Supplicant		*# Der RADIUS Server schickt ein EAP-TLS/Start Paket an den Supplicant
	*# Supplicant antwortet mit EAP/Reponse Paket und EAP-Type=EAP-TLS, TLS Records: client-hello, opt. cipher-spec ansonsten TLS_NULL_WITH_NULL_NULL		*# Supplicant antwortet mit EAP/Reponse Paket und EAP-Type=EAP-TLS, TLS Records: client-hello, opt. cipher-spec ansonsten TLS_NULL_WITH_NULL_NULL
	*# RADIUS Server antwortet mit EAP/Request und EAP-Type=EAP-TLS, TLS Records: server-hello und ~~weiter~~ TLS Records		*# RADIUS Server antwortet mit EAP/Request und EAP-Type=EAP-TLS, TLS Records: server-hello und weitere TLS Records
	*# Der TLS Handshake erfolgt durch EAP/Request und EAP/Response Pakete bei denen die Nutzdaten die TLS Records enthalten		*# Der TLS Handshake erfolgt durch EAP/Request und EAP/Response Pakete bei denen die Nutzdaten die TLS Records enthalten
	*# Nach Empfang des TLS finished records verschickt der Supplicant eine ~~weiter~~ EAP/Response EAP-Type=EAP-TLS Nachricht		*# Nach Empfang des TLS finished records verschickt der Supplicant eine weitere EAP/Response EAP-Type=EAP-TLS Nachricht
	*# RADIUS Antwortet mit EAP-Success		*# RADIUS Antwortet mit EAP-Success

Haussknl: /* Einsatz bei der Rechnerbetriebsgruppe */

2022-10-26T06:05:30Z

Einsatz bei der Rechnerbetriebsgruppe

← Older revision		Revision as of 06:05, 26 October 2022
Line 464:		Line 464:

	Im folgenden Abschnitt sollen noch einmal verschiedene Möglichkeiten einer Authentifizierung mittels 802.1x aufgelistet werden und Packetfence als OpenSource NAC vorgestellt werden.		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 ~~über~~ Live Logs ~~hinaus~~ ~~schöne~~ ~~Grafiken~~ ~~zur~~ ~~Auswertung~~ ~~der~~ RADIUS ~~anfragen~~.		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 ===		=== Switche konfigurieren ===
	Bei der Konfiguration der ~~Switchport~~ gibt es verschiedene Möglichkeiten, je nach gewünschtem verhalten. Auf unserem Testswitch konnten folgende Dinge eingestellt werden:		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		* Eine Authentifizierung kann für jeden Port einzeln aktiviert werden

Haussknl: /* Switche konfigurieren */

2022-10-26T06:00:00Z

Switche konfigurieren

← Older revision		Revision as of 06:00, 26 October 2022
Line 469:		Line 469:
	Bei der Konfiguration der Switchport gibt es verschiedene Möglichkeiten, je nach gewünschtem verhalten. Auf unserem Testswitch konnten folgende Dinge eingestellt werden:		Bei der Konfiguration der Switchport 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)		* 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		* 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
Line 474:		Line 475:
	* 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)		* 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		* 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 Installation & Hardware Requirements ===

Haussknl: /* Switche konfigurieren */

2022-10-26T05:49:50Z

Switche konfigurieren

← Older revision		Revision as of 05:49, 26 October 2022
Line 472:		Line 472:
	* 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		* 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		* 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
	*		*

Haussknl: /* Switche konfigurieren */

2022-10-26T05:38:42Z

Switche konfigurieren

← Older revision		Revision as of 05:38, 26 October 2022
Line 467:		Line 467:

	=== Switche konfigurieren ===		=== Switche konfigurieren ===
	Bei der Konfiguration der Switchport gibt es verschiedene Möglichkeiten, je nach gewünschtem verhalten.		Bei der Konfiguration der Switchport gibt es verschiedene Möglichkeiten, je nach gewünschtem verhalten. Auf unserem Testswitch konnten folgende Dinge eingestellt 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
	*		*