FR 3086821 A1 20200403 FR 1871107 A 20180928 Description Titre de l'invention : Procédés de collaboration et de demande de collaboration entre services de protection associés à au moins un domaine, agents et programme d'ordinateur correspondants. 1. Domaine de l'invention [00011 Le domaine de l'invention est celui des communications au sein d'un réseau de com- munication, par exemple un réseau I P, et notamment celui des services IP à valeur ajoutée. [00021 Plus précisément, l'invention offre une solution permettant à différents services de protection, protégeant un ou plusieurs domaines, de collaborer. De tels services de protection sont par exemple de type DPS (en anglais « DDoS Protection Services », pour « Distrihuted Denial of Service Protection Services », ou services de protection d'attaques par déni de services distribuées), mettant par exemple en oeuvre, mais non exclusivement, une architecture de type DOTS, en anglais « DDoS Open Threat Signaling »). Le service de protection et l'infrastructure déployée pour fournir un tel service sont appelés indifféremment « service de protection » ci-après. [00031 En particulier, l'invention offre une solution permettant de coordonner des actions de mitigation lorsqu'une attaque par déni de services est identifiée. [0004] L'invention trouve notamment des applications dans tout domaine utilisant des réseaux informatiques pouvant être soumis à une attaque de type virus, SPAM, SPIT (en anglais « SPAM over IP Telephony », ou SPAM sur communication téléphonique sur IP), DDoS, etc. 2. Art antérieur [0005] On s'attache plus particulièrement dans la suite de ce document à décrire une pro- blématique existant dans le domaine de la mitigation d'attaques DDoS, Bien sûr, l'invention ne se limite pas à ce domaine particulier d'application, mais présente un intérêt pour la mitigation d'attaques de toute nature. [0006] 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. [0007] Afin de pallier à ces attaques DDoS, des services de détection et de mitigation sont proposés par certains fournisseurs d'accès ou de services à leurs clients. De tels services de protection, ou DPS (« DDoS Protection Service » en anglais), 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 », i.e., les données consenties par l'utilisateur, du trafic « suspect ». [0008] Lorsqu'un service de type DPS est hébergé dans le « Cloud », il est difficile de détecter une attaque DDoS de façon anticipée, car un tel service n'est pas nécessairement présent sur les chemins de routage (par défaut) permettant de joindre le réseau victime d'une attaque DDoS. [0009] Pour résoudre ce problème, il a été notamment proposé de mettre en place des tunnels pour forcer le trafic (entrant ou sortant, en anglais « inbound » ou « outhound ») 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, sans pour autant dégrader la performance ou le niveau de qualité du service fourni au client. En outre, de tels tunnels sont considérés comme des vecteurs d'attaque potentiels. [0010] Lorsqu'un service 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, est un autre exemple de la complexité associée à la vérification du consentement d'un noeud du réseau à recevoir du trafic. [0011] Afin d'aider à l'identification du trafic suspect, une architecture spécifique a été nmmalisée par l'IETF. Une telle architecture, appelée DOTS, permet en particulier à un noeud client, dit client DOTS, d'informer un serveur, dit serveur DOTS, qu'il a détecté une attaque DDoS et que des actions appropriées sont requises. [0012] Ainsi, si un domaine client est la cible d'une attaque DDoS, un client DOTS faisant partie de 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. L'entité de mitigation peut en particulier être co-localisée avec le serveur DOTS. [0013] L'architecture DOTS repose sur l'utilisation de deux canaux de communication entre le client DOTS et le serveur DOTS : [0014] - un canal de signalisation DOTS (en anglais « DOTS Signal Channel »), et [0015] - un canal de données DOTS (en anglais « DOTS Data Channel »). [0016] 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 traiter l'attaque. [0017] Un tel canal de signalisation est notamment décrit dans le document « Di,stributed Denial-ol:Service Open Dirent Signaling (DOTS) Signal Channel Specification », draft-ietf-dots-signal-channel, Reddy, T. et al., janvier 2018. [0018] 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 noeud 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 », ou tout le trafic UDP destiné au numéro de port 443. [0019] Un tel canal de données est notamment décrit dans le document « Distributed Denial-ofService Open Threcn Signaling (DOTS) Data Channel », draftietf-dots-data-channel, Boucadair, M. et al., décembre 2017. [0020] L'architecture DOTS couvre uniquement la relation entre un client DOTS et son serveur DOTS, pour demander de l' assistance lorsque le client DOTS détecte une attaque. En d'autres termes, les clients/serveurs DOTS appartenant à d'autres infrastructures DPS ne. sont pas au courant de l'attaque. [0021] Il existe donc un besoin pour une nouvelle technique permettant notamment d'informer d'autres infrastructures DPS d'une attaque à grande échelle, par exemple une attaque de déni de service, et ainsi de coordonner des actions entre plusieurs DPS, par exemple des actions de mitigation. 3. Exposé de l'invention [0022] L'invention repose sur un nouveau procédé de collaboration entre services de protection associés à un ou plusieurs domaines, mis en oeuvre par un premier agent utilisé par un premier service de protection, comprenant : [0023] - l'identification, par le premier agent, d'une attaque sur au moins une ressource gérée par un domaine protégé par le premier service de protection, [0024] - la transmission, à au moins un deuxième agent utilisé par un deuxième service de protection, d'au moins une information relative à l'attaque identifiée par ledit premier agent. [0025] Typiquement, un agent utilisé par un service de protection appartient à un domaine / une infrastructure offrant ce service de protection. [0026] De cette façon, lorsqu'un domaine client subit une attaque, le service de protection associé à ce domaine client peut propager des informations relatives à cette attaque 4 vers des services de protection associés à ce domaine client ou à d'autres domaines clients, afin que ces autres services de protection puissent anticiper ladite attaque ou une attaque similaire et ainsi protéger ces domaines clients. Aussi, la coordination permet de mettre en place un plan de mitigation distribué impliquant plusieurs DPS ou réseaux d'accès permettant ainsi de limiter la propagation de certaines attaques. [0027] L'étape de transmission peut être restreinte à certains types d'attaques, d'agents voisins. etc. Des politiques (« policies », en anglais) sont typiquement fournies à l'agent qui met en oeuvre ledit procédé de collaboration. [0028] En d'autres termes, il est possible de communiquer des informations relatives à une attaque identifiée par un service de protection, par exemple DPS, à d'autres services de protection qui pourraient en avoir l'usage, quelque soit la portée de l'attaque identifiée, et ainsi d'éviter, ou à tout le moins de ralentir, la propagation d'une attaque. [0029] Par exemple, une telle attaque peut être de type : [0030] - attaque par déni de service (DDoS, typiquement) ; [0031] - virus informatique ; [0032] - SPAM ; [0033] - SPIT ; [0034] - etc. [0035] En particulier, si une attaque est une attaque par déni de service, identifiée par un service de protection protégeant un premier domaine, il est possible d'informer les services de protection protégeant d'autres domaines des actions de mitigation engagées, permettant ainsi aux services de protection protégeant ces autres domaines d'engager par anticipation des actions de mitigation. On diminue ainsi le risque de propagation de l'attaque dans d'autres domaines, par exemple d'autres régions du réseau Internet, ou de dégradation du service fourni par les services de protection protégeant ces autres domaines. [0036] Selon au moins un mode de réalisation, la solution proposée permet de faciliter la co- ordination des actions de mitigation notamment, grâce au partage d'informations relatives aux attaques. Aussi, elle permet de réduire le temps requis pour la mise en place de plans de mitigation grâce au partage et à la dissémination d'actions de mitigation entre domaines DPS. [0037] Selon au moins un mode de réalisation, la solution proposée permet également de propager des informations a priori fiables, puisque ces informations sont obtenues par le service de protection ayant identifié une attaque. [0038] Selon au moins un mode de réalisation, la solution proposée permet également de propager rapidement des informations, ce qui permet aux services de protection recevant les informations relatives aux attaques d'anticiper ces attaques et de réagir d'une manière optimale de manière à limiter un usage abusif de ressources réseau. [00391 Selon une caractéristique particulière, la transmission, à au moins un deuxième agent utilisé par un deuxième service de protection, d'au moins une information relative à l'attaque identifiée par le premier agent, met en oeuvre l'émission d'au moins un message de notification à destination du ou des deuxième(s) agent(s) ou d'un agent intermédiaire en charge de la redirection des messages. [0040] Par exemple, ledit au moins un message de notification comprend au moins une in- formation appartenant au groupe comprenant : [0041] - une information relative à la souscription, par ledit au moins un deuxième agent, à au moins un service de partage d'informations proposé par ledit premier service de protection ; [0042] - un identifiant de l'attaque ; [0043] - une information de description de l'attaque ; [0044] - une information relative à l'état de l'attaque ; [0045] - une information indiquant si une action de mitigation est mise en oeuvre par le premier service de protection [0046] - une information indiquant une action de mitigation mise en oeuvre par le premier service de protection ; [0047] - une demande d'assistance pour traiter l'attaque ; [0048] - etc. [0049] Ces différentes informations peuvent être transmises dans des messages de noti- fication distincts, ou agrégées dans un même message de notification, [0050] En particulier, un nouveau message de notification peut être émis en cas de modi- fication de l'attaque. Par exemple, si de nouvelles sources sont impliquées dans l'attaque, un nouveau message de notification est transmis au(x) deuxième(s) agent(s), éventuellement par l'intermédiaire d'un agent intermédiaire en charge de la redirection des messages. [0051] Selon un mode de réalisation particulier, le procédé de collaboration entre services de protection comprend une étape préalable de souscription, mettant en oeuvre : [0052] - l'établissement d'une session entre le premier agent et ledit au moins un deuxième agent, [0053] - la réception, par le premier agent, d'au moins un message de souscription à au moins un service de partage d'infoi mations proposé par le premier service de protection, [0054] - l'extraction et le stockage des informations véhiculées dans ledit au moins un message de souscription. [0055] Par exemple, ledit au moins un message de souscription comprend au moins une in- formation appartenant au groupe comprenant : [0056] - une information relative à un type de service de partage d'informations demandé 6 (par exemple tous les services de partage d'informations du premier service de protection, le service de partage d'informations relatives à des attaques DDoS du premier service de protection, le service de partage d'informations relatives à la détection de virus du premier service de protection, le service de partage d'informations relatives à des attaques SPIT du premier service de protection, etc.) ; [0057] - un niveau d'alerte associé audit au moins un deuxième agent (par exemple seules les alertes relatives aux attaques critiques sont envoyées, ou seules les alertes qui correspondent aux filtres indiqués par un agent utilisé par un service de protection sont envoyées) ; [0058] - une information de redirection vers un autre agent utilisé par le deuxième service de protection (précisant, par exemple, si les messages de notification doivent être envoyés vers un autre agent utilisé par le même service de protection) ; [0059] - une durée de validité ; [0060] - etc. [0061] Ces différentes informations peuvent être transmises dans des messages de sous- cription distincts, ou agrégées dans un même message de souscription. [0062] En particulier, un tel procédé comprend la suppression automatique, à l'expiration d'une durée de validité associée au message de souscription, des informations véhiculées dans un message de souscription préalablement stockées. [0063] L'invention repose également sur un nouveau procédé de demande de collaboration entre services de protection associés à un ou plusieurs domaines, mis en oeuvre par au moins un deuxième agent utilisé par un deuxième service de protection, selon lequel, un premier agent utilisé par un premier service de protection ayant identifié une attaque sur au moins une ressource gérée par un domaine protégé par le premier service de protection, le procédé comprend : [0064] - la réception, par le deuxième agent, d'au moins une information relative à l'attaque identifiée par le premier agent, [0065] - la détermination d'au moins une action à effectuer, à partir de la ou des in- formations relatives à l'attaque. [0066] En particulier, la réception met en oeuvre la réception d'au moins un message de noti- fication, tel que décrit ci-dessus, transmis par ledit premier agent ou par un agent intermédiaire en charge de la redirection des messages. [0067] Selon un mode de réalisation particulier, la réception met également en oeuvre la réception d'au moins un message de notification transmis par un agent utilisé par un service de protection distinct du premier service de protection. [0068] Il est ainsi possible de corréler les informations reçues de différents agents, ce qui permet notamment de confirmer la réalité ou l'étendue d'une attaque. [0069] Par exemple, ladite au moins une action comprend la transmission, à une entité en charge de la mitigation du deuxième service de protection, de la ou des informations relatives à l'attaque. Eventuellement, ladite au moins une action comprend une mise à jour des filtres gérés par le deuxième service de protection. 100701 Selon un autre exemple, ladite au moins une action comprend la transmission au premier agent, ou à un agent intermédiaire en charge de la redirection des messages, d'un message de partage d'actions avec le premier service de protection. Par exemple, le deuxième agent peut demander à partager un plan de mitigation avec le premier agent. [0071] Selon un mode de réalisation particulier, le procédé de demande de collaboration entre services de protection comprend une étape préalable de souscription mettant en oeuvre [0072] - l'établissement d'une session entre le premier agent et ledit au moins un deuxième agent, [0073] - la transmission, par ledit au moins un deuxième agent, d'un message de sous- cription (tel que décrit précédemment) à au moins un service de partage d'informations proposé par le premier service de protection. [0074] En particulier, ledit au moins un deuxième agent retransmet le message de sous- cription avant l'expiration d'une durée de validité associée audit message de souscription. [0075] Selon un mode de réalisation particulier, le procédé mis en oeuvre par le premier et/ ou le deuxième agent comprend en outre : [0076] - l'identification d'au moins un fournisseur d'accès responsable d'au moins une ressource impliquée dans la propagation du trafic caractéristique de ladite attaque, [00771 - la transmission audit au moins un fournisseur d'accès d'une demande de filtrage du trafic caractéristique de ladite attaque entrant et/ou sortant de ladite au moins une ressource. [0078] De cette façon, les services de protection peuvent collaborer avec les fournisseurs d'accès pour filtrer, voire bloquer, en amont le trafic émis par des machines impliquées dans une attaque, permettant ainsi de limiter la propagation de l'attaque au plus près de sa source. [0079] On note également que, selon l'art antérieur, lorsqu'un grand nombre de machines est impliqué dans la réalisation des attaques, la mise en place de politiques de filtrage adaptées, c'est-à-dire capables d'isoler le trafic en provenance de l'ensemble des machines impliquées dans les attaques, est d'autant plus compliquée que ces machines peuvent être massivement distribuées sur plusieurs réseaux distincts. Dans un tel contexte, la mise en place de filtres est compliquée par l'identification et la déclaration d'un nombre d'adresses ou de réseaux important, avec des risques d'erreur de configuration susceptibles de mettre en péril l'acheminement de trafics légitimes. En outre, les performances de commutation des machines sur lesquelles de tels filtres (ou ACL, en anglais « Access Control List ») sont installés peuvent être inversement proportionnelles au nombre de listes d'accès configurées : plus il y a de filtres, plus les décisions d'acheminement de paquets prennent du temps, au risque de dégrader les performances de commutation des machines. L'installation d'un nombre important d'ACL est elle-même considérée comme une attaque DDoS. [0080] Le mode de réalisation proposé ci-dessus permet notamment de répartir les actions de filtrage entre plusieurs fournisseurs d'accès, ce qui permet de faciliter la mise en place des filtres à grande échelle. [0081] Un autre mode de réalisation concerne un agent utilisé par un service de protection, configuré pour identifier une attaque et transmettre au moins une information relative à l'attaque identifiée à un agent utilisé par un autre service de protection, et/ou configuré pour recevoir au moins une information relative à une attaque identifiée par un agent utilisé par un autre service de protection et déterminer au moins une action à effectuer en conséquence. [0082] Par exemple, un tel agent est un noeud de l'infrastructure utilisée pour la mise en oeuvre du service de protection, embarquant des fonctionnalités spécifiques lui permettant d'identifier une attaque / transmettre au moins une information relative à l'attaque et/ou recevoir au moins une information relative à une attaque / déterminer au moins une action. [0083] Dans un autre mode de réalisation, l'invention concerne un ou plusieurs programmes d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé de collaboration entre services de protection, ou de demande de collaboration entre services de protection, selon au moins un mode de réalisation de l'invention, lorsque ce ou ces programmes est/sont exécuté(s) par un processeur. [0084] 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 collaboration entre services de protection, ou de demande de collaboration entre services de protection, selon au moins un mode de réalisation de l'invention. [0085] Les procédés selon l'invention peuvent donc être mis en oeuvre de diverses manières, notamment sous forme câblée et/ou sous tonne logicielle. 4. Liste des figures [0086] 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 : [0087] [fig.1] La figure 1 illustre un exemple de réseau de communication mettant en oeuvre un procédé de collaboration, ou de demande de collaboration, entre services de protection, selon un mode de réalisation de l'invention ; l00881 Ifig.2[ La figure 2 présente les principales étapes d'un procédé de collaboration, ou de demande de collaboration, entre services de protection, selon au moins un mode de réalisation de l'invention ; [0089] [fig.3A] [0090] [fi c.3B] [0091] [fig.3C] Les figures 3A à 3C illustrent différents modes de communication entre des agents utilisés par des services de protection distincts ; [0092] [fig.4] [0093] [fig.5] Les figures 4 et 5 présentent les principales étapes mises en oeuvre par un agent local et par un agent distant au cours d'une phase de souscription ; [0094] [fig.6] [0095] [fig.7] Les figures 6 et 7 illustrent la transmission et l'utilisation et d'un message de noti- fication selon un mode de réalisation de l'invention ; [0096] [fig.8] [0097] [fig.9] Les figures 8 et 9 présentent les principales étapes mises en ouvre par un agent local et par un agent distant au cours d'une phase de notification ; [0098] [fig.10] [0099] [fig.11] Les figures 10 et H illustrent un mode de réalisation particulier permettant à un fournisseur d'accès de filtrer le trafic caractéristique d'une attaque ; [0100] [fig.12] La figure 12 présente la structure simplifiée d'un agent selon un mode de réalisation particulier. [0101] 5. Description d'un mode de réalisation de l'invention [0102] 5.1 Principe général [0103] Le principe général de l'invention repose sur la collaboration entre au moins deux services de protection associés à un ou plusieurs domaines réseau. L'invention permet en particulier d'infomier un service de protection distant associé à un domaine distant, lorsqu'une attaque sur une ressource gérée par un domaine local est détectée par le service de protection local. I t) [01041 On présente, en relation avec la figure 1, différents équipements d'un réseau de com- munication aptes à mettre en oeuvre la collaboration entre services de protection selon tin mode de réalisation de l'invention. 101051 On considère par exemple un premier domaine 111, associé à un premier service de protection 112, noté par exemple DPS#1, et un deuxième domaine 121, associé à un deuxième service de protection 122, noté par exemple DPS#2. [0106] Par exemple, un domaine comprend une ou plusieurs machines, encore appelées noeuds. On entend ici par « domaine » ou « réseau » un ensemble de machines ou noeuds placés sous la responsabilité d'une même entité. [0107] Les premier et deuxième services de protection 112 et 122 protègent respectivement les ressources réseau des premier et deuxième domaines 111 et 121. Les premier et deuxième domaines 111 et 121 peuvent être connectés au réseau Internet 13. [0108] Des sources d'attaques S1 141, S2 142, ..., Sk 14k peuvent également être connectées au réseau Internet 13 via de fournisseurs d'accès AP#1 151, AP#2 152, AP#n 15n (en anglais « Access Providers »). [0109] La figure 2 illustre les principales étapes mises en oeuvre pour la collaboration entre services de protection dans un réseau de communication tel que celui illustré en figure 1. [0110] Au cours d'une phase de détection, un premier agent 113 utilisé par le premier service de protection 112 protégeant le premier domaine 111 identifie (221) une attaque sur au moins une ressource gérée par le premier domaine 111. [0111] Par exemple, une attaque peut être détectée par un noeud du premier domaine 111 (par exemple un client DOTS) ou par un noeud de l'infrastructure utilisée pour la mise en oeuvre du premier service de protection 121 (premier agent 113 embarquant des fonctionnalités spécifiques selon l'invention ou autre noeud). Le premier agent 113 utilisé par le premier service de protection peut donc soit détecter lui-même l'attaque, soit recevoir cette information de la part d'un autre noeud. [0112] Le premier agent 113 peut alors décider de transmettre (222) à au moins un autre agent, par exemple à un deuxième agent 123 utilisé par le deuxième service de protection 122, protégeant le deuxième domaine 112, au moins une information relative à l'attaque identifiée par le premier agent 113. Une telle information peut éventuellement être transmise à un agent intermédiaire, qui se charge de la retransmettre au deuxième agent 123 notamment. [0113] De son côté, le deuxième agent 123 utilisé par le deuxième service de protection 122 reçoit (223) la ou les informations relatives à l'attaque identifiée par le premier agent 113 utilisé par le premier service de protection 112. [0114] A partir de la ou des informations reçues relatives à l'attaque, le deuxième agent 123 peut déterminer (224) au moins une action à effectuer. 101151 Suite à la phase de détection 22, une phase de mitigation 23 des attaques peut être mise en oeuvre. [0116] Par exemple, il est possible de coordonner plusieurs actions de mitigation engagées suite à la détection d'une attaque, notamment à l'échelle de l'Intemet, au cours de la phase de mitigation 23. [0117] Préalablement à la phase de détection 22, une phase de souscription 21 peut être mise en oeuvre. [0118] Une telle phase de souscription 21 met par exemple en oeuvre l'établissement 211 d'une session entre le premier agent 113 utilisé par le premier service de protection 112, et au moins un agent utilisé par un autre service de protection, par exemple le deuxième agent 123 utilisé par le deuxième service de protection 122. [0119] Pour souscrire aux services de partage d'informations (appelé simplement ci-après service de partage) du premier service de protection 112, le deuxième agent 123 transmet (212) au moins un message de souscription au premier agent 113. Un tel message peut éventuellement être transmis à un agent intermédiaire, qui se charge de le retransmettre au premier agent 113 notamment. [0120] De son côté, le premier agent 113 reçoit (213) le ou les messages de souscription, et stocke (214), par exemple dans une base de données de souscription distante 24, les informations véhiculées par le ou les messages de souscription. [0121] La phase de détection 22 peut alors être mise en oeuvre. [0122] La solution proposée permet donc de coordonner des services de protection, éven- tuellement à l'échelle de l'Internet, de la phase de détection de l'attaque à la phase de mitigation de l'attaque (quelle que soit l'origine de l'attaque, quel que soit le vecteur (par exemple un objet connecté, un tunnel, etc.) et quelles que soient les victimes (réseau, terminal service, etc.)). Selon au moins un mode de réalisation, la solution proposée permet de garantir une cohérence globale et rapide des informations relatives à l'attaque (origine, nature, contenu, cible, vecteur, etc.) et des actions engagées pour la résoudre. [0123] On note que, dans un mode de réalisation particulier, plusieurs services de protection sont associés à un même domaine, i.e., protègent le même domaine. Un exemple d'application est un réseau d'entreprise en « multi-homing ». Dans ce cas, les premier et deuxième domaines 111 et 121 sont un seul et même domaine. [0124] 5.2 Exemples d'application [0125] On décrit ci-après des exemples de mise en oeuvre de l'invention avec des services de protection de type DPS, utilisés principalement pour traiter les attaques DDoS. [0126] On note toutefois que la solution proposée, telle que présentée ci-dessous notamment, s'applique à d'autres attaques de sécurité telles que la propagation de virus, l'exploitation des vulnérabilités des systèmes d'exploitation, etc. 12 [01271 5.2.1 Définition des agents [0128] La solution proposée repose sur l'attribution de fonctionnalités spécifiques à un ou plusieurs noeuds de l'infrastructure utilisée pour la mise en oeuvre d'un service de protection, notés « agent », ou, selon un mode de réalisation particulier mettant en oeuvre des services de protection de type DPS, « agent DIA » (pour « DPS IDAD Agent », or7IDAD signifie « Inter-DES Attack Dissemination and mitigation action sharing and assistance », i.e., assistance et partage des actions de mitigation et d'atténuation d'attaque entre DPS). [0129] Un ou plusieurs agents peuvent être activés par un service de protection. Un agent d'un service de protection peut s'interfacer avec un ou plusieurs agents d'autres services de protection. [0130] 5.2.2 Communication des agents [0131] A) Etablissement d'une session [0132] Les sessions de communication entre les agents peuvent être établies en utilisant des protocoles connus, par exemple [0133] - DTLS (en anglais « Datagram Transport Layer Security », tel que décrit dans le document « Datagram Transport Layer Security Version 1.2 », RFC 6347, Rescorla, E. et N. Modadugu DOT 10.17487/RFC6347, janvier 2012), [0134] - DTLS 1.3 (en anglais « Datagram Transport Layer Security », tel que décrit dans le document « The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", draft-ietf-tls-dtls13-22 », Rescorla, E., Tschofenig, H., et N. Modadugu, novembre 2017), [0135] - TLS (en anglais « Transport Layer Security », tel que décrit dans le document « The Transport Layer Security (TLS) Protocol Version 1.2 », RFC 5246, Dierks, T. et E. Rescorla, DOI 10.17487/RFC5246, août 2008 ou le document « The Transport Layer Security (TLS) Protocol Version 1.3 », RFC8446, E. Rescorla, DOI 10.17487/RFC8446, août 2018). [0136] Les échanges DTLS ou TLS et les échanges concernant la gestion des clés de sécurité sont classiques et ne sont pas décrits plus en détail. [0137] Selon un mode de réalisation particulier, on suppose que les agents utilisés par les services de protection s'authentifient mutuellement. Ainsi, les messages reçus d'une machine usurpant l'identité d'un agent légitime sont rejetés par un autre agent. De la même manière, les demandes d'un agent utilisé par un premier service de protection, non-autorisé à accéder aux services de partage d'informations proposé par un deuxième service de protection, sont ignorées par un agent utilisé par un deuxième service de protection. [0138] Par exemple, cette procédure d'authentification mutuelle est mise en place par les agents des services de protection. 13 (01341 B) Modes de communication [0140] Les agents utilisés par différents services de protection peuvent communiquer di- rectement entre eux, ou via un agent intermédiaire en charge de la redirection des messages. Cet agent intermédiaire est par exemple utilisé par un répartiteur de fédération, ou FD (en anglais « Federation Dispatcher »). [0141] Les figures 3A à 3C illustrent différents exemples de communication entre les agents utilisés par différents services de protection. [0142] La figure 3A illustre un exemple de communication en mode « point-à-point », selon lequel les agents échangent directement des messages entre différents services de protection. Par exemple, un premier agent 321 d'un deuxième service de protection DPS 32 échange des messages directement avec un premier agent 311 d'un premier service de protection DPS 31, un premier agent 341 d'un quatrième service de protection DPS 34 et un premier agent 351 d'un cinquième service de protection DPS 35, Un deuxième agent 322 du deuxième service de protection DPS 32 échange des messages directement avec un premier agent 331 d'un troisième service de protection DPS 33. Les premier 321 et deuxième 322 agents du deuxième service de protection DPS 32 peuvent communiquer entre eux puisqu'ils sont utilisés par le même service de protection. [0143] Selon l'exemple illustré en figure 3A, le deuxième service de protection DPS 32 peut envoyer quatre fois le même message vers les autres services de protection DPS 31, 33, 34 et 35. [0144] Les figures 3B et 3C illustrent des exemples de communication en mode « fédération ». Ce mode suppose que les services de protection sont organisés en des fédérations. Les agents envoient des messages vers un répartiteur de la fédération, qui se charge de relayer les messages d'un agent d'un service de protection de la fédération vers un agent d'un autre service de protection de la fédération ou vers un répartiteur d'une autre fédération. [0145] Selon l'exemple illustré en figure 3B, les services de protection DPS 31 à 35 font partie de la. même fédération, et peuvent donc échanger des messages par l'intermédiaire du répartiteur 36. Par exemple, le premier agent 321 du deuxième service de protection DPS 32 échange des messages avec le répartiteur 36. Un premier agent 361 du répartiteur 36 redirige les messages du premier agent 321 du deuxième service de protection DPS 32 vers le premier agent 311 du premier service de protection DPS 31 et le premier agent 351 du cinquième service de protection DPS 35. Un deuxième agent 362 du répartiteur 36 redirige les messages du premier agent 321 du deuxième service de protection DPS 32 vers le premier agent 331 du troisième service de protection DPS 3 et le premier agent 341 du quatrième service de protection DPS 34. Les premier 361 et deuxième 362 agents du répartiteur 36 peuvent com- 14 muniquer entre eux. [0146] Selon l'exemple illustré en figure 3C, les premier et cinquième services de protection DPS 31 et 35 font partie d'une première fédération, utilisant un premier répartiteur 37, et les deuxième, troisième et quatrième services de protection DPS 32, 33, 34 font partie d'une deuxième fédération, utilisant un deuxième répartiteur 72. Par exemple, le premier agent 321 du deuxième service de protection DPS 32 échange des messages avec le répartiteur 36. Un premier agent 361 du deuxième répartiteur 36 redirige les messages du premier agent 321 du deuxième service de protection DPS 32 vers un premier agent 371 du premier répartiteur 37. Le premier agent 371 du premier répartiteur 37 redirige les messages du premier agent 321 du deuxième service de protection DPS 32 vers le premier agent 311 du premier service de protection DPS 31 et le premier agent 351 du cinquième service de protection DPS 35. Un deuxième agent 362 du deuxième répartiteur 36 redirige les messages du premier agent 321 du deuxième service de protection DPS 32 vers le premier agent 331 du troisième service de protection DPS 3 et le premier agent 341 du quatrième service de protection DPS 34. Les premier 361 et deuxième 362 agents du répartiteur 36 peuvent communiquer entre eux. [0147] Selon les exemples illustrés en figures 3B et 3C, le deuxième service de protection DPS 32 peut envoyer une seule fois le message au répartiteur 36, qui se charge alors de le retransmettre vers les quatre autres services de protection DPS 31, 33, 34 et 35. Ce mode facilite donc l'application ou l'exploitation d'un traitement réalisé par un service de protection, par exemple pour résoudre une attaque en cours au sein de son domaine de responsabilité (par exemple un réseau qu'il protège), tout en optimisant la volumétrie des échanges entre les services de protection d'une fédération. [0148] 5.2.3 Souscription à un service de protection distant [0149] Pour mettre en oeuvre la collaboration entre services de protection, un agent utilisé par un service de protection peut souscrire, selon au moins un mode de réalisation, à au moins un service de partage d'informations proposé par un service de protection distant. [0150] On considère par exemple qu'une session de communication sécurisée est établie entre un agent utilisé par un service de protection, par exemple le premier agent 113 du premier service de protection 112 selon la figure 1, et un agent souhaitant souscrire à au moins un service de partage d'informations proposé par le premier service de protection, par exemple le deuxième agent 123 du deuxième service de protection 122 selon la figure 1. Cette session de communication peut être établie entre les deux agents directement, ou entre les agents via au moins un agent intermédiaire utilisé par au moins un répartiteur au sein d'une fédération. [0151] Une fois la session établie, le deuxième agent 123, souhaitant souscrire à au moins un 15 service de partage d'informations proposé par le premier service de protection 112, envoie au moins un message de souscription au premier agent 113, directement ou via au moins un agent intermédiaire. En d'autres termes, le message de souscription est émis du deuxième agent 123 vers le premier agent 113 ou vers un répartiteur. [0152] Par exemple, le message de souscription est noté SUBSCRIBEO et comprend au moins un attribut, ou paramètre, portant une information de type : [0153] - « Service_type » : information relative à un type ou une nature du service de partage d'informations demandé. Par exemple, si aucune valeur n'est indiquée, le premier agent peut interpréter le message de souscription comme une demande de souscription au service DDoS du premier service de protection. A titre d'exemple, les valeurs poilées par ce paramètre peuvent être [0154] i. 0 : tous les services de partage d'informations supportés par le premier service de protection (destinataire du message de souscription) ; [0155] ii. 1 : service DDoS du premier service de protection ; [0156] iii. 2 : service de détection de virus du premier service de protection ; [0157] iv. 3 : service SPAM du premier service de protection ; [0158] y. 4 : service SPIT du premier service de protection [0159] vi. etc. [0160] On note qu'un même message de souscription peut être utilisé pour indiquer plusieurs types de service. En variante, des messages de souscription dédiés peuvent être envoyés par service. [0161] - « Verbose_lMode » : un niveau d'alerte associé au deuxième agent. En d'autres termes, ce paramètre indique le niveau de granularité des notifications que le deuxième agent, souhaitant souscrire à au moins un service de partage d'informations proposé par le premier service de protection, souhaite recevoir. A titre d'exemple, les valeurs portées par ce paramètre peuvent être : [0162] i. 0 : seules les alertes relatives aux attaques critiques sont envoyées. Par exemple, une attaque est dite critique si la volumétrie du trafic relatif à cette attaque dépasse un certain seuil, ou si elle implique un certain nombre de machines, ou si elle dure plus de X minutes, etc. Cette valeur peut être utilisée par défaut. [0163] ii. 1 : seules les alertes qui correspondent aux filtres indiqués par Fun des agents sont envoyées. Un filtre peut être défini par un ou plusieurs attributs tels que : [0164] + protocole : renseigne un protocole spécifique tel qu'UDP, TCP, NTP, DNS, etc. ; [0165] + numéro de port : renseigne un numéro de port spécifique tel que 80, 23. 443, etc. Eventuellement, une plage de numéros de port peut être spécifiée (par ex. 80-8080) ; [0166] + taille des paquets caractéristiques de l'attaque ; [0167] + etc. [0168] - N_DIA : une information de redirection vers un autre agent utilisé par le deuxième 16 service de protection. Par exemple, ce paramètre précise si le ou les messages de souscription doivent être envoyés vers un autre agent utilisé par le même service de protection (cas de redirection). Dans ce cas, au moins une adresse IP de cet agent peut être fournie ; [0169] - une durée de validité : ce paramètre associe une durée de validité à cette sous- cription. Par exemple, l'absence de ce paramètre ou l'utilisation de la valeur (-1) indique que la souscription a une durée infinie ; [0170] - etc. [0171] Les figures 4 et 5 illustrent les principales étapes mises en oeuvre par les premier et deuxième agents, selon au moins un mode de réalisation. Plus précisément, la figure 4 illustre les étapes mises en oeuvre par le premier agent 113 utilisé par un premier service de protection 112 et la figure 5 illustre les étapes mises en oeuvre par le deuxième agent 123, souhaitant souscrire à au moins un service de partage d'informations proposé par le premier service de protection 112. [0172] Une fois la session établie avec succès avec le premier agent, le deuxième agent 123 envoie un ou plusieurs messages de souscription en positionnant les attributs précités (étape référencée 51 sur la figure 5, similaire à l'étape 212 de la figure 2). Un identifiant peut notamment être associé à la demande de souscription. L'identifiant de souscription peut être associé à un état « demande en cours » (50) dans une base de données de souscription, par exemple la base 24 selon la figure 2. [0173] A réception d'un message de souscription par le premier agent 113 (étape référencée 41 sur la figure 4, similaire à l'étape 213 de la figure 2), celui-ci peut procéder aux vérifications de sécurité (42) pour s'assurer que le deuxième agent 123 est autorisé à souscrire à au moins un service de partage d'informations proposé par le premier service de protection. On note que la politique de souscription à un service de partage d'informations peut avoir été préalablement définie (40). [0174] En cas d'échec des contrôles de sécurité (43), le message de souscription est ignoré par le premier agent 113. [0175] En cas de succès des contrôles de sécurité (44), le premier agent 113 extrait les in- formations incluses dans le message de souscription pour identifier l'agent émetteur du message de souscription (i.e., le deuxième agent 123), et, par exemple, identifier le service de protection pour lequel il est utilisé (i.e., le deuxième service de protection 122), déterminer le type de service de partage d'informations demandé (i.e., la valeur du paramètre « Service_Type »), déterminer la nature des notifications (i.e., la valeur du paramètre « Verbose_Mode »), déterminer la durée de validité de la souscription, etc. [0176] Ces informations sont ensuite sauvegardées dans une base de données de sous- cription, par exemple la base 24 selon la figure 2, par exemple avec l'identifiant de 17 souscription. [0177] Le premier agent vérifie également si le message de souscription concerne une nouvelle souscription (45). 101781 Si le message de souscription concerne une nouvelle souscription, provenant par exemple d'un agent utilisé par un service de protection distinct, un nouvel identifiant de souscription est crée (46) et enregistré dans la base de données de souscription. [0179] Si le message de souscription concerne une souscription existante, par exemple un deuxième message de souscription provenant du deuxième agent 123 pour apporter des informations complémentaires, la base de données de souscription est mise à jour (47). [0180] Le premier agent 113 peut ensuite répondre à l'agent ayant émis le ou les messages de souscription. [0181] Par exemple, le premier agent 113 envoie un message d'acceptation ACK pour confirmer la souscription. Le premier agent 113 peut alternativement envoyer un message d'erreur si, par exemple, le service de partage d'informations souhaité par le deuxième agent 123 n'est pas supporté par le premier service de protection 112 ou si le premier agent 113 est surchargé, etc. [0182] La réception (52) du message d'acceptation ACK par l'agent ayant émis le ou les messages de souscription indique que la souscription s'est déroulée avec succès. [0183] Eventuellement, le deuxième agent 123 peut vérifier (53) si le message d'acceptation ACK reçu du premier agent 113 correspond bien à la demande de souscription émise par le deuxième agent 123, en consultant la base de données de souscription 24. [0184] Si la confirmation ne correspond pas à la souscription (54), le message d'acceptation ACK est ienoré. [0185] Si la confirmation correspond à la souscription (55), la souscription s'est déroulée avec succès, et l'identifiant de souscription est associé à un état « confirmé » dans la base de données de souscription 24. [0186] Le deuxième agent 123 reste ensuite en attente (56) d'informations en provenance du premier agent 113, notamment au cas où une attaque serait identifiée par le premier agent 113. [0187] Selon un mode de réalisation particulier, afin de maintenir la souscription active, le deuxième agent 123 envoie un nouveau message de souscription avant l'expiration de la durée de validité de la souscription définie dans le message de souscription. Si aucun message n'est envoyé avant l'expiration de cette durée de validité, le premier agent 113 peut supprimer la souscription conespondante de la base de données de souscription 24. [0188] Les étapes présentées ci-dessus peuvent également être mises en oeuvre en inversant le sens des messages si le premier agent 113 souhaite souscrire à au moins un service de partage d'informations proposé par le deuxième service de protection 122. Dans ce 18 cas, c'est le premier agent 113 qui envoie au moins un message de souscription au deuxième agent 121 [0189] Deux agents utilisés par des services de protection distincts peuvent également s'échanger mutuellement des messages de souscription « SUBSCRIBE0 ». [0190] 5.2.4 Utilisation du service de protection distant [0191] On se place à nouveau dans le cas décrit précédemment en relation avec les figures 4 et 5 selon lequel le deuxième agent 123 envoie un ou plusieurs messages de souscription au premier agent 113. [0192] Quand le premier agent 113 du premier service de protection 112 identifie une attaque qui correspond aux règles indiquées par le deuxième agent 123 dans le message de souscription et conformes à des politiques locales, le premier agent 113 envoie un ou plusieurs messages de notification au deuxième agent 123 pour l'alerter de cette attaque, directement ou via au moins un agent intermédiaire utilisé par au moins un répartiteur. [0193] Par exemple, comme illustré en figure 6, le premier service de protection 112 détecte une attaque sur au moins une ressource du premier réseau 111 qu'il protège, en provenance des sources S 1 141, S2 142, ..., Sk 14k, connectées au premier réseau III par l'intermédiaire du réseau Internet 13 via de fournisseurs d'accès AP #1 151 et AP #m 15m. [0194] Sur détection de cette attaque DDoS à grande échelle, le premier agent 113 du premier service de protection 112 envoie un message de notification (« NOTIFYQ vers le deuxième agent 123 du deuxième service de protection 122, pour que celui-ci soit informé de l'attaque en cours et puisse engager des actions permettant d'éviter, ou de réduire, le risque que les ressources du deuxième réseau 121 qu'il protège subissent à leur tour la même attaque que les ressources du premier réseau 111. [0195] Par exemple, le deuxième agent 123 peut prendre les mesures nécessaires pour filtrer le trafic en provenance des sources S1 141, S2 142, Sk 14k. [0196] Ainsi, comme illustré en figure 7, le trafic en provenance des sources S1 141, S2 142, Sk 14k et à destination du deuxième réseau 121 est bloqué en amont, car le deuxième service de protection 122 a déjà été mobilisé pour prendre les mesures adéquates suite à la notification reçue de la part du premier service de protection 112. [0197] Par exemple, le message de notification est noté NOTIFY0 et comprend au moins un attribut, ou paramètre, portant une information de type : [0198] - SUBSCRIPTION_ID : information relative à la souscription, par le deuxième agent 123, à au moins un service de partage d'informations proposé par le premier service de protection 112, tel qu'un identifiant de souscription défini lors de la souscription ; [0199] - ATTACK _ID identifiant d'attaque, par exemple généré par le premier agent 113 émetteur du message de notification. Selon un mode de réalisation particulier, le même 19 identifiant est utilisé pendant la durée de vie d'une attaque ; [0200] - ATTACK_DESCRIPTOR information de description technique de l'attaque. Par exemple, ce champ peut inclure un numéro de protocole, un ou plusieurs numéros de port, les machines impliquées dans l'attaque, la direction du trafic (entrant ou sortant), etc., ou une combinaison de ces informations. A noter que la description technique peut indiquer une ou plusieurs machines concernées par l'attaque (par exemple machine_x,sonstructeur_y,_release_z) [0201] - STATUS : information relative à l'état de l'attaque. A titre d'exemple, ce paramètre peut prendre les valeurs suivantes : [0202] i. 0 : l'attaque est toujours active [0203] ii. 1 : l'attaque a été bloquée avec succès ; [0204] iii. etc. [0205] - LOCAL_MITIGATION : information indiquant si une ou plusieurs actions de mi- tigation sont mises en oeuvre localement par le premier service de protection. Aussi, cc champ porte une description technique des actions de mitigation mises en oeuvre par le service de protection de l'agent émetteur du message de notification. Selon un mode de réalisation particulier, ces informations relatives aux actions de mitigation sont partagées à titre informel, et l'agent récepteur du message de notification peut les ignorer. Les actions de mitigation peuvent être génériques (par exemple configuration YANG) ou spécifiques à un constructeur (par exemple fichier de configuration spécifique à « machine_x,_constructeur_y,_release_z ») ; [0206] - SOS : demande d'assistance pour traiter l'attaque. A titre d'exemple, ce champ est positionné à « VRAI » pour demander à un service de protection distant de l'assistance pour mettre fin à l'attaque en cours ; [0207] - etc. [0208] Les messages de notification peuvent être de différentes natures (par exemple STATUS, LOCAL_MITIGATION, SOS, etc.). [0209] Par exemple, le premier agent 113 peut envoyer au deuxième agent 123, directement ou via au moins un agent intermédiaire utilisé par au moins un répartiteur, un ou plusieurs messages de notification décrivant les caractéristiques d'une attaque : NOTIFY(ATTACICD), NOTIFY(ATTACK_ID'kTTACK_DESCREPTOR) ou NOTIFY(ATTACK_ID, STATUS). [0210] Selon un autre exemple, le premier agent 113 peut envoyer au deuxième agent 123, directement ou via au moins un agent intermédiaire utilisé par au moins un répartiteur, un ou plusieurs messages de notification décrivant une action de mitigation locale, telle qu'activée par le premier service de protection 112 du premier agent 113 émetteur du message de notification : NOTIFY (ATTACICID, LOCAL_MITIGATION). [0211] Selon encore un autre exemple, le premier agent 113 peut envoyer au deuxième agent 20 123, directement ou via au moins un agent intermédiaire utilisé par au moins un répartiteur, un ou plusieurs messages de notification demandant de l'assistance pour la mitigation de l'attaque : NOTIFY (ATTACK_ID, SOS). 10212] On note que la description d'une attaque peut varier pendant la durée de vie d'une telle attaque. Par exemple, de nouvelles sources peuvent être impliquées, d'autres protocoles peuvent être exploités, etc. Il est donc souhaitable de pouvoir identifier l'attaque, par exemple au moyen de l'attribut persistant ATTACK_ID, pour suivre son évolution. [0213] Ainsi, plusieurs messages de notification peuvent être envoyés pour notifier les agents ayant souscrit au service de partage d'informations proposé par le premier service de protection, des mises à jour de la description de l'attaque. Par exemple, des messages NOTIFY (ATTACK_ID=Ial , ATTACK_DESCRIPTOR= DESC #1), NOTIFY (ATTACK_ID=1D1, ATTACK_DESCRIPTOR= DESC #2), et NOTIFY (ATTACK_ID=ID1, ATTACK_DESCRIPTOR= DESC #s) sont successivement transmis du premier agent 113 vers le deuxième aszent 123. [0214] Les agents ayant souscrit au service de partage d'informations proposé par le premier service de protection peuvent ainsi mettre à jour leurs filtres en fonction des mises à jour de l'attaque. [0215] Par ailleurs, selon au moins un mode de réalisation, l'attribut ATTACK_DESCRIPTOR de description de l'attaque peut également être utilisé pour corréler différents messages de notification reçus depuis différents services de protection. [0216] Par exemple, si le deuxième agent 123 du deuxième service de protection 122 reçoit d'une part un message de notification NOTIFY (ATTACK_ID=ID1, ATTACK_DESCRIPTOR= DESC #m) en provenance du premier agent 113 du premier service de protection 112, et d'autre part un message de notification NOTIFY (ATTACK_ID=ID2, ATTACK_DESCRIPTOR= DESC #m) en provenance d'un agent d'un autre service de protection, le deuxième agent 123 peut associer ces deux notifications, ayant des identifiants distincts, à une même attaque grâce aux informations incluses dans le champ ATTACK_DESCRIPTOR. Il est ainsi possible de corréler les informations reçues de différents agents, ce qui permet notamment de confirmer la réalité ou l'étendue d'une attaque. [0217] On présente ci-après des exemples de messages de notification pouvant être envoyés successivement pour caractériser les différentes phases d'une attaque : [0218] - NOTIFY(ATTACK_ID=ID1, ATTACK_DESCRIPTOR, STATUS=0) est envoyé pour notifier une attaque en cours ; [0219] - NOTIFY(ATTACK_ID=ID1, SOS=1) est envoyé pour demander de l'assistance aux autres services de protection ; 21 [02201 - NOT1FY(ATTACK JD=1D1, STATUS=1) est envoyé pour notifier qu'une attaque a été bloquée avec succès ; [02211 - NOT1FY(ATTACK_ID=1D1, LOCAL_M1T1GAT1ON) est envoyé pour informer les autres services de protection qu'une action de mitigation est mise en oeuvre lo- calement par le service de protection qui utilise l'agent émettant le message de notification). [0222] Différentes informations peuvent éventuellement être agrégées dans un même message de notification, par exemple : [0223] - NOTIFY(ATTACK_ID=1D2, ATTACK_DESCRIPTOR, LOCAL_ MITIGATION, STATUS=1) est envoyé pour notifier qu'une attaque a été bloquée avec succès (STATUS=1). Le message indique aussi qu'une action de mitigation est mise en oeuvre localement (LOCAL_MITIGATION) ; [0224] - NOTIFY(ATTACK_ID=ID2, ATTACK_DESCRIPTOR, STATUS=0, SOS=1) est envoyé pour demander de l'assistance aux autres services de protection (SOS=1) pour traiter une attaque en cours (STATUS=0). [0225] On présente désormais, en relation avec les figures 8 et 9, les principales étapes mises en oeuvre par les premier et deuxième agents pour la phase de notification, selon au moins un mode de réalisation. Plus précisément, la figure 8 illustre les étapes mises en oeuvre par le premier agent 113 utilisé par un premier service de protection 112, pour identifier une attaque et en informer le deuxième agent 123, et la figure 9 illustre les étapes mises en oeuvre par le deuxième agent 123, recevant l'information d'attaque et déterminant une action à effectuer. [0226] Comme illustré en figure 8, le premier agent 113 peut identifier une attaque (étape ré- férencée 81 sur la figure 8, similaire à l'étape 221 de la figure 2). Par exemple, l'attaque peut être détectée par le premier agent 113, par un autre agent utilisé par le premier service de protection 112, ou être détectée par un noeud du réseau 111 protégé par le premier service de protection 112. [0227] On note que la politique d'identification des attaques pour lesquelles au moins un deuxième agent (par exemple le deuxième agent 123) a souscrit à au moins un service de partage d'informations du premier service de protection peut avoir été préalablement définie (80). Dans ce cas, au cours de l'étape 81, le premier agent 113 identifie une attaque correspondant à cette politique. [0228] Le premier agent 113 peut alors identifier (82) au moins un service de protection, et par exemple tous les services de protection, utilisant un agent ayant souscrit à au moins un service de partage d'informations du premier service de protection. [0229] Pour ce faire, le premier agent 113 peut consulter la base de données de souscription 24. [0230] Le premier agent 113 peut alors envoyer des messages de notification aux agents 22 ayant souscrit à au moins un service de partage d'informations proposé par le premier service de protection (étape référencée 83 sur la figure 8, similaire à l'étape 222 de la figure 2). l02311 Selon un mode de réalisation particulier, le premier agent 113 peut envoyer (84) plusieurs messages de notification, notamment lorsque l'attaque est modifiée, pour informer les agents ayant souscrit à au moins un service de partage d'informations proposé par le premier service de protection et leur permettre de mettre à jour leurs filtres. Un délai est observé entre deux notifications consécutives envoyées vers un même agent distant. [0232] A réception d'un message de notification (étape référencée 91 sur la figure 9, similaire à l'étape 223 de la figure 2), un agent d'un service de protection ayant souscrit à au moins un service de partage d'informations proposé par le premier service de protection, par exemple le deuxième agent 123, procède aux vérifications de sécurité (92) pour s'assurer que le premier agent 113 est autorisé à envoyer des messages de notification. [0233] Pour ce faire, le deuxième agent 123 peut consulter la base de données de sous- cription 24. [0234] En cas d'échec des contrôles de sécurité (93), le message de notification est ignoré par le deuxième agent 123. [0235] En cas de succès des contrôles de sécurité (94), le deuxième agent 123 extrait les in- formations incluses dans le message pour identifier l'agent émetteur du message de notification (i.e., le premier agent 113), et, par exemple, identifier le service de protection auquel il appartient (i.e., le premier service de protection 112), déterminer la nature des notifications (i.e., SOS. STATUS, LOCAL_MITIGATION, etc.). A partir de la ou des informations extraites, et notamment de la nature des notifications, le deuxième agent 123 peut déterminer au moins une action à effectuer. [0236] Par exemple, si le message de notification informe le deuxième agent 123 qu'une attaque est en cours, alors les informations caractéristiques de l'attaque sont extraites du message de mitigation (95) et relayées vers une entité en charge de la mitigation (« mitigator ») du deuxième service de protection 112 qui met en oeuvre le deuxième agent 123, pour qu'il prenne les mesures de protection ad hoc afin d'anticiper l'attaque (96). Selon un mode de réalisation particulier, ces actions peuvent s'inspirer de celles indiquées dans le message de notification si le champ LOCAL_MITIGATION a été renseigné. [0237] Si le message de notification inclut une demande d'assistance pour traiter une attaque en cours, le deuxième agent 123 peut vérifier si des actions locales au deuxième service de protection peuvent être engagées (97). Le deuxième agent 123 peut envoyer un message de partage d'actions « SHARE_ACTIONO » au premier agent 113, di- 23 rectement ou via au moins un agent intermédiaire utilisé par au moins un répartiteur, pour partager un plan de mitigation avec le premier service de protection et mettre en oeuvre localement des actions de mitigation (98). Par exemple, le deuxième agent 123 peut envoyer au premier agent 113, émetteur du message de notification, au moins un message de partage d'actions SHAREACTION(ATTACK_TD, LOCAL_MITIGATION). Le plan de mitigation partagé à l'aide du message SHARE_ACTIONO n'est pas nécessairement mis en oeuvre par le service de protection émetteur, mais petit être rapatrié depuis une base de données capitalisant des BCP (en anglais « Best Current Praetiees ») ou des expériences passées pour des attaques similaires. [0238] Le plan de mitigation peut correspondre à des actions de filtrage, la mise à dis- position de ressources pour la redirection des flux, etc. [0239] Un exemple de plan d'action de mitigation simplifié est présenté ci-dessous : [0240] [Tableaux l] 4)1,4> tcp 1.2.3.0/24 inbound dropcforwarding> 24 [02411 En particulier, dans le mode de transmission « fédération », mettant en oeuvre au moins un répartiteur, le message de partage d'action SHARE_ACTION peut être diffusé vers le premier service de protection ayant sollicité une demande d'assistance, ainsi que vers d'autres services de protection faisant partie de la même fédération. [0242] Par exemple, le message de partage d'action SHARE_ACTION(ATTACK_ID=ID1) est transmis du deuxième agent 123 vers un répartiteur FD, puis du répartiteur FD vers le premier agent 113 et vers au moins un autre agent d'un service de protection distinct faisant partie de la même fédération. [0243] Quelque soit le mode de transmission, le premier agent 113 peut donc rester en attente d'un message de partage SHARE_ACTION (étape référencée 85 sur la figure 8). A réception d'un tel message, le premier agent 113 peut extraire les informations véhiculées par ce message (86) pour partager un plan de mitigation avec le deuxième service de protection et mettre en oeuvre localement des actions de mitigation (87). [0244] On note que les étapes présentées ci-dessus en relation avec les figures 8 et 9 peuvent également être mises en oeuvre en inversant le sens des messages si le premier agent 113 a souscrit à au moins un service de partage d'informations proposé par le deuxième service de protection 122. Dans ce cas, c'est le deuxième agent 123 qui envoie au moins un message de notification au premier agent 113. [0245] 5.2.5 Infarmation des fimmisseurs d'accès [0246] On présente ci-après un mode de réalisation particulier, mis en oeuvre par un agent d'un service de protection tel que décrit précédemment, permettant d'identifier au moins un fournisseur d'accès responsable d'au moins une ressource impliquée dans la propagation du trafic caractéristique de l'attaque. [0247] En effet, l'identification d'un tel fournisseur d'accès permet de lui transmettre une demande de filtrage du trafic caractéristique de l'attaque. [0248] De cette façon, les services de protection peuvent collaborer avec les fournisseurs d'accès pour bloquer en amont des machines impliquées dans une attaque, permettant ainsi de limiter la propagation de l'attaque. [0249] En effet, l'activation de filtres locaux à chaque service de protection ne permet pas de bloquer systématiquement une attaque à l'échelle de l'Internet. De plus, et étant donné le nombre important de machines sources qui peuvent être impliquées dans une attaque, un nombre important de filtres peut être requis. Or l'application de ces filtres a une incidence sur les performances des routeurs et pare-feu. [0250] Les agents des services de protection tels que décrits précédemment peuvent collaborer avec les fournisseurs d'accès pour bloquer en amont les machines injectant du trafic caractéristique d'une attaque dès que possible de façon à limiter la propagation du trafic caractéristique de l'attaque. Selon un mode de réalisation particulier, ces fournisseurs d'accès pourront ensuite empêcher ces machines de se connecter au(x) 25 réseau(x) d'accès, en refusant de leur allouer des adresses/préfixes IP par exemple. [0251] On suppose par exemple que les -fournisseurs d'accès disposent d'une interface de programmation (API) pour offrir à des tiers des services à valeur ajoutée, tels que le filtrage des adresses. [0252] Par exemple, un agent d'un service de protection tel que décrit précédemment détermine l'identité du fournisseur d'accès responsable d'une ressource IP impliquée dans une attaque. Pour ce faire, l'agent d'un service de protection (par exemple, celui ayant identifié une attaque) interroge par exemple la base de données maintenue, par exemple, par le registre régional RIPE (Réseaux IP Européens). [0253] Un exemple de requête utilisant les ressources de la base de données RIPE pour récupérer l'identité du fournisseur d'accès qui gère la ressource IP « 80.12.102.157 » est donné ci-après : [0254] https://apps.db. ripe. net/db-web- ni/equery?searchtext=.80. 12. 102.157#resultsSecuon [0255] Comme indiqué ci-dessus, ce mode de réalisation suppose que les fournisseurs d'accès exposent une interface de programmation (API) pour offrir à des tiers des services à valeur ajoutée, par exemple dans un ou plusieurs serveurs de validation hébergés par ces fournisseurs d'accès. [0256] Si les fournisseurs d'accès exposent une telle API, et si la base de données RIPE est modifiée pour renseigner le/les serveur(s) de validation, la réponse à cette requête indique que la ressource IP « 80.12.102.157 » est allouée, selon cet exemple, au fournisseur d'accès « Orange S.A. », et que le ou les serveur(s) de validation sont localisés par les adresses « 80.12.102.15 » et « 80.12.102.16 ». [0257] Un exemple de réponse à la requête est donné ci-après [0258] Responsible organisation.: Orange S.A. [0259] inetnum: 80.12.102.144 - 80.12.102.159 [0260] validation server(s): 80.12.102.15, 80.12.102.16 [0261] fientante: VISION [0262] descr: France Telecom NDC [0263] country: FR [0264] admis-c: FTO9-RIPE [0265] tech-c: FTO9-RIPE [0266] status: ASS1GNED PA [0267] mnt-by: FT-BRX [0268] created: 2014-11-20T10:56:45Z [0269] last-modified: 2018-02-09T15:00:11Z [0270] source: RIPE [0271] La réponse précise en particulier que le/les serveurs de validation pour cette plage d'adresses « 80.12.102.157 » est joignable avec deux adresses : « 80.12.102.15 » et 26 « 80.12.102.16 ». [0272] Une fois cette adresse récupérée, l'agent du service de protection peut envoyer une demande de filtrage au fournisseur d'accès, par exemple sous la forme d'un message ACTION_REQUESTO. [0273] Sur réception du message ACTION_REQUESTO, le fournisseur d'accès procède à des vérifications, permettant notamment de vérifier que l'agent ayant émis la demande de filtrage est une entité de confiance. [0274] En cas de succès des vérifications, le fournisseur d'accès peut envoyer un message ACTION_REPLY à l'agent. Le service de protection auquel appartient l'agent peut alors activer certains filtres pour bloquer le trafic provenant de la machine malveillante. On note que ce filtrage peut être mis en oeuvre immédiatement ou après une phase d'observation. [0275] Les figures 10 et 11 illustrent la mise en oeuvre d'une telle solution permettant à un fournisseur d'accès de filtrer le trafic caractéristique d'une attaque. [0276] Comme illustré en figure 10, on considère le premier service de protection 112 protégeant le premier réseau 111, connecté au réseau Internet 13, et les sources Si 141 à Sk 14k également connectées au réseau Internet 13 par l'intermédiaire des fournisseurs d'accès AP#1 151 à AP#n 15n. Si l'on considère que tous les fournisseurs d'accès AP#I 151 à AP#n 15n mettent en place la solution décrite ci-dessus, des actions de filtrage peuvent être réparties entre tous les fournisseurs d'accès, pour bloquer le trafic caractéristique d'une attaque en amont du réseau Internet 13. [0277] Comme illustré en figure 11, cette solution présente un intérêt même lorsque tous les fournisseurs d'accès ne mettent pas en place la solution décrite ci-dessus. En effet, à partir du moment où certains fournisseurs d'accès mettent en place la solution décrite ci-dessus, par exemple les fournisseurs d'accès AP#1 151 et AP#n 15n, les services de protection, comme le premier service de protection 122, ont une liste limitée de filtres à gérer. [0278] 5.3 Structures [0279] On présente finalement, en relation avec la figure 12, la structure simplifiée d'un agent selon au moins un mode de réalisation décrit ci-dessus. [0280] Un tel agent comprend une mémoire 101 comprenant une mémoire tampon, une unité de traitement 102, é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 103, mettant en oeuvre des étapes du procédé de collaboration ou de demande de collaboration selon au moins un mode de réalisation de l'invention. [0281] A l'initialisation, les instructions de code du programme d'ordinateur 103 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 102. 27 [0282 Le processeur de l'unité de traitement 102 met en oeuvre des étapes du procédé de collaboration ou de demande de collaboration décrit précédemment, selon les instructions du programme d'ordinateur 103, pour : l02831 - identifier une attaque sur au moins une ressource gérée par un domaine protégé par un service de protection local, et transmettre, à au moins un agent utilisé par un service de protection distant, au moins une information relative à l'attaque identifiée, et/ou [0284] - recevoir au moins une information relative à une attaque identifiée par un agent utilisé par un service de protection distant, et déterminer au moins une action à effectuer, à partir de la ou des informations relatives à ladite attaque. [0285] 5.4 Variantes [0286] La solution de collaboration entre services de protection présentée ci-dessus peut être mise en oeuvre dans différents contextes, par exemple : [0287] - le service de protection est géré par l'administrateur de l'infrastructure réseau à protéger ; [0288] - le service de protection est géré par une autre entité que l'administrateur de l'infrastructure réseau à protéger ; [0289] - le service de protection est activé au sein de l'infrastructure réseau à protéger ; [0290] - le service de- protection est activé en dehors de l'infrastructure réseau à protéger (typiquement, fournisseur d'accès, opérateur de transit, opérateur de service, fournisseur de services « cloud ») ; [0291] - l'infrastructure réseau à protéger peut être un réseau d'opérateur, un réseau d'entreprise, un réseau de client résidentiel, une flotte de mobiles 5G, etc. ; [0292] - l'infrastructure réseau à protéger peut être utilisée pour fournir un ensemble de services, comprenant par exemple un service de connectivité (service de transfert de paquets, typiquement), un service de réseau privé virtuel (« Virtual Private Network » (VPN) en anglais) ou d'autres services à valeur ajoutée, tels que des services de téléphonie, de diffusion de programmes télévisés (service IPTV), de télémétrie IoT (« Internet of Things »), etc. ; [0293] - plusieurs infrastructures réseaux peuvent solliciter le même service de protection ; [0294] - une infrastructure réseau peut invoquer les services d'un ou plusieurs services de protection ; ces services de protection peuvent protéger des attaques de natures différentes ou être associés à des services distincts, par exemple selon les profils de trafic caractéristiques des différents services supportés par l'infrastructure réseau ; [0295] - les sources d'une attaque peuvent être aussi des ressources hébergées au sein de l'infrastructure réseau à protéger, ce qui peut être le cas des attaques de type « Man-in-the-Middle » (MITM), par exemple ; [0296] - etc. [0297] En particulier, un opérateur réseau qui applique des filtres (ou liste de contrôle 28 d'accès «ACL _>]), typiquement sur des routeurs et pare-feu, peut également être considéré comme un fournisseur de service de protection dans le cadre de l'invention. [0298] Selon au moins un mode de réalisation, la solution de collaboration entre services de protection proposée permet : [0299] - de lancer rapidement des actions pour la mitigation d'attaques de façon à limiter la propagation de ces attaques et par conséquent, d'en atténuer l'amplitude, et/ou [0300] - de mobiliser l'ensemble des acteurs impliqués dans la mitigation de telles attaques : les services de protection, mais également les fournisseurs de services responsables des réseaux auxquels la source à l'origine de l'attaque s'est connectée, et/ou [0301] - de communiquer à l'ensemble des services de protection du réseau de commu- nication l'ensemble des informations caractéristiques d'une attaque dès que celle-ci est détectée. La propagation de telles informations permet en effet une mise en alerte rapide (voire instantanée) des services de protection du réseau de communication afin de faciliter une gestion globale et cohérente de l'attaque- et de sa mitigation tout en réduisant le risque et la gravité des dommages que pourrait infliger une telle attaque, et/ou [0302] - de mettre en place des politiques de filtrage coordonnées et globalement cohérentes. De telles politiques permettent d'installer des filtres aux endroits appropriés et ainsi d'optimiser la distribution des listes de contrôle d'accès sans pénaliser les performances des systèmes (routeurs, par exemple), sur- lesquels ces filtres sont installés. 29 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5]