VPN

Utilisation des certificats

La réutilisation d’un certificat pour plusieurs clients empêche d’identifier celui qui l’utilise, augmente l’exposition du certificat, et en cas de compromission de celui-ci, la révocation/réémission du certificat impacte plusieurs clients.
Il est recommandé d’utiliser des certificats uniques et individuels par machine pour une meilleure traçabilité et permettre la révocation sans effets de bords en cas de besoin.
La signature de certificats numériques générés à partir de clés privées jugées obsolètes (ex: RSA 1024) est déprécié pour des raisons de sécurité. Il faut donc empêcher l’utilisation de ces certificats.

Algorithmes de chiffrement et d’authentification

De nouvelles vulnérabilités sur les protocoles et algorithmes sont régulièrement découvertes, remettant en cause leur niveau de protection.
Les différents protocoles et algorithmes inhérents à l’usage des VPN doivent être configurés à l’état de l’art, afin d’éviter les faiblesses des algorithmes obsolètes (cassage…) (Annexes B1 du RGS).

Interdire le trafic entre VPN

Les flux provenant du VPN à destination des autres VPN sont à sécuriser, car la zone d’origine n’est pas forcément une zone de confiance.
Il convient de maîtriser tous les flux à destination des VPN afin d’éviter toute tentative d’attaque.

OpenVPN : Gestion de l’authentification

L’authentification par mot de passe présente plusieurs risques : la fuite du mot de passe (son remplacement nécessite alors d’intervenir sur chaque équipement concerné), son manque de renouvellement, et sa robustesse. L’usage d’un certificat individuel pour l’authentification permet de bloquer les accès par révocation du certificat. La durée de vie des certificats est également fixée, ce qui impose la rotation des secrets dans une fenêtre de temps définie. Enfin, un certificat constitue généralement un secret plus robuste qu’un mot de passe. À ce titre, c’est le mode d’authentification préconisé par l’ANSSI.
Il est recommandé de gérer l’authentification des pairs OpenVPN par certificat.

OpenVPN : Choix du Diffie-Hellman

De nouvelles vulnérabilités sur les protocoles et algorithmes sont régulièrement découvertes, remettant en cause leur niveau de protection.
Les différents protocoles et algorithmes inhérents à l’usage de TLS doivent être configurés à l’état de l’art, afin d’éviter les faiblesses des algorithmes obsolètes (cassage…) (SDE-NT-35/ANSSI/SDE/NP).

OpenVPN : Utilisation de tls-crypt v2

Les premiers échanges pour l’établissement de la connexion TLS entre le client et le serveur OpenVPN sont fait en clair. Cet échange de clés fait en clair peut induire une vulnérabilité de type Man-in-the-Middle.
Pour parer ce type d’attaques, il est recommandé de renseigner une clé pré-partagée tls-crypt permettant de chiffrer aussi les trames d’établissement du canal TLS.

OpenVPN : Désactiver la compression LZO

L’utilisation de la compression LZO est déconseillée, car le ratio de compression laisse fuiter de l’information sur les données compressées claires.
Il est donc recommandé de désactiver la compression LZO.

IPsec : Gestion de l’authentification

L’authentification par mot de passe présente plusieurs risques : la fuite du mot de passe (son remplacement nécessite alors d’intervenir sur chaque équipement concerné), son manque de renouvellement, et sa robustesse. L’usage d’un certificat individuel pour l’authentification permet de bloquer les accès par révocation du certificat. La durée de vie des certificats est également fixée, ce qui impose la rotation des secrets dans une fenêtre de temps définie. Enfin, un certificat constitue généralement un secret plus robuste qu’un mot de passe. À ce titre, c’est le mode d’authentification préconisé par l’ANSSI.
Il est recommandé d’utiliser une authentification par certificats et non par clé pré-partagée (DAT-NT-003/ANSSI/SDE/NP).

IPsec : Groupe Diffie-Hellman

De nouvelles vulnérabilités sur les protocoles et algorithmes sont régulièrement découvertes, remettant en cause leur niveau de protection.
Les différents protocoles et algorithmes inhérents à l’usage d’IPsec doivent être configurés à l’état de l’art, afin d’éviter les faiblesses des algorithmes obsolètes (cassage…) (DAT-NT-003/ANSSI/SDE/NP).

Désactiver PPTP

Plus l’équipement est exposé, plus les sources possibles d’accès illégitimes sont nombreuses, et notamment les scans automatiques. Le protocole PPTP est maintenant considéré comme un protocole obsolète niveau sécurité, afin de restreindre l’exposition de l’équipement, il doit être désactivé.

Désactiver L2TP/IPSec

Plus l’équipement est exposé, plus les sources possibles d’accès illégitimes sont nombreuses, et notamment les scans automatiques.
Il est conseillé de désactiver le serveur L2TP/IPSec afin de restreindre l’exposition de l’équipement.

Certificats utilisateurs

La réutilisation d’un certificat pour plusieurs utilisateurs empêche d’identifier celui qui l’utilise, augmente l’exposition du certificat, et en cas de compromission de celui-ci, la révocation-réémission du certificat impacte plusieurs utilisateurs.
Les certificats utilisateurs doivent être nominatifs pour la traçabilité et permettre leur révocation en cas de besoin. Nous recommandons une validité maximum de 1 an.

Authentification deux facteurs

Les postes mobiles des utilisateurs étant exposés, un facteur d’authentification simple peut fuiter. L’authentification des utilisateurs doit être à deux facteurs.

Algorithmes de chiffrement et d’authentification

De nouvelles vulnérabilités sur les protocoles et algorithmes sont régulièrement découvertes, remettant en cause leur niveau de protection.
Les différents algorithmes inhérents à l’usage de TLS pour l’établissement d’un VPN poste à site doivent être configurés à l’état de l’art afin d’éviter les faiblesses des algorithmes obsolètes (SDE-NT-35/ANSSI/SDE/NP).

Une seule connexion distante à la fois

En changeant l’adresse IP du client "OpenVPN accès distant" pour une adresse IP d’un autre client "OpenVPN accès distant" déjà connecté au serveur d’accès distant, un attaquant obtient les droits de firewall de l’utilisateur usurpé.
Il est donc recommandé de n’autoriser qu’une seule connexion distante à la fois, de cette manière, les droits de firewall ne peuvent pas être usurpés.

Désactiver la compression LZO

L’utilisation de la compression LZO est déconseillée, car le ratio de compression laisse fuiter de l’information sur les données compressées claires.
Il est donc recommandé de désactiver la compression LZO.