fwknop stands for the "FireWall KNock OPerator", and implements an authorization scheme called Single Packet Authorization (SPA). This method of authorization is based around a default-drop packet filter (fwknop supports iptables and firewalld on Linux, ipfw on FreeBSD and Mac OS X, and PF on OpenBSD) and libpcap. SPA is essentially next generation port knocking (more on this below). The design decisions that guide the development of fwknop can be found in the blog post "Single Packet Authorization: The fwknop Approach".

• Download | latest release: 2.6.11
• Tutorial
• Documentation
• Features
• Source Code (github)
• Code Coverage (for the 2.6.10 release)
• Mailing List

You can clone the fwknop git repository as follows from github:

$ git clone https://www.github.com/mrash/fwknop fwknop.git
Cloning into 'fwknop.git'...
remote: Counting objects: 5275, done.
remote: Compressing objects: 100% (1603/1603), done.
remote: Total 5275 (delta 3672), reused 5155 (delta 3552)
Receiving objects: 100% (5275/5275), 2.07 MiB | 3.96 MiB/s, done.
Resolving deltas: 100% (3672/3672), done.

SPA requires only a single encrypted packet in order to communicate various pieces of information including desired access through a firewall policy and/or complete commands to execute on the target system. By using a firewall to maintain a "default drop" stance, the main application of fwknop is to protect services such as OpenSSH with an additional layer of security in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) much more difficult. With fwknop deployed, anyone using nmap to look for SSHD can’t even tell that it is listening - it makes no difference if they want to run a password cracker against SSHD or even if they have a 0-day exploit. The authorization server passively sniffs SPA packets via libcap and hence there is no "server" to which to connect in the traditional sense. Access to a protected service is only granted after an authenticated, properly decrypted, and non-replayed packet is monitored from an fwknop client (see the following network diagram; the SSH session can only take place after the SPA packet is sniffed):

Single Packet Authorization retains the benefits of Port Knocking (i.e. service protection behind a default-drop packet filter), but has the advantages listed below over over Port Knocking. For a complete treatment of all fwknop design goals, see the fwknop tutorial.

**

• SPA can utilize asymmetric ciphers for encryption

• SPA is authenticated with an HMAC in the encrypt-then-authenticate model

• SPA packets are non-replayable

• SPA cannot be broken by trivial sequence busting attacks

• SPA only sends a single packet over the network

• SPA is much faster ** More information Single Packet Authorization and port knocking can be found here:

• Enhancing Firewalls: Conveying User and Application Identification to Network Firewalls This is a Master’s Thesis completed in May, 2007 by Rennie deGraaf at the The University of Calgary. See his website for more information.

• An Analysis of Port Knocking and Single Packet Authorization. This is a Master’s Thesis complete in September, 2006 by Sebastien Jeanquier at the Royal Holloway College, University of London about the concepts of port knocking and Single Packet Authorization. See his website for more information.

• Single Packet Authorization with fwknop. This paper was published in the February, 2006 issue of USENIX ;login: Magazine.

fwknop started out as a Port Knocking implementation in 2004, and at that time it was the first tool to combine traditional encrypted port knocking with passive OS fingerprinting. This made it possible to do things like only allow, say, Linux-2.4/2.6 systems to connect to your SSH daemon. However, if you are still using the port knocking mode in fwknop, I strongly recommend that you switch to the Single Packet Authorization mode.

fwknop on Slashdot

fwknop has made Slashdot twice here: Combining Port Knocking With OS Fingerprinting, and here: Going Beyond Port Knocking; Single Packet Access.