fwsnort-1.6.2 (04/28/2012): - Switched --no-ipt-sync to default to not syncing with the iptables policy. By default fwsnort attempts to match translated Snort rules to the running iptables policy, but this is tough to do well because iptables policies can be complex. And, before fwsnort switched to the iptables-save format for instantiating the policy, a large set of translated rules could take a really long time to make active within the kernel. Finally, many Snort rules restrict themselves to established TCP connections anyway, and if a restrictive policy doesn't allow connections to get into the established state for some port let's say, then there is little harm in having translated Snort rules for this port. Some kernel memory would be wasted (small), but no performance would be lost since packets won't be processed against these rules anyway. The end result is that the default behavior is now to not sync with the local iptables policy in favor of translating and instantiating as many rules as possible. - Replaced Net::IPv4Addr with the excellent NetAddr::IP module which has comprehensive support for IPv6 address network parsing and comparisons. - Moved the fwsnort.sh script and associated files into the /var/lib/fwsnort/ directory. This was suggested by Peter Vrabec. - Bug fix for recent versions of iptables (such as 1.4.12) where the icmp match requires --icmp-type to be set - some Snort rules look for a string to match in icmp traffic, but don't also specify an icmp type. - Bug fix for 'qw(...) usage as parenthesis' warnings for perl > 5.14 - Removed the ExtUtils::MakeMaker RPM build requirement from the fwsnort.spec file. This is a compromise which will allow the fwsnort RPM to be built even if RPM dosen't or can't see that ExtUtils::MakeMaker is installed - most likely it will build anyway. If it doesn't, there are bigger problems since fwsnort is written in perl. If you want to build the fwsnort RPM with a .spec file that requires ExtUtils::MakeMaker, then use the "fwsnort-require-makemaker.spec" file that is bundled in the fwsnort sources. fwsnort-1.6.1 (11/01/2011): - (Kim Hagen) submitted a patch for a bug in fwsnort-1.6 where the fwsnort policy in iptables-save format could not be loaded whenever iptables-save put the nat table output after the filter table output. In this case, fwsnort would fail with an error like the following: Couldn't load target `FWSNORT_FORWARD_ESTAB':/lib/xtables/libipt_FWSNORT_FORWARD_ESTAB.so: cannot open shared object file: No such file or directory fwsnort now invokes 'iptables-save -t filter' in order to ensure that ordering issues do not affect how fwsnort builds its translated rule set. - Bug fix to ensure that fwsnort does not attempt to re-order pattern matches for patterns that have a relative match requirement. For non- relative matches fwsnort re-orders pattern matches based on the pattern length, reasoning that the longest pattern should be processed first for better performance. The usage of the fast_pattern keyword give the user explicit control over this. Here is a Snort rule that is now properly handled by fwsnort (references removed): alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET WEB_CLIENT Possible Adobe Reader and Acrobat Forms Data Format Remote Security Bypass Attempt"; flow:established,to_client; file_data; content:"%FDF-"; depth:300; content:"/F(JavaScript|3a|"; nocase; distance:0; classtype:attempted-user; sid:2010664; rev:8;) Before this change, fwsnort translated this rule as: $IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp -m tcp --sport 80 -m string --hex-string "/F(JavaScript|3a|" --algo bm --from 69 --icase -m string --hex-string "%FDF|2d|" --algo bm --to 364 -m comment --comment "sid:2010664; msg:ET WEB_CLIENT Possible Adobe Reader and Acrobat Forms Data Format Remote Security Bypass Attempt; classtype:attempted-user; rev:8; FWS:1.6;" -j LOG --log-ip-options --log-tcp-options --log-prefix "SID2010664 ESTAB " Note that in the above rule, the "/F(JavaScript|3a|" pattern was switched to be evaluated first even though it is a relative match to the previous pattern in the original Snort rule. After this change, fwsnort translates this rule as: $IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp -m tcp --sport 80 -m string --hex-string "%FDF|2d|" --algo bm --to 364 -m string --hex-string "/F(JavaScript|3a|" --algo bm --from 69 --icase -m comment --comment "sid:2010664; msg:ET WEB_CLIENT Possible Adobe Reader and Acrobat Forms Data Format Remote Security Bypass Attempt; classtype:attempted-user; rev:8; FWS:1.6;" -j LOG --log-ip-options --log-tcp-options --log-prefix "SID2010664 ESTAB " - Updated to the latest Emerging Threats rule set. fwsnort-1.6 (07/28/2011): - Fixed the --ipt-apply functionality - the variable that held the fwsnort.sh path was not initialized properly prior to this change. - Added the --Conntrack-state argument to specify a conntrack state in place of the "established" state that commonly accompanies the Snort "flow" keyword. By default, fwsnort uses the conntrack state of "ESTABLISHED" for this. In certain corner cases, it might be useful to use "ESTABLISHED,RELATED" instead to apply application layer inspection to things like ICMP port unreachable messages that are responses to real attempted communications. (Need to add UDP tracking for the _ESTAB chains for this too - coming soon.) - Recent releases of iptables and the Linux kernel support matching on connection state via the conntrack modules and the --ctstate switch. Added a capabilities test for this, and will fall back to using the state match if the conntrack module is not available. - Bugfix to ensure the iptables log prefixes built by fwsnort are not longer than those allowed by the running iptables firewall. This is usually a total of 29 characters, but fwsnort now dynamically figures out this value. - Bugfix for --ipt-list and --ipt-flush to ensure that the proper iptables binary path is chosen. These args failed without this because the iptables binary was not set. fwsnort-1.5 (01/08/2011): - 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/). fwsnort-1.1 (01/05/2010): - 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. fwsnort-1.0.6 (05/30/2009): - (Franck Joncourt) Updated fwsnort to use the "!