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

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 demande Setup Webmin stable repository? (y/N). Répondez y. À la fin, installez le paquet. L’option --install-recommends installe les dépendances courantes liées à Perl et aux modules SSL. Les modules individuels ne rencontreront ainsi pas plus tard d’erreurs liées à des 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 la commande actuelle directement depuis 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 en cours d’exécution. La configuration se trouve sous /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 qu’il 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) et une ligne indiquant que miniserv.pl est lié à 0.0.0.0:10000. Cette adresse devient 127.0.0.1:10000 lorsque vous utilisez le tunnel présenté plus bas. Si ss n’affiche rien sur le port 10000, Webmin n’a pas démarré. Consultez journalctl -u webmin -n 50 avant de poursuivre.

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 avec l’option A, remplacez le certificat autosigné pour supprimer l’avertissement du navigateur. Vous avez besoin d’un nom pour le certificat et d’un moyen permettant à Let's Encrypt d’atteindre le port 80 pendant la validation. Il s’agit généralement d’un nom DNS, par exemple panel.example.com, avec un enregistrement A qui pointe vers le serveur. Depuis Webmin 2.650 (publié le 25 juin 2026), il peut également s’agir de l’adresse IP publique du serveur, à condition que Certbot 5.3 ou une version ultérieure soit installé. Let's Encrypt émet les certificats IP uniquement avec son profil à courte durée de validité, valable environ six jours. Définissez donc l’intervalle de renouvellement automatique de Webmin en jours ; Webmin n’acceptera pas un intervalle plus long pour un certificat IP.

Cette fonction est intégrée à Webmin : Webmin, puis Webmin Configuration, puis SSL Encryption, puis l’onglet Let's Encrypt. Saisissez le nom d’hôte ou l’adresse IP, choisissez une méthode de validation, 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 ne présente plus d’avertissement.

Le seul point à prévoir est le suivant : le serveur intégré de Webmin écoute sur le port 10000, et non sur le port 80. Un autre service doit donc répondre au challenge http-01 sur le port 80. Trois solutions sont possibles. Si Apache ou nginx sert déjà le nom sur le port 80, indiquez le répertoire des documents de ce site pour la validation (pour une adresse IP, Certbot 5.4 ou une version ultérieure est nécessaire). Si aucun service n’écoute sur le port 80, choisissez le serveur web intégré de Certbot, c’est-à-dire le mode standalone ajouté par Webmin dans la version 2.110 : Certbot démarre temporairement son propre serveur web sur le port 80. Certbot doit donc être installé, et le port 80 doit être libre et autorisé dans votre pare-feu. Vous pouvez aussi utiliser la validation DNS, qui fonctionne pour les noms d’hôte, mais pas pour les adresses IP. Le paquet certbot fourni par Ubuntu 24.04 est en version 2.9. Cette version convient à la validation standalone d’un nom d’hôte, mais elle est trop ancienne pour les certificats IP. Pour ces derniers, installez une version récente de Certbot, par exemple le snap, qui était en version 5.8 en octobre 2026. Sans aucune de ces solutions, la demande échoue avec une erreur de validation. 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 le contexte, le guide sur les certificats TLS Let's Encrypt avec Certbot et nginx explique en détail le déroulement de la validation et la configuration DNS. Si vous avez choisi la solution avec tunnel SSH, vous pouvez ignorer entièrement cette section : le certificat autosigné convient derrière SSH, et un certificat valide émis pour panel.example.com provoquerait de toute façon un avertissement de nom non concordant lorsque vous accédez à 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 d’échec et messages affichés

« Your connection is not private » / NET::ERR_CERT_AUTHORITY_INVALID. Ce message s’affiche lors du tout premier chargement. Cause : le certificat autosigné généré par Webmin lors de l’installation n’a pas d’autorité de certification approuvée. Il ne s’agit pas d’une attaque : le canal est chiffré, mais son identité n’est pas authentifiée. Pour corriger le problème, ignorez temporairement l’avertissement, puis obtenez un certificat Let’s Encrypt valide. Vous pouvez aussi l’accepter définitivement 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 souvent le port 10000, mais vérifiez avant de le supposer. Exécutez sudo ufw status. Si la commande renvoie Status: inactive, ufw ne bloque rien — Ubuntu le livre désactivé et l’ajout d’une règle d’autorisation ne l’active pas —. Cherchez donc plus en amont, par exemple dans le firewall du panneau de contrôle de votre fournisseur. Si la commande renvoie Status: active, exécutez sudo ufw status verbose pour afficher la politique entrante par défaut et les éventuelles règles générales. Si le trafic entrant est refusé et que le port 10000 n’est pas listé, 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. Faites la distinction suivante : un timeout signifie qu’un firewall abandonne silencieusement les paquets, tandis que ERR_CONNECTION_REFUSED signifie que le port est accessible, mais que Webmin ne fonctionne pas. Vérifiez avec sudo systemctl status webmin.

« Access denied for <your IP>. » Vous avez configuré le contrôle d’accès par adresse IP dans l’option A, mais votre adresse actuelle ne figure pas dans la liste autorisée. Il peut aussi s’agir d’une adresse IP dynamique qui a changé ou d’une faute de frappe. Il n’existe aucun moyen de revenir en arrière depuis le navigateur. Corrigez la configuration 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 cloud images utilisant exclusivement des clés. Webmin s’authentifie via PAM avec le mot de passe Unix, mais ce mot de passe n’existe pas pour l’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 à 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 est le point de départ.

FAQ

Webmin peut-il être exposé sans risque sur Internet ?

Considérez Webmin exposé sur Internet comme un shell root avec une page de connexion, car c’est exactement ce qu’il est. La configuration n’est suffisamment sûre qu’avec plusieurs niveaux de protection : un certificat valide, l’authentification à deux facteurs, Fail2ban et, soit une liste d’autorisation IP stricte, soit, mieux encore, aucune exposition publique. La configuration présentant le moins de risques lie Webmin à 127.0.0.1 et y accède via un tunnel SSH. Le port 10000 ne répond alors à personne sur Internet.

Comment supprimer l’avertissement concernant le certificat Webmin ?

L’avertissement (NET::ERR_CERT_AUTHORITY_INVALID) apparaît parce que Webmin est livré avec un certificat auto-signé. Émettez-en un véritable depuis Webmin, Webmin Configuration, SSL Encryption, Let's Encrypt. Utilisez un nom DNS qui pointe vers le serveur, ou l’adresse IP publique du serveur si Certbot 5.3 ou une version ultérieure est installé. Le port 80 doit être accessible pour le challenge, avec une réponse fournie soit par un serveur web existant, soit par le serveur standalone de Certbot. 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 le certificat auto-signé en toute sécurité.

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 adresse IP publique depuis curl ifconfig.me. Webmin l’enregistre dans la ligne allow= de /etc/webmin/miniserv.conf. Attention aux adresses IP dynamiques des connexions domestiques : si l’adresse 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 en utilisant votre mot de passe Unix. Or les images cloud sont généralement configurées avec une authentification uniquement par clé et aucun mot de passe défini pour le compte par défaut. PAM ne trouve donc aucun mot de passe correspondant et la connexion est refusée. Exécutez sudo passwd youruser sur le serveur pour en définir un, puis connectez-vous. En revanche, une ligne Non-existent login as ... dans /var/webmin/miniserv.log signifie que le nom d’utilisateur ne correspond pas à un véritable compte Unix.

À quoi sert Webmin par rapport à SSH classique ?

Webmin fournit une interface 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 niveaux de compétence variés. SSH classique est plus rapide, scriptable et expose une surface d’attaque beaucoup plus réduite pour les tâches 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 question porte plutôt sur le choix d’un panneau que sur l’opposition entre panneau et shell, commencez par comparer 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.