EP4256753A1 - Procédé de détection d'un équipement malveillant dans un réseau de communication, équipement de communication et programme d'ordinateur correspondants - Google Patents

Procédé de détection d'un équipement malveillant dans un réseau de communication, équipement de communication et programme d'ordinateur correspondants

Info

Publication number
EP4256753A1
EP4256753A1 EP21830459.0A EP21830459A EP4256753A1 EP 4256753 A1 EP4256753 A1 EP 4256753A1 EP 21830459 A EP21830459 A EP 21830459A EP 4256753 A1 EP4256753 A1 EP 4256753A1
Authority
EP
European Patent Office
Prior art keywords
equipment
identifier
communication equipment
malicious
name resolution
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21830459.0A
Other languages
German (de)
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4256753A1 publication Critical patent/EP4256753A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature 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
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks

Definitions

  • TITLE Method for detecting malicious equipment in a communication network, communication equipment and corresponding computer program.
  • the field of the invention is that of communications within a communication network, for example a computer network implementing the IP protocol.
  • the invention relates to value-added IP services.
  • the invention relates to name resolution services, for example DNS (in English “Domain Name System”), and proposes a solution for detecting the presence of malicious equipment involved in name resolution.
  • DNS in English “Domain Name System”
  • the DNS system is an important component in the provision of IP services.
  • 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 “uniform 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 “uniform resource identifier”, etc.
  • the DNS service allows a terminal to obtain the IPv4 and/or IPv6 addresses associated with a domain name.
  • HG Home Gateway
  • CPE Customer Premises Equipment
  • Such a residential gateway conventionally serves as an interface between the user's local network ("Local Area Network” (LAN), in English) and the network of an operator with which the user has subscribed to an offer.
  • Internet Service Provider ISP
  • ISP Internet Service Provider
  • the operator During the network connection of a CPE, the operator conventionally provides the CPE with the information necessary to access the connectivity service. Thus, the operator allocates an IPv4 address and/or an IPv6 prefix which can be associated with the CPE to establish IPv4 and/or IPv6 communications from/to the terminals connected to this CPE.
  • the operator also provides the CPE with a list of DNS servers to use for name resolution. To do this, protocols like DHCP for IPv4 (in English “Dynamic Host Configuration Protocol”, in French “protocol de configuration Dynamique des Hosts”, as described in the documents RFC 2131 (“Dynamic Host Configuration Protocol”, R.
  • IPv6 in English “Neighbor Discovery Protocol”, in French “protocol de discovery des neighbors”, as described in the document RFC 4861 (“Neighbor Discovery for IP version 6 (IPv6)”, T Narten et al., September 2007) can be used between the CPE and the access network
  • Other mechanisms such as CWMP (CPE WAN Management Protocol) can be used for the configuration of the CPE.
  • a terminal H1 11 (or an application), present in a local area network LAN, wishes to establish communication with a remote server S 12, identified by a domain name (for example FQ.DN , “Fully Qualified Domain Name” in English), for example “ourexample.com”.
  • a DNS client embedded in the HI terminal 11 can send a DNS request, also called DNS resolution request, of type A (if the terminal supports IPv4) and/or AAAA (if the terminal supports IPv6) to one of the DNS servers 13 provided by the operator and hosted in the access network (for example) to obtain the IP addresses associated with the domain name "ourexample.com”.
  • IPv4 can publish a type A DNS record
  • IPv6 can publish an AAAA type record
  • a server that can be reached in IPv4 and IPv6 can publish A and AAAA type records.
  • a terminal that wants to reach such a server must specify the type of record in the DNS request (A or AAAA).
  • a terminal that supports IPv4 and IPv6 can send two DNS queries: the first query indicates an A-type record and the second indicates an AAAA-type record.
  • the DNS request can be sent directly from the terminal H1 11 to the DNS server 13, as illustrated in FIG. “DNS Terminology”, P. Hoffman et al., January 2019), as illustrated in figure IB.
  • the CPE 14 can relay the DNS request to the DNS server 13 if no response is found in the local cache.
  • the DNS server 13 can respond with a list of IP addresses (for example @S) if at least one entry corresponding to the domain name sought is available in its database for the type of record (A or AAAA) requested, or relay the request to another DNS server according to the hierarchical structure of the DNS architecture if the DNS server 13 does not have such an entry.
  • the response received from another DNS server located higher in said hierarchy is relayed in turn by the DNS server 13 initially requested to the terminal H1 11.
  • the DNS response can be sent directly from the DNS server 13 to the terminal H1 11, as illustrated in FIG. 1A, or sent to the CPE 14 in the event of the presence of a “DNS forwarder” as illustrated in FIG. IB. In the latter case, the “forwarder” of the CPE 14 relays the DNS response to the terminal H1 11.
  • the terminal H1 11 can thus extract the IP address (or addresses) contained in the response (for example @S), then establish communication with the server S 12, by sending a request connection to one of the addresses returned (for example @S).
  • a DNS server is called a nominal server if it has been declared, by the operator via the access network, in a communication device, typically when attaching this device to the network, or by means of a configuration prerequisite, for example a “factory” configuration.
  • the communication equipment retrieves the accessibility information from one or more (nominal) DNS servers provided by the operator(s).
  • An operator can be a provider of connectivity services, voice over IP, etc., and each of these operators can thus provide their own DNS service by hosting one or more DNS servers within their infrastructures.
  • the service can be provided via a fixed or mobile infrastructure (for example of the PLMN type, in English “Public Land Mobile Network”).
  • DNS servers are for example operated by entities such as “Google Public DNS®”, “Cloudflare®” or Q.UAD9®.
  • a communication device can thus retrieve a new DNS configuration for each of its active network interfaces (fixed, mobile, WLAN (“Wireless Local Area Network”), etc.).
  • Other information for example, the reachability of SIP (Session Initiation Protocol) servers
  • SIP Session Initiation Protocol
  • a disadvantage of DNS server discovery mechanisms within a LAN network is that they are not secure.
  • the terminal H1 21 when the terminal H1 21 connects to the local area network LAN, it can receive messages from malicious equipment RS 23 in response to its requests according to the DHCP or ND protocols for example.
  • the terminal H1 21 can receive a message of the router advertisement type RA (“Router Advertisement”) coming from the malicious equipment RS 23, and consider that the malicious equipment RS 23 is its default router.
  • the terminal H1 21, which wishes to establish communication with the remote server S 22 identified by a domain name, can then send a DNS request to the malicious equipment RS 2.3, instead of sending it to the CPE 24.
  • the equipment malicious RS 23 can host a fraudulent DNS server and respond with the address of a malicious remote server AS 25 (for example @AS).
  • the terminal H1 21 can then extract the IP address (or addresses) contained in the response (for example @AS), then establish communication with the malicious server AS 25.
  • This lack of a secure discovery mechanism within the LAN network can thus facilitate the execution of attacks that allow the interception of sensitive user data (for example personal data) and the redirection to fraudulent sites as illustrated in face
  • a first solution envisaged is based on the use of authentication certificates.
  • the invention proposes a solution for the detection of malicious equipment in a communication network, implemented in a communication equipment configured with at least one so-called legitimate name resolution server associated with at least one network interface via which said communication equipment is able to communicate using at least a first identifier.
  • such a detection method comprises:
  • the invention thus allows communication equipment associated with one or more network interfaces (for example fixed, mobile, local network) to pass itself off as another equipment, for example a terminal which joins the network associated with the first identifier (for a local network, for example), in an attempt to detect the presence in said network of malicious equipment involved during name resolution.
  • network interfaces for example fixed, mobile, local network
  • first identifier for a local network, for example
  • the communication equipment is configured with at least one legitimate name resolution server associated with at least one network interface via which the communication equipment is able to communicate using at least one first identifier.
  • the network interfaces can be physical and/or logical interfaces (for example “loopback” interface).
  • This first identifier makes it possible to unambiguously identify the communication equipment (particularly the interface used) and can be used by the communication equipment when it communicates with the terminals of the local network (for example to transmit the DNS configuration information).
  • the communication equipment can also generate, or more generally obtain, at least one second identifier, distinct from the first identifier, but also intended to be used on the same network interface as the first identifier and capable of being used when the communication equipment behaves like a terminal connected to the same local network (for example identified by an SSID (“Service Set Identifier” in English, “Identifying d'Ensemble de Services” in French)).
  • SSID Service Set Identifier” in English, “Identifying d'Ensemble de Services” in French
  • the communication equipment emulates a terminal of the local network, and it is difficult for a fraudulent equipment to identify that the equipment which uses said second identifier is the communication equipment.
  • said at least one second identifier may comprise: a MAC address, and/or a link-local address (“link-local” in English), and/or a unicast IP address, and/or a unique local address (ULA, “Unique Local Address”), and/or an application identifier (token).
  • Such identifiers can be generated randomly, and therefore not repetitively.
  • the simultaneous generation and use of several identifiers which can characterize different layers of the OSI model (link layer, network layer, application layer, for example), has the advantage of making emulation more difficult to detect at which the communication equipment lends itself and to make the mechanism more robust.
  • These different identifiers are not in conflict with those used by the other terminals of the local network. This is possible because the communication equipment has visibility on its own identifiers as well as on those used by the equipment present in the local network. It should be noted that the communication equipment can be responsible for managing any possible conflict of the second identifiers if a new terminal connects to the network when the communication equipment forges a second identifier in conflict with those presented by the new terminal.
  • the communication equipment can request and/or receive information for configuring a name resolution service (which may or may not be part of connectivity information), without the other connected equipment to the network know that it is the communication equipment.
  • a name resolution service which may or may not be part of connectivity information
  • the communication equipment can detect the presence of potentially malicious equipment by analyzing the processing of this request (and possibly of the associated response).
  • the configuration information is obtained in a message received by said communication equipment, said message being a router announcement message or a message according to the DHCP protocol received in response to a message sent by the communication equipment using said at least one second identifier, said name resolution service configuration message.
  • the configuration message is a response to a configuration request from a name resolution service or a response to a router solicitation message transmitted by the communication equipment. It is considered according to this first example that the configuration message is received in response to a request from the communication equipment.
  • the configuration message can be sent spontaneously by a network device. It is considered according to this second example that the configuration message is received in an unsolicited manner, for example during the attachment of the communication equipment to the network by using the second identifier.
  • the name resolution service configuration message can be a response to a name resolution service configuration request.
  • a name resolution service configuration request can be sent in multicast or in unicast.
  • such a configuration request is broadcast when a new device connects to the network, or when attaching the communication device to the network using the second identifier.
  • the configuration request for a name resolution service is transmitted in a DHCP message transmitted using the second identifier.
  • the DHCP or DHCPv6 protocols can be used to convey the configuration request(s) of a name resolution service.
  • the name resolution service configuration message may alternatively be obtained in response to a router solicitation message.
  • a router solicitation message (or RS, for "Router Solicitation") can thus be transmitted by the communication equipment when it emulates a terminal using the at least one second identifier.
  • an RS message requires the transmission by the routers concerned of a router advertisement message or RA, in English "Router Advertisement”), the latter possibly including in particular configuration information of a name resolution service. Following the transmission of such an RS message, the communication equipment therefore listens to the router announcement message(s) responding to the RS message transmitted by the communication equipment.
  • the presence of malicious equipment can be detected in the event of usurpation, in a message received by said communication equipment, of an identity of a default router defined for said at least one interface network.
  • Such a message can be the configuration message of a resolution service defined above, or a separate message.
  • a message is of type RA.
  • the communication equipment may be a CPE.
  • the communication equipment can be a default router for said communication network, and the detection can implement: - the comparison of at least one identifier of the transmitting equipment of said message received by said communication equipment with said at least one first identifier of said communication equipment.
  • the communication equipment can extract from the received message (configuration message of a resolution service or other message not comprising configuration information) the source address of the equipment sending this message, and check if it corresponds to one of its addresses (first identifier of the communication equipment, for example of the global unicast address type or local link of the CPE). If such is the case, the communication equipment concludes that the sending equipment is usurping its identity.
  • correlated identifiers is meant here and throughout the rest of the document identifiers linked by a dependency relationship (for example an identifier and a coded version of this identifier).
  • the source address is an address that belongs to a prefix of the communication equipment (for example an IPv6 prefix /64)
  • the latter decides that there is correlation and therefore that the sending equipment is usurping its identity. .
  • the communication equipment can be a terminal.
  • the communication equipment is not a default router defined for said communication network, and the detection can implement:
  • the communication equipment can extract from the received message (configuration message of a resolution service or other message not comprising configuration information) the source address of the equipment sending this message, and check if it matches one of the addresses of a default router.
  • the communication equipment decides that the equipment sending the message is a malicious equipment. Indeed, the reception of such a message means that the equipment sending the response announces itself as a router, whereas the legitimate router is the router defined by default.
  • the detection also implements:
  • the method implements, prior to the detection step:
  • the detection step following the transmission of such a DNS request, the detection step also implements:
  • the verification of the integrity of the name resolution request comprises: verifying whether said request passing through said communication equipment has been modified with respect to the original request and/or has been duplicated.
  • the detection step also implements: - if a response to said name resolution request is received by the communication equipment, comparing said response, referred to as a test response, with a response to the same request originating from said at least one legitimate name resolution server, referred to as legitimate answer,
  • the method implements at least one action following the detection of the presence of malicious equipment, said at least one action belonging to the group comprising:
  • the notification of an incident belongs to the group comprising:
  • a direct notification of a user of said communication equipment for example: automatic call, SMS, etc.
  • a notification from a user of said communication equipment via an operator of said network for example: sending the notification to the operator, who relays the notification to the user using the means of communication defined in title of the subscribed contract
  • Traffic blocking can be implemented when the communication equipment is a CPE, since the traffic passes through it.
  • the blocking implements a filtering of the messages intended or received by said malicious device.
  • Such a blockage can be temporary or permanent. It can in particular be implemented by filtering the messages intended for or received by the malicious equipment, by using an identifier of the malicious equipment, for example its MAC address or by refusing access to the local network to said malicious equipment if the communication equipment uses unique session identifiers per terminal (for example, WPA-PSK (“Wi-Fi Protected Access-Pre-Shared Key”) with unique keys).
  • WPA-PSK Wi-Fi Protected Access-Pre-Shared Key
  • Such blocking can be implemented by default or conditionally, for example when no identifier of at least one name resolution server is identical or correlated to an identifier of at least one name resolution server legit.
  • the conditions for setting up such blocking can be configured on the communication equipment (for example setting up immediately from the biocage if the DNS server thus discovered appears in a list of unauthorized servers (“discard-list”) provided to the communication equipment).
  • the invention relates to corresponding communication equipment.
  • such communication equipment is in particular suitable for the implementation of a method for detecting fraudulent equipment according to at least one embodiment of the invention.
  • such communication equipment can comprise the different characteristics relating to the method according to the invention, which can be combined or taken separately.
  • the communication equipment is of the gateway type (domestic or business, also called “box”, HG or CPE), terminal (possibly allowing connection sharing, "tethering” in English), access key (“dongle” in English), etc.
  • gateway type domestic or business, also called “box”, HG or CPE
  • terminal possibly allowing connection sharing, "tethering” in English
  • access key (“dongle” in English), etc.
  • the invention relates to one or more computer programs comprising instructions for the implementation of a method for detecting fraudulent equipment according to at least one 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, a DNS resolver (“resolver” or “stub-resolver”, in English), etc.
  • DNS resolver resolver
  • These different modules can be embedded in communication equipment as described above, for example a terminal ("User Equipment” in English), a key equipped for example with a USB port (“(USB) dongle” in English ), a CPE, etc.
  • FIG. presented in relation to the prior art, illustrates an example of deployment of a DNS service without DNS relay embedded in the CPE
  • FIG. 1B presented in relation to the prior art, illustrates an example of deployment of a DNS service with DNS relay embedded in the CPE
  • Figure IC presented in relation to the prior art, illustrates an example of establishing a connection with a remote server
  • FIG. 2 also presented in relation to the prior art, illustrates an example of interception of DNS requests by malicious equipment
  • FIG. 3 presents the main steps of a method for detecting malicious equipment according to at least one embodiment of the invention
  • FIG. 4, FIG. 5 and FIG. 6 illustrate examples of messages exchanged between a CPE and a potentially malicious device
  • FIG. 7 presents a flowchart of the different steps that can be implemented by a CPE to detect the presence of malicious equipment in a local area network
  • FIG. 8 presents a flowchart of the different steps that can be implemented by a terminal to detect the presence of malicious equipment in a local network
  • FIG. 9 presents the simplified structure of a communication device according to a particular embodiment.
  • the general principle of the invention is based on the use of different identifiers associated with the same communication equipment, allowing this communication equipment to emulate the presence of a new equipment in the network. Such emulation makes it possible in particular to detect the presence of malicious equipment in the network, involved during name resolution.
  • a communication device is conventionally configured with at least one legitimate name resolution server associated with at least one network interface via which the communication equipment is able to communicate using at least a first identifier.
  • the communication equipment obtains, for each of its available network interfaces, information (domain names, IP addresses, etc.) relating to at least one legitimate name resolution server, provided by the access network associated with these interfaces (for example the network of an operator).
  • information for example provided to the communication equipment using a protocol such as DHCP for IPv4, DHCPv6 for IPv6, a router advertisement message RA, a protocol configuration option PCO (Protocol Configuration Option), etc., subject to the use of a dedicated identifier used by the communication equipment (for example a MAC address or any other equivalent identifier).
  • such DNS information can be configured locally for each of the available network interfaces associated with the communication equipment, for example in a declarative way by an administrator or a user of the communication equipment.
  • this DNS information may be identical for all the active network interfaces of the communication equipment.
  • the communication equipment thus configured can then use at least a first identifier associated with the network interface via which it can communicate with other terminals.
  • This first identifier is for example a MAC address, an IP address, or an application token (“Token”), and makes it possible to identify the communication equipment in an unambiguous manner.
  • the communication equipment can obtain (for example generate or receive) at least one second identifier, distinct from the first identifier(s), for the communication equipment and for the same network interface(s) as the first identifier(s).
  • This second identifier is for example a MAC address, a link-local IP address, a unicast IP address, a unique local address, an application token, etc.
  • the second identifier thus obtained must also be distinct from those used by the other devices of the local network (and in particular by the terminals of the local network).
  • This second identifier is notably used to obtain, during a third step 33, configuration information of a name resolution service.
  • the configuration information obtained from the second identifier(s) is used to detect the possible presence of malicious equipment.
  • malicious equipment is detected in the event of an anomaly in the processing of a name resolution request sent by said communication equipment using said at least one second identifier and the configuration information obtained.
  • the presence of malicious equipment can also be detected in the event of usurpation, in a message received by the communication equipment, of an identity of a default router defined for said at least one network interface. Such a message may optionally carry said configuration information.
  • Different information can thus be used to detect the presence of malicious equipment: - the reception of a message in which a network device announces itself as a router, making it possible to detect identity theft,
  • the configuration information (which can be received in this same message or in a separate message configuring a name resolution service), making it possible to analyze the processing of DNS requests, in particular if there is no identity theft is detected.
  • the presence of malicious equipment can be detected in the event of identity theft or of an anomaly in the processing of a name resolution request transmitted to at least one name resolution server identified in the information of configuration.
  • the detection method presented applies independently of the transport protocol used by the name resolution service.
  • the transport protocol used by DNS communications can be either IPv4 or IPv6 (depending on network access conditions, in particular), and DNS exchanges can be based on protocols of the application layer (for example HTTPS) or of the transport layer (for example QLIIC/UDP) - according to standards such as DoT (RFC 7858 mentioned above), DNS-over-DTLS (RFC 8094 "DNS over Datagram Transport Layer Security (DTLS)”, T. Reddy et al., February 2017), DoH (RFC 8484 cited above), DNS-over-QUIC (DoQ), etc.
  • the proposed solution thus offers at least one of the following advantages, depending on the embodiment considered: offering a set of reliable and robust name resolution type services, while minimizing the modifications of the existing infrastructures and protocols required to provide such services, to detect attacks and the interception of data within a computer network (domestic or internal corporate network) by fraudulent equipment, which may serve as a relay for such attacks, to continue to offer services to added value, based in particular on name resolution, by an operator to its customers, including the activation of a "forwarder" in a CPE, improving the user's confidence in the operator with which he has subscribed to such name resolution services.
  • legitimate DNS server means a name resolution server, whether of the nominal DNS server type (declared or configured by the operator and for example hosted in the access network), public DNS server, or "alternate” server.
  • Alternate servers means servers that are not the DNS servers set up and operated by an operator. These alternate servers are generally not hosted by the IP service provider. They can, however, operate a public DNS service.
  • Such a legitimate server can therefore be a server configured by the operator or the user.
  • This server can be a server of the operator or of a third party.
  • malwareicious equipment or “fraudulent equipment” also means a machine on the communication network which usurps or announces information making it possible to intercept DNS traffic (for example, a machine usurping the identity of a DNS server or impersonating the default router through which DNS traffic passes).
  • This can be, for example, a device installed by the user, a visitor device (for example a guest), a device located in the coverage area of the WLAN network, a network access device of the operator (CPE), etc.
  • the communication network is for example a domestic computer network or a company network, also called local area network or LAN.
  • a communication equipment of the CPE type associated with at least one network interface between the local network and the access network, and defined as a default router for the terminals from the local network.
  • Other routers can be deployed in the local network, for example a home router different from the CPE and installed to segment the LAN traffic between private traffic and business traffic.
  • the CPE is considered to be a default router.
  • the network interface is a radio interface (WLAN).
  • WLAN radio interface
  • the network interface can be configured with DNS information.
  • DNS information can be provided to the CPE by the access network (allowing to connect to the Internet network), when connecting the CPE to the access network, for example by using DHCP, DHCPv6 protocols, or a message AR, PCO, etc.
  • DNS information can also be configured locally, declaratively, for example via a management interface of the CPE.
  • the CPE can relay the DNS information to the various devices of the local network (including the internal routers if applicable), using at least a first identifier associated with the network interface used for this purpose.
  • the CPE may advertise one or more legitimate DNS servers (identified from DNS information associated with the network interface). These servers can use a transport protocol of the type Do53, DoH, DoT, DoQ., etc., to communicate.
  • the CPE can advertise itself in the local network as being a DNS server, by using at least a first identifier.
  • DNS forwarder or DNS proxy
  • the CPE can announce in the local network the list of legitimate DNS servers, provided to the CPE by the operator via the access network or configured locally , using at least a first identifier.
  • the announcement of DNS information by the CPE implements, for example, the DHCP protocol for IPv4 or IPv6, or ND between the CPE and the equipment on the local network.
  • the various network devices can then communicate via the CPE with machines on the local network or those connected to the Internet, via the network interface, using the first identifier or identifiers.
  • the first identifier(s) comprise a MAC address, for example a MAC address assigned to the network interface which connects the CPE to the local network and which is a priori static.
  • the first identifier(s) can be an IP address, an application token, etc.
  • first identifiers associated with the same local interface are:
  • the address of the DNS server configured for this interface is for example: 81.253.149.10.
  • the CPE In order to detect whether a malicious device is present in the local network, the CPE emulates a local network device.
  • the CPE generates at least one second identifier of the CPE, distinct from the first identifier(s), and intended to be used on the same network interface as the first identifier(s).
  • the second identifier(s) comprise(s) a MAC address.
  • the second identifier(s) comprise a link-local address (“link-local”), an IP unicast address, an HLA address, or an application token, etc.
  • IP address 192.168.1.10
  • DHCPv6 client application token DUID 00-01-00-01-25-8E-CB-A1-14-58-D0-B7-01-DC.
  • the application token can be structured according to a format similar to the DUID (“DHCP Unique Identifier”) attribute defined in the aforementioned RFC8415 document (Section 11).
  • the application token can be structured according to a format similar to the “Cookie” field defined in the document RFC7413 “TCP Fast Open” Y. Cheng et al., December 2014 (Section 4.1).
  • such elements are generated randomly.
  • the CPE can obtain the information (identifiers, triggering of the procedure, etc.) to be used during the emulation procedure by using a mechanism such as RESTCONF Call Home (as described in particular in the document RFC8071 (“NETCONF Call Home and RESTCONF Call Home”, K. Watsen et al., February 2017).
  • a mechanism such as RESTCONF Call Home (as described in particular in the document RFC8071 (“NETCONF Call Home and RESTCONF Call Home”, K. Watsen et al., February 2017).
  • the second identifier(s) must be different from the first identifier(s) used by the CPE to announce the list of DNS servers or announce itself as a DNS server .
  • the CPE is not directly identified by the other equipment on the local network as a CPE (in particular if the first identifier is of the static MAC address type).
  • These second identifiers are also different from those used by the terminals already connected to the local network.
  • the generation of the second identifier(s) is preferably implemented randomly over time, or when a new device connects to the local network.
  • the CPE in order to emulate a terminal connected to the local network, can issue a DNS service configuration request, sent in multicast or unicast in the local network, and identifying the CPE by means of the or second identifier(s). For example, such a DNS service configuration request is sent each time a new device connects to the local network. As a variant, this request can be sent only to this terminal.
  • a DNS service configuration message may be received by the CPE, as indicated in connection with step 33 of obtaining configuration information of FIG. 3, on an address associated with the second identifier, in response to the request sent by the CPE. Note that different emulation modes can be supported by the CPE, depending on the protocols supported in the local network for example.
  • the request for configuration of a DNS service is transmitted in a DHCP message transmitted using said second identifier.
  • the DNS service configuration message received by the CPE can be the acknowledgment of receipt of this request.
  • the CPE can behave like a DHCP client, according to the procedure described in the aforementioned RFC 2131 and RFC 2132 documents.
  • the CPE may include DNS options and/or new OPTION__V4__DNS_RI options (as defined in the document "DHCP and Router Advertisement Options for Encrypted DNS Discovery within Home Networks, M. Boucadair et al., November 2020) in the “Parameter Request List” option.
  • the CPE can behave like a DHCPv6 client, according to the procedure described in the aforementioned RFC 8415 document.
  • the CPE may include DNS options and/or new OPTION__V6__DNS__RI options (as defined in "DHCP and Router Advertisement Options for Encrypted DNS Discovery within Home Networks, M. Boucadair et al., November 2020) in the " Option Request Option (ORO)”.
  • the configuration request for a DNS service is a router request message RS.
  • the DNS service configuration message received by the CPE can be an RA router advertisement message.
  • the CPE can behave like a host (terminal), according to the procedure described in the aforementioned RFC 4861 document. In other words, the CPE can transmit RS messages and listen to RA messages.
  • the CPE in order to emulate a terminal of the local network, can receive a configuration message from a DNS service as indicated in relation to step 33 of obtaining configuration information in FIG. 3, corresponding to an unsolicited announcement message, on an address associated with the second identifier.
  • a configuration message is an RA Router Advertisement message.
  • the configuration information and the second identifier(s) are used to issue a DNS request and detect, if necessary, the presence of malicious equipment in the event of an anomaly in the processing of the DNS request , as indicated in connection with step 34 of Figure 3.
  • the CPE can also receive a message from a device announcing itself as a router.
  • a message may be the same as a DNS service configuration message (i.e. carrying configuration information), or a separate message.
  • the CPE can in particular detect the presence of malicious equipment if the identity of the CPE has been usurped or if it detects an anomaly in the processing of a DNS request transmitted to a DNS server identified from the information configuration via the equipment announcing itself as a router.
  • the CPE can verify the identity of the sender of the message of the equipment announcing itself as a router. For example, the CPE extracts from the message the information making it possible to identify the sender of the message, such as a source MAC address, a source IP address, or any other identifier (for example token or “Token” in English presented in the message) .
  • the identifier(s) of the transmitting equipment are then compared with the first identifier(s) of the CPE.
  • the sending equipment has usurped the identity of the CPE, and more precisely the (or the) first identifier(s) of the CPE. Indeed, it is not the CPE which is at the origin of this message, and therefore the presence of said at least one first identifier in the message as being the source of this message indicates to the CPE that the equipment at the origin of the message is a malicious device usurping its identity, and more specifically in the example considered here, the identity of the default router.
  • the CPE thus detects that the equipment sending the message is malicious equipment, and can initiate an action in response to this detection, for example of the notification of an incident type and/or blocking of the malicious equipment.
  • FIG. 4 illustrates an example of messages exchanged between the CPE 41 and a malicious device 42 in the situation which has just been described.
  • the CPE can communicate with other devices on the local network via the network interface. To do this, it has a first IP address, Base@, associated with a first identifier. It also has a second IP address, New_@, associated with a second identifier according to the invention. Note that several IP addresses can be associated with the same interface, and therefore with an identifier.
  • the CPE 41 sends a configuration request a DNS service in the form of an RS router solicitation message, using its second IP address, New @ as the source address.
  • Such a router request message RS is notably received by the malicious equipment 42, which responds by sending a DNS service configuration message of the router announcement message type RA, having as source address the first address IP, Base@.
  • the CPE 41 detects that the source address of the router announcement message RA corresponds to one of its addresses (Base@), and deduces therefrom that the equipment 42 sending the router announcement message RA is malicious.
  • the CPE can also check, in particular in the case where there is no identity or correlation between at least one identifier of the equipment sending the message and at least a first identifier of the CPE, if the equipment sending the message n does not advertise a separate DNS server from the legitimate DNS server(s).
  • the CPE can in particular compare at least one identifier of at least one DNS server obtained from the configuration information, with at least one identifier of the legitimate DNS server(s) previously announced by the CPE.
  • the CPE can deciding that the equipment transmitting the configuration information is a malicious equipment.
  • the CPE can then initiate an action in response to this detection, for example of the notification of an incident type and/or blocking of the malicious equipment.
  • FIG. 5 illustrates the situation which has just been described by an example of messages exchanged between the CPE 51, a malicious device 52, and a legitimate DNS server 53.
  • the CPE can communicate with the other devices of the local network via the interface network. To do this, it has a first IP address, Base@, corresponding to a first identifier, and a second IP address, New..@, corresponding to a second identifier according to the invention.
  • the CPE 51 sends a request for configuration of a DNS service in the form of an RS router solicitation message in the local area network LAN, using its second IP address, New_@ as the source address.
  • Such an RS message is notably received by the malicious device 52, which responds by sending an RA message specifying a DNS service configuration, identifying a DNS server with the address @RS (which is not that of the legitimate DNS server 53).
  • the CPE detects that the identifier of the DNS server obtained from the configuration message (@RS) is not identical to the identifier of the legitimate DNS server previously announced by the CPE (@DNS), and that the equipment 52 sending the router advertisement message is malicious.
  • the CPE can also verify, in particular in the case where there is identity or correlation between at least one identifier of at least one DNS server obtained from the configuration message and at least one identifier of the legitimate DNS server(s) previously announced by the CPE, if there is no anomaly in the processing of DNS requests.
  • the CPE can send one or more DNS requests via the equipment sending configuration information of a DNS service, and check whether it (the CPE) detects an anomaly in the processing of the request (or requests).
  • (s)DNS By processing a DNS request, we mean here both the way in which we transmit and act on the request and on the response that can be made to this request.
  • the equipment sending configuration information embeds a “forwarder”
  • the DNS request(s) are sent to this sending equipment. Otherwise, the DNS request(s) are sent to the announced DNS server via this sender device.
  • the CPE can check whether it is indeed receiving the DNS request(s), since in the example considered here, it is the legitimate default router.
  • the CPE can in particular check: if the DNS requests are relayed by the sending device to a DNS server on the local network (i.e. the DNS server that the CPE itself hosts if the CPE has a "DNS forwarder » or a DNS server provided by the local network), and/or if the DNS requests have been modified during their routing, and/or if the DNS requests have been duplicated towards another server (which can therefore be identified as malicious) , and/or if the DNS queries are not relayed, and/or if the responses to these DNS queries have been the subject of a fraudulent interception having been able, for example, to call their integrity into question, etc.
  • a DNS server on the local network i.e. the DNS server that the CPE itself hosts if the CPE has a "DNS forwarder » or a DNS server provided by the local network
  • DNS requests have been modified during their routing, and/or if the DNS requests have been duplicated towards another server (which can therefore be identified as malicious)
  • the DNS queries are not relaye
  • the CPE can initiate an action, for example of the type of notification of an incident and/or blocking of the malicious equipment.
  • the CPE can carry out additional tests to check whether its DNS requests are routed to a legitimate DNS server (the one that the CPE hosts itself or a DNS server configured by an operator for example) or another server. . In the latter case, the
  • CPE can detect that the sending equipment is malicious equipment.
  • FIG 6 illustrates an example of the messages exchanged between the CPE 61 i . a malicious device 62, and a legitimate DNS server 63.
  • the exchanges between the potentially malicious device 62 and the legitimate DNS server 63 are not represented.
  • the CPE 61 issues a DNS service configuration request in the form of an RS Router Solicitation message, using its second IP address, New_@ as the source address.
  • RS is notably received by the malicious equipment 62, which responds by sending a DNS service configuration message of the router advertisement message type RA, identifying a DNS server with the @RS address (which is that of the malicious device 62).
  • the CPE then sends several DNS requests, including a request intended for the legitimate server 63 (known to the CPE) and a request intended for the server identified by the address @RS.
  • the CPE can compare the responses received, and if it detects an inconsistency in the responses (for example the malicious device 62 responds with a first address (@AS), while the legitimate DNS server 63 responds with a second address (@ test)), decide that the equipment 62 sending the router announcement message RA is malicious since it manipulates the DNS responses.
  • the remote server identified by the first @AS address is also likely malicious. The identity of this server can be included in the notification message.
  • the various steps described above can be repeated by the CPE, preferably on an irregular basis, for example when a change is detected in the local network (when a new terminal connects to the local network, leaves the local network, etc).
  • This repetition makes it possible in particular to detect fraudulent equipment which would proceed to the generation of a new identifier, for example a new MAC address, in a recurring manner.
  • the CPE can initiate an action, for example of the type of notification of an incident and/or blocking of the malicious equipment, when it detects a malicious equipment in the local area network.
  • the CPE can quarantine equipment identified as malicious.
  • quarantine modes are defined: default quarantine: in this mode, traffic originating from or destined for equipment identified as malicious is systematically blocked by the CPE.
  • blocking implements a filtering of the messages intended for or received by the malicious equipment.
  • Such filtering can in particular be based on an identifier of the malicious equipment, for example its MAC address.
  • This mode covers the case where identical SSID type identifiers are used by a home router different from the CPE and installed for example to segment LAN traffic between private traffic and professional traffic.
  • Such filtering can be temporary, for example for a duration configured in the management interface of the CPE, or permanent. It may also be reviewed following the processing of one or more incident notifications.
  • the CPE can also (alternatively or in addition) issue notifications to report an incident.
  • notification via the operator according to this mode, the CPE sends a notification of an incident to a server of the operator. This notification can then be relayed to the customer (user of the CPE, administrator of the local network), for example by using the means of communication defined under the contract subscribed by the customer (SMS messages, telephone call, email, etc.); direct notification: in this mode, the CPE sends a notification directly to the customer (SMS message, automatic call from the CPE to a customer number, display on the front screen of the CPE, etc.); HTTP redirection: in this mode, the CPE sends a notification to the client (directly or via the operator) to request authorization to redirect traffic.
  • SMS message SMS message, automatic call from the CPE to a customer number, display on the front screen of the CPE, etc.
  • HTTP redirection in this mode, the CPE sends a notification to the client (directly or via the operator) to request authorization to redirect
  • the redirection is performed, for example, the first time an anomaly has been detected.
  • the traffic generated by the malicious device can be redirected to an operator portal accessible in HTTP, and whose URL is contained in the notification sent to the customer.
  • the traffic redirected by the CPE to the operator's portal can thus make it possible to signal fraudulent behavior, and to protect the customer from any fraudulent use of his personal information, such as it may be manipulated by a malicious DNS server.
  • the quarantine can in particular be confirmed following the sending of the notifications, for example if the customer receives a notification and confirms the fraudulent nature of the incident.
  • the blocking policy can thus be updated following the processing of an incident notification.
  • Figure 7 presents a flowchart of the different steps that can be implemented by a CPE to detect the presence of malicious equipment in the local network associated with the CPE: if the CPE receives a message announcing a router (RA), the CPE can compare the source address of the sender of this message with its first identifier or identifiers (71); o if there is identity, the CPE concludes that his identity is being usurped (72), and can initiate an action (73), for example of the type of notification of an incident and/or blocking of the malicious equipment, o if there is no identity, the CPE continues the analysis; the CPE obtains configuration information (for example in a DNS configuration message or in the message announcing a router), and compares the identifier of at least one DNS server obtained from the configuration information, with the identifier of at least one legitimate server (74); o if there is no identity, the CPE concludes that another entity announces itself as a DNS server (75), and can initiate an action (73), for
  • the communication equipment is a CPE, associated with at least one network interface between the local network and the Internet network.
  • the communication equipment can be a local network terminal, a key, etc., possibly allowing connection sharing for access the local network, configured by a user with the identity of his default router as well as a list of trusted DNS servers.
  • the procedure described above is the same with the exception of quarantining. which is not implemented (since the traffic does not pass through this device).
  • FIG. 8 presents a flowchart of the different steps that can be implemented by a terminal to detect the presence of malicious equipment in the local network to which this terminal belongs. It is assumed that this terminal has been previously configured with a list of legitimate DNS servers (for example a list of IP addresses, domain names, authentication credentials) and routers (for example a list of IP addresses , DUID of the DHCP server embedded in a router) of trust (default routers within the meaning of the invention): if the terminal receives a message announcing a router for the network equipment (for example an RA message), the terminal can compare the source address of the sender of this message with the address of the trusted default router (81); o if there is no identity, the terminal concludes that a device is usurping the identity of the default router (82), and can initiate an action (83), for example of the notification of an incident type, o if there is identity, the terminal continues the analysis; the terminal obtains configuration information (for example in a DNS configuration message or in the message announcing
  • configuration information
  • the procedure described above can be activated/deactivated by the user of the communication equipment.
  • the activation or deactivation request mechanism can be executed in particular during the installation of the CPE, during a connection to the management interface of the CPE, via a notification sent by the operator, etc.
  • FIG. 9 there is presented the simplified structure of a communication equipment implementing a method for detecting malicious equipment according to an embodiment described above.
  • such equipment comprises a memory 91, comprising for example a buffer memory, a processing unit 92, equipped for example with a processor P, and controlled by the computer program Pg 93, implementing the method for detecting malicious equipment according to an embodiment described above.
  • the code instructions of the computer program 93 are for example loaded into a RAM memory before being executed by the processor of the processing unit 92.
  • the processor of the processing unit 92 implements implements the steps of the method for detecting malicious equipment according to an embodiment described above, according to the instructions of the computer program 93, for:
  • the presence of malicious equipment in the event of an anomaly in the processing of a name resolution request sent by said communication equipment using said at least one second identifier and the configuration information obtained.
  • the presence of malicious equipment can also be detected in the event of identity theft.

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)

Abstract

Procédé de détection d'un équipement malveillant dans un réseau de communication, équipement de communication et programme d'ordinateur correspondants. L'invention concerne un procédé de détection d'un équipement malveillant dans un réseau de communication, mis en œuvre dans un équipement de communication configuré (31) avec au moins un serveur de résolution de noms dit légitime associé à au moins une interface réseau via laquelle ledit équipement de communication est apte à communiquer en utilisant au moins un premier identifiant. Selon l'invention, un tel procédé comprend : - l'obtention (32) d'au moins un deuxième identifiant pour ledit équipement de communication et ladite au moins une interface réseau, distinct dudit au moins un premier identifiant, - l'obtention (33) d'informations de configuration d'un service de résolution de noms pour ledit équipement de communication utilisant ledit au moins un deuxième identifiant, - la détection (34) de la présence d'un équipement malveillant en cas d'anomalie dans le traitement d'une requête de résolution de noms émise par ledit équipement de communication en utilisant ledit au moins un deuxième identifiant et les informations de configuration obtenues.

Description

DESCRIPTION
TITRE : Procédé de détection d’un équipement malveillant dans un réseau de communication, équipement de communication 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 œuvre le protocole IP. En particulier, l'invention concerne les services IP à valeur ajoutée.
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 pour détecter la présence d'un équipement malveillant impliqué dans la résolution de noms.
2. Art antérieur
Le système DNS est une composante importante dans la fourniture des services IP.
En effet, 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 d'obtenir les adresses IPv4 et/ou IPv6 associées à un nom de domaine.
Différentes solutions peuvent être considérées pour fournir un service DNS à un terminal.
On décrit ci-après, en relation avec les figures IA à IC, des exemples reposant sur l'utilisation d'une passerelle résidentielle, encore appelée HG pour « Home Gateway » ou CPE pour « Customer Premises Equipment ».
On rappelle qu'une telle passerelle résidentielle sert classiquement d'interface entre le réseau local de l'utilisateur (« Local Area Network » (LAN), en anglais) 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 l'ensemble du trafic caractéristique des différents services souscrits par l'utilisateur, et qui supporte également un ensemble de services fournis localement aux terminaux (par exemple service FTP « File Transfer Protocol », service NFS « Network File System », serveur média, etc.).
Lors du raccordement réseau d'un CPE, l'opérateur fournit classiquement au CPE les informations nécessaires pour accéder au service de connectivité. Ainsi, l'opérateur alloue une adresse IPv4 et/ou un préfixe IPv6 qui pourront être associés au CPE pour établir des communications IPv4 et/ou IPv6 depuis/vers les terminaux connectés à ce CPE. L'opérateur fournit aussi au CPE une liste de serveurs DNS à utiliser pour la résolution de noms. Pour ce faire, des protocoles comme DHCP pour IPv4 (en anglais « Dynamic Host Configuration Protocol », en français « protocole de configuration dynamique des hôtes », tels que décrits dans les documents RFC 2131 (« Dynamic Host Configuration Protocol », R. Droms et al., mars 1997) et RFC 2132 (« DHCP Options and BOOTP Vendor Extensions », S. Alexander, mars 1997), DHCPv6 pour IPv6, tel que décrit dans le document RFC 8415 (« Dynamic Host Configuration Protocol for IPv6 (DHCPv6) », T. Mrugalski et al., novembre 2018), ou ND pour IPv6 (en anglais « Neighbor Discovery Protocol », en français « protocole de découverte des voisins », tel que décrit dans le document RFC 4861 (« Neighbor Discovery for IP version 6 (IPv6) », T. Narten et al., septembre 2007) peuvent être utilisés entre le CPE et le réseau d'accès. D'autres mécanismes tels que le protocole CWMP (« CPE WAN Management Protocol ») peuvent être utilisés pour la configuration du CPE.
Ainsi, comme illustré en Figures IA à IC, un terminal H1 11 (ou une application), présent dans un réseau local LAN, souhaite établir une communication avec un serveur distant S 12, identifié par un nom de domaine (par exemple FQ.DN, « Fully Qualified Domain Name » en anglais), par exemple « notreexemple.com ». Un client DNS embarqué dans le terminal HI 11 peut envoyer une requête DNS, encore appelée demande de résolution DNS, de type A (si le terminal supporte IPv4) et/ou AAAA (si le terminal supporte IPv6) à un des serveurs DNS 13 fourni par l'opérateur et hébergé dans le réseau d'accès (par exemple) pour obtenir les adresses IP associées au nom de domaine « notreexemple.com ».
On rappelle qu'un serveur joignable en IPv4 peut publier un enregistrement DNS de type A, alors qu'un serveur joignable en IPv6 peut publier un enregistrement de type AAAA. Un serveur joignable en IPv4 et IPv6 peut publier des enregistrements de type A et AAAA. Un terminal qui veut joindre un tel serveur doit préciser le type de l'enregistrement dans la requête DNS (A ou AAAA). Un terminal qui supporte IPv4 et IPv6 peut envoyer deux requêtes DNS : la première requête indique un enregistrement de type A et la deuxième indique un enregistrement de type AAAA.
La requête DNS peut être envoyée directement du terminal H1 11 au serveur DNS 13, comme illustré en figure IA, ou envoyée au CPE 14 lorsqu'il embarque un proxy DNS (encore appelé « forwarder DNS » tel que défini dans le document RFC 8499 - « DNS Terminology », P. Hoffman et al., janvier 2019), comme illustré en figure IB. Dans ce dernier cas, le CPE 14 peut relayer la requête DNS au serveur DNS 13 si aucune réponse n'est trouvée dans le cache local.
Le serveur DNS 13 peut répondre avec une liste d'adresses IP (par exemple @S) si au moins une entrée correspondant au nom de domaine recherché est disponible dans sa base pour le type d'enregistrement (A ou AAAA) demandé, ou relayer la requête vers un autre serveur DNS selon la structure hiérarchique de l’architecture DNS si le serveur DNS 13 ne dispose pas d'une telle entrée. La réponse reçue d'un autre serveur DNS situé plus haut dans ladite hiérarchie (serveur autoritaire., par exemple) est relayée à son tour par le serveur DNS 13 initialement sollicité vers le terminal H1 11.
La réponse DNS peut être envoyée directement du serveur DNS 13 au terminal H1 11, comme illustré en figure IA, ou envoyée au CPE 14 en cas de présence de « forwarder DNS » comme illustré en figure IB. Dans ce dernier cas, le « forwarder » du CPE 14 relaye la réponse DNS au terminal H1 11.
Comme illustré en figure IC, le terminal H1 11 peut ainsi extraire l'adresse (ou les adresses) IP contenue(s) dans la réponse (par exemple @S), puis établir une communication avec le serveur S 12, en envoyant une demande de connexion à l'une des adresses retournées (par exemple @S).
Un serveur DNS est appelé serveur nominal s’il a été déclaré, par l'opérateur via le réseau d'accès, dans un équipement de communication, typiquement lors de l'attachement de cet équipement au réseau, ou au moyen d'une configuration préalable, par exemple une configuration « usine ». Lors de cette étape, l'équipement de communication récupère l'information d'accessibilité d'un ou plusieurs serveurs DNS (nominaux) fournis par le ou les opé-rateur(s). Un opérateur peut être un fournisseur de service de connectivité, de voix sur IP, etc., et chacun de ces opérateurs peuvent ainsi fournir leur propre service DNS en hébergeant un ou plusieurs serveurs DNS au sein de leurs infrastructures. Le service peut être fourni via une infrastructure fixe ou mobile (par exemple de type PLMN, en anglais « Public Land Mobile Network »).
Par ailleurs, de nos jours, de plus en plus d'entités tierces offrent un service DNS public (« Public Resolvers », en anglais). De tels serveurs DNS sont par exemple exploités par des entités comme « Google Public DNS® », « Cloudflare® » ou Q.UAD9®.
De plus en plus de clients remplacent ou ajoutent à la configuration DNS fournie par leur opérateur, celle leur permettant d'accéder à ces serveurs DNS publics.
Un équipement de communication peut ainsi récupérer une nouvelle configuration DNS pour chacune de ses interfaces réseau actives (fixe, mobile, WLAN (en anglais « Wireless Local Area Network »), etc.). D’autres informations (par exemple, l'accessibilité de serveurs SIP (en anglais « Session Initiation Protocol »)) peuvent également être fournies à l'équipement de communication.
Un inconvénient des mécanismes de découverte des serveurs DNS au sein d'un réseau LAN est qu'ils ne sont pas sécurisés.
Par exemple, comme illustré en figure 2, lorsque le terminal H1 21 se connecte au réseau local LAN, il peut recevoir des messages d'un équipement malveillant RS 23 en réponse à ses sollicitations selon les protocoles DHCP ou ND par exemple. Ainsi, le terminal H1 21 peut recevoir un message de type annonce de routeur RA (en anglais « Router Advertisement ») en provenance de l'équipement malveillant RS 23, et considérer que l’équipement malveillant RS 23 est son routeur par défaut. Le terminai Hl 21, qui souhaite établir une communication avec le serveur distant S 22 identifié par un nom de domaine, peut alors envoyer une requête DNS à l'équipement malveillant RS 2.3, au lieu de l'envoyer au CPE 24. L'équipement malveillant RS 23 peut héberger un serveur DNS frauduleux et répondre avec l'adresse d'un serveur distant malveillant AS 25 (par exemple @AS).
Le terminal H1 21 peut ensuite extraire l'adresse (ou les adresses) IP contenue(s) dans la réponse (par exemple @AS), puis établir une communication avec le serveur malveillant AS 25.
Ce manque de mécanisme de découverte sécurisée au sein du réseau LAN peut ainsi faciliter l'exécution d'attaques qui permettent d'intercepter des données sensibles de l'utilisateur (par exemple des données personnelles) et la redirection vers des sites frauduleux comme illustré en figure
2.
Une première solution envisagée repose sur l'utilisation de certificats d'authentification.
Toutefois, une telle solution n'est pas suffisante pour détecter des équipements frauduleux. En effet, un équipement frauduleux peut présenter un certificat valide, obtenu auprès d'une autorité de certification (en anglais « Certification Authority ») valide, ce qui peut induire les équipements du LAN en erreur.
De plus, l'activation de protocoles tels que DoH (protocole de la couche application, tel que décrit dans le document RFC 8484 - « DNS Queries over HTTPS (DoH) », P. Hoffman et al., octobre 2018) ou DoT (protocole de la couche transport, tel que décrit dans le document RFC 7858 - « Specification for DNS over Transport Layer Security (TLS) » Z. Hu et al., mai 2016) ne permet pas de résoudre ce problème de sécurité car les données d'authentification doivent aussi être acquises par les équipements du LAN.
Il existe donc un besoin pour une nouvelle solution permettant de préserver la sécurité des communications des utilisateurs, tout en offrant des services à valeur ajoutée.
3. Exposé de l'invention
L'invention propose une solution pour la détection d'un équipement malveillant dans un réseau de communication, mise en œuvre dans un équipement de communication configuré avec au moins un serveur de résolution de noms dit légitime associé à au moins une interface réseau via laquelle ledit équipement de communication est apte à communiquer en utilisant au moins un premier identifiant.
Selon l'invention, un tel procédé de détection comprend :
- l'obtention d'au moins un deuxième identifiant pour ledit équipement de communication et ladite au moins une interface réseau, distinct dudit au moins un premier identifiant, - l'obtention d'informations de configuration d'un service de résolution de noms pour ledit équipement de communication utilisant ledit au moins un deuxième identifiant,
- la détection de la présence d'un équipement malveillant en cas d'anomalie dans le traitement d'une requête de résolution de noms émise par ledit équipement de communication en utilisant ledit au moins un deuxième identifiant et les informations de configuration obtenues.
L'invention permet ainsi à un équipement de communication associé à une ou plusieurs interfaces réseau (par exemple fixe, mobile, réseau local) de se faire passer pour un autre équipement, par exemple un terminal qui rejoint le réseau associé au premier identifiant (par exemple un réseau local), pour tenter de détecter la présence dans ledit réseau d'équipements malveillants impliqués lors de la résolution de noms.
Classiquement, l'équipement de communication est configuré avec au moins un serveur de résolution de noms légitime associé à au moins une interface réseau via laquelle l'équipement de communication est apte à communiquer en utilisant au moins un premier identifiant. Dans la suite, les interfaces réseaux peuvent être des interfaces physiques et/ou logiques (par exemple interface « loopback »).
Ce premier identifiant permet d'identifier de façon non ambiguë l'équipement de communication (particulièrement, l'interface utilisée) et peut être utilisé par l'équipement de communication lorsqu'il communique avec les terminaux du réseau local (par exemple pour transmettre les informations de configuration DNS).
L'équipement de communication peut par ailleurs générer, ou plus généralement obtenir, au moins un deuxième identifiant, distinct du premier identifiant, mais également destiné à être utilisé sur la même interface réseau que le premier identifiant et susceptible d'être utilisé lorsque l'équipement de communication se comporte comme un terminal connecté au même réseau local (par exemple identifié par un SSID (« Service Set Identifier » en anglais, « Identifiant d'Ensemble de Services » en français)).
De cette façon, l'équipement de communication émule un terminal du réseau local, et il est difficile pour un équipement frauduleux d'identifier que l'équipement qui utilise ledit deuxième identifiant est l'équipement de communication.
Par exemple, ledit au moins un deuxième identifiant peut comprendre : une adresse MAC, et/ou une adresse de lien-local (« link-local » en anglais), et/ou une adresse IP unicast, et/ou une adresse unique locale (ULA, « Unique Local Address » en anglais), et/ou un identifiant applicatif (jeton ou « token » en anglais).
De tels identifiants peuvent être générés de façon aléatoire, et donc non répétitive.
En particulier, la génération et l’utilisation simultanée de plusieurs identifiants, qui peuvent caractériser des couches différentes du modèle OSI (couche liaison, couche réseau, couche application, par exemple), présente l'avantage de rendre plus difficilement détectable l'émulation à laquelle se prête l'équipement de communication et de rendre le mécanisme plus robuste. Ces différents identifiants ne sont pas en conflit avec ceux utilisés par les autres terminaux du réseau local. Ceci est possible car l'équipement de communication a une visibilité sur ses propres identifiants ainsi que sur ceux utilisés par les équipements présents dans le réseau local. A noter que l'équipement de communication peut se charger de gérer tout éventuel conflit des deuxièmes identifiants si un nouveau terminal se connecte sur le réseau au moment où l'équipement de communication forge un deuxième identifiant en conflit avec ceux présentés par le nouveau terminal.
En utilisant ce deuxième identifiant, l'équipement de communication peut demander et/ou recevoir des informations pour la configuration d'un service de résolution de noms (qui peuvent faire partie d'informations de connectivité ou non), sans que les autres équipements connectés au réseau sachent qu'il est l'équipement de communication.
En particulier, en utilisant ces informations de configuration et le deuxième identifiant pour générer une requête de résolution de noms, l'équipement de communication peut détecter la présence d'un équipement potentiellement malveillant en analysant le traitement qui est fait de cette requête (et éventuellement de la réponse associée).
Selon un mode de réalisation particulier, les informations de configuration sont obtenues dans un message reçu par ledit équipement de communication, ledit message étant un message d'annonce de routeur ou un message selon le protocole DHCP reçu en réponse à un message émis par l’équipement de communication en utilisant ledit au moins un deuxième identifiant, dit message de configuration d'un service de résolution de noms.
Selon un premier exemple, le message de configuration est une réponse à une requête de configuration d'un service de résolution de noms ou une réponse à un message de sollicitation de routeur émis par l'équipement de communication. On considère selon ce premier exemple que le message de configuration est reçu en réponse à une sollicitation de l'équipement de communication. En variante, le message de configuration peut être émis spontanément par un équipement du réseau. On considère selon ce deuxième exemple que le message de configuration est reçu de façon non sollicitée, par exemple lors de l’attachement de l'équipement de communication au réseau en utilisant le deuxième identifiant. Ainsi, comme mentionné ci-avant, Se message de configuration d'un service de résolution de noms peut être une réponse à une requête de configuration d'un service de résolution de noms.
En particulier, une requête de configuration d'un service de résolution de noms peut être envoyée en multicast ou en unicast.
Par exemple, une telle requête en configuration est diffusée lorsqu'un nouvel équipement se connecte au réseau, ou lors de l'attachement de l'équipement de communication au réseau en utilisant le deuxième identifiant.
De cette façon, l'émission d'une requête en configuration d'un service de résolution de noms n'est pas mise en œuvre de façon régulière. Il est ainsi plus difficile pour l'équipement frauduleux de détecter que l'émetteur de la requête en configuration est l'équipement de communication.
Selon un mode de réalisation particulier, la requête en configuration d'un service de résolution de noms est transmise dans un message DHCP émis en utilisant le deuxième identifiant.
Les protocoles DHCP ou DHCPv6 peuvent être utilisés pour véhiculer la ou les requêtes en configuration d'un service de résolution de noms.
Comme mentionné ci-avant, le message de configuration d'un service de résolution de noms peut être obtenu en variante en réponse à un message de sollicitation de routeur.
Un message de sollicitation de routeur (ou RS, pour « Router Solicitation ») peut ainsi être émis par l'équipement de communication lorsqu’il émule un terminal en utilisant le au moins un deuxième identifiant. D'après le document RFC4861 précité, un message RS requiert l'émission par les routeurs concernés d'un message d'annonce de routeur ou RA, en anglais « Router Advertisement »), celui-ci pouvant inclure notamment des informations de configuration d'un service de résolution de noms. Suite à l'émission d'un tel message RS, l'équipement de communication écoute donc le ou les messages d'annonce de routeur répondant au message RS émis par l'équipement de communication.
Selon un mode de réalisation particulier, la présence d'un équipement malveillant peut être détectée en cas d'usurpation, dans un message reçu par ledit équipement de communication, d'une identité d'un routeur par défaut défini pour ladite au moins une interface réseau.
Un tel message peut être le message de configuration d'un service de résolution défini ci- dessus, ou un message distinct. Par exemple, un tel message est de type RA.
En particulier, l'équipement de communication peut être un CPE. Dans ce cas, l'équipement de communication peut être un routeur par défaut pour ledit réseau de communication, et la détection peut mettre en œuvre : - la comparaison d'au moins un identifiant de l'équipement émetteur dudit message reçu par ledit équipement de communication avec ledit au moins un premier identifiant dudit équipement de communication.,
- si ledit au moins un identifiant de l'équipement émetteur est identique ou corrélé audit au moins au moins un premier identifiant dudit équipement de communication, la décision selon laquelle ledit équipement émetteur est un équipement malveillant.
Par exemple, l'équipement de communication peut extraire du message reçu (message de configuration d'un service de résolution ou autre message ne comportant pas d'informations de configuration) l'adresse source de l'équipement émetteur de ce message, et vérifier si elle correspond à l'une de ses adresses (premier identifiant de l'équipement de communication, par exemple de type adresse unicast globale ou lien local du CPE). Si tel est le cas, l'équipement de communication en conclut que l'équipement émetteur usurpe son identité.
Par identifiants corrélés, on entend ici et dans toute la suite du document des identifiants liés par une relation de dépendance (par exemple un identifiant et une version codée de cet identifiant). Notamment, si l'adresse source est une adresse qui appartient à un préfixe de l'équipement de communication (par exemple un préfixe IPv6 /64), ce dernier décide qu'il y a corrélation et donc que l'équipement émetteur usurpe son identité.
Selon un autre exemple, l'équipement de communication peut être un terminal. Dans ce cas, l'équipement de communication n'est pas un routeur par défaut défini pour ledit réseau de communication, et la détection peut mettre en œuvre :
- la comparaison d'au moins un identifiant de l'équipement émetteur dudit message reçu par ledit équipement de communication avec au moins un identifiant d'un routeur défini par défaut,
- si ledit au moins un identifiant de l'équipement émetteur n'est pas identique ou corrélé audit au moins un identifiant d'un routeur défini par défaut, la décision selon laquelle ledit équipement émetteur est un équipement malveillant.
Par exemple, l'équipement de communication peut extraire du message reçu (message de configuration d'un service de résolution ou autre message ne comportant pas d'informations de configuration) l'adresse source de l'équipement émetteur de ce message, et vérifier si elle correspond à l'une des adresses d'un routeur défini par défaut.
Ainsi, si le message reçu provient d'un équipement distinct d'un routeur défini par défaut, l'équipement de communication décide que l'équipement émetteur du message est un équipement malveillant. En effet, la réception d'un tel message signifie que l'équipement émetteur de la réponse s'annonce comme routeur, alors que le routeur légitime est le routeur défini par défaut.
Selon un mode de réalisation particulier, la détection met également en œuvre :
- l'obtention, à partir des informations de configuration, d'au moins un identifiant d'au moins un serveur de résolution de noms,
- la comparaison dudit au moins un identifiant obtenu avec au moins un identifiant dudit au moins un serveur de résolution de noms légitime, et
- si ledit au moins un identifiant obtenu n'est pas identique ou corrélé audit au moins un identifiant dudit au moins un serveur de résolution de noms légitime, la décision selon laquelle ledit équipement émetteur est un équipement malveillant.
On teste de cette façon si un autre équipement du réseau annonce un ou plusieurs serveurs DNS distincts du ou des serveurs légitimes.
Selon un mode de réalisation particulier, le procédé met en œuvre, préalablement à l'étape de détection :
- l'obtention, à partir des informations de configuration, d'au moins un identifiant d'au moins un serveur de résolution de noms,
- l'émission, via l'équipement émetteur desdites informations de configuration, d'au moins une requête de résolution de noms à destination dudit au moins un serveur de résolution de noms identifié.
Dans le cas où l'équipement de communication est un CPE (et donc un routeur par défaut défini pour le réseau de communication), suite à l'émission d'une telle requête DNS, l'étape de détection met en outre en œuvre :
- si ladite requête de résolution de noms transite après son émission par ledit équipement de communication, la vérification de l'intégrité de ladite requête,
- la décision selon laquelle ledit équipement émetteur desdites informations de configuration est un équipement malveillant si ledit équipement de communication ne reçoit pas ladite requête ou si ladite requête n'est pas intègre.
En particulier, la vérification de l'intégrité de la requête de résolution de noms comprend : vérifier si ladite requête transitant par ledit équipement de communication a été modifiée par rapport à la requête d'origine et/ou a été dupliquée.
Dans le cas où l'équipement de communication est un CPE ou un terminal, suite à l'émission d'une telle requête DNS, l’étape de détection met en outre en œuvre : - si une réponse à ladite requête de résolution de noms est reçue par l'équipement de communication, la comparaison de ladite réponse, dite réponse test, avec une réponse à la même requête provenant dudit au moins un serveur de résolution de noms légitime, dite réponse légitime,
- la décision selon laquelle ledit équipement émetteur desdites informations de configuration est un équipement malveillant si ledit équipement de communication ne reçoit pas ladite réponse test ou si ladite réponse test n'est pas identique ou corrélée à ladite réponse légitime.
Selon un mode de réalisation particulier, le procédé met en œuvre au moins une action à l'issue de la détection de la présence d'un équipement malveillant, ladite au moins une action appartenant au groupe comprenant :
- la notification d'un incident,
- le blocage dudit équipement malveillant.
En particulier, la notification d'un incident appartient au groupe comprenant :
- une notification directe d'un utilisateur dudit équipement de communication (par exemple : appel automatique, SMS, etc.),
- une notification d'un utilisateur dudit équipement de communication par l'intermédiaire d'un opérateur dudit réseau (par exemple : envoi de la notification à l'opérateur, qui relaie la notification vers l'utilisateur en utilisant les moyens de communications définis au titre du contrat souscrit),
- une redirection d'URL pour demander une autorisation explicite d'un utilisateur dudit équipement de communication.
Le blocage du trafic peut quant à lui être mis en œuvre lorsque l'équipement de communication est un CPE, puisque le trafic passe par lui.
Par exemple, le blocage met en œuvre un filtrage des messages destinés ou reçus par ledit équipement malveillant.
Un tel blocage peut être temporaire ou permanent. Il peut notamment être mis en œuvre en filtrant les messages destinés à ou reçus par l'équipement malveillant, en utilisant un identifiant de l'équipement malveillant, par exemple son adresse MAC ou en refusant l'accès au réseau local audit équipement malveillant si l'équipement de communication utilise des identifiants de session uniques par terminal (par exemple, WPA-PSK (« Wi-Fi Protected Access- Pre-Shared Key ») avec des clés uniques).
Un tel blocage peut être mis en œuvre par défaut ou de manière conditionnelle, par exemple lorsqu'aucun identifiant d'au moins un serveur de résolution de noms n'est identique ou corrélé à un identifiant d'au moins un serveur de résolution de noms légitime. Les conditions de mise en place d'un tel blocage peuvent être configurées sur l'équipement de communication (par exemple mise en place immédiate du biocage si le serveur DNS ainsi découvert apparaît dans une iiste de serveurs non autorisés (« discard-list ») fournie à l'équipement de communication).
Dans un autre mode de réalisation, l'invention concerne un équipement de communication correspondant.
Par exemple, un tel équipement de communication est notamment adapté pour la mise en œuvre d'un procédé de détection d'un équipement frauduleux selon au moins un mode de réalisation de l'invention. Ainsi, un tel équipement de communication 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 de communication est de type passerelle (domestique ou d'entreprise, encore appelée « box », HG ou CPE), terminal (permettant éventuellement un partage de connexion, « tethering » en anglais), clé d'accès (« dongle » en anglais), etc.
Dans un autre mode de réalisation, l'invention concerne un ou plusieurs programmes d'ordinateur comportant des instructions pour la mise en œuvre d'un procédé de détection d'un équipement frauduleux 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 œuvre 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, un résolveur DNS (« resolver » ou « stub-resolver », en anglais), etc. Ces différents modules peuvent être embarqués dans un équipement de communication tel que décrit ci-dessus, par exemple un terminal (« User Equipment » en anglais), une clé équipée par exemple d'un port USB (« (USB) dongle » en anglais), un CPE, 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 IA, présentée en relation avec l'art antérieur, illustre un exemple de déploiement d'un service DNS sans relai DNS embarqué dans le CPE ; la figure IB, présentée en relation avec l'art antérieur, illustre un exemple de déploiement d'un service DNS avec relai DNS embarqué dans le CPE ; la figure IC, présentée en relation avec l'art antérieur, illustre un exemple d'établissement d’une connexion avec un serveur distant ; la figure 2, également présentée en relation avec l'art antérieur, illustre un exemple d'interception des requêtes DNS par un équipement malveillant ; la figure 3 présente les principales étapes d'un procédé de détection d'un équipement malveillant selon au moins un mode de réalisation de l'invention ; la figure 4, la figure 5 et la figure 6 illustrent des exemples de messages échangés entre un CPE et un équipement potentiellement malveillant ; la figure 7 présente un organigramme des différentes étapes pouvant être mises en œuvre par un CPE pour détecter la présence d'un équipement malveillant dans un réseau local ; la figure 8 présente un organigramme des différentes étapes pouvant être mises en œuvre par un terminal pour détecter la présence d’un équipement malveillant dans un réseau local ; la figure 9 présente la structure simplifiée d'un équipement de communication selon un mode de réalisation particulier.
5. Description d'un mode de réalisation de l'invention
5.1 Principe général
Le principe général de l'invention repose sur l'utilisation de différents identifiants associés à un même équipement de communication, permettant à cet équipement de communication d'émuler la présence d'un nouvel équipement dans le réseau. Une telle émulation permet notamment de détecter la présence d'un équipement malveillant dans le réseau, impliqué lors de la résolution de noms.
On présente, en relation avec la figure 3, les principales étapes mises en oeuvre par un équipement de communication selon l'invention.
Au cours d'une première étape 31, qui peut être mise en œuvre préalablement au procédé de détection selon l'invention, un équipement de communication est classiquement configuré avec au moins un serveur de résolution de noms légitime associé à au moins une interface réseau via laquelle l’équipement de communication est apte à communiquer en utilisant au moins un premier identifiant.
Pour ce faire, selon un premier exemple, l'équipement de communication obtient, pour chacune de ses interfaces réseau disponibles, des informations (noms de domaine, adresses IP, etc.) relatives à au moins un serveur de résolution de noms légitime, fournies par le réseau d'accès associé à ces interfaces (par exemple le réseau d'un opérateur). De telles informations, dites informations DNS ou configuration DNS, sont par exemple fournies à l'équipement de communication en utilisant un protocole tel que DHCP pour IPv4, DHCPv6 pour IPv6, un message d'annonce de routeur RA, une option de configuration de protocole PCO (en anglais « Protocol Configuration Option»), etc., moyennant l'utilisation d'un identifiant dédié utilisé par l'équipement de communication (par exemple une adresse MAC ou tout autre identifiant équivalent).
Selon un deuxième exemple, de telles informations DNS peuvent être configurées localement pour chacune des interfaces réseau disponibles associées à l'équipement de communication, par exemple de manière déclarative par un administrateur ou un utilisateur de l'équipement de communication. Dans un cas particulier, ces informations DNS peuvent être identiques pour toutes les interfaces réseau actives de l'équipement de communication.
L'équipement de communication ainsi configuré peut alors utiliser au moins un premier identifiant associé à l'interface réseau via laquelle il peut communiquer avec d'autres terminaux. Ce premier identifiant est par exemple une adresse MAC, une adresse IP, ou un jeton applicatif (« Token »), et permet d'identifier de façon non ambiguë l'équipement de communication.
Au cours d'une deuxième étape 32, l'équipement de communication peut obtenir (par exemple générer ou recevoir) au moins un deuxième identifiant, distinct du (ou des) premler(s) identifiant(s), pour l'équipement de communication et pour la (ou les) même(s) interface(s) réseau que le (ou les) premier(s) identifiant(s). Ce deuxième identifiant est par exemple une adresse MAC, une adresse IP de lien-local, une adresse IP unicast, une adresse unique locale, un jeton applicatif, etc. Le deuxième identifiant ainsi obtenu doit aussi être distinct de ceux utilisés par les autres équipements du réseau local (et notamment par les terminaux du réseau local).
Ce deuxième identifiant est notamment utilisé pour obtenir, au cours d'une troisième étape 33, des informations de configuration d'un service de résolution de noms.
Au cours d'une quatrième étape 34, on utilise les informations de configuration obtenues à partir du ou des deuxième(s) identîfîant(s) pour détecter la présence éventuelle d'un équipement malveillant.
Notamment, un équipement malveillant est détecté en cas d'anomalie dans le traitement d'une requête de résolution de noms émise par ledit équipement de communication en utilisant ledit au moins un deuxième identifiant et les informations de configuration obtenues.
La présence d'un équipement malveillant peut également être détectée en cas d'usurpation, dans un message reçu par l'équipement de communication, d'une identité d'un routeur par défaut défini pour ladite au moins une interface réseau. Un tel message peut éventuellement porter lesdites informations de configuration.
On peut ainsi exploiter différentes informations pour détecter la présence d'un équipement malveillant : - la réception d'un message dans lequel un équipement du réseau s'annonce comme routeur, permettant de détecter une usurpation d'identité,
- les informations de configuration (qui peuvent être reçues dans ce même message ou dans un message distinct de configuration d'un service de résolution de noms), permettant d'analyser le traitement des requêtes DNS, notamment si aucune usurpation d'identité n'est détectée.
Ainsi, la présence d'un équipement malveillant peut être détectée en cas d'usurpation d'identité ou d'anomalie dans le traitement d'une requête de résolution de noms transmise à au moins un serveur de résolution de noms identifié dans les informations de configuration.
On note que le procédé de détection présenté s'applique indépendamment du protocole de transport utilisé par le service de résolution de noms. En particulier, si l'on considère un réseau IP, le protocole de transport utilisé par les communications DNS peut être indifféremment IPv4 ou IPv6 (selon les conditions d'accès au réseau, notamment), et les échanges DNS peuvent s'appuyer sur des protocoles de la couche application (par exemple HTTPS) ou de la couche transport (par exemple QLIIC/UDP) - selon des standards tels que DoT (RFC 7858 précité), DNS-over-DTLS (RFC 8094 « DNS over Datagram Transport Layer Security (DTLS) », T. Reddy et al., février 2017), DoH (RFC 8484 précité), DNS-over-QUIC (DoQ), etc.
La solution proposée offre ainsi au moins l'un des avantages suivants, selon le mode de réalisation considéré : offrir un ensemble de services de type résolution de noms fiables et robustes, tout en minimisant les modifications des infrastructures et des protocoles existants requises pour fournir de tels services, détecter les attaques et l'interception des données au sein d'un réseau informatique (domestique ou réseau interne d'entreprise) par des équipements frauduleux, qui peuvent servir de relais pour de telles attaques, continuer d'offrir des services à valeur ajoutée, reposant notamment sur la résolution de noms, par un opérateur à ses clients, incluant l'activation d'un « forwarder » dans un CPE, améliorer la confiance de l'utilisateur envers l'opérateur auprès duquel il a souscrit de tels services de résolution de noms.
5.2 Description d'un mode de réalisation particulier
On décrit ci-après différents exemples de mise en œuvre de l'invention pour la détection de serveurs DNS frauduleux.
Par la suite, on entend par « serveur DNS légitime » un serveur de résolution de noms, qu'il soit de type serveur DNS nominal (déclaré ou configuré par l'opérateur et par exemple hébergé dans le réseau d'accès), serveur DNS public, ou serveur « alternatif ». On entend par « serveurs alternatifs » des serveurs qui ne sont pas les serveurs DNS mis en place et exploités par un opérateur. Ces serveurs alternatifs ne sont pas, en général, hébergés par le fournisseur de services IP. Ils peuvent toutefois exploiter un service DNS public.
Un tel serveur légitime peut donc être un serveur configuré par l'opérateur ou l'utilisateur. Ce serveur peut être un serveur de l'opérateur ou d'un tiers.
On entend également par la suite par « équipement malveillant » ou « équipement frauduleux » une machine du réseau de communication qui usurpe ou annonce des informations permettant d'intercepter le trafic DNS (par exemple, une machine usurpant l'identité d'un serveur DNS ou l'usurpation de l'identité du routeur par défaut via lequel transite le trafic DNS).
On note qu'aucune hypothèse n'est faite quant à la nature de l'équipement malveillant. Il peut s'agir par exemple d'un équipement installé par l'utilisateur, d'un équipement visiteur (par exemple invité), d'un équipement situé dans la zone de couverture du réseau WLAN d'un équipement d'accès au réseau de l'opérateur (CPE), etc.
Le réseau de communication est par exemple un réseau informatique domestique ou un réseau d'entreprise, également appelé réseau local ou LAN.
A titre d'exemple, on se place dans le contexte d’un équipement de communication de type CPE, associé à au moins une interface réseau entre le réseau local et le réseau d'accès, et défini comme un routeur par défaut pour les terminaux du réseau local. D'autres routeurs peuvent être déployés dans le réseau local, par exemple un routeur domestique différent du CPE et installé pour segmenter le trafic du LAN entre le trafic privé et le trafic professionnel. Toutefois, le trafic entre le réseau local et le réseau d'accès transitant par le CPE, on considère que le CPE est un routeur par défaut.
Par exemple, l'interface réseau est une interface radio (WLAN).
Comme indiqué en relation avec l'étape 31 de la figure 3, l'interface réseau peut être configurée avec des informations DNS. De telles informations DNS peuvent être fournies au CPE par le réseau d'accès (permettant de se connecter au réseau Internet), lors de la connexion du CPE au réseau d'accès, par exemple en utilisant des protocoles DHCP, DHCPv6, ou un message RA, PCO, etc. Les informations DNS peuvent également être configurées localement, de manière déclarative, par exemple via une interface de gestion du CPE.
Le CPE peut relayer les informations DNS aux différents équipements du réseau local (incluant les routeurs internes le cas échéant), en utilisant au moins un premier identifiant associé à l'interface réseau utilisée à cet effet. Par exemple, le CPE peut annoncer un ou plusieurs serveurs DNS légitimes (identifiés à partir des informations DNS associées à l'interface réseau). Ces serveurs peuvent utiliser un protocole de transport de type Do53, DoH, DoT, DoQ., etc., pour communiquer.
On peut noter que si le CPE embarque un « forwarder DNS » (ou proxy DNS), comme illustré en figure IB, le CPE peut s'annoncer dans le réseau local comme étant un serveur DNS, en utilisant au moins un premier identifiant.
Si le CPE n'embarque pas de « forwarder DNS », comme illustré en figure IA, le CPE peut annoncer dans le réseau local la liste des serveurs DNS légitimes, fournis au CPE par l'opérateur via le réseau d'accès ou configurées localement, en utilisant au moins un premier identifiant.
Dans les deux cas, l'annonce des informations DNS par le CPE met, par exemple, en œuvre le protocole DHCP pour IPv4 ou IPv6, ou ND entre le CPE et les équipements du réseau local.
Les différents équipements du réseau peuvent alors communiquer via le CPE avec des machines du réseau local ou celles connectées à Internet, via l'interface réseau, en utilisant le ou les premiers identifiants. Selon un premier exemple, le ou les premier(s) îdentifiant(s) comprennent une adresse MAC, par exemple une adresse MAC affectée à l'interface réseau qui connecte le CPE au réseau local et qui est a priori statique. Selon un deuxième exemple, le ou les premier(s) identifiant(s) peuvent être une adresse IP, un jeton applicatif, etc.
Des exemples de premiers identifiants associés à une même interface locale sont :
- une adresse MAC physique : 4F:E1:9C:6C:CA:67,
- une adresse IP : 192.168.1.1,
- une adresse IPv6 de liaison locale : fe80::c800:123:123:l.
L'adresse du serveur DNS configuré pour cette interface est par exemple : 81.253.149.10.
Afin de détecter si un équipement malveillant est présent dans le réseau local, le CPE émule un équipement du réseau local.
Pour ce faire, comme indiqué en relation avec l'étape 32 de la figure 3, le CPE génère au moins un deuxième identifiant du CPE, distinct du ou des premier(s) identifiant(s), et destiné à être utilisé sur la même interface réseau que le(s) premier(s) identifiant(s).
Selon un premier exemple, le ou les deuxième(s) iden tif ian t(s) comprennent une adresse MAC. Selon un deuxième exemple, le ou les deuxième(s) identifiant(s) comprennent une adresse de lien- local (« link-local »), une adresse unicast IP, une adresse HLA, ou un jeton applicatif, etc.
Des exemples de deuxièmes identifiants associés à la même interface locale sont
- une adresse MAC physique : 94:5C:67:AB:14:79,
- une adresse IP : 192.168.1.10, - une adresse IPv6 de liaison locale : fe80::6870:9d8e:84fe:798f,
- un jeton applicatif DUID de client DHCPv6 : 00-01-00-01-25-8E-CB-A1-14-58-D0-B7-01-DC.
Dans l'exemple ci-dessus., le jeton applicatif peut être structuré selon un format similaire à l'attribut DUID (« DHCP Unique Identifier ») défini dans le document RFC8415 précité (Section 11). Selon un autre exemple, le jeton applicatif peut être structuré selon un format similaire au champ « Cookie » défini dans le document RFC7413 « TCP Fast Open »Y. Cheng et al., décembre 2014 (Section 4.1).
En particulier, de tels éléments sont générés de façon aléatoire.
A titre d'exemple, une adresse MAC aléatoire peut être générée via une instruction de type macaddr=$(echo $FQDN | md5sum | sed 's/A\(..\)\(..\)\( ..\)\(..\)\(..\) ,*$/02:\l:\2:\3:\4:\5/’) si le CPE utilise un OS Linux, via des outils de génération externes, etc.
Aussi, le CPE peut obtenir les informations (identifiants, déclenchement de la procédure, etc.) à utiliser lors de la procédure d'émulation en utilisant un mécanisme tel que RESTCONF Call Home (tel que décrit notamment dans le document RFC8071 (« NETCONF Call Home and RESTCONF Call Home », K. Watsen et al., Février 2017).
On note que le ou les deuxième(s) identifiant(s) doivent être différent(s) du ou des premier(s) identif iant(s) utilisés par le CPE pour annoncer la liste des serveurs DNS ou s'annoncer comme serveur DNS. De cette façon, le CPE n'est pas directement identifié par les autres équipements du réseau local en tant que CPE (en particulier si le premier identifiant est de type adresse MAC statique). Ces deuxièmes identifiants sont aussi différents de ceux utilisés par les terminaux déjà connectés au réseau local.
De plus, la génération du ou des deuxième(s) identif iant(s) est, de préférence, mise en œuvre de façon aléatoire dans le temps, ou lorsqu'un nouvel équipement se connecte au réseau local.
De cette façon, on évite un comportement régulier et/ou récurrent du CPE, qui pourrait être détecté par un équipement malveillant. En effet, si un équipement malveillant identifie un tel comportement, il pourrait ignorer volontairement les demandes émanant de l'équipement émulé par le CPE.
Selon un premier mode de réalisation, afin d'émuler un terminal connecté au réseau local, le CPE peut émettre une requête de configuration d'un service DNS, envoyée en multicast ou en unicast dans le réseau local, et identifiant le CPE au moyen du ou des deuxième(s) identifiant(s). Par exemple, une telle requête de configuration d'un service DNS est émise à chaque fois qu'un nouvel équipement se connecte au réseau local. En variante, cette requête peut être envoyée uniquement à ce terminal. Un message de configuration d'un service DNS peut être reçu par le CPE, comme indiqué en relation avec l'étape 33 d'obtention d'informations de configuration de la figure 3, sur une adresse associée au deuxième identifiant, en réponse à la requête émise par le CPE. On note que différents modes d'émulation peuvent être supportés par le CPE, en fonction des protocoles supportés dans le réseau local par exemple.
Selon un premier exemple, la requête en configuration d'un service DNS est transmise dans un message DHCP émis en utilisant ledit deuxième identifiant. Dans ce cas, le message de configuration d'un service DNS reçu par le CPE peut être l'accusé de réception de cette requête.
Dans un contexte IPv4, une fois le deuxième identifiant généré par le CPE (par exemple une adresse MAC), le CPE peut se comporter comme un client DHCP, selon la procédure décrite dans les documents RFC 2131 et RFC 2132. précités. Éventuellement, le CPE peut inclure des options DNS et/ou de nouvelles options OPTION__V4__DNS_RI (telles que définies dans le document « DHCP and Router Advertisement Options for Encrypted DNS Discovery within Home Networks, M. Boucadair et al., novembre 2020) dans l'option « Parameter Request List ».
Dans un contexte IPv6, une fois le deuxième identifiant généré par le CPE (par exemple à partir du préfixe lien-local fe80::/10, différent d'un premier identifiant utilisé par le CPE pour s'annoncer comme routeur par défaut au sein du réseau local), le CPE peut se comporter comme un client DHCPv6, selon la procédure décrite dans le document RFC 8415 précité. Éventuellement, le CPE peut inclure des options DNS et/ou de nouvelles options OPTION__V6__DNS__RI (telles que définies dans « DHCP and Router Advertisement Options for Encrypted DNS Discovery within Home Networks, M. Boucadair et al., novembre 2020) dans l'option « Option Request Option (ORO) ».
Selon un deuxième exemple, la requête de configuration d'un service DNS est un message de sollicitation de routeur RS. Dans ce cas, le message de configuration d'un service DNS reçu par le CPE peut être un message d'annonce de routeur RA.
Dans un contexte IPv6, une fois le deuxième identifiant généré par le CPE, le CPE peut se comporter comme un hôte (terminal), selon la procédure décrite dans le document RFC 4861 précité. En d'autres termes, le CPE peut émettre des messages RS et écouter les messages RA.
Selon un deuxième mode de réalisation, afin d'émuler un terminal du réseau local, le CPE peut recevoir un message de configuration d'un service DNS comme indiqué en relation avec l'étape 33 d'obtentions d'informations de configuration de la figure 3, correspondant à un message d'annonce non sollicité, sur une adresse associée au deuxième identifiant. Par exemple, un tel message est un message d'annonce de routeur RA.
Quel que soit le mode de réalisation considéré (message de configuration d'un service DNS reçu par le CPE de type message d'annonce ou réponse à une requête en configuration d'un service DNS), les informations de configuration et le ou les deuxième(s) identifiant(s) sont utilisés pour émettre une requête DNS et détecter le cas échéant la présence d'un équipement malveillant en cas d'anomalie dans le traitement de la requête DNS, comme indiqué en relation avec l'étape 34 de la figure 3.
Le CPE peut, par ailleurs, recevoir un message d'un équipement s'annonçant comme routeur. Un tel message peut être le même que le message de configuration d'un service DNS (i.e. portant des informations de configuration), ou un message distinct.
Dans ce cas, le CPE peut notamment détecter la présence d'un équipement malveillant si l’identité du CPE a été usurpée ou s'il détecte une anomalie dans le traitement d'une requête DNS transmise à un serveur DNS identifié à partir des informations de configuration via l'équipement s'annonçant comme routeur.
En effet, le CPE peut vérifier l'identité de l'émetteur du message de l'équipement s'annonçant comme routeur. Par exemple, le CPE extrait du message les informations permettant d'identifier l'émetteur du message, comme une adresse MAC source, une adresse IP source, ou tout autre identifiant (par exemple jeton ou « Token » en anglais présenté dans le message).
Le ou les identifiants de l'équipement émetteur sont alors comparés avec le ou les premier(s) identifiant(s) du CPE.
S'il y a identité ou corrélation entre au moins un identifiant de l'équipement émetteur du message et au moins un premier identifiant du CPE, cela signifie que l'équipement émetteur a usurpé l'identité du CPE, et plus précisément le (ou les) premier(s) identifiant(s) du CPE. En effet, ce n'est pas le CPE qui est à l'origine de ce message, et donc la présence dudit au moins un premier identifiant dans le message comme étant la source de ce message indique au CPE que l'équipement à l'origine du message est un équipement malveillant usurpant son identité, et plus spécifiquement dans l'exemple envisagé ici, l'identité du routeur par défaut.
Le CPE détecte ainsi que l'équipement émetteur du message est un équipement malveillant, et peut engager une action en réponse à cette détection, par exemple de type notification d'un incident et/ou blocage de l'équipement malveillant.
La figure 4 illustre un exemple de messages échangés entre le CPE 41 et un équipement malveillant 42 dans la situation qui vient d'être décrite. Le CPE peut communiquer avec les autres équipements du réseau local via l'interface réseau. Pour ce faire, il dispose d'une première adresse IP, Base@, associée à un premier identifiant. Il dispose également d'une deuxième adresse IP, New_@, associée à un deuxième identifiant selon l'invention. A noter que plusieurs adresses IP peuvent être associée à une même interface, et donc à un identifiant. Le CPE 41 émet une requête en configuration d'un service DNS sous ia forme d'un message de sollicitation de routeur RS, utilisant sa deuxième adresse IP, New @ comme adresse source. Un tel message de sollicitation de routeur RS est notamment reçu par l'équipement malveillant 42, qui répond par l’envoi d'un message de configuration de service DNS de type message d'annonce de routeur RA, ayant comme adresse source la première adresse IP, Base@. Le CPE 41 détecte que l'adresse source du message d'annonce de routeur RA correspond à l'une de ses adresses (Base@), et en déduit que l'équipement 42 émetteur du message d'annonce de routeur RA est malveillant.
Le CPE peut par ailleurs vérifier, notamment dans le cas où il n'y a pas identité ou corrélation entre au moins un identifiant de l'équipement émetteur du message et au moins un premier identifiant du CPE, si l'équipement émetteur du message n'annonce pas un serveur DNS distinct du ou des serveurs DNS légitimes.
Pour ce faire, le CPE peut notamment comparer au moins un identifiant d'au moins un serveur DNS obtenu à partir des informations de configuration, avec au moins un identifiant du ou des serveurs DNS légitimes préalablement annoncés par le CPE.
S'il n'y a pas identité ou corrélation entre au moins un identifiant d'au moins un serveur DNS obtenu à partir des informations de configuration et au moins un identifiant du ou des serveurs DNS légitimes préalablement annoncés par le CPE, le CPE peut décider que l'équipement émetteur des informations de configuration est un équipement malveillant. Le CPE peut alors engager une action en réponse à cete détection, par exemple de type notification d'un incident et/ou blocage de l'équipement malveillant.
La figure 5 illustre la situation qui vient d'être décrite par un exemple de messages échangés entre le CPE 51, un équipement malveillant 52, et un serveur DNS légitime 53. Le CPE peut communiquer avec les autres équipements du réseau local via l'interface réseau. Pour ce faire, il dispose d'une première adresse IP, Base@, correspondant à un premier identifiant, et d'une deuxième adresse IP, New.. @, correspondant à un deuxième identifiant selon l'invention. Le CPE 51 émet une requête en configuration d'un service DNS sous la forme d'un message de sollicitation de routeur RS dans le réseau local LAN, utilisant sa deuxième adresse IP, New_@ comme adresse source. Un tel message RS est notamment reçu par l'équipement malveillant 52, qui répond par l'envoi d'un message RA précisant une configuration de service DNS, identifiant un serveur DNS avec l'adresse @RS (qui n'est pas celle du serveur DNS légitime 53). Dans ce cas, le CPE détecte que l'identifiant du serveur DNS obtenu à partir du message de configuration (@RS) n'est pas identique à l'identifiant du serveur DNS légitime préalablement annoncé par le CPE (@DNS), et que l'équipement 52 émetteur du message d'annonce de routeur est malveillant. Le CPE peut également vérifier, notamment dans le cas où ii y a identité ou corrélation entre au moins un identifiant d'au moins un serveur DNS obtenu à partir du message de configuration et au moins un identifiant du ou des serveurs DNS légitimes préalablement annoncés par le CPE, s'il n'y a pas d'anomalie dans le traitement de requêtes DNS.
Pour ce faire, le CPE peut envoyer une ou plusieurs requêtes DNS via l'équipement émetteur des informations de configuration d'un service DNS, et vérifier s'il (le CPE) détecte une anomalie dans le traitement de la (ou des) requête(s) DNS. Par traitement d'une requête DNS, on entend ici aussi bien la façon dont on transmet et agit sur la requête que sur la réponse qui peut être faite à cette requête.
En particulier, si l'équipement émetteur des informations de configuration embarque un « forwarder », alors la (ou les) requête(s) DNS sont envoyées à cet équipement émetteur. Sinon, la (ou les) requête(s) DNS sont envoyées vers le serveur DNS annoncé via cet équipement émetteur.
Ainsi, le CPE peut vérifier s'il reçoit bien la (ou les) requête(s) DNS, puisque dans l'exemple envisagé ici, c'est lui le routeur par défaut légitime.
Le CPE peut notamment vérifier : si les requêtes DNS sont relayées par l'équipement émetteur vers un serveur DNS du réseau local (c'est-à-dire le serveur DNS que le CPE héberge lui-même si le CPE embarque un « forwarder DNS », ou un serveur DNS fourni par le réseau local), et/ou si les requêtes DNS ont été modifiées pendant leur acheminement, et/ou si les requêtes DNS ont été dupliquées vers un autre serveur (qui peut donc être identifié comme malveillant), et/ou si les requêtes DNS ne sont pas relayées, et/ou si les réponses à ces requêtes DNS ont fait l'objet d'une interception frauduleuse ayant pu, par exemple, remettre en cause leur intégrité, etc.
Si le CPE détecte une anomalie dans le traitement d'une requête DNS transmise à au moins un serveur DNS identifié dans les informations de configuration, le CPE peut engager une action, par exemple de type notification d'un incident et/ou blocage de l'équipement malveillant.
Dans tous les cas, le CPE peut procéder à des tests supplémentaires pour vérifier si ses requêtes DNS sont acheminées vers un serveur DNS légitime (celui que le CPE héberge lui-même ou un serveur DNS configuré par un opérateur par exemple) ou un autre serveur. Dans ce dernier cas, le
CPE peut détecter que l'équipement émetteur est un équipement malveillant.
Les requêtes DNS vers les serveurs malveillants peuvent ainsi être bloquées. La figure 6 illustre un exemple des messages échangés entre le CPE 61,. un équipement malveillant 62, et un serveur DNS légitime 63. Les échanges entre l'équipement potentiellement malveillant 62 et le serveur DNS légitime 63 ne sont pas représentés. Comme pour les figures 4 et 5, le CPE 61 émet une requête en configuration d'un service DNS sous la forme d'un message de sollicitation de routeur RS, utilisant sa deuxième adresse IP, New_@ comme adresse source. Un tel message de sollicitation de routeur RS est notamment reçu par l'équipement malveillant 62, qui répond par l'envoi d'un message de configuration de service DNS de type message d'annonce de routeur RA, identifiant un serveur DNS avec l'adresse @RS (qui est celle de l'équipement malveillant 62). Le CPE émet alors plusieurs requêtes DNS, dont une requête à destination du serveur légitime 63 (connu du CPE) et une requête à destination du serveur identifié par l'adresse @RS. Le CPE peut comparer les réponses reçues, et s'il détecte une incohérence dans les réponses (par exemple l'équipement malveillant 62 répond avec une première adresse (@AS), alors que le serveur DNS 63 légitime répond avec une deuxième adresse (@test)), décider que l'équipement 62 émetteur du message d'annonce de routeur RA est malveillant puisqu'il manipule les réponses DNS. Le serveur distant identifié par la première adresse @AS est également probablement malveillant. L'identité de ce serveur peut être incluse dans le message de notification.
En particulier, les différentes étapes décrites ci-dessus peuvent être réitérées par le CPE, de préférence de façon non régulière, par exemple lorsqu'un changement est détecté dans le réseau local (lorsqu'un nouveau terminal se connecte au réseau local, quitte le réseau local, etc.).
Cette répétition permet notamment de détecter un équipement frauduleux qui procéderait à la génération d'un nouvel identifiant, par exemple une nouvelle adresse MAC, de façon récurrente.
Comme indiqué précédemment, le CPE peut engager une action, par exemple de type notification d'un incident et/ou blocage de l'équipement malveillant, lorsqu'il détecte un équipement malveillant dans le réseau local.
Le CPE peut notamment mettre en quarantaine l’équipement identifié comme malveillant. Par exemple, deux modes de mise en quarantaine sont définis : mise en quarantaine par défaut : dans ce mode, le trafic en provenance ou à destination de l'équipement identifié comme malveillant est bloqué systématiquement par le CPE. Par exemple, un tel blocage met en œuvre un filtrage des messages destinés au ou reçus par l'équipement malveillant. Un tel filtrage peut notamment reposer sur un identifiant de l'équipement malveillant, par exemple son adresse MAC. mise en quarantaine conditionnelle : dans ce mode, le trafic en provenance ou à destination de l'équipement identifié comme malveillant est bloqué seulement si des identifiants de serveurs DNS différents des identifiants de serveurs DNS connus du CPE (préalablement configurés, soit de manière déclarative, soit lors de la connexion du CPE au réseau d'accès) sont annoncées. Ce mode couvre le cas où des identifiants de type SSID identiques sont utilisés par un routeur domestique différent du CPE et installé par exemple pour segmenter le trafic du LAN entre le trafic privé et le trafic professionnel.
Un tel filtrage peut être temporaire, par exemple pour une durée paramétrée dans l'interface de gestion du CPE, ou permanent. Il peut également être revu suite au traitement d'une ou plusieurs notifications d'incident.
En effet, le CPE peut également (alternativement ou en complément) émettre des notifications permettant de signaler un incident. Par exemple, trois modes de notifications sont définis : notification via l'opérateur : selon ce mode, le CPE envoie une notification d'un incident à un serveur de l'opérateur. Cette notification peut ensuite être relayée vers le client (utilisateur du CPE, administrateur du réseau local), par exemple en utilisant les moyens de communication définis au titre du contrat souscrit par le client (messages SMS, appel téléphonique, email, etc.) ; notification directe : selon ce mode, le CPE envoie directement une notification au client (message SMS, appel automatique depuis le CPE vers un numéro du client, affichage sur l'écran frontal du CPE, etc.) ; redirection HTTP : selon ce mode, le CPE envoie une notification au client (directement ou via l'opérateur) pour lui demander l'autorisation de rediriger le trafic. La redirection est effectuée par exemple, la première fois qu'une anomalie a été détectée. Par exemple, le trafic généré par l'équipement malveillant peut être redirigé vers un portail de l'opérateur accessible en HTTP, et dont l'URL est contenue dans la notification envoyée au client. Le trafic redirigé par le CPE vers le portail de l'opérateur peut ainsi permettre de signaler le comportement frauduleux, et de protéger le client de toute utilisation frauduleuse de ses informations personnelles, telles qu'elles peuvent être manipulées par un serveur DNS malveillant.
La mise en quarantaine peut notamment être confirmée suite à l'envoi des notifications, par exemple si le client reçoit une notification et confirme la nature frauduleuse de l'incident.
La politique de blocage peut ainsi être mise à jour suite au traitement d'une notification d'incident.
A titre de résumé, la figure 7 présente un organigramme des différentes étapes pouvant être mises en œuvre par un CPE pour détecter la présence d'un équipement malveillant dans le réseau local associé au CPE : si le CPE reçoit un message annonçant un routeur (RA), le CPE peut comparer l'adresse source de l'émetteur de ce message avec son ou ses premiers identifiants (71); o s'il y a identité, le CPE conclut qu'on usurpe son identité (72), et peut engager une action (73), par exemple de type notification d'un incident et/ou blocage de l'équipement malveillant, o s'il n'y a pas identité, le CPE poursuit l'analyse ; le CPE obtient des informations de configuration (par exemple dans un message de configuration DNS ou dans le message annonçant un routeur), et compare l'identifiant d'au moins un serveur DNS obtenu à partir des informations de configuration, avec l'identifiant d'au moins un serveur légitime (74) ; o s'il n'y a pas identité, le CPE conclut qu'une autre entité s'annonce comme serveur DNS (75), et peut engager une action (73), par exemple de type notification d'un incident et/ou blocage de l'équipement malveillant, o s'il y a identité, le CPE poursuit l'analyse ; le CPE émet au moins une requête DNS (76) via l'émetteur des informations de configuration ; o s'il détecte une anomalie dans une requête DNS (77) (par exemple la requête DNS ne transite pas par le CPE, la requête DNS transitant par le CPE est modifiée par rapport à la requête DNS émise, la requête DNS est dupliquée, etc.), le CPE peut engager une action (73), par exemple de type notification d'un incident et/ou blocage de l'équipement malveillant ; o s'il ne détecte pas d'anomalie, le CPE poursuit l'analyse ; le CPE attend une réponse à la requête DNS (78) ; o s'il détecte une anomalie dans la réponse (79) (par exemple pas de réponse reçue, ou réponse reçue différente d'une réponse reçue directement d'un serveur DNS légitime), le CPE peut engager une action (73), par exemple de type notification d'un incident et/ou blocage de l'équipement malveillant ; o s'il ne détecte pas d'anomalie, le CPE peut conclure qu'il n'a pas détecté d'équipement malveillant dans le réseau local.
On a décrit ci-dessus un exemple de mise en œuvre selon lequel l'équipement de communication est un CPE, associé à au moins une interface réseau entre le réseau local et le réseau Internet.
Bien entendu, il s'agit d'un simple exemple, et l'équipement de communication peut être un terminal du réseau local, une clé, etc., permettant éventuellement un partage de connexion pour accéder au réseau local, configuré(e) par un utilisateur avec l'identité de son routeur par défaut ainsi qu'une liste de serveurs DNS de confiance. En particulier, dans le cas où un tel équipement n'établit pas de partage de connexion et ne se comporte pas comme un équipement d'accès au réseau, la procédure décrite ci-dessus est la même à l'exception de la mise en quarantaine qui n'est pas mise en œuvre (puisque le trafic ne transite pas par cet équipement).
A titre d'exemple, la figure 8 présente un organigramme des différentes étapes pouvant être mises en œuvre par un terminal pour détecter la présence d'un équipement malveillant dans le réseau local auquel appartient ce terminal. On suppose que ce terminal a été configuré au préalable avec une liste de serveurs DNS légitimes (par exemple une liste d'adresses IP, des noms de domaine, des références d'authentification) et de routeurs (par exemple une liste d'adresses IP, DUID du serveur DHCP embarqué dans un routeur) de confiance (routeurs par défaut au sens de l'invention) : si le terminal reçoit un message annonçant un routeur pour les équipements du réseau (par exemple un message RA), le terminal peut comparer l'adresse source de l'émetteur de ce message avec l'adresse du routeur par défaut de confiance (81); o s'il n'y a pas identité, le terminal conclut qu'un équipement usurpe l'identité du routeur par défaut (82), et peut engager une action (83), par exemple de type notification d'un incident, o s'il y a identité, le terminal poursuit l'analyse ; le terminal obtient des informations de configuration (par exemple dans un message de configuration DNS ou dans le message annonçant un routeur), et compare l'identifiant d'au moins un serveur DNS obtenu à partir des informations de configuration, avec l'identifiant d'au moins un serveur légitime avec lequel il a été préalablement configuré (84) ; o s'il n'y a pas identité, le terminal conclut qu'une autre entité s'annonce comme serveur DNS (85), et peut engager une action (83), par exemple de type notification d'un incident, o s’il y a identité, le terminal poursuit l'analyse ; le terminal émet au moins une requête DNS (86) via l'équipement émetteur des informations de configuration ; le terminal attend une réponse à la requête DNS (87) ; o s'il détecte une anomalie dans la réponse (88) (par exemple pas de réponse reçue, ou réponse reçue différente d'une réponse reçue d'un serveur DNS légitime), le terminal peut engager une action (73), par exemple de type notification d'un incident ; o s'il ne détecte pas d'anomalie, le terminal peut conclure qu'il n'a pas détecté d'équipement malveillant dans le réseau local. On note par ailleurs que la procédure décrite ci-dessus peut être activée/désactivée par l'utilisateur de l'équipement de communication. Le mécanisme de demande d'activation ou de désactivation peut être notamment exécuté lors de l'installation du CPE., lors d'une connexion à l'interface de gestion du CPE, via une notification envoyée par l'opérateur, etc.
5.3 Structure simplifiée de l'équipement de communication
On présente finalement, en relation avec la figure 9, la structure simplifiée d'un équipement de communication mettant en œuvre un procédé de détection d'un équipement malveillant selon un mode de réalisation décrit ci-dessus.
Comme illustré en figure 9, un tel équipement comprend une mémoire 91, comprenant par exemple une mémoire tampon, une unité de traitement 92, équipée par exemple d'un processeur P, et pilotée par le programme d'ordinateur Pg 93, mettant en œuvre le procédé de détection d'un équipement malveillant selon un mode de réalisation décrit ci-dessus.
A l'initialisation, les instructions de code du programme d'ordinateur 93 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 92. Le processeur de l'unité de traitement 92 met en œuvre les étapes du procédé de détection d'un équipement malveillant selon un mode de réalisation décrit ci-dessus, selon les instructions du programme d’ordinateur 93, pour :
- obtenir au moins un deuxième identifiant pour ledit équipement de communication et ladite au moins une interface réseau, distinct dudit au moins un premier identifiant,
- obtenir des informations de configuration d'un service de résolution de noms pour ledit équipement de communication utilisant ledit au moins un deuxième identifiant,
- détecter la présence d'un équipement malveillant en cas d'anomalie dans le traitement d'une requête de résolution de noms émise par ledit équipement de communication en utilisant ledit au moins un deuxième identifiant et les informations de configuration obtenues. Dans un mode particulier de réalisation, la présence d'un équipement malveillant peut également être détectée en cas d'usurpation d'identité.

Claims

REVENDICATIONS
1. Procédé de détection d'un équipement malveillant dans un réseau de communication, mis en œuvre dans un équipement de communication configuré (31) avec au moins un serveur de résolution de noms dit légitime associé à au moins une interface réseau via laquelle ledit équipement de communication est apte à communiquer en utilisant au moins un premier identifiant pour ledit équipement de communication et ladite au moins une interface réseau, caractérisé en ce qu'il comprend :
- l'obtention (32) d'au moins un deuxième identifiant pour ledit équipement de communication et ladite au moins une interface réseau, distinct dudit au moins un premier identifiant,
- l'obtention (33) d'informations de configuration d'un service de résolution de noms pour ledit équipement de communication utilisant ledit au moins un deuxième identifiant,
- la détection (34) de la présence d'un équipement malveillant en cas d'anomalie dans le traitement d'une requête de résolution de noms émise par ledit équipement de communication en utilisant ledit au moins un deuxième identifiant et les informations de configuration obtenues.
2. Procédé selon la revendication 1 dans lequel lesdites informations de configuration sont obtenues dans un message reçu par ledit équipement de communication, ledit message étant un message d'annonce de routeur ou un message selon le protocole DHCP en réponse à un message émis par l'équipement de communication en utilisant ledit au moins un deuxième identifiant, dit message de configuration d'un service de résolution de noms.
3. Procédé selon la revendication 1 ou 2, comprenant en outre la détection (34) de la présence d'un équipement malveillant en cas d'usurpation, dans un message reçu par ledit équipement de communication, d'une identité d'un routeur par défaut défini pour ladite au moins une interface réseau.
4. Procédé selon la revendication 3, caractérisé en ce que ledit équipement de communication est un routeur par défaut pour ledit réseau de communication, et en ce que ladite détection met en œuvre :
- la comparaison d'au moins un identifiant de l'équipement émetteur dudit message reçu par ledit équipement de communication avec ledit au moins un premier identifiant dudit équipement de communication,
- si ledit au moins un identifiant de l'équipement émetteur dudit message reçu est identique ou corrélé audit au moins au moins un premier identifiant dudit équipement de communication, la décision selon laquelle ledit équipement émetteur dudit message reçu est un équipement malveillant.
5. Procédé seton to revendication 3,. caractérisé en ce que ledit équipement de communication n'est pas un routeur par défaut défini pour ledit réseau de communication, et en ce que la détection met en œuvre :
- la comparaison d'au moins un identifiant de l'équipement émetteur dudit message reçu par ledit équipement de communication avec au moins un identifiant d'un routeur défini par défaut,
-si ledit au moins un identifiant de l'équipement émetteur dudit message reçu n'est pas identique ou corrélé audit au moins un identifiant d'un routeur défini par défaut, la décision selon laquelle ledit équipement émetteur dudit message reçu est un équipement malveillant.
6. Procédé selon l’une quelconque des revendications 1 à 5, caractérisé en ce que ladite détection met également en œuvre :
- l'obtention, à partir des informations de configuration, d'au moins un identifiant d'au moins un serveur de résolution de noms,
- la comparaison dudit au moins un identifiant obtenu avec au moins un identifiant dudit au moins un serveur de résolution de noms légitime, et
- si ledit au moins un identifiant obtenu n'est pas identique ou corrélé audit au moins un identifiant dudit au moins un serveur de résolution de noms légitime, la décision selon laquelle l'équipement émetteur desdites informations de configuration est un équipement malveillant.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il met en œuvre, préalablement à l'étape de détection :
- l'obtention, à partir des informations de configuration, d'au moins un identifiant d'au moins un serveur de résolution de noms,
- l'émission, via l'équipement émetteur desdites informations de configuration, d'au moins une requête de résolution de noms à destination dudit au moins un serveur de résolution de noms identifié.
8. Procédé selon la revendication 7, caractérisé en ce que ledit équipement de communication est un routeur par défaut défini pour ledit réseau de communication, et en ce que ladite détection met en outre en œuvre :
- si ladite requête de résolution de noms transite après son émission par ledit équipement de communication, la vérification de l'intégrité de ladite requête,
- la décision selon laquelle ledit équipement émetteur desdites informations de configuration est un équipement malveillant si ledit équipement de communication ne reçoit pas ladite requête ou si ladite requête n’est pas intègre.
9. Procédé seton to revendication 8,. caractérisé en ce que ladite vérification de l'intégrité de ia requête de résolution de noms comprend vérifier si ladite requête transitant par ledit équipement de communication a été modifiée par rapport à la requête d’origine et/ou a été dupliquée.
10. Procédé selon l'une quelconque des revendications 7 à 9, caractérisé en ce qu’il met en œuvre : - si une réponse à ladite requête de résolution de noms est reçue par l’équipement de communication, la comparaison de ladite réponse, dite réponse test, avec une réponse à la même requête provenant dudit au moins un serveur de résolution de noms légitime, dite réponse légitime,
- la décision selon laquelle ledit équipement émetteur desdites informations de configuration est un équipement malveillant si ledit équipement de communication ne reçoit pas ladite réponse test ou si ladite réponse test n’est pas identique ou corrélée à ladite réponse légitime.
11. Procédé selon l’une quelconque des revendications 1 à 10, caractérisé en ce qu'il met en œuvre au moins une action à l'issue de la détection de la présence d'un équipement malveillant, ladite au moins une action appartenant au groupe comprenant :
- la notification d'un incident,
- le blocage dudit équipement malveillant.
12. Procédé selon la revendication 11, caractérisé en ce que ledit blocage met en œuvre un filtrage des messages destinés ou reçus par ledit équipement malveillant.
13. Procédé selon la revendication 11, caractérisé en ce que ladite notification d'un incident appartient au groupe comprenant :
- une notification directe d'un utilisateur dudit équipement de communication,
- une notification d'un utilisateur dudit équipement de communication par l'intermédiaire d'un opérateur dudit réseau,
- une redirection d'URL pour demander une autorisation explicite d'un utilisateur dudit équipement de communication.
14. Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce qu'au moins une desdites étapes d'obtention d'au moins un deuxième identifiant pour ledit équipement de communication, d'obtention d'informations configuration d'un service de résolution de noms, ou de détection de la présence d'un équipement malveillant, est mise en œuvre lorsqu'un nouvel équipement se connecte audit réseau.
15. Procédé selon l'une quelconque des revendications 1 à 14 caractérisé en ce que ledit au moins un deuxième identifiant appartient au groupe comprenant
- une adresse MAC,
- une adresse IP lien-local, - une adresse IP unicast,
- une adresse unique locale,
- un identifiant applicatif.
16. Equipement de communication configuré avec au moins un serveur de résolution de noms dit légitime associé à au moins une interface réseau via laquelle ledit équipement de communication est apte à communiquer en utilisant au moins un premier identifiant pour ledit équipement de communication et ladite au moins une interface réseau, caractérisé en ce qu'il est configuré pour :
- obtenir au moins un deuxième identifiant pour ledit équipement de communication et ladite au moins une interface réseau, distinct dudit au moins un premier identifiant,
- obtenir des informations de configuration d'un service de résolution de noms pour ledit équipement de communication utilisant ledit au moins un deuxième identifiant,
- détecter la présence d'un équipement malveillant en cas d'anomalie dans le traitement d'une requête de résolution de noms émise par ledit équipement de communication en utilisant ledit au moins un deuxième identifiant et les informations de configuration obtenues.
EP21830459.0A 2020-12-01 2021-11-29 Procédé de détection d'un équipement malveillant dans un réseau de communication, équipement de communication et programme d'ordinateur correspondants Pending EP4256753A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2012481A FR3116916A1 (fr) 2020-12-01 2020-12-01 Procédé de détection d’un équipement malveillant dans un réseau de communication, équipement de communication et programme d’ordinateur correspondants.
PCT/FR2021/052128 WO2022117941A1 (fr) 2020-12-01 2021-11-29 Procédé de détection d'un équipement malveillant dans un réseau de communication, équipement de communication et programme d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP4256753A1 true EP4256753A1 (fr) 2023-10-11

Family

ID=74758963

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21830459.0A Pending EP4256753A1 (fr) 2020-12-01 2021-11-29 Procédé de détection d'un équipement malveillant dans un réseau de communication, équipement de communication et programme d'ordinateur correspondants

Country Status (5)

Country Link
US (1) US20240007484A1 (fr)
EP (1) EP4256753A1 (fr)
CN (1) CN116783867A (fr)
FR (1) FR3116916A1 (fr)
WO (1) WO2022117941A1 (fr)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10250636B2 (en) * 2016-07-07 2019-04-02 Attivo Networks Inc Detecting man-in-the-middle attacks

Also Published As

Publication number Publication date
FR3116916A1 (fr) 2022-06-03
CN116783867A (zh) 2023-09-19
WO2022117941A1 (fr) 2022-06-09
US20240007484A1 (en) 2024-01-04

Similar Documents

Publication Publication Date Title
FR2801754A1 (fr) Methode pour assigner une double adresse ip a un poste de travail relie a un reseau de transmission de donnees ip
EP1965559B1 (fr) Procédé de sécurisation d'un flux de données
EP1905194B1 (fr) Detection de double attachement entre un reseau filaire et au moins un reseau sans-fil
FR3058015A1 (fr) Procede de controle dynamique et interactif d'une passerelle residentielle connectee a un reseau de communication, dispositif et programme d'ordinateur correspondants
EP3788762A1 (fr) Procédé d'envoi d'une information et de réception d'une information pour la gestion de réputation d'une ressource ip
EP4256753A1 (fr) Procédé de détection d'un équipement malveillant dans un réseau de communication, équipement de communication et programme d'ordinateur correspondants
WO2019186006A1 (fr) Procédé de connexion sans fil d'un objet communicant à un réseau de communication local, programme d'ordinateur et équipement d'accès correspondant
WO2021074412A1 (fr) Procede de connexion d'un noeud de communication, et noeud de communication correspondant
FR2904503A1 (fr) Procede d'acces par un client a un service au travers d'un reseau, par utilisation combinee d'un protocole de configuration dynamique et d'un protocole point a point, equipement et programme d'ordinateur correspondants
WO2015197978A1 (fr) Procede de protection d'un routeur contre des attaques
WO2022136796A1 (fr) Procedes pour la redirection de trafic, terminal, controleur, serveur d'autorisation, serveurs de resolution de noms, et programme d'ordinateur correspondants
EP3815336A1 (fr) Procédés de gestion du trafic associé à un domaine client, serveur, noeud client et programme d'ordinateur correspondants
WO2023083771A1 (fr) Procédés de contrôle, de vérification et de configuration, et entités configurées pour mettre en œuvre ces procédés
EP3747238B1 (fr) Agrégation d'une pluralité de connexions radio dans un réseau sans fil
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.
WO2024121017A1 (fr) 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
WO2023242315A1 (fr) Procédé de communication entre deux équipements, premier équipement, deuxième équipement et programme d'ordinateur correspondants.
FR3124669A1 (fr) Procede et dispositif de securisation d’un reseau local comprenant un commutateur reseau auquel est reliee une station par liaison filaire
FR3052004B1 (fr) Procede d'echange de donnees entre un objet connecte et un serveur central.
WO2024068722A1 (fr) Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants
WO2023242314A1 (fr) Procédés de surveillance et de gestion d'objets communicants, équipement de confiance, serveur et objets communicants
WO2024156613A1 (fr) Procédé de révocation d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants
FR3118561A1 (fr) Procede de configuration d'une interface securisee entre un reseau de transport et un reseau elementaire d'une pluralite de reseaux elementaires federes a travers le reseau de transport ; interface associee
EP2080404B1 (fr) Serveur descripteur de région et procédé de sélection d'un réseau sans fil

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230525

AK Designated contracting states

Kind code of ref document: A1

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

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)