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

61–70 of 192 posts

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

#61

Post by lotyrin »

tszming wrote: post #35
tuzakey wrote: post #22

Earlier quoted context omitted.

Thats where fail2ban is useful, pick a number of failed auth attempts on any service you care to integrate, lets say 8 PAM failures, and trigger a rule that inserts an iptables rule to drop/reject the attackers IP for 5minutes. That will time out the ssh scan for all but the most patient scanners. If you shared the fail2ban database across hosts you could inject null routes for the offender into your router or block…

I think you have missed the point - you should tell why using non-standard port is less secure, not provide me an alternative, because I would also argue VPN is better fail2ban. You cannot neglect the fact that there are vast amount of bots scanning only port 22 in the Internet. We know this because we have found the evidence in our OWN logs, not from those security experts always saying security through obscurity is…

Because moving your port has an opportunity cost.

Documenting and configuring it has a non-zero cost which could be spent doing something else more impactful.

I've never seen an infrastructure where there was a sufficiently advanced state of security such that obscuring the port numbers of services was the at top of the todo list.

Unless people recommending these things work for shadow organizations I've never heard of, I'm pretty sure it's something done without any kind of cost-benefit analysis.

What are the odds of a SSHd zero-day? Or, more specifically, what are the odds that someone with zero-day knowledge would be so stupid as to decide to risk the vulnerability being discovered by others by using it in a horizontal search of all running SSHds?

Because it has to both be more likely than any other attack that could be mitigated (and port obscurity would have to be the most effective solution) with the same effort.

Pretty sure that for virtually all infrastructures, auditing that your systems are properly isolated, users and services have the least privilege possible prevent massively more probable attacks, and that firewalling services or port knocking or really anything are more effective solutions for this attack.

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

#62

Post by quesera »

sarnowski wrote: post #43

The "change-port" discussion for SSH is so boring :-/ OpenSSH is I guess the most secure daemon on all your servers. People should more think about to change the HTTP(S) ports of their non-public facing sites and other daemons and frameworks they use.

> OpenSSH is I guess the most secure daemon on all your servers.

Probably correct. However, sshd should be the only public facing daemon that hasn't dropped root privileges immediately after binding to its privileged port.

So it should be the only daemon that can directly offer root privs to an attacker.

I say "should" because it's a big world out there and people do some bizarre and indefensible things. Sometimes merely lazy things, but the net effect is the same.

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

#63

Post by socillion »

stephen_g wrote: post #59
tszming wrote: post #19

Earlier quoted context omitted.

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

"Less than an hour" is with gigabit internet, which is rare for an attacker to have.

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

#65

Post by GalacticDomin8r »

danielrm26 wrote: post #33
city41 wrote: post #6

Earlier quoted context omitted.

Privileged ports are why I disagree with this rebuttal. I want some assurance that when I ssh into a box, that I'm hitting a true and sanctioned sshd.

> I want some assurance that when I ssh into a box, that I'm hitting a true and sanctioned sshd. You don't get that from it being on 22; you get it from verifying host keys.

> you get it from verifying host keys.

You might be surprised how often StrictHostKeyChecking is no. Are you checking it on your active installs?

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

#66

Post by axaxs »

yeukhon wrote: post #55
dotBen wrote: 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.

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.

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

#67

Post by sorin-panca »

quesera wrote: post #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…

And use sshguard, because the only thing you should care on a secured host is power consumption. One of my boxes went to 33% on all CPU threads during a sk attack.

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

#68

Post by GalacticDomin8r »

djcapelis wrote: post #8
city41 wrote: post #6

Earlier quoted context omitted.

Privileged ports are why I disagree with this rebuttal. I want some assurance that when I ssh into a box, that I'm hitting a true and sanctioned sshd.

To be fair, you could get the advantages of both by running SSH on a different privileged port than 22. Many of the lower numbered even-numbered ones are good options as for historical reasons those are all mostly unassigned. (Pretty much any even number below 16 isn't used by much.) But I agree, the privileged ports point isn't something that should be brushed aside.

> To be fair, you could get the advantages of both by running SSH on a different privileged port than 22.

ephemeral port range are a tunable at least on FreeBSD. However tuning stuff like this is fraught with disaster consider how difficult it is to guess an ssh password vs all things that can go wrong when changing sshd's listening port. But do it if you want, I bill by the hour.

galacticdominator% sysctl net.inet.ip.portrange net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 10000 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023

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

#69

Post by GalacticDomin8r »

derefr wrote: post #27
danielrm26 wrote: post #15

Earlier quoted context omitted.

If you have random people spinning up daemons on your servers then you don't have an SSH problem.

The ability for someone to "spin up a daemon on your server" would also be called an unprivileged exploit . The ability to spin up a daemon on port 22 on your server, however, would be called a privilege-escalation exploit waiting to happen . If a zero-day gets discovered in the kernel that allows the former, you'll be hoping that it isn't also the latter. This is why trusting unprivileged ports is a bad idea. (...un…

> The ability for someone to "spin up a daemon on your server" would also be called an unprivileged exploit.

No, that is very, very wrong. This is SOP for an account on a system

nc -l 9000 <- spinning up a daemon on your server

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

#70

Post by ewokhead »

a: $port != 22 is enough to thwart most bots and skiddies. If you think the port number is a guarantee that you are safe or that you are communicating with a blessed ssh you are sadly mistaken.

b: Uhh the port number means nothing. Host keys are there for a reason... Someone does not understand the functions of SSH. http://www.snailbook.com/ c: If you are not investigating fingerprint issues when logging in via SSH and you call yourself a sysadmin, please stop. You are going to be the reason your company ends up in the news because your shit got owned and 2,000,000 user account hashes were leaked blah blah.

d: If you are not using key based auth and you have a fly by night keystore policy. Which means you have a keystore - stop. The whole keystore for SSH shit irritates me. I cannot tell you how many times I have heard sysadmins say a that a single private key is a "best practice". It is not a best practice it is a stupid practice and really prevents you from protecting unauthorized logins on other machines for the obvious reasons.

   Put your public keys on bitbucket.com or source 
   management. Put your private keys on an encrypted disk
   in an encrypted archive if you must. This is still dumb
   imho because it is not needed.

   Leave one account (root) with console only/no ssh access
   that will allow for keys to be revoked/recreated when
   users need new keys.
e: The original article http://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-... Is wrong and misguided. port knocking or knockd is an obscurity measure, precisely the kind he argues against. The linked article from the OP calls this out.

f: Spinning up daemons is a big deal for non-priv users? So spinning up a remotely accessible Lisp out of emacs from a screen that is running in the background is bad? Hmm, here I thought that computers were meant to be tools for humans to get work done... Sorry, background processes are part of getting shit done. Users should be able to spin up the stuff they want to spin up in the network segments they have access to without the bureaucracy of misguided fools making the jobs of others more difficult because they think spinning up a gunicorn process or a custom daemon is worse than their unpatched kernel, apache tomcat and mysql listening on a publicly accessible address. Stateful firewalls and hosts allow/deny are there for a reason.

Sorry for the snarky reply here but there are a lot of people chiming in that obviously have very little knowledge about managing *nix ops and remote access. I have pretty strong opinions about this kind of stuff. Especially the single key stupidity and not checking host fingerprints.

Post reply on HN