Tightening Security on SSH & Webmin

I haven't finished moving everything over to my new servers yet however I am getting a few opportunities to look into new things and today I made a couple of changes to tighten up security.

In the greater scheme of things I'm not what you'd consider to be a prime target. I'm not mega-corp and I doubt there's anybody out there who hates my guts or wants to get into my systems in the hope of finding secrets. On the other hand, the fact that I am small-fry implies that I probably won't have paid too much attention to security issues and may be an easy target for being turned into a spam relay or similar i.e. the attraction of my server to a cracker is not what they might find on it, but what they might be able to use it for if they can get in.

A few days ago for example I awoke to a Logwatch report that telling me that another server at the farm where mine lives had made 400+ attempts to log into my server using SSH. I emailed tech support and got a reply about 15 minutes later saying that they'd checked it, shut it down, and emailed the owner. Now it's hardly likely that the owner of that server had instigated the attack, however they would be left with the big pain in the ass problem of finding out how their server was hacked and dealing with it. Obviously I want to do everything I reasonably can to make sure the same thing doesn't happen to me.

I am fortunate (by design) that I'm the only person who needs to log into my server. Thus I don't need to worry about other users having inadequate passwords or installing problematic scripts/programs. I have a firewall, and have shut down any services that I don't use (like telnet and ftp), so you might think I'd be happy to sit back an relax. However, as I am the only person who needs to use SSH or Webmin, (pretty powerful tools), I figuered that there were probably a few ways that I could make it harder for anybody to abuse them.

The most important line of defence is of course to have good passwords and if you don't know what I mean by 'good passwords', you need to do some research. If you are 99% sure that you do know: that's not good enough and you still need to do some research. If you are 100% sure then you are being way too arrogant and you still ought to do some research. The things is that this stuff changes and what we thought was a good password 10 years ago is mediocre by today's standards because the knowledge and tools available to the crackers is more powerful. Unless you did it just last week, do a search and read half a dozen current documents about passwords. If you find anything in any of them that you didn't know, read half a dozen more. My own current thinking on the subject can be found here.

Starting with SSH then:

It's fairly normal for my Logwatch reports to show a few hundred (occasionally a few thousand) failed attempts to log in via SSH. These are generally split between a dozen or so IP address (that change on a daily basis so there's little point trying to block the addresses), and several dozen common names. Amongst all the toms, dicks and harrys who don't even exist on my server (but are fairly common user names generally) there are also a good number of attempts to log in as apache, root, mysql, and other names that are pretty much always present on any LAMP server.

A fairly simple but substantial increase in security therefore is to create a user with a really weird name (that looks like a password), give them an equally cryptic password, and make them the only user with access to SSH. While brute force attempts to log in via SSH will regularly try lists of common names, they are highly unlikely to try 'random' collections of characters. You've now made it just as hard for someone to guess a user name as it is for them to guess a password. Of course this also means that when you log in via SSH you have to use the weird user name and su to root before you can do anything. A small price to pay and it also means of course that anybody who did guess your weird username and the weird password now needs to guess your root password too. That's "something blooming difficult" three times in a row and probably equates to something pretty near to impossible.

Of course that doesn't stop the failed attempts from bloating my Logwatch reports (something I'm looking into and will report on later) but it does mean that I can safely ignore them.

Having now made SHH a heck of a lot more secure, my other concern was Webmin. Again, I'm the only person who needs to use it but when I do I go in as root so there's 'only' a password between me any somebody else getting in there.

I did some searching and found this document (amongst others) that had some interesting information about securing Webmin. My setup was already doing things like using it with SSL however I did opt to go into Webmin: Webmin Configuration: Authentication and change the number of failed logins required before a host is blocked and the time for which it is blocked. These were set at 5 and 60 seconds but I reckon anybody who gets their password wrong five times in a row shouldn't be allowed anywhere near a server in the first place. As we're blocking IP addresses (as opposed to users) however we don't want an attacker who's accessing the server via somewhere like Tiscali or AOL causing an IP address that's been temporarily allocated from a pool being blocked for long periods of time either. As I'm the only one who should be using Webmin on my server I changed the values to 2 and 600.