\documentclass[city=Montpellier,year=2013]{jres}
\usepackage[utf8x]{inputenc}
\title{Persée et la Gorgone : attaques par déni de service utilisant le DNS, et les contre-mesures}
\auteur{Stéphane Bortzmeyer}
	{AFNIC}{%
	    Immeuble International\\
	    78181 Saint-Quentin-en-Yvelines\\
            \url{bortzmeyer (à) nic.fr}}

% Mes macros à moi
\newcommand{\foreign}[1]{\begin{slshape}#1\end{slshape}}
\newcommand{\computer}[1]{{\ttfamily#1}}

\begin{document}

\maketitle

\begin{abstract}
Les années récentes ont vu une brusque augmentation du nombre
d'attaques par déni de service (DoS) utilisant le DNS. Les attaques
ainsi menées dépassent désormais couramment les 20 Gb/s cumulés. Ces
attaques utilisent en général la réflexion (un serveur tiers relaie le
paquet IP) et l'amplification (la réponse est plus grande que la
question, aidant l'attaquant à atteindre son objectif). 

Il existe plusieurs contre-mesures possibles contre ces attaques :
militer pour le déploiement effectif de BCP 38 (c'est-à-dire que les
FAI empêchent l'usurpation d'adresses IP par leurs usagers), modifier
le protocole DNS et imposer une limitation de trafic, refusant de
répondre au-delà d'un certain rythme.

\end{abstract}

\motscles{DNS, sécurité, DoS, dDoS, rate-limiting, BIND, NSD, Netfilter}

\section{Introduction}

Les attaques par déni de service sont une des principales plaies de
l'Internet. Elles sont faciles et relativement peu coûteuses à monter,
et il est très difficile de se défendre, sauf à dépenser des sommes
considérables et, souvent, à brider des activités légitimes.

La variété « attaque par déni de service utilisant le DNS\footnote{Les
attaques contre le service DNS, visant à perturber ce service,
sont une autre question \cite{jcsa2012} \cite{bortzmeyer2012}.} » est
très ancienne (la première description date de 2006 \cite{vaughn1996}). Mais elle était
restée relativement rare, jusqu'à la vague de 2011-2012, qui a été
mise sur le devant de la scène par un fil de discussion sur la liste
dns-operations gérée par l'OARC\footnote{\url{https://www.dns-oarc.net/}} : « \foreign{Abnormal activity from
chinanet?} » en décembre 2011.

Depuis, de nombreuses réunions de l'OARC ou d'organisations similaires
ont été consacrées à ce problème.

\section{Description de l'attaque}

\subsection{Principe}

Le principe d'une attaque par réflexion est simple : l'attaquant
utilise un tiers, le réflecteur. Il écrit
au réflecteur en \emph{mentant} sur son adresse IP. Le paquet arrivant
au réflecteur aura donc une adresse IP source qui est celle de la
victime. Le réflecteur va donc répondre\ldots et enverra la réponse à
la victime. C'est en l'honneur du héros mythologique qui tua la gorgone Méduse, grâce à
une attaque par réflexion (son bouclier poli renvoya vers Méduse le
regard pétrifiant de celle-ci), que le titre de cet exposé et le logiciel
d'attaque présenté plus loin font référence
à Persée.

La réflexion seule n'est pas très utile pour l'attaquant. Elle ne le
dissimule pas vraiment (puisqu'il peut tricher sur son adresse). Elle
brouille un peu les pistes (le trafic entre par un autre chemin que
les paquets qui seraient venus directement de l'attaquant). Ceci dit, elle est
surtout intéressante quand on la couple avec l'amplification. Ce
phénomène se produit lorsque la réponse est plus grande que la
question, ce qui est fréquent avec le DNS\footnote{D'autres protocoles
ont cette propriété, comme SNMP \cite{bitag2012} mais aussi Call of
Duty \cite{callof2010}.} L'attaquant obtient
ainsi plus de Mb/s qu'il n'en avait dépensé. Voici un exemple de
requête et de réponse DNS vu
avec tcpdump :

\begin{lstlisting} 
15:05:49.973266 length 85 proto UDP (17), length 71
15:05:49.973468 length 1996 proto UDP (17), length 1982 \end{lstlisting}

On voit que la réponse était 23 fois plus grande que la requête.
Cette attaque est schématisée sur la figure \ref{schema-attaque}.
\begin{figure}
    \centerline{\includegraphics[height=7cm]{attaque-reflection}}
    \caption{Schéma de l'attaque par réflexion}
    \label{schema-attaque}
\end{figure}

On notera que cette attaque est possible car IP permet de tricher sur
l'adresse IP source (d'où les contre-mesures présentées en section
\ref{bcp38}) et parce que UDP, le protocole de transport principal du
DNS, n'a pas de notion de connexion. 

Une des conséquences de l'usurpation d'adresses est que le réflecteur
peut se tromper sur l'origine de l'attaque. Voyant les adresses IP
source, il risque de prendre la victime pour l'agresseur\ldots

\subsection{Quel réflecteur ?}

Quels serveurs DNS utiliser comme réflecteurs ? L'attaquant par
réflexion+amplification a deux possibilités :

\begin{enumerate}
\item Il peut se servir de résolveurs ouverts, des serveurs DNS
  récursifs qui, contrairement aux bonnes pratiques, répondent à tout
  l'Internet,
\item Il peut se servir de serveurs faisant autorité, par exemple ceux
  d'un gros TLD\footnote{\foreign{Top-Level Domain} ou domaine de
    premier niveau.}.
\end{enumerate}

Avec des résolveurs ouverts, l'attaquant doit :

\begin{enumerate}
\item Mettre un enregistrement DNS de grande taille (le type est
  quelconque, c'est souvent un TXT
  mais cela peut aussi être un A) sur un nom qu'il contrôle, comme
   \path{mechant.attaque.quelquepart.example}. Le contenu
   est indifférent et on trouve des textes comme SONYMOUS, XXXXX\ldots
\item Envoyer des requêtes pour ce nom et ce type à de nombreux
  résolveurs ouverts (il en existe des millions, voir la section \ref{openresolver}).
\end{enumerate}
Les résolveurs vont alors répondre et bombarder la victime.

Le seul risque pour l'attaquant est qu'il soit retrouvé via
l'enregistrement du domaine. Ce risque est faible en pratique. La
plupart des résolveurs ouverts sont des machines lentes et mal
connectées mais elles sont très nombreuses. N'étant la plupart du
temps pas gérées du tout, l'attaquant pourra travailler à son aise.

Dans le second cas (utilisation de serveurs faisant autorité),
l'attaquant va :

\begin{enumerate}
\item Trouver un domaine ayant une bonne
amplification et de bons serveurs. Un domaine signé avec DNSSEC
fournit une meilleure amplification. Prenons le TLD \path{example} pour
la suite.
\item Envoyer des requêtes, par exemple de type ANY\footnote{Requête qui
  demande l'envoi de tous les enregistrements disponibles.} aux serveurs
   faisant autorité pour \path{example} en usurpant l'adresse IP.
\end{enumerate}
Ces serveurs bombardent alors la
victime.

Les serveurs faisant autorité sont moins nombreux que les résolveurs
ouverts mais souvent plus puissants (bonnes machines, et bien
connectées). Par contre, ils sont plus fréquemment gérés, supervisés et donc
relativement bien protégés. 

Maintenant, en pratique, quelles sont les attaques les plus
courantes ? Faut-il concentrer ses efforts sur les attaques DNS ou
bien sur celles faites avec SNMP ? Et, si on se focalise sur le DNS,
le problème le plus grave est-il celui des résolveurs ouverts ou bien
celui des serveurs faisant autorité, notamment avec DNSSEC ? Le
problème est qu'on ne sait pas. Comme le notait
Florent Chabaud \cite{jcsa2012}, contrairement à ce qui se
passe pour les accidents d'avions, les attaques par déni de service ne
font pas l'objet d'une enquête indépendante, avec résultats
publiés. Les décideurs sont donc dans le noir. On voit parfois sur des
forums des affirmations fortes sur le danger de telle ou telle attaque
mais elles ne s'appuient pas sur des faits.

À noter que les attaques sont rarement menées par une machine isolée,
mais plutôt par un \foreign{botnet}, un réseau de machines piratées et
qui obéissent désormais à un maître qui les loue \cite{ollmann2009} pour envoyer du spam, faire des attaques par déni
de service, etc.

\section{L'attaque dans le monde réel}

On l'a vu plus haut, peu d'attaques sont documentées
publiquement \cite{shortt2012}. Félicitons donc Lars Noring (du FAI norvégien PowerTech) qui, à l'atelier
OARC de 2012 à Teddington, a présenté « \foreign{A deep dive
into heaps of Spoofed DNS Traffic} », racontant l'attaque dont son
employeur avait été victime. Des paquets DNS étaient envoyés au
résolveur du FAI, avec une 
adresse IP usurpée, appartenant au réseau local du FAI, et demandant
des noms qui 
appartenaient à ChinaNetCenter, un fournisseur de CDN en Chine.

Le dialogue avec les Chinois a été très difficile (ils prétendaient ne
pas comprendre) 
mais l'attaque a fini par cesser. 

Suite à cette mésaventure, l'auteur a voulu savoir si d'autres opérateurs en Norvège avaient la même faiblesse. Il a envoyé à leurs résolveurs des requêtes avec une adresse IP source usurpée, pour un domaine unique qu'il contrôlait. tcpdump sur le serveur faisant autorité permettait de voir si la requête mensongère avait été reçue. Résultat, 50 \% des FAI norvégiens ne filtraient pas en entrée leurs propres adresses IP\ldots

Même transparence de la part de Jérémy Martin (First Heberg) à la
réunion FRnog 21 de 2013 lorsqu'il a décrit en détail l'attaque dont
avait été victime son employeur (les réflecteurs étaient 80 \% de résolveurs ouverts et 20 \%
de serveurs faisant autorité). % http://www.mail-archive.com/frnog@frnog.org/msg24463.html

Autre exemple, vue sur les serveurs de l'AFNIC (figure \ref{attaque-any}), une attaque réelle, affichée par
le logiciel de supervision DSC. Les requêtes de type ANY sont
normalement en nombre infime (ANY ne sert guère qu'au déboguage). Le
trafic ANY intense est donc presque toujours une attaque.
\begin{figure}
    \centerline{\includegraphics[height=9cm]{dsc-any-queries-rate}}
    \caption{Attaque réelle, requêtes ANY, sur un serveur faisant autorité}
    \label{attaque-any}
\end{figure}

\section{Tester les contre-mesures}

Pour étudier les attaques, on utilise le logiciel
SOP\footnote{\foreign{Shield of Perseus}. Il n'est pas disponible en
France, en raison de l'article 323-3-1 du Code Pénal qui interdit
« d'importer, \emph{de détenir}, d'offrir, de céder ou de mettre à
disposition un 
équipement, un instrument, un programme informatique ou toute donnée
conçus ou 
spécialement adaptés pour commettre une ou plusieurs des infractions
prévues par les articles 323-1 à 323-3 », sauf « motif légitime ». On
peut penser que la recherche en sécurité fait partie des motifs légitimes.}. % http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000006418323&cidTexte=LEGITEXT000006070719
Il permet d'envoyer des
requêtes DNS répétées à un réflecteur, en trichant sur l'adresse source. Ses
principales fonctions :
\begin{itemize}
\item Fonctionne en IPv4 et IPv6\footnote{Même si aucune attaque
  utilisant IPv6 n'a encore été rencontrée dans la nature.},
\item Permet de choisir l'adresse source au hasard dans un préfixe
  donné, pour chaque requête (cela perturbe certains limiteurs de
  trafic),
\item Permet d'utiliser EDNS et DNSSEC,
\item Permet de choisir un certain nombre de champs, comme le
  \foreign{query type} de la requête (A, MX, ANY\ldots).
\end{itemize}
 
D'abord, regardons une attaque menée avec SOP\label{premiere-attaque}. La ligne de commande était :
\begin{lstlisting}
sop --qnames example --source 192.168.2.4 --delay 10000 --count 90000 \
    --size 4096  --dport 9053 192.168.2.1 \end{lstlisting}
Ce qui fait un rythme de cent paquets par seconde (10 000 ųs
entre deux paquets) pendant un quart d'heure. Le type des
requêtes est la valeur par défaut, ANY. Le réflecteur est
\computer{192.168.2.1}, et la victime \computer{192.168.2.4}. La commande dig équivalente
est :
\begin{lstlisting}
dig +dnssec +bufsize=4096 -p 9053 @192.168.2.1 ANY example  \end{lstlisting}
Et elle produit ici une réponse de 1 716 octets.
Sur le réflecteur,
une machine NSD sans contre-mesures déployées, on voit bien
(figure \ref{attaque-simple}) la
différence entre le trafic entrant, qui plafonne à 130 kb/s et le
trafic sortant, plus de dix fois plus important.
\begin{figure}
    \centerline{\includegraphics[height=5cm]{attaque-simple-sans-contremesure}}
    \caption{Attaque simple, sans contre-mesure, en laboratoire (avec
      SOP), vue du réflecteur}
    \label{attaque-simple}
\end{figure}
Naturellement, lors d'une vraie attaque, on observe des débits bien
plus élevés. Celle-ci n'était qu'une expérience de laboratoire.

\section{Changer l'Internet}

 Comme toujours en sécurité (ou en santé publique), la question n'est
 pas trouver \emph{la} bonne technique. Il n'existe pas de panacée. Il faut fermer
 les résolveurs ouverts \emph{et} il faut sécuriser les serveurs faisant
 autorité. Si on étudie les secteurs qui ont ce genre de problème de déploiement
 depuis des siècles (lutte contre la délinquance, santé publique), on
 voit qu'il faut attaquer sur plusieurs fronts à la fois. 

\subsection{Empêcher l'usurpation d'adresse}
\label{bcp38}

Comme le point de départ d'une attaque par réflexion est l'usurpation
d'adresse IP, si on supprime cette possibilité d'usurpation, on
résoud le problème. Le jeu de documents connu sous le nom de
« BCP\footnote{\foreign{Best Current Practices}} 38 », qui comprend
actuellement deux RFC \cite{rfc2827} \cite{rfc3704}, demande
exactement cela : que les FAI ne permettent pas à leurs clients
d'envoyer des paquets avec une adresse IP source usurpée. 

Aujourd'hui, le moins qu'on puisse dire est que le déploiement de BCP
38 n'est pas généralisé\footnote{hping a une option
  \computer{-{}-spoof} si vous voulez tester depuis le réseau de votre
  FAI\ldots}. Le fait que la majorité des réseaux ne permette pas la
triche ne suffit pas, il faudrait qu'une \emph{grande} majorité le
fasse. Autrement, les
attaquants iront simplement sur les réseaux les plus laxistes. Les facteurs économiques jouent contre
BCP 38 : le déployer, pour un FAI, c'est dépenser de l'argent pour
gêner ses utilisateurs et protéger ses concurrents. Les statistiques
du \foreign{Spoofer project}\footnote{\url{http://spoofer.cmand.org/}}
ne permettent pas d'être optimiste. On est là dans un cas typique où
la somme des intérêts individuels ne correspond pas à l'intérêt collectif.

Certains experts estiment que l'essentiel des efforts de lutte contre
les attaques par réflexion devrait être consacré à promouvoir et
illustrer BCP 38. D'autres pensent que c'est une cause perdue.

Un projet plus général, SAVI\footnote{\foreign{Source Address Validation
Improvement}}, vise à généraliser BCP 38 mais il en est à ses tous débuts.

\subsection{Fermer les résolveurs ouverts}
\label{openresolver}

Un autre cas où il faut une campagne longue et patiente de conviction,
pour faire bouger un grand nombre d'acteurs, est celui de la lutte
contre les résolveurs ouverts. Ils facilitent beaucoup l'attaque par
réflexion+amplification puisqu'ils permettent à l'attaquant de choisir
exactement la taille et le type des paquets, qu'il va héberger sur son
serveur, avant d'interroger ces résolveurs ouverts. 

Le danger de ces résolveurs est connu depuis longtemps, l'AFNIC avait
alerté à ce sujet dès 2006 \cite{afnic2006} et le RFC qui recommande
officiellement leur fermeture \cite{RFC5358} date de 2008. Comme le
montrent les études du \foreign{Open
Resolver Project\footnote{\url{http://openresolverproject.org/}}},
ce n'est pas gagné. Les résolveurs ouverts sont nombreux, et en
général non gérés (machines installées en vitesse et pas
administrées par la suite). Prévenir un par un leurs responsables,
devoir tout leur expliquer, et sans garantie qu'ils agissent, est une
tâche épuisante.

\section{Changer le DNS}

Une autre possibilité serait de changer le DNS, pour rendre les
usurpations d'adresse IP source plus difficiles. Pour cela, on peut
par exemple utiliser TCP plutôt que UDP. Cela résoud complètement la
question\footnote{TCP n'est pas vulnérable aux usurpations d'adresse
  menées en aveugle \cite{RFC5961}.} mais cela soulève deux problèmes :
\begin{itemize}
\item Les performances sont moins bonnes en TCP \cite{dupont2013}, même si, aujourd'hui, des serveurs affichant un grand nombre
  de connexions TCP par seconde sont bien plus courants, grâce au Web.
\item Hélas, bien des serveurs DNS ne répondent pas en TCP, en général
  en raison d'un pare-feu mal configuré situé devant le serveur. Le
  remplacement d'UDP par TCP nécessiterait donc une campagne de
  sensibilisation, comme les solutions de la section précédente.
\end{itemize}

Autre changement possible du DNS, plus radical : modifier le protocole
pour avoir un système de \foreign{cookies}. Ce sont des nombres
imprévisibles, générés par le serveur, et que le client doit
transmettre dans ses futures requêtes, pour prouver qu'il a bien reçu
le \foreign{cookie}\footnote{L'attaquant qui usurpe une adresse IP
source travaille en aveugle, puisqu'il ne peut pas recevoir les
réponses.} Comme tout changement de protocole, on peut s'inquiéter des
chances réelles de déploiement, dans un Internet où il est très
difficile de faire bouger les choses.

Naturellement, on n'est pas obligé de déployer ces techniques
seules. On peut les combiner avec la limitation du trafic, présentée
dans la section suivante, par exemple en ne limitant que les clients
qui ne présentent pas de \foreign{cookies}. Cela fournirait une
incitation au déploiement de logiciel plus récent, gérant ces \foreign{cookies}.

\section{Limiter le trafic}

\subsection{Diverses méthodes}
\label{netfilter}

Les attaques utilisant les serveurs faisant autorité s'appuient
souvent sur des requêtes de type ANY, pour obtenir le maximum
d'amplification. Il a parfois été proposé de refuser de répondre à ces
requêtes. Neustar avait choisi cette voie pour \path{us} et \path{biz}
mais a fait machine arrière depuis.

L'approche la plus courante à l'heure actuelle, chez les opérateurs de
serveurs DNS faisant autorité, est de limiter le trafic sortant, pour
empêcher que leurs machines servent d'amplificateurs. Ce
n'est pas que les autres méthodes soient mauvaises, mais leur
déploiement dépend d'autres acteurs. Première idée, diminuer la taille
maximale des réponses, par exemple à 1 460 octets\footnote{Avec NSD,
c'est la directive \computer{ipvX-edns-size: 1460}, avec BIND, c'est \computer{max-udp-size 1460}.}. Cette technique ne semble avoir été déployée, pour l'instant, que
par Verisign, sur les serveurs de \path{com} et \path{net}. Elle diminue
le facteur d'amplification mais celle-ci demeure quand même non négligeable.

On peut déjà utiliser les services de base du système d'exploitation
pour limiter le trafic, et cela a été fait au début, avant que les
logiciels serveurs de noms ne soient dotés de cette fonction. Ainsi,
le serveur racine F, qui tourne sur FreeBSD, avait dans sa
configuration :
\begin{lstlisting}
add     pipe 1          udp     from any to any 53 in
pipe 1  config  mask src-ip 0xffffffff buckets 1024 bw 400Kbit/s queue 3
add     pipe 2          tcp     from any to any 53 in
pipe 2  config  mask src-ip 0xffffffff buckets 1024 bw 100Kbit/s queue 3 \end{lstlisting}

Sur Linux, le système de pare-feu se nomme Netfilter\footnote{Mais est
parfois désigné par le nom de la commande de configuration,
iptables.}. Netfilter est modulaire et deux modules nous intéressent
particulièrement ici :

\begin{itemize}
\item hashlimit permet de faire de la limitation de trafic par préfixe
  IP\footnote{Plusieurs autres modules de limitation de trafic
    existent mais ont des limites sérieuses \cite{bortzmeyer2012b}.},
\item m32 permet de tester des champs quelconques du paquet entrant,
  par exemple pour ne filtrer que les requêtes concernant un domaine donné.
\end{itemize}

m32 utilise un langage plutôt compliqué \cite{bortzmeyer2012c}. Pour ne pas avoir à
écrire directement dans ce langage, on passe par un script en Python\footnote{\url{http://www.bortzmeyer.org/files/generate-netfilter-u32-dns-rule.py}}
qui prend en argument les caractéristiques de la requête (nom demandé,
type demandé) et génère le code m32.

On lance SOP avec les mêmes options qu'en section
\ref{premiere-attaque}. Mais cette fois, on a installé une limitation
du trafic « ANY example » avec Netfilter (figure \ref{netfilter-rate-limiter}).
\begin{figure}
\begin{lstlisting}
iptables -A RATELIMITER -m hashlimit \
        --hashlimit-name DNS --hashlimit-above 20/second \
        --hashlimit-mode srcip 
        --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP

iptables -A INPUT -p udp --dport 9053 -m u32 \
     --u32 $(python generate-netfilter-u32-dns-rule.py --qname example --qtype ANY) \
     -j RATELIMITER \end{lstlisting}
\caption{Commandes Netfilter pour limiter le trafic}
\label{netfilter-rate-limiter}
\end{figure}
% $ Ce dollar est juste pour le mode latex d'Emacs, qui est bête
En regardant le trafic sur la victime (figure \ref{attaque-simple-netfilter}), on voit qu'il a en effet été
divisé par cinq, comme on s'y attendait (SOP attaque à 100 p/s, le
limiteur coupe à 20 p/s) :
\begin{figure}
    \centerline{\includegraphics[height=5cm]{attaque-simple-netfilter}}
    \caption{Attaque simple, Netfilter - figure
      \ref{netfilter-rate-limiter} - limite le trafic ANY (trafic
      vers la victime, sans et avec Netfilter sur le réflecteur)}
    \label{attaque-simple-netfilter}
\end{figure}

À noter que le test aurait aussi pu être fait avec
queryperf\footnote{Distribué dans le répertoire \path{contrib/} de BIND.} ou bien avec une commande comme :
\begin{lstlisting}
% repeat 100 dig +short +tries=1 +time=1 @SERVER ANY example \end{lstlisting}

\subsection{RRL}

Une des techniques les plus déployées, en raison de son efficacité,
est la RRL (\foreign{Response Rate Limiting}). Le terme de RRL est en
général utilisé pour désigner les solutions de limitation de trafic
incluses dans le serveur DNS, et reposant sur l'idée qu'un client n'est pas censé
demander la même chose cent fois par seconde. L'inconvénient principal
de la solution Netfilter présentée en section \ref{netfilter} est
qu'il faut l'installer à la main lorsqu'on détecte une attaque,
puisque la règle est spécifique d'un nom de domaine, et d'un type
d'enregistrement. Au contraire, la RRL \cite{vixie2012} se configure automatiquement : dès que
le rythme des réponses identiques dépasse un certain seuil, la RRL se
déclenche et limite le trafic.

RRL est disponible dans NSD depuis la version 3.2.15 \cite{wouter2012}, dans Knot
depuis la 1.2.0 et dans BIND depuis la 9.9.4. Il peut être nécessaire
de compiler le serveur avec une option spécifique\footnote{\computer{-{}-enable-ratelimit}
pour NSD, et \computer{-{}-enable-rrl} pour BIND}.

L'inconvénient classique de la limitation de trafic est qu'on arrête
aussi les requêtes légitimes. Si la victime de l'attaque par déni de
service est également un client normal (un résolveur interrogeant le
serveur faisant autorité), cette contre-mesure le gênera. En pratique,
la victime n'est en général pas un client DNS et ce n'est donc pas un
problème. Pour les cas où la victime est un client DNS, les mises en
œuvre du concept de RRL utilisent SLIP. Son principe est de répondre
de temps en temps aux requêtes, mais avec le bit TC\footnote{Qui
indique une réponse tronquée} mis à 1. Une telle réponse est plus
petite que la question (et ne contribue donc pas à
l'amplification). Le client DNS qui la recevra réessaiera sa question
en TCP et pourra donc recevoir sa réponse. On peut configurer quel
pourcentage des requêtes pour lesquelles le serveur ne veut pas
répondre déclencheront l'envoi de ce paquet tronqué.

Un exemple de configuration de la RRL dans NSD, le premier serveur DNS
qui a été livré avec cette fonction :
\begin{lstlisting}
server:
       ... 
       # 20 identical queries per second, maximum
       rrl-ratelimit: 20 \end{lstlisting}

La figure \ref{rrl-nsd} montre le nombre de paquets par seconde reçus
par la victime (et non pas le nombre de bits par seconde comme sur
les graphes précédents). L'attaque est la même. Le premier pic
correspond à un réflecteur NSD 3.2.16 sans RRL. Le second au même NSD avec
RRL à 20 réponses par seconde. L'attaquant envoie 100 p/s et la victime en reçoit 200 p/s, car la
réponse, plus grosse que la MTU d'Ethernet, a été fragmentée en deux
paquets. Avec la RRL, on ne reçoit que 50 p/s. Il y a les 20 réponses
par seconde autorisées (40 paquets avec la fragmentation) et le SLIP
pour les réponses refusées. En nombre de paquets, l'effet de RRL peut
donc sembler faible, mais il est plus important en nombre d'octets
(les paquets SLIP sont très petits).

\begin{figure}
    \centerline{\includegraphics[height=5cm]{rrl-nsd}}
    \caption{Le trafic sur la victime, sans et avec RRL}
    \label{rrl-nsd}
\end{figure}

NSD journalise le déclenchement de la limitation de trafic\footnote{Le
  type 255 est ANY, le type envoyé par l'attaquant.} :
\begin{lstlisting}
[1380484720] nsd[31551]: info: ratelimit block example. \
     type any target 192.168.2.0/24 query 192.168.2.4 TYPE255 \end{lstlisting}

Et pour BIND ? La RRL se configure ainsi \cite{kbisc2013} :
\begin{lstlisting}
options {
        ...
        rate-limit {
          responses-per-second 20;
        };
}; \end{lstlisting}
Et le résultat est journalisé :
\begin{lstlisting}
29-Sep-2013 15:52:47.929 client 192.168.2.4#5353 (example): \
    rate limit drop response to 192.168.2.0/24 for example IN ANY  (05a919a3) \end{lstlisting}
Et visible graphiquement sur la figure \ref{rrl-bind}.
\begin{figure}
    \centerline{\includegraphics[height=5cm]{bind-rrl-reflector}}
    \caption{Le trafic sur un réflecteur BIND, avec RRL}
    \label{rrl-bind}
\end{figure}

% TODO Il serait rigolo de tester avec plusieurs qnames (se retrouvant
% dans des ``buckets'' différents, ils pourraient permettre de
% contourner RRL.

Knot permet aussi le RRL :
\begin{lstlisting}
system {
  ...
  rate-limit 20;
} \end{lstlisting}
Avec ses paramètres par
défaut\footnote{Paramètre « SLIP » mis à 1}, Knot est nettement plus modéré quand il limite le trafic.

Une évaluation tierce de l'efficacité de la RRL dans BIND est décrite
dans une excellente étude pratique \cite{rozekrans2013}. Cette étude
note qu'une des faiblesses potentielles de la RRL est dans le cas où
le serveur DNS réflecteur fait autorité pour beaucoup de
domaines\footnote{C'est le cas d'un hébergeur DNS, où des serveurs
servant des centaines de milliers de domaines sont courants.}. Si
l'attaquant fait varier le domaine demandé\footnote{Cela s'est déjà
produit dans certaines attaques.}, il peut contourner la
RRL. L'option \computer{-{}-qnames} de SOP peut prendre comme valeur un
nom de fichier, contenant la liste de domaines hébergés par le
serveur, afin de réaliser cette attaque.

Une autre limite de la RRL est qu'elle ne s'applique pas forcément
bien aux serveurs récursifs qui peuvent, eux aussi, servir de
réflecteurs. Un client DNS d'un serveur faisant autorité n'est pas
censé répéter la même question des dizaines de fois par seconde, parce
qu'il est censé avoir un cache, une mémoire des réponses, pour la
durée du TTL. Au contraire, un client DNS d'un serveur récursif a le
droit de ne pas avoir de mémoire, et il peut donc émettre légitimement
de nombreuses requêtes. La question de l'adaptabilité de la RRL aux
serveurs récursifs est encore ouverte aujourd'hui.

Enfin, comme toute technique de sécurité, la RRL apporte de nouveaux
problèmes. C'est ainsi que son utilisation peut favoriser un autre
type d'attaques, les attaques par empoisonnement
\cite{certa2013-AVI-506} \cite{anssi2013}. Dans ces attaques, l'attaquant va tenter de
répondre aux requêtes d'un client \emph{avant} le serveur légitime. Il
y a donc une course entre le serveur légitime et l'attaquant. Si le
serveur légitime utilise RRL, il renonce délibérement à répondre à
certaines requêtes, se retirant de lui-même de la course. Une solution
possible est de toujours répondre, ne serait-ce que par un paquet
SLIP\footnote{Cela se fait avec \computer{rrl-slip: 1} sur NSD et
\computer{slip 1} sur BIND.}. Mais le problème ne semble pas aujourd'hui très présent en pratique.

Dans le futur, on verra sans doute de nouvelles attaques. Certaines
sont prévues mais d'autres pas. Par exemple, il peut être tentant
d'essayer de tromper le limiteur de trafic en essayant plein de noms
au hasard (la réponse NXDOMAIN, dans un domaine signé, peut être assez
grosse quoique pas autant que lorsque le nom existe). SOP met en œuvre
cette technique avec l'option \computer{-{}-qnames random} :
\begin{lstlisting}
sop --qnames random --suffix example ... \end{lstlisting}
Mais le RRL de NSD ne s'y laisse pas prendre. Il considère les
réponses NXDOMAIN comme une seule réponse :
\begin{lstlisting}
[1380567519] nsd[5195]: info: ratelimit block example. \
   type nxdomain target 192.168.2.0/24 query 192.168.2.4 TYPE255 \end{lstlisting}
Et on voit sur le graphique une amplification en octets qui est
négative (moins de données émises par le réflecteur qu'envoyées par l'attaquant).

\section{Conclusion}

En 2013, le nombre d'attaques utilisant le DNS semble avoir baissé, en
tout cas sur les serveurs faisant autorité ayant déployé des
contre-mesures. Peut-être ont-elles simplement migré vers des serveurs
moins protégés ? De toute façon, il est aujourd'hui nécessaire de mettre en œuvre
des contre-mesures. Outre la sensibilisation à BCP 38 et à la
fermeture des résolveurs ouverts, il est nécessaire d'installer et de
configurer un mécanisme de limitation de trafic sur les serveurs
faisant autorité.

\nocite{*}
\bibliography{article}

\end{document}
