cipherdyne.org

Michael Rash, Security Researcher



Frequently Asked Questions


1. General

1.1. What is fwknop?

fwknop implements an authorization scheme known as Single Packet Authorization (SPA) that requires only a single encrypted packet to communicate various pieces of information including desired access through a Netfilter policy and/or specific commands to execute on the target system. The main application of this program is to protect services such as SSH with an additional layer of security in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) much more difficult. The authorization server passively monitors authorization packets via libpcap and hence there is no "server" to which to connect in the traditional sense. Any service protected by fwknop is inaccessible (by using Netfilter to intercept packets within the Linux kernel) before authenticating; anyone scanning for the service will not be able to detect that it is even listening. This authorization scheme offers many advantages over port knocking, include being non-replayable, much more data can be communicated, and the scheme cannot be broken by simply connecting to extraneous ports on the server in an effort to break knock sequences. The authorization packets can easily be spoofed as well, and this makes it possible to make it appear as though, say, www.yahoo.com is trying to authenticate to a target system but in reality the actual connection will come from a seemingly unrelated IP. Although the default data collection method is to use libpcap to sniff packets off the wire, fwknop can also read packets out of a file that is written by the Netfilter ulogd pcap writer.

1.2. What is the difference between Single Packet Authorization and Port Knocking?

Both technologies communicate information via packets destined to a port or ports on which no server is listening. The packets can be monitored by sniffing the wire via libpcap, or by monitoring firewall logs. The main application of this technology is to use a packet filter (such as a firewall or router ACL) to maintain a default drop stance for a protected service, but allow a remote system to communicate desired access to the protected service. This way the code paths available to a malicious user are minimized since a decent packet filter intercepts packets from within the kernel, and therefore an attacker cannot even establish a session with the protected service.

This is where the similarities end, and you can find a detailed explanation of exactly why Single Packet Authorization is better than port knocking in my USENIX ;login: paper "Single Packet Authorization with Fwknop".

In summary, Single Packet Authorization (SPA) provides the following advantages over port knocking schemes:
  • Single Packet Authorization messages can communicate much more information because the packet payload is used rather than just the packet headers to transmit data. Port knocking schemes typically encode information as sequences of connections to ports, and the sequence itself represents the information being transmitted. Due to the fact that the port fields of the TCP and UDP headers are only 16 bits wide, each individual packet of a port knock sequence can only communicate two bytes of information. It should be noted that other packet header fields could also be used within a port knocking scheme in order to increase the amount of data that can be transmitted, but any conceivable variation of this will not be able to communicate nearly as much data as any method that makes use of the payload portion of IP packets.
  • Single Packet Authorization is much faster. Port knocking schemes must artificially introduce time delays between successive knock packets because there is no notion of a connection with reliable in-order delivery. Packets that arrive out of sequence would break any shared or encrypted port knock sequence agreement between the client and server. By contrast, SPA only requires a single packet to communicate all desired access or command information.
  • Replay attacks are easily be thwarted by including random data within SPA messages and then tracking MD5 sums on the server side. This is much cleaner than methods employed by port knocking schemes that involve relatively complicated state sharing mechanisms that require time synchronization or successive iterations of a hashing function.
  • An attacker cannot easily break the SPA scheme be simply connecting to ports that may be used to communicate authorization messages. In port knocking schemes, if an attacker simply spoofs duplicate packets from the same IP that initiates a legitimate knock sequence to the same target IP, then the sequence will effectively be broken by the attacker.
  • SPA has a much smaller network footprint in terms of alarms that may be generated by an intrusion detection system that monitors the authorization messages. By contrast, a port knocking sequence could easily be detected and interpreted as a port scan by any IDS that has its port scan detection thresholds set low enough.
  • SPA can utilize any IP protocol; even those without any concept of a "port". The fwknop SPA implementation includes support for sending authorization messages over ICMP.

1.3. Why are you releasing it?

Because security bugs are frequently discovered in all sorts of software, including security software such as VPN and encrypted shell services, and so providing an additional layer of security can mean the difference between being compromised or not. I want to see how far the notion of an authenticating Ethernet sniffer (which essentially characterizes what fwknop does) can go towards enhancing system and network security.

1.4. Is there a mailing list?

Yes, SourceForge is generous enough to host the fwknop mailing list.

1.5. What platforms are supported?

The fwknop client runs on platforms such as OS X, FreeBSD, various Linux distributions, and Windows systems under Cygwin. There is also a Windows UI (developed by Sean Greven) that can generate SPA messages without having the fwknop client installed. The fwknopd server is compatible with Linux, Mac OS X, and *BSD systems that run the iptables, ipfw, or pf firewalls.

1.6. What firewalls are supported?

The iptables firewall on Linux systems, the ipfw firewall on *BSD and Mac OS X, and the pf firewall on OpenBSD systems are supported as fwknop-2.0 release. It will be possible to extend fwknopd server support to other firewalls and router ACL's through the use of command execution mode as well.

1.7. Is fwknop available as a Debian or RPM package?

Yes, fwknop is available as an RPM package and Debian packages are available as well (thanks to Franck Joncourt). A howto for installing fwknop on Debian and Ubuntu is available in this blog post.

1.8. What source control system is used by the fwknop project?

fwknop uses git for source control, and the source code can be viewed over the web with gitweb here.

1.9. Is detailed documentation available?

Yes. All documentation on fwknop, including man pages and configuration guides, can be found here. A comprehensive tutorial is also available here: here.

1.10. Is there a complete list of features that fwknop supports?

Yes, the features list can be found here: features.

1.11. How can I make a suggestion or bug report for fwknop?

Both suggestions and bug reports are always welcome and greatly appreciated. Just send email to Michael Rash with your suggestion or bug report. If your suggestion or bug report ends up changing the code in any way then you will be added to the CREDITS file and the online list of contributors.

2. Operational

2.1. What types of services can be protected by fwknop?

Technically, any service that can be filtered by a Netfilter policy is a candidate for protection by fwknop. Having said this however, fwknop is most commonly used to provided an additional layer of security for services that typically have long running sessions such as OpenSSH or OpenVPN.

2.2. Does fwknop have a small OS footprint?

fwknop is entirely written in C, and has a very small footprint. For example, the fwknopd daemon is able to run on small embedded systems such as the Linksys WRT54G router that has been reflashed with OpenWRT.

2.3. What ciphers are supported by fwknop?

Supports both Rijndael and GnuPG methods for the encryption/decryption of SPA packets. In the upcoming fwknop-2.5 release, HMAC-SHA256 will be supported for authentication in the "encrypt-then-authenticate" paradigm as well.

2.4. Is fwknop compatible with SELinux?

Given that complex programs such as tcpdump and iptables that need specialized system access are compatible with SELinux, fwknop is also compatible. However, there isn't yet a list of things that need to be altered in an SELinux policy in order to make fwknop work properly. Depending on its configuration, fwknopd may need to execute GnuPG and it may also need to put an interface in promiscuous mode (although this can be controlled with the ENABLE_PCAP_PROMISC variable in the /etc/fwknop/fwknop.conf file). On Linux, fwknopd always needs to execute iptables commands to alter the local iptables policy when a valid SPA packet is seen. If you have fwknop working under SELinux and you don't mind sharing, please send the steps necessary to get this to work to mbr.at.cipherdyne.org, and I will post these steps here (with attribution of course).