WO2020002853A1 - Procédés de gestion du trafic associé à un domaine client, serveur, nœud client et programme d'ordinateur correspondants - Google Patents

Procédés de gestion du trafic associé à un domaine client, serveur, nœud client et programme d'ordinateur correspondants Download PDF

Info

Publication number
WO2020002853A1
WO2020002853A1 PCT/FR2019/051605 FR2019051605W WO2020002853A1 WO 2020002853 A1 WO2020002853 A1 WO 2020002853A1 FR 2019051605 W FR2019051605 W FR 2019051605W WO 2020002853 A1 WO2020002853 A1 WO 2020002853A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
server
attack
node
domain
Prior art date
Application number
PCT/FR2019/051605
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
Priority to US17/256,377 priority Critical patent/US11563816B2/en
Priority to EP19752541.3A priority patent/EP3815336A1/fr
Publication of WO2020002853A1 publication Critical patent/WO2020002853A1/fr

Links

Classifications

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

Definitions

  • the field of the invention is that of communications within a communication network, for example an IP network, and in particular that of value-added IP services.
  • the invention provides a solution for managing the traffic associated with a client domain, that is to say entering a client domain or leaving a client domain, in the event of a communication problem between the server and a client node in the client domain.
  • the invention offers a solution making it possible to avoid the systematic triggering of a mitigation procedure in the event of loss of connection between a server and a client node.
  • the invention notably finds applications in the field of mitigation of attacks by denial of distributed services (in English DDoS, for “Distributed Douai of Service”), for example implementing, but not exclusively, a DOTS type architecture (in English "DDoS Open Threat Signaling”), as standardized by the IETF.
  • denial of distributed services in English DDoS, for “Distributed Douai of Service”
  • DOTS type architecture in English "DDoS Open Threat Signaling”
  • 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 by using these hosts to amplify attacks.
  • DDoS Protection Services In order to overcome these DDoS attacks, services for detecting and mitigating DDoS attacks are offered by certain access or service providers to their customers. Such mitigation services (in English DPS for "DDoS Protection Services”) can be hosted within the infrastructures operated by access providers or in the “cloud” (in French “cloud”). They allow in particular to distinguish “legitimate” traffic, i.e., data consented by the user, from “suspicious” traffic.
  • DOTS DOTS
  • client client node
  • DOTS server server
  • a DOTS client attached to that client domain can send a message to the DOTS server asking for help.
  • the latter coordinates, with a mitigation entity (in English “mitigator”), the actions to be carried out so that the suspicious traffic, associated with the denial of service attack, is no longer routed to the client domain, while the traffic legitimate continues to be routed normally to the client domain.
  • a mitigation entity in English “mitigator”
  • This solution uses two communication channels between the DOTS client and the server
  • DOTS Signal Channel a DOTS signaling channel
  • DOTS Data channel in English "DOTS Data Channel”
  • the DOTS signaling channel is only used when a DDoS attack is in progress.
  • a DOTS client can use this channel to request assistance from the DOTS server.
  • a DOTS client uses this signaling channel to send a request to the server informing it that the prefix "1.2.3.0/24" is undergoing a DDoS attack, so that the server can take actions to end the attack .
  • Such a request is associated with a DOTS client identified by a unique identifier, noted for example CUID ("Client Unique Identifier").
  • a DOTS server can thus take the appropriate measures to end a DDoS attack on the one hand if the request from the DOTS client does not conflict with other requests from other clients in the same client domain, or with a filtering rule previously installed on the server by another client in the client domain, and on the other hand if the server is authorized to / configured to honor the last request received.
  • the server can send an error message, for example type 4.09 ("Conflict"), to inform the client.
  • Such a signaling channel is described in particular in the document “Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification”, draft-ietf-dots-signal-channel, Reddy, T. et al., January 2018.
  • DSS Distributed Denial-of-Service Open Threat Signaling
  • the DOTS data channel is used when no DDoS attack is in progress.
  • a DOTS client can use this channel to install filtering rules, such as filtering traffic received from certain addresses or traffic destined for a given node.
  • filtering rules such as filtering traffic received from certain addresses or traffic destined for a given node.
  • a DOTS client can use this DOTS data channel to request the server to block all traffic to the prefix "1.2.3.0/24".
  • the DOTS server can install filtering rules in response to a request sent by a client, if this request does not conflict with other requests from other clients in the same client domain or with a rule existing filtering. In the event of a conflict with other rules maintained by the DOTS server, the server can send an error message, for example of type 409 ("Conflict"), to inform the client.
  • Conflict type 409
  • Such a data channel is described in particular in the document “Distributed Denial-of- Service Open Threat Signaling (DOTS) Data Channel”, draft-ietf-dots-data-channel, Reddy, T. et al., December 2017.
  • DSS Distributed Denial-of- Service Open Threat Signaling
  • a DOTS server refuses to process an attack mitigation request sent by a DOTS client while the attack is real, or refuses filtering requests sent by a DOTS client (an objective of the filtering requests being to anticipate DDoS attacks).
  • Such a refusal can notably occur when clients in the client domain have previously asked the server to install filtering rules, but these rules are no longer justified (in English "stale").
  • the DOTS architecture was designed to support automatic mitigation of denial of service attacks by a server in the event of loss of the session established with a DOTS client.
  • the implementation of this procedure is dependent on the value of a mitigation trigger parameter, denoted "trigger-mitigation", associated with a DOTS client in the client domain during a configuration negotiation phase.
  • this mitigation trigger parameter is set by the DOTS client to “FALSE”, or “false” in English, the DOTS server automatically triggers a mitigation procedure if it no longer receives messages from this client DOTS.
  • incoming traffic that is to say intended for the client domain
  • the DOTS server decides to trigger the automatic mitigation procedure. Incoming traffic can thus be redirected to a traffic “purification” center (“DDoS scrubber” or “DDoS scrubbing center”, which is responsible for eliminating DDoS attack traffic.
  • a traffic “purification” center (“DDoS scrubber” or “DDoS scrubbing center”, which is responsible for eliminating DDoS attack traffic.
  • redirecting incoming traffic to a treatment center can be harmful to the customer because it increases the delay in transferring traffic, or even prevents the routing of traffic, while the absence of a message from a DOTS client is not necessarily due to a DDoS attack.
  • a DOTS server can delete all the filters activated by this client, which can adversely affect the proper routing of traffic to the client area.
  • the invention provides a new solution for managing traffic associated with a client domain, i.e., entering the client domain or leaving the client domain, implemented in a server, comprising:
  • o if no session is active the triggering of a mitigation procedure on at least one IP resource associated with the client domain
  • o if at least one session is active the use of the second client node (s) associated with the active session (s), known as the active node (s) (s), to initiate an action to manage the traffic associated with the client domain.
  • the proposed solution is based on the use of at least a second client node of the client domain, in the event of failure of the first client node, to trigger an action for managing traffic entering and / or leaving the client domain.
  • the proposed solution is therefore based on cooperation between the different client nodes belonging to the same client domain.
  • such a traffic management action implements the confirmation that an attack is in progress on at least one IP resource associated with the client domain or the redirection to a second active node of at least part of the traffic associated with at least one IP resource from the client domain.
  • the proposed solution makes it possible to improve the reliability of the responses to DDoS attacks and the coordination between the client nodes of the same domain, in particular the coordination of the mitigation actions of the DDoS attacks, by involving at least another domain client to verify the reality of an attack.
  • the solution proposed according to this embodiment thus makes it possible to avoid the increase in the delay in transferring incoming packets when they are unjustifiably routed to a traffic purification center (“scrubber”).
  • the proposed solution makes it possible to force the path taken by the traffic to request one or more other client nodes during a given period. Consequently, if a DDoS attack is effective, this or these client nodes will be able to report this attack to the server. If the server does not receive a message signaling an attack and requesting the implementation of a mitigation procedure, traffic can be redirected on the nominal path.
  • such cooperation between DOTS clients in the same domain makes it possible in particular to detect and eliminate obsolete entries ("stale") from the tables maintained by the server, for example the filtering rules that are no longer justified following the expiration of a session between the client and the server.
  • stale obsolete entries
  • the solution proposed according to this particular embodiment makes it possible to ensure consistency in the configuration of several clients belonging to the same domain.
  • the proposed solution allows a client node in the client domain to indicate to the server that it can delete entries associated with IP resources managed by another client node of the client domain.
  • the proposed management method can, according to at least one embodiment, apply to traffic leaving the client domain.
  • the server can detect an attack whose origin is the client domain. It can thus proceed to the notification of the client domain and possibly filter outgoing traffic.
  • the invention relates to one or more computer programs comprising instructions for implementing a traffic management method associated with a client domain according to at least one embodiment of the invention , when this or these programs is / are executed by a processor.
  • the invention relates to one or more non-removable, or partially or completely removable, information carriers, readable by a computer, and comprising instructions for one or more computer programs for execution steps of the traffic management method associated with a client domain according to at least one embodiment of the invention.
  • the methods according to the invention can therefore be implemented in various ways, in particular in wired form and / or in software form.
  • FIG. 1 illustrates an example of a communication network implementing a method of traffic management associated with a client domain, according to an embodiment of the invention
  • FIG. 2 presents the main steps of the traffic management method associated with a client domain, according to at least one embodiment of the invention
  • FIGS 3 and 4 illustrate two examples of application of the invention
  • FIG. 5 presents the main steps implemented by a DOTS server according to a first example of application of the invention
  • FIG. 6 illustrates the deletion, in tables maintained by the server, of IP resources which are no longer associated with a client domain
  • Figures 7A to 7D illustrate different variants for the implementation of a second verification phase, allowing confirmation / invalidation if an attack targets IP resources;
  • FIG. 8 presents the main steps implemented by a DOTS server according to a second example of application of the invention.
  • FIG. 9 to 12 illustrate different examples of traffic redirection according to the second example of application of the invention.
  • FIGS 13 and 14 illustrate the detection of conflicts between several clients in the same domain
  • FIG. 15 shows the simplified structure of a server and a client node according to a particular embodiment.
  • the general principle of the invention is based on the use of at least a second client node, belonging to a client domain, to manage traffic entering or leaving the client domain, in the event of a communication problem between the server and a first client node.
  • client domain 11 comprises one or more machines, also called nodes.
  • domain is understood here to mean a set of machines or nodes placed under the responsibility of the same entity.
  • the server 12 does not belong to the client domain 11. According to another example not shown, the server 12 can belong to the client domain 11.
  • FIG. 2 illustrates the main steps implemented for managing the traffic associated with the client domain 11.
  • the server 12 detects (21) a communication problem with a first node in the client domain, known as the failed node. For example, a communication problem is detected if a session between the server 12 and the faulty node is inactive for a duration greater than or equal to a predetermined threshold.
  • a session can be considered inactive if no presence message (for example, of the “heartbeat” type), intended to verify that a remote peer is still active, is received after a longer period or equal to a threshold predetermined noted Th.
  • the server 12 If a communication problem is detected between the server 12 and, for example, the node Cl 111, the server identifies (22) at least one second client node belonging to the client domain 11.
  • the server checks (23) if at least one session is active between the server 12 and the second client node (s).
  • a mitigation procedure 24 is triggered on at least one IP resource associated with the client domain. According to a particular embodiment, if no session is active, the triggering of a mitigation procedure is implemented on all the IP resources associated with the client domain.
  • the second node associated with the active session or sessions is used (25) to initiate an action for managing traffic in the client domain.
  • the mitigation procedure 24 is triggered on at least one IP resource associated with the client domain, and possibly on all IP resources associated with the domain customer. For example, such a mitigation procedure is implemented if more than half of the sessions established between the server and the client nodes in this domain are inactive.
  • Figures 3 and 4 illustrate two examples of application of the invention.
  • the traffic management action implements confirmation that an attack is in progress on at least one IP resource associated with the client domain.
  • the first example of application therefore makes it possible to verify that a DDoS attack is effective before triggering a mitigation procedure.
  • the traffic management action implements a redirection on the active node of at least part of the traffic associated with at least one IP resource from the client domain.
  • FIG. 3 illustrates the main steps of the traffic management method according to the first example of application.
  • the traffic management action implements confirmation that an attack is in progress on at least one IP resource associated with the client domain.
  • the traffic associated with an IP resource can be incoming traffic to an address extracted from this IP resource or outgoing traffic sent from this IP resource.
  • the server 12 transmits ( $ 31) to the active client node 112, and possibly to all the active client nodes in the client domain, at least one request message for confirmation of an attack on at least one IP resource associated with the client domain.
  • a message is noted MACR, OR "ATTACK_CONFIRMATION_REQUEST (Resources)".
  • the IP resources concerned can be explicitly indicated in the message, or not.
  • such a message specifies at least one IP resource, for example an IP resource associated with the failed client node 111 or with the client domain 11. The absence of specification of an IP resource in such a message can be interpreted as a request. confirmation of attack on all IP resources associated with the client domain.
  • IP resource belongs to the group comprising:
  • IP address for example an IPv4 or IPv6 prefix
  • IPv4 or IPv6 prefix for example the IP addresses of the different nodes of the client domain 11
  • IP prefix for example an IPv4 or IPv6 prefix
  • IP prefix for example an IP prefix associated with a connection router of the client domain 11
  • a domain name for example a domain name associated with client domain 11, etc.
  • the active client node 112 receives (32V 2 ) therefore at least one attack confirmation request message relating to at least one IP resource associated with the failed client node 111, or more generally to the client domain 11, coming from the server 12.
  • the active client node 112 checks (33c2) that the IP resource or resources identified in the attack confirmation request message (s) that it receives are effectively associated with the client domain 11.
  • the active client node 112 transmits (341V 2 ) to the server 12 at least one message of fault.
  • an error message is noted MERR, OR "ERROR (Unknown_Resources)".
  • such an error message can indicate the IP resource or resources which do not belong to the client domain 11.
  • Server 12 receives ( $ 342) therefore at least one error message from an active node, indicating that one or more IP resources identified in the attack confirmation request message do not belong to the client domain .
  • the server 12 can then delete ( $ 343) the IP resource or resources identified in the attack confirmation request message (s) or in the error message, from at least one table that it maintains.
  • the active client node 112 transmits (351V 2 ) to at least one client node of the client domain associated with the IP resources identified in the attack confirmation request message, at least one first attack verification message .
  • a first attack verification message is noted MVATTI ; OR
  • the client node receiving (352ci) this MVATTI message can respond to the active node, for example the active client node 112, by transmitting (353ci) a first status message indicating whether an attack is in progress or not.
  • a first status message is noted MSTATI, OR
  • the active client node 112 receiving (354V 2 ) this first status message can then transmit (355V 2 ) to the server 12 at least one first response message informing the server of the response to the first attack verification message.
  • a first response message is noted MREPI, OR “ATTACK_CONFIRMATION_REPLY (Resources, Status)” and indicates the status (attack in progress or not), and the IP resource or resources concerned.
  • the server 12 When the server 12 thus receives ( $ 356) at least a first response message from at least one active node, it can trigger ( $ 37) a mitigation procedure on at least one IP resource associated with the client domain if at minus a first response message confirms an attack.
  • the active client node 112 transmits (361V 2 ), to at least one node in the client domain implementing an attack detection function, at least one second attack verification message relating to at least one IP resource associated with the client domain.
  • a second attack verification message is noted MVATT2 ⁇ or "RESOURCE_PROBE (Rk)".
  • the node N receiving (362N) this message can respond to the active node, for example the active client node 112, by transmitting (363 ⁇ ) a second status message indicating whether an attack is in progress or not.
  • a second status message is noted M $ TAT2 / OR "RESOU RCE_PROBE (code)".
  • the active client node 112 receiving (364V 2 ) this second status message can then transmit (365V 2 ) to the server 12 at least one second response message informing the server of the response to the second attack verification message.
  • a second response message is noted MREP 2 , OR "ATTACK_CONFIRMATION_REPLY (Resources, Status) ”and indicates the status (attack in progress or not), and the IP resource (s) concerned.
  • the server 12 When the server 12 thus receives ( $ 366) at least one second response message from at least one active node, it can trigger ( $ 37) a mitigation procedure on at least one IP resource associated with the client domain if at minus a second response message confirms an attack.
  • the first and second variants are implemented.
  • the active client node 112 therefore transmits at least a first attack verification message to at least one client node of the client domain (for example, to the client node (s) associated with the identified IP resources. in the attack confirmation request message) (351C2), and / or at least a second attack verification message to at least one node of the client domain implementing an attack detection function (361V 2 ) , taking into account at least one selection criterion.
  • the active client node chooses to which node (s) (client node (s) or node (s) activating an attack detection function) it sends attack verification messages.
  • the selection criterion is for example the volume of traffic passing through the neighboring nodes of the active node.
  • the server 12 when it receives at least one response message from said at least one active node (first and / or second response message (s)), it can trigger (37 $ ) a mitigation procedure on at least an IP resource associated with the client domain if at least one response message confirms an attack.
  • the server 12 triggers ( $ 37) a mitigation procedure on at least one IP resource associated with the client domain, if no response to the attack confirmation request message is received for a predetermined duration .
  • the traffic management action is a redirection, on the active node, of at least part of the traffic associated with an IP resource of the client domain.
  • an IP resource can be managed by the failing node.
  • the server 12 can implement, beforehand, a selection (41) of the part of the traffic to be redirected.
  • the selection belongs to the group comprising:
  • a selection of the traffic associated with an IP resource in the client domain ie incoming traffic to an address extracted from this IP resource or outgoing traffic sent from this IP resource
  • a number of network resources greater than or equal to a number predetermined, for example the majority of network resources.
  • the traffic to be managed can be incoming traffic destined for an address extracted from an IP resource or outgoing traffic sent from this IP resource.
  • the server then directs the portion of the selected traffic to the active node, for example node 112.
  • the redirection is implemented for a predetermined duration.
  • the server 12 redirects part of the traffic, initially routed by a path passing through this faulty client node to secondary paths passing through one or more client nodes in the same client domain having an active session with the server.
  • the active node (s) can trigger a mitigation procedure if it (s) finds (s) that the traffic on this active node is illegitimate traffic, i.e., corresponds to a DDoS attack.
  • the method of managing traffic associated with a client domain comprises checking that all the client nodes in the client domain have previously agreed to implement the steps described above which concern them, and in particular the steps of detecting a communication problem between the server and a first client node of the client domain, of identification of at least a second node client of the client domain, and checking that at least one session associated with this second client node is active.
  • the verification of the fact that all the client nodes in the client domain have previously accepted the implementation of the traffic management method implements the control of the value of a mitigation trigger parameter, noted for example “trigger -mitigation ”, associated with each client node in the client domain during a configuration negotiation phase.
  • a mitigation trigger parameter noted for example “trigger -mitigation ”
  • the value of the trigger-mitigation parameter must be equal to "FALSE".
  • the traffic management action can be interrupted if the server receives a message from the faulty node. Indeed, the receipt of such message from the failed node means that the session between the server and the failed node is active again. The latter can optionally order a mitigation action if necessary.
  • Examples of implementation of the invention are described below in a DOTS-type architecture, according to which the client nodes Cl 111, C2 112, C3 113 and Cm 114 are DOTS clients and the server S 12 is a server.
  • DOTS DOTS.
  • the client nodes C1 111, C2 112, C3 113, Cm 114 and the server S 12 can thus communicate via the DOTS signaling and data channels defined in relation to the prior art, to inform the server that the client domain is undergoing a DDoS attack and that appropriate actions are required.
  • a 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 client's domain
  • a signaling message to request the mitigation of a denial of service attack with a DOTS server, the server being able, on reception of such a message, to trigger the actions necessary to end the attack,
  • a message for managing filtering rules such as requesting a DOTS server to install (or have installed) an access control list (ACL).
  • ACL access control list
  • a DOTS request can be sent from a DOTS client, belonging to a DOTS client domain, to a DOTS server or to a plurality of DOTS servers.
  • a DOTS domain can accommodate one or more DOTS clients.
  • several client nodes in a client domain can have DOTS functions.
  • DOTS communications between a client domain and a server can be direct, or established via DOTS gateways (in English "DOTS gateways"). These gateways can be hosted within the client domain, the server domain, or both.
  • DOTS gateways in English "DOTS gateways"
  • a node in the client domain can communicate directly with the server, or transmit a request to a gateway in the client domain which communicates directly with the server or with a gateway in the server domain, or transmit a request to a gateway in the server domain that communicates with the 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 a server domain, authentication of DOTS clients can be entrusted to the DOTS gateway in the server domain.
  • a DOTS server can be configured with the list of DOTS gateways active within its domain and the server can delegate some of its functions to these trusted gateways.
  • the server can safely use the information provided by a gateway appearing in a list declared to the 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 server, retrieving 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 server, retrieving 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 gateways in the client domain or in the server domain, client domain separate from the server domain, etc.
  • DOTS Distributed Denial-of-Service Open Threat Signaling
  • DOTS agents clients (s), server (s)
  • DOTS server authenticate each other.
  • a secure communication channel for example of the (D) TLS type, between a DOTS client and a DOTS server.
  • the different steps implemented by a DOTS client and a DOTS server are presented below, with reference to FIGS. 1 to 4.
  • the client nodes 111 to 114 of FIG. 1 are DOTS clients and that the server 12 in FIG. 1 is a DOTS server.
  • the client domain is therefore a DOTS domain.
  • a first example of application of the invention is presented below in more detail, according to which the traffic management action implements confirmation that an attack is in progress on at least one IP resource associated with the client domain. .
  • This first example of application therefore makes it possible to verify that a DDoS attack is effective before triggering a mitigation procedure, and therefore offers a solution making it possible to avoid unnecessary triggering of mitigation operations.
  • DDoS detector DDoS Detector
  • One or more DDoS detectors can be activated per DOTS domain.
  • the DOTS server monitors the state of the connections with the DOTS clients, or more generally monitors the DOTS sessions, ie, the connections of signaling channels established between the DOTS server and DOTS clients.
  • the DOTS server does not automatically initiate the mitigation procedure but initiates a procedure making it possible to confirm that an attack DDoS is indeed in progress.
  • a communication problem is detected following the non reception by the server, for a predetermined period Th, of presence messages originating from the first DOTS client, for example messages of the “heartbeat” type.
  • the state 521 associated with this faulty DOTS client in the state tables of the server, can be "ATTAQUE_A_VALIDER” (in English “ATTACK_TO_BE_VALIDATED”).
  • the server obtains, during a step 53, a list of at least one IP resource associated with the faulty DOTS client, or more generally with the client domain.
  • IP resources can be IP addresses, IP prefixes or domain names. Domain names can be resolved to IP addresses.
  • IP prefixes denote the IP prefixes directly communicated by a DOTS client or the addresses retrieved via a name resolution system (eg DNS).
  • DNS name resolution system
  • the prefixes can be from the same address family or belong to different families (IPv4, IPv6).
  • the “ATTAQUE_A_VALIDER” state thus indicates that the IP resources associated with the failing DOTS client, or more generally with the client domain, may be subject to a DDoS attack.
  • the server also obtains, during a step 54, a list of at least a second DOTS client belonging to the same domain as the faulty DOTS client, and checks whether this or these second DOTS client (s) are active. , ie, if a DOTS session is active between the server and at least one of these second DOTS clients.
  • the server can also identify IP resources associated with active DOTS clients.
  • the server DOTS can initiate mitigation 55 operations for all IP resources associated with this domain.
  • the state of the faulty client as maintained by the server can then be changed to "MITIGATION_EN_COURS" (in English “MITIGATION_IN_PROGRESS").
  • the server may decide that an attack is in progress if most of the sessions with DOTS clients in the client domain are inactive.
  • a trigger threshold is used for this purpose by the server.
  • this threshold can be 50% or 75% of DOTS sessions established with clients in this domain.
  • the server can decide to trigger the mitigation procedure.
  • other values can be used by the server.
  • the server can send, during a step 56, an unsolicited message for an attack confirmation request (MACR OR "ATTACK_CONFIRMATION_REQUEST ( Resources) ”) to at least one active DOTS client in the domain.
  • an unsolicited message for an attack confirmation request (MACR OR "ATTACK_CONFIRMATION_REQUEST ( Resources) ”) to at least one active DOTS client in the domain.
  • Such a message comprises at least one IP resource associated with the faulty DOTS client, or with the client domain to which the faulty DOTS client belongs.
  • the special value "ANY" can be used to indicate that it is any IP resource associated with the client area.
  • the active DOTS client When an active DOTS client in the client domain receives such an attack confirmation request from the server, the active DOTS client implements a first verification phase during which it can carry out security verifications to ensure server identity and it can validate that the IP resources associated with the attack confirmation request message are effectively associated with the client domain.
  • the request can be ignored by the active client if security checks fail, and the active client may not send a response to the server making the request.
  • the status of the faulty client can be changed to "TEMPS_DE_VALIDATION_ECOULE" (in English “VALIDATION_TIMEOUT”) in the or the state tables maintained by the server.
  • the DOTS server can then launch the mitigation operations 55 for all the IP resources associated with this client domain, and the state of the failing client as maintained by the server can be changed to "MITIGATION_EN_COURS" (in English “MITIGATION_IN_PROGRESS” ).
  • the active client can send an error message (MERR OR "ERROR (Unknown_Resources)" to server to inform him.
  • MRR OR Error (Unknown_Resources)
  • Such a message notably lists the IP resources present in the attack confirmation request message which are not associated with the client domain.
  • the latter When the error message is received by the server, the latter extracts the IP resources indicated in the error message and proceeds to delete the active states associated with these resources.
  • the session between the client C1 111 and the server S 12 is inactive.
  • the session between the client C2 112 and the server S 12 is active.
  • the server can therefore send an attack confirmation request message to the C2 112 client, comprising the IP addresses 1.2.3.4 and 11.2.3.4.
  • the client C2 112 verifies that these addresses belong to the client domain 11, and sends (341 c 2 ) an error message to the server 12 to inform it that the IP address 11.2.3.4 is not associated with the client domain .
  • Server 12 can then delete the filtering rules associated with the IP address 11.2.3.4, or more generally the filtering rules associated with resources not belonging to the client domain. This procedure eliminates obsolete entries ("stale").
  • the active client 112 can proceed to a second verification phase to confirm / invalidate if an attack targets the resource (s) indicated in the confirmation request message d 'attack.
  • the active client 112 can indicate (58) to the server whether or not an attack is in progress on one or more IP resources. For example, the active client 112 sends the server a response message (ATTACK_CONFIRMATION_REPLY (Resources, Status)) with two parameters:
  • the "Resources” parameter which indicates the IP resource or resources concerned
  • the "Status” parameter which is set for example to “1” if an attack is in progress or to "0" otherwise.
  • the state of the failed client as maintained by the server can be changed to
  • the server determines for example that an attack is in progress if at least one of these clients sends a response message carrying the parameter "Status" set to "1" .
  • the state of the failed client as maintained by the server can be changed to
  • DOTS server receives a message from the faulty client, the verification procedure (according to the first or second phase) is interrupted. The status of this client can then be changed to "ON STANDBY" ("IDLE").
  • the clients in the domain are configured beforehand with the list of other clients in the domain, as well as the list of IP resources associated with each client.
  • the active DOTS client 112 directly contacts the DOTS client responsible for managing the resources indicated by the server, for example the faulty client 111 if the attack confirmation request message comprises at least an IP resource associated with the failing DOTS client, or a DOTS entity responsible for managing the client domain if the attack confirmation request message has the special value "ANY" (used to indicate that it is n ' any IP resource associated with the client domain).
  • the active client 112 sends (351V 2 ) at least one first attack verification message (MVATTI OR “DOTS_PEER_PROBE (Request_Code)”) to at least one client node of the client domain associated with the IP resources identified in the message of request for confirmation of attack, for example the defaulting customer 111.
  • MVATTI OR “DOTS_PEER_PROBE (Request_Code) at least one first attack verification message
  • This first attack verification message is for example transmitted from the active client 112 to the failed client 111 to ask him to confirm / deny the attack.
  • the "Request_Code" field of the first verification message can be used to indicate the nature of the request, for example:
  • the first verification message may include a list of resources for which it is necessary to verify whether an attack is in progress.
  • the faulty client 111 can possibly reply (353ci) to this first attack verification message with a first status message (MSJATI OR "DOTS_PEER_PROBE (Reply_Code)") indicating whether an attack is in progress or not.
  • a first status message MSJATI OR "DOTS_PEER_PROBE (Reply_Code)
  • the "Reply_Code" field of the first status message can be used to indicate the nature of the reply, for example:
  • the active client 112 can then send the server a first response message (MREPI OR "ATTACK_CONFIRMATION_REPLY (Resources, Status)”) indicating the status (the "Status” parameter is set to "1” if an attack is in progress or to " 0 ”otherwise) and the IP resource (s) concerned by the attack in progress.
  • MREPI MREPI OR "ATTACK_CONFIRMATION_REPLY (Resources, Status)
  • the active DOTS client 112 contacts a DDoS attack detection function used within the client domain.
  • a DDoS attack detection function used within the client domain.
  • Such a function is for example implemented in at least one node N of the client domain 11, also called a DDoS detector.
  • the active client 112 sends (361c2) at least one second attack verification message (MVAT ⁇ 2 OR “RESOURCE_PROBE (Rk)”) to the DDoS detector 115 to ask to confirm / deny an attack targeting at least one resource.
  • the "Rk" field of the second attack verification message can be used to specify the list of resources concerned:
  • the DDoS attack detection function or the node N 115 activating this function, can possibly respond (363N) to this second attack verification message with a second status message (MSJAT2 OR "RESOURCE_PROBE (Code)" indicating whether or not an attack is in progress.
  • a second status message MSJAT2 OR "RESOURCE_PROBE (Code)"
  • the "Code” field of the second status message can be used to indicate the nature of the response, for example:
  • the active client 112 can then respond to the server with a second response message (MREP 2 OR "ATTACK_CONFIRMATION_REPLY (Resources, Status)”) indicating the status (the "Status” parameter is set to "1" if an attack is in progress or otherwise "0") and the or the IP resources concerned.
  • MREP 2 OR "ATTACK_CONFIRMATION_REPLY (Resources, Status)"
  • the status the "Status” parameter is set to "1" if an attack is in progress or otherwise "0" and the or the IP resources concerned.
  • the active DOTS client 112 can contact a DDoS attack detection function used within the client domain and / or one or more DOTS clients, active or not. , and not necessarily responsible for managing the resources indicated by the server in the attack confirmation request message.
  • the messages exchanged between the active DOTS client 112 and one or more DOTS clients are similar to those described in connection with the first variant and are not described in more detail.
  • the messages exchanged between the active DOTS client 112 and the DDoS attack detection function are similar to those described in connection with the second variant and are not described in more detail.
  • the active client 112 can distribute the attack verification requests between the clients and the DDoS detector according to considerations of activity from neighboring clients, for example.
  • the active client 112 can then send the server a response message indicating the status (the "Status” parameter is set to "1" if an attack is in progress or to "0" otherwise) and the IP resource or resources concerned. According to this third variant, the active client 112 decides that an attack is in progress if it receives at least one response confirming the attack, and informs the server accordingly.
  • the active client 112 can send several response messages to the server.
  • the server decides that an attack is in progress if it receives at least one response confirming the attack.
  • FIG. 7D illustrates three examples of messages exchanged between the active DOTS client 112, the DDoS detector 115, and the client Cm 114.
  • the active DOTS client 112 concludes that an attack is in progress.
  • the active DOTS client 112 concludes that an attack is in progress.
  • the active DOTS client 112 concludes that no attack targets the resource indicated in the request.
  • a second example of application of the invention is presented below in more detail, according to which the traffic management action implements a redirection on the active node of at least part of the traffic associated with the domain.
  • Figure 8 illustrates the main steps implemented to redirect part of the traffic to an active client.
  • the steps of monitoring 51 of DOTS clients belonging to a client domain, of detecting a communication problem with a first DOTS client 52, of obtaining at least one IP resource associated with this faulty client 53, of obtaining 'at least a second client belonging to this client 54 and mitigation domain 55 are similar to those presented in relation to FIG. 5 and are not described in more detail.
  • DOTS clients belonging to the same domain have been identified by the server, the latter verifies that DOTS sessions are active with at least one of these clients.
  • the DOTS server launches the mitigation operations 55 for all the resources associated with this area.
  • the server can, following the detection of a communication problem with a DOTS client (loss of signal for example) redirect (86) part of the traffic, initially routed by the path involving the failing DOTS client, to secondary paths involving one or more DOTS clients in the same domain whose DOTS session is active.
  • a communication problem with a DOTS client loss of signal for example
  • the selection of the traffic to be redirected can be based on one or more selection criteria, belonging to the group comprising:
  • one or more of the DOTS clients called upon during traffic redirection may or may send a signal to the server asking it to launch mitigation operations.
  • the redirection can be programmed for a predetermined duration REDIRECT_Tmax.
  • the DOTS server monitors (87) the inactive session with the failing DOTS client for a predetermined duration REDIRECT_Tmax.
  • the DOTS server can launch mitigation operations 55 for all associated resources to this client area.
  • the server does not receive any request for mitigation (872), and if at least one session with another DOTS client is still active, this means a priori that the problem of communication with the Failed client is not due to a DDoS attack, and the status associated with the failed DOTS client can be set to "EN_VEILLE" ("IDLE”) in the state table or tables maintained by the server.
  • the server can also decide to redirect another portion of the traffic and to repeat the same procedure for another REDIRECT_Tmax duration.
  • a communication problem is detected between the server 12 and the client Cl 111.
  • Part of the incoming traffic 91 is redirected, by means of a router R 92 for example, to the client C2 112 active during a REDIRECT_Tmax duration equal to T1.
  • a router R 92 for example, to the client C2 112 active during a REDIRECT_Tmax duration equal to T1.
  • another part of the incoming traffic 91 can be redirected to the active client Cm 114 for a REDIRECT_Tmax duration equal to T2.
  • a communication problem is detected between the server 12 and the client C1111.
  • Part of the incoming traffic is redirected (100) to another active client.
  • the server triggers the REDIRECT_Tmax timer.
  • the C2 112 client can intercept the redirected traffic (101), in particular if the redirected traffic passes through the C2 112 client, and detect a DDoS attack in the incoming traffic before the expiration of the predetermined duration REDIRECT_Tmax.
  • the server can then trigger DDoS mitigation operations (102) and inform the active C2 112 customer (2.01 (Created)).
  • a communication problem is detected between the server 12 and the client C1 111.
  • Part of the incoming traffic is redirected (100) to another active client.
  • the server triggers the REDIRECT_Tmax timer.
  • the client C2 112 can intercept the redirected traffic (101), in particular if the redirected traffic passes through the client C2 112. If no request for mitigation is received by the server from the client C2 112, and the session DOTS is still active with this C2 112 client, the server concludes that no attack is in progress. The server can then decide to stop traffic redirection (103).
  • DOTS clients are therefore not necessarily located on the path taken by incoming and / or outgoing traffic.
  • DDoS detectors DI 104, D2 105, ..., Dm 106
  • the detection of attacks can then be implemented by one of these detectors, which can communicate the information to the associated DOTS client.
  • the server S 12 can in particular communicate with the DDoS detectors via the DOTS signaling and data channels defined in relation to the prior art.
  • the traffic management method associated with a client domain comprises the verification of a parameter common to the client nodes, making it possible in particular to ensure the consistency of the configuration of the different clients of a same area as for the activation of automatic mitigation on loss of the DOTS signal.
  • a server can activate the procedure described above only if all the clients of the same domain have negotiated the same value for the triggering parameter of mitigation "trigger-mitigation" during the negotiation configuration of DOTS sessions. The server must therefore check the value of this mitigation trigger parameter.
  • the client Cl 111 indicated the value “FALSE” for the triggering mitigation parameter in its configuration negotiation request. (“Trigger-mitigation: false”). It is assumed that the C2 112 client indicated the value “TRUE” for the mitigation trigger parameter in its configuration negotiation request (“trigger-mitigation: true”).
  • the DOTS server detects a conflict between these two requests, and can deactivate automatic mitigation on loss of signal for all clients in this domain.
  • FIG. 13 illustrates the case where the second client C2 has established a DOTS session (131) with the server 12 during which he has indicated that the mitigation trigger parameter is set to "TRUE" ("trigger-mitigation: true "). If the first client C1 subsequently seeks to establish a DOTS session (132) with the server 12 by indicating that the mitigation trigger parameter is set to FALSE ("trigger-mitigation: false"), the new request is in conflict with the one already maintained by the server.
  • the DOTS server can reject the request of the first Cl client, for example with a message 4.09 of type “conflict” 133 (in English “Conflict”).
  • the error message can indicate the nature of the conflict (“conflict-trigger-mitigation”).
  • Client C1 can then send a new negotiation request with the mitigation trigger parameter set to "TRUE" ("trigger-mitigation: true").
  • FIG. 14 illustrates the case where the first client C1 has established a DOTS session (141) with the server 12 during which he has indicated that the mitigation trigger parameter is set to FALSE ("trigger-mitigation: false") . If the second client C2 subsequently seeks to establish a DOTS session (142) with the server 12 by indicating that the mitigation trigger parameter is set to "TRUE" (“trigger-mitigation: true”), the new request is in conflict with that already maintained by the server.
  • the DOTS server can end the TLS or DTLS session with the client Cl having negotiated the "trigger-mitigation: false" parameter. To do this, the DOTS server sends, for example, a “fatal alert” type message 143 (“Fatal Alert”) to the client C1, as described for example in the aforementioned document RFC5246.
  • a “fatal alert” type message 143 (“Fatal Alert”)
  • the client C1 can then reset the session 144 with the server and negotiate 145 a new value of the mitigation trigger parameter set to "TRUE"("trigger-mitigation:true”).
  • a server comprises a memory $ 151 comprising a buffer memory, a processing unit $ 152, equipped for example with a programmable calculation machine or with a dedicated calculation machine, for example a processor P , and controlled by the computer program $ 153, implementing steps of the traffic management method associated with a client domain according to an embodiment of the invention.
  • the code instructions of the computer program 153 $ are for example loaded into a RAM memory before being executed by the processor of the processing unit 152s.
  • the processor of the processing unit 152 $ implements steps of the traffic management method associated with a client domain described above, according to the instructions of the computer program 153 $ , for:
  • o if at least one session is active use the second node associated with said at least one active session, known as the active node, to initiate an action for managing the traffic associated with the client domain.
  • a client node comprises a memory 151c comprising a buffer memory, a processing unit 152 Q equipped for example with a programmable calculation machine or with a dedicated calculation machine, for example a processor P, and controlled by the computer program 153 Q implementing steps of the traffic management method associated with a client domain according to an embodiment of the invention.
  • the code instructions of the computer program 153c are for example loaded into a RAM memory before being executed by the processor of the processing unit 152 Q.
  • the processor 152c of the processing unit implements the steps of the associated traffic management method for a customer area described above according to the instructions of to 153o F or receive computer program at least one attack confirmation request message on at least one IP resource associated with the customer area from the server.

Landscapes

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

Abstract

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

Description

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

Claims

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

Priority Applications (2)

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

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO2020002853A1 true WO2020002853A1 (fr) 2020-01-02

Family

ID=63834171

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2019/051605 WO2020002853A1 (fr) 2018-06-29 2019-06-28 Procédés de gestion du trafic associé à un domaine client, serveur, nœud client et programme d'ordinateur correspondants

Country Status (4)

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

Families Citing this family (1)

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

Citations (2)

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

Family Cites Families (7)

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

Patent Citations (2)

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

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
DIERKS T. ET AL.: "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008 (2008-08-01)
MORTENSEN ARBOR NETWORKS F ANDREASEN CISCO T REDDY MCAFEE A ET AL: "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture; draft-ietf-dots-architecture-05.txt", DISTRIBUTED-DENIAL-OF-SERVICE OPEN THREAT SIGNALING (DOTS) ARCHITECTURE; DRAFT-IETF-DOTS-ARCHITECTURE-05.TXT; INTERNET-DRAFT: DOTS, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENE, no. 5, 26 October 2017 (2017-10-26), pages 1 - 30, XP015122508 *
REDDY, T ET AL.: "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Spécification", DRAFT-IETF-DOTS-SIGNAL-CHANNEL, January 2018 (2018-01-01)
REDDY, T. ET AL.: "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel", DRAFT-IETF-DOTS-DATA-CHANNEL, December 2017 (2017-12-01)
RESCORLA E. ET AL.: "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012 (2012-01-01)
RESCORLA E. ET AL.: "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", DRAFT-IETF-TLS-DTLSL3-22, November 2017 (2017-11-01)
RESCORLA E.: "The Transport Layer Security (TLS) Protocol Version 1.3", DRAFT-IETF-TLS-TLSL3-23, January 2018 (2018-01-01)

Also Published As

Publication number Publication date
FR3081574A1 (fr) 2019-11-29
EP3815336A1 (fr) 2021-05-05
US11563816B2 (en) 2023-01-24
US20210160330A1 (en) 2021-05-27

Similar Documents

Publication Publication Date Title
US20100037309A1 (en) Method and apparatus for providing security in an intranet network
US11546374B2 (en) Selective traffic processing in a distributed cloud computing network
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
EP3533202B1 (fr) Controle dynamique et interactif d&#39;une passerelle residentielle connectee a un reseau de communication
WO2020002853A1 (fr) Procédés de gestion du trafic associé à un domaine client, serveur, nœud client et programme d&#39;ordinateur correspondants
WO2020183100A1 (fr) Mitigation d&#39;attaques informatiques
EP4066461B1 (fr) Procédé de coordination de la mitigation d&#39;une attaque informatique, dispositif et système associés
EP3087719B1 (fr) Procédé de ralentissement d&#39;une communication dans un réseau
CN112514350B (zh) 用于核实ip资源的有效性的方法以及相关联的访问控制服务器、验证服务器、客户端节点、中继节点和计算机程序
EP3857849A1 (fr) Procédés de protection d&#39;un domaine client, noeud client, serveur et programmes d&#39;ordinateur correspondants
WO2019211548A1 (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
EP3857847A1 (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
WO2021105617A1 (fr) Procede d&#39;assistance pour la gestion d&#39;une attaque informatique, dispositif et systeme associes
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
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
WO2008031967A2 (fr) Procédé de supervision d&#39;une session d&#39;accès a un service établie par un terminal client au moyen d&#39;un protocole de configuration dynamique
FR3136922A1 (fr) Procédé de communication entre un premier équipement et un serveur distant, procédé de gestion des communications, premier équipement, serveur distant et programme d’ordinateur correspondants.
EP4256753A1 (fr) Procédé de détection d&#39;un équipement malveillant dans un réseau de communication, équipement de communication et programme d&#39;ordinateur correspondants
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.

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: 19752541

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2019752541

Country of ref document: EP