forked from extern/shorewall_code
b9fcda9812
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@6265 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
468 lines
18 KiB
Plaintext
468 lines
18 KiB
Plaintext
Shorewall 3.9.7
|
|
----------------------------------------------------------------------------
|
|
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
|
|
3.9.2, there are the following packages:
|
|
|
|
- Shorewall ( common files )
|
|
- Shorewall-shell ( the shell-based compiler )
|
|
- Shorewall-perl (the Perl-based compiler )
|
|
|
|
You must install Shorewall and at least one of the compiler packages
|
|
(you may install them both).
|
|
|
|
Problems corrected in 3.9.7.
|
|
|
|
1) Several problems relating to exclusion in the hosts file have been
|
|
corrected.
|
|
|
|
Symptoms included:
|
|
|
|
Access to an undefined value at Rules.pm line 1656.
|
|
Incorrect rule generation.
|
|
|
|
2) Specifying 'maclist' in the hosts file's OPTION column now works.
|
|
|
|
3) A number of problems with handling the hosts file have been
|
|
corrected. These problems are characterized by Perl run-time
|
|
errors and incorrect rules, including:
|
|
|
|
- Not an ARRAY reference at
|
|
/usr/share/shorewall-perl/Shorewall/Rules.pm line 1420.
|
|
|
|
- -A eth0_fwd -s 192.168.0.0/24-m policy --dir in --pol ipsec -j
|
|
HASH(0x8345924)->n{name}
|
|
|
|
4) A value of 'detect' in the GATEWAY column of the providers file no
|
|
longer generates an error during [re]start.
|
|
|
|
Other changes in Shorewall 3.9.6.
|
|
|
|
None.
|
|
|
|
Migration Considerations:
|
|
|
|
1) You cannot simply upgrade your existing Shorewall package. You must
|
|
upgrade Shorewall *and* install one or both of the compilers.
|
|
|
|
If you attempt to upgrade using the RPM, you get this result:
|
|
|
|
gateway:~ # rpm -Uvh shorewall-3.9.2-1.noarch.rpm
|
|
error: Failed dependencies:
|
|
shorewall_compiler is needed by shorewall-3.9.2-1.noarch
|
|
gateway:~ #
|
|
|
|
You must either:
|
|
|
|
rpm -U shorewall-3.9.2.noarch.rpm shorewall-shell-3.9.2.noarch.rpm
|
|
|
|
or
|
|
|
|
rpm -U shorewall-3.9.2.noarch.rpm shorewall-perl-3.9.2.noarch.rpm
|
|
|
|
or
|
|
rpm -i shorewall-shell-3.9.2.noarch.rpm
|
|
rpm -U shorewall-3.9.2.noarch.rpm
|
|
|
|
or
|
|
rpm -i shorewall-perl-3.9.2.noarch.rpm
|
|
rpm -U shorewall-3.9.2.noarch.rpm
|
|
|
|
If you are upgrading using the tarball, you must install either
|
|
shorewall-shell or shorewall-perl before you upgrade
|
|
Shorewall. 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.
|
|
|
|
----------------------------------------------------------------------------
|
|
N E W F E A T U R E S
|
|
----------------------------------------------------------------------------
|
|
1) Shorewall-perl
|
|
|
|
This companion product to Shorewall 3.4.2 and later includes a complete
|
|
rewrite of the compiler in Perl.
|
|
|
|
I decided to make Shorewall-perl a separate product 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.
|
|
|
|
c) By allowing Shorewall-perl to co-exist with the current
|
|
Shorewall stable release (3.4), I'm hoping that the new compiler
|
|
will get more testing and validation than it would if I were to
|
|
package it with a new development version of Shorewall itself.
|
|
|
|
d) Along the same vein, I think that users will be more likely to
|
|
experiment with the new compiler if they can easily fall back to
|
|
the old one if things get sticky.
|
|
------------------------------------------------------------------------
|
|
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) Use of the perl compiler 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. Some of these will probably go away by first
|
|
official release but most will not.
|
|
|
|
a) The Perl-based compiler requires the following capabilities in your
|
|
kernel and iptables.
|
|
|
|
- addrtype match (may be relaxed later)
|
|
- multiport match (will not be relaxed)
|
|
|
|
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) BRIDGING=Yes is not supported. The kernel code necessary to
|
|
support this option was removed in Linux kernel 2.6.20.
|
|
|
|
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. This will be relaxed if and when the addrtype
|
|
match requirement is relaxed.
|
|
|
|
e) Because the compiler is now written in Perl, your compile-time
|
|
extension scripts from earlier versions will no longer work.
|
|
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.
|
|
|
|
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';
|
|
|
|
f) The 'refresh' command is now synonymous with 'restart'.
|
|
|
|
g) Some run-time scripts will need to be changed to write their
|
|
iptables commands to file descriptor 3 in iptables-restore
|
|
format rather than running those commands.
|
|
|
|
maclog
|
|
|
|
Details to follow.
|
|
|
|
Some run-time scripts are simply eliminated because they no
|
|
longer make any sense under Shorewall-perl:
|
|
|
|
initdone - The these two scripts assumed a model where the
|
|
continue chains were built in parallel. In the
|
|
iptables-restore model, chains are built serially
|
|
within tables and tables are build serially.
|
|
|
|
refresh - The 'refresh' command is the same as 'restart'
|
|
refreshed
|
|
|
|
h) 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.
|
|
|
|
i) 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.
|
|
|
|
j) 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.
|
|
|
|
h) 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.
|
|
|
|
i) DELAYBLACKLISTLOAD=Yes is not supported. The entire ruleset is
|
|
atomically loaded with one execution of iptables-restore.
|
|
|
|
j) MAPOLDACTIONS=Yes is not supported. People should have converted
|
|
to using macros by now.
|
|
|
|
k) The pre Shorewall-3.0 format of the zones file is not supported;
|
|
neither is the /etc/shorewall/ipsec file.
|
|
|
|
l) 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.
|
|
|
|
m) 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 ...
|
|
|
|
2) An 'optional' option has been added to
|
|
/etc/shorewall/interfaces. 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.
|
|
|
|
3) 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 '+').
|
|
|
|
4) 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.
|
|
|
|
5) The LOG_MARTIANS and ROUTE_FILTER options are now tri-valued.
|
|
|
|
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.
|
|
|
|
6) 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.
|
|
|
|
7) 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.
|
|
|
|
8) SOURCE and DEST are now reserved zone names to avoid problems with
|
|
bi-directional macro definitions which use these as names as key
|
|
words.
|
|
|
|
----------------------------------------------------------------------------
|
|
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
|
|
----------------------------------------------------------------------------
|
|
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.
|
|
|
|
If you install Shorewall-perl under Shorewall 3.9.2 or later, you can
|
|
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
|
|
|
|
Regardless of the setting of SHOREWALL_COMPILER, there is one change in
|
|
Shorewall operation that is triggered simply by installing
|
|
shorewall-perl. Your params file will be processed during compilation
|
|
with the shell's '-a' option which causes any variables that you set
|
|
or create in that file to be automatically exported. Since the params
|
|
file is processed before shorewall.conf, using -a insures that the
|
|
settings of your params variables are available to the new compiler
|
|
should its use be specified in shorewall.conf.
|
|
|