Webmin sur Ubuntu 24.04 : installer et sécuriser

Ce que vous allez construire

Webmin est un panneau de contrôle web qui place une interface de navigateur devant tout un serveur Linux — utilisateurs, paquets, tâches cron, le pare-feu, Apache, BIND, disques, et une centaine d'autres modules — accessible en HTTPS sur le port 10000. L'installation elle-même tient en trois commandes et prend environ une minute. Si ce guide consacre la plus grande partie de sa longueur à la seconde moitié, c'est que Webmin se connecte en tant que root et peut faire tout ce que root peut faire. Un Webmin grand ouvert ou non authentifié n'est pas « un risque à gérer » ; c'est une compromission complète du serveur avec une page de connexion devant. Alors installez-le en dix minutes, puis passez le reste de l'heure à vous assurer que vous seul pouvez l'atteindre.

Prérequis et un avertissement honnête

Un VPS KVM Ubuntu 24.04 tout neuf avec root ou un utilisateur sudo. Webmin est écrit en Perl et léger — 1 Go de RAM suffit largement et il tourne au repos bien en dessous d'un quart de gigaoctet. Il écoute sur le port TCP 10000 via son propre serveur web intégré (miniserv.pl), pas Apache ni nginx, donc rien d'autre n'a besoin d'être installé au préalable.

Deux choses à décider avant de commencer. D'abord, le compte avec lequel vous vous connectez : Webmin s'authentifie auprès des comptes Unix via PAM, donc vous vous connectez en tant que root ou en tant qu'utilisateur du groupe sudo en utilisant le mot de passe Unix de ce compte. Les images cloud sont généralement uniquement par clé, sans mot de passe défini sur l'utilisateur par défaut, et Webmin ne peut pas connecter un compte sans mot de passe. Définissez un mot de passe avec sudo passwd youruser d'abord, sinon la connexion échouera quoi que vous tapiez.

Deuxièmement, et voici l'avertissement : n'ouvrez pas simplement le port 10000 sur internet pour ensuite l'oublier. Décidez dès maintenant si vous atteindrez Webmin via un tunnel SSH (recommandé, rien d'exposé) ou si vous le restreindrez à votre propre IP. Cette seule décision façonne chaque étape ci-dessous, alors lisez les deux options avant de toucher au pare-feu.

Installer Webmin depuis le dépôt officiel

Webmin publie un dépôt apt signé. Le script d'installation ajoute le dépôt et sa clé de signature GPG afin que les futurs apt upgrade récupèrent Webmin comme n'importe quel autre paquet, et vous obtenez des mises à jour authentifiées au lieu d'un .deb téléchargé qui ne se corrige jamais lui-même.

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

Le script affiche ce qu'il s'apprête à faire et demande Setup repository? (y/N) — répondez y. Une fois terminé, installez le paquet. L'option --install-recommends récupère les dépendances Perl et SSL courantes afin que les modules individuels n'échouent pas plus tard avec des erreurs de bibliothèque manquante.

sudo apt-get install --install-recommends webmin

Webmin a déjà renommé ce script auparavant — les guides plus anciens font référence à setup-repos.sh — donc si l'URL brute renvoie une erreur 404, récupérez la ligne actuelle directement depuis webmin.com/download plutôt que de figer un nom. Une installation correcte se termine par une ligne comme Webmin install complete. You can now login to https://your-host:10000/ as root. Le service est activé et en cours d'exécution, la configuration se trouve sous /etc/webmin, les requêtes sont journalisées dans /var/webmin/miniserv.log, et les connexions échouées vont dans syslog — sur Ubuntu 24.04, le journal systemd.

Confirmez qu'il est bien actif et à l'écoute avant d'ouvrir un navigateur :

sudo systemctl status webmin --no-pager
sudo ss -tlnp | grep 10000

Vous voulez un statut active (running) et une ligne montrant miniserv.pl lié à 0.0.0.0:10000 — cette adresse devient 127.0.0.1:10000 une fois que vous prenez la route du tunnel ci-dessous. Si ss n'affiche rien sur 10000, Webmin n'a pas démarré ; lisez journalctl -u webmin -n 50 avant d'aller plus loin.

Première connexion, et l'avertissement de certificat

Pointez votre navigateur vers https://YOUR_SERVER_IP:10000. Deux choses se produisent sur une machine fraîche.

Si ufw est actif — l'image serveur d'Ubuntu elle-même le livre inactif, mais de nombreux fournisseurs l'activent au préalable — la page ne se chargera pas du tout, ce qui est traité dans les modes de défaillance ci-dessous. Si le port est ouvert, votre navigateur affiche un blocage pleine page : « Votre connexion n'est pas privée » avec le code NET::ERR_CERT_AUTHORITY_INVALID dans Chrome, ou SEC_ERROR_UNKNOWN_ISSUER / « Attention : risque probable de sécurité » dans Firefox. C'est attendu et ce n'est pas une intrusion. Webmin a généré un certificat auto-signé au moment de l'installation (/etc/webmin/miniserv.pem), et parce qu'aucune autorité de certification ne se porte garante pour lui, le navigateur refuse de lui faire confiance en silence. La connexion est toujours chiffrée ; elle n'est simplement pas cautionnée. Passez outre (Avancé, puis Continuer) pour l'instant — nous remplacerons ce certificat correctement plus bas.

Connectez-vous avec root ou votre utilisateur sudo et son mot de passe Unix, et vous arrivez sur le tableau de bord Informations système. Une erreur courante ici est de taper http:// au lieu de https://. miniserv répond en HTTP simple sur ce port avec le texte exact « This web server is running in SSL mode. Try the URL https://... » — la correction consiste littéralement à changer http en https dans la barre d'adresse.

La décision de sécurité : comment allez-vous atteindre Webmin ?

Maintenant la partie qui compte. Un panneau équivalent à root ne devrait pas se trouver sur internet ouvert à répondre aux tentatives de connexion de chaque scanner de la planète. Vous avez deux options défendables, par ordre de préférence.

Le tunnel SSH de l'option B est la meilleure, car elle n'expose absolument rien. La liste d'IP autorisées de l'option A est acceptable si votre adresse est statique. Ne faire ni l'un ni l'autre est exactement l'erreur que tout ce guide existe pour prévenir. Si vous préférez atteindre Webmin via un réseau privé plutôt que l'une ou l'autre, placez la machine derrière un VPN WireGuard auto-hébergé et liez Webmin à l'adresse du tunnel au lieu de l'adresse publique.

Option A : restreindre Webmin à votre IP

Dans le panneau, ouvrez Webmin, puis Webmin Configuration, puis IP Access Control. Choisissez « Only allow from listed addresses » et saisissez votre IP publique, que vous pouvez trouver en exécutant curl ifconfig.me sur votre ordinateur portable. Enregistrez. Webmin écrit ceci dans la ligne allow= de /etc/webmin/miniserv.conf et se redémarre.

Le piège : si votre IP domestique est dynamique et change, ou si vous saisissez mal l'adresse, vous vous verrouillez dehors. Le navigateur affiche alors « Access denied for <your IP> » et aucun formulaire de connexion, et il n'y a aucun chemin de retour par le web. Vous corrigez cela depuis la console du serveur via SSH ou le VNC de votre fournisseur :

sudo nano /etc/webmin/miniserv.conf
# find the line that begins  allow=
# correct your IP, or delete the whole line to allow all again
sudo systemctl restart webmin

Supprimer la ligne allow= restaure un accès entièrement ouvert, donc ne faites cela que pour récupérer l'accès, puis définissez immédiatement une valeur correcte.

Option B : lier à localhost et créer un tunnel via SSH (recommandé)

Mieux que n'importe quelle liste d'autorisation, il vaut mieux ne pas écouter du tout sur l'interface publique. Dites à miniserv de ne se lier qu'à la boucle locale, puis atteignez-le via un tunnel SSH chiffré auquel vous faites déjà confiance.

Éditez /etc/webmin/miniserv.conf et ajoutez, ou modifiez, une ligne :

bind=127.0.0.1

Redémarrez avec sudo systemctl restart webmin. Webmin est désormais inaccessible depuis internet — un balayage de ports sur 10000 ne trouve rien, et la vérification ss d'avant le montre maintenant lié à 127.0.0.1:10000. Depuis votre ordinateur portable, ouvrez un tunnel :

ssh -L 10000:localhost:10000 youruser@YOUR_SERVER_IP

Laissez cette session ouverte et naviguez vers https://localhost:10000. Le trafic circule à l'intérieur de SSH, qui est déjà authentifié par votre clé et chiffré, vous pouvez donc accepter en toute sécurité le certificat auto-signé ici — la couche SSH assure la vraie protection. Fermez la session SSH et Webmin disparaît. Rien à autoriser, rien d'exposé, aucun service supplémentaire à durcir.

Si vous définissez bind=127.0.0.1 et oubliez le tunnel, l'accès distant s'arrête simplement — c'est la fonctionnalité qui marche, pas une panne. Récupérez de la même manière que l'option A : depuis la console, supprimez la ligne bind ou définissez bind=0.0.0.0, puis redémarrez. C'est la même habitude de tunnel que vous utiliseriez pour atteindre une machine de développement distante exécutant Claude Code dans tmux — une seule session SSH, tout est privé, rien de plus à l'écoute sur l'interface publique.

Remplacer le certificat auto-signé par un vrai

Si vous exposez Webmin sur un nom d'hôte sous l'option A, débarrassez-vous de l'avertissement du navigateur avec un vrai certificat Let's Encrypt. Vous avez besoin d'un nom DNS — disons panel.example.com — avec un enregistrement A pointant vers le serveur, et de quelque chose qui répond au défi HTTP du port 80 pendant la validation.

Webmin intègre cela : Webmin, puis Webmin Configuration, puis SSL Encryption, puis l'onglet Let's Encrypt. Saisissez le nom d'hôte, pointez le « website root directory » vers un chemin servi sur le port 80 pour ce domaine, et demandez. Webmin obtient le certificat, met à jour les lignes certfile= et keyfile= dans miniserv.conf pour vous, et le renouvelle automatiquement avant son expiration. Rechargez la page et le cadenas est propre.

Le seul accroc honnête : le serveur propre de Webmin tourne sur 10000, pas sur 80, donc le défi http-01 a besoin d'un vrai serveur web — Apache ou nginx — répondant pour panel.example.com sur le port 80, ou d'une validation basée sur DNS à la place. Sur une machine dédiée à Webmin sans rien sur le port 80, la demande échoue avec une erreur de validation jusqu'à ce que vous donniez à Let's Encrypt un moyen d'atteindre le fichier de défi. Les mécanismes — enregistrements DNS, le défi du port 80, et le renouvellement — sont les mêmes que pour l'émission d'un certificat pour n'importe quel site web. Si vous voulez ce contexte, le guide des certificats TLS Let's Encrypt avec Certbot et nginx détaille le flux de validation et la configuration DNS. Si vous avez pris la route du tunnel SSH, vous pouvez sauter entièrement cette section : le certificat auto-signé convient derrière SSH, et un vrai certificat émis pour panel.example.com ne produirait de toute façon qu'un avertissement de non-correspondance de nom lorsque vous visitez https://localhost:10000.

Activer l'authentification à deux facteurs

Un mot de passe seul est une protection mince pour un panneau root, alors ajoutez un second facteur (2FA). Ouvrez Webmin, puis Webmin Configuration, puis Two-Factor Authentication. Sélectionnez le fournisseur Google Authenticator — c'est du TOTP standard, donc il fonctionne avec Authy, 1Password, ou toute application d'authentification — et enregistrez. Webmin installe le petit module Perl dont il a besoin (Authen::OATH plus un générateur de QR) et active la fonctionnalité ; cette étape seule ne protège encore aucun compte.

Chaque compte enregistre ensuite son propre appareil. Avec la 2FA activée, ouvrez Webmin, puis Webmin Users, choisissez le compte, sélectionnez Enable Two-Factor For User, et Webmin affiche un code QR ; scannez-le avec l'application et saisissez un code généré pour confirmer. À partir de là, la connexion demande le jeton à six chiffres après le mot de passe. Enregistrez-vous avant de vous déconnecter — si la 2FA est requise mais que votre compte n'a jamais scanné de code, vous pouvez toujours effacer l'exigence depuis la console, mais c'est bien moins pénible de s'enregistrer d'abord.

Ajouter Fail2ban pour bannir les connexions par force brute

Même un point de connexion restreint devrait punir les échecs répétés. Webmin signale les connexions échouées à syslog sous la forme webmin[12345]: Invalid login as root from 10.0.0.9, ou Non-existent login as ... pour un nom d'utilisateur qui n'est même pas un compte Unix — sur Ubuntu 24.04, ces lignes atterrissent dans le journal systemd, puisqu'une image standard n'a pas de /var/log/auth.log. Fail2ban livre un filtre webmin-auth standard qui correspond exactement à ces deux lignes, et la prison ci-dessous définit elle-même backend = systemd, donc elle n'a besoin d'aucune regex ni chemin de log personnalisé.

Créez /etc/fail2ban/jail.d/webmin.local :

[webmin-auth]
enabled  = true
port     = 10000
filter   = webmin-auth
backend  = systemd
maxretry = 4
bantime  = 1h

Rechargez avec sudo systemctl restart fail2ban, puis confirmez que la prison est active :

sudo fail2ban-client status webmin-auth

Vous devriez voir la prison listée avec un compteur de bannissements à zéro au départ (sur le backend journal, il n'y a pas de ligne File list:). Pour prouver le câblage de bout en bout, échouez une connexion exprès quelques fois depuis un autre réseau, puis relancez la commande de statut et regardez Currently banned grimper. Si cela n'arrive jamais, assurez-vous que vous ne testez pas depuis une adresse dans l'ignoreip de Fail2ban, et exécutez journalctl SYSLOG_IDENTIFIER=webmin sur le serveur pour confirmer que les lignes Invalid login sont bien écrites. Si Fail2ban n'est pas encore installé sur cette machine, le guide Fail2ban sur Ubuntu 24.04 pour SSH couvre l'installation et la prison SSH que vous devriez exécuter juste à côté de celle-ci.

Restreindre ce que chaque utilisateur Webmin peut toucher

Tout le monde qui a besoin du panneau n'a pas besoin de root sur tout. Sous Webmin, puis Webmin Users, créez des connexions Webmin supplémentaires et n'accordez à chacune que les modules dont elle a besoin — un opérateur de sauvegardes qui ne voit que les modules cron et système de fichiers, par exemple. La modification d'un utilisateur affiche une liste de contrôle de chaque module ; décocher l'un le retire du menu de cet utilisateur et bloque les URL sous-jacentes. C'est de la défense en profondeur : même une session Webmin à faible privilège volée ne peut pas réécrire /etc/shadow quand le module Users n'est pas dans sa liste.

Maintenir Webmin à jour

Parce que vous avez installé depuis le dépôt apt, sudo apt update && sudo apt upgrade récupère les nouvelles versions de Webmin en même temps que le reste du système. Corrigez rapidement — un panneau de contrôle est une cible de choix. Webmin peut aussi se mettre à jour lui-même depuis Webmin, puis Webmin Configuration, puis Upgrade Webmin, mais la voie apt est plus propre sur Ubuntu car elle garde les versions cohérentes avec le reste de votre gestion de paquets. Ne considérez pas cela comme optionnel : plusieurs CVE passées de Webmin étaient des bugs d'exécution de code à distance, et la seule chose entre « corrigé » et « compromis » était la vitesse à laquelle l'administrateur a lancé la mise à jour.

Modes de défaillance, avec les messages que vous verrez

« Votre connexion n'est pas privée » / NET::ERR_CERT_AUTHORITY_INVALID. Affiché au tout premier chargement. Cause : le certificat auto-signé que Webmin a généré à l'installation n'a aucun émetteur de confiance. Ce n'est pas une attaque ; le canal est chiffré, juste pas cautionné. Correction : passez outre l'avertissement pour l'instant, puis émettez un vrai certificat Let's Encrypt, ou acceptez-le définitivement si vous atteignez Webmin via un tunnel SSH.

« This web server is running in SSL mode. Try the URL https://... » Vous avez tapé http://server:10000. miniserv ne parle que TLS sur ce port et vous le dit en clair. Correction : changez http en https dans la barre d'adresse.

La page expire — ERR_CONNECTION_TIMED_OUT / « Ce site est inaccessible ». La requête n'arrive jamais à Webmin. Sur Ubuntu, c'est presque toujours ufw qui bloque le port 10000. Confirmez avec sudo ufw status ; si 10000 n'est pas listé, soit ouvrez-le avec sudo ufw allow 10000/tcp, soit, mieux, laissez-le fermé et utilisez le tunnel SSH de l'option B. Notez la distinction : un délai d'expiration signifie qu'un pare-feu rejette silencieusement les paquets, tandis que ERR_CONNECTION_REFUSED signifie au contraire que le port est joignable mais que Webmin ne tourne pas — vérifiez sudo systemctl status webmin.

« Access denied for <your IP> ». Vous avez configuré IP Access Control sous l'option A et votre adresse actuelle n'est pas dans la liste d'autorisation — une IP dynamique qui a changé, ou une faute de frappe. Il n'y a pas de chemin de retour par le navigateur. Corrigez depuis la console : éditez la ligne allow= dans /etc/webmin/miniserv.conf, corrigez-la ou supprimez-la, et exécutez sudo systemctl restart webmin.

« Login failed. Please try again. » avec des identifiants que vous savez corrects. Le compte n'a pas de mot de passe Unix, ce qui est standard sur les images cloud uniquement par clé. Webmin s'authentifie via PAM contre le mot de passe Unix, et ce mot de passe n'existe pas pour l'utilisateur. Correction : exécutez sudo passwd youruser sur le serveur, puis connectez-vous. Si /var/webmin/miniserv.log affiche Non-existent login as ..., vous tapez un nom d'utilisateur qui n'est pas du tout un compte Unix.

Pour plus de quelques serveurs, l'automatisation passe mieux à l'échelle qu'un panneau de contrôle sur chaque machine : votre premier playbook Ansible est là que cela commence.

FAQ

Est-il sûr d'exposer Webmin sur internet public ?

Traitez un Webmin exposé sur internet comme un shell root avec une page de connexion, car c'est exactement ce que c'est. Il n'est suffisamment sûr qu'en couches : un vrai certificat, l'authentification à deux facteurs, Fail2ban, et soit une liste d'IP autorisées stricte soit, mieux, aucune exposition publique du tout. La configuration la moins risquée lie Webmin à 127.0.0.1 et l'atteint via un tunnel SSH, de sorte que le port 10000 ne répond à personne sur internet ouvert.

Comment me débarrasser de l'avertissement de certificat de Webmin ?

L'avertissement (NET::ERR_CERT_AUTHORITY_INVALID) apparaît parce que Webmin livre un certificat auto-signé. Émettez-en un vrai depuis Webmin, Webmin Configuration, SSL Encryption, Let's Encrypt, en utilisant un nom DNS qui pointe vers le serveur avec quelque chose qui sert le défi du port 80 pour la validation. Si vous n'atteignez jamais Webmin que via un tunnel SSH vers localhost, l'avertissement est inoffensif — SSH chiffre et authentifie déjà la connexion — et vous pouvez accepter en toute sécurité le certificat auto-signé.

Comment restreindre Webmin à ma seule adresse IP ?

Allez dans Webmin, Webmin Configuration, IP Access Control, choisissez « Only allow from listed addresses », et saisissez votre IP publique depuis curl ifconfig.me. Webmin stocke ceci dans la ligne allow= de /etc/webmin/miniserv.conf. Méfiez-vous d'une IP domestique dynamique : si elle change vous êtes verrouillé dehors et devez réparer la ligne allow= depuis la console du serveur, donc une adresse statique ou la méthode du tunnel SSH est plus fiable en pratique.

Pourquoi ma connexion échoue-t-elle même avec le bon mot de passe ?

Webmin s'authentifie via PAM contre votre mot de passe Unix, et les images cloud sont généralement uniquement par clé sans mot de passe défini sur le compte par défaut — il n'y a donc rien à faire correspondre pour PAM et la connexion est rejetée. Exécutez sudo passwd youruser sur le serveur pour en définir un, puis connectez-vous. Une ligne Non-existent login as ... dans /var/webmin/miniserv.log signifie au contraire que le nom d'utilisateur lui-même n'est pas un vrai compte Unix.

À quoi Webmin est-il utile par rapport à SSH simple ?

Webmin est une couche de découvrabilité et de confort. Il est vraiment utile pour parcourir les fichiers de log, gérer les utilisateurs et cron, éditer les règles du pare-feu, et voir l'état des disques et des services sans mémoriser chaque commande — pratique pour les administrateurs occasionnels ou les équipes de compétences mixtes. SSH simple est plus rapide, scriptable, et expose bien moins de surface d'attaque pour le travail de routine. Beaucoup d'administrateurs utilisent les deux : SSH pour la conduite quotidienne, et Webmin lié à localhost derrière un tunnel pour le travail occasionnel en pointer-cliquer.