[ previous ] [ next ] [ threads ]
 
 From:  Adam Nellemann <adam at nellemann dot nu>
 To:  "m0n0wall at lists dot m0n0 dot ch" <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] Port Knocking?
 Date:  Sun, 08 Feb 2004 01:23:45 +0100
Hi,

First of all, I'm no network expert, so I might be missing the point all 
together here! Also, there might be a number of better solutions than 
port knocking out there that I might not know about?

That being said:

How would you go about "trivally sniffing" a seemingly random sequence 
of packets, bound for various ports on the "target" box? Bearing in mind 
that any reasonable intelligent "knocking client" would intersperse the 
real "knocks" with various bogus packets for ports not part of the list 
of "knocker ports" (which would be, at least initally, unknown to the 
hacker), in addition to various other presented schemes to further 
"obfuscate" the knocking sequence (such as time-stamping etc.)

===

I guess that what drew my attention to this (rather alternate I must 
admit) way of doing port security, was the fact that, unlike most other 
kinds of security, the poor hacker would have a hard time knowing what 
part of the inbound trafic to the target he should pay attention to, 
even if he was at all aware of port knocking being used on the target.

Most other security schemes (if I'm not totally mistaken?) takes place 
on a single (or a few, sometimes even known) port(s), on which the 
hacker would focus his attention. A really good (and bugfree) security 
scheme would of course be encrypted in a way that would leave the hacker 
little chance of ever decrypting the packets. But this requires all 
components involved in the scheme to be totally unexploitable and 
bugfree (something which Microsoft et.al. have made difficult to ensure!)

Port knocking, however, will allow any such security scheme to be left 
in effect (if need be), while giving the hacker a lot of grief simply 
trying to figure out which packets and ports he should pay attention to, 
and which are merely "misdirections", before he could even begin to try 
decrypting or otherwise exploiting anything on the target box.

But as I said, I might be overlooking something important?

===

I think it should be noted that (most of) the articles leave no question 
about the limitations of this scheme, nor do they suggest it be used as 
a replacement for any or all other security schemes. In fact I think at 
least one of these (or some sub-link) specifically states that the port 
knocking scheme is mainly useful for some "specialised" cases.

Personally, I still think it a nice feature for m0n0wall. I (and perhaps 
some of the other "home users" out there) don't typically leave many (if 
any) ports open to the WAN, but sometimes find that I would have liked 
to access something or other running on a home PC, from some 
unanticipated remote location. With port-knocking, I could safly leave 
any application or service (ie. FTP, Telnet or remote desktop app.) 
running on my PC, but without opening any ports on the WAN interface, 
knowing that I could do this from any remote site.

This way a not-so-sophisticated user (like myself) wouldn't need to 
worry about the built-in security of any apps or services left running 
on the home PC.

===

Also note that if the knocking scheme isn't made too elaborate (which 
would probably still be sufficient for many of us "home users", who 
doesn't have KGB or NSA hacking our networks on a daily basis!), you 
could, in a pinch, do the knocking sequence manually, if one should have 
omitted to bring the client! Although, I'd probably prefer to make the 
client/script available on some public, but password protected, FTP or 
HTTP server (This under the assumption that certain "secret" paramters, 
such as knocking-port ranges etc. would need to be entered manually in 
the client, for it to work.)

But if a better/simpler solution to this problem exists..?


Adam.


Bart Smit wrote:
> Don Gray wrote:
> 
> [ about port knocking ]
> 
> Frankly, the idea doesn't win any sympathy from me (grumpy old fart)
> whatsoever. The port knocking sequence is trivially sniffed from the
> wire, so it suffers from the same types of problems that unencrypted
> passwords have. And if you want to eliminate problems with buffer
> overflows and similar vulnerabilities in code that listens to the
> network, well, don't listen to the network then! Both the the low level
> networking code in the kernel and the networked application code need to
> be safe against such lines of attack; there is no principal difference
> there. I really fail to see the point.
> 
> --B