Fwknop and single packet authorization

Protecting servers by placing them behind a firewall is a best-practice methodology for systems administrators, but it’s not a panacea: those systems are still visible to network scanners such as nmap and nessus. While services like SMTP and HTTP may need to be accessible to the public, most enterprises also have private internal servers that require external access by traveling support staff. For those users, fwknop, an open source utility that provides single packet authorization, can help sysadmins hide their servers from network nasties.

Single packet authorization is a descendent of port knocking, a technique that’s been around since 2003. As defined by Wikipedia, port knocking is “a method of externally opening ports on a firewall by generating a connection attempt on a set of prespecified closed ports. Once a correct sequence of connection attempts is received, the firewall rules are dynamically modified to allow the host which sent the connection attempts to connect over specific port(s).”

Single packet authorization distills the essence of the port knocking concept down to a single packet. Rather than sending a series of packets to predefined ports, single packet authorization encodes the “knock” within the payload of one packet. Once a proper key has been received, SPA applications modify firewall rules to allow access to the authenticated host. We’ll examine how this is accomplished by installing and testing the Firewall KNock Operator, better known as fwknop.

Developed by Michael Rash, a security researcher at Cypherdyne.org and the author of Linux Firewalls, fwknop is available for download as a binary package, source package, or tarball. We’ll install from source using the tarball to give a better understanding of how the application functions.

Before you download and install fwknop you’ll need to round up two hosts to act as your test lab. The first host will be the single packet authorization client, and the second will be the server. Make sure that the box you choose for your server isn’t a production machine. We’re going to configure iptables access policy to explicitly deny all SSH connections, and that’s something you don’t want to do to a production server. We also suggest that your test platform be a local machine; restoring access to a remote server after you’ve clamped down on firewall policies can be a difficult task.

After downloading fwknop, uncompress and extract the source on both the client and server. Fwknop differs from most source distrbutions in that there isn’t a ./configure script to be used in the normal configure, make, make install sequence. Instead, fwknop uses a Perl script called install.pl to build and install the application. After successfully running install.pl you should have a working fwknop installation. Make sure you have root access when installing fwknop on your server. If you lack root privileges, fwknop will be installed as a client and not as a server, preventing you from proceeding with the single packet authorization test.

Check your installation of fwknop for proper setup by executing the ./fwknop_test.pl script, which is located in the test subdirectory of your fwknop installation. This script took about four minutes to complete 121 tests on our Dell PowerEdge 850 server running CentOS 4. Don’t worry about missing any error messages if you walk away, as the test script records its output in a log file.

Fwknop’s access control policy file is called access.conf and is located in /etc/fwknop on the fwknop server. We’ll use the default settings for our test except for the key. Edit /etc/fwknop/access.conf and skip to the end of the file. Find the line beginning with KEY: and change the key to a sequence of at least eight characters. We chose “myt3stk3y!” for our demonstration.

Locking the door

Once you’ve successfully installed fwknop it’s time to lock down your server. We’ll keep things simple for our demonstration and stick to limiting SSH access. Fwknop is capable of much more than that, however; if you’re interested in pursuing fwknop in depth, read Rash’s Linux Firewalls, which goes into depth on installing and deploying fwknop.

Prior to deploying fwknop, our iptables policy for SSH access looked like this: -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT A quick test reveals that we have no problems connecting to the SSH server from our client:

[user@client-box]$ ssh 192.168.1.130
login as: user
user@192.168.1.130's password: xxxxxxxxxxx
Last login: Mon May  5 15:35:51 2008 from 192.168.1.129
[user@chipotle ~]$

Now reconfigure iptables on our server to deny SSH access. Be careful, as it’s easy to lock yourself out of the server. Most systems administrators would typically use a command-line utility like Red Hat’s system-config-security to change access settings, but for this test we’ll use a text editor, as we only need to change one setting.

Edit /etc/sysconfig/iptables (you’ll need to have root priviledges to do this) and search for the line ending with --dport 22 -j ACCEPT. This is the rule governing SSH access. Change ACCEPT to REJECT and save the file. Restart iptables by running the command /etc/init.d/iptables restart and the new policy will be activated.

To test the modification we’ll try another SSH session from the client to the server. The SSH connection should be rejected with a message similar to ssh: connect to host 192.168.1.130 port 22: Connection refused. If you don’t get a message like this, check that the modification you made to iptables is correct and that you successfully restarted iptables. Your changes won’t go into effect without a valid restart.

Unlocking the door

Now that you’ve restricted SSH access you need to activate fwknop to allow the client access privileges. You can start fwknop in one of two ways. The normal method is /etc/init.d/fwknop start, which puts fwknop in daemon mode. We’ll take advantage of fwknop’s debug mode by executing the command ./fwknopd --d in our installation directory. Fwknop should respond by printing a list of firewall rules and a prompt that reads:
"Sniffing (promisc) packet data from interface: eth0
Wed May 7 10:39:57 2008 [+] pcap_loop()


Fwknop is sniffing packets and waiting for us to send an authorization key.

Using the client machine, switch to the fwknop installation directory and enter ./fwknop -A tcp/22 -k 192.168.1.130, subsituting the IP address of your fwknop server for the 192.168.1.130 entry. You’ll be prompted to enter a key; make sure you use the key you defined in /etc/fwknop/access.conf.

Once a valid key has been sent to the fwknop server you have 30 seconds (you can change this setting by editing /etc/fwknop/access.conf) to initiate an SSH connection. Let’s give it a try:

  [user@client-box]$ ssh 192.168.1.130
  login as: user
  user@192.168.1.130's password: xxxxxxxxxxx
  Last login: Mon May  5 15:39:51 2008 from 192.168.1.129
  [user@chipotle ~]$

We’ve just logged in successfully.

If you are able to SSH to your fwknop server, congratulations — you now have a working single packet authorization deployment. If your login attempt failed, read the debug output from the fwknop server and make sure the access key you submitted matches what’s in /etc/fwknop/access.conf. Key entry mistakes are a common source of errors.

Moving on from here

While we’ve only covered one service in this tutorial, expanding fwknop to provide protection for many services is a straightforward process. You can easily add additional services by defining them in /etc/fwknop/access.conf and restarting fwknop.

Fwknop isn’t appropriate for all situations, but if you’re a systems administrator who needs access to critical assets from outside your enterprise, it’s a great way to hide your systems. If the bad guys can’t see your house, they can’t huff and puff and blow your doors down.