forked from extern/shorewall_code
d34d0a5dfa
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@9557 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
206 lines
7.1 KiB
Plaintext
206 lines
7.1 KiB
Plaintext
Shorewall 4.3.6
|
|
|
|
Shorewall 4.3 is the development thread for Shorewall 4.4 which will be
|
|
released late in 2009.
|
|
|
|
----------------------------------------------------------------------------
|
|
R E L E A S E 4 . 3 H I G H L I G H T S
|
|
----------------------------------------------------------------------------
|
|
|
|
1) Support for Shorewall-shell has been discontinued. Shorewall-perl
|
|
has been combined with Shorewall-common to produce a single
|
|
Shorewall package.
|
|
|
|
2) The interfaces file OPTIONs have been extended to largely remove the
|
|
need for the hosts file.
|
|
|
|
3) It is now possible to define PREROUTING and OUTPUT marking rules
|
|
that cause new connections to use the same provider as an existing
|
|
connection of the same kind.
|
|
|
|
4) Shorewall now supports NOTRACK rules (this feature will also be
|
|
released in Shorewall 4.2.7).
|
|
|
|
Problems corrected in 4.3.6
|
|
|
|
1) The shorewall6 dump command now correctly displays the installed
|
|
Shorewall version.
|
|
|
|
2) Previously, the 'start' command set the permission flags on
|
|
/var/lib/shorewall*/state so that it could be read by
|
|
non-root users while the 'stop' command set the permissions such
|
|
that the file could not be read by those users.
|
|
|
|
Beginning with 4.3.6, both commands will secure the file for
|
|
root-only access. If you want the file to be world-readable, then
|
|
add
|
|
|
|
chmod 744 /var/lib/shorewall*/state
|
|
|
|
To your /etc/shorewall*/started, /etc/shorewall*/stopped and
|
|
/etc/shorewall*/restored files.
|
|
|
|
3) If nets=(<single address>) was specified in
|
|
/etc/shorewall/interfaces then the specification was ignored.
|
|
|
|
4) Shorewall6 compilation failed with this error:
|
|
|
|
ERROR: Unable to open /usr/share/shorewall6/prog.header6:
|
|
No such file or directory
|
|
|
|
Known Problems Remaiining:
|
|
|
|
None.
|
|
|
|
New Features in Shorewall 4.3.6
|
|
|
|
1) To allow bypassing of connection tracking for certain traffic,
|
|
/etc/shorewall/notrack and /etc/shorewall6/notrack files have been
|
|
added.
|
|
|
|
Columns in the file are:
|
|
|
|
SOURCE - <zone>[:<interface>][:<address list>]
|
|
|
|
DEST - [<address list>]
|
|
|
|
PROTO - <protocol name or number>
|
|
|
|
DEST PORT(S) - <port number list>
|
|
|
|
SOURCE PORT(S) - <port number list>
|
|
|
|
USER/GROUP - [<user>][:<group>]
|
|
|
|
May only be specified if the SOURCE <zone> is $FW.
|
|
|
|
Traffic that matches all given criteria will not be subject to
|
|
connection tracking. For such traffic, your policies and/or rules
|
|
must deal with ALL of the packets involved, in both the original
|
|
and the opposite directions. All untracked traffic is passed
|
|
through the relevant rules in the NEW section of the rules
|
|
file. Untracked encapsulated tunnel traffic can be handled by
|
|
entries in /etc/shorewall/tunnels just like tracked traffic
|
|
is. Because every packet of an untracked connection must pass
|
|
through the NEW section rules, it is suggested that rules that deal
|
|
with untracked traffic should appear at the top of the file.
|
|
|
|
Example:
|
|
|
|
/etc/shorewall/tunnels:
|
|
|
|
#TYPE ZONE GATEWAY
|
|
6to4 net
|
|
|
|
/etc/shorewall/notrack
|
|
|
|
#SOURCE DEST PROTO DEST SOURCE USER/
|
|
# PORT(S) PORT(S) GROUP
|
|
net:!192.88.99.1 - 41
|
|
|
|
Given that 192.88.99.1 is an anycast address, many hosts can
|
|
respond to outward traffic to that address. The entry in
|
|
/etc/shorewall/tunnels allows protocol 41 net<->fw. The entry in
|
|
/etc/shorewall/notrack prevents the inbound traffic from creating
|
|
additional useless conntrack entries.
|
|
|
|
As part of this change, the 'show' command is enhanced to support a
|
|
'show raw' command that is an alias for 'show -t raw'. The raw
|
|
table is where NOTRACK rules are created. The dump command is also
|
|
enhanced to display the contents of the raw table.
|
|
|
|
New Features in Shorewall 4.3
|
|
|
|
1) The Shorewall packaging has been completely revamped in Shorewall
|
|
4.3.
|
|
|
|
The new packages are:
|
|
|
|
- Shorewall. Includes the former Shorewall-common and
|
|
Shorewall-perl packages. Includes everything needed
|
|
to create an IPv4 firewall.
|
|
|
|
- Shorewall6. Requires Shorewall. Adds the components necessary to
|
|
create an IPv6 firewall.
|
|
|
|
- Shorewall-lite
|
|
|
|
May be installed on a firewall system to run
|
|
IPv4 firewall scripts generated by Shorewall.
|
|
|
|
- Shorewall6-lite
|
|
|
|
May be installed on a firewall system to run
|
|
IPv6 firewall scripts generated by Shorewall.
|
|
|
|
2) The interfaces file supports a new 'nets=' option. This option
|
|
allows users to restrict a zone's definition to particular networks
|
|
through an interface without having to use the hosts file.
|
|
|
|
Example interfaces file:
|
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
|
loc eth3 detect dhcp,logmartians=1,routefilter=1,nets=172.20.1.0/24
|
|
dmz eth4 detect logmartians=1,routefilter=1,nets=206.124.146.177
|
|
net eth0 detect dhcp,blacklist,tcpflags,optional,routefilter=0,nets=(!172.20.0.0/24,206.124.146.177)
|
|
net eth2 detect dhcp,blacklist,tcpflags,optional,upnp,routefilter=0,nets=(!172.20.0.0/24,206.124.146.177)
|
|
loc tun+ detect nets=172.20.0.0/24
|
|
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
|
|
|
|
Note that when more than one network address is listed, the list
|
|
must be enclosed in parentheses. Notice also that exclusion may be
|
|
used.
|
|
|
|
The first entry in the above interfaces file is equivalent to the
|
|
following:
|
|
|
|
interfaces:
|
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
|
- eth0 detect dhcp,logmartians=1,routefilter=1
|
|
|
|
hosts:
|
|
|
|
#ZONE HOST(S) OPTIONS
|
|
loc $INT_IF:192.20.1.0/24 broadcast
|
|
|
|
Note that the 'broadcast' option is automatically assumed and need
|
|
not be explicitly specified.
|
|
|
|
3) Some websites run applications that require multiple connections
|
|
from a client browser. Where multiple 'balanced' providers are
|
|
configured, this can lead to problems when some of the connections
|
|
are routed through one provider and some through another.
|
|
|
|
To work around this issue, the SAME target has been added to
|
|
/etc/shorewall/tcrules. SAME may be used in the PREROUTING and
|
|
OUTPUT chains. When used in PREROUTING, it causes matching
|
|
connections from an individual local system to all use the same
|
|
provider.
|
|
|
|
For example:
|
|
|
|
SAME:P 192.168.1.0/24 - tcp 80,443
|
|
|
|
If a host in 192.168.1.0/24 attempts a connection on TCP port 80 or
|
|
443 and it has sent a packet on either of those ports in the last
|
|
five minutes then the new connection will use the same provider as
|
|
the connection over which that last packet was sent.
|
|
|
|
When used in the OUTPUT chain, it causes all matching connections
|
|
to an individual remote system to all use the same provider.
|
|
|
|
For example:
|
|
|
|
SAME $FW - tcp 80,443
|
|
|
|
If the firewall attempts a connection on TCP port 80 or
|
|
443 and it has sent a packet on either of those ports in the last
|
|
five minutes to the same remote system then the new connection will
|
|
use the same provider as the connection over which that last packet
|
|
was sent.
|
|
|
|
Important note: SAME only works with providers that have the
|
|
'track' option specified in /etc/shorewall/providers.
|
|
|