Installer et sécuriser Webmin sur Ubuntu 24.04

Ce que vous allez mettre en place

Webmin est un panneau de contrôle web qui fournit une interface de navigateur pour administrer un serveur Linux complet : utilisateurs, paquets, tâches cron, pare-feu, Apache, BIND, disques et une centaine d’autres modules. Il est accessible en HTTPS sur le port 10000. L’installation se fait avec trois commandes et prend environ une minute. Si ce guide consacre la majeure partie de son contenu à la suite, c’est parce que Webmin se connecte en tant que root et peut effectuer toutes les opérations autorisées à root. Un Webmin ouvert à tous ou sans authentification ne constitue pas « un risque à gérer » : il permet de compromettre entièrement le serveur derrière une page de connexion. Installez-le donc en dix minutes, puis consacrez le reste de l’heure à vérifier que vous êtes la seule personne à pouvoir y accéder.

Prérequis et un avertissement important

Il vous faut un VPS KVM Ubuntu 24.04 fraîchement installé, avec root ou un utilisateur disposant de sudo. Webmin est écrit en Perl et reste léger : 1 GB de RAM suffit largement et sa consommation au repos reste nettement inférieure à un quart de gigaoctet. Il écoute sur le port TCP 10000 via son propre serveur web intégré (miniserv.pl), et non via Apache ou nginx. Rien d’autre n’a donc besoin d’être installé au préalable.

Vous devez prendre deux décisions avant de commencer. Premièrement, choisissez le compte avec lequel vous vous connecterez : Webmin s’authentifie auprès des comptes Unix via PAM. Vous vous connecterez donc en tant que root ou avec un utilisateur du groupe sudo, en utilisant le mot de passe Unix de ce compte. Les images cloud utilisent généralement une authentification par clé uniquement et aucun mot de passe n’est défini pour l’utilisateur par défaut. Webmin ne peut pas ouvrir de session avec un compte dépourvu de mot de passe. Définissez d’abord un mot de passe avec sudo passwd youruser, sinon la connexion échouera quelle que soit la valeur saisie.

Deuxièmement, et c’est l’avertissement important : n’ouvrez pas simplement le port 10000 sur Internet avant de passer à autre chose. Décidez dès maintenant si vous accéderez à Webmin via un tunnel SSH (recommandé, sans rien exposer) ou si vous limiterez l’accès à votre propre adresse IP. Cette décision détermine toutes les étapes suivantes. Lisez donc les deux options avant de modifier le firewall.

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 futures exécutions de apt upgrade installent Webmin comme n’importe quel autre paquet. Vous bénéficiez ainsi de mises à jour authentifiées au lieu d’utiliser un fichier .deb téléchargé qui ne se met jamais à jour automatiquement.

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 les opérations prévues et vous demande Setup repository? (y/N). Répondez y. Lorsqu’il a terminé, installez le paquet. L’option --install-recommends installe les dépendances courantes liées à Perl et aux modules SSL. Les modules individuels n’échoueront donc pas plus tard à cause de bibliothèques manquantes.

sudo apt-get install --install-recommends webmin

Webmin a déjà renommé ce script. Les anciens guides font référence à setup-repos.sh. Si l’URL brute renvoie une erreur 404, récupérez directement la commande actuelle sur webmin.com/download au lieu de figer un nom. Une installation correcte se termine par une ligne similaire à Webmin install complete. You can now login to https://your-host:10000/ as root. Le service est activé et démarré. Sa configuration se trouve dans /etc/webmin. Les requêtes sont journalisées dans /var/webmin/miniserv.log. Les échecs d’authentification sont envoyés à syslog ou, sur Ubuntu 24.04, au journal systemd.

Vérifiez que le service est bien démarré et qu’il écoute avant d’ouvrir un navigateur :

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

Vous devez obtenir un état active (running) ainsi qu’une ligne indiquant que miniserv.pl écoute sur 0.0.0.0:10000. Cette adresse devient 127.0.0.1:10000 lorsque vous utilisez le tunnel décrit ci-dessous. Si ss n’affiche rien sur le port 10000, Webmin n’a pas démarré. Consultez journalctl -u webmin -n 50 avant de continuer.

Première connexion et avertissement concernant le certificat

Accédez à https://YOUR_SERVER_IP:10000 avec votre navigateur. Deux choses se produisent sur une installation neuve.

Si ufw est actif, l’image serveur officielle d’Ubuntu le fournit désactivé, mais de nombreux hébergeurs l’activent par défaut, la page ne se charge pas du tout. Ce cas est traité dans les scénarios de panne ci-dessous. Si le port est ouvert, votre navigateur affiche un blocage en pleine page : « Votre connexion n’est pas privée » avec le code NET::ERR_CERT_AUTHORITY_INVALID dans Chrome, ou SEC_ERROR_UNKNOWN_ISSUER / « Avertissement : risque de sécurité potentiel » dans Firefox. C’est normal et cela ne signifie pas qu’il y a eu une intrusion. Webmin a généré un certificat auto-signé lors de l’installation (/etc/webmin/miniserv.pem). Aucune autorité de certification ne l’ayant validé, le navigateur refuse de lui faire confiance sans intervention. La connexion reste chiffrée, mais le certificat n’est pas validé par une autorité de certification. Cliquez sur Advanced, puis Proceed pour le moment. Nous remplacerons correctement ce certificat plus loin.

Connectez-vous avec root ou avec votre utilisateur sudo et son mot de passe Unix. Vous arrivez alors sur le tableau de bord System Information. Une erreur fréquente consiste à saisir http:// au lieu de https://. miniserv répond en HTTP non chiffré sur ce port avec le texte exact « This web server is running in SSL mode. Try the URL https://... ». Pour corriger le problème, il suffit de remplacer http par https dans la barre d’adresse.

La décision de sécurité : comment accéderez-vous à Webmin ?

C’est la partie importante. Un panneau avec des privilèges équivalents à ceux de root ne doit pas être exposé sur Internet et répondre aux tentatives de connexion de tous les scanners. Deux options sont défendables, par ordre de préférence. Toute interface d’administration auto-hébergée pose la même question. C’est pourquoi la sécurité de Vaultwarden dépend de son endpoint d’administration et de son fichier de sauvegarde, plutôt que de son chiffrement.

Le tunnel SSH de l’option B est préférable, car il n’expose absolument rien. L’allowlist d’adresses IP de l’option A convient si votre adresse est statique. Ne choisir aucune de ces options est précisément l’erreur que ce guide cherche à éviter. Si vous préférez accéder à Webmin via un réseau privé, placez le serveur derrière un VPN WireGuard auto-hébergé et liez Webmin à l’adresse du tunnel plutôt qu’à l’adresse publique.

Option A : restreindre Webmin à votre adresse IP

Dans le panneau, ouvrez Webmin, puis Webmin Configuration, puis IP Access Control. Sélectionnez « Only allow from listed addresses » et saisissez votre adresse IP publique. Vous pouvez l’obtenir en exécutant curl ifconfig.me sur votre ordinateur portable. Enregistrez. Webmin inscrit cette valeur sur la ligne allow= de /etc/webmin/miniserv.conf, puis redémarre.

Le piège : si votre adresse IP domestique est dynamique et change, ou si vous saisissez une mauvaise adresse, vous perdez l’accès. Le navigateur affiche alors « Access denied for <your IP> », sans formulaire de connexion. Il n’existe aucun moyen de rétablir l’accès depuis l’interface web. Corrigez le paramètre depuis la console du serveur, via SSH ou la console 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

La suppression de la ligne allow= rétablit un accès complètement ouvert. Faites-le uniquement pour récupérer l’accès, puis définissez immédiatement une valeur correcte.

Option B : lier à localhost et tunneler via SSH (recommandé)

Mieux qu’une quelconque allowlist : ne pas écouter sur l’interface publique. Configurez miniserv pour qu’il soit lié uniquement à loopback, puis accédez-y via un tunnel SSH chiffré auquel vous faites déjà confiance.

Modifiez /etc/webmin/miniserv.conf et ajoutez ou changez une ligne :

bind=127.0.0.1

Redémarrez avec sudo systemctl restart webmin. Webmin est désormais inaccessible depuis Internet, un port scan de 10000 ne trouve rien et le contrôle ss effectué précédemment indique maintenant qu’il est lié à 127.0.0.1:10000. Depuis votre laptop, ouvrez un tunnel :

ssh -L 10000:localhost:10000 youruser@YOUR_SERVER_IP

Laissez cette session ouverte et accédez à https://localhost:10000. Le trafic passe dans SSH, qui est déjà authentifié par votre key et chiffré. Vous pouvez donc accepter sans risque le certificat auto-signé ici : c’est la couche SSH qui assure réellement la protection. Fermez la session SSH et Webmin disparaît. Rien à ajouter à l’allowlist, rien d’exposé, aucun service supplémentaire à sécuriser.

Si vous définissez bind=127.0.0.1 et oubliez le tunnel, l’accès distant s’arrête simplement. C’est le fonctionnement attendu, pas une erreur. Rétablissez l’accès comme avec 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 méthode de tunneling que celle utilisée pour accéder à une machine de développement distante exécutant Claude Code dans tmux : une session SSH, tout reste privé et rien d’autre n’écoute sur l’interface publique.

Remplacer le certificat autosigné par un certificat valide

Si vous exposez Webmin sur un nom d’hôte avec l’option A, remplacez le certificat autosigné pour supprimer l’avertissement du navigateur. Vous avez besoin d’un nom DNS, par exemple panel.example.com, avec un enregistrement A qui pointe vers le serveur, ainsi que d’un service qui répond à la validation HTTP sur le port 80.

Webmin intègre cette fonction : Webmin, puis Webmin Configuration, puis SSL Encryption, puis l’onglet Let's Encrypt. Saisissez le nom d’hôte, indiquez dans « website root directory » un chemin servi sur le port 80 pour ce domaine, puis lancez la demande. Webmin obtient le certificat, met à jour les lignes certfile= et keyfile= dans miniserv.conf, puis le renouvelle automatiquement avant son expiration. Rechargez la page : le cadenas n’affiche plus d’avertissement.

Le point important est le suivant : le serveur Webmin écoute sur le port 10000, pas sur le port 80. Le challenge http-01 nécessite donc un véritable serveur web, Apache ou nginx, qui répond pour panel.example.com sur le port 80. Vous pouvez aussi utiliser une validation basée sur DNS. Sur un serveur qui n’exécute que Webmin et rien sur le port 80, la demande échoue avec une erreur de validation tant que vous ne fournissez pas à Let's Encrypt un moyen d’accéder au fichier de challenge. Le fonctionnement, les enregistrements DNS, le challenge sur le port 80 et le renouvellement sont les mêmes que pour l’émission d’un certificat destiné à un site web. Pour plus de contexte, le guide sur les certificats TLS Let's Encrypt avec Certbot et nginx décrit en détail le processus de validation et la configuration DNS. Si vous avez choisi le tunnel SSH, vous pouvez ignorer entièrement cette section : le certificat autosigné convient derrière SSH, et un véritable certificat émis pour panel.example.com provoquerait de toute façon un avertissement de non-correspondance du nom lorsque vous consulteriez https://localhost:10000.

Activer l’authentification à deux facteurs

Un mot de passe seul protège mal un panneau root. Ajoutez donc un second facteur. Ouvrez Webmin, puis Webmin Configuration, puis Two-Factor Authentication. Sélectionnez le fournisseur Google Authenticator. Il utilise le TOTP standard et fonctionne donc avec Authy, 1Password ou toute application d’authentification. Enregistrez la configuration. Webmin installe le petit module Perl nécessaire (Authen::OATH ainsi qu’un générateur de QR code) et active la fonctionnalité. Cette étape ne protège encore aucun compte.

Chaque compte doit ensuite inscrire son propre appareil. Une fois la 2FA activée, ouvrez Webmin, puis Webmin Users, sélectionnez le compte et choisissez Enable Two-Factor For User. Webmin affiche alors un QR code. Scannez-le avec l’application, puis saisissez un code généré pour confirmer. À partir de ce moment, la connexion demande le token à six chiffres après le mot de passe. Effectuez l’inscription avant de vous déconnecter. Si la 2FA est obligatoire mais que votre compte n’a jamais scanné de code, vous pouvez encore supprimer l’obligation depuis la console, mais il est bien moins contraignant de procéder d’abord à l’inscription.

Ajouter Fail2ban pour bloquer les connexions par force brute

Même un endpoint de connexion restreint doit sanctionner 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 ... lorsqu’il s’agit d’un nom d’utilisateur qui ne correspond même pas à un compte Unix. Sur Ubuntu 24.04, ces lignes arrivent dans le journal systemd, car une image standard ne contient pas /var/log/auth.log. Fail2ban fournit un filtre webmin-auth standard qui correspond exactement à ces deux lignes. La jail ci-dessous définit elle-même backend = systemd. Elle ne nécessite donc ni expression régulière personnalisée ni chemin de journal.

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

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

Rechargez la configuration avec sudo systemctl restart fail2ban, puis vérifiez que la jail est active :

sudo fail2ban-client status webmin-auth

La jail doit apparaître avec un compteur de bannissements initialisé à zéro. Avec le backend journal, aucune ligne File list: n’est présente. Pour vérifier le fonctionnement de bout en bout, provoquez volontairement plusieurs échecs de connexion depuis un autre réseau. Exécutez ensuite à nouveau la commande d’état et surveillez la progression de Currently banned. Si le compteur ne progresse jamais, vérifiez que vous ne testez pas depuis une adresse présente dans ignoreip de Fail2ban. Exécutez aussi 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 ce serveur, le guide Fail2ban sur Ubuntu 24.04 pour SSH explique l’installation et la jail SSH à exécuter en parallèle de celle-ci.

Restreindre ce que chaque utilisateur Webmin peut gérer

Toutes les personnes qui ont besoin du panneau ne doivent pas disposer des privilèges root sur l’ensemble du serveur. Dans Webmin, puis Webmin Users, créez des comptes Webmin supplémentaires et attribuez à chacun uniquement les modules nécessaires. Par exemple, un opérateur chargé des sauvegardes peut accéder uniquement aux modules cron et filesystem. La modification d’un utilisateur affiche une liste à cocher de tous les modules. Désélectionner un module le retire du menu de cet utilisateur et bloque les URL correspondantes. Il s’agit d’une mesure de défense en profondeur : même si une session Webmin disposant de faibles privilèges est volée, elle ne peut pas réécrire /etc/shadow lorsque le module Users ne figure pas dans sa liste.

Maintenir Webmin à jour

Comme vous l’avez installé depuis le dépôt apt, sudo apt update && sudo apt upgrade installe les nouvelles versions de Webmin avec le reste du système. Appliquez rapidement les correctifs, car un panneau de contrôle est une cible privilégiée. Webmin peut également se mettre à jour depuis Webmin, puis Webmin Configuration, puis Upgrade Webmin, mais la méthode avec apt est plus propre sur Ubuntu, car elle maintient des versions cohérentes avec celles gérées par les autres outils de gestion des paquets. Ne considérez pas cette opération comme facultative : plusieurs CVE concernant Webmin étaient des vulnérabilités d’exécution de code à distance, et la seule différence entre un serveur « corrigé » et un serveur « compromis » dépendait de la rapidité avec laquelle l’administrateur lançait la mise à niveau.

Modes de panne et messages affichés

« Your connection is not private » / NET::ERR_CERT_AUTHORITY_INVALID. Ce message s’affiche au tout premier chargement. Cause : le certificat autosigné généré par Webmin lors de l’installation n’a aucune autorité de certification de confiance. Il ne s’agit pas d’une attaque : le canal est chiffré, mais le certificat n’est pas validé par une autorité de confiance. Pour corriger le problème, passez provisoirement outre l’avertissement, puis générez un véritable certificat Let's Encrypt. Vous pouvez aussi accepter définitivement ce certificat si vous accédez à Webmin via un tunnel SSH.

« This web server is running in SSL mode. Try the URL https://... » Vous avez saisi http://server:10000. miniserv utilise uniquement TLS sur ce port et vous l’indique en clair. Pour corriger le problème, remplacez http par https dans la barre d’adresse.

La page expire, ERR_CONNECTION_TIMED_OUT / « This site can't be reached ». La requête n’arrive jamais jusqu’à Webmin. Sur Ubuntu, ufw bloque presque toujours le port 10000. Vérifiez avec sudo ufw status. Si 10000 n’apparaît pas, ouvrez-le avec sudo ufw allow 10000/tcp ou, de préférence, laissez-le fermé et utilisez le tunnel SSH de l’option B. Notez la différence : un timeout signifie qu’un pare-feu bloque silencieusement les paquets, tandis que ERR_CONNECTION_REFUSED signifie que le port est accessible, mais que Webmin n’est pas démarré. Vérifiez sudo systemctl status webmin.

« Access denied for <your IP>. » Vous avez configuré IP Access Control dans l’option A et votre adresse actuelle ne figure pas dans la liste des adresses autorisées. Il peut aussi s’agir d’une adresse IP dynamique qui a changé ou d’une erreur de saisie. Il n’existe aucun moyen de revenir en arrière depuis le navigateur. Pour corriger le problème depuis la console, modifiez la ligne allow= dans /etc/webmin/miniserv.conf, corrigez-la ou supprimez-la, puis exécutez sudo systemctl restart webmin.

« Login failed. Please try again. » avec des identifiants pourtant corrects. Le compte n’a pas de mot de passe Unix, ce qui est courant sur les images cloud utilisant uniquement des clés. Webmin s’authentifie via PAM à partir du mot de passe Unix, mais ce mot de passe n’existe pas pour cet utilisateur. Pour corriger le problème, exécutez sudo passwd youruser sur le serveur, puis connectez-vous. Si /var/webmin/miniserv.log affiche Non-existent login as ..., vous saisissez un nom d’utilisateur qui ne correspond pas du tout à un compte Unix.

Au-delà de quelques serveurs, l’automatisation évolue mieux qu’un panneau de contrôle installé sur chaque machine : votre premier playbook Ansible constitue le point de départ.

FAQ

Est-il sûr d’exposer Webmin sur Internet public ?

Considérez un Webmin accessible depuis Internet comme un shell root avec une page de connexion, car c’est exactement ce qu’il est. Il est suffisamment sûr uniquement avec plusieurs couches de protection : un vrai certificat, l’authentification à deux facteurs, Fail2ban et soit une liste d’adresses IP autorisées stricte, soit, mieux encore, aucune exposition publique. La configuration la moins risquée lie Webmin à 127.0.0.1 et permet d’y accéder via un tunnel SSH. Ainsi, le port 10000 ne répond à personne sur Internet public.

Comment supprimer l’avertissement de certificat Webmin ?

L’avertissement (NET::ERR_CERT_AUTHORITY_INVALID) apparaît parce que Webmin fournit 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 et un service qui répond sur le port 80 pour le challenge de validation. Si vous accédez toujours à Webmin via un tunnel SSH vers localhost, l’avertissement est sans conséquence. SSH chiffre et authentifie déjà la connexion, et vous pouvez accepter sans risque le certificat auto-signé.

Comment limiter Webmin à ma seule adresse IP ?

Accédez à Webmin, Webmin Configuration, IP Access Control, sélectionnez « Only allow from listed addresses » et saisissez votre IP publique depuis curl ifconfig.me. Webmin enregistre ce réglage dans la ligne allow= de /etc/webmin/miniserv.conf. Faites attention aux adresses IP résidentielles dynamiques : si elle change, vous serez bloqué et devrez corriger la ligne allow= depuis la console du serveur. En pratique, une adresse statique ou la méthode du tunnel SSH est donc plus fiable.

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

Webmin s’authentifie via PAM avec votre mot de passe Unix. Or les images cloud sont généralement configurées uniquement avec une clé et aucun mot de passe n’est défini pour le compte par défaut. PAM ne trouve donc aucun mot de passe correspondant et refuse la connexion. 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 en revanche que le nom d’utilisateur ne correspond pas à un véritable compte Unix.

À quoi sert Webmin par rapport à SSH classique ?

Webmin est une couche de découverte et de commodité. Il est réellement utile pour parcourir les fichiers journaux, gérer les utilisateurs et cron, modifier les règles du firewall et consulter l’état des disques et des services sans mémoriser chaque commande. Il convient notamment aux administrateurs occasionnels ou aux équipes aux compétences variées. SSH classique est plus rapide, scriptable et expose une surface d’attaque bien plus réduite pour les opérations courantes. De nombreux administrateurs utilisent les deux : SSH au quotidien et Webmin lié à localhost derrière un tunnel pour les opérations ponctuelles effectuées dans l’interface. Si votre véritable question porte sur le choix d’un panel plutôt que sur l’opposition entre panel et shell, il est utile de comparer d’abord Cockpit et Webmin, car ces deux outils diffèrent par l’étendue des modifications qu’ils peuvent réellement apporter au système et par leur méthode d’authentification.