Webmin Configuration
The Webmin Configuration module allows you to configure most of the important aspects of Webmin itself, as well as install new modules, upgrade existing modules, and upgrade Webmin itself. It also provides a means to change the port and address where the Webmin miniserv.pl web server listens for connections, select different languages, enable or disable SSL encryption, and configure the Webmin built-in logging features.
IP Access Control
Webmin has its own web server, called miniserv.pl, which provides a simple IP access control feature. This page allows you to configure this option. You may enter IP networks (such as 192.168.1.0), IP host addresses (such as 192.168.1.79), and hostnames (such as joesbox.penguinfeet.org). It is wise to limit access to the Webmin server to just those addresses that are trusted. While Webmin has no known exploits in versions greater than 0.970, if someone were to obtain your password, this would provide an additional level of protection from unauthorized access. This option configures the accept and deny directives in the miniserv.conf file. The default is to allow any address to access Webmin.
 | Be aware that using IP access controls within Webmin is an application level security feature. In other words, if ever an exploitable problem were discovered in the Webmin miniserv.pl web server, it would still be accessible from an IP not permitted to use Webmin. So it is still theoretically possible to attack the web server even if the user isn't offered a login page. However, this is a pretty unlikely scenario, requiring a bug in miniserv.pl that is exposed even when an authentication page is not provided. |
Port and Address
The Webmin server will, by default, listen on every active IP address on the system. But if you have multiple addresses and would prefer Webmin to only listen on one of them, you may use this option. So, for example, if you have one network interface connected directly to your local network and a second network interface connected to the internet, you could improve security by causing Webmin to only listen on the local network. In this case, any requests from the internet at large would be ignored, but it would still be possible to connect from local computers. This can be a very effective first line of defense. After all, if the bad guys can't even talk to the Webmin server, they certainly can't try anything funny to break into it.
The Listen on Port option specifies the network port on which Webmin will listen. In a standard Webmin install this will be port 10000, though Caldera installs it on port 1000. Some firewalls may restrict access to ports below 1024, and some may restrict even ports above 1024. If your network has strict proxy restrictions that prevent connecting on port 10000, you may wish to try port 553 or 443 (assuming these ports are not already in use on your Webmin server for normal SSL service). These ports will nearly always be usable through a proxy, even when using an SSL enabled Webmin.
 | In a proxied environment, your client browser must use a CONNECT method to construct a tunnel through the proxy device. Because of the potential for abusing CONNECT requests most proxies prevent this method on all but a few ports. The standard port for SSL web connections is 443, and so it is the most likely port to be available for CONNECT requests. If your proxy is running Squid, and you have administrator privileges you may wish to add Webmins default port to the allowed SSL ports as documented in the Squid chapter of this book. |
As mentioned briefly in the installation chapter, it is possible to alter these configuration settings in the miniserv.conf configuration file in addition to graphical configuration with the Webmin Configuration module. This may be necessary if a firewall prevents you from accessing port 10000, and you only have console or SSH access to the machine. In this case, editing the port option will alter the port, and the bind directive configures the address on which Webmin listens. Whenever editing the miniserve.conf file, Webmin must be restarted for changes to take effect.
Logging
As mentioned earlier, Webmin provides very flexible logging features. With these features, you can very easily monitor what actions those users with adminstrator privileges are performing on the server. It is also possible to log actions based on the module where the actions are performed. The option Log resolved hostnames will cause Webmin to provide a hostname rather than just an IP address for the client computer that performed an action. And Clear logfiles every...hours causes Webmin to rotate its own logs and keep them from overfilling the disk with old logs. If long-term logs are needed for security auditing purposes, it may be wise to include the Webmin log in your normal system backup rotation.
The decisions regarding what to log, whose actions to log, and how long to store those logs, should be carefully considered for your situation. In some cases, a log is unnecessary, while in others it may be required by company policy or useful in addressing the security needs of your environment. If logging is enabled, care should be taken to insure Webmin will have plenty of disk space in the Webmin log directory, as some options can lead to quite verbose logging (Log changes made to files by each action, for example). Remember that Webmin action logging has nothing to do with the logging features of other parts of the system. Syslog is configured separately in the System:System Logs module, while application specific logging is usually configured within the application module.
Proxy Servers
Webmin provides several tools that must connect to the internet to operate correctly. These include the Webmin Update feature, the Software Packages module and others. If your local network uses a proxy to access Web or FTP sites on the internet, you may configure those settings here. If your proxy requires authentication, thie username Webmin will use to login can also be configured on this page in the Username for proxy and Password for proxy fields.
User Interface
The Webmin user interface is configurable in a number of ways. In this module you may configure the colors of your Webmin pages. The colors are expected to be in standard hex triplets, as used in HTML markup on the internet. You may also choose to use the standard fonts of your browser to display page titles, rather than the font provided by the theme you are using. Finally, you may configure where on the page Webmin will display the login name and hostname of the server. This page does not configure Webmin themes, which are configured on their own page, and the changes that can be made here are mild by comparison to the possibilities when using themes. Beware also that these changes may not take effect when using a theme other than the old standard Webmin theme. For example, the new MSC.Linux theme overrides all of these options with its own standard values.
Webmin Modules
As previously mentioned, one of the best things about Webmin is that it is completely modular. Every server daemon, every system feature, every Webmin feature, has its own module that connects to the core Webmin libraries and answers to the Webmin miniserv.pl webserver. Because of the elaborate, but still easily comprehensible, modular framework that Webmin provides, it is very easy to write full featured modules that integrate seemlessly into Webmin and your operating system.
Install Module
From this page, you can install new modules, either from a local file, an uploaded file, or a file downloaded from an FTP site or website. Webmin module packages are simply tar archive files, that contain the complete directory structure of the module. These modules end in the suffix .wbm.
| A great resource for additional Webmin modules is the Third Party Modules for Webmin page, run by Richard Teachout. Richard is a long time fan and supporter of Webmin, and a regular contributor to the Webmin dicussion lists. After spending some time on the list, he perceived a need for a comprehensive resource for modules that work with Webmin. At the time of this writing, there are over 180 modules listed at his site, though it should be mentioned that the site also lists the modules included in the standard Webmin distribution. If you've written a Webmin module, you should post it to this site, so others will be able to easily find and benefit from your efforts. It is also a great place to find example code to help you when writing your own modules (in addition to the standard modules, of course!). Beware, however, that as with any group of free software the modules vary wildly in quality. Some are excellent and on par with any of the best standard Webmin modules, while others are in such an early stage of development as to not be useful. |
Clone Module
The Clone Module feature provides an impressive amount of flexibility for administrators who must provide limited administration access for several instances of the same software on the same machine. If, for example, you have two different Apache configurations running on your system, you could clone the Apache module to allow different users to access the different Apache configurations.
| While this feature does allow interesting and powerful options for multiple users configuring similar services, Webmin should not yet be viewed as an ideal tool for administering a virtual hosting server, where many users configure the Apache virtual servers, Sendmail aliases, and DNS entries. There is a commercial module written by Tim Niemueller, which provides many of these features, and there are also other non-Webmin web-based administration tools that provide this functionality. Also, I have begun public development of a free module to perform these functions. The project is called mojo and is now hosted on SourceForge, at http://mojo.sourceforge.net. |
To clone a module, select the module to clone from the dropdown menu, then enter a new name for the module. To avoid the problem of the new module interfering with the original module, you will want to carefully consider the service being administered by the cloned module. Usually, you will need to set up the new clone with a wholly separate installation of the service being configured. So, for example, if you have cloned Squid so that you may run two different Squid processes you must configure them to use separate configuration files, cache directories, log files, and process IDs. If this precaution is not taken, one or both of the processes will behave erratically or fail to work at all.
Example: Cloning the Squid Module
To take the example further, let's create a clone of the Squid module, and configure two Squid processes to run on the same server without stepping on each other. First, copy the squid.conf configuration file from the command line or the Webmin File Manager to a file named squid2.conf.
[root@delilah /]# cp /etc/squid/squid.conf /etc/squid/squid2.conf
Next create your module clone of the Squid module (referred to as Squid2 from here on). Browse to the newly created clone module, and edit the module configuration by clicking on the Module Config link in the upper left corner of the Squid2 index page. Here you should change the Full path to squid config file to point to the newly created configuration file. You will also need to change the Command to start squid and Command to stop squid to point to another filename as well, let's call it /etc/rc.d/init.d/squid2. We'll have to actually create these files before trying to start up our new Squid process.
We will also need to alter the Full path to PID file to point to squid2.pid rather than squid.pid and change the log directory name. I usually use /var/log/squid2 for a cloned Squid process. This is all that is required within the module configuration for the moment. Click Save to save your changes and return to the Squid2 index page.
Now that we've told Webmin the file to edit, we can actually edit it to configure Squid2 to operate independently of Squid. First we'll need to change Squid2 to operate on a different port or IP than Squid, since no two processes can listen on the same IP:port combination. 8080 is a good secondary cache port to use. This option is configured in Squid2:Ports and Networking. Next alter the cache directories to something different than the Squid cache directories, since they cannot be shared. The same must be done for the access.log, cache.log, and store.log. As mentioned previously, I usually place my Squid2 logs into /var/log/squid2, so this directory must be created with ownership by the same user and group names that Squid runs under (squid:squid on Red Hat Linux).
Finally, copy your Squid startup script to a new location, and modify it to call Squid with the new configuration file and check against the new PID file. For example, on my Red Hat system I would copy /etc/rc.d/init.d/squid to /etc/rc.d/init.d/squid2. You can now configure access controls in Webmin to allow access to separate administrators for each Squid process, or further modify the Squid2 configuration to provide different functionality that the primary Squid process.
Delete Modules
In this section, you may select any modules that you'd like to delete from your Webmin installation. Beware that using this form will delete the selected modules entirely from the system. If you decide later to use a deleted module, you will have to download the module again and reinstall it. It is usually a better idea to simply remove the module from each users access list (possibly even including root), rather than deleting the module here. However, if disk space is a concern, you can use this to delete all unneeded modules from your system.
Operating System
Webmin knows how to interact with your system based on configuration files for each module, that are selected based on the operating system configured here. If your system has Webmin pre-installed, you usually will not need to concern yourself with this. But if you upgrade your system, and the new version moves some configuration files to new locations, updating this may be necessary. On this page you may also set the search path for both programs (like system commands), and for libraries (such as for the password encryption library). Again, these options rarely need to be changed unless you have installed system tools and configuration files in odd locations on your system.
| In current versions of Webmin, at least up to 0.970, changing the OS does not alter existing module configuration files, and will only apply to newly installed modules. A future version will likely alter this behavior to modify the already installed module configurations only if they have not been altered by the user.XXX ?What does Jamie say about this? |
Language
Webmin supports a large number of languages for titles and module text. This page allows you to choose the language of your Webmin. New languages are being added regularly. Users of languages that are not supported are encouraged to write a translation and send it to the author of Webmin. He's always happy to receive new translations, and users are always happy to find that their native language is one that is provided with the distribution.
Index Page Options
This page allows you to configure the layout of the Webmin index pages. You may choose the number of icons to display per row using the Number of Columns field. The Categorize modules? selects whether modules will be grouped under category tabs based on the type of function they perform. The Default category is the category that will be displayed when first logging into Webmin. An alternative header can be used by selecting the Use alternative header option, which provides a somewhat different appearence by placing the host information on the upper right side of the display rather than below the Webmin title. Finally, selecting Go direct to module if user only has one? will cause a user to see only the module they have access to, rather than the Webmin index page when logging in.
Upgrade Webmin
Using this page, you may upgrade your Webmin to the latest version automatically from the Webmin home page, or from a local or uploaded file. This module will use a package management system to perform the update if one is available on your system. If, for example, you have an RPM based system like Caldera, Red Hat, or Mandrake, this feature will upgrade from an RPM package (it even knows how to find the correct package type for your system on the Webmin homepage!).
Authentication
Webmin provides some nice features for preventing brute force password cracking attacks on your server, as well as protection against "forgetful users". If your Webmin server is widely accessible, and provides service to many users, it is probably wise to make use of these features to maximise the security of your system. Security policy in your company may even require usage of some or all of these features.
Password timeouts provide a means to prevent brute force password attacks by limiting the frequency of login attempts by a given user. If enabled, Webmin will block hosts that have a given number of failed login attempts. The time to block the host is configurable in seconds. Webmin will expand the delay on continuing failed login attempts from the same host. Logging of blocked logins can also be enabled.
The next option, Log blocked hosts, logins and authentication failures to syslog configures Webmin to log authentication failures and blocked addresses attempting to login to syslog. These logs will usually appear in the secure or auth file in your system log directory.
Session authentication provides a means of logging users out after a specified time of inactivity. This can help prevent unauthorized users from accessing the server by simply using the computer of someone who does have access. This isn't fullproof, as many browsers now have password management features and authorized users may store their passwords on the local computer, making them accessible to anyone with access to the computer. If security is a concern, you should strongly discourage users from saving login information for the server on their local machine, as well as discouraging leaving open browser sessions when away from their desk or office.
Finally, you may choose to allow logins from users on the same machine where Webmin is running based on the username. This feature should only be used for single user machines, where security is not a major concern. If enabled, anyone with access to the local machine will easily be able to gain root access to your system.
| As any complete system administration tool must, the Webmin web server runs with root privileges. Security should always be a first priority for any publically accessible Webmin-enabled system. A weak security policy, or no security policy at all, is an invitation for disaster. A comprehensive security policy will include a good firewall, and intrusion detection system, vigilance with regard to software updates and errata from your OS vendors, and perhaps most importantly education of users and administrators of your network. |
Reassign Modules
As mentioned earlier, Webmin categorizes modules based on the function they perform, by default. This page provides a simple means for moving modules to new categories, if you find the default categorization is confusing to you. Some third party modules, written before the categorization features were added to Webmin, are miscategorized into the Others category by default, so you may wish to manually move them to their more sensible locations using this module.
Edit Categories
It may also be most sensible to create a new category for your favorite modules, or custom modules written just for your organization. This page allows you to create new module categories, as well as rename or relabel old ones.
Webmin Themes
One of the more recent additions to the Webmin feature set is that of themability. Themes in Webmin are very flexible, allowing a theme developer to modify nearly every single aspect of the appearence and layout of the Webmin pages. For example, in the screenshots throughout this guide, you may have noticed that the icons and titles are not the same as the standard Webmin appearence. These screenshots were taken on a Webmin using the Swell Technology theme, which is a custom theme designed by the author of this book with some help and pointers from Youngjin Hahn (aka Artwiz of Themes.org fame), and Charity Baessell (the webmistress and designer here at Swell Technology).
 | For information on making your own themes for Webmin, you can consult the Creating Themes section of the Webmin module developers guide. |
Switching amongst installed themes is simply a matter of selecting the preferred theme, and then clicking the Change button. Installing a new theme requires you to choose the location of the file (Webmin themes have a suffix of .wbt), and then clicking Install Theme. Changing themes will require a forced refresh of your browser display in order for all new icons and title images to be displayed because browsers often cache images and pages.
Trusted Referers
Because Webmin is web based, it is accessed from your browser. Browsers often store authentication information and will automatically resend it on demand from the Webmin server. Because of this, it could be possible for remote web sites to trigger dangerous actions on your Webmin server (assuming the web site owner has malicious intentions--it would not happen accidentally!). This page allows you to configure which hosts may refer to actions on your Webmin server.
SSL Encryption
If your system has the OpenSSL libraries installed, as well as the Net::SSLeay Perl module, you will be able to use SSL encrypted connections to your Webmin server. This increases the security of your server by allowing password and user information to be sent in an encrypted form. If you will be accessing your Webmin server from across the internet, it is strongly suggested that you use SSL encrypted sessions. Now that both the export restrictions on encryption have been relaxed and the RSA patent has expired, it is becoming more common for Linux and Unix versions to always ship with the necessary libraries and Perl module for this to be enabled out of the box. But if you do need some help setting this option up, there is a nice tutorial on the Using SSL With Webmin page.
Certificate Authority
This page allows you to configure the SSL certificate for this server. Using this, you may configure your system to allow logins without a username and password. If configured, clients may request a personal certificate in the Webmin Users module, and from then on the browser will authenticate itself via the certificate provided. If your users are located in controlled and secured environments, this feature can make using Webmin simpler.
To create a certificate, simply fill in the authority information (this can be any information you'd like to include, such as the name of the administrator of the Webmin server), and click Setup certificate authority.
| If using this authentication method, users should be made aware of the potential security issues involved. Anyone who has access to a machine with such a certificate will be able to access the Webmin server with the same privileges as the primary user of the machine. Thus, a security policy should be in place that includes automatic logout from the system after a period of inactivity. Using the logout facilities of Webmin will no longer work, as authentication is automatic every time the user starts a browser session. |