Résumé

Les règles d’accès aux réseaux des entreprises sont de plus en plus contraignantes, tant en raison du haut niveau de sécurité exigé des systèmes qu’en raison de la mobilité des utilisateurs. Le contrôle d’accès au réseau est donc un point crucial qu’il convient de mettre en œuvre et la mise en quarantaine des clients est l’une des solutions que nous préconisons dans ce cadre. Dans cet article, nous détaillons la procédure générale du contrôle d’accès et les différentes solutions de quarantaine existantes actuellement disponibles. Notre proposition de quarantaine à la «volée» qui allie filtrage des utilisateurs et rétro-contrôle par la métrologie de leurs flux est ensuite exposée. En conclusion nous décrivons les diverses stratégies applicables dans le cadre d’une analyse détaillée des flux réseaux.

Mots clefs

Métrologie, filtrage, authentification, quarantaine, NAC.

1Introduction

Les réseaux d’entreprise ont connu, au fil des années, de nombreuses évolutions qui répondent au double objectif de renforcement de la sécurité et d’offre de nouveaux services. La coopération entre organismes et la venue d’intervenants extérieurs obligent nos réseaux à accueillir un nombre sans cesse croissant d’utilisateurs mobiles. Cette nouvelle contrainte conduit les administrateurs systèmes et réseaux à mettre en œuvre des solutions pour contrôler les accès et garantir l’intégrité du système d’information interne. Depuis plusieurs années, des évolutions multiples ont vu le jour en matière de contrôle d’accès, de filtrage et/ou de cloisonnement des systèmes informatiques et sont maintenant accessibles sur la majorité des produits du marché. Dans cet article, nous décrirons le cadre général du contrôle d’accès dans la section 2 et détaillerons les différentes solutions de mise en quarantaine des systèmes informatiques dans la section 3. Nous présenterons également, au sein de la section 4, une proposition qui allie analyse du trafic réseau en temps réel et zone de quarantaine afin de prévenir, le cas échéant, les incidents et/ou utilisations non conformes du réseau. En conclusion, nous proposerons les diverses stratégies applicables dans le cadre d’une analyse détaillée des flux réseaux.

2Le contrôle d’accès

Le contrôle d’accès est une procédure qui permet d’authentifier un utilisateur ou un système informatique lorsque ces derniers souhaitent accéder à une infrastructure réseau [1] et de leur donner les autorisations nécessaires. Les premières solutions de pseudo-contrôles d’accès étaient fondées sur le détournement de l’utilisation première d’un serveur DHCP [2]. Les administrateurs effectuaient à posteriori, grâce à des outils de scrutation, une analyse permettant de détecter les intrusions ou les anomalies. Bien que très basique, ce type de contrôle d’accès est toujours d’actualité pour les réseaux locaux des organismes en raison des difficultés de mise en place des autres solutions d’authentification.

Néanmoins, de nouvelles solutions ont vu le jour, telles que le contrôle d’accès par adresse MAC des systèmes (MAC-Based), le contrôle d'accès via un portail captif web (WEB-Based) ou l’authentification 802.1X. Après avoir présenté le cadre général de l’accès au réseau, nous décrirons les deux solutions que nous avons retenues, pour le contrôle d’accès aux ressources du réseau informatique.

2.1Le cadre général de l’accès au réseau

La Figure 1 présente le cadre général pour la mise en œuvre des solutions associées au contrôle d’accès. Nous définissons ainsi :

• Un client réseau : c’est un système qui nécessite un accès aux ressources réseaux et systèmes, comme par exemple un client Windows, Unix, Linux, une imprimante, un disque en réseau, un téléphone IP, etc...

• Un commutateur : il est généralement dénommé NAS pour « Network Access Server », ou « point d'accès réseau » qui peut intégrer des fonctions de contrôle d'accès. En effet, de très nombreux commutateurs disponibles sur le marché offrent des fonctionnalités permettant l’authentification des clients réseaux.

• Un serveur RADIUS : il s'agit du serveur d’authentification.

• Un serveur LDAP : il s’agit d’une base d’authentification fondée sur un annuaire intégrant des éléments d'authentification.

• Un serveur DHCP : ce serveur permet d’attribuer dynamiquement une adresse IP à un client réseau.

• Un Portail Captif : redirige la première requête web d'un usager sur une page d'authentification qui doit être validée pour acceder au réseau.

Figure 1: Cadre général du NAC

Il s’agit dès lors, en présence des éléments que nous venons de décrire ci-dessus, de présenter les solutions de contrôle d’admission, les autorisations qui peuvent être données aux clients et les solutions de quarantaine lors d’une procédure de «contrôle d’accès au réseau».

2.1.1Le NAS

Le client RADIUS ou NAS se charge de filtrer les connexions en entrée. Il contraint l'utilisateur à saisir ses identifiants de connexion et les communique en mode sécurisé à un serveur RADIUS. Dans notre article, le commutateur fera office de NAS. Indépendamment de la configuration matérielle retenue, le contrôle d’accès s’effectuera par la configuration des ports du NAS [3].

Pour authentifier les clients réseau, nous décrivons ci-après, un élément clé du contrôle des accès : le serveur RADIUS comme outil de contrôle de la validité des droits d’accès des clients.

2.1.2Serveur d’authentification RADIUS

Le protocole RADIUS est un protocole d'authentification standard et de comptabilisation du trafic entre un NAS et un serveur RADIUS relié à une base d'identification : base de données, annuaire, fichiers locaux, etc... Ce protocole utilise trois types de messages : authentification (vérification de l’identité d’un client), autorisation (droits accordés au client, par exemple le VLAN id) et comptabilisation des informations durant une session (date de connexion, durée de session, trafic entrant et sortant etc….).

Lors d’une tentative d’authentification, le RADIUS peut retourner au NAS un certain nombre d’attributs-valeurs [3] pour permettre le basculement du client réseau dans le VLAN prédéfini. Selon le constructeur de l’équipement, il est également possible d’imposer un filtrage du trafic IP au client réseau. Par exemple, pour affecter un client sur un VLAN prédéfini «189», les attributs suivants doivent être transmis depuis le RADIUS vers le NAS avec les valeurs suivantes : Tunnel-medium-Type:=IEEE-802, Tunnel-Type:=VLAN, Tunnel-Private-Group-Id:=189.
Avec ces valeurs, le NAS basculera le port de connexion du client sur le VLAN 189. Des attributs propriétaires (Vendors Specific Attributs) permettent d'adapter la configuration du NAS en fonction des autorisations à accorder au client. Sur les matériels HP, l'attribut  HP-IP-FILTER-RAW  permet de mettre en place une règle de filtrage (ACE¹) qui sera appliquée au trafic entrant du client sur le port du NAS. Ainsi, les attributs-valeurs permettent d’adapter la connexion du client réseau, indépendamment de ce dernier, aux ressources auxquelles il peut prétendre : un téléphone IP aura besoin du VLAN de la ToIP et de trafic prioritaire par exemple, un client ordinaire sera redirigé dans le VLAN de son groupe habituel sans restriction.

Après avoir énoncé les solutions et les principes généraux, nous détaillons ci-après le fonctionnement des trois solutions majeures d’authentification. Ces trois solutions sont présentées par le schéma de la Figure 2.

2.2Authentification WEB-based

L’authentification par le biais d’un navigateur Internet est certainement la plus simple à mettre en œuvre. Ce type d’authentification est largement utilisé dans les espaces « libre-service » afin que les clients extérieurs puissent avoir accès au réseau sans avoir à paramétrer leur système. La méthode d’authentification s’effectue par le biais d’un navigateur Internet sur lequel le client réseau est invité à saisir un nom d’utilisateur et un mot de passe. Lorsque l’authentification est validée, le trafic réseau du client peut circuler sur le réseau interne. Deux formes d’authentifications « Web » existent : le « Web-Based» intégré au NAS et le portail captif. Ces deux solutions présentent des avantages quasiment identiques, mais celle réalisée via un portail captif autonome reste plus souple quand à sa mise en œuvre et à sa configuration [4].

Figure 2: présentation des 3 solutions connues

Il est à noter que pour cette solution, il est nécessaire de prendre en compte l’expiration du bail de l’adresse IP du client réseau si celui-ci doit être redirigé sur un autre VLAN avec une adresse IP différente. Nous proposerons une alternative à cette problématique dans la section 5.

2.3Authentification MAC-BASED

Ce mode d’authentification permet de rendre très souple la configuration des NAS [3], car la procédure de contrôle est fondée sur l’adresse physique (MAC) du client réseau. Ce mode de contrôle des clients n’est pas le plus sécurisé, mais offre une certaine facilité de mise en œuvre dans un environnement existant. Dans ce cas, l’adresse MAC servira d'identifiant de référence pour l’authentification sur le RADIUS. En cas de succès ou d’échec de l’authentification, les attributs-valeurs permettent d’orienter le client vers un VLAN prédéfini.

Nous considérons que l’authentification par adresse MAC convient parfaitement aux clients qui ne peuvent fournir d’authentifications interactives telles que les téléphones IP, les imprimantes, les postes nomades, etc. En raison du nombre de clients potentiels, l’utilisation d’une base de données pour l’authentification est particulièrement conseillée.

2.4Authentification en 802.1X

Ce mode d'authentification diffère des deux solutions précédentes en ce qu'il nécessite la mise en place d'une Infrastructure de Gestion de Clefs (serveur PKI sur la Figure 2) [5]. Cette méthode requiert la création de certificats qui permettront d'authentifier les clients de manière unique. Un certificat dit "client" est installé sur le client réseau. Lors de la connexion, seuls sont autorisés les échanges relatifs à la validation du certificat. Après validation de ce dernier par le serveur Radius, le client est autorisé à se connecter, sous réserve des restrictions d'accès qui peuvent lui être imposées lors de la phase d'échange des autorisations entre le NAS et le Radius.

Après avoir présenté les trois grandes solutions d'authentification et de contrôle d'accès et sachant qu'il est possible à tout moment de connaître la localisation d'un client sur le réseau, nous pouvons désormais proposer une solution de mise en quarantaine des postes clients, fondée sur le MAC-BASED. Cette localisation d’un client réseau, via son port et son équipement de rattachement, peut s’opérer soit à partir des traces disponibles dans la base de données du Radius et/ou du portail captif, soit grâce à une recherche récursive (en SNMP[6]) sur les équipements réseau.

3Solutions de quarantaine

Comme énoncé dans la section 2, les clients qui se connectent peuvent être authentifiés sur un réseau. Nous considérerons ici les clients authentifiés et reconnus qui doivent avoir accès aux différentes ressources de l’organisme. Ces clients dont la mobilité varie doivent faire l’objet d’un contrôle strict afin d’éviter une compromission de la sécurité du système d’information de la structure qui les héberge. Ce contrôle doit s’effectuer dans une zone réseau tampon : la zone de quarantaine. Dans cette dernière, les accès sont limités et n’autorisent que l’évaluation et les mises à jour logicielles (anti-virus, système d’exploitation, …). Nous décrivons dans les paragraphes suivants les deux principales méthodes de mise en quarantaine.

3.1Quarantaine par vlan dédié

La « quarantaine par VLAN dédié », présentée Figure 3, consiste à cloisonner le client réseau dans un VLAN dédié dès sa demande de connexion.

Figure 3: quarantaine par VLAN dédié

La procédure de mise en quarantaine est la suivante :

• Etape 1 : le client demande l’accès au réseau, via le NAS.

• Etape 2 : le serveur RADIUS contrôle l’accès et change l’assignation du port du NAS sur le VLAN de quarantaine.

• Etape 3 : le client réseau qui n’a accès qu’aux fonctionnalités proposées sur le VLAN de quarantaine est contrôlé et éventuellement mis à jour.

• Etape 4 : le client réseau est conforme à la politique informatique interne et la fin de la quarantaine est décrétée. Le serveur de quarantaine informe le NAS pour une nouvelle assignation de VLAN sur le port de connexion. Le client accède désormais au réseau local de l’organisme.

Au sein de la zone de quarantaine, le client demeure cloisonné si son système n’est pas conforme à la politique générale de l’organisme. Le contrôle par le serveur de validation logiciel s’effectue par le biais d’un agent installé sur le client réseau. Une fois connecté et authentifié, cet agent établit un dialogue avec le serveur de validation afin de vérifier que les pré-requis nécessaires à la libération du client soient réunis. Dans le cadre de l'utilisation d'un agent logiciel libre, nous pourrions opérer ce contrôle en nous basant sur la liste (non exhaustive) suivante : système d’exploitation (version et patchs correctifs), anti-virus (présence et version de la base de définition virale à jour), logiciels (présence de logiciels non-conformes à la politique de l’établissement tels que Skype, p2p, bots, …), analyse spécifique (analyse de certaines clefs du registre spécifique pour les clients Microsoft Windows).

3.2Limites de la quarantaine par VLAN dédié

L’utilisation d’une zone de quarantaine, en amont de l’ouverture des accès réseau, permet de contrôler la conformité du client avant l’ouverture des accès. Cette méthode, bien qu’efficace, ne permet pas à elle seule de garantir totalement l’intégrité du système d’information. En effet, la quarantaine « par VLAN dédié » est un contrôle à un instant T et dès lors que l’accès au réseau est accordé, elle n’assure plus l’évaluation du client au cours de son activité. Une compromission du client préalablement évalué en zone de quarantaine ne serait détectée qu’en cas de nouvelle demande d’authentification et de connexion. Pour pallier cet inconvénient, il est nécessaire de réévaluer, périodiquement le client et/ou d’analyser son activité sur le réseau.

Dans l’hypothèse d’un contrôle initial unique et après avoir été validé en quarantaine, un utilisateur pourrait installer un logiciel non-conforme (Skype par exemple). Nous serions alors dans un cas de figure totalement incohérent. En effet, bien que tous les pré-requis aient été validés lors du contrôle initial, le client ne répondrait plus à ces derniers au cours de sa session. La quasi-totalité des solutions propriétaires proposées sur le marché (Cisco [7], Juniper [8], Qualys [9]) offrent cette modalité de rétro-contrôle logiciel et permettent le redéploiement dynamique d'une nouvelle politique de sécurité : ACL pour les pare-feux, droits du client sur son poste, etc..

Nous décrivons ci-dessous une méthode de cloisonnement par filtrage IP qui évite le renouvellement du bail de l’adresse IP du client réseau, lors du changement de VLAN.

3.3Quarantaine par filtrage

Dans l’hypothèse où l'utilisation d’une zone spécifique de quarantaine ne serait pas jugée pertinente, il pourrait être envisagé de limiter les accès du client au sein du VLAN sur lequel il est connecté. Cette limitation des accès des clients non conformes à la politique informatique de l’établissement pourrait s’opérer au moyen de listes de contrôles (ACLs) [3]. Ces dernières permettent en effet de définir, pour chaque port du NAS, des règles spécifiques de filtrage des paquets IP émis ou reçus par le client. Le client serait alors confiné dans une « quarantaine par filtrage » qui ne donnerait accès qu’à certaines ressources. Cette solution permet également de s’affranchir des problèmes liés au changement d’adresse IP du client dans l’hypothèse où ce dernier n’utiliserait pas un service DHCP.

La solution de quarantaine par filtrage est à privilégier lorsque les clients sont très mobiles (intervenants extérieurs, personnels de l’entreprise itinérants, etc…) et qu'un contrôle logiciel est difficilement applicable. En effet, le confinement de ces clients dès la demande de connexion garantit la sécurité des systèmes informatiques et ce quel que soit le lieu de connexion au réseau. De même, il pourrait être envisagé de limiter le trafic entrant et/ou sortant sur certains postes clients.

Nous avons opté pour l’utilisation de la métrologie du LAN pour effectuer des contrôles. Cette solution est à retenir en complément de l’utilisation des solutions propriétaires qui imposent l’installation d’agents sur les postes clients. Ce contrôle peut être opéré soit au moyen d’une sonde réseau liée au routeur de bordure [10], soit par vérification du trafic émis par le poste client [11].

4Utilisation de la métrologie du LAN

Nos réseaux d’entreprise sont soumis à des contraintes de performance toujours plus élevées. Dans ce contexte les incidents peuvent être lourds de conséquences en terme de fonctionnement. Aussi est-il indispensable de superviser le trafic réseau afin de maintenir une qualité de service optimale. Cette supervision, sur un réseau commuté, doit être effectuée sur chaque NAS afin de disposer d’éléments précis sur le trafic de chaque client connecté. Dès lors, il devient possible de mettre en évidence les anomalies de fonctionnement et/ou les comportements suspects des clients et de planifier des actions automatiques (ou semi-automatiques) en réponse.

Cette proposition de réseau réactif s’appuie sur l’utilisation d'un échantillonnage des flux émis ou reçus par le client réseau durant sa session de connexion. L’utilisation du RADIUS et des tables de contrôles associées permettent de connaître le port de connexion physique d’un client sur le NAS. Cette information couplée à la détection du comportement du client ne respectant pas la politique de sécurité de l’organisme entraînera sa bascule automatique dans la zone de quarantaine, via des scripts et des commandes SNMP.

Nous présentons dans les paragraphes suivants les technologies NetFlow et sFlow qui permettent la collecte du trafic. Nous poursuivrons notre analyse sur l'impact en terme de performance sur les NAS et nous terminerons en détaillant la méthode utilisée pour contrôler les clients de notre réseau.

4.1Définition du NetFlow/Sflow

Un flux est défini par un ensemble de paquets ayant la même origine, la même destination et des caractéristiques communes (port source, port de destination, protocole, etc…). L'analyse des flux permet d'opérer :

• L'édition de statistiques sur l'utilisation des protocoles, des ports et des applications.

• La recherche de DoS.

• L'analyse du trafic pour le prévisionnel d'évolution des liens réseaux, analyse de la Cos et/ou de la Qos

• La détection d'incidents ou de mauvaise configuration, détection de scan horizontaux ou verticaux

• La détection de nouveaux services du réseau, etc..

Il existe deux grandes catégories de flux réseau, le NetFlow et le sFlow. Ces deux types de flux différents trouvent leurs fonctionnalités regroupées dans l'IPFIX [12] qui devient le standard pour l'export de flux d'information des routeurs, des sondes et des commutateurs. La base de ce standard est le NetFlow V9 de Cisco, dont les fonctionnalités ne seront pas détaillées ici.

Concrètement, un flux qui contient les informations relatives aux éléments qui transitent par un équipement (routeur, NAS, …) est émis à destination d'un collecteur.

• Avec les NetFlows, le flux sera émis lorsque l'équipement aura détecté la fin de la session du trafic IP.

• Avec les sFlow (voir Figure 4), le NAS échantillonne le trafic passant sur un port selon une configuration de type : un paquet tous les N paquets circulant sur l’interface de connexion d'un client du NAS sera pris en compte et émis vers le collecteur. Il est à noter que ce mode d'échantillonage fonctionne aussi désormais dans le NetFlow v9 [13].

Figure 4: collecteur sFlow

Dans la solution retenue, il s'agit d'associer les adresses IP sources et destinations avec les ports sources et destinations. Nous décrirons l'utilisation de ces informations dans la section suivante et plus précisément par l'analyse des sFlows.

4.2Utilisation des flow

Il est possible dans un réseau local de répertorier tous les serveurs et les services qui sont fournis sur le réseau. Ainsi, en analysant la destination de chaque paquet échantillonné de manière automatique (programme en perl, php, etc..), il est facile de repérer les comportements suspects en les isolant du trafic réseau normal. La détection du comportement douteux est opérée quasi-instantanément et il est possible d'augmenter la supervision du trafic entre deux « clients » grâce à une re-programmation de l'agent de collecte [11] de flow du NAS qui connecte les clients réseau. Il est ainsi possible de vérifier les intentions des clients réseau lorsque l'on est en présence d'un trafic jugé potentiellement malveillant [14].

Les évènements suivants peuvent être détectés au moyen de l’analyse du réseau local par le biais du collecteur de flow : mauvaise configuration d’un client, scrutation de ports, DoS, P2P, botnet.... Dans l'exemple de capture, réalisée à partir d’un cœur de réseau en utilisant la technologie sFlow sur un réseau local (voir Tableau 1), seuls les champs utiles à notre démonstration sont présentés. Le collecteur que nous utilisons est le « sflowtool v3.13 de InMon Corportation » sur un debian etch.

Protocol	Adresse IP SRC	Port SRC	Adresse IP DST	Port DST
1 : udp	192.168.176.20	40000	192.168.176.121	4000
2 : udp	192.168.176.121	4000	192.168.176.20	40000
3 : tcp	192.168.167.44	2652	192.168.162.12	110
4 : tcp	192.168.167.44	2652	192.168.162.12	110
5 : tcp	192.168.162.108	2148	192.168.162.28	8652

Tableau 1: Exemple de capture de trafic sFlow

Il est évident que connaissant l’architecture du réseau et les services offerts, les paquets 1 et 2 font partie d'un trafic normal : ce sont en effet deux téléphones IP qui dialoguent entre eux. Les paquets 3 et 4 correspondent à une communication entre un poste client et un serveur (192.168.162.12). Le dernier paquet (N° 5) semble suspect puisqu’il s’agit d’une communication entre deux machines du même réseau sur des services non répertoriés. Une analyse plus poussée du client de destination (192.168.162.28) peut être réalisée en reconfigurant l’agent sFlow sur le NAS de connexion (voir section 7).

En comparant l’information collectée avec la liste officielle des services réseau, il est possible de déterminer la dangerosité potentielle du client (192.168.162.28). Le même type de processus doit être mis en œuvre pour détecter les anomalies de configuration, voire les tentatives d’attaques. Dans notre exemple, le paquet N°5 correspond à une tentative frauduleuse d’accès au service 8652 (ganglia).

Nous décrivons dans la section suivante la méthode de redirection de nos clients réseaux dans la zone de quarantaine lorsque ceux-ci ont un comportement suspect.

4.3Mise en œuvre

La figure 5 présente l'environnement de notre expérimentation. Notre réseau est exclusivement composé de matériels HP, majoritairement compatibles avec le MAC-Based. Les commutateurs d'ancienne génération non compatibles imposent l’utilisation d’une solution de localisation des postes clients reliés au réseau. Nous utilisons la base de données associée à Cacti [15] afin d'avoir une base contenant les adresses IP de nos commutateurs ainsi que les noms de communauté SNMP permettant la lecture de la MIB SNMP.

Figure 5: Réseau d'expérimentation

4.3.1Activation du sFlow pour le contrôle de la quarantaine

Lorsqu'une machine se connecte sur un commutateur de bordure, deux possibilités s'offrent à nous :

• Si le NAS est MAC-Based et que l'authentification est réalisée via le Radius, l'activation du sflow sur le port du NAS peut s'opérer grâce à la récupération de l'adresse du NAS dans les tables du radius.

• Si le NAS n'est pas compatible avec le MAC-Based ou que le sFlow n'est pas configurable sur ce NAS, alors il convient de configurer le commutateur de niveau supérieur en sFlow. Dans notre cas de figure, les commutateurs situés au sein des centres de calculs sont compatibles avec le sflow et/ou le NetFlow. Connaissant l'adresse IP du client recherché, nous obtenons son adresse MAC par la lecture de la table ARP [16] en SNMP du coeur de réseau. En associant l'information du protocole LLDP [17] et les noms de communautés SNMP répertoriés dans Cacti, il nous est possible de remonter jusqu'au point de connexion, via les informations contenues dans la MIB SNMP BRIDGE [18]. Cette procédure est également opérationnelle en cours d'utilisation puisque l'information de localisation est par définition connue ou peut l'être y compris sur un client non supervisé.

4.4Détection d'anomalies

Nous fondons notre expérimentation sur un réseau local classique dans lequel tous les commutateurs de bordures sont capables de générer des flux sFlow. Tous ces flux sont expédiés au collecteur et sont analysés quasiment en temps réel.

4.4.1Algorithme général

La méthode que nous avons choisie et développée, afin de pouvoir déterminer les anomalies de fonctionnement sur notre réseau local, se décline comme suit :

• Analyse du trafic aux fins de référencement des serveurs et des services offerts sur le réseau. Ce processus est continu et il permet d'ajouter de nouveaux services pendant l'utilisation du système de contrôle des postes clients.

• Filtrage des protocoles tels que le Netbios et ce afin d’éviter la multiplication des alertes. Concrètement, cette opération conduit à la désactivation de l'analyse des paquets ayant comme source et/ou destination le protocole désigné, pour un serveur donné répertorié.

• Après obtention de la liste des serveurs et/ou services, l'analyse du trafic permettant de repérer les incohérences ou le non respect de la politique réseau présente quatre possibilités :

  • Trafic normal entre serveurs : un des services référencés correspond soit au port source, soit au port de destination du trafic.

  • Trafic anormal entre serveurs : aucun des ports source et/ou destination n'est référencé dans la liste des services autorisés et validés. Dans ce cas, une alerte mail est adressée à l’administrateur. En effet, il ne saurait être question de couper l’ensemble des accès en basculant un serveur en quarantaine.

  • Trafic normal entre client et serveur : les services auxquels accède le client (ports de destination selon le sens du trafic) sont référencés dans la liste des services autorisés et validés

  • Trafic anormal entre clients : les clients n’étant pas supposés offrir un service réseau, le trafic entre eux s’avère suspect. Dans ce cas le client est mis en quarantaine si l'on détecte du « scan » ou des échanges trop importants de données de type « illégal ».

4.4.2Remontées d'information

La génération de graphiques liée à l’analyse en temps réel du trafic assure un suivi de l’évolution des flux et permet d’obtenir un historique facilement accessible.

Figure 6: Services du réseau d'expérimentation

La figure 6 met en évidence les services identifiés qu'ils soient nouveaux ou volontairement déactivés.

Figure 7: Analyse comportementale du LAN

La Figure 7 présente le comportement et les différentes formes de trafic des machines sur le réseau d'expérimentation. Les incohérences du réseau sont constatées lors de la génération du « scan » entre machines depuis un serveur ou depuis un poste client.

Détail de la figure 7 et correspondances :

• « Server To Server » : ajout d’un nouveau service non encore validé ou comportement suspect

• « Server To Client » : réponse à un service non encore validé ou comportement suspect

• « Client To Server » : ajout d’un nouveau service non encore validé ou comportement suspect

• « Client To Client » : comportement suspect volontaire ou involontaire

4.5Dans la pratique

La réelle difficulté réside dans la détermination du seuil à partir duquel les accès doivent être coupés et le client basculé en quarantaine. En effet, il s'agit de trouver le juste équilibre entre la garantie d'intégrité du système d'information et la possibilité pour les utilisateurs de disposer des ressources accessibles sur le réseau.

A titre d'exemple, un client faisant du « scan » vers d'autres clients ou serveurs est détecté par les changements successifs de numéro de port de destination ou par le nombre de machines cibles. Dans ce cas, le client doit être réorienté vers la quarantaine en cours d'utilisation. Cette opération s'effectue au moyen d'une procédure de réauthentification du port du NAS selon deux possibilités :

• Filtrage du poste en mettant en œuvre des ACL. Cette solution nous affranchit de la gestion de la problématique du changement de l'adresse IP du client.

• Renvoi direct dans la zone de quarantaine. Il convient, afin de renouveler l'adresse IP du client, d'effecteur un « arrêt-marche » sur le port du NAS. En effet, cette opération est indispensable pour forcer la couche IP à renouveler son adresse IP.

Dans la pratique il est important de disposer des ACLs par groupe de clients afin de pouvoir intervenir rapidement sur le client potentiellement dangereux. Il est à noter qu'un trop grand nombre d'ACLs par port entraine une augmentation très importante de la charge CPU et mémoire du NAS, laquelle peut même le rendre inutilisable. Les constructeurs recommandent à cet effet de limiter l'utilisation des ACLs dynamiques afin de garantir le bon fonctionnement du NAS.

La solution de cloisonnement via les ACLs couplée à la métrologie pour détecter les anomalies ou les tentatives d’attaques permet de disposer d'une solution de quarantaine dynamique. L’utilisation en quasi temps réel des informations sur le trafic du réseau (NetFlow et/ou sFlow) permet de réagir rapidement. Pour éviter le basculement systématique en quarantaine des faux positifs, il convient de se doter d'un dispositif d'affinement par rétro-contrôle. Néanmoins, il est à noter que la charge CPU du NAS ainsi que le temps de traitement des paquets augmentent au regard d'une authentification basique.

5Conclusion et perspectives

Si de nombreuses solutions permettent d’assurer la sécurité des réseaux, il est indispensable avant toute mise en œuvre de prendre en compte les contraintes et attentes spécifiques tant des utilisateurs finaux que des administrateurs réseau et/ou système. La solution ou les solutions retenues doivent assurer un bon compromis entre les attentes des uns en terme de souplesse et de facilité d’utilisation et les exigences des autres en terme de sécurité et/ou de traçabilité.

Le contrôle d’accès aux ressources internes est devenu un enjeu majeur pour les organismes. Nous avons succinctement présenté l’environnement et les solutions liées à un contrôle d’accès au réseau puis, avons décrit la solution de quarantaine pour les clients réseaux équipés d’un agent logiciel. Cette solution qui est l’une des plus abouties en terme de contrôle de poste client est la plus répandue. Le client qui ne respecterait pas la politique informatique de l’organisme ne pourrait prétendre à un accès aux ressources réseaux et services. En revanche, cette solution n’est pas applicable aux clients extérieurs par exemple. Cette restriction explique notre choix de solution d’analyse en temps réel des flux du client et de « pseudo-quarantaine » qui le confine au sein de son Vlan et/ou restreint ses accès à une liste prédéterminée de serveurs.

L’impact de cette nouvelle forme de quarantaine sur le fonctionnement du réseau est minime puisque pour chaque port analysé par un agent sFlow moins de 1/50 de trafic supplémentaire circule à destination du collecteur. La seule variable que nous intégrerons dans les perspectives de notre recherche sera de limiter le nombre d’ACLs par NAS afin d’éviter que la charge CPU ne devienne trop importante. Une analyse approfondie et automatisée des flux nous permettra de mieux déterminer le comportement à risque d’un client du réseau. Les réponses seront soit une mise en quarantaine simple (protégée par un portail captif), soit une quarantaine filtrée (utilisation d'ACLs), soit enfin une quarantaine cloisonnée (basculement dans un vlan dédié). En complément de l'analyse des flux, nous envisageons d'utiliser le logiciel OCS Inventory [19] comme agent libre de contrôle logiciel afin de disposer, dans notre schéma de gestion de la quarantaine, de l'ensemble des moyens de supervision des clients. Enfin et par ailleurs, la localisation physique précise d'un client, pourrait être obtenue en couplant les informations recueillies lors de l'authentification avec celles issues d'une base de données géographique.

Bibliographie

1. Emmanuel Reuter et Nicolas Bonicco. De l'authentification à la mise en quarantaine. SAR-SSI 2008.

2. RFC 2131 - Dynamic Host Configuration Protocol.

3. Web and Mac Authentication for the 2600 series : http://www.hp.com/rnd/support/manuals/2650_6108.htm

4. Installation du portail captif chillispot - http://cric.grenoble.cnrs.fr/SiteWebAuthentification/InstallationChillispot.php

5. Mise en place d’une IGC : http://www.ssi.gouv.fr/fr/faq/faq_igc.html

6. RFC 1157 – Simple Network Management Protocol

7. Cisco NAC – La mise au point du réseau capable de se défendre tout seul - http://www.cisco.com/web/FR/documents/pdfs/tdm/vpn/White_Paper_NAC_fr.pdf

8. Juniper Unified Access Control Agent : http://www.juniper.net/us/en/local/pdf/brochures/1500051-en.pdf

9. QualysGuard - IT Security and Compliance Delivered as a Service - http://www.qualys.com/products/qg_suite/

10. RFC 3954 - Cisco Systems NetFlow Services Export

11. RFC 3176 - InMon Corporation's sFlow

12. RFC 5101 - Specification of the IP Flow Information Export (IPFIX) Protocol. http://www.rap.prd.fr/pdf/IPFIX.pdf

13. Random Sampled NetFlow. http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/nfstatsa.html

14. Extending Network Visibility by Leveraging NetFlow and sFlow Technologies, http://www.networkinstruments.com

15. Cacti http://www.cacti.net

16. RFC 1213 - ipNetToMediaTable.

17. Link Layer Discovery Protocol

18. RFC 4363 MIB BRIDGE http://www.rfc-editor.org/rfc/rfc4363.txt

19. OCS Inventory-ng - http://www.ocsinventory-ng.org/index.php?page=French

1 Access Control Element, faisant partie intégrante d'une liste de règles ou ACL Access Control List

10/10 JRES 2009