Single Packet Authorization with Fwknop
The February 2006 ;login: features Single Packet Authorization with Fwknop (.pdf, USENIX members only until Feb 07) by Mike Rash, who I was lucky to meet at ShmooCon 2006. This is a great concept, illustrated by the following article excerpts.
So far we have discussed the two most important ways that port knocking is used to enhance security: the passive communication of authentication information, and the server-side use of a packet filter to intercept all attempts to connect with a real server that are not associated with a knock sequence. These two features are also used in Single Packet Authorization to increase security, but this is where the similarities between port knocking and SPA abruptly end.
In port knocking schemes, the communication of information within packet headers, as opposed to the packet payload, severely limits the amount of data that can stilll be transferred effectively...
If two bytes of information were all that were required to communicate the desired access to a knock server, this would not be a significant issue, but it is not enough to simply create a mapping between a knock sequence (however short) and opening a port. We also want our messages to resist decoding by an attacker who may be in the enviable position of being able to monitor every packet emanating from the knock client.
This requirement can be satisfied by using an encryption algorithm, but even a symmetric block cipher with a reasonable key size of, say, 128 bits forces at least eight packets to be sent at two bytes per packet.
In other words, SPA is better than port knocking. Why?
Single Packet Authorization has no such limitation, because the application payload portion of packets is used to send authentication data. The result is that up to the minimum MTU number of bytes of all networks between the client and server can be sent in a single message, and no cumbersome time delays need to be introduced. Fwknop uses this relatively large data size to communicate not only detailed access requirements in SPA messages, but also entire commands to be executed by the fwknop SPA server.
Of course, all SPA messages are encrypted, and the algorithm currently supported by fwknop is the symmetric Rijndael cipher, but the upcoming 0.9.6 release will also support asymmetric encryption via GPG key rings and associated asymmetric cipher(s)...
The ability to send more than just a few bytes of data within an SPA message is the essential innovation that really makes this possible.
That is awesome. Instead of using a port number for communication, use an entire encrypted packet payload.
Port knocking is potentially "louder" than SPA, too.
Finally, to an observer of network traffic, a port knock sequence is indistinguishable from a port scan-- that is, it is a series of connections to various port numbers from a single IP address. Many network intrusion detection systems have the capability of detecting port scans, and have no way to know that a port knock sequence is not an attempt to enumerate the set of services that are accessible from the IP address of the client system. ..
By contrast, Single Packet Authorization does not create a significant enough network footprint to generate an IDS port scan alert.
I think this is really cool. I wish a FreeBSD implementation existed. :)
So far we have discussed the two most important ways that port knocking is used to enhance security: the passive communication of authentication information, and the server-side use of a packet filter to intercept all attempts to connect with a real server that are not associated with a knock sequence. These two features are also used in Single Packet Authorization to increase security, but this is where the similarities between port knocking and SPA abruptly end.
In port knocking schemes, the communication of information within packet headers, as opposed to the packet payload, severely limits the amount of data that can stilll be transferred effectively...
If two bytes of information were all that were required to communicate the desired access to a knock server, this would not be a significant issue, but it is not enough to simply create a mapping between a knock sequence (however short) and opening a port. We also want our messages to resist decoding by an attacker who may be in the enviable position of being able to monitor every packet emanating from the knock client.
This requirement can be satisfied by using an encryption algorithm, but even a symmetric block cipher with a reasonable key size of, say, 128 bits forces at least eight packets to be sent at two bytes per packet.
In other words, SPA is better than port knocking. Why?
Single Packet Authorization has no such limitation, because the application payload portion of packets is used to send authentication data. The result is that up to the minimum MTU number of bytes of all networks between the client and server can be sent in a single message, and no cumbersome time delays need to be introduced. Fwknop uses this relatively large data size to communicate not only detailed access requirements in SPA messages, but also entire commands to be executed by the fwknop SPA server.
Of course, all SPA messages are encrypted, and the algorithm currently supported by fwknop is the symmetric Rijndael cipher, but the upcoming 0.9.6 release will also support asymmetric encryption via GPG key rings and associated asymmetric cipher(s)...
The ability to send more than just a few bytes of data within an SPA message is the essential innovation that really makes this possible.
That is awesome. Instead of using a port number for communication, use an entire encrypted packet payload.
Port knocking is potentially "louder" than SPA, too.
Finally, to an observer of network traffic, a port knock sequence is indistinguishable from a port scan-- that is, it is a series of connections to various port numbers from a single IP address. Many network intrusion detection systems have the capability of detecting port scans, and have no way to know that a port knock sequence is not an attempt to enumerate the set of services that are accessible from the IP address of the client system. ..
By contrast, Single Packet Authorization does not create a significant enough network footprint to generate an IDS port scan alert.
I think this is really cool. I wish a FreeBSD implementation existed. :)
Comments
An IPS company I worked for used a similar method to communicate with the IPS inline without an IP stack listening on the IPS. Encrypted packets were sent in the direction of an IP on the other side of the device. It would pickup on the encrypted payload, decrypt and return the traffic using the MAC / IP of the original destination. For security through obscurity you could set these packets to be UDP 53 and use the IP of a DNS server. To the casual observer they would look like DNS packets.
--Chris
http://www.blackhat.com/html/bh-blackpage/bh-blackpage-07122005.html
If I recall, their implementation should work fine on FreeBSD, it being perl and all. You can find their BlackHat slides here:
http://dc214.unspecific.com/blackhat05/
http://www.nmrc.org/dc13/bh2005-mh-sn-spa.ppt
* In my ;login: article (which you can find reproduced here with permission from USENIX), I give credit to MadHat for coining the term "Single Packet Authorization". (At first I thought Simple Nomad coined the term, but after asking him about it he said the MadHat actually did).
* MadHat/Simple Nomad and I were working completely independently on the same concept at essentially the same time, and in fact I submitted a talk on March 27, 2005 to the same BlackHat Briefings (well before any abstracts were posted so I had no way of knowing that MadHat/Simple Nomad had also submitted a similar talk), but I titled my abstract "Netfilter and Encrypted, Non-replayable, Spoofable, Single Packet Remote Administration". Although I cannot point you to anything on the BlackHat site that proves that I submitted this abstract, I'm sure that if you wish to check with the BlackHat maintainers that they will confirm that what I say is true. In addition, I submitted my abstract one day after having completed the initial implementation, which I had finished the day before: http://trac.cipherdyne.org/trac/fwknop/changeset/225
* My implementation was based around the Rijndael symmetric cipher instead of GnuPG as in the MadHat/Simple Nomad implementation. As soon as BlackHat posted the accepted talk abstracts, I saw the MadHat/Nomad presentation and recognized the similarity to my implmentation. Because at that point it was clear that BlackHat was not going to accept my presentation, I released fwknop-0.9.0 on May 29, 2005 (I notified Simple Nomad of my intention to do this). Fwknop hence became the first publicly available SPA software that used an encrypted payload.
* I have been working in the passive authorization area for a while now. Fwknop was the first piece of software to combine port knocking with passive OS fingerprinting (at least that I am aware of), and I gave a talk about this at DefCon 12 in 2004.
* There are lots of competing passive authorization mechanisms out there. The ideal solution is going to come down to the implementation that offers the best security properties, and that is the most actively maintained and supported.