Name: Tremplin Numérique
Price range: $$$

J'écris souvent sur les meilleures pratiques des homelabbers, mais je ne suis pas toujours mes propres conseils. Cela m'a frappé récemment lorsque mon homelab a été compromis et qu'un robot cryptographique a commencé à exécuter le processeur de mon serveur à 100 %. Voici ce que j'ai fait pour le réparer.

Sommaire

J'avais l'habitude d'ouvrir presque tous les services auto-hébergés sur Internet avec un proxy inverse

Cela a facilité l'accès à distance, d'accord ?

Il y a quelques années, je suis parti en voyage loin de mon laboratoire personnel. J'avais un VPN configuré sur un Raspberry Pi 3b et certains services étaient en panne et je devais les réparer. Mon VPN était lent et lent (grâce au port 10/100 Mbps du Pi 3b) et cela rendait les choses insupportables pour essayer de réparer les services.

J'ai donc décidé d'utiliser le temps pendant lequel j'étais VPN sur le serveur pour inverser tout ce qui se trouvait sur le réseau. Cela simplifierait l'accès à distance à l'un des services auto-hébergés que je devais gérer si je n'étais pas chez moi. Un autre avantage était que même à la maison, je pouvais accéder plus facilement aux services car ils auraient tous un FQDN (nom de domaine pleinement qualifié).

Le problème est que de nombreux amateurs font la même erreur. Une fois que Nginx Proxy Manager ou Cloudflare Tunnels est configuré, il est facile de rendre chaque service disponible en dehors du réseau en quelques clics. Avoir un accès externe à ces services est pratique, mais ce n'est certainement pas le bon choix, comme je l'ai découvert.

Ces jours-ci, Tailscale est installé sur la plupart de mes appareils, et cela fonctionne sur mon serveur avec une connexion LAN de 2,5 Gb/s et une connexion WAN de 1 Gb/s. Le problème est que j'ai encore beaucoup de mes services derrière mon proxy inverse, car s'il n'est pas en panne… eh bien, il est en panne.

Un conteneur qBittorrent réinstallé a été ma chute

J'ai changé de conteneur et j'ai oublié de réinitialiser le mot de passe… oups

J'ai récemment parcouru tout mon homelab, déplaçant les services d'un nœud à un autre et réinstallant les services pour les rendre plus robustes – qBittorrent était l'un de ces services.

J'ai déplacé la plupart des informations de configuration pour qBittorrent lorsque je passe à un nouveau conteneur. Le problème est que je n'ai pas défini de mot de passe pour cela. Cela fait si longtemps que je n'ai pas déployé un nouveau conteneur qBittorrent pour la dernière fois que j'ai complètement oublié qu'il avait généré un mot de passe dans les journaux et défini le nom d'utilisateur sur admin. Honnêtement, je pensais que déplacer mes fichiers de configuration déplacerait mon utilisateur/mot de passe de l'ancien serveur vers le nouveau serveur – j'avais tort.

Ce que je ne savais pas, c'est qu'il existe des botnets qui fouillent activement Internet à la recherche d'interfaces utilisateur Web d'administration qBittorrent exposées à utiliser par force brute. Je n'en ai jamais été la proie auparavant, car je n'utilisais pas admin comme nom d'utilisateur et mon mot de passe comportait 48 caractères et était généré aléatoirement.

Cependant, le nouveau conteneur avait un mot de passe de huit caractères et utilisait le nom d'utilisateur admin, et c'est de là que venait mon problème. Même s’il s’agissait d’un mot de passe généré aléatoirement, il ne contenait que huit caractères, ce qui est relativement facile à utiliser par force brute pour les botnets. Ainsi, avec le nom d'utilisateur admin et un mot de passe facilement cassable, mon instance qBittorrent a été compromise et un botnet s'y trouvait.

Une fois dans l'instance qBittorrent, le botnet a téléchargé un torrent de test pour s'assurer qu'il disposait des autorisations dont il avait besoin, puis il s'est éteint : un mineur de crypto s'est rapidement mis au travail sur le serveur et a commencé à associer mes cœurs de processeur à 100 %. C'est à ce moment-là que j'ai réalisé ce qui se passait et j'ai commencé à travailler pour y remédier.

C'est une erreur facile à commettre, mais les conséquences peuvent être graves

Heureusement, la solution n'était pas si difficile, mais je n'aurais pas dû avoir à le faire en premier lieu

Mon client qBittorrent fonctionne sur mon serveur monté en rack Lenovo RD440, qui est tout sauf silencieux. Normalement, il fait plutôt frais, mon bureau reste frais grâce à un climatiseur monté sur la fenêtre, et il n'y a pas beaucoup de stress, donc les ventilateurs ne tournent jamais vraiment. Cependant, le mineur de crypto-monnaie fonctionnant à 100 % de l'utilisation du processeur sur les deux processeurs Xeon a transformé le serveur normalement à faible bruit en un moteur à réaction.

Cela m'a fait plonger instantanément dans le système pour voir ce qui se passait. J'ai pu trouver le processus erroné et le tuer, puis je suis entré dans mon client qBittorrent et j'ai changé le mot de passe. À partir de là, je pensais que j'étais en sécurité, mais j'ai raté le torrent parasite téléchargé par le botnet, ainsi que la modification apportée à ma configuration qBittorrent.

Finalement, j'ai réinstallé le conteneur qBittorrent à partir de zéro et j'ai ramené tous mes états ISO là où ils se trouvaient auparavant, et le piratage était terminé. J'ai passé une heure ou deux à essayer de comprendre ce qui se passait et comment y remédier, mais j'ai finalement repris le contrôle.

Mon homelab n'est sécurisé que dans la mesure où je le fais – et je l'ai rendu assez non sécurisé

Je travaille toujours pour tout reprendre sous contrôle après cette petite aventure, mais cela m'a montré certaines choses. Ce n’est pas parce que je n’ai subi aucune faille de sécurité depuis plus de cinq ans que je dirige mon homelab que je n’aurai jamais de faille de sécurité.

Les meilleures pratiques pour un homelab sont des bonnes pratiques pour une raison, et placer chaque service derrière un proxy inverse accessible en externe n'est certainement pas une bonne pratique.

Je vais prendre les prochaines semaines pour vraiment renforcer la sécurité de mon homelab et déplacer les services des noms de domaine externes vers des noms de domaine proxy inverse internes et faire en sorte que je doive utiliser un VPN pour y accéder à nouveau. Tailscale sur un système plus rapide est beaucoup plus réactif que mon ancien VPN sur mon Pi, et il est temps que je déplace correctement les services comme ils doivent l'être.