forked from extern/shorewall_code
8b75a2d996
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@9442 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
245 lines
169 KiB
HTML
245 lines
169 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|
<meta name="revised"
|
|
content="$Id$">
|
|
<title>Shorewall News</title>
|
|
</head>
|
|
<body>
|
|
<h1 style="text-align: left;">Shorewall News and Announcements<br>
|
|
</h1>
|
|
<p><span style="font-weight: bold;">
|
|
</span>Copyright © 2001-2009 Thomas M. Eastep</p>
|
|
<p>Permission is granted to copy, distribute and/or modify this
|
|
document
|
|
under the terms of the GNU Free Documentation License, Version 1.2 or
|
|
any
|
|
later version published by the Free Software Foundation; with no
|
|
Invariant
|
|
Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of
|
|
the
|
|
license is included in the section entitled <span
|
|
style="text-decoration: underline;">"</span><span class="quote"><a
|
|
href="GnuCopyright.htm" target="_self">GNU Free Documentation
|
|
License</a></span>".
|
|
</p>
|
|
<p>February 15, 2009<br>
|
|
</p>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<p><strong>2009-02-15 Shorewall 4.2.6</strong></p>
|
|
<pre>Problems corrected in 4.2.6<br><br>1) The CONFIG_PATH in the two- and three-interface Shorewall6 sample<br> configurations was incorrect with the result that this error<br> occurred on 'shorewall6 check' or 'shorewall6 start'.<br><br> ERROR: No IP zones defined<br><br>2) Setting TCP_FLAGS_DISPOSITION=REJECT caused both Shorewall-shell<br> and Shorewall-perl to create invalid iptables commands. This has<br> been corrected but we still strongly recommend against that<br> setting; TCP_FLAGS_DISPOSITION=DROP is preferred.<br><br>3) Shorewall-perl was generating code that checked for state match<br> before kernel modules were loaded. This caused start/restart to<br> fail on systems without kernel module loading. <br><br>4) The Shorewall6 and Shorewall6-lite Makefiles were incorrect.<br><br>5) If a service name is used in a port-mapping rule (a DNAT or<br> REDIRECT rule that changes the destination port), and if the<br> kernel and iptables include Extended Connection Match support, then<br> invalid iptables-restore input is produced by Shorewall-perl.<br><br>6) If iptables 1.4.1 or later was installed, Shorewall-perl generated<br> incorrect iptables-restore input if exclusion was used in the<br> ORIGINAL DEST field of a DNAT or REDIRECT rule.<br><br>7) On kernels earlier than 2.6.20, the 'shorewall show connections'<br> command fails.<br><br>New Feature in Shorewall 4.2.6<br><br>1) A BitTorrent32 macro has been added. This macro matches the<br> extended TCP port range used by BitTorrent 3.2 and later.<br><br>2) A new COUNT action has been added to Shorewall-perl. This action<br> creates an iptables (ip6tables) rule with no target. Connections<br> matching such a rule are simply counted and the packet is passed on<br> to the next rule.<br><br> Shorewall-shell ignores COUNT in actions and macros, thus allowing<br> the standard actions (action.Drop and action.Reject) to have a<br> COUNT rule as their first entry.<br><br>3) A new RESTORE_DEFAULT_ROUTE option has been added to<br> shorewall.conf. It is used to determine whether to restore the<br> default route saved when there are 'balance' providers defined but<br> all of them are down.<br><br> The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the<br> pre-4.2.6 behavior. <br><br> RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a<br> default route in the main table (USE_DEFAULT_RT=No) or in the<br> default table (USE_DEFAULT_RT=Yes) when there are no balance<br> providers available. In that case, RESTORE_DEFAULT_ROUTE=No<br> will cause any default route in the relevant table to be deleted.<br><br>4) IPv4 firewall scripts produced by Shorewall-perl now use dhcpcd's<br> database when trying to detect the gateway for an interface<br> ("detect" in the GATEAWAY column in /etc/shorewall/interfaces).<br><br> As part of this change, it is now permitted to specify 'detect'<br> when USE_DEFAULT_RT=Yes; in that case, the script will only detect<br> gateways for point-to-point devices and for devices configured by<br> dhcpcd.<br><br>5) Shorewall-perl now supports port inversion. A port number or list<br> of port numbers may be preceded by '!" which will cause the rule to<br> match all ports EXCEPT those listed:<br><br> Example: To blacklist 206.124.146.176 for all tcp ports except 80:<br><br> ADDRESS/SUBNET PROTO PORT(S)<br> 206.124.146.177 tcp !80<br><br>6) Shorewall-perl now supports protocol inversion. A protocol name or<br> number may be preceded by '!' to specify all protocols except the<br> one following '!'.<br><br> Example: To blacklist 206.124.146.176 for all protocols except <br> UDP:<br><br> ADDRESS/SUBNET PROTO PORT(S)<br> 206.124.146.177 !udp<br><br> Note that ports may not be specified when protocol inversion<br> is used.<br><br>7) When using Shorewall-perl, neither the 'start' nor 'started'<br> extension script is run during processing of the 'restore'<br> command. To allow extension of that command, we have added a<br> 'restored' extension script that runs at the successful completion<br> of 'restore'. This script is only available with Shorewall-perl.<br><br> With Shorewall-shell, both scripts are run during 'restore' but in<br> that case, the run_iptables() function does nothing. So any<br> run_iptables() calls in the 'start' script are effectively ignored.<br><br>8) Shorewall-perl now correctly handles 'here documents' quoting<br> (<<EOF .... EOF) in run-time extension scripts.<br><strong></strong></pre>
|
|
<p><strong></strong><strong>2009-01-22 Shorewall 4.2.5</strong><br>
|
|
</p>
|
|
<p><strong></strong></p>
|
|
<pre>Problems corrected in 4.2.5<br><br>1) If exclusion is used to define a zone in /etc/shorewall/hosts and<br> that zone is used as the SOURCE zone in a DNAT or REDIRECT rule,<br> then Shorewall-perl can generate invalid iptables-restore input.<br><br>2) A bug in the Perl Cwd module (see<br> <a
|
|
class="moz-txt-link-freetext"
|
|
href="http://rt.cpan.org/Public/Bug/Display.html?id=13851">http://rt.cpan.org/Public/Bug/Display.html?id=13851</a>) causes the<br> Shorewall-perl compiler to fail if it doesn't have at least read<br> access to its current working directory. 4.2.5 contains a<br> workaround.<br><br>3) If 'critical' was specified on an entry in<br> /etc/shorewall6/routestopped, Shorewall6 (Shorewall-perl) would<br> generate an error.<br><br>4) In certain cases where exclusion occurred in /etc/shorewall/hosts,<br> Shorewall-perl would generate incorrect iptables-restore input.<br><br>5) In certain cases where exclusion occurred in /etc/shorewall/hosts,<br> Shorewall-perl would generate invalid iptables-restore input.<br><br>6) The 'shorewall6 refresh' command runs iptables_restore rather than<br> ip6tables_restore.<br><br>7) The commands 'shorewall6 save-start', 'shorewall6-save-restart' and<br> 'shorewall6 restore' were previously broken.<br><br>8) The Debian init script was checking $startup in<br> /etc/default/shorewall rather than in /etc/default/shorweall6<br><br>9) The Archlinux init scripts for Shorewall6 and Shorewall6 Lite were<br> unconverted Shorewall scripts.<br><br>10) When 'detect' is used in the GATEWAY column of<br> /etc/shorewall/providers, Shorewall-perl now ensures that the<br> gateway was successfully detected. If the gateway cannot be<br> detected, action is taken depending on whether the provider is<br> 'optional' or not. If the provider is optional, it's configuration<br> is skipped; if the provider is not optional, the current operation<br> is aborted.<br><br>11) The command 'shorewall6 debug start' would previously fail with<br> ERROR: Command "/sbin/ip6tables -t nat -F" Failed<br><br>12) Both ipv4 and ipv6 compiled programs attempt to run the tcclear<br> script itself at run time rather than running the copy of the<br> file in the compiled script. This usually isn't noticable unless<br> you are running Shorewall Lite or Shorewall6 Lite in which case,<br> the script doesn't get run (since it is on the administrative<br> system and not the firewall system).<br><br>13) If your iptables/kernel included "Extended Connection Tracking<br> Match support" (see the output of "shorewall show capabilities"),<br> then a REDIRECT rule that specified a port list or range would<br> cause Shorewall-perl to create invalid iptables-restore input:<br><br> Running /usr/sbin/iptables-restore...<br> iptables-restore v1.4.2-rc1: conntrack: Bad value for<br> "--ctorigdstport" option: "1025:65535"<br> Error occurred at line: 191<br> Try `iptables-restore -h' or 'iptables-restore --help' for more information.<br> ERROR: iptables-restore Failed. Input is in <i
|
|
class="moz-txt-slash"><span class="moz-txt-tag">/</span>var/lib/shorewall<span
|
|
class="moz-txt-tag">/</span></i>.iptables-restore-input<br><br>Known Problems Remaiining:<br><br>1) When exclusion is used in an entry in /etc/shorewall/hosts, then<br> Shorewall-shell produces an invalid iptables rule if any of the<br> following OPTIONS are also specified in the entry:<br><br> blacklist<br> maclist<br> norfc1918<br> tcpflags<br><br>New Feature in Shorewall 4.2.5<br><br>1) A new 'fallback' option is added in<br> /etc/shorewall/providers. The option works similar to 'balance'<br> except that the default route is added in the default routing table<br> (253) rather than in the main table (254).<br><br> The option can be used by itself or followed by =<number> (e.g,<br> fallback=2).<br><br> When the option is used by itself, a separate (not balanced)<br> default route is added with a metric equal to the provider's NUMBER.<br><br> When the option is used with a number, a balanced route is added<br> with the weight set to the specified number.<br><br> 'fallback' is ignored if USE_DEFAULT_RT=Yes in shorewall.conf and<br> is only available with Shorewall-perl.<br><br> 'fallback' is useful in situations where:<br><br> - You want all traffic to be sent via one primary provider unless<br> there is a compelling reason to use a different provider<br><br> - If the primary provider is down, then you want to balance the<br> outgoing traffic among a set of other providers or to a<br> ordered list of providers.<br><br> In this case:<br><br> - Do not specify 'balance' on any of the providers.<br> - Disable route filtering ('ROUTE_FILTER=No' in shorewall.conf).<br> - Specify 'fallback' on those providers that you want to use if<br> the primary is down.<br> - Only the primary provider should have a default route in the main<br> routing table.<br><br> See <a
|
|
class="moz-txt-link-freetext"
|
|
href="http://www.shorewall.net/MultiISP.html#Complete">http://www.shorewall.net/MultiISP.html#Complete</a> for an example<br> of this option's use.<br><br>2) Shorewall-perl now transparently handles the xtables-addon version<br> of ipp2p. Shorewall detects whether the installed ipp2p is from<br> patch-o-matic-ng or from xtables-addon and proceeds accordingly.<br><br> If the patch-o-matic-ng version is installed:<br><br> a) If no DEST PORT is supplied, the default is "--ipp2p".<br> b) If "ipp2p" is supplied as the DEST PORT, it will be passed to<br> iptables-restore as "--ipp2p".<br><br> If the xtables-addons version is installed:<br><br> a) If no DEST PORT is supplied, the default is "--edk --gnu --dc<br> --kazaa".<br> b) If "ipp2p" is supplied as the DEST PORT, it will be passed to<br> iptables-restore as "--edk --gnu --dc --kazaa".<br><br> Shorewall-perl now also accepts a comma-separated list of options<br> (e.g., "edk,gnu,dc,kazaa).<br><br> Additionally, Shorewall now looks for modules in <i
|
|
class="moz-txt-slash"><span class="moz-txt-tag">/</span>lib/modules<span
|
|
class="moz-txt-tag">/</span></i>$(uname<br> -r)<i
|
|
class="moz-txt-slash"><span class="moz-txt-tag">/</span>extra and in /lib/modules<span
|
|
class="moz-txt-tag">/</span></i>$(uname -r)/extra/ipset<br><br> This change introduced a new capability ("Old IPP2P Match Syntax")<br> so if you use a capabilities file, be sure to re-generate the<br> file(s) after you have installed 4.2.5.<br><br>3) There is now a macro.Git, which opens git-daemon's port (9418/tcp).<br><br>4) There is also a macro.IRC which open's the Internet Relay Chat port<br> (6667/tcp).</pre>
|
|
<p><strong>2009-01-06 Winner of the Shorewall Logo Design Competition
|
|
Announced</strong></p>
|
|
The Shorewall developers are pleased to announce that after deliberating<br>
|
|
upon the matter, we have chosen Gareth Davies' #3 design.<br>
|
|
<p>See<a target="_top"
|
|
href="http://trac.shorewall.net/wiki/LogoDesignCompetition">
|
|
http://trac.shorewall.net/wiki/LogoDesignCompetition</a> for details.<br>
|
|
<strong></strong></p>
|
|
<p><strong>2008-12-31 Shorewall 4.2.4</strong></p>
|
|
<p><strong></strong></p>
|
|
<pre>1) In 4.2.4, two new packages are included:<br><br> a) Shorewall6 - analagous to Shorewall-common but handles IPv6<br> rather than IPv4.<br><br> b) Shorewall6-lite - analagous to Shorewall-lite but handles IPv6<br> rather than IPv4.<br><br> The packages store their configurations in /etc/shorewall6/ and<br> /etc/shorewall6-lite/ respectively. <br><br> The fact that the packages are separate from their IPv4 counterparts<br> means that you control IPv4 and IPv6 traffic separately (the same<br> way that Netfilter does). Starting/Stopping the firewall for one<br> address family has no effect on the other address family.<br><br> For additional information, see<br> http://www.shorewall.net/IPV6Support.html.<br><br> Other features of Shorewall6 are:<br><br> a) There is no NAT of any kind (most people see this as a giant step<br> forward). When an ISP assigns you a public IPv6 address, you are<br> actually assigned an IPv6 'prefix' which is like an IPv4<br> subnet. A 64-bit prefix allows 4 billion squared individual hosts<br> (the size of the current IPv4 address space squared).<br><br> b) The default zone type is ipv6.<br><br> c) The currently-supported interface options in Shorewall6 are:<br><br> blacklist<br> bridge<br> dhcp<br> nosmurfs (traps multicast and Subnet-router anycast addresses<br> used as the packet source address).<br> optional<br> routeback<br> sourceroute<br> tcpflags<br> mss<br> forward (setting it to 0 makes the router behave like a host<br> on that interface rather than like a router).<br><br> d) The currently-supported host options in Shorewall6 are:<br><br> blacklist<br> routeback<br> tcpflags<br><br> e) Traffic Shaping is disabled by default. The tcdevices and<br> tcclasses files are address-family independent so<br> to use the Shorewall builtin Traffic Shaper, TC_ENABLED=Internal<br> should be specified in Shorewall or in Shorewall6 but not in<br> both. In the configuration where the internal traffic shaper is<br> not enabled, CLEAR_TC=No should be specified.<br><br> tcfilters are not available in Shorewall6.<br><br> f) When both an interface and an address or address list need to<br> be specified in a rule, the address or list must be enclosed in<br> angle brackets. Example:<br><br> #ACTION SOURCE DEST<br> ACCEPT net:eth0:<2001:19f0:feee::dead:beef:cafe> dmz<br><br> Note that this includes MAC addresses as well as IPv6 addresses.<br><br> The HOSTS column in /etc/shorewall6/hosts also uses this<br> convention:<br><br> #ZONE HOSTS OPTIONS<br> chat6 eth0:<2001:19f0:feee::dead:beef:cafe><br><br> Even when an interface is not specified, it is permitted to<br> enclose addresses in <> to improve readability. Example:<br><br> #ACTION SOURCE DEST<br> ACCEPT net:<2001:1::1> $FW<br><br> g) The options available in shorewall6.conf are a subset of those<br> available in shorewall.conf.<br><br> h) The Socket6.pm Perl module is required if you include DNS names<br> in your Shorewall6 configuration. Note that it is loaded the<br> first time that a DNS name is encountered so if it is missing,<br> you get a message similar to this one:<br><br> ...<br> Checking /etc/shorewall6/rules...<br> Can't locate Socket6.pm in @INC (@INC contains: /root ...<br> teastep@ursa:~/Configs/standalone6$ <br></pre>
|
|
<p><strong>2008-12-16 Shorewall 4.2.3</strong></p>
|
|
<p><strong></strong></p>
|
|
<pre>Problems corrected in Shorewall 4.2.3<br><br>1) Previously, Shorewall would allow compilation for export of a<br> script named 'shorewall' with the unfortunate side effect that<br> the 'shorewall.conf' file was overwritten. Scripts named<br> 'shorewall' now cause a fatal error to be raised.<br><br>2) Previously, Shorewall-perl attempted to do Shell variable<br> substitution on the first line in /etc/shorewall/compile.<br><br>3) Following the Netfilter tradition, the IPP2P maintainer has made an<br> incompatible syntax change (the --ipp2p option has been<br> removed). Shorewall has always used "-m ipp2p --ipp2p" when<br> detecting the presence of IPP2P support.<br><br> Shorewall-common and Shorewall-perl have been modified to use<br> "-m ipp2p --edk" instead.<br><br>4) When Extended Conntrack Match support was available, Shorewall-perl<br> would create invalid iptables-restore input for certain DNAT rules.<br><br>5) An optimization in all Shorewall-perl 4.2 versions could cause<br> undesirable side effects. The optimization deleted the<br> <interface>_in and <interface>_fwd chains and moved their rules<br> to the appropriate rules chain (a <zone>2<xxx> chain).<br><br> This worked badly in cases where a zone was associated with more<br> than one interface. Rules could be duplicated or, worse, a rule<br> that was intended for only input from one of the interfaces would<br> be applied to input from all of the zone's interfaces.<br><br> This problem has been corrected so that an interface-related<br> chains is only deleted if:<br><br> a) the chain has no rules in it; or<br> b) the interface is associated with only one zone and that zone is<br> associated with only that interface in which case it is safe to<br> move the rules.<br><br>Other changes in Shorewall 4.2.3<br><br>1) Except with the -e option is specified, the Shorewall-perl compiler<br> now verifies user/group names appearing in the USER/GROUP column of<br> the rules file.<br><br>2) The output of 'shorewall dump' now includes the output from<br> 'netstat -tunap'.<br><br>3) Shorewall-perl now accepts '+' as an interface name in<br> /etc/shorewall/interfaces. That name matches any interface and is<br> useful for defining a zone that will match any interface that might<br> be added after Shorewall is started.<br><br> A couple of words of caution are in order.<br><br> a) Because '+' matches any interface name, Shorewall cannot<br> verify interface names appearing in other files when '+' is<br> defined in /etc/shorewall/interfaces.<br><br> b) The zone assigned to '+' must be the last one defined in<br> /etc/shorewall/zones.<br><br>4) Shorewall-perl now uses the iptables --goto parameter in obvious<br> cases.<br><br>5) The 'reset' command now allows you to reset the packet and byte<br> counter on individual chains:<br><br> shorewall reset chain1 chain2 ...<br> shorewall-lite reset chain1 chain2 ...<br></pre>
|
|
<p><strong>2008-11-20 Shorewall 4.2.2</strong></p>
|
|
<p><strong></strong></p>
|
|
Problems corrected in Shorewall 4.2.2
|
|
<pre><br>1) Shorewall-perl now insures that each line copied from a<br> configuration file or user exit is terminated with a newline<br> character.<br><br>2) When ipranges were used to define zones, Shorewall-perl could<br> generate invalid iptables-restore input if 'Repeat Match' was not<br> available. Repeat Match is not a true match -- it rather is a<br> feature of recent iptables releases that allows a match to be<br> repeated within a rule.<br><br>3) With Shorewall-perl, if a destination port list had exactly 16<br> ports, where a port-range counts as two ports, then Shorewall-perl<br> would fail to split the rule into multiple rules and an<br> iptables-restore error would result.<br><br>4) The change to Shorewall-perl in 4.2.1 that promised iptables 1.4.1<br> compatibility contained a typo that prevented it from working<br> correctly.<br><br>5) If a no-NAT rule (DNAT-, ACCEPT+, NONAT) included a destination IP<br> address and no zone name in the DEST column, Shorewall-perl would<br> reject the rule. If a zone name was specified, Shorewall-perl <br> would issue a Warning message.<br><br>6) Previously, if Extended conntrack match support was available, a<br> DNAT rule that specified a server port but no destination port <br> would generate invalid iptables-restore input. <br><br>Other changes in Shorewall 4.2.2<br><br>1) A macro supporting JAP (anonymization protocol) has been added.<br> It can be used as any other macro (e.g., JAP/ACCEPT) in the rules<br> file.<br><br>2) A macro supporting DAAP (Digital Audio Access Protocol) has been added.<br> It can be used as any other macro (e.g., DAAP/ACCEPT) in the rules<br> file.<br><br>3) A macro supporting DCC (Distributed Checksum Clearinghouse) has been<br> added. It can be used as any other macro (e.g., DCCP/ACCEPT) in the<br> rules file.<br><br>4) A macro supporting GNUnet (secure peer-to-peer networking) has been<br> added. It can be used as any other macro (e.g., GNUnet/ACCEPT) in the<br> rules file.<br><br>5) In 4.2.1, a single capability ("Extended conntrack match support")<br> was used both to control the use of --ctorigport and to trigger use<br> of the new syntax for inversion of --ctorigdst (e.g., "!<br> --ctorigdst ..."). In 4.2.2, these are controlled by two separate<br> capabilities. If you use a capabilities file when compiling your<br> configuration, be sure to generate a new one after installing<br> 4.2.2.<br></pre>
|
|
<p><strong>2008-10-25 Shorewall 4.2.1<br>
|
|
</strong><strong></strong></p>
|
|
<pre>Problems corrected in Shorewall 4.2.1<br><br>1) A description of the CONNBYTES column has been added to<br> shorewall-tcrules(5).<br><br>2) Previously, Shorewall-perl would accept zero as the <max> value in<br> the CONNBYTES column of tcrules even when the <min> field was<br> non-zero. A value of zero for <max> was equivalent to omitting<br> <max>.<br><br>3) iptables 1.4.1 discontinued support of syntax generated by<br> shorewall in some cases. Shorewall now detects when the new syntax<br> is required and uses it instead.<br><br>4) The Shorewall-perl implementation of the LENGTH column in<br> /etc/shorewall/tcrules was incomplete with the result that <br> all LENGTH rules matched. Thanks to Lennart Sorensen for the patch.<br><br>5) The 'export' command no longer fails with the error:<br><br> /sbin/shorewall: 1413: Syntax error: "(" unexpected (expecting "fi")<br><br>Other changes in Shorewall 4.2.1<br><br>1) With the recent renewed interest in DOS attacks, it seems<br> appropriate to have connection limiting support in Shorewall. To<br> that end, a CONNLIMIT column has been added to both the policy and<br> rules files.<br><br> The content of these columns is of the format<br><br> [!] <limit>[:<mask>]<br><br> where<br><br> <limit> is the limit on simultaneous TCP connections.<br><br> <mask> specifies the size of the network to which<br> the limit applies and is specified as a<br> CIDR mask length. The default value for<br> <mask> is 32 which means that each remote<br> IP address can have <limit> TCP connections<br> active at once.<br><br> ! Not allowed in the policy file. In the rules file, it<br> causes connections to match when the number of<br> current connections exceeds <limit>.<br> <br> When specified in the policy file, the limit is enforced on all<br> connections that are subject to the given policy (just like<br> LIMIT:BURST). The limit is checked on new connections before the<br> connection is passed through the rules in the NEW section of the<br> rules file.<br><br> It is important to note that while the limit is only checked for<br> those destinations specified in the DEST column, the number of<br> current connections is calculated over all destinations and not<br> just the destination specified in the DEST column.<br><br> Use of this feature requires the connlimit match capability in your<br> kernel and iptables. If you use a capabilities file when compiling<br> your Shorewall configuration(s), then you need to regenerate the<br> file using Shorewall or Shorewall-lite 4.2.1.<br><br>2) Shorewall now supports time/date restrictions on entries in the <br> rules file via a new TIME column.<br><br> The contents of this column is a series of one or more "time<br> elements" separated by apersands ("&"). Possible time elements are:<br><br> utc Times are expressed in Greenwich Mean Time.<br> localtz Times are expressed in local civil time (default)<br> timestart=hh:mm[:ss]<br> timestop=hh:mm[:ss] Start and stop time of day for rule<br> weekdays=ddd[,ddd]... where ddd is Mon,Tue,Wed,Thu,Fri,Sat or<br> Sun<br> monthdays=dd[,dd]... where dd is an ordinal day of the month.<br> datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]<br> datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]<br> where yyyy = Year<br> first mm = Month<br> dd = Day<br> hh = Hour<br> 2nd mm = Minute<br> ss = Second<br><br> Examples:<br><br> 1) utc&timestart=10:00&timestop=12:00<br><br> Between 10am and 12 noon each day, GMT<br><br> 2) datestart=2008-11-01T12:00<br><br> Beginning November 1, 2008 at noon LCT.<br><br> Use of this feature requires the time match capability in your<br> kernel and iptables. If you use a capabilities file when compiling<br> your Shorewall configuration(s), then you need to regenerate the<br> file using Shorewall or Shorewall-lite 4.2.1.<br></pre>
|
|
<p><strong>2006-10-05 Shorewall 4.2.0</strong></p>
|
|
<pre><strong><span style="font-weight: normal;">Release Highlights.</span><br
|
|
style="font-weight: normal;"><br style="font-weight: normal;"><span
|
|
style="font-weight: normal;">1) Support is included for multiple internet providers through the same</span><br
|
|
style="font-weight: normal;"><span style="font-weight: normal;"> ethernet interface.</span><br
|
|
style="font-weight: normal;"><br style="font-weight: normal;"><span
|
|
style="font-weight: normal;">2) Support for NFLOG has been added.</span><br
|
|
style="font-weight: normal;"><br style="font-weight: normal;"><span
|
|
style="font-weight: normal;">3) Enhanced operational logging.</span><br
|
|
style="font-weight: normal;"><br style="font-weight: normal;"><span
|
|
style="font-weight: normal;">4) The tarball installers now work under Cygwin.</span><br
|
|
style="font-weight: normal;"><br style="font-weight: normal;"><span
|
|
style="font-weight: normal;">5) Shorewall-perl now supports IFB devices which allow traffic shaping of</span><br
|
|
style="font-weight: normal;"><span style="font-weight: normal;"> incoming traffic.</span><br
|
|
style="font-weight: normal;"><br style="font-weight: normal;"><span
|
|
style="font-weight: normal;">6) Shorewall-perl supports definition of u32 traffic classification</span><br
|
|
style="font-weight: normal;"><span style="font-weight: normal;"> filters.</span><br></strong></pre>
|
|
<p><strong></strong></p>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<p><strong>2008-03-29 Shorewall 4.0.10</strong></p>
|
|
<p><strong></strong></p>
|
|
<pre>Problems corrected in Shorewall-perl 4.0.10.<br><br>1) Shorewall-perl 4.0.9 erroneously reported an error message when a<br> bridge port was defined in /etc/shorewall/interfaces:<br><br> ERROR: Your iptables is not recent enough to support bridge ports<br><br>2) Under Shorewall-perl, if an empty action was invoked or was named<br> in one of the DEFAULT_xxx options in shorewall.conf, an<br> iptables-restore error occured.<br><br>3) If $ADMIN was empty, then the rule:<br><br> ACCEPT loc:$ADMIN all<br><br> became<br><br> ACCEPT loc net<br><br> It is now flagged as an error.<br><br>4) Previously, Shorewall-perl would reject an IP address range in the<br> ecn and routestopped files.<br><br>5) A POLICY of ":" in /etc/shorewall/policy would produce Perl<br> run-time errors.<br><br>6) An INTERFACE of ":" in /etc/shorewall/interfaces would produce Perl<br> run-time errors.<br><br>7) A MARK of ":" in /etc/shorewall/tcrules would produce Perl<br> run-time errors.<br><br>Problems corrected in Shorewall-shell 4.0.10.<br><br>1) Specifying a value for ACCEPT_DEFAULT or QUEUE_DEFAULT resulted in<br> a fatal error at compile time.<br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in 4.0.10.<br><br>1) The Sample configurations have been updated to set<br> LOG_MARTIANS=keep. In 4.2, this will be changed to<br> LOG_MARTIANS=Yes.<br><br>2) Shorewall-perl now generates a fatal error if a non-existant shell<br> variable is used in any configuration file (except<br> /etc/shorewall/params).<br><br>3) Shorewall-perl now supports an 'l2tp' tunnel type. It opens UDP<br> port 1701 in both directions and assumes that the source port will<br> also be 1701. Some implementations (particularly OS X) use a<br> different source port. In that case, you should use<br> 'generic:udp:1701' rather than 'l2tp'.<br></pre>
|
|
<p><strong>2008-03-01 Shorewall 3.4.8</strong></p>
|
|
<pre>1) Shorewall now removes any default bindings of ipsets before<br> attempting to reload them. Previously, default bindins were not<br> removed with the result that the ipsets could not be destroyed.<br><br><br>2) When HIGH_ROUTE_MARKS=Yes, unpredictable results could occur when<br> marking in the PREROUTING or OUTPUT chains. When a rule specified a<br> mark value > 255, the compiler was using the '--or-mark' operator<br> rather than the '--set-mark' operator with the result that when a<br> packet matched more than one rule, the resulting routing mark was<br> the logical product of the mark values in the rules.<br><br><br> Example:<br><br><br> 0x100 192.168.1.44 0.0.0.0/0<br> 0x200 0.0.0.0/0 0.0.0.0/0 tcp 25<br><br><br> A TCP packet from 192.168.1.44 with destination port 25 would end<br> up with a mark value of 0x300.<br><br><br>3) Shorewall now properly parses comma separated SOURCE (formerly<br> SUBNET) values in the masq configuration file. Previously, the comma<br> separated list was not split up into its components, resulting in an<br> invalid address being passed to the iptables command.<br><br><br> Example:<br><br><br> # /etc/shorewall/masq<br> #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC<br> eth0 192.168.2.1,192.168.2.3<br><br><br>4) Previously, specifying both an interface and a MAC address in the<br> SOURCE column of the tcrules file caused a failure at runtime.<br> Thanks to Justin Joseph for the patch.<br><br><br>5) Previously, specifying both an interface and an address in the<br> tcrules DEST column would cause an incomplete rule to be generated.<br><br><br> Example:<br><br><br> 1 192.168.1.4 eth2:206.124.146.177 tcp 22<br><br><br> The resulting tcrule would be as if this had been specified:<br><br><br> 1 0.0.0.0/0 eth2:206.124.146.177 tcp 22<br><br><br>6) When HIGH_ROUTE_MARKS=Yes, the routing rules generated to match<br> fwmarks to routing tables overflowed the designated range for such<br> marks (10000 - 11000).</pre>
|
|
<hr>
|
|
<p><strong>2008-02-23 Shorewall 4.0.9</strong></p>
|
|
<p><strong></strong></p>
|
|
<pre>Problems corrected in Shorewall-perl 4.0.9.1<br><br>1) In 4.0.9, Shorewall-perl incorrectly generated the following error<br> message:<br><br> ERROR: Your iptables is not recent enough to support bridge ports<br><br>Problems corrected in Shorewall-perl 4.0.9<br><br>1) If a zone was defined with exclusion in /etc/shorewall/hosts, then<br> the rules generated for directing outgoing connections to the zone<br> were incorrect.<br><br> Example:<br><br> /etc/shorewall/zones:<br><br> z ipv4<br><br> /etc/shorewall/interfaces:<br><br> - eth2 <br><br> /etc/shorewall/hosts:<br><br> z eth2:192.168.1.0/24!192.168.1.5<br><br> Traffic from the firewall to 192.168.1.5 was incorrectly classified<br> as $FW->z.<br><br>2) Qualifying 'SOURCE' and 'DEST' with an IP address in a macro file<br> caused 'SOURCE' or 'DEST' to be interpreted incorrectly as the name<br> of an interface.<br><br> Example:<br><br> PARAM DEST SOURCE:224.0.0.22<br><br>3) Specifying '!<user>' in the USER/GROUP column of the files that<br> support it resulted in an invalid iptables rule under<br> Shorewall-perl.<br><br>4) Previously, Shorewall would accept both an interface and an IP<br> address in tcrules POSTROUTING entries (such as CLASSIFY).<br><br> Example:<br><br> 1:11 eth1:192.168.4.9 - tcp 22<br><br> It also allowed both a destination interface and address.<br><br> Example:<br><br> 1:P - eth1:192.168.4.9 tcp 22<br><br> Because Netfilter does not allow an input interface to be specified<br> in POSTROUTING or an output interface to be specified in<br> PREROUTING, Shorewall must use the routing table to generate a list<br> of networks accessed through any interface specified in these<br> cases. Given that a specific address (or set of addresses) has<br> already been specified, it makes no sense qualify it (them) by<br> another list of addresses.<br><br>5) Shorewall-perl incorrectly generated a fatal error when ':C', <br> ':T' or ':CT' was used in a tcrules entry that gave $FW as the<br> SOURCE.<br><br>6) Users have been confused about this error message:<br><br> ERROR: Bridge Ports require Repeat match in your kernel and iptables <br><br> The message has been replaced with:<br><br> ERROR: Your iptables is not recent enough to support bridge ports<br><br> The minimum version required is 1.3.8.<br><br>Problems corrected in Shorewall-shell 4.0.9.<br><br>1) An optimization added to Shorewall-shell in 4.0.0 has been backed<br> out to work around a limitation of Busybox 'sed'.<br><br>2) Previously, specifying both an interface and an address in the<br> tcrules DEST column would cause an incomplete rule to be generated.<br><br> Example:<br><br> 1 192.168.1.4 eth2:206.124.146.177 tcp 22<br><br> The resulting tcrule would be as if this had been specified:<br><br> 1 0.0.0.0/0 eth2:206.124.146.177 tcp 22<br><br>3) When HIGH_ROUTE_MARKS=Yes, the routing rules generated to match<br> fwmarks to routing tables previously overflowed the designated<br> range defined for such marks (10000 - 11000). <br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in 4.0.9.<br><br>1) The Shorewall-perl now flags unprintable garbage characters in<br> configuration files with the message:<br><br> ERROR: Non-ASCII gunk in file <br><br>2) The /usr/share/shorewall/modules file has been updated to reflect<br> module renaming in kernel 2.6.25.<br><br>3) The 'ip route replace' command is broken in kernel 2.6.24. To work<br> around this problem, the undocumented option BROKEN_ROUTING has<br> been added to shorewall.conf. The default is BROKEN_ROUTING=No.<br><br> If you are experiencing 'File Exists' errors from 'ip route<br> replace' commands, then add the following line to your<br> shorewall.conf:<br><br> BROKEN_ROUTING=Yes<br><br> Note: This workaround is only available in Shorewall-perl.<br></pre>
|
|
<p><strong>2008-01-25 Shorewall 4.0.8</strong></p>
|
|
<p><strong></strong></p>
|
|
<pre>Problems corrected in Shorewall-perl 4.0.8.<br><br>1) Mark tests (such as in the TEST column of tcrules or the MARK<br> column of the rules file) were ignoring the value 0. As part of<br> this fix, the default mask generated by entries in these columns<br> has been changed from 0xFF to 0xFFFF for compatibility with<br> Shorewall-shell.<br><br>2) The compilation date recorded in the firewall.conf file produced by<br> Shorewall-perl was previously mangled.<br><br>3) The ability to specify a DEST IP range (round-robin) in a DNAT rule<br> has been restored. In versions 4.0.5 - 4.0.7, an IP range was<br> incorrectly flagged as an error.<br><br>Problems corrected in Shorewall-shell 4.0.8.<br><br>1) Shorewall-shell now properly parses comma separated SOURCE (formerly<br> SUBNET) values in the masq configuration file. Previously, the comma<br> separated list was not split up into its components, resulting in an<br> invalid address being passed to the iptables command.<br><br> Example:<br><br> # /etc/shorewall/masq<br> #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC<br> eth0 192.168.2.1,192.168.2.3<br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in 4.0.8.<br><br>None.<br></pre>
|
|
<hr style="width: 100%; height: 2px;"><strong>2007-12-26 Shorewall 4.0.7</strong>
|
|
<pre>Problems corrected in Shorewall-perl 4.0.7</pre>
|
|
<pre>1) If any of the following files was missing, a harmless Perl warning<br> was issued:</pre>
|
|
<pre> accounting<br> maclist<br> masq<br> nat<br> netmap<br> rfc1918<br> routestopped<br> tunnels</pre>
|
|
<pre> This problem was experienced mostly by Debian users and users of<br> Debian derivatives such as Ubuntu.</pre>
|
|
<pre>2) The iptables utility doesn't retry operations that fail due to<br> resource shortage. Beginning with this release, Shorewall reruns<br> iptables when such a failure occurs.</pre>
|
|
<pre>3) Previously, Shorewall-perl did not accept log levels in upper case<br> (e.g., INFO). Beginning with 4.0.7, log levels are treated in a<br> case-insensitive manner by Shorewall-perl.</pre>
|
|
<pre>4) The column headers in macro files were not aligned. This has been<br> corrected, along with some inaccuracies in the macro.template file.</pre>
|
|
<pre>5) The shorewall.conf files in the Samples did not contain some<br> recently-defined options. They are now up to date.</pre>
|
|
<pre>6) The names of the Jabber macros were shuffled. They are now named<br> correctly.</pre>
|
|
<pre>7) If ADD_IP_ALIASES=Yes, an alias was incorrectly added when the<br> specified INTERFACE ended with ":" (e.g., eth0:).</pre>
|
|
<pre>8) Shorewall-shell generated an incorrect iptables rule from the<br> following:</pre>
|
|
<pre> /etc/shorewall/rules:</pre>
|
|
<pre> ACCEPT loc:eth0:~00-02-02-02-02-02 ...</pre>
|
|
<pre> /etc/shorewall/tcrules:</pre>
|
|
<pre> xxxx eth0:~00-02-02-02-02-02 ...</pre>
|
|
<pre>Known Problems Remaining.</pre>
|
|
<pre>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.</pre>
|
|
<pre>Other changes in 4.0.7</pre>
|
|
<pre>1) If the program named in SHOREWALL_SHELL doesn't exist or is not<br> executable, Shorewall and Shorewall-lite now both fall back to<br> /bin/sh after issuing a warning message. Previously, both<br> terminated with a fatal error.</pre>
|
|
<pre>2) The error message has been improved when a non-root user attempts<br> "shorewall show capabilities".</pre>
|
|
<pre>3) Shorewall-perl now generates fatal error conditions when there are<br> no IPv4 zones defined and when there are no interfaces defined.<hr></pre>
|
|
<p><strong>2007-12-26 Shorewall 4.1.3</strong></p>
|
|
<pre>Problems corrected in Shorewall 4.1.3.</pre>
|
|
<pre>1) If NFLOG or ULOG was specified with parameters, the resulting<br> iptables-restore input contained elements that were incorrectly<br> up-cased.</pre>
|
|
<pre>2) If STARTUP_LOG is specified without LOG_VERBOSITY, /sbin/shorewall<br> produces an error.</pre>
|
|
<pre>3) If LOG_VERBOSITY is specified without STARTUP_LOG, run-time error<br> messages are produced.</pre>
|
|
<pre>4) Shorewall-shell was mishandling the entries in /etc/shorewall/rules<br> and in /etc/shorewall/tcrules where both a SOURCE interface and MAC<br> address were specified.</pre>
|
|
<pre> Example:</pre>
|
|
<pre> ACCEPT net:eth0:~01-02-03-04-05-06 $FW tcp 22</pre>
|
|
<pre>Other changes in Shorewall 4.1.3.</pre>
|
|
<pre>1) If the program named in SHOREWALL_SHELL doesn't exist or is not<br> executable, Shorewall and Shorewall-lite now both fall back to<br> /bin/sh after issuing a warning message. Previously, both<br> terminated with a fatal error.</pre>
|
|
<pre>2) The error message has been improved when a non-root user attempts<br> "shorewall show capabilities".</pre>
|
|
<pre>3) Shorewall-perl now generates fatal error conditions when there are<br> no IPv4 zones defined and when there are no interfaces defined.</pre>
|
|
<pre>4) Shorewall now unconditionally uses tc filter rules to classify<br> traffic by MARK value. Previously, Shorewall used the CLASSIFY<br> target in the POSTROUTING chain if it was available.</pre>
|
|
<pre>5) The Shorewall-common installer (install.sh) now works on Windows<br> under Cygwin.</pre>
|
|
<pre> To install Shorewall-perl under Cygwin:</pre>
|
|
<pre> $ tar -xf shorewall-perl-4.1.3.tar.bz2<br> $ tar -xf shorewall-common-4.1.3.tar.bz2<br> $ cd shorewall-perl-4.1.3<br> $ ./install.sh<br> $ cd ../shorewall-common-4.1.3<br> $ USER=<your user id> GROUP=None ./install.sh<br> <br> The 'shorewall' program is installed in /bin/ (a.k.a, /usr/bin/).<hr></pre>
|
|
<p><strong>2007-11-23 Shorewall 4.0.6</strong></p>
|
|
<pre>Problems corrected in Shorewall-perl 4.0.6.<br><br>1) In a DNAT or REDIRECT rule, if no serverport was given and the DEST<br> PORT(S) list contained a service name containing a hyphen ("-") then<br> an ERROR was generated.<br><br> Example -- Rules file:<br><br> DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125<br><br> Results in:<br><br> ERROR: Invalid port range (ms:wbt:server) : rules (line 49)<br><br> Problem was introduced in Shorewall 4.0.5 and does not occur in<br> earlier releases.<br><br>2) If a long destination port list needed to be broken at a port pair,<br> the generated rule contained an extra comma which resulted in an<br> iptables-restore failure.<br><br>3) Several problems involving port ranges and port lists in REDIRECT<br> rules have been corrected.<br><br>4) Shorewall-perl no longer requires an address in the GATEWAY column<br> of /etc/shorewall/tunnels. If the column is left empty (or contains<br> '-') then 0.0.0.0/0 is assumed.<br><br>5) Previously with Shorewall-perl, redirecting both STDOUT and STDERR<br> to the same file descriptor resulted in scrambled output between<br> the two. The error messages were often in the middle of the<br> regular output far ahead of the point where the error occurred.<br><br> This problem was possible in the Debian Shorewall init script<br> (/etc/init.d/shorewall) which redirects output to the<br> Debian-specific /var/log/shorewall-init.log file in this way:<br><br> $SRWL $SRWL_OPTS start >> $INITLOG 2>&1 && ...<br><br>6) With both compilers, when HIGH_ROUTE_MARKS=Yes, unpredictable<br> results could occur when marking in the PREROUTING or OUTPUT<br> chains. When a rule specified a mark value > 255, the compilers<br> were using the '--or-mark' operator rather than the '--set-mark'<br> operator. Consequently, when a packet matched more than one<br> rule, the resulting routing mark was the logical product of the<br> mark values in the matching rules rather than the mark value from<br> the last matching rule.<br><br> Example:<br><br> 0x100 192.168.1.44 0.0.0.0/0<br> 0x200 0.0.0.0/0 0.0.0.0/0 tcp 25<br><br> A TCP packet from 192.168.1.44 with destination port 25 would have<br> a mark value of 0x300 rather than the expected value of 0x200.<br><br>7) Previously, a 'start -f' on Shorewall Lite would produce the<br> following distressing output before starting the firewall:<br><br> make: *** No rule to make target `/firewall', needed by<br> `/var/lib/shorewall-lite/restore'. Stop.<br><br> Furthermore, the Makefile for both Shorewall and Shorewall Lite<br> failed to take into account the /etc/shorewall/vardir file.<br><br> This has been corrected. As part of the fix, both /sbin/shorewall<br> and /sbin/shorewall-lite support a "show vardir" command that<br> displays the VARDIR setting.<br><br>8) Shorewall-perl was previously ignoring the USER/GROUP column of the<br> tcrules file.<br><br>9) Supplying the name of a built-in chain in the 'refresh' command<br> caused entries in the chain to be duplicated. Since this is a<br> feature of iptables-restore with the '-n' option, built-in chains<br> in the 'refresh' list will now be rejected.<br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in Shorewall 4.0.6.<br><br>1) Shorewall-perl now uses the '--physdev-is-bridged' option when it<br> is available. This option will suppress messages like the following:<br><br> kernel: physdev match: using --physdev-out in the OUTPUT, FORWARD and<br> POSTROUTING chains for non-bridged traffic is not supported<br> anymore.<br><br> This change only affects users who use bport/bport4 zones in a<br> briged configuration and requires that capabilities files be<br> regenerated using Shorewall-common or Shorewall-lite 4.0.6.<br><br>2) Shorewall-perl now allows you to embed Shell or Perl scripts in<br> all configuration files except /etc/shorewall/params and<br> /etc/shorewall/shorewall.conf (As always, you can continue to<br> include arbitrary shell code in /etc/shorewall/params).<br><br> To embed a one-line script, use one of the following:<br><br> SHELL <shell script><br> PERL <perl script><br><br> For multi-line scripts, use:<br><br> BEGIN SHELL<br> <shell script><br> END SHELL<br><br> BEGIN PERL<br> <perl script><br> END PERL<br><br> For SHELL scripts, the output from the script is processed as if it<br> were part of the file.<br><br> Example 1 (Shell): To generate SMTP/ACCEPT rules from zones a b c d<br> and e to the firewall:<br><br> Either:<br><br> BEGIN SHELL <br> for z in a b c d e; do<br> echo SMTP/ACCEPT $z fw tcp 25<br> done<br> END SHELL<br><br> or<br><br> SHELL for z in a b c d e; do echo SMTP/ACCEPT $z fw tcp 25; done<br><br> Either is equivalent to:<br><br> SMTP/ACCEPT a fw tcp 25<br> SMTP/ACCEPT b fw tcp 25<br> SMTP/ACCEPT c fw tcp 25<br> SMTP/ACCEPT d fw tcp 25<br> SMTP/ACCEPT e fw tcp 25<br><br> With a Perl script, if you want to output text to be processed as<br> if it were part of the file, then pass the text to the shorewall()<br> function.<br><br> Example 2 (Perl): To generate SMTP/ACCEPT rules from zones a b c d<br> and e to the firewall:<br><br> BEGIN PERL <br> for ( qw/a b c d e/ ) { <br> shorewall "SMTP/ACCEPT $_ fw tcp 25";<br> }<br> END PERL<br><br> PERL scripts have access to any context accumulated in earlier PERL<br> scripts. All such embedded Perl, as well as conventional Perl<br> extension scripts are placed in the Shorewall::User package. That<br> way, your global variables and functions won't conflict with any of<br> Shorewall's.<br><br> To allow you to load Perl modules and initialize any global state,<br> a new 'compile' compile-time extension script has been added. It is<br> called early in the compilation process.<br><br> For additional information, see<br><br> - http://www.shorewall.net/configuration_file_basics.html#Embedded<br><br>3) To complement Embedded Perl scripts, Shorewall 4.0.6 allows Perl<br> scripts to create filter chains using<br> Shorewall::Chains::new_manual_chain() and then use the chain as a<br> target in subsequent entries in /etc/shorewall/rules.<br><br> See http://www.shorewall.net/ManualChains.html for information.<br><br>4) The 'hits' command now accepts a -t option which limits the report<br> to those log records generated today.<br><br>5) A DONT_LOAD option has been added to shorewall.conf. If there are<br> kernel modules that you don't wish to have loaded, you can list<br> them in this entry as a comma-separated list.<br><br> Example:<br><br> DONT_LOAD=nf_conntrack_sip,nf_nat_sip<br><br>6) Shorewall-perl now supports the --random option of the iptables<br> SNAT, MASQUERADE, DNAT and REDIRECT targets. Please note that<br> iptables support for this option is currently broken for the DNAT<br> and REDIRECT targets; I've sent a patch to the Netfilter team.<br><br> For MASQUERADE, simply place the word 'random' in the ADDRESS<br> column. This causes Netfilter to randomize the source port seen by<br> the remote host.<br><br> Example:<br><br> #INTERFACE SOURCE ADDRESS<br> eth0 eth1 random <br><br> For SNAT, follow the port list by ":random".<br><br> Example:<br><br> #INTERFACE SOURCE ADDRESS<br> eth0 eth1 206.124.146.179:10000-10999:random<br><br> For DNAT, follow the port list by ":random".<br><br> Example:<br><br> #ACTION SOURCE DEST PROTO DEST<br> # PORT(S)<br> DNAT net loc:192.168.1.4:40-50:random tcp 22<br><br> For REDIRECT, you must use the fully-qualified form of the DEST:<br><br> #ACTION SOURCE DEST PROTO DEST<br> # PORT(S)<br> REDIRECT net $FW::40-50:random tcp 22<br><br> Note that ':random' is only effective with SNAT, DNAT and REDIRECT<br> when a port range is specified in the ADDRESS/DEST column. It is<br> ignored by iptables/iptables-restore otherwise.<br></pre>
|
|
<hr>
|
|
<p><strong>2007-10-22 Shorewall 4.0.5</strong></p>
|
|
<pre>Problems corrected in Shorewall 4.0.5.<br><br>1) Previously, Shorewall-perl misprocessed $FW::<port> in the DEST<br> column of a REDIRECT rule, generating an error. '$FW::<port>' now<br> produces the same effect as '<port>'.<br><br>2) If the PROTOCOL (PROTO) column contained 'TCP' or 'UDP' and SOURCE<br> PORT(S) or DEST PORT(S) were given, then Shorewall-perl rejected<br> the entry with the error:<br><br> ERROR: SOURCE/DEST PORT(S) not allowed with PROTO TCP : /etc/shorewall/rules <br><br> The rule was accepted if 'tcp' or 'udp' was used instead.<br><br>3) Shorewall-shell now removes any default bindings of ipsets before<br> attempting to reload them. Previously, default bindings were not<br> removed with the result that the ipsets could not be destroyed.<br><br>Other changes in Shorewall 4.0.5.<br><br>1) Two new options have been added to /etc/shorewall/hosts<br> (Shorewall-perl only).<br><br> broadcast: Permits limited broadcast (destination 255.255.255.255)<br> to the zone.<br><br> destonly: Normally used with the Multi-cast range. Specifies that<br> traffic will be sent to the specified net(s) but that <br> no traffic will be received from the net(s).<br><br> Example:<br><br> wifi eth1:192.168.3.0/24 broadcast<br> wifi eth1:224.0.0.0/4 destonly<br><br> In that example, limited broadcasts from the firewall with a source<br> IP in the 192.168.3.0/24 range will be acccepted as will multicasts<br> (with any source address).<br><br>2) A MULTICAST option has been added to shorewall.conf. This option<br> will normally be set to 'No' (the default). It should be set to <br> 'Yes' under the following circumstances:<br><br> a) You have an interface that has parallel zones defined via<br> /etc/shorewall/hosts.<br> b) You want to forward multicast packets to two or more of those<br> parallel zones.<br><br> In such cases, you will configure a 'destonly' network on each <br> zone receiving multicasts.<br><br> The MULTICAST option is only recognized by Shorewall-perl and is<br> ignored by Shorewall-shell.<br><br>3) As announced in the Shorewall 4.0.4 release notes, Shorewall-perl<br> no longer supports the 'detectnets' option. Specifying that option<br> now results in the following message:<br><br> WARNING: Support for the 'detectnets' option has been removed<br><br> It is suggested that 'detectnets' be replaced by<br> 'routefilter,logmartians'. That will produce the same filtering<br> effect as 'detectnets' while eliminating 1-2 rules per connection.<br><br> One user has asked how to retain the output of 'shorewall show<br> zones' if the 'detectnets' option is removed. While I don't advise<br> doing so, you can reproduce the current 'shorewall show' behavior<br> as follows.<br><br> Suppose that you have a zone named 'wifi' that produces the<br> following output with 'detectnets':<br><br> wifi (ipv4)<br> eth1:192.168.3.0/24<br> <br> You can reproduce this behavior as follows:<br><br> /etc/shorewall/interfaces:<br><br> - eth1 detect ...<br><br> /etc/shorewall/hosts:<br><br> wifi eth1:192.168.3.0/24 broadcast<br><br> If you send multicast to the 'wifi' zone, you also need this entry<br> in your hosts file:<br><br> wifi eth1:224.0.0.0/4 destonly<br><br>4) (Shorewall-perl only) The server port in a DNAT or REDIRECT rule<br> may now be specified as a service name from<br> /etc/services. Additionally:<br><br> a) A port-range may be specified as the service port expressed in<br> the format <low port>-<high port>. Connections are assigned to<br> server ports in round-robin fashion.<br><br> b) The compiler only permits a server port to be specified if the<br> protocol is tcp or udp.<br><br> c) The compiler ensures that the server IP address is valid (note<br> that it is still not permitted to specify the server address as a<br> DNS name).<br><br>5) (Shorewall-perl only) Users are complaining that when they migrate<br> to Shorewall-perl, they have to restrict their port lists to 15<br> ports. In this release, we relax that restriction on destination<br> port lists. Since the SOURCE PORT(s) column in the configuration<br> files is rarely used, we have no plans to relax the restriction in<br> that column.<br><br>6) There have been several cases where iptables-restore has failed<br> while executing a COMMIT command in the .iptables_restore_input<br> file. This gives neither the user nor Shorewall support much to go<br> on when analyzing the problem. As a new debugging aid, the meaning<br> of 'trace' and 'debug' have been changed.<br><br> Traditionally, /sbin/shorewall and /sbin/shorewall-lite have<br> allowed either 'trace' or 'debug' as the first run-line<br> parameter. Prior to 4.0.5, the two words produced the same effect.<br><br> Beginning with Shorewall 4.0.5, the two words have different<br> effects when Shorewall-perl is used.<br><br> trace - Like the previous behavior.<br><br> In the Shorewall-perl compiler, generate a stack trace<br> on WARNING and ERROR messages.<br><br> In the generated script, sets the shell's -x option to<br> trace execution of the script.<br><br> debug - Ignored by the Shorewall-perl compiler.<br><br> In the generated script, causes the commands in<br> .iptables_restore_input to be executed as discrete iptables<br> commands. The failing command can thus be identified and a<br> diagnosis of the cause can be made.<br><br> Users of Shorewall-lite will see the following change when using a<br> script that was compiled with Shorewall-perl 4.0.5 or later.<br><br> trace - In the generated script, sets the shell's -x option to<br> trace execution of the script.<br><br> debug - In the generated script, causes the commands in<br> .iptables_restore_input to be executed as discrete iptables<br> commands. The failing command can thus be identified and a<br> diagnosis of the cause can be made.<br><br> In all other cases, 'debug' and 'trace' remain synonymous. In<br> particular, users of Shorewall-shell will see no change in<br> behavior.<br><br> WARNING: The 'debug' feature in Shorewall-perl is strictly for<br> problem analysis. When 'debug' is used:<br><br> a) The firewall is made 'wide open' before the rules are applied.<br> b) The routestopped file is not consulted and the rules are applied<br> in the canonical iptables-restore order (ASCIIbetical by chain).<br> So if you need critical hosts to be always available during<br> start/restart, you may not be able to use 'debug'.<br><br>7) /usr/share/shorewall-perl/buildports.pl,<br> /usr/share/shorewall-perl/FallbackPorts.pm and <br> /usr/share/shorewall-perl/Shorewall/Ports.pm have been removed.<br><br> Shorewall now resolves protocol and port names as using Perl's<br> interface to the the standard C library APIs getprotobyname() and<br> getservbyname().<br><br> Note 1: <br><br> The protocol names 'tcp', 'TCP', 'udp', 'UDP', 'all', 'ALL',<br> 'icmp' and 'ICMP' are still resolved by Shorewall-perl<br> itself.<br><br> Note 2:<br><br> Those of you running Shorewall-perl under Cygwin may wish to<br> install "real" /etc/protocols and /etc/services files<br> in place of the symbolic links installed by Cygwin.<br><br>8) The contents of the Shorewall::*::$VERSION variables are now a<br> only of interest for Perl programs that are using the modules and<br> specifying a minimum version (e.g., "use Shorewall::Config<br> 4.0.5;"). Each module continues to carry a separate version which<br> indicates the release of Shorewall-perl when the module was last<br> modified</pre>
|
|
<hr>
|
|
<p><strong>2007-10-02 Shorewall 3.4.7</strong></p>
|
|
<pre>Problems Corrected in Shorewall 3.4.7<br><br>1) A bug prevented proper handling of PREROUTING marks when<br> HIGH_ROUTE_MARKS=No and the track option was specified in<br> /etc/shorewall/providers.<br><br>2) Previously, if the following sequence of routing rules was<br> specified, then the first rule would always be omitted.<br><br> #SOURCE DEST PROVIDER PRIORITY<br> $SRC_A $DESTIP1 ISP1 1000<br> $SRC_A $DESTIP2 SOMEISP 1000<br> $SRC_A - ISP2 1000<br><br> The reason for this omission was that Shorewall uses a<br> delete-before-add approach and attempting to delete the third rule<br> resulted in the deletion of the first one instead. <br><br> This problem occurred with both compilers.<br><br>3) When using Shorewall-shell, provider numbers were not recognized in<br> the PROVIDER column of /etc/shorewall/route_rules.</pre>
|
|
<hr>
|
|
<p><strong>2007-09-28 Shorewall 4.0.4</strong></p>
|
|
<pre>Problems Corrected in Shorewall 4.0.4<br><br>1) If no interface had the 'blacklist' option, then when using<br> Shorewall-perl, the 'start' and 'restart' command failed:<br><br> ERROR: No filter chain found with name blacklst<br><br> New Shorewall-perl 4.0.3 packages were released that corrected this<br> problem; it is included here for completeness.<br><br>2) If no interface had the 'blacklist' option, then when using<br> Shorewall-perl, the generated script would issue this harmless<br> message during 'shorewall refresh':<br><br> chainlist_reload: Not found<br><br>3) If /bin/sh was a light-weight shell such as ash or dash, then<br> 'shorewall refresh' failed.<br><br>4) During start/restart, the script generated by Shorewall-perl was<br> clearing the proxy_arp flag on all interfaces; that is not the<br> documented behavior.<br><br>5) If the module-init-tools package was not installed and<br> /etc/shorewall/modules did not exist or was non-empty, then<br> Shorewall-perl would fail with the message:<br><br> ERROR: Can't run lsmod : /etc/shorewall/modules (line 0)<br><br>6) Shorewall-perl now makes a compile-time check to insure that<br> iptables-restore exists and is executable. This check is made when<br> the compiler is being run by root and the -e option is not<br> given.<br><br> Note that iptables-restore must reside in the same directory as the<br> iptables executable specified by IPTABLES in shorewall.conf or<br> located by the PATH in the event that IPTABLES is not specified.<br><br>7) When using Shorewall-perl, if an action was invoked with more than<br> 10 different combinations of log-levels/tags, some of those<br> invocations would have incorrect logging.<br><br>8) Previously, when 'shorewall restore' was executed, the<br> iptables-restore utility was always located using the PATH setting<br> rather than the IPTABLES setting.<br><br> With Shorewall-perl, the IPTABLES setting is now used to locate<br> this utility during 'restore' as it is during the processing of<br> other commands.<br><br>9) Although the shorewall.conf manpage indicates that the value<br> 'internal' is allowed for TC_ENABLED, that value was previously<br> rejected ('Internal' was accepted).<br><br>10) The meaning of the 'loose' provider option was accidentally reversed<br> in Shorewall-perl. Rather than causing certain routing rules to be<br> omitted when specified, it actually caused them to be added (these<br> rules were omitted when the option was NOT specified).<br><br>11) If the 'bridge' option was specified on an interface but there were<br> no bport zones, then traffic originating on the firewall was not<br> passed through the accounting chain.<br><br>12) In commands such as:<br><br> shorewall compile <directory><br> shorewall restart <directory><br> shorewall check <directory><br><br> if the name of the <directory> contained a period ("."), then<br> Shorewall-perl would incorrectly substitute the current working<br> directory for the name.<br><br>13) Previously, if the following sequence of routing rules was<br> specified, then the first rule would always be omitted.<br><br> #SOURCE DEST PROVIDER PRIORITY<br> $SRC_A $DESTIP1 ISP1 1000<br> $SRC_A $DESTIP2 SOMEISP 1000<br> $SRC_A - ISP2 1000<br><br> The reason for this omission was that Shorewall uses a<br> delete-before-add approach and attempting to delete the third rule<br> resulted in the deletion of the first one instead. <br><br> This problem occurred with both compilers.<br><br>14) When using Shorewall-shell, provider numbers were not recognized in<br> the PROVIDER column of /etc/shorewall/route_rules.<br><br>15) An off-by-one problem in Shorewall-perl caused the value 255 to be<br> rejected in the MARK column of /etc/shorewall/tcclasses.<br><br>16) When HIGH_ROUTE_MARKS=Yes, marks with values > 255 must be a<br> multiple of 256. That restriction was being enforced by<br> Shorewall-shell but not by Shorewall-perl. Shorewall-perl now also<br> enforces this restriction.<br><br>17) Using REDIRECT with a parameterized macro (e.g., DNS/REDIRECT)<br> failed with an "Unknown interface" error when using Shorewall-perl.<br><br>Other Changes in Shorewall 4.0.4<br><br>1) The detection of 'Repeat Match' has been improved. 'Repeat Match'<br> is not a match at all but rather is a feature of recent versions of<br> iptables that allows a particular match to be used multiple times<br> within a single rule.<br><br> Example:<br><br> -A foo -m physdev --physdev-in eth0 -m physdev --physdev-out ...<br><br> When using Shorewall-shell, the availability of 'Repeat Match' can<br> speed up compilation very slightly.<br><br>2) Apparently recent Fedora releases are broken. The<br> following sequence of commands demonstrates the problem:<br><br> ip rule add from 1.1.1.1 to 10.0.0.0/8 priority 1000 table 5<br> ip rule add from 1.1.1.1 to 0.0.0.0/0 priority 1000 table main<br> ip rule del from 1.1.1.1 to 0.0.0.0/0 priority 1000<br><br> The third command should fail but doesn't; instead, it incorrectly<br> removes the rule added by the first command.<br> To work around this issue, you can set DELETE_THEN_ADD=No in<br> shorewall.conf which prevents Shorewall from deleting ip rules<br> before attempting to add a similar rule.<br><br>3) When using Shorewall-perl, the following message is now issued if<br> the 'detectnets' option is specified in /etc/shorewall/interfaces:<br><br> WARNING: Support for the 'detectnets' option will be removed from<br> Shorewall-perl in version 4.0.5; better to use 'routefilter' and<br> 'logmartians<br><br> The 'detect' options has always been rather silly. On input, it<br> duplicates the function of 'routefilter'. On output, it is a no-op<br> since traffic that doesn't match a route out of an interface won't<br> be sent through that interface (duh!).<br><br> Beginning with Shorewall 4.0.5, the warning message will read:<br><br> WARNING: Support for the 'detectnets' option has been removed</pre>
|
|
<hr>
|
|
<p><strong>2007-09-01 Shorewall 4.0.3</strong></p>
|
|
<pre>Problems Corrected in 4.0.3<br><br>1) Using the LOG target in the rules file could result in two LOG<br> rules being generated by Shorewall-shell. Additionally, using an IP<br> address range in a rule that performed logging could result in an<br> invalid iptables command.<br><br>2) Shorewall now loads the act_police kernel module needed by traffic<br> shaping.<br><br>3) Previously, "shorewall show -f capabilities" and "shorecap" omitted<br> the "TCPMSS Match" capability. This made it appear to a compiler<br> using a capabilities file that the TCPMSS Match capability was not<br> available.<br><br>4) Previously, Shorewall would truncate long log prefixes to 29<br> characters. This resulted in there being no space between the log<br> prefix and the IN= part of the message.<br><br> Example: fw2net:LOG:HTTPSoutIN= OUT=eth0<br><br> Beginning with this release, Shorewall will truncate the prefix to<br> 28 bytes and add a trailing space.<br><br> Example: fw2net:LOG:HTTPSou IN= OUT=eth0<br><br>5) Previously, if:<br><br> - FASTACCEPT=No<br> - The policy from Z1 to Z2 was CONTINUE<br> - Neither Z1 nor Z2 had parent zones<br> - There were no Z1->Z2 rules<br><br> then connections from Z2->Z1 would fail even if there were<br> rules/policies allowing them. This has been<br> corrected.<br><br>6) The 'shorewall add' and 'shorewall delete' command would fail when:<br><br> - The running configuration was compiled with Shorewall-perl.<br> - The name of the interface specified in the command contained an<br> embedded special character such as '.' or '-'.<br><br> This problem was the result of the change in Shorewall 4.0.2 that<br> removed the legacy mapping of interface names when embedding such<br> names in a Netfilter chain name. To correct the problem, the<br> pre-4.0.2 name mapping is restored when DYNAMIC_ZONES=Yes.<br><br>5) A bug in Shorewall-shell prevented proper handling of PREROUTING<br> marks when HIGH_ROUTE_MARKS=No and the track option was specified<br> in /etc/shorewall/providers.<br><br>6) With Shorewall-perl, if EXPORTPARAMS=Yes then INCLUDE directives in<br> the params file would fail at script execution time with "INCLUDE:<br> not found". This has been corrected.<br><br>7) Shorewall-perl was mis-sorting the zone list when zones were nested<br> more than one deep.<br><br>8) Stale references to http://www.shorewall.net/Documentation.htm have<br> been removed from the config files (including samples). That URL<br> has been replaced by the online manpages.<br><br>Other Changes in 4.0.3<br><br>1) A script generated by Shorewall-perl now tries to modify/restore<br> /etc/iproute2/rt_tables only if the file is writable. This prevents<br> run-time errors when /etc is mounted read-only.<br> <br> A new KEEP_RT_TABLES option has been added to shorewall.conf. When<br> set to Yes, this option prevents Shorewall from altering the<br> /etc/iproute2/rt_tables database. The KEEP_RT_TABLES option is only<br> recognized by Shorewall-perl and is ignored by Shorewall-shell.<br><br>2) Shorewall-perl now requires the FindBin Perl module.<br><br>3) When an optional provider is not available, a script generated by<br> Shorewall-perl will no longer add the corresponding<br> routing rules.<br><br>4) A new 'isusable' extension script has been added. This script<br> allows you to extend the availability test that Shorewall performs<br> on optional providers.<br><br> Here's an example that uses ping to ensure that the default<br> gateways through eth0 and eth1 are reachable:<br><br> case $1 in<br> eth0)<br> ping -c 4 -I eth0 206.124.146.254 > /dev/null 2>&1<br> return<br> ;;<br> eth1)<br> ping -c 4 -I eth1 192.168.12.254 > /dev/null 2>&1<br> return<br> ;;<br> *)<br> # Assume we don't need to do any additional testing<br> # for this interface beyond Shorewall's<br> return 0<br> ;;<br> esac<br><br> Additional information is available at<br> http://www.shorewall.net/shorewall_extension_scripts.htm.<br><br>5) Processing of the message log in the 'show log', 'logwatch' and<br> 'dump' commands has been speeded up thanks to a suggestion by<br> Andrew Suffield.<br><br>6) Beginning with Shorewall 4.0, the shorewall 'stop', and 'clear'<br> commands were processed by the generated script from the<br> last successful 'start', 'restart' or 'refresh' command. This had<br> the side effect that updates to the /etc/shorewall/routestopped<br> file did not take effect until one of those three commands was<br> successfully processed.<br><br> Beginning with Shorewall 4.0.3, the old 3.x behavior is restored as<br> the default and the 4.0 behavior is enabled using the '-f' command<br> option.<br><br> Example: shorewall stop -f<br><br> is only recognized by Shorewall-perl and causes Shorewall to set<br> the MSS field in forwarded TCP SYN packets going in or out the<br> interface to the value that you specify.<br><br> Example:<br><br> #ZONE INTERFACE BROADCAST OPTIONS<br> vpn ppp0 - mss=1400<br><br> The mss option only affects incoming traffic that has not been<br> decrypted by IPSEC and outgoing traffic that will not subsequently<br> be encrypted by IPSEC. The MSS for IPSEC traffic is managed by the<br> 'mss' option in /etc/shorewall/zones.<br><br>8) Shorewall now detects the presence of the 'hashlimit match'<br> capability. There is no builtin support yet for hashlimit but<br> detection allows extension scripts for user-supplied actions to<br> determine if the capability exists.<br><br> With Shorewall-shell, $HASHLIMIT_MATCH will be non-empty if the<br> capability exists.<br><br> With Shorewall-perl, $capabilities{HASHLIMIT_MATCH} will be true in<br> a boolean context if the capability exists. Shorewall-perl users<br> may also code the following in their extension script:<br><br> use Shorewall::Config;<br><br> require_capability( 'HASHLIMIT_MATCH', #Capability<br> 'My hashlimit action' , #Feature requiring <br> #capability<br> 's' ); #Feature is singular<br> #(if plural, pass the<br> empty string)<br><br> That call would procduce the following fatal error if the<br> capability isn't available:<br><br> ERROR: My hashlimit action requires the Hashlimit match capability<br> in your kernel and iptables<br><br>9) NFQUEUE support has been added to Shorewall-perl.<br><br> NFQUEUE may appear in actions, macros, rules and as a policy.<br> When NFQUEUE is used by itself, queue number zero is assumed. To<br> specify a queue number, follow NFQUEUE by a slash ("/") and the<br> queue number.<br><br> Examples (/etc/shorewall/rules):<br><br> NFQUEUE loc net tcp #Queue number 0<br> NFQUEUE/22 loc net udp #Queue number 22<br> NFQUEUE/22:info loc net gre #With logging<br><br> An NFQUEUE_DEFAULT option has been added to shorewall.conf for<br> specifying the default action to use with NFQUEUE policies.<br><br> Use of NFQUEUE requires the NFQUEUE Target capability in your<br> kernel/iptables. If you intend to use NFQUEUE with Shorewall-lite,<br> then you must install Shorewall-lite 4.0.3 in order to build a<br> capabilities file that includes NFQUEUE Target. If your<br> capabilities file was generated by a Shorewall/Shorewall-lite<br> version earlier that 4.0.3, you will receive a warning during<br> compilation.<br><br>10) The 'refresh' command can now refresh chains other than 'blacklst'.<br><br> The syntax of the command is now:<br><br> shorewall refresh [ <chain> ... ]<br><br> If no <chain> is given then 'blacklst' is assumed. Otherwise, the<br> Shorewall-perl compiler compiles a script whose 'refresh' command<br> refreshes the listed <chain>(s).<br><br> The listed chains are assumed to be in the filter table. You can<br> refresh chains in other tables by prefixing the chain name with the<br> table name followed by ":" (e.g., nat:net_dnat). Chain names which<br> follow are assumed to be in that table until the end of the list or<br> until an entry in the list names another table.<br><br> This feature requires Shorewall-perl 4.0.3 as well as<br> Shorewall-common 4.0.3.</pre>
|
|
<hr>
|
|
<p><strong>2007-08-19 Shorewall 3.4.6</strong></p>
|
|
<pre>Problems Corrected in 3.4.6.<br><br>1) If the "Mangle FORWARD Chain" capability was supported, entries in<br> the /etc/shorewall/ecn file would cause invalid iptables<br> commands to be generated.<br><br>2) Certain errors occurring during<br> start/restart/safe-start/safe-restart/try processing could cause<br> the lockfile to be left behind. This resulted in a 60-second delay<br> the next time one of these commands was run.<br><br>3) It was not previously possible to define traffic shaping on a<br> bridge port; the generated script complained that the<br> interface was not up and configured.<br><br>4) Previously, using a port list in the DEST PORT(S) column of the<br> rules file or in an action file caused an invalid iptables command<br> to be generated.<br><br>5) Using the LOG target in the rules file could result in two LOG<br> rules being generated. Additionally, using an IP address range in a<br> rule that performed logging could result in an invalid iptables<br> command.<br><br>6) Shorewall now loads the act_police kernel module needed by traffic<br> shaping.<br><br>7) Previously, "shorewall show -f capabilities" and "shorecap" omitted<br> the "TCPMSS Match" capability. This made it appear to a compiler<br> using a capabilities file that the TCPMSS Match capability was not<br> available.<br><br>8) Previously, Shorewall would truncate long log prefixes to 29<br> characters. This resulted in there being no space between the log<br> prefix and the IN= part of the message.<br><br> Example: fw2net:LOG:HTTPSoutIN= OUT=eth0<br><br> Beginning with this release, Shorewall will truncate the prefix to<br> 28 bytes and add a trailing space.<br><br> Example: fw2net:LOG:HTTPSou IN= OUT=eth0<br><br>9) Previously, if:<br><br> - FASTACCEPT=No<br> - The policy from Z1 to Z2 was CONTINUE<br> - Z1 and Z2 were orphans (neither had parent zones)<br> - There were no Z1->Z2 rules<br><br> then connections from Z2->Z1 would fail even if there were<br> rules/policies allowing them. This has been<br> corrected. <br> <br>Other changes in 3.4.6.<br><br>1) Processing of the message log in the 'show log', 'logwatch' and<br> 'dump' commands has been speeded up thanks to a suggestion by<br> Andrew Suffield.</pre>
|
|
<hr>
|
|
<p><strong>2007-08-10 Shorewall 4.0.2</strong></p>
|
|
<pre>Problems corrected in 4.0.2<br><br>1) The Shorewall-perl compiler was still generating invalid<br> iptables-restore input from entries in /etc/shorewall/ecn.<br><br>2) When using Shorewall-perl, unless an interface was specified as<br> 'optional' in the interfaces file, the 'restore' command would<br> fail if the routes through the interface or the addresses on the<br> interface could not be detected.<br><br> Route detection occurs when the interface is named in the SOURCE<br> column of the masq file. Address detection occurs when<br> DETECT_DNAT_IPADDRS=Yes and the interface is the SOURCE for a DNAT<br> or REDIRECT rule or when 'maclist' is specified for the interface.<br> <br> Since the 'restore' command doesn't use the detected information,<br> detection is now skipped if the command is 'restore'.<br><br>3) It was not previously possible to define traffic shaping on a<br> bridge port; the generated script complained that the<br> interface was not up and configured.<br><br>4) When Shorewall-shell was not installed, certain options in<br> /etc/shorewall/interfaces and /etc/shorewall/hosts would cause the<br> 'add' and 'delete' commands to fail with a missing library error.<br><br> OPTION FILE<br> maclist interfaces,hosts<br> proxyarp interfaces<br><br>5) The /var/lib/shorewall/zones file was being overwritten during<br> processing of the 'refresh' command by a script generated with<br> Shorewall-perl. The result was that hosts previously added to<br> dynamic zones could not be deleted after the 'refresh'.<br><br>6) If the file named as the output file in a Shorewall-perl 'compile'<br> command was a symbolic link, the generated error message<br> erroneously stated that the file's parent directory was a symbolic<br> link.<br><br> As part of this change, cosmetic changes were made to a number of<br> other error messages.<br><br>7) Some intra-zone rules were missing when a zone involved multiple<br> interfaces or when a zone included both IPSEC and non-IPSEC<br> networks.<br><br>8) Shorewall was not previously loading the xt_multiport kernel<br> module.<br><br>9) The Russian and French translations no longer have English headings<br> on notes, cautions, etc..<br><br>10) Previously, using a port list in the DEST PORT(S) column of the<br> rules file or in an action file could cause an invalid iptables<br> command to be generated by Shorewall-shell.<br><br>11) If there were no bridges in a configuration, Shorewall-perl would<br> ignore the CHAIN column in /etc/shorewall/accounting.<br><br>Other changes in 4.0.2<br><br>1) Shorewall-perl now detects when a port range is included in a list<br> of ports and iptables/kernel support for Extended Multi-port Match<br> is not available. This avoids an iptables-restore failure at<br> run-time.<br><br>2) Most chains created by Shorewall-shell have names that can be<br> embedded within shell variable names. This is a workaround for<br> limitations in the shell programming language which has no<br> equivalent to Perl hashes. Often chain names must have the name of<br> a network interface encoded in them. Given that interface names can<br> contain characters that are invalid in a shell variable name,<br> Shorewall-shell performs a name mapping which was carried forward to<br> Shorewall-perl:<br><br> - Trailing '+' is dropped.<br> - The characters ".", "-", "%' and "@" are translated to "_".<br><br> This mapping has been elminated in the 4.0.2 release of Shorewall-<br> perl. So where before you would see chain "eth0_0_in", you may now<br> see the same chain named "eth0.0_in". Similarly, a chain previously<br> named "ppp_fwd" may now be called "ppp+_fwd".<br><br>3) Shorewall-perl now uses the contents of the BROADCAST column in<br> /etc/shorewall/interfaces when the Address Type match capability is<br> not available.</pre>
|
|
<hr>
|
|
<p><strong>2007-07-30 Shorewall 4.0.1</strong></p>
|
|
<pre>Problems corrected in 4.0.1.<br><br>1) The Shorewall Lite installer was producing an empty shorewall-lite<br> manpage. Since the installer runs as part of creating the RPM, the<br> RPM also suffered from this problem. The 4.0.0 Shorewall-lite <br> packages were re-uploaded with this problem corrected.<br><br>2) The Shorewall Lite uninstaller incorrectly removed /sbin/shorewall<br> rather than /sbin/shorewall-lite.<br><br>3) Both the Shorewall and Shorewall Lite uninstallers did a "shorewall<br> clear" if Shorewall [Lite] was running. Now, the Shorewall Lite<br> uninstaller correctly does "shorewall-lite clear" and both<br> uninstallers only perform the 'clear' operation if the other<br> product is not installed. This prevents the removal of one of the<br> two products from clearing the firewall configuration established<br> by the other one.<br><br>4) The 'ipsec' OPTION in /etc/shorewall/hosts was mis-handled by<br> Shorewall-perl. If the zone type was changed to 'ipsec' or<br> 'ipsec4' and the 'ipsec' option removed from the hosts file entry,<br> the configuration worked properly.<br><br>5) If a CLASSID was specified in a tcrule and TC_ENABLED=No, then<br> Shorewall-perl produced the following:<br><br> Compiling...<br> Use of uninitialized value in string ne at /usr/share/shorewall-perl/Shorewall/Tc.pm line 285, <$currentfile> line 18.<br> ERROR: Class Id n:m is not associated with device eth0 : /etc/shorewall/tcrules (line 18)<br><br>6) If IPTABLES was not specified in shorewall.conf, Shorewall-perl was<br> locating the binary using the PATH environmental variable rather<br> than the PATH setting in shorewall.conf. If no PATH was available<br> when Shorewall-perl was run and IPTABLES was not set in<br> shorewall.conf, the following messages were issued:<br><br> Use of uninitialized value in split at /usr/share/shorewall-perl/Shorewall/Config.pm line 1054.<br> ERROR: Can't find iptables executable<br> ERROR: Shorewall restart failed<br><br>7) If the "Mangle FORWARD Chain" capability was supported, entries in<br> the /etc/shorewall/ecn file would cause invalid iptables commands<br> to be generated. This problem occurred with both compilers.<br><br>8) Shorewall now starts at reboot after an upgrade from shorewall <<br> 4.0.0. Previously, Shorewall was not started automatically at<br> reboot after an upgrade using the RPMs.<br><br>9) Shorewall-perl was generating invalid iptables-restore input when a<br> log level was specified with the dropBcast and allowBcast builtin<br> actions and when a log level followed by '!' was used with any<br> builtin actions.<br><br>10) Shorewall-perl was incorrectly rejecting 'min' as a valid unit of<br> time in rate-limiting specifications.<br><br>11) Certain errors occurring during<br> start/restart/safe-start/safe-restart/try processing could cause<br> the lockfile to be left behind. This resulted in a 60-second delay<br> the next time one of these commands was run.<br><br>Other changes in Shorewall 4.0.1.<br><br>1) A new EXPAND_POLICIES option is added to shorewall.conf. The<br> option is recognized by Shorewall-perl and is ignored by<br> Shorewall-shell.<br><br> Normally, when the SOURCE or DEST columns in shorewall-policy(5)<br> contains 'all', a single policy chain is created and the policy is<br> enforced in that chain. For example, if the policy entry is<br><br> #SOURCE DEST POLICY LOG<br> # LEVEL<br> net all DROP info<br><br> then the chain name is 'net2all' which is also the chain named in<br> Shorewall log messages generated as a result of the policy. If<br> EXPAND_POLICIES=Yes, then Shorewall-perl will create a separate<br> chain for each pair of zones covered by the policy. This makes the<br> resulting log messages easier to interpret since the chain in the<br> messages will have a name of the form 'a2b' where 'a' is the SOURCE<br> zone and 'b' is the DEST zone. See<br> http://linuxman.wikispaces.com/PPPPPPS for more information.<br><br>2) The Shorewall-perl dependency on the "Address Type Match"<br> capability has been relaxed. This allows Shorewall 4.0.1 to be used<br> on releases like RHEL4 that don't support that capability.<br><br>3) Shorewall-perl now detects dead policy file entries that result<br> when an entry is masked by an earlier entry. Example:<br><br> all all REJECT info<br> loc net ACCEPT<br><br>4) Recent kernels are apparently hard to configure and we have been<br> seeing a lot of problem reports where the root cause is the lack of<br> state match support in the kernel. This problem is difficult to<br> diagnose when using Shorewall-perl so the generated shell program<br> now checks specifically for this problem and terminates with an<br> error if the capability doesn't exist.</pre>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<p><strong>2007-07-20 Shorewall 4.0.0</strong></p>
|
|
<pre>----------------------------------------------------------------------------<br> R E L E A S E H I G H L I G H T S<br>----------------------------------------------------------------------------<br>1) This is the first Shorewall release that fully integrates the new<br> Shorewall-perl compiler. See the "New Features" section below.<br><br>2) You are now offered a choice as to which compiler(s) you install. In<br> 4.0.0, there are the following packages:<br><br> - Shorewall-common ( common files )<br> - Shorewall-shell ( the shell-based compiler )<br> - Shorewall-perl (the Perl-based compiler )<br><br> You must install at least one of the compiler packages (you may<br> install them both) along with Shorewall-common.<br><br> YOU DO NOT NEED TO UNINSTALL ANY OF YOUR CURRENT PACKAGES.<br><br> See the Migration Considerations below for further information.<br><br>3) The facilities for supporting bridge/firewalls under earlier<br> releases are deprecated and their documentation is omitted from the<br> 4.0 distribution. New bridge support is implemented in the<br> Shorewall-perl compiler. This support utilizes the reduced-function<br> physdev match support available in Linux kernel 2.6.20 and later.<br><br>Problems corrected in 4.0.0 Final.<br><br>1) The shorewall-lite install.sh may now be run multiple times from<br> the same directory. Previously, the manpages were gzipped in-place<br> which made it impossible to rerun the script.<br><br>2) If shorewall.conf contained SHOREWALL_COMPILER=shell (which it can<br> on Shorewall 3.4.2-4 systems) and the shorewall-shell RPM was<br> removed, subsequent "shorewall [re]start" operations failed. When<br> shorewall-shell is removed, the shorewall.conf file is modified to<br> specify SHOREWALL_COMPILER= and the original is saved in<br> shorewall.conf.rpmsave.<br><br>3) The contents of the LOG LEVEL column in /etc/shorewall/policy are<br> now validated at compile time by Shorewall-perl.<br><br>Other changes in Shorewall 4.0.0 Final.<br><br>1) The Perl modules in /usr/share/shorewall-perl/Shorewall/ have been<br> consolidated somewhat, leading to slightly faster compilation.<br><br>Migration Considerations:<br><br>1) Beginning with Shorewall 4.0.0, there is no single 'shorewall'<br> package. Rather there are two compiler packages (shorewall-shell<br> and shorewall-perl) and a set of base files (shorewall-common)<br> which are required by either compiler package.<br><br> Although the names of the packages are changing, you can upgrade<br> without having to uninstall/reinstall.<br><br> To repeat: YOU DO NOT NEED TO UNINSTALL ANY EXISTING PACKAGE.<br><br> If you attempt to upgrade using the shorewall-common RPM, you get<br> this result:<br> gateway:~ # rpm -Uvh shorewall-common-4.0.0.noarch.rpm <br> error: Failed dependencies:<br> shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch<br> gateway:~ #<br><br> You must either:<br><br> rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \<br> shorewall-common-4.0.0.noarch.rpm<br><br> or<br><br> rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \<br> shorewall-perl-4.0.0.noarch.rpm \<br> shorewall-common-4.0.0.noarch.rpm<br><br> If you don't want to use shorewall-perl exclusively then use the<br> second command above then<br><br> rpm -e shorewall-shell<br> <br> If you are upgrading using the tarball, you must install <br> shorewall-shell and/or shorewall-perl before you upgrade<br> using shorewall-common. Otherwise, the install.sh script fails with:<br><br> ERROR: No Shorewall compiler is installed<br><br> The shorewall-shell and shorewall-perl packages are installed from<br> the tarball in the expected way; untar the package, and run the<br> install.sh script.<br><br> Example 1: You have 'shorewall' installed and you want to continue<br> to use the shorewall-shell compiler.<br><br> tar -jxf shorewall-common-4.0.0.tar.bz2<br> tar -jxf shorewall-shell-4.0.0.tar.bz2<br><br> cd shorewall-shell-4.0.0<br> ./install.sh<br> cd ../shorewall-common-4.0.0<br> ./install.sh<br> shorewall check<br> shorewall restart<br><br> Example 2: You have shorewall 3.4.4 and shorewall-perl 4.0.0-Beta7<br> installed and you want to upgrade to 4.0. You do not need the<br> shell-based compiler.<br><br> tar -jxf shorewall-common-4.0.0.tar.bz2<br> tar -jxf shorewall-perl-4.0.0.tar.bz2<br><br> cd shorewall-perl-4.0.0<br> ./install.sh<br> cd ../shorewall-common-4.0.0<br> ./install.sh<br> shorewall check<br> shorewall restart<br><br> Be sure to modify shorewall.conf if it still has<br> SHOREWALL_COMPILER=shell.<br><br>2) The ROUTE_FILTER and LOG_MARTIANS options in shorewall.conf work<br> slightly differently in Shorewall 4.0.0. In prior releases, leaving<br> these options empty was equivalent to setting them to 'No' which<br> caused the corresponding flag in /proc to be reset for all<br> interfaces. Beginning in Shorewall 4.0.0, leaving these options<br> empty causes Shorewall to leave the flags in /proc as they are. You<br> must set the option to 'No' in order to obtain the old behavior.<br><br>3) The -f option is no longer the default when Shorewall is started at<br> boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,<br> "shorewall start" is nearly as fast as "shorewall restore" and<br> "shorewall start" uses the current configuration which avoids<br> confusion.<br><br> If you plan on continuing to use Shorewall-shell and you want to<br> use the "-f" option at boot time, then you must add the following<br> to /etc/sysconfig/shorewall or /etc/default/shorewall:<br><br> OPTIONS="-f"<br><br> If you currently have neither of those files, you will need to<br> create one of them. <br><br>4) This issue will only affect you if you use Shorewall Lite and have<br> modified /usr/share/configpath to specify a different LITEDIR.<br><br> The implementation of LITEDIR has always been<br> unsatisfactory. Furthermore, there have been other cases where<br> people have asked to be able to designate the state directory<br> (default /var/lib/shorewall[-lite]).<br><br> To meet these objectives:<br><br> a) The LITEDIR variable has been eliminated in<br> /usr/share/shorewall[-lite]/configpath.<br><br> b) A new file /etc/shorewall[-lite]/vardir has been added. This<br> file is not created by default but may be added as needed. It<br> is expected to contain a single variable assignment:<br><br> VARDIR=<directory><br><br> Example:<br><br> VARDIR=/root/shorewall<br> <br> To change VARDIR, copy the old directory to the new one before you<br> restart Shorewall[-lite].<br><br> To use this feature with Shorewall-lite, all packages involved<br> (compiler, shorewall-common and shorewall-lite) must be version<br> 4.0.0-RC2 or later.<br><br>----------------------------------------------------------------------------<br> N E W F E A T U R E S<br>----------------------------------------------------------------------------<br>1) Shorewall-perl<br><br> This Shorewall package includes a complete rewrite of the compiler<br> in Perl.<br><br> I decided to make Shorewall-perl a separate package for several reasons:<br><br> a) Embedded applications are unlikely to adopt Shorewall-perl; even<br> Mini-Perl has a substantial disk and RAM footprint.<br><br> b) Because of the gross incompatibilities between the new compiler and the<br> old (see below), migration to the new compiler must be voluntary.<br> ------------------------------------------------------------------------<br> T H E G O O D N E W S:<br> ------------------------------------------------------------------------<br> a) The compiler has a small disk footprint.<br> b) The compiler is very fast.<br> c) The compiler generates a firewall script that uses iptables-restore;<br> so the script is very fast.<br> d) The new compiler does a much better job of validating the<br> configuration and catches many errors that resulted in run-time<br> failures with the old compiler.<br> e) Use of the Shorewall-perl is optional! The old slow clunky<br> Bourne-shell compiler is still available.<br> ------------------------------------------------------------------------<br> T H E B A D N E W S:<br> ------------------------------------------------------------------------<br> There are a number of incompatibilities between the Perl-based compiler<br> and the Bourne-shell one.<br><br> a) The Perl-based compiler requires the following capabilities in your<br> kernel and iptables.<br><br> - addrtype match<br> - multiport match<br><br> These capabilities are in current distributions.<br><br> b) Now that Netfilter has features to deal reasonably with port lists,<br> I see no reason to duplicate those features in Shorewall. The<br> Bourne-shell compiler goes to great pain (in some cases) to<br> break very long port lists ( > 15 where port ranges in lists<br> count as two ports) into individual rules. In the new compiler, I'm<br> avoiding the ugliness required to do that. The new compiler just<br> generates an error if your list is too long. It will also produce<br> an error if you insert a port range into a port list and you don't<br> have extended multiport support.<br><br> c) The old BRIDGING=Yes support has been replaced by new bridge<br> support that uses the reduced 'physdev match' capabilities found<br> in kernel 2.6.20 and later. This new implementation may be used<br> where it is desired to control traffic through a bridge.<br><br> The new implementation includes the following features:<br><br> a) A new "Bridge Port" zone type is defined. Specify 'bport' or<br> 'bport4' in the TYPE column of /etc/shorewall/zones.<br><br> Bridge Port zones should be a sub-zone of a regular ipv4 zone<br> that represents all hosts attached to the bridge.<br><br> b) A new 'bridge' option is defined for entries in <br> /etc/shorewall/interfaces. Bridges should have this option<br> specified, even if you don't want to filter traffic going<br> through the bridge.<br><br> c) Bridge ports must now be defined in<br> /etc/shorewall/interfaces. The INTERFACE column contains<br> both the bridge name and the port name separated by a colon<br> (e.g., "br0:eth1"). No OPTIONS are allowed for bridge<br> ports. The bridge must be defined before its ports and must<br> have the 'bridge' option.<br><br> Bridge Port (BP) zones have a number of limitations:<br><br> a) Each BP zone may only be associated with ports on a single<br> bridge.<br><br> b) BP zones may not be associated with interfaces that are not<br> bridge ports.<br><br> c) You may not have policies or rules where the DEST is a BP<br> zone but the source is not a BP zone. If you need such<br> rules, you must use the BP zone's parent zone as the DEST<br> zone.<br><br> Example (Bridge br0 with ports eth1 and tap0):<br><br> /etc/shorewall/zones:<br><br> fw firewall<br> net ipv4<br> loc ipv4<br> lan:loc bport<br> vpn:loc bport<br><br> /etc/shorewall/interfaces:<br><br> net eth0 - ...<br> loc br0 - ...<br> lan eth1<br> vpn tap0<br><br> When using the /etc/shorewall/hosts file to define a bport4<br> zone, you specify only the port name:<br><br> Example:<br><br> /etc/shorewall/zones:<br><br> fw firewall<br> net ipv4<br> loc ipv4<br> lan:loc bport<br> vpn:loc bport<br><br> /etc/shorewall/hosts<br><br> lan eth1:192.168.2.0/24 ...<br><br> The structure of the accounting rules changes slightly when<br> there are bridges defined in the Shorewall<br> configuration. Because of the restrictions imposed by Netfilter<br> in kernel 2.6.21 and later, output accounting rules must be<br> segregated from forwarding and input rules.<br><br> To accomplish this separation, Shorewall-perl creates two<br> accounting chains:<br><br> - accounting - for input and forwarded traffic.<br> - accountout - for output traffic.<br><br> If the CHAIN column contains '-', then:<br><br> - If the SOURCE column in a rule includes the name of the<br> firewall zone (e.g., $FW), then the rule is add only<br> to the accountout chain.<br><br> - Otherwise, if the DEST in the rule is any or all or 0.0.0.0/0,<br> then the rule is added to both accounting and accountout.<br><br> - Otherwise, the rule is added to accounting only.<br><br> See http://www.shorewall.net/bridge-Shorewall-perl.html for<br> additional information about the new bridge support. <br><br> d) The BROADCAST column in the interfaces file is essentially unused;<br> if you enter anything in this column but '-' or 'detect', you will<br> receive a warning.<br><br> e) Because the compiler is written in Perl, some of your extension<br> scripts from earlier versions will no longer work because<br> Shorewall-perl runs those extension scripts at compile-time rather<br> than at run-time. <br><br> Compile-time scripts are:<br><br> initdone<br> maclog<br> All per-chain scripts including those associated with actions.<br><br> Compile-time extension scripts are executed using the Perl 'eval<br> `cat <file>`' mechanism. Be sure that each script returns a<br> 'true' value; otherwise, the compiler will assume that the<br> script failed and will abort the compilation.<br><br> All scripts will need to begin with the following line:<br><br> use Shorewall::Chains;<br><br> For more complex scripts, you may need to 'use' other Shorewall<br> Perl modules -- browse /usr/share/shorewall-perl/Shorewall/ to<br> see what's available.<br><br> When a script is invoked, the $chainref scalar variable will hold a<br> reference to a chain table entry. <br><br> $chainref->{name} contains the name of the chain<br> $chainref->{table} holds the table name<br> <br> To add a rule to the chain:<br><br> add_rule( $chainref, <the rule> );<br><br> Where<br><br> <the rule> is a scalar argument holding the rule text. Do<br> not include "-A <chain name>"<br><br> Example:<br><br> add_rule( $chainref, '-j ACCEPT' );<br><br> To insert a rule into the chain:<br><br> insert_rule( $chainref, <rulenum>, <the rule> );<br><br> The log_rule_limit function works like it does in the shell<br> compiler with two exceptions:<br><br> - You pass the chain reference rather than the name of<br> the chain.<br> - The commands are 'add' and 'insert' rather than '-A'<br> and '-I'.<br> - There is only a single "pass as-is to iptables"<br> argument (so you must quote that part).<br><br> Example:<br><br> log_rule_limit(<br> 'info' , <br> $chainref , <br> $chainref->{name},<br> 'DROP' , <br> '', #Limit<br> '' , #Log tag<br> 'add', #Command<br> '-p tcp' #Pass as-is<br> );<br><br> Note that in the 'initdone' script, there is no default chain<br> ($chainref). You can objtain a reference to a standard chain by:<br><br> my $chainref = $chain_table{<table>}{<chain name>};<br><br> Example:<br><br> my $chainref = $chain_table{'filter'}{'INPUT'};<br><br> The continue script is eliminated. That script was designed to<br> allow you to add special rules during [re]start. Shorewall-perl<br> doesn't need such rules.<br><br> See http://www.shorewall.net/shorewall_extension_scripts.htm<br> for further information about extension scripts under<br> Shorewall-perl.<br><br> f) The 'refresh' command now works like 'restart' with the<br> following exceptions:<br><br> - The refresh command is rejected if Shorewall is not running.<br> - The refresh command only rebuilds the 'blacklst' chain.<br> - A directory name may not be specified in the refresh command.<br><br> g) The /etc/shorewall/tos file now has zone-independent SOURCE and<br> DEST columns as do all other files except the rules and policy<br> files.<br><br> The SOURCE column may be one of the following:<br><br> [all:]<address>[,...]<br> [all:]<interface>[:<address>[,...]]<br> $FW[:<address>[,...]]<br><br> The DEST column may be one of the following:<br> <br> [all:]<address>[,...]<br> [all:]<interface>[:<address>[,...]]<br><br> This is a permanent change. The old zone-based rules have never<br> worked right and this is a good time to replace them. I've tried<br> to make the new syntax cover the most common cases without<br> requiring change to existing files. In particular, it will<br> handle the tos file released with Shorewall 1.4 and earlier.<br><br> h) Shorewall is now out of the ipset load/reload business. With<br> scripts generated by the Perl-based Compiler, the Netfilter<br> ruleset is never cleared. That means that there is no<br> opportunity for Shorewall to load/reload your ipsets since that<br> cannot be done while there are any current rules using ipsets.<br><br> So:<br><br> i) Your ipsets must be loaded before Shorewall starts. You<br> are free to try to do that with the following code in<br> /etc/shorewall/start:<br><br> if [ "$COMMAND" = start ]; then<br> ipset -U :all: :all:<br> ipset -F<br> ipset -X<br> ipset -R < /my/ipset/contents<br> fi<br><br> The file '/my/ipset/contents' (not its real name of<br> course) will normally be produced using the ipset -S<br> command.<br><br> The above will work most of the time but will fail in a<br> 'shorewall stop' - 'shorewall start' sequence if you<br> use ipsets in your routestopped file (see below).<br><br> ii) Your ipsets may not be reloaded until Shorewall is stopped<br> or cleared.<br><br> iii) If you specify ipsets in your routestopped file then<br> Shorewall must be cleared in order to reload your ipsets.<br><br> As a consequence, scripts generated by the Perl-based compiler<br> will ignore /etc/shorewall/ipsets and will issue a warning if<br> you set SAVE_IPSETS=Yes in shorewall.conf.<br><br> i) Because the configuration files (with the exception of<br> /etc/shorewall/params) are now processed by the Perl-based<br> compiler rather than by the shell, only the basic forms of Shell<br> expansion ($variable and ${variable}) are supported. The more<br> exotic forms such as ${variable:=default} are not<br> supported. Both variables defined in /etc/shorewall/params and<br> environmental variables (exported by the shell) can be used in<br> configuration files.<br><br> j) USE_ACTIONS=No is not supported. That option is intended to<br> minimize Shorewall's footprint in embedded applications. As a<br> consequence, Default Macros are not supported.<br><br> k) DELAYBLACKLISTLOAD=Yes is not supported. The entire ruleset is<br> atomically loaded with one execution of iptables-restore.<br><br> l) MAPOLDACTIONS=Yes is not supported. People should have converted<br> to using macros by now.<br><br> m) The pre Shorewall-3.0 format of the zones file is not supported;<br> neither is the /etc/shorewall/ipsec file.<br><br> n) BLACKLISTNEWONLY=No is not permitted with FASTACCEPT=Yes. This<br> combination doesn't work in previous versions of Shorewall so<br> the Perl-based compiler simply rejects it.<br><br> o) Shorewall-perl has a single rule generator that is used for all<br> rule-oriented files. So it is important that the syntax is<br> consistent between files.<br> <br> With shorewall-shell, there is a special syntax in the SOURCE<br> column of /etc/shorewall/masq to designate "all traffic entering<br> the firewall on this interface except...".<br><br> Example:<br><br> #INTERFACE SOURCE ADDRESSES<br> eth0 eth1!192.168.4.9 ...<br><br> Shorewall-perl uses syntax that is consistent with the rest of<br> Shorewall:<br><br> #INTERFACE SOURCE ADDRESSES<br> eth0 eth1:!192.168.4.9 ...<br><br> p) The 'allowoutUPnP' built-in action is no longer supported. The<br> Netfilter team have removed support for '-m owner --owner-cmd'<br> which that action depended on. <br><br> q) The treatment of the following interface options has changed under<br> Shorewall-perl.<br><br> - arp_filter<br> - routefilter<br> - logmartians<br> - proxy_arp<br> - sourceroute<br><br> With the Shorewall-shell compiler, Shorewall resets these options<br> on all interfaces then sets the option on those interfaces<br> for which the option is defined in /etc/shorewall/interfaces.<br><br> Under Shorewall-perl, these options can be specified with the value<br> 0 or 1 (e.g., proxy_arp=0). If no value is specified, the value 1<br> is assumed. Shorewall will modify only the setting of those<br> interfaces for which the option is specified and will set the<br> option to the given value.<br><br> A fatal compilation error is also generated if you specify one of<br> these options with a wildcard interface (one ending with '+').<br><br> r) The LOG_MARTIANS and ROUTE_FILTER options are now tri-valued in<br> Shorewall-perl.<br><br> Yes - Same as before<br> No - Same as before except that it applies regardless of<br> whether any interfaces have the logmartians/routefilter<br> option<br> Keep - Shorewall ignores the option entirely (which is the<br> default).<br><br> s) Shorewall-perl support nn 'optional' option has been added to<br> /etc/shorewall/interfaces. This option is recognized by<br> Shorewall-perl but not by Shorewall-shell. When 'optional' is<br> specified for an interface, Shorewall will be silent when:<br><br> - a /proc/sys/net/ipv4/conf/ entry for the interface cannot be<br> modified (including for proxy ARP).<br><br> - The first address of the interface cannot be obtained.<br><br> I specify 'optional' on interfaces to Xen virtual machines that<br> may or may not be running when Shorewall is [re]started.<br><br> CAUTION: Use 'optional' at your own risk. If you [re]start<br> Shorewall when an 'optional' interface is not available and then<br> do a 'shorewall save', subsequent 'shorewall restore' and<br> 'shorewall -f start' operations will instantiate a ruleset that<br> does not support that interface, even if it is available at the<br> time of the restore/start.<br><br> t) Shorewall-perl validates all IP addresses and addresses ranges<br> in rules. DNS names are resolved and an error is issued for any<br> name that cannot be resolved.<br> u) Shorewall-perl checks configuration files for the presense of<br> characters that can cause problems if they are allowed into the<br> generated firewall script:<br><br> - Double Quotes. These are prohibited except in the<br> shorewall.conf and params files.<br><br> - Single Quotes. These are prohibited except in the<br> shorewall.conf and params files and in COMMENT lines.<br><br> - Single back quotes. These are prohibited except in the <br> shorewall.conf and params files.<br><br> - Backslash. Probibited except as the last character on a line<br> to denote line continuation.<br><br> v) Under Shorewall-perl, macros may invoke other macros with the<br> restriction that such macros may not be invoked within an action<br> body.<br><br> When marcros are invoked recursively, the parameter passed to an<br> invocation are automatically propagated to lower level macros.<br><br> Macro invocations may be nested to a maximum level of 5.<br> ------------------------------------------------------------------------<br> P R E R E Q U I S I T E S<br> ------------------------------------------------------------------------<br> - Perl (I use Perl 5.8.8 but other versions should work fine)<br> - Perl Cwd Module<br> - Perl File::Basename Module<br> - Perl File::Temp Module<br> - Perl Getopt::Long Module<br> ------------------------------------------------------------------------<br> U S I N G T H E N E W C O M P I L E R<br> If you only install one compiler, then that compiler will be used.<br><br> If you install both compilers, then the compiler actually used depends<br> on the SHOREWALL_COMPILER setting in shorewall.conf.<br><br> The value of this new option can be either 'perl' or 'shell'.<br><br> If you add 'SHOREWALL_COMPILER=perl' to /etc/shorewall/shorewall.conf<br> then by default, the new compiler will be used on the system. If you<br> add it to shorewall.conf in a separate directory (such as a<br> Shorewall-lite export directory) then the new compiler will only be<br> used when you compile from that directory.<br><br> If you only install one compiler, it is suggested that you do not set<br> SHOREWALL_COMPILER.<br><br> You can also select the compiler to use on the command line using the<br> 'C option:<br><br> '-C shell' means use the shell compiler<br> '-C perl' means use the perl compiler<br><br> The -C option overrides the setting in shorewall.conf. <br><br> Example:<br><br> shorewall restart -C perl<br><br>2) Thanks to Paul Gear, an IPPServer macro has been added. Be sure to<br> read the comments in the macro file before trying to use this<br> macro.<br><br>3) Eariler generations of Shorewall Lite required that remote root<br> login via ssh be enabled in order to use the 'load' and 'reload'<br> commands.<br><br> Beginning with this release, you may define an alternative means<br> for accessing the remote firewall system.<br><br> Two new options have been added to shorewall.conf:<br><br> RSH_COMMAND<br> RCP_COMMAND<br><br> The default values for these are as follows:<br><br> RSH_COMMAND: ssh ${root}@${system} ${command}<br> RCP_COMMAND: scp ${files} ${root}@${system}:${destination}<br><br> Shell variables that will be set when the commands are envoked are<br> as follows:<br><br> root - root user. Normally 'root' but may be overridden using<br> the '-r' option.<br><br> system - The name/IP address of the remote firewall system.<br><br> command - For RSH_COMMAND, the command to be executed on the <br> firewall system.<br><br> files - For RCP_COMMAND, a space-separated list of files to<br> be copied to the remote firewall system.<br><br> destination - The directory on the remote system that the files <br> are to be copied into. <br><br>4) The accounting, masq, rules and tos files now have a 'MARK' column<br> similar to the column of the same name in the tcrules file. This<br> column allows filtering by MARK and CONNMARK value (CONNMARK is<br> only accepted under Shorewall Perl).<br><br>5) SOURCE and DEST are now reserved zone names to avoid problems with<br> bi-directional macro definitions which use these as names as key<br> words.<br><br>6) The "shorewall show zones" command now flags zone members that have<br> been added using "shorewall add" by preceding them with a plus sign<br> ("+").<br><br> Example:<br><br> Shorewall 3.9.4 Zones at gateway - Mon May 14 07:48:16 PDT 2007<br><br> fw (firewall)<br> net (ipv4)<br> eth0:0.0.0.0/0<br> loc (ipv4)<br> br0:0.0.0.0/0<br> eth4:0.0.0.0/0<br> eth5:0.0.0.0/0<br> +eth1:0.0.0.0/0<br> dmz (ipv4)<br> eth3:0.0.0.0/0<br> vpn (ipv4)<br> tun+:0.0.0.0/0<br><br> In the above output, "eth1:0.0.0.0/0" was dynamically added to the<br> 'loc' zone. As part of this change, "shorewall delete" will only<br> delete entries that have been added dynamically. In earlier<br> versions, any entry could be deleted although the ruleset was only<br> changed by deleting entries that had been added dynamically.<br><br>7) The 'shorewall version' command now lists the version of the<br> installed compiler(s) if the -a option is used:<br><br> gateway:/bulk/backup # shorewall version -a<br> 4.0.0-Beta1<br> Shorewall-shell 4.0.0-Beta1<br> Shorewall-perl 4.0.0-Beta1<br> gateway:/bulk/backup #<br><br>8) The Perl compiler is externalized. Both the compiler.pl program<br> and the Perl Module interface are documented.<br><br> The compiler program is /usr/share/shorewall-perl/compiler.pl:<br><br> compiler.pl [ <option> ... ] [ <filename> ]<br><br> If a <filename> is given, then the configuration will be compiled<br> output placed in the named file. If <filename> is not given, then<br> the configuration will simply be syntax checked.<br><br> Options are:<br><br> -v <verbosity><br> --verbosity=<verbosity><br> <br> The <verbosity> is a number between 0 and 2 and corresponds to<br> the VERBOSITY setting in shorewall.conf. This setting controls<br> the verbosity of the compiler itself.<br><br> -e<br> --export<br><br> If given, the configuration will be compiled for export to<br> another system.<br><br> -d <directory><br> --directory=<directory><br><br> If this option is omitted, the configuration in /etc/shorewall<br> is compiled/checked. Otherwise, the configuration in the named<br> directory will be compiled/checked.<br><br> -t<br> --timestamp<br><br> If given, each progress message issued by the compiler and by<br> the compiled program will be timestamped.<br><br> --debug<br><br> If given, when a warning or error message is issued, it is <br> supplimented with a stack trace. Requires the Carp Perl<br> module.<br><br> Example (compiles the configuration in the current directory <br> generating a script named 'firewall' and using VERBOSITY<br> 2).<br><br> /usr/share/shorewall-perl/compiler.pl -v 2 -d . firewall<br><br> Note: For compatibility with the Shorewall 3.4.2 and 3.4.3<br> releases, options not passed on the run-line get their values from<br> environmental variables:<br><br> Option Variable<br><br> --verbosity VERBOSE<br> --export EXPORT<br> --directory SHOREWALL_DIR<br> --timestamp TIMESTAMP<br><br> The Perl Module is externalized as follows:<br><br> use lib '/usr/share/shorewall-perl';<br> use Shorewall::Compiler;<br> <br> compiler $filename, $directory, $verbose, $options<br><br> The arguments to the compiler function are as follows:<br><br> $filename - Name of the compiled script to be created.<br> If the arguments evaluates to false, the<br> configuration is syntax checked<br> <br> $directory - The directory containing the configuration.<br> If passed as '', then /etc/shorewall/ is assumed.<br><br> $verbose - The verbosity level (0-2).<br><br> $options - A bitmap of options. Shorewall::Compiler<br> exports two constants to help building this<br> argument:<br><br> EXPORT = 0x01<br> TIMESTAMP = 0x02<br><br> The compiler raises an exception with 'die' if it encounters an<br> error; $@ contains the 'ERROR' messages describing the problem.<br> <br> The compiler function can be called repeatedly with different<br> inputs.<br><br>9) When TC_ENABLED=Internal, Shorewall-perl now validates classids in<br> the MARK/CLASSIFY column of /etc/shorewall/tcrules against the<br> classes generated by /etc/shorewall/tcclasses.<br><br>10) During installation, Shorewall generates the Perl module<br> /usr/share/shorewall-perl/Shorewall/Ports.pm, using your<br> /etc/protocols and /etc/services as input.<br><br> To re-generate the module from those two files:<br><br> 1. Backup your current /usr/share/shorewall-perl/Shorewall/Ports.pm<br> file.<br> 2. /usr/share/shorewall-perl/buildports.pl > \<br> /usr/share/shorewall-perl/Shorewall/Ports.pm<br><br> Note: If the buildports.pl program fails to run to a successful<br> completion during installation, a fallback version of<br> module will be installed. That fallback module was generated from<br> the /etc/protocols and /etc/services shipped with Ubuntu Feisty<br> Fawn.<br><br> Even if the buildports.pl program runs successfully, the fallback<br> module is also installed as<br> /usr/share/shorewall-perl/Shorewall/FallbackPorts.pm. So if you<br> encounter problems with the generated module, simply copy the<br> fallback module to /usr/share/shorewall-perl/Shorewall/Ports.pm.<br><br>11) Tuomo Soini has contributed bi-directional macros for various<br> tunnel types:<br><br> IPsecah<br> GRE<br> IPsec<br> IPIP<br> IPsecnat<br> L2TP<br><br>12) The -f option is no longer the default when Shorewall is started at<br> boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,<br> "shorewall start" is nearly as fast as "shorewall restore" and<br> "shorewall start" uses the current configuration which avoids<br> confusion.<br><br><br> To re-generate the module from those two files:<br><br> 1. Backup your current /usr/share/shorewall-perl/Shorewall/Ports.pm<br> file.<br> 2. /usr/share/shorewall-perl/buildports.pl > \<br> /usr/share/shorewall-perl/Shorewall/Ports.pm<br><br> Note: If the buildports.pl program fails to run to a successful<br> completion during installation, a fallback version of<br> module will be installed. That fallback module was generated from<br> the /etc/protocols and /etc/services shipped with Ubuntu Feisty<br> Fawn.<br><br> Even if the buildports.pl program runs successfully, the fallback<br> module is also installed as<br> /usr/share/shorewall-perl/Shorewall/FallbackPorts.pm. So if you<br> encounter problems with the generated module, simply copy the<br> fallback module to /usr/share/shorewall-perl/Shorewall/Ports.pm.<br><br>11) Tuomo Soini has contributed bi-directional macros for various<br> tunnel types:<br><br> IPsecah<br> GRE<br> IPsec<br> IPIP<br> IPsecnat<br> L2TP<br><br>12) The -f option is no longer the default when Shorewall is started at<br> boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,<br> "shorewall start" is nearly as fast as "shorewall restore" and<br> "shorewall start" uses the current configuration which avoids<br> confusion.<br><br>13) The implementation of LITEDIR has always been<br> unsatisfactory. Furthermore, there have been other cases where<br> people have asked to be able to designate the state directory<br> (default /var/lib/shorewall[-lite]).<br><br> To meet these objectives:<br><br> a) The LITEDIR variable has been eliminated in<br> /usr/share/shorewall[-lite]/configpath.<br><br> b) A new file /etc/shorewall[-lite]/vardir has been added. This<br> file is not created by default but may be added as needed. It<br> is expected to contain a single variable assignment:<br><br> VARDIR=<directory><br><br> Example:<br><br> VARDIR=/root/shorewall<br> <br> To change VARDIR, copy the old directory to the new one before you<br> restart Shorewall[-lite].<br><br> To use this feature with Shorewall-lite, all packages involved<br> (compiler, shorewall-common and shorewall-lite) must be version<br> 4.0.0-RC2 or later.</pre>
|
|
<hr>
|
|
<p><strong>2007-07-15 Shorewall 3.4.5</strong></p>
|
|
<pre>Problems Corrected in 3.4.5.<br><br>1) DYNAMIC_ZONES=Yes can now coexist with Shorewall-perl's 'bport'<br> zones. Those zones themselves may not be dynamically modified but<br> the presence of bport zones no longer causes the 'shorewall add'<br> command to fail.<br><br>2) Shorewall's internal traffic shaper once again works when the 'sed'<br> utility is provided by the Busybox package.<br><br>3) Version 3.4.4 erroneously accepted the values On, Off, on, off, ON<br> and OFF for the IP_FORWARDING option. These values were treated<br> like 'Keep'. The listed values are now once again flagged as an<br> error.<br><br>4) If 'routeback' and 'detectnets' were specified on an interface,<br> limited broadcasts (to 255.255.255.255) and multicasts were dropped<br> when forwarded through the interface. This could cause<br> broadcast-based and multicast applications to fail when running<br> through a bridge with 'detectnets'.<br><br>5) The 'hits' command works once again.<br><br>6) IPSECFILE=ipsec (either explicitly or defaulted) works<br> now. Previously, processing of the ipsec file was bypassed; often<br> with a confusing "missing file" message.<br><br>7) If DETECT_DNAT_IPADDRS=Yes in shorewall.conf but you did't have conntrack<br> match support, then the generated script was missing 'done's.<br><br>Other changes in 3.4.5.<br><br>1) When a Shorewall release includes detection of an additional<br> capability, existing capabilities files become out of<br> date. Previously, this condition was not detected.<br><br> Beginning with this release, each generated capabilities file<br> contains a CAPVERSION specification which defines the capabilities<br> version of the file. If the CAPVERSION in a capabilities file is<br> less than the current CAPVERSION, then Shorewall will issue the<br> following message:<br><br> WARNING: <file> is out of date -- it does not contain all of<br> the capabilities defined by Shorewall version <version><br><br> where<br><br> <file> is the name of the capabilities file.<br> <version> is the current Shorewall version.<br><br> Existing capabilities files contain no CAPVERSION. When such a file<br> is read, Shorewall will issue this message:<br><br> WARNING: <file> may be not contain all of the capabilities defined<br> by Shorewall version <version><br><br>2) When a directory is specified in a command such as 'start' or<br> 'compile', Shorewall now reads the shorewall.conf file (if any) in<br> that directory before deciding which compiler to use. So if<br> SHOREWALL_COMPILER is not specified in<br> /etc/shorewall/shorewall.conf and the -C option was not specified<br> on the run-line, then if Shorewall-perl is installed, the additional<br> shorewall.conf file is read to see if it specifies a<br> SHOREWALL_COMPILER.<br><br>3) The 'save' command now uses iptables-save from the same directory<br> containing iptables. Previously, iptables-save was located via the<br> PATH setting.</pre>
|
|
<hr>
|
|
<p><strong>2007-06-17 Shorewall 3.4.4</strong></p>
|
|
<pre>Problems corrected in 3.4.4:<br><br>1) The commands "shorewall add <interface> <zone>" and "shorewall<br> delete <interface> <zone>" no longer produce spurious error<br> messages.<br><br>2) The command "shorewall delete <interface> <zone>" now actually deletes<br> entries when it successfully completes. Previously, it would appear<br> to remove an entry, even when removing that entry should fail. <br><br>3) Setting HIGH_ROUTE_MARKS=No no longer causes TC_EXPERT flagging.<br><br>4) When run as root, the 'shorewall load' and 'shorewall reload'<br> commands would fail if the LOGFILE setting in<br> /etc/shorewall/shorewall.conf specified a non-existant file.<br><br>5) Entries in /etc/shorewall/tcrules that specify both a source and<br> destination port fail with the following diagnostic:<br><br> iptables v1.3.3: multiport can only have one option<br><br>6) Previously, Shorewall-lite did not allow DHCP traffic through an<br> interface when the interface was a bridge with 'dhcp' specified<br> unless there was a bridge on the administrative system with the<br> same name.<br><br>7) SOURCE and DEST are now flagged as invalid zone name to avoid<br> problems with macros that use those names as keywords.<br><br>8) Previously, Shorewall could *increase* the MSS under some<br> circumstances. This possibility is now eliminated, provided that<br> the system has TCPMSS match support (be sure to update your<br> capabilities files!).<br><br>9) Firewall zone names other than 'fw' no longer cause a error when<br> IPSECFILE is not set or is set to 'ipsec'.<br><br>10) The 'proxyarp' option on an interface was previously ignored when<br> the /etc/shorewall/proxyarp file was empty.<br><br>11) Previously, if action 'a' was defined then the following <br> rule generated an error:<br><br> a: z1 z2 ...<br><br> The trailing ":" is now ignored.<br><br>12) Previously, if a RATE/LIMIT was specified on a REJECT rule, the<br> generated error messages referred to the rule as a DROP rule.<br><br>13) The 'nolock' keyword was previously ignored on several<br> /sbin/shorewall[-lite] commands. <br><br>Other changes in 3.4.4:<br><br>1) The accounting, masq, rules and tos files now have a 'MARK' column<br> similar to the column of the same name in the tcrules file. This<br> column allows filtering by MARK value.<br><br>2) The "shorewall show zones" command now flags zone members that have<br> been added using "shorewall add" by preceding them with a plus sign<br> ("+").<br><br> Example:<br><br> Shorewall 3.9.4 Zones at gateway - Mon May 14 07:48:16 PDT 2007<br><br> fw (firewall)<br> net (ipv4)<br> eth0:0.0.0.0/0<br> loc (ipv4)<br> br0:0.0.0.0/0<br> eth4:0.0.0.0/0<br> eth5:0.0.0.0/0<br> +eth1:0.0.0.0/0<br> dmz (ipv4)<br> eth3:0.0.0.0/0<br> vpn (ipv4)<br> tun+:0.0.0.0/0<br><br> In the above output, "eth1:0.0.0.0/0" was dynamically added to the<br> 'loc' zone. As part of this change, "shorewall delete" will only<br> delete entries that have been added dynamically. In earlier<br> versions, any entry could be deleted although the ruleset was only<br> changed by deleting entries that had been added dynamically.<br><br>3) Eariler generations of Shorewall Lite required that remote root<br> login via ssh be enabled in order to use the 'load' and 'reload'<br> commands.<br><br> Beginning with this release, you may define an alternative means<br> for accessing the remote firewall system.<br><br> Two new options have been added to shorewall.conf:<br><br> RSH_COMMAND<br> RCP_COMMAND<br><br> The default values for these are as follows:<br><br> RSH_COMMAND: ssh ${root}@${system} ${command}<br> RCP_COMMAND: scp ${files} ${root}@${system}:${destination}<br><br> Shell variables that will be set when the commands are envoked are<br> as follows:<br><br> root - root user. Normally 'root' but may be overridden using<br> the '-r' option.<br><br> system - The name/IP address of the remote firewall system.<br><br> command - For RSH_COMMAND, the command to be executed on the <br> firewall system.<br><br> files - For RCP_COMMAND, a space-separated list of files to<br> be copied to the remote firewall system.<br><br> destination - The directory on the remote system that the files <br> are to be copied into. <br><br>4) You may now select the compiler to use on the command line using<br> the '-C' option. This option is available on the following<br> commands:<br><br> check<br> compile<br> export<br> load<br> reload<br> restart<br> start<br> try<br> safe-start<br> save-restart<br><br> Example:<br><br> shorewall try -C perl .</pre>
|
|
<hr>
|
|
<p><strong>2007-06-12 New Host for www.shorewall.net and
|
|
ftp.shorewall.net</strong></p>
|
|
<pre>I'm pleased to announce that Ty Christiansen and the folks at Master Mind<br>Productions (http://mastermindpro.com) have volunteered to host<br>www.shorewall.net and ftp.shorewall.net.<br><br>The new site is up and running and I've just changed DNS to point to the new<br>server. Let me know if you experience any problems.<br><br>Please join me in thanking Ty and Master Mind for their support of the<br>Shorewall project.</pre>
|
|
<hr>
|
|
<p><strong>2007-04-30 Shorewall 3.4.3</strong></p>
|
|
<p><code>Problems corrected in Shorewall 3.4.3</code></p>
|
|
<pre><code>1) The shorecap program was not loading modules correctly.</code></pre>
|
|
<pre><code>2) The CHAIN variable is now set correctly before the 'maclog' script</code></pre>
|
|
<pre><code> is invoked.</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>3) The 'shorewall load' and 'shorewall reload' commands redundently</code></pre>
|
|
<pre><code> re-generated the capabilities file when it resided in the export</code></pre>
|
|
<pre><code> directory.</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>4) Setting LOGFILE to the value of a shell variable from the params</code></pre>
|
|
<pre><code> file now works.</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>5) The 'shorewall-lite restore' command can fail with a 'startup not</code></pre>
|
|
<pre><code> enabled' error.</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>6) When ROUTE_FILTER=Yes in shorewall.conf, Shorewall no longer clears</code></pre>
|
|
<pre><code> the rp_filter flag for all interfaces.</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>7) When LOG_MARTIANS=Yes in shorewall.conf, Shorewall no longer clears</code></pre>
|
|
<pre><code> the log_martians flag for all interfaces.</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>8) The 'shorewall add' and 'shorewall delete' commands no longer fail</code></pre>
|
|
<pre><code> with the message 'ERROR: Only one firewall zone may be defined'.</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>9) It was previously impossible to disable martian logging.</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>10) IP addresses (aliases) added by ADD_IP_ALIASES and ADD_SNAT_ALIASES</code></pre>
|
|
<pre><code> are now correctly deleted when Shorewall stops.</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>11) The 'shorewall add' and 'shorewall delete' commands no longer fail</code></pre>
|
|
<pre><code> with the error 'Only one firewall zone may be defined'.</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>12) The special 'detect' value now works correctly in the ADDRESSES</code></pre>
|
|
<pre><code> column of /etc/shorewall/masq.</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>Other changes in Shorewall 3.4.3</code></pre>
|
|
<pre><code></code></pre>
|
|
<pre><code>1) A LOCKFILE option has been added to shorewall.conf. This file is</code></pre>
|
|
<pre><code> used to serialize updates to the active firewall configuration.</code></pre>
|
|
<pre><code> If not specified, the defaults are:</code></pre>
|
|
<blockquote>
|
|
<p><code>Shorewall - /var/lib/shorewall/lock</code></p>
|
|
<p><code>Shorewall Lite - /var/lib/shorewall-lite/lock</code></p>
|
|
</blockquote>
|
|
<!-- Shorewall Release 3.0.5 -->
|
|
<hr>
|
|
<p><span style="font-weight: bold;">2007-04-08 Shorewall 3.2.10<br>
|
|
</span><span style="font-weight: bold;"></span></p>
|
|
<pre>Problems Corrected in 3.2.10<br><br>1) Previously, if a 'start' or 'restart' command failed during the<br> compilation step, /sbin/shorewall erroneously returned an exit<br> status of zero.<br><br>2) If IMPLICIT_CONTINUE=Yes was in effect, then sub-zones received the<br> implicit CONTINUE policy for their intra-zone traffic (rather than<br> the implicit ACCEPT policy for such traffic). This could cause<br> intra-zone traffic to be rejected by rules in one of the parent<br> zones.<br><br>3) The "shorewall-[lite] [re]start and stop" commands reset the<br> proxy_arp flag on all interfaces on the system making it impossible<br> to control proxy arp manually with Shorewall installed. With this<br> change, shorewall will only clear proxy arp if there were entries in<br> /etc/shorewall/proxyarp the last time that Shorewall was<br> [re]started.<br> <br>4) The /usr/share/shorewall[-lite]/modules file has been updated for<br> kernel 2.6.20.<br><br>5) The /proc/net/ip_conntrack pseudo-file has been inexplicably<br> renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli<br> library has been updated to look for both files.<br><br>6) Tunnels of type 'ipsecnat' failed to work properly due to a missing<br> rule.<br><br>7) The 'shorecap' program was not loading modules correctly. <br><span
|
|
style="font-family: sans-serif;"><span style="font-weight: bold;"></span></span></pre>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-family: sans-serif;"><span style="font-weight: bold;"></span></span><span
|
|
style="font-weight: bold;">2007-04-01 Shorewall 3.4.2<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Problems corrected in Shorewall 3.4.2<br><br>1) The /usr/share/shorewall[-lite]/modules file has been updated for<br> kernel 2.6.20.<br><br>2) The /proc/net/ip_conntrack pseudo-file has been inexplicably<br> renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli<br> library has been updated to look for both files.<br><br>3) Shoreall 3.4 was not consistent with respect to its treatment of<br> log level 'none' and 'none!' and built-in actions. In particular,<br> specifying 'none' with the Limit action produced a run-time error.<br> Shorewall now correctly suppresses generation of log messages when<br> a log level of 'none' or 'none!' is given to a built-in action.<br><br>4) Tunnels of type 'ipsecnat' would sometimes fail to work because of<br> a missing rule.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;"><span style="font-weight: bold;">2007-03-15
|
|
Shorewall 3.4.1<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Problems Corrected in 3.4.1<br><br>1) The "shorewall-[lite] [re]start and stop" commands reset the<br> proxy_arp flag on all interfaces on the system making it impossible<br> to control proxy arp manually with Shorewall installed. There was a<br> partial fix included in 3.4.0; unfortunately, it did not correct the<br> problem completely. Shorewall 3.4.1 includes the rest of the change <br> necessarey to only clear proxy arp if there were entries in<br> /etc/shorewall/proxyarp the last time that Shorewall was<br> [re]started.<br><br>2) If the log-prefix in a log message exceeded 29 characters, <br> 'shorewall restart' fails with 'truncate: command not found' and a<br> possible segmentation fault in iptables.<br><br>3) Log messages specifying a log tag had two spaces appended to the<br> log prefix. This could cause mysterious "log-prefix truncated"<br> messages. <br><br>4) When nested zones were defined in the /etc/shorewall/zones file and<br> IMPLICIT_CONTINUE=Yes was given in /etc/shorewall/shorewall.conf,<br> shell error messages ( usually '<zone>: not found' ) during<br> compilation resulted.<br><br>5) Use of CONTINUE policies lead to startup errors with a message<br> such as the following:<br><br> Applying Policies...<br> iptables v1.3.7: Couldn't load target<br> `CONTINUE':/usr/local/lib/iptables/libipt_CONTINUE.so: cannot open<br> shared object file: No such file or directory<br><br> Try `iptables -h' or 'iptables --help' for more information.<br> <br> ERROR: Command "/sbin/iptables -A net2c148 -j CONTINUE"<br> Failed<br><br>6) If there were hosts defined as 'critical' in<br> /etc/shorewall/routestopped then problems occured in two cases:<br><br> i) On a Shorewall Lite system when 'shorewall stop' or 'shorewall<br> clear' was issued.<br><br> ii) On Shorewall or Shorewall lite system when 'start' or 'restart'<br> failed during execution of the compiled script and there was no saved<br> configuration ('shorewall[-lite] save' has not been issued).<br><br> The symptoms were that the following shell messages were issued and<br> the 'critical' hosts were not enabled:<br><br> /var/lib/shorewall/.start: line nnn: source_ip_range: command not found<br> /var/lib/shorewall/.start: line nnm: dest_ip_range: command not found<br><br>Other changes in 3.4.1<br><br>1) Several changes are included which allow testing of experimental<br> versions of Shorewall on systems with 3.4.1 and later 3.4 releases<br> installed. Among these changes is the detection and reporting of<br> "Address Type Match" which may be used in future 3.4 releases.<br> These changes have no effect on normal Shorewall operation. </pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;"><span style="font-weight: bold;">2007-03-10
|
|
Shorewall 3.4.0<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Shorewall 3.4.0<br><br>Release Highlights<br><br>1) Shorewall can now be tailored to reduce its footprint on embedded<br> systems. As part of this change, actions are now completely<br> optional.<br><br> See http://www.shorewall.net/Modularization.html for details.<br><br>2) Exclusion is now possible in /etc/shorewall/hosts. This is required<br> for bridge/firewalls under kernel 2.6.20 and later.<br><br> See http://www.shorewall.net/NewBridge.html.<br><br>3) Shorewall and Shorewall Lite now include man pages. There is a <br> man page for shorewall(8), one for shorewall-lite(8) and one for<br> each configuration file. As part of this change, all documentation<br> has been removed from Shorewall configuration files. This should<br> make it easier from users to upgrade from one release to the next<br> since the configuration files will only change when column is added<br> or renamed.<br><br> See http://www.shorewall.net/manpages/Manpages.html<br><br>4) Shorewall now remembers the changes that it has made to routing as<br> a result of entries in /etc/shorewall/providers and<br> /etc/shorewall/route_rules and reverses those changes when<br> appropriate.<br><br>Problems Corrected in 3.4.0 Final.<br><br>1) In the rules file, following the action with "!" is supposed to<br> exempt the rule from being suppressed by OPTIMIZE=1. That feature<br> was not working.<br><br>2) If both a macro body and a macro invocation contained an entry in the<br> SOURCE or DEST column, then compilation failed with the error:<br><br> merge_macro_source_dest: command not found<br><br>3) An obscure bug in rule activation having to do with the new<br> exclusion feature in /etc/shorewall/hosts has been corrected.<br><br>4) The "shorewall-[lite] [re]start and stop" commands reset the<br> proxy_arp flag on all interfaces on the system making it impossible<br> to control proxy arp manually with Shorewall installed. With this<br> change, shorewall will only clear proxy arp if there were entries in<br> /etc/shorewall/proxyarp the last time that Shorewall was<br> [re]started.<br><br>New Features in Shorewall 3.4:<br><br>1) In order to accomodate small embedded applications, Shorewall 3.4<br> is now modularized. In addition to the base files, there are<br> loadable "libraries" that may be included or omitted from an<br> embedded system as required.<br><br> Loadable Shorewall libraries reside in /usr/share/shorewall/ and<br> have names that begin with "lib.". The following libraries are<br> included in Shorewall 3.4:<br><br> - lib.accounting. Must be available if you include entries in<br> /etc/shorewall/accounting.<br><br> - lib.actions. Must be available if you do not specify<br> USE_ACTIONS=No in /etc/shorewall/shorewall.conf.<br><br> - lib.base. The base Shorewall library required by all programs,<br> including compiled firewall scripts. This library is also<br> released as part of Shorewall Lite and is installed in<br> /usr/share/shorewall-lite/.<br><br> - lib.cli. Library containing the code common to /sbin/shorewall,<br> /sbin/shorewall-lite. This library is also released as part of<br> Shorewall Lite and is installed in /usr/share/shorewall-lite/.<br><br> - lib.config. Library containing the code that is common to<br> /usr/share/shorewall/compiler and /usr/share/shorewall/firewall. <br><br> - lib.dynamiczones. Must be available if you specify<br> DYNAMIC_ZONES=Yes in shorewall.conf.<br><br> - lib.maclist. Must be available if you specify the 'maclist'<br> option in /etc/shorewall/interfaces or /etc/shorewall/hosts.<br><br> - lib.nat. Must be available if you have entries in<br> /etc/shorewall/masq, /etc/shorewall/nat or /etc/shorewall/netmap<br> or if you use DNAT or REDIRECT rules.<br><br> - lib.providers. Must be available if you have entries in<br> /etc/shorewall/providers.<br><br> - lib.proxyarp. Must be available if you have entries in<br> /etc/shorewall/proxyarp or if you specify the 'proxyarp' option<br> in /etc/shorewall/interfaces.<br><br> - lib.tc. Must be available if you have entries in<br> /etc/shorewall/tcdevices and /etc/shorewall/tcclasses.<br><br> - lib.tcrules. Must be available if you have entries in<br> /etc/shorewall/tcrules.<br><br> - lib.tunnels. Must be available if you have entries in<br> /etc/shorewall/tunnels.<br><br> Embedded applications can further decrease the size of the Shorewall<br> footprint by:<br><br> - Omitting the macro files.<br> - Omitting all unused extension scripts.<br><br> See http://www.shorewall.net/Modularization.html for additional<br> details.<br><br>2) As hinted in the previous bullet, there is a new USE_ACTIONS option<br> in /etc/shorewall/shorewall.conf. Shorewall actions can be very<br> powerful but they also require a lot of code to implement. Embedded<br> applications can omit that code by setting<br> USE_ACTIONS=No. Shorewall will ignore all action-related files<br> including /usr/share/shorewall/actions.std and<br> /etc/shorewall/actions. Builtin actions will still be available for<br> use in rules and macros.<br><br> The 'Limit' action has been converted to a builtin so that Limit is<br> available even when USE_ACTIONS=No.<br><br> See the next item for more information.<br><br>3) Prior to Shorewall 3.4, default actions were specified in<br> /usr/share/shorewall/actions.std or in /etc/shorewall/actions.<br><br> This approach has two drawbacks:<br><br> a) All DROP policies must use the same default action and all<br> REJECT policies must use the same default action.<br><br> b) Now that we have modularized action processing (see the New<br> Features section below), we need a way to define default rules<br> for a policy that does not involve actions.<br><br> The solution is two-fold:<br><br> - Four new options have been added to the<br> /etc/shorewall/shorewall.conf file that allow specifying the<br> default action for DROP, REJECT, ACCEPT and QUEUE.<br><br> The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and<br> QUEUE_DEFAULT.<br><br> DROP_DEFAULT describes the rules to be applied before a<br> connection request is dropped by a DROP policy; REJECT_DEFAULT<br> describes the rules to be applied if a connection request is<br> rejected by a REJECT policy. The other two are similar for<br> ACCEPT and QUEUE policies.<br><br> The value assigned to these may be:<br><br> a) The name of an action.<br> b) The name of a macro<br> c) 'None' or 'none'<br><br> The default values are:<br><br> DROP_DEFAULT="Drop"<br> REJECT_DEFAULT="Reject"<br> ACCEPT_DEFAULT=none<br> QUEUE_DEFAULT=none<br><br> If USE_ACTIONS=Yes, then these values refer to action.Drop and<br> action.Reject respectively. If USE_ACTIONS=No, then these values<br> refer to macro.Drop and macro.Reject.<br><br> If you set the value of either option to "None" then no default<br> action will be used and the default action or macro (if any)<br> must be specified in /etc/shorewall/policy<br><br> - The POLICY column in /etc/shorewall/policy has been extended.<br><br> In /etc/shorewall/policy, when the POLICY is DROP, REJECT,<br> ACCEPT or QUEUE then the policy may be followed by ":" and one<br> of the following:<br><br> a) The word "None" or "none". This causes any default<br> action defined in /etc/shorewall/shorewall.conf<br> to be omitted for this policy.<br> b) The name of an action (requires that USE_ACTIONS=Yes<br> in shorewall.conf). That action will be invoked<br> before the policy is enforced.<br> c) The name of a macro. The rules in that macro will<br> be applied before the policy is enforced. This<br> does not require USE_ACTIONS=Yes.<<br>br><br> Example:<br><br> #SOURCE DEST POLICY LOG<br> # LEVEL<br> loc net ACCEPT<br> net all DROP:MyDrop info<br> #<br> # THE FOLLOWING POLICY MUST BE LAST<br> #<br> all all REJECT:MyReject info<br><br>4) For users whose kernel and iptables have Extended MARK Target<br> support, it is now possible to logically AND or OR a value into the<br> current packet mark by preceding the mark value (and optional mask)<br> with an ampersand ("&") or vertical bar ("|") respectively.<br><br> Example: To logically OR the value 4 into the mark value for<br> packets from 192.168.1.1:<br><br> #MARK SOURCE<br> |4 192.168.1.1<br><br>5) Previously, zone names were restricted to five characters in<br> length. That limit derives from the --log-prefix in Netfilter log<br> messages which must be 29 bytes or less in length. With the<br> standard Shorewall LOGFORMAT, that leaves 11 characters for the<br> chain name; given that many chain names are of the form<br> <zone1>2<zone2>, that gives a maximum zone name length of 5.<br><br> Beginning with this release, the maximum length of a zone name is<br> dependent on the LOGFORMAT (the maximum length may never be less<br> than 5 but it may be greater than 5). For example, setting<br> LOGFORMAT="FW:%s:%s:" will allow zone names of up to 8 characters.<br><br>6) Netfilter provides support for attachment of comments to Netfilter<br> rules. Comments can be up to 255 bytes in length and are visible<br> using the "shorewall show <chain>", "shorewall show nat",<br> "shorewall show mangle" and "shorewall dump" commands. Comments are<br> delimited by '/* ... */" in the output.<br><br> Beginning with Shorewall 3.4, you may place COMMENT lines in the<br> /etc/shorewall/rules, /etc/shorewall/tcrules, /etc/shorewall/nat<br> and /etc/shorewall/masq files and in action files. The remainder of<br> the line is treated as a comment and it will be attached as a<br> Netfilter comment to the rule(s) generated by succeding entries<br> in the file.<br><br> Note: Do not prefix the comment with "#". Shorewall's two-pass<br> compiler strips off "#" comments in the first pass and processes<br> COMMENT lines in the second pass. Hence, by the time that COMMENT<br> is processed, the "#" and everything following it has been removed<br> (see example below).<br><br> To stop the current comment from being attached to further<br> rules, simply include COMMENT on a line by itself (so that the<br> following rules will have no comment) or specify a new COMMENT.<br><br> If you do not have Comment support in your iptables/kernel (see the<br> output of "shorewall[-lite] show capabilities") then COMMENTS are<br> ignored with this warning:<br><br> COMMENT ignored -- requires comment support in iptables/Netfilter<br><br> Example from my rules file:<br><br> #SOURCE SOURCE DEST PROTO DEST PORT(S)<br><br> COMMENT Stop Microsoft Noise<br><br> REJECT loc net tcp 137,445<br> REJECT loc net udp 137:139<br><br> COMMENT # Stop comment from being attached to rules below<br><br> The output of "shorewall show loc2net" includes (folded):<br><br> 0 0 reject tcp -- * * 0.0.0.0/0<br> 0.0.0.0/0 multiport dports 137,445 /* Stop Microsoft Noise */<br> 0 0 reject udp -- * * 0.0.0.0/0<br> 0.0.0.0/0 udp dpts:137:139 /* Stop Microsoft Noise */<br><br>7) A new macro (macro.RDP) has been added for Microsoft Remote<br> Desktop. This macro was contributed by Tuomo Soini.<br><br>8) A new 'maclog' extension file has been added. This file is<br> processed just before logging based on the setting of<br> MACLIST_LOG_LEVEL is done. When the extension is invoked, the CHAIN<br> variable will contain the name of the chain where rules should be<br> inserted. Remember that if you have specified MACLIST_TABLE=mangle,<br> then your run_iptables commands should include "-t mangle".<br><br>9) The SUBNET column in /etc/shorewall/masq has been renamed SOURCE to<br> more accurately describe the contents of the column.<br><br>10) Previously, it was not possible to use exclusion in<br> /etc/shorewall/hosts. Beginning with this release, you may now use<br> exclusion lists in entries in this file. Exclusion lists are<br> discussed at:<br><br> http://www.shorewall.net/configuration_file_basics.htm#Exclusion.<br><br> Example:<br><br> loc eth0:192.168.1.0/24!192.168.1.4,192.168.1.16/28<br><br> In that example, the 'loc' zone is defined to be the subnet<br> 192.168.1.0/24 interfacing via eth0 *except* for host 192.168.1.4<br> and hosts in the sub-network 192.168.1.16/28.<br><br>11) New "shorewall[-lite] show ip" and "shorewall[-lite] show routing"<br> commands have been added. The first produces the same output as "ip<br> addr ls". The second produces a report about your routing rules and<br> tables.<br><br>12) Beginning with this release, Shorewall and Shorewall Lite will<br> share common change logs and release notes.<br><br>13) In Shorewall versions prior to 3.4, multiple jumps to a '2all'<br> chain could be generated in succession.<br><br> Example from an earlier shorewall version:<br><br> gateway:~ # shorewall-lite show eth2_fwd<br> Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 08:54:37 PDT 2006<br><br> Counters reset Thu Oct 19 08:34:47 PDT 2006<br><br> Chain eth2_fwd (1 references)<br> pkts bytes target prot opt in out source destination<br> 0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW<br> 0 0 wifi2all all -- * eth0 0.0.0.0/0 0.0.0.0/0<br> 0 0 wifi2all all -- * br0 0.0.0.0/0 0.0.0.0/0<br> 0 0 wifi2all all -- * eth3 0.0.0.0/0 0.0.0.0/0<br> 0 0 wifi2all all -- * tun+ 0.0.0.0/0 0.0.0.0/0<br> gateway:~ #<br><br> This redundancy may be eliminated by setting OPTIMIZE=1 in shorewall.conf.<br><br> gateway:~ # shorewall-lite show eth2_fwd<br> Shorewall Lite 3.4.0-Beta1 Chains eth2_fwd at gateway - Thu Oct 19 09:15:24 PDT 2006<br><br> Counters reset Thu Oct 19 09:15:19 PDT 2006<br><br> Chain eth2_fwd (1 references)<br> pkts bytes target prot opt in out source destination<br> 0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW<br> 0 0 wifi2all all -- * * 0.0.0.0/0 0.0.0.0/0<br> gateway:~ #<br><br> Note that with OPTIMIZE=1, traffic destined for an<br> interface/Address that falls outside of all defined zones may now<br> be logged out of a '2all' chain rather than out of the FORWARD<br> chain.<br><br> The OPTIMIZE setting also controls the suppression of redundant<br> wildcard rules (those specifying "all" in the SOURCE or DEST<br> column). A wildcard rule is considered to be redundant when it<br> has the same ACTION and Log Level as the applicable policy.<br><br> Example:<br><br> /etc/shorewall/policy<br><br> #SOURCE DEST POLICY LEVEL<br> loc net ACCEPT<br><br> /etc/shorewall/rules<br><br> #ACTION SOURCE DEST PROTO DEST<br> # PORT(S)<br> ...<br> ACCEPT all all icmp 8<br><br> OPTIMIZE=0<br><br> gateway:~ # shorewall show loc2net<br> Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:55:03 PDT 2006<br><br> Counters reset Thu Oct 26 07:54:58 PDT 2006<<br>br><br> Chain loc2net (1 references)<br> pkts bytes target prot opt in out source destination<br> ...<br> 0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0<br> 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8<br> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0<br><br> gateway:~<br><br> OPTIMIZE=1<br><br> gateway:~ # shorewall show loc2net<br> Shorewall Lite 3.4.0-Beta1 Chains loc2net at gateway - Thu Oct 26 07:57:12 PDT 2006<br><br> Counters reset Thu Oct 26 07:56:38 PDT 2006<br><br> Chain loc2net (1 references)<br> pkts bytes target prot opt in out source destination<br> ...<br> 0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0<br> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0<br><br> gateway:~<br><br> If you really want a rule that duplicates the policy, follow the<br> action with "!":<br><br> #ACTION SOURCE DEST PROTO DEST<br> # PORT(S)<br> ...<br> ACCEPT! all all icmp 8<br><br>14) IP Address ranges are now allowed in the drop, reject, allow and<br> logdrop shorewall[-lite] commands.<br><br>15) Previously, Shorewall has not attempted to undo the changes it has<br> made to the firewall's routing as a result of entries in<br> /etc/shorewall/providers and /etc/shorewall/routes. Beginning with<br> this release, Shorewall will attempt to undo these changes.<br><br> When Shorewall starts or is restarted and there are entries in<br> /etc/shorewall/providers, Shorewall will capture the contents<br> of /etc/shorewall/rt_tables and will restore that database when<br> Shorewall is stopped or restarted. Similarly, the default route<br> will be captured the first time that you [re]start Shorewall using<br> this version and will be restored under the following conditions:<br><br> a) shorewall stop<br> b) shorewall clear<br> c) shorewall restart or restore and there are no entries in<br> /etc/shorewall/providers.<br><br> Once the default route has been restored, Shorewall will delete<br> the saved copy so that it will once again be captured at the next<br> shorewall start or shorewall restore.<br><br>16) Shorewall no longer includes policy matches in its generated<br> ruleset when no IPSEC zones or IPSEC networks are defined (IPSEC<br> networks are defined using the 'ipsec' option in<br> /etc/shorewall/hosts).<br><br>17) The Makefile installed in /usr/share/shorewall/configfiles/ is now<br> the same one mentioned at<br> http://www.shorewall.net/CompiledPrograms.html.<br><br> Once the file is copied into an export directory, you modify the<br> setting of the HOST variable to match the name of the remote<br> firewall.<br><br> The default target is the "firewall" script so "make" compiles the<br> firewall script if any of the configuration files have<br> changed. "make install" builds "firewall" if necessary then<br> installs it on the remote firewall. "make capabilities" will<br> generate the "capabilities" file. "make save" will save the running<br> configuration on the remote firewall.<br><br>18) Shorewall and Shorewall Lite now include the following manpages. <br><br> shorewall-accounting(5)<br> shorewall-actions(5)<br> shorewall-blacklist(5)<br> shorewall.conf(5)<br> shorewall-ecn(5)<br> shorewall-exclusion(5)<br> shorewall-hosts(5)<br> shorewall-interfaces(5)<br> shorewall-lite.conf(5)<br> shorewall-lite(8)<br> shorewall-maclist(5)<br> shorewall-masq(5)<br> shorewall-nat(5)<br> shorewall-nesting(5)<br> shorewall-netmap(5)<br> shorewall-params(5)<br> shorewall-policy(5)<br> shorewall-providers(5)<br> shorewall-proxyarp(5)<br> shorewall-rfc1918(5)<br> shorewall-route_rules(5)<br> shorewall-routestopped(5)<br> shorewall-rules(5)<br> shorewall-tcclasses(5)<br> shorewall-tcdevices(5)<br> shorewall-tcrules(5)<br> shorewall-template(5)<br> shorewall-tos(5)<br> shorewall-tunnels(5)<br> shorewall(8)<br> shorewall-zones(5)<br><br> Now that the manpages are in place, command-specific help has been<br> removed since it duplicates information in the man pages.<br><br>19) From the beginning, the Shorewall configuration files in<br> /etc/shorewall/ have contained documentary comments. While these<br> comments are useful, they present an upgrade problem. Beginning<br> with this release, these comments are removed from the<br> configuration files themselves and are replaced by the manpages<br> described in the preceding release note entry.<br><br>20) Shorewall now uses tc fwmark filters to classify packets for<br> traffic shaping when the DEVICE isn't an interface described in<br> /etc/shorewall/interfaces. This is in preparation for the upcoming<br> change to the way that --physdev-out works in iptables/Netfilter;<br> that change is now scheduled for kernel 2.6.20.<br><br>21) If your kernel and iptables have extended multiport support, then<br> Shorewall will use that support for the destination port when<br> generating rules from entries in the /etc/shorewall/tcrules file.<br>22) The 'safe-start' and 'safe-restart' command have been<br> improved. Both now accept an optional directory name; if supplied,<br> Shorewall will look first in that directory for configuration<br> files.<br><br> The commands have also been enhanced to only restore the<br> configuration once in the event of a failure. Previously, if there<br> was a current 'save' command in effect, then that configuration<br> would be restored on a failure and then the last-running<br> configuration would be restored.<br><br>23) The 'try' command has been reimplemented with new semantics. <br><br> If Shorewall is started then the firewall state is saved to a<br> temporary saved configuration (/var/lib/shorewall/.try). Next, if<br> Shorewall is currently started then a restart command is issued;<br> otherwise, a start command is performed. if an error occurs during<br> the compliation phase of the restart or start, the command<br> terminates without changing the Shorewall state. If an error occurs<br> during the restart phase, then a 'shorewall restore' is performed<br> using the saved configuration. If an error occurs during the start<br> phase, then Shorewall is cleared. If the start/restart succeeds<br> and a timeout is specified then a 'clear' or 'restore' is performed<br> after timeout seconds. <br><br>24) The syntax of the 'export' command has been made slightly<br> friendlier.<br><br> The old syntax:<br><br> export <directory1> [user@]system:[<directory2>]<br><br> It is now:<br><br> export <directory1> [user@]system[:<directory2>]<br><br> In other words, if you don't need to specify <directory2>, you may<br> omit the colon (":") following the system name.<br> <br> The old syntax is still accepted -- that is, you can still <br> type:<br><br> export firewall2:<br><br> which is equivalent to<br><br> export firewall2<br><br>25) Shorewall commands may be speeded up slightly by using a<br> 'capabilities' file. The 'capabilities' file was originally<br> designed for use with Shorewall Lite and records the<br> iptables/Netfilter features available on the target system.<br><br> To generate a capabilities file, execute the following command as<br> root:<br><br> shorewall show -f capabilities > /etc/shorewall/capabil<br>ities<br><br> When you install a new kernel and/or iptables, be sure to generate<br> a new capabilities file.<br> <br>26) When syslogd is run with the -C option (which in some<br> implementations causes syslogd to log to an in-memory circular<br> buffer), /sbin/shorewall will now use the 'logread' command to read<br> the log from that buffer. This is for combatibility with OpenWRT.<br><br>27) There is now a ":T" qualifier in /etc/shorewall/tcrules which<br> causes the resulting rule to be inserted into the POSTROUTING<br> chain.<br><br>28) The program /usr/share/shorewall/wait4ifup can be used to wait for<br> a network device (such as a ppp device) to reach the UP state. <br> <br> /usr/share/shorewall/wait4ifup <interface> [ <seconds> ]<br><br> The program will wait for up to <seconds> seconds for the <br> named <interface> to reach the UP state. If <seconds> is not given,<br> 60 seconds is assumed.<br><br> The exit status is zero if <interface> comes up within <seconds><br> seconds and non-zero otherwise.<br><br>29) Previously, 'ipsecnat' tunnels allowed AH traffic by default<br> (unless 'isecnat:noah' was given). Given that AH is incompatible<br> with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.<br><br>30) Shorewall now generates half as many rules as previously in the<br> 'blacklst' chain when BLACKLIST_LOGLEVEL is specified.<br><br>31) Beginning with Shorewall 3.4.0, if EXPORTPARAMS=No in<br> shorewall.conf then Shorewall will not process<br> /etc/shorewall/params when the compiled script is run. With<br> EXPORTPARAMS=No, any shell variables needed at run-time must be set<br> in /etc/shorewall/init.<br><br> In a Shorewall/Shorewall Lite environment, this allows<br> /etc/shorewall/params to be written to run exclusively<br> on the administrative system while /etc/shorewall/init runs<br> exclusively on the firewall system.<br><br> So shell variables required at compile time may be set in<br> /etc/shorewall/params and those required at run-time may be set in<br> /etc/shorewall/init.<br><br> Note 1: If you need shell variables values in your<br> /etc/shorewall/stop or /etc/shorewall/stopped script, then you need<br> to set their values in /etc/shorewall/stop. /etc/shorewall/init is<br> not invoked during processing of the 'stop' and 'clear' commands.<br><br> Note 2: EXPORTPARAMS was actually introduced in Shorewall version<br> 3.2.9. It is described here for the benefit of those who did not<br> install that version.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;"><span style="font-weight: bold;">Old
|
|
News <a href="oldnews.html">here</a><br>
|
|
</span>
|
|
</body>
|
|
</html>
|