Shorewall News and
Announcements
Tom Eastep
Copyright © 2001-2005 Thomas M. Eastep
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 “GNU Free Documentation
License”.
2005-09-12
09/12/2005 Shorewall 2.4.4
Problems Corrected
- An incorrect comment in the /etc/shorewall/proxyarp file
has been removed.
- The message generated when a duplicate policy has been
entered is now more informative. Previously, only the POLICY
column contents appeared in the message. Now the SOURCE, DEST
and POLICY column contents are shown.
- Shorewall now clears the Netfilter "raw" table during
"shorewall [re]start", "shorewall stop" and "shorewall clear"
processing.
New Features
- Tunnel types "openvpnserver" and "openvpnclient" have
been added to reflect the introduction of client and server
OpenVPN configurations in OpenVPN 2.0.
- The COMMAND variable is now set to 'restore' in restore
scripts. The value of this variable is sometimes of interest
to programmers providing custom /etc/shorewall/tcstart
scripts.
08/16/2005 Shorewall 2.4.3
Problems Corrected:
- Shorewall is no longer dependent on the 'which'
utility.
- The 'shorewall add' command failed if there existed a
zone in the configuration that specified the 'ipsec' option
in /etc/shorewall/hosts.
- Shorewall is no longer dependent on /bin/echo.
- A CLASSIFY rule with $FW in the SOURCE column
(tcrules) no longer results in a "shorewall start"
error.
- You may now use port lists in the DEST PORT and SOURCE
PORT columns of the /etc/shorewall/accounting file.
- The "shorewall show capabilities" command now accurately
reports the availability of "Packet type match" independent
of the setting of PKTTYPE in shorewall.conf.
- Thanks to Tuomo Soini, all of the files have been
siginificantly cleaned up in terms of formatting and extra
white-space.
New Features:
- New Allow.Submission and Allow.NTPbrd actions have been
added. Users of the Allow.NTP action that use NTP
broadcasting should switch to use of Allow.NTPbrd
instead.
- The kernel version string is now included in the output
of "shorewall status".
07/30/2005 Shorewall 2.2.6
Problems Corrected:
- MACLIST_TTL Vulnerability
fix.
- TCP_FLAGS_LOG_LEVEL=ULOG breaks with recent versions of
iptables.
- The bogons file has been updated to reflect recent IANA
allocations.
07/21/2005 Shorewall 2.4.2
Problems Corrected:
- The /etc/shorewall/hosts file now includes information
about defining a zone using one or more ipsets.
- A vulnerability involving MACLIST_TTL
> 0 or MACLIST_DISPOSITION=ACCEPT has been
corrected.
- It is now possible to specify !<address> in the
SUBNET column of /etc/shorewall/masq. Previously, it was
necessary to write 0.0.0.0/0!<address>.
- When <network1>!<network2> was specified in
the SUBNET column of /etc/shorewall/masq, IPSEC policies were
not correctly applied to the resulting rules. This usually
resulted in IPSEC not working through the interface specified
in the INTERFACES column.
New Features:
-
A 'loose' provider option has been added. If you wish to be
able to use marking to specify the gateway used by
connections originating on the firewall itself, the specify
'loose' for each provider. It has bee reported that 'loose'
may break the effect of 'track' so beware if you need
'track' functionality (you shouldn't be originating many
connections from your firewall to the net anyway).
To use 'loose', you also need to add two entries in
/etc/shorewall/masq:
#INTERFACE SUBNET ADDRESS
$IF_ISP1 $IP_ISP2 $IP_ISP1
$IF_ISP2 $IP_ISP1 $IP_ISP2
where:
$IF_ISP1 is the interface to ISP 1.
$IF_ISP2 is the interface to ISP 2.
$IP_ISP1 is the IP address of $IF_ISP1
$IP_ISP2 is the IP address of $IF_ISP2
- /sbin/shorewall now issues a warning each time that it
finds that startup is disabled.
- A new COPY column has been added to the
/etc/shorewall/providers file. Normally, when a table
name/number is given in the DUPLICATE column, the entire
table (less default routes) is copied. The COPY column allows
you to limit the routes copied to those that go through an
interface listed in COPY. For example, if you enter eth0 in
INTERFACE, "eth1,eth2" in COPY and 'main' in DUPLICATE then
the new table created will contain those routes through the
interfaces eth0, eth1 and eth2.
07/17/2005
Security vulnerability in MACLIST processing
Description
A security vulnerability has been discovered which affects
all supported stable versions of Shorewall. This
vulnerability enables a client accepted by MAC address
filtering to bypass any other rule. If MACLIST_TTL is set
to a value greater than 0 or MACLIST_DISPOSITION is set to
"ACCEPT" in /etc/shorewall/shorewall.conf (default is
MACLIST_TTL=0 and MACLIST_DISPOSITION=REJECT), and a client is
positively identified through its MAC address, it bypasses all
other policies/rules in place, thus gaining access to all open
services on the firewall.
Fix
Workaround
For Shorewall 2.2.x or 2.4.x, set MACLIST_TTL=0 or
MACLIST_DISPOSITION=REJECT in
/etc/shorewall/shorewall.conf. For Shorewall 2.0.x, set
MACLIST_DISPOSITION=REJECT in
/etc/shorewall/shorewall.conf. MACLIST filtering is of
limited value on Internet-connected hosts, and the Shorewall
team recommends this approach to be used if possible.
Upgrade
For Shorewall 2.4.x, a fixed version of the 'firewall'
script is available at:
http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall
and its mirrors,
http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall
and
http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall.
For Shorewall 2.2.x, a fixed version of the 'firewall'
script is available at:
http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall
and its mirrors,
http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall
and
http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall.
For Shorewall 2.0.x, a fixed version of the 'firewall'
script is available at: http://shorewall.net/pub/shorewall/errata/2.0.17/firewall
and its mirrors,
http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall
and
http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall.
Users of any version before 2.0.17 are urged to upgrade to a
supported version of Shorewall (preferably 2.4.1) before using
the fixed files. Only the most recent version of the
2.0.x and 2.2.x streams will be supported by the development
team, and the 1.x branches are no longer maintained at
all. Future releases of Shorewall will include this
fix.
This information was based on Patrick
Blitz's post to the Full Disclosure mailing list.
Thanks to Supernaut (supernaut at ns dot sympatico dot ca) for
reporting this bug.
Version Upgrade
The vulnerability is corrected in Shorewall 2.4.2 and in
Shorewall 2.2.6.
07/13/2005 Shorewall 2.4.1
Problems Corrected:
- Shell variables may now be used in the zones file.
- The /usr/share/shorewall/bogons file has been updated to
reflect recent IANA allocations.
- Shorewall now detects an error where multiple providers
specify the 'track' option on the same interface.
- The remnants of the GATEWAY column in
/etc/shorewall/interfaces have been removed. This column
appeared briefly in one of the Beta versions and was
immediately removed but some vestiges remained.
- Shorewall now correctly restores a load-balancing default
route during processing of the 'shorewall restore' and
'shorewall -f start' commands. The latter command is normally
executed by the Shorewall init script during reboot.
- A log level of "None!" is now allowed on builtin actions
such as ACCEPT and DROP.
- Previously, LIMIT:BURST parameters in
/etc/shorewall/policy were not correctly applied when the
policy was QUEUE.
- The 'chkconfig' command on FC4 and Mandriva previously
created symbolic links with incorrect names ("S-1shorewall").
The init script has been changed to prevent this incorrect
behavior.
- DHCP traffic forwarded through a bridge could, under some
configurations, be filtered by the 'maclist' option even
though the 'dhcp' option was specified. This has been
corrected.
06/05/2005 Shorewall 2.4.0
Note: Because of the short time that has elapsed since
the release of Shorewall 2.2.0, Shorewall 2.0 will be supported
until 1 December 2005 or until the release of Shorewall 2.6.0,
whichever occurs first.
New Features:
- Shorewall 2.4.0 includes support for multiple internet
interfaces to different ISPs.
The file /etc/shorewall/providers may be used to define the
different providers. It can actually be used to define
alternate routing tables so uses like transparent proxy can
use the file as well.
Columns are:
NAME
The provider name.
NUMBER
The provider number -- a number between 1 and 15
MARK
A FWMARK value used in your /etc/shorewall/tcrules file to
direct packets for this provider.
DUPLICATE The name of an
existing table to duplicate. May be 'main' or the name of a previous
provider.
INTERFACE The name of the
network interface to the provider. Must be listed
in/etc/shorewall/interfaces.
GATEWAY The
IP address of the provider's gateway router. If you enter "detect" here
then Shorewall
will attempt to
determine the gateway IP address automatically.
OPTIONS A
comma-separated list selected from the following:
track If specified, connections FROM this
interface are to
be tracked so that responses may be
routed back out
this same interface.
You want specify 'track' if internet hosts will be
connecting to local
servers through
this provider.
Because of limitations in the 'ip' utility and policy routing, you may not
use the SAVE or
RESTORE tcrules options or use connectionmarking on any traffic to or from
this
interface. For traffic control purposes, you must mark packets in the
FORWARD chain (or
better yet, use the CLASSIFY target).
balance The providers that have 'balance' specified
will get
outbound traffic load-balanced among
them. By default, all interfaces with
'balance' specified will have the same weight (1).
You can change theweight of the route out of the
interface by specifiying
balance=<weight>
where <weight> isthe desired route weight.
Example: You run
squid in your DMZ on IP address 192.168.2.99. Your DMZ
interface is eth2
#NAME NUMBER MARK DUPLICATE INTERFACE
GATEWAY OPTIONS
Squid 1
1
-
eth2 192.168.2.99
-
Use of this feature requires that your kernel and iptabls
support CONNMARK target and conntrack match support. It does
NOT require the ROUTE target extension.
WARNING: The current version of iptables (1.3.1) is broken
with respect to CONNMARK and iptables-save/iptables-restore.
This means that if you configure multiple ISPs, "shorewall
restore" may fail. You must patch your iptables using the
patch at
http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff.
- Shorewall 2.3.0 supports the 'cmd-owner' option of the
owner match facility in Netfilter. Like all owner match
options, 'cmd-owner' may only be applied to traffic that
originates on the firewall.
The syntax of the USER/GROUP column in the following files
has been extended:
/etc/shorewall/accounting
/etc/shorewall/rules
/etc/shorewall/tcrules
/usr/share/shorewall/action.template
To specify a command, prefix the command name with "+".
Examples:
+mozilla-bin
#The program is named "mozilla-bin"
joe+mozilla-bin
#The program is named "mozilla-bin" and
#is being run by user "joe"
joe:users+mozilla-bin #The program is named
"mozilla-bin" and
#is being run by user "joe" with
#effective group "users".
Note that this is not a particularly robust
feature and I would never advertise it as a "Personal
Firewall" equivalent. Using symbolic links, it's easy to
alias command names to be anything you want.
- Support has been added for ipsets (see http://people.netfilter.org/kadlec/ipset/).
In most places where a host or network address may be used,
you may also use the name of an ipset prefaced by "+".
Example:
"+Mirrors"
The name of the set may be optionally followed by:
a) a number from 1 to 6 enclosed in square brackets ([]) --
this number indicates the maximum number of ipset binding
levels that are to be matched. Depending on the context where
the ipset name is used, either all "src" or all "dst" matches
will be used.
Example:
"+Mirrors[4]"
b) a series of "src" and "dst" options separated by commas
and inclosed in square brackets ([]). These will be passed
directly to iptables in the generated --set clause. See the
ipset documentation for details.
Example:
"+Mirrors[src,dst,src]"
Note that "+Mirrors[4]" used in the SOURCE column of the
rules file is equivalent to "+Mirrors[src,src,src,src]".
To generate a negative match, prefix the "+" with "!" as in
"!+Mirrors".
Example 1: Blacklist all hosts in an ipset named
"blacklist"
/etc/shorewall/blacklist
#ADDRESS/SUBNET
PROTOCOL
PORT
+blacklist
Example 2: Allow SSH from all hosts in an ipset named
"sshok:
/etc/shorewall/rules
#ACTION
SOURCE
DEST PROTO DEST
PORT(S)
ACCEPT
+sshok
fw
tcp 22
Shorewall can automatically capture the contents of your
ipsets for you. If you specify SAVE_IPSETS=Yes in
/etc/shorewall/shorewall.conf then "shorewall save" will save
the contents of your ipsets. The file where the sets are
saved is formed by taking the name where the Shorewall
configuration is stored and appending "-ipsets". So if you
enter the command "shorewall save standard" then your
Shorewall configuration will be saved in
var/lib/shorewall/standard and your ipset contents will be
saved in /var/lib/shorewall/standard-ipsets. Assuming the
default RESTOREFILE setting, if you just enter "shorewall
save" then your Shorewall configuration will be saved in
/var/lib/shorewall/restore and your ipset contents will be
saved in /var/lib/shorewall/restore-ipsets.
Regardless of the setting of SAVE_IPSETS, the "shorewall -f
start" and "shorewall restore" commands will restore the
ipset contents corresponding to the Shorewall configuration
restored provided that the saved Shorewall configuration
specified exists.
For example, "shorewall restore standard" would restore the
ipset contents from /var/lib/shorewall/standard-ipsets
provided that /var/lib/shorewall/standard exists and is
executable and that /var/lib/shorewall/standard-ipsets exists
and is executable.
Also regardless of the setting of SAVE_IPSETS, the "shorewall
forget" command will purge the saved ipset information (if
any) associated with the saved shorewall configuration being
removed.
You can also associate ipset contents with Shorewall
configuration directories using the following command:
ipset -S > <config
directory>/ipsets
Example:
ipset -S >
/etc/shorewall/ipsets
When you start or restart Shorewall (including using the
'try' command) from the configuration directory, your ipsets
will be configured from the saved ipsets file. Once again,
this behavior is independent of the setting of
SAVE_IPSETS.
Ipsets are well suited for large blacklists. You can maintain
your blacklist using the 'ipset' utility without ever having
to restart or refresh Shorewall. If you use the
SAVE_IPSETS=Yes feature just be sure to "shorewall save"
after altering the blacklist ipset(s).
Example /etc/shorewall/blacklist:
#ADDRESS/SUBNET
PROTOCOL
PORT
+Blacklist[src,dst]
+Blacklistnets[src,dst]
Create the blacklist ipsets using:
ipset
-N Blacklist iphash
ipset
-N Blacklistnets nethash
Add entries
ipset -A Blacklist
206.124.146.177
ipset -A Blacklistnets
206.124.146.0/24
To allow entries for individual ports
ipset -N SMTP portmap
--from 1 --to 31
ipset -A SMTP 25
ipset -A Blacklist
206.124.146.177
ipset -B Blacklist
206.124.146.177 -b SMTP
Now only port 25 will be blocked from 206.124.146.177.
- Shorewall 2.4.0 can now configure routing if your kernel
and iptables support the ROUTE target extension. This
extension is available in Patch-O-Matic-ng. This feature is
*EXPERIMENTAL* since the Netfilter team have no intention of
ever releasing the ROUTE target extension to kernel.org.
Routing is configured using the /etc/shorewall/routes file.
Columns in the file are as follows:
SOURCE
Source of the packet. May be any of the following:
- A host or network address
- A network interface name.
- The name of an ipset prefaced with "+"
- $FW (for packets originating on the firewall)
- A MAC address in Shorewall format
- A range of IP addresses (assuming that your kernel and iptables support
range match)
- A network interface name followed by ":" and an address or address
range.
DEST
Destination of the packet. May be any of the following:
- A host or network address
- A network interface name (determined from
routing table(s))
- The name of an ipset prefaced with "+"
- A network interface name followed by ":"
and an address or address range.
PROTO
Protocol - Must be "tcp", "udp", "icmp", "ipp2p", a number, or "all".
"ipp2p" requires
ipp2p match support in your kernel andiptables.
PORT(S)
Destination Ports. A comma-separated list of Port names (from
/etc/services), port
numbers or port
ranges; if the protocol is "icmp", thiscolumn is interpreted as the
destination icmp-type(s).
If the protocol is ipp2p, this column is interpreted as an ipp2p option
without the
leading "--" (example "bit" for bit-torrent). If no PORT is given, "ipp2p"
is assumed.
This column is ignored if PROTOCOL = all but must be entered if any of the
following
field is
supplied. In that case, it is suggested that this field contain
"-"
SOURCE PORT(S) (Optional) Source port(s). If
omitted, any
source port is acceptable. Specified as a
comma-separated list of port names, port numbers or port ranges.
TEST
Defines a test on the existing packet or connection mark.
The rule will match only if the test returns true. Tests have the
format
[!]<value>[/<mask>][:C]
Where:
! Inverts the test (not
equal) <value> Value of the packet
or
connection mark.
<mask> A mask to be applied to the mark before testing
:C Designates a
connection mark.
If omitted, the packet mark's value
is tested.
INTERFACE The interface
that the packet is to be routed out of. If you do not specify
this
field then you
must place "-" in this column and enter an IP address in the GATEWAY
column.
GATEWAY The
gateway that the packet is to be forewarded through.
- Normally when Shorewall is stopped, starting or
restarting then connections are allowed from hosts listed in
/etc/shorewall/routestopped to the firewall and to other
hosts listed in /etc/shorewall/routestopped.
A new 'source' option is added for entries in that file which
will cause Shorewall to allow traffic from the host listed in
the entry to ANY other host. When 'source' is specified in an
entry, it is unnecessary to also specify 'routeback'.
Similarly, a new 'dest' option is added which will cause
Shorewall to allow traffic to the host listed in the entry
from ANY other host. When 'source' is specified in an entry,
it is unnecessary to also specify 'routeback'.
- This change was implemented by Lorenzo Martignoni. It
provides two new commands: "safe-start" and
"safe-restart".
safe-start starts
Shorewall then prompts you to ask you if everything looks ok.
If you answer "no" or if you don't answer within 60 seconds,
a "shorewall clear" is executed.
safe-restart saves
your current configuration to /var/lib/shorewall/safe-restart
then issues a "shorewall restart"; It then prompts you to ask
if you if you want to accept the new configuration. If you
answer "no" or if you don't answer within 60 seconds, the
configuration is restored to its prior state.
These new commands require either that your /bin/sh supports
the "-t" option to the 'read' command or that you have
/bin/bash installed.
Old News here