mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-17 20:01:09 +01:00
8c2535c8eb
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@7415 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
1895 lines
104 KiB
HTML
1895 lines
104 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>
|
|
<span style="font-weight: bold;">Tom Eastep<br>
|
|
<br>
|
|
</span>Copyright © 2001-2007 Thomas M. Eastep<br>
|
|
|
|
|
|
<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 class="quote"><a
|
|
href="GnuCopyright.htm" target="_self">GNU Free Documentation
|
|
License</a></span>”.<br>
|
|
</p>
|
|
|
|
<p>October 02, 2007</p>
|
|
<hr style="width: 100%; height: 2px;">
|
|
|
|
<p><strong>2007-10-02 Shorewall 3.4.7</strong></p>
|
|
<pre>Problems Corrected in Shorewall 3.4.7
|
|
|
|
1) A bug prevented proper handling of PREROUTING marks when
|
|
HIGH_ROUTE_MARKS=No and the track option was specified in
|
|
/etc/shorewall/providers.
|
|
|
|
2) Previously, if the following sequence of routing rules was
|
|
specified, then the first rule would always be omitted.
|
|
|
|
#SOURCE DEST PROVIDER PRIORITY
|
|
$SRC_A $DESTIP1 ISP1 1000
|
|
$SRC_A $DESTIP2 SOMEISP 1000
|
|
$SRC_A - ISP2 1000
|
|
|
|
The reason for this omission was that Shorewall uses a
|
|
delete-before-add approach and attempting to delete the third rule
|
|
resulted in the deletion of the first one instead.
|
|
|
|
This problem occurred with both compilers.
|
|
|
|
3) When using Shorewall-shell, provider numbers were not recognized in
|
|
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
|
|
|
|
1) If no interface had the 'blacklist' option, then when using
|
|
Shorewall-perl, the 'start' and 'restart' command failed:
|
|
|
|
ERROR: No filter chain found with name blacklst
|
|
|
|
New Shorewall-perl 4.0.3 packages were released that corrected this
|
|
problem; it is included here for completeness.
|
|
|
|
2) If no interface had the 'blacklist' option, then when using
|
|
Shorewall-perl, the generated script would issue this harmless
|
|
message during 'shorewall refresh':
|
|
|
|
chainlist_reload: Not found
|
|
|
|
3) If /bin/sh was a light-weight shell such as ash or dash, then
|
|
'shorewall refresh' failed.
|
|
|
|
4) During start/restart, the script generated by Shorewall-perl was
|
|
clearing the proxy_arp flag on all interfaces; that is not the
|
|
documented behavior.
|
|
|
|
5) If the module-init-tools package was not installed and
|
|
/etc/shorewall/modules did not exist or was non-empty, then
|
|
Shorewall-perl would fail with the message:
|
|
|
|
ERROR: Can't run lsmod : /etc/shorewall/modules (line 0)
|
|
|
|
6) Shorewall-perl now makes a compile-time check to insure that
|
|
iptables-restore exists and is executable. This check is made when
|
|
the compiler is being run by root and the -e option is not
|
|
given.
|
|
|
|
Note that iptables-restore must reside in the same directory as the
|
|
iptables executable specified by IPTABLES in shorewall.conf or
|
|
located by the PATH in the event that IPTABLES is not specified.
|
|
|
|
7) When using Shorewall-perl, if an action was invoked with more than
|
|
10 different combinations of log-levels/tags, some of those
|
|
invocations would have incorrect logging.
|
|
|
|
8) Previously, when 'shorewall restore' was executed, the
|
|
iptables-restore utility was always located using the PATH setting
|
|
rather than the IPTABLES setting.
|
|
|
|
With Shorewall-perl, the IPTABLES setting is now used to locate
|
|
this utility during 'restore' as it is during the processing of
|
|
other commands.
|
|
|
|
9) Although the shorewall.conf manpage indicates that the value
|
|
'internal' is allowed for TC_ENABLED, that value was previously
|
|
rejected ('Internal' was accepted).
|
|
|
|
10) The meaning of the 'loose' provider option was accidentally reversed
|
|
in Shorewall-perl. Rather than causing certain routing rules to be
|
|
omitted when specified, it actually caused them to be added (these
|
|
rules were omitted when the option was NOT specified).
|
|
|
|
11) If the 'bridge' option was specified on an interface but there were
|
|
no bport zones, then traffic originating on the firewall was not
|
|
passed through the accounting chain.
|
|
|
|
12) In commands such as:
|
|
|
|
shorewall compile <directory>
|
|
shorewall restart <directory>
|
|
shorewall check <directory>
|
|
|
|
if the name of the <directory> contained a period ("."), then
|
|
Shorewall-perl would incorrectly substitute the current working
|
|
directory for the name.
|
|
|
|
13) Previously, if the following sequence of routing rules was
|
|
specified, then the first rule would always be omitted.
|
|
|
|
#SOURCE DEST PROVIDER PRIORITY
|
|
$SRC_A $DESTIP1 ISP1 1000
|
|
$SRC_A $DESTIP2 SOMEISP 1000
|
|
$SRC_A - ISP2 1000
|
|
|
|
The reason for this omission was that Shorewall uses a
|
|
delete-before-add approach and attempting to delete the third rule
|
|
resulted in the deletion of the first one instead.
|
|
|
|
This problem occurred with both compilers.
|
|
|
|
14) When using Shorewall-shell, provider numbers were not recognized in
|
|
the PROVIDER column of /etc/shorewall/route_rules.
|
|
|
|
15) An off-by-one problem in Shorewall-perl caused the value 255 to be
|
|
rejected in the MARK column of /etc/shorewall/tcclasses.
|
|
|
|
16) When HIGH_ROUTE_MARKS=Yes, marks with values > 255 must be a
|
|
multiple of 256. That restriction was being enforced by
|
|
Shorewall-shell but not by Shorewall-perl. Shorewall-perl now also
|
|
enforces this restriction.
|
|
|
|
17) Using REDIRECT with a parameterized macro (e.g., DNS/REDIRECT)
|
|
failed with an "Unknown interface" error when using Shorewall-perl.
|
|
|
|
Other Changes in Shorewall 4.0.4
|
|
|
|
1) The detection of 'Repeat Match' has been improved. 'Repeat Match'
|
|
is not a match at all but rather is a feature of recent versions of
|
|
iptables that allows a particular match to be used multiple times
|
|
within a single rule.
|
|
|
|
Example:
|
|
|
|
-A foo -m physdev --physdev-in eth0 -m physdev --physdev-out ...
|
|
|
|
When using Shorewall-shell, the availability of 'Repeat Match' can
|
|
speed up compilation very slightly.
|
|
|
|
2) Apparently recent Fedora releases are broken. The
|
|
following sequence of commands demonstrates the problem:
|
|
|
|
ip rule add from 1.1.1.1 to 10.0.0.0/8 priority 1000 table 5
|
|
ip rule add from 1.1.1.1 to 0.0.0.0/0 priority 1000 table main
|
|
ip rule del from 1.1.1.1 to 0.0.0.0/0 priority 1000
|
|
|
|
The third command should fail but doesn't; instead, it incorrectly
|
|
removes the rule added by the first command.
|
|
To work around this issue, you can set DELETE_THEN_ADD=No in
|
|
shorewall.conf which prevents Shorewall from deleting ip rules
|
|
before attempting to add a similar rule.
|
|
|
|
3) When using Shorewall-perl, the following message is now issued if
|
|
the 'detectnets' option is specified in /etc/shorewall/interfaces:
|
|
|
|
WARNING: Support for the 'detectnets' option will be removed from
|
|
Shorewall-perl in version 4.0.5; better to use 'routefilter' and
|
|
'logmartians
|
|
|
|
The 'detect' options has always been rather silly. On input, it
|
|
duplicates the function of 'routefilter'. On output, it is a no-op
|
|
since traffic that doesn't match a route out of an interface won't
|
|
be sent through that interface (duh!).
|
|
|
|
Beginning with Shorewall 4.0.5, the warning message will read:
|
|
|
|
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
|
|
|
|
1) Using the LOG target in the rules file could result in two LOG
|
|
rules being generated by Shorewall-shell. Additionally, using an IP
|
|
address range in a rule that performed logging could result in an
|
|
invalid iptables command.
|
|
|
|
2) Shorewall now loads the act_police kernel module needed by traffic
|
|
shaping.
|
|
|
|
3) Previously, "shorewall show -f capabilities" and "shorecap" omitted
|
|
the "TCPMSS Match" capability. This made it appear to a compiler
|
|
using a capabilities file that the TCPMSS Match capability was not
|
|
available.
|
|
|
|
4) Previously, Shorewall would truncate long log prefixes to 29
|
|
characters. This resulted in there being no space between the log
|
|
prefix and the IN= part of the message.
|
|
|
|
Example: fw2net:LOG:HTTPSoutIN= OUT=eth0
|
|
|
|
Beginning with this release, Shorewall will truncate the prefix to
|
|
28 bytes and add a trailing space.
|
|
|
|
Example: fw2net:LOG:HTTPSou IN= OUT=eth0
|
|
|
|
5) Previously, if:
|
|
|
|
- FASTACCEPT=No
|
|
- The policy from Z1 to Z2 was CONTINUE
|
|
- Neither Z1 nor Z2 had parent zones
|
|
- There were no Z1->Z2 rules
|
|
|
|
then connections from Z2->Z1 would fail even if there were
|
|
rules/policies allowing them. This has been
|
|
corrected.
|
|
|
|
6) The 'shorewall add' and 'shorewall delete' command would fail when:
|
|
|
|
- The running configuration was compiled with Shorewall-perl.
|
|
- The name of the interface specified in the command contained an
|
|
embedded special character such as '.' or '-'.
|
|
|
|
This problem was the result of the change in Shorewall 4.0.2 that
|
|
removed the legacy mapping of interface names when embedding such
|
|
names in a Netfilter chain name. To correct the problem, the
|
|
pre-4.0.2 name mapping is restored when DYNAMIC_ZONES=Yes.
|
|
|
|
5) A bug in Shorewall-shell prevented proper handling of PREROUTING
|
|
marks when HIGH_ROUTE_MARKS=No and the track option was specified
|
|
in /etc/shorewall/providers.
|
|
|
|
6) With Shorewall-perl, if EXPORTPARAMS=Yes then INCLUDE directives in
|
|
the params file would fail at script execution time with "INCLUDE:
|
|
not found". This has been corrected.
|
|
|
|
7) Shorewall-perl was mis-sorting the zone list when zones were nested
|
|
more than one deep.
|
|
|
|
8) Stale references to http://www.shorewall.net/Documentation.htm have
|
|
been removed from the config files (including samples). That URL
|
|
has been replaced by the online manpages.
|
|
|
|
Other Changes in 4.0.3
|
|
|
|
1) A script generated by Shorewall-perl now tries to modify/restore
|
|
/etc/iproute2/rt_tables only if the file is writable. This prevents
|
|
run-time errors when /etc is mounted read-only.
|
|
|
|
A new KEEP_RT_TABLES option has been added to shorewall.conf. When
|
|
set to Yes, this option prevents Shorewall from altering the
|
|
/etc/iproute2/rt_tables database. The KEEP_RT_TABLES option is only
|
|
recognized by Shorewall-perl and is ignored by Shorewall-shell.
|
|
|
|
2) Shorewall-perl now requires the FindBin Perl module.
|
|
|
|
3) When an optional provider is not available, a script generated by
|
|
Shorewall-perl will no longer add the corresponding
|
|
routing rules.
|
|
|
|
4) A new 'isusable' extension script has been added. This script
|
|
allows you to extend the availability test that Shorewall performs
|
|
on optional providers.
|
|
|
|
Here's an example that uses ping to ensure that the default
|
|
gateways through eth0 and eth1 are reachable:
|
|
|
|
case $1 in
|
|
eth0)
|
|
ping -c 4 -I eth0 206.124.146.254 > /dev/null 2>&1
|
|
return
|
|
;;
|
|
eth1)
|
|
ping -c 4 -I eth1 192.168.12.254 > /dev/null 2>&1
|
|
return
|
|
;;
|
|
*)
|
|
# Assume we don't need to do any additional testing
|
|
# for this interface beyond Shorewall's
|
|
return 0
|
|
;;
|
|
esac
|
|
|
|
Additional information is available at
|
|
http://www.shorewall.net/shorewall_extension_scripts.htm.
|
|
|
|
5) Processing of the message log in the 'show log', 'logwatch' and
|
|
'dump' commands has been speeded up thanks to a suggestion by
|
|
Andrew Suffield.
|
|
|
|
6) Beginning with Shorewall 4.0, the shorewall 'stop', and 'clear'
|
|
commands were processed by the generated script from the
|
|
last successful 'start', 'restart' or 'refresh' command. This had
|
|
the side effect that updates to the /etc/shorewall/routestopped
|
|
file did not take effect until one of those three commands was
|
|
successfully processed.
|
|
|
|
Beginning with Shorewall 4.0.3, the old 3.x behavior is restored as
|
|
the default and the 4.0 behavior is enabled using the '-f' command
|
|
option.
|
|
|
|
Example: shorewall stop -f
|
|
|
|
is only recognized by Shorewall-perl and causes Shorewall to set
|
|
the MSS field in forwarded TCP SYN packets going in or out the
|
|
interface to the value that you specify.
|
|
|
|
Example:
|
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
|
vpn ppp0 - mss=1400
|
|
|
|
The mss option only affects incoming traffic that has not been
|
|
decrypted by IPSEC and outgoing traffic that will not subsequently
|
|
be encrypted by IPSEC. The MSS for IPSEC traffic is managed by the
|
|
'mss' option in /etc/shorewall/zones.
|
|
|
|
8) Shorewall now detects the presence of the 'hashlimit match'
|
|
capability. There is no builtin support yet for hashlimit but
|
|
detection allows extension scripts for user-supplied actions to
|
|
determine if the capability exists.
|
|
|
|
With Shorewall-shell, $HASHLIMIT_MATCH will be non-empty if the
|
|
capability exists.
|
|
|
|
With Shorewall-perl, $capabilities{HASHLIMIT_MATCH} will be true in
|
|
a boolean context if the capability exists. Shorewall-perl users
|
|
may also code the following in their extension script:
|
|
|
|
use Shorewall::Config;
|
|
|
|
require_capability( 'HASHLIMIT_MATCH', #Capability
|
|
'My hashlimit action' , #Feature requiring
|
|
#capability
|
|
's' ); #Feature is singular
|
|
#(if plural, pass the
|
|
empty string)
|
|
|
|
That call would procduce the following fatal error if the
|
|
capability isn't available:
|
|
|
|
ERROR: My hashlimit action requires the Hashlimit match capability
|
|
in your kernel and iptables
|
|
|
|
9) NFQUEUE support has been added to Shorewall-perl.
|
|
|
|
NFQUEUE may appear in actions, macros, rules and as a policy.
|
|
When NFQUEUE is used by itself, queue number zero is assumed. To
|
|
specify a queue number, follow NFQUEUE by a slash ("/") and the
|
|
queue number.
|
|
|
|
Examples (/etc/shorewall/rules):
|
|
|
|
NFQUEUE loc net tcp #Queue number 0
|
|
NFQUEUE/22 loc net udp #Queue number 22
|
|
NFQUEUE/22:info loc net gre #With logging
|
|
|
|
An NFQUEUE_DEFAULT option has been added to shorewall.conf for
|
|
specifying the default action to use with NFQUEUE policies.
|
|
|
|
Use of NFQUEUE requires the NFQUEUE Target capability in your
|
|
kernel/iptables. If you intend to use NFQUEUE with Shorewall-lite,
|
|
then you must install Shorewall-lite 4.0.3 in order to build a
|
|
capabilities file that includes NFQUEUE Target. If your
|
|
capabilities file was generated by a Shorewall/Shorewall-lite
|
|
version earlier that 4.0.3, you will receive a warning during
|
|
compilation.
|
|
|
|
10) The 'refresh' command can now refresh chains other than 'blacklst'.
|
|
|
|
The syntax of the command is now:
|
|
|
|
shorewall refresh [ <chain> ... ]
|
|
|
|
If no <chain> is given then 'blacklst' is assumed. Otherwise, the
|
|
Shorewall-perl compiler compiles a script whose 'refresh' command
|
|
refreshes the listed <chain>(s).
|
|
|
|
The listed chains are assumed to be in the filter table. You can
|
|
refresh chains in other tables by prefixing the chain name with the
|
|
table name followed by ":" (e.g., nat:net_dnat). Chain names which
|
|
follow are assumed to be in that table until the end of the list or
|
|
until an entry in the list names another table.
|
|
|
|
This feature requires Shorewall-perl 4.0.3 as well as
|
|
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.
|
|
|
|
1) If the "Mangle FORWARD Chain" capability was supported, entries in
|
|
the /etc/shorewall/ecn file would cause invalid iptables
|
|
commands to be generated.
|
|
|
|
2) Certain errors occurring during
|
|
start/restart/safe-start/safe-restart/try processing could cause
|
|
the lockfile to be left behind. This resulted in a 60-second delay
|
|
the next time one of these commands was run.
|
|
|
|
3) It was not previously possible to define traffic shaping on a
|
|
bridge port; the generated script complained that the
|
|
interface was not up and configured.
|
|
|
|
4) Previously, using a port list in the DEST PORT(S) column of the
|
|
rules file or in an action file caused an invalid iptables command
|
|
to be generated.
|
|
|
|
5) Using the LOG target in the rules file could result in two LOG
|
|
rules being generated. Additionally, using an IP address range in a
|
|
rule that performed logging could result in an invalid iptables
|
|
command.
|
|
|
|
6) Shorewall now loads the act_police kernel module needed by traffic
|
|
shaping.
|
|
|
|
7) Previously, "shorewall show -f capabilities" and "shorecap" omitted
|
|
the "TCPMSS Match" capability. This made it appear to a compiler
|
|
using a capabilities file that the TCPMSS Match capability was not
|
|
available.
|
|
|
|
8) Previously, Shorewall would truncate long log prefixes to 29
|
|
characters. This resulted in there being no space between the log
|
|
prefix and the IN= part of the message.
|
|
|
|
Example: fw2net:LOG:HTTPSoutIN= OUT=eth0
|
|
|
|
Beginning with this release, Shorewall will truncate the prefix to
|
|
28 bytes and add a trailing space.
|
|
|
|
Example: fw2net:LOG:HTTPSou IN= OUT=eth0
|
|
|
|
9) Previously, if:
|
|
|
|
- FASTACCEPT=No
|
|
- The policy from Z1 to Z2 was CONTINUE
|
|
- Z1 and Z2 were orphans (neither had parent zones)
|
|
- There were no Z1->Z2 rules
|
|
|
|
then connections from Z2->Z1 would fail even if there were
|
|
rules/policies allowing them. This has been
|
|
corrected.
|
|
|
|
Other changes in 3.4.6.
|
|
|
|
1) Processing of the message log in the 'show log', 'logwatch' and
|
|
'dump' commands has been speeded up thanks to a suggestion by
|
|
Andrew Suffield.</pre>
|
|
<hr>
|
|
|
|
<p><strong>2007-08-10 Shorewall 4.0.2</strong></p>
|
|
<pre>Problems corrected in 4.0.2
|
|
|
|
1) The Shorewall-perl compiler was still generating invalid
|
|
iptables-restore input from entries in /etc/shorewall/ecn.
|
|
|
|
2) When using Shorewall-perl, unless an interface was specified as
|
|
'optional' in the interfaces file, the 'restore' command would
|
|
fail if the routes through the interface or the addresses on the
|
|
interface could not be detected.
|
|
|
|
Route detection occurs when the interface is named in the SOURCE
|
|
column of the masq file. Address detection occurs when
|
|
DETECT_DNAT_IPADDRS=Yes and the interface is the SOURCE for a DNAT
|
|
or REDIRECT rule or when 'maclist' is specified for the interface.
|
|
|
|
Since the 'restore' command doesn't use the detected information,
|
|
detection is now skipped if the command is 'restore'.
|
|
|
|
3) It was not previously possible to define traffic shaping on a
|
|
bridge port; the generated script complained that the
|
|
interface was not up and configured.
|
|
|
|
4) When Shorewall-shell was not installed, certain options in
|
|
/etc/shorewall/interfaces and /etc/shorewall/hosts would cause the
|
|
'add' and 'delete' commands to fail with a missing library error.
|
|
|
|
OPTION FILE
|
|
maclist interfaces,hosts
|
|
proxyarp interfaces
|
|
|
|
5) The /var/lib/shorewall/zones file was being overwritten during
|
|
processing of the 'refresh' command by a script generated with
|
|
Shorewall-perl. The result was that hosts previously added to
|
|
dynamic zones could not be deleted after the 'refresh'.
|
|
|
|
6) If the file named as the output file in a Shorewall-perl 'compile'
|
|
command was a symbolic link, the generated error message
|
|
erroneously stated that the file's parent directory was a symbolic
|
|
link.
|
|
|
|
As part of this change, cosmetic changes were made to a number of
|
|
other error messages.
|
|
|
|
7) Some intra-zone rules were missing when a zone involved multiple
|
|
interfaces or when a zone included both IPSEC and non-IPSEC
|
|
networks.
|
|
|
|
8) Shorewall was not previously loading the xt_multiport kernel
|
|
module.
|
|
|
|
9) The Russian and French translations no longer have English headings
|
|
on notes, cautions, etc..
|
|
|
|
10) Previously, using a port list in the DEST PORT(S) column of the
|
|
rules file or in an action file could cause an invalid iptables
|
|
command to be generated by Shorewall-shell.
|
|
|
|
11) If there were no bridges in a configuration, Shorewall-perl would
|
|
ignore the CHAIN column in /etc/shorewall/accounting.
|
|
|
|
Other changes in 4.0.2
|
|
|
|
1) Shorewall-perl now detects when a port range is included in a list
|
|
of ports and iptables/kernel support for Extended Multi-port Match
|
|
is not available. This avoids an iptables-restore failure at
|
|
run-time.
|
|
|
|
2) Most chains created by Shorewall-shell have names that can be
|
|
embedded within shell variable names. This is a workaround for
|
|
limitations in the shell programming language which has no
|
|
equivalent to Perl hashes. Often chain names must have the name of
|
|
a network interface encoded in them. Given that interface names can
|
|
contain characters that are invalid in a shell variable name,
|
|
Shorewall-shell performs a name mapping which was carried forward to
|
|
Shorewall-perl:
|
|
|
|
- Trailing '+' is dropped.
|
|
- The characters ".", "-", "%' and "@" are translated to "_".
|
|
|
|
This mapping has been elminated in the 4.0.2 release of Shorewall-
|
|
perl. So where before you would see chain "eth0_0_in", you may now
|
|
see the same chain named "eth0.0_in". Similarly, a chain previously
|
|
named "ppp_fwd" may now be called "ppp+_fwd".
|
|
|
|
3) Shorewall-perl now uses the contents of the BROADCAST column in
|
|
/etc/shorewall/interfaces when the Address Type match capability is
|
|
not available.</pre>
|
|
<hr>
|
|
|
|
<p><strong>2007-07-30 Shorewall 4.0.1</strong></p>
|
|
<pre>Problems corrected in 4.0.1.
|
|
|
|
1) The Shorewall Lite installer was producing an empty shorewall-lite
|
|
manpage. Since the installer runs as part of creating the RPM, the
|
|
RPM also suffered from this problem. The 4.0.0 Shorewall-lite
|
|
packages were re-uploaded with this problem corrected.
|
|
|
|
2) The Shorewall Lite uninstaller incorrectly removed /sbin/shorewall
|
|
rather than /sbin/shorewall-lite.
|
|
|
|
3) Both the Shorewall and Shorewall Lite uninstallers did a "shorewall
|
|
clear" if Shorewall [Lite] was running. Now, the Shorewall Lite
|
|
uninstaller correctly does "shorewall-lite clear" and both
|
|
uninstallers only perform the 'clear' operation if the other
|
|
product is not installed. This prevents the removal of one of the
|
|
two products from clearing the firewall configuration established
|
|
by the other one.
|
|
|
|
4) The 'ipsec' OPTION in /etc/shorewall/hosts was mis-handled by
|
|
Shorewall-perl. If the zone type was changed to 'ipsec' or
|
|
'ipsec4' and the 'ipsec' option removed from the hosts file entry,
|
|
the configuration worked properly.
|
|
|
|
5) If a CLASSID was specified in a tcrule and TC_ENABLED=No, then
|
|
Shorewall-perl produced the following:
|
|
|
|
Compiling...
|
|
Use of uninitialized value in string ne at /usr/share/shorewall-perl/Shorewall/Tc.pm line 285, <$currentfile> line 18.
|
|
ERROR: Class Id n:m is not associated with device eth0 : /etc/shorewall/tcrules (line 18)
|
|
|
|
6) If IPTABLES was not specified in shorewall.conf, Shorewall-perl was
|
|
locating the binary using the PATH environmental variable rather
|
|
than the PATH setting in shorewall.conf. If no PATH was available
|
|
when Shorewall-perl was run and IPTABLES was not set in
|
|
shorewall.conf, the following messages were issued:
|
|
|
|
Use of uninitialized value in split at /usr/share/shorewall-perl/Shorewall/Config.pm line 1054.
|
|
ERROR: Can't find iptables executable
|
|
ERROR: Shorewall restart failed
|
|
|
|
7) If the "Mangle FORWARD Chain" capability was supported, entries in
|
|
the /etc/shorewall/ecn file would cause invalid iptables commands
|
|
to be generated. This problem occurred with both compilers.
|
|
|
|
8) Shorewall now starts at reboot after an upgrade from shorewall <
|
|
4.0.0. Previously, Shorewall was not started automatically at
|
|
reboot after an upgrade using the RPMs.
|
|
|
|
9) Shorewall-perl was generating invalid iptables-restore input when a
|
|
log level was specified with the dropBcast and allowBcast builtin
|
|
actions and when a log level followed by '!' was used with any
|
|
builtin actions.
|
|
|
|
10) Shorewall-perl was incorrectly rejecting 'min' as a valid unit of
|
|
time in rate-limiting specifications.
|
|
|
|
11) Certain errors occurring during
|
|
start/restart/safe-start/safe-restart/try processing could cause
|
|
the lockfile to be left behind. This resulted in a 60-second delay
|
|
the next time one of these commands was run.
|
|
|
|
Other changes in Shorewall 4.0.1.
|
|
|
|
1) A new EXPAND_POLICIES option is added to shorewall.conf. The
|
|
option is recognized by Shorewall-perl and is ignored by
|
|
Shorewall-shell.
|
|
|
|
Normally, when the SOURCE or DEST columns in shorewall-policy(5)
|
|
contains 'all', a single policy chain is created and the policy is
|
|
enforced in that chain. For example, if the policy entry is
|
|
|
|
#SOURCE DEST POLICY LOG
|
|
# LEVEL
|
|
net all DROP info
|
|
|
|
then the chain name is 'net2all' which is also the chain named in
|
|
Shorewall log messages generated as a result of the policy. If
|
|
EXPAND_POLICIES=Yes, then Shorewall-perl will create a separate
|
|
chain for each pair of zones covered by the policy. This makes the
|
|
resulting log messages easier to interpret since the chain in the
|
|
messages will have a name of the form 'a2b' where 'a' is the SOURCE
|
|
zone and 'b' is the DEST zone. See
|
|
http://linuxman.wikispaces.com/PPPPPPS for more information.
|
|
|
|
2) The Shorewall-perl dependency on the "Address Type Match"
|
|
capability has been relaxed. This allows Shorewall 4.0.1 to be used
|
|
on releases like RHEL4 that don't support that capability.
|
|
|
|
3) Shorewall-perl now detects dead policy file entries that result
|
|
when an entry is masked by an earlier entry. Example:
|
|
|
|
all all REJECT info
|
|
loc net ACCEPT
|
|
|
|
4) Recent kernels are apparently hard to configure and we have been
|
|
seeing a lot of problem reports where the root cause is the lack of
|
|
state match support in the kernel. This problem is difficult to
|
|
diagnose when using Shorewall-perl so the generated shell program
|
|
now checks specifically for this problem and terminates with an
|
|
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>----------------------------------------------------------------------------
|
|
R E L E A S E H I G H L I G H T S
|
|
----------------------------------------------------------------------------
|
|
1) This is the first Shorewall release that fully integrates the new
|
|
Shorewall-perl compiler. See the "New Features" section below.
|
|
|
|
2) You are now offered a choice as to which compiler(s) you install. In
|
|
4.0.0, there are the following packages:
|
|
|
|
- Shorewall-common ( common files )
|
|
- Shorewall-shell ( the shell-based compiler )
|
|
- Shorewall-perl (the Perl-based compiler )
|
|
|
|
You must install at least one of the compiler packages (you may
|
|
install them both) along with Shorewall-common.
|
|
|
|
YOU DO NOT NEED TO UNINSTALL ANY OF YOUR CURRENT PACKAGES.
|
|
|
|
See the Migration Considerations below for further information.
|
|
|
|
3) The facilities for supporting bridge/firewalls under earlier
|
|
releases are deprecated and their documentation is omitted from the
|
|
4.0 distribution. New bridge support is implemented in the
|
|
Shorewall-perl compiler. This support utilizes the reduced-function
|
|
physdev match support available in Linux kernel 2.6.20 and later.
|
|
|
|
Problems corrected in 4.0.0 Final.
|
|
|
|
1) The shorewall-lite install.sh may now be run multiple times from
|
|
the same directory. Previously, the manpages were gzipped in-place
|
|
which made it impossible to rerun the script.
|
|
|
|
2) If shorewall.conf contained SHOREWALL_COMPILER=shell (which it can
|
|
on Shorewall 3.4.2-4 systems) and the shorewall-shell RPM was
|
|
removed, subsequent "shorewall [re]start" operations failed. When
|
|
shorewall-shell is removed, the shorewall.conf file is modified to
|
|
specify SHOREWALL_COMPILER= and the original is saved in
|
|
shorewall.conf.rpmsave.
|
|
|
|
3) The contents of the LOG LEVEL column in /etc/shorewall/policy are
|
|
now validated at compile time by Shorewall-perl.
|
|
|
|
Other changes in Shorewall 4.0.0 Final.
|
|
|
|
1) The Perl modules in /usr/share/shorewall-perl/Shorewall/ have been
|
|
consolidated somewhat, leading to slightly faster compilation.
|
|
|
|
Migration Considerations:
|
|
|
|
1) Beginning with Shorewall 4.0.0, there is no single 'shorewall'
|
|
package. Rather there are two compiler packages (shorewall-shell
|
|
and shorewall-perl) and a set of base files (shorewall-common)
|
|
which are required by either compiler package.
|
|
|
|
Although the names of the packages are changing, you can upgrade
|
|
without having to uninstall/reinstall.
|
|
|
|
To repeat: YOU DO NOT NEED TO UNINSTALL ANY EXISTING PACKAGE.
|
|
|
|
If you attempt to upgrade using the shorewall-common RPM, you get
|
|
this result:
|
|
gateway:~ # rpm -Uvh shorewall-common-4.0.0.noarch.rpm
|
|
error: Failed dependencies:
|
|
shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch
|
|
gateway:~ #
|
|
|
|
You must either:
|
|
|
|
rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \
|
|
shorewall-common-4.0.0.noarch.rpm
|
|
|
|
or
|
|
|
|
rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \
|
|
shorewall-perl-4.0.0.noarch.rpm \
|
|
shorewall-common-4.0.0.noarch.rpm
|
|
|
|
If you don't want to use shorewall-perl exclusively then use the
|
|
second command above then
|
|
|
|
rpm -e shorewall-shell
|
|
|
|
If you are upgrading using the tarball, you must install
|
|
shorewall-shell and/or shorewall-perl before you upgrade
|
|
using shorewall-common. Otherwise, the install.sh script fails with:
|
|
|
|
ERROR: No Shorewall compiler is installed
|
|
|
|
The shorewall-shell and shorewall-perl packages are installed from
|
|
the tarball in the expected way; untar the package, and run the
|
|
install.sh script.
|
|
|
|
Example 1: You have 'shorewall' installed and you want to continue
|
|
to use the shorewall-shell compiler.
|
|
|
|
tar -jxf shorewall-common-4.0.0.tar.bz2
|
|
tar -jxf shorewall-shell-4.0.0.tar.bz2
|
|
|
|
cd shorewall-shell-4.0.0
|
|
./install.sh
|
|
cd ../shorewall-common-4.0.0
|
|
./install.sh
|
|
shorewall check
|
|
shorewall restart
|
|
|
|
Example 2: You have shorewall 3.4.4 and shorewall-perl 4.0.0-Beta7
|
|
installed and you want to upgrade to 4.0. You do not need the
|
|
shell-based compiler.
|
|
|
|
tar -jxf shorewall-common-4.0.0.tar.bz2
|
|
tar -jxf shorewall-perl-4.0.0.tar.bz2
|
|
|
|
cd shorewall-perl-4.0.0
|
|
./install.sh
|
|
cd ../shorewall-common-4.0.0
|
|
./install.sh
|
|
shorewall check
|
|
shorewall restart
|
|
|
|
Be sure to modify shorewall.conf if it still has
|
|
SHOREWALL_COMPILER=shell.
|
|
|
|
2) The ROUTE_FILTER and LOG_MARTIANS options in shorewall.conf work
|
|
slightly differently in Shorewall 4.0.0. In prior releases, leaving
|
|
these options empty was equivalent to setting them to 'No' which
|
|
caused the corresponding flag in /proc to be reset for all
|
|
interfaces. Beginning in Shorewall 4.0.0, leaving these options
|
|
empty causes Shorewall to leave the flags in /proc as they are. You
|
|
must set the option to 'No' in order to obtain the old behavior.
|
|
|
|
3) The -f option is no longer the default when Shorewall is started at
|
|
boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,
|
|
"shorewall start" is nearly as fast as "shorewall restore" and
|
|
"shorewall start" uses the current configuration which avoids
|
|
confusion.
|
|
|
|
If you plan on continuing to use Shorewall-shell and you want to
|
|
use the "-f" option at boot time, then you must add the following
|
|
to /etc/sysconfig/shorewall or /etc/default/shorewall:
|
|
|
|
OPTIONS="-f"
|
|
|
|
If you currently have neither of those files, you will need to
|
|
create one of them.
|
|
|
|
4) This issue will only affect you if you use Shorewall Lite and have
|
|
modified /usr/share/configpath to specify a different LITEDIR.
|
|
|
|
The implementation of LITEDIR has always been
|
|
unsatisfactory. Furthermore, there have been other cases where
|
|
people have asked to be able to designate the state directory
|
|
(default /var/lib/shorewall[-lite]).
|
|
|
|
To meet these objectives:
|
|
|
|
a) The LITEDIR variable has been eliminated in
|
|
/usr/share/shorewall[-lite]/configpath.
|
|
|
|
b) A new file /etc/shorewall[-lite]/vardir has been added. This
|
|
file is not created by default but may be added as needed. It
|
|
is expected to contain a single variable assignment:
|
|
|
|
VARDIR=<directory>
|
|
|
|
Example:
|
|
|
|
VARDIR=/root/shorewall
|
|
|
|
To change VARDIR, copy the old directory to the new one before you
|
|
restart Shorewall[-lite].
|
|
|
|
To use this feature with Shorewall-lite, all packages involved
|
|
(compiler, shorewall-common and shorewall-lite) must be version
|
|
4.0.0-RC2 or later.
|
|
|
|
----------------------------------------------------------------------------
|
|
N E W F E A T U R E S
|
|
----------------------------------------------------------------------------
|
|
1) Shorewall-perl
|
|
|
|
This Shorewall package includes a complete rewrite of the compiler
|
|
in Perl.
|
|
|
|
I decided to make Shorewall-perl a separate package for several reasons:
|
|
|
|
a) Embedded applications are unlikely to adopt Shorewall-perl; even
|
|
Mini-Perl has a substantial disk and RAM footprint.
|
|
|
|
b) Because of the gross incompatibilities between the new compiler and the
|
|
old (see below), migration to the new compiler must be voluntary.
|
|
------------------------------------------------------------------------
|
|
T H E G O O D N E W S:
|
|
------------------------------------------------------------------------
|
|
a) The compiler has a small disk footprint.
|
|
b) The compiler is very fast.
|
|
c) The compiler generates a firewall script that uses iptables-restore;
|
|
so the script is very fast.
|
|
d) The new compiler does a much better job of validating the
|
|
configuration and catches many errors that resulted in run-time
|
|
failures with the old compiler.
|
|
e) Use of the Shorewall-perl is optional! The old slow clunky
|
|
Bourne-shell compiler is still available.
|
|
------------------------------------------------------------------------
|
|
T H E B A D N E W S:
|
|
------------------------------------------------------------------------
|
|
There are a number of incompatibilities between the Perl-based compiler
|
|
and the Bourne-shell one.
|
|
|
|
a) The Perl-based compiler requires the following capabilities in your
|
|
kernel and iptables.
|
|
|
|
- addrtype match
|
|
- multiport match
|
|
|
|
These capabilities are in current distributions.
|
|
|
|
b) Now that Netfilter has features to deal reasonably with port lists,
|
|
I see no reason to duplicate those features in Shorewall. The
|
|
Bourne-shell compiler goes to great pain (in some cases) to
|
|
break very long port lists ( > 15 where port ranges in lists
|
|
count as two ports) into individual rules. In the new compiler, I'm
|
|
avoiding the ugliness required to do that. The new compiler just
|
|
generates an error if your list is too long. It will also produce
|
|
an error if you insert a port range into a port list and you don't
|
|
have extended multiport support.
|
|
|
|
c) The old BRIDGING=Yes support has been replaced by new bridge
|
|
support that uses the reduced 'physdev match' capabilities found
|
|
in kernel 2.6.20 and later. This new implementation may be used
|
|
where it is desired to control traffic through a bridge.
|
|
|
|
The new implementation includes the following features:
|
|
|
|
a) A new "Bridge Port" zone type is defined. Specify 'bport' or
|
|
'bport4' in the TYPE column of /etc/shorewall/zones.
|
|
|
|
Bridge Port zones should be a sub-zone of a regular ipv4 zone
|
|
that represents all hosts attached to the bridge.
|
|
|
|
b) A new 'bridge' option is defined for entries in
|
|
/etc/shorewall/interfaces. Bridges should have this option
|
|
specified, even if you don't want to filter traffic going
|
|
through the bridge.
|
|
|
|
c) Bridge ports must now be defined in
|
|
/etc/shorewall/interfaces. The INTERFACE column contains
|
|
both the bridge name and the port name separated by a colon
|
|
(e.g., "br0:eth1"). No OPTIONS are allowed for bridge
|
|
ports. The bridge must be defined before its ports and must
|
|
have the 'bridge' option.
|
|
|
|
Bridge Port (BP) zones have a number of limitations:
|
|
|
|
a) Each BP zone may only be associated with ports on a single
|
|
bridge.
|
|
|
|
b) BP zones may not be associated with interfaces that are not
|
|
bridge ports.
|
|
|
|
c) You may not have policies or rules where the DEST is a BP
|
|
zone but the source is not a BP zone. If you need such
|
|
rules, you must use the BP zone's parent zone as the DEST
|
|
zone.
|
|
|
|
Example (Bridge br0 with ports eth1 and tap0):
|
|
|
|
/etc/shorewall/zones:
|
|
|
|
fw firewall
|
|
net ipv4
|
|
loc ipv4
|
|
lan:loc bport
|
|
vpn:loc bport
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
net eth0 - ...
|
|
loc br0 - ...
|
|
lan eth1
|
|
vpn tap0
|
|
|
|
When using the /etc/shorewall/hosts file to define a bport4
|
|
zone, you specify only the port name:
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/zones:
|
|
|
|
fw firewall
|
|
net ipv4
|
|
loc ipv4
|
|
lan:loc bport
|
|
vpn:loc bport
|
|
|
|
/etc/shorewall/hosts
|
|
|
|
lan eth1:192.168.2.0/24 ...
|
|
|
|
The structure of the accounting rules changes slightly when
|
|
there are bridges defined in the Shorewall
|
|
configuration. Because of the restrictions imposed by Netfilter
|
|
in kernel 2.6.21 and later, output accounting rules must be
|
|
segregated from forwarding and input rules.
|
|
|
|
To accomplish this separation, Shorewall-perl creates two
|
|
accounting chains:
|
|
|
|
- accounting - for input and forwarded traffic.
|
|
- accountout - for output traffic.
|
|
|
|
If the CHAIN column contains '-', then:
|
|
|
|
- If the SOURCE column in a rule includes the name of the
|
|
firewall zone (e.g., $FW), then the rule is add only
|
|
to the accountout chain.
|
|
|
|
- Otherwise, if the DEST in the rule is any or all or 0.0.0.0/0,
|
|
then the rule is added to both accounting and accountout.
|
|
|
|
- Otherwise, the rule is added to accounting only.
|
|
|
|
See http://www.shorewall.net/4.0/bridge-Shorewall-perl.html for
|
|
additional information about the new bridge support.
|
|
|
|
d) The BROADCAST column in the interfaces file is essentially unused;
|
|
if you enter anything in this column but '-' or 'detect', you will
|
|
receive a warning.
|
|
|
|
e) Because the compiler is written in Perl, some of your extension
|
|
scripts from earlier versions will no longer work because
|
|
Shorewall-perl runs those extension scripts at compile-time rather
|
|
than at run-time.
|
|
|
|
Compile-time scripts are:
|
|
|
|
initdone
|
|
maclog
|
|
All per-chain scripts including those associated with actions.
|
|
|
|
Compile-time extension scripts are executed using the Perl 'eval
|
|
`cat <file>`' mechanism. Be sure that each script returns a
|
|
'true' value; otherwise, the compiler will assume that the
|
|
script failed and will abort the compilation.
|
|
|
|
All scripts will need to begin with the following line:
|
|
|
|
use Shorewall::Chains;
|
|
|
|
For more complex scripts, you may need to 'use' other Shorewall
|
|
Perl modules -- browse /usr/share/shorewall-perl/Shorewall/ to
|
|
see what's available.
|
|
|
|
When a script is invoked, the $chainref scalar variable will hold a
|
|
reference to a chain table entry.
|
|
|
|
$chainref->{name} contains the name of the chain
|
|
$chainref->{table} holds the table name
|
|
|
|
To add a rule to the chain:
|
|
|
|
add_rule( $chainref, <the rule> );
|
|
|
|
Where
|
|
|
|
<the rule> is a scalar argument holding the rule text. Do
|
|
not include "-A <chain name>"
|
|
|
|
Example:
|
|
|
|
add_rule( $chainref, '-j ACCEPT' );
|
|
|
|
To insert a rule into the chain:
|
|
|
|
insert_rule( $chainref, <rulenum>, <the rule> );
|
|
|
|
The log_rule_limit function works like it does in the shell
|
|
compiler with two exceptions:
|
|
|
|
- You pass the chain reference rather than the name of
|
|
the chain.
|
|
- The commands are 'add' and 'insert' rather than '-A'
|
|
and '-I'.
|
|
- There is only a single "pass as-is to iptables"
|
|
argument (so you must quote that part).
|
|
|
|
Example:
|
|
|
|
log_rule_limit(
|
|
'info' ,
|
|
$chainref ,
|
|
$chainref->{name},
|
|
'DROP' ,
|
|
'', #Limit
|
|
'' , #Log tag
|
|
'add', #Command
|
|
'-p tcp' #Pass as-is
|
|
);
|
|
|
|
Note that in the 'initdone' script, there is no default chain
|
|
($chainref). You can objtain a reference to a standard chain by:
|
|
|
|
my $chainref = $chain_table{<table>}{<chain name>};
|
|
|
|
Example:
|
|
|
|
my $chainref = $chain_table{'filter'}{'INPUT'};
|
|
|
|
The continue script is eliminated. That script was designed to
|
|
allow you to add special rules during [re]start. Shorewall-perl
|
|
doesn't need such rules.
|
|
|
|
See http://www.shorewall.net/4.0/shorewall_extension_scripts.htm
|
|
for further information about extension scripts under
|
|
Shorewall-perl.
|
|
|
|
f) The 'refresh' command now works like 'restart' with the
|
|
following exceptions:
|
|
|
|
- The refresh command is rejected if Shorewall is not running.
|
|
- The refresh command only rebuilds the 'blacklst' chain.
|
|
- A directory name may not be specified in the refresh command.
|
|
|
|
g) The /etc/shorewall/tos file now has zone-independent SOURCE and
|
|
DEST columns as do all other files except the rules and policy
|
|
files.
|
|
|
|
The SOURCE column may be one of the following:
|
|
|
|
[all:]<address>[,...]
|
|
[all:]<interface>[:<address>[,...]]
|
|
$FW[:<address>[,...]]
|
|
|
|
The DEST column may be one of the following:
|
|
|
|
[all:]<address>[,...]
|
|
[all:]<interface>[:<address>[,...]]
|
|
|
|
This is a permanent change. The old zone-based rules have never
|
|
worked right and this is a good time to replace them. I've tried
|
|
to make the new syntax cover the most common cases without
|
|
requiring change to existing files. In particular, it will
|
|
handle the tos file released with Shorewall 1.4 and earlier.
|
|
|
|
h) Shorewall is now out of the ipset load/reload business. With
|
|
scripts generated by the Perl-based Compiler, the Netfilter
|
|
ruleset is never cleared. That means that there is no
|
|
opportunity for Shorewall to load/reload your ipsets since that
|
|
cannot be done while there are any current rules using ipsets.
|
|
|
|
So:
|
|
|
|
i) Your ipsets must be loaded before Shorewall starts. You
|
|
are free to try to do that with the following code in
|
|
/etc/shorewall/start:
|
|
|
|
if [ "$COMMAND" = start ]; then
|
|
ipset -U :all: :all:
|
|
ipset -F
|
|
ipset -X
|
|
ipset -R < /my/ipset/contents
|
|
fi
|
|
|
|
The file '/my/ipset/contents' (not its real name of
|
|
course) will normally be produced using the ipset -S
|
|
command.
|
|
|
|
The above will work most of the time but will fail in a
|
|
'shorewall stop' - 'shorewall start' sequence if you
|
|
use ipsets in your routestopped file (see below).
|
|
|
|
ii) Your ipsets may not be reloaded until Shorewall is stopped
|
|
or cleared.
|
|
|
|
iii) If you specify ipsets in your routestopped file then
|
|
Shorewall must be cleared in order to reload your ipsets.
|
|
|
|
As a consequence, scripts generated by the Perl-based compiler
|
|
will ignore /etc/shorewall/ipsets and will issue a warning if
|
|
you set SAVE_IPSETS=Yes in shorewall.conf.
|
|
|
|
i) Because the configuration files (with the exception of
|
|
/etc/shorewall/params) are now processed by the Perl-based
|
|
compiler rather than by the shell, only the basic forms of Shell
|
|
expansion ($variable and ${variable}) are supported. The more
|
|
exotic forms such as ${variable:=default} are not
|
|
supported. Both variables defined in /etc/shorewall/params and
|
|
environmental variables (exported by the shell) can be used in
|
|
configuration files.
|
|
|
|
j) USE_ACTIONS=No is not supported. That option is intended to
|
|
minimize Shorewall's footprint in embedded applications. As a
|
|
consequence, Default Macros are not supported.
|
|
|
|
k) DELAYBLACKLISTLOAD=Yes is not supported. The entire ruleset is
|
|
atomically loaded with one execution of iptables-restore.
|
|
|
|
l) MAPOLDACTIONS=Yes is not supported. People should have converted
|
|
to using macros by now.
|
|
|
|
m) The pre Shorewall-3.0 format of the zones file is not supported;
|
|
neither is the /etc/shorewall/ipsec file.
|
|
|
|
n) BLACKLISTNEWONLY=No is not permitted with FASTACCEPT=Yes. This
|
|
combination doesn't work in previous versions of Shorewall so
|
|
the Perl-based compiler simply rejects it.
|
|
|
|
o) Shorewall-perl has a single rule generator that is used for all
|
|
rule-oriented files. So it is important that the syntax is
|
|
consistent between files.
|
|
|
|
With shorewall-shell, there is a special syntax in the SOURCE
|
|
column of /etc/shorewall/masq to designate "all traffic entering
|
|
the firewall on this interface except...".
|
|
|
|
Example:
|
|
|
|
#INTERFACE SOURCE ADDRESSES
|
|
eth0 eth1!192.168.4.9 ...
|
|
|
|
Shorewall-perl uses syntax that is consistent with the rest of
|
|
Shorewall:
|
|
|
|
#INTERFACE SOURCE ADDRESSES
|
|
eth0 eth1:!192.168.4.9 ...
|
|
|
|
p) The 'allowoutUPnP' built-in action is no longer supported. The
|
|
Netfilter team have removed support for '-m owner --owner-cmd'
|
|
which that action depended on.
|
|
|
|
q) The treatment of the following interface options has changed under
|
|
Shorewall-perl.
|
|
|
|
- arp_filter
|
|
- routefilter
|
|
- logmartians
|
|
- proxy_arp
|
|
- sourceroute
|
|
|
|
With the Shorewall-shell compiler, Shorewall resets these options
|
|
on all interfaces then sets the option on those interfaces
|
|
for which the option is defined in /etc/shorewall/interfaces.
|
|
|
|
Under Shorewall-perl, these options can be specified with the value
|
|
0 or 1 (e.g., proxy_arp=0). If no value is specified, the value 1
|
|
is assumed. Shorewall will modify only the setting of those
|
|
interfaces for which the option is specified and will set the
|
|
option to the given value.
|
|
|
|
A fatal compilation error is also generated if you specify one of
|
|
these options with a wildcard interface (one ending with '+').
|
|
|
|
r) The LOG_MARTIANS and ROUTE_FILTER options are now tri-valued in
|
|
Shorewall-perl.
|
|
|
|
Yes - Same as before
|
|
No - Same as before except that it applies regardless of
|
|
whether any interfaces have the logmartians/routefilter
|
|
option
|
|
Keep - Shorewall ignores the option entirely (which is the
|
|
default).
|
|
|
|
s) Shorewall-perl support nn 'optional' option has been added to
|
|
/etc/shorewall/interfaces. This option is recognized by
|
|
Shorewall-perl but not by Shorewall-shell. When 'optional' is
|
|
specified for an interface, Shorewall will be silent when:
|
|
|
|
- a /proc/sys/net/ipv4/conf/ entry for the interface cannot be
|
|
modified (including for proxy ARP).
|
|
|
|
- The first address of the interface cannot be obtained.
|
|
|
|
I specify 'optional' on interfaces to Xen virtual machines that
|
|
may or may not be running when Shorewall is [re]started.
|
|
|
|
CAUTION: Use 'optional' at your own risk. If you [re]start
|
|
Shorewall when an 'optional' interface is not available and then
|
|
do a 'shorewall save', subsequent 'shorewall restore' and
|
|
'shorewall -f start' operations will instantiate a ruleset that
|
|
does not support that interface, even if it is available at the
|
|
time of the restore/start.
|
|
|
|
t) Shorewall-perl validates all IP addresses and addresses ranges
|
|
in rules. DNS names are resolved and an error is issued for any
|
|
name that cannot be resolved.
|
|
u) Shorewall-perl checks configuration files for the presense of
|
|
characters that can cause problems if they are allowed into the
|
|
generated firewall script:
|
|
|
|
- Double Quotes. These are prohibited except in the
|
|
shorewall.conf and params files.
|
|
|
|
- Single Quotes. These are prohibited except in the
|
|
shorewall.conf and params files and in COMMENT lines.
|
|
|
|
- Single back quotes. These are prohibited except in the
|
|
shorewall.conf and params files.
|
|
|
|
- Backslash. Probibited except as the last character on a line
|
|
to denote line continuation.
|
|
|
|
v) Under Shorewall-perl, macros may invoke other macros with the
|
|
restriction that such macros may not be invoked within an action
|
|
body.
|
|
|
|
When marcros are invoked recursively, the parameter passed to an
|
|
invocation are automatically propagated to lower level macros.
|
|
|
|
Macro invocations may be nested to a maximum level of 5.
|
|
------------------------------------------------------------------------
|
|
P R E R E Q U I S I T E S
|
|
------------------------------------------------------------------------
|
|
- Perl (I use Perl 5.8.8 but other versions should work fine)
|
|
- Perl Cwd Module
|
|
- Perl File::Basename Module
|
|
- Perl File::Temp Module
|
|
- Perl Getopt::Long Module
|
|
------------------------------------------------------------------------
|
|
U S I N G T H E N E W C O M P I L E R
|
|
If you only install one compiler, then that compiler will be used.
|
|
|
|
If you install both compilers, then the compiler actually used depends
|
|
on the SHOREWALL_COMPILER setting in shorewall.conf.
|
|
|
|
The value of this new option can be either 'perl' or 'shell'.
|
|
|
|
If you add 'SHOREWALL_COMPILER=perl' to /etc/shorewall/shorewall.conf
|
|
then by default, the new compiler will be used on the system. If you
|
|
add it to shorewall.conf in a separate directory (such as a
|
|
Shorewall-lite export directory) then the new compiler will only be
|
|
used when you compile from that directory.
|
|
|
|
If you only install one compiler, it is suggested that you do not set
|
|
SHOREWALL_COMPILER.
|
|
|
|
You can also select the compiler to use on the command line using the
|
|
'C option:
|
|
|
|
'-C shell' means use the shell compiler
|
|
'-C perl' means use the perl compiler
|
|
|
|
The -C option overrides the setting in shorewall.conf.
|
|
|
|
Example:
|
|
|
|
shorewall restart -C perl
|
|
|
|
2) Thanks to Paul Gear, an IPPServer macro has been added. Be sure to
|
|
read the comments in the macro file before trying to use this
|
|
macro.
|
|
|
|
3) Eariler generations of Shorewall Lite required that remote root
|
|
login via ssh be enabled in order to use the 'load' and 'reload'
|
|
commands.
|
|
|
|
Beginning with this release, you may define an alternative means
|
|
for accessing the remote firewall system.
|
|
|
|
Two new options have been added to shorewall.conf:
|
|
|
|
RSH_COMMAND
|
|
RCP_COMMAND
|
|
|
|
The default values for these are as follows:
|
|
|
|
RSH_COMMAND: ssh ${root}@${system} ${command}
|
|
RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
|
|
|
|
Shell variables that will be set when the commands are envoked are
|
|
as follows:
|
|
|
|
root - root user. Normally 'root' but may be overridden using
|
|
the '-r' option.
|
|
|
|
system - The name/IP address of the remote firewall system.
|
|
|
|
command - For RSH_COMMAND, the command to be executed on the
|
|
firewall system.
|
|
|
|
files - For RCP_COMMAND, a space-separated list of files to
|
|
be copied to the remote firewall system.
|
|
|
|
destination - The directory on the remote system that the files
|
|
are to be copied into.
|
|
|
|
4) The accounting, masq, rules and tos files now have a 'MARK' column
|
|
similar to the column of the same name in the tcrules file. This
|
|
column allows filtering by MARK and CONNMARK value (CONNMARK is
|
|
only accepted under Shorewall Perl).
|
|
|
|
5) SOURCE and DEST are now reserved zone names to avoid problems with
|
|
bi-directional macro definitions which use these as names as key
|
|
words.
|
|
|
|
6) The "shorewall show zones" command now flags zone members that have
|
|
been added using "shorewall add" by preceding them with a plus sign
|
|
("+").
|
|
|
|
Example:
|
|
|
|
Shorewall 3.9.4 Zones at gateway - Mon May 14 07:48:16 PDT 2007
|
|
|
|
fw (firewall)
|
|
net (ipv4)
|
|
eth0:0.0.0.0/0
|
|
loc (ipv4)
|
|
br0:0.0.0.0/0
|
|
eth4:0.0.0.0/0
|
|
eth5:0.0.0.0/0
|
|
+eth1:0.0.0.0/0
|
|
dmz (ipv4)
|
|
eth3:0.0.0.0/0
|
|
vpn (ipv4)
|
|
tun+:0.0.0.0/0
|
|
|
|
In the above output, "eth1:0.0.0.0/0" was dynamically added to the
|
|
'loc' zone. As part of this change, "shorewall delete" will only
|
|
delete entries that have been added dynamically. In earlier
|
|
versions, any entry could be deleted although the ruleset was only
|
|
changed by deleting entries that had been added dynamically.
|
|
|
|
7) The 'shorewall version' command now lists the version of the
|
|
installed compiler(s) if the -a option is used:
|
|
|
|
gateway:/bulk/backup # shorewall version -a
|
|
4.0.0-Beta1
|
|
Shorewall-shell 4.0.0-Beta1
|
|
Shorewall-perl 4.0.0-Beta1
|
|
gateway:/bulk/backup #
|
|
|
|
8) The Perl compiler is externalized. Both the compiler.pl program
|
|
and the Perl Module interface are documented.
|
|
|
|
The compiler program is /usr/share/shorewall-perl/compiler.pl:
|
|
|
|
compiler.pl [ <option> ... ] [ <filename> ]
|
|
|
|
If a <filename> is given, then the configuration will be compiled
|
|
output placed in the named file. If <filename> is not given, then
|
|
the configuration will simply be syntax checked.
|
|
|
|
Options are:
|
|
|
|
-v <verbosity>
|
|
--verbosity=<verbosity>
|
|
|
|
The <verbosity> is a number between 0 and 2 and corresponds to
|
|
the VERBOSITY setting in shorewall.conf. This setting controls
|
|
the verbosity of the compiler itself.
|
|
|
|
-e
|
|
--export
|
|
|
|
If given, the configuration will be compiled for export to
|
|
another system.
|
|
|
|
-d <directory>
|
|
--directory=<directory>
|
|
|
|
If this option is omitted, the configuration in /etc/shorewall
|
|
is compiled/checked. Otherwise, the configuration in the named
|
|
directory will be compiled/checked.
|
|
|
|
-t
|
|
--timestamp
|
|
|
|
If given, each progress message issued by the compiler and by
|
|
the compiled program will be timestamped.
|
|
|
|
--debug
|
|
|
|
If given, when a warning or error message is issued, it is
|
|
supplimented with a stack trace. Requires the Carp Perl
|
|
module.
|
|
|
|
Example (compiles the configuration in the current directory
|
|
generating a script named 'firewall' and using VERBOSITY
|
|
2).
|
|
|
|
/usr/share/shorewall-perl/compiler.pl -v 2 -d . firewall
|
|
|
|
Note: For compatibility with the Shorewall 3.4.2 and 3.4.3
|
|
releases, options not passed on the run-line get their values from
|
|
environmental variables:
|
|
|
|
Option Variable
|
|
|
|
--verbosity VERBOSE
|
|
--export EXPORT
|
|
--directory SHOREWALL_DIR
|
|
--timestamp TIMESTAMP
|
|
|
|
The Perl Module is externalized as follows:
|
|
|
|
use lib '/usr/share/shorewall-perl';
|
|
use Shorewall::Compiler;
|
|
|
|
compiler $filename, $directory, $verbose, $options
|
|
|
|
The arguments to the compiler function are as follows:
|
|
|
|
$filename - Name of the compiled script to be created.
|
|
If the arguments evaluates to false, the
|
|
configuration is syntax checked
|
|
|
|
$directory - The directory containing the configuration.
|
|
If passed as '', then /etc/shorewall/ is assumed.
|
|
|
|
$verbose - The verbosity level (0-2).
|
|
|
|
$options - A bitmap of options. Shorewall::Compiler
|
|
exports two constants to help building this
|
|
argument:
|
|
|
|
EXPORT = 0x01
|
|
TIMESTAMP = 0x02
|
|
|
|
The compiler raises an exception with 'die' if it encounters an
|
|
error; $@ contains the 'ERROR' messages describing the problem.
|
|
|
|
The compiler function can be called repeatedly with different
|
|
inputs.
|
|
|
|
9) When TC_ENABLED=Internal, Shorewall-perl now validates classids in
|
|
the MARK/CLASSIFY column of /etc/shorewall/tcrules against the
|
|
classes generated by /etc/shorewall/tcclasses.
|
|
|
|
10) During installation, Shorewall generates the Perl module
|
|
/usr/share/shorewall-perl/Shorewall/Ports.pm, using your
|
|
/etc/protocols and /etc/services as input.
|
|
|
|
To re-generate the module from those two files:
|
|
|
|
1. Backup your current /usr/share/shorewall-perl/Shorewall/Ports.pm
|
|
file.
|
|
2. /usr/share/shorewall-perl/buildports.pl > \
|
|
/usr/share/shorewall-perl/Shorewall/Ports.pm
|
|
|
|
Note: If the buildports.pl program fails to run to a successful
|
|
completion during installation, a fallback version of
|
|
module will be installed. That fallback module was generated from
|
|
the /etc/protocols and /etc/services shipped with Ubuntu Feisty
|
|
Fawn.
|
|
|
|
Even if the buildports.pl program runs successfully, the fallback
|
|
module is also installed as
|
|
/usr/share/shorewall-perl/Shorewall/FallbackPorts.pm. So if you
|
|
encounter problems with the generated module, simply copy the
|
|
fallback module to /usr/share/shorewall-perl/Shorewall/Ports.pm.
|
|
|
|
11) Tuomo Soini has contributed bi-directional macros for various
|
|
tunnel types:
|
|
|
|
IPsecah
|
|
GRE
|
|
IPsec
|
|
IPIP
|
|
IPsecnat
|
|
L2TP
|
|
|
|
12) The -f option is no longer the default when Shorewall is started at
|
|
boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,
|
|
"shorewall start" is nearly as fast as "shorewall restore" and
|
|
"shorewall start" uses the current configuration which avoids
|
|
confusion.
|
|
|
|
|
|
To re-generate the module from those two files:
|
|
|
|
1. Backup your current /usr/share/shorewall-perl/Shorewall/Ports.pm
|
|
file.
|
|
2. /usr/share/shorewall-perl/buildports.pl > \
|
|
/usr/share/shorewall-perl/Shorewall/Ports.pm
|
|
|
|
Note: If the buildports.pl program fails to run to a successful
|
|
completion during installation, a fallback version of
|
|
module will be installed. That fallback module was generated from
|
|
the /etc/protocols and /etc/services shipped with Ubuntu Feisty
|
|
Fawn.
|
|
|
|
Even if the buildports.pl program runs successfully, the fallback
|
|
module is also installed as
|
|
/usr/share/shorewall-perl/Shorewall/FallbackPorts.pm. So if you
|
|
encounter problems with the generated module, simply copy the
|
|
fallback module to /usr/share/shorewall-perl/Shorewall/Ports.pm.
|
|
|
|
11) Tuomo Soini has contributed bi-directional macros for various
|
|
tunnel types:
|
|
|
|
IPsecah
|
|
GRE
|
|
IPsec
|
|
IPIP
|
|
IPsecnat
|
|
L2TP
|
|
|
|
12) The -f option is no longer the default when Shorewall is started at
|
|
boot time (usually via /etc/init.d/shorewall). With Shorewall-perl,
|
|
"shorewall start" is nearly as fast as "shorewall restore" and
|
|
"shorewall start" uses the current configuration which avoids
|
|
confusion.
|
|
|
|
13) The implementation of LITEDIR has always been
|
|
unsatisfactory. Furthermore, there have been other cases where
|
|
people have asked to be able to designate the state directory
|
|
(default /var/lib/shorewall[-lite]).
|
|
|
|
To meet these objectives:
|
|
|
|
a) The LITEDIR variable has been eliminated in
|
|
/usr/share/shorewall[-lite]/configpath.
|
|
|
|
b) A new file /etc/shorewall[-lite]/vardir has been added. This
|
|
file is not created by default but may be added as needed. It
|
|
is expected to contain a single variable assignment:
|
|
|
|
VARDIR=<directory>
|
|
|
|
Example:
|
|
|
|
VARDIR=/root/shorewall
|
|
|
|
To change VARDIR, copy the old directory to the new one before you
|
|
restart Shorewall[-lite].
|
|
|
|
To use this feature with Shorewall-lite, all packages involved
|
|
(compiler, shorewall-common and shorewall-lite) must be version
|
|
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.
|
|
|
|
1) DYNAMIC_ZONES=Yes can now coexist with Shorewall-perl's 'bport'
|
|
zones. Those zones themselves may not be dynamically modified but
|
|
the presence of bport zones no longer causes the 'shorewall add'
|
|
command to fail.
|
|
|
|
2) Shorewall's internal traffic shaper once again works when the 'sed'
|
|
utility is provided by the Busybox package.
|
|
|
|
3) Version 3.4.4 erroneously accepted the values On, Off, on, off, ON
|
|
and OFF for the IP_FORWARDING option. These values were treated
|
|
like 'Keep'. The listed values are now once again flagged as an
|
|
error.
|
|
|
|
4) If 'routeback' and 'detectnets' were specified on an interface,
|
|
limited broadcasts (to 255.255.255.255) and multicasts were dropped
|
|
when forwarded through the interface. This could cause
|
|
broadcast-based and multicast applications to fail when running
|
|
through a bridge with 'detectnets'.
|
|
|
|
5) The 'hits' command works once again.
|
|
|
|
6) IPSECFILE=ipsec (either explicitly or defaulted) works
|
|
now. Previously, processing of the ipsec file was bypassed; often
|
|
with a confusing "missing file" message.
|
|
|
|
7) If DETECT_DNAT_IPADDRS=Yes in shorewall.conf but you did't have conntrack
|
|
match support, then the generated script was missing 'done's.
|
|
|
|
Other changes in 3.4.5.
|
|
|
|
1) When a Shorewall release includes detection of an additional
|
|
capability, existing capabilities files become out of
|
|
date. Previously, this condition was not detected.
|
|
|
|
Beginning with this release, each generated capabilities file
|
|
contains a CAPVERSION specification which defines the capabilities
|
|
version of the file. If the CAPVERSION in a capabilities file is
|
|
less than the current CAPVERSION, then Shorewall will issue the
|
|
following message:
|
|
|
|
WARNING: <file> is out of date -- it does not contain all of
|
|
the capabilities defined by Shorewall version <version>
|
|
|
|
where
|
|
|
|
<file> is the name of the capabilities file.
|
|
<version> is the current Shorewall version.
|
|
|
|
Existing capabilities files contain no CAPVERSION. When such a file
|
|
is read, Shorewall will issue this message:
|
|
|
|
WARNING: <file> may be not contain all of the capabilities defined
|
|
by Shorewall version <version>
|
|
|
|
2) When a directory is specified in a command such as 'start' or
|
|
'compile', Shorewall now reads the shorewall.conf file (if any) in
|
|
that directory before deciding which compiler to use. So if
|
|
SHOREWALL_COMPILER is not specified in
|
|
/etc/shorewall/shorewall.conf and the -C option was not specified
|
|
on the run-line, then if Shorewall-perl is installed, the additional
|
|
shorewall.conf file is read to see if it specifies a
|
|
SHOREWALL_COMPILER.
|
|
|
|
3) The 'save' command now uses iptables-save from the same directory
|
|
containing iptables. Previously, iptables-save was located via the
|
|
PATH setting.</pre>
|
|
<hr>
|
|
|
|
<p><strong>2007-06-17 Shorewall 3.4.4</strong></p>
|
|
<pre>Problems corrected in 3.4.4:
|
|
|
|
1) The commands "shorewall add <interface> <zone>" and "shorewall
|
|
delete <interface> <zone>" no longer produce spurious error
|
|
messages.
|
|
|
|
2) The command "shorewall delete <interface> <zone>" now actually deletes
|
|
entries when it successfully completes. Previously, it would appear
|
|
to remove an entry, even when removing that entry should fail.
|
|
|
|
3) Setting HIGH_ROUTE_MARKS=No no longer causes TC_EXPERT flagging.
|
|
|
|
4) When run as root, the 'shorewall load' and 'shorewall reload'
|
|
commands would fail if the LOGFILE setting in
|
|
/etc/shorewall/shorewall.conf specified a non-existant file.
|
|
|
|
5) Entries in /etc/shorewall/tcrules that specify both a source and
|
|
destination port fail with the following diagnostic:
|
|
|
|
iptables v1.3.3: multiport can only have one option
|
|
|
|
6) Previously, Shorewall-lite did not allow DHCP traffic through an
|
|
interface when the interface was a bridge with 'dhcp' specified
|
|
unless there was a bridge on the administrative system with the
|
|
same name.
|
|
|
|
7) SOURCE and DEST are now flagged as invalid zone name to avoid
|
|
problems with macros that use those names as keywords.
|
|
|
|
8) Previously, Shorewall could *increase* the MSS under some
|
|
circumstances. This possibility is now eliminated, provided that
|
|
the system has TCPMSS match support (be sure to update your
|
|
capabilities files!).
|
|
|
|
9) Firewall zone names other than 'fw' no longer cause a error when
|
|
IPSECFILE is not set or is set to 'ipsec'.
|
|
|
|
10) The 'proxyarp' option on an interface was previously ignored when
|
|
the /etc/shorewall/proxyarp file was empty.
|
|
|
|
11) Previously, if action 'a' was defined then the following
|
|
rule generated an error:
|
|
|
|
a: z1 z2 ...
|
|
|
|
The trailing ":" is now ignored.
|
|
|
|
12) Previously, if a RATE/LIMIT was specified on a REJECT rule, the
|
|
generated error messages referred to the rule as a DROP rule.
|
|
|
|
13) The 'nolock' keyword was previously ignored on several
|
|
/sbin/shorewall[-lite] commands.
|
|
|
|
Other changes in 3.4.4:
|
|
|
|
1) The accounting, masq, rules and tos files now have a 'MARK' column
|
|
similar to the column of the same name in the tcrules file. This
|
|
column allows filtering by MARK value.
|
|
|
|
2) The "shorewall show zones" command now flags zone members that have
|
|
been added using "shorewall add" by preceding them with a plus sign
|
|
("+").
|
|
|
|
Example:
|
|
|
|
Shorewall 3.9.4 Zones at gateway - Mon May 14 07:48:16 PDT 2007
|
|
|
|
fw (firewall)
|
|
net (ipv4)
|
|
eth0:0.0.0.0/0
|
|
loc (ipv4)
|
|
br0:0.0.0.0/0
|
|
eth4:0.0.0.0/0
|
|
eth5:0.0.0.0/0
|
|
+eth1:0.0.0.0/0
|
|
dmz (ipv4)
|
|
eth3:0.0.0.0/0
|
|
vpn (ipv4)
|
|
tun+:0.0.0.0/0
|
|
|
|
In the above output, "eth1:0.0.0.0/0" was dynamically added to the
|
|
'loc' zone. As part of this change, "shorewall delete" will only
|
|
delete entries that have been added dynamically. In earlier
|
|
versions, any entry could be deleted although the ruleset was only
|
|
changed by deleting entries that had been added dynamically.
|
|
|
|
3) Eariler generations of Shorewall Lite required that remote root
|
|
login via ssh be enabled in order to use the 'load' and 'reload'
|
|
commands.
|
|
|
|
Beginning with this release, you may define an alternative means
|
|
for accessing the remote firewall system.
|
|
|
|
Two new options have been added to shorewall.conf:
|
|
|
|
RSH_COMMAND
|
|
RCP_COMMAND
|
|
|
|
The default values for these are as follows:
|
|
|
|
RSH_COMMAND: ssh ${root}@${system} ${command}
|
|
RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
|
|
|
|
Shell variables that will be set when the commands are envoked are
|
|
as follows:
|
|
|
|
root - root user. Normally 'root' but may be overridden using
|
|
the '-r' option.
|
|
|
|
system - The name/IP address of the remote firewall system.
|
|
|
|
command - For RSH_COMMAND, the command to be executed on the
|
|
firewall system.
|
|
|
|
files - For RCP_COMMAND, a space-separated list of files to
|
|
be copied to the remote firewall system.
|
|
|
|
destination - The directory on the remote system that the files
|
|
are to be copied into.
|
|
|
|
4) You may now select the compiler to use on the command line using
|
|
the '-C' option. This option is available on the following
|
|
commands:
|
|
|
|
check
|
|
compile
|
|
export
|
|
load
|
|
reload
|
|
restart
|
|
start
|
|
try
|
|
safe-start
|
|
save-restart
|
|
|
|
Example:
|
|
|
|
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
|
|
Productions (http://mastermindpro.com) have volunteered to host
|
|
www.shorewall.net and ftp.shorewall.net.
|
|
|
|
The new site is up and running and I've just changed DNS to point to the new
|
|
server. Let me know if you experience any problems.
|
|
|
|
Please join me in thanking Ty and Master Mind for their support of the
|
|
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> 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> 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/capabilities<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>
|