Webmin provides a number of configurable options, access control features, and flexible action logging that provides you with maximum flexibility and security of the Webmin server and the various Webmin system administration modules. These features are accessed through the Webmin tab on the index page of Webmin. When you display the Webmin tab, you see icons for Usermin Configuration, Webmin Actions Log, Webmin Configuration, Webmin Servers Index, and Webmin Users. Keep in mind that the modules located under the Webmin tab are for configuring Webmin itself, not the underlying system. So, for example, creating a user in the Webmin Users module will not create a system user, only a Webmin user. Likewise, the Webmin Actions Log module allows you to search and view the Webmin log, not any system or service log that might exist. We'll get to those kinds of options later. For the moment, we're going to skip over Usermin Configuration because Usermin receives full coverage in the next chapter.
The Webmin Actions Log page provides access to the Webmin log. You can configure this log for each module and individual users. This module does not configure the logs, but provides you with a means to search the logs for actions performed by particular logged users, or actions performed in given logged modules. Configuration of Webmin logging capabilities is covered in the Webmin Configuration section.
With this module it is possible to search for actions by specific users, within specific modules, for a given range of dates, or any combination of those qualifications. For example, if you manage a number of junior system administrators and you'd like to find out if one of them has edited an Apache virtual server configuration in the past week, this module makes those kinds of questions easy to answer (assuming logging to that degree is enabled, of course).
The Webmin Configuration module (Figure 3.1, “Webmin Configuration”) 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.
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 host names (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.
![[Caution]](http://swelltech.com/support/webminguide/images/caution.png) | Caution |
|---|---|
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. | |
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, although 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.
![[Note]](http://swelltech.com/support/webminguide/images/note.png) | Note |
|---|---|
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 miniserv.conf file, Webmin must be restarted for changes to take effect.
As mentioned earlier, Webmin provides very flexible logging features. With these features, you can very easily monitor what actions those users with administrator 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 host names will cause Webmin to provide a host name 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.
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, the username Webmin will use to login can also be configured on this page in the Username for proxy and Password for proxy fields.
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 host name 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. Be aware 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.
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 web server. 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.
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.
| Note |
|---|---|
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 200 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. | |
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.
| Caution |
|---|---|
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 are a number of commercial and Open Source efforts underway to provide such services within the framework of Webmin. At the time of this writing none are production-ready, but with the number of people pursuing the goal, it is likely that such a tool is not far off. | |
To clone a module, select the module to clone from the drop-down 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.
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 than the primary Squid process.
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.
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.
| Note |
|---|---|
In current versions of Webmin, at least up to 1.020, 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. | |
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.
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 appearance 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.
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!).
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 maximize 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 fool-proof, 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 user name. 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 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 mis-categorized into the Others category by default, so you may wish to manually move them to their more sensible locations using this module.
Instead of moving modules within existing categories it may be most sensible to create a new category for your favorite modules, or for custom modules written just for your organization. This page allows you to create new module categories, as well as rename or relabel old ones.
One of the more fun additions to the Webmin feature set is that of "themeability." Themes in Webmin are very flexible, allowing a theme developer to modify nearly every single aspect of the appearance 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 appearance. 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).
![[Tip]](http://swelltech.com/support/webminguide/images/tip.png) | Tip |
|---|---|
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. To force a refresh in Netscape, Mozilla and related browsers, press and hold the Shift key, while clicking the refresh button. Similarly, in Internet Explorer, press and hold the Ctrl key while clicking the refresh button. Themes can be chosen system-wide, or for an individual user in both Webmin and Usermin.
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.
In some circumstances it may be useful to have one or more Webmin modules accessible to any user, without requiring authentication. For example, it may be useful to allow users to view some read-only statistics about the server, or allow a user to mount or unmount a device using a custom command, or similar. Extreme caution should be taken when using this feature of Webmin, as giving users access to the wrong module can easily lead to an exploitable condition. To be more explicit, very few standard modules are harmless enough to be safely usable with this feature.
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.
This page allows you to configure the SSL certificate for this server. Using this, you may configure your system to allow logins without a user name 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.
| Caution |
|---|---|
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. This prevents the use of the login timeouts that are normally possible with Webmin, and so should be used with caution in environments where a logged in machine may be left unattended. | |
This page provides access to every Webmin server on your local network (Figure 3.2, “Webmin Servers”). Clicking any icon will direct your browser to the login page of the server clicked. Clicking Broadcast for servers will cause Webmin to send out a broadcast request to port 10000 over your local network. Every Webmin server on your network will reply and identify itself. Webmin will then add those servers to the list of servers. You may also scan specific networks for servers, if you manage Webmin servers remotely. Simply enter the subnet to search and click Scan for servers.
Clicking on a server icon will simply direct your browser to the Webmin port on the selected server, allowing you to log in. You may also configure Webmin to connect you to the server through a proxied connection, if you provide a user name and password for the other server. This can be useful when connecting remotely to a front-end Webmin server on the routable Internet that also connects to a non-routable private network, allowing an administrator outside of the private network to tunnel through to administer systems inside the private network.
Versions of Webmin beyond 0.85 provide support for some functions to be executable via remote procedure calls, if login information is provided for the remote server. This allows a single Webmin server to directly configure or monitor other Webmin servers. Currently this functionality is limited to the System and Server Status module and some of the modules in the Cluster category. It is likely that many of the other modules will expand to take advantage of this new functionality in the future.
This page allows you to configure any number of users and give each some specified subset of the system to maintain. It would allow you, for example, to create a mail administrator who only had access to the Sendmail module, a DNS administrator who could only modify the DNS records, and a Squid administrator who only had permission to edit the Squid configuration. In this way, delegation of authority is very simply and securely handled.
To edit a Webmin user and the modules they have access to, click on the name of the user on the Webmin Users index page. Each user has a list of accessible modules, and a number of additional options that can be configured. From the Edit Webmin User page, it is possible to change the users password, select an SSL certificate for them to use for authentication, alter the language and theme from the default, and specify the IP addresses from which this user can login. Also on this page is a list of all modules that are installed on the machine, each with a check box beside it. If checked, the user will have access to the module.
Webmin also allows finer grained control over many modules, and this functionality is becoming more flexible with every release (Figure 3.3, “Editing User Access Controls”). For example, a user with permission to use the Apache Module can be denied the ability to edit some specific aspects of the configuration. In the example below you can see that the user is being granted permission to edit only one of the many available virtual servers. To edit fine grained access controls, browse to the Webmin Users index page, and click on the module name link beside the user whose access controls you wish to edit.
Creating new users is also easy. Click the Create a new Webmin User link and choose a user name or use one of an existing user on the system (Figure 3.4, “Create Webmin User”). Choose between using the users UNIX password, or choose a new one. Select which modules the user will have access to, and click Save. Now you can edit the fine grained access controls for the user, or accept the defaults. Adding or deleting modules from the users access list can be performed by clicking on the user name from the Webmin Users page, and then editing the user in whatever manner is required.
Webmin, like UNIX, understands the concept of groups. Groups in Webmin are similar to UNIX groups in that they ease administration of heavily populated servers by allowing easy creation of any number of users with the same set of permissions and access controls. To create a group click on the Create a new Webmin group link, give it a name, and select the modules that members of the new group should have access to. After saving the new group, any user can be assigned to the group and automatically receive the module access of the group, plus whatever modules are specified for the user. Currently users can only be a member of one group, so the Webmin groups feature is somewhat less flexible than that of most modern UNIX variants and Linux where users can be members of a primary group in addition to a number of supplemental groups.
Because Webmin runs with the privileges of the root user, it is vitally important that Webmin be locked down tightly before allowing remote Internet access. Historically, Webmin is pretty secure, but there have been exploits discovered in the past, and there will probably be exploits discovered in the future. Any tool which runs as root has the potential to be an entry point for a malicious cracker to unlimited access to the machine.
So in order to prevent all of the woes that can result from an exploited machine, we're going to take a few steps to limit our risk, and minimize the damage that can be done without us noticing. We will briefly discuss password policy, application level network access control, SSL, and firewall configuration. The tutorial will wrap up with a survey of some other techniques and technologies that can be used to help maintain a secure system.
Countless studies and anecdotes from both sides of the security issue (crackers on one side, and those who implement systems to protect against crackers on the other) have told us that cracking weak passwords is nearly always a reliable, if time consuming way to obtain illicit entry into a system. Because many users, and even system administrators use weak, easily guessed passwords, it is quite common for a determined hacker to run an automated password hunt on a target system. Another, perhaps even more frightening, technique crackers use is what is known as Social Engineering.
Social Engineering is a technique as old as malicious cracking itself, which plays on human nature to overcome technical barriers to entry by going the easier path of getting through a humans line of defense. One common technique is for a cracker to pose as tech support staff, and simply ask for the users password so they can "test" something or other on the network. This works disturbingly often, even among technically savvy users. This type of attack can happen via any communications medium, including telephone, IRC, email, etc. and its continued success relies on the human desire to be helpful. This technique is often enhanced through the use of other subtle additions to further lower the guard of the person answering the phone or email. The cracker may mention that there is a "problem" on the network, of some sort, which taps into another fundamental aspect of human nature: complaining about the state of the network. Everyone complains about the state of the network in an office at one point or another, and when a "tech" calls to say he is going to fix it it further establishes his credibility with the victim. In the users mind, it seems obvious that no outsider would know about the "network problems" he has been experiencing lately, so this caller must be legitimate.
In my time of supporting UNIX servers I've noticed another aspect of human nature that is sometimes exploited by crackers. When asked to type in their password, some users spell it out quietly under their breath while entering the letters. Experienced typists are far less likely to speak the text they are entering in this way, but it may be a last resort trick used by a Social Engineering cracker to simply ask the user to type in their password a few times (because by the second or third time, the user is either excited enough to be taking part in "solving a network problem" to begin talking or singing along with their text input or be frustrated enough at being kept away from his real work to start muttering along with what he is typing). Users should be cautioned against this habit. This may all sound like a rather silly way to break into a network, when Hollywood movies always show us a lone cracker in a basement filled with computer junk, but it is likely that the most determined, and thus the most dangerous, crackers will use these techniques before attempting more time consuming technical attacks like brute force password searches. These techniques work, if users are not aware of the danger.
This only scratches the surface of how crackers operate. But it does begin to make it clear that good passwords and educated users are a core part of any successful security policy. Insist upon quality passwords, and notify your users of the policy. A good password policy might include the following requirements:
- Minimum Length
A good password should be a minimum of 6 or 8 characters. All other things being equal, longer passwords are more secure than shorter passwords, simply because a brute force attack has more possibilities to go through to find a password that works.
- No Dictionary Words
It is generally recommended to avoid plain dictionary words, or even dictionary words at all. The reason for this is that brute force attacks usually involve attempting all of the words in a word list, or in a dictionary file. Real words are simply easier to guess and easier to obtain through brute force attacks. Weird spellings, odd capitalizations, and combinations of word fragments can all be used to create less easily guessed passwords without making them much less memorable for the user. After all, if the user has a drawer full of their passwords on sticky notes because they can't remember them, the cure is worse than the disease.
- Include Numbers
Another good possibility is to enforce the inclusion of at least one number in all passwords. This automatically increases the pool of possible passwords by an order of magnitude, even if dictionary words are allowed. Again, this doesn't make passwords significantly less memorable for the user, but does increase the security of the password. However, use of birthdays, anniversaries, etc. should be discouraged as these are easily guessable, and more prone to Social Engineering attacks.
- Scheduled Password Changes
In environments where security is important, it is wise to implement a mandatory password change after some specified period of time. The inconvenience to users of this choice should be carefully balanced against the security needs of the environment. It is less useful if frustrated users alternate between two passwords because they are being forced to change them every two weeks, or even worse if they write them down somewhere in their desk because they don't want to take the effort to remember a new password every week. Once every 6 months is probably frequent enough for all but the most extreme circumstances.
- Failed Login Timeouts
In the event that a cracker attempts a brute force attack on your server, password timeouts can be very effective at making the process extremely time consuming, or even impossible. Going on the assumption that a user usually will not mistype their password more than a few times, many authenticators can timeout and refuse to allow any login for that user for a specified period of time after that number of failed logins is reached. With this feature enabled, it becomes a daunting task to use brute force password searches to break into a system that has password timeouts of this sort. It can potentially increase the time it takes by months or years, and the likelihood of detection of the scans considerably since one or more users will begin to complain of being unable to login (since their password is in a state of timeout most of the time).
- Education
This is perhaps the most important in light of the prevalance of Social Engineering. Users of the network, both new and old, should receive training about the password policy, why the policy has been implemented, and how to use the tools required to take part in the new policy. This training doesn't have to be a large investment in time, effort, or money. In high tech environments, a simple email reminder with the policy and instructions sent out every month to old users and immediately to new users could be enough. In traditional business, education, or government, environments it may be better to schedule a one hour group lecture the first time in order to explain both the whys and the hows, followed by a question and answer period. It is also vitally important that users understand that no one should ever ask for their password, and they should never give out their password to anyone, no matter who they claim to be. It might also be appropriate to make clear that the real system admnistrator doesn't need a password to log in as any user, and thus would never need a users password to test or fix anything.
| Caution |
|---|---|
Some of these policy choices cannot currently be enforced with Webmin. As of version 0.970, only password timeouts are available. Even so, encouraging users to use secure passwords, and more importantly for you as an administrator, using good password policy, can achieve the same goals without enforcing them. It is likely that Webmin will have all of these features in some form or another in future revisions. Your underlying OS variant probably supports some or all of them, as well, for system passwords. Educating users about these issues becomes more important when policy cannot be enforced via technical measures. | |
As discussed above, a carefully considered password policy can be very helpful in defending against crackers. Webmin provides a simple means to enforce some aspects of password policy for Webmin users in the Webmin:Webmin Configuration:Authentication module. Here you may choose to enable password timeouts, and automatically block hosts that appear to be running brute force attacks on the Webmin server.
Also, enabling logging of failed login attempts is an excellent idea, assuming someone will read those logs on occasion. It is possible using tools like logwatch to automatically be notified via email of some types of logged data. While logwatch is not currently configurable within Webmin, it is well worth your time to read up on this utility, or any similar tool provided by your OS vendor and to make use of it to help ease the burden of administering a system. To enable logging of authentication failures, browse to the Webmin:Webmin Configuration:Authentication module, and select Log blocked hosts, logins and authentication failures to syslog Disable session authentication. Then you may configure any log analysis tools you use to flag these authentication failures so that a human administrator can watch for signs of cracker activity.
| Note |
|---|---|
The logwatch utility is Open Source software, available from www.logwatch.org. The program is maintained by Kirk Bauer and is included with many Linux distributions. Other OS variants often provide similar functionality | |
As discussed earlier in this chapter, Webmin provides a few mechanisms to provide network level security to your Webmin installation. Utilizing some or all of them can increase security immensely, without adding complexity to the deployment. The primary purpose of these features is to allow Webmin to refuse to even talk to someone on an address that is not allowed to login.
To begin, take a look at your network topology diagram, or write down your local network information, if your network isn't large enough to justify a full diagram. Then write down the network information for every user that must be able to access your Webmin server. This may get complicated rather quickly, if you have dial-up or other remote users who need to log in from dynamically assigned IP addresses, but even in such cases it may be possible to reach a viable compromise.
The first step, is to decide if you can restrict access to one particular network interface on your server. If your Webmin server has a non-routable local address and a routable Internet address, you should decide whether anyone will ever need to be able to access the Webmin server from outside of your local network. If not, simply configure Webmin to listen on the local interface. This can be configured using the Webmin:Webmin Configuration:Port and Address module by selecting the radio button beside the Listen on IP Address option, and entering your internal IP in the entry field.
Before moving on to other items, it may be worthwhile to consider moving Webmin to another port. Webmin being on port 10000 leads to one additional type of possible exploit, that would be difficult for a cracker to take advantage of, but is probably not impossible for a local user. Because port 10000 is a non-privileged port, any user with login permission on the server could start an arbitrary server that listened on that port, if Webmin were not currently running on the port. Once a local user is able to start a server on port 10000, it is trivial to setup a web server that looks like the Webmin login page, but in fact is just a simple CGI script in the users home directory. If the system administrator then attempts to login, his password can be grabbed and stored for the user to pick up later (or worse, mailed out automatically as soon as it has been grabbed). A particularly clever script of this sort could delete itself after its job is done, and even restart Webmin so the administrator will believe they simply entered the wrong password when they attempted to login the first time. One solution to this problem is to simply run Webmin on a port below 1024, as these ports require root permission to bind to, so a malicious user would not be able to run a password grabbing trojan on the same port, and thus would not be able to fool anyone into entering their authentication information.
| Note |
|---|---|
In some OS variants and versions, it is possible to control which users can bind to any port, whether above or below 1024. This feature is sometimes known as capabilities or ACLs. A proposed, but then withdrawn, specification labeled POSIX.1e provided some of the capabilities that are supported by some Linux versions. With features of this sort it may be possible to make port 10000 behave just like a sub-1024 port, but availability of this kind of feature varies wildly, so it will not be covered here. In the vast majority of environments, it makes sense to run Webmin on port 1000, or if connectivity through very restrictive proxy firewalls is required, port 553. | |
The next step is to setup application level IP access control to your Webmin installation. If you have only static, or local addresses that should have access to Webmin, then your job is simple. Just open the Webmin:Webmin Configuration:IP Access Control module, and select the Only allow from listed addresses radio button, and then enter all of the addresses or host names that must have Webmin access.
If, however, you have users who will be accessing Webmin from dial-up connections, or some other form of dynamic link, you cannot know in advance what IP address they will need to log in from. In some cases this can be mostly worked around, if you have a friendly ISP who will provide a list of their IP blocks. With the list of all possible addresses on which your dial-up users may come in on, you can severely limit the percentage of Internet users who can access your Webmin installation, simply because a single ISP only represents a tiny number of the total addresses on the Internet. This is, for lack of a better term, Good Enough. Obviously, large nationwide ISPs are not generally helpful enough to provide this information for you, but if you are lucky enough to have a service-oriented local or regional ISP, you will likely find the technicians to be quite helpful.
If address based access control is not feasible due to needing nationwide dial-up access or similar, it isn't the end of the world. Assuming systems are kept up to date, and other security policies followed, it is highly unlikely that your Webmin server will ever expose an exploitable condition to crackers.
| Note |
|---|---|
Webmin version 1.000 and above provides the option to do a host name lookup for every user access. The result of this will be that a dynamically assigned IP with a DNS entry with DynDNS, or a similar service, will be able to be checked against the IP Access Control list, just like a fixed address. This is not efficient if you have more than a few domain names entered in the IP Access Control list, due to the high overhead of performing a name lookup for every host name in the list on every request. But it can be very useful if you have one or two administrators or users who travel or simply don't have a fixed address at their normal location, because they can have a domain name that follows them wherever they go, and this name can be used to allow them access. I use this feature for the swelltech.com web server, since it is remotely located and I often access it from my dynamically-assigned home ADSL link. | |
Webmin is a web-based application, thus it operates using the standard protocols of the Internet and specifically the HTTP or HTTPS protocol. In a default installation from tarball or package, Webmin operates via the standard unencrypted HTTP protocol. In some environments this presents no major security threat, but in most situations this is a quite large hole in the security of a Webmin installation. If you only access Webmin across a local network of only trusted clients, and have a firewall closing your local network to outsiders, then you may feel safe in using Webmin over an unencrypted link. Otherwise, if you ever access your Webmin across the Internet or an intranet that may have untrusted clients (for example, a laptop owned by an outside consultant, temporary employees, etc.) encryption should be considered mandatory.
Luckily, setting up Webmin for use with SSL connections is pretty simple, and requires only installation of two other packages: OpenSSL and the Perl Net::SSLeay module. Here we'll briefly discuss installing these tools from source, though it is even easier if your OS vendor provides binary packages. Documenting the actual installation process will be left for the included documentation of these packages.
OpenSSL is an Open Source implementation of the Secure Sockets Layer protocol (SSL), as well as the Transport Layer Security protocol (TLS). It provides strong encryption library routines that are easy to integrate into other software, and is thus used quite frequently in Open Source projects requiring encryption. Because of this, if you are using any modern Open Source operating system, like Linux or FreeBSD, you probably already have OpenSSL installed on your system or can get a package for your OS that is simpler to install.
OpenSSL is free software, and can be downloaded from the www.openssl.org homepage, or one of its many mirrors. Download it to the server running Webmin. If you don't have a graphical browser installed, or are accessing your server remotely you can use lynx or wget to fetch it from the website. If no text mode HTTP client is available, you can get the file from the ftp.openssl.org FTP site instead. I've never seen any Internet capable operating system that does not have at least one text-mode FTP client available. Even Windows includes a simple FTP client for use in the MS-DOS shell! To install simply follow the instructions found in the INSTALL document included in the source distribution.
Because Webmin is written in Perl, it needs a Perl interface to the OpenSSL libraries. The standard choice for this is the Net::SSLeay module, which can be downloaded for free from CPAN or one of its mirrors. You may also be able to download a packaged binary version from your OS vendor.
Webmin itself offers a module for managing and installing Perl modules on your system. Using this module, documented later in this book, you may be able to install the Net::SSLeay module using this module. On my test systems (mostly Red Hat Linux of varying versions) I could only successfully install using the Webmin module if I left out the make test option, selecting only make and install. No additional arguments were required, however.
If a package is not provided by your vendor and installation via Webmin fails for some reason (and there are several reasons why it might), simply visit the Comprehensive Perl Archive Network (CPAN), and search for "SSLeay" to get the latest version. After downloading the tarball, unzip and untar it:
[joe@grover /joe]$ tar zxvf Net_SSLeay.pm-1.15.tar.gz
Or, if your OS doesn't use GNU tar you may have to unzip and untar in two+ steps:
[joe@grover /joe]$ gunzip Net_SSLeay.pm-1.15.tar.gz
[joe@grover /joe]$ tar xvf Net_SSLeay.pm-1.15.tar
Change directory to the newly created Net_SSLeay directory. Run the Makefile.PL using Perl, like so:
[joe@grover Net_SSLeay.pm-1.15]# perl Makefile.PL
Assuming no problems arise, this will generate a standard makefile suitable for your system. If OpenSSL was installed from an RPM, you may need to explicitly specify the /usr directory on the command line, though it appears to be unnecessary in new versions the module. But if it complains about being unable to find an OpenSSL installation you can try the following:
[joe@grover Net_SSLeay.pm-1.15]# perl Makefile.PL /usr
Next, use make to build, test and install the module into the correct location. The command sequence is as follows (don't forget to switch user to root before the install phase):
[joe@grover Net_SSLeay.pm-1.15]# make
[joe@grover Net_SSLeay.pm-1.15]# make test
[joe@grover Net_SSLeay.pm-1.15]# su
Password:
[root@grover Net_SSLeay.pm-1.15]# make install
Finally, test to be sure the module is installed, using the following command line:
[root@grover Net_SSLeay.pm-1.15]# perl -e 'use Net::SSLeay; print "Success!\n"'
Success!
If the result is only the word Success!, then the module has been successfully installed. Otherwise, if you see an error regarding Perls inability to find the module, it is not installed correctly.
Now that the correct additional tools are installed, all that is left is to turn on SSL connections in the Webmin configuration. This can be done from within Webmin itself, or if you're particularly paranoid and don't want even want to login once over an unencrypted connection you can edit the configuration file manually.
To enable SSL connections using Webmin, browse to the Webmin:Webmin Configuration:SSL Encryption page, and click the radio button labeled Enable SSL support, if available. Click save, and you will automatically be redirected to the https port and connected via an SSL link.
To enable from the command line, for example from a SSH login or a direct console login, edit the miniserv.conf file, usually located in /etc/webmin or possibly /usr/local/webmin-0.980/etc, where 0.980 is replaced by the version of Webmin you have installed. The option to modify is ssl=, which defaults to 0 (off). Changing it to a 1 and restarting the Webmin server will enable SSL connections. You can then login on the HTTPS port as documented earlier.
As in the earlier discussion of IP Access Controls, the goal when constructing a set of firewall rules is to prevent access to sensitive ports by unknown persons. If, for example, you can restrict the external network addresses that can talk to your server on port 10000 (or 1000, depending on the port you choose to run Webmin on) you can very easily make it impossible to exploit your Webmin installation via most types of attack. This is perhaps a bold claim, but it is easily provable assuming one can trust the firewall to do its job.
Unfortunately, the Internet is a world of trade-offs and constantly changing conditions. Sometimes, you simply cannot lock down your machine using a firewall without locking out all of the people who need to use it. If you remotely manage your server via a dial-up connection, the firewall clearly cannot be restricted to allowing only one IP. So compromises are required. As in the IP Access Controls, an ideal world would allow you to restrict access to only one or two external IP addresses (and some or all of the IP addresses within your own local network), but most likely you'll have to allow large blocks of IP addresses to account for dynamically assigned addresses on dial-up, DSL and Cable Internet connections. As before, if you have a helpful ISP, you'll be able to obtain a list of the network blocks that may be assigned to you.
Firewall configuration is outside the scope of this book, but adding protection for Webmin to an existing firewall is usually trivial. If your network does not yet have a firewall of some sort, it is well worth your time to research the options and implement a reasonable firewall. If you are using a free UNIX-like system like FreeBSD, Linux, OpenBSD, NetBSD, etc. you already have access to a very flexible firewall system. All that will be needed is a few hours or days to study the implementation of such firewalls, and a few minutes to construct an appropriate ruleset (just don't forget to protect the Webmin port!). Users of other UNIX OS variants may need to purchase a firewall package from your vendor, or a free firewall system may be available for download.
Security is a many-sided problem, and as such, a number of tools have been developed to help an administrator implement a highly secure system. In the preceding four sections, I've addressed the first line defensive techniques and how they can be applied to Webmin. Those techniques are designed to prevent intrusion in the first place. They do nothing to let you know an intrusion has taken place, nor do they respond proactively to an attack that is underway. Therefore, it is worth taking a brief tangential look at some intrusion detection tools, and attack response tools.
There are a large number of free and commercial intrusion detection systems available for all of the major UNIX variants. An IDS provides an easy method of auditing one or more systems to insure that they have not been exploited. Most such systems create a database of file identifier keys (usually an MD5 hash, or similar strongly encrypted key), which is also encrypted with a passphrase known only to the system administrator. Some systems provide an easy means to store the database on another machine, or it can be written to a floppy or CD for use in a read only mode, so that even if the machine is violated tampering with the file key database is impossible rather than merely extremely difficult.
Perhaps the most popular IDS for free UNIX systems is Tripwire, which is available in both an Open Source and proprietary version. It is available in package form from many Linux distribution vendors, and source downloads for all supported operating systems. Tripwire uses a database of MD5 keys, which is generated on a known secure system. Using a simple cronjob, tripwire can then be run periodically to insure no unexpected changes have occurred on the system since the last database generation. Using two passphrases, it is possible for tripwire to prevent unauthorized tampering with the database (for example, a cracker regenerating the database after having modified all of the files needed for future entry).
| Note |
|---|---|
The Open Source variant of Tripwire can be downloaded from www.tripwire.org. A thorough reading of the documentation is recommended before attempting to use it, because though it is relatively simple to use, the required steps for initial setup and database generation are not at all obvious. | |
Another simple but effective intrusion detection method for systems that use RPM or any other package manager that keeps a database and can verify file integrity, is to keep a copy of the package database on another system, or stored on read only media. With this database and a known good installation of the package manager, one can verify all of the system files quickly and easily. The drawback of this method is that it cannot detect new files and modification of files that were not installed from packages. If no proper intrusion detection system is available, this can be a life saver in the event of an intrusion on a system that has no complete IDS installed.
Some pitfalls to watch for in the event of an intrusion, is that once a cracker has gained access to your system with root privileges, there is nothing to prevent him from modifying the tripwire or package manager binaries to prevent them from reporting good results even after all of their changes. Such a modification is usually obvious to an experienced administrator, because normal file changes should show up in such checks, and over time those changes will probably not be accurately reported by the cracked IDS or package manager. This problem is most easily worked around by installing secondary versions of these tools and running them against a database stored on read only media, like a CD or floppy disk with writing disabled. While a cracker with the knowledge to make these changes is rare, it is likely that such ideas will eventually be included in rootkits making it easy for even the most brain damaged cracker to thoroughly cover his tracks pretty effectively.
There are several new tools designed to recognize common types of attack and respond to them quickly enough to diffuse the attack. There is no single name for such systems, and the way in which they work varies depending on their particular focus. Two such tools are PortSentry and Hogwash.
PortSentry is the most mature of these types of tool, and takes a more basic approach to the problem. PortSentry keeps an eye on network connections, and watches for a rapid series of abnormal connections that is usually indicative of a network scan. When such a scan is detected the host from which the attack originates is simply blocked using the normal packet filter on the system. PortSentry is made more attractive by the fact that a Webmin module exists to easily administer and configure a PortSentry installation.
| Note |
|---|---|
PortSentry, like Tripwire, is available in both commercial and Open Source versions. The Open Source release is available for download from www.psionic.com | |
A newer entry into the field, Hogwash uses a rule based system to detect hundreds of known exploit types, and can drop those packets without disturbing any other kind of traffic from the host. Hogwash is based on the rule engine of the Snort network intrusion detection system, but adds the ability to respond to the intrusion by dropping or disarming the troublemaking packet by rewriting it to a harmless form.
Tidak ada komentar:
Posting Komentar