Slashdot Log In
"Port Knocking" For Added Security
Posted by
CmdrTaco
on Thu Feb 05, 2004 02:03 PM
from the thats-a-crazy-idea dept.
from the thats-a-crazy-idea dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
not bad (Score:5, Insightful)
Re:not bad (Score:5, Interesting)
And? It is still more secure. By using "port knocking" they HAVE to sniff out your network traffic and find the port combo. Without "port knocking" they just need to run nmap and see what ports they can try to attack.
Parent
Re:not bad (Score:5, Informative)
Hence, weather or not it is secure, is all a matter of opinion. Personally, I think if you can't run SSH out in the open, you shouldn't run it thru an obscurity filter.
We have no SSH configured on our outside network. Not with OTP, not from only allowed IP's. Not from only a specific port. Not with KnownHosts only. Not with known RSA keys only.
You want on, you've gotta be in the building. It'd be nice to fix problems while remote, but it's just not an option because of the security problems it presents. I live within a mile of the building, specifically so not having remote access isn't a big deal. I can go from sleeping in bed, to in the building in less then 10 minutes. It's a pain for small problems. However, it's small issue in comparison to dealing with a full blown network breakin due to SSH.
On occasion, I believe we have had someone local build an SSH tunnel that we can VPN thru onto our network. However, someone who already had access had to initiate the connection by hand with the correct IP. That's only allowed if we voice authenticate from you.
Kirby
Parent
Re:Promiscuous mode (Score:5, Informative)
Essentially, with a little judicious arp spoofing and a flood or two, the switch can be confused into just "making sure" the packets get to the right destination by broadcasting like a hub when it would normally be switching.
Parent
Services listen on ports. (Score:5, Insightful)
If the port is closed, then it is impossible to attack that service through that port.
This process closes those ports.
Parent
Re:not bad (Score:5, Insightful)
Open ports per se are not insecure!
The whole point behind port knocking is the wrong impression that "open" ports are more insecure than "closed" ports. This is totally bogus.
It's about the applications behind the open ports, and it's not more complicated to write code which listens to a specific port and drops the connection if it doesn't recieve some secret number as the only payload of the first packet, than it is to write the kernel tcp/ip stack.
That brings me to another mantra
Kernel code is not intrinsically more secure than application level code!.
There are many examples for buggy and overflowing tcp/ip stacks (ping-o-death comes to mind if you're somewhat older).
Parent
Re:not bad (Score:5, Interesting)
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.
Yeah, this is no substitute for properly securing the original service, but it's an extra layer that means there's even more that needs to be captured for a successful hack...
Parent
Not good (Score:5, Insightful)
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.
Parent
Re:not bad (Score:5, Interesting)
Re "brute forcing"... the number of possible knocks is (ports used for knocking) ** (ports in knock sequence). Yes, that's exponentiation.
In fact, I'd suggest making the knock sequence much longer then in the article; ten might be good. Then, if you allocate 100 ports to the knocked and randomly select a 10 port sequence for the knocking, you get 100 ** 10 possible knocks, or 100,000,000,000,000,000,000 (100 sextillion) possible knocks.
With just a few more ports in the sequence and just a modest investment in ports, you can make brute forcing impossible.
(And if you mix up the ports so they aren't sequential and the attacker has to guess THOSE ports, it goes to approx. (2**16)**(number of knock), so for a 10-port sequence on potentially all TCP ports it's 1,461,501,637,330,902,918,203,684,832,716,283,019
(I love posting big numbers on Slashdot.)
You need to worry about sniffers way more then brute forcers. (And as this is another layer of security, hopefully on top of an already fairly secure protocol like SSH, it's a good thing; now the 'man in the middle' has to have advanced knowlege to even know there's something to get into the middle of!)
Parent
Old Idea, Different Use (Score:5, Informative)
Parent
not so shady... (Score:5, Interesting)
iptables -N ${SSH_TABLE}
iptables -Z ${SSH_TABLE}
iptables -A ${SSH_TABLE} -m state --state NEW -m limit --limit 2/minute --limit-
burst 2 -j DROP
iptables -A ${SSH_TABLE} -m state --state NEW -m limit --limit 7/hour --limit-bu
rst 7 -j DROP
iptables -A ${SSH_TABLE} -m state --state NEW -m limit --limit 10/day --limit-bu
rst 10 -j ACCEPT
iptables -A ${SSH_TABLE} -j DROP
well, I thought it was cool...
Parent
Re:not bad (Score:5, Interesting)
Hmm, lots of people have pointed this out, but it's easy to set up a system of one-time passwords... provided it's done in a cryptographically secure way, there's little point in sniffing for combinations.
Of course, you can still sniff to see what ports are actually in use...
Parent
My idea (Score:5, Interesting)
Easy enough... (Score:5, Insightful)
Sniffing.
Knock knock... who's there? (Score:5, Funny)
Who's there?
Usher.
Usher who?
Usher wish I could SSH to your server!
Sorry...
Before you complain about "Obscurity" (Score:5, Insightful)
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!
Obscurity IS Security (Score:5, Insightful)
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.)
Parent
Re:Obscurity IS Security (Score:5, Insightful)
Most security is based on secrets of one kind or another---that doesn't make it "obscurity."
Parent
Re:Obscurity IS Security (Score:5, Insightful)
So this just makes part of the protocol secret, and one of our assumptions about security protocols is that the protocols are known.
Yes, it's an interesting and reasonably clever little hack (it is not, however, new), it does tend to hide some information (e.g. that the ports are even open) but if you're going to make the port look closed, anyhow, why not just listen on that port for something that would cause the service to "wake up"? I guess they thought it seemed a bit more clever the other way, who knows?
Parent
Old stuff (Score:5, Funny)
Slashdotted? (Score:5, Funny)
Is the site slashdotted...
...or do I have to knock my way in?
Silent Bob (Score:5, Informative)
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.
NOT security through obscurity (Score:5, Interesting)
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.
Possible problems (Score:5, Interesting)
Reverse-knock (Score:5, Interesting)
Security through obscurity (Score:5, Insightful)
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 [amazon.com], to figure out the knock.
hmm... (Score:5, Interesting)
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.
go a step further (Score:5, Interesting)
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.
Knock Knock Honey Pot (Score:5, Interesting)
Christ people! (Score:5, Informative)
freq. hopping analogy- (Score:5, Interesting)
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
TCP/IP problems with this method. (Score:5, Informative)
The problem is of course that since no connection is being established, there's no guaranteed delivery of packets, and no guaranteed delivery of packets in the order they were sent. This could be very problematic across network connections that drop packets, and provide you no feedback as to why you can't open your connection. If only 10 % of my packets get dropped, and I require 10 "knocks", I only have
Is there a clever way to solve this problem, or is the reliability of it tied to a low amount of packet loss on a network?
It's _not_ just another password... (Score:5, Interesting)
Stop complainin about "security through obscurity" (Score:5, Insightful)
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.
Re:Password (Score:5, Insightful)
Except it hides that the port is open at all, which is useful.
Parent
Not the point (Score:5, Insightful)
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.
Parent
Re:Brute Force (Score:5, Informative)
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.
Parent
Re:Well, there go the logfiles (Score:5, Interesting)
Parent
Re:Well, there go the logfiles (Score:5, Insightful)
And what stops them from brute-forcing regular password protected access on a known port?
1) You don't know how many ports are in the knock sequence
2) You don't know that the range is
3) You don't know what port will open when you get it right
Similar to a password, only instead of base 94 (a-z,A-Z,0-9`~-_=+\][|}{';":/.,?>million trillion trillion trials to crack. Then you have to do one more scan to figure out which port actually opened after each trial and hope no other service opened a port for some unrelated reason.
I'm thinking it's a tad more secure than password authentication alone... and you can always throw password auth in after the client connects, so you can throw in a few false-positives (bogus logins) to keep them busy.
And a five second window to transmit the sequence is pretty generous. If you wanted to harden it even more against brute forcing, you could require a full 5 second wait and accept all connection attempts from a particular host. That would limit an attacker to 20 attempts per minute max. So it'll take the better part of 32 billion trillion years to crack it.
At that point, you can consider the end of the universe as "The ultimate connection timeout"
=Smidge=
Parent
Re:Well, there go the logfiles (Score:5, Interesting)
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.
Parent
Re:Well, there go the logfiles (Score:5, Informative)
Is zero secure enough for you? The ports used for knocking are not open. The knock is the connect attempt which is recorded as an event on the server. The client gets nothing, not a NAK not a reset, nothing.
Parent
Re:Well, there go the logfiles (Score:5, Interesting)
Parent
Re:Well, there go the logfiles (Score:5, Interesting)
Parent
Neither. (Score:5, Insightful)
#2. Sniffing the port knocks - to do this, you would already have to have the upstream compromised or be on some shared network.
Parent
Re:Well, there go the logfiles (Score:5, Interesting)
Different knock patterns at the NAT open you to different internal hosts. Quite interesting possibilities there.
Parent
Re:Well, there go the logfiles (Score:5, Insightful)
And yes, one the most annoying things about sitting behind a NAT is only being able to forward a port to a single host at a time. This would be great if "port knocking" could solve this, though in a very Rube Goldberg fashion.
Parent
Re:Open a whole range of ports (Score:5, Informative)
Parent
Re:Open a whole range of ports (Score:5, Insightful)
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.
Parent
Re:Well, there go the logfiles (Score:5, Insightful)
Parent
Re:Equivalent to a password (Score:5, Interesting)
This seems much better than a password, I would think (Though I certainly would still use a password as well).
As an analogy, if you want to get into a house, and find a locked door, you have a few options... You can try one of those M x N position key blanks, which will take a very very long time (exhaustive search). You can try to pick it (exploit a weakness in the password algorithm). You can try to get ahold of a copy of the real key (packet sniffing, "shoulder surfing", etc). But you have no doubt that somewhere, a key exists that will open that door.
Now compare that to a solid block of concrete, roughly the size of a house. What does it do? Do helicopters land on it? Does it cover something, or hold something down? Does it have something sealed inside it? You'd never suspect that that, if you utter the magic phrase "Sim sala bim bamba sala do saladim", a door will appear in the side of this large concrete block, allowing those with a key to gain entrance.
The main difference involves knowing whether or not a way in exists. With just a passworded port, an attacker knows that enough effort will pay off. Adding in port knocking, that attacker doesn't know whether or not their hard work can ever gain them entrance, since a port might well not exist.
Now, in my opinion, the more interesting question here involves how to hide this from one's ISP (ie, make it snoop-proof).
Parent