++/etc/shorewall/rules: + +#ACTION SOURCE DEST PROTO DEST PORT(S) +SMB(ACCEPT) loc fw + +The above is equivalent to coding the following series of + rules: + +#TARGET SOURCE DEST PROTO DEST PORT(s) +ACCEPT loc fw udp 135,445 +ACCEPT loc fw udp 137:139 +ACCEPT loc fw udp 1024: 137 +ACCEPT loc fw tcp 135,139,445 +
October 22, 2007
+November 23, 2007
2007-11-23 Shorewall 4.0.6
+Problems corrected in Shorewall-perl 4.0.6.
+
+1) In a DNAT or REDIRECT rule, if no serverport was given and the DEST
+ PORT(S) list contained a service name containing a hyphen ("-") then
+ an ERROR was generated.
+
+ Example -- Rules file:
+
+ DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125
+
+ Results in:
+
+ ERROR: Invalid port range (ms:wbt:server) : rules (line 49)
+
+ Problem was introduced in Shorewall 4.0.5 and does not occur in
+ earlier releases.
+
+2) If a long destination port list needed to be broken at a port pair,
+ the generated rule contained an extra comma which resulted in an
+ iptables-restore failure.
+
+3) Several problems involving port ranges and port lists in REDIRECT
+ rules have been corrected.
+
+4) Shorewall-perl no longer requires an address in the GATEWAY column
+ of /etc/shorewall/tunnels. If the column is left empty (or contains
+ '-') then 0.0.0.0/0 is assumed.
+
+5) Previously with Shorewall-perl, redirecting both STDOUT and STDERR
+ to the same file descriptor resulted in scrambled output between
+ the two. The error messages were often in the middle of the
+ regular output far ahead of the point where the error occurred.
+
+ This problem was possible in the Debian Shorewall init script
+ (/etc/init.d/shorewall) which redirects output to the
+ Debian-specific /var/log/shorewall-init.log file in this way:
+
+ $SRWL $SRWL_OPTS start >> $INITLOG 2>&1 && ...
+
+6) With both compilers, when HIGH_ROUTE_MARKS=Yes, unpredictable
+ results could occur when marking in the PREROUTING or OUTPUT
+ chains. When a rule specified a mark value > 255, the compilers
+ were using the '--or-mark' operator rather than the '--set-mark'
+ operator. Consequently, when a packet matched more than one
+ rule, the resulting routing mark was the logical product of the
+ mark values in the matching rules rather than the mark value from
+ the last matching rule.
+
+ Example:
+
+ 0x100 192.168.1.44 0.0.0.0/0
+ 0x200 0.0.0.0/0 0.0.0.0/0 tcp 25
+
+ A TCP packet from 192.168.1.44 with destination port 25 would have
+ a mark value of 0x300 rather than the expected value of 0x200.
+
+7) Previously, a 'start -f' on Shorewall Lite would produce the
+ following distressing output before starting the firewall:
+
+ make: *** No rule to make target `/firewall', needed by
+ `/var/lib/shorewall-lite/restore'. Stop.
+
+ Furthermore, the Makefile for both Shorewall and Shorewall Lite
+ failed to take into account the /etc/shorewall/vardir file.
+
+ This has been corrected. As part of the fix, both /sbin/shorewall
+ and /sbin/shorewall-lite support a "show vardir" command that
+ displays the VARDIR setting.
+
+8) Shorewall-perl was previously ignoring the USER/GROUP column of the
+ tcrules file.
+
+9) Supplying the name of a built-in chain in the 'refresh' command
+ caused entries in the chain to be duplicated. Since this is a
+ feature of iptables-restore with the '-n' option, built-in chains
+ in the 'refresh' list will now be rejected.
+
+Known Problems Remaining.
+
+1) The 'refresh' command doesn't refresh the mangle table. So changes
+ made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may
+ not be reflected in the running ruleset.
+
+Other changes in Shorewall 4.0.6.
+
+1) Shorewall-perl now uses the '--physdev-is-bridged' option when it
+ is available. This option will suppress messages like the following:
+
+ kernel: physdev match: using --physdev-out in the OUTPUT, FORWARD and
+ POSTROUTING chains for non-bridged traffic is not supported
+ anymore.
+
+ This change only affects users who use bport/bport4 zones in a
+ briged configuration and requires that capabilities files be
+ regenerated using Shorewall-common or Shorewall-lite 4.0.6.
+
+2) Shorewall-perl now allows you to embed Shell or Perl scripts in
+ all configuration files except /etc/shorewall/params and
+ /etc/shorewall/shorewall.conf (As always, you can continue to
+ include arbitrary shell code in /etc/shorewall/params).
+
+ To embed a one-line script, use one of the following:
+
+ SHELL <shell script>
+ PERL <perl script>
+
+ For multi-line scripts, use:
+
+ BEGIN SHELL
+ <shell script>
+ END SHELL
+
+ BEGIN PERL
+ <perl script>
+ END PERL
+
+ For SHELL scripts, the output from the script is processed as if it
+ were part of the file.
+
+ Example 1 (Shell): To generate SMTP/ACCEPT rules from zones a b c d
+ and e to the firewall:
+
+ Either:
+
+ BEGIN SHELL
+ for z in a b c d e; do
+ echo SMTP/ACCEPT $z fw tcp 25
+ done
+ END SHELL
+
+ or
+
+ SHELL for z in a b c d e; do echo SMTP/ACCEPT $z fw tcp 25; done
+
+ Either is equivalent to:
+
+ SMTP/ACCEPT a fw tcp 25
+ SMTP/ACCEPT b fw tcp 25
+ SMTP/ACCEPT c fw tcp 25
+ SMTP/ACCEPT d fw tcp 25
+ SMTP/ACCEPT e fw tcp 25
+
+ With a Perl script, if you want to output text to be processed as
+ if it were part of the file, then pass the text to the shorewall()
+ function.
+
+ Example 2 (Perl): To generate SMTP/ACCEPT rules from zones a b c d
+ and e to the firewall:
+
+ BEGIN PERL
+ for ( qw/a b c d e/ ) {
+ shorewall "SMTP/ACCEPT $_ fw tcp 25";
+ }
+ END PERL
+
+ PERL scripts have access to any context accumulated in earlier PERL
+ scripts. All such embedded Perl, as well as conventional Perl
+ extension scripts are placed in the Shorewall::User package. That
+ way, your global variables and functions won't conflict with any of
+ Shorewall's.
+
+ To allow you to load Perl modules and initialize any global state,
+ a new 'compile' compile-time extension script has been added. It is
+ called early in the compilation process.
+
+ For additional information, see
+
+ - http://www.shorewall.net/configuration_file_basics.html#Embedded
+
+3) To complement Embedded Perl scripts, Shorewall 4.0.6 allows Perl
+ scripts to create filter chains using
+ Shorewall::Chains::new_manual_chain() and then use the chain as a
+ target in subsequent entries in /etc/shorewall/rules.
+
+ See http://www.shorewall.net/ManualChains.html for information.
+
+4) The 'hits' command now accepts a -t option which limits the report
+ to those log records generated today.
+
+5) A DONT_LOAD option has been added to shorewall.conf. If there are
+ kernel modules that you don't wish to have loaded, you can list
+ them in this entry as a comma-separated list.
+
+ Example:
+
+ DONT_LOAD=nf_conntrack_sip,nf_nat_sip
+
+6) Shorewall-perl now supports the --random option of the iptables
+ SNAT, MASQUERADE, DNAT and REDIRECT targets. Please note that
+ iptables support for this option is currently broken for the DNAT
+ and REDIRECT targets; I've sent a patch to the Netfilter team.
+
+ For MASQUERADE, simply place the word 'random' in the ADDRESS
+ column. This causes Netfilter to randomize the source port seen by
+ the remote host.
+
+ Example:
+
+ #INTERFACE SOURCE ADDRESS
+ eth0 eth1 random
+
+ For SNAT, follow the port list by ":random".
+
+ Example:
+
+ #INTERFACE SOURCE ADDRESS
+ eth0 eth1 206.124.146.179:10000-10999:random
+
+ For DNAT, follow the port list by ":random".
+
+ Example:
+
+ #ACTION SOURCE DEST PROTO DEST
+ # PORT(S)
+ DNAT net loc:192.168.1.4:40-50:random tcp 22
+
+ For REDIRECT, you must use the fully-qualified form of the DEST:
+
+ #ACTION SOURCE DEST PROTO DEST
+ # PORT(S)
+ REDIRECT net $FW::40-50:random tcp 22
+
+ Note that ':random' is only effective with SNAT, DNAT and REDIRECT
+ when a port range is specified in the ADDRESS/DEST column. It is
+ ignored by iptables/iptables-restore otherwise.
+
+2007-10-22 Shorewall 4.0.5
Problems corrected in Shorewall 4.0.5.