diff --git a/web/oldnews.html b/web/oldnews.html
index 1e9a7b0b1..685f1a79a 100644
--- a/web/oldnews.html
+++ b/web/oldnews.html
@@ -1,22 +1,16 @@
-
-
-
+
+ Old News
+
- Old News
-
-
-
- 10/05/2005
-
-2007-01-16 Shorewall 3.2.9
-
+
+2007-02-10 Shorewall 3.2.9
+
Problems Corrected in 3.2.9
1) While most distributions store the Shorewall Lite compiled program
in /var/lib/shorewall-lite/, Shorewall includes features that allow
that location to be changed on a per-distribution basis. The
default for a particular distribution may be determined by the
command "shorewall[-lite] show config".
teastep@lists:~/shorewall/trunk$ shorewall show config
Default CONFIG_PATH is /etc/shorewall:/usr/share/shorewall
LITEDIR is /var/lib/shorewall-lite
teastep@lists:~/shorewall/trunk$
The LITEDIR setting is the location where the compiled script
should be placed. Unfortunately, the "shorewall [re]load" command
previously used the setting on the administrative system rather
than the one from the firewall system so it was possible for that
command to upload the compiled script to the wrong directory.
To work around this problem, Shorewall now determines the LITEDIR
setting on the firewall system and uses that setting for uploading
the compiled script and its companion .conf file.
2) Previously, IP ranges and ipset names were handled incorrectly in
the last column of the maclist file with the result that run-time
errors occured.
3) The new SIP and H323 Netfilter helper modules were not being
automatically loaded by Shorewall. They have now been added to the
/usr/share/shorewall[-lite]/modules files.
Other Changes in 3.2.9
1) Previously, 'ipsecnat' tunnels allowed AH traffic by default
(unless 'isecnat:noah' was given). Given that AH is incompatible
with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.
2) A macro that handles SixXS has been contributed by Christian
Roessner.
3) It is rather difficult to code a 'params' file that assigns other
than constant values such that it works correctly with Shorewall
Lite. To work around this problem, a new EXPORTPARAMS option
has been added to shorewall.conf. When EXPORTPARAMS=No, the
'params' file is no longer copied to the compiler output.
With EXPORTPARAMS=No, if you need to set environmental variables on
the firewall system for use by your extension scripts, then do so
in the init extension script.
The default is EXPORTPARAMS=Yes to retain the current behavior. So
if you are happy with the current behavior, you need make no change
to your shorewall.conf file.
-2007-01-16 Shorewall 3.2.8
+style="font-weight:
+bold;">2007-01-16 Shorewall 3.2.8
Problems Corrected in 3.2.8
1) The 'ash' shell produced an error when processing an entry with a
log tag from /etc/shorewall/rules.
2) If the file /etc/shorewall/init did not exist, then the compiler
would incorrectly copy /usr/share/shorewall/init into the
compiled script. /usr/share/shorewall/init is a symbolic link
to the Shorewall init script (usually /etc/init.d/shorewall).
3) Previously, "ipp2p:udp" was incorrectly rejected in the PROTO
column of an action definition.
Other Changes in 3.2.8.
1) New macros for network printing protocols have been added,
courtesy of Tuomo Soini. Tuomo also provided a macro for TFTP.
The print-oriented macros are:
macro.IPP
macro.Jetdirect
macro.Printer
2006-08-26 Shorewall 3.2.3
-Shorewall Problems Corrected in 3.2.3
1) A problem in 'install.sh' resulted in sandbox violations on
Gentoo and, when Shorewall is installed using an RPM, the problem
caused an incorrect copy of shorewall.conf to be installed in
/usr/share/shorewall/configfiles/.
2) A typo in the functions file caused startup errors when the user's
distribution did not support a true mktemp program (such as
Bering Uclibc). Patch courtesy of Cédric Schieli.
3) Several erroneous references to ip_addr_del() were made in
/var/lib/shorewall/compiler and in the code that it generates.
a) These should have been references to del_ip_addr()
b) One of the calls also had an incorrect parameter list.
4) Previously, "shorewall check -e" would erroneously attempt to
detect interfaces configured for traffic shaping.
5) SUBSYSLOCK functionality has been restored.
6) In prior versions, setting 'mss=' in /etc/shorewall/zones did not
affect traffic to/from the firewall zone. That has been corrected.
7) When /sbin/shorewall was run under BusyBox ash, shell errors would
occur if certain command options were given.
8) Previously, the 'optional' provider option did not detect the case
where the interface was DOWN but still had a configured IP
address. Shorewall was detecting such interfaces as UP and later
'ip replace route' commands would fail.
It should also be clarified that the 'optional' option is intended
to detect cases where a provider interface is in a state that would
cause 'shorewall [re]start' to fail; it is not intended to
determine whether communication is possible using the interface.
9) Previously, the "shorewall add" command would fail with error
messages indicating that the commands "chain_exists" and
"verify_hosts_file" could not be found.
10) Using earlier Shorewall versions, the following sequence of
commands produced inconsistant results:
a) shorewall [re] start
b) Modify /etc/shorewall/tcdevices and/or /etc/shorewall/tcclasses
c) shorewall refresh
d) shorewall save
e) shorewall restore (or reboot and shorewall start -f during boot
up)
After that series of commands, the state of traffic shaping was as
it was after step a) rather than as it was after step c). The fix
involved re-implementing 'shorewall refresh' as a compile/execute
procedure similar to [re]start. While the entire configuration is
recompiled, only ecn, blacklisting, tcrules and traffic control
will be updated in the running configuration.
11) DNAT rules generated under DETECT_DNAT_IPADDRS=Yes may have been
incorrect with the result that the rules didn't work at all.
Other Shorewall changes in 3.2.3
1) A 'shorewall export' command has been added.
shorewall export [ <directory1> ] [user@]<system>:[<directory2>]
If <directory1> is omitted, then the current working directory is
assumed.
Causes the shorewall configuration in <directory1> to be compiled
into a program called '<directory1>/firewall'. If compilation is
successful, the '<directory1>/firewall' script is copied via scp
to the specified <system>.
Example:
shorewall export admin@gateway:
This command would compile the configuration in the current working
directory then copy the 'firewall' (and 'firewall.conf') files to
admin's home directory on system 'gateway'.
2) Normally, Shorewall tries to protect users from themselves by
preventing PREROUTING and OUTPUT tcrules from being applied to
packets that have been marked by the 'track' option in
/etc/shorewall/providers.
If you really know what you are doing and understand packet marking
thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and
Shorewall will not include these cautionary checks.
3) Previously, CLASSIFY tcrules were always processed out of the
POSTROUTING chain. Beginning with this release, they are processed
out of the POSTROUTING chain *except* when the SOURCE is
$FW[:<address>] in which case the rule is processed out of the
OUTPUT chain.
See the Migration Considerations section for further information.
4) Previously, if you specified 'detectnets' on an interface with a
default route, Shorewall would ignore the default route with a
warning message. This could lead to systems that were inaccessible
from the net, even from systems listed in the 'routestopped' file.
Specifying 'detectnets' on an interface with a default route now
generates a fatal error.
Shorewall Lite problems corrected in 3.2.3
1) A typo in /usr/share/shorewall-lite/functions caused startup errors
on distributions like Bering Uclibc that don't have a true mktemp
utility.
Other Shorewall Lite changes in 3.2.3
None.
+Shorewall Problems Corrected in 3.2.3
1) A problem in 'install.sh' resulted in sandbox violations on
Gentoo and, when Shorewall is installed using an RPM, the problem
caused an incorrect copy of shorewall.conf to be installed in
/usr/share/shorewall/configfiles/.
2) A typo in the functions file caused startup errors when the user's
distribution did not support a true mktemp program (such as
Bering Uclibc). Patch courtesy of Cédric Schieli.
3) Several erroneous references to ip_addr_del() were made in
/var/lib/shorewall/compiler and in the code that it generates.
a) These should have been references to del_ip_addr()
b) One of the calls also had an incorrect parameter list.
4) Previously, "shorewall check -e" would erroneously attempt to
detect interfaces configured for traffic shaping.
5) SUBSYSLOCK functionality has been restored.
6) In prior versions, setting 'mss=' in /etc/shorewall/zones did not
affect traffic to/from the firewall zone. That has been corrected.
7) When /sbin/shorewall was run under BusyBox ash, shell errors would
occur if certain command options were given.
8) Previously, the 'optional' provider option did not detect the case
where the interface was DOWN but still had a configured IP
address. Shorewall was detecting such interfaces as UP and later
'ip replace route' commands would fail.
It should also be clarified that the 'optional' option is intended
to detect cases where a provider interface is in a state that would
cause 'shorewall [re]start' to fail; it is not intended to
determine whether communication is possible using the interface.
9) Previously, the "shorewall add" command would fail with error
messages indicating that the commands "chain_exists" and
"verify_hosts_file" could not be found.
10) Using earlier Shorewall versions, the following sequence of
commands produced inconsistant results:
a) shorewall [re] start
b) Modify /etc/shorewall/tcdevices and/or /etc/shorewall/tcclasses
c) shorewall refresh
d) shorewall save
e) shorewall restore (or reboot and shorewall start -f during boot
up)
After that series of commands, the state of traffic shaping was as
it was after step a) rather than as it was after step c). The fix
involved re-implementing 'shorewall refresh' as a compile/execute
procedure similar to [re]start. While the entire configuration is
recompiled, only ecn, blacklisting, tcrules and traffic control
will be updated in the running configuration.
11) DNAT rules generated under DETECT_DNAT_IPADDRS=Yes may have been
incorrect with the result that the rules didn't work at all.
Other Shorewall changes in 3.2.3
1) A 'shorewall export' command has been added.
shorewall export [ <directory1> ] [user@]<system>:[<directory2>]
If <directory1> is omitted, then the current working directory is
assumed.
Causes the shorewall configuration in <directory1> to be compiled
into a program called '<directory1>/firewall'. If compilation is
successful, the '<directory1>/firewall' script is copied via scp
to the specified <system>.
Example:
shorewall export admin@gateway:
This command would compile the configuration in the current working
directory then copy the 'firewall' (and 'firewall.conf') files to
admin's home directory on system 'gateway'.
2) Normally, Shorewall tries to protect users from themselves by
preventing PREROUTING and OUTPUT tcrules from being applied to
packets that have been marked by the 'track' option in
/etc/shorewall/providers.
If you really know what you are doing and understand packet marking
thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and
Shorewall will not include these cautionary checks.
3) Previously, CLASSIFY tcrules were always processed out of the
POSTROUTING chain. Beginning with this release, they are processed
out of the POSTROUTING chain *except* when the SOURCE is
$FW[:<address>] in which case the rule is processed out of the
OUTPUT chain.
See the Migration Considerations section for further information.
4) Previously, if you specified 'detectnets' on an interface with a
default route, Shorewall would ignore the default route with a
warning message. This could lead to systems that were inaccessible
from the net, even from systems listed in the 'routestopped' file.
Specifying 'detectnets' on an interface with a default route now
generates a fatal error.
Shorewall Lite problems corrected in 3.2.3
1) A typo in /usr/share/shorewall-lite/functions caused startup errors
on distributions like Bering Uclibc that don't have a true mktemp
utility.
Other Shorewall Lite changes in 3.2.3
None.
2006-08-10 Shorewall 3.2.2
@@ -71,12 +65,12 @@ style="font-weight: bold;">
2006-07-19 Shorewall bridge/firewall support
change upcoming
-I regret to announce that Shorewall bridge/firewall support in its
current form (BRIDGING=Yes in shorewall.conf) is going away. I will
retain the code in Shorewall for the foreseeable future but users
migrating to new kernels coming out next year will find that their
current bridge configurations no longer work. Shorewall bridge/firewall
users upgrading to more immediate new kernel releases (possibly as early
as 2.6.18) will find Netfilter warning messages appearing in their
kernel log when Shorewall [re]starts.
The reason that this support is going away is that the underlying
Netfilter feature that BRIDGING=Yes depends on (physdev match) is being
reduced in scope to the point that it will no longer be possible to use
that feature for Shorewall zone definition. There is a significant list
of pending Netfilter bug reports than cannot be resolved so long as
'physdev match' works the way that it does today.
While 'physdev match' was a great idea in terms of the function that it
provides, it appears impossible to implement that function without
breaking other parts of the greater Linux IP stack; in short, 'physdev
match' in its current form should never have been released in the first
place.
So -- what can current Shorewall bridge/firewall users do?
-----------------------------------------------------------------------
a) Configure Shorewall as if you have a simple bridge
(http://www.shorewall.net/SimpleBridge.html) and use ebtables to filter
traffic in and out of the individual bridge ports.
b) Configure Shorewall so that you specifically enumerate the IP
addresses of the hosts connected to all but one of the bridge ports.
Example where br0 connects to 192.168.1.0/24:
/etc/shorewall/shorewall.conf
BRIDGING=<doesn't matter>
/etc/shorewall/zones
z1 ipv4
z2 ipv4
/etc/shorewall/interfaces
- br0 detect routeback
/etc/shorewall/hosts:
z1 br0:192.168.1.1-192.168.1.15,192.168.1.18,...
z2 br0:192.168.1.0/24
In other words, explicitly specify the hosts in the first zone listed
in /etc/shorewall/zones (z1 in the above example) then simply specify
the entire network for the second zone. If the second zone contains your
default gateway, then you would enter 0.0.0.0/0 rather than
192.168.1.0/24.
I will expand these instructions into an article on the web site just as
soon as I find the time.
c) If you have ipset support, you can take the same approach as in b)
above but define 'z1' using one or more ipsets rather than with an
explicit lists of network/host IP addresses. That will generally result
in a smaller ruleset.
-----------------------------------------------------------------------
I realize that the options available to you are more cumbersome to
configure and maintain than what you have today but at the moment, I see
no alternatives. I will however continue to ponder the problem, and if I
come up with something better I will let you know.
-Tom
+I regret to announce that Shorewall bridge/firewall support in its
current form (BRIDGING=Yes in shorewall.conf) is going away. I will
retain the code in Shorewall for the foreseeable future but users
migrating to new kernels coming out next year will find that their
current bridge configurations no longer work. Shorewall bridge/firewall
users upgrading to more immediate new kernel releases (possibly as early
as 2.6.18) will find Netfilter warning messages appearing in their
kernel log when Shorewall [re]starts.
The reason that this support is going away is that the underlying
Netfilter feature that BRIDGING=Yes depends on (physdev match) is being
reduced in scope to the point that it will no longer be possible to use
that feature for Shorewall zone definition. There is a significant list
of pending Netfilter bug reports than cannot be resolved so long as
'physdev match' works the way that it does today.
While 'physdev match' was a great idea in terms of the function that it
provides, it appears impossible to implement that function without
breaking other parts of the greater Linux IP stack; in short, 'physdev
match' in its current form should never have been released in the first
place.
So -- what can current Shorewall bridge/firewall users do?
-----------------------------------------------------------------------
a) Configure Shorewall as if you have a simple bridge
(http://www.shorewall.net/SimpleBridge.html) and use ebtables to filter
traffic in and out of the individual bridge ports.
b) Configure Shorewall so that you specifically enumerate the IP
addresses of the hosts connected to all but one of the bridge ports.
Example where br0 connects to 192.168.1.0/24:
/etc/shorewall/shorewall.conf
BRIDGING=<doesn't matter>
/etc/shorewall/zones
z1 ipv4
z2 ipv4
/etc/shorewall/interfaces
- br0 detect routeback
/etc/shorewall/hosts:
z1 br0:192.168.1.1-192.168.1.15,192.168.1.18,...
z2 br0:192.168.1.0/24
In other words, explicitly specify the hosts in the first zone listed
in /etc/shorewall/zones (z1 in the above example) then simply specify
the entire network for the second zone. If the second zone contains your
default gateway, then you would enter 0.0.0.0/0 rather than
192.168.1.0/24.
I will expand these instructions into an article on the web site just as
soon as I find the time.
c) If you have ipset support, you can take the same approach as in b)
above but define 'z1' using one or more ipsets rather than with an
explicit lists of network/host IP addresses. That will generally result
in a smaller ruleset.
-----------------------------------------------------------------------
I realize that the options available to you are more cumbersome to
configure and maintain than what you have today but at the moment, I see
no alternatives. I will however continue to ponder the problem, and if I
come up with something better I will let you know.
-Tom
2006-07-11 Shorewall 3.2.0
-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 if 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 to configure the firewall.
The generated script supports the following commands:
start - starts the firewall
stop - stops the firewall
clear - clears the firewall (removes all iptables rules)
restart - restarts the firewall
status - displays the firewall status
version - displays the version of shorewall used to create the
script
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.
+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 if 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 to configure the firewall.
The generated script supports the following commands:
start - starts the firewall
stop - stops the firewall
clear - clears the firewall (removes all iptables rules)
restart - restarts the firewall
status - displays the firewall status
version - displays the version of shorewall used to create the
script
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.
2006-06-21 Shorewall 3.0.8
@@ -119,7 +113,7 @@ for more information.
2006-01-05 Shorewall 3.0.4
-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.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.
2005-12-13 Shorewall 3.0.3
@@ -164,36 +158,44 @@ for more information.
Problems Corrected in 2.4.7
-1) When MACLIST_TABLE=mangle and an interface is enabled for DHCP (the
- 'dhcp' option is specified in /etc/shorewall/interfaces) then
-broadcasts
- on UDP port 67 to address 255.255.255.255 from address 0.0.0.0 were
-being
- dropped and logged. While this did not prevent the client from
-acquiring
- an IP address, it could result in lots of log messages.
+1) When MACLIST_TABLE=mangle and an interface is enabled for DHCP
+(the
+ 'dhcp' option is specified in /etc/shorewall/interfaces)
+then broadcasts
+ on UDP port 67 to address 255.255.255.255 from address
+0.0.0.0 were being
+ dropped and logged. While this did not prevent the client
+from acquiring
+ an IP address, it could result in lots of log messages.
-2) Entries for openvpn tunnels (including openvpnclient and
- openvpnserver) that specify a port but no protocol cause startup
- errors as follows:
+2) Entries for openvpn tunnels (including openvpnclient and
+ openvpnserver) that specify a port but no protocol cause
+startup
+ errors as follows:
- iptables v1.3.3: unknown protocol `1194' specified
- Try `iptables -h' or 'iptables --help' for more
-information.
- ERROR: Command "/usr/sbin/iptables -A net2fw -p 1194 -s
- 0.0.0.0/0 --sport 1194 -j ACCEPT" Failed
+ iptables
+v1.3.3: unknown protocol `1194' specified
+ Try
+`iptables -h' or 'iptables --help' for more information.
+ ERROR:
+Command "/usr/sbin/iptables -A net2fw -p 1194 -s
+ 0.0.0.0/0
+--sport 1194 -j ACCEPT" Failed
- The problem may be worked around by specifying the protocol as well
- (e.g., "openvpn:udp:3455).
+ The problem may be worked around by specifying the
+protocol as well
+ (e.g., "openvpn:udp:3455).
-3) 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.
+3) 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.
-4) Specifying an interface name in the SOURCE column
- of /etc/shorewall/tcrules resulted in a startup error.
+4) Specifying an interface name in the SOURCE column
+ of /etc/shorewall/tcrules resulted in a startup error.
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".
+ - 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.
+ 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.
+ [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.
+ - 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.
+ 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.
+ - 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.
+ 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".
+ - 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.
+ 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.
+ - 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).
+ - 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:
+ 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:
+
+ 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.
+ 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.
+
+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.
+/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
+
+
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
+href="http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">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
+href="http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">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
+href="http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">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
+href="http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">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.
+href="http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall">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
+href="http://seclists.org/lists/fulldisclosure/2005/Jul/0409.html">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
+
+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.
+ - 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.
+ 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.
+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.
+ - 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.
+ 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:
+ Columns are:
-
-NAME
-The provider name.
+
+ NAME
+ The provider name.
-
-NUMBER The
-provider number -- a number between 1 and 15
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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:
+
+ 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.
+
+ 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.
+
+ 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).
+
+ 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.
+
+ 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
+ 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 -
+
+ #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.
+ 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.
+ 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.
+ - 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:
+ 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
+ /etc/shorewall/accounting
+ /etc/shorewall/rules
+ /etc/shorewall/tcrules
+
+ /usr/share/shorewall/action.template
-To specify a command, prefix the command name with "+".
+ To specify a command, prefix the command name with "+".
- Examples:
+ 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".
+
+ +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.
+ 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/).
+ href="http://people.netfilter.org/kadlec/ipset/">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 "+".
+ 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"
+ Example: "+Mirrors"
-The name of the set may be optionally followed by:
+ 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.
+ 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]"
+ 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.
+ 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]"
+ 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]".
+ 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".
+ To generate a negative match, prefix the "+" with "!" as in
+ "!+Mirrors".
-Example 1: Blacklist all hosts in an ipset named "blacklist"
+ Example 1: Blacklist all hosts in an ipset named "blacklist"
-
-/etc/shorewall/blacklist
+
+ /etc/shorewall/blacklist
-
-#ADDRESS/SUBNET
-PROTOCOL PORT
-
-+blacklist
+
+ #ADDRESS/SUBNET
+ PROTOCOL PORT
+
+ +blacklist
-Example 2: Allow SSH from all hosts in an ipset named "sshok:
+ Example 2: Allow SSH from all hosts in an ipset named "sshok:
-
-/etc/shorewall/rules
+
+ /etc/shorewall/rules
-
-#ACTION
-SOURCE DEST
-PROTO DEST PORT(S)
-
-ACCEPT
-+sshok
-fw
-tcp 22
+
+ #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.
+ 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.
+ 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.
+ 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.
+ 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:
+ You can also associate ipset contents with Shorewall configuration
+ directories using the following command:
- ipset -S > <config
-directory>/ipsets
+ ipset -S > <config
+ directory>/ipsets
-Example:
+ Example:
- ipset -S > /etc/shorewall/ipsets
+ 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.
+ 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).
+ 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:
+ Example /etc/shorewall/blacklist:
-#ADDRESS/SUBNET
-PROTOCOL PORT
+ #ADDRESS/SUBNET
+ PROTOCOL PORT
-+Blacklist[src,dst]
+ +Blacklist[src,dst]
-+Blacklistnets[src,dst]
+ +Blacklistnets[src,dst]
-Create the blacklist ipsets using:
+ Create the blacklist ipsets using:
- ipset -N
-Blacklist iphash
- ipset -N
-Blacklistnets nethash
+ ipset -N Blacklist
+ iphash
+ ipset -N
+ Blacklistnets nethash
-Add entries
+ Add entries
- ipset -A Blacklist 206.124.146.177
- ipset -A Blacklistnets
-206.124.146.0/24
+ ipset -A Blacklist
+ 206.124.146.177
+ ipset -A Blacklistnets
+ 206.124.146.0/24
-To allow entries for individual ports
+ To allow entries for individual ports
- ipset -N SMTP portmap --from 1
---to 31
- ipset -A SMTP 25
+ 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
+ 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.
+ 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.
+ 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:
+ 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:
+ 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.
+
+ - 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:
+
+ 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.
+
+ - 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.
+
+ 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).
+
+ 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.
+
+ 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 "-"
+
+ 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.
+
+ 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.
+
+ 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]
+
+ The rule will match only if the test returns true. Tests have the format
+
+ [!]<value>[/<mask>][:C]
-
-Where:
+
+ Where:
-
-! Inverts the test (not equal)
- <value> Value of the
-packet or
-
-connection mark.
+
+ ! 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.
+
+ <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.
+
+ 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.
+
+ 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.
+ 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'.
+ 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'.
+ 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".
+ 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-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.
+ 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.
+ These new commands require either that your /bin/sh supports the "-t"
+ option to the 'read' command or that you have /bin/bash installed.
- 05/20/2005 Shorewall CVS
- Repository has Moved to Sourceforge
+05/20/2005 Shorewall CVS Repository
+has Moved to Sourceforge
+
+ The CVS repository may now be accessed at http://sourceforge.net/cvs/?group_id=22587.
+
+05/20/2005 Shorewall 2.2.5
+
+ This will be my last 2.2 release. It contains a couple of small bug
+fixes that I hadn't yet released.
+
+-Tom
+
+Problems Corrected:
+
+
+ - Previously, if PKTTYPE=No in shorewall.conf then pkttype match would
+ still be used if the kernel supported it.
+ - A typo in the 'tunnel' script has been corrected (Thanks to Patrik
+ Varmecký).
+ - A warning is now generated if an invalid short zone name is used in
+ /etc/shorewall/zones.
+
+
+05/18/2005 Tom stepping away from Shorewall
+development and support
+
+It is with regret that I announce that my involvement in Shorewall
+development and support is officially ending.
+
+Unlike the originators of other successful open source projects, I have not
+been able to attract a core of people who believe in Shorewall and who are
+willing to make sacrifices to ensure it's success. That is my weakness and I
+accept it. But is means that I have been left with trying to develop,
+document, and support Shorewall almost single-handedly. I cannot do it any
+more.
+
+I will clean up what I have for a 2.3 release and place it on the server as
+my last Shorewall release -- Shorewall 2.4.0.
+
+Discussions aimed at continuing Shorewall development under new leadership
+are continuing.
+
+Shorewall will always be a part of my life that I look back on with
+fondness.
+
+Regards,
+
+-Tom
+
+
+05/02/2005 Shorewall 2.2.4
+
+
+Problems Corrected:
+
+
+ - The error message:
-
The CVS repository may now be accessed at http://sourceforge.net/cvs/?group_id=22587.
-
-
- 05/20/2005 Shorewall 2.2.5
+ Error: No appropriate chain for zone
+ <z1> to zone <z2>
- This will be my last 2.2 release. It contains a couple
- of small bug fixes that I hadn't yet released.
-
- -Tom
-
- Problems Corrected:
-
-
-
- - Previously, if PKTTYPE=No in shorewall.conf then pkttype
- match would still be used if the kernel supported it.
-
- - A typo in the 'tunnel' script has been corrected (Thanks
- to Patrik Varmecký).
-
- - A warning is now generated if an invalid short zone name
- is used in /etc/shorewall/zones.
-
-
- 05/18/2005 Tom stepping away
- from Shorewall development and support
-
- It is with regret that I announce that my involvement in
- Shorewall development and support is officially ending.
-
- Unlike the originators of other successful open source
- projects, I have not been able to attract a core of people who
- believe in Shorewall and who are willing to make sacrifices to
- ensure it's success. That is my weakness and I accept it. But
- is means that I have been left with trying to develop,
- document, and support Shorewall almost single-handedly. I
- cannot do it any more.
-
- I will clean up what I have for a 2.3 release and place it on
- the server as my last Shorewall release -- Shorewall 2.4.0.
-
- Discussions aimed at continuing Shorewall development under
- new leadership are continuing.
-
- Shorewall will always be a part of my life that I look back on
- with fondness.
-
- Regards,
-
- -Tom
-
-
- 05/02/2005 Shorewall
- 2.2.4
-
-
- Problems Corrected:
-
-
-
- - The error message:
-
- Error: No appropriate
- chain for zone <z1> to zone <z2>
-
- has been changed to one that is more self-explanatory:
-
- Error: No policy
- defined for zone <z1> to zone <z2>
-
- - When only an interface name appeared in the HOST(S)
- column of an /etc/shorewall/hosts file entry, a misleading
- iptables error message resulted. Now the following message is
- generated:
-
- Error: Invalid HOST(S)
- column contents: <column contents>
-
- New Features:
-
-
-
- - Support has been added for UPnP using linux-igd (http://linux-idg.sourceforge.net).
- UPnP is required by a number of popular applications
- including MSN IM.
-
-
-
-
WARNING:
-
-
-
- From a security architecture viewpoint, UPnP is a disaster.
- It assumes that:
-
-
-
- - All local systems and their users are completely
- trustworthy.
-
- - No local system is infected with any worm or
- trojan.
-
-
-
-
- If either of these assumptions are not true then UPnP can
- be used to totally defeat your firewall and to allow
- incoming connections to arbitrary local systems on any port
- whatsoever.
- In short: USE UPnP AT
- YOUR OWN RISK.
-
-
-
-
-
-
-
WARNING:
-
-
-
- The linux-igd project appears to be inactive and the web
- site does not display correctly on any open source browser
- that I've tried.
-
- Building and installing linux-igd is not for the faint of
- heart. You must download the source from CVS and be
- prepared to do quite a bit of fiddling with the include
- files from libupnp (which is required to build and/or run
- linux-igd).
-
-
-
- Configuring linux-igd:
-
-
-
- In /etc/upnpd.conf, you will want:
-
-
- insert_forward_rules = yes
-
- prerouting_chain_name = UPnP
-
- forward_chain_name = forwardUPnP
-
-
-
- Shorewall Configuration:
-
-
-
- In /etc/shorewall/interfaces, you need the 'upnp' option on
- your external interface.
-
- If your fw->loc policy is not ACCEPT then you need this
- rule:
-
-
- allowoutUPnP
- fw loc
-
- Note: To use 'allowoutUPnP', your iptables and kernel must
- support the 'owner match' feature (see the output of
- "shorewall check").
-
- If your loc->fw policy is not ACCEPT then you need this
- rule:
-
-
- allowinUPnP
- loc fw
-
- You MUST have this rule:
-
-
- forwardUPnP
- net loc
-
-
-
- You must also ensure that you have a route to
- 224.0.0.0/4 on you internal (local) interface.
-
-
-
- - A new 'started' extension script has been added.
- The difference between this extension script and
- /etc/shorewall/start is that this one is invoked after
- delayed loading of the blacklist (DELAYBLACKLISTLOAD=Yes) and
- after the 'shorewall' chain has been created (thus signaling
- that the firewall is completely up.
-
- /etc/shorewall/started should not change the firewall
- configuration directly but may do so indirectly by running
- /sbin/shorewall with the 'nolock' option.
-
-
-
- - By default, shorewall is started with the "-f" (fast)
- option when your system boots. You can override that setting
- by setting the OPTIONS variable in /etc/sysconfig/shorewall
- (SUSE/Redhat) or /etc/default/shorewall (Debian/Bering). If
- neither file exists, feel free to create one or the
- other.
-
- Example: If you want Shorewall to always use the config
- files even if there is a saved configuration, then
- specify:
-
- OPTIONS=""
-
-
-
- - Shorewall now has support for the SAME target. This
- change affects the /etc/shorewall/masq and
- /etc/shorewall/rules file.
-
- SAME is useful when you specify multiple target IP addresses
- (in the ADDRESSES column of /etc/shorewall/masq or in the
- DEST column of /etc/shorewall/rules).
-
- If you use normal SNAT then multiple connections from a
- given local host to hosts on the internet can be assigned
- different source IP addresses. This confuses some
- applications that use multiple connections. To correct this
- problem, prefix the list of address ranges in the ADDRESS
- column with "SAME:"
-
-
- Example: SAME:206.124.146.176-206.124.146.180
-
- If you want each internal system to use the same IP address
- from the list regardless of which internet host it is talking
- to then prefix the ranges with "SAME:nodst:".
-
-
- Example:
- SAME:nodst:206.124.146.176-206.124.146.180
-
- Note that it is not possible to map port numbers when using
- SAME.
-
- In the rules file, when multiple connections from an
- internet host match a SAME rule then all of the connections
- will be sent to the same internal server. SAME rules are very
- similar to DNAT rules with the keyword SAME replacing DNAT.
- As in the masq file, changing the port number is not
- supported.
-
-
-
- - A "shorewall show capabilities" command has been added to
- report the capabilities of your kernel and iptables.
-
- Example:
-
- gateway:~# shorewall show
- capabilities
- Loading
- /usr/share/shorewall/functions...
- Processing
- /etc/shorewall/params ...
- Processing
- /etc/shorewall/shorewall.conf...
- Loading Modules...
- Shorewall has detected the
- following iptables/netfilter capabilities:
-
- NAT: Available
-
- Packet Mangling: Available
-
- Multi-port Match: Available
-
- Extended Multi-port Match: Available
-
- Connection Tracking Match: Available
-
- Packet Type Match: Not available
-
- Policy Match: Available
-
- Physdev Match: Available
-
- IP range Match: Available
-
- Recent Match: Available
-
- Owner Match: Available
- gateway:~#
-
-
-
- - A "-v" option has been added to /sbin/shorewall.
- Currently, this option only affects the "show log" command
- (e.g., "shorewall -v show log") and the "monitor" command. In
- these commands, it causes the MAC address in the log message
- (if any) to be displayed. As previously, when "-v" is
- omitted, the MAC address is suppressed.
-
-
-
- - In /etc/shorewall/rules, a value of 'none' in either the
- SOURCE or DEST columns now causes the rule to be ignored.
- This is most useful when used with shell variables:
-
- Example:
-
-
- /etc/shorewall/rules:
-
-
- AllowFTP
- $FTP_CLIENTS fw
-
- When FTP_CLIENTS
- is set to 'none', the above rule is ignored. Otherwise,
- the rule is evaluated and generates Netfilter rules.
-
-
-
- - The installer now detects that it is running on a
- Slackware system and adjusts the DEST and INIT variables
- accordingly.
-
-
-
- 05/01/2005 Tom spoke at
- LinuxFest NW 2005 -- Bellingham Technical College, Bellingham
- Washington
-
- Tom's presentation was entitled "Shorewall and Native IPSEC"
- and is available for download here (PDF Format).
+ has been changed to one that is more self-explanatory:
- 04/07/2005 Shorewall
- 2.2.3
-
- Problems Corrected:
-
-
-
- - If a zone is defined in /etc/shorewall/hosts using
- <interface>:!<network> in the HOSTS column then
- startup errors occur on "shorewall [re]start".
-
- - Previously, if "shorewall status" was run on a system
- whose kernel lacked advanced routing support
- (CONFIG_IP_ADVANCED_ROUTER), then no routing
- information was displayed.
-
- New Features:
-
-
-
- - A new extension script "continue" has been added. This
- script is invoked after Shorewall has set the built-in filter
- chains policy to DROP, deleted any existing Netfilter rules
- and user chains and has enabled existing connections. It is
- useful for enabling certain communication while Shorewall is
- being [re]started. Be sure to delete any rules that you add
- here in your /etc/shorewall/start file.
-
- - There has been ongoing confusion about how the
- /etc/shorewall/routestopped file works. People understand how
- it works with the 'shorewall stop' command but when they read
- that 'shorewall restart' is logically equivalent to
- 'shorewall stop' followed by 'shorewall start' then they
- erroneously conclude that /etc/shorewall/routestopped can be
- used to enable new connections during 'shorewall restart'. Up
- to now, it cannot -- that file is not processed during either
- 'shorewall start' or 'shorewall restart'.
-
- Beginning with Shorewall version 2.2.3,
- /etc/shorewall/routestopped will be processed TWICE during
- 'shorewall start' and during 'shorewall restart'. It will be
- processed early in the command execution to add rules
- allowing new connections while the command is running and it
- will be processed again when the command is complete to
- remove the rules added earlier.
-
- The result of this change will be that during most of
- [re]start, new connections will be allowed in accordance with
- the contents of /etc/shorewall/routestopped.
-
- - The performance of configurations with a large numbers of
- entries in /etc/shorewall/maclist can be improved by setting
- the new MACLIST_TTL variable in
- /etc/shorewall/shorewall.conf.
-
- If your iptables and kernel support the "Recent Match" (see
- the output of "shorewall check" near the top), you can cache
- the results of a 'maclist' file lookup and thus reduce the
- overhead associated with MAC Verification.
-
- When a new connection arrives from a 'maclist' interface,
- the packet passes through then list of entries for that
- interface in /etc/shorewall/maclist. If there is a match then
- the source IP address is added to the 'Recent' set for that
- interface. Subsequent connection attempts from that IP
- address occuring within $MACLIST_TTL seconds will be accepted
- without having to scan all of the entries. After $MACLIST_TTL
- from the first accepted connection request from an IP
- address, the next connection request from that IP address
- will be checked against the entire list.
-
- If MACLIST_TTL is not specified or is specified as empty
- (e.g, MACLIST_TTL="" or is specified as zero then 'maclist'
- lookups will not be cached.
-
- - You can now specify QUEUE as a policy and you can
- designate a common action for QUEUE policies in
- /etc/shorewall/actions. This is useful for sending packets to
- something like Snort Inline.
-
-
- 03/31/2005 Shorewall
- 2.0.17
+ Error: No policy defined for zone
+ <z1> to zone <z2>
+ When only an interface name appeared in the HOST(S) column of an
+ /etc/shorewall/hosts file entry, a misleading iptables error message
+ resulted. Now the following message is generated:
- Problems Corrected:
+ Error: Invalid HOST(S) column
+ contents: <column contents>
+
+New Features:
+
+
+ - Support has been added for UPnP using linux-igd (http://linux-idg.sourceforge.net).
+ UPnP is required by a number of popular applications including MSN
+ IM.
+
+
+
+
WARNING:
-
- - Invoking the 'rejNotSyn' action results in an error at
- startup.
+
+From a security architecture viewpoint, UPnP is a disaster. It assumes
+that:
-
- The UDP and TCP port numbers in
- /usr/share/shorewall/action.AllowPCA were reversed.
+
+ - All local systems and their users are completely trustworthy.
+ - No local system is infected with any worm or trojan.
+
+
- If a zone is defined in /etc/shorewall/hosts using
- <interface>:!<network> in the HOSTS column
- then startup errors occur on "shorewall [re]start".
-
-
-
03/12/2005 Shorewall 2.2.2
-
- Problems Corrected:
+
+If either of these assumptions are not true then UPnP can be used to totally
+defeat your firewall and to allow incoming connections to arbitrary local
+systems on any port whatsoever.
+In short: USE UPnP AT YOUR OWN
+RISK.
+
+
+
+
+
+
+
WARNING:
-
- - The SOURCE column in the /etc/shorewall/tcrules file now
- correctly allows IP ranges (assuming that your iptables and
- kernel support ranges).
-
+
+The linux-igd project appears to be inactive and the web site does not
+display correctly on any open source browser that I've tried.
+
+Building and installing linux-igd is not for the faint of heart. You must
+download the source from CVS and be prepared to do quite a bit of fiddling
+with the include files from libupnp (which is required to build and/or run
+linux-igd).
+
+
+
-
-
- New Features:
+
+Configuring linux-igd:
-
- - The SOURCE column in the /etc/shorewall/tcrules file now
- allows $FW to be optionally followed by ":" and a
- host/network address or address range.
+
+In /etc/upnpd.conf, you will want:
+
+
+insert_forward_rules = yes
+
+prerouting_chain_name = UPnP
+
+forward_chain_name = forwardUPnP
+
+
+
+Shorewall Configuration:
-
The output from 'arp -na' has been added to the
- 'shorewall status' display.
-
The 2.6.11 Linux kernel and iptables 1.3.0 now allow port
- ranges to appear in port lists handled by "multiport match".
- If Shorewall detects this capability, it will use "multiport
- match" for port lists containing port ranges. Be cautioned
- that each port range counts for TWO ports and a port list
- handled with "multiport match" can still specify a maximum of
- 15 ports.
-
- As always, if a port list in /etc/shorewall/rules is
- incompatible with "multiport match", a separate iptables rule
- will be generated for each element in the list.
+
+In /etc/shorewall/interfaces, you need the 'upnp' option on your external
+interface.
+
+If your fw->loc policy is not ACCEPT then you need this rule:
+
+
+allowoutUPnP
+fw loc
+
+Note: To use 'allowoutUPnP', your iptables and kernel must support the 'owner
+match' feature (see the output of "shorewall check").
+
+If your loc->fw policy is not ACCEPT then you need this rule:
+
+
+allowinUPnP
+loc fw
+
+You MUST have this rule:
+
+
+forwardUPnP
+net loc
+
+
+
-
-
- SUBNETS
- TARGET
-
- 192.168.1.0/24 RETURN
-
- then traffic from 192.168.1.4 to 10.0.3.9 will be accepted
- even though you also have:
-
-
- SUBNETS
- TARGET
-
- 10.0.0.0/8
- logdrop
-
- Setting RFC1918_STRICT=Yes in shorewall.conf will cause such
- traffic to be logged and dropped since while the packet's
- source matches the RETURN rule, the packet's destination
- matches the 'logdrop' rule.
-
- If not specified or specified as empty (e.g.,
- RFC1918_STRICT="") then RFC1918_STRICT=No is assumed.
-
- WARNING: RFC1918_STRICT=Yes requires that your kernel and
- iptables support 'Connection Tracking' match.
-
-
-
- 02/15/2005 Shorewall
- 2.2.1
+
+ You must also ensure that you have a route to 224.0.0.0/4 on you
+internal (local) interface.
+
+
+ - A new 'started' extension script has been added. The difference
+ between this extension script and /etc/shorewall/start is that this one
+ is invoked after delayed loading of the blacklist
+ (DELAYBLACKLISTLOAD=Yes) and after the 'shorewall' chain has been created
+ (thus signaling that the firewall is completely up.
-
This release rolls up the fixes for bugs found in the
- first 2-3 weeks of deployment of Shorewall 2.2.
-
-
-
- - The /etc/shorewall/policy file contained a misleading
- comment and both that file and the /etc/shorewall/zones file
- lacked examples.
-
- - Shorewall previously used root's default umask which
- could cause files in /var/lib/shorewall to be world-readable.
- Shorewall now uses umask 0177.
-
- - In log messages produced by logging a built-in action,
- the packet disposition was displayed incorrectly.
-
- Example:
-
-
- rejNotSyn:ULOG
- all
- all
- tcp
-
- produces the log message:
-
-
- Feb 12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...
-
- rather than
-
-
- Feb 12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...
-
-
-
- - The comments regarding built-in actions in
- /usr/share/shorewall/actions.std have been corrected.
-
- - The /etc/shorewall/policy file in the LRP package was
- missing the 'all->all' policy.
-
-
- 02/05/2005 End of Support for
- Shorewall 1.4
+ /etc/shorewall/started should not change the firewall configuration
+ directly but may do so indirectly by running /sbin/shorewall with the
+ 'nolock' option.
- Effective today, support for Shorewall 1.4 has been
- discontinued. See the link at the top of this article for
- upgrade information.
-
- 02/01/2005 Shorewall
- 2.0.16
-
- This release back-ports the DROPINVALID shorewall.conf option
- from 2.2.0.
-
-
-
- - Recent 2.6 kernels include code that evaluates TCP
- packets based on TCP Window analysis. This can cause packets
- that were previously classified as NEW or ESTABLISHED to be
- classified as INVALID.
-
- The new kernel code can be disabled by including this
- command in your /etc/shorewall/init file:
-
- echo 1 >
- /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
-
- Additional kernel logging about INVALID TCP packets may be
- obtained by adding this command to /etc/shorewall/init:
-
- echo 1 >
- /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
-
- Traditionally, Shorewall has dropped INVALID TCP packets
- early. The new DROPINVALID option allows INVALID packets to
- be passed through the normal rules chains by setting
- DROPINVALID=No.
-
- If not specified or if specified as empty (e.g.,
- DROPINVALID="") then DROPINVALID=Yes is assumed.
-
-
- 02/01/2005 Shorewall
- 2.2.0
+
+ By default, shorewall is started with the "-f" (fast) option when your
+ system boots. You can override that setting by setting the OPTIONS
+ variable in /etc/sysconfig/shorewall (SUSE/Redhat) or
+ /etc/default/shorewall (Debian/Bering). If neither file exists, feel free
+ to create one or the other.
- New Features:
-
+ Example: If you want Shorewall to always use the config files even if
+ there is a saved configuration, then specify:
+
+ OPTIONS=""
+
+
+ Shorewall now has support for the SAME target. This change affects the
+ /etc/shorewall/masq and /etc/shorewall/rules file.
+
+ SAME is useful when you specify multiple target IP addresses (in the
+ ADDRESSES column of /etc/shorewall/masq or in the DEST column of
+ /etc/shorewall/rules).
+
+ If you use normal SNAT then multiple connections from a given local host
+ to hosts on the internet can be assigned different source IP addresses.
+ This confuses some applications that use multiple connections. To correct
+ this problem, prefix the list of address ranges in the ADDRESS column
+ with "SAME:"
+
+
+ Example: SAME:206.124.146.176-206.124.146.180
+
+ If you want each internal system to use the same IP address from the list
+ regardless of which internet host it is talking to then prefix the ranges
+ with "SAME:nodst:".
+
+
+ Example: SAME:nodst:206.124.146.176-206.124.146.180
+
+ Note that it is not possible to map port numbers when using SAME.
+
+ In the rules file, when multiple connections from an internet host match
+ a SAME rule then all of the connections will be sent to the same internal
+ server. SAME rules are very similar to DNAT rules with the keyword SAME
+ replacing DNAT. As in the masq file, changing the port number is not
+ supported.
+
+
+ A "shorewall show capabilities" command has been added to report the
+ capabilities of your kernel and iptables.
+
+ Example:
+
+ gateway:~# shorewall show capabilities
+ Loading
+ /usr/share/shorewall/functions...
+ Processing /etc/shorewall/params ...
+ Processing
+ /etc/shorewall/shorewall.conf...
+ Loading Modules...
+ Shorewall has detected the following
+ iptables/netfilter capabilities:
+
+ NAT: Available
+
+ Packet Mangling: Available
+
+ Multi-port Match: Available
+
+ Extended Multi-port Match: Available
+
+ Connection Tracking Match: Available
+
+ Packet Type Match: Not available
+
+ Policy Match: Available
+
+ Physdev Match: Available
+
+ IP range Match: Available
+
+ Recent Match: Available
+
+ Owner Match: Available
+ gateway:~#
+
+
+ A "-v" option has been added to /sbin/shorewall. Currently, this option
+ only affects the "show log" command (e.g., "shorewall -v show log") and
+ the "monitor" command. In these commands, it causes the MAC address in
+ the log message (if any) to be displayed. As previously, when "-v" is
+ omitted, the MAC address is suppressed.
+
+
+ In /etc/shorewall/rules, a value of 'none' in either the SOURCE or DEST
+ columns now causes the rule to be ignored. This is most useful when used
+ with shell variables:
+
+ Example:
+
+ /etc/shorewall/rules:
+
+
+ AllowFTP
+ $FTP_CLIENTS fw
+
+ When FTP_CLIENTS is set to
+ 'none', the above rule is ignored. Otherwise, the rule is evaluated
+ and generates Netfilter rules.
+
+
+ The installer now detects that it is running on a Slackware system and
+ adjusts the DEST and INIT variables accordingly.
+
+
-
- - ICMP packets that are in the INVALID state are now
- dropped by the Reject and Drop default actions. They do so
- using the new 'dropInvalid' builtin action. An 'allowInvalid'
- builtin action is also provided which accepts packets in that
- state.
+05/01/2005 Tom spoke at LinuxFest NW 2005
+-- Bellingham Technical College, Bellingham Washington
+
+Tom's presentation was entitled "Shorewall and Native IPSEC" and is available
+for download here (PDF
+Format).
+
+04/07/2005 Shorewall 2.2.3
+
+Problems Corrected:
+
+
+ - If a zone is defined in /etc/shorewall/hosts using
+ <interface>:!<network> in the HOSTS column then startup
+ errors occur on "shorewall [re]start".
+ - Previously, if "shorewall status" was run on a system whose kernel
+ lacked advanced routing support (CONFIG_IP_ADVANCED_ROUTER), then
+ no routing information was displayed.
+
+New Features:
- - The /etc/shorewall/masq file INTERFACE column now allows
- additional options.
-
- Normally MASQUERADE/SNAT rules are evaluated after
- one-to-one NAT rules defined in the /etc/shorewall/nat file.
- If you preceed the interface name with a plus sign ("+") then
- the rule will be evaluated before one-to-one NAT.
-
- Examples:
-
- +eth0
- +eth1:192.0.2.32/27
-
- Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for
- an entry by following the interface name by ":" but no
- digit.
-
- Examples:
-
- eth0:
- eth1::192.0.2.32/27
- +eth3:
-
-
+
+ - A new extension script "continue" has been added. This script is
+ invoked after Shorewall has set the built-in filter chains policy to
+ DROP, deleted any existing Netfilter rules and user chains and has
+ enabled existing connections. It is useful for enabling certain
+ communication while Shorewall is being [re]started. Be sure to delete any
+ rules that you add here in your /etc/shorewall/start file.
+ - There has been ongoing confusion about how the
+ /etc/shorewall/routestopped file works. People understand how it works
+ with the 'shorewall stop' command but when they read that 'shorewall
+ restart' is logically equivalent to 'shorewall stop' followed by
+ 'shorewall start' then they erroneously conclude that
+ /etc/shorewall/routestopped can be used to enable new connections during
+ 'shorewall restart'. Up to now, it cannot -- that file is not processed
+ during either 'shorewall start' or 'shorewall restart'.
+
+ Beginning with Shorewall version 2.2.3, /etc/shorewall/routestopped will
+ be processed TWICE during 'shorewall start' and during 'shorewall
+ restart'. It will be processed early in the command execution to add
+ rules allowing new connections while the command is running and it will
+ be processed again when the command is complete to remove the rules added
+ earlier.
+
+ The result of this change will be that during most of [re]start, new
+ connections will be allowed in accordance with the contents of
+ /etc/shorewall/routestopped.
+ - The performance of configurations with a large numbers of entries in
+ /etc/shorewall/maclist can be improved by setting the new MACLIST_TTL
+ variable in /etc/shorewall/shorewall.conf.
+
+ If your iptables and kernel support the "Recent Match" (see the output of
+ "shorewall check" near the top), you can cache the results of a 'maclist'
+ file lookup and thus reduce the overhead associated with MAC
+ Verification.
+
+ When a new connection arrives from a 'maclist' interface, the packet
+ passes through then list of entries for that interface in
+ /etc/shorewall/maclist. If there is a match then the source IP address is
+ added to the 'Recent' set for that interface. Subsequent connection
+ attempts from that IP address occuring within $MACLIST_TTL seconds will
+ be accepted without having to scan all of the entries. After $MACLIST_TTL
+ from the first accepted connection request from an IP address, the next
+ connection request from that IP address will be checked against the
+ entire list.
+
+ If MACLIST_TTL is not specified or is specified as empty (e.g,
+ MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not be
+ cached.
+ - You can now specify QUEUE as a policy and you can designate a common
+ action for QUEUE policies in /etc/shorewall/actions. This is useful for
+ sending packets to something like Snort Inline.
+
+
+03/31/2005 Shorewall 2.0.17
+
+ Problems Corrected:
- - Similar to 2), the /etc/shorewall/nat file INTERFACE
- column now allows you to override the setting of
- ADD_IP_ALIASES=Yes by following the interface name with ":"
- but no digit.
+
+ - Invoking the 'rejNotSyn' action results in an error at startup.
+ - The UDP and TCP port numbers in /usr/share/shorewall/action.AllowPCA
+ were reversed.
+ - If a zone is defined in /etc/shorewall/hosts using <interface>:!<network> in the HOSTS column then
+ startup errors occur on "shorewall [re]start".
+
+
+03/12/2005 Shorewall 2.2.2
+
+Problems Corrected:
- - All configuration files in the Shorewall distribution
- with the exception of shorewall.conf are now empty. In
- particular, the /etc/shorewall/zones, /etc/shorewall/policy
- and /etc/shorewall/tos files now have no active entries.
- Hopefully this will stop the questions on the support and
- development lists regarding why the default entries are the
- way they are.
+
+ - The SOURCE column in the /etc/shorewall/tcrules file now correctly
+ allows IP ranges (assuming that your iptables and kernel support
+ ranges).
+
+ - If A is a user-defined action and you have file /etc/shorewall/A then
+ when that file is invoked by Shorewall during [re]start, the $TAG value
+ may be incorrect.
+ - Previously, if an iptables command generating a logging rule failed,
+ the Shorewall [re]start was still successful. This error is now
+ considered fatal and Shorewall will be either restored from the last save
+ (if any) or it will be stopped.
+ - The port numbers for UDP and TCP were previously reversed in the
+ /usr/share/shorewall/action.AllowPCA file.
+ - Previously, the 'install.sh' script did not update the
+ /usr/share/shorewall/action.* files.
+ - Previously, when an interface name appeared in the DEST column of
+ /etc/shorewall/tcrules, the name was not validated against the set of
+ defined interfaces and bridge ports.
+
+
+New Features:
- - Previously, including a log level (and optionally a log
- tag) on a rule that specified a user-defined (or
- Shorewall-defined) action would log all traffic passed to the
- action. Beginning with this release, specifying a log level
- in a rule that specifies a user- or Shorewall-defined action
- will cause each rule in the action to be logged with the
- specified level (and tag).
-
- The extent to which logging of action rules occurs is
- goverend by the following:
+
+ - The SOURCE column in the /etc/shorewall/tcrules file now allows $FW to
+ be optionally followed by ":" and a host/network address or address
+ range.
+ - Shorewall now clears the output device only if it is a terminal. This
+ avoids ugly control sequences being placed in files when /sbin/shorewall
+ output is redirected.
+ - The output from 'arp -na' has been added to the 'shorewall status'
+ display.
+ - The 2.6.11 Linux kernel and iptables 1.3.0 now allow port ranges to
+ appear in port lists handled by "multiport match". If Shorewall detects
+ this capability, it will use "multiport match" for port lists containing
+ port ranges. Be cautioned that each port range counts for TWO ports and a
+ port list handled with "multiport match" can still specify a maximum of
+ 15 ports.
+
+ As always, if a port list in /etc/shorewall/rules is incompatible with
+ "multiport match", a separate iptables rule will be generated for each
+ element in the list.
+ - Traditionally, the RETURN target in the 'rfc1918' file has caused
+ 'norfc1918' processing to cease for a packet if the packet's source IP
+ address matches the rule. Thus, if you have:
+
+
+ SUBNETS
+ TARGET
+
+ 192.168.1.0/24 RETURN
+
+ then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though
+ you also have:
+
+
+ SUBNETS
+ TARGET
+
+ 10.0.0.0/8 logdrop
+
+ Setting RFC1918_STRICT=Yes in shorewall.conf will cause such traffic to
+ be logged and dropped since while the packet's source matches the RETURN
+ rule, the packet's destination matches the 'logdrop' rule.
+
+ If not specified or specified as empty (e.g., RFC1918_STRICT="") then
+ RFC1918_STRICT=No is assumed.
+
+ WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables
+ support 'Connection Tracking' match.
+
+
- -
-
- - When you invoke an action and specify a log level,
- only those rules in the action that have no log level
- will be changed to log at the level specified at the
- action invocation.
-
- Example:
-
- /etc/shorewall/action.foo:
-
- ACCEPT -
- - tcp 22
- bar:info
-
- /etc/shorewall/rules:
-
- foo:debug fw net
-
- Logging in the invoked 'foo' action will be:
-
- ACCEPT:debug -
- - tcp 22
- bar:info
-
-
+02/15/2005 Shorewall 2.2.1
+
+ This release rolls up the fixes for bugs found in the first 2-3 weeks
+of deployment of Shorewall 2.2.
+
+
+ - The /etc/shorewall/policy file contained a misleading comment and both
+ that file and the /etc/shorewall/zones file lacked examples.
+ - Shorewall previously used root's default umask which could cause files
+ in /var/lib/shorewall to be world-readable. Shorewall now uses umask
+ 0177.
+ - In log messages produced by logging a built-in action, the packet
+ disposition was displayed incorrectly.
+
+ Example:
+
+
+ rejNotSyn:ULOG all
+ all
+ tcp
+
+ produces the log message:
+
+ Feb 12
+ 23:57:08 server Shorewall:rejNotSyn:ULOG: ...
+
+ rather than
+
+ Feb 12
+ 23:57:08 server Shorewall:rejNotSyn:REJECT: ...
+
+
+ - The comments regarding built-in actions in
+ /usr/share/shorewall/actions.std have been corrected.
+ - The /etc/shorewall/policy file in the LRP package was missing the
+ 'all->all' policy.
+
+
+02/05/2005 End of Support for Shorewall
+1.4
+
+ Effective today, support for Shorewall 1.4 has been discontinued. See
+the link at the top of this article for upgrade information.
+
+02/01/2005 Shorewall 2.0.16
+
+This release back-ports the DROPINVALID shorewall.conf option from 2.2.0.
- - If you follow the log level with "!" then logging
- will be at that level for all rules recursively invoked
- by the action
-
- Example: /etc/shorewall/action.foo:
-
- Update: I've been informed by Mandrake
- Development that this problem has been corrected in
- Mandrake 10.0 Final (the problem still exists in the 10.0
- Community release).
- ACCEPT -
- - tcp 22
- bar:info
-
- /etc/shorewall/rules:
-
- foo:debug! fw
- net
-
- Logging in the invoke 'foo' action will be:
-
- ACCEPT:debug -
- - tcp 22
- bar:debug!
-
-
-
-
-
+
+ - Recent 2.6 kernels include code that evaluates TCP packets based on TCP
+ Window analysis. This can cause packets that were previously classified
+ as NEW or ESTABLISHED to be classified as INVALID.
+
+ The new kernel code can be disabled by including this command in your
+ /etc/shorewall/init file:
+
+ echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
+
+ Additional kernel logging about INVALID TCP packets may be obtained by
+ adding this command to /etc/shorewall/init:
+
+ echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
+
+ Traditionally, Shorewall has dropped INVALID TCP packets early. The new
+ DROPINVALID option allows INVALID packets to be passed through the normal
+ rules chains by setting DROPINVALID=No.
+
+ If not specified or if specified as empty (e.g., DROPINVALID="") then
+ DROPINVALID=Yes is assumed.
+
-
- This change has an effect on extension scripts used with
- user-defined actions. If you define an action 'acton' and you
- have an /etc/shorewall/acton script then when that script is
- invoked, the following three variables will be set for use by
- the script:
-
-
-
-
- $CHAIN = the name of the chain where your rules are to be
- placed. When logging is used on an action invocation,
- Shorewall creates a chain with a slightly different name
- from the action itself.
- $LEVEL = Log level. If empty, no logging was
- specified.
- $TAG = Log Tag.
+
02/01/2005 Shorewall 2.2.0
+
+ New Features:
+
+
+ - ICMP packets that are in the INVALID state are now dropped by the
+ Reject and Drop default actions. They do so using the new 'dropInvalid'
+ builtin action. An 'allowInvalid' builtin action is also provided which
+ accepts packets in that state.
+ - The /etc/shorewall/masq file INTERFACE column now allows additional
+ options.
+
+ Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules
+ defined in the /etc/shorewall/nat file. If you preceed the interface name
+ with a plus sign ("+") then the rule will be evaluated before one-to-one
+ NAT.
+
+ Examples:
+
+ +eth0
+ +eth1:192.0.2.32/27
+
+ Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an entry by
+ following the interface name by ":" but no digit.
+
+ Examples:
+
+ eth0:
+ eth1::192.0.2.32/27
+ +eth3:
+
+
+ - Similar to 2), the /etc/shorewall/nat file INTERFACE column now allows
+ you to override the setting of ADD_IP_ALIASES=Yes by following the
+ interface name with ":" but no digit.
+ - All configuration files in the Shorewall distribution with the
+ exception of shorewall.conf are now empty. In particular, the
+ /etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos files
+ now have no active entries. Hopefully this will stop the questions on the
+ support and development lists regarding why the default entries are the
+ way they are.
+ - Previously, including a log level (and optionally a log tag) on a rule
+ that specified a user-defined (or Shorewall-defined) action would log all
+ traffic passed to the action. Beginning with this release, specifying a
+ log level in a rule that specifies a user- or Shorewall-defined action
+ will cause each rule in the action to be logged with the specified level
+ (and tag).
+
+ The extent to which logging of action rules occurs is goverend by the
+ following:
+
+ - When you invoke an action and specify a log level, only those rules
+ in the action that have no log level will be changed to log at the
+ level specified at the action invocation.
-
- Example:
-
- /etc/shorewall/rules:
-
- acton:info:test
-
- Your /etc/shorewall/acton file will be run with:
-
-
-
-
- $CHAIN="%acton1
- $LEVEL="info"
- $TAG="test"
-
-
-
-
-
- - The /etc/shorewall/startup_disabled file is no longer
- created when Shorewall is first installed. Rather, the
- variable STARTUP_ENABLED is set to 'No' in
- /etc/shorewall/shorewall.conf. In order to get Shorewall to
- start, that variable's value must be set to 'Yes'. This
- change accomplishes two things:
-
- -
-
- - It prevents Shorewall from being started prematurely
- by the user's initialization scripts.
-
- - It causes /etc/shorewall/shorewall.conf to be
- modified so that it won't be replaced by upgrades using
- RPM.
-
-
-
-
-
- - Support has been added for the 2.6 Kernel IPSEC
- implementation. To use this support, you must have installed
- the IPSEC policy match patch and the four IPSEC/Netfilter
- patches from Patch-0-Matic-ng. The policy match patch affects
- both your kernel and iptables. There are two ways to specify
- that IPSEC is to be used when communicating with a set of
- hosts; both methods involve the new /etc/shorewall/ipsec
- file:
-
- -
-
- - If encrypted communication is used with all hosts in
- a zone, then you can designate the zone as an "ipsec"
- zone by placing 'Yes" in the IPSEC ONLY column in
- /etc/shorewall/ipsec:
-
- #ZONE
- IPSEC OPTIONS
- ...
- #
- ONLY
- vpn
- Yes
-
- The hosts in the zone (if any) must be specified in
- /etc/shorewall/hosts but you do not need to specify the
- 'ipsec' option on the entries in that file (see below).
- Dynamic zones involving IPSEC must use that
- technique.
-
- Example:Under 2.4 Kernel FreeS/Wan:
-
- /etc/shorewall/zones:
-
- net
- Net The big bad Internet
- vpn
- VPN Remote Network
-
- /etc/shorewall/interfaces:
-
- net
- eth0 ...
- vpn
- ipsec0 ...
-
- Under 2.6 Kernel with this new support:
-
- /etc/shorewall/zones:
-
- net
- Net The big bad Internet
- vpn
- VPN Remote Network
-
- /etc/shorewall/interfaces:
-
- net
- eth0 ...
-
- /etc/shorewall/hosts:
-
- vpn
- eth0:0.0.0.0/0
-
- /etc/shorewall/ipsec
-
- vpn Yes
-
-
-
- -
- If only part of the hosts in a zone require encrypted
- communication, you may use of the new 'ipsec' option in
- /etc/shorewall/hosts to designate those hosts.
-
- Example:
-
- Under 2.4 Kernel FreeS/Wan:
-
- /etc/shorewall/zones:
-
-
-net Net The big bad Internet
-loc Local Extended local zone
-
- /etc/shorewall/interfaces:
-
- net
- eth0 ...
- loc
- eth1 ...
- loc
- ipsec0 ...
-
- Under 2.6 Kernel with this new support:
-
- /etc/shorewall/zones:
-
- net
- Net The big bad
- Internet
- vpn
- VPN Remote Network
-
- /etc/shorewall/interfaces:
-
- net
- eth0 ...
- loc
- eth1 ...
-
- /etc/shorewall/hosts:
-
- vpn
- eth0:0.0.0.0/0 ipsec,...
-
-
-
-
-
-
- Regardless of which technique you choose, you can specify
- additional SA options for the zone in the
- /etc/shorewall/ipsec entry.
-
- The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
- input-output, input and output characteristics of the
- security associations to be used to decrypt (input) or
- encrypt (output) traffic to/from the zone.
-
- The available options are:
-
-
-
-
- - reqid[!]=<number> where <number> is
- specified using setkey(8) using the 'unique:<number>'
- option for the SPD level.
-
- - spi[!]=<number> where <number> is the SPI
- of the SA. Since different SAs are used to encrypt and
- decrypt traffic, this option should only be listed in the
- IN OPTIONS and OUT OPTIONS columns.
-
- - proto[!]=ah|esp|ipcomp
-
- - mss=<number> (sets the MSS value in TCP SYN
- packets and is not related to policy matching)
-
- - mode[!]=transport|tunnel
-
- - tunnel-src[!]=<address>[/<mask>] (only
- available with mode=tunnel)
-
- - tunnel-dst[!]=<address>[/<mask>] (only
- available with mode=tunnel). Because tunnel source and
- destination are dependent on the direction of the traffic,
- these options should only appear in the IN OPTIONS and OUT
- OPTIONS columns.
-
- - strict (if specified, packets must match all
- policies; policies are delimited by 'next').
-
- - next (only available with
- strict)
-
-
- Examples:
-
- #ZONE IPSEC
- OPTIONS
-
- IN
- OUT
- #
- ONLY
-
- OPTIONS
- OPTIONS
- vpn
- Yes mode=tunnel,proto=esp
- spi=1000 spi=1001
- loc
- No reqid=44,mode=transport
-
- The /etc/shorewall/masq file has a new IPSEC column added.
- If you specify Yes or yes in that column then the unencrypted
- packets will have their source address changed. Otherwise,
- the unencrypted packets will not have their source addresses
- changed. This column may also contain a comma-separated list
- of the options specified above in which case only those
- packets that will be encrypted by an SA matching the given
- options will have their source address changed.
-
-
-
- - To improve interoperability, tunnels of type 'ipsec' no
- longer enforce the use of source port 500 for ISAKMP and
- OpenVPN tunnels no longer enforce use of the specified port
- as both the source and destination ports.
-
- - A new 'allowBcast' builtin action has been added -- it
- silently allows broadcasts and multicasts.
-
- - The -c option in /sbin/shorewall commands is now
- deprecated. The commands where -c was previously allowed now
- permit you to specify a configuration directory after the
- command:
-
- shorewall check [
- <configuration-directory> ]
- shorewall restart [
- <configuration-directory> ]
- shorewall start [
- <configuration-directory> ]
-
-
-
- - Normally, when SNAT or MASQUERADE is applied to a tcp or
- udp connection, Netfilter attempts to retain the source port
- number. If it has to change to port number to avoid
- <source address>,<source port> conflicts, it
- tries to do so within port ranges ( < 512, 512-1023, and
- > 1023). You may now specify an explicit range of source
- ports to be used by following the address or address range
- (if any) in the ADDRESS column with ":" and a port range in
- the format <low-port>-<high-port>. You must
- specify either "tcp" or "udp" in the PROTO column.
-
- Examples 1 -- MASQUERADE with tcp source ports
- 4000-5000:
-
-
- #INTERFACE SUBNET
- ADDRESS PROTO
-
- eth0 192.168.1.0/24
- :4000-5000 tcp
-
- Example 2 -- SNAT with udp source ports 7000-8000:
-
- #INTERFACE SUBNET
- ADDRESS
-
- PROTO
-
- eth0
- 10.0.0.0/8
- 192.0.2.44:7000-8000 udp
-
-
-
- - You may now account by user/group ID for outbound traffic
- from the firewall itself with entries in
- /etc/shorewall/accounting. Such accounting rules must be
- placed in the OUTPUT chain. See the comments at the top of
- /etc/shorewall/accounting for details.
-
- - Shorewall now verifies that your kernel and iptables have
- physdev match support if BRIDGING=Yes in shorewall.conf.
-
- - Beginning with this release, if your kernel and iptables
- have iprange match support (see the output from "shorewall
- check"), then with the exception of the /etc/shorewall/netmap
- file, anywhere that a network address may appear an IP
- address range of the form <low address>-<high
- address> may also appear.
-
- - Support has been added for the iptables CLASSIFY target.
- That target allows you to classify packets for traffic
- shaping directly rather than indirectly through fwmark.
- Simply enter the <major>:<minor> classification
- in the first column of /etc/shorewall/tcrules:
-
- Example:
-
- #MARK/
- SOURCE
- DEST
- PROTO PORT(S)
- #CLASSIFY
- 1:30
- -
- eth0
- tcp 25
-
- Note that when using this form of rule, it is acceptable to
- include the name of an interface in the DEST column.
-
- Marking using the CLASSIFY target always occurs in the
- POSTROUTING chain of the mangle table and is not affected by
- the setting of MARK_IN_FORWARD_CHAIN in shorewall.conf.
-
- - During "shorewall start", IP addresses to be added as a
- consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes
- are quietly deleted when /etc/shorewall/nat and
- /etc/shorewall/masq are processed then they are re-added
- later. This is done to help ensure that the addresses can be
- added with the specified labels but can have the undesirable
- side effect of causing routes to be quietly deleted. A new
- RETAIN_ALIASES option has been added to shorewall.conf; when
- this option is set to Yes, existing addresses will not be
- deleted. Regardless of the setting of RETAIN_ALIASES,
- addresses added during "shorewall start" are still deleted at
- a subsequent "shorewall stop" or "shorewall restart".
-
- - Users with a large black list (from
- /etc/shorewall/blacklist) may want to set the new
- DELAYBLACKLISTLOAD option in shorewall.conf. When
- DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections
- before loading the blacklist rules. While this may allow
- connections from blacklisted hosts to slip by during
- construction of the blacklist, it can substantially reduce
- the time that all new connections are disabled during
- "shorewall [re]start".
-
- - Using the default LOGFORMAT, chain names longer than 11
- characters (such as in user-defined actions) may result in
- log prefix truncation. A new shorewall.conf action
- LOGTAGONLY has been added to deal with this problem. When
- LOGTAGONLY=Yes, logging rules that specify a log tag will
- substitute the tag for the chain name in the log prefix.
-
- Example -- file
- /etc/shorewall/action.thisisaverylogactionname:
-
- Rule:
-
- DROP:info:ftp
- 0.0.0.0/0 0.0.0.0/0
- tcp 21
-
- Log prefix with LOGTAGONLY=No:
-
- Shorewall:thisisaverylongacti
-
-
- Log prefix with LOGTAGONLY=Yes:
-
- Shorewall:ftp:DROP
-
-
-
- - Shorewall now resets the 'accept_source_route' flag for
- all interfaces. If you wish to accept source routing on an
- interface, you must specify the new 'sourceroute' interface
- option in /etc/shorewall/interfaces.
-
- - The default Drop and Reject actions now invoke the new
- standard action 'AllowICMPs'. This new action accepts
- critical ICMP types:
-
- Type 3 code 4 (fragmentation needed)
- Type
- 11 (TTL exceeded)
-
-
-
- - Explicit control over the kernel's Martian logging is now
- provided using the new 'logmartians' interface option. If you
- include 'logmartians' in the interface option list then
- logging of Martian packets on will be enabled on the
- specified interface. If you wish to globally enable martian
- logging, you can set LOG_MARTIANS=Yes in shorewall.conf.
-
- - You may now cause Shorewall to use the '--set-mss' option
- of the TCPMSS target. In other words, you can cause Shorewall
- to set the MSS field of SYN packets passing through the
- firewall to the value you specify. This feature extends the
- existing CLAMPMSS option in /etc/shorewall/shorewall.conf by
- allowing that option to have a numeric value as well as the
- values "Yes" and "No".
-
- Example:
-
- CLAMPMSS=1400
-
-
-
- - Shorewall now includes support for the ipp2p match
- facility. This is a departure from my usual policy in that
- the ipp2p match facility is included in Patch-O-Matic-NG and
- is unlikely to ever be included in the kernel.org source
- tree. Questions about how to install the patch or how to
- build your kernel and/or iptables should not be posted on the
- Shorewall mailing lists.
-
- In the following files, the "PROTO" or "PROTOCOL" column may
- contain "ipp2p":
-
-
- /etc/shorewall/rules
-
- /etc/shorewall/tcrules
-
- /etc/shorewall/accounting
-
- When the PROTO or PROTOCOL column contains "ipp2p" then the
- DEST PORT(S) or PORT(S) column may contain a recognized ipp2p
- option; for a list of the options and their meaning, at a
- root prompt:
-
- iptables -m ipp2p --help
-
- You must not include the leading "--" on the option;
- Shorewall will supply those characters for you. If you do not
- include an option then "ipp2p" is assumed (Shorewall will
- generate "-m ipp2p --ipp2p").
-
- - Shorewall now has support for the CONNMARK target from
- iptables. See the /etc/shorewall/tcrules file for
- details.
-
- - A new debugging option LOGALLNEW has been added to
- shorewall.conf. When set to a log level, this option causes
- Shorewall to generaate a logging rule as the first rule in
- each builtin chain.
-
- - The table name is used as the chain
- name in the log prefix.
- - The chain name is used as the target in
- the log prefix.
-
- Example: Using the default LOGFORMAT, the log prefix for
- logging from the nat table's PREROUTING chain is:
-
- Shorewall:nat:PREROUTING
-
- IMPORTANT: There is no rate limiting on these logging rules
- so use LOGALLNEW at your own risk; it may cause high CPU and
- disk utilization and you may not be able to control your
- firewall after you enable this option.
-
- DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES
- WILL BE SENT TO ANOTHER SYSTEM.
-
-
-
- - The SUBNET column in /etc/shorewall/rfc1918 has been
- renamed SUBNETS and it is now possible to specify a list of
- addresses in that column.
-
- - The AllowNNTP action now also allows NNTP over SSL/TLS
- (NNTPS).
-
- - For consistency, the CLIENT PORT(S) column in the tcrules
- file has been renamed SOURCE PORT(S).
-
- - The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is
- now shown in the output of "shorewall status".
-
- - A new IPTABLES option has been added to shorewall.conf.
- IPTABLES can be used to designate the iptables executable to
- be used by Shorewall. If not specified, the iptables
- executable determined by the PATH setting is used.
-
- - You can now use the "shorewall show zones" command to
- display the current contents of the zones. This is
- particularly useful if you use dynamic zones
- (DYNAMIC_ZONES=Yes in shorewall.conf).
-
- Example:
-
- ursa:/etc/shorewall # shorewall
- show zones
-
- Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST
- 2004
-
-
- loc
-
- eth0:192.168.1.0/24
-
- eth1:1.2.3.4
-
- net
-
- eth0:0.0.0.0/0
-
- WiFi
-
- eth1:0.0.0.0/0
-
- sec
-
- eth1:0.0.0.0/0
-
-
- ursa:/etc/shorewall #
-
-
-
- - Variable expansion may now be used with the INCLUDE
- directive.
-
- Example:
-
- /etc/shorewall/params
-
- FILE=/etc/foo/bar
-
- Any other config
- file:
-
- INCLUDE $FILE
-
-
-
- - The output of "shorewall status" now includes the results
- of "ip -stat link ls". This helps diagnose performance
- problems caused by link errors.
-
- - Previously, when rate-limiting was specified in
- /etc/shorewall/policy (LIMIT:BURST column), any traffic which
- exceeded the specified rate was silently dropped. Now, if a
- log level is given in the entry (LEVEL column) then drops are
- logged at that level at a rate of 5/min with a burst of
- 5.
-
- - Recent 2.6 kernels include code that evaluates TCP
- packets based on TCP Window analysis. This can cause packets
- that were previously classified as NEW or ESTABLISHED to be
- classified as INVALID.
-
- The new kernel code can be disabled by including this
- command in your /etc/shorewall/init file:
-
- echo 1 >
- /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
-
-
- Additional kernel logging about INVALID TCP packets may be
- obtained by adding this command to /etc/shorewall/init:
-
- echo 1 >
- /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
-
-
- Traditionally, Shorewall has dropped INVALID TCP packets
- early. The new DROPINVALID option allows INVALID packets to
- be passed through the normal rules chains by setting
- DROPINVALID=No.
-
- If not specified or if specified as empty (e.g.,
- DROPINVALID="") then DROPINVALID=Yes is assumed.
-
-
-
- - The "shorewall add" and "shorewall delete" commands now
- accept a list of hosts to add or delete.
-
- Examples:
-
- shorewall add eth1:1.2.3.4
- eth1:2.3.4.5 z12
- shorewall
- delete eth1:1.2.3.4 eth1:2.3.4.5 z12
-
- The above commands may also be
- written:
-
- shorewall add eth1:1.2.3.4,2.3.4.5
- z12
- shorewall
- delete eth1:1.2.3.4,2.3.4.5 z12
-
-
-
- - TCP OpenVPN tunnels are now supported using the 'openvpn'
- tunnel type. OpenVPN entries in /etc/shorewall/tunnels have
- this format:
-
- openvpn[:{tcp|udp}][:<port>]
- <zone>
- <gateway>
-
- Examples:
-
- openvpn:tcp
- net
- 1.2.3.4 # TCP tunnel on port 1194
-
- openvpn:3344
- net 1.2.3.4 # UDP on port
- 3344
-
- openvpn:tcp:4455 net
- 1.2.3.4 # TCP on port 4455
-
-
-
- - A new 'ipsecvpn' script is included in the tarball and in
- the RPM. The RPM installs the file in the Documentation
- directory (/usr/share/doc/packages/shorewall-2.2.0-0RC1).
-
- This script is intended for use on Roadwarrior laptops for
- establishing an IPSEC SA to/from remote networks. The script
- has some limitations:
-
-
-
-
- - Only one instance of the script may be used at a
- time.
-
- - Only the first SPD accessed will be instantiated at the
- remote gateway. So while the script creates SPDs to/from
- the remote gateway and each network listed in the NETWORKS
- setting at the front of the script, only one of these may
- be used at a time.
-
-
- - The output of "shorewall status" now lists the loaded
- netfilter kernel modules.
-
- - The range of UDP ports opened by the AllowTrcrt action
- has been increased to 33434:33524.
-
- - The IANA has recently registered port 1194 for use by
- OpenVPN. In previous versions of Shorewall (and OpenVPN), the
- default port was 5000 but has been changed to 1194 to conform
- to the new OpenVPN default.
-
-
- 01/17/2005 - Shorewall
- 2.2.0 RC5
-
- Problems Corrected:
-
-
-
- - The AllowTrcrt action has been changed to allow up to 30
- hops (same as default for 'traceroute'). Previously, the
- action was documented as allowing 20 hops but actually only
- allowed for 6 hops.
-
-
- - Using some lightweight shells, valid entries in
- /etc/shorewall/ecn produce startup errors.
-
- New Features:
-
-
-
- - A new AllowInvalid standard built-in action has been
- added. This action accepts packets that are in the INVALID
- connection-tracking state.
-
- 01/16/2005 - New Shorewall Mirrors
-
- Thanks to Lorenzo Martignoni and Nick Slikey, there are
- now Shorewall mirrors in
- Milan Italy and in Austin Texas. Thanks Lorenzo and Nick!
-
- 01/12/2005 - Shorewall 2.0.15
-
- Problems Corrected:
-
-
-
- - The range of ports opened by the AllowTrcrt action has
- been expanded to 33434:33524 to allow for a maximum of 30
- hops.
-
- - Code mis-ported from 2.2.0 in release 2.0.14 caused the
- following error during "shorewall start" where SYN
- rate-limiting is present in /etc/shorewall/policy:
-
- Bad argument `DROP'
- Try `iptables -h' or
- 'iptables --help' for more information.
-
-
- 01/06/2005 - Shorewall 2.2.0 RC4
-
- New Features:
-
-
-
- - A listing of loaded iptables kernel modules is now
- included in the output of "shorewall status".
-
-
- Problems Corrected.
-
-
-
- - Several problems associated with processing the IPSEC
- colummn in /etc/shorewall/masq have been corrected.
-
-
- 01/03/2005 - Shorewall 2.0.14
-
- New Features:
-
-
-
- - Previously, when rate-limiting was specified in
- /etc/shorewall/policy (LIMIT:BURST column), any traffic which
- exceeded the specified rate was silently dropped. Now, if a
- log level is given in the entry (LEVEL column) then drops are
- logged at that level at a rate of 5/min with a burst of
- 5.
-
-
- Problems Corrected:
-
-
-
- - A typo in the /etc/shorewall/interfaces file has been
- fixed.
-
- - "bad variable" error messages occurring during "shorewall
- stop" and "shorewall clear" have been eliminated.
-
- - A misleading typo in /etc/shorewall/tunnels has been
- corrected. The TYPE column for an IPIP tunnel should contain
- "ipip" rather than "ip".
-
-
- 12/31/2004 - Mandrake-specific RPMs
- available
-
- Jack Coates has generously volunteered to provide
- Shorewall RPMs for use under Mandrake. You can download Jack's
- RPMs from http://www.monkeynoodle.org/tmp/
-
-
- 12/31/2004 - Redhat/Fedora-specific RPMs
- available
-
- Simon Matter has graciously volunteered to provide RPMs
- tailored for Redhat and Fedora. You can download Simon's RPMs
- from http://www.invoca.ch/pub/packages/shorewall/
-
-
- Thanks, Simon!
-
- 12/30/2004 - Shorewall 2.2.0 RC3
-
- Problems Corrected:
-
-
-
- - The following error message could appear during
- "shorewall stop" or "shorewall clear":
-
-
-
- local: lo:: bad variable name
-
-
-
- - The rate limiting example in /etc/shorewall/rules has
- been changed to use the RATE LIMIT column.
-
- - Entries in /etc/shorewall/masq with the INTERFACE column
- containing <ifname>:: (e.g., "eth0::") would generate a
- progress message but would not generate an iptables
- rule.
-
- - A misleading typo in /etc/shorewall/tunnels has been
- corrected.
-
-
-
-
-
-
- 12/24/2004 - Shorewall
- 2.2.0 RC2
-
- New Features:
-
-
-
- - By popular demand, the default port for Open VPN tunnels
- is now 1194 (the IANA-reserved port number for Open
- VPN).
-
- 12/19/2004 - Shorewall 2.2.0 RC1
-
- Problems Corrected:
-
-
-
- - The syntax of the add and delete command has been
- clarified in the help summary produced by
- /sbin/shorewall.
-
- New Features:
-
-
-
- -
- TCP OpenVPN tunnels are now supported using the 'openvpn'
- tunnel type. OpenVPN entries in /etc/shorewall/tunnels have
- this format:
+ Example:
-
- openvpn[:{tcp|udp}][:<port>]
- <zone>
- <gateway>
+ /etc/shorewall/action.foo:
- Examples:
+ ACCEPT - -
+ tcp 22
+ bar:info
+
+ /etc/shorewall/rules:
+
+ foo:debug fw net
+
+ Logging in the invoked 'foo' action will be:
+
+ ACCEPT:debug -
+ - tcp 22
+ bar:info
+
+
+ - If you follow the log level with "!" then logging will be at that
+ level for all rules recursively invoked by the action
+
+ Example: /etc/shorewall/action.foo:
+
+ Update: I've been informed by Mandrake Development that this
+ problem has been corrected in Mandrake 10.0 Final (the problem still
+ exists in the 10.0 Community release).
+ ACCEPT - -
+ tcp 22
+ bar:info
+
+ /etc/shorewall/rules:
+
+ foo:debug! fw net
+
+ Logging in the invoke 'foo' action will be:
+
+ ACCEPT:debug -
+ - tcp 22
+ bar:debug!
+
+
+
+
+
-
- openvpn:tcp net 1.2.3.4 # TCP tunnel on port 5000
+
+This change has an effect on extension scripts used with user-defined
+actions. If you define an action 'acton' and you have an /etc/shorewall/acton
+script then when that script is invoked, the following three variables will
+be set for use by the script:
+
+
+
+
+$CHAIN = the name of the chain where your rules are to be placed. When
+logging is used on an action invocation, Shorewall creates a chain with a
+slightly different name from the action itself.
+$LEVEL = Log level. If empty, no logging was specified.
+$TAG = Log Tag.
+
+
+Example:
+
+/etc/shorewall/rules:
+
+acton:info:test
+
+Your /etc/shorewall/acton file will be run with:
+
+
+
+
+$CHAIN="%acton1
+$LEVEL="info"
+$TAG="test"
+
+
+
+
+ - The /etc/shorewall/startup_disabled file is no longer created when
+ Shorewall is first installed. Rather, the variable STARTUP_ENABLED is set
+ to 'No' in /etc/shorewall/shorewall.conf. In order to get Shorewall to
+ start, that variable's value must be set to 'Yes'. This change
+ accomplishes two things:
+
+ - It prevents Shorewall from being started prematurely by the user's
+ initialization scripts.
+ - It causes /etc/shorewall/shorewall.conf to be modified so that it
+ won't be replaced by upgrades using RPM.
+
+
+
+ - Support has been added for the 2.6 Kernel IPSEC implementation. To use
+ this support, you must have installed the IPSEC policy match patch and
+ the four IPSEC/Netfilter patches from Patch-0-Matic-ng. The policy match
+ patch affects both your kernel and iptables. There are two ways to
+ specify that IPSEC is to be used when communicating with a set of hosts;
+ both methods involve the new /etc/shorewall/ipsec file:
+
+ - If encrypted communication is used with all hosts in a zone, then
+ you can designate the zone as an "ipsec" zone by placing 'Yes" in the
+ IPSEC ONLY column in /etc/shorewall/ipsec:
+
+ #ZONE
+ IPSEC OPTIONS ...
+ #
+ ONLY
+ vpn
+ Yes
+
+ The hosts in the zone (if any) must be specified in
+ /etc/shorewall/hosts but you do not need to specify the 'ipsec'
+ option on the entries in that file (see below). Dynamic zones
+ involving IPSEC must use that technique.
+
+ Example:Under 2.4 Kernel FreeS/Wan:
+
+ /etc/shorewall/zones:
+
+ net
+ Net The big bad Internet
+ vpn
+ VPN Remote Network
+
+ /etc/shorewall/interfaces:
+
+ net
+ eth0 ...
+ vpn
+ ipsec0 ...
+
+ Under 2.6 Kernel with this new support:
+
+ /etc/shorewall/zones:
+
+ net
+ Net The big bad Internet
+ vpn
+ VPN Remote Network
+
+ /etc/shorewall/interfaces:
+
+ net
+ eth0 ...
+
+ /etc/shorewall/hosts:
+
+ vpn
+ eth0:0.0.0.0/0
+
+ /etc/shorewall/ipsec
+
+ vpn Yes
+
+
+ - If only part of the hosts in a zone require encrypted
+ communication, you may use of the new 'ipsec' option in
+ /etc/shorewall/hosts to designate those hosts.
+
+ Example:
+
+ Under 2.4 Kernel FreeS/Wan:
+
+ /etc/shorewall/zones:
+
+ net Net The big bad Internet
+loc Local Extended local zone
+ /etc/shorewall/interfaces:
+
+ net
+ eth0 ...
+ loc
+ eth1 ...
+ loc
+ ipsec0 ...
+
+ Under 2.6 Kernel with this new support:
+
+ /etc/shorewall/zones:
+
+ net
+ Net The big bad
+ Internet
+ vpn
+ VPN Remote Network
+
+ /etc/shorewall/interfaces:
+
+ net
+ eth0 ...
+ loc
+ eth1 ...
+
+ /etc/shorewall/hosts:
+
+ vpn
+ eth0:0.0.0.0/0 ipsec,...
+
+
+
+
+Regardless of which technique you choose, you can specify additional SA
+options for the zone in the /etc/shorewall/ipsec entry.
+
+The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the input-output,
+input and output characteristics of the security associations to be used to
+decrypt (input) or encrypt (output) traffic to/from the zone.
+
+The available options are:
+
+
+
+
+ - reqid[!]=<number> where <number> is specified using
+ setkey(8) using the 'unique:<number>' option for the SPD level.
+ - spi[!]=<number> where <number> is the SPI of the SA. Since
+ different SAs are used to encrypt and decrypt traffic, this option should
+ only be listed in the IN OPTIONS and OUT OPTIONS columns.
+ - proto[!]=ah|esp|ipcomp
+ - mss=<number> (sets the MSS value in TCP SYN packets and is not
+ related to policy matching)
+ - mode[!]=transport|tunnel
+ - tunnel-src[!]=<address>[/<mask>] (only available with
+ mode=tunnel)
+ - tunnel-dst[!]=<address>[/<mask>] (only available with
+ mode=tunnel). Because tunnel source and destination are dependent on the
+ direction of the traffic, these options should only appear in the IN
+ OPTIONS and OUT OPTIONS columns.
+ - strict (if specified, packets must match all policies; policies
+ are delimited by 'next').
+ - next (only available with strict)
+
+
+Examples:
+
+#ZONE IPSEC
+OPTIONS
+ IN
+ OUT
+#
+ONLY
+
+OPTIONS OPTIONS
+vpn
+Yes mode=tunnel,proto=esp
+spi=1000 spi=1001
+loc
+No reqid=44,mode=transport
+
+The /etc/shorewall/masq file has a new IPSEC column added. If you specify Yes
+or yes in that column then the unencrypted packets will have their source
+address changed. Otherwise, the unencrypted packets will not have their
+source addresses changed. This column may also contain a comma-separated list
+of the options specified above in which case only those packets that will be
+encrypted by an SA matching the given options will have their source address
+changed.
+
+
+ - To improve interoperability, tunnels of type 'ipsec' no longer enforce
+ the use of source port 500 for ISAKMP and OpenVPN tunnels no longer
+ enforce use of the specified port as both the source and destination
+ ports.
+ - A new 'allowBcast' builtin action has been added -- it silently allows
+ broadcasts and multicasts.
+ - The -c option in /sbin/shorewall commands is now deprecated. The
+ commands where -c was previously allowed now permit you to specify a
+ configuration directory after the command:
+
+ shorewall check [
+ <configuration-directory> ]
+ shorewall restart [
+ <configuration-directory> ]
+ shorewall start [
+ <configuration-directory> ]
+
+
+ - Normally, when SNAT or MASQUERADE is applied to a tcp or udp
+ connection, Netfilter attempts to retain the source port number. If it
+ has to change to port number to avoid <source
+ address>,<source port> conflicts, it tries to do so within port
+ ranges ( < 512, 512-1023, and > 1023). You may now specify an
+ explicit range of source ports to be used by following the address or
+ address range (if any) in the ADDRESS column with ":" and a port range in
+ the format <low-port>-<high-port>. You must specify either
+ "tcp" or "udp" in the PROTO column.
+
+ Examples 1 -- MASQUERADE with tcp source ports 4000-5000:
+
+ #INTERFACE
+ SUBNET
+ ADDRESS PROTO
+
+ eth0 192.168.1.0/24
+ :4000-5000 tcp
+
+ Example 2 -- SNAT with udp source ports 7000-8000:
+
+ #INTERFACE
+ SUBNET
+ ADDRESS
+
+ PROTO
+
+ eth0
+ 10.0.0.0/8
+ 192.0.2.44:7000-8000 udp
+
+
+ - You may now account by user/group ID for outbound traffic from the
+ firewall itself with entries in /etc/shorewall/accounting. Such
+ accounting rules must be placed in the OUTPUT chain. See the comments at
+ the top of /etc/shorewall/accounting for details.
+ - Shorewall now verifies that your kernel and iptables have physdev match
+ support if BRIDGING=Yes in shorewall.conf.
+ - Beginning with this release, if your kernel and iptables have iprange
+ match support (see the output from "shorewall check"), then with the
+ exception of the /etc/shorewall/netmap file, anywhere that a network
+ address may appear an IP address range of the form <low
+ address>-<high address> may also appear.
+ - Support has been added for the iptables CLASSIFY target. That target
+ allows you to classify packets for traffic shaping directly rather than
+ indirectly through fwmark. Simply enter the <major>:<minor>
+ classification in the first column of /etc/shorewall/tcrules:
+
+ Example:
+
+ #MARK/
+ SOURCE
+ DEST PROTO
+ PORT(S)
+ #CLASSIFY
+ 1:30
+ -
+ eth0 tcp
+ 25
+
+ Note that when using this form of rule, it is acceptable to include the
+ name of an interface in the DEST column.
+
+ Marking using the CLASSIFY target always occurs in the POSTROUTING chain
+ of the mangle table and is not affected by the setting of
+ MARK_IN_FORWARD_CHAIN in shorewall.conf.
+ - During "shorewall start", IP addresses to be added as a consequence of
+ ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted when
+ /etc/shorewall/nat and /etc/shorewall/masq are processed then they are
+ re-added later. This is done to help ensure that the addresses can be
+ added with the specified labels but can have the undesirable side effect
+ of causing routes to be quietly deleted. A new RETAIN_ALIASES option has
+ been added to shorewall.conf; when this option is set to Yes, existing
+ addresses will not be deleted. Regardless of the setting of
+ RETAIN_ALIASES, addresses added during "shorewall start" are still
+ deleted at a subsequent "shorewall stop" or "shorewall restart".
+ - Users with a large black list (from /etc/shorewall/blacklist) may want
+ to set the new DELAYBLACKLISTLOAD option in shorewall.conf. When
+ DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before
+ loading the blacklist rules. While this may allow connections from
+ blacklisted hosts to slip by during construction of the blacklist, it can
+ substantially reduce the time that all new connections are disabled
+ during "shorewall [re]start".
+ - Using the default LOGFORMAT, chain names longer than 11 characters
+ (such as in user-defined actions) may result in log prefix truncation. A
+ new shorewall.conf action LOGTAGONLY has been added to deal with
+ this problem. When LOGTAGONLY=Yes, logging rules that specify a log tag
+ will substitute the tag for the chain name in the log prefix.
+
+ Example -- file /etc/shorewall/action.thisisaverylogactionname:
+
+ Rule:
+
+ DROP:info:ftp
+ 0.0.0.0/0 0.0.0.0/0
+ tcp 21
+
+ Log prefix with LOGTAGONLY=No:
+
+ Shorewall:thisisaverylongacti
+
+ Log prefix with LOGTAGONLY=Yes:
+
+ Shorewall:ftp:DROP
+
+
+ - Shorewall now resets the 'accept_source_route' flag for all interfaces.
+ If you wish to accept source routing on an interface, you must specify
+ the new 'sourceroute' interface option in /etc/shorewall/interfaces.
+ - The default Drop and Reject actions now invoke the new standard action
+ 'AllowICMPs'. This new action accepts critical ICMP types:
+
+ Type 3 code 4 (fragmentation needed)
+ Type 11 (TTL
+ exceeded)
+
+
+ - Explicit control over the kernel's Martian logging is now provided
+ using the new 'logmartians' interface option. If you include
+ 'logmartians' in the interface option list then logging of Martian
+ packets on will be enabled on the specified interface. If you wish to
+ globally enable martian logging, you can set LOG_MARTIANS=Yes in
+ shorewall.conf.
+ - You may now cause Shorewall to use the '--set-mss' option of the TCPMSS
+ target. In other words, you can cause Shorewall to set the MSS field of
+ SYN packets passing through the firewall to the value you specify. This
+ feature extends the existing CLAMPMSS option in
+ /etc/shorewall/shorewall.conf by allowing that option to have a numeric
+ value as well as the values "Yes" and "No".
+
+ Example:
+
+ CLAMPMSS=1400
+
+
+ - Shorewall now includes support for the ipp2p match facility. This is a
+ departure from my usual policy in that the ipp2p match facility is
+ included in Patch-O-Matic-NG and is unlikely to ever be included in the
+ kernel.org source tree. Questions about how to install the patch or how
+ to build your kernel and/or iptables should not be posted on the
+ Shorewall mailing lists.
+
+ In the following files, the "PROTO" or "PROTOCOL" column may contain
+ "ipp2p":
+
+ /etc/shorewall/rules
+ /etc/shorewall/tcrules
+ /etc/shorewall/accounting
+
+ When the PROTO or PROTOCOL column contains "ipp2p" then the DEST PORT(S)
+ or PORT(S) column may contain a recognized ipp2p option; for a list of
+ the options and their meaning, at a root prompt:
+
+ iptables -m ipp2p --help
+
+ You must not include the leading "--" on the option; Shorewall will
+ supply those characters for you. If you do not include an option then
+ "ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").
+ - Shorewall now has support for the CONNMARK target from iptables. See
+ the /etc/shorewall/tcrules file for details.
+ - A new debugging option LOGALLNEW has been added to shorewall.conf. When
+ set to a log level, this option causes Shorewall to generaate a logging
+ rule as the first rule in each builtin chain.
+
+ - The table name is used as the chain name in the log
+ prefix.
+ - The chain name is used as the target in the log
+ prefix.
+
+ Example: Using the default LOGFORMAT, the log prefix for logging from the
+ nat table's PREROUTING chain is:
+
+ Shorewall:nat:PREROUTING
+
+ IMPORTANT: There is no rate limiting on these logging rules so use
+ LOGALLNEW at your own risk; it may cause high CPU and disk utilization
+ and you may not be able to control your firewall after you enable this
+ option.
+
+ DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL BE SENT
+ TO ANOTHER SYSTEM.
+
+
+ - The SUBNET column in /etc/shorewall/rfc1918 has been renamed SUBNETS
+ and it is now possible to specify a list of addresses in that column.
+ - The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).
+ - For consistency, the CLIENT PORT(S) column in the tcrules file has been
+ renamed SOURCE PORT(S).
+ - The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now shown in
+ the output of "shorewall status".
+ - A new IPTABLES option has been added to shorewall.conf. IPTABLES can be
+ used to designate the iptables executable to be used by Shorewall. If not
+ specified, the iptables executable determined by the PATH setting is
+ used.
+ - You can now use the "shorewall show zones" command to display the
+ current contents of the zones. This is particularly useful if you use
+ dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).
+
+ Example:
+
+ ursa:/etc/shorewall # shorewall show
+ zones
+
+ Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST
+ 2004
+
+ loc
+
+ eth0:192.168.1.0/24
+
+ eth1:1.2.3.4
+
+ net
+
+ eth0:0.0.0.0/0
+ WiFi
+
+ eth1:0.0.0.0/0
+ sec
+
+ eth1:0.0.0.0/0
+
+
+ ursa:/etc/shorewall #
+
+
+ - Variable expansion may now be used with the INCLUDE directive.
+
+ Example:
+
+ /etc/shorewall/params
+
+ FILE=/etc/foo/bar
+
+ Any other config file:
+
+ INCLUDE $FILE
+
+
+ - The output of "shorewall status" now includes the results of "ip -stat
+ link ls". This helps diagnose performance problems caused by link
+ errors.
+ - Previously, when rate-limiting was specified in /etc/shorewall/policy
+ (LIMIT:BURST column), any traffic which exceeded the specified rate was
+ silently dropped. Now, if a log level is given in the entry (LEVEL
+ column) then drops are logged at that level at a rate of 5/min with a
+ burst of 5.
+ - Recent 2.6 kernels include code that evaluates TCP packets based on TCP
+ Window analysis. This can cause packets that were previously classified
+ as NEW or ESTABLISHED to be classified as INVALID.
+
+ The new kernel code can be disabled by including this command in your
+ /etc/shorewall/init file:
+
+ echo 1 >
+ /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
+
+ Additional kernel logging about INVALID TCP packets may be obtained by
+ adding this command to /etc/shorewall/init:
+
+ echo 1 >
+ /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
+
+ Traditionally, Shorewall has dropped INVALID TCP packets early. The new
+ DROPINVALID option allows INVALID packets to be passed through the normal
+ rules chains by setting DROPINVALID=No.
+
+ If not specified or if specified as empty (e.g., DROPINVALID="") then
+ DROPINVALID=Yes is assumed.
+
+
+ - The "shorewall add" and "shorewall delete" commands now accept a list
+ of hosts to add or delete.
+
+ Examples:
+
+ shorewall add
+ eth1:1.2.3.4 eth1:2.3.4.5 z12
+ shorewall delete
+ eth1:1.2.3.4 eth1:2.3.4.5 z12
+
+ The above commands may also be written:
+
+ shorewall add
+ eth1:1.2.3.4,2.3.4.5 z12
+ shorewall delete
+ eth1:1.2.3.4,2.3.4.5 z12
+
+
+ - TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel type.
+ OpenVPN entries in /etc/shorewall/tunnels have this format:
+
+ openvpn[:{tcp|udp}][:<port>]
+ <zone>
+ <gateway>
+
+ Examples:
+
+ openvpn:tcp
+ net 1.2.3.4
+ # TCP tunnel on port 1194
+
+ openvpn:3344 net
+ 1.2.3.4 # UDP on port 3344
+
+ openvpn:tcp:4455 net
+ 1.2.3.4 # TCP on port 4455
+
+
+ - A new 'ipsecvpn' script is included in the tarball and in the RPM. The
+ RPM installs the file in the Documentation directory
+ (/usr/share/doc/packages/shorewall-2.2.0-0RC1).
+
+ This script is intended for use on Roadwarrior laptops for establishing
+ an IPSEC SA to/from remote networks. The script has some limitations:
+
+
+
+
+ - Only one instance of the script may be used at a time.
+ - Only the first SPD accessed will be instantiated at the remote gateway.
+ So while the script creates SPDs to/from the remote gateway and each
+ network listed in the NETWORKS setting at the front of the script, only
+ one of these may be used at a time.
+
+
+ - The output of "shorewall status" now lists the loaded netfilter kernel
+ modules.
+ - The range of UDP ports opened by the AllowTrcrt action has been
+ increased to 33434:33524.
+ - The IANA has recently registered port 1194 for use by OpenVPN. In
+ previous versions of Shorewall (and OpenVPN), the default port was 5000
+ but has been changed to 1194 to conform to the new OpenVPN default.
+
+
+01/17/2005 - Shorewall 2.2.0 RC5
+
+ Problems Corrected:
+
+
+ - The AllowTrcrt action has been changed to allow up to 30 hops (same as
+ default for 'traceroute'). Previously, the action was documented as
+ allowing 20 hops but actually only allowed for 6 hops.
+
+ - Using some lightweight shells, valid entries in /etc/shorewall/ecn
+ produce startup errors.
+
+New Features:
+
+
+ - A new AllowInvalid standard built-in action has been added. This action
+ accepts packets that are in the INVALID connection-tracking state.
+
+01/16/2005 - New
+Shorewall Mirrors
+
+ Thanks to Lorenzo Martignoni and Nick Slikey, there are now Shorewall
+mirrors in Milan Italy and in Austin
+Texas. Thanks Lorenzo and Nick!
+
+01/12/2005 - Shorewall 2.0.15
+
+Problems Corrected:
+
+
+ - The range of ports opened by the AllowTrcrt action has been expanded to
+ 33434:33524 to allow for a maximum of 30 hops.
+ - Code mis-ported from 2.2.0 in release 2.0.14 caused the following error
+ during "shorewall start" where SYN rate-limiting is present in
+ /etc/shorewall/policy:
+
+ Bad argument `DROP'
+ Try `iptables -h' or 'iptables --help' for
+ more information.
+
+
+01/06/2005 -
+Shorewall 2.2.0 RC4
+
+New Features:
+
+
+ - A listing of loaded iptables kernel modules is now included in the
+ output of "shorewall status".
+
+
+Problems Corrected.
+
+
+ - Several problems associated with processing the IPSEC colummn in
+ /etc/shorewall/masq have been corrected.
+
+
+01/03/2005 - Shorewall
+2.0.14
+
+New Features:
+
+
+ - Previously, when rate-limiting was specified in /etc/shorewall/policy
+ (LIMIT:BURST column), any traffic which exceeded the specified rate was
+ silently dropped. Now, if a log level is given in the entry (LEVEL
+ column) then drops are logged at that level at a rate of 5/min with a
+ burst of 5.
+
+
+Problems Corrected:
+
+
+ - A typo in the /etc/shorewall/interfaces file has been fixed.
+ - "bad variable" error messages occurring during "shorewall stop" and
+ "shorewall clear" have been eliminated.
+ - A misleading typo in /etc/shorewall/tunnels has been corrected. The
+ TYPE column for an IPIP tunnel should contain "ipip" rather than "ip".
+
+
+12/31/2004 -
+Mandrake-specific RPMs available
+
+ Jack Coates has generously volunteered to provide Shorewall RPMs for
+use under Mandrake. You can download Jack's RPMs from http://www.monkeynoodle.org/tmp/
+
+12/31/2004 -
+Redhat/Fedora-specific RPMs available
+
+Simon Matter has graciously volunteered to provide RPMs tailored for Redhat
+and Fedora. You can download Simon's RPMs from http://www.invoca.ch/pub/packages/shorewall/
+
+Thanks, Simon!
+
+12/30/2004 -
+Shorewall 2.2.0 RC3
+
+Problems Corrected:
+
+
+ - The following error message could appear during "shorewall stop" or
+ "shorewall clear":
+
+
+ local: lo:: bad variable name
+
+
+ - The rate limiting example in /etc/shorewall/rules has been changed to
+ use the RATE LIMIT column.
+ - Entries in /etc/shorewall/masq with the INTERFACE column containing
+ <ifname>:: (e.g., "eth0::") would generate a progress message but
+ would not generate an iptables rule.
+ - A misleading typo in /etc/shorewall/tunnels has been corrected.
+
+
+
+
+
+
+12/24/2004 - Shorewall 2.2.0 RC2
+
+ New Features:
+
+
+ - By popular demand, the default port for Open VPN tunnels is now 1194
+ (the IANA-reserved port number for Open VPN).
+
+12/19/2004 -
+Shorewall 2.2.0 RC1
+
+ Problems Corrected:
+
+
+ - The syntax of the add and delete command has been clarified in the help
+ summary produced by /sbin/shorewall.
+
+New Features:
+
+
+ - TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel type.
+ OpenVPN entries in /etc/shorewall/tunnels have this format:
+
+ openvpn[:{tcp|udp}][:<port>]
+ <zone> <gateway>
+
+ Examples:
+
+ openvpn:tcp net 1.2.3.4 # TCP tunnel on port 5000
openvpn:3344 net 1.2.3.4 # UDP on port 3344
- openvpn:tcp:4455 net 1.2.3.4 # TCP on port 4455
-
-
-
- - A new 'ipsecvpn' script is included in the tarball and in
- the RPM. The RPM installs the file in the Documentation
- directory (/usr/share/doc/packages/shorewall-2.2.0-0RC1).
-
- This script is intended for use on Roadwarrior laptops for
- establishing an IPSEC SA to/from remote networks. The script
- has some limitations:
-
- - Only one instance of the script may be
- used at a time.
- - Only the first SPD accessed will be
- instantiated at the remote gateway. So while the script
- creates SPDs to/from the remote gateway and each network
- listed in the NETWORKS setting at the front of the script,
- only one of these may be used at a time.
-
-
- 12/11/2004 - Shorewall 2.2.0 Beta 8
+ openvpn:tcp:4455 net 1.2.3.4 # TCP on port 4455
+
+ A new 'ipsecvpn' script is included in the tarball and in the RPM. The
+ RPM installs the file in the Documentation directory
+ (/usr/share/doc/packages/shorewall-2.2.0-0RC1).
- Problems Corrected:
-
-
-
- - A typo in the /etc/shorewall/interfaces file has been
- corrected.
-
- - Previously, the "add" and "delete" commands were
- generating incorrect policy matches when policy match support
- was available.
-
- New Features:
-
-
-
- - Recent 2.6 kernels include code that evaluates TCP
- packets based on TCP Window analysis. This can cause packets
- that were previously classified as NEW or ESTABLISHED to be
- classified as INVALID.
-
- The new kernel code can be disabled by including this
- command in your /etc/shorewall/init file:
-
- echo 1 >
- /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
-
- Additional kernel logging about INVALID TCP packets may be
- obtained by adding this command to /etc/shorewall/init:
-
- echo 1 >
- /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
-
- Traditionally, Shorewall has dropped INVALID TCP packets
- early. The new DROPINVALID option allows INVALID packets to
- be passed through the normal rules chains by setting
- DROPINVALID=No.
-
- If not specified or if specified as empty (e.g.,
- DROPINVALID="") then DROPINVALID=Yes is assumed.
-
-
-
- - The "shorewall add" and "shorewall delete" commands now
- accept a list of hosts to add or delete.
-
- Examples:
-
- shorewall add eth1:1.2.3.4 eth1:2.3.4.5
- z12
- shorewall delete eth1:1.2.3.4
- eth1:2.3.4.5 z12
-
- The above commands may also be written:
-
- shorewall add eth1:1.2.3.4,2.3.4.5
- z12
- shorewall delete eth1:1.2.3.4,2.3.4.5
- z12
-
-
-
- 12/04/2004 - Shorewall 2.2.0 Beta 7
-
- Problems Corrected:
-
-
-
- - The "shorewall add" and "shorewall delete" commands now
- work in a bridged environment. The syntax is:
-
-
- shorewall add
- <interface>[:<port>]:<address>
- <zone>
-
- shorewall delete
- <interface>[:<port>]:<address>
- <zone>
-
- Examples:
-
-
- shorewall add br0:eth2:192.168.1.3 OK
-
- shorewall delete br0:eth2:192.168.1.3 OK
-
-
-
- - Previously, "shorewall save" created an out-of-sequence
- restore script. The commands saved in the user's
- /etc/shorewall/start script were executed prior to the
- Netfilter configuration being restored. This has been
- corrected so that "shorewall save" now places those commands
- at the end of the script.
-
- To accomplish this change, the "restore base" file
- (/var/lib/shorewall/restore-base) has been split into two
- files:
-
- /var/lib/shorewall/restore-base -- commands to be executed
- before Netfilter the configuration is restored.
-
- /var/lib/shorewall/restore-tail -- commands to be executed
- after the Netfilter configuration is restored.
-
-
-
- - Previously, traffic from the firewall to a dynamic zone
- member host did not need to match the interface specified
- when the host was added to the zone. For example, if
- eth0:1.2.3.4 is added to dynamic zone Z then traffic out of
- any firewall interface to 1.2.3.4 will obey the fw->Z
- policies and rules. This has been corrected.
-
- - Shorewall uses the temporary chain 'fooX1234' to probe
- iptables for detrmining which features are supported.
- Previously, if that chain happened to exist when Shorewall
- was run, capabilities were mis-detected.
-
- New Features:
-
-
-
- - You can now use the "shorewall show zones" command to
- display the current contents of the zones. This is
- particularly useful if you use dynamic zones
- (DYNAMIC_ZONES=Yes in shorewall.conf).
-
- Example:
-
-
- ursa:/etc/shorewall # shorewall show zones
-
- Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST
- 2004
-
- loc
-
- eth0:192.168.1.0/24
-
- eth1:1.2.3.4
- net
-
- eth0:0.0.0.0/0
- WiFi
-
- eth1:0.0.0.0/0
- sec
-
- eth1:0.0.0.0/0
-
-
- ursa:/etc/shorewall #
-
-
-
- - Variable expansion may now be used with the INCLUDE
- directive.
-
- Example:
-
-
- /etc/shorewall/params
-
-
- FILE=/etc/foo/bar
-
- Any other config
- file:
-
-
- INCLUDE $FILE
-
-
-
- - The output of "shorewall status" now includes the results
- of "ip -stat link ls". This helps diagnose performance
- problems caused by link errors.
-
- - Previously, when rate-limiting was specified in
- /etc/shorewall/policy (LIMIT:BURST column), any traffic which
- exceeded the specified rate was silently dropped. Now, if a
- log
- level is given in the entry (LEVEL column) then drops are
- logged at that level at a rate of 5/min with a burst of
- 5.
-
-
- 12/02/2004 - Shorewall 2.0.13
+ This script is intended for use on Roadwarrior laptops for establishing
+ an IPSEC SA to/from remote networks. The script has some limitations:
- Problems Corrected:
+ - Only one instance of the script may be used at a
+ time.
+ - Only the first SPD accessed will be instantiated at
+ the remote gateway. So while the script creates SPDs to/from the remote
+ gateway and each network listed in the NETWORKS setting at the front of
+ the script, only one of these may be used at a time.
+
+
+12/11/2004 -
+Shorewall 2.2.0 Beta 8
+
+ Problems Corrected:
+
+ - A typo in the /etc/shorewall/interfaces file has been corrected.
+ - Previously, the "add" and "delete" commands were generating incorrect
+ policy matches when policy match support was available.
+
+New Features:
-
- -
- A typo in /usr/share/shorewall/firewall caused the
- "shorewall add" to issue an error message:
-
-
-/usr/share/shorewall/firewall: line 1: match_destination_hosts: command not found
-
-
-
- 12/01/2004 - Shorewall 2.0.12
-
- Problems Corrected:
-
-
-
- - A typo in shorewall.conf (NETNOTSYN) has been
- corrected.
-
- - The "shorewall add" and "shorewall delete" commands now
- work in a bridged environment. The syntax is:
-
- shorewall add
- <interface>[:<bridge port>][:<address>]
- <zone>
- shorewall delete
- <interface>[:<bridge port>][:<address>]
- <zone>
-
- Examples:
-
- shorewall add
- br0:eth2:192.168.1.3 OK
- shorewall delete
- br0:eth2:192.168.1.3 OK
-
-
-
- - Previously, "shorewall save" created an out-of-sequence
- restore script. The commands saved in the user's
- /etc/shorewall/start script were executed prior to the
- Netfilter configuration being restored. This has been
- corrected so that "shorewall save" now places those commands
- at the end of the script.
-
- To accomplish this change, the "restore base" file
- (/var/lib/shorewall/restore-base) has been split into two
- files:
-
- /var/lib/shorewall/restore-base -- commands to
- be executed before the Netfilter configuration is
- restored.
-
- /var/lib/shorewall/restore-tail -- commands to
- be executed after the Netfilter configuration is
- restored.
-
-
-
- - Previously, traffic from the firewall to a dynamic zone
- member host did not need to match the interface specified
- when the host was added to the zone. For example, if
- eth0:1.2.3.4 is added to dynamic zone Z then traffic out of
- any firewall interface to 1.2.3.4 will obey the fw->Z
- policies and rules. This has been corrected.
-
- New Features:
-
-
-
- - Variable expansion may now be used with the INCLUDE
- directive.
-
- Example:
-
-
- /etc/shorewall/params
-
-
- FILE=/etc/foo/bar
-
- Any other config
- file:
-
-
- INCLUDE $FILE
-
-
- 11/26/2004 - Shorewall 2.2.0 Beta 6
+
+ - Recent 2.6 kernels include code that evaluates TCP packets based on TCP
+ Window analysis. This can cause packets that were previously classified
+ as NEW or ESTABLISHED to be classified as INVALID.
-
Beta 5 was more or less DOA. Here's Beta 6.
-
- Problems Corrected:
+ The new kernel code can be disabled by including this command in your
+ /etc/shorewall/init file:
+
+ echo 1 >
+ /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
+
+ Additional kernel logging about INVALID TCP packets may be obtained by
+ adding this command to /etc/shorewall/init:
+
+ echo 1 >
+ /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
+
+ Traditionally, Shorewall has dropped INVALID TCP packets early. The new
+ DROPINVALID option allows INVALID packets to be passed through the normal
+ rules chains by setting DROPINVALID=No.
+
+ If not specified or if specified as empty (e.g., DROPINVALID="") then
+ DROPINVALID=Yes is assumed.
+
+
+ The "shorewall add" and "shorewall delete" commands now accept a list
+ of hosts to add or delete.
+
+ Examples:
+
+ shorewall add eth1:1.2.3.4 eth1:2.3.4.5 z12
+ shorewall delete eth1:1.2.3.4 eth1:2.3.4.5 z12
+
+ The above commands may also be written:
+
+ shorewall add eth1:1.2.3.4,2.3.4.5 z12
+ shorewall delete eth1:1.2.3.4,2.3.4.5 z12
+
+
+
+12/04/2004 -
+Shorewall 2.2.0 Beta 7
+
+Problems Corrected:
+
+ - The "shorewall add" and "shorewall delete" commands now work in a
+ bridged environment. The syntax is:
+
+ shorewall
+ add <interface>[:<port>]:<address> <zone>
+ shorewall
+ delete <interface>[:<port>]:<address> <zone>
+
+ Examples:
+
+ shorewall
+ add br0:eth2:192.168.1.3 OK
+ shorewall
+ delete br0:eth2:192.168.1.3 OK
+
+
+ - Previously, "shorewall save" created an out-of-sequence restore script.
+ The commands saved in the user's /etc/shorewall/start script were
+ executed prior to the Netfilter configuration being restored. This has
+ been corrected so that "shorewall save" now places those commands at the
+ end of the script.
+
+ To accomplish this change, the "restore base" file
+ (/var/lib/shorewall/restore-base) has been split into two files:
+
+ /var/lib/shorewall/restore-base -- commands to be executed before
+ Netfilter the configuration is restored.
+
+ /var/lib/shorewall/restore-tail -- commands to be executed after the
+ Netfilter configuration is restored.
+
+
+ - Previously, traffic from the firewall to a dynamic zone member host did
+ not need to match the interface specified when the host was added to the
+ zone. For example, if eth0:1.2.3.4 is added to dynamic zone Z then
+ traffic out of any firewall interface to 1.2.3.4 will obey the fw->Z
+ policies and rules. This has been corrected.
+ - Shorewall uses the temporary chain 'fooX1234' to probe iptables for
+ detrmining which features are supported. Previously, if that chain
+ happened to exist when Shorewall was run, capabilities were
+ mis-detected.
+
+New Features:
-
- - Fixed a number of problems associated with not having an
- IPTABLES value assigned in shorewall.conf
+
+ - You can now use the "shorewall show zones" command to display the
+ current contents of the zones. This is particularly useful if you use
+ dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).
+
+ Example:
+
+ ursa:/etc/shorewall #
+ shorewall show zones
+ Shorewall-2.2.0-Beta7 Zones at
+ ursa - Sat Nov 27 11:18:25 PST 2004
+
+ loc
+
+ eth0:192.168.1.0/24
+
+ eth1:1.2.3.4
+ net
+
+ eth0:0.0.0.0/0
+ WiFi
+
+ eth1:0.0.0.0/0
+ sec
+
+ eth1:0.0.0.0/0
+
+ ursa:/etc/shorewall #
+
+
+ - Variable expansion may now be used with the INCLUDE directive.
+
+ Example:
+
+ /etc/shorewall/params
+
+
+ FILE=/etc/foo/bar
+
+ Any other config file:
+
+
+ INCLUDE $FILE
+
+
+ - The output of "shorewall status" now includes the results of "ip -stat
+ link ls". This helps diagnose performance problems caused by link
+ errors.
+ - Previously, when rate-limiting was specified in /etc/shorewall/policy
+ (LIMIT:BURST column), any traffic which exceeded the specified rate was
+ silently dropped. Now, if a log
+ level is given in the entry (LEVEL column) then drops are logged at that
+ level at a rate of 5/min with a burst of 5.
+
+
+12/02/2004 - Shorewall
+2.0.13
+
+ Problems Corrected:
- - Corrected a 'duplicate chain' error on "shorewall add"
- when the 'mss' option is present in /etc/shorewall/ipsec.
-
-
- 11/26/2004 - Shorewall 2.2.0 Beta 5
-
- Problems corrected:
+
+ - A typo in /usr/share/shorewall/firewall caused the "shorewall add" to
+ issue an error message:
+ /usr/share/shorewall/firewall: line 1: match_destination_hosts: command not found
+
+
+12/01/2004 - Shorewall
+2.0.12
+
+Problems Corrected:
-
- - A typo in shorewall.conf (NETNOTSYN) has been
- corrected.
-
- New Features:
+
+ - A typo in shorewall.conf (NETNOTSYN) has been corrected.
+ - The "shorewall add" and "shorewall delete" commands now work in a
+ bridged environment. The syntax is:
+
+ shorewall add
+ <interface>[:<bridge port>][:<address>] <zone>
+ shorewall delete
+ <interface>[:<bridge port>][:<address>] <zone>
+
+ Examples:
+
+ shorewall add br0:eth2:192.168.1.3 OK
+ shorewall delete br0:eth2:192.168.1.3
+ OK
+
+
+ - Previously, "shorewall save" created an out-of-sequence restore script.
+ The commands saved in the user's /etc/shorewall/start script were
+ executed prior to the Netfilter configuration being restored. This has
+ been corrected so that "shorewall save" now places those commands at the
+ end of the script.
+
+ To accomplish this change, the "restore base" file
+ (/var/lib/shorewall/restore-base) has been split into two files:
+
+ /var/lib/shorewall/restore-base -- commands to be executed
+ before the Netfilter configuration is restored.
+
+ /var/lib/shorewall/restore-tail -- commands to be executed
+ after the Netfilter configuration is restored.
+
+
+ - Previously, traffic from the firewall to a dynamic zone member host did
+ not need to match the interface specified when the host was added to the
+ zone. For example, if eth0:1.2.3.4 is added to dynamic zone Z then
+ traffic out of any firewall interface to 1.2.3.4 will obey the fw->Z
+ policies and rules. This has been corrected.
+
+New Features:
+
+ - Variable expansion may now be used with the INCLUDE directive.
+
+ Example:
+
+ /etc/shorewall/params
+
+
+ FILE=/etc/foo/bar
+
+ Any other config file:
+
+
+ INCLUDE $FILE
+
+
+11/26/2004 -
+Shorewall 2.2.0 Beta 6
+
+ Beta 5 was more or less DOA. Here's Beta 6.
+
+Problems Corrected:
-
- - For consistency, the CLIENT PORT(S) column in the tcrules
- file has been renamed SOURCE PORT(S).
+
+ - Fixed a number of problems associated with not having an IPTABLES value
+ assigned in shorewall.conf
+ - Corrected a 'duplicate chain' error on "shorewall add" when the 'mss'
+ option is present in /etc/shorewall/ipsec.
+
+
+11/26/2004 -
+Shorewall 2.2.0 Beta 5
+
+Problems corrected:
- - The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is
- now shown in the output of "shorewall status".
+
+ - A typo in shorewall.conf (NETNOTSYN) has been corrected.
+
+New Features:
- - A new IPTABLES option has been added to shorewall.conf.
- IPTABLES can be used to designate the iptables executable to
- be used by Shorewall. If not specified, the iptables
- executable determined by the PATH setting is used.
-
-
- 11/23/2004 - Shorewall 2.0.11
-
- Problems corrected:
+
+ - For consistency, the CLIENT PORT(S) column in the tcrules file has been
+ renamed SOURCE PORT(S).
+ - The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now shown in
+ the output of "shorewall status".
+ - A new IPTABLES option has been added to shorewall.conf. IPTABLES can be
+ used to designate the iptables executable to be used by Shorewall. If not
+ specified, the iptables executable determined by the PATH setting is
+ used.
+
+
+11/23/2004 - Shorewall
+2.0.11
+
+Problems corrected:
+
+ - The INSTALL file now include special instructions for Slackware
+ users.
+ - The bogons file has been updated.
+ - Service names are replaced by port numbers in /etc/shorewall/tos.
+ - A typo in the install.sh file that caused an error during a new install
+ has been corrected.
+
+New Features:
-
- - The INSTALL file now include special instructions for
- Slackware users.
+
+ - The AllowNNTP action now allows NNTP over SSL/TLS (NTTPS).
+
+
+11/19/2004 -
+Shorewall 2.2.0 Beta 4
+
+Problems Corrected:
- - The bogons file has been updated.
+
+ - A cut and paste error resulted in some nonsense in the description of
+ the IPSEC column in /etc/shorewall/masq.
+ - A typo in /etc/shorewall/rules has been corrected.
+ - The bogons file has been updated.
+ - The "shorewall add" command previously reported success but did nothing
+ -- now it works.
+
+New Features:
- - Service names are replaced by port numbers in
- /etc/shorewall/tos.
+
+ - The AllowNNTP action now allows NNTP over SSL/TLS (NNTPS).
+
+
+11/09/2004 -
+Shorewall 2.2.0 Beta 3
+
+Problems Corrected:
- - A typo in the install.sh file that caused an error during
- a new install has been corrected.
-
- New Features:
+
+ - Missing '#' in the rfc1918 file has been corrected.
+ - The INSTALL file now includes special instructions for Slackware
+ users.
+
+New Features:
+
+ - In CLASSIFY rules (/etc/shorewall/tcrules), an interface name may now
+ appear in the DEST column as in:
-
- - The AllowNNTP action now allows NNTP over SSL/TLS
- (NTTPS).
-
-
- 11/19/2004 - Shorewall 2.2.0 Beta 4
-
- Problems Corrected:
-
-
-
- - A cut and paste error resulted in some nonsense in the
- description of the IPSEC column in /etc/shorewall/masq.
-
- - A typo in /etc/shorewall/rules has been corrected.
-
- - The bogons file has been updated.
-
- - The "shorewall add" command previously reported success
- but did nothing -- now it works.
-
- New Features:
-
-
-
- - The AllowNNTP action now allows NNTP over SSL/TLS
- (NNTPS).
-
-
- 11/09/2004 - Shorewall 2.2.0 Beta 3
-
- Problems Corrected:
-
-
-
- - Missing '#' in the rfc1918 file has been corrected.
-
- - The INSTALL file now includes special instructions for
- Slackware users.
-
- New Features:
-
-
-
- -
- In CLASSIFY rules (/etc/shorewall/tcrules), an interface
- name may now appear in the DEST column as in:
-
-
- #MARK/ SOURCE DEST PROTO PORT(S)
+ #MARK/ SOURCE DEST PROTO PORT(S)
#CLASSIFY
- 1:30 - eth0 tcp 25
-
-
-
- 11/02/2004 - Shorewall 2.2.0 Beta 2
+ 1:30 - eth0 tcp 25
+
+
+11/02/2004 -
+Shorewall 2.2.0 Beta 2
+
+ Problems Corrected:
+
+
+ - The "shorewall check" command results in the (harmless) error
+ message:
+
+ /usr/share/shorewall/firewall:
+ line 2753:
+
+ check_dupliate_zones: command not found
- Problems Corrected:
+
+ - The AllowNTP standard action now allows outgoing responses to
+ broadcasts.
+ - A clarification has been added to the hosts file's description of the
+ 'ipsec' option pointing out that the option is redundent if the zone
+ named in the ZONE column has been designated an IPSEC zone in the
+ /etc/shorewall/ipsec file.
+
+New Features:
+
+ - The SUBNET column in /etc/shorewall/rfc1918 has been renamed SUBNETS
+ and it is now possible to specify a list of addresses in that column.
+
+
+10/25/2004 - Shorewall
+2.0.10
+
+Problems Corrected:
-
- - The "shorewall check" command results in the (harmless)
- error message:
-
-
- /usr/share/shorewall/firewall: line 2753:
-
- check_dupliate_zones: command not found
-
-
+
+ - The GATEWAY column was previously ignored in 'pptpserver' entries in
+ /etc/shorewall/tunnels.
+ - When log rule numbers are included in the LOGFORMAT, duplicate rule
+ numbers could previously be generated.
+ - The /etc/shorewall/tcrules file now includes a note to the effect that
+ rule evaluation continues after a match.
+ - The error message produced if Shorewall couldn't obtain the routes
+ through an interface named in the SUBNET column of /etc/shorewall/masq
+ was less than helpful since it didn't include the interface name.
+
+
+New Features:
- - The AllowNTP standard action now allows outgoing
- responses to broadcasts.
-
- - A clarification has been added to the hosts file's
- description of the 'ipsec' option pointing out that the
- option is redundent if the zone named in the ZONE column has
- been designated an IPSEC zone in the /etc/shorewall/ipsec
- file.
-
- New Features:
-
-
-
- - The SUBNET column in /etc/shorewall/rfc1918 has been
- renamed SUBNETS and it is now possible to specify a list of
- addresses in that column.
-
-
- 10/25/2004 - Shorewall 2.0.10
-
- Problems Corrected:
-
-
-
- - The GATEWAY column was previously ignored in 'pptpserver'
- entries in /etc/shorewall/tunnels.
-
- - When log rule numbers are included in the LOGFORMAT,
- duplicate rule numbers could previously be generated.
-
- - The /etc/shorewall/tcrules file now includes a note to
- the effect that rule evaluation continues after a match.
-
- - The error message produced if Shorewall couldn't obtain
- the routes through an interface named in the SUBNET column of
- /etc/shorewall/masq was less than helpful since it didn't
- include the interface name.
-
-
- New Features:
-
-
-
- - The "shorewall status" command has been enhanced to
- include the values of key /proc settings:
-
- Example from a two-interface firewall:
-
- /proc
-
- /proc/sys/net/ipv4/ip_forward = 1
- /proc/sys/net/ipv4/conf/all/proxy_arp = 0
- /proc/sys/net/ipv4/conf/all/arp_filter = 0
- /proc/sys/net/ipv4/conf/all/rp_filter = 0
- /proc/sys/net/ipv4/conf/default/proxy_arp =
- 0
- /proc/sys/net/ipv4/conf/default/arp_filter =
- 0
- /proc/sys/net/ipv4/conf/default/rp_filter =
- 0
- /proc/sys/net/ipv4/conf/eth0/proxy_arp = 0
- /proc/sys/net/ipv4/conf/eth0/arp_filter = 0
- /proc/sys/net/ipv4/conf/eth0/rp_filter = 0
- /proc/sys/net/ipv4/conf/eth1/proxy_arp = 0
- /proc/sys/net/ipv4/conf/eth1/arp_filter = 0
- /proc/sys/net/ipv4/conf/eth1/rp_filter = 0
- /proc/sys/net/ipv4/conf/lo/proxy_arp = 0
- /proc/sys/net/ipv4/conf/lo/arp_filter = 0
- /proc/sys/net/ipv4/conf/lo/rp_filter = 0
-
-
+
+ - The "shorewall status" command has been enhanced to include the values
+ of key /proc settings:
- 10/24/2004 - Shorewall 2.2.0 Beta1
+ Example from a two-interface firewall:
- The first beta in the 2.2 series is now available.
- Download location is:
-
-
-
-
-
- The features available in this release and the migration
- considerations are covered in the
- release notes. Highlights include:
-
-
-
- - The behavior produced by specifying a log level in an
- action invocation is now much more rational. Previously, all
- packets sent to the action were logged; now each rule within
- the invoked action behaves as if logging had been specified
- on it.
-
- - Support for the 2.6 Kernel's native IPSEC implementation
- is now available.
-
- - Support for ipp2p is included.
-
- - Support for the iptables CONNMARK facility is now
- included in Shorewall.
-
- - A new LOGALLNEW option facilitates problem analysis.
-
- - Users with a large static blacklist can now defer loading
- the blacklist until after the rest of the ruleset has been
- enabled. Doing so can decrease substantially the amount of
- time that connections are disabled during shorewall [re]start.
-
- - Support for the iptables 'iprange match' feature has been
- enabled. Users whose kernel and iptables contain this feature
- can use ip address ranges in most places in their Shorewall
- configuration where a CIDR netowrk can be used.
-
- - Accepting of source routing and martian logging may now
- be enabled/disabled on each interface.
-
- - Shorewall now supports the CLASSIFY iptable target.
-
-
- 9/23/2004 - Shorewall 2.0.9
-
- Problems Corrected:
-
-
-
- - Previously, an empty PROTO column or a value of "all" in
- that column would cause errors when processing the
- /etc/shorewall/tcrules file.
-
- New Features:
-
-
-
- - The "shorewall status" command now includes the output of
- "brctl show" if the bridge tools are installed.
-
-
-
- 9/20/2004 – Change in Shorewall
- Support
-
- Friends,
-
- The demands that my job and my personal life are
- currently placing on me are such that supporing Shorewall to
- the extent that I have been doing is just not possible any
- more.
-
- I will continue to be active on the development
- list and will continue to develop Shorewall if at all
- possible.
-
- I will also continue to read the user's list and
- will help with problems that interest me. But I am no longer
- going to hop on every problem as soon as I see it.
-
- This change means that I'm going to have to depend
- on you folks to help each other; I'm confident that we can make
- this work.
-
- 8/22/2004 - Shorewall 2.0.8
-
- Problems Corrected:
-
-
- -
-
Entries in the USER/GROUP column of an action file (made
- from action.template) may be ignored or cause odd
- errors.
-
-
-
- 7/29/2004 - Shorewall 2.0.7
+ /proc
- Problems Corrected:
+ /proc/sys/net/ipv4/ip_forward = 1
+ /proc/sys/net/ipv4/conf/all/proxy_arp = 0
+ /proc/sys/net/ipv4/conf/all/arp_filter = 0
+ /proc/sys/net/ipv4/conf/all/rp_filter = 0
+ /proc/sys/net/ipv4/conf/default/proxy_arp = 0
+ /proc/sys/net/ipv4/conf/default/arp_filter = 0
+ /proc/sys/net/ipv4/conf/default/rp_filter = 0
+ /proc/sys/net/ipv4/conf/eth0/proxy_arp = 0
+ /proc/sys/net/ipv4/conf/eth0/arp_filter = 0
+ /proc/sys/net/ipv4/conf/eth0/rp_filter = 0
+ /proc/sys/net/ipv4/conf/eth1/proxy_arp = 0
+ /proc/sys/net/ipv4/conf/eth1/arp_filter = 0
+ /proc/sys/net/ipv4/conf/eth1/rp_filter = 0
+ /proc/sys/net/ipv4/conf/lo/proxy_arp = 0
+ /proc/sys/net/ipv4/conf/lo/arp_filter = 0
+ /proc/sys/net/ipv4/conf/lo/rp_filter = 0
+
+
+
+10/24/2004 -
+Shorewall 2.2.0 Beta1
+
+ The first beta in the 2.2 series is now available. Download location
+is:
+
-
- -
-
The PKTTYPE option
- introduced in version 2.0.6 is now used when generating
- rules to REJECT packets. Broadcast packets are silently
- dropped rather than being rejected with an ICMP (which is a
- protocol violation) and users whose kernels have broken
- packet type match support are likely to see messages
- reporting this violation. Setting PKTTYPE=No should cause
- these messages to cease.
-
- -
-
Multiple interfaces with the
- 'blacklist' option no longer result in an error message at
- startup.
-
+
- -
-
The following has been added to
- /etc/shorewall/bogons:
-
- 0.0.0.0
- RETURN
-
- This prevents the 'nobogons' option from logging DHCP
- 'DISCOVER' broadcasts.
-
-
+The features available in this release and the migration considerations
+are covered in the release
+notes. Highlights include:
+
+
+ - The behavior produced by specifying a log level in an action invocation
+ is now much more rational. Previously, all packets sent to the action
+ were logged; now each rule within the invoked action behaves as if
+ logging had been specified on it.
+ - Support for the 2.6 Kernel's native IPSEC implementation is now
+ available.
+ - Support for ipp2p is included.
+ - Support for the iptables CONNMARK facility is now included in
+ Shorewall.
+ - A new LOGALLNEW option facilitates problem analysis.
+ - Users with a large static blacklist can now defer loading the blacklist
+ until after the rest of the ruleset has been enabled. Doing so can
+ decrease substantially the amount of time that connections are disabled
+ during shorewall [re]start.
+ - Support for the iptables 'iprange match' feature has been enabled.
+ Users whose kernel and iptables contain this feature can use ip address
+ ranges in most places in their Shorewall configuration where a CIDR
+ netowrk can be used.
+ - Accepting of source routing and martian logging may now be
+ enabled/disabled on each interface.
+ - Shorewall now supports the CLASSIFY iptable target.
+
- New Features:
+9/23/2004 - Shorewall
+2.0.9
+
+Problems Corrected:
+
+
+ - Previously, an empty PROTO column or a value of "all" in that column
+ would cause errors when processing the /etc/shorewall/tcrules file.
+
+New Features:
-
- -
-
To improve supportability, the "shorewall status"
- command now includes IP and Route configuration
- information.
-
- Example:
-
- IP
- Configuration
-
- 1: lo:
- <LOOPBACK,UP> mtu 16436 qdisc noqueue
- link/loopback 00:00:00:00:00:00 brd
- 00:00:00:00:00:00
- inet
- 127.0.0.1/8 brd 127.255.255.255 scope host lo
- inet6 ::1/128 scope host
- 2: eth0:
- <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
- pfifo_fast qlen 1000
- link/ether 00:a0:c9:15:39:78 brd
- ff:ff:ff:ff:ff:ff
- inet6 fe80::2a0:c9ff:fe15:3978/64 scope
- link
- 3: eth1:
- <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
- pfifo_fast qlen 1000
- link/ether 00:a0:c9:a7:d7:bf brd
- ff:ff:ff:ff:ff:ff
- inet6 fe80::2a0:c9ff:fea7:d7bf/64 scope
- link
- 5: sit0@NONE:
- <NOARP> mtu 1480 qdisc noop
- link/sit 0.0.0.0 brd 0.0.0.0
- 6: eth2:
- <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc
- pfifo_fast qlen 1000
- link/ether 00:40:d0:07:3a:1b brd
- ff:ff:ff:ff:ff:ff
- inet6 fe80::240:d0ff:fe07:3a1b/64 scope
- link
- 7: br0:
- <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc
- noqueue
- link/ether 00:40:d0:07:3a:1b brd
- ff:ff:ff:ff:ff:ff
- inet
- 192.168.1.3/24 brd 192.168.1.255 scope global
- br0
- inet6 fe80::240:d0ff:fe07:3a1b/64 scope
- link
-
- Routing
- Rules
-
- 0: from all
- lookup local
- 32765: from all
- fwmark ca lookup
- www.out
- 32766: from all
- lookup main
- 32767: from all
- lookup default
-
- Table
- local:
-
- broadcast 192.168.1.0
- dev br0 proto kernel scope link src
- 192.168.1.3
- broadcast
- 127.255.255.255 dev lo proto kernel scope
- link src 127.0.0.1
- local 192.168.1.3 dev
- br0 proto kernel scope host src
- 192.168.1.3
- broadcast
- 192.168.1.255 dev br0 proto kernel scope
- link src 192.168.1.3
- broadcast 127.0.0.0
- dev lo proto kernel scope link src
- 127.0.0.1
- local 127.0.0.1 dev
- lo proto kernel scope host src
- 127.0.0.1
- local 127.0.0.0/8 dev
- lo proto kernel scope host src
- 127.0.0.1
-
- Table
- www.out:
-
- default via
- 192.168.1.3 dev br0
-
- Table main:
-
- 192.168.1.0/24 dev
- br0 proto kernel scope link src
- 192.168.1.3
- default via
- 192.168.1.254 dev br0
-
- Table
- default:
-
-
+
+ - The "shorewall status" command now includes the output of "brctl show"
+ if the bridge tools are installed.
+
+
- 7/16/2004 - Shorewall 2.0.6
+
9/20/2004 – Change in
+Shorewall Support
+
+Friends,
+
+The demands that my job and my personal life are currently
+placing on me are such that supporing Shorewall to the extent that I have
+been doing is just not possible any more.
+
+I will continue to be active on the development list and will
+continue to develop Shorewall if at all possible.
+
+I will also continue to read the user's list and will help with
+problems that interest me. But I am no longer going to hop on every problem
+as soon as I see it.
+
+This change means that I'm going to have to depend on you folks
+to help each other; I'm confident that we can make this work.
+
+8/22/2004 - Shorewall 2.0.8
+
+Problems Corrected:
+
+ Entries in the USER/GROUP column of an action file (made from
+ action.template) may be ignored or cause odd errors.
+
+
+7/29/2004 - Shorewall 2.0.7
+
+ Problems Corrected:
+
+ The PKTTYPE option introduced in version
+ 2.0.6 is now used when generating rules to REJECT packets. Broadcast
+ packets are silently dropped rather than being rejected with an ICMP
+ (which is a protocol violation) and users whose kernels have broken
+ packet type match support are likely to see messages reporting this
+ violation. Setting PKTTYPE=No should cause these messages to cease.
+ Multiple interfaces with the 'blacklist'
+ option no longer result in an error message at startup.
+ The following has been added to /etc/shorewall/bogons:
- Problems Corrected:
+ 0.0.0.0 RETURN
+
+ This prevents the 'nobogons' option from logging DHCP 'DISCOVER'
+ broadcasts.
+
-
- -
-
Some users have reported the
- packet type match option in iptables/Netfilter failing to
- match certain broadcast packets. The result is that the
- firewall log shows a lot of broadcast packets.
+
New Features:
+
+ To improve supportability, the "shorewall status" command now
+ includes IP and Route configuration information.
+
+ Example:
+
+ IP Configuration
+
+ 1: lo: <LOOPBACK,UP> mtu 16436
+ qdisc noqueue
+ link/loopback
+ 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ inet 127.0.0.1/8
+ brd 127.255.255.255 scope host lo
+ inet6 ::1/128 scope
+ host
+ 2: eth0:
+ <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen
+ 1000
+ link/ether
+ 00:a0:c9:15:39:78 brd ff:ff:ff:ff:ff:ff
+ inet6
+ fe80::2a0:c9ff:fe15:3978/64 scope link
+ 3: eth1:
+ <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen
+ 1000
+ link/ether
+ 00:a0:c9:a7:d7:bf brd ff:ff:ff:ff:ff:ff
+ inet6
+ fe80::2a0:c9ff:fea7:d7bf/64 scope link
+ 5: sit0@NONE: <NOARP> mtu 1480
+ qdisc noop
+ link/sit 0.0.0.0
+ brd 0.0.0.0
+ 6: eth2:
+ <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen
+ 1000
+ link/ether
+ 00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff
+ inet6
+ fe80::240:d0ff:fe07:3a1b/64 scope link
+ 7: br0:
+ <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc
+ noqueue
+ link/ether
+ 00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff
+ inet 192.168.1.3/24
+ brd 192.168.1.255 scope global br0
+ inet6
+ fe80::240:d0ff:fe07:3a1b/64 scope link
+
+ Routing Rules
+
+ 0: from
+ all lookup local
+ 32765: from all
+ fwmark ca lookup www.out
+ 32766: from all lookup
+ main
+ 32767: from all lookup
+ default
+
+ Table local:
+
+ broadcast 192.168.1.0 dev br0
+ proto kernel scope link src 192.168.1.3
+ broadcast 127.255.255.255 dev
+ lo proto kernel scope link src 127.0.0.1
+ local 192.168.1.3 dev br0 proto
+ kernel scope host src 192.168.1.3
+ broadcast 192.168.1.255 dev br0
+ proto kernel scope link src 192.168.1.3
+ broadcast 127.0.0.0 dev lo
+ proto kernel scope link src 127.0.0.1
+ local 127.0.0.1 dev lo proto
+ kernel scope host src 127.0.0.1
+ local 127.0.0.0/8 dev lo proto
+ kernel scope host src 127.0.0.1
+
+ Table www.out:
+
+ default via 192.168.1.3 dev
+ br0
+
+ Table main:
+
+ 192.168.1.0/24 dev br0 proto
+ kernel scope link src 192.168.1.3
+ default via 192.168.1.254 dev
+ br0
+
+ Table default:
+
+
+7/16/2004 - Shorewall 2.0.6
+
+ Problems Corrected:
+
+ Some users have reported the packet type
+ match option in iptables/Netfilter failing to match certain broadcast
+ packets. The result is that the firewall log shows a lot of broadcast
+ packets.
+
+ Other users have complained of the following message when starting
+ Shorewall:
+
+
+ modprobe: cant locate module ipt_pkttype
+
+ Users experiencing either of these problems can use PKTTYPE=No in
+ shorewall.conf to cause Shorewall to use IP address filtering of
+ broadcasts rather than packet type.
+ The shorewall.conf and zones file are no
+ longer given execute permission by the installer script.
+ ICMP packets that are in the INVALID state are now dropped by the
+ Reject and Drop default actions. They do so using the new 'dropInvalid'
+ builtin action.
+
+
+7/10/2004 - Shorewall 2.0.5
+
+Problems Corrected:
+
+ If DISABLE_IPV6=Yes in shorewall.conf
+ then harmless error messages referring to $RESTOREBASE are generated
+ during shorewall stop.
+ An anachronistic comment concerning a mangle option has been removed
+ from shorewall.conf.
+
+
+7/06/2004 - Shorewall 2.0.4
+
+Problems Corrected:
+
+
+7/03/2004 - New Shorewall Release Model
+
+ Effective today, Shorewall is adopting a new release model which takes
+ideas from the one used in the Linux Kernel and from the release model for
+Postfix.
+
+ Releases continue to have a three-level
+ identification x.y.z (e.g., 2.0.3).
+ The first two levels (x.y)
+ designate the Major Release Number (e.g., 2.0)
+ The third level (z) designates
+ the Minor Release Number.
+ Even numbered major releases (e.g.,
+ 1.4, 2.0, 2.2, ...) are Stable Releases. No new features
+ are added to stable releases and new minor releases of a stable release
+ will only contain bug fixes. Installing a new minor release for the major
+ release that you are currently running involves no migration issues (for
+ example, if you are running 1.4.10 and I release 1.4.11, your current
+ configuration is 100% compatible with the new release).
+ Support is available through the Mailing List for the two most
+ recent Stable Releases.
+ Odd numbered major releases (e.g., 2.1,
+ 2.3, ...) are Development Releases. Development releases are where
+ new functionality is introduced. Documentation for new features will be
+ available but it may not be up to the standards of the stable release
+ documentation. Sites running Development Releases should be prepared to
+ play an active role in testing new features. Bug fixes and problem
+ resolution for the development release take a back seat to support of the
+ stable releases. Problem reports for the current development release
+ should be sent to the Shorewall Development
+ Mailing List.
+ When the level of functionality of the
+ current development release is judged adaquate, the Beta period for a new
+ Stable release will begin. Beta releases have identifications of the form
+ x.y.0-BetaN where x.y is the number of the next Stable
+ Release and N=1,2,3... . Betas are expected to occur rougly once
+ per year. Beta releases may contain new functionality not present in the
+ previous beta release (e.g., 2.2.0-Beta4 may contain functionality not
+ present in 2.2.0-Beta3). When I'm confident that the current Beta release
+ is stable, I will release the first Release Candidate. Release
+ candidates have identifications of the form x.y.0-RCn where
+ x.y is the number of the next Stable Release and n=1,2,3...
+ . Release candidates contain no new functionailty -- they only contain
+ bug fixes. When the stability of the current release candidate is judged
+ to be sufficient then that release candidate will be released as the new
+ stable release (e.g., 2.2.0). At that time, the new stable release and
+ the prior stable release are those that are supported.
+ What does it mean for a major release to
+ be supported? It means that I will answer questions about the
+ release and that if a bug is found, I will fix the bug and include the
+ fix in the next minor release.
+ Between minor releases, bug fixes will continue to be made available
+ through the Errata page for each major release.
+
+
+The immediate implications of this change are as follows:
+
+ The functionality of the 2.0 major
+ release is frozen at the level of minor release 2.0.3.
+ The two major releases currently
+ supported are 1.4 and 2.0.
+ I will be opening the 2.1 development
+ release shortly with the release of 2.1.0.
+ Bug-fix releases with identifications of the form x.y.zX
+ where X=a,b,c,... (e.g., 2.0.3c) will not be seen in the future.
+
+
+7/02/2004 - Shorewall 2.0.3c
+
+ Problems Corrected:
+
+ Error messages regarding $RESTOREBASE
+ occur during shorewall stop
+ If CLEAR_TC=Yes in shorewall.conf, shorewall stop
+ fails without removing the lock file.
+
+
+
+6/30/2004 - Shorewall 2.0.3b and Shorewall 1.4.10g
+
+ Problems Corrected:
+
+ The security vulnerability fix released
+ in Shorewall 2.0.3a failed under Slackware 9.1.
+ The security vulnerability fix released in Shorewall 2.0.3a failed
+ if mktemp was not installed.
+
+
+6/28/2004 - Shorewall 2.0.3a and Shorewall
+1.4.10f
+
+ Problems Corrected:
+
+ Javier Fernández-Sanguino
+ Peña has discovered an exploitable vulnerability in the
+ way that Shorewall handles temporary files and directories. The
+ vulnerability can allow a non-root user to cause arbitrary files on the
+ system to be overwritten. LEAF Bering and Bering uClibc users are
+ generally not at risk due to the fact that LEAF boxes do not typically
+ allow logins by non-root users.
+ (2.0.3a only) A non-empty DEST entry in /etc/shorewall/tcrules will
+ generate an error and Shorewall fails to start.
+
+
+Note:: Slackware users may need the
+'functions' file from CVS (STABLE/ project for 1.4.10f and STABLE2/ project
+for 2.0.3a) to prevent startup errors with these versions installed. These
+updatged files are also available from the Errata (2.0, 1.4).
+
+6/23/2004 - Shorewall 2.0.3
+
+ Problems Corrected:
+
+ The 'firewall' script is not purging
+ temporary restore files in /var/lib/shorewall. These files have names of
+ the form "restore-nnnnn".
+ The /var/lib/shorewall/restore script
+ did not load the kernel modules specified in /etc/shorewall/modules.
+ Specifying a null common action in
+ /etc/shorewall/actions (e.g., :REJECT) results in a startup error.
+ If /var/lib/shorewall does not exist,
+ shorewall start fails.
+ DNAT rules with a dynamic source zone
+ don't work properly. When used, these rules cause the rule to be checked
+ against ALL input, not just input from the designated zone.
+ The install.sh script reported
+ installing some files in /etc/shorewall when the files were actually
+ installed in /usr/share/shorewall.
+ Shorewall checks netfilter capabilities
+ before loading kernel modules. Hence if kernel module autoloading isn't
+ enabled, the capabilities will be misdetected.
+ The 'newnotsyn' option in
+ /etc/shorewall/hosts has no effect.
+ The file /etc/init.d/shorewall now gets
+ proper ownership when the RPM is built by a non-root user.
+ Rules that specify bridge ports in both
+ the SOURCE and DEST columns no longer cause "shorewall start" to fail.
+ Comments in the rules file have been
+ added to advise users that "all" in the SOURCE or DEST column does not
+ affect intra-zone traffic.
+ With BLACKLISTNEWONLY=Yes, ICMP packets with state INVALID are now
+ passed through the blacklisting chains. Without this change, it is not
+ possible to blacklist hosts that are mounting certain types of ICMP-based
+ DOS attacks.
+
+
+Issues when migrating from Shorewall 2.0.2 to Shorewall 2.0.3:
+
+ The 'dropNonSyn' standard builtin action has been replaced with the
+ 'dropNotSyn' standard builtin action. The old name can still be used but
+ will generate a warning.
+
+
+New Features:
+
+ Shorewall now supports multiple saved
+ configurations.
+
+ The default saved configuration
+ (restore script) in /var/lib/shorewall is now specified using the
+ RESTOREFILE option in shorewall.conf. If this variable isn't set then
+ to maintain backward compatibility, 'restore' is assumed.
- Other users have complained of the following message when
- starting Shorewall:
+ The value of RESTOREFILE must be a simple file name; no slashes ("/")
+ may be included.
+ The "save" command has been extended
+ to be able to specify the name of a saved configuration.
-
- modprobe: cant locate module ipt_pkttype
+
+ shorewall save [ <file name> ]
- Users experiencing either of these problems can use
- PKTTYPE=No in shorewall.conf to cause Shorewall to use IP
- address filtering of broadcasts rather than packet
- type.
+ The current state is saved to /var/lib/shorewall/<file name>.
+ If no <file name> is given, the configuration is saved to the
+ file determined by the RESTOREFILE setting.
-
-
The shorewall.conf and zones
- file are no longer given execute permission by the
- installer script.
-
-
- -
-
ICMP packets that are in the INVALID state are now
- dropped by the Reject and Drop default actions. They do so
- using the new 'dropInvalid' builtin action.
-
-
-
- 7/10/2004 - Shorewall 2.0.5
-
- Problems Corrected:
-
-
- -
-
If DISABLE_IPV6=Yes in
- shorewall.conf then harmless error messages referring to
- $RESTOREBASE are generated during shorewall
- stop.
-
-
- -
-
An anachronistic comment concerning a mangle option has
- been removed from shorewall.conf.
-
-
-
- 7/06/2004 - Shorewall 2.0.4
-
- Problems Corrected:
-
-
-
- 7/03/2004 - New Shorewall
- Release Model
-
- Effective today, Shorewall is adopting a new release model
- which takes ideas from the one used in the Linux Kernel and
- from the release model for Postfix.
-
-
- -
-
Releases continue to have a
- three-level identification x.y.z (e.g., 2.0.3).
-
-
- -
-
The first two levels
- (x.y) designate the Major Release Number
- (e.g., 2.0)
-
-
- -
-
The third level (z)
- designates the Minor Release Number.
-
-
- -
-
Even numbered major releases
- (e.g., 1.4, 2.0, 2.2, ...) are Stable
- Releases. No new features are added to stable releases
- and new minor releases of a stable release will only
- contain bug fixes. Installing a new minor release for the
- major release that you are currently running involves no
- migration issues (for example, if you are running 1.4.10
- and I release 1.4.11, your current configuration is 100%
- compatible with the new release).
-
-
- -
-
Support is available through
- the Mailing List
- for the two most recent Stable Releases.
-
-
- -
-
Odd numbered major releases
- (e.g., 2.1, 2.3, ...) are Development Releases.
- Development releases are where new functionality is
- introduced. Documentation for new features will be
- available but it may not be up to the standards of the
- stable release documentation. Sites running Development
- Releases should be prepared to play an active role in
- testing new features. Bug fixes and problem resolution for
- the development release take a back seat to support of the
- stable releases. Problem reports for the current
- development release should be sent to the Shorewall
- Development Mailing List.
-
-
- -
-
When the level of
- functionality of the current development release is judged
- adaquate, the Beta period for a new Stable release will
- begin. Beta releases have identifications of the form
- x.y.0-BetaN where x.y is the number of the
- next Stable Release and N=1,2,3... . Betas are
- expected to occur rougly once per year. Beta releases may
- contain new functionality not present in the previous beta
- release (e.g., 2.2.0-Beta4 may contain functionality not
- present in 2.2.0-Beta3). When I'm confident that the
- current Beta release is stable, I will release the first
- Release Candidate. Release candidates have
- identifications of the form x.y.0-RCn where
- x.y is the number of the next Stable Release and
- n=1,2,3... . Release candidates contain no new
- functionailty -- they only contain bug fixes. When the
- stability of the current release candidate is judged to be
- sufficient then that release candidate will be released as
- the new stable release (e.g., 2.2.0). At that time, the new
- stable release and the prior stable release are those that
- are supported.
-
-
- -
-
What does it mean for a
- major release to be supported? It means that I will
- answer questions about the release and that if a bug is
- found, I will fix the bug and include the fix in the next
- minor release.
-
-
- -
-
Between minor releases, bug fixes will continue to be
- made available through the Errata page for each major
- release.
-
-
-
- The immediate implications of this change are as
- follows:
-
-
- -
-
The functionality of the 2.0
- major release is frozen at the level of minor release
- 2.0.3.
-
-
- -
-
The two major releases
- currently supported are 1.4 and 2.0.
-
-
- -
-
I will be opening the 2.1
- development release shortly with the release of 2.1.0.
-
-
- -
-
Bug-fix releases with identifications of the form
- x.y.zX where X=a,b,c,... (e.g., 2.0.3c) will not be
- seen in the future.
-
-
-
- 7/02/2004 - Shorewall 2.0.3c
-
- Problems Corrected:
-
-
- -
-
Error messages regarding
- $RESTOREBASE occur during shorewall stop
-
-
- -
-
If CLEAR_TC=Yes in shorewall.conf, shorewall
- stop fails without removing the lock file.
-
-
-
-
- 6/30/2004 - Shorewall 2.0.3b and Shorewall 1.4.10g
-
- Problems Corrected:
-
-
- -
-
The security vulnerability
- fix released in Shorewall 2.0.3a failed under Slackware
- 9.1.
-
-
- -
-
The security vulnerability fix released in Shorewall
- 2.0.3a failed if mktemp was not installed.
-
-
-
- 6/28/2004 - Shorewall 2.0.3a and
- Shorewall 1.4.10f
-
- Problems Corrected:
-
-
- -
-
Javier Fernández-Sanguino
- Peña has discovered an exploitable vulnerability in the way
- that Shorewall handles temporary files and directories. The
- vulnerability can allow a non-root user to cause arbitrary
- files on the system to be overwritten. LEAF Bering and
- Bering uClibc users are generally not at risk due to the
- fact that LEAF boxes do not typically allow logins by
- non-root users.
-
-
- -
-
(2.0.3a only) A non-empty DEST entry in
- /etc/shorewall/tcrules will generate an error and Shorewall
- fails to start.
-
-
-
- Note:: Slackware users may need
- the 'functions' file from CVS (STABLE/ project for 1.4.10f and
- STABLE2/ project for 2.0.3a) to prevent startup errors with
- these versions installed. These updatged files are also
- available from the Errata (2.0, 1.4).
-
- 6/23/2004 - Shorewall 2.0.3
-
- Problems Corrected:
-
-
- -
-
The 'firewall' script is not
- purging temporary restore files in /var/lib/shorewall.
- These files have names of the form "restore-nnnnn".
-
-
- -
-
The
- /var/lib/shorewall/restore script did not load the kernel
- modules specified in /etc/shorewall/modules.
-
-
- -
-
Specifying a null common
- action in /etc/shorewall/actions (e.g., :REJECT) results in
- a startup error.
-
-
- -
-
If /var/lib/shorewall does
- not exist, shorewall start fails.
-
-
- -
-
DNAT rules with a dynamic
- source zone don't work properly. When used, these rules
- cause the rule to be checked against ALL input, not just
- input from the designated zone.
-
-
- -
-
The install.sh script
- reported installing some files in /etc/shorewall when the
- files were actually installed in /usr/share/shorewall.
-
-
- -
-
Shorewall checks netfilter
- capabilities before loading kernel modules. Hence if kernel
- module autoloading isn't enabled, the capabilities will be
- misdetected.
-
-
- -
-
The 'newnotsyn' option in
- /etc/shorewall/hosts has no effect.
-
-
- -
-
The file
- /etc/init.d/shorewall now gets proper ownership when the
- RPM is built by a non-root user.
-
-
- -
-
Rules that specify bridge
- ports in both the SOURCE and DEST columns no longer cause
- "shorewall start" to fail.
-
-
- -
-
Comments in the rules file
- have been added to advise users that "all" in the SOURCE or
- DEST column does not affect intra-zone traffic.
-
-
- -
-
With BLACKLISTNEWONLY=Yes, ICMP packets with state
- INVALID are now passed through the blacklisting chains.
- Without this change, it is not possible to blacklist hosts
- that are mounting certain types of ICMP-based DOS
- attacks.
-
-
-
- Issues when migrating from Shorewall 2.0.2 to Shorewall
- 2.0.3:
-
-
- -
-
The 'dropNonSyn' standard builtin action has been
- replaced with the 'dropNotSyn' standard builtin action. The
- old name can still be used but will generate a warning.
-
-
-
- New Features:
-
-
- -
-
Shorewall now supports
- multiple saved configurations.
-
-
- -
-
The default saved
- configuration (restore script) in /var/lib/shorewall is
- now specified using the RESTOREFILE option in
- shorewall.conf. If this variable isn't set then to
- maintain backward compatibility, 'restore' is
- assumed.
-
- The value of RESTOREFILE must be a simple file name;
- no slashes ("/") may be included.
-
-
- -
-
The "save" command has
- been extended to be able to specify the name of a saved
- configuration.
-
-
- shorewall save [ <file name> ]
-
- The current state is saved to
- /var/lib/shorewall/<file name>. If no <file
- name> is given, the configuration is saved to the
- file determined by the RESTOREFILE setting.
-
-
- -
-
The "restore" command
- has been extended to be able to specify the name of a
- saved configuration:
-
-
- shorewall restore [ <file name> ]
-
- The firewall state is restored from
- /var/lib/shorewall/<file name>. If no <file
- name> is given, the firewall state is restored from
- the file determined by the RESTOREFILE setting.
-
-
- -
-
The "forget" command has
- changed. Previously, the command unconditionally
- removed the /var/lib/shorewall/save file which records
- the current dynamic blacklist. The "forget" command now
- leaves that file alone.
-
- Also, the "forget" command has been extended to be
- able to specify the name of a saved configuration:
-
-
- shorewall forget [ <file name> ]
-
- The file /var/lib/shorewall/<file name> is
- removed. If no <file name> is given, the file
- determined by the RESTOREFILE setting is removed.
-
-
- -
-
The "shorewall -f start"
- command restores the state from the file determined by
- the RESTOREFILE setting.
-
-
-
-
- -
-
"!" is now allowed in
- accounting rules.
-
-
- -
-
Interface names appearing
- within the configuration are now verified. Interface names
- must match the name of an entry in
- /etc/shorewall/interfaces (or if bridging is enabled, they
- must match the name of an entry in
- /etc/shorewall/interfaces or the name of a bridge port
- appearing in /etc/shorewall/hosts).
-
-
- -
-
A new 'rejNotSyn' built-in
- standard action has been added. This action responds to
- "New not SYN" packets with an RST.
+
The "restore" command has been
+ extended to be able to specify the name of a saved configuration:
- The 'dropNonSyn' action has been superceded by the new
- 'dropNotSyn' action. The old name will be accepted until
- the next major release of Shorewall but will generate a
- warning.
+ shorewall
+ restore [ <file name> ]
- Several new logging actions involving "New not SYN"
- packets have been added:
+ The firewall state is restored from /var/lib/shorewall/<file
+ name>. If no <file name> is given, the firewall state is
+ restored from the file determined by the RESTOREFILE setting.
+ The "forget" command has changed.
+ Previously, the command unconditionally removed the
+ /var/lib/shorewall/save file which records the current dynamic
+ blacklist. The "forget" command now leaves that file alone.
-
- logNewNotSyn -- logs the packet with disposition =
- LOG
- dLogNewNotSyn
- -- logs the packet with disposition = DROP
- rLogNewNotSyn
- -- logs the packet with disposition = REJECT
+ Also, the "forget" command has been extended to be able to specify
+ the name of a saved configuration:
- The packets are logged at the log level specified in the
- LOGNEWNOTSYN option in shorewall.conf. If than option is
- empty or not specified, then 'info' is assumed.
+
+ shorewall forget [ <file name> ]
- Examples (In all cases, set NEWNOTSYN=Yes in
- shorewall.conf):
-
-
- -
-
To simulate the behavior
- of NEWNOTSYN=No:
-
-
- -
-
Add 'NoNewNotSyn' to
- /etc/shorewall/actions.
-
-
- -
-
Create /etc/shorewall/action.NoNewNotSyn
- containing:
-
-
- dLogNotSyn
-
- dropNotSyn
-
-
- -
-
Early in your rules file, place:
-
-
- NoNewNotSyn all
- all tcp
-
-
-
-
- -
-
Drop 'New not SYN'
- packets from the net only. Don't log them:
-
-
- -
-
Early in your rules file, place:
-
-
- dropNotSyn
- net
- all tcp
-
-
-
-
+ The file /var/lib/shorewall/<file name> is removed. If no
+ <file name> is given, the file determined by the RESTOREFILE
+ setting is removed.
-
-
Slackware users no longer have to modify the install.sh
- script before installation. Tuomo Soini has provided a
- change that allows the INIT and FIREWALL variables to be
- specified outside the script as in:
-
- DEST=/etc/rc.d
- INIT=rc.firewall ./install.sh
+ The "shorewall -f start" command
+ restores the state from the file determined by the RESTOREFILE
+ setting.
-
- 6/3/2004 - Shorewall 2.0.2f
-
-
- Fixes one problem:
-
-
-
- - Versions 2.0.2d and 2.0.2e fail to load kernel modules
- unless MODULE_SUFFIX is set in shorewall.conf
-
-
-
- 6/2/2004 - Shorewall 2.0.2e
-
-
- One problem corrected:
-
-
-
- - LOG rules within an action generate two Netfilter logging
- rules.
-
-
-
- 5/28/2004 - Shorewall 2.0.2d
-
- One problem corrected:
-
-
-
- - Shorewall was checking capabilities before loading kernel
- modules. Consequently, if kernel module autoloading was
- disabled, the capabilities were mis-detected.
-
-
-
- 5/21/2004 - Shorewall 2.0.2c
- One problem corrected:
-
-
-
- - DNAT rules with a dynamic source zone don't work
- properly. When used, these rules cause the rule to be checked
- against ALL input, not just input from the designated
- zone.
-
-
-
- 5/18/2004 - Shorewall 2.0.2b
-
- Corrects two problems:
-
-
- - Specifying a null common action in /etc/shorewall/actions
- (e.g., :REJECT) results in a startup error.
-
-
-
- - If /var/lib/shorewall does not exist, shorewall start
- fails.
-
-
-
- 5/15/2004 - Shorewall 2.0.2a
-
-
- Corrects two problems:
-
-
-
- - Temporary restore files were not being removed from
- /var/lib/shorewall. These files have names of the form
- 'restore-nnnnn'. You can remove files that have
- accumulated with the command:
-
- rm -f
- /var/lib/shorewall/restore-[0-9]*
-
-
-
- - The restore script did not load kernel modules. The
- result was that after a cold load, applications like FTP and
- IRC DCC didn't work.
-
- To correct:
-
- 1) Install 2.0.2a
- 2) "shorewall restart"
- 3) "shorewall save"
-
-
- 5/13/2004 - Shorewall 2.0.2
-
- Problems Corrected since 2.0.1
-
-
-
- - The /etc/init.d/shorewall script installed on Debian by
- install.sh failed silently due to a missing file
- (/usr/share/shorewall/wait4ifup). That file is not part of
- the normal Shorewall distribution and is provided by the
- Debian maintainer.
-
- - A meaningless warning message out of the proxyarp file
- processing has been eliminated.
-
- - The "shorewall delete" command now correctly removes all
- dynamic rules pertaining to the host(s) being deleted. Thanks
- to Stefan Engel for this correction.
-
- Issues when migrating from Shorewall 2.0.1 to Shorewall
- 2.0.2:
-
-
-
- - Extension Scripts -- In order for extension scripts to
- work properly with the new iptables-save/restore integration
- (see New Feature 1 below), some change may be required to
- your extension scripts. If your extension scripts are
- executing commands other than iptables then those commands
- must also be written to the restore file (a temporary file in
- /var/lib/shorewall that is renamed
- /var/lib/shorewall/restore-base at the end of the
- operation).
-
- The following functions should be of help:
-
- A. save_command() -- saves the passed command to the restore
- file.
-
- Example:
-
- save_command echo
- Operation Complete
-
- That command would simply write "echo Operation
- Complete" to the restore file.
-
- B. run_and_save_command() -- saves the passed command to the
- restore file then executes it. The return value is the exit
- status of the command.
-
- Example:
-
- run_and_save_command
- "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"
-
- Note that as in this example, when the
- command involves file redirection then the entire command
- must be enclosed in quotes. This applies to all of the
- functions described here.
-
- C. ensure_and_save_command() -- runs the passed command. If
- the command fails, the firewall is restored to it's prior
- saved state and the operation is terminated. If the command
- succeeds, the command is written to the restore file.
-
-
-
- - Dynamic Zone support -- If you don't need to use the
- "shorewall add" and "shorewall delete commands, you should
- set DYNAMIC_ZONES=No in /etc/shorewall/shorewall.conf.
-
- New Features:
-
-
-
- - Shorewall has now been integrated with
- iptables-save/iptables-restore to provide very fast start and
- restart. The elements of this integration are as follows:
-
- a) The 'shorewall save' command now saves the current
- configuration in addition to the current dynamic blacklist.
- If you have dynamic zones, you will want to issue 'shorewall
- save' when the zones are empty or the current contents of the
- zones will be restored by the 'shorewall restore' and
- 'shorewall -f start' commands.
-
- b) The 'shorewall restore' command has been added. This
- command restores the configuration at the time of the last
- 'save'.
-
- c) The -f (fast) option has been added to 'shorewall start'.
- When specified (e.g. 'shorewall -f start'), shorewall will
- perform a 'shorewall restore' if there is a saved
- configuration. If there is no saved configuration, a normal
- 'shorewall start' is performed.
-
- d) The /etc/init.d/shorewall script now translates the
- 'start' command into 'shorewall -f start' so that fast
- restart is possible.
-
- e) When a state-changing command encounters an error and
- there is current saved configuration, that configuration will
- be restored (currently, the firewall is placed in the
- 'stopped' state).
-
- f) If you have previously saved the running configuration
- and want Shorewall to discard it, use the 'shorewall forget'
- command. WARNING: iptables 1.2.9 is broken with respect to
- iptables-save; if your kernel has connection tracking match
- support, you must patch iptables 1.2.9 with the iptables
- patch availale from the Shorewall errata page.
-
-
-
- - The previous implementation of dynamic zones was
- difficult to maintain. I have changed the code to make
- dynamic zones optional under the control of the DYNAMIC_ZONES
- option in /etc/shorewall/shorewall.conf.
-
-
-
- - In earlier Shorewall 2.0 releases, Shorewall searches in
- order the following directories for configuration files.
-
- a) The directory specified in a 'try' command or specified
- using the -c option.
- b) /etc/shorewall
- c) /usr/share/shorewall
-
- In this release, the CONFIG_PATH option is added to
- shorewall.conf. CONFIG_PATH contains a list of directory
- names separated by colons (":"). If not set or set to a null
- value (e.g., CONFIG_PATH="") then
- "CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed.
- Now Shorewall searches for shorewall.conf according to the
- old rules and for other configuration files as follows:
-
- a) The directory specified in a 'try' command or specified
- using the -c option.
- b) Each directory in $CONFIG_PATH is searched in
- sequence.
-
- In case it is not obvious, your CONFIG_PATH should include
- /usr/share/shorewall and your shorewall.conf file must be in
- the directory specified via -c or in a try command, in
- /etc/shorewall or in /usr/share/shorewall.
-
- For distribution packagers, the default CONFIG_PATH is set
- in /usr/share/shorewall/configpath. You can customize this
- file to have a default that differs from mine.
-
-
-
- - Previously, in /etc/shorewall/nat a Yes (or yes) in the
- LOCAL column would only take effect if the ALL INTERFACES
- column also contained Yes or yes. Now, the LOCAL columns
- contents are treated independently of the contents of the ALL
- INTERFACES column.
-
-
-
- - The folks at Mandrake have created yet another kernel
- module naming convention (module names end in "ko.gz"). As a
- consequence, beginning with this release, if MODULE_SUFFIX
- isn't specified in shorewall.conf, then the default value is
- "o gz ko o.gz ko.gz".
-
-
-
- - An updated bogons file is included in this release.
-
-
-
- - In /etc/shorewall/rules and in action files generated
- from /usr/share/shorewall/action.template, rules that perform
- logging can specify an optional "log tag". A log tag is a
- string of alphanumeric characters and is specified by
- following the log level with ":" and the log tag.
-
- Example:
-
- ACCEPT:info:ftp
- net dmz
- tcp 21
-
- The log tag is appended to the log prefix generated by the
- LOGPREFIX variable in /etc/shorewall/conf. If "ACCEPT:info"
- generates the log prefix "Shorewall:net2dmz:ACCEPT:" then
- "ACCEPT:info:ftp" will generate "Shorewall:net2dmz:ACCEPT:ftp
- " (note the trailing blank). The maximum length of a log
- prefix supported by iptables is 29 characters; if a larger
- prefix is generated, Shorewall will issue a warning message
- and will truncate the prefix to 29 characters.
-
-
-
- - A new "-q" option has been added to /sbin/shorewall
- commands. It causes the start, restart, check and refresh
- commands to produce much less output so that warning messages
- are more visible (when testing this change, I discovered a
- bug where a bogus warning message was being generated).
-
-
-
- - Shorewall now uses 'modprobe' to load kernel modules if
- that utility is available in the PATH; otherwise, 'insmod' is
- used.
-
-
-
- - It is now possible to restrict entries in the
- /etc/shorewall/masq file to particular protocols and
- destination port(s). Two new columns (PROTO and PORT(S)) have
- been added to the file.
-
- Example:
-
- You want all outgoing SMTP traffic entering the firewall on
- eth1 to be sent from eth0 with source IP address
- 206.124.146.177. You want all other outgoing traffic from
- eth1 to be sent from eth0 with source IP address
- 206.124.146.176.
-
-
- eth0 eth1 206.124.146.177
- tcp 25
-
- eth0 eth1
- 206.124.146.176
-
- THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!
-
- Assuming that 10.0.0.0/8 is the only host/network connected
- to eth1, the progress message at "shorewall start" would
- be:
-
- Masqueraded Networks and Hosts:
- To 0.0.0.0/0 (tcp 25)
- from 10.0.0.0/8 through eth0 using 206.124.146.177
- To 0.0.0.0/0 (all) from
- 10.0.0.0/8 through eth0 using 206.124.146.176
-
-
-
- - Two new actions are available in the /etc/shorewall/rules
- file.
-
- ACCEPT+ -- Behaves like
- ACCEPT with the exception that it exempts matching
- connections from subsequent DNAT[-] and REDIRECT[-]
- rules.
- NONAT --
- Exempts matching connections from subsequent DNAT[-] and
- REDIRECT[-] rules.
-
-
-
- - A new extension script 'initdone' has been added. This
- script is invoked at the same point as the 'common' script
- was previously and is useful for users who mis-used that
- script under Shorewall 1.x (the script was intended for
- adding rules to the 'common' chain but many users treated it
- as a script for adding rules before Shorewall's).
-
-
-
- - Installing/Upgrading Shorewall on Slackware has been
- improved. Slackware users must use the tarball and must
- modify settings in the install.sh script before running it as
- follows:
-
- DEST="/etc/rc.d"
- INIT="rc.firewall"
-
- Thanks to Alex Wilms for helping with this change.
-
-
- 4/17/2004 - Presentation at LinuxFest NW
-
- Today I gave a presentation at LinuxFest NW in Bellingham. The
- presentation was entitled "Shorewall and the Enterprise" and described
- the history of Shorewall and gave an overview of its features.
-
- 4/5/2004 - Shorewall 2.0.1
-
- Problems Corrected since 2.0.0
-
-
-
-
- - Using actions in the manner recommended in the
- documentation results in a Warning that the rule is a
- policy.
-
- - When a zone on a single interface is defined using
- /etc/shorewall/hosts, superfluous rules are generated in the
- <zone>_frwd chain.
-
- - Thanks to Sean Mathews, a long-standing problem with
- Proxy ARP and IPSEC has been corrected. Thanks Sean!!!
-
- - The "shorewall show log" and "shorewall logwatch"
- commands incorrectly displayed type 3 ICMP packets.
-
-
- Issues when migrating from Shorewall 2.0.0 to Shorewall
- 2.0.1:
-
-
-
-
- - The function of 'norfc1918' is now split between that
- option and a new 'nobogons' option.
-
- The rfc1918 file released with Shorewall now contains
- entries for only those three address ranges reserved by RFC
- 1918. A 'nobogons' interface option has been added which
- handles bogon source addresses (those which are reserved by
- the IANA, those reserved for DHCP auto-configuration and the
- class C test-net reserved for testing and documentation
- examples). This will allow users to perform RFC 1918
- filtering without having to deal with out of date data from
- IANA. Those who are willing to update their
- /usr/share/shorewall/bogons file regularly can specify the
- 'nobogons' option in addition to 'norfc1918'.
-
- The level at which bogon packets are logged is specified in
- the new BOGON_LOG_LEVEL variable in shorewall.conf. If that
- option is not specified or is specified as empty (e.g,
- BOGON_LOG_LEVEL="") then bogon packets whose TARGET is
- 'logdrop' in /usr/share/shorewall/bogons are logged at the
- 'info' level.
-
- New Features:
-
-
-
-
- - Support for Bridging Firewalls has been added. For
- details, see
-
- http://shorewall.net/bridge.html
-
-
-
-
- - Support for NETMAP has been added. NETMAP allows NAT to
- be defined between two network:
-
-
- a.b.c.1 -> x.y.z.1
-
- a.b.c.2 -> x.y.z.2
-
- a.b.c.3 -> x.y.z.3
-
- ...
-
- http://shorewall.net/netmap.htm
-
-
-
-
- - The /sbin/shorewall program now accepts a "-x" option to
- cause iptables to print out the actual packet and byte counts
- rather than abbreviated counts such as "13MB".
-
- Commands affected by this are:
-
-
- shorewall -x show [ <chain>[ <chain> ...] ]
-
- shorewall -x show tos|mangle
-
- shorewall -x show nat
-
- shorewall -x status
-
- shorewall -x monitor [ <interval> ]
-
-
-
- -
- Shorewall now traps two common zone definition errors:
-
-
-
- - Including the firewall zone in a /etc/shorewall/hosts
- record.
-
- - Defining an interface for a zone in both
- /etc/shorewall/interfaces and /etc/shorewall/hosts.
-
-
-
-
-
- - In the second case, the following will appear during
- "shorewall [re]start" or "shorewall check":
-
- Determining Hosts in Zones...
- ...
- Error: Invalid zone
- definition for zone <name of zone>
- Terminated
-
-
-
- - To support bridging, the following options have been
- added to entries in /etc/shorewall/hosts:
-
-
- norfc1918
-
- nobogons
-
- blacklist
-
- tcpflags
-
- nosmurfs
-
- newnotsyn
-
- With the exception of 'newnotsyn', these options are only
- useful when the entry refers to a bridge port.
-
- Example:
-
- #ZONE
- HOST(S) OPTIONS
- net
- br0:eth0
- norfc1918,nobogons,blacklist,tcpflags,nosmurfs
-
-
- 3/14/2004 - Shorewall 2.0.0b
- Corrects two problems:
-
-
-
- - Thanks to Sean Mathews, the long-standing problem with
- Proxy ARP and IPSEC has been eliminated!
-
- - The default value of the ALL INTERFACES column in
- /etc/shorewall/nat is documented as 'No' but the default
- continued to be 'Yes' as it was in Shorewall 1.4.
-
-
-
- 3/14/2004 - Shorewall 2.0.0a
-
- Corrects one problem:
-
-
-
- - Rules of the form:
-
- <action>
- zone1 zone2
-
- generated a warning stating that the rule was a policy.
-
-
-
- 3/14/2004 - Shorewall 2.0.0
-
-
- Dedicated to Agnes Van Slyke Eastep: March 14, 1910 -
- February 23, 2004
-
-
- Problems Corrected since 1.4.10
-
-
-
- - A blank USER/GROUP column in /etc/shorewall/tcrules no
- longer causes a [re]start error.
-
- - The 'fgrep' utility is no longer required (caused startup
- problems on LEAF/Bering).
-
- - The "shorewall add" command no longer inserts rules
- before checking of the blacklist.
-
- - The 'detectnets' and 'routeback' options may now be used
- together with the intended effect.
-
- - The following syntax previously produced an error:
-
- DNAT z1!z2,z3
- z4...
-
-
-
- Problems Corrected since RC2
-
-
-
-
- - CONTINUE rules now work again.
-
- - A comment in the rules file has been corrected.
-
-
-
- Issues when migrating from Shorewall 1.4.x to Shorewall
- 2.0.0:
-
-
-
- - The 'dropunclean' and 'logunclean' interface options are
- no longer supported. If either option is specified in
- /etc/shorewall/interfaces, an threatening message will be
- generated.
-
- - The NAT_BEFORE_RULES option has been removed from
- shorewall.conf. The behavior of Shorewall is as if
- NAT_BEFORE_RULES=No had been specified. In other words, DNAT
- rules now always take precidence over one-to-one NAT
- specifications.
-
- - The default value for the ALL INTERFACES column in
- /etc/shorewall/nat has changed. In Shorewall 1.*, if the
- column was left empty, a value of "Yes" was assumed. This has
- been changed so that a value of "No" is now assumed.
-
- - The following files don't exist in Shorewall 2.0:
- /etc/shorewall/common.def
- /etc/shorewall/common
- /etc/shorewall/icmpdef
- /etc/shorewall/action.template (Moved to
- /usr/share/shorewall)
- /etc/shorewall/rfc1918 (Moved to /usr/share/shorewall).
-
- The /etc/shorewall/action file now allows an action to be
- designated as the "common" action for a particular policy
- type by following the action name with ":" and the policy
- (DROP, REJECT or ACCEPT).
-
- The file /usr/share/shorewall/actions.std has been added to
- define those actions that are released as part of Shorewall.
- In that file are two actions as follows:
-
- Drop:DROP
- Reject:REJECT
-
- The "Drop" action is the common action for DROP policies
- while the "Reject" action is the default action for "REJECT"
- policies. These actions will be performed on packets prior to
- applying the DROP or REJECT policy respectively. In the first
- release, the difference between "Reject" and "Drop" is that
- "Reject" REJECTs SMB traffic while "Drop" silently drops such
- traffic.
-
- As described above, Shorewall allows a common action for
- ACCEPT policies but does not specify such an action in the
- default configuration.
-
- If for some reason, you don't wish to have a common DROP or
- REJECT action, just include :DROP or :REJECT respectively in
- your /etc/shorewall/actions file.
-
- The file /usr/share/shorewall/actions.std catalogs the
- standard actions and is processed prior to
- /etc/shorewall/actions. This causes a large number of actions
- to be defined. The files which define these aactions are also
- located in /usr/share/shorewall as is the he action template
- file (action.template).
-
- These actions may be used in the ACTION column of the rules
- column. So for example, to allow FTP from your loc zone to
- your firewall, you would place this rule in
- /etc/shorewall/rules:
-
- #ACTION
- SOURCE DEST
- AllowFTP
- loc
- fw
-
- If you want to redefine any of the Shorewall-defined
- actions, simply copy the appropriate action file from
- /usr/share/shorewall to /etc/shorewall and modify the copy as
- desired. Your modified copy will be used rather than the
- original one in /usr/share/shorewall.
-
- Note: The 'dropBcast' and 'dropNonSyn' actions are built
- into Shorewall and may not be changed.
-
- Beginning with version 2.0.0-Beta2, Shorewall will only
- create a chain for those actions that are actually used.
-
-
-
- - The /etc/shorewall directory no longer contains a 'users'
- file or a 'usersets' file. Similar functionality is now
- available using user-defined actions.
-
- Now, action files created by copying
- /usr/share/shorewall/action.template may specify a USER and
- or GROUP name/id in the final column just like in the rules
- file (see below). It is thus possible to create actions that
- control traffic from a list of users and/or groups.
-
- The last column in /etc/shorewall/rules is now labeled
- USER/GROUP and may contain:
-
- [!]<user number>[:]
- [!]<user name>[:]
- [!]:<group number>
- [!]:<group name>
- [!]<user number>:<group
- number>
- [!]<user number>:<group
- name>
- [!]<user name>:<group
- number>
- [!]<user name>:<group
- name>
-
-
-
- - It is no longer possible to specify rate limiting in the
- ACTION column of /etc/shorewall/rules -- you must use the
- RATE LIMIT column.
-
-
-
- - Depending on which method you use to upgrade, if you have
- your own version of /etc/shorewall/rfc1918, you may have to
- take special action to restore it after the upgrade. Look for
- /etc/shorewall/rfc1918*, locate the proper file and rename it
- back to /etc/shorewall/rfc1918. The contents of that file
- will supercede the contents of
- /usr/share/shorewall/rfc1918.
-
-
- New Features:
-
-
-
- - The INCLUDE directive now allows absolute file
- names.
-
- - A 'nosmurfs' interface option has been added to
- /etc/shorewall/interfaces. When specified for an interface,
- this option causes smurfs (packets with a broadcast address
- as their source) to be dropped and optionally logged (based
- on the setting of a new SMURF_LOG_LEVEL option in
- shorewall.conf).
-
- - fw->fw traffic may now be controlled by Shorewall.
- There is no need to define the loopback interface in
- /etc/shorewall/interfaces; you simply add a fw->fw policy
- and fw->fw rules. If you have neither a fw->fw policy
- nor fw->fw rules, all fw->fw traffic is allowed.
-
- - There is a new PERSISTENT column in the proxyarp file. A
- value of "Yes" in this column means that the route added by
- Shorewall for this host will remain after a "shorewall stop"
- or "shorewall clear".
-
- - "trace" is now a synonym for "debug" in /sbin/shorewall
- commands. So to trace the "start" command, you could
- enter:
-
- shorewall trace start 2> /tmp/trace
-
- The trace information would be written to the file
- /tmp/trace.
-
-
-
- - When defining an ipsec tunnel in /etc/shorewall/tunnels,
- if you follow the tunnel type ("ipsec" or "ipsecnet") with
- ":noah" (e.g., "ipsec:noah"), then Shorewall will only create
- rules for ESP (protocol 50) and will not create rules for AH
- (protocol 51).
-
- - A new DISABLE_IPV6 option has been added to
- shorewall.conf. When this option is set to "Yes", Shorewall
- will set the policy for the IPv6 INPUT, OUTPUT and FORWARD
- chains to DROP during "shorewall [re]start" and "shorewall
- stop". Regardless of the setting of this variable, "shorewall
- clear" will silently attempt to set these policies to
- ACCEPT.
-
- If this option is not set in your existing shorewall.conf
- then a setting of DISABLE_IPV6=No is assumed in which case,
- Shorewall will not touch any IPv6 settings except during
- "shorewall clear".
-
- - The CONTINUE target is now available in action
- definitions. CONTINUE terminates processing of the current
- action and returns to the point where that action was
- invoked.
-
-
- 2/15/2004 - Shorewall 1.4.10c
-
- Corrects one problem:
-
- Entries in /etc/shorewall/tcrules with an empty USER/GROUP
- column would cause a startup error.
-
- 2/12/2004 - Shorewall 1.4.10b
-
- Corrects one problem:
-
-
-
- - In the /etc/shorewall/masq entry “eth0:!10.1.1.150 0.0.0.0/0!10.1.0.0/16
- 10.1.2.16”, the “!10.1.0.0/16” is ignored.
-
-
- 2/8/2004 - Shorewall 1.4.10a
-
- Corrects two problems:
-
-
-
- - A problem which can cause [re]start to fail inexplicably
- while processing /etc/shorewall/masq.
-
- - Interfaces using the Atheros WiFi card to use the
- 'maclist' option.
-
-
- 1/30/2004 - Shorewall 1.4.10
-
- Problems Corrected since version 1.4.9
-
-
- - The column descriptions in the action.template file did
- not match the column headings. That has been corrected.
-
- - The presence of IPV6 addresses on devices generated error
- messages during [re]start if ADD_IP_ALIASES=Yes or
- ADD_SNAT_ALIASES=Yes are specified in
- /etc/shorewall/shorewall.conf. These messages have been
- eliminated.
-
- - The CONTINUE action in /etc/shorewall/rules now
- works correctly. A couple of problems involving rate limiting
- have been corrected. These bug fixes courtesy of Steven Jan
- Springl.
-
- - Shorewall now tried to avoid sending an ICMP response to
- broadcasts and smurfs.
-
- - Specifying "-" or "all" in the PROTO column of an action
- no longer causes a startup error.
-
- Migragion Issues:
-
- None.
-
- New Features:
-
-
-
- - The INTERFACE column in the /etc/shorewall/masq file may
- now specify a destination list.
-
- Example:
-
- #INTERFACE
-
- SUBNET ADDRESS
-
- eth0:192.0.2.3,192.0.2.16/28 eth1
-
- If the list begins with "!" then SNAT will occur only if the
- destination IP address is NOT included in the list.
-
-
-
- - Output traffic control rules (those with the firewall as
- the source) may now be qualified by the effective userid
- and/or effective group id of the program generating the
- output. This feature is courtesy of Frédéric
- LESPEZ.
-
- A new USER column has been added to /etc/shorewall/tcrules.
- It may contain :
-
- [<user name or
- number>]:[<group name or number>]
-
- The colon is optionnal when specifying only a user.
-
- Examples : john: / john
- / :users / john:users
-
-
-
- - A "detectnets" interface option has been added for
- entries in /etc/shorewall/interfaces. This option
- automatically tailors the definition of the zone named in the
- ZONE column to include just those hosts that have
- routes through the interface named in the INTERFACE column.
- The named interface must be UP when Shorewall is
- [re]started.
-
- WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
- INTERFACE!
-
-
- 1/27/2004 - Shorewall 1.4.10 RC3
-
- http://shorewall.net/pub/shorewall/Beta
-
- ftp://shorewall.net/pub/shorewall/Beta
-
-
- Problems Corrected since version 1.4.9
-
-
- - The column descriptions in the action.template file did
- not match the column headings. That has been corrected.
-
- - The presence of IPV6 addresses on devices generated error
- messages during [re]start if ADD_IP_ALIASES=Yes or
- ADD_SNAT_ALIASES=Yes are specified in
- /etc/shorewall/shorewall.conf. These messages have been
- eliminated.
-
- - The CONTINUE action in /etc/shorewall/rules now
- works correctly. A couple of problems involving rate limiting
- have been corrected. These bug fixes courtesy of Steven Jan
- Springl.
-
- - Shorewall now tried to avoid sending an ICMP response to
- broadcasts and smurfs.
-
-
- Migragion Issues:
-
- None.
-
- New Features:
-
-
-
- - The INTERFACE column in the /etc/shorewall/masq file may
- now specify a destination list.
-
- Example:
-
- #INTERFACE
-
- SUBNET ADDRESS
-
- eth0:192.0.2.3,192.0.2.16/28 eth1
-
- If the list begins with "!" then SNAT will occur only if the
- destination IP address is NOT included in the list.
-
-
-
- - Output traffic control rules (those with the firewall as
- the source) may now be qualified by the effective userid
- and/or effective group id of the program generating the
- output. This feature is courtesy of Frédéric
- LESPEZ.
-
- A new USER column has been added to /etc/shorewall/tcrules.
- It may contain :
-
- [<user name or
- number>]:[<group name or number>]
-
- The colon is optionnal when specifying only a user.
-
- Examples : john: / john
- / :users / john:users
-
-
-
- - A "detectnets" interface option has been added for
- entries in /etc/shorewall/interfaces. This option
- automatically tailors the definition of the zone named in the
- ZONE column to include just those hosts that have
- routes through the interface named in the INTERFACE column.
- The named interface must be UP when Shorewall is
- [re]started.
-
- WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
- INTERFACE!
-
-
- 1/24/2004 - Shorewall 1.4.10 RC2
-
- http://shorewall.net/pub/shorewall/Beta
-
- ftp://shorewall.net/pub/shorewall/Beta
-
-
- Problems Corrected since version 1.4.9
-
-
- - The column descriptions in the action.template file did
- not match the column headings. That has been corrected.
-
- - The presence of IPV6 addresses on devices generated error
- messages during [re]start if ADD_IP_ALIASES=Yes or
- ADD_SNAT_ALIASES=Yes are specified in
- /etc/shorewall/shorewall.conf. These messages have been
- eliminated.
-
- Migragion Issues:
-
- None.
-
- New Features:
-
-
-
- - The INTERFACE column in the /etc/shorewall/masq file may
- now specify a destination list.
-
- Example:
-
- #INTERFACE
-
- SUBNET ADDRESS
-
- eth0:192.0.2.3,192.0.2.16/28 eth1
-
- If the list begins with "!" then SNAT will occur only if the
- destination IP address is NOT included in the list.
-
-
-
- - Output traffic control rules (those with the firewall as
- the source) may now be qualified by the effective userid
- and/or effective group id of the program generating the
- output. This feature is courtesy of Frédéric
- LESPEZ.
-
- A new USER column has been added to /etc/shorewall/tcrules.
- It may contain :
-
- [<user name or
- number>]:[<group name or number>]
-
- The colon is optionnal when specifying only a user.
-
- Examples : john: / john
- / :users / john:users
-
-
-
- - A "detectnets" interface option has been added for
- entries in /etc/shorewall/interfaces. This option
- automatically tailors the definition of the zone named in the
- ZONE column to include just those hosts that have
- routes through the interface named in the INTERFACE column.
- The named interface must be UP when Shorewall is
- [re]started.
-
- WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
- INTERFACE!
-
-
- 1/22/2004 - Shorewall 1.4.10 RC1
-
- Problems Corrected since version 1.4.9
-
-
- - The column descriptions in the action.template file did
- not match the column headings. That has been corrected.
-
- - The presence of IPV6 addresses on devices generated error
- messages during [re]start if ADD_IP_ALIASES=Yes or
- ADD_SNAT_ALIASES=Yes are specified in
- /etc/shorewall/shorewall.conf. These messages have been
- eliminated.
-
- Migragion Issues:
-
- None.
-
- New Features:
-
-
-
- - The INTERFACE column in the /etc/shorewall/masq file may
- now specify a destination list.
-
- Example:
-
- #INTERFACE
-
- SUBNET ADDRESS
-
- eth0:192.0.2.3,192.0.2.16/28 eth1
-
- If the list begins with "!" then SNAT will occur only if the
- destination IP address is NOT included in the list.
-
-
-
- - Output traffic control rules (those with the firewall as
- the source) may now be qualified by the effective userid
- and/or effective group id of the program generating the
- output. This feature is courtesy of Frédéric
- LESPEZ.
-
- A new USER column has been added to /etc/shorewall/tcrules.
- It may contain :
-
- [<user name or
- number>]:[<group name or number>]
-
- The colon is optionnal when specifying only a user.
-
- Examples : john: / john
- / :users / john:users
-
-
-
- 1/13/2004 - Shorewall 1.4.9
-
-
- Problems Corrected since version 1.4.8:
-
-
-
- - There has been a low continuing level of confusion over
- the terms "Source NAT" (SNAT) and "Static NAT". To avoid
- future confusion, all instances of "Static NAT" have been
- replaced with "One-to-one NAT" in the documentation and
- configuration files.
-
- - The description of NEWNOTSYN in shorewall.conf has been
- reworded for clarity.
-
- - Wild-card rules (those involving "all" as SOURCE or DEST)
- will no longer produce an error if they attempt to add a rule
- that would override a NONE policy. The logic for expanding
- these wild-card rules now simply skips those (SOURCE,DEST)
- pairs that have a NONE policy.
-
- - DNAT rules that also specified SNAT now work reliably.
- Previously, there were cases where the SNAT specification was
- effectively ignored.
-
-
- Migration Issues:
-
- None.
-
- New Features:
-
-
-
- - The documentation has been completely rebased to Docbook
- XML. The documentation is now released as separate HTML and
- XML packages.
-
- - To cut down on the number of "Why are these ports closed
- rather than stealthed?" questions, the SMB-related rules in
- /etc/shorewall/common.def have been changed from 'reject' to
- 'DROP'.
-
- - For easier identification, packets logged under the
- 'norfc1918' interface option are now logged out of chains
- named 'rfc1918'. Previously, such packets were logged under
- chains named 'logdrop'.
-
- - Distributors and developers seem to be regularly
- inventing new naming conventions for kernel modules. To avoid
- the need to change Shorewall code for each new convention,
- the MODULE_SUFFIX option has been added to shorewall.conf.
- MODULE_SUFFIX may be set to the suffix for module names in
- your particular distribution. If MODULE_SUFFIX is not set in
- shorewall.conf, Shorewall will use the list "o gz ko
- o.gz".
-
- To see what suffix is used by your distribution:
-
- ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
-
- All of the files listed should have the same suffix
- (extension). Set MODULE_SUFFIX to that suffix.
-
- Examples:
-
- If all files end in ".kzo" then set
- MODULE_SUFFIX="kzo"
- If all files end in ".kz.o" then
- set MODULE_SUFFIX="kz.o"
-
- - Support for user defined rule ACTIONS has been
- implemented through two new files:
-
- /etc/shorewall/actions - used to list the user-defined
- ACTIONS.
- /etc/shorewall/action.template - For each user defined
- <action>, copy this file to
- /etc/shorewall/action.<action> and add the appropriate
- rules for that <action>. Once an <action> has
- been defined, it may be used like any of the builtin ACTIONS
- (ACCEPT, DROP, etc.) in /etc/shorewall/rules.
-
- Example: You want an action that logs a packet at the 'info'
- level and accepts the connection.
-
- In /etc/shorewall/actions, you would add:
-
- LogAndAccept
-
- You would then copy /etc/shorewall/action.template to
- /etc/shorewall/action.LogAndAccept and in that file, you
- would add the two rules:
- LOG:info
- ACCEPT
-
- - The default value for NEWNOTSYN in shorewall.conf is now
- "Yes" (non-syn TCP packets that are not part of an existing
- connection are filtered according to the rules and policies
- rather than being dropped). I have made this change for two
- reasons:
-
- a) NEWNOTSYN=No tends to result in lots of "stuck"
- connections since any timeout during TCP session tear down
- results in the firewall dropping all of the retries.
-
- b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info
- resulted in lots of confusing messages when a connection got
- "stuck". While I could have changed the default value of
- LOGNEWNOTSYN to suppress logging, I dislike defaults that
- silently throw away packets.
-
- - The common.def file now contains an entry that silently
- drops ICMP packets with a null source address. Ad Koster
- reported a case where these were occuring frequently as a
- result of a broken system on his external network.
-
-
- 12/29/2003 - Shorewall 1.4.9 Beta 2
-
-
-
- Problems Corrected since version 1.4.8:
-
-
- - There has been a low continuing level of confusion over
- the terms "Source NAT" (SNAT) and "Static NAT". To avoid
- future confusion, all instances of "Static NAT" have been
- replaced with "One-to-one NAT" in the documentation and
- configuration files.
-
- - The description of NEWNOTSYN in shorewall.conf has been
- reworded for clarity.
-
- - Wild-card rules (those involving "all" as SOURCE or DEST)
- will no longer produce an error if they attempt to add a rule
- that would override a NONE policy. The logic for expanding
- these wild-card rules now simply skips those (SOURCE,DEST)
- pairs that have a NONE policy.
-
- - DNAT rules that also specified SNAT now work reliably.
- Previously, there were cases where the SNAT specification was
- effectively ignored.
-
-
-
- Migration Issues:
-
- None.
-
- New Features:
-
-
- - The documentation has been completely rebased to Docbook
- XML. The documentation is now released as separate HTML and
- XML packages.
-
-
- - To cut down on the number of "Why are these ports closed
- rather than stealthed?" questions, the SMB-related rules in
- /etc/shorewall/common.def have been changed from 'reject' to
- 'DROP'.
-
- - For easier identification, packets logged under the
- 'norfc1918' interface option are now logged out of chains
- named 'rfc1918'. Previously, such packets were logged under
- chains named 'logdrop'.
-
- - Distributors and developers seem to be regularly
- inventing new naming conventions for kernel modules. To avoid
- the need to change Shorewall code for each new convention,
- the MODULE_SUFFIX option has been added to shorewall.conf.
- MODULE_SUFFIX may be set to the suffix for module names in
- your particular distribution. If MODULE_SUFFIX is not set in
- shorewall.conf, Shorewall will use the list "o gz ko
- o.gz".
-
- To see what suffix is used by your distribution:
-
- ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
-
- All of the files listed should have the same suffix
- (extension). Set MODULE_SUFFIX to that suffix.
-
- Examples:
-
- If all files end in ".kzo" then set
- MODULE_SUFFIX="kzo"
- If all files end in ".kz.o" then
- set MODULE_SUFFIX="kz.o"
-
- - Support for user defined rule ACTIONS has been
- implemented through two new files:
-
- /etc/shorewall/actions - used to list the user-defined
- ACTIONS.
- /etc/shorewall/action.template - For each user defined
- <action>, copy this file to
- /etc/shorewall/action.<action> and add the appropriate
- rules for that <action>. Once an <action> has
- been defined, it may be used like any of the builtin ACTIONS
- (ACCEPT, DROP, etc.) in /etc/shorewall/rules.
-
- Example: You want an action that logs a packet at the 'info'
- level and accepts the connection.
-
- In /etc/shorewall/actions, you would add:
-
- LogAndAccept
-
- You would then copy /etc/shorewall/action.template to
- /etc/shorewall/action.LogAndAccept and in that file, you
- would add the two rules:
- LOG:info
- ACCEPT
-
-
- - The default value for NEWNOTSYN in shorewall.conf is now
- "Yes" (non-syn TCP packets that are not part of an existing
- connection are filtered according to the rules and policies
- rather than being dropped). I have made this change for two
- reasons:
-
- a) NEWNOTSYN=No tends to result in lots of "stuck"
- connections since any timeout during TCP session tear down
- results in the firewall dropping all of the retries.
-
- b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info
- resulted in lots of confusing messages when a connection got
- "stuck". While I could have changed the default value of
- LOGNEWNOTSYN to suppress logging, I dislike defaults that
- silently throw away packets.
-
-
-
-
- 12/28/2003 - www.shorewall.net/ftp.shorewall.net Back
- On-line
-
-
- Our high-capacity server has been restored to service --
- please let us know
- if you find any problems.
-
- 12/29/2003 - Shorewall 1.4.9 Beta 1
-
-
-
- Problems Corrected since version 1.4.8:
-
-
- - There has been a low continuing level of confusion over
- the terms "Source NAT" (SNAT) and "Static NAT". To avoid
- future confusion, all instances of "Static NAT" have been
- replaced with "One-to-one NAT" in the documentation and
- configuration files.
-
- - The description of NEWNOTSYN in shorewall.conf has been
- reworded for clarity.
-
- - Wild-card rules (those involving "all" as SOURCE or DEST)
- will no longer produce an error if they attempt to add a rule
- that would override a NONE policy. The logic for expanding
- these wild-card rules now simply skips those (SOURCE,DEST)
- pairs that have a NONE policy.
-
-
- Migration Issues:
-
- None.
-
- New Features:
-
-
- - To cut down on the number of "Why are these ports closed
- rather than stealthed?" questions, the SMB-related rules in
- /etc/shorewall/common.def have been changed from 'reject' to
- 'DROP'.
-
- - For easier identification, packets logged under the
- 'norfc1918' interface option are now logged out of chains
- named 'rfc1918'. Previously, such packets were logged under
- chains named 'logdrop'.
-
- - Distributors and developers seem to be regularly
- inventing new naming conventions for kernel modules. To avoid
- the need to change Shorewall code for each new convention,
- the MODULE_SUFFIX option has been added to shorewall.conf.
- MODULE_SUFFIX may be set to the suffix for module names in
- your particular distribution. If MODULE_SUFFIX is not set in
- shorewall.conf, Shorewall will use the list "o gz ko
- o.gz".
-
- To see what suffix is used by your distribution:
-
- ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
-
- All of the files listed should have the same suffix
- (extension). Set MODULE_SUFFIX to that suffix.
-
- Examples:
-
- If all files end in ".kzo" then set
- MODULE_SUFFIX="kzo"
- If all files end in ".kz.o" then
- set MODULE_SUFFIX="kz.o"
-
- - Support for user defined rule ACTIONS has been
- implemented through two new files:
-
- /etc/shorewall/actions - used to list the user-defined
- ACTIONS.
- /etc/shorewall/action.template - For each user defined
- <action>, copy this file to
- /etc/shorewall/action.<action> and add the appropriate
- rules for that <action>. Once an <action> has
- been defined, it may be used like any of the builtin ACTIONS
- (ACCEPT, DROP, etc.) in /etc/shorewall/rules.
-
- Example: You want an action that logs a packet at the 'info'
- level and accepts the connection.
-
- In /etc/shorewall/actions, you would add:
-
- LogAndAccept
-
- You would then copy /etc/shorewall/action.template to
- /etc/shorewall/action.LogAndAccept and in that file, you
- would add the two rules:
- LOG:info
- ACCEPT
-
-
- - The default value for NEWNOTSYN in shorewall.conf is now
- "Yes" (non-syn TCP packets that are not part of an existing
- connection are filtered according to the rules and policies
- rather than being dropped). I have made this change for two
- reasons:
-
- a) NEWNOTSYN=No tends to result in lots of "stuck"
- connections since any timeout during TCP session tear down
- results in the firewall dropping all of the retries.
-
- b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info
- resulted in lots of confusing messages when a connection got
- "stuck". While I could have changed the default value of
- LOGNEWNOTSYN to suppress logging, I dislike defaults that
- silently throw away packets.
-
-
- 12/03/2003 - Support Torch Passed
- Effective today, I am reducing my participation in the
- day-to-day support of Shorewall. As part of this shift to
- community-based Shorewall support a new
- Shorewall Newbies mailing list has been established to
- field questions and problems from new users. I will not monitor
- that list personally. I will continue my active development of
- Shorewall and will be available via the development list to
- handle development issues -- Tom.
-
- 11/07/2003 - Shorewall 1.4.8
-
- Problems Corrected since version 1.4.7:
-
-
-
- - Tuomo Soini has supplied a correction to a problem that
- occurs using some versions of 'ash'. The symptom is that
- "shorewall start" fails with:
-
- local: --limit: bad variable name
- iptables v1.2.8: Couldn't load match
- `-j':/lib/iptables/libipt_-j.so:
- cannot open shared object file: No such file or
- directory
- Try `iptables -h' or 'iptables --help' for more
- information.
-
- - Andres Zhoglo has supplied a correction that avoids
- trying to use the multiport match iptables facility on ICMP
- rules.
-
- Example of rule that previously caused
- "shorewall start" to fail:
-
-
- ACCEPT loc $FW
- icmp 0,8,11,12
-
-
-
- - Previously, if the following error message was issued,
- Shorewall was left in an inconsistent state.
-
- Error: Unable to determine the routes through
- interface xxx
-
-
-
- - Handling of the LOGUNCLEAN option in shorewall.conf has
- been corrected.
-
- - In Shorewall 1.4.2, an optimization was added. This
- optimization involved creating a chain named
- "<zone>_frwd" for most zones defined using the
- /etc/shorewall/hosts file. It has since been discovered that
- in many cases these new chains contain redundant rules and
- that the "optimization" turns out to be less than optimal.
- The implementation has now been corrected.
-
- - When the MARK value in a tcrules entry is followed by
- ":F" or ":P", the ":F" or ":P" was previously only applied to
- the first Netfilter rule generated by the entry. It is now
- applied to all entries.
-
- - An incorrect comment concerning Debian's use of the
- SUBSYSLOCK option has been removed from shorewall.conf.
-
- - Previously, neither the 'routefilter' interface option
- nor the ROUTE_FILTER parameter were working properly. This
- has been corrected (thanks to Eric Bowles for his analysis
- and patch). The definition of the ROUTE_FILTER option has
- changed however. Previously, ROUTE_FILTER=Yes was documented
- as enabling route filtering on all interfaces (which didn't
- work). Beginning with this release, setting ROUTE_FILTER=Yes
- will enable route filtering of all interfaces brought up
- while Shorewall is started. As a consequence,
- ROUTE_FILTER=Yes can coexist with the use of the
- 'routefilter' option in the interfaces file.
-
- - If MAC verification was enabled on an interface with a
- /32 address and a broadcast address then an error would occur
- during startup.
-
- - The NONE policy's intended use is to suppress the
- generating of rules that can't possibly be traversed. This
- means that a policy of NONE is inappropriate where the source
- or destination zone is $FW or "all". Shorewall now generates
- an error message if such a policy is given in
- /etc/shorewall/policy. Previously such a policy caused
- "shorewall start" to fail.
-
- - The 'routeback' option was broken for wildcard interfaces
- (e.g., "tun+"). This has been corrected so that 'routeback'
- now works as expected in this case.
-
-
- Migration Issues:
-
-
-
- - The definition of the ROUTE_FILTER option in
- shorewall.conf has changed as described in item 8) above.
-
-
- New Features:
-
-
-
- - A new QUEUE action has been introduced for rules. QUEUE
- allows you to pass connection requests to a user-space filter
- such as ftwall (http://p2pwall.sourceforge.net). The ftwall
- program allows for effective filtering of p2p applications
- such as Kazaa. For example, to use ftwall to filter P2P
- clients in the 'loc' zone, you would add the following
- rules:
-
- QUEUE loc
- net tcp
- QUEUE loc
- net udp
- QUEUE loc
- fw udp
-
- You would normally want to place those three rules BEFORE
- any ACCEPT rules for loc->net udp or tcp.
-
- Note: When the protocol specified is TCP ("tcp", "TCP" or
- "6"), Shorewall will only pass connection requests (SYN
- packets) to user space. This is for compatibility with
- ftwall.
-
- - A BLACKLISTNEWNONLY option has been added to
- shorewall.conf. When this option is set to "Yes", the
- blacklists (dynamic and static) are only consulted for new
- connection requests. When set to "No" (the default if the
- variable is not set), the blacklists are consulted on every
- packet.
-
- Setting this option to "No" allows blacklisting to stop
- existing connections from a newly blacklisted host but is
- more expensive in terms of packet processing time. This is
- especially true if the blacklists contain a large number of
- entries.
-
- - Chain names used in the /etc/shorewall/accounting file
- may now begin with a digit ([0-9]) and may contain embedded
- dashes ("-").
-
-
- 10/30/2003 - Shorewall 1.4.8 RC1
-
- Given the small number of new features and the relatively few
- lines of code that were changed, there will be no Beta for
- 1.4.8.
-
-
- http://shorewall.net/pub/shorewall/Beta
-
- ftp://shorewall.net/pub/shorewall/Beta
-
- Problems Corrected since version 1.4.7:
-
-
-
- - Tuomo Soini has supplied a correction to a problem that
- occurs using some versions of 'ash'. The symptom is that
- "shorewall start" fails with:
-
- local: --limit: bad variable name
- iptables v1.2.8: Couldn't load match
- `-j':/lib/iptables/libipt_-j.so:
- cannot open shared object file: No such file or
- directory
- Try `iptables -h' or 'iptables --help' for more
- information.
-
- - Andres Zhoglo has supplied a correction that avoids
- trying to use the multiport match iptables facility on ICMP
- rules.
-
- Example of rule that previously caused
- "shorewall start" to fail:
-
-
- ACCEPT loc $FW
- icmp 0,8,11,12
-
-
-
- - Previously, if the following error message was issued,
- Shorewall was left in an inconsistent state.
-
- Error: Unable to determine the routes through
- interface xxx
-
-
-
- - Handling of the LOGUNCLEAN option in shorewall.conf has
- been corrected.
-
- - In Shorewall 1.4.2, an optimization was added. This
- optimization involved creating a chain named
- "<zone>_frwd" for most zones defined using the
- /etc/shorewall/hosts file. It has since been discovered that
- in many cases these new chains contain redundant rules and
- that the "optimization" turns out to be less than optimal.
- The implementation has now been corrected.
-
- - When the MARK value in a tcrules entry is followed by
- ":F" or ":P", the ":F" or ":P" was previously only applied to
- the first Netfilter rule generated by the entry. It is now
- applied to all entries.
-
- - An incorrect comment concerning Debian's use of the
- SYBSYSLOCK option has been removed from shorewall.conf.
-
- - Previously, neither the 'routefilter' interface option
- nor the ROUTE_FILTER parameter were working properly. This
- has been corrected (thanks to Eric Bowles for his analysis
- and patch). The definition of the ROUTE_FILTER option has
- changed however. Previously, ROUTE_FILTER=Yes was documented
- as enabling route filtering on all interfaces (which didn't
- work). Beginning with this release, setting ROUTE_FILTER=Yes
- will enable route filtering of all interfaces brought up
- while Shorewall is started. As a consequence,
- ROUTE_FILTER=Yes can coexist with the use of the
- 'routefilter' option in the interfaces file.
-
- Migration Issues:
-
-
-
- - The definition of the ROUTE_FILTER option in
- shorewall.conf has changed as described in item 8) above.
-
-
- New Features:
-
-
-
- - A new QUEUE action has been introduced for rules. QUEUE
- allows you to pass connection requests to a user-space filter
- such as ftwall (http://p2pwall.sourceforge.net). The ftwall
- program allows for effective filtering of p2p applications
- such as Kazaa. For example, to use ftwall to filter P2P
- clients in the 'loc' zone, you would add the following
- rules:
-
- QUEUE loc
- net tcp
- QUEUE loc
- net udp
- QUEUE loc
- fw udp
-
- You would normally want to place those three rules BEFORE
- any ACCEPT rules for loc->net udp or tcp.
-
- Note: When the protocol specified is TCP ("tcp", "TCP" or
- "6"), Shorewall will only pass connection requests (SYN
- packets) to user space. This is for compatibility with
- ftwall.
-
- - A BLACKLISTNEWNONLY option has been added to
- shorewall.conf. When this option is set to "Yes", the
- blacklists (dynamic and static) are only consulted for new
- connection requests. When set to "No" (the default if the
- variable is not set), the blacklists are consulted on every
- packet.
-
- Setting this option to "No" allows blacklisting to stop
- existing connections from a newly blacklisted host but is
- more expensive in terms of packet processing time. This is
- especially true if the blacklists contain a large number of
- entries.
-
- - Chain names used in the /etc/shorewall/accounting file
- may now begin with a digit ([0-9]) and may contain embedded
- dashes ("-").
-
-
-
- 10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper
- bag awards 
Shorewall
- 1.4.7c released.
-
-
- - The saga with "<zone>_frwd" chains continues. The
- 1.4.7c script produces a ruleset that should work for
- everyone even if it is not quite optimal. My apologies for
- this ongoing mess.
-
-
-
- 10/24/2003 - Shorewall 1.4.7b
- This is a bugfx rollup of the 1.4.7a fixes plus:
-
-
-
- - The fix for problem 5 in 1.4.7a was wrong with the result
- that "<zone>_frwd" chains might contain too few rules.
- That wrong code is corrected in this release.
-
-
-
- 10/21/2003 - Shorewall 1.4.7a
-
-
- This is a bugfix rollup of the following problem
- corrections:
-
-
-
- - Tuomo Soini has supplied a correction to a problem that
- occurs using some versions of 'ash'. The symptom is that
- "shorewall start" fails with:
-
- local: --limit: bad variable name
- iptables v1.2.8: Couldn't load match
- `-j':/lib/iptables/libipt_-j.so:
- cannot open shared object file: No such file or
- directory
- Try `iptables -h' or 'iptables --help' for more
- information.
-
-
-
- - Andres Zhoglo has supplied a correction that avoids
- trying to use the multiport match iptables facility on ICMP
- rules.
-
- Example of rule that previously caused
- "shorewall start" to fail:
-
-
- ACCEPT loc $FW
- icmp 0,8,11,12
-
-
-
- - Previously, if the following error message was issued,
- Shorewall was left in an inconsistent state.
-
- Error: Unable to determine the routes through
- interface xxx
-
-
-
- - Handling of the LOGUNCLEAN option in shorewall.conf has
- been corrected.
-
- - In Shorewall 1.4.2, an optimization was added. This
- optimization involved creating a chain named
- "<zone>_frwd" for most zones defined using the
- /etc/shorewall/hosts file. It has since been discovered that
- in many cases these new chains contain redundant rules and
- that the "optimization" turns out to be less than optimal.
- The implementation has now been corrected.
-
- - When the MARK value in a tcrules entry is followed by
- ":F" or ":P", the ":F" or ":P" was previously only applied to
- the first Netfilter rule generated by the entry. It is now
- applied to all entries.
-
-
-
- 10/06/2003 - Shorewall 1.4.7
-
- Problems Corrected since version 1.4.6 (Those in bold font
- were corrected since 1.4.7 RC2).
-
-
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
- variable was being tested before it was set.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
- - The "shorewall stop" command is now disabled when
- /etc/shorewall/startup_disabled exists. This prevents people
- from shooting themselves in the foot prior to having
- configured Shorewall.
-
- - A change introduced in version 1.4.6 caused error
- messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
- and ip addresses were being added to a PPP interface; the
- addresses were successfully added in spite of the
- messages.
-
- The firewall script has been modified to eliminate the error
- messages
-
- - Interface-specific dynamic blacklisting chains are now
- displayed by "shorewall monitor" on the "Dynamic Chains" page
- (previously named "Dynamic Chain").
-
- - Thanks to Henry Yang, LOGRATE and LOGBURST now work
- again.
-
- - The 'shorewall reject' and 'shorewall drop'
- commands now delete any existing rules for the subject IP
- address before adding a new DROP or REJECT rule. Previously,
- there could be many rules for the same IP address in the
- dynamic chain so that multiple 'allow' commands were required
- to re-enable traffic to/from the address.
-
- - When ADD_SNAT_ALIASES=Yes in shorewall.conf, the
- following entry in /etc/shorewall/masq resulted in a startup
- error:
-
- eth0 eth1
- 206.124.146.20-206.124.146.24
-
-
-
- - Shorewall previously choked over IPV6 addresses
- configured on interfaces in contexts where Shorewall needed
- to detect something about the interface (such as when
- "detect" appears in the BROADCAST column of the
- /etc/shorewall/interfaces file).
-
- - Shorewall will now load module files that are formed from
- the module name by appending ".o.gz".
-
- - When Shorewall adds a route to a proxy ARP host and such
- a route already exists, two routes resulted previously. This
- has been corrected so that the existing route is replaced if
- it already exists.
-
- - The rfc1918 file has been updated to reflect recent
- allocations.
-
- - The documentation of the USER SET column in the rules
- file has been corrected.
-
- - If there is no policy defined for the zones specified in
- a rule, the firewall script previously encountered a shell
- syntax error:
-
-
- [: NONE:
- unexpected operator
-
-
- Now, the absence of a policy generates an error message and
- the firewall is stopped:
-
-
- No policy defined
- from zone <source> to zone <dest>
-
-
-
- - Previously, if neither /etc/shorewall/common nor
- /etc/shorewall/common.def existed, Shorewall would fail to
- start and would not remove the lock file. Failure to remove
- the lock file resulted in the following during subsequent
- attempts to start:
-
-
- Loading
- /usr/share/shorewall/functions...
- Processing /etc/shorewall/params ...
- Processing
- /etc/shorewall/shorewall.conf...
- Giving up on lock file
- /var/lib/shorewall/lock
- Shorewall Not Started
-
- Shorewall now reports a fatal error if neither of these two
- files exist and correctly removes the lock fille.
-
- - The order of processing the various options has been
- changed such that blacklist entries now take precedence over
- the 'dhcp' interface
- setting.
-
- - The log message generated from the 'logunclean' interface
- option has been changed to reflect a disposition of LOG
- rather than DROP.
-
- - When a user name and/or
- a group name was specified in the USER SET column and the
- destination zone was qualified with a IP address, the user
- and/or group name was not being used to qualify the rule.
-
- Example:
-
- ACCEPT fw net:192.0.2.12 tcp 23 - -
- - vladimir:
-
-
-
- - The /etc/shorewall/masq
- file has had the spurious "/" character at the front
- removed.
-
-
-
- Migration Issues:
-
-
-
- - Shorewall IP Traffic Accounting has changed since
- snapshot 20030813 -- see the Accounting Page for details.
-
- - The Uset Set capability introduced in SnapShot 20030821
- has changed -- see the User Set
- page for details.
-
- - The per-interface Dynamic Blacklisting facility
- introduced in the first post-1.4.6 Snapshot has been removed.
- The facility had too many idiosyncrasies for dial-up users to
- be a viable part of Shorewall.
-
-
- New Features:
-
-
-
- - Thanks to Steve Herber, the 'help' command can now give
- command-specific help (e.g., shorewall help
- <command>).
-
- - A new option "ADMINISABSENTMINDED" has been added to
- /etc/shorewall/shorewall.conf. This option has a default
- value of "No" for existing users which causes Shorewall's
- 'stopped' state to continue as it has been; namely, in
- the stopped state only traffic to/from hosts listed in
- /etc/shorewall/routestopped is accepted.
-
- With ADMINISABSENTMINDED=Yes (the default for new installs),
- in addition to traffic to/from the hosts listed in
- /etc/shorewall/routestopped, Shorewall will allow:
-
- a) All traffic originating from the firewall
- itself; and
- b) All traffic that is part of or related to an
- already-existing connection.
-
- In particular, with ADMINISABSENTMINDED=Yes, a
- "shorewall stop" entered through an ssh session will not kill
- the session.
-
- Note though that even with ADMINISABSENTMINDED=Yes, it
- is still possible for people to shoot themselves in the
- foot.
-
- Example:
-
- /etc/shorewall/nat:
-
- 206.124.146.178
- eth0:0 192.168.1.5
-
- /etc/shorewall/rules:
-
- ACCEPT net
- loc:192.168.1.5 tcp
- 22
- ACCEPT loc
- fw tcp
- 22
-
- From a remote system, I ssh to 206.124.146.178 which
- establishes an SSH connection with local system 192.168.1.5.
- I then create a second SSH connection from that computer to
- the firewall and confidently type "shorewall stop". As part
- of its stop processing, Shorewall removes eth0:0 which kills
- my SSH connection to 192.168.1.5!!!
-
- - Given the wide range of VPN software, I can never hope to
- add specific support for all of it. I have therefore decided
- to add "generic" tunnel support.
-
- Generic tunnels work pretty much like any of the other
- tunnel types. You usually add a zone to represent the systems
- at the other end of the tunnel and you add the appropriate
- rules/policies to
- implement your security policy regarding traffic to/from
- those systems.
-
- In the /etc/shorewall/tunnels file, you can have entries of
- the form:
-
- generic:<protocol>[:<port>]
- <zone> <ip address>
- <gateway zones>
-
- where:
-
- <protocol> is the
- protocol used by the tunnel
- <port> if
- the protocol is 'udp' or 'tcp' then this is the destination
- port number used by the tunnel.
- <zone> is
- the zone of the remote tunnel gateway
- <ip address> is
- the IP address of the remote tunnel gateway.
- <gateway
- zone> Optional. A comma-separated list of zone
- names. If specified, the remote gateway is to be considered
- part of these zones.
-
- - An 'arp_filter' option has been added to the
- /etc/shorewall/interfaces file. This option causes
- /proc/sys/net/ipv4/conf/<interface>/arp_filter to be
- set with the result that this interface will only answer ARP
- 'who-has' requests from hosts that are routed out through
- that interface. Setting this option facilitates testing of
- your firewall where multiple firewall interfaces are
- connected to the same HUB/Switch (all interfaces connected to
- the single HUB/Switch should have this option specified).
- Note that using such a configuration in a production
- environment is strongly recommended against.
-
- - The ADDRESS column in /etc/shorewall/masq may now include
- a comma-separated list of addresses and/or address ranges.
- Netfilter will use all listed addresses/ranges in round-robin
- fashion. \
-
- - An /etc/shorewall/accounting file has been added to allow
- for traffic accounting. See the accounting documentation for a
- description of this facility.
-
- - Bridge interfaces (br[0-9]) may now be used in
- /etc/shorewall/maclist.
-
- - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
- /etc/shorewall/rules may now be rate-limited. For DNAT and
- REDIRECT rules, rate limiting occurs in the nat table DNAT
- rule; the corresponding ACCEPT rule in the filter table is
- not rate limited. If you want to limit the filter table rule,
- you will need o create two rules; a DNAT- rule and an ACCEPT
- rule which can be rate-limited separately.
-
- Warning: When rate
- limiting is specified on a rule with "all" in the SOURCE or
- DEST fields, the limit will apply to each pair of zones
- individually rather than as a single limit for all pairs of
- covered by the rule.
-
- To specify a rate limit,
-
- a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
-
- <
- <rate>/<interval>[:<burst>] >
-
- where
-
- <rate> is the sustained
- rate per <interval>
- <interval> is "sec" or
- "min"
- <burst> is the largest
- burst accepted within an <interval>. If not given, the
- default of 5 is assumed.
-
- There may be no white space between the ACTION and "<"
- nor there may be any white space within the burst
- specification. If you want to specify logging of a
- rate-limited rule, the ":" and log level comes after the
- ">" (e.g., ACCEPT<2/sec:4>:info ).
-
- b) A new RATE LIMIT column has been added to the
- /etc/shorewall/rules file. You may specify the rate limit
- there in the format:
-
-
- <rate>/<interval>[:<burst>]
-
- Let's take an example:
-
-
- ACCEPT<2/sec:4>
- net dmz
- tcp 80
-
- The first time this rule is reached, the packet will be
- accepted; in fact, since the burst is 4, the first four
- packets will be accepted. After this, it will be 500ms (1
- second divided by the rate
- of 2) before a packet will be accepted from this rule,
- regardless of how many packets reach it. Also, every 500ms
- which passes without matching a packet, one of the bursts
- will be regained; if no packets hit the rule for 2 second,
- the burst will be fully recharged; back where we started.
-
-
- - Multiple chains may now be displayed in one "shorewall
- show" command (e.g., shorewall show INPUT FORWARD
- OUTPUT).
-
- - Output rules (those with $FW as the SOURCE) may now be
- limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html for
- details.
-
-
- 10/02/2003 - Shorewall 1.4.7 RC2
-
-
- http://shorewall.net/pub/shorewall/Beta
-
- ftp://shorewall.net/pub/shorewall/Beta
-
- Problems Corrected since version 1.4.6 (Those in bold font
- were corrected since 1.4.7 RC 1).
-
-
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
- variable was being tested before it was set.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
- - The "shorewall stop" command is now disabled when
- /etc/shorewall/startup_disabled exists. This prevents people
- from shooting themselves in the foot prior to having
- configured Shorewall.
-
- - A change introduced in version 1.4.6 caused error
- messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
- and ip addresses were being added to a PPP interface; the
- addresses were successfully added in spite of the
- messages.
-
- The firewall script has been modified to eliminate the error
- messages
-
- - Interface-specific dynamic blacklisting chains are now
- displayed by "shorewall monitor" on the "Dynamic Chains" page
- (previously named "Dynamic Chain").
-
- - Thanks to Henry Yang, LOGRATE and LOGBURST now work
- again.
-
- - The 'shorewall reject' and 'shorewall drop'
- commands now delete any existing rules for the subject IP
- address before adding a new DROP or REJECT rule. Previously,
- there could be many rules for the same IP address in the
- dynamic chain so that multiple 'allow' commands were required
- to re-enable traffic to/from the address.
-
- - When ADD_SNAT_ALIASES=Yes in shorewall.conf, the
- following entry in /etc/shorewall/masq resulted in a startup
- error:
-
- eth0 eth1
- 206.124.146.20-206.124.146.24
-
-
-
- - Shorewall previously choked over IPV6 addresses
- configured on interfaces in contexts where Shorewall needed
- to detect something about the interface (such as when
- "detect" appears in the BROADCAST column of the
- /etc/shorewall/interfaces file).
-
- - Shorewall will now load module files that are formed from
- the module name by appending ".o.gz".
-
- - When Shorewall adds a route to a proxy ARP host and such
- a route already exists, two routes resulted previously. This
- has been corrected so that the existing route is replaced if
- it already exists.
-
- - The rfc1918 file has been updated to reflect recent
- allocations.
-
- - The documentation of the
- USER SET column in the rules file has been
- corrected.
-
- - If there is no policy
- defined for the zones specified in a rule, the firewall
- script previously encountered a shell syntax error:
-
-
- [: NONE:
- unexpected operator
-
-
- Now, the absence of a policy generates an error message and
- the firewall is stopped:
-
-
- No policy defined
- from zone <source> to zone <dest>
-
-
-
- - Previously, if neither
- /etc/shorewall/common nor /etc/shorewall/common.def existed,
- Shorewall would fail to start and would not remove the lock
- file. Failure to remove the lock file resulted in the
- following during subsequent attempts to start:
-
-
- Loading
- /usr/share/shorewall/functions...
- Processing /etc/shorewall/params ...
- Processing
- /etc/shorewall/shorewall.conf...
- Giving up on lock file
- /var/lib/shorewall/lock
- Shorewall Not Started
-
- Shorewall now reports a fatal error if neither of these two
- files exist and correctly removes the lock fille.
-
- - The order of processing
- the various options has been changed such that blacklist
- entries now take precedence over the 'dhcp' interface
- setting.
-
- - The log message
- generated from the 'logunclean' interface option has been
- changed to reflect a disposition of LOG rather than
- DROP.
-
- - The RFC1918 file has
- been updated to reflect recent IANA allocations.
-
-
- Migration Issues:
-
-
-
- - Shorewall IP Traffic Accounting has changed since
- snapshot 20030813 -- see the Accounting Page for details.
-
- - The Uset Set capability introduced in SnapShot 20030821
- has changed -- see the User Set
- page for details.
-
- - The per-interface Dynamic Blacklisting facility
- introduced in the first post-1.4.6 Snapshot has been removed.
- The facility had too many idiosyncrasies for dial-up users to
- be a viable part of Shorewall.
-
-
- New Features:
-
-
-
- - Thanks to Steve Herber, the 'help' command can now give
- command-specific help (e.g., shorewall help
- <command>).
-
- - A new option "ADMINISABSENTMINDED" has been added to
- /etc/shorewall/shorewall.conf. This option has a default
- value of "No" for existing users which causes Shorewall's
- 'stopped' state to continue as it has been; namely, in
- the stopped state only traffic to/from hosts listed in
- /etc/shorewall/routestopped is accepted.
-
- With ADMINISABSENTMINDED=Yes (the default for new installs),
- in addition to traffic to/from the hosts listed in
- /etc/shorewall/routestopped, Shorewall will allow:
-
- a) All traffic originating from the firewall
- itself; and
- b) All traffic that is part of or related to an
- already-existing connection.
-
- In particular, with ADMINISABSENTMINDED=Yes, a
- "shorewall stop" entered through an ssh session will not kill
- the session.
-
- Note though that even with ADMINISABSENTMINDED=Yes, it
- is still possible for people to shoot themselves in the
- foot.
-
- Example:
-
- /etc/shorewall/nat:
-
- 206.124.146.178
- eth0:0 192.168.1.5
-
- /etc/shorewall/rules:
-
- ACCEPT net
- loc:192.168.1.5 tcp
- 22
- ACCEPT loc
- fw tcp
- 22
-
- From a remote system, I ssh to 206.124.146.178 which
- establishes an SSH connection with local system 192.168.1.5.
- I then create a second SSH connection from that computer to
- the firewall and confidently type "shorewall stop". As part
- of its stop processing, Shorewall removes eth0:0 which kills
- my SSH connection to 192.168.1.5!!!
-
- - Given the wide range of VPN software, I can never hope to
- add specific support for all of it. I have therefore decided
- to add "generic" tunnel support.
-
- Generic tunnels work pretty much like any of the other
- tunnel types. You usually add a zone to represent the systems
- at the other end of the tunnel and you add the appropriate
- rules/policies to
- implement your security policy regarding traffic to/from
- those systems.
-
- In the /etc/shorewall/tunnels file, you can have entries of
- the form:
-
- generic:<protocol>[:<port>]
- <zone> <ip address>
- <gateway zones>
-
- where:
-
- <protocol> is the
- protocol used by the tunnel
- <port> if
- the protocol is 'udp' or 'tcp' then this is the destination
- port number used by the tunnel.
- <zone> is
- the zone of the remote tunnel gateway
- <ip address> is
- the IP address of the remote tunnel gateway.
- <gateway
- zone> Optional. A comma-separated list of zone
- names. If specified, the remote gateway is to be considered
- part of these zones.
-
- - An 'arp_filter' option has been added to the
- /etc/shorewall/interfaces file. This option causes
- /proc/sys/net/ipv4/conf/<interface>/arp_filter to be
- set with the result that this interface will only answer ARP
- 'who-has' requests from hosts that are routed out through
- that interface. Setting this option facilitates testing of
- your firewall where multiple firewall interfaces are
- connected to the same HUB/Switch (all interfaces connected to
- the single HUB/Switch should have this option specified).
- Note that using such a configuration in a production
- environment is strongly recommended against.
-
- - The ADDRESS column in /etc/shorewall/masq may now include
- a comma-separated list of addresses and/or address ranges.
- Netfilter will use all listed addresses/ranges in round-robin
- fashion. \
-
- - An /etc/shorewall/accounting file has been added to allow
- for traffic accounting. See the accounting documentation for a
- description of this facility.
-
- - Bridge interfaces (br[0-9]) may now be used in
- /etc/shorewall/maclist.
-
- - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
- /etc/shorewall/rules may now be rate-limited. For DNAT and
- REDIRECT rules, rate limiting occurs in the nat table DNAT
- rule; the corresponding ACCEPT rule in the filter table is
- not rate limited. If you want to limit the filter table rule,
- you will need o create two rules; a DNAT- rule and an ACCEPT
- rule which can be rate-limited separately.
-
- Warning: When rate
- limiting is specified on a rule with "all" in the SOURCE or
- DEST fields, the limit will apply to each pair of zones
- individually rather than as a single limit for all pairs of
- covered by the rule.
-
- To specify a rate limit,
-
- a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
-
- <
- <rate>/<interval>[:<burst>] >
-
- where
-
- <rate> is the sustained
- rate per <interval>
- <interval> is "sec" or
- "min"
- <burst> is the largest
- burst accepted within an <interval>. If not given, the
- default of 5 is assumed.
-
- There may be no white space between the ACTION and "<"
- nor there may be any white space within the burst
- specification. If you want to specify logging of a
- rate-limited rule, the ":" and log level comes after the
- ">" (e.g., ACCEPT<2/sec:4>:info ).
-
- b) A new RATE LIMIT column has been added to the
- /etc/shorewall/rules file. You may specify the rate limit
- there in the format:
-
-
- <rate>/<interval>[:<burst>]
-
- Let's take an example:
-
-
- ACCEPT<2/sec:4>
- net dmz
- tcp 80
-
- The first time this rule is reached, the packet will be
- accepted; in fact, since the burst is 4, the first four
- packets will be accepted. After this, it will be 500ms (1
- second divided by the rate
- of 2) before a packet will be accepted from this rule,
- regardless of how many packets reach it. Also, every 500ms
- which passes without matching a packet, one of the bursts
- will be regained; if no packets hit the rule for 2 second,
- the burst will be fully recharged; back where we started.
-
-
- - Multiple chains may now be displayed in one "shorewall
- show" command (e.g., shorewall show INPUT FORWARD
- OUTPUT).
-
- - Output rules (those with $FW as the SOURCE) may now be
- limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html for
- details.
-
-
- 9/18/2003 - Shorewall 1.4.7 RC 1
-
-
- http://shorewall.net/pub/shorewall/Beta
-
- ftp://shorewall.net/pub/shorewall/Beta
-
- Problems Corrected since version 1.4.6 (Those in bold font
- were corrected since 1.4.7 Beta 1).
-
-
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
- variable was being tested before it was set.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
- - The "shorewall stop" command is now disabled when
- /etc/shorewall/startup_disabled exists. This prevents people
- from shooting themselves in the foot prior to having
- configured Shorewall.
-
- - A change introduced in version 1.4.6 caused error
- messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
- and ip addresses were being added to a PPP interface; the
- addresses were successfully added in spite of the
- messages.
-
- The firewall script has been modified to eliminate the error
- messages
-
- - Interface-specific dynamic blacklisting chains are now
- displayed by "shorewall monitor" on the "Dynamic Chains" page
- (previously named "Dynamic Chain").
-
- - Thanks to Henry Yang, LOGRATE and LOGBURST now work
- again.
-
- - The 'shorewall reject' and 'shorewall drop'
- commands now delete any existing rules for the subject IP
- address before adding a new DROP or REJECT rule. Previously,
- there could be many rules for the same IP address in the
- dynamic chain so that multiple 'allow' commands were required
- to re-enable traffic to/from the address.
-
- - When ADD_SNAT_ALIASES=Yes in shorewall.conf, the
- following entry in /etc/shorewall/masq resulted in a startup
- error:
-
- eth0 eth1
- 206.124.146.20-206.124.146.24
-
-
-
- - Shorewall previously choked over IPV6 addresses
- configured on interfaces in contexts where Shorewall needed
- to detect something about the interface (such as when
- "detect" appears in the BROADCAST column of the
- /etc/shorewall/interfaces file).
-
- - Shorewall will now load module files that are formed from
- the module name by appending ".o.gz".
-
- - When Shorewall adds a route to
- a proxy ARP host and such a route already exists, two routes
- resulted previously. This has been corrected so that the
- existing route is replaced if it already exists.
-
- - The rfc1918 file has
- been updated to reflect recent allocations.
-
-
- Migration Issues:
-
-
-
- - Shorewall IP Traffic Accounting has changed since
- snapshot 20030813 -- see the Accounting Page for details.
-
- - The Uset Set capability introduced in SnapShot 20030821
- has changed -- see the User Set
- page for details.
-
- - The per-interface Dynamic Blacklisting facility
- introduced in the first post-1.4.6 Snapshot has been removed.
- The facility had too many idiosyncrasies for dial-up users to
- be a viable part of Shorewall.
-
-
- New Features:
-
-
-
- - Thanks to Steve Herber, the 'help' command can now give
- command-specific help (e.g., shorewall help
- <command>).
-
- - A new option "ADMINISABSENTMINDED" has been added to
- /etc/shorewall/shorewall.conf. This option has a default
- value of "No" for existing users which causes Shorewall's
- 'stopped' state to continue as it has been; namely, in
- the stopped state only traffic to/from hosts listed in
- /etc/shorewall/routestopped is accepted.
-
- With ADMINISABSENTMINDED=Yes (the default for new installs),
- in addition to traffic to/from the hosts listed in
- /etc/shorewall/routestopped, Shorewall will allow:
-
- a) All traffic originating from the firewall
- itself; and
- b) All traffic that is part of or related to an
- already-existing connection.
-
- In particular, with ADMINISABSENTMINDED=Yes, a
- "shorewall stop" entered through an ssh session will not kill
- the session.
-
- Note though that even with ADMINISABSENTMINDED=Yes, it
- is still possible for people to shoot themselves in the
- foot.
-
- Example:
-
- /etc/shorewall/nat:
-
- 206.124.146.178
- eth0:0 192.168.1.5
-
- /etc/shorewall/rules:
-
- ACCEPT net
- loc:192.168.1.5 tcp
- 22
- ACCEPT loc
- fw tcp
- 22
-
- From a remote system, I ssh to 206.124.146.178 which
- establishes an SSH connection with local system 192.168.1.5.
- I then create a second SSH connection from that computer to
- the firewall and confidently type "shorewall stop". As part
- of its stop processing, Shorewall removes eth0:0 which kills
- my SSH connection to 192.168.1.5!!!
-
- - Given the wide range of VPN software, I can never hope to
- add specific support for all of it. I have therefore decided
- to add "generic" tunnel support.
-
- Generic tunnels work pretty much like any of the other
- tunnel types. You usually add a zone to represent the systems
- at the other end of the tunnel and you add the appropriate
- rules/policies to
- implement your security policy regarding traffic to/from
- those systems.
-
- In the /etc/shorewall/tunnels file, you can have entries of
- the form:
-
- generic:<protocol>[:<port>]
- <zone> <ip address>
- <gateway zones>
-
- where:
-
- <protocol> is the
- protocol used by the tunnel
- <port> if
- the protocol is 'udp' or 'tcp' then this is the destination
- port number used by the tunnel.
- <zone> is
- the zone of the remote tunnel gateway
- <ip address> is
- the IP address of the remote tunnel gateway.
- <gateway
- zone> Optional. A comma-separated list of zone
- names. If specified, the remote gateway is to be considered
- part of these zones.
-
- - An 'arp_filter' option has been added to the
- /etc/shorewall/interfaces file. This option causes
- /proc/sys/net/ipv4/conf/<interface>/arp_filter to be
- set with the result that this interface will only answer ARP
- 'who-has' requests from hosts that are routed out through
- that interface. Setting this option facilitates testing of
- your firewall where multiple firewall interfaces are
- connected to the same HUB/Switch (all interfaces connected to
- the single HUB/Switch should have this option specified).
- Note that using such a configuration in a production
- environment is strongly recommended against.
-
- - The ADDRESS column in /etc/shorewall/masq may now include
- a comma-separated list of addresses and/or address ranges.
- Netfilter will use all listed addresses/ranges in round-robin
- fashion. \
-
- - An /etc/shorewall/accounting file has been added to allow
- for traffic accounting. See the accounting documentation for a
- description of this facility.
-
- - Bridge interfaces (br[0-9]) may now be used in
- /etc/shorewall/maclist.
-
- - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
- /etc/shorewall/rules may now be rate-limited. For DNAT and
- REDIRECT rules, rate limiting occurs in the nat table DNAT
- rule; the corresponding ACCEPT rule in the filter table is
- not rate limited. If you want to limit the filter table rule,
- you will need o create two rules; a DNAT- rule and an ACCEPT
- rule which can be rate-limited separately.
-
- Warning: When rate
- limiting is specified on a rule with "all" in the SOURCE or
- DEST fields, the limit will apply to each pair of zones
- individually rather than as a single limit for all pairs of
- covered by the rule.
-
- To specify a rate limit,
-
- a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
-
- <
- <rate>/<interval>[:<burst>] >
-
- where
-
- <rate> is the sustained
- rate per <interval>
- <interval> is "sec" or
- "min"
- <burst> is the largest
- burst accepted within an <interval>. If not given, the
- default of 5 is assumed.
-
- There may be no white space between the ACTION and "<"
- nor there may be any white space within the burst
- specification. If you want to specify logging of a
- rate-limited rule, the ":" and log level comes after the
- ">" (e.g., ACCEPT<2/sec:4>:info ).
-
- b) A new RATE LIMIT column has been added to the
- /etc/shorewall/rules file. You may specify the rate limit
- there in the format:
-
-
- <rate>/<interval>[:<burst>]
-
- Let's take an example:
-
-
- ACCEPT<2/sec:4>
- net dmz
- tcp 80
-
- The first time this rule is reached, the packet will be
- accepted; in fact, since the burst is 4, the first four
- packets will be accepted. After this, it will be 500ms (1
- second divided by the rate
- of 2) before a packet will be accepted from this rule,
- regardless of how many packets reach it. Also, every 500ms
- which passes without matching a packet, one of the bursts
- will be regained; if no packets hit the rule for 2 second,
- the burst will be fully recharged; back where we started.
-
-
- - Multiple chains may now be displayed in one "shorewall
- show" command (e.g., shorewall show INPUT FORWARD
- OUTPUT).
-
- - Output rules (those with $FW as the SOURCE) may now be
- limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html for
- details.
-
-
- 9/15/2003 - Shorewall 1.4.7 Beta 2
-
-
- http://shorewall.net/pub/shorewall/Beta
-
- ftp://shorewall.net/pub/shorewall/Beta
-
- Problems Corrected since version 1.4.6 (Those in bold font
- were corrected since 1.4.7 Beta 1).
-
-
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
- variable was being tested before it was set.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
- - The "shorewall stop" command is now disabled when
- /etc/shorewall/startup_disabled exists. This prevents people
- from shooting themselves in the foot prior to having
- configured Shorewall.
-
- - A change introduced in version 1.4.6 caused error
- messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
- and ip addresses were being added to a PPP interface; the
- addresses were successfully added in spite of the
- messages.
-
- The firewall script has been modified to eliminate the error
- messages
-
- - Interface-specific dynamic blacklisting chains are now
- displayed by "shorewall monitor" on the "Dynamic Chains" page
- (previously named "Dynamic Chain").
-
- - Thanks to Henry Yang, LOGRATE and LOGBURST now work
- again.
-
- - The 'shorewall
- reject' and 'shorewall drop' commands now delete any existing
- rules for the subject IP address before adding a new DROP or
- REJECT rule. Previously, there could be many rules for the
- same IP address in the dynamic chain so that multiple 'allow'
- commands were required to re-enable traffic to/from the
- address.
-
- - When ADD_SNAT_ALIASES=Yes in
- shorewall.conf, the following entry in /etc/shorewall/masq
- resulted in a startup error:
-
- eth0 eth1
- 206.124.146.20-206.124.146.24
-
-
-
- - Shorewall previously choked
- over IPV6 addresses configured on interfaces in contexts
- where Shorewall needed to detect something about the
- interface (such as when "detect" appears in the BROADCAST
- column of the /etc/shorewall/interfaces file).
-
- - Shorewall will now load
- module files that are formed from the module name by
- appending ".o.gz".
-
-
- Migration Issues:
-
-
-
- - Shorewall IP Traffic Accounting has changed since
- snapshot 20030813 -- see the Accounting Page for details.
-
- - The Uset Set capability introduced in SnapShot 20030821
- has changed -- see the User Set
- page for details.
-
- - The per-interface Dynamic Blacklisting facility
- introduced in the first post-1.4.6 Snapshot has been removed.
- The facility had too many idiosyncrasies for dial-up users to
- be a viable part of Shorewall.
-
-
- New Features:
-
-
-
- - Thanks to Steve Herber, the 'help' command can now give
- command-specific help (e.g., shorewall help
- <command>).
-
- - A new option "ADMINISABSENTMINDED" has been added to
- /etc/shorewall/shorewall.conf. This option has a default
- value of "No" for existing users which causes Shorewall's
- 'stopped' state to continue as it has been; namely, in
- the stopped state only traffic to/from hosts listed in
- /etc/shorewall/routestopped is accepted.
-
- With ADMINISABSENTMINDED=Yes (the default for new installs),
- in addition to traffic to/from the hosts listed in
- /etc/shorewall/routestopped, Shorewall will allow:
-
- a) All traffic originating from the firewall
- itself; and
- b) All traffic that is part of or related to an
- already-existing connection.
-
- In particular, with ADMINISABSENTMINDED=Yes, a
- "shorewall stop" entered through an ssh session will not kill
- the session.
-
- Note though that even with ADMINISABSENTMINDED=Yes, it
- is still possible for people to shoot themselves in the
- foot.
-
- Example:
-
- /etc/shorewall/nat:
-
- 206.124.146.178
- eth0:0 192.168.1.5
-
- /etc/shorewall/rules:
-
- ACCEPT net
- loc:192.168.1.5 tcp
- 22
- ACCEPT loc
- fw tcp
- 22
-
- From a remote system, I ssh to 206.124.146.178 which
- establishes an SSH connection with local system 192.168.1.5.
- I then create a second SSH connection from that computer to
- the firewall and confidently type "shorewall stop". As part
- of its stop processing, Shorewall removes eth0:0 which kills
- my SSH connection to 192.168.1.5!!!
-
- - Given the wide range of VPN software, I can never hope to
- add specific support for all of it. I have therefore decided
- to add "generic" tunnel support.
-
- Generic tunnels work pretty much like any of the other
- tunnel types. You usually add a zone to represent the systems
- at the other end of the tunnel and you add the appropriate
- rules/policies to
- implement your security policy regarding traffic to/from
- those systems.
-
- In the /etc/shorewall/tunnels file, you can have entries of
- the form:
-
- generic:<protocol>[:<port>]
- <zone> <ip address>
- <gateway zones>
-
- where:
-
- <protocol> is the
- protocol used by the tunnel
- <port> if
- the protocol is 'udp' or 'tcp' then this is the destination
- port number used by the tunnel.
- <zone> is
- the zone of the remote tunnel gateway
- <ip address> is
- the IP address of the remote tunnel gateway.
- <gateway
- zone> Optional. A comma-separated list of zone
- names. If specified, the remote gateway is to be considered
- part of these zones.
-
- - An 'arp_filter' option has been added to the
- /etc/shorewall/interfaces file. This option causes
- /proc/sys/net/ipv4/conf/<interface>/arp_filter to be
- set with the result that this interface will only answer ARP
- 'who-has' requests from hosts that are routed out through
- that interface. Setting this option facilitates testing of
- your firewall where multiple firewall interfaces are
- connected to the same HUB/Switch (all interfaces connected to
- the single HUB/Switch should have this option specified).
- Note that using such a configuration in a production
- environment is strongly recommended against.
-
- - The ADDRESS column in /etc/shorewall/masq may now include
- a comma-separated list of addresses and/or address ranges.
- Netfilter will use all listed addresses/ranges in round-robin
- fashion. \
-
- - An /etc/shorewall/accounting file has been added to allow
- for traffic accounting. See the accounting documentation for a
- description of this facility.
-
- - Bridge interfaces (br[0-9]) may now be used in
- /etc/shorewall/maclist.
-
- - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
- /etc/shorewall/rules may now be rate-limited. For DNAT and
- REDIRECT rules, rate limiting occurs in the nat table DNAT
- rule; the corresponding ACCEPT rule in the filter table is
- not rate limited. If you want to limit the filter table rule,
- you will need o create two rules; a DNAT- rule and an ACCEPT
- rule which can be rate-limited separately.
-
- Warning: When rate
- limiting is specified on a rule with "all" in the SOURCE or
- DEST fields, the limit will apply to each pair of zones
- individually rather than as a single limit for all pairs of
- covered by the rule.
-
- To specify a rate limit,
-
- a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
-
- <
- <rate>/<interval>[:<burst>] >
-
- where
-
- <rate> is the sustained
- rate per <interval>
- <interval> is "sec" or
- "min"
- <burst> is the largest
- burst accepted within an <interval>. If not given, the
- default of 5 is assumed.
-
- There may be no white space between the ACTION and "<"
- nor there may be any white space within the burst
- specification. If you want to specify logging of a
- rate-limited rule, the ":" and log level comes after the
- ">" (e.g., ACCEPT<2/sec:4>:info ).
-
- b) A new RATE LIMIT column has been added to the
- /etc/shorewall/rules file. You may specify the rate limit
- there in the format:
-
-
- <rate>/<interval>[:<burst>]
-
- Let's take an example:
-
-
- ACCEPT<2/sec:4>
- net dmz
- tcp 80
-
- The first time this rule is reached, the packet will be
- accepted; in fact, since the burst is 4, the first four
- packets will be accepted. After this, it will be 500ms (1
- second divided by the rate
- of 2) before a packet will be accepted from this rule,
- regardless of how many packets reach it. Also, every 500ms
- which passes without matching a packet, one of the bursts
- will be regained; if no packets hit the rule for 2 second,
- the burst will be fully recharged; back where we started.
-
-
- - Multiple chains may now be displayed in one "shorewall
- show" command (e.g., shorewall show INPUT FORWARD
- OUTPUT).
-
- - Output rules (those with $FW as the SOURCE) may now be
- limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html for
- details.
-
-
- 8/27/2003 - Shorewall Mirror in Australia
-
- Thanks to Dave Kempe and Solutions First (http://www.solutionsfirst.com.au), there is now
- a Shorewall Mirror in Australia:
-
-
-
- 8/26/2003 - French Version of the Shorewall Setup
- Guide
- Thanks to Fabien Demassieux, there is now a French translation of the
- Shorewall Setup Guide. Merci Beacoup, Fabien!
-
- 8/25/2003 - Shorewall 1.4.7 Beta 1
-
-
- http://shorewall.net/pub/shorewall/Beta
-
- ftp://shorewall.net/pub/shorewall/Beta
-
- Problems Corrected since version 1.4.6
-
-
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
- variable was being tested before it was set.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
- - The "shorewall stop" command is now disabled when
- /etc/shorewall/startup_disabled exists. This prevents people
- from shooting themselves in the foot prior to having
- configured Shorewall.
-
- - A change introduced in version 1.4.6 caused error
- messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
- and ip addresses were being added to a PPP interface; the
- addresses were successfully added in spite of the
- messages.
-
- The firewall script has been modified to eliminate the error
- messages
-
- - Interface-specific dynamic blacklisting chains are now
- displayed by "shorewall monitor" on the "Dynamic Chains" page
- (previously named "Dynamic Chain").
-
- - Thanks to Henry Yang, LOGRATE and LOGBURST now work
- again.
-
-
-
- Migration Issues:
-
-
-
- - Shorewall IP Traffic Accounting has changed since
- snapshot 20030813 -- see the Accounting Page for details.
-
- - The Uset Set capability introduced in SnapShot 20030821
- has changed -- see the User Set
- page for details.
-
- - The per-interface Dynamic Blacklisting facility
- introduced in the first post-1.4.6 Snapshot has been removed.
- The facility had too many idiosyncrasies for dial-up users to
- be a viable part of Shorewall.
-
-
- New Features:
-
-
-
- - Thanks to Steve Herber, the 'help' command can now give
- command-specific help (e.g., shorewall help
- <command>).
-
- - A new option "ADMINISABSENTMINDED" has been added to
- /etc/shorewall/shorewall.conf. This option has a default
- value of "No" for existing users which causes Shorewall's
- 'stopped' state to continue as it has been; namely, in
- the stopped state only traffic to/from hosts listed in
- /etc/shorewall/routestopped is accepted.
-
- With ADMINISABSENTMINDED=Yes (the default for new installs),
- in addition to traffic to/from the hosts listed in
- /etc/shorewall/routestopped, Shorewall will allow:
-
- a) All traffic originating from the firewall
- itself; and
- b) All traffic that is part of or related to an
- already-existing connection.
-
- In particular, with ADMINISABSENTMINDED=Yes, a
- "shorewall stop" entered through an ssh session will not kill
- the session.
-
- Note though that even with ADMINISABSENTMINDED=Yes, it
- is still possible for people to shoot themselves in the
- foot.
-
- Example:
-
- /etc/shorewall/nat:
-
- 206.124.146.178
- eth0:0 192.168.1.5
-
- /etc/shorewall/rules:
-
- ACCEPT net
- loc:192.168.1.5 tcp
- 22
- ACCEPT loc
- fw tcp
- 22
-
- From a remote system, I ssh to 206.124.146.178 which
- establishes an SSH connection with local system 192.168.1.5.
- I then create a second SSH connection from that computer to
- the firewall and confidently type "shorewall stop". As part
- of its stop processing, Shorewall removes eth0:0 which kills
- my SSH connection to 192.168.1.5!!!
-
- - Given the wide range of VPN software, I can never hope to
- add specific support for all of it. I have therefore decided
- to add "generic" tunnel support.
-
- Generic tunnels work pretty much like any of the other
- tunnel types. You usually add a zone to represent the systems
- at the other end of the tunnel and you add the appropriate
- rules/policies to
- implement your security policy regarding traffic to/from
- those systems.
-
- In the /etc/shorewall/tunnels file, you can have entries of
- the form:
-
- generic:<protocol>[:<port>]
- <zone> <ip address>
- <gateway zones>
-
- where:
-
- <protocol> is the
- protocol used by the tunnel
- <port> if
- the protocol is 'udp' or 'tcp' then this is the destination
- port number used by the tunnel.
- <zone> is
- the zone of the remote tunnel gateway
- <ip address> is
- the IP address of the remote tunnel gateway.
- <gateway
- zone> Optional. A comma-separated list of zone
- names. If specified, the remote gateway is to be considered
- part of these zones.
-
- - An 'arp_filter' option has been added to the
- /etc/shorewall/interfaces file. This option causes
- /proc/sys/net/ipv4/conf/<interface>/arp_filter to be
- set with the result that this interface will only answer ARP
- 'who-has' requests from hosts that are routed out through
- that interface. Setting this option facilitates testing of
- your firewall where multiple firewall interfaces are
- connected to the same HUB/Switch (all interfaces connected to
- the single HUB/Switch should have this option specified).
- Note that using such a configuration in a production
- environment is strongly recommended against.
-
- - The ADDRESS column in /etc/shorewall/masq may now include
- a comma-separated list of addresses and/or address ranges.
- Netfilter will use all listed addresses/ranges in round-robin
- fashion. \
-
- - An /etc/shorewall/accounting file has been added to allow
- for traffic accounting. See the accounting documentation for a
- description of this facility.
-
- - Bridge interfaces (br[0-9]) may now be used in
- /etc/shorewall/maclist.
-
- - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
- /etc/shorewall/rules may now be rate-limited. For DNAT and
- REDIRECT rules, rate limiting occurs in the nat table DNAT
- rule; the corresponding ACCEPT rule in the filter table is
- not rate limited. If you want to limit the filter table rule,
- you will need o create two rules; a DNAT- rule and an ACCEPT
- rule which can be rate-limited separately.
-
- Warning: When rate
- limiting is specified on a rule with "all" in the SOURCE or
- DEST fields, the limit will apply to each pair of zones
- individually rather than as a single limit for all pairs of
- covered by the rule.
-
- To specify a rate limit,
-
- a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
-
- <
- <rate>/<interval>[:<burst>] >
-
- where
-
- <rate> is the sustained
- rate per <interval>
- <interval> is "sec" or
- "min"
- <burst> is the largest
- burst accepted within an <interval>. If not given, the
- default of 5 is assumed.
-
- There may be no white space between the ACTION and "<"
- nor there may be any white space within the burst
- specification. If you want to specify logging of a
- rate-limited rule, the ":" and log level comes after the
- ">" (e.g., ACCEPT<2/sec:4>:info ).
-
- b) A new RATE LIMIT column has been added to the
- /etc/shorewall/rules file. You may specify the rate limit
- there in the format:
-
-
- <rate>/<interval>[:<burst>]
-
- Let's take an example:
-
-
- ACCEPT<2/sec:4>
- net dmz
- tcp 80
-
- The first time this rule is reached, the packet will be
- accepted; in fact, since the burst is 4, the first four
- packets will be accepted. After this, it will be 500ms (1
- second divided by the rate
- of 2) before a packet will be accepted from this rule,
- regardless of how many packets reach it. Also, every 500ms
- which passes without matching a packet, one of the bursts
- will be regained; if no packets hit the rule for 2 second,
- the burst will be fully recharged; back where we started.
-
-
- - Multiple chains may now be displayed in one "shorewall
- show" command (e.g., shorewall show INPUT FORWARD
- OUTPUT).
-
- - Output rules (those with $FW as the SOURCE) may now be
- limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html for
- details.
-
-
-
- 8/23/2003 - Snapshot 1.4.6_20030823
-
-
- http://shorewall.net/pub/shorewall/Snapshots/
-
- ftp://shorewall.net/pub/shorewall/Snapshots/
-
- Problems Corrected since version 1.4.6
-
-
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
- variable was being tested before it was set.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
- - The "shorewall stop" command is now disabled when
- /etc/shorewall/startup_disabled exists. This prevents people
- from shooting themselves in the foot prior to having
- configured Shorewall.
-
- - A change introduced in version 1.4.6 caused error
- messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
- and ip addresses were being added to a PPP interface; the
- addresses were successfully added in spite of the
- messages.
-
- The firewall script has been modified to eliminate the error
- messages
-
- - Interface-specific dynamic blacklisting chains are now
- displayed by "shorewall monitor" on the "Dynamic Chains" page
- (previously named "Dynamic Chain").
-
- - Thanks to Henry Yang, LOGRATE and LOGBURST now work
- again.
-
-
-
- Migration Issues:
-
-
-
- - Once you have installed this version of Shorewall, you
- must restart Shorewall before you may use the 'drop',
- 'reject', 'allow' or 'save' commands.
-
- - To maintain strict compatibility with previous versions,
- current uses of "shorewall drop" and "shorewall reject"
- should be replaced with "shorewall dropall" and "shorewall
- rejectall"
-
- - Shorewall IP Traffic Accounting has changed since
- snapshot 20030813 -- see the Accounting Page for details.
-
- - The Uset Set capability introduced in SnapShot 20030821
- has changed -- see the User Set
- page for details.
-
- New Features:
-
-
-
- - Shorewall now creates a dynamic blacklisting chain for
- each interface defined in /etc/shorewall/interfaces. The
- 'drop' and 'reject' commands use the routing table to
- determine which of these chains is to be used for
- blacklisting the specified IP address(es).
-
- Two new commands ('dropall' and 'rejectall') have been
- introduced that do what 'drop' and 'reject' used to do;
- namely, when an address is blacklisted using these new
- commands, it will be blacklisted on all of your firewall's
- interfaces.
-
- - Thanks to Steve Herber, the 'help' command can now give
- command-specific help (e.g., shorewall help
- <command>).
-
- - A new option "ADMINISABSENTMINDED" has been added to
- /etc/shorewall/shorewall.conf. This option has a default
- value of "No" for existing users which causes Shorewall's
- 'stopped' state to continue as it has been; namely, in
- the stopped state only traffic to/from hosts listed in
- /etc/shorewall/routestopped is accepted.
-
- With ADMINISABSENTMINDED=Yes (the default for new installs),
- in addition to traffic to/from the hosts listed in
- /etc/shorewall/routestopped, Shorewall will allow:
-
- a) All traffic originating from the firewall
- itself; and
- b) All traffic that is part of or related to an
- already-existing connection.
-
- In particular, with ADMINISABSENTMINDED=Yes, a
- "shorewall stop" entered through an ssh session will not kill
- the session.
-
- Note though that even with ADMINISABSENTMINDED=Yes, it
- is still possible for people to shoot themselves in the
- foot.
-
- Example:
-
- /etc/shorewall/nat:
-
- 206.124.146.178
- eth0:0 192.168.1.5
-
- /etc/shorewall/rules:
-
- ACCEPT net
- loc:192.168.1.5 tcp
- 22
- ACCEPT loc
- fw tcp
- 22
-
- From a remote system, I ssh to 206.124.146.178 which
- establishes an SSH connection with local system 192.168.1.5.
- I then create a second SSH connection from that computer to
- the firewall and confidently type "shorewall stop". As part
- of its stop processing, Shorewall removes eth0:0 which kills
- my SSH connection to 192.168.1.5!!!
-
- - Given the wide range of VPN software, I can never hope to
- add specific support for all of it. I have therefore decided
- to add "generic" tunnel support.
-
- Generic tunnels work pretty much like any of the other
- tunnel types. You usually add a zone to represent the systems
- at the other end of the tunnel and you add the appropriate
- rules/policies to
- implement your security policy regarding traffic to/from
- those systems.
-
- In the /etc/shorewall/tunnels file, you can have entries of
- the form:
-
- generic:<protocol>[:<port>]
- <zone> <ip address>
- <gateway zones>
-
- where:
-
- <protocol> is the
- protocol used by the tunnel
- <port> if
- the protocol is 'udp' or 'tcp' then this is the destination
- port number used by the tunnel.
- <zone> is
- the zone of the remote tunnel gateway
- <ip address> is
- the IP address of the remote tunnel gateway.
- <gateway
- zone> Optional. A comma-separated list of zone
- names. If specified, the remote gateway is to be considered
- part of these zones.
-
- - An 'arp_filter' option has been added to the
- /etc/shorewall/interfaces file. This option causes
- /proc/sys/net/ipv4/conf/<interface>/arp_filter to be
- set with the result that this interface will only answer ARP
- 'who-has' requests from hosts that are routed out through
- that interface. Setting this option facilitates testing of
- your firewall where multiple firewall interfaces are
- connected to the same HUB/Switch (all interfaces connected to
- the single HUB/Switch should have this option specified).
- Note that using such a configuration in a production
- environment is strongly recommended against.
-
- - The ADDRESS column in /etc/shorewall/masq may now include
- a comma-separated list of addresses and/or address ranges.
- Netfilter will use all listed addresses/ranges in round-robin
- fashion. \
-
- - An /etc/shorewall/accounting file has been added to allow
- for traffic accounting. See the accounting documentation for a
- description of this facility.
-
- - Bridge interfaces (br[0-9]) may now be used in
- /etc/shorewall/maclist.
-
- - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
- /etc/shorewall/rules may now be rate-limited. For DNAT and
- REDIRECT rules, rate limiting occurs in the nat table DNAT
- rule; the corresponding ACCEPT rule in the filter table is
- not rate limited. If you want to limit the filter table rule,
- you will need o create two rules; a DNAT- rule and an ACCEPT
- rule which can be rate-limited separately.
-
- Warning: When rate
- limiting is specified on a rule with "all" in the SOURCE or
- DEST fields, the limit will apply to each pair of zones
- individually rather than as a single limit for all pairs of
- covered by the rule.
-
- To specify a rate limit,
-
- a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
-
- <
- <rate>/<interval>[:<burst>] >
-
- where
-
- <rate> is the sustained
- rate per <interval>
- <interval> is "sec" or
- "min"
- <burst> is the largest
- burst accepted within an <interval>. If not given, the
- default of 5 is assumed.
-
- There may be no white space between the ACTION and "<"
- nor there may be any white space within the burst
- specification. If you want to specify logging of a
- rate-limited rule, the ":" and log level comes after the
- ">" (e.g., ACCEPT<2/sec:4>:info ).
-
- b) A new RATE LIMIT column has been added to the
- /etc/shorewall/rules file. You may specify the rate limit
- there in the format:
-
-
- <rate>/<interval>[:<burst>]
-
- Let's take an example:
-
-
- ACCEPT<2/sec:4>
- net dmz
- tcp 80
-
- The first time this rule is reached, the packet will be
- accepted; in fact, since the burst is 4, the first four
- packets will be accepted. After this, it will be 500ms (1
- second divided by the rate
- of 2) before a packet will be accepted from this rule,
- regardless of how many packets reach it. Also, every 500ms
- which passes without matching a packet, one of the bursts
- will be regained; if no packets hit the rule for 2 second,
- the burst will be fully recharged; back where we started.
-
-
- - Multiple chains may now be displayed in one "shorewall
- show" command (e.g., shorewall show INPUT FORWARD
- OUTPUT).
-
- - Output rules (those with $FW as the SOURCE) may now be
- limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html for
- details.
-
-
-
- 8/13/2003 - Snapshot 1.4.6_20030813
-
-
- http://shorewall.net/pub/shorewall/Snapshots/
-
- ftp://shorewall.net/pub/shorewall/Snapshots/
-
- Problems Corrected since version 1.4.6
-
-
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
- variable was being tested before it was set.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
- - The "shorewall stop" command is now disabled when
- /etc/shorewall/startup_disabled exists. This prevents people
- from shooting themselves in the foot prior to having
- configured Shorewall.
-
- - A change introduced in version 1.4.6 caused error
- messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
- and ip addresses were being added to a PPP interface; the
- addresses were successfully added in spite of the
- messages.
-
- The firewall script has been modified to eliminate the error
- messages
-
- - Interface-specific dynamic blacklisting chains are
- now displayed by "shorewall monitor" on the "Dynamic Chains"
- page (previously named "Dynamic Chain").
-
-
-
- Migration Issues:
-
-
-
- - Once you have installed this version of Shorewall, you
- must restart Shorewall before you may use the 'drop',
- 'reject', 'allow' or 'save' commands.
-
- - To maintain strict compatibility with previous versions,
- current uses of "shorewall drop" and "shorewall reject"
- should be replaced with "shorewall dropall" and "shorewall
- rejectall"
-
- New Features:
-
-
-
- - Shorewall now creates a dynamic blacklisting chain for
- each interface defined in /etc/shorewall/interfaces. The
- 'drop' and 'reject' commands use the routing table to
- determine which of these chains is to be used for
- blacklisting the specified IP address(es).
-
- Two new commands ('dropall' and 'rejectall') have been
- introduced that do what 'drop' and 'reject' used to do;
- namely, when an address is blacklisted using these new
- commands, it will be blacklisted on all of your firewall's
- interfaces.
-
- - Thanks to Steve Herber, the 'help' command can now give
- command-specific help (e.g., shorewall help
- <command>).
-
- - A new option "ADMINISABSENTMINDED" has been added to
- /etc/shorewall/shorewall.conf. This option has a default
- value of "No" for existing users which causes Shorewall's
- 'stopped' state to continue as it has been; namely, in
- the stopped state only traffic to/from hosts listed in
- /etc/shorewall/routestopped is accepted.
-
- With ADMINISABSENTMINDED=Yes (the default for new installs),
- in addition to traffic to/from the hosts listed in
- /etc/shorewall/routestopped, Shorewall will allow:
-
- a) All traffic originating from the firewall
- itself; and
- b) All traffic that is part of or related to an
- already-existing connection.
-
- In particular, with ADMINISABSENTMINDED=Yes, a
- "shorewall stop" entered through an ssh session will not kill
- the session.
-
- Note though that even with ADMINISABSENTMINDED=Yes, it
- is still possible for people to shoot themselves in the
- foot.
-
- Example:
-
- /etc/shorewall/nat:
-
- 206.124.146.178
- eth0:0 192.168.1.5
-
- /etc/shorewall/rules:
-
- ACCEPT net
- loc:192.168.1.5 tcp
- 22
- ACCEPT loc
- fw tcp
- 22
-
- From a remote system, I ssh to 206.124.146.178 which
- establishes an SSH connection with local system 192.168.1.5.
- I then create a second SSH connection from that computer to
- the firewall and confidently type "shorewall stop". As part
- of its stop processing, Shorewall removes eth0:0 which kills
- my SSH connection to 192.168.1.5!!!
-
- - Given the wide range of VPN software, I can never hope to
- add specific support for all of it. I have therefore decided
- to add "generic" tunnel support.
-
- Generic tunnels work pretty much like any of the other
- tunnel types. You usually add a zone to represent the systems
- at the other end of the tunnel and you add the appropriate
- rules/policies to
- implement your security policy regarding traffic to/from
- those systems.
-
- In the /etc/shorewall/tunnels file, you can have entries of
- the form:
-
- generic:<protocol>[:<port>]
- <zone> <ip address>
- <gateway zones>
-
- where:
-
- <protocol> is the
- protocol used by the tunnel
- <port> if
- the protocol is 'udp' or 'tcp' then this is the destination
- port number used by the tunnel.
- <zone> is
- the zone of the remote tunnel gateway
- <ip address> is
- the IP address of the remote tunnel gateway.
- <gateway
- zone> Optional. A comma-separated list of zone
- names. If specified, the remote gateway is to be considered
- part of these zones.
-
- - An 'arp_filter' option has been added to the
- /etc/shorewall/interfaces file. This option causes
- /proc/sys/net/ipv4/conf/<interface>/arp_filter to be
- set with the result that this interface will only answer ARP
- 'who-has' requests from hosts that are routed out through
- that interface. Setting this option facilitates testing of
- your firewall where multiple firewall interfaces are
- connected to the same HUB/Switch (all interfaces connected to
- the single HUB/Switch should have this option specified).
- Note that using such a configuration in a production
- environment is strongly recommended against.
-
- - The ADDRESS column in /etc/shorewall/masq may now include
- a comma-separated list of addresses and/or address ranges.
- Netfilter will use all listed addresses/ranges in round-robin
- fashion. \
-
- - An /etc/shorewall/accounting file has been added to allow
- for traffic accounting. See the accounting documentation for a
- description of this facility.
-
- - Bridge interfaces (br[0-9]) may now be used in
- /etc/shorewall/maclist.
-
- - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
- /etc/shorewall/rules may now be rate-limited. For DNAT and
- REDIRECT rules, rate limiting occurs in the nat table DNAT
- rule; the corresponding ACCEPT rule in the filter table is
- not rate limited. If you want to limit the filter table rule,
- you will need o create two rules; a DNAT- rule and an ACCEPT
- rule which can be rate-limited separately.
-
- Warning: When rate
- limiting is specified on a rule with "all" in the SOURCE or
- DEST fields, the limit will apply to each pair of zones
- individually rather than as a single limit for all pairs of
- covered by the rule.
-
- To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-]
- or LOG with
-
- <
- <rate>/<interval>[:<burst>] >
-
- where
-
- <rate> is the sustained
- rate per <interval>
- <interval> is "sec" or
- "min"
- <burst> is the largest
- burst accepted within an <interval>. If not given, the
- default of 5 is assumed.
-
- There may be no white space between the ACTION and "<"
- nor there may be any white space within the burst
- specification. If you want to specify logging of a
- rate-limited rule, the ":" and log level comes after the
- ">" (e.g., ACCEPT<2/sec:4>:info ).
-
- Let's take an example:
-
-
- ACCEPT<2/sec:4>
- net dmz
- tcp 80
-
- The first time this rule is reached, the packet will be
- accepted; in fact, since the burst is 4, the first four
- packets will be accepted. After this, it will be 500ms (1
- second divided by the rate
- of 2) before a packet will be accepted from this rule,
- regardless of how many packets reach it. Also, every 500ms
- which passes without matching a packet, one of the bursts
- will be regained; if no packets hit the rule for 2 second,
- the burst will be fully recharged; back where we started.
-
-
-
- 8/9/2003 - Snapshot 1.4.6_20030809
-
-
- http://shorewall.net/pub/shorewall/Snapshots/
-
- ftp://shorewall.net/pub/shorewall/Snapshots/
-
- Problems Corrected since version 1.4.6
-
-
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
- variable was being tested before it was set.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
- - The "shorewall stop" command is now disabled when
- /etc/shorewall/startup_disabled exists. This prevents people
- from shooting themselves in the foot prior to having
- configured Shorewall.
-
- - A change introduced in version 1.4.6 caused error
- messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
- and ip addresses were being added to a PPP interface; the
- addresses were successfully added in spite of the
- messages.
-
- The firewall script has been modified to eliminate the error
- messages
-
-
- Migration Issues:
-
-
-
- - Once you have installed this version of Shorewall, you
- must restart Shorewall before you may use the 'drop',
- 'reject', 'allow' or 'save' commands.
-
- - To maintain strict compatibility with previous versions,
- current uses of "shorewall drop" and "shorewall reject"
- should be replaced with "shorewall dropall" and "shorewall
- rejectall"
-
- New Features:
-
-
-
- - Shorewall now creates a dynamic blacklisting chain for
- each interface defined in /etc/shorewall/interfaces. The
- 'drop' and 'reject' commands use the routing table to
- determine which of these chains is to be used for
- blacklisting the specified IP address(es).
-
- Two new commands ('dropall' and 'rejectall') have been
- introduced that do what 'drop' and 'reject' used to do;
- namely, when an address is blacklisted using these new
- commands, it will be blacklisted on all of your firewall's
- interfaces.
-
- - Thanks to Steve Herber, the 'help' command can now give
- command-specific help (e.g., shorewall help
- <command>).
-
- - A new option "ADMINISABSENTMINDED" has been added to
- /etc/shorewall/shorewall.conf. This option has a default
- value of "No" for existing users which causes Shorewall's
- 'stopped' state to continue as it has been; namely, in
- the stopped state only traffic to/from hosts listed in
- /etc/shorewall/routestopped is accepted.
-
- With ADMINISABSENTMINDED=Yes (the default for new installs),
- in addition to traffic to/from the hosts listed in
- /etc/shorewall/routestopped, Shorewall will allow:
-
- a) All traffic originating from the firewall
- itself; and
- b) All traffic that is part of or related to an
- already-existing connection.
-
- In particular, with ADMINISABSENTMINDED=Yes, a
- "shorewall stop" entered through an ssh session will not kill
- the session.
-
- Note though that even with ADMINISABSENTMINDED=Yes, it
- is still possible for people to shoot themselves in the
- foot.
-
- Example:
-
- /etc/shorewall/nat:
-
- 206.124.146.178
- eth0:0 192.168.1.5
-
- /etc/shorewall/rules:
-
- ACCEPT net
- loc:192.168.1.5 tcp
- 22
- ACCEPT loc
- fw tcp
- 22
-
- From a remote system, I ssh to 206.124.146.178 which
- establishes an SSH connection with local system 192.168.1.5.
- I then create a second SSH connection from that computer to
- the firewall and confidently type "shorewall stop". As part
- of its stop processing, Shorewall removes eth0:0 which kills
- my SSH connection to 192.168.1.5!!!
-
- - Given the wide range of VPN software, I can never hope to
- add specific support for all of it. I have therefore decided
- to add "generic" tunnel support.
-
- Generic tunnels work pretty much like any of the other
- tunnel types. You usually add a zone to represent the systems
- at the other end of the tunnel and you add the appropriate
- rules/policies to
- implement your security policy regarding traffic to/from
- those systems.
-
- In the /etc/shorewall/tunnels file, you can have entries of
- the form:
-
- generic:<protocol>[:<port>]
- <zone> <ip address>
- <gateway zones>
-
- where:
-
- <protocol> is the
- protocol used by the tunnel
- <port> if
- the protocol is 'udp' or 'tcp' then this is the destination
- port number used by the tunnel.
- <zone> is
- the zone of the remote tunnel gateway
- <ip address> is
- the IP address of the remote tunnel gateway.
- <gateway
- zone> Optional. A comma-separated list of zone
- names. If specified, the remote gateway is to be considered
- part of these zones.
-
- - An 'arp_filter' option has been added to the
- /etc/shorewall/interfaces file. This option causes
- /proc/sys/net/ipv4/conf/<interface>/arp_filter to be
- set with the result that this interface will only answer ARP
- 'who-has' requests from hosts that are routed out through
- that interface. Setting this option facilitates testing of
- your firewall where multiple firewall interfaces are
- connected to the same HUB/Switch (all interfaces connected to
- the single HUB/Switch should have this option specified).
- Note that using such a configuration in a production
- environment is strongly recommended against.
-
-
-
- 8/5/2003 - Shorewall-1.4.6b
-
- Problems Corrected since version 1.4.6:
-
-
-
- - Previously, if TC_ENABLED is set to yes in shorewall.conf
- then Shorewall would fail to start with the error "ERROR:
- Traffic Control requires Mangle"; that problem has been
- corrected.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
- - The "shorewall stop" command is now disabled when
- /etc/shorewall/startup_disabled exists. This prevents people
- from shooting themselves in the foot prior to having
- configured Shorewall.
-
- - A change introduced in version 1.4.6 caused error
- messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
- and ip addresses were being added to a PPP interface; the
- addresses were successfully added in spite of the
- messages.
-
- The firewall script has been modified to eliminate the error
- messages.
-
-
- 8/5/2003 - Shorewall-1.4.6b
-
- Problems Corrected since version 1.4.6:
-
-
-
- - Previously, if TC_ENABLED is set to yes in shorewall.conf
- then Shorewall would fail to start with the error "ERROR:
- Traffic Control requires Mangle"; that problem has been
- corrected.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
- - The "shorewall stop" command is now disabled when
- /etc/shorewall/startup_disabled exists. This prevents people
- from shooting themselves in the foot prior to having
- configured Shorewall.
-
- - A change introduced in version 1.4.6 caused error
- messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
- and ip addresses were being added to a PPP interface; the
- addresses were successfully added in spite of the
- messages.
-
- The firewall script has been modified to eliminate the error
- messages.
-
-
-
- 7/31/2003 - Snapshot 1.4.6_20030731
-
-
- http://shorewall.net/pub/shorewall/Snapshots/
-
- ftp://shorewall.net/pub/shorewall/Snapshots/
-
-
- Problems Corrected since version 1.4.6:
-
-
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
- variable was being tested before it was set.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
-
-
- Migration Issues:
-
-
-
- - Once you have installed this version of Shorewall, you
- must restart Shorewall before you may use the 'drop',
- 'reject', 'allow' or 'save' commands.
-
- - To maintain strict compatibility with previous versions,
- current uses of "shorewall drop" and "shorewall reject"
- should be replaced with "shorewall dropall" and "shorewall
- rejectall"
-
-
- New Features:
-
-
-
- - Shorewall now creates a dynamic blacklisting chain for
- each interface defined in /etc/shorewall/interfaces. The
- 'drop' and 'reject' commands use the routing table to
- determine which of these chains is to be used for
- blacklisting the specified IP address(es).
-
- Two new commands ('dropall' and 'rejectall') have been
- introduced that do what 'drop' and 'reject' used to do;
- namely, when an address is blacklisted using these new
- commands, it will be blacklisted on all of your firewall's
- interfaces.
-
- - Thanks to Steve Herber, the 'help' command can now give
- command-specific help (e.g., shorewall help
- <command>).
-
- - A new option "ADMINISABSENTMINDED" has been added to
- /etc/shorewall/shorewall.conf. This option has a default
- value of "No" for existing users which causes Shorewall's
- 'stopped' state to continue as it has been; namely, in
- the stopped state only traffic to/from hosts listed in
- /etc/shorewall/routestopped is accepted.
-
- With ADMINISABSENTMINDED=Yes (the default for new installs),
- in addition to traffic to/from the hosts listed in
- /etc/shorewall/routestopped, Shorewall will allow:
-
- a) All traffic originating from the firewall
- itself; and
- b) All traffic that is part of or related to an
- already-existing connection.
-
- In particular, with ADMINISABSENTMINDED=Yes, a
- "shorewall stop" entered through an ssh session will not kill
- the session.
-
- Note though that even with ADMINISABSENTMINDED=Yes, it
- is still possible for people to shoot themselves in the
- foot.
-
- Example:
-
- /etc/shorewall/nat:
-
- 206.124.146.178
- eth0:0 192.168.1.5
-
- /etc/shorewall/rules:
-
- ACCEPT net
- loc:192.168.1.5 tcp
- 22
- ACCEPT loc
- fw tcp
- 22
-
- From a remote system, I ssh to 206.124.146.178 which
- establishes an SSH connection with local system 192.168.1.5.
- I then create a second SSH connection from that computer to
- the firewall and confidently type "shorewall stop". As part
- of its stop processing, Shorewall removes eth0:0 which kills
- my SSH connection to 192.168.1.5!!!
-
-
- 7/27/2003 - Snapshot 1.4.6_20030727
-
-
- http://shorewall.net/pub/shorewall/Snapshots/
-
- ftp://shorewall.net/pub/shorewall/Snapshots/
-
- Problems Corrected since version 1.4.6
-
-
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
- variable was being tested before it was set.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
-
- Migration Issues:
-
-
-
- - Once you have installed this version of Shorewall, you
- must restart Shorewall before you may use the 'drop',
- 'reject', 'allow' or 'save' commands.
-
- - To maintain strict compatibility with previous versions,
- current uses of "shorewall drop" and "shorewall reject"
- should be replaced with "shorewall dropall" and "shorewall
- rejectall"
-
- New Features:
-
-
-
- - Shorewall now creates a dynamic blacklisting chain for
- each interface defined in /etc/shorewall/interfaces. The
- 'drop' and 'reject' commands use the routing table to
- determine which of these chains is to be used for
- blacklisting the specified IP address(es).
-
- Two new commands ('dropall' and 'rejectall') have been
- introduced that do what 'drop' and 'reject' used to do;
- namely, when an address is blacklisted using these new
- commands, it will be blacklisted on all of your firewall's
- interfaces.
-
- - Thanks to Steve Herber, the 'help' command can now give
- command-specific help (e.g., shorewall help
- <command>).
-
-
-
- 7/26/2003 - Snapshot 1.4.6_20030726
-
-
- http://shorewall.net/pub/shorewall/Snapshots/
-
- ftp://shorewall.net/pub/shorewall/Snapshots/
-
-
- Problems Corrected since version 1.4.6:
-
-
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
- variable was being tested before it was set.
-
- - Corrected handling of MAC addresses in the SOURCE column
- of the tcrules file. Previously, these addresses resulted in
- an invalid iptables command.
-
-
-
- Migration Issues:
-
-
-
- - Once you have installed this version of Shorewall, you
- must restart Shorewall before you may use the 'drop',
- 'reject', 'allow' or 'save' commands.
-
- - To maintain strict compatibility with previous versions,
- current uses of "shorewall drop" and "shorewall reject"
- should be replaced with "shorewall dropall" and "shorewall
- rejectall"
-
-
- New Features:
-
- Shorewall now creates a dynamic blacklisting chain for each
- interface defined in /etc/shorewall/interfaces. The 'drop' and
- 'reject' commands use the routing table to determine which of
- these chains is to be used for blacklisting the specified IP
- address(es).
-
- Two new commands ('dropall' and 'rejectall') have been
- introduced that do what 'drop' and 'reject' used to do; namely,
- when an address is blacklisted using these new commands, it
- will be blacklisted on all of your firewall's interfaces.
-
- 7/22/2003 - Shorewall-1.4.6a
-
- Problems Corrected:
-
-
-
- - Previously, if TC_ENABLED is set to yes in shorewall.conf
- then Shorewall would fail to start with the error "ERROR:
- Traffic Control requires Mangle"; that problem has been
- corrected.
-
-
- 7/20/2003 - Shorewall-1.4.6
-
-
- Problems Corrected:
-
-
-
- - A problem seen on RH7.3 systems where Shorewall
- encountered start errors when started using the "service"
- mechanism has been worked around.
-
-
-
- - Where a list of IP addresses appears in the DEST column
- of a DNAT[-] rule, Shorewall incorrectly created multiple
- DNAT rules in the nat table (one for each element in the
- list). Shorewall now correctly creates a single DNAT rule
- with multiple "--to-destination" clauses.
-
-
-
- - Corrected a problem in Beta 1 where DNS names containing
- a "-" were mis-handled when they appeared in the DEST column
- of a rule.
-
-
-
- - A number of problems with rule parsing have been
- corrected. Corrections involve the handling of "z1!z2" in the
- SOURCE column as well as lists in the ORIGINAL DESTINATION
- column.
-
-
-
- - The message "Adding rules for DHCP" is now suppressed if
- there are no DHCP rules to add.
-
-
-
- Migration Issues:
-
-
-
- - In earlier versions, an undocumented feature allowed
- entries in the host file as follows:
-
- z
- eth1:192.168.1.0/24,eth2:192.168.2.0/24
-
- This capability was never documented and has been removed in
- 1.4.6 to allow entries of the following format:
-
- z
- eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
- - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options
- have been removed from /etc/shorewall/shorewall.conf. These
- capabilities are now automatically detected by Shorewall (see
- below).
-
-
-
- New Features:
-
-
-
- - A 'newnotsyn' interface option has been added. This
- option may be specified in /etc/shorewall/interfaces and
- overrides the setting NEWNOTSYN=No for packets arriving on
- the associated interface.
-
-
-
- - The means for specifying a range of IP addresses in
- /etc/shorewall/masq to use for SNAT is now documented.
- ADD_SNAT_ALIASES=Yes is enabled for address ranges.
-
-
-
- - Shorewall can now add IP addresses to subnets other than
- the first one on an interface.
-
-
-
- - DNAT[-] rules may now be used to load balance
- (round-robin) over a set of servers. Servers may be specified
- in a range of addresses given as <first
- address>-<last address>.
-
- Example:
-
- DNAT net loc:192.168.10.2-192.168.10.5 tcp
- 80
-
-
-
- - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT
- configuration options have been removed and have been
- replaced by code that detects whether these capabilities are
- present in the current kernel. The output of the start,
- restart and check commands have been enhanced to report the
- outcome:
-
- Shorewall has detected the following iptables/netfilter
- capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Verifying Configuration...
-
-
-
- - Support for the Connection Tracking Match Extension has
- been added. This extension is available in recent
- kernel/iptables releases and allows for rules which match
- against elements in netfilter's connection tracking table.
- Shorewall automatically detects the availability of this
- extension and reports its availability in the output of the
- start, restart and check commands.
-
- Shorewall has detected the following iptables/netfilter
- capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Connection Tracking Match: Available
- Verifying Configuration...
-
- If this extension is available, the ruleset generated by
- Shorewall is changed in the following ways:
-
- -
-
- - To handle 'norfc1918' filtering, Shorewall will not
- create chains in the mangle table but will rather do all
- 'norfc1918' filtering in the filter table (rfc1918
- chain).
-
- - Recall that Shorewall DNAT rules generate two
- netfilter rules; one in the nat table and one in the
- filter table. If the Connection Tracking Match Extension
- is available, the rule in the filter table is extended to
- check that the original destination address was the same
- as specified (or defaulted to) in the DNAT rule.
-
-
-
-
-
- - The shell used to interpret the firewall script
- (/usr/share/shorewall/firewall) may now be specified using
- the SHOREWALL_SHELL parameter in shorewall.conf.
-
-
-
- - An 'ipcalc' command has been added to
- /sbin/shorewall.
-
- ipcalc [ <address>
- <netmask> | <address>/<vlsm> ]
-
- Examples:
-
- [root@wookie root]# shorewall
- ipcalc 192.168.1.0/24
-
- CIDR=192.168.1.0/24
-
- NETMASK=255.255.255.0
-
- NETWORK=192.168.1.0
-
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- [root@wookie root]# shorewall
- ipcalc 192.168.1.0 255.255.255.0
-
- CIDR=192.168.1.0/24
-
- NETMASK=255.255.255.0
-
- NETWORK=192.168.1.0
-
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- Warning:
-
- If your shell only supports 32-bit signed arithmatic (ash or
- dash), then the ipcalc command produces incorrect information
- for IP addresses 128.0.0.0-1 and for /1 networks. Bash should
- produce correct information for all valid IP addresses.
-
-
-
- - An 'iprange' command has been added to
- /sbin/shorewall.
-
- iprange
- <address>-<address>
-
- This command decomposes a range of IP addressses into a list
- of network and host addresses. The command can be useful if
- you need to construct an efficient set of rules that accept
- connections from a range of network addresses.
-
- Note: If your shell only supports 32-bit signed arithmetic
- (ash or dash) then the range may not span 128.0.0.0.
-
- Example:
-
- [root@gateway root]#
- shorewall iprange 192.168.1.4-192.168.12.9
- 192.168.1.4/30
- 192.168.1.8/29
- 192.168.1.16/28
- 192.168.1.32/27
- 192.168.1.64/26
- 192.168.1.128/25
- 192.168.2.0/23
- 192.168.4.0/22
- 192.168.8.0/22
- 192.168.12.0/29
- 192.168.12.8/31
- [root@gateway root]#
-
-
-
- - A list of host/net addresses is now allowed in an entry
- in /etc/shorewall/hosts.
-
- Example:
-
- foo
- eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
- - The "shorewall check" command now includes the chain name
- when printing the applicable policy for each pair of
- zones.
-
- Example:
-
- Policy for dmz to
- net is REJECT using chain all2all
-
- This means that the policy for connections from the dmz to
- the internet is REJECT and the applicable entry in the
- /etc/shorewall/policy was the all->all policy.
-
-
-
- - Support for the 2.6 Kernel series has been added.
-
-
-
- 7/15/2003 - New Mirror in Brazil
-
- Thanks to the folks at securityopensource.org.br, there is now
- a Shorewall mirror in Brazil.
-
- 7/15/2003 - Shorewall-1.4.6 RC 1
-
-
- Problems Corrected:
-
-
-
- - A problem seen on RH7.3 systems where Shorewall
- encountered start errors when started using the "service"
- mechanism has been worked around.
-
-
-
- - Where a list of IP addresses appears in the DEST column
- of a DNAT[-] rule, Shorewall incorrectly created multiple
- DNAT rules in the nat table (one for each element in the
- list). Shorewall now correctly creates a single DNAT rule
- with multiple "--to-destination" clauses.
-
-
-
- - Corrected a problem in Beta 1 where DNS names containing
- a "-" were mis-handled when they appeared in the DEST column
- of a rule.
-
-
-
- - A number of problems with rule parsing have been
- corrected. Corrections involve the handling of "z1!z2" in the
- SOURCE column as well as lists in the ORIGINAL DESTINATION
- column.
-
-
-
- Migration Issues:
-
-
-
- - In earlier versions, an undocumented feature allowed
- entries in the host file as follows:
-
- z
- eth1:192.168.1.0/24,eth2:192.168.2.0/24
-
- This capability was never documented and has been removed in
- 1.4.6 to allow entries of the following format:
-
- z
- eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
- - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options
- have been removed from /etc/shorewall/shorewall.conf. These
- capabilities are now automatically detected by Shorewall (see
- below).
-
-
-
- New Features:
-
-
-
- - A 'newnotsyn' interface option has been added. This
- option may be specified in /etc/shorewall/interfaces and
- overrides the setting NEWNOTSYN=No for packets arriving on
- the associated interface.
-
-
-
- - The means for specifying a range of IP addresses in
- /etc/shorewall/masq to use for SNAT is now documented.
- ADD_SNAT_ALIASES=Yes is enabled for address ranges.
-
-
-
- - Shorewall can now add IP addresses to subnets other than
- the first one on an interface.
-
-
-
- - DNAT[-] rules may now be used to load balance
- (round-robin) over a set of servers. Servers may be specified
- in a range of addresses given as <first
- address>-<last address>.
-
- Example:
-
- DNAT net loc:192.168.10.2-192.168.10.5 tcp
- 80
-
-
-
- - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT
- configuration options have been removed and have been
- replaced by code that detects whether these capabilities are
- present in the current kernel. The output of the start,
- restart and check commands have been enhanced to report the
- outcome:
-
- Shorewall has detected the following iptables/netfilter
- capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Verifying Configuration...
-
-
-
- - Support for the Connection Tracking Match Extension has
- been added. This extension is available in recent
- kernel/iptables releases and allows for rules which match
- against elements in netfilter's connection tracking table.
- Shorewall automatically detects the availability of this
- extension and reports its availability in the output of the
- start, restart and check commands.
-
- Shorewall has detected the following iptables/netfilter
- capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Connection Tracking Match: Available
- Verifying Configuration...
-
- If this extension is available, the ruleset generated by
- Shorewall is changed in the following ways:
-
- -
-
- - To handle 'norfc1918' filtering, Shorewall will not
- create chains in the mangle table but will rather do all
- 'norfc1918' filtering in the filter table (rfc1918
- chain).
-
- - Recall that Shorewall DNAT rules generate two
- netfilter rules; one in the nat table and one in the
- filter table. If the Connection Tracking Match Extension
- is available, the rule in the filter table is extended to
- check that the original destination address was the same
- as specified (or defaulted to) in the DNAT rule.
-
-
-
-
-
- - The shell used to interpret the firewall script
- (/usr/share/shorewall/firewall) may now be specified using
- the SHOREWALL_SHELL parameter in shorewall.conf.
-
-
-
- - An 'ipcalc' command has been added to
- /sbin/shorewall.
-
- ipcalc [ <address>
- <netmask> | <address>/<vlsm> ]
-
- Examples:
-
- [root@wookie root]# shorewall
- ipcalc 192.168.1.0/24
-
- CIDR=192.168.1.0/24
-
- NETMASK=255.255.255.0
-
- NETWORK=192.168.1.0
-
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- [root@wookie root]# shorewall
- ipcalc 192.168.1.0 255.255.255.0
-
- CIDR=192.168.1.0/24
-
- NETMASK=255.255.255.0
-
- NETWORK=192.168.1.0
-
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- Warning:
-
- If your shell only supports 32-bit signed arithmatic (ash or
- dash), then the ipcalc command produces incorrect information
- for IP addresses 128.0.0.0-1 and for /1 networks. Bash should
- produce correct information for all valid IP addresses.
-
-
-
- - An 'iprange' command has been added to
- /sbin/shorewall.
-
- iprange
- <address>-<address>
-
- This command decomposes a range of IP addressses into a list
- of network and host addresses. The command can be useful if
- you need to construct an efficient set of rules that accept
- connections from a range of network addresses.
-
- Note: If your shell only supports 32-bit signed arithmetic
- (ash or dash) then the range may not span 128.0.0.0.
-
- Example:
-
- [root@gateway root]#
- shorewall iprange 192.168.1.4-192.168.12.9
- 192.168.1.4/30
- 192.168.1.8/29
- 192.168.1.16/28
- 192.168.1.32/27
- 192.168.1.64/26
- 192.168.1.128/25
- 192.168.2.0/23
- 192.168.4.0/22
- 192.168.8.0/22
- 192.168.12.0/29
- 192.168.12.8/31
- [root@gateway root]#
-
-
-
- - A list of host/net addresses is now allowed in an entry
- in /etc/shorewall/hosts.
-
- Example:
-
- foo
- eth1:192.168.1.0/24,192.168.2.0/24
-
-
- 7/7/2003 - Shorewall-1.4.6 Beta 2
-
- Problems Corrected:
-
-
-
- - A problem seen on RH7.3 systems where Shorewall
- encountered start errors when started using the "service"
- mechanism has been worked around.
-
-
-
- - Where a list of IP addresses appears in the DEST column
- of a DNAT[-] rule, Shorewall incorrectly created multiple
- DNAT rules in the nat table (one for each element in the
- list). Shorewall now correctly creates a single DNAT rule
- with multiple "--to-destination" clauses.
-
-
-
- - Corrected a problem in Beta 1 where DNS names containing
- a "-" were mis-handled when they appeared in the DEST column
- of a rule.
-
-
-
- Migration Issues:
-
-
-
- - In earlier versions, an undocumented feature allowed
- entries in the host file as follows:
-
- z
- eth1:192.168.1.0/24,eth2:192.168.2.0/24
-
- This capability was never documented and has been removed in
- 1.4.6 to allow entries of the following format:
-
- z
- eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
- - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options
- have been removed from /etc/shorewall/shorewall.conf. These
- capabilities are now automatically detected by Shorewall (see
- below).
-
-
-
- New Features:
-
-
-
- - A 'newnotsyn' interface option has been added. This
- option may be specified in /etc/shorewall/interfaces and
- overrides the setting NEWNOTSYN=No for packets arriving on
- the associated interface.
-
-
-
- - The means for specifying a range of IP addresses in
- /etc/shorewall/masq to use for SNAT is now documented.
- ADD_SNAT_ALIASES=Yes is enabled for address ranges.
-
-
-
- - Shorewall can now add IP addresses to subnets other than
- the first one on an interface.
-
-
-
- - DNAT[-] rules may now be used to load balance
- (round-robin) over a set of servers. Servers may be specified
- in a range of addresses given as <first
- address>-<last address>.
-
- Example:
-
- DNAT net loc:192.168.10.2-192.168.10.5 tcp
- 80
-
-
-
- - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT
- configuration options have been removed and have been
- replaced by code that detects whether these capabilities are
- present in the current kernel. The output of the start,
- restart and check commands have been enhanced to report the
- outcome:
-
- Shorewall has detected the following iptables/netfilter
- capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Verifying Configuration...
-
-
-
- - Support for the Connection Tracking Match Extension has
- been added. This extension is available in recent
- kernel/iptables releases and allows for rules which match
- against elements in netfilter's connection tracking table.
- Shorewall automatically detects the availability of this
- extension and reports its availability in the output of the
- start, restart and check commands.
-
- Shorewall has detected the following iptables/netfilter
- capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Connection Tracking Match: Available
- Verifying Configuration...
-
- If this extension is available, the ruleset generated by
- Shorewall is changed in the following ways:
-
- -
-
- - To handle 'norfc1918' filtering, Shorewall will not
- create chains in the mangle table but will rather do all
- 'norfc1918' filtering in the filter table (rfc1918
- chain).
-
- - Recall that Shorewall DNAT rules generate two
- netfilter rules; one in the nat table and one in the
- filter table. If the Connection Tracking Match Extension
- is available, the rule in the filter table is extended to
- check that the original destination address was the same
- as specified (or defaulted to) in the DNAT rule.
-
-
-
-
-
- - The shell used to interpret the firewall script
- (/usr/share/shorewall/firewall) may now be specified using
- the SHOREWALL_SHELL parameter in shorewall.conf.
-
-
-
- - An 'ipcalc' command has been added to
- /sbin/shorewall.
-
- ipcalc [ <address>
- <netmask> | <address>/<vlsm> ]
-
- Examples:
-
- [root@wookie root]# shorewall
- ipcalc 192.168.1.0/24
-
- CIDR=192.168.1.0/24
-
- NETMASK=255.255.255.0
-
- NETWORK=192.168.1.0
-
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- [root@wookie root]# shorewall
- ipcalc 192.168.1.0 255.255.255.0
-
- CIDR=192.168.1.0/24
-
- NETMASK=255.255.255.0
-
- NETWORK=192.168.1.0
-
- BROADCAST=192.168.1.255
- [root@wookie root]#
-
- Warning:
-
- If your shell only supports 32-bit signed arithmatic (ash or
- dash), then the ipcalc command produces incorrect information
- for IP addresses 128.0.0.0-1 and for /1 networks. Bash should
- produce correct information for all valid IP addresses.
-
-
-
- - An 'iprange' command has been added to
- /sbin/shorewall.
-
- iprange
- <address>-<address>
-
- This command decomposes a range of IP addressses into a list
- of network and host addresses. The command can be useful if
- you need to construct an efficient set of rules that accept
- connections from a range of network addresses.
-
- Note: If your shell only supports 32-bit signed arithmetic
- (ash or dash) then the range may not span 128.0.0.0.
-
- Example:
-
- [root@gateway root]#
- shorewall iprange 192.168.1.4-192.168.12.9
- 192.168.1.4/30
- 192.168.1.8/29
- 192.168.1.16/28
- 192.168.1.32/27
- 192.168.1.64/26
- 192.168.1.128/25
- 192.168.2.0/23
- 192.168.4.0/22
- 192.168.8.0/22
- 192.168.12.0/29
- 192.168.12.8/31
- [root@gateway root]#
-
-
-
- - A list of host/net addresses is now allowed in an entry
- in /etc/shorewall/hosts.
-
- Example:
-
- foo
- eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
-
- 7/4/2003 - Shorewall-1.4.6 Beta 1
-
- Problems Corrected:
-
-
-
- - A problem seen on RH7.3 systems where Shorewall
- encountered start errors when started using the "service"
- mechanism has been worked around.
-
-
-
- - Where a list of IP addresses appears in the DEST column
- of a DNAT[-] rule, Shorewall incorrectly created multiple
- DNAT rules in the nat table (one for each element in the
- list). Shorewall now correctly creates a single DNAT rule
- with multiple "--to-destination" clauses.
-
-
-
- New Features:
-
-
-
- - A 'newnotsyn' interface option has been added. This
- option may be specified in /etc/shorewall/interfaces and
- overrides the setting NEWNOTSYN=No for packets arriving on
- the associated interface.
-
-
-
- - The means for specifying a range of IP addresses in
- /etc/shorewall/masq to use for SNAT is now documented.
- ADD_SNAT_ALIASES=Yes is enabled for address ranges.
-
-
-
- - Shorewall can now add IP addresses to subnets other than
- the first one on an interface.
-
-
-
- - DNAT[-] rules may now be used to load balance
- (round-robin) over a set of servers. Up to 256 servers may be
- specified in a range of addresses given as <first
- address>-<last address>.
-
- Example:
-
- DNAT net loc:192.168.10.2-192.168.10.5 tcp
- 80
-
- Note that this capability has previously been available
- using a combination of a DNAT- rule and one or more ACCEPT
- rules. That technique is still preferable for load-balancing
- over a large number of servers (> 16) since specifying a
- range in the DNAT rule causes one filter table ACCEPT rule to
- be generated for each IP address in the range.
-
-
-
- - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT
- configuration options have been removed and have been
- replaced by code that detects whether these capabilities are
- present in the current kernel. The output of the start,
- restart and check commands have been enhanced to report the
- outcome:
-
- Shorewall has detected the following iptables/netfilter
- capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Verifying Configuration...
-
-
-
- - Support for the Connection Tracking Match Extension has
- been added. This extension is available in recent
- kernel/iptables releases and allows for rules which match
- against elements in netfilter's connection tracking table.
- Shorewall automatically detects the availability of this
- extension and reports its availability in the output of the
- start, restart and check commands.
-
- Shorewall has detected the following iptables/netfilter
- capabilities:
- NAT: Available
- Packet Mangling: Available
- Multi-port Match: Available
- Connection Tracking Match: Available
- Verifying Configuration...
-
- If this extension is available, the ruleset generated by
- Shorewall is changed in the following ways:
-
- -
-
- - To handle 'norfc1918' filtering, Shorewall will not
- create chains in the mangle table but will rather do all
- 'norfc1918' filtering in the filter table (rfc1918
- chain).
-
- - Recall that Shorewall DNAT rules generate two
- netfilter rules; one in the nat table and one in the
- filter table. If the Connection Tracking Match Extension
- is available, the rule in the filter table is extended to
- check that the original destination address was the same
- as specified (or defaulted to) in the DNAT rule.
-
-
-
-
-
- - The shell used to interpret the firewall script
- (/usr/share/shorewall/firewall) may now be specified using
- the SHOREWALL_SHELL parameter in shorewall.conf.
-
-
-
- 6/17/2003 - Shorewall-1.4.5
-
- Problems Corrected:
-
-
-
- - The command "shorewall debug try <directory>" now
- correctly traces the attempt.
-
- - The INCLUDE directive now works properly in the zones
- file; previously, INCLUDE in that file was ignored.
-
- - /etc/shorewall/routestopped records with an empty second
- column are no longer ignored.
-
-
-
- New Features:
-
-
-
- - The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule
- may now contain a list of addresses. If the list begins with
- "!' then the rule will take effect only if the original
- destination address in the connection request does not match
- any of the addresses listed.
-
-
- 6/15/2003 - Shorewall, Kernel 2.4.21 and iptables
- 1.2.8
-
- The firewall at shorewall.net has been upgraded to the
- 2.4.21 kernel and iptables 1.2.8 (using the "official" RPM from
- netfilter.org). No problems have been encountered with this set
- of software. The Shorewall version is 1.4.4b plus the
- accumulated changes for 1.4.5.
-
-
- 6/8/2003 - Updated Samples
-
- Thanks to Francesca Smith, the samples have been updated to
- Shorewall version 1.4.4.
-
- 5/29/2003 - Shorewall-1.4.4b
-
- Groan -- This version corrects a problem whereby the
- --log-level was not being set when logging via syslog. The most
- commonly reported symptom was that Shorewall messages were
- being written to the console even though console logging was
- correctly configured per FAQ 16.
-
-
- 5/27/2003 - Shorewall-1.4.4a
- The Fireparse --log-prefix fiasco continues. Tuomo Soini has
- pointed out that the code in 1.4.4 restricts the length of
- short zone names to 4 characters. I've produced version 1.4.4a
- that restores the previous 5-character limit by conditionally
- omitting the log rule number when the LOGFORMAT doesn't contain
- '%d'.
-
-
- 5/23/2003 - Shorewall-1.4.4
- I apologize for the rapid-fire releases but since there is a
- potential configuration change required to go from 1.4.3a to
- 1.4.4, I decided to make it a full release rather than just a
- bug-fix release.
-
- Problems corrected:
-
-
-
- None.
-
- New Features:
-
-
-
- - A REDIRECT- rule target has been added. This target
- behaves for REDIRECT in the same way as DNAT- does for DNAT
- in that the Netfilter nat table REDIRECT rule is added but
- not the companion filter table ACCEPT rule.
-
-
-
- - The LOGMARKER variable has been renamed LOGFORMAT and has
- been changed to a 'printf' formatting template which accepts
- three arguments (the chain name, logging rule number and the
- disposition). To use LOGFORMAT with fireparse (http://www.fireparse.com), set
- it as:
-
- LOGFORMAT="fp=%s:%d
- a=%s "
-
- CAUTION: /sbin/shorewall uses the leading part of the
- LOGFORMAT string (up to but not including the first '%') to
- find log messages in the 'show log', 'status' and 'hits'
- commands. This part should not be omitted (the LOGFORMAT
- should not begin with "%") and the leading part should be
- sufficiently unique for /sbin/shorewall to identify Shorewall
- messages.
-
-
-
- - When logging is specified on a DNAT[-] or REDIRECT[-]
- rule, the logging now takes place in the nat table rather
- than in the filter table. This way, only those connections
- that actually undergo DNAT or redirection will be logged.
-
-
-
- 5/20/2003 - Shorewall-1.4.3a
-
- This version primarily corrects the documentation included in
- the .tgz and in the .rpm. In addition:
-
-
-
- - (This change is in 1.4.3 but is not documented) If you
- are running iptables 1.2.7a and kernel 2.4.20, then Shorewall
- will return reject replies as follows:
- a) tcp - RST
- b) udp - ICMP port unreachable
- c) icmp - ICMP host unreachable
- d) Otherwise - ICMP host prohibited
- If you are running earlier software, Shorewall will follow
- it's traditional convention:
- a) tcp - RST
- b) Otherwise - ICMP port unreachable
-
- - UDP port 135 is now silently dropped in the common.def
- chain. Remember that this chain is traversed just before a
- DROP or REJECT policy is enforced.
-
-
-
- 5/18/2003 - Shorewall 1.4.3
-
- Problems Corrected:
-
-
-
- - There were several cases where Shorewall would fail to
- remove a temporary directory from /tmp. These cases have been
- corrected.
-
- - The rules for allowing all traffic via the loopback
- interface have been moved to before the rule that drops
- status=INVALID packets. This insures that all loopback
- traffic is allowed even if Netfilter connection tracking is
- confused.
-
- New Features:
-
-
-
- - IPV6-IPV4 (6to4) tunnels are now supported in the
- /etc/shorewall/tunnels file.
-
- - You may now change the leading portion of the
- --log-prefix used by Shorewall using the LOGMARKER variable
- in shorewall.conf. By default, "Shorewall:" is used.
-
-
-
- 5/10/2003 - Shorewall Mirror in Asia
-
-
- Ed Greshko has established a mirror in Taiwan -- Thanks
- Ed!
-
-
- 5/8/2003 - Shorewall Mirror in Chile
- Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago
- Chile.
-
- 4/21/2003 - Samples updated for Shorewall version
- 1.4.2
-
- Thanks to Francesca Smith, the sample configurations are now
- upgraded to Shorewall version 1.4.2.
-
- 4/9/2003 - Shorewall 1.4.2
-
-
- Problems Corrected:
-
-
-
- - TCP connection requests rejected out of the
- common chain are now properly rejected with TCP RST;
- previously, some of these requests were rejected with an
- ICMP port-unreachable response.
-
- - 'traceroute -I' from behind the firewall previously
- timed out on the first hop (e.g., to the firewall). This
- has been worked around.
-
-
-
- New Features:
-
-
- - Where an entry in the/etc/shorewall/hosts file specifies
- a particular host or network, Shorewall now creates an
- intermediate chain for handling input from the related zone.
- This can substantially reduce the number of rules traversed
- by connections requests from such zones.
-
-
-
- - Any file may include an INCLUDE directive. An INCLUDE
- directive consists of the word INCLUDE followed by a file
- name and causes the contents of the named file to be
- logically included into the file containing the INCLUDE. File
- names given in an INCLUDE directive are assumed to reside in
- /etc/shorewall or in an alternate configuration directory if
- one has been specified for the command.
-
- Examples:
- shorewall/params.mgmt:
- MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
- TIME_SERVERS=4.4.4.4
- BACKUP_SERVERS=5.5.5.5
- ----- end params.mgmt -----
-
-
- shorewall/params:
- # Shorewall 1.3 /etc/shorewall/params
- [..]
- #######################################
-
- INCLUDE params.mgmt
-
- # params unique to this host here
- #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE -
- DO NOT REMOVE
- ----- end params -----
-
-
- shorewall/rules.mgmt:
- ACCEPT
- net:$MGMT_SERVERS
- $FW tcp 22
- ACCEPT
- $FW
- net:$TIME_SERVERS udp
- 123
- ACCEPT
- $FW
- net:$BACKUP_SERVERS tcp 22
- ----- end rules.mgmt -----
-
- shorewall/rules:
- # Shorewall version 1.3 - Rules File
- [..]
- #######################################
-
- INCLUDE rules.mgmt
-
- # rules unique to this host here
- #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE
- -- DO NOT REMOVE
- ----- end rules -----
-
- INCLUDE's may be nested to a level of 3 -- further nested
- INCLUDE directives are ignored with a warning message.
-
-
-
- - Routing traffic from an interface back out that interface
- continues to be a problem. While I firmly believe that this
- should never happen, people continue to want to do it. To
- limit the damage that such nonsense produces, I have added a
- new 'routeback' option in /etc/shorewall/interfaces and
- /etc/shorewall/hosts. When used in /etc/shorewall/interfaces,
- the 'ZONE' column may not contain '-'; in other words,
- 'routeback' can't be used as an option for a multi-zone
- interface. The 'routeback' option CAN be specified however on
- individual group entries in /etc/shorewall/hosts.
-
- The 'routeback' option is similar to the old 'multi' option
- with two exceptions:
-
- a) The option pertains to a particular
- zone,interface,address tuple.
-
- b) The option only created infrastructure to
- pass traffic from (zone,interface,address) tuples back to
- themselves (the 'multi' option affected all
- (zone,interface,address) tuples associated with the given
- 'interface').
-
- See the 'Upgrade Issues'
- for information about how this new option may affect your
- configuration.
-
-
-
- 3/24/2003 - Shorewall 1.4.1
-
- This release follows up on 1.4.0. It corrects a problem
- introduced in 1.4.0 and removes additional warts.
-
- Problems Corrected:
-
-
-
- - When Shorewall 1.4.0 is run under the ash shell (such as
- on Bering/LEAF), it can attempt to add ECN disabling rules
- even if the /etc/shorewall/ecn file is empty. That problem
- has been corrected so that ECN disabling rules are only added
- if there are entries in /etc/shorewall/ecn.
-
- New Features:
-
-
-
- Note: In the list that follows, the term group refers
- to a particular network or subnetwork (which may be 0.0.0.0/0
- or it may be a host address) accessed through a particular
- interface. Examples:
-
-
-
- eth0:0.0.0.0/0
- eth2:192.168.1.0/24
- eth3:192.0.2.123
-
- You can use the "shorewall check" command to see the groups
- associated with each of your zones.
-
-
-
- - Beginning with Shorewall 1.4.1, if a zone Z comprises
- more than one group then if there is no explicit Z to Z
- policy and there are no rules governing traffic from Z to Z
- then Shorewall will permit all traffic between the groups in
- the zone.
-
- - Beginning with Shorewall 1.4.1, Shorewall will never
- create rules to handle traffic from a group to itself.
-
- - A NONE policy is introduced in 1.4.1. When a policy of
- NONE is specified from Z1 to Z2:
-
-
-
- - There may be no rules created that govern connections
- from Z1 to Z2.
-
- - Shorewall will not create any infrastructure to handle
- traffic from Z1 to Z2.
-
- See the upgrade issues for a
- discussion of how these changes may affect your configuration.
-
- 3/17/2003 - Shorewall 1.4.0
- Shorewall 1.4 represents the next step in the evolution of
- Shorewall. The main thrust of the initial release is simply to
- remove the cruft that has accumulated in Shorewall over time.
-
-
- IMPORTANT: Shorewall 1.4.0 requires the iproute
- package ('ip' utility).
-
- Function from 1.3 that has been omitted from this version
- include:
-
-
-
- - The MERGE_HOSTS variable in shorewall.conf is no longer
- supported. Shorewall 1.4 behavior is the same as 1.3 with
- MERGE_HOSTS=Yes.
-
-
-
- - Interface names of the form
- <device>:<integer> in /etc/shorewall/interfaces
- now generate an error.
-
-
-
- - Shorewall 1.4 implements behavior consistent with
- OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an
- error at startup as will specification of the 'noping' or
- 'filterping' interface options.
-
-
-
- - The 'routestopped' option in the
- /etc/shorewall/interfaces and /etc/shorewall/hosts files is
- no longer supported and will generate an error at startup if
- specified.
-
-
-
- - The Shorewall 1.2 syntax for DNAT and REDIRECT rules is
- no longer accepted.
-
-
-
- - The ALLOWRELATED variable in shorewall.conf is no longer
- supported. Shorewall 1.4 behavior is the same as 1.3 with
- ALLOWRELATED=Yes.
-
-
-
- - The icmp.def file has been removed.
-
-
- Changes for 1.4 include:
-
-
-
- - The /etc/shorewall/shorewall.conf file has been
- completely reorganized into logical sections.
-
-
-
- - LOG is now a valid action for a rule
- (/etc/shorewall/rules).
-
-
-
- - The firewall script and version file are now installed in
- /usr/share/shorewall.
-
-
-
- - Late arriving DNS replies are now silently dropped in the
- common chain by default.
-
-
-
- - In addition to behaving like OLD_PING_HANDLING=No,
- Shorewall 1.4 no longer unconditionally accepts outbound ICMP
- packets. So if you want to 'ping' from the firewall, you will
- need the appropriate rule or policy.
-
-
-
- - CONTINUE is now a valid action for a rule
- (/etc/shorewall/rules).
-
-
-
- - 802.11b devices with names of the form wlan<n> now
- support the 'maclist' option.
-
-
-
- - Explicit Congestion Notification (ECN - RFC 3168) may now
- be turned off on a host or network basis using the new
- /etc/shorewall/ecn file. To use this facility:
-
- a) You must be running kernel 2.4.20
- b) You must have applied the patch in
-
- http://www.shorewall/net/pub/shorewall/ecn/patch.
- c) You must have iptables 1.2.7a installed.
-
-
-
- - The /etc/shorewall/params file is now processed first so
- that variables may be used in the
- /etc/shorewall/shorewall.conf file.
-
-
-
- - Shorewall now gives a more helpful diagnostic
- when the 'ipchains' compatibility kernel module is loaded and
- a 'shorewall start' command is issued.
-
-
-
- - The SHARED_DIR variable has been removed from
- shorewall.conf. This variable was for use by package
- maintainers and was not documented for general use.
-
-
-
- - Shorewall now ignores 'default' routes when detecting
- masq'd networks.
-
-
- 3/10/2003 - Shoreall 1.3.14a
-
- A roleup of the following bug fixes and other updates:
-
-
- - There is an updated rfc1918 file that reflects the resent
- allocation of 222.0.0.0/8 and 223.0.0.0/8.
-
-
-
- - The documentation for the routestopped file claimed that
- a comma-separated list could appear in the second column
- while the code only supported a single host or network
- address.
-
- - Log messages produced by 'logunclean' and 'dropunclean'
- were not rate-limited.
-
- - 802.11b devices with names of the form
- wlan<n> don't support the 'maclist' interface
- option.
-
- - Log messages generated by RFC 1918 filtering are not rate
- limited.
-
- - The firewall fails to start in the case where you have
- "eth0 eth1" in /etc/shorewall/masq and the default route is
- through eth1
-
-
- 2/8/2003 - Shoreawall 1.3.14
-
- New features include
-
-
- - An OLD_PING_HANDLING option has been added to
- shorewall.conf. When set to Yes, Shorewall ping handling is
- as it has always been (see
- http://www.shorewall.net/ping.html).
-
- When OLD_PING_HANDLING=No, icmp echo (ping) is handled via
- rules and policies just like any other connection request.
- The FORWARDPING=Yes option in shorewall.conf and the 'noping'
- and 'filterping' options in /etc/shorewall/interfaces will
- all generate an error.
-
-
-
- - It is now possible to direct Shorewall to create a
- "label" such as "eth0:0" for IP addresses that it
- creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes.
- This is done by specifying the label instead of just the
- interface name:
-
- a) In the INTERFACE column of
- /etc/shorewall/masq
- b) In the INTERFACE column of
- /etc/shorewall/nat
-
-
- - Support for OpenVPN Tunnels.
-
-
-
- - Support for VLAN devices with names of the form $DEV.$VID
- (e.g., eth0.0)
-
-
-
- - In /etc/shorewall/tcrules, the MARK value may be
- optionally followed by ":" and either 'F' or 'P' to designate
- that the marking will occur in the FORWARD or PREROUTING
- chains respectively. If this additional specification is
- omitted, the chain used to mark packets will be determined by
- the setting of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
-
-
-
- -
- When an interface name is entered in the SUBNET column of
- the /etc/shorewall/masq file, Shorewall previously
- masqueraded traffic from only the first subnet defined on
- that interface. It did not masquerade traffic from:
-
- a) The subnets associated with other
- addresses on the interface.
- b) Subnets accessed through local
- routers.
-
- Beginning with Shorewall 1.3.14, if you enter an interface
- name in the SUBNET column, shorewall will use the
- firewall's routing table to construct the masquerading/SNAT
- rules.
-
- Example 1 -- This is how it works in 1.3.14.
-
-
-
- [root@gateway test]# cat /etc/shorewall/masq
- #INTERFACE SUBNET ADDRESS
- eth0 eth2 206.124.146.176
- #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
- [root@gateway test]# ip route show dev eth2
- 192.168.1.0/24 scope link
- 192.168.10.0/24 proto kernel scope link src 192.168.10.254
-
-
-
- [root@gateway test]# shorewall start
- ...
- Masqueraded Subnets and Hosts:
- To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
- To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
- Processing /etc/shorewall/tos...
-
-
-
- When upgrading to Shorewall 1.3.14, if you have multiple
- local subnets connected to an interface that is specified
- in the SUBNET column of an /etc/shorewall/masq entry, your
- /etc/shorewall/masq file will need changing. In most cases,
- you will simply be able to remove redundant entries. In
- some cases though, you might want to change from using the
- interface name to listing specific subnetworks if the
- change described above will cause masquerading to occur on
- subnetworks that you don't wish to masquerade.
-
- Example 2 -- Suppose that your current config is as
- follows:
-
-
-
- [root@gateway test]# cat /etc/shorewall/masq
- #INTERFACE SUBNET ADDRESS
- eth0 eth2 206.124.146.176
- eth0 192.168.10.0/24 206.124.146.176
- #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
- [root@gateway test]# ip route show dev eth2
- 192.168.1.0/24 scope link
- 192.168.10.0/24 proto kernel scope link src 192.168.10.254
- [root@gateway test]#
-
-
-
- In this case, the second entry in
- /etc/shorewall/masq is no longer required.
-
- Example 3 -- What if your current configuration is like
- this?
-
-
-
- [root@gateway test]# cat /etc/shorewall/masq
- #INTERFACE SUBNET ADDRESS
- eth0 eth2 206.124.146.176
- #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
- [root@gateway test]# ip route show dev eth2
- 192.168.1.0/24 scope link
- 192.168.10.0/24 proto kernel scope link src 192.168.10.254
- [root@gateway test]#
-
-
-
- In this case, you would want to change the
- entry in /etc/shorewall/masq to:
-
-
- #INTERFACE SUBNET ADDRESS
- eth0 192.168.1.0/24 206.124.146.176
- #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
-
-
-
- 2/5/2003 - Shorewall Support included in Webmin
- 1.060
-
- Webmin version 1.060 now has Shorewall support included as
- standard. See http://www.webmin.com.
-
- 2/4/2003 - Shorewall 1.3.14-RC1
-
- Includes the Beta 2 content plus support for OpenVPN
- tunnels.
-
- 1/28/2003 - Shorewall 1.3.14-Beta2
-
- Includes the Beta 1 content plus restores VLAN device names
- of the form $dev.$vid (e.g., eth0.1)
-
- 1/25/2003 - Shorewall 1.3.14-Beta1
-
-
- The Beta includes the following changes:
-
-
-
- - An OLD_PING_HANDLING option has been added to
- shorewall.conf. When set to Yes, Shorewall ping handling is
- as it has always been (see
- http://www.shorewall.net/ping.html).
-
- When OLD_PING_HANDLING=No, icmp echo (ping) is handled via
- rules and policies just like any other connection request.
- The FORWARDPING=Yes option in shorewall.conf and the 'noping'
- and 'filterping' options in /etc/shorewall/interfaces will
- all generate an error.
-
-
-
- - It is now possible to direct Shorewall to create a
- "label" such as "eth0:0" for IP addresses that it
- creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes.
- This is done by specifying the label instead of just the
- interface name:
-
- a) In the INTERFACE column of
- /etc/shorewall/masq
- b) In the INTERFACE column of
- /etc/shorewall/nat
-
-
- -
- When an interface name is entered in the SUBNET column of
- the /etc/shorewall/masq file, Shorewall previously
- masqueraded traffic from only the first subnet defined on
- that interface. It did not masquerade traffic from:
-
- a) The subnets associated with other
- addresses on the interface.
- b) Subnets accessed through local
- routers.
-
- Beginning with Shorewall 1.3.14, if you enter an interface
- name in the SUBNET column, shorewall will use the
- firewall's routing table to construct the masquerading/SNAT
- rules.
-
- Example 1 -- This is how it works in 1.3.14.
-
-
-
- [root@gateway test]# cat /etc/shorewall/masq
- #INTERFACE SUBNET ADDRESS
- eth0 eth2 206.124.146.176
- #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
- [root@gateway test]# ip route show dev eth2
- 192.168.1.0/24 scope link
- 192.168.10.0/24 proto kernel scope link src 192.168.10.254
-
-
-
- [root@gateway test]# shorewall start
- ...
- Masqueraded Subnets and Hosts:
- To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
- To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
- Processing /etc/shorewall/tos...
-
-
-
- When upgrading to Shorewall 1.3.14, if you have multiple
- local subnets connected to an interface that is specified
- in the SUBNET column of an /etc/shorewall/masq entry, your
- /etc/shorewall/masq file will need changing. In most cases,
- you will simply be able to remove redundant entries. In
- some cases though, you might want to change from using the
- interface name to listing specific subnetworks if the
- change described above will cause masquerading to occur on
- subnetworks that you don't wish to masquerade.
-
- Example 2 -- Suppose that your current config is as
- follows:
-
-
-
- [root@gateway test]# cat /etc/shorewall/masq
- #INTERFACE SUBNET ADDRESS
- eth0 eth2 206.124.146.176
- eth0 192.168.10.0/24 206.124.146.176
- #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
- [root@gateway test]# ip route show dev eth2
- 192.168.1.0/24 scope link
- 192.168.10.0/24 proto kernel scope link src 192.168.10.254
- [root@gateway test]#
-
-
-
- In this case, the second entry in
- /etc/shorewall/masq is no longer required.
-
- Example 3 -- What if your current configuration is like
- this?
-
-
-
- [root@gateway test]# cat /etc/shorewall/masq
- #INTERFACE SUBNET ADDRESS
- eth0 eth2 206.124.146.176
- #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
- [root@gateway test]# ip route show dev eth2
- 192.168.1.0/24 scope link
- 192.168.10.0/24 proto kernel scope link src 192.168.10.254
- [root@gateway test]#
-
-
-
- In this case, you would want to change the
- entry in /etc/shorewall/masq to:
-
-
- #INTERFACE SUBNET ADDRESS
- eth0 192.168.1.0/24 206.124.146.176
- #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
-
-
-
-
- 1/18/2003 - Shorewall 1.3.13 Documentation in PDF
- Format
-
- Juraj Ontkanin has produced a PDF containing the Shorewall
- 1.3.13 documenation. the PDF may be downloaded from
- ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-
- http://slovakia.shorewall.net/pub/shorewall/pdf/
-
-
- 1/17/2003 - shorewall.net has MOVED
-
- Thanks to the generosity of Alex Martin and Rett Consulting, www.shorewall.net
- and ftp.shorewall.net are now hosted on a system in Bellevue,
- Washington. A big thanks to Alex for making this happen.
-
-
- 1/13/2003 - Shorewall 1.3.13
-
-
- Just includes a few things that I had on the burner:
-
-
-
- - A new 'DNAT-' action has been added for entries in the
- /etc/shorewall/rules file. DNAT- is intended for advanced
- users who wish to minimize the number of rules that
- connection requests must traverse.
-
- A Shorewall DNAT rule actually generates two iptables rules:
- a header rewriting rule in the 'nat' table and an ACCEPT rule
- in the 'filter' table. A DNAT- rule only generates the first
- of these rules. This is handy when you have several DNAT
- rules that would generate the same ACCEPT rule.
-
- Here are three rules from my previous rules
- file:
-
- DNAT
- net dmz:206.124.146.177 tcp smtp - 206.124.146.178
- DNAT
- net dmz:206.124.146.177 tcp smtp - 206.124.146.179
- ACCEPT net
- dmz:206.124.146.177 tcp www,smtp,ftp,...
-
- These three rules ended up generating _three_
- copies of
-
- ACCEPT
- net dmz:206.124.146.177 tcp smtp
-
- By writing the rules this way, I end up with
- only one copy of the ACCEPT rule.
-
- DNAT-
- net dmz:206.124.146.177 tcp smtp -
- 206.124.146.178
- DNAT-
- net dmz:206.124.146.177 tcp smtp -
- 206.124.146.179
- ACCEPT net
- dmz:206.124.146.177 tcp www,smtp,ftp,....
-
-
-
- - The 'shorewall check' command now prints out the
- applicable policy between each pair of zones.
-
-
-
- - A new CLEAR_TC option has been added to shorewall.conf.
- If this option is set to 'No' then Shorewall won't clear the
- current traffic control rules during [re]start. This setting
- is intended for use by people that prefer to configure
- traffic shaping when the network interfaces come up rather
- than when the firewall is started. If that is what you want
- to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply
- an /etc/shorewall/tcstart file. That way, your traffic
- shaping rules can still use the 'fwmark' classifier based on
- packet marking defined in /etc/shorewall/tcrules.
-
-
-
- - A new SHARED_DIR variable has been added that allows
- distribution packagers to easily move the shared directory
- (default /usr/lib/shorewall). Users should never have a need
- to change the value of this shorewall.conf setting.
-
-
-
- 1/6/2003 -
- BURNOUT
-
- Until further notice, I will not be involved in either
- Shorewall Development or Shorewall Support
-
- -Tom Eastep
-
-
- 12/30/2002 - Shorewall Documentation in PDF
- Format
-
- Juraj Ontkanin has produced a PDF containing the Shorewall
- 1.3.12 documenation. the PDF may be downloaded from
-
- ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-
- http://slovakia.shorewall.net/pub/shorewall/pdf/
-
-
-
- 12/27/2002 - Shorewall 1.3.12 Released
-
- Features include:
-
-
-
- - "shorewall refresh" now reloads the traffic shaping rules
- (tcrules and tcstart).
-
- - "shorewall debug [re]start" now turns off debugging after
- an error occurs. This places the point of the failure near
- the end of the trace rather than up in the middle of it.
-
- - "shorewall [re]start" has been speeded up by more than
- 40% with my configuration. Your milage may vary.
-
- - A "shorewall show classifiers" command has been added
- which shows the current packet classification filters. The
- output from this command is also added as a separate page in
- "shorewall monitor"
-
- - ULOG (must be all caps) is now accepted as a valid syslog
- level and causes the subject packets to be logged using the
- ULOG target rather than the LOG target. This allows you to
- run ulogd (available from http://www.netfilter.org/projects/ulogd/index.html)
- and log all Shorewall messages to a separate log file.
-
- - If you are running a kernel that has a FORWARD chain in
- the mangle table ("shorewall show mangle" will show you the
- chains in the mangle table), you can set
- MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for
- marking input packets based on their destination even when
- you are using Masquerading or SNAT.
-
- - I have cluttered up the /etc/shorewall directory with
- empty 'init', 'start', 'stop' and 'stopped' files. If you
- already have a file with one of these names, don't worry --
- the upgrade process won't overwrite your file.
-
- - I have added a new RFC1918_LOG_LEVEL variable to shorewall.conf. This variable
- specifies the syslog level at which packets are logged as a
- result of entries in the /etc/shorewall/rfc1918 file.
- Previously, these packets were always logged at the 'info'
- level.
-
-
-
- 12/20/2002 - Shorewall 1.3.12 Beta 3
-
- This version corrects a problem with Blacklist logging. In Beta
- 2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the
- firewall would fail to start and "shorewall refresh" would also
- fail.
-
-
- 12/20/2002 - Shorewall 1.3.12 Beta 2
-
- The first public Beta version of Shorewall 1.3.12 is now
- available (Beta 1 was made available only to a limited
- audience).
-
- Features include:
-
-
-
- - "shorewall refresh" now reloads the traffic shaping rules
- (tcrules and tcstart).
-
- - "shorewall debug [re]start" now turns off debugging after
- an error occurs. This places the point of the failure near
- the end of the trace rather than up in the middle of it.
-
- - "shorewall [re]start" has been speeded up by more than
- 40% with my configuration. Your milage may vary.
-
- - A "shorewall show classifiers" command has been added
- which shows the current packet classification filters. The
- output from this command is also added as a separate page in
- "shorewall monitor"
-
- - ULOG (must be all caps) is now accepted as a valid syslog
- level and causes the subject packets to be logged using the
- ULOG target rather than the LOG target. This allows you to
- run ulogd (available from http://www.netfilter.org/projects/ulogd/index.html)
- and log all Shorewall messages to a separate log file.
-
- - If you are running a kernel that has a FORWARD chain in
- the mangle table ("shorewall show mangle" will show you the
- chains in the mangle table), you can set
- MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for
- marking input packets based on their destination even when
- you are using Masquerading or SNAT.
-
- - I have cluttered up the /etc/shorewall directory with
- empty 'init', 'start', 'stop' and 'stopped' files. If you
- already have a file with one of these names, don't worry --
- the upgrade process won't overwrite your file.
-
- You may download the Beta from:
-
-
-
- http://www.shorewall.net/pub/shorewall/Beta
-
- ftp://ftp.shorewall.net/pub/shorewall/Beta
-
-
- 12/12/2002 - Mandrake Multi Network Firewall 
-
- Shorewall is at the center of MandrakeSoft's recently-announced
-
- Multi Network Firewall (MNF) product. Here is the
- press release.
-
-
- 12/7/2002 - Shorewall Support for Mandrake 9.0
-
- Two months and 3 days after I ordered Mandrake 9.0, it was
- finally delivered. I have installed 9.0 on one of my systems
- and I am now in a position to support Shorewall users who run
- Mandrake 9.0.
-
- 12/6/2002 - Debian 1.3.11a Packages Available
-
-
- Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
- 12/3/2002 - Shorewall 1.3.11a
-
- This is a bug-fix roll up which includes Roger Aich's fix
- for DNAT with excluded subnets (e.g., "DNAT foo!bar ...").
- Current 1.3.11 users who don't need rules of this type need not
- upgrade to 1.3.11.
-
- 11/24/2002 - Shorewall 1.3.11
-
- In this version:
-
-
- - A 'tcpflags' option has been added to entries in /etc/shorewall/interfaces.
- This option causes Shorewall to make a set of sanity check on
- TCP packet header flags.
-
- - It is now allowed to use 'all' in the SOURCE or DEST
- column in a rule. When
- used, 'all' must appear by itself (in may not be qualified)
- and it does not enable intra-zone traffic. For example, the
- rule
-
- ACCEPT loc all tcp 80
-
- does not enable http traffic from 'loc' to 'loc'.
-
- - Shorewall's use of the 'echo' command is now compatible
- with bash clones such as ash and dash.
-
- - fw->fw policies now generate a startup error.
- fw->fw rules generate a warning and are ignored
-
-
- 11/14/2002 - Shorewall Documentation in PDF
- Format
-
- Juraj Ontkanin has produced a PDF containing the Shorewall
- 1.3.10 documenation. the PDF may be downloaded from
-
- ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
-
- http://slovakia.shorewall.net/pub/shorewall/pdf/
-
-
-
- 11/09/2002 - Shorewall is Back at SourceForge
-
- The main Shorewall 1.3 web site is now back at SourceForge
- at http://shorewall.sf.net.
-
-
- 11/09/2002 - Shorewall 1.3.10
-
- In this version:
-
-
-
- 10/24/2002 - Shorewall is now in Gentoo Linux
-
- Alexandru Hartmann reports that his Shorewall package is now a
- part of the Gentoo Linux
- distribution. Thanks Alex!
-
-
- 10/23/2002 - Shorewall 1.3.10 Beta 1
- In this version:
-
-
-
- You may download the Beta from:
-
-
-
-
- 10/10/2002 - Debian 1.3.9b Packages Available
-
-
- Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
- 10/9/2002 - Shorewall 1.3.9b
- This release rolls up fixes to the installer and to the
- firewall script.
-
-
- 10/6/2002 - Shorewall.net now running on RH8.0
-
- The firewall and server here at shorewall.net are now running
- RedHat release 8.0.
-
- 9/30/2002 - Shorewall 1.3.9a
- Roles up the fix for broken tunnels.
-
-
- 9/30/2002 - TUNNELS Broken in 1.3.9!!!
- There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall
- -- copy that file to /usr/lib/shorewall/firewall.
-
-
- 9/28/2002 - Shorewall 1.3.9
-
- In this version:
-
-
-
- - DNS
- Names are now allowed in Shorewall config files (although
- I recommend against using them).
-
- - The connection SOURCE may now be qualified by both
- interface and IP address in a Shorewall rule.
-
- - Shorewall startup is now disabled after initial
- installation until the file /etc/shorewall/startup_disabled
- is removed. This avoids nasty surprises during reboot for
- users who install Shorewall but don't configure it.
-
- - The 'functions' and 'version' files and the 'firewall'
- symbolic link have been moved from /var/lib/shorewall to
- /usr/lib/shorewall to appease the LFS police at Debian.
-
-
-
- 9/23/2002 - Full Shorewall Site/Mailing List Archive
- Search Capability Restored
-
- 
A couple of recent configuration
- changes at www.shorewall.net broke the Search facility:
-
-
-
-
- - Mailing List Archive Search was not available.
-
- - The Site Search index was incomplete
-
- - Only one page of matches was presented.
-
-
- Hopefully these problems are now corrected.
-
- 9/23/2002 - Full Shorewall Site/Mailing List Archive
- Search Capability Restored
-
- A couple of recent configuration changes at www.shorewall.net
- had the negative effect of breaking the Search facility:
-
-
-
- - Mailing List Archive Search was not available.
-
- - The Site Search index was incomplete
-
- - Only one page of matches was presented.
-
- Hopefully these problems are now corrected.
-
-
- 9/18/2002 - Debian 1.3.8 Packages Available
-
-
- Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
- 9/16/2002 - Shorewall 1.3.8
-
- In this version:
-
-
-
- - A NEWNOTSYN option
- has been added to shorewall.conf. This option determines
- whether Shorewall accepts TCP packets which are not part of
- an established connection and that are not 'SYN' packets (SYN
- flag on and ACK flag off).
-
- - The need for the 'multi' option to communicate between
- zones za and zb on the same interface is removed in the case
- where the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will
- exist if:
-
- -
-
- - There is a policy for za to zb; or
-
- - There is at least one rule for za to zb.
-
-
-
-
-
- - The /etc/shorewall/blacklist file now contains three
- columns. In addition to the SUBNET/ADDRESS column, there are
- optional PROTOCOL and PORT columns to block only certain
- applications from the blacklisted addresses.
-
-
-
- 9/11/2002 - Debian 1.3.7c Packages Available
-
- Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
- 9/2/2002 - Shorewall 1.3.7c
-
- This is a role up of a fix for "DNAT" rules where the source
- zone is $FW (fw).
-
- 8/31/2002 - I'm not available
-
- I'm currently on vacation -- please respect my need
- for a couple of weeks free of Shorewall problem reports.
-
- -Tom
-
- 8/26/2002 - Shorewall 1.3.7b
-
- This is a role up of the "shorewall refresh" bug fix and the
- change which reverses the order of "dhcp" and "norfc1918"
- checking.
-
- 8/26/2002 - French FTP Mirror is Operational
-
- ftp://france.shorewall.net/pub/mirrors/shorewall
- is now available.
-
- 8/25/2002 - Shorewall Mirror in France
-
- Thanks to a Shorewall user in Paris, the Shorewall web site
- is now mirrored at http://france.shorewall.net.
-
- 8/25/2002 - Shorewall 1.3.7a Debian Packages
- Available
-
- Lorenzo Martignoni reports that the packages for version
- 1.3.7a are available at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
- 8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award
- for its Author -- Shorewall 1.3.7a released
-
- 1.3.7a corrects problems occurring in rules file processing
- when starting Shorewall 1.3.7.
-
- 8/22/2002 - Shorewall 1.3.7 Released 8/13/2002
-
- Features in this release include:
-
-
- - The 'icmp.def' file is now empty! The rules in that file
- were required in ipchains firewalls but are not required in
- Shorewall. Users who have ALLOWRELATED=No in shorewall.conf should see the Upgrade Issues.
-
- - A 'FORWARDPING' option has been added to shorewall.conf. The effect of
- setting this variable to Yes is the same as the effect of
- adding an ACCEPT rule for ICMP echo-request in /etc/shorewall/icmpdef.
- Users who have such a rule in icmpdef are encouraged to
- switch to FORWARDPING=Yes.
-
- - The loopback CLASS A Network (127.0.0.0/8) has been added
- to the rfc1918 file.
-
- - Shorewall now works with iptables 1.2.7
-
- - The documentation and web site no longer uses FrontPage
- themes.
-
-
- I would like to thank John Distler for his valuable input
- regarding TCP SYN and ICMP treatment in Shorewall. That input
- has led to marked improvement in Shorewall in the last two
- releases.
-
- 8/13/2002 - Documentation in the CVS
- Repository
-
- The Shorewall-docs project now contains just the HTML and
- image files - the Frontpage files have been removed.
-
- 8/7/2002 - STABLE branch added to CVS
- Repository
-
- This branch will only be updated after I release a new
- version of Shorewall so you can always update from this branch
- to get the latest stable tree.
-
- 8/7/2002 - Upgrade
- Issues section added to the Errata
- Page
-
- Now there is one place to go to look for issues involved
- with upgrading to recent versions of Shorewall.
-
- 8/7/2002 - Shorewall 1.3.6
-
- This is primarily a bug-fix rollup with a couple of new
- features:
-
-
-
- 7/30/2002 - Shorewall 1.3.5b Released
-
- This interim release:
-
-
- - Causes the firewall script to remove the lock file if it
- is killed.
-
- - Once again allows lists in the second column of the /etc/shorewall/hosts
- file.
-
- - Includes the latest QuickStart Guides.
-
-
- 7/29/2002 - New Shorewall Setup Guide Available
-
- The first draft of this guide is available at http://www.shorewall.net/shorewall_setup_guide.htm.
- The guide is intended for use by people who are setting up
- Shorewall to manage multiple public IP addresses and by people
- who want to learn more about Shorewall than is described in the
- single-address guides. Feedback on the new guide is
- welcome.
-
- 7/28/2002 - Shorewall 1.3.5 Debian Package
- Available
-
- Lorenzo Martignoni reports that the packages are version
- 1.3.5a and are available at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
- 7/27/2002 - Shorewall 1.3.5a Released
-
- This interim release restores correct handling of REDIRECT
+
+
"!" is now allowed in accounting
rules.
-
- 7/26/2002 - Shorewall 1.3.5 Released
-
- This will be the last Shorewall release for a while. I'm
- going to be focusing on rewriting a lot of the
- documentation.
-
- In this version:
-
-
- - Empty and invalid source and destination qualifiers are
- now detected in the rules file. It is a good idea to use the
- 'shorewall check' command before you issue a 'shorewall
- restart' command be be sure that you don't have any
- configuration problems that will prevent a successful
- restart.
-
- - Added MERGE_HOSTS variable in shorewall.conf to provide saner
- behavior of the /etc/shorewall/hosts file.
-
- - The time that the counters were last reset is now
- displayed in the heading of the 'status' and 'show'
- commands.
-
- - A proxyarp option has been added for entries in /etc/shorewall/interfaces.
- This option facilitates Proxy ARP sub-netting as described in
- the Proxy ARP subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/).
- Specifying the proxyarp option for an interface causes
- Shorewall to set
- /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
-
- - The Samples have been updated to reflect the new
- capabilities in this release.
-
-
- 7/16/2002 - New Mirror in Argentina
-
- Thanks to Arturo "Buanzo" Busleiman, there is now a
- Shorewall mirror in Argentina. Thanks Buanzo!!!
-
- 7/16/2002 - Shorewall 1.3.4 Released
-
- In this version:
-
-
- - A new /etc/shorewall/routestopped
- file has been added. This file is intended to eventually
- replace the routestopped option in the
- /etc/shorewall/interface and /etc/shorewall/hosts files. This
- new file makes remote firewall administration easier by
- allowing any IP or subnet to be enabled while Shorewall is
- stopped.
-
- - An /etc/shorewall/stopped extension script has been
- added. This script is invoked after Shorewall has
- stopped.
-
- - A DETECT_DNAT_ADDRS option has been added to /etc/shoreall/shorewall.conf.
- When this option is selected, DNAT rules only apply when the
- destination address is the external interface's primary IP
- address.
-
- - The QuickStart
- Guide has been broken into three guides and has been
- almost entirely rewritten.
-
- - The Samples have been updated to reflect the new
- capabilities in this release.
-
-
- 7/8/2002 - Shorewall 1.3.3 Debian Package
- Available
-
- Lorenzo Marignoni reports that the packages are available at
- http://security.dsi.unimi.it/~lorenzo/debian.html.
-
- 7/6/2002 - Shorewall 1.3.3 Released
-
- In this version:
-
-
- - Entries in /etc/shorewall/interface that use the wildcard
- character ("+") now have the "multi" option assumed.
-
- - The 'rfc1918' chain in the mangle table has been renamed
- 'man1918' to make log messages generated from that chain
- distinguishable from those generated by the 'rfc1918' chain
- in the filter table.
-
- - Interface names appearing in the hosts file are now
- validated against the interfaces file.
-
- - The TARGET column in the rfc1918 file is now checked for
- correctness.
-
- - The chain structure in the nat table has been changed to
- reduce the number of rules that a packet must traverse and to
- correct problems with NAT_BEFORE_RULES=No
-
- - The "hits" command has been enhanced.
-
-
- 6/25/2002 - Samples Updated for 1.3.2
-
- The comments in the sample configuration files have been
- updated to reflect new features introduced in Shorewall
- 1.3.2.
-
- 6/25/2002 - Shorewall 1.3.1 Debian Package
- Available
-
- Lorenzo Marignoni reports that the package is available at
- http://security.dsi.unimi.it/~lorenzo/debian.html.
-
- 6/19/2002 - Documentation Available in PDF Format
-
- Thanks to Mike Martinez, the Shorewall Documentation is now
- available for download in Adobe PDF format.
-
- 6/16/2002 - Shorewall 1.3.2 Released
-
- In this version:
-
-
-
- 6/6/2002 - Why CVS Web access is Password
- Protected
-
- Last weekend, I installed the CVS Web package to provide
- brower-based access to the Shorewall CVS repository. Since
- then, I have had several instances where my server was almost
- unusable due to the high load generated by website copying
- tools like HTTrack and WebStripper. These mindless tools:
-
-
- - Ignore robot.txt files.
-
- - Recursively copy everything that they find.
-
- - Should be classified as weapons rather than tools.
-
-
- These tools/weapons are particularly damaging when combined
- with CVS Web because they doggedly follow every link in the
- cgi-generated HTML resulting in 1000s of executions of the
- cvsweb.cgi script. Yesterday, I spend several hours
- implementing measures to block these tools but unfortunately,
- these measures resulted in my server OOM-ing under even
- moderate load.
-
- Until I have the time to understand the cause of the OOM (or
- until I buy more RAM if that is what is required), CVS Web
- access will remain Password Protected.
-
- 6/5/2002 - Shorewall 1.3.1 Debian Package
- Available
-
- Lorenzo Marignoni reports that the package is available at
- http://security.dsi.unimi.it/~lorenzo/debian.html.
-
- 6/2/2002 - Samples Corrected
-
- The 1.3.0 samples configurations had several serious
- problems that prevented DNS and SSH from working properly.
- These problems have been corrected in the 1.3.1 samples.
-
- 6/1/2002 - Shorewall 1.3.1 Released
-
- Hot on the heels of 1.3.0, this release:
-
-
- - Corrects a serious problem with "all <zone>
- CONTINUE" policies. This problem is present in all versions
- of Shorewall that support the CONTINUE policy. These previous
- versions optimized away the "all2<zone>" chain
- and replaced it with the "all2all" chain with the usual
- result that a policy of REJECT was enforced rather than the
- intended CONTINUE policy.
-
- - Adds an /etc/shorewall/rfc1918 file
- for defining the exact behavior of the 'norfc1918' interface
- option.
-
-
- 5/29/2002 - Shorewall 1.3.0 Released
-
- In addition to the changes in Beta 1, Beta 2 and RC1,
- Shorewall 1.3.0 includes:
-
-
- - A 'filterping' interface option that allows ICMP
- echo-request (ping) requests addressed to the firewall to be
- handled by entries in /etc/shorewall/rules and
- /etc/shorewall/policy.
-
-
- 5/23/2002 - Shorewall 1.3 RC1 Available
-
- In addition to the changes in Beta 1 and Beta 2, RC1
- (Version 1.2.92) incorporates the following:
-
-
- - Support for the /etc/shorewall/whitelist file has been
- withdrawn. If you need whitelisting, see these
- instructions.
-
-
- 5/19/2002 - Shorewall 1.3 Beta 2 Available
-
- In addition to the changes in Beta 1, this release which
- carries the designation 1.2.91 adds:
-
-
- - The structure of the firewall is changed markedly. There
- is now an INPUT and a FORWARD chain for each interface; this
- reduces the number of rules that a packet must traverse,
- especially in complicated setups.
-
- - Sub-zones may now be
- excluded from DNAT and REDIRECT rules.
-
- - The names of the columns in a number of the configuration
- files have been changed to be more consistent and
- self-explanatory and the documentation has been updated
- accordingly.
-
- - The sample configurations have been updated for 1.3.
-
-
- 5/17/2002 - Shorewall 1.3 Beta 1 Available
-
- Beta 1 carries the version designation 1.2.90 and implements
- the following features:
-
-
- - Simplified rule syntax which makes the intent of each
- rule clearer and hopefully makes Shorewall easier to
- learn.
-
- - Upward compatibility with 1.2 configuration files has
- been maintained so that current users can migrate to the new
- syntax at their convenience.
-
- - WARNING: Compatibility
- with the old parameterized sample configurations has NOT been
- maintained. Users still running those configurations should
- migrate to the new sample configurations before upgrading to
- 1.3 Beta 1.
-
-
- 5/4/2002 - Shorewall 1.2.13 is Available
-
- In this version:
-
-
-
- 4/30/2002 - Shorewall Debian News
-
- Lorenzo Marignoni reports that Shorewall 1.2.12 is now in
- both the Debian
- Testing Branch and the Debian
- Unstable Branch.
-
- 4/20/2002 - Shorewall 1.2.12 is Available
-
-
- - The 'try' command works again
-
- - There is now a single RPM that also works with SUSE.
-
-
- 4/17/2002 - Shorewall Debian News
-
- Lorenzo Marignoni reports that:
-
-
-
- Thanks, Lorenzo!
-
- 4/16/2002 - Shorewall 1.2.11 RPM Available for
- SUSE
-
- Thanks to Stefan
- Mohr, there is now a Shorewall 1.2.11
- SUSE RPM available.
-
- 4/13/2002 - Shorewall 1.2.11 Available
-
- In this version:
-
-
- - The 'try' command now accepts an optional timeout. If the
- timeout is given in the command, the standard configuration
- will automatically be restarted after the new configuration
- has been running for that length of time. This prevents a
- remote admin from being locked out of the firewall in the
- case where the new configuration starts but prevents
- access.
-
- - Kernel route filtering may now be enabled globally using
- the new ROUTE_FILTER parameter in /etc/shorewall/shorewall.conf.
-
- - Individual IP source addresses and/or subnets may now be
- excluded from masquerading/SNAT.
-
- - Simple "Yes/No" and "On/Off" values are now
- case-insensitive in /etc/shorewall/shorewall.conf.
-
-
- 4/13/2002 - Hamburg Mirror now has FTP
-
- Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.
- Thanks Stefan!
-
- 4/12/2002 - New Mirror in Hamburg
-
- Thanks to Stefan
- Mohr, there is now a mirror of the Shorewall website at http://germany.shorewall.net.
-
- 4/10/2002 - Shorewall QuickStart Guide Version 1.1
- Available
-
- Version 1.1 of the
- QuickStart Guide is now available. Thanks to those who have
- read version 1.0 and offered their suggestions. Corrections
- have also been made to the sample scripts.
-
- 4/9/2002 - Shorewall QuickStart Guide Version 1.0
- Available
-
- Version 1.0 of the
- QuickStart Guide is now available. This Guide and its
- accompanying sample configurations are expected to provide a
- replacement for the recently withdrawn parameterized
- samples.
-
- 4/8/2002 - Parameterized Samples Withdrawn
-
- Although the parameterized
- samples have allowed people to get a firewall up and
- running quickly, they have unfortunately set the wrong level of
- expectation among those who have used them. I am therefore
- withdrawing support for the samples and I am recommending that
- they not be used in new Shorewall installations.
-
- 4/2/2002 - Updated Log Parser
-
- John Lodge has
- provided an updated version of his CGI-based log parser with
- corrected date handling.
-
- 3/30/2002 - Shorewall Website Search Improvements
-
- The quick search on the home page now excludes the mailing
- list archives. The Extended
- Search allows excluding the archives or restricting the
- search to just the archives. An archive search form is also
- available on the mailing list
- information page.
-
- 3/28/2002 - Debian Shorewall News (From Lorenzo
- Martignoni)
-
-
-
- 3/25/2002 - Log Parser Available
-
- John Lodge has
- provided a CGI-based log
- parser for Shorewall. Thanks John.
-
- 3/20/2002 - Shorewall 1.2.10 Released
-
- In this version:
-
-
- - A "shorewall try" command has been added (syntax:
- shorewall try <configuration directory>). This
- command attempts "shorewall -c <configuration
- directory> start" and if that results in the firewall
- being stopped due to an error, a "shorewall start" command is
- executed. The 'try' command allows you to create a new configuration and
- attempt to start it; if there is an error that leaves your
- firewall in the stopped state, it will automatically be
- restarted using the default configuration (in
- /etc/shorewall).
-
- - A new variable ADD_SNAT_ALIASES has been added to /etc/shorewall/shorewall.conf.
- If this variable is set to "Yes", Shorewall will
- automatically add IP addresses listed in the third column of
- the /etc/shorewall/masq
- file.
-
- - Copyright notices have been added to the
- documenation.
-
-
- 3/11/2002 - Shorewall 1.2.9 Released
-
- In this version:
-
-
- -
- Filtering by MAC
- address has been added. MAC addresses may be used as
- the source address in:
-
-
+
+ Interface names appearing within the
+ configuration are now verified. Interface names must match the name of an
+ entry in /etc/shorewall/interfaces (or if bridging is enabled, they must
+ match the name of an entry in /etc/shorewall/interfaces or the name of a
+ bridge port appearing in /etc/shorewall/hosts).
+ A new 'rejNotSyn' built-in standard
+ action has been added. This action responds to "New not SYN" packets with
+ an RST.
+
+ The 'dropNonSyn' action has been superceded by the new 'dropNotSyn'
+ action. The old name will be accepted until the next major release of
+ Shorewall but will generate a warning.
+
+ Several new logging actions involving "New not SYN" packets have been
+ added:
+
+ logNewNotSyn -- logs the
+ packet with disposition = LOG
+ dLogNewNotSyn -- logs the
+ packet with disposition = DROP
+ rLogNewNotSyn -- logs the
+ packet with disposition = REJECT
+
+ The packets are logged at the log level specified in the LOGNEWNOTSYN
+ option in shorewall.conf. If than option is empty or not specified, then
+ 'info' is assumed.
+
+ Examples (In all cases, set NEWNOTSYN=Yes in shorewall.conf):
+
+ To simulate the behavior of
+ NEWNOTSYN=No:
+
+ Add 'NoNewNotSyn' to
+ /etc/shorewall/actions.
+ Create /etc/shorewall/action.NoNewNotSyn containing:
+
+
+ dLogNotSyn
+
+ dropNotSyn
+ Early in your rules file, place:
+
+
+ NoNewNotSyn all
+ all tcp
+
- Several bugs have been fixed
-
- - The 1.2.9 Debian Package is also available at http://security.dsi.unimi.it/~lorenzo/debian.html.
-
-
- 3/1/2002 - 1.2.8 Debian Package is Available
-
- See http://security.dsi.unimi.it/~lorenzo/debian.html
-
- 2/25/2002 - New Two-interface Sample
-
- I've enhanced the two interface sample to allow access from
- the firewall to servers in the local zone -
- http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz
-
- 2/23/2002 - Shorewall 1.2.8 Released
-
- Do to a serious problem with 1.2.7, I am releasing 1.2.8. It
- corrects problems associated with the lock file used to prevent
- multiple state-changing operations from occuring
- simultaneously. My apologies for any inconvenience my
- carelessness may have caused.
-
- 2/22/2002 - Shorewall 1.2.7 Released
-
- In this version:
-
-
- - UPnP probes (UDP destination port 1900) are now silently
- dropped in the common chain
-
- - RFC 1918 checking in the mangle table has been
- streamlined to no longer require packet marking. RFC 1918
- checking in the filter table has been changed to require half
- as many rules as previously.
-
- - A 'shorewall check' command has been added that does a
- cursory validation of the zones, interfaces, hosts, rules and
- policy files.
-
-
- 2/18/2002 - 1.2.6 Debian Package is Available
-
- See http://security.dsi.unimi.it/~lorenzo/debian.html
-
- 2/8/2002 - Shorewall 1.2.6 Released
-
- In this version:
-
-
- - $-variables may now be used anywhere in the configuration
- files except /etc/shorewall/zones.
-
- - The interfaces and hosts files now have their contents
- validated before any changes are made to the existing
- Netfilter configuration. The appearance of a zone name that
- isn't defined in /etc/shorewall/zones causes "shorewall
- start" and "shorewall restart" to abort without changing the
- Shorewall state. Unknown options in either file cause a
- warning to be issued.
-
- - A problem occurring when BLACKLIST_LOGLEVEL was not set
- has been corrected.
-
-
- 2/4/2002 - Shorewall 1.2.5 Debian Package
- Available
-
- see http://security.dsi.unimi.it/~lorenzo/debian.html
-
- 2/1/2002 - Shorewall 1.2.5 Released
-
- Due to installation problems with Shorewall 1.2.4, I have
- released Shorewall 1.2.5. Sorry for the rapid-fire
- development.
-
- In version 1.2.5:
-
-
- - The installation problems have been corrected.
-
- - SNAT is now
- supported.
-
- - A "shorewall version" command has been added
-
- - The default value of the STATEDIR variable in
- /etc/shorewall/shorewall.conf has been changed to
- /var/lib/shorewall in order to conform to the GNU/Linux File
- Hierarchy Standard, Version 2.2.
-
-
- 1/28/2002 - Shorewall 1.2.4 Released
-
-
- - The "fw" zone may now be
- given a different name.
-
- - You may now place end-of-line comments (preceded by '#')
- in any of the configuration files
-
- - There is now protection against against two state
- changing operations occuring concurrently. This is
- implemented using the 'lockfile' utility if it is available
- (lockfile is part of procmail); otherwise, a less robust
- technique is used. The lockfile is created in the STATEDIR
- defined in /etc/shorewall/shorewall.conf and has the name
- "lock".
-
- - "shorewall start" no longer fails if "detect" is
- specified in /etc/shorewall/interfaces
- for an interface with subnet mask 255.255.255.255.
-
-
- 1/27/2002 - Shorewall 1.2.3 Debian Package Available
- -- see http://security.dsi.unimi.it/~lorenzo/debian.html
-
- 1/20/2002 - Corrected firewall script
- available
-
- Corrects a problem with BLACKLIST_LOGLEVEL. See the errata for details.
-
- 1/19/2002 - Shorewall 1.2.3 Released
-
- This is a minor feature and bugfix release. The single new
- feature is:
-
-
- - Support for TCP MSS Clamp to PMTU -- This support is
- usually required when the internet connection is via PPPoE or
- PPTP and may be enabled using the CLAMPMSS option in
- /etc/shorewall/shorewall.conf.
-
-
- The following problems were corrected:
-
-
- - The "shorewall status" command no longer hangs.
-
- - The "shorewall monitor" command now displays the icmpdef
- chain
-
- - The CLIENT PORT(S) column in tcrules is no longer
- ignored
-
-
- 1/18/2002 - Shorewall 1.2.2 packaged with new LEAF release
-
- Jacques Nilo and Eric Wolzak have released a kernel 2.4.16
- LEAF distribution that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo
- for details.
-
- 1/11/2002 - Debian Package (.deb) Now Available -
- Thanks to Lorenzo
- Martignoni, a 1.2.2 Shorewall Debian package is now
- available. There is a link to Lorenzo's site from the Shorewall download page.
-
- 1/9/2002 - Updated 1.2.2 /sbin/shorewall available -
- This corrected
- version restores the "shorewall status" command to
- health.
-
- 1/8/2002 - Shorewall 1.2.2 Released
-
- In version 1.2.2
-
-
+ Slackware users no longer have to modify the install.sh script
+ before installation. Tuomo Soini has provided a change that allows the
+ INIT and FIREWALL variables to be specified outside the script as in:
+
+ DEST=/etc/rc.d INIT=rc.firewall
+ ./install.sh
+
+
-
- Use of TCP RST replies has been expanded
+6/3/2004 - Shorewall 2.0.2f
+
-
- - TCP connection requests rejected because of a REJECT
- policy are now replied with a TCP RST packet.
+Fixes one problem:
+
+
+ - Versions 2.0.2d and 2.0.2e fail to load kernel modules unless
+ MODULE_SUFFIX is set in shorewall.conf
+
+
- - TCP connection requests rejected because of a
- protocol=all rule in /etc/shorewall/rules are now replied
- with a TCP RST packet.
-
+6/2/2004 - Shorewall 2.0.2e
+
+
+One problem corrected:
+
+
+ - LOG rules within an action generate two Netfilter logging rules.
+
+
+
+5/28/2004 - Shorewall 2.0.2d
+
+One problem corrected:
+
+
+ - Shorewall was checking capabilities before loading kernel modules.
+ Consequently, if kernel module autoloading was disabled, the capabilities
+ were mis-detected.
+
+
+
+5/21/2004 - Shorewall 2.0.2c
+One problem corrected:
+
+
+ - DNAT rules with a dynamic source zone don't work properly. When
+ used, these rules cause the rule to be checked against ALL input,
+ not just input from the designated zone.
+
+
+
+5/18/2004 - Shorewall 2.0.2b
+
+Corrects two problems:
+
+ - Specifying a null common action in /etc/shorewall/actions (e.g.,
+ :REJECT) results in a startup error.
+
+
+ - If /var/lib/shorewall does not exist, shorewall start fails.
+
+
+
+5/15/2004 - Shorewall 2.0.2a
+
+
+Corrects two problems:
+
+
+ - Temporary restore files were not being removed from /var/lib/shorewall.
+ These files have names of the form 'restore-nnnnn'. You can remove
+ files that have accumulated with the command:
+
+ rm -f /var/lib/shorewall/restore-[0-9]*
+
+
+ - The restore script did not load kernel modules. The result was that
+ after a cold load, applications like FTP and IRC DCC didn't work.
+
+ To correct:
+
+ 1) Install 2.0.2a
+ 2) "shorewall restart"
+ 3) "shorewall save"
+
+
+5/13/2004 - Shorewall 2.0.2
+
+Problems Corrected since 2.0.1
+
+
+ - The /etc/init.d/shorewall script installed on Debian by install.sh
+ failed silently due to a missing file (/usr/share/shorewall/wait4ifup).
+ That file is not part of the normal Shorewall distribution and is
+ provided by the Debian maintainer.
+ - A meaningless warning message out of the proxyarp file processing has
+ been eliminated.
+ - The "shorewall delete" command now correctly removes all dynamic rules
+ pertaining to the host(s) being deleted. Thanks to Stefan Engel for this
+ correction.
+
+Issues when migrating from Shorewall 2.0.1 to Shorewall 2.0.2:
+
+
+ - Extension Scripts -- In order for extension scripts to work properly
+ with the new iptables-save/restore integration (see New Feature 1 below),
+ some change may be required to your extension scripts. If your extension
+ scripts are executing commands other than iptables then those commands
+ must also be written to the restore file (a temporary file in
+ /var/lib/shorewall that is renamed /var/lib/shorewall/restore-base at the
+ end of the operation).
+
+ The following functions should be of help:
+
+ A. save_command() -- saves the passed command to the restore file.
+
+ Example:
+
+ save_command echo Operation
+ Complete
+
+ That command would simply write "echo Operation Complete" to
+ the restore file.
+
+ B. run_and_save_command() -- saves the passed command to the restore file
+ then executes it. The return value is the exit status of the command.
+
+ Example:
+
+ run_and_save_command "echo 1 >
+ /proc/sys/net/ipv4/icmp_echo_ignore_all"
+
+ Note that as in this example, when the command
+ involves file redirection then the entire command must be enclosed in
+ quotes. This applies to all of the functions described here.
+
+ C. ensure_and_save_command() -- runs the passed command. If the command
+ fails, the firewall is restored to it's prior saved state and the
+ operation is terminated. If the command succeeds, the command is written
+ to the restore file.
+
+
+ - Dynamic Zone support -- If you don't need to use the "shorewall add"
+ and "shorewall delete commands, you should set DYNAMIC_ZONES=No in
+ /etc/shorewall/shorewall.conf.
+
+New Features:
+
+
+ - Shorewall has now been integrated with iptables-save/iptables-restore
+ to provide very fast start and restart. The elements of this integration
+ are as follows:
+
+ a) The 'shorewall save' command now saves the current configuration in
+ addition to the current dynamic blacklist. If you have dynamic zones, you
+ will want to issue 'shorewall save' when the zones are empty or the
+ current contents of the zones will be restored by the 'shorewall restore'
+ and 'shorewall -f start' commands.
+
+ b) The 'shorewall restore' command has been added. This command restores
+ the configuration at the time of the last 'save'.
+
+ c) The -f (fast) option has been added to 'shorewall start'. When
+ specified (e.g. 'shorewall -f start'), shorewall will perform a
+ 'shorewall restore' if there is a saved configuration. If there is no
+ saved configuration, a normal 'shorewall start' is performed.
+
+ d) The /etc/init.d/shorewall script now translates the 'start' command
+ into 'shorewall -f start' so that fast restart is possible.
+
+ e) When a state-changing command encounters an error and there is current
+ saved configuration, that configuration will be restored (currently, the
+ firewall is placed in the 'stopped' state).
+
+ f) If you have previously saved the running configuration and want
+ Shorewall to discard it, use the 'shorewall forget' command. WARNING:
+ iptables 1.2.9 is broken with respect to iptables-save; if your kernel
+ has connection tracking match support, you must patch iptables 1.2.9 with
+ the iptables patch availale from the Shorewall errata page.
+
+
+ - The previous implementation of dynamic zones was difficult to maintain.
+ I have changed the code to make dynamic zones optional under the control
+ of the DYNAMIC_ZONES option in /etc/shorewall/shorewall.conf.
+
+
+ - In earlier Shorewall 2.0 releases, Shorewall searches in order the
+ following directories for configuration files.
+
+ a) The directory specified in a 'try' command or specified using the -c
+ option.
+ b) /etc/shorewall
+ c) /usr/share/shorewall
+
+ In this release, the CONFIG_PATH option is added to shorewall.conf.
+ CONFIG_PATH contains a list of directory names separated by colons (":").
+ If not set or set to a null value (e.g., CONFIG_PATH="") then
+ "CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed. Now
+ Shorewall searches for shorewall.conf according to the old rules and for
+ other configuration files as follows:
+
+ a) The directory specified in a 'try' command or specified using the -c
+ option.
+ b) Each directory in $CONFIG_PATH is searched in sequence.
+
+ In case it is not obvious, your CONFIG_PATH should include
+ /usr/share/shorewall and your shorewall.conf file must be in the
+ directory specified via -c or in a try command, in /etc/shorewall or in
+ /usr/share/shorewall.
+
+ For distribution packagers, the default CONFIG_PATH is set in
+ /usr/share/shorewall/configpath. You can customize this file to have a
+ default that differs from mine.
+
+
+ - Previously, in /etc/shorewall/nat a Yes (or yes) in the LOCAL column
+ would only take effect if the ALL INTERFACES column also contained Yes or
+ yes. Now, the LOCAL columns contents are treated independently of the
+ contents of the ALL INTERFACES column.
+
+
+ - The folks at Mandrake have created yet another kernel module naming
+ convention (module names end in "ko.gz"). As a consequence, beginning
+ with this release, if MODULE_SUFFIX isn't specified in shorewall.conf,
+ then the default value is "o gz ko o.gz ko.gz".
+
+
+ - An updated bogons file is included in this release.
+
+
+ - In /etc/shorewall/rules and in action files generated from
+ /usr/share/shorewall/action.template, rules that perform logging can
+ specify an optional "log tag". A log tag is a string of alphanumeric
+ characters and is specified by following the log level with ":" and the
+ log tag.
+
+ Example:
+
+ ACCEPT:info:ftp
+ net dmz
+ tcp 21
+
+ The log tag is appended to the log prefix generated by the LOGPREFIX
+ variable in /etc/shorewall/conf. If "ACCEPT:info" generates the log
+ prefix "Shorewall:net2dmz:ACCEPT:" then "ACCEPT:info:ftp" will generate
+ "Shorewall:net2dmz:ACCEPT:ftp " (note the trailing blank). The maximum
+ length of a log prefix supported by iptables is 29 characters; if a
+ larger prefix is generated, Shorewall will issue a warning message and
+ will truncate the prefix to 29 characters.
+
+
+ - A new "-q" option has been added to /sbin/shorewall commands. It causes
+ the start, restart, check and refresh commands to produce much less
+ output so that warning messages are more visible (when testing this
+ change, I discovered a bug where a bogus warning message was being
+ generated).
+
+
+ - Shorewall now uses 'modprobe' to load kernel modules if that utility is
+ available in the PATH; otherwise, 'insmod' is used.
+
+
+ - It is now possible to restrict entries in the /etc/shorewall/masq file
+ to particular protocols and destination port(s). Two new columns (PROTO
+ and PORT(S)) have been added to the file.
+
+ Example:
+
+ You want all outgoing SMTP traffic entering the firewall on eth1 to be
+ sent from eth0 with source IP address 206.124.146.177. You want all other
+ outgoing traffic from eth1 to be sent from eth0 with source IP address
+ 206.124.146.176.
+
+ eth0
+ eth1 206.124.146.177 tcp 25
+ eth0
+ eth1 206.124.146.176
+
+ THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!
+
+ Assuming that 10.0.0.0/8 is the only host/network connected to eth1, the
+ progress message at "shorewall start" would be:
+
+ Masqueraded Networks and Hosts:
+ To 0.0.0.0/0 (tcp 25) from
+ 10.0.0.0/8 through eth0 using 206.124.146.177
+ To 0.0.0.0/0 (all) from 10.0.0.0/8
+ through eth0 using 206.124.146.176
+
+
+ - Two new actions are available in the /etc/shorewall/rules file.
+
+ ACCEPT+ -- Behaves like ACCEPT with
+ the exception that it exempts matching connections from subsequent
+ DNAT[-] and REDIRECT[-] rules.
+ NONAT -- Exempts
+ matching connections from subsequent DNAT[-] and REDIRECT[-] rules.
+
+
+ - A new extension script 'initdone' has been added. This script is
+ invoked at the same point as the 'common' script was previously and is
+ useful for users who mis-used that script under Shorewall 1.x (the script
+ was intended for adding rules to the 'common' chain but many users
+ treated it as a script for adding rules before Shorewall's).
+
+
+ - Installing/Upgrading Shorewall on Slackware has been improved.
+ Slackware users must use the tarball and must modify settings in the
+ install.sh script before running it as follows:
+
+ DEST="/etc/rc.d"
+ INIT="rc.firewall"
+
+ Thanks to Alex Wilms for helping with this change.
+
+
+4/17/2004 - Presentation at LinuxFest NW
+
+Today I gave a presentation at LinuxFest NW in Bellingham. The presentation
+was entitled "Shorewall and the Enterprise" and described the history
+of Shorewall and gave an overview of its features.
+
+4/5/2004 - Shorewall 2.0.1
+
+Problems Corrected since 2.0.0
+
+
+
+ - Using actions in the manner recommended in the documentation results in
+ a Warning that the rule is a policy.
+ - When a zone on a single interface is defined using
+ /etc/shorewall/hosts, superfluous rules are generated in the
+ <zone>_frwd chain.
+ - Thanks to Sean Mathews, a long-standing problem with Proxy ARP and
+ IPSEC has been corrected. Thanks Sean!!!
+ - The "shorewall show log" and "shorewall logwatch" commands incorrectly
+ displayed type 3 ICMP packets.
+
+
+Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:
+
+
+
+ - The function of 'norfc1918' is now split between that option and a new
+ 'nobogons' option.
+
+ The rfc1918 file released with Shorewall now contains entries for only
+ those three address ranges reserved by RFC 1918. A 'nobogons' interface
+ option has been added which handles bogon source addresses (those which
+ are reserved by the IANA, those reserved for DHCP auto-configuration and
+ the class C test-net reserved for testing and documentation examples).
+ This will allow users to perform RFC 1918 filtering without having to
+ deal with out of date data from IANA. Those who are willing to update
+ their /usr/share/shorewall/bogons file regularly can specify the
+ 'nobogons' option in addition to 'norfc1918'.
+
+ The level at which bogon packets are logged is specified in the new
+ BOGON_LOG_LEVEL variable in shorewall.conf. If that option is not
+ specified or is specified as empty (e.g, BOGON_LOG_LEVEL="") then bogon
+ packets whose TARGET is 'logdrop' in /usr/share/shorewall/bogons are
+ logged at the 'info' level.
+
+New Features:
+
+
+
+ - Support for Bridging Firewalls has been added. For details, see
+
+ http://shorewall.net/bridge.html
+
+
+ - Support for NETMAP has been added. NETMAP allows NAT to be defined
+ between two network:
+
+
+ a.b.c.1 -> x.y.z.1
+
+ a.b.c.2 -> x.y.z.2
+
+ a.b.c.3 -> x.y.z.3
+ ...
+
+ http://shorewall.net/netmap.htm
+
+
+ - The /sbin/shorewall program now accepts a "-x" option to cause iptables
+ to print out the actual packet and byte counts rather than abbreviated
+ counts such as "13MB".
+
+ Commands affected by this are:
+
+
+ shorewall -x show [ <chain>[ <chain> ...] ]
+
+ shorewall -x show tos|mangle
+
+ shorewall -x show nat
+
+ shorewall -x status
+
+ shorewall -x monitor [ <interval> ]
+
+
+ - Shorewall now traps two common zone definition errors:
+
+
+ - Including the firewall zone in a /etc/shorewall/hosts record.
+ - Defining an interface for a zone in both /etc/shorewall/interfaces
+ and /etc/shorewall/hosts.
+
-
- - A LOGFILE
- specification has been added to
- /etc/shorewall/shorewall.conf. LOGFILE is used to tell the
- /sbin/shorewall program where to look for Shorewall
- messages.
+
+ - In the second case, the following will appear during "shorewall
+ [re]start" or "shorewall check":
+
+ Determining Hosts in Zones...
+ ...
+ Error: Invalid zone definition for zone
+ <name of zone>
+ Terminated
+
+
+ - To support bridging, the following options have been added to entries
+ in /etc/shorewall/hosts:
+
+ norfc1918
+ nobogons
+ blacklist
+ tcpflags
+ nosmurfs
+ newnotsyn
+
+ With the exception of 'newnotsyn', these options are only useful when the
+ entry refers to a bridge port.
+
+ Example:
+
+ #ZONE HOST(S)
+ OPTIONS
+ net br0:eth0
+ norfc1918,nobogons,blacklist,tcpflags,nosmurfs
+
- 1/5/2002 - New Parameterized Samples (version 1.2.0) released. These are minor
- updates to the previously-released samples. There are two new
- rules added:
+3/14/2004 - Shorewall 2.0.0b
+Corrects two problems:
+
+ - Thanks to Sean Mathews, the long-standing problem with Proxy ARP and
+ IPSEC has been eliminated!
+ - The default value of the ALL INTERFACES column in /etc/shorewall/nat is
+ documented as 'No' but the default continued to be 'Yes' as it was in
+ Shorewall 1.4.
+
+
+
+3/14/2004 - Shorewall 2.0.0a
+
+Corrects one problem:
+
+
+ - Rules of the form:
+
+ <action>
+ zone1 zone2
+
+ generated a warning stating that the rule was a policy.
+
+
+
+3/14/2004 - Shorewall 2.0.0
+
+
+Dedicated to Agnes Van Slyke Eastep: March 14, 1910 - February 23, 2004
+
+
+Problems Corrected since 1.4.10
+
+
+ - A blank USER/GROUP column in /etc/shorewall/tcrules no longer causes a
+ [re]start error.
+ - The 'fgrep' utility is no longer required (caused startup problems on
+ LEAF/Bering).
+ - The "shorewall add" command no longer inserts rules before checking of
+ the blacklist.
+ - The 'detectnets' and 'routeback' options may now be used together with
+ the intended effect.
+ - The following syntax previously produced an error:
+
+ DNAT z1!z2,z3 z4...
+
+
+
+Problems Corrected since RC2
+
+
+
+ - CONTINUE rules now work again.
+ - A comment in the rules file has been corrected.
+
+
+
+Issues when migrating from Shorewall 1.4.x to Shorewall 2.0.0:
+
+
+ - The 'dropunclean' and 'logunclean' interface options are no longer
+ supported. If either option is specified in /etc/shorewall/interfaces, an
+ threatening message will be generated.
+ - The NAT_BEFORE_RULES option has been removed from shorewall.conf. The
+ behavior of Shorewall is as if NAT_BEFORE_RULES=No had been specified. In
+ other words, DNAT rules now always take precidence over one-to-one NAT
+ specifications.
+ - The default value for the ALL INTERFACES column in /etc/shorewall/nat
+ has changed. In Shorewall 1.*, if the column was left empty, a value of
+ "Yes" was assumed. This has been changed so that a value of "No" is now
+ assumed.
+ - The following files don't exist in Shorewall 2.0:
+ /etc/shorewall/common.def
+ /etc/shorewall/common
+ /etc/shorewall/icmpdef
+ /etc/shorewall/action.template (Moved to /usr/share/shorewall)
+ /etc/shorewall/rfc1918 (Moved to /usr/share/shorewall).
+
+ The /etc/shorewall/action file now allows an action to be designated as
+ the "common" action for a particular policy type by following the action
+ name with ":" and the policy (DROP, REJECT or ACCEPT).
+
+ The file /usr/share/shorewall/actions.std has been added to define those
+ actions that are released as part of Shorewall. In that file are two
+ actions as follows:
+
+ Drop:DROP
+ Reject:REJECT
+
+ The "Drop" action is the common action for DROP policies while the
+ "Reject" action is the default action for "REJECT" policies. These
+ actions will be performed on packets prior to applying the DROP or REJECT
+ policy respectively. In the first release, the difference between
+ "Reject" and "Drop" is that "Reject" REJECTs SMB traffic while "Drop"
+ silently drops such traffic.
+
+ As described above, Shorewall allows a common action for ACCEPT policies
+ but does not specify such an action in the default configuration.
+
+ If for some reason, you don't wish to have a common DROP or REJECT
+ action, just include :DROP or :REJECT respectively in your
+ /etc/shorewall/actions file.
+
+ The file /usr/share/shorewall/actions.std catalogs the standard actions
+ and is processed prior to /etc/shorewall/actions. This causes a large
+ number of actions to be defined. The files which define these aactions
+ are also located in /usr/share/shorewall as is the he action template
+ file (action.template).
+
+ These actions may be used in the ACTION column of the rules column. So
+ for example, to allow FTP from your loc zone to your firewall, you would
+ place this rule in /etc/shorewall/rules:
+
+ #ACTION
+ SOURCE DEST
+ AllowFTP
+ loc
+ fw
+
+ If you want to redefine any of the Shorewall-defined actions, simply copy
+ the appropriate action file from /usr/share/shorewall to /etc/shorewall
+ and modify the copy as desired. Your modified copy will be used rather
+ than the original one in /usr/share/shorewall.
+
+ Note: The 'dropBcast' and 'dropNonSyn' actions are built into Shorewall
+ and may not be changed.
+
+ Beginning with version 2.0.0-Beta2, Shorewall will only create a chain
+ for those actions that are actually used.
+
+
+ - The /etc/shorewall directory no longer contains a 'users' file or a
+ 'usersets' file. Similar functionality is now available using
+ user-defined actions.
+
+ Now, action files created by copying /usr/share/shorewall/action.template
+ may specify a USER and or GROUP name/id in the final column just like in
+ the rules file (see below). It is thus possible to create actions that
+ control traffic from a list of users and/or groups.
+
+ The last column in /etc/shorewall/rules is now labeled USER/GROUP and may
+ contain:
+
+ [!]<user number>[:]
+ [!]<user name>[:]
+ [!]:<group number>
+ [!]:<group name>
+ [!]<user number>:<group number>
+ [!]<user number>:<group name>
+ [!]<user name>:<group number>
+ [!]<user name>:<group name>
+
+
+ - It is no longer possible to specify rate limiting in the ACTION column
+ of /etc/shorewall/rules -- you must use the RATE LIMIT column.
+
+
+ - Depending on which method you use to upgrade, if you have your own
+ version of /etc/shorewall/rfc1918, you may have to take special action to
+ restore it after the upgrade. Look for /etc/shorewall/rfc1918*, locate
+ the proper file and rename it back to /etc/shorewall/rfc1918. The
+ contents of that file will supercede the contents of
+ /usr/share/shorewall/rfc1918.
+
+
+New Features:
+
+
+ - The INCLUDE directive now allows absolute file names.
+ - A 'nosmurfs' interface option has been added to
+ /etc/shorewall/interfaces. When specified for an interface, this option
+ causes smurfs (packets with a broadcast address as their source) to be
+ dropped and optionally logged (based on the setting of a new
+ SMURF_LOG_LEVEL option in shorewall.conf).
+ - fw->fw traffic may now be controlled by Shorewall. There is no need
+ to define the loopback interface in /etc/shorewall/interfaces; you simply
+ add a fw->fw policy and fw->fw rules. If you have neither a
+ fw->fw policy nor fw->fw rules, all fw->fw traffic is
+ allowed.
+ - There is a new PERSISTENT column in the proxyarp file. A value of "Yes"
+ in this column means that the route added by Shorewall for this host will
+ remain after a "shorewall stop" or "shorewall clear".
+ - "trace" is now a synonym for "debug" in /sbin/shorewall commands. So to
+ trace the "start" command, you could enter:
+
+ shorewall trace start 2> /tmp/trace
+
+ The trace information would be written to the file /tmp/trace.
+
+
+ - When defining an ipsec tunnel in /etc/shorewall/tunnels, if you follow
+ the tunnel type ("ipsec" or "ipsecnet") with ":noah" (e.g.,
+ "ipsec:noah"), then Shorewall will only create rules for ESP (protocol
+ 50) and will not create rules for AH (protocol 51).
+ - A new DISABLE_IPV6 option has been added to shorewall.conf. When this
+ option is set to "Yes", Shorewall will set the policy for the IPv6 INPUT,
+ OUTPUT and FORWARD chains to DROP during "shorewall [re]start" and
+ "shorewall stop". Regardless of the setting of this variable, "shorewall
+ clear" will silently attempt to set these policies to ACCEPT.
+
+ If this option is not set in your existing shorewall.conf then a setting
+ of DISABLE_IPV6=No is assumed in which case, Shorewall will not touch any
+ IPv6 settings except during "shorewall clear".
+ - The CONTINUE target is now available in action definitions. CONTINUE
+ terminates processing of the current action and returns to the point
+ where that action was invoked.
+
+
+2/15/2004 - Shorewall 1.4.10c
+
+Corrects one problem:
+
+Entries in /etc/shorewall/tcrules with an empty USER/GROUP column would cause
+a startup error.
+
+2/12/2004 - Shorewall 1.4.10b
+
+Corrects one problem:
+
+
+ - In the /etc/shorewall/masq entry “eth0:!10.1.1.150 0.0.0.0/0!10.1.0.0/16
+ 10.1.2.16â€, the “!10.1.0.0/16†is ignored.
+
+
+2/8/2004 - Shorewall 1.4.10a
+
+Corrects two problems:
+
+
+ - A problem which can cause [re]start to fail inexplicably while
+ processing /etc/shorewall/masq.
+ - Interfaces using the Atheros WiFi card to use the 'maclist' option.
+
+
+1/30/2004 - Shorewall 1.4.10
+
+Problems Corrected since version 1.4.9
+
+ - The column descriptions in the action.template file did not match the
+ column headings. That has been corrected.
+ - The presence of IPV6 addresses on devices generated error messages
+ during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
+ specified in /etc/shorewall/shorewall.conf. These messages have been
+ eliminated.
+ - The CONTINUE action in /etc/shorewall/rules now works
+ correctly. A couple of problems involving rate limiting have been
+ corrected. These bug fixes courtesy of Steven Jan Springl.
+ - Shorewall now tried to avoid sending an ICMP response to broadcasts and
+ smurfs.
+ - Specifying "-" or "all" in the PROTO column of an action no longer
+ causes a startup error.
+
+Migragion Issues:
+
+ None.
+
+New Features:
+
+
+ - The INTERFACE column in the /etc/shorewall/masq file may now specify a
+ destination list.
+
+ Example:
+
+ #INTERFACE
+ SUBNET ADDRESS
+ eth0:192.0.2.3,192.0.2.16/28 eth1
+
+ If the list begins with "!" then SNAT will occur only if the destination
+ IP address is NOT included in the list.
+
+
+ - Output traffic control rules (those with the firewall as the source)
+ may now be qualified by the effective userid and/or effective group id of
+ the program generating the output. This feature is courtesy of
+ Frédéric LESPEZ.
+
+ A new USER column has been added to /etc/shorewall/tcrules. It may
+ contain :
+
+ [<user name or number>]:[<group
+ name or number>]
+
+ The colon is optionnal when specifying only a user.
+
+ Examples : john: / john / :users /
+ john:users
+
+
+ - A "detectnets" interface option has been added for entries in
+ /etc/shorewall/interfaces. This option automatically tailors the
+ definition of the zone named in the ZONE column to include just
+ those hosts that have routes through the interface named in the INTERFACE
+ column. The named interface must be UP when Shorewall is [re]started.
+
+ WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
+
+
+
+1/27/2004 - Shorewall 1.4.10 RC3
+
+http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+
+
+Problems Corrected since version 1.4.9
+
+ - The column descriptions in the action.template file did not match the
+ column headings. That has been corrected.
+ - The presence of IPV6 addresses on devices generated error messages
+ during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
+ specified in /etc/shorewall/shorewall.conf. These messages have been
+ eliminated.
+ - The CONTINUE action in /etc/shorewall/rules now works
+ correctly. A couple of problems involving rate limiting have been
+ corrected. These bug fixes courtesy of Steven Jan Springl.
+ - Shorewall now tried to avoid sending an ICMP response to broadcasts and
+ smurfs.
+
+
+Migragion Issues:
+
+ None.
+
+New Features:
+
+
+ - The INTERFACE column in the /etc/shorewall/masq file may now specify a
+ destination list.
+
+ Example:
+
+ #INTERFACE
+ SUBNET ADDRESS
+ eth0:192.0.2.3,192.0.2.16/28 eth1
+
+ If the list begins with "!" then SNAT will occur only if the destination
+ IP address is NOT included in the list.
+
+
+ - Output traffic control rules (those with the firewall as the source)
+ may now be qualified by the effective userid and/or effective group id of
+ the program generating the output. This feature is courtesy of
+ Frédéric LESPEZ.
+
+ A new USER column has been added to /etc/shorewall/tcrules. It may
+ contain :
+
+ [<user name or number>]:[<group
+ name or number>]
+
+ The colon is optionnal when specifying only a user.
+
+ Examples : john: / john / :users /
+ john:users
+
+
+ - A "detectnets" interface option has been added for entries in
+ /etc/shorewall/interfaces. This option automatically tailors the
+ definition of the zone named in the ZONE column to include just
+ those hosts that have routes through the interface named in the INTERFACE
+ column. The named interface must be UP when Shorewall is [re]started.
+
+ WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
+
+
+
+1/24/2004 - Shorewall 1.4.10 RC2
+
+http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+
+
+Problems Corrected since version 1.4.9
+
+ - The column descriptions in the action.template file did not match the
+ column headings. That has been corrected.
+ - The presence of IPV6 addresses on devices generated error messages
+ during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
+ specified in /etc/shorewall/shorewall.conf. These messages have been
+ eliminated.
+
+Migragion Issues:
+
+ None.
+
+New Features:
+
+
+ - The INTERFACE column in the /etc/shorewall/masq file may now specify a
+ destination list.
+
+ Example:
+
+ #INTERFACE
+ SUBNET ADDRESS
+ eth0:192.0.2.3,192.0.2.16/28 eth1
+
+ If the list begins with "!" then SNAT will occur only if the destination
+ IP address is NOT included in the list.
+
+
+ - Output traffic control rules (those with the firewall as the source)
+ may now be qualified by the effective userid and/or effective group id of
+ the program generating the output. This feature is courtesy of
+ Frédéric LESPEZ.
+
+ A new USER column has been added to /etc/shorewall/tcrules. It may
+ contain :
+
+ [<user name or number>]:[<group
+ name or number>]
+
+ The colon is optionnal when specifying only a user.
+
+ Examples : john: / john / :users /
+ john:users
+
+
+ - A "detectnets" interface option has been added for entries in
+ /etc/shorewall/interfaces. This option automatically tailors the
+ definition of the zone named in the ZONE column to include just
+ those hosts that have routes through the interface named in the INTERFACE
+ column. The named interface must be UP when Shorewall is [re]started.
+
+ WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
+
+
+1/22/2004 - Shorewall 1.4.10 RC1
+
+Problems Corrected since version 1.4.9
+
+ - The column descriptions in the action.template file did not match the
+ column headings. That has been corrected.
+ - The presence of IPV6 addresses on devices generated error messages
+ during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
+ specified in /etc/shorewall/shorewall.conf. These messages have been
+ eliminated.
+
+Migragion Issues:
+
+ None.
+
+New Features:
+
+
+ - The INTERFACE column in the /etc/shorewall/masq file may now specify a
+ destination list.
+
+ Example:
+
+ #INTERFACE
+ SUBNET ADDRESS
+ eth0:192.0.2.3,192.0.2.16/28 eth1
+
+ If the list begins with "!" then SNAT will occur only if the destination
+ IP address is NOT included in the list.
+
+
+ - Output traffic control rules (those with the firewall as the source)
+ may now be qualified by the effective userid and/or effective group id of
+ the program generating the output. This feature is courtesy of
+ Frédéric LESPEZ.
+
+ A new USER column has been added to /etc/shorewall/tcrules. It may
+ contain :
+
+ [<user name or number>]:[<group
+ name or number>]
+
+ The colon is optionnal when specifying only a user.
+
+ Examples : john: / john / :users /
+ john:users
+
+
+
+1/13/2004 - Shorewall 1.4.9
+
+
+Problems Corrected since version 1.4.8:
+
+
+ - There has been a low continuing level of confusion over the terms
+ "Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all
+ instances of "Static NAT" have been replaced with "One-to-one NAT" in the
+ documentation and configuration files.
+ - The description of NEWNOTSYN in shorewall.conf has been reworded for
+ clarity.
+ - Wild-card rules (those involving "all" as SOURCE or DEST) will no
+ longer produce an error if they attempt to add a rule that would override
+ a NONE policy. The logic for expanding these wild-card rules now simply
+ skips those (SOURCE,DEST) pairs that have a NONE policy.
+ - DNAT rules that also specified SNAT now work reliably. Previously,
+ there were cases where the SNAT specification was effectively
+ ignored.
+
+
+Migration Issues:
+
+ None.
+
+New Features:
+
+
+ - The documentation has been completely rebased to Docbook XML. The
+ documentation is now released as separate HTML and XML packages.
+ - To cut down on the number of "Why are these ports closed rather than
+ stealthed?" questions, the SMB-related rules in /etc/shorewall/common.def
+ have been changed from 'reject' to 'DROP'.
+ - For easier identification, packets logged under the 'norfc1918'
+ interface option are now logged out of chains named 'rfc1918'.
+ Previously, such packets were logged under chains named 'logdrop'.
+ - Distributors and developers seem to be regularly inventing new naming
+ conventions for kernel modules. To avoid the need to change Shorewall
+ code for each new convention, the MODULE_SUFFIX option has been added to
+ shorewall.conf. MODULE_SUFFIX may be set to the suffix for module names
+ in your particular distribution. If MODULE_SUFFIX is not set in
+ shorewall.conf, Shorewall will use the list "o gz ko o.gz".
+
+ To see what suffix is used by your distribution:
+
+ ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
+
+ All of the files listed should have the same suffix (extension). Set
+ MODULE_SUFFIX to that suffix.
+
+ Examples:
+
+ If all files end in ".kzo" then set
+ MODULE_SUFFIX="kzo"
+ If all files end in ".kz.o" then set
+ MODULE_SUFFIX="kz.o"
+ - Support for user defined rule ACTIONS has been implemented through two
+ new files:
+
+ /etc/shorewall/actions - used to list the user-defined ACTIONS.
+ /etc/shorewall/action.template - For each user defined <action>,
+ copy this file to /etc/shorewall/action.<action> and add the
+ appropriate rules for that <action>. Once an <action> has
+ been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
+ DROP, etc.) in /etc/shorewall/rules.
+
+ Example: You want an action that logs a packet at the 'info' level and
+ accepts the connection.
+
+ In /etc/shorewall/actions, you would add:
+
+ LogAndAccept
+
+ You would then copy /etc/shorewall/action.template to
+ /etc/shorewall/action.LogAndAccept and in that file, you would add the
+ two rules:
+ LOG:info
+ ACCEPT
+ - The default value for NEWNOTSYN in shorewall.conf is now "Yes" (non-syn
+ TCP packets that are not part of an existing connection are filtered
+ according to the rules and policies rather than being dropped). I have
+ made this change for two reasons:
+
+ a) NEWNOTSYN=No tends to result in lots of "stuck" connections since any
+ timeout during TCP session tear down results in the firewall dropping all
+ of the retries.
+
+ b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots
+ of confusing messages when a connection got "stuck". While I could have
+ changed the default value of LOGNEWNOTSYN to suppress logging, I dislike
+ defaults that silently throw away packets.
+ - The common.def file now contains an entry that silently drops ICMP
+ packets with a null source address. Ad Koster reported a case where these
+ were occuring frequently as a result of a broken system on his external
+ network.
+
+
+12/29/2003 - Shorewall 1.4.9 Beta 2
+
+
+
+Problems Corrected since version 1.4.8:
+
+ - There has been a low continuing level of confusion over the terms
+ "Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all
+ instances of "Static NAT" have been replaced with "One-to-one NAT" in the
+ documentation and configuration files.
+ - The description of NEWNOTSYN in shorewall.conf has been reworded for
+ clarity.
+ - Wild-card rules (those involving "all" as SOURCE or DEST) will no
+ longer produce an error if they attempt to add a rule that would override
+ a NONE policy. The logic for expanding these wild-card rules now simply
+ skips those (SOURCE,DEST) pairs that have a NONE policy.
+ - DNAT rules that also specified SNAT now work reliably. Previously,
+ there were cases where the SNAT specification was effectively ignored.
+
+
+
+Migration Issues:
+
+ None.
+
+New Features:
+
+ - The documentation has been completely rebased to Docbook XML. The
+ documentation is now released as separate HTML and XML packages.
+
+ - To cut down on the number of "Why are these ports closed rather than
+ stealthed?" questions, the SMB-related rules in /etc/shorewall/common.def
+ have been changed from 'reject' to 'DROP'.
+ - For easier identification, packets logged under the 'norfc1918'
+ interface option are now logged out of chains named 'rfc1918'.
+ Previously, such packets were logged under chains named 'logdrop'.
+ - Distributors and developers seem to be regularly inventing new naming
+ conventions for kernel modules. To avoid the need to change Shorewall
+ code for each new convention, the MODULE_SUFFIX option has been added to
+ shorewall.conf. MODULE_SUFFIX may be set to the suffix for module names
+ in your particular distribution. If MODULE_SUFFIX is not set in
+ shorewall.conf, Shorewall will use the list "o gz ko o.gz".
+
+ To see what suffix is used by your distribution:
+
+ ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
+
+ All of the files listed should have the same suffix (extension). Set
+ MODULE_SUFFIX to that suffix.
+
+ Examples:
+
+ If all files end in ".kzo" then set
+ MODULE_SUFFIX="kzo"
+ If all files end in ".kz.o" then set
+ MODULE_SUFFIX="kz.o"
+ - Support for user defined rule ACTIONS has been implemented through two
+ new files:
+
+ /etc/shorewall/actions - used to list the user-defined ACTIONS.
+ /etc/shorewall/action.template - For each user defined <action>,
+ copy this file to /etc/shorewall/action.<action> and add the
+ appropriate rules for that <action>. Once an <action> has
+ been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
+ DROP, etc.) in /etc/shorewall/rules.
+
+ Example: You want an action that logs a packet at the 'info' level and
+ accepts the connection.
+
+ In /etc/shorewall/actions, you would add:
+
+ LogAndAccept
+
+ You would then copy /etc/shorewall/action.template to
+ /etc/shorewall/action.LogAndAccept and in that file, you would add the
+ two rules:
+ LOG:info
+ ACCEPT
+
+ - The default value for NEWNOTSYN in shorewall.conf is now "Yes" (non-syn
+ TCP packets that are not part of an existing connection are filtered
+ according to the rules and policies rather than being dropped). I have
+ made this change for two reasons:
+
+ a) NEWNOTSYN=No tends to result in lots of "stuck" connections since any
+ timeout during TCP session tear down results in the firewall dropping all
+ of the retries.
+
+ b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots
+ of confusing messages when a connection got "stuck". While I could have
+ changed the default value of LOGNEWNOTSYN to suppress logging, I dislike
+ defaults that silently throw away packets.
+
+
+
+
+12/28/2003 - www.shorewall.net/ftp.shorewall.net Back On-line
+
+
+
+Our high-capacity server has been restored to service -- please let us know if you find any
+problems.
+
+12/29/2003 - Shorewall 1.4.9 Beta 1
+
+
+
+Problems Corrected since version 1.4.8:
+
+ - There has been a low continuing level of confusion over the terms
+ "Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all
+ instances of "Static NAT" have been replaced with "One-to-one NAT" in the
+ documentation and configuration files.
+ - The description of NEWNOTSYN in shorewall.conf has been reworded for
+ clarity.
+ - Wild-card rules (those involving "all" as SOURCE or DEST) will no
+ longer produce an error if they attempt to add a rule that would override
+ a NONE policy. The logic for expanding these wild-card rules now simply
+ skips those (SOURCE,DEST) pairs that have a NONE policy.
+
+
+Migration Issues:
+
+ None.
+
+New Features:
+
+ - To cut down on the number of "Why are these ports closed rather than
+ stealthed?" questions, the SMB-related rules in /etc/shorewall/common.def
+ have been changed from 'reject' to 'DROP'.
+ - For easier identification, packets logged under the 'norfc1918'
+ interface option are now logged out of chains named 'rfc1918'.
+ Previously, such packets were logged under chains named 'logdrop'.
+ - Distributors and developers seem to be regularly inventing new naming
+ conventions for kernel modules. To avoid the need to change Shorewall
+ code for each new convention, the MODULE_SUFFIX option has been added to
+ shorewall.conf. MODULE_SUFFIX may be set to the suffix for module names
+ in your particular distribution. If MODULE_SUFFIX is not set in
+ shorewall.conf, Shorewall will use the list "o gz ko o.gz".
+
+ To see what suffix is used by your distribution:
+
+ ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
+
+ All of the files listed should have the same suffix (extension). Set
+ MODULE_SUFFIX to that suffix.
+
+ Examples:
+
+ If all files end in ".kzo" then set
+ MODULE_SUFFIX="kzo"
+ If all files end in ".kz.o" then set
+ MODULE_SUFFIX="kz.o"
+ - Support for user defined rule ACTIONS has been implemented through two
+ new files:
+
+ /etc/shorewall/actions - used to list the user-defined ACTIONS.
+ /etc/shorewall/action.template - For each user defined <action>,
+ copy this file to /etc/shorewall/action.<action> and add the
+ appropriate rules for that <action>. Once an <action> has
+ been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
+ DROP, etc.) in /etc/shorewall/rules.
+
+ Example: You want an action that logs a packet at the 'info' level and
+ accepts the connection.
+
+ In /etc/shorewall/actions, you would add:
+
+ LogAndAccept
+
+ You would then copy /etc/shorewall/action.template to
+ /etc/shorewall/action.LogAndAccept and in that file, you would add the
+ two rules:
+ LOG:info
+ ACCEPT
+
+ - The default value for NEWNOTSYN in shorewall.conf is now "Yes" (non-syn
+ TCP packets that are not part of an existing connection are filtered
+ according to the rules and policies rather than being dropped). I have
+ made this change for two reasons:
+
+ a) NEWNOTSYN=No tends to result in lots of "stuck" connections since any
+ timeout during TCP session tear down results in the firewall dropping all
+ of the retries.
+
+ b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots
+ of confusing messages when a connection got "stuck". While I could have
+ changed the default value of LOGNEWNOTSYN to suppress logging, I dislike
+ defaults that silently throw away packets.
+
+
+12/03/2003 - Support Torch Passed
+Effective today, I am reducing my participation in the day-to-day support of
+Shorewall. As part of this shift to community-based Shorewall support a new
+Shorewall
+Newbies mailing list has been established to field questions and problems
+from new users. I will not monitor that list personally. I will continue my
+active development of Shorewall and will be available via the development
+list to handle development issues -- Tom.
+
+11/07/2003 - Shorewall 1.4.8
+
+ Problems Corrected since version 1.4.7:
+
+
+ - Tuomo Soini has supplied a correction to a problem that occurs using
+ some versions of 'ash'. The symptom is that "shorewall start" fails
+ with:
+
+ local: --limit: bad variable name
+ iptables v1.2.8: Couldn't load match
+ `-j':/lib/iptables/libipt_-j.so:
+ cannot open shared object file: No such file or directory
+ Try `iptables -h' or 'iptables --help' for more
+ information.
+ - Andres Zhoglo has supplied a correction that avoids trying to use the
+ multiport match iptables facility on ICMP rules.
+
+ Example of rule that previously caused "shorewall start" to
+ fail:
+
+
+ ACCEPT loc $FW
+ icmp 0,8,11,12
+
+
+ - Previously, if the following error message was issued, Shorewall was
+ left in an inconsistent state.
+
+ Error: Unable to determine the routes through interface
+ xxx
+
+
+ - Handling of the LOGUNCLEAN option in shorewall.conf has been
+ corrected.
+ - In Shorewall 1.4.2, an optimization was added. This optimization
+ involved creating a chain named "<zone>_frwd" for most zones
+ defined using the /etc/shorewall/hosts file. It has since been discovered
+ that in many cases these new chains contain redundant rules and that the
+ "optimization" turns out to be less than optimal. The implementation has
+ now been corrected.
+ - When the MARK value in a tcrules entry is followed by ":F" or ":P", the
+ ":F" or ":P" was previously only applied to the first Netfilter rule
+ generated by the entry. It is now applied to all entries.
+ - An incorrect comment concerning Debian's use of the SUBSYSLOCK option
+ has been removed from shorewall.conf.
+ - Previously, neither the 'routefilter' interface option nor the
+ ROUTE_FILTER parameter were working properly. This has been corrected
+ (thanks to Eric Bowles for his analysis and patch). The definition of the
+ ROUTE_FILTER option has changed however. Previously, ROUTE_FILTER=Yes was
+ documented as enabling route filtering on all interfaces (which didn't
+ work). Beginning with this release, setting ROUTE_FILTER=Yes will enable
+ route filtering of all interfaces brought up while Shorewall is started.
+ As a consequence, ROUTE_FILTER=Yes can coexist with the use of the
+ 'routefilter' option in the interfaces file.
+ - If MAC verification was enabled on an interface with a /32 address and
+ a broadcast address then an error would occur during startup.
+ - The NONE policy's intended use is to suppress the generating of rules
+ that can't possibly be traversed. This means that a policy of NONE is
+ inappropriate where the source or destination zone is $FW or "all".
+ Shorewall now generates an error message if such a policy is given in
+ /etc/shorewall/policy. Previously such a policy caused "shorewall start"
+ to fail.
+ - The 'routeback' option was broken for wildcard interfaces (e.g.,
+ "tun+"). This has been corrected so that 'routeback' now works as
+ expected in this case.
+
+
+Migration Issues:
+
+
+ - The definition of the ROUTE_FILTER option in shorewall.conf has changed
+ as described in item 8) above.
+
+
+New Features:
+
+
+ - A new QUEUE action has been introduced for rules. QUEUE allows you to
+ pass connection requests to a user-space filter such as ftwall
+ (http://p2pwall.sourceforge.net). The ftwall program allows for effective
+ filtering of p2p applications such as Kazaa. For example, to use ftwall
+ to filter P2P clients in the 'loc' zone, you would add the following
+ rules:
+
+ QUEUE loc
+ net tcp
+ QUEUE loc
+ net udp
+ QUEUE loc
+ fw udp
+
+ You would normally want to place those three rules BEFORE any ACCEPT
+ rules for loc->net udp or tcp.
+
+ Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), Shorewall
+ will only pass connection requests (SYN packets) to user space. This is
+ for compatibility with ftwall.
+ - A BLACKLISTNEWNONLY option has been added to shorewall.conf. When this
+ option is set to "Yes", the blacklists (dynamic and static) are only
+ consulted for new connection requests. When set to "No" (the default if
+ the variable is not set), the blacklists are consulted on every
+ packet.
+
+ Setting this option to "No" allows blacklisting to stop existing
+ connections from a newly blacklisted host but is more expensive in terms
+ of packet processing time. This is especially true if the blacklists
+ contain a large number of entries.
+ - Chain names used in the /etc/shorewall/accounting file may now begin
+ with a digit ([0-9]) and may contain embedded dashes ("-").
+
+
+10/30/2003 - Shorewall 1.4.8 RC1
+
+Given the small number of new features and the relatively few lines of code
+that were changed, there will be no Beta for 1.4.8.
+
+
+http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+
+ Problems Corrected since version 1.4.7:
+
+
+ - Tuomo Soini has supplied a correction to a problem that occurs using
+ some versions of 'ash'. The symptom is that "shorewall start" fails
+ with:
+
+ local: --limit: bad variable name
+ iptables v1.2.8: Couldn't load match
+ `-j':/lib/iptables/libipt_-j.so:
+ cannot open shared object file: No such file or directory
+ Try `iptables -h' or 'iptables --help' for more
+ information.
+ - Andres Zhoglo has supplied a correction that avoids trying to use the
+ multiport match iptables facility on ICMP rules.
+
+ Example of rule that previously caused "shorewall start" to
+ fail:
+
+
+ ACCEPT loc $FW
+ icmp 0,8,11,12
+
+
+ - Previously, if the following error message was issued, Shorewall was
+ left in an inconsistent state.
+
+ Error: Unable to determine the routes through interface
+ xxx
+
+
+ - Handling of the LOGUNCLEAN option in shorewall.conf has been
+ corrected.
+ - In Shorewall 1.4.2, an optimization was added. This optimization
+ involved creating a chain named "<zone>_frwd" for most zones
+ defined using the /etc/shorewall/hosts file. It has since been discovered
+ that in many cases these new chains contain redundant rules and that the
+ "optimization" turns out to be less than optimal. The implementation has
+ now been corrected.
+ - When the MARK value in a tcrules entry is followed by ":F" or ":P", the
+ ":F" or ":P" was previously only applied to the first Netfilter rule
+ generated by the entry. It is now applied to all entries.
+ - An incorrect comment concerning Debian's use of the SYBSYSLOCK option
+ has been removed from shorewall.conf.
+ - Previously, neither the 'routefilter' interface option nor the
+ ROUTE_FILTER parameter were working properly. This has been corrected
+ (thanks to Eric Bowles for his analysis and patch). The definition of the
+ ROUTE_FILTER option has changed however. Previously, ROUTE_FILTER=Yes was
+ documented as enabling route filtering on all interfaces (which didn't
+ work). Beginning with this release, setting ROUTE_FILTER=Yes will enable
+ route filtering of all interfaces brought up while Shorewall is started.
+ As a consequence, ROUTE_FILTER=Yes can coexist with the use of the
+ 'routefilter' option in the interfaces file.
+
+Migration Issues:
+
+
+ - The definition of the ROUTE_FILTER option in shorewall.conf has changed
+ as described in item 8) above.
+
+
+New Features:
+
+
+ - A new QUEUE action has been introduced for rules. QUEUE allows you to
+ pass connection requests to a user-space filter such as ftwall
+ (http://p2pwall.sourceforge.net). The ftwall program allows for effective
+ filtering of p2p applications such as Kazaa. For example, to use ftwall
+ to filter P2P clients in the 'loc' zone, you would add the following
+ rules:
+
+ QUEUE loc
+ net tcp
+ QUEUE loc
+ net udp
+ QUEUE loc
+ fw udp
+
+ You would normally want to place those three rules BEFORE any ACCEPT
+ rules for loc->net udp or tcp.
+
+ Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), Shorewall
+ will only pass connection requests (SYN packets) to user space. This is
+ for compatibility with ftwall.
+ - A BLACKLISTNEWNONLY option has been added to shorewall.conf. When this
+ option is set to "Yes", the blacklists (dynamic and static) are only
+ consulted for new connection requests. When set to "No" (the default if
+ the variable is not set), the blacklists are consulted on every
+ packet.
+
+ Setting this option to "No" allows blacklisting to stop existing
+ connections from a newly blacklisted host but is more expensive in terms
+ of packet processing time. This is especially true if the blacklists
+ contain a large number of entries.
+ - Chain names used in the /etc/shorewall/accounting file may now begin
+ with a digit ([0-9]) and may contain embedded dashes ("-").
+
+
+
+10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper bag awards
+![]()
Shorewall 1.4.7c
+released.
+
+ - The saga with "<zone>_frwd" chains continues. The 1.4.7c script
+ produces a ruleset that should work for everyone even if it is not quite
+ optimal. My apologies for this ongoing mess.
+
+
+
+10/24/2003 - Shorewall 1.4.7b
+This is a bugfx rollup of the 1.4.7a fixes plus:
+
+
+ - The fix for problem 5 in 1.4.7a was wrong with the result that
+ "<zone>_frwd" chains might contain too few rules. That wrong code
+ is corrected in this release.
+
+
+
+10/21/2003 - Shorewall 1.4.7a
+
+
+This is a bugfix rollup of the following problem corrections:
+
+
+ - Tuomo Soini has supplied a correction to a problem that occurs using
+ some versions of 'ash'. The symptom is that "shorewall start" fails
+ with:
+
+ local: --limit: bad variable name
+ iptables v1.2.8: Couldn't load match
+ `-j':/lib/iptables/libipt_-j.so:
+ cannot open shared object file: No such file or directory
+ Try `iptables -h' or 'iptables --help' for more
+ information.
+
+
+ - Andres Zhoglo has supplied a correction that avoids trying to use the
+ multiport match iptables facility on ICMP rules.
+
+ Example of rule that previously caused "shorewall start" to
+ fail:
+
+
+ ACCEPT loc $FW
+ icmp 0,8,11,12
+
+
+ - Previously, if the following error message was issued, Shorewall was
+ left in an inconsistent state.
+
+ Error: Unable to determine the routes through interface
+ xxx
+
+
+ - Handling of the LOGUNCLEAN option in shorewall.conf has been
+ corrected.
+ - In Shorewall 1.4.2, an optimization was added. This optimization
+ involved creating a chain named "<zone>_frwd" for most zones
+ defined using the /etc/shorewall/hosts file. It has since been discovered
+ that in many cases these new chains contain redundant rules and that the
+ "optimization" turns out to be less than optimal. The implementation has
+ now been corrected.
+ - When the MARK value in a tcrules entry is followed by ":F" or ":P", the
+ ":F" or ":P" was previously only applied to the first Netfilter rule
+ generated by the entry. It is now applied to all entries.
+
+
+
+10/06/2003 - Shorewall 1.4.7
+
+Problems Corrected since version 1.4.6 (Those in bold font were corrected
+since 1.4.7 RC2).
+
+
+ - Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
+ tested before it was set.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+ - The "shorewall stop" command is now disabled when
+ /etc/shorewall/startup_disabled exists. This prevents people from
+ shooting themselves in the foot prior to having configured Shorewall.
+ - A change introduced in version 1.4.6 caused error messages during
+ "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
+ added to a PPP interface; the addresses were successfully added in spite
+ of the messages.
+
+ The firewall script has been modified to eliminate the error messages
+ - Interface-specific dynamic blacklisting chains are now displayed by
+ "shorewall monitor" on the "Dynamic Chains" page (previously named
+ "Dynamic Chain").
+ - Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
+ - The 'shorewall reject' and 'shorewall drop' commands now
+ delete any existing rules for the subject IP address before adding a new
+ DROP or REJECT rule. Previously, there could be many rules for the same
+ IP address in the dynamic chain so that multiple 'allow' commands were
+ required to re-enable traffic to/from the address.
+ - When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in
+ /etc/shorewall/masq resulted in a startup error:
+
+ eth0 eth1
+ 206.124.146.20-206.124.146.24
+
+
+ - Shorewall previously choked over IPV6 addresses configured on
+ interfaces in contexts where Shorewall needed to detect something about
+ the interface (such as when "detect" appears in the BROADCAST column of
+ the /etc/shorewall/interfaces file).
+ - Shorewall will now load module files that are formed from the module
+ name by appending ".o.gz".
+ - When Shorewall adds a route to a proxy ARP host and such a route
+ already exists, two routes resulted previously. This has been corrected
+ so that the existing route is replaced if it already exists.
+ - The rfc1918 file has been updated to reflect recent allocations.
+ - The documentation of the USER SET column in the rules file has been
+ corrected.
+ - If there is no policy defined for the zones specified in a rule, the
+ firewall script previously encountered a shell syntax error:
+
+ [: NONE: unexpected
+ operator
+
+ Now, the absence of a policy generates an error message and the firewall
+ is stopped:
+
+ No policy defined from zone
+ <source> to zone <dest>
+
+
+ - Previously, if neither /etc/shorewall/common nor
+ /etc/shorewall/common.def existed, Shorewall would fail to start and
+ would not remove the lock file. Failure to remove the lock file resulted
+ in the following during subsequent attempts to start:
+
+ Loading /usr/share/shorewall/functions...
+ Processing /etc/shorewall/params ...
+ Processing /etc/shorewall/shorewall.conf...
+ Giving up on lock file /var/lib/shorewall/lock
+ Shorewall Not Started
+
+ Shorewall now reports a fatal error if neither of these two files exist
+ and correctly removes the lock fille.
+ - The order of processing the various options has been changed such that
+ blacklist entries now take precedence over the 'dhcp' interface setting.
+ - The log message generated from the 'logunclean' interface option has
+ been changed to reflect a disposition of LOG rather than DROP.
+ - When a user name and/or a group name
+ was specified in the USER SET column and the destination zone was
+ qualified with a IP address, the user and/or group name was not being
+ used to qualify the rule.
+
+ Example:
+
+ ACCEPT fw net:192.0.2.12 tcp 23 - - -
+ vladimir:
+
+
+ - The /etc/shorewall/masq file has had
+ the spurious "/" character at the front removed.
+
+
+
+Migration Issues:
+
+
+ - Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
+ see the Accounting Page for details.
+ - The Uset Set capability introduced in SnapShot 20030821 has changed --
+ see the User Set page for details.
+ - The per-interface Dynamic Blacklisting facility introduced in the first
+ post-1.4.6 Snapshot has been removed. The facility had too many
+ idiosyncrasies for dial-up users to be a viable part of Shorewall.
+
+
+New Features:
+
+
+ - Thanks to Steve Herber, the 'help' command can now give
+ command-specific help (e.g., shorewall help <command>).
+ - A new option "ADMINISABSENTMINDED" has been added to
+ /etc/shorewall/shorewall.conf. This option has a default value of "No"
+ for existing users which causes Shorewall's 'stopped' state to
+ continue as it has been; namely, in the stopped state only traffic
+ to/from hosts listed in /etc/shorewall/routestopped is accepted.
+
+ With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
+ to traffic to/from the hosts listed in /etc/shorewall/routestopped,
+ Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+ already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+ entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+ possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+ eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+ loc:192.168.1.5 tcp 22
+ ACCEPT loc
+ fw tcp 22
+
+ From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+ connection with local system 192.168.1.5. I then create a second SSH
+ connection from that computer to the firewall and confidently type
+ "shorewall stop". As part of its stop processing, Shorewall removes
+ eth0:0 which kills my SSH connection to 192.168.1.5!!!
+ - Given the wide range of VPN software, I can never hope to add specific
+ support for all of it. I have therefore decided to add "generic" tunnel
+ support.
+
+ Generic tunnels work pretty much like any of the other tunnel types. You
+ usually add a zone to represent the systems at the other end of the
+ tunnel and you add the appropriate rules/policies to
+ implement your security policy regarding traffic to/from those
+ systems.
+
+ In the /etc/shorewall/tunnels file, you can have entries of the form:
+
+ generic:<protocol>[:<port>] <zone> <ip
+ address> <gateway zones>
+
+ where:
+
+ <protocol> is the protocol
+ used by the tunnel
+ <port> if the protocol
+ is 'udp' or 'tcp' then this is the destination port number used by the
+ tunnel.
+ <zone> is the zone of
+ the remote tunnel gateway
+ <ip address> is the IP address
+ of the remote tunnel gateway.
+ <gateway zone>
+ Optional. A comma-separated list of zone names. If specified, the remote
+ gateway is to be considered part of these zones.
+ - An 'arp_filter' option has been added to the /etc/shorewall/interfaces
+ file. This option causes
+ /proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
+ result that this interface will only answer ARP 'who-has' requests from
+ hosts that are routed out through that interface. Setting this option
+ facilitates testing of your firewall where multiple firewall interfaces
+ are connected to the same HUB/Switch (all interfaces connected to the
+ single HUB/Switch should have this option specified). Note that using
+ such a configuration in a production environment is strongly recommended
+ against.
+ - The ADDRESS column in /etc/shorewall/masq may now include a
+ comma-separated list of addresses and/or address ranges. Netfilter will
+ use all listed addresses/ranges in round-robin fashion. \
+ - An /etc/shorewall/accounting file has been added to allow for traffic
+ accounting. See the accounting
+ documentation for a description of this facility.
+ - Bridge interfaces (br[0-9]) may now be used in
+ /etc/shorewall/maclist.
+ - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
+ /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
+ rules, rate limiting occurs in the nat table DNAT rule; the corresponding
+ ACCEPT rule in the filter table is not rate limited. If you want to limit
+ the filter table rule, you will need o create two rules; a DNAT- rule and
+ an ACCEPT rule which can be rate-limited separately.
+
+ Warning: When rate limiting is
+ specified on a rule with "all" in the SOURCE or DEST fields, the limit
+ will apply to each pair of zones individually rather than as a single
+ limit for all pairs of covered by the rule.
+
+ To specify a rate limit,
+
+ a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
+
+ <
+ <rate>/<interval>[:<burst>] >
+
+ where
+
+ <rate> is the sustained rate per
+ <interval>
+ <interval> is "sec" or "min"
+ <burst> is the largest burst
+ accepted within an <interval>. If not given, the default of 5 is
+ assumed.
+
+ There may be no white space between the ACTION and "<" nor there may
+ be any white space within the burst specification. If you want to specify
+ logging of a rate-limited rule, the ":" and log level comes after the
+ ">" (e.g., ACCEPT<2/sec:4>:info ).
+
+ b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
+ file. You may specify the rate limit there in the format:
+
+
+ <rate>/<interval>[:<burst>]
+
+ Let's take an example:
+
+
+ ACCEPT<2/sec:4>
+ net dmz
+ tcp 80
+
+ The first time this rule is reached, the packet will be accepted; in
+ fact, since the burst is 4, the first four packets will be accepted.
+ After this, it will be 500ms (1 second divided by the rate
+ of 2) before a packet will be accepted from this rule, regardless of how
+ many packets reach it. Also, every 500ms which passes without matching a
+ packet, one of the bursts will be regained; if no packets hit the rule
+ for 2 second, the burst will be fully recharged; back where we
+ started.
+
+ - Multiple chains may now be displayed in one "shorewall show" command
+ (e.g., shorewall show INPUT FORWARD OUTPUT).
+ - Output rules (those with $FW as the SOURCE) may now be limited to a set
+ of local users and/or groups. See http://shorewall.net/UserSets.html for
+ details.
+
+
+10/02/2003 - Shorewall 1.4.7 RC2
+
+
+http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+
+Problems Corrected since version 1.4.6 (Those in bold font were corrected
+since 1.4.7 RC 1).
+
+
+ - Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
+ tested before it was set.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+ - The "shorewall stop" command is now disabled when
+ /etc/shorewall/startup_disabled exists. This prevents people from
+ shooting themselves in the foot prior to having configured Shorewall.
+ - A change introduced in version 1.4.6 caused error messages during
+ "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
+ added to a PPP interface; the addresses were successfully added in spite
+ of the messages.
+
+ The firewall script has been modified to eliminate the error messages
+ - Interface-specific dynamic blacklisting chains are now displayed by
+ "shorewall monitor" on the "Dynamic Chains" page (previously named
+ "Dynamic Chain").
+ - Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
+ - The 'shorewall reject' and 'shorewall drop' commands now
+ delete any existing rules for the subject IP address before adding a new
+ DROP or REJECT rule. Previously, there could be many rules for the same
+ IP address in the dynamic chain so that multiple 'allow' commands were
+ required to re-enable traffic to/from the address.
+ - When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in
+ /etc/shorewall/masq resulted in a startup error:
+
+ eth0 eth1
+ 206.124.146.20-206.124.146.24
+
+
+ - Shorewall previously choked over IPV6 addresses configured on
+ interfaces in contexts where Shorewall needed to detect something about
+ the interface (such as when "detect" appears in the BROADCAST column of
+ the /etc/shorewall/interfaces file).
+ - Shorewall will now load module files that are formed from the module
+ name by appending ".o.gz".
+ - When Shorewall adds a route to a proxy ARP host and such a route
+ already exists, two routes resulted previously. This has been corrected
+ so that the existing route is replaced if it already exists.
+ - The rfc1918 file has been updated to reflect recent allocations.
+ - The documentation of the USER SET
+ column in the rules file has been corrected.
+ - If there is no policy defined for the
+ zones specified in a rule, the firewall script previously encountered a
+ shell syntax error:
+
+ [: NONE: unexpected
+ operator
+
+ Now, the absence of a policy generates an error message and the firewall
+ is stopped:
+
+ No policy defined from zone
+ <source> to zone <dest>
+
+
+ - Previously, if neither
+ /etc/shorewall/common nor /etc/shorewall/common.def existed, Shorewall
+ would fail to start and would not remove the lock file. Failure to remove
+ the lock file resulted in the following during subsequent attempts to
+ start:
+
+ Loading /usr/share/shorewall/functions...
+ Processing /etc/shorewall/params ...
+ Processing /etc/shorewall/shorewall.conf...
+ Giving up on lock file /var/lib/shorewall/lock
+ Shorewall Not Started
+
+ Shorewall now reports a fatal error if neither of these two files exist
+ and correctly removes the lock fille.
+ - The order of processing the various
+ options has been changed such that blacklist entries now take precedence
+ over the 'dhcp' interface setting.
+ - The log message generated from the
+ 'logunclean' interface option has been changed to reflect a disposition
+ of LOG rather than DROP.
+ - The RFC1918 file has been updated to
+ reflect recent IANA allocations.
+
+
+Migration Issues:
+
+
+ - Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
+ see the Accounting Page for details.
+ - The Uset Set capability introduced in SnapShot 20030821 has changed --
+ see the User Set page for details.
+ - The per-interface Dynamic Blacklisting facility introduced in the first
+ post-1.4.6 Snapshot has been removed. The facility had too many
+ idiosyncrasies for dial-up users to be a viable part of Shorewall.
+
+
+New Features:
+
+
+ - Thanks to Steve Herber, the 'help' command can now give
+ command-specific help (e.g., shorewall help <command>).
+ - A new option "ADMINISABSENTMINDED" has been added to
+ /etc/shorewall/shorewall.conf. This option has a default value of "No"
+ for existing users which causes Shorewall's 'stopped' state to
+ continue as it has been; namely, in the stopped state only traffic
+ to/from hosts listed in /etc/shorewall/routestopped is accepted.
+
+ With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
+ to traffic to/from the hosts listed in /etc/shorewall/routestopped,
+ Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+ already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+ entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+ possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+ eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+ loc:192.168.1.5 tcp 22
+ ACCEPT loc
+ fw tcp 22
+
+ From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+ connection with local system 192.168.1.5. I then create a second SSH
+ connection from that computer to the firewall and confidently type
+ "shorewall stop". As part of its stop processing, Shorewall removes
+ eth0:0 which kills my SSH connection to 192.168.1.5!!!
+ - Given the wide range of VPN software, I can never hope to add specific
+ support for all of it. I have therefore decided to add "generic" tunnel
+ support.
+
+ Generic tunnels work pretty much like any of the other tunnel types. You
+ usually add a zone to represent the systems at the other end of the
+ tunnel and you add the appropriate rules/policies to
+ implement your security policy regarding traffic to/from those
+ systems.
+
+ In the /etc/shorewall/tunnels file, you can have entries of the form:
+
+ generic:<protocol>[:<port>] <zone> <ip
+ address> <gateway zones>
+
+ where:
+
+ <protocol> is the protocol
+ used by the tunnel
+ <port> if the protocol
+ is 'udp' or 'tcp' then this is the destination port number used by the
+ tunnel.
+ <zone> is the zone of
+ the remote tunnel gateway
+ <ip address> is the IP address
+ of the remote tunnel gateway.
+ <gateway zone>
+ Optional. A comma-separated list of zone names. If specified, the remote
+ gateway is to be considered part of these zones.
+ - An 'arp_filter' option has been added to the /etc/shorewall/interfaces
+ file. This option causes
+ /proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
+ result that this interface will only answer ARP 'who-has' requests from
+ hosts that are routed out through that interface. Setting this option
+ facilitates testing of your firewall where multiple firewall interfaces
+ are connected to the same HUB/Switch (all interfaces connected to the
+ single HUB/Switch should have this option specified). Note that using
+ such a configuration in a production environment is strongly recommended
+ against.
+ - The ADDRESS column in /etc/shorewall/masq may now include a
+ comma-separated list of addresses and/or address ranges. Netfilter will
+ use all listed addresses/ranges in round-robin fashion. \
+ - An /etc/shorewall/accounting file has been added to allow for traffic
+ accounting. See the accounting
+ documentation for a description of this facility.
+ - Bridge interfaces (br[0-9]) may now be used in
+ /etc/shorewall/maclist.
+ - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
+ /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
+ rules, rate limiting occurs in the nat table DNAT rule; the corresponding
+ ACCEPT rule in the filter table is not rate limited. If you want to limit
+ the filter table rule, you will need o create two rules; a DNAT- rule and
+ an ACCEPT rule which can be rate-limited separately.
+
+ Warning: When rate limiting is
+ specified on a rule with "all" in the SOURCE or DEST fields, the limit
+ will apply to each pair of zones individually rather than as a single
+ limit for all pairs of covered by the rule.
+
+ To specify a rate limit,
+
+ a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
+
+ <
+ <rate>/<interval>[:<burst>] >
+
+ where
+
+ <rate> is the sustained rate per
+ <interval>
+ <interval> is "sec" or "min"
+ <burst> is the largest burst
+ accepted within an <interval>. If not given, the default of 5 is
+ assumed.
+
+ There may be no white space between the ACTION and "<" nor there may
+ be any white space within the burst specification. If you want to specify
+ logging of a rate-limited rule, the ":" and log level comes after the
+ ">" (e.g., ACCEPT<2/sec:4>:info ).
+
+ b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
+ file. You may specify the rate limit there in the format:
+
+
+ <rate>/<interval>[:<burst>]
+
+ Let's take an example:
+
+
+ ACCEPT<2/sec:4>
+ net dmz
+ tcp 80
+
+ The first time this rule is reached, the packet will be accepted; in
+ fact, since the burst is 4, the first four packets will be accepted.
+ After this, it will be 500ms (1 second divided by the rate
+ of 2) before a packet will be accepted from this rule, regardless of how
+ many packets reach it. Also, every 500ms which passes without matching a
+ packet, one of the bursts will be regained; if no packets hit the rule
+ for 2 second, the burst will be fully recharged; back where we
+ started.
+
+ - Multiple chains may now be displayed in one "shorewall show" command
+ (e.g., shorewall show INPUT FORWARD OUTPUT).
+ - Output rules (those with $FW as the SOURCE) may now be limited to a set
+ of local users and/or groups. See http://shorewall.net/UserSets.html for
+ details.
+
+
+9/18/2003 - Shorewall 1.4.7 RC 1
+
+
+http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+
+Problems Corrected since version 1.4.6 (Those in bold font were corrected
+since 1.4.7 Beta 1).
+
+
+ - Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
+ tested before it was set.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+ - The "shorewall stop" command is now disabled when
+ /etc/shorewall/startup_disabled exists. This prevents people from
+ shooting themselves in the foot prior to having configured Shorewall.
+ - A change introduced in version 1.4.6 caused error messages during
+ "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
+ added to a PPP interface; the addresses were successfully added in spite
+ of the messages.
+
+ The firewall script has been modified to eliminate the error messages
+ - Interface-specific dynamic blacklisting chains are now displayed by
+ "shorewall monitor" on the "Dynamic Chains" page (previously named
+ "Dynamic Chain").
+ - Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
+ - The 'shorewall reject' and 'shorewall drop' commands now
+ delete any existing rules for the subject IP address before adding a new
+ DROP or REJECT rule. Previously, there could be many rules for the same
+ IP address in the dynamic chain so that multiple 'allow' commands were
+ required to re-enable traffic to/from the address.
+ - When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in
+ /etc/shorewall/masq resulted in a startup error:
+
+ eth0 eth1
+ 206.124.146.20-206.124.146.24
+
+
+ - Shorewall previously choked over IPV6 addresses configured on
+ interfaces in contexts where Shorewall needed to detect something about
+ the interface (such as when "detect" appears in the BROADCAST column of
+ the /etc/shorewall/interfaces file).
+ - Shorewall will now load module files that are formed from the module
+ name by appending ".o.gz".
+ - When Shorewall adds a route to a proxy ARP
+ host and such a route already exists, two routes resulted previously.
+ This has been corrected so that the existing route is replaced if it
+ already exists.
+ - The rfc1918 file has been updated to
+ reflect recent allocations.
+
+
+Migration Issues:
+
+
+ - Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
+ see the Accounting Page for details.
+ - The Uset Set capability introduced in SnapShot 20030821 has changed --
+ see the User Set page for details.
+ - The per-interface Dynamic Blacklisting facility introduced in the first
+ post-1.4.6 Snapshot has been removed. The facility had too many
+ idiosyncrasies for dial-up users to be a viable part of Shorewall.
+
+
+New Features:
+
+
+ - Thanks to Steve Herber, the 'help' command can now give
+ command-specific help (e.g., shorewall help <command>).
+ - A new option "ADMINISABSENTMINDED" has been added to
+ /etc/shorewall/shorewall.conf. This option has a default value of "No"
+ for existing users which causes Shorewall's 'stopped' state to
+ continue as it has been; namely, in the stopped state only traffic
+ to/from hosts listed in /etc/shorewall/routestopped is accepted.
+
+ With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
+ to traffic to/from the hosts listed in /etc/shorewall/routestopped,
+ Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+ already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+ entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+ possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+ eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+ loc:192.168.1.5 tcp 22
+ ACCEPT loc
+ fw tcp 22
+
+ From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+ connection with local system 192.168.1.5. I then create a second SSH
+ connection from that computer to the firewall and confidently type
+ "shorewall stop". As part of its stop processing, Shorewall removes
+ eth0:0 which kills my SSH connection to 192.168.1.5!!!
+ - Given the wide range of VPN software, I can never hope to add specific
+ support for all of it. I have therefore decided to add "generic" tunnel
+ support.
+
+ Generic tunnels work pretty much like any of the other tunnel types. You
+ usually add a zone to represent the systems at the other end of the
+ tunnel and you add the appropriate rules/policies to
+ implement your security policy regarding traffic to/from those
+ systems.
+
+ In the /etc/shorewall/tunnels file, you can have entries of the form:
+
+ generic:<protocol>[:<port>] <zone> <ip
+ address> <gateway zones>
+
+ where:
+
+ <protocol> is the protocol
+ used by the tunnel
+ <port> if the protocol
+ is 'udp' or 'tcp' then this is the destination port number used by the
+ tunnel.
+ <zone> is the zone of
+ the remote tunnel gateway
+ <ip address> is the IP address
+ of the remote tunnel gateway.
+ <gateway zone>
+ Optional. A comma-separated list of zone names. If specified, the remote
+ gateway is to be considered part of these zones.
+ - An 'arp_filter' option has been added to the /etc/shorewall/interfaces
+ file. This option causes
+ /proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
+ result that this interface will only answer ARP 'who-has' requests from
+ hosts that are routed out through that interface. Setting this option
+ facilitates testing of your firewall where multiple firewall interfaces
+ are connected to the same HUB/Switch (all interfaces connected to the
+ single HUB/Switch should have this option specified). Note that using
+ such a configuration in a production environment is strongly recommended
+ against.
+ - The ADDRESS column in /etc/shorewall/masq may now include a
+ comma-separated list of addresses and/or address ranges. Netfilter will
+ use all listed addresses/ranges in round-robin fashion. \
+ - An /etc/shorewall/accounting file has been added to allow for traffic
+ accounting. See the accounting
+ documentation for a description of this facility.
+ - Bridge interfaces (br[0-9]) may now be used in
+ /etc/shorewall/maclist.
+ - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
+ /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
+ rules, rate limiting occurs in the nat table DNAT rule; the corresponding
+ ACCEPT rule in the filter table is not rate limited. If you want to limit
+ the filter table rule, you will need o create two rules; a DNAT- rule and
+ an ACCEPT rule which can be rate-limited separately.
+
+ Warning: When rate limiting is
+ specified on a rule with "all" in the SOURCE or DEST fields, the limit
+ will apply to each pair of zones individually rather than as a single
+ limit for all pairs of covered by the rule.
+
+ To specify a rate limit,
+
+ a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
+
+ <
+ <rate>/<interval>[:<burst>] >
+
+ where
+
+ <rate> is the sustained rate per
+ <interval>
+ <interval> is "sec" or "min"
+ <burst> is the largest burst
+ accepted within an <interval>. If not given, the default of 5 is
+ assumed.
+
+ There may be no white space between the ACTION and "<" nor there may
+ be any white space within the burst specification. If you want to specify
+ logging of a rate-limited rule, the ":" and log level comes after the
+ ">" (e.g., ACCEPT<2/sec:4>:info ).
+
+ b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
+ file. You may specify the rate limit there in the format:
+
+
+ <rate>/<interval>[:<burst>]
+
+ Let's take an example:
+
+
+ ACCEPT<2/sec:4>
+ net dmz
+ tcp 80
+
+ The first time this rule is reached, the packet will be accepted; in
+ fact, since the burst is 4, the first four packets will be accepted.
+ After this, it will be 500ms (1 second divided by the rate
+ of 2) before a packet will be accepted from this rule, regardless of how
+ many packets reach it. Also, every 500ms which passes without matching a
+ packet, one of the bursts will be regained; if no packets hit the rule
+ for 2 second, the burst will be fully recharged; back where we
+ started.
+
+ - Multiple chains may now be displayed in one "shorewall show" command
+ (e.g., shorewall show INPUT FORWARD OUTPUT).
+ - Output rules (those with $FW as the SOURCE) may now be limited to a set
+ of local users and/or groups. See http://shorewall.net/UserSets.html for
+ details.
+
+
+9/15/2003 - Shorewall 1.4.7 Beta 2
+
+
+http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+
+Problems Corrected since version 1.4.6 (Those in bold font were corrected
+since 1.4.7 Beta 1).
+
+
+ - Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
+ tested before it was set.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+ - The "shorewall stop" command is now disabled when
+ /etc/shorewall/startup_disabled exists. This prevents people from
+ shooting themselves in the foot prior to having configured Shorewall.
+ - A change introduced in version 1.4.6 caused error messages during
+ "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
+ added to a PPP interface; the addresses were successfully added in spite
+ of the messages.
+
+ The firewall script has been modified to eliminate the error messages
+ - Interface-specific dynamic blacklisting chains are now displayed by
+ "shorewall monitor" on the "Dynamic Chains" page (previously named
+ "Dynamic Chain").
+ - Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
+ - The 'shorewall reject' and
+ 'shorewall drop' commands now delete any existing rules for the subject
+ IP address before adding a new DROP or REJECT rule. Previously, there
+ could be many rules for the same IP address in the dynamic chain so that
+ multiple 'allow' commands were required to re-enable traffic to/from the
+ address.
+ - When ADD_SNAT_ALIASES=Yes in shorewall.conf,
+ the following entry in /etc/shorewall/masq resulted in a startup
+ error:
+
+ eth0 eth1
+ 206.124.146.20-206.124.146.24
+
+
+ - Shorewall previously choked over IPV6
+ addresses configured on interfaces in contexts where Shorewall needed to
+ detect something about the interface (such as when "detect" appears in
+ the BROADCAST column of the /etc/shorewall/interfaces file).
+ - Shorewall will now load module files
+ that are formed from the module name by appending ".o.gz".
+
+
+Migration Issues:
+
+
+ - Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
+ see the Accounting Page for details.
+ - The Uset Set capability introduced in SnapShot 20030821 has changed --
+ see the User Set page for details.
+ - The per-interface Dynamic Blacklisting facility introduced in the first
+ post-1.4.6 Snapshot has been removed. The facility had too many
+ idiosyncrasies for dial-up users to be a viable part of Shorewall.
+
+
+New Features:
+
+
+ - Thanks to Steve Herber, the 'help' command can now give
+ command-specific help (e.g., shorewall help <command>).
+ - A new option "ADMINISABSENTMINDED" has been added to
+ /etc/shorewall/shorewall.conf. This option has a default value of "No"
+ for existing users which causes Shorewall's 'stopped' state to
+ continue as it has been; namely, in the stopped state only traffic
+ to/from hosts listed in /etc/shorewall/routestopped is accepted.
+
+ With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
+ to traffic to/from the hosts listed in /etc/shorewall/routestopped,
+ Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+ already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+ entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+ possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+ eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+ loc:192.168.1.5 tcp 22
+ ACCEPT loc
+ fw tcp 22
+
+ From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+ connection with local system 192.168.1.5. I then create a second SSH
+ connection from that computer to the firewall and confidently type
+ "shorewall stop". As part of its stop processing, Shorewall removes
+ eth0:0 which kills my SSH connection to 192.168.1.5!!!
+ - Given the wide range of VPN software, I can never hope to add specific
+ support for all of it. I have therefore decided to add "generic" tunnel
+ support.
+
+ Generic tunnels work pretty much like any of the other tunnel types. You
+ usually add a zone to represent the systems at the other end of the
+ tunnel and you add the appropriate rules/policies to
+ implement your security policy regarding traffic to/from those
+ systems.
+
+ In the /etc/shorewall/tunnels file, you can have entries of the form:
+
+ generic:<protocol>[:<port>] <zone> <ip
+ address> <gateway zones>
+
+ where:
+
+ <protocol> is the protocol
+ used by the tunnel
+ <port> if the protocol
+ is 'udp' or 'tcp' then this is the destination port number used by the
+ tunnel.
+ <zone> is the zone of
+ the remote tunnel gateway
+ <ip address> is the IP address
+ of the remote tunnel gateway.
+ <gateway zone>
+ Optional. A comma-separated list of zone names. If specified, the remote
+ gateway is to be considered part of these zones.
+ - An 'arp_filter' option has been added to the /etc/shorewall/interfaces
+ file. This option causes
+ /proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
+ result that this interface will only answer ARP 'who-has' requests from
+ hosts that are routed out through that interface. Setting this option
+ facilitates testing of your firewall where multiple firewall interfaces
+ are connected to the same HUB/Switch (all interfaces connected to the
+ single HUB/Switch should have this option specified). Note that using
+ such a configuration in a production environment is strongly recommended
+ against.
+ - The ADDRESS column in /etc/shorewall/masq may now include a
+ comma-separated list of addresses and/or address ranges. Netfilter will
+ use all listed addresses/ranges in round-robin fashion. \
+ - An /etc/shorewall/accounting file has been added to allow for traffic
+ accounting. See the accounting
+ documentation for a description of this facility.
+ - Bridge interfaces (br[0-9]) may now be used in
+ /etc/shorewall/maclist.
+ - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
+ /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
+ rules, rate limiting occurs in the nat table DNAT rule; the corresponding
+ ACCEPT rule in the filter table is not rate limited. If you want to limit
+ the filter table rule, you will need o create two rules; a DNAT- rule and
+ an ACCEPT rule which can be rate-limited separately.
+
+ Warning: When rate limiting is
+ specified on a rule with "all" in the SOURCE or DEST fields, the limit
+ will apply to each pair of zones individually rather than as a single
+ limit for all pairs of covered by the rule.
+
+ To specify a rate limit,
+
+ a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
+
+ <
+ <rate>/<interval>[:<burst>] >
+
+ where
+
+ <rate> is the sustained rate per
+ <interval>
+ <interval> is "sec" or "min"
+ <burst> is the largest burst
+ accepted within an <interval>. If not given, the default of 5 is
+ assumed.
+
+ There may be no white space between the ACTION and "<" nor there may
+ be any white space within the burst specification. If you want to specify
+ logging of a rate-limited rule, the ":" and log level comes after the
+ ">" (e.g., ACCEPT<2/sec:4>:info ).
+
+ b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
+ file. You may specify the rate limit there in the format:
+
+
+ <rate>/<interval>[:<burst>]
+
+ Let's take an example:
+
+
+ ACCEPT<2/sec:4>
+ net dmz
+ tcp 80
+
+ The first time this rule is reached, the packet will be accepted; in
+ fact, since the burst is 4, the first four packets will be accepted.
+ After this, it will be 500ms (1 second divided by the rate
+ of 2) before a packet will be accepted from this rule, regardless of how
+ many packets reach it. Also, every 500ms which passes without matching a
+ packet, one of the bursts will be regained; if no packets hit the rule
+ for 2 second, the burst will be fully recharged; back where we
+ started.
+
+ - Multiple chains may now be displayed in one "shorewall show" command
+ (e.g., shorewall show INPUT FORWARD OUTPUT).
+ - Output rules (those with $FW as the SOURCE) may now be limited to a set
+ of local users and/or groups. See http://shorewall.net/UserSets.html for
+ details.
+
+
+8/27/2003 - Shorewall Mirror in Australia
+
+Thanks to Dave Kempe and Solutions First (http://www.solutionsfirst.com.au), there is now a
+Shorewall Mirror in Australia:
+
+
+
+8/26/2003 - French Version of the Shorewall Setup Guide
+Thanks to Fabien Demassieux, there is now a French translation of the Shorewall Setup
+Guide. Merci Beacoup, Fabien!
+
+8/25/2003 - Shorewall 1.4.7 Beta 1
+
+
+http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+
+Problems Corrected since version 1.4.6
+
+
+ - Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
+ tested before it was set.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+ - The "shorewall stop" command is now disabled when
+ /etc/shorewall/startup_disabled exists. This prevents people from
+ shooting themselves in the foot prior to having configured Shorewall.
+ - A change introduced in version 1.4.6 caused error messages during
+ "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
+ added to a PPP interface; the addresses were successfully added in spite
+ of the messages.
+
+ The firewall script has been modified to eliminate the error messages
+ - Interface-specific dynamic blacklisting chains are now displayed by
+ "shorewall monitor" on the "Dynamic Chains" page (previously named
+ "Dynamic Chain").
+ - Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
+
+
+
+Migration Issues:
+
+
+ - Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
+ see the Accounting Page for details.
+ - The Uset Set capability introduced in SnapShot 20030821 has changed --
+ see the User Set page for details.
+ - The per-interface Dynamic Blacklisting facility introduced in the first
+ post-1.4.6 Snapshot has been removed. The facility had too many
+ idiosyncrasies for dial-up users to be a viable part of Shorewall.
+
+
+New Features:
+
+
+ - Thanks to Steve Herber, the 'help' command can now give
+ command-specific help (e.g., shorewall help <command>).
+ - A new option "ADMINISABSENTMINDED" has been added to
+ /etc/shorewall/shorewall.conf. This option has a default value of "No"
+ for existing users which causes Shorewall's 'stopped' state to
+ continue as it has been; namely, in the stopped state only traffic
+ to/from hosts listed in /etc/shorewall/routestopped is accepted.
+
+ With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
+ to traffic to/from the hosts listed in /etc/shorewall/routestopped,
+ Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+ already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+ entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+ possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+ eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+ loc:192.168.1.5 tcp 22
+ ACCEPT loc
+ fw tcp 22
+
+ From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+ connection with local system 192.168.1.5. I then create a second SSH
+ connection from that computer to the firewall and confidently type
+ "shorewall stop". As part of its stop processing, Shorewall removes
+ eth0:0 which kills my SSH connection to 192.168.1.5!!!
+ - Given the wide range of VPN software, I can never hope to add specific
+ support for all of it. I have therefore decided to add "generic" tunnel
+ support.
+
+ Generic tunnels work pretty much like any of the other tunnel types. You
+ usually add a zone to represent the systems at the other end of the
+ tunnel and you add the appropriate rules/policies to
+ implement your security policy regarding traffic to/from those
+ systems.
+
+ In the /etc/shorewall/tunnels file, you can have entries of the form:
+
+ generic:<protocol>[:<port>] <zone> <ip
+ address> <gateway zones>
+
+ where:
+
+ <protocol> is the protocol
+ used by the tunnel
+ <port> if the protocol
+ is 'udp' or 'tcp' then this is the destination port number used by the
+ tunnel.
+ <zone> is the zone of
+ the remote tunnel gateway
+ <ip address> is the IP address
+ of the remote tunnel gateway.
+ <gateway zone>
+ Optional. A comma-separated list of zone names. If specified, the remote
+ gateway is to be considered part of these zones.
+ - An 'arp_filter' option has been added to the /etc/shorewall/interfaces
+ file. This option causes
+ /proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
+ result that this interface will only answer ARP 'who-has' requests from
+ hosts that are routed out through that interface. Setting this option
+ facilitates testing of your firewall where multiple firewall interfaces
+ are connected to the same HUB/Switch (all interfaces connected to the
+ single HUB/Switch should have this option specified). Note that using
+ such a configuration in a production environment is strongly recommended
+ against.
+ - The ADDRESS column in /etc/shorewall/masq may now include a
+ comma-separated list of addresses and/or address ranges. Netfilter will
+ use all listed addresses/ranges in round-robin fashion. \
+ - An /etc/shorewall/accounting file has been added to allow for traffic
+ accounting. See the accounting
+ documentation for a description of this facility.
+ - Bridge interfaces (br[0-9]) may now be used in
+ /etc/shorewall/maclist.
+ - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
+ /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
+ rules, rate limiting occurs in the nat table DNAT rule; the corresponding
+ ACCEPT rule in the filter table is not rate limited. If you want to limit
+ the filter table rule, you will need o create two rules; a DNAT- rule and
+ an ACCEPT rule which can be rate-limited separately.
+
+ Warning: When rate limiting is
+ specified on a rule with "all" in the SOURCE or DEST fields, the limit
+ will apply to each pair of zones individually rather than as a single
+ limit for all pairs of covered by the rule.
+
+ To specify a rate limit,
+
+ a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
+
+ <
+ <rate>/<interval>[:<burst>] >
+
+ where
+
+ <rate> is the sustained rate per
+ <interval>
+ <interval> is "sec" or "min"
+ <burst> is the largest burst
+ accepted within an <interval>. If not given, the default of 5 is
+ assumed.
+
+ There may be no white space between the ACTION and "<" nor there may
+ be any white space within the burst specification. If you want to specify
+ logging of a rate-limited rule, the ":" and log level comes after the
+ ">" (e.g., ACCEPT<2/sec:4>:info ).
+
+ b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
+ file. You may specify the rate limit there in the format:
+
+
+ <rate>/<interval>[:<burst>]
+
+ Let's take an example:
+
+
+ ACCEPT<2/sec:4>
+ net dmz
+ tcp 80
+
+ The first time this rule is reached, the packet will be accepted; in
+ fact, since the burst is 4, the first four packets will be accepted.
+ After this, it will be 500ms (1 second divided by the rate
+ of 2) before a packet will be accepted from this rule, regardless of how
+ many packets reach it. Also, every 500ms which passes without matching a
+ packet, one of the bursts will be regained; if no packets hit the rule
+ for 2 second, the burst will be fully recharged; back where we
+ started.
+
+ - Multiple chains may now be displayed in one "shorewall show" command
+ (e.g., shorewall show INPUT FORWARD OUTPUT).
+ - Output rules (those with $FW as the SOURCE) may now be limited to a set
+ of local users and/or groups. See http://shorewall.net/UserSets.html for
+ details.
+
+
+
+8/23/2003 - Snapshot 1.4.6_20030823
+
+
+ http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/
+
+Problems Corrected since version 1.4.6
+
+
+ - Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
+ tested before it was set.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+ - The "shorewall stop" command is now disabled when
+ /etc/shorewall/startup_disabled exists. This prevents people from
+ shooting themselves in the foot prior to having configured Shorewall.
+ - A change introduced in version 1.4.6 caused error messages during
+ "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
+ added to a PPP interface; the addresses were successfully added in spite
+ of the messages.
+
+ The firewall script has been modified to eliminate the error messages
+ - Interface-specific dynamic blacklisting chains are now displayed by
+ "shorewall monitor" on the "Dynamic Chains" page (previously named
+ "Dynamic Chain").
+ - Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
+
+
+
+Migration Issues:
+
+
+ - Once you have installed this version of Shorewall, you must restart
+ Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
+ commands.
+ - To maintain strict compatibility with previous versions, current uses
+ of "shorewall drop" and "shorewall reject" should be replaced with
+ "shorewall dropall" and "shorewall rejectall"
+ - Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
+ see the Accounting Page for details.
+ - The Uset Set capability introduced in SnapShot 20030821 has changed --
+ see the User Set page for details.
+
+New Features:
+
+
+ - Shorewall now creates a dynamic blacklisting chain for each interface
+ defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
+ use the routing table to determine which of these chains is to be used
+ for blacklisting the specified IP address(es).
+
+ Two new commands ('dropall' and 'rejectall') have been introduced that do
+ what 'drop' and 'reject' used to do; namely, when an address is
+ blacklisted using these new commands, it will be blacklisted on all of
+ your firewall's interfaces.
+ - Thanks to Steve Herber, the 'help' command can now give
+ command-specific help (e.g., shorewall help <command>).
+ - A new option "ADMINISABSENTMINDED" has been added to
+ /etc/shorewall/shorewall.conf. This option has a default value of "No"
+ for existing users which causes Shorewall's 'stopped' state to
+ continue as it has been; namely, in the stopped state only traffic
+ to/from hosts listed in /etc/shorewall/routestopped is accepted.
+
+ With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
+ to traffic to/from the hosts listed in /etc/shorewall/routestopped,
+ Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+ already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+ entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+ possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+ eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+ loc:192.168.1.5 tcp 22
+ ACCEPT loc
+ fw tcp 22
+
+ From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+ connection with local system 192.168.1.5. I then create a second SSH
+ connection from that computer to the firewall and confidently type
+ "shorewall stop". As part of its stop processing, Shorewall removes
+ eth0:0 which kills my SSH connection to 192.168.1.5!!!
+ - Given the wide range of VPN software, I can never hope to add specific
+ support for all of it. I have therefore decided to add "generic" tunnel
+ support.
+
+ Generic tunnels work pretty much like any of the other tunnel types. You
+ usually add a zone to represent the systems at the other end of the
+ tunnel and you add the appropriate rules/policies to
+ implement your security policy regarding traffic to/from those
+ systems.
+
+ In the /etc/shorewall/tunnels file, you can have entries of the form:
+
+ generic:<protocol>[:<port>] <zone> <ip
+ address> <gateway zones>
+
+ where:
+
+ <protocol> is the protocol
+ used by the tunnel
+ <port> if the protocol
+ is 'udp' or 'tcp' then this is the destination port number used by the
+ tunnel.
+ <zone> is the zone of
+ the remote tunnel gateway
+ <ip address> is the IP address
+ of the remote tunnel gateway.
+ <gateway zone>
+ Optional. A comma-separated list of zone names. If specified, the remote
+ gateway is to be considered part of these zones.
+ - An 'arp_filter' option has been added to the /etc/shorewall/interfaces
+ file. This option causes
+ /proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
+ result that this interface will only answer ARP 'who-has' requests from
+ hosts that are routed out through that interface. Setting this option
+ facilitates testing of your firewall where multiple firewall interfaces
+ are connected to the same HUB/Switch (all interfaces connected to the
+ single HUB/Switch should have this option specified). Note that using
+ such a configuration in a production environment is strongly recommended
+ against.
+ - The ADDRESS column in /etc/shorewall/masq may now include a
+ comma-separated list of addresses and/or address ranges. Netfilter will
+ use all listed addresses/ranges in round-robin fashion. \
+ - An /etc/shorewall/accounting file has been added to allow for traffic
+ accounting. See the accounting
+ documentation for a description of this facility.
+ - Bridge interfaces (br[0-9]) may now be used in
+ /etc/shorewall/maclist.
+ - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
+ /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
+ rules, rate limiting occurs in the nat table DNAT rule; the corresponding
+ ACCEPT rule in the filter table is not rate limited. If you want to limit
+ the filter table rule, you will need o create two rules; a DNAT- rule and
+ an ACCEPT rule which can be rate-limited separately.
+
+ Warning: When rate limiting is
+ specified on a rule with "all" in the SOURCE or DEST fields, the limit
+ will apply to each pair of zones individually rather than as a single
+ limit for all pairs of covered by the rule.
+
+ To specify a rate limit,
+
+ a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
+
+ <
+ <rate>/<interval>[:<burst>] >
+
+ where
+
+ <rate> is the sustained rate per
+ <interval>
+ <interval> is "sec" or "min"
+ <burst> is the largest burst
+ accepted within an <interval>. If not given, the default of 5 is
+ assumed.
+
+ There may be no white space between the ACTION and "<" nor there may
+ be any white space within the burst specification. If you want to specify
+ logging of a rate-limited rule, the ":" and log level comes after the
+ ">" (e.g., ACCEPT<2/sec:4>:info ).
+
+ b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
+ file. You may specify the rate limit there in the format:
+
+
+ <rate>/<interval>[:<burst>]
+
+ Let's take an example:
+
+
+ ACCEPT<2/sec:4>
+ net dmz
+ tcp 80
+
+ The first time this rule is reached, the packet will be accepted; in
+ fact, since the burst is 4, the first four packets will be accepted.
+ After this, it will be 500ms (1 second divided by the rate
+ of 2) before a packet will be accepted from this rule, regardless of how
+ many packets reach it. Also, every 500ms which passes without matching a
+ packet, one of the bursts will be regained; if no packets hit the rule
+ for 2 second, the burst will be fully recharged; back where we
+ started.
+
+ - Multiple chains may now be displayed in one "shorewall show" command
+ (e.g., shorewall show INPUT FORWARD OUTPUT).
+ - Output rules (those with $FW as the SOURCE) may now be limited to a set
+ of local users and/or groups. See http://shorewall.net/UserSets.html for
+ details.
+
+
+
+8/13/2003 - Snapshot 1.4.6_20030813
+
+
+ http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/
+
+Problems Corrected since version 1.4.6
+
+
+ - Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
+ tested before it was set.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+ - The "shorewall stop" command is now disabled when
+ /etc/shorewall/startup_disabled exists. This prevents people from
+ shooting themselves in the foot prior to having configured Shorewall.
+ - A change introduced in version 1.4.6 caused error messages during
+ "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
+ added to a PPP interface; the addresses were successfully added in spite
+ of the messages.
+
+ The firewall script has been modified to eliminate the error messages
+ - Interface-specific dynamic blacklisting chains are now displayed
+ by "shorewall monitor" on the "Dynamic Chains" page (previously named
+ "Dynamic Chain").
+
+
+
+Migration Issues:
+
+
+ - Once you have installed this version of Shorewall, you must restart
+ Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
+ commands.
+ - To maintain strict compatibility with previous versions, current uses
+ of "shorewall drop" and "shorewall reject" should be replaced with
+ "shorewall dropall" and "shorewall rejectall"
+
+New Features:
+
+
+ - Shorewall now creates a dynamic blacklisting chain for each interface
+ defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
+ use the routing table to determine which of these chains is to be used
+ for blacklisting the specified IP address(es).
+
+ Two new commands ('dropall' and 'rejectall') have been introduced that do
+ what 'drop' and 'reject' used to do; namely, when an address is
+ blacklisted using these new commands, it will be blacklisted on all of
+ your firewall's interfaces.
+ - Thanks to Steve Herber, the 'help' command can now give
+ command-specific help (e.g., shorewall help <command>).
+ - A new option "ADMINISABSENTMINDED" has been added to
+ /etc/shorewall/shorewall.conf. This option has a default value of "No"
+ for existing users which causes Shorewall's 'stopped' state to
+ continue as it has been; namely, in the stopped state only traffic
+ to/from hosts listed in /etc/shorewall/routestopped is accepted.
+
+ With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
+ to traffic to/from the hosts listed in /etc/shorewall/routestopped,
+ Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+ already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+ entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+ possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+ eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+ loc:192.168.1.5 tcp 22
+ ACCEPT loc
+ fw tcp 22
+
+ From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+ connection with local system 192.168.1.5. I then create a second SSH
+ connection from that computer to the firewall and confidently type
+ "shorewall stop". As part of its stop processing, Shorewall removes
+ eth0:0 which kills my SSH connection to 192.168.1.5!!!
+ - Given the wide range of VPN software, I can never hope to add specific
+ support for all of it. I have therefore decided to add "generic" tunnel
+ support.
+
+ Generic tunnels work pretty much like any of the other tunnel types. You
+ usually add a zone to represent the systems at the other end of the
+ tunnel and you add the appropriate rules/policies to
+ implement your security policy regarding traffic to/from those
+ systems.
+
+ In the /etc/shorewall/tunnels file, you can have entries of the form:
+
+ generic:<protocol>[:<port>] <zone> <ip
+ address> <gateway zones>
+
+ where:
+
+ <protocol> is the protocol
+ used by the tunnel
+ <port> if the protocol
+ is 'udp' or 'tcp' then this is the destination port number used by the
+ tunnel.
+ <zone> is the zone of
+ the remote tunnel gateway
+ <ip address> is the IP address
+ of the remote tunnel gateway.
+ <gateway zone>
+ Optional. A comma-separated list of zone names. If specified, the remote
+ gateway is to be considered part of these zones.
+ - An 'arp_filter' option has been added to the /etc/shorewall/interfaces
+ file. This option causes
+ /proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
+ result that this interface will only answer ARP 'who-has' requests from
+ hosts that are routed out through that interface. Setting this option
+ facilitates testing of your firewall where multiple firewall interfaces
+ are connected to the same HUB/Switch (all interfaces connected to the
+ single HUB/Switch should have this option specified). Note that using
+ such a configuration in a production environment is strongly recommended
+ against.
+ - The ADDRESS column in /etc/shorewall/masq may now include a
+ comma-separated list of addresses and/or address ranges. Netfilter will
+ use all listed addresses/ranges in round-robin fashion. \
+ - An /etc/shorewall/accounting file has been added to allow for traffic
+ accounting. See the accounting
+ documentation for a description of this facility.
+ - Bridge interfaces (br[0-9]) may now be used in
+ /etc/shorewall/maclist.
+ - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
+ /etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
+ rules, rate limiting occurs in the nat table DNAT rule; the corresponding
+ ACCEPT rule in the filter table is not rate limited. If you want to limit
+ the filter table rule, you will need o create two rules; a DNAT- rule and
+ an ACCEPT rule which can be rate-limited separately.
+
+ Warning: When rate limiting is
+ specified on a rule with "all" in the SOURCE or DEST fields, the limit
+ will apply to each pair of zones individually rather than as a single
+ limit for all pairs of covered by the rule.
+
+ To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-] or LOG
+ with
+
+ <
+ <rate>/<interval>[:<burst>] >
+
+ where
+
+ <rate> is the sustained rate per
+ <interval>
+ <interval> is "sec" or "min"
+ <burst> is the largest burst
+ accepted within an <interval>. If not given, the default of 5 is
+ assumed.
+
+ There may be no white space between the ACTION and "<" nor there may
+ be any white space within the burst specification. If you want to specify
+ logging of a rate-limited rule, the ":" and log level comes after the
+ ">" (e.g., ACCEPT<2/sec:4>:info ).
+
+ Let's take an example:
+
+
+ ACCEPT<2/sec:4>
+ net dmz
+ tcp 80
+
+ The first time this rule is reached, the packet will be accepted; in
+ fact, since the burst is 4, the first four packets will be accepted.
+ After this, it will be 500ms (1 second divided by the rate
+ of 2) before a packet will be accepted from this rule, regardless of how
+ many packets reach it. Also, every 500ms which passes without matching a
+ packet, one of the bursts will be regained; if no packets hit the rule
+ for 2 second, the burst will be fully recharged; back where we
+ started.
+
+
+
+8/9/2003 - Snapshot 1.4.6_20030809
+
+
+ http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/
+
+Problems Corrected since version 1.4.6
+
+
+ - Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
+ tested before it was set.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+ - The "shorewall stop" command is now disabled when
+ /etc/shorewall/startup_disabled exists. This prevents people from
+ shooting themselves in the foot prior to having configured Shorewall.
+ - A change introduced in version 1.4.6 caused error messages during
+ "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
+ added to a PPP interface; the addresses were successfully added in spite
+ of the messages.
+
+ The firewall script has been modified to eliminate the error messages
+
+
+Migration Issues:
+
+
+ - Once you have installed this version of Shorewall, you must restart
+ Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
+ commands.
+ - To maintain strict compatibility with previous versions, current uses
+ of "shorewall drop" and "shorewall reject" should be replaced with
+ "shorewall dropall" and "shorewall rejectall"
+
+New Features:
+
+
+ - Shorewall now creates a dynamic blacklisting chain for each interface
+ defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
+ use the routing table to determine which of these chains is to be used
+ for blacklisting the specified IP address(es).
+
+ Two new commands ('dropall' and 'rejectall') have been introduced that do
+ what 'drop' and 'reject' used to do; namely, when an address is
+ blacklisted using these new commands, it will be blacklisted on all of
+ your firewall's interfaces.
+ - Thanks to Steve Herber, the 'help' command can now give
+ command-specific help (e.g., shorewall help <command>).
+ - A new option "ADMINISABSENTMINDED" has been added to
+ /etc/shorewall/shorewall.conf. This option has a default value of "No"
+ for existing users which causes Shorewall's 'stopped' state to
+ continue as it has been; namely, in the stopped state only traffic
+ to/from hosts listed in /etc/shorewall/routestopped is accepted.
+
+ With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
+ to traffic to/from the hosts listed in /etc/shorewall/routestopped,
+ Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+ already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+ entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+ possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+ eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+ loc:192.168.1.5 tcp 22
+ ACCEPT loc
+ fw tcp 22
+
+ From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+ connection with local system 192.168.1.5. I then create a second SSH
+ connection from that computer to the firewall and confidently type
+ "shorewall stop". As part of its stop processing, Shorewall removes
+ eth0:0 which kills my SSH connection to 192.168.1.5!!!
+ - Given the wide range of VPN software, I can never hope to add specific
+ support for all of it. I have therefore decided to add "generic" tunnel
+ support.
+
+ Generic tunnels work pretty much like any of the other tunnel types. You
+ usually add a zone to represent the systems at the other end of the
+ tunnel and you add the appropriate rules/policies to
+ implement your security policy regarding traffic to/from those
+ systems.
+
+ In the /etc/shorewall/tunnels file, you can have entries of the form:
+
+ generic:<protocol>[:<port>] <zone> <ip
+ address> <gateway zones>
+
+ where:
+
+ <protocol> is the protocol
+ used by the tunnel
+ <port> if the protocol
+ is 'udp' or 'tcp' then this is the destination port number used by the
+ tunnel.
+ <zone> is the zone of
+ the remote tunnel gateway
+ <ip address> is the IP address
+ of the remote tunnel gateway.
+ <gateway zone>
+ Optional. A comma-separated list of zone names. If specified, the remote
+ gateway is to be considered part of these zones.
+ - An 'arp_filter' option has been added to the /etc/shorewall/interfaces
+ file. This option causes
+ /proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
+ result that this interface will only answer ARP 'who-has' requests from
+ hosts that are routed out through that interface. Setting this option
+ facilitates testing of your firewall where multiple firewall interfaces
+ are connected to the same HUB/Switch (all interfaces connected to the
+ single HUB/Switch should have this option specified). Note that using
+ such a configuration in a production environment is strongly recommended
+ against.
+
+
+
+8/5/2003 - Shorewall-1.4.6b
+
+Problems Corrected since version 1.4.6:
+
+
+ - Previously, if TC_ENABLED is set to yes in shorewall.conf then
+ Shorewall would fail to start with the error "ERROR: Traffic
+ Control requires Mangle"; that problem has been corrected.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+ - The "shorewall stop" command is now disabled when
+ /etc/shorewall/startup_disabled exists. This prevents people from
+ shooting themselves in the foot prior to having configured Shorewall.
+ - A change introduced in version 1.4.6 caused error messages during
+ "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
+ added to a PPP interface; the addresses were successfully added in spite
+ of the messages.
+
+ The firewall script has been modified to eliminate the error
+ messages.
+
+
+8/5/2003 - Shorewall-1.4.6b
+
+Problems Corrected since version 1.4.6:
+
+
+ - Previously, if TC_ENABLED is set to yes in shorewall.conf then
+ Shorewall would fail to start with the error "ERROR: Traffic
+ Control requires Mangle"; that problem has been corrected.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+ - The "shorewall stop" command is now disabled when
+ /etc/shorewall/startup_disabled exists. This prevents people from
+ shooting themselves in the foot prior to having configured Shorewall.
+ - A change introduced in version 1.4.6 caused error messages during
+ "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
+ added to a PPP interface; the addresses were successfully added in spite
+ of the messages.
+
+ The firewall script has been modified to eliminate the error messages.
+
+
+
+7/31/2003 - Snapshot 1.4.6_20030731
+
+
+ http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/
+
+
+Problems Corrected since version 1.4.6:
+
+
+ - Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
+ tested before it was set.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+
+
+
+Migration Issues:
+
+
+ - Once you have installed this version of Shorewall, you must restart
+ Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
+ commands.
+ - To maintain strict compatibility with previous versions, current uses
+ of "shorewall drop" and "shorewall reject" should be replaced with
+ "shorewall dropall" and "shorewall rejectall"
+
+
+New Features:
+
+
+ - Shorewall now creates a dynamic blacklisting chain for each interface
+ defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
+ use the routing table to determine which of these chains is to be used
+ for blacklisting the specified IP address(es).
+
+ Two new commands ('dropall' and 'rejectall') have been introduced that do
+ what 'drop' and 'reject' used to do; namely, when an address is
+ blacklisted using these new commands, it will be blacklisted on all of
+ your firewall's interfaces.
+ - Thanks to Steve Herber, the 'help' command can now give
+ command-specific help (e.g., shorewall help <command>).
+ - A new option "ADMINISABSENTMINDED" has been added to
+ /etc/shorewall/shorewall.conf. This option has a default value of "No"
+ for existing users which causes Shorewall's 'stopped' state to
+ continue as it has been; namely, in the stopped state only traffic
+ to/from hosts listed in /etc/shorewall/routestopped is accepted.
+
+ With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
+ to traffic to/from the hosts listed in /etc/shorewall/routestopped,
+ Shorewall will allow:
+
+ a) All traffic originating from the firewall itself; and
+ b) All traffic that is part of or related to an
+ already-existing connection.
+
+ In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
+ entered through an ssh session will not kill the session.
+
+ Note though that even with ADMINISABSENTMINDED=Yes, it is still
+ possible for people to shoot themselves in the foot.
+
+ Example:
+
+ /etc/shorewall/nat:
+
+ 206.124.146.178
+ eth0:0 192.168.1.5
+
+ /etc/shorewall/rules:
+
+ ACCEPT net
+ loc:192.168.1.5 tcp 22
+ ACCEPT loc
+ fw tcp 22
+
+ From a remote system, I ssh to 206.124.146.178 which establishes an SSH
+ connection with local system 192.168.1.5. I then create a second SSH
+ connection from that computer to the firewall and confidently type
+ "shorewall stop". As part of its stop processing, Shorewall removes
+ eth0:0 which kills my SSH connection to 192.168.1.5!!!
+
+
+7/27/2003 - Snapshot 1.4.6_20030727
+
+
+ http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/
+
+Problems Corrected since version 1.4.6
+
+
+ - Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
+ tested before it was set.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+
+
+Migration Issues:
+
+
+ - Once you have installed this version of Shorewall, you must restart
+ Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
+ commands.
+ - To maintain strict compatibility with previous versions, current uses
+ of "shorewall drop" and "shorewall reject" should be replaced with
+ "shorewall dropall" and "shorewall rejectall"
+
+New Features:
+
+
+ - Shorewall now creates a dynamic blacklisting chain for each interface
+ defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
+ use the routing table to determine which of these chains is to be used
+ for blacklisting the specified IP address(es).
+
+ Two new commands ('dropall' and 'rejectall') have been introduced that do
+ what 'drop' and 'reject' used to do; namely, when an address is
+ blacklisted using these new commands, it will be blacklisted on all of
+ your firewall's interfaces.
+ - Thanks to Steve Herber, the 'help' command can now give
+ command-specific help (e.g., shorewall help <command>).
+
+
+
+7/26/2003 - Snapshot 1.4.6_20030726
+
+
+ http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/
+
+
+Problems Corrected since version 1.4.6:
+
+
+ - Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
+ tested before it was set.
+ - Corrected handling of MAC addresses in the SOURCE column of the tcrules
+ file. Previously, these addresses resulted in an invalid iptables
+ command.
+
+
+
+Migration Issues:
+
+
+ - Once you have installed this version of Shorewall, you must restart
+ Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
+ commands.
+ - To maintain strict compatibility with previous versions, current uses
+ of "shorewall drop" and "shorewall reject" should be replaced with
+ "shorewall dropall" and "shorewall rejectall"
+
+
+New Features:
+
+Shorewall now creates a dynamic blacklisting chain for each interface defined
+in /etc/shorewall/interfaces. The 'drop' and 'reject' commands use the
+routing table to determine which of these chains is to be used for
+blacklisting the specified IP address(es).
+
+Two new commands ('dropall' and 'rejectall') have been introduced that do
+what 'drop' and 'reject' used to do; namely, when an address is blacklisted
+using these new commands, it will be blacklisted on all of your firewall's
+interfaces.
+
+7/22/2003 - Shorewall-1.4.6a
+
+Problems Corrected:
+
+
+ - Previously, if TC_ENABLED is set to yes in shorewall.conf then
+ Shorewall would fail to start with the error "ERROR: Traffic
+ Control requires Mangle"; that problem has been corrected.
+
+
+7/20/2003 - Shorewall-1.4.6
+
+
+Problems Corrected:
+
+
+ - A problem seen on RH7.3 systems where Shorewall encountered start
+ errors when started using the "service" mechanism has been worked
+ around.
+
+
+ - Where a list of IP addresses appears in the DEST column of a DNAT[-]
+ rule, Shorewall incorrectly created multiple DNAT rules in the nat table
+ (one for each element in the list). Shorewall now correctly creates a
+ single DNAT rule with multiple "--to-destination" clauses.
+
+
+ - Corrected a problem in Beta 1 where DNS names containing a "-" were
+ mis-handled when they appeared in the DEST column of a rule.
+
+
+ - A number of problems with rule parsing have been corrected. Corrections
+ involve the handling of "z1!z2" in the SOURCE column as well as lists in
+ the ORIGINAL DESTINATION column.
+
+
+ - The message "Adding rules for DHCP" is now suppressed if there are no
+ DHCP rules to add.
+
+
+
+Migration Issues:
+
+
+ - In earlier versions, an undocumented feature allowed entries in the
+ host file as follows:
+
+ z
+ eth1:192.168.1.0/24,eth2:192.168.2.0/24
+
+ This capability was never documented and has been removed in 1.4.6 to
+ allow entries of the following format:
+
+ z eth1:192.168.1.0/24,192.168.2.0/24
+
+
+ - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
+ from /etc/shorewall/shorewall.conf. These capabilities are now
+ automatically detected by Shorewall (see below).
+
+
+
+New Features:
+
+
+ - A 'newnotsyn' interface option has been added. This option may be
+ specified in /etc/shorewall/interfaces and overrides the setting
+ NEWNOTSYN=No for packets arriving on the associated interface.
+
+
+ - The means for specifying a range of IP addresses in /etc/shorewall/masq
+ to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
+ address ranges.
+
+
+ - Shorewall can now add IP addresses to subnets other than the first one
+ on an interface.
+
+
+ - DNAT[-] rules may now be used to load balance (round-robin) over a set
+ of servers. Servers may be specified in a range of addresses given as
+ <first address>-<last address>.
+
+ Example:
+
+ DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
+
+
+ - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
+ have been removed and have been replaced by code that detects whether
+ these capabilities are present in the current kernel. The output of the
+ start, restart and check commands have been enhanced to report the
+ outcome:
+
+ Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Verifying Configuration...
+
+
+ - Support for the Connection Tracking Match Extension has been added.
+ This extension is available in recent kernel/iptables releases and allows
+ for rules which match against elements in netfilter's connection tracking
+ table. Shorewall automatically detects the availability of this extension
+ and reports its availability in the output of the start, restart and
+ check commands.
+
+ Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Connection Tracking Match: Available
+ Verifying Configuration...
+
+ If this extension is available, the ruleset generated by Shorewall is
+ changed in the following ways:
+
+ - To handle 'norfc1918' filtering, Shorewall will not create chains
+ in the mangle table but will rather do all 'norfc1918' filtering in
+ the filter table (rfc1918 chain).
+ - Recall that Shorewall DNAT rules generate two netfilter rules; one
+ in the nat table and one in the filter table. If the Connection
+ Tracking Match Extension is available, the rule in the filter table
+ is extended to check that the original destination address was the
+ same as specified (or defaulted to) in the DNAT rule.
+
+
+
+ - The shell used to interpret the firewall script
+ (/usr/share/shorewall/firewall) may now be specified using the
+ SHOREWALL_SHELL parameter in shorewall.conf.
+
+
+ - An 'ipcalc' command has been added to /sbin/shorewall.
+
+ ipcalc [ <address> <netmask> |
+ <address>/<vlsm> ]
+
+ Examples:
+
+ [root@wookie root]# shorewall ipcalc
+ 192.168.1.0/24
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+ [root@wookie root]# shorewall ipcalc
+ 192.168.1.0 255.255.255.0
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+ Warning:
+
+ If your shell only supports 32-bit signed arithmatic (ash or dash), then
+ the ipcalc command produces incorrect information for IP addresses
+ 128.0.0.0-1 and for /1 networks. Bash should produce correct information
+ for all valid IP addresses.
+
+
+ - An 'iprange' command has been added to /sbin/shorewall.
+
+ iprange <address>-<address>
+
+ This command decomposes a range of IP addressses into a list of network
+ and host addresses. The command can be useful if you need to construct an
+ efficient set of rules that accept connections from a range of network
+ addresses.
+
+ Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
+ then the range may not span 128.0.0.0.
+
+ Example:
+
+ [root@gateway root]# shorewall iprange
+ 192.168.1.4-192.168.12.9
+ 192.168.1.4/30
+ 192.168.1.8/29
+ 192.168.1.16/28
+ 192.168.1.32/27
+ 192.168.1.64/26
+ 192.168.1.128/25
+ 192.168.2.0/23
+ 192.168.4.0/22
+ 192.168.8.0/22
+ 192.168.12.0/29
+ 192.168.12.8/31
+ [root@gateway root]#
+
+
+ - A list of host/net addresses is now allowed in an entry in
+ /etc/shorewall/hosts.
+
+ Example:
+
+ foo
+ eth1:192.168.1.0/24,192.168.2.0/24
+
+
+ - The "shorewall check" command now includes the chain name when printing
+ the applicable policy for each pair of zones.
+
+ Example:
+
+ Policy for dmz to net is
+ REJECT using chain all2all
+
+ This means that the policy for connections from the dmz to the internet
+ is REJECT and the applicable entry in the /etc/shorewall/policy was the
+ all->all policy.
+
+
+ - Support for the 2.6 Kernel series has been added.
+
+
+
+7/15/2003 - New Mirror in Brazil
+
+Thanks to the folks at securityopensource.org.br, there is now a Shorewall
+mirror in Brazil.
+
+7/15/2003 - Shorewall-1.4.6 RC 1
+
+
+Problems Corrected:
+
+
+ - A problem seen on RH7.3 systems where Shorewall encountered start
+ errors when started using the "service" mechanism has been worked
+ around.
+
+
+ - Where a list of IP addresses appears in the DEST column of a DNAT[-]
+ rule, Shorewall incorrectly created multiple DNAT rules in the nat table
+ (one for each element in the list). Shorewall now correctly creates a
+ single DNAT rule with multiple "--to-destination" clauses.
+
+
+ - Corrected a problem in Beta 1 where DNS names containing a "-" were
+ mis-handled when they appeared in the DEST column of a rule.
+
+
+ - A number of problems with rule parsing have been corrected. Corrections
+ involve the handling of "z1!z2" in the SOURCE column as well as lists in
+ the ORIGINAL DESTINATION column.
+
+
+
+Migration Issues:
+
+
+ - In earlier versions, an undocumented feature allowed entries in the
+ host file as follows:
+
+ z
+ eth1:192.168.1.0/24,eth2:192.168.2.0/24
+
+ This capability was never documented and has been removed in 1.4.6 to
+ allow entries of the following format:
+
+ z eth1:192.168.1.0/24,192.168.2.0/24
+
+
+ - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
+ from /etc/shorewall/shorewall.conf. These capabilities are now
+ automatically detected by Shorewall (see below).
+
+
+
+New Features:
+
+
+ - A 'newnotsyn' interface option has been added. This option may be
+ specified in /etc/shorewall/interfaces and overrides the setting
+ NEWNOTSYN=No for packets arriving on the associated interface.
+
+
+ - The means for specifying a range of IP addresses in /etc/shorewall/masq
+ to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
+ address ranges.
+
+
+ - Shorewall can now add IP addresses to subnets other than the first one
+ on an interface.
+
+
+ - DNAT[-] rules may now be used to load balance (round-robin) over a set
+ of servers. Servers may be specified in a range of addresses given as
+ <first address>-<last address>.
+
+ Example:
+
+ DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
+
+
+ - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
+ have been removed and have been replaced by code that detects whether
+ these capabilities are present in the current kernel. The output of the
+ start, restart and check commands have been enhanced to report the
+ outcome:
+
+ Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Verifying Configuration...
+
+
+ - Support for the Connection Tracking Match Extension has been added.
+ This extension is available in recent kernel/iptables releases and allows
+ for rules which match against elements in netfilter's connection tracking
+ table. Shorewall automatically detects the availability of this extension
+ and reports its availability in the output of the start, restart and
+ check commands.
+
+ Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Connection Tracking Match: Available
+ Verifying Configuration...
+
+ If this extension is available, the ruleset generated by Shorewall is
+ changed in the following ways:
+
+ - To handle 'norfc1918' filtering, Shorewall will not create chains
+ in the mangle table but will rather do all 'norfc1918' filtering in
+ the filter table (rfc1918 chain).
+ - Recall that Shorewall DNAT rules generate two netfilter rules; one
+ in the nat table and one in the filter table. If the Connection
+ Tracking Match Extension is available, the rule in the filter table
+ is extended to check that the original destination address was the
+ same as specified (or defaulted to) in the DNAT rule.
+
+
+
+ - The shell used to interpret the firewall script
+ (/usr/share/shorewall/firewall) may now be specified using the
+ SHOREWALL_SHELL parameter in shorewall.conf.
+
+
+ - An 'ipcalc' command has been added to /sbin/shorewall.
+
+ ipcalc [ <address> <netmask> |
+ <address>/<vlsm> ]
+
+ Examples:
+
+ [root@wookie root]# shorewall ipcalc
+ 192.168.1.0/24
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+ [root@wookie root]# shorewall ipcalc
+ 192.168.1.0 255.255.255.0
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+ Warning:
+
+ If your shell only supports 32-bit signed arithmatic (ash or dash), then
+ the ipcalc command produces incorrect information for IP addresses
+ 128.0.0.0-1 and for /1 networks. Bash should produce correct information
+ for all valid IP addresses.
+
+
+ - An 'iprange' command has been added to /sbin/shorewall.
+
+ iprange <address>-<address>
+
+ This command decomposes a range of IP addressses into a list of network
+ and host addresses. The command can be useful if you need to construct an
+ efficient set of rules that accept connections from a range of network
+ addresses.
+
+ Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
+ then the range may not span 128.0.0.0.
+
+ Example:
+
+ [root@gateway root]# shorewall iprange
+ 192.168.1.4-192.168.12.9
+ 192.168.1.4/30
+ 192.168.1.8/29
+ 192.168.1.16/28
+ 192.168.1.32/27
+ 192.168.1.64/26
+ 192.168.1.128/25
+ 192.168.2.0/23
+ 192.168.4.0/22
+ 192.168.8.0/22
+ 192.168.12.0/29
+ 192.168.12.8/31
+ [root@gateway root]#
+
+
+ - A list of host/net addresses is now allowed in an entry in
+ /etc/shorewall/hosts.
+
+ Example:
+
+ foo
+ eth1:192.168.1.0/24,192.168.2.0/24
+
+
+7/7/2003 - Shorewall-1.4.6 Beta 2
+
+Problems Corrected:
+
+
+ - A problem seen on RH7.3 systems where Shorewall encountered start
+ errors when started using the "service" mechanism has been worked
+ around.
+
+
+ - Where a list of IP addresses appears in the DEST column of a DNAT[-]
+ rule, Shorewall incorrectly created multiple DNAT rules in the nat table
+ (one for each element in the list). Shorewall now correctly creates a
+ single DNAT rule with multiple "--to-destination" clauses.
+
+
+ - Corrected a problem in Beta 1 where DNS names containing a "-" were
+ mis-handled when they appeared in the DEST column of a rule.
+
+
+
+Migration Issues:
+
+
+ - In earlier versions, an undocumented feature allowed entries in the
+ host file as follows:
+
+ z
+ eth1:192.168.1.0/24,eth2:192.168.2.0/24
+
+ This capability was never documented and has been removed in 1.4.6 to
+ allow entries of the following format:
+
+ z eth1:192.168.1.0/24,192.168.2.0/24
+
+
+ - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
+ from /etc/shorewall/shorewall.conf. These capabilities are now
+ automatically detected by Shorewall (see below).
+
+
+
+New Features:
+
+
+ - A 'newnotsyn' interface option has been added. This option may be
+ specified in /etc/shorewall/interfaces and overrides the setting
+ NEWNOTSYN=No for packets arriving on the associated interface.
+
+
+ - The means for specifying a range of IP addresses in /etc/shorewall/masq
+ to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
+ address ranges.
+
+
+ - Shorewall can now add IP addresses to subnets other than the first one
+ on an interface.
+
+
+ - DNAT[-] rules may now be used to load balance (round-robin) over a set
+ of servers. Servers may be specified in a range of addresses given as
+ <first address>-<last address>.
+
+ Example:
+
+ DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
+
+
+ - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
+ have been removed and have been replaced by code that detects whether
+ these capabilities are present in the current kernel. The output of the
+ start, restart and check commands have been enhanced to report the
+ outcome:
+
+ Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Verifying Configuration...
+
+
+ - Support for the Connection Tracking Match Extension has been added.
+ This extension is available in recent kernel/iptables releases and allows
+ for rules which match against elements in netfilter's connection tracking
+ table. Shorewall automatically detects the availability of this extension
+ and reports its availability in the output of the start, restart and
+ check commands.
+
+ Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Connection Tracking Match: Available
+ Verifying Configuration...
+
+ If this extension is available, the ruleset generated by Shorewall is
+ changed in the following ways:
+
+ - To handle 'norfc1918' filtering, Shorewall will not create chains
+ in the mangle table but will rather do all 'norfc1918' filtering in
+ the filter table (rfc1918 chain).
+ - Recall that Shorewall DNAT rules generate two netfilter rules; one
+ in the nat table and one in the filter table. If the Connection
+ Tracking Match Extension is available, the rule in the filter table
+ is extended to check that the original destination address was the
+ same as specified (or defaulted to) in the DNAT rule.
+
+
+
+ - The shell used to interpret the firewall script
+ (/usr/share/shorewall/firewall) may now be specified using the
+ SHOREWALL_SHELL parameter in shorewall.conf.
+
+
+ - An 'ipcalc' command has been added to /sbin/shorewall.
+
+ ipcalc [ <address> <netmask> |
+ <address>/<vlsm> ]
+
+ Examples:
+
+ [root@wookie root]# shorewall ipcalc
+ 192.168.1.0/24
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+ [root@wookie root]# shorewall ipcalc
+ 192.168.1.0 255.255.255.0
+ CIDR=192.168.1.0/24
+ NETMASK=255.255.255.0
+ NETWORK=192.168.1.0
+
+ BROADCAST=192.168.1.255
+ [root@wookie root]#
+
+ Warning:
+
+ If your shell only supports 32-bit signed arithmatic (ash or dash), then
+ the ipcalc command produces incorrect information for IP addresses
+ 128.0.0.0-1 and for /1 networks. Bash should produce correct information
+ for all valid IP addresses.
+
+
+ - An 'iprange' command has been added to /sbin/shorewall.
+
+ iprange <address>-<address>
+
+ This command decomposes a range of IP addressses into a list of network
+ and host addresses. The command can be useful if you need to construct an
+ efficient set of rules that accept connections from a range of network
+ addresses.
+
+ Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
+ then the range may not span 128.0.0.0.
+
+ Example:
+
+ [root@gateway root]# shorewall iprange
+ 192.168.1.4-192.168.12.9
+ 192.168.1.4/30
+ 192.168.1.8/29
+ 192.168.1.16/28
+ 192.168.1.32/27
+ 192.168.1.64/26
+ 192.168.1.128/25
+ 192.168.2.0/23
+ 192.168.4.0/22
+ 192.168.8.0/22
+ 192.168.12.0/29
+ 192.168.12.8/31
+ [root@gateway root]#
+
+
+ - A list of host/net addresses is now allowed in an entry in
+ /etc/shorewall/hosts.
+
+ Example:
+
+ foo
+ eth1:192.168.1.0/24,192.168.2.0/24
+
+
+
+
+7/4/2003 - Shorewall-1.4.6 Beta 1
+
+Problems Corrected:
+
+
+ - A problem seen on RH7.3 systems where Shorewall encountered start
+ errors when started using the "service" mechanism has been worked
+ around.
+
+
+ - Where a list of IP addresses appears in the DEST column of a DNAT[-]
+ rule, Shorewall incorrectly created multiple DNAT rules in the nat table
+ (one for each element in the list). Shorewall now correctly creates a
+ single DNAT rule with multiple "--to-destination" clauses.
+
+
+
+New Features:
+
+
+ - A 'newnotsyn' interface option has been added. This option may be
+ specified in /etc/shorewall/interfaces and overrides the setting
+ NEWNOTSYN=No for packets arriving on the associated interface.
+
+
+ - The means for specifying a range of IP addresses in /etc/shorewall/masq
+ to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
+ address ranges.
+
+
+ - Shorewall can now add IP addresses to subnets other than the first one
+ on an interface.
+
+
+ - DNAT[-] rules may now be used to load balance (round-robin) over a set
+ of servers. Up to 256 servers may be specified in a range of addresses
+ given as <first address>-<last address>.
+
+ Example:
+
+ DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
+
+ Note that this capability has previously been available using a
+ combination of a DNAT- rule and one or more ACCEPT rules. That technique
+ is still preferable for load-balancing over a large number of servers
+ (> 16) since specifying a range in the DNAT rule causes one filter
+ table ACCEPT rule to be generated for each IP address in the range.
+
+
+ - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
+ have been removed and have been replaced by code that detects whether
+ these capabilities are present in the current kernel. The output of the
+ start, restart and check commands have been enhanced to report the
+ outcome:
+
+ Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Verifying Configuration...
+
+
+ - Support for the Connection Tracking Match Extension has been added.
+ This extension is available in recent kernel/iptables releases and allows
+ for rules which match against elements in netfilter's connection tracking
+ table. Shorewall automatically detects the availability of this extension
+ and reports its availability in the output of the start, restart and
+ check commands.
+
+ Shorewall has detected the following iptables/netfilter capabilities:
+ NAT: Available
+ Packet Mangling: Available
+ Multi-port Match: Available
+ Connection Tracking Match: Available
+ Verifying Configuration...
+
+ If this extension is available, the ruleset generated by Shorewall is
+ changed in the following ways:
+
+ - To handle 'norfc1918' filtering, Shorewall will not create chains
+ in the mangle table but will rather do all 'norfc1918' filtering in
+ the filter table (rfc1918 chain).
+ - Recall that Shorewall DNAT rules generate two netfilter rules; one
+ in the nat table and one in the filter table. If the Connection
+ Tracking Match Extension is available, the rule in the filter table
+ is extended to check that the original destination address was the
+ same as specified (or defaulted to) in the DNAT rule.
+
+
+
+ - The shell used to interpret the firewall script
+ (/usr/share/shorewall/firewall) may now be specified using the
+ SHOREWALL_SHELL parameter in shorewall.conf.
+
+
+
+6/17/2003 - Shorewall-1.4.5
+
+Problems Corrected:
+
+
+ - The command "shorewall debug try <directory>" now correctly
+ traces the attempt.
+ - The INCLUDE directive now works properly in the zones file; previously,
+ INCLUDE in that file was ignored.
+ - /etc/shorewall/routestopped records with an empty second column are no
+ longer ignored.
+
+
+
+New Features:
+
+
+ - The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now
+ contain a list of addresses. If the list begins with "!' then the rule
+ will take effect only if the original destination address in the
+ connection request does not match any of the addresses listed.
+
+
+6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8
+
+The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and
+iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems
+have been encountered with this set of software. The Shorewall version is
+1.4.4b plus the accumulated changes for 1.4.5.
+
+
+6/8/2003 - Updated Samples
+
+Thanks to Francesca Smith, the samples have been updated to Shorewall
+version 1.4.4.
+
+5/29/2003 - Shorewall-1.4.4b
+
+Groan -- This version corrects a problem whereby the --log-level was not
+being set when logging via syslog. The most commonly reported symptom was
+that Shorewall messages were being written to the console even though console
+logging was correctly configured per FAQ 16.
+
+
+5/27/2003 - Shorewall-1.4.4a
+The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out that
+the code in 1.4.4 restricts the length of short zone names to 4 characters.
+I've produced version 1.4.4a that restores the previous 5-character limit by
+conditionally omitting the log rule number when the LOGFORMAT doesn't contain
+'%d'.
+
+
+5/23/2003 - Shorewall-1.4.4
+I apologize for the rapid-fire releases but since there is a potential
+configuration change required to go from 1.4.3a to 1.4.4, I decided to make
+it a full release rather than just a bug-fix release.
+
+ Problems corrected:
+
+
+
+ None.
+
+ New Features:
+
+
+ - A REDIRECT- rule target has been added. This target behaves for
+ REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter nat
+ table REDIRECT rule is added but not the companion filter table ACCEPT
+ rule.
+
+
+ - The LOGMARKER variable has been renamed LOGFORMAT and has been changed
+ to a 'printf' formatting template which accepts three arguments (the
+ chain name, logging rule number and the disposition). To use LOGFORMAT
+ with fireparse (http://www.fireparse.com), set it
+ as:
+
+ LOGFORMAT="fp=%s:%d a=%s "
+
+ CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT
+ string (up to but not including the first '%') to find log messages in
+ the 'show log', 'status' and 'hits' commands. This part should not be
+ omitted (the LOGFORMAT should not begin with "%") and the leading part
+ should be sufficiently unique for /sbin/shorewall to identify Shorewall
+ messages.
+
+
+ - When logging is specified on a DNAT[-] or REDIRECT[-] rule, the logging
+ now takes place in the nat table rather than in the filter table. This
+ way, only those connections that actually undergo DNAT or redirection
+ will be logged.
+
+
+
+5/20/2003 - Shorewall-1.4.3a
+
+This version primarily corrects the documentation included in the .tgz and in
+the .rpm. In addition:
+
+
+ - (This change is in 1.4.3 but is not documented) If you are running
+ iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject
+ replies as follows:
+ a) tcp - RST
+ b) udp - ICMP port unreachable
+ c) icmp - ICMP host unreachable
+ d) Otherwise - ICMP host prohibited
+ If you are running earlier software, Shorewall will follow it's
+ traditional convention:
+ a) tcp - RST
+ b) Otherwise - ICMP port unreachable
+ - UDP port 135 is now silently dropped in the common.def chain. Remember
+ that this chain is traversed just before a DROP or REJECT policy is
+ enforced.
+
+
+
+5/18/2003 - Shorewall 1.4.3
+
+ Problems Corrected:
+
+
+ - There were several cases where Shorewall would fail to remove a
+ temporary directory from /tmp. These cases have been corrected.
+ - The rules for allowing all traffic via the loopback interface have been
+ moved to before the rule that drops status=INVALID packets. This insures
+ that all loopback traffic is allowed even if Netfilter connection
+ tracking is confused.
+
+ New Features:
+
+
+ - IPV6-IPV4 (6to4) tunnels are now supported in the
+ /etc/shorewall/tunnels file.
+ - You may now change the leading portion of the --log-prefix
+ used by Shorewall using the LOGMARKER variable in shorewall.conf. By
+ default, "Shorewall:" is used.
+
+
+
+5/10/2003 - Shorewall Mirror in Asia
+
+
+Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
+
+
+5/8/2003 - Shorewall Mirror in Chile
+Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.
+
+4/21/2003 - Samples updated for Shorewall version 1.4.2
+
+Thanks to Francesca Smith, the sample configurations are now upgraded to
+Shorewall version 1.4.2.
+
+4/9/2003 - Shorewall 1.4.2
+
+
+ Problems Corrected:
+
+
+
+ - TCP connection requests rejected out of the common chain are
+ now properly rejected with TCP RST; previously, some of these requests
+ were rejected with an ICMP port-unreachable response.
+ - 'traceroute -I' from behind the firewall previously timed out on the
+ first hop (e.g., to the firewall). This has been worked around.
+
+
+
+ New Features:
+
+ - Where an entry in the/etc/shorewall/hosts file specifies a particular
+ host or network, Shorewall now creates an intermediate chain for handling
+ input from the related zone. This can substantially reduce the number of
+ rules traversed by connections requests from such zones.
+
+
+ - Any file may include an INCLUDE directive. An INCLUDE directive
+ consists of the word INCLUDE followed by a file name and causes the
+ contents of the named file to be logically included into the file
+ containing the INCLUDE. File names given in an INCLUDE directive are
+ assumed to reside in /etc/shorewall or in an alternate configuration
+ directory if one has been specified for the command.
+
+ Examples:
+ shorewall/params.mgmt:
+ MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
+ TIME_SERVERS=4.4.4.4
+ BACKUP_SERVERS=5.5.5.5
+ ----- end params.mgmt -----
+
+
+ shorewall/params:
+ # Shorewall 1.3 /etc/shorewall/params
+ [..]
+ #######################################
+
+ INCLUDE params.mgmt
+
+ # params unique to this host here
+ #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT
+ REMOVE
+ ----- end params -----
+
+
+ shorewall/rules.mgmt:
+ ACCEPT
+ net:$MGMT_SERVERS
+ $FW tcp 22
+ ACCEPT
+ $FW
+ net:$TIME_SERVERS udp 123
+ ACCEPT
+ $FW
+ net:$BACKUP_SERVERS tcp 22
+ ----- end rules.mgmt -----
+
+ shorewall/rules:
+ # Shorewall version 1.3 - Rules File
+ [..]
+ #######################################
+
+ INCLUDE rules.mgmt
+
+ # rules unique to this host here
+ #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT
+ REMOVE
+ ----- end rules -----
+
+ INCLUDE's may be nested to a level of 3 -- further nested INCLUDE
+ directives are ignored with a warning message.
+
+
+ - Routing traffic from an interface back out that interface continues to
+ be a problem. While I firmly believe that this should never happen,
+ people continue to want to do it. To limit the damage that such nonsense
+ produces, I have added a new 'routeback' option in
+ /etc/shorewall/interfaces and /etc/shorewall/hosts. When used in
+ /etc/shorewall/interfaces, the 'ZONE' column may not contain '-'; in
+ other words, 'routeback' can't be used as an option for a multi-zone
+ interface. The 'routeback' option CAN be specified however on individual
+ group entries in /etc/shorewall/hosts.
+
+ The 'routeback' option is similar to the old 'multi' option with two
+ exceptions:
+
+ a) The option pertains to a particular
+ zone,interface,address tuple.
+
+ b) The option only created infrastructure to pass traffic
+ from (zone,interface,address) tuples back to themselves (the 'multi'
+ option affected all (zone,interface,address) tuples associated with the
+ given 'interface').
+
+ See the 'Upgrade Issues' for information
+ about how this new option may affect your configuration.
+
+
+
+3/24/2003 - Shorewall 1.4.1
+
+This release follows up on 1.4.0. It corrects a problem introduced in
+1.4.0 and removes additional warts.
+
+Problems Corrected:
+
+
+ - When Shorewall 1.4.0 is run under the ash shell (such as on
+ Bering/LEAF), it can attempt to add ECN disabling rules even if the
+ /etc/shorewall/ecn file is empty. That problem has been corrected so that
+ ECN disabling rules are only added if there are entries in
+ /etc/shorewall/ecn.
+
+New Features:
+
+
+
+ Note: In the list that follows, the term group refers to a
+ particular network or subnetwork (which may be 0.0.0.0/0 or it may be a
+ host address) accessed through a particular interface. Examples:
+
+
+
+ eth0:0.0.0.0/0
+ eth2:192.168.1.0/24
+ eth3:192.0.2.123
+
+ You can use the "shorewall check" command to see the groups associated with
+ each of your zones.
+
+
+ - Beginning with Shorewall 1.4.1, if a zone Z comprises more than one
+ group then if there is no explicit Z to Z policy and there are no rules
+ governing traffic from Z to Z then Shorewall will permit all traffic
+ between the groups in the zone.
+ - Beginning with Shorewall 1.4.1, Shorewall will never create rules to
+ handle traffic from a group to itself.
+ - A NONE policy is introduced in 1.4.1. When a policy of NONE is
+ specified from Z1 to Z2:
+
+
+ - There may be no rules created that govern connections from Z1 to
+ Z2.
+ - Shorewall will not create any infrastructure to handle traffic from Z1
+ to Z2.
+
+See the upgrade issues for a discussion of
+how these changes may affect your configuration.
+
+3/17/2003 - Shorewall 1.4.0
+Shorewall 1.4 represents the next step in the evolution of Shorewall. The
+main thrust of the initial release is simply to remove the cruft that has
+accumulated in Shorewall over time.
+
+IMPORTANT: Shorewall 1.4.0 requires the iproute package ('ip'
+utility).
+
+Function from 1.3 that has been omitted from this version include:
+
+
+ - The MERGE_HOSTS variable in shorewall.conf is no longer supported.
+ Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
+
+
+ - Interface names of the form <device>:<integer> in
+ /etc/shorewall/interfaces now generate an error.
+
+
+ - Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No.
+ OLD_PING_HANDLING=Yes will generate an error at startup as will
+ specification of the 'noping' or 'filterping' interface options.
+
+
+ - The 'routestopped' option in the /etc/shorewall/interfaces and
+ /etc/shorewall/hosts files is no longer supported and will generate an
+ error at startup if specified.
+
+
+ - The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
+ accepted.
+
+
+ - The ALLOWRELATED variable in shorewall.conf is no longer supported.
+ Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
+
+
+ - The icmp.def file has been removed.
+
+
+Changes for 1.4 include:
+
+
+ - The /etc/shorewall/shorewall.conf file has been completely reorganized
+ into logical sections.
+
+
+ - LOG is now a valid action for a rule (/etc/shorewall/rules).
+
+
+ - The firewall script and version file are now installed in
+ /usr/share/shorewall.
+
+
+ - Late arriving DNS replies are now silently dropped in the common chain
+ by default.
+
+
+ - In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 no
+ longer unconditionally accepts outbound ICMP packets. So if you want to
+ 'ping' from the firewall, you will need the appropriate rule or
+ policy.
+
+
+ - CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
+
+
+ - 802.11b devices with names of the form wlan<n> now support the
+ 'maclist' option.
+
+
+ - Explicit Congestion Notification (ECN - RFC 3168) may now be turned off
+ on a host or network basis using the new /etc/shorewall/ecn file. To use
+ this facility:
+
+ a) You must be running kernel 2.4.20
+ b) You must have applied the patch in
+ http://www.shorewall/net/pub/shorewall/ecn/patch.
+ c) You must have iptables 1.2.7a installed.
+
+
+ - The /etc/shorewall/params file is now processed first so that variables
+ may be used in the /etc/shorewall/shorewall.conf file.
+
+
+ - Shorewall now gives a more helpful diagnostic when the
+ 'ipchains' compatibility kernel module is loaded and a 'shorewall start'
+ command is issued.
+
+
+ - The SHARED_DIR variable has been removed from shorewall.conf. This
+ variable was for use by package maintainers and was not documented for
+ general use.
+
+
+ - Shorewall now ignores 'default' routes when detecting masq'd
+ networks.
+
+
+3/10/2003 - Shoreall 1.3.14a
+
+A roleup of the following bug fixes and other updates:
+
+ - There is an updated rfc1918 file that reflects the resent allocation of
+ 222.0.0.0/8 and 223.0.0.0/8.
+
+
+ - The documentation for the routestopped file claimed that a
+ comma-separated list could appear in the second column while the code
+ only supported a single host or network address.
+ - Log messages produced by 'logunclean' and 'dropunclean' were not
+ rate-limited.
+ - 802.11b devices with names of the form wlan<n> don't
+ support the 'maclist' interface option.
+ - Log messages generated by RFC 1918 filtering are not rate limited.
+ - The firewall fails to start in the case where you have "eth0 eth1" in
+ /etc/shorewall/masq and the default route is through eth1
+
+
+2/8/2003 - Shoreawall 1.3.14
+
+New features include
+
+ - An OLD_PING_HANDLING option has been added to shorewall.conf. When set
+ to Yes, Shorewall ping handling is as it has always been (see
+ http://www.shorewall.net/ping.html).
+
+ When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
+ policies just like any other connection request. The FORWARDPING=Yes
+ option in shorewall.conf and the 'noping' and 'filterping' options in
+ /etc/shorewall/interfaces will all generate an error.
+
+
+ - It is now possible to direct Shorewall to create a "label" such
+ as "eth0:0" for IP addresses that it creates under
+ ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying
+ the label instead of just the interface name:
+
+ a) In the INTERFACE column of /etc/shorewall/masq
+ b) In the INTERFACE column of /etc/shorewall/nat
+
+ - Support for OpenVPN Tunnels.
+
+
+ - Support for VLAN devices with names of the form $DEV.$VID (e.g.,
+ eth0.0)
+
+
+ - In /etc/shorewall/tcrules, the MARK value may be optionally followed by
+ ":" and either 'F' or 'P' to designate that the marking will occur in the
+ FORWARD or PREROUTING chains respectively. If this additional
+ specification is omitted, the chain used to mark packets will be
+ determined by the setting of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
+
+
+ - When an interface name is entered in the SUBNET column of the
+ /etc/shorewall/masq file, Shorewall previously masqueraded traffic from
+ only the first subnet defined on that interface. It did not masquerade
+ traffic from:
+
+ a) The subnets associated with other addresses on the
+ interface.
+ b) Subnets accessed through local routers.
+
+ Beginning with Shorewall 1.3.14, if you enter an interface name in the
+ SUBNET column, shorewall will use the firewall's routing table to
+ construct the masquerading/SNAT rules.
+
+ Example 1 -- This is how it works in 1.3.14.
+
+
+ [root@gateway test]# cat /etc/shorewall/masq
+ #INTERFACE SUBNET ADDRESS
+ eth0 eth2 206.124.146.176
+ #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+ [root@gateway test]# ip route show dev eth2
+ 192.168.1.0/24 scope link
+ 192.168.10.0/24 proto kernel scope link src 192.168.10.254
+
+ [root@gateway test]# shorewall start
+ ...
+ Masqueraded Subnets and Hosts:
+ To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
+ To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
+ Processing /etc/shorewall/tos...
+
+ When upgrading to Shorewall 1.3.14, if you have multiple local subnets
+ connected to an interface that is specified in the SUBNET column of an
+ /etc/shorewall/masq entry, your /etc/shorewall/masq file will need
+ changing. In most cases, you will simply be able to remove redundant
+ entries. In some cases though, you might want to change from using the
+ interface name to listing specific subnetworks if the change described
+ above will cause masquerading to occur on subnetworks that you don't wish
+ to masquerade.
+
+ Example 2 -- Suppose that your current config is as follows:
+
+
+ [root@gateway test]# cat /etc/shorewall/masq
+ #INTERFACE SUBNET ADDRESS
+ eth0 eth2 206.124.146.176
+ eth0 192.168.10.0/24 206.124.146.176
+ #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+ [root@gateway test]# ip route show dev eth2
+ 192.168.1.0/24 scope link
+ 192.168.10.0/24 proto kernel scope link src 192.168.10.254
+ [root@gateway test]#
+
+ In this case, the second entry in /etc/shorewall/masq is no
+ longer required.
+
+ Example 3 -- What if your current configuration is like this?
+
+
+ [root@gateway test]# cat /etc/shorewall/masq
+ #INTERFACE SUBNET ADDRESS
+ eth0 eth2 206.124.146.176
+ #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+ [root@gateway test]# ip route show dev eth2
+ 192.168.1.0/24 scope link
+ 192.168.10.0/24 proto kernel scope link src 192.168.10.254
+ [root@gateway test]#
+
+ In this case, you would want to change the entry in
+ /etc/shorewall/masq to:
+
+ #INTERFACE SUBNET ADDRESS
+ eth0 192.168.1.0/24 206.124.146.176
+ #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+
+
+
+2/5/2003 - Shorewall Support included in Webmin 1.060
+
+Webmin version 1.060 now has Shorewall support included as standard. See
+http://www.webmin.com.
+
+2/4/2003 - Shorewall 1.3.14-RC1
+
+Includes the Beta 2 content plus support for OpenVPN tunnels.
+
+1/28/2003 - Shorewall 1.3.14-Beta2
+
+Includes the Beta 1 content plus restores VLAN device names of the form
+$dev.$vid (e.g., eth0.1)
+
+1/25/2003 - Shorewall 1.3.14-Beta1
+
+
+The Beta includes the following changes:
+
+
+ - An OLD_PING_HANDLING option has been added to shorewall.conf. When set
+ to Yes, Shorewall ping handling is as it has always been (see
+ http://www.shorewall.net/ping.html).
+
+ When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
+ policies just like any other connection request. The FORWARDPING=Yes
+ option in shorewall.conf and the 'noping' and 'filterping' options in
+ /etc/shorewall/interfaces will all generate an error.
+
+
+ - It is now possible to direct Shorewall to create a "label" such
+ as "eth0:0" for IP addresses that it creates under
+ ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying
+ the label instead of just the interface name:
+
+ a) In the INTERFACE column of /etc/shorewall/masq
+ b) In the INTERFACE column of /etc/shorewall/nat
+
+ - When an interface name is entered in the SUBNET column of the
+ /etc/shorewall/masq file, Shorewall previously masqueraded traffic from
+ only the first subnet defined on that interface. It did not masquerade
+ traffic from:
+
+ a) The subnets associated with other addresses on the
+ interface.
+ b) Subnets accessed through local routers.
+
+ Beginning with Shorewall 1.3.14, if you enter an interface name in the
+ SUBNET column, shorewall will use the firewall's routing table to
+ construct the masquerading/SNAT rules.
+
+ Example 1 -- This is how it works in 1.3.14.
+
+
+ [root@gateway test]# cat /etc/shorewall/masq
+ #INTERFACE SUBNET ADDRESS
+ eth0 eth2 206.124.146.176
+ #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+ [root@gateway test]# ip route show dev eth2
+ 192.168.1.0/24 scope link
+ 192.168.10.0/24 proto kernel scope link src 192.168.10.254
+
+ [root@gateway test]# shorewall start
+ ...
+ Masqueraded Subnets and Hosts:
+ To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
+ To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
+ Processing /etc/shorewall/tos...
+
+ When upgrading to Shorewall 1.3.14, if you have multiple local subnets
+ connected to an interface that is specified in the SUBNET column of an
+ /etc/shorewall/masq entry, your /etc/shorewall/masq file will need
+ changing. In most cases, you will simply be able to remove redundant
+ entries. In some cases though, you might want to change from using the
+ interface name to listing specific subnetworks if the change described
+ above will cause masquerading to occur on subnetworks that you don't wish
+ to masquerade.
+
+ Example 2 -- Suppose that your current config is as follows:
+
+
+ [root@gateway test]# cat /etc/shorewall/masq
+ #INTERFACE SUBNET ADDRESS
+ eth0 eth2 206.124.146.176
+ eth0 192.168.10.0/24 206.124.146.176
+ #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+ [root@gateway test]# ip route show dev eth2
+ 192.168.1.0/24 scope link
+ 192.168.10.0/24 proto kernel scope link src 192.168.10.254
+ [root@gateway test]#
+
+ In this case, the second entry in /etc/shorewall/masq is no
+ longer required.
+
+ Example 3 -- What if your current configuration is like this?
+
+
+ [root@gateway test]# cat /etc/shorewall/masq
+ #INTERFACE SUBNET ADDRESS
+ eth0 eth2 206.124.146.176
+ #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+ [root@gateway test]# ip route show dev eth2
+ 192.168.1.0/24 scope link
+ 192.168.10.0/24 proto kernel scope link src 192.168.10.254
+ [root@gateway test]#
+
+ In this case, you would want to change the entry in
+ /etc/shorewall/masq to:
+
+ #INTERFACE SUBNET ADDRESS
+ eth0 192.168.1.0/24 206.124.146.176
+ #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+
+
+1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format
+
+Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13
+documenation. the PDF may be downloaded from
+ ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
+ http://slovakia.shorewall.net/pub/shorewall/pdf/
+
+1/17/2003 - shorewall.net has MOVED
+
+Thanks to the generosity of Alex Martin and Rett Consulting, www.shorewall.net and
+ftp.shorewall.net are now hosted on a system in Bellevue, Washington. A big
+thanks to Alex for making this happen.
+
+
+1/13/2003 - Shorewall 1.3.13
+
+
+Just includes a few things that I had on the burner:
+
+
+ - A new 'DNAT-' action has been added for entries in the
+ /etc/shorewall/rules file. DNAT- is intended for advanced users who wish
+ to minimize the number of rules that connection requests must
+ traverse.
+
+ A Shorewall DNAT rule actually generates two iptables rules: a header
+ rewriting rule in the 'nat' table and an ACCEPT rule in the 'filter'
+ table. A DNAT- rule only generates the first of these rules. This is
+ handy when you have several DNAT rules that would generate the same
+ ACCEPT rule.
+
+ Here are three rules from my previous rules file:
+
+ DNAT net
+ dmz:206.124.146.177 tcp smtp - 206.124.146.178
+ DNAT net
+ dmz:206.124.146.177 tcp smtp - 206.124.146.179
+ ACCEPT net
+ dmz:206.124.146.177 tcp www,smtp,ftp,...
+
+ These three rules ended up generating _three_ copies of
+
+ ACCEPT net
+ dmz:206.124.146.177 tcp smtp
+
+ By writing the rules this way, I end up with only one copy
+ of the ACCEPT rule.
+
+ DNAT- net
+ dmz:206.124.146.177 tcp smtp - 206.124.146.178
+ DNAT- net
+ dmz:206.124.146.177 tcp smtp - 206.124.146.179
+ ACCEPT net
+ dmz:206.124.146.177 tcp www,smtp,ftp,....
+
+
+ - The 'shorewall check' command now prints out the applicable policy
+ between each pair of zones.
+
+
+ - A new CLEAR_TC option has been added to shorewall.conf. If this option
+ is set to 'No' then Shorewall won't clear the current traffic control
+ rules during [re]start. This setting is intended for use by people that
+ prefer to configure traffic shaping when the network interfaces come up
+ rather than when the firewall is started. If that is what you want to do,
+ set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an
+ /etc/shorewall/tcstart file. That way, your traffic shaping rules can
+ still use the 'fwmark' classifier based on packet marking defined in
+ /etc/shorewall/tcrules.
+
+
+ - A new SHARED_DIR variable has been added that allows distribution
+ packagers to easily move the shared directory (default
+ /usr/lib/shorewall). Users should never have a need to change the value
+ of this shorewall.conf setting.
+
+
+
+1/6/2003 - BURNOUT
+
+Until further notice, I will not be involved in either Shorewall
+Development or Shorewall Support
+
+-Tom Eastep
+
+
+12/30/2002 - Shorewall Documentation in PDF Format
+
+Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12
+documenation. the PDF may be downloaded from
+
+ ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
+ http://slovakia.shorewall.net/pub/shorewall/pdf/
+
+
+12/27/2002 - Shorewall 1.3.12 Released
+
+Features include:
+
+
+ - "shorewall refresh" now reloads the traffic shaping rules (tcrules and
+ tcstart).
+ - "shorewall debug [re]start" now turns off debugging after an error
+ occurs. This places the point of the failure near the end of the trace
+ rather than up in the middle of it.
+ - "shorewall [re]start" has been speeded up by more than 40% with my
+ configuration. Your milage may vary.
+ - A "shorewall show classifiers" command has been added which shows the
+ current packet classification filters. The output from this command is
+ also added as a separate page in "shorewall monitor"
+ - ULOG (must be all caps) is now accepted as a valid syslog level and
+ causes the subject packets to be logged using the ULOG target rather than
+ the LOG target. This allows you to run ulogd (available from http://www.netfilter.org/projects/ulogd/index.html)
+ and log all Shorewall messages to a
+ separate log file.
+ - If you are running a kernel that has a FORWARD chain in the mangle
+ table ("shorewall show mangle" will show you the chains in the mangle
+ table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for marking
+ input packets based on their destination even when you are using
+ Masquerading or SNAT.
+ - I have cluttered up the /etc/shorewall directory with empty 'init',
+ 'start', 'stop' and 'stopped' files. If you already have a file with one
+ of these names, don't worry -- the upgrade process won't overwrite your
+ file.
+ - I have added a new RFC1918_LOG_LEVEL variable to shorewall.conf. This variable specifies
+ the syslog level at which packets are logged as a result of entries in
+ the /etc/shorewall/rfc1918 file. Previously, these packets were always
+ logged at the 'info' level.
+
+
+
+12/20/2002 - Shorewall 1.3.12 Beta 3
+
+This version corrects a problem with Blacklist logging. In Beta 2, if
+BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall would fail to
+start and "shorewall refresh" would also fail.
+
+
+12/20/2002 - Shorewall 1.3.12 Beta 2
+
+The first public Beta version of Shorewall 1.3.12 is now available (Beta 1
+was made available only to a limited audience).
+
+Features include:
+
+
+ - "shorewall refresh" now reloads the traffic shaping rules (tcrules and
+ tcstart).
+ - "shorewall debug [re]start" now turns off debugging after an error
+ occurs. This places the point of the failure near the end of the trace
+ rather than up in the middle of it.
+ - "shorewall [re]start" has been speeded up by more than 40% with my
+ configuration. Your milage may vary.
+ - A "shorewall show classifiers" command has been added which shows the
+ current packet classification filters. The output from this command is
+ also added as a separate page in "shorewall monitor"
+ - ULOG (must be all caps) is now accepted as a valid syslog level and
+ causes the subject packets to be logged using the ULOG target rather than
+ the LOG target. This allows you to run ulogd (available from http://www.netfilter.org/projects/ulogd/index.html)
+ and log all Shorewall messages to a
+ separate log file.
+ - If you are running a kernel that has a FORWARD chain in the mangle
+ table ("shorewall show mangle" will show you the chains in the mangle
+ table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This
+ allows for marking input packets based on their destination even when you
+ are using Masquerading or SNAT.
+ - I have cluttered up the /etc/shorewall directory with empty 'init',
+ 'start', 'stop' and 'stopped' files. If you already have a file with one
+ of these names, don't worry -- the upgrade process won't overwrite your
+ file.
+
+You may download the Beta from:
+
+
+
+ http://www.shorewall.net/pub/shorewall/Beta
+ ftp://ftp.shorewall.net/pub/shorewall/Beta
+
+
+12/12/2002 - Mandrake Multi Network Firewall
+
+Shorewall is at the center of MandrakeSoft's recently-announced Multi
+Network Firewall (MNF) product. Here is the press
+release.
+
+
+12/7/2002 - Shorewall Support for Mandrake 9.0
+
+Two months and 3 days after I ordered Mandrake 9.0, it was finally
+delivered. I have installed 9.0 on one of my systems and I am now in a
+position to support Shorewall users who run Mandrake 9.0.
+
+12/6/2002 - Debian 1.3.11a Packages Available
+
+
+Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
+
+12/3/2002 - Shorewall 1.3.11a
+
+This is a bug-fix roll up which includes Roger Aich's fix for DNAT with
+excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 users who don't
+need rules of this type need not upgrade to 1.3.11.
+
+11/24/2002 - Shorewall 1.3.11
+
+In this version:
+
+ - A 'tcpflags' option has been added to entries in /etc/shorewall/interfaces. This
+ option causes Shorewall to make a set of sanity check on TCP packet
+ header flags.
+ - It is now allowed to use 'all' in the SOURCE or DEST column in a rule. When used, 'all' must appear by
+ itself (in may not be qualified) and it does not enable intra-zone
+ traffic. For example, the rule
+
+ ACCEPT loc all tcp 80
+
+ does not enable http traffic from 'loc' to 'loc'.
+ - Shorewall's use of the 'echo' command is now compatible with bash
+ clones such as ash and dash.
+ - fw->fw policies now generate a startup error. fw->fw rules
+ generate a warning and are ignored
+
+
+11/14/2002 - Shorewall Documentation in PDF Format
+
+Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10
+documenation. the PDF may be downloaded from
+
+ ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
+ http://slovakia.shorewall.net/pub/shorewall/pdf/
+
+
+11/09/2002 - Shorewall is Back at SourceForge
+
+The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
+
+
+11/09/2002 - Shorewall 1.3.10
+
+In this version:
+
+
+10/24/2002 - Shorewall is now in Gentoo Linux
+
+Alexandru Hartmann reports that his Shorewall package is now a part of the Gentoo Linux distribution. Thanks
+Alex!
+
+
+10/23/2002 - Shorewall 1.3.10 Beta 1
+In this version:
+
+
+You may download the Beta from:
+
+
+
+10/10/2002 - Debian 1.3.9b Packages Available
+
+
+Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
+
+10/9/2002 - Shorewall 1.3.9b
+This release rolls up fixes to the installer and to the firewall script.
+
+
+10/6/2002 - Shorewall.net now running on RH8.0
+
+The firewall and server here at shorewall.net are now running RedHat release
+8.0.
+
+9/30/2002 - Shorewall 1.3.9a
+Roles up the fix for broken tunnels.
+
+
+9/30/2002 - TUNNELS Broken in 1.3.9!!!
+There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall
+-- copy that file to /usr/lib/shorewall/firewall.
+
+
+9/28/2002 - Shorewall 1.3.9
+
+In this version:
+
+
+ - DNS Names are now
+ allowed in Shorewall config files (although I recommend against using
+ them).
+ - The connection SOURCE may now be qualified by both interface and IP
+ address in a Shorewall rule.
+ - Shorewall startup is now disabled after initial installation until the
+ file /etc/shorewall/startup_disabled is removed. This avoids nasty
+ surprises during reboot for users who install Shorewall but don't
+ configure it.
+ - The 'functions' and 'version' files and the 'firewall' symbolic link
+ have been moved from /var/lib/shorewall to /usr/lib/shorewall to appease
+ the LFS police at Debian.
+
+
+
+9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
+Restored
+
+ A couple of recent configuration changes at www.shorewall.net
+broke the Search facility:
+
+
+
+
+ - Mailing List Archive Search was not available.
+ - The Site Search index was incomplete
+ - Only one page of matches was presented.
+
+
+Hopefully these problems are now corrected.
+
+9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
+Restored
+
+A couple of recent configuration changes at www.shorewall.net had the
+negative effect of breaking the Search facility:
+
+
+ - Mailing List Archive Search was not available.
+ - The Site Search index was incomplete
+ - Only one page of matches was presented.
+
+Hopefully these problems are now corrected.
+
+
+9/18/2002 - Debian 1.3.8 Packages Available
+
+
+Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
+
+9/16/2002 - Shorewall 1.3.8
+
+In this version:
+
+
+ - A NEWNOTSYN option has been added
+ to shorewall.conf. This option determines whether Shorewall accepts TCP
+ packets which are not part of an established connection and that are not
+ 'SYN' packets (SYN flag on and ACK flag off).
+ - The need for the 'multi' option to communicate between zones za and zb
+ on the same interface is removed in the case where the chain 'za2zb'
+ and/or 'zb2za' exists. 'za2zb' will exist if:
+
+ - There is a policy for za to zb; or
+ - There is at least one rule for za to zb.
+
+
+
+ - The /etc/shorewall/blacklist file now contains three columns. In
+ addition to the SUBNET/ADDRESS column, there are optional PROTOCOL and
+ PORT columns to block only certain applications from the blacklisted
+ addresses.
+
+
+
+9/11/2002 - Debian 1.3.7c Packages Available
+
+Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
+
+9/2/2002 - Shorewall 1.3.7c
+
+This is a role up of a fix for "DNAT" rules where the source zone is $FW
+(fw).
+
+8/31/2002 - I'm not available
+
+I'm currently on vacation -- please respect my need for a couple of
+weeks free of Shorewall problem reports.
+
+-Tom
+
+8/26/2002 - Shorewall 1.3.7b
+
+This is a role up of the "shorewall refresh" bug fix and the change which
+reverses the order of "dhcp" and "norfc1918" checking.
+
+8/26/2002 - French FTP Mirror is Operational
+
+ftp://france.shorewall.net/pub/mirrors/shorewall
+is now available.
+
+8/25/2002 - Shorewall Mirror in France
+
+Thanks to a Shorewall user in Paris, the Shorewall web site is now
+mirrored at http://france.shorewall.net.
+
+8/25/2002 - Shorewall 1.3.7a Debian Packages Available
+
+Lorenzo Martignoni reports that the packages for version 1.3.7a are
+available at http://security.dsi.unimi.it/~lorenzo/debian.html.
+
+8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author
+-- Shorewall 1.3.7a released
+
+1.3.7a corrects problems occurring in rules file processing when starting
+Shorewall 1.3.7.
+
+8/22/2002 - Shorewall 1.3.7 Released 8/13/2002
+
+Features in this release include:
+
+ - The 'icmp.def' file is now empty! The rules in that file were required
+ in ipchains firewalls but are not required in Shorewall. Users who have
+ ALLOWRELATED=No in shorewall.conf
+ should see the Upgrade Issues.
+ - A 'FORWARDPING' option has been added to shorewall.conf. The effect of setting
+ this variable to Yes is the same as the effect of adding an ACCEPT rule
+ for ICMP echo-request in /etc/shorewall/icmpdef. Users
+ who have such a rule in icmpdef are encouraged to switch to
+ FORWARDPING=Yes.
+ - The loopback CLASS A Network (127.0.0.0/8) has been added to the
+ rfc1918 file.
+ - Shorewall now works with iptables 1.2.7
+ - The documentation and web site no longer uses FrontPage themes.
+
+
+I would like to thank John Distler for his valuable input regarding TCP
+SYN and ICMP treatment in Shorewall. That input has led to marked improvement
+in Shorewall in the last two releases.
+
+8/13/2002 - Documentation in the CVS
+Repository
+
+The Shorewall-docs project now contains just the HTML and image files -
+the Frontpage files have been removed.
+
+8/7/2002 - STABLE branch added to CVS
+Repository
+
+This branch will only be updated after I release a new version of
+Shorewall so you can always update from this branch to get the latest stable
+tree.
+
+8/7/2002 - Upgrade Issues section
+added to the Errata Page
+
+Now there is one place to go to look for issues involved with upgrading to
+recent versions of Shorewall.
+
+8/7/2002 - Shorewall 1.3.6
+
+This is primarily a bug-fix rollup with a couple of new features:
+
+
+7/30/2002 - Shorewall 1.3.5b Released
+
+This interim release:
+
+ - Causes the firewall script to remove the lock file if it is killed.
+ - Once again allows lists in the second column of the /etc/shorewall/hosts file.
+ - Includes the latest QuickStart
+ Guides.
+
+
+7/29/2002 - New Shorewall Setup Guide Available
+
+The first draft of this guide is available at http://www.shorewall.net/shorewall_setup_guide.htm.
+The guide is intended for use by people who are setting up Shorewall to
+manage multiple public IP addresses and by people who want to learn more
+about Shorewall than is described in the single-address guides. Feedback on
+the new guide is welcome.
+
+7/28/2002 - Shorewall 1.3.5 Debian Package Available
+
+Lorenzo Martignoni reports that the packages are version 1.3.5a and are
+available at http://security.dsi.unimi.it/~lorenzo/debian.html.
+
+7/27/2002 - Shorewall 1.3.5a Released
+
+This interim release restores correct handling of REDIRECT rules.
+
+7/26/2002 - Shorewall 1.3.5 Released
+
+This will be the last Shorewall release for a while. I'm going to be
+focusing on rewriting a lot of the documentation.
+
+ In this version:
+
+ - Empty and invalid source and destination qualifiers are now detected in
+ the rules file. It is a good idea to use the 'shorewall check' command
+ before you issue a 'shorewall restart' command be be sure that you don't
+ have any configuration problems that will prevent a successful
+ restart.
+ - Added MERGE_HOSTS variable in shorewall.conf to provide saner
+ behavior of the /etc/shorewall/hosts file.
+ - The time that the counters were last reset is now displayed in the
+ heading of the 'status' and 'show' commands.
+ - A proxyarp option has been added for entries in /etc/shorewall/interfaces. This
+ option facilitates Proxy ARP sub-netting as described in the Proxy ARP
+ subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/).
+ Specifying the proxyarp option for an interface causes Shorewall to set
+ /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
+ - The Samples have been updated to reflect the new capabilities in this
+ release.
+
+
+7/16/2002 - New Mirror in Argentina
+
+Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in
+Argentina. Thanks Buanzo!!!
+
+7/16/2002 - Shorewall 1.3.4 Released
+
+In this version:
+
+ - A new /etc/shorewall/routestopped
+ file has been added. This file is intended to eventually replace the
+ routestopped option in the /etc/shorewall/interface and
+ /etc/shorewall/hosts files. This new file makes remote firewall
+ administration easier by allowing any IP or subnet to be enabled while
+ Shorewall is stopped.
+ - An /etc/shorewall/stopped extension
+ script has been added. This script is invoked after Shorewall has
+ stopped.
+ - A DETECT_DNAT_ADDRS option has been added to /etc/shoreall/shorewall.conf. When this
+ option is selected, DNAT rules only apply when the destination address is
+ the external interface's primary IP address.
+ - The QuickStart Guide has
+ been broken into three guides and has been almost entirely rewritten.
+ - The Samples have been updated to reflect the new capabilities in this
+ release.
+
+
+7/8/2002 - Shorewall 1.3.3 Debian Package Available
+
+Lorenzo Marignoni reports that the packages are available at http://security.dsi.unimi.it/~lorenzo/debian.html.
+
+7/6/2002 - Shorewall 1.3.3 Released
+
+In this version:
+
+ - Entries in /etc/shorewall/interface that use the wildcard character
+ ("+") now have the "multi" option assumed.
+ - The 'rfc1918' chain in the mangle table has been renamed 'man1918' to
+ make log messages generated from that chain distinguishable from those
+ generated by the 'rfc1918' chain in the filter table.
+ - Interface names appearing in the hosts file are now validated against
+ the interfaces file.
+ - The TARGET column in the rfc1918 file is now checked for
+ correctness.
+ - The chain structure in the nat table has been changed to reduce the
+ number of rules that a packet must traverse and to correct problems with
+ NAT_BEFORE_RULES=No
+ - The "hits" command has been enhanced.
+
+
+6/25/2002 - Samples Updated for 1.3.2
+
+The comments in the sample configuration files have been updated to
+reflect new features introduced in Shorewall 1.3.2.
+
+6/25/2002 - Shorewall 1.3.1 Debian Package Available
+
+Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.
+
+6/19/2002 - Documentation Available in PDF Format
+
+Thanks to Mike Martinez, the Shorewall Documentation is now available for
+download in Adobe PDF format.
+
+6/16/2002 - Shorewall 1.3.2 Released
+
+In this version:
+
+
+6/6/2002 - Why CVS Web access is Password Protected
+
+Last weekend, I installed the CVS Web package to provide brower-based
+access to the Shorewall CVS repository. Since then, I have had several
+instances where my server was almost unusable due to the high load generated
+by website copying tools like HTTrack and WebStripper. These mindless
+tools:
+
+ - Ignore robot.txt files.
+ - Recursively copy everything that they find.
+ - Should be classified as weapons rather than tools.
+
+
+These tools/weapons are particularly damaging when combined with CVS Web
+because they doggedly follow every link in the cgi-generated HTML resulting
+in 1000s of executions of the cvsweb.cgi script. Yesterday, I spend several
+hours implementing measures to block these tools but unfortunately, these
+measures resulted in my server OOM-ing under even moderate load.
+
+Until I have the time to understand the cause of the OOM (or until I buy
+more RAM if that is what is required), CVS Web access will remain Password
+Protected.
+
+6/5/2002 - Shorewall 1.3.1 Debian Package Available
+
+Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.
+
+6/2/2002 - Samples Corrected
+
+The 1.3.0 samples configurations had several serious problems that
+prevented DNS and SSH from working properly. These problems have been
+corrected in the 1.3.1 samples.
+
+6/1/2002 - Shorewall 1.3.1 Released
+
+Hot on the heels of 1.3.0, this release:
+
+ - Corrects a serious problem with "all <zone> CONTINUE"
+ policies. This problem is present in all versions of Shorewall that
+ support the CONTINUE policy. These previous versions optimized away the
+ "all2<zone>" chain and replaced it with the "all2all" chain
+ with the usual result that a policy of REJECT was enforced rather than
+ the intended CONTINUE policy.
+ - Adds an /etc/shorewall/rfc1918
+ file for defining the exact behavior of the 'norfc1918' interface option.
+
+
+5/29/2002 - Shorewall 1.3.0 Released
+
+In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0
+includes:
+
+ - A 'filterping' interface option that allows ICMP echo-request (ping)
+ requests addressed to the firewall to be handled by entries in
+ /etc/shorewall/rules and /etc/shorewall/policy.
+
+
+5/23/2002 - Shorewall 1.3 RC1 Available
+
+In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92)
+incorporates the following:
+
+ - Support for the /etc/shorewall/whitelist file has been withdrawn. If
+ you need whitelisting, see these instructions.
+
+
+5/19/2002 - Shorewall 1.3 Beta 2 Available
+
+In addition to the changes in Beta 1, this release which carries the
+designation 1.2.91 adds:
+
+ - The structure of the firewall is changed markedly. There is now an
+ INPUT and a FORWARD chain for each interface; this reduces the number of
+ rules that a packet must traverse, especially in complicated setups.
+ - Sub-zones may now be excluded from
+ DNAT and REDIRECT rules.
+ - The names of the columns in a number of the configuration files have
+ been changed to be more consistent and self-explanatory and the
+ documentation has been updated accordingly.
+ - The sample configurations have been updated for 1.3.
+
+
+5/17/2002 - Shorewall 1.3 Beta 1 Available
+
+Beta 1 carries the version designation 1.2.90 and implements the following
+features:
+
+ - Simplified rule syntax which makes the intent of each rule clearer and
+ hopefully makes Shorewall easier to learn.
+ - Upward compatibility with 1.2 configuration files has been maintained
+ so that current users can migrate to the new syntax at their
+ convenience.
+ - WARNING: Compatibility with the old
+ parameterized sample configurations has NOT been maintained. Users still
+ running those configurations should migrate to the new sample
+ configurations before upgrading to 1.3 Beta 1.
+
+
+5/4/2002 - Shorewall 1.2.13 is Available
+
+In this version:
+
+
+4/30/2002 - Shorewall Debian News
+
+Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the Debian Testing
+Branch and the Debian Unstable
+Branch.
+
+4/20/2002 - Shorewall 1.2.12 is Available
+
+ - The 'try' command works again
+ - There is now a single RPM that also works with SUSE.
+
+
+4/17/2002 - Shorewall Debian News
+
+Lorenzo Marignoni reports that:
+
+
+Thanks, Lorenzo!
+
+4/16/2002 - Shorewall 1.2.11 RPM Available for SUSE
+
+Thanks to Stefan Mohr, there
+is now a Shorewall 1.2.11 SUSE
+RPM available.
+
+4/13/2002 - Shorewall 1.2.11 Available
+
+In this version:
+
+ - The 'try' command now accepts an optional timeout. If the timeout is
+ given in the command, the standard configuration will automatically be
+ restarted after the new configuration has been running for that length of
+ time. This prevents a remote admin from being locked out of the firewall
+ in the case where the new configuration starts but prevents access.
+ - Kernel route filtering may now be enabled globally using the new
+ ROUTE_FILTER parameter in /etc/shorewall/shorewall.conf.
+ - Individual IP source addresses and/or subnets may now be excluded from
+ masquerading/SNAT.
+ - Simple "Yes/No" and "On/Off" values are now case-insensitive in
+ /etc/shorewall/shorewall.conf.
+
+
+4/13/2002 - Hamburg Mirror now has FTP
+
+Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.
+Thanks Stefan!
+
+4/12/2002 - New Mirror in Hamburg
+
+Thanks to Stefan Mohr, there
+is now a mirror of the Shorewall website at http://germany.shorewall.net.
+
+4/10/2002 - Shorewall QuickStart Guide Version 1.1 Available
+
+Version 1.1 of the QuickStart
+Guide is now available. Thanks to those who have read version 1.0 and
+offered their suggestions. Corrections have also been made to the sample
+scripts.
+
+4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available
+
+Version 1.0 of the QuickStart
+Guide is now available. This Guide and its accompanying sample
+configurations are expected to provide a replacement for the recently
+withdrawn parameterized samples.
+
+4/8/2002 - Parameterized Samples Withdrawn
+
+Although the parameterized
+samples have allowed people to get a firewall up and running quickly,
+they have unfortunately set the wrong level of expectation among those who
+have used them. I am therefore withdrawing support for the samples and I am
+recommending that they not be used in new Shorewall installations.
+
+4/2/2002 - Updated Log Parser
+
+John Lodge has provided an
+updated version of his CGI-based log
+parser with corrected date handling.
+
+3/30/2002 - Shorewall Website Search Improvements
+
+The quick search on the home page now excludes the mailing list archives.
+The Extended Search allows excluding the
+archives or restricting the search to just the archives. An archive search
+form is also available on the mailing list information
+page.
+
+3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni)
+
+
+3/25/2002 - Log Parser Available
+
+John Lodge has provided a CGI-based log parser for Shorewall. Thanks
+John.
+
+3/20/2002 - Shorewall 1.2.10 Released
+
+In this version:
+
+ - A "shorewall try" command has been added (syntax: shorewall try
+ <configuration directory>). This command attempts "shorewall
+ -c <configuration directory> start" and if that results in
+ the firewall being stopped due to an error, a "shorewall start" command
+ is executed. The 'try' command allows you to create a new configuration and attempt to start
+ it; if there is an error that leaves your firewall in the stopped state,
+ it will automatically be restarted using the default configuration (in
+ /etc/shorewall).
+ - A new variable ADD_SNAT_ALIASES has been added to /etc/shorewall/shorewall.conf. If this
+ variable is set to "Yes", Shorewall will automatically add IP addresses
+ listed in the third column of the /etc/shorewall/masq file.
+ - Copyright notices have been added to the documenation.
+
+
+3/11/2002 - Shorewall 1.2.9 Released
+
+In this version:
+
- See the README file for upgrade instructions.
+3/1/2002 - 1.2.8 Debian Package is Available
- 1/1/2002 - Shorewall Mailing
- List Moving
+See http://security.dsi.unimi.it/~lorenzo/debian.html
- The Shorewall mailing list hosted at Sourceforge is moving to
- Shorewall.net. If you are a current subscriber to the list at
- Sourceforge, please see these
- instructions. If you would like to subscribe to the new
- list, visit http://www.shorewall.net/mailman/listinfo/shorewall-users.
+2/25/2002 - New Two-interface Sample
- 12/31/2001 - Shorewall 1.2.1 Released
+I've enhanced the two interface sample to allow access from the firewall
+to servers in the local zone - http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz
- In version 1.2.1:
+2/23/2002 - Shorewall 1.2.8 Released
+Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects
+problems associated with the lock file used to prevent multiple
+state-changing operations from occuring simultaneously. My apologies for any
+inconvenience my carelessness may have caused.
+
+2/22/2002 - Shorewall 1.2.7 Released
+
+In this version:
+
+ - UPnP probes (UDP destination port 1900) are now silently dropped in the
+ common chain
+ - RFC 1918 checking in the mangle table has been streamlined to no longer
+ require packet marking. RFC 1918 checking in the filter table has been
+ changed to require half as many rules as previously.
+ - A 'shorewall check' command has been added that does a cursory
+ validation of the zones, interfaces, hosts, rules and policy files.
+
+
+2/18/2002 - 1.2.6 Debian Package is Available
+
+See http://security.dsi.unimi.it/~lorenzo/debian.html
+
+2/8/2002 - Shorewall 1.2.6 Released
+
+In this version:
+
+ - $-variables may now be used anywhere in the configuration files except
+ /etc/shorewall/zones.
+ - The interfaces and hosts files now have their contents validated before
+ any changes are made to the existing Netfilter configuration. The
+ appearance of a zone name that isn't defined in /etc/shorewall/zones
+ causes "shorewall start" and "shorewall restart" to abort without
+ changing the Shorewall state. Unknown options in either file cause a
+ warning to be issued.
+ - A problem occurring when BLACKLIST_LOGLEVEL was not set has been
+ corrected.
+
+
+2/4/2002 - Shorewall 1.2.5 Debian Package Available
+
+see http://security.dsi.unimi.it/~lorenzo/debian.html
+
+2/1/2002 - Shorewall 1.2.5 Released
+
+Due to installation problems with Shorewall 1.2.4, I have released
+Shorewall 1.2.5. Sorry for the rapid-fire development.
+
+In version 1.2.5:
+
+ - The installation problems have been corrected.
+ - SNAT is now supported.
+ - A "shorewall version" command has been added
+ - The default value of the STATEDIR variable in
+ /etc/shorewall/shorewall.conf has been changed to /var/lib/shorewall in
+ order to conform to the GNU/Linux File Hierarchy Standard, Version
+ 2.2.
+
+
+1/28/2002 - Shorewall 1.2.4 Released
+
+ - The "fw" zone may now be given a
+ different name.
+ - You may now place end-of-line comments (preceded by '#') in any of the
+ configuration files
+ - There is now protection against against two state changing operations
+ occuring concurrently. This is implemented using the 'lockfile' utility
+ if it is available (lockfile is part of procmail); otherwise, a less
+ robust technique is used. The lockfile is created in the STATEDIR defined
+ in /etc/shorewall/shorewall.conf and has the name "lock".
+ - "shorewall start" no longer fails if "detect" is specified in /etc/shorewall/interfaces for an
+ interface with subnet mask 255.255.255.255.
+
+
+1/27/2002 - Shorewall 1.2.3 Debian Package Available -- see http://security.dsi.unimi.it/~lorenzo/debian.html
+
+1/20/2002 - Corrected firewall script available
+
+Corrects a problem with BLACKLIST_LOGLEVEL. See the
+errata for details.
+
+1/19/2002 - Shorewall 1.2.3 Released
+
+This is a minor feature and bugfix release. The single new feature is:
+
+ - Support for TCP MSS Clamp to PMTU -- This support is usually required
+ when the internet connection is via PPPoE or PPTP and may be enabled
+ using the CLAMPMSS option in
+ /etc/shorewall/shorewall.conf.
+
+
+The following problems were corrected:
+
+ - The "shorewall status" command no longer hangs.
+ - The "shorewall monitor" command now displays the icmpdef chain
+ - The CLIENT PORT(S) column in tcrules is no longer ignored
+
+
+1/18/2002 - Shorewall 1.2.2 packaged with new LEAF release
+
+Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF
+distribution that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo
+for details.
+
+1/11/2002 - Debian Package (.deb) Now Available - Thanks to Lorenzo Martignoni, a 1.2.2
+Shorewall Debian package is now available. There is a link to Lorenzo's site
+from the Shorewall download page.
+
+1/9/2002 - Updated 1.2.2 /sbin/shorewall available - This corrected version
+restores the "shorewall status" command to health.
+
+1/8/2002 - Shorewall 1.2.2 Released
+
+In version 1.2.2
+
+ - Support for IP blacklisting has been added
- - Logging of
- Mangled/Invalid Packets is added.
-
- - The tunnel script has been
- corrected.
-
- - 'shorewall show tc' now correctly handles tunnels.
+ - You specify whether you want packets from blacklisted hosts dropped
+ or rejected using the BLACKLIST_DISPOSITION
+ setting in /etc/shorewall/shorewall.conf
+ - You specify whether you want packets from blacklisted hosts logged
+ and at what syslog level using the BLACKLIST_LOGLEVEL setting in
+ /etc/shorewall/shorewall.conf
+ - You list the IP addresses/subnets that you wish to blacklist in /etc/shorewall/blacklist
+ - You specify the interfaces you want checked against the blacklist
+ using the new "blacklist"
+ option in /etc/shorewall/interfaces.
+ - The black list is refreshed from /etc/shorewall/blacklist by the
+ "shorewall refresh" command.
-
- 12/21/2001 - Shorewall 1.2.0 Released! - I
- couldn't resist releasing 1.2 on 12/21/2001
-
- Version 1.2 contains the following new features:
-
+
+ - Use of TCP RST replies has been expanded
-
-
For the next month or so, I will continue to provide
- corrections to version 1.1.18 as necessary so that current
- version 1.1.x users will not be forced into a quick upgrade to
- 1.2.0 just to have access to bug fixes.
-
- For those of you who have installed one of the Beta RPMS,
- you will need to use the "--oldpackage" option when upgrading
- to 1.2.0:
-
-
- rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm
-
-
- 12/19/2001 - Thanks to Steve Cowles, there is now
- a Shorewall mirror in Texas. This web site is mirrored at
- http://www.infohiiway.com/shorewall and the ftp site
- is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall.
-
-
- 11/30/2001 - A new set of the parameterized Sample
- Configurations has been released. In this version:
-
-
- - Ping is now allowed between the zones.
-
- - In the three-interface configuration, it is now possible
- to configure the internet services that are to be available
- to servers in the DMZ.
-
-
- 11/20/2001 - The current version of Shorewall is
- 1.1.18.
-
- In this version:
-
-
- - The spelling of ADD_IP_ALIASES has been corrected in the
- shorewall.conf file
-
- - The logic for deleting user-defined chains has been
- simplified so that it avoids a bug in the LRP version of the
- 'cut' utility.
-
- - The /var/lib/lrpkg/shorwall.conf file has been corrected
- to properly display the NAT entry in that file.
-
-
- 11/19/2001 - Thanks to Juraj Ontkanin, there is now
- a Shorewall mirror in the Slovak Republic. The website is
- now mirrored at http://www.nrg.sk/mirror/shorewall and the
- FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.
-
- 11/2/2001 - Announcing Shorewall Parameter-driven Sample
- Configurations. There are three sample configurations:
-
-
- - One Interface -- for a standalone system.
-
- - Two Interfaces -- A masquerading firewall.
-
- - Three Interfaces -- A masquerading firewall with
- DMZ.
-
-
- Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17
- . See the README file for instructions.
-
- 11/1/2001 - The current version of Shorewall is
- 1.1.17. I intend this to be the last of the 1.1
- Shorewall releases.
-
- In this version:
-
-
-
- 10/22/2001 - The current version of Shorewall is
- 1.1.16. In this version:
-
-
- - A new "shorewall show connections" command has been
- added.
-
- - In the "shorewall monitor" output, the currently tracked
- connections are now shown on a separate page.
-
- - Prior to this release, Shorewall unconditionally added
- the external IP adddress(es) specified in /etc/shorewall/nat.
- Beginning with version 1.1.16, a new parameter (ADD_IP_ALIASES) may be set to
- "no" (or "No") to inhibit this behavior. This allows IP
- aliases created using your distribution's network
- configuration tools to be used in static NAT.
-
-
- 10/15/2001 - The current version of Shorewall is
- 1.1.15. In this version:
-
-
- - Support for nested zones has been improved. See the documentation for
- details
-
- - Shorewall now correctly checks the alternate
- configuration directory for the 'zones' file.
-
-
- 10/4/2001 - The current version of Shorewall is
- 1.1.14. In this version
-
-
- - Shorewall now supports alternate configuration
- directories. When an alternate directory is specified when
- starting or restarting Shorewall (e.g., "shorewall -c
- /etc/testconf restart"), Shorewall will first look for
- configuration files in the alternate directory then in
- /etc/shorewall. To create an alternate configuration
- simply:
- 1. Create a New Directory
- 2. Copy to that directory any of your configuration files
- that you want to change.
- 3. Modify the copied files as needed.
- 4. Restart Shorewall specifying the new directory.
-
- - The rules for allowing/disallowing icmp echo-requests
- (pings) are now moved after rules created when processing the
- rules file. This allows you to add rules that selectively
- allow/deny ping based on source or destination address.
-
- - Rules that specify multiple client ip addresses or
- subnets no longer cause startup failures.
-
- - Zone names in the policy file are now validated against
- the zones file.
-
- - If you have packet mangling support
- enabled, the "norfc1918" interface
- option now logs and drops any incoming packets on the
- interface that have an RFC 1918 destination address.
-
-
- 9/12/2001 - The current version of Shorewall is
- 1.1.13. In this version
-
-
- - Shell variables can now be used to parameterize Shorewall
- rules.
-
- - The second column in the hosts file may now contain a
- comma-separated list.
-
- Example:
- sea
- eth0:130.252.100.0/24,206.191.149.0/24
-
- - Handling of multi-zone interfaces has been improved. See
- the documentation for
- the /etc/shorewall/interfaces file.
-
-
- 8/28/2001 - The current version of Shorewall is
- 1.1.12. In this version
-
-
- - Several columns in the rules file may now contain
- comma-separated lists.
-
- - Shorewall is now more rigorous in parsing the options in
- /etc/shorewall/interfaces.
-
- - Complementation using "!" is now supported in rules.
-
-
- 7/28/2001 - The current version of Shorewall is
- 1.1.11. In this version
-
-
- - A "shorewall refresh" command has been added to allow for
- refreshing the rules associated with the broadcast address on
- a dynamic interface. This command should be used in place of
- "shorewall restart" when the internet interface's IP address
- changes.
-
- - The /etc/shorewall/start file (if any) is now processed
- after all temporary rules have been deleted. This change
- prevents the accidental removal of rules added during the
- processing of that file.
-
- - The "dhcp" interface option is now applicable to firewall
- interfaces used by a DHCP server running on the
- firewall.
-
- - The RPM can now be built from the .tgz file using "rpm
- -tb"
-
-
- 7/6/2001 - The current version of Shorewall is
- 1.1.10. In this version
-
-
- - Shorewall now enables Ipv4 Packet Forwarding by default.
- Packet forwarding may be disabled by specifying
- IP_FORWARD=Off in /etc/shorewall/shorewall.conf. If you don't
- want Shorewall to enable or disable packet forwarding, add
- IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf
- file.
-
- - The "shorewall hits" command no longer lists extraneous
- service names in its last report.
-
- - Erroneous instructions in the comments at the head of the
- firewall script have been corrected.
-
-
- 6/23/2001 - The current version of Shorewall is
- 1.1.9. In this version
-
-
- - The "tunnels" file really is in the RPM now.
-
- - SNAT can now be applied to port-forwarded
- connections.
-
- - A bug which would cause firewall start failures in some
- dhcp configurations has been fixed.
-
- - The firewall script now issues a message if you have the
- name of an interface in the second column in an entry in
- /etc/shorewall/masq and that interface is not up.
-
- - You can now configure Shorewall so that it doesn't require the NAT and/or
- mangle netfilter modules.
-
- - Thanks to Alex Polishchuk, the "hits" command from
- seawall is now in shorewall.
-
- - Support for IPIP tunnels has been
- added.
-
-
- 6/18/2001 - The current version of Shorewall is
- 1.1.8. In this version
-
-
-
- 6/2/2001 - The current version of Shorewall is 1.1.7.
- In this version
-
-
- - The TOS rules are now deleted when the firewall is
- stopped.
-
- - The .rpm will now install regardless of which version of
- iptables is installed.
-
- - The .rpm will now install without iproute2 being
- installed.
-
- - The documentation has been cleaned up.
-
- - The sample configuration files included in Shorewall have
- been formatted to 80 columns for ease of editing on a VGA
- console.
-
-
- 5/25/2001 - The current version of Shorewall is
- 1.1.6. In this version
-
-
- - You may now
- rate-limit the packet log.
-
- - Previous versions of Shorewall have an implementation of
- Static NAT which violates the principle of least
- surprise. NAT only occurs for packets arriving at
- (DNAT) or send from (SNAT) the interface named in the
- INTERFACE column of /etc/shorewall/nat. Beginning with
- version 1.1.6, NAT effective regardless of which interface
- packets come from or are destined to. To get compatibility
- with prior versions, I have added a new "ALL "ALL INTERFACES" column to
- /etc/shorewall/nat. By placing "no" or "No" in the new
- column, the NAT behavior of prior versions may be
- retained.
-
- - The treatment of IPSEC
- Tunnels where the remote gateway is a standalone system has
- been improved. Previously, it was necessary to include an
- additional rule allowing UDP port 500 traffic to pass through
- the tunnel. Shorewall will now create this rule automatically
- when you place the name of the remote peer's zone in a new
- GATEWAY ZONE column in /etc/shorewall/tunnels.
-
-
- 5/20/2001 - The current version of Shorewall is
- 1.1.5. In this version
-
-
-
- 5/10/2001 - The current version of Shorewall is
- 1.1.4. In this version
-
-
- - Accepting RELATED
- connections is now optional.
-
- - Corrected problem where if "shorewall start" aborted
- early (due to kernel configuration errors for example),
- superfluous 'sed' error messages were reported.
-
- - Corrected rules generated for port redirection.
-
- - The order in which iptables kernel modules are loaded has
- been corrected (Thanks to Mark Pavlidis).
-
-
- 4/28/2001 - The current version of Shorewall is
- 1.1.3. In this version
-
-
- - Correct message issued when Proxy ARP address added
- (Thanks to Jason Kirtland).
-
- - /tmp/shorewallpolicy-$$ is now removed if there is an
- error while starting the firewall.
-
- - /etc/shorewall/icmp.def and /etc/shorewall/common.def are
- now used to define the icmpdef and common chains unless
- overridden by the presence of /etc/shorewall/icmpdef or
- /etc/shorewall/common.
-
- - In the .lrp, the file /var/lib/lrpkg/shorwall.conf has
- been corrected. An extra space after "/etc/shorwall/policy"
- has been removed and "/etc/shorwall/rules" has been
- added.
-
- - When a sub-shell encounters a fatal error and has stopped
- the firewall, it now kills the main shell so that the main
- shell will not continue.
-
- - A problem has been corrected where a sub-shell stopped
- the firewall and main shell continued resulting in a
- perplexing error message referring to "common.so"
- resulted.
-
- - Previously, placing "-" in the PORT(S) column in
- /etc/shorewall/rules resulted in an error message during
- start. This has been corrected.
-
- - The first line of "install.sh" has been corrected -- I
- had inadvertently deleted the initial "#".
-
-
- 4/12/2001 - The current version of Shorewall is
- 1.1.2. In this version
-
-
- - Port redirection now works again.
-
- - The icmpdef and common chains may now be user-defined.
-
- - The firewall no longer fails to start if "routefilter" is
- specified for an interface that isn't started. A warning
- message is now issued in this case.
-
- - The LRP Version is renamed "shorwall" for 8,3 MSDOS file
- system compatibility.
-
- - A couple of LRP-specific problems were corrected.
-
-
- 4/8/2001 - Shorewall is now affiliated with the Leaf Project 
-
- 4/5/2001 - The current version of Shorewall is 1.1.1. In
- this version:
-
-
- - The common chain is traversed from INPUT, OUTPUT and
- FORWARD before logging occurs
-
- - The source has been cleaned up dramatically
-
- - DHCP DISCOVER packets with RFC1918 source addresses no
- longer generate log messages. Linux DHCP clients generate
- such packets and it's annoying to see them logged.
-
-
- 3/25/2001 - The current version of Shorewall is 1.1.0. In
- this version:
-
-
- - Log messages now indicate the packet disposition.
-
- - Error messages have been improved.
-
- - The ability to define zones consisting of an enumerated
- set of hosts and/or subnetworks has been added.
-
- - The zone-to-zone chain matrix is now sparse so that only
- those chains that contain meaningful rules are defined.
-
- - 240.0.0.0/4 and 169.254.0.0/16 have been added to the
- source subnetworks whose packets are dropped under the
- norfc1918 interface option.
-
- - Exits are now provided for executing an user-defined
- script when a chain is defined, when the firewall is
- initialized, when the firewall is started, when the firewall
- is stopped and when the firewall is cleared.
-
- - The Linux kernel's route filtering facility can now be
- specified selectively on network interfaces.
-
-
- 3/19/2001 - The current version of Shorewall is 1.0.4.
- This version:
-
-
- - Allows user-defined zones. Shorewall now has only one
- pre-defined zone (fw) with the remaining zones being defined
- in the new configuration file /etc/shorewall/zones. The
- /etc/shorewall/zones file released in this version provides
- behavior that is compatible with Shorewall 1.0.3.
-
- - Adds the ability to specify logging in entries in the
- /etc/shorewall/rules file.
-
- - Correct handling of the icmp-def chain so that only ICMP
- packets are sent through the chain.
-
- - Compresses the output of "shorewall monitor" if awk is
- installed. Allows the command to work if awk isn't installed
- (although it's not pretty).
-
-
- 3/13/2001 - The current version of Shorewall is 1.0.3.
- This is a bug-fix release with no new features.
-
-
- - The PATH variable in the firewall script now includes
- /usr/local/bin and /usr/local/sbin.
-
- - DMZ-related chains are now correctly deleted if the DMZ
- is deleted.
-
- - The interface OPTIONS for "gw" interfaces are no longer
- ignored.
-
-
- 3/8/2001 - The current version of Shorewall is 1.0.2. It
- supports an additional "gw" (gateway) zone for tunnels and it
- supports IPSEC tunnels with end-points on the firewall. There
- is also a .lrp available now.
-
+
+ - A LOGFILE specification has
+ been added to /etc/shorewall/shorewall.conf. LOGFILE is used to tell the
+ /sbin/shorewall program where to look for Shorewall messages.
+
+
+1/5/2002 - New Parameterized Samples (version 1.2.0) released. These are minor updates to
+the previously-released samples. There are two new rules added:
+
+ - Unless you have explicitly enabled Auth connections (tcp port 113) to
+ your firewall, these connections will be REJECTED rather than DROPPED.
+ This speeds up connection establishment to some servers.
+ - Orphan DNS replies are now silently dropped.
+
+
+See the README file for upgrade instructions.
+
+1/1/2002 - Shorewall Mailing List
+Moving
+
+The Shorewall mailing list hosted at Sourceforge is moving to Shorewall.net. If
+you are a current subscriber to the list at Sourceforge, please see these instructions. If
+you would like to subscribe to the new list, visit http://www.shorewall.net/mailman/listinfo/shorewall-users.
+
+12/31/2001 - Shorewall 1.2.1 Released
+
+In version 1.2.1:
+
+
+12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist
+releasing 1.2 on 12/21/2001
+
+Version 1.2 contains the following new features:
+
+
+For the next month or so, I will continue to provide corrections to
+version 1.1.18 as necessary so that current version 1.1.x users will not be
+forced into a quick upgrade to 1.2.0 just to have access to bug fixes.
+
+For those of you who have installed one of the Beta RPMS, you will need to
+use the "--oldpackage" option when upgrading to 1.2.0:
+
+
+ rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm
+
+
+12/19/2001 - Thanks to Steve
+Cowles, there is now a Shorewall mirror in Texas. This web site is
+mirrored at http://www.infohiiway.com/shorewall and the ftp site is at
+ftp://ftp.infohiiway.com/pub/mirrors/shorewall.
+
+
+11/30/2001 - A new set of the parameterized Sample
+Configurations has been released. In this version:
+
+ - Ping is now allowed between the zones.
+ - In the three-interface configuration, it is now possible to configure
+ the internet services that are to be available to servers in the
+ DMZ.
+
+
+11/20/2001 - The current version of Shorewall is 1.1.18.
+
+In this version:
+
+ - The spelling of ADD_IP_ALIASES has been corrected in the shorewall.conf
+ file
+ - The logic for deleting user-defined chains has been simplified so that
+ it avoids a bug in the LRP version of the 'cut' utility.
+ - The /var/lib/lrpkg/shorwall.conf file has been corrected to properly
+ display the NAT entry in that file.
+
+
+11/19/2001 - Thanks to Juraj
+Ontkanin, there is now a Shorewall mirror in the Slovak Republic. The
+website is now mirrored at http://www.nrg.sk/mirror/shorewall and the FTP site is
+mirrored at ftp://ftp.nrg.sk/mirror/shorewall.
+
+11/2/2001 - Announcing Shorewall Parameter-driven Sample
+Configurations. There are three sample configurations:
+
+ - One Interface -- for a standalone system.
+ - Two Interfaces -- A masquerading firewall.
+ - Three Interfaces -- A masquerading firewall with DMZ.
+
+
+Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17
+. See the README file for instructions.
+
+11/1/2001 - The current version of Shorewall is 1.1.17. I
+intend this to be the last of the 1.1 Shorewall releases.
+
+In this version:
+
+
+10/22/2001 - The current version of Shorewall is 1.1.16. In this
+version:
+
+ - A new "shorewall show connections" command has been added.
+ - In the "shorewall monitor" output, the currently tracked connections
+ are now shown on a separate page.
+ - Prior to this release, Shorewall unconditionally added the external IP
+ adddress(es) specified in /etc/shorewall/nat. Beginning with version
+ 1.1.16, a new parameter (ADD_IP_ALIASES) may be set to "no"
+ (or "No") to inhibit this behavior. This allows IP aliases created using
+ your distribution's network configuration tools to be used in static
+ NAT.
+
+
+10/15/2001 - The current version of Shorewall is 1.1.15. In this
+version:
+
+ - Support for nested zones has been improved. See the documentation for details
+ - Shorewall now correctly checks the alternate configuration directory
+ for the 'zones' file.
+
+
+10/4/2001 - The current version of Shorewall is 1.1.14. In this
+version
+
+ - Shorewall now supports alternate configuration directories. When an
+ alternate directory is specified when starting or restarting Shorewall
+ (e.g., "shorewall -c /etc/testconf restart"), Shorewall will first look
+ for configuration files in the alternate directory then in
+ /etc/shorewall. To create an alternate configuration simply:
+ 1. Create a New Directory
+ 2. Copy to that directory any of your configuration files that you want
+ to change.
+ 3. Modify the copied files as needed.
+ 4. Restart Shorewall specifying the new directory.
+ - The rules for allowing/disallowing icmp echo-requests (pings) are now
+ moved after rules created when processing the rules file. This allows you
+ to add rules that selectively allow/deny ping based on source or
+ destination address.
+ - Rules that specify multiple client ip addresses or subnets no longer
+ cause startup failures.
+ - Zone names in the policy file are now validated against the zones
+ file.
+ - If you have packet
+ mangling support enabled, the "norfc1918" interface option now
+ logs and drops any incoming packets on the interface that have an RFC
+ 1918 destination address.
+
+
+9/12/2001 - The current version of Shorewall is 1.1.13. In this
+version
+
+ - Shell variables can now be used to parameterize Shorewall rules.
+ - The second column in the hosts file may now contain a comma-separated
+ list.
+
+ Example:
+ sea
+ eth0:130.252.100.0/24,206.191.149.0/24
+ - Handling of multi-zone interfaces has been improved. See the documentation for the
+ /etc/shorewall/interfaces file.
+
+
+8/28/2001 - The current version of Shorewall is 1.1.12. In this
+version
+
+ - Several columns in the rules file may now contain comma-separated
+ lists.
+ - Shorewall is now more rigorous in parsing the options in
+ /etc/shorewall/interfaces.
+ - Complementation using "!" is now supported in rules.
+
+
+7/28/2001 - The current version of Shorewall is 1.1.11. In this
+version
+
+ - A "shorewall refresh" command has been added to allow for refreshing
+ the rules associated with the broadcast address on a dynamic interface.
+ This command should be used in place of "shorewall restart" when the
+ internet interface's IP address changes.
+ - The /etc/shorewall/start file (if any) is now processed after all
+ temporary rules have been deleted. This change prevents the accidental
+ removal of rules added during the processing of that file.
+ - The "dhcp" interface option is now applicable to firewall interfaces
+ used by a DHCP server running on the firewall.
+ - The RPM can now be built from the .tgz file using "rpm -tb"
+
+
+7/6/2001 - The current version of Shorewall is 1.1.10. In this
+version
+
+ - Shorewall now enables Ipv4 Packet Forwarding by default. Packet
+ forwarding may be disabled by specifying IP_FORWARD=Off in
+ /etc/shorewall/shorewall.conf. If you don't want Shorewall to enable or
+ disable packet forwarding, add IP_FORWARDING=Keep to your
+ /etc/shorewall/shorewall.conf file.
+ - The "shorewall hits" command no longer lists extraneous service names
+ in its last report.
+ - Erroneous instructions in the comments at the head of the firewall
+ script have been corrected.
+
+
+6/23/2001 - The current version of Shorewall is 1.1.9. In this
+version
+
+ - The "tunnels" file really is in the RPM now.
+ - SNAT can now be applied to port-forwarded connections.
+ - A bug which would cause firewall start failures in some dhcp
+ configurations has been fixed.
+ - The firewall script now issues a message if you have the name of an
+ interface in the second column in an entry in /etc/shorewall/masq and
+ that interface is not up.
+ - You can now configure Shorewall so that it doesn't require the NAT and/or mangle
+ netfilter modules.
+ - Thanks to Alex Polishchuk, the "hits" command from seawall is now
+ in shorewall.
+ - Support for IPIP tunnels has been added.
+
+
+6/18/2001 - The current version of Shorewall is 1.1.8. In this
+version
+
+
+6/2/2001 - The current version of Shorewall is 1.1.7. In this
+version
+
+ - The TOS rules are now deleted when the firewall is stopped.
+ - The .rpm will now install regardless of which version of iptables is
+ installed.
+ - The .rpm will now install without iproute2 being installed.
+ - The documentation has been cleaned up.
+ - The sample configuration files included in Shorewall have been
+ formatted to 80 columns for ease of editing on a VGA console.
+
+
+5/25/2001 - The current version of Shorewall is 1.1.6. In this
+version
+
+ - You may now rate-limit the packet
+ log.
+ - Previous versions of Shorewall have an implementation of Static NAT
+ which violates the principle of least surprise. NAT only occurs for
+ packets arriving at (DNAT) or send from (SNAT) the interface named in the
+ INTERFACE column of /etc/shorewall/nat. Beginning with version 1.1.6, NAT
+ effective regardless of which interface packets come from or are destined
+ to. To get compatibility with prior versions, I have added a new "ALL "ALL INTERFACES" column to
+ /etc/shorewall/nat. By placing "no" or "No" in the new column, the
+ NAT behavior of prior versions may be retained.
+ - The treatment of IPSEC Tunnels where
+ the remote gateway is a standalone system has been improved.
+ Previously, it was necessary to include an additional rule allowing UDP
+ port 500 traffic to pass through the tunnel. Shorewall will now create
+ this rule automatically when you place the name of the remote peer's zone
+ in a new GATEWAY ZONE column in /etc/shorewall/tunnels.
+
+
+5/20/2001 - The current version of Shorewall is 1.1.5. In this
+version
+
+
+5/10/2001 - The current version of Shorewall is 1.1.4. In this
+version
+
+ - Accepting RELATED connections is now
+ optional.
+ - Corrected problem where if "shorewall start" aborted early (due to
+ kernel configuration errors for example), superfluous 'sed' error
+ messages were reported.
+ - Corrected rules generated for port redirection.
+ - The order in which iptables kernel modules are loaded has been
+ corrected (Thanks to Mark Pavlidis).
+
+
+4/28/2001 - The current version of Shorewall is 1.1.3. In this
+version
+
+ - Correct message issued when Proxy ARP address added (Thanks to Jason
+ Kirtland).
+ - /tmp/shorewallpolicy-$$ is now removed if there is an error while
+ starting the firewall.
+ - /etc/shorewall/icmp.def and /etc/shorewall/common.def are now used to
+ define the icmpdef and common chains unless overridden by the presence of
+ /etc/shorewall/icmpdef or /etc/shorewall/common.
+ - In the .lrp, the file /var/lib/lrpkg/shorwall.conf has been corrected.
+ An extra space after "/etc/shorwall/policy" has been removed and
+ "/etc/shorwall/rules" has been added.
+ - When a sub-shell encounters a fatal error and has stopped the firewall,
+ it now kills the main shell so that the main shell will not continue.
+ - A problem has been corrected where a sub-shell stopped the firewall and
+ main shell continued resulting in a perplexing error message referring to
+ "common.so" resulted.
+ - Previously, placing "-" in the PORT(S) column in /etc/shorewall/rules
+ resulted in an error message during start. This has been corrected.
+ - The first line of "install.sh" has been corrected -- I had
+ inadvertently deleted the initial "#".
+
+
+4/12/2001 - The current version of Shorewall is 1.1.2. In this
+version
+
+ - Port redirection now works again.
+ - The icmpdef and common chains may
+ now be user-defined.
+ - The firewall no longer fails to start if "routefilter" is specified for
+ an interface that isn't started. A warning message is now issued in this
+ case.
+ - The LRP Version is renamed "shorwall" for 8,3 MSDOS file system
+ compatibility.
+ - A couple of LRP-specific problems were corrected.
+
+
+4/8/2001 - Shorewall is now affiliated with the Leaf Project
+
+4/5/2001 - The current version of Shorewall is 1.1.1. In this
+version:
+
+ - The common chain is traversed from INPUT, OUTPUT and FORWARD before
+ logging occurs
+ - The source has been cleaned up dramatically
+ - DHCP DISCOVER packets with RFC1918 source addresses no longer generate
+ log messages. Linux DHCP clients generate such packets and it's annoying
+ to see them logged.
+
+
+3/25/2001 - The current version of Shorewall is 1.1.0. In this
+version:
+
+ - Log messages now indicate the packet disposition.
+ - Error messages have been improved.
+ - The ability to define zones consisting of an enumerated set of hosts
+ and/or subnetworks has been added.
+ - The zone-to-zone chain matrix is now sparse so that only those chains
+ that contain meaningful rules are defined.
+ - 240.0.0.0/4 and 169.254.0.0/16 have been added to the source
+ subnetworks whose packets are dropped under the norfc1918
+ interface option.
+ - Exits are now provided for executing an user-defined script when a
+ chain is defined, when the firewall is initialized, when the firewall is
+ started, when the firewall is stopped and when the firewall is
+ cleared.
+ - The Linux kernel's route filtering facility can now be specified
+ selectively on network interfaces.
+
+
+3/19/2001 - The current version of Shorewall is 1.0.4. This
+version:
+
+ - Allows user-defined zones. Shorewall now has only one pre-defined zone
+ (fw) with the remaining zones being defined in the new configuration file
+ /etc/shorewall/zones. The /etc/shorewall/zones file released in this
+ version provides behavior that is compatible with Shorewall
+ 1.0.3.
+ - Adds the ability to specify logging in entries in the
+ /etc/shorewall/rules file.
+ - Correct handling of the icmp-def chain so that only ICMP packets are
+ sent through the chain.
+ - Compresses the output of "shorewall monitor" if awk is installed.
+ Allows the command to work if awk isn't installed (although it's not
+ pretty).
+
+
+3/13/2001 - The current version of Shorewall is 1.0.3. This is a
+bug-fix release with no new features.
+
+ - The PATH variable in the firewall script now includes /usr/local/bin
+ and /usr/local/sbin.
+ - DMZ-related chains are now correctly deleted if the DMZ is deleted.
+ - The interface OPTIONS for "gw" interfaces are no longer ignored.
+
+
+3/8/2001 - The current version of Shorewall is 1.0.2. It supports an
+additional "gw" (gateway) zone for tunnels and it supports IPSEC tunnels with
+end-points on the firewall. There is also a .lrp available now.
+
-