Un serveur DNS exposé sur le web, FBI

  • par

L’idée m’est venue de mettre en ligne un serveur DNS 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 du serveur DNS

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 des listes de blocages (publicités et 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 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 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éficié de mon serveur DNS, à savoir l’IP du VPS et donc de PiHole. 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 protégé, l’adresse e-mail y est toujours affichée. De plus, puisque le VPS est allemand et le BSI aussi, les infos sont facilement 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 le service est accessible en fonction des besoins (si c’est un serveur web privé, ajoutez des règles de filtrage quant aux connexions autorisées (types, bloquer des sous-réseaux entier…).
  • 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 quand même pratique. 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. Clairement, je ne m’attendais pas à être « harcelé » au bout d’une semaine. Et encore, potentiellement mon service était pris dans les filets dès son arrivée sur le web…

Faites attention à vous !

2 commentaires sur “Un serveur DNS exposé sur le web, FBI”

  1. Bonjour,
    Je ne vois pas trop l’intérêt d’héberger un résolveur DNS sur un VPS. Pour moi, Pi-Hole (ou AdGuard que j’utilise maintenant) est à installer en local, dans ton réseau, pour faire office de résolveur vers l’extérieur.
    Ainsi, tu ne rencontres pas ce genre de souci.

    1. Bonjour Guillaume,
      L’intérêt était d’avoir un serveur DNS ‘maitrisé’, puisque je ne pouvais (à l’époque) pas m’auto-héberger. Le test n’a pas été aussi concluant que prévu… 🙂
      Maintenant, c’est le cas > un AdGuard dans un docker sur un HP MicroServer et tout roule !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *