fwknop: Single Packet Authorization in Ubuntu

Posted by admin on June 24, 2007 under Tech Tips | Be the First to Comment

WARNING! THIS POST HAS BEEN MARKED AS OUTDATED!

While there may be useful information still contained within the article, there may be other more relevant articles out on the Internet. Please pay close attention to version numbers of software that this article refers to. If you’re not careful, you could break your system if you do not understand what you are doing. If you would like to see this article updated, please contact the site administrator using the Contact page. Thanks!

Updated (11/21/2007): I’ve added an updated version of this How-to on the community supported Ubuntu documentation site. The new document can be found at: https://help.ubuntu.com/community/SinglePacketAuthorization.

Single Packet Authorization (SPA) using “fwknop” is probably one of the coolest recent innovations in server and network access control technology. Just what is SPA, you ask? SPA is a method of limiting access to server and network resources by cryptographically authenticating users before any type TCP/IP stack access is allowed.

In it’s simplest form, your Linux server can have an inbound firewall rule that by default drops all access to any of it’s listening services. Nmap scans will completely fail to detect any open ports, and zero-day attacks will not have any effect on vulnerable services since the firewall is blocking access to the applications.

The server however has a nifty trick up it’s sleeve. An authorized user sends a single encrypted UDP packet that is passively sniffed and analyzed by the fwknopd service running on the server using pcap. If successfully authenticated, fwknopd dynamically creates an iptables firewall rule, granting the source IP address of the authorized client access to the service for a defined period of time (default is 30 seconds). Pretty frickin’ cool, eh?

Okay, so here’s how to get it working in Ubuntu 7.04.

In this example, the service we will be protecting is SSH. I will be using a simple firewall rule that blocks all inbound connections, but has an unrestricted outbound policy. The client will authenticate using a GNUPG key pair.

1. We start by setting up the firewall. I’ve provided a firewall script below that should work for most configurations. Tailor this to your needs. Do NOT use this script unless you know for sure you want all traffic blocked.

$ wget https://savvyadmin.com/downloads/firewall
$ sudo cp firewall /etc/init.d/firewall
$ sudo chmod 755 /etc/init.d/firewall
$ sudo update-rc.d firewall defaults 10
$ sudo /etc/init.d/firewall start

2. Install fwknop prerequisites.

$ sudo apt-get install build-essential libpcap-dev mailx -y

3. Download latest version of fwknop from the official website, and install.

Site: http://www.cipherdyne.org/fwknop/download/

$ wget http://www.cipherdyne.org/fwknop/download/fwknop-1.8.1.tar.gz
$ tar zxvf fwknop-1.8.1.tar.gz
$ cd fwknop-1.8.1
$ sudo ./install.pl

(The installer will ask you a couple of questions. You will need to provide the interface you wish the service to monitor, and specify that the installation should run as a server).

$ sudo update-rc.d fwknop defaults 20

4. You (the client) and the server should use individualized PGP key pairs for this to work as securely as possible. The client will use it’s own private key to digitally sign the SPA packet payload, and then use the servers public key to encrypt it as well. The server will use the clients public key and digital signature to verify that the SPA packet originated from a trusted source. This means that both the server and the client will need a signed copy of each others public keys in their keyring.

The instructions on how to generate these key pairs are located at:

http://www.cipherdyne.org/fwknop/docs/gpghowto.html

Once you have followed the sites instructions, you’re almost ready to have SPA working. I know it’s a lot to take in if you are not familiar with the concepts behind the PGP cryptosystem, so make sure to read up on it if you’re feeling a bit lost. Gnupg’s manual is located here.

5. As also mentioned in the above referenced article, you will need to edit the fwknop configuration file “/etc/fwknop/access.conf”. An example of this configuration is shown below.

SOURCE: ANY;
OPEN_PORTS: tcp/22;
DATA_COLLECT_MODE: PCAP;
GPG_HOME_DIR: /root/.gnupg;
GPG_DECRYPT_ID: SERVER_KEY_ID;
GPG_DECRYPT_PW: PASSWORD_HERE;
GPG_REMOTE_ID: CLIENT_KEY_ID;
FW_ACCESS_TIMEOUT: 30;

6. Start the fwknopd service:

$ sudo /etc/init.d/fwknop start

7. You should now be ready to test things out using another computer with the fwknop client. You install everything exactly the same as the server, with the exception of specifying that the installer should run fwknop as a client.

The typical authorization process from client to server can be completed as follows.

$ fwknop -A tcp/22 --gpg-recip SERVER_KEY --gpg-sign CLIENT_KEY -w -k SERVER_IP

The “-w” flag queries www.whatismyip.com for the clients real ip address and uses that as the source address. This is useful when you are behind a NAT firewall, since the source address specified on the SPA packet would otherwise be a local address.

If you are on the same network as the server, or simply do not have to worry about NAT, the syntax would be as follows:

$ fwknop -A tcp/22 --gpg-recip SERVER_KEY --gpg-sign CLIENT_KEY -a CLIENT_IP -k SERVER_IP

If successful, your server adds the appropriate access list entry for you to connect using your ssh client. You will have 30 seconds to make the connection, after which the access list is dynamically removed.

$ ssh username@SERVER_IP

It is important to note that the SPA packet is sent to the servers IP address using the destination port of UDP/62201. You must ensure that this port number is allowed outbound from the network you are connecting from, and that no router or firewall is blocking it from reaching your server.

It should also be noted that the time stamp embedded in the SPA packet must fall within 120 seconds of the servers clock. You should make sure that both the server and client are using NTP to keep their clocks as close as possible.

Check out your syslogs and iptables output for useful information while testing.

$ watch -n1 sudo iptables -L -n
$ tail -f /var/log/syslog

Hope this provides you with some very useful information to get you started with SPA.