EP4256753A1

EP4256753A1 - Method for detecting a malicious device in a communication network, corresponding communication device and computer program

Info

Publication number: EP4256753A1
Application number: EP21830459.0A
Authority: EP
Inventors: Mohamed Boucadair; Christian Jacquenet
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2020-12-01
Filing date: 2021-11-29
Publication date: 2023-10-11
Also published as: US20240007484A1; WO2022117941A1; CN116783867A; FR3116916A1

Abstract

Method for detecting a malicious device in a communication network, corresponding communication device and computer program. The invention relates to a method for detecting a malicious device in a communication network, the method being implemented in a communication device configured (31) with at least one name resolution server which is referred to as the legitimate name resolution server and associated with at least one network interface through which the communication device is able to communicate using at least one first identifier. According to the invention, such a method comprises : - obtaining (32) at least one second identifier for the communication device and the at least one network interface, which identifier is separate from the at least one first identifier, - obtaining (33) configuration information from a name resolution service for the communication device using the at least one second identifier, - detecting (34) the presence of a malicious device in the event of an anomaly in the processing of a name resolution request sent by the communication device using the at least one second identifier and the obtained configuration information.

Description

DESCRIPTION

TITLE: Method for detecting malicious equipment in a communication network, communication equipment and corresponding computer program.

1. Field of the invention

The field of the invention is that of communications within a communication network, for example a computer network implementing the IP protocol. In particular, the invention relates to value-added IP services.

More specifically, 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.

2. Prior Art

The DNS system is an important component in the provision of IP services.

Indeed, 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 For example, the DNS service allows a terminal to obtain the IPv4 and/or IPv6 addresses associated with a domain name.

Different solutions can be considered for providing a DNS service to a terminal.

Examples based on the use of a residential gateway, also called HG for “Home Gateway” or CPE for “Customer Premises Equipment”, are described below, in relation to figures IA to IC.

It is recalled that 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). It is therefore equipment for access to an operator's network through which passes all the characteristic traffic of the various services subscribed to by the user, and which also supports a set of services provided locally to the terminals (for example FTP service “File Transfer Protocol”, NFS service “Network File System”, media server, etc.).

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. Droms et al., March 1997) and RFC 2132 ("DHCP Options and BOOTP Vendor Extensions", S. Alexander, March 1997), DHCPv6 for IPv6, as described in RFC 8415 ("Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", T. Mrugalski et al. , November 2018), or ND for 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.

Thus, as illustrated in Figures IA to IC, 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".

It is recalled that a server reachable in IPv4 can publish a type A DNS record, whereas a server reachable in 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. In the latter case, 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 (authoritative server, for example) 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.

As illustrated in figure IC, 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. During this step, 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”).

In addition, nowadays, more and more third-party entities offer a public DNS service (“Public Resolvers”, in English). Such DNS servers are for example operated by entities such as “Google Public DNS®”, “Cloudflare®” or Q.UAD9®.

More and more customers replace or add to the DNS configuration provided by their operator, the one allowing them to access these public DNS servers.

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) may also be provided to the communications equipment.

A disadvantage of DNS server discovery mechanisms within a LAN network is that they are not secure.

For example, as illustrated in FIG. 2, 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. Thus, 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

2.

A first solution envisaged is based on the use of authentication certificates.

However, such a solution is not sufficient to detect fraudulent equipment. Indeed, fraudulent equipment can present a valid certificate, obtained from a valid certification authority, which can mislead LAN equipment.

In addition, the activation of protocols such as DoH (application layer protocol, as described in RFC 8484 - "DNS Queries over HTTPS (DoH)", P. Hoffman et al., October 2018) or DoT ( transport layer protocol, as described in RFC 7858 - "Specification for DNS over Transport Layer Security (TLS)" Z. Hu et al., May 2016) does not solve this security problem because the data Authentication must also be acquired by LAN equipment.

There is therefore a need for a new solution to preserve the security of user communications, while offering value-added services.

3. Disclosure of Invention

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.

According to the invention, such a detection method comprises:

- obtaining at least one second identifier for said communication equipment and said at least one network interface, distinct from said at least one first identifier, - obtaining configuration information from a name resolution service for said communication equipment using said at least one second identifier,

- detecting 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 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.

Conventionally, 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. In the following, 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, “Identifiant d'Ensemble de Services” in French)).

In this way, 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.

For example, 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.

In particular, 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.

By using this second identifier, 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.

In particular, by using this configuration information and the second identifier to generate a name resolution request, the communication equipment can detect the presence of potentially malicious equipment by analyzing the processing of this request (and possibly of the associated response).

According to a particular embodiment, 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.

According to a first example, 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. As a variant, 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. Thus, as mentioned above, the name resolution service configuration message can be a response to a name resolution service configuration request.

In particular, a name resolution service configuration request can be sent in multicast or in unicast.

For example, 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.

In this way, the emission of a request for configuration of a name resolution service is not implemented on a regular basis. It is thus more difficult for the fraudulent equipment to detect that the sender of the configuration request is the communication equipment.

According to a particular embodiment, 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.

As mentioned above, 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. According to the aforementioned RFC4861 document, 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.

According to a particular embodiment, 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. For example, such a message is of type RA.

In particular, the communication equipment may be a CPE. In this case, 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.,

- if said at least one identifier of the transmitting equipment is identical or correlated to said at least at least one first identifier of said communication equipment, the decision that said transmitting equipment is malicious equipment.

For example, 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.

By 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). In particular, if 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. .

According to another example, the communication equipment can be a terminal. In this case, the communication equipment is not a default router defined 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 at least one identifier of a router defined by default,

- if said at least one identifier of the sender equipment is not identical or correlated to said at least one identifier of a router defined by default, the decision that said sender equipment is malicious equipment.

For example, 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.

Thus, if the message received comes from an equipment distinct from a router defined by default, 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.

According to a particular embodiment, the detection also implements:

- obtaining, from the configuration information, at least one identifier of at least one name resolution server,

- the comparison of said at least one identifier obtained with at least one identifier of said at least one legitimate name resolution server, and

- if said at least one identifier obtained is not identical or correlated to said at least one identifier of said at least one legitimate name resolution server, the decision that said transmitting equipment is malicious equipment.

In this way, we test whether another device on the network announces one or more DNS servers distinct from the legitimate server(s).

According to a particular embodiment, the method implements, prior to the detection step:

- the transmission, via the equipment transmitting said configuration information, of at least one name resolution request intended for said at least one identified name resolution server.

In the case where the communication equipment is a CPE (and therefore a default router defined for the communication network), following the transmission of such a DNS request, the detection step also implements:

- if said name resolution request transits after its transmission by said communication equipment, verification of the integrity of said request,

- the decision that said equipment sending said configuration information is malicious equipment if said communication equipment does not receive said request or if said request is not intact.

In particular, 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.

In the case where the communication equipment is a CPE or a terminal, following the transmission of such a DNS request, 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 decision that said equipment sending said configuration information is malicious equipment if said communication equipment does not receive said test response or if said test response is not identical or correlated to said legitimate response.

According to a particular embodiment, 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:

- notification of an incident,

- the blocking of said malicious equipment.

In particular, 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),

- a URL redirection to request explicit authorization from a user of said communication equipment.

Traffic blocking can be implemented when the communication equipment is a CPE, since the traffic passes through it.

For example, 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).

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).

In another embodiment, the invention relates to corresponding communication equipment.

For example, 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. Thus, such communication equipment can comprise the different characteristics relating to the method according to the invention, which can be combined or taken separately.

For example, 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.

In another embodiment, 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.

In particular, 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. 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.

4. List of Figures

Other characteristics and advantages of the invention will appear more clearly on reading the following description of a particular embodiment, given by way of a simple illustrative and non-limiting example, and the appended drawings, among which: 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.

5. Description of an embodiment of the invention

5.1 General principle

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.

In relation to FIG. 3, the main steps implemented by communication equipment according to the invention are presented.

During a first step 31, which can be implemented prior to the detection method according to the invention, 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.

To do this, according to a first example, 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). Such information, called DNS information or DNS configuration, is 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).

According to a second example, 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. In a particular case, 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.

During a second step 32, 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.

During a fourth step 34, the configuration information obtained from the second identifier(s) is used to detect the possible presence of malicious equipment.

In particular, 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.

Thus, 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.

It is noted that the detection method presented applies independently of the transport protocol used by the name resolution service. In particular, if we consider an IP network, 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.

5.2 Description of a particular embodiment

Various examples of implementation of the invention for the detection of fraudulent DNS servers are described below.

Thereafter, the term "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. “Alternative 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.

Hereinafter, the term "malicious 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).

Note that no assumption is made as to the nature of the malicious equipment. 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.

By way of example, we place ourselves in the context of 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. However, since the traffic between the local network and the access network passes through the CPE, the CPE is considered to be a default router.

For example, the network interface is a radio interface (WLAN).

As indicated in connection with step 31 of Figure 3, the network interface can be configured with DNS information. Such 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. For example, 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.

It can be noted that if the CPE embeds a “DNS forwarder” (or DNS proxy), as illustrated in FIG. 1B, the CPE can advertise itself in the local network as being a DNS server, by using at least a first identifier.

If the CPE does not have a “DNS forwarder” on board, as illustrated in figure IA, 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.

In both cases, 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. According to a first example, 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. According to a second example, the first identifier(s) can be an IP address, an application token, etc.

Examples of first identifiers associated with the same local interface are:

- a physical MAC address: 4F:E1:9C:6C:CA:67,

- an IP address: 192.168.1.1,

- a local link IPv6 address: fe80::c800:123:123:l.

The address of the DNS server configured for this interface is for example: 81.253.149.10.

In order to detect whether a malicious device is present in the local network, the CPE emulates a local network device.

To do this, as indicated in relation to step 32 of FIG. 3, 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).

According to a first example, the second identifier(s) comprise(s) a MAC address. According to a second example, the second identifier(s) comprise a link-local address (“link-local”), an IP unicast address, an HLA address, or an application token, etc.

Examples of second identifiers associated with the same local interface are

- a physical MAC address: 94:5C:67:AB:14:79,

- an IP address: 192.168.1.10, - a local link IPv6 address: fe80::6870:9d8e:84fe:798f,

- a DHCPv6 client application token DUID: 00-01-00-01-25-8E-CB-A1-14-58-D0-B7-01-DC.

In the example above, 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). According to another example, 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).

In particular, such elements are generated randomly.

For example, a random MAC address can be generated via an instruction like macaddr=$(echo $FQDN | md5sum | sed 's/ ^A $..$$..$$ ..\ )\(..$$..$ ,*$/02:\l:\2:\3:\4:\5/') if the CPE uses a Linux OS, via external build tools , etc.

Also, 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).

Note that 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 . In this way, 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.

In addition, the generation of the second identifier(s) is preferably implemented randomly over time, or when a new device connects to the local network.

In this way, regular and/or recurring behavior of the CPE is avoided, which could be detected by malicious equipment. Indeed, if a malicious device identifies such a behavior, it could deliberately ignore the requests emanating from the device emulated by the CPE.

According to a first embodiment, in order to emulate a terminal connected to the local network, the CPE 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.

According to a first example, the request for configuration of a DNS service is transmitted in a DHCP message transmitted using said second identifier. In this case, the DNS service configuration message received by the CPE can be the acknowledgment of receipt of this request.

In an IPv4 context, once the second identifier has been generated by the CPE (for example a MAC address), the CPE can behave like a DHCP client, according to the procedure described in the aforementioned RFC 2131 and RFC 2132 documents. Optionally, 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.

In an IPv6 context, once the second identifier generated by the CPE (for example from the link-local prefix fe80::/10, different from a first identifier used by the CPE to advertise itself as the default router within of the local network), the CPE can behave like a DHCPv6 client, according to the procedure described in the aforementioned RFC 8415 document. Optionally, 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)”.

According to a second example, the configuration request for a DNS service is a router request message RS. In this case, the DNS service configuration message received by the CPE can be an RA router advertisement message.

In an IPv6 context, once the second identifier has been generated by the CPE, 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.

According to a second embodiment, in order to emulate a terminal of the local network, the CPE 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. For example, such a message is an RA Router Advertisement message.

Regardless of the embodiment considered (DNS service configuration message received by the CPE of the announcement message type or response to a service configuration request DNS), 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. Such a message may be the same as a DNS service configuration message (i.e. carrying configuration information), or a separate message.

In this case, 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.

Indeed, 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.

If there is identity or correlation between at least one identifier of the equipment sending the message and at least one first identifier of the CPE, this means that 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).

To do this, 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.

If there is no identity or correlation between at least one identifier of at least one DNS server obtained from the configuration information and at least one identifier of the legitimate DNS server(s) announced beforehand 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). In this case, 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.

To do this, 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.

In particular, if the equipment sending configuration information embeds a “forwarder”, then 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.

Thus, 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.

If the CPE detects an anomaly in the processing of a DNS request transmitted to at least one DNS server identified in the configuration information, the CPE can initiate an action, for example of the type of notification of an incident and/or blocking of the malicious equipment.

In any case, 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.

DNS requests to malicious servers can thus be blocked. Figure 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. As with Figures 4 and 5, 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. Such a router request message 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.

In particular, 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.

As indicated previously, 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.

In particular, the CPE can quarantine equipment identified as malicious. For example, two 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. For example, such 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. conditional quarantine: in this mode, traffic from or to equipment identified as malicious is blocked only if DNS server identifiers different from the identifiers of DNS servers known to the CPE (configured beforehand, either declaratively, or when connecting the CPE to the access network) are announced. 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.

Indeed, the CPE can also (alternatively or in addition) issue notifications to report an incident. For example, three notification modes are defined: 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. The redirection is performed, for example, the first time an anomaly has been detected. For example, 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.

As a summary, 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 example of the notification type of an incident and/or blocking of malicious equipment, o if there is identity, the CPE continues the analysis; the CPE issues at least one DNS query (76) via the configuration information issuer; o if it detects an anomaly in a DNS request (77) (for example the DNS request does not pass through the CPE, the DNS request passing through the CPE is modified in relation to the DNS request sent, the DNS request is duplicated, etc.), the CPE can initiate an action (73), for example of the type of notification of an incident and/or blocking of the malicious equipment; o if it does not detect an anomaly, the CPE continues the analysis; the CPE waits for a response to the DNS query (78); o if it detects an anomaly in the response (79) (for example no response received, or response received different from a response received directly from a legitimate DNS server), the CPE can take action (73), for example of notification of an incident and/or blocking of malicious equipment; o if it does not detect an anomaly, the CPE can conclude that it has not detected any malicious equipment in the local network.

An exemplary implementation has been described above in which the communication equipment is a CPE, associated with at least one network interface between the local network and the Internet network.

Of course, this is a simple example, and 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. In particular, in the event that such equipment does not establish connection sharing and does not behave like network access equipment, 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).

By way of example, 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 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 with which it has been previously configured (84); o if there is no identity, the terminal concludes that another entity announces itself as a DNS server (85), and can initiate an action (83), for example of the notification of an incident type, o s there is identity, the terminal continues the analysis; the terminal sends at least one DNS request (86) via the equipment sending configuration information; the terminal waits for a response to the DNS request (87); o if it detects an anomaly in the response (88) (for example no response received, or response received different from a response received from a legitimate DNS server), the terminal can initiate an action (73), for example incident notification type; o if it does not detect an anomaly, the terminal can conclude that it has not detected any malicious equipment in the local network. It should also be noted that 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.

5.3 Simplified structure of communication equipment

Finally, in relation to 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.

As illustrated in FIG. 9, 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.

On initialization, 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:

- obtain at least one second identifier for said communication equipment and said at least one network interface, distinct from said at least one first identifier,

- obtaining configuration information from a name resolution service for said communication equipment using said at least one second identifier,

- Detecting 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. In a particular embodiment, the presence of malicious equipment can also be detected in the event of identity theft.

Claims

1. Method for detecting malicious equipment in a communication network, implemented in a communication equipment configured (31) with at least one so-called legitimate name resolution server associated with at least one network interface via which said equipment communication device is able to communicate using at least one first identifier for said communication equipment and said at least one network interface, characterized in that it comprises:

- obtaining (32) at least one second identifier for said communication equipment and said at least one network interface, distinct from said at least one first identifier,

- obtaining (33) configuration information of a name resolution service for said communication equipment using said at least one second identifier,

- detecting (34) 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 .

2. Method according to claim 1 wherein said configuration information is obtained in a message received by said communication equipment, said message being a router advertisement message or a message according to the DHCP protocol in response to a message transmitted by the communication equipment using said at least one second identifier, said name resolution service configuration message.

3. Method according to claim 1 or 2, further comprising the detection (34) of the presence of malicious equipment in the event of usurpation, in a message received by said communication equipment, of an identity of a router default defined for said at least one network interface.

4. Method according to claim 3, characterized in that said communication equipment is a default router for said communication network, and in that said detection implements:

- 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,

- If said at least one identifier of the transmitting equipment of said received message is identical or correlated to said at least at least one first identifier of said communication equipment, the decision that said transmitting equipment of said received message is malicious equipment.

5. Process according to claim 3. characterized in that said communication equipment is not a default router defined for said communication network, and in that the detection implements:

if said at least one identifier of the equipment sending said message received is not identical or correlated to said at least one identifier of a router defined by default, the decision that said equipment sending said message received is malicious equipment.

6. Method according to any one of claims 1 to 5, characterized in that said detection also implements:

- If said at least one identifier obtained is not identical or correlated to said at least one identifier of said at least one legitimate name resolution server, the decision that the equipment issuing said configuration information is malicious equipment.

7. Method according to any one of claims 1 to 6, characterized in that it implements, prior to the detection step:

8. Method according to claim 7, characterized in that said communication equipment is a default router defined for said communication network, and in that said detection further implements:

9. Process according to claim 8. characterized in that said 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.

10. Method according to any one of claims 7 to 9, characterized in that it implements: - if a response to said name resolution request is received by the communication equipment, the comparison of said response, said test response, with a response to the same request from said at least one legitimate name resolution server, said legitimate response,

11. Method according to any one of claims 1 to 10, characterized in that it implements at least one action following the detection of the presence of malicious equipment, said at least one action belonging to the group including:

- notification of an incident,

- the blocking of said malicious equipment.

12. Method according to claim 11, characterized in that said blocking implements filtering of messages intended for or received by said malicious equipment.

13. Method according to claim 11, characterized in that said notification of an incident belongs to the group comprising:

- a direct notification of a user of said communication equipment,

- a notification from a user of said communication equipment via an operator of said network,

14. Method according to any one of claims 1 to 13, characterized in that at least one of said steps of obtaining at least a second identifier for said communication equipment, of obtaining configuration information from a name resolution service, or detection of the presence of malicious equipment, is implemented when a new equipment connects to said network.

15. Method according to any one of claims 1 to 14 characterized in that said at least one second identifier belongs to the group comprising

- a MAC address,

- a link-local IP address, - a unicast IP address,

- a unique local address,

- an application identifier.

16. 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 one first identifier for said communication equipment and said at least a network interface, characterized in that it is configured for: