Article MISC Mai 2007 – Mon serveur DNS, mon IDS oublié

Cet article est issu de l’article publié dans le numéro de [MISC n°31 de Mai 2007|http://www.ed-diamond.com/produit.php?ref=misc31&id_rubrique=8&caracteristique=1-2-&caracdisp=2-9-|fr]. J’en suis l’auteur (christophe.brocas@free.fr). Tous droits réservés à MISC. Je le poste ici car l’idée d’utiliser son serveur DNS semble être dans l’actualité du monde de la détection d’intrusions.

Cet article est issu de l’article publié dans le numéro de MISC n°31 de Mai 2007. J’en suis l’auteur (christophe.brocas@free.fr). Tous droits réservés à MISC. Je le poste ici car l’idée d’utiliser son serveur DNS semble être dans l’actualité du monde de la détection d’intrusions.

Mon serveur DNS, mon IDS préféré
Christophe Brocas, christophe.brocas@free.fr

Le Système d’Information (SI) des entreprises est un capital de ressources à protéger des attaques et, si une attaque réussit, la compromission et les évasions de données doivent être détectées le plus tôt possible. Pour détecter des postes compromis sur le réseau de l’entreprise, des solutions complexes et onéreuses sont souvent proposées aux Directeurs Informatiques (DSI) mais le plus souvent, peu de solutions de détection anti-intrusions sont effectivement en place. Or, la bonne compréhension à la fois de son architecture et du comportement des codes malicieux présents sur les postes compromis permet de proposer une première réponse élégante, peu couteuse et efficiente à cette problématique.

1. Introduction

1.1 Compromission de postes

Uune détection, quelle détection ? Afin de sécuriser son SI, une entreprise doit déployer une interconnexion applicative filtrée par des proxies et des serveurs dédiées (exemples : filtrage http/smtp, relais dns) afin de pouvoir fixer des règles de sécurité consistantes. Cependant, une fois cette architecture déployée, la majorité des entreprises ne semble pas se préoccuper des tentatives de contournement/d’accès direct à l’extérieur depuis un poste du LAN compromis. Elles se reposent généralement sur les différentes alertes que peuvent remonter les solutions d’antivirus postes et serveurs. Or, si les protections amont de filtrages des flux HTTP/SMTP sont utiles, la détection des postes compromis est nécessaire tant sur le plan de l’intégrité des données de son SI que sur le plan de la responsabilité de l’entreprise qui pourrait ainsi fournir, par exemple, une base à des réseaux de postes zombies.

1.2 Avoir un IDS sans le savoir

La solution ? L’analyse des serveurs applicatifs est un moyen simple de connaître les compromissions potentielles dans son LAN. Les logs du serveur DNS et, dans une moindre mesure, ceux du pare-feu sont des sources de données disponibles pour effectuer cette veille anti-intrusion.

Concentrons-nous sur le DNS : comment diable un serveur DNS peut-il nous révéler les intrusions déjà effectuées sur son réseau ?

Et les réponses sont :

  • comprendre le comportement des différents types de codes malicieux présents sur les postes compromis ;
  • en déduire les types de requêtes DNS pouvant être émis par ces codes ;
  • en fonction de ces profils, analyser les logs du serveur DNS et isoler les postes susceptibles d’être compromis.

2. Architecture à base de proxies et de relais :

C’est un pré-requis nécessaire. Mais, attention, dans les logs d’un serveur DNS, rien ne distingue une requête émise par un poste de celle émise par un autre. Le seul moyen de stigmatiser une requête émise par un poste en particulier est de pouvoir définir le comportement normal d’un poste en termes de requêtes DNS. Et ce, par rapport à celui, différent, des serveurs de type proxies ou relais.

2.1 Flux vers l’Internet : « authentication required » !

Les flux émis vers l’Internet depuis un poste de travail sont nombreux : * émis consciemment par l’utilisateur : envoi d’email, navigation sur le web ou téléchargement de fichiers etc ; * mais aussi émis de manière invisible pour l’utilisateur : mise à jour du système d’exploitation, rapatriement de mises à jour antivirales etc . Et je ne parle que des flux légitimes !


Figure 1 : architecture proxies et serveurs relais

Et pour être reconnus comme légitimes, l’ensemble de ces flux doivent être soumis à habilitation. Pour cela, il faut que ces flux soient reroutés de manière systématique vers des équipements de filtrage nécessitant une habilitation, à savoir les proxies ou serveur relais. Habilitation que devra renseigner l’utilisateur pour chaque type de flux. !!2.2 Proxies et relais, uniques émetteurs de requêtes DNS vers Internet’ Les machines proxies ou relais se doivent, pour être utilisées, d’exiger de l’utilisateur une authentification. Cela se traduit par des demandes d’identification HTTP par le proxy HTTP ou l’utilisation de SMTP AUTH pour l’envoi de mail via le serveur SMTP de votre entreprise. Les flux émis par les postes vers Internet sont alors authentifiés, donc moins sujet à être vecteur d’attaques.


Figure 2 : étapes d’une requête HTTP

Le gain de cette architecture en termes de détection d’intrusion ? Tout le trafic émis par les postes à destination de l’Internet est dans un premier temps redirigé vers ces machines intermédiaires. Les requêtes DNS de résolution de domaines internet ne sont alors plus émises que par ces équipements proxies et relais :

  • En effet, afin de pouvoir router, par exemple, les requêtes HTTP vers google.fr émises par un poste (point 1 sur la figure 2) ;
  • le proxy de l’entreprise demande une résolution DNS de type A sur le domaine google.fr (point 2) pour le compte de ce poste ;
  • La requête peut ensuite être émise vers le serveur HTTP cible (point 3).
  • NB : Il en est de même pour les envois de mails où le serveur SMTP joue le rôle du proxy HTTP.

Comme vous pouvez le voir, grâce à cette architecture centralisée et maîtrisée, les logs de votre serveur DNS deviennent de manière mécanique des sources fiables de données de détection d’intrusion : toute demande de résolution DNS d’un domaine internet émise par un poste lambda peut être considérée comme une alerte d’une compromission potentielle.

3. Configuration du serveur DNS Bind

3.1 Configuration par défaut : état des lieux

Les configurations figurant dans cet article décrivent la configuration d’un serveur DNS Bind et ont été testées avec un serveur Bind en version stable 9.3.2 sous Ubuntu 6.06. La configuration par défaut d’un serveur DNS Bind ne collecte pas dans ses fichiers de logs les requêtes émises par les clients DNS. En effet, ces requêtes peuvent générer beaucoup d’écritures dans ces fichiers dont la taille peut donc augmenter rapidement. Nous allons donc utiliser la gestion automatique des fichiers de logs fournie par Bind, gestion améliorée depuis la version 9.3 par la gestion d’une taille maximale de fichiers de logs. Une présentation des options de logging de Bind a été faite dans un article précédent de MISC

3.2 Collecte des requêtes clientes dans les logs de Bind

Voici un exemple de définition d’un channel permettant de collecter les requêtes émises par les clients :

# Declenchement du log des requetes
querylog;
# paragraphe definissant le logging 
logging { 
channel querieslogs { 
file "queries.log" versions 10 size 20m; 
print-time yes;
print-category yes;
};
category queries { 
querieslogs; }; 
}; 

 

 

Des fichiers de configuration complets pour chaque type de serveur (cache interne, cache internet, maitre interne et maitre internet avec des sections de logs complètes sont disponibles sur le site de MISC. De plus, vous trouverez la documentation exhaustive des options de log de Bind en ligne sur le site du logiciel .

4. Que chercher dans les logs ?

4.1 Topologie du comportement réseaux des codes malicieux

Un poste de travail compromis par un code malicieux a pour vocation de devenir une source d’informations émises à destination de serveurs externes, ou une source d’attaques pouvant être pilôtées ou pas depuis Internet. Dans les deux cas, une communication vers des serveurs externes tentera d’être initiée. Ces serveurs peuvent être des cibles d’attaques (spams[], dénis de services distribuées[]), des serveurs de contrôle fournissant des instructions aux codes malicieux distribuées ou bien des serveurs de collecte d’informations usurpées à l’utilisateur du poste.

4.2 Requêtes DNS émises par des codes malicieux

Ils existent deux grands types de requêtes :

  • les requêtes de type MX qui sont émises par les moteurs d’envoi de spams et de virus qui sont lancés sur les postes une fois compromis. De même, ces requêtes servent à ces codes malicieux pour se propager via email. Ce type de requête fournit le nom et l’adresse IP du(des) serveur(s) SMTP réceptionnant pour le domaine passé en paramètre ;
  • les requêtes de type A représentent la majeure partie des requêtes restantes. Ces requêtes peuvent alors correspondre à des demandes de résolution de noms de futures cibles, de serveurs de téléchargement de nouveaux codes malicieux (ou de mises à jour) ou encore de sites fournissant des ordres aux codes malicieux(serveurs IRC par exemple) .
  • Pour les requêtes MX, on peut en avoir la trace pas plus loin que dans sa messagerie. Exemple d’entête de spam dans la BAL de votre serviteur :
[...]
Received: from 200.253.154.11 (HELO data-app.com) (200.253.154.11) by mrelay5-1.free.fr with SMTP;
14 Dec 2006 19:44:31 -0000
Message-ID: <01c71fb7$588313d0$0200a8c0@servidor>
Reply-To: "Kalpana Lo"
From: "Kalpana Lo"
To: "Charles Chickering"
Subject: Re: [...]

On y voit un mail émis directement depuis un poste sur l’Internet vers le serveur MX de l’hébergeur de ma BAL. Cette émission a donc fait l’objet d’une demande de résolution MX pour le domaine free.fr sur le serveur DNS du poste internet.

5. Exploitation des logs DNS

5.1 Extraction des données

#egrep -v -i "@IP1|@IP2" /var/log/queries.1og | egrep -v -i mondomaine.fr 

La ligne de commandes précédente permet : * d’isoler l’ensemble des requêtes émises par les postes de travail (premier grep) ; * demandant une requête sur un domaine différent du domaine de l’entreprise ici nommé mondomaine.fr (second grep). Les données produites par cette commande correspondent à une liste d’adresses IP ayant un comportement DNS anormal selon les critères décrit dans le chapitre 4 :

[...]
22-Jan-2007 22:55:24.978 queries: client 192.168.0.190#32788: query: google.fr IN A +
22-Jan-2007 22:55:49.228 queries: client 192.168.0.190#32788: query: hotmail.com IN MX + %%%
[...]

On voit dans l’exemple ci-dessus un poste interne d’adresse IP 192.168.0.190 demander au DNS l’adresse IP de google.fr ainsi que celle du serveur SMTP gérant le domaine hotmail.com. Or, ces deux requêtes ne devraient jamais être émises par un poste du LAN car elles portent sur un domaine différent de celui de l’entreprise. En effet, ces deux requêtes DNS devraient avoir été émises respectivement par le proxy HTTP et par le relais de messagerie de l’entreprise. Ces deux machines ayant auparavant demandé son habilitation HTTP ou l’utilisateur de messagerie à l’utilisateur du poste.

NB : On peut bien entendu spécialiser cette ligne de commandes pour obtenir soit les requêtes de type MX soit les requêtes de type A.

5.2 Faux positifs ?

Explications et actions correctrices Nous avons décrit dans le chapitre 2 un pré-requis ambitieux qui était que toutes les communications ou tentatives de communication vers Internet émises par les postes de travail passaient par un proxy ou une machine relais. Or, la première analyse que vous allez mener sur les données extraites des logs de votre serveur DNS risque fort de plus vous mettre sur la trace de postes lançant des Windows Update que sur celle de postes zombies (du moins je l’espère pour votre LAN 😉 ). Vos premières actions vont donc être de travailler sur ces mécanismes légitimes s’exécutant sur vos postes et émettant des requêtes vers l’Internet : * de forcer le passage par proxy des actions qui le peuvent ; * d’inactiver les mécanismes s’exécutant mais finalement ne le devant pas ; * de noter les mécanismes devant absolument exécuter des connexions externes directes afin de les exclure des remontées des logs DNS. Notez bien que ce type de connexion devrait être rarissime car étant anormales en termes de politique de sécurité.

5.3 Gestion des alarmes

La liste des adresses IP ainsi remontées par la scrutation du fichier queries.log permet aux administrateurs des postes et au responsable sécurité de déclencher les actions appropriées. Parmi elles, on peut lister les quelques actions suivantes : * mise hors réseau du poste incriminé ; * recherche du code malicieux ; * recherche de l’explication de la compromission : manque de suivi des mises à jour antivirales, mise en ligne du poste directement sur le net (ex: à domicile), contournement de la politique de sécurité etc ; * remasterisation du poste avec restauration des données sauvegardées à une date antérieure à la compromission si la date est identifiée ;

6. Limites et pistes d’améliorations

6.1 Limites

Le processus de recherche de postes compromis que nous venons de décrire possède des limites liées au fait que nous travaillons sur le serveur DNS. Les limites majeures viennent du fait que l’on suppose que le code malicieux n’utilisera pas de données d’authentification dérobées à l’utilisateur du poste. Ainsi, l’émission de mails en SMTP authentifié à travers le relais SMTP de l’entreprise. Idem pour l’utilisation du proxy HTTP de l’entreprise pour attaquer un site extérieur ou récupérer des ordres d’un serveur de synchronisation. La remarque que l’on peut faire est que la majorité des codes malicieux sont conçus pour travailler sur des architectures ouvertes (DNS/SMTP/HTTP ouverts vers l’extérieur).

6.2 Pistes d’amélioration

Elles sont de deux ordres : exploitabilité de la solution et consolidation des données DNS avec les tentatives d’accès direct à l’extérieur par adresses IP. L’exploitabilité de cette solution serait de travailler sur l’enchainement des opérations de recherche dans les fichiers de logs, cyclage, compression et suppression de ces fichiers. Pour ce qui est de la consolidation, il faudrait déclencher de telles recherches sur les rejets du Firewall concernant des requêtes en provenance de postes en plan d’adressage interne (ex: 10.0.0.0/8) à destination d’adresses externes (vers l’internet donc).

7. Conclusion

Comme nous venons de le voir, une architecture qui permet de bien maîtriser les flux de données couplée à une analyse des logs de son (ses) serveur(s) DNS permet de disposer d’une sonde de détection de postes compromis. Cette solution a l’avantage d’être légère, non structurante et … ne coûte rien ! Cela n’empêche en aucun cas le RSSI ou le DSI de doter l’entreprise de solutions plus complète (et complexe), intrusive et chère.

[Article MISC] reverse proxy Apache 2.2 ou l’intérêt d’un équipement en coupure

Juste un petit mot pour rappeler que le MISC de Janvier/Février 2008 est sorti avec un petit article de votre serviteur dedans.

L’objet ? une présentation de l’intérêt d’avoir un reverse proxy (ici Apache 2.2) pour mettre en ligne sur Internet une application de type boite noire pour ses collaborateurs ou partenaires.

Pourquoi un reverse proxy ?

  • capacité à maîtriser la mise en ligne sans toucher au code (réécriture HTTP cookies compris, réécriture HTML)
  • capacité à ajouter des fonctionnalités sans toucher au serveur applicatif : https, authentification et habilitation LDAP par exemple
  • capacité à bloquer certaines attaques toujours sans toucher au code (puisque vous ne l’avez pas car c’est une boite noire) Cela vaut la peine d’y réfléchir finalement, non 😉 ?

PS : pourquoi Apache ? parce que c’est libre, parce que c’est efficace en diable et parce que c’est super documenté. What else ? 😉

[Article MISC] Mon serveur DNS, mon IDS oublié ;-)

Le numéro de Mai/Juin 2007 de MISC publie un article de votre serviteur sur l’utilisation d’un serveur DNS d’entreprise en tant que sonde de détections d’intrusion. Enjoy !

Le numéro de Mai/Juin 2007 de MISC publie un article de votre serviteur sur l’utilisation d’un serveur DNS d’entreprise en tant que sonde de détections d’intrusion. Enjoy !

Le numéro de Mai/Juin 2007 de MISC est sorti 🙂

Au milieu d’articles pointus sur la sécurité de la VOIP (par exemple), vous pourrez y lire un article écrit par mes soins, bien moins expert certes que ses congénères mais pouvant peut-être vous aider dans votre lutte quotidienne contre les intrusions au sein de votre LAN chéri 😉

L’idée : utiliser votre serveur DNS en tant que sonde de détection d’intrusion (aka IDS).

Les prérequis :

  • avoir une architecture DNS répondant aux critères de sécurité décrits dans un autre post de ce blog
  • avoir une interconnexion avec l’internet ENTIEREMENT basée sur des proxies (HTTP notamment) ou des relais (SMTP, DNS).

La mise en oeuvre :

  • sur le serveur BIND, rendre actif le log des requêtes reçues par le serveur,
  • au sein de ces requêtes, identifier toutes les adresses IP n’étant PAS celles des serveurs relais ou proxies. Vous avez avec cette liste d’adresses IP une liste potentielle des postes infectés (ou mal configurés 🙂 ).

Le reste c ‘est chez votre libraire préféré 😉 !

[Article MISC] De la sécurité d’une architecture DNS d’entreprise

Cet article est issu de l’article publié dans le numéro 23 de MISC. Ses auteurs sont Christophe Brocas (christophe.brocas@free.fr) et Jean-Michel Farin (jeanmichel.farin@free.fr). Tous droits réservés à MISC.

Ces dix dernières années, les entreprises ont vu une interconnexion toujours croissante de leurs systèmes d’informations (SI), entre eux ainsi qu’avec l’internet. Cette interconnexion s’est accompagnée d’une adoption massive de protocoles standards. Parmi ces protocoles, le DNS (Domain Name Service) affiche la double caractéristique d’être le plus systématiquement utilisé et sûrement le moins correctement surveillé.

Cet article est issu de l’article publié dans le numéro 23 de MISC. Ses auteurs sont Christophe Brocas (christophe.brocas@free.fr) et Jean-Michel Farin (jeanmichel.farin@free.fr). Tous droits réservés à MISC.

Ces dix dernières années, les entreprises ont vu une interconnexion toujours croissante de leurs systèmes d’informations (SI), entre eux ainsi qu’avec l’internet. Cette interconnexion s’est accompagnée d’une adoption massive de protocoles standards. Parmi ces protocoles, le DNS (Domain Name Service) affiche la double caractéristique d’être le plus systématiquement utilisé et sûrement le moins correctement surveillé.

Continuer la lecture de « [Article MISC] De la sécurité d’une architecture DNS d’entreprise »

Article MISC sur une architecture d’entreprise DNS sécurisée

Et ben voilà, le ch’tit teasing est achevé par la grâce d’un billet matinal chez MISC.

Jean-Michel Farin et votre serviteur avont en effet commis un article sur la mise en place d’une architecture d’entreprise DNS sécurisée. L’objectif était de fournir des choix d’architecture plus qu’un HOW-TO Bind bien que les fichiers de confs soient disponibles.

Cet article a été proposé à Frédéric Raynal suite à son édito du mois de Juillet (MISC 21) concernant la recherche de nouveaux rédacteurs. En espérant que cet article vous sera profitable tant de manière personnelle qu’au sein votre environnement professionnel 🙂

PS : bon, c’est sûr, à côté de gars qui contribuent à un bouquin comme celui-ci, cela fait un peu pauvre. Mais, on fait ce que l’on peut ma bonne dame 😉