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-11-11
11/11/2005
Shorewall 3.0.0
New Features in Shorewall 3.0.0
1) Error and warning messages are made easier to spot by using
capitalization (e.g., ERROR: and WARNING:).
2) A new option 'critical' has been added to
/etc/shorewall/routestopped. This option can be used to enable
communication with a host or set of hosts during the entire
"shorewall [re]start/stop" process. Listing a host with this option
differs from listing it without the option in several ways:
a) The option only affect traffic between the listed host(s) and the
firewall itself.
b) If there are any entries with 'critical', the firewall
will be completely opened briefly during start, restart and stop but
there will be no chance of any packets to/from the listed host(s)
being dropped or rejected.
Possible uses for this option are:
a) Root file system is NFS mounted. You will want to list the NFS server
in the 'critical' option.
b) You are running Shorewall in a Crossbeam environment
(www.crossbeam.com). You will want to list the Crossbeam interface
in this option
3) A new 'macro' feature has been added.
Macros are very similar to actions and can be used in similar
ways. The differences between actions and macros are as follows:
a) An action creates a separate chain with the same name as the
action (when logging is specified on the invocation of an action,
a chain beginning with "%" followed by the name of the action and
possibly followed by a number is created). When a macro is
invoked, it is expanded in-line and no new chain is created.
b) An action may be specified as the default action for a policy;
macros cannot be specified this way.
c) Actions must be listed in either /usr/share/shorewall/actions.std
or in /etc/shorewall/actions. Macros are defined simply by
placing their definition file in the CONFIG_PATH.
d) Actions are defined in a file with a name beginning with
"action." and followed by the name of the action. Macro files are
defined in a file with a name beginning with "macro.".
e) Actions may invoke other actions. Macros may not directly invoke
other macros although they may invoke other macros indirectly
through an action.
f) DNAT[-] and REDIRECT[-] rules may not appear in an action. They
are allowed in a macro with the restriction that the a macro
containing one of these rules may not be invoked from an action.
g) The values specified in the various columns when you invoke a
macro are substituted in the corresponding column in each rule in
the macro. The first three columns get special treatment:
ACTION If you code PARAM as the action in a macro then
when you invoke the macro, you can include the
name of the macro followed by a slash ("/") and
an ACTION (either built-in or user-defined. All
instances of PARAM in the body of the macro will be
replaced with the ACTION.
Any logging applied when the macro is invoked is
applied following the same rules as for actions.
SOURCE and
DEST If the rule in the macro file specifies a value and
the invocation of the rule also specifies a value then
the value in the invocation is appended to the value
in the rule using ":" as a separator.
Example:
/etc/shorewall/macro.SMTP
PARAM - loc tcp 25
/etc/shorewall/rules:
SMTP/DNAT:info net 192.168.1.5
Would be equivalent to the following in the rules file:
DNAT:info net loc:192.168.1.5 tcp 25
Rest Any value in the invocation replaces the value in the
rule in the macro.
One additional restriction applies to the mixing of macros and
actions. Macros that are invoked from actions cannot themselves
invoke other actions.
4) If you have 'make' installed on your firewall, then when you use
the '-f' option to 'shorewall start' (as happens when you reboot),
if your /etc/shorewall/ directory contains files that were modified
after Shorewall was last restarted then Shorewall is started using
the config files rather than using the saved configuration.
5) The 'arp_ignore' option has been added to /etc/shorewall/interfaces
entries. This option sets
/proc/sys/net/ipv4/conf/<interface>/arp_ignore. By default, the
option sets the value to 1. You can also write arp_ignore=<value>
where value is one of the following:
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the sender's
IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope
host, only resolutions for global and link addresses are
replied
4-7 - reserved
8 - do not reply for all local addresses
WARNING -- DO NOT SPECIFY arp_ignore FOR ANY INTERFACE INVOLVED IN
PROXY ARP.
6) In /etc/shorewall/rules, "all+" in the SOURCE or DEST column works
like "all" but also includes intrazone traffic. So the rule:
ACCEPT loc all+ tcp 22
would allow SSH traffic from loc->loc whereas
ACCEPT loc all tcp 22
does not.
7) A new FASTACCEPT option has been added to shorewall.conf.
Normally, Shorewall defers accepting ESTABLISHED/RELATED packets
until these packets reach the chain in which the original connection
was accepted. So for packets going from the 'loc' zone to the 'net'
zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net'
chain.
If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are
accepted early in the INPUT, FORWARD and OUTPUT chains. If you set
FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or
RELATED sections of /etc/shorewall/rules.
8) Shorewall now generates an error if the 'norfc1918' option is
specified for an interface with an RFC 1918 address.
9) You may now specify "!" followed by a list of addresses in the
SOURCE and DEST columns of entries in /etc/shorewall/rules,
/etc/shorewall/tcrules and in action files and Shorewall will
generate the rule that you expect.
Example 1 (/etc/shorewall/rules):
#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc:!192.168.1.0/24,10.0.0.0/8 net tcp 80
That rule would allow loc->net HTTP access except for the local
networks 192.168.1.0/24 and 10.0.0.0/8.
Example 2 (/etc/shorewall/rules):
#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc:10.0.0.0/24!10.0.0.4,10.0.0.22 \
net tcp 80
That rule would allow loc->net HTTP access from the local
network 10.0.0.0/24 except for hosts 10.0.0.4 and 10.0.0.22.
10) Tunnel types "openvpnserver" and "openvpnclient" have been added
to reflect the introduction of client and server OpenVPN
configurations in OpenVPN 2.0.
11) 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.
12) Previously, if you defined any intra-zone rule(s) then any traffic
not matching the rule(s) was subject to normal policies (which
usually turned out to involve the all->all REJECT policy). Now, the
intra-zone ACCEPT policy will still be in effect in the presence of
intra-zone rules. That policy can still be overridden by an
explicit policy in your /etc/shorewall/policy file.
Example:
/etc/shorewall/rules:
DNAT loc:!192.168.1.4 loc:192.168.1.4:3128 tcp 80
Any other loc->loc traffic will still be accepted. If you want to
also log that other loc->loc traffic at the info log level then
insert this into /etc/shorewall/policy:
#SOURCE DEST POLICY LOG LEVEL
loc loc ACCEPT info
13) Prior to Shorewall 2.5.3, the rules file only controlled packets in
the Netfilter states NEW and INVALID. Beginning with this release,
the rules file can also deal with packets in the ESTABLISHED and
RELATED states.
The /etc/shorewall/rules file may now be divided into
"sections". Each section is introduced by a line that begins with
the keyword SECTION followed by the section name. Sections
are as listed below and must appear in the order shown.
ESTABLISHED
Rules in this section apply to packets in the ESTABLISHED
state.
RELATED
Rules in this section apply to packets in the RELATED state.
NEW
Rules in this section apply to packets in the NEW and INVALID
states.
Rules in the ESTABLISHED and RELATED sections are limited to the
following ACTIONs:
ACCEPT, DROP, REJECT, QUEUE, LOG and User-defined actions.
Macros may be used in these sections provided that they expand to
only these ACTIONs.
At the end of the ESTABLISHED and RELATED sections, there is an
implicit "ALLOW all all all" rule.
RESTRICTION: If you specify FASTACCEPT=Yes in
/etc/shorewall.shorewall.conf then the ESTABLISHED and RELATED
sections must be empty.
14) The value 'ipp2p' is once again allowed in the PROTO column of
the rules file. It is recommended that rules specifying 'ipp2p'
only be included in the ESTABLISHED section of the file.
15) Shorewall actions lack a generalized way to pass parameters to an
extension script associated with an action. To work around this
lack, some users have used the log tag as a parameter. This works
but requires that a log level other than 'none' be specified when
the action is invoked. Beginning with this release, you can invoke
an action with 'none'.
Example:
#ACTION SOURCE DEST
A:none:these,are,parameters $FW net
When /etc/shorewall/A is invoked, the LEVEL variable will be empty
but the TAG variable will contain "these,are,parameters" which
can be easily parsed to isolate "these", "are" and "parameters":
ifs=$IFS
IFS=,
set -- $TAG
IFS=$ifs
Now, $1 = these, $2 = are and $3 = parameters
16) The "shorewall check" command now checks the /etc/shorewall/masq,
/etc/shorewall/blacklist, /etc/shorewall/proxyarp,
/etc/shorewall/nat and /etc/shorewall/providers files.
17) Arne Bernin's "tc4shorewall" package has been integrated into
Shorewall.
See: http://www.shorewall.net/3.0/traffic_shaping.htm for details.
Thanks, Arne!
18) When /usr/share/shorewall/functions is loaded it now sets
SHOREWALL_LIBRARY=Loaded
Application code such as /etc/shorewall/tcstart may test that
variable to determine if the library has been loaded into the
current shell process.
19) The install.sh script now does a much cleaner job of backing up the
current installation. It copies the directories /etc/shorewall,
/usr/share/shorewall and /var/lib/shorewall to a directory of the
same name with "-$VERSION.bkout" appended. The init script and
/sbin/shorewall are backed up to the /usr/share/shorewall and
/var/lib/shorewall directories respectively. This makes it very
simple to remove the backups:
rm -rf /etc/shorewall-*.bkout
rm -rf /usr/share/shorewall-*.bkout
rm -rf /var/lib/shorewall-*.bkout
20) A new '-n' option has been added to the "start", "restart",
"restore", "stop" and "try" commands. This option instructs
Shorewall to not alter the routing in any way.
This option is useful when you have a multi-ISP environment because
it prevents the route cache from being flushed which preserves the
mapping of end-point address pairs to routes.
21) The output of "shorewall dump" now includes a capabilities report
such as the one produced by "shorewall show capabilities".
22) The "plain" zone type has been replaced by "ipv4". The types
"IPv4" and "IPV4" are synonyms for "ipv4". In addition, "IPSEC",
"ipsec4" and "IPSEC4" are recognized synonyms for "ipsec".
23) The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been
removed as have the 'newnotsyn' options in /etc/shorewall/interfaces
and /etc/shorewall/hosts. See the Migration Considerations for
instructions if you wish to block "new-not-syn" TCP packets.
24) The "shorewall show zones" command now displays the zone type. You
must have restarted Shorewall using this release before this feature
will work correctly.
25) The multi-ISP code now requires that that you set MARK_IN_FORWARD_CHAIN=Yes
in shorewall.conf. This is done to ensure that "shorewall refresh" will
work correctly.
26) Shorewall now supports UDP IPP2P matching. In addition to the "ipp2p"
keyword in the PROTOCOL column of the relevant files, the following
values may be specified:
ipp2p:tcp Equivalent to ipp2p and matches TCP traffic
only.
ipp2p:udp Matches UDP traffic.
ipp2p:all Matches both UDP and TCP traffic. You may
not specify a SOURCE PORT with this PROTOCOL.
27) Normally MAC verification triggered by the 'maclist' interface and host
options is done out of the INPUT and FORWARD chains of the filter table.
Users have reported that under some circumstances, MAC verification is
failing for forwarded packets when the packets are being forwarded out
of a bridge.
To work around this problem, a MACLIST_TABLE option has been added to
shorewall.conf. The default value is MACLIST_TABLE=filter which results
in the current behavior. If MACLIST_TABLE=mangle then filtering will
take place out of the PREROUTING chain of the mangle table. Because
the REJECT target may not be used in the PREROUTING chain, the settings
MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.
28) The sample configurations are now packaged with the product. They are
in the Samples directory on the tarball and are in the RPM they are
in the Samples sub-directory of the Shorewall documentation
directory.
10/31/2005
Shorewall 2.4.6
Problems Corrected in 2.4.6
- "shorewall refresh" would fail if there were entries in
/etc/shorewall/tcrules with non-empty USER/GROUP or TEST columns.
- An unprintable character in a comment caused /sbin/shorewall to
fail when used with a light-weight shell like 'dash'.
- When using some flavors of 'ash', certain /sbin/shorewall
commands produced 'ipset: not found' messages.
- Support for OpenVPN TCP tunnels was released in Shorewall 2.2.0
but the implementation was incomplete. It has now been completed and is
documented in the /etc/shorewall/tunnels file.
- The test that Shorewall uses to detect the availability of the
owner match capability has been changed to avoid the generation of
ipt_owner messages under kernel 2.6.14.
New Features in 2.4.6
- Normally MAC verification triggered by the 'maclist' interface
and host options is done out of the INPUT and FORWARD chains of the
filter table. Users have reported that under some circulstances, MAC
verification is failing for forwarded packets when the packets are
being forwarded out of a bridge.
To work around this problem, a MACLIST_TABLE option has been added to
shorewall.conf. The default value is MACLIST_TABLE=filter which results
in the current behavior. If MACLIST_TABLE=mangle then filtering will
take place out of the PREROUTING chain of the mangle table. Because the
REJECT target may not be used in the PREROUTING chain, the settings
MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.
- A "dump" command has been added to /sbin/shorewall for
compatibility with Shorewall 3.0. In 2.4.6, the "dump" command provides
the same output as the "status".
10/05/2005
Shorewall 2.4.5
Problems Corrected in 2.4.5
- In previous versions, when the command is 'start', 'restart' or
'stop' then OUTPUT traffic to hosts listed in
/etc/shorewall/routestopped is not enabled if ADMINISABSENTMINDED=Yes.
That traffic is now enabled independent of the setting of
ADMINISABSENTMINDED.
- Although it was documented that icmp types could be used in the
tcrules file, the code did not support it. Thanks to Jorge Molina, that
problem is now corrected.
- In a multi-ISP configuration, fwmark routing rules now have a
higher priority than source IP rules. This allows entries in tcrules to
be more effective in controlling routing.
- Previously, not all of the mangle chains were flushed during
"shorewall restart".
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