Un serveur DNS exposé sur le web, FBI

BlogLife août 04, 2020

L'idée m'est venue lorsque j'ai saisi des articles concernant PiHole. Ne souhaitant pas héberger ce service chez moi, j'ai directement exploité un VPS pour y mettre ce service.
Pour être direct : c'est une fausse bonne idée. Ne le faites pas !


Rétrospective et mise en place

Achat rapide d'un VPS en Allemagne chez Hetzner, installation succinte d'une distribution, modification rapide des DNS et c'est plié.

Pas peu fier d'avoir mis en place PiHole dans un conteneur derrière Traefik, je me suis empressé de mettre en place toute une suite de liste de blocages pour les publicités et autres outils de métriques. Tout s'est très bien mis en place, pas d'erreur/problème remonté... C'est tout bon.

Le blocage le plus "lourd" a été de pouvoir joindre PiHole via le reverse-proxy - pour ça, une configuration a été faite côté Traefik dont les fichiers sont disponibles via GitHub à cette adresse.

En soit, la mise en place est simple : un VPS sous Debian, un docker + docker-compose et le fichier docker-compose.yml qui va bien. Ouverture des flux 80/TCP, 443/TCP, 8080/TCP (tableau de bord Traefik) et enfin le port 53 en TCP et aussi en UDP. Oui, aujourd'hui, les DNS et les machines communiqnent de plus en plus via le port 53 en TCP pour la résolution DNS - je vous laisse visiter deux liens de l'excellent blog de Stéphane BORTZMEYER : https://www.bortzmeyer.org/7766.html && https://www.bortzmeyer.org/dns-over-tcp.html.

Quelques reload du service plus tard, le PiHole était fin prêt à résoudre les dizaines de milliers de requêtes qu'il allait prendre..!


Exploitation et problème

En quelques clics (Windows...), mes cartes réseaux ont bénéficier d'un serveur DNS, à savoir l'IP du VPS et donc de PiHole (reverse-proxy, tout ça...). Même pour certaines de mes VM, c'est maintenant PiHole qui était le serveur DNS à contacter.
Tout s'est très bien passé, je n'ai pas ressenti de latence lors des requêtes, aucun problème à signaler. Parfait... exploitons alors, sans se poser de questions.

Après une semaine environ de mise en place, un "truc" est arrivé : e-mail du BSI.

Le BSI (Bundesamt für Sicherheit in der Informationstechnik), c'est l'équivalent allemand de notre ANSSI. Mon nom de domaine étant plus ou moins protégé, l'adresse e-mail y est toujours affichée ; de plus, puisque le VPS est allemand et que le BSI est allemand, les infos sont facilement accessibles et croisées.

Le BSI m'a alors expliqué en quelques lignes quel était le problème, pourquoi "moi" et un début de piste pour remédier au soucis. Ne souhaitant pas afficher publiquement ce qu'il en est, voici un résumé :

  • le BSI est informé des attaques mondiales, y compris les botnet.
  • vi leurs sondes, l'IP du VPS a été vue comme faisant partie d'un botnet mondial d'attaques DNS
  • pour être plus précis, mon VPS servait de machine zombie pour faire du "DDoS DNS reflection", donc via le port 53 UDP/TCP.

Lorsque j'ai reçu le mail, je me suis dis : "fake, encore un spam" ; puis après avoir reçu plusieurs appels provenant d'Allemagne et d'autres notifications de manière générale, je me suis dis qu'il y avait vraiment quelque chose. Après avoir pris conscience de la gravité du problème, la remédiation fût simple et rapide : dans mon fichier docker-compose.yml, j'ai tout simplement commenté les deux ports 53 pour le service Traefik. Un petit docker-compose up -d et s'en était fini de cette malencontreuse association (à mon insu). Le fichier de configuration Traefik a été mis à jour aussi pour ne plus avoir d'entrypoint sur les 53.


La leçon

Mettre des services en oeuvre sur le web, c'est devenu très facile. Qu'importe les compétences, vous pouvez facilement trouver des astuces ou même des gens prêts à vous rendre service. Toutefois, puisqu'il s'agit d'un espace libre, tout le monde ET tous les robots seront présents dès les premières millisecondes où votre service sera en écoute..!

Installer un service et s'en servir c'est chouette, par contre il y a un vrai travail à faire autour :

  • s'assurer que ledit service est accessible en fonction des besoins (par exemple, si c'est un serveur web privé, ajouter des règles de filtrage et de blocage quant aux connexions autorisées, les types de connexions, pourquoi pas bloquer des adresses réseau entières...).
  • toujours s'informer des vulnérabilités qui apparaissent sur les services mis en place (donc prendre les mesures adéquats en fonction de la criticité et de l'impact).
  • avoir un système de supervision, d'une part sur l'état des services mais surtout sur le nombre de connexion entrantes, leur type, leur taille, leur source... et coupler le tout à un système d'alertes automatiques.
  • "tester c'est douter", mais parfois c'est pratique quand même... essayez d'auditer vos systèmes, il existe de nombreux outils permettant de le faire à votre place et en plus gratuitement !

C'est une mauvaise aventure qui, fort heureusement, ne m'a rien coûté, que ce soit en terme financier qu'en terme technique. C'est une bétise, clairement, et pour tout dire je ne m'attendais pas à être "harcelé" au bout d'une semaine... Et encore, c'est au bout d'une semaine qu'on m'en a informé, alors que potentiellement mon service était pris dans les filets dès son arrivée sur le web...

Faites attention à vous !

Mots clés

Julien HOMMET

Bercé par l'informatique depuis mon plus jeune âge, je transforme ma passion en expertise.