Live data from Hacker News

Why Putting SSH On Another Port is a Good Idea

danielmiessler.com

131–140 of 192 posts

Re: Why Putting SSH On Another Port is a Good Idea

#131
post #112
post #83

Earlier quoted context omitted.

Run it on a port where (port != 22 && port I run my SSH daemons on port 1022. It reduces brute-force attacks significantly without reducing security in any way that I'm aware of. I also have a ~/.ssh/config file in my laptop that tells SSH to use port 1022 whenever I'm connecting to one of my own remote machines so I don't even need to type anything extra when I use ssh, rsync, etc.

I agree but I think TFA should clarify that it's probably a good idea to run sshd on a non-standard port . While other posters are right to point out that server certificate should make sure nobody can truly hijack your sshd there's no point in taking the risk unless for some reason all privileged ports are in use. Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the ke…

monkeysphere is how you deal with your SSH keys. It's pretty awesome.

http://web.monkeysphere.info/getting-started-ssh/

So I figured I'd share it here: https://news.ycombinator.com/item?id=6617132

Re: Why Putting SSH On Another Port is a Good Idea

#133
post #2

Ouch, camouflage on a tank is a good analogy. Nice response post. In addition to, as the author encourages, being "weary of the 'by obscurity'" argument (as I'm sure we all already are), I would also advocate being wary of it :)

Seriously, I think "wary" might be the most-misspelled word in the English language right now....

http://grammarist.com/usage/wary-weary/

Re: Why Putting SSH On Another Port is a Good Idea

#134
Let's start with a secure implementation for remote access:

1. SSH:

Port - 22

Protocol - 2

PermitRootLogin - no

StrictModes - yes

MaxAuthTries - 1

PasswordAuthentication - no

PermitEmptyPasswords - no

ChallengeResponseAuthentication - no

UsePAM - yes

2. PAM_ABL (auto-ban by account after three retires)

3. IPTables (auto-ban by IP after three retries)

So in the above implementation an attacker has three attempts, max. This means the logs are quiet, yet accurately depict intrusion attempts. This also stops brute force attempts in their tracks and requires no exemptions to normal workflow.

If, under the above circumstances, I were to obscure the port as well, this would serve no purpose than to completely side step script kiddie brute force attempts (as minimized as they would be in this configuration) with the horrific side effect of forcing my users to maintain (at the least) a config entry for the custom port assignment. Which, by the way, would become perpetually worse with the amount of servers and users in play.

This is why obscuring the port is such a bad idea.

And if you still want to obscure the port because the server, or network device, in question should only have occasional access by an extremely limited group of people, then just throw on a white list and possibly restrict access only through another server. Both provide more security than moving the port.

And moreover, this article isn't even about SSH. It's about the semantics surrounding the usage of the term "security through obscurity" in the previous article. Which is hilarious to me, as both articles are full of shit. For one, the security implications of non-privileged ports is moot as the attacker already has access. And two, being less likely of a target is still being a target. Those five people who found the port in the test sample. Those are the ones who win most likely to exploit; not the thousands of script kiddies brute forcing you.

Your time would be much better spent obscuring the actual version information for the service than the access point to it ...

(Reposted here, as the original site went down.)

Re: Why Putting SSH On Another Port is a Good Idea

#135
As I understand his argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security. The problem is that:

1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits.

2. The security it adds is itself bad (sent in cleartext, easily brute-forced)

3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.).

And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems.

Re: Why Putting SSH On Another Port is a Good Idea

#136
post #135

As I understand his argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security . The problem is that: 1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits. 2. The security it adds is itself bad (sent in cleartext, ea…

I changed it because it makes FreeBSD's nightly security run output not contain thousands of lines like this:

    Jul 28 23:53:57 hostname sshd[1068]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55040 ssh2
    Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2
    Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2
    Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2
    Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2
    Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2
    Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2
    Jul 28 23:54:00 hostname sshd[1092]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55566 ssh2
    Jul 28 23:54:00 hostname sshd[1092]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55566 ssh2

Re: Why Putting SSH On Another Port is a Good Idea

#137

a: $port != 22 is enough to thwart most bots and skiddies. If you think the port number is a guarantee that you are safe or that you are communicating with a blessed ssh you are sadly mistaken. b: Uhh the port number means nothing. Host keys are there for a reason... Someone does not understand the functions of SSH. http://www.snailbook.com/ c: If you are not investigating fingerprint issues when logging in via SSH a…

Sorry for deviating for the topic, but I think it must be said: "Sorry for the snarky reply" is not enough, considering that you wrote it at the same time you could have gone back and rewrite the text into a polite, well-worded argument. That's just condescension - if you really were sorry, you'd have rewritten your text.

By replying like that you've ensured that your point won't come across - for all I know you might be technically right, but using that tone ensures that lots of people will refuse to read past the second paragraph.

If your argument is solid, that's all you need. IMHO, snark makes your point come across as bragging, and no one likes that.

Re: Why Putting SSH On Another Port is a Good Idea

#138
post #135

As I understand his argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security . The problem is that: 1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits. 2. The security it adds is itself bad (sent in cleartext, ea…

For some reason I can't upvote you.

Re: Why Putting SSH On Another Port is a Good Idea

#139
post #135

As I understand his argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security . The problem is that: 1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits. 2. The security it adds is itself bad (sent in cleartext, ea…

For some reason I can't upvote you.

Clear your cache: https://news.ycombinator.com/item?id=6616972

Re: Why Putting SSH On Another Port is a Good Idea

#140

Earlier quoted context omitted.

> You don't get that from it being on 22; you get it from verifying host keys. You know how you just wrote a blog post talking about how more layers of security are better even if all you're gaining is obscurity ? This isn't an exception. And it is a valid point that by moving from a privileged port to a non-privileged port, you just traded away a layer (arguably a more useful one than you gain by moving away from 22…

Ok, fair point. I'd say it differently, though. Instead of defending the original point, which was bad, I'd instead say among all other controls--most important of which is patching, removing passwords, etc.--one control is running below 1024. I could go for that. Except I actually think the gain from being up high (over 60K) is greater than the gain from being below 1024. It's not about being invincible, it's about…

Firstly, I like the tone you used to concede your original point.

As to whether the port should be below 1024 or above 60000, I am undecided. I'd love to see some empirical data on this: let's say I run ssh over several days on port 22, port 762 and port 90332. How many connections do I get for each port?

Post reply on HN