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 both iptables on Linux systems and ipfw on FreeBSD and Mac OS X systems) and libpcap.
1.9.12 is a significant release that moves by default to the new libfko and the new FKO module for SPA encryption and decryption. Other new features include interface monitoring for the fwknopd daemon so it can survive administrative changes due to things like a DHCP address changes, and the ability to send SPA packets through HTTP proxies.
Here’s an excerpt from the 1.9.12 ChangeLog appears below:
- Fully integrated the FKO module that is part of the libfko library for all SPA routines – encryption/decryption, digest calculation, replay attack detection, etc. The default is to always use the FKO module if it has been installed, but the original perl code remains intact as well just in case FKO does not exist on the local system. The libfko code can be viewed with Trac here.
- Added the ability to recover from interface error conditions, such as when fwknopd sniffs a ppp interface (say, associated with a VPN) that goes away and then is recreated. In previous versions of fwknop, this would result in the fwknopd daemon no longer able to receive SPA packets. This new functionality is controlled by five new configuration variables in the fwknop.conf file: ENABLE_INTF_CHECKS, INTF_CHECKS_INTERVAL, ENABLE_INTF_EXISTS_CHECK, ENABLE_INTF_RUNNING_CHECK, and ENABLE_INTF_BYTES_CHECK. By default, all of these checks are enabled and are run every 20 seconds by the knoptm daemon. If any check fails, then knoptm stops the fwknopd daemon once the error condition is corrected (such as when the interface comes back) so that knopwatchd will then restart it. The fwknopd daemon cannot receive packet data until the error condition is cleared (most likely except perhaps for the “RUNNING” check, but restarting the fwknopd daemon is better than not being able to access a service).
- Updated the fwknop client to include the SPA destination before DNS resolution when sending an SPA packet over an HTTP request. This allows more flexible Apache configurations with virtual web hosts to function properly with HTTP requests that contain SPA packet data. Also updated the fwknop client to include a leading “/” in SPA packets over HTTP, and updated the fwknopd server to strip this out before attempting SPA packet decryption.
- Updated the fwknop client to resolve external IP addresses (with the -R argument) here by default.
- Submitted patch to the fwknop client to add HTTP proxy support when sending SPA packets over HTTP. The result is a new –HTTP-proxy option that expects the proxy host to be given as “http://HOST”, and it also supports the “http://HOST:PORT” notation as well.
To find out more read our interview with fwknop developer Michael Rash.