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”.
June 11, 2006
New Features:
1) Shorewall has always been very noisy (lots of messages). No longer.
You set the default level of verbosity using the VERBOSITY option in
shorewall.conf. If you don't set it (as would be the case of you use your
old shorewall.conf file) then VERBOSITY defaults to a value of 2 which
results in behavior compatible with previous Shorewall versions.
A value of 1 suppresses some of the output (like the old -q option did)
while a value of 0 makes Shorewall almost silent. A value of -1
suppresses all output except warning and error messages.
The value specified in the 3.2 shorewall.conf is 1. So you can make
Shorewall as verbose as previously using a single -v and you can make it
almost silent by using a single -q.
If VERBOSITY is set at 2, you can still make a command nearly
silent by using two "q"s (e.g., shorewall -qq restart).
In summary, each "q" subtracts one from VERBOSITY while each "v" adds one
to VERBOSITY.
The "shorewall show log", "shorewall logwatch" and "shorewall dump"
commands require VERBOSITY to be greater than or equal to 3 to
display MAC addresses.This is consistent with the previous
implementation which required a single -v to enable MAC display but
means that if you set VERBOSITY=0 in shorewall.conf, then you will
need to include -vvv in commands that display log records in order
to have MACs displayed.
To make the display of MAC addresses less cumbersome, a '-m' option has
been added to the "show" and logwatch commands:
shorewall show -m log
shorewall logwatch -m
2) A new 'shorewall compile' command has been added.
shorewall compile [ -e ] [ <config directory> ] <script file>
where:
-e Allows the generated script to run
on a system with Shorewall Lite installed.
Generates an error if the configuration uses
an option that would prevent the generated
script from running on a system other than
where the 'compile' command is running (see
additional consideration a) below).
<config directory> Is an optional directory to be searched for
configuration files prior to those listed
in CONFIG_DIR in
/etc/shorewall/shorewall.conf.
<script file> Is the name of the output file.
The 'compile' command processes the configuration and generates a
script file which may then be executed (either directly or using the
'shorewall restore' command) to configure the firewall.
The generated script contains error checking and will terminate if an
important command fails. Before terminating:
a) The script will check for the existence of the restore script
specified by the RESTOREFILE variable in shorewall.conf. If that
restore script exists, it is executed.
b) If the restore script doesn't exist but Shorewall appears to be
installed on the system, the equivalent of an
"/sbin/shorewall stop" command is executed.
Some additional considerations:
a) When you run 'compile' on one system and then run the generated script
on another system under Shorewall Lite, there are certain limitations.
1) A compatible version of Shorewall Lite must be running on the remote
system. Going forward, the goal is that any minor version of
the current major version will be compatible. So if the
program is compiled using Shorewall 3.2.x, any 3.2.y version
or 3.p.q version (where p > 2) of Shorewall Lite will be compatible.
2) The 'detectnets' interface option is not allowed.
3) DYNAMIC_ZONES=Yes is not allowed.
4) You must supply the file /etc/shorewall/capabilities to provide
the compiler with knowledge of the capabilities of the system
where the script is to be run. See below.
5) If your /etc/shorewall/params file contains code other than simple
assignment statements with contant values, then you should move
that code to /etc/shorewall/init. That way, the code will be
executed on the target system when the compiled script is run and
not on the local system at compile time.
b) If you run the "shorewall compile" or "shorewall check" commands under
a user other than 'root', then you must supply
/etc/shorewall/capabilities.
c) To aid in building /etc/shorewall/capabilities, a 'shorecap' program
is provided in the Shorewall Lite package and is installed in
/usr/share/shorewall-lite/shorecap when you install Shorewall Lite.
For instructions about running shorecap, see the comments at the
top of the program file (it's a simple shell script).
The "shorewall start" and "shorewall restart" commands have been
rewritten to use compilation. They both compile a temporary program
then run it. This results in a slightly longer elapsed time than the
similar commands required under earlier versions of Shorewall but new
connections are blocked for a much smaller percentage of that time.
If an error is found during the compilation phase, /sbin/shorewall
terminates and the Shorewall state is unchanged.
Under Shorewall 3.1.5, "shorewall restart" takes roughly 16.5 seconds
on my firewall:
real 0m16.599s
user 0m6.292s
sys 0m9.885s
Of the elapsed 16.5 seconds, new connections are disabled less than
3.5 seconds. Here are some numbers for comparison:
A) shorewall restart (Shorewall 3.0.4)
real 0m17.540s
user 0m5.956s
sys 0m10.737s
B) ./foo restart # foo created using "shorewall compile"
real 0m3.297s
user 0m1.444s
sys 0m1.728s
C) shorewall restore (Shorewall 3.0.4) # Restores from file generated by
# "shorewall save"
real 0m1.164s
user 0m0.556s
sys 0m0.608s
D) shorewall restore (shorewall 3.1.5)
real 0m1.637s
user 0m0.728s
sys 0m0.584s
The time difference between B and C reflects the difference between
"iptables-restore" and multiple executions of "iptables". The time
difference between C and D results from the fact that the "restore"
command in Shorewall 3.1 runs the compiled program in a way that
turns all iptables commands into no-ops then invokes
iptables-restore. The system is a 1.4Ghz Celeron with 512MB RAM.
As a final part of this change, the "check" command now compiles the
current configuration and writes the compiled output to /dev/null. So
"check" performs all of the same validation that compile does. Note that
there is still no guarantee that the generated script won't encounter
run-time errors.
2) The /etc/shorewall/maclist file has a new column layout. The first column
is now DISPOSITION. This column determines what to do with matching
packets and can have the value ACCEPT or DROP (if MACLIST_TABLE=filter, it
can also contain REJECT). This change is upward compatible so your existing
maclist file can still be used.
ACCEPT, DROP and REJECT may be optionally followed by a log level to
cause the packet to be logged.
4) In macro files, you can now use the reserved words SOURCE and DEST
in the columns of the same names. When Shorewall expands the
macro, it will substitute the SOURCE from the macro invocation for
SOURCE and the DEST from the invocation for DEST. This allows you
to write macros that act in both directions (from source to destination
and from destination to source).
Example:
macro.FOO:
PARAM SOURCE DEST udp 500
PARAM DEST SOURCE udp 500
/etc/shorewall/rules:
FOO/ACCEPT fw net
Resulting rules:
ACCEPT fw net udp 500
ACCEPT net fw udp 500
This new feature has been used to implement the SMBBI macro.
SMBBI is the same as the SMB macro with the exception that
it passes SMB traffic in both directions whereas SMB only
passes that traffic in one direction.
5) In the /etc/shorewall/rules file and in actions, you may now specify
'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to 'tcp' but also
requires that the SYN flag is set and the RST, FIN and ACK flags be
off ("--syn" is added to the iptables rule).
As part of this change, Shorewall no longer adds the "--syn" option
to TCP rules that specify QUEUE as their target.
6) /sbin/shorewall now supports a "-t" option that causes all progress
messages to be timestamped.
Example (VERBOSITY=0 in shorewall.conf):
gateway:/etc/shorewall # shorewall -t restart
07:08:51 Compiling...
07:09:05 Shorewall configuration compiled to /var/lib/shorewall/.restart
07:09:05 Restarting Shorewall....
07:09:08 done.
gateway:/etc/shorewall #
7) A 'refreshed' extension script has been added -- it is executed after
"shorewall refresh" has finished.
8) Two new dynamic blacklisting commands have been added:
logdrop -- like 'drop' but causes the dropped packets to be logged.
logreject -- like 'reject' but causes the rejected packets to be
logged.
Packets are logged at the BLACKLIST_LOGLEVEL if one was specified at the
last "shorewall [re]start"; otherwise, they are logged at the 'info'
log level.
9) A new IMPLICIT_CONTINUE option has been added to shorewall.conf. When
this option is set to "Yes", it causes subzones to be treated differently
with respect to policies.
Subzones are defined by following their name with ":" and a list of parent
zones (in /etc/shorewall/zones). Normally, you want to have a set of
special rules for the subzone and if a connection doesn't match any of
those subzone-specific rules then you want the parent zone rules and
policies to be applied. With IMPLICIT_CONTINUE=Yes, that happens
automatically.
If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then
subzones are not subject to this special treatment.
With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden
by including an explicit policy (one that does not specify "all" in either
the SOURCE or the DEST columns).
Example:
/etc/shorewall/zones:
prnt ipv4
chld:prnt ipv4
Traffic to/from the 'chld' zone will first pass through the applicable
'chld' rules and if none of those rules match then it will be passed through
the appropriate 'prnt' rules. If the connection request does not match
any of the 'prnt' rules then the relevant 'prnt' policy is applied.
If you want the fw->chld policy to be ACCEPT, simply add this entry to
/etc/shorewall/policy:
$FW chld ACCEPT
Traffic from all other zones to 'chld' will be subject to the implicit
CONTINUE policy.
10) Shorewall now includes support for explicit routing rules when the
/etc/shorewall/providers file is used. A new file,
/etc/shorewall/route_rules can be used to add routing rules based on
packet source and/or destination.
The file has the following columns:
SOURCE(optonal) An ip address (network or host) that
matches the source IP address in a packet.
May also be specified as an interface
name optionally followed by ":" and an
address. If the define 'lo' is specified,
the packet must originate from the firewall
itself.
DEST(optional) An ip address (network or host) that
matches the destination IP address in a packet.
If you choose to omit either SOURCE or DEST,
place "-" in the column. Note that you
may not omit both SOURCE and DEST.
PROVIDER The provider to route the traffic through.
May be expressed either as the provider name
or the provider number. You may also specify
the 'main' routing table here, either by
name or by number (254).
PRIORITY
The rule's priority which determines the order
in which the rules are processed.
1000-1999 Before Shorewall-generated
'MARK' rules
11000- 11999 After 'MARK' rules but before
Shorewall-generated rules for
provider interfaces.
26000-26999 After provider interface rules but
before 'default' rule.
Rules with equal priority are applied in
the order in which they appear in the file.
Example 1: You want all traffic coming in on eth1 to be routed to the ISP1
provider:
#PROVIDER PRIORITY SOURCE DEST
ISP1 1000 eth1
Example 2: You use OpenVPN (routed setup /tunX) in combination with multiple
providers. In this case you have to set up a rule to ensure that
the OpenVPN traffic is routed back through the tunX interface(s)
rather than through any of the providers. 10.8.0.0/24 is the
subnet choosen in your OpenVPN configuration (server 10.8.0.0
255.255.255.0)
#SOURCE DEST PROVIDER PRIORITY
- 10.8.0.0/24 main 1000
11) Prior to now, it has not been possible to use connection marking in
/etc/shorewall/tcrules if you have a multi-ISP configuration that uses the
'track' option.
Beginning with this release, you may now set HIGH_ROUTE_MARKS=Yes in
shorewall.conf to effectively divide the packet mark and connection mark
into two 8-byte mark fields.
When you do this:
a) The MARK field in the providers file must have a value that is
less than 65536 and that is a multiple of 256 (using hex
representation, the values are 0x0100-0xFF00 with the low-order
8 bits being zero).
b) You may only set those mark values in the PREROUTING chain.
c) Marks used for traffic shaping must still be in the range of 1-255
and may still not be set in the PREROUTING chain.
d) When you SAVE or RESTORE in tcrules, only the TC mark value is
saved or restored. Shorewall handles saving and restoring the
routing (provider) marks.
12) A TOS column has been added to /etc/shorewall/tcrules. This allows marking
based on the contents of the TOS field in the packet header.
13) Beginning with this release, the way in which packet marking in the
PREROUTING chain interracts with the 'track' option in /etc/shorewall/providers
has changed in two ways:
a) Packets *arriving* on a tracked interface are now passed to the PREROUTING
marking chain so that they may be marked with a mark other than the
'track' mark (the connection still retains the 'track' mark).
b) When HIGH_ROUTE_MARKS=Yes, you can still clear the mark on packets
in the PREROUTING chain (i.e., you can specify a mark value of zero).
14) Shorewall will now attempt to detect the MTU of devices listed in
/etc/shorewall/tcdevices and will use the detected MTU in setting
up traffic shaping.
15) In /etc/shorewall/rules, the values "all-" and "all+-" may now be
used for zone names. "all-" means "All zones except the firewall";
"all+-" means "All zones except the firewall" and intra-zone
traffic is included.
16) Kernel version 2.6.16 introduces 'xtables', a new common packet
filtering and connection tracking facility that supports both IPv4
and IPv6. Because a different set of kernel modules must be loaded
for xtables, Shorewall now includes two 'modules' files:
a) /usr/share/shorewall/modules -- the former
/etc/shorewall/modules
b) /usr/share/shorewall/xmodules -- a new file that support
xtables.
If you wish to use the new file, then simply execute this command:
cp -f /usr/share/shorewall/xmodules /etc/shorewall/modules
17) Shorewall now checks to see if devices in /etc/shorewall/tcdevices
exist. If a device does not exist, a warning message is issued and
that device's entries in /etc/shorewall/tcclasses are ignored. This
applies to "shorewall start", "shorewall restart" and "shorewall
refresh".
18) "load" and "reload" commands have been added. These commands allow
a non-root user with ssh access to a remote system running
Shorewall Lite to compile a firewall script on the local system and
to install that script on the remote system.
Syntax is:
shorewall [re]load [ <directory> ] <system>
If <directory> is omitted, the current working directory is
assumed.
The command is equivalent to:
/sbin/shorewall compile -e <directory> firewall &&\
scp firewall root@<system>:/var/lib/shorewall-lite/ &&\
ssh root@<system> '/sbin/shorewall-lite [re]start' # Note 1
In other words, the configuration in the specified (or defaulted)
directory is compiled to a file called firewall in that
directory. If compilation succeeds, then 'firewall' is copied to the
(usually remote) <system> using scp. If the copy succeeds,
Shorewall Lite on <system> is started or restarted via ssh (
load causes Shorewall Lite to be started and 'reload' causes
Shorewall Lite to be re-started)
Note 1: In Shorewall Lite 3.2.0 RC4, the 'firewall' script has moved
from /usr/share/shorewall-lite/ to /var/lib/shorewall-lite in
packages from shorewall.net. The package maintainers for the
various distributions are free to choose the directory where the
script will be stored under their distribution by altering the
value of LITEDIR in /usr/share/shorewall/configpath. You can run the
"shorewall show config" command to see how your distribution
defines LITEDIR.
Problems corrected in 2.4.9
1) Updated the bogons file to reflect recent IANA allocations.
2) If you use SAME or SAME:nodst in the ADDRESS column of /etc/shorewall/masq and
if you set ADD_SNAT_ALIASES=Yes in shorewall.conf, then "shorewall start" will
fail with the error 'Error: an inet prefix is expected rather than "SAME".'.
3) It is now possible to exclude a single source MAC address using
!<MAC address>. Previously, a startup error occurred.
Problems corrected in 3.0.7
1) Previously, if your kernel did not supply the mangle table FORWARD chain
then "shorewall [re]start" would fail. Now, if your mangle table does
not supply this chain Shorewall will avoid using either that chain or
the mangle table POSTROUTING chain. This change is strictly to stop Shorewall
from blowing up during [re]start on very old kernels (such as 2.4.17
running on a PS2); if your kernel does not support these chains and you
try to mark packets in either of them using entries in
/etc/shorewall/tcrules, [re]start will fail.
2) Previously, if there were more than 10 IP addresses on a multi-ISP interface,
some of the routing rules generated by Shorewall were placed after the
default rule which resulted in them not being recognized.
3) When install.sh is used to install on a Debian or Ubuntu system, the
SUBSYSLOCK option in shorewall.conf was not being cleared.
It will now be cleared, provided that Perl is installed on the system.
4) When exclusion lists appeared in the /etc/shorewall/tcrules file, the
resulting 'exclusion chains' (whose names begin with 'excl_') were not
deleted as part of 'shorewall [re]start'. This meant that 'refresh'
would fail, either the first or second time that it was done since
the last 'shorewall [re]start'.
Other changes in 3.0.7
None.
Effectively today, Shorewall source code repository was migrated to Subversion SCM.
Please read https://sourceforge.net/svn/?group_id=22587 and http://www.shorewall.net/download.htm#SVN for more information.
Problems corrected in 3.0.6
1) A typo in the output of "help drop" has been corrected.
2) Previously, 'shorewall start' would fail in the presence of a network
interface named 'inet'.
3) A shell syntax error was reported when duplicate policies appeared in
/etc/shorewall/policy.
4) The iptable_nat and iptable_mangle modules were previously omitted
from /etc/shorewall/modules.
5) If you use SAME or SAME:nodst in the ADDRESS column of /etc/shorewall/masq
and if you set ADD_SNAT_ALIASES=Yes in shorewall.conf, then "shorewall
start" will fail with the error 'Error: an inet prefix is expected rather
than "SAME".'.
6) Previously, the 'routeback' option was ignored in an entry in the
/etc/shorewall/hosts file that referred to a (set of) bridge port(s).
Example:
dmz xenbr0:vif+ routeback
Other changes in 3.0.6
1) A 'refreshed' extension script has been added -- it is executed after
"shorewall refresh" has finished.
Problems corrected in Shorewall 3.0.5
1) Previously, if /etc/shorewall/ipsets existed, it was run when Shorewall starts
but not when Shorewall was restored.
2) When using the NETKEY IPSEC implementation in kernel 2.6 but without the
policy match patch and the Netfilter/IPSEC patches, previously an
entry in /etc/shorewall/tunnels was not sufficient in cases where:
a) gw<->gw traffic was encrypted
b) The gw<->gw policy through the tunnel was not ACCEPT
Thanks to Tuomo Soini, this has been corrected. By simply including the
remote VPN zone in the GATEWAY ZONE column for the tunnel's entry, no
additional rules are required.
3) Extra blank output lines are no longer produced by install.sh (patch
courtesy of Tuomo Soini).
4) TCP packets sent to QUEUE by rules in the ESTABLISHED section of the
rules file previously didn't work (they had the "--syn" parameter
added to them which resulted in a rule that no traffic would match).
WARNING: If you use the QUEUE target from an action, Shorewall will
still insert --syn if the protocol is tcp. So you don't want to
invoke such an action from the ESTABLISHED section of the rules
file.
5) The description of the SOURCE column in /etc/shorewall/rules has been
improved (patch courtesy of Ed Suominen).
6) The 'allow', 'drop' and 'reject' commands no longer produce iptables
errors when executed while Shorewall is not started.
7) The spelling of "maximize-throughput" has been corrected in the code
that implements tcclasses parsing. Patch courtesy of Paul Traina.
8) Shorewall now generates the correct match for devices in
/etc/shorewall/tcdevices that are actually bridge ports.
New Features in Shorewall 3.0.5
1) The facilities available for dealing with the TOS field in
/etc/shorewall/tcclasses has been expended. The OPTIONS field is now may
contain a comma-separates list of the following:
tos=0x<value>[/0x<mask>] (mask defaults to 0xff)
- this lets you define a classifier
for the given <value>/<mask> combination
of the IP packet's TOS/Precedence/DiffSrv
octet (aka the TOS byte). Please note,
classifiers override all mark settings,
so if you define a classifer for a class,
all traffic having that mark will go in it
regardless of any mark set on the packet
by a firewall/mangle filter.
NOTE: multiple tos= statements may be
applied per class and per interface, but
a given value/mask pair is valid for only
ONE class per interface.
tos-<tosname> - aliases for the following TOS octet
value and mask encodings. TOS encodings
of the "TOS byte" have been deprecated in
favor of diffserve classes, but programs
like ssh, rlogin, and ftp still use them.
tos-minimize-delay 0x10/0x10
tos-maximize-throughput 0x08/0x08
tos-maximize-reliability 0x04/0x04
tos-minimize-cost 0x02/0x02
tos-normal-service 0x00/0x1e
tcp-ack - defined causes an tc filter to
be created that puts all tcp ack
packets on that interface that have
an size of <=64 Bytes to go in this
class. This is useful for speeding up
downloads. Please note that the size
of the ack packets is limited to 64
bytes as some applications (p2p for
example) use to make every packet an
ack packet which would cause them
all into here. We want only packets
WITHOUT payload to match, so the size
limit.
NOTE: This option is only valid for
ONE class per interface.
Note that the semantics of 'tos-<tosname>' have changed slightly. Previously,
these were tested using a mask of 0xff (example: tos-minimize-delay was
equivalent to 0x10/0xff). Now each bit is tested individually.
This enhancement is courtesy of Paul Traina.
Problems Corrected in 3.0.4
1) The shorewall.conf file is once again "console friendly". Patch is
courtesy of Tuomo Soini.
2) A potential security hole has been closed. Previously, Shorewall ACCEPTed
all traffic from a bridge port that was sent back out on the same port. If
the port was described in /etc/shorewall/hosts using the wildcard "+" (eg,
xenbr0:vif+), this could lead to traffic being passed in variance with the
supplied policies and rules.
3) Previously, an intra-zone policy of NONE would cause a startup error. That
problem has been corrected.
4) When RETAIN_ALIASES=Yes, the script produced by "shorewall save" did not
add the retained aliases. This means that the following sequence of
events resulted in missing aliases:
shorewall start
shorewall restart
shorewall save
reboot
shorewall -f start (which is the default during boot up)
5) When a 2.x standard action is invoked with a log level (example
"AllowPing:info"), logging does not occur.
New Features in 3.0.4
1) By popular demand, the 'Limit' action described at
http://www1.shorewall.net/PortKnocking.html#Limit has been made a standard
action. Limit requires 'recent match' support in your kernel and iptables.
2) DISABLE_IPV6 no longer disabled local (loopback) IPV6 traffic. This
change is reported to improve Java startup time on some distributions.
3) Shorewall now contains support for wildcard ports. In
/etc/shorewall/hosts, you may specify the port name with trailing "+" then
use specific port names in rules.
Example:
/etc/shorewall/hosts
vpn br0:tap+
/etc/shorewall/rules
DROP vpn:tap0 vpn:tap1 udp 9999
4) For the benefit of those who run Shorewall on distributions that don't
autoload kernel modules, /etc/shorewall/modules now contains load commands
for a wide range of Netfilter modules.
Problems Corrected in 3.0.3
1) The comments in the /etc/shorewall/shorewall.conf and
/etc/shorewall/hosts files have been changed to clarify when
BRIDGING=Yes is required when dealing with bridges.
2) Thanks to Tuomo Soini, formatting of the comments in the tcdevices
and tcclasses files has been cleaned up.
3) Specifying 'trace' on the 'safe-start' and 'safe-restart' command no
longer fails.
4) The output of "shorewall help restore" has been corrected. It previously
printed incorrect syntax for that command.
5) The README.txt file in the tarball was stale and contained incorrect
information. It has been corrected.
6) The shorewall.conf default setting of CLEAR_TC was previously "No". Given
that the default setting of TC_ENABLED is "Internal", the setting of
CLEAR_TC has been changed to the more appropriate value of "Yes".
7) Specifying an interface name in the SOURCE column of /etc/shorewall/tcrules
resulted in a startup error.
8) When the 'install.sh' script is used on Debian, it now creates
/var/log/shorewall-init.log. And if perl is installed on the system then
STARTUP_ENABLED=Yes is specified in shorewall.conf (the user must still
set startup=1 in /etc/default/shorewall).
New Features in 3.0.3
1) A "shorewall show macros" command has been added. This command displays a list of the standard macros along with a brief description of each. 2) The '-q' option is now supported with 'safe-start' and 'safe-restart'. 3) The value "-" is now allowed in the ADDRESS/SUBNET column of /etc/shorewall/blacklist. That value is equivalent to specifying 0.0.0.0/0 in that column. 4) The output of "shorewall show tc" and "shorewall show classifiers" is now included in the output from "shorewall dump". This will aid us in analyzing traffic shaping problems. 5) You can now specify 'none' in the COPY column of /etc/shorewall/providers to signal that you want Shorewall to only copy routes through the interface listed in the INTERFACE column. Note: This works on older versions of Shorewall as well. It is now documented. 6) An 'ipdecimal' command has been added to /sbin/shorewall. This command converts between dot-quad and decimal. Example: gateway:/etc/openvpn# shorewall ipdecimal 192.168.1.4 3232235780 gateway:/etc/openvpn# shorewall ipdecimal 3232235780 192.168.1.4 gateway:/etc/openvpn# 7) /etc/init.d/shorewall now supports a 'reload' command which is synonymous with the 'restart' command.
Problems Corrected in 3.0.2
1) A couple of typos in the one-interface sample configuration have
been corrected.
2) The 3.0.1 version of Shorewall was incompatible with old versions of
the Linux kernel (2.4.7 for example). The new code ignores errors
produced when Shorewall 3.x is run on these ancient kernels.
3) Arch Linux installation routines has been improved.
New Features in 3.0.2
1) A new Webmin macro has been added. This macro assumes that Webmin is
running on its default port (10000).
Problems Corrected in 3.0.1
1) If the previous firewall configuration included a policy other than ACCEPT in the nat, mangle or raw tables then Shorewall would not set the policy to ACCEPT. This could result in a ruleset that rejected or dropped all traffic. 2) The Makefile was broken such that 'make' didn't always work correctly. 3) If the SOURCE or DEST column in a macro body was non-empty and a dash ("-") appeared in the corresponding column of an invocation of that macro, then an invalid rule was generated. 4) The comments in the /etc/shorewall/blacklist file have been updated to clarify that the PORTS column refers to destination port number/service names. 5) When CLAMPMSS is set to a value other than "No" and FASTACCEPT=Yes, the order of the rules generated was incorrect causing RELATED TCP connections to not have CLAMPMSS applied. New Features in 3.0.1 1) To make the macro facility more flexible, Shorewall now examines the contents of the SOURCE and DEST columns in both the macro body and in the invocation and tries to create the intended rule. If the value in the invocation appears to be an address (IP or MAC) or the name of an ipset, then it is placed after the value in the macro body. Otherwise, it is placed before the value in the macro body. Example 1: /etc/shorewall/macro.foo: PARAM - 192.168.1.5 tcp http /etc/shorewallrules: foo/ACCEPT net loc Effective rule: ACCEPT net loc:192.168.1.5 tcp http Example 2: /etc/shorewall/macro.bar: PARAM net loc tcp http /etc/shorewall/rules: bar/ACCEPT - 192.168.1.5 Effective rule: ACCEPT net loc:192.168.1.5 tcp http
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=$ifs2
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
2
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.