Strongwan deaktiviert den Benutzerzugriff

Strongwan deaktiviert den Benutzerzugriff

Wie kann ich mit der Strongswan-Public-Key-Authentifizierung den Zugriff für einen bestimmten Benutzer deaktivieren?

Ich habe also eine funktionierende Pub-Key-Authentifizierung. Der SAN ist die E-Mail und die ID. Gibt es eine Möglichkeit, die Authentifizierung für eine bestimmte Benutzer-ID (RightID) abzulehnen? Ich möchte den Benutzerzugriff einfach ein- und ausschalten können, was ich mit PSK-Authentifizierung tun könnte, indem ich einfach Einträge in der Secrets-Datei entferne. Ich hoffe, dass es eine Möglichkeit gibt, dies mit Zertifikaten zu tun. Ich würde ein Zertifikat mit dem Grund „Halten“ widerrufen, aber die PKI von Strongswan unterstützt die Möglichkeit zum Widerrufen nicht. Ich habe auch versucht, eine Falle einzurichten, um die Authentifizierung abzulehnen, aber ohne Erfolg. Es muss die Möglichkeit geben, anzugeben, welche Client-IDs eine Verbindung herstellen dürfen.

conn main
       leftauth=pubkey
       leftcert=servercert.pem
       rightauth=pubkey
       leftid=mydomain.com
       type=tunnel 
       left=%any 
       leftsubnet=0.0.0.0/0 
       right=%any
       rightsubnet=192.168.137.0/24
       esp=aes128gcm16-sha256-modp3072
       ike=aes128gcm16-sha256-modp3072
       keyexchange=ikev2
       ikelifetime=28800s #Time before re authentication of keys
       auto=add

conn close
       also=main
       [email protected]
       rightauth=never
       auto=route

Antwort1

Während es derzeit kein Plugin gibt, um einzelne Identitäten (oder Zertifikate/Schlüssel) auf die schwarze Liste zu setzen,WhitelistPluginbietet eine Möglichkeit, alle zulässigen Identitäten auf eine Whitelist zu setzen. Es verfügt über einen Befehl zum Verwalten der Whitelist, während der IKE-Daemon ausgeführt wird.

Etwas Ähnliches auf dynamischere Weise zu tun (z.B. alle Identitäten abzulehnen, die einem bestimmten Muster entsprechen) ist möglich über dasExt-AuthentifizierungPlugin. Das konfigurierte Skript (oder der Befehl) wird nach einer erfolgreichen Client-Authentifizierung aufgerufen und erhält die Client-Identität in der IKE_REMOTE_IDUmgebungsvariable. Wenn der Befehl mit etwas anderem als beendet wird 0, wird der Client abgelehnt.


Technisch gesehen ist die richtige Methode zum Blockieren von Client-Zertifikaten die Verwendung von CRL oder OCSP. Beachten Sie, dass der Grund „Hold“ ( --reason certificate-holdmit pki --signcrl) hauptsächlich dann relevant ist, wenn Sie Delta-CRLs verwenden, da solche Sperrungen in einer Delta-CRL über den Grund „removeFromCRL“ (den strongSwan derzeit überhaupt nicht unterstützt) rückgängig gemacht werden können. Aber wie Sie bereits erwähnt haben, pkiunterstützt der Befehl derzeit auch nicht das Weglassen (d. h. Rückgängigmachen) einiger Sperrungen, wenn die --lastcrlOption zum Erstellen einer neuen vollständigen CRL auf Grundlage einer alten verwendet wird.

Und obwohl Sie eine neue CRL von Grund auf neu erstellen könnten, die alle derzeit widerrufenen Zertifikate enthält, besteht das Problem darin, dass es derzeit nicht möglich ist, die Seriennummer ( cRLNumber) der ausgestellten CRL manuell anzugeben. Sofern nicht --lastcrl(oder --basecrl) verwendet wird, ist sie immer 1. Und mit derselben (oder einer niedrigeren) Seriennummer wird die CRL beim erneuten Laden nicht ersetzt (es sei denn, Sie löschen alle Anmeldeinformationen und Caches vollständig, bevor Sie sie laden, was nur mit swanctleiner ziemlich drastischen Maßnahme möglich ist - wie z. B. ein Neustart des IKE-Daemons, nur um die CRL neu zu laden).

Die Verwendung von OCSP könnte eine Option sein, da openssl ocspSie damit beispielsweise eine einfache Indexdatei bereitstellen könnten, die Sie manuell erstellen und ändern können (siehe beispielsweisemeine Antwort hierfür eine Beschreibung des Formats). Neben der Notwendigkeit, diesen zusätzlichen Dienst auszuführen, besteht ein möglicher Nachteil darin, dass OpenSSL erfordert, dass der Index auch alle aktuell gültigen Zertifikate enthält.

verwandte Informationen