Obscurity: Does Changing Your SSH Port Lower Your Risk?
danielmiessler.com
danielmiessler.com
It's the equivalent of moving your main door to the back of your house. Far fewer people will knock, even though burglars can still get in.
If you are running a shared environment the irritation of the log entries (or needing to run something like fail2ban or similar if you don't already) may be small compared to having to explain to your users again and again and again that the reason their SSH/SCP/SFTP client won't connect is that they need to tell it to use a different port (and then have to work out how to set a different port in the client they are using because they'll expect you to know).
As far as I know (and google shows), they don't exist.
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_number...
That means:
- If you have a guessable user name / password, you will still get hacked, and probably also by more determined people - which leads to:
- Those determined to get into your server will be delayed a few seconds, at most.
It's fine, do it, but only to get the bulk of the automated attacks out of your firewall / logs. If you're uncomfortable running SSH on port 22, your setup isn't safe enough, and switching ports is just putting a band-aid on an infected wound.
Hints:
- Root can't login from SSH. Use sudo.
- Public key only.
- If you have multiple servers, only one can accept SSH connections from the world. Preferably not in the same IP-subnet, much less domain, as any public facing server. Use this as gateway to other servers.
- IP whitelist, if practical.
Assume your primary user account is called "user".
Set up a second account, whose password you want to be your sudo password. Let's call this account "admin".
In /etc/sudoers:
Defaults:user runas_default=admin
Defaults:user runaspw
sudo -u root whoami
The only downside is that "root" is no longer the default user to become, you have to explicitly specify it.
Talking about bots/viruses/script kiddies and not targeted attacks. 18,000 to 5 is not what I would call slightly. In fact I would call it 4 orders of magnitude greater. Extremely greater.
Obviously, not all 18,000 of those attempts were going to succeed. Finding the port is the easy part.
In conjunction with the following, I've had virtually no issues:
Port 22222 #Easy to remember, rarely hit. Even if it does get hit, it takes them a little longer to scan up to this range. Move it higher if you want.
Protocol 2 #NO EXCEPTIONS!
LoginGraceTime: 60 #seconds. If you need more than 60 seconds, you're probably doing it wrong. Change to 30 if your host is fast.
PermitRootLogin No #self explanatory. No means no.
AllowUsers jefe78 otherguy #this should help if you use obscure user names
Now, combine that with denyhosts http://centoshelp.org/security/denyhosts/ and some really strict configs and you should be better off than you were.
The obscurity approach doesn't actually increase security, it does increase the difficulty to use and diagnose things (it's just another step to remember and your network is just a little bit different form everybody else') and it might give you some artificial sense of being more secure. Plus there are off the shelf tools that can monitor and even dynamically repair those attacks on the fly (IPS products) and when you start using different ports those tools don't all work the same way and some won't work at all, in that case the obscurity would actually reduce your security and reduce the effectiveness of other tools you use for security.
If you're saying that you could get confused and the hassle is worth more than the gain, that's one thing, but to say that there's no benefit is false.
Reducing risk of actual threats == security.
Dogma, let it go.
nmap and other tools will already identify services on different ports, switching ports protects you from the dumbest of the dumb robots and that's it. The cost of which is potentially more confusion on your network. The other cost if you have an IPS that is protocol aware, it may not work with your altered ports.
I guess if you're only worried about script kiddies and robots then there is potentially some benefit. If you're worried about actually being attacked then it makes your life marginally more difficult (just a tiny bit more complexity) and it offers no security.
Yeah, and camouflaged tanks show up pretty plain in infrared.
He should have removed "Port 22" from the config file to get any significant results. Right now it only says that if an attacker gets an SSH-like answer on port 22, it's very unlikely he'll try on port 24 as well.
This is unhelpful because if there's a bug in OpenSSH, then even an OpenSSH "reject all on port 22" configuration* might be compromised.
I think it's very much more likely that an attacker, when not getting any answer (or being instantly rejected) on port 22, will portscan the server to see if any other ports are open, and then try the non-standard port, which in this case is 24.
* I'm unsure if this is possible in SSH (like reject all root logins), but anything non-standard might trigger the "no SSH @ 22" response, so I'm hypothesizing a best-case-scenario config.
This is all scripted stuff we're talking about.
I've always believed that this was a useless measure of security. The things it defends against are are made ineffective by other security measures you should be taking anyway. In the end, the only benefit it produces is reducing logspam.
That said, first have your basic security squared away. Only then, layer that with just enough obscurity to avoid attention. By analogy, acquire your armored vehicle first, then drive it to your camouflaged hiding place. It doesn't matter if you avoid all but 1 of 10,000 shots, if shrapnel from that one shot kills you anyways.
The advantage of ssh-faker is that if you are logging in remotely from somewhere that is not your normal haunt, you can remotely add an entry to /etc/hosts.allow to let yourself past the gate.
If you're "not in your normal haunt" and your attempts to log in are blocked by ssh-faker, then how are you going to "remotely add an entry to /etc/hosts.allow to let yourself past the gate"?
Why not just require an extra ssh password? At least that way it couldn't be sniffed. And even that is simply ridiculous, as you could just use one password that's twice as long.
What am I not getting here?
What it does protect from, given that most attackers will not have your ssh-faker password, is from the attackers obtaining any access to your sshd to try anything, be it a password scan or whatever. It is another layer in front that deflects all of the script kiddies, and many of the more intelligent attackers.
Why telnet? Because ssh-faker is not an sshd, and so you can't submit your password to it using ssh.
Perfect, no, another layer, yes. Kind of like having a lock on both your front gate and front door. Those who can't get through the gate lock can not ever attack the door lock. Those who can get through the gate lock still have to then attack the separate door lock.
Not that I use or endorse it.
Port 38378, 1292, 65000, in quick succession. IMPOSSIBLE a port scan will ever hit those ports in that order.
Have that sequence trigger a modification to your iptables or execute some script to modify sshd_config or whatever else. It works wonders and is another level of security.
You should be running SSH with keys only, never with password authentication. Passwords are for encrypting your keys on your local machine and for sudo which is restricted to specific accounts. Source IP filters really slow you down, but may work in some circumstances.
As your network gets larger you'll need to restrict any inbound SSH and use a VPN to a firewall or bastion host and use something like puppet to distribute your ssh keys. Make sure you do two factor auth to the VPN with a password and at least some sort of key.
Can you elaborate on this or provide a reference? I've never heard this before and am curious what the implications of various iptables filters are.
Good security is layered. This reduces attacks. Reducing attacks is better. Changing port is better than not changing port.
And most people posting here obviously didn't read the article because it clearly stated this was in addition to all the other security measures you put into ssh.
People tend to change sshd port so they won't get port scanned. It should be compared to hiding one apartment's door. However, the real annoyance is that after some bot detects sshd it starts brute-force attacking it. Compare it to thief standing in front of your door and trying to pick a lock for a long time. There are tools like denyhosts[1] and fail2ban[2] to prevent such abuse - N failed attempts and unless you're from a trusted network - you're banned.
The open question is whenever you gain something valuable, while giving up your convenience (you'll have to specify `-p` option or register every host in `$HOME/.ssh/config`)? Most security rightfully relies on `auth_token`, so first thing to do is to ensure it's strong enough. The rest of changes are relatively insignificant (just compare 4096 bits of your private key to 16 bits of port number).
I believe people care about their sshd port only because it's noisy in `auth.log` when they're attacked.
In the past, our experiment had a server that was hit particularly hard with SSH attempts for some reason. So, you had to visit a page on port 8080, which would temporarily add your IP to an allow list, in which case you could then attempt to access ssh on port 22.
It works exceptionally good because port scanners usually start low :)
The reason we had it as a web page was because it was easier for the windows/putty crowd.
This may seem unlikely to you, but so is being compromised if you're security conscious, which you obviously are if you're thinking about changing the port (you'll stay up to date, disable password authentication, etc).
Most security problems occur when you overlook something. For example, you're far more likely to be compromised through a vulnerability in a web app you don't use a package manager for and so don't receive automatic updates for. Or through a user who set a weak password or compromised another machine with his key on it. And so on.
I think that on balance it makes little difference when you consider the real reasons why people get compromised.
Following from that, of course you should do it. In the vast majority of cases it's no inconvenience (add a host block to your ~/.ssh/config file if you don't want to type out/remember the port), so you're talking about a change that's all upside.
It just doesn't get you off the hook for doing ANYTHING else in terms of security good practice. You don't get to use insecure passwords (in fact, preferably you're disallowing passwords entirely in your server config). You don't get to be lax about cleaning up unneeded accounts. You don't get to chmod everything 777 and ignore which binaries are SUID/SGID. You don't get to slack off patching your box.
Overall though I think it would increase security... just might attract some trouble too.
Going for the low-hanging fruit pays off frequently enough to make trying harder extremely inefficient in comparison.
If you run SSHd on a port over 1024 you increase the chance that an non-privileged user on your machine (a user on a shared host, or a compromised externally accessible application) might somehow crash your SSHd and launch its own to capture usernames/passwords or such.
Bots scanning for SSH on ports other than 22 will likely scan the whole 65536 range, not just the first 1024, so you don't get extra obscurity by using a higher port.
Do you have any statistics to back up that assertion? I'd expect most attackers to concentrate on ports below 1024, with proportionately fewer of them bothering to scan higher ports.
In other words: yes, to random probers. Jury's out on non-random (my guess is no. If they're watching your network, and you ever use the port, it'll get probed for vulnerabilities).
Noneleless, if you can choose between being obscure or being a prominent potential target...
Those who disagree with this outright are stuck with someone else's thoughts. Please read: http://danielmiessler.com/study/security_and_obscurity/
I never run SSH on port 22 on a publicly-visible computer when I can help it.
I thought it astounding that the idea sometimes meets with scoffing, seemingly with a presumption that such a practice must be the sum total of one's security precautions.
No matter how effective a security technique is, it can be shouted down as "taking minimal effort to overcome," "providing a false sense of security" or "not going to stop a determined attacker." Dude, I live in a Bayesian world, I just want to improve the probabilities. Then again, that must be effective rhetoric for getting consulting gigs.
For instance, I have our servers only accessible to my work IP. However, that means I need to connect to them through there when I am not at work - coffee shops, hotels, my phone's dynamic IP - so my work server needs to be accessible to anywhere.