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.
I'm seeing occasional mysterious POST
requests without Content-Type
s
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 POST
s 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 POST
s 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 POST
s 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 POST
s 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 POST
s 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.