Tutorial: Securing Webmin

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 that 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.

Password Policy

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 human's line of defense. One common technique is for a cracker to pose as tech support staff and simply ask for the user's 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, and so on, 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 user's 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 six or eight 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, and so on 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 six 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 because one or more users will begin to complain of being unable to log in (because their password is in a state of timeout most of the time).

Education

This is perhaps the most important in light of the prevalence 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 administrator doesn't need a password to log in as any user, and thus would never need a user's 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.

Setting Authentication Policy

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 [http://www.logwatch.org]. The program is maintained by Kirk Bauer and is included with many Linux distributions. Other OS variants often provide similar functionality.

Setting Network Access Controls

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 log in.

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.

Setting the Listen Address and Port

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 nonprivileged 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 set up 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 log in 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.

IP Access Control

The next step is to set up 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, because it is remotely located and I often access it from my dynamically assigned home ADSL link.