Obscurity: Does Changing Your SSH Port Lower Your Risk?

http://danielmiessler.com/blog/security-and-obscurity-does-changing-your-ssh-port-lower-your-risk

by danielrm26 • 15 years ago

54 93 15 years ago

jarin• 15 years ago

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.

dspillett2• 15 years ago

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.

gnosis5• 15 years ago

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

stcredzero• 15 years ago

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.

ElliotH• 15 years ago

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.

measure2xcut1x2• 15 years ago

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.

antihero• 15 years ago

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

yock• 15 years ago

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.

rapind• 15 years ago

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.

AndyJPartridge• 15 years ago

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

Vivtek• 15 years ago

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

orenmazor• 15 years ago

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

code_duck4• 15 years ago

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

Groxx2• 15 years ago

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.

Legion• 15 years ago

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

trotsky3• 15 years ago

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.

code_duck4• 15 years ago

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.

trotsky3• 15 years ago

You don't use a VPN in those locations?

bradleyland• 15 years ago

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.

zach2• 15 years ago

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

danielrm265• 15 years ago

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/

zach2• 15 years ago

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.

Groxx2• 15 years ago

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

mseebach• 15 years ago

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.

goldmab2• 15 years ago

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?

KaeseEs• 15 years ago

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.

oreilly2• 15 years ago

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)

njharman3• 15 years ago

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

johnthedebs• 15 years ago

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.

chopsueyar• 15 years ago

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

unshift• 15 years ago

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

viraptor• 15 years ago

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

growt• 15 years ago

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

Not that I use or endorse it.

jefe784• 15 years ago

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.

rarrrrrr• 15 years ago

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

jefe784• 15 years ago

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

relix• 15 years ago

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.

danielrm265• 15 years ago

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.

teaspoon2• 15 years ago

Scripts can't implement conditional behavior?

16s• 15 years ago

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?

pwg3• 15 years ago

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.

gnosis5• 15 years ago

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

pwg3• 15 years ago

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

TheCondor2• 15 years ago

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.

danielrm265• 15 years ago

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.

artmageddon2• 15 years ago

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

TheCondor2• 15 years ago

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.

rlpb• 15 years ago

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.

poutine• 15 years ago

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.

jwatzman• 15 years ago

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.

jefe784• 15 years ago

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

njharman3• 15 years ago

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

petercooper2• 15 years ago

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.

dspillett2• 15 years ago

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

gnosis5• 15 years ago

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.

notyourwork• 15 years ago

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.

kijinbear• 15 years ago

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

LordLandon• 15 years ago

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.

pentarim• 15 years ago

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

getsat2• 15 years ago

Check this out: http://www.google.com/search?q=single+packet+authorization

poink• 15 years ago

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.

jefe784• 15 years ago

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.

invertd• 15 years ago

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

teaspoon2• 15 years ago

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.

juiceandjuice2• 15 years ago

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

getsat2• 15 years ago

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

juiceandjuice2• 15 years ago

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.

andyv• 15 years ago

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.

drdaeman• 15 years ago

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.

Obscurity: Does Changing Your SSH Port Lower Your Risk?

Related Stories