FR3081574A1 - Procedes de gestion du trafic associe a un domaine client, serveur, nœud client et programme d'ordinateur correspondants. - Google Patents

Procedes de gestion du trafic associe a un domaine client, serveur, nœud client et programme d'ordinateur correspondants. Download PDF

Info

Publication number
FR3081574A1
FR3081574A1 FR1856024A FR1856024A FR3081574A1 FR 3081574 A1 FR3081574 A1 FR 3081574A1 FR 1856024 A FR1856024 A FR 1856024A FR 1856024 A FR1856024 A FR 1856024A FR 3081574 A1 FR3081574 A1 FR 3081574A1
Authority
FR
France
Prior art keywords
client
server
attack
node
domain
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.)
Pending
Application number
FR1856024A
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
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.)
Orange SA
Original Assignee
Orange 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 Orange SA filed Critical Orange SA
Priority to FR1856024A priority Critical patent/FR3081574A1/fr
Priority to US17/256,377 priority patent/US11563816B2/en
Priority to EP19752541.3A priority patent/EP3815336A1/fr
Priority to PCT/FR2019/051605 priority patent/WO2020002853A1/fr
Publication of FR3081574A1 publication Critical patent/FR3081574A1/fr
Pending legal-status Critical Current

Links

Classifications

    • 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/14—Session management
    • H04L67/148—Migration or transfer of sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • 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/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels

Landscapes

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

Abstract

L'invention concerne un procédé de gestion du trafic associé à un domaine client, mis en œuvre dans un serveur, ledit procédé comprenant : - la détection (21) d'un problème de communication entre ledit serveur et au moins un premier nœud client dudit domaine client, dit nœud défaillant, - l'identification (22) d'au moins un deuxième nœud client appartenant audit domaine client, - la vérification (23) si une session est active entre ledit serveur et ledit au moins un deuxième nœud client, et ○ si aucune session n'est active : le déclenchement d'une procédure de mitigation sur au moins une ressource IP associée audit domaine client, ○ si au moins une session est active : l'utilisation du deuxième nœud client associé à ladite au moins une session active, dit nœud actif, pour engager une action de gestion du trafic associé audit domaine client.

Description

Procédés de gestion du trafic associé à un domaine client, serveur, nœud client et programme d'ordinateur correspondants.
1. Domaine de l'invention
Le domaine de l'invention est celui des communications au sein d'un réseau de communication, par exemple un réseau IP, et notamment celui des services IP à valeur ajoutée.
Plus précisément, l'invention offre une solution pour gérer le trafic associé à un domaine client, c'est-à-dire entrant dans un domaine client ou sortant d'un domaine client, en cas de détection d'un problème de communication entre le serveur et un nœud client du domaine client.
En particulier, l'invention offre une solution permettant d'éviter le déclenchement systématique d'une procédure de mitigation en cas de perte de connexion entre un serveur et un nœud client.
L'invention trouve notamment des applications dans le domaine de la mitigation d'attaques par déni de services distribuées (en anglais DDoS, pour « Distributed Denial of Service »), mettant par exemple en œuvre, mais non exclusivement, une architecture de type DOTS (en anglais « DDoS Open Threat Signaling »), telle que normalisée par l'IETF.
2. Art antérieur
Pour rappel, une attaque DDoS est une tentative de rendre des ressources, par exemple des ressources réseau ou de calcul, indisponibles pour leurs utilisateurs. De telles attaques peuvent être massivement déployées en compromettant un grand nombre d'hôtes, et en utilisant ces hôtes pour amplifier les attaques.
Afin de pallier à ces attaques DDoS, des services de détection et de mitigation des attaques DDoS sont proposés par certains fournisseurs d'accès ou de services à leurs clients. De tels services de mitigation (en anglais DPS pour « DDoS Protection Services ») peuvent être hébergés au sein des infrastructures exploitées par les fournisseurs d'accès ou dans le « cloud » (en français « nuage »). Ils permettent notamment de distinguer le trafic « légitime », Le., les données consenties par l'utilisateur, du trafic « suspect ».
Lorsqu'un service de type DPS est hébergé dans le « cloud », il est difficile d'identifier une attaque DDoS de façon anticipée, car un tel service n'est pas présent sur les chemins de routage (par défaut) permettant de joindre le réseau victime d'une attaque DDoS.
Pour résoudre ce problème, il a été notamment proposé de mettre en place des tunnels pour forcer le trafic (entrant ou sortant) sur un site ou un réseau destiné à être inspecté par le service DPS. Toutefois, cette approche augmente considérablement la latence observée par les utilisateurs et impose des contraintes de dimensionnement du service DPS pour être en mesure de traiter tout le trafic entrant ou sortant de tous les utilisateurs du réseau.
Lorsqu'un service de type DPS est hébergé au sein d'une infrastructure exploitée par un fournisseur d'accès, même si le service DPS est présent sur le chemin de routage du trafic entrant ou sortant d'un réseau, des difficultés peuvent survenir pour l'identification du trafic suspect. Notamment, avec l'augmentation du trafic chiffré, transporté en particulier sur UDP (par exemple, le trafic QUIC, pour «Quick UDP Internet Connection » en anglais), il est difficile de distinguer le trafic légitime du trafic suspect. La difficulté d'accéder en clair aux messages de contrôle, tels que les messages « SYN/SYN-ACK/ACK » prévus dans le protocole TCP, peut en effet rendre complexe la vérification du consentement d'un nœud du réseau à recevoir du trafic.
Afin d'aider à l'identification du trafic suspect, une architecture spécifique a été normalisée par l'IETF. Une telle architecture, appelée DOTS, permet à un nœud client, dit client DOTS, d'informer un serveur, dit serveur DOTS, que son réseau est sujet à une attaque DDoS et que des actions appropriées sont requises.
Ainsi, si un domaine client est la cible d'une attaque DDoS, un client DOTS attaché à ce domaine client peut envoyer un message au serveur DOTS pour demander de l'aide. Ce dernier coordonne, avec une entité de mitigation (en anglais « mitigator »), les actions à effectuer pour que le trafic suspect, associé à l'attaque de déni de service, ne soit plus acheminé vers le domaine client, alors que le trafic légitime continue d'être acheminé normalement vers le domaine client.
Cette solution utilise deux canaux de communication entre le client DOTS et le serveur DOTS :
un canal de signalisation DOTS (en anglais « DOTS Signal Channel »), et un canal de données DOTS (en anglais « DOTS Data Channel »).
Le canal de signalisation DOTS est uniquement utilisé quand une attaque DDoS est en cours. Ainsi, un client DOTS peut utiliser ce canal pour demander de l'aide auprès du serveur DOTS. Par exemple, un client DOTS utilise ce canal de signalisation pour envoyer une requête au serveur l'informant que le préfixe « 1.2.3.0/24 » subit une attaque DDoS, afin que le serveur puisse engager des actions pour mettre fin à l'attaque. Une telle requête est associée à un client DOTS identifié par un identifiant unique, noté par exemple CUID (« Client Unique Identifier »).
Un serveur DOTS peut ainsi prendre les mesures adéquates pour mettre fin à une attaque DDoS d'une part si la requête émanant du client DOTS n'est pas en conflit avec d'autres demandes émanant d'autres clients du même domaine client, ou avec une règle de filtrage installée préalablement sur le serveur par un autre client du domaine client, et d'autre part si le serveur est habilité à/configuré pour honorer la dernière requête reçue. En cas de conflit, le serveur peut envoyer un message d'erreur, par exemple de type 4.09 (« Conflict »), pour informer le client.
Un tel canal de signalisation est notamment décrit dans le document « Distributed Denialof-Service Open Threat Signaling (DOTS) Signal Channel Specification », draft-ietf-dots-signalchannel, Reddy, T. et al., janvier 2018.
Le canal de données DOTS est quant à lui utilisé lorsqu'aucune attaque DDoS n'est en cours. Par exemple, un client DOTS peut utiliser ce canal pour installer des règles de filtrage, telles que le filtrage du trafic reçu de certaines adresses ou celui destiné à un nœud donné. Par exemple, un client DOTS peut utiliser ce canal de données DOTS pour demander au serveur de bloquer tout le trafic à destination du préfixe « 1.2.3.0/24 ».
Le serveur DOTS peut procéder à l'installation de règles de filtrage en réponse à une demande envoyée par un client, si cette demande n'est pas en conflit avec d'autres demandes provenant d'autres clients du même domaine client ou avec une règle de filtrage existante. En cas de conflit avec d'autres règles maintenues par le serveur DOTS, le serveur peut envoyer un message d'erreur, par exemple de type 409 (« Conflict »), pour informer le client.
Un tel canal de données est notamment décrit dans le document « Distributed Denial-ofService Open Threat Signaling (DOTS) Data Channel», draft-ietf-dots-data-channel, Reddy, T. et al., décembre 2017.
Selon la procédure décrite dans les deux documents précités, il existe un risque qu'un serveur DOTS refuse de traiter une demande de mitigation d'attaque émise par un client DOTS alors que l'attaque est réelle, ou refuse des demandes de filtrage émise par un client DOTS (un objectif des demandes de filtrage étant d'anticiper des attaques DDoS). Un tel refus peut notamment survenir lorsque des clients du domaine client ont préalablement demandé au serveur d'installer des règles de filtrage, mais que ces règles ne sont désormais plus justifiées (en anglais « stale »).
Par ailleurs, l'architecture DOTS a été conçue pour supporter la mitigation automatique d'attaques de déni de service par un serveur en cas de perte de la session établie avec un client DOTS. La mise en œuvre de cette procédure est dépendante de la valeur d'un paramètre de déclenchement de mitigation, noté « trigger-mitigation », associé à un client DOTS du domaine client au cours d'une phase de négociation de configuration.
En d'autres termes, si la valeur de ce paramètre de déclenchement de mitigation est valorisée par le client DOTS à « FAUX », ou « false » en anglais, le serveur DOTS déclenche automatiquement une procédure de mitigation s'il ne reçoit plus de messages depuis ce client
DOTS.
Par exemple, tant que le serveur DOTS reçoit des messages réguliers de présence du client DOTS, par exemple de type « Heartbeat », le trafic entrant (c'est-à-dire destiné au domaine client) est acheminé normalement par les routeurs situés sur le chemin par défaut. Si le serveur DOTS ne reçoit plus de messages provenant du client DOTS, il décide de déclencher la procédure de mitigation automatique. Le trafic entrant peut ainsi être redirigé vers un centre « d'épuration » du trafic (« DDoS scrubber » ou « DDoS scrubbing center », en anglais), qui se charge d'éliminer le trafic d'attaque DDoS.
On note qu'un tel déclenchement automatique d'une procédure de mitigation peut être problématique dans le cas où l'absence de message d'un client DOTS n'est pas due à une attaque DDoS, mais à un autre problème (problème logiciel, opération de maintenance en cours sans clôture convenable de la session DOTS, nœud intermédiaire indisponible, etc.).
En particulier, la redirection du trafic entrant vers un centre d'épuration peut être dommageable pour le client car elle augmente le délai de transfert du trafic, voire empêche l'acheminement du trafic, alors que l'absence de message d'un client DOTS n'est pas nécessairement due à une attaque DDoS.
Par ailleurs, en cas d'inactivité d'un client DOTS ou lorsque celui-ci se déconnecte, un serveur DOTS peut procéder à la suppression de l'ensemble des filtres activés par ce client, ce qui peut nuire au bon acheminement du trafic vers le domaine client.
Il existe donc un besoin pour une nouvelle technique pour la gestion du trafic associé à un domaine client, permettant par exemple d'éviter le déclenchement automatique d'une procédure de mitigation lorsqu'une telle procédure n'est pas justifiée car qu'il n'y a pas d'attaque en cours.
3. Exposé de l'invention
L'invention propose une solution nouvelle pour la gestion du trafic associé à un domaine client, Le., entrant dans le domaine client ou sortant du domaine client, mis en œuvre dans un serveur, comprenant :
la détection d'un problème de communication entre le serveur et au moins un premier nœud client du domaine client, dit nœud défaillant, l'identification d'au moins un deuxième nœud client appartenant au domaine client, la vérification si une session est active entre le serveur et le ou les deuxième(s) nœud(s) client(s), et o si aucune session n'est active : le déclenchement d'une procédure de mitigation sur au moins une ressource IP associée au domaine client, o si au moins une session est active : l'utilisation du ou des deuxième(s) nœud(s) client(s) associé(s) à la ou aux session(s) active(s), dit nœud(s) actif(s), pour engager une action de gestion du trafic associé au domaine client.
Ainsi, la solution proposée repose sur l'utilisation d'au moins un deuxième nœud client du domaine client, en cas de défaillance du premier nœud client, pour déclencher une action de gestion du trafic entrant et/ou sortant du domaine client.
La solution proposée repose donc sur une coopération entre les différents nœuds clients appartenant à un même domaine client.
Par exemple, une telle action de gestion du trafic met en œuvre la confirmation qu'une attaque est en cours sur au moins une ressource IP associée au domaine client ou la redirection sur un deuxième nœud actif d'au moins une partie du trafic associée à au moins une ressource IP du domaine client.
Selon au moins un mode de réalisation, la solution proposée permet d'améliorer la fiabilité des réponses aux attaques DDoS et la coordination entre les nœuds clients d'un même domaine, notamment la coordination des actions de mitigation des attaques DDoS, en impliquant au moins un autre client du domaine pour vérifier la réalité d'une attaque.
La solution proposée selon ce mode de réalisation permet ainsi d'éviter l'augmentation du délai de transfert des paquets entrants lorsqu'ils sont acheminés vers un centre d'épuration du trafic (« scrubber ») de manière injustifiée.
En particulier, selon au moins un mode de réalisation, la solution proposée permet de forcer le chemin emprunté par le trafic pour solliciter un ou plusieurs autres nœuds clients pendant une période donnée. Par conséquent, si une attaque DDoS est effective, ce ou ces nœuds clients pourront signaler cette attaque au serveur. Si le serveur ne reçoit pas de message signalant une attaque et requérant la mise en œuvre d'une procédure de mitigation, le trafic peut être redirigé sur le chemin nominal.
Par ailleurs, selon au moins un mode de réalisation particulier, une telle coopération entre les clients DOTS d'un même domaine permet notamment de détecter et d'éliminer les entrées obsolètes (« stale ») des tables maintenues par le serveur, par exemple les règles de filtrage qui ne sont plus justifiées suite à l'expiration d'une session entre le client et le serveur. Ainsi, la solution proposée selon ce mode de réalisation particulier permet d'assurer une cohérence de la configuration de plusieurs clients appartenant au même domaine.
Notamment, la solution proposée permet à un nœud client du domaine client d'indiquer au serveur qu'il peut supprimer des entrées associées à des ressources IP gérées par un autre nœud client du domaine client.
On note également que le procédé de gestion proposé peut, selon au moins un mode de réalisation, s'appliquer au trafic sortant du domaine client. Par exemple, le serveur peut détecter une attaque dont l'origine est le domaine client. Il peut ainsi procéder à la notification du domaine client et éventuellement filtrer le trafic sortant.
D'autres modes de réalisation de l'invention concernent un serveur et un nœud client correspondants.
Dans un autre mode de réalisation, l'invention concerne un ou plusieurs programmes d'ordinateur comportant des instructions pour la mise en œuvre d'un procédé de gestion du trafic associé à un domaine client selon au moins un mode de réalisation de l'invention, lorsque ce ou ces programmes est/sont exécuté(s) par un processeur.
Dans encore un autre mode de réalisation, l'invention concerne un ou plusieurs supports d'informations, inamovibles, ou partiellement ou totalement amovibles, lisibles par un ordinateur, et comportant des instructions d'un ou plusieurs programmes d'ordinateur pour l'exécution des étapes du procédé de gestion du trafic associé à un domaine client selon au moins un mode de réalisation de l'invention.
Les procédés selon l'invention peuvent donc être mis en œuvre de diverses manières, notamment sous forme câblée et/ou sous forme logicielle.
4. Liste des figures
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
la figure 1 illustre un exemple de réseau de communication mettant en œuvre un procédé de gestion du trafic associé à un domaine client, selon un mode de réalisation de l'invention ;
la figure 2 présente les principales étapes du procédé de gestion du trafic associé à un domaine client, selon au moins un mode de réalisation de l'invention ;
les figures 3 et 4 illustrent deux exemples d'application de l'invention ;
la figure 5 présente les principales étapes mises en œuvre par un serveur DOTS selon un premier exemple d'application de l'invention ;
la figure 6 illustre la suppression, dans des tables maintenues par le serveur, des ressources IP qui ne sont plus associées à un domaine client ;
les figures 7A à 7D illustrent différentes variantes pour la mise en œuvre d'une deuxième phase de vérification, permettant de confirmer/infirmer si une attaque cible des ressources IP ;
la figure 8 présente les principales étapes mises en œuvre par un serveur DOTS selon un deuxième exemple d'application de l'invention ;
les figures 9 à 12 illustrent différents exemples de redirection de trafic selon le deuxième exemple d'application de l'invention ;
les figures 13 et 14 illustrent la détection de conflit entre plusieurs clients d'un même domaine ; et la figure 15 présente la structure simplifiée d'un serveur et d'un nœud client selon un mode de réalisation particulier.
5. Description d'un mode de réalisation de l'invention
5.1 Principe général
Le principe général de l'invention repose sur l'utilisation d'au moins un deuxième nœud client, appartenant à un domaine client, pour gérer le trafic entrant ou sortant du domaine client, en cas de problème de communication entre le serveur et un premier nœud client.
On présente, en relation avec la figure 1, différents équipements d'un réseau de communication mettant en œuvre un procédé de gestion du trafic entrant ou sortant d'un domaine client selon un mode de réalisation de l'invention.
On considère par exemple plusieurs nœuds clients Cl 111, C2 112, C3 113, Cm 114 appartenant à un domaine client 11, communiquant avec un serveur S 12. Par exemple, le domaine client 11 comprend une ou plusieurs machines, encore appelées nœuds. On entend ici par « domaine » un ensemble de machines ou nœuds placés sous la responsabilité d'une même entité.
Selon l'exemple illustré, le serveur 12 n'appartient pas au domaine client 11. Selon un autre exemple non illustré, le serveur 12 peut appartenir au domaine client 11.
La figure 2 illustre les principales étapes mises en œuvre pour la gestion du trafic associé au domaine client 11.
Le serveur 12 détecte (21) un problème de communication avec un premier nœud du domaine client, dit nœud défaillant. Par exemple, un problème de communication est détecté si une session entre le serveur 12 et le nœud défaillant est inactive pendant une durée supérieure ou égale à un seuil prédéterminé. En particulier, une session peut être considérée inactive si aucun message de présence (par exemple, de type « heartbeat »), destiné à vérifier qu'un pair distant est toujours actif, n'est reçu à l'issue d'une durée supérieure ou égale à un seuil prédéterminé noté Th.
Si un problème de communication est détecté entre le serveur 12 et, par exemple, le nœud Cl 111, le serveur identifie (22) au moins un deuxième nœud client appartenant au domaine client 11.
Le serveur vérifie (23) si au moins une session est active entre le serveur 12 et le ou les deuxième(s) nœud (s) client(s).
Si aucune session n'est active (231), une procédure de mitigation 24 est déclenchée sur au moins une ressource IP associée au domaine client. Selon un mode de réalisation particulier, si aucune session n'est active, le déclenchement d'une procédure de mitigation est mis en œuvre sur toutes les ressources IP associées au domaine client.
Si au moins une session est active (232), le deuxième nœud associé à la ou aux sessions actives, dit nœud actif, par exemple le nœud C2 112, est utilisé (25) pour engager une action de gestion du trafic du domaine client.
Selon un mode de réalisation particulier, si le nombre de sessions inactives est supérieur ou égal à un seuil prédéterminé, la procédure de mitigation 24 est déclenchée sur au moins une ressource IP associée au domaine client, et éventuellement sur toutes les ressources IP associées au domaine client. Par exemple, une telle procédure de mitigation est mise en œuvre si plus de la moitié des sessions établies entre le serveur et les nœuds clients de ce domaine sont inactives.
Les figures 3 et 4 illustrent deux exemples d'application de l'invention. Selon le premier exemple d'application, l'action de gestion du trafic met en œuvre la confirmation qu'une attaque est en cours sur au moins une ressource IP associée au domaine client. Le premier exemple d'application permet donc de vérifier qu'une attaque DDoS est effective avant de déclencher une procédure de mitigation. Selon le deuxième exemple d'application, l'action de gestion du trafic met en œuvre une redirection sur le nœud actif d'au moins une partie du trafic associé à au moins une ressource IP du domaine client.
La figure 3 illustre les principales étapes du procédé de gestion du trafic selon le premier exemple d'application.
Selon ce premier exemple d'application, l'action de gestion du trafic met en œuvre la confirmation qu'une attaque est en cours sur au moins une ressource IP associée au domaine client. En particulier, le trafic associé à une ressource IP peut être le trafic entrant à destination d'une adresse extraite de cette ressource IP ou le trafic sortant émis depuis cette ressource IP.
Pour ce faire, le serveur 12 transmet (31$) au nœud client actif 112, et éventuellement à tous les nœuds clients actifs du domaine client, au moins un message de demande de confirmation d'attaque portant sur au moins une ressource IP associée au domaine client. Par exemple, un tel message est noté Macr, ou « ATTACK_CONFIRMATION_REQUEST(Resources) ». On note que les ressources IP concernées peuvent être indiquées explicitement dans le message, ou non. Par exemple, un tel message spécifie au moins une ressource IP, par exemple une ressource IP associée au nœud client défaillant 111 ou au domaine client 11. L'absence de spécification d'une ressource IP dans un tel message peut être interprétée comme une requête de confirmation d'attaque portant sur l'ensemble des ressources IP associées au domaine client.
En particulier, une telle ressource IP appartient au groupe comprenant :
une adresse IP (par exemple un préfixe IPv4 ou IPv6), par exemple les adresses IP des différents nœuds du domaine client 11, un préfixe IP (par exemple un préfixe IPv4 ou IPv6), par exemple un préfixe IP associé à un routeur de raccordement du domaine client 11, un nom de domaine, par exemple un nom de domaine associé au domaine client 11, etc.
Le nœud client actif 112 reçoit (32ς2) donc au moins un message de demande de confirmation d'attaque portant sur au moins une ressource IP associée au nœud client défaillant 111, ou plus généralement au domaine client 11, en provenance du serveur 12.
Le nœud client actif 112 vérifie (33ς2) que la ou les ressources IP identifiées dans le ou les message(s) de demande de confirmation d'attaque qu'il reçoit sont effectivement associées au domaine client 11.
Si au moins une ressource IP identifiée dans le ou les message(s) de demande de confirmation d'attaque n'est pas associée au domaine client, le nœud client actif 112 transmet (341q2) au serveur 12 au moins un message d'erreur. Par exemple, un tel message d'erreur est noté Merr, ou « ERROR(Unknown_Resources) ». En particulier, un tel message d'erreur peut indiquer la ou les ressources IP qui n'appartiennent pas au domaine client 11.
Le serveur 12 reçoit (342$) donc au moins un message d'erreur en provenance d'un nœud actif, indiquant qu'une ou plusieurs ressources IP identifiées dans le message de demande de confirmation d'attaque n'appartiennent pas au domaine client.
Le serveur 12 peut alors supprimer (343$) la ou les ressources IP identifiées dans le ou les message(s) de demande de confirmation d'attaque ou dans le message d'erreur, d'au moins une table qu'il maintient.
Si au moins une ressource IP identifiée dans le ou les message(s) de demande de confirmation d'attaque est associée au domaine client, plusieurs variantes sont envisageables.
Selon une première variante, le nœud client actif 112 transmet (351c2) à au moins un nœud client du domaine client associé aux ressources IP identifiées dans le message de demande de confirmation d'attaque, au moins un premier message de vérification d'attaque. Par exemple, un tel premier message de vérification d'attaque est noté MvATTb ou « DOTS_PEER_PROBE(Request_Code) ». Un tel message est notamment envoyé au nœud client défaillant 111 pour lui demander de confirmer/infirmer l'attaque.
Le nœud client recevant (352ci) ce message MvatTL· Par exemple le nœud client défaillant 111, peut répondre au nœud actif, par exemple le nœud client actif 112, en transmettant (353ci) un premier message de statut indiquant si une attaque est en cours ou non. Par exemple, un tel premier message de statut est noté M st AT h ou « DOTS_PEER_PROBE(Reply_Code) ».
Le nœud client actif 112 recevant (354c2) ce premier message de statut peut alors transmettre (355c2) au serveur 12 au moins un premier message de réponse informant le serveur de la réponse au premier message de vérification d'attaque. Par exemple, un tel premier message de réponse est noté Mrepi, ou « ATTACK_CONFIRMATION_REPLY(Resources, Status) » et indique le statut (attaque en cours ou non), et la ou les ressources IP concernées.
Lorsque le serveur 12 reçoit ainsi (356$) au moins un premier message de réponse en provenance d'au moins un nœud actif, il peut déclencher (37$) une procédure de mitigation sur au moins une ressource IP associée au domaine client si au moins un premier message de réponse confirme une attaque.
Selon une deuxième variante, le nœud client actif 112 transmet (361c2), à au moins un nœud du domaine client mettant en œuvre une fonction de détection d'attaque, au moins un deuxième message de vérification d'attaque portant sur au moins une ressource IP associée au domaine client. Par exemple, un tel deuxième message de vérification d'attaque est noté Mvatt2, ou « RESOURCE_PROBE(Rk) ».
Le nœud N recevant (362^) ce message peut répondre au nœud actif, par exemple le nœud client actif 112, en transmettant (363^) un deuxième message de statut indiquant si une attaque est en cours ou non. Par exemple, un tel deuxième message de statut est noté Mstat2, ou « RESOURCE_PROBE(code) ».
Le nœud client actif 112 recevant (364c2) ce deuxième message de statut peut alors transmettre (365c2) au serveur 12 au moins un deuxième message de réponse informant le serveur de la réponse au deuxième message de vérification d'attaque. Par exemple, un tel deuxième message de réponse est noté Mrep2, ou « ATTACK_CONFIRMATION_REPLY(Resources,
Status) » et indique le statut (attaque en cours ou non), et la ou les ressources IP concernées.
Lorsque le serveur 12 reçoit ainsi (366$) au moins un deuxième message de réponse en provenance d'au moins un nœud actif, il peut déclencher (37$) une procédure de mitigation sur au moins une ressource IP associée au domaine client si au moins un deuxième message de réponse confirme une attaque.
Selon une troisième variante, les première et deuxième variantes sont mises en œuvre.
Le nœud client actif 112 transmet donc au moins un premier message de vérification d'attaque à au moins un nœud client du domaine client (par exemple, au(x) nœud(s) client(s) associé(s) aux ressources IP identifiées dans le message de demande de confirmation d'attaque) (351c2b et/ou au moins un deuxième message de vérification d'attaque à au moins un nœud du domaine client mettant en œuvre une fonction de détection d'attaque (361c2), en tenant compte d'au moins un critère de sélection.
Par exemple, le nœud client actif choisit à quel(s) nœud(s) (nœud(s) client(s) ou nœud(s) activant une fonction de détection d'attaque) il envoie des messages de vérification d'attaque. Le critère de sélection est par exemple le volume du trafic transitant par les nœuds voisins du nœud actif.
A nouveau, lorsque le serveur 12 reçoit au moins un message de réponse en provenance dudit au moins un nœud actif (premier et/ou deuxième message(s) de réponse), il peut déclencher (37$) une procédure de mitigation sur au moins une ressource IP associée au domaine client si au moins un message de réponse confirme une attaque.
Selon un mode de réalisation particulier, le serveur 12 déclenche (37$) une procédure de mitigation sur au moins une ressource IP associée au domaine client, si aucune réponse au message de demande de confirmation d'attaque n'est reçue pendant une durée prédéterminée.
On présente désormais, en relation avec la figure 4, les principales étapes du procédé de gestion du trafic selon le deuxième exemple d'application.
Selon ce deuxième exemple d'application, l'action de gestion du trafic est une redirection, sur le nœud actif, d'au moins une partie du trafic associé à une ressource IP du domaine client. En particulier, une telle ressource IP peut être gérée par le nœud défaillant.
Le serveur 12 peut mettre en œuvre, au préalable, une sélection (41) de la partie du trafic à rediriger. Par exemple, la sélection appartient au groupe comprenant :
une sélection aléatoire, une sélection du trafic provenant d'un nœud source utilisant un nombre de ressources réseau supérieur ou égal à un nombre prédéterminé, par exemple la majorité des ressources réseau ;
une sélection du trafic associé à une ressource IP du domaine client (i.e. du trafic entrant à destination d'une adresse extraite de cette ressource IP ou du trafic sortant émis depuis cette ressource IP) utilisant un nombre de ressources réseau supérieur ou égal à un nombre prédéterminé, par exemple la majorité des ressources réseau.
Comme déjà indiqué, le trafic à gérer peut être le trafic entrant à destination d'une adresse extraite d'une ressource IP ou le trafic sortant émis depuis cette ressource IP. On se place ci-après dans le contexte de la gestion du trafic entrant sur le domaine client.
Le serveur dirige ensuite la partie du trafic sélectionné vers le nœud actif, par exemple le nœud 112. Par exemple, la redirection est mise en œuvre pendant une durée prédéterminée.
Ainsi, sur détection d'un problème de communication entre le serveur et un nœud client, par exemple le nœud 111, le serveur 12 redirige une partie du trafic, acheminé initialement par un chemin passant par ce nœud client défaillant vers des chemins secondaires passant par un ou plusieurs nœuds clients du même domaine client présentant une session active avec le serveur.
Eventuellement, le ou les nœuds actifs peuvent déclencher une procédure de mitigation s'il(s) constate(nt) que le trafic sur ce nœud actif est du trafic illégitime, i.e., correspond à une attaque DDoS.
Selon un autre mode de réalisation, qui peut être combiné avec l'un des exemples d'application présenté ci-dessus, le procédé de gestion du trafic associé à un domaine client comprend la vérification du fait que tous les nœuds clients du domaine client ont préalablement accepté de mettre en œuvre les étapes décrites ci-dessus qui les concernent, et notamment les étapes de détection d'un problème de communication entre le serveur et un premier nœud client du domaine client, d'identification d'au moins un deuxième nœud client du domaine client, et de vérification qu'au moins une session associée à ce deuxième nœud client est active.
En particulier, la vérification du fait que tous les nœuds clients du domaine client ont préalablement accepté la mise en œuvre du procédé de gestion du trafic met en œuvre le contrôle de la valeur d'un paramètre de déclenchement de mitigation, noté par exemple « trigger-mitigation », associé à chaque nœud client du domaine client au cours d'une phase de négociation de configuration. Par exemple, la valeur du paramètre de déclenchement de mitigation « trigger-mitigation » doit être égale à « FAUX ».
Par ailleurs, selon un autre mode de réalisation, qui peut être combiné avec l'un des exemples d'application présentés ci-dessus, l'action de gestion du trafic peut être interrompue si le serveur reçoit un message en provenance du nœud défaillant. En effet, la réception d'un tel message en provenance du nœud défaillant signifie que la session entre le serveur et le nœud qui était défaillant est de nouveau active. Ce dernier peut éventuellement commander une action de mitigation en cas de besoin.
5.2 Exemples d'application dans le domaine des services de mitigation (DPS)
On décrit ci-après des exemples de mise en œuvre de l'invention dans une architecture de type DOTS, selon laquelle les nœuds clients Cl 111, C2 112, C3 113 et Cm 114 sont des clients DOTS et le serveur S 12 est un serveur DOTS. Les nœuds clients Cl 111, C2 112, C3 113, Cm 114 et le serveur S 12 peuvent ainsi communiquer via les canaux de signalisation et de données DOTS définis en relation avec l'art antérieur, pour informer le serveur que le domaine client subit une attaque DDoS et que des actions appropriées sont requises.
5.2.1 Rappels sur l'architecture DOTS
Une requête DOTS peut être, par exemple :
un message de gestion d'alias, par exemple destiné à associer un identifiant avec une ou plusieurs ressources réseau située(s) dans le domaine du client, un message de signalisation pour solliciter la mitigation d'une attaque de déni de service auprès d'un serveur DOTS, le serveur pouvant, sur réception d'un tel message, déclencher les actions nécessaires pour mettre fin à l'attaque, ou un message de gestion de règles de filtrage, tel que la sollicitation d'un serveur DOTS pour qu'il installe (ou fasse installer) une liste de contrôle d'accès (ACL pour « Access Control List »).
Une requête DOTS peut être envoyée d'un client DOTS, appartenant à un domaine client DOTS, à un serveur DOTS ou à une pluralité de serveurs DOTS.
Un domaine DOTS peut accueillir un ou plusieurs clients DOTS. En d'autres termes, plusieurs nœuds client d'un domaine client peuvent disposer de fonctions DOTS.
Les communications DOTS entre un domaine client et un serveur peuvent être directes, ou établies via des passerelles DOTS (en anglais « DOTS gateways »). Ces passerelles peuvent être hébergées au sein du domaine client, du domaine du serveur, ou des deux. En d'autres termes, un nœud du domaine client peut communiquer directement avec le serveur, ou transmettre une requête à une passerelle du domaine client qui communique directement avec le serveur ou avec une passerelle du domaine serveur, ou transmettre une requête à une passerelle du domaine serveur qui communique avec le serveur.
Une passerelle DOTS localisée dans un domaine client est considérée par un serveur DOTS comme un client DOTS.
Une passerelle DOTS localisée dans un domaine serveur est considérée par un client DOTS comme un serveur DOTS. En cas de présence d'une passerelle DOTS dans un domaine serveur, l'authentification des clients DOTS peut être confiée à la passerelle DOTS du domaine serveur. Un serveur DOTS peut être configuré avec la liste des passerelles DOTS actives au sein de son domaine et le serveur peut déléguer certaines de ses fonctions à ces passerelles de confiance. En particulier, le serveur peut utiliser en toute sécurité les informations fournies par une passerelle figurant dans une liste déclarée auprès du serveur et maintenue par celui-ci, moyennant une procédure d'authentification ad hoc (par exemple, configuration explicite de la liste par l'administrateur habilité du serveur, récupération de la liste auprès d'un serveur d'authentification tel qu'un serveur AAA (pour « Authentication, Authorization and Accounting »), etc.).
Les modes de réalisation présentés ci-après peuvent être mis en œuvre quelle que soit la configuration de l'architecture DOTS (un ou plusieurs clients DOTS dans un domaine client, pas de passerelle DOTS, une ou plusieurs passerelles DOTS dans le domaine client ou dans le domaine serveur, domaine client distinct du domaine serveur, etc.).
L'établissement d'une session DOTS sécurisée peut se dérouler conformément à la procédure décrite dans le document « Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification » précité. Par exemple, les sessions peuvent être établies en utilisant une procédure décrite dans l'un des documents suivants :
« Datagram Transport Layer Security Version 1.2 », Rescorla E. et al., RFC 6347, DOI 10.17487/RFC6347, janvier 2012, « The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 », Rescorla E. et al., draft-ietf-tls-dtlsl3-22, novembre 2017, « The Transport Layer Security (TLS) Protocol Version 1.2 », Dierks T. et al., RFC 5246, DOI 10.17487/RFC5246, août 2008, « The Transport Layer Security (TLS) Protocol Version 1.3 », Rescorla E., draft-ietf-tlstlsl3-23, janvier 2018.
Dans la suite, on suppose que les agents DOTS (client(s), serveur(s)) s'authentifient mutuellement. Il existe donc un canal de communication sécurisé, par exemple de type (D)TLS, entre un client DOTS et un serveur DOTS.
Ainsi, les messages reçus d'un autre serveur usurpant l'identité du serveur légitime peuvent être rejetés par un client DOTS. De la même manière, les demandes des clients DOTS non-autorisés à accéder au service de mitigation peuvent être ignorées par le serveur DOTS. On suppose dans la suite que cette procédure est mise en place par les agents DOTS.
Les détails des échanges (D)TLS, et ceux concernant la gestion des clés de sécurité pour l'authentification mutuelle des agents DOTS, ne font pas l'objet de la présente invention et ne sont pas détaillés ici.
On présente ci-après les différentes étapes mises en œuvre par un client DOTS et un serveur DOTS, en référence aux figures 1 à 4. On considère à titre d'exemple que les nœuds clients 111 à 114 de la figure 1 sont des clients DOTS et que le serveur 12 de la figure 1 est un serveur DOTS. Le domaine client est donc un domaine DOTS.
5.2.2 Premier exemple d'application : Procédure de mitigation automatigue coopérative sur détection de perte du signal
On présente ci-après plus en détail un premier exemple d'application de l'invention, selon lequel l'action de gestion du trafic met en œuvre la confirmation qu'une attaque est en cours sur au moins une ressource IP associée au domaine client.
Ce premier exemple d'application permet donc de vérifier qu'une attaque DDoS est effective avant de déclencher une procédure de mitigation, et offre donc une solution permettant d'éviter le déclenchement inutile d'opérations de mitigation.
Comme décrit ci-après, la détection d'une attaque DDoS au sein d'un domaine client peut être effectuée par un client DOTS lui-même et/ou par une fonction dédiée, appelée détecteur DDoS (« DDoS Detector » en anglais). Un ou plusieurs détecteurs DDoS peuvent être activés par domaine DOTS.
Comme illustré en figure 5, au cours d'une étape de « monitoring » 51, le serveur DOTS surveille l'état des connexions avec les clients DOTS, ou plus généralement surveille les sessions DOTS, Le., les connexions de canaux de signalisation établies entre le serveur DOTS et les clients DOTS.
Si un problème de communication avec un premier client DOTS est détecté au cours d'une étape 52, par exemple une perte de signal prolongé, le serveur DOTS ne déclenche pas automatiquement la procédure de mitigation mais déclenche une procédure permettant de confirmer qu'une attaque DDoS est effectivement en cours. Par exemple, un problème de communication est détecté suite à la non réception par le serveur, pendant une période Th prédéterminée, de messages de présence en provenance du premier client DOTS, par exemple des messages de type « heartbeat ».
Dans ce cas, l'état 521 associé à ce client DOTS défaillant, dans les tables à états du serveur, peut être « ATTAQUE_A_VALIDER » (en anglais « ATTACK_TO_BE_VALIDATED »).
Le serveur obtient, au cours d'une étape 53, une liste d'au moins une ressource IP associée au client DOTS défaillant, ou plus généralement au domaine client.
Comme déjà indiqué, les ressources IP peuvent être des adresses IP, des préfixes IP ou des noms de domaine. Les noms de domaine peuvent être résolus en des adresses IP. Les préfixes IP dénotent ci-après les préfixes IP directement communiqués par un client DOTS ou les adresses récupérées via un système de résolution de nom (par ex. DNS). Les préfixes peuvent être de la même famille d'adresses ou appartenir à des familles distinctes (IPv4, IPv6).
L'état « ATTAQUE_A_VALIDER » indique ainsi que les ressources IP associées au client DOTS défaillant, ou plus généralement au domaine client, subissent peut-être une attaque DDoS.
Le serveur obtient également, au cours d'une étape 54, une liste d'au moins un deuxième client DOTS appartenant au même domaine que le client DOTS défaillant, et vérifie si ce ou ces deuxième(s) client(s) DOTS sont actifs, Le., si une session DOTS est active entre le serveur et au moins un de ces deuxièmes clients DOTS. Le serveur peut également procéder à l'identification des ressources IP associées aux clients DOTS actifs.
Si toutes les sessions sont inactives (541), c'est-à-dire si aucun message de présence, par exemple de type « heartbeat », n'est reçu pendant une période Th pour tous les clients DOTS identifiés du domaine, le serveur DOTS peut lancer les opérations de mitigation 55 pour toutes les ressources IP associées à ce domaine. L'état du client défaillant tel que maintenu par le serveur peut alors être passé à « MITIGATION_EN_COURS » (en anglais « MITIGATION_IN_PROGRESS »).
En variante, le serveur peut décider qu'une attaque est en cours si la plupart des sessions avec les clients DOTS du domaine client sont inactives. Un seuil de déclenchement est utilisé à cet effet par le serveur. Par exemple, ce seuil peut être à 50% ou 75% des sessions DOTS établies avec les clients de ce domaine. Ainsi, si plus de la moitié des sessions entre le serveur et les clients DOTS du domaine sont inactives, le serveur peut décider de déclencher la procédure de mitigation. Bien entendu, d'autres valeurs peuvent être utilisées par le serveur.
Si au moins une session DOTS est active (542) entre le serveur et un client DOTS, le serveur peut envoyer, au cours d'une étape 56, un message non-sollicité de demande de confirmation d'attaque (Macr ou « ATTACK_CONFIRMATION_REQUEST(Resources) ») à au moins un client DOTS actif du domaine.
Un tel message comporte au moins une ressource IP associée au client DOTS défaillant, ou au domaine client auquel appartient le client DOTS défaillant. Par exemple, la valeur spéciale « ANY » peut être utilisée pour indiquer qu'il s'agit de n'importe quelle ressource IP associée au domaine client.
A l'envoi de ce message, l'état du client DOTS défaillant, tel que maintenu par le serveur, passe par exemple à « EN_ATTENTE_DE_CONFIRMATION » (en anglais « WAITING_FOR_CONFIRMATION »).
Lorsqu'un client DOTS actif du domaine client reçoit une telle requête de confirmation d'attaque en provenance du serveur, le client DOTS actif met en œuvre une première phase de vérification au cours de laquelle il peut procéder aux vérifications de sécurité pour s'assurer de l'identité du serveur et il peut valider que les ressources IP associées au message de demande de confirmation d'attaque sont effectivement associées au domaine client.
La requête peut être ignorée par le client actif en cas d'échec des vérifications de sécurité, et le client actif peut ne pas envoyer de réponse au serveur à l'origine de la requête.
Si aucune réponse au message de demande de confirmation d'attaque n'est reçue par le serveur après un temps prédéterminé Te (57), l'état du client défaillant peut être passé à « TEMPS_DE_VALIDATION_ECOULE » (en anglais « VALIDATION_TIMEOUT ») dans la ou les tables à états maintenues par le serveur.
Le serveur DOTS peut alors procéder au lancement des opérations de mitigation 55 pour toutes les ressources IP associées à ce domaine client, et l'état du client défaillant tel que maintenu par le serveur peut être passé à « MITIGATION_EN_COURS » (en anglais « MITIGATION_IN_PROGRESS »).
Par ailleurs, si au moins une ressource IP indiquée dans le message de demande de confirmation d'attaque n'est pas associée au domaine client, le client actif peut envoyer un message d'erreur (Merr ou « ERROR(Unknown_Resources) ») au serveur pour l'informer. Un tel message liste notamment les ressources IP présentes dans le message de demande de confirmation d'attaque qui ne sont pas associées au domaine client.
Quand le message d'erreur est reçu par le serveur, ce dernier extrait les ressources IP renseignées dans le message d'erreur et procède à la suppression des états actifs associés à ces ressources.
Par exemple, comme illustré en figure 6, la session entre le client Cl 111 et le serveur S 12 est inactive. En revanche, la session entre le client C2 112 et le serveur S 12 est active. Le serveur peut donc envoyer un message de demande de confirmation d'attaque au client C2 112, comportant les adresses IP 1.2.3.4 et 11.2.3.4. Le client C2 112 vérifie que ces adresses appartiennent bien au domaine client 11, et envoie (341c2) un message d'erreur au serveur 12 pour l'informer que l'adresse IP 11.2.3.4 n'est pas associée au domaine client. Le serveur 12 peut alors supprimer les règles de filtrage associées à l'adresse IP 11.2.3.4, ou plus généralement les règles de filtrage associées à des ressources n'appartenant pas au domaine client. Cette procédure permet d'éliminer les entrées obsolètes (« stale »).
A l'issue de cette première phase de vérification, le client actif 112 peut procéder à une deuxième phase de vérification pour confirmer/infirmer si une attaque cible la/les ressource(s) indiquée(s) dans le message de demande de confirmation d'attaque.
En d'autres termes, en plus de la première phase de vérification locale permettant de vérifier si les ressources IP indiquées dans le message de demande de confirmation d'attaque sont associées au domaine client, et notamment gérées par le client actif, d'autres modalités de vérification, qui ne sont pas mutuellement exclusives, peuvent être adoptées par le client actif pour conclure si une attaque est en cours ou pas.
A l'issue de cette deuxième phase de vérification, détaillée ci-après en relation avec les figures 7A à 7D, le client actif 112 peut indiquer (58) au serveur si une attaque est en cours ou non sur une ou plusieurs ressources IP. Par exemple, le client actif 112 envoie au serveur un message de réponse (ATTACK_CONFIRMATION_REPLY (Resources, Status)) comportant deux paramètres : le paramètre « Resources», qui indique la ou les ressources IP concernées, et le paramètre « Status», qui est positionné par exemple à « 1 » si une attaque est en cours ou à « 0 » sinon.
Si le paramètre « Status» est valorisé à « 1 » (581), cela signifie qu'une attaque est en cours sur au moins une ressource IP associée au message de demande de confirmation d'attaque, et le serveur procède au lancement des opérations de mitigation 55 pour les ressources IP concernées, ou à défaut pour l'ensemble des ressources IP associées au domaine client.
L'état du client défaillant tel que maintenu par le serveur peut être passé à « ATTAQUE_VALIDEE » (en anglais « ATTACK_VALIDATED »), puis « MITIGATION_EN_COURS » (« MITIGATION_IN_PROGRESS »).
Si le serveur reçoit plusieurs messages de réponse provenant de différents clients du domaine, le serveur détermine par exemple qu'une attaque est en cours si au moins un de ces clients envoie un message de réponse portant le paramètre « Status» valorisé à « 1 ».
Si le paramètre « Status» est valorisé à « 0 » (582) dans toutes les réponses reçues, cela signifie qu'aucune attaque n'est en cours, et qu'il n'est pas nécessaire que le serveur active une procédure de mitigation.
L'état du client défaillant tel que maintenu par le serveur peut être passé à « ATTAQUEJNVALIDEE » (en anglais « ATTACK J N VALIDATED »), puis «EN VEILLE» (en anglais « IDLE ».
On note par ailleurs que si le serveur DOTS reçoit un message du client défaillant, la procédure de vérification (selon la première ou la deuxième phase) est interrompue. L'état de ce client peut alors être passé à « EN VEILLE » (« IDLE »).
On présente ci-après trois variantes pour la mise en œuvre de la deuxième phase de vérification, permettant de confirmer/infirmer si une attaque cible la/les ressource(s) indiquée(s) dans le message de demande de confirmation d'attaque, et identifiée(s) comme appartenant au domaine client.
On suppose ici, à titre d'exemple, que les clients du domaine sont configurés au préalable avec la liste des autres clients du domaine, ainsi que la liste des ressources IP associées à chaque client.
Selon une première variante, illustrée en figure 7A, le client DOTS actif 112 contacte directement le client DOTS responsable de la gestion des ressources indiquées par le serveur, par exemple le client défaillant 111 si le message de demande de confirmation d'attaque comporte au moins une ressource IP associée au client DOTS défaillant, ou une entité DOTS responsable de la gestion du domaine client si le message de demande de confirmation d'attaque porte la valeur spéciale « ANY » (utilisée pour indiquer qu'il s'agit de n'importe quelle ressource IP associée au domaine client).
Par exemple, le client actif 112 envoie (351c2) au moins un premier message de vérification d'attaque (Mvatti ou « DOTS_PEER_PROBE(Request_Code) ») à au moins un nœud client du domaine client associé aux ressources IP identifiées dans le message de demande de confirmation d'attaque, par exemple le client défaillant 111.
Ce premier message de vérification d'attaque est par exemple transmis du client actif 112 au client défaillant 111 pour lui demander de confirmer/infirmer l'attaque.
Le champ « Request_Code » du premier message de vérification peut être utilisé pour indiquer la nature de la requête, par exemple :
« 0 » : message de détection de vie du client défaillant 111, Le., est-ce que ce client 111 est toujours actif dans le domaine ;
« 1 » : demande si le client défaillant 111 est au courant d'une attaque pour une ressource donnée ; dans ce cas, le premier message de vérification peut comporter une liste de ressources pour lesquelles il faut vérifier si une attaque est en cours.
Le client défaillant 111 peut éventuellement répondre (353ci) à ce premier message de vérification d'attaque avec un premier message de statut (Mstati ou « DOTS_PEER_PROBE(Reply_Code) ») indiquant si une attaque est en cours ou non.
Le champ « Reply_Code » du premier message de statut peut être utilisé pour indiquer la nature de la réponse, par exemple :
« 0 » : aucune attaque n'est en cours ;
« 1 » : confirmation de l'attaque.
Le client actif 112 peut ensuite envoyer au serveur un premier message de réponse (Mrepi ou « ATTACK_CONFIRMATION_REPLY(Resources, Status)») indiquant le statut (le paramètre « Status » est positionné à « 1 » si une attaque est en cours ou à « 0 » sinon) et la ou les ressources IP concernées par l'attaque en cours.
Selon une deuxième variante, illustrée en figure 7B, le client DOTS actif 112 contacte une fonction de détection d'attaque DDoS utilisée au sein du domaine client. Une telle fonction est par exemple mise en œuvre dans au moins un nœud N du domaine client 11, encore appelé détecteur DDoS.
Par exemple, le client actif 112 envoie (361c2) au moins un deuxième message de vérification d'attaque (Mvatt2 ou « RESOURCE_PROBE(Rk) ») au détecteur DDoS 115 pour demander de confirmer/infirmer une attaque ciblant au moins une ressource.
Le champ « Rk » du deuxième message de vérification d'attaque peut être utilisé pour préciser la liste des ressources concernées :
« ANY » ou champ vide : s'il faut vérifier si une attaque est en cours sur toutes les ressources IP du domaine client ; ou une liste explicite des ressources IP pour lesquelles il faut vérifier si une attaque est en cours.
La fonction de détection d'attaque DDoS, ou le nœud N 115 activant cette fonction, peut éventuellement répondre (363^) à ce deuxième message de vérification d'attaque avec un deuxième message de statut (Mstat2 ou (( RESOURCE_PROBE(Code) ») indiquant si une attaque est en cours ou non.
Le champ « Code » du deuxième message de statut peut être utilisé pour indiquer la nature de la réponse, par exemple :
« 0 » : aucune attaque n'est en cours ;
« 1 » : confirmation de l'attaque.
Le client actif 112 peut ensuite répondre au serveur avec un deuxième message de réponse (Mrep2 ou « ATTACK_CONFIRMATION_REPLY(Resources, Status) ») indiquant le statut (le paramètre « Status » est positionné à « 1 » si une attaque est en cours ou à « 0 » sinon) et la ou les ressources IP concernées.
Selon une troisième variante, illustrée en figure 7C, combinant les première et deuxième variantes, le client DOTS actif 112 peut contacter une fonction de détection d'attaque DDoS utilisée au sein du domaine client et/ou un ou plusieurs clients DOTS, actifs ou non, et non nécessairement responsable de la gestion des ressources indiquées par le serveur dans le message de demande de confirmation d'attaque.
Les messages échangés entre le client DOTS actif 112 et un ou plusieurs clients DOTS sont similaires à ceux décrits en relation avec la première variante et ne sont pas décrits plus en détail. Les messages échangés entre le client DOTS actif 112 et la fonction de détection d'attaque DDoS sont similaires à ceux décrits en relation avec la deuxième variante et ne sont pas décrits plus en détail.
Eventuellement, le client actif 112 peut répartir les demandes de vérification d'attaque entre les clients et le détecteur DDoS selon des considérations d'activité des clients voisins, par exemple.
Le client actif 112 peut ensuite envoyer au serveur un message de réponse indiquant le statut (le paramètre « Status » est positionné à « 1 » si une attaque est en cours ou à « 0 » sinon) et la ou les ressources IP concernées. Selon cette troisième variante, le client actif 112 décide qu'une attaque est en cours s'il reçoit au moins une réponse confirmant l'attaque, et informe le serveur en conséquence.
Eventuellement, le client actif 112 peut envoyer plusieurs messages de réponse au serveur. Dans ce cas, le serveur décide qu'une attaque est en cours s'il reçoit au moins une réponse confirmant l'attaque.
La figure 7D illustre trois exemples de messages échangés entre le client DOTS actif 112, le détecteur DDoS 115, et le client Cm 114.
Selon le premier exemple 71, le premier message de statut indique qu'aucune attaque n'est en cours (DOTS_PEER_PROBE(Reply_Code=0) et le deuxième message de statut indique qu'une attaque est en cours (RESOURCE_PROBE(Code=l)). Dans ce cas, le client DOTS actif 112 conclut qu'une attaque est en cours.
Selon le deuxième exemple 72, le premier message de statut indique qu'une attaque est en cours (DOTS_PEER_PROBE(Reply_Code=l) et le deuxième message de statut indique qu'aucune attaque n'est en cours (RESOURCE_PROBE(Code=0)). Dans ce cas, le client DOTS actif 112 conclut qu'une attaque est en cours.
Selon le troisième exemple 73, le premier message de statut indique qu'aucune attaque n'est en cours (DOTS_PEER_PROBE(Reply_Code=0) et le deuxième message de statut indique également qu'aucune attaque n'est en cours (RESOURCE_PROBE(Code=0)). Dans ce cas, le client DOTS actif 112 conclut qu'aucune attaque ne cible la ressource indiquée dans la requête.
On note que les différents messages échangés entre le serveur DOTS et les clients DOTS peuvent utiliser les canaux de signalisation et de données DOTS présentés en relation avec l'art antérieur.
5.2.3 Deuxième exemple d'application : solliciter d'autres clients DOTS du domaine
On présente ci-après plus en détail un deuxième exemple d'application de l'invention, selon lequel l'action de gestion du trafic met en œuvre une redirection sur le nœud actif d'au moins une partie du trafic associé au domaine.
La figure 8 illustre les principales étapes mises en œuvre pour rediriger une partie du trafic sur un client actif.
Les étapes de monitoring 51 des clients DOTS appartenant à un domaine client, de détection d'un problème de communication avec un premier client DOTS 52, d'obtention d'au moins une ressource IP associée à ce client défaillant 53, d'obtention d'au moins un deuxième client appartenant à ce domaine client 54, et de mitigation 55 sont similaires à celles présentées en relation avec la figure 5 et ne sont pas décrites plus en détail.
En particulier, si des clients DOTS appartenant au même domaine ont été identifiés par le serveur, celui-ci vérifie que des sessions DOTS sont actives avec au moins un de ces clients.
Si toutes les sessions DOTS sont inactives (541), par exemple aucun message de présence de type « heartbeat » n'est reçu pendant une période Th pour tous les clients du domaine, le serveur DOTS lance les opérations de mitigation 55 pour toutes les ressources associées à ce domaine.
Si au moins une session DOTS avec un client du domaine client est active (542), le serveur peut, suite à la détection d'un problème de communication avec un client DOTS (perte du signal par exemple) rediriger (86) une partie du trafic, acheminé initialement par le chemin impliquant le client DOTS défaillant, vers des chemins secondaires impliquant un ou plusieurs clients DOTS du même domaine dont la session DOTS est active.
Selon un mode de réalisation particulier, la sélection du trafic à rediriger peut reposer sur un ou plusieurs critères de sélection, appartenant au groupe comprenant :
sélection aléatoire, sélection du trafic provenant d'une source donnée consommant la majorité des ressources réseau (Ll), sélection du trafic à destination d'une machine donnée consommant la majorité des ressources réseau (Ll), etc.
Si une partie du trafic est effectivement associé à une attaque DDoS, un ou plusieurs des clients DOTS sollicités lors de la redirection du trafic peut ou peuvent envoyer un signal au serveur pour lui demander de lancer les opérations de mitigation.
Par exemple, la redirection peut être programmée pour une durée prédéterminée REDIRECT_Tmax. Ainsi, le serveur DOTS surveille (87) la session inactive avec le client DOTS défaillant pendant une durée prédéterminée REDIRECT_Tmax.
Si, à l'issue de cette durée prédéterminée REDIRECT_Tmax, le serveur reçoit une demande de mitigation ou si la ou les sessions précédemment actives ne sont plus actives (871), le serveur DOTS peut lancer les opérations de mitigation 55 pour toutes les ressources associées à ce domaine client.
Si, à l'issue de cette durée prédéterminée REDIRECT_Tmax, le serveur ne reçoit aucune demande de mitigation (872), et si au moins une session avec un autre client DOTS est toujours active, cela signifie a priori que le problème de communication avec le client défaillant n'est pas dû à une attaque DDoS, et l'état associé au client DOTS défaillant peut être placé à « EN_VEILLE » (« IDLE ») dans la ou les tables à états maintenues par le serveur.
Le serveur peut par ailleurs décider de rediriger une autre portion du trafic et de réitérer la même procédure pour une autre durée REDIRECT_Tmax.
Selon l'exemple illustré en figure 9, un problème de communication est détecté entre le serveur 12 et le client Cl 111. Une partie du trafic entrant 91 est redirigée, grâce à un routeur R 92 par exemple, vers le client C2 112 actif pendant une durée REDIRECT_Tmax égale à Tl. A l'issue de cette durée, une autre partie du trafic entrant 91 peut être redirigée vers le client Cm 114 actif pendant une durée REDIRECT_Tmax égale à T2.
Selon l'exemple illustré en figure 10, un problème de communication est détecté entre le serveur 12 et le client Cl 111. Une partie du trafic entrant est redirigée (100) vers un autre client actif. Une fois le trafic redirigé vers d'autres chemins, le serveur déclenche le «timer» REDIRECT_Tmax. Le client C2 112 peut intercepter le trafic redirigé (101), en particulier si le trafic redirigé transite par le client C2 112, et détecter une attaque DDoS dans le trafic entrant avant l'expiration de la durée prédéterminée REDIRECT_Tmax. Le client C2 112 peut alors demander au serveur DOTS d'engager une procédure de mitigation (par exemple en utilisant le message PUT(mid=5986)). Le serveur peut alors déclencher les opérations de mitigation DDoS (102) et informer le client C2 112 actif (2.01 (Created)).
Selon l'exemple illustré en figure 11, un problème de communication est détecté entre le serveur 12 et le client Cl 111. Une partie du trafic entrant est redirigée (100) vers un autre client actif. Une fois le trafic redirigé vers d'autres chemins, le serveur déclenche le «timer» REDIRECT_Tmax. Le client C2 112 peut intercepter le trafic redirigé (101), en particulier si le trafic redirigé transite par le client C2 112. Si aucune demande de mitigation n'est reçue par le serveur de la part du client C2 112, et que la session DOTS est toujours active avec ce client C2 112, le serveur conclut qu'aucune attaque n'est en cours. Le serveur peut alors décider de l'arrêt de la redirection du trafic (103).
Selon les exemples illustrés en figures 10 et 11, on suppose que, par construction du service DOTS, les clients DOTS sont activés sur des routeurs d'interconnexion. Il ne s'agit toutefois que d'un exemple de mise en œuvre.
La technique proposée peut également être mise en œuvre quand les clients sont activés dans d'autres nœuds. Les clients DOTS ne sont donc pas nécessairement situés sur le chemin emprunté par le trafic entrant et/ou sortant. Dans ce cas, comme illustré en figure 12, des détecteurs DDoS (DI 104, D2 105, ..., Dm 106) peuvent être activés pour surveiller le trafic écoulé via les différents liens d'interconnexion du domaine client. La détection d'attaques peut alors être mise en œuvre par l'un de ces détecteurs, qui peut communiquer l'information au client DOTS associé.
Le serveur S 12 peut notamment communiquer avec les détecteurs DDoS via les canaux de signalisation et de données DOTS définis en relation avec l'art antérieur.
5.2.4 Détection de conflit entre plusieurs clients du même domaine
Par ailleurs, selon au moins un mode de réalisation, le procédé de gestion du trafic associé à un domaine client comprend la vérification d'un paramètre commun aux nœuds client, permettant notamment d'assurer la cohérence de la configuration des différents clients d'un même domaine quant à l'activation de la mitigation automatique sur perte du signal DOTS.
Ainsi, selon ce mode de réalisation, un serveur peut n'activer la procédure décrite précédemment que si tous les clients d'un même domaine ont négocié la même valeur pour le paramètre de déclenchement de mitigation « trigger-mitigation » au cours de la négociation de configuration des sessions DOTS. Le serveur doit donc vérifier la valeur de ce paramètre de déclenchement de mitigation.
A titre d'exemple, on suppose que le client Cl 111 a indiqué la valeur « FAUX » pour le paramètre de déclenchement de mitigation dans sa demande de négociation de configuration (« trigger-mitigation : false »). On suppose que le client C2 112 a indiqué la valeur « VRAI » pour le paramètre de déclenchement de mitigation dans sa demande de négociation de configuration (« trigger-mitigation: true »). Le serveur DOTS détecte un conflit entre ces deux demandes, et peut procéder à la désactivation de la mitigation automatique sur perte de signal pour tous les clients de ce domaine.
La figure 13 illustre le cas où le deuxième client C2 a établi une session DOTS (131) avec le serveur 12 au cours de laquelle il a indiqué que le paramètre de déclenchement de mitigation est valorisé à « VRAI » (« trigger-mitigation: true »). Si le premier client Cl cherche par la suite à établir une session DOTS (132) avec le serveur 12 en indiquant que le paramètre de déclenchement de mitigation est valorisé à FAUX (« trigger-mitigation: false »), la nouvelle requête est en conflit avec celle déjà maintenue par le serveur.
En particulier, si la requête maintenue par le serveur indique que la procédure de mitigation automatique sur perte de signal est désactivée (« trigger-mitigation: true »), alors le serveur DOTS peut rejeter la demande du premier client Cl, par exemple avec un message 4.09 de type « conflit » 133 (en anglais « Conflict »). En particulier, le message d'erreur peut indiquer la nature du conflit (« conflict-trigger-mitigation »).
Le client Cl peut alors envoyer une nouvelle requête de négociation avec le paramètre de déclenchement de mitigation valorisé à « VRAI » (« trigger-mitigation: true »).
La figure 14 illustre le cas où le premier client Cl a établi une session DOTS (141) avec le serveur 12 au cours de laquelle il a indiqué que le paramètre de déclenchement de mitigation est valorisé à FAUX (« trigger-mitigation: false »). Si le deuxième client C2 cherche par la suite à établir une session DOTS (142) avec le serveur 12 en indiquant que le paramètre de déclenchement de mitigation est valorisé à « VRAI » (« trigger-mitigation: true »), la nouvelle requête est en conflit avec celle déjà maintenue par le serveur.
En particulier, si la requête maintenue par le serveur indique que la procédure de mitigation automatique sur perte de signal est activée (« trigger-mitigation: false »), alors le serveur DOTS peut mettre fin à la session TLS ou DTLS avec le client Cl ayant négocié le paramètre « trigger-mitigation: false». Pour ce faire, le serveur DOTS envoie par exemple un message de type « alerte fatale » 143 (« Fatal Alert ») au client Cl, tel que décrit par exemple dans le document RFC5246 précité.
Le client Cl peut alors procéder à la réinitialisation 144 de la session avec le serveur et à la négociation 145 d'une nouvelle valeur du paramètre de déclenchement de mitigation valorisé à « VRAI » (« trigger-mitigation: true »).
5.3 Structures
On présente finalement, en relation avec la figure 15, les structures simplifiées d'un serveur et d'un nœud client selon l'un des modes de réalisation décrits ci-dessus.
Selon un mode de réalisation particulier, un serveur comprend une mémoire 151$ comprenant une mémoire tampon, une unité de traitement 152$, équipée par exemple d'une machine de calcul programmable ou d'une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d'ordinateur 153$, mettant en œuvre des étapes du procédé de gestion du trafic associé à un domaine client selon un mode de réalisation de l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur 153$ sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 152sLe processeur de l'unité de traitement 152$ met en œuvre des étapes du procédé de gestion du trafic associé à un domaine client décrit précédemment, selon les instructions du programme d'ordinateur 153$, pour :
détecter un problème de communication entre le serveur et au moins un premier nœud client du domaine client, dit nœud défaillant, identifier au moins un deuxième nœud client appartenant au domaine client, vérifier si une session est active entre le serveur et le ou les deuxième(s) nœud(s) client(s), o si aucune session n'est active : déclencher une procédure de mitigation sur au moins une ressource IP associée au domaine client, o si au moins une session est active : utiliser le deuxième nœud client associé à ladite au moins une session active, dit nœud actif, pour engager une action de gestion du trafic associé au domaine client.
Selon un mode de réalisation particulier, un nœud client comprend une mémoire 151c comprenant une mémoire tampon, une unité de traitement 152c, équipée par exemple d'une machine de calcul programmable ou d'une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d'ordinateur 153c, mettant en œuvre des étapes du procédé de gestion du trafic associé à un domaine client selon un mode de réalisation de l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur 153c sont Par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 152cLe processeur de l'unité de traitement 152c rnet en œuvre des étapes du procédé de gestion du trafic associé à un domaine client décrit précédemment, selon les instructions du programme d'ordinateur 153c, pour recevoir au moins un message de demande de confirmation d'attaque portant sur au moins une ressource IP associée au domaine client, en provenance du serveur.

Claims (15)

  1. REVENDICATIONS
    1. Procédé de gestion du trafic associé à un domaine client, mis en œuvre dans un serveur, ledit procédé comprenant :
    la détection (21) d'un problème de communication entre ledit serveur et au moins un premier nœud client dudit domaine client, dit nœud défaillant, l'identification (22) d'au moins un deuxième nœud client appartenant audit domaine client, la vérification (23) si une session est active entre ledit serveur et ledit au moins un deuxième nœud client, et o si aucune session n'est active : le déclenchement d'une procédure de mitigation sur au moins une ressource IP associée audit domaine client, o si au moins une session est active : l'utilisation du deuxième nœud client associé à ladite au moins une session active, dit nœud actif, pour engager une action de gestion du trafic associé audit domaine client.
  2. 2. Procédé selon la revendication 1, caractérisé en ce que ladite action de gestion du trafic met en œuvre la confirmation qu'une attaque est en cours sur au moins une ressource IP associée audit domaine client, ladite confirmation comprenant la transmission (31$), audit au moins un nœud actif, d'au moins un message de demande de confirmation d'attaque portant sur au moins une ressource IP associée au domaine client.
  3. 3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend la réception (342$) d'au moins un message d'erreur en provenance dudit nœud actif, indiquant qu'une ou plusieurs ressources IP identifiées dans ledit au moins un message de demande de confirmation d'attaque n'appartiennent pas audit domaine client, et la suppression (343$) de ces ressources IP d'au moins une table maintenue par ledit serveur.
  4. 4. Procédé selon la revendication 2, caractérisé en ce qu'il comprend le déclenchement d'une procédure de mitigation (37$) sur au moins une ressource IP associée audit domaine client si aucune réponse au message de demande de confirmation d'attaque n'est reçue pendant une durée prédéterminée ou si au moins un message de réponse reçu (356$, 366$), en provenance dudit au moins un nœud actif, confirme une attaque.
  5. 5. Procédé selon la revendication 1, caractérisé en ce que ladite action de gestion du trafic est une redirection (42), sur ledit nœud actif, d'au moins une partie du trafic associé à au moins une ressource IP associée audit domaine client.
  6. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend la vérification du fait que tous les nœuds clients dudit domaine client ont préalablement accepté de mettre en œuvre les étapes de la revendication 1 qui les concernent.
  7. 7. Procédé selon la revendication 6, caractérisé en ce que ladite vérification met en œuvre le contrôle de la valeur d'un paramètre de déclenchement de mitigation associé à chaque nœud client dudit domaine client au cours d'une phase de négociation de configuration.
  8. 8. Procédé de gestion du trafic associé à un domaine client, mis en œuvre dans un nœud client associé à une session active avec un serveur, ledit procédé comprenant la réception (32c2) d'au moins un message de demande de confirmation d'attaque portant sur au moins une ressource IP associée au domaine client, en provenance dudit serveur.
  9. 9. Procédé selon la revendication 8, caractérisé en ce qu'il comprend la vérification (33c2) que les ressources IP identifiées dans ledit au moins un message de demande de confirmation d'attaque sont associées audit domaine client.
  10. 10. Procédé selon l'une quelconque des revendications 8 et 9, caractérisé en ce qu'il comprend :
    la transmission (351c2), à au moins un nœud client dudit domaine client associé aux ressources IP identifiées dans ledit au moins un message de demande de confirmation d'attaque, d'au moins un premier message de vérification d'attaque, la transmission (355c2) audit serveur, le cas échéant, d'au moins un premier message de réponse informant ledit serveur d'une réponse dudit nœud client associé aux ressources IP identifiées dans ledit au moins un message de demande de confirmation d'attaque audit premier message de vérification d'attaque.
  11. 11. Procédé selon l'une quelconque des revendications 8 à 10, caractérisé en ce qu'il comprend :
    la transmission (361c2), à au moins un nœud dudit domaine client mettant en œuvre une fonction de détection d'attaque, d'au moins un deuxième message de vérification d'attaque portant sur au moins une ressource IP associée au domaine client ;
    la transmission (365c2) audit serveur, le cas échéant, d'au moins un deuxième message de réponse informant ledit serveur d'une réponse dudit nœud mettant en œuvre une fonction de détection d'attaque.
  12. 12. Procédé selon l'une quelconque des revendications 8 à 11, caractérisé en ce qu'il comprend la transmission d'au moins un premier message de vérification d'attaque audit au moins un nœud client associé aux ressources IP identifiées dans ledit au moins un message de demande de confirmation d'attaque, et/ou au moins un deuxième message de vérification d'attaque audit au moins un nœud dudit domaine client mettant en œuvre une fonction de détection d'attaque, en tenant compte d'au moins un critère de sélection.
  13. 13. Serveur comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour gérer le trafic associé à un domaine client, mettant en œuvre :
    la détection d'un problème de communication entre ledit serveur et au moins un premier nœud client dudit domaine client, dit nœud défaillant, l'identification d'au moins un deuxième nœud client appartenant audit domaine client, la vérification si une session est active entre ledit serveur et ledit au moins un deuxième nœud client, et o si aucune session n'est active : le déclenchement d'une procédure de mitigation sur au moins une ressource IP associée audit domaine client, o si au moins une session est active : l'utilisation du deuxième nœud client associé à ladite au moins une session active, dit nœud actif, pour engager une action de gestion du trafic associé audit domaine client.
  14. 14. Nœud client comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour la gestion du trafic associé à un domaine client, mettant en œuvre la réception d'au moins un message de demande de confirmation d'attaque portant sur au moins une ressource IP associée au domaine client, en provenance d'un serveur avec lequel une session est active.
  15. 15. Programme d'ordinateur comportant des instructions pour la mise en œuvre d'un procédé selon l'une quelconque des revendications 1 à 12 lorsque ce programme est exécuté par un processeur.
FR1856024A 2018-06-29 2018-06-29 Procedes de gestion du trafic associe a un domaine client, serveur, nœud client et programme d'ordinateur correspondants. Pending FR3081574A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1856024A FR3081574A1 (fr) 2018-06-29 2018-06-29 Procedes de gestion du trafic associe a un domaine client, serveur, nœud client et programme d'ordinateur correspondants.
US17/256,377 US11563816B2 (en) 2018-06-29 2019-06-28 Methods for managing the traffic associated with a client domain and associated server, client node and computer program
EP19752541.3A EP3815336A1 (fr) 2018-06-29 2019-06-28 Procédés de gestion du trafic associé à un domaine client, serveur, noeud client et programme d'ordinateur correspondants
PCT/FR2019/051605 WO2020002853A1 (fr) 2018-06-29 2019-06-28 Procédés de gestion du trafic associé à un domaine client, serveur, nœud client et programme d'ordinateur correspondants

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1856024 2018-06-29
FR1856024A FR3081574A1 (fr) 2018-06-29 2018-06-29 Procedes de gestion du trafic associe a un domaine client, serveur, nœud client et programme d'ordinateur correspondants.

Publications (1)

Publication Number Publication Date
FR3081574A1 true FR3081574A1 (fr) 2019-11-29

Family

ID=63834171

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1856024A Pending FR3081574A1 (fr) 2018-06-29 2018-06-29 Procedes de gestion du trafic associe a un domaine client, serveur, nœud client et programme d'ordinateur correspondants.

Country Status (4)

Country Link
US (1) US11563816B2 (fr)
EP (1) EP3815336A1 (fr)
FR (1) FR3081574A1 (fr)
WO (1) WO2020002853A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3086821A1 (fr) * 2018-09-28 2020-04-03 Orange Procedes de collaboration et de demande de collaboration entre services de protection associes a au moins un domaine, agents et programme d’ordinateur correspondants.

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150334123A1 (en) * 2014-05-15 2015-11-19 Cisco Technology, Inc. Ground truth evaluation for voting optimization
US20170223050A1 (en) * 2012-08-07 2017-08-03 Cloudflare, Inc. Identifying a Denial-of-Service Attack in a Cloud-Based Proxy Service

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7320032B2 (en) * 2001-05-21 2008-01-15 Hewlett-Packard Development Company, L.P. Methods and structure for reducing resource hogging
US7739328B1 (en) * 2001-12-11 2010-06-15 Actional Corporation Traffic manager for distributed computing environments
US8250650B2 (en) * 2004-09-09 2012-08-21 International Business Machines Corporation Front-end protocol for server protection
US8327022B2 (en) * 2006-10-10 2012-12-04 International Business Machines Corporation Method and apparatus for updating a domain name server
US20110225230A1 (en) * 2010-03-15 2011-09-15 Russ Craig F Method and apparatus for detecting active and orphan session-based connections
US8675488B1 (en) * 2010-09-07 2014-03-18 Juniper Networks, Inc. Subscriber-based network traffic management
US10666503B1 (en) * 2018-09-27 2020-05-26 Amazon Technologies, Inc. Network connection and termination system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170223050A1 (en) * 2012-08-07 2017-08-03 Cloudflare, Inc. Identifying a Denial-of-Service Attack in a Cloud-Based Proxy Service
US20150334123A1 (en) * 2014-05-15 2015-11-19 Cisco Technology, Inc. Ground truth evaluation for voting optimization

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MORTENSEN ARBOR NETWORKS F ANDREASEN CISCO T REDDY MCAFEE A ET AL: "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture; draft-ietf-dots-architecture-05.txt", DISTRIBUTED-DENIAL-OF-SERVICE OPEN THREAT SIGNALING (DOTS) ARCHITECTURE; DRAFT-IETF-DOTS-ARCHITECTURE-05.TXT; INTERNET-DRAFT: DOTS, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENE, no. 5, 26 October 2017 (2017-10-26), pages 1 - 30, XP015122508 *

Also Published As

Publication number Publication date
EP3815336A1 (fr) 2021-05-05
US20210160330A1 (en) 2021-05-27
WO2020002853A1 (fr) 2020-01-02
US11563816B2 (en) 2023-01-24

Similar Documents

Publication Publication Date Title
US20150020188A1 (en) Network Host Provided Security System for Local Networks
JP2009528757A (ja) ピアツーピア通信の検出及び制御
US11546374B2 (en) Selective traffic processing in a distributed cloud computing network
EP3857848B1 (fr) Procédé d'allocation d'un identifiant à un noeud client, procédé d'enregistrement d'un identifiant, dispositif, noeud client, serveur et programmes d'ordinateurs correspondants
EP3533202B1 (fr) Controle dynamique et interactif d'une passerelle residentielle connectee a un reseau de communication
WO2020002853A1 (fr) Procédés de gestion du trafic associé à un domaine client, serveur, nœud client et programme d'ordinateur correspondants
EP3939232A1 (fr) Mitigation d'attaques informatiques
EP4066461B1 (fr) Procédé de coordination de la mitigation d'une attaque informatique, dispositif et système associés
WO2019211548A1 (fr) Procédé d'envoi d'une information et de réception d'une information pour la gestion de réputation d'une ressource ip
CN112514350B (zh) 用于核实ip资源的有效性的方法以及相关联的访问控制服务器、验证服务器、客户端节点、中继节点和计算机程序
EP3087719B1 (fr) Procédé de ralentissement d'une communication dans un réseau
US12034701B2 (en) Methods for protecting a client domain, corresponding client node, server and computer programs
FR3086821A1 (fr) Procedes de collaboration et de demande de collaboration entre services de protection associes a au moins un domaine, agents et programme d’ordinateur correspondants.
WO2021105617A1 (fr) Procede d'assistance pour la gestion d'une attaque informatique, dispositif et systeme associes
WO2024121017A1 (fr) Procédés de détection d'un serveur de résolution de noms de domaine malveillant, équipement, serveur de confiance et programme d'ordinateur correspondants
WO2023117802A1 (fr) Procédés d'identification d'au moins un serveur de mitigation et de protection d'un domaine client contre une attaque informatique, dispositifs et signal correspondants
FR3136922A1 (fr) Procédé de communication entre un premier équipement et un serveur distant, procédé de gestion des communications, premier équipement, serveur distant et programme d’ordinateur correspondants.
WO2008031967A2 (fr) Procédé de supervision d'une session d'accès a un service établie par un terminal client au moyen d'un protocole de configuration dynamique

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20191129

RX Complete rejection

Effective date: 20210713