2013/7/1 Stephane Bortzmeyer <bortzme...@nic.fr>
> On Mon, Jul 01, 2013 at 12:07:16PM +0300,
> Arnaud GRANAL <serp...@gmail.com> wrote
> a message of 137 lines which said:
>
> > > Bref, un conseil à ceux qui veulent faire une attaque DNS par
> > > réflexion avec résolveurs ouverts : n'utilisez pas ces services.
> >
> > Pas sur que ce soit efficace,
>
> Relisez ma phrase. Je n'ai jamais suggéré de fermer ces services. Je
> donnais un conseil aux attaquants (en espérant qu'ils me paieront en
> bitcoins).
>
>
Je disais qu'un simple round-robin sur un gros nombre de resolveurs permet
de contourner le probleme (mais le probleme est deja evoque dans un draft
au sujet de DNS RRL).
> > Si ce ne sont pas des resolveurs DNS recursifs, les mecs pourront de
> > toute facon taper sur des serveurs autoritaires.
>
> Un adjudant est autoritaire, un serveur DNS fait autorité.
>
> Et, non, ce n'est pas pareil (et, désolé, je parle de ce que je
> connais et vois tous les jours, sur nos serveurs faisant
> autorité). Les serveurs faisant autorité sont certes plus rapides mais
> ont presque toujours une amplification plus faible (qui peut me
> trouver un enregistrement de 4 096 octets sur un tel serveur ?), et
> surtout sont activement gérés, monitorés et munis des derniers
> perfectionnements (genre RRL).
>
>
Effectivement. Il y a quand meme quelques bons clients qui racontent leur
vie dans les records DNS ( dig axfr @ns12.zoneedit.com zonetransfer.me )
Mais n'est-il pas plus agreable pour le client de recevoir le bit TC
(truncated reply) de la part du serveur sur toutes les queries "douteuses"
plutot que de subir un rate-limit ou throttle ?
Client agressif (c.f. rate limiting):
=> Paquets automatiquement tronques a "taille de la query envoyee par le
client" (ou une taille arbitrairement basse).
=> Amplification nulle (le DNS ne devient plus qu'un relai d'attaque
basique).
Seul gros defaut que je vois c'est le temps perdu a faire le 3-way
handshake TCP, mais est-ce moins pire qu'un timeout ou une reponse DNS tres
tres lente ?
> > Meme si bind etait patche pour utiliser un systeme de cookie (a la
> > syncookies), ou forcer le fallback en TCP en cas de high-rate, il y
> > de toute facon plein de protocoles favorables a l'amplification (les
> > jeux type Half-Life, Call of Duty..., Bittorent en UDP, SNMP, SIP).
>
> Mais ce ne serait plus mon problème :-)
>
>
Les problemes des hommes sont plus grand que l'humanite :o)
> > Je ne sais meme pas si le rate-limiting est une bonne idee au fond,
> > car elle permettrait en theorie d'empoisonner le cache bien plus
> > facilement.
>
> Merci de la description, je regarde ça.
>
> > => 8.8.8.8 se met donc a ne plus repondre a serveur X
>
> Attention, les rate-limiteurs existants dans les serveurs de noms
> répondent (technique dite SLIP), même lorsqu'ils limitent.
>
>
Effectivement, quelques dig ANY isc.org @8.8.8.8 +edns=0 (3 ou 4) suffisent
a trigger le rate-limiting.
Mais visiblement, comme vous dites, le serveur ne timeout pas reellement
comme semble le faire croire queryperf, mais il sleep (sans mauvais jeux de
mots).
Arnaud.
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
