Why putting SSH on another port than 22 is bad idea
adayinthelifeof.nl
adayinthelifeof.nl
We camouflage tanks. We build stealth fighters. If obscurity had zero value, we'd just paint the tanks bright pink with hot orange flames and drop all the stealth research too. No need to sneak around. Obscurity is useless right?
Hide from the bear and it might not find and eat you. Move your ssh port and your logs will have less idiots out there filling them up. That fact alone is worth changing ports.
Obscurity has its place along side other tactics. And when you put it all together, you'll have a more secure system.
So please cut the "Security through obscurity" crap.
Most thieves aren't career criminals in search of wallets. Perhaps a respectable working man sees a wallet of a young rich kid currently in the water. The man could use some extra cash and sees large bills protruding from the wallet and decides to take it. Why not? The man has a family and that kid probably has a trust fund.
The wallet stuffed in a shoe or buried under a towel prevents temptation. It's not actually more secure but it keeps honest people honest.
Nothing is really secure. Adding security is all about making something harder. Harder to live with, harder to access, harder to do un-detected, etc. If hiding something from plain sight makes it even slightly more troublesome of a heist, it's actually security IMO.
It shouldn't be your only form of security but to write it off completely seems silly.
Security through obscurity is only a problem if it's the only security.
A lot of the army forces are wearing camo fatigues 100% of the time while in combat zones, I'm sure they would have a lot to learn from you.
Sarcasm aside, security through obscurity is not very useful when it's the only defense vector used but it's very important when it's part of a multi-angle defense. The more hurdles you put on the path of hackers, the more time you buy to defend against them.
Generally, I think it's best to avoid publicly accessible SSH but if needed, changing the port is a good idea.
I always remove password auth and direct root login however even though my machine is now secure, the logs are filled with failed login attempts.
Clean and tidy logs help spot anomalies indicative of real attacks and not someone looking for open port 22 and hoping the combo root/root somehow works.
I don't think it's wise to change the port and consider things safe. All other security advice still applies however changing the default port in addition to locking down access seems like a wise decision to me.
The idea behind security through obscurity being bad isn't about stealthiness, it's about that the idea that an attacker not privy to details of the system isn't really disadvantaged. Using a secret custom cipher is worse than using publicly vetted and analyzed ciphers like AES or ChaCha20.
Specifically, port-knocking isn't about security through obscurity. Your secret is the knocking sequence. Making the port inaccessible without that makes sense.
Well OP is assuming that I trust the root user of the machine I am SSH'ing to. If I do, then what's the concern? The root user probably told me what the SSH port is. If I don't, then well what's to say the SSH daemon on port 22 is secure? In any case, there are many other ports that are not 22 and are < 1024. You don't have to pick 2222.
Changing the port is not the ultimate defense against attack, but in my experience it does reduce random drive-by type attacks. Same reason you raise your windows when you lock your car - as easy as it is to break a car window, a thief would rather steal from a car with an open window than smash your windows and steal from yours.
If you are, then the author is 100% correct that it is not a good idea to run a SSH server above port 1024, or any port other than 22.
There are much better solutions to dealing with drive-by attempted logins, and some of them are built into ssh.
Ok, but you haven't explained why. The author's stated claim is that running an SSH server over 1024 means the connecting party cannot trust the server, but that of course doesn't apply if you are running the server.
If you want to truly secure your server, then yeah, changing the port doesn't really do much but there are some minor benefits (see other responses in this thread, and on the internet). I'm still not seeing the harm.
That said, I run ssh on a non-standard port for one reason only, it's a crap-load easier to check the log files for suspicious activity that way. I still run use the same protections I do for servers with ssh on 22.
Trusting the root user is different from trusting everyone with shell access to that machine. Only root (or a process with the appropriate capability) can bind to port 22 because it's below port 1024. Normal users can bind to port 2222. So now $EVIL_USER puts "@reboot /home/$EVIL_USER/bind_port_2222" in his crontab, or some such other method of getting to port 2222 before the ssh daemon.
This is mostly mitigated by the fact that $EVIL_USER can't read the host private keys which means that the impersonation will be detected by anyone who has the host in the known_hosts file, but that only counts for ssh, and assumes you've connected to the host previously. If you're running something like DNS or FTP on a multi-user machine, using a non-privileged port is a Bad Idea.
I hadn't thought of this. Setting up the malicious executable to somehow bind to the SSH port before the SSH daemon is able to and then rebooting the computer - assuming the user has reboot privileges - seems to be the only way to do this correct?
(Once the SSH daemon has bound to its assigned port, then I don't think the port matters - if the user is able to kill a root-owned SSH daemon, he's likely able to start his service on whatever port he wants).
Not necessarily. You wouldn't necessarily need reboot privileges, you could just wait until root reboots the machine for whatever unrelated reason (e.g. kernel update). And you could do the same thing with the daemon: Wait until some updated version of the daemon is released and when root is installing it there will be a race starting when the old version exits before the new version starts and binds the port.
You're also just causing trouble for yourself because then you have to worry about a bunch of arcana like whether the daemon is using SO_REUSEADDR, IPV6_V6ONLY, only binding to the IPv4 address when the machine is dual stack, etc.
With public key auth, an attacker can't capture anything useful (unless of course they record traffic and later figure out a way to later capture the private key [1], but this isn't a problem that changing the port will fix).
> mimics SSH
You can't mimic the key files in /etc/ssh/ssh_host_whatever_key without root privileges, assuming these files are properly secured. So users will get an unexpected warning that the host key has changed.
> simple script that listens to port 2222
True -- in cases where something isn't already listening on 2222. But if sshd is started early in the boot process and listens on 2222, won't any script started as a regular user be unable to bind to the socket?
I'm asking because I don't really know but have to set up my own servers from time to time (hobby admin).
Edit: I always use key based auth, don't allow root etc.
Of course you do: the SSH host keys. They are an integral part of the SSH trust model. If you blindly accept any host key thrown at you, for a machine you didn't just boot for the first time, then nothing can help you as you can easily be man-in-the-middled even if you are using port 22 (say from the cafe wireless you are using).
Next, he talks about anyone setting up a script to listen on a non privileged port to collect passwords. Okay. So, are you saying I shouldn't connect to your server then? Because if I set MY server's SSH port on 2222, I'm not worried about anyone collecting passwords on MY server. Unless they have root. Then I have bigger problems, and they can also collect my password when logging on to port 22.
Also, security through obscurity is hardly useless. Sure, don't use it as your only security defense, but it does have value. Obscurity means hiding something of value from plain sight. Can you find that object? Sure. That doesn't mean stealth is pointless. If so, we wouldn't have camouflage, stealth bombers, and the NSA. Stealth can be be valuable.
Lastly is keys over passwords. Again, unless you have root on the box, you're not getting the login password without brute force, or some protocol vulnerability. And, if your password is weak, what makes you think using keys is any stronger? First, you can create SSH keys without encrypting it with a password. If you choose to encrypt it with a password, what makes you think that password will be any stronger? Sure, remote password brute forcing us infeasible, but scanning Github for private keys isn't. What's one server versus another, unless you're targeting the user?
No, this article isn't thought through.
Under different circumstances different tradeoffs would apply, but for my current modes of use I don't see a compelling reason to put SSH on port 22.
firstly, How does he hope to mimic SSH with a script, when most 'companies' will roll out DNS sshfp records, heck, I even do it at home. -- he'd need to access the private keys in /etc/ssh/ to be able to do anything; unless he's rooted my box, I don't see how he could.
Secondly; he'd need to kill my sshd process in order to make his script work, sshd is not the kind of process driven behemoth that apache+modphp is, so you can't brute force it to death- how are you going to kill it if you're not root?
Finally; if you kill my sshd- where does your session go.
of course, all of this could be bypassed if you had root, but if you are root you can do anything anyway- you could capture and decrypt data with the private keys- surely that'd be easier.
(also, if you're root you can bind port 22 anyway, so it's a moot point)
http://www.danielmiessler.com/blog/putting-ssh-another-port-...
> 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.
... surely the point here is that this is not an internal server (if it were, you wouldn't be getting tens of thousands of attacks in your example).
So in the case of a server running on port 22, someone with user level access couldn't set up a daemon running on port 2222 because it wouldn't be allowed through the external firewall. Put ssh on 2222, and you just opened the firewall for a port any user can open.
I agree with a lot of your other comments, though.
I think people throw this phrase out because it scans nicely and makes you sound like you know what you're talking about, especially to yourself.
ignoring other authentication methods, PKI, etc..
http://www.danielmiessler.com/blog/putting-ssh-another-port-...
Camouflage on tanks doesn't remove the armor; it just lowers the chance that it'll be needed.
Having SSH moved to an alternate port helps mitigate the load caused by continuous SSH worm connections. Having the firewall additionally block SSH except from pre-approved adds additional defense, but adds the complexity that the admin cannot login from his mobile phone using just SSH without first adding his current temporary IP address to the firewall.
The alternate port, is not by itself a security mechanism but it can help in real life deployments.
It is a good article and raises really good points. I have bookmarked it because I do want to experiment with the author's iptables example.
You shouldn't mistake obscurity for security, but obscurity that doesn't actively bother the user doesn't hurt security. Again, emphasis on not mistaking obscurity for security, i.e. moving SSH to a port other than 22 does not mean that you can keep using password authentication.
Virtually all DNS servers on the Internet deny zone transfers (AXFR). This is entirely an "obscurity" measure, but it's still useful as long as people don't assume one of their hosts won't be found if it has a guessable hostname or IP address. There are many other examples.
On the other hand, your explanation plus the other replies probably help people dispel this notion for others, so maybe it's good to keep this kind of thing coming around.
All the change of port does is reduce the load avg from brute force attacks and failed connection attempts. You can accomplish the same thing with a fail2ban rule on the standard port.
Changing the port doesn't prevent intrusions. That's not a security benefit. That's a performance benefit, and a short-lived one at that, since what do you think botnet hackers will do once they've figured out that we're all running SSHd on a non-standard port and their brute force success rate goes to zero? They're going to adapt to the situation and scan the machine before connecting to it.
It's not security if it doesn't give a guarantee. Changing the port guarantees nothing.
I typically don't bother, and just use fail2ban, but it's silly to say that it doesn't make it more secure. It does, if only marginally. As long as people are aware that it isn't sufficient, and that they still need to use strong passwords and/or public key auth, then there's no problem with saying that this makes things more secure.
Also, you can put port numbers in your SSH config, so you never have to type them.
The only thing moving the SSH daemon does is give us a slight, conditional performance benefit (that using fail2ban on port 22 also gives, along with an actual security benefit). It does not give us any security benefit at all.