WO2013127619A1 - Méthode d'inventaire de réseau - Google Patents

Méthode d'inventaire de réseau Download PDF

Info

Publication number
WO2013127619A1
WO2013127619A1 PCT/EP2013/052691 EP2013052691W WO2013127619A1 WO 2013127619 A1 WO2013127619 A1 WO 2013127619A1 EP 2013052691 W EP2013052691 W EP 2013052691W WO 2013127619 A1 WO2013127619 A1 WO 2013127619A1
Authority
WO
WIPO (PCT)
Prior art keywords
probability
host
detection
network
notification
Prior art date
Application number
PCT/EP2013/052691
Other languages
English (en)
Inventor
Thibaut HENN
Original Assignee
Amossys
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Amossys filed Critical Amossys
Publication of WO2013127619A1 publication Critical patent/WO2013127619A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/142—Network analysis or design using statistical or mathematical methods
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/028—Capturing of monitoring data by filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis

Definitions

  • the invention relates to network monitoring.
  • the invention relates more particularly to the monitoring of networks comprising communication terminals.
  • Such communication terminals may take the form of personal computers, personal assistants, tablets or smart phones. More specifically, the invention relates to the inventory of such communication networks.
  • the inventory of a communication network consists on the one hand of listing the hosts present on this network, and on the other hand for each of these hosts, to obtain the list of the software installed therein, as well as their versions. It's about finding the operating systems used, the servers installed and available, but also the clients used. Such an inventory makes sense in modern communications networks, especially local area networks, in which more and more terminals of different types are connected.
  • Knowing the inventory of a network is important for both an administrator and an attacker as it gives an overview of network security.
  • knowing the versions of the present software makes it possible to know, via public databases, the potential vulnerabilities of these softwares, and therefore, vulnerable machines.
  • Maintaining an accurate and up-to-date inventory requires the use of dedicated software.
  • the increasing size of the networks no longer makes it possible to list manually.
  • the possibility for users to install their own software, as well as the constant updates of software does not allow to maintain these lists manually.
  • the historical method of obtaining inventory consists in manually connecting to the servers of the communication network and observing banners transmitted by them. Indeed, the various software of the time transmitted to the customer their name, their version number, but also the operating system making them work as well as its version.
  • IP Internet Protocol
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • Active methods These methods transmit specially forged packets to hosts and analyze the responses (or lack thereof) of them. Active methods are generally divided into two categories:
  • passive methods these methods do not transmit packets over the network but perform an analysis of the captured traffic to determine the services using the network. An impression is then taken of the system or systems by applying detection rules on events and / or packets that deliver a result.
  • a hybrid technique uses a first passive inventory phase and a second phase of active inventory.
  • an active phase is instantiated to try to complete the based.
  • port scanning combines the techniques of discovering open TCP and UDP ports on a host and inferring the services that operate there. Initially, port scans were performed while attempting to connect to the server ports. A second, less cumbersome technique was to send only the first TCP packet (the SYN) and wait for the response (which depends on the opening of the port).
  • SYN the first TCP packet
  • Current systems typically include standard firewalls that limit the use of such techniques.
  • Active systems and service detection techniques are the first to be published. They followed a need for detection of equipment on the network. All these techniques work on the same principle: transmit specially forged packets and use signatures to deduce the system based on the responses received. The different approaches focus more on the interesting fields (transmitted and received packets) than on the techniques used. They implement databases of detection rules to determine a system using the observations made.
  • the systems based on detection rules choose the first system listed (this is for example the case in the software "pOf"), the statistical systems choose the one having the better probability (example of Robert Beverly, "A robust classifier for passive tcp / ip", In Fingerprinting, in PAM, 200).
  • These methods do not manage the series of observations and contradictions can appear (in "robust classifier for passive tcp / ip", these contradictions are interpreted as several machines sharing the same IP address, which is obviously not necessarily the case, and thus generates a false interpretation).
  • active methods by their nature, natively manage the series of observations. Two different approaches are then used:
  • the requests (transmitted by the device in charge of carrying out the inventory) are chosen in the manner of a decision tree.
  • the device selects a request making it possible to delete possible systems until only one system remains possible.
  • the present disclosure proposes an inventory system of a network, providing a probability associated with its inferences and a learning ability.
  • the invention relates to a method of inventorying a communication network, said network comprising at least one host h exchanging data with other equipment of said network.
  • said method comprising the following phases: a phase of obtaining at least one footprint E associated with said host h, said at least one footprint E comprising at least one detection notification representative of at least one activation at least one detection rule r by at least one element exchanged on said network and associated with said host A; a phase of obtaining, from said at least one imprint E, at least one probability p of presence of at least one service s within said host h, from at least one probabilistic database associating said at least one detection rule r has at least one predetermined probability.
  • said method further comprises a prior learning phase comprising a step of filling said probabilistic database with the aid of a communication network comprising known equipment.
  • said phase of obtaining said at least one footprint E of said host h comprises at least one iteration of the following steps:
  • said detection notification delivered during said application of said at least one detection rule delivers a binary result.
  • said detection notification delivered during said application of said at least one detection rule delivers a probabilistic result.
  • said phase of obtaining at least one probability p of presence of at least one service s within said host h comprises, for each notification of said detection fingerprint E:
  • said prior probability is multiplied by a coefficient c dt whose value is a function of time between said notification of said detection cavity and / or a coefficient having a predetermined value.
  • the invention also relates to an inventory device of a communication network, said network comprising at least one host h exchanging data with other equipment of said network.
  • said device comprises: means for obtaining at least one footprint E associated with said host h, said at least one footprint E comprising at least one detection notification representative of at least one activation of at least one detection rule r by at least one element exchanged on said network and associated with said host h; means for obtaining, from said at least one fingerprint E, at least one probability p of presence of at least one service s within said host h, from at least one probabilistic database associating said at least one detection rule r with at least one probability.
  • the invention also relates to a computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, and comprising program code instructions for the implementation of the previously described method.
  • Figure 1 shows a block diagram of an embodiment of the invention
  • Figure 2 schematically shows a device for implementing the invention.
  • the method currently described does not have the disadvantages of the prior art.
  • the method described makes it possible to take into account for the identification of a system, the results previously obtained. Unlike prior techniques, this consideration is carried out recursively and non-discriminatory: this means, for example, that the disadvantages associated with the decision trees are not present with the method described. This also means that the disadvantages of scoring (percentage allocation) are not present in the described method.
  • the described method offers the possibility of correcting erroneous results by updating the knowledge base that is used to obtain the detection rule identification results.
  • the general principle is based on a recursive probabilistic calculation. This calculation makes it possible, unlike the previous techniques, to obtain a sequence of probabilities of belonging or non-belonging. This calculation also makes it possible to prevent certain possibilities of concordance being purely and simply eliminated, as is the case with other systems.
  • the invention implements a technique in which a probabilistic database is used.
  • This probabilistic database lists, for a given detection rule, probabilities associated with systems (and / or services).
  • the invention uses this probability database to associate a given host with a certain quantity of possible services, this possible quantity of services being a function of the Trigger detection rules against packets "listened" on the network.
  • the invention relates to a method of inventorying a communication network, said network comprising at least one host h exchanging data with other equipment of said network, said method comprising the following phases: a phase of obtaining at least one footprint E associated with said host h, said footprint E comprising at least one detection notification representative of at least one activation of at least one detection rule r by at least one element exchanged on said network and associated with said host h; a phase of obtaining, from said at least one fingerprint E, at least one probability p of presence of at least one service s within said host h, from at least one probabilistic database associating said at least one detection rule r at least one predetermined probability.
  • the invention comprises the following phases:
  • An observation phase takes place, during which the exploitable data that travels over the network (for example TCP packets, IP packets, etc.) are used to form a fingerprint and be injected into a socket module.
  • fingerprint. at. this impression taking module operates iteratively and attempts, at least for a portion of the rules of detection of the detection rule database, to apply these detection rules to the exploitable data;
  • b. when exploitable data activates a detection rule r (the activation bit result is "1") this activation is kept in the database (as well as its association with the host h at the origin of the exploitable data) to be used thereafter.
  • the acquisition module continues to take the impression as long as usable data are provided.
  • the footprint E obtained at the end of this acquisition phase, consists of the ordered sequence or not activated detection rules (n), and is recorded in database.
  • a probabilistic calculation module uses a fingerprint E to recursively calculate the probability of discovery of one or more systems (services) If that could be associated with this fingerprint: a. for each detected detection rule r t of a fingerprint E, the list of associated systems and their respective probabilities of presence are identified within the database. b. these probabilities are combined with the previous probabilities (or a probability 0 if it is the first recursive iteration) to deliver a resultant probability. vs. this recursive process is implemented as long as detection rules (associated with probabilities) remain to be processed.
  • the result obtained at the end of this probabilistic calculation phase, for a given host h, is a set of probabilities associated with one or more systems (services).
  • FIG. 1 schematizes the global architecture of this embodiment and lists the four main elements: memory (Mry), volatile or not: stores the prior knowledge (the probabilities), the parameters of the model and the intermediate results; the acquisition module (M E ): listens to the network and notifies (stores in the Mry memory) when detection rules validate network packets;
  • the probability estimation module uses the notifications (from the fingerprinting module M E ) and communicates with the memory ⁇ Mry) to estimate the probability of hosting the services;
  • the parameter learning module communicates with the database (ry) to update the model parameters.
  • the modules of this embodiment can be deployed on different machines, or grouped, totally or partially on a single machine and / or in a single software component without changing the principles. The description of this embodiment follows the modules listed in the diagram of FIG.
  • the memory allows access and modification of the following elements:
  • the probabilities, for the hosts (h), that the services (s) are hosted there (noted P h (s)), it can take the form of a table containing elements of the form of recordings (h, s , P h (s)); these probabilities are grouped in P.
  • the lists of detection rules and services are valued according to a priori knowledge bases. For any service that a detection rule is able to detect (based on knowledge at priori), the corresponding counter is initialized to 1 (it is at 0 otherwise). The other elements are empty and will be valued during the execution of the tool.
  • Passive impression taking is performed by the acquisition module M E. Passive impression taking uses a binary detection rule approach. These detection rules take a network packet as input and output a boolean (true / false decision). The principle of obtaining a result associated with a detection rule is therefore simple.
  • any system of binary detection rules can be used in the context of this embodiment, the only constraint being to provide a binary indication for the elements of the observed traffic ("true” or “1” for an application from the detection rule to a packet and "false” or "0” for non-application of the detection rule to a packet).
  • the binary indication is preferred for reasons of simplicity.
  • a probabilistic indication is also envisaged. We would then obtain a double probabilistic system. The advantage of such a dual probabilistic system is, of course, the fact that a more refined probability will be obtained in the end.
  • syntactic detection rules of TCP / SYN packets derived from the detection rules of the pOf tool
  • regular expression detection rules relating to HTTP protocol headers.
  • the acquisition module M E transmits (either directly or in the form of a creation of a record in a database) a notification to the estimation module of the probability M P.
  • This notification includes a timestamp, the identifier of the source machine of the packet, and the identifier of the detection rule that has been validated. 5.2.3 Estimation of the probability of hosting by the estimation module
  • the estimation of the probability of hosting (ie of a given service or system on a given host) by the probability estimation module (p) uses the sequence (ordered or not) of the module's notifications. previous M E impression to provide an estimate of the probability that a service is present on a host.
  • a detection rule does not always detect the same service, but a set (a class) of services that share certain properties in the packets they transmit (for example, systems Linux with a 2.6 kernel); several equivalent services can be hosted simultaneously within a host. It can be compatible services (web browsers for example), or incompatible (operating systems), the different systems sharing the same address, for example through an address translation system (NAT).
  • a detection rule does not always detect the same service, but a set (a class) of services that share certain properties in the packets they transmit (for example, systems Linux with a 2.6 kernel); several equivalent services can be hosted simultaneously within a host. It can be compatible services (web browsers for example), or incompatible (operating systems), the different systems sharing the same address, for example through an address translation system (NAT).
  • NAT address translation system
  • the event "the service is causing a notification” corresponds to the event "the service is at the origin of the first, or to one of the following”.
  • the probability is calculated recursively as follows:
  • P h (s ⁇ No) that is, the probability that the service is the source of the notification
  • P h (s ⁇ n) P (s ⁇ r), ie the probability that a service is behind the traffic validated by a detection rule.
  • This probability is estimated in a preliminary learning phase (described below).
  • the probability calculation method within the meaning of the invention is implemented within a specific probability calculation module. This module uses, in input, the notifications of the passive impression taking, a notification and denoted (h, r, t) thereafter.
  • the list of hosts is updated; if a host has not yet been seen (that is, no probability has been calculated for it), the probability calculation module adds this host to the H list of hosts. The notification is added to the list of traces A.
  • the probability calculation module carries out, in this embodiment, the following operations: 1. Retrieve the number of validation of the detection rule in V (number which is named v in the following). 2. For each counter for detection rule r in list C, perform the following steps:
  • calculating probability based on counter values is one of many approaches to calculating probability.
  • the probability associated with a service or system may already be present in the probabilistic database without it being necessary to calculate the ratio p s .
  • the first characteristic is the insertion of a scheduling in the impression taking.
  • notifications are scheduled to take into account the actual occurrence of events (packets, traces) that triggered the notifications.
  • the calculation takes into account the scheduling.
  • the general idea is: the inventory is not fixed. At any time, machines start, stop and systems present behind an address can change (change of address assignment via DHCP or dual boot). The process is then improved to be able to "forget” its previous deductions.
  • the coefficient is adapted according to the needs. When the coefficient "c" is "1", the system does not forget anything. When he is worth 0, he forgets everything. The more we go from 0 to 1, the more we keep in memory old events and therefore the "old” probabilities retain value.
  • the coefficient c may be close to 0, since in this case the old forecasts do not necessarily have any meaning.
  • the order of the traces and their timestamps makes sense. It is also necessary to store in the memory the moment when the stored results have been calculated. In another embodiment, it is also possible to assign a coefficient c to the old probabilities, without being conditioned to a time elapsed between the previous update and the current update. In this case the formula does not take into account the time.
  • Table 2 shows an example of progression of the probabilities associated with the three services for an arbitrary sequence of notifications.
  • the learning makes it possible to estimate the coefficient p s mentioned in the preceding section via the calculation of the counters.
  • Learning takes as input a trace (A) of detection, and an explicit inventory (provided by an expert for example), in the form of an association table between services and hosts (HS).
  • An optional first step of initialization can be performed. This phase consists of putting all the counters back to 0. When this step is not performed, the consecutive learning phases accumulate.
  • the training performs the following operations:
  • the described method is able to quantify the presence of a system, and when several solutions are possible, it allows to classify them from the most probable to the least probable.
  • the probability provided has a real mathematical meaning: it quantifies the probability, given the observations, that the system concerned is present on the host. Low probabilities indicate that the service is unlikely to be present, but may be the source of some network observations. On the other hand, a high probability indicates that the service is very likely to be present.
  • the learning phase also improves the accuracy and relevance of the detection rules of the database.
  • the database of detection rules of pOf contains many errors (for example, detection rules are referenced as detecting the systems of the Windows Vista family while they detect the systems of the XP family). Without learning, the tool is likely to detect erroneous systems.
  • the latter comprises a memory M 21, a processing unit 22, equipped for example with a microprocessor, and controlled by the computer program Pg 23.
  • the code instructions of the computer program 23 are example loaded into a RAM before being executed by the processor of the processing unit 22.
  • the processing unit 22 receives as input the data 24 issued by the various hosts of the network in which the inventory must be made. (This is for example TCP packets, IP or HTTP stubborn).
  • the microprocessor ⁇ of the processing unit 22 performs one or more passive prints of these data 24, according to the instructions of the program Pg 23.
  • the processing unit 22 outputs probabilities 25 (for example lists of probabilities associated with different services / systems), intended to allow for an inventory of the network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Power Engineering (AREA)
  • Artificial Intelligence (AREA)
  • Computer Security & Cryptography (AREA)
  • Evolutionary Computation (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Pure & Applied Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention se rapporte à un procédé d'inventaire d'un réseau de communication, ledit réseau comprenant au moins un hôte h échangeant des données avec d'autres équipements dudit réseau. Selon l'invention, ledit procédé comprend les phases suivantes : une phase d'obtention d'au moins une empreinte E associée audit hôte h, ladite au moins une empreinte E comprenant au moins une notification de détection représentative d'au moins une activation d'au moins une règle de détection r par au moins un élément échangé sur ledit réseau et associé audit hôte h; une phase d'obtention, à partir de ladite au moins une empreinte E, d'au moins une probabilité p de présence d'au moins un service s au sein dudit hôte h, à partir d'au moins une base de données probabiliste associant ladite au moins une règle de détection r à au moins une probabilité prédéterminée.

Description

Méthode d'inventaire de réseau.
1 DOMAINE DE L'INVENTION
L'invention se rapporte à la surveillance de réseaux. L'invention se rapporte plus particulièrement à la surveillance de réseaux comprenant des terminaux de communication. De tels terminaux de communication peuvent prendre la forme d'ordinateurs personnels, d'assistants personnels, de tablettes ou de téléphones intelligents. Plus spécifiquement encore, l'invention concerne l'inventaire de tels réseaux de communication.
L'inventaire d'un réseau de communication consiste d'une part à lister les hôtes présents sur ce réseau, et d'autre part pour chacun de ces hôtes, à obtenir la liste des logiciels qui y sont installés, ainsi que leurs versions. Il s'agit de trouver les systèmes d'exploitation utilisés, les serveurs installés et disponibles, mais aussi des clients utilisés. Un tel inventaire prend tout son sens dans les réseaux de communications modernes, particulièrement les réseaux locaux d'entreprises, dans lesquels de plus en plus de terminaux de nature différentes sont connectés.
La connaissance de l'inventaire d'un réseau est importante, autant pour un administrateur que pour un attaquant car elle donne un aperçu de la sécurité du réseau. En effet, connaître les versions des logiciels présents permet de savoir, via des bases de données publiques, les vulnérabilités potentielles de ces logiciels, et donc, des machines vulnérables.
Maintenir un inventaire précis et à jour nécessite l'utilisation de logiciels dédiés. D'une part, la taille croissante des réseaux ne permet plus d'établir de liste manuellement. D'autre part la possibilité, pour les utilisateurs, d'installer leurs propres logiciels, ainsi que les mises à jours constantes des logiciels ne permet pas de maintenir ces listes à jours manuellement.
2 SOLUTIONS DE L'ART ANTÉRIEUR
Depuis de nombreuses années, l'inventaire de réseau de communication est au centre des préoccupations tant de la part d'éditeurs de logiciels, qui tentent de fournir des solutions permettant de réaliser un tel inventaire de la manière la plus simple et la plus efficace possible, qu'au centre des préoccupations de groupes de personnes dont les intentions sont nettement moins louables, et pour lesquels l'obtention d'un inventaire de réseau permet de préparer des attaques destinées à récupérer des données confidentielles ou à mettre à mal un service de communication.
La méthode historique d'obtention d'inventaire consiste à se connecter manuellement aux serveurs du réseau de communication et à observer des bannières transmises par ces derniers. En effet, les différents logiciels de l'époque transmettaient au client leur nom, leur numéro de version, mais également le système d'exploitation les faisant fonctionner ainsi que sa version.
Depuis, et pour éviter que des attaquants ne devinent trop facilement les versions des logiciels installés, les services et logiciels sont moins verbeux et il est nécessaire d'utiliser des méthodes d'inventaire plus élaborées. Ainsi, on utilise des méthodes qui utilisent les protocoles de communications existants, par exemple à base de paquets (IP, pour « Internet Protocol », TCP pour « Transmission Control Protocol », UDP pour « User Datagram Protocol », etc.) pour réaliser l'inventaire. Parmi ces méthodes, on distingue les trois typologies d'approche suivantes : 1. les méthodes par agents : ces méthodes utilisent des agents logiciels installés sur chacun des postes surveillés et remontent les configurations de ces derniers vers un serveur central.
2. les méthodes actives : ces méthodes transmettent des paquets spécialement forgés vers les hôtes et analysent les réponses (ou l'absence de réponse) de ces derniers. On subdivise généralement les méthodes actives en deux catégories:
a. les méthodes à balayage de ports, consistant à découvrir les ports ouverts chez le destinataire des paquets transmis; b. la prise d'empreinte de systèmes, consistant à découvrir les systèmes d'exploitation hébergés sur les hôtes en fonction de règles de détection de systèmes et/ou de services.
3. les méthodes passives : ces méthodes ne transmettent pas de paquet sur le réseau mais effectuent une analyse du trafic capturé pour déterminer les services utilisant le réseau. On réalise alors un prise d'empreinte du ou des systèmes en appliquant sur des événements et/ou des paquets des règles de détection qui délivrent un résultat.
Récemment, une technique hybride a été proposée, elle utilise une première phase d'inventaire passif et une deuxième phase d'inventaire actif. Lors d'une requête d'un utilisateur en vue de construire un inventaire, si la connaissance de l'outil (qui met en œuvre la méthode hybride) ne permet pas d'y répondre, une phase active est instanciée pour tenter de compléter la base.
On ne détaille pas dans la présente divulgation, ces différentes méthodes qui sont considérées comme étant bien connues de l'homme du métier.
Pour ce qui est des méthodes à base d'agents, c'est l'approche la plus intrusive pour le réseau car elle nécessite d'installer des agents logiciels sur tous les postes surveillés. Ces derniers ont pour charge d'extraire la configuration du poste pour l'envoyer ensuite vers un serveur central. Bien que fiables, ces méthodes sont parfois jugées trop intrusives. Il est parfois impossible d'intervenir sur tous les postes du réseau (impossibilité technique, organisationnelle ou juridique). C'est pour répondre à ces problèmes que les méthodes actives ou passives ont été mises au point.
La méthode active du balayage de ports (« scan de ports ») regroupe les techniques consistant à découvrir les ports TCP et UDP ouverts sur un hôte et d'en déduire les services qui y fonctionnent. Initialement, les scans de ports étaient effectués en tentant de se connecter aux ports des serveurs. Une deuxième technique, moins lourde consistait à n'envoyer que le premier paquet TCP (le SYN) et d'attendre la réponse (qui dépend de l'ouverture du port). Cependant, les systèmes actuels comprennent en général des pare-feu (« firewall ») installés de manière standard qui limitent l'utilisation de telles techniques.
Les techniques actives de détection de systèmes et de services sont les premières à avoir été publiées. Elles faisaient suite à un besoin de détection des équipements présents sur le réseau. Toutes ces techniques fonctionnent sur le même principe : transmettre des paquets spécialement forgés et utiliser des signatures pour déduire le système en fonction des réponses reçues. Les différentes approches se focalisent plus sur les champs intéressants (des paquets transmis et reçus) que sur les techniques mises en œuvre. Elles mettent en œuvre des bases de données de règles de détection permettant de déterminer un système à l'aide des observations réalisées.
Les techniques passives ont été développées après les techniques actives. Elles font suite à un besoin de furtivité dans la phase de découverte des systèmes d'exploitation. En effet, suite à la publication des techniques actives, les outils de surveillance ont commencé à intégrer des règles de détection et des mécanismes pour détecter l'utilisation de ces outils.
Les techniques passives, bien que similaires dans leur démarche (déduire le système d'après les changements dans la valeur de certains champs), sont plus prolifiques en typologies de méthodes employées et la littérature propose plus d'originalité. Parmi les méthodes employées, certaines utilisent également des bases de données de règles de détection permettant de déterminer un système à l'aide des observations réalisées (c'est par exemple le cas du logiciel « pOf »). D'autres méthodes utilisent une classification naïve bayésienne à la place de règles de détection statiques. Dans le cadre de la prise d'empreinte de système d'exploitation, il est parfois nécessaire de choisir entre plusieurs possibilités. Que ce soit lors d'une observation, ou après une série d'observations. En effet, les règles de détection ou les systèmes utilisés proposent parfois plusieurs solutions différentes pour expliquer leurs observations. Au niveau atomique, c'est à dire après une seule observation, les systèmes à base de règles de détection choisissent le premier système listé (c'est par exemple le cas dans le logiciel « pOf »), les systèmes statistiques choisissent celui ayant la meilleure probabilité (exemple de Robert Beverly. "A robust classifier for passive tcp/ip ". In Fingerprinting, in PAM, 200). Ces méthodes ne gèrent pas les suites d'observations et des contradictions peuvent apparaître (dans « A robust classifier for passive tcp/ip », ces contradictions sont interprétées comme plusieurs machines partageant la même adresse IP, ce qui n'est évidemment pas forcément le cas, et donc génère une fausse interprétation). D'un autre côté, les méthodes actives, de par leur nature, gère nativement les séries d'observations. Deux approches différentes sont alors utilisées :
1. Dans une première approche, les requêtes (transmises par le dispositif en charge de réaliser l'inventaire) sont choisies à la manière d'un arbre de décision.Le dispositif sélectionne une requête permettant de supprimer des systèmes possibles jusqu'à ce qu'il n'en reste qu'un seul système possible.
Cette approche pose problème puisque l'on élimine automatiquement, avec un arbre de décision, un ensemble de possibilités sur la base de la concordance d'une requête avec une seule règle de détection, concordance qui peut s'avérer fausse.
2. Dans une deuxième approche, les systèmes se voient attribuer un score (initialement 0). Chaque fois qu'une règle de détection est validée, le score des systèmes concernés augmente (de 1 dans le cas du logiciel « nmap », d'un coefficient déterminé par un expert dans le cas du logiciel « Xprobe »). Le système choisi est celui ayant le meilleur résultat (exprimé en pourcentage du score maximal possible). Là encore, cette approche pose problème car le résultat obtenu n'a pas de réalité mathématique. Il s'agit plutôt d'une sélection arbitraire du système qui présente le meilleur score. 3 RÉSUMÉ DE L'INVENTION
L'invention ne pose pas ces problèmes liés aux méthodes de l'art antérieur. En effet, la présente divulgation propose un système d'inventaire d'un réseau, fournissant une probabilité associée à ses déductions et une capacité d'apprentissage.
Plus particulièrement, l'invention se rapporte à un procédé d'inventaire d'un réseau de communication, ledit réseau comprenant au moins un hôte h échangeant des données avec d'autres équipements dudit réseau.
Selon un mode de réalisation, ledit procédé comprenant les phases suivantes : une phase d'obtention d'au moins une empreinte E associée audit hôte h, ladite au moins une empreinte E comprenant au moins une notification de détection représentative d'au moins une activation d'au moins une règle de détection r par au moins un élément échangé sur ledit réseau et associé audit hôte A ; une phase d'obtention, à partir de ladite au moins une empreinte E, d'au moins une probabilité p de présence d'au moins un service s au sein dudit hôte h, à partir d'au moins une base de données probabiliste associant ladite au moins une règle de détection r à au moins une probabilité prédéterminée.
Ainsi, à la différence des méthodes de l'art antérieur, dans lesquelles des scores en pourcentage sont affectés aux hôtes et équipements du réseau de communication, l'invention permet d'obtenir un ensemble de probabilités associé aux règles déclenchées lors de la reconnaissance. Selon un mode de réalisation particulier, ledit procédé comprend en outre une phase préalable d'apprentissage comprenant une étape de remplissage de ladite base de données probabiliste à l'aide d'un réseau de communication comprenant des équipements connus. Selon un mode de réalisation particulier, ladite phase d'obtention de ladite au moins une empreinte E dudit hôte h comprend au moins une itération des étapes suivantes :
réception d'un élément en provenance dudit réseau de communication et associée audit hôte h ; application, audit élément, d'au moins une règle de détection r parmi une base de données de règles de détection R, délivrant une notification de détection ; sauvegarde, au sein d'une liste de notification de prise d'empreinte A, de ladite notification de détection lorsque ladite notification de détection est au moins partiellement positive, ladite liste de notification de prise d'empreinte A représentant ladite empreint E.
Selon un mode de réalisation particulier, ladite notification de détection délivrée lors de ladite application de ladite au moins une règle de détection délivre un résultat binaire.
Selon un mode de réalisation particulier, ladite notification de détection délivrée lors de ladite application de ladite au moins une règle de détection délivre un résultat probabiliste.
Selon un mode de réalisation particulier, ladite phase d'obtention d'au moins une probabilité p de présence d'au moins un service s au sein dudit hôte h comprend, pour chaque notification de ladite empreinte de détection E :
une étape d'obtention, à partir de ladite au moins une base de données probabiliste, d'au moins une probabilité ps associée à ladite notification ; une étape de calcul d'une probabilité résultante pr telle que :
Figure imgf000009_0001
dans laquelle pa désigne une probabilité antérieure associée dans une itération préalable ou 0 lorsque qu'aucune itération préalable n'a été mise en œuvre : une étape de sauvegarde de ladite probabilité résultante pr.
Selon un mode de réalisation particulier, lors du calcul de ladite probabilité résultante pr, ladite probabilité antérieure pa est affecté d'un coefficient cdt dont la valeur est fonction du temps écoulé entre lesdites notifications de ladite empreinte de détection et/ou d'un coefficient ayant une valeur prédéterminée.
L'invention concerne également un dispositif d'inventaire d'un réseau de communication, ledit réseau comprenant au moins un hôte h échangeant des données avec d'autres équipements dudit réseau.
Selon un mode de réalisation particulier, ledit dispositif comprend : - des moyens d'obtention d'au moins une empreinte E associée audit hôte h, ladite au moins une empreinte E comprenant au moins une notification de détection représentative d'au moins une activation d'au moins une règle de détection r par au moins un élément échangé sur ledit réseau et associé audit hôte h ; - des moyens d'obtention, à partir de ladite au moins une empreinte E, d'au moins une probabilité p de présence d'au moins un service s au sein dudit hôte h, à partir d'au moins une base de données probabiliste associant ladite au moins une règle de détection r à au moins une probabilité.
L'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, et comprenant des instructions de code de programme pour la mise en œuvre de la méthode précédemment décrite.
4 LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un synoptique d'un mode de réalisation de l'invention ; la figure 2 présente schématiquement un dispositif de mise en œuvre de l'invention.
5 DESCRIPTION DÉTAILLÉE DE L'INVENTION 5.1 Rappel du principe de l'invention
La méthode présentement décrite ne présente pas les inconvénients de l'art antérieur. Au contraire, la méthode décrite permet de prendre compte pour l'identification d'un système, les résultats précédemment obtenus. A la différence des techniques antérieures, cette prise en compte est effectuée de manière récursive et non discriminatoire : cela signifie par exemple que les inconvénients liés aux arbres de décision ne sont pas présents avec la méthode décrite. Cela signifie également que les inconvénients liés au scoring (attribution d'un pourcentage) n'est pas présent dans la méthode décrite.
Par ailleurs, la méthode décrite offre la possibilité de corriger des résultats erronés en mettant à jour la base de connaissance qui est utilisée pour obtenir les résultats d'identification de règles de détection.
Le principe général repose sur un calcul probabiliste récursif. Ce calcul permet, à la différence des techniques antérieures, d'obtenir une suite de probabilités d'appartenance ou de non appartenance. Ce calcul permet également d'éviter que certaines possibilités de concordance soient purement et simplement éliminées, comme cela est le cas d'autres systèmes.
Plus particulièrement, l'invention met en œuvre une technique dans laquelle une base de données probabiliste est utilisée. Cette base de données probabiliste répertorie, pour une règle de détection donnée, des probabilités associées à des systèmes (et/ou des services). L'invention utilise cette base de données de probabilités pour associer un hôte donné à une certaine quantité de services possibles, cette quantité de services possible étant fonction du déclenchement des règles de détection par rapport aux paquets « écoutés » sur le réseau.
Ainsi, de manière générale, l'invention se rapporte à une méthode d'inventaire d'un réseau de communication, ledit réseau comprenant au moins un hôte h échangeant des données avec d'autres équipements dudit réseau, ledit procédé comprenant les phases suivantes : une phase d'obtention d'au moins une empreinte E associée audit hôte h, ladite empreinte E comprenant au moins une notification de détection représentative d'au moins une activation d'au moins une règle de détection r par au moins un élément échangé sur ledit réseau et associé audit hôte h ; une phase d'obtention, à partir de ladite au moins une empreinte E, d'au moins une probabilité pde présence d'au moins un service s au sein dudit hôte h, à partir d'au moins une base de données probabiliste associant ladite au moins une règle de détection r à au moins une probabilité prédéterminée.
En d'autres termes, l'invention comprend les phases suivantes :
1. une phase d'observation a lieu, au cours de laquelle les données exploitables qui transitent sur le réseau (par exemple des paquets TCP, des paquets IP, etc.) sont utilisées pour former une empreinte et être injectées dans un module de prise d'empreinte. a. ce module de prise d'empreinte fonctionne de manière itérative et tente, au moins pour une portion des règles de détection de la base de données de règles de détection, d'appliquer ces règles de détection sur les données exploitables ; b. lorsqu'une donnée exploitable active une règle de détection r (le résultat binaire de activation est « 1 »), cette activation est conservée en base de données (ainsi que son association avec l'hôte h à l'origine de la donnée exploitable) pour être utilisée par la suite. c. le module de prise d'empreinte poursuit la prise d'empreinte tant que des données exploitables lui sont fournies. d. Pour un hôte donnée h, l'empreinte E, obtenue à l'issue de cette phase de prise d'empreinte, est constituée de la suite ordonnée ou non des règles de détection activées (n), et est enregistrée en base de données.
2. Lorsqu'une ou plusieurs empreintes sont disponibles, elles peuvent être utilisées par un module de calcul probabiliste. Ce module utilise une empreinte E pour calculer récursivement la probabilité de découverte d'un ou plusieurs systèmes (services) Si qui pourraient être associés à cette empreinte : a. pour chaque règle de détection rt activée d'une empreinte E, on identifie, au sein de la base de données, la liste des systèmes associés et leurs probabilités de présence respectives. b. ces probabilités sont combinées aux probabilités précédentes (ou à une probabilité 0 s'il s'agit de la première itération récursive) pour délivrer une probabilité résultante. c. ce processus récursif est mis en œuvre tant qu'il reste des règles de détection (associées à des probabilités) à traiter.
Le résultat obtenu à l'issue de cette phase de calcul probabiliste, pour un hôte h donné, est un ensemble de probabilités associées à un ou plusieurs systèmes (services).
On peut noter que selon l'invention, l'utilisation d'une base de données probabiliste permet d'obtenir un résultat mathématique qui représente une réelle connaissance. Ceci est bien différent des systèmes de l'art antérieur. En effet, il est très rare que la validation d'une règle puisse à coup sûr permettre l'identification d'un système. Il est plus logique (et plus intuitif) de considérer qu'un résultat donné représente une certaine probabilité. Par la suite, on présente notamment un mode de réalisation de l'invention.
Il est clair cependant que ce mode de réalisation ne limite en rien la portée de l'invention, et que d'autres modes de réalisation peuvent être envisagés sans sortir du cadre de l'invention.
5.2 Description d'un mode de réalisation On présente dans ce mode de réalisation, une mise en œuvre de la méthode précédemment décrite.
Ce mode de réalisation s'articule autour de quatre éléments complémentaires. La figure 1 schématise l'architecture globale de ce mode de réalisation et liste les quatre principaux éléments : - la mémoire (Mry), volatile ou non : stocke les connaissances à priori (les probabilités), les paramètres du modèle et les résultats intermédiaires ; le module de prise d'empreinte (ME) : écoute le réseau et notifie (enregistre dans la mémoire Mry) lorsque des règles de détection valident des paquets réseau ;
- le module d'estimation des probabilités (MP) utilise les notifications (issues du module de prise d'empreintes ME) et communique avec la mémoire {Mry) pour estimer la probabilité d'hébergement des services ; le module d'apprentissage des paramètres : communique avec la base de données( ry) pour mettre à jour les paramètres du modèle. Les modules de ce mode de réalisation peuvent être déployés sur des machines différentes, ou regroupés, totalement ou partiellement sur une seule et même machine et/ou dans un seul et même composant logiciel sans en changer les principes. La description de ce mode de réalisation suit les modules listés sur le schéma de la figure 1.
5.2.1 Mémoire
La mémoire permet d'accéder et de modifier les éléments suivants :
1. des listes :
a. La liste des services et/ou systèmes informatiques à prendre en compte (S) ;
b. La liste des hôtes observés (H) ;
c. La liste des règles de détection( ?) ;
d. La liste des notifications de la prise d'empreinte (A) ;
2. des compteurs :
a. le nombre de fois qu'une règle de détection a été validée pour un hôte hébergeant un service, sous la forme d'une table d'enregistrements de la forme (r, s, c) où « r » est une règle de détection, « s » est un service, et « c » est le compteur ; ces compteurs sont regroupés dans C.
b. le nombre de validation d'une règle de détection, ce nombre se calcule comme la somme des compteurs pour une règle de détection donnée, ces compteurs sont regroupés dans V.
3. des résultats intermédiaires :
a. les probabilités, pour les hôtes (h), que les services (s) y soient hébergés (notés Ph(s)), elle peut prendre la forme d'une table contenant des éléments de la forme d'enregistrements (h, s, Ph(s)) ; ces probabilités sont regroupées dans P.
Dans ce mode de réalisation, pour économiser l'espace mémoire, seul les enregistrements dont la probabilité est strictement positive sont stockés.
Au démarrage de l'outil, les listes des règles de détection et des services sont valorisées d'après des bases de connaissances à priori. Pour tout service qu'une règle de détection est capable de détecter (d'après les connaissances à priori), le compteur correspondant est initialisé à 1 (il est à 0 sinon). Les autres éléments sont vides et seront valorisés pendant l'exécution de l'outil.
5.2.2 Prise d'empreinte passive à base de règles de détection
La prise d'empreinte passive est réalisée par le module de prise d'empreinte ME. La prise d'empreinte passive utilise une approche par règle de détection binaire. Ces règles de détection prennent en entrée un paquet réseau et fournissent en sortie un booléen (décision vrai/faux). Le principe d'obtention d'un résultat associé à une règle de détection est donc simple.
D'une manière générale, tout système de règles de détection binaires est utilisable dans le cadre de ce mode de réalisation, la seule contrainte étant de fournir une indication binaire pour les éléments du trafic observé (« vrai » ou « 1 » pour une application de la règle de détection à un paquet et « faux » ou « 0 » pour une non-application de la règle de détection à un paquet).
Note : dans ce mode de réalisation de l'invention, l'indication binaire est privilégiée pour des raisons de simplicité. Bien entendu, une indication probabiliste est également envisagée. On obtiendrait alors un double système probabiliste. L'avantage d'un tel double système probabiliste est bien entendu le fait qu'une probabilité plus « affinée » sera obtenue au final.
A titre d'exemple, deux systèmes de règles de détection ont été utilisés : des règles de détection syntaxiques des paquets TCP/SYN (tirées des règles de détection de l'outil pOf), et des règles de détection par expression régulière portant sur les en-têtes du protocole HTTP.
Lorsqu'une règle de détection valide un paquet observé, le module de prise d'empreinte ME transmet (soit directement, soit sous la forme d'une création d'un enregistrement en base de données) une notification vers le module d'estimation de la probabilité MP. Cette notification comprend un horodatage, l'identifiant de la machine source du paquet et l'identifiant de la règle de détection qui a été validée. 5.2.3 Estimation de la probabilité d'hébergement par le module d'estimation
L'estimation de la probabilité d'hébergement (i.e. d'un service ou d'un système donné sur un hôte donné) par le module d'estimation des probabilités ( p)utilise la suite (ordonnée ou non) des notifications du module de prise d'empreinte ME précédent pour fournir une estimation de la probabilité qu'un service soit présent sur un hôte.
Une des difficultés de cette estimation réside dans les contraintes suivantes : une règle de détection ne détecte pas toujours le même service, mais un ensemble (une classe) de services qui partagent certaines propriétés dans les paquets qu'ils transmettent (par exemple, les systèmes Linux avec un noyau 2.6) ; plusieurs services équivalents peuvent être hébergés simultanément au sein d'un hôte. Il peut s'agir de services compatibles (des navigateurs webs par exemple), ou incompatibles (des systèmes d'exploitations), les différents systèmes partageant la même adresse, par exemple par l'intermédiaire d'un système de translation d'adresse (NAT).
Il est donc nécessaire de proposer une méthode qui tienne compte de ces difficultés tout en réalisant un calcul probabiliste qui tienne compte de la réalité.
5.2.3.1 Modélisation mathématique
Soit donc une suite de notifications N = {rij = (h, r, t)}. Ces notifications sont remontées par les sondes passives et contiennent l'information qu'une règle de détection r donnée à validé le trafic d'un hôte h un instant t donné.
Par commodité, nous définissons les fonctions h(n) et r(n) fournissant respectivement l'hôte et la règle de détection relative à une notification n. Une séquence de notification vide (ne contenant aucune notification) est notée ε. Pour une suite non vide de notification N = n0...nk, on note N0 = n0son premier élément et Ni..k = ni...rik la suite privée de son premier élément.
La probabilité qu'un hôte h héberge un service s est notée Pu(s) et se calcule en fonction de la suite des notifications :Ph(s) = Ph(s\N ). Intuitivement, l'événement "le service est à l 'origine d'une notification " correspond à l'événement "le service est à l 'origine de la première, ou à l 'une des suivantes ". La probabilité se calcule récursivement de la manière suivante :
( . ( 0 N = ε
W \N) - {Ph (s \No) + Ρ}ι(3 \Ν1Λ) - Ph(s \NQ) x ΡΗ(3 \Ν1Λ) sinon
La probabilité Ph(s\No) (c'est-à-dire la probabilité que le service soit à l'origine de la notification) ne dépend pas de l'hôte considéré (h) et peut donc s'exprimer plus simplement Ph(s\n) = P(s\r), c'est à dire la probabilité qu'un service soit à l'origine du trafic validé par une règle de détection.
Cette probabilité est estimée dans une phase d'apprentissage préalable (décrite ci-après).
5.2.3.2 Mise en œuyre de la méthode de calcul de probabilité La méthode de calcul de probabilité au sens de l'invention est mise en œuvre au sein d'un module spécifique de calcul de probabilité. Ce module utilise, en entrée, les notifications de la prise d'empreinte passive, une notification et notée (h, r, t) par la suite.
Avant de débuter les calculs, la liste des hôtes est actualisée ; si un hôte n'a pas encore été vu (c'est-à-dire qu'aucune probabilité n'a été calculé à son égard), le module de calcul de probabilité ajoute cet hôte dans la liste H des hôtes. La notification est ajoutée à la liste des traces A.
Pour estimer les probabilités, le module de calcul de probabilité effectue, dans ce mode de réalisation, les opérations suivantes : 1. Récupérer le nombre de validation de la règle de détection dans V (nombre qui est nommé v dans la suite). 2. Pour chaque compteur concernant la règle de détection r dans la liste C, effectuer les étapes suivantes :
(a) Extraire le service concerné (nommé s dans la suite)
(b) Extraire la valeur du compteur (nommé c par la suite)
(c) Calculer le coefficient ps = -, c'est-à-dire le rapport entre le nombre de validations de la règle de détection concernant ce service et le nombre de validations totale de la règle de détection.
(d) Extraire l'ancienne probabilité Pu(s) dans P, si elle n'existait pas encore, l'initialiser à 0 (nommé pa par la suite)
(e) Calculer la nouvelle probabilité résultante pr = pa + ps ~ a ps
(f) Mettre à jour probabilité Ρ ) = pr, et si pr vaut 0, ne plus stocker cette probabilité.
Notons que le calcul de probabilité en se basant sur des valeurs de compteur est une approcha parmi d'autres pour calculer la probabilité. Dans d'autres modes de réalisation, la probabilité associée à un service ou à un système peut déjà être présente dans la base de données probabiliste sans qu'il soit nécessaire d'effectuer le calcul du ratio ps.
5.2.3.3 Introduction d'un coefficient temporel
Afin de tenir compte du temps qui s'écoule entre les notifications de la prise d'empreinte (lorsque cet écoulement temporel a une signification), et donc d'obtenir un résultat qui a encore plus de sens, les inventeurs ont eu l'idée d'introduire deux caractéristiques complémentaires qui peuvent ou non être combinées.
La première caractéristique est l'insertion d'un ordonnancement dans la prise d'empreinte. Plus particulièrement, les notifications sont ordonnancées afin de tenir compte de la survenance réelle des événements (paquets, traces) qui ont déclenché les notifications.
Selon une deuxième caractéristique, qui peut être couplée à l'ordonnancement, le calcul tient compte de l'ordonnancement. L'idée générale est la suivante : l'inventaire n'est pas figé. À tout moment, des machines démarrent, s'arrêtent et les systèmes présents derrière une adresse peuvent changer (changement d'attribution des adresses via DHCP ou dual boot). Le procédé est alors amélioré pour pouvoir "oublier" ses précédentes déductions. Concrètement, la formule de calcul de probabilité est modifiée de la manière suivante : pr = cdt.pa * (1 -ps) + ps cdt signifie "c exposant dt" où dt est le temps écoulé entre la précédente mise à jour et la mise à jour courante (en secondes) et c est un coefficient. Le coefficient est adapté en fonction des besoins. Quand le coefficient « c » vaut " 1", le système n'oublie rien. Quand il vaut 0, il oublie tout. Plus on va de 0 à 1, plus on garde en mémoire des vieux événements et donc plus les probabilités « anciennes » conservent de la valeur.
Dans les systèmes très dynamiques (c'est-à-dire dans les systèmes ou le parc évolue vite), le coefficient c peut être proche de 0, puisque dans ce cas, les anciennes prévisions n'ont pas forcément de sens.
Dans ce cas, l'ordonnancement des traces et leur horodatage prend tout son sens. Il faut également stocker, dans la mémoire, le moment où les résultats stockés ont été calculés. Dans un autre mode de réalisation, il est également possible d'affecter un coefficient c aux anciennes probabilités, sans qu'il soit conditionné à un temps écoulé entre la précédente mise à jour et la mise à jour courante. Dans ce cas la formule ne tient pas compte du temps.
5.2.3.4 Exemple numérique d'application Pour cet exemple, nous considérons deux règles de détection (r r2) qui permettent de détecter chacune deux systèmes, dont l'un est en commun (soit au total trois systèmes si, s2 et sc- système commun). Le tableau 1 donne les probabilités de détection de ces deux règles de détection pour les trois systèmes. P(s\r) Sl S2 ri ½ 0 ½ r2 0 ½ ½
Tableau 1
Si les deux règles de détection génèrent des notifications pour un hôte h donné, l'estimation des probabilités engendre une probabilité plus grande pour le système en commun sc. Le tableau 2 montre un exemple de progression des probabilités associées aux trois services pour une suite arbitraire de notifications.
Figure imgf000021_0001
Tableau 2
Plus les notifications sont nombreuses, plus les probabilités augmentent asymptotiquement vers 1 , mais le système commun aux deux règles de détection conserve une probabilité supérieure aux deux autres (il converge plus vite). De ce tableau on déduit que, dans la mesure où les deux règles de détection permettent de qualifier deux systèmes, la reconnaissance, pour un hôte h donné, d'une activation tantôt de la règle de détectionr; et tantôt de la règle de détection^ fait plutôt pencher la balance en faveur du système commun. La méthode de l'invention permet ainsi de corroborer un résultat que l'on pourrait qualifier d'intuitif.
Notons qu'il n'est pas assuré que le système commun sc soit effectivement le système à l'origine des notifications. Il se pourrait fort bien qu'en définitive ce soit le système sjou le système s2 qui soit à l'origine des notifications. En effet, dans la mesure où ce sont bien des probabilités de détection qui servent de point de départ au calcul. Ainsi, par exemple, au regard des résultats du tableau 2, il y a à l'issu du calcul, 2% de chance que ce ne soit pas le système sc qui soit à l'origine des notifications. 5.2.4 Apprentissage des paramètres
L'apprentissage permet d'estimer le coefficient ps mentionné dans la section précédente via le calcul des compteurs. L'apprentissage prend en entrée une trace (A) de détection, et un inventaire explicite (fournis par un expert par exemple), sous la forme d'une table d'association entre les services et les hôtes (l H S).
Une première étape facultative d'initialisation peut être effectuée. Cette phase consiste à remettre l'ensemble des compteurs à 0. Lorsque cette étape n'est pas effectuée, les phases d'apprentissages consécutives se cumulent.
Ensuite, et pour chaque notification (h, r, t) dans la liste de notifications, l'apprentissage effectue les opérations suivantes :
1. Extraire de l'inventaire /, toutes les associations concernant l'hôte h. Pour chaque association (h, s), effectuer les étapes suivantes :
(a) Ajouter 1 au compteur C pour la règle de détection r et le service s ;
(b) Ajouter 1 au compteur F pour la règle de détection r. 5.3 Apport de ce mode de réalisation
Le calcul des probabilités fournies par ce mode de réalisation permet de mieux qualifier l'existence ou non d'un service derrière un hôte particulier. En effet, les systèmes actuels ne proposent que deux possibilités : proposer plusieurs résultats plus ou moins contradictoires sans possibilité pour l'utilisateur de trancher, ou choisir arbitrairement le système ayant la meilleure note.
Comme cela a été démontré dans l'exemple numérique, la méthode décrite est capable de quantifier la présence d'un système, et lorsque plusieurs solutions sont possibles, elle permet de les classer de la plus probable à la moins probable.
La probabilité fournie a un réel sens mathématique : elle quantifie la probabilité, au vu des observations, que le système concerné soit présent sur l'hôte. De faibles probabilités indiquent que le service a peu de chance d'être présent, mais qu'il peut être à l'origine de certaines observations réseaux. Une grande probabilité indique, à l'opposé, que le service à de grande chance d'être présent.
L'utilisation d'un cadre probabiliste permet également d'utiliser des règles de détection pour la prise d'empreinte très différentes dans leur nature et de corréler leurs résultats de manière homogène. Chaque règle de détection validée apportant de nouvelles connaissances sur le réseau surveillé et augmentant d'autant la précision de l'outil.
Cette augmentation s'est montrée significative lors de tests. En plus d'améliorer la précision générale de la méthode de l'invention, la phase d'apprentissage permet aussi d'améliorer la précision et la pertinence des règles de détection de la base. En effet, la base de données des règles de détection de pOf contient nombre d'erreurs (par exemple, des règles de détection sont référencées comme détectant les systèmes de la famille Windows Vista alors qu'elles détectent les systèmes de la famille XP). Sans apprentissage, l'outil est susceptible de détecter des systèmes erronés. Une fois la phase d'apprentissage effectuée, la base de connaissance se corrige et les détections sont, par voie de conséquence, plus précises. 5.4 Autres caractéristiques optionnelles et avantages
On présente, en relation avec la figure 2, un mode de réalisation d'un dispositif de d'inventaire au sens de l'invention.
Ce dernier comprend une mémoire M 21, une unité de traitement 22, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur Pg 23. À l'initialisation, les instructions de code du programme d'ordinateur 23 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 22. L'unité de traitement 22 reçoit en entrée les données 24 émises par les différents hôtes du réseau au sein duquel il faut réaliser l'inventaire (il s'agit par exemple de paquets TCP, IP ou d'entêtés HTTP). Le microprocesseur μΡ de l'unité de traitement 22 réalise une ou plusieurs empreintes passives de ces données 24, selon les instructions du programme Pg 23. L'unité de traitement 22 délivre en sortie des probabilités 25 (par exemple des listes de probabilités associées à différents services/systèmes), destinés à permettre de réaliser un inventaire du réseau.

Claims

REVENDICATIONS
Procédé d'inventaire d'un réseau de communication, ledit réseau comprenant au moins un hôte h échangeant des données avec d'autres équipements dudit réseau, ledit procédé comprenant les phases suivantes : une phase d'obtention d'au moins une empreinte E associée audit hôte h, ladite au moins une empreinte E comprenant au moins une notification de détection représentative d'au moins une activation d'au moins une règle de détection r par au moins un élément échangé sur ledit réseau et associé audit hôte h ; une phase d'obtention, à partir de ladite au moins une empreinte E, d'au moins une probabilité p de présence d'au moins un service s au sein dudit hôte h, à partir d'au moins une base de données probabiliste associant ladite au moins une règle de détection r à au moins une probabilité prédéterminée.
Procédé d'inventaire selon la revendication 1, caractérisé en ce qu'il comprend en outre une phase préalable d'apprentissage comprenant une étape de remplissage de ladite base de données probabiliste à l'aide d'un réseau de communication comprenant des équipements connus.
Procédé d'inventaire selon la revendication 1, caractérisé en ce que ladite phase d'obtention de ladite au moins une empreinte E dudit hôte h comprend au moins une itération des étapes suivantes :
réception d'un élément en provenance dudit réseau de communication et associée audit hôte h ; application, audit élément, d'au moins une règle de détection r parmi une base de données de règles de détection R, délivrant une notification de détection ; sauvegarde, au sein d'une liste de notification de prise d'empreinte A, de ladite notification de détection lorsque ladite notification de détection est au moins partiellement positive, ladite liste de notification de prise d'empreinte A représentant ladite empreint E.
Procédé d'inventaire selon la revendication 3, caractérisé en ce que ladite notification de détection délivrée lors de ladite application de ladite au moins une règle de détection délivre un résultat binaire.
Procédé d'inventaire selon la revendication 3, caractérisé en ce que ladite notification de détection délivrée lors de ladite application de ladite au moins une règle de détection délivre un résultat probabiliste.
Procédé d'inventaire selon la revendication 1, caractérisé en ce que ladite phase d'obtention d'au moins une probabilité p de présence d'au moins un service s au sein dudit hôte h comprend, pour chaque notification de ladite empreinte de détection E :
une étape d'obtention, à partir de ladite au moins une base de données probabiliste, d'au moins une probabilité ps associée à ladite notification ; une étape de calcul d'une probabilité résultante pr telle que :
Figure imgf000026_0001
dans laquelle pa désigne une probabilité antérieure associée dans une itération préalable ou 0 lorsque qu'aucune itération préalable n'a été mise en œuvre ; une étape de sauvegarde de ladite probabilité résultante pr.
Procédé d'inventaire selon la revendication 6, caractérisé en ce que, lors du calcul de ladite probabilité résultante pr, ladite probabilité antérieure pa est affecté d'un coefficient cdt dont la valeur est fonction du temps écoulé entre lesdites notifications de ladite empreinte de détection et/ou d'un coefficient ayant une valeur prédéterminée.
8. Dispositif d'inventaire d'un réseau de communication, ledit réseau comprenant au moins un hôte h échangeant des données avec d'autres équipements dudit réseau, ledit dispositif comprenant : des moyens d'obtention d'au moins une empreinte E associée audit hôte h, ladite au moins une empreinte E comprenant au moins une notification de détection représentative d'au moins une activation d'au moins une règle de détection r par au moins un élément échangé sur ledit réseau et associé audit hôte h ; des moyens d'obtention, à partir de ladite au moins une empreinte E, d'au moins une probabilité p de présence d'au moins un service s au sein dudit hôte h, à partir d'au moins une base de données probabiliste associant ladite au moins une règle de détection r à au moins une probabilité.
9. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de d'inventaire selon l'une au moins des revendications 1 à 7, lorsqu'il est exécuté sur un ordinateur.
PCT/EP2013/052691 2012-02-29 2013-02-11 Méthode d'inventaire de réseau WO2013127619A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1251858A FR2987534B1 (fr) 2012-02-29 2012-02-29 Methode d'inventaire de reseau.
FR1251858 2012-02-29

Publications (1)

Publication Number Publication Date
WO2013127619A1 true WO2013127619A1 (fr) 2013-09-06

Family

ID=47681929

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/052691 WO2013127619A1 (fr) 2012-02-29 2013-02-11 Méthode d'inventaire de réseau

Country Status (2)

Country Link
FR (1) FR2987534B1 (fr)
WO (1) WO2013127619A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030200304A1 (en) * 2002-04-18 2003-10-23 Thorpe John Robert Apparatus and method to automatically collect data regarding assets of a business entity
US20090037353A1 (en) * 2007-08-03 2009-02-05 Greenwald Lloyd G Method and system for evaluating tests used in operating system fingerprinting
US7519954B1 (en) * 2004-04-08 2009-04-14 Mcafee, Inc. System and method of operating system identification
US20090182864A1 (en) * 2008-01-15 2009-07-16 Faud Khan Method and apparatus for fingerprinting systems and operating systems in a network
US20110314143A1 (en) * 2010-06-22 2011-12-22 Sourcefire, Inc. System and method for resolving operating system or service identity conflicts

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030200304A1 (en) * 2002-04-18 2003-10-23 Thorpe John Robert Apparatus and method to automatically collect data regarding assets of a business entity
US7519954B1 (en) * 2004-04-08 2009-04-14 Mcafee, Inc. System and method of operating system identification
US20090037353A1 (en) * 2007-08-03 2009-02-05 Greenwald Lloyd G Method and system for evaluating tests used in operating system fingerprinting
US20090182864A1 (en) * 2008-01-15 2009-07-16 Faud Khan Method and apparatus for fingerprinting systems and operating systems in a network
US20110314143A1 (en) * 2010-06-22 2011-12-22 Sourcefire, Inc. System and method for resolving operating system or service identity conflicts

Also Published As

Publication number Publication date
FR2987534A1 (fr) 2013-08-30
FR2987534B1 (fr) 2014-02-28

Similar Documents

Publication Publication Date Title
EP3301617B1 (fr) Procédés d'apprentissage sécurisé de paramètres d'un réseau de neurones à convolution, et de classification sécurisée d'une donnée d'entrée
EP2548337B1 (fr) Procédé d'identification d'un protocole à l'origine d'un flux de données
EP0951155A1 (fr) Procédé et système d'administration de réseaux et de systèmes
CA2778847C (fr) Identification par controle de donnees biometriques d'utilisateur
FR3058243A1 (fr) Procede de controle d'identite d'un utilisateur au moyen d'une base de donnees publique
FR3106914A1 (fr) Procédé de surveillance de données échangées sur un réseau et dispositif de détection d’intrusions
WO2015044595A1 (fr) Procédé de détection d'anomalies dans un trafic réseau
FR2902954A1 (fr) Systeme et procede de stockage d'un inventaire des systemes et/ou services presents sur un reseau de communication
EP3549047B1 (fr) Procede d'authentification d'un equipement terminal, dispositif, equipement serveur et programme d'ordinateur associes
EP2849404B1 (fr) Procédé de détection d'intrusions non solliciteés dans un reseau d'information, dispositif, produit programme d'ordinateur et moyen de stockage correspondants
WO2013127619A1 (fr) Méthode d'inventaire de réseau
EP3316549A1 (fr) Procédé de contrôle d'identité d'un utilisateur au moyen d'une base de données publique
EP3857810B1 (fr) Procédé cryptographique de comparaison sécurisée de deux données secrètes x et y
CA2867241A1 (fr) Procede de cryptage d'une pluralite de donnees en un ensemble securise
EP3714588A1 (fr) Procede de gestion a distance d'un dispositif connecte a une passerelle residentielle
EP3495982B1 (fr) Procédé de détection d'une attaque informatique contre une base de données, produit programme d'ordinateur et système de détection associés
WO2018029564A1 (fr) Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central
EP3672209B1 (fr) Procédé d'identification de noeud de communication
EP3729768A1 (fr) Procédé de construction automatique de scénarios d'attaques informatiques, produit programme d'ordinateur et système de construction associés
EP3539259A1 (fr) Procédé et dispositif d'actualisation d'un modèle prédictif d'une variable relative à un terminal mobile
WO2011144880A1 (fr) Procédé et dispositif d'analyse de données interceptées sur un réseau ip pour la surveillance de l'activité des utilisateurs d'un site web
FR2955682A1 (fr) Procede de fourniture d'un code dynamique par l'intermediaire d'un telephone
FR2910204A1 (fr) Systeme et procede de surveillance passive d'un reseau de communication
EP2832074A1 (fr) Procédé de masquage des données composant un profil utilisateur associé à un noeud d'un réseau
EP2880558B1 (fr) Procédé de traitement de données pour analyse situationnelle

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13703429

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13703429

Country of ref document: EP

Kind code of ref document: A1