forked from extern/shorewall_code
3fb876ef1b
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@6710 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
721 lines
29 KiB
XML
721 lines
29 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
<!-- $Id$ -->
|
|
<article id="upgrade_issues">
|
|
<articleinfo>
|
|
<title>Upgrade Issues</title>
|
|
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2002</year>
|
|
|
|
<year>2003</year>
|
|
|
|
<year>2004</year>
|
|
|
|
<year>2005</year>
|
|
|
|
<year>2006</year>
|
|
|
|
<year>2007</year>
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
|
|
<holder></holder>
|
|
</copyright>
|
|
|
|
<legalnotice>
|
|
<para>Permission is granted to copy, distribute and/or modify this
|
|
document under the terms of the GNU Free Documentation License, Version
|
|
1.2 or any later version published by the Free Software Foundation; with
|
|
no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
|
Texts. A copy of the license is included in the section entitled
|
|
<quote><ulink type="" url="copyright.htm">GNU Free Documentation
|
|
License</ulink></quote>.</para>
|
|
</legalnotice>
|
|
</articleinfo>
|
|
|
|
<section id="Important">
|
|
<title>Important</title>
|
|
|
|
<para>It is important that you read all of the sections on this page where
|
|
the version number mentioned in the section title is later than what you
|
|
are currently running.</para>
|
|
|
|
<para>In the descriptions that follows, the term
|
|
<emphasis>group</emphasis> refers to a particular network or subnetwork
|
|
(which may be <literal>0.0.0.0/0</literal> or it may be a host address)
|
|
accessed through a particular interface.</para>
|
|
|
|
<para>Examples:</para>
|
|
|
|
<simplelist columns="1" type="vert">
|
|
<member><literal>eth0:0.0.0.0/0</literal></member>
|
|
|
|
<member><literal>eth2:192.168.1.0/24</literal></member>
|
|
|
|
<member><literal>eth3:192.0.2.123</literal></member>
|
|
</simplelist>
|
|
|
|
<para>You can use the <command moreinfo="none">shorewall check</command>
|
|
command to see the groups associated with each of your zones.</para>
|
|
</section>
|
|
|
|
<section id="V4.0.0">
|
|
<title>Versions >= 4.0.0-Beta1</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>This is the first Shorewall release that fully integrates the
|
|
new Shorewall-perl compiler. You are now offered a choice as to which
|
|
compiler(s) you install. In Shorewall 4.0.0, there are the following
|
|
packages:<itemizedlist>
|
|
<listitem>
|
|
<para>Shorewall-common ( common files )</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Shorewall-shell ( the shell-based compiler )</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Shorewall-perl (the Perl-based compiler )</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Shorewall-lite</para>
|
|
</listitem>
|
|
</itemizedlist>You must install Shorewall-common and at least one of
|
|
the compiler packages (you may install them both).</para>
|
|
|
|
<para>You cannot simply upgrade your existing Shorewall package. You
|
|
must upgrade Shorewall-common <emphasis role="bold">and</emphasis>
|
|
install one or both of the compilers.</para>
|
|
|
|
<para>If you attempt to upgrade using the common RPM, you get this
|
|
result:<programlisting>gateway:~ # rpm -Uvh shorewall-common-4.0.0.noarch.rpm
|
|
error: Failed dependencies:
|
|
shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch
|
|
gateway:~ #</programlisting> You must either:<programlisting>rpm -U shorewall-common-4.0.0.noarch.rpm shorewall-shell-4.0.0.noarch.rpm</programlisting>or<programlisting>rpm -U shorewall-common-4.0.0.noarch.rpm shorewall-perl-4.0.0.noarch.rpm</programlisting>or<programlisting>rpm -U shorewall-common-4.0.0.noarch.rpm shorewall-shell-4.0.0.noarch.rpm shorewall-perl-4.0.0.noarch.rpm</programlisting>If
|
|
you are upgrading using the tarball, you must install either
|
|
shorewall-shell or shorewall-perl before you upgrade Shorewall using
|
|
the Shorewall-common tarball. Otherwise, the install.sh script fails
|
|
with:<simplelist>
|
|
<member>ERROR: No Shorewall compiler is installed</member>
|
|
</simplelist>The shorewall-shell and shorewall-perl packages are
|
|
installed from the tarball in the expected way; untar the package, and
|
|
run the install.sh script.</para>
|
|
|
|
<para>The RPMs are set up so that if you upgrade an existing Shorewall
|
|
installation as part of a distribution upgrade and you have not
|
|
already installed shorewall-perl, then you will end up with
|
|
Shorewall-common and Shorewall-shell installed. </para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The ROUTE_FILTER and LOG_MARTIANS options in shorewall.conf work
|
|
slightly differently in Shorewall 4.0.0. In prior releases, leaving
|
|
these options empty was equivalent to setting them to 'No' which
|
|
caused the corresponding flag in /proc to be reset for all interfaces.
|
|
Beginning in Shorewall 4.0.0, leaving these options empty causes
|
|
Shorewall to leave the flags in /proc as they are. You must set the
|
|
option to 'No' in order to obtain the old behavior.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="V3.4.0">
|
|
<title>Versions >= 3.4.0-Beta1</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Shorewall supports the notion of "default actions". A default
|
|
action defines a set of rules that are applied before a policy is
|
|
enforced. Default actions accomplish two goals:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>Relieve log congestion. Default actions typically include
|
|
rules to silently drop or reject traffic that would otherwise be
|
|
logged when the policy is enforced.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Insure correct operation. Default actions can also avoid
|
|
common pitfalls like dropping connection requests on TCP port 113.
|
|
If these connections are dropped (rather than rejected) then you
|
|
may encounter problems connecting to internet services that
|
|
utilize the AUTH protocol of client authentication.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>In prior Shorewall versions, default actions (action.Drop and
|
|
action.Reject) were defined for DROP and REJECT policies in
|
|
<filename>/usr/share/shorewall/actions.std</filename>. These could be
|
|
overridden in <filename>/etc/shorewall/actions</filename>.</para>
|
|
|
|
<para>This approach has two drawbacks:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>All DROP policies must use the same default action and all
|
|
REJECT policies must use the same default action.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Now that we have <ulink
|
|
url="Modularization.html">modularized action processing</ulink>,
|
|
we need a way to define default rules for a policy that does not
|
|
involve actions.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>If you have not overridden the defaults using entries in
|
|
<filename>/etc/shorewall/actions</filename> then you need make no
|
|
changes to migrate to Shorewall version 3.4. If you have overridden
|
|
either of these entries, then please read on.</para>
|
|
|
|
<para>The change in version 3.4 is two-fold:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Four new options have been added to the
|
|
<filename>/etc/shorewall/shorewall.conf</filename> file that allow
|
|
specifying the default action for DROP, REJECT, ACCEPT and
|
|
QUEUE.</para>
|
|
|
|
<para>The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT
|
|
and QUEUE_DEFAULT.</para>
|
|
|
|
<para>DROP_DEFAULT describes the rules to be applied before a
|
|
connection request is dropped by a DROP policy; REJECT_DEFAULT
|
|
describes the rules to be applied if a connection request is
|
|
rejected by a REJECT policy. The other two are similar for ACCEPT
|
|
and QUEUE policies. The value assigned to these may be:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The name of an action.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The name of a macro.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>'None' or 'none'</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>The default values are:</para>
|
|
|
|
<simplelist>
|
|
<member>DROP_DEFAULT="Drop"</member>
|
|
|
|
<member>REJECT_DEFAULT="Reject"</member>
|
|
|
|
<member>ACCEPT_DEFAULT=none</member>
|
|
|
|
<member>QUEUE_DEFAULT=none</member>
|
|
</simplelist>
|
|
|
|
<para>If USE_ACTIONS=Yes, then these values refer to action.Drop
|
|
and action.Reject respectively. If USE_ACTIONS=No, then these
|
|
values refer to macro.Drop and macro.Reject.</para>
|
|
|
|
<para>If you set the value of either option to "None" then no
|
|
default action will be used and the default action or macro (if
|
|
any) must be specified in
|
|
<filename>/etc/shorewall/policy</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The POLICY column in /etc/shorewall/policy has been
|
|
extended.</para>
|
|
|
|
<para>In <filename>/etc/shorewall/policy</filename>, when the
|
|
POLICY is DROP, REJECT, ACCEPT or QUEUE then the policy may be
|
|
followed by ":" and one of the following:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The word "None" or "none". This causes any default
|
|
action defined in
|
|
<filename>/etc/shorewall/shorewall.conf</filename> to be
|
|
omitted for this policy.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The name of an action (requires that USE_ACTIONS=Yes in
|
|
<filename>shorewall.conf</filename>). That action will be
|
|
invoked before the policy is enforced.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The name of a macro. The rules in that macro will be
|
|
applied before the policy is enforced. This does not require
|
|
USE_ACTIONS=Yes.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Example:</para>
|
|
|
|
<programlisting>#SOURCE DEST POLICY LOG
|
|
# LEVEL
|
|
loc net ACCEPT
|
|
net all DROP:MyDrop info
|
|
#
|
|
# THE FOLLOWING POLICY MUST BE LAST
|
|
#
|
|
all all REJECT:MyReject info</programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The 'Limit' action is now a builtin. If you have 'Limit' listed
|
|
in <filename>/etc/shorewall/actions</filename>, remove the entry. Also
|
|
remove the files <filename>/etc/shorewall/action.Limit</filename>
|
|
and/or <filename>/etc/shorewall/Limit</filename> if you have
|
|
them.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This issue only applies if you have entries in
|
|
<filename>/etc/shorewall/providers</filename>.</para>
|
|
|
|
<para>Previously, Shorewall has not attempted to undo the changes it
|
|
has made to the firewall's routing as a result of entries in
|
|
<filename>/etc/shorewall/providers</filename> and
|
|
<filename>/etc/shorewall/routes</filename>. Beginning with this
|
|
release, Shorewall will attempt to undo these changes. This change can
|
|
present a migration issue in that the initial routing configuration
|
|
when this version of Shorewall is installed has probably been changed
|
|
by Shorewall already. Hence, when Shorewall restores the original
|
|
configuration, it will be installing a configuration that the
|
|
previously-installed version has already modified.</para>
|
|
|
|
<para>The steps to correcting this after you have installed version
|
|
3.4 or later of Shorewall are as follows:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para><command>shorewall[-lite] stop</command></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Remove the files
|
|
<filename>/var/lib/shorewall[-lite]/default_route</filename> and
|
|
<filename>/var/lib/shorewall[-lite]/undo_routing</filename> if
|
|
they exist.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Either restart networking or reboot.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>shorewall[-lite] start</command></para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This issue only applies if you run Shorewall Lite.</para>
|
|
|
|
<para>The <filename>/etc/shorewall-lite/shorewall.conf</filename> file
|
|
has been renamed
|
|
<filename>/etc/shorewall-lite/shorewall-lite.conf</filename>. When you
|
|
upgrade, your <filename>shorewall.conf</filename> file will be renamed
|
|
<filename>shorewall-lite.conf</filename>.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="V3.2.0">
|
|
<title>Version >= 3.2.0</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>If you are upgrading from version 2.4 or earlier, please read
|
|
the 3.0.0 upgrade considerations below.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A number of macros have been split into two. The macros affected
|
|
are:</para>
|
|
|
|
<simplelist>
|
|
<member>IMAP</member>
|
|
|
|
<member>LDAP</member>
|
|
|
|
<member>NNTP</member>
|
|
|
|
<member>POP3</member>
|
|
|
|
<member>SMTP</member>
|
|
</simplelist>
|
|
|
|
<para>Each of these macros now handles only traffic on the native
|
|
(plaintext) port. There is a corresponding macro with S added to the
|
|
end of the name for the SSL version of the same protocol. Thus each
|
|
macro results in the insertion of only one port per invocation. The
|
|
Web macro has not been split, but two new macros, HTTP and HTTPS have
|
|
been created. The Web macro is deprecated in favour of these new
|
|
macros, and may be removed from future Shorewall releases.</para>
|
|
|
|
<para>These changes have been made to ensure no unexpected ports are
|
|
opened due to the use of macros.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In previous Shorewall releases, DNAT and REDIRECT rules
|
|
supported a special syntax for exclusion of a subnet from the effect
|
|
of the rule.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<blockquote>
|
|
<para>Z2 is a subzone of Z1:</para>
|
|
|
|
<programlisting>DNAT Z1!Z2 loc:192.168.1.4 ...</programlisting>
|
|
</blockquote>
|
|
|
|
<para>That feature has never worked correctly when Z2 is a dynamic
|
|
zone. Furthermore, now that Shorewall supports exclusion lists, the
|
|
capability is redundant since the above rule can now be written in the
|
|
form:</para>
|
|
|
|
<programlisting>DNAT Z1:!<list of exclusions> loc:192.168.1.4 ...</programlisting>
|
|
|
|
<para>Beginning with Shorewall 3.2.0, the special exclusion syntax
|
|
will no longer be supported.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Important if you use the QUEUE target.</para>
|
|
|
|
<para>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).</para>
|
|
|
|
<para>As part of this change, Shorewall no longer adds the "--syn"
|
|
option to TCP rules that specify QUEUE as their target.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Extension Scripts may require change</para>
|
|
|
|
<para>In previous releases, extension scripts were executed during
|
|
<command>[re]start</command> by using the Bourne Shell "." operator.
|
|
In addition to executing commands during <command>[re]start</command>,
|
|
these scripts had to "save" the commands to be executed during
|
|
<command>shorewall restore</command>.</para>
|
|
|
|
<para>This clumsiness has been eliminated in Shorewall 3.2. In
|
|
Shorewall 3.2, extension scripts are copied in-line into the compiled
|
|
program and are executed in-line during <command>start</command>,
|
|
<command>restart</command> and <command>restore</command>. This
|
|
applies to all extension scripts except those associated with a chain
|
|
or action -- those extension scripts continue to be processed at
|
|
compile time.</para>
|
|
|
|
<para>This new approach has two implications for existing
|
|
scripts.</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>It is no longer necessary to save the commands; so functions
|
|
like 'save_command', 'run_and_save_command' and
|
|
'ensure_and_save_command' need no longer be called. The generated
|
|
program will contain functions with these names:</para>
|
|
|
|
<simplelist>
|
|
<member>save_command() - does nothing</member>
|
|
|
|
<member>run_and_save_command() - runs the passed
|
|
command</member>
|
|
|
|
<member>ensure_and_save_command() - runs the passed command and
|
|
stops the firewall if the command fails.</member>
|
|
</simplelist>
|
|
|
|
<para>These functions should provide for transparent migration of
|
|
scripts that use them until you can get around to eliminating
|
|
their use completely.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>When the extension script is copied into the compiled
|
|
program, it is indented to line up with the surrounding code. If
|
|
you have 'awk' installed on your system, the Shorewall compiler
|
|
will correctly handle line continuation (last character on the
|
|
line = "\"). If you do not have awk, it will not be possible to
|
|
use line-continuation in your extension scripts. In no case is it
|
|
possible to continue a quoted string over multiple lines without
|
|
having additional whitespace inserted into the string.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>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:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>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).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>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).</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>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:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para><filename>/usr/share/shorewall/modules</filename> -- the
|
|
former <filename>/etc/shorewall/modules</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>/usr/share/shorewall/xmodules -- a new file that support
|
|
xtables.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>If you wish to use the new file, then simply execute this
|
|
command:</para>
|
|
|
|
<para><command>cp -f /usr/share/shorewall/xmodules
|
|
/etc/shorewall/modules</command></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(<emphasis role="bold">Versions >= 3.2.3</emphasis>)
|
|
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.</para>
|
|
|
|
<para>With correctly-coded rulesets, this change should have no
|
|
effect. Users having incorrectly-coded tcrules may need to change
|
|
them.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#MARK/ SOURCE DEST PROTO DEST SOURCE
|
|
#CLASSIFY PORTS(S) PORT(S)
|
|
1:110 $FW eth3 tcp - 22</programlisting>
|
|
</blockquote>
|
|
|
|
<para>While the user may have expected this rule to only affect
|
|
traffic from the firewall itself, the rule was really equivalent to
|
|
this one:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#MARK/ SOURCE DEST PROTO DEST SOURCE
|
|
#CLASSIFY PORTS(S) PORT(S)
|
|
1:110 0.0.0.0/0 eth3 tcp - 22</programlisting>
|
|
</blockquote>
|
|
|
|
<para>So after this change, the second rule will be required rather
|
|
than the first if that is what was really wanted.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="V3.0.0">
|
|
<title>Version >= 3.0.0</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>The "monitor" command has been eliminated.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The "DISPLAY" and "COMMENTS" columns in the /etc/shorewall/zones
|
|
file have been removed and have been replaced by the former columns of
|
|
the /etc/shorewall/ipsec file. The latter file has been
|
|
removed.</para>
|
|
|
|
<para>Additionally the FW option in shorewall.conf has been deprecated
|
|
and is no longer set to 'fw' by default. New users are expected to
|
|
define the firewall zone in /etc/shorewall/zones.</para>
|
|
|
|
<para>Adhering to the principle of least astonishment, the old
|
|
<filename>/etc/shorewall/ipsec</filename> file will continue to be
|
|
supported. A new IPSECFILE variable in /etc/shorewall/shorewall.conf
|
|
determines the name of the file that Shorewall looks in for IPSEC
|
|
information. If that variable is not set or is set to the empty value
|
|
then IPSECFILE=ipsec is assumed. So if you simply upgrade and don't do
|
|
something idiotic like replace your current shorewall.conf file with
|
|
the new one, your old configuration will continue to work. A dummy
|
|
'ipsec' file is included in the release so that your package manager
|
|
(e.g., rpm) won't remove your existing file.</para>
|
|
|
|
<para>The shorewall.conf file included in this release sets
|
|
IPSECFILE=zones so that new users are expected to use the <ulink
|
|
url="Documentation.htm#Zones">new zone file format</ulink>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The DROPINVALID option has been removed from shorewall.conf. The
|
|
behavior will be as if DROPINVALID=No had been specified. If you wish
|
|
to drop invalid state packets, use the dropInvalid built-in
|
|
action.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The 'nobogons' interface and hosts option as well as the
|
|
BOGON_LOG_LEVEL option have been eliminated.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Most of the standard actions have been replaced by parameterized
|
|
macros (see below). So for example, the action.AllowSMTP and
|
|
action.DropSMTP have been removed an a parameterized macro macro.SMTP
|
|
has been added to replace them.</para>
|
|
|
|
<para>In order that current users don't have to immediately update
|
|
their rules and user-defined actions, Shorewall can substitute an
|
|
invocation of the a new macro for an existing invocation of one of the
|
|
old actions. So if your rules file calls AllowSMTP, Shorewall will
|
|
replace that call with SMTP/ACCEPT. Because this substitution is
|
|
expensive, it is conditional based on the setting of MAPOLDACTIONS in
|
|
shorewall.conf. If this option is set to YES or if it is not set (such
|
|
as if you are using your old shorewall.conf file) then Shorewall will
|
|
perform the substitution. Once you have converted to use the new
|
|
macros, you can set MAPOLDACTIONS=No and invocations of those actions
|
|
will go much quicker during 'shorewall [re]start'.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The STATEDIR variable in /etc/shorewall/shorewall.conf has been
|
|
removed. STATEDIR is now fixed at /var/lib/shorewall. If you have
|
|
previously set STATEDIR to another directory, please copy the files
|
|
from that directory to /var/lib/shorewall/ before [re]starting
|
|
Shorewall after the upgrade to this version.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The "shorewall status" command now just gives the status of
|
|
Shorewall (started or not-started). The previous status command has
|
|
been renamed "dump". The command also shows the state relative to the
|
|
state diagram at <ulink
|
|
url="http://shorewall.net/starting_and_stopping_shorewall.htm">http://shorewall.net/starting_and_stopping_shorewall.htm</ulink>.
|
|
In addition to the state, the time and date at which that state was
|
|
entered is shown.</para>
|
|
|
|
<para>Note that at least one "shorewall [re]start" must be issued
|
|
after upgrading to this release before "shorewall status" will show
|
|
anything but "Unknown" for the state.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The "shorewall forget" command now removes the dynamic blacklist
|
|
save file (/var/lib/shorewall/save).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In previous versions of Shorewall, the rules generated by
|
|
entries in <filename>/etc/shorewall/tunnels</filename> preceded those
|
|
rules generated by entries in
|
|
<filename>/etc/shorewall/rules</filename>. Beginning with this
|
|
release, the rules generated by entries in the tunnels file will
|
|
appear *AFTER* the rules generated by the rules file. This may cause
|
|
you problems if you have REJECT, DENY or CONTINUE rules in your rules
|
|
file that would cause the tunnel transport packets to not reach the
|
|
rules that ACCEPT them. See <ulink
|
|
url="http://www.shorewall.net/VPNBasics.html">http://www.shorewall.net/VPNBasics.html</ulink>
|
|
for information on the rules generated by entries in the tunnels
|
|
file.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have
|
|
been removed as have the 'newnotsyn' options in
|
|
<filename>/etc/shorewall/interfaces</filename> and
|
|
<filename>/etc/shorewall/hosts</filename>.</para>
|
|
|
|
<para>TCP new-not-syn packets may be blocked using the 'dropNotSyn' or
|
|
'rejNotSyn' built-in actions.</para>
|
|
|
|
<para>Example: Reject all new-not-syn packets from the net and log
|
|
them at the 'info' level.</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO
|
|
SECTION NEW
|
|
rejNotSyn:info net all tcp</programlisting>
|
|
|
|
<para>Note that the rule is added at the front of the NEW section of
|
|
the rules file.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A new TC_SCRIPT option replaces TC_ENABLED in shorewall.conf. If
|
|
the option is not set then the internal shaper (tc4shorewall by Arne
|
|
Bernin) is used. Otherwise, the script named in the variable is
|
|
used.</para>
|
|
|
|
<para>Users who currently use an
|
|
<filename>/etc/shorewall/tcstart</filename> file and wish to continue
|
|
to do so should set TC_SCRIPT=/etc/shorewall/tcstart in
|
|
shorewall.conf.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="V2.4.0">
|
|
<title>Version >= 2.4.0</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Shorewall now enforces the restriction that mark values used in
|
|
<filename> /etc/shorewall/tcrules</filename> are less than 256. If you
|
|
are using mark values >= 256, you must change your configuration
|
|
before you upgrade.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The value "ipp2p" is no longer accepted in the PROTO column of
|
|
the <filename>/etc/shorewall/rules</filename> file. This support has
|
|
never worked as intended and cannot be made to work in a consistent
|
|
way. A "Howto" article on filtering P2P with Shorewall and ipp2p will
|
|
be forthcoming.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>LEAF/Bering packages for 2.4.0 and later releases are not
|
|
available from shorewall.net. See the <ulink
|
|
url="http://leaf.sourceforge.net">LEAF site</ulink> for those
|
|
packages.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
</article> |