This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Networking

Fwknop and single packet authorization

By Robert D. Currier on May 20, 2008 (9:00:00 AM)

Share    Print    Comments   

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.

Bob Currier is a senior data engineer at Mote Marine Laboratory in Sarasota, Florida, where he manages a Linux server farm and writes code for a fleet of autonomous underwater vehicles. He is the author of more than 100 features, reviews, and opinion pieces in Linux.com, Network World, ZDnet.com, Smart Computing, and other trade publications.

Share    Print    Comments   

Comments

on Fwknop and single packet authorization

Note: Comments are owned by the poster. We are not responsible for their content.

sniffing port knocks?

Posted by: Anonymous [ip: 198.36.89.8] on May 20, 2008 02:18 PM
The article doesn't go into this but what I want to know is whether the key is encryted, used as a hash, etc. or is it just sent in the clear with the port knock? If it clear text, what stops anyone sniffing the connection from noticing that ssh sessions are preceeded by our key bearing portknock, and simply replaying the knock/key?

#

Re: sniffing port knocks?

Posted by: Anonymous [ip: 24.72.92.155] on May 20, 2008 10:19 PM
According to the overview here, http://cipherdyne.org/fwknop/index.html, SPA packets aren't replayable.

#

Fwknop and single packet authorization

Posted by: Galik on May 20, 2008 04:38 PM
I also suspect it is not much different that a straight forward password system. In fact I fail to see the difference. However I suppose the benefit is that the ports are not open to network scrutiny until after the password is given, and then only for a limited time. I suppose that adds another layer of security to the onion.

#

Fwknop and single packet authorization

Posted by: Anonymous [ip: 200.201.164.12] on May 20, 2008 10:37 PM
As someone who has used FWKnop, it is not only a "forward password system". You can use it to run a remote command (like sending the correct SPA packet triggers a reboot) or you can even send commands to be run in the server, embedded on the packet.

The packet is not replayable cause FWKnop rejects more than one packet per unit of time (60s if I remember the default) and it does not allow for a packet to be accepted with more than x seconds of difference in time, which literally blocks any replay attemp.

It can use PGP public/private keys so it can verify both client and server, which is even nicer.

I really don't know why fwknop is not more known, it's a fantastic tool. (and no, it's not security through obscurity, it's more like the onion metaphor).

#

Re: Fwknop and single packet authorization

Posted by: Anonymous [ip: 85.205.248.79] on May 21, 2008 08:52 AM
Just to add to the clarifications. The authentication/authorization data contained in an fwknop 'auth. packet', is encrypted but also integrity protected by using a SHA-256 hash over the entire content of the packet, that the server stores in a hash log and checks any subsequent auth packet hashes against, to check for replays. The auth packet also contains a timestamp, and if fwknop receives any packet that is older than 120 seconds (by default), that packet is silently rejected. So it helps ensure fresh and non-replayable packets.

For a detailed look at how Port Knocking and SPA work, check out http://www.securethoughts.net/spa/ . For anyone interested in learning more about SPA and its usage, you are welcome to post on the Port Knocking and Single Packet Authorization Forums (http://www.securethoughts.net/forum/viewforum.php?f=6).

// SJ

#

Fwknop and single packet authorization

Posted by: Anonymous [ip: 65.103.68.37] on May 24, 2008 08:17 AM
I think it is a great system, but I would like to see have a compiled version so I don't have to load perl on to my firewall. I would like to see a GUI tool that I can give to clients to open a connection (for Linux/Mac/Windows), maybe in Java.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya