Cyrille Giquello

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== DNS ======

===== sur l'Oueb =====

Pourquoi il ne faut pas utiliser bind : 
  * http://cr.yp.to/djbdns/blurb/unbind.html
  * http://cr.yp.to/djbdns/blurb/bindmoney.html
Pourquoi djbdns est plus secure que bind :
  * http://cr.yp.to/djbdns/blurb/security.html
De l'importance de séparer le cache des serveurs autoritaires :
  * http://cr.yp.to/djbdns/separation.html

Sur l'wiki Sos-Admin :
  * http://wiki.sos-admin.com/wiki/Cat%C3%A9gorie:DNS
  * http://wiki.sos-admin.com/wiki/Cat%C3%A9gorie:S%C3%A9curiser_DNS_bind

===== DNS =====

certains hackeurs utilisent recursivité pour lancer des attaques avec l'ip spoofée.

  acl recurseallow { XXX.YYY.ZZZ.AAA; 127.0.0.1; };
  options {
        directory "/var/named";
        allow-recursion { recurseallow; };
  };

J'ai regardé un petit peu plus loin le problème, utiliser allow-recursion pour limiter vos IP est pas trop mal et facile à mettre en place, mais ce n'est pas la panacée...  en effet, ceci empêchera les requêtes récursives (le fait que votre serveur interroge d'autres serveurs DNS externes lors de demandes provenant du net), mais cela n'empèchera pas d'interroger les informations se trouvant déjà dans le cache de Bind...  

Voici une autre solution un petit peu plus lourde à mettre en place mais plus efficace :

Dans chacune de vos zones (qui sont configurées dans /etc/named.conf en général), ajoutez le paramètre suivant : 

  allow-query { any; };

Ce paramètre va indiquer que n'importe qui peut effectuer une requète sur cette zone.  Ce paramètre est aussi à ajouter au niveau de la définition des zones locales, comme localhost et 0.0.127.in-addr.arpa.

Ensuite, au niveau des paramètres globaux du serveur, ajoutez l'indication plus restrictive :

  allow-query {127.0.0.1;ip_de_votre_serveur;};

Ainsi, à part depuis votre propre serveur, seuls les domaines configurés localement pourront être interrogés, toute autre interrogation sera purement et simplement rejetée, même si le domaine interrogé est présent dans le cache.

Dans tous les cas, la meilleure solution consiste à séparer le serveur de cache (qui clairement a besoin du récursif) du serveur authoritaire...  que tu utilises djbdns ou bind c'est la même chose, c'est d'ailleurs très clairement conseillé aussi dans la documentation de djbdns.  L'inconvénient de cela c'est qu'il faut utiliser 2 IP différentes (ce qui peut bien sûr être l'IP locale 127.0.0.1 d'un côté et l'ip publique de l'autre).


Personellement, c'est ce que je fais, mais en plus je sépare même les 2 services sur des machines différentes : j'ai un serveur DNS qui se charge exclusivement du cache DNS et donc du récursif, qui est accessible depuis mes serveurs (et configuré au niveau de resolv.conf) mais qui n'est pas accessible depuis le net, et à l'inverse mes serveurs DNS autoritaires n'effectuent aucune recherche récursive, mais sont eux bien évidemment accessibles publiquement.  C'est là la meilleure chose à faire : si un serveur est accessible depuis le net, alors il ne fait aucune requête récursive.

Le problème ne se pose que lorsque l'on souhaite que un seul serveur effectue les 2 opérations, ce qui est le cas de la configuration par défaut de OVH.  Il serait nettement plus simple d'utiliser l'un des serveurs de OVh comme serveur de cache (le cache serait d'autant plus efficace) et de n'utiliser les serveurs DNS de chacun de nos serveurs que comme serveurs autoritaires, avec dans ce cas les recherches récursives totalement désactivées, mais ça c'est à OVH de mettre en place, car il faudrait un serveur de cache prévu pour gérer toutes les requêtes de tous les dédiés. 

===== DjbDNDS =====

> Pourrais-tu détailler ton avis ?  Je suis certain que l'installation de
> tinydns a été au moins aussi complexe que les 2 lignes à ajouter dans la
> configuration de Bind...  le problème mentionné dans ce thread est une
> mauvaise configuration à la base, qui pourrait aussi être effectuée avec
> tinydns/djbdns...

Non, par défaut, djbdns est protégé contre ce type d'attaque.

> Dans tous les cas, la meilleure solution consiste à séparer le serveur de
> cache (qui clairement a besoin du récursif) du serveur authoritaire...

Oui, et bien c'est comme ça que fonctionne djbdns de base, et c'est dans ce 
sens qu'est la doc : tu créé SOIT un serveur autoritaire, soit un serveur de 
cache, soit...

> que 
> tu utilises djbdns ou bind c'est la même chose, c'est d'ailleurs très
> clairement conseillé aussi dans la documentation de djbdns.  L'inconvénient
> de cela c'est qu'il faut utiliser 2 IP différentes (ce qui peut bien sûr
> être l'IP locale 127.0.0.1 d'un côté et l'ip publique de l'autre).

Oui, mais en même temps, dans 90% des cas :
* tu as 1 autoritaire à destination du monde -> bindé sur ton IP
* un cache local, bindé sur 127.0.0.1
* si tu veux un cache pour ton réseau, ou pour tes serveurs (rarement 
nécessaire pour des dédiés, sauf en cas de vm/vservers/...), et bien il 
n'autorise les requêtes récursives qu'aux adresses IP ou subnets que tu lui 
as donné dans sa conf. Donc par défaut, un cache ne fonctionne pour personne 
sous djbdns.

> Personellement, c'est ce que je fais, mais en plus je sépare même les 2
> services sur des machines différentes : j'ai un serveur DNS qui se charge
> exclusivement du cache DNS et donc du récursif, qui est accessible depuis
> mes serveurs (et configuré au niveau de resolv.conf) mais qui n'est pas
> accessible depuis le net, et à l'inverse mes serveurs DNS autoritaires
> n'effectuent aucune recherche récursive, mais sont eux bien évidemment
> accessibles publiquement.

C'est le fonctionnement de base de djbdns sans se poser de question ou autre. 
Ca t'assure ne ne pas ouvrir de faille par oubli ou méconnaissance des 
méandres du protocole DNS.
D'un autre coté, vu la faible empreinte mémoire de djbdns et sa facilité 
d'installation/configuration, le mieux (niveau perfs et secu) est d'avoir un 
dns cache local sur chaque serveur physique (voire virtuel, selon les 
applications) qui peut forwarder vers un serveur cache de réseau si tu est 
sur un réseau privé (pour limiter le traffic sortant).

> C'est là la meilleure chose à faire : si un 
> serveur est accessible depuis le net, alors il ne fait aucune requête
> récursive.

C'est la façon de fonctionner par default de djbdns.

> Le problème ne se pose que lorsque l'on souhaite que un seul serveur
> effectue les 2 opérations, ce qui est le cas de la configuration par défaut de OVH.  

On peut sous djbdns aussi, mais il ne servira de cache que pour les IP ou 
subnets que tu auras explicitement spécifiés. Donc même dans cette 
configuration tu est secure.

> Il serait nettement plus simple d'utiliser l'un des serveurs de 
> OVh comme serveur de cache (le cache serait d'autant plus efficace) et de
> n'utiliser les serveurs DNS de chacun de nos serveurs que comme serveurs
> autoritaires, avec dans ce cas les recherches récursives totalement
> désactivées, mais ça c'est à OVH de mettre en place, car il faudrait un
> serveur de cache prévu pour gérer toutes les requêtes de tous les dédiés.

Non, le mieux (selon moi) serait un djbdns autoritaire sur ton IP publique, et 
un djbdns cache local sur chaque machine (qui éventuellement forward ses 
requêtes à un dns cache fournis par OVH pour ses clients, mais ca n'est pas 
nécessaire non plus).

Je suis désollé, je ne supporte pas le Buggy Internet Name Daemon, c'est plus 
fort que moi. Trop d'historique dans les failles de secu, trop mal pensé, 
trop lourd, trop chiant à configurer finement, bref, si vous voulez l'avis 
d'un expert (je ne vous demande pas de me croire sur parole, je ne suis personne pour vous) :

  * Pourquoi il ne faut pas utiliser bind : http://cr.yp.to/djbdns/blurb/unbind.html http://cr.yp.to/djbdns/blurb/bindmoney.html
  * Pourquoi djbdns est plus secure que bind : http://cr.yp.to/djbdns/blurb/security.html
  * De l'importance de séparer le cache des serveurs autoritaires : http://cr.yp.to/djbdns/separation.html

Je suis prêt à répondre à vos questions si ca vous interesse.

Cordialement,
jc <bohinjc@phiropsi.com>

> Je suis désollé, je ne supporte pas le Buggy Internet Name Daemon, c'est plus 
> fort que moi. Trop d'historique dans les failles de secu, trop mal pensé, 
> trop lourd, trop chiant à configurer finement, bref, si vous voulez l'avis 
> d'un expert (je ne vous demande pas de me croire sur parole, je ne suis 
> personne pour vous) :

Je suis d'accord avec toi sur ce point, Bind est lourd et chiant à configurer et a pas mal de défauts, toutefois djbdns a aussi ses défauts et ne convient pas à tout le monde (dans mon cas Bind sert de DNS secondaire pour mes clients, or djbdns à ce niveau n'a pas exactement le même comportement ce qui fait que certaines choses qui fonctionnent sur le primaire de mes clients ne fonctionneraient pas sur mon secondaire s'il était en djbdns), de plus Bind est déjà installé sur les machines, et le configurer correctement est tout aussi facile que de le désinstaller et installer djbdns à la place (qui soit dit en passant nécessite aussi d'être patché lors de l'installation, pour supporter ipv6 par exemple,...).

Bind est chiant à configurer, mais si Bind est mal configuré, la première solution est de mieux le configurer avant de se dire "je passe à un autre soft", qui lui aussi peut avoir ses défauts de configurations.

Pour info : j'ai pour plus de 30Mo de configuration DNS, regrouper tout ça dans un seul fichier ne me plait pas trop, pas plus que d'être obligé de recompiler tout le fichier chaque fois que je modifie un seul paramètre.  Essaye d'ajouter un service de dns dynamique à ça, et tu te vois recompiler les 30Mo du fichier de config de façon intempestive, je n'ai vu aucun moyen de modifier un seul paramètre sans devoir tout recompiler  :( .

djbdns utilise une config au format cdb, le format cdb est adapté à des fichiers qui ne nécessitent que relativement peu de modifications.

Stéphane Bouvard <ml@frn.be>