mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-15 12:14:32 +01:00
5cf57190fb
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1606 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
436 lines
13 KiB
Plaintext
Executable File
436 lines
13 KiB
Plaintext
Executable File
Shorewall 2.1.8
|
|
|
|
----------------------------------------------------------------------
|
|
Problems Corrected since 2.0.3
|
|
|
|
1) A non-empty DEST entry in /etc/shorewall/tcrules will generate an
|
|
error and Shorewall fails to start.
|
|
|
|
2) A potential security vulnerablilty in the way that Shorewall
|
|
handles temporary files and directories has been corrected.
|
|
|
|
3) Two problems with logging NAT rules (DNAT and REDIRECT) could cause
|
|
startup failures.
|
|
|
|
4) Some users have reported the pkttype match option in iptables/
|
|
Netfilter failing to match certain broadcast packets. The result
|
|
is that the firewall log shows a lot of broadcast packets.
|
|
|
|
Users experiencing this problem can use PKTTYPE=No in
|
|
shorewall.conf to cause Shorewall to use IP address filtering of
|
|
broadcasts rather than packet type.
|
|
|
|
Problems Corrected since 2.1.0
|
|
|
|
1) The "check" command fails with the following message:
|
|
|
|
iptables: No chain/target/match by that name
|
|
|
|
Problems Corrected since 2.1.4
|
|
|
|
1) Per-interface options like 'norfc1918' are not applied to requests
|
|
that have been unencrypted as a result of an entry in the SPD.
|
|
|
|
Problems corrected since 2.1.6
|
|
|
|
1) Dynamic zones marked as 'ipsec' in /etc/shorewall/ipsec now work
|
|
correctly.
|
|
|
|
Problems corrected since 2.1.7
|
|
|
|
1) Fix parsing of ACTION with ":" but no log level (Richard Musil).
|
|
|
|
2) Fix parsing of PROTO column in /etc/shorewall/tcrules.
|
|
|
|
3) Packets that will be encrypted or that have been decrypted by IPSEC
|
|
are now exempted from the rules established by one-to-one NAT. This
|
|
allows tunnel mode IPSEC to work for local networks where some of
|
|
the systems use one-to-one NAT.
|
|
|
|
4) The shorewall.spec file now directs rpm to cause Shorewall to start
|
|
automatically at boot. This feature was inadvertently removed in
|
|
Shorewall 2.1.3.
|
|
|
|
-----------------------------------------------------------------------
|
|
Issues when migrating from Shorewall 2.0 to Shorewall 2.1:
|
|
|
|
1) Shorewall configuration files except shorewall.conf are now empty
|
|
(they contain only comments). If you wish to retain the defaults
|
|
in any of the following files, you should copy these files before
|
|
upgrading them then restore them after the upgrade:
|
|
|
|
/etc/shorewall/zones
|
|
/etc/shorewall/policy
|
|
/etc/shorewall/tos
|
|
|
|
2) The following builtin actions have been removed and have been
|
|
replaced by the new action logging implementation described in the
|
|
new features below.
|
|
|
|
logNotSyn
|
|
rLogNotSyn
|
|
dLogNotSyn
|
|
|
|
3) If shorewall.conf is upgraded to the latest version, it needs to be
|
|
modified to set STARTUP_ENABLED=Yes
|
|
|
|
4) The Leaf/Bering version of Shorewall was previously named:
|
|
|
|
shorwall-<version>.lrp
|
|
|
|
Beginning with 2.1, that file will now be named:
|
|
|
|
shorewall-lrp-<version>.tgz
|
|
|
|
Simply rename that file to 'shorwall.lrp' when installing it on your
|
|
LEAF/Bering system.
|
|
|
|
5) The ORIGINAL DEST column of the /etc/shorewall/rules file may no
|
|
longer contain a second (SNAT) address. You must use an entry in
|
|
/etc/shorewall/masq instead.
|
|
|
|
Example from Shorewall FAQ #1:
|
|
|
|
Prior to Shorewall 2.1:
|
|
|
|
/etc/shorewall/interfaces
|
|
|
|
loc eth1 detect routeback,...
|
|
|
|
/etc/shorewall/rules
|
|
|
|
DNAT loc loc:192.168.1.12 tcp 80 \
|
|
- 130.252.100.69:192.168.1.254
|
|
|
|
Shorewall 2.1 and Later:
|
|
|
|
/etc/shorewall/interfaces
|
|
|
|
loc eth1 detect routeback,...
|
|
|
|
/etc/shorewall/masq:
|
|
|
|
eth1 eth1 192.168.1.254 tcp 80
|
|
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
DNAT loc loc:192.168.1.12 tcp 80 \
|
|
- 130.252.100.69
|
|
|
|
-----------------------------------------------------------------------
|
|
New Features:
|
|
|
|
1) ICMP packets that are in the INVALID state are now dropped by the
|
|
Reject and Drop default actions. They do so using the new
|
|
'dropInvalid' builtin action.
|
|
|
|
2) The /etc/shorewall/masq file INTERFACE column now allows additional
|
|
options.
|
|
|
|
Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT
|
|
rules defined in the /etc/shorewall/nat file. If you preceed the
|
|
interface name with a plus sign ("+") then the rule will be
|
|
evaluated before one-to-one NAT.
|
|
|
|
Examples:
|
|
|
|
+eth0
|
|
+eth1:192.0.2.32/27
|
|
|
|
Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an
|
|
entry by following the interface name by ":" but no digit.
|
|
|
|
Examples:
|
|
|
|
eth0:
|
|
eth1::192.0.2.32/27
|
|
+eth3:
|
|
|
|
3) Similar to 2), the /etc/shorewall/nat file INTERFACE column now allows
|
|
you to override the setting of ADD_IP_ALIASES=Yes by following the
|
|
interface name with ":" but no digit.
|
|
|
|
4) All configuration files in the Shorewall distribution with the
|
|
exception of shorewall.conf are now empty. In particular, the
|
|
/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos
|
|
files now have no active entries. Hopefully this will stop the
|
|
questions on the support and development lists regarding why the
|
|
default entries are the way they are.
|
|
|
|
5) Previously, specifying a log level (and optionally a log tag) on a
|
|
rule that specified a user-defined (or Shorewall-defined) action
|
|
would log all traffic passed to the action. Beginning with this
|
|
release, specifying a log level in a rule that specifies a user-
|
|
or Shorewall-defined action will cause each rule in the action to
|
|
be logged with the specified level (and tag).
|
|
|
|
The extent to which logging of action rules occurs is goverend by
|
|
the following:
|
|
|
|
a) When you invoke an action and specify a log level, only those
|
|
rules in the action that have no log level will be changed to log
|
|
at the level specified at the action invocation.
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/action.foo:
|
|
|
|
ACCEPT - - tcp 22
|
|
bar:info
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
foo:debug fw net
|
|
|
|
Logging in the invoke 'foo' action will be:
|
|
|
|
ACCEPT:debug - - tcp 22
|
|
bar:info
|
|
|
|
b) If you follow the log level with "!" then logging will
|
|
be at that level for all rules recursively invoked by the action
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/action.foo:
|
|
|
|
ACCEPT - - tcp 22
|
|
bar:info
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
foo:debug! fw net
|
|
|
|
Logging in the invoke 'foo' action will be:
|
|
|
|
ACCEPT:debug - - tcp 22
|
|
bar:debug!
|
|
|
|
This change has an effect on extension scripts used with
|
|
user-defined actions. If you define an action 'acton' and you have
|
|
a /etc/shorewall/acton script then when that script is invoked,
|
|
the following three variables will be set for use by the script:
|
|
|
|
$CHAIN = the name of the chain where your rules are to be
|
|
placed. When logging is used on an action invocation,
|
|
Shorewall creates a chain with a slightly different name from
|
|
the action itself.
|
|
|
|
$LEVEL = Log level. If empty, no logging was specified.
|
|
|
|
$TAG = Log Tag.
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
acton:info:test
|
|
|
|
Your /etc/shorewall/acton file will be run with:
|
|
|
|
$CHAIN="acton1"
|
|
$LEVEL="info"
|
|
$TAG="test"
|
|
|
|
6) The /etc/shorewall/startup_disabled file is no longer created when
|
|
Shorewall is first installed. Rather, the variable STARTUP_ENABLED
|
|
is set to 'No' in /etc/shorewall/shorewall.conf. In order to get
|
|
Shorewall to start, that variable's value must be set to
|
|
'Yes'. This change accomplishes two things:
|
|
|
|
a) It prevents Shorewall from being started prematurely by the
|
|
user's initialization scripts.
|
|
|
|
b) It causes /etc/shorewall/shorewall.conf to be modified so that
|
|
it won't be replaced by upgrades using RPM.
|
|
|
|
7) Some additional support has been added for the 2.6 Kernel IPSEC
|
|
implementation. To use this support, you must have installed the
|
|
IPSEC policy match patch from Patch-0-Matic-ng. That patch affects
|
|
both your kernel and iptables.
|
|
|
|
There are two ways to specify that IPSEC is to be used when
|
|
communicating with a set of hosts; both methods involve the new
|
|
/etc/shorewall/ipsec file:
|
|
|
|
a) If encrypted communication is used with all hosts in a zone,
|
|
then you can designate the zone as an "ipsec" zone by placing
|
|
'Yes" in the IPSEC ONLY column in the /etc/shorewall/ipsec:
|
|
|
|
#ZONE IPSEC OPTIONS
|
|
# ONLY
|
|
vpn Yes
|
|
|
|
The hosts in the zone (if any) must be specified in
|
|
/etc/shorewall/hosts but you do not need to specify the 'ipsec'
|
|
option on the entries in that file (see below).
|
|
|
|
Dynamic zones involving IPSEC must use that technique.
|
|
|
|
Example:
|
|
|
|
Under 2.4 Kernel FreeS/Wan:
|
|
|
|
/etc/shorewall/zones:
|
|
|
|
net Net The big bad Internet
|
|
vpn VPN Remote Network
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
net eth0 ...
|
|
vpn ipsec0 ...
|
|
|
|
Under 2.6 Kernel with this new support:
|
|
|
|
/etc/shorewall/zones:
|
|
|
|
net Net The big bad Internet
|
|
vpn VPN Remote Network
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
net eth0 ...
|
|
|
|
/etc/shorewall/hosts:
|
|
|
|
vpn eth0:0.0.0.0/0
|
|
|
|
/etc/shorewall/ipsec
|
|
|
|
vpn Yes
|
|
|
|
b) If only part of the hosts in a zone require encrypted
|
|
communication, you may use of the new 'ipsec' option in
|
|
/etc/shorewall/hosts to designate those hosts.
|
|
|
|
Example:
|
|
|
|
Under 2.4 Kernel FreeS/Wan:
|
|
|
|
/etc/shorewall/zones:
|
|
|
|
net Net The big bad Internet
|
|
loc Local Extended local zone
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
net eth0 ...
|
|
loc eth1 ...
|
|
loc ipsec0 ...
|
|
|
|
Under 2.6 Kernel with this new support:
|
|
|
|
/etc/shorewall/zones:
|
|
|
|
net Net The big bad Internet
|
|
vpn VPN Remote Network
|
|
|
|
/etc/shorewall/interfaces:
|
|
|
|
net eth0 ...
|
|
loc eth1 ...
|
|
|
|
/etc/shorewall/hosts:
|
|
|
|
vpn eth0:0.0.0.0/0 ipsec,...
|
|
|
|
Regardless of which technique you choose, you can specify
|
|
additional SA options for the zone in the /etc/shorewall/ipsec
|
|
entry.
|
|
|
|
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
|
|
input-output, input and output characteristing of the security
|
|
policies to be used to decrypt (input) or encrypt (output) traffic
|
|
to/from the zone.
|
|
|
|
The available options are:
|
|
|
|
reqid[!]=<number> where <number> is specified using setkey(8) using
|
|
the 'unique:<number>' option for the SPD level.
|
|
|
|
spi[!]=<number> where <number> is the SPI of the SA. Since
|
|
different SAs are used to encrypt and decrypt traffic, this
|
|
option should only be listed in the IN OPTIONS and OUT OPTIONS
|
|
columns.
|
|
|
|
proto[!]=ah|esp|ipcomp
|
|
|
|
mode[!]=transport|tunnel
|
|
|
|
tunnel-src[!]=<address>[/<mask>] (only available with mode=tunnel)
|
|
|
|
tunnel-dst[!]=<address>[/<mask>] (only available with
|
|
mode=tunnel). Because tunnel source and destination are
|
|
dependent on the direction of the traffic, these options
|
|
should only appear in the IN OPTIONS and OUT OPTIONS columns.
|
|
|
|
strict (if specified, packets must match all policies;
|
|
polcies are delimited by 'next').
|
|
|
|
next (only available with strict)
|
|
|
|
Examples:
|
|
|
|
#ZONE IPSEC OPTIONS IN OUT
|
|
# ONLY OPTIONS OPTIONS
|
|
vpn Yes mode=tunnel,proto=esp spi=1000 spi=1001
|
|
loc No reqid=44,mode=transport
|
|
|
|
The /etc/shorewall/masq file has a new IPSEC column added. If you
|
|
specify Yes or yes in that column then the unencrypted packets will
|
|
have their source address changed. Otherwise, the unencrypted
|
|
packets will not have their source addresses changed. This column
|
|
may also contain a comma-separated list of the options specified
|
|
above in which case only those packets that will be encrypted
|
|
by an SA matching the given options will have their source address
|
|
changed.
|
|
|
|
8) To improve interoperability, tunnels of type 'ipsec' no longer
|
|
enforce the use of source port 500 for ISAKMP.
|
|
|
|
9) A new 'allowBcast' builtin action has been added -- it silently
|
|
allows broadcasts and multicasts.
|
|
|
|
10) The -c option in /sbin/shorewall commands is now deprecated. The
|
|
commands where -c was previously allowed now permit you to specify
|
|
a configuration directory after the command:
|
|
|
|
shorewall check [ <configuration-directory> ]
|
|
shorewall restart [ <configuration-directory> ]
|
|
shorewall start [ <configuration-directory> ]
|
|
|
|
11) Normally, when SNAT or MASQUERADE is applied to a tcp or udp
|
|
connection, Netfilter attempts to retain the source port
|
|
number. If it has to change to port number to avoid
|
|
<source address>,<source port> conflicts, it tries to do so
|
|
within port ranges ( < 512, 512-1023, and > 1023). You may
|
|
now specify an explicit range of source ports to be used
|
|
by following the address or address range (if any) in the
|
|
ADDRESS column with ":" and a port range in the format
|
|
<low-port>-<high-port>. You must specify either "tcp" or
|
|
"udp" in the PROTO column.
|
|
|
|
Examples 1 -- MASQUERADE with tcp source ports 4000-5000:
|
|
|
|
#INTERFACE SUBNET ADDRESS PROTO
|
|
eth0 192.168.1.0/24 :4000-5000 tcp
|
|
|
|
Example 2 -- SNAT with udp source ports 7000-8000:
|
|
|
|
#INTERFACE SUBNET ADDRESS PROTO
|
|
eth0 10.0.0.0/8 192.0.2.44:7000-8000 udp
|
|
|
|
12) You may now account by user/group ID for outbound traffic from the
|
|
firewall itself with entries in /etc/shorewall/accounting. Such
|
|
accounting rules must be placed in the OUTPUT chain.
|
|
|
|
See the comments at the top of /etc/shorewall/accounting for
|
|
details.
|
|
|
|
13) Shorewall now verifies that your kernel and iptables have physdev
|
|
match support if BRIDGING=Yes in shorewall.conf.
|
|
|
|
|