FR3101977A1 - Système et procédé de détection d’un algorithme de génération de domaine DGA - Google Patents

Système et procédé de détection d’un algorithme de génération de domaine DGA Download PDF

Info

Publication number
FR3101977A1
FR3101977A1 FR2010294A FR2010294A FR3101977A1 FR 3101977 A1 FR3101977 A1 FR 3101977A1 FR 2010294 A FR2010294 A FR 2010294A FR 2010294 A FR2010294 A FR 2010294A FR 3101977 A1 FR3101977 A1 FR 3101977A1
Authority
FR
France
Prior art keywords
domain
client terminal
tuples
dns
dga
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR2010294A
Other languages
English (en)
Other versions
FR3101977B1 (fr
Inventor
Jean-Yves BISIAUX
Sylvain GALLIANO
Christophe Girard
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Efficient IP SAS
Original Assignee
Efficient IP SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Efficient IP SAS filed Critical Efficient IP SAS
Publication of FR3101977A1 publication Critical patent/FR3101977A1/fr
Application granted granted Critical
Publication of FR3101977B1 publication Critical patent/FR3101977B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/23—Clustering techniques
    • G06F18/231—Hierarchical techniques, i.e. dividing or merging pattern sets so as to obtain a dendrogram
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/02—Knowledge representation; Symbolic representation
    • G06N5/022—Knowledge engineering; Knowledge acquisition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/144—Detection or countermeasures against botnets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Mathematical Physics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Health & Medical Sciences (AREA)
  • Virology (AREA)
  • General Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Medical Informatics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L’invention concerne un procédé et un dispositif de détection d’un algorithme de génération de domaine DGA dans un réseau de communication informatique (106) comprenant au moins un serveur de résolution de requêtes DNS (104) émanant d’au moins un terminal client (102). Le réseau de communication informatique (106) comprend en outre un module de détection (108) couplé au serveur de résolution (104) et configuré pour analyser les requêtes DNS selon les étapes suivantes :- pour chaque requête DNS , associer le nom de domaine demandé et l’identité du terminal client demandeur pour former un tuple ;- combiner en partitions homogènes les tuples selon la technique de détection de communautés de tuples ; et- en déduire pour chaque partition homogène l’ensemble des terminaux clients exploitant un même DGA.

Description

Système et procédé de détection d’un algorithme de génération de domaine DGA
DOMAINE DE L’INVENTION
La présente invention concerne la détection d’un algorithme de génération de domaine, appelé encore DGA pour « Domain Generation Algorithm ». Elle trouve une application générale dans la détection de logiciel malveillant (malware) exploitant un DGA.
CONTEXTE DE L’INVENTION
De manière générale, un DGA est une technique permettant de générer en grande quantité des noms de domaines Internet. Les noms de domaines ainsi générés par DGA ne sont pas, pour la grande majorité d’entre eux enregistrés dans les systèmes de noms de domaine (appelés encore DNS pour Domain Name System), c’est-à-dire que les requêtes de résolution DNS aboutissent à NXDOMAIN (non existing domain) comme code de retour négatif à une requête DNS.
La technique DGA est généralement utilisée par des logiciels malveillants insidieusement installés sur des terminaux, périphériques ou objets connectés tels que téléphones, ordinateurs, tablettes, caméras, systèmes d’alarme, …
Les logiciels malveillants exploitants les DGA peuvent entre autres être de types : adware, spyware, virus, worm, trojan, keylogger, rootkit, phishing, spear phishing, bots, botnets, ransomware.
Les logiciels malveillants sont le plus souvent contrôlés et commandés par un serveur complice distant qu’ils localisent par la résolution d’un nom de domaine via le protocole DNS. Ce serveur est appelé C&C pour « server Command & Control » dans le vocabulaire de la cybersécurité. Pour que le serveur complice ne puisse pas être découvert, le logiciel malveillant change régulièrement de nom choisi depuis une liste générée de manière déterministe. Les noms de cette liste sont générés par un algorithme DGA utilisé conjointement par le serveur C&C et le logiciel malveillant.
Des logiciels malveillants peuvent se diffuser en se multipliant et se distribuant dans un réseau dans le but de mener une cyberattaque massive distribuée ou pour se cacher dans un grand flux de requêtes.
On connaît déjà des systèmes de détection de logiciels malveillants. Généralement ils sont basés sur l’analyse du nom de domaine généré par DGA. Les techniques d’analyses sont généralement lexicales, fréquence de caractères, séquençage de caractères ou tout autre calcul d’entropie. Par exemple, la clusterisation par analyse lexicale est décrite dans la publication [CODDULM] Chunyu Han; Yongzheng Zhang.CODDULM: An Approach for Detecting C&C Domains of DGA on Passive DNS Traffic.2017 6th International Conference on Computer Science and Network Technology. 2017.
.Aujourd’hui, de tels systèmes de détection connus ne sont plus totalement satisfaisants puisqu’ils génèrent de nombreux faux positifs en raison des noms de domaines génériques utilisés par le cloud, par exemples entre autres, pour les machines virtuelles ou les micro services. Ou encore, ces systèmes de détection sont devenus inefficaces car les concepteurs de DGA de dernières générations ont fait évoluer leurs algorithmes pour trouver des parades techniques en imitant des noms communs de l’internet. Certains d’entre eux se basent sur des dictionnaires de mots naturels comme entre autres : suppobox, matsnu, gozi, nymaim2, ou pizd.
La présente invention améliore la situation.
Elle porte sur un procédé de détection d’algorithme de génération de domaine DGA dans un réseau de communication informatique comprenant au moins un serveur de résolution de requêtes DNS émanant d’au moins un terminal client.
Selon une définition générale de l’invention, le réseau de communication informatique comprend en outre un module de détection couplé au serveur de résolution de requêtes DNS et configuré pour analyser les requêtes DNS selon les étapes suivantes :
- pour chaque requête DNS collecté par le serveur de résolution, associer le nom de domaine demandé et l’identité du terminal client demandeur pour former un tuple unique;
- combiner en partitions homogènes les tuples selon la technique de détection de communautés ; et
- en déduire, pour chaque partition homogène ainsi combinée, l’ensemble des terminaux clients exploitant un même DGA.
En pratique, l’analyse est basée sur le comportement des terminaux clients qui utilisent le DGA en comparant lesdits comportements entre eux. L’objectif de la détection est de déceler des similitudes de comportement des terminaux clients en général et plus particulièrement l’ensemble des domaines communs à un DGA requetés par un ensemble de terminaux clients infectés par un logiciel malveillant exploitant ledit DGA.
Le Demandeur a observé que seules les requêtes DNS vers des noms de domaines inconnus sont ici d’intérêt pour la détection du logiciel malveillant.
De façon surprenante, le Demandeur a aussi observé que les terminaux clients infectés d’un même logiciel malveillant font un ensemble de requêtes DNS communes. C’est-à-dire que tous les terminaux clients d’un ensemble limité de terminaux clients ont requetés tous les noms de domaines d’un ensemble limité de domaines. Ainsi la presque totalité des terminaux clients d’un ensemble qui requêteront la presque totalité des domaines d’un ensemble donne ici un niveau de similitude de comportement des terminaux clients DNS élevés.
Un terminal client peut être infecté simultanément par plusieurs logiciels malveillants, et donc héberger plusieurs DGAs, qui auront des formes de domaines différentes. De ce fait, un terminal client pourra se trouver dans plusieurs regroupements.
Selon un premier mode de réalisation non limitatif, le procédé comprend un filtrage par statistique descriptive qui permet d’éliminer sur des dépassements de seuils les tuples dont le comportement n’est pas significatif d’un DGA, comme les fonctions de covariance, écart type ou de calcul de distance euclidienne.
Selon un deuxième mode de réalisation non limitatif, la détection de communautés de tuples est réalisée à partir d’un graphe biparti qui comprend:
  1. une pluralité de nœuds de type terminal client;
  2. une pluralité de nœuds de type domaines;
  3. une pluralité d’arêtes représentant chacune une requête DNS d’un nœud de terminal client vers un nœud de domaine; un nœud de domaine pouvant être connecté à plusieurs nœuds de terminal client et un nœud de terminal client pouvant être connecté à plusieurs nœuds de domaine, et
  4. la recherche de communautés de nœuds dans ledit graphe biparti étant propre à générer des partitions distinctes, elles-mêmes réparties en graphes bipartis incluant des tuples représentant un ensemble cohérent de terminaux clients faisant des requêtes DNS sur un ensemble de domaines.
Le bon partitionnement d'un graphe biparti implique un nombre d'arêtes intra-communautaires important et un nombre d'arêtes inter-communautaires faible. Une des principales méthodes pour évaluer la qualité de la structure des communautés découvertes s’appuie sur le calcul de la modularité (Q) telle que proposée ci-dessous par Newman et Girvan [NEW2004]Newman and Girvan. Finding and evaluating community structure in networks. Department of Physics and Center for the Study of Complex Systems, University of Michigan. 2004 .
Le procédé selon l’invention comprend en outre une mesure de la qualité de la clusterisation selon un calcul de la modularité des communautés de tuples ainsi détectées.
La mesure de la modularité des communautés d’un graphe peut se calculer avec la formule de modularité (Q) de Newman and Girvan [NEW2004]. Où (m) est le nombre d'arêtes du réseau, (Lc) nombre d'arêtes intra-communautaires pour la communauté (c), (kc) la sommes des degrés des noeuds dans la communauté (c). D’autres calculs de modularité peuvent être utilisés ici comme ceux de Murata [MUR01]Murata, T. Modularities for bipartite networks. In HT ’09 : Proceedings of the Twen-tieth ACM Conference on Hypertext and Hypermedia, New York, NY, USA. ACM. 2009, Latapy [LATA01]Guillaume and Latapy. Modularities for bipartite networks. Information Processing Letters 90(6), 215–221. 2004, Potts [POTTS02]J.M. Kumpula; J. Saramäki; K. Kaski & J. Kertész (2007). "Limited resolution in complex network community detection with Potts model approach". European Physical Journal B. 2007ou Dugué [DUG01]Dugué, N.; & Perez, A.. Directed Louvain: maximizing modularity in directed networks. Doctoral dissertation, Université d’Orléans. 2015.
Ce mode de réalisation a la particularité d'exploiter sans s’y limiter des algorithmes de détection de communautés, qui maximisent la modularité comme Louvain [LOUV01]Blondel, Vincent D; Guillaume, Jean-Loup; Lambiotte, Renaud; Lefebvre, Etienne (9 October 2008). "Fast unfolding of communities in large networks". Journal of Statistical Mechanics: Theory and Experiment. 2008et/ou Label Propagation Algorithms (LPA) [LPA011]Gennaro Cordasco and Luisa Gargano. Community Detection via Semi–Synchronous Label Propagation Algorithms. Dipartimento di Informatica ed Applicazioni “R.M. Capocelli” University of Salerno, 2011, ou encore comme infomap [INFOMAP]M. Rosvall, D. Axelsson, and C.T. Bergstrom. The Map Equation. Eur. Phys. J. Special Topics 178, 13–23. EDP Sciences, Springer-Verlag 2010 / DOI: 10.1140/epjst/e2010-01179-1. 2009qui s’appuie sur la recherche de schémas de flux dans un réseau.
A la différence d’autres techniques de détections de DGA comme les publicationsClustering and Capturing Group Activities for DGA- based botnets detection[CCGA]Zhicheng Liu; Xiaochun Yun; Yongzheng Zhang; Yipeng Wang. CCGA: Clustering and Capturing Group Activities for DGA-based botnets detection. 18th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/13th IEEE International Conference On Big Data Science And Engineering. 2019ouDGA Botnet detection using Collaborative Filtering and Density-based Clustering[DGABOT1]Trung-Duc Nguyen; Tuan-Dung Cao; Linh-Giang Nguyen. DGA Botnet detection using Collaborative Filtering and Density-based Clustering. Proceedings of the Sixth International Symposium on Information and Communication Technology. 2015 & 18th IEEE International Conference. 2019,le procédé conforme à l’invention n’utilise pas en première phase de clusterisation par densité pour des questions de difficulté de mise en oeuvre, de qualité et de performance.
En effet, le Demandeur a observé en premier lieu que la clusterisation par densité est de mise en œuvre difficile par rapport à la recherche de communautés.Les données utilisées sont structurées en deux dimensions: le domaine et la valeur numérique du nombre de clients terminaux ayant fait une requête sur ce même domaine. Les algorithmes de clusterisation par densité regroupent ensuite les domaines en N clusters. L’algorithme K-Means [KMEAN]J. A. Hartigan et M. A. Wong. Algorithm AS 136: A K-Means Clustering Algorithm, Journal of the Royal Statistical Society, Series C, vol. 28, no 1,. 1979,nécessite de spécifier le nombre N de cluster a trouver ce qui n’est pas pertinent puisque nous ne le connaissons pas. L’algorithme DBSCAN [DBSCAN]M. Ester, H.-P. Kriegel, J. Sander, and X. Xu, A density-based algorithm for discovering clusters in large spatial databases with noise, in Proceedings of the 2nd International Conference on Knowledge Discovery and Data mining. 1996va faire varier le nombre de clusters N en fonction d’autres paramètres comme le seuil de distance convenant à la densité du nombre de clients terminaux par domaine et facteur d'identification du bruit. L’ajustement de ces paramètres rend l’application de DBSCAN difficile à mettre en œuvre pour généraliser une clusterisation sur des jeux de données très diversifiés.
En outre, le Demandeur a observé en second lieu que la précision de la clusterisation par densité est relativement insatisfaisante par rapport à la recherche de communautés.En pratique, la qualité de la classification est mesurée en fonction du taux de précision (also called positive predictive value) et du taux de recall (also known as sensitivity) qui dans le contexte ici est la proportion de tuple d’un vrai DGA du cluster trouvé sur l’ensemble des tuples d’un vrai DGA. Où (R) est le recall, (Tp) le true positive correspondant au nombre de tuples du DGA bien classifié dans le cluster trouvé et (Fn) le false positive correspondant au tuple du DGA non classifié dans le cluster trouvé. Si le taux de précision est plutôt satisfaisante avec la clusterisation par densité, le taux de recall est lui très variable et donc très difficile à stabiliser à cause des deux paramètres de configuration de DBSCAN ou encore plus significativement avec le choix de la variable K de K-Means.
Enfin, le Demandeur a observé en troisième lieu que la performance de la clusterisation par densité est insuffisante par rapport à la recherche de communautés. En pratique, Le temps d'exécution d’un algorithme est fonction de sa complexité et de la volumétrie des données à traiter. La complexité de l’algorithme DBSCAN est de pour l’indexation et entre une complexité de temps linéarithmique au meilleur des cas jusqu'à quadratique dans pire des cas en fonction de ses paramètres de configuration. Les algorithmes de détection de communautés comme Louvain [LOUV01] ou Label Propagation Algorithms [LPA011], ont une complexité de temps linéaire au mieux ou au pire linéarithmique . La complexité de type linéaire ou linéarithmique étant très significativement inférieure complexité quadratique sur de grand volume de traitement, la détection par communauté est bien plus performante que la recherche par densité, d’un rapport de 1:1008000 temps pour 1 million d’itérations de calcul.
Selon un troisième mode de réalisation non limitatif, la détection de communautés de tuples est accompagnée d’une méthode d’agrégation de clusters par chaînage. Il est à noter qu’un DGA continue, dans le temps, à générer beaucoup de domaines. Donc, dans un ensemble de domaines identifiés, beaucoup de nouveaux domaines vont remplacer les précédents. Dans un ensemble, les noms de domaines sont éphémères et leur nombre peut varier dans le temps.
Il faut une quantité minimum de tuples pour définir un cluster et donc en déduire un DGA. De nouveaux clusters de DGA sont découverts à chaque analyse. On peut considérer ici la succession des clusters découvert comme un flux quand il est projeté dans le temps. L’association entre l’ensemble des clients et l’ensemble des noms de domaines reste elle avantageusement stable ce qui permet de chaîner des clusters découverts sur une période de temps longue.
Il est aussi à noter qu’un logiciel malveillant peut muter, c’est-à-dire qu’il peut télécharger, remplacer son propre code en cours d'exécution et ainsi faire évoluer son DGA. En suivant l’ensemble des clients commun qui requêtent un flux de domaines communs, le procédé conforme à l’invention n’est pas sensible au changement de DGA et peut avantageusement continuer à suivre l’évolution du groupe de clients DNS.
Le procédé selon l’invention comprend en outre une recherche de chaînages de clusters dans le temps selon au moins une technique appartenant au groupe formé par apprentissage automatique non supervisé, apprentissage automatique supervisé, détection de communauté.
La présente invention a également pour objet un système de détection d’un algorithme de génération de domaine DGA, dans un réseau de communication informatique comprenant au moins un serveur de résolution de requêtes DNS émanant d’au moins un terminal client.
Selon un aspect de l’invention, le réseau de communication informatique comprend en outre un module de détection couplé au serveur de résolution DNS et comprenant des moyens de traitement de données configurés, pour chaque requête DNS, à associer le nom de domaine demandé et l’identité du terminal client demandeur pour former un tuple ; à combiner en partitions homogènes les tuples ainsi combinés selon au moins une technique d’agrégation de type détection de communautés de tuples; et à en déduire pour chaque partition homogène l’ensemble des terminaux clients exploitant un même DGA.
Les moyens de traitement de données comprennent en outre des moyens de mesure propre à mesurer la qualité de la clusterisation selon un calcul de la modularité des communautés de tuples ainsi détectées.
La présente invention a encore pour objet un programme d’ordinateur comprenant des instructions qui conduisent le système de détection de DGA ci-avant, à exécuter les étapes du procédé de détection de DGA, visé ci-avant.
D’autres avantages et caractéristiques de l’invention apparaîtront à l’examen de la description et des dessins dans lesquels :
  • [Fig. 1]représente schématiquement l’environnement d’un réseau informatique mettant en œuvre l’invention ;
  • [Fig. 2]représente schématiquement la structure des composants du serveur de résolution DNS et du module de détection de DGA conformément à l’invention ;
  • [Fig. 3]représente schématiquement un exemple de graphe biparti ;
  • [Fig. 4]représente schématiquement un exemple de graphe biparti clusterisé ;
  • [Fig. 5]représente schématiquement conforme à l’invention ;
  • [Fig. 6]représente schématiquement la notion de tuple ; et
  • [Fig.7] représente schématiquement un diagramme de chaînage de clusters.
DESCRIPTION DÉTAILLÉE DES FIGURES
La illustre un exemple d’environnement de réseau informatique 100. L'environnement réseau informatique 100 peut être soit un environnement distribué public, soit un environnement réseau fermé privé. L'environnement de réseau informatique 100 peut inclure différents terminaux clients ou dispositifs informatiques 102-1, 102-2, ..., 102-N couplés de manière à communiquer avec un serveur de résolution de requêtes de système de noms de domaine DNS 104 via un réseau de communication informatique 106.
A titre d’exemple, le terminal client 102 peut être un dispositif informatique de serveur d’applications 102-4, d'un dispositif mobile 102-3 (tablette, smartphone,…), d’un objet connecté 102-1, et/ou d'un ordinateur personnel 102-2 à travers lequel un utilisateur peut accéder à une application ou un service informatique en utilisant un nom d’application. Le terminal client 102 est distingué par un identifiant unique qui peut être soit son adresse IP, son adresse physique de réseau MAC, un numéro de mobile IMSI (GSM, UMTS, ou LTE), un numéro d’inventaire arbitraire ou tout autre identifiant permettant d’identifier un client DNS. Ce numéro peut être transporté dans l'entête du protocole DNS ou dans l’extension du protocole EDNS. Dans une implémentation, le serveur de résolution DNS 104 peut être un serveur de noms de domaine pour analyser les demandes de nom de domaine et identifier un domaine de premier niveau (TLD) et un domaine de second niveau (SLD) à partir de la demande de nom de domaine et pour traduire la demande de nom de domaine en un protocole Internet correspondant. Le serveur DNS 104 peut également être un serveur Web fournissant un accès au contenu numérique aux dispositifs informatiques 102, un serveur DNS récursif, un serveur DNS de transfert et un serveur DNS de mise en cache.
Le réseau 106 peut être un réseau sans fil ou câblé, ou une combinaison de ceux-ci. Le réseau 106 peut être un ensemble de réseaux individuels, interconnectés les uns avec les autres et fonctionnant comme un seul grand réseau (par exemple, Internet ou un intranet). Des exemples de tels réseaux individuels incluent, sans toutefois s'y limiter, le réseau de téléphonie mobile, le réseau local, le réseau métropolitain le réseau étendu, le réseau satellite. En fonction de la technologie, le réseau 106 comprend diverses entités de réseau, telles que des émetteurs-récepteurs, des passerelles, des pares-feux, et des routeurs ; cependant, ces détails ont été omis pour faciliter la compréhension.
L'environnement de réseau informatique 100 est associé à un serveur de résolution de requêtes DNS 104 qui peut recevoir des requêtes DNS liées provenant des terminaux clients 102 via la liaison 107 et peut fournir une réponse sous la forme d'une adresse IP de serveurs hébergeant l’application ou autre service informatique. Les demandes peuvent être générées lorsqu'un utilisateur peut avoir l'intention d'accéder à une application via le terminal client 102 et d'entrer un nom d’application ou par exemple une URL (Uniform Resource Locator) dans la barre d'adresse d'un explorateur Web. Le serveur DNS 104 peut extraire l'adresse IP du terminal client 102 à partir de la demande reçue, puis utiliser l'adresse IP pour retourner la réponse au terminal client 102. Le serveur DNS 104 peut également stocker l'adresse IP du dispositif informatique 102 afin de répondre aux demandes ultérieures du terminal client 102 avec un temps aller-retour réduit.
Le serveur de résolution de requêtes 104 est couplé via la liaison 109 à un détecteur 208 de DGA, décrit plus en détail en référence à la figure 2.
La figure 2 figure 2 illustre un exemple des composants du serveur de résolution 104 et du système de détection de DGA 208.
Le serveur DNS 104 peut comprendre un ou plusieurs processeurs 120, une ou des interfaces 121 dont l’une est reliée au réseau informatique 106 via la liaison 107 et une mémoire 122. En outre, le serveur DNS 104 peut inclure un cache 123.
Entre autres possibilités, le cache 123 peut servir de référentiel externe pour stocker des informations sur les noms de domaine fréquemment demandés et les adresses IP d'hôte. Dans une mise en œuvre du présent objet, la mémoire cache 123 peut stocker des informations de mappage pour des noms de domaine et leurs adresses IP respectives. Dans un exemple de mise en œuvre, le cache 123 peut être un référentiel interne au sein du serveur DNS 104 pour stocker les informations sur les noms de domaine fréquemment demandés.
Le processeur 120, parmi d'autres capacités, peut être configuré pour extraire et exécuter des instructions lisibles par ordinateur stockées dans la mémoire 122. Le processeur 120 peut être mis en œuvre sous la forme d'un ou de plusieurs microprocesseurs, micro-ordinateurs, microcontrôleurs, processeurs de signaux numériques, unités de traitement centrales, machines d'état, circuits logiques et / ou de tout dispositif manipulant des signaux sur la base d'instructions opérationnelles. Les fonctions des différents éléments représentés sur la figure 2, y compris tous les blocs fonctionnels étiquetés "processeur (s)", peuvent être fournies via l'utilisation d'un matériel dédié ainsi que d'un matériel capable d'exécuter un logiciel en association avec un logiciel approprié. Lorsqu'elles sont fournies par un processeur, les fonctions peuvent être fournies par un seul processeur dédié, par un seul processeur partagé ou par une pluralité de processeurs individuels, dont certains peuvent être partagés. De plus, l'utilisation explicite du terme "processeur" ne doit pas être interprétée comme visant exclusivement le matériel capable d'exécuter un logiciel, et peut implicitement inclure, sans limitation, le matériel du processeur de signal numérique (DSP), le processeur de réseau, le circuit intégré à application spécifique (ASIC) , FPGA (Field Programmable Gate Array), mémoire morte (ROM) pour le stockage du logiciel, mémoire vive (RAM), mémoire non volatile.
D'autres matériels, conventionnels et / ou personnalisés, peuvent également être inclus.
La ou les interfaces 121 peuvent inclure une variété d'interfaces et d'interfaces matérielles lisibles par machine qui permettent au serveur DNS 104 d'interagir avec différentes entités, telles que le processeur 120, le module de cache 123. En outre, la ou les interfaces 121 peuvent permettre aux composants du serveur DNS 104 de communiquer avec d'autres serveurs DNS et des référentiels externes. Les interfaces 121 peuvent faciliter de multiples communications dans une grande variété de réseaux et de types de protocoles, un réseau local, etc.
De son côté, le système de détection de DGA 208 peut comprendre un ou plusieurs processeurs 220, une ou des interfaces 221 dont l’une est reliée au cache 123 via la liaison 109 et une mémoire 222
La mémoire 222 peut être couplée au processeur 220 et peut, entre autres capacités, fournir des données et des instructions pour générer différentes requêtes. La mémoire 222 peut inclure tout support lisible par ordinateur connu dans la technique, y compris, par exemple, une mémoire volatile, telle qu'une mémoire vive statique (SRAM) et une mémoire vive dynamique (DRAM), et / ou une mémoire non volatile, telle que mémoire morte (ROM), mémoire morte programmable effaçable, mémoires flash, disques durs, disques optiques et bandes magnétiques.
En pratique, le détecteur de DGA 208 comprend un module 200 configuré pour exécuter les méthodes d'agrégation des tuples que l’on décrira plus en détail ci-après.
Les techniques d’agrégation suivantes sont utilisées indépendamment ou successivement pour agréger/combiner les tuples: les statistiques descriptives 201, les algorithmes basés sur la détection de communautés 202 et les méthodes de chaînages de clusters 204.
En référence à la , la représentation de graphe biparti structuré par un ensemble de noeuds de type terminal client 310 et ensemble de noeuds de domaine 340. Une arête 320 représente la requête DNS d’un noeud de type terminal client 311 vers un noeud de type domaine 344. Un noeud de domaine 344 peut être connecté à plusieurs noeud de type terminaux clients 311 de même qu’un terminal client 311 peut être connecté à plusieurs domaines 344.
Ainsi la détection de communautés de domaines est réalisée à partir d’un graphe biparti comprenant:
  1. une pluralité de nœuds de type terminal client 310;
  2. une pluralité de nœuds de type domaines 340;
  3. une pluralité d'arêtes 320 représentant chacune une requête DNS d’un nœud de terminal client 311 vers un nœud de domaine 344; un nœud de domaine 344 pouvant être connecté à plusieurs nœuds de terminal client 311 et un nœud de terminal client 311 pouvant être connecté à plusieurs nœuds de domaine 344.
La représente une partie du graphe biparti représenté en qui a été traité par une recherche de communauté. Le résultat de recherche de communauté crée un premier cluster 410 contenant les noeuds de type terminal client 411 et les noeuds de type domaine 413, et un autre cluster distinct 430 contenant les noeuds de type terminal client 431 et les noeuds de type domaine 433. Chaque noeud appartenant à un cluster possède une arête-intracommunautaire 412 ou 432, une arête-intercommunautaire 420 relie deux noeuds appartenant à des communautés différentes.
Ainsi, la recherche de communautés de nœuds dans le graphe biparti est propre à générer des partitions distinctes 410, 430, elles-mêmes réparties en graphes bipartis incluant des tuples représentant un ensemble cohérent de terminaux clients faisant des requêtes DNS sur un ensemble de domaines.
La illustre les relations entre les domaines et les clients. Une ligne représente l’identifiant du client 501 et une colonne représente un nom de domaine 502. L’intersection d’une ligne et d’une colonne, appelée ici tuple 503 représente une requête faite par ce client pour ce nom de domaine. On appelle un cluster 504-n l’ensemble des tuples pour lesquels à peu près les mêmes clients 501 ont fait des requêtes sur à peu près les mêmes domaines 502. Les tuples dont le domaine correspond à un DGA 503-2 font partie du cluster 504-n. Les tuples dont le domaine ne correspond pas à un DGA 503-1 n’appartiennent pas au cluster 504-n.
La décrit un tuple. Le tuple 602 est une relation entre un nom de domaine 603 faisant l’objet d’une requête par un client 601. Le terminal client 601 est distingué par un identifiant unique qui peut être soit son adresse IP, son adresse physique de réseau MAC, un numéro de mobile IMSI (GSM, UMTS, ou LTE), un numéro d’inventaire arbitraire ou tout autre identifiant permettant d’identifier un client DNS. Ce numéro peut être transporté dans l’entête du protocole DNS ou dans l’extension du protocole EDNS.
La représente un diagramme de chaînages de clusters dans le temps entre plusieurs périodes 711, 713, 714. Le chaînage 721 permet de raccorder un ou plusieurs clusters à un ou plusieurs clusters entre deux périodes de clusterisations 711, 713, 714. La succession de chaînage sur plus de deux périodes permet de suivre par recouvrement l’évolution d’un cluster incluant des divisions et des fusions. La dimension temporelle permet ainsi d’enrichir les processus de clusterisation par chaînage.
La description qui précède a été dirigée vers des modes de réalisation spécifiques. Il apparaîtra cependant que d'autres variantes et modifications peuvent être apportées aux modes de réalisation décrits, avec l'obtention de tout ou partie de leurs avantages. Par exemple, il est expressément envisagé que les composants et / ou éléments décrits ici puissent être mis en œuvre sous forme de logiciel stocké sur un support lisible par ordinateur tangible (non transitoire) (par exemple, disques / CD / RAM / EEPROM / etc.) ayant instructions de programme exécutées sur un ordinateur, un matériel informatique, un micrologiciel ou une combinaison de ces éléments. En conséquence, cette description doit être prise uniquement à titre d'exemple et ne doit pas limiter autrement la portée des modes de réalisation décrits ici. Par conséquent, l'objet des revendications annexées est de couvrir toutes les variations et modifications telles qu'elles entrent dans l'esprit et la portée véritables des modes de réalisation décrits ici.

Claims (10)

  1. Procédé de détection d’un algorithme de génération de domaine DGA dans un réseau de communication informatique (106) comprenant au moins un serveur de résolution de requêtes DNS (104) émanant d’au moins un terminal client (102), caractérisé en ce que le réseau de communication informatique (106) comprend en outre un module de détection (108) couplé au serveur de résolution (104) et configuré pour analyser les requêtes DNS selon les étapes suivantes :
    - pour chaque requête DNS, associer le nom de domaine demandé et l’identité du terminal client demandeur pour former un tuple ;
    - combiner en partitions homogènes les tuples selon la technique de détection de communautés ; et
    - en déduire pour chaque partition homogène l’ensemble des terminaux clients exploitant un même DGA.
  2. 2. Procédé selon la revendication 1, caractérisé en ce que la technique de détection de communautés est réalisée à partir d’un graphe biparti comprenant:
    -une pluralité de nœuds de type terminal client (310);
    -une pluralité de nœuds de type domaine (340);
    -une pluralité d’arêtes (320) représentant chacune une requête DNS d’un nœud de terminal client (311) vers un nœud de domaine (344) ; un nœud de domaine (344) pouvant être connecté à plusieurs nœuds de terminal client (311) et un nœud de terminal client (311) pouvant être connecté à plusieurs nœuds de domaine (344), et
    -la recherche de communautés de tuples dans ledit graphe biparti étant propre à générer des partitions distinctes (410, 430), elles-mêmes réparties en graphes bipartis incluant des tuples représentant un ensemble cohérent de terminaux clients faisant des requêtes DNS sur un ensemble de domaines.
  3. Procédé selon la revendication 2, caractérisé en ce qu’il comprend en outre une mesure de la qualité de la clusterisation selon un calcul de la modularité des communautés de tuples ainsi détectées.
  4. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape de filtrage par statistique descriptive.
  5. Procédé selon la revendication 4, caractérisé en ce que la statistique descriptive est une fonction de covariance, écart type ou de calcul de distance euclidienne.
  6. Procédé selon la revendication 1, caractérisé en ce qu’il comprend en outre une recherche de chaînages de clusters (712) dans le temps (711, 713, 714) selon au moins une technique appartenant au groupe formé par apprentissage automatique non supervisé, apprentissage automatique supervisé, détection de communauté.
  7. Système de détection d’un algorithme de génération de domaine DGA, dans un réseau de communication informatique (106) comprenant au moins un serveur de résolution de requêtes DNS (104) émanant d’au moins un terminal client (102), caractérisé en ce que le réseau de communication informatique (106) comprend en outre un module de détection (108) couplé au serveur de résolution (104) et comprenant des moyens de traitement de données configurés, pour chaque requête DNS, à associer le nom de domaine demandé et l’identité du terminal client demandeur pour former un tuple; à combiner en partitions homogènes les tuples ainsi combinés selon la technique de détection de communautés; et à en déduire pour chaque partition homogène l’ensemble des terminaux clients exploitant un même DGA.
  8. Système selon la revendication 7, caractérisé en ce que la détection de communautés comprend un graphe biparti comprenant :
    -une pluralité de nœuds de type terminal client (310), une pluralité de nœuds de type domaines (340);
    -une pluralité d’arêtes (320) représentant chacune une requête DNS d’un nœud de terminal client (311) vers un nœud de domaine (344) ; un nœud de domaine (344) pouvant être connecté à plusieurs nœuds de terminal client (311) et un nœud de terminal client (311) pouvant être connecté à plusieurs nœuds de domaine (344), et
    -la recherche de communautés de tuples étant propre à générer des partitions distinctes (410, 430), elles-mêmes réparties en graphes bipartis incluant des tuples représentant un ensemble cohérent de terminaux clients faisant des requêtes DNS sur un ensemble de domaines.
  9. Système selon la revendication 8, caractérisé en ce que les moyens de traitement comprennent en outre des moyens de mesure propre à mesurer la qualité de la clusterisation selon un calcul de la modularité des communautés de tuples ainsi détectées.
  10. Programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé selon l’une des revendications 1 à 6 lorsque ledit programme est exécuté sur le système de détection selon l’une des revendications 7 à 9.
FR2010294A 2019-10-10 2020-10-08 Système et procédé de détection d’un algorithme de génération de domaine DGA Active FR3101977B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1911252 2019-10-10
FR1911252A FR3101978B1 (fr) 2019-10-10 2019-10-10 Système et procédé de détection d’un algorithme de génération de domaine DGA

Publications (2)

Publication Number Publication Date
FR3101977A1 true FR3101977A1 (fr) 2021-04-16
FR3101977B1 FR3101977B1 (fr) 2024-02-16

Family

ID=70613818

Family Applications (2)

Application Number Title Priority Date Filing Date
FR1911252A Active FR3101978B1 (fr) 2019-10-10 2019-10-10 Système et procédé de détection d’un algorithme de génération de domaine DGA
FR2010294A Active FR3101977B1 (fr) 2019-10-10 2020-10-08 Système et procédé de détection d’un algorithme de génération de domaine DGA

Family Applications Before (1)

Application Number Title Priority Date Filing Date
FR1911252A Active FR3101978B1 (fr) 2019-10-10 2019-10-10 Système et procédé de détection d’un algorithme de génération de domaine DGA

Country Status (2)

Country Link
US (1) US11777969B2 (fr)
FR (2) FR3101978B1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12045198B2 (en) * 2022-07-29 2024-07-23 Dell Products L.P. Multi-domain and multi-tier scale-out architecture for clustered file systems

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8260914B1 (en) * 2010-06-22 2012-09-04 Narus, Inc. Detecting DNS fast-flux anomalies
US10198579B2 (en) * 2014-08-22 2019-02-05 Mcafee, Llc System and method to detect domain generation algorithm malware and systems infected by such malware
US10685295B1 (en) * 2016-12-29 2020-06-16 X Development Llc Allocating resources for a machine learning model
JP6912714B2 (ja) * 2017-07-21 2021-08-04 富士通株式会社 情報処理装置、情報処理方法および情報処理プログラム

Non-Patent Citations (15)

* Cited by examiner, † Cited by third party
Title
BLONDEL, VINCENT DGUILLAUME, JEAN-LOUPLAMBIOTTE, RENAUDLEFEBVRE, ETIENNE: "Fast unfolding of communities in large networks", JOURNAL OF STATISTICAL MECHANICS: THEORY AND EXPERIMENT., 9 October 2008 (2008-10-09)
CHUNYU HANYONGZHENG ZHANG: "CODDULM: An Approach for Detecting C&C Domains ofDGA on Passive DNS Traffic", 2017 6TH INTERNATIONAL CONFÉRENCE ON COMPUTER SCIENCE AND NETWORK TECHNOLOGY, 2017
DUGUÉ, N.;PEREZ, A..: "Doctoral dissertation,", 2015, UNIVERSITÉ D'ORLÉANS, article "Directed Louvain: maximizing modularity in directed networks"
GENNARO CORDASCOLUISA GARGANO.: "Dipartimento di Informatica", 2011, UNIVERSITY OF SALERNO, article "Community Détection via Semi-Synchronous Label Propagation Algorithms"
GUILLAUMELATAPY: "Modularities for bipartite networks", INFORMATION PROCESSING LETTERS, vol. 90, no. 6, 2004, pages 215 - 221
HAN CHUNYU ET AL: "CODDULM: An approach for detecting C&C domains of DGA on passive DNS traffic", 2017 6TH INTERNATIONAL CONFERENCE ON COMPUTER SCIENCE AND NETWORK TECHNOLOGY (ICCSNT), IEEE, 21 October 2017 (2017-10-21), pages 385 - 388, XP033333441, DOI: 10.1109/ICCSNT.2017.8343724 *
J. A. HARTIGANM. A. WONG.: "Algorithm AS 136: A K-Means Clustering Algorithm", JOURNAL OF THE ROYAL STATISTICAL SOCIETY, vol. 28, no. 1, 1979
J.M. KUMPULA;J. SARAMÂKIK. KASKIJ. KERTÉSZ: "Limited resolution in complex network community detection with Potts model approach", EUROPEAN PHYSICAL JOURNAL B. 2007, 2007
LIU ZHICHENG ET AL: "CCGA: Clustering and Capturing Group Activities for DGA-Based Botnets Detection", 2019 18TH IEEE INTERNATIONAL CONFERENCE ON TRUST, SECURITY AND PRIVACY IN COMPUTING AND COMMUNICATIONS/13TH IEEE INTERNATIONAL CONFERENCE ON BIG DATA SCIENCE AND ENGINEERING (TRUSTCOM/BIGDATASE), IEEE, 5 August 2019 (2019-08-05), pages 136 - 143, XP033653707, DOI: 10.1109/TRUSTCOM/BIGDATASE.2019.00027 *
M. ESTERH.-P. KRIEGELJ. SANDERX. XU: "A density-based algorithm for discovering clusters in large spatial databases with noise", PROCEEDINGS OF THE 2ND INTERNATIONAL CONFÉRENCE ON KNOWLEDGE DISCOVERY AND DATA MINING, 1996
M. ROSVALLD. AXELSSONC.T. BERGSTROM.: "Eur. Phys. J. Spécial Topics", vol. 178, 2009, SPRINGER-VERLAG, article "The Map Equation", pages: 13 - 23
MURATA, T: "Modularities for bipartite networks", HT '09: PROCEEDINGS OF THE TWEN-TIETH ACM CONFÉRENCE ON HYPERTEXT AND HYPERMEDIA, NEW YORK, NY, USA. ACM., 2009
TRUNG-DUC NGUYEN ET AL: "DGA Botnet detection using Collaborative Filtering and Density-based Clustering", PROCEEDINGS OF THE SIXTH INTERNATIONAL SYMPOSIUM ON INFORMATION AND COMMUNICATION TECHNOLOGY, SOICT 2015, 1 January 2015 (2015-01-01), New York, New York, USA, pages 1 - 7, XP055719996, ISBN: 978-1-4503-3843-1, DOI: 10.1145/2833258.2833310 *
TRUNG-DUC NGUYENTUAN-DUNG CAOLINH-GIANG NGUYEN: "DGA Botnet detection using Collaborative Filtering and Density-based Clustering", PROCEEDINGS OF THE SIXTH INTERNATIONAL SYMPOSIUM ON INFORMATION AND COMMUNICATION TECHNOLOGY. 2015 & 18TH IEEE INTERNATIONAL CONFERENCE, 2019
ZHICHENG LIUXIAOCHUN YUNYONGZHENG ZHANGYIPENG WANG.: "CCGA: Clustering and Capturing Group Activities for DGA -based botnets detection.", 18TH IEEE INTERNATIONAL CONFÉRENCE ON TRUST, SECURITY AND PRIVACY IN COMPUTING AND COMMUNICATIONS/13TH IEEE INTERNATIONAL CONFÉRENCE ON BIG DATA SCIENCE AND ENGINEERING, 2019

Also Published As

Publication number Publication date
FR3101978B1 (fr) 2024-02-09
FR3101977B1 (fr) 2024-02-16
US20210112084A1 (en) 2021-04-15
US11777969B2 (en) 2023-10-03
FR3101978A1 (fr) 2021-04-16

Similar Documents

Publication Publication Date Title
US10757101B2 (en) Using hash signatures of DOM objects to identify website similarity
EP3278516B1 (fr) Structure de détection et de classification de tunnel dns fondée sur une analyse de comportement pour sécurité de réseau
US9686283B2 (en) Using hash signatures of DOM objects to identify website similarity
US10425383B2 (en) Platforms for implementing an analytics framework for DNS security
US8260914B1 (en) Detecting DNS fast-flux anomalies
US10078743B1 (en) Cross identification of users in cyber space and physical world
Najafi et al. MalRank: a measure of maliciousness in SIEM-based knowledge graphs
US11716337B2 (en) Systems and methods of malware detection
CN112673386A (zh) 用于高效标签传播的基于集成的数据管理管道
Alenazi et al. Holistic model for http botnet detection based on dns traffic analysis
Venkatesh et al. BotSpot: fast graph based identification of structured P2P bots
Ma et al. DNSRadar: Outsourcing malicious domain detection based on distributed cache-footprints
Izhikevich et al. Predicting ipv4 services across all ports
CN112204930B (zh) 恶意域名检测设备、系统和方法
EP3586488B1 (fr) Détection d'attaques d'amplification sur les bases de données sur la base d'ipfix
Wright et al. Don’t@ me: Hunting twitter bots at scale
Brissaud et al. Passive monitoring of https service use
FR3101977A1 (fr) Système et procédé de détection d’un algorithme de génération de domaine DGA
Jusko et al. Using behavioral similarity for botnet command-and-control discovery
Wullink et al. ENTRADA: enabling DNS big data applications
Morichetta et al. LENTA: Longitudinal exploration for network traffic analysis from passive data
JP6669679B2 (ja) 分類装置、分類方法及び分類プログラム
Sharma et al. Evaluation of collaborative intrusion detection system architectures in mobile edge computing
Moore et al. Deep learning for network intrusion: A hierarchical approach to reduce false alarms
Liao et al. Malicious domain detection based on semi‐supervised learning and parameter optimization

Legal Events

Date Code Title Description
PLSC Publication of the preliminary search report

Effective date: 20211008

PLFP Fee payment

Year of fee payment: 2

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5