Secure SSH using Port Knock

Great.. But unless you are using password authentication SSH is a perfectly secure service and doesn't need to be hidden by methods like these. Port knocking is just one more thing to go wrong.

Maybe port knocking is useful somewhere else though. I'm not sure where.

@sednet:

Great.. But unless you are using password authentication SSH is a perfectly secure service and doesn't need to be hidden by methods like these. Port knocking is just one more thing to go wrong.

Maybe port knocking is useful somewhere else though. I'm not sure where.

HHHHMMMMMMMMMMM

http://www.cloudlinux.com/blog/clnews/sshd-exploit.php

@richardschmd:

HHHHMMMMMMMMMMM

http://www.cloudlinux.com/blog/clnews/sshd-exploit.php

That's not really a SSHD exploit, not a vuln in sshd. AFAIK that vector was trojaned sysadmin computers with keyloggers and password auth.

@richardschmd:

@sednet:

Great.. But unless you are using password authentication SSH is a perfectly secure service and doesn't need to be hidden by methods like these. Port knocking is just one more thing to go wrong.

Maybe port knocking is useful somewhere else though. I'm not sure where.

HHHHMMMMMMMMMMM

http://www.cloudlinux.com/blog/clnews/sshd-exploit.php

That was not a SSH issue. If you give away your house keys it doesn't matter how good your locks are.

OpenSSH has an excellent security history. You can read about known issues in old versions at http://www.openssh.org/security.html. Also there was an incident where the Debian project broke the entropy mixing code and shipped an OpenSSH version that generated keys from a limited pool of random numbers.

Turn off password authentication, use long ECDSA key pairs, turn on privilege separation, and for no money you have the best security going. The other things people put around SSH like port knocking, fail2ban, iptables rate limiting, and using non-standard ports may save some disk space because they log fewer attacks but I don't believe they improve security at all.

Typically port knocking shouldn't be viewed as a security measure because, well, it isn't. I've always viewed it as just a way to reduce noise in the logs generated by script kiddies. fail2ban and similar don't reduce log noise and typically create more problems (e.g. locking out legit users which takes time to unlock, generating even more noise in logs, heavy overhead in iptables with lists of thousands of hosts to block, etc.)

If you really need to hide ports in a secure way you should consider running OpenVPN (http://openvpn.net/) or at least run a secure port knocker: http://www.thoughtcrime.org/software/knockknock/

I used to run port knockers when I was running some servers with high hacker value, but those were the days before phones and other devices that can be hard/impossible to generate knocks. Now I just run on a non-standard port (to reduce log noise without overhead of fail2ban) but I'm probably going to move to OpenVPN.

Crysis

I was just trying to help……

Thats the first and last post from me…….

@richardschmd:

Crysis

I was just trying to help……

Thats the first and last post from me…….

Don't sweat it. Saying the sky is blue would provoke an argument around here.

http://www.cipherdyne.org/fwknop/

Peer Review - it's what keeps engineering (and science, tech, etc) honest.

Debate (i.e. the naysayers) is good. Either your idea is defensible, or it's not.

Bringing up both sides of the idea allows people that find your article to rethink whether it's worth them deploying (or not).

So don't take it personal, you posted a nice article, and others brought up the point that it might not be the most secure method out there. It's all good.

There have been vulnerabilities discovered in OpenSSH before, although none have been found for a reasonable length of time it could happen again - any day.

If a serious 0day for OpenSSH was dropped tomorrow then it could be disastrous, all of the low hanging fruit would be picked off first.

• Changing your default port raises the fruit a little.

• Using port knocking raises the fruit even further.

You have to decide about the trade-offs you are willing to make in reducing your attack surface (which I feel should be reduced where possible). Is mitigating against an 0day threat something you need? For some absolutely!

Some port knocking implementations are more secure than others but it's all about finding a balance that works best for your requirements. Even the weaker port knocking implementations will still help with defence in depth.

@sednet:

@richardschmd:

Crysis

I was just trying to help……

Thats the first and last post from me…….

Don't sweat it. Saying the sky is blue would provoke an argument around here.

Seriously. This is an informative thread to those of us who are less familiar with this world.

Thanks :)

I think it's a valid idea. People who say fail2ban and port knocking are not security measures and only reduce log noise need to review the fact that they are security measures because they reduce or positively affect attack surface.

http://en.wikipedia.org/wiki/Attack_surface

@jebblue:

I think it's a valid idea. People who say fail2ban and port knocking are not security measures and only reduce log noise need to review the fact that they are security measures because they reduce or positively affect attack surface.

http://en.wikipedia.org/wiki/Attack_surface

People say they are not security measures because they are not. A service which is secure without fail2ban or port knocking does not have its security increased by using them, and their addition does not provide security to an insecure system. If password or key strength is low, the kind of limiting done by fail2ban won't help, and port knocking is pretty much the definition of security by obscurity.

For people looking to further lock down SSH and similar services, I'd suggest these, in rough order of decreasing reward/work ratio:

• 2 factor auth (Google's PAM repo is easy to configure: https://code.google.com/p/google-authenticator/ )

• fwknop ( https://github.com/mrash/fwknop ) or knockknock ( https://github.com/moxie0/knockknock ), both of which use signed requests to actually accomplish what "port knocking" claims to: providing an authentication layer before communicating with the real SSH daemon

• VPN: Putting your services inside a VPN does roughly the same thing, with the downside of being a bit more configuration work and the upside of covering a much larger range of services.

• Les

@akerl:

@jebblue:

I think it's a valid idea. People who say fail2ban and port knocking are not security measures and only reduce log noise need to review the fact that they are security measures because they reduce or positively affect attack surface.

http://en.wikipedia.org/wiki/Attack_surface

People say they are not security measures because they are not. A service which is secure without fail2ban or port knocking does not have its security increased by using them, and their addition does not provide security to an insecure system. If password or key strength is low, the kind of limiting done by fail2ban won't help, and port knocking is pretty much the definition of security by obscurity.

For people looking to further lock down SSH and similar services, I'd suggest these, in rough order of decreasing reward/work ratio:

• 2 factor auth (Google's PAM repo is easy to configure: https://code.google.com/p/google-authenticator/ )

• fwknop ( https://github.com/mrash/fwknop ) or knockknock ( https://github.com/moxie0/knockknock ), both of which use signed requests to actually accomplish what "port knocking" claims to: providing an authentication layer before communicating with the real SSH daemon

• VPN: Putting your services inside a VPN does roughly the same thing, with the downside of being a bit more configuration work and the upside of covering a much larger range of services.

• Les

http://tech.slashdot.org/story/01/07/23 … snt-so-bad">http://tech.slashdot.org/story/01/07/23/2043209/when-security-through-obscurity-isnt-so-bad

"But it doesn't hurt to obscure things sometimes just to make it tougher for your attacker."

My original point is that security through obscurity is a way to improve security posture and for me that makes it a security measure. Is it security on its own? No. Is "engineered security" enough, no, look at Heartbleed as an example of why. Or the RSA scare a few years ago.

edit: Or the SSH scare on debian.

The idea that setting up a series of hurdles is the path to a secure system is one of the most depressing misconceptions in modern security practice. Stacking in things on the principle that more steps is better is roughly equivalent to the current US airport security theatre.

These days, just having a strong password or key is enough to project your from roving bots. The remaining threat pool is "targeted attacker", and a targeted attacker isn't going to be affected by your port knocking or changed port or fail2ban.

• Les

You mean changing 'root' to 'thisisnotroot' doesn't really help my security?

>> The idea that setting up a series of hurdles is the path to a secure system is one of the most depressing misconceptions in modern security practice.

I've stated, clearly, twice, what it is and what I'm saying it is. Hurdles, using your term, are a deterrent. I have over a decade in the military and am speaking English as a sign of the fact that deterrents do work. They are not a guarantee, they are not a total solution. What they also do not do is hurt to use them.

http://www.thefreedictionary.com/security+measures

"a precautionary measure warding off impending danger or damage or injury etc."

You could also Google "warding off".