(This is a bit of a rant. There may well be more rants to come.)

If you say to a security professional, ‘I’m going to run my ssh daemon on an unusual port for security reasons’, you’d better stand back and wait for the gasp. *gasp* they say! That’s just security through obscurity, which is no security at all! Shut down your servers and turn the lights off on the way out, you worthless collection of mucus.

‘Security through obscurity’: it even rhymes, which means that it joins the list of empty phrases that sound like they carry authority but actually don’t. ‘It’s Adam and Eve, not Adam and Steve!’ ‘White is right!’ Ohhh I seeeee: there was me thinking you were just a bigot, but your argument rhymes, so it smartly trumps anything I could possibly say!

Seriously though, I think that StO (to save some typing) is an indispensible part of network security. Clearly such a measure will be worthless against a Mitnick-style social engineer worming his way into your organisation in a dozen different and inventive ways. Nor should it be your only line of defence: that really would be stupid. But it is an excellent way to mitigate against the biggest threat to your average public-facing service: automated attacks.

If you run a webserver, mail server or a machine with a public-facing ssh daemon, you’ll know all about automated attacks. They can range from the mundane


sshd[1690]: Invalid user oracle from 94.249.x.y
sshd[1692]: Invalid user test from 94.249.x.y
sshd[3099]: Invalid user nagios from 66.23.x.y

to the downright rude


31.3.x.y - - [08/Sep/2011:02:45:45 +0100] "GET soapCaller.bs HTTP/1.1" 400 291 "-" "Morfeus Fucking Scanner"
58.218.x.y - - [08/Sep/2011:14:59:44 +0100] "GET http://www.silkool.com/cgi-bin/son!fuckyou.php HTTP/1.1" 403 290 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

but if you run such a service, you’ll see this sort of stuff many times a day (and if you don’t at least skim through your logs every day, you get a little slap). The ssh brute-force attack is trying to guess username/password pairs, while the first HTTP attack is looking for a vulnerable script to exploit (the second is seeing if your webserver is stupid enough to let someone use it as a proxy).

How could we use StO to mitigate this kind of threat? Well, the scripts that run these attacks aren’t trivial, but they are looking for easy targets. I’m not going to get into an exhaustive discussion of StO methods, but a good example for an ssh service is port knocking. This means that the ssh daemon won’t talk on port 22 until a connection has been received on some other port. If the clients can cope, we could even run the daemon on a different port altogether. Although ssh daemons identify themselves very obviously when they start talking to a client, I’ve never seen an ssh exploit search script that will try any port other than the default.

The same applies to webservers with some kind of privileged interface. There are lots of cases where it’s necessary to expose such an interface to the world: for example, you might run a project wiki where the admins are scattered around the world on dynamic IP addresses. If you called that interface http://your.domain/admin/ then you’re asking for it, as there are plenty of automated attacks that will find it. However, if you use http://your.domain/fnurk-squart-plurnb/ then no-one will ever guess it. Possibly including your users 🙂

So the StO rule is: try to avoid putting things where you might expect to find them. Obviously some things have to use the default (you wouldn’t get much mail if your SMTP server was listening on port 6239), but there are plenty of changes you can make to stop those scripted attacks. Pick unusual port numbers and block the default ones at your firewall; hide admin interfaces behind unusual addresses; call admin users something other than ‘admin’.

Well, you get the point. I feel a bit better for ranting 😉