Brevet FR3053195A1 — publié le 20171229

PROCEDE ET DISPOSITIF DE CONTROLE DE FLUX DE DONNEES TRANSMIS SELON LE PROTOCOLE DNS (DOMAIN NAME SYSTEM). 1. Domaine de l'invention L'invention concerne le domaine des réseaux de télécommunications fixes et mobiles, et plus particulièrement les communications établies selon le protocole DNS (système de noms de domaine en français). 2. Art Antérieur L'accès à un réseau de communication IP (Internet Protocol en anglais) géré par un opérateur n'est en général pas gratuit pour un utilisateur. En effet, l'accès à de tels services nécessite des ressources en termes de bande passante et d'infrastructure. L'opérateur du réseau de communication offre alors l'accès à son réseau IP en échange d'une compensation financière de l'utilisateur. L'opérateur du réseau de communication IP peut par exemple proposer à l'utilisateur un abonnement pour accéder au réseau IP. Le prix de l'abonnement comprend alors l'accès au réseau IP, tel que l'Internet par exemple, et les communications nécessaires à un tel accès. Dans d'autres cas, l'utilisateur peut choisir de payer l'accès au réseau IP en fonction de son utilisation, en payant par exemple en fonction de la durée d'utilisation ou de la consommation de la bande passante. Certaines communications sur un réseau IP peuvent cependant être émises gratuitement par l'utilisateur. Par exemple, lorsque l'utilisateur dispose d'une carte prépayée pour accéder à un service de téléphonie via un réseau de communication d'un opérateur, l'utilisateur doit pouvoir accéder à un site web pour pouvoir recharger sa carte prépayée lorsque le montant de la carte prépayée est nul. L'accès au site web pour pouvoir recharger une carte prépayée doit alors pouvoir être fourni à l'utilisateur gratuitement. Un tel accès est mis en oeuvre via des échanges selon le protocole DNS à travers le réseau de communication car en général les échanges DNS entre terminaux et serveurs sont gratuits. Le protocole DNS est généralement utilisé pour permettre aux applications, telles que la navigation Internet ou les courriels, d'utiliser des noms, tels que exemple.fr par exemple, pour fonctionner, plutôt que des adresses IP difficiles à mémoriser et qui peuvent parfois changer. Par exemple, en référence avec la figure 1, lorsqu'un utilisateur entre sur le navigateur web de son terminal (T1) le nom de domaine exemple.fr, une requête DNS est envoyée (El) à un serveur de résolution DNS (RES). 3053195 2 Le serveur de résolution DNS vérifie si sa mémoire cache contient déjà l'adresse IP correspondant au nom de domaine exemple.fr. Si c'est le cas, le serveur de résolution DNS renvoie (E8) une réponse DNS comprenant l'adresse IP du nom de domaine exemple.fr au navigateur du terminal (T1) de l'utilisateur. Le navigateur peut alors envoyer (E9) une 5 requête HTTP à l'adresse IP reçue afin d'avoir accès au service fourni par un serveur (SW) à cette adresse IP. Si la mémoire cache du serveur de résolution DNS (RES) ne contient pas l'adresse IP du nom de domaine exemple.fr, le serveur de résolution DNS (RES) envoie (E2) une nouvelle demande à un serveur racine (RAC) pour trouver quel serveur (SN1) contrôle le domaine de 10 premier niveau .fr. Cette nouvelle demande émise par le serveur de résolution DNS (RES) et les suivantes sont communément appelées des requêtes récursives. En réponse à cette nouvelle demande, le serveur racine (RAC) envoie (E3) au serveur DNS (RES) l'adresse IP du serveur (SN1) contrôlant le domaine de premier niveau .fr. Le serveur de résolution DNS (RES) envoie alors (E4) une nouvelle demande au serveur (SN1), pour obtenir (E5) l'adresse 15 IP du serveur (SN2) qui contrôle le domaine exemple.fr. Ensuite, le serveur de résolution DNS (RES) envoie (E6) une nouvelle demande au serveur (SN2) qui contrôle le domaine exemple.fr pour obtenir (E7) l'adresse IP pour le nom de domaine: exemple.fr. Ensuite, le serveur de résolution DNS (RES) renvoie (E8) au navigateur du terminal (T1) de l'utilisateur une réponse DNS comprenant l'adresse IP du nom de domaine exemple.fr. 20 Avec un tel système hiérarchique, un propriétaire d'un domaine peut ainsi définir les serveurs d'autorité pour son domaine, i.e. les serveurs contrôlant le domaine. Ainsi, la destination finale recevant les requêtes DNS pour ce domaine est contrôlée par le propriétaire du domaine. Certains utilisateurs malveillants utilisent le protocole DNS afin d'accéder à des services, via 25 le réseau de communication, sans avoir à payer pour accéder au réseau de communication. Par exemple, ces utilisateurs peuvent "surfer", i.e. naviguer, sur l'Internet gratuitement ou accéder à des services via des sites web sans payer pour l'accès au réseau de communication ou l'utilisation de la bande passante. De tels utilisateurs utilisent le mécanisme de tunnel DNS (DNS tunneling en anglais) qui 30 permet d'encapsuler un autre protocole dans des échanges DNS. En référence à la figure 2, un tel mécanisme de tunnel DNS comprend un domaine contrôlé, par exemple "mytunnel.com", un serveur de tunnel DNS (TUN), et un terminal client (TC) d'un utilisateur fraudeur. Le domaine contrôlé est utilisé pour définir le serveur autoritaire faisant autorité pour ce domaine. Le serveur de tunnel DNS (TUN) est alors défini comme 35 étant un tel serveur autoritaire faisant autorité pour le domaine contrôlé "mytunnel.com". Le serveur de tunnel DNS (TUN) est généralement un serveur accessible via ('Internet et commandé par l'utilisateur du tunnel DNS. 3053195 3 Le terminal client (TC) initie une requête DNS pour le nom de domaine contrôlé "mytunnel.com" et encode les données qu'il souhaite envoyer dans la charge utile de la requête DNS, par exemple une requête HTTP vers un site web (SW). Le terminal client (TC) envoie (E21) ensuite la requête DNS pour le nom de domaine 5 contrôlé "mytunnel.com" vers le serveur de résolution DNS (RES). Le nom de domaine demandé "mytunnel.com" n'étant pas dans le cache du serveur de résolution DNS, celui-ci renvoie (E22) la requête vers le serveur racine (RAC) pour trouver quel serveur contrôle le domaine de premier niveau .com du nom de domaine demandé. Le serveur racine (RAC) renvoie (E23) au serveur de résolution DNS (RES) l'adresse du serveur (SN3) contrôlant le 10 domaine de premier niveau ".com". Le serveur de résolution DNS (RES) envoie alors (E24) une nouvelle requête au serveur (SN3) pour obtenir (E25) l'adresse du serveur contrôlant le nom de domaine "mytunnel.com". Le serveur de résolution DNS envoie alors (E26) une requête vers le serveur de tunnel DNS (TUN) contrôlant le domaine "mytunnel.com". Le serveur de tunnel DNS (TUN) décode la requête HTTP contenue dans la charge utile de la 15 requête DNS et accède (E27) via l'Internet au serveur (SW) adressé par la requête HTTP, par exemple le site www.exemple.com. Le serveur (SW) renvoie (E28) le code HTML d'une page web accessible sur le site www.exemple.com par exemple, au serveur de tunnel DNS (TUN). Le serveur de tunnel DNS (TUN) encapsule le code HTML dans un message de réponse DNS de type TXT par exemple et renvoie (E29) la réponse au serveur de résolution 20 DNS (RES) qui la transmet (E30) au terminal client (TC). Ainsi, l'utilisateur du terminal client (TC) a pu accéder au site web www.exemple.com gratuitement via le protocole DNS. De tels tunnels DNS génèrent du trafic venant perturber le réseau de communication de l'opérateur qui, en outre, n'obtient en contrepartie aucune compensation financière pour 25 l'utilisation de son réseau. L'utilisation de tunnels DNS pour la fraude, notamment sur les réseaux mobiles, représente des pertes de revenus importantes pour l'opérateur. De plus, le mécanisme de tunnel DNS est également utilisé par des utilisateurs mal intentionnés dans le but de transmettre des applications malveillantes (malware en anglais) à des terminaux d'autres utilisateurs ou de voler des informations sensibles à ces autres 30 utilisateurs. L'utilisation du mécanisme de tunnel DNS par des personnes malveillantes a donc un impact important tant pour l'opérateur du réseau de communication que pour ses utilisateurs abonnés. Pour contrôler l'utilisation des tunnels DNS par les personnes malveillantes, il est connu de 35 placer un serveur de contrôle en coupure de flux dans le réseau de communication. Un tel serveur de contrôle analyse alors tous les flux DNS transmis dans le réseau de communication et lors de la détection d'un flux DNS non autorisé, la transmission de ce flux 3053195 4 DNS est arrêtée, i.e. la requête DNS n'est pas transmise au serveur de résolution DNS. Cependant, une telle solution est coûteuse et complexe à mettre en oeuvre car le serveur de contrôle doit analyser tous les flux DNS transmis dans le réseau de communication. De plus, lorsque le serveur de contrôle est hors service, par exemple à cause d'une panne, le service 5 DNS dans son ensemble est hors service, impactant alors tous les utilisateurs du réseau de communication. 3. Exposé de l'invention L'invention vient améliorer l'état de la technique. A cet effet, elle concerne un procédé de 10 contrôle d'un flux de données transmis selon le protocole DNS, comprenant la réception, par un module de contrôle, d'une requête DNS émise par un terminal et destinée à un serveur de résolution DNS, la requête DNS comprenant une question relative à un nom de domaine, la vérification si ladite requête DNS satisfait au moins un critère prédéterminé, et lorsque ladite requête DNS vérifie ledit au moins un critère prédéterminé, la génération par le module 15 de contrôle d'une réponse DNS valide pour le serveur de résolution DNS, ladite réponse DNS comprenant au moins un élément de réponse incorrect à ladite question comprise dans ladite requête DNS reçue, et l'envoi par le module de contrôle audit serveur de résolution DNS, de ladite réponse DNS, l'étape d'envoi étant mise en oeuvre avant la réception par le serveur de résolution DNS d'une réponse reçue en provenance d'un serveur autoritaire en 20 réponse à ladite requête DNS. La vérification d'au moins un critère prédéterminé permet de détecter si la requête DNS reçue est une requête frauduleuse, i.e. si elle a été émise par un terminal d'un utilisateur fraudeur et si sa destination finale doit être le serveur autoritaire pour le nom de domaine compris dans la requête DNS. Par serveur autoritaire, on entend ici le serveur faisant 25 autorité pour ce nom de domaine, i.e. le serveur contrôlant le nom de domaine frauduleux. L'invention permet ainsi, lors de la détection d'un flux DNS issu d'une fraude, de répondre au terminal ayant émis ce flux DNS avant la réponse attendue par le terminal de l'utilisateur fraudeur. Ainsi, une réponse incorrecte est envoyée au terminal de l'utilisateur fraudeur, i.e. avec un contenu non attendu par le terminal de l'utilisateur fraudeur. La réponse envoyée 30 par le serveur de résolution DNS ne comprend ainsi pas les informations demandées par le terminal dans sa requête DNS. Cependant, la réponse DNS générée par le module de contrôle doit être valide du point de vue du serveur de résolution DNS afin que celui-ci puisse retransmettre la réponse au terminal de l'utilisateur fraudeur, sans nécessité de modifications du serveur de résolution 35 DNS. 3053195 5 Lorsque le serveur de résolution DNS reçoit ultérieurement une réponse à la requête DNS en provenance d'un serveur autoritaire, cette réponse n'est alors pas prise en compte par le serveur de résolution DNS qui a déjà envoyé une réponse au terminal. Selon un mode particulier de réalisation de l'invention, ladite requête DNS émise par le 5 terminal est reçue par le serveur de résolution DNS et transmise audit module de contrôle par ledit serveur de résolution DNS. Dans ce mode de réalisation, le module de contrôle est placé en coupure flux entre le serveur de résolution DNS et le serveur autoritaire. Selon un autre mode particulier de réalisation de l'invention, la réponse envoyée par le module de contrôle comprend la question comprise dans la requête DNS reçue par le 10 module de contrôle et éventuellement une réponse sélectionnée aléatoirement. La réponse reçue par le terminal de l'utilisateur fraudeur comprend ainsi une réponse non attendue par l'utilisateur fraudeur. Selon un autre mode particulier de réalisation de l'invention, ledit au moins un critère prédéterminé vérifie le type de la requête DNS reçue. 15 Selon un autre mode particulier de réalisation de l'invention, lorsque le type de la requête DNS est un type TXT selon le protocole DNS, l'étape de vérification dudit au moins un critère prédéterminé comprend en outre la détermination de la longueur du nom de domaine demandé dans la requête DNS, ledit critère prédéterminé étant vérifié dans le cas où la longueur du nom de domaine demandé est supérieure à un seuil prédéterminé. 20 Le type TXT d'une requête DNS est souvent utilisé, par certains fournisseurs de services pour mettre à jour des informations relatives à ces services, telles que la signature d'un fournisseur d'antivirus, ou des notifications de mises à jour. Cet usage est parfaitement valide car ici il ne s'agit pas d'établir un tunnel de communication entre le fournisseur de services et un terminal d'un utilisateur via la requête DNS. 25 Dans le mécanisme de tunnel DNS, plus la longueur du nom de domaine demandé dans la requête DNS est grande, plus le débit utilisé par le terminal de l'utilisateur fraudeur sera grand. Ainsi, la longueur du nom de domaine demandé dans une requête DNS de type TXT permet d'avoir une indication concernant la validité de la requête DNS. Selon un autre mode particulier de réalisation de l'invention, ledit au moins un critère 30 prédéterminé vérifie le nom de domaine demandé dans la requête DNS reçue par le module de contrôle, à partir d'une liste de noms de domaine légitimes, ledit au moins un critère prédéterminé étant vérifié lorsque le nom de domaine demandé n'appartient pas à ladite liste. Selon un autre mode particulier de réalisation de l'invention, ledit au moins un critère 35 prédéterminé vérifie si le nom de domaine demandé dans la requête DNS appartient à une liste noire de noms de domaines illégitimes. 3053195 6 Ce mode particulier de réalisation de l'invention permet ainsi d'avoir un premier niveau de détection rapide de requête DNS illégitimes. D'autres critères peuvent ensuite être vérifiés si le nom de domaine demandé dans la requête DNS n'appartient pas à la liste noire. Selon un autre mode particulier de réalisation de l'invention, lorsque ladite requête DNS 5 vérifie un critère prédéterminé selon l'un quelconque des modes de réalisation décrit ci- dessus, le nom de domaine demandé est ajouté dans ladite liste noire de noms de domaines illégitimes. Ce mode particulier de réalisation de l'invention permet ainsi de mettre à jour la liste noire de noms de domaine qui sont utilisés pour frauder, à partir de la détection via d'autres critères prédéterminés. 10 Selon un autre mode particulier de réalisation de l'invention, la vérification dudit au moins un critère prédéterminé est mise en oeuvre uniquement lorsque le nom de domaine demandé dans la requête DNS n'est pas présent dans un cache du serveur de résolution DNS. Avantageusement, ce mode particulier de réalisation de l'invention permet de limiter le nombre de requêtes DNS à analyser tout en restant efficace en terme de détection des 15 requêtes DNS non valides. En effet, en général, la plupart des noms de domaine demandés dans une requête DNS sont contenus dans le cache du serveur de résolution DNS. Seule une petite partie, environ 5%, des requêtes DNS reçues par le serveur de résolution DNS nécessite l'envoi de requêtes récursives vers des serveurs autoritaires pour obtenir la réponse appropriée à la requête DNS. 20 Dans le cas du mécanisme de tunnel DNS, la réponse demandée n'est jamais dans le cache du serveur de résolution DNS, puisque le but du tunnel est de s'adresser à un serveur autoritaire participant à la fraude. De plus, les utilisateurs fraudeurs modifient souvent le nom de domaine contrôlé pour la fraude pour éviter justement que ce nom de domaine soit mis en cache. 25 Ce mode de réalisation permet de ne pas impacter le service de résolution DNS dans son ensemble, ou tout au plus d'impacter seulement le trafic DNS du réseau pour lequel le nom de domaine n'est pas en cache du serveur de résolution DNS. Les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux étapes du procédé de 30 contrôle de flux de données défini ci-dessus. L'invention concerne aussi un dispositif de contrôle d'un flux de données transmis selon le protocole DNS comprenant: - un module de communication configuré pour recevoir une requête DNS émise par 35 un terminal et destinée à un serveur de résolution DNS, ladite requête DNS comprenant une question relative à un nom de domaine, 3053195 7 - un module de traitement configuré pour vérifier si ladite requête DNS satisfait au moins un critère prédéterminé, - lorsque ladite requête DNS vérifie ledit au moins un critère prédéterminé, ledit module de traitement étant configuré pour générer une réponse DNS 5 valide pour le serveur de résolution DNS, ladite réponse DNS comprenant au moins un élément de réponse incorrect à ladite question comprise dans ladite requête DNS reçue, et ledit module de communication étant configuré pour envoyer audit serveur de résolution DNS, ladite réponse DNS générée, l'envoi étant mis en oeuvre avant la réception par le serveur de résolution DNS d'une réponse reçue en provenance d'un serveur 10 autoritaire en réponse à ladite requête DNS. Ce dispositif de contrôle pourra bien sûr comporter les différentes caractéristiques relatives au procédé de contrôle selon l'invention. Ainsi, les caractéristiques et avantages de ce dispositif de contrôle sont les mêmes que ceux du procédé de contrôle, et ne sont pas détaillés plus amplement. Selon un mode particulier de réalisation de l'invention, ledit dispositif de contrôle est placé 15 entre le serveur de résolution DNS et le serveur autoritaire. Ainsi, seules les requêtes DNS pour lesquelles le serveur de résolution DNS n'a pas de réponse en cache, seront examinées par le dispositif de contrôle. Selon un mode particulier de réalisation de l'invention, le dispositif de contrôle est compris dans un terminal. Selon un autre mode particulier de réalisation de l'invention, le dispositif de contrôle est 20 compris dans un serveur de résolution DNS. L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de contrôle selon l'un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Un tel programme peut utiliser n'importe quel langage de programmation. Il peut être 25 téléchargé depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur. Le procédé de contrôle selon l'invention peut être mis en oeuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. 4. Liste des figures 30 D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 illustre des étapes d'un procédé de résolution d'adresse selon le protocole DNS selon l'art antérieur déjà expliqué ci-dessus; 35 - la figure 2 illustre des étapes d'un procédé mettant en oeuvre un mécanisme de tunnel DNS selon l'art antérieur déjà expliqué ci-dessus; la figure 3 illustre des étapes du procédé de contrôle d'un flux de données selon le 3053195 8 protocole DNS selon un mode particulier de réalisation de l'invention; la figure 4 illustre des étapes du procédé de contrôle d'un flux de données selon le protocole DNS selon un autre mode particulier de réalisation de l'invention; la figure 5 présente la structure simplifiée d'un dispositif de contrôle adapté pour 5 mettre en oeuvre le procédé de contrôle selon un mode particulier de réalisation de l'invention. 5. Description d'un mode de réalisation de l'invention 5.1 Principe général 10 Le principe général de l'invention est de contrôler les flux de données émis selon le protocole DNS lorsque ces flux de données sont émis par des terminaux d'utilisateurs malveillants qui veulent contourner les mécanismes de facturation des opérateurs de réseaux de communication ou des fournisseurs de services. Pour cela, sur réception d'une requête DNS comprenant une question relative à un nom de 15 domaine adressée à un serveur de résolution DNS, le procédé de contrôle selon l'invention vérifie si la requête DNS satisfait un critère prédéterminé, visant à détecter la fraude, et génère une réponse à la requête DNS. Une telle réponse est ensuite envoyée à l'émetteur de la requête DNS avant la réception par le serveur de résolution DNS d'une réponse à une requête DNS récursive envoyée à un serveur autoritaire. Ainsi, l'utilisateur malveillant ne 20 reçoit pas la réponse attendue et le procédé visant à contourner les mécanismes de facturation échoue. 5.2 Exemples de mise en oeuvre La figure 3 illustre des étapes du procédé de contrôle d'un flux de données selon le protocole 25 DNS selon un mode particulier de réalisation de l'invention. Un tel procédé est par exemple mis en oeuvre par un module de contrôle CTRL compris dans un serveur ou un terminal (non représenté) placé en coupure des flux DNS, i.e. sur le chemin des flux DNS dans un réseau de communication entre un terminal TC et un ou des serveurs racines de résolution DNS. De manière préférentielle, le module de contrôle CTRL est dans un serveur placé après un 30 serveur de résolution DNS désigné par la référence RES sur la figure 3. Ainsi, le module de contrôle CTRL ne vérifie que les requêtes DNS pour lesquelles le serveur RES de résolution DNS n'a pas mémorisé une réponse dans son cache. De manière alternative, le module de contrôle CTRL est compris dans un des serveurs RES de résolution DNS d'un réseau de communication. 35 Lors d'une étape E31, le terminal TC d'un utilisateur fraudeur émet une requête DNS à destination d'un serveur de résolution DNS RES. Une telle requête DNS comprend notamment une question relative à un nom de domaine, par exemple www.exemple.fr, que le 3053195 9 serveur de résolution DNS doit résoudre, i.e. pour lequel le serveur DNS doit fournir une adresse IP. Selon un mode particulier de réalisation de l'invention, lors de l'étape E31, ladite requête DNS est reçue par le serveur de résolution DNS RES. Lors d'une étape E32, le serveur de 5 résolution DNS RES vérifie que le nom de domaine compris dans la requête DNS n'est pas mémorisé dans le cache du serveur RES. Si le nom de domaine compris dans la requête DNS n'est pas mémorisé dans le cache du serveur RES, lors de l'étape E32, le serveur de résolution DNS RES envoie ladite requête DNS au module de contrôle CTRL. Toujours au cours de l'étape E32, le module de contrôle CTLR reçoit ladite requête DNS. Lors d'une 10 étape E33, le serveur de résolution DNS RES envoie de manière classique à un serveur racine RAC une requête DNS récursive basée sur la requête DNS reçue. Cette étape est similaire à l'étape E2 de la figure 1 ou E22 de la figure 2. De manière alternative, le serveur de résolution DNS RES peut envoyer une seule requête DNS récursive qui est alors transmise au module de contrôle CTRL par un routeur du réseau 15 de communication placé après le serveur RES de résolution DNS via un mécanisme de "mirroring" (miroir en français). Dans ce cas, le routeur transmet la requête DNS récursive à la fois au module de contrôle CTRL et à destination d'un serveur racine RAC du réseau de communication ou d'un serveur de contrôle d'un nom de domaine. De manière classique, lors d'une étape E330, la requête DNS récursive est transmise par le 20 serveur RES de résolution DNS à destination du serveur de tunnel TUN, tel que discuté en relation avec la figure 2. Pour plus de clarté, les différents échanges entre le serveur RES de résolution DNS et les différents serveurs autoritaires tels que décrits en relation avec la figure 2 ne sont pas repris ici. Lors d'une étape E34, le module de contrôle CTRL vérifie si ladite requête DNS satisfait au 25 moins un critère prédéterminé. Un tel critère vise à détecter si la requête DNS est une requête de contournement du système de facturation de l'opérateur du réseau de communication. Le module de contrôle CTRL peut vérifier un ou plusieurs critères de manière successive selon un ordre prédéterminé ou en parallèle. Dès qu'un critère est satisfait, i.e. dès qu'il est détecté que la requête DNS est une requête frauduleuse via un des 30 critères possibles, le procédé passe à l'étape E36. Selon d'autres modes de réalisation, dès qu'un critère est satisfait, le procédé peut continuer à vérifier d'autres critères afin de confirmer le caractère frauduleux de la requête DNS. Ce mode de réalisation permet de limiter le nombre de fausses détections. Selon des modes particuliers de réalisation de l'invention, différents critères peuvent être 35 vérifiés. Selon un premier exemple, le module de contrôle CTRL comprend dans une mémoire une liste noire de noms de domaines illégitimes. De tels noms de domaine illégitimes ont au 3053195 10 préalable été configurés par l'opérateur du réseau de communication. La liste noire est ensuite mise à jour à partir de noms de domaine détectés comme frauduleux. Le module de contrôle CTRL vérifie alors si le nom de domaine www.exemple.fr compris dans la requête DNS appartient à la liste noire. Si c'est le cas, le procédé passe à l'étape E36. Sinon, 5 d'autres critères sont vérifiés. Selon un autre exemple, le module de contrôle CTRL comprend dans une mémoire une liste blanche de noms de domaines légitimes. De tels noms de domaine légitimes ont au préalable été configurés par l'opérateur du réseau de communication. Le module de contrôle CTRL vérifie alors si le nom de domaine www.exemple.fr compris dans la requête DNS 10 appartient à la liste blanche. Si ce n'est pas le cas, la requête DNS est considérée comme frauduleuse, ou éventuellement frauduleuse. Le procédé passe alors à l'étape E36 ou d'autres critères sont vérifiés afin de confirmer le caractère frauduleux de la requête DNS. Selon un autre exemple, le module de contrôle CTRL vérifie le type de la requête DNS reçue. Par exemple, une requête DNS avec un champ type à la valeur "NULL" ou "MB", ou 15 "MG" ou "MR" est uniquement utilisée à des fins expérimentales et n'a donc pas de raisons de transiter dans un réseau de communication opérationnel. Selon un autre exemple, une requête DNS avec un champ type à la valeur "TXT" ou "WKS" est utilisée par certains fournisseurs de service dans un but bien particulier, par exemple par un mécanisme de notification d'informations ("push") ou de mises à jour de signatures de 20 fournisseurs d'antivirus. Il est à noter que lorsqu'une requête DNS frauduleuse comporte un type "TXT", la longueur du nom de domaine compris dans la requête est en général excessivement longue. Alors que lorsqu'une requête DNS qui comporte un type "TXT" est valide, i.e. émise par un fournisseur de services autorisé, le nom de domaine est relativement court. En général, une 25 telle requête DNS a une taille de l'ordre de 20-50 octets. Ainsi, lorsque le type de la requête DNS est un type "TXT", le procédé de contrôle CTRL détermine en outre la longueur du nom de domaine demandé dans la requête DNS. Dans le cas où la longueur du nom de domaine demandé est supérieure à un seuil prédéterminé, la requête DNS est détectée comme frauduleuse. La longueur du nom de domaine peut être 30 vérifiée soit par le nombre de caractères du nom de domaine demandé, le seuil prédéterminé étant alors un nombre maximal de caractères, soit par le nombre d'octets nécessaires pour représenter le nom de domaine, le seuil prédéterminé étant alors un nombre maximal d'octets, par exemple 100 octets. Selon un mode particulier de réalisation de l'invention, lorsque la requête DNS est détectée 35 comme frauduleuse à l'étape E34, la liste noire de noms de domaine illégitimes est mise à jour lors d'une étape E35 en ajoutant le nom de domaine www.exemple.fr compris dans la requête DNS si celui-ci n'est pas présent. 3053195 11 S'il n'est pas détecté que la requête DNS est une requête frauduleuse, le module de contrôle CTRL ne passe pas à l'étape E36 et le procédé prend fin. Lors de l'étape E36, le module de contrôle CTRL génère une réponse DNS à la requête DNS. Une telle réponse doit être une réponse valide pour le serveur de résolution DNS RES 5 afin que celui-ci puisse la transmettre au terminal TC de manière transparente. Ainsi, il n'est pas nécessaire de modifier le fonctionnement du procédé de résolution DNS connu. Ladite réponse DNS comprend également au moins un élément de réponse incorrect à ladite question comprise dans ladite requête DNS reçue. Selon un mode particulier de réalisation de l'invention, la réponse générée comprend la 10 question initiale comprise dans la requête DNS reçue par le module de contrôle CTRL et éventuellement une réponse sélectionnée aléatoirement. Par exemple, un élément de réponse incorrect peut être une adresse IP nulle, ou une adresse IP avec une partie manquante. Selon un autre exemple, une liste d'adresses IP incorrectes peut être définie par l'opérateur. De telles adresses peuvent par exemple pointer sur des pages blanches ou 15 comprenant du code source non interprétable par le navigateur du terminal TC, ou encore du code source comprenant des erreurs. Une adresse IP parmi cette liste peut alors être sélectionnée de manière aléatoire. En variante, l'élément de réponse incorrect peut être sélectionné aléatoirement parmi: l'adresse IP nulle, l'adresse IP avec une partie manquante ou une adresse IP de la liste précitée. 20 Lors d'une étape E37, le module de contrôle CTRL envoie au serveur de résolution DNS RES la réponse DNS générée. Cet envoi est mis en oeuvre avant que le serveur de résolution DNS RES reçoive (étape E39) une réponse en provenance du serveur autoritaire TUN en réponse à la requête DNS récursive transmise à l'étape E330. Lors de l'étape E37, le serveur de résolution DNS RES reçoit la réponse générée, avant la 25 réponse émise par le serveur TUN. Lors d'une étape E38, le serveur de résolution DNS RES transmet alors au terminal TC la réponse générée par le module de contrôle CTRL. Lors de l'étape E39, lorsque le serveur de résolution DNS RES reçoit la réponse émise par le serveur TUN, il ne traite pas cette réponse car une réponse DNS a déjà été transmise par 30 le serveur RES au terminal TC. La figure 4 illustre des étapes du procédé de contrôle d'un flux de données selon le protocole DNS selon un autre mode particulier de réalisation de l'invention. Le procédé de contrôle est ici mis en oeuvre par un module de contrôle CTRL placé entre le terminal TC et le serveur 35 RES de résolution DNS. Lors d'une étape E310, le terminal TC d'un utilisateur fraudeur émet une requête DNS à destination d'un serveur de résolution DNS RES. Une telle requête DNS comprend 3053195 12 notamment une question relative à un nom de domaine, par exemple www.exemple.fr, que le serveur de résolution DNS doit résoudre, i.e. pour lequel le serveur DNS doit fournir une adresse IP. Dans ce mode de réalisation de l'invention, selon une variante, le module de contrôle CTRL 5 intercepte (étape E310) toutes les requêtes DNS transmises dans le réseau de communication à destination du serveur RES de résolution DNS et les transmet (étape E320) ensuite au serveur RES de résolution DNS. Selon une autre variante, les requêtes DNS sont transmises au serveur RES de résolution DNS et au module de contrôle CTRL par un routeur du réseau de communication (non 10 représenté) via un mécanisme de "mirroring". Les étapes E33'-E39' et E330' sont identiques aux étapes E33-E39 et E330 respectivement décrites en relation avec la figure 3. La figure 5 présente la structure simplifiée d'un dispositif de contrôle CTRL adapté pour 15 mettre en oeuvre le procédé de contrôle selon l'un quelconque des modes particuliers de réalisation de l'invention décrits en relation avec la figure 3 ou la figure 4. Le dispositif de contrôle CTRL comprend une mémoire MEM, une unité de traitement UT, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM. Le programme d'ordinateur PG comprend des instructions pour 20 mettre en oeuvre les étapes du procédé de contrôle tel que décrit précédemment, lorsque le programme est exécuté par le processeur PROC. A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en oeuvre les étapes du 25 procédé de contrôle décrit en relation avec la figure 3 selon les instructions du programme d'ordinateur PG. Pour cela, le dispositif de contrôle comprend un module de communication COM configuré pour recevoir une requête DNS émise par un terminal et destinée à un serveur de résolution DNS, ladite requête DNS comprenant une question relative à un nom de domaine. L'unité de 30 traitement est configurée pour vérifier si ladite requête DNS satisfait au moins un critère prédéterminé, et lorsque ladite requête DNS vérifie ledit au moins un critère prédéterminé, l'unité de traitement génère une réponse DNS valide pour le serveur de résolution DNS, ladite réponse DNS comprenant au moins un élément de réponse incorrect à ladite question comprise dans ladite requête DNS reçue. Le module de communication COM est également 35 configuré pour envoyer audit serveur de résolution DNS, ladite réponse DNS générée, l'envoi étant mis en oeuvre avant la réception, par le serveur de résolution DNS, d'une réponse reçue en provenance d'un serveur autoritaire en réponse à ladite requête DNS. 3053195 13 Selon un mode particulier de réalisation de l'invention, la mémoire MEM comprend une liste noire LS1 de noms de domaine illégitimes. Selon un autre mode particulier de réalisation de l'invention, la mémoire MEM comprend une liste blanche LS2 de noms de domaine légitimes. 5 Selon un mode particulier de réalisation de l'invention, le dispositif de contrôle CTRL décrit précédemment est compris dans un terminal, ou un serveur ou un serveur de résolution DNS. REVENDICATIONS1. Procédé de contrôle d'un flux de données transmis selon un protocole de système de noms de domaine, dit DNS, comprenant: - une étape de réception (E32), par un module de contrôle (CTRL), d'une requête DNS émise par un terminal (TC) et destinée à un serveur de résolution DNS (RES), la requête DNS comprenant une question relative à un nom de domaine, - une étape de vérification (E34) si ladite requête DNS satisfait au moins un critère prédéterminé, - lorsque ladite requête DNS vérifie ledit au moins un critère prédéterminé, - une étape de génération (E36) par le module de contrôle d'une réponse DNS valide pour le serveur de résolution DNS, ladite réponse DNS comprenant au moins un élément de réponse incorrect à ladite question comprise dans ladite requête DNS reçue, - une étape d'envoi (E37) par le module de contrôle audit serveur de résolution DNS, de ladite réponse DNS, l'étape d'envoi étant mise en oeuvre avant la réception (E39) par le serveur de résolution DNS d'une réponse reçue en provenance d'un serveur autoritaire en réponse à ladite requête DNS. 2. Procédé de contrôle selon la revendication 1, dans lequel ladite requête DNS émise par le terminal est reçue par le serveur de résolution DNS et transmise audit module de contrôle par ledit serveur de résolution DNS. 3. Procédé de contrôle selon l'une quelconque des revendications 1 ou 2, dans lequel la réponse envoyée par le module de contrôle comprend la question comprise dans la requête DNS reçue par le module de contrôle et éventuellement une réponse sélectionnée aléatoirement. 4. Procédé de contrôle selon l'une quelconque des revendications 1 à 3, dans lequel ledit au moins un critère prédéterminé vérifie le type de la requête DNS reçue. 3053195 15 5. Procédé de contrôle selon la revendication 4, dans lequel, lorsque le type de la requête DNS est un type TXT selon le protocole DNS, l'étape de vérification dudit au moins un critère prédéterminé comprend en outre: - une étape de détermination de la longueur du nom de domaine demandé dans la 5 requête DNS, - dans le cas où la longueur du nom de domaine demandé est supérieure à un seuil prédéterminé, ledit critère prédéterminé est vérifié. 6. Procédé de contrôle selon la revendication 1, dans lequel ledit au moins un critère 10 prédéterminé vérifie le nom de domaine demandé dans la requête DNS reçue par le module de contrôle, à partir d'une liste de noms de domaine légitimes, ledit au moins un critère prédéterminé étant vérifié lorsque le nom de domaine demandé n'appartient pas à ladite liste. 15 7. Procédé de contrôle selon la revendication 1, dans lequel ledit au moins un critère prédéterminé vérifie si le nom de domaine demandé dans la requête DNS appartient à une liste noire de noms de domaines illégitimes. 8. Procédé de contrôle selon la revendication 6, dans lequel lorsque ladite requête DNS 20 vérifie un critère prédéterminé selon l'une quelconque des revendications 3 à 5, le nom de domaine demandé est ajouté dans ladite liste noire de noms de domaines illégitimes. 9. Procédé de contrôle selon la revendication 1, dans lequel l'étape de vérification dudit au moins un critère prédéterminé est mise en oeuvre uniquement lorsque le nom de domaine 25 demandé dans la requête DNS n'est pas présent dans un cache du serveur de résolution DNS. 10. Dispositif de contrôle (CTRL) d'un flux de données transmis selon le protocole DNS comprenant: 30 - un module de communication (COM) configuré pour recevoir une requête DNS émise par un terminal et destinée à un serveur de résolution DNS, ladite requête DNS comprenant une question relative à un nom de domaine, - un module de traitement (UT) configuré pour vérifier si ladite requête DNS satisfait au moins un critère prédéterminé, 35 - lorsque ladite requête DNS vérifie ledit au moins un critère prédéterminé, 3053195 16 ledit module de traitement étant configuré pour générer une réponse DNS valide pour le serveur de résolution DNS, ladite réponse DNS comprenant au moins un élément de réponse incorrect à ladite question comprise dans ladite requête DNS reçue, et ledit module de communication étant configuré pour envoyer audit serveur de 5 résolution DNS, ladite réponse DNS générée, l'envoi étant mis en oeuvre avant la réception par le serveur de résolution DNS d'une réponse reçue en provenance d'un serveur autoritaire en réponse à ladite requête DNS. 11. Dispositif de contrôle selon la revendication 10, ledit dispositif de contrôle étant placé 10 entre le serveur de résolution DNS et le serveur autoritaire. 12. Terminal comprenant un dispositif de contrôle selon l'une quelconque des revendications 10 ou 11. 15 13. Serveur de résolution DNS comprenant un dispositif de contrôle selon la revendication 10. 14. Programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de contrôle selon l'une quelconque des revendications 1 à 9, lorsque ledit programme est exécuté par un processeur. 20