mardi 16 mars 2010

Analyse DNS comportementale anti-botnets

L'administrateur réseau et sécurité doit surveiller son réseau pour détecter des activités malveillantes afin d'y parer. Le problème est classique et revient à s'interroger sur ce qui différencie une action normale d'une action malveillante. L'evil Bit étant resté au rang de draft, le meilleur moyen consiste d'avoir des logs et de les consulter.
Le log management est une activité à part entière et généralement on est coincé entre des logs gigantesques contenant forcément l'information pertinente, mais noyée, et des logs réduits qui ne sont finalement que quelques statistiques facilement exploitables, mais loin d'être suffisantes.

Aujourd'hui, le risque, c'est le botnet. Les filtres IP en bordure deviennent puissants, de niveau applicatif, et il devient difficile de les attaquer de front. Toutefois, cela n'empêche pas les botnets de communiquer. Certains utilisent des protocoles de type P2P, ce qui peut se bloquer simplement, d'autres des requêtes web légitimes protocolairement parlant ce qui est bien plus compliqué à bloquer.

Toutefois, je pense qu'il est possible de tracer l'activité de machines zombifiées. Tout d'abord, il faut se poser la question: "que font ces machines?". Elles se connectent au canal de commande et contrôle, puis obéissent aux ordres reçus. Ces ordres sont (je schématise), soit envoyer du SPAM en quantités, soit servir de relais web (ou P2P) pour héberger du malware servant à infecter les futures victimes. La partie qui transforme la machine en site web ne m'intéresse pas. Regardons de plus près les autres activités.

Effectuons une analyse rétroactive. Ces machines vont donc tôt ou tard envoyer du SPAM. Cette activité revient à envoyer du mail. Comment envoie-t'on un mail? En débutant par une requête mail MX pour trouver l'adresse IP du serveur mail de destination. Ceci est donc une trace permettant de lever une suspicion légitime: toute machine de son réseau effectuant une requête DNS MX doit immédiatement être investiguée plus en avant.

Mais à l'origine, le zombie doit se connecter à son canal de commande. Encore une fois, il doit réaliser une requête DNS pour trouver l'adresse IP de destination. Il s'agit d'une requête de type A, banale, commune à toutes les autres requêtes. Toutefois, je pense qu'on peut creuser par là. Les domaines changent en permanence, inutile de vouloir corréler la dessus. Par contre, un point m'a toujours étonné: comment font ces botmaster pour déposer 5000 noms de domaines par jour, alors qu'en déposer un me coute 5 euros? La réponse est simple, il suffit de trouver un registrar complaisant. Et ce point me semble suffisement important pour être noté.
Donc il suffit de surveiller son DNS, et chercher les authoritative DNS pour chaque domaine interrogé. Ensuite, une liste est faite entre les DNS "finaux" si je peux dire, et les requêtes faites par les machines locales. Cette liste permettra d'indiquer une part de "crédibilité" du serveur DNS répondant du domaine. Si un léger pourcentage des machines de mon réseau interroge régulièrement des serveurs DNS hébergés chez un fournisseur n'ayant pas toute les garanties, cela doit être un signal d'alarme.
Comment connaître ces DNS douteux? Je pense que la géolocalisation IP est une piste qui doit être corrélée avec les AS contenant les serveurs.
Petit à petit, il doit être possible de donner un indice d'innocuité ou non à des serveurs DNS, à la manière de DNSBL ou autre mécanisme de ranking.
Idéalement, il serait sans doute possible d'identifier un botnet via ses serveurs DNS de références (quel AS, quel registrar, etc...)

Le volume de ces données doit rester gérable même pour des gros réseaux en fonction des doublons. Chaque nom de domaine doit être unique dans la base. Ensuite, chaque enregistrement des serveur DNS doit remonter la liste des domaines dont il s'occupe.

Quoi qu'il en soit, cela ne réglera pas le problème des botnets. Cette méthode permet à mon avis d'être plus proactif dans la détection des machines zombifiées sur un gros réseau uniquement avec une analyse des logs DNS:
-si une machine émet une requête DNS MX, alors une analyse est nécessaire
-un log continu des requêtes DNS A des machines doit permettre de trouver assez rapidement quelles machines vont se connecter sur le botmaster, et devra mener à une analyse approfondie.
Pour valider cette analyse j'aurais besoin de grandes quantités de trafic DNS sur un réseau vaste. Je ne pense pas que cela se trouve facilement sur internet. Toutefois, cela mériterait qu'on s'y arrête, ne serait-ce que pour essayer.

3 commentaires:

  1. Bonjour Kevin,
    ton blog est très bien. J'ai ajouté un lien vers lui sur le mien. Je te serais reconnaissant si tu considérais que cela vaut la peine pour toi d'en faire autant: http://infond.blogspot.com
    PS: bien sûr, il est inutile de valider ce commentaire :)
    Au plaisir de te rencontrer.
    t0ka7a

    RépondreSupprimer
  2. Merci pour le link, mais je n'ai pas de barre de link ou mettre le tien. Je valide le commentaire, ton blog est également très intéressant.
    Je suis justement en train de faire pas mal d'études sur la mise en oeuvre de TPM sous linux donc ton blog est source d'inspiration :)

    RépondreSupprimer
  3. Super intéressant, merci.
    Pour info http://dnslookup.fr permet de faire l'audit complet d'un domaine.

    RépondreSupprimer