Forums d'entraide informatique - Astuces - Conseils

Ces dix dernières années, les entreprises ont vu une interconnexion toujours croissante de leurs systèmes d'information (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é.
1. Introduction
Le DNS est souvent vu comme un protocole utilitaire au fonctionnement opaque. Et à la vue de son caractère primordial pour le bon fonctionnement des protocoles applicatifs tels SMTP ou HTTP, les portes de ce protocole sont souvent laissées grandes ouvertes tout au long de la chaîne de liaison du SI (postes, serveurs, routeurs, etc.).
Nous verrons dans cet article comment sécuriser ce protocole et en particulier son implémentation dans un réseau d'entreprise. Les exemples de configuration reposeront sur le logiciel Bind, version 9.I.x et suivantes [BIND].
1.1 Terminologie
Avant de plonger dans le DNS, accordons-nous sur les termes utilisés dans ce document :
Resolver : logiciel client DNS sollicité par les applications sur les postes clients afin d'obtenir une résolution ;
MM Serveur cache : serveur sollicité par les resolvers ou par d'autres serveurs cache. Ce type de serveur assure la fonction de récupération d'informations auprès de serveurs de noms ou d'autres serveurs cache. Il stocke les informations collectées dans son cache. Ce serveur ne gérant aucune zone DNS, le type de recherche supportée est récursif ;
/111 Serveur SOA : serveur de noms faisant autorité répondant aux requêtes pour une (ou plusieurs) zone(s). Ce serveur n'ayant pour mission que de répondre à des requêtes sur un ou plusieurs domaines, dans notre configuration, nous n'autorisons aucune récursion.
1.2 Les vulnérabilités DNS
À présent, regardons les différents types de menaces pouvant toucher le DNS :
La fuite d'informations via des canaux cachés ;
MI La corruption de résolution DNS permettant d'abuser les utilisateurs du système, d'informations et de leur dérober des informations sensibles ;
Le déni de services par l'acceptation de requêtes illégales ou par corruption de données dans les zones hébergées par les serveurs DNS internes.
La fuite d'informations
La fuite d'informations par tunnel DNS a été couverte de manière complète dans les pages de MISC ITUNI Les contre-mesures pour lutter contre ce type d'évasion se concentreront autour de la politique d'accès au service DNS ainsi qu'aux requêtes autorisées en fonction du type de client. La mise en oeuvre de cette politique sera décrite dans le paragraphe « Configuration du serveur DNS cache interne ».
Corruption de résolution
Ce type d'attaque a pour but de corrompre les données DNS fournies au client afin de, par exemple, le diriger à son insu vers des sites différents de ceux visés. Et ainsi, de lui dérober tout type d'informations sensibles.
Ce type d'attaque peut être réalisé par : MI Compromission du processus de résolution ;
MM Modification du trafic DNS ;
MM Ou compromission des données dans le cache d'un serveur de noms.
Les réponses que cet article amènera viseront à :
MI Sécuriser le processus de résolution et en maîtriser les possibilités de modification ;
Il/Limiter au strict minimum l'usage des requêtes récursives ;
an S'assurer de l'intégrité des transactions.
Le déni de services
Le déni de services distribué est une menace commune à tous les protocoles TCP/IP implémentés sur les serveurs accessibles de l'internet.
En dehors des mesures de protection réseau (IPS) ou de répartition de charges, peu de réponses spécifiques à la configuration DNS peuvent être appliquées. Cependant, les mesures suivantes permettent de limiter l'impact et l'implication des serveurs DNS dans ces attaques :
Restriction des transferts de zone ;
MI Interdiction de toute récursion ;
-1/Contrôle des requêtes simples ;
Al Restriction des notifications.

2. Architecture
Les règles du jeu
Pour maîtriser au mieux le DNS et son utilisation, nous fixons les règles suivantes
Aucune machine du réseau interne ne peut accéder à l'internet. Elles utilisent toutes un proxy I-ITTP pour le web ou un relais SMTP pour la messagerie
MI Aucune machine ne peut donc résoudre autre chose que le domaine morldornai ne.tr.
Cela permet d'être sûr de pouvoir déployer une politique de sécurité maîtrisable.
2.1 Les serveurs DNS et leur rôle
La base pour fixer une politique de résolution est donc de définir un périmètre et des règles d'accès :
Illa Un serveur DNS cache interne assure la résolution de tout
type de requête issue d'une machine du réseau interne.
Un serveur DNS SOA assure la gestion du domaine de l'entreprise pour le réseau interne de l'entreprise. Ce serveur ne peut être sollicité que par le serveur de résolution.
Un serveur DNS cache en DMZ assure la résolution des requêtes sur les noms internet issues du serveur DNS cache interne.
IBM Un serveur DNS SOA externe assure la gestion du domaine de l'entreprise pour les machines de l'internet. Ce serveur sera sollicitable par toute machine sur l'internet.
Fig. I : Architecture générale
2.2 Résolution d'une requête interne du domaine ou d'un sous-domaine de l'entreprise
Tout d'abord, le resolver envoie sa requête au serveur DNS référencé dans sa configuration. Ce serveur est un DNS cache qui vérifie que le resolver est habilité à demander des résolutions pour le domaine ou sous-domaine demandé via la mise en place d'ACL sur adresses IP (directive aci) et de vues (directive view). Le DNS cache ne contient aucune zone, mais sait trouver le serveur maître de la zone interrogée (directive forwar der s). Nous utilisons les fonctionnalités de retransmission sélective pour ce type de résolution (définition de zones de type forward et non maître ou esclave). Afin de préserver les serveurs maîtres au mieux des attaques, ceux-ci sont placés dans des DMZ et seuls les serveurs cache sont autorisés à y accéder.
2.3 Résolution d'une requête interne d'un domaine Internet
Le resolver interroge le serveur cache référencé. Le serveur cache vérifie que le resolver est habilité à résoudre les domaines inconnus (donc Internet). Le domaine interrogé n'étant pas connu par le serveur cache comme zone faisant l'objet d'une retransmission sélective, le serveur cache retransmet la requête au serveur cache délégué aux résolutions externes que nous avons pris soin de positionner dans une DMZ. Ici aussi, seuls les serveurs cache sont autorisés à y accéder. En cas d'attaque (via une hypothétique mauvaise implémentation du contrôle d'état UDP sur notre pare-feu par exemple !), l'attaquant n'accédera qu'a un serveur en DMZ uniquement capable de résoudre des requêtes vers Internet.
2.4 Résolution d'une requête externe du domaine de l'entreprise
Dans ce cas, les requêtes proviennent d'Internet vers un serveur que nous hébergeons. Bien entendu ce serveur est en DMZ. Étant donné le peu de sûreté que constitue Internet, il ne nous semble pas utile de mettre en place des habilitations pour les résolutions.
Nous restreignons les données de notre domaine au strict minimum pour Internet. Le resolver trouve alors sa réponse dans le DNS que nous lui proposons, la requête ne doit jamais entrer dans l'entreprise.
3. Serveur DNS cache interne 3.1 Attention au poste de travail!
Comme nous le disions en introduction, la corruption de données de résolution est le problème majeur du DNS. Et

En effet, la résolution de noms dans les systèmes d'exploitation modernes implique des composants autres que les serveurs DNS.
Par exemple, sous un système Microsoft Windows, le processus de résolution suit les étapes suivantes
MM Vérification si on demande la résolution du propre nom de la machine ;
IM Présence du nom dans le fichier Mosts (%Systemroot%\ System32\0rives\Etc\hosts3
▪    DNS;
WINS ;
111M broadcast réseaux ;
LMHOSTS.
Ainsi, si vous modifiez le contenu du fichier ,iosts, la chaîne de résolution DNS est corrompue. Toute la politique de sécurité DNS est déjà réduite à néant !
Cette méthode est utilisée par exemple par les vers de la lignée MYTOB [VER] qui font ainsi pointer des sites de type symantec.com ou update.symantec.com vers 12 7.0.0.1 et empêcher ainsi toute mise à jour de l'antivirus.
La solution est donc de s'assurer que les utilisateurs n'ont pas les droits administrateur et donc ne peuvent exécuter de processus pouvant modifier le fichier hasts. Idem pour ce qui est de l'accès aux paramètres DNS.
3.2 Configuration du serveur DNS cache interne
Une fois que le poste client nous semble correctement configure, voyons la configuration du serveur de cache interne. Dans notre exemple, les machines du réseau interne sont dans le réseau 1 0.1,0.0/16 et le serveur cache interne à l'adresse 10.1.255,4.
                                           
        Les vues sous Bind - suite                                   
                                           
    Jeu de clients 1            Vue 1    de donne. db zone                       
                C ---.                           
                named.conf                           
                Fichiers                           
                virtuel                           
                                           
                Vue 2                           
    .•.        Jeu de                               
    ■        clients 2                               
            _—.                               
                C —1e.                           
                                           
    Démon            named.conf                           
    named.conf            Fichiers de données                           
    Nafned            virluel                           
    Reste du monde            db.zone                           
                Vue 3                           
                --p.                           
                named.conf            dit        de données       
                Fichiers            zone               
                virtuel                           
    Fig. 2 : Mécanisme des vues sous Sind répondant ici à trois types de clients                                       
                                           
Au chapitre 2, nous avons défini différents types de clients au sein du réseau interne (machines standards et machines passerelles). Ces différents types de clients vont se traduire par 2 ACL différentes
Tous les fichiers de configuration sont disponibles sur le site de MISC [MISC23].
// ENTETE DU FICHIER NAMEO.CONE du UNS CACHE INTERNE // Definition des différents types de clients
// les proxies
acl "passerelles" { 10.1.255.3/32; };
// les machines du reseau interne de l'entreprise acl "reseaulocal" { 10.1.0.0/16; };
// le Dg cache en DMZ
acl "drs-cache-internet" { 10.255.1.4/32; }; // le DM soa interne
acl "dns-soa'    10,255.2.4/32; };
// localisation des fichiers de configuration options { directory -/var/hamed":
version "unavailable"; };
À ces 2 types de clients vont correspondre 2 types de vues qui fourniront 2 types de résolution. Voici la vue fournie aux clients de type proxies ou passerelles.
1 I Suite du FICHIER HAHED.CONF du DNS CACHE INTERNE
// vue s'adressant aux proxies
view "passerelles" {
// machines à qui s'adressent cette eue. Ici les proxies de l'entreprise. match-clients { "passerelles"; };
// en cas de requête faite sur un domaine non géré par ce serveur, // envoi des requétes sur le UNS cache internet
forward only;
forwarders { 10.255.1.4; };
// requête sur le mondornaine.fr :
1/ redirection de la requête vers le UNS SOA

forwarders { 10.255.2.4;}; forward
// redirection identique pour les requetes sur la zone reverse zone 1.0.in-addr.arpz" {
type forward;
forwarders { 10,255.2.4; };
forward only;
Figure
Les passerelles peuvent effectuer tout type de requête. Ces requêtes seront satisfaites de la manière suivante
MI Requête sur le domaine simndomaine .f r : envoi d'une requête auprès du serveur maître interne (IP: 1 0 . 2 5 5. 2 .4)
Requête sur tout autre domaine : envoi vers le serveur cache en DMZ (adresse IP 1 . 2 5 5.1 .4).
Voici ensuite la vue pour les postes lambda du réseau local
// Fin du FICHIER nAMED.CIAF du DS CACHE IWTERNE
// vue s'adressant aux RE du réseau interne de 1 'entreprise vise i'reseaulocal" {
// Machines e qui s'adressent nette vue.
// Ici, les machines lambda PC) du réseau interne. match-clients { "reseaulocar; };
// requête sur le mondomaine.fr
il redirection de la requête vers le 11115 MA interne zone "mondorraine.fr'' {
type forward;
forwarders { 10,255,2.4; };
forward ony;
I;
// redirection identique pour les requêtes sur la zone reverse zone "10.1n-addr.arpe
type forward;
forwarders { 10.255.2.4; };
forward only;
NOTE
Les zones de type toi ib r,1 ont été introduites en version 9.I.x de Bind.
Cette configuration ne permet de résoudre que des noms dans le domaine man do rnaine.f r. Les autres noms de domaines ne sont résolus que pour les machines passerelles.
Cette mesure combinée à la fermeture de tous les ports réseau (comme HTTP/S ou SMTP) pour les machines du LAN au niveau du firewall empêche toute capacité d'évasion par tunnel DNS autonome. Pour que l'évasion soit désormais possible, il faut que l'attaquant dispose du code d'authentification de l'utilisateur sur le proxy applicatif ce qui limite grandement la menace des attaques automatisées. Et nous sortons là du périmètre de la sécurisation du DNS.
4. DNS SOA interne
4.1 Mise en sûreté des informations
Les informations contenues dans le DNS SOA interne font de ce DNS le cœur de notre système. En effet, il est le seul à contenir les données de résolution et doit à ce titre être le plus protégé. Ce DNS est placé derrière un pare-feu voire un IPS implémentant un contrôle d'état sur UDF performant. Des règles de sécurité sont mises en place pour n'autoriser que les DNS cache interne à interroger notre DNS SOA interne. Ces règles sont mises en place sur l'équipement de sécurité réseau et dans la configuration du DNS.
Ces restrictions limitent les risques de déni de services sur notre DNS SOA interne, le nombre de clients simultanés étant limité par le nombre de DNS cache.
4.2 Les mises à jour dynamiques
Certaines applications de l'entreprise peuvent nécessiter la mise en place des mises à jour dynamiques (serveur DHCP, contrôleur de domaine, etc.) sur notre DNS SOA. Dans ce cas, il est intéressant de créer des sous-domaines particuliers pour ces applications, celles-ci ne peuvent alors pas tout modifier dans notre DNS.
Par exemple, on peut créer le sous-domaine dhcp.niondomvine.fr sur notre DN5 et autoriser le serveur DHCP à y effectuer ses mises à jour sans lui donner de droits sur 'Rondo-ma ine. f r. L'option
update-policy permet de plus de limiter les opérations possibles

sur la zone. Ainsi, nous pouvons autoriser le serveur DHCP à ne modifier que les enregistrements de type A, garantissant ainsi l'impossibilité de modification de nos enregistrements de type NS par exemple.
L'utilisation de clef TSIG est également une sécurité à mettre en oeuvre autant que possible.
4.3 Création d'une clef pour mises à jour dynamiques
Nous commençons par mettre en place des clefs TSIG pour les serveurs utilisant les mises à jour dynamiques et acceptant d'utiliser ce type de clefs. Nous générerons notre clef avec l'outil dnssec-keygen. Prenons par exemple la mise en place d'une clef pour notre serveur DHCP :
dnssec-keygen -a FINAC-MD5 -h 512 -n SOIT dhcp.mondomaine.fr
Explication des options :
/1. L'option -a permet de choisir l'algorithme utilisé par la clef
(ici MMAC-1105).
Iffl L'option -`2 est la longueur de la clef (ici 512 bits).
L'option    spécifie le type de clef créé (dans notre cas, il
s'agit d'une clef de type HOST).
.11 Le dernier paramètre est le nom de la clef.
Nous obtenons deux fichiers du type Kdhcp.fflordomaine. fr.+157+55315.key et Kehcp.inondarnaine.fr.+157+55315.private contenant chacun la clef. En effet, dans notre cas, ces deux fichiers sont identiques. Les noms de ces fichiers sont toujours formés par la lettre K majuscule, suivie du nom de la clef, puis de l'identifiant de l'algorithme utilisé et un identifiant.
Le fichier en .key contient notre clef sous la forme :
dhcp.reondcraine.fr. IN KEY 512 3 157 S5m+161iLtk6Y7-vnKi-8jpiilf112AHLxN8SqVeZqzxi}y g+1_1187PbT5w0 pteHcN4Ndw059t2TYtkpsbUocilv1+g.a
et le fichier .pri vate contient cette même clef mais sous la forme :
Private-key-format: v1.2
Algorithm: 157 {1111AC_MD5)
Key: S511+161iLtk6Y7+nK+8jpV1f112AillyN8SeelqzxDyg+L1187PbT5wOoteilcidildw059t2TY UpsbUocilvli-g==
Pour nos besoins, nous créons un nouveau fichier ne contenant que la clef. Ce fichier s'appelle cl efdhcp key et contient :
secret lS5ranliiiiLtk6Y1+nKtajpVifil2AHLoN8SqVeZquQyg+1.1187P6I5w0ptehtili4Ndw059t2 PlikpsbUochly1+g=";
4.4 Configuration
Nous filtrons les adresses IP source via l'option al 1 olv -d ue ry.
acl "dns-cache-interne" { 10.1.255.4/32; }: acl "updateservers" { 10.1.255.7/32; };
options (
// Répertoire çà se trouvent les fichiers de zone directory "har/named";
// Modification du nom de version renvoyé version "unavailable";
// Interdiction des transferts de zone allow-transfer{"none";};
// Interdiction des notifications de mise à jour
allow-notify {none;};
r/ Autorisations de requêtes internes et pour le UNS cache allow-query (127.0.0.1; "dns-cache-interne";"updateservers';};
// Pas de récursion recorsion no;
/1 Définition de la clef du serveur DHCP key "key.dhcp.rmondomaine.fr" {
algorithm hmac-ric15;
include "clefdhcp.key";
1;
// Définition de la sous-zone maitre dhcp zone "dhcp,mondomaine.fr" {
type master;
file "db.dhcp.mondorvaine.fr";
// Définition des droits de mise à jour (type A pour le serveur utilisant la clef dhcp)
update-policy {
Brant key.dhcp.mondomaine.fr nase dhcp.mondomaine.fr A ;
1;
forwarders {};
1/ Définition de la zone maitre zone "mondomaine.fr"
type master;
fiie "db.undomaine.fr ; forwarders {};
5. Serveur DNS cache en DMZ
Ce serveur a pour vocation d'effectuer pour le compte du serveur DNS cache interne les résolutions de noms de domaines internet. Cette particularité nous permet de restreindre les clients pouvant le solliciter à ce seul serveur.
NOTE
Si vous utilisez une version de Bind inférieure à 9.x, il faut prendre soin de se prémunir de 2 risques majeurs de corruption de caches :
grJ.E Le glue fetching qui consiste pour un serveur, recevant un enregistrement NS sans enregistrement de type A, à chercher à obtenir cet enregistrement A entraînant des risques de corruption du cache.
La prédiction du numéro de l'ID du message DNS [HEADER] qui rend le serveur sensible aux attaques de force brute.
Voici la configuration du serveur :
définition d'une ACL pointant le DOS cache interne acl 'dns-cache-interne" { 10,255,1.4/32; };
options {
// répertoire contenant les fichiers de configuration directory "/var/named";
I/ aucun transfert de zone autorisé
allow-transfer{"none";};
// seul le dns cache interne est autorisé à allow-query ( "dns-cache-interne'; };

II pour BIND 8: randomisation de l'ID de message CAS //use-id-pool yes;
Il pour Bind 8: pas de glue fetching
//fetch-glue no;
// Définition de la zone racine
fi Elle contient la liste des serveurs racines à qui le serveur va s'adresser Il pour commencer à résoudre les requêtes.
zone
type tint;
file "/var/named/named.root";
6. Serveur DNS SOA externe
Le serveur DNS Internet est celui le plus exposé en considérant le danger extérieur (nous ne reviendrons pas sur ce vaste sujet...). Il est donc important de bien lui appliquer les règles de sécurité appliquées à tout serveur disponible sur Internet.
Au niveau de la configuration DNS, elle est très simple. Il suffit de créer une zone de type maître sur ce serveur et d'interdire toute récursion.
Il faut ensuite remplir la zone avec les données devant être disponibles sur Internet.
options {
// Répertoire où se trouvent les fichiers de zone directory "/var/named";
// Modification do nom de version renvoyé version "unavailable";
// Interdiction des transferts de zone allow-transfer{"none";
Il Interdiction des notifications de mise a jour allow-notify (none;);
// Autorisations de requêtes allow-query (any;);
// Pas de récursion recursion no;
// Définition de la zone maître zone "mondomaine.fr" (
type master;
file "db.mondomaine.fr*; forwarders {};
NOTE    eeeeeleee ,
Nous pouvons fusionner physiquement les 2 serveurs DNS Internet (le cache et le serveur DNS internet). La configuration utiliserait alors le principe des vues en fonction de l'adresse appelante comme nous l'avons vu au chapitre 3 pour la configuration du DNS cache interne.
7. Les logs
Par défaut, le démon narned envoie tous ses messages au syslog de la machine qui peut aussi recevoir les messages des autres démons du système. Le manque de lisibilité d'un tel syslog nuit directement à la sécurité du DNS en gênant sa supervision.
Heureusement, il est possible de configurer les logs de named via des canaux de legs afin de, dans notre cas, rediriger certains types de messages dans des fichiers spécifiques. named peut utiliser plusieurs canaux de logo en parallèle traitant les mêmes informations ou non. Dans notre exemple, nous utilisons deux canaux de logs, un premier pour les messages concernant les problèmes de sécurité et les transferts de zone et un second pour les autres messages et les transferts de zone (messages par défaut).
Ces lignes de configuration sont à placer dans les fichiers /etcf riamoti.(onf de tous les DNS.
logging {
I/ Paramétrage du canai des messages de sécurité
channel securitylogs {
// Envoi vers le fichier dns_security.log avec roulement de lê archives de 5110 file "/var/log/named-sec.log" versions 18 size 5m;
// Affichage de tous les messages (+messages debug si activation du mode

sonorité dynarnic;
// Affiche le nom de la catégorie du message
print-category yes;
// Affiche la sévérité du message dans les logs
print-severity yes;
!/ Affiche la date du message dans les logs
print-time yes:
1)
// Paramétrage du canal par défaut
channel defaultlogs {
// Envoi vers le fichier dns_default.log avec roulement de 10 archives de 51ilo file "/var/log/namod-default.lor versions 10 size 5m;
// Affiche les messages de sévérité "info' et supérieur
severity info;
// Affiche le nom de la catégorie du message
print-category yes;
// Affiche la sévérité du message dans les logs
print-severity yes;
// Affiche la date du message dans les logs
print-time yes;
1)
// Envoi des messages par défaut à notre canal defaultlogs category default { defaultlogs; };
Il Envoi des messages de transferts a nos canaux defaultlogs et securitylogs
category xfer-in    securitylogs; defaultlogs; 1;
category xfer-out    securitylogs; defaultlogs; };
// Envoi des messages de sécurité à notre canal securitylogs category security ( securitylogs; );
);
Il est également possible de créer un canal spécial pour les mises à jour dynamiques sur les serveurs utilisant ce service :
Carmel upaatecgs {
file "/var/log/named-update.log" versions lg size 5m;
severity dynamic; print-category yes; print-severity yes; print-time yes;
};
category update t updatelogs: };
Voici deux exemples de messages lus dans le fichier de logs de sécurité :
tiou 25 1B:34:51.41P security: info: client 192.168.9.9#1319: query (cache) denied goy 25 15:22:53.39B security: error: client 192.168.9.9#32776: zone transfer 'mondomaine.fr/IN' denied
Ces deux messages ont les significations suivantes : MM Le premier est une interdiction d'interrogation.
1ffl Le second est une interdiction de transfert de zone.
8. Conclusion
Comme nous avons pu le voir, la sécurisation du DNS passe avant tout par le fait de se poser les bonnes questions sur son utilisation. Qui l'utilise ? Pour quels types de résolution ? Est-ce légitime
La réponse à ces questions sous l'angle de la sécurité nous a permis d'arriver aux solutions suivantes :
Une séparation des différents services DNS (résolution internet vs résolution du domaine interne) par spécialisation des serveurs ;
Une politique centralisée et maîtrisée d'accès à l'internet limitant le spectre de clients pouvant solliciter et donc potentiellement exploiter le DNS.
Une amélioration supplémentaire pourrait être l'utilisation de DNSSEC [DNSSEC] pour le contrôle d'intégrité et l'authentification des demandes de résolutions de noms et les réponses associées. Cette utilisation serait à implémenter au niveau du DNS SOA internet.
L'ensemble de cette architecture a bien entendu un coût par rapport à un DNS non maîtrisé (postes ouverts sur l'internet, etc.). Ce coût doit être identifié et prévu tant sur le plan financier, organisationnel que humain. En effet, la sécurisation du composant DNS au sein du SI ne pourra être menée à bien sans cette étude d'impact. Et nous espérons que cet article vous aidera à calibrer vos besoins par rapport à votre environnement.