cipherdyne.org

Michael Rash, Security Researcher



fwknop: Single Packet Authorization and Port Knocking

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

You can clone the fwknop git repository as follows through github or through cipherdyne.org:
$ 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.

--or--

$ git clone http://www.cipherdyne.org/git/fwknop.git fwknop.git
Cloning into 'fwknop.git'...
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 have a 0-day exploit or not. The authorization server passively sniffs authorization 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 a valid encrypted 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):

Network diagram to illustrate the deployment of fwknop within an iptables firewall
Single Packet Authorization retains the benefits of Port Knocking (i.e. service protection behind a default-drop packet filter), but has the following advantages over Port Knocking:

  • SPA can utilize asymmetric ciphers for encryption. Asymmetric ciphers typically have larger key sizes than symmetric ciphers, and the data transmission rate of port knocking (which uses packet headers instead of packet payloads as used by SPA) is not sufficient to effectively use an asymmetric cipher. SPA is compatible with 2048-bit Elgamal GnuPG keys, and other asymmetric ciphers can be used as well.
  • SPA is authenticated with an HMAC in the encrypt-then-authenticate model. Due to limits on data transmission, it is difficult to use strong authentication within port knocking protocols.
  • SPA packets are non-replayable. There are strategies (such as S/Key-style iteration of a hash function) used by port knocking implementations to reduce the danger of a replayed knock sequence, but these strategies are relatively brittle and not generally very scalable to lots of users.
  • SPA cannot be broken by trivial sequence busting attacks. For any attacker who can monitor a port knocking sequence, the sequence can be busted by simply spoofing a duplicate packet (as though it comes from the source of the real sequence) to the previous port in a sequence.
  • SPA only sends a single packet over the network, and hence does not look like a port scan to any intermediate IDS that may be watching. This is not to say that SPA is impossible to detect - it is just that intrusion detection systems are not generally trying to detect SPA. In contrast, many many intrusion detection systems are already trying to detect port scans today, so using port knocking will call unwanted attention essentially by default.
  • SPA is much faster because it only sends a single packet. Port knocking implementations must build in time delays between successive packets because there is no guarantee of in-order delivery.

More information Single Packet Authorization and port knocking can be found here:


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.