Contributed by jose on from the false-security dept.
I am intrigged by the port knocking idea. Although this is very much an obscurity layer, it seem to be a great way to force would-be intruder to make a lot of noise before finding what they look for. Forcing five or six port knocks before a connection would make it difficult for scanners to find running services without being easily detectable. What to OpenBSD folk think of it?
Cheers.
http://www.portknocking.org/ "
Port knocking has been used by malware for a while now, but I haven't seen a convincing argument for it in real security. Has anyone implemented this (for example using the pflog0 interface to retrieve packets) on OpenBSD?
(Comments are closed)
By Anonymous Coward () on
I'd like to be able to open up sshd globally without the need of opening say port 22 (or any other assigned port for that matter) to the world, unless they know the portknock sequence (in essence, the password).
This thinking is on the principle of "whatif" there's ever a remote exploit in OpenSSH; while still allowing myself ssh access from wherever I am remotely.
To me, it's just an additional layer of security - perhaps security through obscurity but I personally see it as an addition to whatever existing infrastructure(s) is/are impletmented.
Just my thoughts...
Comments
By ssc () on
isn't it funny that ppl try to protect themselves from bugs in software by adding even more software?
By old3n () on
AC, you say that you'd like to "open up sshd globally" but only to whoever knows the right portknock sequence/password... but this sequence is very vulnerable to evesdropping, DoS and network variations ie loss, reordering, NAT with load balancing...
Thanks, I'd much rather rely on some strong authentication (DSA or whatever) over a reliable link (TCP), like, er... SSH itself (doh!)
"It's just an additional layer of security", maybe but it's weaker than what it supposedly protects. However, it certainly is another layer of complexity, with its own new problems...
Comments
By Anonymous Coward () on
Couple questions for you then..
If they DoS it, couldn't they just as easily DoS OpenSSH itself?
Sure it's possible to evesdrop the port sequences, so then they get that (taking them a couple more steps) and get to ssh. Now they're sitting at a login: prompt without a login/passwd. Where's the danger in that if ssh were already open to the world itself?
I'm not trying to sound like an ass here at all, I really am curious on these questions.
Don't get me wrong either. I trust OpenSSH, but as in the past there was bugs and always will be. I just hope they're not as serious as to allow remote execution or shell level access.
Regards.
Comments
By anonymous atom () anonymous@super-atom.com on mailto:anonymous@super-atom.com
By old3n () on
Here's why it's IMHO (comments welcome) much easier to DoS a box relying on port knocking than on sshd alone.
1) Unlike SSH/TCP, no handshake is necessary to transmit a port knock (that's the whole idea). Therefore pretty much anyone can spoof a sequence (correct or not) from any address without revealing anything about their possible identity.
Impossible to filter out at the target.
I could spoof knocks from a bazillion of machines (using part(s) of the right sequence if I sniffed it earlier, or just noise if I didn't). How many will the port-knock gatekeeper software keep track of? If it starts discarding legitimate attempts, better yet exhaust the host resources or even crashes, our DoS was successful.
2) The "knock password" is not atomic but is a sequence of packets, which can arrive out-of-order etc or, in case of a DoS, with some chaff in between. [This is IMHO a major design limitation; I'd much rather rely on the password consisting of, say, one UDP packet instead of several TCP SYN.]
Anyway, if this added junk causes your port-knock sequence to be rejected, we have another case of successful DoS. If you relax the rules so that noise/out-of-order/loss issues don't affect you, chances are that just knocking on random ports for a while will open the port-knock gate as well now.
I understand your point of view "we have seen a nasty hole in OpenSSH in the past, port knocking is a way to protect myself from the next one".
Sure it is, but you just added one layer of software here, with new opportunities for bugs or other problems (I was mentioning DoS).
It's a tradeoff. Personally I don't think the benefits of port-knocking outweight the risks, inconvenience etc, so I won't use it on a production system and I don't think it should be part of the default OpenBSD install. But I'm sure nobody would complain having it available as a port/package for whoever want to use it...
By Benjamin Schweizer () gopher at h07 dot org on http://www.redsheep.de/
Comments
By Matt Van Mater () on
After looking at the config files, readme, etc I don't see why you couldn't build your own gg scanner and look over your network for hosts listening for this traffic? You might have to try a few common session identifiers but many script kiddies could be found easily because they were too lazy to change the 'test' identifier.
Also, why wouldn't an IDS be able to pick up gg specific traffic? There has to be some sort of specific packet sequence or payload that gg looks for beyond the simple identifier listed in the shell script as 'test'. Otherwise the ggd daemon would kick off every time the characters 'test' went over the wire, which I doubt it does.
In any case, this is a pretty nifty idea. I'd hate to be on the receiving end of it though :)
Comments
By Benjamin Schweizer () gopher at h07 dot org on http://www.redsheep.de/
The only method of detecting a well infected machine is some statistics on irregular traffic. And there is no security, there is only trust.
[1] I assume that it is possible to use some timing analyses under high system load to detect a ldpreload.
By qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvb () on
there is zero gain from sending multiple packets to serveral ports in order. you might as well send one packet with, say, the port numbers as payload. or better yet, a crypto challenge.
but guess what, this is exactly what daemons like sshd, which is the type of service this would be used for, already do. so instead of reimplementing the wheel, why not hack to improve sshd instead?
or if you're really after obscurity, use a better thought out idea, like tcp md5 signatures (i believe this has been suggested before). man 4 tcp.
Comments
By Anthony () on
Comments
By djm () on
By Anonymous Coward () on
By Krunch () on http://krunch.servebeer.com/~krunch/