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

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 Download PDF

Info

Publication number
WO2023117802A1
WO2023117802A1 PCT/EP2022/086477 EP2022086477W WO2023117802A1 WO 2023117802 A1 WO2023117802 A1 WO 2023117802A1 EP 2022086477 W EP2022086477 W EP 2022086477W WO 2023117802 A1 WO2023117802 A1 WO 2023117802A1
Authority
WO
WIPO (PCT)
Prior art keywords
mitigation
server
mitigation server
domain
client
Prior art date
Application number
PCT/EP2022/086477
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Original Assignee
Orange
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 filed Critical Orange
Publication of WO2023117802A1 publication Critical patent/WO2023117802A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud

Definitions

  • the field of the invention is that of communications established on a network, for example an IP network, and in particular that of value-added IP services.
  • the invention finds applications in particular in the field of mitigating attacks by distributed denial of service (DDoS, for "Distributed Denial of Service”), implementing for example, but not exclusively, an architecture of the DOTS type (in English “DDoS Open Threat Signaling”), as standardized by the IETF, or the mitigation of intrusion attacks.
  • DDoS distributed denial of service
  • DOTS distributed Denial of service
  • the invention offers a solution making it possible to facilitate the coordination of the mitigation actions undertaken in order to counter computer attacks impacting a client domain.
  • a DDoS attack is an attempt to make resources, for example network or computing resources, unavailable to their users.
  • resources for example network or computing resources
  • Such attacks can be massively deployed by compromising a large number of hosts, and using these hosts to amplify the attacks.
  • tunnels through which the traffic originating from or intended for a site or a network is routed.
  • Such tunnels thus constitute a traffic transport resource that the DPS service can then inspect.
  • the establishment and use of tunnels considerably increases the latency observed by users and imposes constraints on the sizing of the DPS service to be able to handle all the traffic coming from or intended for all user terminals of such tunnels.
  • said tunnels are considered potential attack vectors.
  • DOTS architecture In order to help identify suspicious traffic, a specific architecture has been standardized within the IETF, called the DOTS architecture. Such an architecture allows a client node, called DOTS client, to inform a mitigation server, called DOTS server, that it has detected a DDoS attack and that appropriate mitigation actions are required.
  • DOTS client a client node
  • DOTS server a mitigation server
  • a DOTS client When a client domain is the target of a DDoS attack, a DOTS client forming part of this client domain can thus send a message to a DOTS server to request help.
  • the latter coordinates, with a mitigation entity (“mitigator”), the actions to be taken so that the traffic of the denial of service attack is no longer routed to the client domain, while the legitimate traffic continues to be routed normally to the client domain.
  • the DOTS architecture is based on the use of two communication channels for the exchange of signaling messages between a DOTS client and a DOTS server:
  • DOTS Data Channel (“DOTS Data Channel”)
  • DOTS Signal Channel in English “DOTS Signal Channel”.
  • the DOTS data channel can be used when no DDoS attack is detected by a DOTS client, in particular to facilitate the implementation of preventive actions, such as the installation of traffic filters.
  • the data channel can also be used to pre-install filter rules to be activated during a mitigation (for example, to identify a part of the traffic which should not be deleted by the mitigation actions).
  • a DOTS client can use this channel to install filtering rules for traffic received from certain addresses or that destined for a given node, or to instruct the server to block all traffic destined for the prefix "1.2.3.0/24 or all UDP traffic destined for port number 443, commonly used by denial of service attacks.
  • the DOTS signaling channel for its part, is used particularly when a DDoS attack is in progress.
  • a DOTS client can use this channel to request assistance from from the DOTS server.
  • a DOTS client uses the signaling channel to send a mitigation request to the server informing it that the prefix "1.2.3.0/24" is under DDoS attack, so that the server can take action to terminate the attack. 'offensive.
  • CUID Client Unique IDentifier
  • the mitigation entity If the mitigation entity is not co-located with the DOTS server, the latter relays the request to a mitigation entity which can thus take the appropriate mitigation measures to put an end to a DDoS attack on the one hand, if the request from the DOTS client does not conflict with other requests from other DOTS clients that are part of the same client domain, or with a filter rule previously installed by the DOTS server in response to a request from another client from the same client domain, and on the other hand, if the server is authorized/configured to honor the last request received. When the DOTS server is not authorized to process such a request, it rejects it and issues an error message 4.03 (Bad Request).
  • a DOTS server refuses to process signaling messages from a DOTS client, such as an attack mitigation request sent by a DOTS client when the attack is real. , or filtering requests sent by a DOTS client (an objective of the filtering requests being to anticipate DDoS attacks).
  • a refusal may in particular occur when the client domain uses an “anycast” address to join a DOTS server or in the event of failure of an algorithm making it possible to identify an output device from the client domain, for example.
  • An “anycast” address is an address configured with several network interfaces and which therefore makes it possible to reach several devices. Thus, a data packet whose destination is an "anycast” address will be processed by a single device that has been configured with this address, but which happens to be closest to the source sending the packet within the meaning of the dynamic routing policy implemented. implemented within the network.
  • a request sent by a DOTS client of the client domain can be sent to a DOTS server which is not authorized to process it. Such a request will then be systematically rejected by said DOTS server and no mitigation action can be implemented, either preventively or curatively to mitigate a detected attack.
  • the invention meets this need by proposing a method for identifying at least one attack mitigation server authorized to protect a client domain against a computer attack.
  • Such a method is particular in that it is implemented by a first attack mitigation server and that it comprises:
  • Such a solution designated in the rest of the description by LOST (for "Liberal processing of ddos mitigation requeSTs"), makes it possible to ensure that no message requesting assistance for the management of attacks ( request for attack mitigation or implementation of filtering rules) issued by a client node does not remain unanswered even if it is transmitted to a mitigation server unable to process it.
  • any of the signaling messages mentioned before such as a solicitation message sent via the signaling channel (e.g. a request mitigation) or a solicitation message sent via the data channel (e.g. a filter request).
  • a solicitation message sent via the signaling channel e.g. a request mitigation
  • a solicitation message sent via the data channel e.g. a filter request
  • the invention was introduced with reference to the DOTS architecture, it also applies to other architectures designed for the exchange between different entities of signaling messages in connection with the management of attack traffic (preventive and/or curative management) such as, for example, architectures using signaling based on the NETCONF protocol or even other proprietary architectures designed for this purpose.
  • the solution applies independently of the internal architecture of the mitigation service. In particular, the solution applies if the mitigation actions are undertaken directly by the mitigation server that received the solicitation message or by an external entity (“mitigator”, typically) to which the solicitation message was relayed by said server mitigation.
  • a mitigation server is unable to process a solicitation message sent by the client node (e.g. an attack solicitation message), because it does not have the authorizations (or authorizations) necessary to do so.
  • a solicitation message sent by the client node e.g. an attack solicitation message
  • the mitigation server is not authorized to apply certain policies relating to resources (e.g. IP, URI, FQDN prefixes) of the client domain such as policies for routing, traffic filtering or redirection, etc.
  • the inability of the mitigation server to process the request message sent by the client node stems from the fact that it is not authorized to process this request message.
  • a mitigation server is unable to process a solicitation message sent by the client node (eg an attack mitigation request) because it does not have the structural resources ( computing capacities, network resources) and/or functional resources to do so, or an interface with an entity having such resources (eg "mitigator" mentioned above).
  • a mitigation server is designated as not being able to process the request message sent by the client node.
  • a mitigation server capable of processing a message requesting assistance for managing attacks within the meaning of the invention is, on the one hand, authorized to do so, and on the other hand, has the structural (eg hardware, software, etc.) and functional resources to do so or an interface with an external entity (eg "mitigator") having such resources.
  • a first mitigation server determines that it is not capable of processing an attack solicitation message, that is to say according to the embodiment envisaged, because that he is not authorized to do so and/or because he is not able to do so (directly or indirectly via an interface with an external entity responsible for developing and/or implementing a plan mitigation)
  • it seeks to identify a second mitigation server authorized to process the attack solicitation message it has received.
  • the first mitigation server determines that it is not capable of processing a solicitation message, that is to say, for example, that it is not not authorized to process this request, rather than rejecting this request, it will seek to identify at least one other mitigation server which would be able to process this solicitation message.
  • This other mitigation server may in turn implement the present method recursively until a mitigation server actually capable of processing the solicitation message is identified.
  • the mitigation server uses at least one identifier of the target client domain of the attack (first identifier within the meaning of the invention). This identifier is specially created to allow such identification of another mitigation server.
  • This new identifier of the client domain is associated with at least one mitigation service protecting resources of the client domain (for example, a DPS service for DDoS type attacks) and makes it possible to make the link between the client domain and at least one server attack mitigation implementing said at least one mitigation service and authorized to process a solicitation message sent by a client node of the client domain in question.
  • at least one mitigation service protecting resources of the client domain for example, a DPS service for DDoS type attacks
  • Such an identifier of the client domain to which the client node having sent the request message is attached can be common to several mitigation services (e.g. to several DPS services), for example to several mitigation services provided by the same entity. administration.
  • an identifier of the client domain to which the client node that sent the request message is attached can be specific to a mitigation service (e.g. to a DPS service) implemented, for example by the second mitigation server and will therefore not be recognized by another mitigation service implemented, for example by a third mitigation server.
  • an identifier of the client domain can be specific to a mitigation server contributing to implementing a mitigation service.
  • the first mitigation server having implemented the present solution finds itself in possession of data allowing the processing of the solicitation message which it has received but which it cannot process, thus avoiding that the latter remains unanswered. , such processing being carried out by another mitigation server (second mitigation server within the meaning of the invention).
  • At least one said first identifier of said customer domain is obtained by querying a first database using a domain name associated with said customer domain.
  • a first database maintains a register in which a domain name associated with the client domain of the client node having sent the solicitation message is associated with at least one identifier of said client domain.
  • a DNS Domain Name System
  • At least one said first identifier of said client domain is extracted from said solicitation message.
  • the first identifier in question of said client domain is conveyed in a field of the solicitation message.
  • the first mitigation server it suffices for the first mitigation server to extract this information from the solicitation message.
  • at least one said first identifier of said client domain can be obtained by the first mitigation server by means of a second identifier of said client domain extracted from the solicitation message.
  • This embodiment has a privileged application when the solicitation message includes a second identifier of the client domain common to several servers or mitigation services (i.e. which identifies several servers/mitigation services), of which the first mitigation server having received the solicitation message, and that the first mitigation server is not able to process this message. It is indeed important to be able to identify another mitigation server authorized to process it.
  • the first mitigation server can use the second identifier extracted from the request message to obtain a domain name associated with said client domain. Then, from this domain name he can, for example by querying the first database, obtain one or more identifiers of the client domain associated with the domain name obtained (first identifiers within the meaning of the invention), and from of these client domain identifiers, identify one or more mitigation servers authorized to process the solicitation message.
  • the choice of mitigation server(s) to which to direct the solicitation message for processing may depend on various parameters (mitigation policies, existing agreements with the client domain and/or between protection services, etc.)
  • the request message when the request message includes an identifier of the client domain common to several servers or mitigation services, including the first mitigation server having received the request message, and the first mitigation server does not is unable to process this message, it uses this client domain identifier to identify the other mitigation servers authorized to process the signaling message.
  • the method further comprises a step of obtaining at least one location information from said second mitigation server by querying a second database by means of said first identifier of said client domain.
  • Such location information of said second mitigation server may include at least one network address of said second mitigation server and/or at least one port number of said second mitigation server.
  • the identification and/or location information of said second server is transmitted by the first server to the client node.
  • the client node can send a new solicitation message directly to the second server.
  • the first mitigation server acts as a relay for the client node by transmitting the solicitation message to the second server.
  • This second variant has the advantage of reducing the processing time of the solicitation message.
  • the invention also relates to a method for protecting a client domain against a computer attack, said method being implemented by a client node hosted by the client domain and comprising:
  • the distinct mitigation services can for example be managed by distinct administrative entities.
  • the solicitation message comprises at least one identifier of said client domain by means of which said at least one piece of information identifying said second mitigation server is obtained by the first mitigation server.
  • the invention also relates to an attack mitigation server, called first mitigation server, authorized to protect a client domain against a computer attack, and comprising at least one processor configured to:
  • Another object of the invention relates to a client node hosted by a client domain comprising at least one processor configured to:
  • the invention also relates to a signal intended to be transmitted by a client node hosted by a client domain to at least one first attack mitigation server, said signal comprising a request message for assistance for attack management, said solicitation message comprising at least one identifier of said client domain by means of which at least one piece of information identifying at least one second mitigation server authorized to process said solicitation message can be obtained.
  • the invention finally relates to computer program products comprising program code instructions for implementing the methods as described above, when they are executed by a processor.
  • the invention also relates to a recording medium readable by a computer on which are recorded computer programs comprising program code instructions for the execution of the steps of the methods according to the invention as described below. above.
  • Such a recording medium can be any entity or device capable of storing programs.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a USB key or a hard disk.
  • such a recording medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means, so that the computer programs it contains can be executed remotely.
  • the programs according to the invention can in particular be downloaded from a network, for example the Internet network.
  • the recording medium may be an integrated circuit in which the programs are incorporated, the circuit being suitable for executing or for being used in the execution of the aforementioned methods which are the objects of the invention.
  • FIG. 1 this figure represents different equipment of a communication network implementing a method for identifying at least one mitigation server according to one embodiment of the invention
  • FIG. 2 this figure represents the main steps of the processes for identifying at least one server for mitigation and protection of a client domain against a computer attack which is the subject of this solution,
  • FIG. 3 this figure represents the simplified structure of a client node according to one of the embodiments of the present invention
  • FIG. 4 this figure represents the simplified structure of a mitigation server according to one of the embodiments described above.
  • the general principle of the invention is based on the ability of an attack mitigation server to determine that it is not capable of processing a message requesting assistance in attack management, such as an attack mitigation request issued by a client node of a client domain which is the target of an attack in progress or a filtering request to be activated in the event of a proven attack, etc.
  • the mitigation server relies on local information (e.g. authorizations preconfigured by an administrator) or retrieved via dedicated interfaces from external entities (e.g. to an external “mitigator”, a database) .
  • These interfaces are for example similar or identical to those of Figure 1 of the RFC 8811 document published by the IETF and entitled "DDos Open Threat Signaling (DOTS) Architecture", August 2020.
  • a DOTS architecture as introduced previously is envisaged.
  • a prompt may be, in this context, a DOTS request.
  • DOTS request can be for example:
  • an alias management message for example intended to associate an identifier with one or more network resources located in the customer's domain
  • a signaling message to request the mitigation of a denial of service attack from a DOTS server, the mitigation server being able, upon receipt of such a message, to trigger the actions necessary to put an end to the attack (including coordination with an external entity such as a "mitigator"),
  • the inability of a mitigation server to process such a request message can have different origins.
  • the mitigation server is unable to process a solicitation message sent by the client node (e.g. an attack solicitation message), because it does not have authorizations (or authorizations) necessary to do so. This is the case, for example, when the mitigation server is not authorized to apply certain policies relating to resources of the client domain such as routing, filtering or traffic redirection policies, etc. It is then said that the mitigation server is not authorized to process the request message sent by the client node.
  • a mitigation server may be unable to process a solicitation message sent by the client node (eg an attack mitigation request) because said server and/or the entities to be applied in the implementation of mitigation actions do not have the structural (eg computing capacity, network resources) and/or functional resources to do so. Such a mitigation server is then designated as not being able to process the solicitation message sent by the client node.
  • a mitigation server may be unable to process a solicitation message sent by the client node either because it is not authorized to do so, or because it does not is not fit to do so.
  • a mitigation server capable of processing a message requesting assistance for the management of attacks within the meaning of the invention is on the one hand authorized to do so and on the other hand, has the structural (e.g. hardware, software, etc.) and functional resources to do so.
  • a first mitigation server determines that it is not capable of processing a solicitation message, for example here because it is not authorized to do so, it seeks to identify a second mitigation server authorized to process the solicitation message that it has received.
  • first client domain 11 comprising one or more machines (computer devices), also called nodes.
  • domain means a set of machines or nodes placed under the responsibility of the same administrative entity.
  • THE client domain 11 comprises for example several client nodes C1, C2, C3 and Cm, m designating an integer greater than or equal to 1, communicating with a first mitigation server S12.
  • the first mitigation server S12 belongs to a first server domain 12, while a second mitigation server S13 belongs to a second server domain 13 and a third mitigation server S14 belongs to a third server domain 14.
  • Each of these server domains 12, 13, 14 contribute to the implementation of a DPS service making it possible in particular to distinguish “legitimate” traffic, Le., the data consented to by the user, from “suspicious” traffic.
  • the server domains 12, 13 and 14 are managed by distinct administrative entities. However, as a variant, they can be managed by the same administrative entity.
  • a single mitigation server associated with each DPS service and with each server domain is considered. However, it is possible as a variant to envisage several mitigation servers per server domain, these being able to be configured to protect distinct resources or common resources of the client domain 11.
  • a DPS service can be hosted within the infrastructures operated by the access providers or in the “cloud” (in French “cloud”).
  • a client domain such as client domain 11 interfaces with one or more server domains 12, 13. DPS services.
  • the detection of an attack can be performed by a DOTS client node of the client domain concerned by the attack, such as the client node C1, or by means of a dedicated function, called DDoS detector (DDoS Detector, in English), or both.
  • DDoS detector DDoS Detector
  • one or more DDoS detectors can be activated within a single DOTS customer domain.
  • these networks can be IP networks, mobile networks (5G, B5G , 6G), etc.
  • Examples of implementation of the invention in a DOTS type architecture are described below, according to which the client nodes C1, C2, C3 and Cm are DOTS clients and the mitigation servers S12, S13, S14 are DOTS servers.
  • the client nodes C1, C2, C3, Cm and the servers S12, S13, S14 can thus communicate via signaling channels and/or DOTS data defined in relation to the prior art, to inform the servers S12, S13, S14 by means of DOTS requests as described above that protective actions are required, such as, for example, the mitigation of attacks or the implementation of filter rules.
  • DOTS DOTS
  • present solution can be implemented within the framework of other types of architectures, such as for example proprietary architectures or architectures exploiting signaling based on the NETCONF protocol. It also applies to attacks other than DDoS attacks, such as for example intrusion attacks.
  • a DOTS domain can host one or more DOTS clients.
  • multiple client nodes in a client domain can have DOTS capabilities.
  • the DOTS communications between a client domain and a mitigation server can be direct, or established via DOTS gateways. These gateways can be hosted within the customer domain, the mitigation server domain, or both.
  • a client node of the client domain can communicate directly with the mitigation server, or transmit a request to a gateway of the client domain which communicates directly with the mitigation server or with a gateway of the domain of the mitigation server, or send a request to a gateway in the mitigation server's domain that communicates with the mitigation server.
  • a DOTS gateway located in a client domain is considered by a DOTS server as a DOTS client.
  • a DOTS gateway located in a server domain is considered by a DOTS client as a DOTS server. If there is a DOTS gateway in the domain of the mitigation server, the authentication of DOTS clients can be entrusted to the DOTS gateway of the domain of the mitigation server.
  • a DOTS server can be configured with a list of trusted DOTS gateways active within its domain and the mitigation server can delegate some of its functions to these trusted gateways.
  • the mitigation server can safely use the information provided by a gateway appearing in a list declared to the mitigation server and maintained by the latter, by means of an ad hoc authentication procedure (for example, explicit configuration of the list by the authorized administrator of the mitigation server, recovery of the list from an authentication server such as an AAA server (for “Authentication, Authorization and Accounting”), etc.).
  • an ad hoc authentication procedure for example, explicit configuration of the list by the authorized administrator of the mitigation server, recovery of the list from an authentication server such as an AAA server (for “Authentication, Authorization and Accounting”), etc.
  • DOTS architecture one or more DOTS clients in a client domain, no DOTS gateway, one or more DOTS in the client domain or in the mitigation server domain, client domain distinct from the mitigation server domain, etc.
  • each DOTS client domain such as the client domain 11
  • DADI DADI-lli identifier
  • DPS Administrative Domain Identifier assigns globally uniquely to the DOTS client domain, and defined for the purposes of the invention.
  • This DADI identifier reflects the fact that the client domain is protected by at least one DPS service and makes it possible to identify said at least one DPS service associated with the client domain.
  • a same client domain 11 can have one or more DADI DADI-lli identifier(s).
  • Such a DADI identifier therefore makes the link between a client domain, such as the client domain 11, and at least one DPS service that can be implemented in order to assist the client nodes of the client domain considered in the event of an attack. .
  • a link is subsequently used to identify at least one mitigation server implementing the DPS service in question, and capable of processing the solicitation message.
  • a mitigation server capable of processing a request message is a server authorized to do so (in other words which has the necessary authorizations to process this request message).
  • a mitigation server capable of processing a solicitation message is not only authorized to do so but also has the necessary resources to process this message or to interface with an external entity (e.g. “mitigator” ) able to handle it.
  • a single DADI identifier can be used to identify several DPS services associated with a single customer domain.
  • a client domain may have resources (e.g. IP prefixes monitored by client nodes) managed (protected) by a first mitigation server implementing a first DPS service and other resources managed by a second mitigation server implementing a second DPS service.
  • the same DADI identifier can then be used for communications with separate mitigation servers.
  • the first and the second DPS service are for example managed by separate administrative entities. However, as a variant, they can be managed by the same administrative entity.
  • a DADI identifier makes it possible, unlike other known identifiers such as CUID and CDID identifiers, to identify a client domain and not a client node.
  • the use of a customer domain identifier makes it possible to ensure that whatever the customer node (of the customer domain) at the origin of the transmission of the solicitation message, it is sent to a mitigation server which, failing to be able to process it, will implement the present solution making it possible to identify a mitigation server authorized to process the solicitation message.
  • an identifier of a client node is used. Indeed, client nodes belonging to the same client domain can be managed by different mitigation servers. If we limit our to the use of an identifier of a client node, another mitigation server will not be able to process the request message because it is not authorized to do so and thus the request message will remain without answer. [0081] Moreover, such a CDID identifier cannot be used to identify another authorized mitigation server because this CDID identifier is generated on the basis of a digest (or hash) of a certificate of the client node used to authenticate the latter with a given mitigation server. This summary being specific to this association, it cannot therefore be reused for other purposes.
  • a DADI identifier can be allocated to a client domain by a DPS service provider. In such a case, it is ensured that the identification spaces used by different DPS service providers do not overlap, for example by coordinating the allocation of DADI identifiers between the DPS service providers or by using a space hierarchical identifier (e.g. the DADI identifier contains a part that is unique to each DPS service provider). In this way, it is ensured that each DADI identifier is globally unique (that is to say on all the customer domains considered). Indeed, for the purposes of the present solution, it is important that a DADI identifier unambiguously identifies a given customer domain and thus makes it possible to establish a link with the DPS service(s) responsible for protecting this customer domain.
  • the DADI identifiers can be allocated to client domains by an independent entity, such as the IANA (or “Internet Assigned Numbers Authority”).
  • IANA or “Internet Assigned Numbers Authority”.
  • IANA Internet Assigned Numbers Authority
  • the same DADI DADI-lli identifier associated (that is to say allocated) to the client domain 11, can be used by several DPS services.
  • a DADI DADI-II2 identifier associated with the client domain 11 is specific to a second DPS2 service implemented, for example by the mitigation server S13 and is therefore not recognized by a first DPS1 service.
  • customer domain 11 has a DADI DADI-II3 identifier specific to the third DPS3 service.
  • all of the DADI identifiers allocated to different DOTS client domains are maintained in a first register of DADI identifiers accessible to a plurality of DPS services (and to the mitigation servers contributing to the implementation of these DPS services).
  • This first register establishes a correspondence between client domain names and the DADI identifiers allocated to the client domains associated with these client domain names.
  • an entry in such a register might look like this:
  • Such a first register of DADI identifiers can for example be stored in a DNS register. Since such DNS registers are, in general, already deployed in a network, it is advantageous to use them to store the information relating to these DADI identifiers. Indeed, these DNS registers being known to the various nodes of the client domains, their interrogation by the client nodes is easy. Of course, other types of registers can be considered to store the first register of DADI identifiers (eg SQL (Structured Query Language) or LDAP (Lightweight Directory Access Protocol) database).
  • SQL Structured Query Language
  • LDAP Lightweight Directory Access Protocol
  • the first register of DADI identifiers can be private, that is to say that access to the data that it maintains is restricted, or public, that is to say that the access to the data it maintains is free. Whether to use a private or public DADI registry is an engineering choice. It should be noted, however, that use of a public DADI credential registry may provide access to sensitive information, for example, the absence of an entry in the DADI credential registry for a given customer domain may indicate that this domain is not protected against attacks. This information can be exploited by attackers against affected customer domains.
  • DNS SVCB type entries can be used to associate a DOTS client domain name , such as customer domain 11, with its identifier(s) DADI, DADI-lli, DADI-112, DADI-II3.
  • the choice to use this type of entry is based on the fact that, the DNS SVCB entries comprising several service parameters, it is thus possible to use one of these service parameters to memorize the DADI identifier(s) therein. a customer domain. It is then not necessary to create new types of entries.
  • the service parameters of an SVCB DNS entry are called SvcParams (for “Service Parameters” in English), and each of these service parameters is characterized by a key (SvcParamKey) and a value (Value ).
  • SvcParamKey a key which is called here "dadi” for illustrative purposes, and valued with the list of DADI identifiers associated with the domain client 11 namely DADI-lli, DADI-II2 and DADI-II3.
  • the first DADI identifier register On receipt of an SVCB-type DNS request sent by a mitigation server in order to obtain the DADI identifier(s) associated with the client domain 11, the first DADI identifier register returns the identifier(s) DADI associated with the customer domain 11.
  • DPS_Active_DADI DPS_Active_DADI
  • This second DPS_Active_DADI register can look like this:
  • This second DPS_Active_DADI register can also be stored in a DNS type register.
  • Other types of registers can be considered such as, for example, an LDAP directory or an SQL database as mentioned above.
  • Each DPS service provider proceeds, for the DPS services it provides, to add or delete entries in this second DPS_Active_DADI register according to agreements made with the various DOTS client domains for which they are authorized to mitigate attacks and protect resources.
  • Dedicated APIs for “Application Programming Interface” can be used for this purpose.
  • DPS_Active_DADI register An example of creating an entry in the DPS_Active_DADI register is described below.
  • REGISTER(dadi) a primitive used to add an entry to the DPS_Active_DADI register.
  • Such a primitive indicates that one or more DADI identifier(s) is associated with one or more mitigation server(s) identified by a set of DPS_Contact_Point parameters which may include in particular here, identification information such as a domain name, location information such as one or more IP addresses, one or more port numbers, as well as other information such as, for example, a period of validity of the recording, etc.
  • DELETE a primitive used to delete an entry in said DPS_Active_DADI register. This primitive is used for example to delete a registration when a client domain no longer uses the mitigation services of a given DPS service provider.
  • the REGISTER and DELETE primitives are authenticated in order to ensure that a DPS service provider is authorized to perform an operation relating to a DADI identifier in the DPS_Active_DADI register.
  • the [FIG. 2] illustrates the main steps of the methods for identifying at least one server for mitigating and protecting a client domain against a computer attack which is the subject of the present solution.
  • a client node Cl of the client domain 11 detects an attack targeting all or part of the resources of the client domain 11, in a manner known per se and not described here. Such an attack may not have hit client domain 11 yet.
  • the client node Cl sends, in a step E2, a message requesting assistance in attack management intended for a first DOTS mitigation server, for example here the server mitigation service S12, in order to signal the attack of which it is the target and request the execution of a mitigation service (“Request Mitigation”) in order to deal with this attack.
  • a request message is for example a DOTS request.
  • the client node Cl inserts a new DOTS parameter here called “dadi” in the “Request Mitigation” solicitation message, and more particularly in a header of this solicitation message.
  • This new “dadi” parameter includes the DADI identifier(s) DADI-lli, DADI-II2 and DADI-II3, associated with the client domain 11 to which the client node Cl belongs.
  • Uri-Path "mitigate”
  • the solicitation message includes several DADI identifiers
  • This last possibility is less interesting because it increases the size of the solicitation message (and therefore the risk of message fragmentation).
  • the DADI identifier(s) are inserted into the body of the “Request Mitigation” solicitation message (eg, PUT or POST messages).
  • the client node Cl can insert a UDP option or TCP, depending on the transport protocol used to send the "Request Mitigation” solicitation message.
  • UDP option or TCP An example format of such an option conforms to the format documented in IETF publication RFC793.
  • the mitigation server S12 determines, during a step E3, whether it is capable of processing this message, that is to say in the implementation particular consideration contemplated here, if he is empowered to do so. This determination can be carried out by means known to those skilled in the art and not described in detail here.
  • the server S12 If the server S12 is capable (ie authorized here) of processing the solicitation message, then it informs the client node C1 that it can respond favorably to the solicitation message received, in a step E4.
  • the attack impacting the resources of the client domain 11 is then mitigated in a conventional manner (either directly by the server S12 or by interfacing with an external entity such as a “mitigator”).
  • the mitigation server S12 determines that it is unable to process the “Request Mitigation” request message because, in the particular implementation considered here, it does not is not authorized to manage the resource targeted by the attack (identified for example by the fields "target-prefix", “target-uri”, “target-fqdn”, etc., of the body of the message), then the server mitigation S12 seeks to identify another mitigation server authorized to process the solicitation message. To this end, the mitigation server S12 seeks to obtain at least one DADI identifier associated with the client domain 11 to which the client node C1 sending the solicitation message belongs during a step E5.
  • a first situation in which the “Request Mitigation” solicitation message does not include any DADI identifier associated with the client domain 11, and a second situation (case considered as an example here) in which the "Request Mitigation” solicitation message includes at least one DADI identifier associated with the client domain 11 (in its message body, in one of its header fields, or in a transport option such as a UDP option as described above ).
  • the server S12 determines a domain name associated with the client domain 11. For this purpose, it extracts, for example, a domain name associated with the client domain 11 included, for example, in the certificate used to create the (D)TLS association required beforehand to send the “Request Mitigation” solicitation message. Then it interrogates, by means of the domain name thus obtained, the first register of identifiers DADI by sending it during a step E6, an SVCB request. The first DADI identifier registry then uses this domain name to obtain at least one DADI identifier DADI-lli, DADI-II2 and/or DADI-II3, associated with the client domain 11. Once these DADI identifiers DADI-lli, DADI -II2 and/or DADI-II3 obtained, they are transmitted to the mitigation server S12 by the first register of DADI identifiers.
  • the server S12 in a step E7, sends a new request , designated for example here by "QUERY_DPS_REGISTRY", and specially designed for the needs of this solution, intended for the DPS_Active_DADI register in order to identify at least one mitigation server, authorized to process the "Request Mitigation" solicitation message associated with the (x) identifier(s) obtained.
  • a DPS_Active_DADI register is populated by the DPS service providers whose DPS services implement the present solution.
  • the server S12 extracts, during a step E8, the DADI identifier(s) present in the “Request Mitigation” solicitation message and verifies that this (these) identifier(s) DADI is (are) associated with the DPS service that it contributes to implemented.
  • Such information is for example configured locally at the level of each mitigation server.
  • the DPS service implemented by the mitigation server S12 does not correspond to a DPS service associated with the DADI identifier(s) extracted from the solicitation message, this means that the message "Request Mitigation" request was erroneously sent to the server S12 because the DPS service that it implements is not a DPS service retained by the manager entity of the client domain 11 to mitigate the attacks against the resources of this customer domain indicated in the signaling message.
  • the mitigation server S12 sends, in a step E9, a "QUERY_DPS_REGISTRY" request to the DPS_Active_DADI register in order to identify at least one mitigation server (S13 or S14 in the example of the figure 1 considered here) authorized to process the “Request Mitigation” solicitation message and associated with the identifier extracted from the solicitation message.
  • the mitigation server S12 sends a "QUERY_DPS_REGISTRY" request to the DPS_Active_DADI register in order to identify at least one mitigation server (S13 or S14 in the example of Figure 1 considered here) authorized and able to process the “Request Mitigation” solicitation message, and associated with the identifier extracted from the solicitation message.
  • a real-time publication of the information relating to the various mitigation servers or an interrogation of the information of the mitigation server in order to determine the ability of the latter to process the solicitation message is assumed.
  • the mitigation server S12 implements the mitigation service (DPS1 in the example considered here) which is associated with the DADI identifier DADI-lli allocated to the client domain 11. It is assumed in this example that the DADI identifier extracted from the solicitation message is the DADI-II3 identifier. By consulting the DPS_Active_DADI register, the mitigation server S12 finds that the DADI identifier DADI-II3 does not correspond to the DADI identifier DADI-lli associated with the mitigation service DPS1 that it implements.
  • DPS1 the mitigation service
  • the mitigation server S12 then interrogates the register DPS_Active_DADI in order to identify, by means of the identifier DADI-II3 extracted from the request message, a mitigation server associated with the identifier DADI-II3. During this step, it obtains the data relating to the mitigation server in question (S14 in the illustrative example considered here).
  • the DADI identifier extracted by the server S12 during step E8 is indeed associated with the DPS service of the mitigation server S12 and the mitigation server S12 is not authorized to process the solicitation message, this means, in the embodiment described here, that the same DADI identifier is used by several DPS services (case not represented in table 2). In fact, in this situation, the DADI identifier extracted by the server S12 during step E8 identifies DPS services responsible for protecting the client domain 11; however the server S12 although authorized to protect certain resources of the client domain 11 (eg 1.2.3.4/32), is not authorized to protect other resources (eg 11.12.13.14/32) at the origin of the solicitation message.
  • the mitigation server S12 uses the domain name of the client domain 11 found for example in the certificate used to create the (D)TLS association required beforehand to sending the request message "Request Mitigation" as described above, in order to send, in a step E10, an SVCB request to the first register of DADI identifiers to obtain the DADI identifier(s) associated with the domain customer 11.
  • the server S12 Upon receipt of the DADI identifier(s) associated with the client domain 11, the server S12 then sends, in a step Eli, a "QUERY_DPS_REGISTRY" request to the DPS_Active_DADI register in order to identify the at least one mitigation server authorized to process the “Request Mitigation” solicitation message.
  • the mitigation server S12 contributes to implementing a mitigation service which is associated with the DADI identifier DADI-lli associated with the client domain 11.
  • the DADI identifier extracted from the request message is the identifier DADI-lli.
  • the mitigation server S12 finds that the identifier DADI extracted from the request message, DADI-lli, corresponds to the DPS service that it implements although it is not capable of processing this request message.
  • the mitigation server S12 then interrogates the first register of DADI identifiers in order to identify the client domain 11 associated with the identifier DADI-lli extracted from the solicitation message received.
  • the mitigation server obtains from the first register of DADI identifiers that the identifier DADI-lli is associated with the client domain 11.
  • the mitigation server S12 also obtains the information that the client domain 11 is additionally associated with the identifiers DADI- II3 and DADI-II2.
  • the mitigation server S12 then interrogates the DPS_Active_DADI register in order to identify, by means of the DADI-lli identifier extracted from the solicitation message and, if applicable, the DADI-II3 and DADI-II2 identifiers obtained by interrogating the DADI identifier registry, another mitigation server helping to implement here a DPS service different from the DPS service implemented by the mitigation server S12 but which is also associated with the DADI-lli identifier extracted from the solicitation message , or to another DADI-II3 or DADI-II2 identifier associated with a mitigation service protecting the resources of the client domain 11.
  • the mitigation server S12 interrogates the DPS_Active_DADI register in order to identify, by means of the DADI-lli identifier extracted from the solicitation message, only another mitigation server contributing to implementing a service DPS differs from the DPS service implemented by the mitigation server S12 but which is also associated with the identifier DADI-lli extracted from the solicitation message.
  • the implementation of one or other of the variants may depend on any agreements made between the client domain and the DPS protection services, or between the DPS protection services among themselves, etc.
  • the mitigation server S12 can obtain the location information of the mitigation servers authorized and likely to respond to the initial mitigation request.
  • the transmission of all or part of the information that identifies the DPS service provider(s) that operate said mitigation servers to the mitigation server S12 may be conditioned by the possible existence of agreements made between the various DPS service providers.
  • the mitigation server S12 can only have access to the contact information of the partner DPS service providers, according to the DADI identifiers associated with their clients, and which appear in the DPS_Active_DADI register.
  • the mitigation server S12 receives, during a step E12, a message from the DPS_Active_DADI register.
  • Such a message returns a set of parameters (that is to say information) DPS_Contact_Point associated with one or more mitigation servers a priori authorized to process the solicitation message.
  • a set of DPS_Contact_Point parameters can include information identifying a mitigation server such as a domain name, location information for this mitigation server (e.g. an IP address, a port number), and other information such as a registration validity period, etc. relating to the DPS service associated with it.
  • the mitigation server S12 contacts the DPS_Active_DADI register to retrieve the contact point or points (mitigation servers) of the DPS services authorized to process the mitigation request according to the values of the DADI identifiers.
  • the registry's response may consist of the transmission of all or part of the DPS contact points, depending on whether agreements have been made between the different DPS service providers or not.
  • the mitigation server S12 can only obtain the DPS_Contact_Point information associated with mitigation servers implementing the same DPS service, regardless of the location of these mitigation servers.
  • the mitigation server S12 can only obtain the DPS_Contact_Point information associated with mitigation servers located in the same server domain as it but having resources different from its own, etc. [0135] Following receipt of this message comprising the DPS_Contact_Point information, the mitigation server S12 can undertake at least two actions. Such a choice of an action to be taken is made for example on the basis of attack traffic processing policies which are supplied to it by the provider of mitigation services which exploits it.
  • a first action consists in requesting a redirection of the request message “Request Mitigation” to another mitigation server, identified by a set of parameters DPS_Contact_Point present in the message received during step E12.
  • the mitigation server S12 sends, in a step E13, a redirection message to the client node C1, this redirection message includes information allowing the client node C1 to identify (and if necessary to locate) the mitigation server to which it must resend the solicitation message.
  • a redirection message includes information allowing the client node C1 to identify (and if necessary to locate) the mitigation server to which it must resend the solicitation message.
  • Such a message comprises a list of alternative mitigation servers to which the request message can be retransmitted, corresponding to the sets of parameters DPS_Contact_Point received by the mitigation server S12. These mitigation servers are identified in the “alt-server” attributes of said redirect message. Depending on the policies adopted, this redirection message can be transmitted in parallel to all the mitigation servers identified in the list or according to a predefined order.
  • the client node C1 Upon receipt of this redirection message, the client node C1 resends, in a step E14, the "Request Mitigation" request message to the mitigation server(s) identified in the redirection message, for example to the mitigation S14. If several mitigation servers are identified in the redirect message, the solicitation message can be sent to these servers in parallel or sequentially.
  • the mitigation server S14 Upon receipt of the solicitation message sent by the client node C1 during step E14, the mitigation server S14 implements, in turn, the steps E3 to E15 previously described.
  • a second action consists, for the mitigation server S12, in relaying, in a step E15, the “Request Mitigation” request message to the mitigation server(s) identified during the step E12.
  • the identified mitigation server implements, in turn, the steps E3 to E15 previously described.
  • the attack impacting the resources of the client domain 11 can then be mitigated in a conventional manner (directly by the server in question or by interfacing with an external entity such as a “mitigator”).
  • the mitigation server S12 has sought to identify, in order to process the request message, a mitigation server implementing a different DPS service than itself.
  • it can be envisaged that it identifies another mitigation server authorized to process the solicitation message and implementing the same service as it.
  • Such a loop can be avoided, for example, by ensuring that the mitigation server that relayed the request message is excluded from the list of mitigation servers to which the request message may be relayed.
  • a client node C1, C2, C3, Cm comprises a memory 101c comprising a buffer memory, a processing unit 102c, equipped for example with a programmable calculation machine or a machine dedicated computing device, for example a processor P, and controlled by the computer program 103c, implementing steps of the methods for identifying at least one mitigation server and protecting a client domain against a computer attack according to one embodiment of the invention.
  • the code instructions of the computer program 103c are for example loaded into a RAM memory before being executed by the processor of the processing unit 102c.
  • the processor of the processing unit 102c implements steps of the method for identifying at least one server for mitigating and protecting a client domain against a computer attack described above, according to the instructions of the program computer case 103c, for:
  • a mitigation server S12, S13, S14 comprises a memory 111s, c comprising a buffer memory, a processing unit 112s, c, equipped for example with a programmable calculation machine or a dedicated calculation, for example a processor P, and driven by the computer program 113s, c, implementing steps of the methods for identifying at least one mitigation server and protecting a client domain against an attack computer according to one embodiment of the invention.
  • the code instructions of the computer program 113s, c are for example loaded into a RAM memory before being executed by the processor of the processing unit 112S.
  • the processor of the processing unit 112s, c implements steps of the methods described previously, according to the instructions of the computer program 113s, c, for:
  • - receive a message requesting assistance for the management of attacks from a client node of the client domain; and when said mitigation server, called first mitigation server, is not able to process said request message: - obtain, by means of an identifier of said client domain obtained by the first mitigation server, at least one piece of information identification of at least one second attack mitigation server authorized to process said solicitation message.

Landscapes

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

Abstract

Des services de détection et de mitigation d'attaques informatiques sont proposés par certains fournisseurs d'accès à leurs clients. Cependant, il arrive parfois qu'un message de sollicitation d'une assistance pour la gestion d'attaques émis par un nœud d'un domaine client subissant une attaque informatique soit envoyé vers un serveur de mitigation qui n'est pas capable de le traiter. Une telle demande sera systématiquement rejetée et aucune action de mitigation ne sera mise en œuvre. La présente solution permet de s'assurer qu'aucun message de sollicitation émis par un nœud ne reste sans réponse même s'il est transmis à destination d'un serveur de mitigation incapable de le traiter. Pour cela, lorsqu'un serveur de mitigation détermine qu'il n'est pas capable de traiter un message de sollicitation plutôt que de rejeter cette sollicitation, il va chercher à identifier au moins un autre serveur de mitigation qui serait en mesure de traiter ce message de sollicitation.

Description

Description
Titre de l'invention : 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
Domaine de l'invention
[0001] Le domaine de l'invention est celui des communications établies sur un réseau, par exemple un réseau IP, et notamment celui des services IP à valeur ajoutée.
[0002] L'invention trouve notamment des applications dans le domaine de la mitigation d'attaques par déni de service 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, ou la mitigation d'attaques par intrusion.
[0003] Plus précisément, l'invention offre une solution permettant de faciliter la coordination des actions de mitigation engagées afin de contrer des attaques informatiques impactant un domaine client.
Art antérieur et ses inconvénients
[0004] 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.
[0005] 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 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 ».
[0006] 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 les composantes de détection mises en œuvre par un tel service ne sont pas forcément présentes sur les chemins empruntés par les données caractéristiques du trafic d'attaque pour atteindre sa ou ses victimes.
[0007] Pour résoudre ce problème, il a été notamment proposé de mettre en place des tunnels au travers desquels le trafic en provenance ou à destination d'un site ou d'un réseau est acheminé. De tels tunnels constituent ainsi une ressource de transport du trafic que le service DPS peut alors inspecter. Toutefois, l'établissement et l'utilisation de tunnels augmentent considérablement la latence observée par les utilisateurs et imposent des contraintes de dimensionnement du service DPS pour être en mesure de traiter tout le trafic en provenance ou à destination de l'ensemble des terminaux utilisateurs de tels tunnels. En outre, lesdits tunnels sont considérés comme des vecteurs d'attaque potentiels.
[0008] 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 emprunté par le trafic en provenance ou à destination 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 (pour « User Datagram Protocol » en anglais) tel que par exemple le trafic QUIC, il est difficile de distinguer le trafic légitime du trafic suspect. La difficulté d'accéder en clair aux messages de contrôle, similaires aux messages « SYN/SYN-ACK/ACK » du protocole TCP (pour « Transmission Control Protocol » en anglais), peut en effet compliquer la vérification du consentement d'un nœud du réseau à recevoir du trafic, par exemple.
[0009] Afin d'aider à l'identification du trafic suspect, une architecture spécifique a été normalisée au sein de l'IETF, appelée architecture DOTS. Une telle architecture, permet à un nœud client, dit client DOTS, d'informer un serveur de mitigation, dit serveur DOTS, qu'il a détecté une attaque DDoS et que des actions de mitigation appropriées sont requises.
[0010] Lorsqu'un domaine client est la cible d'une attaque DDoS, un client DOTS faisant partie de ce domaine client peut ainsi envoyer un message à un 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 de 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.
[0011] L'architecture DOTS repose sur l'utilisation de deux canaux de communication pour l'échange de messages de signalisation entre un client DOTS et un serveur DOTS :
- un canal de données DOTS (en anglais « DOTS Data Channel »), et
- un canal de signalisation DOTS (en anglais « DOTS Signal Channel »).
[0012] Le canal de données DOTS peut être utilisé lorsqu'aucune attaque DDoS n'est détectée par un client DOTS, notamment pour faciliter la mise en place d'actions préventives, telles que l'installation de filtres de trafic. Le canal de données peut aussi être utilisé pour préinstaller des règles de filtrage à activer lors d'une mitigation (par exemple, identifier une partie du trafic qui ne doit pas être supprimée par les actions de mitigation). Par exemple, un client DOTS peut utiliser ce canal pour installer des règles de filtrage du trafic reçu de certaines adresses ou celui destiné à un nœud donné, ou pour demander au serveur de bloquer tout le trafic à destination du préfixe « 1.2.3.0/24 » ou encore tout le trafic UDP à destination du numéro de port 443, couramment utilisé par les attaques de déni de service.
[0013] Le canal de signalisation DOTS, quant à lui, est utilisé particulièrement 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 le canal de signalisation pour envoyer une requête de mitigation 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 parmi la pluralité des clients actifs d'un domaine client, noté CUID (« Client Unique IDentifier »).
[0014] Si l'entité de mitigation n'est pas colocalisée avec le serveur DOTS, ce dernier relaye la requête à une entité de mitigation qui peut ainsi prendre les mesures de mitigation 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 DOTS faisant partie du même domaine client, ou avec une règle de filtrage installée préalablement par le serveur DOTS en réponse à une requête d'un autre client du même domaine client, et d'autre part, si le serveur est habilité à/configuré pour honorer la dernière requête reçue. Lorsque le serveur DOTS n'est pas habilité à traiter une telle requête, il la rejette et émet un message d'erreur 4.03 (Bad Request).
[0015] Il existe par conséquent un risque qu'un serveur DOTS refuse de traiter des messages de signalisation provenant d'un client DOTS, comme par exemple une requête de mitigation d'attaque émise par un client DOTS alors que l'attaque est réelle, ou des requêtes de filtrage émises par un client DOTS (un objectif des requêtes de filtrage étant d'anticiper des attaques DDoS). Un tel refus peut notamment survenir lorsque le domaine client utilise une adresse « anycast » pour joindre un serveur DOTS ou en cas de défaillance d'un algorithme permettant d'identifier un équipement de sortie du domaine client, par exemple. Une adresse « anycast » est une adresse configurée avec plusieurs interfaces réseau et qui permet donc de joindre plusieurs équipements. Ainsi, un paquet de données ayant pour destination une adresse « anycast » sera traité par un seul équipement ayant été configuré avec cette adresse, mais qui se trouve être le plus proche de la source émettrice du paquet au sens de la politique de routage dynamique mise en œuvre au sein du réseau.
[0016] Dans de tels cas de figure, une requête émise par un client DOTS du domaine client peut être envoyée vers un serveur DOTS qui n'est pas habilité à la traiter. Une telle requête sera alors systématiquement rejetée par ledit serveur DOTS et aucune action de mitigation ne pourra être mise en œuvre, que ce soit de manière préventive ou de manière curative pour mitiger une attaque détectée.
[0017] Il existe donc un besoin d'une nouvelle technique permettant d'améliorer la coordination des actions de mitigation engagées afin de contrer des attaques impactant ou susceptibles d'impacter un domaine client. Exposé de l'invention
[0018] L’invention répond à ce besoin en proposant un procédé d'identification d'au moins un serveur de mitigation d'attaques habilité à protéger un domaine client contre une attaque informatique.
[0019] Un tel procédé est particulier en ce qu'il est mis en œuvre par un premier serveur de mitigation d'attaques et qu'il comprend :
- la réception d'un message de sollicitation d'une assistance pour la gestion d'attaques en provenance d'un nœud client du domaine client ; et lorsque ledit premier serveur de mitigation n'est pas capable de traiter ledit message de sollicitation :
- l'obtention, au moyen d'au moins un premier identifiant dudit domaine client obtenu par le premier serveur de mitigation, d'au moins une information d'identification d'au moins un deuxième serveur de mitigation d'attaques habilité à traiter ledit message de sollicitation.
[0020] Une telle solution, désignée dans la suite de la description par LOST (pour « Liberal processing of ddos mitigation requeSTs »), permet de s'assurer qu'aucun message de sollicitation d'une assistance pour la gestion d'attaques (ex. demande de mitigation d'attaque ou de mise en place de règles de filtrage) émis par un nœud client ne reste sans réponse même s'il est transmis à destination d'un serveur de mitigation incapable de le traiter.
[0021] Aucune limitation n'est attachée à la nature du message de sollicitation. Il peut s'agir par exemple, dans le contexte d'une architecture DOTS telle que citée précédemment, de l'un quelconque des messages de signalisation évoqués avant, comme un message de sollicitation envoyé via le canal de signalisation (par ex. une requête de mitigation) ou un message de sollicitation envoyé via le canal de données (par ex. une requête de filtrage). On note par ailleurs que, bien que l'invention ait été introduite en référence à l'architecture DOTS, elle s'applique également à d'autres architectures conçues pour l'échange entre différentes entités de messages de signalisation en lien avec la gestion d'un trafic d'attaque (gestion préventive et/ou curative) telles que par exemple des architectures exploitant une signalisation reposant sur le protocole NETCONF ou encore d'autres architectures propriétaires conçues à cet effet. Aussi, la solution s'applique indépendamment de l'architecture interne du service de mitigation. Particulièrement, la solution s'applique si les actions de mitigation sont entreprises directement par le serveur de mitigation ayant reçu le message de sollicitation ou par une entité externe (« mitigator », typiquement) vers laquelle le message de sollicitation a été relayé par ledit serveur de mitigation.
[0022] L'incapacité d'un serveur de mitigation à traiter un tel message de sollicitation peut avoir différentes origines. [0023] Ainsi, dans un mode particulier de réalisation, un serveur de mitigation est dans l'incapacité de traiter un message de sollicitation émis par le nœud client (ex. un message de sollicitation d'attaque), car il ne dispose pas des autorisations (ou habilitations) nécessaires pour le faire. C'est le cas, par exemple, lorsque le serveur de mitigation n'est pas autorisé à appliquer certaines politiques relatives à des ressources (par ex. des préfixes IP, URI, FQDN) du domaine client telles que des politiques de routage, de filtrage ou de redirection de trafic, etc. Autrement dit, dans ce mode de réalisation, l'incapacité du serveur de mitigation à traiter le message de sollicitation émis par le nœud client provient du fait qu'il n'est pas habilité à traiter ce message de sollicitation.
[0024] Dans un autre mode de réalisation, un serveur de mitigation est dans l'incapacité de traiter un message de sollicitation émis par le nœud client (ex. une demande de mitigation d'attaque) car il ne dispose pas des ressources structurelles (par ex. les capacités de calcul, les ressources réseau) et/ou fonctionnelles pour le faire, ou d'une interface avec une entité disposant de telles ressources (ex. « mitigator » évoqué précédemment). Dans la suite de la description, un tel serveur de mitigation est désigné comme n'étant pas apte à traiter le message de sollicitation émis par le nœud client.
[0025] Dans un autre mode de réalisation, on s'intéresse aux deux conditions évoquées ci-dessus (habilitation et aptitude) pour déterminer si un serveur de mitigation est capable ou non de traiter un message de sollicitation. Autrement dit, dans cet autre mode de réalisation, un serveur de mitigation capable de traiter un message de sollicitation d'une assistance pour la gestion d'attaques au sens de l'invention est d'une part, habilité à le faire, et d'autre part, dispose des ressources structurelles (ex. matérielles, logicielles, etc.) et fonctionnelles pour le faire ou d'une interface avec une entité externe (ex. « mitigator ») disposant de telles ressources.
[0026] Conformément à l'invention, lorsqu'un premier serveur de mitigation détermine qu'il n'est pas capable de traiter un message de sollicitation d'attaque, c'est-à-dire selon le mode de réalisation envisagé, parce qu'il n'est pas habilité à le faire et/ou parce qu'il n'est pas apte à le faire (directement ou indirectement via une interface avec une entité externe chargée d'élaborer et/ou de mettre en œuvre un plan de mitigation), il cherche à identifier un deuxième serveur de mitigation habilité à traiter le message de sollicitation d'attaque qu'il a reçu.
[0027] En effet, dans le cas présent, lorsque le premier serveur de mitigation détermine qu'il n'est pas capable de traiter un message de sollicitation, c'est-à-dire, par exemple, qu'il n'est pas habilité à traiter cette demande, plutôt que de rejeter cette demande, il va chercher à identifier au moins un autre serveur de mitigation qui serait en mesure de traiter ce message de sollicitation. Cet autre serveur de mitigation peut à son tour mettre en œuvre la présente méthode de manière récursive jusqu'à ce qu'un serveur de mitigation effectivement capable de traiter le message de sollicitation soit identifié. [0028] Pour cela, le serveur de mitigation utilise au moins un identifiant du domaine client cible de l'attaque (premier identifiant au sens de l'invention). Cet identifiant est spécialement créé pour permettre une telle identification d'un autre serveur de mitigation. Ce nouvel identifiant du domaine client est associé à au moins un service de mitigation protégeant des ressources du domaine client (par exemple, un service DPS pour des attaques de type DDoS) et permet de faire le lien entre le domaine client et au moins un serveur de mitigation d'attaques mettant en œuvre ledit au moins un service de mitigation et habilité à traiter un message de sollicitation émis par un nœud client du domaine client en question.
[0029] Un tel identifiant du domaine client auquel est rattaché le nœud client ayant émis le message de sollicitation peut être commun à plusieurs services de mitigation (ex. à plusieurs services DPS), par exemple à plusieurs services de mitigation fournis par une même entité administrative. Dans un autre exemple, un identifiant du domaine client auquel est rattaché le nœud client ayant émis le message de sollicitation peut être spécifique à un service de mitigation (ex. à un service DPS) mis en œuvre, par exemple par le deuxième serveur de mitigation et ne sera, par conséquent, pas reconnu par un autre service de mitigation mis en œuvre, par exemple par un troisième serveur de mitigation. Dans un autre exemple encore, un identifiant du domaine client peut être spécifique à un serveur de mitigation contribuant à mettre en œuvre un service de mitigation.
[0030] Le premier serveur de mitigation ayant mis en œuvre la présente solution se retrouve alors en possession de données permettant le traitement du message de sollicitation qu'il a reçu mais qu'il ne peut traiter, évitant ainsi que ce dernier reste sans réponse, un tel traitement étant effectué par un autre serveur de mitigation (deuxième serveur de mitigation au sens de l'invention).
[0031] Dans un exemple, au moins un dit premier identifiant dudit domaine client est obtenu par interrogation d'une première base de données au moyen d'un nom de domaine associé audit domaine client.
[0032] Dans un tel exemple, une première base de données maintient un registre dans lequel un nom de domaine associé au domaine client du nœud client ayant émis le message de sollicitation est associé à au moins un identifiant dudit domaine client. Une telle première base de données est par exemple maintenue par un serveur DNS (Domain Name System).
[0033] Dans un autre exemple, au moins un dit premier identifiant dudit domaine client est extrait dudit message de sollicitation.
[0034] Dans cet exemple, le premier identifiant en question dudit domaine client est véhiculé dans un champ du message de sollicitation. Ainsi, il suffit au premier serveur de mitigation d'extraire cette information du message de sollicitation. [0035] Dans une implémentation du présent procédé, au moins un dit premier identifiant dudit domaine client peut être obtenu par le premier serveur de mitigation au moyen d'un deuxième identifiant dudit domaine client extrait du message de sollicitation.
[0036] Ce mode de réalisation a une application privilégiée lorsque le message de sollicitation comprend un deuxième identifiant du domaine client commun à plusieurs serveurs ou services de mitigation (c-à-d. qui identifie plusieurs serveurs/ services de mitigation), dont le premier serveur de mitigation ayant reçu le message de sollicitation, et que le premier serveur de mitigation n'est pas en mesure de traiter ce message. Il est en effet important de pouvoir identifier un autre serveur de mitigation habilité à le traiter.
[0037] Dans cette situation, le premier serveur de mitigation peut utiliser le deuxième identifiant extrait du message de sollicitation pour obtenir un nom de domaine associé audit domaine client. Puis, à partir de ce nom de domaine il peut, par exemple en interrogeant la première base de données, obtenir un ou plusieurs identifiants du domaine client associés au nom de domaine obtenu (premiers identifiants au sens de l'invention), et à partir de ces identifiants du domaine client, identifier un ou plusieurs serveurs de mitigation habilités à traiter le message de sollicitation. Le choix du ou des serveurs de mitigation vers lesquels orienter le message de sollicitation pour traitement peut dépendre de différents paramètres (politiques de mitigation, accords existants avec le domaine client et/ou entre les services de protection, etc.)
[0038] Dans une variante de réalisation, lorsque le message de sollicitation comprend un identifiant du domaine client commun à plusieurs serveurs ou services de mitigation dont le premier serveur de mitigation ayant reçu le message de sollicitation, et que le premier serveur de mitigation n'est pas en mesure de traiter ce message, il utilise cet identifiant du domaine client pour identifier les autres serveurs de mitigation habilités à traiter le message de signalisation.
[0039] Dans un exemple, le procédé comprend en outre une étape d'obtention d'au moins une information de localisation dudit deuxième serveur de mitigation par interrogation d'une deuxième base de données au moyen dudit premier identifiant dudit domaine client.
[0040] Une telle information de localisation dudit deuxième serveur de mitigation peut comprendre au moins une adresse réseau dudit deuxième serveur de mitigation et/ou au moins un numéro de port dudit deuxième serveur de mitigation.
[0041] Ainsi, il est possible de contacter ce deuxième serveur de mitigation afin de l'informer de la survenue d'une attaque ayant pour cible des ressources du domaine client.
[0042] Dans un exemple, les informations d'identification et/ou de localisation dudit deuxième serveur sont transmises par le premier serveur au nœud client.
[0043] Ainsi à réception de ces informations, le nœud client peut émettre un nouveau message de sollicitation directement à destination du deuxième serveur. [0044] Dans un autre exemple, le premier serveur de mitigation agit comme un relai pour le nœud client en transmettant le message de sollicitation à destination du deuxième serveur. Cette deuxième variante a pour avantage de réduire le délai de traitement du message de sollicitation.
[0045] L'invention concerne également un procédé de protection d'un domaine client contre une attaque informatique, ledit procédé étant mis en œuvre par un nœud client hébergé par le domaine client et comprenant :
- la transmission d'un message de sollicitation d'une assistance pour la gestion d'attaques à destination d'un premier serveur de mitigation d'attaques ;
- la réception d'au moins une information d'identification d'au moins un deuxième serveur de mitigation d'attaques habilité à traiter ledit message de sollicitation, le premier et le deuxième serveur de mitigation d'attaques étant associés à des services de mitigation distincts ; et
- la transmission dudit message de sollicitation à destination dudit deuxième serveur de mitigation.
[0046] Les services de mitigation distincts peuvent être par exemple gérés par des entités administratives distinctes.
[0047] Dans un exemple, le message de sollicitation comprend au moins un identifiant dudit domaine client au moyen duquel ladite au moins une information d'identification dudit deuxième serveur de mitigation est obtenue par le premier serveur de mitigation.
[0048] L'invention concerne encore un serveur de mitigation d'attaques, dit premier serveur de mitigation, habilité à protéger un domaine client contre une attaque informatique, et comprenant au moins un processeur configuré pour :
- recevoir un message de sollicitation d'une assistance pour la gestion d'attaques en provenance d'un nœud client du domaine client ; et lorsque ledit premier serveur de mitigation n'est pas capable de traiter ledit message de sollicitation :
- obtenir, au moyen d'un identifiant dudit domaine client obtenu par le premier serveur de mitigation, au moins une information d'identification d'au moins un deuxième serveur de mitigation d'attaques habilité à traiter ledit message de sollicitation.
[0049] Un autre objet de l'invention concerne un nœud client hébergé par un domaine client comprenant au moins un processeur configuré pour :
- transmettre un message de sollicitation d'une assistance pour la gestion d'attaques à destination d'un premier serveur de mitigation d'attaques ; - recevoir au moins une information d'identification d'au moins un deuxième serveur de mitigation d'attaques habilité à traiter ledit message de sollicitation, le premier et le deuxième serveur de mitigation d'attaques étant associés à des services de mitigation distincts ; et
- transmettre ledit message de sollicitation à destination dudit deuxième serveur de mitigation.
[0050] L'invention concerne encore un signal destiné à être transmis par un nœud client hébergé par un domaine client à destination d'au moins un premier serveur de mitigation d'attaques, ledit signal comprenant un message de sollicitation d'une assistance pour la gestion d'attaques, ledit message de sollicitation comprenant au moins un identifiant dudit domaine client au moyen duquel au moins une information d'identification d'au moins un deuxième serveur de mitigation habilité à traiter ledit message de sollicitation peut être obtenue.
[0051] L'invention concerne enfin des produits programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre des procédés tels que décrits précédemment, lorsqu'ils sont exécutés par un processeur.
[0052] L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel sont enregistrés des programmes d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes des procédés selon l'invention tels que décrits ci-dessus.
[0053] Un tel support d’enregistrement peut être n’importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple une clé USB ou un disque dur.
[0054] D’autre part, un tel support d’enregistrement peut être un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d’autres moyens, de sorte que les programmes d'ordinateur qu'il contient sont exécutables à distance. Les programmes selon l’invention peuvent être en particulier téléchargés sur un réseau par exemple le réseau Internet.
[0055] Alternativement, le support d’enregistrement peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution des procédés objets de l'invention précités.
Brève description des dessins
[0056] D’autres buts, caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles : [FIG. 1] : cete figure représente différents équipements d'un réseau de communication metant en œuvre un procédé d'identification d'au moins un serveur de mitigation selon un mode de réalisation de l'invention,
[FIG. 2] : cete figure représente les principales étapes des procédés d'identification d'au moins un serveur de mitigation et de protection d'un domaine client contre une ataque informatique objet de la présente solution,
[FIG. 3] : cete figure représente la structure simplifiée d'un nœud client selon l'un des modes de réalisation de la présente invention,
[FIG. 4] : cete figure représente la structure simplifiée d'un serveur de mitigation selon l'un des modes de réalisation décrits ci-dessus.
Description détaillée de modes de réalisation de l'invention
[0057] Le principe général de l'invention repose sur la capacité d'un serveur de mitigation d'ataques à déterminer qu'il n'est pas capable de traiter un message de sollicitation d'une assistance dans la gestion d'ataques, comme une demande de mitigation d'une ataque émise par un nœud client d'un domaine client qui est la cible d'une ataque en cours ou une requête de filtrage à activer en cas d'attaque avérée, etc. Pour ce faire, le serveur de mitigation repose sur des informations locales (par ex. les habilitations préconfigurées par un administrateur) ou récupérées via des interfaces dédiées depuis des entités externes (par ex. vers un « mitigator » externe, une base de données). Ces interfaces sont par exemple similaires ou identiques à celles de la Figure 1 du document RFC 8811 édité par l'IETF et intitulé « DDos Open Threat Signaling (DOTS) Architecture », August 2020.
[0058] Dans une implémentation de la présente solution, on envisage une architecture DOTS telle qu'introduite précédemment. Un tel message de sollicitation peut être, dans ce contexte, une requête DOTS. Une telle 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 gestion de règles de filtrage tel que demander à un serveur DOTS d'installer une liste de contrôle d'accès ou ACL (pour « Access Control List » en anglais),
- un message de signalisation pour solliciter la mitigation d'une ataque de déni de service auprès d'un serveur DOTS, le serveur de mitigation pouvant, sur réception d'un tel message, déclencher les actions nécessaires pour metre fin à l'ataque (incluant la coordination avec une entité externe telle qu'un « mitigator »),
- un message de signalisation pour contrôler un filtre préinstallé tel que décrit dans la RFC9133. [0059] Si ledit serveur de mitigation est incapable de traiter le message de sollicitation reçu, il va alors chercher à identifier au moins un autre serveur de mitigation qui serait en mesure de traiter ce message de sollicitation plutôt que de rejeter la sollicitation en question. Ainsi, on s'assure que tout message de sollicitation émis par un nœud client d'un domaine client est traité.
[0060] L'incapacité d'un serveur de mitigation à traiter un tel message de sollicitation peut avoir différentes origines. Dans l'implémentation particulière décrite en détail ici, on considère que le serveur de mitigation est dans l'incapacité de traiter un message de sollicitation émis par le nœud client (ex. un message de sollicitation d'attaque), car il ne dispose pas des autorisations (ou habilitations) nécessaires pour le faire. C'est le cas, par exemple, lorsque le serveur de mitigation n'est pas autorisé à appliquer certaines politiques relatives à des ressources du domaine client telles que des politiques de routage, de filtrage ou de redirection de trafic, etc. On dit alors que le serveur de mitigation n'est pas habilité à traiter le message de sollicitation émis par le nœud client.
[0061] Dans une autre implémentation, un serveur de mitigation peut être dans l'incapacité de traiter un message de sollicitation émis par le nœud client (ex. une demande de mitigation d'attaque) car ledit serveur et/ou les entités à appliquer dans la mise en place d'actions de mitigation ne disposent pas des ressources structurelles (par ex. les capacités de calcul, les ressources réseau) et/ou fonctionnelles pour le faire. Un tel serveur de mitigation est alors désigné comme n'étant pas apte à traiter le message de sollicitation émis par le nœud client.
[0062] Dans une autre implémentation encore, un serveur de mitigation peut être dans l'incapacité de traiter un message de sollicitation émis par le nœud client soit parce qu'il n'est pas habilité à le faire, soit parce qu'il n'est pas apte à le faire. A l'inverse, dans cette implémentation, un serveur de mitigation capable de traiter un message de sollicitation d'une assistance pour la gestion d'attaques au sens de l'invention est d'une part, habilité à le faire et d'autre part, dispose des ressources structurelles (ex. matérielles, logicielles, etc.) et fonctionnelles pour le faire.
[0063] Conformément à l'invention, lorsqu'un premier serveur de mitigation détermine qu'il n'est pas capable de traiter un message de sollicitation, par exemple ici parce qu'il n'est pas habilité à le faire, il cherche à identifier un deuxième serveur de mitigation habilité à traiter le message de sollicitation qu'il a reçu.
[0064] On présente, en relation avec la [FIG. 1], différents équipements d'un réseau de communication mettant en œuvre un procédé d'identification d'au moins un serveur de mitigation selon un mode de réalisation de l'invention.
[0065] On considère un premier domaine client 11 comprenant une ou plusieurs machines (dispositifs informatiques), 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é administrative. Le domaine client 11 comprend par exemple plusieurs nœuds clients Cl, C2, C3 et Cm, m désignant un entier supérieur ou égal à 1, communiquant avec un premier serveur de mitigation S12.
[0066] Le premier serveur de mitigation S12 appartient à un premier domaine serveur 12, tandis qu'un deuxième serveur de mitigation S13 appartient à un deuxième domaine serveur 13 et un troisième serveur de mitigation S14 appartient à un troisième domaine serveur 14. Chacun de ces domaines serveurs 12, 13, 14 contribue à la mise en œuvre d'un service DPS permettant notamment de distinguer le trafic « légitime », Le., les données consenties par l'utilisateur, du trafic « suspect ». Dans le mode de réalisation décrit ici, on considère que les domaines serveurs 12, 13 et 14 sont gérés par des entités administratives distinctes. Toutefois en variante, ils peuvent être gérés par une même entité administrative. Par ailleurs, par souci de simplification ici, on considère un seul serveur de mitigation associé à chaque service DPS et à chaque domaine serveur. Toutefois, il est possible en variante d'envisager plusieurs serveurs de mitigation par domaine serveur, ceux-ci pouvant être configurés pour protéger des ressources distinctes ou des ressources communes du domaine client 11.
[0067] Un service DPS peut être hébergé au sein des infrastructures exploitées par les fournisseurs d'accès ou dans le « cloud » (en français « nuage »).
[0068] Ainsi, un domaine client, tel que le domaine client 11 s'interface avec un ou plusieurs domaines serveurs 12, 13. Par abus de langage on dira qu'un domaine client tel que le domaine client 11 s'interface avec plusieurs services DPS.
[0069] La détection d'une attaque, telle qu'une attaque DDoS, au sein d'un domaine client tel que le domaine client 11, peut être effectuée par un nœud client DOTS du domaine client concerné par l'attaque, tel que le nœud client Cl, ou au moyen d'une fonction dédiée, appelée détecteur DDoS (DDoS Detector, en anglais), ou les deux. De manière générale, un ou plusieurs détecteurs DDoS peuvent être activés au sein d'un même domaine client DOTS. Dans la suite, aucune hypothèse n'est faite quant à l'architecture interne d'un domaine client ni aux mécanismes de détection DDoS mis en œuvre au sein du domaine.
[0070] Enfin, la présente solution peut être mise en œuvre indépendamment de la nature des infrastructures réseau utilisées par les composantes (clients, serveurs) d'une architecture DOTS : ces réseaux peuvent être des réseaux IP, des réseaux mobiles (5G, B5G, 6G), etc.
[0071] 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, C2, C3 et Cm sont des clients DOTS et les serveurs de mitigation S12, S13, S14 sont des serveurs DOTS. Les nœuds clients Cl, C2, C3, Cm et les serveurs S12, S13, S14 peuvent ainsi communiquer via des canaux de signalisation et/ou de données DOTS définis en relation avec l'art antérieur, pour informer les serveurs S12, S13, S14 au moyen de requêtes DOTS telles que décrites précédemment que des actions de protection sont requises, comme par exemple, la mitigation d'attaques ou la mise en place de règles de filtrage. Bien que décrite en relation avec une architecture DOTS, la présente solution peut être mise en œuvre dans le cadre d'autres types d'architectures, telles que par exemple des architectures propriétaires ou des architectures exploitant une signalisation reposant sur le protocole NETCONF. Elle s'applique par ailleurs à d'autres attaques que des attaques DDoS, comme par exemple à des attaques par intrusion.
[0072] 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.
[0073] Les communications DOTS entre un domaine client et un serveur de mitigation 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 de mitigation, ou des deux. En d'autres termes, un nœud client du domaine client peut communiquer directement avec le serveur de mitigation, ou transmettre une requête à une passerelle du domaine client qui communique directement avec le serveur de mitigation ou avec une passerelle du domaine du serveur de mitigation, ou transmettre une requête à une passerelle du domaine du serveur de mitigation qui communique avec le serveur de mitigation. Il convient de noter qu'une passerelle DOTS localisée dans un domaine client est considérée par un serveur DOTS comme un client DOTS.
[0074] 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 le domaine du serveur de mitigation, l'authentification des clients DOTS peut être confiée à la passerelle DOTS du domaine du serveur de mitigation. Un serveur DOTS peut être configuré avec une liste des passerelles DOTS de confiance, actives au sein de son domaine et le serveur de mitigation peut déléguer certaines de ses fonctions à ces passerelles de confiance. En particulier, le serveur de mitigation peut utiliser en toute sécurité les informations fournies par une passerelle figurant dans une liste déclarée auprès du serveur de mitigation 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 de mitigation, récupération de la liste auprès d'un serveur d'authentification tel qu'un serveur AAA (pour « Authentication, Authorization and Accounting »), etc.).
[0075] Les modes de réalisation de la présente solution 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 du serveur de mitigation, domaine client distinct du domaine du serveur de mitigation, etc.).
[0076] Dans la présente solution, on suppose que chaque domaine client DOTS, tel que le domaine client 11, dispose d'au moins un identifiant appelé par exemple ici « DOTS Administrative Domain Identifier » ou DADI, alloué de façon globalement unique au domaine client DOTS, et défini pour les besoins de l'invention. Cet identifiant DADI reflète le fait que le domaine client est protégé par au moins un service DPS et permet d'identifier ledit au moins un service DPS associé au domaine client. Un même domaine client 11 peut disposer d'un ou plusieurs identifia nt(s) DADI DADI-lli.
[0077] Un tel identifiant DADI fait donc le lien entre un domaine client, tel que le domaine client 11, et au moins un service DPS pouvant être mis en œuvre afin d'assister les nœuds clients du domaine client considéré en cas d'attaque. Un tel lien est utilisé par la suite pour identifier au moins un serveur de mitigation mettant en œuvre le service DPS en question, et capable de traiter le message de sollicitation. Comme mentionné précédemment, dans l'implémentation particulière décrite ici, un serveur de mitigation capable de traiter un message de sollicitation est un serveur habilité à le faire (autrement dit qui dispose des autorisations nécessaires pour traiter ce message de sollicitation). Dans une variante d'implémentation, un serveur de mitigation capable de traiter un message de sollicitation est non seulement habilité à le faire mais également dispose des ressources nécessaires pour traiter ce message ou pour s'interfacer avec une entité externe (ex. « mitigator ») apte à le traiter.
[0078] Un même identifiant DADI peut être utilisé pour identifier plusieurs services DPS associés à un même domaine client. Un domaine client peut avoir des ressources (par ex. des préfixes IP sous la surveillance des nœuds clients) gérées (protégées) par un premier serveur de mitigation mettant en œuvre un premier service DPS et d'autres ressources gérées par un deuxième serveur de mitigation mettant en œuvre un deuxième service DPS. Un même identifiant DADI peut alors être utilisé pour les communications avec des serveurs de mitigation distincts. Le premier et le deuxième service DPS sont par exemple gérés par des entités administratives distinctes. Toutefois, en variante, ils peuvent être gérés par la même entité administrative.
[0079] Il convient de noter qu'un identifiant DADI permet, contrairement à d'autres identifiants connus tels que les identifiants CUID et CDID, d'identifier un domaine client et non pas un nœud client. L'utilisation d'un identifiant de domaine client permet de s'assurer que quel que soit le nœud client (du domaine client) à l'origine de l'émission du message de sollicitation, celui-ci est émis à destination d'un serveur de mitigation qui, à défaut d'être capable de le traiter, mettra en œuvre la présente solution permettant d'identifier un serveur de mitigation habilité à traiter le message de sollicitation.
[0080] Cela n'est pas le cas si l'on utilise un identifiant d'un nœud client. En effet, des nœuds clients appartenant à un même domaine client peuvent être gérés par des serveurs de mitigation différents. Si l'on se limite à l'utilisation d'un identifiant d'un nœud client, un autre serveur de mitigation ne pourra pas traiter le message de sollicitation car il n'est pas habilité à le faire et ainsi le message de sollicitation restera sans réponse. [0081] De plus, un tel identifiant CDID ne peut pas être utilisé pour identifier un autre serveur de mitigation habilité car cet identifiant CDID est généré sur la base d'un condensé (ou hash) d'un certificat du nœud client utilisé pour authentifier ce dernier auprès d'un serveur de mitigation donné. Ce condensé étant propre à cette association, il ne peut donc être réutilisé à d'autres fins.
[0082] Un identifiant DADI peut être alloué à un domaine client par un fournisseur de services DPS. Dans un tel cas de figure, on s'assure que les espaces d'identification utilisés par différents fournisseurs de services DPS ne se recouvrent pas, par exemple en coordonnant l'attribution des identifiants DADI entre les fournisseurs de services DPS ou en utilisant un espace d'identification hiérarchique (par ex. l'identifiant DADI contient une partie qui est unique à chaque fournisseur de services DPS). De cette sorte, on s'assure que chaque identifiant DADI est globalement unique (c'est-à-dire sur l'ensemble des domaines clients considérés). En effet, pour les besoins de la présente solution, il est important qu'un identifiant DADI identifie de manière non-ambiguë un domaine client donné et permette ainsi d'établir un lien avec le ou les services DPS chargés de protéger ce domaine client.
[0083] Dans un autre exemple, pour s'assurer de cette unicité globale, les identifiants DADI peuvent être alloués aux domaines clients par une entité indépendante, telle que l'IANA (ou « Internet Assigned Numbers Authority » en anglais). L'implication d'une telle autorité indépendante permet de s'assurer qu'il n'y a pas de recouvrement entre les différents identifiants DADI alloués aux domaines clients.
[0084] Dans un exemple, un même identifiant DADI DADI-lli associé (c'est-à-dire alloué) au domaine client 11, peut être utilisé par plusieurs services DPS. Dans un autre exemple, un identifiant DADI DADI-II2 associé au domaine client 11 est spécifique à un deuxième service DPS2 mis en œuvre, par exemple par le serveur de mitigation S13 et n'est, par conséquent, pas reconnu par un premier service DPS1 mis en œuvre, par exemple par le serveur de mitigation S12 ou encore par un troisième service DPS3 mis en œuvre, par exemple par le serveur de mitigation S14. Par exemple, le domaine client 11 dispose d'un identifiant DADI DADI-II3 spécifique au troisième service DPS3.
[0085] Dans le mode de réalisation décrit ici, l'ensemble des identifiants DADI alloués à différents domaines clients DOTS sont maintenus dans un premier registre d'identifiants DADI accessible à une pluralité de services DPS (et aux serveurs de mitigation contribuant à la mise en œuvre de ces services DPS). Ce premier registre établit une correspondance entre des noms de domaines clients et les identifiants DADI alloués aux domaines clients associés à ces noms de domaines clients. Ainsi, une entrée d'un tel registre peut se présenter de la manière suivante :
[0086] [Tablel]
Figure imgf000018_0001
où les entiers « ij » et « kl » font référence respectivement à des domaines clients « ij » et « kl ».
[0087] Un tel premier registre d'identifiants DADI peut être par exemple stocké dans un registre DNS. De tels registres DNS étant, en général, déjà déployés dans un réseau, il est avantageux de les utiliser pour mémoriser les informations relatives à ces identifiants DADI. En effet, ces registres DNS étant connus des différents nœuds des domaines clients, leur interrogation par les nœuds clients est aisée. Bien entendu, d'autres types de registres peuvent être considérés pour stocker le premier registre d'identifiants DADI (par ex. base de données SQL (Structured Query Language) ou LDAP (Lightweight Directory Access Protocol)).
[0088] En outre, le premier registre d'identifiants DADI peut être privé, c'est-à-dire que l'accès aux données qu'il maintient est restreint, ou public, c'est-à-dire que l'accès aux données qu'il maintient est libre. L'utilisation d'un registre d'identifiants DADI privé ou public relève d'un choix d'ingénierie. Il convient toutefois de noter que l'utilisation d'un registre d'identifiants DADI public peut donner accès à des informations sensibles, par exemple, l'absence d'une entrée dans le registre d'identifiants DADI pour un domaine client donné peut indiquer que ce domaine n'est pas protégé contre des attaques. Cette information peut être exploitée par les attaquants contre les domaines clients concernés.
[0089] Lorsque le premier registre d'identifiants DADI est un registre DNS, des entrées de type DNS SVCB, telles que définies dans le document I-D.ietf-dnsop-svcb-https, peuvent être utilisées pour associer un nom de domaine client DOTS, tel que le domaine client 11, avec son/ses identifiants DADI, DADI-lli, DADI-112, DADI-II3. Le choix d'utiliser ce type d'entrées repose sur le fait que, les entrées DNS SVCB comprenant plusieurs paramètres de services, il est ainsi possible d'utiliser l'un de ces paramètres de services pour y mémoriser le ou les identifiants DADI d'un domaine client. Il n'est alors pas nécessaire de créer de nouveaux types d'entrées.
[0090] De façon connue, les paramètres de service d'une entrée DNS SVCB sont appelés SvcParams (pour « Service Parameters » en anglais), et chacun de ces paramètres de service est caractérisé par une clé (SvcParamKey) et une valeur (Value). Dans le mode de réalisation décrit ici, il est donc proposé de définir un nouveau paramètre de service correspondant à une clé « SvcParamKey » que l'on appelle ici « dadi » à titre illustratif, et valorisé avec la liste des identifiants DADI associés au domaine client 11 à savoir DADI-lli, DADI-II2 et DADI-II3. [0091] Un exemple d'une demande de création d'une entrée de type DNS SVCB dans le premier registre d'identifiants DADI associant le domaine client 11 « dots-client.example.com » à l'identifiant DADI-lli dont la valeur est « 4572sdl74sfl », se présente comme suit :
_dots-client.example.com. 7200 IN SVCB 1 alpn=dots dadi=4572sdl74sfl simple. example.
[0092] A réception d'une requête DNS de type SVCB émise par un serveur de mitigation afin d'obtenir le ou les identifia nt(s) DADI associés au domaine client 11, le premier registre d'identifiants DADI retourne le ou les identifiants DADI associés au domaine client 11.
[0093] Parallèlement, les différents fournisseurs de services DPS exploitant les serveurs de mitigation S12, S13, S14, selon la présente solution maintiennent un deuxième registre d'identifiants DADI, dit DPS_Active_DADI, dont chaque entrée associe un ou plusieurs identifia nt(s) DADI associé(s) à un domaine client DOTS, tel que le domaine client 11, avec des données relatives à un ou plusieurs serveurs de mitigation mettant en œuvre un service DPS. Ce deuxième registre DPS_Active_DADI peut se présenter de la manière suivante :
[0094] [Table2]
Figure imgf000019_0001
;0095] Ce deuxième registre DPS_Active_DADI peut également être stocké dans un registre de type DNS. Bien entendu, d'autres types de registres peuvent être considérés comme, par exemple, un annuaire LDAP ou une base de données SQL tels que cités précédemment.
[0096] Chaque fournisseur de services DPS procède, pour les services DPS qu'il fournit, à l'ajout ou la suppression d'entrées dans ce deuxième registre DPS_Active_DADI selon des accords passés avec les différents domaines clients DOTS pour lesquels ils sont habilités à mitiger des attaques et à protéger des ressources. Des API (pour « Application Programming Interface » en anglais) dédiées peuvent être utilisées à cet effet.
[0097] Un exemple de création d'une entrée dans le registre DPS_Active_DADI est décrit ci-après. On appelle REGISTER(dadi) une primitive utilisée pour ajouter une entrée au registre DPS_Active_DADI. Une telle primitive indique qu'un ou plusieurs identifia nt(s) DADI est associé avec un ou plusieurs serveur(s) de mitigation identifié(s) par un jeu de paramètres DPS_Contact_Point qui peut comprendre notamment ici, une information d'identification telle qu'un nom de domaine, des informations de localisation telles qu'une ou plusieurs adresses IP, un ou plusieurs numéros de port, ainsi que d'autres informations telles que par exemple une durée de validité de l'enregistrement, etc.
[0098] De même, on appelle DELETE (dadi) une primitive utilisée pour supprimer une entrée dans ledit registre DPS_Active_DADI. Cette primitive est utilisée par exemple pour supprimer un enregistrement quand un domaine client n'utilise plus les services de mitigation d'un fournisseur de services DPS donné.
[0099] Dans un exemple d'implémentation, les primitives REGISTER et DELETE sont authentifiées afin de s'assurer qu'un fournisseur de services DPS est habilité à procéder à une opération relative à un identifiant DADI dans le registre DPS_Active_DADI.
[0100] La [FIG. 2] illustre les principales étapes des procédés d'identification d'au moins un serveur de mitigation et de protection d'un domaine client contre une attaque informatique objet de la présente solution.
[0101] Ainsi, dans une étape El, un nœud client Cl du domaine client 11 détecte une attaque ciblant tout ou partie des ressources du domaine client 11, de façon connue en soi et non décrite ici. Une telle attaque peut ne pas avoir encore touché le domaine client 11.
[0102] Afin de mitiger cette attaque, le nœud client Cl émet, dans une étape E2, un message de sollicitation d'une assistance dans la gestion d'attaques à destination d'un premier serveur de mitigation DOTS, par exemple ici le serveur de mitigation S12, afin de signaler l'attaque dont il est la cible et demander l'exécution d'un service de mitigation (« Request Mitigation ») afin de traiter cette attaque. Un message de sollicitation est par exemple une requête DOTS.
[0103] Le nœud client Cl insère un nouveau paramètre DOTS appelé ici « dadi » dans le message de sollicitation « Request Mitigation », et plus particulièrement dans un entête de ce message de sollicitation. Ce nouveau paramètre « dadi », inséré pour les besoins de la présente solution, comprend le ou les identifia nt(s) DADI DADI-lli, DADI-II2 et DADI-II3, associés au domaine client 11 auquel appartient le nœud client Cl.
[0104] Un exemple des entêtes d'un tel message de sollicitation modifié conformément à la présente solution est fourni ci-après, pour l'exemple illustratif de l'identifiant DADI-lli envisagé précédemment et ayant la valeur « 4572sdl74sfl » :
Header: PUT (Code=0.03)
Uri-Host: "www.example.com"
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "cuid=mydotsclient"
Uri-Path: "mid=57956"
Uri-Path: "dadi=4572sdl74sfl"
Content-Format: "application/cbor"
[0105] Lorsque le message de sollicitation comprend plusieurs identifiants DADI, ces derniers peuvent être séparés au moyen d'un séparateur comme par exemple « ; » entre les identifiants (par ex. dadi=DADI-lli ; DADI-II2 ; DADI-II3), ou l'argument est répété (par ex. Uri-Path: "dadi=DADI-lli", Uri-Path:"dadi=DADI-112", Uri-Path:"dadi=DADI-113"). Cette dernière possibilité est moins intéressante car elle augmente la taille du message de sollicitation (et donc le risque de fragmentation du message).
[0106] Les différents entêtes du message de sollicitation représentés ci-dessus sont définis dans le document RFC9132 publié par l'IETF (« Internet Engineering Task Force » en anglais). Ainsi, l'un des entêtes « Uri-Path », comprend, dans le cadre de la mise en œuvre de la présente solution, la valeur « 4572sdl74sfl » de l'identifiant DADI DADI-lli associé au domaine client 11.
[0107] En variante, le ou les identifiant(s) DADI sont insérés dans le corps du message de sollicitation « Request Mitigation » (par ex., les messages PUT ou POST).
[0108] Selon une autre variante de réalisation, qui peut être utilisée de façon alternative à ce qui vient d'être décrit ou de façon complémentaire, afin de s'assurer que les différents serveurs de mitigation recevant le message de sollicitation « Request Mitigation » puissent avoir accès à une valeur du paramètre DOTS « dadi » (par exemple, la requête « Request Mitigation » a été acheminée vers un serveur DOTS qui n'est pas en mesure de la déchiffrer), le nœud client Cl peut insérer une option UDP ou TCP, selon le protocole de transport utilisé pour envoyer le message de sollicitation « Request Mitigation ». Un exemple de format d'une telle option est conforme au format documenté dans la publication RFC793 de l'IETF.
[0109] A réception du message de sollicitation « Request Mitigation », le serveur de mitigation S12 détermine, au cours d'une étape E3, s'il est capable de traiter ce message, c'est-à-dire dans l'implémentation particulière envisagée ici, s'il est habilité à le faire. Cette détermination peut être réalisée par des moyens connus de l'homme du métier et non décrits en détail ici.
[0110] Si le serveur S12 est capable (i.e. habilité ici) de traiter le message de sollicitation, alors il informe le nœud client Cl qu'il peut répondre favorablement au message de sollicitation reçu, dans une étape E4. L'attaque impactant les ressources du domaine client 11 est alors mitigée de manière classique (soit directement par le serveur S12 soit en s'interfaçant avec une entité externe telle qu'un « mitigator »). [0111] Si au cours de l'étape E3, le serveur de mitigation S12 détermine qu'il n'est pas en mesure de traiter le message de sollicitation « Request Mitigation » car, dans l'implémentation particulière envisagée ici, il n'est pas habilité à gérer la ressource ciblée par l'attaque (identifiée par exemple par les champs « target-prefix », « target-uri », « target-fqdn », etc., du corps du message), alors le serveur de mitigation S12 cherche à identifier un autre serveur de mitigation habilité à traiter le message de sollicitation. A cet effet, le serveur de mitigation S12 cherche à obtenir au moins un identifiant DADI associé au domaine client 11 auquel appartient le nœud client Cl émetteur du message de sollicitation au cours d'une étape E5.
[0112] A ce stade, deux situations se présentent : une première situation dans laquelle le message de sollicitation « Request Mitigation » ne comprend aucun identifiant DADI associé au domaine client 11, et une deuxième situation (cas envisagé en exemple ici) dans laquelle le message de sollicitation « Request Mitigation » comprend au moins un identifiant DADI associé au domaine client 11 (dans son corps de message, dans l'un de ses champs d'entête, ou dans une option transport telle qu'une option UDP comme décrit précédemment).
[0113] Dans la première situation, le serveur S12 détermine alors un nom de domaine associé au domaine client 11. A cet effet, il extrait par exemple, un nom de domaine associé au domaine client 11 compris, par exemple, dans le certificat utilisé pour créer l'association (D)TLS requise au préalable pour l'envoi du message de sollicitation « Request Mitigation ». Puis il interroge au moyen du nom de domaine ainsi obtenu, le premier registre d'identifiants DADI en lui envoyant lors d'une étape E6, une requête SVCB. Le premier registre d'identifiants DADI utilise alors ce nom de domaine pour obtenir au moins un identifiant DADI DADI-lli, DADI-II2 et/ou DADI- II3, associé au domaine client 11. Une fois ces identifiants DADI DADI-lli, DADI-II2 et/ou DADI-II3 obtenus, ils sont transmis au serveur de mitigation S12 par le premier registre d'identifiants DADI.
[0114] Une fois en possession du ou des identifia nt(s) DADI DADI-lli, DADI-II2, DADI-II3 associé(s) au domaine client 11, le serveur S12, émet, dans une étape E7, une nouvelle requête, désignée par exemple ici par « QUERY_DPS_REGISTRY », et spécialement conçue pour les besoins de la présente solution, à destination du registre DPS_Active_DADI afin d'identifier au moins un serveur de mitigation, habilité à traiter le message de sollicitation « Request Mitigation » associé au(x) identifiant(s) obtenu(s). Comme indiqué en référence à la table 2, un tel registre DPS_Active_DADI est alimenté par les fournisseurs de services DPS dont les services DPS mettent en œuvre la présente solution.
[0115] Dans la deuxième situation, le serveur S12 extrait, au cours d'une étape E8, le ou les identifia nt(s) DADI présent(s) dans le message de sollicitation « Request Mitigation » et vérifie que cet (ces) identifia nt(s) DADI est (sont) bien associé(s) au service DPS qu'il contribue à mettre en œuvre. Une telle information est par exemple configurée localement au niveau de chaque serveur de mitigation.
[0116] Si le service DPS mis en œuvre par le serveur de mitigation S12 ne correspond pas à un service DPS associé à l'(aux) identifia nt(s) DADI extrait(s) du message de sollicitation, cela signifie que le message de sollicitation « Request Mitigation » a été acheminé par erreur au serveur S12 car le service DPS qu'il met en œuvre n'est pas un service DPS retenu par l'entité gestionnaire du domaine client 11 pour mitiger les attaques contre les ressources de ce domaine client indiquées dans le message de signalisation.
[0117] Dans ce cas, le serveur de mitigation S12 émet, dans une étape E9, une requête « QUERY_DPS_REGISTRY » à destination du registre DPS_Active_DADI afin d'identifier au moins un serveur de mitigation (S13 ou S14 dans l'exemple de la figure 1 envisagé ici) habilité à traiter le message de sollicitation « Request Mitigation » et associé à l'identifiant extrait du message de sollicitation.
[0118] Dans un autre exemple d'implémentation de l'invention, le serveur de mitigation S12 émet une requête « QUERY_DPS_REGISTRY » à destination du registre DPS_Active_DADI afin d'identifier au moins un serveur de mitigation (S13 ou S14 dans l'exemple de la figure 1 envisagé ici) habilité et apte à traiter le message de sollicitation « Request Mitigation », et associé à l'identifiant extrait du message de sollicitation. Dans cet exemple, il est supposé une publication en temps réel des informations relatives aux différents serveurs de mitigation ou une interrogation des informations du serveur de mitigation afin de déterminer l'aptitude de ce dernier à traiter le message de sollicitation.
[0119] Par exemple, le serveur de mitigation S12 met en œuvre le service de mitigation (DPS1 dans l'exemple envisagé ici) qui est associé à l'identifiant DADI DADI-lli alloué au domaine client 11. On suppose dans cet exemple que l'identifiant DADI extrait du message de sollicitation est l'identifiant DADI-II3. En consultant le registre DPS_Active_DADI, le serveur de mitigation S12 constate que l'identifiant DADI DADI-II3 ne correspond pas à l'identifiant DADI DADI-lli associé au service DPS1 de mitigation qu'il met en œuvre. Le serveur de mitigation S12 interroge alors le registre DPS_Active_DADI afin d'identifier, au moyen de l'identifiant DADI-II3 extrait du message de sollicitation, un serveur de mitigation associé à l'identifiant DADI-II3. Il obtient lors de cette étape les données relatives au serveur de mitigation en question (S14 dans l'exemple illustratif envisagé ici).
[0120] Dans le cas de figure où l'identifiant DADI extrait par le serveur S12 au cours de l'étape E8 est bien associé au service DPS du serveur de mitigation S12 et que le serveur de mitigation S12 n'est pas habilité à traiter le message de sollicitation, cela veut dire, dans le mode de réalisation décrit ici, qu'un même identifiant DADI est utilisé par plusieurs services DPS (cas non représenté dans la table 2). [0121] En effet, dans cette situation, l'identifiant DADI extrait par le serveur S12 au cours de l'étape E8 identifie des services DPS chargés de protéger le domaine client 11 ; cependant le serveur S12 bien qu'habilité à protéger certaines ressources du domaine client 11 (par ex. 1.2.3.4/32), n'est pas habilité à protéger d'autres ressources (par ex. 11.12.13.14/32) à l'origine du message de sollicitation.
[0122] Dans ce cas, dans le mode de réalisation décrit ici, le serveur de mitigation S12 utilise le nom de domaine du domaine client 11 se trouvant par exemple dans le certificat utilisé pour créer l'association (D)TLS requise au préalable pour l'envoi du message de sollicitation « Request Mitigation » comme décrit précédemment, afin d'émettre, dans une étape E10, une requête SVCB à destination du premier registre d'identifiants DADI pour obtenir le ou les identifiants DADI associé(s) au domaine client 11.
[0123] A réception du ou des identifia nt(s) DADI associé(s) au domaine client 11, le serveur S12, émet ensuite, dans une étape Eli, une requête « QUERY_DPS_REGISTRY » à destination du registre DPS_Active_DADI afin d'identifier au moins un serveur de mitigation habilité à traiter le message de sollicitation « Request Mitigation ».
[0124] Par exemple, le serveur de mitigation S12 contribue à mettre en œuvre un service de mitigation qui est associé à l'identifiant DADI DADI-lli associé au domaine client 11. L'identifiant DADI extrait du message de sollicitation est l'identifiant DADI-lli. Le serveur de mitigation S12 constate que l'identifiant DADI extrait du message de sollicitation, DADI-lli, correspond au service DPS qu'il met en œuvre bien qu'il n'est pas capable de traiter ce message de sollicitation.
[0125] Le serveur de mitigation S12 interroge alors le premier registre d'identifiants DADI afin d'identifier le domaine client 11 associé à l'identifiant DADI-lli extrait du message de sollicitation reçu. Le serveur de mitigation obtient du premier registre d'identifiants DADI que l'identifiant DADI-lli est associé au domaine client 11. Le serveur de mitigation S12 obtient également l'information selon laquelle le domaine client 11 est associé en outre aux identifiants DADI-II3 et DADI-II2.
[0126] Le serveur de mitigation S12 interroge ensuite le registre DPS_Active_DADI afin d'identifier, au moyen de l'identifiant DADI-lli extrait du message de sollicitation et le cas échéant, des identifiants DADI-II3 et DADI-II2 obtenus en interrogeant le registre d'identifiants DADI, un autre serveur de mitigation contribuant à mettre en œuvre ici un service DPS différent du service DPS mis en œuvre par le serveur de mitigation S12 mais qui est également associé à l'identifiant DADI-lli extrait du message de sollicitation, ou à un autre identifiant DADI-II3 ou DADI-II2 associé à un service de mitigation protégeant les ressources du domaine client 11.
[0127] Dans une variante de réalisation, le serveur de mitigation S12 interroge le registre DPS_Active_DADI afin d'identifier, au moyen de l'identifiant DADI-lli extrait du message de sollicitation uniquement un autre serveur de mitigation contribuant à mettre en œuvre un service DPS different du service DPS mis en œuvre par le serveur de mitigation S12 mais qui est également associé à l'identifiant DADI-lli extrait du message de sollicitation.
[0128] La mise en œuvre de l'une ou l'autre des variantes peut dépendre d'accords éventuels passés entre le domaine client et les services de protection DPS, ou entre les services de protection DPS entre eux, etc.
[0129] Plus particulièrement, le serveur de mitigation S12 peut obtenir les informations de localisation des serveurs de mitigation habilités et susceptibles de répondre à la demande de mitigation initiale. La transmission de tout ou partie des informations qui identifient le ou les fournisseurs de services DPS qui exploitent lesdits serveurs de mitigation au serveur de mitigation S12 peut être conditionnée par l'existence éventuelle d'accords passés entre les différents fournisseurs de services DPS. Ainsi, le serveur de mitigation S12 peut n'avoir accès qu'aux informations de contact des fournisseurs de services DPS partenaires, selon les identifiants DADI associés à leurs clients, et qui figurent dans le registre DPS_Active_DADI.
[0130] En réponse à une requête « QUERY_DPS_REGISTRY », qu'elle ait été émise au cours de l'étape E7, E9 ou Eli, le serveur de mitigation S12 reçoit, au cours d'une étape E12, un message en provenance du registre DPS_Active_DADI.
[0131] Un tel message retourne un jeu de paramètres (c'est-à-dire des informations) DPS_Contact_Point associés à un ou plusieurs serveurs de mitigation a priori habilités à traiter le message de sollicitation. Comme précisé plus haut, un tel jeu de paramètres DPS_Contact_Point peut comprendre une information d'identification d'un serveur de mitigation tel qu'un nom de domaine, des informations de localisation de ce serveur de mitigation (par ex. une adresse IP, un numéro de port), et d'autres informations telles qu'une durée de validité de l'enregistrement, etc. relatives au service DPS qui lui est associé.
[0132] Ainsi, le serveur de mitigation S12 contacte le registre DPS_Active_DADI pour récupérer le ou les points de contact (serveurs de mitigation) des services DPS habilités à traiter la requête de mitigation selon les valeurs des identifiants DADI. La réponse du registre peut consister en la transmission de tout ou partie des points de contact DPS, selon que des accords ont été passés entre les différents fournisseurs de services DPS ou pas
[0133] Ainsi, à titre d'exemple, le serveur de mitigation S12 peut n'obtenir que les informations DPS_Contact_Point associées à des serveurs de mitigation mettant en œuvre le même service DPS, quelle que soit la localisation de ces serveurs de mitigation.
[0134] Dans un autre exemple, le serveur de mitigation S12 peut n'obtenir que les informations DPS_Contact_Point associées à des serveurs de mitigation localisés dans le même domaine serveur que lui mais disposant de ressources différentes des siennes, etc. [0135] Suite à la reception de ce message comprenant les informations DPS_Contact_Point, le serveur de mitigation S12 peut entreprendre au moins deux actions. Un tel choix d'une action à entreprendre s'effectue par exemple sur la base de politiques de traitement du trafic d'attaque qui lui sont fournies par le fournisseur de services de mitigation qui l'exploite.
[0136] Ainsi, une première action consiste à demander une redirection du message de sollicitation « Request Mitigation » vers un autre serveur de mitigation, identifié par un jeu de paramètres DPS_Contact_Point présent dans le message reçu au cours de l'étape E12.
[0137] Pour cela, le serveur de mitigation S12 émet, dans une étape E13, un message de redirection à destination du nœud client Cl, ce message de redirection comprend des informations permettant au nœud client Cl d'identifier (et le cas échéant de localiser) le serveur de mitigation à destination duquel il doit réémettre le message de sollicitation. Un exemple du corps d'un tel message de redirection est fourni ci -dessous :
{
"ietf-dots-signal-channel:redirected-signal": [
{
"alt-server": "dps-contact-pointl.name ",
"alt-server-record": [
"2001:db8:6401::l",
"2001:db8:6401::2"
]
},
{
"alt-server": "dps-contact-point2.name",
"alt-server-record": [
"2001:db8:3000::l",
"2001:db8:3000: :2"
]
}
]
} [0138] Un tel message comprend une liste de serveurs de mitigation alternatifs à destination desquels le message de sollicitation peut être réémis, correspondant aux jeux de paramètres DPS_Contact_Point reçus par le serveur de mitigation S12. Ces serveurs de mitigation sont identifiés dans les attributs « alt-server » dudit message de redirection. Selon les politiques adoptées, ce message de redirection peut être transmis en parallèle à tous les serveurs de mitigation identifiés dans la liste ou selon un ordre prédéfini.
[0139] A réception de ce message de redirection, le nœud client Cl réémet, dans une étape E14, le message de sollicitation « Request Mitigation » vers le ou les serveurs de mitigation identifiés dans le message de redirection, par exemple vers le serveur de mitigation S14. Si plusieurs serveurs de mitigation sont identifiés dans le message de redirection, le message de sollicitation peut être envoyé vers ces serveurs en parallèle ou en séquentiel.
[0140] A réception du message de sollicitation émis par le nœud client Cl au cours de l'étape E14, le serveur de mitigation S14 met en œuvre, à son tour, les étapes E3 à E15 précédemment décrites.
[0141] Il en sera ainsi jusqu'à ce qu'un serveur de mitigation capable de traiter le message de sollicitation soit identifié.
[0142] Une deuxième action consiste, pour le serveur de mitigation S12, à relayer, dans une étape E15, le message de sollicitation « Request Mitigation » vers le ou les serveurs de mitigation identifiés au cours de l'étape E12.
[0143] A réception du message de sollicitation relayé par le serveur de mitigation S12 au cours de l'étape E15, le serveur de mitigation identifié met en œuvre, à son tour, les étapes E3 à E15 précédemment décrites.
[0144] Il en sera ainsi jusqu'à ce qu'un serveur de mitigation capable de traiter le message de sollicitation ainsi relayé de serveur de mitigation en serveur de mitigation soit identifié.
[0145] Lorsqu'un serveur de mitigation en mesure de traiter le message de sollicitation est identifié, l'attaque impactant les ressources du domaine client 11 peut alors être mitigée de manière classique (directement par le serveur en question ou en s'interfaçant avec une entité externe telle qu'un « mitigator »).
[0146] On note que dans l'exemple envisagé ici, le serveur de mitigation S12 a cherché à identifier, pour traiter le message de sollicitation, un serveur de mitigation mettant en œuvre un autre service DPS que lui. Toutefois, dans une variante de réalisation, on peut envisager qu'il identifie un autre serveur de mitigation habilité à traiter le message de sollicitation et mettant en œuvre le même service que lui. Dans cette variante, il est toutefois recommandé de mettre en place des mécanismes permettant d'éviter, lors d'une mise en œuvre récursive du procédé d'identification selon l'invention, qu'une boucle soit créée en sollicitant plusieurs fois un même serveur de mitigation incapable de traiter le message de sollicitation. Une telle boucle peut être évitée par exemple, en s'assurant que le serveur de mitigation ayant relayé le message de sollicitation est exclu de la liste des serveurs de mitigation vers lesquels le message de sollicitation peut être amené à être relayé.
[0147] On présente, en relation avec la [FIG. 3], la structure simplifiée d'un nœud client Cl, C2, C3, Cm selon l'un des modes de réalisation décrits ci-dessus.
[0148] Selon un mode de réalisation particulier, un nœud client Cl, C2, C3, Cm comprend une mémoire 101c comprenant une mémoire tampon, une unité de traitement 102c, é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 103c, mettant en œuvre des étapes des procédés d'identification d'au moins un serveur de mitigation et de protection d'un domaine client contre une attaque informatique selon un mode de réalisation de l'invention.
[0149] A l'initialisation, les instructions de code du programme d'ordinateur 103c sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 102c.
[0150] Le processeur de l'unité de traitement 102c met en œuvre des étapes du procédé d'identification d'au moins un serveur de mitigation et de protection d'un domaine client contre une attaque informatique décrit précédemment, selon les instructions du programme d'ordinateur 103c, pour :
- transmettre un message de sollicitation d'une assistance pour la gestion d'attaques à destination d'un premier serveur de mitigation d'attaques ;
- recevoir au moins une information d'identification d'au moins un deuxième serveur de mitigation d'attaques habilité à traiter ledit message de sollicitation, le premier et le deuxième serveur de mitigation d'attaques étant par exemple associés à des services de mitigation distincts ; et
- transmettre ledit message de sollicitation à destination dudit deuxième serveur de mitigation.
[0151] On présente, en relation avec la [FIG. 4], la structure simplifiée d'un serveur de mitigation S12, S13, S14 selon l'un des modes de réalisation décrits ci-dessus.
[0152] Par exemple, un serveur de mitigation S12, S13,S14 comprend une mémoire llls,c comprenant une mémoire tampon, une unité de traitement 112s, c, é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 113s, c, mettant en œuvre des étapes des procédés d'identification d'au moins un serveur de mitigation et de protection d'un domaine client contre une attaque informatique selon un mode de réalisation de l'invention. [0153] A l'initialisation, les instructions de code du programme d'ordinateur 113s, c sont par exemple chargees dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 112S.
[0154] Le processeur de l'unité de traitement 112s, c met en œuvre des étapes des procédés décrit précédemment, selon les instructions du programme d'ordinateur 113s,c, pour :
- recevoir un message de sollicitation d'une assistance pour la gestion d'attaques en provenance d'un nœud client du domaine client ; et lorsque ledit serveur de mitigation, dit premier serveur de mitigation, n'est pas capable de traiter ledit message de sollicitation : - obtenir, au moyen d'un identifiant dudit domaine client obtenu par le premier serveur de mitigation, au moins une information d'identification d'au moins un deuxième serveur de mitigation d'attaques habilité à traiter ledit message de sollicitation.

Claims

28 Revendications
[Revendication 1] Procédé d'identification d'au moins un serveur de mitigation d'attaques habilité à protéger un domaine client contre une attaque informatique, ledit procédé étant mis en œuvre par un premier serveur de mitigation d'attaques et comprenant :
- la réception d'un message de sollicitation d'une assistance pour la gestion d'attaques en provenance d'un nœud client du domaine client ; et lorsque ledit premier serveur de mitigation n'est pas capable de traiter ledit message de sollicitation:
- l'obtention, au moyen d'un au moins premier identifiant dudit domaine client obtenu par le premier serveur de mitigation, d'au moins une information d'identification d'au moins un deuxième serveur de mitigation d'attaques habilité à traiter ledit message de sollicitation.
[Revendication 2] Procédé d'identification d'au moins un serveur de mitigation selon la revendication 1 dans lequel au moins un dit premier identifiant dudit domaine client est obtenu par interrogation d'une première base de données au moyen d'un nom de domaine associé audit domaine client.
[Revendication 3] Procédé d'identification d'au moins un serveur de mitigation selon la revendication 1 dans lequel au moins un dit premier identifiant dudit domaine client obtenu est extrait dudit message de sollicitation.
[Revendication 4] Procédé d'identification d'au moins un serveur de mitigation selon l'une quelconque des revendications 1 à 3 dans lequel au moins un dit premier identifiant dudit domaine client est obtenu au moyen d'un deuxième identifiant dudit domaine client extrait du message de sollicitation.
[Revendication 5] Procédé d'identification d'au moins un serveur de mitigation selon la revendication 4 dans lequel ledit au moins un premier identifiant dudit domaine client est obtenu au moyen d'un nom de domaine dudit domaine client associé audit deuxième identifiant dudit domaine client.
[Revendication 6] Procédé d'identification d'au moins un serveur de mitigation selon l'une quelconque des revendications 1 à 5 comprenant une étape d'obtention d'au moins une information de localisation dudit deuxième serveur de mitigation par interrogation d'une deuxième base de données au moyen dudit premier identifiant dudit domaine client.
[Revendication 7] Procédé d'identification d'au moins un serveur de mitigation selon l'une quelconque des revendications 1 à 6 dans lequel ladite au moins une information d'identification dudit deuxième serveur de mitigation comprend au moins un nom de domaine d'un domaine associé audit deuxième serveur de mitigation.
[Revendication 8] Procédé d'identification d'au moins un serveur de mitigation selon la revendication 6 dans lequel ladite au moins une information de localisation dudit deuxième serveur de mitigation comprend au moins une adresse réseau dudit deuxième serveur de mitigation et/ou au moins un numéro de port dudit deuxième serveur de mitigation.
[Revendication 9] Procédé d'identification d'au moins un serveur de mitigation selon l'une quelconque des revendications 1 à 8 comprenant en outre la transmission, à destination dudit nœud client, desdites informations d'identification et/ou de localisation dudit deuxième serveur de mitigation.
[Revendication 10] Procédé d'identification d'au moins un serveur de mitigation selon l'une quelconque des revendications 1 à 9 comprenant en outre la transmission, à destination dudit deuxième serveur de mitigation, dudit message de sollicitation.
[Revendication 11] Procédé de protection d'un domaine client contre une attaque informatique, ledit procédé étant mis en œuvre par un nœud client hébergé par le domaine client et comprenant :
- la transmission d'un message de sollicitation d'une assistance pour la gestion d'attaques à destination d'un premier serveur de mitigation d'attaques, ledit message de sollicitation comprenant au moins un identifiant dudit domaine client ; et
- la réception d'au moins une information d'identification, obtenue par ledit premier serveur de mitigation au moyen dudit au moins un identifiant, d'au moins un deuxième serveur de mitigation d'attaques habilité à traiter ledit message de sollicitation, le premier et le deuxième serveur de mitigation d'attaques étant associés à des services de mitigation distincts ; et
- la transmission dudit message de sollicitation à destination dudit deuxième serveur de mitigation.
[Revendication 12] Serveur de mitigation d'attaques, dit premier serveur de mitigation, habilité à protéger un domaine client contre une attaque informatique, et comprenant au moins un processeur configuré pour :
- recevoir un message de sollicitation d'une assistance pour la gestion d'attaques en provenance d'un nœud client du domaine client ; et lorsque ledit premier serveur de mitigation n'est pas capable de traiter ledit message de sollicitation:
- obtenir, au moyen d'un identifiant dudit domaine client obtenu par le premier serveur de mitigation, au moins une information d'identification d'au moins un deuxième serveur de mitigation d'attaques habilité à traiter ledit message de sollicitation.
[Revendication 13] Nœud client hébergé par un domaine client comprenant au moins un processeur configuré pour : - transmettre un message de sollicitation d'une assistance pour la gestion d'attaques à destination d'un premier serveur de mitigation d'attaques, ledit message de sollicitation comprenant au moins un identifiant dudit domaine client ;
- recevoir au moins une information d'identification, obtenue par ledit premier serveur de mitigation au moyen dudit au moins un identifiant, d'au moins un deuxième serveur de mitigation d'attaques habilité à traiter ledit message de sollicitation, le premier et le deuxième serveur de mitigation d'attaques étant associés à des services de mitigation distincts ; et
- transmettre ledit message de sollicitation à destination dudit deuxième serveur de mitigation. [Revendication 14] Signal destiné à être transmis par un nœud client hébergé par un domaine client à destination d'au moins un premier serveur de mitigation d'attaques, ledit signal comprenant un message de sollicitation d'une assistance pour la gestion d'attaques, ledit message de sollicitation comprenant au moins un identifiant dudit domaine client au moyen duquel au moins une information d'identification d'au moins un deuxième serveur de mitigation habilité à traiter ledit message de sollicitation peut être obtenue.
PCT/EP2022/086477 2021-12-20 2022-12-16 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 WO2023117802A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2113987A FR3131023A1 (fr) 2021-12-20 2021-12-20 Procédés d’identification d’au moins un serveur de mitigation et de protection d’un domaine client contre une attaque informatique, dispositifs, signal et dispositifs correspondants
FRFR2113987 2021-12-20

Publications (1)

Publication Number Publication Date
WO2023117802A1 true WO2023117802A1 (fr) 2023-06-29

Family

ID=82100635

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/086477 WO2023117802A1 (fr) 2021-12-20 2022-12-16 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

Country Status (2)

Country Link
FR (1) FR3131023A1 (fr)
WO (1) WO2023117802A1 (fr)

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
US20180109555A1 (en) * 2016-10-19 2018-04-19 Cisco Technology, Inc. Inter-domain distributed denial of service threat signaling

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
US20180109555A1 (en) * 2016-10-19 2018-04-19 Cisco Technology, Inc. Inter-domain distributed denial of service threat signaling

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"DDos Open Threat Signaling (DOTS) Architecture", August 2020, L'IETF
MORTENSEN ARBOR NETWORKS A ET AL: "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture; draft-ietf-dots-architecture-02.txt", DISTRIBUTED-DENIAL-OF-SERVICE OPEN THREAT SIGNALING (DOTS) ARCHITECTURE; DRAFT-IETF-DOTS-ARCHITECTURE-02.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 1 May 2017 (2017-05-01), pages 1 - 29, XP015119412 *
REDDY T ET AL: "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification; draft-ietf-dots-signal-channel-41.txt", no. 41, 6 January 2020 (2020-01-06), pages 1 - 108, XP015137150, Retrieved from the Internet <URL:https://tools.ietf.org/html/draft-ietf-dots-signal-channel-41> [retrieved on 20200106] *

Also Published As

Publication number Publication date
FR3131023A1 (fr) 2023-06-23

Similar Documents

Publication Publication Date Title
US20060072569A1 (en) Network address translation protocol for transmission control protocol connections
US8510548B1 (en) Method and discovery system for discovering encrypted peer-to-peer (EP2P) nodes associated with a particular EP2P network
EP3476095A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
Man et al. Dns cache poisoning attack: Resurrections with side channels
EP3857848B1 (fr) Procédé d&#39;allocation d&#39;un identifiant à un noeud client, procédé d&#39;enregistrement d&#39;un identifiant, dispositif, noeud client, serveur et programmes d&#39;ordinateurs correspondants
KR102254220B1 (ko) 익명화된 네트워크 트래픽 기반의 사이버 위협 정보 공유 방법 및 이를 이용한 시스템
WO2018130796A1 (fr) Procédés et dispositifs de vérification de la validité d&#39;une délégation de diffusion de contenus chiffrés
EP3788762A1 (fr) Procédé d&#39;envoi d&#39;une information et de réception d&#39;une information pour la gestion de réputation d&#39;une ressource ip
WO2023117802A1 (fr) Procédés d&#39;identification d&#39;au moins un serveur de mitigation et de protection d&#39;un domaine client contre une attaque informatique, dispositifs et signal correspondants
EP4066461B1 (fr) Procédé de coordination de la mitigation d&#39;une attaque informatique, dispositif et système associés
EP3815335A1 (fr) Procédés de vérification de la validité d&#39;une ressource ip, serveur de contrôle d&#39;accès, serveur de validation, noeud client, noeud relais et programme d&#39;ordinateur correspondants
EP3087719B1 (fr) Procédé de ralentissement d&#39;une communication dans un réseau
WO2015197978A1 (fr) Procede de protection d&#39;un routeur contre des attaques
EP3815336A1 (fr) Procédés de gestion du trafic associé à un domaine client, serveur, noeud client et programme d&#39;ordinateur correspondants
Pahlevan Signaling and policy enforcement for co-operative firewalls
WO2020065234A1 (fr) Procédés de protection d&#39;un domaine client, nœud client, serveur et programmes d&#39;ordinateur correspondants
FR3143150A1 (fr) Procédé de gestion d’un ensemble d’adresses IP, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés.
WO2020065233A1 (fr) Procédé de collaboration et de demande de collaboration entre services de protection associés à au moins un domaine, agents et programme d&#39;ordinateur correspondants
WO2024068722A1 (fr) Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants
WO2023242315A1 (fr) Procédé de communication entre deux équipements, premier équipement, deuxième équipement et programme d&#39;ordinateur correspondants.
WO2024121017A1 (fr) Procédés de détection d&#39;un serveur de résolution de noms de domaine malveillant, équipement, serveur de confiance et programme d&#39;ordinateur correspondants
FR3136075A1 (fr) Infrastructure de sécurité ; procédé et produit programme d’ordinateur associés.
FR3110802A1 (fr) Procédé de contrôle de l’attribution d’une adresse IP à un équipement client dans un réseau de communication local, procédé de traitement d’une requête d’attribution d’une adresse IP à un équipement client dans un réseau de communication local, dispositifs, équipement d’accès, équipement serveur et programmes d’ordinateur correspondants.
FR2950767A1 (fr) Procede de communications securisees dans un reseau de telecommunications

Legal Events

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

Ref document number: 22835447

Country of ref document: EP

Kind code of ref document: A1