ACES. Livrable 3.1. Spécifications Détaillées du Gestionnaire de Contexte

ACES Livrable 3.1 Spécifications Détaillées du Gestionnaire de Contexte

Résumé L objectif du sous projet 3 est de concevoir un système de collecte d informations contextuelles locales, d une part et une interface permettant d abstraire ces données et d y accéder par le biais de requêtes exprimées selon le formalisme M4D4 (c.f. sous projet 2). Ce document est divisé en trois parties. Les deux premières décrivent deux systèmes de collecte des informations cartographiques, la première étant une approche passive, la seconde active. La dernière partie décrit la couche d abstraction de données et l accès aux données concrètes, remontées par les systèmes de collecte. Cette couche d abstraction de données peut donc être perçue comme une implémentation du modèle M4D4.

Table des matières 1 Introduction 2 1.1 Acquisition active............................................. 2 1.2 Acquisition passive............................................ 4 2 Collecte Passive de Données Contextuelles Locales 5 2.1 Présentation de l approche........................................ 5 2.2 État de l art de l approche passive.................................... 7 2.2.1 Publications............................................ 7 2.2.2 Outils commerciaux....................................... 7 2.2.3 Outils open-source........................................ 8 2.3 Architecture générale........................................... 9 2.4 Inventaire des nœuds du réseau...................................... 9 2.4.1 Structures de données concrètes................................. 10 2.4.2 Algorithme de mise à jour des données............................. 11 2.4.3 Implémentation de la sonde................................... 13 2.5 Inventaire de produits........................................... 14 2.5.1 Structures de données concrètes................................. 14 2.5.2 Algorithme de mise à jour des données............................. 15 2.5.3 Implémentation de la sonde................................... 15 2.5.4 Problèmes liés à l identification des logiciels.......................... 17 3 Collecte Active de Données Contextuelles Locales 18 4 Gestionnaire de Contexte 24 4.1 Buts et prédicats.............................................. 24 4.2 Prédicats M4D4 et vues SQL équivalentes................................ 24 4.3 Traduction des prédicats en arbres abstraits............................... 25 4.4 Algorithme de génération d une requête SQL.............................. 26 4.4.1 Phase 1 : liste des variables sélectionnées............................ 26 4.4.2 Phase 2 : liste des tables sélectionnées.............................. 26 4.4.3 Phase 3 : contraintes de jointures................................. 27 4.4.4 Phase 4 : contraintes de valeur littérale.............................. 27 4.4.5 Phase 5 : contraintes de comparaison.............................. 27 4.5 Reste................................................... 28

Chapitre 1 Introduction Les outils de détection d intrusions (IDS) utilisés pour détecter les attaques informatiques génèrent un volume important d alertes, dont le niveau de sévérité est généralement peu fiable. Une manière de réduire le volume des alertes et d améliorer la fiabilité consiste à prendre en compte les propriétés des machines du réseau surveillé (la cartographie). En effet, les informations cartographiques permettent d une part d évaluer la vulnérabilité des hôtes et d autre part de caractériser les hôtes dont la configuration est réputée pour engendrer des alertes non pertinentes, qui représentent une part importante du volume global d alertes. Ces informations cartographiques permettent aussi d assurer la mise en conformité du parc de machines. Enfin, l optimisation de la couverture des systèmes de détection d attaque nécessite aussi une connaissance de la topologie du réseau. Dans un contexte d accroissement constant de la taille, du dynamisme et de l entropie des réseaux, il est indispensable d automatiser la tâche d inventaire des caractéristiques des machines et de la topologie du réseau surveillé. L utilisation de postes nomades et les mises-à-jour régulières des logiciels augmentent encore la dynamique de la cartographie. On peut distinguer deux familles principales de techniques de cartographie des réseaux, l active et la passive. 1.1 Acquisition active L approche active consiste à interroger les machines du réseau pour obtenir leur configuration. Ces interrogations peuvent être adressées à des agents logiciels ad-hoc déployés sur les machines, qui sont chargés de collecter localement les informations cartographiques et de les envoyer à un composant central. Le cas échéant, ces agents peuvent aussi envoyer périodiquement les informations de leur propre initiative. Les interrogations peuvent aussi reposer sur des protocoles dédiés, comme SNMP. Cette approche est détaillée dans le chapitre 3 Les interrogations peuvent aussi être des stimuli envoyés à l ensemble des machines d un réseau depuis un poste central, qui déduit la configuration des machines de l analyse des réponses aux stimuli. La stimulation des composants se fait en initiant des connexions réseau. L ensemble des couches OSI fournissennt des indice pertinents pour découvrir les caractéristiques recherchées. Ainsi, une technique élémentaire permettant de connaître les services présents sur un hôte est le balayage de ports. Le balayage de ports consiste à initier une connexion TCP sur l ensemble des ports de l hôte considéré et observer ceux pour lesquels une connexion est établie. En effet, l établissement d une connexion TCP se fait en trois étapes : le client initie la connexion sur un port donné (SYN) ; si un serveur écoute sur ce port, il accepte la connexion (SYN- ACK) et le client termine l établissement (ACK). Il existe plusieurs variantes du balayage de ports que nous résumons ici : 1. TCP connect : L appel système connect() est utilisé par les systèmes d exploitation vers les machine cibles sur tous les ports cible. Si le port est ouvert, le connect() retournera une valeur valide, sinon le port n est pas atteignable. 2. TCP SYN scanning : souvent référencé comme le balayage half-open, parce qu il n ouvre pas une communication TCP en entier. L auditeur envoie un paquet SYN, comme si il allait ouvrir une connexion réelle ; si la 2

réponse est un SYN-ACK, le port testé est bien ouvert et l auditeur répond en envoyant un RST pour éteindre la connexion. 3. TCP FIN scanning : Cette technique utilise la spécificité suivante du protocole TCP : les ports fermés repondent à un paquet FIN avec un paquet RST, alors que les autres ports (ceux ouverts) ignorent les paquets. 4. UDP ICMP port unreachable scanning : technique qui utilise le protocole UDP et le message d erreur ICMP_PORT_UNREACH. Une machine envoie une erreur ICMP_PORT_UNREACH quand un paquet est envoyé sur un de leurs ports fermés. Ainsi, on peut savoir quels ports ne sont pas ouverts, donc en déduire quels sont ceux qui le sont. Cette technique a le désavantage d utiliser le protocole UDP qui n oblige pas les machines à émettre un acquittement à tous paquets reçus (en fonction des protocoles de niveau supérieur). Ces variantes du balayage de ports permettent à l auditeur d être plus ou moins discret. Notons toutefois que nous utilisons ici l acquisition de la cartographie afin de garantir la sécurité du système d information et non à des fins malveillantes. Le problème de la furtivité n a donc pas lieu d être. En associant la liste des ports ouverts obtenue par balayage à une base de donnée des logiciels réputés pour écouter sur les ports considérés, il est possible d en déduire le type de logiciel présent sur l hôte. Bien sûr, ce type d approche n est pas totalement fiable, car une application peut écouter sur un port différent de celui sur lequel cette application écoute habituellement. Rien n empêche par exemple de faire écouter un serveur HTTP sur le port 21, habituellement associé aux serveurs FTP. Les systèmes d exploitation des composants du réseau peuvent aussi être découverts par heuristique. En effet, certaines ambiguités des spécifications du protocole TCP/IP donnent lieu à des implémentations différentes des piles TCP/IP dans les systèmes d exploitation [3, 4]. Différentes versions de systèmes d exploitations peuvent ainsi être reconnues en soumettant au composant audité des paquets forgés, possèdant des combinaisons d options discriminantes dans les entêtes IP et TCP, parmi lesquelles la taille de la fenêtre TCP, le MSS Maximum Segment Size (TCP), le TTL Time To Live, le WS Window Scale, etc. Le balayage TCP évoqué précédemment permet à l auditeur de faire des suppositions plus ou moins fiables sur la nature des services hébergés sur les hôtes mais ne permet pas d obtenir des informations précises sur le modèle ou la version des serveurs. Lorsqu ils sont sollicités, certains serveurs fournissent dans leur réponse leur modèle et leur version. Les résultats obtenus par balayage TCP peuvent ainsi être complétés en soumettant aux services ouverts des requêtes permettant d identifier précisément les serveurs. Un grand nombre d outils open-source ou commerciaux sont disponibles pour effectuer de l acquisition de la cartographie par stimuli. Le plus utilisé est probablement nmap 1. nmap dispose de l ensemble des fonctionnalités décrites précédement pour reconnaître les services et les systèmes d exploitations. L acquisition par stimuli est généralement une fonctionnalité qu offrent les scanners de vulnérabilité comme Nessus 2. En plus des tests présentés ci-dessus, ces outils lancent des attaques contre les services afin d évaluer la vulnérabilité des composants. Bien entendu, les attaques lancées par ces outils peuvent avoir des effets de bord plus ou moins néfastes pour l environnement surveillé. Les tests effectués par Nessus sont sans conséquence lorsqu ils se cantonnent à l acquisition de la cartographie. Cette technique pallie au problème de déploiement à grande échelle posé par l approche à base d agents, car elle ne nécessite pas la présence d agents sur les machines surveillées. Elle introduit cependant de nouveaux inconvénients. Tout d abord, le temps nécessaire à l audit de l ensemble des composants d un réseau et à la mise à jour des informations est important. Par voie de conséquence, l approche est peu adaptée aux changements fréquents de configuration des composants du système d information. De plus, le trafic engendré par l approche est volumineux et les effets de bord inhérents à l approche peuvent s avérer nuisibles pour l environnement surveillé. Un autre inconvénient de l approche est que seuls les caractéristiques recherchées peuvent être découvertes. Une mise à jour régulière de la base de test de l auditeur est donc nécessaire. La base de données de Nessus, par exemple, comprend approximativement 2000 tests. Comme elle fonctionne par interrogation à distance des composants, l approche par stimuli ne peut découvrir que les serveurs. Les applications qui n écoutent pas sur un port ne peuvent pas être découvertes. Enfin, les mécanismes de filtrages (comme les pare-feux par exemple) limitent les possibilités de découverte des outils d acquisition par stimuli. 1 http://www.insecure.org/nmap/ 2 http://www.nessus.org 3

1.2 Acquisition passive Par opposition à l approche active, l approche dite passive ne requiert aucune interaction avec les composants audités. Elle consiste à découvrir la cartographie d un réseau uniquement en observant les communications entre les composants d un réseau. Dans le cadre du projet ACES, nous proposons d exploiter les approches actives et passives. Les chapitres 2 et 3 de ce livrable leurs sont respectivement dédiées. Le chapitre 4 décrit le gestionnaire de contexte, chargé d interpréter les requêtes émanant des modules d analyse d alertes selon le formalisme M4D4 et de les traduire dans le format de données concret utilisé par les différents systèmes de collecte des informations cartographiques. 4

Chapitre 2 Collecte Passive de Données Contextuelles Locales 2.1 Présentation de l approche La collecte passive d informations contextuelles locales consiste à identifier des données cartographiques et topologiques sur le système d information uniquement par l écoute du trafic réseau. L analyse des interactions entre un client et un serveur révèle en effet un certain nombre de caractéristiques sur la structure du réseau et les machines, ainsi que sur les applications que ces dernières hébergent. A titre d illustration, considérons les figures 2.1 et 2.2, qui représentent respectivement le contenu d une requête HTTP d un client adressée à un serveur et la réponse de ce dernier. On constate que la requête contient le type de navigateur (MSIE 6.0) utilisé par le client pour effectuer sa requête et le type de système d exploitation (Windows NT 5.1). La réponse contient quant à elle le type de serveur Web (Apache). Bien entendu, l annonce de ces données est laissé à la liberté des protagonistes ; elles peuvent donc ne pas être fournies, ou bien forgées afin de tromper les systèmes de collecte passive. On supposera que la plupart du temps, ces données, lorsqu elles sont disponibles, sont valides. Il est en effet peu probable que les utilisateurs légitimes d un système d information se préoccupent de modifier les annonces effectués par leurs logiciels auprès des serveurs. L approche passive présente un certain nombre d avantages par rapport aux approches actives : Innocuité : contrairement aux approches actives, l approche passive n engendre aucun effet de bord néfaste sur le réseau. Outre le trafic réseau additionnel inhérent aux approches actives, certaines requêtes effectuées peuvent parfois engendrer des dénis de service sur certaines applications ou équipements réseau. Par principe, la collecte passive ne génère aucun trafic sur le réseau et écoute simplement le trafic par le biais d une interface réseau dédiée. Rapidité : la cartographie d un réseau de grande taille par les approches actives peut s avérer extrêmement longue car il est nécessaire de stimuler l ensemble des ports de l ensemble des adresses IP d une plage donnée, sans compter que certains équipements de filtrage dans le réseau peuvent ralentir encore le processus, en ne répondant pas aux stimuli, ce qui impose à la sonde d attendre l expiration des connexions pendantes. À l inverse, la collecte et la mise à jour des données cartographiques par approche passive se fait au fil de l eau. Réactivité : la fraîcheur des informations cartographiques fournies par des approches actives correspond à l état du réseau découvert lors de la découverte précédente. Compte tenu du temps nécessaire à la découverte de grands réseaux et du trafic important engendré (qui incite les administrateurs à exécuter les découvertes en dehors des heures travaillées pour ne pas perturber l utilisation du réseau par les utilisateurs), la période entre deux découvertes peut être très importante. À l inverse, la découverte d une information par approche passive se fait «au plus tôt», c est-à-dire à la première sollicitation d un service par un client. Simplicité : les sondes passives ne nécessitent aucune infrastructure spécifique et sont simples à installer et à maintenir dans un réseau. Une seule sonde permet de découvrir les caractéristiques d un ensemble de machines dans un réseau (à condition que sa localisation dans le réseau le permette). En fonction de la taille du réseau, 5

http://internalserver/ IP TCP HTTP GET / HTTP/1.1\r\n Accept: application/vnd.ms-powerpoint,... Accept-Language: fr\r\n Accept-Encoding: gzip, deflate\r\n User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: intranoo\r\n Connection: Keep-Alive\r\n FIG. 2.1 Requête du client 200 OK IP TCP HTTP HTTP/1.1 200 OK\r\n Response Code: 200 Date: Wed, 25 Aug 2004 08:53:50 GMT\r\n Server: Apache\r\n Last-Modified: Tue, 11 May 2004 07:46:20 GMT\r\n Accept-Ranges: bytes\r\n Content-Length: 300\r\n Keep-Alive: timeout=15, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html\r\n FIG. 2.2 Réponse du serveur quelques sondes sont alors suffisantes pour obtenir une couverture du réseau. Les approches orientées agents, au contraire, nécessitent le déploiement d agents logiciels sur l ensemble des machines d un réseau, ce qui s avère d autant d autant plus difficile dans les réseaux où cohabitent des systèmes hétérogènes (voire impossible sur certains équipements spécifiques comme les imprimantes ou les équipements d interconnexion). Capacité de découverte : par définition, les sondes actives découvrent au plus ce qu elles cherchent explicitement. Les sondes passives, au contraire, permettent de découvrir des caractéristiques spécifiques de manière relativement générique. De plus, l approche passive permet d analyser les deux interlocuteurs d une communication et par conséquent découvrir des caractéristiques propres au client, contrairement aux approches actives qui ne peuvent solliciter que les serveurs. Malgré tout, la collecte passive n est pas exempte d inconvénients inhérents à l approche : Trafic chiffré : l approche passive analysant le contenu et les entêtes des trames à différent niveaux des couches protocolaires. Par conséquent, l utilisation du chiffrement limite considérablement les capacités d analyse des sondes passives. Les approches actives ou par agents ne sont pas impactées par le trafic chiffré, puisque la sollicitation des service se fait à l initiative des sondes. Réactivité : la réactivité a été évoquée parmi les avantages de l approche passive car les informations sont découvertes «au plus tôt». On peut toutefois objecter que les caractéristiques peuvent aussi être détectées «au plus tard», si la première sollicitation correspond à une attaque. Volume de trafic : à l instar des sondes de détection d intrusions réseau (NIDS), les sondes passive peuvent être fortement contraintes par le volume de trafic à analyser. Si ce volume est trop important, la sonde est susceptible de perdre des paquets et ne pas découvrir certains services. On notera toutefois que l impact de la perte de paquets par une sonde passive est moins important que dans le cas des NIDS car il ne s agit pas de détecter des attaques, mais des informations cartographique. De plus, il est probable qu une découverte rendue impossible par la perte d un paquet ne soit en réalité que repoussée à plus tard (en l occurrence à la prochaine sollicitation similaire du service). 6

Présence d éléments perturbateurs : certains éléments dans le réseau sont susceptible d introduire des erreurs dans les observations effectuées par les sondes passives. Par exemple, une sonde située en amont d un machine effectuant de la translation d adresse engendre des erreurs d identification des machines. Qualité des informations découvertes : les observations fournies par les sondes passives sont généralement de moins précises que les approches actives ou par agents. Les observations peuvent être aussi entachées d erreurs ou d incertitudes. Ceci est principalement lié au fait que les sondes passives sont tributaires du contenu sollicitations analysées, contrairement aux approches actives qui choisissent les stimuli adressés aux machines auditées. La qualité parfois médiocre des observations est aussi liée à la nature même des éléments utilisés pour identifier des caractéristiques cartographiques. Ces éléments peuvent en effet être ambigus, erronés, ou non fiables. Dans la suite de ce chapitre, nous décrivons le fonctionnement de la sonde passive développée dans le cadre de ACES et l architecture logicielle. La sonde passive permet d identifier trois catégories d informations que nous détaillons ci-après : inventaire des nœuds machines sur le réseau, type et version des systèmes d exploitation, type et version des logiciels client/serveur. 2.2 État de l art de l approche passive Il existe peu de publications sur l acquisition passive. En revanche, plusieurs produits open-source et commerciaux proposent des fonctions d acquisition passive, mais qui souffrent encore d inconvénients. Nous évoquons d abord les quelques publications dont nous avons connaissance sur le sujet, puis nous énumérons les caractéristiques d outils commerciaux et open-source. On pourra se référer à une page dédiée à l acquisition passive pour une brève synthèse des outils disponibles (http://www.networkintrusion.co.uk/osfp.htm). 2.2.1 Publications Dans [6], Dayioglu et Ozgit décrivent l utilisation d informations cartographiques obtenues passivement avec des alertes issues de NIDS (Network-based Intrusion Detection Systems). L outil est un module greffé à Snort qui utilise des attributs de TCP discriminants afin de deviner le système d exploitation des composants. La taille de la fenêtre TCP, la valeur de TTL, le drapeau de fragmentation sont des exemples d attributs dont les valeurs varient en fonction des systèmes d exploitation. Dans une publication récente, Webster et al décrivent un outil d acquisition passive baptisé LANscape [5]. L outil est composé de quatre composants. Une sonde est responsable du suivi de l état des connexions TCP afin de découvrir les ports ouverts. Un composant est chargé d agréger les informations issues des sondes et mettre à jour les informations stockées dans le composant de stockage. Enfin, le quatrième composant est chargé de la visualisation des informations découvertes. Cette publication offre des enseignements pertinents sur des problèmes intrinsèques de l approche rencontrés. Par exemple, les auteurs évoquent les difficultés rencontrées avec les ports transitoires. Certains services, comme par exemple FTP, ouvrent des ports élevés (> 1024) aléatoires 1, qu ils se communiquent sur un canal de commande le temps d échanger des données. Une fois l échange terminé, le port est refermé par l une ou l autre des parties. Cependant, du point de vue de la sonde passive, le port est encore ouvert. Les serveurs mandataires (proxies) engendrent le même type de problèmes. 2.2.2 Outils commerciaux Les solutions commerciales d acquisition passive sont d autant plus onéreuses que l audit de réseaux de grande taille nécessite une multiplication des sondes pour auditer l ensemble du réseau et que le prix individuel des sondes est élevé. Les deux produits majeurs du marché sont NeVO [14] et RNA [13]. NeVO est le composant d acquisition passive annexé à la version commerciale de Nessus. Originellement, Nessus est un outil d audit actif, que complète naturellement le composant passif. Le caractère hybride de l approche est intéressant. 1 ou bien demandent au client d ouvrir un port 7

RNA est le composant d acquisition passive annexé à la version commerciale de Snort, baptisée Sourcefire. Snort est un système de détection d intrusions réseau, orienté signatures. Ce type de composant est une extension naturelle d un NIDS, car les techniques utilisées pour reconnaître les attaques, basées sur l étude des effets de bord de ces dernières sur le réseau, sont les mêmes que pour la reconnaissance de services. La maquette prévue dans ce projet exploite d ailleurs aussi les fonctions de reconnaissance et d extraction de motifs d IDS existants. 2.2.3 Outils open-source Il existe un grand nombre de d outils open-source performants, mais qui offrent un champ de fonctionnalités assez retreint ; il manque une infrastructure réunissant l ensemble des fonctions souhaitées. C est là l un des objectifs de notre étude : réutiliser autant que possible les outils existants pour construire un outil capable de remplir l ensemble des fonctions souhaitées de l acquisition passive. On peut découper les fonctions offertes par les outils open-source en deux catégories : la découverte de systèmes d exploitation et la découverte de services. Siphon[7] est un outil rudimentaire de détection de systèmes d exploitation et de services ouverts (au sens TCP). Les réponses positives des serveurs, c est à dire la présence des drapeaux SYN et ACK dans les paquets sont utilisé pour la découverte de services. Archaeoperyx [15] offre une interface graphique pour Siphon. Les développements semblent à l abandon depuis 2000, ainsi que la base de signatures d OS, qui rend l outil obsolete. Pof [8] est un outil de prise passive d empreintes systèmes qui est à l origine d autres outils tels que Ettercap [10] ou bien le module de Prelude [9] dédié à la reconnaissance d OS. La communauté qui contribue au développement est très active et par conséquent ces outils sont à jour pour la reconnaissance des systèmes d exploitations. Au titre des outils capables de reconnaître les systèmes d exploitations, citons aussi pfprintd [11] et Disco [12]. Leurs caractéristiques sont très similaires à celles de pof, nous ne détaillons donc pas plus ces outils. Bien qu il nous intéresse en premier lieu pour ses fonctions de prise d empreinte passive d OS, Ettercap offre d autres possibilités d analyse. Il permet notamment de lister les ports ouverts, les services hébergés et le type d hôte (simple hôte, passerelle ou routeur). La dernière version d Ettercap est très complète, mais la plupart des fonctions font appel à des méthodes d investigation actives. En effet, Ettercap stimule les hôtes en leur envoyant des requêtes et en analysant leurs réponses, ou bien s immisce dans les conversations (Man In The Middle), ce qui implique une interception et une redirection des paquets. Ces caractéristique sont intéressantes, mais elles sont intrinsèquement perturbantes vis-à-vis du réseau surveillé et violent notre contrainte de passivité. De toutes façons, dans notre contexte, nous utilisons la technique passive à des fins d administration du réseau donc, nous supposons donc que la sonde d acquisition est située à un endroit privilégié du réseau où le trafic est accessible à la sonde. Cependant, la nouvelle version de ettercap propose un mode exclusivement passif et est capable nativement d acquérir un grand nombre de caractéristiques, parmi les quelles les adresses IP des machines et leur nom, ainsi que les services ouverts. Le nom des machines est obtenu de manière passive en inspectant les requêtes DNS qui transitent sur le réseau. Dans son mode de fonctionnement passif, Ettercap peut également donner le type de carte réseau, en associant aux trois premiers octets de l adresse MAC son constructeur. Ensuite, selon le mode conventionnel de prise d empreinte, il détermine le système d exploitation des hôtes (actuellement, de l ordre de 1400 signatures sont référencées, tenues à jour par les contributeurs du projet). Enfin, les communications lui permettent de savoir quels sont les ports ouverts (TCP et UDP), en analysant notamment les paquets SYN+ACK, dans le cas de TCP, et d en déduire le fonctionnement vraisemblable de certains services. Ettercap évalue également de manière statistique la fonction de certaines machines (e.g. routeur, passerelle ou simple hôte), grâce aux messages ICMP. Enfin, ettercap présente des interfaces aux différents étages de l analyse, qui permettent de greffer des modules spécifiques. En revanche, Ettercap est incapable de suivre les sessions dans leur intégralité dans son fonctionnement passif. Comme nous le verrons, pour être plus précise, la collecte des informations de cartographie nécessite d analyser les sessions et non seulement les paquets individuels. 8

Données cartographiques conversion SQL Traitement des données tube nommé Sonde d'écoute Sonde passive d'écoute Sonde passive d'écoute passive réseau FIG. 2.3 Architecture de la sonde de cartographie passive La totalité de ces outils se base assez naturellement sur la bibliothèque libpcap pour l acquisition des paquets sur le réseau et bénéficient ainsi de l expressivité des filtres offerts par libpcap. Notons enfin que l ensemble des outils décrits manquent des fonctions nécessaires à la supervision de réseaux de grande taille sur le long terme. Ils ne sont pas intégrés dans une infrastructure globale capable d intégrer les observations de plusieurs sondes, le stockage de ces observations et la mise à jour des observations avec des informations collectées dans le passé. 2.3 Architecture générale L architecture de la sonde passive peut être divisée en trois composants fonctionnels. Le premier composant est responsable de la collecte, du filtrage et de l analyse de bas niveau du contenu des trames réseaux. Le second composant reçoit les événements issus du composant précédent pour consolider les observations, c est-à-dire normaliser et enrichir les observations et détecter les incohérences. Le troisième composant est responsable de la structuration et de la persistance des données cartographiques. La figure 2.3 présente l architecture de la sonde. La fonction de capture et d analyse du contenu des paquets réseaux s appuie sur les outils open-source existants Snort et Ettercap. Ces outils sont modifiés pour les besoins propres de collecte cartographique. Les données collectées par ces outils sont envoyées via un tube nommé au processus de traitement qui, après analyse, envoie ou met à jour les informations dans une base de données relationnelle. Le fonctionnement de ces composants ainsi que les structures de données concrètes auxquelles accède le gestionnaire de contexte sont décrites dans les sections suivantes de ce document. 2.4 Inventaire des nœuds du réseau Dans un contexte sécuritaire, il est primordial d être en mesure d identifier précisément les entités cible et source des attaques. Les entités de base considérées sont les nœuds du réseau, car ce sont les entités actives, chargées d exécuter des processus pour le compte d utilisateurs, et susceptibles d être affectés par des vulnérabilités. 9

On peut noter que le concept même de nœud est ambigu : les failles étant essentiellement logiques, les nœuds à identifier au sein du réseau ne sont pas tant les machines physiques que les entités logiques qui interagissent dans le réseau, c est-à-dire les systèmes d exploitation et les logiciels qu ils hébergent. Si dans la grande majorité des cas les machines physiques n hébergent qu un seul système d exploitation, il peut arriver que des machines soient multi-boot, auquel cas l association entre une machine physique et une entité logique n est plus valable qu à un instant donné. Notons enfin qu avec l utilisation grandissante des techniques de virtualisation (hébergement d une ou plusieurs machines virtuelles au sein d un même système d exploitation), l unicité de l association entre une machine physique et une entité logique n est même plus vraie à un instant donné. Dans le cadre de ce sous projet, nous ne considérerons pas le problème posé par les techniques de virtualisation, jugeant qu elles sont encore suffisamment exotiques. Pour résumer, nous considérerons dans la suite qu un nœud du réseau est une instance de système d exploitation exécuté à un instant donné. L objectif de l inventaire de machine est de collecter les différentes identités des nœuds du réseau, tout en essayant de préserver la cohérences entre ces différentes identités. Les identités considérées dans le cadre de la collecte passive sont les adresses MAC, les adresses IP et les noms réseau. L identification des nœuds du réseau impliqués dans des attaques à partir de ces différentes identités n est pas triviale. Aucune des quatre informations évoquées ci-dessus ne permettent d identifier les nœuds avec certitude car différents phénomènes ou mécanismes présents dans les réseaux peuvent les masquer ou les rendre ambigus : Les noms réseaux sont probablement les identités les plus pérennes et les plus évocatrices d un nœud. Le caractère évocateur d une identité est relatif à l interprétation que peut en avoir un opérateur de sécurité humain, qui est plus à même de connaître une machine par son nom que par son adresse IP et a fortiori par son adresse MAC. L obtention du nom réseau d un nœud à partir d une adresse IP se fait par l utilisation de mécanismes de résolution de type DNS. Cependant, la disponibilité des noms de machines n est pas garantie. En effet, les cas d échec de résolution inverse (c-à-d d obtention d un nom à partir d une adresse IP) sont fréquents. De plus, un nom réseau peut être associé à plusieurs adresses IP distinctes et une adresse IP est associée à au plus un nom réseau. Les adresses IP présentent l avantage d être disponibles de facto dans les trames réseau analysées par la sonde passive, mais leur pouvoir évocateur et leur pérennité sont inférieurs à ceux des noms réseau, notamment du fait de l utilisation croissante du protocole DHCP (Dynamic Host Configuration Protocol), qui rend dynamique l affectation des adresses IP aux nœuds du réseau. De plus, l utilisation de mécanismes de translation d adresse (NAT, Network Address Translation) peut masquer les adresses IP source et/ou destination réelles. Les adresses MAC constituent le moyen le plus fiable pour identifier un nœud dans le réseau, puisqu elles sont associées à une carte réseau physique. Cependant, ces identités ne sont valides que pour les machines dont une interface est située dans le même segment réseau que celle de la sonde passive. En théorie, une adresse MAC est associée à au plus une adresse IP. Cependant, la plupart des systèmes d exploitation autorisent l affectation de plusieurs adresses IP à une même carte réseau. On notera enfin qu un hôte peut être équipé de plusieurs interfaces réseaux ; par conséquent, une adresse MAC ne constitue pas un identifiant unique de nœud en soi. Dans la cadre de la cartographie passive, nous nous intéresserons plus spécialement au protocole DHCP car il contient des informations permettant de réunir les différentes identités des nœuds. En effet, une requête DHCP contient l adresse MAC de l hôte demandeur, l adresse IP qui lui est attribuée, ainsi que le nom qui lui est attribué dans le réseau, lorsque la mise à jour dynamique des DNS est activée dans le réseau. 2.4.1 Structures de données concrètes La Figure 2.4 représente le schéma relationnel de la sonde passive développée dans le cadre du projet. Les données d identification de machines sont stockées dans la table hosts et dans la table hosts_properties. La table hosts stocke les valeurs les plus à jour du nom (host_name), des adresses MAC (host_macaddr) et IP (host_ipv4) et du domaine (domain) des nœuds identifiés de manière unique par un identifiant symbolique host_id. La table hosts_properties est décrite plus en détail dans les sections suivantes. Dans le cas de l inventaire des nœuds du réseau, elle permet de mémoriser les identités de nœuds devenues obsolètes. Il est utile de mémoriser ces informations afin de permettre des raisonnements sur les alertes a posteriori (par exemple connaître l état de vulnérabilité d un hôte à une date donnée). 10

Hosts host_id host_ipv4 host_by_ip host_dhcp host_name host_by_name host_macaddr host_by_mac host_domain host_desc hosts_properties host_id prop_id prop_type prop_meaning prop_content prop_time products product_id prod_name prod_type prod_categorie prod_port cano_id reg_id data_cano_products reg_id prod_categorie _order regex nom_cst nom version_cst version os_cst os text prod_cano cano_id name_id version_id os_id FIG. 2.4 Schéma relationnel des structures de données concrètes utilisées par la sonde passive 2.4.2 Algorithme de mise à jour des données Deux processus distincts contribuent à l alimentation et à la mise à jour du contenu de ces tables dans la sonde passive. Le premier processus alimente la base à partir des adresses IP présentes dans les trames réseau qui sont analysées, ainsi que par résolution DNS ; le second alimente la base par analyse des requêtes DHCP. Les algorithmes de stockage et de mise à jour sont décrits dans la section suivante. Mise à jour à partir des adresses IP contenues dans les trames L Algorithme 1 met à jour les données stockées dans les tables hosts (symbolisée par H ) et hosts_properties à partir d une adresse IP trouvée dans un paquet IP et retourne l identifiant symbolique de nœud associé. La première instruction consiste à obtenir le nom du nœud à partir de son adresse IP par les mécanismes classiques de résolution inverse de noms. On peut objecter que, ce faisant, la sonde n est pas strictement passive, puisqu elle effectue des requêtes à destination d un serveur DNS, par exemple. Ceci n est pas rédhibitoire car il s agit d un trafic ni volumineux ni potentiellement nocif comme peut l être celui engendré par sonde active par stimuli. De plus, pour obtenir une sonde strictement passive, il serait envisageable de placer une autre sonde passive en amont des serveurs de résolution de nom, dédiée à la capture des requêtes DNS, par exemple. Le gain en innocuité se ferait au détriment de la simplicité de l architecture et du traitement des informations. Nous n adopterons donc pas cette solution dans le cadre de ce projet. En cas de succès de la résolution inverse de nom et si il n existe qu un seul couple ip,name dans la base H, alors l identifiant symbolique est retourné. S il existe plusieurs noms identiques en base, différentes stratégies de mise à jour des informations sont entreprises en fonction du nombre de noms. Dans tous les cas, le nom issu de la résolution, jugé le plus pérenne, est utilisé en priorité pour retrouver l identifiant symbolique de nœud. La procédure memoriser est chargée du stockage des informations dans la tabel hosts_properties. La procédure newhost crée une nouvelle entrée dans la base hosts en lui affectant un identifiant symbolique unique. En cas d échec de la résolution de nom, l identifiant symbolique associé à l adresse IP est retourné s il existe, ou une nouvelle entrée est ajoutée à la table hosts. Mise à jour à partir des requêtes DHCP L Algorithme 2 met à jour les données stockées dans les tables hosts et hosts_properties à partir d une requête DHCP o dans laquelle figure l adresse MAC o.mac, l adresse IP o.ip et le nom o.name du nœud client DHCP. Cette procédure suppose que les DNS sont mis à jour dynamiquement. Dans le cas où un nœud présent dans la table hosts possède la même adresse MAC que celle de la requête, les autres identités de du nœud (adresse IP et nom) sont mises à jour et les éventuelles identités devenues obsolètes sont 11

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Data: Une adresse IP ip Result: Identifiant symbolique du nœud et mise à jour de la table des hôtes H name resolve(ip); if name is defined then if!t H /t.ip = ip t.name = name then return t.hid; else let n = {t H /t.name = name} ; if n = 0 then if t H /t.ip = ip then t.hostname name; memoriser(t.hid, ip, name); return t.hid; else return new host(ip,name); end else if n = 1 then let t = n H /n.name = name; memoriser(t.hid, t.ip); t.ip ip; return t.hid; else return new host(ip,name); end end else if t H /t.ip = ip then return t.hid else return new host(ip); end end Algorithm 1: Mise à jour de l inventaire des nœuds à partir d une adresse IP mémorisées dans la table hosts_properties. S il n existe aucun nœud associé à l adresse MAC de la requête, il est nécessaire d identifier un éventuel nœud déjà présent dans la table hosts, qui correpond au nœud client de la requête DHCP. Cette situation peut se produire si par exemple le nœud en question a préalablement été identifié par la simple analyse de trafic IP (c.f. Algorithme 1). La recherche par nom est utilisée en priorité car le nom est jugé une information plus pérenne que l adresse IP. En l absence de nom coïncidant avec celui de la requête, c est l adresse IP qui est utilisée comme clé d indexation (lignes 15 à 25). Dans ce dernier cas, en présence d une telle adresse IP, il est nécessaire de vérifier si le nœud correspondant a été identifié par le biais de la sonde DHCP (test en ligne 17). Dans l affirmative, l adresse IP est invalidée (ligne 20) et une nouvelle entrée est ajoutée à la table hosts. Les cas les plus fréquents correspondent à une demande DHCP initiale, au renouvellement d un bail déjà acquis, ou à la perte d une adresse suit à l expiration d un bail. Des cas plus exotiques peuvent se produire, qui peuvent rendre ambiguë l identification de la machine physique concernée par la requête. Par exemple, l association entre un nom de machine et son adresse MAC peut changer, suite à un changement de nom logique ou au remplacement de la carte réseau ; une même machine peut posséder plusieurs adresses MAC ; des machines distinctes peuvent éventuellement posséder le même nom d hôte (cas de machines 12

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Data: Une requête o = (o.mac, o.ip, o.name) Result: Mise à jour de la table des hôtes H if h H /h.mac = o.mac then if o.ip h.ip then memoriser(h, h.ip); h.ip o.ip; end if o.name h.name then memoriser(h, h.name); h.name o.name; end else let n = {h H /h.name = o.name} ; if n = 1 then memoriser(h.id, h.ip); (h.mac, h.ip) (o.mac, o.ip); else if n = 0 then if h H /h.ip = o.ip then if h.dhcp then (h.dhcp, h.mac, h.name) (true, o.mac, o.name); else h.by_ipv4 f alse; ajouter(h, new host(o.mac, o.ip, o.name)); end else ajouter(h, new host(o.mac, o.ip, o.name)); end else ajouter(h, new host(o.mac, o.ip, o.name)); end end Algorithm 2: Mise à jour de l inventaire des nœuds à partir des requêtes DHCP clonées) ; une machine peut avoir plusieurs accès ethernet, si bien qu un même nom peut être associé à plusieurs adresses MAC, ou au contraire autant de noms que d adresses MAC, auquel cas une même machine physique peut être vue comme plusieurs machines logiques ; les machines multi-boot sont susceptibles de posséder plusieurs noms et une seule adresse MAC. Une administration rigoureuse du réseau (absence de machine anonyme ou homonymes, par exemple) et/ou l inclusion de certaines propriétés dans les données cartographiques permettent de limiter ces difficultés. 2.4.3 Implémentation de la sonde La sonde d analyse du trafic DHCP est implémentée sous la forme d un module de EttercapNG, chargée de disséquer les requêtes DHCP. Les données analysées sont envoyées à l application de traitement des informations par le biais d un tube nommé. Le protocole DHCP contient différentes informations en fonction du type de requête effectué. Dans le cas d un renouvellement de bail unicast, le champ yiaddr contient l adresse IP choisie par le client. Dans le cas d une demande initiale par broadcast, l option 54 contient l adresse IP du serveur élu. Dans tous les cas, on obtient l adresse MAC du client et optionnellement son nom complet. 13

2.5 Inventaire de produits Les produits sont des logiciels au sens large, c est à dire des applications et des systèmes d exploitation. Comme présenté dans le livrable 6.1, la connaissance des produits est utile pour raisonner sur les alertes fournies par les sondes de détection d attaque. En effet, la grande majorité des vulnérabilité sont présentes au niveau des entités logiques d un système d information. La comparaison de la configuration vulnérable d un logiciel avec la configuration effective d un nœud du réseau permet de diagnostiquer le succès ou l échec d une attaque exploitant la vulnérabilité, à condition que ces configurations soient fiables 2. De plus, il existe des configurations logicielles dont le comportement normal est réputé pour engendrer des fausses alertes ou des alertes non pertinentes au niveau de certaines sondes de détection d attaques. La connaissance de la présence de ces configurations au sein d un système d information permet de reconnaître des occurrences de fausses alertes. 2.5.1 Structures de données concrètes Les données d inventaire logicielles sont stockées dans plusieurs tables dont la structure est décrite ci-après. La Figure 2.4 représente les relations entre ces tables. Identification des produits La description d un produit est stockée dans la table products. Un produit est identifié de manière unique par une valeur symbolique prod_id. La valeur prod_name est la description brute du produit, telle que fournie par la sonde passive ; prod_type est le type de service associé au produit (par exemple httpserver, etc.). La champ prod_categorie indique si le produit référencé est un système d exploitation, un service ouvert inconnu (c est-à-dire pour lequel il n existe aucune expression régulière satisfaisante), un produit de type client ou un produit de type serveur. Le champ prod_port est le numéro de port sur lequel le service identifié par prod_id est réputé écouter. Les champs cano_id et reg_id sont des clés étrangères des tables prod_cano et data_cano_prod, respectivement. Il n existe actuellement pas de nomenclature officielle des noms de produits. Les systèmes de collecte d informations cartographiques utilisent par conséquent leur propre convention de nommage. Pour exploiter ces différents outils, il est nécessaire d établir une nomenclature unique de nommage des logiciels et de convertir les noms bruts issus des outils dans cette représentation unique. On notera qu un récent projet baptisé CPE 3 (Common Platform Enumeration) créé à l initiative du Mitre 4 a pour ambition de proposer un schéma de nommage unique, basé sur un formalisme XML. Le formalisme proposé par CPE a été retenu dans le cadre de ACES pour la description des produits. Les noms normalisés sont stockés dans la table prod_cano. Formellement, un produit normalisé est un triplet constitué d un nom (name_id), d une version (version_id) et d un nom de système d exploitation (os_id) pour lequel le logiciel est conçu. Chaque produit normalisé est identifié de manière unique par une valeur symbolique cano_id. Pour éviter la redondance, les valeurs name_id, version_id et (os_id) sont en réalité des clés étrangères associées des valeurs stockées dans trois tables distinctes (non représentées sur la Figure 2.4 pour plus de lisibilité). La table data_cano_prod est utilisée par le processus de normalisation des noms de produits et contient les règles de conversion des noms bruts vers les noms normalisés. Cette table contient la catégorie de produit à filtrer prod_categorie (système d exploitation, serveur, client), l ordre d application de la règle (_order), l expression régulière de filtrage (regex) et les numéros de champ dans l expression régulière ou les constantes à utiliser pour formater les descriptions de produits. Par exemple, l entrée reg_id = 3 prod_categorie = server-version 2 Nous verrons que, en pratique, cette condition est difficile à remplir 3 http://cpe.mitre.org/ 4 http://www.mitre.org/ 14

_order = ap01 regex = ^Apache/(\d+(?:\.\d+)+) \((Unix Debian Red Hat Linux) nom_cst = TRUE nom = Apache version_cst = FALSE version = 1 os_cst = FALSE os = 2 signifie que le produit est de type serveur, qu il s agit de la première règle à tester dans la famille des règles ap, que le nom de produit extrait est constant et vaut «Apache», que le numéro de version est variable et disponible dans le premier sous-champ du résultat de l application de l expression régulière sur la donnée brute, et que le nom de système d exploitation est aussi variable et disponible dans le second sous-champ. Association entre les nœuds et les produits Le but de la collecte passive de la cartographie est d identifier les associations effectives entre des nœuds du réseau et les produits qu ils hébergent. Ce lien est implémenté au niveau des structures de données concrètes par la table hosts_properties. Les nœuds sont liés au produits par le biais du champ prop_content de la table hosts_properties, qui contient une clé étrangère, correspondant à un identifiant unique de produit. Afin de pouvoir étendre les caractéristiques d une machine, hosts_properties contient un champ décrivant la nature de l information (prop_meaning) et sa valeur (prop_content). Cette structure permet d ajouter des propriétés d hôtes nécessitant des structures de données plus complexes qu un simple couple (type, valeur) : prop_type contient alors le nom d une table et prop_content la clé primaire d une entrée de cette table. Dans le cas de l association des nœuds avec des produits, prop_type contient la valeur «runs» et prop_content une valeur correspondant à un prop_id. La table hosts_properties est aussi utilisée pour mémoriser les données d identification devenues obsolètes. Ainsi, les adresses MAC et IP et le nom d un hôte obsolètes sont stockées dans le champ prop_content, avec comme données prop_meaning les valeurs hostname, mac_addr et ip_addr (c.f. 10). 2.5.2 Algorithme de mise à jour des données L algorithme consiste simplement à rechercher l identifiant symbolique du produit à partir de la description brute qui en est donnée par la sonde. En l absence de ce produit, un nouveau produit est ajouté à la liste des produits et un nouvel identifiant est retourné. L identifiant symbolique de l hôte à partir de son adresse IP est obtenu par invocation de la procédure gethostbyip, qui correspond à l Algorithme 1 donné précédemment. Enfin, l association entre l identifiant symbolique d hôte et l identifiant symbolique de produit est ajouté à la liste des propriétés d hôtes. Si la propriété d hôte a été détectée précédemment, la date d observation est simplement mise à jour, sinon un nouvelle propriété d hôte est créée avec comme date d observation la date courante. 2.5.3 Implémentation de la sonde Deux processus de détection séparés sont utilisés pour détecter les systèmes d exploitation et les applications. Détection de systèmes d exploitation À l instar de l approche active par stimuli, l identification des systèmes d exploitation par analyse passive se base sur des ambiguïtés dans les spécifications du protocole TCP/IP, qui donnent lieu à des implémentations différentes dans les piles TCP/IP des systèmes d exploitations. Il est ainsi possible d identifier la nature et la version du système d exploitation d un client et d un serveur par les techniques de prise d empreinte (fingerprinting), qui consistent à analyser certains champs des entêtes TCP/IP (TTL, taille de fenêtre, DF, TOS) présents dans les trames échangées. 15

1 2 3 4 5 6 7 8 9 10 Data: Un événement e = (ip, prod,cat) où ip est l adresse IP d une machine, prod un nom brut de produit et cat une catégorie de produit Result: Mise à jour des tables produits P et propriété de nœuds H P if p P /p.cat = cat p.prod = prod then p new product(prod, cat); end hid gethostbyip(ip); if hp H P /hp.hid = hid hp.type = run hp.content = p.id then hp new host property(hid, run, p.id); end else hp.t currenttime end Algorithm 3: Mise à jour de l inventaire des associations produits/nœuds L identification de systèmes d exploitations par cartographie passive n est pas totalement fiable. En particulier, les données à disposition ne sont pas toujours suffisantes pour distinguer deux versions de systèmes d exploitation différentes. D une manière générale, cette technique permet de distinguer des familles de systèmes d exploitation, ce qui suffit souvent pour déterminer l échec d une attaque (plutôt que son succès). Ettercap est utilisé pour la détection de systèmes d exploitation. Sa base d empreintes de systèmes compte plusieurs centaines d entrées. Détection d applications Comme illustré dans l exemple donné en introduction de ce chapitre, l identification des logiciels par cartographie passive repose sur l extraction des annonces faites par certains logiciels dans les requêtes ou réponses du protocole applicatif. L extraction des annonces effectuées par les logiciels est réalisée à partir d expression régulières au format PCRE (Perl Compatible Regular Expressions). L outil open-source Snort dispose des fonctions nécessaires à cette extraction. Une base de règles ad-hoc sera donc élaborée dans le cadre du projet pour capturer les données voulues. Par exemple, les deux règles suivantes permettent d identifier respectivement un client et un serveur web : log tcp any any -> any 80 ( flow: from_client,established; content: "User-Agent\: "; classtype:client-version; pcre:"/user-agent\:\s([^\r\n]+)[\r\n]/"; msg:"...";) log tcp any 80 -> any any ( flow: from_server,established; content: "Server\:"; classtype:server-version; pcre:"/server\:\s([^\r\n]+)[\r\n]/"; msg:"...";) Bien entendu, seuls les services écoutant sur les ports standards énumérés dans les signatures (par exemple 80 dans le cas du HTTP) pourront être identifiés. La base de règles du prototype de sonde développé dans le cadre de ACES se limitera à l analyse de quelques protocoles applicatifs les plus courants, à savoir les applications HTTP, mail (SMTP, POP), FTP, SSH, IRC, NNTP. 16

2.5.4 Problèmes liés à l identification des logiciels Afin de raisonner sur les alertes, nous avons besoin de croiser des informations sur la cartographie du système d information avec des informations sur les configurations vulnérables des applications. Les premières sont obtenues par le biais de sondes de collecte actives ou passive et les secondes à partir de bases de données de vulnérabilité diverses (OSVDB, ICAT, etc.). Ni les unes ni les autres n utilisent de référentiel commun de nommage des logiciel, ce qui complique la tâche de corrélation car les identifiants de produits sont incompatibles, imprécis, ambigus et parfois entachés d erreurs, comme cela a été évoqué plus haut (c.f. 14). Le projet CPE, qui propose un schéma de nommage unique est balbutiant. Les sondes cartographiques et les bases de données de vulnérabilités ne l utilisent donc pas encore pour identifier les produits. Il est possible que cela soit le cas dans ultérieurement, lorsque la base de données CPE sera suffisamment riche. En attendant, nous devons faire la conversion des noms bruts vers un schéma de nommage unique. Comme nous l avons déjà évoqué, le schéma de nommage retenu dans le cadre du projet est compatible avec celui proposé par CPE. Cette conversion peut s opérer à différents étages du système de collecte cartographique. La technique la plus élégante consiste à alimenter la base de connaissance directement avec des données normalisées, ce qui signifie que le travail de conversion est assuré directement par les sondes. C est la technique que nous adoptons pour l identification des logiciels affectés par des malwares, dans le cadre du contexte global. La base des noms de logiciels est aussi alimentée par des systèmes dont nous n avons pas forcément la maîtrise. Dans ce dernier cas, la conversion est effectuée à l extérieur de ces systèmes, par un processus ad-hoc, situé au niveau de la base de connaissance. Ce processus prend en entrée les règles de conversion (sous la forme d expressions régulières), les descriptions de logiciels issues de sources non compatibles avec CPE, applique les conversions et les stocke dans la base d informations cartographiques. Cette opération de conversion est symbolisée dans le schéma d architecture donné en Figure 2.3 par la flèche dont le label est «conversion». Le principe de fonctionnement est d essayer d appliquer une à une les expressions régulières sur les données brutes. En cas de succès, des données sont éventuellement extraites du résultat de l application de l expression régulière (par exemple le numéro de version d un produit), puis la description normalisée du produit est stockée dans la base. La conversion d une donnée brute peut éventuellement donner lieu à l insertion de plusieurs entrées normalisées, par exemple lorsqu une donnée brute identifie une application donnée et un système d exploitation. Les requêtes émanant du gestionnaire de corrélation n exploitent que les données normalisées. 17

Chapitre 3 Collecte Active de Données Contextuelles Locales La solution logicielle DNA consiste en un moteur de découverte et d inventaire réseau automatique. A l issue de cette étape active de récupération d informations, un algorithme permet d établir la connectivité en couches 2 et 3 entre les différents équipements réseau. Ces informations sont stockées dans une base de données relationnelle. Dans le cadre de ACES, DNA sera donc utilisé comme une sonde logicielle, source d informations contextuelles cartographiques. La table ntxcprocnetworkobject contient la liste des équipements découverts sur le réseau : ntxcprocnetworkobject Field Type Null Default Extra UOID string(200) No lasthistory int(11) Yes 0 PrimaryIntIndex int(11) Yes NULL PrimaryIpAddress string(50) Yes NULL ObjectTypeID int(11) Yes 0 Services int(11) Yes NULL PublicCommunity string(50) Yes NULL PrivateCommunity string(50) Yes NULL Hostname string(50) Yes NULL VendorID int(11) Yes 0 ProductID string(200) Yes NULL extendedproductid string(10) Yes NULL wmiserial string(50) Yes NULL fingerprintos string(255) Yes NULL fingerprintosdetails string(255) Yes NULL x int(11) Yes -1 y int(11) Yes -1 La table dnahistory contient la liste des inventaires effectués par DNA. 18

dnahistory Field Type Null Default Extra ID int(11) No auto-increment startdate string(19) Yes 0000-00-00 00 :00 :00 enddate string(19) Yes 0000-00-00 00 :00 :00 status int(11) Yes 0 comments string(200) Yes NULL network string(50) Yes NULL maxdevicesreached int(11) No -1 compacted int(11) Yes 0 setupvalues blob(16777215) Yes NULL discoveryresults blob(16777215) Yes NULL La table DnaObjectHistory permet de faire une référence croisée entre DnaHistory (liste des inventaires) et NetworkObject (Liste des équipements découverts), permettant de définir les matériels découverts lors d une découverte donnée. DnaObjectHistory Field Type Null Default Extra ID int(11) No auto-increment UOID string(200) Yes NULL history int(11) Yes 0 discoverydate string(19) Yes NULL processtime int(11) No -1 Les tables Privinstalledsw et wmisoftware contiennent les listes des logiciels installes sur la machine, récupérée par SNMP ou WMI. Privinstalledsw Field Type Null Default Extra installedswid int(11) No auto-increment UOID string(200) Yes NULL history int(11) Yes 0 filename string(200) Yes NULL swsize int(11) Yes 0 installeddate string(19) Yes 0000-00-00 00 :00 :00 wmisoftware Field Type Null Default Extra ID int(11) No auto-increment UOID string(200) No History int(11) No 0 Name string(200) Yes NULL Vendor string(100) Yes NULL Version string(50) Yes NULL InstallDate string(10) Yes NULL InstallLocation string(200) Yes NULL IdentificationCode string(200) Yes NULL La table refsysobject contient la liste des modèles d équipements (ex :Cisco2800, Passport 1150, ) et le type s y rapportant : switch, routeur, serveur... 19

refsysobject Field Type Null Default Extra sysobjectid int(11) No auto-increment sysobjectmib string(200) Yes NULL ProductID string(200) Yes NULL ObjectType int(4) Yes 0 visiotype int(4) Yes 1 La table wmiprocess contient la liste des processus exécutés sur la machine. wmiprocess Field Type Null Default Extra UOID string(200) No History int(11) No 0 Caption string(200) Yes NULL CommandLine string(200) Yes NULL CreationDate string(200) Yes NULL CSName string(200) Yes NULL Description string(200) Yes NULL ExecutablePath string(200) Yes NULL ExecutionState string(200) Yes NULL InstallDate string(200) Yes NULL Name string(200) Yes NULL OSCreationClassName string(200) Yes NULL OSName string(200) Yes NULL PageFaults string(200) Yes NULL PageFileUsage string(200) Yes NULL ParentProcessId string(200) Yes NULL PeakPageFileUsage string(200) Yes NULL ProcessId string(200) Yes NULL SessionId string(200) Yes NULL Status string(200) Yes NULL TerminationDate string(200) Yes NULL ThreadCount string(200) Yes NULL UserModeTime string(200) Yes NULL VirtualSize string(200) Yes NULL WindowsVersion string(200) Yes NULL La table wmiservice contient la liste des services actifs sur la machine. 20

wmiservice Field Type Null Default Extra ID int(11) No auto-increment UOID string(200) No History int(11) No 0 Name string(200) Yes NULL Caption string(200) Yes NULL Description string(255) Yes NULL DisplayName string(200) Yes NULL InstallDate string(200) Yes NULL PathName string(200) Yes NULL ProcessId string(200) Yes NULL ServiceSpecificExitCode string(200) Yes NULL ServiceType string(200) Yes NULL Started string(200) Yes NULL StartMode string(200) Yes NULL StartName string(200) Yes NULL State string(200) Yes NULL Status string(200) Yes NULL SystemName string(200) Yes NULL La table Procl2topology est renseignée par l algorithme de calcul de topologie et définit la connectivité entre les équipements réseau. 21

Procl2topology Field Type Null Default Extra SwitchDetailID int(11) No auto-increment SwitchInfoID int(11) Yes NULL UOID string(200) Yes NULL history int(11) Yes 0 SwitchIntID int(11) Yes NULL SwitchSlot int(11) Yes NULL SwitchCard int(11) Yes NULL SwitchPort int(11) Yes NULL SwitchPortDescription string(200) Yes NULL SwitchPortMLTID string(255) Yes NULL SwitchPortXtraDescription string(200) Yes NULL SwitchPortMAC string(200) Yes NULL SwitchPortSpeed real(22) Yes NULL SwitchPortDuplex string(200) Yes NULL SwitchPortType string(200) Yes NULL SwitchPortStatus int(11) Yes NULL SwitchPortAdminStatus int(11) Yes NULL SwitchPortVLAN string(200) Yes NULL SwitchPortSTGroot string(200) Yes NULL SwitchPortSTGStatus string(200) Yes NULL SwitchLinkType string(200) Yes NULL SwitchPortToUOID string(200) Yes NULL SwitchPortToInt int(11) Yes NULL SwitchPortToSlot int(11) Yes NULL SwitchPortToCard int(11) Yes NULL SwitchPortToPort int(11) Yes NULL SwitchPortToPortVLAN string(200) Yes NULL SwitchPortToPortMAC string(200) Yes NULL SwitchPortToPortIP string(200) Yes NULL SwitchPortToPortHostName string(200) Yes NULL SwitchPortToPortDescription string(200) Yes NULL SwitchPortToPortSpeed int(11) Yes NULL SwitchPortToPortDuplex string(200) Yes NULL SwitchPortToPortType string(200) Yes NULL SwitchPortToPortStatus int(11) Yes NULL SwitchPortToPortAdminStatus int(11) Yes NULL SwitchPortToPortSTGroot string(200) Yes NULL SwitchPortToPortSTGStatus string(200) Yes NULL SwitchPortToPortVendor string(255) Yes NULL Fort des informations décrites ci-dessus, le gestionnaire de contexte peut adresser différents types de requêtes, effectuées par le gestionnaire de corrélation : Liste des Processus tournant sur une machine donnée Liste des produits installes sur une machine et leur version Version d un logiciel donné Connectivité entre deux adresses IP Liste des interfaces IP d une machine Cette liste est non exhaustive, et peut être amenée a être complétée en fonction des besoins du gestionnaire de corrélation. 22

Cette interface soulève un problème transverse récurrent : celui de la standardisation du nommage des applications et systèmes d exploitation. Apres avoir étudié différentes solutions pour répondre a ce problème, nous avons finalement choisi d établir en interne une liste consolidée de ces applications, a partir des informations disponibles auprès de la communauté sur Internet. 23

Chapitre 4 Gestionnaire de Contexte Le gestionnaire de contexte est l élément de l architecture responsable du traitement des requêtes émanant des modules de corrélation d alertes au sujet d informations contextuelles, exprimées selon le formalisme M4D4 (c.f. livrables du sous-projet 2). M4D4 est un langage de description unificateur des informations manipulées par les modules de corrélation. Ce langage constitue une couche d abstraction qui affranchit les modules de corrélation de la connaissance des structures de données spécifiques utilisées par les systèmes de collecte d informations contextuelles. Le gestionnaire de contexte, en revanche, connaît ces structures de données et est capable d interpréter une requête M4D4 pour la traduire dans ces différents langages. 4.1 Buts et prédicats Le test de propriétés sur le contexte local ou global se fait par vérification d un but à la mode Prolog, c est-à-dire par une suite de prédicats à vérifier simultanément. Exemple : nodeaddress(x, 192.168.0.123 ),run(x,y), software(y,z,_, os,_),z~ debian Le résultat attendu pouvant être : soit une liste de n-uplets de valeurs à affecter à un sous-ensemble défini des variables pour vérifier le but (résultat d une projection au sens de l algèbre relationnelle), soit un résultat vrai/faux si la liste des variables de projection est vide. L ensemble des prédicats utilisables est défini par M4D4. 4.2 Prédicats M4D4 et vues SQL équivalentes L information sur le contexte local et global est mémorisée dans des tables SQL a priori non équivalentes aux prédicats M4D4 : on définit donc sur ces tables des vues calquées sur les prédicats. La définition des prédicats M4D4 et donc des vues SQL équivalentes est fournie par un dictionnaire (lstdefpred) contenant des entrées de la forme nom_prédicat : liste_attributs. Les clés étrangères doivent porter le même nom que les clés primaires. Exemple de dictionnaire en Python : defpred = { \ nodeaddress : [ idnd, AdIp ], \ software : [ idsoft, Name, Vers, Type, Arch ], \ run : [ idnd, idsoft ], \ affect : [ idvulne, Conf ], \ takepartin : [ idsoft, Conf ], \ refersto : [ idvulne, Org, SN ], \ 24

} require : [ idvulne, Access ], \ severity : [ idvulne, Svr ] \ Vérifier un but revient alors à faire une requête SQL sur les vues équivalentes aux prédicats définis par M4D4 : on reporte sur le SGBD l optimisation de la traduction des requêtes sur les vues en requêtes sur les tables réelles. Un but tel que run(12,x),run(_,y),x!=y sera traduit en : SELECT t0.idsoft AS X FROM vw_run as t0, vw_run as t1 WHERE t0.idnd=12 and t0.idsoft!=t1.idsoft si la liste des variables de projection est {X}, ou en : SELECT count(*) as count FROM vw_run as t0, vw_run as t1 WHERE t0.idnd=12 and t0.idsoft!=t1.idsoft si cette liste est vide. 4.3 Traduction des prédicats en arbres abstraits Un compilateur permet de traduire un but M4D4 en arbres abstraits (compilateur suffisamment simple pour être écrit à la main sous forme d un analyseur récursif descendant). Trois types de nœuds sont utilisés pour construire les arbres abstraits : Predicats, avec les champs : nom, nom du prédicat/de la vue, alias, alias de table pour les jointures SQL (alias systématique pour pouvoir traiter les jointures utilisant plusieurs fois la même table), lstarg, liste des nœuds arguments successeurs du nœud prédicat, Arg, avec les champs : typarg, type de l argument : variable / chaîne de caractère / entier / joker, val, la valeur, Comp, avec les champs : typcomp, type de comparateur parmi {==,! =, <, <=, >, >=, }, larg et rarg, références des nœuds successeurs à gauche et à droite. L analyseur produit trois listes : une liste d arbres abstraits pour les prédicats, lstpred, une liste d arbres abstraits pour les contraintes d (in)égalité, lstcomp, un dictionnaire (au sens de Python) lstvar, ayant pour clés les variables utilisées et comme valeurs associées la liste des références par les prédicats. Pour le but run(12,x),run(_,y),x!=y l analyseur générera une liste d arbres abstraits pour les prédicats M4D4 (en notation indentée) : Predicat nom= run, alias= t0 Arg type=int, val=12 Arg type=var, val= X Predicat nom= run, alias= t1 Arg type=joker, val= Arg type=var, val= Y (les alias de la forme ti, où i est le rang du prédicat, sont affectés par un parcours de la liste des arbres). une liste d arbres abstraits pour les contraintes d (in)égalité : Comp type=!= Arg type=var, val= X Arg type=var, val= Y 25

et un dictionnaire des variables et de leur références ; chaque référence a deux champs, ref, référence de l arbre abstrait dans lstpred et numarg, rang du paramètre : X : [(run/t1),1)] Y : [(run/t2),1)] 4.4 Algorithme de génération d une requête SQL Données en entrée : lstpred, liste des arbres abstraits des prédicats M4D4 présents dans le but, lstcomp, liste des arbres abstraits des contraintes d (in)égalites du but, lstvar, dictionnaire des variables avec la liste de leurs références par les prédicats, lstvaraff, liste des variables de projection (sous-ensemble des variables du but), lstdefpred, dictionnaire des prédicats alias vues et de leurs arguments alias champs. L algorithme se décompose en 5 phases : 1. génération de la liste des variables sélectionnées (ou d un count(*)), 2. génération de la liste des tables sur lesquelles porte le select, avec alias systématiques, 3. génération des contraintes dues aux jointures (variables présentes dans plusieurs prédicats), 4. génération des contraintes de valeur (arguments constants dans les prédicats), 5. génération des contraintes dues aux comparaisons Ces cinq phases permettent de générer les zones suivantes dans une requête SQL : SELECT (1) FROM (2) WHERE (3) (4) (5). Exemple déjà cité (sans contrainte de jointure, donc sans zone (3)) : SELECT t0.idsoft AS X FROM vw_run as t0, vw_run as t1 WHERE t0.idnd=12 and t0.idsoft!=t1.idsoft 4.4.1 Phase 1 : liste des variables sélectionnées En pseudo langage : sql = SELECT ; si vide(lstvaraff) alors sql += count(*) AS count sinon pour chaque var dans lstvaraff faire si pas 1er item alors s +=, ; finsi ref = lstvar[var].lstref[0]; // 1er référence à var sql += ref.pred.nom // nom du prédicat = de la vue // + nom du champ +. + lstdefpred[ref.pred.nom][ref.numarg] // + alias + AS + var; fin pour finsi 4.4.2 Phase 2 : liste des tables sélectionnées En pseudo langage ("vw_" est le préfixe des noms de vues pour éviter les collisions de noms de vues avec les noms de tables) : 26

sql += FROM ; pour chaque pred dans lstpred faire si pas 1er item alors s +=, ; finsi sql += vw_ +pred.nom + pred.alias; fin pour 4.4.3 Phase 3 : contraintes de jointures Les contraintes (clause WHERE) sont générées dans une chaîne séparée, sql2, qui ne sera concaténée à la requête sql que s il existe effectivement des contraintes. En pseudo langage : pour chaque var,lstref dans lstvar faire si lg(lstref) > 1 alors ref = lstref[0]; // 1ère ref à var rvalue = ref.pred.alias // alias // + nom du champ +. + lstdefpred[ref.pred.nom][ref.numarg]; pour i=1 à lg(lstref)-1 faire // à partir seconde ref. si pas 1er item alors sql2 +=, ; sql2 += lstref[i].pred.alias +. + lstdefpred[lstref[i].pred.nom][lstref[i].numarg] + = + rvalue; fin faire finsi fin faire 4.4.4 Phase 4 : contraintes de valeur littérale Elles correspondent à la présence de littéraux dans les prédicats du but. Algorithme de génération en pseudo langage : pour chaque pred dans lstpred faire pour i=0 à lg(pred.lstarg)-1 faire arg = pred.lstarg[i]; si arg.typarg dans {STR, INT} alors si pas 1er littéral alors sql2 += AND ; finsi sql2 += pred.alias +. + lstdefpred[pred.name][i] + = + " " + arg.val + " "; finsi fin faire fin faire 4.4.5 Phase 5 : contraintes de comparaison Cette section est générée à partir de la liste des arbres abstraits déduits des contraintes d (in)égalité présentes dans le but. Noter que la grammaire des buts impose que le premier membre des (in)égalités soit une variable. Algorithme en pseudo-langage : pour chaque comp dans lstcomp faire si pas 1ère contrainte alors sql2 += AND ; finsi ref = lstvar[comp.larg.val].lstref[0]; // 1ère ref à lvalue 27

sql2 += ref.pred.alias +. + lstdefpred[ref.pred.name][ref.numarg]; sql2 += comp.typcomp; // == ou!= etc. si comp.rarg.typarg == VAR alors // si rvalue de type var ref = lstvar[comp.rarg.val].lstref[0]; // 1ère ref rvalue sql2 += ref.pred.alias +. + lstdefpred[ref.pred.name][ref.numarg]; elsif comp.rarg dans {STR, INT} alors sql2 =+ " " + comp.rarg.val + " "; finsi fin faire Pour finir, concaténation des clauses WHERE au SELECT : si sql2!= alors sql += WHERE + sql2; finsi 28

Bibliographie [1] B. Morin, Corrélation d alertes issues de sondes de détection d intrusions avec prise en compte d informations sur le système surveillé, Thèse de doctorat, 2004. [2] G. Ollmann, Passive Information Gathering, Next Generation Security Software ltd, NISR, 2004. [3] D. Comer, J. Lin, Probing TCP Implementations, Proceedings of the 1994 Summer USENIX Conference, Boston, MA. [4] V. Paxson, Automated Packet Trace Analysis of TCP Implementations, ACM SIGCOMM 97, September 1997, Cannes, France [5] S. Webster, R. Lippmann and M. Zissman, LANscape : A Passive Network Mapping System, Experience Using Active and Passive Mapping for Network Situational Awareness, Fifth IEEE International Symposium on Network Computing and Applications (NCA 06), pp. 19-26, 2006. [6] B. Dayiglu and A. Ozgit, Use of Passive Network Mapping to Enhance Signature Quality of Misuse Network Intrusion Detection Systems, 16th International Symposium on Computer and Information Science, Novembre 2001. [7] Siphon, http://siphon.sourceforge.net/. [8] Pof, http://lcamtuf.coredump.cx/p0f.shtml. [9] Prelude, http://www.prelude-ids.org/. [10] Ettercap, http://ettercap.sourceforge.net/. [11] pfprintd, http://www.raisdorf.net/projects/pfprintd. [12] Disco, http://www.altmode.com/disco/. [13] RNA, http://www.sourcefire.com/technology/rna.html [14] Nevo, http://www.tenablesecurity.com/nevo.html. [15] Archaeopteryx, http://members.fortunecity.com/sektorsecurity/projects/archaeopteryx.html 29