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."
I predict a flood of commenters whining about this being "security through obscurity."
Something tells me I'm going to be seeing a lot bigger firewall logs in the future, as this catches on.
Damn, interesting...
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.
This is secure in the same way 50-character passphrases are secure, sure they are harder to crack but who the hell is goig to remember them. The harder you make something to use, users will start trying to find ways around it.
whats more, connection attempts are easy to sniff, you might as well be using telnet...THIS THING IS BEGGING FOR A "REPLAY ATTACK".
Ahhhhh!!
Land shark
I though about this along time ago as a way of hiding a trojan. Of course I didnt patent it so no money for me : /
Im not here now... Im out KILLING pepperoni
This security is easily defeated if the connection can be sniffed to find the 'secret handshake'.
little pig little pig...
let me in
come on kids. Have we not learned our lessons? Even as a one time pad, this is lame
Sure it's great if the machine's not firewalled in the first place...
Am I the only one who heard Beavis say "Port Knocker!"?
Probably...
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
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.
Well, it's just a password to connect to a port where the password happens to consist of connection tries to specific ports.
It's a nice hack, but I am sure there are other ways to implement password-protected port access...
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
Snoop and replay the pattern.
You'd need to change the "secret handshake" each time used.
I am not at all sure I see the benefit of it. It makes connecting more complicated and therefore troublesome, while sniffing out a "secret" knock should be trivial with tcpdump or whatever tool you like to use.
Right now, script kiddies have their computers automatically try to access other peoples' computers, looking for ones without firewalls, etc.. If this happens, wouldn't you expect them to just send out random knocks in the hopes of getting something? If that happens, you will be more secure personally, but the increased traffic may cause more problems that it solves.
G
Knock knock...
;)
Who's there?
Usher.
Usher who?
Usher wish I could SSH to your server!
Sorry...
libertarianswag.com
Interesting. So the next step would be to have one-time port knock sequences a-la one-time passwords (to defeat adversaries who are grabbing a copy of all your packets). But it seems like there is a race condition between the delay after the knock and the actual connection. Anyone have a solution to this?
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!
I think the /.ers knocked one to many times on this mans port.
I can't wait until I want to ssh into home from some cyber cafe behind a firewall or from an os where I can't replicate the knock!
Security through obscurity rules!
Do a google search on 'port finger pulling.'
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.
It seems to me that anyone who was watching your packets go by could pick out the knocking sequence. Granted, if no one suspects knocking, no one will notice. But, now that it's on the front page of slashdot, I don't think it's very obscure security anymore.
Upstairs Dog, Downstairs People.
I thought that it had been decided - security by obscurity is bad! It creates a false sense of security, leading people to think they are safe when in fact they are not.
Someone pls clue me in why this is any different.
Most writers regard truth as their most valuable possession, and therefore are most economical in its use - Mark Twain
The only use I can really see for this is to run servers where you aren't allowed (brain dead ISPs, etc.) As a security method I think it is a bad idea.
I think we need to focus on cleaning code, using proper passwords and encryption, and having sensible policies, such as locking out accounts for a pre determined amount of time after a login failure.
Port knocking probably will never catch on for more than a few paranoid people because it requires too much of a change on the client side. It generates more traffic.
We have secure protocols. I believe priviledge seperation, non-executable stacks, and strong authentication systems are a lot better than some knocking scheeme (which could be easily sniffed, unless it changes, but you would know it was there).
We need to focus on security, not obsfication.
I was thinking about implementing this a while ago; I guess it's an obvious enough idea that others have been thinking along the same lines. This is equivalent to to putting a password on access to the port.
Ideally, the implementation will only consider connection attempts originating from the same IP address.
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!
Is the site slashdotted...
...or do I have to knock my way in?
I demand the Cone of Silence!
...simply using open ports, but with a whole lot more bandwidth.
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.
this sounds like a really cool idea. not to mention being reminicent of tactics used in (cheesy) hacker movies (like "hackers")
I'm not sure sniffing would work. Imagine an algorithm for the password based on some variable (time for instance) and a seed (password) that is known to both machines but not transmitted. It would be a bit harder to reverse engineer and crack the "knocking code".
Just an idea.
--D3X
The One Site for Free Adult Entertainment...
Why do people insist on pursuing humanistic metaphors in cyberspace when there isn't a practical application? This whole premise is ridiculous.
If you want to play with humanistic metaphors, remember the first rule of security is that its better to have ONE door in your house that you keep an eye on, than five windows and two doors with an elaborate security system. In the latter case, you have seven points of entry instead of one.
There's no reason you couldn't change the knock sequence after each knock in a cryptographically hard-to-guess way (like the SSH one-time passcode mode) or use a hash of the time of day (to the nearest minute) plus some known pass code, exactly like SecureID cards.
Preventing replay attacks is not difficult, and the port-knocking technique generally is a pretty cool hack.
You are a defamatory bastard! Taco has never been in a bathroom!
There are only 2^16 ports available. So, basically this knocking technique boils down to choosing a 5/6/7/8 letter password over a 2^16 alphabet. (To be more precise, you can ignore the port numbers 0 to 1023 as part of the alphabet as they are 'reserved'). So, effectively, it boils down to 2^16 - 1024.
Somebody do the math, but it doesn't look to be that secure. Brute-forcing this would not take long.
Free XBox, PS2
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
I already have a solution for this scenario. It's called a VPN. Anyone who doesn't know the "secret handshake" (VPN encryption key) doesn't get past the firewall. I don't have to worry about port 22 on my server....or any other port.
-ted
Why not just filter by IP? If you need control over who is allowed to access a port, this seems to be a better solution.
No I DO
I could build a backdoor on the server that [...] detects connection attempts to closed ports 1026,1027,1029,1034,1026,1044 and 1035 in that sequence within 5 seconds [...]
Then your secret handshake wouldn't exactly be very secret, now would it? Why not use something that actually would remain a secret. Something fairly cryptographically strong, for example. It could still run on an unrelated port, and manage access to other ports the same way, but wouldn't be (as) easily broken by restrictive firewalls, wouldn't be sniffable, and still has the added advantage of added security (though by no means a complete solution) without depending on any modification of whatever's listening on the port your restricting access to.
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
This could easily be sniffed detected by malicious parties, as well as exploited pretty easily. The only way I would feel secure with this is if the pending port connection checked the IP of the incoming connection, at which point, the knocking becomes pointless
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Some people have already pointed out the obvious weakness of this, that the secret knock is only an added layer of obscurity, and security by obscurity is flawed in many ways. But this scheme could be a little more secure if the knock itself was a function only known to those 'in the know'. For example, it could be a function of time, so if time.nist.gov says it's time X, then I look in my secret list of knocks and get the port and timing sequence for this particular f(X).
A third party could be watching your knock, and as soon as they recognize the knock they could try it themselves. But by then, the knock-as-a-function-of-time would have changed, so it would do them no good.
Nuh uh! I am the winner of the ten bucks. It's okay, I'll buy you a beer.
Before you Slashdot about "port knocking", please
send your text through a spellchecker.
"implimenting" should read "implementing".
Remember, the "President"
was AWOL
Regards,
Kilgore
What if multiple attempts from the same IP are made to access the port at the same time? Wouldn't the knocks get all mixed up?
Mad Software: Rantings on Developing So
OpenSSH is a great peice of sodtware - but it's so huge that I can't help but think that their could be flaws in it (like the one of 6 months ago)
I would love to layer another peice of security infront of OpenSSH and this seems like a great idea.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
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.
Yeah, I know I'm always saying that, I need to start taking out patents instead of letting other people steal my idea. Anyway there's a few issues here: 1. The "knock" ports need to be open all the way to the server. This means that you'll have to punch holes in your main firewall or else not use 1 main firewall but instead indiv. firewalls per server which tends to be less managable/less secure 2. There's no real set way of implementing this yet. Try telling your users to first run telnet 1023, then telnet 1059, then telnet 1236 then actually ssh into the real port. Course if your this paranoid it's probably an ultra secure box anyway. It'd be awesome to see this implemented and allow for easy "keying" of the ports, so I can choose any number combo I prefer. Of course it should then also make sure the ssh connection is coming from the same IP that knocked. And it might take a while but a sniffer would crack the combo...
Could this be implemented with IP Tables under Linux? I remember seeing a set of rules to detect a port scan; could a similar set of rules be used to unlock a port for a given remote IP number?
Of course, this won't take off unless there's also knocking support built into the clients (like ssh).
Hmm - port knocking is all well and good, until someone finds out about the secret knock through some means (e.g. "hello, I work with the security department and we need your password and secret knock").
So, we'll need to change the knock every so often, and we'll have to securely communicate what the new knock is to everyone who needs to know it.
So we'll use encryption so we can securely communicate the port-knocking key so we can securely communicate.
Hey, I have an idea: let's just use encryption in the first place and not even bother with port knocking.
What Would Jesus Do
(for a Klondike bar)?
It sounds like a euphemism for something obscene. I bet it's illegal in Texas.
-Carolyn
Like Daddy always said: if you can't dazzle 'em with brilliance, baffle 'em with bullshit.
it's been slashdotted Anybody got a cache?
...silicone implants to spoof their way in. This will cause the so-called Pam Anders or 'Andersing' of your server.
This will work great, until someone finds a bug in the knock processor, and uses it to root your box.
I love Kimmy!
Pon mah dick, nigga!
Cisco ACLs can be configured to change when a particular login is observed.
I would think that this method would be slightly better, since the router can require authentication before opening the port.
Don't pick up the pho*(@)$*@&@!@ NO CARRIER
just see a Microsoft "get the facts" advert on /.?!?!
An infinite number of monkeys will eventually come up with the complete works of
The justifiably paranoid administrator can open the ssh/22 port on his system by initiating TCP connections to ports 31,32,30. At the end of the ssh session, the port would be closed by using the second sequence shown above. If the host from which the administrator is connecting is not trusted (if, say, keystrokes may be snooped), the use of the third sequence would deny all further traffic from the IP, preventing anyone from duplicating the session. This assumes the port sequence and system login credentials are not captured by a third party and used before the legitimate session ends.
A simple extension to this is that instead of blocking the current IP, you could simply use a smarter script client and server side. The first time you successfully log in, it goes to the next thing. You don't even need to disable the port - it only keeps it alive for your current session. The client and server both know what the next (different) sequence then should be...if it was 32,30,31 before, now its 30,32,31. That sort of thing. Obviously, this qould work better with more than 3 ports, but as the article (that darn thing) points out, even in the sub-1024 range, about a quarter are usable for such things.
Also note, for those that didn't F@#$ing read the article, that the sequence merely opens a port - the reference was SSH, as an example. So if you get the sequence, it allows you to attempt an SSH login. Its not just security through obscurity at that point. Its additional security through obscruity :P
I'd love to see this paired with a dynamic set of sequences. Or...nah, I won't mention the idea I just had. I might want to patent it [snicker]
Did you say fart knocker....
I have sshd running on my machine, but on a high port number. Even if someone found it was open, they wouldn't know it was ssh without some further investigation. So this scheme is fine, but at the end it shouldn't open ssh on 22, but on some other pre-arranged port.
Gates' Law: Every 18 months, the speed of software halves.
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.
one could also change the sequence of ports that are used to be based on some key/progression/timestamp? so the knock is constantly changing... so even if someone sniffs the knock, it wont help.
"Nyquil - The stuffy, sneezy, why-the-hell-is-the-room-spinning medicine."
My gripe is that we're supposed to have 65k+ ports .. but i am only allowed to use a couple. 53/80/443. so i have to tunnel everything. why dont we just tunnel everything on 1 port and have the server scan for public keys and open apps based on that from just 1 port. would pretty much accomplish the same thing.
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.
This introduces several additional points of failure in every connection. For example, suppose you had a 5 port knock before connecting to your final real port. If any one of these fails to reach the end point, you're denied service. Thus, if I have the ability to stop some of your packets from coming through, I only have to stop one packet per connection attempt -- a new low bandwidth DOS.
Even if there's nobody malicious in between you and the server, you need to make sure that 5 packets get through in sequence. That's not terribly easy.
I thought of this years ago while working at DEC!
I've been knock, knock, knocking on port 80, but no one is answering!
SIGFAULT
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.
whoever modded this "informative" obviously did not even bother trying to search for "ninnle linux"
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
To send the sequence of port knocks there will have to be a slight delay between each one in order to make sure the packets arive in the right sequence.
Which means that there is ample enough time for someone to "ruin" this sequence of knocks... thus preventing an authorized communication from taking place.
No?
I'm your huckleberry
I've got a great new idea for secure data transmission. Rather than sending encrypted data inside a frame, you just access certain ports in a certain sequence. Set aside 16 ports, and you can send four bits of data by noticing the order in which people try to access the ports, without opening a single port at all. Repeat at will for arbitrary length messages.
Now, just layer on some uuencoding in case it has to be compatible with some 300 bps 7-bit serial link somewhere -- make that base-64 in case of escape characters -- and we've got a great new transports for warez and pr0n on thos P2P apps.
Nobody will ever figure this one out.
This assumes the port sequence and system login credentials are not captured by a third party and used before the legitimate session ends.
Simple solution - limit the number of open sessions to the port then. Duh. Allow only 1 login. Have the script watching to see when the session ends, then close the port up directly after. That, combined with the dynamic sequences, and viola - you could almost forget about needing a password! I kid ;)
Now that we'll have scripts out there that randomly knock on various sequences, trying to get luck. Geeze....great.
This seems very inconvenient and only marginally secure. It's a major hassle to have to go to this sequence every time you want to connect. Adapting software to do it for you could help, but you can't do that for everyone.
And what if you wanted to offer your service to others, or even the general public? Do you require them all to run specially adapted software? Or do you tell them the sequence, with the risk that they forget and have to ask for it again, or leave it on a note that some malicious person could find, or even just tell it to someone else?
If you wanted to keep your knock all to yourself, rest assured that someone could sniff it just fine.
I suggest you keep your SSH port open and make sure your sshd is patched. You can then use all your other services through SSH tunnels if you like.
Please correct me if I got my facts wrong.
Have a rotating sequence of acceptable knocks. ... Knock(n)
This way any sniffing doesn't know that the same knock won't work next time.
Further screw them up by having repeats in your rotation so a dedicated sniffer sees a repeat and think the rotation is complete.
Knock1, Knock2, Knock3, Knock1, Knock4
The client knows all the knock sequences and tries them in order with some reasonable time separation.
Sniffer doesn't know which one opened the ports (random time to open ports from successful knock ex 1-20 seconds) and if he repeats, knock may or may not work.
As others have suggested will work fine as part of multi-layered system.
Ouch
Here's my FagPG key.
VSBBUkUgVEVIIEZBSUxVUkUKWU9VIEFSRSBURUggRk FJTFVSRQoKWVlPVSBBUkUgVEVIIEZBSUxV
UkUKCllPVSBBUk UgVEVIIEZBSUxVUkUKT1UgQVJFIFRFSCBGQUlMVVJFCllPVSBB UkUgVEVIIEZB
SUxVUkVZT1UgQVJFIFRFSFlPVSBBUkUgVEVI IEZBSUxVUkUKCllPVSBBUkUgVEVIIEZBSUxVUkUK
IEZBSUxV UkUKCllPVSBBUkUgVEVIIEZBSUxVUkUKCgpZT1UgQVJFIFRFSC BGQUlMVVJFCiMgUGxl
YXNlIHRyeSB0byBrZWVwIHBvc3RzIG 9uIHRvcGljLgojIFRyeSB0byByZXBseSB0byBvdGhlciBw
ZW 9wbGUncyBjb21tZW50cyBpbnN0ZWFkIG9mIHN0YXJ0aW5nIG5l dyB0aHJlYWRzLgojIFJlYWQg
b3RoZXIgcGVvcGxlJ3MgbWVz c2FnZXMgYmVmb3JlIHBvc3RpbmcgeW91ciBvd24gdG8gYXZvaW Qg
c2ltcGx5IGR1cGxpY2F0aW5nIHdoYXQgaGFzIGFscmVhZH kgYmVlbiBzYWlkLgojIFVzZSBhIGNs
ZWFyIHN1YmplY3QgdG hhdCBkZXNjcmliZXMgd2hhdCB5b3VyIG1lc3NhZ2UgaXMgYWJv dXQuCiMg
T2ZmdG9waWMsIEluZmxhbW1hdG9yeSwgSW5hcHBy b3ByaWF0ZSwgSWxsZWdhbCwgb3IgT2ZmZW5z
aXZlIGNvbW1l bnRzIG1pZ2h0IGJlIG1vZGVyYXRlZC4gKFlvdSBjYW4gcmVhZC BldiMgUGxlYXNl
IHRyeSB0byBrZWVwIHBvc3RzIG9uIHRvcG ljLgojIFRyeSB0byByZXBseSB0byBvdGhlciBwZW9w
bGUncy Bjb21tZW50cyBpbnN0ZWFkIG9mIHN0YXJ0aW5nIG5ldyB0aHJl YWRzLgojIFJlYWQgb3Ro
ZXIgcGVvcGxlJ3MgbWVzc2FnZXMg YmVmb3JlIHBvc3RpbmcgeW91ciBvd24gdG8gYXZvaWQgc2lt
cGx5IGR1cGxpY2F0aW5nIHdoYXQgaGFzIGFscmVhZHkgYmVlbi BzYWlkLgojIFVzZSBhIGNsZWFy
IHN1YmplY3QgdGhhdCBkZX NjcmliZXMgd2hhdCB5b3VyIG1lc3NhZ2UgaXMgYWJvdXQuCiMg T2Zm
dG9waWMsIEluZmxhbW1hdG9yeSwgSW5hcHByb3ByaWF0 ZSwgSWxsZWdhbCwgb3IgT2ZmZW5zaXZl
IGNvbW1lbnRzIG1p Z2h0IGJlIG1vZGVyYXRlZC4gKFlvdSBjYW4gcmVhZCBldmVyeX RoaW5nLCBl
dmVuIG1vZGVyYXRlZCBwb3N0cywgYnkgYWRqdX N0aW5nIHlvdSMgUGxlYXNlIHRyeSB0byBrZWVw
IHBvc3RzIG 9uIHRvcGljLgojIFRyeSB0byByZXBseSB0byBvdGhlciBwZW9w bGUncyBjb21tZW50
cyBpbnN0ZWFkIG9mIHN0YXJ0aW5nIG5l dyB0aHJlYWRzLgojIFJlYWQgb3RoZXIgcGVvcGxlJ3Mg
bWVz c2FnZXMgYmVmb3JlIHBvc3RpbmcgeW91ciBvd24gdG8gYXZvaW Qgc2ltcGx5IGR1cGxpY2F0
aW5nIHdoYXQgaGFzIGFscmVhZH kgYmVlbiBzYWlkLgojIFVzZSBhIGNsZWFyIHN1YmplY3QgdGhh
dCBkZXNjcmliZXMgd2hhdCB5b3VyIG1lc3NhZ2UgaXMgYWJv dXQuCiMgT2ZmdG9waWMsIEluZmxh
bW1hdG9yeSwgSW5hcHBy b3ByaWF0ZSwgSWxsZWdhbCwgb3IgT2ZmZW5zaXZlIGNvbW1lbn RzIG1p
Z2h0IGJlIG1vZGVyYXRlZC4gKFlvdSBjYW4gcmVhZC BldmVyeXRoaSMgUGxlYXNlIHRyeSB0byBr
ZWVwIHBvc3RzIG 9uIHRvcGljLgojIFRyeSB0byByZXBseSB0byBvdGhlciBwZW9w bGUncyBjb21t
ZW50cyBpbnN0ZWFkIG9mIHN0YXJ0aW5nIG5l dyB0aHJlYWRzLgojIFJlYWQgb3RoZXIgcGVvcGxl
J3MgbWVz c2FnZXMgYmVmb3JlIHBvc3RpbmcgeW91ciBvd24gdG8gYXZvaW Qgc2ltcGx5IGR1cGxp
Y2F0aW5nIHdoYXQgaGFzIGFscmVhZH kgYmVlbiBzYWlkLgojIFVzZSBhIGNsZWFyIHN1YmplY3Qg
dG hhdCBkZXNjcmliZXMgd2hhdCB5b3VyIG1lc3NhZ2UgaXMgYWJv dXQuCiMgT2ZmdG9waWMsIElu
ZmxhbW1hdG9yeSwgSW5hcHBy b3ByaWF0ZSwgSWxsZWdhbCwgb3IgT2ZmZW5zaXZlIGNvbW1lbn Rz
IG1pZ2h0IGJlIG1vZGVyYXRlZC4gKFlvdSBjYW4gcmVhZC BldmVyeXRoaW5nLCBldmVuIG1vZGVy
YXRlZCBwb3N0cywgYn kgYWRqdXN0aW5nIHlvdXIgdGhyZXNob2xkIG9uIHRoZSBVc2Vy IFByZWZl
cmVuY2VzIFBhZ2UpCiMgSWYgeW91IHdhbnQgcmVw bGllcyB0byB5b3VyIGNvbW1lbnRzIHNlbnQg
dG8geW91LCBj b25zaWRlciBsb2dnaW5nIGluIG9yIGNyZWF0aW5nIGFuIGFjY2 91bnQubmcsIGUj
IFBsZWFzZSB0cnkgdG8ga2VlcCBwb3N0cy BvbiB0b3BpYy4KIyBUcnkgdG8gcmVwbHkgdG8gb3Ro
An idea like this occurred to me a couple years ago when I was listening to a computer security class.
Namely, the knocking attempts can become a communications channel if they're timed right. cf Also Red October ("One ping only.").
Low-speed, to be sure, and kind of "1-way" dominant, but more surreptitious, if there's a need for that.
And more difficult to detect in the log files, if knock timing is done for port 80.
"Provided by the management for your protection."
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.)
How is this different from a password transmitted plain-text over the wire? The author is trying to use the port number as an information channel. As an information channel, all the same security problems exist as for regular channels. In this case, the "port number sequence" is unencrypted. So we're back to plain-text passwords...
message144 (also known as xor) has been doing that since 99? yeah its not new.
-green is the color of the rainbow
Exactly the argument to counter the overplayed "security through obscurity" card. Absolutely correct! Mod up!
I don't get this idea. How is this knocking fundamentally different from, say, a password? It's a sequence of signals you make which only you and the server are supposed to know, thus to verify your identity. But compared with password or RSA/DSA keys, it's slower, consuming more resources, and cannot be solely relied on -- too easy to sniff. If you want your security to be tighter, you might as well make your passwd harder to guess.
This isn't about having multiple doors - it's about turning doors into doorbells.
G
I can see it now:
1024-1025-1026-1027-1028... nope.
1024-1025-1026-1027-1029... nope.
1024-1025-1026-1027-1030... nope.
1024-1025-1026-1027-1031... nope.
0.003 seconds later:
1024-1025-1157-2009-2087... nope.
1024-1025-1157-2009-2088... nope.
1024-1025-1157-2009-2089... nope.
1024-1025-1157-2009-2090... nope.
0.002 seconds later:
1024-1025-1500-1111-1836... nope.
1024-1025-1500-1111-1837... nope.
1024-1025-1500-1111-1838... nope.
1024-1025-1500-1111-1839... nope.
Multiplied by the hundreds, or thousands.
Nice.
Let's give 5CR1P7 K1661E5 a new, simpler idea on how to bust into firewalls...
The problem with socialism is that they always run out of other people's money. - Margaret Thatcher
What a novel idea. I wonder if there is a way to extend this to fighting spam. Perhaps not by using the actual "knocking" mechanism but by pairing a sent message with some information contained in another protocol.
:)
Imagine: I send an email to a buddy, through my ISP's mail server. My email client also contacts my buddy's mail server directly, "knocks" on it and informs it to expect my message. If an unexpected message shows up it's flagged as spam.
I'm not sure how feasible this is-- I'm just trying to think outside the box on spam fighting.
--Nick
..some variation on 'shave and a haircut, two bits'.
before someone else does!
I've used this in the past.. but it's only real value is that nobody knows you are doing it. Someone with a sniffer and a brain can figure it out.
In the end, it's only a gimmick. If you have to knock a few ports.. that can be sniffed out, just like a password. Though it might seem at first like it's more secure, it's not.. it just adds obscurity.
Now.. obscurity of this nature does have some value... it's obscurity.. and not likely to be detected by some script kiddie...
but don't kid yourself into thinking this is revolutionary, or in any technical way more secure. It's not.
Does anyone know the secret knock for www.portknocking.org:80 ?
Thanks.
SPAM
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.
Ma take this computer off of me
I can't use it anymore
Its screen's blue, too blue for me
And I feel like knocking on someone's port
Knock, knock, knocking on someone's port
Ma take these scripts from me
I just can't run them anymore
There's a crowd of lawyers a-followin' me
And I feel like knocking on someone's port
Knock, knock, knocking on someone's port
Slashdot's here to take down your system.
To prevent sniffer attacks against port knocking, one could very easily implement a shared key based system where the knock sequence and timing were defined by an algorighm that generated the sequence based on a shared key and current time. It's still just another password and layer of obscurity; however, it's more cryptographically secure than a fixed knock that can be sniffed out.
I can't think of a way to implement a public key based knocking system without the server needing a copy of each possible user's public keys; and that would sort of defeat the intention of such a system to begin with.
Perhaps I will hack something into that reference implementation. The idea sounds pretty fun to implement, especially for folks who have completely shitty ISP's who get irate about listening services..
How many people are going to say sniff and repeat the sequence. You still have to get through the service after it opens. The whole point is that they don't know what is going on in the first place. And rotating keys are a good idea anyway. I like this idea for running some kind of server behind your ISP that normally doesn't allow such things. When I had excite@home I would regularly get firewall logs that said "authorizedscan.home.com" portscanning me.
And someone should tell Taco how to spell "implement" (To miss it once is a typo. To miss it twice is a "d'oh!";)
Helevius
finaly some stupid implementing this stupid idea,
until now there were only stupids suggesting it all the time.
The only place it not totally stupid, is if noone
else uses it and noone else know that you use it.
(Or may think about it).
Otherwise it is like opening the tellnet port and only allowing connects if you give the correct passwords. (With the addional feature that writing telnet-daemons is streight-forward, so that you are not so likely to implement buffer overruns...)
I was about to post the exact same thing. You people can be such insufferable whiners sometimes...
Did anyone get to the site before it got slashdotted? I'm guessing 20,000 knocks at port 80 in under 5 seconds isn't the entry.
Don't automatic garage doors rotate the frequency they use to open the doors, to prevent simple scanning (which would be analogous to sniffing in this case)? I could see where this idea could be used in combination with a lot of other ideas (Port Sentry) to make it a far less trivial task to find an open port on a machine. The reason script kiddies are successful and abundant is because its cheap and easy, this might not keep someone determined out, but it actually makes it a lot more work for the lazy intruder.
-G
"Immolation is the sincerest form of flattery."
the 'hammer' will have a different IP than the authorized 'knocker'
every day http://en.wikipedia.org/wiki/Special:Random
Wouldn't he have had to hack a computer closer to his target in order to be successful?
Wouldn't the best option be to have some type of SecurID based password in order to access the port? Unless there is a bug or hole in the software isn't a randomly changing password that requires a pin about as good as it gets?
And as they say, Security through obscurity isn't.
"Thanks to the remote control I have the attention span of a gerbil."
Unless you open all ports on the firewall, at which point why have a firewall?
Or am I wrong?
There was a good response about your network being sniffed and you could get the knocking sequence, but maybe the knocking sequence could also be changed regularly and you get a key that somehow deciphers what knock sequence to use on what given day or whatever.
I've never implemented anything like that, so that's just a general idea. You can see what I'm saying -- yet ANOTHER layer somehow that changes.
Berto
Although people are right in saying that packet sniffing can easily defeat this, I think it still improves security.
It leaves the impression that the machine has no ports open, so script kiddies will leave you alone. Also, an attacker can't just exploit a server bug to crack the system without also being in a suitable location to packet sniff the knock combination to get the port open in the first place.
Homme petit d'homme petit, s'attend, n'avale
Don't just open the ports on which remote clients are to knock. Open a whole range of ports--say, a couple thousand. Then an attacker won't (easily) be able to try all the possible knock sequences.
Gates' Law: Every 18 months, the speed of software halves.
Most, if not all, ethernet chips have a promiscuous mode. Normally they are configured to ignore all packets with a destination address other than theirs. But they have a promiscuous mode where they capture all packets.
It is trivial to capture other packets on the same ethernet.
Infuriate left and right
Interesting concept... I thought of this 2 years ago and I'm now kicking myself in the balls for not acting on it! (not literally)
In my version of "port knocking", everything was going to be controled via ICMP echo packets.. aka "ping".
A single Ping packet can contain arbitrary data of an arbitrary length less than 64k. Through a config file, the system admin could define ping sequences using time, data, and/or packet size, along with a specified script to execute on each successful reception of the ping sequence.
Then, remotely, people who know the ping sequences could use almost any available ping utility on any machine to open remote ports, etc.
The concept of executing a script, rather than opening or closing ports, allows for more flexibility. Not only can the admin open and close ports via scripts, but could do other useful things.
Skiers and Riders -- http://www.snowjournal.com
I think this whole idea is a cool technique. It isn't the same as security through obscurity because the security still relies in a key. It is more like "network protocol steganography" actually.
---------
Create a WAP server now
I didn't RTFA, so maybe this was already covered.
This doesn't seem like it would help in the case of a man in the middle attack. The knock sequence would show up along with the rest of the sniffed traffic, right?
There are some people that if they don't know, you can't tell 'em.
I did this forever ago and it was a helluva lot easier than the above hack. You just make a 3 line perl cgi on your website somewhere that accepts a password and a note. When the user puts in the right password you puts their host at the end of /etc/hosts.allow file you let them in. Duh... Now that was easy.
How can this ingenious troll produce this high-value crapflood data?
Well, my friend, it is actually quite easy.
Open your favourite editor, which is of course vim.
That's all, faggots!
just get xinetd to dispatch a bunch of bash scripts when you connect to a port. hook up some scripts together, and get them to launch the ssh server when done in the right sequence. i also use that to shutdown my local serverbox just by telnetting to a certain port on it.
so many people are in a fuss about how insecure this is. Gansters have been using secret knocks+password for ages to get into their hideouts.
"knock, pause, knock knock, pause, knock"
"what's the password?"
"new england clam chowder"
perl -e '$_="\007/4`\cp%2,".chr(127);s/./"\"\\c$&\""/gees
Axl Rose:
Hey, hey hey hey
Knock Knock Knockin' on Heaven's Port....
Looks like the secret knock for this site was just hitting port 80 a few hundred thousand times.
Two-Bits
Which, of course, is the same way you'd get them the encryption keys in the first place. If you're going to that much trouble but still risk exposing your keys through distribution to users, why not just add a few more bits to your keys.
Unless, of course, each "knock" was a SSH session with a unique key, each of which was preceded by eight nonecrypted knocks on other ports...
I love recursion.
"Prepare for the worst - hope for the best."
Actually in most configurations this could be detected by looking at the returned packets. The firewall protecting the network would generally block all the ports except those involved in the 'knocking' so these would return nothing (assuming a drop rule is in place), the closed ports could then be detected by observing the RST packet sent when they are probed. This could be trivially done with nmap. The other likely configuration is that firewall shows all unused ports as closed, in this case you can detect which ones were closed by the firewall and which ones were closed by the machine behind it by the difference in the TTL field of the returned packet.
The one situation where this technique could work is where a host is directly on the network and has no firewall. A very bad idea.
From what I can tell, this is still vulnerable to a replay attack. The examples shown would also be relatively easy to brute-force.
I agree with the parent post in that this is a good layer of defense against random port-scanning. My question is how much better is it than simply moving your services to non-standard ports?
I thought about using this scheme to mask the SSH port when I realized that the reason I have the server is because I'm running a website on it...
Next method please.
Is portknocking computationally cheaper than SSL? Or some other authentication over LDAP?
--
make install -not war
While knocking, you could also try other ports to confound anyone how might be trying to sniff the sequence. If the sequence is 2347 92347 239 234098 , then throw in a few 43588, 2394, 2349. If the 'doorman' is looking for 2347 - $junk_data - 92347 - $junk_data - 239 - $junk_data - 234098 ,m you can even repeat some of the ports that it's looking for in other parts of the string.
Computers are useless. They can only give you answers.
-- Pablo Picasso
I know I have to ask this but does anyone have a patent on this yet???
If not I bet one from Microsoft, SCO or some lawyer was just filed.
Evolution or ID?
Port knocking would help defeat a virus that spreads by exploiting unpatched or 0-day expoitss running on ports that need to be exposed.
This would allow you to let in legitimate traffic while holding back a virus trying to exploit port 1434. It wouldn't matter how long Microsoft took to write a patch. The number of request from a virus slowing down the network is another story.
By most people's definition, RSA is "security through obsurity" - all you need is the proper key, and you bust the code. Unfortunately, to bust a 1024-bit key, there's a lot of possible codes. This system provides security through obscurity (the key being the obscure part.)
Disregarding any way to step around the system, this seems secure. Let's say we can use 5 ports to knock, and these are between 1000-9999. That's 9000 different ports. That gives us 9000*8999*8998*8997*8996 = 58,983,415,510,950,216,000 ~= 2^66
different ways to have a secret knock. Now this is not that great, but I would guess (here's where I might be wrong) that it has the around the same strength as a 128-bit RSA key, since you only need to divide the key by sqrt(2^128)=2^64 numbers to break it.
I mean, not to mention a sysadmin might notice 2^66 * 5 port accesses. Now, that's only 5 ports; the number of ports "knocked" could be much greater, increasing the amount of security. In fact the example in the posting uses 7.
--Stephen
Did you ever notice that *nix doesn't even cover Linux?
before the port knocking would be turned into smaller codes, like:
88,0,24,0,103,0,2760,0,667,0,22
which would mean: knock on port 88, wait a second, knock on port 24, wait a second, knock on port 103, wait a second, knock on port 2760, wait a second, knock on port 667,wait a second, and try to access port 22.
Then somebody would turn that into a string, and bing!, you had a secondary password.
Ostiary is a program that can protect OpenSSH in a similar way to port knocking. It allows for secure remote script execution. It was written by a member of MDLUG.
... don't come knockin'
Sorry. I've had very little sleep.
Let's say the correct squence is ports 2000, 2002, 2004. You could add a check that says if there is a knock on port 2001 or 2003 then this guy is locked out for a while.
GET YOUR WEAPONS READY! --DR.LIGHT
Only use the knocking sequence (call it a key) once. So that if someone is watching the network and try to repeat the key, the port will not open.
Be Free: Free Software Tuition
on debian-security a couple of months back.
Anyway, one of the biggest problems is failure rate. If that "secret knock" fails unless you correctly use the appropriate sequence of knocks, then anyone malicious can implement a trivial denial-of-service attack just by constantly hitting random ports, preventing any knock completion.
Alternatively, if you ignore non-knockable ports, or ports that aren't part of the knock, then you've dramatically whittled down the strength of your virtual password, and made it that much easier to brute-force.
Perhaps this would deter some of the lowest levels of sk|21p7 |<1dd13z from getting in, but that would be true only for about two weeks, whereupon new toyz are released that automate these attacks, and you've given the black hats one more weapon (DoS through spoofed noise packets) in the meantime.
I guess if you really, really wanted to do this, you could have a single accessible port that would listen for access, and then receive an encrypted key that determines which other port your server opens for a possible connection. But basically all you're doing then is adding on another layer of password protection, whose effect will be circumvented when somebody finally decides it's annoying to have to login twice or enter multiple passwords, and sets them both to the same thing, on auto-login, then leaves his laptop sitting around for three minutes. And you've still not fixed the sniffing problem. There are bigger security soft spots to be addressed than trivially hiding access to your ssh port.
Freedom isn't free; its price is the well-being of others.
Seems like you could instead make a simple UDP ping-pong protocol (obviously with some encryption involved) that would let you set up arbitrary temporary NAT redirections. If such a thing were optionally available for those little firewall boxes from Linksys, Netgear, et al, it would make my life a lot easier (for when I need to VNC into my parent's machine to help them out, for instance).
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
When this port's a rockin' don't come a knockin'!
You may now commence your groaning 8)
This method is already used by the proof-of-concept linux backdoor cd00r, written in 2000.
Nope... ethereal will just list the ports one after the other with all the connections. Are we opening TCP ports to every one of these ports... that is a lot of overhead to establish a tcp connection... Not to mention that each one of these ports will have to have its own queue to manage connections and what happens if you have 30 users trying to connect to the so called "knocking" at a time. Race Condition anyone?
So the question is... what advantage does this give to the server. The only thing I can think of is that 2 week old script kiddie has to work a lil harder to telnet to your mail server and do a 'vrfy' on an account. Other than that... It requires special applications and becomes an administrators nightmare(oh... I can't get it... or... even worse... DOS attack keeps you from even making it to the ssh port).
it seems there already is a bunch of specialists working on it - well experienced in knocking the 80th one. Wish they open the door one day, though.
#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.
Jon Katz and George Michael may do it, but leave Rob alone.
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
site up
knock 80
knock 80
knock 80
site down
Why screw with some complicated method? Just say "To access my SSH port, first send a UDP datagram to port $foo containing this data [list]".
Since you cannot tell if anybody received a UDP datagram or not, you can then have the stealth advantages of not having a TCP port open until the UDP packet comes in.
And if you require the UDP packet to be a time-stamped message, signed with a keypair, you can protect yourself against replay attacks and such.
www.eFax.com are spammers
i've been running SSH on a nonstandard port with this in the way:
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...
Keep your packets off my GNU/Girlfriend!
NASA finds bunny on Mars...
Yes, really...
http://www.rense.com/general48/stransge.htm
two bits.
Seriously though, isn't this just akin to the real world where you don't open the door unless they know the secret knock?
what i do, is set to log all packets coming to 10 different ports. log packets also to 20 other ports. those 10 special ports have to be attempted in a specific order, and the 20 extra ones are there to block access to a host.
/var/log/messages for the 10 special ports. Is all 20 of the "trick" ports there? Are they from the same IP address? If so, deny all tcp connections to that host. Are the 10 special ports there? In the right order? Ok, open up port 34345 (random port, not the same I use) to port 22 on the ssh box I use to gain access to the rest of my network (only open it for the IP address which knocked right). This is very secure, and damn hard to find, as any connections to the 20 ports ensure that the bad guys get blocked from that IP address forever.
a perl script runs in the background, checks
More secure than say, having the SSH server just listening on a given port.
If done correctly I would assume that the port would only open for the IP that issued the knock. TCP Wrappers has been limiting ports based on rules for years, adding secret knock functionality, especially if you have Wrappers listening on all your ports would probably not be that difficult.
Because instead of running the port open ALL THE TIME TO THE ENTIRE WORLD, it is only open for a short time to the address that correctly knocked.
Which means that someone attacking your system has to have compromised your upstream so they can sniff your traffic.
Looks like we knocked the crap out of port 80 on the article. Anyone have the text?
"Ain't I a stinka..." - Bugs
All security, in the end, is security through obscurity. Noobs are the ones claiming that obscurity won't work.
In the end, what is the goal of security - to protect the data being stored or presented. Now, protection against a DoS maybe won't fall into this category, since that is just basic load balancing and testing. Everything else, though, requires enforcing the principle of least access.
to enforce that principle, you have to limit the availability of accounts that are privileged to do things you don't want done. Now, that is handled through password, multiple factor authentication, encryption etc. But all of those are predicated on the attacker not knowing what precise string is the equivalent of the old "Open Sesame".
Patching? Chrooting? Hardening? all of those boil down to an attempt to make the attacker who wants to haxor something enter in through the appropriate channels (VPN to the backend and SSH in, open the door and sit at a keyboard, etc) and, o enter through those channels, he must know something that is not available (password, numebr being displayed on a SecurID token, key shape, etc).
Security is all about preserving obscurity. Nothing more, nothing less.
This is a great way to keep an open server running and not get busted by your ISP. Only problem with me is my employer's firewall only allows certain ports to pass thru. This is what I'm going to do:
1. Run SSH on one of few ports that will pass thru employer's firewall.
2. Have iptables allow inbound from my employer's netblock.
3. Have portknocking set up for any other connections.
4. Block anything else.
- There is no reason to ignore reserved ports. For this scheme, any closed port is usable. So the "alphabet" is 2^16 - the number of open ports on the box.
- It could as easily be a 50 letter password if you wanted.
- The feedback mechanism is so slow (network) that even a short sequence would take a long time. Suppose there were 100000 possible combinations (this is way low). Suppose it takes 5 seconds to check each (this is probably the fastest realistic time). That's almost 6 days of brute force effort.
- Brute forcing this would be incredibly noisy.
- Once you get through this, you still have to get through ssh.
The upshot of this is that you can have a sequence which is stronger (from a brute force perspective) than an 8 character ascii password. Still, this does look more promising for clandestine activity than it does for additional security..sig: file not found
A secret website! you need to do port knocking to access my secret website. Nuh nuh! i wont tell you the right port knocking password! *run away cackling*
you could get even fancier and have your knock ports listen for particular packet types (first port listens for TCP, second port listens for UDP, etc...). That'll bump that stat up even higher.
First off, I don't think this is security by obscurity. This is just another layer of communications like a handshake is to modems and faxes. Security by obscurity would be a rolling port that was say 22 from 6-9am, 25 from 9-12pm, 31 from time x to time y and so forth. Or perhaps they would give you a randomizer seed set at a January 1st, 12:00am of that year and you run the seed through X times where X is the number of hours since January 1st 12:00am. Even changing the port from 22 to 44 is security by obscurity.
That being said, what's the next application of this? HTTP? Port 80 only if 1337 was hit before. That could be how Slashdot subscribers could login... now that's 1337.
---- The geek shall inherit the Earth.
Excuse me, with SSH and/or GPG we are dealing with 1024-bit keys today (which is just an example, not a maximum limitation).
How 16-bit key can be more secure than 1024-bit key?
The is negative. Noway 16-bit security can be stronger than 1024-bit one. It's against the theory of information, which is not proved false yet.
I know why somepeople will love such nocking security - because it's through obscurity. People without math in brains often prefer security through obscurity. And always fail.
Don't repeat their mistakes!
Less is more !
I wrote proof of concept code for this a few years ago. Mine is implemented as modified network sniffer code (with promisc disabled), so it doesn't require any weird firewall configs. I was considering some other things which could be useful, such as transmitting data via a fake network scan.
It does have an open port. The client connects, and gets 16 bytes (sizeof(md5 hash)) as a salt. It then hashes this using HMAC-MD5 with a secret password, and sends the result (16 bytes) back. Fixed-length data all the way, essentially zero chance of buffer overruns. Essentially impossible to crack, except for dictionary attacks. So low-resource it runs fine on my Mac SE/30 webserver.
I call it Ostiary (mirror here) and I think it's damn secure.
There'll be a Linux Gazette article about it this month (Feb) when it comes out.
PHEM - party like it's 1997-2003!
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.
just set up a continuous connection attempt on port 22, and when soemone else knocks that special knock, you're in.
...implementation? Basically, SecureID works through time synchronization on a physical device (usually a credit card looking device with an LCD display, or a keychain fob) and your user ID.
In a nutshell, what they do is make a passcode based on an algorithm using the current time, plus your user ID. When you attempt to log in, the server has generated the same passcode for your user ID due to the time being synched. In practice, this has shown to be pretty secure.
So, you have two versions of the software, one on the remote machine to generate the sequence of ports to be "knocked" on, and the server side which uses the same algorithm to listen on those ports. You could have it change at whatever time interval you like, but would add another layer of security on top!
Vidi Vici Veni
That's not usually a security feature per se. That is, such broadcasts can still be followed, it's just not as easy as it has been with conventional scanners.
It's also used to help use the spectrum more efficiently, rathter than as a security mechanism.
I should know, I have an amature radio license...
person with the knock and whamo you know it. Chances are the lamo that uses this isnt going to
change the knock.. not ever (as he will prolly hard code the knock into his client app). So once
you have the knock bam your done.. now just break his password..
Security through obuscurity never works.
.. whos there ?
.. ?
SSH
SSH who
Can anyone say "Replay Attack"? This is "secure" untill you use it. No better then a password, really. What's next, a cool feature in knock_proxy to implement a password to knocking-sequence pairing?
This has been around for years
superman runs linux
Use an OTKS to open the port for a specific user, perhaps, and then expire that sequence, as with a one-time password?
I'll shut up about it now, though, since I can't even get OPIE running right on my FreeBSD box.
NB: YMMV. IANAL. Take the above with a grain of salt.
Reminds me of xringd for dialup connections. Call the modem's phone #, let it ring the correct number of times, do it the proper number of times (iirc), and then hang up. The modem will dial the pre-set number. cool!
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!
Many here have posted about how the complexity of the "knocking" challenges could be significantly advanced that it would be hard to brute force. Well, this is good and everything, but you have to consider that if you are on a high-traffic site, you don't want the server side to have to be spending a whole lot of resources on determining whether or not a constant stream of incoming SYNs are part of a "knocking" sequence.
I imagine if this caught on there'd be technology to offload this burden onto, but until then it could be hairy for a site trying to do this with a complex challenge and a lot of incoming requests.
dmiessler.com -- grep understanding knowledge
So what you're saying is...If Jim knocks and gets the open door...the door really only looks open to him. Everyone else sees it as closed (based on his IP address or something).
Is it based on IP address? What if he's coming through a NAT at a college campus, lets say. Can I get at the open door if I'm on the campus too after he knocks?
This means you might as well set up your systems however you want, with regard to what services are on what port. But the services still answer the standard way. To get around this, what if all services had an easy way to change their inital behavior, e.g. accepted an optional plug-in or personality module front?
The plug-in would be some code/script that follows an api that runs a little challenge-response game of the creator's desire.
This user (admin) definable "hand-shake" could range from nothing (i.e. standard service as it is today) to something as simple as Service: I will act "standard" after I see the word "please" or as complicated as the plug-in writer wants to get [strong crypto, multi pass challange/response, hardware key tie-in, etc.
The trick is to make sure plug-in [port listener] is secure - since this would be the object to be attacked. [rather than the current services].
Basically, as has been noted, security thru obscurity, but "standardized" in such a way that it is easier to do, and therefore might get done more often. [but it occurs to me that those who care are already doing something...]
I guess I just described a meta-service, huh? Then all your security eggs would be in one basket.
If this is a patentable idea, send me money, thanks.
This issue is a bit more complicated than you think.
Mine listens for 2,546,782 simultanaeous connections to port 80 within 10 seconds, then it opens up the back door.
Try it at:
http://slashdot-this.org
Is to simply use some iptables rules to only allow ssh connections from where you expect them from. For example, if you have live servers colocated somewhere then only allow connections from the ip block of your office.
iptables -A INPUT -i eth0 -p tcp -s \! ip.of.off.ice --dport 22 -j DROP
Excellent description.
but still really big.
Require syns to ports A, B, C, and D, which opens port E where you have to send a password, which opens port F from which you must do an HTTP GET for /foobar.html, which opens ports G which when connected sends you the number of random port H, on which an anonymous FTP service is now running to which you must send a SITE STARTIT command then download the number of port I, which will be the SSH service once you've pinged the server 7 times with 42 byte packets. And to make it really challenging, you have maybe 10 seconds to complete the sequence. (Think a lot of terminals just waiting for you to hit 'enter'... The pings would take most of the time.)
Oh, and if you do anything wrong after the first 3 ports are hit, you can't try again for 30 seconds.
You have to call a modem connected to the server. The number of rings defines whose login gets rewritten from /bin/false to their real shell (/usr/bin/perl!). There is a five minute window at this point for this user to log in using ssh.
Does anyone even know what I'm talking about? :)
Power corrupts. PowerPoint corrupts absolutely. E. Tufte
Everyone has focused on the "does it make you more secure" arguments about this method. I'd be more interested in how it can be implemented properly since no TCP connection is being established using the knocks. I'd assume either a TCP SYN is being sent to the TCP ports, or the protocol uses UDP.
.9^10, or 35% chance of my sequence getting to its destination intact. 5% packet loss would up my chances to about 60%. Increasing amounts of knocks decreases my chances of the sequence arriving intact.
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?
AccountKiller
It's about blocking the gain of simple portscanners.. but I'd rather see a OpenBSD style system for linux, login via ssh and it allows you modified firewall rules to gain access to other systems, login securely then you can use IMAP/POP/etc.
So if I just randomly attempt to connect to ports on your computer, you'll never be able to connect?
Unless you correlate the knocks with an IP address. Is that what they do? Maybe I should read the article/code...
Old news. Very old news. Memories of the 90s come about.
on port 80....You're Slashdotted...
sure you cannot sniff ssh, but you can monitor the connections and log them ..... ... you just do the same ...
:)
connect to 2038, 6664, 5552,5543 and so on
of coz you gotta be on the same net (or sniffing on/near a router on the way)
if you change the nocking sequence every time based on whatewer algorythm, it is much harder unless someone knows the algo
Because, with this method, a scanner might not see anything there.
No large concrete block to even indicate that something might be there.
Just a featureless plain. You don't even know if there is something interesting there. You don't even know if there is ANYTHING there.
Statistically, you'd more often be trying secret passwords where there wasn't even a server to hear you.
I see a lot of comments saying "Well, why not just have two passwords?". It seems that people didn't read the article (the first link is /.ed, the second is not). The whole point is that with this, until you knock, the machine appears as a closed machine. No ports open. All ports will simply drop packets on the floor, meaning that a hacker scanning your subnet will not bother with that machine. The machine essentially appears invisible until knocked. Even with the most secure system, the hacker can still see that you're running, say, sshd, Apache, CUPS, and a few other services. And if a buffer overflow was announced 5 minutes ago for, say, sshd, they know that they can attempt to exploit the machine, since they see port 22 open. If you are using Port Knocking, you can have a vulnerable sshd, and it's a hell of a lot less likely to get exploited since the cracker has no way of knowing that you're running sshd...
There is no sig, there is only Zuul.
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.
I can... you packet-sniff while someone's going through their knock and just follow the port sequence. Once you get the magic knock, you're once step closer to getting through the door. Now with hundreds of people connecting at once, you'll just have to organize your packet-sniffing log by source, port, and time (just to make sure you do it fast enough). This just gives the script kiddies something else to look for with their scripts.
"The best laid plans of mice and men gang oft agley..." - ROBERT BURNS
In general, security through obscurity is a waste of time. Similar to moving your "secret" webserver up to port 8888, it may buy you a *tiny* bit of "security" by being slightly tougher to find, but these types of configs don't fundamentally improve your overall security.
/. posts.
My biggest fear when I hear of these stories is that your typical sys-admin will spend 4 days implementing secret-knock perl scripts and then return to the life of surfing pr0n, ignoring log files, applying patches once a quarter, and writing long-winded
This one gang kept wanting me to join cause I'm pretty good with a bo staff.
Yes, all secrecy is obscurity in some sense, but there is an important distinction to be made between two types of obscurity. The fact that a port knocking scheme consisting of, say, 10 knocks is being used is one peice of information that someone would have to know in order to be allowed in. What the sequence of ports to knock on *actually is* is a second peice of information. These two peices of information are of very different types. What is the chance that the first peice of info can be guessed? Impossible to say. What is the chance of guessing the second? Simple. It's one over the number of ways of choosing 10 ports from the set of all ports. (NumPorts!/(NumPorts - 10)!) The security provided by the obscurity of the first peice of info is unquantifiable. This is what is typically call 'Security through Obscurity'. The security provided by the the actual password (or whatever you want to call it) is a calculable, knowable quantity. This is real, scientific Security, as opposed to just having a feeling that it is 'unlikely' that someone will guess you are using port knocking, or whatever.
Have an incorrect knock give them the goatse guy. That'll learn 'em!
In soviet russia, ports knock on you!
...it's already /.ed. Congrats;)
I have discovered a truly remarkable sig which this 120 chars is too small to contain.
A password doesn't have to be a series of upper/lower/ascii characters that do not form a word. It can be something like a bird call or a series of "knocks" as in this method. Is this useful? It certainly adds complexity to the attacker's problem. Instead of blindingly hitting a target, they'd need to do some kind of man-in-the middle attack to determine what this UNENCRYPTED password is.
A better approach is to abandon this kind of cleverness and never use the word "Password" again. A passphrase that's greater than 14 characters is far superior to any obfuscation or password complexity. It beats shoulder surfing, you can't bruteforce it and you're unlikely to find the right combination of words in a dictionary for every random human being in this world. Stop the password madness! Evolve ye damn slashdotters!
That's not my passphrase, I swear.
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.
The first point to make is this is no different, in terms of the resources required to perform such a DOS, as the situation is currently. This is a non-issue because it's already an issue with or without knocking.
There are all sorts of tricks to use that would keep the knocking daemon from chewing up memory such as any invalid knocking attempt makes the daemon sleep for X seconds. Or only the last 5 IP addresses that tried to knock have their knocking history recorded, so only a minimal memory footprint is made by the knocking daemon.
Second point, someone has to know enough that a knocking daemon is on a particular machine before they can start brute-forcing it. Otherwise an attacker would be required to try and brute force knock every server online. Care to think of the logistics of that?
Also, if no ports are accessible without knocking, a machine with a knocking daemon is going to appear to be dead. Why would someone "brute-knock" a dead IP address?
Don't let root login via ssh and use key exchange for autentication. Who needs another secret handshake?
Switched networks will only work if you ahve good physical security and vlans implemented. Otherwise Captain Blackhat is coming onto your campus with a MAC spoofer and will have this beat in no time.
the problem is, you would have to enable the clients (ssh, ftp (which means for instance dreamweaver's ftp code) etc..) to use it on a public system. and the public systems (i.e. webservers) are the systems we need this on, because they are the targets of the crackers..
so, good idea, but will it ever happen?
but IF it happened, i could think of methods to use it like we use passwords today. translate the knocks into letters and these build a password, a meta-passowrd in this sense..
sounds cool to me..
PAT
SEO Test: TIGI und SEBASTIAN - Online Shop - V
It should be "Shave and a Haircut, 2 Bits"
Does this remind anyone of Close Encounters if there was some musical visual interface to manually select the port numbers/sequence?
*shrug*
e.
Build Your Own PVR/HTPC news, reviews, &
Or, if the the door leads a massive mine/homeland built by dwaves, one could make it visible only in moonlight, and inscribe the password as a riddle in Elvish. A suspicious person might try numerous spells of opening before realizing that the obvious equivalent of username:admin password:secret is the key.
I'm sure this bad computer analogy could be extended, but I'll stop now.
Come and knock on our ports,
we've been waiting for you.
Cuz this port is hers and hers and his, this port knock's for you!!!!!
You said "port knocking".
I've read some people saying that a malicious user could simply sniff the network and determine the key. I don't see this as a major problem, though. You could set each machine to have its own individual knock, requiring an attacker to also spoof a machine who's knock he's discovered. Again, this could be complicated by having some sort of function that defines legal knocks, but that generates so many that each knock can only be used once...a sort of one-time pad for the knocks. This would assume that you have a secure method of trading the knock lists (flashback to Mission: Impossible's "NOC-list"...heh). I'm sure there's some sort of encryption scheme you could setup based on the time that keeps a sniffed knock from being able to be used again, but that can also be dynamically generated by any machine attempting to connect to the server. I think this assumes a little bit about the topology of the network. I'm sure it could be tweaked for most setups, though.
...here you go:
~/bin/gensig.pl
The funny thing is, why open up ports in a general fashion? Why not just open up those ports to connections from the IP that knocked?
tasks(723) drafts(105) languages(484) examples(29106)
All the "sniff and replay" comments here are missing the point. Of course if you just set it up so that a knock on ports "5432 2272 8787 3456 ..." (of whatever length) could easily just be sniffed and replayed. Thats trivial.
;-)
However, imagine if you implemented it with an algorithm on the server (or NAT/firewall box) that used a "password" seed, in combination with something temporal (like today's date and the current hour. Or even better, something even more obscure like yesterday's closing price of MSFT...) in order to generate the specific sequence of ports using a cryptographically secure hash method. Then when you want to (say) open port 22 on the firewall (only for the IP you are connecting from of course), you use a little client program (that you carry around on your USB memory key or whatever) and the password to generate the knock sequence to use on the fly.
As the referenced site mentions, this was discussed and even implemented in a very nice Sysadmin article some months ago. Without access to the "knock sequence password" AND the details of the specific algorithm in use, I cant imagine ANY way of brute forcing it.
Obscure AND secure. Even better.
...it's more like plain-text-auth:
you submit a 5x16 bit password (4 knocks in a 16-bit range of ports plus the actual connect to the correct port). By forcing a 1sec delay between knock-sequences, one would need 2^80 seconds to brute-force it... that's 28334786263782000 Years if i didn't mess up. You can add some more bits by including the TCP-Flags required to be set for knock-packets, etc...
However, anyone sniffing your traffic could find out in a snap.
And no, it's not revolutionarry. But its nifty!
I have discovered a truly remarkable sig which this 120 chars is too small to contain.
this is not just security through obscurity. this is also more/different key.
two ways to get 0wn3d r:
1) they know your key.
2) they know how to not need your key.
there is some obscurity to this, but if instead of closing the "knock" ports, you instead replied with "successfully knocked on port 9834" (for all your unused ports), and sent them a link to this article, you still have gained extra key bits.
In the face of (2), however, you are much better off. They have to be clever enough to defeat your sshd and the knock protocol at the same time.
I'm thinking diffie-helman carried out using the port numbers that you try to hit as the transmission channel could be kind of cool. not sure if it useful, but it would be cool.
Would there be an advantage to using a modified sniffer agent on the firewall to detect the sequence?
I think we need a new mod code. -1 grammar. You'd get a -2 grammar for consistent misuse of the word then.
This is a pretty poor shared secret. For one, it can easily fall prey to a simple replay attack. If you're going to turn away connections based upon them not knowing the secret handshake, you'd be better off incorporating some sort of challenge-response directly into the TCP connection handshake instead, wouldn't you?
Sticking a small cryptographically hashed payload onto the SYN, SYN_ACK and ACK packets would seem to give you better security.
Just because it works, doesn't mean it isn't broken.
"open port Y for ip Z using key K"
if the port opening policy accepts this command then it is opened otherwise it is not. Better yet 'REAL' crypto could be used to protect the ports. Fore example...
"open port Y for ip Z @ TIMESTAMP" Encrypted by K.
This simpler implementation (more likely to be correct) will provide equivalent security.
So after n unsuccessful knock sequence attempts from a particular IP, you start to ignore the IP. So you might get slammed for a while, but after a while the machine would wise up.
;-)
Kinda like a secret club, except you know who's on the other side of the door!
Stevie Ray Vaughan's lost single
"Well...The port is a rockin' don't bother knockin'
Yeah...The port is a rockin' don't bother knockin'
Yeah...The port is a rockin' don't bother come on in"
DOS = Denial of Spirits?
Though in deference, the FBI didn't so much knock as kick the darn door in.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
This is a great way to hinder people from randomly picking to hack your box by scanning for open ports. However, if someone is dedicated to hack YOU specifically, they could still use a man-in-the-middle attack, sniff the packets to see which port sequence you were using, etc, etc.
Of course, there really is no way to block a skilled hacker who is intent on breaking into a specific network/box by any means necessary.
I don't know if anyone has tried this. I haven't really researched it. But a friend and I implemented a rather interesting device based on the fact that when you connect to a webserver you send data first. If you are connecting to ssh you wait for the server to init the conversation. So bascially when you connect to the port if you imediatly send it forwards you to the webserver, if you wait for a predetermined time it sends you to the ssh server. Very handy for getting around the companies policy of not allowing ssh inbound. I don't necessarily think this is secure, but to the casual observer the port will look and act like the a webserver. And it is out there if you care to try and find it :)
If this becomes common and there are lots of people trying to knock, you could send messages by knocking.
E.g. knocking at ports 99, 97, 116 could be the word cat.
Properly encrypted it would be hard to tell if you were knocking or communicating. Probably only useful for short messages though. Unless knocking was continuous to obfuscate when true knocking activity.
</tin foil hat>
It's unfortunate that the code there is only for ipchains and not iptables, which leaves many Linux users out in the dark...
I'm not cryptowise enough to know how to implement this, but since the goal is to foil portscanning, it's fair to assume that the attacker does not know a valid username on the machine. Suppose you built this into the ssh client, such that it would generate the portknock key as a one-way hash of your username? The server then has to check the portknock against valid knocks based on the login accounts on that machine. The whole process becomes entirely transparent to the user, while still utterly foiling portscans. Are we happy?
The more direct path would just be to add that username hash as the initial connect string, so the ssh server doesn't respond unless it's valid. That skips the whole complicated portknock thing, which is kind of clunky, as cool as it is.
Even with this knocking sequence in place, as long as you have 'knocked' and are connected to the host, the comptuer can still be port scanned.
The random # of ports is great, but the suggested timing limitations could be an added dimension to the security scheme. It was suggested that the combination should be received within a certain amount of time, or the sequence would be negated. There could be a min and max time limitation, say it could be required that the sequence finish within 3-5 seconds. This could slow any brute force attempts to a crawl even with a shorter combination of ports. If it were able to be even more specific the time between knocks could be measured... Think of it like "knock ... knock... knock-knock-knock... knock-knock."
First time I saw this implimented was about 95 on a BSDi system. The concept and availability of this isn't anything new. The first discussions I heard where in the late 80's, and those where stories about mainframe systems on ArpaNet. Talk about old news *grin* The perl implimentation my be new code but the methodology isn't for sure.
I'm sorry, I'm to tired to be witty at the moment so this message will have to do.
No, I am teh winner!!11~~
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).
Not a cure all, but every little bit helps.
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
This is stupid. Why not just send some little blurb of out-of-band data 'open-says-me'. Why go through the whole sequence? Even a benign looking sequence of HTTP requests would be better.
The man in the middle can sniff the port knocking and replay it just as easily (ok, much easier) than the actual mitm attack itself. All this does is make douches who are too fucking stupid to learn what "security" means feel smart. If someone is dedicating the time and resources to attacking you specifically, this is useless. If you are just trying to protect yourself from script kiddies scanning vulnerable daemons to 0wnz, then just patch your machines. Wow, that was tough.
What if you were to set the port knock up so that you had to connect from different known ipaddresses in the same knock sequence instead of just someone knocking from one? I would help a bit, kind of like the secure submarine communication system where you used the echoes created by the presence of the water to basically encrypt your message. Anyway just a thought.
There is a slightly different implementation of Martin Krzywinski's port-knocking idea available at: http://doorman.sourceforge.net
--- There is no bun but Bun, and Fuzzy is His prophet! Bunbun akbar! ---
I like an idea posted earlier of using a single port to knock on, that looks for a certain key signature in the first packet. This can be sniffed more easily than a port-knocking sequence, but...
If you don't have too many users on a system, you could use a key sequence. Each user would be given a key generator, which generates a near-infinite number of keys in a certain sequence. The host system would be looking for a particular key, and its matching key generator would then advance once it's been used.
This system would have to be used with a single-port type of access because a client requires a simple (trinary) response from the server. The response can be either "used already", "wrong", or "right". The client then tries keys in turn until it receives the "unused" signal, at which point it connects on the desired port. If there were a lot of active users of the system, this process might take some time. If the only server responses were "used already" or "unused" (wrong or right), then a client could get permanently off track if packets were lost because it would not know that it went beyond the sequence.
This system might still have problems with simultaneous logins. And it is "opening up" an additional port. But I can't think of any way that the knocking port alone could be used for a remote exploit. One could also abuse this system if one could selectively block transmissions both ways. I don't know if that's possible or not.
Its just adding another layer that can get broken. This is not in the spirit of keeping it simple stupid...
Of course keeping a port closed is assuming the daemon behind it is insecure. Keep a secure daemon and thats far simpler than a port-knocking structure in the kernel.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
here is why. the first point of entry or attack for ANY attack HAS to be either a) a port scan to find running services, or b) a network sniff of your traffic to find traffic related to running services. The latter (b) is much more difficult than the former (a) due to having to 0wn an uplevel device in your traffic stream to sniff your traffic. Also, with the popularity of switched networks, sniffing is more and more difficult. Since B is much more difficult than A, A is the initial point of attack for most attackers. This method eliminates A as an initial point of attack, but ONLY FOR PRIVATE SERVICES like SSH. In the case of a paranoid techie (us) who wants NO services exposed, this is a nice way to hide our SSH sessions. However, in reality it is only marginally more secure than using a pub/priv keypair for SSH.
Actually this has been covered on LinuxSecurity a while ago. And the implementation is apparently usable.
Sure, while you don't have a guarantee that the packets arrived or the order in which they do, the truth is that in a real world situation most packets will arive and will arive in the proper order, particularly if they are sent with delays in the order of several hundred milliseconnds or more (that is, several tenths of a second or more). If somehow the knock doesn't go through, you knock again. If you still fail then you likely don't have a good enough connection for reliable use anyway. Obviously there might be some exceptions to this (like a web server connected to a cell phone), but in most cases dropped and out or order packets would not be an issue.
That said, I do agree with the post that made the point that anything that can be done by port knocking can generally be done better with information sent on a single port.
I'm an American. I love this country and the freedoms that we used to have.
Kris Gleason implemented a similar scheme in his gettyps code back in the 90s (it still available and in most distributions). For the "knock" one would dial into a modem (or any serial port) and let it ring a specified number of times. If the right number of rings was received before disconnect, gettyps would allow the next call to connect.
Michael.
Linux : Mac
The one positive I see for this tool is that the host would be invisible to most scanning tools as all ports are closed until the correct port sequence is sent... On the other hand, the fact that the port stays open until another port scan sequence is sent leads me to suspect that a dropped connection could leave it fully exposed anyway. So, is it worth the time and effort? I suspect not.
For every problem there is a solution that is simple, obvious and wrong.
use iptables -j REJECT <port-unreachable> on ssh.
Run a UDP server on a wierd port. To get in, send your current IP + timestamp signed with a RSA/DSA key. If the signature is incorrect, forge a port-unreachable packet back (so it looks like a closed port) If it's correct, reply with a signed challange using server-timestamp, requestor-timestamp and a random value. Requestor answers the chalange, and the server adds an allow rule to iptables.
This is safe from replay attacks, window-of-opportunity attacks (it only allows your host to the port, not everyone) but may be/probably is subject to MitM attacks. (Anyone along your route can watch you open the port, and after you succeed hijack your IP then attack SSH)
Still, that's infinitely better then a fixed cleartext password that opens the door to EVERYONE, which is all that the stupid "knock" is.
If you looked for knocking after a service is connected instead, and drop the connection if the followup knocks don't occur within a short time, it could really frustrate the script kiddies.
They get a connection, then immediately lose it. They then need to decide if it a network problem, a problem in their script, or something else? Might keep them busy trying to 'debug' their code for a while.
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
I recently wrote a test DDoS script that used sockets to communicate between the master and slaves. Portscanners (like nmap) never showed any open ports even when the socket script was running on the slaves... waiting for commands. I'm not an experienced, low-level network programmer, so I can't explain exactly how this works, just know what I saw... two programs exchanging commands through network sockets with no ports open.
Butthead: "Uhhhha, I am gonna emale you....in the butt.
Beavis: "Shutup! Port-knocker!
"The point the grandparent is making is that you shouldn't be running insecure services on a public interface to start with."
. ht ml
But you will never know whether any service is insecure or not. Even SSH has had vulnerabilities.
http://www.nwfusion.com/news/2003/0917certwarns
"Security through obscurity is never a good choice."
No, that isn't "security through obscurity". "Security through obscurity" refers to hiding how something is done, not the password (in this case, the knock sequence). The method for port knocking is known. What is not known is the password.
"The only thing a port knocking scheme is good for is for concealement -- hiding the fact from a port-scanner that a port is open."
It hides the fact that a service is running on the server by keeping the port closed until the password is issued. What's wrong with concealment? If they can't scan you, they probably won't try to attack you.
"This makes is much more valuable for grey-hat and black-hat scenerios than it does for legitimate purposes."
Rather, it makes it much easier and safer to remotely administer your machine than running that service with that port open.
"If all you want is secure remote access, a properly configured SSHD on port 22 is secure enough."
I've already shown that SSH has had vulnerabilities. You should not believe that SSH is secure.
What would happen if you knocked on every port within a certain range (like 100 at a time or something) simueltaneusly and knocked 10 times or something?
Good point, but it's important to remember that a port doesn't really exist, it's only an abstraction in the TCP/IP stack anyway. So if we are talking about a computer "actually connected directly to the Internet", it makes little difference if the secret handshake to access a service in a computer as accessed by an order of packets received with different port numbers, or with different packet types sent to the same port, or by any other identifying data in the packet.
With more and more devices behind NAT routers, this distinction does start to matter. Unless the router knows about the knocking, this system has problems that a single port system would not have. On the other hand, if port knocking (or any other sort of identifying handshaking) was built into the NAT router, it could do a great job of idetifying authorized users and switch them to the proper system on the local LAN, which could then run with common software that did not need to be programmed to deal with the knockers.
I'm an American. I love this country and the freedoms that we used to have.
see the rest of the details HERE
Error encountered in IAWebSig.clsSig.Create: Last Procedure: sPrc_Ins_tblSig
Okay, if it is insecure, how is it attacked?
"The only real use for this is hiding the existence of ssh, if for some reason that is important to you. After that you can use ssh to hide everything else, since that is effective against sniffing."
Or any other service that you don't want to be open to attack. Although running any other service through SSH would be a good idea.
If the knocking daemon 'goes to sleep' after invalid knocks, you're in bad shape. I wasn't saying it would be a DoS, I said it would be DoS-like. Basically, if you stop listening whenever someone gives the wrong knock, they can just keep knocking and you'll never be able to let anyone in.
G
Howdy, This is a weak authentication door in front of a (hopefully) strong authentication door. So why have the weak door? All your security resides in the strong door. Is there a cost savings for putting up the weak door to wead out the bulk of script kiddie/robot scans? Maybe it would make you less suceptible to DDOS attacks aimd at the strong door. But to put up the weak door, you are already conceeding that you are not 'popular'. So bottom line for me is ... I don't see a valid use case for this. But on the other hand, the world is a shockingly diverse place and maybe there is someone out there with a valid use case I just don't see.
I did this about 5 years ago. But my method was a bit different. Instead of using port numbers to contain the information (and that's all it really is, is just information), I sent a single UDP packet, with a source port of 53 (so it looks like a DNS answer), formatted like a DNS answer, that contained the information in the DNS answer data. Then it opened the SSH filter for that IP address to come in (I did it for 5 minutes, not 10 seconds). It still had to fully authenticate via SSH, so even if someone sniffed my DNS packet and tried to fake it, they could at most have a locked door to jiggle the handle on. Next time I do this, it will be to generate an MD5 checksum from the client IP and a secret salt, and send that as an IPv6 address in the packet. Then it can't even be faked from some other IP address.
now we need to go OSS in diesel cars
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.
Who's that knocking at my port,
Who's that knocking at my port,
Who's that knocking at my port?
It's Barnacle Bill the Hacker
http://cmn.listprojects.darklab.org/
works great so far...
This is a neat trick, but it does not really increase protection against targeted attacks.
It really is nothing more than a password to get access to the front gate... When somebody eavesdrops (sniffing), they will know the passwords, thus get access to the gate. They can sucessfully detect the knocking sequence because it is followed by a successfull ssh connection (duh!).
The password is this 'secret sequence' in this 'port knocking'. Why not just use a daemon that listens on a UDP socket for a packet with an encrypted password in its payload? The payload could even be an RSA-signed and/or encrypted request (that includes a timestamp). That would be unscannable too, because UDP is connectionless, and be a lot more secure because of the real encryption/protection of the request data (the server can verify the identity of the sender of the request from the RSA signature, and can deny the request if one was made earlier with the same time stamp, twarting even sniffing of the UDP packet).
Except for not having the ssh daemon 'connected' to the internet at all times and thus evading many port-scanning worms/scripts, this port knocking is nothing more than just some security through obscurity: At best it will delay the attacker somewhat, but probably not at all while giving the user a false sense of being secured.
--- Hindsight is 20/20, but walking backwards is not the answer.
I'm assuming a simple implementation of the knock protection here, but if one was to constantly knock at scattered ports and times on the targeted system, the system might not open the secret destination port to anyone, including legitimate users who are trying to get in at the time.
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.
...it's kind of a Rube-Goldberg device when there are robust IPSec and SSL implementations for just about every platform out there. For the infrequent connections mentioned in the article - server administration, employees submitting documents from unknown remote locations, etc. - the extra CPU overhead of IPSec or SSL wouldn't have a significant impact.
Of course, you could combine port knocking with packet- or session-encryption but if you've implemented that correctly then port knocking doesn't buy you much extra security IMO.
If we're going to write (new, secure) software to do this crap, then why not just write a (new, secure) piece of software that listens on all ports and acts as if all are open, but then kills (or ignores) any illegitimate actions.
If everybody runs it, then port scanning just goes away. Duh!
http://www.openbsd.org/faq/pf/authpf.html
Also available for Free- and NetBSD.
Brilliant for ie. IPsec + WLAN. This way, you use SSH to authenticate your IP. After that, you use a/multiple rule(s) whixh deliver additional functions like for example access to MySQL or IPsec. You keep the SSH tunnel open. After you're done, you close the SSH session. And after that, the/all rule(s) are removed again. It is just that, brilliant! And it works on all the 3 major BSD's too!
I think this "port knocking" feature is rather some lame, unsecure a-like of AuthPF. Not useful for whitehats. To me, it's rather some kiddie feature to hide some backdoor which listens on a port.
- The writeup of this article is horribly out of sync from what the page is actually saying. The method advocated is literally an encrypted message, being sent by attempting connections on closed ports. This message contains the IP of the computer which the user wants to allow access to. So no, you can't just sniff and repeat the sequence -- not only may the encrypted message be different every time, but it doesn't have your IP address in it anyway.
- There are all sorts of interesting layers which are suggested to add on top of this. For example -- having ports on which access attempts are ignored. Since the point of encryption is to make things look like noise, add some actual noise as well. Implemented properly (and with some fairly thorough theoretical grounding, one would hope), this is yet another layer of "password" -- knowing where the holes are. Even implemented incorrectly, it would take quite a number of sniffed legitimate connections before a cracker could properly infer where the holes are. A lot more secure than WEP =]
- In a nutshell -- port knocking adds several layers of "password" before you even get down to the services you're already currently trusting. And it is extremely difficult to detect that these even exist.
Here's where I see it falling down -- there's just way too many complicated "passwords" to conceivably remember. You've got your private key for encrypting your knock (the page talked a lot about one-time pads, though never gave any indication of how you would securely obtain such a thing remotely), you've got the allowable port ranges (was it 618-724,864-885,915-1012 or 619-724,864-885,915-1012? -- more "guessable" port ranges are more cryptographically vulnerable!) -- it's not like you're going to be able to use this to log in and check your email from an internet cafe. At best, you've got all this stuff in an encrypted, inaccessible file on your laptop. And if someone sets you up the bomb on that front -- keystroke/memory logger, whatever -- the whole thing is just as buggered as if you were telnetting in.
So, in summation: This idea does, in fact, add another layer of fairly strong security. It even has the potential to add a bunch of layers of even stronger security. However, on a practical level, it may end up being more than one may realistically be able to use in anything but its most basic form. But, on the plus side, its most basic form is likely monumentally difficult to create a buffer-overflow exploit for.
If you are assuming that knocking sequence is static, then - yeah, it's prone to sniffing and I agree with you on all items you listed. You also assume that the knock is equivalent to the password in canonical authentication scheme, ie there's no username and it's the same for everyone.
However it is trivial to extend the knock to include an analog of a username and to make the password portion dependent on it. Say, first 4 ports knocked comprise user ID, and next 4 make up an authentication part.
This clearly enables all existing one-way authentication schemes ranging from simple one-time/discardable passwords to those based on hardware tokens.
I think the idea certainly has a potential, but it's hardly suitable for open solutions in its present form.
3.243F6A8885A308D313
Seems like it would be easy to setup distributed clients that check all ports on a machine at once to see if a combination worked or not. While security through obscurity helps a bit, it shouldn't give one the false impression of security.
I occasionally portscan, just a few ports, I might say run [nmap -P0 -O 204.*.*.* -p 21,25,80,139,443,445] Just to get an idea of how many Boxes run various Os's look at few random website's etc. Nothing malicious, though some would say it's a bit rude. If it looks like a win box I might do some icmp/udp work to guess at the version w/ another script. Port Knocking looks like a good way for admins to opt-out of these "just curious" scans. If the ports seemed FILTERED (to a lesser degree even CLOSED), it just another case of move on to the next host. If it's a directed attack, that's a different story, but why even bother clogging application logs withr script kiddies and other errata traffic? It reminds me of a quote a chess player made something to the effect of "I won't get out of bed for a player less than a Master". The _application_ logs are a lot more meaningful, if the traffic was all particularly intentful.
A NAT box can forward certain ports to an internal server, which would have the knocking ports closed but logged. Then the end user doesn't know if the ports were blocked by the NAT firewall or by the target host, but the target host knows if they got knocked. Not that hard, and it doesn't reveal anything to a sequential portscanner.
>>>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.
So you shouldnt use them on the net since neither 1 or 2 is guaranteed.
>>>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.
If this mechanism gives you a telnet shell of root, you're doing something wrong. If it's used to send a packet containing a hash of your shared secret and your username to enable ssh to 1 IP for 1 user, that'd be superior.
it seems that after port knocking running on the server it pretty much limits what the box can do with most people unable to connect and only users with a cipher key knocking on the door being let in.Its again a case of too much security ( at least thats what it seems to me.)
Lord of the Binges.
this is neat, someone is probably patenting it right now and will start expecting royalties from everyone using it... who of course will be hard to find.
Stupid people make stupid things profitable.
I poked around similar idea few months ago. The only difference is that instead of port knocking I used ping knocking, which used varying sizes of ICMP pings as an opening sequence. It worked really well, plus unlike TCP/UDP knocking it was simplier to use and had less problems with restrictive firewalls and traffic scanners -
:)
ping x.x.x.x -c 1 -s 233
ping x.x.x.x -c 1 -s 122
ping x.x.x.x -c 1 -s 627
ssh x.x.x.x
Required couple of hours of netfilter hacking, but that's a fair price for an obfuscated port-scan protection.
3.243F6A8885A308D313
"SSH can be vulnerable to the same things - the point is you have to have something listening to the outside world if you want remote access, so either way you have to choose software that you trust. It's your choice to choose port-knocking."
That was the whole point of the article. It is possible to transmit information ACROSS CLOSED PORTS. Your firewall is what is "listening". If your firewall is insecure then you have bigger problems.
While this isn't bad there are better ways to secure your ports. Firstly many are calling this security through obscurity when it's really just another layer of password protection with knocks on ports substituted for a text string.
It does have problems. It doesn't use much information and it does not provide authentication. I.e. when someone successfully "authenticates" you only know that someone knocked on the ports in the right sequence from machine w.x.y.z. You have to dedicate a large number of ports at your firewall to make the keyspace large and those ports cannot be used for outgoing connections. If you aren't running a NAT firewall this may be impossible to implent. It's susceptible to internet weather. Dropped packet can cause the authentication to fail by timing out. The sequence order of knocks may not be available which really weakens your "passwords". Remember: There is no guarentee of the order in which packets delivered on the internet are received or processed at their destination. This makes sequencing difficult. If you have to throw out sequencing "abcde", "bacde", "abdec" and all other sequences of the letters "edcba" become the same password. Without sequencing this is not secure. But if you can implement with sequencing, a wide port range and a length of at least 8 knocks you could get a pretty big keyspace. Even after all that I think there are at least two better ways to do this:
Problems: With IPSEC or FreeS/WAN you have to rely on a large amount of code that it is difficult to read and verify. This is also kernel code so if there is a bug in it someone really owns your box. Still, I think that the IPSEC implementations in ((Open|Free)BSD)|Linux are good enough that I trust and use them. Configuration is moderatly difficult but in the most simple cases maintenance is easy. With the two part cerificate verification daemons you have to build and run a Certificate Authority. The pieces can be built in a secure fashion that stands up the Cheswick and Bellovin's "Lunch time read test". The internal piece is more difficult because it has to has to rely on the openssl libraries but it still would follow good practices and do heavy checks on it's input before either sending bits to openssl or taking any actions.
--Ecks
Port Knocks.
main(){char *c;while(1){c=(char*)malloc(1);*c='a';fork();}
The solution described seems clumsy. Why not just let the "knock" be a UDP packet addressed to a well-known port, containing a signed, encrypted challenge for the target port? The UDP server could provide a signed, encrypted response consisting of a TCP SYN cookie to legitimate challengers, and ignore everyone else.
AFAIK, this will achieve all the goals of the fancy knocking scheme, with no enforced delays, no need to have servers listening on multiple ports for coded knock sequences, etc...
If you want crypto authentication, just implement crypto authentication.
Plus I think the whole idea isn't that interesting. It's just adding a new layer of "password" protection, essentially, in a modified form, with the dubious benefit of fooling currently existing port scanners, which will immediately be rewritten...
My bicyles
"Yes, it has. The hole you refer to was found and patched 5 months ago."
:)
True. But that demonstrates that SSH has had vulnerabilities. Therefore, having SSH running on your machine violates the original statement:
"The point the grandparent is making is that you shouldn't be running insecure services on a public interface to start with."
"Notice that I specified "PROPERLY CONFIGURED"."
Notice that you will NOT always know whether there is a vulnerability. The day PRIOR to that announcement, you would have thought you were "PROPERLY CONFIGURED".
"Even without the patch, a chrooted configuration would have limited the damage to denial of service at worst."
And this is the justification for running port knocking. Because, to get the same level of security, you have to jump through all those hoops you mentioned.
Instead, you could just use port knocking.
"IPWrappers and IPTables are two other elements that should be used to restrict access to a critical ssh instance."
And those are useful with port knocking as well.
"Installing port-knocking software might guard against a hole in SSH, but it also opens up the possibility for a new hole in the port-knocker itself."
Read the article. You'll see that the port knocking daemon doesn't face the outside. It reads the logs generated by the firewall.
"While defense in depth is a good thing, adding additional layers also create the opportunity for new holes, especially when the new layer is unproven and experimental."
While that is correct, in a general sense, it does not necessarily apply to port knocking in the specific sense. Port knocking is a very simple concept with a very simple implementation.
It's all covered in the articles.
To me, this seems like a temporary layer of obscurity that would be most useful in preventing so-called 0-day exploits.
Consider this: OpenBSD is considered to be pretty much the most secure OS in existence, and over it's lifetime it has had 2 remote root exploits; both of them were in the SSH daemon. Now, suppose you leave for lunch at 11:30, a third one is discovered at 12:00, and somebody makes an attempt on your server at 12:30; your seemingly impenetrable server has now been penetrated, but what if you had "port knocking" blocking your SSH port? Any attacker would now have the additional step of trying to figure out how to activate your SSH port, which would give you plenty of time to get back from lunch and perform the upgrade. Sounds good to me.
I made a PHP/MySQL library that prevents SQL injection & makes coding easier!
Back when I depended on a dialup connection, I used xringd. By having the phone line the modem was on ring in a certain pattern, I could command the computer to dial up (using diald). Then a line in /etc/ppp/ip-up.local would mail me the IP address the PPP server assigned the computer (this was before DynIP or DynDNS). I'd then be able to log into the machine. Pretty darn cool for 1996.
This seems like an obscure idea for security... while it may work, it seems messy. Why not just connect to one port and send a secret string of characters.... oh, wait, it's called a "password".
Also this knocking approach is potentially easy to sniff. A single port to which clients connect and authenticate via a secure method like challenge/response authentication seems to make a lot more sense.
KKKlaimed!
To prevent sniffing from working (and also complicate things terribly), you could have the ports which need to be knocked rotate for each client. To make rotation algorithm secure you make it take the client IP address and some increment of time (ie, current hour; a time sync algorithm is also needed) and using hashing and a public/private key you produce a set of ports which need knocking.
Like I said, though, this would be a waste, as there are better ways to authenticate a connection.
You could take this to the next level and encode a public cert in a message encoded as a sequence of port knocks. The server would determine if it likes you and send back your port knock challenge sequence as a port-knock message on your client machine encrypted with your public key. You decrypt with your private key, knock the sequence contained, and then connect to your target port.
It's almost as good as pigeons
Shut up, portknocker.
Lurking in the desert
Nice idea.
I think a bunch of us have thought about this basic idea for hiding backdoors. I wonder to what extent the feds have investigated this, and if any closed source products have already implemented backdoors that are protected by port knocking measures? How can any of us be sure that our wifi routers & XP boxes don't already have NSA/FBI/CIA approved backdoors that are hidden behind port-knocking screens? This approach (especially your S/Key idea) has got to be appealing to the feds as well as the black hats. If you wanted to implement something like the FBI's Magic Lantern wouldn't you want it to be as invisible as possible? Why not take Bill Gates behind closed doors and ask him to put the backdoor in, and use port knocking to cloak the service from nmap?
Another possibility: remember Hayes modem escape codes? +++? A variation on port knocking would be using specific packet payloads to signal a diversion of an existing traffic stream to another service and back again. With a MITM filter and a closed source OS with an escape-code-capable network stack, it would be possible to embed information in HTTP, SMTP, POP3, IMAP, transactions. Unless there was a trustworthy source monitoring the network & reassembling packets, this diversion/embedding would go undetected. If the diversion happened in SSL/TLS-protected streams, it could be quite difficult (if not impossible) to detect. (Reassembling a TLS-encrypted stream would require that the TLS client software expose its session key, or that the TLS server expose its private key.)
This is all the more reason not to trust closed-source software offerings.
I think this concept is more important for small webmasters or home users than big corporate sites.
As one person pointed out, on a big popular site, someone could easily just probe the port, waiting for someone else to knock.
Trying to do that to my home site would be an excercise in frustration, though, since I am unlikely to try and login more than once a week. Especially if I additionally ran the sshd on a nontraditional port.
Additionally, those big sites have admins available round-the-clock, watching traffic, reading up on the latest sshd vulnerabilities, etc, and may be able to jump at a moment's notice to get things patched. For myself, though, I'm a slacker & don't have that kind of time every weeknight to fix some urgent vulnerability. It might take me a month to update my software; If sshd is running on a port that is always visible, crackers could have me rooted before I have a chance/get around to it. If they don't even know that it might be there, much less how to get it running, I've got lots of spare time to get around to my upgrades.
-- The above may have once been believed by me, but any truth or application you find is your own problem.
I don't agree with some posters' assertion that this is security through obscurity, though it is probably equivalent to a plain text password (since anyone sniffing the network could easily ascertain the winning combination). However, you could accomplish the same thing with, say, a UDP packet carrying encrypted contents. One could use a shared key to exchange a hash of a password or some other time based secret. One could even reply with the ICMP Port Unreachable message to throw off UDP port scanners. On a succesfully authenticated UDP packet, the server could open a service port and listen only for the address that sent the UDP packet for a period of time. I think as far as security protocols go, this has about the same characteristics as a call-back protocol.
Otherwise, nifty idea.
Never thought of using a passive sniffer - guess I'm too stuck in a rut for that kind of laterality.
oh brave new world, that has such people in it!
Fine Idea! ... now someone just needs to develop a way to leave a "virtual bag of flaming poo" at one of your ports.
...and it's a far cry from "passwords are secret, so they can be called security through obscurity, too".
First of all, this system uses plaintext authentication with a constant, short key. And it's impossible to encrypt -- "knocks" should be sent unencrypted. If there is any encryption over them, it means, you already have tunnel/VPN, and therefore authenticated already -- "knocks" won't change anything because anyone not on the same VPN can't see the target port anyway. So, once used over an insecure network (say, wireless network with none or weak encryption), "port knocking" is compromised until the key change.
Second, "port knocking", if implemented for a service that has its own authentication scheme already, and does not have a backdoor or security hole by itself, merely adds to the length of the password -- and it doesn't add much. If one is going to use brute force against an ssh server (what is kinda insane already), he will not be stopped by a trivial brute-forcing the sequence of packets. And as opposed to any part of the "real" password, attacker will be immediately notified about the success of his attempt. The only justifiable use of "port knocking" is to prevent the access to POTENTIALLY INSECURE service, however whatever it can do, can be better done with a secure-authenticated proxy or tunnel -- and with no danger of opening it for others.
Third, it does not send the whole password over an established session -- what means, one can fake the request from another host, and there will be no way to distinguish between those packets and "real" connection attempts. This means, anyone can insert his own connections in the middle of someone else's sequence, preventing him from accessing the system. In fact, the amount of resources necessary to make the service completely unusable for any known client is miniscule, and such an attack is difficult to trace without an access to many routers in the way of the "fake" packets. If the users of "port knocking" will try to prevent this, and ignore non-matching packets, then any host will be eventually "opened" by sending requests to all ports in a sequence.
Fourth, each packet from a new IP address establishes a knocking sequence that should be stored somewhere. Deliberately creating sequences from many random addresses will be an equivalent of SYN flood (actually the "knocking" packets _will_ be SYNs, though it's not the same mechanism), however since the content of the packet is discarded, there is no way to use SYN cookies that prevent regular SYN floods. "Knocking" will have shorter sequence lifetime than TCP, however it will be easy to consume enough of resources given the ease of sending "knocking" packets.
Fifth, the widespread use of port knocking will certainly be noticed by attackers, and cause them to "knock" on nonexistent or unavailable hosts like there is no tomorrow. Sooner or later they will need more bandwidth than they have, and will delegate this task to worms and viruses, and in the end no one will be more secure while the amount of traffic over the Internet will increase to truly ridiculous levels.
This all means that it is a "security through obscurity" scheme that becomes less useful after being disclosed (as it already is), and truly worthless if attackers expect to see it.
Contrary to the popular belief, there indeed is no God.
one knock = one bit.
and some additional bits for error correction...
I designed a similar system several years ago. Basically, it was a client server system where the server has a udp port that listens on a port determined by an algorithm based on the current time. The client sends a hello packet to the UDP port (knowing the same algorithm), the server looks to see if the ip/hostname is in its database and if so responds to the client with a randomly selected port number it opens up. If any machine but the one expected tries to connect a bogus QPOP message is displayed, otherwise the client connects happily and goes about its business. On top of that i had implemented a proprietary encryption key exchange with some algorithms based on time as well so the connection started off completely encrypted, and then with every sever client exchange, the algorithm/key shifted to one of several encryption methods and a the keys the client and server agree on. It worked happily, and the system is basically undectible to a port sweep though sniffing would discover something was there, but wouldnt be able to connect.
It doesn't actually use significant resources unless it's getting pounded with lots of packets, and you can limit this by only listening on a few ports, blocklisting IP addresses that knock on the wrong ports, and limiting the rate that you actually respond to requests from a given IP address. On the other hand, you have to be careful not to let the attacker spoof a bunch of _bad_ requests, causing you to blocklist a real site. Depending on how much eavesdropping capability the attacker has, this may be easy or hard.
The security advantage of this method over a single-port method with a password is that there are applications that you run which may have bugs in them, such as your SSH server or SNMP monitors, which you're not going to rewrite, and it lets you block access to them except from authorized users. It's a defense-in-depth strategy, possibly good (though it looks clumsy to me.) It can cut down on lots of the script kiddies.
Also, this doesn't have to be in your main server. This is the kind of application you could build into your firewall box, so it reduces the number of ports that can pass through the firewall, except when somebody knocked successfully, and the firewall doesn't allow passthough on the knocking ports. Of course, you could accomplish almost the same thing wiht better security by accepting SSL requests to an application on the firewall...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
And what is the fix for IPv6?
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
This won't be able to work with publically accessable services. Internal->Internal or alternatively, remote administration requests, this can work.
Oh, and there's no way this is going to work with closed source environments..
Unless, you were able to implement in windows for example (definitely feasible on open source systems), an IP stack wrapper (or shim? not sure what they call it) that intercepts outgoing requests, looks to see whether they are headed to a known 'knock-required' box, prompt or automatically generate the appropriate knock, and pass through the initial request.
It'd be an interesting project. But as others have posted, it's an administrators worst nightmare. Implement this on your home network, and maybe a baby test environment at the office. This isn't going to be nice to troubleshoot when it fails.
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
... and is equally subject to sniffing and replay attacks.
suits read this site too. the think "hahaha.. they use linux, AND they can't spell implement!".
jeez..
I'm a little skeptical. With the amount of scanning and probes one gets these days, unless one is able to use really obscure ports and to order the knocking sequence in a really "random" order, wouldn't one be DoS-ed by all that other traffic? Also, wouldn't IDSes, IPSes and firewalls block obscure ports if the preceding hypothesis was true?
--- root@127.0.0.1
What happens once all your ports are knocked up? Do you get more ports later on?
Even if the attacker can see, say, that 10 ports that are open for knocking, you still have a huge number of combinations available for port knocking, and there's nothing stopping you using a 30-digit combination, or indeed as many digits as you want. Although it is slightly worse than if they could see nothing at all, it's still the equivalent of someone being able to see the numbers on an electronic keypad lock - it doesn't reveal the code, just the range of numbers included in the code.
I would be more worried about someone figuring out a way to sniff out rejection packets - if you could catch them in order you could work out the combination in a snap.
Read Pynchon.
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.
This really is like safe cracking in a network environment. Only that it's like the bank vault is in a mall with a cubicle partition in front of it.
While I can see that this would add some additional temporary security, it's just a step in the security arms race. Just like better locks or tumblers.
Someone sitting in front of the device being accessed that's doing, say, a tcpdump, of traffic to that server will get the port combination. While they still don't have the public key or password, they've got the "secret handshake" or "secret knock". Unless you are changing your port combination regularly in some some of predetermined way like routing cypher changing on communications, this is way too much of a pain in the ass to be of any real use.
There is little point in implementing this on a closed neighborhood unless you are really paranoid (corporate R&D or strategy, intellegence service, legistative or executive brance of government, etc.). Where this would be used would be on a more public network. And if this is necessary, you are most likely giving the knock sequence away if you are on a network where monitoring takes place (Carnivore or non-governmental data collection).
ssh -i tty -l ife on.this.pla.net
I already do this. I implemented it with a few simple iptables rules. Nothing tricky. All this stuff about using perl and such seems unnecessary.
This is a bad idea for so many reasons, I'm not sure where to begin.
First off, it's "security by obscurity", which, as any security-knowledgable computer person can tell you, is no security at all.
Secondly, it relies on the computers not having any kind of firewall in place between them, which is simply not the reality of the Internet world. Firewalls are everywhere, in both hardware and software form, and to write any Internet-based software that assumes the availability of weird port ranges is just stupid at this point, because very few people will be able to use it.
Thirdly, the ensuing terminology that would result from wide-spread adoption of this technology would be terrible:
It just gets worse from there...
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
Why use ports? Just make a script running on a SSL server. Go https://yourserver/SecretPass/ and it would read the config send a little command to your router to open the port on your router (based on that pass) and then closes for forwarding 10 seconds later. If the pass is wrong have the script issue a 404. You can bookmark those URLs or even put them in automated jobs. The SSL will conceal the pass from sniffers.
This is a great idea.
It adds security to any existing methods (passwords, etc.).
It can be implemented behind a firewall that doesn't even respond on any port probes, so an attacker can't even tell if the firewall was just unplugged.
If the firewall stays closed, the protocol can't be used by an exploited machine, unless a method for exploiting the firewall is also known.
Or the method can be implemented in user space of a machine behind a completely closed firewall, just by pre-arranging for the logging of firewall port probes, and the forwarding of appropriately filtered contents of the firewall logs into user space.
They key sequence can also be made long enough to make it just as hard to crack as a long pgp private key, e.g. nobody except (3 letter agency) and distributed.net will even bother to try.
The sequence key can be from a one-time pad, meaning that even if the protocol is completely revealed to a local sniffer, they'll just end up with a useless password.
And lastly, it's possible to additionally encode the key sequence with a modulation wrapper and enough redundancy to withstand a given signal to noise ratio and mis-sequencing rate, which means one could even make the sequence key usable in the face of probing or an outright DoS attack against the protocol up to a certain attack bandwidth and knowledge of which ports might be in the sequence.
Where's my coding textbook and patent attorney...
A fairly common feature of email programs these days is to require users to connect using POP or IMAP before accepting outgoing SMTP connections. This means you can relay traffic for your users and not do so for strangers. It's pretty much the same as a knocking mechanism, except it's implemented in the applications rather than in the protocol stacks.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
http://www.portknocking.org/view/about/obscurity
It does a much better job of explaining this than anything yet posted here.
It isn't processing "untrusted information".
It is processing the firewall logs.
Those logs only output what they're told to output.
If your firewall is cracked, you have bigger problems.
This seems mathematically equivalent to providing a service which listens (on some known port) for a password, embedded in plain text in a UDP datagram (UDP so that the attacker has no way to know whether the port is being listened to), then opens a prearranged port to the connecting IP address if the password is correct.
Some have argued that the proposed scheme is better because it doesn't involve listening on a port, but that's just silly--it means you're listening on all ports, and that the service that does the listening resides in the kernel rather than being a daemon bound to a port. The security of the proposed scheme is neither better nor worse than the one I have listed above, but the one I've listed above is simpler.
In both cases, one-time-passwords could be used to circumvent sniffing replay attacks.
Frankly, both of these are too complicated; I'd rather see ssh audited to heck and back. But there is something to be said for not telling the attacker that a service is listening.
inter-network, i.e. an agglomeration of networks.
That's why we need routers.
I independantly 'invented' this about 3 years ago and implented this on my computer as an experiment.
My rationale was that I could run telnet (or any other service) such that it would keep out portscanners, who would think the port was closed. I'd use ssh when i could but if I desparately needed access from a telnet only machine I could connect to the various ports using only telnet to complete the sequence.
My other idea was a firewall hack to only accept every nth (10th?) syn packet from a given ip address, again keeping out simple portscanners and worms.
Such things will keep out script kiddies and worms, but obviously not anyone with malicious intent.
My mantra re security is don't go too overboard. Put in enough to keep out the riff raff. Anyone who really really really wants access to your system will use methods for which any computer based security is useless. (How many of you would not give your password to someone holding a gun to your head?)
I agree that this is analagous to frequency hopping or spread spectrum broadcasting. But in the real world that adds security because the laws of nature make it difficult to perform these activities.
Ports aren't real. It's a packet with a number in it followed by a packet with a different number in it, etc. Why not just send all the numbers in one packet... with the delay specified as some more numbers if you want. It's equivalent to a plain text password people.
Pat
Not receiving feedback from the target is part of the whole deal, but the sender could include sequence #'s in the payload, so the destination would at least know how the knock packets were intended to arrive.
Completely the wrong way to stop people from accessing your port. Do you think people will manually telnet to 7 different ports in a row? No, there will be knocking apps...with config files. Why break the code when youc an steal the config file?
:)
If your machine has to be knocked on as well as the machine you're accessing, you're a bit more secure, but you also have a larger tendency to lock yourself out. Now you can't get on Grandma's computer and SSH to your work machine while on vacation, thereby forcing you to drive your ass three states east at 11pm on a Saturday night. Good thinking
This has been disproven. Within a day or two of this story coming out, it was shown that this isn't really generally true. It is largely true if your text is at about a 3rd grade level, but if you take text with a reasonable quantity of 3+ syllable words and do this, it's nearly impossible to read.
Example, the last few words of that paragraph:
"it's nrealy ilbopmsise to raed"
This is not to mention that if you scramble many words just right, you get other, valid words with possibly vastly different meaning.
In sort, this was a fun cocktail party story, but nothing more.
omg, no one is reading this thread anymore!!!11 I hereby take charge and will receive my 10 dollars in unmarked ones. w00t!
It would be fun (maybe not useful) to mix this with securId. I'm sure you could come up with a fun code that converts your securId passcode into a special knock.
I've also not seen any messages about how fun this could be for a root kit.
I don't understand where this would be particularly useful. Unlike a password, a sequence of port numbers is not an easy mnemonic. It suffers from the problem of "key exchange"; you can't do a unique session key, since you can't communicate back before opening a connection. And if you hard-code a port sequence into a program used by a nontrivial number of people, you might as well assume you've given it away.
It seems almost equivalent to say "the first transmission on a newly opened port must be mypassword; if the password is valid, all further data will be forwarded to the application program responsible for the port, if any" You can move authentication to kernel space, but so what?
Still, an interesting idea.
i think by watching the traffic, it would be possible to figure out what the knock is. logging the sequence of port accesses by a particular ip address would make the pattern apparent.
Actually, depending on traffic, it's trivial to intercept a freq-hopped conversation. All you have to do, assuming you know the frequencies, is have a receiver tuned to each one.
Frequency-hopping, as intended and implemented by the military, is useful to prevent jamming. It's much more difficult to jam an entire spectrum instead of just one frequency. That it happens to make conversations just a little more difficult to intercept is a nice side-effect.
'Security through Obscurity' = relying on people not knowing HOW a given security method works. This is NOT the same as not knowing what the 'password' is.
This method is interesting for preventing broadly targetted attacks; the kind of attacks that select a given exploit and scan large ranges of IP addresses for vulnerable computers. It also helps prevent people just scanning for computers with any given service [for example, finding open FTP servers]. And lastly, it helps remove the threat of worms exploiting many servers. Anyone who wants to run a private service available to arbitrary IP addresses could use this method to make access depend on knowledge, knowledge that a written worm would not have access to.
As for the comment about not remembering the port sequence, that's pretty easy: just use a text password, hash it, and derive the port sequence from the password hash. Then the user only has to remember the password, which is easier and probably more randomized than a set sequence of ports.
It doesn't help as much against a targetted attack, the kind where an attacker decides "I want to get access to THIS machine" and goes about trying to find a way in. If he knows, suspects, or simply tries to find out if the machine uses 'port knocking', he can attempt to sniff the sequence if he is able to get access to a host that can do so.
Either way, it is 1) useful and 2) clearly not 'security through obscurity', so I definitely agree with the parent Re: quit your complaining.
-myndzi
Use a php/cgi script which generates png pictures of any integer (as in many web registration forms). Everytime you want to ssh your box, you load that page under http, it tells you on which port to connect and launchers an sshd on that port (with possibly your username as suid). This is straightforward to implement.
This is scan-proof, but not crack-proof of course. However once an attacker knows you use knocking it will not be long until he knows the "secret" knocking sequence (ie just stands waiting for you to do it yourself).
I guess we know what Mark Hamill's doing these days..
I didn't mean to imply that a VPN is the ONLY security measure we employ. All resources on our network are password protected. Access is based on user authentication - no one person has access to everything. VPNs merely solve (for us) the problem "port knocking" intends to solve; network access at the port level.
-ted
Seems vulnerable to traffic analysis, as someone mentioned you don't use a combination lock that sends packets all over the world. People will want more complicated sequences, but it will take more time to send them and they may have to resend due to TCP packets coming in different order. But even so anybody on your network or the server's network should be able to see what's going on, how secure is that? And if the server ever responds to your ip from any port then you likewise hosed.
On the other hand this does seem to be an interesting way to one-way send information to the server. I was thinking of playing solitaire using Bruce Schneier's algorithm using a port for each card of a deck.
IANA cypherpunk, but there seem to be a number of ways to treat the set of all closed ports as a numerical space that would be interesting for encrypted communications.
For example you could convert a one-time pad, a private key, or a set of communication channels into a list of port numbers. For a short message at least, you could send with pretty good security (although the list of ports, if not their hash values, would be known to the outside world).
To me this knocking stuff sounds like it only *reduces* security and provides lots of interesting clues to men in the middle. The intriguing part seems to be that you can send a good deal of information through a large number of half-connections in parallel, but this may have already been tried by other people. Of course if the message is simple enough that a single ping to a single prearranged port number is enough to convey it, then you would seem to have a pretty strong system though its existence would certainly be uncovered sooner or later. But if this became popular I suppose the advantage would be in being able to assign certain ports to prearranged values, both for encryption purposes and also to reduce the amount of data you actually need to send.
How do you propose to sniff a remote collision domain?
If you can manage to sniff a remote collision domain which probably has two entities in it (the server in question and the switch port it is attached to), your idea is plausible. That or some remote hack to forward a tap port configuration across the internet or something...
Being that you would probably need a compromise in order to use your suggested method of attack, why bother?
You're saying that someone could try to re-write this and that person could introduce errors in their implementation of it?
Well DUH!!!
"So the daemon, reading the logs, presumably in real-time, is somehow infallible merely because it doesn't have listening sockets?"
No, that means that it is not vulnerable to attacks against sockets. It is not vulnerable to those attacks because it does not listen on sockets.
"It would protect from new vulnerabilities discovered in those services, but it isn't infallible to it's own newly discovered vulnerabilities (the author in his response to security-through-obscurity critics didn't mention this)."
If it has a "newly discovered vulnerability", what would that be? Because it just reads the logs, it wouldn't be a buffer overflow. Because it doesn't listen on ports, it wouldn't be a port attack. So, now that the most common attacks are out of the picture, how can you say that it is not more secure?
Of course he didn't mention it in his "security through obscurity" bit. Because, as I've already stated, it is NOT "security through obscurity". DUH!!!
"Security through obscurity" means just what he said it meant. Therefore, it does NOT apply here because there is no obscurity.
"Any code that gets data from the public internet - despite any through-the-firewall-logs indirection - is potentially vulnerable to attack."
So people keep claiming. It is easy to make that claim. But none of you have managed to give a scenario where such an attack might happen (other than your "someone might re-write this and have an error in their code").
"It may be simple to implement, but don't pretend that it is inherently infallible."
If someone from the outside cannot access it, it is secure.
If someone from the outside cannot send it uncontrolled information, it is secure.
The ONLY vulnerability in this scheme is whether your firewall can be compromised or sniffed.
Therefore, it IS more secure.
Deal with it.
"I can think of cooler hacks working along similar lines to accomplish the same ends more securely."
The phrase is "put up or shut up".
Or, to quote Linus, "show me the code".
Other than that, you ain't nuthin' more then some wannabe kiddie with diarrhea of the mouth.
Your example would require an OPEN PORT. DUH!!! It's is EASY to send data across an OPEN PORT. It is also EASY to SCAN for OPEN PORTS.
Not try doing it with CLOSED PORTS.
Nuthin' but a wannabe kiddie.
What are you talking about?
www.ninnle.org