Résumé de l’attaque : Utilisation de nos DNS Externes ouverts sur Internet pour effectuer un Déni de Service sur un serveur quelconque. Le but est d’utiliser notre infrastructure à des fins d’attaque. Il s’agit d’une attaque de type DRDoS par amplification.

stats_bind_rdos

Caractéristiques de l’attaque

  • attaque de type déni de service (on tente de faire tomber un serveur en le bombardant de requêtes) [DoS] ;
  • attaque distribuée : il semble que l’attaque soit distribuée, c’est à dire que plusieurs machines sources soient utilisées (nous ne pouvons avoir de certitudes sur ce point) [D];
  • attaque par amplification : la requête qui est envoyée a un poids faible par rapport à la taille de notre réponse. On se sert de nos réponses pour amplifier l’attaque ;
  • attaque réflexive : nous sommes le vecteur de l’attaque. Nous sommes utilisés dans le déni de service [R].

Principe de l’attaque

Un individu malveillant (que nous nommerons Mallory) décide d’attaquer un serveur web, celui de Bob. Pour ce faire, Mallory décide d’utiliser un réseau de PC zombies (un botnet, un réseau de machines infectées par un virus ou un troyen et que Mallory peut contrôler). C’est la partie distribuée de l’attaque. Chaque machine zombie contrôlée par Mallory va envoyer des requêtes DNS en rafale sur notre serveur DNS. Les requêtes portent toujours sur les mêmes domaines (comportement scripté) et sont du type ANY, les plus coûteuses (la taille de nos réponses est plus importante que la taille des requêtes). C’est la partie amplification de l’attaque. Dans notre cas, en passant par notre DNS Mallory multiplie par 10 (voir calcul plus bas) sa capacité de nuisance. Chaque requête transmise par les machines de Mallory a été forgée : l’adresse IP source a été usurpée ; elle ne correspond pas à la machine source de l’attaque mais à l’adresse IP de la victime, ici celle de Bob. Il s’agit de l’utilisation d’une faiblesse connue du protocole DNS (nous sommes en UDP, donc non connecté ; usurper une adresse IP dans le cadre de TCP n’est pas possible). C’est la partie réflexive de l’attaque. Le serveur de Bob (le pauvre) va être saturé (ce serveur ou un équipement intermédiaire de l’infrastructure de Bob, comme un parefeu ou autre) par les réponses que nous lui transmettons. Bob ne verra comme source de l’attaque que notre propre adresse IP (celle de notre serveur DNS). Il pourra donc croire que nous avons essayé de le faire tomber.

Conclusion

À mon sens, cette attaque pose trois problèmes principaux :

  • le risque de saturation est réel pour nos serveurs. Bien que nous ne soyons pas visés directement par les attaques (la volonté n’est pas de faire tomber notre serveur DNS), nous ne connaissons ni la capacité de nos serveurs ni la capacité de nuisance des attaquants (Mallory et sa bande) ;
  • les ressources de l’infrastructure sont utilisées pour mettre à mal des serveurs ; nous ne sommes que le bras armé d’attaquants qui utilisent (volent ?) notre puissance et notre bande passante. Dans le contexte que nous connaissons, où nous allons compter le nombre d’impressions par agents cela a de quoi laisser perplexe ;
  • le risque est diplomatique enfin : des serveurs gouvernementaux ou ministériels sont utilisés pour attaquer des ressources diverses (sites chinois, américains, irlandais). Cet impact n’est pas négligeable.

Quantification de l’effet amplification

Sur un serveur DNS, nous lançons la capture des requêtes effectuées par une machine cliente :

# tcpdump -i bond0 -s 0 src 192.168.120.73 or dst 192.168.120.73 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes 
11:41:51.568090 IP 192.168.120.73.47893 > mondns.domain: 16470+ ANY? toto1.domaine.fr. (32) 
11:41:51.568267 IP mondns.domain > 192.168.120.73.47893: 16470* 6/0/3 SOA, NS dns.domaine.fr, MX mail.domaine.fr. 0, A toto.domaine.fr. (248) 
11:42:40.451817 IP 192.168.120.73.36587 > mondns.domain: 22819+ ANY? toto2.domaine.fr. (29) 
11:42:40.642098 IP mondns.domain > 192.168.120.73.36587: 22819 8/5/2 MX mail.domaine.fr. 20, SOA, NS dns.domaine.fr. (343)

Les captures ont été tronquées bien sûr. Depuis la machine cliente, lancement des commandes :

# dig @192.168.130.201 toto1.domaine.fr ANY

Pour chaque domaine utilisé pour l’attaque par amplification, nous pouvons ainsi quantifier l’amplification. Nous voyons dans la capture les éléments suivants :

11:43:12.787273 IP 192.168.120.73.40997 > mondns.domain: 24721+ ANY? toto1.domaine.fr. (29)
11:43:12.825365 IP mondns.domain > 192.168.120.73.40997: 24721 9/5/2 MX relaismsg2.domaine.fr. 20, A reverse.domaine.net, SOA, NS dns1.domaine.fr. (359)

La taille de la requête initiale est de 29 octets (sans compter les entêtes UDP et IP). La taille de la réponse du serveur DNS est de 359 octets (sans compter les entêtes UDP et IP). Le facteur d’amplification dans ce cas est 359/29 soit 12.37. Pour un octet reçu, nous en transmettons 12.37. Soit un ratio moyen de 10.2. Pour un octet reçu, nous transmettons en moyenne 10.2 octets.