Brevet FR3042624A1 — publié le 20170421

Procédé d'aide à la détection d'infection d'un terminal par un logiciel malveillant La présente invention concerne un procédé d'aide à la détection d'une infection d'un terminal par un logiciel malveillant. Elle trouve une application particulièrement intéressante dans la protection de réseaux et terminaux informatiques, notamment dans la détection de terminaux infectés par des logiciels malveillants tels que des virus. Les terminaux peuvent être des ordinateurs, des terminaux mobiles intelligents (on parle de « smartphone » en anglais), des tablettes, des serveurs. L'infection de terminaux informatiques au moyen de logiciels malveillants est destinée à permettre à des personnes malveillantes, ou cybercriminels, de prendre le contrôle des terminaux à distance et d'en extraire des données sensibles telles que des identifiants, des mots de passe, des données bancaires, etc. Une telle infection peut se produire de différentes façons : téléchargement depuis le terminal de fichiers infectés à travers le réseau Internet, ouverture de pièces jointes à des courriers électroniques, on parle dans ce cas d'hameçonnage ou de « phishing » en anglais. Le logiciel malveillant peut également être transmis au moyen d'un support amovible tel qu'une clé « USB » (de l' anglais « Universal Serial Bus »). L'infection peut également être consécutive à l'exploitation par le créateur du logiciel malveillant d'une vulnérabilité du terminal, par exemple une faille du navigateur, etc. Une fois que le terminal est infecté par le logiciel malveillant, il se connecte à un ou des serveurs malveillants situés dans le réseau Internet afin de recevoir des ordres ou/et d'envoyer des informations contenues dans le terminal infecté. La plupart des logiciels malveillants utilisent le protocole « http » (de l' anglais « hypertext transfer protocol ») qui constitue la majorité du trafic Internet. Les logiciels malveillants génèrent ainsi un trafic malveillant qui se fond dans un trafic légitime et qui est en outre difficile à identifier et à isoler. Les techniques habituelles de détection d'un trafic malveillant reposent essentiellement sur une recherche dans une base de signatures d' « URL » (de l' anglais « Uniform Resource Locator ») malveillantes, ou liste noire d'URL malveillantes. Ces bases recensent des ressources et des serveurs malveillants connus dans le réseau Internet. Une tentative de connexion d'un terminal vers l'une des ressources dont la signature est présente dans la base indique soit la présence effective d'un logiciel malveillant sur le terminal, soit une tentative d'infection dudit terminal. Afin de pallier ce genre d'attaque, il est habituel de mettre en place un système de surveillance du trafic réseau qui analyse l'ensemble du trafic issu du terminal afin d'identifier des communications qui peuvent être associées à un logiciel malveillant. Ainsi, lorsque le terminal émet une requête http à destination du réseau Internet, celle-ci est interceptée par le 3042624 2 système de surveillance qui analyse le contenu de la requête. Si l'URL ne fait pas partie de la liste noire, le trafic n'est pas bloqué et le logiciel à l'origine de la requête http reçoit en réponse la ressource demandée. Si l'URL comprise dans la requête est référencée dans la liste noire des URL malveillantes, la requête est bloquée et un message d'erreur est envoyé au terminal Dans 5 ce cas, et afin de lutter contre les infections, une alerte est émise à destination d'un administrateur de sécurité afin d'appliquer au plus vite des solutions de remédiation, telles qu'un anti-virus spécialisé, une mise en quarantaine du terminal, etc., avant que le logiciel malveillant n'ait eu le temps de générer des dégâts importants. Cependant, une telle solution génère de nombreux faux-positifs qui pénalisent 10 l'administration du système. Un faux-positif se définit par la génération d'une alerte d'infection pour un terminal alors que celui-ci n'est pas infecté. En effet, un grand nombre d'accès à des URL malveillantes est lié non pas à la présence d'un logiciel malveillant sur le terminal considéré, mais à des redirections et des accès automatiques utilisant des fonctionnalités du protocole http et exploitées par les attaquants pour tenter d'infecter les terminaux concernés. Par 15 exemple, une requête inoffensive émanant d'un terminal peut entraîner le chargement sur un serveur d'une page par le navigateur qui peut inclure des liens ou des redirections vers des ressources malveillantes. L'ajout de ces ressources malveillantes peut être fait par l'attaquant, par exemple par exploitation d'une vulnérabilité du serveur web contacté par le terminal, par utilisation détournée de publicités, etc. Par exemple, un utilisateur se connecte au site 20 «http://downloadmusicl.com/ » et son navigateur se connecte de manière automatique et transparente au serveur malveillant « http://lshot.ru/ » suite à une redirection par le serveur contacté. Un tel accès est qualifié d'indirect car il est consécutif à un accès à une ressource légitime du réseau, en l'espèce «http://downloadmusicl.com/ ». Le système de surveillance analyse les deux requêtes qui émanent du terminal et génère une alerte pour la deuxième requête 25 indiquant que le terminal est infecté. Ainsi, aucune distinction n'est faite par le système de surveillance entre une tentative d'infection par accès indirect, et une véritable infection qui implique une connexion directe sur un site malveillant. Un administrateur de sécurité est alors obligé d'analyser chaque alerte afin de déterminer si le terminal est réellement infecté. Cela diminue l'efficacité et l'intérêt d'une détection automatique d'infection d'un terminal, dès lors 30 que les tentatives d'infection donnent également lieu à des alertes du même niveau de criticité que les alertes représentatives de réelles infections. Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de 35 la technique et/ou d'y apporter des améliorations. 3042624 3 A cette fin, l'invention propose un procédé d'aide à la détection d'infection d'un terminal par un logiciel malveillant, comprenant : - réception en provenance du terminal d'une requête courante de demande d'accès à une ressource d'un réseau, 5 - détection que la ressource requise est malveillante, - lorsque la requête courante comprend une référence à une ressource initiale, vérification qu'un accès à la ressource initiale a été demandé depuis le terminal dans au moins une requête antérieure, ladite ressource initiale ayant été détectée légitime lors du traitement de la requête antérieure, ladite requête courante étant alors considérée comme une tentative 10 d'infection du terminal. Le procédé de détection d'infection d'un terminal permet ainsi d'améliorer la fiabilité de la détection d'infection en réduisant de façon notable le nombre de faux-positifs. Pour mémoire un faux-positif correspond à la génération d'une alerte d'infection alors que le terminal est sain, exempt d'infection. En effet, le procédé décrit permet de distinguer parmi des requêtes 15 concernant des ressources identifiées comme malicieuses, celles qui sont liées à une infection du terminal, et celles qui sont liées à une tentative d'infection. La tentative d'infection se caractérise par un accès indirect à un contenu malveillant, qui est le fruit d'une redirection ou de l'inclusion d'un lien au niveau d'un serveur ou d'une application web. Le contenu malveillant est alors chargé automatiquement par le terminal lors de l'accès à une page ou à un lien 20 référençant ce contenu. Dans ce cas, c'est le serveur à l'origine de la redirection ou du lien qui a peut-être été victime d'une attaque. Avec le procédé d'aide à la détection, un administrateur de sécurité qui reçoit des alertes d'infection ne perd pas de temps dans l'analyse de tentatives d'infection. Il peut alors réagir rapidement à des alertes qui correspondent à de réelles infections du terminal afin d'éviter la propagation d'une attaque à d'autres terminaux et des effets 25 désastreux sur le terminal. Une mise en oeuvre de l'invention a permis de filtrer plus de quatre-vingt-dix pour cent des alertes qui correspondaient à des accès indirects à des ressources malveillantes, et donc de réduire très fortement le nombre de fausses alertes qui sans ce procédé auraient été émises. Dans un exemple de réalisation, le procédé comprend, lorsque la ressource initiale dont 30 la référence est comprise dans la requête courante n'a pas été demandée par le terminal dans une requête antérieure pendant un intervalle de temps de supervision, un envoi d'une alerte représentative d'une infection du terminal Dans ce cas, la requête courante est incohérente avec les requêtes légitimes antérieures émises depuis le terminal dans un passé récent. En effet, la requête courante fait référence à une 35 ressource initiale qui figure dans le champ référent de l'entête, alors que la ressource initiale n'a 3042624 4 pas fait l'objet d'une requête depuis le terminal durant ce passé récent qui correspond à l'intervalle de supervision. Dans ce cas, il est probable qu'un cybercriminel a injecté un faux champ référent dans la requête courante de manière à faire croire que la requête courante est liée à une précédente requête émise depuis le terminal Il y a donc lieu d'envoyer une alerte, puisque 5 la requête courante a été falsifiée sur le terminal. Dans un exemple de réalisation, le procédé comprend, lorsque la ressource requise est une ressource légitime, un enregistrement de ladite ressource en association avec une valeur d'horodatage courante, représentative d'une dernière date d'accès à la ressource. Une ressource légitime requise depuis le terminal est associée à une valeur d'horodatage 10 représentative de la dernière date d'accès à la ressource. La valeur d'horodatage permet ainsi de tenir compte d'un délai normal qui sépare l'émission de requêtes successives liées par le biais de leur champ référent. Par exemple, dans le cas d'un utilisateur qui surfe sur Internet et qui accède à une première page depuis son navigateur, puis à partir de cette première page à une seconde page, on estime que le temps qui sépare l'accès à ces deux pages n'excède pas une 15 certaine durée, qui correspond dans la procédé à l'intervalle de temps de supervision. L'enregistrement des ressources légitimes requises et la prise en compte de valeurs d'horodatage associées aux requêtes relatives à ces ressources permet ainsi de tenir compte d'un lien temporel entre des requêtes liées par le biais de leur champ référent. Dans un exemple de réalisation, la ressource est enregistrée dans un historique de 20 requêtes, l'enregistrement de la ressource comprenant : - application d'au moins une fonction de hachage à une valeur binaire courante associée à la ressource, - détermination d'au moins une position courante dans un filtre de Bloom à date d'expiration à partir de ladite valeur binaire courante, ledit filtre étant associé au terminal et 25 assimilé à l'historique des requêtes, et - enregistrement de la valeur d'horodatage courante à ladite position courante du filtre. L'exemple décrit ici propose d'utiliser un filtre de Bloom à date d'expiration afin de gérer un historique de requêtes à des ressources légitimes. Les filtres de Bloom sont des structures de données compactes, bien adaptées pour mémoriser un très grand nombre de 30 données et pour être interrogées sur la présence ou l'absence d'un élément donné dans le filtre. Ainsi, les filtres de Bloom permettent d'obtenir des performances très intéressantes lors d'une mise en oeuvre en temps réel du procédé d' aide à la détection d'infection d'un terminal par un logiciel malveillant. Le filtre de Bloom à date d'expiration enregistre dans une entrée du filtre une valeur d'horodatage qui est associée ici à la dernière date d'accès à la ressource légitime qui 35 figure dans la requête légitime. 3042624 5 Par ailleurs l'utilisation d'un filtre de Bloom pour enregistrer des informations sur les requêtes légitimes émises depuis le terminal préserve l'anonymat des utilisateurs à l'origine des requêtes. En effet, les filtres de Bloom enregistrent des valeurs d'horodatage associées à des requêtes, les requêtes étant uniquement utilisées pour calculer une position dans le filtre. Ainsi, 5 une fois qu'une position a été calculée en association avec une requête, aucune information quant au contenu de la requête n'est stockée dans le filtre. Cet aspect est fondamental pour le respect de la vie privée des utilisateurs, notamment dans le cas où la solution d'aide à la détection d'infection d'un terminal est mise en oeuvre dans le réseau. Dans un exemple d'utilisation du filtre de Bloom décrit précédemment, une recherche 10 d'une ressource initiale dans le filtre comprend : - application de la fonction de hachage à une valeur binaire initiale associée à la ressource initiale, - détermination d'au moins une position dans le filtre de Bloom à partir de ladite valeur binaire initiale, 15 - sélection, parmi la au moins une position, de la position dans le filtre qui comprend la valeur d'horodatage la plus faible, - lorsque la durée comprise entre la valeur d'horodatage la plus faible et une date courante est inférieure à une durée d'expiration associée au filtre, indication que la ressource initiale figure dans l'historique. 20 Cet exemple décrit les étapes qui sont mises en oeuvre pour rechercher si une ressource initiale qui est référencée dans une requête courante figure ou non dans l'historique des requêtes. Dans un exemple de réalisation, le filtre de Bloom est associé au terminal et à au moins un champ compris dans un entête de la requête courante. 25 Dans cet exemple, il est tenu compte d'un contexte propre aux requêtes émises depuis le terminal pour la gestion de l'historique. Ainsi, un historique est associé non seulement au terminal mais également à un contexte d'émission des requêtes. Le contexte comprend par exemple l'application à l'origine de la requête, le langage dans lequel le terminal souhaite recevoir une réponse, etc. Les éléments du contexte sont par exemple des champs qui peuvent 30 être présents dans les requêtes émises depuis le terminal. Ainsi, il peut y avoir une pluralité d'historiques gérés pour un seul terminal. Cela permet de pallier un cas où un cybercriminel renseigne dans des requêtes à des ressources malveillantes qu'il fait émettre depuis le terminal un champ référent à une ressource populaire qui a de fortes chances d'être présente dans l'historique des ressources légitimes 35 requises depuis le terminal Ce cas correspond à un contournement de la solution proposée par 3042624 6 le procédé afin d'écarter des alertes les accès indirects à des ressources malveillantes, et qui consiste à vérifier, lorsqu'un champ référent est présent dans une requête courante à une ressource malveillance, que la ressource qui figure dans le champ référent a été requise précédemment depuis le terminal. 5 L'invention porte également un dispositif d'aide à la surveillance d'un trafic réseau, agencé pour aider à la détection d'infection d'un terminal par un logiciel malveillant, ledit dispositif comprenant : - des moyens de réception, agencés pour recevoir en provenance du terminal une requête courante de demande d'accès à une ressource d'un réseau, 10 - des moyens de détection, agencés pour détecter que la ressource requise est malveillante, - des moyens de vérification, agencés pour vérifier, lorsque la requête courante comprend une référence à une ressource initiale, que l'accès à la ressource initiale a été demandé depuis le terminal dans au moins une requête antérieure, ladite ressource initiale ayant 15 été détectée légitime lors du traitement de la requête antérieure, ladite requête courante étant alors considérée comme une tentative d'infection du terminal. Dans un exemple de réalisation, le dispositif d'aide à la surveillance est intégré dans un terminal utilisateur. Dans cet exemple, le dispositif de surveillance est intégré dans le terminal. Il s'agit par 20 exemple d'un logiciel anti-virus ou anti-malware installé sur le terminal L'invention concerne aussi un programme d'ordinateur sur un support de données et chargeable dans la mémoire d'un ordinateur, le programme comprenant des portions de code pour l'exécution des étapes du procédé d'aide à la détection d'infection d'un terminal par un logiciel malveillant tel que décrit précédemment, lorsque le programme est exécuté sur ledit 25 ordinateur. L'invention porte également sur un support de données dans lequel est enregistré le programme précédent. D'autres caractéristiques et avantages de la présente invention seront mieux compris de 30 la description et des dessins annexés parmi lesquels : - la figure 1 présente les étapes d'un procédé d'aide à la détection de l'infection d'un terminal par un logiciel malveillant, selon un exemple de réalisation ; - les figures 2a et 2b présentent des exemples de réalisation des étapes de mise à jour de l'historique des requêtes et de recherche dans l'historique ; 3042624 7 - les figures 3a, 3b et 3c illustrent l'utilisation de filtres de Bloom pour la mise en oeuvre du procédé, selon différents exemples de réalisation ; - la figure 4 est une représentation schématique d'un dispositif de surveillance de trafic utilisé pour la mise en oeuvre du procédé, selon un exemple de réalisation. 5 Les étapes d'un procédé d'aide à la détection d'infection d'un terminal par un logiciel malveillant, selon un exemple de réalisation vont maintenant être décrites en relation avec la figure 1. Un terminal informatique (non représenté sur la figure 1) est agencé pour émettre des 10 requêtes afin d'accéder à des ressources d'un réseau, par exemple le réseau Internet. Une ressource est généralement désignée par un localisateur uniforme de ressource, ou « URL » (de l'anglais « Uniform Resource Locator »), auquel se substitue habituellement une adresse web. Les ressources sont accédées au moyen d'un protocole de communication client-serveur, par exemple « http » (de l'anglais « hypertext transfer protocol »). Les clients http les plus connus 15 sont les navigateurs web qui permettent à des utilisateurs d'accéder au moyen de leur terminal à un serveur contenant des données. Par la suite on appelle ressource, ou URL, une donnée proposée par un serveur ou le serveur lui-même qui sont concernés par la requête. Dans l'exemple décrit ici, le terminal informatique est par exemple un ordinateur personnel de type « PC » (de l'anglais « Personal Computer »), un terminal mobile, une tablette, un « PDA » (de 20 l'anglais « Personal Digital Assistant »), etc., agencés pour permettre à un utilisateur d'accéder à des ressources d'un réseau de données tel que le réseau Internet. Dans un autre exemple de réalisation, le terminal informatique est un serveur. Un dispositif de surveillance du trafic 40 tel que représenté sur la figure 4 est agencé pour aider à la détection d'une infection du terminal par un logiciel malveillant (ou « malware » 25 en anglais). Le dispositif de surveillance 40 est placé en coupure de trafic entre le terminal et le réseau Internet. Ainsi, toute requête de ressource émise par le terminal à destination du réseau Internet transite par le dispositif de surveillance 40 qui l'intercepte et l'analyse. Il est pertinent d'analyser l'ensemble des requêtes http issues du terminal car la plupart des cybercriminels utilisent le protocole http pour perpétrer des attaques au moyen de logiciels malveillants. En 30 effet, ce protocole constituant la majorité du trafic Internet, les logiciels malveillants qui reposent sur ce protocole génèrent un trafic d'attaque qui se fond dans un trafic légitime et qu'il est de ce fait difficile de détecter et d'isoler. L'invention n'est bien sûr pas limitée au protocole http et peut s'appliquer, moyennant des adaptations, à d'autres protocoles. Dans une étape initiale E0 de réception d'une requête, une requête http courante, 35 destinée à demander l'accès à une ressource courante située dans le réseau Internet est envoyée 3042624 8 depuis le terminal à un serveur du réseau apte à délivrer la ressource. La requête courante émise par le terminal est interceptée par le dispositif de surveillance 40. L'utilisateur du terminal a par exemple sélectionné un lien hypertexte dans une page affichée dans son navigateur web. Par exemple, il a sélectionné le lien « http://downloadmusicl.com/ ». Outre le nom du serveur à 5 contacter, ici « dowloadmusicl.com », la requête http comprend dans un entête un ensemble de champs destinés à fournir au serveur destinataire de la requête des informations complémentaires sur des caractéristiques de l'application cliente à l'origine de la requête ou/et des caractéristiques de la ressource courante requise. Ainsi, un champ de l'entête précise le nom de l'application cliente à l'origine de la requête, tel que le nom du navigateur utilisé pour 10 émettre la requête ainsi que son numéro de version, les langages supportés par l'application cliente, le format de l'écran, etc. L'entête peut comprendre également un champ référent, ou champ « Referer » dans le cas du protocole http. Le champ référent permet d'indiquer au serveur une ressource initiale de référence à partir de laquelle la ressource courante a été obtenue. Dans le cas d'un utilisateur qui navigue sur internet et qui accède à une page web, si le 15 champ référent est renseigné, cela indique que l'utilisateur a suivi un lien pour accéder à la page relative à la ressource courante et le champ référent précise alors le lien que l'utilisateur a sélectionné. Par exemple, si l'entête de la requête qui demande l'accès au serveur « downloadmusicl.com », comprend dans le champ référent «http://google.fr », cela indique que l'utilisateur a sélectionné la ressource « downloadmusicl.com » depuis le site « google.fr ». 20 A noter que dans ce cas, on dit que l'accès relatif à la ressource « downloadmusicl.com » est un accès indirect. Les informations contenues dans le champ référent sont utilisées habituellement par un serveur pour identifier des sites tiers pointant sur son contenu. Cela permet à l'administrateur du serveur de faire des statistiques d'accès, des optimisations en termes de dimensionnement, etc. A noter que le champ référent n'est pas uniquement présent lors d'une 25 navigation explicite d'un utilisateur qui à partir d'une première page sélectionne un lien pour accéder à une deuxième page. Il est également présent dans des requêtes qui sont effectuées de manière automatique par le navigateur pour charger par exemple des images ou des scripts et qui sont dues à des redirections au niveau du serveur. Ces fonctionnalités sont d'ailleurs exploitées par les cybercriminels pour tenter d'infecter des terminaux. 30 Dans une étape suivante El de détection, le dispositif de surveillance 40 vérifie si la ressource courante qui figure dans la requête courante est présente dans une base de données de ressources malveillantes. De telles bases recensent des signatures d'URL associées à des ressources malveillantes connues de l'Internet. Il est donc vérifié si la signature de la ressource courante figure dans la base. 3042624 9 Dans un premier cas (branche « nok » sur la figure 1) où la ressource courante ne figure pas dans la base des ressources réseau malveillantes, indiquant ainsi que la requête est légitime dans le sens où elle concerne une ressource qui n'est pas référencée comme malveillante, la requête est retransmise dans le réseau par le dispositif de surveillance dans une étape E2 5 d'envoi, afin d'être traitée. La ressource courante requise est alors ajoutée à un historique de requêtes dans une étape E3 de mise à jour de l'historique des requêtes. Le procédé continue alors dans l'étape EO de réception, en attente d'une prochaine requête. L'historique des requêtes est destiné à mémoriser les requêtes légitimes, c'est-à-dire qui concernent des ressources légitimes, émises depuis le terminal sur un intervalle de temps de supervision donné. 10 L'historique concerne donc des requêtes antérieures à la requête courante. L'historique est également destiné à vérifier pour toute nouvelle requête à une ressource malveillante qui comprend dans son entête une référence à une ressource initiale, si la nouvelle requête est liée, par le biais du champ référent, à une requête légitime antérieure, émise dans un passé récent depuis le terminal et qui concerne la ressource initiale. Dans ce cas, la nouvelle requête qui 15 concerne une ressource malveillante n'est que le fruit d'une tentative d'infection du terminal. En effet, la requête initiale concerne une ressource qui comprend un lien ou une redirection vers la ressource malveillante. L'ajout de la ressource malveillante a pu être fait par le cybercriminel par exploitation d'une vulnérabilité du serveur contacté, l'utilisation détournée de réseaux de publicité, etc. Dans le cas où la nouvelle requête n'est pas liée par le biais du champ référent à 20 une requête initiale émise depuis le terminal alors la nouvelle requête est due à une infection du terminal. C'est une requête spontanée, issue probablement d'un logiciel malveillant installé sur le terminal de l'utilisateur et indépendante des requêtes récemment émises depuis le terminal. L'utilisation et la gestion de l'historique permet ainsi d'affiner l'analyse des requêtes qui concernent des ressources malveillantes et de faire un tri entre celles qui sont dues à des 25 tentatives d'infection et celles qui sont dues à des infections réelles du terminal. Ainsi, aucune alerte n'est levée dans le cas de requêtes indirectes, c'est-à-dire consécutives à des redirections ou des liens au niveau d'un serveur, permettant de réduire notablement le nombre de faux-positifs. La gestion d'un historique de requêtes se justifie par le fait d'une part qu'il est 30 nécessaire d'identifier des liens entre plusieurs requêtes émises depuis un terminal dans le but d'identifier des liens légitimes entre requêtes, ou/et des redirections vers des ressources malveillantes indépendantes du terminal, et d'autre part par le fait que l'information contenue dans le champ référent d'une requête ne peut être considérée comme fiable dans le cas de logiciels malveillants. En effet, un cybercriminel peut aisément créer un logiciel malveillant qui 35 positionne de manière systématique dans des requêtes émises à l'insu de l'utilisateur le champ 3042624 10 référent à une valeur associée à un site populaire, de manière à faire croire que l'application à l'origine de la requête a suivi un lien fourni par ce site populaire. Dans une approche naïve où les requêtes qui comprennent un champ référent à une ressource légitime seraient systématiquement écartées de l'analyse du fait de leur référence à une précédente requête, cela 5 permettrait à un logiciel malveillant de ne pas être détecté et de continuer à émettre des requêtes jusqu'à ce qu'une requête vers un site malveillant aboutisse. Il est donc nécessaire d'aller plus loin qu'une simple vérification de la présence d'un champ référent dans ce cas et de vérifier que la requête initiale a bien été émise depuis le terminal dans un passé récent. Un exemple de réalisation de l'étape E3 de mise à jour de l'historique est décrit plus 10 loin, en relation avec la figure 2a. Dans un deuxième cas (branche « ok » sur la figure 1) où la ressource courante requise depuis le terminal figure dans la base des ressources malveillantes connues, dans une étape optionnelle E4 de blocage et d'envoi d'un message, le dispositif de surveillance 40 bloque la requête et envoie un message d'information au terminal indiquant que l'accès à la ressource est 15 refusé. A noter qu'à ce stade, aucune alerte n'est envoyée à un administrateur de sécurité en charge de la sécurité du terminal En effet, la requête courante concerne une ressource identifiée comme étant malicieuse, elle est bloquée, mais on ne peut dire si la requête est due à une infection du terminal ou à une tentative d'infection. Pour mémoire, une requête inoffensive émise par le terminal peut entraîner le chargement sur un serveur d'une page par le navigateur, 20 qui peut inclure des liens ou des redirections vers des ressources malveillantes. Le but d'une telle requête peut être d'infecter le terminal En tout état de cause, le problème se situe dans ce cas au niveau du serveur et non au niveau du terminal Dans une étape suivante E5 de contrôle, le dispositif de surveillance 40 vérifie si la requête courante comprend dans son entête une référence à une ressource initiale. En d'autres 25 termes le dispositif de surveillance vérifie si l'entête de la requête courante comprend un champ référent qui comprend la ressource initiale. Dans un premier cas (branche « nok » sur la figure 1) où la requête courante ne comprend pas dans son entête une référence à une ressource initiale, alors une alerte est levée à l'attention de l'administrateur de sécurité dans une étape E6 d'envoi d'une alerte. L'alerte est 30 destinée à informer l'administrateur que le terminal est infecté. En effet, dans ce cas, la requête émise par le terminal est une requête directe à une ressource malveillante via une application, par exemple le navigateur. Dans cet exemple, le procédé continue dans l'étape E0 de réception, en attente d'une prochaine requête. En variante, le procédé s'arrête, en attente d'une analyse de l'administrateur de sécurité et d'une mise en oeuvre d'une mesure de remédiation. 3042624 11 Dans un deuxième cas (branche « ok » sur la figure 1) où la requête comprend dans son entête une référence à une ressource initiale, il est vérifié dans une étape E7 de test si le champ référent qui figure dans l'entête de la requête courante appartient à l'historique des ressources. Dans un premier cas (branche « ok » sur la figure 1), la ressource initiale qui figure dans 5 le champ référent de la requête courante figure dans l'historique des requêtes. Cela signifie que la ressource initiale a été demandée depuis le terminal dans au moins une requête antérieure dans un passé récent, plus précisément pendant l'intervalle de temps de supervision. Dans ce cas, la requête courante constitue une requête d'accès indirecte à la ressource courante malveillante, issue probablement d'une redirection ou d'un lien au niveau d'un serveur ou d'un 10 site web. Cette requête est représentative d'une tentative d'infection du terminal mais en aucun cas d'une infection réelle du terminal, il n'y a donc pas lieu d'alerter l'administrateur. Le procédé continue à l'étape EO, en attente d'une prochaine requête. Dans un deuxième cas (branche « nok » sur la figure 1) où la ressource initiale qui figure dans le champ référent ne figure pas dans l'historique, indiquant que la ressource initiale 15 n'a pas été demandée par le terminal dans une requête antérieure pendant l'intervalle de temps de supervision, une alerte est levée à l'attention de l'administrateur de sécurité au cours d'une étape E8 d'envoi d'une alerte. En effet, dans ce cas, le champ référent qui figure dans la requête courante est un faux champ référent : un cybercriminel a manipulé la requête courante sur le terminal afin d'introduire un champ référent dont le contenu n'est lié à aucune requête 20 antérieure émise depuis le terminal. Une telle manipulation est destinée à faire croire que la requête à la ressource malveillante est liée à une redirection au niveau du serveur ou d'un serveur web. En tout état de cause, la falsification de la requête sur le terminal par le cybercriminel est représentative d'une infection effective du terminal, le cybercriminel ayant réussi à manipuler la requête. Dans cet exemple, le procédé continue dans l'étape EO de 25 réception, en attente d'une prochaine requête. En variante, le procédé s'arrête, en attente d'une analyse de l'administrateur de sécurité et d'une mise en oeuvre d'une mesure de remédiation le cas échéant. Dans l'exemple décrit ici, une requête à une ressource malveillante est bloquée au cours de l'étape E4 de blocage. Dans un autre exemple de réalisation, la requête n'est pas bloquée. On 30 peut vouloir privilégier l'envoi des requêtes pour éviter de bloquer un trafic légitime. En effet, il se peut que la base de données des ressources malveillantes soit erronée et comprenne une ressource tout à fait légitime. On comprend dans ce cas l'importance de distinguer une infection du terminal d'une tentative d'infection. 3042624 12 Des exemples de mise en oeuvre de l'étape E3 de mise à jour de l'historique des requêtes, et de l'étape E7 de recherche de la ressource dans l'historique vont maintenant être décrits en relation avec respectivement les figures 2a et 2b. L'étape E3 décrite en relation avec la figure 2a comprend une pluralité de sous-étapes. 5 Dans cet exemple de réalisation, la mise à jour de l'historique des requêtes reposent sur l'utilisation des filtres de Bloom à date d'expiration (ou « time-out Bloom filter » en anglais). Un filtre de Bloom est une structure de données probabiliste, compacte, adaptée pour mémoriser de manière optimale une très grande quantité de données, et pour être interrogée sur la présence ou l'absence d'un élément donné dans le filtre. Plus précisément, un filtre de Bloom est une 10 table de n éléments. S'agissant de filtres à date d'expiration, les différents éléments de la table, sont destinés à contenir des dates à la place d'un simple bit dans le cas des filtres de Bloom standards. Enregistrer une requête, plus précisément une ressource associée à une requête, dans le filtre de Bloom consiste à calculer une pluralité de positions dans le filtre à partir de la ressource comprise dans la requête et à enregistrer dans cette pluralité de positions une valeur 15 d'horodatage correspondant à la date de réception de la requête par le module de surveillance 40. Cette valeur d' horodatage est représentative de la dernière date d'accès à la ressource. Il est connu que les filtres de Bloom sont sujets aux faux-positifs. En effet, bien que l'on sache avec certitude qu'un élément est absent du filtre, on ne sait qu'avec une certaine probabilité qu'un élément peut être présent dans le filtre. Afin de réduire ce nombre de faux-positifs, dû à de 20 possibles collisions dans le filtre, plusieurs positions sont calculées pour chaque requête. Ainsi une requête est associée à plusieurs positions dans le filtre. Dans cet exemple de réalisation, un filtre de Bloom à date d'expiration Tb est associé au terminal, par exemple à l' adresse IP du terminal dans une phase de configuration initiale (non représentée sur la figure 2a). Le filtre Tb est un vecteur à n-éléments, notés Tb[0], ...Tb[n- 25 1], initialisé à 0. Dans l'exemple décrit ici n est fixé à vingt-cinq mille Dans une première sous-étape E31 de conversion, une ressource courante légitime notée x qui figure dans la requête courante est convertie dans un format binaire. Cette conversion est obtenue à partir de la valeur numérique de chacun des caractères qui composent la chaîne de caractères désignant la ressource courante. La valeur binaire de la ressource ainsi obtenue est 30 notée b. Par exemple on peut utiliser des convertisseurs disponibles sur Internet. Dans une sous-étape suivante E32 d'application de fonctions de hachage, k fonctions de hachage Fpi, 1 REVENDICATIONS1. Procédé d'aide à la détection d'infection d'un terminal par un logiciel malveillant, comprenant : - réception (EO) en provenance du terminal d'une requête courante de demande d'accès à une ressource d'un réseau, - détection (El) que la ressource requise est malveillante, - lorsque la requête courante comprend (E5) une référence à une ressource initiale, vérification (E7) qu'un accès à la ressource initiale a été demandé depuis le terminal dans au moins une requête antérieure, ladite ressource initiale ayant été détectée légitime lors du traitement de la requête antérieure, ladite requête courante étant alors considérée comme une tentative d'infection du terminal. 2. Procédé selon la revendication 1, comprenant, lorsque la ressource initiale dont la référence est comprise dans la requête courante n'a pas été demandée par le terminal dans une requête antérieure pendant un intervalle de temps de supervision, un envoi (E8) d'une alerte représentative d'une infection du terminal 3. Procédé selon l'une des revendications précédentes, comprenant, lorsque la ressource requise est une ressource légitime, un enregistrement (E3) de ladite ressource en association avec une valeur d'horodatage courante, représentative d'une dernière date d'accès à la ressource. 4. Procédé selon la revendication 3, dans lequel la ressource est enregistrée dans un historique de requêtes, l'enregistrement de la ressource comprenant : - application (E32) d'au moins une fonction de hachage à une valeur binaire courante associée à la ressource, - détermination (E33) d'au moins une position courante dans un filtre de Bloom à date d'expiration à partir de ladite valeur binaire courante, ledit filtre étant associé au terminal et assimilé à l'historique des requêtes, et - enregistrement (E34) de la valeur d'horodatage courante à ladite position courante du filtre. 5. Procédé selon la revendication 4, dans lequel une recherche d'une ressource initiale dans le filtre comprend : 3042624 21 - application (E72) de la fonction de hachage à une valeur binaire initiale associée à la ressource initiale, - détermination (E73) d'au moins une position dans le filtre de Bloom à partir de ladite valeur binaire initiale, 5 - sélection (E75), parmi la au moins une position, de la position dans le filtre qui comprend la valeur d'horodatage la plus faible, - lorsque la durée comprise entre la valeur d'horodatage la plus faible et une date courante est inférieure à une durée d'expiration associée au filtre, indication (E76) que la ressource initiale figure dans l'historique. 10 6. Procédé selon la revendication 4 ou la revendication 5, dans lequel le filtre de Bloom est associé au terminal et à au moins un champ compris dans un entête de la requête courante. 7. Dispositif d'aide à la surveillance d'un trafic réseau, agencé pour aider à la détection 15 d'infection d'un terminal par un logiciel malveillant, ledit dispositif comprenant : - des moyens de réception (404), agencés pour recevoir en provenance du terminal une requête courante de demande d'accès à une ressource d'un réseau, - des moyens de détection (405), agencés pour détecter que la ressource requise est malveillante, 20 - des moyens de vérification (406), agencés pour vérifier, lorsque la requête courante comprend une référence à une ressource initiale, que l'accès à la ressource initiale a été demandé depuis le terminal dans au moins une requête antérieure, ladite ressource initiale ayant été détectée légitime lors du traitement de la requête antérieure, ladite requête courante étant alors considérée comme une tentative d'infection du terminal. 25 8. Terminal utilisateur comprenant un dispositif d'aide à la surveillance selon la revendication 7. 9. Programme d'ordinateur sur un support de données et chargeable dans la mémoire 30 d'un ordinateur, le programme comprenant des portions de code pour l'exécution des étapes du procédé d'aide à la détection d'infection d'un terminal par un logiciel malveillant selon l'une quelconque des revendications 1 à 6, lorsque le programme est exécuté sur ledit ordinateur. 10. Support de données dans lequel est enregistré le programme selon la revendication 35 9.