FR3064772A1 - Procede d’aide a la detection d’attaques par denis de services - Google Patents
Procede d’aide a la detection d’attaques par denis de services Download PDFInfo
- Publication number
- FR3064772A1 FR3064772A1 FR1752576A FR1752576A FR3064772A1 FR 3064772 A1 FR3064772 A1 FR 3064772A1 FR 1752576 A FR1752576 A FR 1752576A FR 1752576 A FR1752576 A FR 1752576A FR 3064772 A1 FR3064772 A1 FR 3064772A1
- Authority
- FR
- France
- Prior art keywords
- connection
- identifier
- execution
- representative
- function
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 428
- 238000001514 detection method Methods 0.000 title abstract description 22
- 230000008569 process Effects 0.000 claims abstract description 353
- 238000012545 processing Methods 0.000 claims abstract description 56
- 238000004364 calculation method Methods 0.000 claims abstract description 25
- 239000002151 riboflavin Substances 0.000 claims abstract description 6
- 239000004149 tartrazine Substances 0.000 claims abstract description 6
- 238000004891 communication Methods 0.000 claims description 67
- 239000004230 Fast Yellow AB Substances 0.000 claims description 3
- 239000004229 Alkannin Substances 0.000 claims description 2
- 239000004172 quinoline yellow Substances 0.000 claims 1
- 230000006870 function Effects 0.000 description 119
- 230000015654 memory Effects 0.000 description 15
- 230000000694 effects Effects 0.000 description 7
- 230000000875 corresponding effect Effects 0.000 description 6
- 230000000977 initiatory effect Effects 0.000 description 5
- 239000011800 void material Substances 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 108010061309 E021 Proteins 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000004445 quantitative analysis Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000000523 sample Substances 0.000 description 1
- 238000009738 saturating Methods 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
-
- 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
-
- 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/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
-
- 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/16—Implementing security features at a particular protocol layer
- H04L63/168—Implementing security features at a particular protocol layer above the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/12—Detection or prevention of fraud
- H04W12/126—Anti-theft arrangements, e.g. protection against subscriber identity module [SIM] cloning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/141—Denial of service attacks against endpoints in a network
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
Abstract
L'invention concerne un procédé d'aide à la détection d'attaques par dénis de service applicatifs dans un système proposant au moins une application, ladite application utilisant au moins un service, le procédé comprenant : - interception (E101) de l'exécution d'une fonction du noyau du système d'exploitation représentative de la réception d'une demande de connexion à l'application en provenance d'un équipement client, association d'un identifiant de ladite connexion à l'identiiant d'au moins un processus, ledit processus étant en charge du traitement de ladite connexion sur un premier service, et obtention d'un premier intervalle de temps représentatif d'un temps CPU consommé par ledit processus depuis sa création, - interception (E102) de l'exécution d'une deuxième fonction du noyau du système d'exploitation représentative d'une fermeture de ladite connexion, et obtention d'un deuxième intervalle de temps représentatif d'un temps CPU consommé par ledit processus depuis sa création, - calcul (E20) d'un temps CPU total consommé pour le traitement de ladite connexion à partir d'au moins le deuxième et le premier intervalle de temps CPU consommé par ledit processus.
Description
® RÉPUBLIQUE FRANÇAISE
INSTITUT NATIONAL DE LA PROPRIÉTÉ INDUSTRIELLE © N° de publication : 3 064 772 (à n’utiliser que pour les commandes de reproduction)
©) N° d’enregistrement national : 17 52576
COURBEVOIE © Int Cl8 : G 06 F12/14 (2017.01), G 06 F21/00, H 04 L 29/06
DEMANDE DE BREVET D'INVENTION A1
| ©) Date de dépôt : 28.03.17. | ©) Demandeur(s) : ORANGE Société anonyme — FR. |
| ©) Priorité : | |
| @ Inventeur(s) : CHAIGNON PAUL, CHOUAKIYACINE | |
| et LAZRI KAHINA. | |
| (43) Date de mise à la disposition du public de la | |
| demande : 05.10.18 Bulletin 18/40. | |
| ©) Liste des documents cités dans le rapport de | |
| recherche préliminaire : Se reporter à la fin du | |
| présent fascicule | |
| (© Références à d’autres documents nationaux | ©) Titulaire(s) : ORANGE Société anonyme. |
| apparentés : | |
| ©) Demande(s) d’extension : | ©) Mandataire(s) : ORANGE. |
PROCEDE D'AIDE A LA DETECTION D'ATTAQUES PAR DENIS DE SERVICES.
FR 3 064 772 - A1 (5/) L'invention concerne un procédé d'aide à la détection d'attaques par dénis de service applicatifs dans un système proposant au moins une application, ladite application utilisant au moins un service, le procédé comprenant:
- interception (E101) de l'exécution d'une fonction du noyau du système d'exploitation représentative de la réception d'une demande de connexion à l'application en provenance d'un équipement client, association d'un identifiant de ladite connexion à l'identiiant d'au moins un processus, ledit processus étant en charge du traitement de ladite connexion sur un premier service, et obtention d'un premier intervalle de temps représentatif d'un temps CPU consommé par ledit processus depuis sa création,
- interception (E102) de l'exécution d'une deuxième fonction du noyau du système d'exploitation représentative d'une fermeture de ladite connexion, et obtention d'un deuxième intervalle de temps représentatif d'un temps CPU consommé par ledit processus depuis sa création,
- calcul (E20) d'un temps CPU total consommé pour le traitement de ladite connexion à partir d'au moins le deuxième et le premier intervalle de temps CPU consommé par ledit processus.
PI
Procédé d’aide à la détection d’attaques par dénis de services
La présente invention se rapporte au domaine général des télécommunications. Elle concerne plus particulièrement l’aide à la détection d’attaques par dénis de service applicatifs qui visent à rendre un service indisponible à des utilisateurs légitimes par saturation des ressources d’un serveur ou d’un équipement réseau.
On connaît plusieurs types d’attaques par dénis de services (on parle habituellement de DoS ou de DDoS, pour « Distributed Déniai of Service ») : les attaques par dénis de services réseaux et les attaques par dénis de services applicatifs.
Les attaques par dénis de services réseaux consistent en l’envoi d’un nombre important de paquets réseau à un service cible, par exemple un équipement réseau ou un serveur Web, de manière à mobiliser les ressources dans le traitement de ces paquets. Cela a pour conséquence de saturer les ressources du service cible et de rendre ces ressources non disponibles pour le traitement de requêtes provenant de clients légitimes. Les attaques par dénis de services réseaux se caractérisent principalement par l’envoi d’une quantité significative de paquets réseau. La détection de telles attaques repose donc principalement sur une analyse quantitative des requêtes reçues par un équipement réseau.
La deuxième catégorie d’attaques par dénis de services correspond à des attaques applicatives. Celles-ci visent des vulnérabilités d’implémentation d’une application Web ou directement des pages qui consomment beaucoup de ressources CPU (de l’anglais « Central Processing Unit ») et de mémoire pour se créer ou s’exécuter. Par exemple, une telle page peut permettre de faire des recherches dans une base de données de taille importante. De telles pages utilisent souvent des langages interprétés qui provoquent de forts besoins en consommation de ressources de type processeur et mémoire.
Une telle attaque est plus facile à réaliser qu’une attaque par dénis de service réseaux et est également plus subtile à détecter. En effet, l’attaque applicative ne requiert pas d’importantes ressources réseaux pour parvenir à une saturation du service ciblé : il suffit d’envoyer des requêtes légitimes à une page web consommatrice de ressource CPU à une fréquence que l’on peut qualifier de normale. Une « fréquence normale » correspond à quelques requêtes par seconde. On comprend que les attaques par dénis de service applicatifs sont plus difficiles à identifier que des attaques par dénis de services réseaux.
Un des buts de l’invention est de remédier à des insuffisances/inconvénients de l’état de la technique et/ou d’y apporter des améliorations.
A cette fin, l’invention propose un procédé d’aide à la détection d’attaques par dénis de service applicatifs dans un système proposant au moins une application, ladite application utilisant au moins un service, le procédé comprenant :
- interception de l’exécution d’une fonction du noyau du système d’exploitation représentative de la réception d’une demande de connexion à l’application en provenance d’un équipement client, association d’un identifiant de ladite connexion à l’identifiant d’au moins un processus, ledit processus étant en charge du traitement de ladite connexion sur un premier service, et obtention d’un premier intervalle de temps représentatif d’un temps CPU consommé par ledit processus depuis sa création,
- interception de l’exécution d’une deuxième fonction du noyau du système d’exploitation représentative d’une fermeture de ladite connexion, et obtention d’un deuxième intervalle de temps représentatif d’un temps CPU consommé par ledit processus depuis sa création,
- calcul d’un temps CPU total consommé pour le traitement de ladite connexion à partir d’au moins le deuxième et le premier intervalle de temps CPU consommé par ledit processus.
Ue procédé décrit ici permet d’associer à chaque équipement client qui demande l’exécution d’une application sur un serveur un profil de consommation précis, représentatif du temps CPU réellement consommé au niveau du serveur pour le traitement de l’application pour ce client. Le temps CPU correspond au temps que le processeur a consacré au traitement de la requête initiée par l’équipement client et est mesuré comme une somme de mesures de temps d’exécution d’au moins un processus du serveur. Il est important de noter que dans un environnement multi tâches tel qu’un serveur susceptible d’héberger une pluralité d’applications, la détermination du temps CPU consommé par des processus dans le cadre d’une activité donnée, ici le traitement d’une connexion issue d’un équipement client, n’est pas évidente. Il est en effet connu qu’un processus donné s’occupe généralement de plusieurs connexions. En outre, une connexion est généralement traitée par plusieurs processus.
Ainsi, le procédé permet d’associer à chaque client d’une application web un profil de consommation de temps CPU précis qu’il a engendré au niveau du serveur hébergeant l’application.
Le procédé repose sur l’interception d’un certain nombre de fonctions du noyau du système d’exploitation. En se plaçant ainsi au niveau du noyau du système d’exploitation, le procédé est agnostique et ne dépend pas de programmes utilisateur particuliers. Par exemple il ne nécessite pas qu’une application supervisée soit programmée de manière à intégrer sa propre supervision. Par ailleurs, on s’affranchit ainsi de spécificités relatives à des interfaces propres à certaines applications.
Dans un exemple de réalisation, le procédé comprend, lorsque ladite application utilise au moins deux services et qu’un premier processus d’un premier des au moins deux services établit une communication avec un deuxième processus d’un deuxième des au moins deux services, un identifiant dudit premier processus étant associé à l’identifiant de ladite connexion :
- interception de l’exécution d’une fonction du noyau du système d’exploitation représentative d’une demande d’établissement d’une communication entre le premier processus et le deuxième processus,
- interception de l’exécution d’une fonction du noyau du système d’exploitation représentative de l’établissement de la communication entre le premier et le deuxième processus, association d’un identifiant du deuxième processus à l’identifiant de ladite connexion, et obtention d’un deuxième premier intervalle de temps représentatif du temps CPU consommé par le deuxième processus depuis sa création,
- interception de l’exécution d’une fonction du noyau du système d’exploitation représentative de la fermeture de la communication entre le premier processus et le deuxième processus, et obtention d’un deuxième intervalle de temps représentatif du temps CPU consommé par le deuxième processus depuis sa création,
- calcul d’un deuxième temps CPU de traitement associé à ladite communication à partir du deuxième et du premier deuxième intervalle de temps,
- prise en compte du deuxième temps CPU pour le calcul du temps CPU total consommé pour le traitement de ladite connexion.
Ue procédé s’applique à des applications qui font appel à une pluralité de services. Typiquement il s’applique à une application Web qui repose sur un service HTTP, un service PHP et un service SQU et pour laquelle un processus d’un premier service envoie des requêtes à un processus d’un deuxième service. Le procédé permet de chaîner les différents processus à un identifiant de la connexion établie par l’équipement client, en l’espèce une adresse IP de l’équipement, et de récolter les informations relatives aux temps d’activité qu’un processus consacre au traitement de la connexion. Ce chaînage est complété notamment lors de l’établissement de communications inter processus au cours desquelles un premier processus, dit processus client, établit une communication avec un deuxième processus, dit processus serveur, par le biais d’une communication inter processus tel qu’un socket.
Dans un exemple de réalisation, l’identifiant du deuxième processus est associé à l’identifiant de ladite connexion lorsqu’un premier identifiant de la communication entre le premier et le deuxième processus, ledit premier identifiant étant obtenu dans une structure de données associée au premier processus est identique à un deuxième identifiant de la communication entre le premier et le deuxième processus, ledit deuxième identifiant étant obtenu dans une structure de données associée au deuxième processus.
Ainsi, une liste des processus qui contribuent au traitement de la connexion est construite au fur et à mesure que des processus actifs, i.e., contributeurs, sont identifiés.
Avantageusement, le procédé comprend, dans une étape de configuration initiale une fourniture d’une liste de processus à superviser pour ladite application, et
- interception de l’exécution d’une fonction du noyau du système d’exploitation représentative de la création d’un processus fils par un processus parent,
- lorsque le processus parent appartient à la liste des processus à superviser, obtention de l’identifiant dudit processus fils et ajout dudit processus fils à la liste des processus à superviser.
Le procédé s’applique à une liste initiale de processus fournie par l’administrateur en charge de superviser l’exécution de l’application. Cette liste de processus comprend les processus à superviser dans le cadre de l’exécution de l’application. Fournir une telle liste initiale permet de limiter les interceptions de fonctions du noyau du système d’exploitation à des processus qui sont effectivement associés à l’application Web. Cette liste est dynamique en ce sens que des processus qui sont créés dans le cadre de l’exécution de l’application sont intégrés à la liste de processus à superviser dès leur création. Le procédé s’applique à tout instant à l’ensemble des processus qui contribuent à l’exécution de l’application. Ainsi, le calcul du temps CPU total est précis et tient compte de l’ensemble des processus exécutés dans le cadre de l’application.
Dans un exemple de réalisation, le procédé comprend :
- interception de l’exécution d’une fonction du noyau du système d’exploitation représentative de l’arrêt d’un processus existant,
- lorsque le processus existant appartient à la liste des processus à superviser, obtention de l’identifiant dudit processus existant et suppression dudit processus existant dans la liste des processus à superviser.
De même, lorsque des processus qui font partie de la liste des processus supervisés sont arrêtés, ils sont supprimés de la liste. Ainsi, le procédé optimise le traitement qu’il met en œuvre en se concentrant sur les processus susceptibles de consommer du temps CPU.
U’invention concerne également un serveur apte à héberger au moins une application, ladite application utilisant au moins un service, ledit serveur comprenant :
- des premiers moyens d’interception et d’obtention, agencés pour intercepter l’exécution d’une fonction du noyau du système d’exploitation représentative de la réception d’une demande de connexion à l’application en provenance d’un équipement client, associer un identifiant de ladite connexion à l’identifiant d’au moins un processus, ledit processus étant en charge du traitement de ladite connexion, et pour obtenir un premier intervalle de temps représentatif d’un temps CPU consommé par ledit processus depuis sa création,
- des deuxièmes moyens d’interception et d’obtention, agencés pour intercepter l’exécution d’une deuxième fonction du noyau du système d’exploitation représentative d’une fermeture de ladite connexion, et pour obtenir un deuxième intervalle de temps représentatif d’un temps CPU consommé par ledit processus depuis sa création,
- des moyens de calcul, agencés pour calculer un temps CPU total consommé pour le traitement de ladite connexion à partir d’au moins le deuxième et le premier intervalle de temps CPU consommé par ledit processus.
L’invention porte également sur un programme pour un serveur apte à héberger au moins une application utilisant au moins un service, ledit programme comprenant des instructions de code de programme destinées à commander l’exécution des étapes du d’aide à la détection d’attaques par dénis de service applicatifs, tel que décrit précédemment, lorsque le programme est exécuté sur ledit serveur.
L’invention concerne aussi un support de données dans lequel est enregistré le programme décrit ci-dessus.
D'autres caractéristiques et avantages de la présente invention seront mieux compris de la description et des dessins annexés parmi lesquels :
- la figure 1 présente les étapes d’un procédé d’aide à la détection d’attaques par dénis de services applicatifs, selon un exemple de réalisation ;
- la figure 2 est une représentation schématique d’un serveur, apte à mettre en œuvre le procédé d’aide à la détection d’attaques par dénis de services applicatifs, selon un exemple de réalisation.
Les étapes d’un procédé d’aide à la détection d’attaques par dénis de service applicatifs, selon un exemple de réalisation, vont maintenant être décrites en relation avec la figure 1.
L’invention est décrite ici dans le cas de l’accès à partir de navigateurs Web d’équipements clients à une ou des applications Web hébergées par un équipement informatique, tel un serveur. L’accès à ces applications Web repose sur le protocole de communication HTTP (pour « HyperText Transfer Protocol ») et le protocole de transport TCP (pour « Transmission Control Protocol »). Beaucoup d’attaques visent de telles applications, accessibles à partir de navigateurs Web. Ces applications utilisent la plupart du temps le protocole HTTP et le protocole TCP qui est le protocole de transport utilisé pour la majorité du trafic Internet. Dans l’exemple de réalisation décrit ici, le système d’exploitation du serveur qui héberge les applications Web est Linux. L’invention est applicable à l’ensemble des systèmes d’exploitation de type Linux et Unix. De même l’invention n’est pas limitée à des applications Web et s’applique à toute application qui nécessite l’établissement d’une connexion TCP avec le serveur.
Une application Web repose sur un ou plusieurs services pour s’exécuter : par exemple un serveur HTTP, tel Apache, adapté pour recevoir des requêtes émises par des navigateurs d’équipements clients, chercher une page et la renvoyer, un service de génération de contenus tel que PHP (pour « PHP: Hypertext Preprocessor »), adapté pour décrire dans une page Web un affichage dynamique d’informations, et un système de gestion de base de données tel que MySQL, adapté pour stocker des données et permettre leur manipulation à travers un langage de requête associé. L’utilisation de ces trois services n’est nécessaire que lorsque Ton souhaite afficher des informations provenant d’une base de données. On admet qu’une telle configuration se présente assez fréquemment car elle répond globalement à la majorité des besoins.
Les différents services impliqués lors de l’exécution de l’application Web comprennent un service dit frontal (ou service « frontend »), agencé pour recevoir les requêtes en provenance des navigateurs des équipements clients et un ou plusieurs services en arrière-plan, ou backoffice (ou services « backend »), lorsqu’ils sont appelés par un autre service. Typiquement un service HTTP, qualifié de service frontend, qui reçoit des requêtes de navigateurs d’équipements clients, fait appel à des services PHP et MySQL, qui sont qualifiés de services backend.
Les différents services impliqués lors de l’exécution d’une application Web s’exécutent sous forme de processus. Un processus est défini comme une instance de programme en cours d’exécution. Ues processus communiquent afin de se transmettre des requêtes à traiter et des réponses à ces requêtes au moyen de mécanismes de communication interprocessus (ou « IPC » en anglais pour « Inter Process Communications »). Ces mécanismes de communication font en général appel au noyau du système d’exploitation du serveur qui héberge l’application Web pour l’établissement de la connexion entre deux processus.
Le procédé d’aide à la détection d’attaques par dénis de services applicatifs décrit ici consiste à associer à une connexion TCP au niveau du serveur, initiée par un client lors de l’accès à l’application Web via le navigateur du client, l’ensemble des processus qui sont impliqués par cette exécution, et à comptabiliser le temps CPU que l’ensemble de ces processus a consommé pour traiter cette connexion. Ce temps CPU correspond à un cumul de temps effectif passé par le processeur du serveur pour le traitement de la connexion TCP. Il est important de souligner que la détermination du temps consacré par des processus à une connexion TCP donnée n’est pas évidente puisqu’il est connu qu’un processus donné s’occupe généralement de plusieurs connexions. En outre, une connexion est généralement traitée par plusieurs processus.
Pour identifier les processus qui contribuent au traitement d’une connexion TCP, ou connexion cliente, et comptabiliser le temps CPU associé, des sondes sont utilisées afin d’intercepter l’exécution et/ou le retour ou fin d’exécution de certaines fonctions du noyau du système d’exploitation et de déclencher des traitements particuliers sur ces interceptions. Plus précisément, un programme de supervision, apte à mettre en œuvre les étapes du procédé d’aide à la détection d’attaques par dénis de services applicatifs positionne des points d’interception (ou « hook » en anglais) sur l’appel et/ou la sortie de certaines fonctions du noyau du système d’exploitation et déclenche un traitement spécifique lors d’une telle interception. Ainsi, à chaque fois que le noyau du système d’exploitation appelle ou sort d’une fonction supervisée, le programme de supervision prend la main pour mettre en œuvre une fonction d’interception prévue par le programme de supervision. La fonction d’interception est appelée avec des informations de contexte d’exécution de la fonction du noyau dont l’exécution a été interceptée et qui comprennent des informations sur le processus courant, ou processus en cours d’exécution, lorsque la fonction du noyau a été appelée, les valeurs de registres CPU, etc. Les informations sur le processus courant sont comprises dans une structure de données, appelée « struct task_struct », allouée dynamiquement à chaque processus et qui peut être obtenue à partir des informations de contexte d’exécution. A noter que les arguments passés à la fonction du noyau du système d’exploitation lorsqu’elle est appelée peuvent être obtenus à partir des valeurs des registres CPU.
Une fois obtenu le temps CPU accordé par chacun des processus au traitement d’une connexion cliente, il est calculé un temps CPU total effectif que le système d’exploitation a consacré au traitement de cette connexion. Ce calcul du temps CPU total est mis en œuvre lors de la fermeture de la connexion TCP initiée par le client.
A noter que le programme de supervision qui met en œuvre le procédé d’aide à la détection d’attaques par dénis de services applicatifs s’exécute dans l’espace utilisateur, au même titre que l’application Web. Le programme de supervision est indépendant de l’application Web ; il peut s’appliquer à toute application Web qui s’exécute sur le serveur. En ce sens, le procédé d’aide à la détection d’attaques par dénis de services applicatifs est qualifié d’agnostique en ce qui concerne les applications Web susceptibles de s’exécuter sur le serveur.
Dans une phase PO de configuration initiale, dans une sous-étape E01 de fourniture d’une liste initiale de processus, il est fourni par un administrateur en charge de la supervision des applications Web proposées sur le serveur une liste initiale de processus qui comprend les identifiants de tous les processus des différents services associés à l’application Web pour laquelle la supervision doit être mise en œuvre. Un identifiant de processus, ou PID (pour « Process IDentifier), est un code unique attribué par le système d’exploitation à tout processus lors de son démarrage. Il permet d’identifier les processus dans toute commande qui s’applique à un processus. L’étape E01 de fourniture de la liste initiale de processus est mise en œuvre à chaque fois que le programme de supervision est exécuté pour une application Web. Fournir une telle liste initiale permet de limiter les interceptions de fonctions du noyau du système d’exploitation à des processus qui sont effectivement associés à l’application Web. Ainsi, lors de toute interception de l’exécution d’une fonction du noyau du système d’exploitation, il est d’abord vérifié que le processus courant associé à l’exécution de la fonction du noyau et dont l’identifiant est disponible dans des informations de contexte d’exécution de la fonction du noyau, fait partie des processus associés à l’application Web. Si le processus courant ne fait pas partie de la liste des processus relatifs à l’application Web, alors l’interception de la fonction du noyau, plus précisément le traitement associé à cette interception, est interrompue de manière à poursuivre l’exécution normale du noyau. Ce cas de figure correspond à l’exécution d’un processus associé à une autre application qui s’exécute sur le même serveur que l’application Web. Interrompre la supervision dans ce cas permet de limiter l’impact du procédé sur cette autre application.
Dans un exemple de réalisation, la liste des processus est segmentée par service. Un premier groupe de processus correspond par exemple aux processus du service frontend HTTP, un deuxième groupe de processus regroupe les processus d’un service backend tel que PHP, etc. Une telle segmentation permet de détailler la répartition par service de la consommation CPU relative à une connexion cliente donnée, et d’analyser plus finement l’origine de consommations anormales de temps CPU.
A noter cependant que la configuration initiale n’est pas forcément représentative de l’ensemble des processus impliqués lors de l’exécution de l’application Web. En effet, la liste initiale de processus peut évoluer au fil du temps : les services créent et arrêtent des processus pour s’adapter à une charge courante, par exemple en fonction du nombre de requêtes reçues. Ainsi il est nécessaire de tenir compte de créations et d’arrêts de processus lors de l’exécution de l’application Web.
A cette fin dans une étape suivante E02 de première mise à jour dynamique de la liste des processus, l’exécution d’une première fonction du noyau, appelée à chaque création d’un nouveau processus est interceptée. Intercepter l’exécution de cette première fonction permet d’obtenir, via les informations de contexte d’exécution de la fonction du noyau au moment de l’interception, l’identifiant du nouveau processus créé et l’identifiant du processus à l’origine de la création de ce nouveau processus. Ce processus est habituellement appelé « processus père », et le nouveau processus « processus fils ». Dans le cas où le processus père fait partie des processus supervisés qui figurent dans la liste initiale de processus obtenue au cours de l’étape E01 de fourniture de la liste initiale, alors il est nécessaire de superviser également le processus fils qui fait partie de l’application Web. Dans une sous-étape E021 de mise à jour de la liste, mise en œuvre lorsque le processus père fait partie de la liste des processus supervisés, l’identifiant du processus fils, obtenu à partir des informations de contexte d’exécution associées à la fonction du noyau en cours d’exécution, est ajouté à la liste de processus à superviser.
Dans un exemple de réalisation, correspondant au cas où l’application Web s’exécute sur un serveur dont le système d’exploitation est Linux, le prototype de la fonction du noyau du système d’exploitation dont l’exécution est interceptée est : void wake_up_new_task (struct task_struct *p). On rappelle que le prototype d’une fonction est une description qui comprend le nom de la fonction, le type des arguments, ou paramètres d’entrée de la fonction, et le type de la valeur renvoyée. La fonction du noyau wake_up_new_task est appelée à chaque fois qu’un nouveau processus est créé. Un nouveau processus est créé au moyen d’un appel système, par exemple « fork » ou « clone ». L’objet donné en argument de la fonction, en l’espèce la structure de données struct task_struct *p, contient les informations sur le nouveau processus. En interceptant l’exécution de cette fonction, l’identifiant du nouveau processus est récupéré via l’objet donné en argument. L’identifiant du processus père est obtenu via les informations de contexte d’exécution de la fonction du noyau.
Lors d’une étape E03 de deuxième mise àjour dynamique, mise en œuvre lors de l’arrêt d’un des processus supervisés, il est intercepté l’exécution d’une fonction du noyau du système d’exploitation appelée à chaque fois qu’un processus est arrêté. Cette interception permet de supprimer de la liste des processus à superviser celui qui a été arrêté. L’identifiant du processus arrêté figure dans les informations de contexte d’exécution de la fonction du noyau dont l’exécution est interceptée. Ainsi, l’identifiant du processus arrêté, s’il fait partie de la liste des processus associés à l’exécution de l’application Web est alors supprimé de la liste des processus à superviser dans une sous-étape E031 de mise àjour de la liste. La liste de processus est ainsi mise àjour dynamiquement. Cela permet d’optimiser les traitements en se limitant aux processus actifs pour l’application web en cours d’exécution.
Dans l’exemple de réalisation décrit ici qui correspond au système d’exploitation Linux, le prototype de la fonction dont l’exécution est interceptée lors de l’arrêt d’un processus est : void do_exit(long code).
L’étape E02 de première mise à jour de la liste de processus, respectivement E03 de deuxième mise à jour, est exécutée dès qu’un processus associé à l’application Web est créé, respectivement arrêté. Ces étapes s’exécutent comme tâche de fond pendant toute l’exécution de l’application de supervision.
Dans une phase suivante PI de traitement, mise en œuvre en tâche de fond pendant toute l’exécution du programme de supervision et de préférence après avoir fourni la liste initiale de processus au cours de l’étape E01 de la phase PO, l’exécution et/ou la fin d’exécution d’une pluralité de fonctions du noyau du système d’exploitation est interceptée dans une étape E10 d’interception. Des informations relatives à l’exécution de l’application Web sont alors récupérées à partir des informations de contexte d’exécution de la fonction du noyau interceptée et/ou de la structure de données struct task_struct associée au processus pour lequel la fonction du noyau est exécutée. On rappelle que la structure de donnée struct task_struct d’un processus peut être obtenue à partir des informations de contexte d’exécution de la fonction du noyau dont l’exécution est interceptée. Pour des raisons de lisibilité, l’étape E10 d’interception est décrite sous forme d’une pluralité de sous-étapes, chacune des sous-étapes étant dédiée à une fonction du noyau du système d’exploitation dont l’exécution est interceptée. A noter que pour la pluralité de sous-étapes de l’étape E10 décrites ci-dessous, il est vérifié que le processus courant pour lequel l’exécution de la fonction du noyau est interceptée fait partie de la liste des processus supervisés telle que fournie et enrichie au cours des étapes E01 de fourniture de la liste initiale de processus, E02 et E03 de première et deuxième mise à jour, décrites précédemment.
Ainsi :
- dans une sous-étape E101 de l’étape d’interception E10, l’exécution d’une fonction de demande de connexion, mise en œuvre à chaque fois qu’un client demande l’ouverture d’une connexion TCP à partir d’un équipement client, est interceptée. Dans l’exemple décrit ici, cette fonction est appelée lorsque le serveur HTTP, en écoute sur un port TCP destiné à recevoir les demandes de connexion reçoit une demande de connexion.
Dans le cas de Linux, le prototype de la fonction du noyau appelée est : struct sock *inet csk accept(struct sock *sk, int flags, int *err). Plus précisément, le serveur HTTP qui reçoit une demande de connexion sur le port TCP en provenance d’un équipement client utilise l’appel système accept qui résulte en l’exécution de la fonction du noyau inet_csk_accept. A noter que cette fonction est bloquante dans le sens où elle ne retourne qu’une fois qu’une connexion a été établie avec le client. L’interception du retour de cette fonction permet d’établir une relation entre la connexion distante d’un client, identifiée par une adresse IP associée à l’équipement du client à l’origine de la demande de connexion courante, et le processus du serveur HTTP qui gère cette connexion courante, en l’espèce celui qui a appelé la fonction accept. Des informations sur la connexion TCP établie sont disponibles dans l’objet retourné par la fonction du noyau, en l’espèce l’objet struct sock. En particulier, l’objet retourné contient l’adresse IP du client, ce qui permet de l’identifier de façon unique. Il est mémorisé dans un tableau associatif l’adresse IP du client en association avec au moins l’identifiant du processus qui gère la connexion courante pour le serveur HTTP. L’identifiant du processus est récupéré à partir des informations de contexte d’exécution de la fonction dont l’exécution a été interceptée. Par ailleurs, dans un exemple de réalisation, une première instance de la structure de données struct task_struct propre au processus à l’origine de l’interception de l’exécution de la fonction du noyau est mémorisée en association avec l’identifiant du processus. La première instance de la structure de données est obtenue à partir des informations de contexte d’exécution de la fonction du noyau. La première instance de la structure de données struct task_struct comprend un intervalle de temps, noté Δίγ et appelé « premier intervalle de temps » correspondant au temps d’exécution CPU consommé par le processus depuis sa création. Cet intervalle est donc représentatif de l’activité passée du processus, mesurée en consommation CPU, avant qu’il ne soit en charge du traitement de la connexion TCP. Ce premier intervalle de temps est destiné à être utilisé dans le calcul du temps CPU dédié à la connexion TCP ;
- dans une sous-étape E102 de l’étape E10 d’interception, l’exécution d’une fonction représentative d’une fermeture de connexion, mise en œuvre à chaque fois qu’une connexion TCP est fermée est interceptée. L’interception de l’exécution de cette fonction déclenche dans une étape E20 de calcul de temps CPU, le calcul de la consommation CPU totale dédié au traitement de la connexion TCP. L’étape E20 de calcul est décrite précisément par la suite.
Dans le cas de Linux, la fonction dont l’exécution est interceptée est représentative d’un changement d’état d’une connexion. Un des paramètres de cette fonction fournit le nouvel état que prend la connexion. Ainsi, l’interception de cette fonction du noyau permet de détecter qu’une connexion se termine lorsque l’état retourné par cette fonction est « fermé » (ou « closed » en anglais), le prototype de la fonction du noyau appelée lorsque la connexion TCP change d’état est: void tcp set state (struct sock *sk, int state). La variable «state» comprend l’état de la connexion. Le paramètre struct sock *sk permet d’identifier la connexion TCP qui vient d’être fermée. L’identifiant du processus en charge de la connexion TCP, obtenu dans les informations de contexte d’exécution, permet d’identifier, via le tableau associatif l’adresse IP du client associée à l’identifiant du processus en charge de la connexion. Le calcul de la consommation CPU totale, mis en œuvre au cours de l’étape E20 permet ainsi d’associer une consommation CPU totale à la connexion TCP. Dans un exemple de réalisation, une deuxième instance de la structure de données struct task_struct propre au processus à l’origine de l’exécution de la fonction du noyau interceptée est mémorisée en association avec l’identifiant du processus. La deuxième instance comprend un intervalle de temps, noté Δί2 et appelé « deuxième intervalle de temps » correspondant au temps CPU consommé par le processus depuis sa création. Ce deuxième intervalle de temps est représentatif de l’activité passée du processus, c’est-à-dire depuis sa création et jusqu’à ce que la connexion TCP soit fermée. Ce deuxième intervalle de temps est destiné à être utilisé dans le calcul du temps d’exécution CPU dédié à la connexion au cours de l’étape E20 ;
Les fonctions suivantes sont spécifiques à une configuration dans laquelle plusieurs services interagissent pour fournir l’application Web. Typiquement, l’application Web implique un premier service HTTP, un deuxième service de création de pages Web dynamiques, tel que PHP et un troisième service de gestion de base de données, tel que MySQL. Dans ce cas, un processus d’un premier service peut communiquer avec un processus d’un deuxième service dans le cadre de l’exécution de l’application Web. Lorsque ce genre de communication est mis en œuvre, les services peuvent utiliser des mécanismes de communication inter processus pour se transmettre des requêtes. Dans une communication inter processus, on distingue un processus client qui transmet une requête à traiter à un processus serveur destiné à recevoir et traiter la requête. Bien sûr, dans une communication inter processus un processus serveur peut également jouer le rôle d’un processus client si, après avoir reçu une requête d’un processus client, il transmet lui-même une requête à un autre processus. C’est le cas par exemple lorsqu’un processus du service HTTP transmet une requête au service PHP qui lui-même fait appel à un service MySQL. Le service PHP joue successivement le rôle du serveur pour la requête en provenance du service HTTP et le rôle du client pour la requête qu’il transmet au service MySQL. Afin de mesurer le temps CPU total consommé pour traiter la connexion TCP, il est donc nécessaire de tracer ces communications inter processus afin d’identifier tous les processus impliqués dans le traitement de la connexion et de prendre en compte le temps CPU qu’ils ont consommé pour contribuer au traitement de la connexion TCP.
Dans un exemple de réalisation, les communications inter processus sont mises en œuvre au moyen d’un ensemble normalisé de fonctions de communication, également appelé interfaces de connexion. Le terme habituellement utilisé pour désigner cet ensemble de fonctions de communication est le terme anglais « socket ». Parmi les communications inter processus basées sur les sockets, on distingue les communications basées sur des sockets Unix et les communications basées sur des sockets TCP.
Dans le cas de communications inter processus reposant sur des sockets, les fonctions du noyau dont on souhaite superviser l’exécution sont les suivantes :
- dans une sous-étape E103 de l’étape E10 d’interception, l’exécution d’une fonction du noyau appelée lorsqu’un premier processus d’un premier service initie une communication avec un deuxième processus d’un deuxième service est interceptée. La communication entre les deux processus est initiée au moyen d’un socket en faisant un appel système de type connect. Ehi tel appel système est destiné à débuter une communication sur un socket.
Dans un premier exemple de réalisation, basé sur les socket Unix, le prototype de la fonction du noyau d’initiation d’une communication dont l’exécution est interceptée est : int unix_stream_connect(struct socket *sock, struct sockaddr *ua ddr, int addr_len, int f lags ) . Au retour de cette fonction, la connexion entre les premier et deuxième processus est établie. Dans cette communication le premier processus est le processus client et le deuxième processus est le processus serveur. L’identifiant du premier processus, ou processus client, qui a initié la communication est obtenu dans les informations de contexte d’exécution de la fonction du noyau. Il est possible de récupérer un objet représentatif de la communication côté processus serveur. Cet objet, struct sock, est obtenu dans le champ peer de l’argument struct socket *sock de la fonction. Ehi lien entre le processus client et l’objet struct sock *sock est mémorisé jusqu’à obtenir l’identifiant du processus serveur lorsque le processus serveur accepte la communication inter processus.
Dans un deuxième exemple de réalisation, basé sur les sockets TCP, le prototype de la fonction du noyau d’initiation d’une communication est :
int tcp_connect (struct sock *sk) . Cette fonction est appelée lorsqu’un processus souhaite établir une connexion TCP en faisant un appel système de type connect. Le processus qui fait l’appel système joue le rôle du client dans la connexion à établir entre les deux processus. L’interception de l’exécution de cette fonction permet de récupérer un 4-uplet TCP destiné à identifier la connexion entre les deux processus. Ce 4-uplet comprend une adresse IP source, un port source, une adresse IP destination et un port destination. Les connexions entre les processus client et serveur s’effectuent sur l’interface locale, i.e. sur le même équipement. De ce fait, les adresses IP source et destination sont égales à une adresse désignée par « localhost » pour une connexion locale. Les deux ports permettent donc d’identifier de manière unique la connexion depuis les deux processus. Un lien entre l’identifiant du processus client, à l’origine de l’appel système connect, et les ports source et destination est mémorisé jusqu’à identifier le processus serveur.
A noter qu’au moment de l’initiation d’une communication entre un processus client et un processus serveur, que ce soit au moyen d’un socket Unix ou d’un socket TCP, on ne connaît pas encore l’identifiant du processus serveur ;
- dans une sous-étape El 04 de l’étape E10 d’interception, l’exécution d’une fonction du noyau destinée à établir la communication entre deux processus de services différents, après initiation d’une communication inter processus, est interceptée. Cette fonction est appelée par le processus serveur lorsque celui-ci accepte des communications de processus client via des sockets. L’interception de l’exécution de cette fonction permet d’obtenir l’identifiant du processus serveur qui accepte la communication inter processus initiée par le processus client et permet ainsi de compléter le tableau associatif propre à la connexion TCP qui mémorise les identifiants des processus impliqués dans le traitement de la connexion TCP.
Dans un premier exemple de réalisation, basé sur les socket Unix, le prototype de la fonction du noyau d’établissement de la communication dont l’exécution est interceptée est : int unix_accept(struct socket *sock, struct socket *newsock, int flags). Cette fonction est appelée par un processus serveur qui souhaite accepter des communications de processus clients initiées via des sockets Unix. Cette fonction est bloquante dans le sens où elle ne retourne une valeur qu’une fois la connexion effectivement établie avec un processus client. L’interception du retour de cette fonction permet de récupérer l’objet struct_sock correspondant au côté serveur de la connexion. Plus précisément, cet objet est un champ de la structure struct socket *newsock, paramètre de unix_accept. Ainsi, il est possible de corréler l’identifiant du processus client avec l’identifiant du processus serveur à partir des informations sauvegardées lors de l’exécution de la fonction unix_stream_connect lorsque l’identifiant du socket obtenu dans le champ peer est identique à 1 ’ identifiant du socket qui figure dans 1 ’ obj et struct socket * news oc k.
Ainsi, lors de l’interception du retour de l’exécution de cette fonction, la communication entre le processus client et le processus serveur est établie et les identifiants du processus client et du processus serveur sont disponibles. L’identifiant du processus serveur est mémorisé dans le tableau associatif propre à la connexion TCP courante et qui comprend déjà l’identifiant du processus client.
Dans un deuxième exemple de réalisation, basé sur les socket TCP, le prototype de la fonction du noyau d’établissement de la communication est :
struct sock *inet_csk_accept(struct sock *sk, int flags, int *er r ) qui correspond à la fonction appelée dès lors que des services écoutent sur un port TCP pour recevoir des connexions. Cette fonction est bloquante et ne retourne qu’une fois qu’une connexion a été établie avec un processus client. A noter que cette fonction a été interceptée lors d’une demande de connexion d’un client et a permis d’associer un identifiant de processus à l’adresse IP du client. Afin de distinguer la connexion client à travers le réseau des connexions inter processus sur le système, le 4-uplet TCP est examiné. Il est vérifié si les adresses IP source et destination sont égales à l’adresse « localhost », indiquant qu’il s’agit d’une connexion locale, c’est-à-dire une connexion inter processus sur le même système. En interceptant le retour de cette fonction, on récupère le 4-uplet à partir de la valeur de retour struct sock * de la fonction du noyau. L’égalité entre le port source et le port destination permet d’obtenir l’identifiant du processus client à partir des données mémorisées lors de l’interception de l’exécution de la fonction tcp_connect. Ainsi l’identifiant du processus serveur est corrélé à l’identifiant du processus client, lui-même associé à l’identifiant de la connexion TCP dans le tableau associatif.
Dans un exemple de réalisation, mis en œuvre lors de l’interception de l’exécution de la fonction du noyau d’établissement d’une communication inter processus au moyen d’un socket Unix ou TCP, une première instance de la structure de données struct task_struct associée au processus serveur est mémorisée, en association avec l’identifiant du processus serveur. Cette première instance comprend un premier intervalle de temps, noté Δίχ, qui correspond au temps CPU consommé par le processus serveur depuis sa création. Cette valeur est destinée à être utilisée pour calculer le temps CPU total consacré au traitement de la connexion TCP, plus précisément afin de calculer le temps CPU consommé par le processus serveur pour traiter la connexion TCP.
Ainsi, que ce soit au moyen de socket Unix ou de socket TCP, le procédé offre une solution pour identifier précisément l’ensemble de processus qui sont impliqués dans chacune des connexions TCP qui émanent d’équipements clients. Un chaînage de processus est ainsi mémorisé dans le tableau associatif et ce chaînage de processus est adapté pour calculer précisément le temps CPU dédié à chacune des connexions TCP à partir des temps CPU que chacun des processus a consommé lors du traitement de la connexion TCP. Par ailleurs, le temps CPU peut être précisé et décliné pour chacun des services obtenu pour chacun des services impliqués dans l’exécution de l’application Web dès lors que l’on segmente les informations relatives aux processus impliqués en fonction des services sous-jacents ;
- dans une sous-étape E105 de l’étape E10 d’interception, l’exécution d’une fonction du noyau représentative de la fermeture d’une connexion inter processus est interceptée.
Dans un premier exemple de réalisation, basé sur les socket Unix, le prototype de la fonction représentative de la fermeture d’une communication inter processus est : int unix_shutdown (struct socket *sock, int mode). L’exécution de cette fonction est interceptée afin de détecter la fin de la communication inter processus. Dans un exemple de réalisation, cela déclenche le calcul de la consommation CPU du processus serveur qui participe à la communication inter processus. L’identifiant du processus serveur est obtenu à partir de l’argument struct socket * sock de la fonction unix_shutdown.
Dans un deuxième exemple de réalisation, basé sur les socket TCP, le prototype de la fonction représentative de la fermeture d’une communication inter processus est : void tcp_set_state (struct sock *sk, int state). L’identifiant du processus serveur est obtenu à partir de l’argument struct sock *sk.
Dans un exemple de réalisation, mis en œuvre lors de l’interception de l’exécution de la fonction du noyau représentative de la fermeture de la communication inter processus au moyen d’un socket Unix ou TCP, une deuxième instance de la structure de données struct task_struct associée au processus serveur est mémorisée, en association avec l’identifiant du processus serveur. Cette deuxième instance comprend un deuxième intervalle de temps, noté Δί2, qui correspond au temps CPU consommé par le processus serveur depuis sa création. Cette valeur est destinée à être utilisée pour calculer le temps CPU total consacré au traitement de la connexion TCP, plus précisément afin de calculer le temps CPU consommé par le processus serveur pour le traitement de la connexion TCP.
Comme précisé précédemment, l’exécution des sous-étapes E101 à E105 commence par une vérification que le processus pour lequel la fonction du noyau dont l’exécution a été interceptée fait partie de la liste de processus supervisés. Pour un processus qui ne fait pas partie de la liste, l’exécution de la sous-étape est interrompue.
Dans l’étape suivante E20 de calcul du temps CPU, mise en œuvre lors de l’interception au cours de l’étape E102 de l’étape E10 d’interception du retour de l’exécution de la fonction du noyau représentative d’une fermeture de la connexion courante, il est procédé au calcul du temps CPU total consommé par l’ensemble des processus impliqués dans le traitement de la connexion TCP. Ce temps correspond à la somme des temps CPU que chacun des processus impliqué dans l’exécution de l’application Web lancée depuis la connexion client a consommé lors du traitement de la connexion TCP.
Lors de l’exécution de l’application Web, il a été mémorisé dans le tableau associatif un identifiant d’une connexion TCP courante en association avec l’ensemble des identifiants de processus impliqués dans le traitement de la connexion. Pour chacun des processus impliqués, il a été mémorisé une première instance de la structure de données struct task_structà un instant initial, représentatif d’un début d’activité du processus pour le traitement de la connexion. Cette première instance comprend un premier intervalle de temps, Δί1; représentatif du temps CPU consommé par le processus depuis sa création jusqu’à l’instant initial. Il a également été mémorisé une deuxième instance de la structure de données struct task_struct à un second instant, représentatif d’une fin de contribution du processus au traitement de la connexion TCP. La deuxième instance comprend un deuxième intervalle de temps, Δί2, représentatif du temps CPU consommé par le processus depuis sa création jusqu’au second instant. Ainsi, le temps At, correspondant au temps CPU consommé par le processus pour traiter la connexion TCP est obtenu en calculant la différence entre le deuxième et le premier intervalle de temps. En d’autres termes, At = At2 — Atr . En faisant la somme des temps CPU que chacun des processus a consommé pour traiter la connexion TCP on obtient le temps CPU total du serveur consommé pour le traitement de la connexion.
Dans le cas où un seul service est impliqué dans l’exécution de l’application Web, les premier et deuxième intervalles de temps correspondent respectivement à l’intervalle de temps qui figure dans la structure de donnée struct task_struct lors de l’interception du retour de la fonction du noyau appelée pour demander l’ouverture d’une connexion TCP et à l’intervalle de temps qui figure dans la structure de données struct task_struct lors de l’interception de l’exécution de la fonction de fermeture de la connexion.
Dans le cas où plusieurs services sont impliqués et que des communications inter processus sont mises en œuvre, les premier et deuxième intervalles pris en compte pour un processus backend correspondent respectivement à l’intervalle de temps qui figure dans la structure de donnée struct task_struct du processus lors de l’interception de l’exécution de la fonction du noyau d’établissement de la communication consécutive à l’initiation d’une communication par un autre processus, et à l’intervalle de temps qui figure dans la structure de données struct task_struct du processus lors de l’interception de l’exécution de la fonction du noyau de fermeture de la communication.
Dans l’exemple de réalisation de l’étape E20 de calcul de temps CPU total décrit ici, le calcul du temps CPU total est mis en œuvre à la fermeture de la connexion TCP, à partir des structures de données struct task_struct mémorisées durant l’exécution de l’application Web. Dans un autre exemple de réalisation, le calcul est mis en œuvre au fil de l’eau. Ainsi, les temps CPU consommés par les processus qui participent au traitement de la connexion TCP sont cumulés au fil du temps. Le calcul de la valeur du temps CPU total est finalisé lors de la fermeture de la connexion TCP. Cet exemple de réalisation permet de limiter le stockage des structures de données struct task_struct. L’espace mémoire nécessaire à la mise en œuvre du procédé d’aide à la détection d’attaques par dénis de services applicatifs est ainsi optimisé.
Dans un exemple de réalisation, un outil ou interface appelé eBPF (pour « extended Berkeley Packet Filter »), destiné à traiter des événements, tels que des appels aux fonctions interceptées directement dans le contexte du noyau du système d’exploitation est utilisé. Cependant cet outil ne permet d’accéder à la structure de données struct task_struct qui contient la durée d’activité d’un processus courant que dans des versions récentes du noyau du système d’exploitation Linux. Dans un autre exemple de réalisation, mis en œuvre pour des versions plus anciennes du noyau, l’exécution de certaines fonctions du noyau du système d’exploitation est interceptée de manière à récupérer la structure de données struct task_struct d’un processus qui fait partie de la liste des processus à superviser. Ces fonctions sont :
-struct rq *finish_task_switch(struct task_struct *prev) ;
cette fonction est appelée après qu’un nouveau processus ait été assigné par l’ordonnanceur (ou « scheduler » en anglais) au CPU. L’argument struct task_struct *prev représente le processus précédemment assigné au CPU et la structure de données struct task_struct comprend l’identifiant du nouveau processus. Intercepter l’exécution de cette fonction permet de récupérer les structures de données struct task_struct correspondant aux processus supervisés au fur et à mesure que leur exécution est arrêtée. Lors de l’interception de l’exécution de cette fonction, l’adresse de la structure de données struct task_struct est mémorisée en association avec l’identifiant du processus à laquelle elle est associée. Cependant, l’interception de l’exécution de cette fonction implique qu’un processus soit arrêté avant de pouvoir calculer sa consommation de temps CPU. Il y a donc, au lancement de l’outil de supervision, un laps de temps pendant lequel la consommation CPU associée à une connexion TCP ne peut être observée. Ce laps de temps s’applique aussi à tout nouveau processus jusqu’à ce qu’un autre processus soit pris en charge par le CPU. Pour pallier ce problème, l’exécution de la fonction du noyau suivante est intercepté, afin d’obtenir la structure de données struct task struct d’un processus dès sa création :
-void wake_up_new_task (struct task_struct *p) ; cette fonction est appelée lorsqu’un nouveau processus est créé à l’aide d’appels système. L’argument struct task_struct *p fournit l’adresse en mémoire de l’objet struct task_struct associé au nouveau processus. Il est alors mémorisé une association entre l’identifiant du nouveau processus et l’adresse en mémoire de l’objet struct task_struct.
Le procédé décrit ici repose sur des communications inter processus basées sur des sockets et ne tient pas compte de communications inter processus basées sur une mémoire partagée, (« shared memory Inter Process Communication » en anglais). Dans des communications basées sur une mémoire partagée, le noyau du système d’exploitation réserve un espace mémoire que les processus utilisent ensuite pour communiquer, sans passer par le noyau. On considère que ce cas nécessite de définir un protocole très bas niveau au niveau de l’application Web et complexifie également pour un programme de supervision l’obtention d’informations sur les temps CPU des processus. Le procédé décrit ici s’applique à des applications web pour lesquelles les communications inter processus reposent sur une interface standardisée, en l’espèce les communications inter processus basées sur les sockets.
Le procédé tel que décrit précédemment suppose qu’un processus ne traite qu’une seule connexion TCP à la fois. Il est cependant possible que des processus d’un serveur aient un fonctionnement asynchrone : chaque processus s’occupe alors de plusieurs connexions TCP en même temps. Ce mode de fonctionnement est parfois utilisé pour des processus frontend qui se contentent de transmettre des requêtes à des processus backend. Ainsi, plutôt que d’attendre qu’un processus backend termine le traitement d’une connexion TCP, le processus frontend continue de transmettre des requêtes liées à une connexion TCP à d’autres processus backend. Ainsi, un petit nombre de processus frontend est nécessaire pour dispatcher un grand nombre de requêtes à des processus backend. Dans un tel fonctionnement asynchrone, le procédé décrit ici néglige la consommation de temps CPU induite par les processus frontend. En effet, parce que les processus frontend se contentent de dispatcher les requêtes TCP au processus backend, on estime qu’ils consomment très peu de temps CPU pour traiter une connexion distante. Négliger ce temps n’impacte donc pas le temps total de consommation CPU de manière significative. Dans un exemple de réalisation, un traitement asynchrone des connexions par un serveur peut être détecté par l’outil dans une phase de pré-analyse. En effet, un processus traitant des connexions TCP de façon asynchrone reçoit de nouvelles connexions avant d’avoir fermé les précédentes. Lors de l’interception de l’exécution de fonctions du noyau, un processus asynchrone fait donc des appels système de type accept sans qu’il y ait forcément un appel système de type close. La phase de pré-analyse est agencée pour détecter qu’au moins deux appels système accept sont mis en œuvre, sans qu’un appel système de type close soit détecté.
Le procédé d’aide à la détection d’attaques par dénis de services applicatifs tel que décrit précédemment peut facilement s’intégrer à des procédés de détection d’attaques. De tels procédés reposent en général sur des métriques particulières que l’on ne détaillera pas ici. On peut citer cependant que le procédé d’aide à la détection permet d’identifier des connexions de certains équipements client pour lesquelles le traitement par le serveur est anormalement long par rapport à des requêtes équivalentes en provenance d’autres équipements client. Il offre également une aide à l’analyse en permettant d’identifier quels processus et/ou quel(s) service(s) sont à l’origine d’une consommation CPU anormale.
Pour des raisons de clarté, on a décrit ici le cas d’une connexion TCP établie à partir d’un équipement client. Bien sûr, le procédé est prévu pour gérer en parallèle une pluralité de connexions TCP entrantes et les moyens décrits permettent de gérer pour chacune des connexions les informations relatives au processus impliqués et de calculer pour chacune des connexions TCP le temps CPU consacré au traitement de cette connexion.
Un serveur 20, apte à mettre en œuvre les étapes du procédé d’aide à la détection d’attaques par dénis de services applicatifs, selon un exemple de réalisation, va maintenant être décrit en relation avec la figure 2.
Le serveur 20 est un équipement informatique tel un ordinateur. Il comprend :
- une unité de traitement ou processeur 201, ou CPU, destinée à charger des instructions en mémoire, à les exécuter, à effectuer des opérations ;
- un ensemble de mémoires, dont une mémoire volatile 202, ou « RAM » (pour « Random Access Memory »), utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mémoire de stockage 203 de type « EEPROM » (de l’anglais « Electrically Erasable Programmable Read Only Memory »). En particulier, la mémoire de stockage 203 est agencée pour mémoriser un premier programme, comprenant des instructions de code pour mettre en œuvre une application, telle qu’une application Web, et un deuxième programme qui comprend des instructions de code pour mettre en œuvre les étapes du procédé d’aide à la détection d’attaques par dénis de services tel que décrit précédemment ;
Le serveur 20 comprend également :
- un premier module 204 d’interception et d’obtention, agencé pour intercepter l’exécution d’une fonction du noyau du système d’exploitation représentative de la réception d’une demande de connexion à l’application en provenance d’un équipement client, et pour associer un identifiant de ladite connexion à l’identifiant d’un processus, ledit processus étant en charge du traitement de ladite connexion. Le premier module 204 d’interception et d’obtention est également agencé pour obtenir un premier intervalle de temps représentatif d’un temps CPU consommé par ledit processus depuis sa création. Le module 204 d’interception et d’obtention est agencé pour mettre en œuvre l’étape E101 du procédé d’aide à la détection d’attaques par dénis de services applicatifs ;
- un deuxième module 205 d’interception et d’obtention, agencé pour intercepter l’exécution d’une deuxième fonction du noyau du système d’exploitation représentative d’une fermeture de ladite connexion. Le deuxième module 205 d’interception et d’obtention est également agencé pour obtenir un deuxième intervalle de temps représentatif d’un temps CPU consommé par ledit processus depuis sa création. Ue deuxième module 205 d’interception et d’obtention est également agencé pour obtenir un premier intervalle de temps représentatif d’un temps CPU consommé par ledit processus depuis sa création. Le deuxième module 205 d’interception et d’obtention est agencé pour mettre en œuvre l’étape E102 du procédé d’aide à la détection d’attaques par dénis de services applicatifs ;
- un module de calcul 206, agencé pour calculer un temps CPU total consommé pour le traitement de ladite connexion à partir d’au moins le deuxième et le premier intervalle de temps CPU consommé par ledit processus. Le module de calcul 206 est agencé pour mettre en œuvre l’étape E20 du procédé décrit précédemment.
Le premier module 204 d’interception et d’obtention, le deuxième module 205 d’interception et d’obtention et le module de calcul 206 sont de préférence des modules logiciels comprenant des instructions logicielles pour mettre en œuvre les étapes du procédé d’aide à la détection d’attaques par dénis de services applicatifs qui sont mises en œuvre par le serveur 20.
L'invention concerne donc aussi :
- un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d’aide à la détection d’attaques par dénis de services applicatifs tel que décrit précédemment lorsque ce programme est exécuté par un processeur du serveur, et
- un support d’enregistrement lisible sur lequel est enregistré le programme d'ordinateur décrit ci-dessus.
Claims (8)
- REVENDICATIONS1. Procédé d’aide à la détection d’attaques par dénis de service applicatifs dans un système proposant au moins une application, ladite application utilisant au moins un service, le procédé comprenant :- interception (E101) de l’exécution d’une fonction du noyau du système d’exploitation représentative de la réception d’une demande de connexion à l’application en provenance d’un équipement client, association d’un identifiant de ladite connexion à l’identifiant d’au moins un processus, ledit processus étant en charge du traitement de ladite connexion sur un premier service, et obtention d’un premier intervalle de temps représentatif d’un temps CPU consommé par ledit processus depuis sa création,- interception (E102) de l’exécution d’une deuxième fonction du noyau du système d’exploitation représentative d’une fermeture de ladite connexion, et obtention d’un deuxième intervalle de temps représentatif d’un temps CPU consommé par ledit processus depuis sa création,- calcul (E20) d’un temps CPU total consommé pour le traitement de ladite connexion à partir d’au moins le deuxième et le premier intervalle de temps CPU consommé par ledit processus.
- 2. Procédé selon la revendication 1 comprenant, lorsque ladite application utilise au moins deux services et qu’un premier processus d’un premier des au moins deux services établit une communication avec un deuxième processus d’un deuxième des au moins deux services, un identifiant dudit premier processus étant associé à l’identifiant de ladite connexion :- interception (E103) de l’exécution d’une fonction du noyau du système d’exploitation représentative d’une demande d’établissement d’une communication entre le premier processus et le deuxième processus,- interception (E104) de l’exécution d’une fonction du noyau du système d’exploitation représentative de l’établissement de la communication entre le premier et le deuxième processus, association d’un identifiant du deuxième processus à l’identifiant de ladite connexion, et obtention d’un deuxième premier intervalle de temps représentatif du temps CPU consommé par le deuxième processus depuis sa création,- interception (E105) de l’exécution d’une fonction du noyau du système d’exploitation représentative de la fermeture de la communication entre le premier processus et le deuxième processus, et obtention d’un deuxième intervalle de temps représentatif du temps CPU consommé par le deuxième processus depuis sa création,- calcul (E20) d’un deuxième temps CPU de traitement associé à ladite communication à partir du deuxième et du premier deuxième intervalle de temps,- prise en compte du deuxième temps CPU pour le calcul du temps CPU total consommé pour le traitement de ladite connexion.
- 3. Procédé selon la revendication 2, dans lequel l’identifiant du deuxième processus est associé à l’identifiant de ladite connexion lorsqu’un premier identifiant de la communication entre le premier et le deuxième processus, ledit premier identifiant étant obtenu dans une structure de données associée au premier processus est identique à un deuxième identifiant de la communication entre le premier et le deuxième processus, ledit deuxième identifiant étant obtenu dans une structure de données associée au deuxième processus.
- 4. Procédé selon l’une des revendications précédentes, comprenant, dans une étape de configuration initiale une fourniture d’une liste de processus à superviser pour ladite application, et- interception (E02) de l’exécution d’une fonction du noyau du système d’exploitation représentative de la création d’un processus fds par un processus parent,- lorsque le processus parent appartient à la liste des processus à superviser, obtention de l’identifiant dudit processus fils et ajout dudit processus fils à la liste des processus à superviser.
- 5. Procédé selon la revendication précédente, comprenant :- interception (E03) de l’exécution d’une fonction du noyau du système d’exploitation représentative de l’arrêt d’un processus existant,- lorsque le processus existant appartient à la liste des processus à superviser, obtention de l’identifiant dudit processus existant et suppression dudit processus existant dans la liste des processus à superviser.
- 6. Serveur (20) apte à héberger au moins une application, ladite application utilisant au moins un service, ledit serveur comprenant :- des premiers moyens (204) d’interception et d’obtention, agencés pour intercepter l’exécution d’une fonction du noyau du système d’exploitation représentative de la réception d’une demande de connexion à l’application en provenance d’un équipement client, associer un identifiant de ladite connexion à l’identifiant d’au moins un processus, ledit processus étant en charge du traitement de ladite connexion, et pour obtenir un premier intervalle de temps représentatif d’un temps CPU consommé par ledit processus depuis sa création,- des deuxièmes moyens (205) d’interception et d’obtention, agencés pour intercepter l’exécution d’une deuxième fonction du noyau du système d’exploitation représentative d’une5 fermeture de ladite connexion, et pour obtenir un deuxième intervalle de temps représentatif d’un temps CPU consommé par ledit processus depuis sa création,- des moyens de calcul (206), agencés pour calculer un temps CPU total consommé pour le traitement de ladite connexion à partir d’au moins le deuxième et le premier intervalle de temps CPU consommé par ledit processus.
- 7. Programme pour un serveur apte à héberger au moins une application utilisant au moins un service, ledit programme comprenant des instructions de code de programme destinées à commander l’exécution des étapes du d’aide à la détection d’attaques par dénis de service applicatifs, selon l’une des revendications 1 à 5, lorsque le programme est exécuté sur15 ledit serveur.
- 8. Support de données dans lequel est enregistré le programme selon la revendication 7.PO1/1
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1752576A FR3064772B1 (fr) | 2017-03-28 | 2017-03-28 | Procede d’aide a la detection d’attaques par denis de services |
| PCT/FR2018/050714 WO2018178545A1 (fr) | 2017-03-28 | 2018-03-23 | Procédé d'aide à la détection d'attaques par dénis de services |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1752576A FR3064772B1 (fr) | 2017-03-28 | 2017-03-28 | Procede d’aide a la detection d’attaques par denis de services |
| FR1752576 | 2017-03-28 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3064772A1 true FR3064772A1 (fr) | 2018-10-05 |
| FR3064772B1 FR3064772B1 (fr) | 2019-11-08 |
Family
ID=59520993
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1752576A Active FR3064772B1 (fr) | 2017-03-28 | 2017-03-28 | Procede d’aide a la detection d’attaques par denis de services |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR3064772B1 (fr) |
| WO (1) | WO2018178545A1 (fr) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109977633B (zh) * | 2019-03-28 | 2023-04-07 | 武汉斗鱼鱼乐网络科技有限公司 | 一种程序保护方法及相关装置 |
| CN112199668B (zh) * | 2020-09-01 | 2024-03-01 | 中国科学院信息工程研究所 | 一种检测容器中应用层消耗CPU的DoS攻击的方法和装置 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1788752A1 (fr) * | 2005-11-21 | 2007-05-23 | Alcatel Lucent | Noeud de réseau avec protection de surcharge de processeur de plan de contrôle |
| US20140304798A1 (en) * | 2013-04-06 | 2014-10-09 | Citrix Systems, Inc. | Systems and methods for http-body dos attack prevention with adaptive timeout |
| WO2015145210A1 (fr) * | 2014-03-27 | 2015-10-01 | Telefonaktiebolaget L M Ericsson (Publ) | Procédé et système de protection contre les attaques par refus de service distribuées |
-
2017
- 2017-03-28 FR FR1752576A patent/FR3064772B1/fr active Active
-
2018
- 2018-03-23 WO PCT/FR2018/050714 patent/WO2018178545A1/fr active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1788752A1 (fr) * | 2005-11-21 | 2007-05-23 | Alcatel Lucent | Noeud de réseau avec protection de surcharge de processeur de plan de contrôle |
| US20140304798A1 (en) * | 2013-04-06 | 2014-10-09 | Citrix Systems, Inc. | Systems and methods for http-body dos attack prevention with adaptive timeout |
| WO2015145210A1 (fr) * | 2014-03-27 | 2015-10-01 | Telefonaktiebolaget L M Ericsson (Publ) | Procédé et système de protection contre les attaques par refus de service distribuées |
Non-Patent Citations (1)
| Title |
|---|
| VILHELM GRAY: "linux - How do I get the total CPU usage of an application from /proc/pid/stat? - Stack Overflow", 24 May 2013 (2013-05-24), pages 1 - 4, XP055413055, Retrieved from the Internet <URL:https://stackoverflow.com/questions/16726779/how-do-i-get-the-total-cpu-usage-of-an-application-from-proc-pid-stat> [retrieved on 20171005] * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3064772B1 (fr) | 2019-11-08 |
| WO2018178545A1 (fr) | 2018-10-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3479285B1 (fr) | Procédé et dispositif de surveillance de la sécurité d'un système d'information | |
| EP2724509B1 (fr) | Procédé de détection d'attaques et de protection | |
| EP2705644B1 (fr) | Procede et dispositif de detection d'intrusions sur un ensemble de ressources virtuelles | |
| EP3156931B1 (fr) | Procédé de détection de vulnerabilités dans un serveur virtuel de production d'un système informatique virtuel ou en nuage | |
| EP2962242B1 (fr) | Procede de detection d'attaques de machines virtuelles | |
| US10230690B2 (en) | Digital media content distribution blocking | |
| CN108632213A (zh) | 设备信息处理方法及装置 | |
| CN108052824B (zh) | 一种风险防控方法、装置及电子设备 | |
| US20210084073A1 (en) | Advanced detection of identity-based attacks to assure identity fidelity in information technology environments | |
| EP3398316B1 (fr) | Procede de traitement d'un service reseau | |
| EP3931694A1 (fr) | Procédé d'évaluation des dispositifs d'une infrastructure de réseau en vue du déploiement d'une fonction virtualisée | |
| FR3061570A1 (fr) | Mecanisme de surveillance et d'alertes des applications du systeme informatique | |
| Izhikevich et al. | Predicting ipv4 services across all ports | |
| FR3064772B1 (fr) | Procede d’aide a la detection d’attaques par denis de services | |
| FR3096531A1 (fr) | Procédé d’allocation de ressources d’une infrastructure de réseau | |
| EP3029573B1 (fr) | Systeme et methode de test de performances d'une infrastructure informatique | |
| WO2022034273A1 (fr) | Procede de traitement d'un service de transport de donnees | |
| FR3096535A1 (fr) | Procédés et dispositifs de sécurisation d’un réseau de périphérie à accès multiple | |
| FR3058810A1 (fr) | Procede et dispositif d'actualisation d'un modele predictif d'une variable relative a un terminal mobile | |
| WO2023217638A1 (fr) | Procédé, dispositif et système de certification d'une ressource | |
| WO2023217639A1 (fr) | Procédé, dispositif et système d'élaboration dynamique d'une infrastructure de données | |
| Aijaz et al. | Performance analysis of a framework for multi-interfaced service level agreements on mobile devices | |
| WO2020128246A1 (fr) | Procédé de détermination d'un chemin de transmission de données, et dispositif correspondant | |
| FR3038413A1 (fr) | Procede de gestion de l'authentification d'un client dans un systeme informatique | |
| FR3004304A1 (fr) | Procede de caracterisation d'un reseau informatique |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20181005 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |