Wandering Thoughts archives

2018-07-06

Having your SSH server on an alternate port provides no extra security today

Every so often I either hear someone say that having your SSH server on a non-standard TCP port provides extra security or get asked whether it does. On today's Internet, the simple answer is no, it doesn't provide any extra security, or at least that it shouldn't. To explain that and convince you, let's talk about the two risks that your SSH server opens you up to. Let us call these the the scattershot risk and the targeted risk.

The scattershot risk is mass SSH password guessing. Pretty much any system on the Internet with an open SSH port will see a legion of compromised zombie machines show up to repeatedly try to guess username/password combinations, because why not; if you have a compromised machine and nothing better to use it for, you might as well turn it loose to see if you can get lucky. Of course SSH is not the only service that people will try mass password guessing against; attackers are also constantly probing against at least authenticated SMTP servers and IMAP servers. Probably they're trying anything that exposes password authentication to the Internet.

However, you should never be vulnerable to the broad risk because you shouldn't have accounts with weak passwords that can be guessed. Especially you shouldn't have such accounts exposed to SSH, because there are a number of ways to insure this. First, obviously you want to enforce password quality rules (whether just on yourself, for a personal machine, or on everyone). If you're worried about random accounts getting created by software that may mis-manage them and their passwords, you can lock down the SSH configuration so that only a few accounts can log in via SSH (you probably don't need that postgres system account to be able to SSH in, for example). Finally, you can always go all the way to turning off password authentication entirely and only accepting public keys; this will shut down all password guessing attacks completely, even if attackers know (or guess) a username that's allowed to log in remotely.

(SSH is actually a quite easy daemon to lock down this way, because it has good authentication options and it's relatively easy to configure restrictions on who can use it. Things like IMAP or authenticated SMTP are generally rather more troublesome because they have much weaker support for easily deployed access restrictions and they don't have public key authentication built in in the same way.)

The targeted risk is that someone will find a vulnerability in the (Open)SSH server software that you're running and then use it to attack you (and lots of other people who are also running that version). This could be the disaster scenario of full remote code execution, or an authentication bypass, or merely that they can work out your server's private key just by connecting to it (see also). This is an actual risk (even if it's probably relatively unlikely in practice), but on today's Internet, moving SSH to an alternate port doesn't mitigate it due to modern mass scanning and things like shodan and zmap. If your SSH is answering on some port, modern mass scanning will find it and in fact it's probably already in someone's database, complete with its connection banner and any other interesting details such as its host keys. In other words, all of the things that someone unleashing an exploit needs to know in order to target you.

You could get lucky, of course; the people developing a mass exploit could be lazy and just check against and target port 22, on the grounds that this will sweep up more than enough machines and they don't need to get absolutely everyone. But don't count on it, especially if the attackers are sophisticated and intend to be stealthy. And it's also possible that the Shodan-like search engine or the Internet scanning software that the attackers are using makes it easier for them to just ask for 'all SSH servers with this banner (regardless of port)' than to specifically limit things to port 22.

PS: The one thing that moving your SSH server off port 22 is good for is reducing log noise from all of the zombie machines trying scattershot password guessing attacks against you. My personal view is that there are better alternatives, including not paying attention to your logs about that kind of thing, but opinions differ here.

sysadmin/SSHAltPortNoSecurity written at 23:00:02; Add Comment

I'm seeing occasional mysterious POST requests without Content-Types

Sometimes I go out of my way to turn over rocks in the web server logs for Wandering Thoughts, but other times my log monitoring turns them over for me. The latter is how I know that Wandering Thoughts has been seeing periodic bursts of unusual POST requests that don't appear to have a Content-Type. I saw another such burst today, so I'm going to write this one up.

Today's burst is six requests from a single IP (86.139.145.21), POST'ing to a single entry between 12:55:12 and 12:56:08. In fact there were two burst of three POSTs each, one burst at 12:55:12 and 12:55:13 and the second at 12:56:08. DWiki's logging say that all of them lacked a Content-Type but it didn't record any other details. This specific IP address made no other requests today, or even in the past nine days. On July 2nd, it was nine POSTs to this entry from 59.46.77.82 in three bursts of three, at 21:36:20, 21:42:2[12], and 21:53:35. Both IPs used a very generic User-Agent that I believe is simply the current Chrome on Windows 10.

In all of the cases so far, the POSTs are made directly to the URL of a Wandering Thoughts entry, not to, say, the 'write a comment' page. This is noteworthy because I don't have any forms or other links that do POST submissions to entry URLs; all references to entry URLs are plain links and thus everyone should be using GET requests. Anything that's deciding to make these POST requests is making them up, either by mistake or through some maliciousness.

(In the past I've seen zero length POSTs with a valid HTML form content-type, which I believe were also for regular entry URLs although past me didn't write that explicitly in the entry.)

There's a part of me that wants to augment DWiki's logging to record, say, the claimed Content-Length for these POST requests so I can see if they claim to have content or if they're 0-length. Probably this is going further in turning over rocks than I want to, unless I'm going to go all the way to logging the actual POST body to try to see what these people are up to.

(Apparently POSTs without a Content-Type are technically legal and you're supposed to interpret the contents as the generic application/octet-stream (unless you want to attempt to guess by inspecting the data, which you don't). See eg here, pointing to the HTTP 1.1 specification. However, all of my POST forms properly specify the content-type the browser should use, so this shouldn't be happening even for proper POST requests to valid POST URLs.)

PS: Apache probably accepts POSTs with no Content-Type to static, GET-only resources because Apache will accept pretty much anything you throw at it. DWiki is more cautious, although that's basically become a mistake.

web/POSTWithoutContentType written at 01:35:10; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.