WO2024121017A1 - Procédés de détection d'un serveur de résolution de noms de domaine malveillant, équipement, serveur de confiance et programme d'ordinateur correspondants - Google Patents

Procédés de détection d'un serveur de résolution de noms de domaine malveillant, équipement, serveur de confiance et programme d'ordinateur correspondants Download PDF

Info

Publication number
WO2024121017A1
WO2024121017A1 PCT/EP2023/084041 EP2023084041W WO2024121017A1 WO 2024121017 A1 WO2024121017 A1 WO 2024121017A1 EP 2023084041 W EP2023084041 W EP 2023084041W WO 2024121017 A1 WO2024121017 A1 WO 2024121017A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
domain name
resolution
equipment
server
Prior art date
Application number
PCT/EP2023/084041
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2024121017A1 publication Critical patent/WO2024121017A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • 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
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • 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/12—Applying verification of the received information

Definitions

  • TITLE Methods for detecting a malicious domain name resolution server, equipment, trusted server and corresponding computer program.
  • the field of the invention is that of communications within a communications network, for example a computer network implementing the IP protocol.
  • the invention concerns name resolution services, for example DNS (in English “Domain Name System”), and proposes a solution helping to detect the presence of a malicious server involved in name resolution.
  • DNS in English “Domain Name System”
  • multi-service offers including “Triple Play” offers (since they simultaneously offer access to the Internet, video content (including the broadcast of television programs) and conversational services (IP telephony) ), have captured a significant share of the market.
  • CPE Customer Premises Equipment
  • HG Home Gateway
  • box Such a CPE conventionally serves as an interface between a user's local network (“Local Area Network” (LAN)) and the network of an operator with whom the user has subscribed to a service offer ("Internet Service Provider” (ISP), in English). It is therefore access equipment to an operator's network through which the traffic characteristic of the various services subscribed to by the user passes.
  • LAN Local Area Network
  • ISP Internet Service Provider
  • an attack consists of modifying the configuration of DNS information stored in a CPE, descriptive of at least one trusted server associated with at least one network interface via which the CPE is able to communicate.
  • a DNS service makes it possible to associate a resource (for example of the domain name type, URI (in English “Uniform Resource Identifier”, in French “unique resource identifier”), etc.) with one or more IP addresses to access this resource.
  • a resource for example of the domain name type, URI (in English “Uniform Resource Identifier”, in French “unique resource identifier”), etc.
  • the DNS service allows a terminal connected to the CPE to obtain the IPv4 and/or IPv6 addresses associated with a domain name.
  • a DNS resolution request is relayed by the CPE to at least one of the trusted DNS servers configured in the CPE.
  • a connection is then established between the terminal and the application server using the IP address(es) returned by the DNS server to the CPE.
  • an attacker wishes to capture a user's traffic and intercept some of his data, he can, according to a first example, provide the user with an IP address of a malicious application server used by the attacker, instead of an IP address of the (legitimate) application server to which the user initially wanted to access.
  • the attacker can modify the configuration of the DNS information stored in the CPE so that it relays DNS requests sent by the terminal to a malicious DNS server managed by the attacker, instead of the trusted DNS server initially configured. . All communications that require DNS exchanges can thus be intercepted by the malicious DNS server.
  • the attacker can then redirect the traffic of the user victim of the attack to fraudulent servers which will emulate certain sites (for example, servers used to carry out a financial transaction).
  • the attacker can also decide to redirect application requests sent by the user to a “legitimate” application server, to prevent the user from realizing that he is the target of an attack.
  • the attacker first directs the user's requests to a "fraudulent” application server by manipulating DNS requests, then to the "legitimate” application server.
  • the attacker can modify the configuration of the DNS information stored in the CPE so that it relays DNS requests sent by the terminal to a malicious DNS server managed by the attacker, instead of the initially configured trusted DNS server.
  • the fraudulent application server does not "emulate” the requested service but behaves like a relay ("proxy") which completes the security association with the user's terminal and relays messages between this terminal and the legitimate application server. In doing so, the fraudulent application server accesses the content of the encrypted messages.
  • proxy a relay which completes the security association with the user's terminal and relays messages between this terminal and the legitimate application server. In doing so, the fraudulent application server accesses the content of the encrypted messages.
  • Password protection of access to the CPE administration interface (which notably allows DNS information to be configured in the CPE) is not sufficient to protect the CPE from the attacks described above. Indeed, as most users do not use (or do not even suspect the existence of) a CPE administration interface, the protection of access to this administration interface is often weak. Likewise, protecting access to the CPE administration interface by MAC address (“Medium Access Control”) may prove ineffective because an attacker can change the MAC address of his terminal to be identical to that (s) authorized by the CPE. These MAC addresses can in fact be acquired maliciously by listening to Wi-Fi exchanges, for example.
  • the invention proposes a solution for detecting a malicious domain name resolution server, implemented in equipment configured with at least one trusted domain name resolution server associated with at least one network interface via which said equipment is capable of communicating.
  • Such equipment implements: the transmission, to at least one of said trusted servers, of at least one request for activation of a domain name resolution verification service, the reception of at least a response comprising at least one domain name generated by said trusted server for said at least one interface, the transmission of at least one request for resolution of said at least one domain name, if no request for resolution of said at least one name domain name is received by said trusted server, or if at least one request for resolution of said at least one domain name is received by said trusted server but includes an anomaly, the receipt of at least one notification inviting said equipment to take action.
  • the proposed solution thus allows equipment (for example a terminal, a CPE, etc.) to initiate an action if a trusted domain name resolution server, configured for at least one network interface (for example Ethernet, Wireless LAN, etc.) of the equipment, detects an anomaly in a specific domain resolution request issued via an interface of the equipment.
  • equipment for example a terminal, a CPE, etc.
  • a trusted domain name resolution server configured for at least one network interface (for example Ethernet, Wireless LAN, etc.) of the equipment, detects an anomaly in a specific domain resolution request issued via an interface of the equipment.
  • the trusted server can generate one or more specific domain names for at least one interface of the equipment.
  • a domain name denoted for example “TARGET_HB_FQDN”
  • TARGET_HB_FQDN can be generated randomly by the trusted server.
  • the trusted server can transmit to the equipment the domain name(s) generated for at least one of its interfaces.
  • Such domain names are therefore known only to the trusted server and the equipment.
  • the trusted server can then detect the presence of a malicious server if no request for resolution of this or these domain names is received by it, or if one or more requests for resolution of this or these domain names (called for example “HB” in the following) are received but contain an anomaly (for example, the source address of the domain name resolution request is not an address of the equipment).
  • a malicious server if no request for resolution of this or these domain names is received by it, or if one or more requests for resolution of this or these domain names (called for example “HB” in the following) are received but contain an anomaly (for example, the source address of the domain name resolution request is not an address of the equipment).
  • a notification is sent by the trusted server to the equipment, so that the equipment can initiate at least one action allowing, for example, to correct the active domain name resolution configuration.
  • Such an action can thus be executed automatically by the equipment, without user intervention.
  • the equipment's DNS configuration information can be reset, or traffic to or from a malicious application server can be stopped.
  • the proposed solution thus contributes to improving the robustness of value-added IP services (DNS services included) and to protecting the user from attacks that would rely on a name resolution service such as the DNS service.
  • the proposed solution does not require traffic inspection in the network (e.g. in the access network) or communications profiling for anomaly detection.
  • the solution can thus be implemented independently of the underlying connectivity offer.
  • equipment according to the invention can embed one or more “DNS clients”.
  • DNS clients can be supported by the operating system (or OS) of a device, or be specific to an application. In the latter case, several DNS clients can be activated on the same equipment, each of these clients being uniquely identified.
  • the method according to the invention can be implemented by one of these DNS clients or be supported by a dedicated application.
  • each DNS client of a piece of equipment can implement the steps described above.
  • the invention makes no assumptions about the internal interface used between an application and a name resolution function (a DNS client, typically).
  • said at least one response also includes verification data (denoted for example “CHALLENGE”) generated by said trusted server for said at least one activation request.
  • Said at least one resolution request for said at least one domain name generated by the equipment then includes proof of integrity obtained from said verification data.
  • the trusted server Upon receipt of a resolution request by the trusted server, the latter can thus verify the integrity of the resolution request thanks to the proof of integrity, which contributes to improving the security of the proposed solution.
  • the proof of integrity is a digest (also called “hash”) of said verification data.
  • said at least one request for resolution of said at least one domain name includes an indicator requiring the generation, by said trusted server, of new verification data.
  • the equipment can then initiate a change in the verification data. As described below with the description of a particular embodiment, the equipment sends for example a resolution request denoted “HB (C, NONCE1)”.
  • the server which may initiate a change in the verification data.
  • Such a change of verification data may in particular be implemented on a regular basis or according to other policies local to the name resolution server.
  • said at least one response and/or said resolution request may be encrypted.
  • Such encryption makes it possible to preserve the verification data transmitted in the response to the activation request (i.e. response from the trusted server to the equipment) or the proof of integrity transmitted in the “HB” resolution request.
  • said at least one response also includes recurrence information (denoted for example “EPOCH”).
  • EPOCH recurrence information
  • the recurrence information provides the frequency of sending resolution requests (“HB”) by the equipment, the sending of a resolution request when the equipment is restarted, during a connection to a new network, etc.
  • HB sending resolution requests
  • said at least one activation request includes at least one contact address of said equipment (denoted for example “CONTACT_URI”).
  • the trusted server can send the equipment a notification to this contact address to inform the equipment of anomaly(s) observed in the resolution of domain names. It is assumed that the equipment implements the appropriate procedures to be able to receive these messages (for example configuration of a firewall, NAT). These procedures are known per se and are therefore not repeated here. An example is described in particular in the document RFC6887 “Port Control Protocol (PCP)” of April 2013. According to a particular embodiment, the descriptive information of said at least one trusted server is stored in a register maintained by said equipment and access to which is protected. Remember that it is conventional to configure at least one list of at least one trusted server associated with at least one interface of equipment.
  • such configuration information (ie descriptive information of said at least one trusted server) is stored in a specific register, access to which is protected, for example by a password or verification keys. This way, an attacker does not have direct access to this configuration information, which helps to strengthen the security of the proposed solution.
  • the registry to which access is protected is distinct from any other registry used for the storage of other information relating to domain name resolution.
  • this protected register is not predefined, and may be different for different devices.
  • the location of the register may in particular be chosen randomly when activating the domain name resolution verification service.
  • the equipment being configured to execute at least one action, said equipment executes at least one given action (for example, preconfigured) upon receipt of a notification inviting it to execute said at least one action.
  • said at least one action belongs to the group comprising: replacing the active domain name resolution configuration with the configuration of one of said trusted servers, deactivating outgoing communications with the exception of communications to one of said servers trusted, generate a local notification to inform a user of a change in the domain name resolution configuration, request sending of the active domain name resolution configuration.
  • the invention also relates to such a method for detecting a malicious domain name resolution server, implemented in the trusted server.
  • Such a trusted server implements the following steps: receiving at least one request for activation of a domain name resolution verification service, coming from said equipment, the transmission of at least one response comprising at least one domain name generated by said trusted server for said at least one interface, if no request for resolution of said at least one domain name is received by said trusted server, or if at least one request for resolution of said at least one domain name is received by said trusted server but includes an anomaly, transmission to said equipment of at least one notification inviting it to execute an action.
  • the trusted server can generate one or more specific domain names for at least one interface of the equipment and detect a problem in the domain name resolution check service if no domain name resolution request specific domain name is not received, or if a request to resolve the specific domain name is received but contains an anomaly. If a problem is detected, the trusted server can send a notification to at least one contact address of said equipment carried by said activation request or to the address used by said equipment to transmit said activation request. These checks are made possible because the trusted server is authoritative for the domain names generated for at least one interface of a piece of equipment.
  • an anomaly is detected if said at least one resolution request for said at least one domain name and if said at least one activation request does not come from the same equipment.
  • the trusted server compares the addresses used for sending the activation request and for sending the resolution request for said at least one domain name. If they differ or are not associated with the same equipment, the trusted server detects an anomaly.
  • said at least one response also includes verification data generated by said trusted server for said at least one activation request.
  • said at least one resolution request for said at least one domain name includes a proof of integrity obtained from said verification data, and an anomaly is detected if said proof of integrity carried by said at least one request resolution of said at least one domain name is not consistent with a proof of integrity obtained from verification data known to the trusted server.
  • the trusted server randomly generates verification data and transmits it in its response.
  • the equipment calculates a digest of this verification data, and transmits it in the specific domain name resolution request.
  • the server trusted can locally calculate a digest of the verification data that it knows, and compare it with the digest received in the resolution request.
  • said at least one response includes new verification data generated by said trusted server for said equipment, at the initiative of said trusted server or upon receipt of a request from said equipment.
  • the verification data can actually be renewed at the initiative of the equipment or the trusted server, for example regularly, so as to improve the security of the proposed solution.
  • said at least one response also includes recurrence information (denoted for example "EPOCH”) of said at least one request for resolution of said at least one domain name, and an anomaly is detected if no request resolution of said at least one domain name is received by said trusted server or if said at least one request for resolution of said at least one domain name is not consistent with said recurrence information.
  • EPOCH recurrence information
  • said activation and/or resolution requests for said at least one domain name use an option according to the DNS mechanism as described in document RFC 6891 (“Extension Mechanisms for DNS” (EDNS) d 'April 2013) to transmit various information between the equipment and the trusted server (for example a domain name ("TARGET_HB_FQDN”), verification data (“CHALLENGE”), recurrence information (“EPOCH”), a contact address (“CONTACT_URI”), etc.).
  • a domain name (“TARGET_HB_FQDN")
  • CHALLENGE” verification data
  • EPOCH recurrence information
  • CONTACT_URI contact address
  • the invention relates to corresponding equipment.
  • Such equipment is particularly suitable for implementing a method for detecting a malicious domain name resolution server according to at least one embodiment of the invention.
  • such equipment can include the different characteristics relating to the process according to the invention, which can be combined or taken separately.
  • the equipment is of type CPE, terminal, etc.
  • the equipment can be connected to a fixed network, a mobile network, a network of connected objects (for example a mesh network using the “Thread” protocol), etc.
  • the invention relates to a corresponding trusted server.
  • a trusted server is particularly suitable for implementing a method for detecting a malicious domain name resolution server according to at least one embodiment of the invention.
  • a server can include the different characteristics relating to the method according to the invention, which can be combined or taken separately.
  • the invention relates to one or more computer programs comprising instructions for implementing a method for detecting a malicious domain name resolution server according to at least one mode of embodiment of the invention, when this or these programs is/are executed by a processor.
  • the methods according to the invention can therefore be implemented in various ways, in particular in wired form and/or in software form.
  • the method according to the invention can be implemented by a generic module, an application, etc.
  • Figure 1 illustrates the main steps of a method for detecting a malicious domain name resolution server according to one embodiment
  • Figure 2 presents the generic format of a WADE option according to one embodiment
  • Figure 3 presents a example of WADE option according to one embodiment
  • Figure 4 illustrates an example of messages exchanged between a DNS client and a trusted server without anomaly detection
  • Figure 5 illustrates an example of messages exchanged between a DNS client and a trusted server with modification of the verification data at the initiative of the DNS client
  • Figure 6 illustrates an example of messages exchanged between a DNS client and a trusted server with modification of the verification data at the initiative of the trusted server
  • Figure 7 illustrates an example of messages exchanged between a DNS client and a trusted server with detection of an anomaly such as non-compliance with recurrence information
  • Figure 8 illustrates an example of messages exchanged between a DNS
  • equipment for example a terminal, a CPE
  • descriptive information from at least one trusted domain name resolution server associated with a network interface via which the equipment is capable to communicate.
  • the general principle of the invention is based on the generation, by the trusted server, of at least one specific domain name for at least one interface of the equipment and the establishment of a procedure for issuing requests resolutions related to this specific domain name.
  • the trusted server can thus detect a problem in a domain name resolution service if it does not receive any resolution request for the specific domain name, or if a request for resolution of the specific domain name that it receives includes a anomaly.
  • the trusted server can then inform the equipment, which can then take appropriate actions.
  • equipment H 11 configured with at least one trusted DNS domain name resolution server 12 associated with at least one network interface via which the equipment is able to communicate.
  • the equipment 11 transmits to the trusted server 12, via at least one network interface, at least one request for ACTIV activation of a domain name resolution verification service.
  • the trusted server 12 receives said at least one ACTIV activation request during a step 121.
  • the activation request may in particular be a dedicated request, such as a DNS request reserved for the activation of the domain name resolution verification service.
  • a dedicated request is a request to resolve a dedicated domain name, capable of triggering the activation of the verification service.
  • This dedicated domain name can be a name configured when subscribing to the service (for example “peraspera. example”) or a domain name reserved for this use and which can be used by all operators (for example “peraspera. arpa ").
  • the activation request may be a “non-dedicated” request.
  • the equipment does not generate a DNS request relating to a domain name dedicated to the activation of the domain name resolution verification service, but uses a classic DNS request, for example a DNS request issued for needs of an application embedded in the equipment, and inserts information for the activation of the domain name resolution service.
  • a classic DNS query is thus diverted by inserting specific information, for example in the form of a new option according to a DNS extension mechanism as described below.
  • the trusted server 12 can generate at least one specific domain name for the network interface used, and transmit to the equipment 11 at least one response comprising the specific domain name(s), during a step 122.
  • the trusted server transmits a single REP response bearing a unique domain name.
  • the equipment 11 receives the REP response during a step 112.
  • the equipment 11 can then transmit to the trusted server 12 at least one request for resolution of the unique DNS REQ domain name during a step 113.
  • a resolution request relating to the unique domain name is subsequently also called HB (“Heartbeat” in English).
  • the trusted server 12 If the trusted server 12 receives a REQ DNS request during a step 123, but this REQ DNS request contains an anomaly, the trusted server 12 sends a NOTIF notification to the equipment 11 during a step 124 , inviting him to perform an action.
  • the trusted server 12 If the trusted server 12 does not receive any DNS REQ request relating to the unique domain name communicated to the equipment 11 during activation of the procedure (steps 122/112), the trusted server 12 sends a NOTIF notification to the equipment 11 inviting it to execute an action, for example after a waiting period.
  • the waiting period can in particular be predefined, configured in the trusted server, known to the equipment or transmitted to the equipment, etc.
  • the equipment 11 can thus receive, during a step 114, a NOTIF notification inviting it to execute an action, for example a predefined action.
  • the equipment can then execute such an action, without requiring interaction with a user of the equipment or an administrator of a local network (for example administrator of a home network, administrator of a CPE).
  • different information can be used by the trusted server to detect an anomaly when processing a domain name resolution request.
  • verification data and/or recurrence information can be transmitted in the REP response from the trusted server to the equipment, and used by the equipment to manage the transmission of the domain name resolution request.
  • unique DNS REQ to the trusted server.
  • An anomaly may in particular be detected if the ACTIV activation request and the REQ DNS unique domain name resolution request do not come from the same equipment, or if proof of integrity, obtained from the verification data and conveyed by the DNS REQ query, is not consistent with a proof of integrity obtained from verification data known to and maintained locally by the trusted server, or if the issuance of the DNS REQ query(ies) is not conforms to the recurrence information, or if the DNS REQ query includes information from a DNS relay, for example.
  • PER ASPERA PER-DNS client guards Against malicious DNS Server swapping, traffic intERception, and datA theft”, or “procedure for detection and mitigation of DNS configuration changes”.
  • the user can subscribe to the PER ASPERA service using a dedicated interface.
  • the PER ASPERA service may in particular be provided to terminals directly connected to the network of a service provider or reserved for offers which are based on the provision of a CPE.
  • equipment denotes a terminal or a CPE used by a user wishing to benefit from the PER ASPERA service.
  • the PER ASPERA service may be offered by a connectivity service provider, a DNS service provider, etc.
  • a user may request a DNS service provider distinct from the provider providing connectivity.
  • the user equipment can connect to several networks using the same access equipment or different equipment.
  • the user's equipment can use the same DNS service for all access networks (fixed and mobile) to which it can connect.
  • the PER ASPERA service may be offered independently of the nature of the access network(s) used by the user's equipment.
  • the PER ASPERA server can only be used for some of the interfaces.
  • the equipment or at least one network interface of the equipment, is configured with at least a list of at least one trusted DNS server.
  • the connections between the equipment and the trusted server(s) are, in the embodiment described here, secure.
  • the trusted server(s) can support at least one encryption scheme based for example on the use of one or other of the following protocols: DNS over TLS (DoT), DNS over DTLS (DoD), DNS over HTTPS (DoH), DNS over QUIC (DoQ), DNS over CoAP (DoC), etc.
  • the configuration of the list or lists of at least one trusted server can be carried out using a mechanism based on a discovery of resolvers designated by their neighbors (DNR, “Discovery of Neighbor-designated Resolvers”, as described in the document “DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)” of August 2022, a mechanism based on a key exchange (IKE, “Internet Key Exchange”, as described in the document “Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS” of September 2022), etc.
  • IKE Internet Key Exchange
  • IKEv2 Internet Key Exchange Protocol Version 2
  • the equipment can also be configured with at least one action.
  • the equipment is configured with an indexed list of predefined actions.
  • Such a list may contain the following actions (non-exhaustive): policy/action index “0”: replace the active domain name resolution configuration with the configuration of one of the trusted servers, policy index/ action index "1”: disable outgoing communications except communications to one of the trusted servers for a given interface, policy/action index "2”: generate a local notification to inform the user a change to the domain name resolution configuration, policy/action index "3": request to send the active domain name resolution configuration, etc.
  • the descriptive information of the trusted server(s) is stored in a register maintained by the equipment and access to which is protected. Access to this register can notably implement strong authentication mechanisms (for example, through the use of a dedicated password or multi-level verification keys). The location of such a register can in particular be decided when activating the PER ASPERA service.
  • the registry can correspond to dedicated entries in a Windows ⁇ registry, a file, a database, etc.
  • such a register is distinct from any other register used for the storage of other information relating to domain name resolution.
  • the register where the list(s) of at least one trusted server are stored is therefore isolated from other registers used for storing information used for DNS management.
  • the descriptive information of the trusted server(s) may be duplicated to be stored on the one hand in the register to which access is protected, and on the other hand in a register conventionally used for storing information relating to resolution. of domain names.
  • This isolation aims to prevent modification of the list of trusted DNS servers by a malicious application or following fraudulent access to the equipment.
  • an application that accesses the local DNS configuration without user consent can possibly modify the active DNS configuration, but cannot modify the configuration of trusted servers stored in the registry whose access is protected.
  • the term “DNS client” is used to designate the equipment or at least one network interface of the equipment implementing the proposed solution.
  • a DNS client transmits to at least one of its trusted servers at least one DNS request for activation of the PER ASPERA service.
  • this activation request can be dedicated to the activation of the domain name resolution verification service.
  • the activation request is a DNS request reserved for the PER ASPERA service.
  • the activation request may be non-dedicated, in particular when conventional requests are used for the needs of usage applications.
  • the DNS client uses a request issued for example by an application embedded in the equipment by inserting the information required for activation of the PER ASPERA service.
  • an activation request is sent to each of these lists, i.e. to at least one trusted server from each of the lists. This makes it possible in particular to control DNS activity for all of the interfaces of a piece of equipment when they are associated with different trusted servers.
  • the activation request(s) use a new option according to the EDNS mechanism.
  • WADE An EDNS Option for Watching DNS associations to prevent swapping, interception, and theft.
  • the identification of an extended request according to the EDNS mechanism is carried out using a pseudo “resource-record” (RR) OPT.
  • the “OPTION-DATA” data field of the RR OPT provides six control indicators, for example in the form of 6 bits H, N, C, T, E, U: the H bit, too called “HB_ENABLE” (for “Heartbeat Enable” in English), positioned at the value “1” indicates a request for activation of the PER ASPERA service, while the value “0” is used to deactivate the PER ASPERA service, the bit N positioned at the value “1” indicates the presence of the “NUNCE” field, the bit C positioned at the value “1” indicates the presence of the “CHALLENGE” field, the bit T positioned at the value “1” indicates the presence of the “TARGET_HB_FQDN” field, the E bit set to the value “1” indicates the presence of the “EPOCH” field, the U bit set to the value “1” indicates the presence of the “CONTACT_URI” field.
  • H bit too called “HB_ENABLE” (for “Heartbeat Enable” in English)
  • variable parameters are preceded by a field which indicates the size of the parameter.
  • An activation request including the WADE option, as illustrated in Figure 3 uses the H bit and possibly the U bit, set to the value “1”.
  • the other bits can be set to the value “0”.
  • the H bit can take a value “1” to indicate a request for activation of the PER ASPERA service.
  • the “U” bit can also take a value “1” to indicate the presence of the “CONTACTJJRI” field.
  • a “URI_Length” field can in particular be provided to indicate the size of the parameter present in the “CONTACT_URI” field, as illustrated in Figure 3.
  • Such a “CONTACTJJRI” field may be present in a request to activate the PER ASPERA service. This field lists the contact identifier(s) that the trusted server (which receives the activation request) can use to report anomalies observed in the DNS configuration information (for example by sending the DNS client a notification accordingly). inviting action).
  • the contact address(es) for sending notifications are those entered in the “CONTACTJJRI” field. If the U bit is set to the value “0”, ie if the “CONTACT_URI” field is not present, this means that the contact address for sending notifications is the address (as well as the number of port) used by the DNS client to send this activation request.
  • PER ASPERA service can be deactivated at any time by equipment.
  • a request that contains the WADE option can be sent from the DNS client to a trusted server, using the H bit set to the value "0".
  • the service is activated.
  • Such a WADE option is only inserted in a DNS request intended for a trusted server. This verification is based, for example, on the destination IP address of the DNS request or the DNA (“Authentication Domain Name”) of the target DNS server.
  • At least one trusted server receives at least one activation request for the PER ASPERA service during a step 121.
  • a trusted server may respond with an error message.
  • the DNS client can optionally select another trusted server configured in its list, send an activation request to the same server but without the WADE option, end the communication and generate a local notification (application, user, etc. ), etc.
  • a trusted server can process the activation request received.
  • the trusted server can extract the information communicated in the WADE option, in particular in the “CONTACT_URI” field if applicable.
  • the trusted server can extract a source IP address and port number from the activation request. This information can be stored for later re-use.
  • a trusted server can thus maintain one or more source addresses per DNS client.
  • the trusted server can in particular prepare at least one response and transmit it to the DNS client during step 122 of Figure 1.
  • a response can in particular take the form of a DNS query which includes the WADE option such as 'illustrated in Figure 2.
  • such a response including the WADE option uses bits H and T, and possibly bits C and E, positioned at the value “1”.
  • the other bits (U, N) can be set to the value “0”.
  • the H bit can be set to “1” to indicate acceptance of a request for activation of the PER ASPERA service.
  • the T bit can also be set to “1” to indicate the presence of the “TARGET_HB_FQDN” field.
  • a “TARGET_HB_FQDN_Length” field can in particular be provided to indicate the size of the parameter present in the “TARGET_HB_FQDN” field.
  • Such a “TARGET_HB_FQDN” field includes one or more specific domain names generated by the trusted server for the DNS client considered. The trusted server is authoritative for these domain names. They are therefore considered unique, and known only to the DNS client and the trusted server. To do this, they are generated randomly for example.
  • bit C can take a value “1” to indicate the presence of a “CHALLENGE” field.
  • a “CHALLENGE_Length” field can in particular be provided to indicate the size of the parameter present in the “CHALLENGE” field.
  • Such a “CHALLENGE” field contains verification data that can be used by the DNS client to determine proof of integrity.
  • verification data may be randomly generated and used by the DNS client to calculate a proof of integrity, such as a hash.
  • Such integrity proof can then be inserted by the DNS client in subsequent DNS requests intended for the trusted server.
  • bit E can take a value “1” to indicate the presence of an “EPOCH” field.
  • An “EPOCHJength” field can in particular be provided to indicate the size of the parameter present in the “EPOCH” field.
  • Such an “EPOCH” field includes recurrence information, used by the DNS client to transmit “HB” domain name resolution requests. For example, such a field indicates the periodicity of HB queries by the DNS client.
  • bits C, T, E are set to the value “1” and bits U and N are set to the value “0”.
  • the trusted server can store the information communicated to each DNS client.
  • the trusted server can control the TTL (“Time To Live”) field of the responses to force the DNS client to renew the activation of the PER ASPERA service by returning an activation request.
  • TTL Time To Live
  • the DNS client receives a response from the trusted server during a step 112.
  • the DNS client can extract the information contained in the WADE option, particularly in the “TARGET_HB_FQDN” field. If information is present in the “EPOCH” and/or “CHALLENGE” fields, this information can also be extracted.
  • the DNS client can store this information, in association with at least one trusted server and at least one interface. Multiple responses that contain the WADE option can be sent to the DNS client by a server of confidence. All this information can be stored by the DNS client in an appropriate registry, access to which can be protected.
  • the DNS client can then issue a request to resolve the domain name present in the “TARGET_HB_FQDN” field during a step 113.
  • a request can in particular take the form of a DNS request with WADE option as illustrated in Figure 2.
  • WADE option can use the H and N bits set to the value “1”.
  • the other bits (C, T, E and U) can be set to the value “0”.
  • the N bit can be set to “1” to indicate the presence of the “NUNCE” field.
  • a “NONCE_Length” field can in particular be provided to indicate the size of the parameter present in the “NONCE” field.
  • Such a “NUNCE” field includes for example a proof of integrity generated from the verification data transmitted in the “CHALLENGE” field.
  • Figure 4 illustrates an example of messages exchanged between a DNS client 41 and a trusted DNS server 42.
  • the DNS client 41 sends an activation request using its address @1 as a source address
  • the trusted server 42 constructs a response including the fields “TARGET_HB_FQDN”, “EPOCH” and CHALLENGE.
  • the trust server 42 has the information contained in the fields “TARGET_HB_FQDN » “EPOCH” and “CHALLENGE”, and the source address of the activation request (@1).
  • the DNS client 41 can in particular issue one or more DNS queries for the resolution of the domain name indicated in the "TARGET_HB_FQDN" field, denoted HB, taking into account the value indicated in the "EPOCH” field of the response received.
  • the “EPOCH” field includes recurrence information indicating a sending frequency Tl of HB requests.
  • a first HB request for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field can be issued at time T0+T1
  • a second HB request for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field can be issued at time TO+2*T1
  • a third HB request for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field can be issued at time TO+3*T1, etc.
  • Such HB (“HeartBeat”) requests make it possible to signal to the trusted server 42 the presence of an active association with a DNS client 41.
  • the DNS client 41 can in particular calculate a summary of the verification data conveyed in the “CHALLENGE” field of the response received during the PER ASPERA activation phase.
  • Such a summary can in particular be inserted in the “NUNCE” field of the HB request which contains the WADE option.
  • the DNS client 41 issues a first HB request (412) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity in the “NONCE” field. at time T0+T1.
  • the trust server 42 can also verify that the proof of integrity contained in the “NUNCE” field of the HB request is consistent with a proof of integrity determined locally from the verification data stored by the trust server 42 (such as recorded in the “CHALLENGE” field in the response sent by the trusted server).
  • the trusted server 42 can calculate a digest of the verification data (for example carry out the “Hash (CHALLENGE)” calculation where Hash designates a hash function corresponding to that applied by the DNS client 41 to generate the digest of the verification data.
  • SHAs Secure Hash Algorithms
  • the trust server 42 can also check whether the recurrence information specified in the “EPOCH” field is respected. This is not the case, an anomaly is detected
  • the indication of the "hash” function to be used by a DNS client can be communicated using the WADE option. To do this, a bit. “I” is defined for this purpose among the “unassigned” bits described in Figure 2. When the “I” bit is set to “1”, the identity of the “hash” function is indicated in the body of the WADE option (e.g. SHA2-256).
  • the DNS client 41 can then issue a second HB request (413) for the resolution of the domain name indicated in the TARGET_HB_FQDN field, including a proof of integrity in the NONCE field, at time T0+2T1.
  • the DNS client 41 can issue a third HB request (414) and so on.
  • the information communicated during activation of the PER ASPERA service can be modified at the initiative of the trusted server 42 or the DNS client 41.
  • Figure 5 illustrates an example of messages exchanged between the DNS client 41 and the trusted server 42, with a request to modify the verification data at the initiative of the DNS client 41.
  • the DNS client 41 issues an activation request using its address @1, and that the trusted server 42 constructs a response including the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGEl” (Activ. PER APSERA 511).
  • the DNS client 41 issues a first HB request (512) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity in the “NONCE1” field. at time T0+T1.
  • the trust server 42 can in particular verify that the source address of the activation request (@1) and the source address of the first HB request (src@) are consistent .
  • the trust server 42 can also verify that the proof of integrity contained in the “NONCE1” field of the HB request is consistent with a proof of integrity determined locally from the verification data carried by the “CHALLENGEl” field.
  • the trusted server 42 can calculate a digest of the verification data (Hash (CHALLENGEl)) and verify that it is equal to the digest transmitted in the “NONCE1” field.
  • the trusted server 42 can also check whether the recurrence information specified in the “EPOCH” field is respected.
  • the DNS client 41 may request to modify the verification data (“CHALLENGEl”) at any time. To do this, the DNS client can send a second HB request (513) for the resolution of the domain name indicated in the "TARGET_HB_FQDN” field including a proof of integrity in the "NONCE1" field, calculated on the basis of the data from verification of the “CHALLENGEl” field. To inform the trusted server 42 that the DNS client 41 requests new verification data, bits C and N are set to “1”.
  • the trusted server 42 can accept the request and generate new verification data, which is transmitted to the DNS client 41 in a response which contains the WADE option, in the “CHALLENGE2” field (514).
  • the DNS client 41 can issue a third HB request (515) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity in the “NONCE2” field, at time T0+2T1. Such proof of integrity is obtained from the new “CHALLENGE2” verification data.
  • the trust server 42 can also verify that the proof of integrity contained in the “NONCE2” field of the HB request is consistent with a proof of integrity determined locally from the new verification data stored by the trust server 42 ( as contained in the “CHALLENGE2” field of the response sent by the trusted server).
  • the trusted server 42 can calculate a digest of the verification data (Hash (CHALLENGE2)) and verify that it is equal to the digest contained in the “NONCE2” field.
  • the trusted server 42 can also check whether the recurrence information contained in the “EPOCH” field is respected.
  • the DNS client 41 can issue a fourth HB request (516) and so on.
  • Figure 6 illustrates an example of messages exchanged between the DNS client 41 and the trusted server 42, with a request to modify the verification data at the initiative of the trusted server 42.
  • the DNS client 41 issues an activation request using its address @1, and that the trusted server 42 constructs a response including the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGEl” (Activ. PER APSERA 611).
  • the DNS client 41 issues a first HB request (612) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity in the “NONCE1” field. at time T0+T1.
  • the trust server 42 can in particular verify that the source address of the activation request (@1) and the source address of the first HB request (src@) are consistent .
  • the trust server 42 can also verify that the proof of integrity specified in the “NONCE1” field of the HB request is consistent with a proof of integrity determined from the verification data recorded in the “CHALLENGEl” field.
  • the trusted server 42 can calculate a digest of the verification data (Hash (CHALLENGEl)) and verify that it is equal to the digest recorded in the “NONCE1” field.
  • the trusted server 42 can also check whether the recurrence information contained in the “EPOCH” field is respected.
  • the trusted server 42 can decide at any time to modify the verification data (“CHALLENGEl”).
  • the trusted server 42 can generate new verification data.
  • the trusted server 42 can transmit the new verification data to the DNS client 41 in a response which contains the WADE option, recorded in the “CHALLENGE2” field (614).
  • bit C is set to “1”.
  • the DNS client 41 can issue a third HB request (615) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity contained in the “NONCE2” field, at time T0+2T1. Such proof of integrity is obtained from the new “CHALLENGE2” verification data.
  • the trust server 42 can also verify that the proof of integrity recorded in the “NONCE2” field of the HB request is consistent with a proof of integrity determined locally from the new verification data stored by the trust server 42 ( as contained by the “CHALLENGE2” field in the response sent by the trusted server).
  • the trusted server 42 can calculate a digest of the verification data (Hash (CHALLENGE2)) and verify that it is equal to the digest transmitted in the “NONCE2” field.
  • the trusted server 42 can also check whether the recurrence information contained in the “EPOCH” field is respected.
  • the DNS client 41 can issue a fourth HB request (616) and so on.
  • the trusted server 42 can modify the verification data at regular intervals for security purposes.
  • Figure 7 illustrates an example of messages exchanged between the DNS client 41 and the trusted server 42.
  • the DNS client 41 issues an activation request using its address @1, and that the trusted server 42 constructs a response including the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE” (Activ. PER APSERA 711).
  • the DNS client 41 issues a first HB request (712) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity recorded in the “NONCE” field.
  • the trust server 42 can in particular verify that the source address of the activation request (@1) and the source address of the first HB request (src@) are consistent .
  • the trusted server 42 can also verify that the proof of integrity contained in the “NUNCE” field of the HB request is consistent with a proof of integrity determined locally from the verification data contained in the “CHALLENGE” field.
  • the trusted server 42 can also check whether the recurrence information recorded in the “EPOCH” field is respected.
  • the trusted server 42 notes that it does not receive an HB request at times TO + Tl, TO + 2T1 and TO + 3T1 for example. It therefore detects that the recurrence information contained in the “EPOCH” field (recurrence of requests with a periodicity Tl) is not respected, and issues at least one notification inviting the DNS client 41 to take action.
  • one or more notification messages 713 are sent to the address entered in the “CONTACT_URI” field for the DNS client 41, or to the address used by the DNS client 41 to send the activation request.
  • a notification message can be Push HTTPS, Update DNS, etc.
  • the exchange illustrated in Figure 7 can in particular be observed when a malicious DNS server 73 has been configured in the equipment embedding the DNS client 41, and this malicious server 73 blocks all or part of the DNS requests sent by the DNS client 41
  • the DNS client 41 can initiate one or more actions upon receipt of the notification message(s), such as reinstalling the trusted DNS configuration, blocking certain communications, etc.
  • the trusted server 42 can again receive an HB request.
  • Figure 8 illustrates an example of messages exchanged between the DNS client 41 and the trusted server 42.
  • the DNS client 41 issues an activation request using its address @1, and that the trusted server 42 constructs a response including the fields “TARGET_HB_FQDN”, “EPOCH” and “CHALLENGE” (Activ. PER APSERA 811).
  • the DNS client 41 issues a first HB request (812) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity recorded in the “NONCE” field.
  • the trust server 42 can in particular verify that the source address of the activation request (@1) and the source address of the first HB request (src@) are consistent .
  • the trust server 42 can also verify that the proof of integrity contained in the “NUNCE” field of the HB request is consistent with a proof of integrity determined from the verification data recorded in the “CHALLENGE” field.
  • the trusted server 42 can also check whether the recurrence information specified in the “EPOCH” field is respected.
  • the DNS client 41 then issues a second HB request (813) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field, including a proof of integrity in the “NONCE” field.
  • this second HB request (813) is intercepted by a server F 83 and relayed to the trusted server 42.
  • the trusted server 42 issues at least one notification 814 inviting the DNS client 41 to take action.
  • one or more notification messages 814 are sent to the address entered in the CONTACT_URI field for the DNS client 41, or to the address used by the DNS client 41 to send the activation request.
  • the DNS client initiates an action such as replacing the active domain name resolution configuration with the configuration of one of the DNS servers. trust, etc.
  • the trusted server 42 can trigger the execution of several actions for HB exchanges using an IP address distinct from that used during activation of the PER ASPERA service.
  • the exchange illustrated in Figure 8 can in particular be observed when a malicious DNS server 83 has been configured in the equipment embedding the DNS client 41, and this malicious server 83 behaves like an intermediate DNS relay ("proxy") which relays messages between the DNS client 41 and the trusted server 42.
  • proxy intermediate DNS relay
  • the trusted server 42 can again receive an HB request.
  • the trusted server 42 can also include an EDE option, as described in document RFC 8914 “Extended DNS Errors” of October 2020, to inform the DNS client that a DNS error has been observed by the trusted server.
  • the DNS client can proceed to perform the action indicated in this response.
  • the indication of the action to be performed by a DNS client can be provided using the WADE option.
  • an “A” bit is defined for this purpose among the “unassigned” bits presented in Figure 2. When the “A” bit is set to “1”, the index of the action is entered in the body of the WADE option.
  • the DNS client 41 when the DNS client 41 wishes to deactivate the PER ASPERA service, it issues an HB request (912) for the resolution of the domain name indicated in the “TARGET_HB_FQDN” field including a proof of integrity in the “NUNCE” field, calculated on the basis of the verification data recorded in the “CHALLENGE” field.
  • the H bit “HB_ENABLE” is set to “0”.
  • the trust server 42 verifies that there is no anomaly. For example, the trusted server 42 can reject the HB request 912 and return an error message if the proof of integrity contained in the NONCE field of the HB request 912 does not correspond to the proof of integrity calculated locally by the trusted server 42 for the verification data recorded in the CHALLENGE field and stored locally for this DNS client.
  • the trust server 42 validates the deactivation of the PER ASPERA service.
  • such equipment respectively trusted server, comprises a memory 101E, respectively 101S, comprising for example a buffer memory, a processing unit 102E, respectively 102S, equipped for example with a processor P, and controlled by the computer program Pg 103E, respectively 103S, implementing the method for detecting a malicious server according to an embodiment described above.
  • the code instructions of the computer program 103E are for example loaded into a RAM memory before being executed by the processor of the processing unit 102E.
  • the processor of the processing unit 102E implements the steps of the method for detecting a malicious server according to an embodiment described above, according to the instructions of the computer program 103E, to: transmit, to the destination 'at least one of said trusted servers, at least one request for activation of a domain name resolution verification service, receive at least one response comprising at least one domain name generated by said trusted server for said at least one at least one interface, transmit at least one request for resolution of said at least one domain name, if no request for resolution of said at least one domain name is received by said trusted server, or if at least one request for resolution of said at least one domain name is received by said trusted server but contains an anomaly, receiving at least one notification inviting said equipment to take action.
  • the code instructions of the computer program 103S are for example loaded into a RAM memory before being executed by the processor of the processing unit 102S.
  • the processor of the processing unit 102S implements the steps of the method for detecting a malicious server according to an embodiment described above, according to the instructions of the computer program 103S, for: receive at least one request for activation of a domain name resolution verification service, coming from said equipment, transmit at least one response comprising at least one domain name generated by said trusted server for said at least one interface , - if no request for resolution of said at least one domain name is received by said trusted server, or if at least one request for resolution of said at least one domain name is received by said trusted server but includes an anomaly , transmit to said equipment at least one notification inviting it to execute an action.

Landscapes

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

Abstract

L'invention concerne un procédé de détection d'un serveur DNS malveillant, mis en œuvre dans un équipement configuré avec au moins un serveur DNS de confiance, mettant en œuvre : − la transmission (111), à destination d'au moins un desdits serveurs de confiance, d'au moins une requête d'activation d'un service de vérification DNS, − la réception (112) d'au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance, − la transmission (113) d'au moins une requête de résolution dudit au moins un nom de domaine, − si aucune requête de résolution dudit au moins un nom de domaine n'est reçue par ledit serveur de confiance, ou si au moins une requête est reçue mais comporte une anomalie, la réception (114) d'au moins une notification invitant ledit équipement à engager une action.

Description

DESCRIPTION
TITRE : Procédés de détection d'un serveur de résolution de noms de domaine malveillant, équipement, serveur de confiance et programme d'ordinateur correspondants.
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 informatique mettant en oeuvre le protocole IP.
Plus précisément, l'invention concerne les services de résolution de noms, par exemple DNS (en anglais « Domain Name System »), et propose une solution contribuant à détecter la présence d'un serveur malveillant impliqué dans la résolution de noms.
2. Art antérieur
Le développement de l'Internet s'appuie sur un ensemble d'offres de services pour les marchés grand public et entreprises. Parmi celles-ci, les offres dites multi-services, dont les offres « Triple Play » (car proposant simultanément un accès à Internet, à des contenus vidéo (dont la diffusion de programmes télévisés) et à des services conversationnels (téléphonie sur IP)), ont accaparé une part importante du marché.
L'un des facteurs communs aux offres des opérateurs est la présence systématique d'une passerelle domestique ou d'entreprise, souvent appelée CPE (« Customer Premises Equipment »), HG (« Home Gateway ») ou encore « box ». Un tel CPE sert classiquement d'interface entre le réseau local d'un utilisateur (« Local Area Network » (LAN)) et le réseau d'un opérateur auprès duquel l'utilisateur a souscrit une offre de service (« Internet Service Provider » (ISP), en anglais). C'est donc un équipement d'accès au réseau d'un opérateur par lequel transite le trafic caractéristique des différents services souscrits par l'utilisateur.
Le CPE étant un point de passage pour le trafic en provenance ou à destination d'un utilisateur via un réseau d'opérateur, des attaques peuvent être menées sur cet équipement, par exemple pour intercepter des données sensibles de l'utilisateur, telles que des données bancaires.
A titre d'exemple, une attaque consiste à modifier la configuration des informations DNS stockées dans un CPE, descriptives d'au moins un serveur de confiance associé à au moins une interface réseau via laquelle le CPE est apte à communiquer.
Pour rappel, un service DNS permet d'associer une ressource (par exemple de type nom de domaine, URI (en anglais « Uniform Resource Identifier », en français « identifiant uniforme de ressource »), etc.) avec une ou plusieurs adresses IP pour accéder à cette ressource. Par exemple, le service DNS permet à un terminal connecté au CPE d'obtenir les adresses IPv4 et/ou IPv6 associées à un nom de domaine. Ainsi, quand un terminal connecté au CPE veut joindre un serveur applicatif identifié par un nom de domaine, une requête de résolution DNS est relayée par le CPE vers l'un au moins des serveurs DNS de confiance configurés dans le CPE. Une connexion est alors établie entre le terminal et le serveur applicatif en utilisant la ou les adresses IP retournées par le serveur DNS au CPE.
Si un attaquant souhaite capter le trafic d'un utilisateur et intercepter certaines de ses données, il peut, selon un premier exemple, fournir à l'utilisateur une adresse IP d'un serveur applicatif malveillant utilisé par l'attaquant, en lieu et place d'une adresse IP du serveur applicatif (légitime) auquel l'utilisateur souhaitait initialement accéder. Pour ce faire, l'attaquant peut modifier la configuration des informations DNS stockées dans le CPE pour qu'il relaie les requêtes DNS émises par le terminal vers un serveur DNS malveillant géré par l'attaquant, au lieu du serveur DNS de confiance initialement configuré. Toutes les communications qui nécessitent des échanges DNS peuvent ainsi être interceptées par le serveur DNS malveillant. L'attaquant peut alors rediriger le trafic de l'utilisateur victime de l'attaque vers des serveurs frauduleux qui émuleront certains sites (par exemple, des serveurs utilisés pour réaliser une transaction financière).
Selon un deuxième exemple, l'attaquant peut aussi décider de rediriger les requêtes applicatives émises par l'utilisateur vers un serveur applicatif « légitime », pour éviter que l'utilisateur ne se rende compte qu'il est la cible d'une attaque. Dans ce cas, l'attaquant dirige d'abord les requêtes de l'utilisateur vers un serveur applicatif « frauduleux » en manipulant les requêtes DNS, puis vers le serveur applicatif « légitime ». Pour ce faire, comme dans le premier exemple, l'attaquant peut modifier la configuration des informations DNS stockées dans le CPE pour qu'il relaie les requêtes DNS émises par le terminal vers un serveur DNS malveillant géré par l'attaquant, au lieu du serveur DNS de confiance initialement configuré. Toutefois, dans le deuxième exemple, le serveur applicatif frauduleux « n'émule » pas le service demandé mais se comporte comme un relais (« proxy ») qui termine l'association de sécurité avec le terminal de l'utilisateur et relaie les messages entre ce terminal et le serveur applicatif légitime. Ce faisant, le serveur applicatif frauduleux accède au contenu des messages chiffrés.
La protection par un mot de passe de l'accès à l'interface d'administration du CPE (qui permet notamment de configurer les informations DNS dans le CPE) ne suffit pas à protéger le CPE des attaques décrites précédemment. En effet, comme la plupart des utilisateurs n'utilisent pas (voire ne soupçonnent même pas l'existence) d'interface d'administration du CPE, la protection de l'accès à cette interface d'administration est souvent faible. De même, la protection de l'accès à l'interface d'administration du CPE par adresse MAC (« Medium Access Control ») peut s'avérer inefficace car un attaquant peut changer l'adresse MAC de son terminal pour être identique à celle(s) autorisée(s) par le CPE. Ces adresses MAC peuvent en effet être acquises de façon malveillante en écoutant les échanges Wi-Fi, par exemple.
Il existe donc un besoin d'une nouvelle solution pour détecter une modification frauduleuse des informations de configuration DNS, et qui puisse notamment préserver la sécurité des données personnelles des utilisateurs.
3. Exposé de l'invention
L'invention propose une solution pour la détection d'un serveur de résolution de noms de domaine malveillant, mise en oeuvre dans un équipement configuré avec au moins un serveur de résolution de noms de domaine de confiance associé à au moins une interface réseau via laquelle ledit équipement est apte à communiquer.
Un tel équipement met en oeuvre : la transmission, à destination d'au moins un desdits serveurs de confiance, d'au moins une requête d'activation d'un service de vérification de résolution de noms de domaine, la réception d'au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, la transmission d'au moins une requête de résolution dudit au moins un nom de domaine, si aucune requête de résolution dudit au moins un nom de domaine n'est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, la réception d'au moins une notification invitant ledit équipement à engager une action.
La solution proposée permet ainsi à un équipement (par exemple un terminal, un CPE, etc.) d'engager une action si un serveur de confiance de résolution de noms de domaine, configuré pour au moins une interface réseau (par exemple Ethernet, Wireless LAN, etc.) de l'équipement, détecte une anomalie dans une requête de résolution de domaine spécifique émise via une interface de l'équipement.
Plus précisément, selon la solution proposée, le serveur de confiance peut générer un ou plusieurs noms de domaine spécifiques pour au moins une interface de l'équipement. Par exemple, un tel nom de domaine, noté par exemple « TARGET_HB_FQDN », peut être généré de façon aléatoire par le serveur de confiance. On considère donc qu'un tel nom de domaine est unique et que le serveur de confiance est identifié comme serveur autoritaire ou faisant autorité (appelé « authoritative server » en anglais) pour le nom de domaine ainsi généré. Le serveur de confiance peut transmettre à l'équipement le ou les noms de domaine générés pour au moins une de ses interfaces. De tels noms de domaine sont donc connus uniquement du serveur de confiance et de l'équipement. Le serveur de confiance peut alors détecter la présence d'un serveur malveillant si aucune requête de résolution de ce ou ces noms de domaine n'est reçue par lui, ou si une ou plusieurs requêtes de résolution de ce ou ces noms de domaine (appelées par exemple dans la suite « HB ») sont reçues mais comportent une anomalie (par exemple, l'adresse source de la requête de résolution du nom de domaine n'est pas une adresse de l'équipement).
Dans ce cas, une notification est envoyée par le serveur de confiance à l'équipement, afin que l'équipement puisse engager au moins une action permettant par exemple de corriger la configuration de résolution de noms de domaine active. Une telle action peut ainsi être exécutée automatiquement par l'équipement, sans intervention d'un utilisateur. De ce fait, quand bien même l'utilisateur n'aurait aucune connaissance technique des systèmes informatiques, les informations de configuration DNS de l'équipement peuvent être réinitialisées, ou le trafic vers ou en provenance d'un serveur applicatif malveillant être stoppé.
La solution proposée contribue ainsi à améliorer la robustesse des services IP à valeur ajoutée (services DNS inclus) et à préserver l'utilisateur d'attaques qui reposeraient sur un service de résolution de noms tel que le service DNS.
De plus, la solution proposée ne requiert pas d'inspection de trafic dans le réseau (par exemple dans le réseau d'accès) ou de profilage des communications pour la détection d'anomalies. La solution peut ainsi être mise en oeuvre indépendamment de l'offre de connectivité sous-jacente.
On note qu'un équipement selon l'invention peut embarquer un ou plusieurs « clients DNS ». En d'autres termes, un client DNS peut être supporté par le système d'exploitation (ou OS pour « Operating System » en anglais) d'un équipement, ou être spécifique à une application. Dans ce dernier cas, plusieurs clients DNS peuvent être activés sur un même équipement, chacun de ces clients étant identifié de façon univoque. Le procédé selon l'invention peut être mis en oeuvre par l'un de ces clients DNS ou être supporté par une application dédiée. Notamment, chaque client DNS d'un équipement peut mettre en oeuvre les étapes décrites ci-dessus. L'invention ne fait aucune hypothèse quant à l'interface interne utilisée entre une application et une fonction de résolution de noms (un client DNS, typiquement).
Selon un mode de réalisation particulier, ladite au moins une réponse comporte également des données de vérification (notées par exemple « CHALLENGE ») générées par ledit serveur de confiance pour ladite au moins une requête d'activation. Ladite au moins une requête de résolution dudit au moins un nom de domaine générée par l'équipement comporte alors une preuve d'intégrité obtenue à partir desdites données de vérification.
A réception d'une requête de résolution par le serveur de confiance, ce dernier peut ainsi vérifier l'intégrité de la requête de résolution grâce à la preuve d'intégrité, ce qui contribue à améliorer la sécurité de la solution proposée. Par exemple, la preuve d'intégrité est un condensé (encore appelé « hachage » ou « hash ») desdites données de vérification.
Dans un mode de réalisation particulier, ladite au moins une requête de résolution dudit au moins un nom de domaine comporte un indicateur requérant la génération, par ledit serveur de confiance, de nouvelles données de vérification.
Un tel changement des données de vérification contribue à renforcer la sécurité de la solution proposée.
L'équipement peut alors être à l'initiative d'un changement des données de vérification. Comme décrit par la suite avec la description d'un mode de réalisation particulier, l'équipement envoie par exemple une requête de résolution notée « HB (C, NONCE1) ».
En variante, c'est le serveur qui peut être à l'initiative d'un changement des données de vérification.
Un tel changement des données de vérification peut notamment être mis en oeuvre de façon régulière ou selon d'autres politiques locales au serveur de résolution de noms.
En particulier, ladite au moins une réponse et/ou ladite requête de résolution peuvent être chiffrées. Un tel chiffrement permet de préserver les données de vérification transmises dans la réponse à la requête d'activation (i.e. réponse du serveur de confiance vers l'équipement) ou la preuve d'intégrité transmise dans la requête de résolution « HB ».
Dans un mode de réalisation particulier, ladite au moins une réponse comporte également une information de récurrence (notée par exemple « EPOCH »). Ladite au moins une requête de résolution dudit au moins un nom de domaine est transmise en tenant compte de ladite information de récurrence.
Par exemple, l'information de récurrence prévoit la périodicité d'envoi des requêtes de résolution (« HB ») par l'équipement, l'envoi d'une requête de résolution au redémarrage de l'équipement, lors d'une connexion à un nouveau réseau, etc.
Dans un mode de réalisation particulier, ladite au moins une requête d'activation comporte au moins une adresse de contact dudit équipement (notée par exemple « CONTACT_URI »).
De cette façon, le serveur de confiance peut envoyer à l'équipement une notification vers cette adresse de contact pour informer l'équipement d'anomalie(s) constatée(s) dans la résolution de noms de domaine. On suppose que l'équipement met en place les procédures adéquates pour pouvoir recevoir ces messages (par exemple configuration d'un pare-feu, NAT). Ces procédures sont connues en soi et ne sont donc pas réitérées ici. Un exemple est notamment décrit dans le document RFC6887 « Port Control Protocol (PCP) » d'avril 2013. Selon un mode de réalisation particulier, les informations descriptives dudit au moins un serveur de confiance sont stockées dans un registre maintenu par ledit équipement et dont l'accès est protégé. On rappelle qu'il est classique de configurer au moins une liste d'au moins un serveur de confiance associé à au moins une interface d'un équipement. Selon l'invention, de telles informations de configuration (i.e. informations descriptives dudit au moins un serveur de confiance) sont stockées dans un registre spécifique, dont l'accès est protégé, par exemple par un mot de passe ou des clés de vérification. De cette façon, un attaquant n'a pas directement accès à ces informations de configuration, ce qui contribue à renforcer la sécurité de la solution proposée.
En particulier, le registre dont l'accès est protégé est distinct de tout autre registre utilisé pour le stockage d'autres informations relatives à la résolution de noms de domaine.
Notamment, l'emplacement de ce registre protégé n'est pas prédéfini, et peut être différent pour différents équipements. L'emplacement du registre peut notamment être choisi aléatoirement au moment de l'activation du service de vérification de résolution de noms de domaine.
Selon un mode de réalisation particulier, l'équipement étant configuré pour exécuter au moins une action, ledit équipement exécute au moins une action donnée (par exemple, préconfigurée) à réception d'une notification l'invitant à exécuter ladite au moins une action. Par exemple, ladite au moins une action appartient au groupe comprenant : remplacer la configuration de résolution de noms de domaine active par la configuration d'un desdits serveurs de confiance, désactiver les communications sortantes à l'exception des communications vers l'un desdits serveurs de confiance, générer une notification locale pour informer un utilisateur d'une modification de la configuration de résolution de noms de domaine, demander l'envoi de la configuration de résolution de noms de domaine active.
Notamment, de telles actions peuvent avoir été préalablement configurées pour l'équipement. Ainsi, à réception d'une notification, l'équipement connaît l'action qu'il doit exécuter. La solution proposée ne fait donc pas intervenir l'utilisateur pour la résolution des anomalies. L'utilisateur n'est donc pas censé disposer de connaissances techniques particulières pour la mise en oeuvre de l'invention.
L'invention concerne également un tel procédé de détection d'un serveur de résolution de noms de domaine malveillant, mis en oeuvre dans le serveur de confiance.
Un tel serveur de confiance met en oeuvre les étapes suivantes : la réception d'au moins une requête d'activation d'un service de vérification de résolution de noms de domaine, en provenance dudit équipement, la transmission d'au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, si aucune requête de résolution dudit au moins un nom de domaine n'est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, la transmission audit équipement d'au moins une notification l'invitant à exécuter une action.
Comme déjà indiqué, le serveur de confiance peut générer un ou plusieurs noms de domaine spécifiques pour au moins une interface de l'équipement et détecter un problème dans le service de vérification de résolution de noms de domaine si aucune requête de résolution du nom de domaine spécifique n'est reçue, ou si une requête de résolution du nom de domaine spécifique est reçue mais comporte une anomalie. Si un problème est détecté, le serveur de confiance peut envoyer une notification à au moins une adresse de contact dudit équipement portée par ladite requête d'activation ou à l'adresse utilisée par ledit équipement pour transmettre ladite requête d'activation. Ces vérifications sont rendues possibles du fait que le serveur de confiance fait autorité pour les noms de domaines générés pour au moins une interface d'un équipement.
Selon un mode de réalisation particulier, une anomalie est détectée si ladite au moins une requête de résolution dudit au moins un nom de domaine et si ladite au moins une requête d'activation ne proviennent pas du même équipement.
Par exemple, le serveur de confiance compare les adresses utilisées pour l'émission de la requête d'activation et pour l'émission de la requête de résolution dudit au moins un nom de domaine. Si elles diffèrent ou ne sont pas associées au même équipement, le serveur de confiance détecte une anomalie.
Selon un mode de réalisation particulier, ladite au moins une réponse comporte également des données de vérification générées par ledit serveur de confiance pour ladite au moins une requête d'activation. Dans ce cas, ladite au moins une requête de résolution dudit au moins un nom de domaine comporte une preuve d'intégrité obtenue à partir desdites données de vérification, et une anomalie est détectée si ladite preuve d'intégrité portée par ladite au moins une requête de résolution dudit au moins un nom de domaine n'est pas cohérente avec une preuve d'intégrité obtenue à partir des données de vérification connues du serveur de confiance.
Par exemple, le serveur de confiance génère de façon aléatoire des données de vérification, et les transmet dans sa réponse. L'équipement calcule un condensé de ces données de vérification, et le transmet dans la requête de résolution du nom de domaine spécifique. A réception, le serveur de confiance peut calculer localement un condensé des données de vérification qu'il connaît, et le comparer avec le condensé reçu dans la requête de résolution.
Selon un mode de réalisation particulier, ladite au moins une réponse comporte de nouvelles données de vérification générées par ledit serveur de confiance pour ledit équipement, à l'initiative dudit serveur de confiance ou à réception d'une requête en provenance dudit équipement.
Comme indiqué précédemment, les données de vérification peuvent effectivement être renouvelées à l'initiative de l'équipement ou du serveur de confiance, par exemple régulièrement, de façon à améliorer la sécurité de la solution proposée.
Selon un mode de réalisation particulier, ladite au moins une réponse comporte également une information de récurrence (notée par exemple « EPOCH ») de ladite au moins une requête de résolution dudit au moins un nom de domaine, et une anomalie est détectée si aucune requête de résolution dudit au moins un nom de domaine n'est reçue par ledit serveur de confiance ou si ladite au moins une requête de résolution dudit au moins un nom de domaine n'est pas cohérente avec ladite information de récurrence.
A nouveau, l'utilisation d'une telle information de récurrence contribue à renforcer la sécurité de la solution proposée.
Selon un mode de réalisation particulier, lesdites requêtes d'activation et/ou de résolution dudit au moins un nom de domaine utilisent une option selon le mécanisme DNS tel que décrit dans le document RFC 6891 (« Extension Mechanisms for DNS » (EDNS) d'avril 2013) pour transmettre différentes informations entre l'équipement et le serveur de confiance (par exemple un nom de domaine (« TARGET_HB_FQDN »), des données de vérification (« CHALLENGE »), des informations de récurrence (« EPOCH »), une adresse de contact (« CONTACT_URI »), etc.).
Dans un autre mode de réalisation, l'invention concerne un équipement correspondant. Un tel équipement est notamment adapté pour la mise en oeuvre d'un procédé de détection d'un serveur de résolution de noms de domaine malveillant selon au moins un mode de réalisation de l'invention. Ainsi, un tel équipement peut comporter les différentes caractéristiques relatives au procédé selon l'invention, qui peuvent être combinées ou prises isolément. Par exemple, l'équipement est de type CPE, terminal, etc. L'équipement peut être raccordé à un réseau fixe, un réseau mobile, un réseau d'objets connectés (par exemple un réseau maillé selon le protocole « Thread »), etc.
Dans un autre mode de réalisation, l'invention concerne un serveur de confiance correspondant. Un tel serveur de confiance est notamment adapté pour la mise en oeuvre d'un procédé de détection d'un serveur de résolution de noms de domaine malveillant selon au moins un mode de réalisation de l'invention. Ainsi, un tel serveur peut comporter les différentes caractéristiques relatives au procédé selon l'invention, qui peuvent être combinées ou prises isolément.
Dans encore un autre mode de réalisation, l'invention concerne un ou plusieurs programmes d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé de détection d'un serveur de résolution de noms de domaine malveillant selon au moins un mode de réalisation de l'invention, lorsque ce ou ces programmes est/sont exécuté(s) par un processeur.
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.
En particulier, le procédé selon l'invention peut être implémenté par un module générique, une application, etc.
4. Liste des figures
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 illustre les principales étapes d'un procédé de détection d'un serveur de résolution de noms de domaine malveillant selon un mode de réalisation, la figure 2 présente le format générique d'une option WADE selon un mode de réalisation, la figure 3 présente un exemple d'option WADE selon un mode de réalisation, la figure 4 illustre un exemple de messages échangés entre un client DNS et un serveur de confiance sans détection d'anomalie, la figure 5 illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec modification des données de vérification à l'initiative du client DNS, la figure 6 illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec modification des données de vérification à l'initiative du serveur de confiance, la figure 7 illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec détection d'une anomalie de type non-respect de l'information de récurrence, la figure 8 illustre un exemple de messages échangés entre un client DNS et un serveur de confiance avec détection d'une anomalie liée à l'adresse source, la figure 9 illustre un exemple de messages échangés entre un client DNS et un serveur de confiance pour la désactivation d'un service de vérification de résolution de noms de domaine, et la figure 10 présente la structure simplifiée d'un équipement, respectivement d'un serveur de confiance, selon un mode de réalisation.
5. Description d'un mode de réalisation de l'invention 5.1 Principe général
On se place dans le contexte d'un équipement (par exemple un terminal, un CPE) configuré avec des informations descriptives d'au moins un serveur de confiance de résolution de noms de domaine associé à une interface réseau via laquelle l'équipement est apte à communiquer.
Le principe général de l'invention repose sur la génération, par le serveur de confiance, d'au moins un nom de domaine spécifique pour au moins une interface de l'équipement et la mise en place d'une procédure d'émission de requêtes de résolution liées à ce nom de domaine spécifique. Le serveur de confiance peut ainsi détecter un problème dans un service de résolution de noms de domaine s'il ne reçoit aucune requête de résolution du nom de domaine spécifique, ou si une requête de résolution du nom de domaine spécifique qu'il reçoit comporte une anomalie. Le serveur de confiance peut alors informer l'équipement, qui peut dès lors engager des actions adéquates.
On présente, en relation avec la figure 1, les principales étapes mises en oeuvre pour la détection d'un serveur de résolution de noms de domaine malveillant selon l'invention.
On considère un équipement H 11 configuré avec au moins un serveur de confiance de résolution de noms de domaine DNS 12 associé à au moins une interface réseau via laquelle l'équipement est apte à communiquer.
Au cours d'une première étape 111, l'équipement 11 transmet au serveur de confiance 12, via au moins une interface réseau, au moins une requête d'activation ACTIV d'un service de vérification de résolution de noms de domaine. Le serveur de confiance 12 reçoit ladite au moins une requête d'activation ACTIV au cours d'une étape 121.
La requête d'activation peut notamment être une requête dédiée, telle qu'une requête DNS réservée à l'activation du service de vérification de résolution de noms de domaine. Un exemple d'une telle requête dédiée est une requête de résolution d'un nom de domaine dédié, apte à déclencher l'activation du service de vérification. Ce nom de domaine dédié peut être un nom configuré lors de la souscription au service (par exemple « peraspera. example ») ou un nom de domaine réservé à cet usage et qui peut être utilisé par tous les opérateurs (par exemple « peraspera. arpa »).
En variante, la requête d'activation peut être une requête « non dédiée ». Dans ce cas, l'équipement ne génère pas une requête DNS portant sur un nom de domaine dédié à l'activation du service de vérification de résolution de noms de domaine, mais utilise une requête DNS classique, par exemple une requête DNS émise pour les besoins d'une application embarquée dans l'équipement, et y insère des informations pour l'activation du service de résolution de noms de domaine. On détourne ainsi une requête DNS classique en y insérant des informations particulières, par exemple sous la forme d'une nouvelle option selon un mécanisme d'extension DNS tel que décrit ci-après. Le serveur de confiance 12 peut générer au moins un nom de domaine spécifique pour l'interface réseau utilisée, et transmettre à l'équipement 11 au moins une réponse comportant le ou les noms de domaine spécifiques, au cours d'une étape 122. On considère qu'un tel nom de domaine est unique et que le serveur de confiance fait autorité pour le nom de domaine ainsi généré. Selon l'exemple illustré par la figure 1, le serveur de confiance transmet une seule réponse REP portant un nom de domaine unique. L'équipement 11 reçoit la réponse REP au cours d'une étape 112.
L'équipement 11 peut alors transmettre au serveur de confiance 12 au moins une requête de résolution du nom de domaine unique REQ DNS au cours d'une étape 113. Une telle requête de résolution portant sur le nom de domaine unique est par la suite également appelée HB (« Heartbeat » en anglais).
Si le serveur de confiance 12 reçoit une requête REQ DNS au cours d'une étape 123, mais que cette requête REQ DNS comporte une anomalie, le serveur de confiance 12 envoie une notification NOTIF à l'équipement 11 au cours d'une étape 124, l'invitant à exécuter une action.
Si le serveur de confiance 12 ne reçoit aucune requête REQ DNS portant sur le nom de domaine unique communiqué à l'équipement 11 lors de l'activation de la procédure (étapes 122/112), le serveur de confiance 12 envoie une notification NOTIF à l'équipement 11 l'invitant à exécuter une action, par exemple après une période d'attente. La période d'attente peut notamment être prédéfinie, configurée dans le serveur de confiance, connue de l'équipement ou transmise à l'équipement, etc.
L'équipement 11 peut ainsi recevoir, au cours d'un étape 114, une notification NOTIF l'invitant à exécuter une action, par exemple une action prédéfinie. L'équipement peut ensuite exécuter une telle action, sans nécessiter d'interaction avec un utilisateur de l'équipement ou un administrateur d'un réseau local (par exemple administrateur d'un réseau domestique, administrateur d'un CPE).
Comme décrit par la suite, différentes informations peuvent être utilisées par le serveur de confiance pour détecter une anomalie lors du traitement d'une requête de résolution de noms de domaine. Notamment, des données de vérification et/ou une information de récurrence peuvent être transmises dans la réponse REP du serveur de confiance vers l'équipement, et utilisées par l'équipement pour la gestion de la transmission de la requête de résolution du nom de domaine unique REQ DNS vers le serveur de confiance. Une anomalie peut notamment être détectée si la requête d'activation ACTIV et la requête de résolution du nom de domaine unique REQ DNS ne proviennent pas du même équipement, ou si une preuve d'intégrité, obtenue à partir des données de vérification et véhiculée par la requête REQ DNS, n'est pas cohérente avec une preuve d'intégrité obtenue à partir des données de vérification connues du et maintenues localement par le serveur de confiance, ou si l'émission de la ou des requêtes REQ DNS n'est pas conforme à l'information de récurrence, ou si la requête REQ DNS inclut une information d'un relais DNS, par exemple.
5.2 Description détaillée d'un mode particulier de réalisation
5.2.1 Configuration initiale
On décrit ci-après un exemple détaillé de mise en oeuvre de l'invention. On considère qu'un utilisateur de l'équipement (par exemple un terminal) souhaite activer un service de vérification de résolution de noms de domaine. Par la suite, on nomme un tel service « PER ASPERA » (« PER-DNS client guards Against malicious DNS Server swapping, traffic intERception, and datA theft », ou « procédure de détection et de mitigation de changement de configuration DNS »).
Par exemple, l'utilisateur peut souscrire au service PER ASPERA en utilisant une interface dédiée. Le service PER ASPERA peut notamment être fourni à des terminaux directement connectés au réseau d'un fournisseur de service ou réservé à des offres qui reposent sur la fourniture d'un CPE. Comme déjà indiqué, on dénote par « équipement » un terminal ou un CPE utilisé par un utilisateur souhaitant profiter du service PER ASPERA. On note que le service PER ASPERA peut être proposé par un fournisseur de service de connectivité, un fournisseur de service DNS, etc. En particulier, un utilisateur peut solliciter un fournisseur de service DNS distinct du fournisseur qui lui fournit la connectivité. L'équipement de l'utilisateur peut se connecter à plusieurs réseaux en utilisant un même équipement d'accès ou des équipements différents. L'équipement de l'utilisateur peut utiliser un même service DNS pour l'ensemble des réseaux d'accès (fixes et mobiles) auxquels il peut se connecter. Le service PER ASPERA peut être proposé indépendamment de la nature du ou des réseau(x) d'accès utilisé(s) par l'équipement de l'utilisateur. De plus, le serveur PER ASPERA peut n'être utilisé que pour une partie des interfaces.
De façon classique, l'équipement, ou au moins une interface réseau de l'équipement, est configurée avec au moins une liste d'au moins un serveur DNS de confiance. Afin d'améliorer la sécurité de la solution proposée, les connexions entre l'équipement et le ou les serveurs de confiance sont, dans le mode de réalisation décrit ici, sécurisées. Ainsi, le ou les serveurs de confiance peuvent supporter au moins un schéma de chiffrement reposant par exemple sur l'utilisation de l'un ou l'autre des protocoles suivants : DNS over TLS (DoT), DNS over DTLS (DoD), DNS over HTTPS (DoH), DNS over QUIC (DoQ), DNS over CoAP (DoC), etc.
La configuration de la ou des listes d'au moins un serveur de confiance peut être réalisée en utilisant un mécanisme reposant sur une découverte des résolveurs désignés par leurs voisins (DNR, « Discovery of Neighbor-designated Resolvers », tel que décrit dans le document « DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) » d'août 2022, un mécanisme basé sur un échange de clés (IKE, « Internet Key Exchange », tel que décrit dans le document « Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS » de septembre 2022), etc. Si l'équipement dispose de plusieurs interfaces réseau, au moins une liste d'au moins un serveur de confiance peut être configurée par interface réseau (filaire, sans fil, 5G, etc.). Dans ce cas, une liste d'au moins un serveur de confiance peut être associée à un identifiant de l'interface réseau concernée.
Selon un mode de réalisation particulier, l'équipement peut également être configuré avec au moins une action. Par exemple, l'équipement est configuré avec une liste indexée d'actions prédéfinies. Une telle liste peut contenir les actions suivantes (non-exhaustive) : index de politique / d'action « 0 » : remplacer la configuration de résolution de noms de domaine active par la configuration d'un des serveurs de confiance, index de politique / d'action « 1 » : désactiver les communications sortantes à l'exception des communications vers l'un des serveurs de confiance pour une interface donnée, index de politique / d'action « 2 » : générer une notification locale pour informer l'utilisateur d'une modification de la configuration de résolution de noms de domaine, index de politique / d'action « 3 » : demander l'envoi de la configuration de résolution de noms de domaine active, etc.
Selon un mode de réalisation particulier, les informations descriptives du ou des serveurs de confiance (i.e. la configuration de la ou des listes d'au moins un serveur de confiance) sont stockées dans un registre maintenu par l'équipement et dont l'accès est protégé. L'accès à ce registre peut notamment mettre en oeuvre des mécanismes d'authentification forte (par exemple, par l'utilisation d'un mot de passe dédié ou des clés de vérification à plusieurs niveaux). L'emplacement d'un tel registre peut notamment être décidé lors de l'activation du service PER ASPERA. Le registre peut correspondre à des entrées dédiées dans une base de registre Windows©, un fichier, une base de données, etc.
En particulier, un tel registre est distinct de tout autre registre utilisé pour le stockage d'autres informations relatives à la résolution de noms de domaine. Le registre où sont stockées la ou les listes d'au moins un serveur de confiance est donc isolé des autres registres utilisés pour le stockage des informations exploitées pour la gestion DNS.
Éventuellement, les informations descriptives du ou des serveurs de confiance peuvent être dupliquées pour être d'une part stockées dans le registre dont l'accès est protégé, d'autre part dans un registre classiquement utilisé pour le stockage d'informations relatives à la résolution de noms de domaine. Cette isolation a pour objectif d'éviter la modification de la liste des serveurs DNS de confiance par une application malveillante ou à la suite d'un accès frauduleux à l'équipement.
Concrètement, une application qui accède à la configuration DNS locale sans consentement de l'utilisateur peut éventuellement modifier la configuration DNS active, mais ne peut pas modifier la configuration des serveurs de confiance stockée dans le registre dont l'accès est protégé.
5.2.2 Activation du service PER ASPERA
Par la suite, on utilise le terme « client DNS » pour désigner l'équipement ou au moins une interface réseau de l'équipement mettant en oeuvre la solution proposée.
Comme décrit dans la figure 1, au cours d'une première étape 111, un client DNS transmet à au moins un de ses serveurs de confiance au moins une requête DNS d'activation du service PER ASPERA.
Comme déjà indiqué, cette requête d'activation peut être dédiée à l'activation du service de vérification de résolution de noms de domaine. Dans ce cas, la requête d'activation est une requête DNS réservée au service PER ASPERA. En variante, la requête d'activation peut être non dédiée, notamment lorsque des requêtes conventionnelles sont utilisées pour les besoins des applications d'usage. Dans ce cas, le client DNS utilise une requête émise par exemple par une application embarquée dans l'équipement en insérant les informations requises pour l'activation du service PER ASPERA.
On note que si un même serveur de confiance est associé à plusieurs interfaces de l'équipement, une requête d'activation par interface peut être envoyée ; chacune de ces requêtes est acheminée vers le serveur de confiance via l'interface concernée. En effet, l'envoi de ces différentes requêtes par interface permet de communiquer à un serveur de confiance l'adresse externe de l'équipement (client DNS) qui le rend joignable via cette interface.
Si plusieurs listes de serveurs de confiance sont configurées, alors une requête d'activation est envoyée vers chacune de ces listes, i.e. vers au moins un serveur de confiance de chacune des listes. Ceci permet en particulier de contrôler l'activité DNS pour l'ensemble des interfaces d'un équipement lorsque celles-ci sont associées à des serveurs de confiance différents.
Selon un mode de réalisation de l'invention, la ou les requêtes d'activation utilisent une nouvelle option selon le mécanisme EDNS . Une telle option est nommée ci-après WADE (« An EDNS Option for WAtching DNS associations to prevent swapping, interception, and theft »). L'identification d'une requête étendue selon le mécanisme EDNS est réalisée grâce à un pseudo « resource-record » (RR) OPT.
Le format générique de l'option WADE est illustré dans la figure 2. Comme illustré par la figure 2, le champ de données « OPTION-DATA » du RR OPT prévoit six indicateurs de contrôle, par exemple sous la forme de 6 bits H, N, C, T, E, U : le bit H, aussi appelé « HB_ENABLE » (pour « Heartbeat Enable » en anglais), positionné à la valeur « 1 » indique une demande d'activation du service PER ASPERA, alors que la valeur « 0 » est utilisée pour désactiver le service PER ASPERA, le bit N positionné à la valeur « 1 » indique la présence du champ « NONCE », le bit C positionné à la valeur « 1 » indique la présence du champ « CHALLENGE », le bit T positionné à la valeur « 1 » indique la présence du champ « TARGET_HB_FQDN », le bit E positionné à la valeur « 1 » indique la présence du champ « EPOCH », le bit U positionné à la valeur « 1 » indique la présence du champ « CONTACT_URI ».
Ces différents champs (« NONCE », « CHALLENGE », « TARGET_HB_FQDN », « EPOCH », « CONTACTJJRI ») sont présentés par la suite. En particulier, les champs « CHALLENGE », « TARGET_HB_FQDN », et « EPOCH » sont renseignés par un serveur de confiance.
Quand plusieurs de ces champs sont transportés dans une même option WADE, alors ces différents champs sont insérés selon l'ordre des bits de contrôle. Les paramètres variables sont précédés par un champ qui renseigne la taille du paramètre.
Une requête d'activation incluant l'option WADE, telle qu'illustrée par la figure 3, utilise le bit H et éventuellement le bit U, positionnés à la valeur « 1 ». Les autres bits (N, C, T, et E) peuvent être positionnés à la valeur « 0 ».
Ainsi, le bit H peut prendre une valeur « 1 » pour indiquer une demande d'activation du service PER ASPERA. Le bit « U » peut également prendre une valeur « 1 » pour indiquer la présence du champ « CONTACTJJRI ». Un champ « URI_Length » peut notamment être prévu pour renseigner la taille du paramètre présent dans le champ « CONTACT_URI », comme illustré par la figure 3.
Un tel champ « CONTACTJJRI » peut être présent dans une requête d'activation du service PER ASPERA. Ce champ liste le ou les identifiants de contact que le serveur de confiance (qui reçoit la requête d'activation) peut utiliser pour rendre compte d'anomalies constatées dans les informations de configuration DNS (par exemple en transmettant au client DNS une notification l'invitant à engager une action).
Si le bit U est positionné à la valeur « 1 », i.e. si le champ « CONTACT_URI » est présent, cela signifie que la ou les adresses de contact pour l'envoi des notifications sont celles renseignées dans le champ « CONTACTJJRI ». Si le bit U est positionné à la valeur « 0 », i.e. si le champ « CONTACT_URI » n'est pas présent, cela signifie que l'adresse de contact pour l'envoi des notifications est l'adresse (ainsi que le numéro de port) utilisée par le client DNS pour envoyer cette requête d'activation.
On note que le service PER ASPERA peut être désactivé à tout moment par un équipement. Pour ce faire, une requête qui contient l'option WADE peut être envoyée du client DNS vers un serveur de confiance, en utilisant le bit H positionné à la valeur « 0 ». Dans la suite, on suppose que le service est activé.
On note qu'une telle option WADE n'est insérée que dans une requête DNS destinée à un serveur de confiance. Cette vérification repose par exemple sur l'adresse IP destination de la requête DNS ou l'ADN (« Authentication Domain Name ») du serveur DNS cible.
5.2.3 Réponse du serveur de confiance
Comme indiqué en relation avec la figure 1, au moins un serveur de confiance reçoit au moins une requête d'activation du service PER ASPERA au cours d'une étape 121.
Si un serveur de confiance ne supporte pas l'option WADE, alors il peut répondre avec un message d'erreur. Le client DNS peut éventuellement sélectionner un autre serveur de confiance configuré dans sa liste, envoyer une requête d'activation vers le même serveur mais sans l'option WADE, mettre fin à la communication et générer une notification locale (application, utilisateur, etc.), etc.
Si un serveur de confiance supporte l'option WADE, alors il peut traiter la requête d'activation reçue. Notamment, le serveur de confiance peut extraire les informations communiquées dans l'option WADE, notamment dans le champ « CONTACT_URI » le cas échéant. Par exemple, le serveur de confiance peut extraire une adresse IP et un numéro de port source de la requête d'activation. Ces informations peuvent être stockées pour être ré-utilisées par la suite. Un serveur de confiance peut ainsi maintenir une ou plusieurs adresses sources par client DNS.
Le serveur de confiance peut notamment préparer au moins une réponse et la transmettre au client DNS au cours de l'étape 122 de la figure 1. Une telle réponse peut notamment prendre la forme d'une requête DNS qui inclut l'option WADE telle qu'illustrée par la figure 2.
En particulier, une telle réponse incluant l'option WADE utilise les bits H et T, et éventuellement les bits C et E, positionnés à la valeur « 1 ». Les autres bits (U, N) peuvent être positionnés à la valeur « 0 ». Ainsi, le bit H peut être valorisé à « 1 » pour indiquer l'acceptation d'une demande d'activation du service PER ASPERA.
Le bit T peut également être valorisé à « 1 » pour indiquer la présence du champ « TARGET_HB_FQDN ». Un champ « TARGET_HB_FQDN_Length » peut notamment être prévu pour renseigner la taille du paramètre présent dans le champ « TARGET_HB_FQDN ». Un tel champ « TARGET_HB_FQDN » comporte un ou plusieurs noms de domaine spécifiques générés par le serveur de confiance pour le client DNS considéré. Le serveur de confiance fait autorité pour ces noms de domaine. Ils sont donc considérés comme uniques, et connus uniquement du client DNS et du serveur de confiance. Pour ce faire, ils sont générés de façon aléatoire par exemple.
Éventuellement, le bit C peut prendre une valeur « 1 » pour indiquer la présence d'un champ « CHALLENGE ». Un champ « CHALLENGE_Length » peut notamment être prévu pour renseigner la taille du paramètre présent dans le champ « CHALLENGE ».
Un tel champ « CHALLENGE » comporte des données de vérification qui peuvent être utilisées par le client DNS pour déterminer une preuve d'intégrité. Par exemple, de telles données de vérification peuvent être générées aléatoirement et utilisées par le client DNS pour calculer une preuve d'intégrité, telle qu'un condensé (« hash » en anglais). Une telle preuve intégrité peut ensuite être insérée par le client DNS dans les requêtes DNS ultérieures destinées au serveur de confiance.
Éventuellement, le bit E peut prendre une valeur « 1 » pour indiquer la présence d'un champ « EPOCH ». Un champ « EPOCHJength » peut notamment être prévu pour renseigner la taille du paramètre présent dans le champ « EPOCH ».
Un tel champ « EPOCH » comporte une information de récurrence, utilisée par le client DNS pour transmettre les requêtes de résolution de noms de domaine « HB ». Par exemple, un tel champ indique la périodicité des requêtes HB par le client DNS.
Si les champs « EPOCH » et « CHALLENGE » sont activés, les bits C, T, E sont positionnés à la valeur « 1 » et les bits U et N sont positionnés à la valeur « 0 ».
En particulier, le serveur de confiance peut stocker les informations communiquées à chaque client DNS.
Dans un mode de réalisation particulier, le serveur de confiance peut contrôler le champ TTL (« Time To Live ») des réponses pour forcer le client DNS à renouveler l'activation du service PER ASPERA en renvoyant une requête d'activation.
5.2.4 Requête de résolution du nom de domaine du champ TARGET_HB_FQDN
Comme indiqué en relation avec la figure 1, le client DNS reçoit une réponse du serveur de confiance au cours d'une étape 112.
Le client DNS peut extraire les informations contenues dans l'option WADE, notamment dans le champ « TARGET_HB_FQDN ». Si des informations sont présentes dans les champs « EPOCH » et/ou « CHALLENGE », ces informations peuvent également être extraites. Le client DNS peut stocker ces informations, en association avec au moins un serveur de confiance et au moins une interface. Plusieurs réponses qui contiennent l'option WADE peuvent être envoyées au client DNS par un serveur de confiance. Toutes ces informations peuvent être stockées par le client DNS dans un registre approprié, dont l'accès peut être protégé.
Comme illustré par la figure 1, le client DNS peut alors émettre une requête de résolution du nom de domaine présent dans le champ « TARGET_HB_FQDN » au cours d'une étape 113. Une telle requête peut notamment prendre la forme d'une requête DNS avec option WADE telle qu'illustrée par la figure 2. En particulier, une telle requête qui contient l'option WADE peut utiliser les bits H et N positionnés à la valeur « 1 ». Les autres bits (C, T, E et U) peuvent être positionnés à la valeur « 0 ».
Le bit N peut être valorisé à « 1 » pour indiquer la présence du champ « NONCE ». Un champ « NONCE_Length » peut notamment être prévu pour renseigner la taille du paramètre présent dans le champ « NONCE ».
Un tel champ « NONCE » comporte par exemple une preuve d'intégrité générée à partir des données de vérification transmises dans le champ « CHALLENGE ».
La figure 4 illustre un exemple de messages échangés entre un client DNS 41 et un serveur DNS de confiance 42.
A titre d'exemple, on considère que le client DNS 41 émet une requête d'activation en utilisant son adresse @1 comme adresse source, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE ». A l'issue de ces étapes de réception d'au moins une requête d'activation et de construction d'au moins une réponse (notées Activ. PER APSERA 411), le serveur de confiance 42 dispose des informations contenues dans les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE », et de l'adresse source de la requête d'activation (@1).
Selon l'exemple considéré, le client DNS 41 peut notamment émettre une ou plusieurs requêtes DNS pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », notées HB, en tenant compte de la valeur indiquée dans le champ « EPOCH » de la réponse reçue. Par exemple, le champ « EPOCH » comporte une information de récurrence indiquant une périodicité d'envoi Tl des requêtes HB. Ainsi, une première requête HB pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » peut être émise à l'instant T0+T1, une deuxième requête HB pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » peut être émise à l'instant TO+2*T1, une troisième requête HB pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » peut être émise à l'instant TO+3*T1, etc.
De telles requêtes HB (« HeartBeat ») permettent de signaler au serveur de confiance 42 la présence d'une association active avec un client DNS 41. Selon l'exemple considéré, le client DNS 41 peut notamment calculer un condensé des données de vérification véhiculées dans le champ « CHALLENGE » de la réponse reçue lors de la phase d'activation PER ASPERA. Un tel condensé peut notamment être inséré dans le champ « NONCE » de la requête HB qui contient l'option WADE.
Selon l'exemple illustré par la figure 4, le client DNS 41 émet une première requête HB (412) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d'intégrité dans le champ « NONCE », à l'instant T0+T1. A réception de la première requête HB (412), le serveur de confiance 42 peut notamment vérifier que l'adresse source de la requête d'activation (@1) et l'adresse source de la première requête HB (src@) sont cohérentes, i.e. permettent d'identifier le même équipement (src@=@l). Si ce n'est pas le cas, une anomalie est détectée. Le serveur de confiance 42 peut également vérifier que la preuve d'intégrité contenue dans le champ « NONCE » de la requête HB est cohérente avec une preuve d'intégrité déterminée localement à partir des données de vérification stockées par le serveur de confiance 42 (telles que consignées dans le champ « CHALLENGE » dans la réponse émise par le serveur de confiance). Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (par exemple procéder au calcul « Hash (CHALLENGE) » où Hash désigne une fonction de hachage correspondant à celle appliquée par le client DNS 41 pour générer le condensé des données de vérification (par exemple « Secure Hash Algorithms (SHAs) » décrits dans le document RFC 6234 « US Secure Hash Algorithms (SHA and SHA- based HMAC and HKDF) » de mai 2011) et vérifier qu'il est égal au condensé transmis dans le champ « NONCE ». Si ce n'est pas le cas, une anomalie est détectée par le serveur de confiance 42. Le serveur de confiance 42 peut également vérifier si l'information de récurrence spécifiée dans le champ « EPOCH » est respectée. Si ce n'est pas le cas, une anomalie est détectée. En variante, l'indication de la fonction « hash » à utiliser par un client DNS peut être communiquée à l'aide de l'option WADE. Pour ce faire, un bit « I » est défini à cet effet parmi les bits « unassigned » décrits dans la figure 2. Quand le bit « I » est positionné à « 1 », l'identité de la fonction « hash » est renseignée dans le corps de l'option WADE (par exemple SHA2-256).
Le client DNS 41 peut ensuite émettre une deuxième requête HB (413) pour la résolution du nom de domaine indiqué dans le champ TARGET_HB_FQDN, comportant une preuve d'intégrité dans le champ NONCE, à l'instant T0+2T1. Le serveur de confiance 42 peut notamment vérifier que l'adresse source de la requête d'activation (@1) et l'adresse source de la deuxième requête HB (src@) sont cohérentes (src@=@l), que le condensé des données de vérification (Hash (CHALLENGE)) est égal au condensé transmis dans le champ NONCE et que l'information de récurrence contenue dans le champ « EPOCH » est respectée. Le client DNS 41 peut émettre une troisième requête HB (414) et ainsi de suite.
Dans l'exemple illustré par la figure 4, aucune anomalie n'est détectée.
Dans un mode de réalisation particulier, les informations communiquées lors de l'activation du service PER ASPERA peuvent être modifiées à l'initiative du serveur de confiance 42 ou du client DNS 41.
La figure 5 illustre un exemple de messages échangés entre le client DNS 41 et le serveur de confiance 42, avec une demande de modification des données de vérification à l'initiative du client DNS 41.
On considère par exemple que le client DNS 41 émet une requête d'activation en utilisant son adresse @1, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGEl » (Activ. PER APSERA 511).
Selon l'exemple illustré par la figure 5, le client DNS 41 émet une première requête HB (512) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d'intégrité dans le champ « NONCE1 », à l'instant T0+T1. A réception de la première requête HB (512), le serveur de confiance 42 peut notamment vérifier que l'adresse source de la requête d'activation (@1) et l'adresse source de la première requête HB (src@) sont cohérentes. Le serveur de confiance 42 peut également vérifier que la preuve d'intégrité contenue dans le champ « NONCE1 » de la requête HB est cohérente avec une preuve d'intégrité déterminée localement à partir des données de vérification portées par le champ « CHALLENGEl ». Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (Hash (CHALLENGEl)) et vérifier qu'il est égal au condensé transmis dans le champ « NONCE1 ». Le serveur de confiance 42 peut également vérifier si l'information de récurrence spécifiée dans le champ « EPOCH » est respectée.
Le client DNS 41 peut demander à tout moment de modifier les données de vérification (« CHALLENGEl »). Pour ce faire, le client DNS peut envoyer une deuxième requête HB (513) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » comportant une preuve d'intégrité dans le champ « NONCE1 », calculé sur la base des données de vérification du champ « CHALLENGEl ». Pour informer le serveur de confiance 42 que le client DNS 41 demande de nouvelles données de vérification, les bits C et N sont positionnés à « 1 ».
A réception de ce message, le serveur de confiance 42 peut accepter la demande et générer de nouvelles données de vérification, qui sont transmises au client DNS 41 dans une réponse qui contient l'option WADE, dans le champ « CHALLENGE2 » (514).
Le client DNS 41 peut émettre une troisième requête HB (515) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d'intégrité dans le champ « NONCE2 », à l'instant T0+2T1. Une telle preuve d'intégrité est obtenue à partir des nouvelles données de vérification « CHALLENGE2 ». A réception de la troisième requête HB (515), le serveur de confiance 42 peut notamment vérifier que l'adresse source de la requête d'activation (@1) et l'adresse source de la troisième requête HB (src@) sont cohérentes, i.e. permettent d'identifier le même équipement (src@=@l). Le serveur de confiance 42 peut également vérifier que la preuve d'intégrité contenue dans le champ « NONCE2 » de la requête HB est cohérente avec une preuve d'intégrité déterminée localement à partir des nouvelles données de vérification stockées par le serveur de confiance 42 (telles que contenues dans le champ « CHALLENGE2 » de la réponse émise par le serveur de confiance). Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (Hash (CHALLENGE2)) et vérifier qu'il est égal au condensé contenu dans le champ « NONCE2 ». Le serveur de confiance 42 peut également vérifier si l'information de récurrence contenue dans le champ « EPOCH » est respectée.
Le client DNS 41 peut émettre une quatrième requête HB (516) et ainsi de suite.
La figure 6 illustre un exemple de messages échangés entre le client DNS 41 et le serveur de confiance 42, avec une demande de modification des données de vérification à l'initiative du serveur de confiance 42.
On considère par exemple que le client DNS 41 émet une requête d'activation en utilisant son adresse @1, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGEl » (Activ. PER APSERA 611).
Selon l'exemple illustré par la figure 6, le client DNS 41 émet une première requête HB (612) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d'intégrité dans le champ « NONCE1 », à l'instant T0+T1. A réception de la première requête HB (612), le serveur de confiance 42 peut notamment vérifier que l'adresse source de la requête d'activation (@1) et l'adresse source de la première requête HB (src@) sont cohérentes. Le serveur de confiance 42 peut également vérifier que la preuve d'intégrité spécifiée dans le champ « NONCE1 » de la requête HB est cohérente avec une preuve d'intégrité déterminée à partir des données de vérification consignées dans le champ « CHALLENGEl ». Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (Hash (CHALLENGEl)) et vérifier qu'il est égal au condensé consigné dans le champ « NONCE1 ». Le serveur de confiance 42 peut également vérifier si l'information de récurrence contenue dans le champ « EPOCH » est respectée.
Le serveur de confiance 42 peut décider à tout moment de modifier les données de vérification (« CHALLENGEl »).
Par exemple, à réception d'une deuxième requête HB (613) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » comportant une preuve d'intégrité consignée dans le champ « NONCE1 », calculé sur la base des données de vérification du champ « CHALLENGEl », le serveur de confiance 42 peut générer de nouvelles données de vérification. Le serveur de confiance 42 peut transmettre les nouvelles données de vérification au client DNS 41 dans une réponse qui contient l'option WADE, consignée dans le champ « CHALLENGE2 » (614). Pour informer le client DNS 41 que le serveur de confiance 42 a généré de nouvelles données de vérification qui sont transmises dans le champ « CHALLENGE2 », le bit C est positionné à « 1 ».
Le client DNS 41 peut émettre une troisième requête HB (615) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d'intégrité contenue dans le champ « NONCE2 », à l'instant T0+2T1. Une telle preuve d'intégrité est obtenue à partir des nouvelles données de vérification « CHALLENGE2 ». A réception de la troisième requête HB (615), le serveur de confiance 42 peut notamment vérifier que l'adresse source de la requête d'activation (@1) et l'adresse source de la troisième requête HB (src@) sont cohérentes, i.e. permettent d'identifier le même équipement (src@=@l). Le serveur de confiance 42 peut également vérifier que la preuve d'intégrité consignée dans le champ « NONCE2 » de la requête HB est cohérente avec une preuve d'intégrité déterminée localement à partir des nouvelles données de vérification stockées par le serveur de confiance 42 (telles que contenues par le champ « CHALLENGE2 » dans la réponse émise par le serveur de confiance). Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (Hash (CHALLENGE2)) et vérifier qu'il est égal au condensé transmis dans le champ « NONCE2 ». Le serveur de confiance 42 peut également vérifier si l'information de récurrence contenue dans le champ « EPOCH » est respectée.
Le client DNS 41 peut émettre une quatrième requête HB (616) et ainsi de suite.
Par exemple, le serveur de confiance 42 peut modifier les données de vérification à fréquence régulière pour des besoins de sécurité.
On présente désormais, en relation avec la figure 7, la détection d'une anomalie lorsque l'information de récurrence contenue dans le champ « EPOCH » n'est pas respectée.
La figure 7 illustre un exemple de messages échangés entre le client DNS 41 et le serveur de confiance 42. On considère par exemple que le client DNS 41 émet une requête d'activation en utilisant son adresse @1, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE » (Activ. PER APSERA 711).
Selon l'exemple illustré par la figure 7, le client DNS 41 émet une première requête HB (712) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d'intégrité consignée dans le champ « NONCE ». A réception de la première requête HB (712), le serveur de confiance 42 peut notamment vérifier que l'adresse source de la requête d'activation (@1) et l'adresse source de la première requête HB (src@) sont cohérentes. Le serveur de confiance 42 peut également vérifier que la preuve d'intégrité contenue dans le champ « NONCE » de la requête HB est cohérente avec une preuve d'intégrité déterminée localement à partir des données de vérification contenues dans le champ « CHALLENGE ». Le serveur de confiance 42 peut également vérifier si l'information de récurrence consignée dans le champ « EPOCH » est respectée.
Le serveur de confiance 42 constate qu'il ne reçoit pas de requête HB aux instants TO + Tl, TO + 2T1 et TO + 3T1 par exemple. Il détecte donc que l'information de récurrence contenue dans le champ « EPOCH » (récurrence des requêtes avec une périodicité Tl) n'est pas respectée, et émet au moins une notification invitant le client DNS 41 à engager une action.
Par exemple, un ou plusieurs messages de notification 713 sont envoyés vers l'adresse renseignée dans le champ « CONTACT_URI » pour le client DNS 41, ou vers l'adresse utilisée par le client DNS 41 pour envoyer la requête d'activation.
Par exemple, un message de notification peut être de type Push HTTPS, Update DNS, etc. Un tel message peut notamment comporter un index correspondant à une action donnée, par exemple préconfigurée. Par exemple, si un message de notification comporte un index égal à 0 (Notif. (Action = 0)), le client DNS engage une action de type remplacement de la configuration de résolution de noms de domaine active par la configuration d'un des serveurs de confiance. Si un message de notification comporte un index égal à 1 (Notif. (Action = 1)), le client DNS engage une action de type « désactiver les communications sortantes à l'exception des communications vers l'un des serveurs de confiance pour l'interface considérée », etc.
L'échange illustré par la figure 7 peut notamment être observé quand un serveur DNS malveillant 73 a été configuré dans l'équipement embarquant le client DNS 41, et que ce serveur malveillant 73 bloque tout ou partie des requêtes DNS émises par le client DNS 41. Le client DNS 41 peut engager une ou plusieurs actions à réception du ou des messages de notification, comme réinstaller la configuration DNS de confiance, bloquer certaines communications, etc.
Une fois la configuration DNS de confiance réinstallée par exemple (réinstallation des informations descriptives des serveurs DNS de confiance), le serveur de confiance 42 peut de nouveau recevoir une requête HB.
On présente maintenant, en relation avec la figure 8, la détection d'une anomalie lorsque l'adresse source d'une requête HB n'est pas cohérente avec l'adresse source de la requête d'activation. Des étapes similaires peuvent être mises en oeuvre lorsque la preuve d'intégrité véhiculée par une requête HB n'est pas cohérente avec la preuve d'intégrité déterminée localement par le serveur de confiance à partir des données de vérification connues du serveur de confiance. Selon l'un et/ou l'autre de ces cas, cela signifie typiquement que la requête HB a été relayée par un autre serveur DNS potentiellement malveillant. Le serveur de confiance peut ainsi détecter que les requêtes HB (ou toute autre requête DNS) émises par le client DNS sont interceptées par un autre serveur DNS avant leur acheminement vers le serveur de confiance.
La figure 8 illustre un exemple de messages échangés entre le client DNS 41 et le serveur de confiance 42. On considère par exemple que le client DNS 41 émet une requête d'activation en utilisant son adresse @1, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE » (Activ. PER APSERA 811).
Selon l'exemple illustré par la figure 8, le client DNS 41 émet une première requête HB (812) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d'intégrité consignée dans le champ « NONCE ». A réception de la première requête HB (812), le serveur de confiance 42 peut notamment vérifier que l'adresse source de la requête d'activation (@1) et l'adresse source de la première requête HB (src@) sont cohérentes. Le serveur de confiance 42 peut également vérifier que la preuve d'intégrité contenue dans le champ « NONCE » de la requête HB est cohérente avec une preuve d'intégrité déterminée à partir des données de vérification consignées dans le champ « CHALLENGE ». Le serveur de confiance 42 peut également vérifier si l'information de récurrence spécifiée dans le champ « EPOCH » est respectée.
Le client DNS 41 émet ensuite une deuxième requête HB (813) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d'intégrité dans le champ « NONCE ». Or comme illustré par la figure 8, cette deuxième requête HB (813) est interceptée par un serveur F 83 et relayée au serveur de confiance 42. A réception de la deuxième requête HB (813), le serveur de confiance 42 constate que l'adresse source de la requête d'activation (@1) et l'adresse source de la deuxième requête HB (src@) ne sont pas cohérentes (src@ !=@1). Il détecte donc une anomalie et que la deuxième requête HB a probablement été relayée par un autre serveur DNS potentiellement malveillant (F 83). Le serveur de confiance 42 émet au moins une notification 814 invitant le client DNS 41 à engager une action. Par exemple, un ou plusieurs messages de notification 814 sont envoyés vers l'adresse renseignée dans le champ CONTACT_URI pour le client DNS 41, ou vers l'adresse utilisée par le client DNS 41 pour envoyer la requête d'activation. Par exemple, un tel message peut être de type réponse DNS, relayée par le serveur malveillant 83, comportant un index correspondant à une action donnée, par exemple préconfigurée, à exécuter par le client DNS. Par exemple, si une réponse DNS comporte un index égal à 3 (Rep. (Action = 3)), le client DNS engage une action de type « demander l'envoi de l'identité du serveur DNS actif ». Si une réponse DNS comporte un index égal à 0 (Rep. (Action = 0)), le client DNS engage une action de type remplacement de la configuration de résolution de noms de domaine active par la configuration d'un des serveurs de confiance, etc. On note que le serveur de confiance 42 peut déclencher l'exécution de plusieurs actions au titre des échanges HB utilisant une adresse IP distincte de celle utilisée lors de l'activation du service PER ASPERA.
L'échange illustré par la figure 8 peut notamment être observé quand un serveur DNS malveillant 83 a été configuré dans l'équipement embarquant le client DNS 41, et que ce serveur malveillant 83 se comporte comme un relais DNS intermédiaire (« proxy ») qui relaie les messages entre le client DNS 41 et le serveur de confiance 42.
Une fois la configuration DNS de confiance réinstallée par exemple (réinstallation des informations descriptives des serveurs DNS de confiance), le serveur de confiance 42 peut de nouveau recevoir une requête HB.
Dans un mode de réalisation particulier, le serveur de confiance 42 peut aussi inclure une option EDE, telle que décrite dans le document RFC 8914 « Extended DNS Errors » d'octobre 2020, pour informer le client DNS qu'une erreur DNS a été constatée par le serveur de confiance. A réception de cette réponse, le client DNS peut procéder à l'exécution de l'action indiquée dans cette réponse. En variante, l'indication de l'action à exécuter par un client DNS peut être renseignée à l'aide de l'option WADE. Pour ce faire, un bit « A » est défini à cet effet parmi les bits « unassigned » présentés dans la figure 2. Quand le bit « A » est positionné à « 1 », l'index de l'action est renseigné dans le corps de l'option WADE.
On présente enfin, en relation avec la figure 9, un exemple de désactivation du service PER ASPERA, pour au moins une interface de l'équipement. On considère par exemple que le client DNS 41 émet une requête d'activation en utilisant son adresse @1, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE » (Activ. PER APSERA 911).
Selon l'exemple illustré par la figure 9, lorsque le client DNS 41 souhaite désactiver le service PER ASPERA, il émet une requête HB (912) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » comportant une preuve d'intégrité dans le champ « NONCE », calculé sur la base des données de vérification consignées dans le champ « CHALLENGE ». Pour informer le serveur de confiance 42 que le client DNS 41 souhaite désactiver le service PER ASPERA, le bit H « HB_ENABLE » est positionné à « 0 ».
A réception d'une telle requête, le serveur de confiance 42 vérifie qu'il n'y a pas d'anomalie. Par exemple, le serveur de confiance 42 peut rejeter la requête HB 912 et renvoyer un message d'erreur si la preuve d'intégrité contenue dans le champ NONCE de la requête HB 912 ne correspond pas à la preuve d'intégrité calculée localement par le serveur de confiance 42 pour les données de vérification consignées dans le champ CHALLENGE et stockées localement pour ce client DNS.
S'il ne détecte pas d'anomalie, le serveur de confiance 42 valide la désactivation du service PER ASPERA.
5.3 Structure simplifiée d'un équipement et d'un serveur de confiance selon un mode de réalisation
On présente finalement, en relation avec la figure 10, la structure simplifiée d'un équipement, respectivement d'un serveur de confiance, mettant en oeuvre un procédé de détection d'un serveur malveillant selon un mode de réalisation décrit ci-dessus.
Comme illustré par la figure 10, un tel équipement, respectivement serveur de confiance, comprend une mémoire 101E, respectivement 101S, comprenant par exemple une mémoire tampon, une unité de traitement 102E, respectivement 102S, équipée par exemple d'un processeur P, et pilotée par le programme d'ordinateur Pg 103E, respectivement 103S, mettant en oeuvre le procédé de détection d'un serveur malveillant selon un mode de réalisation décrit ci-dessus.
A l'initialisation, les instructions de code du programme d'ordinateur 103E sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 102E. Le processeur de l'unité de traitement 102E met en oeuvre les étapes du procédé de détection d'un serveur malveillant selon un mode de réalisation décrit ci-dessus, selon les instructions du programme d'ordinateur 103E, pour : transmettre, à destination d'au moins un desdits serveurs de confiance, au moins une requête d'activation d'un service de vérification de résolution de noms de domaine, recevoir au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, transmettre au moins une requête de résolution dudit au moins un nom de domaine, si aucune requête de résolution dudit au moins un nom de domaine n'est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, recevoir au moins une notification invitant ledit équipement à engager une action.
A l'initialisation, les instructions de code du programme d'ordinateur 103S sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 102S. Le processeur de l'unité de traitement 102S met en oeuvre les étapes du procédé de détection d'un serveur malveillant selon un mode de réalisation décrit ci-dessus, selon les instructions du programme d'ordinateur 103S, pour : recevoir au moins une requête d'activation d'un service de vérification de résolution de noms de domaine, en provenance dudit équipement, transmettre au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface, - si aucune requête de résolution dudit au moins un nom de domaine n'est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, transmettre audit équipement au moins une notification l'invitant à exécuter une action.

Claims

REVENDICATIONS
1. Procédé de détection d'un serveur de résolution de noms de domaine malveillant, mis en oeuvre dans un équipement configuré avec au moins un serveur de résolution de noms de domaine de confiance associé à au moins une interface réseau via laquelle ledit équipement est apte à communiquer, mettant en oeuvre :
- la transmission (111), à destination d'au moins un desdits serveurs de confiance, d'au moins une requête d'activation d'un service de vérification de résolution de noms de domaine,
- la réception (112) d'au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface,
- la transmission (113) d'au moins une requête de résolution dudit au moins un nom de domaine,
- si aucune requête de résolution dudit au moins un nom de domaine n'est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, la réception (114) d'au moins une notification invitant ledit équipement à engager une action.
2. Procédé selon la revendication 1, caractérisé en ce que ladite au moins une réponse comporte également des données de vérification générées par ledit serveur de confiance pour ladite au moins une requête d'activation, et en ce que ladite au moins une requête de résolution dudit au moins un nom de domaine comporte une preuve d'intégrité obtenue à partir desdites données de vérification.
3. Procédé selon la revendication 2, caractérisé en ce que ladite au moins une requête de résolution dudit au moins un nom de domaine comporte un indicateur requérant la génération, par ledit serveur de confiance, de nouvelles données de vérification.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite au moins une réponse et/ou ladite requête de résolution dudit au moins un nom de domaine sont chiffrées.
5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite au moins une réponse comporte également une information de récurrence et en ce que ladite au moins une requête de résolution dudit au moins un nom de domaine est transmise en tenant compte de ladite information de récurrence.
6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite au moins une requête d'activation comporte au moins une adresse de contact dudit équipement.
7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les informations descriptives dudit au moins un serveur de confiance sont stockées dans un registre maintenu par ledit équipement et dont l'accès est protégé.
8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit équipement exécute au moins une action donnée à réception d'une notification l'invitant à exécuter ladite au moins action, ladite au moins une action appartenant au groupe comprenant :
- remplacer la configuration de résolution de noms de domaine active par la configuration d'un desdits serveurs de confiance,
- désactiver les communications sortantes à l'exception des communications vers l'un desdits serveurs de confiance,
- générer une notification locale pour informer un utilisateur d'une modification de la configuration de résolution de noms de domaine,
- demander l'envoi de la configuration de résolution de noms de domaine active.
9. Procédé de détection d'un serveur de résolution de noms de domaine malveillant, mis en oeuvre dans un serveur de résolution de noms de domaine de confiance configuré dans un équipement et associé à au moins une interface réseau via laquelle ledit équipement est apte à communiquer, mettant en oeuvre :
- la réception (121) d'au moins une requête d'activation d'un service de vérification de résolution de noms de domaine, en provenance dudit équipement,
- la transmission (122) d'au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface,
- si aucune requête de résolution dudit au moins un nom de domaine n'est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, la transmission (124) audit équipement d'au moins une notification l'invitant à exécuter une action.
10. Procédé selon la revendication 9, caractérisé en ce qu'une anomalie est détectée si ladite au moins une requête de résolution dudit au moins un nom de domaine et si ladite au moins une requête d'activation ne proviennent pas du même équipement.
11. Procédé selon l'une quelconque des revendications 9 et 10, caractérisé en ce que ladite au moins une réponse comporte également des données de vérification générées par ledit serveur de confiance pour ladite au moins une requête d'activation, en ce que ladite au moins une requête de résolution dudit au moins un nom de domaine comporte une preuve d'intégrité obtenue à partir desdites données de vérification, et en ce qu'une anomalie est détectée si ladite preuve d'intégrité portée par ladite au moins une requête de résolution dudit au moins un nom de domaine n'est pas cohérente avec une preuve d'intégrité obtenue localement à partir desdites données de vérification connues dudit serveur de confiance.
12. Procédé selon l'une quelconque des revendications 9 à 11, caractérisé en ce que ladite au moins une réponse comporte également une information de récurrence de ladite au moins une requête de résolution dudit au moins un nom de domaine, et en ce qu'une anomalie est détectée si aucune requête de résolution dudit au moins un nom de domaine n'est reçue par ledit serveur de confiance ou si ladite au moins une requête de résolution dudit au moins un nom de domaine n'est pas cohérente avec ladite information de récurrence.
13. Procédé selon l'une quelconque des revendications 9 à 12, caractérisé en ce que ladite au moins une notification d'action est transmise à au moins une adresse de contact dudit équipement portée par ladite requête d'activation ou à l'adresse utilisée par ledit équipement pour transmettre ladite requête d'activation.
14. Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce que lesdites requêtes d'activation et/ou de résolution utilisent une option selon le mécanisme EDNS (« Extension Mechanisms for DNS ») pour échanger des informations entre ledit équipement et ledit serveur de confiance.
15. Équipement configuré avec au moins un serveur de résolution de noms de domaine de confiance associé à au moins une interface réseau via laquelle ledit équipement est apte à communiquer, caractérisé en ce qu'il est configuré pour :
- transmettre, à destination d'au moins un desdits serveurs de confiance, au moins une requête d'activation d'un service de vérification de résolution de noms de domaine,
- recevoir au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface,
- transmettre au moins une requête de résolution dudit au moins un nom de domaine,
- si aucune requête de résolution dudit au moins un nom de domaine n'est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, recevoir au moins une notification invitant ledit équipement à engager une action.
16. Serveur de résolution de noms de domaine de confiance configuré dans un équipement et associé à au moins une interface réseau via laquelle ledit équipement est apte à communiquer, caractérisé en ce qu'il est configuré pour :
- recevoir au moins une requête d'activation d'un service de vérification de résolution de noms de domaine, en provenance dudit équipement, - transmettre au moins une réponse comportant au moins un nom de domaine généré par ledit serveur de confiance pour ladite au moins une interface,
- si aucune requête de résolution dudit au moins un nom de domaine n'est reçue par ledit serveur de confiance, ou si au moins une requête de résolution dudit au moins un nom de domaine est reçue par ledit serveur de confiance mais comporte une anomalie, transmettre audit équipement au moins une notification l'invitant à exécuter une action.
PCT/EP2023/084041 2022-12-05 2023-12-04 Procédés de détection d'un serveur de résolution de noms de domaine malveillant, équipement, serveur de confiance et programme d'ordinateur correspondants WO2024121017A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2212748A FR3142817A1 (fr) 2022-12-05 2022-12-05 Procédés de détection d’un serveur de résolution de noms de domaine malveillant, équipement, serveur de confiance et programme d’ordinateur correspondants.
FRFR2212748 2022-12-05

Publications (1)

Publication Number Publication Date
WO2024121017A1 true WO2024121017A1 (fr) 2024-06-13

Family

ID=85726194

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/084041 WO2024121017A1 (fr) 2022-12-05 2023-12-04 Procédés de détection d'un serveur de résolution de noms de domaine malveillant, équipement, serveur de confiance et programme d'ordinateur correspondants

Country Status (2)

Country Link
FR (1) FR3142817A1 (fr)
WO (1) WO2024121017A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7620733B1 (en) * 2005-03-30 2009-11-17 Cisco Technology, Inc. DNS anti-spoofing using UDP
US20170329850A1 (en) * 2007-10-31 2017-11-16 Microsoft Technology Licensing, Llc Secure dns query
US20200007585A1 (en) * 2018-02-06 2020-01-02 Akamai Technologies, Inc. Secure request authentication for a threat protection service

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7620733B1 (en) * 2005-03-30 2009-11-17 Cisco Technology, Inc. DNS anti-spoofing using UDP
US20170329850A1 (en) * 2007-10-31 2017-11-16 Microsoft Technology Licensing, Llc Secure dns query
US20200007585A1 (en) * 2018-02-06 2020-01-02 Akamai Technologies, Inc. Secure request authentication for a threat protection service

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "History for doc/protocol.md - iagox86/dnscat2 . GitHub", 2 June 2018 (2018-06-02), XP093053075, Retrieved from the Internet <URL:https://github.com/iagox86/dnscat2/commits/master/doc/protocol.md> [retrieved on 20230609] *
EASTLAKE IBM D: "Domain Name System Security Extensions; rfc2535.txt", DOMAIN NAME SYSTEM SECURITY EXTENSIONS; RFC2535.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, March 1999 (1999-03-01), XP015008318 *
PORT CONTROL PROTOCOL (PCP, 2013
US SECURE HASH ALGORITHMS (SHA AND SHA-BASED HMAC AND HKDF, 2011

Also Published As

Publication number Publication date
FR3142817A1 (fr) 2024-06-07

Similar Documents

Publication Publication Date Title
US11647003B2 (en) Concealing internal applications that are accessed over a network
KR101265305B1 (ko) 부정적인 인터넷 계정 액세스 방지
US20080028225A1 (en) Authorizing physical access-links for secure network connections
WO2019062666A1 (fr) Procédé et appareil permettant d&#39;accéder de manière sécurisée à un réseau interne
FR3041493A1 (fr) Equipement pour offrir des services de resolution de noms de domaine
US10158610B2 (en) Secure application communication system
EP1720315B1 (fr) Gestion et administration de réseau par surveillande du trafic et analyse de vulnérabilité
JP2014501959A (ja) ユーザにサービスアクセスを提供する方法およびシステム
EP3857848B1 (fr) Procédé d&#39;allocation d&#39;un identifiant à un noeud client, procédé d&#39;enregistrement d&#39;un identifiant, dispositif, noeud client, serveur et programmes d&#39;ordinateurs correspondants
WO2018115647A1 (fr) Validation de livraison de contenu et de verification d&#39;une delegation de livraison d&#39;un contenu
WO2024121017A1 (fr) Procédés de détection d&#39;un serveur de résolution de noms de domaine malveillant, équipement, serveur de confiance et programme d&#39;ordinateur correspondants
EP3087719B1 (fr) Procédé de ralentissement d&#39;une communication dans un réseau
FR3080967A1 (fr) Procede d&#39;envoi d&#39;une information et de reception d&#39;une information pour la gestion de reputation d&#39;une ressource ip
CN112514350B (zh) 用于核实ip资源的有效性的方法以及相关联的访问控制服务器、验证服务器、客户端节点、中继节点和计算机程序
WO2020002853A1 (fr) Procédés de gestion du trafic associé à un domaine client, serveur, nœud client et programme d&#39;ordinateur correspondants
EP4268426A1 (fr) Procedes pour la redirection de trafic, terminal, controleur, serveur d&#39;autorisation, serveurs de resolution de noms, et programme d&#39;ordinateur correspondants
CN114499965B (zh) 一种基于pop3协议的上网认证方法及系统
WO2022117941A1 (fr) Procédé de détection d&#39;un équipement malveillant dans un réseau de communication, équipement de communication et programme d&#39;ordinateur correspondants
EP4073999A1 (fr) Procede de traitement de requetes de resolution de nom de domaine
FR3110802A1 (fr) Procédé de contrôle de l’attribution d’une adresse IP à un équipement client dans un réseau de communication local, procédé de traitement d’une requête d’attribution d’une adresse IP à un équipement client dans un réseau de communication local, dispositifs, équipement d’accès, équipement serveur et programmes d’ordinateur correspondants.
WO2023117802A1 (fr) Procédés d&#39;identification d&#39;au moins un serveur de mitigation et de protection d&#39;un domaine client contre une attaque informatique, dispositifs et signal correspondants
CN114257437A (zh) 远程访问方法、装置、计算设备及存储介质
FR3086821A1 (fr) Procedes de collaboration et de demande de collaboration entre services de protection associes a au moins un domaine, agents et programme d’ordinateur correspondants.

Legal Events

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

Ref document number: 23814227

Country of ref document: EP

Kind code of ref document: A1