Is there a way to increase the privileged port range from 1024 in linux? If it's set to a high enough number, say 1024*1024, that would solve both problems (we could use a large port number for ssh and not allow non-root users to hijack the port).
Why Putting SSH On Another Port is a Good Idea
91–100 of 192 posts
Re: Why Putting SSH On Another Port is a Good Idea
#92Earlier quoted context omitted.
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.
There are indirect scanning techniques that induce and measure traffic from ordinary non-compromised hosts. When the attacker notices that he gets banned for scanning he'll do that.
http://nmap.org/book/idlescan.html but IIRC there are more ways than this to do it.
Re: Why Putting SSH On Another Port is a Good Idea
#93Earlier 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?
Could a non root user just read the host keys from sshd,
No, file permissions.
then kill it and serve them?
Users with uid != 0 cannot kill other user's processes.
Or could it even just MITM it?
No, host key verification ensures that you are talking to the intended ssh daemon without packets being intercepted. The host key is a public key of the SSH server, which is verified by the client to be the key registered for that particular host. Since only the server has corresponding private key, the MITM cannot eavesdrop on the key exchange.
Re: Why Putting SSH On Another Port is a Good Idea
#94He'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 agree with the sentiment of your post, however, I'm not sure if for the kind of user who would put a root:root shell on port 24601 the alternative in the absence of the article [2] wouldn't be putting the same shell on port 22. The former at least has a better chance to stay uncompromised until somebody comes in to fix it.
Edit: I also wonder if a passwordless root Telnet would last longer. :-)
Re: Why Putting SSH On Another Port is a Good Idea
#95Amend the title to include (if you run only one SSH daemon and you're the only one who needs to access it).
Then I agree.
Otherwise, hell no.
Re: Why Putting SSH On Another Port is a Good Idea
#96He'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 argument shouldn't even be present about that point. Changing the SSH port towards the internet is a very pragmatic solution to spam in your logs.
I know people will mention fail2ban but I'd rather not have a log parser running day and night on every internet facing server when I can just change the port and get rid of all that spam Forever. (I have yet to encounter one robot that can dynamically scan for SSH ports and use anything else than 22).
Also, in my personal opinion, using a high port like 24601 is insecure because if your SSH daemon ever crashes then an unprivileged user on your system can listen on that high port and receive your precious connections. So personally I always use an alternative ssh port under 1024.
Re: Why Putting SSH On Another Port is a Good Idea
#97a: $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…
>I cannot tell you how many times I have heard sysadmins say a that a single private key is a "best practice".
Are you talking about a host key, user key, what? Confused.
Re: Why Putting SSH On Another Port is a Good Idea
#98It's probably already been said, but it can be said enough: Security through obscurity is valid for marginally increasing the total security margin, but relying on any one practice or technique always smells like a dangerous approach. (Hence the hollistic practice of many overlapping features providing defence-in-depth.)
Changing ports reduces the threat surface in limited but practical ways, however far more effective would be using secure port knocking (say fwknop with GPG and is also time-based).
Secure port knocking and changing ports together would be perfectly valid. In fact, I have deployed these for openbsd jumpboxes guarding core infrastructure. So breaking in would require defeating fwknop with GPG and ssh.
(If anything needs public auditing, it's GPG and SSH. VPN code also considering the logic often makes OpenSSL look simple. )
Re: Why Putting SSH On Another Port is a Good Idea
#99Earlier quoted context omitted.
> I want some assurance that when I ssh into a box, that I'm hitting a true and sanctioned sshd. You don't get that from it being on 22; you get it from verifying host keys.
> 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…
Privileged ports isn't an example of security through security. Maybe you could call it security by convention. Still, it relies on a number of assumptions, none of which can be relied upon if a system is compromised, and if the system isn't compromised... well, you don't have a problem now do you?
Honestly, the only win of a using "privileged ports" these days is you don't have to worry about the odds of some other service randomly binding to your port. Since most systems spin up ssh well before they spin up services that bind to random ports, and generally don't ever shut down ssh, that isn't much a win, but either way, it is NOT a _security_ win.
Re: Why Putting SSH On Another Port is a Good Idea
#100Earlier quoted context omitted.
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.
So that means you can't SSH into your remote machine from an arbitrary connection? What do you do when you're traveling?