Michael Rash, Security Researcher

Software Releases    [Summary View]

« Previous | Next »

Software Release - fwknop-1.9.8

software release fwknop-1.9.8 The 1.9.8 release of fwknop is ready for download. This release introduces support for SPA packets encrypted with gpg2, fixes issues around the usage of GnuPG options files (fwknop now does not reference them at all by default, but there are new --gpg-use-options and GPG_USE_OPTIONS directives to override this), and adds configurable base64 encoded prefixes. Normally the fwknop client strips the 'hQ' prefix (base64 encoded 0x8502) before sending an SPA packet encrypted with GnuPG out on the wire, and the fwknopd server adds it back in before base64 decoding. This is to make it more difficult to write Snort rules to detect fwknop communications.

Here is the complete ChangeLog:

  • Made the updated UI from Sean Greven available on This update fixes the timezone problem so that SPA packets generated by the UI will be properly handled by an fwknopd server.
  • Added GPG_NO_REQUIRE_PREFIX to access.conf to control whether the GnuPG 'hQ' prefix is added before base64 decoding and decrypting. Normally this is not needed, but if there appear to be communications issues between the fwknop client and the fwknopd server then this option can be useful to ensure that encrypted SPA data is sent through the GnuPG decryption routine. The 'hQ' prefix is a heuristic derived from the file 'magic' database for describing data encrypted with GnuPG, and the fwknop client normally strips this data from outgoing SPA packets (unless the --Include-gpg-prefix option is used).
  • Added 'GPG_PATH <path> to fwknopd (via access.conf) so that different paths to the gpg binary can be specified on a per-SOURCE basis. This allows one SOURCE stanza to apply one gpg binary to decrypt incoming SPA packets (say /usr/bin/gpg), and another SOURCE stanza to apply to another gpg binary (say /usr/bin/gpg2). In this way, fwknop/fwknopd now supports gpg2 in addition to gpg.
  • Bugfix to make sure that neither fwknop nor fwknopd reference any options file in GnuPG mode, and this is now the default (which overrides the now unnecessary --gpg-no-options arg). There is a new option --gpg-use-options and GPG_USE_OPTIONS to restore the usage of an options file by GnuPG by fwknop and fwknopd (not normally needed).
  • Added '--gpg-prefix <bytes> to the fwknop client so that the predictable prefix for GnuPG encrypted data can be changed. Normally this prefix is 'hQ' (base64 encoded), or the raw bytes 0x8502.
  • Added the ability to control the path used for the gpg binary on the client side with a new argument '--gpg-path <path> and on the server side with gpgCmd in the fwknop.conf file. The GnuPG::Interface module normally just takes the first instance of gpg that is the current path, but this new feature allows the path to the binary to be explicitly set.
  • Added --Save-packet-append to allow SPA packets to be appended to the --Save-packet-file in --Save-packet mode. This allows multiple SPA packets to more easily be stored for closer examination (i.e. to make sure randomness is high or to test encryption properties over large sets of SPA packets).
  • Updated fwknopd to enforce the DIGEST_TYPE variable more strictly by not accepting SPA packets that do not include digest of the specified type. The DIGEST_TYPE default is 'ALL', so normally fwknopd accepts any supported digest.
  • Bugfix to make sure to apply BLACKLIST checks to IP addresses specified with -a (or derived via -R) in addition to the source IP in the IP header (which can be modified via --Spoof-src). (Franck Joncourt submitted a patch for this.)
  • Bugfix to ensure that the permissions for the /var/run/fwknop/ file are set to 0600 (noticed by Franck Joncourt).
  • Bugfix to remove the Net::IPv4Addr dependency in the fwknop client and knoptm daemon (Franck Joncourt).
  • (Test suite) Added the script to the test/ directory. This script parses files that contain base64 encoded data (one record per line), and produces data files that can be graphed with Gnuplot in order to visualize SPA packets. The new --Save-packet-append argument makes it easy to generate large collections of SPA packets with the fwknop client, and this data can then be parsed by to look for features that are common across SPA packets (this should be minimized because every fwknop SPA packet contains 16 bytes of random data).
  • (Test suite) Added tests for GPG_NO_REQUIRE_PREFIX functionality and for the expected GnuPG prefix.
  • (Test suite) Added tests for GnuPG version 2 (a check is made to see if it is installed before these tests are run).

Software Release - gpgdir-1.9.2

gpgdir-1.9.2 released The 1.9.2 release of gpgdir is ready for download. This release introduces new functionality to support the recursive signing and verification of files within a directory in addition to the usual recursive encryption/decryption cycle. Each signature is created as a detached .asc file, which GnuPG normally creates with the '-b -a' arguments. As an illustration of this, suppose that you want to recursively sign all files with a .tar.bz2 extension within a directory "/home/user/data" and all of its sub-directories. This could be useful if you need to switch GnuPG keys after one key expires, and update all signatures to be generated from a new key. The following command will accomplish this: $ gpgdir --Include .tar.bz2 --sign data
[+] Executing: gpgdir --Include .tar.bz2 --sign data
Using GnuPG key: 1234ABCD
Enter signing password.

[+] Signing files in directory: /home/user/data
[+] Building file list...
[+] Signing: /home/user/data/file1.tar.bz2
[+] Signing: /home/user/data/file2.tar.bz2
[+] Signing: /home/user/data/dir1/file3.tar.bz2
[+] Signing: /home/user/data/dir1/file4.tar.bz2
[+] Signing: /home/user/data/dir2/file5.tar.bz2
[+] Signing: /home/user/data/dir2/file6.tar.bz2

[+] Total number of files signed: 6

And now to recursively verify all GnuPG signatures in the /home/user/data/ directory: $ ./gpgdir --verify /home/user/data
[+] Verifying signatures in directory: /home/user/data
[+] Building file list...
[+] Verifying: /home/user/data/file1.tar.bz2.asc
[+] Verifying: /home/user/data/file2.tar.bz2.asc
[+] Verifying: /home/user/data/dir1/file3.tar.bz2.asc
[+] Verifying: /home/user/data/dir1/file4.tar.bz2.asc
[+] Verifying: /home/user/data/dir2/file5.tar.bz2.asc
[+] Verifying: /home/user/data/dir2/file6.tar.bz2.asc

[+] Total number of files verified: 6

Here is the complete ChangeLog: for the 1.9.2 release:

  • Added new modes '--sign <dir>' and '--verify <dir>' to allow all files in the specified directory to be signed or verified instead of encrypted or decrypted. All GnuPG signatures are created as "<file>.asc", and the original file is not removed in --sign mode. In --verify mode, if any file does not match the expected .asc signature, then a warning like the following will be generated: [+] Verifying: /home/mbr/src/gpgdir/test/data-dir/multi-line-ascii.asc [GNUPG:] BADSIG 9EDEEEEBA742EEEF Some User <>
  • Bugfix to not die() when files that are encrypted with a different GnuPG key are encountered in a directory that is being decrypted. A warning message (see below) is now generated and the file is skipped: [+] Decrypting: /home/mbr/tmp/gpgdir/a.gpg [GNUPG:] BAD_PASSPHRASE CF16F0FCFFF3FF4F [-] Skipping file encrypted with different GnuPG key: a.gpg
  • Updated to use the status output from GnuPG::Interface to detect a bad passphrase and whether a file is encrypted with the expected GnuPG key.
  • Moved the GnuPG::Interface, Class::MethodMaker, and Term::ReadKey modules to the deps/ directory, and updated the installer and RPM spec file to account for the path change. This change was suggested by Franck Joncourt for the other projects.
  • Updated the test suite to generate files in the output/ directory according to test number and append the result of each test within each file. This makes it easy to tell which tests have failed with a simple 'grep fail output/*test'.
  • Added the gpgdir-nodeps.spec file to allow an RPM to be built that does not contain any perl modules dependencies.
  • Updated gpgdir to import perl modules via 'require' statements instead of 'use' statements so that the path to the modules directory can be changed via the --Lib-dir command line argument. Also updated to use the 'auto' heuristic (first implemented in the fwknop project) to detect perl module directories that should be used in the --Lib-dir directory to import perl modules from.

Software Release - fwknop-1.9.7

fwknop-1.9.7 release The 1.9.7 release of fwknop is available for download. This release changes several areas of fwknop related to packaging and packet decoding. First, in order to better support the work of Franck Joncourt to package the projects for Debian, all perl module dependencies have been moved into the deps/ directory. Second, it is looking like fwknop will eventually be integrated with Fedora thanks to the work of Mirek Trmac who contributed significant patches (including the removal of the NetPacket dependency). Also, as mentioned in the latest releases of fwsnort and psad, every project release is now signed with a new GnuPG key that is dedicated just for this purpose, and this key can be downloaded here.

The complete ChangeLog for fwknop-1.9.7 appears below:

  • Mirek Trmac from Red Hat contributed several patches so that fwknop can be bundled within the Fedora Linux distribution. These patches implemented the following changes:
    • Updates to fwknopd to remove the NetPacket module as a dependency (this is a particularly important update since it assists with getting fwknop bundled with Debian as well). The patch manually decodes the network and transport layer headers.
    • A patch to make the fwknop init script not start fwknopd by default on Red Hat systems. This patch also supports Fedora init script conventions better (i.e. fwknop instead of the fwknopd name for the lock file in /var/lock/subsys).
    • Updated the fwknop Makefile to respect the OPTS variable which is used in the RPM spec file.
    • Bugfix in fwknop_serv to support the variable expansion code from fwknopd. This was important for the TCPSERV_PID_FILE file which is defined as $FWKNOP_RUN_DIR/
    • Updated fwknopd to use the Net::Pcap API valid in Net::Pcap-0.14 for the datalink() function (used to detect the datalink layer type).
  • Updated fwknop, fwknopd, and knoptm to import perl modules out of the /usr/lib/fwknop/ directory if it exists. This allows the perl module path to be manipulated via the --Lib-dir command line argument and 'require' statements instead of the old 'use module' strategy.
  • Added module version output for each non-core perl module used by fwknop and fwknopd in --debug mode. This is mostly useful for the test suite to see which versions of the modules are being used.
  • Added the ability to ignore any local GnuPG 'options' file with a new command line argument --gpg-no-options (for the fwknop client) and a new access.conf config variable GPG_NO_OPTIONS (for the fwknopd daemon). This fixes a problem reported by Mike Holzmann where the 'encrypt-to' option in the default options file was causing SPA packets to exceed 1500 bytes when encrypted with a 2048-bit GnuPG key. Also added the MAX_SNIFF_BYTES to the fwknop.conf file and --Max-packet-size to the fwknop command line to alter the default of 1500 bytes if needed (but this shouldn't really be necessary).
  • Bugfix for 'Premature end of base64 data' and 'Premature padding of base64 data' warning messages from MIME::Base64 errors. Now fwknopd applies more rigorous checks for base64 encoded characters, and either of these two messages above will result in the packet data being discarded before it is sent through any decryption function. Mike Holzmann reported this issue.
  • (Test suite) Added --test-system-fwknop to allow any installed version of fwknop to be installed instead of the scripts bundled within the local source distribution.

Software Release - psad-2.1.4

psad-2.1.4 released The 2.1.4 release of psad is available for download. This release moves all dependencies into a new deps/ directory - including all perl modules, Snort rules files, and the whois client (from Marco d'Itri). This makes for a cleaner integration of psad with the Debian Linux distribution, thanks to Franck Joncourt. There are also a couple of minor bugfixes and feature enhancements according to the ChangeLog entries below. Finally, all projects are now signed with a new GnuPG key available here.

  • Restructured perl module paths to make it easy to introduce a "nodeps" distribution of psad that does not contain any perl modules. This allows better integration with systems that already have all necessary modules installed (including the IPTables::ChainMgr and IPTables::Parse modules). The main driver for this work is to make all projects easily integrated with distributions based on Debian, and Franck Joncourt has been instrumental in making this process a reality. All perl modules are now placed within the "deps" directory, and the script checks to see if this directory exists - a separate psad-nodeps-<ver> tarball will be distributed without this directory. The Debian package for psad can then reference the -nodeps tarball, and a new "psad-nodeps.spec" file has been added to build an RPM from the psad sources that does not install any perl modules.
  • Updated to use the normal system whois client if the /usr/bin/whois_psad path does not exist, and moved the whois/ directory into the deps/ directory. This removes /usr/bin/whois_psad as a strict dependency.
  • Bugfix to honor the IPT_SYSLOG_FILE variable in --Analyze-msgs mode.
  • Switched from the deprecated bleeding-all.rules file to the new emerging-all.rules available from Matt Jonkman at Emerging Threats (

Software Release - fwsnort-1.0.5

fwsnort-1.0.5 release The 1.0.5 release of fwsnort is available for download. For this release all Snort rules and perl modules packaged within the fwsnort sources have been moved into the deps/ directory so that it is clear which components are dependencies, and this change makes it easy to build "nodeps" tar archives and RPMs of fwsnort that do not include any dependencies. This change was suggested by Franck Joncourt in support of his efforts to create Debian packages of fwsnort, and this will also mean that fwsnort will integrate easily into Linux distributions such as Ubuntu). Also, from now on, all project will be signed with a new GnuPG key that is dedicated just for this purpose, and this key can be downloaded here.

The complete ChangeLog for fwsnort-1.0.5 appears below:

  • Replaced the bleeding-all.rules file with the emerging-all.rules file. This is because Matt Jonkman now releases his rule sets at
  • Restructured perl module paths to make it easy to introduce a "nodeps" distribution of fwsnort that does not contain any perl modules. This allows better integration with systems that already have all necessary modules installed (including the IPTables::ChainMgr and IPTables::Parse modules). The main driver for this work is to make all projects easily integrated with distributions based on Debian, and Franck Joncourt has been instrumental in making this process a reality. All perl modules are now placed within the "deps" directory, and the script checks to see if this directory exists - a separate fwsnort-nodeps-<ver> tarball will be distributed without this directory. The Debian package for fwsnort can then reference the -nodeps tarball, and a new "fwsnort-nodeps.spec" file has been added to build an RPM from the fwsnort sources that does not install any perl modules.
  • Updated to import perl modules from /usr/lib/fwsnort, but only if this path actually exists in the filesystem. This is similar to the strategy implemented by psad. A new variable FWSNORT_LIBS_DIR was added to the fwsnort.conf to support this.
  • Added support for multiple Snort rule directories as a comma-separated list for the argument to --snort-rdir.
  • Moved 'threshold' to the unsupported list since there will be several signatures that use this feature to detect the Dan Kaminsky DNS attack, and fwsnort does not yet support the usage of the iptables --limit match.

Software Release - fwknop-1.9.6

software release fwknop-1.9.6 The 1.9.6 release of fwknop is ready for download. This release was made at The Last HOPE conference over the weekend in NYC, and introduces several new features that make SPA traffic more difficult to detect on a network even when an IDS is watching. Previous to the 1.9.6 version of fwknop, it was possible to write Snort rules to detect SPA traffic by looking for invariant artifacts from base-64 encoding and also from encryption operations (both Rijndael and GnuPG). These artifacts are now stripped out by the fwknop client before being transmitted on the wire, and the result is that SPA packets are now more highly randomized. This implies that SPA packets generated by the 1.9.6 release are not compatible with older fwknop deployments by default, but the client does offer command line arguments to maintain compatibility if necessary.

Here is an excerpt from the ChangeLog:

  • SPA packets are base64-encoded by the fwknop client, and this encoding pads data with '=' chars until the total length of the encoded data is a multiple of four. This characteristic can be used within a Snort rule to assist in the detection of SPA communications. The 1.9.6 release of fwknop strips out these padding characters before the client sends an SPA packet, and the fwknopd server adds them back in (to form a multiple of four) before base64 decoding the packet data. This reduces the level of identifying information in SPA packets and therefore makes it more difficult to detect the usage of SPA for service access. For reference, a Snort rule that would detect SPA packets via the trailing '=' chars (previous to this release) would be:

    alert udp any any -> any 62201 (msg:"fwknop SPA traffic"; dsize:>150; pcre:"/==$/"; sid:20080001; rev:1;)

  • According to the 'file' command (via it's 'magic') database, files that are encrypted with GnuPG begin with 0x8502, and this is true for SPA packets generated by fwknop (previous to this release). In fwknop-1.9.6, the "hQ" prefix is removed by the fwknop client and added back in by the fwknopd server if it doesn't exist. This measure is another effort to make SPA packets more difficult to detect on the wire, such as with the following Snort rule:

    alert udp any any -> any 62201 (msg:"fwknop GnuPG encrypted SPA traffic"; content:"hQ"; depth:2; dsize:>1000; sid:20080003; rev:1;)

  • Updated the fwknop client to randomize the UDP source port for default SPA packet generation. There is also a new command line argument --Source-port <port> to allow the user to manually set the source port on the fwknop client command line. A lot more attention is given now to source ports after the Dan Kaminsky DNS caching exploit, and it turns out that even on Linux that the kernel did not randomize UDP source ports until the 2.6.24 kernel. Of course, any userspace process is free to request a random port itself, but if a userspace application did not build this in then it would be up to the kernel to assign a source port. In the case of Linux, here are two links that show the change to the kernel code as well as the ChangeLog entry for UDP source port randomization:

    Kernel commit


Software Release - gootrude-0.2

Gootrude queries Yahoo Gootrude-0.2 is available for download. This release changes the default search engine from Google to Yahoo because it appears that Yahoo's Terms of Service do not prohibit automated queries (although I'm not a lawyer). Gootrude retains the ability to query Google at your own risk if you so desire. As long as you use Gootrude as designed to collect search engine results only once per day with a limited number of search terms (say, 20 or less), it is unlikely to provoke a negative reaction from search engines. Over time, support for many additional search engines will be added to Gootrude so that search results can be trended from all sorts of different data sources.

Also, this post should really have announced Gootrude as a "search results trender" instead of a "search trender". The goal of the project is made clear in the README, and here is the complete ChangeLog, for the Gootrude-0.2 release:

  • Added support for querying Yahoo for search results and made this the default because Google's TOS does not technially allow automated queries. However, Gootrude continues to support querying Google for search results, and responsible use of Gootrude once per day with a limited set of search terms should most likely not be a cause for concern for Google. A new syntax of the searchterms.conf file allows search terms to express which search engine should be queried on an individual basis according to the following syntax (note the middle element): [Linux "highspeed firewalls"] [yahoo:count] [Linux_highspeed_firewalls.dat]
  • Changed the default USER_AGENT variable to "Gootrude <version>".
  • Added a percentage-based offset for the plot minimum and maximum ranges on the y-axis (with a default of 10% controlled by two new variables MIN_PERCENT_DIFF and MAX_PERCENT_DIFF). This value can also be set by the search terms themselves via an additional config element as follows (for a 20% offset instead for example): [yrange:20%/20%]
  • Increased SEARCH_TERM_DELAY to two seconds to be nicer to search engines.

Three software releases - psad, fwknop, gpgdir

Three software releases The following releases of the Cipherdyne security projects are now available: psad-2.1.3, fwknop-1.9.5, and gpgdir-1.9.1. The motivation for a group release stems from the need to make similar changes to the fwknop and gpgdir projects to update to version 2.11 of the Class::MethodMaker perl module from CPAN - a dependency of GnuPG::Interface. This version fixes a build error under recent versions of perl (such as perl-5.10.0) which are distributed on systems like Fedora 9. Also, for both fwknop and gpgdir, thanks to a suggestion made by Jean-Denis Girard on the fwknop mailing list, the default locale has been set to "C" via the LC_ALL environmental variable so that GnuPG output can be properly interpreted even on systems where a different locale is used. The locale can be manually set or not used at all with two new command line arguments --locale <str> and --no-locale respectively. On another note, Kevin Hilton has written an excellent how-to for fwknop on Ubuntu systems.

For psad, it was time to make a new release after it became necessary to update the whois client so that IP addresses such as (which was scanning a psad user) could be properly identified with whois records. In addition, psad was updated to parse syslog files directly for iptables log messages instead of requiring reconfiguration of the syslog daemon to write messages to the /var/lib/psad/psadfifo named pipe. This simplifies the proper installation of psad, and is now a default setting. Although there is a slight performance penalty since psad now parses all messages that are written to the /var/log/messages file (this is the default path), it should not be noticeable on most systems. Further, the old behavior of using the named pipe can be restored via the ENABLE_SYSLOG_FILE variable in the /etc/psad/psad.conf file.

Finally, Franck Joncourt has made excellent progress in developing Debian packages for the IPTables::ChainMgr and IPTables::Parse modules, and he is also close to a Debian package for the fwknop project.

The complete change logs for these new releases can be found as follows: psad-2.1.3, fwknop-1.9.5, and gpgdir-1.9.1

Single Packet Authorization with Port Randomization

Single Packet Authorization with Port Randomization After two months of development, the 1.9.4 release of fwknop is available for download. This release introduces new functionality that has implications for hardening both fwknop SPA communications and the follow-on connections that client programs make (such as SSH). Specifically, the 1.9.4 release adds two port randomization options to 1) send the SPA packet over a random port between 10,000 and 65,535 (requires updating the default PCAP_FILTER variable on the fwknopd server side), and 2) select a random port that is used as the destination port in a NAT operation on the fwknopd server system. These two options can be used individually or together, and are enabled with two new command line options, --rand-port and --NAT-rand-port respectively, to the fwknop client (see examples below).

The inspiration for adding this functionality came from a post to the "Documentation, Tips & Tricks". Gentoo forum, and I have credited John Brendler with the idea. In response to John's post, I would like to mention however that all Port Knocking / Single Packet Authorization implementations suffer from "piggy-back exploits", including those that select random ports for SPA communications or for NAT operations against follow-on sessions. A "piggy-back exploit" is where an attacker takes advantage of the fact that a firewall rule inserted by a PK/SPA system accepts a connection from an IP address to a destination port specified by the SPA packet(s). So, if the attacker can spoof packets from this source IP, or if the attacker happens to be on the same internal network as the SPA client (and hence sends connections out through the same NAT device), then the firewall rule will accept these packets just as though they originated from the legitimate SPA client system. If an attacker is in a privileged position and can sniff the legitimate session as it is initiated, then one can envision an automated attack that spoofs packets from the same source IP and directs them at the same service. Further, such an "attack" can be made just by watching outgoing connections without paying any attention whatsoever to whether or not a set of SPA packets are sent first - it doesn't matter if the real connection is made to a random translated port on the SPA system; the attacker can see this port in the real connection itself.

Now, should you be concerned about such a piggy-back attack? Not really. First, if the attacker is not going through the same NAT device as the real connection, then any response to a spoofed packet will go back to the spoofed source - not back to the attacker. So, for TCP connections, unless the attacker can effectively perform a sequence prediction attack an existing connection (and even then that is of little use against an encrypted application layer protocol such as SSH), this is not very effective. Second, even if an attacker is behind the same NAT device as the SPA client, just being able to access the targeted service over TCP/IP does not imply an automatic vulnerability; SPA is an additive measure to whatever existing security mechanisms are already in place (barring a vulnerability in libpcap itself in the SPA server for example). Third, there are an awful lot of networks out there to which an attacker will not have such privileged access, and therefore not be in a position able to sniff anything useful. Forth, fwknop minimizes the opportunity for an attacker to conduct a piggy-back attack by maintaining a small window of time (30 seconds by default) for any new firewall rules after receiving a valid SPA packet. By using a connection tracking mechanism built into iptables or ipfw, any connection established during the accept window is allowed to remain open but all attempts to create a new connection must first preceeded with a new SPA packet in order to gain access.

Finally, although port randomization is an enhancement, fwknop has had the ability for a long time to allow the user to select the destination port for SPA packets with the --Server-port argument as well as the destination port for a NAT'd connection to an internal system. Hence, fwknop SPA packets are not always sent over udp/62201. But, I agree that it is useful to add the port randomization features that John Brendler suggested, and this is why I've implemented them in fwknop. Randomizing the SPA destination port along with the destination port of the follow-on connection makes traffic analysis more difficult.

Now, let us see the new --rand-port and --NAT-rand-port options in a practical example. We'll assume that the fwknopd server is at hostname spaserver with IP, and the fwknop client runs on the spaclient system with IP We ultimately want to gain access to SSHD on the spaserver system, and we assume that iptables is configured in a default-drop stance for all attempts to communicate with SSHD. Also, there is no requirement to necessarily attempt to gain access only to an SSHD instance running on an internal server via a forwarded port - the iptables PREROUTING chain can forward a port to a local socket as well (based on a routing calculation for the destination IP), and on the fwknop client command line we use the --NAT-local argument for this.

Because the --rand-port option sends the SPA packet over a random destination port, we first need to set the PCAP_FILTER variable as follows in the /etc/fwknop/fwknop.conf file: [spaserver]# vi /etc/fwknop/fwknop.conf
PCAP_FILTER udp dst portrange 10000-65535;

[spaserver]# /etc/init.d/fwknop restart
[+] knopwatchd is running (pid: 17584), stopping daemon
[+] knoptm is running (pid: 17582), stopping daemon
[+] fwknopd is running (pid: 17580), stopping daemon
Starting the fwknop daemons.
With the fwknopd server up and running, we now use the fwknop client to gain access to SSHD on the spaserver system via a randomly selected NAT'd port (and we show that SSHD is never accessible over the standard TCP port 22 even from the spaclient system):
[spaclient]$ nmap -sT -n -P0 -p 22

Starting Nmap 4.20 ( ) at 2008-06-02 01:48 EDT
Interesting ports on
22/tcp filtered ssh

Nmap finished: 1 IP address (1 host up) scanned in 12.017 seconds

[spaclient]$  fwknop -A tcp/22 --NAT-local --NAT-rand-port \
--rand-port -R -D

[+] Starting fwknop client (SPA mode)...
[+] Requesting NAT access for randomized port: 16791
    Resolving external IP via:
    Got external address:

[+] 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:    4846125760033285
        Username:       mbr
        Timestamp:      1212386108
        Version:        1.9.4
        Type:           5 (Local NAT access mode)
        NAT access:,16791
        SHA256 digest:  ZyWG+nRGYMfWFssJuOy7bhGmJHpHia6T1igaNnVVhqI

[+] Sending 206 byte message to over udp/52949...
    Requesting NAT access to tcp/22 on via port 16791

[spaclient]$  ssh -p 16791 mbr@
mbr@'s password:
The above output shows that the client system indeed has access to the spaserver system via TCP port 16791, which is forwarded to the local SSH daemon. In the /var/log/messages file, fwknopd has written the following messages to syslog: [spaserver]# tail /var/log/messages
Jun 2 01:54:16 spaserver fwknopd: received valid Rijndael encrypted packet from:, remote user: mbr, client version: 1.9.4 (SOURCE line num: 151)
Jun 2 01:54:17 spaserver fwknopd: add FWKNOP_PREROUTING -> to 22) DNAT rule 30 sec
Jun 2 01:54:17 spaserver fwknopd: add FWKNOP_INPUT -> ACCEPT rule 30 sec
Jun 2 01:54:58 spaserver fwknop(knoptm): removed iptables FWKNOP_PREROUTING DNAT rule for ->, 30 sec timeout exceeded
Jun 2 01:55:11 spaserver fwknop(knoptm): removed iptables FWKNOP_INPUT ACCEPT rule for ->, 30 sec timeout exceeded
In closing, here is an abbreviated version (the randomization options are not duplicated here) of the fwknop-1.9.4 ChangeLog:

  • Added the ability to specify the port that SPA packets are sent over with the fwknop client by using the syntax "<host|IP>:<port>". So, for example, to have the client send an SPA packet to over UDP port 12345 (instead of the default of 62201), one could use the following command:

    $ fwknop -A tcp/22 -R -D

  • Bugfix to add a check for "keep-state" in ipfw policies in addition to the existing "check-state" check (noticed by Sebastien Jeanquier).
  • Updated the script to try to determine the OS type as early as possible during the install process.
  • Added the MIN_SPA_PKT_LEN variable with 160 (bytes) as the default. This allows fwknopd to ignore packets that are not at least this many bytes (including packet headers) before any decryption attempt is made.
  • Added --time-offset-plus and --time-offset-minus args to the fwknop client command line. This allows the time stamp within an SPA packet to be influenced without setting the system clock (which normal users cannot usually do). This is useful for when the client and server systems have clocks that are out of sync.
  • Bugfix on Ubuntu systems to make sure that the fwknop init script is installed with a priority of 99 instead of 20 - this puts fwknop as late as possible within the boot sequence so that the system is ready to run fwknop.
  • Bugfix to not open ports that are not specifically requested in an SPA packet even if those ports are listed in the OPEN_PORTS variable in the access.conf file.
  • Updated to version 5.47 of the Digest::SHA module.
  • Updated to version 0.7 of the IPTables::ChainMgr module (includes perldoc documentation).
  • Updated to version 0.6 of the IPTables::Parse module (includes perldoc documentation).
  • Added NAT, port randomization, and and time offset option discussions to fwknop(8) man page.

Software Release - gpgdir-1.9

gpgdir-1.9 released The 1.9 release of gpgdir is ready for download. This release introduces minor fixes to change the --Obfuscate file format and adds process locking against multiple instances of gpgdir from operating against the same directory.

On a side note, Ben Martin wrote an article on gpgdir entitled "Protecting directory trees with gpgdir" for Ben emphasizes using the gpgdir --Wipe option to securely delete files from the filesystem after they are encrypted with GnuPG, and I agree with this. In addition, there is nothing that prevents gpgdir from being used in conjunction with an encrypted filesystem such as Cryptmount to achieve additional protections for directory structures (which gpgdir does not alter).

Here is the complete ChangeLog: for the 1.9 release:
  • Changed --Obfuscate-filenames format to not include the gpgdir PID. This allows directories to be encrypted/decrypted under -O multiple times without creating new filenames (which would pollute encrypted directories under rsync to other systems). The new -O encrypted filename format is just "gpgdir_<num>.gpg".
  • Added PID locking against directories so that multiple gpgdir processes cannot operate against the same top-level directory simultaneously. This is useful for users that typically operate with multiple shells and might launch gpgdir from any of them.
« Previous | Next »