cipherdyne.org

28 July, 2011

The 1.6 release of fwsnort is available for download. This is a fairly significant release that adds support for the Snort fast_pattern keyword, makes enhancements to the --QUEUE and --NFQUEUE modes, supports the conntrack module for connection tracking, adds support for case-insensitive pattern matches using the --icase argument to the iptables string match extension, and several other things. The Snort fast_pattern keyword allows the rule author to influence the order in which Snort tries to match a pattern against network traffic. When multiple patterns are included in a rule, Snort usually tries to match the longest pattern first reasoning that the longest pattern is probably the least likely to trigger a match and therefore the remaining pattern searches would not have to be performed. But, there are times when the rule author would like to explicitly ask Snort to match on a particular pattern first, and the fast_pattern keyword is the mechanism that makes this possible. Because iptables matches are evaluated in order and a failing match short circuits a rule, fast_pattern support with the string match extension is possible through proper ordering in the iptables rule. Here is an example Snort rule from Emerging Threats with the fast_pattern keyword applied to the forth pattern: alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET WEB_CLIENT Possible Internet Explorer srcElement Memory Corruption Attempt"; flow:established,to_client; file_data; content:"document.createEventObject"; distance:0; nocase; content:".innerHTML"; within:100; nocase; content:"window.setInterval"; distance:0; nocase; content:"srcElement"; fast_pattern; nocase; distance:0; classtype:attempted-user; reference:url,www.microsoft.com/technet/security/bulletin/ms10-002.mspx; reference:url,tools.cisco.com/security/center/viewAlert.x?alertId=19726; reference:url,www.kb.cert.org/vuls/id/492515; reference:cve,2010-0249; reference:url,doc.emergingthreats.net/2010799; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_MSIE; sid:2010799; rev:5;) fwsnort translates this rule as follows in iptables-save format from the /etc/fwsnort/fwsnort.save file - the original iptables commands in non-save format are also available in the /etc/fwsnort/fwsnort_iptcmd.sh script: -A FWSNORT_FORWARD_ESTAB -p tcp -m tcp --sport 80 -m string --string "srcElement" --algo bm --from 82 --icase -m string --string "document.createEventObject" --algo bm --from 64 --icase -m string --string ".innerHTML" --algo bm --to 190 --icase -m string --string "window.setInterval" --algo bm --from 74 --icase -m comment --comment "sid:2010799; msg:ET WEB_CLIENT Possible Internet Explorer srcElement Memory Corruption Attempt; classtype:attempted-user; reference:url,www.microsoft.com/technet/security/bulletin/ms10-002.mspx; rev:5; FWS:1.6;" -j LOG --log-ip-options --log-tcp-options --log-prefix "SID2010799 ESTAB " Note that the srcElement string is matched first in the iptables rule even though it is the last string in the original Snort rule. With fast_pattern support, fwsnort policies should be a bit faster at run time in the in the Linux kernel. On a final note, the iptables multiport match is also supported with the fwsnort-1.6 release, so Snort rules with lists of source or destination ports (like this: "alert tcp $HOME_NET [0:20,22:24,26:138,140:444,446:464,466:586,588:901,903:1432,1434:65535] -> any any") can be translated.

The complete fwsnort-1.6 ChangeLog can be found here via the fwsnort gitweb interface.

09 January, 2011

The 1.5 release of fwsnort is available for download. This is a major release that moves to using the iptables-save format for instantiating the fwsnort policy, and this allows the run time for adding the fwsnort policy to the kernel to be drastically reduced. fwsnort now splices in the translated Snort rules into the iptables policy in the running kernel at the time of translation. So, any updates to the iptables policy that are made after fwsnort is executed and before fwsnort.sh is run would be lost. Hence, it is advisable to execute fwsnort.sh soon after running fwsnort. This is a reasonable tradeoff though considering the performance benefit as seen below - which gives an example of how long it takes to add an fwsnort iptables policy via the old strategy of executing one iptables command at a time vs. implementing the same policy with iptables-restore. First, fwsnort is used to translate the Snort web-misc.rules, web-cgi.rules, backdoor.rules files like so: [root@minastirith /etc/fwsnort]# fwsnort --snort-rfile web-misc.rules,web-cgi.rules,backdoor.rules --no-ipt-sync

[+] Generated iptables rules for 713 out of 754 signatures: 94.56%

[+] Logfile: /var/log/fwsnort/fwsnort.log
[+] iptables script (individual commands): /etc/fwsnort/fwsnort_iptcmds.sh

Main fwsnort iptables-save file: /etc/fwsnort/fwsnort.save

You can instantiate the fwsnort policy with the following command:

/sbin/iptables-restore < /etc/fwsnort/fwsnort.save

Or just execute: /etc/fwsnort/fwsnort.sh
The output above illustrates the changes for the fwsnort-1.5 release. All of the previous behavior in fwsnort has been preserved in the /etc/fwsnort/fwsnort_iptcmds.sh script. That is, each individual iptables command to add every fwsnort rule one by one is implemented in this script - this is analogous to how the fwsnort.sh script was built by older versions of fwsnort. But, with the 1.5 release the fwsnort.sh script now just executes the iptables-restore command against the new fwsnort.save file.

If we execute the fwsnort_iptcmds.sh script and time its execution, we get the following on my desktop system: [root@minastirith /etc/fwsnort]# time /etc/fwsnort/fwsnort_iptcmds.sh
[+] Adding backdoor rules:
Rules added: 122
[+] Adding web-cgi rules:
Rules added: 696
[+] Adding web-misc rules:
Rules added: 600
[+] Finished.

real 0m24.391s
user 0m1.560s
sys 0m11.500s
[root@minastirith /etc/fwsnort]# iptables -v -nL |wc -l
1509 So, the fwsnort policy together with the running iptables policy is about 1500 rules long, and it took over 24 seconds to add to the running kernel. Now, let's time the fwsnort.sh script instead (which is just a wrapper around the iptables-restore command): [root@minastirith /etc/fwsnort]# time /etc/fwsnort/fwsnort.sh

[+] Splicing fwsnort rules into the iptables policy...
Done.


real 0m0.121s
user 0m0.060s
sys 0m0.040s
[root@minastirith /etc/fwsnort]# iptables -v -nL |wc -l
1509 Ok, over 24 seconds to instantiate the fwsnort policy for the old strategy, and about a 10th of a second for the new strategy for a speed up of 240 times! This gets even better for an fwsnort policy with thousands of rules. Note that the number of iptables rules is the same between the two executions.

The complete ChangeLog entries are displayed below:

• Major update to use the iptables-save format instead of the older strategy of always just executing iptables commands directly (which was very flow for large fwsnort policies). The /etc/fwsnort/fwsnort.sh script now just executes:
  
  /sbin/iptables-restore < /etc/fwsnort/fwsnort.save
  
  All fwsnort rules are now placed in the /etc/fwsnort/fwsnort.save file, but the older fwsnort.sh output (for the individual commands version) is still available at /etc/fwsnort/fwsnort_iptcmds.sh. This functionality extends to ip6tables policies as well. The fwsnort man page explain this in better detail:
  
  "As of fwsnort-1.5 all iptables rules built by fwsnort are written out to the /etc/fwsnort/fwsnort.save file in iptables-save format. This allows a long fwsnort policy (which may contain thousands of iptables rules translated from a large Snort signature set) to be quickly instantiated via the "iptables-restore" command. A wrapper script /etc/fwsnort/fwsnort.sh is also written out to make this easy. Hence, the typical work flow for fwsnort is to: 1) run fwsnort, 2) note the Snort rules that fwsnort was able to successfully translate (the number of such rules is printed to stdout), and then 3) execute the /etc/fwsnort/fwsnort.sh wrapper script to instantiate the policy in the running kernel."
• Added the --rules-url argument so that the URL for updating the Emerging Threats rule set can be specified from the command line. The default is:
  
  http://rules.emergingthreats.net/open/snort-2.9.0/emerging-all.rules
• Updated to automatically check for the maximum length string that the string match supports, and this is used to through out any Snort rules with content matches longer than this length.
• Updated the iptables capabilities testing routines to add and delete testing rules to/from the custom chain 'FWS_CAP_TEST'. This maintains a a cleaner separation between fwsnort and any existing iptables policy even during the capabilities testing phase.
• Added the --ipt-check-capabilities argument to have fwsnort test the capabilities of the local iptables firewall and exit.
• Added the --string-match-alg argument to allow the string matching algorithm used by fwsnort to be specified from the command line. The default algorithm is 'bm' for 'Boyer-Moore', but 'kmp' may also be specified (short for the 'Knuth-Morris-Pratt' algorithm).
• Updated to the latest complete rule set from Emerging Threats (see http://www.emergingthreats.net/).

14 July, 2010

The 2.1.7 release of psad is available for download. This release adds some relatively minor functionality to switch whois lookups to the destination IP whenever the source IP is part of a directly connected subnet. This change gives better reporting data in normal psad email alerts. The complete ChangeLog entries are displayed below. The psad-2.1.6 release was also made a few days ago, and fixes a bug that caused psad to die on some Ubuntu systems when using the Date::Calc Decode_Month() function, and it also added the --Override-config feature so that alternate configuration variables can be specified via config files besides psad.conf (implemented by Franck Joncourt).

• (Dan A. Dickey) Added the ability to use the "ip" command from the iproute2 tools to acquire IP addresses from local interfaces. Dan's description is as follows: "...A main reason for doing this is in the case of multi-homed hosts. ifconfig sets these up on an interface using aliases, iproute2 does not. So, for a multi-homed interface (eth0 with multiple addresses), ifconfig -a only shows the first one configured and not the rest. ip addr shows all of the configured addresses...".
• Added ENABLE_WHOIS_FORCE_ASCII to replace any non-ascii characters in whois data (which is common with whois lookups against Chinese IP addresses for example) with the string "NA". This option is disabled by default, but can be useful if errors like the following are seen upon receiving an email alert from psad:
  
  <<< 554 5.6.1 Eight bit data not allowed
  554 5.0.0 Service unavailable
  
  
• Updated psad to issue whois lookups against IP addresses that are not directly connected to the local system. This is useful for example when an internal system is scanning an external destination system, and the scan is logged in the FORWARD chain. Issuing whois lookups on the internal system (frequently on RFC 1918 address space) is not usually very useful, but issuing the whois lookup against the destination system gives much more interesting data. This feature can be disabled with the new ENABLE_WHOIS_FORCE_SRC_IP variable.

07 Jan, 2010

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.

08 Sep, 2009

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.

05 Sep, 2009

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

29 July, 2009

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)

30 May, 2009

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

11 May, 2009

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.

19 February, 2009

The IPTables::ChainMgr module is now used by the PacketFence NAC system in the latest 1.8.0 release. The module is used to build iptables rules that match on source MAC addresses, set a connection mark, and jump packets into a dedicated MARK chain.

The latest release of the IPTables::ChainMgr module is 0.9 (available as of Feb 11th), and can be downloaded from CPAN. The changes since the 0.8 release are:

• Added Net::IPv4Addr prerequisite to Makefile.PL (patch submitted by Dominik Gehl).
• Updated perldoc documentation to properly discuss the delete_chain() API. The material about the $jump_from_chain was missing (Darien Kindlund reported this issue).
• Applied patch from Darien Kindlund to add the ability to specify the source MAC address via the --mac-source <addr> command line argument to iptables.