[AlternC-dev] TR: Avertissement concernant les serveurs DNS recursifs ouverts

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Olivier HUET o.huet at apogea.net
Mer 29 Mar 12:22:00 CEST 2006


Sur nos serveurs AlternC, la config par defaut semble etre de laisser le DNS en recursif ouvert :(

Voici ma proposition de patch (actuellement en teste sur l'un de nos serveurs en pre1.0)

J'ai egalement mis fetch-glue a no pour eviter le cache poisoning.

Comme c'est la premiere fois que je touche a ca, n'hesitez pas a critiquer ;-)

D'apres ce que j'en lis, il semble urgent de verouiller les DNS recursifs ouverts...

Olivier

 


-----Message d'origine-----
De:	AFNIC [SMTP:relations.prestataires at afnic.fr]
Date:	mercredi 29 mars 2006 11:06
A:	fai at afnic.fr
Objet:	Avertissement concernant le	s serveurs DNS recursifs ouverts

[Attached is an english version, if necessary.]

Vous l'avez peut-etre vu dans la presse, les attaques par deni de
service utilisant des serveurs DNS pour l'amplification sont en
brusque augmentation.

Ces attaques ont en commun d'utiliser des serveurs DNS recursifs
ouverts. Un serveur DNS recursif est dit ouvert lorsqu'il repond a des
requetes du monde entier (et pas seulement de son reseau local, comme
il devrait le faire). Il peut alors servir de relais pour l'attaque
par deni de service, engageant ainsi potentiellement la responsabilite
de son administrateur. La reponse DNS etant typiquement plus grosse
que la requete, il y a amplification de l'attaque, permettant a
l'attaquant d'economiser sa bande passante.

L'AFNIC tient a attirer l'attention de tous ses membres sur le danger
que representent les serveurs DNS recursifs ouverts. Ils ont peu
d'usages legitimes alors que leur role dans les attaques actuelles en
fait une menace pour tout l'Internet. L'AFNIC recommande fortement la
fermeture de ces serveurs ouverts, selon les methodes exposees dans
les references. Par exemple, pour le serveur DNS BIND, l'usage de
"recursion no" est demande. Pour le service recursif a destination du
reseau local (et des clients, pour un FAI), il faut utiliser une
deuxieme machine ou bien un deuxieme demon sur la meme machine ou
encore les vues de BIND 9.

Vous pouvez naturellement demander details ou aide a l'AFNIC
<hostmaster at nic.fr>.

L'AFNIC, ainsi que les autres registres de TLD, poursuit la reflexion
quant aux autres mesures a adopter contre ce risque. Une des
possibilites discutees est le refus de servir les requetes des
serveurs DNS recursifs ouverts. Pour l'instant, les etudes montrent
qu'une part importante de serveurs de noms sur le reseau sont des
recursifs ouverts, ce qui merite notre attention collective et devrait
faire l'objet de mesures correctives de la part des gestionnaires de
serveurs de noms.


References :

Securing an Internet Name Server
http://www.cert.org/archive/pdf/dns.pdf. Une tres bonne synthese
pratique pour l'administrateur systeme.

DNS Amplification attacks
http://www.isotf.org/news/DNS-Amplification-Attacks.pdf. Une bonne
description des attaques actuelles.

The Continuing Denial of Service Threat Posed by DNS Recursion
http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf. L'avis du
CERT etats-unien.

Stop abusing my computer in DDOSes, thanks
http://weblog.barnet.com.au/edwin/cat_networking.html. Une description
du premier cas connu de cette attaque, connu sous le nom de
"x.p.ctrc.cc".

[En francais] Il est recommande de fermer les serveurs DNS recursifs
ouverts
http://www.bortzmeyer.org/fermer-les-recursifs-ouverts.html. Inclus
une description detaillee de l'attaque.
 
-------------- section suivante --------------
--- /etc/bind/named.conf.svg    Wed Mar 29 12:03:06 2006
+++ /etc/bind/named.conf        Wed Mar 29 12:15:51 2006
@@ -28,6 +28,8 @@
        auth-nxdomain no;    # conform to RFC1035
         allow-query     { "internal"; };
         allow-transfer  { "allslaves"; };
+       allow-recursion { "internal"; "allslaves"; };
+       fetch-glue no;

 };
-------------- section suivante --------------
As you have perhaps noticed in the media, denial-of-service (DoS)
attacks using DNS servers to get an amplification of the attack are
currently becoming more common.

These attacks all use ORNs, Open Recursive Nameservers. A recursive
DNS nameserver is "open" when it accepts to reply, not only to its
local network (as it should) but also to the whole world. It can
therefore be used as a proxy for the DoS attack. Being part of the
attack, it can engages the responsability of his administrator. Since
a DNS reply is typically larger than the request, the attack is
amplified, so the bad guy can save his bandwidth.

AFNIC wants to remind all its members that ORNs are a danger for the
whole Internet. These ORNs have few legitimate uses. AFNIC strongly
recommends to stop the ORNs, following the techniques described in the
references. For instance, for the BIND program, using "recursion no"
is recommended. For the legitimate recursive service towards the local
network (and towards the clients if you are an access provider), you
need to use a second machine, or a second daemon or even the views of
BIND 9.

Of course, you can ask AFNIC for help or advices <hostmaster at nic.fr>.

AFNIC, together with other TLD registries, pursues its reflection
about this vulnerability and the best ways to counter it. One of the
possible ways is to stop serving the DNS requests from ORNs. At the
present time, surveys show that an important part of the nameservers
on the Internet are ORNs, which should call for our attention and for
action by the system administrators.


References :

Securing an Internet Name Server
http://www.cert.org/archive/pdf/dns.pdf. A very good practical
synthesis for the system administrator.

DNS Amplification attacks
http://www.isotf.org/news/DNS-Amplification-Attacks.pdf. A good
description of the current attacks.

The Continuing Denial of Service Threat Posed by DNS Recursion
http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf. Official
advice from the USAn CERT.

Stop abusing my computer in DDOSes, thanks
http://weblog.barnet.com.au/edwin/cat_networking.html. A description
of the first known case, known as "x.p.ctrc.cc".



Plus d'informations sur la liste de diffusion Dev