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 succincte 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 soi, 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 communiquent 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éficié 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 souci. Ne souhaitant pas afficher publiquement ce qu'il en est, voici un résumé :
- le BSI est informé des attaques mondiales, y compris les botnets.
- via 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 dit : "fake, encore un spam" ; après avoir reçu plusieurs appels provenant d'Allemagne et d'autres notifications de manière générale, je me suis dit 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 c'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 œuvre sur le web, c'est devenu très facile. Qu'importent 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équates 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 connexions 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 !
