What Is Webmin? Uses, Safe Installation and Security Guide

What is Webmin and what is it used for?

Webmin is a free, open source, browser based system administration tool for Linux and other Unix-like servers. It lets you manage users, services, disks, packages, cron jobs and firewall rules without typing commands. It also ships modules for software such as Apache, Nginx, MySQL and BIND.

In this guide we treat Webmin as a system administration panel, not as a hosting control panel. We are a digital marketing and web team, not a hosting company. So everything here rests on Webmin's official documentation, its download page and its security advisories. The commands match what those official pages show.

We wrote this for two kinds of readers. If you own a website or an online store, you will learn whether you actually need this tool. If you run your own VPS, you will install it from the official repository and then lock it down before it sits open on the internet.

What can you manage with this panel?

The official site describes the project as a web based system administration tool for Unix-like servers. In other words, the focus is the server itself, not a single website. Each section of the interface is a module. Behind the scenes, each module edits the relevant config file or runs the right command for you.

Here are the modules most people reach for first:

• System: user and group accounts, disks and file systems, disk quotas, and services that start at boot.
• Packages: listing, updating and removing software packages.
• Scheduled jobs: creating, editing and manually running cron jobs.
• Networking: network interfaces, firewall rules and BIND DNS server settings.
• Servers: configuration for Apache, Nginx, MySQL or MariaDB, PostgreSQL, Postfix and similar services.
• Tools: an in-browser terminal, a file manager, system logs and custom commands.

However, the modules you see depend on the software installed on your server. For example, if Nginx is missing, its module only shows a notice. So do not expect every service to appear the moment you install the panel. It helps you manage what already runs on the machine.

How does the panel work under the hood?

Webmin ships its own small web server. According to the official docs, it listens on port 10000 on all interfaces by default. When you change a setting in the browser, the panel edits the matching file or runs the needed command. As a result, it acts as a layer that works on the server with administrator rights.

That design has two consequences. First, anyone who can log in can, in practice, control the whole server. Second, a flaw in the panel turns straight into a flaw in the server. That is why later sections spend real time on access limits, HTTPS and two-factor authentication.

On the other hand, the tool does not convert your config files into its own format. If you change an Apache setting in the panel, it writes the change straight into Apache's own file. So even if you remove the panel one day, your server keeps running on standard files. That sets it apart from some hosting panels, which impose their own template systems.

In short, think of it as a remote control rather than an abstraction layer. You handle a large share of command line tasks through visual forms instead. Still, knowing what changes in the background will save you when something breaks.

What is the difference between Webmin, Virtualmin and Usermin?

All three come from the same ecosystem, but they serve different people. Webmin is the core interface a system administrator uses to manage the server. Virtualmin is a hosting control panel that runs on top of it. Usermin is a simpler interface for regular server users who want to manage their mail, files and personal settings.

Here is a simple way to picture it. The base panel lets you manage each service on its own. Virtualmin then ties those services together per domain. For instance, when you add a domain, Virtualmin sets up the web server config, the DNS zone, the database and the mailbox in one step. The base tool does not do that for you.

Therefore, the base panel alone may be enough for a VPS that runs a single app. If you plan to host several client sites, you most likely want a hosting panel such as Virtualmin instead. Usermin mostly matters for end users who only need mail or file access.

The official site also mentions Cloudmin, which targets managing multiple servers and virtual machines. Most readers who run one server can skip it. Even so, knowing the whole family makes it easier to pick the right tool.

How is Webmin different from cPanel and Plesk?

This is where most confusion starts. cPanel and Plesk are web hosting control panels. Their job is to manage domains, sites, mailboxes and databases per customer account. Webmin, by contrast, is a system panel that manages the server's operating system. So installing it will not give you a cPanel-style customer panel.

Treat the license row as a general frame and always check current terms on each product's own site. We also compare Plesk and cPanel in more depth in another article in this series. If you are not sure which setup fits you yet, start with our guide to choosing web hosting.

Who should use this tool, and who should not?

The panel suits people who run their own VPS or physical server and know Linux at a basic level. For example, a developer may want to see cron jobs, service status and logs on one screen. A small team may also prefer to track package updates and user accounts through a visual interface.

That said, it is not the right choice for everyone. On shared hosting you have no root access, so you cannot install it and you do not need it. If you pay for a managed VPS, your provider's own panel is usually the safer path.

To figure out which server type fits you, read our comparison of VPS, VDS and cloud servers. In short:

• If you manage your own server, know Linux basics and want a visual helper, the tool makes sense.
• If you will host several client sites, Virtualmin or a commercial hosting panel fits better.
• Managed hosting or a managed VPS suits you best if you never want to touch server administration.
• If you deploy with containers, also look at self-hosted PaaS tools such as Coolify.

What should you prepare before installing?

A little preparation saves you from problems later. Since the panel runs as a root service, start with a clean, updated server. Also decide up front who will reach the panel and from which IP address.

• Supported distribution: the official download page covers repository setup for Debian and Ubuntu based systems as well as RHEL, Rocky Linux, AlmaLinux, CentOS and Fedora.
• Admin access: a user account with sudo rights that can log in over SSH.
• Updated system: update existing packages with your distribution's package manager first.
• Your IP address: find the office or home IP you will connect from with our What Is My IP tool.
• Firewall plan: decide whether port 10000 opens to everyone or only to specific addresses.
• Backup: on a production server, take a snapshot or backup before you start.

The last item matters most, because the panel edits system files directly. One wrong setting can stop a service. If you have no backup plan yet, our website backup strategy guide gives you a solid base. And if package downloads crawl, our article on Linux package mirrors can help.

How do you install Webmin from the official repository?

Webmin's official download page advises against manual package installs and points to the repository method instead. The benefit is clear. The panel hooks into your system's package manager, so future updates arrive together with your other packages. Our steps below follow the commands on that page.

1. Connect to the server over SSH as a user with sudo rights.
2. Download the repository setup script to a file, and do not run it yet.
3. Open the script in a pager or text editor and read it.
4. Run the script with sudo; it adds the repository definition and the signing key.
5. Install the package with your distribution's package manager.

These are the download and repository commands from the official page, plus a step to read the script:

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

Then install the package. Use the first line on Debian and Ubuntu based systems, and the second line on the RHEL family:

sudo apt-get install webmin --install-recommends
sudo dnf install webmin

Once the install finishes, the service starts on its own. You can check its status with your distribution's service manager. That way you know the panel runs before you even open a browser.

Why should you avoid one-line pipe-to-shell installs?

A common pattern online is to download a script and pipe it straight into a shell on the same line. It is quick, but it is risky. You end up running code as root without ever seeing it. And if the connection drops midway, a partial script may still run.

With this panel the concern is sharper. It runs as a service with access to the entire server, so every step in the install chain has to be trustworthy. Saving the script to a file first gives you two chances: you read what it does, and you confirm it really came from the official source.

That is why the steps above save the script, then read it, and only then run it. In addition, the script adds the repository signing key. From then on, every update passes through your package manager's signature check. So instead of a one-time shortcut, you get a lasting chain of trust.

Keep the same habit with other tools. When an install guide asks you to pipe a script into a shell, download it and read it first. In a company setting, it also helps to have a second person on the team review the script.

What should you check on your first login?

After the install, open your server's address on port 10000 in a browser. For example, if your server's address is 203.0.113.10, type https://203.0.113.10:10000 into the address bar. The official page also reminds you that your firewall has to allow that port.

On first load your browser will most likely show a certificate warning. That happens because the panel starts with a self-signed certificate. Only click through if you know for sure you reached your own server. Later, you replace it with a real certificate and the warning goes away for good.

You sign in with the server's system accounts. During the first session, run through these checks:

1. Review the dashboard for the operating system, the panel version and the number of pending package updates.
2. Apply pending system updates.
3. Open the Webmin Users module and look for unneeded users or accounts with broad rights.
4. Open the Webmin Configuration module and move on to access, authentication and SSL settings.

These four steps shrink the window during which the panel sits open on the internet. In particular, set up access limits in that first session. Out of the box, the panel accepts connections from any IP address.

How do you restrict access to Webmin port 10000?

According to the official Webmin Configuration documentation, the panel accepts connections from any IP by default. You can fix that at two layers: the operating system firewall and the panel's own IP access control. Using both means one layer still protects you if you make a mistake in the other.

The first layer is the firewall. If you use UFW on Ubuntu, the rule below opens port 10000 only to your own IP address. Replace 198.51.100.25 with your actual address:

sudo ufw allow from 198.51.100.25 to any port 10000 proto tcp
sudo ufw status numbered

If you added a rule earlier that opened the port to everyone, delete it. On cPanel or VPS setups that use CSF, you can apply the same logic through the allow list in our CSF Firewall guide.

The second layer is the IP Access Control setting. Open it inside Webmin Configuration and choose the option that only allows listed addresses. Then add single IPs, network ranges or hostnames. However, the official docs warn that hostname based rules can fall to DNS spoofing, so stick with IP addresses.

A stricter option is to have the panel listen only on the local address and reach it through an SSH tunnel. With that setup, the port never faces the internet at all.

How do you reach the panel through an SSH tunnel?

An SSH tunnel links a port on your own computer to a port on the server over an encrypted connection. That way the panel stays off the public internet, and only people with SSH access can use it. This works especially well for small teams where one or two people log in.

First, use the Ports and Addresses section in Webmin Configuration to make the panel listen on the local address. Then run the command below on your own computer. Swap in your own username and server address:

ssh -L 10000:127.0.0.1:10000 youruser@203.0.113.10

While the tunnel is open, go to https://localhost:10000 in your browser. The browser sends the request to port 10000 on your machine, and SSH carries it to the server over the encrypted link. When you close the session, the tunnel closes too.

There is one precondition, though. SSH itself has to be secure. Key based login instead of passwords, no direct root login and a tool that blocks repeated failed attempts all belong in that chain. We cover those settings in the SSH hardening article in this series. For brute force protection, you can also follow our Fail2ban setup guide.

Does changing the default port improve security?

Partly, but it does not count as a security control on its own. Moving away from port 10000 cuts down noise from automated bots that scan default ports. A targeted attacker, however, can scan every port and still find the panel. So add a port change next to access limits, not in place of them.

You can change the port in two ways. The first is the Ports and Addresses section in Webmin Configuration. The second is editing the main config file from the command line. Change the port line in the file, then restart the service:

sudo nano /etc/webmin/miniserv.conf
# change the port=10000 line to the new value
sudo systemctl restart webmin

Before you pick a new port, make sure no other service uses it. Also open a firewall rule for the new port and remove the old one. Otherwise you either lock yourself out or leave the old port open for no reason.

The official docs point out one more detail: ports below 1024 need root privileges. The panel already runs as root, so it can use them. Still, handing a standard port such as 443 to the panel can clash with the website on the same server.

How do you turn on HTTPS and two-factor authentication?

The SSL Encryption section inside Webmin Configuration controls the panel's encrypted connections. Make sure SSL is on. Next, replace the self-signed certificate with a real one for your server's hostname. The panel lets you upload your own certificate or request one through Let's Encrypt.

You can confirm the certificate works with our SSL checker tool. If you want the basics behind HTTPS, our SSL certificate guide explains the core ideas.

The second step is two-factor authentication. The official docs list two providers: Google Authenticator, which uses the TOTP protocol, and Authy, a commercial service. You switch the feature on globally in the two-factor section of Webmin Configuration. After that, each user enrolls their own authenticator app in the Webmin Users module.

TOTP codes depend on the clock. If the server time drifts, even correct codes can fail. So check that time sync runs on your server; our NTP and Linux time sync guide walks you through it. Accurate time also makes logs far easier to read.

Which authentication settings deserve attention?

The Authentication section in Webmin Configuration decides how the panel reacts to failed logins. Its password timeout option, as described in the official docs, temporarily blocks hosts after repeated failures. Keep it on, because it is your first line of defense against brute force attempts.

The same section also offers an option to log blocked hosts, logins and authentication failures to syslog. Turning it on pays off twice. First, you can review who logged in and when. Second, tools like Fail2ban can read those entries and block attacking addresses at the firewall level.

Also review these settings:

• Auto logout after inactivity: it limits the risk of a session someone forgot to close.
• Permanent login cookie: convenient, but risky on shared computers; we suggest you keep it off.
• User permissions: give each person only the modules they actually need.
• Strong passwords: create long, unique passwords with our password generator.

The permissions item matters more than it looks. The official security page notes that some flaws could only be exploited by Webmin users with limited rights. In other words, giving untrusted people module access widens the impact of any bug.

What can we learn from Webmin's security history?

Webmin's official security page lists reported flaws version by version. The best known incident involves version 1.890, which shipped with a backdoor. According to the official write-up, someone had maliciously modified the password_change.cgi file. Anyone who knew about the backdoor could run commands as root, and the issue carries the identifier CVE-2019-15231.

The same page says versions 1.900 through 1.920 contained similar code. In those versions, however, an attacker could only exploit it if the option to change expired passwords was on. Version 1.930 fixed the problem. In short, the incident targeted the build and release chain more than the code itself.

The security page contains other entries too. For instance, CVE-2022-30708 describes a flaw that let less privileged panel users modify arbitrary files with root rights. Entries like these share one lesson: the more popular a panel becomes, the more attention it draws from attackers.

We take three practical points from this history. Always install from the official repository so you receive signed updates. Follow the security page on a regular schedule. And never leave the panel open to the internet, because an exposed panel becomes an early target whenever a new flaw goes public.

How do you keep the panel updated and monitored?

If you installed from the official repository, the panel updates along with your system packages. So the most important habit is to apply package updates on a regular basis. On Debian and Ubuntu, apt handles that; on the RHEL family, dnf does. The dashboard also shows pending updates, so you can see the state at a glance.

Decide on automatic updates based on the server's role. On a critical production server, a balanced approach is to apply security updates automatically and handle major upgrades by hand. Whichever path you choose, confirm that a backup exists before you update.

For monitoring, turn these checks into a routine:

1. Check for panel and system package updates every week.
2. Review the failed login entries the panel writes to syslog.
3. Disable accounts in the Webmin Users module that nobody uses anymore.
4. Confirm that the firewall only allows the expected rules for port 10000 or your chosen port.
5. Follow the official security advisories page for new entries.

This routine keeps the panel from quietly weakening over the years. After all, security rarely comes from a one-time setup. It comes from boring but steady checks.

When is the command line a better choice than a GUI panel?

A graphical panel makes many tasks easier, but it does not fully replace the command line. For work that must be repeatable and documented, the shell wins by a wide margin. For example, if you need the same config on several servers, scripts or configuration management tools give you consistency.

We also reach straight for the command line in these cases:

• Troubleshooting: when a service crashes, inspecting logs, processes and network connections from the terminal is faster.
• Version control: tracking config files in Git shows you the full history of changes.
• Automation: deploy scripts and CI pipelines rely on commands, not on a web interface.
• Lockouts: when the panel will not load, SSH is the only tool you have left.

On the other hand, the panel shines in some areas. Listing cron jobs, checking disk usage, reviewing user accounts or finding a setting for a service you rarely touch all feel easier in a browser. That is why we suggest you see the two approaches as partners, not rivals.

A practical rule: handle regular and critical work with commands, scripts and version control. Use the panel for occasional checks and small tweaks. That way you keep both speed and traceability.

When should you not install the panel yourself?

To be honest, not every site owner needs this tool. If your server administration skills are limited, running a root level panel that can face the internet may bring more risk than benefit. In that case, leaving server management to your hosting provider is the smarter call.

We suggest you skip a do-it-yourself install in these situations:

• You use shared hosting, because you have no admin access anyway.
• Your server already runs cPanel, Plesk or another hosting panel, because two panels editing the same files can collide.
• You pay for a managed VPS, because you may break the provider's support scope.
• You cannot keep up with firewall rules, SSH keys and update routines yourself.

People often overlook the second item. As we also note in the CyberPanel and aaPanel articles in this series, the healthiest setup gives one management panel authority over a server. If in doubt, ask your provider's support team first.

Our team works on the web design and digital marketing side. If you want help drawing that line for your site's infrastructure, we can review hosting options with you as part of our web design service.

A short Webmin setup checklist

We pulled the steps from this guide into one list. Use it during a fresh install or when you audit an existing panel:

1. Update the server and take a backup or snapshot.
2. Download the repository script from the official address, read it, then run it.
3. Install the package with apt or dnf.
4. Open port 10000 in the firewall only to your own IP, or use an SSH tunnel.
5. In IP Access Control, allow only listed addresses.
6. Install a real SSL certificate.
7. Turn on two-factor authentication and confirm time sync.
8. Enable password timeouts and syslog logging.
9. Give users only the module permissions they need.
10. Follow updates and official security advisories on a regular basis.

Once you finish these ten steps, the panel becomes a handy and reasonably secure admin interface for your server. Still, no checklist replaces ongoing maintenance.

Is Webmin the right fit for you?

The tool works well for people who want to manage a Linux server from a browser and already have basic system skills. It is not a hosting panel; it manages the server itself. If you plan to host several client sites, Virtualmin or a commercial panel fits better.

Always install from the official repository and read the script first. Then restrict port 10000, turn on HTTPS and two-factor authentication, and keep updates flowing. The security history also reminds us of something simple: the more useful a panel is, the more valuable it looks to attackers.

If server administration is not your job, there is nothing wrong with admitting that. Moving to a managed service or leaning on your provider's support protects both your time and your site.