

Fwknop: Single Packet Authorization and Port Knocking - kolev
http://www.cipherdyne.org/fwknop/

======
zarvox
Moxie's criticism of portknocking implementations [1] has several facets that
apply to fwknop. I would not recommend using fwknop in general.

Unrelated to security, but practical experience from using fwknop in the past:
port-knocking tools that depend on timestamped packets are a great way to get
locked out of your server if you have time skew between server and client. EC2
instances will drift a lot over their lifetime, so if you're not running NTP
you will likely eventually fall outside the portknocking implementation's
grace period, and then be unable to access your server at all, short of
rebooting it or figuring out how skewed the clock is. Not fun.

[1]
[http://www.thoughtcrime.org/software/knockknock/](http://www.thoughtcrime.org/software/knockknock/)

~~~
michaelrash
First, let me state that I have a lot of respect for Moxie. That out of the
way, knockknock is not above criticism too:

1) It is possible to mount a MITM attack against knockknock just by
intercepting a knockknock packet, changing the source IP, and retransmitting.
This is a consequence of knockknock not encrypting the source IP within any
payload (which involve only packet headers in the knockknock implementation).
fwknop does not suffer from this problem because it encrypts the IP to be
allowed within the SPA payload. 2) You mention time synchronization issues
above. Well, knockknock uses AES in CTR mode, and this also requires
synchronization between the client and server of a different kind. If
synchronization were a problem for fwknop, then you must apply this critique
to knockknock too. You _can_ disable time sync in fwknop if you really want
to, but it was added to prevent MITM attacks.

Here are the design goals that fwknop is developed around:

[http://www.cipherdyne.org/fwknop/docs/fwknop-
tutorial.html#d...](http://www.cipherdyne.org/fwknop/docs/fwknop-
tutorial.html#design)

~~~
zarvox
Thanks for the detailed reply!

I agree that there are certainly a number of tradeoffs involved, and reading
the design goals you linked, I see that (in particular) the desire to be able
to run fwknop on OpenWRT and other particularly resource-constrained setups
makes a strong argument for your implementation strategy.

Your comments on MITM and synchronization are well-received. It's clear that
you take the security of the fwknop implementation seriously, and I apologize
if I was overly negative. I should have read more about the design goals
before criticizing the project so harshly.

For what it's worth, in place of my first comment, I should probably instead
say that fwknop was not a good fit for my needs at the time, but that there
certainly exist cases where it will be an excellent solution, and to watch out
for a practical gotcha I learned the hard way. :)

