La diversité des équipements BYOD et des menaces associées ne permettent plus d'assurer la sécurité d'un réseau uniquement en filtrant les flux via des firewalls. Les solutions de type NAC (Network Access Control) proposent une approche novatrice à ces problématiques.
1. Introduction
Dans un schéma conventionnel de sécurisation d'un réseau d'entreprise, les différents postes sont conformes aux exigences de sécurité de la DSI (direction des systèmes d'information) et voient leurs accès réseaux filtrés aux niveau 2 (switching/VLAN), niveau 3 (routage) et niveau 4 (firewalling) de la couche OSI. Ce modèle qui était jusqu'à présent relativement efficace est mis à mal par l'émergence du BYOD mais aussi par nombre de menaces de type 0-day difficiles à traiter sur ce type d'infrastructures.
1.1 Diversité d'équipements BYOD
Les équipements BYOD arrivant sur les réseaux d'entreprise via les employés peuvent être très diversifiés. On distinguera généralement trois principales catégories : les smartphones dont l'usage principal reste généralement l'utilisation du compte mail d'entreprise, les tablettes qui permettent plus d'interactions (e.g. la prise de notes en réunion et les accès SSH/Terminal Server en mobilité) et les ordinateurs portables qui peuvent être utilisés en lieu et place de la station de travail fournie par l'entreprise.
Malgré des usages différents, ces différents équipements posent des problématiques de sécurisation similaires. Tout d'abord, ils utilisent souvent des systèmes d'exploitation différents de ce que la DSI a l'habitude de supporter : iOS et Android pour les smartphones/tablettes, Mac OS X et GNU/Linux sont aussi régulièrement vus sur les ordinateurs portables. Quand bien même la DSI serait à même de supporter ces technologies, la plupart des employés n'accepteront pas de donner le contrôle de leurs équipements personnels à des solutions de gestion de parc gérées par la DSI.
Il est donc nécessaire de mettre en place des solutions plus souples que la gestion traditionnelle de parc informatique via un annuaire Active Directory et ses GPO ou de flotte mobile via un serveur BES (BlackBerry Entreprise Server).
1.2 Problématiques réseaux associées
Une autre problématique issue de l'émergence d'équipements BYOD sur un réseau d'entreprise est qu'il devient impossible de déterminer avec certitude quels seraient les accès légitimes pour chaque adresse IP associée à un équipement. En effet, la plupart de ces équipements seront connectés en Wi-Fi, ce qui rend l'identification de l'équipement en fonction du port-réseau impossible. L’identification par mac-address reste possible, mais c'est une solution peu fiable.
La stratégie d'interdire ces équipements ou de les isoler dans une DMZ privée de tout accès à des ressources sensibles serait une des solutions les plus évidentes du point de vue de la sécurité. Cependant, dans la réalité des faits, le BYOD arrive bien souvent par les cadres supérieurs qui de par leur place dans l'organigramme feront pression pour que l'organisation supporte ces équipements d'une manière ou d'une autre. De plus, il peut être dangereux de sous-estimer l'inventivité d'une personne cherchant à contourner une situation jugée absurde, une politique trop stricte entraînera donc généralement une escalade entre solutions de contournement et nouvelles solutions de blocage.
Par ailleurs, il ne faut pas oublier que si ces équipements BYOD peuvent être une menace pour le réseau existant, ils permettent aussi parfois d'ajouter des accès réseaux 3G à des équipements habituellement soumis au filtrage mis en place par la DSI. Ils peuvent donc favoriser la fuite d'informations ou le contournement d'une politique de filtrage des accès Internet.
1.3 Besoin de solutions pro-actives
En dehors de la problématique du BYOD, il est aujourd'hui difficile de s'assurer de la bonne sécurisation d'un équipement ayant accès au réseau uniquement par le fait qu'il est mis à jour régulièrement et administré de manière à ce que l'utilisateur ne puisse rien installer/exécuter de dangereux. En effet, un certain nombre de vulnérabilités sont aujourd'hui exploitées sur des logiciels standards et nécessaires pour la productivité de l'organisation (Java, Internet Explorer, Acrobat Reader, …) avant qu'une solution de contournement (work-around) ou patch soit disponible.
Cet état de fait impose donc la mise en place de solutions pro-actives capables d'agir en profondeur pour sécuriser un réseau d'entreprise.
1.4 Les apports du NAC
Afin des lutter contre l'ensemble des menaces précédemment identifiées, les solutions de NAC (Network Access Control) entendent proposer une solution intégrée et efficace. Afin d'offrir une authentification efficace des équipements, ces solutions s'appuient généralement sur la technologie 802.1X, elles proposent ensuite des mécanismes permettant de s'assurer en temps réel du bon respect des politiques de sécurité par l'équipement ainsi que des solutions de détection de comportement suspect/inapproprié. L'ensemble de ces mesures, lorsqu'elles sont correctement associées, permettent de gérer d'une manière la plus efficace possible la diversité des équipements, les risques associés à ces nouveaux équipements et de traiter les problématiques de menaces dites « 0-day » sur les équipements BYOD ou non.
1.5 Définition d'une politique NAC/BYOD
Une solution NAC reste une solution de sécurité comme une autre, ce n'est pas une solution miracle permettant de résoudre automatiquement l'ensemble des problématiques de sécurités associées. Avant même de faire le choix d'une solution et d'envisager son implémentation, il est nécessaire de définir la politique de sécurité que la solution NAC devra faire appliquer.
Fig. 1 : Exemple d'une politique NAC/BYOD
On commencera généralement par définir les différents niveaux de segmentation du réseau :
- VLAN utilisateur : cela correspondra au VLAN dans lequel l'équipement respectant toutes les contraintes de sécurité sera placé. Il est relativement fréquent d'avoir plusieurs VLAN en fonction par exemple de l'équipe dans laquelle travaille l'utilisateur.
- VLAN invité : afin de fournir un certain niveau de connectivité réseau à des équipements identifiés mais pour lesquels il n'est pas forcement possible de s'assurer du respect de l'ensemble des règles de sécurité, il est généralement indispensable d'avoir un VLAN invité.
- Zone de quarantaine : afin de ne pas permettre à des ordinateurs infectés de propager leurs infections sur les VLAN utilisateur ou invité, il est nécessaire de définir une zone de quarantaine dans laquelle chaque équipement sera isolé des autres et n'aura accès qu'à un portail spécifique expliquant les raisons de cette quarantaine et les manières d'y remédier.
Il faudra ensuite traiter les différents cas découlant des questions suivantes :
- L'équipement est-il authentifié via 802.1X ?
- L'équipement est-il managé par la DSI ou est-il un BYOD ?
- Quel est l'état de « santé » de l'équipement ?
On peut ensuite arriver à matérialiser la politique sur la forme d'un diagramme comme celui de la figure 1 et passer à l'étude et l'implémentation d'une solution.
2. 802.1X
Quelle que soit la solution de NAC utilisée, la méthode d'authentification standardisée restera la norme IEEE 802.1X. Cette norme définit l'encapsulation du protocole EAP (Extensible Authentification Protocol – RFC 3748 [1]) au sein de réseaux respectant les normes IEEE 802 comme les réseaux filaires commutés 802.1 ou Wi-Fi 802.11.
Au niveau du vocabulaire, la norme nomme l'équipement sur lequel la connexion est établie un authenticator, c'est cet équipement qui est en charge de l'authentification de la connexion. Afin d'effectuer cette authentification, il se base sur un supplicantcôté client et à un serveur d'authentification qui dans notre cas sera généralement intégré au serveur NAC.
2.1 Fonctionnement
L'authentification d'une connexion via 802.1X se fait via quatre étapes distinctes.
2.1.1 Initialisation de la connexion
Lors de cette étape, l'authenticator considère la connexion comme non autorisée et bloque tout trafic qui ne correspond pas au protocole 802.1X.
2.1.2 Initiation des mécanismes d'authentification
Juste après l'initialisation, l'authenticator envoie régulièrement des requêtes EAP de manière à pouvoir identifier le supplicant présent de l'autre côté du lien. Une fois la réponse du supplicant reçue, elle est transmise via le protocole RADIUS au serveur d'authentification.
2.1.3 Négociation de la méthode EAP
En fonction de l'identité annoncée, le serveur d'authentification propose une méthode EAP qui est transmise au supplicantvia l'intermédiaire de l'authenticator. Le supplicantpeut alors accepter la méthode EAP proposée ou en proposer une autre.
Il est donc possible de proposer une authentification par certificat dans un premier temps tout en acceptant que le supplicants'authentifie via un challenge basé sur un identifiant et mot de passe comme un OTP (One Time Password) en cas d'absence de certificat côté supplicant.
2.1.4 Authentification
Une fois la méthode EAP acceptée par le supplicantet le serveur d'authentification, l'authentification EAP est effectuée et la connexion est autorisée et un VLAN peut être dynamiquement assigné par l'authenticatorsur demande du serveur d'authentification.
2.2 Implémentations
Du côté des authenticators, la plupart des équipements filaires et sans fils supportent cette norme 802.1X depuis plusieurs années.
Au niveau des systèmes d'exploitation, des supplicantssont présents nativement dans Microsoft Windows (depuis Windows 2000 SP4) et Mac OS X (depuis la version 10.3), mais il est fréquent d'utiliser comme supplicant un agent fourni par l'éditeur de la solution NAC utilisée de manière à mêler authentification et vérification de l'état de l'équipement. Pour les systèmes d'exploitation libres, différentes solutions telles que Open1X [2] existent.
Au sein des terminaux mobiles, iOS et Android fournissent des supplicants802.1X.
2.3 Vulnérabilités connues
L'authentification n'étant effectuée qu'à l'établissement de la connexion, toute attaque de type Man-In-The-Middle permet à un attaquant laissant le poste légitime s'authentifier via le protocole 802.1X de profiter ensuite de la connexion ouverte sans avoir à s'authentifier lui-même.
Il est donc nécessaire de mettre en place les contre-mesures appropriées au niveau des équipements réseaux afin d'éviter qu'une attaque Man-In-The-Middle rende l'authentification 802.1X inefficace.
Par ailleurs, les trames de déconnexion EAP envoyées par le supplicant transitent en clair et ne contiennent pas d'informations issues de l'authentification 802.1X. Il est donc possible, pour un attaquant ayant accès à l'authenticator et la possibilité de forger son adresse MAC, de créer un déni de service.
Cette attaque est normalement caduque avec la dernière version de la norme 802.1X-2010 qui utilise MACSec (802.1AE) afin de sécuriser les échanges de trames au sein du LAN.
3. Les contrôles supplémentaires
Afin d'aller plus loin que l'authentification 802.1X, il est nécessaire de s'assurer du niveau de sécurité de l'équipement. Ces vérifications peuvent se faire suivant les cas avec ou sans agent.
3.1 Avec agent
La solution avec agent est généralement privilégiée pour les équipements lourds dotés de systèmes d'exploitation relativement standards tels que Microsoft Windows, Mac OS X ou GNU/Linux. Le rôle de l'agent est d'effectuer l'ensemble des tests nécessaires pour évaluer le niveau de sécurité de l'équipement qui rejoint le réseau.
Les tests généralement effectués constitueront à vérifier la présence d'un antivirus et/ou anti-malware à jour, la présence ou l'absence de certains exécutables. Il pourra aussi être possible de s'assurer que le système d'exploitation est à jour et que les mises à jour automatiques sont activées. Les équipements BYOD étant par nature fortement mobiles, il peut aussi être utile de vérifier que leurs données sont chiffrées. Sur les solutions NAC les plus abouties, l'agent va jusqu'à être un HIDS (Host Intrusion Detection System) capable de remonter les événements suspects sur le serveur NAC.
Fig. 2 : Exemple d'une règle de vérification du chiffrement des disques durs
Contrairement à ce qui est possible sur un équipement géré par la DSI, la mise en place des mesures de sécurité (installation d'un antivirus, mise à jour du système, …) qui pourrait être effectuée par des GPO (politiques de groupes en environnement Microsoft) n'est pas effectuée sans intervention/validation de l'utilisateur de l'équipement BYOD. L'utilisateur garde donc la maîtrise de son équipement et peut donc faire le choix de ne pas respecter l'ensemble des contraintes (par exemple ne peut pas chiffrer ses disques durs). D'un autre côté, l'organisation peut éviter d'avoir des équipements ne respectant pas l'ensemble des politiques de sécurité sur ses réseaux privilégiés et les isoler sur un réseau invité.
Au niveau de l'authentification 802.1X, l'agent peut communiquer les informations qu'il a récupérées sur l'état de l'équipement via le supplicant. Le serveur d'authentification de la solution NAC peut alors refuser l'authentification 802.1X à un équipement non conforme. Généralement, l'agent communique aussi directement et régulièrement avec le serveur NAC de manière à ce que la solution NAC ait une information en temps réel et complète sur l'état de l'équipement.
3.2 Sans agent
La diversité des équipements supportés fait qu'il n'est pas toujours possible d'avoir un agent pour chaque type d'équipement, même si certaines solutions utilisent des agents Java pour supporter un maximum d'équipements, l'agent n'est réellement efficace que s'il est capable d'adapter ses tests aux spécificités du système d'exploitation de l'équipement. Pour des équipements avec des systèmes un plus exotiques comme les smartphones et tablettes, la solution sans agent est donc généralement préférée.
Dans le cas d'une validation de l'équipement sans agent, des tests sont effectués par le serveur NAC généralement à l'établissement de la connexion. Il s'agit d'identifier les ports réseaux ouverts et les éventuelles vulnérabilités qui pourraient y être associées par exemple via un outil comme OpenVAS pour une solution NAC open source.
Il est généralement possible via ces tests d'identifier le type d'équipement demandant un accès au réseau et d'appliquer une règle d'isolation différente en fonction de l'équipement. Par exemple : isoler dans un VLAN dédié et limité à la téléphonie, un équipement détecté comme un téléphone VOIP.
Fig. 3 : Exemple de règles d'isolation en fonction du type d'équipement détecté
Les tests effectués à l'établissement de la connexion étant par nature bien plus légers que ceux qui auraient pu être effectués par un agent, la solution est généralement liée à un équipement réseau jouant le rôle d'IDS (Intrusion Detection System) afin de détecter des équipements dont le comportement sur le réseau indiquerait une éventuelle infection et bloquer leurs accès réseaux en temps réel.
4. La mise en pratique
4.1 Les solutions existantes
Comme pour toute technologie relativement nouvelle, différents acteurs proposent leurs solutions avec des positionnements relativement différents.
Côté open source, une solution sort du lot : PacketFence [3], qui propose une solution relativement complète sans agent se basant en intégrant des projets reconnus dans leurs domaines respectifs : OpenVAS pour la recherche d'équipements vulnérables et Snort pour la partie IDS. Il manque encore un système d'agent qui pourrait tout à fait être développé en suivant les standards NAC ouverts définis par le TCG (Trusted Computing Group) dans les normes Trust Network Connect [4].
Côté équipementiers réseaux, les fabricants habituels d'appliances Firewall proposent aussi leurs solutions NAC. Habitués des solutions IDS, ils proposent généralement des solutions sans agent performantes mais pêchent généralement du côté de l'agent.
Côté éditeurs de solutions antivirus, on retrouve plus ou moins la philosophie inverse. Habitués à déployer des agents de plus en plus complexes sur différents systèmes d'exploitation, ils proposent généralement les solutions avec des agents plus aboutis souvent au détriment de l’intégration avec les équipements réseaux existants.
À noter également que dans un environnement Microsoft Windows, les versions serveurs du système d'exploitation (depuis 2008 server) intègrent NAP qui joue un rôle de NAC avec, chose assez rare au niveau de la firme de Redmond pour être soulignée, des clients pour les systèmes d'exploitation concurrents GNU/Linux et Mac OS X.
4.2 Intégration à un environnement réseau existant
4.2.1 Côté infrastructure
La plupart des switchs et points d'accès Wi-Fi étant nativement compatibles avec la technologie 802.1X, aucun changement n'est nécessaire, il suffit juste de configurer les équipements afin qu'ils utilisent le NAC comme serveur d'authentification 802.1X. Il sera aussi parfois nécessaire de segmenter un peu plus le réseau sans fil de manière à créer des associations SSID/VLAN physiques permettant des règles de filtrage plus simples au niveau des firewalls qui ne seront pas instrumentés par le NAC.
Fig. 4 : Exemple d'intégration d'une appliance NAC à un réseau Wi-Fi existant
4.2.2 Côté client
Suivant les politiques de sécurité et solutions NAC retenues, il peut être nécessaire d'installer un agent NAC sur les clients lourds. Pour les smartphones, il est possible d'authentifier les équipements via certificat, mais l'utilisation du login et mot de passe de l'utilisateur dans l'annuaire reste une alternative tout à fait valable. Dans ce cas, l'utilisateur ne verra que très peu de modifications, il aura juste à utiliser son login et son mot de passe habituel à la place d'une passphrase Wi-Fi.
Fig. 5 : Authentification Wi-Fi 802.1X sur smartphone Android
Conclusion
Que ce soit pour gérer plus efficacement de nouvelles menaces ou pour mettre en place des politiques de sécurité adaptées au BYOD, les solutions NAC proposent des solutions intéressantes sans pour autant être encore totalement abouties. Il est donc nécessaire d'aller au-delà de l'effet de mode du moment et s'armer de patience avant de mettre en place une solution adaptée à ses contraintes.
Liens
[1] RFC 3748 – Extensible Authentification Protocol : http://tools.ietf.org/html/rfc3748
[2] Open1X – 802.1X supplicant open source : http://open1x.sourceforge.net
[3] PacketFence – NAC open source : http://www.packetfence.org
[4] Trust Network Connect – standard ouvert du Trusted Computing Group : http://www.trustedcomputinggroup.org/developers/trusted_network_connect
