Hacker News new | past | comments | ask | show | jobs | submit login
Obscurity: Does Changing Your SSH Port Lower Your Risk? (danielmiessler.com)
54 points by danielrm26 on Feb 18, 2011 | hide | past | web | favorite | 93 comments



Even if it didn't, it lowers the number of log entries, failed attempts, and number of connections by several orders of magnitude. I've never regretted doing it though I pick a far more obscure port than this. None of my clients have had issues with me doing this either and sshagent makes it transparent to me.

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.


For the log file issue I usually recommend using something like fail2ban to start blocking hosts after too many failed logins in a given time period (and unblock them after a while).

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).


The problem with fail2ban is that it's vulnerable to denial of service attacks when the attacker spoofs the source IP address of the failed login attempts.


How do you spoof TCP connections?



I'd be amazed if you could show me a TCP spoofing attack that works against a remote host (that you aren't on the same LAN as).

As far as I know (and google shows), they don't exist.


Glad you mentioned choosing a obscure port. Not that 24 is wrong though <1024 are reserved for various protocols so usually I tend to select ports above this reserved range. Never know when you decide to roll out say mail on 25 and sure enough find out your ssh port is running on 25.


Any port not listed in the link below, or listed as "Unassigned", would be fair game.

http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_number...


If you're running a multi-user server, with possibly malicious users, that's not a good idea. Ports <1024 can only be bound to by root; so if a valid user of the server can figure out how to crash sshd, he can run his own version on the same port >1024, and then all your users' password are belong to him.


When I read your comment, I thought "surely you couldn't rig up a fake sshd to steal passwords" thinking the protocol wouldn't send passwords in plaintext but instead some hashing would take place. I read the RFC and, wow, it does send plaintext (though it's over an encrypted transport). Ouch..


Any client that has the server's public key in their known_hosts will throw up a big fat error.


This is mitigated by not allowing password-based logins for SSH. Your point still stands though.


This. Plus installed knockd (http://www.zeroflux.org/projects/knock) of course :)



Anyone got this to work? My attempt ended up with an encrypted packet size over the 1500 byte limit.


Not being on port 22 raises the bar for getting into your server slightly, but as both the article and others here point out, you still get connections.

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.


> raises the bar for getting into your server slightly,

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.


There would be fewer hits on the port sure, but it wouldn't really raise the bar to getting in, which is the point he was trying to make.

Obviously, not all 18,000 of those attempts were going to succeed. Finding the port is the easy part.


If you can log in as account xyz over SSH, and account xyz has permission to do anything with sudo, how is that more secure than letting root log in over SSH?


If root can log in, the username is definitely known to the attacker and they must figure out the password. If root can't log in, the username of someone with an entry in sudoers probably isn't known to the attacker, so they must figure out both the username and password.


I do like this answer, but I'll also point out that making someone guess two strings is just as secure as making them guess one long string. If root has a random 10-char password, that's roughly the same number of guesses as a user's first name with an 8-char password.


Unless they can read the shadow file somehow, or a specific user attack vector makes it somewhat easier than complete guessing...


I'm not up to speed on security, but it appears to me that your sudo password should probably be different from your account password, so the scenario turns into figuring out the username and two passwords.


Is that even possible? I've never heard of anyone having a separate sudo password.


Yes. Here's how to set a separate sudo password:

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
Now, as "user", you can

  sudo -u root whoami
and you will be asked for "admin"'s password.

The only downside is that "root" is no longer the default user to become, you have to explicitly specify it.


Hm... would the user not being in sudoers and using su with root password being different than the user password make more sense?


To log in via SSH, you (should) have a key, and a password for that key. To sudo on the server should require a different, complex password for the paranoid admin. (So 2 long passwords and a key to gain sudo priv's)


I've always moved my server ports to the 10,000+ range. The number of connections is trivial.

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.


My advice, and I've been doing security for about 10 years now, run SSH on the normal SSH ports. Keep it patched. Install a good password policy. Centralize your accounts in an LDAP database. And then, perhaps restrict the SSH access to the few accounts or users that really need it. Perhaps you could use a jump host..

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.


The military disagrees, that's why they paint their tanks to match their surroundings.

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.


Quite honestly at worst you'll just keep out clueless script kiddies, but a determined person can still find your SSH port. It's also worth noting that your server isn't going to launch a 105mm depleted-uranium tank shell in the face of some unscrupulous port-scanner :)


Number of clueless script kiddies far, far, far outweigh number of determined people after my particular server.

Reducing risk of actual threats == security.

Dogma, let it go.


Fair enough regarding making the port harder to find, but I hope it's not your only countermeasure.


Precisely correct.


I don't know that I'd equate camouflaging a tank to switching ports.

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.


> nmap and other tools will already identify services on different ports

Yeah, and camouflaged tanks show up pretty plain in infrared.


This is generally well regarded security advice. Its what #ubuntu-server tends to recommend to people if they come in saying their SSH port is being attacked. Simply changing the port greatly reduces the number of attacks, and combined with IP blocking (automatic with fail2ban or similar) you are completely protected from these simplistic automated attacks.


The folks in #ubuntu-server say that because it quickly placates the people who erroneously believe they're under attack when in fact practically every public ssh daemon in the world gets probed for weaknesses.

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.


Maybe I'm stating the obvious, but in my experience an obscure port number will limit the number of requests, AND you should have a hard firewall in front of it with IP blocking | filtering.


What advantage does having a hard firewall give you over using iptables?


Less load on the server, plus probably fewer vulnerabilies and simpler admin on the firewall device. I suppose your mileage will vary.


This is a failed study.

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.


You're assuming a human attacker, which is not the case for the vast majority of probes and attacks. Bad guys don't generally sit there with a port scanner going from IP to IP.

This is all scripted stuff we're talking about.


Scripts can't implement conditional behavior?


It's not a matter of "can't"; it's a matter of "don't". My understanding is that scripts check a few places and move on. They're not AI-scripted human replacements that start scanning the entire Internet on all ports once they get an RST or a drop on 22.


We changed our SSH port if only for the fact that fail2ban was showing up near the top of the list for CPU time while SSH was running on port 22. After moving SSH to another port, it's consistently at the bottom.


Seems like all security tools are double edged swords. Lots of folks react against security-by-obscurity, because it can get overconfident fools hurt badly. Someone please name any security tool that doesn't do this.

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.


He should instead put ssh-faker ( http://freshmeat.net/projects/ssh-faker/ ) in front of his sshd, and then any attempt to connect from an IP not already in /etc/hosts.allow will fail to even get to see his sshd, much less attempt to exploit it.

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 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"?


Because the way ssh-faker works, it sends an sshd connect string, just like a real sshd, but then waits for you to enter a secret ssh-faker passphrase. If you enter the passphrase, it adds the IP you are connecting from to /etc/hosts.allow and then disconnects. So you first telnet to your ssh port, enter your ssh-faker passphrase, then connect with ssh normally, and log in (hopefully with only key based auth).


So this requires you to first send a password in plain text (ie. unencrypted and open to anyone who sniffs the connection) before you can log in? Why telnet? This really makes no sense whatsoever.

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?


It is not perfect. But then, nothing seldom is.

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.


I'll just leave that here: http://en.wikipedia.org/wiki/Port_knocking

Not that I use or endorse it.


I've used and endorse it. Set it up to accept a knock sequence along the lines of:

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.


Quite impossible, since TCP ports don't go past 65535. :)


90,000 was an exaggeration. The point stands though.


Port obscurity is pointless when there's much better ways to secure your host.

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.


> Port obscurity is pointless when there's much better ways to secure your host.

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.


Source IP filters really slow you down

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.


Using keys isn't always an option. Passwords are a necessary evil in SOME cases. Which is to say, keys are ideal when appropriate.


Well, SSH server is secured with `(username, auth_token, sshd_port)` 3-tuple, where `auth_token` is a password, public key, OTP or whatever else it may be. By changing the sshd port from default, one, indeed, would somehow increase security.

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.


Here's a philosophical question. Is choosing a strong password "security by obscurity"? A 20-character mixed-case random string is only more secure than the password "password" because so many users default to the latter, and to short words and dictionary words in general. But it's no easier to generate a rainbow table for an English dictionary than it is to generate one for an equally-sized subset of 20-character strings.


What's even better is setting up an access sequence to allow you to connect to SSH.

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 :)


You've reinvented port knocking. Use SPA instead: http://www.google.com/search?q=single+packet+authorization


yeah I couldn't remember what it was called.

The reason we had it as a web page was because it was easier for the windows/putty crowd.


There is another side to this risk. Perhaps you do lower the risk of compromise by changing your port. But you also increase the risk of locking yourself out somehow (especially if you use other tricks such as limiting IP ranges).

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.


Of course it lowers your risk. Unauthorized users will make fewer connections, meaning fewer login attempts, meaning less of a chance of being 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.


While I agree, you might be able to argue that the hits on an obscured port (24 in this example) come from more experienced hackers who would be more able to compromise your box. And potentially having a non conventional SSH port might be attractive. I.e. Whatever's behind this hidden door must be more valuable than what's behind this obvious door.

Overall though I think it would increase security... just might attract some trouble too.


If you change the port, you are saying you know more than the average admin, and may have more interesting things on your server.


So leaving it port 22 lets your server blend in with the crowd, making it more secure... by obscurity!


I don't think anonymous attackers care what is on your server. They probably want to use it for botnets or spam.


OK, that makes my brain hurt. (Not saying you're wrong...)


once you get the script kiddies out, all thats left are the mind games people. like the bad guy from hackers.


Not really. Just that you're less lazy. Nearly every SSH tutorial out there tells you to change the port. And if you're less lazy, you're also more likely to watch for strange activity. Which means they're more likely to be caught and kicked out if they try to turn your machine into a bot-spammer.

Going for the low-hanging fruit pays off frequently enough to make trying harder extremely inefficient in comparison.


I've got the SSH port on my webserver set to a random >1024 port, and I get at least 2-3 denyhosts emails per day.


You should not run a system service on a port below 1024. On unix-a-like systems there is usually a rule that a non privileged user can not listen on a port below 1024 - Apache and similar services do it by running as root or similar initially and dropping privileges once the port is open and ready.

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.


"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.


My strategy for years has been to run SSH on port 22, visible only to hosts inside my local network via a firewall (iptables) rule. Connecting on port 22 is not allowed from the outside. SSH also listens on port 2222 and can be connected to from the outside, root logins are not permitted. Works great.


>The stats over the weekend were over 18,000 connections to port 22, and five (5) to port 24

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).


Yes. Obscurity works. I mean it's not perfect, but otherwise, why put camo paint on tanks? Why not just paint them bright pink and let them stand on their own defensive capabilities?


Discussing obscurity in the security community is like talking to coffee aficionados about Starbucks.

Noneleless, if you can choose between being obscure or being a prominent potential target...


That's precisely the attitude I was trying to address with the article. If you ask the top security people in the world, they agree that obscurity can aid security if don't correctly.

Those who disagree with this outright are stuck with someone else's thoughts. Please read: http://danielmiessler.com/study/security_and_obscurity/


Wonderful explanation.

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.


If you filter IPs for sensitive services like ssh (and isn't that fairly standard practice) then I wouldn't expect there to be a real difference in risk level.


No doubt, IP filtering is the most secure plan. It's not feasible for many use cases however.

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.


You don't use a VPN in those locations?


I'm not even sure what exactly a VPN is, to be honest. I use SSH and SSH tunneling to do everything.


The same result as an ssh tunnel just lower on the network stack. In your case it'd seem that you can filter all your servers except for your one tunnel/bounce host. A VPN host just wouldn't have anything else on it.


I should look into that. Thanks for the tip.


Here's another obscurity question: Does usings hosts files instead of public dns for domain lookup lower your risk?


no. if you're scanning for open ssh ports you just scan IP blocks, not host names.


At the same time, I wouldn't leave your domain names open to full listing from any host. Otherwise finding one correct login, rev-dns of the host and the whole list of your internal machines might cause many problems...


There is definitely a benefit. However, don't feel too complacent about the perceived benefit.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: