Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Putting SSH On Another Port is a Good Idea

danielmiessler.com

Post reply on HN
Print view View original

161–170 of 192 posts

Re: Why Putting SSH On Another Port is a Good Idea

#161

Post by unethical_ban »

teddyh wrote: post #135

As I understand his argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security . The problem is that: 1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits. 2. The security it adds is itself bad (sent in cleartext, ea…

Everyone else is chiming in with their anecdotal proofs, so I will with mine.

Yes, if you have a long password or key-only method of logging in, and disable root login, and patch the daemon, then party on.

But for the extra bit of protection against 0-days and bullshit amounts of logs from quick port-22 only scans on your network, it helps to move it to another port. This is why I disagree with your mathematically founded reasoning. It doesn't fit with real world scanner behavior.

If it's just your home network, it's not confusing because only you use it. If it's a corporate network, then using putty might be a little annoying, but it's not hard to communicate another standard.

Re: Why Putting SSH On Another Port is a Good Idea

#162

Post by mscarborough »

marcosdumay wrote: post #159
INTPenis wrote: post #96

Earlier quoted context omitted.

I think you're making some assumptions about people in your argument. This is really very simple, security is a multi layered thing and security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful. Bottom line, good security always takes discipline because humans are the last line of defense. There is no one button solution and anyone in security should know this so the argumen…

> security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful. That's ok. Just don't pretend that you are getting anything worthwhile from that policy. All you get is a 10 bit door, added (not multiplied - so, it does not increase your overall security) to whatever security you already had. In computer security, people normally consider anything with less than 64 bits worthles…

> I'd consider a non-standard port (and concern about bots) to be a huge flag announcing "This system is exploitable".

Every system is exploitable. How is changing a port indicative of someone who did nothing else to secure their shell access? I keep all mine on 22, but have been considering moving it just to keep the logs a little more sane for when I actually have to read them to find something.

Re: Why Putting SSH On Another Port is a Good Idea

#163

Post by kenrose »

grahamedgecombe wrote: post #118
antocv wrote: post #110

Earlier quoted context omitted.

> Many HTTP proxies only allow traffic through to port 80 and port 443. The benefit of ssh on port 443 is that if the proxy is handed a CONNECT verb, Thats not how HTTPS works, there is no HTTP proxy for 443. You are in a corporate environment where nothing is let out on port 80, except through their HTTP proxy. However, port 443 is allowed out. > In fact, this behaviour is what makes HTTPS remain secure when going t…

It can work like this - see: http://wiki.squid-cache.org/Features/HTTPS#CONNECT_tunnel

Right. Sorry, in case I wasn't clear, the HTTP proxy acts as a proxy for HTTP on port 80, but tunnels HTTPS traffic (and anything else including ssh) on port 443. The tunnelling is done using the HTTP CONNECT verb.

Re: Why Putting SSH On Another Port is a Good Idea

#164

Post by Zancarius »

axaxs wrote: post #66
yeukhon wrote: post #55

Earlier quoted context omitted.

Security is as strong as your weakest link. If you can't protect your port 22, any other ports are probably easy to take over too. Are you saying you get extra time since attacker has to find this new port? I am not totally sure what you mean. Please educate me.

It's more of an annoyance. If you require password based login, port 22 will lead to constant attempts that fill the logs. Move to any other port,and you'll see none.

Curiously, that was my primary motive for moving SSH on a couple of servers off 22. It had nothing to do with any notion of security and everything to do with the annoyance of filling up my auth logs with mindless login attempts by dozens of bots.

Maybe that's the wrong reason, but irritation can be a decent motivator. :)

Re: Why Putting SSH On Another Port is a Good Idea

#167

Post by uiri »

INTPenis wrote: post #96
bcoates wrote: post #87

He's right that "security by obscurity" isn't the entire story -- it's more like a mnemonic device for the more complex idea that: 1. In the real world, security resources aren't free. 2. Security decisions are made by users. 3. Humans will engage in risk compensation [1] 4. Setting policy doesn't change people's brains, it just tells them what to do. 5. It doesn't matter what you intend, it matters what users actual…

I think you're making some assumptions about people in your argument. This is really very simple, security is a multi layered thing and security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful. Bottom line, good security always takes discipline because humans are the last line of defense. There is no one button solution and anyone in security should know this so the argumen…

It really isn't difficult to write such a robot, it just involves a port scan before actually probing. Using bash, something like:

  nmap $host | grep -i open | cut -d '/' -f 1 | xargs -I {} ./sshscan.sh $host {}
Where the contents of sshscan.sh is something like:

  #!/bin/bash
  
  nc $1 $2 | grep -i ssh
  if [ $? -eq 0 ]; then
  # ssh probing stuff here
  fi

Re: Why Putting SSH On Another Port is a Good Idea

#168

Post by jstanley »

MarkMc wrote: post #140
danielrm26 wrote: post #46

Earlier quoted context omitted.

Ok, fair point. I'd say it differently, though. Instead of defending the original point, which was bad, I'd instead say among all other controls--most important of which is patching, removing passwords, etc.--one control is running below 1024. I could go for that. Except I actually think the gain from being up high (over 60K) is greater than the gain from being below 1024. It's not about being invincible, it's about…

Firstly, I like the tone you used to concede your original point. As to whether the port should be below 1024 or above 60000, I am undecided. I'd love to see some empirical data on this: let's say I run ssh over several days on port 22, port 762 and port 90332. How many connections do I get for each port?

For 90332, I suspect not many :)

Re: Why Putting SSH On Another Port is a Good Idea

#169

Post by bsdetector »

simias wrote: post #112
kijin wrote: post #83

Earlier quoted context omitted.

Run it on a port where (port != 22 && port I run my SSH daemons on port 1022. It reduces brute-force attacks significantly without reducing security in any way that I'm aware of. I also have a ~/.ssh/config file in my laptop that tells SSH to use port 1022 whenever I'm connecting to one of my own remote machines so I don't even need to type anything extra when I use ssh, rsync, etc.

I agree but I think TFA should clarify that it's probably a good idea to run sshd on a non-standard port . While other posters are right to point out that server certificate should make sure nobody can truly hijack your sshd there's no point in taking the risk unless for some reason all privileged ports are in use. Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the ke…

They just need to scan once to find the port speaking SSH, then brute force as usual.

If you want actual more protection run a bogus SSH (with no login allowed) on 22 and a thousand unused ports... then they have to try them all or guess which port is actually able to log in.

Re: Why Putting SSH On Another Port is a Good Idea

#170

Post by teddyh »

unethical_ban wrote: post #161
teddyh wrote: post #135

As I understand his argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security . The problem is that: 1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits. 2. The security it adds is itself bad (sent in cleartext, ea…

Everyone else is chiming in with their anecdotal proofs, so I will with mine. Yes, if you have a long password or key-only method of logging in, and disable root login, and patch the daemon, then party on. But for the extra bit of protection against 0-days and bullshit amounts of logs from quick port-22 only scans on your network, it helps to move it to another port. This is why I disagree with your mathematically fo…

> But for the extra bit of protection against 0-days

I am not in a position where I feel I need to worry about remotely exploitable 0-days in my SSH daemon. If you are, then your situation is, I feel, exceptional.

That said, perhaps those people should sponsor a project to fix this for real. This could be accomplished by having not one program, but two, one after the other, both with realistic keysizes and security. The password/key to get log in would be then be the combination of two separate keys, one for each program.

But what I have described is more or less the same as having a key/password-protected tunnel on top of SSH, so they could just use that. A 0-day in the tunnel/VPN would not allow access through SSH, and a 0-day in SSH would not matter since SSH can’t be accessed directly in the first place. This way, both the tunnel and SSH would need a 0-day at the same time for the security to fail. Like a RAID-1 array. If even this is not sufficiently secure, just increase the number of layers.

> and bullshit amounts of logs

This is a separate problem, better addressed by adjusting SSH to not log stupid amounts of stuff in the first place.

Post reply on HN