fwknop - Single Packet Authorization

Introduction

fwknop implements an authorization scheme known as Single Packet Authorization (SPA) for strong service concealment. SPA requires only a single packet which is encrypted, non-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default-drop filtering stance. The main application of SPA is to use a firewall to drop all attempts to connect to services such as SSH in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) more difficult. Because there are no open ports, any service that is concealed by SPA naturally cannot be scanned for with Nmap. The fwknop project supports four different firewalls: iptables, firewalld, PF, and ipfw across Linux, OpenBSD, FreeBSD, and Mac OS X. There is also support for custom scripts so that fwknop can be made to support other infrastructure such as ipset or nftables.

SPA is essentially next generation Port Knocking (PK), but solves many of the limitations exhibited by PK while retaining its core benefits. PK limitations include a general difficulty in protecting against replay attacks, asymmetric ciphers and HMAC schemes are not usually possible to reliably support, and it is trivially easy to mount a DoS attack against a PK server just by spoofing an additional packet into a PK sequence as it traverses the network (thereby convincing the PK server that the client doesn't know the proper sequence). All of these shortcomings are solved by SPA. At the same time, SPA hides services behind a default-drop firewall policy, acquires SPA data passively (usually via libpcap or other means), and implements standard cryptographic operations for SPA packet authentication and encryption/decryption.

SPA packets generated by fwknop leverage HMAC for authenticated encryption in the encrypt-then-authenticate model. Although the usage of an HMAC is currently optional (enabled via the --use-hmac command line switch), it is highly recommended for three reasons:

Without an HMAC, cryptographically strong authentication is not possible with fwknop unless GnuPG is used, but even then an HMAC should still be applied.
An HMAC applied after encryption protects against cryptanalytic CBC-mode padding oracle attacks such as the Vaudenay attack and related trickery (like the more recent "Lucky 13" attack against SSL).
The code required by the fwknopd daemon to verify an HMAC is much more simplistic than the code required to decrypt an SPA packet, so an SPA packet without a proper HMAC isn't even sent through the decryption routines.

The final reason above is why an HMAC should still be used even when SPA packets are encrypted with GnuPG due to the fact that SPA data is not sent through libgpgme functions unless the HMAC checks out first. GnuPG and libgpgme are relatively complex bodies of code, and therefore limiting the ability of a potential attacker to interact with this code through an HMAC operation helps to maintain a stronger security stance. Generating an HMAC for SPA communications requires a dedicated key in addition to the normal encryption key, and both can be generated with the --key-gen option.

fwknop encrypts SPA packets either with the Rijndael block cipher or via GnuPG and associated asymmetric cipher. If the symmetric encryption method is chosen, then as usual the encryption key is shared between the client and server (see the /etc/fwknop/access.conf file for details). The actual encryption key used for Rijndael encryption is generated via the standard PBKDF1 key derivation algorithm, and CBC mode is set. If the GnuPG method is chosen, then the encryption keys are derived from GnuPG key rings.

Use Cases

People who use Single Packet Authorization (SPA) or its security-challenged cousin Port Knocking (PK) usually access SSHD running on the same system where the SPA/PK software is deployed. That is, a firewall running on a host has a default-drop policy against all incoming SSH connections so that SSHD cannot be scanned, but a SPA daemon reconfigures the firewall to temporarily grant access to a passively authenticated SPA client:

SPA-basic-access-SSHD "Basic SPA usage to access SSHD"

fwknop supports the above, but also goes much further and makes robust usage of NAT (for iptables/firewalld firewalls). After all, important firewalls are usually gateways between networks as opposed to just being deployed on standalone hosts. NAT is commonly used on such firewalls (at least for IPv4 communications) to provide Internet access to internal networks that are on RFC 1918 address space, and also to allow external hosts access to services hosted on internal systems.

Because fwknop integrates with NAT, SPA can be leveraged to access internal services through the firewall by users on the external Internet. Although this has plenty of applications on modern traditional networks, it also allows fwknop to support cloud computing environments such as Amazon's AWS:

SPA-Amazon-AWS-cloud "SPA usage on Amazon AWS cloud environments"

User Interface

The official cross-platform fwknop client user interface fwknop-gui (download, github) is developed by Jonathan Bennett. Most major client-side SPA modes are supported including NAT requests, HMAC and Rijndael keys (GnuPG is not yet supported), fwknoprc stanza saving, and more. Currently fwknop-gui runs on Linux, Mac OS X, and Windows - here is a screenshot from OS X: fwknop-gui-OS-X-screenshot "fwknop-gui on Mac OS X" Similarly, an updated Android client is available as well.

Tutorial

A comprehensive tutorial on fwknop can be found here:

http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html

Features

The following is a complete list of features supported by the fwknop project:

fwknop