Mettre en place un serveur Debian administrable avec Webmin

Quand on monte un nouveau serveur, les premières heures sont toujours les mêmes : on durcit la machine, on crée un utilisateur correct, on coupe ce qui traîne, et on met en place de quoi l'administrer sans avoir à ouvrir un terminal pour chaque détail. Cet article décrit la procédure que j'utilise sur mes Debian fraîches : préparation via mes scripts, installation de Webmin, et activation de firewalld pour ne laisser passer que ce qui doit l'être.

L'idée n'est pas de transformer le serveur en sapin de Noël, mais d'avoir une base saine sur laquelle bâtir, qu'il s'agisse d'expérimenter dans un LXC ou de préparer une VM destinée à recevoir une vraie charge.

Étape 1 — Préparer la machine

Sur une Debian neuve, on commence par récupérer un petit script qui en télécharge d'autres. C'est juste un point d'entrée : il va chercher dans mon dépôt Forgejo un ensemble de scripts d'initialisation que je maintiens à jour.

wget -O fetch_scripts.sh https://git.abonnel.fr/cedricAbonnel/notes-techniques/raw/branch/main/scripts/fetch_scripts.sh
chmod +x fetch_scripts.sh
./fetch_scripts.sh

À ce stade, un dossier common/ apparaît à côté du script. C'est là que se trouve le vrai travail :

cd common/
./setup_debian.sh

setup_debian.sh fait ce qu'on a tous fini par écrire un jour : mise à jour des paquets, installation des outils de base, création d'un utilisateur non-root avec les bons droits sudo, durcissement minimal de SSH. Rien de magique, mais c'est répétable et c'est ce qui compte quand on provisionne souvent.

Important : une fois le script terminé, il faut se déconnecter de la session root et se reconnecter avec l'utilisateur que le script vient de créer. Tout ce qui suit se fait avec cet utilisateur, en passant par sudo quand nécessaire. Continuer en root est une mauvaise habitude qui finit toujours par se payer.

Étape 2 — Installer Webmin

Webmin est une interface web d'administration système. Pour quelqu'un qui débute, c'est une porte d'entrée appréciable : on voit les services qui tournent, les utilisateurs, les paquets installés, les logs, le tout depuis un navigateur. Pour quelqu'un d'expérimenté, c'est un complément pratique quand on veut donner un accès limité à un collègue moins à l'aise en ligne de commande.

Webmin fournit son propre script pour configurer le dépôt apt :

curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh

Ce script ajoute le dépôt officiel Webmin à la liste des sources apt et importe la clé GPG associée. Une fois fait, l'installation devient une commande apt classique :

sudo apt-get install webmin usermin --install-recommends

Petite précision sur les deux paquets : Webmin sert à l'administration système (root ou utilisateur sudo), Usermin est sa version pour les utilisateurs standards, qui leur permet de gérer leur propre compte, leurs mails, leurs fichiers, sans toucher au système. Sur une machine mono-utilisateur, on peut se passer d'Usermin, mais l'installer maintenant coûte trois mégaoctets et évite d'y revenir plus tard.

Étape 3 — Se connecter à l'interface

Webmin écoute par défaut sur le port 10000 en HTTPS. Depuis un navigateur :

https://<ip-du-serveur>:10000

<ip-du-serveur> est à remplacer par l'adresse de la machine. Le navigateur va râler à propos du certificat — c'est normal, Webmin génère un certificat auto-signé à l'installation. On peut accepter l'avertissement pour l'instant ; si la machine est destinée à un usage durable, on remplacera ça plus tard par un vrai certificat (Let's Encrypt via un reverse proxy, par exemple).

Pour la connexion, on utilise les identifiants Linux de l'utilisateur sudo, pas un compte spécifique à Webmin. C'est l'utilisateur que setup_debian.sh a créé à l'étape 1. Webmin s'appuie sur PAM, donc tout compte système autorisé à se connecter peut potentiellement entrer — d'où l'importance de l'étape suivante.

Étape 4 — Activer le pare-feu

Une machine accessible sur internet sans pare-feu, c'est une question de temps avant les premiers ennuis. Sur Debian, je préfère firewalld à ufw ou à la configuration brute de nftables : la notion de zones est pratique, la syntaxe se retient, et l'intégration avec Webmin est correcte.

Installation et activation :

sudo apt update
sudo apt install firewalld
sudo systemctl enable firewalld
sudo systemctl start firewalld

enable rend le service persistant au redémarrage, start le lance immédiatement. Vérification :

sudo firewall-cmd --state

Le retour attendu est running. Si c'est autre chose, systemctl status firewalld permet de comprendre ce qui coince — c'est souvent un conflit avec un autre service de filtrage déjà en place.

À ce stade, le pare-feu tourne mais avec une configuration par défaut qui, selon la zone active, peut bloquer Webmin. Il faut donc explicitement autoriser le port 10000 :

sudo firewall-cmd --add-port=10000/tcp --permanent
sudo firewall-cmd --reload

Le --permanent écrit la règle dans la configuration ; sans ça, elle disparaît au prochain redémarrage. Le reload recharge la configuration pour que la règle prenne effet immédiatement. C'est l'erreur classique : on ajoute une règle, on continue à ne pas pouvoir se connecter, on perd dix minutes avant de se rappeler du reload.

Pour aller plus loin

Une fois cette base en place, plusieurs directions s'offrent selon le rôle de la machine.

Si elle est destinée à héberger un service web public, l'étape logique suivante consiste à placer Webmin derrière un reverse proxy plutôt que de l'exposer directement sur le port 10000. Le port 10000 est alors fermé vers l'extérieur, et l'interface devient accessible via un sous-domaine en HTTPS avec un vrai certificat. C'est plus propre, plus sûr, et ça évite l'avertissement de certificat à chaque connexion.

Si la machine est un serveur d'applications, autant profiter du fait que firewalld est en place pour réfléchir aux ports en amont. Mieux vaut décider tout de suite quelles applications écoutent où, plutôt que d'empiler les --add-port au fil de l'eau et de finir avec une configuration que plus personne ne comprend.

Et dans tous les cas, garder une trace écrite des choix faits : quels ports ouverts, quel utilisateur sudo, quelle convention de nommage. Un fichier README.md à la racine du home de l'admin, peu importe le support — l'important c'est que dans six mois, on puisse retrouver le fil sans avoir à tout rétro-ingénierer.