Modifications entre les versions 3 et 7 (s'étendant sur 4 versions)
Version 3 à la date du 2007-09-24 19:13:20
Taille: 4050
Commentaire: mmmhhh à revérifier pour voir si ça fonctionne réellement :)
Version 7 à la date du 2012-01-30 08:49:53
Taille: 5038
Commentaire:
Texte supprimé. Texte ajouté.
Ligne 12: Ligne 12:
Cependant il est fortement recommandé (voir obligatoire !) de [:/Sécurisation:sécuriser le service DNS]. Cependant il est fortement recommandé (voir obligatoire !) de [[/Sécurisation|sécuriser le service DNS]].
Ligne 26: Ligne 26:
== view/resursion == == view/recursion ==
Ligne 28: Ligne 28:
Il y a peu, en testant des outils en ligne de vérification de DNS, j'ai remarqué une erreur importante dans mon DNS, j'étais en "Open Server". Autrement dit, n'importe qui, dans le monde, peut utiliser mon DNS pour effectuer des requêtes autre que demander des informations sur mon réseau interne. Au passage, on peut utiliser cette propriété pour fournir de mauvaises informations au cache de Bind. Une documentation était fournit pour éviter d'être en "Open Server" : [http://www.cymru.com/Documents/secure-bind-template.html].
Le livre de Bind fournit aussi une bonne documentation : [http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html]
Il y a peu, en testant des outils en ligne de vérification de DNS, j'ai remarqué une erreur importante dans mon DNS, j'étais en "Open Server". Autrement dit, n'importe qui, dans le monde, peut utiliser mon DNS pour effectuer des requêtes autre que demander des informations sur mon réseau interne. Au passage, on peut utiliser cette propriété pour fournir de mauvaises informations au cache de Bind. Une documentation était fournit pour éviter d'être en "Open Server" : [[http://www.cymru.com/Documents/secure-bind-template.html]].
Le livre de Bind fournit aussi une bonne documentation : [[http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html]]
Ligne 70: Ligne 70:
== DNSSEC ==
La gestion des noms de domaines est sujette à de nombreux types d'attaques informatiques. A la base, ces attaques consiste à transmettre aux serveurs "slave" ou aux "resolvers" des informations erronées afin de détourner le trafic destiné aux sites cibles de l'attaque.

Afin d'éviter ce problème, une serie de RFC ont permis l'extension du protocole DNS, lui permettant de supporter un certain nom d'opération cryptographique dans le but de:
 * Garantir l' '''authenticité''' des parties impliqués dans des échanges de messages/transactions DNS;
 * Garantir l' '''intégrité''' des données échangées lors de ces transactions ou échanges de messages DNS;
 * Assurer la preuve de non existence lorsqu'une requête aboutie à une réponse de type NXDOMAIN pour une entité.

A l'AUF, DNSSEC pourrait nous intéresser à plus d'un titre. D'abord pour sécuriser nos DNS, mais aussi il pourrait nous servir pour ''publier'' les certificats
Ligne 74: Ligne 83:
 * le site de BIND : http://www.isc.org/sw/bind/  * le site de BIND : http://www.isc.org/software/bind/ 
Ligne 79: Ligne 88:
CatégorieEbauche ["CatégorieRecommandationDRI"] CatégorieEbauche [[CatégorieRecommandationsARI]]

Pour mettre en place un service DNS, le logiciel recommandé à l'AUF est BIND version 9. Le paquet Debian correspondant est bind9.

/!\ Cette page a été écrite à toute vitesssssse, merci aux DNSmen de la ré-écrire un peu plus proprement et plus en détail.

Installation

L'installation du service se fait simplement avec :

# aptitude install bind9

Cependant il est fortement recommandé (voir obligatoire !) de sécuriser le service DNS.

{i} Le nom du logiciel effectuant le service DNS (et donc du processus) est named, tandis que BIND (Berkeley Internet Name Daemon) est le nom du projet.

/!\ Veillez à bien installer bind9 (avec un 9 à la fin). Le paquet bind fournit quant à lui la version 8.x de BIND, ce qui n'est pas la même chose !

Configuration

  • Ajouter une zone : créer le fichier /etc/bind/db.nom.de.la.zone puis référencer la zone dans /etc/bind/named.conf.local

Quand une zone est ajoutée ou mise à jour, lancez invoke-rc.d bind9 reload ou encore rndc reload.

{i} L'outil rndc (remote name daemon control) permet d'être plus fin dans les ordres envoyés à named, voir man rndc.

view/recursion

Il y a peu, en testant des outils en ligne de vérification de DNS, j'ai remarqué une erreur importante dans mon DNS, j'étais en "Open Server". Autrement dit, n'importe qui, dans le monde, peut utiliser mon DNS pour effectuer des requêtes autre que demander des informations sur mon réseau interne. Au passage, on peut utiliser cette propriété pour fournir de mauvaises informations au cache de Bind. Une documentation était fournit pour éviter d'être en "Open Server" : http://www.cymru.com/Documents/secure-bind-template.html. Le livre de Bind fournit aussi une bonne documentation : http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html

  • Les "view" servent a présenter différentes visions de notre réseau, suivant la "personne" qui interroge notre serveur DNS. Par exemple, vous pouvez vouloir réserver certaines machines d'une partie de votre réseau à un usage interne et donc qu'elles ne soient pas visibles de l'extérieur, ou bien vouloir que votre réseau FOAD puissent voir une machine qui ne doit pas être vu de votre réseau grand publique.
  • L'option "recursion", qui porte la valeur yes/no, autorise ou non votre serveur DNS à interroger les autres serveurs DNS. Ce qui fait qu'on est "Open Server" ou non.

De manière basique, on peut donc créer une vue "interne" pour notre réseau, notre dmz, notre vpn, etc... qui autorise les requête récursives, et une vue "externe" qui n'autorise pas ce genre de requête.

// fichier /etc/bind/named.conf.local

acl "rezointerne" {
   192.168.1.0/24; // notre réseau interne
   10.XX.0.0/24; // notre rpv
   XX.XX.XX.XX/28; // notre plage d'adresse publique
};

view "interne" {
   match-clients { rezointerne; };
   recursion yes;

   zone "refer.ga" {
        type master;
        file "/etc/bind/local/interne.refer.ga.hosts";
   };
};

view "externe" {
   match-clients { any; };
   recursion no;

   zone "refer.ga" {
        type master;
        file "/etc/bind/local/externe.refer.ga.hosts";
   }; 
};
  • Il est possible que le fichier soit le même, mais il est aussi possible d'avoir deux fichiers différents.

/!\ toutes vos zones doivent être définit dans toutes les vues (pour si vous en avez plus de 2). Donc si vous avez 2 vues, mais 15 zones, par exemple, vous pouvez intégrer vos zones dans un fichier à part utiliser un include pour que ce soit plus lisible.

DNSSEC

La gestion des noms de domaines est sujette à de nombreux types d'attaques informatiques. A la base, ces attaques consiste à transmettre aux serveurs "slave" ou aux "resolvers" des informations erronées afin de détourner le trafic destiné aux sites cibles de l'attaque.

Afin d'éviter ce problème, une serie de RFC ont permis l'extension du protocole DNS, lui permettant de supporter un certain nom d'opération cryptographique dans le but de:

  • Garantir l' authenticité des parties impliqués dans des échanges de messages/transactions DNS;

  • Garantir l' intégrité des données échangées lors de ces transactions ou échanges de messages DNS;

  • Assurer la preuve de non existence lorsqu'une requête aboutie à une réponse de type NXDOMAIN pour une entité.

A l'AUF, DNSSEC pourrait nous intéresser à plus d'un titre. D'abord pour sécuriser nos DNS, mais aussi il pourrait nous servir pour publier les certificats

Pour aller plus loin

Quelques liens :


CatégorieEbauche CatégorieRecommandationsARI

DNS (dernière édition le 2012-01-30 08:49:53 par NacerAdamouSaidou)