Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Putting SSH On Another Port is a Good Idea

danielmiessler.com

Post reply on HN
Print view View original

151–160 of 192 posts

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

#151

Post by rsync »

teddyh wrote: post #130
jvdh wrote: post #107

Earlier quoted context omitted.

Even so, it is still a very weak security layer that you are adding on to something that is already very secure. Does that really make it less secure? Now running SSH on a different port is an even weaker obscurity layer, but still, it still adds some security.

I think nobody is denying that it adds security . The question is, does the added security offset the increased complexity and associated difficulties?

This is, I think, the only valid argument against knocking.

The standard (and always condescending) responses are that it is either a very small password and/or that an attacker can record and replay the knock from an eavesdropping position.

Both of those are true, of course, but they neglect that the knock is always in addition to whatever else you are already doing to protect ssh.

So I have always rejected those arguments and continue to evangelize for port knocking.

BUT, the added complexity part is a valid point. I try to keep systems as bare and simple as possible and hate to add even a single unnecessary dependency package. I am happy to say that (on FreeBSD, at least) knock[1] is light, simple, and has run for thousands of days on busy production servers as well as my personal servers without even a single incident.

[1] /usr/ports/security/knock

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

#152

Post by beams_of_light »

kijin wrote: post #83
djcapelis wrote: post #3

2. Next he talks about this non-root listener issue. He claims that you shouldn’t run your SSH daemon on a non-privileged port because anyone can spin up a daemon up there. Great point, except you can still do that even if you run your main one on 22. I don't think I understand this point at all. What is it that you're trying to say? Are you sure you understood the original post's point? djc@capelis.dj:~$ nc -l -p 14…

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 would never have known about this had I not read this article and the comments here, and have been running SSH servers for a very long time.

The solution I'm particularly fond of is mentioned in Daniel's blog comments, which is to use iptables to block externalip:22 and redirect a non-standard port to localhost:22.

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

#153

Post by derefr »

GalacticDomin8r wrote: post #69
derefr wrote: post #27

Earlier quoted context omitted.

The ability for someone to "spin up a daemon on your server" would also be called an unprivileged exploit . The ability to spin up a daemon on port 22 on your server, however, would be called a privilege-escalation exploit waiting to happen . If a zero-day gets discovered in the kernel that allows the former, you'll be hoping that it isn't also the latter. This is why trusting unprivileged ports is a bad idea. (...un…

> The ability for someone to "spin up a daemon on your server" would also be called an unprivileged exploit. No, that is very, very wrong. This is SOP for an account on a system nc -l 9000 <- spinning up a daemon on your server

Rather, the ability for someone who isn't considered to have an account on your server, to spin up a daemon on your server.

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

#154

Post by [deleted] »

MarkMc wrote: post #140
danielrm26 wrote: post #46

Earlier quoted context omitted.

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?

[deleted]

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

#155

Post by MertsA »

microtonal wrote: post #127
lotyrin wrote: post #58

Earlier quoted context omitted.

fail2ban

And now you have another exploitable venue, the log parser of fail2ban ;). Personally, I trust netfilter/iptables' rate limiting more.

Even better yet is pam_abl. If any IP or user fails authentication faster than a configured rate pam_abl will block logging into that user or any authentication attempts coming from the same IP address and it's all nicely tied into PAM so you don't have to worry about yet another fail2ban vulnerability or someone spoofing some important IP address and tricking your server into blocking it.

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

#156

Post by teddyh »

mistercow wrote: post #148
teddyh wrote: 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…

>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. Aren't there rate limiting tricks you can use to impose great cost on searching for the correct port?

There are more effective rate-limiting settings in the SSH daemon, and these have the bonus of not impairing the functionality of the rest of the TCP/IP stack.

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

#157

Post by teddyh »

sdfjkl wrote: post #144
belorn wrote: post #143

Earlier quoted context omitted.

Here is an even worse log output nightmare: Enable logging in the firewall/ids, which show all packets sent to a closed port. It's massive. Endless. Like looking into the endless void. Of course, my computer does not log packets that are just bouncing against my computer. It would distract me too much, and maybe it would do so for you to. Easier just to tell the computer to not bug you about it, and trust that the "a…

This is the default email that a freshly installed FreeBSD sends you every night. It also contains a bunch of other bits. That's a bit different than subscribing to firewall spam.

It follows, obviously, that creating these log entries in the first place (much less reporting them) is a silly thing to do, just as receiving firewall logs for every packet to a closed port would be.

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

#158

Post by teddyh »

rsync wrote: post #151
teddyh wrote: post #130

Earlier quoted context omitted.

I think nobody is denying that it adds security . The question is, does the added security offset the increased complexity and associated difficulties?

This is, I think, the only valid argument against knocking. The standard (and always condescending) responses are that it is either a very small password and/or that an attacker can record and replay the knock from an eavesdropping position. Both of those are true, of course, but they neglect that the knock is always in addition to whatever else you are already doing to protect ssh. So I have always rejected those ar…

I used the word “complexity” not in the meaning of “the installed system is more complex for having more software in it”, but in the sense of “I don’t want to feel like I’m entering Diagon Alley just for wanting to use SSH” – i.e. complex to use, not complex to set up.

But your interpretation works too – they are both valid arguments, in my opinion.

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

#159

Post by marcosdumay »

INTPenis wrote: post #96
bcoates wrote: post #87

He's right that "security by obscurity" isn't the entire story -- it's more like a mnemonic device for the more complex idea that: 1. In the real world, security resources aren't free. 2. Security decisions are made by users. 3. Humans will engage in risk compensation [1] 4. Setting policy doesn't change people's brains, it just tells them what to do. 5. It doesn't matter what you intend, it matters what users actual…

I think you're making some assumptions about people in your argument. This is really very simple, security is a multi layered thing and security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful. Bottom line, good security always takes discipline because humans are the last line of defense. There is no one button solution and anyone in security should know this so the argumen…

> security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful.

That's ok. Just don't pretend that you are getting anything worthwhile from that policy. All you get is a 10 bit door, added (not multiplied - so, it does not increase your overall security) to whatever security you already had.

In computer security, people normally consider anything with less than 64 bits worthless. A 10 protection can be brute-forced by hand.

As humans work, changing that port is a clear indicator of an admin that didn't care about avoiding the less secure modes of SSH. If you are looking for obscurity, I'd consider a non-standard port (and concern about bots) to be a huge flag announcing "This system is exploitable".

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

#160

Post by lttlrck »

gnur wrote: post #103
GalacticDomin8r wrote: post #68

Earlier quoted context omitted.

> To be fair, you could get the advantages of both by running SSH on a different privileged port than 22. ephemeral port range are a tunable at least on FreeBSD. However tuning stuff like this is fraught with disaster consider how difficult it is to guess an ssh password vs all things that can go wrong when changing sshd's listening port. But do it if you want, I bill by the hour. galacticdominator% sysctl net.inet.i…

What can go wrong by changing the listening port of sshd? I have changed the port on my vps purely for less clutter in my logs, but I haven't had anything go wrong because of it.

It introduces a communications problem. Which machines are running SSH on a non-standard port and what is it? Plus some tools are harder to set up, IIRC SVN+SSH is one of them.
Post reply on HN