Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature: Security
A critique of port knocking
By Arvind Narayanan
on
August 10, 2004 (8:00:00 AM)
Share
Print
Comments
Suppose you want to be able to retrieve files from your Linux system remotely. The "standard" method of running the SSH server on port 22 is notoriously inadequate. OpenSSH, which is the SSH server on the majority of Linux
installations, suffers from regular exploits of buffer overflow and other vulnerabilities,
and you neither have the time to keep up with the patches nor want to make the effort -- you'd rather put up with not being able to access your files. This is where port knocking might seem to help -- but don't count on it.
Port knocking is a method of "message transmission across closed
ports." It works like this: initially a firewall blocks all ports on
the server. The client issues a series of connection requests (knocks)
to different ports; these are, of course, dropped since the ports are blocked.
However, there is a daemon that monitors the log files for connection
requests, and the sequence of requests serves as an encrypted code. If
the code makes sense to the daemon, it enables SSH or another service
(for a particular IP address and on a particular port encoded by the knock
sequence).
Port knocking acts as an extra layer of security. It is also claimed to have the advantage of stealth: an attacker can't detect whether you're using port knocking or not.
But how effective is it?
Let's dispose of the stealth argument first. Suppose that port knocking becomes widely used (and surely that's the point of its existence?). Say it is running on 10% of all servers. Then an attacker simply assumes that the target machine is using port knocking and proceeds to attack it. The attack succeeds with a probability of one in 10 (of what it would have been if stealth were not employed), but those odds are worthwhile to the attacker, considering that the cost of the attack is far smaller than the expected gains from a successful attack. This kind of technique is quite common in port scanning -- crackers use multiple automated methods, each of which has only a small probability of success, but which taken together prove very effective.
The stealthiness of port knocking is limited in scope -- your machine appears uninteresting to someone who's scanning a whole range of IPs for open ports. A more dedicated attacker has a multitude of methods to infer that the target machine could be using port knocking, such as sniffing the (highly distinctive!) stream of packets in the knock sequence, observing that a machine known to host a service appears to have no ports open, social engineering, or even something as silly as finding a entry like "I got port knocking working today! w00t!" buried deep in the user's Weblog.
Security through obscurity is bad when it is the sole defense. This is true in a general theoretical sense, and there is always a cost associated with making the system more complicated in order to add an extra obscurity layer. In the case of port knocking, the hoops you need to jump through to achieve stealth far outweight the marginal benefits. Furthermore, there are much cleaner ways to achieve stealth, as we will see in a moment.
Once stealth is taken out of the equation, it becomes clear what port scanning really is. A port is not a physical object but merely a 16-bit integer. A sequence of knocks is therefore just a sequence of bits that lets you in -- in other words, a passphrase. So port knocking is simply a method to authenticate yourself with a passphrase. The obvious question then is, in what way is this convoluted and inefficient method of sending a passphrase across a network better than the straightforward method of putting it in a packet and sending it? The obvious answer is, it is not. (The second obvious question is, how is it different from authenticating yourself with a passphrase using SSH? But we'll get to that shortly.)
Think of security as an onion. If properly designed and implemented, each layer presents a new hurdle to the attacker. This is called "defense in depth." But the onion structure comes at a cost: it becomes much more difficult to analyze the security of the system. All too often, the layers serve as obfuscation and give you an illusion of security while leaving a single weak point open to an attacker.
To avoid falling into this trap, build your onion from standard components and to put them together in standard ways. On the other hand, everything about port knocking is about implementing crypto primitives in an obscure manner. If you're using a key, you call it a key. You gain nothing by calling it a sequence of port numbers; in fact, you lose a lot. When you think of a key as a key, it's clear that you shouldn't store it in any public location. On the other hand, log files (which contain the key in the form of port sequences) can lie around for ages. This is a typical example of how nonstandard terminology and implementation complicates analyzing the security of a system.
There are two reasons why a port knocking attacker may be thwarted: one is that only some ports are allowed in knock sequences (customized by the user) and the second is that the knock sequence can be encrypted with a password. The first defense is an extremely poor one. Security should reside only in knowledge of the key, and not in bits and pieces sprinkled throughout the system. That's Kerchoffs' law, often used as a rallying cry against security through obscurity.
The second defense is much better, but amazingly, it is presented as optional in the port knocking overview page. There is in fact little or no security in port knocking without encrypting knock sequences. Even with it, there are problems.
Firstly, the unnecessary only-some-ports-valid "protection layer" complicates things. Suppose you decide on a list of 32 valid ports (the current implementation allows up to 256). How long does the port knock sequence need to be? You might think that since each port is a 16-bit integer, you need 8 knocks, so that you get 8*16 bits or 128 bits of security (virtually unbreakable). But since each port has only 32 possible values (5 bits), what you actually get is only 8*5=40 bits of security (trivially breakable)! Granted, this is a problem for the implementer and not for the end user, and the current (proof-of-concept) implementation appears to take care of the length issue. But it is easy to go wrong. This is a particularly serious problem, since there is bound to be pressure on the implementer to make the knock sequence as short as possible, since it can easily take a minute to complete a port knock. When trying to reach a compromise between the two conflicting goals, security flaws result.
Secondly, there's the matter of what you're going to do about replay attacks. A replay attack is one where a router sitting between the client and the server passively sniffs what the client is sending, and sends the same bitstream after a while to the server, pretending to be the client. The standard defense is a challenge-response protocol, but that is of course ruled out because we don't want the server to send anything until the client authenticates itself. The documentation says that a flag field is added to the knock sequence and incremented for each port knock, preventing replay attacks. But this is nonstandard and dubious. What happens when the server is rebooted? What if the counter resets? As far as I can figure out, only a single-byte field is allocated for the flag, which makes resetting a real threat.
In general, port knocking has too many points of potential attack. In particular, anyone with non-root access to the server should be able to trivially break the system. This does not seem to be of concern to the developers.
Lessons from port knocking
There are several security lessons we can take from port knocking. There is a demand for barebones authentication system without bells and whistles that doesn't require maintenance. The problem with OpenSSH is that it tries to do everything. When designing a barebones system, it is essential to keep the target audience in mind and to decide the scope in terms of what features it will offer and what attacks it is designed to resist. I like the fact that the port knocking implementation is not written in C, a language which is subject to buffer overflow bugs. The approach of layering port knocking over SSH instead of replacing it is certainly sound. On the other hand, reinventing cryptography is definitely unsound.
Let us therefore take the port knocking out of port knocking and see what we get. It is a simple system for manipulating firewall rules based on standard password-based authentication and symmetric key encryption. By implementing this hypothetical daemon in a high level language and zealously resisting the urge to add any other features, we can greatly reduce the bugginess and possibly achieve a reasonable approximation to zero-maintenance. Stealth can be added: have the service run on a UDP rather than a TCP port. Since UDP is connectionless, the concept of closed and open ports is much weaker than for TCP. By having the application send out an ICMP_PORT_UNREACH message whenever a packet is received on that port (but nevertheless processing the packet), it can be made to look like a closed port to anyone who doesn't know the password. The extra obscurity might be useful if the overall system is simple enough. On the other hand we might forgo stealth and implement a challenge-response protocol instead to reliably stop replay attacks.
In conclusion, even though port knocking addresses a problem that many face, the solution is needlessly complicated and far from optimal.
Port knocking acts as an extra layer of security. It is also claimed to have the advantage of stealth: an attacker can't detect whether you're using port knocking or not.
But how effective is it?
Let's dispose of the stealth argument first. Suppose that port knocking becomes widely used (and surely that's the point of its existence?). Say it is running on 10% of all servers. Then an attacker simply assumes that the target machine is using port knocking and proceeds to attack it. The attack succeeds with a probability of one in 10 (of what it would have been if stealth were not employed), but those odds are worthwhile to the attacker, considering that the cost of the attack is far smaller than the expected gains from a successful attack. This kind of technique is quite common in port scanning -- crackers use multiple automated methods, each of which has only a small probability of success, but which taken together prove very effective.
The stealthiness of port knocking is limited in scope -- your machine appears uninteresting to someone who's scanning a whole range of IPs for open ports. A more dedicated attacker has a multitude of methods to infer that the target machine could be using port knocking, such as sniffing the (highly distinctive!) stream of packets in the knock sequence, observing that a machine known to host a service appears to have no ports open, social engineering, or even something as silly as finding a entry like "I got port knocking working today! w00t!" buried deep in the user's Weblog.
Security through obscurity is bad when it is the sole defense. This is true in a general theoretical sense, and there is always a cost associated with making the system more complicated in order to add an extra obscurity layer. In the case of port knocking, the hoops you need to jump through to achieve stealth far outweight the marginal benefits. Furthermore, there are much cleaner ways to achieve stealth, as we will see in a moment.
Once stealth is taken out of the equation, it becomes clear what port scanning really is. A port is not a physical object but merely a 16-bit integer. A sequence of knocks is therefore just a sequence of bits that lets you in -- in other words, a passphrase. So port knocking is simply a method to authenticate yourself with a passphrase. The obvious question then is, in what way is this convoluted and inefficient method of sending a passphrase across a network better than the straightforward method of putting it in a packet and sending it? The obvious answer is, it is not. (The second obvious question is, how is it different from authenticating yourself with a passphrase using SSH? But we'll get to that shortly.)
Think of security as an onion. If properly designed and implemented, each layer presents a new hurdle to the attacker. This is called "defense in depth." But the onion structure comes at a cost: it becomes much more difficult to analyze the security of the system. All too often, the layers serve as obfuscation and give you an illusion of security while leaving a single weak point open to an attacker.
To avoid falling into this trap, build your onion from standard components and to put them together in standard ways. On the other hand, everything about port knocking is about implementing crypto primitives in an obscure manner. If you're using a key, you call it a key. You gain nothing by calling it a sequence of port numbers; in fact, you lose a lot. When you think of a key as a key, it's clear that you shouldn't store it in any public location. On the other hand, log files (which contain the key in the form of port sequences) can lie around for ages. This is a typical example of how nonstandard terminology and implementation complicates analyzing the security of a system.
There are two reasons why a port knocking attacker may be thwarted: one is that only some ports are allowed in knock sequences (customized by the user) and the second is that the knock sequence can be encrypted with a password. The first defense is an extremely poor one. Security should reside only in knowledge of the key, and not in bits and pieces sprinkled throughout the system. That's Kerchoffs' law, often used as a rallying cry against security through obscurity.
The second defense is much better, but amazingly, it is presented as optional in the port knocking overview page. There is in fact little or no security in port knocking without encrypting knock sequences. Even with it, there are problems.
Firstly, the unnecessary only-some-ports-valid "protection layer" complicates things. Suppose you decide on a list of 32 valid ports (the current implementation allows up to 256). How long does the port knock sequence need to be? You might think that since each port is a 16-bit integer, you need 8 knocks, so that you get 8*16 bits or 128 bits of security (virtually unbreakable). But since each port has only 32 possible values (5 bits), what you actually get is only 8*5=40 bits of security (trivially breakable)! Granted, this is a problem for the implementer and not for the end user, and the current (proof-of-concept) implementation appears to take care of the length issue. But it is easy to go wrong. This is a particularly serious problem, since there is bound to be pressure on the implementer to make the knock sequence as short as possible, since it can easily take a minute to complete a port knock. When trying to reach a compromise between the two conflicting goals, security flaws result.
Secondly, there's the matter of what you're going to do about replay attacks. A replay attack is one where a router sitting between the client and the server passively sniffs what the client is sending, and sends the same bitstream after a while to the server, pretending to be the client. The standard defense is a challenge-response protocol, but that is of course ruled out because we don't want the server to send anything until the client authenticates itself. The documentation says that a flag field is added to the knock sequence and incremented for each port knock, preventing replay attacks. But this is nonstandard and dubious. What happens when the server is rebooted? What if the counter resets? As far as I can figure out, only a single-byte field is allocated for the flag, which makes resetting a real threat.
In general, port knocking has too many points of potential attack. In particular, anyone with non-root access to the server should be able to trivially break the system. This does not seem to be of concern to the developers.
Lessons from port knocking
There are several security lessons we can take from port knocking. There is a demand for barebones authentication system without bells and whistles that doesn't require maintenance. The problem with OpenSSH is that it tries to do everything. When designing a barebones system, it is essential to keep the target audience in mind and to decide the scope in terms of what features it will offer and what attacks it is designed to resist. I like the fact that the port knocking implementation is not written in C, a language which is subject to buffer overflow bugs. The approach of layering port knocking over SSH instead of replacing it is certainly sound. On the other hand, reinventing cryptography is definitely unsound.
Let us therefore take the port knocking out of port knocking and see what we get. It is a simple system for manipulating firewall rules based on standard password-based authentication and symmetric key encryption. By implementing this hypothetical daemon in a high level language and zealously resisting the urge to add any other features, we can greatly reduce the bugginess and possibly achieve a reasonable approximation to zero-maintenance. Stealth can be added: have the service run on a UDP rather than a TCP port. Since UDP is connectionless, the concept of closed and open ports is much weaker than for TCP. By having the application send out an ICMP_PORT_UNREACH message whenever a packet is received on that port (but nevertheless processing the packet), it can be made to look like a closed port to anyone who doesn't know the password. The extra obscurity might be useful if the overall system is simple enough. On the other hand we might forgo stealth and implement a challenge-response protocol instead to reliably stop replay attacks.
In conclusion, even though port knocking addresses a problem that many face, the solution is needlessly complicated and far from optimal.
Comments
on A critique of port knockingNote: Comments are owned by the poster. We are not responsible for their content.
the solution he offers is elegant and workable. I wager good odds someone will take this up inside the next few months and provide an implementation.
A solution without an implementation is, experience tells us, unproven. And with an implementation, one can test the assumptions being made.
Not defending port-knocking, but it is out there. Build a better mousetrap, they will come. Plan a better mouse trap, they won't come.<nobr> <wbr></nobr>:)
Not defending port-knocking, but it is out there. Build a better mousetrap, they will come. Plan a better mouse trap, they won't come.<nobr> <wbr></nobr>:)
You mean *besides* the one he already presented?
Another solution to what people would use port knocking for would be VPN.
Your first barrier to authentication would be VPN access to a special subnet, then SSH would be allowed from that subnet.
Port knocking is a bad idea. It's simple, replayable, and worst of all, it makes the system more vulnerable to DOSes.
Another solution to what people would use port knocking for would be VPN.
Your first barrier to authentication would be VPN access to a special subnet, then SSH would be allowed from that subnet.
Port knocking is a bad idea. It's simple, replayable, and worst of all, it makes the system more vulnerable to DOSes.
port knocking using a one-time pad?<nobr> <wbr></nobr>;-)
I can see one use(??) for port knocking, though it's a bit on the dangerous side. You could use it for emergency shutdown in the case that your computer as been compromised and it won't let you in through ssh anymore. The knock sequence would have to be complex enough that the risk of it being triggered by accident is kept at ~0. This suffers from a major security through obscurity problem, though, as intruders would disable the port knocking if this ever became common. (Not that it ever would, of course.)
I actually used something like this on one of my computers a few years ago, but then a single(!) knock was enought to make the computer reboot. I don't recall if I ever had any use for it, and I had to disable it after I told a friend about it. But it was sort of fun, anyway.
I actually used something like this on one of my computers a few years ago, but then a single(!) knock was enought to make the computer reboot. I don't recall if I ever had any use for it, and I had to disable it after I told a friend about it. But it was sort of fun, anyway.
You come across as being a bit confused. Where does your figure of "1/10th the chance of success" come from? How does port knocking reduce the chance of success by 9/10ths - or is that supposed to be just an example figure?
Your choice of words about layers of an onion is interesting. It's true that creating multiple layers of security can still leave a single gaping hole, but the fact that port knocking is a completely seperate measure means this is quite unlikely. If there is some security flaw in OpenSSH, then it's surely better to also have a port-knocking implementation in between your machine and potential attackers...?
Granted, it would be foolish to rely on port knocking as the sole means of protection. It would be foolhardy not to patch your various servers to fix security flaws in the belief that your port knocking would keep you safe, but on the other hand, having up-to-date servers and an otherwise credible security policy *in addition* to port knocking would be a good way to go.
Also I find fault in your "security through obscurity" argument. The mistake is that you are assuming that port knocking is a form of this, but it is not. It doesn't matter if an attacker knows if you are using port knocking techniques - even if you posted this particular fact on your blog - the point is, it's still that little bit harder for an attacker to crack your system.
Your choice of words about layers of an onion is interesting. It's true that creating multiple layers of security can still leave a single gaping hole, but the fact that port knocking is a completely seperate measure means this is quite unlikely. If there is some security flaw in OpenSSH, then it's surely better to also have a port-knocking implementation in between your machine and potential attackers...?
Granted, it would be foolish to rely on port knocking as the sole means of protection. It would be foolhardy not to patch your various servers to fix security flaws in the belief that your port knocking would keep you safe, but on the other hand, having up-to-date servers and an otherwise credible security policy *in addition* to port knocking would be a good way to go.
Also I find fault in your "security through obscurity" argument. The mistake is that you are assuming that port knocking is a form of this, but it is not. It doesn't matter if an attacker knows if you are using port knocking techniques - even if you posted this particular fact on your blog - the point is, it's still that little bit harder for an attacker to crack your system.
The 1/10 figure comes from the sentence before it: "Let's dispose of the stealth argument first. Suppose that port knocking becomes widely used (and surely that's the point of its existence?). Say it is running on 10% of all servers."
Well, yes, 1/10th probability = 10% probability, but there's no logical connection between the figures.
If 10% of all servers are running a port knocking implementation, how does that imply that attacking an arbitrary machine (and assuming that it is in fact running port knocking) has one-tenth probability of the chance of succeeding against a machine known not to be using port knocking - unless you assume that the fact port knocking is being used has absolutely no effect on the probability of the attack being successful?
(And if that were the case, wouldn't the better argument just be that: "port knocking has no effect on the probability of an attack being successful).
Anyway, what sort of idiot attacker would *assume* that the target machine was using port knocking if only 10% machines were using it? You'd have much more success assuming that port knocking *wasn't* beign used...
If 10% of all servers are running a port knocking implementation, how does that imply that attacking an arbitrary machine (and assuming that it is in fact running port knocking) has one-tenth probability of the chance of succeeding against a machine known not to be using port knocking - unless you assume that the fact port knocking is being used has absolutely no effect on the probability of the attack being successful?
(And if that were the case, wouldn't the better argument just be that: "port knocking has no effect on the probability of an attack being successful).
Anyway, what sort of idiot attacker would *assume* that the target machine was using port knocking if only 10% machines were using it? You'd have much more success assuming that port knocking *wasn't* beign used...
Your understanding of probability is deeply flawed, and I would suggest either a course or text on the topic. (If you ever see this again...)
10% probability is based on all servers - ie, not terribly useful for attacking a single server, where it either is on or not, but useful for attacking a large number of random unknown machines. Also, "only 10% [of servers]" is several million machines. A recent attack against BlackICE hit every vulnerable machine, 12,000 in total, in 45 minutes.
In addition, this would not be a solitary attack, except perhaps at first. Like most other highly successful worms/hackers, it would be one part of a broad array of exploits, any one of which could be successful and the tipping point. You don't need to assume that it is used; it's enough to know that it could be used, and work from there. Many hybrid worms, and all competent attackers, have used this theory to great results.
10% probability is based on all servers - ie, not terribly useful for attacking a single server, where it either is on or not, but useful for attacking a large number of random unknown machines. Also, "only 10% [of servers]" is several million machines. A recent attack against BlackICE hit every vulnerable machine, 12,000 in total, in 45 minutes.
In addition, this would not be a solitary attack, except perhaps at first. Like most other highly successful worms/hackers, it would be one part of a broad array of exploits, any one of which could be successful and the tipping point. You don't need to assume that it is used; it's enough to know that it could be used, and work from there. Many hybrid worms, and all competent attackers, have used this theory to great results.
I like the fact that the port knocking implementation is not written in C...
Are you under the impression that the code you found is the implementation, rather than an example? I can see where that would lead to some of your conclusions.
Don't want replay attacks? Encoding the source address in the knock sequence would help. Opening a nonstandard port for connection after a successful knock would be another way to go.
Worried about an exhaustive searching attack (and ignoring the time constraints)? Lock out addresses that complete a knock sequence and fail to immediately connect to the correct port.
Your 10% break-in figure if 10% of servers are using port knocking assumes that all port knocking implementations will be insecure. It also assumes that the cracker is going to be willing to waste the time necessary to attack every address, whether there appears to be a machine located at it or not.
I agree that you don't need to reinvent cryptography. Cryptography is not what port knocking is about. It's about not being the "low hanging fruit", and security in depth.
Reminder: There is nothing wrong with "security through obscurity", it's "security only through obscurity that's a bad idea.
I don't even buy the author's assumption that OpenSSH is insecure. If so, that would be news to me and he should write another essay on why OpenSSH is insecure. His argument that OpenSSH "must frequently be patched", even if I granted his definition of "frequently" (whatever that is), is unconvincing. Any software must be patched occasionally or even frequently. OpenSSH is no different and the necessity of periodically patching software does not, by itself, suffice to deserve calling said software "insecure."
Yes, all software, like qmail and djbdns.
The article is well-written and the author makes a defensible argument. Here are my responses to the other initial responders:
1) "So go on then, write your better solution....."
Maybe he will, or has. However, alerting the public to problems with port knocking is valid regardless of whether or not the author has developed something better.
2) "Where does your figure of "1/10th the chance of success" come from?"
Did you read the article? The author is making an illustration, and started by saying "Say it is running on 10% of all servers." His point is that if port-knocking was to become widespread, attacking it would become part of the arsenal of the attacker, which would eliminate the main benefit of port-knocking (the fact that it is difficult to detect if it is in use). And I think you dismiss the author's 'security through obscurity' argument too quickly -- a little "extra" security may in fact NOT be better if it misleads the user into thinking that it provides more security than it actually does.
3) "Your 10% break-in figure if 10% of servers are using port knocking assumes that all port knocking implementations will be insecure."
No, the author does not assume that. The author assumes that if port knocking becomes widespread, say to the point that 10% of all servers use it, then 10% of the time an attacker will find that his port-knocking attacks were worthwhile. For example, say that a cracker has a port-knocking crack that works 5% of the time. If the cracker applies that crack to every server he wants to compromise, then 10% of the time the crack will be meaningfully used, and 5% of those times it will actually be effective. Therefore,<nobr> <wbr></nobr>.5% of the time the crack will work on a randomly-selected server. This means that the cracker now knows that 1 in 200 servers will be successfully compromised by the port-knocking attack.
Of course, hopefully this is just the first security layer in the compromised server's onion, but the author knows that. The point is that if you can assume that a certain number of servers implement port-knocking, the 'advantage' of being undetectable is largely mitigated.
4) "Reminder: There is nothing wrong with "security through obscurity", it's "security only through obscurity that's a bad idea."
I disagree. Any "security through obscurity" carries with it the risk that the user has an over-inflated view of how secure his server is. For example: burying a needle in a haystack may make someone think that "no one will ever find the needle, how can they even know it is there?" This individual will be easily compromised by the first guy that comes along with a high-powered metal detector.
Is "security through obscurity" better than nothing? In most cases, yes. However, it has a risk associated with it, and users should be cognizant of that risk.
Good article.
1) "So go on then, write your better solution....."
Maybe he will, or has. However, alerting the public to problems with port knocking is valid regardless of whether or not the author has developed something better.
2) "Where does your figure of "1/10th the chance of success" come from?"
Did you read the article? The author is making an illustration, and started by saying "Say it is running on 10% of all servers." His point is that if port-knocking was to become widespread, attacking it would become part of the arsenal of the attacker, which would eliminate the main benefit of port-knocking (the fact that it is difficult to detect if it is in use). And I think you dismiss the author's 'security through obscurity' argument too quickly -- a little "extra" security may in fact NOT be better if it misleads the user into thinking that it provides more security than it actually does.
3) "Your 10% break-in figure if 10% of servers are using port knocking assumes that all port knocking implementations will be insecure."
No, the author does not assume that. The author assumes that if port knocking becomes widespread, say to the point that 10% of all servers use it, then 10% of the time an attacker will find that his port-knocking attacks were worthwhile. For example, say that a cracker has a port-knocking crack that works 5% of the time. If the cracker applies that crack to every server he wants to compromise, then 10% of the time the crack will be meaningfully used, and 5% of those times it will actually be effective. Therefore,<nobr> <wbr></nobr>.5% of the time the crack will work on a randomly-selected server. This means that the cracker now knows that 1 in 200 servers will be successfully compromised by the port-knocking attack.
Of course, hopefully this is just the first security layer in the compromised server's onion, but the author knows that. The point is that if you can assume that a certain number of servers implement port-knocking, the 'advantage' of being undetectable is largely mitigated.
4) "Reminder: There is nothing wrong with "security through obscurity", it's "security only through obscurity that's a bad idea."
I disagree. Any "security through obscurity" carries with it the risk that the user has an over-inflated view of how secure his server is. For example: burying a needle in a haystack may make someone think that "no one will ever find the needle, how can they even know it is there?" This individual will be easily compromised by the first guy that comes along with a high-powered metal detector.
Is "security through obscurity" better than nothing? In most cases, yes. However, it has a risk associated with it, and users should be cognizant of that risk.
Good article.
The point is that if you can assume that a certain number of servers implement port-knocking, the 'advantage' of being undetectable is largely mitigated.
Why? The attacker would need to see your network traffic to be able to make any kind of guess as to the port-knocking sequence, even if you use a fixed one with only handful of knocks. If even a thousand people have seen you knock on your computer, it's a reduction by a factor of a million or so, and the port knocking will have done its job well enough.
I agree with you that one has to be careful with security through obscurity, but it certainly can be used to reduce the number of possible attackers. We buy locks for our doors not because they're impossible to pick (or circumvent), but because they reduce the number of people who could do so, and the chance that they could do so undisturbed.
That said, I can't see myself playing with this 'port knocking'; it's all too likely to get stuck in firewalls or just be too hard to activate from someone else's computer.
> The attacker would need to see your network traffic
I don't think it is valid to make that assumption -- a successful port-knock attack could rely on brute force or buffer-overflow and not on snooping. For example, The author said that a poor port-knock implementation could result in an 8-knock sequence against a list of only 32 'knockable' ports, which would be equivalent to a 40-bit key. This scenario could theoretically be successfully attacked by brute force (using an automated tool trying every possible combination until the correct sequence is found).
Similarly, a buffer-overflow attack could exploit a flaw in the port-knock implementation. What if the service listening for port-knocks experiences a buffer overflow if 40 knocks occur on a single port in a 3 second period? This kind of failure could lead to denial-of-service atttacks (at best) or could be combined with other exploits to compromise the server (at worst).
Obviously, neither of those examples requires any knowledge of the user's port sequence whatsoever.
I'm not saying (and neither is the author) that port knocking is worthless or easily compromised, but it isn't as secure as it might first appear to those that aren't aware of security architectures and the strategies employed to attack them. The author is pointing out that the 'stealth' aspect advertised as a key feature of port knocking is not the magic bullet it is made out to be, and that using a simple service (port connectivity) in a non-standard way (port-knocking) may result in non-obvious security flaws.
I'm inclined just to stick with SSH also.<nobr> <wbr></nobr>:^]
I don't think it is valid to make that assumption -- a successful port-knock attack could rely on brute force or buffer-overflow and not on snooping. For example, The author said that a poor port-knock implementation could result in an 8-knock sequence against a list of only 32 'knockable' ports, which would be equivalent to a 40-bit key. This scenario could theoretically be successfully attacked by brute force (using an automated tool trying every possible combination until the correct sequence is found).
Similarly, a buffer-overflow attack could exploit a flaw in the port-knock implementation. What if the service listening for port-knocks experiences a buffer overflow if 40 knocks occur on a single port in a 3 second period? This kind of failure could lead to denial-of-service atttacks (at best) or could be combined with other exploits to compromise the server (at worst).
Obviously, neither of those examples requires any knowledge of the user's port sequence whatsoever.
I'm not saying (and neither is the author) that port knocking is worthless or easily compromised, but it isn't as secure as it might first appear to those that aren't aware of security architectures and the strategies employed to attack them. The author is pointing out that the 'stealth' aspect advertised as a key feature of port knocking is not the magic bullet it is made out to be, and that using a simple service (port connectivity) in a non-standard way (port-knocking) may result in non-obvious security flaws.
I'm inclined just to stick with SSH also.<nobr> <wbr></nobr>:^]
The author was mistaken about the effective key-length.
It may well be that only 32 ports are configured as knockable on a given system, but that has no effect on how many ports are available to guess, it just means that a knock on any other port is meaningless. No more information is gained by knocking on a knockable port than is gained by knocking on an unknockable port, so any given port (barring another service actively running on it) is just as likely as any other port.
Even if you know that I'm using a port knocking implementation that only allows 32 ports to be configured to knock, how are you going to know what ports they are?
I could be using ports 1-32 or odd ports from 1001 to 1063, or 32 ports that I chose by rolling really big dice. Heck, if I have an 8-port knock sequence, tecnically I'm only *using* 8 ports. That doesn't tell you *which* ports, though.
The author assumed that just because I can only pick 32 ports that they have to be the same 32 ports everyone else uses. If the attacker can figure out which ports I'm allowing knocks on, I've got other problems than the fact that only 32 ports watch for knocks.
How would a 40-bit passcode to gain access to SSH possibly be worse than a 0-bit passcode to gain access to SSH? If one of my users uses the password '48205728' does that mean that my security system has a 10,000,000
Now, if the spec requires 32 particular ports, then the author is right about the strength, but that's not the impression I got from reading that it could be configured with up to 256 ports.
Want fun & games? How about this? One wrong knock, and the attacker gets a false positive that sets him lose on a 1bps connection to a honeypot system that's not connected to the rest of the network.
It may well be that only 32 ports are configured as knockable on a given system, but that has no effect on how many ports are available to guess, it just means that a knock on any other port is meaningless. No more information is gained by knocking on a knockable port than is gained by knocking on an unknockable port, so any given port (barring another service actively running on it) is just as likely as any other port.
Even if you know that I'm using a port knocking implementation that only allows 32 ports to be configured to knock, how are you going to know what ports they are?
I could be using ports 1-32 or odd ports from 1001 to 1063, or 32 ports that I chose by rolling really big dice. Heck, if I have an 8-port knock sequence, tecnically I'm only *using* 8 ports. That doesn't tell you *which* ports, though.
The author assumed that just because I can only pick 32 ports that they have to be the same 32 ports everyone else uses. If the attacker can figure out which ports I'm allowing knocks on, I've got other problems than the fact that only 32 ports watch for knocks.
How would a 40-bit passcode to gain access to SSH possibly be worse than a 0-bit passcode to gain access to SSH? If one of my users uses the password '48205728' does that mean that my security system has a 10,000,000
Now, if the spec requires 32 particular ports, then the author is right about the strength, but that's not the impression I got from reading that it could be configured with up to 256 ports.
Want fun & games? How about this? One wrong knock, and the attacker gets a false positive that sets him lose on a 1bps connection to a honeypot system that's not connected to the rest of the network.
cool, then have the firewall pull all the information it can about the IP that the hacker is attacking from, (who owns it-reverse DNS, admin contact info-whois, etc.) and e-mail the info to the admin -- while the attacker is still trying to get into the honeypot.
better yet, have it ssh it over to another server on another network, and have that server send the e-mail, so that if the hacker is actually watching the packets, what goes by telling on him will be encrypted and not plain text.
One objection was that the thing could be replayed. Why not encode a timestamp into the knock. Heck, why not use UDP packets as the author suggested, and load those packets with hashed data that includes time-stamps and other information that must match the servers time(a skewed clock on your client machine just might keep you out). The packet still gets rejected, but the contents are read and logged, and if the contents aren't correct (eg. wrong user or wrong timestamps) then this thing just doesn't open up.
better yet, have it ssh it over to another server on another network, and have that server send the e-mail, so that if the hacker is actually watching the packets, what goes by telling on him will be encrypted and not plain text.
One objection was that the thing could be replayed. Why not encode a timestamp into the knock. Heck, why not use UDP packets as the author suggested, and load those packets with hashed data that includes time-stamps and other information that must match the servers time(a skewed clock on your client machine just might keep you out). The packet still gets rejected, but the contents are read and logged, and if the contents aren't correct (eg. wrong user or wrong timestamps) then this thing just doesn't open up.
I don't know the author, so I don't know why I'm taking such lengths to defend him (her?), but here goes:
> The author was mistaken about the effective key-length.
It looks that way, but the author may have really been talking about the implementor of the port-knocking service improperly limiting the ports that can be used, not the end-user. His subsequent quote would support that interpretation:
"Granted, this is a problem for the implementer and not for the end user, and the current (proof-of-concept) implementation appears to take care of the length issue."
So, I don't know. He could have gotten it wrong, or he could have worded the sentence poorly, and failed to clearly communicate that he was talking about the service implementor and not the service configurer (the end-user). I'm inclined to believe the latter because I don't think the author could have the obvious grasp of all these issues yet make such a simple mistake.
> The author was mistaken about the effective key-length.
It looks that way, but the author may have really been talking about the implementor of the port-knocking service improperly limiting the ports that can be used, not the end-user. His subsequent quote would support that interpretation:
"Granted, this is a problem for the implementer and not for the end user, and the current (proof-of-concept) implementation appears to take care of the length issue."
So, I don't know. He could have gotten it wrong, or he could have worded the sentence poorly, and failed to clearly communicate that he was talking about the service implementor and not the service configurer (the end-user). I'm inclined to believe the latter because I don't think the author could have the obvious grasp of all these issues yet make such a simple mistake.
"His point is that if port-knocking was to become widespread, attacking it would become part of the arsenal of the attacker, which would eliminate the main benefit of port-knocking (the fact that it is difficult to detect if it is in use). "
The difficult part of detection of port knocking is not _whether_ port-knocking is in use, but on which ports it is in use. A standard scan of a port-knocked server will _never_ reveal which ports are being listened to for knocking. You are essentially requiring a cleartext passphrase before even telling someone that they need a passphrase. It's an onion - an additional layer. If you relied on portknocking for security, you're stupid - it's a plaintext password. However, port-knocking does restrict the amount of information others have about you, which makes you less of a target. It's like running LinuxPPC - it doesn't make you secure, but the likelihood of a random hacker breaking in is very small. Just by using it you have decreased your hackability a certain percentage.
The difficult part of detection of port knocking is not _whether_ port-knocking is in use, but on which ports it is in use. A standard scan of a port-knocked server will _never_ reveal which ports are being listened to for knocking. You are essentially requiring a cleartext passphrase before even telling someone that they need a passphrase. It's an onion - an additional layer. If you relied on portknocking for security, you're stupid - it's a plaintext password. However, port-knocking does restrict the amount of information others have about you, which makes you less of a target. It's like running LinuxPPC - it doesn't make you secure, but the likelihood of a random hacker breaking in is very small. Just by using it you have decreased your hackability a certain percentage.
> The difficult part of detection of port knocking is not _whether_ port-knocking is in use, but on which ports it is in use.
That may be the difficult part, but it may be useful to attackers to just be able to determine _whether_ port-knocking is in use (or to just assume it). For instance, a denial-of-service attack might be discovered for a port-knocking implementation, and may only require knowledge of port-knocking's existence. Or, once a server is determined to be using port-knocking, a replay attack could be employed. Therefore, if the use of port-knocking becomes widespread, an attacker will just assume that port-knocking is in use on unresponsive servers and initiate port-knocking attacks.
I think it is reasonable to object is my stating that "difficult detection is the main benefit of port-knocking". That probably isn't true. A better statement would be "difficult detection is the most intriguing benefit of port-knocking."
Everyone agrees that port-knocking is additional security. But, the fact that it is difficult to detect if it is or isn't being used does not significantly add to the level of security. In addition, a "successful attack" is broader than just determining the knock sequence; successful attacks would also include denial-of-service.
That may be the difficult part, but it may be useful to attackers to just be able to determine _whether_ port-knocking is in use (or to just assume it). For instance, a denial-of-service attack might be discovered for a port-knocking implementation, and may only require knowledge of port-knocking's existence. Or, once a server is determined to be using port-knocking, a replay attack could be employed. Therefore, if the use of port-knocking becomes widespread, an attacker will just assume that port-knocking is in use on unresponsive servers and initiate port-knocking attacks.
I think it is reasonable to object is my stating that "difficult detection is the main benefit of port-knocking". That probably isn't true. A better statement would be "difficult detection is the most intriguing benefit of port-knocking."
Everyone agrees that port-knocking is additional security. But, the fact that it is difficult to detect if it is or isn't being used does not significantly add to the level of security. In addition, a "successful attack" is broader than just determining the knock sequence; successful attacks would also include denial-of-service.
For 3).
Yes, I did read the article.
"...Then an attacker simply assumes that the target machine is using port knocking and proceeds to attack it. The attack succeeds with a probability of one in 10 (of what it would have been if stealth were not employed)"<nobr> <wbr></nobr>... implying that using port knocking reduces the chance of succsesful attack by 9/10ths.
How are the "one in 10" and "10%" supposed to be related? (yes, I'm aware that they are an equal probability - but they are used in two different, non-interdependent contexts).
It's like saying: "if X% of machines use port knocking, then if you try to crack such a machine, your chance of success will be reduced to X% of what it was."
Following that through to its logical conclusion: "if 100% of machines using port knocking, and you try to crack such a machine, your chance of success will be 100% of what it was (if nobody was using port knocking) - that is, if everybody used port knocking, it would have absolutely no effect on the probability of an attack being successful".
How do you figure that?
Yes, I did read the article.
"...Then an attacker simply assumes that the target machine is using port knocking and proceeds to attack it. The attack succeeds with a probability of one in 10 (of what it would have been if stealth were not employed)"<nobr> <wbr></nobr>... implying that using port knocking reduces the chance of succsesful attack by 9/10ths.
How are the "one in 10" and "10%" supposed to be related? (yes, I'm aware that they are an equal probability - but they are used in two different, non-interdependent contexts).
It's like saying: "if X% of machines use port knocking, then if you try to crack such a machine, your chance of success will be reduced to X% of what it was."
Following that through to its logical conclusion: "if 100% of machines using port knocking, and you try to crack such a machine, your chance of success will be 100% of what it was (if nobody was using port knocking) - that is, if everybody used port knocking, it would have absolutely no effect on the probability of an attack being successful".
How do you figure that?
I don't know quite how to explain it further<nobr> <wbr></nobr>... perhaps you are confusing "successful attack on port-knocking layer" with "successful total compromise of system."
No one is saying that port-knock cracking is easy, or that once you have cracked the port-knocking on a server that you are all the way in. All that is being said is this: there is some percentage that represents how effective a particular port-knock crack will be. If that percentage is 10%, then all it means is that 10% of the time the attacker will be able to get past port-knocking (and then presumably will begin work on cracking the next layer of the onion).
Now, if 50% of all the servers that the cracker wants to break into use port-knocking, then for any randomly selected server in that group the attacker will have a 5% chance that the port-knock crack will work. The other 95% of the time the port-knock crack didn't work, either because the server wasn't using port-knocking, or because the server was using it but the crack wasn't effective.
No one is saying that port-knock cracking is easy, or that once you have cracked the port-knocking on a server that you are all the way in. All that is being said is this: there is some percentage that represents how effective a particular port-knock crack will be. If that percentage is 10%, then all it means is that 10% of the time the attacker will be able to get past port-knocking (and then presumably will begin work on cracking the next layer of the onion).
Now, if 50% of all the servers that the cracker wants to break into use port-knocking, then for any randomly selected server in that group the attacker will have a 5% chance that the port-knock crack will work. The other 95% of the time the port-knock crack didn't work, either because the server wasn't using port-knocking, or because the server was using it but the crack wasn't effective.
> a 5% chance that the port-knock crack will work
Excuse me, but how does the cracker even know that it has worked with any particular sequence ?
It is trivial to implement a mechanism that avoids port-knocking cracks, just add a time delay. The server watches for port knocking. Once a particular sequence is seen from a specific address it waits, say, 15 seconds and then opens, say, port 22 for that address. If any other port is knocked by that address in that time then port 22 is not opened.
We have now made it such that a 'brute force' attack has zero change of success unless it delays for some number of seconds between combinations. If it does delay then it can only try several thousand combinations per day. The chances of success then being insignifgicant, even if they knew which ports were valid port knocks, even if they knew port knocking was being used. Change the knock sequence on a daily basis using some calculation including date and the chance of success is effectively zero. And this is totally independent of whether other machines implement port knocking or not.
Excuse me, but how does the cracker even know that it has worked with any particular sequence ?
It is trivial to implement a mechanism that avoids port-knocking cracks, just add a time delay. The server watches for port knocking. Once a particular sequence is seen from a specific address it waits, say, 15 seconds and then opens, say, port 22 for that address. If any other port is knocked by that address in that time then port 22 is not opened.
We have now made it such that a 'brute force' attack has zero change of success unless it delays for some number of seconds between combinations. If it does delay then it can only try several thousand combinations per day. The chances of success then being insignifgicant, even if they knew which ports were valid port knocks, even if they knew port knocking was being used. Change the knock sequence on a daily basis using some calculation including date and the chance of success is effectively zero. And this is totally independent of whether other machines implement port knocking or not.
The author of the article was surely talking about a "successful total compromise of system." It's not me who is confusing the two. I'm not basing this on some half-baked notion, but on the actual sentences used in the article.
As a justifying quote:
"those odds are worthwhile to the attacker, considering that the cost of the attack is far smaller than the expected gains from a successful attack"
Also, immediately following that:
"This kind of technique is quite common in port scanning -- crackers use multiple automated methods, each of which has only a small probability of success, but which taken together prove very effective."
What the author is implying here is that, If you successfully attack the port knocking layer, you *have* compromised the whole system.
If I'm wrong about this, then it's the fault of the phrasing being employed - which makes the intended meaning unclear (and, I would argue, incorrect).
As a justifying quote:
"those odds are worthwhile to the attacker, considering that the cost of the attack is far smaller than the expected gains from a successful attack"
Also, immediately following that:
"This kind of technique is quite common in port scanning -- crackers use multiple automated methods, each of which has only a small probability of success, but which taken together prove very effective."
What the author is implying here is that, If you successfully attack the port knocking layer, you *have* compromised the whole system.
If I'm wrong about this, then it's the fault of the phrasing being employed - which makes the intended meaning unclear (and, I would argue, incorrect).
I think the article is too subjective. Port Knocking is a nice idea, and if properly implemented it could improve security. 'Security plus obscurity' is better than security alone.
Firstly, the unnecessary only-some-ports-valid "protection layer" complicates things. Suppose you decide on a list of 32 valid ports (the current implementation allows up to 256). How long does the port knock sequence need to be? You might think that since each port is a 16-bit integer, you need 8 knocks, so that you get 8*16 bits or 128 bits of security (virtually unbreakable). But since each port has only 32 possible values (5 bits), what you actually get is only 8*5=40 bits of security (trivially breakable)!
Here the author assumes that the choice of which 32 ports will be apparent.
If I choose to use a$a$a$a$ as a password does that give my system 16-bit security? (After all, I only used 2 values, which can be reduced to 2 bit-states if you know which two values I used.) The answer? No my system still has 92^8-bit security. (It may be that I've chosen a weak password, but that's another discussion entirely.)
If I happen to choose ports 1-32, with an 8-knock sequence, yeah I'll probably get brute forced a bit faster than someone who uses a randomly generated set of 32 ports, but only because his ports are likely to be distributed througout the entire range, requiring the brute-force app to go through more iterations.
The idea with port-knocking is that you don't get *any* feedback until you've knocked the entire sequence correctly. The attacker has no way to know which ports are the 32 valid ports you've chosen, therefore he must treat them all equally.
If the attacker discovers that you're using 32 particular ports, then yes your security is weakened. Just like if he found out I was using a password that only had 2 different characters in it. That's why key-related information is kept *secret*. (Hiding information about your key isn't 'security through obscurity', it's the basis of security.)
Having a bug in a port-knock service that allows access is still better than having httpd, ssh, sendmail, and ftp (each of which might have such a bug) plainly accessible when you don't want need it. Barring such a bug in port-knock, an attacker at least has to authenticate to your system before they can try hacking another service.
Yeah,
As far as I am concerned this article is a joke. Port knocking is not meant to be the sole layer of security, but it can provide a nice cushion if you are on vacation while the latest exploit for X service is found and can't update your boxes.
I will cede to the authors opinion that port knocking is insecure IF the standard port for whatever service is used IF the attacker knows that port knocking is being used IF he knows the length of the knock nessecary IF he knows the available ports that knocks may be recieved on IF he can sniff your traffic/cares enough to.
But lets be serious.
If someone is that dedicated to cracking your security and are comptent the chances are they will. The basic premise behind port knocking (as I understand it)is not that it is secure, it simply makes you less of an attractive target to the 1337 skript kiddies. That being said, what's the point of this article? Don't use port knocking and then not bother to secure your services? OK, sure.
--Kevin S.
leviticus [at] (Google's totally awesome mail service).com
As far as I am concerned this article is a joke. Port knocking is not meant to be the sole layer of security, but it can provide a nice cushion if you are on vacation while the latest exploit for X service is found and can't update your boxes.
I will cede to the authors opinion that port knocking is insecure IF the standard port for whatever service is used IF the attacker knows that port knocking is being used IF he knows the length of the knock nessecary IF he knows the available ports that knocks may be recieved on IF he can sniff your traffic/cares enough to.
But lets be serious.
If someone is that dedicated to cracking your security and are comptent the chances are they will. The basic premise behind port knocking (as I understand it)is not that it is secure, it simply makes you less of an attractive target to the 1337 skript kiddies. That being said, what's the point of this article? Don't use port knocking and then not bother to secure your services? OK, sure.
--Kevin S.
leviticus [at] (Google's totally awesome mail service).com
Just my $0.02
The author says:
1) "The obvious question then is, in what way is this convoluted and inefficient method of sending a passphrase across a network better than the straightforward method of putting it in a packet and sending it? The obvious answer is, it is not. (The second obvious question is, how is it different from authenticating yourself with a passphrase using SSH? But we'll get to that shortly.)"
The whole idea behind port knocking is to deter common tools / scripts and script kiddies. It also makes it much more difficult for even more serious intruders. If port knocking succeeds in eliminating just script kiddies and no one else, then I think that it's worth the time.
2) "OpenSSH, which is the SSH server on the majority of Linux installations, suffers from regular exploits of buffer overflow and other vulnerabilities, and you neither have the time to keep up with the patches nor want to make the effort -- you'd rather put up with not being able to access your files. This is where port knocking might seem to help -- but don't count on it." Even if what you say is correct (which I can easily disagree with), you can always use something like Libsafe to block the majority of buffer overflow attacks. Using Libsafe means that your application doesn't even need constant patching, even if it's vulnerable.
3) "Secondly, there's the matter of what you're going to do about replay attacks. A replay attack is one where a router sitting between the client and the server passively sniffs what the client is sending, and sends the same bitstream after a while to the server, pretending to be the client. " This can be countered by changing the sequence after each connection. Of course, it would be ridiculous to have the user handle this, so after each successful connection, a random port sequence can be generated by the server and transmitted to the client application. Upon recieving confirmation from the client that the new sequence has reached the client, the server would then modify its behavior to allow only port knocks matching the new sequence. Some wrapper is probably all you'd need.
The author says:
1) "The obvious question then is, in what way is this convoluted and inefficient method of sending a passphrase across a network better than the straightforward method of putting it in a packet and sending it? The obvious answer is, it is not. (The second obvious question is, how is it different from authenticating yourself with a passphrase using SSH? But we'll get to that shortly.)"
The whole idea behind port knocking is to deter common tools / scripts and script kiddies. It also makes it much more difficult for even more serious intruders. If port knocking succeeds in eliminating just script kiddies and no one else, then I think that it's worth the time.
2) "OpenSSH, which is the SSH server on the majority of Linux installations, suffers from regular exploits of buffer overflow and other vulnerabilities, and you neither have the time to keep up with the patches nor want to make the effort -- you'd rather put up with not being able to access your files. This is where port knocking might seem to help -- but don't count on it." Even if what you say is correct (which I can easily disagree with), you can always use something like Libsafe to block the majority of buffer overflow attacks. Using Libsafe means that your application doesn't even need constant patching, even if it's vulnerable.
3) "Secondly, there's the matter of what you're going to do about replay attacks. A replay attack is one where a router sitting between the client and the server passively sniffs what the client is sending, and sends the same bitstream after a while to the server, pretending to be the client. " This can be countered by changing the sequence after each connection. Of course, it would be ridiculous to have the user handle this, so after each successful connection, a random port sequence can be generated by the server and transmitted to the client application. Upon recieving confirmation from the client that the new sequence has reached the client, the server would then modify its behavior to allow only port knocks matching the new sequence. Some wrapper is probably all you'd need.
I thought that the main point of port knocking is
to not reveal whether the machine is switched on,
in which case you don't want to send out an
ICMP_PORT_UNREACH message.
Is it easy to write a script that receives UDP
packets without revealing whether the machine is
there or not? If it is, then that sounds like a
better solution that port knocking.
Ideally you wouldn't just open the port when the
secret signal is received, as you might get
randomly port-scanned at just that moment.
to not reveal whether the machine is switched on,
in which case you don't want to send out an
ICMP_PORT_UNREACH message.
Is it easy to write a script that receives UDP
packets without revealing whether the machine is
there or not? If it is, then that sounds like a
better solution that port knocking.
Ideally you wouldn't just open the port when the
secret signal is received, as you might get
randomly port-scanned at just that moment.
>I thought that the main point of port knocking is
to not reveal whether the machine is switched on
That's impossible.
As I detailed in another post, you can't do port knocking with UDP, because you have no guarantee that the server will receive the same sequence of packets you are sending.
On the other way, establishing a TCP connection requires that source and destination "shake hands" -- that is, destination must respond to you before you can even start sending data.
to not reveal whether the machine is switched on
That's impossible.
As I detailed in another post, you can't do port knocking with UDP, because you have no guarantee that the server will receive the same sequence of packets you are sending.
On the other way, establishing a TCP connection requires that source and destination "shake hands" -- that is, destination must respond to you before you can even start sending data.
Port knocking is using uncompleted connections to transmit information. The client has no idea if the server got the SYN packet or not. The server is blocking the packet and isn't going to tell them either way. If it gets dropped somewhere between the two computers neither will ever know.
So UDP is no different, and it allows sending more information more reliably. Either the whole thing arrives or the whole thing is lost. That way the client can retry is the port doesn't open. With port knocking you wouldn't know which port was dropped and the server would then be out of sync with the client.
So UDP is no different, and it allows sending more information more reliably. Either the whole thing arrives or the whole thing is lost. That way the client can retry is the port doesn't open. With port knocking you wouldn't know which port was dropped and the server would then be out of sync with the client.
Why do a google search for on CERT's web pages when you can directly search their <A HREF="http://www.kb.cert.org/vuls/" title="cert.org">Vulnerabilty Notes database</a cert.org> directly?
That gives a vastly different picture than the seemingly unending results from google. I have suspicion that googling also counts pages that include "OpenSSH: Not Vulnerable" in the body.
Using CERT's database, I count a grand total of 13 entries that deal directly with an OpenSSH vulnerability. Here they are, sorted by
date:
<TT>VU# 40327 06/09/2000 OpenSSH UseLogin option allows remote execution
of commands as root
VU#363181 12/07/2000 OpenSSH disregards client configuration and
allows server access to ssh-agent and/or X11 after session negotiation
VU#797027 06/19/2001 OpenSSH does not initialize PAM session thereby
allowing PAM restrictions to be bypassed
VU#905795 09/27/2001 OpenSSH fails to properly apply source IP based
access control restrictions
VU#655259 06/12/2001 OpenSSH allows arbitrary file deletion via
symlink redirection of temporary file
VU#945216 02/08/2001 SSH CRC32 attack detection code contains remote
integer overflow
VU#157447 12/04/2001 OpenSSH UseLogin directive permits privilege
escalation
VU#408419 03/07/2002 OpenSSH contains a one-off overflow of an array
in the channel handling code
VU#369347 06/24/2002 OpenSSH vulnerabilities in challenge response
handling
VU#978316 06/04/2003 Vulnerability in OpenSSH daemon (sshd)
VU#333628 09/16/2003 OpenSSH contains buffer management errors
VU#209807 09/23/2003 Portable OpenSSH server PAM conversion stack
corruption
VU#602204 09/23/2003 OpenSSH PAM challenge authentication failure</TT>
Odd, it's almost been an entire year since OpenSSH had a CERT vulnerability warning. And seems to contradict your assertion that OpenSSH is a leaky raft.
I certainly would like to read Theo's reaction to this article...
1) Even if 10% of hosts used port knocking, you would need to attack all hosts on the internet, have a 100% effective method of identifying a host using port-knocking, and a 100% effective method of defeating port-knocking, to have a 10% effectiveness on average of "compromising" an arbitrary machine.
2) Even then this "compromise" accomplishes very little. Using your example, i.e assuming that you knew beforehand what service port-knocking controlled (SSH), and you knew which port would be opened for the service (port 22), you now still need to attack SSH.
As an aside, the assumption that the port-knock sequences have a one to one match to ports is invalid. How about squences that encode which port and which service ?
This article as various other weak points, but a note on "security through obscurity".
Obscurity is not bad, security only through obscurity is undesirable, because it is not provably secure.
Analogy -
Best: Locked door that is hidden.
Worser: Locked door that is not hidden.
Worser still: Unlocked door that is hidden.
Worser still: Unlocked door that is not hidden.
2) Even then this "compromise" accomplishes very little. Using your example, i.e assuming that you knew beforehand what service port-knocking controlled (SSH), and you knew which port would be opened for the service (port 22), you now still need to attack SSH.
As an aside, the assumption that the port-knock sequences have a one to one match to ports is invalid. How about squences that encode which port and which service ?
This article as various other weak points, but a note on "security through obscurity".
Obscurity is not bad, security only through obscurity is undesirable, because it is not provably secure.
Analogy -
Best: Locked door that is hidden.
Worser: Locked door that is not hidden.
Worser still: Unlocked door that is hidden.
Worser still: Unlocked door that is not hidden.
He critisises the idea because of an implementation he has found. When done properly, port knocking can add an extra layer of security and significantly improve the overall security of certain systems (the DSL connected private PC). A good implementation is e. g. Doorman <A HREF="http://doorman.sourceforge.net/" title="sourceforge.net">http://doorman.sourceforge.net/</a sourceforge.net> and I can only recommend it to protect your PC. Of course, having it disconnected, locked in a vault is still more secure than using port knocking.
Port knocking by UDP can't work. Either the author doesn't understand TCP/IP at all, or he didn't really think about it.
UDP is *not* a reliable communication protocol. Packets can get lost or be delivered in a different order than they were sent. If the server must receive the exact same data that you are sending (in this case, the exact same sequence of knocks), you *must* use TCP. That's exactly what it's been designed for.
UDP is *not* a reliable communication protocol. Packets can get lost or be delivered in a different order than they were sent. If the server must receive the exact same data that you are sending (in this case, the exact same sequence of knocks), you *must* use TCP. That's exactly what it's been designed for.
How is it different from raw IP traffic? Sorry, but please reiterate over TCP/IP yourself
Knock twice<nobr> <wbr></nobr>:)
I don"t think you understand how TCP/IP works either. UDP requires applacation work to assure that lost or re-ordered packets are worked around. I believe, if you read the article, the author was suggesting a UDP based pre-authentacation deamon that listens on a UDP port for a "key" and then opens other ports, while still generating a ICMP_PORT_UNREACHABLE packet.
A good design goal of any security technique is that it fails CLOSED. When packet loss is becomes an issure, interactive use of across the networks is mostly usuless anyway.
A good design goal of any security technique is that it fails CLOSED. When packet loss is becomes an issure, interactive use of across the networks is mostly usuless anyway.
I think you (as many other people) are confused about the meaning of "bits" in security. To say that 40 bits of security is "trivially breakable" is as incorrect as saying that "128 bits of security is virtually unbreakable": this is valid only in the context of symetric ciphers attacked by brute force (for example, a 128 bits RSA public key is trivially breakable), and you can not reduce any measure to a number of bits.
To say that 40 bits (for a symetric cipher) is trivially breakable means that it is computationaly possible to try all possible keys (or rather, in average, half of them) in a "reasonable" time. With port-knocking, each attempt is done over the network with a much, much higher latency than having your CPU try a key -- how long would it take to test each 2^39 (in average) combination over a network ? The exact number is left as an exercice to the reader depending on his assumptions, but it is definitively not what I would call "trivial" (assuming 1000 attempts per second, I get an average of 17 years).
This, of course, does not mean that the rest of your article is bad.
Zorglub
To say that 40 bits (for a symetric cipher) is trivially breakable means that it is computationaly possible to try all possible keys (or rather, in average, half of them) in a "reasonable" time. With port-knocking, each attempt is done over the network with a much, much higher latency than having your CPU try a key -- how long would it take to test each 2^39 (in average) combination over a network ? The exact number is left as an exercice to the reader depending on his assumptions, but it is definitively not what I would call "trivial" (assuming 1000 attempts per second, I get an average of 17 years).
This, of course, does not mean that the rest of your article is bad.
Zorglub
Forget calculating the time for a brute force. Just look at the traffic volume:
An empty TCP packet is 40 bytes. I need 8 of those to try one key -> 360 bytes/key. Testing the 2^39 combinations takes thus 180 Terabyte.
The actual number might be less as one can use overlapping keys for efficiency, but there is still an lower bound on one 40 Bytes/key, meaning 20 TB for a 50% chance.
That DoS would worry me a lot more than the chance of hitting my knock key.<nobr> <wbr></nobr>/ol
An empty TCP packet is 40 bytes. I need 8 of those to try one key -> 360 bytes/key. Testing the 2^39 combinations takes thus 180 Terabyte.
The actual number might be less as one can use overlapping keys for efficiency, but there is still an lower bound on one 40 Bytes/key, meaning 20 TB for a 50% chance.
That DoS would worry me a lot more than the chance of hitting my knock key.<nobr> <wbr></nobr>/ol
As the multitude of negative comments indicate, this author is so uninformed that he should be embarassed to have his name on this. And NewsForge should be ashamed at giving a podium to such content - it drags down them and the good articles by other authors on the site.
On the contrary. I'm sure NewsForge is thrilled to have so many negative responses to this author's articles. As the success of Slashdot indicates, sites like these thrive on flamewars. It doesn't matter if the content is accurate or well informed, as long as it gets responses and gets readers interested and involved. Flamebait is the easiest way of achieving this.
So don't expect NewsForge to retract the article or issue and apology. If anything, exect a followup article from the author or others like him attacking some sacred cow.
BTW: Judging the quality of an article by the number of negative responses it gets is ridiculous.
So don't expect NewsForge to retract the article or issue and apology. If anything, exect a followup article from the author or others like him attacking some sacred cow.
BTW: Judging the quality of an article by the number of negative responses it gets is ridiculous.
Of course, the real value of port knocking is in hiding open ports from port scanners. An attacker would have to increase his efforts by an order of magnitude in order to succeed.
An anonymous reader says:
Thank-you. I was losing hope reading all of these posts.
The real point to port knocking is to escape from the myriad of evil scans. Why would any sane person stand up in the field of battle, when you can lie down in a trench.
Of course moving to a non-standard port also achieves this, but port knocking even avoids a targetted scan of your entire portspace.
Is this security? No. This is just improving your odds.
Of course, the real value of port knocking is in hiding open ports from port scanners.
Thank-you. I was losing hope reading all of these posts.
The real point to port knocking is to escape from the myriad of evil scans. Why would any sane person stand up in the field of battle, when you can lie down in a trench.
Of course moving to a non-standard port also achieves this, but port knocking even avoids a targetted scan of your entire portspace.
Is this security? No. This is just improving your odds.
The problem with UDP authentication is you can't send a custom UDP packet from a web terminal. On the other hand, you can easily create TCP request packets...
The point the author seems to have difficulty presenting clearly is that a determined attacker that wants to specifically break into YOUR system will find no obstructions presented by port knocking that can't be overcome.
But the point he is deliberately missing is that port knocking is an added, effective defense against being randomly targeted by worms, hackers and/or automated scripts. It does add a certain level of security, since so many attacks come from that route.
Both points are valid, and both points have their place. I personally think that since port knocking adds "some" value, that it's worth the effort.
* "The bear problem" is when you're hiking in the woods and start getting chased by a bear, you don't have to be able to outrun the bear. You just have to be able to outrun at least one of the guys you're with. The moral is if you make yourself a more difficult target, the attackers will move on to easier pickings.
Why not just have the server and client share a secret? They both could generate the secret off some shared password. After each successful login, the port sequence used in port knocking is then changed randomly with the initial hash of the password.
The client would then use the new sequence on the next login attempt, and the server would only accept connections using this sequence. Sniffing the traffic would be useless unless you try to do some brute force attack on the password and try comparing results with the traffic (so then change your password each month).
The client would then use the new sequence on the next login attempt, and the server would only accept connections using this sequence. Sniffing the traffic would be useless unless you try to do some brute force attack on the password and try comparing results with the traffic (so then change your password each month).
Many of the limitations of port knocking are addressed by <a href="http://www.cipherdyne.org/fwknop/docs/SPA.html">Single Packet Authorization</a>. Check out the <a href="http://www.cipherdyne.org/fwknop/">fwknop</a> implementation of SPA.
Riiiiiight....
Posted by: Anonymous Coward on August 10, 2004 06:03 PMWe'll be waiting.<nobr> <wbr></nobr>:)
#