Single Packet Authorization

Single Packet Authorization fills the gaps in port knocking.
Single Packet Authorization

The end result of the above discussion is that port knocking provides some real benefits that enhance security, but some serious limitations also need to be addressed. Single Packet Authorization is a relatively new protocol that retains all of the benefits of port knocking, but fixes the limitations discussed above. The first publicly available SPA implementation was released in May 2005 as a piece of software called fwknop ( fwknop was originally created in 2004 as the first port knocking implementation to combine passive OS fingerprinting and port knocking (this made it possible to do things like “accept knock sequences only from Linux-2.4 systems”), but the SPA method is now the most popular (and default) authentication method offered by fwknop. Note that fwknop provides both authentication and authorization services, but a full discussion of the difference between the two is beyond the scope of this article.

Single Packet Authorization mandates a similar architecture to port knocking. Both have client and server components, the server maintains control of a default-drop packet filter, and the server monitors packets passively. However, this is where the architectural similarities between port knocking and SPA diverge.

Single Packet Authorization moves the data transmission to where it belongs—in the application layer. This implies that instead of being able to send only two bytes of data per packet, as in the case of port knocking, SPA is able to send up to the minimum MTU worth of data (1,500 bytes on Ethernet networks) between the client and the server in each packet. This far outstrips the data transmission rate possible with port knocking, and having easy access to this amount of packet data opens up a huge range of possibilities. The remainder of this article discusses Single Packet Authorization as implemented by fwknop.

fwknop defines the following packet format at the application layer:

  • 16 bytes of random data

  • Client username

  • Client timestamp

  • fwknop version

  • Mode (access or command)

  • Access (or command string)

  • MD5 sum

Many of the fields in the SPA packet format have a variable length, but are separated by a : character (fields are base64-encoded, so embedded colons cannot break this syntax). Once the fwknop client builds the packet format above, the entire packet is encrypted using one of two encryption algorithms: the Rijndael symmetric block cipher with a 128-bit shared key or the asymmetric ElGamal algorithm with up to a 2,048-bit public/private key pair generated by GnuPG. By default, the fwknop client sends SPA packets over UDP port 62201, but this easily can be changed from the command line; see the --Server-port argument. (fwknop offers many configuration options—see Resources for a link to the documentation and man pages.) For a graphical representation of SPA in action, see Figure 2.

Figure 2. SPA in Action

So, what are all the fields for? First, the 16 bytes of random data allows one of the highest priority limitations in port knocking to be solved—the replay problem. Every SPA packet is prepended with 16 bytes of random data before being encrypted, and then upon a successful decrypt by the fwknop server, the MD5 sum of the entire packet is cached. The random data allows every SPA packet to be different (even when the same access directive is sent), so the MD5 sum of every packet also has a high probability of being different. If the MD5 sum of any new packet matches the sum of a previous packet, the fwknop server takes no action and writes a warning message to syslog. Hence, any SPA packet that is intercepted by a third party cannot be replayed on the network in an effort to get access through the default-drop packet filter.

The client username and timestamp are placed within the packet by fwknop and the username is used to maintain different authorization levels for remote users by the fwknop server. fwknop can be installed on a multiuser system, and each user can be authorized to connect to different services by a remote fwknop server. The fwknop version field is used to maintain backward compatibility. Fields can be added or deleted in new releases of fwknop, but by using the version number, the fwknop server can remain compatible with the manner in which older clients build SPA packets. The mode field tells the fwknop server whether the client wants to access a service or execute a command (with the specific access control directive or command in the next field). For example, to gain access to TCP port 22, the Access field would contain the string <IP>,tcp/22 where <IP> is whatever IP address the client chose to put in the packet. Finally, the MD5 sum field contains the MD5 sum of the unencrypted packet before the client transmits it. This is used by the server to verify message integrity after decryption.

We already have seen how the increased amount of data that can be transmitted via an SPA packet has solved the replay problem and the extremely low data transmission rate in port knocking schemes. We have two remaining limitations in port knocking that need to be addressed. First, the single packet nature of the SPA protocol means that a malicious third party cannot break the authentication scheme just by spoofing a packet to the same port over which a monitored SPA packet is sent. Finally, because the SPA protocol requires only a single packet, it does not appear to any intermediate IDS like a port scan. All that any IDS can see is an unintelligible blob of data seemingly spuriously sent to some IP address.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

fwknop and SELINUX on FC6

Andy B's picture

I can't seem to implement the fwknop daemon on FC6 with SELINUX running. Has anyone come up with a policy that allows iptables to write to the /var/log/fwknop directory? Disabling SELINUX is not an option here, but might be for others.

Michael Rash

mrash's picture

Although I haven't run fwknop on an SELINUX system, I would think that if you have apache or mysql installed and running, then you could use the same SELINUX policy settings that are applied to those daemons. They also write to directories like /var/log/apache2 and /var/log/mysql. In fwknop, the fwknopd and knoptm daemons need to write to files in /var/log/fwknop, and all three of fwknopd, knopwatchd, and knoptm daemons need to write to files in /var/run/fwknop/.


marc's picture

Think this USENIX article should be listed in the references!

Single Packet Authorization with Fwknop
by Michael Rash

ok ok...

marc's picture

my mistake... its the same guy


Open Mouth Insert Foot's picture

Drool on your keyboard much?

16 bytes of random data?

Anonymous's picture

>Every SPA packet is prepended with 16 bytes of random data before being
>encrypted, and then upon a successful decrypt by the fwknop server, the
>MD5 sum of the entire packet is cached.

Assuming the attacker can encrypt packets, does this provide any additional security? Couldn't an attacker just replace the first 16 bytes with their own arbitrary data?

Caching the MD5

Anonymous's picture

Perhaps I'm missing something, but how long must you keep previous MD5 hashs lying about to compare every new packet received? It would seem that if someone replayed after the MD5 cache was purged/recycled you could replay the message. True?

Re: Caching the MD5

anonymous's picture

By default fwknopd also requires that SPA packets are not older than two minutes (see the MAX_SPA_PACKET_AGE variable in the /etc/fwknop/fwknop.conf file), so even if the MD5 sum cache is removed, this is of little use to an attacker. Note that the SPA age is determined from a time stamp that is included within the encrypted SPA message, so even if an attacker intercepts an SPA packet the original time stamp cannot be changed.

The packet is encrypted and

sb's picture

The packet is encrypted and the attacker doesn't have your private key. If he tries to change a single bit, the entire packet will be rejected as garbage.

Of course, if whitelisting

Anonymous's picture

Of course, if whitelisting is used then potentially some of this is effectively a moot point, is it not?

Well, the description of SPA

Anonymous's picture

Well, the description of SPA says that two methods can be used for encryption: Rijndael symmetric block cipher or the asymmetric ElGamal algorithm.

If you're using symmetric crypto, obviously you have to provide the key to every client that will need access. (Possibly a bad idea if there are multiple clients.) If you're using asymmetric crypto, the attacker doesn't need your private key to encrypt messages - just your public key. In this case it is feasible that an attacker could encrypt their own packets.

The random data just prevents replay attacks (using captured packets that were previously encrypted).

Re: Well, the description of SPA

mrash's picture

Hello - If asymmetric crypto is used, then the fwknop SPA server requires that that SPA packet is cryptographically signed by an approved client private key. So, it is true that an arbitrary client can encrypt an SPA packet with the server public key (which is published to the world), but the SPA server will reject it because it is not also signed. Part II of this article will illustrate this, but in the meantime here is a howto for using GnuPG for SPA encryption. Note the GPG_REMOTE_ID variable in the SPA server config specifies the client key ID's that must sign an asymmetrically encrypted SPA packet.