EP2572488A1 - 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 - Google Patents

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

Info

Publication number
EP2572488A1
EP2572488A1 EP11727248A EP11727248A EP2572488A1 EP 2572488 A1 EP2572488 A1 EP 2572488A1 EP 11727248 A EP11727248 A EP 11727248A EP 11727248 A EP11727248 A EP 11727248A EP 2572488 A1 EP2572488 A1 EP 2572488A1
Authority
EP
European Patent Office
Prior art keywords
frame
layer
data
packet
http
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP11727248A
Other languages
German (de)
English (en)
Inventor
Gregory Crapella
Thibaud Bazelle
Laurent Chollon
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
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 Thales SA filed Critical Thales SA
Publication of EP2572488A1 publication Critical patent/EP2572488A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • 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/04—Processing captured monitoring data, e.g. for logfile generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • the subject of the invention is that of methods and devices for real-time processing of a data stream intercepted on an IP communication network.
  • the legally authorized administration (noted ALA in the document) of a state is provided, by the host of the website or its administrator, one or more files "log", grouping the connection history on the website access server.
  • This approach involves making the host or administrator aware of the fact that the website he is hosting is listening.
  • the invention therefore aims to overcome the aforementioned problems by providing a method and an analysis device for processing, in real time, an intercepted data stream on an IP communication network for the detailed monitoring of the activity of the users of a website of interest.
  • the subject of the invention is a method for analyzing HTTP requests intercepted on an IP network for monitoring the activity of the users of a predetermined website, comprising the steps of:
  • selecting the acquired data frame if its bit structure satisfies a plurality of conditions comprising at least one condition corresponding to the IP layer of the frame, at least one condition corresponding to the transport layer of the frame and at least one condition corresponding to the application layer of the frame;
  • the method comprises one or more of the following characteristics, taken separately or in any technically possible combination:
  • the selection step allows the selection of a frame whose transport layer is a TCP layer and whose application layer is an HTTP layer.
  • said at least one condition on the IP layer, or said at least one condition on the TCP layer is to compare the length of a packet of bits included in the acquired frame, which packet is considered as being an IP packet, respectively a TCP packet, with a predefined length of the header of an IP packet, respectively a TCP packet.
  • said at least one condition on the IP layer consists in applying, on the header of a packet of bits included in the acquired frame , packet considered to be an IP packet, respectively an HTTP packet, a mask for extracting a group of bits and comparing this group of bits with expected binary value for a parameter present in the header of an IP packet, respectively the header of an HTTP packet.
  • the method comprises an additional step of formatting the extracted data according to a predetermined model, preferably by associating meta-data.
  • the invention also relates to a device for implementing the method according to any one of claims 1 to 5, characterized in that it comprises:
  • a selection means capable of verifying a plurality of conditions on the bit structure of an acquired data frame obtained at the output of the acquisition means, and comprising at least one verification routine of a condition corresponding to the IP layer of the frame, at least one check routine of a condition corresponding to the frame transport layer and at least one check routine of a condition corresponding to the frame application layer;
  • extraction means capable of extracting data from the application layer of a selected data frame obtained at the output of the selection means
  • recording means able to store the extracted data obtained at the output of the extraction module in a database.
  • the device comprises one or more of the following characteristics, taken separately or in any technically possible combination.
  • the selection means is adapted for selecting an acquired data frame whose transport layer is a TCP layer and whose application layer is an HTTP layer.
  • the device comprises a processing stage comprising a plurality of processing server computers, each processing server computer being connected to said IP communication network and comprising an instantiation of said acquisition, selection and extraction means.
  • the device further comprises a storage stage comprising a plurality of storage server computers, each storage server computer being connected to said plurality of processing server computers, being associated with at least one database, and comprising an instantiation of said storage means adapted to store the extracted data communicated by a processing server computer in the database associated with the storage server computer considered.
  • the device further comprises a reproduction stage comprising at least one rendering computer comprising interrogation means for the different databases of the storage stage.
  • the modularity of the device that is to say the separation into modules of the processing, storage and rendering steps, and the scalability of the device, that is to say the possibility of having several instances of each module, allows real-time analysis of an IP data stream with very high throughput and / or high volume.
  • the method makes it possible to process, in real time, a data stream having a very high bit rate, of the order of a few Gbits.
  • the extraction step of the data of interest for the monitoring of the website is performed only downstream of the selection step, on a reduced number of selected frames.
  • FIG. 1 is a schematic representation of the hardware architecture for the implementation of the processing method
  • FIG. 2 is a schematic representation of the various software for implementing the processing method
  • FIG. 3 is a schematic flow chart showing the different steps of the analysis method
  • FIG. 4 is a detailed flowchart representing the filtering step of the treatment method.
  • a computer comprises storage means, such as a random access memory RAM, a ROM and a storage space such as one or more hard disks, and calculation means, such as a processor, able to execute the instructions of computer programs that are stored in the storage means of the computer.
  • storage means such as a random access memory RAM, a ROM and a storage space such as one or more hard disks
  • calculation means such as a processor, able to execute the instructions of computer programs that are stored in the storage means of the computer.
  • a computer further includes input / output interfaces adapted for connecting the computer to at least one network enabling it to communicate with at least one other computer connected to that network.
  • the architecture 1 comprises a first client computer 10, a second client computer 12, and a third client computer 14.
  • the client computers 10 and 12 are of the personal computer (PC) type and the computer Client 14 is of the mobile phone type capable of connecting to a 3G type of cellular telephone network.
  • PC personal computer
  • the architecture 1 also comprises a server computer 20 constituting an HTTP or Web server. It hosts a website to watch.
  • Architecture 1 comprises two IP communication networks.
  • the first network is a Wi-Fi network
  • 30 is a network managed by an ISP that can cooperate with the ALA.
  • the second network 32 is managed by another operator.
  • the server 20 is connected to the second network. Alternatively, it belongs to the first network.
  • the networks 30 and 32 allow IP communication between a client computer 10,
  • the networks comprise a plurality of access devices 40, 42, 44 and 46 as well as a plurality of router equipment 50, 52 and 54, and interconnection equipment between networks 100 and 102.
  • a router equipment is able to re-transmit an incident IP packet to a node of the network that the router equipment chooses according to the address of the final recipient of the packet, address that the router equipment is able to read in the incident packet.
  • Interconnection equipment constitutes a network access point 30 for the other networks.
  • the interconnection equipments 100, 102 are managed by the access provider, in agreement with the other operator or operators of the other networks.
  • a client computer belonging to a user having a subscription with the service provider can be connected to the first network 30 in different ways.
  • the client computer 10 is connected to the access equipment 40 by a link of the type
  • the computer 12 is connected to the access equipment 42 by a link of the RTC type.
  • the mobile telephone 14 is connected by a wireless link to the access equipment 46.
  • An IP address is assigned to the client computer when it connects to the access equipment.
  • the device for implementing the treatment method is shown in FIG. 1 and is indicated by the general reference 150.
  • the device 150 comprises a first processing stage 152.
  • the processing stage comprises two processing server computers 200 and 202.
  • a processing server has an addressable memory space.
  • a processing server is connected, upstream, to the first IP network.
  • the first processing computer 200 is connected to the router 50 and the second processing computer 202 is connected to the interconnection equipment 100.
  • a processing server is connected, downstream, to one or more storage servers that will now be described.
  • the device 150 comprises a second storage stage 154.
  • the storage stage comprises three storage server computers 300, 302 and 304.
  • Each storage server is associated with a database, respectively 301, 303, 305.
  • the device 150 includes a reproduction stage 156.
  • the reproduction stage comprises a restitution client computer 400.
  • the restitution client computer is connected to each of the databases 301, 303, 305.
  • Passive interception software is stored and executed on one or more of the equipment of the first network managed by the service provider.
  • the interconnection equipment 100 implements interception software.
  • the interception software includes a filtering module for filtering duplicate HTTP requests including a URL that is part of a list of URLs or portions of reference URLs with which the filtering module is set.
  • the URL of the monitored website is mentioned in this reference list.
  • the interconnection equipment 100 is able to route an intercepted HTTP request to one of the processing servers 200, 202 of the device 150.
  • FIG. 2 represents a program whose execution allows the implementation of the treatment method.
  • this program is divided into different software programs, which are respectively stored and executed by computers different from the device 150.
  • Processing software 210 is stored on each of the processing servers 200, 202.
  • the processing software 210 is able to read a configuration file 21 1 containing the various parameters necessary for its operation, such as lengths, expressed in number of bits, corresponding to the lengths of the headers ("HEADER") of the packets of the various OSI layers encapsulated in a frame, masks for extracting groups of bits, and predefined values expected for these groups of bits.
  • various parameters necessary for its operation such as lengths, expressed in number of bits, corresponding to the lengths of the headers ("HEADER") of the packets of the various OSI layers encapsulated in a frame, masks for extracting groups of bits, and predefined values expected for these groups of bits.
  • the software 210 comprises an acquisition module 212 capable of listening to a predefined port of the processing server, the port on which the intercepted frames are incident.
  • the module 212 is capable of acquiring the entirety of an incident frame on the listened port, of storing the frame in the addressable memory space of the processing server, and of placing, in a stack 213 associated with a frame, a first pointer indicating the address of the first bit of this acquired frame.
  • the software 210 includes a selection module 214 capable of analyzing in depth the frames acquired.
  • the module 214 is able to access, bit by bit, the frames stored in the addressable memory space of the processing server.
  • the selection module is capable of adding or subtracting pointers from the stack 213 associated with a frame.
  • the module 214 comprises a plurality of verification routines:
  • a first routine for verifying a condition on the IP layer able to compare the length of a packet of bits included in a frame with a predefined length of the header of an IP packet
  • a second routine for verifying a condition on the IP layer capable of applying a second mask adapted to extract a second group of bits, and comparing this second group of bits with a second binary value corresponding to an expected value for a second group of bits, protocol parameter present in an IP packet header,
  • a third routine for checking a condition on the TCP layer able to compare the length of a packet of bits included in a frame with a predefined length of the header of a TCP packet
  • a fourth routine for checking a condition on the HTTP layer able to apply a fourth mask adapted to extract a fourth group of bits, and to compare this fourth group of bits with a fourth binary value corresponding to an expected value for a fourth type parameter, present in an HTTP packet header, and,
  • a fifth routine for verifying a condition on the HTTP layer able to apply a fifth mask adapted to extract a fifth group of bits, and to compare this fifth group of bits with at least a fifth binary value corresponding to an expected value for at least a portion of a URL parameter present in an HTTP packet header. All these verifications are carried out without de-encapsulating the different layers of the OSI model (IP, TCP and HTTP) thus making it possible to obtain reduced processing times and thus to be able to analyze a flow of data having a very high throughput.
  • IP IP, TCP and HTTP
  • the software 210 also includes a module 216 for extracting the data contained in an HTTP packet.
  • the module 216 outputs data, and adds associated meta-data. All of this data is called D.
  • the processing software 210 includes a module 218 for selecting the storage server from among the various servers constituting the storage stage 154.
  • the module 218 includes a table of occupancy 219 giving the address of the different storage servers 300, 302, 304, as well as their respective instant state of occupation among "free” and "busy” states.
  • the processing software 210 includes a coding and transmission module 220 capable of taking, as input, the address of the server chosen by the module 218, the port used, and the data produced by the module 216, then communicate this data D to the storage server chosen.
  • This data can be encrypted using for example the AES 256 encryption code known to those skilled in the art.
  • Storage software 310 is executed on each of the storage servers 300, 302, 304.
  • the storage software 310 is able to read a configuration file 31 1 containing the various parameters necessary for its operation.
  • the software 310 includes an acquisition module 312 able to listen to a predefined port of the storage server and to acquire the incoming D data.
  • the software 310 includes a decoding module 314 able to extract the data.
  • the software 310 comprises a module 316 able to decode the meta-data to the data D and to store all of this data in a file F. This file is placed in a particular directory of an archiving structure comprising a plurality of files. directories.
  • the software 310 includes a storage module 318 able to monitor the filling rate of each of the directories of the archiving structure, to compare this rate with a threshold value, and to store the contents of a directory in a table. particular of the database associated with the storage server.
  • a rendering software 410 is able to be executed by the rendering server
  • the software 410 includes a human / machine interface 1 12 for the development of complex queries for querying the databases 301, 303, 305.
  • the software 410 comprises a module 414 for interrogating the databases. It is capable of interpreting a complex query into a plurality of queries according to the query language used by the databases.
  • the module 414 is able to issue an interrogation request to the databases 301, 303, 305, and to receive the corresponding responses. It is capable of aggregating these responses before transmitting them to the interface module 412.
  • FIG. 5 recalling the binary structure of a frame.
  • the server 20 hosts a website on which users exchange data (such as written messages, photos, videos, binary files), deposited on the site and searchable through a suitable web page.
  • data such as written messages, photos, videos, binary files
  • ALA wishing to monitor itself website implements the process to acquire information about the users of this website.
  • the ALA then approaches the Internet access provider managing the first network to set the different instances of the interception software with, as a reference URL, the root of the Internet site to be monitored.
  • the interception software is executed.
  • the client station 10 When the user of the client station 10 posts a message on the website hosted by the server 20, the client station 10 sends an HTTP request whose header includes the method "POST", so that the server 20 , recipient, know how to interpret the HTTP message contained in the HTTP request.
  • the client station 10 issues an HTTP request whose header includes the method "G AND".
  • HTTP requests to the Web site accessible on the server 20 and passing on the equipment 100 are intercepted. They are duplicated and their copies are filtered. HTTP requests with the URL of the monitored website are sent to the device 150.
  • the original IP frames are not affected by the interception software, which ensures normal operation from the user's point of view.
  • the number of HTTP requests incident on the processing servers is very high.
  • the structure of the device 150 makes it possible to distribute this charge between the different processing servers.
  • the module 212 stores a complete frame, corresponding to an incident HTTP request, in the addressable memory space of the server 200.
  • a first pointer P1 is placed in a stack associated with this frame. The first pointer P1 indicates the memory address of the first bit of the frame to be filtered.
  • a selection step 614 consisting of an in-depth analysis of the bit structure of the frame.
  • the selection step 614 which is performed by the execution of the selection module 214, begins with the determination of the length L0 of the frame (step 1010 in FIG. 4). .
  • a second pointer P2 is placed in the stack associated with the frame. This second pointer points to an address of the memory space obtained by shifting a length L1 of the address indicated by the first pointer P1 (step 1020). Thus, the second pointer points to the first octet of the IP layer of the frame (level 3 layer of the OSI model).
  • the length L2 of the IP packet encapsulated in the frame is calculated in step 1030. This length L2 is obtained by subtracting the length L1 from the length L1.
  • the length L3 of the header of an IP packet is defined by the IP protocol. This length L3 makes it possible to verify a first condition which consists in comparing the length L2 of the IP packet with the length L3 (step 1040).
  • the length L2 is less than the length L3, it means that the packet in question is not an IP packet. As a result, the frame is rejected and the method proceeds to select the next frame.
  • the length L2 is greater than the length L3, it means that, if it is indeed an IP packet, it includes, in addition to an IP header, an IP message comprising possibly relevant data.
  • a second mask M2 is applied to the IP header of the IP packet ("HEADER" of the IP packet) so as to extract a second group of bits and to compare it with a second expected binary value d a second parameter relating to the protocol used in the transport layer (level 4 layer of the OSI model), the second parameter present in the IP header.
  • the second expected value corresponds to the use of the TCP protocol.
  • the frame is rejected and the process proceeds to the selection of the next frame.
  • a third pointer P3 is placed in step 1060 in the stack 213 associated with the frame. This third pointer points to an address obtained by shifting a length L3 of the address indicated by the second pointer P2. The third pointer indicates the beginning of the TCP layer of the frame.
  • a length L4 is calculated which corresponds to the length of the TCP packet. This length L4 is obtained by the difference between the length L2 and the length L3.
  • the length L5 of the header of a TCP packet is predetermined. This length L5 makes it possible to test a third condition which consists in comparing the length L4 of the TCP packet with the length L5 (step 1080).
  • the length L4 is less than the length L5, it means that the packet considered is not a TCP packet. As a result, the frame is rejected and the method proceeds to select the next frame.
  • the TCP packet includes, in addition to a TCP header, a TCP message that can contain relevant information.
  • a fourth pointer P4 is placed in the stack associated with the frame. This fourth pointer points to an address that corresponds to the offset of a length L5 of the address indicated by the third pointer P3. The fourth pointer points to the beginning of the HTTP layer of the studied frame (application layers 5 to 7 of the OSI model).
  • a fourth mask M4 is applied to the HTTP header to extract a fourth group of bits and compare it to a fourth expected bit value for a fourth type parameter of the HTTP packet.
  • the fourth expected value is the "POST" value or the "GET” value of this method parameter.
  • the frame is not considered and the method proceeds to the step of selecting the next frame.
  • a fifth mask M5 is applied to the HTTP header so as to compare a portion of the URL with a plurality of non-existent fifth values. desired corresponding to reference strings.
  • the method continues with a step 616 for extracting and reformatting the HTTP data by executing the module 216.
  • the data extracted from the HTTP header of the HTTP request is the URL, the address Source IP of the frame, the destination IP address of the frame, the "User-Agent” that is to say the identifier of the navigator used, and the "REFERER” that is to say the URL a web page that has a HyperText-type link, which the client has just followed, to access a resource on the monitored website. This can be a link on a page outside the monitored website, but also a link on the monitored website.
  • Each of these data is kept in an associated variable.
  • additional data are associated with the processed frame.
  • the URL of the HTTP request corresponds to a reference URLO which, in the configuration file 21 1, is associated with a particular type of case, such as the "terrorism" type, the type of case constitutes a meta-data associated with the frame during step 616.
  • step 618 the selection module 218 monitoring this buffer space, finds that a new data message has just been deposited there to be sent to a storage database.
  • the module 218 reads the table 219 in search of the address of a storage server 300, 302, 304 in the "free" state to which the data message is addressed.
  • the module 218 selects a destination storage server, for example the storage server 300.
  • the data message is therefore sent to the chosen storage server.
  • This message can be encrypted in AES 256.
  • a decoding step 714 makes it possible to recover the data D which is stored in a file F.
  • a classification step 716 of the data file then makes it possible to choose an archive directory for this file.
  • the choice of a particular directory is made on the basis of the metadata that has been associated with the file F.
  • the storage step in a database 301 associated with the storage server 300, step 718 in FIG. 3, is performed by the execution of the module 318 which continuously polls the fill rate of each directory in the archive structure.
  • the filling rate of a directory exceeds a predetermined threshold rate, the entire contents of this directory is saved in the database 301, in a table having a predetermined format.
  • step 812 off-line, through the man / machine interface 412 displayed on the display of the rendering server 400, an ALA member constructs complex queries for querying the databases 301, 303 , 305. This member uses a meta-language.
  • step 814 these complex requests are transmitted to the consultation module 414 which translates them into as many queries using the SQL language allowing a direct interrogation of the databases 301, 303 and / or 305.
  • the data extracted from the various databases of data are repatriated to the rendering server 400.
  • the consultation module 414 aggregates these different data so that they are presented to the operator through the interface 412.
  • the device and the method of treatment which have just been described make it possible to process a large volume data stream by a single processing server computer comprising a motherboard having standard characteristics.
  • the scale of the processing device being easily adaptable to the needs, by multiplying the computers composing each of the layers of the device, very high data streams can be processed by the device according to the invention. These high data streams are typically those found at the access point of a national subnet of the Internet.
  • the method avoids a multiplication of the calculation times and a considerable increase in the processing times required for each request, while enabling the extraction of a large amount of data necessary for monitoring the website and the activities of its users.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Ce procédé comporte les étapes consistant à: acquérir (612) la trame de données complète d'une requête HTTP; sélectionner (614) la trame de données acquise si sa structure binaire vérifie une pluralité de conditions comportant au moins une condition correspondant à la couche IP (1040, 1050) de la trame, au moins une condition correspondant à la couche de transport (1080) de la trame et au moins une condition correspondant à la couche d'application (1100, 1110) de la trame; extraire (616) des données d'intérêt de la couche d'application de la trame sélectionnée; enregistrer (618, 620, 712, 714, 716, 718) les données extraites, dans une base de données (301, 303, 305).

Description

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
L'invention a pour domaine celui des procédés et des dispositifs de traitement en temps réel d'un flux de données intercepté sur un réseau de communication IP.
Pour la surveillance d'un site Web particulier, l'administration légalement autorisée (notée ALA dans le document) d'un état se font remettre, par l'hébergeur du site Web ou son administrateur, un ou plusieurs fichiers « log », regroupant l'historique de la connexion sur le serveur d'accès au site Web.
Cette manière de faire implique de mettre l'hébergeur ou l'administrateur au courant du fait que le site Web qu'il héberge est sous écoute.
De plus, si l'hébergeur ou l'administrateur ne relève pas de la loi nationale, le site Web étant hébergé à l'étranger bien que les utilisateurs de ce site Web soient des nationaux de cet état, il est difficile pour l'ALA de contraindre l'hébergeur ou l'administrateur étranger de fournir les fichiers « log ».
L'invention a donc pour but de pallier aux problèmes précités en proposant un procédé et un dispositif d'analyse permettant de traiter, en temps réel, un flux de données interceptées sur un réseau de communication IP pour la surveillance détaillée de l'activité des utilisateurs d'un site Web d'intérêt.
Pour cela l'invention a pour objet un procédé d'analyse de requête HTTP interceptées sur un réseau IP pour la surveillance de l'activité des utilisateurs d'un site Web prédéterminé, comportant les étapes consistant à :
- acquérir la trame de données complète d'une requête HTTP;
- sélectionner la trame de données acquise si sa structure binaire vérifie une pluralité de conditions comportant au moins une condition correspondant à la couche IP de la trame, au moins une condition correspondant à la couche de transport de la trame et au moins une condition correspondant à la couche d'application de la trame;
- extraire des données d'intérêt de la couche d'application de la trame sélectionnée
- enregistrer les données extraites, dans une base de données.
Suivant des modes particuliers de réalisation, le procédé comporte une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaison techniquement possibles :
- l'étape de sélection permet la sélection d'une trame dont la couche de transport est une couche TCP et dont la couche d'application est une couche HTTP. - à l'étape de sélection, ladite au moins une condition sur la couche IP, respectivement ladite au moins une condition sur la couche TCP, consiste à comparer la longueur d'un paquet de bits inclus dans la trame acquise, paquet considéré comme étant un paquet IP, respectivement un paquet TCP, avec une longueur prédéfinie de l'en-tête d'un paquet IP, respectivement d'un paquet TCP.
- à l'étape de sélection, ladite au moins une condition sur la couche IP, respectivement ladite au moins une condition sur la couche HTTP, consiste à appliquer, sur l'en-tête d'un paquet de bits inclus dans la trame acquise, paquet considéré comme étant un paquet IP, respectivement un paquet HTTP, un masque pour extraire un groupe de bits et à comparer ce groupe de bits avec valeur binaire attendue pour un paramètre présent dans l'en-tête d'un paquet IP, respectivement l'en-tête d'un paquet HTTP.
- entre l'étape consistant à extraire les données de la couche d'application de ladite trame et à enregistrer ces données dans une base de données, le procédé comporte une étape supplémentaire consistant à mettre en forme les données extraites selon un modèle prédéterminé, de préférence en y associant des meta-données.
L'invention a également pour objet un dispositif pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comporte :
- un moyen d'acquisition d'une trame de données complète d'une requête HTTP interceptée sur un réseau de communication IP auquel ledit dispositif est connecté ;
- un moyen de sélection propre à vérifier une pluralité de conditions sur la structure binaire d'une trame de données acquise obtenue en sortie du moyen d'acquisition, et comportant au moins une routine de vérification d'une condition correspondant à la couche IP de la trame, au moins une routine de vérification d'une condition correspondant à la couche de transport de la trame et au moins une routine de vérification d'une condition correspondant à la couche d'application de la trame ;
- un moyen d'extraction apte à extraire des données de la couche d'application d'une trame de données sélectionnée obtenue en sortie du moyen de sélection ;
- un moyen d'enregistrement apte à stocker les données extraites obtenues en sortie du module d'extraction dans une base de données.
Suivant des modes particuliers de réalisation, le dispositif comporte une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles.
- le moyen de sélection est adapté pour la sélection d'une trame de données acquises dont la couche de transport est une couche TCP et dont la couche d'application est une couche HTTP. - le dispositif comporte un étage de traitement comportant une pluralité d'ordinateurs serveur de traitement, chaque ordinateur serveur de traitement étant connecté audit réseau de communication IP et comportant une instanciation desdits moyens d'acquisition, de sélection et d'extraction.
- le dispositif comporte, en outre, un étage de stockage comportant une pluralité d'ordinateurs serveur de stockage, chaque ordinateur serveur de stockage étant connecté à ladite pluralité d'ordinateurs serveur de traitement, étant associé à au moins une base de données, et comportant une instanciation desdits moyens de stockage apte à stocker les données extraites communiquées par un ordinateur serveur de traitement dans la base de données associée à l'ordinateur serveur de stockage considéré.
- le dispositif comporte, en outre, un étage de restitution comportant au moins un ordinateur de restitution comportant des moyens d'interrogation des différentes bases de données de l'étage de stockage.
La modularité du dispositif, c'est à dire la séparation en modules des étapes de traitement, de stockage et de restitution, et l'extensibilité du dispositif, c'est-à-dire la possibilité d'avoir plusieurs instances de chaque module, autorise l'analyse, en temps réel, d'un flux de données IP présentant un débit très élevé et/ou un volume important.
Grâce à la mise en œuvre d'une étape de sélection comportant une analyse « en profondeur » des données IP incidentes, c'est-à-dire une analyse au niveau binaire des trames, le procédé permet de traiter, en temps réel, un flux de données présentant un débit très élevé, de l'ordre de quelques Gbits. L'étape d'extraction des données présentant un intérêt pour la surveillance du site Web n'est réalisée qu'en aval de l'étape de sélection, sur un nombre réduit de trames sélectionnées.
L'invention et ses avantages seront mieux compris à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés sur lesquels :
- la figure 1 est une représentation schématique de l'architecture matérielle pour la mise en œuvre du procédé de traitement ;
- la figure 2 est une représentation schématique des différents logiciels permettant la mise en œuvre du procédé de traitement ;
- la figure 3 est un organigramme schématique représentant les différentes étapes du procédé d'analyse ;
- la figure 4 est un organigramme détaillé représentant l'étape de filtrage du procédé de traitement ; et,
- la figure 5 représente les différentes couches d'une trame. De manière générique, un ordinateur comporte des moyens de mémorisation, tels qu'une mémoire vive RAM, une mémoire morte ROM et un espace de stockage tels qu'un ou plusieurs disques durs, et des moyens de calcul, tels qu'un processeur, aptes à exécuter les instructions de programmes informatiques qui sont stockées dans les moyens de mémorisation de l'ordinateur.
Un ordinateur comporte en outre des interfaces entrée/sortie adaptées pour la connexion de l'ordinateur à au moins un réseau lui permettant d'entrer en communication avec au moins un autre ordinateur connecté à ce réseau.
En se référant à la figure 1 , l'architecture 1 comporte un premier ordinateur client 10, un second ordinateur client 12, et un troisième ordinateur client 14. Les ordinateurs client 10 et 12 sont du type ordinateur personnel (PC) et l'ordinateur client 14 est du type téléphone mobile capable de se connecter à un réseau de téléphonie cellulaire du type 3G.
L'architecture 1 comporte également un ordinateur serveur 20 constituant un serveur HTTP ou Web. Il héberge un site Web à surveiller.
L'architecture 1 comporte deux réseaux de communication IP. Le premier réseau
30 est un réseau géré par un fournisseur d'accès à Internet pouvant coopérer avec l'ALA.
Le second réseau 32 est géré par un autre opérateur. Le serveur 20 est connecté au second réseau. En variante, il appartient au premier réseau.
Les réseaux 30 et 32 autorisent la communication IP entre un ordinateur client 10,
12, 14 et le serveur HTTP 20. Les réseaux comportent une pluralité d'équipements d'accès 40, 42, 44 et 46 ainsi qu'une pluralité d'équipements routeur 50, 52 et 54, et d'équipement d'interconnexion entre réseaux 100 et 102.
Un équipement routeur est apte à réémettre un paquet IP incident vers un nœud du réseau que l'équipement routeur choisit en fonction de l'adresse du destinataire final du paquet, adresse que l'équipement routeur est apte à lire dans le paquet incident.
Un équipement d'interconnexion constitue un point d'accès au réseau 30 pour les autres réseaux. Les équipements d'interconnexion 100, 102 sont gérés par le fournisseur d'accès, en accord avec le ou les autres opérateurs des autres réseaux.
Un ordinateur client appartenant à un utilisateur ayant un abonnement auprès du fournisseur d'accès peut être connecté au premier réseau 30 de différentes manières.
Ainsi, l'ordinateur client 10 est connecté à l'équipement d'accès 40 par un lien du type
ADSL. L'ordinateur 12 est connecté à l'équipement d'accès 42 par un lien du type RTC.
Le téléphone mobile 14 est connecté par un lien hertzien à l'équipement d'accès 46. Une adresse IP est attribuée à l'ordinateur client lorsqu'il se connecte à l'équipement d'accès. Le dispositif pour la mise en œuvre du procédé de traitement est représenté sur la figure 1 et est indiqué par la référence générale 150.
Le dispositif 150 comporte un premier étage de traitement 152. Sur la figure 1 , l'étage de traitement comporte deux ordinateurs serveur de traitement 200 et 202.
Un serveur de traitement comporte un espace de mémoire adressable.
Un serveur de traitement est connecté, en amont, au premier réseau IP. Ainsi le premier ordinateur de traitement 200 est connecté au routeur 50 et le second ordinateur de traitement 202 est connecté à l'équipement d'interconnexion 100.
Un serveur de traitement est connecté, en aval, à un ou plusieurs serveurs de stockage qui vont maintenant être décrits.
Le dispositif 150 comporte un second étage de stockage 154. Sur la figure 1 , l'étage de stockage comporte trois ordinateurs serveur de stockage 300, 302 et 304. Chaque serveur de stockage est associé à une base de données, respectivement 301 , 303, 305.
Enfin, le dispositif 150 comporte un étage de restitution 156. Sur la figure 1 , l'étage de restitution comporte un ordinateur client de restitution 400. L'ordinateur client de restitution est connecté à chacune des bases de données 301 , 303, 305.
Un logiciel d'interception passive est stocké et exécuté sur un ou plusieurs des équipements du premier réseau géré par le fournisseur d'accès. Par exemple, l'équipement d'interconnexion 100 met en œuvre un logiciel d'interception. Celui-ci comporte un module de duplication du type « port mirroring » pour dupliquer la totalité des requêtes HTTP transitant sur l'équipement 100.
Le logiciel d'interception comporte un module de filtrage permettant de filtrer les requêtes HTTP dupliquées comportant une URL faisant partie d'une liste d'URLs ou de parties d'URL de référence avec laquelle le module de filtrage est paramétré. L'URL du site Web surveillé est mentionnée dans cette liste de référence.
L'équipement d'interconnexion 100 est propre à router une requête HTTP interceptée vers l'un des serveurs de traitement 200, 202 du dispositif 150.
La figure 2 représente un programme dont l'exécution permet la mise en oeuvre du procédé de traitement. Dans le mode de réalisation décrit, ce programme est réparti en différents logiciels, qui sont respectivement mémorisés et exécutés par des ordinateurs différents du dispositif 150.
Un logiciel de traitement 210 est mémorisé sur chacun des serveurs de traitement 200, 202.
Le logiciel de traitement 210 est capable de lire un fichier de configuration 21 1 contenant les différents paramètres nécessaires à son fonctionnement, tels que des longueurs, exprimées en nombre de bits, correspondant aux longueurs des en-têtes (« HEADER ») des paquets des différentes couches OSI encapsulées dans une trame, des masques d'extraction de groupes de bits, et des valeurs prédéfinies attendues pour ces groupes de bits.
Le logiciel 210 comporte un module d'acquisition 212 capable d'écouter un port prédéfini du serveur de traitement, port sur lequel les trames interceptées sont incidentes. Le module 212 est capable d'acquérir l'intégralité d'une trame incidente sur le port écouté, de stocker la trame dans l'espace de mémoire adressable du serveur de traitement, et de placer, dans une pile 213 associée à une trame, un premier pointeur indiquant l'adresse du premier bit de cette trame acquise.
Le logiciel 210 comporte un module de sélection 214 apte à analyser en profondeur les trames acquises. Le module 214 est capable d'accéder, bit à bit, aux trames mémorisées dans l'espace de mémoire adressable du serveur de traitement. Le module de sélection est capable d'ajouter ou de soustraire des pointeurs de la pile 213 associée à une trame.
Le module 214 comporte une pluralité de routines de vérification :
- une première routine de vérification d'une condition sur la couche IP, apte à comparer la longueur d'un paquet de bits inclus dans une trame avec une longueur prédéfinie de l'entête d'un paquet IP,
- une seconde routine de vérification d'une condition sur la couche IP, apte à appliquer un second masque adapté pour extraire un second groupe de bits, et à comparer ce second groupe de bit avec une seconde valeur binaire correspondant à une valeur attendue pour un paramètre de protocole présent dans un en-tête de paquet IP,
- une troisième routine de vérification d'une condition sur la couche TCP, apte à comparer la longueur d'un paquet de bits inclus dans une trame avec une longueur prédéfinie de l'en-tête d'un paquet TCP,
- une quatrième routine de vérification d'une condition sur la couche HTTP, apte à appliquer un quatrième masque adapté pour extraire un quatrième groupe de bits, et à comparer ce quatrième groupe de bits avec une quatrième valeur binaire correspondant à une valeur attendue pour un paramètre de type, présent dans un en-tête de paquet HTTP, et,
- une cinquième routine de vérification d'une condition sur la couche HTTP, apte à appliquer un cinquième masque adapté pour extraire un cinquième groupe de bits, et à comparer ce cinquième groupe de bits avec au moins une cinquième valeur binaire correspondant à une valeur attendue pour au moins une portion d'un paramètre d'URL présent dans un en-tête de paquet HTTP. Toutes ces vérifications sont effectuées sans désencapsuler les différentes couches du modèle OSI (IP, TCP et HTTP) permettant ainsi d'obtenir des temps de traitement réduits et donc de pouvoir analyser un flux de donnée ayant un débit très important.
Le logiciel 210 comporte également un module 216 d'extraction des données contenues dans un paquet HTTP. Le module 216 génère en sortie des données, et ajoute des meta-données associées. L'ensemble de ces données est appelé D.
Le logiciel de traitement 210 comporte un module 218 de sélection du serveur de stockage parmi les différents serveurs constituant l'étage de stockage 154. Le module 218 comporte une table d'occupation 219 donnant l'adresse des différents serveurs de stockage 300, 302, 304, ainsi que leur état respectif instantané d'occupation parmi des états « libre » et « occupé ».
Enfin, le logiciel de traitement 210 comporte un module 220 de codage et d'émission capable de prendre, en entrée, l'adresse du serveur choisi par le module 218, le port utilisé, et les données produites par le module 216, puis de communiquer ces données D au serveur de stockage choisi. Ces données peuvent être chiffrées en utilisant par exemple le code de cryptage AES 256 connu de l'homme du métier.
Un logiciel de stockage 310 est exécuté sur chacun des serveurs de stockage 300, 302, 304.
Le logiciel de stockage 310 est capable de lire un fichier de configuration 31 1 contenant les différents paramètres nécessaires à son fonctionnement.
Le logiciel 310 comporte un module d'acquisition 312 apte à écouter un port prédéfini du serveur de stockage et à acquérir les données D entrantes.
Le logiciel 310 comporte un module de décodage 314 apte à extraire les données. Le logiciel 310 comporte un module 316 propre à décoder les meta-données aux données D et à stocker l'ensemble de ces données dans un fichier F. Celui-ci est placé dans un répertoire particulier d'une structure d'archivage comportant une pluralité de répertoires.
Enfin, le logiciel 310 comporte un module de stockage 318 propre à surveiller le taux de remplissage de chacun des répertoires de la structure d'archivage, à comparer ce taux avec une valeur seuil, et à stocker le contenu d'un répertoire dans une table particulière de la base de données associée au serveur de stockage.
Un logiciel de restitution 410 est propre à être exécuté par le serveur de restitution
400.
Le logiciel 410 comporte une interface homme/machine 1 12 permettant l'élaboration de requêtes complexes d'interrogation des bases de données 301 , 303, 305. Le logiciel 410 comporte un module 414 d'interrogation des bases de données. Il est capable d'interpréter une requête complexe en une pluralité de requêtes conformes au langage d'interrogation utilisé par les bases de données. Le module 414 est propre à émettre une requête d'interrogation vers les bases de données 301 , 303, 305, et à recevoir les réponses correspondantes. Il est capable d'agréger ces réponses avant de les transmettre au module d'interface 412.
Le procédé d'analyse va maintenant être décrit en référence aux figures 3 et 4, la figure 5 rappelant la structure binaire d'une trame.
Le serveur 20 héberge un site Web sur lequel des utilisateurs échangent des données (telles que messages écrits, photos, vidéos, fichiers binaires), déposés sur le site et consultables au travers d'une page Web adaptée.
L'ALA souhaitant surveiller se site Web met en œuvre le procédé pour acquérir des informations sur les utilisateurs de ce site Web.
L'ALA se rapproche alors du fournisseur d'accès à l'Internet gérant le premier réseau pour qu'il paramètre les différents instances du logiciel d'interception avec, comme URL de référence, la racine du site Internet à surveiller. Les logiciels d'interception sont exécutés.
Lorsque l'utilisateur du poste client 10 dépose un message sur le site Web hébergé par le serveur 20, le poste client 10 émet une requête HTTP dont l'en-tête comporte la méthode « POST », de manière à ce que le serveur 20, destinataire, sache comment interpréter le message HTTP contenu dans la requête HTTP.
De manière similaire, lorsque l'utilisateur du poste 10 consulte une page du site Web, le poste client 10 émet une requête HTTP dont l'en-tête comporte la méthode « G ET ».
Grâce au logiciel d'interception passive exécuté sur l'équipement d'interconnexion
100 les requêtes HTTP à destination du site Web accessible sur le serveur 20 et transitant sur l'équipement 100 sont interceptées. Elles sont dupliquées et leurs copies sont filtrées. Les requêtes HTTP comportant l'URL du site Web surveillé sont envoyées vers le dispositif 150. Les trames IP originales ne sont absolument pas impactées par le logiciel d'interception, ce qui garantit un fonctionnement normal du point de vue de l'utilisateur.
Le nombre des requêtes HTTP incidentes sur les serveurs de traitement est très élevé. La structure du dispositif 150 permet de repartir cette charge entre les différents serveurs de traitement.
Par l'exécution du logiciel de traitement 210, les étapes de traitement suivantes sont mises en œuvre au niveau du serveur 200. Dans une étape initiale d'acquisition 612, le module 212 stocke une trame complète, correspondant à une requête HTTP incidente, dans l'espace mémoire adressable du serveur 200. Un premier pointeur P1 est placé dans une pile associée à cette trame. Le premier pointeur P1 indique l'adresse mémoire du premier bit de la trame à filtrer.
Puis, le procédé se poursuit par une étape de sélection 614 consistant en une analyse, en profondeur, de la structure binaire de la trame.
Comme cela est représenté en détail sur la figure 4, l'étape de sélection 614, qui est réalisée par l'exécution du module de sélection 214, débute par la détermination de la longueur L0 de la trame (étape 1010 sur la figure 4).
L'en-tête de la couche de transport d'une trame (couches 2 du modèle OSI) ayant une première longueur prédéterminée L1 , un second pointeur P2 est placé dans la pile associée à la trame. Ce second pointeur pointe vers une adresse de l'espace mémoire obtenue par décalage d'une longueur L1 de l'adresse indiquée par le premier pointeur P1 (étape 1020). Ainsi, le second pointeur pointe sur le premier octet de la couche IP de la trame (couche de niveau 3 du modèle OSI).
La longueur L2 du paquet IP encapsulé dans la trame est calculée à l'étape 1030. Cette longueur L2 est obtenue en soustrayant à la longueur L0, la longueur L1 .
La longueur L3 de l'en-tête d'un paquet IP est définie par le protocole IP. Cette longueur L3 permet de vérifier une première condition qui consiste à comparer la longueur L2 du paquet IP à la longueur L3 (étape 1040).
Si la longueur L2 est inférieure à la longueur L3, cela signifie que le paquet considéré n'est pas un paquet IP. En conséquence, la trame est rejetée et le procédé passe à la sélection de la trame suivante.
En revanche, si la longueur L2 est supérieure à la longueur L3, cela signifie que, s'il s'agit effectivement d'un paquet IP, celui-ci comporte, en plus d'un en-tête IP, un message IP comportant éventuellement des données pertinentes.
A l'étape 1050, un second masque M2 est appliqué sur l'en-tête IP du paquet IP (« HEADER » du paquet IP) de manière à extraire un second groupe de bits et à le comparer à une seconde valeur binaire attendue d'un second paramètre relatif au protocole utilisé dans la couche de transport (couche de niveau 4 du modèle OSI), second paramètre présent dans l'en-tête IP. Dans le présent mode de réalisation, la seconde valeur attendue correspond à l'utilisation du protocole TCP.
A l'issue de la vérification de cette seconde condition, si la valeur du second paramètre de protocole est différente de « TCP », la trame est rejetée et le procédé passe à la sélection de la trame suivante. En revanche, si la valeur du second paramètre de protocole est égale à « TCP » , un troisième pointeur P3 est placé, à l'étape 1060, dans la pile 213 associée à la trame. Ce troisième pointeur pointe sur une adresse obtenue par décalage d'une longueur L3 de l'adresse indiquée par le second pointeur P2. Le troisième pointeur indique le début de la couche TCP de la trame.
A l'étape 1070, une longueur L4 est calculée qui correspond à la longueur du paquet TCP. Cette longueur L4 est obtenue par la différence entre la longueur L2 et la longueur L3.
La longueur L5 de l'en-tête d'un paquet TCP est prédéterminée. Cette longueur L5 permet la tester une troisième condition qui consiste à comparer la longueur L4 du paquet TCP à la longueur L5 (étape 1080).
Si la longueur L4 est inférieure à la longueur L5, cela signifie que le paquet considéré n'est pas un paquet TCP. En conséquence, la trame est rejetée et le procédé passe à la sélection de la trame suivante.
En revanche, si la longueur L4 est supérieure à la longueur L5, le paquet TCP comporte, en plus d'un en-tête TCP, un message TCP pouvant contenir des informations pertinentes.
A l'étape 1090, un quatrième pointeur P4 est placé dans la pile associée à la trame. Ce quatrième pointeur pointe vers une adresse qui correspond au décalage d'une longueur L5 de l'adresse indiqué par le troisième pointeur P3. Le quatrième pointeur pointe sur le début de la couche HTTP de la trame étudiée (couches d'application 5 à 7 du modèle OSI).
Puis, à l'étape 1 100, un quatrième masque M4 est appliqué sur l'en-tête HTTP de manière à extraire un quatrième groupe de bits et à le comparer à une quatrième valeur binaire attendue pour un quatrième paramètre de type du paquet HTTP. La quatrième valeur attendue est la valeur « POST » ou la valeur « GET » de ce paramètre de méthode.
Si la méthode HTTP utilisée n'est pas l'une des deux méthodes précédentes, la trame n'est pas considérée et le procédé passe à l'étape de sélection de la trame suivante.
Si la méthode HTTP est un POST ou un GET, à l'étape 1 1 10, un cinquième masque M5 est appliqué sur l'en-tête HTTP de manière à comparer une partie de l'URL à une pluralité de cinquième valeurs non-souhaitées correspondant à des chaînes de caractères de référence.
Si la comparaison s'avère positive, la trame est rejetée sinon la trame est sélectionnée. Ce dernier test permet, par exemple, d'écarter les requêtes HTTP comportant un message correspondant à une image, en mentionnant la chaîne « .jpg »dans la liste des chaînes de caractères de référence.
Pour une trame sélectionnée, le procédé se poursuit par une étape 616 d'extraction et de reformatage des données HTTP par exécution du module 216. Les données extraites de l'en-tête HTTP de la requête HTTP sont l'URL, l'adresse IP source de la trame, l'adresse IP destinataire de la trame, le « User-Agent » c'est-à-dire l'identifiant du navigateur utilisé, et le « REFERER » c'est-à-dire l'URL d'une page Web sur laquelle se situe un lien du type HyperText, que le client vient de suivre, pour accéder à une ressource du site Web surveillé. Cela peut être un lien sur une page extérieure au site Web surveillé, mais également un lien sur le site Web surveillé.
Chacune de ces données est conservée dans une variable associée.
Avantageusement, des données supplémentaires, dites meta-données, sont associées à la trame traitée. Ainsi, si l'URL de la requête HTTP correspond à une URLO de référence qui, dans le fichier de configuration 21 1 , est associée à un type d'affaire particulier, tel que le type « terrorisme », le type d'affaire constitue une meta-donnée associée à la trame lors de l'étape 616.
Un ensemble de données et de meta-données, composant un message de données D, est finalement mémorisé dans un espace mémoire tampon du serveur de traitement 200.
A l'étape 618, le module de sélection 218 surveillant cet espace mémoire tampon, constate qu'un nouveau message de données vient d'y être déposé afin d'être envoyé vers une base de données de stockage.
Le module 218 lit la table 219 à la recherche de l'adresse d'un serveur de stockage 300, 302, 304 dans l'état « libre » auquel adresser le message de données. Le module 218 sélectionne un serveur de stockage destinataire, par exemple le serveur de stockage 300.
Le message de données est donc envoyé au serveur de stockage choisi. Ce message peut être chiffré en AES 256. Du côté du serveur de stockage 300, après une étape 712 d'acquisition du message de données D, une étape de décodage 714 permet de récupérer les données D qui sont stockées dans un fichier F.
Une étape de classification 716 du fichier de données permet alors de choisir un répertoire d'archivage pour ce fichier. Le choix d'un répertoire particulier s'effectue sur la base des meta-données qui ont été associées au fichier F.
L'étape de stockage dans une base de données 301 associée au serveur de stockage 300, étape 718 sur la figure 3, est réalisée par l'exécution du module 318 qui scrute en permanence le taux de remplissage de chacun des répertoires de la structure d'archivage. Lorsque le taux de remplissage d'un répertoire dépasse un taux seuil prédéterminé, l'intégralité du contenu de ce répertoire est sauvegardée dans la base de données 301 , dans un tableau ayant un format prédéterminé.
A l'étape 812, hors ligne, au travers de l'interface homme/machine 412 affichée sur l'écran du serveur de restitution 400, un membre de l'ALA construit des requêtes complexes d'interrogation des bases de données 301 , 303, 305. ce membre utilise un meta-langage.
A l'étape 814, ces requêtes complexes sont transmises au module de consultation 414 qui les traduit en autant de requêtes utilisant le langage SQL permettant une interrogation directe des bases de données 301 , 303 et/ou 305. Les données extraites des différentes bases de données sont rapatriées sur le serveur de restitution 400. Le module de consultation 414 agrège ces différentes données pour qu'elles soient présentées à l'opérateur à travers l'interface 412.
Le dispositif et le procédé de traitement qui viennent d'être décrits permettent de traiter un flux de données de grand volume par un unique ordinateur serveur de traitement comportant une carte mère présentant des caractéristiques standard. L'échelle du dispositif de traitement étant facilement adaptable aux besoins, en multipliant les ordinateurs composant chacune des couches du dispositif, des flux de données très élevés peuvent être traités par le dispositif selon l'invention. Ces flux de données élevés sont typiquement ceux que l'on trouve au point d'accès d'un sous-réseau national du réseau Internet.
Par le traitement en profondeur d'une requête HTTP, c'est-à-dire au niveau binaire de la trame correspondante, le procédé évite une multiplication des temps de calcul et un allongement considérable des temps de traitement requis pour chaque requête, tout en permettant l'extraction d'un grand nombre de données nécessaires à la surveillance du site Web et des activités de ses utilisateurs.

Claims

REVENDICATIONS
1 .- Procédé d'analyse de requête HTTP interceptées sur un réseau IP (30) pour la surveillance de l'activité des utilisateurs d'un site Web prédéterminé, comportant les étapes consistant à :
- acquérir (612) la trame de données complète d'une requête HTTP;
- sélectionner (614) la trame de données acquise si sa structure binaire vérifie une pluralité de conditions comportant au moins une condition correspondant à la couche IP (1040, 1050) de la trame, au moins une condition correspondant à la couche de transport (1080) de la trame et au moins une condition correspondant à la couche d'application (1 100, 1 1 10) de la trame;
- extraire (616) des données d'intérêt de la couche d'application de la trame sélectionnée ;
- enregistrer (618, 620, 712, 714, 716, 718) les données extraites, dans une base de données (301 , 303, 305).
2.- Procédé selon la revendication 1 , caractérisé en ce que l'étape de sélection
(612) permet la sélection d'une trame dont la couche de transport est une couche TCP et dont la couche d'application est une couche HTTP.
3. - Procédé selon la revendication 2, caractérisé en ce que, à l'étape de sélection (612), ladite au moins une condition sur la couche IP, respectivement ladite au moins une condition sur la couche TCP, consiste à comparer (1040 ; 1080) la longueur d'un paquet de bits inclus dans la trame acquise, paquet considéré comme étant un paquet IP, respectivement un paquet TCP, avec une longueur prédéfinie de l'en-tête d'un paquet IP, respectivement d'un paquet TCP.
4. - Procédé selon la revendication 2 ou la revendication 3, caractérisé en ce que, à l'étape de sélection (612), ladite au moins une condition sur la couche IP, respectivement ladite au moins une condition sur la couche HTTP, consiste à appliquer, sur l'en-tête d'un paquet de bits inclus dans la trame acquise, paquet considéré comme étant un paquet IP, respectivement un paquet HTTP, un masque pour extraire un groupe de bits et à comparer (1050 ; 1 100, 1 1 10) ce groupe de bits avec valeur binaire attendue pour un paramètre présent dans l'en-tête d'un paquet IP, respectivement l'en-tête d'un paquet HTTP.
5. - Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, entre l'étape consistant à extraire les données de la couche d'application de ladite trame et à enregistrer ces données dans une base de données, le procédé comporte une étape supplémentaire consistant à mettre en forme les données extraites selon un modèle prédéterminé, de préférence en y associant des meta-données.
6. - Dispositif pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comporte :
- un moyen d'acquisition (212) d'une trame de données complète d'une requête HTTP interceptée sur un réseau de communication IP auquel ledit dispositif est connecté ;
- un moyen de sélection (214) propre à vérifier une pluralité de conditions sur la structure binaire d'une trame de données acquise obtenue en sortie du moyen d'acquisition, et comportant au moins une routine de vérification d'une condition correspondant à la couche IP de la trame, au moins une routine de vérification d'une condition correspondant à la couche de transport de la trame et au moins une routine de vérification d'une condition correspondant à la couche d'application de la trame ;
- un moyen d'extraction (216) apte à extraire des données de la couche d'application d'une trame de données sélectionnée obtenue en sortie du moyen de sélection ;
- un moyen d'enregistrement (218 à 318) apte à stocker les données extraites obtenues en sortie du module d'extraction dans une base de données (301 , 303, 305).
7. - Dispositif selon la revendication 6, caractérisé en ce que le moyen de sélection (212) est adapté pour la sélection d'une trame de données acquises dont la couche de transport est une couche TCP et dont la couche d'application est une couche HTTP.
8. - Dispositif selon la revendication 6 ou la revendication 7, caractérisé en ce qu'il comporte un étage de traitement (152) comportant une pluralité d'ordinateurs serveur de traitement (200, 202), chaque ordinateur serveur de traitement étant connecté audit réseau de communication IP et comportant une instanciation desdits moyens d'acquisition, de sélection et d'extraction.
9. - Dispositif selon la revendication 8, caractérisé en ce qu'il comporte, en outre, un étage de stockage (154) comportant une pluralité d'ordinateurs serveur de stockage (300, 3020, 304), chaque ordinateur serveur de stockage étant connecté à ladite pluralité d'ordinateurs serveur de traitement, étant associé à au moins une base de données (301 , 303, 305), et comportant une instanciation desdits moyens de stockage apte à stocker les données extraites communiquées par un ordinateur serveur de traitement dans la base de données associée à l'ordinateur serveur de stockage considéré.
10.- Dispositif selon la revendication 9, caractérisé en ce qu'il comporte, en outre, un étage de restitution (156) comportant au moins un ordinateur de restitution (400) comportant des moyens d'interrogation des différentes bases de données de l'étage de stockage.
EP11727248A 2010-05-20 2011-05-20 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 Withdrawn EP2572488A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1002132A FR2960371B1 (fr) 2010-05-20 2010-05-20 Procede et dispositif d'analyse de donnees interceptees sur un reseau ip pour la surveillance de l'activite des utilisateurs d'un site web
PCT/FR2011/051153 WO2011144880A1 (fr) 2010-05-20 2011-05-20 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

Publications (1)

Publication Number Publication Date
EP2572488A1 true EP2572488A1 (fr) 2013-03-27

Family

ID=43332999

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11727248A Withdrawn EP2572488A1 (fr) 2010-05-20 2011-05-20 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

Country Status (4)

Country Link
US (1) US20130205015A1 (fr)
EP (1) EP2572488A1 (fr)
FR (1) FR2960371B1 (fr)
WO (1) WO2011144880A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3028370B1 (fr) * 2014-11-12 2019-09-27 Bull Sas Methodes et systemes de supervision applicative
CN105577496B (zh) * 2016-03-03 2018-06-15 烽火通信科技股份有限公司 一种家庭网关利用云平台识别接入设备类型的系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020035681A1 (en) * 2000-07-31 2002-03-21 Guillermo Maturana Strategy for handling long SSL messages
JP2004145583A (ja) * 2002-10-24 2004-05-20 Nippon Telegr & Teleph Corp <Ntt> フィルタリングシステム
US7594011B2 (en) * 2004-02-10 2009-09-22 Narus, Inc. Network traffic monitoring for search popularity analysis
US7760719B2 (en) * 2004-06-30 2010-07-20 Conexant Systems, Inc. Combined pipelined classification and address search method and apparatus for switching environments
US7706291B2 (en) * 2007-08-01 2010-04-27 Zeugma Systems Inc. Monitoring quality of experience on a per subscriber, per session basis

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2011144880A1 *

Also Published As

Publication number Publication date
FR2960371B1 (fr) 2012-06-22
US20130205015A1 (en) 2013-08-08
FR2960371A1 (fr) 2011-11-25
WO2011144880A1 (fr) 2011-11-24

Similar Documents

Publication Publication Date Title
US11936764B1 (en) Generating event streams based on application-layer events captured by remote capture agents
US10812514B2 (en) Configuring the generation of additional time-series event data by remote capture agents
EP1899887B1 (fr) Procede et systeme de reperage et de filtrage d&#39;informations multimedia sur un reseau
EP2023533B1 (fr) Procédé et installation de classification de trafics dans les réseaux IP
FR2855691A1 (fr) Securisation de la distribution de documents numeriques dans un reseau pair a pair
CN106878074B (zh) 流量过滤方法及装置
US20160127180A1 (en) Streamlining configuration of protocol-based network data capture by remote capture agents
FR2849559A1 (fr) Outil et methode d&#39;analyse de chemin dans un reseau de transmission de donnees comprenant plusieurs systemes autonomes internet
US11477161B1 (en) Systems and methods for detecting DNS communications through time-to-live analyses
WO2011144880A1 (fr) Procédé et dispositif d&#39;analyse de données interceptées sur un réseau ip pour la surveillance de l&#39;activité des utilisateurs d&#39;un site web
CN111211995B (zh) 一种字符串匹配库获取网络流量业务分析方法及装置
Qin et al. Behavior spectrum: An effective method for user's web access behavior monitoring and measurement
EP3818676A1 (fr) Identification de protocole d&#39;un flux de données
Kim et al. Today's usenet usage: NNTP traffic characterization
Qiao et al. FLAS: Traffic analysis of emerging applications on Mobile Internet using cloud computing tools
Gu et al. Meta-TFEN: A Multi-Modal Deep Learning Approach for Encrypted Malicious Traffic Detection
EP2880558B1 (fr) Procédé de traitement de données pour analyse situationnelle
Pujol Gil Web content delivery, monetization, and search
FR2994297A1 (fr) Procede de traitement de donnees de connexion d&#39;une plateforme d&#39;un site internet
EP2365680A1 (fr) Dispositif de gestion dynamique des pages de sites internet dont les fréquentations et audience doivent être analysées
WO2023036847A1 (fr) Procede et système de surveillance et gestion du trafic de données
Manesh et al. Forensic investigation framework for P2P protocol
CN116996732A (zh) 一种伪造识别场景下的存储、调度检测方法和系统
FR3081075A1 (fr) Utilisation d&#39;une technologie a chaine de blocs et systeme d&#39;authentification pour authentifier un fichier informatique
EP2830281A1 (fr) Procédé d&#39;association de sources de données hétérogènes pour la sécurité des réseaux de communication et système associé

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20121206

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20130911

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20140429