astradele

Naturally, after being hacked, my thoughts turned to prevention and detection tools. My experience with such tools, though, was fraught with false positives and frequent emails that I would simply skim and delete. Considering that the attack vector was successful due to a very weak password, I was looking for simple techniques to act as a safety net that weren’t too noisy on a regular basis.

There’s a lot of information and tools out there, more of them and more mature than the last time I looked a few years ago. Rather than go over what I looked into, it’s probably better to simply consider what I decided to use.

BTW, my server runs on Debian (testing); my workstations run on Xubuntu. The reason I switched to the Debian line is because of the superior administration, operations, and maintenace model ( i.e. apt-get). Similarly, I limited my tool use to what was available in the Debian and Ubuntu archives (which are substantial anyway).

denyhosts is pretty simple, but effective. The server maintains a /var/log/auth.log that notes all attempts to authenticate, in particular all attempts to use ssh to connect to the box. denyhosts periodically analyses that log, and adds repeat offenders to the /etc/hosts.deny file. That file is read used by services like sshd and inetd to block certain IP addresses before they are allowed to exchange a single byte with a service.

denyhosts is an ideal balance of convenience, flexibility, and accuracy. As a periodic script, it has very low resource requirements. Its configuration file is quite flexible in defining what constitutes denial (and whether the denial is permanent or temporary). The rate of false positives is quite low; I’m unlikely to forget my password five times in a row. Lastly, it direclty addresses the most common attack vector on my server: brute force dictionary attempts on the SSH port. As a bonus, my logfiles aren’t filled with denial attempts now.

This completely disables the ability to log in via SSH with a password. I rarely log in with passwords anyway. Instead, I create a private SSH key on each computer that initiates a connection with my server, and add the associated public key to my ~/.ssh/authorized_keys file. This is a very common technique. There’s a chance I’ll be temporarily inconveniened if I’m using a foreign computer or if a workstation gets wiped, but in practice, I can’t recall that ever happening to me. There’s always root access via the remote console through my ISP, anyway. This completely prevents the automated dictionary attacks I fell prey to.

TIGER, or the ‘tiger’ scripts, is a set of Bourne shell scripts, C programs and data files which are used to perform a security audit of UNIX systems. TIGER has one primary goal: report ways ‘root’ can be compromised.

I find Tiger pretty painless. It has spurious warnings, but it remembers which ones it saw last time, and it won’t email me about old ones – only new ones. It’s also easy to configure rules to filter out what you don’t care about, too. I rebooted my server at one point, and on Tiger’s next run I was informed that my firewall was off. I forgot to enable it on boot – oops!

I wrote a simple shell script to read the output of ifconfig and capture the number of bytes sent and received since the last run. I run the script every 24 hours, and have it set to email me if the number of bytes exceeds a threshold. I figure, if my server gets compromised, it’s for the bandwidth that it has, so I’ll notice quickly if my bandwidth usage spikes.

To that end, I also installed bandwidthd, which generates a webpage of daily/weekly/monthly reports on where my bandwidth is going, i.e. who my server is talking to. It was originally a bid memory/cpu hungry, but after reading the documentation, I learned that it was much more reasonable if I turned off the graphs.

passwdqc is a replacement for the default passwd related programs. It can be configured to strictly (or leniently) enforce various rules on password length, complexity, and composition. Most usefully, I find, is that it will suggest complex passphrases to you when setting a new password. This alleviates the temptation to use insecure passwords for lack of imagination. Here’s an example:

You can now choose the new password or passphrase.

A valid password should be a mix of upper and lower case letters, digits, and other characters. You can use a 6 character long password with characters from at least 3 of these 4 classes, or a 5 character long password containing characters from all the classes. An upper case letter that begins the password and a digit that ends it do not count towards the number of character classes used.

A passphrase should be of at least 3 words, 8 to 40 characters long and contain enough different characters.

Alternatively, if noone else can see your terminal now, you can pick this as your password: "grade:sadly!hearty".

These were all simple steps. The work was in discovering what was out there. I also took some other minor precautions to protect my data that I have on my server – encrypting files, restricting home directory permissions, etc. Anyone who hacks my server is unlikely to be interested in my personal files, but I find it an uncomfortable thought anwyay.

Now that I’m done all the work restoring and securing my server, I’m not completely unhappy that I was hacked; at least I learned a few things useful for the future.