OpenVPN, authentification radius + client authentification 2 étapes

fab_d

Bonjour à toutes à et tous,

Je suis le petit nouveau du forum et je suis à la quête de réponses dans ma croisade :p

Je vous explique ma problématique qui je l'espère pourra être résolue.

Il m'a été demandé de mettre en place un openVPN avec authentification via (AD) où l'on externaliserait un maximum en dehors du Pfsense l'ensemble des configurations.

J'ai tout de même quelques contraintes:

on n'utilise pas le CA de l'active directory (raison sécurité logique..)
une authentification en 2 étapes côté user (login/pwd + certif)

mais où est donc ma problématique dans tout cela ?

Bien j'arrive à connecter le radius et à générer un CA sur Pfsense. Mais lorsque je lis les tutos de Pfsense, je vois que l'on crée à chaque utilisateur un certificat directement sur le Pfsense :-/ (ça ne convient pas à ma problématique d'externalisation)

Par hasard, quelqu'un aurait-il une méthode à me proposer ?

Je vous remercie de l'aide que vous pourrez m'apporter !

un jeune padawan ;D

ps: si je viens vers vous c'est que j'ai parcouru l'ensemble des tutoriels qu'il existe sur internet.

chris4916

@fab_d:

ps: si je viens vers vous c'est que j'ai parcouru l'ensemble des tutoriels qu'il existe sur internet.

Prétentieux ;D ;D ;D (joke)

Au delà de la plaisanterie :
1 - je ne vois pas ou est le problème avec AD… enfin, si j'en vois plein mais pas en terme de sécurité avec le certificat, ou en tous cas pas plus qu'avec n'importe quel autre certificat
2 - tu veux atteindre 2 objectifs qui me paraissent antinomiques: ne pas gérer une nouvelle base de comptes et ne pas utiliser (pleinement) celle que tu as déjà ???

Je suis tout à fait d'accord en revanche que gérer sur pfSense les utilisateurs que tu as par ailleurs dans AD n'a pas beaucoup de sens.

As-tu exploré une piste qui consisterait à déployer une PKI qui se baserait sur le LDAP de AD comme base de compte pour gérer par ailleurs des certificats. Je ne vois pas trop en quoi ce serait plus sécurisé que les certificats de AD mais comme je ne comprends pas quel est le problème bien que tu écrives

on n'utilise pas le CA de l'active directory (raison sécurité logique..)

un lien que tu as bien sûr déjà parcouru puisqu'il fait parti de l'ensemble des tutoriels d'internet :P

fab_d

Mais euhhh bon aller d'accord un poil prétentieux ;D

Je te remercie tout d'abord du temps que tu m'accordes.

Pour t'éclaircir sur la situation, je suis étudiant en IT (je découvre encore bcp de domaines dont les certificats et les VPNs :p). Mais je tente un maximum de faire mon éducation de padawan ! :-)

Lorsque j'écrivais dans mon topic précédent qu'il m'était demandé de ne pas employer le CA de l'AD, car le prof. estime qu'il doit rester offline et ne doit pas être utilisé pour des procédures telles que celle-ci. Il m'a indiqué que c'était pour une "raison de sécurité".

Maintenant, je savais avant de venir ici qu'on pouvait générer un CA dans Pfsense(grâce au tuto que tu cites), mais aussi en importer un dont celui de l'AD (d'où le fait que le prof. interdit son utilisation)..

On va dire que la question 1 était "useless", mais je ne visualise pas trop l'avantage d'en générer un ou d'utiliser celui de l'AD :-/

ma seconde question était mal pensée. J'aurais dû formuler ma question comme suite:
N'existe-t-il pas une méthode permettant d'employer l'authentification à 2 facteurs, sans pour autant devoir générer un certificat pour chaque utilisateur directement sur le Pfsense. (Il m'a été demandé d'externaliser au maximum la configuration en dehors du Pfsense, maintenant je présume que tout n'est pas forcément externalisable).

Pour ce qui est d'explorer la solution du PKI, je suis en train d'y regarder. Enfin d'abord, de comprendre comment ça fonctionne avant de tenter de m'en servir :D (préférable de savoir marché avant de courir héhé ! )

En te remerciant pour l'aide que tu m'apporteras ainsi que ta patience face au jeune padawan

chris4916

si le but est de faire "2FA", il faut bien un facteur supplémentaire en plus du login et du pwd.
Ne pas utiliser un certificat propre à l'utilisateur me semble surprenant. Si c'est, par exemple, un certificat partagé par plusieurs utilisateurs, ça a peu de sens, bien qu'on puisse imaginer, par exemple, que ce soit un certificat partagé.
Faisable d'un point de vue théorique mais ingérable dans la vraie vie.

par exemple si le laptop sur lequel est installé ce certificat est volé, tu va révoquer le certificat en question et si c'est le même partout…. du es bon pour redéployer le nouveau certif sur tous les postes. Bref, ça ne marche pas :-(

Et dès lors que tu va vouloir gérer un certificat par utilisateur, tu vas entrer, d'une manière ou d'une autre dans le monde de la PKI.

Mais il y a d'autres moyens de faire du 2FA. je ne sais pas si ça rentre dans le cadre de ton étude mais il y a des token, de la biométrie, ou, et c'est très courant dans le monde Radius, OTP (one time password) avec différentes méthode de génération du mot de passe (par exemple RSA SecurID)
Si ton étude n'est que théorique, c'est définitivement une bonne solution ;-)

chris4916

En écho à ton PM, je colle ici ma réponse qui peut servir à d'autre ou être une base de discussion publique.

C'est fou le nombre d'étudiants qui ont un projet "pfSense" :-) ça va faire de l'ombre aux sociétés de service :-X

Désolé, la suite est longue 8)

Je connais assez peu pfSense que j'utilise depuis peu. Il faut donc prendre ma réponse avec des pincettes pour ce qui est de cet aspect.
En revanche, l'IAM est mon métier :-)

Je ne comprends pas bien si le résultat de ton projet est une étude théorique ou une mise en œuvre pratique mais, dans tous les cas, je considère que gérer des comptes (utilisateurs) sur la machine qui fait office de firewall est un non sens d'un point de vue sécurité. Ce peut être en revanche un bon compromis dans un petit environnement (PME) qui va privilégier l'aspect "all-in-one" et simplicité d'administration mais compromis veut dire également concessions. Bref….

Ce qu'il faut bien comprendre, d'une manière générale, c'est que le serveur VPN est configuré pour s'appuyer sur un service d'authentification "à définir", lequel peut être le serveur pfSense lui même, LDAP ou Radius (et pas nécessairement un package Radius sur pfSense)

Un autre paramètre de OpenVPN, potentiellement indépendant de la base de compte utilisée pour l'authentification, c'est l'aspect "cryptographique" de la connexion, lequel va s'appuyer sur un certificat coté utilisateur qui va être validé (ou pas) par le serveur VPN car celui-ci embarque, dans ce cas, son propre certificat. A ce moment, c'est du strict X509: si les certificats client et serveur sont issu d'un CA commun ou si il y a une cross-certification (qui correspond grosso-modo au trust du monde Microsoft), alors le certificat présenté par le client est validé.

Si au niveau du serveur VPN tu actives la fonction de matching de l'utilisateur, le serveur VPN va en plus s'assurer que le CN du certificat présenté correspond au login de l'utilisateur.

De la section ci-dessus découle 2 points importants:

1 - si tu veux gérer des PKI différentes pour différents type d'utilisateurs (par exemple des utilisateur permanents et des utilisateurs temporaires) alors il faut soit 2 serveurs VPN différents présentant chacun son propre certificat soit mettre en œuvre au niveau des CA de ces 2 PKI une cross-certification pour que le certificat serveur (VPN) unique valide (et soit validé dans un double hand-check X509) par des certificats utilisateurs issus de PKI distinctes.

2 - l'indépendance entre l'authentification utilisateur et le certificat présenté est toute relative si le serveur VPN force le matching ;D ;D

Qu'est-ce que ça signifie dans la pratique ?

Tu évoques dans ton PM une idée genre "génération de certificat par script" pour une catégorie de la population. S'agissant d'un certificat utilisateur, ça me laisse perplexe ??? la difficulté n'est pas là de générer le certificat mais de le transmettre de manière sécurisée à l'utilisateur avec tout ce que ça implique en terme de process et de vérification.

Dans l'absolu, cette simple partie est un projet à part entière.

En effet, il s'agit de mettre en œuvre l'infrastructure qui va permettre, à un utilisateur authentifié (et ce point est potentiellement critique) de générer, depuis son poste de travail, un CSR qui sera ensuite envoyé au serveur pour signature et donc génération du certificat. C'est un peu plus qu'un simple script mais une application à part entière, avec quelques aspects tricky. Ne pas oublier que dès lors qu'il y a des certificats qui se promènent dans la nature, il faut gérer une CRL (révocations !)

Tu trouveras sur le web quelques applications qui vont dans ce sens mais compte tenu de l'impact de ce genre de fonctionnalité, je pense qu'il est toujours souhaitable de se poser la question de "développement maison" vs. "application externe" vs. "PKI qui embarque cette fonctionnalité".

Pour répondre à ta question sur le "bypass du CA de pfSense":
1 - ça montre que en parcourant tous les tutos du web, tu as sauté quelques lignes (et tu as du mal lire la doc pfSense également :p)
2 - il suffit d'importer un certificat (dans la section CA de pfSense) signer par une CA externe et de l'utiliser au niveau de ton serveur VPN

Et voila, la partie théorique de ton étude est finie, ou presque 8)
Ou en tous cas, voila les grandes lignes, il te faut ensuite travailler sur les détails (par exemple apprendre un peu de X509 pour ne pas que ma description soit juste un truc creux ou incompréhensible)