Single Packet Authorization

Single Packet Authorization fills the gaps in port knocking.

Single Packet Authorization provides similar security benefits to port knocking in terms of protecting services with a packet filter that is configured in a default-drop stance. Anyone scanning for a target service that is protected in this way will be unable to detect such a service is listening, and this makes even the exploitation of zero-day vulnerabilities much more difficult. SPA offers elegant solutions to many limitations in port knocking implementations. These allow SPA to solve the replay problem, achieve a data transmission rate that makes the use of asymmetric encryption possible, thwart simple spoofing attacks and remain under the radar of intrusion detection systems that are monitoring networks for port scans.

See next month's LJ for Part II to this article, which will show exactly how to use SPA.

Michael Rash holds a Masters' Degree in applied mathematics with a concentration in computer security from the University of Maryland. Michael is the founder of, a Web site dedicated to open-source security software for Linux systems, and he works as Security Architect on the Dragon Intrusion Detection System for Enterasys Networks. He is the author of the upcoming book Linux Firewalls: Attack Detection and Response, published by No Starch Press.



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.