forked from extern/shorewall_code
e2e827cdbc
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@8079 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
499 lines
17 KiB
Plaintext
499 lines
17 KiB
Plaintext
Shorewall 4.1 Patch Release 4.
|
|
|
|
----------------------------------------------------------------------------
|
|
R E L E A S E 4 . 1 H I G H L I G H T S
|
|
----------------------------------------------------------------------------
|
|
1) Support is included for multiple internet providers through the same
|
|
ethernet interface.
|
|
|
|
2) Support for NFLOG has been added.
|
|
|
|
3) Enhanced operational logging.
|
|
|
|
4) The tarball installers now work under Cygwin.
|
|
|
|
Problems corrected in Shorewall 4.1.4.
|
|
|
|
1) Previously, a value of 0 was ignored in the TEST column of tcrules
|
|
and the MARK column of the rules files.
|
|
|
|
Also, the default mask for entries in these columns has been
|
|
changed from 0xFF to 0xFFFF for compatibility with Shorewall-shell.
|
|
|
|
2) The compilation date recorded in the firewall.conf file produced by
|
|
Shorewall-perl was previously mangled.
|
|
|
|
3) The following situation would result in unexpected behavior.
|
|
|
|
/etc/shorewall/zones:
|
|
|
|
#ZONE TYPE
|
|
fw firewall
|
|
net ipv4
|
|
loc ipv4
|
|
dmz ipv4
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
|
net ppp0
|
|
loc eth1
|
|
loc ppp+
|
|
dmz eth2
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
#ACTION SOURCE DEST PROTO DEST
|
|
# PORT(S)
|
|
ACCEPT net dmz tcp 80
|
|
REDIRECT loc 3128 tcp 80
|
|
|
|
The web server in the dmz (implied by the first rule) is
|
|
inaccessible from the 'net' zone because the REDIRECT rule
|
|
redirects all traffic arriving on 'ppp+' to local port 3128.
|
|
|
|
Shorewall 4.1.4 includes a fix for this problem that also requires
|
|
a configuration change.
|
|
|
|
The basic problem with the above configuration is that 'net' is a
|
|
sub-zone of 'loc' (since ppp0 is a subset of ppp+) but Shorewall
|
|
isn't able to recognize that fact.
|
|
|
|
By changing the /etc/shorewall/zones file to make the parent/child
|
|
relationship explicit, Shorewall will now know that 'net' is a
|
|
sub-zone of 'loc'.
|
|
|
|
/etc/shorewall/zones:
|
|
|
|
#ZONE TYPE
|
|
fw firewall
|
|
loc ipv4
|
|
net:loc ipv4
|
|
dmz ipv4
|
|
|
|
Be sure that there are no CONTINUE policies from net to another
|
|
zone and that IMPLICIT_CONTINUE=No (to prevent implicit CONTINUE
|
|
policies from 'net' to all other zones).
|
|
|
|
Other changes in Shorewall 4.1.4.
|
|
|
|
1) When installing on Cygwin, /etc/shorewall is no longer fully
|
|
populated. Rather, only the shorewall.conf and params files are
|
|
installed. As always, the full configuration file set is installed
|
|
in /usr/share/shorewall/configfiles.
|
|
|
|
2) Specifying a destination zone in a NAT-only rule now generates a
|
|
warning and the destination zone is ignored. NAT-only rules are:
|
|
|
|
NONAT
|
|
REDIRECT-
|
|
DNAT-
|
|
|
|
3) The /etc/shorewall/masq and /etc/shorewall/nat file now accept a
|
|
comma-separated list of interface names where before only a single
|
|
interface name could be listed (Shorewall-perl only).
|
|
|
|
This feature is not for beginners. It iterates over the
|
|
list of interfaces, substituting each interface in place of the
|
|
list and processing the resulting entry according to the semantics
|
|
of earlier Shorewall versions. If you don't know where to use this,
|
|
don't try.
|
|
|
|
Example 1:
|
|
|
|
/etc/shorewall/masq:
|
|
|
|
#INTERFACE SOURCE ADDRESS
|
|
eth0,eth1 eth2 1.2.3.4
|
|
|
|
equivalent to:
|
|
|
|
#INTERFACE SOURCE ADDRESS
|
|
eth0 eth2 1.2.3.4
|
|
eth1 eth2 1.2.3.4
|
|
|
|
Example 2:
|
|
|
|
/etc/shorewall/masq:
|
|
|
|
#INTERFACE SOURCE ADDRESS
|
|
eth0,eth1::192.168.1.0/24 eth2 1.2.3.4
|
|
|
|
equivalent to:
|
|
|
|
#INTERFACE SOURCE ADDRESS
|
|
eth0::192.168.1.0/24 eth2 1.2.3.4
|
|
eth1::192.168.1.0/24 eth2 1.2.3.4
|
|
|
|
Example 3:
|
|
|
|
/etc/shorewall/nat:
|
|
|
|
#EXTERNAL INTERFACE INTERNAL
|
|
206.124.146.178 eth0,wlan0 192.168.1.3
|
|
|
|
equivalent to:
|
|
|
|
#EXTERNAL INTERFACE INTERNAL
|
|
206.124.146.178 eth0 192.168.1.3
|
|
206.124.146.178 wlan0 192.168.1.3
|
|
|
|
4) Previously, the INTERFACE name used in the masq, nat and netmap
|
|
files had to exactly match the name of an interface from the
|
|
interfaces file. Beginning with Shorewall-perl 4.1.4, the
|
|
interface may loosely match a wildcard entry in the interfaces
|
|
file.
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
vpn tun+
|
|
|
|
/etc/shorewall/masq:
|
|
|
|
tun1 192.168.4.0/24
|
|
|
|
Migration Issues.
|
|
|
|
1) Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero
|
|
mark values < 256 to be assigned in the OUTPUT chain. This has been
|
|
changed so that only high mark values may be assigned
|
|
there. Packet marking rules for traffic shaping of packets
|
|
originating on the firewall must be coded in the POSTROUTING table.
|
|
|
|
2) Previously, Shorewall did not range-check the value of the
|
|
VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.1:
|
|
|
|
a) A VERBOSITY setting outside the range -1 through 2 is rejected.
|
|
b) After the -v and -q options are applied, the resulting value is
|
|
adjusted to fall within the range -1 through 2.
|
|
|
|
3) Specifying a destination zone in a NAT-only rule now generates a
|
|
warning and the destination zone is ignored. NAT-only rules are:
|
|
|
|
NONAT
|
|
REDIRECT-
|
|
DNAT-
|
|
|
|
New Features in Shorewall 4.1.
|
|
|
|
1) Shorewall 4.1 contains experimental support for multiple Internet
|
|
providers through a single ethernet interface. Configuring two
|
|
providers through a single interface differs from two providers
|
|
through two interfaces in several ways.
|
|
|
|
a) Only ethernet (or ethernet-like) interfaces can be used. For
|
|
inbound traffic, the MAC addresses of the gateway routers is used
|
|
to determine which provider a packet was received through. Note
|
|
that only routed traffic can be categorized using this technique.
|
|
|
|
b) You must specify the address on the interface that corresponds to
|
|
a particular provider in the INTERFACE column by following the
|
|
interface name with a colon (":") and the address.
|
|
|
|
c) Entries in /etc/shorewall/masq must be qualified by the provider
|
|
name (or number).
|
|
|
|
d) This feature requires Realm Match support in your kernel and
|
|
iptables. If you use a capabilities file, you need to regenerate
|
|
the file with Shorewall 4.1 or Shorewall-lite 4.1.
|
|
|
|
e) You must add route_rules entries for networks that are accessed
|
|
through a particular provider.
|
|
|
|
f) If you have additional IP addresses through either provider,
|
|
you must add route_rules to direct traffic FROM each of those
|
|
addresses through the appropriate provider.
|
|
|
|
g) You must add MARK rules for any traffic that you know originates
|
|
from a particular provider.
|
|
|
|
Example:
|
|
|
|
Providers Blarg (1) and Avvanta (2) are both connected to
|
|
eth0. The firewall's IP address with Blarg is 206.124.146.176/24
|
|
(gateway 206.124.146.254) and the IP address from Avvanta is
|
|
130.252.144.8/24 (gateway 130.252.144.254). We have a second IP
|
|
address (206.124.146.177) from Blarg.
|
|
|
|
/etc/shorewall/providers:
|
|
|
|
#PROVIDER NUMBER MARK DUPLICATE INTERFACE GATEWAY
|
|
Blarg 1 1 main eth0:206.124.146.176 206.124.146.254 ...
|
|
Avvanta 2 2 main eth0:130.252.144.8 130.252.144.254 ...
|
|
|
|
/etc/shorewall/masq:
|
|
|
|
#INTERFACE SOURCE ADDRESS
|
|
eth0(Blarg) 130.252.144.8 206.124.146.176
|
|
eth0(Avvanta) 206.124.146.176 130.252.144.8
|
|
eth0(Blarg) eth1 206.124.146.176
|
|
eth0(Avvanta) eth1 130.252.144.8
|
|
|
|
/etc/shorewall/route_rules:
|
|
|
|
#SOURCE DEST PROVIDER PRIORITY
|
|
- 206.124.146.0/24 Blarg 1000
|
|
- 130.252.144.0/24 Avvanta 1000
|
|
206.124.146.177 - Blarg 26000
|
|
|
|
/etc/shorewall/tcrules
|
|
|
|
#MARK/CLASSIFY SOURCE DEST
|
|
1 eth0:206.124.146.0/24 0.0.0.0/0
|
|
2 eth0:130.242.144.0/24 0.0.0.0/0
|
|
|
|
2) You may now include the name of a table (nat, mangle or filter) in
|
|
a 'shorewall refresh' command by following the table name with a
|
|
colon (e.g., mangle:). This causes all non-builtin chains in the
|
|
table to be reloaded.
|
|
|
|
Example:
|
|
|
|
shorewall refresh nat:
|
|
|
|
3) When no chain name is given to the 'shorewall refresh' command, the
|
|
mangle table is refreshed along with the blacklist chain (if
|
|
any). This allows you to modify /etc/shorewall/tcrules and install
|
|
the changes using 'shorewall refresh'.
|
|
|
|
4) Support for the NFLOG log target has been added. NFLOG is a
|
|
successor to ULOG. In addition, both ULOG and NFLOG may be followed
|
|
by a list of up to three numbers in parentheses.
|
|
|
|
The first number specifies the netlink group (1-32). If omitted
|
|
(e.g., NFLOG(,0,10)) then a value of 1 is assumed.
|
|
|
|
The second number specifies the maximum number of bytes to copy. If
|
|
omitted, 0 (no limit) is assumed.
|
|
|
|
The third number specifies the number of log messages that should
|
|
be buffered in the kernel before they are sent to user space. The
|
|
default is 1.
|
|
|
|
Examples:
|
|
|
|
/etc/shorewall/shorewall.conf:
|
|
|
|
MACLIST_LOG_LEVEL=NFLOG(1,0,1)
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
ACCEPT:NFLOG(1,0,1) vpn fw tcp ssh,time,631,8080
|
|
|
|
5) Shorewall-perl 4.1 implements an alternative syntax for macro
|
|
parameters and for the NFQUEUE queue number. Rather than following
|
|
the macro name (or NFQUEUE) with a slash ("/") and the parameter,
|
|
the parameter may be enclosed in parentheses.
|
|
|
|
Examples -- each pair shown below are equivalent:
|
|
|
|
DNS/ACCEPT DNS(ACCEPT)
|
|
NFQUEUE/3 NFQUEUE(3)
|
|
|
|
The old syntax will still be accepted but will cease to be documented
|
|
in some future Shorewall release.
|
|
|
|
6) Shorewall 4.1 contains enhanced operational logging capabilities
|
|
through a set of related enhancements to Shorewall-common and
|
|
Shorewall-perl. The enhancements are not supported by
|
|
Shorewall-shell nor are they supported by Shorewall-lite except
|
|
when the script is compiled using Shorewall-perl.
|
|
|
|
a) The STARTUP_LOG option in /etc/shorewall/shorewall.conf gives
|
|
the name of the Shorewall operational log. The log will be
|
|
created if it does not exist.
|
|
|
|
b) The LOG_VERBOSITY option in /etc/shorewall/shorewall.conf gives
|
|
the verbosity at which logging will occur. It uses the same
|
|
value range as VERBOSITY:
|
|
|
|
-1 Do not log
|
|
0 Almost quiet
|
|
1 Only major steps
|
|
2 Verbose
|
|
|
|
c) An absolute VERBOSITY may be specified on the command line
|
|
using the -v option followed by -1,0,1 or 2.
|
|
|
|
Example:
|
|
|
|
shorewall -v2 check
|
|
|
|
d) The /etc/init.d/shorewall script supplied with the
|
|
shorewall.net packages sets '-v0' as the default. This may be
|
|
overridden with the OPTIONS setting in /etc/defaults/shorewall or
|
|
/etc/sysconfig/shorewall.
|
|
|
|
Logging occurs on both Shorewall-perl and the generated script when
|
|
the following commands are issued:
|
|
|
|
start
|
|
restart
|
|
refresh
|
|
|
|
Messages in the log are always timestamped.
|
|
|
|
This change implemented two new options to the Shorewall-perl
|
|
compiler (/usr/share/shorewall-perl/compiler.pl).
|
|
|
|
--log=<logfile>
|
|
--log_verbosity={-1|0-2}
|
|
|
|
The --log option is ignored when --log_verbosity is not supplied or
|
|
is supplied with value -1.
|
|
|
|
To avoid a proliferation of parameters to
|
|
Shorewall::Compiler::compile(), that function has been changed to
|
|
use named parameters. Parameter names are:
|
|
|
|
object Object file. If omitted or '', the
|
|
configuration is syntax checked.
|
|
directory Directory. If omitted or '', configuration
|
|
files are located using
|
|
CONFIG_PATH. Otherwise, the directory named by
|
|
this parameter is searched first.
|
|
verbosity Verbosity; range -1 to 2
|
|
timestamp 0|1 -- timestamp messages.
|
|
debug 0|1 -- include stack trace in warning/error
|
|
messages.
|
|
export 0|1 -- compile for export.
|
|
chains List of chains to be reloaded by 'refresh'.
|
|
log File to log compiler messages to.
|
|
log_verbosity Log Verbosity; range -1 to 2.
|
|
|
|
Those parameters that are supplied must have defined values.
|
|
|
|
Defaults are:
|
|
|
|
object '' ('check' command)
|
|
directory ''
|
|
verbosity 1
|
|
timestamp 0
|
|
debug 0
|
|
export 0
|
|
chains ''
|
|
log ''
|
|
log_verbosity -1
|
|
|
|
|
|
Example:
|
|
|
|
use lib '/usr/share/shorewall-perl/';
|
|
use Shorewall::Compiler;
|
|
|
|
compiler( object => '/root/firewall',
|
|
log => '/root/compile.log',
|
|
log_verbosity => 2 );
|
|
|
|
7) Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero
|
|
mark values < 256 to be assigned in the OUTPUT chain. This has been
|
|
changed so that only high mark values may be assigned
|
|
there. Packet marking rules for traffic shaping of packets
|
|
originating on the firewall must be coded in the POSTROUTING table.
|
|
|
|
8) Previously, Shorewall did not range-check the value of the
|
|
VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.1:
|
|
|
|
a) A VERBOSITY setting outside the range -1 through 2 is rejected.
|
|
b) After the -v and -q options are applied, the resulting value is
|
|
adjusted to fall within the range -1 through 2.
|
|
|
|
9) The tcdevices file has been extended to include an OPTIONS
|
|
column. Currently only a single option is defined.
|
|
|
|
classify When specified, you must use explicit CLASSIFY tcrules
|
|
to classify traffic by class. Shorewall will not create
|
|
any CLASSIFY rules to classify traffic by mark value.
|
|
|
|
The 'classify' option should be specified when you want to do all
|
|
classification using CLASSIFY tcrules. Because CLASSIFY is not a
|
|
terminating target, every packet passes through all CLASSIFY
|
|
rules. 'classify' can prevent packets from having to pass through
|
|
useless additional rules.
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/tcdevices
|
|
|
|
#INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS
|
|
$EXT_IF 1300kbit 384kbit classify
|
|
|
|
/etc/shorewall/tcclasses
|
|
|
|
#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
|
|
$EXT_IF 10 5*full/10 full 1 tcp-ack,tos-minimize-delay
|
|
$EXT_IF 20 2*full/10 6*full/10 2 default
|
|
$EXT_IF 30 2*full/10 6*full/10 3
|
|
|
|
/etc/shorewall/tcrules
|
|
|
|
#MARK SOURCE DEST PROTO PORT(S) SOURCE
|
|
# PORT(S)
|
|
1:110 192.168.0.0/22 $EXT_IF
|
|
1:130 206.124.146.177 $EXT_IF tcp - 873
|
|
|
|
This example shows my own simple traffic shaping configuration. I
|
|
have three classes; one for traffic from our local network, one for
|
|
rsync from the master shorewall.net server, and one for all other
|
|
DMZ traffic. I use CLASSIFY rules to assign traffic to the first
|
|
and third class and let the rest default to the second class.
|
|
|
|
10) COMMENT lines are now supported in macro bodies by Shorewall-perl
|
|
and are ignored by the Shorewall-shell compiler. The standard
|
|
macros (with the exception of macro.Drop and macro.Reject) have
|
|
been modified to include a COMMENT line describing the macro.
|
|
|
|
COMMENT lines in macros work slightly differently from COMMENT
|
|
lines in other files. COMMENT lines in macros are ignored if
|
|
COMMENT support is not available or if there was a COMMENT in use
|
|
when the top-level macro was invoked. This allows the
|
|
following:
|
|
|
|
/usr/share/shorewall/macro.SSH:
|
|
|
|
#ACTION SOURCE PROTO DEST SOURCE RATE USER/
|
|
# PORT(S) PORT(S) LIMIT GROUP
|
|
COMMENT SSH
|
|
PARAM - - tcp 22
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
COMMENT Allow SSH from home
|
|
SSH/ALLOW net:$MYIP $FW
|
|
COMMENT
|
|
|
|
The comment line in macro.SSH will not override the
|
|
COMMENT line in the rules file and the generated rule will show
|
|
|
|
/* Allow SSH from home */
|
|
|
|
when displayed through the Shorewall show and dump commands.
|
|
|
|
11) If the program named in SHOREWALL_SHELL doesn't exist or is not
|
|
executable, Shorewall and Shorewall-lite now both fall back to
|
|
/bin/sh after issuing a warning message. Previously, both
|
|
terminated with a fatal error.
|
|
|
|
12) Shorewall-perl now generates fatal error conditions when there are
|
|
no IPv4 zones defined and when there are no interfaces defined.
|
|
|
|
13) Shorewall now unconditionally uses tc filter rules to classify
|
|
traffic by MARK value. Previously, Shorewall used the CLASSIFY
|
|
target in the POSTROUTING chain if it was available.
|
|
|
|
14) The Shorewall-common installer (install.sh) now works on Windows
|
|
under Cygwin.
|
|
|
|
To install Shorewall-perl under Cygwin:
|
|
|
|
$ tar -xf shorewall-perl-4.1.3.tar.bz2
|
|
$ tar -xf shorewall-common-4.1.3.tar.bz2
|
|
$ cd shorewall-perl-4.1.3
|
|
$ USER=<your user id> GROUP=None ./install.sh
|
|
$ cd ../shorewall-common-4.1.3
|
|
$ USER=<your user id> GROUP=None ./install.sh
|
|
|
|
The 'shorewall' program is installed in /bin/ (a.k.a, /usr/bin/).
|