Slashdot Mirror
"Port Knocking" For Added Security
Jeff writes "The process of Port Knocking is a way to allow only people who know the "secret knock" access to a certain port on a system. For example, if I wanted to connect via SSH to a server, I could build a backdoor on the server that does not directly listen on port 22 (or any port for that matter) until it detects connection attempts to closed ports 1026,1027,1029,1034,1026,1044 and 1035 in that sequence within 5 seconds, then listens on port 22 for a connection within 10 seconds.
The web site explains it in some detail, and there is even an experimental perl implementation of it that is available for download. I can't think of any easy ways you could get around a system using this security method - let alone even know that a system is implementing it.
Another article on port knocking is here."
Something tells me I'm going to be seeing a lot bigger firewall logs in the future, as this catches on.
But it does seem like a layer of obscurity to what should otherwise be a secure port. What if someone is sniffing your network? Unlike an encrypted password, they could easily replay this sequence and gain access to your "hidden" port.
The more you know, the less you understand.
I can't think of any easy ways you could get around a system using this security method - let alone even know that a system is implimenting it.
Sniffing.
An analogy would be a military base with a ten-foot-thick steel blast door. This is like having a door that teleports around at random, which can only be frozen in one spot by speaking some magic word. Even if you know the word, you still don't have the key to the door. But if you do have the key, you still can't get in without the magic word because the door keeps teleporting around.
Obscurity is great, if it is part of a layered security policy which is ultimately based on strong cryptography. This is a really cool idea!
There is an easy way around it. The problem is you will make yourself very obvious. Simply pick a time at which the server in question is in high use. Hammer the port. Eventually someone will knock on the door opening it for 10 seconds and you put your foot in the door before they do. The other way is if you can get a packet sniffer simply look at the packets that came before and determine the secret knock.
This is still an interesting idea and definitely has at least a few places in which it would be an effective authentication mechanism.
The GeekNights podcast is going strong. Listen!
Except it hides that the port is open at all, which is useful.
"The "knocking ports" could also be configured that if there are random hits to the standard port without the proper knock, the system could lock down for 30 seconds and even ignore the proper knock so that if somebody's trying to brute force all the possible knocks, they'll never get feedback when they have the right one."
That would just create a new variant to DOS attacks. Instead of taking you offline, they just persistantly knock on random ports, thereby disabling your ability to communicate with trusted sources.
G
As everyone else is saying, this is just security by obscurity. That doesn't mean that you shouldn't use it, because it probably would help a lot in keeping out script kiddies and casual hackers. But the flip side, as always, is that you're giving yourself and your users a false sense of security when you pretend that measures like this will actually prevent motivated hackers from getting past it.
The most obvious way to break into a system like this is to compromise a nearby machine first and install a packet sniffer. Once you can see the traffic to the host running this port knocking system, it would be easy to discover the pattern. In fact, port knocking is less secure than a lot of other nonstandard authentication mechanisms because you could figure out the secret simply by looking at packet headers (since they contain the port numbers).
The other problem I see with this system is that it requires users to either memorize the secret knock, or use a program that automatically knocks for them. Since most people have a hard time even remembering all of their usernames and passwords, you'd see a lot of people writing down the knock, sending it via email, or writing scripts to knock for them. Dozens of opportunities to a hacker, especially one skilled in social engineering, to figure out the knock.
come on kids. Have we not learned our lessons? Even as a one time pad, this is lame
You are very much missing the point. Yes, security through obscurity is terrible when it is the only security method you use. However, it can be used to augment a better security system. Even if somebody figured out the secret knock, they would still have to get past your sshd. And if an sshd exploit was found, your secret knock might give you enough time to patch the system before it could be exploited. More security is always a good thing.
Disbelief in security through obscurity doesn't mean you have to paint a bull's eye on your head and dare people to attack you.
Toronto-area transit rider? Rate your ride.
There is only one form of security for a publicly accessible interface: obscurity. What is a password? It is a piece of information that you know that someone else doesn't - it is obscurity. The key to your house is something you have that someone else doesn't. If they knew the obscure details of your key they could make one. What is a private key, a key for SSH, a kerberos function? They are all information you know which (hopefully) a potential attacker doesn't. This is obscurity.
If you have a security system for a public interface (the front door to your house, a computer port, etc...) that does not rely on obscurity you have a system better than any theoretical system anyone has ever thought of. (Biometrics don't count - they are just another piece of information that you have that someone else probably doesn't. That's obscurity.)
#1. DoS attacks - how is this different from any other DoS attack?
#2. Sniffing the port knocks - to do this, you would already have to have the upstream compromised or be on some shared network.
That depends on the NAT gateway, as per the original poster. If the NAT gateway is dropping all packets that aren't part of a) valid incoming connections or b) a port knocking scheme, a portscan would reveal some or all of the ports utilized in the port knocking scheme. Ports that are closed but part of the knocking scheme would return a connection refused, while all the other (filtered) ports would simply be dropped.
Granted, most anyone implementing this sort of security setup on their firewall would most likely think about this and either a) open an entire range of ports, only some of which would be used for port knocking (as a previous poster mentioned) or b) simply close everything at the NAT gateway and not drop any packets, thereby not revealing any detail regarding a port knocking scheme.
I'm sure there are several other ways to deal with this at a NAT gateway, but they just aren't coming to mind at the moment.
Fully licensed blockchain psychiatrist
It isn't the port. It's the service listening on that port.
If the port is closed, then it is impossible to attack that service through that port.
This process closes those ports.
This system is going to be unreliable. No way around it. A single dropped packet and you have to try all over again. If you're really paranoid, like some have proposed, and disable the "knock monitor" temporarily if someone tries to connect unsuccessfully, it will also be horribly slow.
If you use it on a LAN, maybe the net will be reliable enough, but then you have to worry about sniffers...
PHEM - party like it's 1997-2003!
God damn, if I hear one more of you go, "this is just security through obscurity!" I am going to puke. This is the same as cleartext passwords, which are pretty secure if (a) you know nobody is sniffing the network and (b) you know nobody is masquerading as the host you want to connect to. Of course those things aren't typically true, so this alone isn't very secure. But it does disguise your exchange which, contrary to what the security-through-obscurity folks are saying, does give you some small measure of security.
This is just a way of encoding some bit transfer in the IP protocol instead of in the beginning of whatever protocol you're using after the connection. You could also use it to send cryptographic credentials which could be as secure as any other protocol (plus some extra security by obscurity). The only problem with that is that you need a way to send back information via TCP (because most good authentication protocols are two-way), but I think you need that anyway in order to serialize your knocks.
That depends on the NAT gateway
No, the gateway or direct host has ALL PORTS CLOSED, however it does log port requests. If the log shows the knocking sequence, then and only then, will it open a port.
A great many people think they are thinking when they are merely rearranging their prejudices. -- William James
It seems like a malicious user could keep you from connecting to your own machine by sending "malicious knock noise" to multiple ports. Meanwhile, your valid knocks would be disregarded as they are intermingled with malicious knocks. This may not seem like a big deal since the malicious user's connection could probably be stopped easily. But in a crisis it may cost you precious seconds or even minutes before you can eliminate the "malicious knock noise" and log into your system.
I don't think you get it. This way of securing a port (22 for example) is obscuring in the sense it hide the fact that you have a service up (SSH) to the outside world unless you know the "knock code".
You can then hide any service that is not to be known from the public (SMTP, POP, SSH, TELNET, whatever...) thus removing the probability that any exploit for these may be exploited: The hacker on the other end doesn't even know the service is running!
Write boring code, not shiny code!