Michael Rash, Security Researcher

2007 Blog Archive    [Summary View]

EnGarde Secure Linux Bundles fwknop and psad

EnGarde Secure Linux Bundles fwknop and psad The EnGarde Linux distribution, which focuses on security, has announced that they now bundle both fwknop and psad within their latest release (3.0.18). Here is a quote from their press release:

   Guardian Digital is happy to announce the release of EnGarde Secure Community 3.0.18 (Version 3.0, Release 18). This release includes many updated packages and bug fixes, some feature enhancements to Guardian Digital WebTool and the SELinux policy, and a few new features.

In distribution since 2001, EnGarde Secure Community was one of the very first security platforms developed entirely from open source, and has been engineered from the ground-up to provide users and organizations with complete, secure Web functionality, DNS, database, e-mail security and even e-commerce.

Coupled with the EnGarde annoucement, has published an article about how to configure fwknop on EnGarde systems to add a strong default-drop stance for SSHD:

   This article will walk the reader through an EnGarde Secure Linux implementation of fwknop, from the initial iptables rules setup to the deployment of fwknop on both the server and client side. By the end of the article, the user will be able to explicitly shutdown all access to the EnGarde Secure Linux SSH daemon to only those with fwknop credentials.

Software Release - fwknop-1.9.0

fwknop-1.9.0 release The 1.9.0 release of fwknop is ready for download. This release introduces major new functionality including inbound NAT support for authenticated connections (iptables firewalls only for now), iptables OUTPUT chain support, a test suite for SPA communications, the ability of the fwknopd daemons to restart themselves after a configurable length of time, and more.

Below is the output of the new test suite running on a Linux system: # ./

[+] ==> Running fwknop test suite; firewall: iptables <==

[+] perl program compilation.........................................pass (0)
[+] C program compilation............................................pass (1)
[+] Stopping any running fwknopd processes...........................pass (2)
[+] Flushing all fwknop iptables rules...............................pass (3)
[+] Testing Rijndael key validity....................................pass (4)
[+] Generating SPA access packet with fwknop client..................pass (5)
[+] Sniffing SPA access packet to acquire access.....................pass (6)
[+] Firewall access rules exist......................................pass (7)
(Sleeping for 10 (+5) seconds for firewall rule timeout)
15 10 5 0
[+] Firewall access rules removed....................................pass (8)
[+] Stopping all running fwknopd processes...........................pass (9)
[+] Replay attack detection..........................................pass (10)
[+] SPA packet randomness............................................pass (11)
[+] Generating SPA packet with src addr......................pass (12)
[+] Sniffing packet source address with src addr.............pass (13)
[+] Generating SPA packet with invalid user..........................pass (14)
[+] Invalid user detection...........................................pass (15)
[+] Generating SPA command packet....................................pass (16)
[+] Sniffing SPA command packet and executing........................pass (17)
[+] Making sure firewall rules have been removed.....................pass (18)
[+] Generating SPA command packet with non-matching regex............pass (19)
[+] SPA command packet filtered......................................pass (20)
[+] Making sure firewall rules do not exist..........................pass (21)
[+] Stopping all running fwknopd processes...........................pass (22)
[+] Generating FORWARD chain access packet...........................pass (23)
[+] FORWARD request detection........................................pass (24)
[+] FORWARD and DNAT access..........................................pass (25)
(Sleeping for 10 (+5) seconds for firewall rule timeout)
15 10 5 0
[+] Making sure firewall rules have been removed.....................pass (26)
[+] Stopping all running fwknopd processes...........................pass (27)
[+] Generating SPA access packet with fwknop client..................pass (28)
[+] SPA communications via tcpdump capture file......................pass (29)
[+] Firewall access rules exist......................................pass (30)
(Sleeping for 10 (+5) seconds for firewall rule timeout)
15 10 5 0
[+] Firewall access rules removed....................................pass (31)
[+] Stopping all running fwknopd processes...........................pass (32)
[+] Deleting all fwknopd iptables chains.............................pass (33)

[+] ==> Passed 34 tests against fwknop. <==
For those interested in the changes in the fwknop-1.9.0 release, here is the complete ChangeLog:
  • Added a test suite so that fwknop and fwknopd functionality can be automatically tested over the loopback interface (see the script in the test/ directory).
  • Major update to allow SPA packets to create DNAT connections to internal systems through the FORWARD chain (iptables only). This is useful to connect through to internal systems (that may be running on non-routable IP addresses) via a border firewall or router that is running fwknopd to create inbound DNAT rules.
  • Added support for the iptables OUTPUT chain via two new variable in the fwknop.conf file: ENABLE_IPT_OUTPUT and IPT_OUTPUT_ACCESS. This is useful for iptables firewalls that are not running the conntrack modules and that have a restrictive OUTPUT chain (so SYN/ACK responses are not allowed out without an explicit ACCEPT rule).
  • Added the ability to force the fwknopd and knoptm daemons to restart themselves (via knopwatchd) after a configurable timeout (see the ENABLE_VOLUNTARY_EXITS and EXIT_INTERVAL variables in the /etc/fwknop/fwknop.conf file). This feature is for those that want fwknopd to go through its initialization routine periodically just in case there is a logic (or other) bug that might result in fwknopd not accepting a valid SPA packet. NOTE: This feature is disabled by default, and is not normally needed since fwknopd is quite stable in most deployments.
  • Major update to perform all firewall rule expirations with knoptm, which is now started in all data collection modes. Older versions of fwknopd maintained its own firewall rule expiration code for the FILE_PCAP, ULOG_PCAP, and KNOCK modes, so two mechanisms were being maintained for the same purpose. The 1.9.0 release fixes this oversight.
  • Minor bugfix to have knopwatchd generate syslog messages whenever an fwknop daemon needs to be restarted.
  • Added --interface command line argument to to allow the sniffing interface to be specified from the command line. Also updated to enforce a 10-try maximum for attempting to accept a valid interface name from the command line (LANG env issues can exist sometimes).
  • Updated SPA packet format for server_auth and forward_info elements; the internal MD5 sum is now always the last field in an SPA packet. This makes extensions of the SPA protocol much easier, and the generation of SPA packets more elegant. Also, SPA packet validation has been improved to ensure that fields that are supposed to be digits really only contain integer data.
  • Added ENABLE_FORWARD_ACCESS variable to the access.conf file, and added ENABLE_IPT_FORWARDING to the fwknop.conf file. These variables provide the per-SOURCE ability to create DNAT connnections through the FORWARD chain.
  • Replaced the IPT_AUTO_CHAIN1 variable with IPT_INPUT_ACCESS and IPT_FORWARD_ACCESS in fwknop.conf.
  • Added --Forward-access argument to the fwknop client.
  • Added client version number to syslog messages generated by fwknopd when a valid SPA packet is received.
  • Added human readable timestamp to MD5 cache. Here is an example of the update format: X6WF2C29kEgAv4aDJ8TDeQ [Wed Nov 28 09:24:46 2007]
  • Added --Count argument to fwknopd so that it calls exit() when the specified number of packets is monitored.
  • Added --no-logs argument to knoptm in support of the test suite so that no emails are generated.
  • Bugfix in fwknopd to account for non-Ethernet link layer header over *BSD loopback interfaces.
  • Added --Save-dst argument to the fwknop client to add a priority file to store client command line arguments (~/ This file is only overwritten when --Save-dst is used.
  • Added fwknopd --fw-del-chains to allow the fwknopd iptables chains to easily be deleted.
  • Minor fwknopd bugfix to set process exit status to 0 when --Kill is used.

Single Packet Authorization and Port Knocking Forum

Single Packet Authorization and Port Knocking Forum Sebastien Jeanquier has started a dedicated online forum for the discussion of port knocking and Single Packet Authorization. I think this is a great idea, and will help to increase awareness in SPA and related technologies. Here is Sebastien's first post that introduces the forum:

   There have been numerous debates around the subjects of Port Knocking and Single Packet Authorization (SPA). Does it increase security? Does it not? What are the drawbacks? Although I would definitely group Port Knocking and SPA under the "Port Knocking" banner, the two methods are actually quite different, and many people sometimes confuse them.

Despite all the discussion, there has not been any dedicated forum for those with interests in these great subjects... until now. This forum is open to any and all discussions about PK and SPA ideas, developments, and uses; and you will undoubtedly get plenty of clarifications or help with regards to how PK/SPA work and how to use them in your security implementations.

One topic that I would like to see discussed is what the ideal features, design, and implementation would be in an SPA system. There are many considerations here, everything from what the right way is to interact with the packet filter to which language to use.

fwsnort-1.0.3 Software Release

fwsnort-1.0.3 Software Release The 1.0.3 release of fwsnort is ready for download. This release adds the ability to interpret basic PCRE's expressions (more detail below) and includes a major signature update from Bleeding Threats. A new command line argument --include-re-caseless allows fwsnort to restrict its translation operation to Snort rules that contain a regular expression (matched case-insensitively). For example, here is the command to build an iptables policy derived from Snort rules in the bleeding-all.rules file that contain the string "sid:2007" (for signatures that were added in 2007): # fwsnort --include-type bleeding-all --include-regex "sid:2007" --include-re-caseless
Snort Rules File Success Fail Ipt_apply Total

[+] bleeding-all.rules 614 28 607 642
614 28 607 642

[+] Generated iptables rules for 614 out of 642 signatures: 95.64%
[+] Found 607 applicable snort rules to your current iptables

[+] Logfile: /var/log/fwsnort.log
[+] iptables script: /etc/fwsnort/
This results in 607 successfully translated Snort rules, and here is the iptables command equivalent built by fwsnort for the "BLEEDING-EDGE MALWARE Adware Checkin" signature: $IPTABLES -A FWSNORT_OUTPUT_ESTAB -p tcp --dport 80 -m string --string "wmid=" --algo bm -m string --string "&mid=" --algo bm -m string --string "&lid=" --algo bm -m comment --comment "sid:2007696; msg:BLEEDING-EDGE MALWARE Adware Checkin; classtype:trojan-activity; rev:1; FWS:1.0.3;" -j LOG --log-ip-options --log-tcp-options --log-prefix "[15] SID2007696 ESTAB " Here is the full ChangeLog:
  • Added --include-re-caseless and --exclude-re-caseless options to have --include-regex and --exclude-regex options match case insensitively.
  • Major signature update from Bleeding Threats. This update includes a large number of new signatures with PCRE statements, with an emphasis on detecting SQL injection attacks directed at internal webservers from external sources.
  • Added the ability to interpret PCRE statements that include simple string matches separated by ".*" and ".+" as multiple iptables string matches. The only negative consequence in terms of signature detection is that ordering is not preserved; that is, the PCRE "/UNION.+SELECT/" would only match a packet that contains "UNION" followed by "SELECT", whereas an iptables rule that uses a string match for UNION and a separate string match for SELECT would match a packet that contains both strings but in reverse. Typically this is not a huge concern, and the PCRE translation can be disabled with a new option --no-pcre.
  • Added asn1 keyword to unsupported list.

fwknop Windows UI

fwknop Windows UI Sean Greven, a contributor to the fwknop project, has developed a UI for generating fwknop Single Packet Authorization messages from Windows systems without the need for the regular fwknop client to be installed. The UI can be downloaded here, and the source code (which Sean has contributed to fwknop under the GPL) can be downloaded here.

Although the fwknop client functions under Cygwin, it is an important step to be able to generate SPA packets without fwknop installed at all since many users do not run systems with Cygwin installed. With Sean's UI, users can easily leverage the strength of Single Packet Authorization to protect services such as SSHD on Linux, *BSD, or Mac OS X systems and authenticate from Windows at the same time. The UI is currently in a testing phase and the initial version supports symmetrically encrypted SPA messages (with the Rijndael cipher), but also leveraging GnuPG is on the roadmap.

Here is a screenshot of the UI installed on a Windows 2000 system. The UI is on the left, and the fwknopd daemon on the target (Linux) system is running in debug mode so that you can see the iptables ACCEPT rule added for the Windows client and then deleted after 30 seconds. Netfilter's connection tracking subsystem is used to keep any established connection open, but no new connections can be established unless another non-replayed SPA packet is sniffed off the wire by fwknopd:
fwknop Windows UI

Ubuntu Howto on Single Packet Authorization

Ubuntu fwknop Howto Gilbert Mendoza of has written an excellent howto guide for making use of Single Packet Authorization with fwknop on the Ubuntu Linux distribution. While fwknop is not yet released as a Debian package (although this should be coming soon), Gilbert's guide provides instructions for bootstrapping fwknop into a functional state on Ubuntu. He covers the installation of fwknop, configuring fwknopd to authenticate SPA clients with GnuPG (including construction of a specific set of GnuPG keys for this purpose), and setting up a default-drop iptables policy. Here is a portion of the introduction:

   Single Packet Authorization (SPA) using "fwknop" is probably one of the coolest recent innovations in server and network access control technology. Just what is SPA, you ask? SPA is a method of limiting access to server and network resources by cryptographically authenticating users before any type of TCP/IP stack access is allowed.

In it's simplest form, your Linux server can have an inbound firewall rule that by default drops all access to any of it's listening services. Nmap scans will completely fail to detect any open ports, and zero-day attacks will not have any effect on vulnerable services since the firewall is blocking access to the applications.

Gilbert made a posting to his blog a few months ago about SPA as well.

Software Release - fwknop-1.8.3

fwknop-1.8.3 release The 1.8.3 release of fwknop is ready for download. This release reinstates the legacy port knocking operation mode (for those that really want to use it instead of Single Packet Authorization). A few bugs have also been fixed, particularly for the auto-resolution of external NAT addresses via (and a backup resolution URL exists now as well that you can hit with the --URL option on the fwknop client command line).

Below is an illustration of the old port knocking mode in action. The fwknopd server running on reconfigures the iptables policy to allow an SSH connection from the client system after receiving the encrypted port knock sequence: $ fwknop -A tcp/22 -a -D --Server-mode knock
[+] Starting fwknop client (encrypted port knocking mode)...
[+] Enter an encryption key. This key must match a key in the file
/etc/fwknop/access.conf on the remote system.

Encryption Key:
[+] Clear-text sequence (11 bytes): 192 168 10 2 0 22 6 28 109 98 114
[+] Cipher-text sequence (32 bytes): 83 97 108 116 101 100 95 95 110 133 220 202 45 184 129 230 175 166 62 162 104 46 183 22 193 82 17 126 174 38 76 222
[+] Sending port knocking sequence to knock server:
   -> tcp/61083 (packet: 0)
   -> tcp/61097 (packet: 1)
   -> tcp/61108 (packet: 2)
   -> tcp/61116 (packet: 3)
   -> tcp/61101 (packet: 4)
   -> tcp/61100 (packet: 5)
   -> tcp/61095 (packet: 6)
   -> tcp/61095 (packet: 7)
   -> tcp/61110 (packet: 8)
   -> tcp/61133 (packet: 9)
   -> tcp/61220 (packet: 10)
   -> tcp/61202 (packet: 11)
   -> tcp/61045 (packet: 12)
   -> tcp/61184 (packet: 13)
   -> tcp/61129 (packet: 14)
   -> tcp/61230 (packet: 15)
   -> tcp/61175 (packet: 16)
   -> tcp/61166 (packet: 17)
   -> tcp/61062 (packet: 18)
   -> tcp/61162 (packet: 19)
   -> tcp/61104 (packet: 20)
   -> tcp/61046 (packet: 21)
   -> tcp/61183 (packet: 22)
   -> tcp/61022 (packet: 23)
   -> tcp/61193 (packet: 24)
   -> tcp/61082 (packet: 25)
   -> tcp/61017 (packet: 26)
   -> tcp/61126 (packet: 27)
   -> tcp/61174 (packet: 28)
   -> tcp/61038 (packet: 29)
   -> tcp/61076 (packet: 30)
   -> tcp/61222 (packet: 31)
[+] Finished knock sequence.
$ ssh -l mbr
On the fwknopd server, the following messages are written to syslog that show an iptables ACCEPT rule being added for the client system for 30 seconds and then removed. The SSH connection from the client remains open by using the Netfilter connection tracking subsystem to allow packets in the ESTABLISHED state through, but once the ACCEPT rule is removed no new SSH connections can be established: Nov 17 10:34:47 isengard fwknopd: successful knock decrypt for (SOURCE block: 1)
Nov 17 10:34:47 isengard fwknopd: adding iptables FWKNOP_INPUT ACCEPT rule for -> tcp/22 (30 seconds)
Nov 17 10:35:19 isengard fwknopd: removed iptables FWKNOP_INPUT ACCEPT rule for -> tcp/22, 30 second timeout exceeded
Port knocking sequences do not necessarily have to be encrypted, and fwknop supports shared sequences. This can be useful to allow systems where perl is not installed to take advantage of some port knocking capabilities without requiring the fwknop client. In the screenshot below, the fwknopd server (in the right hand terminal) has been configured to accept a sequence that consists of the two TCP ports 1234 followed 5001. The client (in the left hand terminal) just needs to use any program such as netcat or telnet to hit these two ports, which generates iptables log messages at the fwknopd server where the shared sequence is parsed and validated. Once the correct sequence is seen, fwknopd opens port 22 for 30 seconds (this timeout is configured in the /etc/fwknop/access.conf file):
fwknop-1.8.3 release
For those interested in the changes in the fwknop-1.8.3 release, here is the complete ChangeLog:
  • Updated external IP resolution to point to, and added as a backup site for fwknop IP resolution.
  • Added storage of source IP along with SPA MD5 sum. This allows the user to infer which networks are more hostile if an SPA packet is replayed.
  • Added SPA packet hex dumps in 'fwknopd --debug' mode so that the integration of third-party encryption algorithms is easier to troubleshoot. Sean Greven contributed a patch for this.
  • Reinstated the legacy port knocking mode. It appears that all encrypted output from the updated Crypt::Rijndael module is at least 32 bytes long, so port knocking sequences are now 32 bytes long as well (they were previously 16 bytes long in old versions of fwknop).
  • Bugfix to ensure the key length is at least 8 chars in --get-key mode.
  • Minor update to remove init message on OS X install.
  • Updated to set the LANG environmental variable to "en_US.UTF-8". This should fix the problem where the output of ifconfig was not interpreted correctly if the locale LANG setting is not English.
  • Implemented verbose email alerting by setting the ALERTING_METHODS variable to "verbose". This instructs fwknopd to generate a new email message for each message that it normally logs vis syslog (this feature is not the default, and must be manually enabled). Online Interview

Digg Michael Rash Interview Online Interview interviewed me about various topics in computer security (with an emphasis on Linux security). The interview grew out of the publication of the Linux Firewalls book, and Mirko Zorz wrote the (excellent) interview questions. Writing answers to these questions was a thought provoking process, and I'm grateful for having the opportunity to write for The interview opens with a question about how I became interested in computer security, and I'd like to mention the following note (I didn't put this in the interview):

One of the best books I have ever read in the field of computer security is Firewalls and Internet Security: Repelling the Wily Hacker by Cheswick and Bellovin. It was 1997, and I was getting my feet wet working with Check Point firewalls and a few Cisco NetRanger systems for network IDS, and with the help of the book to provide some fascinating examples, I was hooked. I have not yet read the second edition of the book, but the first edition was outstanding. A nice balance is struck between theory and practical examples (such as concepts in cryptography vs. tracking the movements of a malicious individual with a custom modifications to an STMP daemon). Anyone looking for an authoritative introduction to computer security should read the book.

On an unrelated note, there have been a couple of additional reviews of the Linux Firewalls book; one at and the other by A.P. Lawrence. The later even includes a video review at

Free Linux Firewalls Book Chapter

Digg Free Linux Firewalls Book Chapter Free Linux Firewalls Book Chapter No Starch Press has posted Chapter 10: Deploying fwsnort for free download on their site. This chapter concentrates on the application of fwsnort to iptables rulesets, as mentioned in the chapter introduction:

   With the theoretical discussion in Chapter 9 on the emulation of Snort rule options within iptables behind us, we'll talk in this chapter about how to get fwsnort to actually do something! Namely, we'll discuss the administration of fwsnort and illustrate how it can be used to instruct iptables to detect attacks that are associated with the Snort signature ruleset.

When fwsnort is executed from the command line with no restrictive arguments to limit the scope of the translation process, the default output displays the success and failure rates for translating Snort signatures as seen below. Not all Snort signatures can be re-cast into an iptables rule because of complexities (such as PCRE's) that cannot (yet) be handled within iptables, but as you can see fwsnort achieves a 60% translation rate for the Snort-2.3.3 ruleset - this is more than sufficient to catch a lot of malicious traffic.
[iptablesfw]# fwsnort
Snort Rules File Success Fail Ipt_apply Total [+] attack-responses.rules 15 2 0 17 [+] backdoor.rules 62 7 1 69 [+] bad-traffic.rules 10 3 0 13 [+] bleeding-all.rules 1076 573 5 1649 [+] exploit.rules 31 43 0 74 [+] web-cgi.rules 286 62 0 348 [+] web-client.rules 7 10 0 17 [+] web-coldfusion.rules 35 0 0 35 [+] web-frontpage.rules 34 1 0 35 [+] web-iis.rules 103 11 0 114 [+] web-misc.rules 265 61 0 326 [+] web-php.rules 78 48 0 126 [+] x11.rules 2 0 0 2 2725 1761 91 4486 [+] Generated iptables rules for 2725 out of 4486 signatures: 60.74% [+] Found 91 applicable snort rules to your current iptables policy. [+] Logfile: /var/log/fwsnort.log [+] Iptables script: /etc/fwsnort/
The chapter goes on to give several specific attack examples, and how fwsnort can be used to detect them. Here is an example Bleeding Edge Snort rule for detecting the Dumador Trojan (which affects Windows systems and contains both a keylogger and a backdoor): alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BLEEDING-EDGE \
TROJAN Dumador Reporting User Activity"; flow:established,to_server; \
uricontent:".php?p="; nocase; uricontent:"?machineid="; nocase; \
uricontent:"&connection="; nocase; uricontent:"&iplan="; nocase; \
classtype:trojan-activity; reference:url, \
Virus_descriptions/24279/; sid:2002763; rev:2;)
By using the fwsnort --snort-sid command line argument, fwsnort will build an iptables command that detects a specific Snort rule ID, so we use this to restrict fwsnort's translation process to just the Dumador signature: [iptablesfw]# fwsnort --snort-sid 2002763
[+] Parsing Snort rules files...
[+] Found sid: 2002763 in bleeding-all.rules
Successful translation.
The result is a rather complicated iptables command that uses the string match extension multiple times to express the uricontent fields in the Snort rule. Also, the reference information and the Snort msg field are stored within the iptables rule with the comment match. Finally, the FWSNORT_FORWARD_ESTAB iptables chain is used to only perform the inspection over established TCP connections (the jump rule into this chain uses the state match): $IPTABLES -A FWSNORT_FORWARD_ESTAB -s -p tcp --dport 80 -m \
string --string ".php?p=" --algo bm -m string --string "?machineid=" --algo \
bm -m string --string "&connection=" --algo bm -m string --string "&iplan=" \
--algo bm -m comment --comment "sid:2002763; msg: BLEEDING-EDGE TROJAN \
Dumador Reporting User Activity; classtype: trojan-activity; reference: \
url,; rev: 2; FWS:1.0;" -j LOG \
--log-ip-options --log-tcp-options --log-prefix "[1] SID2002763 ESTAB "

Book Review of Linux Firewalls: Attack Detection and Response

Linux Firewalls Book Review Mirko Zorz of has written a postive review of my book Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort. Here are a couple of excerpts from his review:

Rash illustrates why you should run fwsnort, a tool that translates Snort rules into equivalent iptables rules and guides you through a deployment with a myriad of other details. The practical aspect of the book continues and you see how fwsnort operates with specific real-world attacks. After all this material, the chapter that ties together a significant part of the book shows you how to combine fwsnort together with psad.

A firewall can generate a vast amount of data and visualizing iptables logs is a necessity for many. The author explains how to use Gnuplot and AfterGlow with psad in order to get a graphical depiction of iptables log data. You learn how to interpret data based on several examples.

If you want to master Linux firewalls get this title, it is outstanding.

Thanks for the kind words, Mirko. O'Reilly also made a press release about the book as well, and soon after the hit counts in Google went from about 600 to over 49,000 in the span of a week (I run a set of queries against Google every day and watch for trends in the results).