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."
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.
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!
That is a very old method i developed with my friends. We would only open the door after a "secret" knock sequence. We had seen this on TV and thought this would be cool. We jeopardized the security regularly when we said "wrong knock" after someone else knocked. Usually parents. Then they would say "open up". And we had to comply.
Is the site slashdotted...
...or do I have to knock my way in?
I demand the Cone of Silence!
The idea was that you didn't want to disclose that you were running a Freenet node unless the person connecting to you already knew your node's public key.
So when someone wants to establish a connection to you, they must send some encrypted data providing they know your public key. Your node can receive this data and only respond if it is correct. Furthermore, you could let your Freenet node sit on port 25, for example, and forward invalid connection attempts to a mail server on a different port.
Through this mechanism, your Freenet node could quite effectively hide behind another server, only making itself known to those already part of the Freenet network.
IIRC this wasn't actually implemented in Freenet, but it is the intention to add it at some point. Still, it is amazing how many ideas were pioneered by Freenet years ago and are only showing up in the wider public conciousness now.
It should be noted that this is NOT (necessarily) an example of security through obscurity. One could treat the port-knocking sequence as a "key". Long enough keys could make port-scanning impossible for anyone who doesn't know the key. Real mathematical cryptography is based on a similar principle.
Also, this is only a defense against port-scanning. Even if someone did manage to break the knocking sequence, they would still have to use some kind of exploit against the machine on the port they discovered.
-3Suns
~~~~
The Revolution will be Slashdotted
The shady side of hackerdom has been using this very technique to hide their backdoors from port scanning admins. Or, uh, so I've heard...
"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
Has anyone implemented a system where a service would be stopped if the ports next to it were scanned? i.e. if 1024, 1025, 1026, 1027 were scanned, a service running on 1028 would stop.
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.
Improperly done, the knock sentry could become a security/QOS issue in itself.
This definitely is security through obscurity and perhaps would work in the same way as a car alarm. There's lots more systems out there that are easier to break into, and if someone does try, just hope that they get fed up and moves on to the next one.
If you've gone this far, why not do something like they do on radio. Open up severable ports at the same time and multiplex your signal over several of them while sending noise over the ununsed ports randomly switching between ports using a syncronized random selector.
Implement it in combination with a onetime type password arrangement. You look up what the series of knocks is supposed to be on your secureID card (or whatever), then knock in the combination it tells you to use. Tie it in with the server you want to get into, and the port you actually connect to for ssh can be different every time.
IE, secureID says sequence is "1234 1441 1114 5123", you knock on the first three, and 5123 is the ssh port activated for you only.
Casca
Somebody do the math, but it doesn't look to be that secure. Brute-forcing this would not take long.
Assuming a 5 'letter' password, you have (2^16 - 1024)^5 possible passwords, which is 1.1 X 10^24. Assuming both the server and the attacker are on fat pipes and the server is implemented in a dumb way so that it doesn't recognize brute-force attempts, you could pull off perhaps 100 attempts per second. So it would take you about 10^22 seconds, or 350 trillion years.
In security, I think this technique is comparable to a reasonably strong plaintext password. It can be sniffed, but it can't really be brute-forced.
Today's show was brought to you by Google Calculator.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
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.)
Actually, an interesting potential of this is to have you "knock" at the NAT gateway. Proper knocking opens up a given service and knock ports to an internal system.
Different knock patterns at the NAT open you to different internal hosts. Quite interesting possibilities there.
That is the point.
1. Many ports getting a sequence is much more like noise than one port getting it -> much harder to identify an attempt of intrusion.
2. If you have a backdoor, as mentioned in the article, how will you know it has not been accessed? It was not listening, it gets activated, does its duty, deactivates. If it is a good backdoor it is invisible to that system (only visible though an additional layer).
So it is a better way of getting a connection, but not a solve-all for the intruder, and I doubt the intruder cares about any waste of your resources.
--
FreeNET user? Comfortable with the adverse selection?
One interesting way to use this would be to forward incorrect knocks to a honeypot instead of the legitamite service. Then the attacker could never determine if he had indeed knocked successfully and would waste time running around in a fake system giving you valuable data about there intrusion methods and freeing up the actual service for legit users.
This looks similar to how frequency-hopping is used on secure radios.
Two radios synchronize, based on a key, and both change frequency every so many milliseconds. If you don't know the key, you can't send or receive to either of them.
I would like to see this extended to a port-hopping system for all ports and services. Sure -- it will burn some clock cycles, but I like the approach.
- Sam
http://www.iamsam.com
The summary says that the ports to knock on are closed. Portscanning shouldn't reveal which ones are available to be knocked on.
University - a box of academia nuts.
That doesn't seem right. If the order of the knocks is important, how do you get around that there's never a guarantee in what order network packets arrive? If no packets are sent back at all, how do you know when to send the next knock or even if the knock made it to the server?
This is security by obscurity, but it is useful. Don't repeat this mantra just because "the experts" say so.
Since some still don't understand its use, i'll be speaking metaphorical:
Assume you need to have a special key to open a certain otherwise secure door. OpenSSH might be that door and your passphrase and your certificate are the key.
An attacker can still forge the key or attack the lock with a different approach, picking etc. - comparable to "social engineering" to get the password, brute forcing or exploits.
And that port knocking sequence now effectively hides the lock, leaving an attacker without a first approach to pick or break the lock. It just adds another layer of security. You just don't know where to start your attack. You can't use exploits, you can't try brute force - nothing, heck you don't even know what type of daemon your target is.
A clean stainless steel door with a covert RFID-detector one square inch in size, hidden somewhere, sure as hell beats the same door with a clearly visible lock. You still need to pick the lock, but you can't poke your lockpicking tools into solid steel and you can't crack something you cannot discern.
--- Still one addition to say: having a machine connected to the internet with no ports open makes you a prime suspect for the port knocking scheme.
A good stealth scheme may be implemented, so a potential attacker (excuse for this metaphor again) does not even see the door (or the building, for that matter).
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
What if I turn this whole thing around and install fake services on a number of ports?
For example, whenever you make a connection to a port between 1025 and 2048 on my system, you're greeted with "OpenSSH ...", and prompted to authenticate. But only behind one among those 1024 ports is the real SSH. On any other port, the fake service takes the username and password you've entered, wait a few seconds (just idling around), and tell you "Authentication failed". If you try too often to connect to faked services, you're put on the black list to avoid DOS, of course.
When a process is listening for new connections, it doesn't block existing connections from carrying on sending and receving data
When a port is 'connected', it means that a process has an established connection to another host.
Therefore, no, just because a port is not listening/open, doesn't prevent an existing connection from sending and receiving data.
If that was the case, then the first person to telnet/ssh to your box would tie up that port and a second connection would be blocked until the first had freed up the port, however that is not what happens at all.
All they're saying is that when the portknocking daemon detected the correct knock sequence on closed ports, it starts a process to LISTEN for new connections, ideally from just the host that did the knocking, for a limited period of time (10 seconds). Once a TCP connection is established with the listening host, that host no longer needs to listen, and that's why it stops after 10 seconds.
http://www.portknocking.org/view/about/obscurity
It does a much better job of explaining this than anything yet posted here.