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..?
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.