danielmiessler.com - Latest Comments in Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

cob — Sat, 26 Oct 2013 12:07:43 -0000

Daniel,

I've followed your stories on BBR and HackerNews for a while now, this one is very intriguing and I appreciate the effort.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Bob — Sat, 19 Feb 2011 13:04:15 -0000

I agree that only good administrators should have access and the risk of a screw-up is low, but it is a risk - and that's what this is all about. Is the risk of an admin making a mistake (and even good ones do) higher than the risk of getting hit by an ssh 0-day and saved by a different port? In most cases I don't believe it is.

I would note that although changing the port should be an easy change, ssh is critical and a mistake made when configuring it can lead to a high security risk or leave you unable to fix a genuine security problem elsewhere. This is always the case but is surely an argument for reducing the time spent in sshd_config unnecessarily.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Justin DeMaris — Sat, 19 Feb 2011 11:44:15 -0000

I have to say I was of the same mentality that the port changes were a stupid change that added complexity, but the point that really hit home for me was the zero-day one. We take for granted that SSH itself is secure. And if you want to buy yourself a bit of extra time from automated attacks when a zero-day gets exposed, running on a different port will most CERTAINLY buy you some time.

With regards to the added complexity part... any good administrator is inside the sshd_config file for any server deployment anyway, so changing the port number is very minimal risk. If you keep it consistent across your company, then anyone who has a legitimate reason to be using SSH anyway shouldn't have a problem with it after initial training. Anybody who is comfortable enough with SSH to be given server access should be fine at changing the port number to connect with. Anybody who isn't comfortable with that has no business having shell access to your server.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Bob — Sat, 19 Feb 2011 08:04:44 -0000

It really isn't that simple.

A better analogy would be to say we could install a magical camouflage on our tanks that reduced the chance of getting hit by 1% but actually made it break down 1% more as well. Should we do it? Well, we could, but in the end it doesn't make any difference.

So changing the ssh port reduces my exposure to automated ssh attacks. I already have adequate protection against these through other policies (which I would require anyway), they are very very low risk.

However, by doing this I have at least:

- Made an additional configuration change. In other words, added complexity, no matter how minor. And we know about complexity and security.

- Added to user and admin WTF factor. Oh, here's that complexity again.

- Admin time taken away from dealing with real threats.

- Changed to a less-tested code path through ssh. In this case a very very minor one, but once you start making this sort tweak they all add up.

These are maybe a bit of a stretch but so is the idea of a different port stopping some new ssh 0-day.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Daniel Miessler — Fri, 18 Feb 2011 19:39:43 -0000

If your tank armor is good enough then getting owned by a bullet is
small. So why use camo?

More importantly: Why not?

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Bob — Fri, 18 Feb 2011 19:29:30 -0000

I think that sometimes people spend far too much time faffing around creating novel solutions to minor risks rather than putting the effort into following good practice - which will mitigate the trivial stuff anyway - and saving their creativity for the real worries.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Arik — Fri, 18 Feb 2011 19:29:03 -0000

The problem is that you measure the risk by the number of hits on your port.

Perhaps the 3 hits on the non-standard port are more risky than all of the other hits combined?

-- Arik

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Bob — Fri, 18 Feb 2011 19:26:11 -0000

I don't think this is really the case. If you follow good security practice then your risk of getting owned by an automated attempt is near zero even if a new OpenSSH vulnerability is found and - somehow - makes its way into automated scripts quickly enough for you to be hit without warning. These automated attempts are not a security risk for most people, at least I would hope not most people reading this. Moving port does precisely nothing to mitigate the genuine risk of a determined attacker except the thin argument that it reduces noise in logs, and there are other equally valid solutions there.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Russell VT — Fri, 18 Feb 2011 17:27:05 -0000

I think you discount the idea that many Internet-daemon compromises have nothing to do with successful authentication. And, as-is the case with past SSH vulnerabilities, buffer overflows can happen early-on in the protocol exchange, possibly leading to a root shell. Yeah, it's only a stop-gap measure, but moving services like SSH to a port not normally seen/probed in a basic namp scan tends to at least keep the script kiddies away (and, as you say, keeps your logs MUCh cleaner).

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Russell VT — Fri, 18 Feb 2011 17:20:35 -0000

You need to pick a "better" non-standard port ... preferably something not already defined on the "common list of TCP ports." You've experienced more probes on 24 in a weekend than I tend to see in a year or two. Simply adding some multiples of a hundred tends to get you off the list...

Ref: http://en.wikipedia.org/wik...

Someone submitted you to Reddit, BTW:

http://www.reddit.com/r/net...

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Pronto185 — Fri, 18 Feb 2011 15:29:27 -0000

I change my ssh port to 443, though for a completely different reason. My school blocks outbound 22 on wifi...

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Bob Smith — Fri, 18 Feb 2011 15:07:57 -0000

port 22, zero attempts. Iptables for the win.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Evan Kaufman — Fri, 18 Feb 2011 12:21:50 -0000

I think it's much simpler in the long run to just set up (for example) fail2ban, and never have to worry about what port your ssh was on or whether some other service or app will support a custom ssh port. That's what I do for my VPS's and I have no complaints whatsoever. Still, it makes an interesting point that an obscurity layer *on top of already sound security* can usually only make a good thing better.

The only worry is that the security may fail and you may never notice because it's already obscured. This is most likely to happen in a situation where a system is likely to switch maintainers at some point and the new maintainer may not know all the ins & outs.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

JC — Fri, 18 Feb 2011 12:21:11 -0000

Not really, they could try millions of times and fail if you have root password disabled and fail2ban set up.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Scott Rubin — Fri, 18 Feb 2011 12:13:23 -0000

I run SSH on a non-standard port sometimes, but I don't have any delusions that it actually helps anything. All my SSH are key-auth only. Since every bot in the universe attempts to connect with password auth, they will never get in even if I'm on port 22. The reason I move the port is simply to make the log files cleaner, since they won't be full of failed attempts.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

WebDesignHero — Sun, 09 Jan 2011 13:06:44 -0000

From my own personal experience, I have no seen a difference in switching ports. I have to connect from hotels quite frequently. Obviously someone makes their living from hacking there, because when I get home I am still seeing attack on the port I selected for that week. If you just open the port, most automated attacks will use the default. If you are scanned and have banners, they will figure it out if they want. My guess is since they saw the traffic going to the particular receiver socket, they recorded it then performed their attack. In your experiment, how many connections were you making to port 24 from the public? Besides the minor annoyance of the attacker opening connections, and I had high hopes they were not going to crack my key and password.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Sol Invictus — Thu, 11 Dec 2008 20:29:00 -0000

This is a really, really good idea. Security through obscurity is not a replacement for other standard industry-best security practices, but it is a very helpful part.

The bottom line is it consumes server resources to deal with bogus connections. Even if you have an effective rejection system in place, a non-standard port reduces the amount of traffic you have to deal with.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Drew — Thu, 11 Dec 2008 17:12:58 -0000

I do this too. A while back I got really annoyed by the number of brute force attempts on my servers.

I have a HIDS system in place which alerts me to brute force attacks. On port 22 I would get at least 10 messages that it had blocked a brute force attack every day. I thought about disabling that rule, but then I realized that what I wanted to do was block out the annoying scripts, not the deliberate attacks on my systems. So I moved the SSH port to 831 (just made the number up). Now I don't get the attack messages unless someone scans my system to look at open ports and attack the services on them, something which indicates a much more dedicated attack which I might actually be worried about. I think I've gotten all of one ssh brute force alert across 10 servers.

To mitigate the inconvenience I just put the ports in my .ssh/config file along with shorthands, such as:

Host s1
HostName server1
Port 831

Really quite elegant.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

andrew cooke — Thu, 11 Dec 2008 14:44:47 -0000

i used to do this, but switched to using knockd instead.

one reason i switched is that it wasn't always easy to persuade other software to use the new port. even sftp requires quite an ugly syntax to pass the parameter down to the ssh layer.

the other reason was that my isp started "traffic shaping". that means that data transfer using non-standard ports had limited bandwidth.

neither of those is a very powerful argument (and i've since changed providers - from vtr to telefonica chile - to avoid the traffic shaping) and knockd is itself a bit frustrating to use if you don't have the client handy (you can trigger it using telnet, but it's hit and miss).

even so, you might consider it... http://www.portknocking.org/

ps also, of course, it can protect other protocols too.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Mike — Thu, 11 Dec 2008 12:22:32 -0000

I just run SSH on a non-standard port >1024 to keep down the size of my log files.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

blahedo — Fri, 29 Aug 2008 13:04:30 -0000

What you're advocating here is not so much security improvement through obscurity, but security improvement through irregularity. You could proclaim from the mountaintops that you serve ssh on port 24—in fact, you just did—and it would still have improved your security. Heck, you could respond to attempts on 22 with a message redirecting them two ports higher, and it would improve your security, because it would still filter out all the wardialer-style scripts. It wouldn't work if everyone did the same thing, but by decreasing regularity, you make it much harder for the scripts to account for your case. None of these stop someone determined to get into your system in particular, of course, but that's why you're not relying on them.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Samir — Tue, 27 May 2008 13:39:55 -0000

plz can you tell me how to change the port of the ssh on fedora 8
because ive 2 servers on the same router when so i cant login to one of them because the servers ssh have the same port
plz help me , thx

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Sean — Sun, 16 Mar 2008 15:33:30 -0000

The problem with changing ports that services listen on is the loss of trust. Services that listen on ports lower than 1024 are considered "trusted" because they require root privileges. So if SSH is enabled on a very high port, I'd be worried about my personal security when I connect to that system.

Also, using service detection with tools like NMAP will quickly remove negate any extra security that is provided by running on non-standard ports.

The only upside to running on non-standard ports is that automated attacks won't occur, but honestly a good firewall ruleset or a something like deny_hosts really solves the problem while retaining the "trust" factor.

Re: Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

Adrian Bool — Sun, 16 Mar 2008 06:57:44 -0000

I agree wholeheartedly; it's just another level of protection as part of defence in depth - although I'd use port 48351, or similar, rather than port 24!

This action would only be security through obscurity if you had no password or private key on the accounts - the non-standard port was your only protection. I'm sure that that is not the case!

A further protection is, on your firewall, to only permit connections with a source port less than 1024, then use the 'UsePrivilegedPort yes' in your ~/.ssh/config file to tell ssh to use source ports < 1024. My quick checks with nmap showed that nmap used source ports over 1024 - so even a hit on the right destination port would not result in an 'open'.

Were you monitoring the traffic to your ssh ports, if yes, were most of the source ports < 1024??