Génération automatique de règles Snort pour la détection des réseaux Fast-Flux

1. Qu’est-ce qu’un réseau Fast-Flux ?

1.1 Définition

Le Fast-Flux (FF) est le détournement d’une technique DNS légitime, le load-balancing. La technique des FF a pour vocation d'optimiser la durée de vie de certains types de réseaux. En effet, elle est utilisée par des sites Internet malveillants pour masquer leurs activités malicieuses (phishing, spamming, malware delivering, pédopornographie...).

Les réseaux FF se basent sur l’utilisation de machines infectées appelées botnets, pouvant être des ordinateurs de particuliers, d’entreprises ou même des serveurs. Ces botnets sont regroupés en un réseau dont le contrôle est assuré par un serveur central appelé Command and Control (C&C). Un tel réseau sera appelé Fast-Flux Service Network (FFSN).

Les botnets étaient à l’origine utilisés sur des serveurs Internet Relay Chat (IRC). Un script en cours d'exécution sur une machine infectée permet de prendre le contrôle d’un salon via une présence continue, d’y diffuser du contenu et de récupérer des données sur les clients de ce dernier. L’automatisation des actions et la rapidité de propagation des données par les botnets IRC ont donné lieu au concept de machines zombies, utilisées actuellement dans les FFSN.

 

 

 

 

1.2 Single Flux et Double Flux

Il existe deux types de FFNS : ceux basés sur un mécanisme Single Flux et ceux basés sur un mécanisme Double Flux.

Dans un FFSN Single Flux, les botnets servent de « proxy inversés » au site malveillant (seule l'adresse IP du serveur C&C est connue). Un serveur DNS, contrôlé via un serveur C&C, redirige les clients vers les bots, ce qui permet également de répartir la charge entre ces derniers.

Un FFSN Double Flux, en plus d’utiliser des bots comme proxies pour des sites malveillants, utilise certains de ces derniers comme proxies DNS. Les requêtes envoyées vers ces « faux » DNS sont transmises au(x) serveur(s) C&C, qui choisit alors les bots vers lesquels rediriger les trafics. Un FFSN Double Flux possède donc, en plus du Single Flux, les caractéristiques suivantes :

- Un DNS à plusieurs niveaux ;

- De changer fréquemment l'association NS-IP auprès du registraire du nom de domaine.

De par sa topologie et ses caractéristiques, il est donc plus difficile de détecter le pirate d'un réseau Fast-Flux. Enfin, certains registraires de domaines prêtent peu d'attention aux activités de leurs clients ce qui ne facilite pas la lutte contre les réseaux Fast-Flux.

1.3 Mode de déploiement

Deux modèles d’architecture existent pour les FFSN : centralisé ou décentralisé.

Dans un FFSN centralisé, tous les botnets sont contrôlés au moyen d’un serveur C&C. Le contrôle se fait en direct ou à l’aide d’un nœud supérieur dans la hiérarchie, qui servira de relais au serveur C&C. Historiquement, le protocole HTTP sert de vecteur de communication, mais on trouve à présent des FFSN basés sur le protocole HTTPS et utilisant le réseau TOR (The Onion Router). Ce changement est autant lié aux faiblesses du premier, comme l’absence de chiffrement qui facilite la détection, qu’aux forces des suivants, par exemple le chiffrement ou encore « l’anonymisation ». Le modèle centralisé présente un single point of failure au travers du serveur C&C, mais cette faiblesse est quelque peu compensée par l’anonymat apporté par le réseau TOR.

Les FFSN décentralisés sont eux basés sur des protocoles P2P (Peer-to-Peer), ce qui les rend très robustes. Chaque nœud pouvant jouer le rôle d’un serveur C&C et/ou d’un bot, la destruction de l’un d’entre eux n’affecte pas le fonctionnement global d’un FFSN. La tendance à bloquer le protocole P2P en entreprise, principalement utilisé pour réaliser des téléchargements illégaux, remet cependant en cause certaines utilisations de ce modèle.

1.4 Utilisation des Fast-Flux

Les FFSN sont principalement utilisés pour le spam, le phishing et la distribution de malwares au travers de sites malicieux. Ils exploitent des techniques comme le Round-Robin DNS et s'inspirent du modèle CDN (Content Delivery Network), pour passer inaperçus.

La durée de vie de tels réseaux dépendra de leur vocation. L’article traitant des comportements des FFSN [13], montre dans une étude que les FFSN utilisés dans le cadre du spam sont les plus pérennes, à l’inverse de ceux consacrés à la distribution de malwares par exemple. La taille joue également un rôle important dans la durée de vie des FFSN. Une taille importante permet de garantir une certaine persistance face à la destruction des botnets, mais aussi d'être moins détectable en disposant de plus de sources différentes. On notera cependant, toujours selon cette étude, que l’augmentation de la durée de vie par rapport à la taille atteint une asymptote. Le facteur taille ne permet pas de prolonger à l’infini la vie d’un FFSN.

2. Solutions théoriques

Dans cette partie, nous allons présenter plusieurs études de recherche dont le but était de détecter des domaines FF.

2.1 Détection via caractéristiques bot et DNS

La première solution de détection en temps réel des FFSN est proposée par Martinez-Bea et al [8]. L’objectif de cette solution est la détection en temps réel de services de FFSN. Elle se base sur deux méthodes existantes en les reprenant et en les combinant afin d’améliorer les résultats.

La première méthode [9] exploite les caractéristiques d’une requête DNS à un domaine (nombre d’IP pour un domaine, nombre de pays différents…) et les compare à des valeurs seuils typiques des domaines FF. La seconde méthode [6] se base sur les facteurs intrinsèques aux botnets (latence du réseau, temps de chargement d’une page…) et les compare également à des valeurs seuils pour indiquer s'il s'agit d'un domaine FF.

Chacune de ces méthodes présentait des résultats avec soit beaucoup de faux négatifs, soit beaucoup de faux positifs. Ici, la solution combine ces deux méthodes pour outrepasser leurs limites.

Un test a été fait en comparant la détection de domaines FF des trois méthodes, voici le résultat.

 

 

Comme nous pouvons le voir, en combinant les deux méthodes, il y a une réduction non négligeable du nombre de faux positifs et faux négatifs. Cependant, on observe que la méthode n’est pas optimale avec la présence d’un faux positif.

Finalement, la force d'une des méthodes comblant la faiblesse de l'autre et vice versa, c'est par la combinaison de ces deux recherches que les auteurs ont créé un moyen de détection fiable des domaines FF.

2.2 Détection des Fast-Flux en temps réel

La seconde solution [12] est aussi une solution en temps réel proposée par le groupe de recherche Milcord.

Sa méthodologie repose sur 5 capteurs :

- 3 capteurs actifs :

- 2 capteurs passifs :

La partie intéressante est au niveau de la partie active de la solution. La détection du TTL permet un premier filtrage grossier des noms de domaines. Un site sain a, en général, un TTL plus élevé qu’un FFSN par exemple, 300 pour Google jusqu’à 3600 pour Microsoft. Cependant certains FFSN peuvent avoir un TTL supérieur à 300.

Le répertoire d’activité FF est un capteur qui va enregistrer l’activité d’un FF pendant 24h et va permettre d’affiner le résultat de la détection par TTL.

Le capteur d’activité va réagir lorsque les FFSN arrêtent de fonctionner pendant quelques heures ou jours afin d’éviter d'être détectés. Ce comportement n’est pas visible sur un nom de domaine sain tel que google.com, car il doit être tout le temps disponible. C’est cette absence d’activité qui peut être un facteur indiquant la présence d’un FF.

Le répertoire d’empreintes associe les adresses IP d’un domaine avec l’Autonomous System Number (ASN), caractéristique dépendant du Fournisseur d’Accès à Internet. Un domaine FF se disperse plus facilement qu’un domaine sain, car il possède les adresses de machines contaminées partout dans le monde. C’est en calculant l’indice de dispersion et en le comparant à un seuil, choisi arbitrairement, que le domaine sera répertorié sain ou non.

 

 

Pour conclure, cette solution est capable de montrer un taux de détection moyen de 96% sur une fenêtre de tests de 10 minutes et peut atteindre 100% sur des durées supérieures à 10 minutes.

2.3 Détection par data-mining

Nous avons étudié un article de recherche [11] comparant trois techniques de data-mining, utilisées dans le cadre de la détection de FFSN, à savoir :

- Régression linéaire ;

- Classification naïve bayésienne ;

- Méthode des K plus proches voisins.

Chacune de ces techniques a été testée dans un environnement réaliste (60 000 domaines sains pour 100 domaines FF). Il en ressort que la technique la plus efficace est celle des K plus proches voisins. Elle possède en moyenne des résultats supérieurs à ceux des deux autres techniques.

Il faudra cependant noter que cette solution n’est pas une méthode de détection a priori de FF, mais a posteriori. Ce qui signifie que l’utilisateur doit se connecter sur un domaine pour que la solution puisse donner son verdict. De plus, cette option possède certaines limites :

- La similitude des caractéristiques d’un domaine sain par rapport à un jeune domaine FF ;

- L’évolution des technologies qui nécessite une mise à jour constante de la solution.

2.4 Détection par géolocalisation

Cette méthode repose sur les principes de la géolocalisation pour détecter les domaines basés sur des FFSN. Nous avons étudié deux travaux de recherche [7] [10] proposant une implémentation concrète :

- Spatial Snapshot Mechanism for Delay-free Detection ;

- Localized Spatial Geolocation Detection.

Ces solutions sont « Delay-free ». Elles se basent sur une seule réponse DNS pour classifier un domaine. Elles utilisent la position géographique des bots, diverses métriques spatiales et des bases de données externes pour fonctionner.

Les principales métriques spatiales employées sont :

- La dispersion : la présence dans différents pays ;

- Le degré de relation spatiale des services : distance entre un hôte et le fournisseur de service.

Par exemple, un réseau FF aura tendance à avoir des bots présents dans différents pays, éloignés de leur fournisseur de services et dans des Autonomous System (AS) très différents.

La détection se décompose en quatre étapes :

- Extraction des données d’une réponse DNS ;

- Récupération des informations spatiales ;

- Génération des métriques ;

- Classification du domaine analysé (FFSN ou non).

En plus de la rapidité de détection, cette méthode présente l’avantage de ne pas se laisser tromper par les FFSN se camouflant en réseaux bénins. En effet, elle se base peu sur les caractéristiques réseaux des FFSN (TTL, nombre de bots, nombre d’adresses IP…) et les FFSN ne peuvent fausser leurs caractéristiques géographiques.

Cependant, en l’absence de données spatiales associées aux domaines scannés, cette méthode se trouve dans l’incapacité totale de fonctionner.

2.5 Limites des solutions de détections actuelles

Les FFSN ont tendance à s’adapter aux techniques de détection, notamment ceux en temps réel, afin de maximiser leur durée de vie et leur efficacité. Les réseaux malveillants « copient » les caractéristiques de réseaux légitimes, exploitant notamment les techniques du RR-DNS et des CDN citées précédemment. Les moyens de détections deviennent ainsi moins précis et peuvent voir leur période de collecte d’informations sensiblement rallongée. Il est important de noter que, même si en théorie il est possible de se rapprocher de valeurs seuils pour se faire passer pour un domaine sain, en pratique cela reste extrêmement difficile et complexe à réaliser.

Certaines caractéristiques propres aux FF restent cependant difficilement camouflables. Par exemple, ces réseaux souffrent d’une dispersion géographique élevée en raison de la nature même des botnets. On peut aussi remarquer un important turnover au niveau des adresses IP liées à la suppression de nœuds, ainsi que des adresses largement réparties et non successives.

3. Approche proposée pour la détection via les blacklists

3.1 Principe

Notre outil a pour objectif de détecter des connexions d’utilisateurs d’un réseau à des domaines FF. Cet outil est implémentable rapidement et facilement afin de permettre son utilisation par toutes les entreprises, contrairement aux solutions théoriques vues précédemment. Son objectif diffère cependant de ces dernières solutions et leur est complémentaire. En effet, il vise la détection des connexions sortantes vers des sites hébergés sur des réseaux FF, plutôt que leur détection en soit.

Pour fonctionner, notre outil est composé de trois modules :

- L'IDS/IPS Snort ;

- Un script Bash ;

- Une blacklist.

L'IDS Snort est au cœur de la solution de détection. Cet outil de détection d'intrusion a été retenu, car il est librement accessible à toutes les entreprises (distribué sous licence GPL). Il jouit également d'une communauté active et d'une certaine popularité, ce qui se traduit par une documentation facilement accessible sur Internet.

Le script joue un rôle central dans l’outil, c’est lui qui va permettre de créer la blacklist et de l’intégrer à l’IDS de manière automatique. Le langage Bash fut choisi, car il permet l'exploitation du script par un grand nombre de distributions Linux.

La blacklist se compose, quant à elle, de domaines reconnus comme étant malveillants (FFSN, distribution de malwares…) par des sites spécialisés de confiance. Ces derniers distribuent des listes de domaines et d’adresses identifiées pour leurs activités frauduleuses, dangereuses ou comme infectées par des botnets. Les sites Internet choisis sont Malwaresdomains, Palevotracker, Spyeyetracker et Zeustracker.

L'installation de cette solution a été réalisée sur un Raspberry Pi utilisé lors du développement et des tests présentés plus tard dans cet article.

3.2 Algorithme

3.2.1 Le script

Pour chacune des bases de données, nous obtenons une liste de domaines malveillants, incluant des domaines FF.

Le script Bash va tout d’abord extraire ces données afin d’obtenir les URLs de ces domaines FF en « parsant » chacune des listes des sites précédents.

Les listes des domaines sont récupérées via la commande wget et sont ajoutées dans un fichier temporaire. Ensuite, la fonction addDomain ajoute le contenu de ce fichier temporaire dans un autre fichier comportant l’ensemble des domaines trouvés sur les quatre sites cités précédemment, et ce uniquement si le domaine ne s’y trouve pas déjà.

Une fois la liste de ces domaines établie, le script génère une règle Snort par domaine et place ces dernières dans un fichier .rules dédié. Une sauvegarde de l’ancien fichier de règles est archivée en cas de problèmes.

Une fois l’opération terminée, le script se charge de relancer Snort afin que les nouvelles règles puissent être prises en compte. Pour cela, le script retrouve le PID du processus Snort en cours d’exécution et le réinitialise à l’aide de la commande suivante, qui oblige la relecture de la configuration :

Enfin, à l’aide de la commande cron permettant l’exécution automatique de tâches, nous pouvons paramétrer le script afin qu’il se lance régulièrement de manière autonome afin de garder les bases à jour.

3.2.2 La règle Snort

L’objectif de la règle est, qu’une fois en place, Snort puisse détecter la connexion d’utilisateurs de notre réseau à des domaines FF connus et générer une alerte. Voici un exemple de règle dont on se servira pour la suite pour expliquer comment cela fonctionne avec le domaine factice FF xyz.com :

3.2.2.1 Variables d’entrées

Les variables d’entrées $HOME_NET, $EXTERNAL et $HTTP_PORTS sont à définir au préalable dans le fichier de configuration de Snort pour le fonctionnement de l'IDS.

La variable $HOME_NET doit contenir l’adresse réseau de l’entreprise ou le sous-réseau que l’on souhaite surveiller. La variable $EXTERNAL doit contenir l’adresse des réseaux de destination des flux que l’on souhaite également surveiller, étant donné que les domaines FF sont présents sur Internet, il est préférable de la configurer en mettant l’adresse 0.0.0.0 afin d’indiquer à Snort que l’on souhaite surveiller tous les paquets sortants. Pour terminer, la variable $HTTP_PORTS détermine les ports de destination des flux que l’on souhaite surveiller. Les flux ici étant des flux web, il faut la définir pour monitorer les protocoles HTTP et HTTPS.

3.2.2.2 L’objet recherché

Les champs de la règle permettant à Snort de détecter la connexion d'un utilisateur à un domaine FF sont content et http_method. En effet, content:”GET” et http_method permettent de spécifier à Snort de rechercher dans les paquets toutes les requêtes de type HTTP GET parmi celles sortantes du réseau. Les deux autres instructions content (« Host » et « mondomain.ru ») sont présentes afin de rechercher le champ comportant l’adresse URL dans un paquet HTTP GET sortant émis par un client. Pour mieux comprendre la règle, voici une capture d’écran d’une requête HTTP GET sur Wireshark.

 

 

Comme nous pouvons le voir, le paquet HTTP GET contient le champ suivant : Host: domaine\r\n. C’est cela qu’exploite Snort pour générer les alertes avec les mots clés indiqués précédemment. À noter que \r\n correspond à |0d 0a| en hexadécimal, ce qui correspond bien à l’une des instructions content que nous avons.

Enfin, nous avons séparé le content “Host” et le content de l’URL afin d’éviter l’apparition de faux positifs, c’est-à-dire un domaine légitime qui a été identifié par Snort en tant que domaine FF. Cela peut être, par exemple, une recherche Google avec l’URL d’un domaine FF.

3.2.2.3 Les champs msg et classtype

Le champ msg de la règle permet l’affichage d’informations concernant cette dernière dans les logs et la console. Notre script remplit automatiquement ce champ avec la valeur Fast-Flux domain : <nom du domaine> en se basant sur la blacklist créée précédemment.

De plus, nous avons créé au préalable dans Snort un type de classe particulier pour les alertes Fast-Flux afin d’améliorer leur visibilité. Ce type est référencé dans la règle via le champ classtype:fast-flux. C’est également dans cette classe que l’on définit le niveau de criticité d’une alerte. Les FF étant potentiellement dangereux, nous avons décidé de donner à cette classe une priorité 1, c’est-à-dire la plus élevée.

Ces deux champs permettent de retrouver plus facilement des informations de détection de FF dans les fichiers de logs ou dans une éventuelle Interface graphique.

3.2.2.4 Conclusion

Voici un exemple d’alerte que Snort génère suite à la connexion d’un utilisateur au domaine FF factice xyz.com :

Nous avons donc un outil capable de récupérer une liste de domaines FF sur plusieurs bases de données connues, de mettre à jour les règles de Snort et de les appliquer en le réinitialisant de manière automatique.

3.3 Expérimentations et résultats

Afin de tester l’outil, nous avons utilisé une liste de sites Internet regroupant deux types de sujets. Le premier type correspond à 1000 domaines sains, c’est-à-dire des sites Internet tout à fait légitimes comme Google. Ces derniers ont été récupérés sur le site Alexa [14] qui référence les sites les plus visités sur Internet. Le second type correspond aux domaines FF. Lors de l’expérimentation, nous avons récupéré une liste de 177 domaines FF obtenus sur les quatre sites fournissant les bases de données, cités précédemment.

 

	Fast-Flux	Sain
Nombres de domaines	177	1000

Nous avons également utilisé un poste client qui va se connecter aux sites Internet de la liste. Il est branché à un Hub sur lequel est connecté notre IDS Snort, afin que ce dernier puisse analyser les connexions de l’utilisateur.

Enfin, nous avons utilisé la commande wget dans un script pour automatiser les connexions utilisateurs vers les sites Internet.

À l’issue de cette étape, nous obtenons les résultats dans le fichier « alert » généré par Snort. Dans ce fichier sont référencées les alertes émises par Snort lorsqu’un paquet HTTP GET a été identifié positivement par une règle Snort. À l’aide d’un autre script, nous avons pu déterminer quels sites ont été reconnus ou non dans les alertes

À l'issue de plusieurs tests, nous avons obtenu toujours les mêmes résultats, à savoir :

 

	Vrai positif	Vrai négatif	Faux positif	Faux négatif
Domaines détectés	177	1000	0	0

Cette expérience démontre deux choses : que les règles sont bien toutes créées automatiquement, mais aussi que ces dernières ont relevé tous les sites malveillants, sans logger de connexions à destination d'un site légitime.

Conclusion

Nous avons pu constater que les solutions apportées par les chercheurs sont difficiles à mettre en œuvre par une entreprise et peu nombreuses.

De notre côté, nous voulions créer une solution simple, économique et rapide à mettre en place. Son champ d’action dépend de bases de données, sur lesquelles nous n’avons aucun contrôle, mais cet outil garantit une détection fiable des connexions vers les domaines FF blacklistés.

Cette solution permet donc, après détection, d’alerter l’administrateur afin qu’il puisse réagir rapidement pour effectuer toutes les actions nécessaires, comme isoler les machines potentiellement infectées du réseau.

En revanche, seules les communications réalisées par le biais du protocole HTTP sont prises en charge. Pour les communications en HTTPS, il est possible de se tourner vers une solution de blacklist basée sur un proxy. Le proxy sera placé en coupure pour détecter quel est le domaine visé par la requête d'un client.

Enfin, cette solution est complémentaire et ne remplace en aucun lieu les autres équipements (FW, AV, Proxy…) ni les procédures mises en place pour la sécurisation d’un réseau et de ses équipements.

Bibliographie

[1] Malwaredomains. http://malwaredomains.lehigh.edu/files/domains.txt

[2] MaxMind - GeoIP | Base de données de localisation d’adresses IP. https://www.maxmind.com/fr/geolocation landing

[3] Palevotracker. https://palevotracker.abuse.ch/blocklists.php?download=domainblocklist

[4] Spyeyetracker. https://spyeyetracker.abuse.ch/blocklist.php?download=domainblocklist

[5] Zeustracker. https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist

[6] Ching-Hsiang Hsu, Chun-Ying Huang, and Kuan-Ta Chen. Fast-flux bot detection in real time. In Somesh Jha, Robin Sommer, and Christian Kreibich, editors, Recent Advances in Intrusion Detection, number 6307 in Lecture Notes in Computer Science, pages 464–483. Springer Berlin Heidelberg, 2010.

[7] Si-Yu Huang, Ching-Hao Mao, and Hahn-Ming Lee. Fast-flux service network detection based on spatial snapshot mechanism for delay-free detection. In Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security, ASIACCS ’10, page 101–111. ACM, 2010.

[8] S. Martinez-Bea, S. Castillo-Perez, and J. Garcia-Alfaro. Real-time malicious fast-flux detection using DNS and bot related features. In 2013 Eleventh Annual International Conference on Privacy, Security and Trust (PST), pages 369–372.

[9] D.K. McGrath, A. Kalafut, and M. Gupta. Phishing infrastructure fluxes all the way. 7(5) :21–28, sept.-oct. 2009.

[10] Horng-Tzer Wang, Ching-Hao Mao, Kuo-Ping Wu, and Hahn-Ming Lee. Real-time fast-flux identification via localized spatial geolocation detection. In Computer Software and Applications Conference (COMPSAC), 2012 IEEE 36th Annual, pages 244–252.

[11] Jiayan Wu, Liwei Zhang, Jian Liang, Sheng Qu, and Zhiqiang Ni. A comparative study for fast-flux service networks detection. In 2010 Sixth International Conference on Networked Computing and Advanced Information Management (NCM), pages 346–350.

[12] Caglayan A., Toothaker M., Drapeau D., Burke D., Eaton G. « Real-Time Detection of Fast Flux Service Networks ». In : Conference For Homeland Security, 2009. CATCH ’09. Cybersecurity Applications Technology [En ligne]. Conference For Homeland Security, 2009. CATCH ’09. Cybersecurity Applications Technology. [s.l.] : [s.n.], 2009. p. 285‑292. Disponible sur : http://dx.doi.org/10.1109/CATCH.2009.44

[13] Alper Caglayan, Mike Toothaker, Dan Drapaeau, Dustin Burke, and Gerry Eaton. Behavioral Patterns of Fast Flux Service Networks. In Proceedings of the 2010 43rd Hawaii International Conference on System Sciences (HICSS '10). IEEE Computer Society,Washington,DC,USA,1-9.DOI=10.1109/HICSS.2010.81 http://dx.doi.org/10.1109/HICSS.2010.81

[14] Alexa Top Global Sites. http://www.alexa.com/topsites