Knock Knock Knocking On Firewall’s Door

Raul Siles
Firewall technologies are still today a critical component to protect systems and networks. Standard filtering solutions can be complemented with more advanced techniques to secure the services behind a firewall.
What you will learn...
How to deploy fwknop (an open-source SPA implementation) using FC6 Linux,
The in-depth knowledge about technologies presented in the article,
The basics of port knocking concept.
What you should know...
The standard firewall capabilities.

This entry level article constitutes a brief introduction to a concept known as port knocking, and specifically to one of its derivatives, Single Packet Authorization (SPA). From a practical perspective, the article provides a step-by-step guide for beginners to deploy fwknop (an open-source SPA implementation) using FC6 Linux, and provides additional links for those interested in getting in-depth knowledge about these technologies.
Introduction: Demystifying Firewall Technologies
Trying to demystify firewalls as the one-and-only solution that solves all security threads, it seems useful to exemplify firewall technologies through the following analogy: Firewalls are like traffic lights, they simply allow or deny traffic, and once they allow it, the traffic flows through. A green traffic light indicates traffic is allowed, while a red traffic light indicates traffic is denied. Both scenarios can be directly mapped to firewall rules with an action of allow or deny. Additionally, an amber traffic light indicates traffic is still allowed but with caution; in the firewall world, this can be translated to a rule allowing but logging traffic.
This analogy helps to dismiss firewalls as a unique line of defense for an IT infrastructure, highlighting the need to apply defense in depth principles. The technologies covered in this article provide additional protection to increase the security provided by a firewall, applying defense in depth to the firewall device itself.
Fortunately enough, the usage of a firewall as the one and only protection mechanism was a common thought years ago, but today, any security conscious IT professional knows that multiple technologies are required to prevent, detect and respond to all the different attacks going on through IP-based networks. However, the previous analogy should not devaluate the relevance of firewalls, in the same way traffic lights are crucial to regulate and manage traffic in the real world. Simplifying, firewalls filter traffic based on source IP address and port and destination IP address and port. There are multiple types of firewalling technologies, such as packet filters, stateful filters, proxy gateways, application-level firewalls… but, roughly speaking, they simply increase the granularity and conditions that can be specified in a firewall rule to allow or deny traffic. Therefore, each firewall rule is like a tiny traffic light, managing the flow of certain traffic specified by the rule definition.
Firewalls work by following a statically defined ruleset (except for some temporary rules dynamically generated by stateful filters) that can only be modified manually, by changing the firewall policy through the firewall configuration file or graphical interface. Based on that, one could wonder if this type of solution, a traffic light that is opened (or closed) 24x7, is required in all the scenarios where a firewall is needed. Port knocking, and its related technologies, provides new add-ons to the standard firewall capabilities, avoiding the always on traffic light role, and providing access controls similar to the main door barriers in most buildings, where you need to identify yourself prior to getting temporary access to the facilities.
Port Knocking
Port knocking is a network-based client-server communication mechanism that allows creating new rules in a firewall and, therefore, opening specific ports remotely. Its main advantage is that it makes possible to establish network connections through the firewall using ports that (most of the time) are closed.
The standard port knocking mechanism is based on generating (using the port knocking client) a set of connection attempts on a set of predefined closed ports. These connection attempts will be analyzed by the port knocking server, and once the correct sequence is identified, the firewall ruleset is dynamically modified to add a new rule that allows the source host (client) to connect to a target (previously closed) port.
Some related literature refers to port knocking as an advanced network authentication system, such as the first paper on the topic [ref1] published in 2003. Some port knocking advanced evolutions, like Single Packet Authorization (SPA), are referred as an authorization mechanism [ref2]. Although port knocking and SPA both require authentication and authorization, from a general perspective, they mainly provide advanced remote firewall management capabilities and make the services protected by the firewall stealthier. Their main goal is to remotely manage the firewall policy adding (or removing) new filtering rules. Obviously, these sensitive management tasks must be properly authenticated and provide strict authoritative controls to only allow the modification of certain rules. Port knocking is sometimes negatively identified as a security through obscurity solution, but, it tends to be an additional layer of defense that applies the principle of less privilege to a highly granular level, that is, at the firewall rules level. If a specific firewall rule is not required all the time, what is the advantage of having it always active? The same principle is applied in other security solutions, such as authentication systems that only allow certain users to log in during specific timeframes, such as working hours. Port knocking makes resources available only when they are required, that is, when the user requests them using the port knock sequence.
Finally, port knocking is commonly implemented in two modes. First one is called file mode and is based on configuring a daemon to watch the firewall log files for connection attempts, identify the knock sequence or SPA, and then modify the firewall configuration accordingly. It can also be implemented using network mode, where the process examines packets gathered through live traffic captures using libpcap.
Port Knocking History
The port knocking term was coined by Martin Krzywinski [ref1] [ref4]. Its capabilities were extended by Michael Rash in the original fwknop implementation in 2004 [ref5], combining traditional encrypted port knocking with passive OS fingerprinting. Then, the concept evolved to Single Packet Authorization (SPA), which retains the benefits of port knocking, but has other advantages such as the usage of asymmetric ciphers for encryption, provides non-replayable packets, and a remarkable simplicity and speed because it only sends a single packet over the network. SPA was coined by MadHat in 2005 [ref8] and, at the same time, Michael Rash provided the most commonly used, actively maintained and supported implementation nowadays, fwknop [ref5]. More general details about port knocking and SPA, their benefits, disadvantages and difference can be obtained from the main port knocking portal [ref3] and initial related articles [ref4], from the fwknop homepage [ref5] and from several presentations on the topic between 2004 and 2006 in major security conferences, like Toorcon, Shmoocon, BackHat, DefCon…
Step-by-step guide to deploy SPA using fwknop in FC6
The following section describes step-by-step how to deploy Single Packet Authorization (SPA) using fwknop [ref5] on Linux, using Fedora Core 6 (FC6) for both the client and the server systems. The tool is going to be deployed to manage iptables (Netfilter) acting as a personal firewall to protect a FC6 system, that is, the firewall only filters traffic entering or leaving this single computer. Fwknop can also be deployed on a multi-homed firewall, allowing or denying traffic for other systems or networks.
OS (FC6) Requirements
The examples on this article are based on the Fedora Core 6 (FC6) Linux distribution. A minimal installation was performed on the tests systems (client and server), selecting only the default Base software packages from the Base System group, recommended for creating small router/firewall boxes.
Additionally, the following packages are required:
$ rpm -aq | grep -i libpcap
libpcap-0.9.4-9.fc6
$ rpm -aq | grep -i iptables
iptables-1.3.5-1.2.1
iptables-ipv6-1.3.5-1.2.1
$ rpm -aq | grep perl
perl-5.8.8-10

Step 1. Downloading fwknop
The first step to deploy fwknop is to download the tool from the official homepage, available at http://www.cipherdyne.org/fwknop/download/. The current version available is 1.0 from November 05, 2006. To simplify the installation in FC6, it is recommended to download the RPM package, called fwknop-1.0-1.i386.rpm. Once downloaded to a user directory, for example /home/eric, its MD5 checksum should be verified to check the software integrity. The value must match the one published in the official Web page:
$ md5sum fwknop-1.0-1.i386.rpm
1c4bd61a49dffae3bcacc8ab06b86802
fwknop-1.0-1.i386.rpm

Step 2. Installing fwknop
The next step is to install the fwknop RPM package as root in both, the SPA client and the SPA server:
$ su -
Password:
# rpm -iv /home/eric/
fwknop-1.0-1.i386.rpm
Preparing packages for installation.
fwknop-1.0-1
[+] You can edit the
EMAIL_ADDRESSES
variable in /etc/fwknop
/fwknop.conf
/etc/fwknop/
fwknop.conf to have email
alerts sent to an address
other than root@localhost

Step 3. Pointing to the right libpcap version
The fwknop server (192.168.1.66) requires the packet capture library (libpcap) to capture the network traffic containing the SPA packets. The current version was compiled using the 0.8.3 version of libpcap, but FC6 includes by default the 0.9.4 version. Fwknop can work with the latest version, although it is required to create a symbolic link (just on the server) to point the old version to the new one:
# ln -s /usr/lib/libpcap.so.0.9.4 /
usr/lib/libpcap.so.0.8.3

Step 4. Reviewing fwknop files and directories
In order to understand how a tool works, it is always a good practice to inspect the RPM package contents to list the files the software includes. For those readers interested on all the details, the following command provides the full list of files:
$ rpm -q --filesbypkg fwknop-1.0-1 | more
To sum up, fwknop saves all its configuration files under the /etc/fwknop/ directory. The client binary is called /usr/bin/fwknop and the server binaries are available at /usr/sbin/ (search by *knop*). All the libraries required by the tool are stored under /usr/lib/fwknop/, the documentation (manual pages) are available at /usr/share/man/man8/fwknop* and the tool log files are located at /var/log/fwknop and /var/run/fwknop. The server startup script is called /etc/rc.d/init.d/fwknop and enables the service for run-levels 3, 4 and 5:
# chkconfig --list | grep fwknop
fwknop 0:off 1:off 2:off
3:on 4:on 5:on 6:off

Step 5. Reviewing file and directory permissions
The default root umask that determines the default file permissions in FC6 is 0022, therefore, after installing fwknop some files have too relaxed permissions. It is recommended to restrict them through the chmod command so that they can only be read by root, especially files that contain clear text passwords, such as access.conf:
# umask
0022
# ll /etc/fwknop/
total 72
-rw-r--r-- 1 root root 6147
Nov 6 03:54 access.conf
-rw-r--r-- 1 root root 883
Nov 6 03:54 alert.conf
-rw-r--r-- 1 root root 7637
Nov 6 03:54 fwknop.conf
-rw-r--r-- 1 root root 1523
Jan 5 00:11 knopwatchd.conf
-rw-r--r-- 1 root root 26526
Nov 6 03:54 pf.os
# chmod 600 /etc/fwknop/*

Not only the configuration files permissions must be modified, but also the tool client executable; the fwknop server binaries permissions are restrictive enough (500) by default:
# ll /usr/bin/fwknop
-rwxr-xr-x 1 root root 44817 Nov
6 03:54 /usr/bin/fwknop
# chmod 700 /usr/bin/fwknop

Step 6. Configuring the fwknop server: fwknopd
Although port knocking and SPA can be used to protect any service and its associated ports, they are mainly used to protect and enable access to remote management protocols, and especially long running TCP sessions, such as Secure Shell, SSH (TCP port 22).
The article presents two configuration examples. The first one focuses on allowing access to SSH while the second allows the client to manage remotely the rules that should be applied in the iptables firewall.
Fwknop offers much more capabilities than these two introductory examples, so for the seasoned reader, it is recommended to check fwknop documentation and test more advanced scenarios. More information can be obtained from the tool manual pages (fwknop, fwknopd, knopmd and knopwatch). Besides, fwknop configuration files are very well documented and the tool homepage [ref5] provides extra details in the form of documents, FAQ and related articles.
Step 6.1. Customizing the access.conf file
The access.conf file defines the access control directives and defines parameters for accepting single-packet authorization messages. The example below allows SPA packets from any source IP address via libpcap. Once a valid packet is received, fwknop will dynamically reconfigure the local iptables policy to allow temporary access to the SSH daemon from the IP address specified in the SPA packet for 30 seconds:
SOURCE: ANY;
OPEN_PORTS: tcp/22;
DATA_COLLECT_MODE: PCAP;
KEY: $uper$ecre7;
FW_ACCESS_TIMEOUT: 30;

The default configuration has been modified adding the two directives marked in bold, the service port and the secret key. Additionally, it is possible to open multiple ports at once, as in OPEN_PORTS: tcp/22,upd/53;.
Fwknop offers lots of advanced options, such as using public/private GPG keys as an alternate encryption method instead of the original symmetric key. Additionally, instead of allowing access, fwknop can be configured to allow a remote client to send a command to the fwknopd server, which will be executed as root. It is even possible to restrict what commands can be executed through regular expressions or require what must be the username on the system that generates the authorization packet.
Step 6.2. Understanding the pf.os file
Besides, fwknop also implements the traditional port knocking concept and provides parameters for accepting shared or encrypted knock sequences. It is even capable of enforcing what must be the operating system from which the encrypted sequence originates. This functionality is implemented through passive OS fingerprinting techniques using a database ,badapted from the p0f tool [ref6] (available in the pf.os file).
Step 6.3. Understanding the alert.conf file
The alert.conf file is used to configure how the main two daemons, fwknop and knopwatchd, generate notification alerts. By default they send alerts using syslog and email
(root@localhost). Step 6.4. Customizing the fwknop.conf file
The fwknop.conf file is the main Firewall Knock Operator configuration file and provides lots of different options and controls to manage things, like the integrity of the timestamp between the client and the server (by default their clocks could differ a maximum of 120 seconds). To simplify the article, only the following two parameters have been modified.
By default fwknopd will sniff traffic in promiscuous mode on the default Linux network interface (eth0). Due to the fact this is not required while protecting a single system, the setting has been modified not to require this interface mode:
ENABLE_PCAP_PROMISC N;
Fwknop uses libpcap filters to look for remote SPA management packets for performance reasons, not to require looking to all packets. It is recommended to change the default port (UDP port 62201):
PCAP_FILTER udp port 29905;
Step 6.5. Understanding the knopwatchd.conf file
The knopwatchd.conf file defines the settings driving the fwknop watch daemon (knopwatchd), a process that monitors the other fwknop processes and makes sure they are running (ala watch dog). The main processes are knopmd, which filters out iptables from other kernel messages for port knocking (not used in SPA mode), knoptm that removes the temporary iptables entries (after the default 30 seconds timeout expires) and fwknopd, the main fwknop server.
Step 7. Resolving conflicts between SELinux and fwknopd
By default, FC6 has SELinux enabled. The restrictions imposed by this security subsystem, especially on the Netfilter hooks, do not allow fwknop to dynamically modify the iptables policy, as indicated by the audit denied logs generated when fwknopd starts.
In order to simplify the setup and make fwknop work in FC6, this subsystem can be disabled by modifying the SELINUX variable inside the /etc/sysconfig/selinux configuration file from enforcing to disabled. It is required to reboot the system for this setting to take place. This is not a good security practice but it was required to avoid going deeper on all the complexity associated to SELinux in this article.
Step 8. Setting up the server firewall policy
The article examples use a very restrictive iptables policy, where no input traffic is allowed by default, the default action is to drop it all and only allow traffic related with previous sessions. The firewall policy in FC6 is defined in the /etc/sysconfig/iptables file and should look like this:
# cat /etc/sysconfig/iptables
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POLICY - [0:0]
-A INPUT -j POLICY
-A FORWARD -j POLICY
#
-A POLICY -i lo -j ACCEPT
-A POLICY -m state --state
ESTABLISHED,RELATED -j ACCEPT
-A POLICY -j DROP
COMMIT
The new policy can be applied by restarting the iptables service and displayed through the iptables command, using the -nL (or -vnL) options:
# service iptables restart
# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
POLICY all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
POLICY all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain POLICY (2 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
DROP all -- 0.0.0.0/0 0.0.0.0/0

The fwknop server can be started in FC6 by rebooting the system or by running the service command. Once it is up, it will add its own dynamic firewall rules to a custom iptables chain called FWKNOP_INPUT:
# service fwknop start (& stop)
# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt
source destination
FWKNOP_INPUT all --
0.0.0.0/0 0.0.0.0/0
POLICY all -- 0.0.0.0/
0 0.0.0.0/0
...
Chain FWKNOP_INPUT
(1 references)
target prot opt
source destination
...

Step 9. Testing the server ports before sending any SPA packet
The following nmap [ref7] commands show that, using the previous firewall policy, there aren’t any TCP or UDP ports opened on the server:
# nmap –n -sT -p 1-65535 192.168.1.66
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2007-01-05 04:56 CET
All 65535 scanned ports on 192.168.1.66 are filtered
MAC Address: 00:01:02:09:52:0F (3com)
Nmap finished: 1 IP address (1 host up) scanned in 1356.765 seconds
#
# nmap –n -sU -p 1-65535 192.168.1.66

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at
2007-01-05 05:09 CET
All 65535 scanned ports on 192.168.1.66 are open|filtered
MAC Address: 00:01:02:09:52:0F (3com)
Nmap finished: 1 IP address (1 host up) scanned in 1350.906 seconds

Step 10. Running the fwknop client
The fwknop client system (192.168.1.55) only requires the RPM package to be installed. There is no configuration associated to it. If the client tries to connect to TCP port 22, the connections times out due to the firewall default drop policy:
$ ssh 192.168.1.66
ssh: connect to host
192.168.1.66 port 22:
Connection timed out
$

The client can send an SPA packet specifying the server SPA listening port (UDP port 29905), the server IP address (-k) and the source IP address that must be allowed, in this case the one associated to the SPA packet (-s). Once prompted, the user must type the server shared key (defined in the access.conf file):
$ fwknop --Server-port 29905 -s -k 192.168.1.66
[+] Starting fwknop in client mode.
[+] Enter an encryption key. This key must match a key in the file
/etc/fwknop/access.conf on the remote system.
Encryption Key:
[+] Building encrypted single-packet authorization (SPA) message...
[+] Packet fields:

Random data: 6156915380424820
Username: eric
Timestamp: 1168010834
Version: 1.0
Action: 1 (access mode)
Access: 0.0.0.0,none,0
MD5 sum: Yrpc6vw8yfRu+EymXASCFA

[+] Sending 150 byte message to 192.168.1.66 over udp/29905...

At this point, the valid SPA packet is accepted by fwknopd and it modifies the iptables policy to allow the traffic coming from the client IP address (192.168.1.55) going to TCP port 22 for the next 30 seconds:
# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
FWKNOP_INPUT all -- 0.0.0.0/0 0.0.0.0/0
POLICY all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT)
target prot opt source destination
POLICY all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain FWKNOP_INPUT (1 references)
target prot opt source destination
ACCEPT tcp -- 192.168.1.55 0.0.0.0/0 tcp dpt:22

Chain POLICY (2 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
DROP all -- 0.0.0.0/0 0.0.0.0/0
At this point, the SSH connection from the client to the server can be established:
$ ssh 192.168.1.66
eric@192.168.1.66's password:
Last login: Fri Jan 5 16:17:58 2007 from 192.168.1.254
[eric@cucu ~]$ uname -a
Linux cucu.monsters.com 2.6.18-1.2868.fc6 #1
SMP Fri Dec 15 17:31:29
EST 2006 i686 i686 i386 GNU/Linux

After 30 seconds the newly created rule will disappear and access won’t be allowed anymore. However, due to the iptables stateful capabilities, the connections already established will be kept. The currently established sessions can be listed through the following command:
# cat /proc/net/ip_conntrack
tcp 6 431671 ESTABLISHED src=
192.168.1.55 dst=192.168.1.66 sport=
35608 dport=22 packets=70 bytes=6304 src=
192.168.1.66 dst=192.168.1.55 sport=
22 dport=35608 packets=52 bytes=
7204 [ASSURED] mark=0 secmark=0 use=1
The main server log, /var/log/messages, details all the fwknop actions. The valid SPA packet is received, the access rule is created and the rule is removed after 30 seconds:
Jan 5 16:21:52 cucu fwknopd: received
valid Rijndael encrypted packet from:
192.168.1.55, remote user: eric
Jan 5 16:21:52 cucu fwknopd: adding
FWKNOP_INPUT ACCEPT rule for
192.168.1.55 -> tcp/22 (30 seconds)
Jan 5 16:22:23 cucu knoptm: removed
iptables FWKNOP_INPUT ACCEPT
rule for 192.168.1.55 -> tcp/
22, 30 second timeout exceeded

When the fwknop client is behind a NAT device, the communication can still be established by allowing the client to resolve its public IP address through the www.whatismyip.com Web service. The client resolves and notifies the server the public IP address, adding it to the encrypted SPA payload, when the -w client option (replacing the -s option) is used. Other IP address resolution services can be specified.
Step 11. Managing the source IP address from the fwknop client
Apart from creating a firewall rule that allows access from its own IP address to the fixed target port configured in the server side, the fwknop client can be used to dynamically manage the firewall policy remotely. For example, using the -a option it is possible to tell the fwknop server to open a rule for a different source IP address. The following fwknop com:
$ fwknop --Server-port 29905 -a 192.168.1.254 -k
192.168.1.66
[+] Starting fwknop in client mode.
[+] Enter an encryption key. This key must match a key in the file
/etc/fwknop/access.conf on the remote system.
Encryption Key:

[+] Building encrypted single-packet authorization (SPA) message...
[+] Packet fields:
Random data: 4634543881557025
Username: eric
Timestamp: 1168014145
Version: 1.0
Action: 1 (access mode)
Access: 192.168.1.254,none,0
MD5 sum: GhC6gtJ1jEdCtzCbZ4V2Ug

[+] Sending 150 byte message to 192.168.1.66 over udp/29905...
Step 12. Managing the firewall policy from the fwknop client
The first example focused on providing access to a fixed server port, TCP/22. However, by modifying the fwknop server configuration, it is possible for the client to remotely create rules for other ports, thus manage the firewall policy remotely. The client can specify which ports are opened by fwknopd in the firewall policy if the OPEN_PORTS directive in the access.conf file is replaced by the PERMIT_CLIENT_PORTS. The access.conf file should look like this:
SOURCE: ANY;
PERMIT_CLIENT_PORTS: Y;
DATA_COLLECT_MODE: PCAP;
KEY: $uper$ecre7;
FW_ACCESS_TIMEOUT: 30;
Once the configuration file has been modified, the fwknop server must be restarted for the changes to be applied:
# service fwknop restart
Using the new configuration, the client can specify the target ports through the -A switch. It can open a single port, like the previously used TCP port 22, or it can open multiple ports simultaneously (with a single SPA packet). This functionality, combined with the previous source IP address option (-a), allows to almost completely (the source port and destination address cannot be specified) manage the firewall policy, being possible to create any firewall rule by setting the source IP address and the destination port:
$ fwknop --Server-port 29905 –
a 192.168.1.254 –A “tcp/22”
-k 192.168.1.66

$ fwknop --Server-port 29905 –
a 192.168.1.254 –A “tcp/22,udp/
53” -k 192.168.1.66

The present article was written using fwknop version 1.0, published on November 05, 2006. All file references (size, timestamps, MD5 values…) reflect this version.
While writing the article, a bug associated with the OPEN_PORTS variable was found. When the OPEN_PORTS variable is replaced by the PERMIT_CLIENT_PORTS, as in Step12, the fwknopd 1.0 server dies due to an undefined value used as a HASH reference. Due to the smart design decision of providing a monitoring process, knopwatchd, all fwknop server processes are restarted after the error condition. After contacting Michael Rash, the fwknop author, he was impressively responsive and fixed it in less than 2 hours on a Sunday evening. To try the examples throughout this article, it is strongly recommended to download the latest tool version, 1.0.1, published on January 09, 2007.
Kudos to Michael for his great security tools and his support and contributions to the open source community!
Fwknop version and OPEN_PORTS bug The present article was written using fwknop version 1.0, published on November 05, 2006. All file references (size, timestamps, MD5 values…) reflect this version. While writing the article, a bug associated with the OPEN_PORTS variable was found. When the OPEN_PORTS variable is replaced by the PERMIT_CLIENT_PORTS, as in Step12, the fwknopd 1.0 server dies due to an undefined value used as a HASH reference. Due to the smart design decision of providing a monitoring process, knopwatchd, all fwknop server processes are restarted after the error condition. After contacting Michael Rash, the fwknop author, he was impressively responsive and fixed it in less than 2 hours on a Sunday evening. To try the examples throughout this article, it is strongly recommended to download the latest tool version, 1.0.1, published on January 09, 2007.
Kudos to Michael for his great security tools and his support and contributions to the open source community!
Conclusions
Port knocking, and specifically SPA, provides advance authentication and authorization capabilities to remotely manage a firewall policy, therefore, reducing the exposure of the services protected by the firewall. They allow granting temporary access to these services at the very moment when it is required. The article focuses on how to deploy fwknop in FC6 to increase the security of SSH and other services.
Although port knocking and SPA are presented as techniques for securing access to remote services, and some commercial IPS products use similar stealthy communication channels to send commands to the inline IPS device, they can also be used by attackers to create stealthy backdoors. Some newer rootkits have already implemented similar methods.
Although the article doesn’t cover it explicitly, port knocking and SPA can be used not only to protect incoming traffic (ingress filtering) but outgoing traffic too (egress filtering). For a complete defense in depth solution, you should deploy them in both directions.

References

[ref 1] Port Knocking – Network Authentication Across Closed Ports. Martin Krzywinski. SysAdmin magazine. June 2003. Volume 12, Number 6, http://www.samag.com/articles/2003/0306/,
[ref2] Single Packet Authorization with fwknop. Michael Rash.USENIX. February 2006. Volume 31, Number 1, http://www.usenix.org/publications/login/2006-02/pdfs/rash.pdf (login required), http://www.cipherdyne.org/fwknop/docs/SPA.html,
[ref3] Port Knocking, http://www.portknocking.org, http://portknocking.sourceforge.net,
[ref4] Port Knocking. Martin Krzywinski. Linux Journal. June 2003, http://www.linuxjournal.com/article/6811,
[ref5] Fwknop: Firewall Knock Operator. Michael Rash, http://www.cipherdyne.org/fwknop/,
[ref6] p0f: Passive OS Fingerprinting. Michal Zalewski, http://lcamtuf.coredump.cx/p0f.shtml,
[ref7] nmap: Network Mapper. Fyodor Vaskovich, http://insecure.org/nmap/,
[ref8] SPA: Single Packet Authorization. MadHat and Simple Nomad. BlackHat Briefings USA 2005, http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-madhat.pdf.

About the author

Raul Siles is a senior Independent Security Consultant specializing in advanced security solutions and prevention, detection and response services in various industries (government, defense, telecom, manufacturing, financial...). Raul's expertise and service offerings includes security architectures design and review, penetration tests, incident handling, forensic and malware analysis, network, system, database and application security assessments and hardening, code security reviews, wireless security, honeynets solutions, intrusion detection/prevention, expert witness, information security management and security awareness and training (through The SANS Institute).