Comment prévenir une rupture VPN avec IPv6 - Actualités RT Sécurité

Comment prévenir une rupture VPN avec IPv6

le 17/10/2019, par Scott Hogg, Network World (adaptation Jean Elyan), Sécurité, 1217 mots

Si les VPN d'accès à distance ne sont pas correctement configurés, le trafic IPv6 de périphériques distants peut échapper aux contrôles de sécurité de l'entreprise.

Comment  prévenir une rupture VPN avec IPv6

Les entreprises qui ne savent pas précisément comment fonctionne l'IPv6 sur les dispositifs des utilisateurs distants prennent le risque que ces machines accèdent à des sites interdits même si elles passent par des VPN normalement destinés à restreindre leur accès. Cette faille est liée au fait que certains de ces VPN d'accès distant sont configurés pour inspecter et appliquer des contrôles de sécurité uniquement au trafic IPv4 quand il traverse un concentrateur VPN, mais n'applique pas les mêmes protections au trafic IPv6. Si bien que le trafic IPv6 peut accéder librement et directement à Internet sans que ces contrôles soient appliqués. Ce problème de fuite IPv6 de VPN, pourtant bien connu, est souvent négligé. Il existe des solutions pour éviter cette fuite IPv6, mais la première étape est de comprendre ce qui se passe afin d'en apprécier l'importance.

La fuite IPv6 de VPN, un problème négligé

De nombreuses entreprises ne réalisent pas combien de fois l'IPv6 est utilisé sur les appareils qui accèdent à leurs réseaux via VPN. Généralement, les téléphones, tablettes et ordinateurs portables utilisés pour l'accès à distance aux réseaux d'entreprise prennent en charge l'IPv6, tout comme les services haut-débit et cellulaires qu'ils peuvent utiliser pour accéder à Internet. Par conséquent, les entreprises omettent souvent de considérer l'IPv6 comme un critère de sécurité. Leurs configurations VPN n'inspectent que le trafic IPv4, ce qui permet aux appareils mobiles d'accéder librement aux sites IPv6 qui pourraient s'avérer dangereux pour les réseaux, les appareils et leurs données d'entreprise. Une fois le VPN établi, le concentrateur VPN inspecte le trafic à destination d'Internet et bloque le trafic qui pointe vers des destinations jugées hors limites par les politiques de l'entreprise. (Voir figure 1).

 


Dans ce schéma, on peut voir un ordinateur portable VPN d'entreprise classique où le trafic IPv4 est le seul à revenir vers le périmètre Internet de l'entreprise via le tunnel VPN. La ligne rouge représente le trafic IPv4 dirigé vers l'entreprise pour être soumis à inspection et aux contrôles de sécurité avant d'accéder à Internet. Tout le trafic IPv4 doit passer par le tunnel VPN et ne peut pas accéder directement à Internet. Mais ce n'est pas le cas du trafic IPv6, représenté par la ligne bleue. (Crédit : Network World/IDG)

La plupart des VPN d'entreprise appliquent ce qu'on appelle le « no split-tunneling », pour améliorer la sécurité en forçant toutes les connexions IPv4 à traverser le VPN. Or, avec le no split-tunneling, une fois qu'une connexion VPN a été établie, les périphériques distants ne peuvent pas établir de connexion séparée à l'Internet en général. Typiquement, la configuration consiste à annoncer une route IPv4 (0.0.0.0.0/0.0.0.0.0) par défaut sur le tunnel VPN au client VPN. Cette route par défaut IPv4 est insérée dans la table de routage du client VPN, visualisé dans la Figure 1 par l'espace rouge sur l'écran de l'ordinateur portable. Donc, quand l'utilisateur final exécute le VPN, toutes ses tentatives de connexion à des sites Web IPv4 sont détournées via l'intranet de l'entreprise pour inspection.

Le problème, c'est que, souvent, les entreprises n'appliquent pas les paramètres de « no split tunneling » au VPN pour qu'il inclut la route par défaut IPv6 qui se trouve également dans la table de routage du client VPN (::/0), représentée en bleu sur l'écran du portable de la figure 1. Le trafic IPv6 conserve ainsi un accès direct à Internet, contournant toute mesure de sécurité du périmètre Internet de l'entreprise. Les entreprises doivent prendre en compte le fait que les appareils qui se connectent à leurs réseaux sont déjà compatibles IPv6 et qu'ils sont utilisés par leur personnel nomade. Il est important qu'elles adoptent une approche active pour remédier à ce défaut de sécurité.

Prévenir la fuite IPv6 d'un VPN

En effet, l'approche recommandée, celle qui donne le meilleur résultat, consiste à activer l'IPv6 sur le VPN et dans le périmètre de l'entreprise. Les entreprises devraient commencer à activer la connectivité IPv6 sur leur périmètre Internet, puis établir une connectivité IPv6 à leurs VPN. Les pare-feu périmétriques des entreprises modernes et leur logiciel VPN peuvent déjà utiliser l'IPv6. Il suffit de les activer et de les configurer. Dans ce cas, le flux de circulation ressemblerait à celui de la figure ci-dessous.

 


Voici l'architecture VPN IPv6 recommandée où le client VPN utilise la connectivité réseau IPv4 et la connectivité réseau IPv6. Il dispose à la fois d'une table de routage IPv4 et d'une table de routage IPv6 avec leurs routes par défaut respectives conduisant le trafic Internet dans le tunnel VPN. Cela permet aux systèmes périmétriques de l'entreprise d'inspecter les deux protocoles et d'appliquer les mêmes protections de sécurité, évitant ainsi la fuite IPv6 du VPN. (Crédit : Network World/IDG)

Une seconde option consiste à utiliser un client VPN qui empêche lui-même les fuites IPv6. Par exemple, le client AnyConnect de Cisco associé à l'appliance de sécurité ASA de Cisco permet de contrôler la configuration du split-tunneling sur les clients compatibles IPv6. De même, le VPN GlobalProtect de Palo Alto Networks et le client SSL VPN FortiClient de Fortinet sont compatibles IPv6. Il s'agit simplement d'activer l'IPv6 et de le contrôler avec les politiques VPN.

Malheureusement, certaines entreprises préfèrent interrompre la connectivité IPv6 une fois le tunnel VPN établi. Dans ce cas, le serveur VPN annonce la route par défaut IPv6 (::/0) à la table de routage du client VPN en dirigeant toutes les connexions IPv6 via le tunnel VPN. Cependant, quand le VPN et le réseau interne de l'entreprise sont uniquement acheminés en IPv4, toutes les connexions IPv6 sont supprimées. Une entreprise ne devrait pas annoncer cette route IPv6 par défaut au VPN si elle n'a pas de connectivité IPv6 parce que cela provoque des problèmes de connectivité d'application pour tous les clients VPN essayant d'accéder aux applications utilisant l'IPv6. Les utilisateurs qui ont besoin d'accéder à des sites compatibles IPv6 ne pourront pas se connecter, et ils souffriront de retard quand le client se reconnectera en fallback rapide à l'IPv4.

Une troisième option consisterait à s'appuyer sur le système de noms de domaine (DNS) pour empêcher la fuite IPv6 du VPN. Dans ce cas, seul le VPN IPv4 serait maintenu, mais toutes les résolutions d'adresses DNS seraient forcées de passer dans le tunnel. Les requêtes DNS IPv6 seraient écrasées, mais les requêtes IPv4 passeraient. Cette approche peut avoir des inconvénients, car elle entamerait la performance de certaines applications compatibles IPv6 par rapport aux résolutions DNS IPv6. Elle peut également entraîner des tentatives de déconnexion et de fallback en IPv4. Enfin, pour l'administrateur IT, cette option rend aussi le dépannage de problèmes d'application plus difficile, car il doit identifier les applications compatibles IPv4 et/ou IPv6 et rechercher le problème au niveau du DNS, de la connectivité, des politiques VPN et de la configuration du client VPN.

Plus les entreprises attendent pour construire des VPN d'accès à distance compatibles IPv6, plus le problème de fuite IPv6 de VPN s'aggrave. Les appareils des utilisateurs utiliseront de plus en plus l'IPv6 et le trafic IPv4 repassera de moins en moins par le VPN de l'entreprise. Il est temps qu'elles prennent la mesure de ce problème de fuite IPv6 du VPN et qu'elles activent l'IPv6 sur leurs périmètres Internet et au niveau de leurs VPN d'accès distant.

Comment désactiver le protocole LLMNR dans Windows Server

De façon générale, LLMNR ou Link-Local Multicast Name Resolution (résolution de noms multidiffusion) n'est pas nécessaire dans les réseaux modernes et il laisse la porte ouverte aux attaques man-in-the-middle....

le 07/11/2019, par Susan Bradley, IDG NS (adaptation Jean Elyan), 809 mots

« Les entreprises plus ciblées que le grand public », selon Mikko...

Au cours des deux dernières années, les pirates ont changé de cible. Le grand public est moins visé que les entreprises, et les attaques contre ces dernières sont de plus en plus sophistiquées. Lors du CeBit...

le 04/11/2019, par Julia Talevski, ARNnet (adapté par Jean Elyan), 590 mots

Cisco émet un avis de sécurité critique pour le conteneur REST API de...

La vulnérabilité dans le conteneur de service virtuel Cisco REST API de IOS XE - elle porte la référence CVE-2019-12643 - pourrait permettre à des attaquants de récupérer le token-id d'un utilisateur...

le 23/10/2019, par Michael Cooney, IDG NS (adapté par Jean Elyan), 497 mots

Dernier dossier

Les white-box sont-elles l'avenir de la commutation réseau ?

Et si vous pouviez gérer vos commutateurs de centres de données et vos routeurs de la même façon que vos serveurs et ainsi réduire les coûts des dépenses en capital ? C'est la promesse des white-box qui amènent des systèmes d'exploitation réseau open source fonctionnant sur du matériel courant.Pour en avoir le coeur net, nous avons testé Cumulus...

Dernier entretien

Jamshid Rezaei

DSI de Mitel

Le DSI de Mitel, Jamshid Rezaei, a adopté le système japonais du Kaizen prônant l'amélioration continue...