I don't use port knocking because spiped is simpler and far more secure.
First I've heard of spiped/tarsnap, what makes it more secure?
Why Not Use Port Knocking? (2012)
41–50 of 57 posts
Re: Why Not Use Port Knocking? (2012)
#42Obligatory: I think port knocking is really silly and you shouldn't waste time with it. Disable root logins and password logins in SSH. If you have lots of hosts running SSH, collapse them down to one exposed SSH bastion host. Then get on with your life.
Any resources on best practices for a bastion host?
Re: Why Not Use Port Knocking? (2012)
#43I don't use port knocking because spiped is simpler and far more secure.
First I've heard of spiped/tarsnap, what makes it more secure?
spiped and tarsnap are two different things -- spiped is a daemon for creating encrypted pipes, and tarsnap is an online backup service.
Which do you want to know about?
Re: Why Not Use Port Knocking? (2012)
#44Earlier quoted context omitted.
In case anyone ever wonders why "disable password logins" is commonly used as a synonym for "use keys", it's because of the config file and the way SSH for Linux works. If you enable both passwords and keys, then either will succeed instead of both being required! This unintuitive result is a rather dire "gotcha" for anyone new to the task. Personally I would like to have both, in succession, but have not found a way…
> Personally I would like to have both, in succession Key files can be password protected. Do you mean "(key+password) + password" or just not aware of passworded keyfiles?
Different issue. It is definitely best practice to use a long passphrase to protect every secret key, this is off topic.
What I meant was, you connect to the SSH server and authenticate cryptographically (use passphrase locally when prompted) - then you also need a logon + password for the SSH server to complete the authentication. This would reject the internet noise banging on the port, but impose a 2 factor test.
Re: Why Not Use Port Knocking? (2012)
#45Obligatory: I think port knocking is really silly and you shouldn't waste time with it. Disable root logins and password logins in SSH. If you have lots of hosts running SSH, collapse them down to one exposed SSH bastion host. Then get on with your life.
If you're concerned enough to set up an SSH bastion host, do the right thing and set up a VPN. Not only is it a completely separate application (vs two SSH daemons which might both be exploited by a single 0day), it gives you fine-grained control over what users get access to what parts of the network, it doesn't magically grant a user shell, and ultimately allows for tunneling any network service without fumbling wi…
A VPN is also a fine answer. I'm marginally more worried about the code quality of something like openvpn than I am about openssh at this point, but six of one.
I think the "clandestine entry point" stuff is mostly a psychological benefit.
Re: Why Not Use Port Knocking? (2012)
#46fwknop ( http://www.cipherdyne.com/fwknop/ ) uses a single connection try (with certificates and that cannot be replayed even if captured) to open a port. It adds another potential point of failure in your chain to access, but if is simple and well tested enough could work as a protection.
And the main reason to have port knocking (over, i.e. fail2ban) is not stopping brute force attacks, but future vulnerabilties and exploits in services that should not be used by the whole internet. If there are very few persons, or machines that should connect to a service (and the origin IPs are not fully known to enable just them in the firewall) putting a fwknop or similar layer over that services should avoid external people to even try to connect to those services.
And there actually had been vulnerabilities in ssh, vpns, puppet (a remote code execution vulnerability for it has been patched this very week) and more that could had been exploited before you knew about them.
Also, "plain" port knocking could be protected against brute force scanning by having trap ports, if you hit them, then your IP is blocked. That won't protect from MITM that see how you connect (NSA at the very least), but will prevent scanning.
Re: Why Not Use Port Knocking? (2012)
#47Earlier quoted context omitted.
If you have cause to worry about security holes in SSH, you should not rely on port knocking to protect you.
That does not follow. Making a service unavailable to an attacker is an excellent way to prevent it from being attacked. And ssh may have holes in it, it was written by people, people make mistakes and there have been holes in it in the past.
Adding a port knocking in front of your ssh server do not make the service unavailable to attackers. At best it deter some attackers, based on the same principal that some store owners puts up a cardboard box painted to look like a video camera. If the added "security" prevents most onlookers and casually would-be-attackers, then the cardboard box is indeed an excellent way to prevent the store from being attacked.
It is still however a cardboard box with paint on it. The effectiveness disappear the second criminals bother to test the illusion. What I then wonder is, did the store owner trust the cardboard box effect to the degree of not installing a proper door, lock and alarm?
Re: Why Not Use Port Knocking? (2012)
#48Earlier quoted context omitted.
If you're concerned enough to set up an SSH bastion host, do the right thing and set up a VPN. Not only is it a completely separate application (vs two SSH daemons which might both be exploited by a single 0day), it gives you fine-grained control over what users get access to what parts of the network, it doesn't magically grant a user shell, and ultimately allows for tunneling any network service without fumbling wi…
A VPN is also a fine answer. I'm marginally more worried about the code quality of something like openvpn than I am about openssh at this point, but six of one. I think the "clandestine entry point" stuff is mostly a psychological benefit.
And it reduces junk in the log.
Re: Why Not Use Port Knocking? (2012)
#49I wonder if some port knocking schemes can be attacked using a De Bruijn sequence. If the firewall only examines the last N potential knocks amongst K ports, sent from a given IP address, then every possible combination of knocks can be bruteforced in just K^N knocks (by taking into account the existence of every permutation as a subsequence within the De Bruijn sequence) instead of the more obvious (K^N)*N knock solution (naively trying each permutation in sequence.)
Re: Why Not Use Port Knocking? (2012)
#50Obligatory: I think port knocking is really silly and you shouldn't waste time with it. Disable root logins and password logins in SSH. If you have lots of hosts running SSH, collapse them down to one exposed SSH bastion host. Then get on with your life.
He's why it's not silly and why disabling password logins and using key-based logins in SSH doesn't increase your security:
If you turn off password logins, people will use authorized_keys to in effect get a password-less login. If their public key has a password, this is OK, since they're either using ssh-agent or typing in their password at the time of the login. However, what if their ssh key has no password on it? That gives a password-less login path to my host, which is less secure. The problem is, it is impossible to detect, on the server side, a login with a key with no password.