Sécurité des systèmes informatiques/Sécurité informatique/Chiffrement de flux et VPN

Sécurité des systèmes informatiques

• Introduction
• Fonctionnement dans une entreprise
  • Le domaine SSI
    • Documents SSI
  • La veille technologique sécurité
    • Scénarios
  • Administration/Exploitation
  • Environnement
  • Législation
• Moyens techniques de protection
  • Réseau et firewall
    • Aspects architecturaux
      • Utilisation de DMZ
      • Diversification et haute-disponibilité
  • Systèmes d'authentification
  • Chiffrement de flux et VPN
  • Détection d'intrusion
  • Gestion des traces
  • Observation, surveillance, supervision
• Protection et applications usuelles
  • Antivirus
  • Traces et mots de passe Windows
  • Serveur HTTP
  • Filtrage d'URL
  • Signature et messagerie
  • Serveur DNS (BIND 9)
  • PKI et signatures
  • Routage dynamique
  • Active directory
  • Samba
• Recherche de vulnérabilités

La protection des flux réseaux, et notamment des flux point à point identifiables facilement, comme les transferts de fichiers entre entreprises ou les accès des ordinateurs portables des utilisateurs nomades vers le réseau interne d'une entreprise à partir d'Internet, peut bénéficier d'une technique de protection générique consistant à authentifier et chiffrer l'ensemble du flux réseau concerné. Les technologies permettant cette protection sont souvent regroupées sous la désignation de « VPN » pour Virtual Private Network (réseau privé virtuel). On peut grossièrement dissocier les implémentations entre :

• la mise en œuvre d'un tunnel réseau protégé directement au niveau IP entre deux machines qui protège tous les échanges effectués mais peut théoriquement contraindre l'une des machines (située dans un environnement hostile) à interrompre ses communications hors du VPN ;
• et la création d'un tunnel au niveau des services applicatifs (généralement au niveau TCP) qui peut permettre de protéger plus spécifiquement les flux associés à un service donné (les flux X11 par exemple, voire les flux HTTP via SSL par exemple si on veut bien voir HTTPS comme un tunnel).

Suivant que l'on souhaite protéger les communications au niveau IP ou TCP, la problématique d'authentification est assez différente. Dans le premier cas, il s'agit de réaliser une authentification mutuelle des machines détentrices des adresses IP concernées. Dans le deuxième cas, l'authentification peut éventuellement également porter sur les utilisateurs des applications activant le tunnel. Cette frontière n'est pas hermétique, mais il faut apparemment utiliser des extensions des techniques de VPN de niveau IP pour incorporer une authentification utilisateur quand elle est souhaitée, par exemple pour des accès nomades (voir IPSEC).

Dans les deux cas, la mise en œuvre fait appel à des techniques assez similaires : authentification forte (par exemple à l'aide de certificats X.509, ou des algorithmes d'authentification basés sur RSA ou DSA), négociation de clés intermédiaires et d'algorithmes de chiffrement (DES, 3DES, AES, Blowfish, etc.) et/ou de contrôle d'intégrité (MD5, SHA-1, SHA-256, etc.) et traitement du flux avec mise à jour régulière des clés. On trouve donc un grand nombre de points communs entre les deux approches. Par ailleurs, dans le domaine des standards normalisés et des implémentations les plus répandues, deux grands acteurs dominent la mise en œuvre : IPSEC/ISAKMP pour le chiffrement au niveau IP, et SSL (via SSH ou HTTPS) pour le chiffrement au niveau des flux applicatifs TCP.

IPSEC

Les objectifs de l'architecture IPsec présentée dans la [RFC 2401] (sur laquelle cette section est largement basée) sont de fournir différents services de sécurité pour le trafic au niveau IP, que ce soit pour les environnements IPv4 ou IPv6, via l'utilisation de mécanismes de sécurité cryptographiques ou protocolaires. Les différents éléments composant cette architecture de sécurité sont :

• les protocoles de sécurité : AH (Authentication Header) pour la garantie de l'intégrité, et ESP (Encapsulating Security Payload') pour la confidentialité ;
• les associations de sécurité (SA) : leur définition, leur fonctionnement, leur gestion, et les traitements associés ;
• la gestion des clefs de chiffrement : manuelle ou automatique, et notamment via IKE (Internet Key Exchange) ou dans le schéma général d'ISAKMP ;
• et enfin les algorithmes de protection de l'intégrité ou de chiffrement eux-mêmes ([RFC 2403], [RFC 2404], etc.).

IPsec fournit les services de sécurité en permettant à un système informatique de sélectionner les protocoles de sécurité souhaités, de déterminer le(s) algorithme(s) à utiliser pour ces services, et en mettant en place les clefs cryptographiques nécessaires pour leur mise en œuvre.

L'ensemble des services de sécurité fournis par IPsec incluent le contrôle d'accès, la protection de l'intégrité des paquets, la garantie d'authenticité de l'origine des paquets, le rejet des paquets rejoués (c'est à dire une forme de protection partielle d'intégrité sur les séquences de paquets), la confidentialité (via le chiffrement), et une confidentialité partielle sur la nature des flux réseaux transportés. Comme ces services sont fournis au niveau IP, ils peuvent être utilisés par n'importe quel protocole de plus haut niveau, comme TCP, UDP, ICMP, BGP, etc.

IPsec supporte aussi la négociation de la compression au niveau IP, notamment en raison du fait que, quand le chiffrement est employé, il empêche toute compression efficace par les protocoles de plus bas niveau.

IPsec

IPsec utilise deux protocoles pour assurer la sécurité du trafic réseau : AH et ESP. Ces protocoles sont décrits respectivement dans les [RFC 2402] et [RFC 2406].

• Le mode AH (Authentication Header) fournit une protection de l'intégrité des paquets, la garantie de l'origine des paquets et une protection optionnelle contre les rejeux.
• Le mode ESP du protocole (Encapsulating Security Payload) fournit la confidentialité. Il peut aussi fournir une protection de l'intégrité des paquets, la garantie de l'origine des paquets et une protection contre les rejeux.
• AH et ESP sont tous deux des véhicules pour le contrôle d'accès, basé sur la distribution de clefs cryptographiques et la gestion des flux réseaux associés aux protocoles de sécurité.

Ces protocoles peuvent être utilisés seuls ou simultanément pour fournir des services de sécurité sur IPv4 ou IPv6. Chaque protocole permet d'utiliser deux modes : le mode transport ou le mode tunnel. Dans le mode transport, ils fournissent essentiellement une protection à l'usage des protocoles de plus haut niveau ; dans le mode tunnel, ces protocoles sont appliqués à des paquets IP encapsulés.

IPsec permet donc à l'utilisateur ou l'administrateur de contrôler la granularité du trafic auquel un service de sécurité est offert. Par exemple, il est possible de créer un seul tunnel crypté pour transporter tout le trafic réseau entre deux passerelles sécurisées ou bien un tunnel chiffré séparé peut être construit pour chaque connexion TCP établie entre chaque paire de machines communiquant au travers de ces passerelles. Pour permettre cette flexibilité, l'infrastructure de gestion d'IPsec doit inclure des fonctions permettant :

• de spécifier quels services de sécurité doivent être utilisés et comment ils doivent être combinés ;
• de définir la granularité à laquelle un niveau de protection donné doit être appliqué ;
• de choisir les algorithmes utilisés concrètement pour les protections cryptographiques.

Comme tout ces services de sécurité reposent sur des valeurs secrètes partagées (des clefs cryptographiques), IPsec repose sur un ensemble de mécanismes séparés nécessaires pour mettre en place ces clefs. IPsec supporte à la fois une distribution manuelle ou automatique des clefs de chiffrement, d'intégrité et d'authentification. L'ensemble des normes relatives à IPsec fournit une solution spécifique pour la gestion automatisée des clefs : IKE, basée sur des solutions de cryptographie asymétrique (à clef publique), mais d'autres approches peuvent être employées, en s'appuyant sur le cadre général fourni par ISAKMP.

ISAKMP/IKE

ISAKMP, défini dans la [RFC 2408], est le protocole permettant la mise en place des associations de sécurité (SA) utilisables pour la mise en œuvre du tunnel chiffré. Ce protocole ne définit pas précisément les techniques d'authentification et d'échange de clefs utilisables mais fournit le contexte permettant de définir ces techniques.

Le protocole technique le plus utilisé du point de vue opérationnel semble être IKE, défini dans la [RFC 2409], à l'intérieur de l'ensemble normatif d'IPsec. D'autres protocoles sont possibles mais moins répandus, par exemple OAKLEY (défini dans la [RFC 2412] et utilisant une technique de type Diffie-Helmman) dont IKE est une variante simplifiée.

Déroulement d'une session

Les différentes phases de l'établissement d'une session IPsec sont schématiquement les suivantes :

1. Un tunnel IPsec est initié lorsqu’un trafic à protéger devant aller d’un point à un autre est détecté (soit sur la machine elle-même en mode transport, soit par la passerelle du site en mode tunnel).
2. Phase 1 (IKE) : négociation de la politique d'établissement des associations de sécurité (SA) ISAKMP. Une fois que les 2 extrémités du tunnel sont authentifiées, un canal de communication protégé est créé pour la poursuite de la négociation IKE.
3. Phase 2 (IKE) : les 2 extrémités du tunnel utilisent alors ce canal protégé pour négocier les associations IPsec (ESP et/ou AH). La négociation des paramètres finaux détermine comment le tunnel IPsec établi pourra fonctionner (algorithmes utilisés, intervalles de renouvellement des clefs de chiffrement, etc.).
4. Le tunnel IPsec est créé, les échanges des données transférées entre les 2 extrémités du tunnel IPsec sont basées sur les paramètres IPsec configurés dans le « transform set » choisi.
5. Le tunnel IPsec se termine quand les SA sont supprimées ou quand leur durée de vie expire.

Les phases de négociation 1 et 2 sont cruciales pour l'établissement de la session IPsec. Surtout quand on a affaire à des implémentations hétérogènes de constructeurs différents, les critères de succès de la négociation peuvent être difficiles à atteindre. En effet, le protocole est assez complexe, quasiment impossible à observer sur le réseau (car chiffré dès les premières phases) et met en jeu un nombre important de paramètres parfois assez cryptiques. En pratique, la partie la plus difficile de la mise en œuvre d'un VPN IPsec consiste généralement à bien paramétrer les logiciels pour assurer le succès de cette négociation. Quand on a affaire à la même implémentation à chaque bout du tunnel, les fichiers de configuration sont presque les mêmes, et la tâche est généralement plus simple.

Pendant la durée de vie de la session de communication IPsec, des négociations périodiques sont effectuées via ISAKMP pour faire varier les clefs de sessions utilisées. En règle générale, les clefs de sessions utilisées pour les protocoles ESP ou AH (type phase 2) sont renégociées avec une période de l'ordre d'une heure, celles utilisées pour les négociations ISAKMP elles-mêmes au bout d'une période de l'ordre d'un jour. La valeur optimale de ces paramètres varie bien évidemment suivant les algorithmes cryptographiques autorisés (et notamment la longueur des clefs impliquées) et le volume de trafic échangé.

Clients VPN « personnels » (authentification de l’utilisateur)

Une utilisation particulièrement importante des protections de type VPN concerne les accès des utilisateurs nomades aux ressources du réseau interne d'une entreprise. Dans ce mode de fonctionnement, la protection accrue offerte par l'utilisation d'un VPN (à la fois en terme d'authentification et de protection du flux pendant son activité) permet d'envisager de permettre à ces postes de travail itinérants d'accéder à la majorité des ressources du réseau interne à partir d'Internet (et donc de points d'accès opérateurs classiques, avec une couverture géographique très large) voire à partir d'un point d'accès sans fil (WiFi).

Dans ce cas toutefois, on souhaite généralement associer l'authentification mise en œuvre par le logiciel VPN (par exemple une implémentation IPsec) avec une authentification de l'utilisateur accédant au réseau interne. Dans ce cas, l'authentification effectuée par un protocole comme IPsec n'est pas totalement adaptée. Par ailleurs, le souci pratique est fréquemment de ré-utiliser une infrastructure d'authentification existante pour les utilisateurs (utilisant par exemple S/Key, ou de simples mots de passe via RADIUS) et de ne profiter que de la sécurité offerte par IPsec au niveau du transport (pas tellement au niveau de l'authentification).

Il faut aussi souligner, dans ce cas, l'importance de la protection de l'ordinateur portable lui-même par rapport aux ressources réseau qui peuvent éventuellement l'entourer. En effet, la liaison VPN offrant généralement un accès au niveau IP, même si les flux sont ultérieurement contrôlés par un firewall de l'entreprise, il peut être possible de rebondir vers le réseau interne en prenant appui sur l'ordinateur portable si celui-ci est vulnérable. C'est tout à fait possible par exemple en activant les fonctions de routage du système d'exploitation de l'ordinateur portable, ou en utilisant des relais applicatifs ou des relais génériques (logiciels que nous avons déjà présentés sous un autre éclairage). Ceci conduit généralement à coupler l'utilisation d'un « client » VPN avec un firewall personnel permettant d'interdire tout accès réseau n'empruntant pas le canal protégé par le VPN. Il faut noter que, notamment pour pallier aux attaques les plus complexes ou aux infections virales capables de se propager en différé, les protections du firewall personnel doivent aussi être actives même quand le VPN lui-même n'est pas actif.

Face à ces besoins, même si le fonctionnement d'IPsec est souvent respecté pour tout ce qui est du fonctionnement courant du VPN, un certain nombre d'implémentations « propriétaires » ont vu le jour. (En toute rigueur, un certain nombre d'implémentations ont aussi précédé l'apparition des standards IPsec.) De manière générale, ces clients VPN « personnels » propriétaires offrent des fonctionnalités additionnelles en terme d'authentification ou de protection mais ces extensions ne respectent généralement pas une norme et sont donc généralement uniquement compatibles avec une passerelle du même constructeur. Dans la pratique, il est important de les identifier correctement, que ce soit pour profiter de ces fonctionnalités additionnelles ou pour ne pas en pâtir.

Tunnels SSH

Pour la mise en place de liaisons protégées de type VPN au niveau applicatif, une solution pragmatique qui permet parfois de trouver des solutions efficaces dans les cas où le mode de fonctionnement d'IPsec est un peu trop contraignant, est d'utiliser le mode tunnel de connexions SSH.

SSH est d'abord un outil de connexion à distance de machine à machine offrant une authentification forte (par chiffrement asymétrique RSA ou DSA en général, éventuellement couplé à une authentification par mot de passe Unix classique) et une protection de la session distante (à la fois du point de vue de sa confidentialité et de son intégrité). Toutefois, le protocole SSH permet également d'utiliser le canal de communication TCP protégé pour transporter les communications réseau d'autres applications (si celles-ci le permettent sans trop de complication). Cette configuration est notamment recommandée pour renforcer la sécurité de sessions X11 distantes traversant des réseaux non-sûrs, en utilisant les fonctions de x-forwarding offertes à la fois par OpenSSH et XFree86/XOrg.

L'avantage de cette solution est de pouvoir être mise en place éventuellement entièrement en mode utilisateur, en tout cas sans impliquer des paramétrages sophistiqués impliquant potentiellement l'ensemble du fonctionnement réseau des machines concernées.

OpenVPN

Une solution similaire mais plus récente est dédiée à la mise en place de tunnels au niveau applicatif. Il s'agit d'OpenVPN. Elle utilise également les possibilités offertes par le protocole TLS et son implémentation OpenSSL. Cette réalisation illustre bien les avantages de fonctionner au niveau applicatif par rapport à IPsec : OpenVPN fonctionne sur la majeure partie des systèmes d'exploitation et peut traverser assez facilement des firewall intermédiaires. Cette utilitaire qui entre en version 2 nous semble particulièrement intéressant.