EP3857847A1 - Procédé de collaboration et de demande de collaboration entre services de protection associés à au moins un domaine, agents et programme d'ordinateur correspondants - Google Patents

Procédé de collaboration et de demande de collaboration entre services de protection associés à au moins un domaine, agents et programme d'ordinateur correspondants

Info

Publication number
EP3857847A1
EP3857847A1 EP19801930.9A EP19801930A EP3857847A1 EP 3857847 A1 EP3857847 A1 EP 3857847A1 EP 19801930 A EP19801930 A EP 19801930A EP 3857847 A1 EP3857847 A1 EP 3857847A1
Authority
EP
European Patent Office
Prior art keywords
agent
attack
protection service
service
protection
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP19801930.9A
Other languages
German (de)
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP3857847A1 publication Critical patent/EP3857847A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • 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/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • 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/1433—Vulnerability analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/141—Denial of service attacks against endpoints in a network

Definitions

  • TITLE Methods of collaboration and request for collaboration between protection services associated with at least one domain, agents and corresponding computer program.
  • 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 offers a solution allowing different protection services, protecting one or more domains, to collaborate.
  • protection services are for example of DPS type (in English “DDoS Protection Services”, for “Distributed Douai of Service Protection Services”, or attack protection services by denial of distributed services), for example implementing, but not exclusively, an architecture of the DOTS type, in English “DDoS Open Threat Signaling”).
  • the protection service and the infrastructure deployed to provide such a service are interchangeably called “protection service” below.
  • the invention provides a solution for coordinating mitigation actions when a denial of service attack is identified.
  • the invention notably finds applications in any field using computer networks which may be subjected to a virus, SPAM, SPIT (in English "SPAM over IP Telephony", or SPAM over telephone communication over IP), DDoS, etc. attack.
  • 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 the attacks.
  • DPS DDoS Protection Service
  • tunnels to force traffic (incoming or outgoing, in English "inbound” or "outbound") on a site or a network intended to be inspected by the DPS service.
  • this approach considerably increases the latency observed by users and imposes constraints on the dimensioning of the DPS service in order to be able to handle all the incoming or outgoing traffic of all network users, without degrading performance or the level of quality of service provided to the client.
  • tunnels are considered to be potential attack vectors.
  • DOTS a specific architecture
  • a client node said DOTS client
  • DOTS server a server
  • DOTS server a server
  • appropriate actions are required.
  • a DOTS client in 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.
  • the mitigation entity can be co-located with the DOTS server.
  • the DOTS architecture is based on the use of two communication channels between the DOTS client and the DOTS server: a DOTS signaling channel (in English "DOTS Signal Channel”), and a DOTS data channel (in English "DOTS Data Channel”).
  • a DOTS signaling channel in English "DOTS Signal 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 help 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 deal with the attack.
  • 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", or all UDP traffic destined for port number 443.
  • 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, Boucadair, M. et al., December 2017.
  • DSS Distributed Denial-of- Service Open Threat Signaling
  • the DOTS architecture only covers the relationship between a DOTS client and its DOTS server, to request assistance when the DOTS client detects an attack.
  • DOTS clients / servers belonging to other DPS infrastructures are not aware of the attack.
  • the invention is based on a new method of collaboration between protection services associated with one or more domains, implemented by a first agent used by a first protection service, comprising:
  • an agent used by a protection service belongs to a domain / infrastructure offering this protection service.
  • the protection service associated with this client domain can propagate information relating to this attack to protection services associated with this client domain or with other client domains, so that these other protection services can anticipate said attack or a similar attack and thus protect these client domains.
  • Coordination also makes it possible to set up a distributed mitigation plan involving several DPS or access networks, thereby limiting the spread of certain attacks.
  • the transmission step can be restricted to certain types of attacks, neighboring agents, etc. Policies are typically provided to the agent who implements said collaboration process.
  • such an attack can be of the type:
  • DDoS denial of service attack
  • an attack is a denial of service attack, identified by a protection service protecting a first domain
  • the invention is not limited to the propagation of information towards protection services deployed within neighboring domains and / or located on the routing path of the traffic of an attack.
  • the invention makes it possible to create interconnections between remote protection services which wish to establish a collaboration between them to maintain or implement a more effective security policy to deal with attacks liable to affect the underlying domains that 'they protect, for example by sharing the mitigation plans they implement.
  • These interconnections are established thanks to the implementation, in accordance with the invention, of a prior subscription mechanism with the protection services proposing the sharing of information on all or part of the attacks that they identify.
  • various security checks can be carried out to determine whether it is appropriate to share such information with the protection service at the origin of the subscription request.
  • the invention makes it possible, by means of this sharing, to anticipate attacks effectively, without requiring the protection services collaborating with one another to have visibility on or to control the same traffic and, in particular the traffic of the attack.
  • the invention allows a collaboration of protection services between them whatever the nature and the scope of an attack, and in particular the resources involved (at the origin of the attack or attacked).
  • the invention is based on a characterization of an attack, in the information provided to the protection services having subscribed to the information sharing service, without explicitly associating it with the targets of said visible attack. of a protection service (for example without disclosing the addresses of the targets of the attack as seen by the protection service which identified the attack).
  • This characteristic is important for preserving the confidentiality of communications and the nature of these communications (for example with which application (s) they are associated with) within a domain protected by a protection service.
  • the proposed solution makes it possible to facilitate the coordination of mitigation actions in particular, by sharing information relating to attacks. Also, it makes it possible to reduce the time required for the implementation of mitigation plans thanks to the sharing and dissemination of mitigation actions between DPS domains.
  • the proposed solution also makes it possible to propagate a priori reliable information, since this information is obtained by the protection service having identified an attack.
  • the proposed solution also makes it possible to quickly propagate information, which allows protection services receiving information about attacks to anticipate these attacks and to react optimally in order to limit the abuse of network resources.
  • the transmission to at least one second agent used by a second protection service, of at least information relating to the attack identified by the first agent, implements the emission of at least one notification message intended for the second agent (s) or an intermediary agent in charge of message redirection.
  • said at least one notification message comprises at least one item of information belonging to the group comprising:
  • This different information can be transmitted in separate notification messages, or aggregated in the same notification message.
  • a new notification message can be sent if the attack is modified. For example, if new sources are involved in the attack, a new notification message is sent to the second agent (s), possibly through an intermediary agent in charge of redirecting messages.
  • the method of collaboration between protection services comprises a prior subscription step, implementing:
  • the establishment of a session between the first agent and said at least one second agent the reception, by the first agent, of at least one message for subscribing to at least one information sharing service offered by the first service protection,
  • said at least one subscription message comprises at least one item of information belonging to the group comprising:
  • information relating to a type of information sharing service requested for example all the information sharing services of the first protection service, the information sharing service relating to DDoS attacks of the first protection service, the first protection service virus detection information sharing service, first protection service's information sharing service for SPIT attacks, etc.;
  • an alert level associated with said at least one second agent for example only alerts relating to critical attacks are sent, or only alerts which correspond to the filters indicated by an agent used by a protection service are sent;
  • redirection information to another agent used by the second protection service (specifying, for example, if the notification messages must be sent to another agent used by the same protection service);
  • This different information can be transmitted in separate subscription messages, or aggregated in the same subscription message.
  • such a method comprises the automatic deletion, at the expiration of a period of validity associated with the subscription message, of the information conveyed in a subscription message previously stored.
  • the invention is also based on a new method for requesting collaboration between protection services associated with one or more domains, implemented by at least one second agent used by a second protection service having subscribed to a first protection service. to at least one information sharing service offered by the first protection service, according to which a first agent used by the first protection service having identified an attack on at least one resource managed by a domain protected by the first protection service protection, the process includes:
  • reception implements the reception of at least one notification message, as described above, transmitted by said first agent or by an intermediate agent in charge of message redirection.
  • the reception also implements the reception of at least one notification message transmitted by an agent used by a protection service distinct from the first protection service.
  • said at least one action comprises the transmission, to an entity in charge of the mitigation of the second protection service, of the information or information relating to the attack.
  • said at least one action comprises an update of the filters managed by the second protection service.
  • said at least one action comprises the transmission to the first agent, or to an intermediate agent in charge of message redirection, of an action sharing message with the first protection service.
  • the second agent can request to share a mitigation plan with the first agent (that is, to be informed of this mitigation plan).
  • the method of requesting collaboration between protection services comprises a prior subscription step implementing:
  • the establishment of a session between the first agent and said at least one second agent the transmission, by said at least one second agent, of a subscription message (as described above) to at least one sharing service of information offered by the first protection service.
  • said at least one second agent retransmits the subscription message before the expiration of a period of validity associated with said subscription message.
  • the method implemented by the first and / or the second agent further comprises:
  • protection services can collaborate with access providers to filter, or even block, upstream the traffic emitted by machines involved in an attack, thus limiting the spread of the attack as close to its source.
  • the embodiment proposed above makes it possible in particular to distribute the filtering actions between several access providers, which makes it possible to facilitate the installation of filters on a large scale.
  • Another embodiment relates to an agent used by a protection service, configured to identify an attack and transmit at least information relating to the identified attack to an agent used by another protection service having subscribed to this protection service. to at least one information sharing service offered by this protection service, and / or configured to receive at least information relating to an attack identified by an agent used by another protection service with which he has subscribed to a service information sharing and determine at least one action to perform accordingly.
  • such an agent is a node of the infrastructure used for the implementation of the protection service, embedding specific functionalities allowing it to identify an attack / transmit at least information relating to the attack and / or receive at least information relating to an attack / determining at least one action.
  • the invention relates to one or more computer programs comprising instructions for implementing a method of collaboration between protection services, or of request for collaboration between protection services, according to at least an 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 method of collaboration between protection services, or of request for collaboration between protection services, 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.
  • Figure 1 illustrates an example of a communication network implementing a method of collaboration, or request for collaboration, between protection services, according to an embodiment of the invention
  • FIG 2 shows the main steps of a collaboration process, or collaboration request, between protection services, according to at least one embodiment of the invention
  • FIG. 3C Figures 3A to 3C illustrate different modes of communication between agents used by separate protection services
  • FIGs 4 and 5 show the main steps implemented by a local agent and by a remote agent during a subscription phase
  • FIGs 6 and 7 illustrate the transmission and use of a notification message according to an embodiment of the invention
  • FIGs 8 and 9 show the main steps implemented by a local agent and by a remote agent during a notification phase
  • FIG 11 Figures 10 and 11 illustrate a particular embodiment allowing an access provider to filter the traffic characteristic of an attack
  • Figure 12 shows the simplified structure of an agent according to a particular embodiment.
  • the general principle of the invention is based on collaboration between at least two protection services associated with one or more network domains.
  • the invention makes it possible in particular to inform a remote protection service associated with a remote domain, when an attack on a resource managed by a local domain is detected by the local protection service.
  • first domain 111 associated with a first protection service 112, noted for example DPS # 1
  • second domain 121 associated with a second protection service 122, noted for example DPS # 2.
  • a domain includes one or more machines, also called nodes.
  • domain or “network” means a set of machines or nodes placed under the responsibility of the same entity.
  • the first and second protection services 112 and 122 respectively protect the network resources of the first and second domains 111 and 121.
  • the first and second domains 111 and 121 can be connected to the Internet 13.
  • Attack sources SI 141, S2 142, ..., Sk 14k can also be connected to the Internet 13 via access providers AP # 1 151, AP # 2 152, AP # n 15n (in English "Access Providers ”).
  • FIG. 2 illustrates the main steps implemented for collaboration between protection services in a communication network such as that illustrated in FIG. 1.
  • a first agent 113 used by the first protection service 112 protecting the first domain 111 identifies (221) an attack on at least one resource managed by the first domain 111.
  • an attack can be detected by a node of the first domain 111 (for example a DOTS client) or by a node of the infrastructure used for the implementation of the first protection service 121 (first agent 113 embedding specific functionalities according to the invention or other node).
  • the first agent 113 used by the first protection service can therefore either detect the attack itself or receive this information from from another node.
  • the first agent 113 can then decide to transmit (222) to at least one other agent, for example to a second agent 123 used by the second protection service 122, protecting the second domain 112, at least information relating to the attack identified by the first agent 113. Such information can possibly be transmitted to an intermediate agent, who is responsible for retransmitting it to the second agent 123 in particular.
  • the second agent 123 used by the second protection service 122 receives (223) the information or information relating to the attack identified by the first agent 113 used by the first protection service 112.
  • the second agent 123 can determine (224) at least one action to be performed.
  • a mitigation phase 23 of the attacks can be implemented.
  • a subscription phase 21 Prior to the detection phase 22, a subscription phase 21 can be implemented.
  • Such a subscription phase 21 implements, for example, the establishment 211 of a session between the first agent 113 used by the first protection service 112, and at least one agent used by another protection service, for example the second agent 123 used by the second protection service 122.
  • the second agent 123 transmits (212) at least one subscription message to the first agent 113.
  • a message may possibly be transmitted to an intermediary agent, who is responsible for retransmitting it to the first agent 113 in particular.
  • the first agent 113 receives (213) the subscription message (s), and stores (214), for example in a remote subscription database 24, the information conveyed by the subscription message (s).
  • the detection phase 22 can then be implemented.
  • the proposed solution therefore makes it possible to coordinate protection services, possibly on an Internet scale, from the attack detection phase to the mitigation of the attack (whatever the origin of the attack, whatever the vector (for example a connected object, a tunnel, etc.) and whoever the victims are (network, terminal service, etc.) ).
  • the proposed solution makes it possible to guarantee global and rapid consistency of the information relating to the attack (origin, nature, content, target, vector, etc.) and of the actions taken to resolve it.
  • protection services are associated with the same domain, i.e., protect the same domain.
  • An example of an application is a “multi-homing” corporate network.
  • the first and second domains 111 and 121 are one and the same domain.
  • the proposed solution is based on the allocation of specific functionalities to one or more nodes of the infrastructure used for the implementation of a protection service, denoted “agent”, or, according to a particular embodiment implementing DPS type protection services, "DIA agent” (for “DPS IDAD Agent”, where IDAD stands for "Inter-DPS Attack Dissemination and mitigation action sharing and assistance”, ie, assistance and sharing of mitigation and mitigation actions d 'attack between DPS).
  • DIA agent for “DPS IDAD Agent”, where IDAD stands for "Inter-DPS Attack Dissemination and mitigation action sharing and assistance", ie, assistance and sharing of mitigation and mitigation actions d 'attack between DPS.
  • One or more agents can be activated by a protection service.
  • a protection service agent can interface with one or more agents from other protection services.
  • DTLS or TLS exchanges and exchanges concerning the management of security keys are conventional and are not described in more detail.
  • the agents used by the protection services authenticate each other.
  • messages received from a machine usurping the identity of a legitimate agent are rejected by another agent.
  • requests from an agent used by a first protection service, who is not authorized to access information sharing services offered by a second protection service are ignored by an agent used by a second protection service. protection.
  • this mutual authentication procedure is implemented by protection service agents.
  • the agents used by different protection services can communicate directly with each other, or via an intermediary agent in charge of message redirection.
  • This intermediate agent is for example used by a federation dispatcher, or FD (in English "Federation Dispatcher").
  • FIGS. 3A to 3C illustrate different examples of communication between the agents used by different protection services.
  • FIG. 3A illustrates an example of communication in “point-to-point” mode, according to which the agents exchange messages directly between different protection services.
  • a first agent 321 of a second DPS protection service 32 exchanges messages directly with a first agent 311 of a first DPS protection service 31, a first agent 341 of a fourth DPS protection service 34 and a first agent 351 of a fifth DPS protection service 35.
  • a second agent 322 of the second DPS protection service 32 exchanges messages directly with a first agent 331 of a third DPS protection service 33.
  • the first 321 and second 322 agents of the second protection service DPS 32 can communicate with each other since they are used by the same protection service.
  • the second DPS protection service 32 can send the same message four times to the other DPS protection services 31, 33, 34 and 35.
  • FIGS. 3B and 3C illustrate examples of communication in “federation” mode. This mode supposes that the protection services are organized in federations. Agents send messages to a federation dispatcher, who is responsible for relaying messages from an agent of a federation protection service to an agent of another federation protection service or to a dispatcher of another federation.
  • the DPS protection services 31 to 35 are part of the same federation, and can therefore exchange messages via the dispatcher 36.
  • the first agent 321 of the second protection service DPS 32 exchanges messages with dispatcher 36.
  • a first agent 361 of dispatcher 36 redirects messages from the first agent 321 of the second DPS protection service 32 to the first agent 311 of the first DPS protection service 31 and the first agent 351 of the fifth DPS protection service 35.
  • a second agent 362 of dispatcher 36 redirects messages from the first agent 321 of the second DPS protection service 32 to the first agent 331 of the third DPS protection service 3 and the first agent 341 of the fourth DPS protection service 34.
  • the first 361 and second 362 dispatchers 36 can communicate with each other.
  • the first and fifth DPS protection services 31 and 35 are part of a first federation, using a first distributor 37
  • the second, third and fourth DPS protection services 32, 33, 34 are part of a second federation, using a second dispatcher 72.
  • the first agent 321 of the second DPS protection service 32 exchanges messages with the dispatcher 36.
  • a first agent 361 of the second dispatcher 36 redirects the messages of the first agent 321 from the second DPS protection service 32 to a first agent 371 from the first dispatcher 37.
  • the first agent 371 from the first dispatcher 37 redirects messages from the first agent 321 from the second DPS protection service 32 to the first agent 311 from the first protection service DPS 31 and the first agent 351 of the fifth protection service DPS 35.
  • a second agent 362 of the second dispatcher 36 redirects messages from the first agent 321 of the second DPS protection service 32 to the first agent 331 of the third DPS protection service 3 and the first agent 341 of the fourth DPS protection service 34.
  • the first 361 and second 362 agents of the dispatcher 36 can communicate with each other.
  • the second DPS protection service 32 can send the message only once to the dispatcher 36, which is then responsible for retransmitting it to the other four DPS protection services 31, 33, 34 and 35.
  • This mode therefore facilitates the application or the exploitation of a processing carried out by a protection service, for example to resolve an attack in progress within its area of responsibility (for example a network that it protects), while optimizing the volume of exchanges between the protection services of a federation.
  • an agent used by a protection service can subscribe, according to at least one embodiment, to at least one information sharing service offered by a remote protection service.
  • a secure communication session is established between an agent used by a protection service, for example the first agent 113 of the first protection service 112 according to FIG. 1, and an agent wishing to subscribe to at least one service.
  • information sharing offered by the first protection service for example the second agent 123 of the second protection service 122 according to FIG. 1.
  • This communication session can be established between the two agents directly, or between the agents via at least an intermediary agent used by at least one dispatcher within a federation.
  • the second agent 123 wishing to subscribe to at least one information sharing service offered by the first protection service 112, sends at least one subscription message to the first agent 113, directly or via at least one intermediary agent.
  • the subscription message is sent from the second agent 123 to the first agent 113 or to a dispatcher.
  • the subscription message is noted SUBSCRIBE () and includes at least one attribute, or parameter, carrying information of the type:
  • Service_type information relating to a type or nature of the information sharing service requested. For example, if no value is specified, the first agent can interpret the subscription message as a request to subscribe to the DDoS service of the first protection service. For example, the values carried by this parameter can be:
  • iv.3 SPAM service of the first protection service
  • v. 4 SPIT service of the first protection service
  • subscription message can be used to indicate several types of service.
  • dedicated subscription messages can be sent per service.
  • “Verbose_Mode” an alert level associated with the second agent.
  • this parameter indicates the level of granularity of the notifications that the second agent, wishing to subscribe to at least one information sharing service offered by the first protection service, wishes to receive.
  • the values carried by this parameter can be:
  • i. 0 only alerts relating to critical attacks are sent. For example, an attack is said to be critical if the volume of traffic relating to this attack exceeds a certain threshold, or if it involves a certain number of machines, or if it lasts more than X minutes, etc. This value can be used by default.
  • a filter can be defined by one or more attributes such as:
  • + protocol informs a specific protocol such as UDP, TCP, NTP, DNS, etc. ;
  • + port number enter a specific port number such as 80, 23, 443, etc.
  • a range of port numbers can be specified (eg 80-8080);
  • N_DIA redirection information to another agent used by the second protection service.
  • this parameter specifies whether the subscription message (s) should be sent to another agent used by the same protection service (in the case of redirection).
  • at least one IP address for this agent can be provided;
  • this parameter associates a period of validity with this subscription. For example, the absence of this parameter or the use of the value (-1) indicates that the subscription has an infinite duration;
  • Figures 4 and 5 illustrate the main steps implemented by the first and second agents, according to at least one embodiment. More specifically, Figure 4 illustrates the steps implemented by the first agent 113 used by a first protection service 112 and FIG. 5 illustrates the steps implemented by the second agent 123, wishing to subscribe to at least one information sharing service offered by the first service protection 112.
  • the second agent 123 sends one or more subscription messages by positioning the aforementioned attributes (step referenced 51 in FIG. 5, similar to step 212 in FIG. 2).
  • an identifier can be associated with the subscription request.
  • the subscription identifier can be associated with a “request in progress” state (50) in a subscription database, for example base 24 according to FIG. 2.
  • the latter On receipt of a subscription message by the first agent 113 (step referenced 41 in FIG. 4, similar to step 213 in FIG. 2), the latter can carry out security checks (42) to ensure that the second agent 123 is authorized to subscribe to at least one information sharing service offered by the first protection service. It is noted that the policy for subscribing to an information sharing service may have been previously defined (40).
  • the first agent 113 extracts the information included in the subscription message to identify the agent sending the subscription message (ie, the second agent 123), and, for example, identify the protection service for which it is used (ie, the second protection service 122), determining the type of information sharing service requested (ie, the value of the "Service_Type” parameter), determining the nature of the notifications (ie , the value of the "Verbose_Mode” parameter), determine the period of validity of the subscription, etc.
  • This information is then saved in a subscription database, for example the base 24 according to FIG. 2, for example with the subscription identifier.
  • the first agent also checks whether the subscription message relates to a new subscription (45).
  • the subscription message concerns a new subscription, for example coming from an agent used by a separate protection service, a new subscription identifier is created (46) and recorded in the subscription database.
  • the subscription database is updated (47).
  • the first agent 113 can then respond to the agent that issued the subscription message (s).
  • the first agent 113 sends an ACK acceptance message to confirm the subscription.
  • the first agent 113 can alternatively send an error message if, for example, the information sharing service desired by the second agent 123 is not supported by the first protection service 112 or if the first agent 113 is overloaded , etc.
  • the reception (52) of the ACK acceptance message by the agent that issued the subscription message (s) indicates that the subscription has been completed successfully.
  • the second agent 123 can check (53) whether the acceptance message ACK received from the first agent 113 corresponds to the subscription request sent by the second agent 123, by consulting the subscription database 24.
  • the ACK acceptance message is ignored.
  • the subscription has been completed successfully, and the subscription identifier is associated with a "confirmed" state in the subscription database 24.
  • the second agent 123 then remains awaiting (56) information from the first agent 113, in particular in the event that an attack is identified by the first agent 113.
  • the second agent 123 in order to keep the subscription active, sends a new subscription message before the expiration of the subscription validity period defined in the subscription message. If no message is sent before the expiration of this period of validity, the first agent 113 can delete the corresponding subscription from the subscription database 24.
  • the steps presented above can also be implemented by reversing the direction of the messages if the first agent 113 wishes to subscribe to at least one information sharing service offered by the second protection service 122. In this case, it is the first agent 113 which sends at least one subscription message to the second agent 123.
  • the first agent 113 of the first protection service 112 When the first agent 113 of the first protection service 112 identifies an attack which corresponds to the rules indicated by the second agent 123 in the subscription message and which comply with local policies, the first agent 113 sends one or more notification messages to the second agent 123 to alert it of this attack, directly or via at least one intermediary agent used by at least one dispatcher.
  • the first protection service 112 detects an attack on at least one resource of the first network 111 that it protects, coming from the connected sources SI 141, S2 142, ..., Sk 14k to the first network 111 via the Internet 13 via access providers AP # 1 151 and AP #m 15m.
  • the first agent 113 of the first protection service 112 Upon detection of this large-scale DDoS attack, the first agent 113 of the first protection service 112 sends a notification message (“NOTIFY ()”) to the second agent 123 of the second protection service 122, so that the latter is informed of the attack in progress and can initiate actions making it possible to avoid, or reduce, the risk that the resources of the second network 121 which it protects undergo in their turn the same attack as the resources of the first network 111.
  • NOTIFY () a notification message
  • the second agent 123 can take the necessary measures to filter the traffic coming from the sources SI 141, S2 142, ..., Sk 14k.
  • the traffic originating from sources SI 141, S2 142, ..., Sk 14k and destined for the second network 121 is blocked upstream, because the second protection service 122 has already been mobilized for take the appropriate measures following the notification received from the first protection service 112.
  • the notification message is noted NOTIFY () and includes at least one attribute, or parameter, carrying information of the type:
  • SUBSCRIPTIONJD information relating to the subscription, by the second agent 123, to at least one information sharing service offered by the first protection service 112, such as a subscription identifier defined during the subscription;
  • ATTACK_ID attack identifier, for example generated by the first agent 113 sending the notification message.
  • the same identifier is used during the lifetime of an attack
  • ATTACK_DESCRIPTOR technical description information of the attack.
  • this field can include a protocol number, one or more port numbers, the machines involved in the attack (for example, machine type or model), the direction of traffic (inbound or outbound), etc., or a combination of this information.
  • the technical description may indicate one or more machines affected by the attack (for example machine_x, _constru Budapest_y, _release_z);
  • STATUS information relating to the state of the attack.
  • this parameter can take the following values:
  • LOCAL_MITIGATION information indicating whether one or more mitigation actions are implemented locally by the first protection service. Also, this field carries a technical description of the mitigation actions implemented by the protection service of the agent sending the notification message. According to a particular embodiment, this information relating to the mitigation actions is shared informally, and the agent receiving the notification message can ignore it.
  • the mitigation actions can be generic (for example YANG configuration) or specific to a manufacturer (for example configuration file specific to "machine_x, _constru Budapest_y, _release_z");
  • SOS request for assistance in dealing with the attack. For example, this field is set to "TRUE" to ask a remote protection service for assistance to end the attack in progress;
  • the notification messages can be of different natures (for example STATUS, LOCAL_MITIGATION, SOS, etc.).
  • the first agent 113 can send to the second agent 123, directly or via at least one intermediate agent used by at least one dispatcher, one or more notification messages describing the characteristics of an attack: NOTIFY (ATTACKJD), NOTIFY (ATTACK_ID, ATTACK_DESCRIPTOR) or NOTIFY (ATTACK_ID, STATUS).
  • NOTIFY ATTACKJD
  • NOTIFY ATTACK_ID
  • ATTACK_DESCRIPTOR NOTIFY
  • STATUS STATUS
  • the first agent 113 can send to the second agent 123, directly or via at least one intermediate agent used by at least one dispatcher, one or more notification messages describing a local mitigation action, as activated by the first protection service 112 of the first agent 113 sending the notification message: NOTIFY (ATTACKJD, LOCAL_MITIGATION).
  • the first agent 113 can send to the second agent 123, directly or via at least one intermediary agent used by at least one dispatcher, one or more notification messages requesting assistance for the mitigation of the attack : NOTIFY (ATTACKJD, SOS).
  • an attack can vary during the lifetime of such an attack. For example, new sources may be involved, other protocols may be exploited, etc. It is therefore desirable to be able to identify the attack, for example by means of the persistent attribute ATTACKJD, to follow its evolution.
  • notification messages can be sent to notify the agents having subscribed to the information sharing service offered by the first protection service, of updates to the description of the attack.
  • the agents having subscribed to the information sharing service offered by the first protection service can thus update their filters according to the updates of the attack.
  • the attack description attribute ATTACK_DESCRIPTOR can also be used to correlate different notification messages received from different protection services.
  • Different information can possibly be aggregated in the same notification message, for example:
  • FIG. 8 illustrates the steps implemented by the first agent 113 used by a first protection service 112, to identify an attack and inform the second agent 123 thereof
  • FIG. 9 illustrates the steps implemented by the second agent 123, receiving the attack information and determining an action to be carried out.
  • the first agent 113 can identify an attack (step referenced 81 in FIG. 8, similar to step 221 in FIG. 2).
  • the attack may be detected by the first agent 113, by another agent used by the first protection service 112, or be detected by a network node 111 protected by the first protection service 112.
  • the policy for identifying attacks for which at least one second agent (for example the second agent 123) has subscribed to at least one information sharing service from the first protection service may have been previously defined (80) .
  • the first agent 113 identifies an attack corresponding to this policy.
  • the first agent 113 can then identify (82) at least one protection service, and for example all the protection services, using an agent having subscribed to at least one information sharing service from the first protection service.
  • the first agent 113 can consult the subscription database 24.
  • the first agent 113 can then send notification messages to the agents having subscribed to at least one information sharing service offered by the first protection service (step referenced 83 in FIG. 8, similar to step 222 in FIG. 2).
  • the first agent 113 can send (84) several notification messages, in particular when the attack is modified, to inform the agents having subscribed to at least one information sharing service offered by the first service and allow them to update their filters. A delay is observed between two consecutive notifications sent to the same remote agent.
  • an agent of a protection service having subscribed to at least one information sharing service offered by the first protection service for example the second agent 123, performs security checks (92) to ensure that the first agent 113 is authorized to send notification messages.
  • the second agent 123 can consult the subscription database 24.
  • the second agent 123 extracts the information included in the message to identify the agent sending the notification message (ie, the first agent 113), and, for example, identify the service protection to which it belongs (ie, the first protection service 112), determine the nature of the notifications (ie, SOS, STATUS, LOCAL_MITIGATION, etc.). From the information or information extracted, and in particular from the nature of the notifications, the second agent 123 can determine at least one action to be carried out.
  • the notification message informs the second agent 123 that an attack is in progress
  • the information characteristic of the attack is extracted from the mitigation message (95) and relayed to an entity in charge of the mitigation (" mitigator ") of the second protection service 112 which implements the second agent 123, so that it takes the ad hoc protection measures in order to anticipate the attack (96).
  • these actions can be inspired by those indicated in the notification message if the LOCAL_MITIGATION field has been completed.
  • the second agent 123 can check whether actions local to the second protection service can be initiated (97).
  • the second agent 123 can send an action sharing message "SHARE_ACTION ()" to the first agent 113, directly or via at least one intermediate agent used by at least one dispatcher, to share a mitigation plan with the first protection service and locally implement mitigation actions (98).
  • the second agent 123 can send to the first agent 113, the sender of the notification message, at least one SHARE_ACTION action sharing message (ATTACK_ID, LOCAL_MITIGATION).
  • the mitigation plan shared using the SHARE_ACTION () message is not necessarily implemented by the issuing protection service, but can be retrieved from a database capitalizing on BCP (in English "Best Current Practices") or past experiences for similar attacks.
  • the mitigation plan can correspond to filtering actions, the provision of resources for redirecting flows, etc.
  • the simplified mitigation plan presented in Table 1 does not describe the target of the attack, but only characterizes the source of the suspicious traffic which is at the origin of the attack: the traffic emitted by such a source (1.2.3.0/24) is therefore filtered in this example.
  • the SHARE_ACTION action sharing message can be broadcast to the first protection service having requested a request for assistance, as well as to other protection services belonging to the same federation.
  • the first agent 113 can therefore remain waiting for a SHARE_ACTION sharing message (step referenced 85 in FIG. 8). Upon receipt of such a message, the first agent 113 can extract the information conveyed by this message (86) to share a mitigation plan with the second protection service and locally implement mitigation actions (87).
  • the steps presented above in relation to FIGS. 8 and 9 can also be implemented by reversing the direction of the messages if the first agent 113 has subscribed to at least one information sharing service offered by the second. protection service 122. In this case, it is the second agent 123 which sends at least one notification message to the first agent 113.
  • a particular embodiment is presented below, implemented by a protection service agent as described above, making it possible to identify at least one access provider responsible for at least one resource involved in the propagation. characteristic of the attack.
  • the protection services can collaborate with access providers to block upstream the machines involved in an attack, thus making it possible to limit the propagation of the attack.
  • Protection service agents can collaborate with access providers to block upstream the machines injecting traffic characteristic of an attack as soon as possible so as to limit the propagation of the traffic characteristic of the attack. According to a particular embodiment, these access providers can then prevent these machines from connecting to the access network (s), by refusing to allocate them IP addresses / prefixes for example.
  • access providers have a programming interface (API) to offer value-added services to third parties, such as address filtering.
  • API programming interface
  • an agent of a protection service determines the identity of the access provider responsible for an IP resource involved in an attack.
  • the agent of a protection service queries for example the database maintained, for example, by the regional register RIPE (European IP Networks).
  • this embodiment assumes that the access providers expose a programming interface (API) to offer third-party value-added services, for example in one or more validation servers hosted by these providers. 'access.
  • API programming interface
  • the response to this request indicates that the IP resource "80.12.102.157” is allocated, according to this example, to the access provider "Orange SA", and that the validation server (s) are located by the addresses "80.12.102.15” and "80.12.102.16".
  • the response specifies in particular that the validation server (s) for this address range "80.12.102.157" can be reached with two addresses: "80.12.102.15” and "80.12.102.16".
  • the protection service agent can send a filtering request to the access provider, for example in the form of an ACTION_REQUEST () message.
  • the access provider On receipt of the ACTION_REQUEST () message, the access provider carries out checks, making it possible in particular to verify that the agent having issued the filtering request is a trusted entity.
  • the access provider can send an ACTION_REPLY message to the agent.
  • the protection service to which the agent belongs can then activate certain filters to block traffic from the malicious machine. It is noted that this filtering can be implemented immediately or after an observation phase.
  • Figures 10 and 11 illustrate the implementation of such a solution allowing an access provider to filter the traffic characteristic of an attack.
  • the first protection service 112 protecting the first network 111, connected to the Internet 13, and the sources SI 141 to Sk 14k also connected to the Internet 13 via the access providers AP # 1,151 to AP # n 15n. If we consider that all the access providers AP # 1 151 to AP # n 15n implement the solution described above, filtering actions can be distributed among all the access providers, to block the traffic characteristic of an attack upstream of the Internet 13.
  • this solution is of interest even when all the access providers do not implement the solution described above. Indeed, from the moment when certain access providers set up the solution described above, for example the access providers AP # 1 151 and AP # n 15n, protection services, such as the first service of protection 122, have a limited list of filters to manage.
  • Such an agent comprises a memory 101 comprising a buffer memory, a processing unit 102, equipped for example with a programmable calculation machine or with a dedicated calculation machine, for example a processor P, and controlled by the program computer 103, implementing steps of the collaboration or collaboration request method according to at least one embodiment of the invention.
  • the code instructions of the computer program 103 are for example loaded into a RAM memory before being executed by the processor of the processing unit 102.
  • the processor of the processing unit 102 implements steps of the collaboration or collaboration request method described above, according to the instructions of the computer program 103, for:
  • the protection service is managed by the administrator of the network infrastructure to be protected; the protection service is managed by another entity than the administrator of the network infrastructure to be protected;
  • the protection service is activated within the network infrastructure to be protected
  • the protection service is activated outside the network infrastructure to be protected (typically, access provider, transit operator, service operator, "cloud” service provider);
  • the network infrastructure to be protected can be an operator network, a corporate network, a residential customer network, a fleet of 5G mobiles, etc. ;
  • the network infrastructure to be protected can be used to provide a set of services, including for example a connectivity service (packet transfer service, typically), a Virtual Private Network (VPN) service in English ) or other value-added services, such as telephony services, television program broadcasting (IPTV service), loT telemetry ("Internet of Things”), etc. ;
  • a connectivity service packet transfer service, typically
  • VPN Virtual Private Network
  • IPTV service television program broadcasting
  • loT telemetry Internet of Things
  • a network infrastructure can invoke the services of one or more protection services; these protection services can protect from attacks of different kinds or be associated with different services, for example according to the traffic profiles characteristic of the different services supported by the network infrastructure;
  • the sources of an attack can also be resources hosted within the network infrastructure to be protected, which can be the case of “Man-in-the-Middle” (MITM) attacks, for example;
  • MITM Man-in-the-Middle
  • a network operator who applies filters can also be considered as a protection service provider within the framework of the invention.
  • the collaboration solution between protection services proposed allows:
  • the protection services but also the service providers responsible for the networks to which the source of the attack is connected, and / or

Landscapes

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

Abstract

L'invention concerne un procédé de collaboration entre services de protection associés à un ou plusieurs domaines. Selon l'invention, un tel procédé comprend : - l'identification (221), par un premier agent utilisé par un premier service de protection, d'une attaque sur au moins une ressource gérée par un domaine protégé par ledit premier service de protection, - la transmission (222), à au moins un deuxième agent utilisé par un deuxième service de protection ayant souscrit auprès du premier service de protection à au moins un service de partage d'informations proposé par le premier service de protection, d'au moins une information relative à ladite attaque identifiée par le premier agent.

Description

DESCRIPTION
TITRE : Procédés de collaboration et de demande de collaboration entre services de protection associés à au moins un domaine, agents et programme d'ordinateur correspondants.
1. Domaine de l'invention
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 permettant à différents services de protection, protégeant un ou plusieurs domaines, de collaborer. De tels services de protection sont par exemple de type DPS (en anglais « DDoS Protection Services », pour « Distributed Déniai of Service Protection Services », ou services de protection d'attaques par déni de services distribuées), mettant par exemple en oeuvre, mais non exclusivement, une architecture de type DOTS, en anglais « DDoS Open Threat Signaling »). Le service de protection et l'infrastructure déployée pour fournir un tel service sont appelés indifféremment « service de protection » ci- après.
En particulier, l'invention offre une solution permettant de coordonner des actions de mitigation lorsqu'une attaque par déni de services est identifiée.
L'invention trouve notamment des applications dans tout domaine utilisant des réseaux informatiques pouvant être soumis à une attaque de type virus, SPAM, SPIT (en anglais « SPAM over IP Telephony », ou SPAM sur communication téléphonique sur IP), DDoS, etc.
2. Art antérieur
On s'attache plus particulièrement dans la suite de ce document à décrire une problématique existant dans le domaine de la mitigation d'attaques DDoS. Bien sûr, l’invention ne se limite pas à ce domaine particulier d’application, mais présente un intérêt pour la mitigation d'attaques de toute nature.
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 sont proposés par certains fournisseurs d'accès ou de services à leurs clients. De tels services de protection, ou DPS (« DDoS Protection Service » en anglais), peuvent être hébergés au sein des infrastructures exploitées par les fournisseurs d'accès ou dans le « cloud » (en français « nuage »). Ils permettent notamment de distinguer le trafic « légitime », i.e., les données consenties par l'utilisateur, du trafic « suspect ».
Lorsqu'un service de type DPS est hébergé dans le « cloud », il est difficile de détecter une attaque DDoS de façon anticipée, car un tel service n'est pas nécessairement présent sur les chemins de routage (par défaut) permettant de joindre le réseau victime d'une attaque DDoS.
Pour résoudre ce problème, il a été notamment proposé de mettre en place des tunnels pour forcer le trafic (entrant ou sortant, en anglais « inbound » ou « outbound ») sur un site ou un réseau destiné à être inspecté par le service DPS. Toutefois, cette approche augmente considérablement la latence observée par les utilisateurs et impose des contraintes de dimensionnement du service DPS pour être en mesure de traiter tout le trafic entrant ou sortant de tous les utilisateurs du réseau, sans pour autant dégrader la performance ou le niveau de qualité du service fourni au client. En outre, de tels tunnels sont considérés comme des vecteurs d'attaque potentiels.
Lorsqu'un service DPS est hébergé au sein d'une infrastructure exploitée par un fournisseur d'accès, même si le service DPS est présent sur le chemin de routage du trafic entrant ou sortant d'un réseau, des difficultés peuvent survenir pour l'identification du trafic suspect. Notamment, avec l'augmentation du trafic chiffré, transporté en particulier sur UDP (par exemple, le trafic QUIC, pour « Quick UDP Internet Connection » en anglais), il est difficile de distinguer le trafic légitime du trafic suspect. La difficulté d'accéder en clair aux messages de contrôle, tels que les messages « SYN/SYN-ACK/ACK » prévus dans le protocole TCP, est un autre exemple de la complexité associée à la vérification du consentement d'un 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 en particulier à un nœud client, dit client DOTS, d'informer un serveur, dit serveur DOTS, qu'il a détecté une attaque DDoS et que des actions appropriées sont requises.
Ainsi, si un domaine client est la cible d'une attaque DDoS, un client DOTS faisant partie de ce domaine client peut envoyer un message au serveur DOTS pour demander de l'aide. Ce dernier coordonne, avec une entité de mitigation (en anglais « mitigator »), les actions à effectuer pour que le trafic suspect, associé à l'attaque de déni de service, ne soit plus acheminé vers le domaine client, alors que le trafic légitime continue d'être acheminé normalement vers le domaine client. L'entité de mitigation peut en particulier être co-localisée avec le serveur DOTS.
L'architecture DOTS repose sur l'utilisation de 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 traiter l'attaque.
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 », ou tout le trafic UDP destiné au numéro de port 443.
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, Boucadair, M. et al., décembre 2017.
L'architecture DOTS couvre uniquement la relation entre un client DOTS et son serveur DOTS, pour demander de l'assistance lorsque le client DOTS détecte une attaque. En d'autres termes, les clients/serveurs DOTS appartenant à d'autres infrastructures DPS ne sont pas au courant de l'attaque.
Il existe donc un besoin pour une nouvelle technique permettant notamment d'informer d'autres infrastructures DPS d'une attaque à grande échelle, par exemple une attaque de déni de service, et ainsi de coordonner des actions entre plusieurs DPS, par exemple des actions de mitigation.
3. Exposé de l'invention
L'invention repose sur un nouveau procédé de collaboration entre services de protection associés à un ou plusieurs domaines, mis en œuvre par un premier agent utilisé par un premier service de protection, comprenant :
l'identification, par le premier agent, d'une attaque sur au moins une ressource gérée par un domaine protégé par le premier service de protection, la transmission, à au moins un deuxième agent utilisé par un deuxième service de protection ayant souscrit auprès du premier service de protection à au moins un service de partage d'informations proposé par le premier service de protection, d'au moins une information relative à l'attaque identifiée par ledit premier agent.
Typiquement, un agent utilisé par un service de protection appartient à un domaine / une infrastructure offrant ce service de protection.
De cette façon, lorsqu'un domaine client subit une attaque, le service de protection associé à ce domaine client peut propager des informations relatives à cette attaque vers des services de protection associés à ce domaine client ou à d'autres domaines clients, afin que ces autres services de protection puissent anticiper ladite attaque ou une attaque similaire et ainsi protéger ces domaines clients. Aussi, la coordination permet de mettre en place un plan de mitigation distribué impliquant plusieurs DPS ou réseaux d'accès permettant ainsi de limiter la propagation de certaines attaques.
L'étape de transmission peut être restreinte à certains types d'attaques, d'agents voisins, etc. Des politiques (« policies », en anglais) sont typiquement fournies à l'agent qui met en oeuvre ledit procédé de collaboration.
En d'autres termes, il est possible de communiquer des informations relatives à une attaque identifiée par un service de protection, par exemple DPS, à d'autres services de protection qui pourraient en avoir l'usage, quelque soit la portée de l'attaque identifiée, et ainsi d'éviter, ou à tout le moins de ralentir, la propagation d'une attaque.
Par exemple, une telle attaque peut être de type :
attaque par déni de service (DDoS, typiquement) ;
virus informatique ;
SPAM ;
SPIT ;
etc.
En particulier, si une attaque est une attaque par déni de service, identifiée par un service de protection protégeant un premier domaine, il est possible d'informer les services de protection protégeant d'autres domaines des actions de mitigation engagées, permettant ainsi aux services de protection protégeant ces autres domaines d'engager par anticipation des actions de mitigation. On diminue ainsi le risque de propagation de l'attaque dans d'autres domaines, par exemple d'autres régions du réseau Internet, ou de dégradation du service fourni par les services de protection protégeant ces autres domaines. Ainsi l'invention ne se limite pas à la propagation d'informations vers des services de protection déployés au sein de domaines voisins et/ou situés sur le chemin de routage du trafic d'une attaque. Au contraire, l'invention permet de créer des interconnexions entre des services de protection distants qui souhaitent établir une collaboration entre eux pour maintenir ou mettre en oeuvre une politique de sécurité plus efficace pour traiter des attaques susceptibles d'affecter les domaines sous-jacents qu'ils protègent, grâce par exemple au partage des plans de mitigation qu'ils mettent en oeuvre. Ces interconnexions sont établies grâce à la mise en oeuvre, conformément à l'invention, d'un mécanisme de souscription préalable auprès des services de protection proposant le partage d'informations sur tout ou partie des attaques qu'ils identifient. Lors de cette souscription, divers contrôles de sécurité peuvent être effectués pour déterminer s'il convient de partager de telles informations avec le service de protection à l'origine de la demande de souscription.
L'invention permet par le biais de ce partage d'anticiper efficacement les attaques, sans imposer aux services de protection collaborant entre eux d'avoir une visibilité sur ou de contrôler le même trafic et, en particulier le trafic de l'attaque. L'invention permet une collaboration de services de protection entre eux quelle que soit la nature et la portée d'une attaque, et notamment les ressources impliquées (à l'origine de l'attaque ou attaquées).
Ainsi, dans un mode particulier de réalisation, l'invention repose sur une caractérisation d'une attaque, dans les informations fournies aux services de protection ayant souscrit au service de partage d'informations, sans l'associer explicitement aux cibles de ladite attaque visibles d'un service de protection (par exemple sans divulguer les adresses des cibles de l'attaque telles que vues par le service de protection qui a identifié l'attaque). Cette caractéristique est importante pour la préservation de la confidentialité des communications et la nature de celles-ci (par exemple à quelle(s) application(s) elles sont associées) au sein d'un domaine protégé par un service de protection.
Selon au moins un mode de réalisation, la solution proposée permet de faciliter la coordination des actions de mitigation notamment, grâce au partage d'informations relatives aux attaques. Aussi, elle permet de réduire le temps requis pour la mise en place de plans de mitigation grâce au partage et à la dissémination d'actions de mitigation entre domaines DPS.
Selon au moins un mode de réalisation, la solution proposée permet également de propager des informations a priori fiables, puisque ces informations sont obtenues par le service de protection ayant identifié une attaque.
Selon au moins un mode de réalisation, la solution proposée permet également de propager rapidement des informations, ce qui permet aux services de protection recevant les informations relatives aux attaques d'anticiper ces attaques et de réagir d'une manière optimale de manière à limiter un usage abusif de ressources réseau.
Selon une caractéristique particulière, la transmission, à au moins un deuxième agent utilisé par un deuxième service de protection, d'au moins une information relative à l'attaque identifiée par le premier agent, met en oeuvre l'émission d'au moins un message de notification à destination du ou des deuxième(s) agent(s) ou d'un agent intermédiaire en charge de la redirection des messages.
Par exemple, ledit au moins un message de notification comprend au moins une information appartenant au groupe comprenant :
une information relative à la souscription, par ledit au moins un deuxième agent, à au moins un service de partage d'informations proposé par ledit premier service de protection ; un identifiant de l'attaque ;
une information de description de l'attaque ;
une information relative à l'état de l'attaque ;
une information indiquant si une action de mitigation est mise en oeuvre par le premier service de protection ;
une information indiquant une action de mitigation mise en oeuvre par le premier service de protection ;
une demande d'assistance pour traiter l'attaque ;
etc.
Ces différentes informations peuvent être transmises dans des messages de notification distincts, ou agrégées dans un même message de notification.
En particulier, un nouveau message de notification peut être émis en cas de modification de l'attaque. Par exemple, si de nouvelles sources sont impliquées dans l'attaque, un nouveau message de notification est transmis au(x) deuxième(s) agent(s), éventuellement par l'intermédiaire d'un agent intermédiaire en charge de la redirection des messages.
Selon un mode de réalisation particulier, le procédé de collaboration entre services de protection comprend une étape préalable de souscription, mettant en oeuvre :
l'établissement d'une session entre le premier agent et ledit au moins un deuxième agent, la réception, par le premier agent, d'au moins un message de souscription à au moins un service de partage d'informations proposé par le premier service de protection,
l'extraction et le stockage des informations véhiculées dans ledit au moins un message de souscription.
Par exemple, ledit au moins un message de souscription comprend au moins une information appartenant au groupe comprenant :
une information relative à un type de service de partage d'informations demandé (par exemple tous les services de partage d'informations du premier service de protection, le service de partage d'informations relatives à des attaques DDoS du premier service de protection, le service de partage d'informations relatives à la détection de virus du premier service de protection, le service de partage d'informations relatives à des attaques SPIT du premier service de protection, etc.) ;
un niveau d'alerte associé audit au moins un deuxième agent (par exemple seules les alertes relatives aux attaques critiques sont envoyées, ou seules les alertes qui correspondent aux filtres indiqués par un agent utilisé par un service de protection sont envoyées) ;
une information de redirection vers un autre agent utilisé par le deuxième service de protection (précisant, par exemple, si les messages de notification doivent être envoyés vers un autre agent utilisé par le même service de protection) ;
une durée de validité ;
etc.
Ces différentes informations peuvent être transmises dans des messages de souscription distincts, ou agrégées dans un même message de souscription.
En particulier, un tel procédé comprend la suppression automatique, à l'expiration d'une durée de validité associée au message de souscription, des informations véhiculées dans un message de souscription préalablement stockées.
L'invention repose également sur un nouveau procédé de demande de collaboration entre services de protection associés à un ou plusieurs domaines, mis en oeuvre par au moins un deuxième agent utilisé par un deuxième service de protection ayant souscrit auprès d'un premier service de protection à au moins un service de partage d'informations proposé par le premier service de protection, selon lequel, un premier agent utilisé par le premier service de protection ayant identifié une attaque sur au moins une ressource gérée par un domaine protégé par le premier service de protection, le procédé comprend :
la réception, par le deuxième agent, d'au moins une information relative à l'attaque identifiée par le premier agent,
la détermination d'au moins une action à effectuer, à partir de la ou des informations relatives à l'attaque. En particulier, la réception met en œuvre la réception d'au moins un message de notification, tel que décrit ci-dessus, transmis par ledit premier agent ou par un agent intermédiaire en charge de la redirection des messages.
Selon un mode de réalisation particulier, la réception met également en œuvre la réception d'au moins un message de notification transmis par un agent utilisé par un service de protection distinct du premier service de protection.
Il est ainsi possible de corréler les informations reçues de différents agents, ce qui permet notamment de confirmer la réalité ou l'étendue d'une attaque.
Par exemple, ladite au moins une action comprend la transmission, à une entité en charge de la mitigation du deuxième service de protection, de la ou des informations relatives à l'attaque. Eventuellement, ladite au moins une action comprend une mise à jour des filtres gérés par le deuxième service de protection.
Selon un autre exemple, ladite au moins une action comprend la transmission au premier agent, ou à un agent intermédiaire en charge de la redirection des messages, d'un message de partage d'actions avec le premier service de protection. Par exemple, le deuxième agent peut demander à partager un plan de mitigation avec le premier agent (autrement dit d'être informé de ce plan de mitigation).
Selon un mode de réalisation particulier, le procédé de demande de collaboration entre services de protection comprend une étape préalable de souscription mettant en œuvre :
l'établissement d'une session entre le premier agent et ledit au moins un deuxième agent, la transmission, par ledit au moins un deuxième agent, d'un message de souscription (tel que décrit précédemment) à au moins un service de partage d'informations proposé par le premier service de protection.
En particulier, ledit au moins un deuxième agent retransmet le message de souscription avant l'expiration d'une durée de validité associée audit message de souscription.
Selon un mode de réalisation particulier, le procédé mis en œuvre par le premier et/ou le deuxième agent comprend en outre :
l'identification d'au moins un fournisseur d'accès responsable d'au moins une ressource impliquée dans la propagation du trafic caractéristique de ladite attaque,
la transmission audit au moins un fournisseur d'accès d'une demande de filtrage du trafic caractéristique de ladite attaque entrant et/ou sortant de ladite au moins une ressource.
De cette façon, les services de protection peuvent collaborer avec les fournisseurs d'accès pour filtrer, voire bloquer, en amont le trafic émis par des machines impliquées dans une attaque, permettant ainsi de limiter la propagation de l'attaque au plus près de sa source.
On note également que, selon l'art antérieur, lorsqu'un grand nombre de machines est impliqué dans la réalisation des attaques, la mise en place de politiques de filtrage adaptées, c'est-à-dire capables d'isoler le trafic en provenance de l'ensemble des machines impliquées dans les attaques, est d'autant plus compliquée que ces machines peuvent être massivement distribuées sur plusieurs réseaux distincts. Dans un tel contexte, la mise en place de filtres est compliquée par l'identification et la déclaration d'un nombre d'adresses ou de réseaux important, avec des risques d'erreur de configuration susceptibles de mettre en péril l'acheminement de trafics légitimes. En outre, les performances de commutation des machines sur lesquelles de tels filtres (ou ACL, en anglais « Access Control List ») sont installés peuvent être inversement proportionnelles au nombre de listes d'accès configurées : plus il y a de filtres, plus les décisions d'acheminement de paquets prennent du temps, au risque de dégrader les performances de commutation des machines. L'installation d'un nombre important d'ACL est elle-même considérée comme une attaque DDoS.
Le mode de réalisation proposé ci-dessus permet notamment de répartir les actions de filtrage entre plusieurs fournisseurs d'accès, ce qui permet de faciliter la mise en place des filtres à grande échelle.
Un autre mode de réalisation concerne un agent utilisé par un service de protection, configuré pour identifier une attaque et transmettre au moins une information relative à l'attaque identifiée à un agent utilisé par un autre service de protection ayant souscrit auprès de ce service de protection à au moins un service de partage d'informations proposé par ce service de protection, et/ou configuré pour recevoir au moins une information relative à une attaque identifiée par un agent utilisé par un autre service de protection auprès duquel il a souscrit à un service de partage d'informations et déterminer au moins une action à effectuer en conséquence.
Par exemple, un tel agent est un nœud de l'infrastructure utilisée pour la mise en œuvre du service de protection, embarquant des fonctionnalités spécifiques lui permettant d'identifier une attaque / transmettre au moins une information relative à l'attaque et/ou recevoir au moins une information relative à une attaque / déterminer au moins une action.
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 collaboration entre services de protection, ou de demande de collaboration entre services de protection, selon au moins un mode de réalisation de l'invention, lorsque ce ou ces programmes est/sont exécuté(s) par un processeur. Dans encore un autre mode de réalisation, l'invention concerne un ou plusieurs supports d’informations, inamovibles, ou partiellement ou totalement amovibles, lisibles par un ordinateur, et comportant des instructions d'un ou plusieurs programmes d'ordinateur pour l'exécution des étapes du procédé de collaboration entre services de protection, ou de demande de collaboration entre services de protection, selon au moins un mode de réalisation de l'invention.
Les procédés selon l'invention peuvent donc être mis en oeuvre de diverses manières, notamment sous forme câblée et/ou sous 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 :
[Fig 1] La figure 1 illustre un exemple de réseau de communication mettant en oeuvre un procédé de collaboration, ou de demande de collaboration, entre services de protection, selon un mode de réalisation de l'invention ;
[Fig 2] La figure 2 présente les principales étapes d'un procédé de collaboration, ou de demande de collaboration, entre services de protection, selon au moins un mode de réalisation de l'invention ;
[Fig 3 A]
[Fig 3B]
[Fig 3C] Les figures 3A à 3C illustrent différents modes de communication entre des agents utilisés par des services de protection distincts ;
[Fig 4]
[Fig 5] Les figures 4 et 5 présentent les principales étapes mises en oeuvre par un agent local et par un agent distant au cours d'une phase de souscription ;
[Fig 6]
[Fig 7] Les figures 6 et 7 illustrent la transmission et l'utilisation et d'un message de notification selon un mode de réalisation de l'invention ;
[Fig 8]
[Fig 9] Les figures 8 et 9 présentent les principales étapes mises en oeuvre par un agent local et par un agent distant au cours d'une phase de notification ;
[Fig 10]
[Fig 11] Les figures 10 et 11 illustrent un mode de réalisation particulier permettant à un fournisseur d'accès de filtrer le trafic caractéristique d'une attaque ; [Fig 12] La figure 12 présente la structure simplifiée d'un agent 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 la collaboration entre au moins deux services de protection associés à un ou plusieurs domaines réseau. L'invention permet en particulier d'informer un service de protection distant associé à un domaine distant, lorsqu'une attaque sur une ressource gérée par un domaine local est détectée par le service de protection local.
On présente, en relation avec la figure 1, différents équipements d'un réseau de communication aptes à mettre en oeuvre la collaboration entre services de protection selon un mode de réalisation de l'invention.
On considère par exemple un premier domaine 111, associé à un premier service de protection 112, noté par exemple DPS#1, et un deuxième domaine 121, associé à un deuxième service de protection 122, noté par exemple DPS#2.
Par exemple, un domaine comprend une ou plusieurs machines, encore appelées noeuds. On entend ici par « domaine » ou « réseau » un ensemble de machines ou noeuds placés sous la responsabilité d'une même entité.
Les premier et deuxième services de protection 112 et 122 protègent respectivement les ressources réseau des premier et deuxième domaines 111 et 121. Les premier et deuxième domaines 111 et 121 peuvent être connectés au réseau Internet 13.
Des sources d'attaques SI 141, S2 142, ..., Sk 14k peuvent également être connectées au réseau Internet 13 via de fournisseurs d'accès AP#1 151, AP#2 152, AP#n 15n (en anglais « Access Providers »).
La figure 2 illustre les principales étapes mises en oeuvre pour la collaboration entre services de protection dans un réseau de communication tel que celui illustré en figure 1.
Au cours d'une phase de détection, un premier agent 113 utilisé par le premier service de protection 112 protégeant le premier domaine 111 identifie (221) une attaque sur au moins une ressource gérée par le premier domaine 111.
Par exemple, une attaque peut être détectée par un nœud du premier domaine 111 (par exemple un client DOTS) ou par un nœud de l'infrastructure utilisée pour la mise en œuvre du premier service de protection 121 (premier agent 113 embarquant des fonctionnalités spécifiques selon l'invention ou autre nœud). Le premier agent 113 utilisé par le premier service de protection peut donc soit détecter lui-même l'attaque, soit recevoir cette information de la part d'un autre nœud.
Le premier agent 113 peut alors décider de transmettre (222) à au moins un autre agent, par exemple à un deuxième agent 123 utilisé par le deuxième service de protection 122, protégeant le deuxième domaine 112, au moins une information relative à l'attaque identifiée par le premier agent 113. Une telle information peut éventuellement être transmise à un agent intermédiaire, qui se charge de la retransmettre au deuxième agent 123 notamment.
De son côté, le deuxième agent 123 utilisé par le deuxième service de protection 122 reçoit (223) la ou les informations relatives à l'attaque identifiée par le premier agent 113 utilisé par le premier service de protection 112.
A partir de la ou des informations reçues relatives à l'attaque, le deuxième agent 123 peut déterminer (224) au moins une action à effectuer.
Suite à la phase de détection 22, une phase de mitigation 23 des attaques peut être mise en œuvre.
Par exemple, il est possible de coordonner plusieurs actions de mitigation engagées suite à la détection d'une attaque, notamment à l'échelle de l'Internet, au cours de la phase de mitigation 23.
Préalablement à la phase de détection 22, une phase de souscription 21 peut être mise en œuvre.
Une telle phase de souscription 21 met par exemple en œuvre l'établissement 211 d'une session entre le premier agent 113 utilisé par le premier service de protection 112, et au moins un agent utilisé par un autre service de protection, par exemple le deuxième agent 123 utilisé par le deuxième service de protection 122.
Pour souscrire aux services de partage d'informations (appelé simplement ci-après service de partage) du premier service de protection 112, le deuxième agent 123 transmet (212) au moins un message de souscription au premier agent 113. Un tel message peut éventuellement être transmis à un agent intermédiaire, qui se charge de le retransmettre au premier agent 113 notamment.
De son côté, le premier agent 113 reçoit (213) le ou les messages de souscription, et stocke (214), par exemple dans une base de données de souscription distante 24, les informations véhiculées par le ou les messages de souscription.
La phase de détection 22 peut alors être mise en œuvre.
La solution proposée permet donc de coordonner des services de protection, éventuellement à l'échelle de l'Internet, de la phase de détection de l'attaque à la phase de mitigation de l'attaque (quelle que soit l'origine de l'attaque, quel que soit le vecteur (par exemple un objet connecté, un tunnel, etc.) et quelles que soient les victimes (réseau, terminal service, etc.)). Selon au moins un mode de réalisation, la solution proposée permet de garantir une cohérence globale et rapide des informations relatives à l'attaque (origine, nature, contenu, cible, vecteur, etc.) et des actions engagées pour la résoudre.
On note que, dans un mode de réalisation particulier, plusieurs services de protection sont associés à un même domaine, i.e., protègent le même domaine. Un exemple d'application est un réseau d'entreprise en « multi-homing ». Dans ce cas, les premier et deuxième domaines 111 et 121 sont un seul et même domaine.
5.2 Exemples d'application
On décrit ci-après des exemples de mise en oeuvre de l'invention avec des services de protection de type DPS, utilisés principalement pour traiter les attaques DDoS.
On note toutefois que la solution proposée, telle que présentée ci-dessous notamment, s'applique à d'autres attaques de sécurité telles que la propagation de virus, l'exploitation des vulnérabilités des systèmes d'exploitation, etc.
5.2.1 Définition des agents
La solution proposée repose sur l'attribution de fonctionnalités spécifiques à un ou plusieurs noeuds de l'infrastructure utilisée pour la mise en oeuvre d'un service de protection, notés « agent », ou, selon un mode de réalisation particulier mettant en oeuvre des services de protection de type DPS, « agent DIA » (pour « DPS IDAD Agent », où IDAD signifie « Inter-DPS Attack Dissémination and mitigation action sharing and assistance », i.e., assistance et partage des actions de mitigation et d'atténuation d'attaque entre DPS).
Un ou plusieurs agents peuvent être activés par un service de protection. Un agent d'un service de protection peut s'interfacer avec un ou plusieurs agents d'autres services de protection.
5.2.2 Communication des agents
A) Etablissement d'une session
Les sessions de communication entre les agents peuvent être établies en utilisant des protocoles connus, par exemple :
- DTLS (en anglais « Datagram Transport Layer Security », tel que décrit dans le document « Datagram Transport Layer Security Version 1.2 », RFC 6347, Rescorla, E. et N. Modadugu DOI 10.17487/ FC6347, janvier 2012),
- DTLS 1.3 (en anglais « Datagram Transport Layer Security », tel que décrit dans le document « The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", draft-ietf-tls-dtlsl3- 22 », Rescorla, E., Tschofenig, H., et N. Modadugu, novembre 2017),
- TLS (en anglais « Transport Layer Security », tel que décrit dans le document « The Transport Layer Security (TLS) Protocol Version 1.2 », RFC 5246, Dierks, T. et E. Rescorla, DOI 10.17487/RFC5246, août 2008 ou le document « The Transport Layer Security (TLS) Protocol Version 1.3 », RFC8446, E. Rescorla, DOI 10.17487/R FC8446, août 2018).
Les échanges DTLS ou TLS et les échanges concernant la gestion des clés de sécurité sont classiques et ne sont pas décrits plus en détail.
Selon un mode de réalisation particulier, on suppose que les agents utilisés par les services de protection s'authentifient mutuellement. Ainsi, les messages reçus d'une machine usurpant l'identité d'un agent légitime sont rejetés par un autre agent. De la même manière, les demandes d'un agent utilisé par un premier service de protection, non-autorisé à accéder aux services de partage d'informations proposé par un deuxième service de protection, sont ignorées par un agent utilisé par un deuxième service de protection.
Par exemple, cette procédure d'authentification mutuelle est mise en place par les agents des services de protection.
B) Modes de communication
Les agents utilisés par différents services de protection peuvent communiquer directement entre eux, ou via un agent intermédiaire en charge de la redirection des messages. Cet agent intermédiaire est par exemple utilisé par un répartiteur de fédération, ou FD (en anglais « Fédération Dispatcher »).
Les figures 3A à 3C illustrent différents exemples de communication entre les agents utilisés par différents services de protection.
La figure 3A illustre un exemple de communication en mode « point-à-point », selon lequel les agents échangent directement des messages entre différents services de protection. Par exemple, un premier agent 321 d'un deuxième service de protection DPS 32 échange des messages directement avec un premier agent 311 d'un premier service de protection DPS 31, un premier agent 341 d'un quatrième service de protection DPS 34 et un premier agent 351 d'un cinquième service de protection DPS 35. Un deuxième agent 322 du deuxième service de protection DPS 32 échange des messages directement avec un premier agent 331 d'un troisième service de protection DPS 33. Les premier 321 et deuxième 322 agents du deuxième service de protection DPS 32 peuvent communiquer entre eux puisqu'ils sont utilisés par le même service de protection. Selon l'exemple illustré en figure 3A, le deuxième service de protection DPS 32 peut envoyer quatre fois le même message vers les autres services de protection DPS 31, 33, 34 et 35.
Les figures 3B et 3C illustrent des exemples de communication en mode « fédération ». Ce mode suppose que les services de protection sont organisés en des fédérations. Les agents envoient des messages vers un répartiteur de la fédération, qui se charge de relayer les messages d'un agent d'un service de protection de la fédération vers un agent d'un autre service de protection de la fédération ou vers un répartiteur d'une autre fédération.
Selon l'exemple illustré en figure 3B, les services de protection DPS 31 à 35 font partie de la même fédération, et peuvent donc échanger des messages par l'intermédiaire du répartiteur 36. Par exemple, le premier agent 321 du deuxième service de protection DPS 32 échange des messages avec le répartiteur 36. Un premier agent 361 du répartiteur 36 redirige les messages du premier agent 321 du deuxième service de protection DPS 32 vers le premier agent 311 du premier service de protection DPS 31 et le premier agent 351 du cinquième service de protection DPS 35. Un deuxième agent 362 du répartiteur 36 redirige les messages du premier agent 321 du deuxième service de protection DPS 32 vers le premier agent 331 du troisième service de protection DPS 3 et le premier agent 341 du quatrième service de protection DPS 34. Les premier 361 et deuxième 362 agents du répartiteur 36 peuvent communiquer entre eux.
Selon l'exemple illustré en figure 3C, les premier et cinquième services de protection DPS 31 et 35 font partie d'une première fédération, utilisant un premier répartiteur 37, et les deuxième, troisième et quatrième services de protection DPS 32, 33, 34 font partie d'une deuxième fédération, utilisant un deuxième répartiteur 72. Par exemple, le premier agent 321 du deuxième service de protection DPS 32 échange des messages avec le répartiteur 36. Un premier agent 361 du deuxième répartiteur 36 redirige les messages du premier agent 321 du deuxième service de protection DPS 32 vers un premier agent 371 du premier répartiteur 37. Le premier agent 371 du premier répartiteur 37 redirige les messages du premier agent 321 du deuxième service de protection DPS 32 vers le premier agent 311 du premier service de protection DPS 31 et le premier agent 351 du cinquième service de protection DPS 35. Un deuxième agent 362 du deuxième répartiteur 36 redirige les messages du premier agent 321 du deuxième service de protection DPS 32 vers le premier agent 331 du troisième service de protection DPS 3 et le premier agent 341 du quatrième service de protection DPS 34. Les premier 361 et deuxième 362 agents du répartiteur 36 peuvent communiquer entre eux.
Selon les exemples illustrés en figures 3B et 3C, le deuxième service de protection DPS 32 peut envoyer une seule fois le message au répartiteur 36, qui se charge alors de le retransmettre vers les quatre autres services de protection DPS 31, 33, 34 et 35. Ce mode facilite donc l'application ou l'exploitation d'un traitement réalisé par un service de protection, par exemple pour résoudre une attaque en cours au sein de son domaine de responsabilité (par exemple un réseau qu'il protège), tout en optimisant la volumétrie des échanges entre les services de protection d'une fédération.
5.2.3 Souscription à un service de protection distant
Pour mettre en oeuvre la collaboration entre services de protection, un agent utilisé par un service de protection peut souscrire, selon au moins un mode de réalisation, à au moins un service de partage d'informations proposé par un service de protection distant.
On considère par exemple qu'une session de communication sécurisée est établie entre un agent utilisé par un service de protection, par exemple le premier agent 113 du premier service de protection 112 selon la figure 1, et un agent souhaitant souscrire à au moins un service de partage d'informations proposé par le premier service de protection, par exemple le deuxième agent 123 du deuxième service de protection 122 selon la figure 1. Cette session de communication peut être établie entre les deux agents directement, ou entre les agents via au moins un agent intermédiaire utilisé par au moins un répartiteur au sein d'une fédération.
Une fois la session établie, le deuxième agent 123, souhaitant souscrire à au moins un service de partage d'informations proposé par le premier service de protection 112, envoie au moins un message de souscription au premier agent 113, directement ou via au moins un agent intermédiaire. En d'autres termes, le message de souscription est émis du deuxième agent 123 vers le premier agent 113 ou vers un répartiteur.
Par exemple, le message de souscription est noté SUBSCRIBE() et comprend au moins un attribut, ou paramètre, portant une information de type :
« Service_type » : information relative à un type ou une nature du service de partage d'informations demandé. Par exemple, si aucune valeur n'est indiquée, le premier agent peut interpréter le message de souscription comme une demande de souscription au service DDoS du premier service de protection. A titre d'exemple, les valeurs portées par ce paramètre peuvent être :
i. 0 : tous les services de partage d'informations supportés par le premier service de protection (destinataire du message de souscription) ;
ii. 1 : service DDoS du premier service de protection ;
iii.2 : service de détection de virus du premier service de protection ;
iv.3 : service SPAM du premier service de protection ; v. 4 : service SPIT du premier service de protection ;
vi. etc.
On note qu'un même message de souscription peut être utilisé pour indiquer plusieurs types de service. En variante, des messages de souscription dédiés peuvent être envoyés par service.
« Verbose_Mode » : un niveau d'alerte associé au deuxième agent. En d'autres termes, ce paramètre indique le niveau de granularité des notifications que le deuxième agent, souhaitant souscrire à au moins un service de partage d'informations proposé par le premier service de protection, souhaite recevoir. A titre d'exemple, les valeurs portées par ce paramètre peuvent être :
i. 0 : seules les alertes relatives aux attaques critiques sont envoyées. Par exemple, une attaque est dite critique si la volumétrie du trafic relatif à cette attaque dépasse un certain seuil, ou si elle implique un certain nombre de machines, ou si elle dure plus de X minutes, etc. Cette valeur peut être utilisée par défaut.
ii. 1 : seules les alertes qui correspondent aux filtres indiqués par l'un des agents sont envoyées. Un filtre peut être défini par un ou plusieurs attributs tels que :
+ protocole : renseigne un protocole spécifique tel qu'UDP, TCP, NTP, DNS, etc. ;
+ numéro de port : renseigne un numéro de port spécifique tel que 80, 23, 443, etc. Eventuellement, une plage de numéros de port peut être spécifiée (par ex. 80-8080) ;
+ taille des paquets caractéristiques de l'attaque ;
+ etc.
N_DIA : une information de redirection vers un autre agent utilisé par le deuxième service de protection. Par exemple, ce paramètre précise si le ou les messages de souscription doivent être envoyés vers un autre agent utilisé par le même service de protection (cas de redirection). Dans ce cas, au moins une adresse IP de cet agent peut être fournie ;
une durée de validité : ce paramètre associe une durée de validité à cette souscription. Par exemple, l'absence de ce paramètre ou l'utilisation de la valeur (-1) indique que la souscription a une durée infinie ;
etc.
Les figures 4 et 5 illustrent les principales étapes mises en oeuvre par les premier et deuxième agents, selon au moins un mode de réalisation. Plus précisément, la figure 4 illustre les étapes mises en œuvre par le premier agent 113 utilisé par un premier service de protection 112 et la figure 5 illustre les étapes mises en œuvre par le deuxième agent 123, souhaitant souscrire à au moins un service de partage d'informations proposé par le premier service de protection 112.
Une fois la session établie avec succès avec le premier agent, le deuxième agent 123 envoie un ou plusieurs messages de souscription en positionnant les attributs précités (étape référencée 51 sur la figure 5, similaire à l'étape 212 de la figure 2). Un identifiant peut notamment être associé à la demande de souscription. L'identifiant de souscription peut être associé à un état « demande en cours » (50) dans une base de données de souscription, par exemple la base 24 selon la figure 2.
A réception d'un message de souscription par le premier agent 113 (étape référencée 41 sur la figure 4, similaire à l'étape 213 de la figure 2), celui-ci peut procéder aux vérifications de sécurité (42) pour s'assurer que le deuxième agent 123 est autorisé à souscrire à au moins un service de partage d'informations proposé par le premier service de protection. On note que la politique de souscription à un service de partage d'informations peut avoir été préalablement définie (40).
En cas d'échec des contrôles de sécurité (43), le message de souscription est ignoré par le premier agent 113.
En cas de succès des contrôles de sécurité (44), le premier agent 113 extrait les informations incluses dans le message de souscription pour identifier l'agent émetteur du message de souscription (i.e., le deuxième agent 123), et, par exemple, identifier le service de protection pour lequel il est utilisé (i.e., le deuxième service de protection 122), déterminer le type de service de partage d'informations demandé (i.e., la valeur du paramètre « Service_Type »), déterminer la nature des notifications (i.e., la valeur du paramètre « Verbose_Mode »), déterminer la durée de validité de la souscription, etc.
Ces informations sont ensuite sauvegardées dans une base de données de souscription, par exemple la base 24 selon la figure 2, par exemple avec l'identifiant de souscription.
Le premier agent vérifie également si le message de souscription concerne une nouvelle souscription (45).
Si le message de souscription concerne une nouvelle souscription, provenant par exemple d'un agent utilisé par un service de protection distinct, un nouvel identifiant de souscription est crée (46) et enregistré dans la base de données de souscription.
Si le message de souscription concerne une souscription existante, par exemple un deuxième message de souscription provenant du deuxième agent 123 pour apporter des informations complémentaires, la base de données de souscription est mise à jour (47).
Le premier agent 113 peut ensuite répondre à l'agent ayant émis le ou les messages de souscription.
Par exemple, le premier agent 113 envoie un message d'acceptation ACK pour confirmer la souscription. Le premier agent 113 peut alternativement envoyer un message d'erreur si, par exemple, le service de partage d'informations souhaité par le deuxième agent 123 n'est pas supporté par le premier service de protection 112 ou si le premier agent 113 est surchargé, etc.
La réception (52) du message d'acceptation ACK par l'agent ayant émis le ou les messages de souscription indique que la souscription s'est déroulée avec succès.
Eventuellement, le deuxième agent 123 peut vérifier (53) si le message d'acceptation ACK reçu du premier agent 113 correspond bien à la demande de souscription émise par le deuxième agent 123, en consultant la base de données de souscription 24.
Si la confirmation ne correspond pas à la souscription (54), le message d'acceptation ACK est ignoré.
Si la confirmation correspond à la souscription (55), la souscription s'est déroulée avec succès, et l'identifiant de souscription est associé à un état « confirmé » dans la base de données de souscription 24.
Le deuxième agent 123 reste ensuite en attente (56) d'informations en provenance du premier agent 113, notamment au cas où une attaque serait identifiée par le premier agent 113.
Selon un mode de réalisation particulier, afin de maintenir la souscription active, le deuxième agent 123 envoie un nouveau message de souscription avant l'expiration de la durée de validité de la souscription définie dans le message de souscription. Si aucun message n'est envoyé avant l'expiration de cette durée de validité, le premier agent 113 peut supprimer la souscription correspondante de la base de données de souscription 24.
Les étapes présentées ci-dessus peuvent également être mises en oeuvre en inversant le sens des messages si le premier agent 113 souhaite souscrire à au moins un service de partage d'informations proposé par le deuxième service de protection 122. Dans ce cas, c'est le premier agent 113 qui envoie au moins un message de souscription au deuxième agent 123.
Deux agents utilisés par des services de protection distincts peuvent également s'échanger mutuellement des messages de souscription « SUBSCRIBE() ».
5.2.4 Utilisation du service de protection distant On se place à nouveau dans le cas décrit précédemment en relation avec les figures 4 et 5 selon lequel le deuxième agent 123 envoie un ou plusieurs messages de souscription au premier agent 113.
Quand le premier agent 113 du premier service de protection 112 identifie une attaque qui correspond aux règles indiquées par le deuxième agent 123 dans le message de souscription et conformes à des politiques locales, le premier agent 113 envoie un ou plusieurs messages de notification au deuxième agent 123 pour l'alerter de cette attaque, directement ou via au moins un agent intermédiaire utilisé par au moins un répartiteur.
Par exemple, comme illustré en figure 6, le premier service de protection 112 détecte une attaque sur au moins une ressource du premier réseau 111 qu'il protège, en provenance des sources SI 141, S2 142, ..., Sk 14k, connectées au premier réseau 111 par l'intermédiaire du réseau Internet 13 via de fournisseurs d'accès AP #1 151 et AP #m 15m.
Sur détection de cette attaque DDoS à grande échelle, le premier agent 113 du premier service de protection 112 envoie un message de notification (« NOTIFY() ») vers le deuxième agent 123 du deuxième service de protection 122, pour que celui-ci soit informé de l'attaque en cours et puisse engager des actions permettant d'éviter, ou de réduire, le risque que les ressources du deuxième réseau 121 qu'il protège subissent à leur tour la même attaque que les ressources du premier réseau 111.
Par exemple, le deuxième agent 123 peut prendre les mesures nécessaires pour filtrer le trafic en provenance des sources SI 141, S2 142, ..., Sk 14k.
Ainsi, comme illustré en figure 7, le trafic en provenance des sources SI 141, S2 142, ..., Sk 14k et à destination du deuxième réseau 121 est bloqué en amont, car le deuxième service de protection 122 a déjà été mobilisé pour prendre les mesures adéquates suite à la notification reçue de la part du premier service de protection 112.
Par exemple, le message de notification est noté NOTIFY() et comprend au moins un attribut, ou paramètre, portant une information de type :
SUBSCRIPTIONJD : information relative à la souscription, par le deuxième agent 123, à au moins un service de partage d'informations proposé par le premier service de protection 112, tel qu'un identifiant de souscription défini lors de la souscription ;
ATTACK_ID : identifiant d'attaque, par exemple généré par le premier agent 113 émetteur du message de notification. Selon un mode de réalisation particulier, le même identifiant est utilisé pendant la durée de vie d'une attaque ; ATTACK_DESCRIPTOR : information de description technique de l'attaque. Par exemple, ce champ peut inclure un numéro de protocole, un ou plusieurs numéros de port, les machines impliquées dans l'attaque (par exemple, type ou modèle de machines), la direction du trafic (entrant ou sortant), etc., ou une combinaison de ces informations. A noter que la description technique peut indiquer une ou plusieurs machines concernées par l'attaque (par exemple machine_x,_constructeur_y,_release_z) ;
STATUS : information relative à l'état de l'attaque. A titre d'exemple, ce paramètre peut prendre les valeurs suivantes :
i. 0 : l'attaque est toujours active ;
ii. 1 : l'attaque a été bloquée avec succès ;
iii.etc.
LOCAL_MITIGATION : information indiquant si une ou plusieurs actions de mitigation sont mises en oeuvre localement par le premier service de protection. Aussi, ce champ porte une description technique des actions de mitigation mises en oeuvre par le service de protection de l'agent émetteur du message de notification. Selon un mode de réalisation particulier, ces informations relatives aux actions de mitigation sont partagées à titre informel, et l'agent récepteur du message de notification peut les ignorer. Les actions de mitigation peuvent être génériques (par exemple configuration YANG) ou spécifiques à un constructeur (par exemple fichier de configuration spécifique à « machine_x,_constructeur_y,_release_z ») ;
SOS : demande d'assistance pour traiter l'attaque. A titre d'exemple, ce champ est positionné à « VRAI » pour demander à un service de protection distant de l'assistance pour mettre fin à l'attaque en cours ;
etc.
Les messages de notification peuvent être de différentes natures (par exemple STATUS, LOCAL_MITIGATION, SOS, etc.).
Par exemple, le premier agent 113 peut envoyer au deuxième agent 123, directement ou via au moins un agent intermédiaire utilisé par au moins un répartiteur, un ou plusieurs messages de notification décrivant les caractéristiques d'une attaque : NOTIFY(ATTACKJD), NOTIFY(ATTACK_ID, ATTACK_DESCRIPTOR) ou NOTIFY(ATTACK_ID, STATUS).
Selon un autre exemple, le premier agent 113 peut envoyer au deuxième agent 123, directement ou via au moins un agent intermédiaire utilisé par au moins un répartiteur, un ou plusieurs messages de notification décrivant une action de mitigation locale, telle qu'activée par le premier service de protection 112 du premier agent 113 émetteur du message de notification : NOTIFY (ATTACKJD, LOCAL_MITIGATION).
Selon encore un autre exemple, le premier agent 113 peut envoyer au deuxième agent 123, directement ou via au moins un agent intermédiaire utilisé par au moins un répartiteur, un ou plusieurs messages de notification demandant de l'assistance pour la mitigation de l'attaque : NOTIFY (ATTACKJD, SOS).
On note que la description d'une attaque peut varier pendant la durée de vie d'une telle attaque. Par exemple, de nouvelles sources peuvent être impliquées, d'autres protocoles peuvent être exploités, etc. Il est donc souhaitable de pouvoir identifier l'attaque, par exemple au moyen de l'attribut persistant ATTACKJD, pour suivre son évolution.
Ainsi, plusieurs messages de notification peuvent être envoyés pour notifier les agents ayant souscrit au service de partage d'informations proposé par le premier service de protection, des mises à jour de la description de l'attaque. Par exemple, des messages NOTIFY (ATTACKJD=ID1, ATTACK_DESCRIPTOR= DESC #1), NOTIFY (ATTACK_ID=ID1, ATTACKJD ESC R IPTOR= DESC #2), et NOTIFY (ATTACK_ID=ID1, ATT AC K_D ESCR I PTO R= DESC #s) sont successivement transmis du premier agent 113 vers le deuxième agent 123.
Les agents ayant souscrit au service de partage d'informations proposé par le premier service de protection peuvent ainsi mettre à jour leurs filtres en fonction des mises à jour de l'attaque.
Par ailleurs, selon au moins un mode de réalisation, l'attribut ATTACK_DESCRIPTOR de description de l'attaque peut également être utilisé pour corréler différents messages de notification reçus depuis différents services de protection.
Par exemple, si le deuxième agent 123 du deuxième service de protection 122 reçoit d'une part un message de notification NOTIFY (ATTACK_ID=ID1, ATT AC K_D ESC RI PTO R= DESC #m) en provenance du premier agent 113 du premier service de protection 112, et d'autre part un message de notification NOTIFY (ATTACK_ID=ID2, ATTACK_DESCRIPTOR= DESC #m) en provenance d'un agent d'un autre service de protection, le deuxième agent 123 peut associer ces deux notifications, ayant des identifiants distincts, à une même attaque grâce aux informations incluses dans le champ ATTACK_DESCRIPTOR. Il est ainsi possible de corréler les informations reçues de différents agents, ce qui permet notamment de confirmer la réalité ou l'étendue d'une attaque.
On présente ci-après des exemples de messages de notification pouvant être envoyés successivement pour caractériser les différentes phases d'une attaque : - NOTIFY(ATTACK_ID=IDl, ATTACK_DESCRIPTOR, STATUS=0) est envoyé pour notifier une attaque en cours ;
NOTIFY(ATTACK_ID=IDl, SOS=l) est envoyé pour demander de l'assistance aux autres services de protection ;
NOTIFY(ATTACK_ID=IDl, STATUS=1) est envoyé pour notifier qu'une attaque a été bloquée avec succès ;
NOTIFY(ATTACK_ID=IDl, LOCAL_MITIGATION) est envoyé pour informer les autres services de protection qu'une action de mitigation est mise en oeuvre localement (i.e., par le service de protection qui utilise l'agent émettant le message de notification).
Différentes informations peuvent éventuellement être agrégées dans un même message de notification, par exemple :
- NOTIFY(ATTACK_ID=ID2, ATTACK_DESCRIPTOR, LOCAL_MITIGATION, STATUS=1) est envoyé pour notifier qu'une attaque a été bloquée avec succès (STATUS=1). Le message indique aussi qu'une action de mitigation est mise en oeuvre localement (LOCAL_MITIGATION) ;
- NOTIFY(ATTACK_ID=ID2, ATTACK_DESCRIPTOR, STATUS=0, SOS=l) est envoyé pour demander de l'assistance aux autres services de protection (SOS=l) pour traiter une attaque en cours (STATUS=0).
On présente désormais, en relation avec les figures 8 et 9, les principales étapes mises en oeuvre par les premier et deuxième agents pour la phase de notification, selon au moins un mode de réalisation. Plus précisément, la figure 8 illustre les étapes mises en oeuvre par le premier agent 113 utilisé par un premier service de protection 112, pour identifier une attaque et en informer le deuxième agent 123, et la figure 9 illustre les étapes mises en oeuvre par le deuxième agent 123, recevant l'information d'attaque et déterminant une action à effectuer.
Comme illustré en figure 8, le premier agent 113 peut identifier une attaque (étape référencée 81 sur la figure 8, similaire à l'étape 221 de la figure 2). Par exemple, l'attaque peut être détectée par le premier agent 113, par un autre agent utilisé par le premier service de protection 112, ou être détectée par un nœud du réseau 111 protégé par le premier service de protection 112.
On note que la politique d'identification des attaques pour lesquelles au moins un deuxième agent (par exemple le deuxième agent 123) a souscrit à au moins un service de partage d'informations du premier service de protection peut avoir été préalablement définie (80). Dans ce cas, au cours de l'étape 81, le premier agent 113 identifie une attaque correspondant à cette politique. Le premier agent 113 peut alors identifier (82) au moins un service de protection, et par exemple tous les services de protection, utilisant un agent ayant souscrit à au moins un service de partage d'informations du premier service de protection.
Pour ce faire, le premier agent 113 peut consulter la base de données de souscription 24.
Le premier agent 113 peut alors envoyer des messages de notification aux agents ayant souscrit à au moins un service de partage d'informations proposé par le premier service de protection (étape référencée 83 sur la figure 8, similaire à l'étape 222 de la figure 2).
Selon un mode de réalisation particulier, le premier agent 113 peut envoyer (84) plusieurs messages de notification, notamment lorsque l'attaque est modifiée, pour informer les agents ayant souscrit à au moins un service de partage d'informations proposé par le premier service de protection et leur permettre de mettre à jour leurs filtres. Un délai est observé entre deux notifications consécutives envoyées vers un même agent distant.
A réception d'un message de notification (étape référencée 91 sur la figure 9, similaire à l'étape 223 de la figure 2), un agent d'un service de protection ayant souscrit à au moins un service de partage d'informations proposé par le premier service de protection, par exemple le deuxième agent 123, procède aux vérifications de sécurité (92) pour s'assurer que le premier agent 113 est autorisé à envoyer des messages de notification.
Pour ce faire, le deuxième agent 123 peut consulter la base de données de souscription 24.
En cas d'échec des contrôles de sécurité (93), le message de notification est ignoré par le deuxième agent 123.
En cas de succès des contrôles de sécurité (94), le deuxième agent 123 extrait les informations incluses dans le message pour identifier l'agent émetteur du message de notification (i.e., le premier agent 113), et, par exemple, identifier le service de protection auquel il appartient (i.e., le premier service de protection 112), déterminer la nature des notifications (i.e., SOS, STATUS, LOCAL_MITIGATION, etc.). A partir de la ou des informations extraites, et notamment de la nature des notifications, le deuxième agent 123 peut déterminer au moins une action à effectuer.
Par exemple, si le message de notification informe le deuxième agent 123 qu'une attaque est en cours, alors les informations caractéristiques de l'attaque sont extraites du message de mitigation (95) et relayées vers une entité en charge de la mitigation (« mitigator ») du deuxième service de protection 112 qui met en oeuvre le deuxième agent 123, pour qu'il prenne les mesures de protection ad hoc afin d'anticiper l'attaque (96). Selon un mode de réalisation particulier, ces actions peuvent s'inspirer de celles indiquées dans le message de notification si le champ LOCAL_MITIGATION a été renseigné.
Si le message de notification inclut une demande d'assistance pour traiter une attaque en cours, le deuxième agent 123 peut vérifier si des actions locales au deuxième service de protection peuvent être engagées (97). Le deuxième agent 123 peut envoyer un message de partage d'actions « SHARE_ACTION() » au premier agent 113, directement ou via au moins un agent intermédiaire utilisé par au moins un répartiteur, pour partager un plan de mitigation avec le premier service de protection et mettre en oeuvre localement des actions de mitigation (98). Par exemple, le deuxième agent 123 peut envoyer au premier agent 113, émetteur du message de notification, au moins un message de partage d'actions SHARE_ACTION(ATTACK_ID, LOCAL_MITIGATION). Le plan de mitigation partagé à l'aide du message SHARE_ACTION() n'est pas nécessairement mis en oeuvre par le service de protection émetteur, mais peut être rapatrié depuis une base de données capitalisant des BCP (en anglais « Best Current Practices ») ou des expériences passées pour des attaques similaires.
Le plan de mitigation peut correspondre à des actions de filtrage, la mise à disposition de ressources pour la redirection des flux, etc.
Un exemple de plan d'action de mitigation simplifié est présenté ci-dessous :
[Table 1]
On note que le plan de mitigation simplifié présenté dans la Table 1 ne décrit pas de cible de l'attaque, mais caractérise uniquement la source du trafic suspect et qui est à l'origine de l'attaque : le trafic émis par une telle source (1.2.3.0/24) est donc filtré dans cet exemple. En particulier, dans le mode de transmission « fédération », mettant en oeuvre au moins un répartiteur, le message de partage d'action SHARE_ACTION peut être diffusé vers le premier service de protection ayant sollicité une demande d'assistance, ainsi que vers d'autres services de protection faisant partie de la même fédération.
Par exemple, le message de partage d'action SHARE_ACTION(ATTACK_ID=IDl) est transmis du deuxième agent 123 vers un répartiteur FD, puis du répartiteur FD vers le premier agent 113 et vers au moins un autre agent d'un service de protection distinct faisant partie de la même fédération.
Quelque soit le mode de transmission, le premier agent 113 peut donc rester en attente d'un message de partage SHARE_ACTION (étape référencée 85 sur la figure 8). A réception d'un tel message, le premier agent 113 peut extraire les informations véhiculées par ce message (86) pour partager un plan de mitigation avec le deuxième service de protection et mettre en oeuvre localement des actions de mitigation (87).
On note que les étapes présentées ci-dessus en relation avec les figures 8 et 9 peuvent également être mises en oeuvre en inversant le sens des messages si le premier agent 113 a souscrit à au moins un service de partage d'informations proposé par le deuxième service de protection 122. Dans ce cas, c'est le deuxième agent 123 qui envoie au moins un message de notification au premier agent 113.
5.2.5 Information des fournisseurs d'accès
On présente ci-après un mode de réalisation particulier, mis en oeuvre par un agent d'un service de protection tel que décrit précédemment, permettant d'identifier au moins un fournisseur d'accès responsable d'au moins une ressource impliquée dans la propagation du trafic caractéristique de l'attaque.
En effet, l'identification d'un tel fournisseur d'accès permet de lui transmettre une demande de filtrage du trafic caractéristique de l'attaque.
De cette façon, les services de protection peuvent collaborer avec les fournisseurs d'accès pour bloquer en amont des machines impliquées dans une attaque, permettant ainsi de limiter la propagation de l'attaque.
En effet, l'activation de filtres locaux à chaque service de protection ne permet pas de bloquer systématiquement une attaque à l'échelle de l'Internet. De plus, et étant donné le nombre important de machines sources qui peuvent être impliquées dans une attaque, un nombre important de filtres peut être requis. Or l'application de ces filtres a une incidence sur les performances des routeurs et pare-feu. Les agents des services de protection tels que décrits précédemment peuvent collaborer avec les fournisseurs d'accès pour bloquer en amont les machines injectant du trafic caractéristique d'une attaque dès que possible de façon à limiter la propagation du trafic caractéristique de l'attaque. Selon un mode de réalisation particulier, ces fournisseurs d'accès pourront ensuite empêcher ces machines de se connecter au(x) réseau(x) d'accès, en refusant de leur allouer des adresses/préfixes IP par exemple.
On suppose par exemple que les fournisseurs d'accès disposent d'une interface de programmation (API) pour offrir à des tiers des services à valeur ajoutée, tels que le filtrage des adresses.
Par exemple, un agent d'un service de protection tel que décrit précédemment détermine l'identité du fournisseur d'accès responsable d'une ressource IP impliquée dans une attaque. Pour ce faire, l'agent d'un service de protection (par exemple, celui ayant identifié une attaque) interroge par exemple la base de données maintenue, par exemple, par le registre régional RIPE (Réseaux IP Européens).
Un exemple de requête utilisant les ressources de la base de données RIPE pour récupérer l'identité du fournisseur d'accès qui gère la ressource IP « 80.12.102.157 » est donné ci-après :
Comme indiqué ci-dessus, ce mode de réalisation suppose que les fournisseurs d'accès exposent une interface de programmation (API) pour offrir à des tiers des services à valeur ajoutée, par exemple dans un ou plusieurs serveurs de validation hébergés par ces fournisseurs d'accès.
Si les fournisseurs d'accès exposent une telle API, et si la base de données RIPE est modifiée pour renseigner le/les serveur(s) de validation, la réponse à cette requête indique que la ressource IP « 80.12.102.157 » est allouée, selon cet exemple, au fournisseur d'accès « Orange S.A. », et que le ou les serveur(s) de validation sont localisés par les adresses « 80.12.102.15 » et « 80.12.102.16 ».
Un exemple de réponse à la requête est donné ci-après :
La réponse précise en particulier que le/les serveurs de validation pour cette plage d'adresses « 80.12.102.157 » est joignable avec deux adresses : « 80.12.102.15 » et « 80.12.102.16 ».
Une fois cette adresse récupérée, l'agent du service de protection peut envoyer une demande de filtrage au fournisseur d'accès, par exemple sous la forme d'un message ACTION_REQUEST().
Sur réception du message ACTION_REQUEST(), le fournisseur d'accès procède à des vérifications, permettant notamment de vérifier que l'agent ayant émis la demande de filtrage est une entité de confiance.
En cas de succès des vérifications, le fournisseur d'accès peut envoyer un message ACTION_REPLY à l'agent. Le service de protection auquel appartient l'agent peut alors activer certains filtres pour bloquer le trafic provenant de la machine malveillante. On note que ce filtrage peut être mis en oeuvre immédiatement ou après une phase d'observation.
Les figures 10 et 11 illustrent la mise en oeuvre d'une telle solution permettant à un fournisseur d'accès de filtrer le trafic caractéristique d'une attaque.
Comme illustré en figure 10, on considère le premier service de protection 112 protégeant le premier réseau 111, connecté au réseau Internet 13, et les sources SI 141 à Sk 14k également connectées au réseau Internet 13 par l'intermédiaire des fournisseurs d'accès AP#1 151 à AP#n 15n. Si l'on considère que tous les fournisseurs d'accès AP#1 151 à AP#n 15n mettent en place la solution décrite ci-dessus, des actions de filtrage peuvent être réparties entre tous les fournisseurs d'accès, pour bloquer le trafic caractéristique d'une attaque en amont du réseau Internet 13.
Comme illustré en figure 11, cette solution présente un intérêt même lorsque tous les fournisseurs d'accès ne mettent pas en place la solution décrite ci-dessus. En effet, à partir du moment où certains fournisseurs d'accès mettent en place la solution décrite ci-dessus, par exemple les fournisseurs d'accès AP#1 151 et AP#n 15n, les services de protection, comme le premier service de protection 122, ont une liste limitée de filtres à gérer.
5.3 Structures
On présente finalement, en relation avec la figure 12, la structure simplifiée d'un agent selon au moins un mode de réalisation décrit ci-dessus. Un tel agent comprend une mémoire 101 comprenant une mémoire tampon, une unité de traitement 102, équipée par exemple d'une machine de calcul programmable ou d'une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d'ordinateur 103, mettant en oeuvre des étapes du procédé de collaboration ou de demande de collaboration selon au moins un mode de réalisation de l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur 103 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 102.
Le processeur de l'unité de traitement 102 met en oeuvre des étapes du procédé de collaboration ou de demande de collaboration décrit précédemment, selon les instructions du programme d'ordinateur 103, pour :
identifier une attaque sur au moins une ressource gérée par un domaine protégé par un service de protection local, et transmettre, à au moins un agent utilisé par un service de protection distant, au moins une information relative à l'attaque identifiée, et/ou
recevoir au moins une information relative à une attaque identifiée par un agent utilisé par un service de protection distant, et déterminer au moins une action à effectuer, à partir de la ou des informations relatives à ladite attaque.
5.4 Variantes
La solution de collaboration entre services de protection présentée ci-dessus peut être mise en oeuvre dans différents contextes, par exemple :
le service de protection est géré par l'administrateur de l'infrastructure réseau à protéger ; le service de protection est géré par une autre entité que l'administrateur de l'infrastructure réseau à protéger ;
le service de protection est activé au sein de l'infrastructure réseau à protéger ;
le service de protection est activé en dehors de l'infrastructure réseau à protéger (typiquement, fournisseur d'accès, opérateur de transit, opérateur de service, fournisseur de services « cloud ») ;
l'infrastructure réseau à protéger peut être un réseau d'opérateur, un réseau d'entreprise, un réseau de client résidentiel, une flotte de mobiles 5G, etc. ;
l'infrastructure réseau à protéger peut être utilisée pour fournir un ensemble de services, comprenant par exemple un service de connectivité (service de transfert de paquets, typiquement), un service de réseau privé virtuel (« Virtual Private Network » (VPN) en anglais) ou d'autres services à valeur ajoutée, tels que des services de téléphonie, de diffusion de programmes télévisés (service IPTV), de télémétrie loT (« Internet of Things »), etc. ;
plusieurs infrastructures réseaux peuvent solliciter le même service de protection ;
une infrastructure réseau peut invoquer les services d'un ou plusieurs services de protection ; ces services de protection peuvent protéger des attaques de natures différentes ou être associés à des services distincts, par exemple selon les profils de trafic caractéristiques des différents services supportés par l'infrastructure réseau ;
les sources d'une attaque peuvent être aussi des ressources hébergées au sein de l'infrastructure réseau à protéger, ce qui peut être le cas des attaques de type « Man-in-the- Middle » (MITM), par exemple ;
etc.
En particulier, un opérateur réseau qui applique des filtres (ou liste de contrôle d'accès « ACL »), typiquement sur des routeurs et pare-feu, peut également être considéré comme un fournisseur de service de protection dans le cadre de l'invention.
Selon au moins un mode de réalisation, la solution de collaboration entre services de protection proposée permet :
de lancer rapidement des actions pour la mitigation d'attaques de façon à limiter la propagation de ces attaques et par conséquent, d'en atténuer l'amplitude, et/ou
de mobiliser l'ensemble des acteurs impliqués dans la mitigation de telles attaques : les services de protection, mais également les fournisseurs de services responsables des réseaux auxquels la source à l'origine de l'attaque s'est connectée, et/ou
de communiquer à l'ensemble des services de protection du réseau de communication l'ensemble des informations caractéristiques d'une attaque dès que celle-ci est détectée. La propagation de telles informations permet en effet une mise en alerte rapide (voire instantanée) des services de protection du réseau de communication afin de faciliter une gestion globale et cohérente de l'attaque et de sa mitigation tout en réduisant le risque et la gravité des dommages que pourrait infliger une telle attaque, et/ou
de mettre en place des politiques de filtrage coordonnées et globalement cohérentes. De telles politiques permettent d'installer des filtres aux endroits appropriés et ainsi d'optimiser la distribution des listes de contrôle d'accès sans pénaliser les performances des systèmes (routeurs, par exemple), sur lesquels ces filtres sont installés.

Claims

REVENDICATIONS
1. Procédé de collaboration entre services de protection associés à un ou plusieurs domaines, caractérisé en ce qu'il comprend :
l'identification (221), par un premier agent utilisé par un premier service de protection, d'une attaque sur au moins une ressource gérée par un domaine protégé par ledit premier service de protection, et
la transmission (222), à au moins un deuxième agent utilisé par un deuxième service de protection ayant souscrit auprès du premier service de protection à au moins un service de partage d'informations proposé par le premier service de protection, d'au moins une dite information relative à ladite attaque identifiée par le premier agent.
2. Procédé selon la revendication 1, caractérisé en ce que ladite transmission (222) met en oeuvre l'émission d'au moins un message de notification, à destination dudit au moins un deuxième agent ou d'un agent intermédiaire en charge de la redirection des messages.
3. Procédé selon l’une quelconque des revendications 1 et 2, caractérisé en ce qu'il comprend une étape préalable de souscription, mettant en oeuvre :
l'établissement (211) d'une session entre ledit premier agent et ledit au moins un deuxième agent,
la réception (213), par ledit premier agent, d'au moins un message de souscription audit au moins un service de partage d'informations proposé par ledit premier service de protection, et l'extraction et le stockage (214) des informations véhiculées dans ledit au moins un message de souscription.
4. Procédé de demande de collaboration entre services de protection associés à un ou plusieurs domaines, caractérisé en ce que, un premier agent utilisé par un premier service de protection ayant identifié une attaque sur au moins une ressource gérée par un domaine protégé par ledit premier service de protection, ledit procédé comprend :
la réception (223), par au moins un deuxième agent utilisé par un deuxième service de protection ayant souscrit auprès du premier service de protection à au moins un service de partage d'informations proposé par le premier service de protection, d'au moins une information relative à ladite attaque identifiée par ledit premier agent, et
la détermination (224) d'au moins une action à effectuer, à partir de la ou des informations relatives à ladite attaque.
5. Procédé selon la revendication 4, caractérisé en ce que ladite réception (223) met en oeuvre la réception d'au moins un message de notification, transmis par ledit premier agent ou par un agent intermédiaire en charge de la redirection des messages.
6. Procédé selon la revendication 5, caractérisé en ce que ladite réception (223) met également en oeuvre la réception d'au moins un message de notification transmis par un agent utilisé par un service de protection distinct du premier service de protection.
7. Procédé selon l’une quelconque des revendications 4 à 6, caractérisé en ce que ladite au moins une action comprend la transmission, à une entité en charge de la mitigation du deuxième service de protection, de la ou des informations relatives à ladite attaque.
8. Procédé selon l’une quelconque des revendications 4 à 7, caractérisé en ce que ladite au moins une action comprend la transmission audit premier agent, ou à un agent intermédiaire en charge de la redirection des messages, d'un message de partage d'actions avec le premier service de protection.
9. Procédé selon l’une quelconque des revendications 4 à 8, caractérisé en ce qu'il comprend une étape préalable de souscription mettant en oeuvre :
l'établissement (211) d'une session entre ledit premier agent et ledit au moins un deuxième agent, et
la transmission (212), par ledit au moins un deuxième agent, d'un message de souscription à au moins un service de partage d'informations proposé par ledit premier service de protection.
10. Procédé selon l'une quelconque des revendications 2 ou 5, caractérisé en ce que ledit au moins un message de notification comprend au moins une information appartenant au groupe comprenant :
une information relative à la souscription, par ledit au moins un deuxième agent, audit au moins un service de partage d'informations proposé par ledit premier service de protection ; un identifiant de l'attaque ;
une information de description de l'attaque ;
une information relative à l'état de l'attaque ;
une information indiquant si une action de mitigation est mise en oeuvre par le premier service de protection ;
une information indiquant une action de mitigation mise en oeuvre par le premier service de protection ;
une demande d'assistance pour traiter l'attaque.
11. Procédé selon l'une quelconque des revendications 3 ou 9, caractérisé en ce que ledit au moins un message de souscription comprend au moins une information appartenant au groupe comprenant :
une information relative à un type de service de partage d'informations demandé ; un niveau d'alerte associé audit au moins un deuxième agent ;
une information de redirection vers un autre agent utilisé par le deuxième service de protection ;
une durée de validité.
12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce qu'il comprend en outre :
l'identification d'au moins un fournisseur d'accès responsable d'au moins une ressource impliquée dans la propagation du trafic caractéristique de ladite attaque, et
la transmission audit au moins un fournisseur d'accès d'une demande de filtrage du trafic caractéristique de ladite attaque entrant et/ou sortant de ladite au moins une ressource.
13. Agent utilisé par un premier service de protection, comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour :
identifier (221) une attaque sur au moins une ressource gérée par un domaine protégé par ledit premier service de protection,
transmettre (222), à au moins un deuxième agent utilisé par un deuxième service de protection ayant souscrit auprès du premier service de protection à au moins un service de partage d'informations proposé par le premier service de protection, au moins une information relative à ladite attaque identifiée par le premier agent.
14. Agent utilisé par un deuxième service de protection ayant souscrit auprès d'un premier service de protection à au moins un service de partage d'informations proposé par le premier service de protection, ledit agent comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour :
recevoir (223) au moins une information relative à une attaque identifiée par un premier agent utilisé par le premier service de protection, ladite attaque portant sur au moins une ressource gérée par un domaine protégé par le premier service de protection,
déterminer (224) au moins une action à effectuer, à partir de la ou des informations relatives à ladite attaque.
15. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l’une quelconque des revendications 1 à 12 lorsque ce programme est exécuté par un processeur.
EP19801930.9A 2018-09-28 2019-09-26 Procédé de collaboration et de demande de collaboration entre services de protection associés à au moins un domaine, agents et programme d'ordinateur correspondants Pending EP3857847A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1871107A FR3086821A1 (fr) 2018-09-28 2018-09-28 Procedes de collaboration et de demande de collaboration entre services de protection associes a au moins un domaine, agents et programme d’ordinateur correspondants.
PCT/FR2019/052280 WO2020065233A1 (fr) 2018-09-28 2019-09-26 Procédé de collaboration et de demande de collaboration entre services de protection associés à au moins un domaine, agents et programme d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP3857847A1 true EP3857847A1 (fr) 2021-08-04

Family

ID=66690431

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19801930.9A Pending EP3857847A1 (fr) 2018-09-28 2019-09-26 Procédé de collaboration et de demande de collaboration entre services de protection associés à au moins un domaine, agents et programme d'ordinateur correspondants

Country Status (5)

Country Link
US (1) US11985161B2 (fr)
EP (1) EP3857847A1 (fr)
CN (1) CN113056896B (fr)
FR (1) FR3086821A1 (fr)
WO (1) WO2020065233A1 (fr)

Family Cites Families (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7269850B2 (en) * 2002-12-31 2007-09-11 Intel Corporation Systems and methods for detecting and tracing denial of service attacks
CN100370757C (zh) * 2004-07-09 2008-02-20 国际商业机器公司 识别网络内分布式拒绝服务攻击和防御攻击的方法和系统
CN1949770A (zh) * 2005-10-14 2007-04-18 华为技术有限公司 一种推送信息提供方法及推送代理装置
US11120406B2 (en) * 2006-11-16 2021-09-14 Comcast Cable Communications, Llc Process for abuse mitigation
US9569587B2 (en) * 2006-12-29 2017-02-14 Kip Prod Pi Lp Multi-services application gateway and system employing the same
CN101184088B (zh) * 2007-12-14 2010-12-01 浙江工业大学 一种多点联动的局域网防火墙协同方法
US8627493B1 (en) * 2008-01-08 2014-01-07 Juniper Networks, Inc. Single sign-on for network applications
US10492102B2 (en) * 2009-01-28 2019-11-26 Headwater Research Llc Intermediate networking devices
US8856869B1 (en) * 2009-06-22 2014-10-07 NexWavSec Software Inc. Enforcement of same origin policy for sensitive data
US8966622B2 (en) * 2010-12-29 2015-02-24 Amazon Technologies, Inc. Techniques for protecting against denial of service attacks near the source
WO2013184225A1 (fr) * 2012-06-06 2013-12-12 The Trustees Of Columbia University In The City Of New York Système et dispositif de réseautage unifié pour environnements mobiles hétérogènes
US9094445B2 (en) * 2013-03-15 2015-07-28 Centripetal Networks, Inc. Protecting networks from cyber attacks and overloading
CN105493046B (zh) * 2013-09-28 2019-08-13 迈克菲有限公司 面向服务的中介、方法和计算机可读存储介质
CN105519039A (zh) * 2013-09-29 2016-04-20 迈克菲股份有限公司 数据交换层上的威胁情报
CN104639504B (zh) 2013-11-12 2018-09-21 华为技术有限公司 网络协同防御方法、装置和系统
JP6081386B2 (ja) 2014-01-30 2017-02-15 日本電信電話株式会社 情報共有装置、情報共有方法、および、情報共有プログラム
US9350668B2 (en) * 2014-06-03 2016-05-24 The Viki Group, Inc. Systems and methods for IP sharing across wide area networks
CN104378364B (zh) 2014-10-30 2018-02-27 广东电子工业研究院有限公司 一种信息安全管理中心的协同分析方法
US9806961B2 (en) * 2014-12-31 2017-10-31 Motorola Solutions, Inc. Method and apparatus for managing subscriptions for a subscription-notification service
US9787719B2 (en) * 2015-02-26 2017-10-10 Symantec Corporation Trusted third party broker for collection and private sharing of successful computer security practices
US11277383B2 (en) * 2015-11-17 2022-03-15 Zscaler, Inc. Cloud-based intrusion prevention system
US11159486B2 (en) * 2015-11-17 2021-10-26 Zscaler, Inc. Stream scanner for identifying signature matches
JP6533476B2 (ja) 2016-02-15 2019-06-19 日本電信電話株式会社 ＤＤｏＳ攻撃情報共有装置、動作方法及びプログラム
US10104119B2 (en) * 2016-05-11 2018-10-16 Cisco Technology, Inc. Short term certificate management during distributed denial of service attacks
US10728280B2 (en) * 2016-06-29 2020-07-28 Cisco Technology, Inc. Automatic retraining of machine learning models to detect DDoS attacks
US10516672B2 (en) * 2016-08-05 2019-12-24 Oracle International Corporation Service discovery for a multi-tenant identity and data security management cloud service
JP6612197B2 (ja) * 2016-08-22 2019-11-27 日本電信電話株式会社 ＤＤｏＳ連携対処装置、ＤＤｏＳ連携対処方法及びプログラム
CN107800668B (zh) 2016-09-05 2020-09-08 华为技术有限公司 一种分布式拒绝服务攻击防御方法、装置及系统
WO2018126065A1 (fr) * 2016-12-30 2018-07-05 Intel Corporation Stockage et traitement de données décentralisés pour dispositifs iot
JP6679521B2 (ja) 2017-02-16 2020-04-15 日本電信電話株式会社 通信システム及びＤＤｏＳ連携対処方法
US10791138B1 (en) * 2017-03-30 2020-09-29 Fireeye, Inc. Subscription-based malware detection
US10848397B1 (en) * 2017-03-30 2020-11-24 Fireeye, Inc. System and method for enforcing compliance with subscription requirements for cyber-attack detection service
US10721239B2 (en) * 2017-03-31 2020-07-21 Oracle International Corporation Mechanisms for anomaly detection and access management
JP7250703B2 (ja) * 2017-05-18 2023-04-03 パロ アルト ネットワークス，インコーポレイテッド 相関関係駆動型脅威の評価と修復
US10516695B1 (en) * 2017-09-26 2019-12-24 Amazon Technologies, Inc. Distributed denial of service attack mitigation in service provider systems
US11134058B1 (en) * 2017-10-06 2021-09-28 Barracuda Networks, Inc. Network traffic inspection
US11785104B2 (en) * 2017-11-27 2023-10-10 Lacework, Inc. Learning from similar cloud deployments
WO2020101747A1 (fr) * 2018-01-08 2020-05-22 All Purpose Networks, Inc. Système de recouvrement de réseau de courtiers de publication-abonnement
US20210367926A1 (en) * 2018-03-20 2021-11-25 Telefonaktiebolaget Lm Ericsson (Publ) Methods and Apparatus for Operating and Managing a Constrained Device within a Network
US11055417B2 (en) * 2018-04-17 2021-07-06 Oracle International Corporation High granularity application and data security in cloud environments
GB2563497B (en) * 2018-05-18 2019-10-09 Qip Solutions Ltd Data filtering
MX2020012311A (es) * 2018-06-03 2021-03-25 Hoz Diego Jorge David De Metodo y sistema de comunicacion segura por proxificacion de sockets de red.
FR3081573A1 (fr) * 2018-06-29 2019-11-29 Orange Procedes de verification de la validite d'une ressource ip, serveur de controle d'acces, serveur de validation, nœud client, nœud relais et programme d'ordinateur correspondants.
FR3081574A1 (fr) * 2018-06-29 2019-11-29 Orange Procedes de gestion du trafic associe a un domaine client, serveur, nœud client et programme d'ordinateur correspondants.
WO2020036947A1 (fr) * 2018-08-13 2020-02-20 Intel Corporation Techniques dans un noyau de paquet évolué pour un accès restreint à des services d'opérateur local
US11050785B2 (en) * 2018-08-25 2021-06-29 Mcafee, Llc Cooperative mitigation of distributed denial of service attacks originating in local networks
US10531305B1 (en) * 2018-09-27 2020-01-07 Palo Alto Networks, Inc. Service-based security per subscription and/or equipment identifiers in mobile networks
FR3086776A1 (fr) * 2018-09-28 2020-04-03 Orange Procede d'allocation d'un identifiant a un nœud client, procede d'enregistrement d'un identifiant, dispositif, nœud client, serveur et programmes d'ordinateurs correspondants.
FR3086825A1 (fr) * 2018-09-28 2020-04-03 Orange Procedes de protection d'un domaine client contre une attaque informatique, nœud client, serveur et programmes d'ordinateur correspondants.

Also Published As

Publication number Publication date
FR3086821A1 (fr) 2020-04-03
CN113056896B (zh) 2024-01-05
US20210400082A1 (en) 2021-12-23
WO2020065233A1 (fr) 2020-04-02
US11985161B2 (en) 2024-05-14
CN113056896A (zh) 2021-06-29

Similar Documents

Publication Publication Date Title
US20130312054A1 (en) Transport Layer Security Traffic Control Using Service Name Identification
US11895149B2 (en) Selective traffic processing in a distributed cloud computing network
EP3857848B1 (fr) Procédé d'allocation d'un identifiant à un noeud client, procédé d'enregistrement d'un identifiant, dispositif, noeud client, serveur et programmes d'ordinateurs correspondants
FR3072238B1 (fr) Dispositif et procede de transmission de donnees
EP4066461B1 (fr) Procédé de coordination de la mitigation d'une attaque informatique, dispositif et système associés
WO2020183100A1 (fr) Mitigation d'attaques informatiques
WO2020065233A1 (fr) Procédé de collaboration et de demande de collaboration entre services de protection associés à au moins un domaine, agents et programme d'ordinateur correspondants
CN112514350B (zh) 用于核实ip资源的有效性的方法以及相关联的访问控制服务器、验证服务器、客户端节点、中继节点和计算机程序
WO2020002853A1 (fr) Procédés de gestion du trafic associé à un domaine client, serveur, nœud client et programme d'ordinateur correspondants
EP3857849A1 (fr) Procédés de protection d'un domaine client, noeud client, serveur et programmes d'ordinateur correspondants
Jabel et al. A study of SIP trunk security and challenges
Patil et al. VoIP security
WO2023117802A1 (fr) Procédés d'identification d'au moins un serveur de mitigation et de protection d'un domaine client contre une attaque informatique, dispositifs et signal correspondants
EP4128701A1 (fr) Procédé de gestion de communications et dispositifs associés
Miltenburg et al. Preventing Common Attacks on Critical Infrastructure
Wing et al. Voip Security
FR2950767A1 (fr) Procede de communications securisees dans un reseau de telecommunications

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210315

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20231212