Data Circle

If you’re running SpamAssassin on your servers you might want to check out this critical bug: FH_DATE_PAST_20XX scores on all mails dated 2010 or later. Broadly speaking, all emails with a Date: field of 2010 will trigger a SpamAssassin rule, which means that the mail will be more likely (but not definitely) to be marked as spam. Running sa-update as root fixed the problem on my system, as this updates the SpamAssassin rules. The fix is only temporary, as it will flag up mails from 2020 onwards, but hopefully the developers will have implemented a more permanent fix by then.

After some comments about security recently on the Bytemark IRC channel, I started to look through the logs for the various services which I run on my servers to see if there were any obvious security holes which needed plugging. Most services seemed secure, and I’d already cracked down on spam, but I did notice a lot of failed login attempts for ssh in the authentication log (/var/log/auth.log on Debian systems if you want to check your own). Every so often, there would be a burst of login attempts from a given IP address, which would either attempt to brute force the root password or try to login to common account names (e.g. guest). I only have a small number of accounts on my servers anyway, and the root passwords are all strong, so I wasn’t too worried that any of these attempts would succeed, but nevertheless I wanted to take some steps to reduce or eliminate them.

First, I considered reporting the offending IP addresses to their netblock abuse contacts. Unfortunately many of the connections came from Brazil or China, where I don’t expect to get a response. Even when I contacted European ISPs with logs of what machines on their netblock were doing, I didn’t receive any replies, though it’s possible they took action and couldn’t tell me about it.

Since trying to get the netblock admins to tackle the problem at its source didn’t do much good, I decided to deploy some technical measure instead, namely:

1. Disabling root logins over ssh.
2. Moving ssh to a different port.

Disabling root logins does what it says on the tin, i.e. you can prevent anyone from logging in as root over ssh, even if they provide the correct password. The response from the server is the same as if an incorrect password was entered, so they will not know that you have disabled this feature. The relevant setting can be found in the ssh config file (/etc/ssh/sshd_config on Debian):

PermitRootLogin no

If this is currently set to PermitRootLogin yes, simply change the yes to no and reload ssh (/etc/init.d/ssh reload). You’ve now effectively blocked anyone from brute forcing your root password over ssh, although the login attempt messages will still appear in your logs.

Moving ssh to another port is the second effective method of stopping people from trying to brute force their way into your machine. By default ssh runs on port 22, but there is no reason why it needs to, other than convention. You can easily change the port using the following directive in the ssh config file:

Port 22

You can change the value to anything you want, so long as another service is not running on the same port—e.g. don’t change to port 80 if you’re already running a web server. Most brute force login attempts will come from automated programs which assume that ssh is running on port 22, so if you move the service to another port they will simply receive a ‘Connection refused’ error message. Making this change has, as of the time of writing, completely eliminated all the failed login attempt messages in my authentication logs.

You could of course go one step further and only permit ssh logins from users with keys or from specific IP addresses, but that creates a degree of management overhead which you may not wish to bear. In my case, I access four different servers from various locations and machines, so it’s simply not practical to use such a tight restriction.

Other ssh security tips which you might want to try if you are really paranoid include:

1. Use fail2ban to scan your log files and automatically block any IP addresses which produce too many failed login attempts.
2. If you have multiple IP addresses, limit ssh so that it only runs on one of them, using ListenAddress.
3. Throttle ssh connections so that only one connection per IP address can be made in a given length of time – e.g. every minute. This will significantly slow down any brute force attempts.
4. If you don’t need ssh, simply disable it entirely (this is probably not an option for most administrators though).

Hopefully these tips will help you to lock down ssh, as it’s in all our interests for machines on the Internet to be as secure as possible.

If you’re still running Internet Explorer, you should probably be aware of a critical security update which Microsoft released yesterday, which you can get either via their website or through Windows Update. If you have automatic updates enabled, the patch may be downloaded and applied the next time you switch off your machine, though with something like this you might want to double-check anyway. All the cool kids are running a more secure browser now, but even if you don’t use IE but still run Windows I’d strongly recommend patching your browser.

Phishing, the art of obtaining information from users by pretending to be from a reputable known source, is surprisingly effective, despite attempts by numerous organisations (particularly banks) to educate users about this issue. Recently, the University of Manchester, where I’ve been a student for nearly five years, was hit by a barrage of emails pretending to be from IT Services (the department which runs most of the University’s email, amongst other things) which encouraged students and staff to reply with their username and password. Unbelievably for an organisation which supposedly consists of intelligent people who are working towards obtaining one of the highest qualifications in the country, more than seventy people replied with their login details. As a result, millions of spam messages were sent from University accounts, causing some major mail providers, including Hotmail, to block all incoming mail from manchester.ac.uk addresses and their subdomains.

Phishing relies upon the fact that it doesn’t matter if only one in ten thousand people are completely lacking in common sense (given the University’s size, it’s probably actually more like one in five thousand)—spam enough of them and you’ll eventually get some hits. It amazes me that people still fall for this trick, because to me it seems so painstakingly obvious that a bank would never ask for information such as your PIN, but it would appear that the message has still not got through to everyone.

The latest version of the Firefox web browser has been released. If you haven’t already upgraded, you should go to Help->Check for Updates or use your package management software to download the latest version as soon as possible, because there are a number of security fixes included in the update. The full release notes can, as always, be found on the official Mozilla website.

LiveJournal XSS Security Challenge at Slashdot

LiveJournal has launced an XSS Security Challenge which currently offers a free permanent account (like a paid account but does not have to be renewed, plus there are some other bonus features) to anyone who finds a Cross Site Scripting (XSS) security hole in the CVS code for the site. There’s also the possibility of additional rewards later on, once the Six Apart lawyers have decided on any rules for the challenge. If you know a reasonable amount about JavaScript, you could be in with a chance to not only fix a bug in software used by millions of people every day but also collect a bounty at the same time. What more could you ask for?