Why Not Use Port Knocking? (2012)(bsdly.blogspot.in)
bsdly.blogspot.in
Why Not Use Port Knocking? (2012)
http://bsdly.blogspot.in/2012/04/why-not-use-port-knocking.html
13 comments
Obligatory: 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.
I once had a legitimate use case for port knocking. The network monitoring software at Yahoo! Japan was very strict and you were not allowed to connect to a system outside of their network via SSH. (Don't get me started on the local spyware installed on everyone's Windows boxes... that was easy to inject a DLL into and crash though). Me being extremely evil, wanted to connect to my home computer over SSH.
They had a loophole that the network monitoring system would trigger an alert that gets manually verified. If the port was open, they could verify that it was an actual SSH server. If the port was closed, they would write it off as a false alarm.
They had a loophole that the network monitoring system would trigger an alert that gets manually verified. If the port was open, they could verify that it was an actual SSH server. If the port was closed, they would write it off as a false alarm.
sslh[1] usually allows you to reach it even through fairly restrictive firewalls. At least unless they have their certs installed and inspect ssl traffic.
[1] http://www.rutschle.net/tech/sslh.shtml
[1] http://www.rutschle.net/tech/sslh.shtml
They don't need to have certs installed, since sslh doesn't actually tunnel SSH-over-SSL, it just redirects the connection to the right daemon. Simply pointing ssh to that port would have given up the trick.
Most useful comment in this whole conversation. Incredibly handy for home servers - for which I'd just resigned myself to the fate of running ssh on port 80.
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 with SSH tunneling.
IMO, If your aim is to provide a clandestine entry point to your network, port knocking is amazingly effective. Your host can be completely silent on the internet and seemly be offline but still provide network services. Keep a honeypot online on the same network and most attackers will be busy for weeks/months.
IMO, If your aim is to provide a clandestine entry point to your network, port knocking is amazingly effective. Your host can be completely silent on the internet and seemly be offline but still provide network services. Keep a honeypot online on the same network and most attackers will be busy for weeks/months.
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.
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.
I'm failing to see what this has to do with the threat model that port knocking addresses. Suffice it to say that an attacker who has access to your SSH identity file has with virtually total certainty access to your SSH passphrase as well.
I'm failing to see what this has to do with the threat model that port knocking addresses.
You said:
I think port knocking is really silly and you shouldn't waste time with it. Disable root logins and password logins in SSH.
I'm pointing out that will lead to less security, not more, for the stated reason.
Suffice it to say that an attacker who has access to your SSH identity file has with virtually total certainty access to your SSH passphrase as well.
How so? By brute for cracking it?
You said:
I think port knocking is really silly and you shouldn't waste time with it. Disable root logins and password logins in SSH.
I'm pointing out that will lead to less security, not more, for the stated reason.
Suffice it to say that an attacker who has access to your SSH identity file has with virtually total certainty access to your SSH passphrase as well.
How so? By brute for cracking it?
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 to configure it. This would be simpler than the SSH-to-SSH solution.
Personally I would like to have both, in succession, but have not found a way to configure it. This would be simpler than the SSH-to-SSH solution.
> 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?
Key files can be password protected. Do you mean "(key+password) + password" or just not aware of passworded keyfiles?
If you can force authentication via both private key and a password, then you're authenticating via both "something you have" (the key), and "something you know" (the password). Having a passphrase on the key protects access to the key, but it doesn't provide any additional levels of authentication to the (remote) system that is requesting authentication — after all, the user could have removed the passphrase from the key file, there's no way for the remote system to know.
Unfortunately, there doesn't seem to be a way to require both a key and a passphrase to be entered. There may be a way to do it with some (custom?) pam configuration/modules, but as far as I know, nothing in sshd itself.
Unfortunately, there doesn't seem to be a way to require both a key and a passphrase to be entered. There may be a way to do it with some (custom?) pam configuration/modules, but as far as I know, nothing in sshd itself.
Not sure how robust it would be, but you can set a default shell that would be a simple script requiring log in before launching bash. That would give you both.
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.
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.
If you want two factors for SSH authentication, you can and should set up a two-factor auth system, like Duo.
Any resources on best practices for a bastion host?
I personally see port knocking with cryptographic payload just as one tool on layered security. I'm still wondering why people bother horrible VPN/IPsec junk with annoying clients. I got something like 10 different clients installed. It shouldn't be required at all, if systems and protocols are already secure. You can use something like TOTP key as payload to open ports up or something more complex/secure if you want.
Afaik passwords aren't bad option either. You should consider password as shared secret blob, not as password. It's as unlikely that someone is going to guess 256 bit password as it is that they guess any other 256 bit secret.
Afaik passwords aren't bad option either. You should consider password as shared secret blob, not as password. It's as unlikely that someone is going to guess 256 bit password as it is that they guess any other 256 bit secret.
Completely off topic - I find the term "Port Knocking" somewhat amusing as my home village is Portknockie
http://www.portknockiewebsite.co.uk/
[NB I say home as my family has been there pretty much forever, I live in Edinburgh]
http://www.portknockiewebsite.co.uk/
[NB I say home as my family has been there pretty much forever, I live in Edinburgh]
Heh...unusual to bump into another HN'er from the North East. My folks used to do the family "Sunday Drive" through Portnockie then onwards to Cullen for a fish supper or picnic on Cullen beach. I'm in Dunning now.
> Title: Why Not Use Port Knocking?
For me, the answer is simple: It violates Kerckhoffs’s principle¹. If you want more secret bits that users need to know in order to access your system, increase your password lengths. If you want to keep log sizes manageable, adjust your logging levels.
1) https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
For me, the answer is simple: It violates Kerckhoffs’s principle¹. If you want more secret bits that users need to know in order to access your system, increase your password lengths. If you want to keep log sizes manageable, adjust your logging levels.
1) https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
> If you want to keep log sizes manageable, adjust your logging levels.
Changing the port is a really good and simple fix. If you also drop packets to closed ports instead of rejecting them, you slow the scan down enough that only a targeted attack is likely to find your ssh port.
All that with no performance penalties, no cumbersome configuration, no experimental software, with one change to one config file. I say do it.
Changing the port is a really good and simple fix. If you also drop packets to closed ports instead of rejecting them, you slow the scan down enough that only a targeted attack is likely to find your ssh port.
All that with no performance penalties, no cumbersome configuration, no experimental software, with one change to one config file. I say do it.
I'm not a fan of changing the SSH port, but at least I get what that buys you.
Changing port is the wrong solution to large log files. This seems obvious to me, but maybe I can put forward another drawback of changing the port number: It is confusing.
I mean, you could easily stop using the DNS and use raw IP addresses for everything - this should cut down on your attacks and maybe even spam, right? Nobody does this because it it insanely inconvenient, and ignores the solution to this inconvenience which DNS is. Standardized port numbers exist for many reasons - do not abandon them and create complexity for your fellows merely for your personal convenience.
I mean, you could easily stop using the DNS and use raw IP addresses for everything - this should cut down on your attacks and maybe even spam, right? Nobody does this because it it insanely inconvenient, and ignores the solution to this inconvenience which DNS is. Standardized port numbers exist for many reasons - do not abandon them and create complexity for your fellows merely for your personal convenience.
> I mean, you could easily stop using the DNS and use raw IP addresses for everything - this should cut down on your attacks and maybe even spam, right?
No, it wouldn't. But you do have a point. And most sysadmins don't let just anyone axfr their zone.
Like changing the port, it's not a security measure and it will inconvenience someone every once in a while. Still, I don't need to advertise every host I run.
Same with using a PO box or your provider's info for whois. It's not going to deter anyone determined but it cuts down on some casual annoyances.
EDIT: Also, setting the port
No, it wouldn't. But you do have a point. And most sysadmins don't let just anyone axfr their zone.
Like changing the port, it's not a security measure and it will inconvenience someone every once in a while. Still, I don't need to advertise every host I run.
Same with using a PO box or your provider's info for whois. It's not going to deter anyone determined but it cuts down on some casual annoyances.
EDIT: Also, setting the port
Host *.whatever.net
IdentityFile ~/.ssh/whatever
ServerAliveInterval 10
port 17022
> it's not a security measure and it will inconvenience someone every once in a while
So why do it? And port knocking will inconvenience every user, all the time.
> setting the port in ssh config costs you nothing
It costs complexity for all users of the system. This includes you, all other people using it, all servers and their services wanting SSH access, etc. Standards are a good thing.
So why do it? And port knocking will inconvenience every user, all the time.
> setting the port in ssh config costs you nothing
It costs complexity for all users of the system. This includes you, all other people using it, all servers and their services wanting SSH access, etc. Standards are a good thing.
The issue is, the SSH server is many tens of thousands of lines and extremely complex, while a port-knocking implementation might be a few hundred lines and very easy to audit. It's much easier to be certain that the simple one is bug free. The simple one protects the complex one.
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?
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?
Unfortunately OpenSSH doesn't give you that much control over logging. In my setup I'd like to log successful logins as well as failed login attempts for users that exist, excluding root because logins for root are disabled. This would keep all the scripted (and wholly inneffectual) break-in attempts from flooding the logs while allowing the sysadmin to keep an eye on the more interesting events.
I don't use port knocking, nor do I run sshd on a nonstandard port, but I perfectly understand the people who do that just to keep the log spam down.
I don't use port knocking, nor do I run sshd on a nonstandard port, but I perfectly understand the people who do that just to keep the log spam down.
The sequence of ports becomes a key. I don't think the principle is violated.
What I think is that you should disable password authentication anyway, and adding port knocking to a ssh server that doesn't accept passwords is equivalent to adding a thin wood plank to a 20" steel door with an state of the art lock.
What I think is that you should disable password authentication anyway, and adding port knocking to a ssh server that doesn't accept passwords is equivalent to adding a thin wood plank to a 20" steel door with an state of the art lock.
But the sequence can be found by sniffing the network connection. Unlike the ssh passwords, which aren't ever transmitted in plain text.
> The sequence of ports becomes a key.
Yes, I agree completely. Which is why it buys you nothing compared to simply increasing your password/key lengths with the equivalent number of bits. On the contrary, it introduces confusing complexity for oneself and one’s fellows. Maybe this is what unconscionable people call “Job security”?
> equivalent to adding a thin wood plank
It is less like a thin wooden plank and more like a hedge maze which all legitimate users also must traverse each time. And all the hedges are made of asbestos.
Yes, I agree completely. Which is why it buys you nothing compared to simply increasing your password/key lengths with the equivalent number of bits. On the contrary, it introduces confusing complexity for oneself and one’s fellows. Maybe this is what unconscionable people call “Job security”?
> equivalent to adding a thin wood plank
It is less like a thin wooden plank and more like a hedge maze which all legitimate users also must traverse each time. And all the hedges are made of asbestos.
Reason by analogy much? Layered security and out of band. Flaw in ssh? Still have another speed bump in the attack vector.
Not only is port knocking just adding a key that gives you nothing over a longer password or actual ssh key, but it's also a key that you send in plaintext over public networks every time you connect.
I've used it before, though this article seems to be fixated upon a fixed port sequence and fairly compares that to a password layer that is futile as between you and the server your knocking many people can see and know that sequence, making it moot.
Which I agree with. But if you use a port sewquence derived from a S/KEY, then each port knock sequence is a one time sequence never to be repeated.
It is a simple and dirty level of security using the much hated obscurity approach, but by varying the ports via a aranged S/KEY sequence you can move it up a whole level. S/KEY easy to do and worked well on old old old nokia over 10 years ago as a little simple java app. Just using it to derive a port sequence instead of a one time password.
Which I agree with. But if you use a port sewquence derived from a S/KEY, then each port knock sequence is a one time sequence never to be repeated.
It is a simple and dirty level of security using the much hated obscurity approach, but by varying the ports via a aranged S/KEY sequence you can move it up a whole level. S/KEY easy to do and worked well on old old old nokia over 10 years ago as a little simple java app. Just using it to derive a port sequence instead of a one time password.
I don't use port knocking but:
"all implementations had the downside of adding yet another piece of clearly experimental software to my system along with somewhat convoluted procedures for setting the thing up" what? you can add port knocking with literally 3 iptables rules, netfilter is a rock-solid proven piece of software.
"explain to me what problem this is supposed to solve." visibility: if target cannot be found there's no target to attack; security by obscurity is good (as long as security doesn't depend just on it).
I use bastion host to ssh to my servers with key and different port (yes different port is good; for a couple of sysadmins who cares we broke some standard?)
"all implementations had the downside of adding yet another piece of clearly experimental software to my system along with somewhat convoluted procedures for setting the thing up" what? you can add port knocking with literally 3 iptables rules, netfilter is a rock-solid proven piece of software.
"explain to me what problem this is supposed to solve." visibility: if target cannot be found there's no target to attack; security by obscurity is good (as long as security doesn't depend just on it).
I use bastion host to ssh to my servers with key and different port (yes different port is good; for a couple of sysadmins who cares we broke some standard?)
> for a couple of sysadmins who cares we broke some standard?)
<s> (. I think I'll change the protocol numbers of TCP and UDP to use each others' numbers. Complete protection! No standard TCP/IP stack will be able to connect! Yay! .) </s>
<s> (. I think I'll change the protocol numbers of TCP and UDP to use each others' numbers. Complete protection! No standard TCP/IP stack will be able to connect! Yay! .) </s>
I meant changing ssh port from 22 to whatever, not breaking the protocols, since it's internal use who cares (I found people who does). Actually you only need to follow port standards for public-facing stuff, typically just DNS, mail (pop, imap/s), http(s)
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?
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?
Which do you want to know about?
Each value is a 16-bit number, with a size of two bytes, or equal to two ASCII characters or one Unicode character. Port knocking examples generally do not run to more than three packets, which means that the minimum amount of information a prospective attacker would need to get right in order to gain access is six bytes, equal to six ASCII characters or three Unicode characters.
Is the brute force effort being simplified too much? Wikipedia entry says this about brute force attack on port-knocking: As a stateful system, the port would not open until after the correct three-digit sequence had been received in order, without other packets in between.
That equates to a maximum of 655363 packets in order to obtain and detect a single successful opening, in the worst case scenario. That's 281,474,976,710,656 or over 281 trillion packets. On average, an attempt would take approximately 9.2 quintillion packets to successfully open a single, simple three-port TCP-only knock by brute force.
Is the brute force effort being simplified too much? Wikipedia entry says this about brute force attack on port-knocking: As a stateful system, the port would not open until after the correct three-digit sequence had been received in order, without other packets in between.
That equates to a maximum of 655363 packets in order to obtain and detect a single successful opening, in the worst case scenario. That's 281,474,976,710,656 or over 281 trillion packets. On average, an attempt would take approximately 9.2 quintillion packets to successfully open a single, simple three-port TCP-only knock by brute force.
Could you clarify your maximum packets math? You may have left out a word or two.
Maximum packet maths came from the wikipedia entry.
http://en.wikipedia.org/wiki/Port_knocking . First two paragraphs under the "Benefits" section.
I see.
You wrote:
"That equates to a maximum of 655363 packets in order to obtain and detect a single successful opening."
They wrote:
"That equates to a maximum of 65536 ^ 3 packets in order to obtain and detect a single successful opening."
You wrote:
"That equates to a maximum of 655363 packets in order to obtain and detect a single successful opening."
They wrote:
"That equates to a maximum of 65536 ^ 3 packets in order to obtain and detect a single successful opening."
I 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.)
https://en.wikipedia.org/wiki/De_Bruijn_sequence
https://en.wikipedia.org/wiki/De_Bruijn_sequence
fwknop ( 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.
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.
I see port knocking as protection against an 0day sshd exploit instead of protection against brute forcing.
The article didn't really mention that angle.
The article didn't really mention that angle.
That was a lot of words to encourage use of authors own tool instead of or aside perhaps even with port knocking.
The article hasnt anyway delivered any meaningful reason not to use port knocking, just a few straw-man arguments such as "most people only setup 3 port sequences".
The idea presented though is an interesting one, run your ssh on one port, and when that one authenticates with any method, only then allow connections to a second ssh on another port, which has perhaps only then begun listening or being allowed to accept connections from that specific uid, and if that authenticates then the user is in. Like having two gates infront of a city instead of a secret handshake with 16 port sequences say.
The article hasnt anyway delivered any meaningful reason not to use port knocking, just a few straw-man arguments such as "most people only setup 3 port sequences".
The idea presented though is an interesting one, run your ssh on one port, and when that one authenticates with any method, only then allow connections to a second ssh on another port, which has perhaps only then begun listening or being allowed to accept connections from that specific uid, and if that authenticates then the user is in. Like having two gates infront of a city instead of a secret handshake with 16 port sequences say.
There are two broad classes of attackers: targeted attackers, who specifically want to get into your system, and script kiddies who are scanning broad swaths of the Internet looking for an easy target. Most of these countermeasures, like port knocking and moving sshd to a different port, do very little to dissuade the first group. But they make you much less of a target for the second group.
These discussions (and so many security discussions on the internet) make the argument that unless something is effective against targeted attackers, it's not worth doing. That's ridiculous. In the 20+ years I've been running computers on the internet, targeted attackers are outnumbered by random scans thousands to one. Of course, you'll say, any countermeasure that's good enough to stop targeted attackers is good enough to stop these guys as well. And that's true, but for two things:
1. I like my logging and alerting to intentionally be loud when a targeted attacker is messing with my system. By raising the bar enough so that only targeted attackers get through, I'm able to do that.
2. There have been zero-day vulnerabilities in probably most of the daemons I've run over the years. And when those zero-days come, I inevitably get hit with random scans looking for vulnerable versions. Those are almost always stopped cold by things as simple as running on a different port. I'd like to think I'm pretty good at keeping up with vulnerability alerts and updating my software when something like that happens, but simple changes that buy me a little time aren't a bad thing.