J'ai un serveur OpenVPN qui utilise des certificats et une authentification LDAP.
Le problème est qu'un utilisateur peut partager son certificat et que d'autres utilisateurs LDAP valides peuvent utiliser ce certificat.
Question
Comment puis-je m'assurer que le certificat de Bob ne peut être utilisé qu'avec l'utilisateur LDAP "bob"?
Selon ce post , common_namene peut pas être truqué par l'utilisateur.
Ajoutez ceci à openvpn server.conf
script-security 2
# untrusted state
auth-user-pass-verify /etc/openvpn/scripts/check_cn_on_connect.sh via-env
/etc/openvpn/scripts/check_cn_on_connect.sh contient
#!/bin/bash
# username and common_name must be the same to allow access.
# users are not allowed to share their cert
if [ $username != $common_name ]; then
echo "$(date +%Y%m%d-%H%M%S) DENIED username=$username cert=$common_name" >> /var/log/openvpn-access.log
exit 1
fi
echo "$(date +%Y%m%d-%H%M%S) GRANTED username=$username cert=$common_name" >> /var/log/openvpn-access.log
exit 0
Mise à jour
C'est pour OpenVPN 2.1.4. Dans la version 2.2.0, ils ont ajouté de nombreuses nouvelles variables que vous pouvez voir env >> /tmp/env, où l'une de ces nouvelles variables est l'empreinte digitale / le numéro de série du certificat.
Il existe de nombreuses options, car OpenVPN est un projet open source, et il a la possibilité d'écrire votre propre crochet d'authentification. Il y a beaucoup de gens qui ont fait beaucoup de choses différentes pour fournir différents niveaux d'authentification.
Je n'ai pas essayé la plupart de ces derniers juste les voir mentionnés dans les docs / blogs / maillists. Certains d'entre eux peuvent nécessiter des correctifs ou la version non gratuite.
Une méthode principale consistera à rendre la partie privée de votre paire de clés extrêmement difficile à extraire / copier.
Si la protection de leur clé est coûteuse, n'est pas prise en charge sur vos plates-formes clientes ou n'est pas possible pour une autre raison, il vous reste quelques options.
Réglez beaucoup de journalisation sur votre serveur, pour surveiller les anomalies. Si Bob ne se connecte normalement qu'à partir de sa maison, puis un jour, il commence à se connecter depuis Acme Inc., vous devrez peut-être enquêter.
Configurez l'authentification multifacteur. Votre certificat compte comme «quelque chose que vous avez». Vous devriez donc chercher des alternatives dans «quelque chose que vous êtes» ou «quelque chose que vous savez». Cela inclut les métriques biologiques ou les mots de passe / phrases de passe.
auth-user-pass-verifyoption. Cette option transmet le nom d'utilisateur et le mot de passe fournis à un script / programme externe qui prendra la décision d'authentification en fonction de ce que vous voulez.
auth-user-pass-verify /etc/openvpn/scripts/connect.sh via-envpour obtenir le nom d'utilisateur de l'utilisateur. Savez-vous si je peux également obtenir l'ID du certificat que l'utilisateur utilise? Si c'est le cas, je peux écrire un script Perl qui vérifie un fichier yaml avec des ID de cert connus.Je ne suis pas un pro de la sécurité, je suis strict en matière de sécurité. Votre question atteint précisément le cœur de la sécurité informatique: la confiance. Comme je le vois, il ne faut jamais supposer que Bob peut faire confiance. Bien sûr, Bob pourrait être un gars vraiment gentil et digne de confiance. Il travaille dans votre entreprise depuis plus de 20 ans. Cependant, la personne «Bob» est totalement hors de propos dans votre infrastructure informatique.
Bob utilise des «relais» arbitraires qui permettent l'accès. Les relais peuvent être n'importe quoi: un mot de passe, un certificat, un jeton matériel, un balayage d'iris, un ADN. Ce sont des clés qui permettent d'accéder à votre système. Si votre question concerne la vérification de l'identité de la personne qui utilise une clé, la seule réponse honnête est probablement que vous devrez être dans la même pièce. Dans tous les autres cas, je pense que vous ne devez pas vous assurer que Bob est vraiment Bob et qu'il n'est pas actuellement détenu à bout portant alors qu'il y a accès. Donc, dans votre plan de conception d'infrastructure informatique, la chose logique n'est pas de faire référence à "Bob": une entité a accédé à votre site.
Parce que vous ne pouvez vraiment savoir qu'une «entité» a obtenu l'accès avec une clé que vous avez évanouie dans le passé, la bonne perspective est probablement de limiter le nombre de portes que la clé peut ouvrir. Plus vous sortez de clés, moins elles ouvrent de portes.
OpenVPN a également une option pour autoriser une seule connexion simultanée par clé. Ensuite, si Alice se connecte avec la clé de Bob alors que Bob est déjà à l'intérieur, Alice se voit refuser l'accès. Malheureusement, cela signifie également que Bob ne peut pas se connecter lorsque Alice est connectée avec la clé de Bob. Vous devez donc configurer votre système pour vous informer des tentatives de connexion simultanées à partir de plusieurs IP source. Et lancez les deux en cas de violation, Bob devra donc appeler pour obtenir de l'aide.
Le point est: ne vous assurez pas de choses dont vous ne pouvez pas être sûr et gardez cela à l'esprit lors de la conception de votre plan de sécurité. Supposons qu'il y ait toujours une personne plus intelligente, loin devant vous, qui ne peut pas attendre pour vous prouver le contraire ... juste "pour le lulz". :-)
la source