The 1.1 release of fwsnort is ready for download. This is a significant release that adds support for ip6tables so that SNORT inspection logic can be applied to IPv6 traffic within the Linux kernel. This release also includes a new feature that allows fwsnort to build perl commands interfaced with netcat that generate packet data that matches Snort rules (for those that that can be faithfully translated - see the --include-perl-triggers command line argument and associated comments within the fwsnort.sh file).

Here is the complete fwsnort-1.1 ChangeLog:

• Added the ability to build an fwsnort policy that utilizes ip6tables instead of iptables. This allows fwsnort filtering and altering capabilities to apply to IPv6 traffic instead of just IPv4 traffic. To enable ip6tables usage, use the "-6" or "--ip6tables" command line arguments.
• Added the --include-perl-triggers command line argument so that translated Snort rules can easily be tested. This argument instructs fwsnort to include 'perl -e print ... ' commands as comments in the /etc/fwsnort/fwsnort.sh script, and these commands can be combined with netcat to send payloads across the wire that match Snort rules.
• Updated fwsnort to create logs in the /var/log/fwsnort/ directory instead of directly in the /var/log/ directory. The path is controlled by a new variable 'LOG_FILE' in the /etc/fwsnort/fwsnort.conf file.
• Added several variables in /etc/fwsnort/fwsnort.conf to control paths to everything from the config file to the snort rules path. Coupled with this is the ability to create variables within path components and fwsnort will expand them (e.g. 'CONF_DIR /etc/fwsnort; CONF_FILE $CONF_DIR/fwsnort.conf').
• Added --Last-cmd arg so that it is easy to rebuild the fwsnort.sh script with the same command line args as the previous execution.

Snort is a registered trademark of Sourcefire, Inc.

Russ McRee of holisticinfosec.org has written the January Toolsmith issue from the ISSA Journal about fwknop and the ability to create ghost services with Single Packet Authorization. In his Toolsmith paper, Russ emphasizes the possibility of using the ghost services concept to bypass strict outbound network filtering rules on a local network in order to access an external service that is bound to a port that is filtered by the local firewall. That is, the service is made accessible by having the SPA packet created by the fwknop client request that the remote fwknopd server create iptables DNAT rules to forward connections to a port that the local network actually allows out to the port where the service is bound. Russ uses this concept to access a file that is piped through a netcat listener on TCP port 6543, but do it from the heavily filtered network over TCP port 110 (normally associated with pop3).

Here is a link to the Toolsmith PDF entitled "Single Packet Authorization: The Ghost in the Machine".

Most usages of Single Packet Authorization focus on gaining access to a service such as sshd that is behind a default-drop packet filter. The point being that anyone who is scanning for the service cannot even tell that it is listening - let alone target it with an exploit or an attempt to brute force a password. This is fine, but given that firewalls such as iptables offer well designed NAT capabilities, can a more interesting access model be developed for SPA? How about accessing sshd through a port where another service (such as Apache on port 80) is already bound? Because iptables operates on packets within kernel space, NAT functions apply before there is any conflict with a user space application such as Apache. This makes it possible to create "ghost" services where a port switches for a short period of time to whatever service is requested within an SPA packet (e.g. sshd), but everyone else always just sees the service that is normally bound there (e.g. Apache on port 80).

To illustrate this concept, let's use fwknop from the spaclient system below to access sshd on the spaserver system, but request the access be granted through port 80. Further, on the spaserver system, let's verify that Apache is running and from the perspective of any scanner out on the Internet this is the only service that is accessible. That is, sshd and all other services are firewalled off by iptables. We'll assume that the spaclient system has IP 1.1.1.1, the spaserver system has IP 2.2.2.2, and the scanner system has IP 3.3.3.3.

First, let's scan the spaserver system from the scanner system and verify that only port 80 is accessible:

[scanner]# nmap -P0 -n -sV 2.2.2.2

Starting Nmap 5.00 ( http://nmap.org ) at 2009-11-29 15:14 EST
Interesting ports on 2.2.2.2:
Not shown: 999 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.8 ((Ubuntu) mod_python/3.3.1 Python/2.5.2)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 90.94 seconds

Good. Now, from the spaclient system, let's fire up fwknop and request access to sshd on the spaserver system. But instead of just gaining access to port 22, we'll request access to port 22 via port 80 - the fwknopd daemon will build the appropriate DNAT iptables rules to make this work:

[spaclient]$ fwknop -A tcp/22 --NAT-access 2.2.2.2:80 --NAT-local -a 1.1.1.1 -D 2.2.2.2

[+] Starting fwknop client (SPA 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: 3829970026924871
Username: mbr
Timestamp: 1259526613
Version: 1.9.12
Type: 5 (Local NAT access mode)
Access: 0.0.0.0,tcp/22
NAT access: 2.2.2.2,80
SHA256 digest: Om/GsIVQIRyAp6UWyqjXVqlEQhxz+lVsQhCl1rFBfuI

[+] Sending 182 byte message to 2.2.2.2 over udp/62201...
Requesting NAT access to tcp/22 on 2.2.2.2 via port 80


With the receipt of the SPA packet, the fwknopd daemon has reconfigured iptables to allow an ssh connection through port 80 from the spaclient IP 1.1.1.1 (note the "-p 80" argument on the ssh command line):

[spaclient]$ ssh -p 80 -l mbr 2.2.2.2
mbr@2.2.2.2's password:
[spaserver]$

If we can the spaserver again from the scanner system, we still only see Apache:

[scanner]# nmap -P0 -n -sV 2.2.2.2

Starting Nmap 5.00 ( http://nmap.org ) at 2009-11-29 15:29 EST
Interesting ports on 2.2.2.2:
Not shown: 999 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.8 ((Ubuntu) mod_python/3.3.1 Python/2.5.2)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 89.22 seconds

So, the IP 1.1.1.1 has access to sshd, but all the scanner can ever see is 'Apache httpd 2.2.8'.

A legitimate question at this point is 'why is this useful?'. Well, I have been on networks before where local access controls only allowed outbound DNS, HTTP and HTTPS traffic, so this technique allows ssh connections to be made in a manner that is consistent with these access controls. (This assumes that HTTP connections are not made through a proxy, and that the fwknopd daemon is configured to sniff SPA packets over port 53.) Further, to anyone who is able to sniff traffic, it can be hard to figure out what is really going on in terms of SPA packets and associated follow-on connections. This is especially true when other tricks such as port randomization are also applied.

I demonstrated the service ghosting technique at DojoCon a few weeks ago, and the video of this is available here (towards the end of the video).

At the upcoming SANS Incident Detection Summit on December 9th and 10th I will be participating in two panel discussions. The first is entitled "Enterprise Network Detection Tools and Tactics" and is described by Richard Bejtlich (who has organized the whole conference) as a venue where "speakers with large-scale experience will share their tools and tactics for identifying suspicious and malicious activity". The second, "Detection Using Logs", focuses on the usage of platform, operating system, and application logs to detect intrusions, and Security Information Management and log aggregation and search systems will be discussed.

If you are going to be at the conference, please say hello!

UDPATE: The talk slides can be downloaded here and a video of the talk is available too.

On Friday November 6th I will be giving a talk on Single Packet Authorization with fwknop at the upcoming DojoCon conference at Capitol College in Laurel, MD. This talk will focus on some recent developments in the world of fwknop development and the resulting enhancements to SPA capabilities. Topics to be emphasized include:

• The new libfko C implementation and what it means for SPA deployments.
• Interface monitoring for administrative control changes and increasing packet counts. This adds an extra dimension of reliability for fwknopd server operations.
• HTTP proxy support, as well as the development of an SSL web gateway for sending SPA packets on behalf of client systems that cannot construct SPA packets themselves.
• Development efforts for future fwknop features (such as additional client integration, and deployments on embedded Linux distributions).

The 1.9.12 release of fwknop is ready for download. This is a significant release that moves by default to the new libfko and the new FKO module for SPA encryption and decryption. Other new features include interface monitoring for the fwknopd daemon so it can survive administrative changes due to things like a DHCP address changes, and the ability to send SPA packets through HTTP proxies.

An excerpt from the 1.9.12 ChangeLog appears below:

• Fully integrated the FKO module that is part of the libfko library for all SPA routines - encryption/decryption, digest calculation, replay attack detection, etc. The default is to always use the FKO module if it has been installed, but the original perl code remains intact as well just in case FKO does not exist on the local system. The libfko code can be viewed with Trac here
• Added the ability to recover from interface error conditions, such as when fwknopd sniffs a ppp interface (say, associated with a VPN) that goes away and then is recreated. In previous versions of fwknop, this would result in the fwknopd daemon no longer able to receive SPA packets. This new functionality is controlled by five new configuration variables in the fwknop.conf file: ENABLE_INTF_CHECKS, INTF_CHECKS_INTERVAL, ENABLE_INTF_EXISTS_CHECK, ENABLE_INTF_RUNNING_CHECK, and ENABLE_INTF_BYTES_CHECK. By default, all of these checks are enabled and are run every 20 seconds by the knoptm daemon. If any check fails, then knoptm stops the fwknopd daemon once the error condition is corrected (such as when the interface comes back) so that knopwatchd will then restart it. The fwknopd daemon cannot receive packet data until the error condition is cleared (most likely except perhaps for the "RUNNING" check, but restarting the fwknopd daemon is better than not being able to access a service).
• Updated the fwknop client to include the SPA destination before DNS resolution when sending an SPA packet over an HTTP request. This allows more flexible Apache configurations with virtual web hosts to function properly with HTTP requests that contain SPA packet data. Also updated the fwknop client to include a leading "/" in SPA packets over HTTP, and updated the fwknopd server to strip this out before attempting SPA packet decryption.
• Updated the fwknop client to resolve external IP addresses (with the -R argument) here by default.
• (Jonathan Bennett): Submitted patch to the fwknop client to add HTTP proxy support when sending SPA packets over HTTP. The result is a new --HTTP-proxy option that expects the proxy host to be given as "http://HOST", and it also supports the "http://HOST:PORT" notation as well.

There has been a Trac repository available on trac.cipherdyne.org since 2006, and in that time I've collected quite a lot of Apache log data. Today, the average number of hits per day against the fwknop, psad, fwsnort, and gpgdir Trac repositories combined is over 40,000. These hits come mostly from search engine crawlers such as Googlebot/2.1, msnbot/2.0b, Baiduspider+, and Yahoo! Slurp/3.0;. However, not all such crawlers are created equal. It turns out that Google is far and away the most dedicated indexer of the cipherdyne.org Trac repositories, and to me this is somewhat surprising considering the reputation Google has for efficiently crawling the web. That is, I would have expected that the non-Google crawlers would most likely hit the Trac repositories on average more often than Google. But perhaps Google is extremely interested in getting the latest code made available via Trac indexed as quickly as possible, and for svn repositories that are made accessible only via Trac (such as the cipherdyne.org repositories), perhaps brute force indexing of all possible links in Trac is better. Or, perhaps the other search engines are simply not as interested in code within Trac repositories so they don't bother to aggressively index it, or maybe they are just not very thorough when compared to Google.

Let's see some examples. The following graphs are produced with the webalizer project. This graph shows the uptick in hits against Trac shortly after it was first made available in 2006: So, the average number of hits goes from 803 starting out in May and jumps rapidly to nearly 17,000 in December. Here are the top five User-Agents and associated hit counts:

Hits	Percentage	User-Agent
5062	37.06%	Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
5004	36.63%	noxtrumbot/1.0 (crawler@noxtrum.com)
1283	9.39%	msnbot/0.9 (+http://search.msn.com/msnbot.htm)
475	3.48%	Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060418...
457	3.35%	Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20051229...

Right off the bat Google is the top crawler, but only just barely. In December, this changes to the following:

Hits	Percentage	User-Agent
478063	90.94%	Mozilla/5.0 (compatible; Googlebot/2.1; ...
11299	2.15%	Mozilla/5.0 (compatible; BecomeBot/3.0; ...
8287	1.58%	msnbot-media/1.0 (+http://search.msn.com/msnbot.htm)
6423	1.22%	Mozilla/5.0 (compatible; Yahoo! Slurp; ...
4029	0.77%	Mozilla/2.0 (compatible; Ask Jeeves/Teoma; ...

Now things are drastically different - Google's crawler now accounts for over 90% of all hits against Trac, and has created over 42 times the number of hits from the second place crawler "BecomeBot/3.0" (a shopping-related crawler - maybe they like the price of "zero" for the cipherdyne.org projects).

Let's fast forward to 2009 and take a look at how things are shaping up (note that data from 2008 is not included in this graph): The month of May was certainly an aberration with over 56,000 hits per day, and August topped out at 42,000 hits per day. In May, the top five crawlers were:

Hits	Percentage	User-Agent
1510435	86.14%	Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
73740	4.21%	Mozilla/5.0 (compatible; DotBot/1.1; http://www.dotnetdotcom.org/
33482	1.91%	Mozilla/5.0 (compatible; Charlotte/1.1; http://www.searchme.com/support/)
22699	1.29%	Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; ...
20980	1.20%	Mozilla/5.0 (compatible; MJ12bot/v1.2.4; ...

Google maintains a crawling rate of over 20 times as many hits as the second place crawler "DotBot/1.1". In August, 2009 (some of the most recent data), the crawler hit counts were:

Hits	Percentage	User-Agent
947703	86.02%	Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
43876	3.98%	msnbot/2.0b (+http://search.msn.com/msnbot.htm)
30951	2.81%	Mozilla/5.0 (compatible; DotBot/1.1; http://www.dotnetdotcom.org/
11578	1.05%	Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; ...)
10880	0.99%	msnbot/1.1 (+http://search.msn.com/msnbot.htm)

This time "msnbot/2.0b" makes it to second place, but it is still far behind Google in terms of hit counts. So, what is Google looking at that needs so many hits? One clue perhaps is that Google likes to re-index older data (probably to ensure that a content update has not been missed). Here is an example of all hits against a link that contains the "diff" formated output for changeset 353 in the fwknop project. The output is organized by each year since 2006, and the first command counts the number of hits from Google, and the second command shows all of the non-Googlebot hits:

[trac.cipherdyne.org]$ for f in 200*; do echo $f; grep diff $f/trac_access* |grep "/trac/fwknop/changeset/353" | grep Googlebot |wc -l; done
2006
6
2007
4
2008
6
2009
2

[trac.cipherdyne.org]$ for f in 200*; do echo $f; grep diff $f/trac_access* |grep "/trac/fwknop/changeset/353" | grep -v Googlebot ; done
2006
74.6.74.211 - - [10/Oct/2006:07:38:21 -0400] "GET /trac/fwknop/changeset/353?format=diff HTTP/1.0" 200 - "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
205.209.170.161 - - [19/Nov/2006:14:17:57 -0500] "GET /trac/fwknop/changeset/353?format=diff HTTP/1.1" 200 - "-" "MJ12bot/v1.0.8 (http://majestic12.co.uk/bot.php?+)"
2007
2008
38.99.44.102 - - [27/Dec/2008:17:51:34 -0500] "GET /trac/fwknop/changeset/353/?format=diff&new=353 HTTP/1.0" 200 - "-" "Mozilla/5.0 (Twiceler-0.9 http://www.cuil.com/twiceler/robot.html)"
2009
208.115.111.250 - - [14/Jul/2009:20:42:32 -0400] "GET /trac/fwknop/changeset/353?format=diff&new=353 HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; DotBot/1.1; http://www.dotnetdotcom.org/, crawler@dotnetdotcom.org)"
208.115.111.250 - - [28/Jun/2009:10:00:32 -0400] "GET /trac/fwknop/changeset/353?format=diff&new=353 HTTP/1.1" 200 - "-" "Mozilla/5.0 (compatible; DotBot/1.1; http://www.dotnetdotcom.org/, crawler@dotnetdotcom.org)"

So, Google keeps hitting the "changeset 353" link multiple times each year, whereas the other crawlers (except for DotBot) each hit the link once and never came back. Further, many crawlers have not hit the link at all, so perhaps they are not nearly as thorough as Google.

A few questions come to mind to conclude this blog post. Please contact me if you would like to discuss any of these:

• For any other people out there who also run Trac, what crawlers have you seen in your logs, and does Google stand out as a more dedicated indexer than the other crawlers?
• For anyone who runs Trac but also makes the svn repository directly accessible, does Google continue to aggressively index Trac? Does the svn access imply that whatever code is versioned within is used as a more authoritative source than Trac itself?
• It would seem that any crawler could implement an optimization around the Trac timeline feature so that source code change links are indexed only when a timeline update is made. But, perhaps this is too detailed for crawlers to worry about? It would require additional machinery to interpret the Trac application, so search engines most likely try to avoid such customizations.
• Why do the non-Google crawlers lag so far behind in terms of hit counts? Are the differences in resources that Google can bring to bear on crawling the web vs. the other search engines so great that the others just cannot keep up? Or, maybe the others are just not so interested in code that is made available in Trac?

The 1.9.5 release of gpgdir is ready for download. This release adds support for decrypting files that have been encrypted with PGP (so they have the .pgp file extension). This feature was essentially implemented for free in gpgdir because GnuPG along with the GnuPG::Interface perl module can decrypt PGP-encrypted files. Here is an example:

$ cd dir
$ find . -type f
./file0.pgp
./file5.pgp
./subdir2/file8.pgp
./subdir2/file7.pgp
./subdir1/file6.pgp
./file4.pgp
./file3.pgp
./file2.pgp
./file1.pgp
$ gpgdir -d .
[+] Executing: gpgdir -d .
Using GnuPG key: ABCD1234
Password:

[+] Decrypting files in directory: /home/mbr/tmp/dir
[+] Building file list...
[+] Decrypting: /home/mbr/tmp/dir/file3.pgp
[+] Decrypting: /home/mbr/tmp/dir/subdir2/file8.pgp
[+] Decrypting: /home/mbr/tmp/dir/subdir2/file7.pgp
[+] Decrypting: /home/mbr/tmp/dir/subdir1/file6.pgp
[+] Decrypting: /home/mbr/tmp/dir/file1.pgp
[+] Decrypting: /home/mbr/tmp/dir/file2.pgp
[+] Decrypting: /home/mbr/tmp/dir/file5.pgp
[+] Decrypting: /home/mbr/tmp/dir/file4.pgp
[+] Decrypting: /home/mbr/tmp/dir/file0.pgp

[+] Total number of files decrypted: 9

$ !find
find . -type f
./file4
./file3
./file5
./subdir2/file8
./subdir2/file7
./subdir1/file6
./file1
./file2
./file0

The speed at which the open source software movement develops new code is frequently quite impressive, and people crank out higher levels of production when they do something they really like to work on. This remains true for the new Morpheus-fwknop Windows UI written by Daniel Lopez, and a new release (0.7) of Morpheus is now available from Sourceforge. The release notes for 0.7 read as follows:

• Implement PGP Encryption.
• Allow to Open multiple port on Forward/Nat Local mode.
• New UI with a little more color.
• Launch an Application after sending the SPA Packet.

Here are a couple of screenshots of Morpheus in action. The look and feel has changed quite a bit from the previous release.

Fyodor recently released Nmap-5.00, and this release marks a major milestone in Nmap development as it is now quite mature, has a large following, and is feature rich. With Nmap, service discovery and interrogation has never been easier or more automated, and for me Nmap provided much of the inspiration to develop psad (scan detection via iptables log messages) and fwknop (hide services from all types of scans behind a default-drop packet filter with Single Packet Authorization).

Some of the more interesting Nmap features these days include the Nmap Scripting Engine (NSE), the Zenmap user interface, and ndiff. The NSE is an Nmap extension that allows users to express networking tasks via the Lua embedded programming language, and the resulting scripts are executed via Nmap against targeted systems. As an example of some of the power that NSE provides, a recent update allows Nmap to interrogate a system in order to see if it is infected with the Conficker worm.

Zenmap provides a nice graphical interface to point and click Nmap scanning, complete with interactive editing of Nmap command line arguments, scan results display with context sensitive text colors, and even a network topology viewer to represent scan targets. The screenshot below illustrates the scan results view of a scan against a Netgear router:

An excellent example of the topology view in Zenmap can be found here.

With the new Nmap release, some questions the security community may ask include:

• Will scan activity significantly increase? Most likely there will be a burst of scanning over the next few weeks as people adopt and experiment with the new release - especially after the broad news coverage Nmap is getting.
• By direct examination of network traffic Is it possible to differentiate Nmap-5.00 scans from those that originate from older versions? My guess is most likely not, but a source code diff from older versions should make this clear.
• Does the new release imply that the Conficker worm will accelerate its decline as more scans are made to find infected systems? Note that Conficker seems to already be on the decline by one measure.

Finally, I wonder if ndiff will change how people use Nmap in the long run? It is great to have accurate scan information about a target, but it is even better to see how this information changes over time. For example, if a system is compromised and is forced to stand up a new backdoor service, then this will cause a "blip" in ndiff results if this system is the target of regular Nmap scans. Or, if a broad policy change is made in a router ACL or firewall rule set, then this can result in broad ndiff changes too. Another example might be if a networked application is upgraded such that it advertises itself differently from one scan to the next (say, via a banner such as "Apache/2.2.11 (Ubuntu) Server at localhost Port 80"), ndiff might alert you more effectively than other techniques (this assumes that you have enabled version scanning).

On a technical note, it is possible to introduce false positives into ndiff output if the Nmap command line is altered from one diff to the next. Suppose that scans for a particular UDP service seem to finish fairly quickly and reliably because the target returns an ICMP port unreachable message (indicating that the service is not filtered). But, in the interest of speeding scans up further, suppose the --max-rtt-timeout argument is used on the Nmap command line, and suppose that timeout is reduced too far. In this case, through no fault of its own, Nmap would report the service as filtered because the ICMP port unreachable message returned after the reduced timer had already expired. If the before and after Nmap scan results are compared, ndiff would report the difference even though the user is responsible for creating it. Nmap is doing its job though, and changing how Nmap is invoked for automated scans is probably not very common. At least, over time the way Nmap is invoked would average out to the same. The main goal of comparing scan results is wonderfully automated by ndiff, and is a powerful mechanism for seeing how network service availability changes over time.

Congratulations to Fyodor and the Nmap developers on a great release.

This past week one a good one for Single Packet Authorization with two software releases. First, an initial version of libfko, the all C implementation of SPA developed by Damien Stuart can be downloaded along with documentation. The libfko library allows other programs to easily implement the SPA protocol, and a new C client is bundled with fwknop-c-0.62 as well as a new perl module "FKO" that implements a perl XS extension of libfko functions. Once the fwknopd server piece is also developed (a new replacement fwknop C client is included, but not a replacement for fwknopd yet), the libfko code will allow SPA to easily be extended to systems where perl is either not installed or cannot be run (due to hardware constraints such as small routers running OpenWRT).

fwknop-c follows the standard autoconf method of installing open source software, so just:

$ ./configure --prefix=/usr && make
$ su
# make install

The new fwknop-c client can be found at /usr/bin/fwknop once you have installed per the above, and all important options are supported similarly to the perl fwknop client. So, the familiar commands like:

$ fwknop -A tcp/22 -R -D <host_or_ip>

should work just the same. A few of the command line arguments have been changed in the C version, and by default the output on stdout is reduced (just use -v to change this).

Second, a new project called morpheus-fwknop was developed and released by Daniel Lopez. This project is a Windows UI written in .NET to send SPA packets that fwknopd can decrypt. With morpheus-fwknop, there is no need to install Cygwin in order to access services protected by SPA from Windows. This is the first viable UI to succeed Sean Greven's UI developed in Delphi (which still works too!), and morpheus-fwknop is released under the GPL. Naturally, source code can be downloaded, and here are two screenshots that show the look and feel: It is excellent to see work going on in the world of user interfaces to fwknop and SPA. Without an effective UI on Windows, a large user base is effectively cut off.

Recently, Bobby Krupczak, a reader of "Linux Firewalls" pointed out to me that the iptables script used in the book does not log traffic over the loopback interface, and that such traffic is also blocked because of the INPUT and OUTPUT policies of "DROP" (instead of having a separate DROP rule). This should be made more clear in the book. Quite right - all logging is excluded for traffic that is sent or received over the loopback interface, and the iptables policy also drops loopback traffic because no ACCEPT rule exists. The lack of a logging rule is mostly because logging traffic generated locally and restricted to the loopback interface is usually a distraction from logging more important (and potentially malicious) traffic from remote networks. However, if a local process seems to have connectivity issues, then making sure that loopback traffic flows unimpeded is important. The iptables.sh script has been updated to ACCEPT all loopback traffic handled by the INPUT and OUTPUT chains.

On another note, I would also like to mention that the script has been updated to block IPv6 traffic altogether. With more networks routing IPv6 these days, and with things like Federal mandates for IPv6 compliance on Federal networks, IPv6 adoption is... still slow. However, Linux has had the ability to speak IPv6 for a long time, and Nmap can scan for IPv6-enabled services. Hence it is important to apply iptables controls to IPv6 traffic via ip6tables. The consequences of not doing this could be a system compromise via a service that can communicate over IPv6, but that is normally firewalled off in the IPv4 world.

Here is an example of scanning ::1 on an Ubuntu-9.04 system with Nmap without any ip6tables controls applied. Note that three important services are available over IPv6:

[root@isengard ~]# nmap -6 -P0 ::1

Starting Nmap 5.00 ( http://nmap.org ) at 2009-07-28 21:10 EDT
Interesting ports on ip6-localhost (::1):
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds



With the updated iptables script deployed, Nmap no longer sees these services.

Have you checked the output of ip6tables -v -nL | grep DROP lately on your Linux system? If you are running a different operating system, are you confident that IPv6 traffic is being filtered appropriately?

[root@isengard ~]# ip6tables -v -nL | grep DROP
Chain INPUT (policy DROP 0 packets, 0 bytes)
Chain FORWARD (policy DROP 0 packets, 0 bytes)
Chain OUTPUT (policy DROP 0 packets, 0 bytes)

UPDATE: 08/07/09 So, Defcon 17 has come and gone, and I have not heard anything credible to indicate there is a new vulnerability in OpenSSH. That said, I still run all of my SSH daemons behind SPA/fwknop. My original post appears below.

There are rumors of a new vulnerability in OpenSSH that may affect several versions previous to the current OpenSSH-5.2 release. IF these rumors are true - and there is a claim that details will be provided in time for the upcoming Black Hat and Defcon conferences three weeks from now - then it may be a good idea to deploy either a port knocking or SPA solution to protect SSH daemons. Although solid proof has yet to be released, it is a good bet that if there really is a remotely exploitable vulnerability, then it will have nothing to do with brute force password guessing.

Although log parsers that wrap thresholds around failed login attempts can be useful, what I worry about are vulnerabilities where password guessing is completely unnecessary for successful compromises. This is where SPA comes in because it makes a service essentially impossible to identify via scans, and so when an attacker (who may be armed with a 0-day exploit) goes looking for SSH servers to attack, your server will not be listed. There have been remote exploits against OpenSSH before that allow arbitrary code execution, and password guessing was nowhere in sight. It is only a matter of time before the next one is found (hopefully by the whitehats first) in OpenSSH or any other SSH implementation that you are running.

In the meantime, perhaps the Metasploit framework will come up with an exploit before Black Hat. Or, perhaps this will always stay as just a rumor. Either way, there is little harm in protecting your SSH daemon behind SPA and a default-drop firewall policy.

Although the media blitz surrounding the Conficker worm has died down, the worldwide computing infrastructure that the worm has cobbled together still exists and remains under the control of its masters. The resulting botnet is an impressive demonstration of distributed computing control and recoverability. Many organizations - from companies to governments - would be envious of such automation. Most likely the botnet is being used as a money making machine by renting out "botnet time" to criminals who then use it for their own purposes. New Scientist has a good summary of the Conficker saga, and includes a discussion of its switch from HTTP to a peer-to-peer module for communications and updates. Even though Conficker has perhaps not yet been used to issue DoS attacks against high profile sites, it has had measurable impacts such as leaving Manchester unable to issue parking tickets and Microsoft announcing a $250,000 bounty on the Conficker authors. On the defense side, the Conficker Working Group has produced some nice infection distribution maps and Nmap added Conficker scan detection based on an excellent paper written by Tillmann Werner and Felix Leder.

In the context of iptables and fwsnort, the goal is to give Linux systems the ability to detect and interfere network traffic associated with Conficker (at least as much as possible), and this process starts with Snort rules from the Emerging Threats rule set. There are currently six active Snort rules designed to detect Conficker in the Emerging Threats set, and an additional four that have been commented out. The six active rules so far detect the Conficker.A and Conficker.B variants, but hopefully more rules will become available as better detection techniques are developed.

Now, how does fwsnort do with translating the six Emerging Threats rules? Let's find out with the command below. This uses the --include-regex feature to restrict fwsnort to just those rules that contain the string "conficker", and we also add the new --include-perl-trigger argument (to be released in fwsnort-1.0.7) that builds a perl command to mimic the application layer data in each Snort rule. By combining this perl command with netcat, it is possible to test whether the iptables policy built by fwsnort properly detects attacks. Finally, we also use the --ipt-reject argument to have iptables drop any packet that matches the Conficker signatures and reset the connection at the same time:

# fwsnort --include-regex conficker --include-re-caseless --snort-rfile /etc/fwsnort/snort_rules/emerging-all.rules --include-perl-triggers --ipt-reject | tail -n 4
[+] Generated iptables rules for 3 out of 6 signatures: 50.00%

[+] Logfile: /var/log/fwsnort.log
[+] iptables script: /etc/fwsnort/fwsnort.sh


Ok, so three out of the six signatures (I'm using 'signature' and 'rule' interchangeably in this blog post) converted properly to iptables rules. Those that did not convert contain elements such as pcre and threshold that are not currently supported by fwsnort.

Below is an example of one Snort signature that did convert correctly. This is rule ID 2009201, and it detects shellcode directed at TCP/445 from Conficker.B:

alert tcp $EXTERNAL_NET any -> $HOME_NET 445 (msg:"ET CURRENT_EVENTS Conficker.b Shellcode"; flow:established,to_server; content:"|e8 ff ff ff ff c2|_|8d|O|10 80|1|c4|Af|81|9MSu|f5|8|ae c6 9d a0|O|85 ea|O|84 c8|O|84 d8|O|c4|O|9c cc|Ise|c4 c4 c4|,|ed c4 c4 c4 94|&<O8|92|\;|d3|WG|02 c3|,|dc c4 c4 c4 f7 16 96 96|O|08 a2 03 c5 bc ea 95|\;|b3 c0 96 96 95 92 96|\;|f3|\;|24 |i|95 92|QO|8f f8|O|88 cf bc c7 0f f7|2I|d0|w|c7 95 e4|O|d6 c7 17 cb c4 04 cb|{|04 05 04 c3 f6 c6 86|D|fe c4 b1|1|ff 01 b0 c2 82 ff b5 dc b6 1f|O|95 e0 c7 17 cb|s|d0 b6|O|85 d8 c7 07|O|c0|T|c7 07 9a 9d 07 a4|fN|b2 e2|Dh|0c b1 b6 a8 a9 ab aa c4|]|e7 99 1d ac b0 b0 b4 fe eb eb|"; reference:url,www.honeynet.org/node/388; reference:url,doc.emergingthreats.net/2009201; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_Conficker; classtype:trojan-activity; sid:2009201; rev:4;)

Here is the equivlent iptables command built by fwsnort and included in the /etc/fwsnort/fwsnort.sh script. Note the usage of the FWSNORT_FORWARD_ESTAB chain which is reserved for packets that are part of established TCP connections:

$IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp --dport 445 -m string --hex-string "|e8ffffffffc2|_|8d|O|1080|1|c4|Af|81|9MSu|f5|8|aec69da0|O|85ea|O|84c8|O|84d8|O|c4|O|9ccc|Ise|c4c4c4|,|edc4c4c494|&<O8|923bd3|WG|02c3|,|dcc4c4c4f7169696|O|08a203c5bcea953bb3c096969592963bf33b24|i|9592|QO|8ff8|O|88cfbcc70ff7|2I|d0|w|c795e4|O|d6c717cbc404cb|{|040504c3f6c686|D|fec4b1|1|ff01b0c282ffb5dcb61f|O|95e0c717cb|s|d0b6|O|85d8c707|O|c0|T|c7079a9d07a4|fN|b2e2|Dh|0cb1b6a8a9abaac4|]|e7991dacb0b0b4feebeb|" --algo bm -m comment --comment "sid:2009201; msg:ET CURRENT_EVENTS Conficker.b Shellcode; classtype:trojan-activity; reference:url,www.honeynet.org/node/388; rev:4; FWS:1.0.6;" -j LOG --log-ip-options --log-tcp-options --log-prefix "[3] DRP SID2009201 ESTAB "

Because the pattern in the above signature is longer than 128 bytes, we'll increase the value of the MAX_STRING_LEN variable to 256 in the /etc/fwsnort/fwsnort.conf file. With that done, let's execute the /etc/fwsnort/fwsnort.sh script now and see how iptables handles such traffic on the wire:

# /etc/fwsnort/fwsnort.sh
[+] Adding emerging-all rules:
iptables v1.4.1.1: STRING too long `|e8ffffffffc2|_|8d|O|1080|1|c4|Af|81|9MSu|f5|8|aec69da0|O|85ea|O|84c8|O|84d8|O|c4|O|9ccc|Ise|c4c4c4|,|edc4c4c494|&<O8|923bd3|WG|02c3|,|dcc4c4c4f7169696|O|08a203c5bcea953bb3c096969592963bf33b24|i|9592|QO|8ff8|O|88cfbcc70ff7|2I|d0|w|c795e4|O|d6c717cbc404cb|{|040504c3f6c686|D|fec4b1|1|ff01b0c282ffb5dcb61f|O|95e0c717cb|s|d0b6|O|85d8c707|O|c0|T|c7079a9d07a4|fN|b2e2|Dh|0cb1b6a8a9abaac4|]|e7991dacb0b0b4feebeb|' Try `iptables -h' or 'iptables --help' for more information.

Ok, that is disappointing. It turns out that iptables currently enforces a 128-byte maximum on all strings supplied to the string match extension for inspecting payload data. Normally this is not a problem since the individual patterns in most Snort rules are typically less than 128 bytes, but in this case we'd like to work around this limitation. To do so requires that we patch and recompile the xt_string kernel module (assuming xt_string is configured as a module) with the following patch:

# git diff
diff --git a/include/linux/netfilter/xt_string.h b/include/linux/netfilter/xt_string.h
index 8a6ba7b..afc60a2 100644
--- a/include/linux/netfilter/xt_string.h
+++ b/include/linux/netfilter/xt_string.h
@@ -1,7 +1,7 @@
#ifndef _XT_STRING_H
#define _XT_STRING_H

-#define XT_STRING_MAX_PATTERN_SIZE 128
+#define XT_STRING_MAX_PATTERN_SIZE 256
#define XT_STRING_MAX_ALGO_NAME_SIZE 16

enum {
@@ -15,7 +15,7 @@ struct xt_string_info
u_int16_t to_offset;
char algo[XT_STRING_MAX_ALGO_NAME_SIZE];
char pattern[XT_STRING_MAX_PATTERN_SIZE];
- u_int8_t patlen;
+ u_int16_t patlen;
union {
struct {
u_int8_t invert;

With the new xt_string module loaded let's execute the fwsnort.sh script once again:

# /etc/fwsnort/fwsnort.sh
[+] Adding emerging-all rules:
Rules added: 12
[+] Finished.

Ah, that's better. The fwsnort iptables policy loaded properly in the running kernel. Now, let's use the perl trigger command along with netcat to send data across the wire that should match the signature. The trigger itself can be found in the /etc/fwsnort/fwsnort.sh script. First, we fire up a netcat server on TCP port 445 on a target system which is protected by another system running the fwsnort iptables policy, and then with the perl trigger we send bytes that match the Conficker.B shell code signature across the wire to the target. The complete perl command is listed below even though it certainly is obtuse looking. You can see how the bytes it is printing match the content strings in the original signature:

[target]# nc -l -p 445
[attacker]$ perl -e 'print "\xe8\xff\xff\xff\xff\xc2_\x8dO\x10\x801\xc4Af\x819MSu\xf58\xae\xc6\x9d\xa0O\x85\xeaO\x84\xc8O\x84\xd8O\xc4O\x9c\xccIse\xc4\xc4\xc4,\xed\xc4\xc4\xc4\x94&<O8\x92\x3b\xd3WG\x02\xc3,\xdc\xc4\xc4\xc4\xf7\x16\x96\x96O\x08\xa2\x03\xc5\xbc\xea\x95\x3b\xb3\xc0\x96\x96\x95\x92\x96\x3b\xf3\x3b\x24i\x95\x92QO\x8f\xf8O\x88\xcf\xbc\xc7\x0f\xf72I\xd0w\xc7\x95\xe4O\xd6\xc7\x17\xcb\xc4\x04\xcb{\x04\x05\x04\xc3\xf6\xc6\x86D\xfe\xc4\xb11\xff\x01\xb0\xc2\x82\xff\xb5\xdc\xb6\x1fO\x95\xe0\xc7\x17\xcbs\xd0\xb6O\x85\xd8\xc7\x07O\xc0T\xc7\x07\x9a\x9d\x07\xa4fN\xb2\xe2Dh\x0c\xb1\xb6\xa8\xa9\xab\xaa\xc4]\xe7\x99\x1d\xac\xb0\xb0\xb4\xfe\xeb\xeb"' |nc 10.1.1.1 445

The fwsnort iptables policy has reset the connection, and the following iptables log message was also produced:

Jul 4 13:23:18 fwsnort kernel: [10966.350782] [2] REJ SID2009201 ESTAB IN=lo OUT= MAC=AB:00:00:AB:00:00:AB:00:00:AB:00:00:08:00 SRC=192.168.10.1 DST=10.1.1.1 LEN=244 TOS=0x00 PREC=0x00 TTL=64 ID=5976 DF PROTO=TCP SPT=49053 DPT=445 WINDOW=513 RES=0x00 ACK PSH URGP=0 OPT (0101080A0028B05B0028B058)

Of course, the best defense against Conficker is to patch Windows systems against the MS08-067 vulnerability, and to use Nmap to scan for systems that are already infected. Those that are should be completely reimaged.

On June 19th Leandro Almeida gave a presentation entitled "Single Packet Authorization - Increasing the security in SSH" at the ENSOL conference in João Person, Brazil. ENSOL is an open source conference that goes by the title "Freedom in the Extreme", and given that Brazil is highly supportive of Linux, I'm sure that it is a good conference. Leandro has posted an English translation of his slides here. It is good to see some additional presentations on the SPA concept at open source conferences, and Leandro emphasizes the usage of the fwknop SPA implementation to protect SSH.

The 1.0.6 release of fwsnort is ready for download. This release fixes a bug that caused some Snort rules to not be translated into iptables rules due to improper handling of escaped semicolons. Now that this bug has been fixed, an additional 58 rules from the Emerging Threats rule set are now properly supported. Also made it easier to point fwsnort at a single file with a Snort rule set to be converted (see the --fwsnort-rfile command line argument).

Here is the complete ChangeLog:

• (Franck Joncourt) Updated fwsnort to use the "! <option> <arg> syntax instead of the older "<option> ! <arg> for the iptables command line.
• (Franck Joncourt) For the --hex-string and --string matches, if the argument exceeds 128 bytes (iptables 1.4.2) then iptables fails with an error "iptables v1.4.2: STRING too long". Fixes this with a patch that adds a new variable in fwsnort.conf "MAX_STRING_LEN", so that the size of the content can be limited. If the content (null terminated string) is more than MAX_STRING_LEN chars, fwsnort throws the rule away.
• Bug fix to allow fwsnort to properly translate snort rules that have "content" fields with embedded escaped semicolons (e.g. "\;"). This allows fwsnort to translate about 58 additional rules from the Emerging Threats rule set.
• Bug fix to allow case insensitive matches to work properly with the --include-re-caseless and --exclude-re-caseless arguments.
• Bug fix to move the 'rawbytes' keyword to the list of keywords that are ignored since iptables does a raw match anyway as it doesn't run any preprocessors in the Snort sense.
• Added the --snort-rfile argument so that a specific Snort rules file (or list of files separated by commas) is parsed.
• Added a small hack to choose the first port from a port list until the iptables 'multiport' match is supported.
• Updated to consolidate spaces in hex matches in the fwsnort.sh script since the spaces are not part of patterns to be searched anyway.
• Updated to the latest complete rule set from Emerging Threats (see http://www.emergingthreats.net/).
• Added the "fwsnort-nobuildreqs.spec" file for building fwsnort on systems (such as Debian) that do not install/upgrade software via RPM. This file omits the "BuildRequires: perl-ExtUtils-MakeMaker" directive, and this fixes errors like the following on an Ubuntu system when building fwsnort with rpmbuild:
  
  rpm: To install rpm packages on Debian systems, use alien. See README.Debian.
error: cannot open Packages index using db3 - No such file or directory (2)
error: cannot open Packages database in /var/lib/rpm
  
  

Recently I ran into a situation in which several Snort rules from the Emerging Threats rule sets were not being properly translated into iptables rules by fwsnort. It turned out that fwsnort did not correctly parse Snort content fields that contained escaped semicolons (e.g. "\;"). In the Snort signature language, the argument to every keyword in the body of a Snort rule such as content, pcre, and flowbits is terminated with a semicolon, and some keywords also use opening and closing double quotes. But, Snort supports escaping with a backslash so that these characters can easily be made to be part of a keyword argument as opposed to the delimiting syntax. Snort does not allow the argument of a content keyword to contain an embedded semicolon that is not escaped (e.g. content:"distloc=;";), and will generate an error similar to the following if a rule does not conform to this:

Initializing rule chains...
ERROR: /etc/snort/rules/web-cgi.rules(3) =& Content data needs to be enclosed in quotation marks (")!
Fatal Error, Quitting..

In this case, we change content:"distloc=;"; to content:"distloc=\;"; and the error goes away. However, in addition to the escaping mechanism, any double quote or semicolon that is part of a content field can just be specified in hex notation between pipe "|" characters instead.

So, what are the tradeoffs in using one convention vs. the other?

Using backslashes can complicate the way an argument looks (since backslashes are not part of the content that is actually searched for in network traffic), but they can also make the argument more intuitive to look at than the hex syntax. This can be important when looking at lots of packet traces. For example, in web traffic the semicolon is used in HTTP request headers as a separator and therefore has special significance in HTTP, and the semicolon is also a separator for multiple commands launched from a command shell. So, for those that don't automatically know the hex equivalent of a semicolon (0x3b), it might be better to look at content:"distloc=\;"; instead of content:"distloc=|3B|"; when interpreting signature matches against raw packet traces since it emphasizes the importance of the semicolon.

There are important examples of Snort rule sets that use each strategy for the arguments to content fields (escaped semicolons vs. the hex equivalent). The complete Emerging Threats rule set contains 58 signatures with escaped semicolons:

$ perl -lwne 'while (/content:"(.*?)"/g) { $tmp = $1; if ($tmp =~ /\x3b/) { print $tmp; }} ' emerging-all.rules |wc -l
58

Note that the 'while (/content:"(.*?)"/g)' loop is necessary above in order to parse all content fields from each Snort rule - using something like 'if (/content:"(.*?)"/' would just parse the very first content field in each Snort rule. Here is an example content field from the "ET MALWARE Vaccine-program.co.kr Related Spyware Checkin" signature:

|0d 0a|User-Agent\: Mozilla/3.0 (compatible\; Indy Library)|0d 0a|

By contrast, I've seen a few Sourcefire VRT rule sets, and none of them appear to use escaped semicolons in any of their signatures. They always prefer to use the "|3B|" hex notation.

Now, why is this important for fwsnort? The reason is that the current version - fwsnort-1.0.5 - does not properly parse content fields with escaped semicolons. However, this will be corrected in the upcoming fwsnort-1.0.6 release, which will be completed within the next two days or so. In the meantime, here is a link to fwsnort-1.0.6-pre4 that corrects this issue.

Sean Wilkerson convinced me to join Twitter as a way to help increase the exposure that the Cipherdyne projects have on the Internet, and also to interact more with peers in the security community. After having used Twitter now for a couple of weeks, I can see some benefit in its ability to rapidly broadcast updates (140 characters at a time) and to make it easy to see what others are working on (subject to what they choose to reveal of course). Further, it seems plausible that Twitter's flexibility and speed would make it easier to acquire answers to questions than trying to contact people directly via email. Sean also had mentioned that after a recent talk he gave at DojoSec (hopefully video of it will be posted soon) he noticed that people are using Twitter during security talks as a way to organize the audience around the topic at hand. This provides a way for the audience to converge on challenging questions and bring participation to a higher level. Finally, as a measure of its success, it might be worth noting that Twitter has also been in the news recently as a mechanism for organizing a revolution in the former-Soviet republic of Moldova.

The 1.9.11 release of fwknop is ready for download. The major feature addition in this release is the ability to utilize ipfw 'sets' to organize new rules added by the fwknopd daemon on Mac OS X or FreeBSD systems after receiving a valid SPA packet. A couple of other features were added as well, such as user-defined type and code values for SPA packets sent over ICMP, and support in the test suite for running specific chains of related tests.

Here is the complete ChangeLog:

• (Julien Picalaus) Contributed patches to implement a proper interface to use ipfw 'sets' on systems running ipfw firewalls. This involved changes to fwknopd, knoptm, and the fwknop.conf file like so: Added a test to see if the local ipfw firewall policy is using dynamic rules. Added ipfw_move_rule() so that rules can be moved from one set to another. Added ipfw_disable() set subroutine and it is called at init for IPFW_SET_NUM (except when ipfw isn't using dynamic rules). Made sure that rule finding includes disabled rules (ipfw list -S and changes to regexp) and returning the set in addition to the rule number. When granting access, if a corresponding disabled rule already exists, enable it instead of adding a new one (except when ipfw isn't using dynamic rules). When adding rules, only use keep-state if there are already dynamic rules. Added IPFW_SET_NUM so that the set number for new ipfw can be specified, and add IPFW_DYNAMIC_INTERVAL so that the interval over which rules that have no associated dynamic rules are removed (the default is 60 seconds).
• (Franck Joncourt) Bug fix to add -O command line arg to knopwatchd to specify an override config file if one is given on the fwknopd command line.
• Added --icmp-type and --icmp-code command line arguments for the fwknop client in order to manually set the ICMP type/code values when using "--Spoof-proto icmp" or "--Server-proto icmp". Also restructured how SPA packets are sent over the various protocols. Here is an example of sending an SPA packet over an ICMP packet with type "123" and code "123" (not normal ICMP type/code values) with the pcap trace shown:
  
  
  # fwknop -A tcp/22 -s --Server-proto icmp --icmp-type 123 --icmp-code 123 -D 127.0.0.1
# tcpdump -i lo -l -nn icmp or udp -s 0 -X
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
07:24:32.527221 IP 127.0.0.1 > 127.0.0.1: ICMP type-#123, length 169
0x0000: 4510 00bd 0000 4000 4001 3c2e 7f00 0001 E.....@.@.<.....
0x0010: 7f00 0001 7b7b e66f 0000 0000 2b63 6a6f ....{{.o....+cjo
0x0020: 5049 6138 7345 7a35 4864 7955 5176 624b PIa8sEz5HdyUQvbK
0x0030: 6637 6f51 5934 4e36 4c6c 3454 6931 4453 f7oQY4N6Ll4Ti1DS
0x0040: 2b4f 3756 6636 4775 6234 756f 6738 4432 +O7Vf6Gub4uog8D2
0x0050: 3155 4377 5259 6b52 2b30 354b 7043 6b33 1UCwRYkR+05KpCk3
0x0060: 4f66 452f 4f32 6737 6d37 5064 4846 4842 OfE/O2g7m7PdHFHB
0x0070: 7a32 4745 3766 7a31 4a4c 7652 764e 626c z2GE7fz1JLvRvNbl
0x0080: 7a4a 7250 5355 3665 5051 5375 7a54 394b zJrPSU6ePQSuzT9K
0x0090: 702b 4446 4a79 7a6b 3847 6c51 6a70 3564 p+DFJyzk8GlQjp5d
0x00a0: 3957 3673 4f52 7945 3771 6f57 6b56 634e 9W6sORyE7qoWkVcN
0x00b0: 4e41 6167 6231 5a79 6a63 4834 49 NAagb1ZyjcH4I
  
  
• Updated all unpack() calls for packet decoding in fwknopd to use the "mN" format instead of "m[N]" format for proper operation on older versions of perl. On FreeBSD 7.0 with perl-5.6.2 the following error is generated without this fix: "Invalid type in unpack: '['".
• Bug fix to not require that gpg is installed in order to install fwknop.
• (Franck Joncourt) Documentation updates for the knopwatchd.8 man page to include the latest command line options.
• (Martin Ferrari) Bug fix to provide a work around for fwknopd segfaults on Debian systems when the version of Net::Pcap that is installed comes from doing 'apt-get install fwknop-server'. See the thread at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508432 for more info.
• Bug fix to ensure that UDP rules in ipfw firewalls are timed out correctly by knoptm (the problem was that 'keep-state' was required).
• (Test suite): Added tests for multi-port access requests. So, to gain access to tcp/22,udp/1194 with one SPA packet, the test suite verifies that the code support this.
• (Test suite): Started on updates to handle the upcoming libfko C implementation of Single Packet Authorization (the command line args are somewhat different).
• (Test suite): Added support for multiple include/exclude test identifying strings (separated by commas). For example, to run the 'Setup', 'Basic', and 'Replay' tests, just do:
  ./fwknop_test.pl --include Setup,Basic,Replay
• (Test suite): Added the ability to test sending SPA packets over ICMP.
• (Test suite): Added import_perl_modules() routine from fwknop itself to enforce the usage of the same perl modules as those that fwknop references. The main application of this is for the Net::RawIP module which is used by the test suite for the SPA over ICMP tests.

Julien Picalaus recently posted a message to the fwknop mailing list in which he explains how to use Strawberry Perl (reportedly what Larry Wall uses for his perl distribution on Windows systems) along with the Perl Packager to create a native Windows binary for the fwknop client. The result is a functional fwknop.exe binary that can be used on Windows systems to gain access to services protected by an fwknopd server running on other systems with iptables or ipfw policies.

At some point, if fwknopd is modified to hook into a Windows firewalling API, then this same technique could be used create stand alone fwknopd binaries for Windows as well. This would extend Single Packet Authorization (SPA) firmly into the Windows world. In the meantime, Julien's instructions for the fwknop client are as follows:

• Install strawberry perl.
• Use CPAN to install Crypt::CBC and Crypt::Rijndael (required by fwknop).
• Grab the fwknop sources and try to run perl fwknop -whatever options you need, to make sure it works. Apparently, you need to provide the --Home option since fwknop can't find home folders without it.
• Use CPAN to install Module::ScanDeps, PAR::Dist, PAR, PAR::Packer.
• Run pp -c -M Crypt::Rijndael -o fwknop.exe fwknop (at least this worked for me, not sure why I had to specify the Rijndael module manually).
• You have fwknop.exe.