Why Putting SSH On Another Port is a Good Idea • Hacker News Board

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

#81

Post by petsos » Sat, Oct 26, 2013, 6:06 AM UTC

MichaelGG wrote: post #37

sp332 wrote: post #14

Earlier quoted context omitted.

Exploiting a single user's account and opening a high port is not the same as getting root on a system.

So you're operating with a compromised user account capable of killing your sshd on port 1234 but there's no other local escalation exploits? Seems like something a little script or patch could fix up really easily - make sure your daemon is running on port 1234. If it's not, take whatever defensive measures you think would be effective.

Look at it a different way. If a bug was found that could kill sshd, then a local user could replace it.

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

#82

Post by mikegirouard » Sat, Oct 26, 2013, 6:11 AM UTC

quesera wrote: post #57

In moving sshd to an alternate port, I've noticed two things: a greatly decreased amount of log noise from dictionary attacks, and a moderately increased amount of portscans. It's reasonably clear to your average net malfeasant that any host running recognizable services is going to be running sshd. So why not do both? Put a dummy sshd on 22/tcp, deny all auth attempts, log whatever keeps you swimming in interesting…

I've done this in the past with some pretty good results. Though, I've dropped it because I found myself constantly locking myself out of my own machines.

I can't deny, it is a cool technique though. PortSentry is a good tool to use for just this. Anytime someone came to :22 and the machine just disappears.

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

#83

Post by kijin » Sat, Oct 26, 2013, 6:16 AM UTC

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.

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

#84

Post by mkmkmmmmm » Sat, Oct 26, 2013, 6:22 AM UTC

eslaught wrote: post #29

programminggeek wrote: post #20

Here is something to think about, the author is right, but if you follow many ssh setup tutorials that say to move to say port 25000, you are less likely to be port scanned than the default, but still more likely than if you had used something totally random like say port 42 or 818. By me even writing this clever hackers will start scanning those ports too, just to be sure they are hitting everyone. That being said,…

Port scanning is generally automated (edit: and scans all ports, not just the handful you listed), so it doesn't actually matter which port you pick as long as it's not 22. Port scanners like nmap are widely available, so the time to actually figure out which port is running SSH is quite short in practice. Basically, there are two classes of people: 1. Those who use port scanners. 2. Those who do not. If you are bein…

If you want to defend against port scanning just open some honeyports that ban all connectors. Maybe randomize these every X hours.

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

#85

Post by zorbo » Sat, Oct 26, 2013, 6:27 AM UTC

__david__ wrote: post #38

fletchowns wrote: post #13

How about: Why it doesn't matter what port you run SSH on * Because anything but the IP address of your office or VPN connection should be blocked at the firewall level for that port

Why would I use a VPN when I have SSH? IE, why do you think that a VPN is somehow more secure than an SSH connection?

VPN is not mutually exclusive with using SSH. What he's saying is that people should firewall their SSH ports to only allow access from trusted IPs, and VPN's make that easier to do.

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

#86

Post by dave1010uk » Sat, Oct 26, 2013, 6:30 AM UTC

pepr wrote: post #11

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…

His argument is that we can't be sure whether we're talking to the real SSH running or some rogue SSH run by an unprivileged user. That's why SSH servers have their server host keys with fingerprints you're supposed to verify using a different channel when first connecting: if someone managed to spin up a rogue SSH server, it would have a different host key and you would get a big fat warning from your SSH client tha…

Could a non root user just read the host keys from sshd, then kill it and serve them? Or could it even just MITM it?

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

#87

Post by bcoates » Sat, Oct 26, 2013, 6:43 AM UTC

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 actually do.

The upshot of this is that any security policy that is highly visible and highly inconvenient will reduce your security, and has to have a substantial benefit to justify its cost. You can say "I'll do stupid port reassignment tricks, and I'll also mandate that passwords are forbidden, and require that private keys be managed properly" but at three in the morning when the whatever is overdue and not working what you're gonna get is:

I'll just do password auth with root:root, nobody ever hits port 24601 anyway. Besides, look at this page [2], using a strange port makes me invisible like the Predator and makes me four thousand times more secure! I really want to believe this so I do.

Also, subverting scanners is an anti-security move, not a pro-security one. Scanners are a helpful tool to identify what the hell is running on your network. Your security efforts have to find every hole, the bad guys only have to find one. Don't put yourself at an even bigger disadvantage by making your systems harder to analyze.

[1] http://en.wikipedia.org/wiki/Risk_compensation

[2] http://www.danielmiessler.com/blog/security-and-obscurity-do...

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

#88

Post by xarball » Sat, Oct 26, 2013, 6:53 AM UTC

dave1010uk wrote: post #86

pepr wrote: post #11

Earlier quoted context omitted.

His argument is that we can't be sure whether we're talking to the real SSH running or some rogue SSH run by an unprivileged user. That's why SSH servers have their server host keys with fingerprints you're supposed to verify using a different channel when first connecting: if someone managed to spin up a rogue SSH server, it would have a different host key and you would get a big fat warning from your SSH client tha…

Could a non root user just read the host keys from sshd, then kill it and serve them? Or could it even just MITM it?

That's what file system permissions are for, on the private key.

(I might be wrong about this, but...) I've seen quite a few instances where SSH refuses to let people even try to log in if there's a chance that a private key has the wrong permissions applied, so as to minimize the risk of someone accidentally letting others read it -- as you suggested.

You'll find the default SSH config on the more noteworthy Linux distributions to do this 90% of the time time without even asking :)

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

#89

Post by telephonetemp » Sat, Oct 26, 2013, 6:55 AM UTC

mb0 wrote: post #75

danielrm26 wrote: post #15

Earlier quoted context omitted.

If you have random people spinning up daemons on your servers then you don't have an SSH problem.

Something as simple as an exploit against a php script could lead to unprivileged code execution & something as minimal as memory exhaustion could kill off your sshd process. If the sshd process is killed, and the attacker knows what port it was on (netstat -na | grep LISTEN), the attacker could spawn their own daemon on the unprivileged port that was previously being used for sshd, and that daemon could be used to c…

This is a very valid point and a good reason to choose a port in the privileged range if you use an alternative port for SSH. I wonder, though, what is the worst it can do if you don't use password authentication? E.g., to offer you a fake shell and try to capture your sudo password a rogue daemon would have to have access to your public key, which as an unprivileged user it shouldn't.

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

#90

Post by entropy_ » Sat, Oct 26, 2013, 7:00 AM UTC

dave1010uk wrote: post #86

pepr wrote: post #11

Earlier quoted context omitted.

His argument is that we can't be sure whether we're talking to the real SSH running or some rogue SSH run by an unprivileged user. That's why SSH servers have their server host keys with fingerprints you're supposed to verify using a different channel when first connecting: if someone managed to spin up a rogue SSH server, it would have a different host key and you would get a big fat warning from your SSH client tha…

Could a non root user just read the host keys from sshd, then kill it and serve them? Or could it even just MITM it?

No, they couldn't. sshd usually runs as root* so it can create shells for in user that's logging in. Therefore, only root could kill the daemon. Also, as mentioned by the sibling post, its configuration files are usually(if not you have a serious problem) only writeable by root so nobody else could modify them.

* Note, I guess you could run an sshd that only allows logging in to a single user and runs as that user but both points above still stand even in that case.