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