Webmin Security: Lock Down Access, Logins and Updates

Webmin is a browser front end to root on a Linux or Unix server, so every login, module grant and RPC link it holds is effectively a privileged credential. This guide explains how to run Webmin, and the Virtualmin hosting layer built on it, so that only the right people reach the login page, each person gets only the modules they need, and changes are logged and patched. It covers the Webmin account model, module access control, the Global ACL, IP access control, two-factor authentication, password timeouts, referer checking, the Servers Index and RPC, the Virtualmin remote API, logging and update settings. It is written for system administrators, hosting operators and security engineers who run Webmin on their own servers or inherit servers where it is already installed. For the wider picture across hosting panels, see Hosting control panels security; this page goes deeper on Webmin's own settings.

This is an independent guide from NHI Mgmt Group, based on Webmin's public documentation as of November 2026. It is not sponsored or reviewed by Webmin. Product features change, so confirm settings against Webmin's current documentation.

Key takeaways

• Treat every Webmin user as a root-adjacent identity. Webmin's own documentation explains that the server process runs with full root privileges even for restricted users, so module grants and the "Can edit module configuration?" setting are the real security boundary.
• Restrict the network path first. IP Access Control with "Only allow from listed addresses", a specific "Listen on IP address" and firewall rules on port 10000 keep the login page off the open internet.
• Turn on the login protections. Two-factor authentication (Google Authenticator TOTP), "Enable password timeouts", session authentication with "Auto-logout after" and referer checking together raise the cost of password guessing and cross-site requests.
• RPC links and remote API calls carry root. A Servers Index entry set to "Login via Webmin with username", or a Virtualmin remote API script, holds credentials that can run any command on the target, so manage them as machine secrets.
• Logs and updates close the loop. Keep action logging on, turn on "Log changes made to files by each action", send authentication failures to syslog, and enable GnuPG signature checks and scheduled update reports.

How identity and access work in Webmin

Webmin is a web server (miniserv) that listens on TCP port 10000 by default and runs modules as CGI programs with root privileges. Every request is authorised against the Webmin user who is logged in, the modules that user has been granted, and the per-module access control settings. Webmin's documentation is direct about the consequence: because the process runs as root, a single misconfigured grant can let an untrusted user edit arbitrary files or run commands as root. The Webmin security page adds that privilege escalation by users who have not been properly restricted by the root user is outside the scope of its security reporting, because the fine-grained ACLs are the intended control. In shared responsibility terms, Webmin ships the controls and the administrator decides how tightly to set them.

A default install has one account, root or admin, with access to every module. Further accounts are created in the Webmin Users module, and each has a password mode:

Webmin supports two login styles. Session authentication, the default, uses Webmin's login form and a cookie, supports "Auto-logout after" a set number of minutes, and lets an administrator view and cancel sessions in Webmin Users; sessions older than one week are removed automatically. HTTP basic authentication cannot log out properly, so keep session authentication on. Leave "Offer to remember login permanently?" off, since the documentation itself flags it as a possible security risk, and keep "Always require username and password" selected rather than allowing passwordless login from localhost.

Usermin is the companion interface for ordinary Unix users (mail, file manager, password change). It is a separate service with its own configuration, so apply the same network, timeout and update settings to it if it is installed.

Admin roles and privileged access

Webmin has no fixed role names. Roles are built from module grants, per-module access control and groups. The documentation describes three patterns: restricted users who see only selected modules, sub-administrators who can manage some other Webmin users, and groups whose members inherit module access and settings (groups can nest, and child groups inherit from parents).

Settings that decide whether a role is really restricted

Some modules are equivalent to root by nature. Software Packages exposes only "Can edit module configuration?" because any installer can escalate, and the Webmin security page asks administrators to limit modules such as Custom Commands to trusted users and to set allowed URL download destinations for restricted users. Treat Command Shell, Upload and Download, File Manager, Scheduled Cron Jobs, Software Packages and Users and Groups as full administrative grants when you design roles.

Our recommendation (NHI Mgmt Group): keep the full root or admin Webmin account for break-glass use, give named administrators their own accounts with two-factor authentication, and review every user's module list each quarter. Webmin Users shows session IDs linked to the actions taken in that session, which makes a quarterly review quick. For the wider discipline see the Privileged Access Management Guide.

Virtualmin account tiers

Virtualmin adds hosting tiers on top of Webmin. Its documentation describes the master administrator (root, who manages all aspects of the server), resellers (Virtualmin Professional, who create virtual server accounts for others), virtual server owners (who administer one server with its sub-servers and aliases within limits set above them) and mail or FTP users who belong to one virtual server. Set resource and feature limits for each reseller and owner, give each owner only the features they use, and protect reseller credentials like administrator credentials, because a reseller can create new accounts.

Integrations, API tokens and service accounts

Webmin's non-human access paths are where long-lived credentials collect. Each one should be inventoried, owned and scoped like any other service account.

• Webmin Servers Index and RPC: a remote server added with the link type "Login via Webmin with username" stores a remote Webmin username and password on the master and enables RPC, which Webmin's documentation says can run any command or modify any file on the remote server. Anyone who can click that icon acts with the remote user's privileges, often root. Use "Login when icon is clicked" (each person logs in as themselves) unless central management is needed, hide servers from untrusted users, and remember the documentation's note that hiding a server in this module does not block RPC use from other modules.
• RPC transport: slow mode uses HTTP requests to port 10000; fast mode opens extra TCP connections on roughly ports 10001 to 10100. Allow those ports only between the master and its managed servers.
• Discovery: auto-discovery uses UDP port 10000 and replies with hostname, port and SSL mode. Turn off UDP listening on hosts that do not need to be discovered.
• Virtualmin remote API: calls go to https://yourserver:10000/virtual-server/remote.cgi with the command in a program parameter, use the same authentication as the web interface, and are available only to the master administrator. That makes every script that calls the API a holder of a root-level credential. Use POST (Virtualmin recommends it because GET puts parameters in the URL), keep TLS verification on with a trusted certificate, read the password from a secrets store rather than a command line, and restrict the source addresses in IP Access Control. See the Secrets Management Guide.
• Virtualmin command line API: the virtualmin programs need a root shell, so access is governed by SSH and sudo policy rather than Webmin. See the OpenSSH Server Hardening Guide.
• Anonymous Module Access: maps URL paths to a Webmin user with no login. Webmin's documentation warns never to use / as a path. Leave it empty unless a specific read-only page needs it, and map it to a user with no other grants.
• Client certificates: Webmin's Certificate Authority page enables client-certificate login (it needs SSL mode). It suits administrators on managed devices; record who holds each certificate and revoke on leaving.

Logging and detection

Webmin writes two logs that matter to defenders. The action log, /var/webmin/webmin.log (some distribution packages use /var/log/webmin/), records actions that change the system, with user, module, client host and time. The access log, /var/webmin/miniserv.log, is in common log format and records every page requested. When "Log changes made to files by each action" is on, diffs are stored in /var/webmin/diffs/, including commands run and, for MySQL and PostgreSQL, SQL statements. File change logging is off by default; turn it on, since the extra disk use is small against the forensic value.

Forward syslog and both Webmin logs to your SIEM (see the SIEM Guide), and do not use "Clear logfiles every" on the host as a substitute for central retention.

Metrics that show the controls are working:

• Percentage of Webmin and Usermin instances reachable only from listed admin networks (target 100%).
• Percentage of named Webmin users enrolled in two-factor authentication.
• Days from a Webmin release on the security page to deployment across the estate.
• Number of Servers Index entries using "Login via Webmin with username", each with a named owner.
• Number of restricted users with "Can edit module configuration?" set to Yes (target zero).

Hardening baseline

The settings below come from Webmin Configuration unless noted. Roll them out in this order so you do not lock yourself out.

1. Inventory. Find every host listening on TCP 10000 (Webmin's usual port) or the port your Usermin installs use, and record the version and installed modules. Prefer the official rpm, deb, pkg or tar packages; the Webmin security page advises against the setup.pl installer where a package exists.
2. Keep a second way in. Before changing access settings, confirm SSH or console access, so a mistaken IP rule can be reversed from the server command line by editing the IP access setting in Webmin's miniserv.conf file (confirm the directive name in the Webmin documentation) and restarting Webmin.
3. Restrict the network. Set IP Access Control to "Only allow from listed addresses" using IP ranges rather than hostnames (Webmin notes reverse DNS can be spoofed), set "Listen on IP address" to the management interface, and add host firewall rules. Reach Webmin over a VPN, bastion or out-of-band management network. If Webmin sits behind a proxy, turn off "Trust level for proxy headers" whenever clients can connect directly.
4. Encrypt. Keep SSL mode on and replace the self-generated certificate with one from your internal CA or a public CA.
5. Login protection. Turn on "Enable password timeouts" and set "Block hosts with more than" and "failed logins for" (our starting point: 5 failures, 300 seconds, tuned to your users). Keep session authentication with "Auto-logout after" (our starting point: 15 to 30 minutes).
6. Two-factor authentication. Choose Google Authenticator (TOTP) on the Two-Factor Authentication page, then enrol each user in Webmin Users. Pilot on one administrator account first, keep the break-glass account documented, then enforce for all named users. See the MFA Guide.
7. Referer checking. Keep "Referer checking enabled?" at Yes and turn off "Trust links from unknown referers". Do not click "Don't show this warning in future", which turns referer checking off. For setup.pl installs, the security page says to add referers_none=1 to /etc/webmin/config.
8. Least function. Remove modules nobody uses, leave Anonymous Module Access empty, and keep full PAM conversation support off unless your PAM setup needs it.
9. Updates. Keep "Check GnuPG signature on package?" on, update from webmin.com, enable "Scheduled updating currently enabled" with "Email update report to" a monitored mailbox, and apply vendor security updates promptly from the Webmin security page. Patch the operating system too; Webmin's page mentions dependencies such as bash. See the Patch Management Guide.
10. Logging. Turn on syslog for authentication events and file change logging, and forward logs off the host.

Rollback: every Webmin setting above is stored under /etc/webmin/. Back up that directory before each phase; restoring it and restarting the service returns the previous state. Test each phase on one server before the estate.

Small and large estates

A single VPS owner can get most of the value from steps 3, 5, 6 and 9 in an hour: bind Webmin to a VPN or SSH tunnel, turn on timeouts and TOTP, and enable update reports. Larger hosting estates should add central log forwarding, a quarterly access review and a named owner for every RPC link and API script, and manage /etc/webmin/ through configuration management so drift is visible. For the host itself, follow the Linux Server Hardening Guide.

Framework mapping

Common misconfigurations

• Port 10000 reachable from anywhere: the most common setting to change. Bind to a management interface and list allowed addresses, so the login page is reachable only from admin networks.
• "Restricted" users who can edit module configuration: the module looks limited in the menu, but the configuration screen can change paths and commands the module runs as root. Set it to No for every non-root user.
• RPC links shared with junior staff: a "Login via Webmin with username" icon gives whoever clicks it the remote root account. Switch to "Login when icon is clicked" or hide the server and set "Can accept RPC calls?" to No.
• API scripts with embedded root passwords: Virtualmin API examples pass credentials on the command line for brevity. In production, read them from a secrets store, keep certificate verification on and limit source IPs.
• Referer warning dismissed: clicking "Don't show this warning in future" turns referer checking off for everyone. Keep it on and add trusted websites instead.
• Update reports going nowhere: scheduled updating without a monitored "Email update report to" address leaves releases unapplied. Route reports to a team mailbox or ticket queue.

Practitioner checklist

• List every host with Webmin or Usermin, its version, its installed modules and an owner.
• Set IP Access Control to listed admin networks and bind "Listen on IP address" to the management interface.
• Turn on password timeouts, session authentication, auto-logout and syslog for authentication failures.
• Enable TOTP two-factor authentication and enrol every named user.
• Set "Can edit module configuration?" and "Can accept RPC calls?" to No for every limited user.
• Review Servers Index RPC links and Virtualmin API scripts, assign owners and move passwords into a secrets store.
• Keep referer checking on and Anonymous Module Access empty.
• Enable GnuPG signature checks and scheduled update reports, and track time to patch.
• Turn on file change logging and forward webmin.log, miniserv.log and syslog to the SIEM.
• Back up /etc/webmin/ before every change and review user grants quarterly.

Standards and references

• Webmin: Webmin Configuration module documentation
• Webmin: Webmin Users module documentation
• Webmin: Security
• Webmin: Webmin Actions Log documentation
• Webmin: Webmin Servers Index documentation
• Virtualmin: Remote API
• Virtualmin: Understanding Virtual Server and Account Types
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Hosting control panels security · Linux Server Hardening Guide · Privileged Access Management Guide · Service Account Security Guide · MFA Guide