Live data from Hacker News

Why Putting SSH On Another Port is a Good Idea

danielmiessler.com

51–60 of 192 posts

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

#51
post #31

Actually, one thing I've found useful is keeping an sshd listening on port 443. I know, I know, sacrilege reusing the HTTPS port, right? The benefit of this is that it can allow you to tunnel through an HTTP proxy (e.g., like in a corporate environment). 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, it will transpare…

I use sshttp for this - support for both port HTTP and HTTPS. I don't serve any webpages, but I wanted the option to also use a more aggressive SSH holepunch on the same port, and just naked SSH if I could.

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

#52
post #24

The reason he's right is most attacks on SSH are one-dimensional. In most cases the dimension is IP range - an automated process moves from IP address to IP address examining port 22 for any common vulnerabilities. Rarely do these processes check all ports. Moving your SSH deamon to a different port prevents those automated processes from then hitting your security layer on whichever port you are running. The other d…

Turning off passwords and only using keys also mitigates the standard brute force attacks that happen. Frankly I'd much rather do that then have my server on a non-standard port.

Attacks on port 22 end up consuming CPU.

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

#54

Here is something to think about, the author is right, but if you follow many ssh setup tutorials that say to move to say port 25000, you are less likely to be port scanned than the default, but still more likely than if you had used something totally random like say port 42 or 818. By me even writing this clever hackers will start scanning those ports too, just to be sure they are hitting everyone. That being said,…

Port scanning is generally automated (edit: and scans all ports, not just the handful you listed), so it doesn't actually matter which port you pick as long as it's not 22. Port scanners like nmap are widely available, so the time to actually figure out which port is running SSH is quite short in practice. Basically, there are two classes of people: 1. Those who use port scanners. 2. Those who do not. If you are bein…

Who is going to bother with a portscanner when there are plenty of targets on port 22. The targets on other ports are more likely to have been set to use keys, or at least have better passwords.

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

#55
post #24

The reason he's right is most attacks on SSH are one-dimensional. In most cases the dimension is IP range - an automated process moves from IP address to IP address examining port 22 for any common vulnerabilities. Rarely do these processes check all ports. Moving your SSH deamon to a different port prevents those automated processes from then hitting your security layer on whichever port you are running. The other d…

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.

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

#56

Earlier quoted context omitted.

Turning off passwords and only using keys also mitigates the standard brute force attacks that happen. Frankly I'd much rather do that then have my server on a non-standard port.

Attacks on port 22 end up consuming CPU.

and attack on other ports don't?

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

#57
In moving sshd to an alternate port, I've noticed two things: a greatly decreased amount of log noise from dictionary attacks, and a moderately increased amount of portscans.

It's reasonably clear to your average net malfeasant that any host running recognizable services is going to be running sshd.

So why not do both?

Put a dummy sshd on 22/tcp, deny all auth attempts, log whatever keeps you swimming in interesting data.

Then run real sshd elsewhere, possibly filtered, possibly port knocked, and hopefully permitting key-based auth only.

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

#58

Earlier quoted context omitted.

Turning off passwords and only using keys also mitigates the standard brute force attacks that happen. Frankly I'd much rather do that then have my server on a non-standard port.

Attacks on port 22 end up consuming CPU.

fail2ban

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

#59
post #19
post #17

Its kinda silly to move the port, a targeted attack is going to start with an portscan of you box, the attacker is going to say "oh what’s this here on port 2222?" and promptly discover that its ssh listening on a high port. Port knocking would make that discovery less likely I suppose but its still all treating a symptom of a bigger problem. So why not solve the problem with something a little more proactive like tu…

Yes, you have pointed out - a targeted attack. What if non-targeted attack like a robot scanning all port 22 in your datacenter?

Well, apparently with Zmap [1] you can do internet-wide scans in less than an hour from a single host, so I can't imagine they'd have that much trouble finding any open SSH ports on a smaller IP range.

So just changing the SSH port will do little, but enabling port knocking would help it stay hidden.

1. https://zmap.io/zmap-talk-sec13.pdf

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

#60
post #24

The reason he's right is most attacks on SSH are one-dimensional. In most cases the dimension is IP range - an automated process moves from IP address to IP address examining port 22 for any common vulnerabilities. Rarely do these processes check all ports. Moving your SSH deamon to a different port prevents those automated processes from then hitting your security layer on whichever port you are running. The other d…

Turning off passwords and only using keys also mitigates the standard brute force attacks that happen. Frankly I'd much rather do that then have my server on a non-standard port.

Bots frequently exploit changes that were recently fixed upstream. Not perhaps 0-days, but maybe a couple days after the original fix. How up-to-date do you really keep your SSH server? On the off chance the attacker gets to an exploit faster than you get around to updating your machine, then keys won't keep you safe. Using a non-standard port in that scenario might very well save you from the botnets, if the GP's argument about the dimensionality of attacks is correct.
Post reply on HN