Réseau et services pour la plateforme informatique : Différence entre versions

DNS Sécurité

Pourquoi DNS Sécurité

Il y a des attaques visant directement le DNS.Les atteintes aux infrastructures DNS sont essentiellement d’ordre technique, faisant appel à des stratégies d’attaques massives ou de corruption des informations échangées entre les ré-solveurs et les serveurs DNS.

Les principales techniques de sécurisation

Chaque acteur présent sur Internet est un maillon d’une chaîne de valeur où tous sont interdépendants. Les conseils suivants ne sont donc pas destinés à une catégorie d’acteurs en particulier mais à tous ceux qui participent du fonctionnement du DNS : gestionnaires de domaines de premier niveau (registre), bureaux d’enregistrement, entreprises, fournisseurs d’accès...

1.assurer la meilleure redondance possible, de manière à ce qu’un serveur affecté par une attaque puisse être remplacé en toute transparence par d’autres serveurs disposant des mêmes informations mais situés sur d’autres réseaux. C’est la raison pour laquelle les registres de noms de domaine, tel l’AFNIC, exigent toujours que chaque nom de domaine soit installé sur au moins deux serveurs de noms. D’autres techniques plus élaborées, comme le recours à des nuages anycast, permettent d’augmenter encore plus la redondance avec à la clé des gains notables en termes de sécurisation et de performances.

2.veiller à utiliser des versions à jour des logiciels DNS, notamment de BIND, corrigées par les « patchs » appropriés, afin de ne pas être vulnérable à des attaques portant sur des failles de sécurité déjà bien identifiées.

3.assurer une surveillance régulière de ses serveurs et de leur configuration, de préférence depuis plusieurs points de l’Internet. Il est souvent arrivé, en raison de la robustesse du DNS, que la panne de serveurs ne soit détectée que lorsque le dernier d’entre eux tombe en panne. Pour vérifier la configuration, il existe des logiciels libres comme ZoneCheck. Pour assurer la surveillance depuis l’extérieur, l’organisation qui ne souhaite pas déployer une infrastructure spécifique peut faire appel à des services commerciaux ou communautaires existants.

4.envisager de déployer DNSSEC, protocole de sécurisation du DNS par l’authentification des serveurs, ce système limitant notamment les attaques par empoisonnement. La perception de l’intérêt de DNSSEC a été fortement accrue par la révélation de la faille Kaminsky qui a montré comment exploiter efficacement des vulnérabilités déjà connues au plan théorique.

5.définir un « Plan de continuité d’activité » permettant à la victime d’une attaque de poursuivre, ou de reprendre en cas d’incident grave, ses activités avec un minimum d’indisponibilité de ses services. Cette précaution est particulièrement essentielle pour tous ceux qui dépendent d’Internet – et donc du DNS – pour leur chiffre d’affaires, notamment ceux qui proposent des services en ligne à leurs clients.

Semaine 2

Serveur DNS

Au départ j'ai réservé un nom de domaine plil.info pour associer un nom DNS à mon adresses IP 5.23.44.83 (les zones inverses doivent, elles aussi, être gérées). Il est suggéré d'utiliser le registrar Gandi (http://www.gandi.net). Une fois mon nom de domaine reservé, j'ai configuré bind (paquetage bind9) sur mon serveur virtuel Xen cong-dns pour donner les adresses correspondant à mon nom de réseau IP, au nom de mon interface de routeur, au nom de ma machine et au nom de l'adresse de diffusion de mon réseau IP. J'ai utilisé l'interface web de mon fournisseur pour paramétrer ma machine comme serveur DNS maître et une machine de mon fournisseur comme DNS esclave.

1.Fichier d'adresses

   $TTL 259200
   @ IN SOA ns.plil.info. postmaster.plil.info. (
        3      	  ; Version
        7200             ; Refresh (2h)
        3600             ; Retry   (1h)
        1209600          ; Expire (14j)
        259200 )         ; Minimum TTL (3j)
       IN NS ns.plil.info.
	IN NS ns6.gandi.net.
   www       IN A       5.23.44.83
   ns        IN A       5.23.44.83

2.Le DNS est maitre pour certaines zones

   zone "plil.info"{
     type master;
     file "/etc/bind/plil.info.signed";
   };

Sécurisation de serveur DNS par DNSSEC

Pour entrer dans les détails, il faut effectuer les opération suivantes.

1. Il faut ajouter l'option dnssec-enable yes; dans le fichier named.conf.options ;
2. Il faut créer un répertoire de nom plil.info.dnssec pour y générer les clefs ;
3. Il faut créer la clef asymétrique de signature de clefs de zone (pour accélérer la génération sur un système de test nous pouvons utiliser l'option -r /dev/urandom) ;

   dnssec-keygen -r /dev/urandom -a RSASHA1 -b 2048 -f KSK -n ZONE plil.info

4. Il faut créer la clef asymétrique de la zone pour signer les enregistrements (pour accélérer la génération sur un système de test nous pouvons utiliser l'option -r /dev/urandom) ;

   dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE plil.info

5. Il faut renommer les deux paires de clefs obtenues en utilisant le nom de la zone comme préfixe puis en suffixant d'abord par la destination de la clef (-ksk pour la KSK ou -zsk pour la ZSK) puis par le type de clef (.key pour la clef publique ou .private pour la clef privée) ; En conséquence, après tous ces étapes dans le répertoire plil.info.dnssec j'ai 5 fichiers:

5 fichiers dans le répertoire plil.info.dnssec
6. Il faut incluer les clefs publiques dans votre fichier de zone, incrémentez le numéro de version de la zone ;

    $include /etc/bind/plil.info.dnssec/plil.info-ksk.key
    $include /etc/bind/plil.info.dnssec/plil.info-zsk.key

7. Il faut signer les enregistrements de la zone ;

    dnssec-signzone -o plil.info -k plil.info-ksk ../plil.info plil.info-zsk

J'ai créé un autre nom de domaine congchen.fr ensuite j'ai refait toutes les étapes précédentes, donc dans mon répertoire bind j'ai des fichiers ci-dessous


Les fichiers dans le répertoire bind
8. Il faut aussi modifier le fichier named.conf.local pour utiliser la zone signée de suffixe .signed ;
9. il ne reste plus qu'à communiquer la partie publique de la KSK (présente dans le fichier plil.info-ksk.key) à votre registrar (par exemple gandi.net, regardez à "Manage DNSSEC" dans la section "DNS servers").

Une fois le "Manage DNSSEC" est fait, je pouvait visualiser la chaîne de DNSSEC pour plil.info et congchen.fr

• 

  Chaîne de DNSSEC pour plil.info

• 

  Chaîne de DNSSEC pour congchen.fr

Sécurisation par DNSSEC-Tools

Présentation de DNSSEC-Tools projet

Le projet DNSSEC -Tools est une open-source désigné pour rendre DNSSEC facile. DNSSEC -Tools est une suite de logiciels d'open-source et libre, contenant une grande variété d'outils et de bibliothèques. Son organisation modulaire et le code de source libre permettent de personnaliser et de construire des propres outils de chacun.

Le diagramme de DNSSEC-Tools

Le digramme de DNSSEC-Tools

Le DNSSEC-Tools a certains outils:

1. End user
2. Zone Administrators
3. Application Authors
4. Operational Debuggers
5. Authoritative Server Administrators
6. Recursive Server Administrators
7. Management Station Operators
8. Network Monitors

Procédure avec DNSSEC-Tools

Pour commencer, il faut d'abord installer le DNSSEC-Tools dans le PC.

 apt-get install DNSSEC-Tools

Ensuite je peux commencer à signer ma propre zone mais j'ai besoin d'un fichier pour ma domaine.

  $TTL 3600
  congchen.fr. 1000 IN SOA ns.congchen.fr. admin.congchen.fr.(

5  ; serial 7200  ; refresh(2 hours) 3600  ; retry(1 hour) 604800  ; expire(1 week) 600  ; minimum(10 minutes) ) 1000 NS ns.congchen.fr. 1000 NS ns6.gandi.net.

  ns      1000 IN A 5.23.44.83
  www     1000 IN A 5.23.44.83

Afin de signer le fichier de la zone,j'ai utilisé zonesigner. Pour la première fois, il faut ajouter -genkeys option pour dire au zonesigner que je veux générer une nouvelle clé pour la zone.

  zonesigner -genkeys congchen.fr
  

Génération de la clé

Dans le répertoire dnssec-tools, j'ai des fichiers .key et .private automatiquement

Le digramme de DNSSEC-Tools