forked from extern/shorewall_code
b2c54f5063
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@7069 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
1403 lines
59 KiB
XML
1403 lines
59 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<refentry>
|
|
<refmeta>
|
|
<refentrytitle>shorewall.conf</refentrytitle>
|
|
|
|
<manvolnum>5</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>shorewall.conf</refname>
|
|
|
|
<refpurpose>Shorewall global configuration file</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>/etc/shorewall/shorewall.conf</command>
|
|
</cmdsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>This file sets options that apply to Shorewall as a whole.</para>
|
|
|
|
<para>The file consists of Shell comments (lines beginning with '#'),
|
|
blank lines and assignment statements
|
|
(<emphasis>variable</emphasis>=<emphasis>value</emphasis>).</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>OPTIONS</title>
|
|
|
|
<para>Many options have as their value a <emphasis>log-level</emphasis>.
|
|
Log levels are a method of describing to syslog (8) the importance of a
|
|
message and a number of parameters in this file have log levels as their
|
|
value.</para>
|
|
|
|
<para>These levels are defined by syslog and are used to determine the
|
|
destination of the messages through entries in /etc/syslog.conf (5). The
|
|
syslog documentation refers to these as "priorities"; Netfilter calls them
|
|
"levels" and Shorewall also uses that term.</para>
|
|
|
|
<para>Valid levels are:</para>
|
|
|
|
<programlisting> 7 debug
|
|
6 info
|
|
5 notice
|
|
4 warning
|
|
3 err
|
|
2 crit
|
|
1 alert
|
|
0 emerg</programlisting>
|
|
|
|
<para>For most Shorewall logging, a level of 6 (info) is appropriate.
|
|
Shorewall log messages are generated by NetFilter and are logged using
|
|
facility 'kern' and the level that you specifify. If you are unsure of the
|
|
level to choose, 6 (info) is a safe bet. You may specify levels by name or
|
|
by number.</para>
|
|
|
|
<para>If you have built your kernel with ULOG target support, you may also
|
|
specify a log level of ULOG (must be all caps). Rather than log its
|
|
messages to syslogd, Shorewall will direct netfilter to log the messages
|
|
via the ULOG target which will send them to a process called 'ulogd'.
|
|
ulogd is available with most Linux distributions (although it probably
|
|
isn't installed by default). Ulogd is also available from <ulink
|
|
url="http://www.netfilter.org/projects/ulogd/index.html">http://www.netfilter.org/projects/ulogd/index.html</ulink>
|
|
and can be configured to log all Shorewall message to their own log
|
|
file</para>
|
|
|
|
<para>The following options may be set in shorewall.conf.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">ACCEPT_DEFAULT=</emphasis>{<emphasis>action</emphasis>|<emphasis>macro</emphasis>|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">DROP_DEFAULT=</emphasis>{<emphasis>action</emphasis>|<emphasis>macro</emphasis>|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">REJECT_DEFAULT=</emphasis>{<emphasis>action</emphasis>|<emphasis>macro</emphasis>|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">QUEUE_DEFAULT=</emphasis>{<emphasis>action</emphasis>|<emphasis>macro</emphasis>|<emphasis
|
|
role="bold">none</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>In earlier Shorewall versions, a "default action" for DROP and
|
|
REJECT policies was specified in the file
|
|
/usr/share/shorewall/actions.std.</para>
|
|
|
|
<para>To allow for default rules to be applied when USE_ACTIONS=No,
|
|
the DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and QUEUE_DEFAULT
|
|
options have been added.</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.</para>
|
|
|
|
<para>The value applied to these may be:</para>
|
|
|
|
<simplelist>
|
|
<member>a) The name of an
|
|
<replaceable>action</replaceable>.</member>
|
|
|
|
<member>b) The name of a <replaceable>macro</replaceable>
|
|
(Shorewall-shell only)</member>
|
|
|
|
<member>c) <emphasis role="bold">None</emphasis> or <emphasis
|
|
role="bold">none</emphasis></member>
|
|
</simplelist>
|
|
|
|
<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 must be
|
|
specified in <ulink
|
|
url="shorewall-policy.html">shorewall-policy</ulink>(5).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ADD_IP_ALIASES=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter determines whether Shorewall automatically adds
|
|
the external address(es) in <ulink
|
|
url="shorewall-nat.html">shorewall-nat</ulink>(5). If the variable
|
|
is set to <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis> then Shorewall automatically adds these
|
|
aliases. If it is set to <emphasis role="bold">No</emphasis> or
|
|
<emphasis role="bold">no</emphasis>, you must add these aliases
|
|
yourself using your distribution's network configuration
|
|
tools.</para>
|
|
|
|
<para>If this variable is not set or is given an empty value
|
|
(ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.</para>
|
|
|
|
<warning>
|
|
<para>Addresses added by ADD_IP_ALIASES=Yes are deleted and
|
|
re-added during shorewall restart. As a consequence, connections
|
|
using those addresses may be severed.</para>
|
|
</warning>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ADD_SNAT_ALIASES=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter determines whether Shorewall automatically adds
|
|
the SNAT ADDRESS in <ulink
|
|
url="shorewall-masq.html">shorewall-masq</ulink>(5). If the variable
|
|
is set to <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis> then Shorewall automatically adds these
|
|
addresses. If it is set to <emphasis role="bold">No</emphasis> or
|
|
<emphasis role="bold">no</emphasis>, you must add these addresses
|
|
yourself using your distribution's network configuration
|
|
tools.</para>
|
|
|
|
<para>If this variable is not set or is given an empty value
|
|
(ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.</para>
|
|
|
|
<warning>
|
|
<para>Addresses added by ADD_SNAT_ALIASES=Yes are deleted and
|
|
re-added during shorewall restart. As a consequence, connections
|
|
using those addresses may be severed.</para>
|
|
</warning>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ADMINISABSENTMINDED=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>The value of this variable affects Shorewall's stopped state.
|
|
When ADMINISABSENTMINDED=No, only traffic to/from those addresses
|
|
listed in <ulink
|
|
url="shorewall-routestopped.html">shorewall-routestopped</ulink>(5)
|
|
is accepted when Shorewall is stopped. When ADMINISABSENTMINDED=Yes,
|
|
in addition to traffic to/from addresses in <ulink
|
|
url="shorewall-routestopped.html">shorewall-routestopped</ulink>(5),
|
|
connections that were active when Shorewall stopped continue to work
|
|
and all new connections from the firewall system itself are allowed.
|
|
If this variable is not set or is given the empty value then
|
|
ADMINISABSENTMINDED=No is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">BLACKLIST_DISPOSITION=</emphasis>[<emphasis
|
|
role="bold">DROP</emphasis>|<emphasis
|
|
role="bold">REJECT</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter determines the disposition of packets from
|
|
blacklisted hosts. It may have the value DROP if the packets are to
|
|
be dropped or REJECT if the packets are to be replied with an ICMP
|
|
port unreachable reply or a TCP RST (tcp only). If you do not assign
|
|
a value or if you assign an empty value then DROP is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">BLACKLIST_LOGLEVEL=</emphasis>[<emphasis>log-level</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter determines if packets from blacklisted hosts
|
|
are logged and it determines the syslog level that they are to be
|
|
logged at. Its value is a syslog level (Example:
|
|
BLACKLIST_LOGLEVEL=debug). If you do not assign a value or if you
|
|
assign an empty value then packets from blacklisted hosts are not
|
|
logged.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">BLACKLISTNEWONLY=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>When set to <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis>, blacklists are only consulted for new
|
|
connections. When set to <emphasis role="bold">No</emphasis> or
|
|
<emphasis role="bold">no</emphasis>, blacklists are consulted for
|
|
every packet (will slow down your firewall noticably if you have
|
|
large blacklists). If the BLACKLISTNEWONLY option is not set or is
|
|
set to the empty value then BLACKLISTNEWONLY=No is assumed.</para>
|
|
|
|
<note>
|
|
<para>BLACKLISTNEWONLY=No is incompatible with
|
|
FASTACCEPT=Yes.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">BRIDGING=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>When set to <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis>, enables Shorewall Bridging support.<note>
|
|
<para>BRIDGING=Yes may not work properly with Linux kernel
|
|
2.6.20 or later and is not supported by Shorewall-perl.</para>
|
|
</note></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">CLAMPMSS=[</emphasis><emphasis
|
|
role="bold">Yes</emphasis>|<emphasis
|
|
role="bold">No</emphasis>|<emphasis>value</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter enables the TCP Clamp MSS to PMTU feature of
|
|
Netfilter and is usually required when your internet connection is
|
|
through PPPoE or PPTP. If set to <emphasis
|
|
role="bold">Yes</emphasis> or <emphasis role="bold">yes</emphasis>,
|
|
the feature is enabled. If left blank or set to <emphasis
|
|
role="bold">No</emphasis> or <emphasis role="bold">no</emphasis>,
|
|
the feature is not enabled.</para>
|
|
|
|
<note>
|
|
<para>This option requires CONFIG_IP_NF_TARGET_TCPMSS in your
|
|
kernel.</para>
|
|
</note>
|
|
|
|
<para>You may also set CLAMPMSS to a numeric
|
|
<emphasis>value</emphasis> (e.g., CLAMPMSS=1400). This will set the
|
|
MSS field in TCP SYN packets going through the firewall to the
|
|
<emphasis>value</emphasis> that you specify.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">CLEAR_TC=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If this option is set to <emphasis role="bold">No</emphasis>
|
|
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 <ulink
|
|
url="shorewall-tcrules.html">shorewall-tcrules</ulink>(5). If not
|
|
specified, CLEAR_TC=Yes is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">CONFIG_PATH</emphasis>=[<emphasis>directory</emphasis>[:<emphasis>directory</emphasis>]...]</term>
|
|
|
|
<listitem>
|
|
<para>Specifies where configuration files other than shorewall.conf
|
|
may be found. CONFIG_PATH is specifies as a list of directory names
|
|
separated by colons (":"). When looking for a configuration file
|
|
other than shorewall.conf:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>If the command is "try" or if "-c <configuration
|
|
directory>" was specified in the command then the directory
|
|
given in the command is searched first.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Next, each directory in the CONFIG_PATH setting is
|
|
searched in sequence.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>If CONFIG_PATH is not given or if it is set to the empty value
|
|
then the contents of /usr/share/shorewall/configpath are used. As
|
|
released from shorewall.net, that file sets the CONFIG_PATH to
|
|
/etc/shorewall:/usr/share/shorewall but your particular distribution
|
|
may set it differently. See the output of shorewall show config for
|
|
the default on your system.</para>
|
|
|
|
<para>Note that the setting in /usr/share/shorewall/configpath is
|
|
always used to locate shorewall.conf.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">DELAYBLACKLISTLOAD=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Users with a large static black list (<ulink
|
|
url="shorewall-blacklist.html">shorewall-blacklist</ulink>(5)) may
|
|
want to set the DELAYBLACKLISTLOAD option to <emphasis
|
|
role="bold">Yes</emphasis>. 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 <emphasis
|
|
role="bold">shorewall</emphasis> [<emphasis
|
|
role="bold">re</emphasis>]<emphasis
|
|
role="bold">start</emphasis>.</para>
|
|
|
|
<note>
|
|
<para>DELAYBLACKLISTLOAD=Yes is not supported by
|
|
Shorewall-perl.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">DETECT_DNAT_IPADDRS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If set to <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis>, Shorewall will detect the first IP
|
|
address of the interface to the source zone and will include this
|
|
address in DNAT rules as the original destination IP address. If set
|
|
to <emphasis role="bold">No</emphasis> or <emphasis
|
|
role="bold">no</emphasis>, Shorewall will not detect this address
|
|
and any destination IP address will match the DNAT rule. If not
|
|
specified or empty, “DETECT_DNAT_IPADDRS=Yes” is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">DYNAMIC_ZONES=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>When set to <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis>, enables dynamic zones. DYNAMIC_ZONES=Yes
|
|
is not allowed in configurations that will run under Shorewall
|
|
Lite.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">EXPAND_POLICIES=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Normally, when the SOURCE or DEST columns in
|
|
shorewall-policy(5) contains 'all', a single policy chain is created
|
|
and the policy is enforced in that chain. For example, if the policy
|
|
entry is<programlisting>#SOURCE DEST POLICY LOG
|
|
# LEVEL
|
|
net all DROP info</programlisting>then the chain name is 'net2all'
|
|
which is also the chain named in Shorewall log messages generated as
|
|
a result of the policy. If EXPAND_POLICIES=Yes, then Shorewall-perl
|
|
will create a separate chain for each pair of zones covered by the
|
|
policy. This makes the resulting log messages easier to interpret
|
|
since the chain in the messages will have a name of the form 'a2b'
|
|
where 'a' is the SOURCE zone and 'b' is the DEST zone.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">EXPORTPARAMS=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>It is quite difficult to code a 'params' file that assigns
|
|
other than constant values such that it works correctly with
|
|
Shorewall Lite. The EXPORTPARAMS option works around this problem.
|
|
When EXPORTPARAMS=No, the 'params' file is not copied to the
|
|
compiler output.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>The default is EXPORTPARAMS=Yes</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">FASTACCEPT=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Normally, Shorewall defers accepting ESTABLISHED/RELATED
|
|
packets until these packets reach the chain in which the original
|
|
connection was accepted. So for packets going from the 'loc' zone to
|
|
the 'net' zone, ESTABLISHED/RELATED packets are ACCEPTED in the
|
|
'loc2net' chain.</para>
|
|
|
|
<para>If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets
|
|
are accepted early in the INPUT, FORWARD and OUTPUT chains. If you
|
|
set FASTACCEPT=Yes then you may not include rules in the ESTABLISHED
|
|
or RELATED sections of <ulink
|
|
url="shorewall-rules.html">shorewall-rules</ulink>(5).</para>
|
|
|
|
<note>
|
|
<para>FASTACCEPT=Yes is incompatible with
|
|
BLACKLISTNEWONLY=No.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">HIGH_ROUTE_MARKS=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Prior to version 3.2.0, it was not possible to use connection
|
|
marking in <ulink
|
|
url="shorewall-tcrules.html">shorewall-tcrules</ulink>(5) if you
|
|
have a multi-ISP configuration that uses the track option.</para>
|
|
|
|
<para>Beginning with release 3.2.0, you may now set
|
|
HIGH_ROUTE_MARKS=Yes in to effectively divide the packet mark and
|
|
connection mark into two 8-byte mark fields.</para>
|
|
|
|
<para>When you do this:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>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).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You may only set those mark values in the PREROUTING
|
|
chain.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Marks used for traffic shaping must still be in the range
|
|
of 1-255 and may still not be set in the PREROUTING
|
|
chain.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>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.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">IMPLICIT_CONTINUE=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>When this option is set to <emphasis
|
|
role="bold">Yes</emphasis>, it causes subzones to be treated
|
|
differently with respect to policies.</para>
|
|
|
|
<para>Subzones are defined by following their name with ":" and a
|
|
list of parent zones (in <ulink
|
|
url="shorewall-zones.html">shorewall-zones</ulink>(5)). 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; see
|
|
<ulink url="shorewall-nesting.html">shorewall-nesting</ulink>(5).
|
|
With IMPLICIT_CONTINUE=Yes, that happens automatically.</para>
|
|
|
|
<para>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).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">IP_FORWARDING=</emphasis>[<emphasis
|
|
role="bold">On</emphasis>|<emphasis
|
|
role="bold">Off</emphasis>|<emphasis
|
|
role="bold">Keep</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter determines whether Shorewall enables or
|
|
disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward).
|
|
Possible values are:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">On</emphasis> or <emphasis
|
|
role="bold">on</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>packet forwarding will be enabled.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">Off</emphasis> or <emphasis
|
|
role="bold">off</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>packet forwarding will be disabled.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">Keep</emphasis> or <emphasis
|
|
role="bold">keep</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Shorewall will neither enable nor disable packet
|
|
forwarding.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>If this variable is not set or is given an empty value
|
|
(IP_FORWARD="") then IP_FORWARD=On is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">IPSECFILE=</emphasis>{<emphasis
|
|
role="bold">zones</emphasis>|<emphasis
|
|
role="bold">ipsec</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>This should be set to <emphasis role="bold">zones</emphasis>
|
|
for all new Shorewall installations. IPSECFILE=ipsec is only used
|
|
for compatibility with pre-Shorewall-3.0 configurations.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">IPTABLES=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter names the iptables executable to be used by
|
|
Shorewall. If not specified or if specified as a null value, then
|
|
the iptables executable located using the PATH option is
|
|
used.</para>
|
|
|
|
<para>Regardless of how the IPTABLES utility is located (specified
|
|
via IPTABLES= or located via PATH), Shorewall uses the
|
|
iptables-restore and iptables-save utilities from that same
|
|
directory.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">LOG_MARTIANS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis
|
|
role="bold">No</emphasis>|Keep]</term>
|
|
|
|
<listitem>
|
|
<para>If set to <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis>, sets
|
|
/proc/sys/net/ipv4/conf/all/log_martians and
|
|
/proc/sys/net/ipv4/conf/default/log_martians to 1. Default is
|
|
<emphasis role="bold">No</emphasis> which sets both of the above to
|
|
zero. If you do not enable martian logging for all interfaces, you
|
|
may still enable it for individual interfaces using the <emphasis
|
|
role="bold">logmartians</emphasis> interface option in <ulink
|
|
url="shorewall-interfaces.html">shorewall-interfaces</ulink>(5).</para>
|
|
|
|
<para>The value <emphasis role="bold">Keep</emphasis> is only
|
|
allowed under Shorewall-perl. It causes Shorewall to ignore the
|
|
option. If the option is set to <emphasis
|
|
role="bold">Yes</emphasis>, then martians are logged on all
|
|
interfaces. If the option is set to <emphasis
|
|
role="bold">No</emphasis>, then martian logging is disabled on all
|
|
interfaces except those specified in <ulink
|
|
url="shorewall-interfaces.html">shorewall-interfaces</ulink>(5).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOGALLNEW=</emphasis>[<emphasis>log-level</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>When set to a log level, this option causes Shorewall to
|
|
generate a logging rule as the first rule in each builtin
|
|
chain.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The table name is used as the chain name in the log
|
|
prefix.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The chain name is used as the target in the log
|
|
prefix.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>For example, using the default LOGFORMAT, the log prefix for
|
|
logging from the nat table's PREROUTING chain is:</para>
|
|
|
|
<programlisting> Shorewall:nat:PREROUTING
|
|
</programlisting>
|
|
|
|
<important>
|
|
<para>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.</para>
|
|
</important>
|
|
|
|
<caution>
|
|
<para>Do not use this option if the resulting log messages will be
|
|
sent to another system.</para>
|
|
</caution>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOGFILE=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter tells the /sbin/shorewall program where to look
|
|
for Shorewall messages when processing the <emphasis
|
|
role="bold">dump</emphasis>, <emphasis
|
|
role="bold">logwatch</emphasis>, <emphasis role="bold">show
|
|
log</emphasis>, and <emphasis role="bold">hits</emphasis> commands.
|
|
If not assigned or if assigned an empty value, /var/log/messages is
|
|
assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">LOGFORMAT=</emphasis>[<emphasis
|
|
role="bold">"</emphasis><emphasis>formattemplate</emphasis><emphasis
|
|
role="bold">"</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>The value of this variable generate the --log-prefix setting
|
|
for Shorewall logging rules. It contains a “printf” formatting
|
|
template which accepts three arguments (the chain name, logging rule
|
|
number (optional) and the disposition). To use LOGFORMAT with
|
|
fireparse, set it as:</para>
|
|
|
|
<programlisting> LOGFORMAT="fp=%s:%d a=%s "</programlisting>
|
|
|
|
<para>If the LOGFORMAT value contains the substring “%d” then the
|
|
logging rule number is calculated and formatted in that position; if
|
|
that substring is not included then the rule number is not included.
|
|
If not supplied or supplied as empty (LOGFORMAT="") then
|
|
“Shorewall:%s:%s:” is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOGBURST=</emphasis>[<emphasis>burst</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">LOGRATE=</emphasis>[<emphasis>rate</emphasis>/{<emphasis
|
|
role="bold">minute</emphasis>|<emphasis
|
|
role="bold">second</emphasis>}]</term>
|
|
|
|
<listitem>
|
|
<para>These parameters set the match rate and initial burst size for
|
|
logged packets. Please see iptables(8) for a description of the
|
|
behavior of these parameters (the iptables option --limit is set by
|
|
LOGRATE and --limit-burst is set by LOGBURST). If both parameters
|
|
are set empty, no rate-limiting will occur.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<programlisting> LOGRATE=10/minute
|
|
LOGBURST=5</programlisting>
|
|
|
|
<para>For each logging rule, the first time the rule is reached, the
|
|
packet will be logged; in fact, since the burst is 5, the first five
|
|
packets will be logged. After this, it will be 6 seconds (1 minute
|
|
divided by the rate of 10) before a message will be logged from the
|
|
rule, regardless of how many packets reach it. Also, every 6 seconds
|
|
which passes without matching a packet, one of the bursts will be
|
|
regained; if no packets hit the rule for 30 seconds, the burst will
|
|
be fully recharged; back where we started.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">LOGTAGONLY=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Using the default LOGFORMAT, chain names may not exceed 11
|
|
characters or truncation of the log prefix may occur. Longer chain
|
|
names may be used with log tags if you set LOGTAGONLY=Yes. With
|
|
LOGTAGONLY=Yes, if a log tag is specified then the tag is included
|
|
in the log prefix in place of the chain name.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">MACLIST_DISPOSITION=</emphasis>[<emphasis
|
|
role="bold">ACCEPT</emphasis>|<emphasis
|
|
role="bold">DROP</emphasis>|<emphasis
|
|
role="bold">REJECT</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Determines the disposition of connections requests that fail
|
|
MAC Verification and must have the value ACCEPT (accept the
|
|
connection request anyway), REJECT (reject the connection request)
|
|
or DROP (ignore the connection request). If not set or if set to the
|
|
empty value (e.g., MACLIST_DISPOSITION="") then
|
|
MACLIST_DISPOSITION=REJECT is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">MACLIST_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Determines the syslog level for logging connection requests
|
|
that fail MAC Verification. The value must be a valid syslogd log
|
|
level. If you don't want to log these connection requests, set to
|
|
the empty value (e.g., MACLIST_LOG_LEVEL="").</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">MACLIST_TABLE=</emphasis>[<emphasis
|
|
role="bold">filter</emphasis>|<emphasis
|
|
role="bold">mangle</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Normally, MAC verification occurs in the filter table (INPUT
|
|
and FORWARD) chains. When forwarding a packet from an interface with
|
|
MAC verification to a bridge interface, that doesn't work.</para>
|
|
|
|
<para>This problem can be worked around by setting
|
|
MACLIST_TABLE=mangle which will cause Mac verification to occur out
|
|
of the PREROUTING chain. Because REJECT isn't available in that
|
|
environment, you may not specify MACLIST_DISPOSITION=REJECT with
|
|
MACLIST_TABLE=mangle.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">MACLIST_TTL=[</emphasis><emphasis>number</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>The performance of configurations with a large numbers of
|
|
entries in <ulink
|
|
url="shorewall-maclist.html">shorewall-maclist</ulink>(5) can be
|
|
improved by setting the MACLIST_TTL variable in <ulink
|
|
url="shorewall.conf.html">shorewall.conf</ulink>(5).</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>When a new connection arrives from a 'maclist' interface, the
|
|
packet passes through then list of entries for that interface in
|
|
<ulink url="shorewall-maclist.html">shorewall-maclist</ulink>(5). 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 occurring 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.</para>
|
|
|
|
<para>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).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">MAPOLDACTIONS=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Previously, Shorewall included a large number of standard
|
|
actions (AllowPing, AllowFTP, ...). These have been replaced with
|
|
parameterized macros. For compatibility, Shorewall can map the old
|
|
names into invocations of the new macros if you set
|
|
MAPOLDACTIONS=Yes. If this option is not set or is set to the empty
|
|
value (MAPOLDACTIONS="") then MAPOLDACTIONS=Yes is assumed.</para>
|
|
|
|
<note>
|
|
<para>MAPOLDACTIONS=Yes is not supported by Shorewall-perl. With
|
|
Shorewall-perl, if MAPOLDACTIONS is not set or is set to the ampty
|
|
value then MAPOLDACTIONS=No is assumed.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">MARK_IN_FORWARD_CHAIN=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If your kernel has a FORWARD chain in the mangle table, you
|
|
may set MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in
|
|
the tcrules file to occur in that chain rather than in the
|
|
PREROUTING chain. This permits you to mark inbound traffic based on
|
|
its destination address when DNAT is in use. To determine if your
|
|
kernel has a FORWARD chain in the mangle table, use the <emphasis
|
|
role="bold">/sbin/shorewall show mangle</emphasis> command; if a
|
|
FORWARD chain is displayed then your kernel will support this
|
|
option. If this option is not specified or if it is given the empty
|
|
value (e.g., MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No
|
|
is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">MODULE_SUFFIX=</emphasis>[<emphasis
|
|
role="bold">"</emphasis><emphasis>extension</emphasis> ...<emphasis
|
|
role="bold">"</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>The value of this option determines the possible file
|
|
extensions of kernel modules. The default value is "o gz ko
|
|
o.gz".</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">MODULESDIR=</emphasis>[<emphasis>pathname</emphasis>[<emphasis
|
|
role="bold">:</emphasis><emphasis>pathname</emphasis>]...]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter specifies the directory/directories where your
|
|
kernel netfilter modules may be found. If you leave the variable
|
|
empty, Shorewall will supply the value "/lib/modules/`uname
|
|
-r`/kernel/net/ipv4/netfilter" in versions of Shorewall prior to
|
|
3.2.4 and "/lib/modules/`uname
|
|
-r`/kernel/net/ipv4/netfilter:/lib/modules/`uname
|
|
-r`/kernel/net/ipv4/netfilter" in later versions.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">MUTEX_TIMEOUT=</emphasis>[<emphasis>seconds</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>The value of this variable determines the number of seconds
|
|
that programs will wait for exclusive access to the Shorewall lock
|
|
file. After the number of seconds corresponding to the value of this
|
|
variable, programs will assume that the last program to hold the
|
|
lock died without releasing the lock.</para>
|
|
|
|
<para>If not set or set to the empty value, a value of 60 (60
|
|
seconds) is assumed.</para>
|
|
|
|
<para>An appropriate value for this parameter would be twice the
|
|
length of time that it takes your firewall system to process a
|
|
<emphasis role="bold">shorewall restart</emphasis> command.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">OPTIMIZE=</emphasis>[<emphasis
|
|
role="bold">0</emphasis>|<emphasis role="bold">1</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Traditionally, Shorewall has created rules for <ulink
|
|
url="../ScalabilityAndPerformance.html">the complete matrix of host
|
|
groups defined by the zones, interfaces and hosts files</ulink>. Any
|
|
traffic that didn't correspond to an element of that matrix was
|
|
rejected in one of the built-in chains. When the matrix is sparse,
|
|
this results in lots of largely useless rules.</para>
|
|
|
|
<para>These extra rules can be eliminated by setting
|
|
OPTIMIZE=1.</para>
|
|
|
|
<para>The OPTIMIZE setting also controls the suppression of
|
|
redundant wildcard rules (those specifying "all" in the SOURCE or
|
|
DEST column). A wildcard rule is considered to be redundant when it
|
|
has the same ACTION and Log Level as the applicable policy.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">PATH=</emphasis><emphasis>pathname</emphasis>[<emphasis
|
|
role="bold">:</emphasis><emphasis>pathname</emphasis>]...</term>
|
|
|
|
<listitem>
|
|
<para>Determines the order in which Shorewall searches directories
|
|
for executable files.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">PKTTYPE=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Normally Shorewall attempts to use the iptables packet type
|
|
match extension to determine broadcast and multicast packets.</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>This can cause a message to appear during shorewall start
|
|
(modprobe: cant locate module ipt_pkttype).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Some users have found problems with the packet match
|
|
extension with the result that their firewall log is flooded
|
|
with messages relating to broadcast packets.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>If you are experiencing either of these problems, setting
|
|
PKTTYPE=No will prevent Shorewall from trying to use the packet type
|
|
match extension and to use IP address matching to determine which
|
|
packets are broadcasts or multicasts.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RCP_COMMAND="</emphasis><replaceable>command</replaceable><emphasis
|
|
role="bold">"</emphasis></term>
|
|
|
|
<listitem>
|
|
<para></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RSH_COMMAND="</emphasis><replaceable>command</replaceable><emphasis
|
|
role="bold">"</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Eariler generations of Shorewall Lite required that remote
|
|
root login via ssh be enabled in order to use the
|
|
<command>load</command> and <command>reload</command> commands.
|
|
Beginning with release 3.9.5, you may define an alternative means
|
|
for accessing the remote firewall system. In that release, two new
|
|
options were added to shorewall.conf:<simplelist>
|
|
<member>RSH_COMMAND</member>
|
|
|
|
<member>RCP_COMMAND</member>
|
|
</simplelist>The default values for these are as
|
|
follows:<simplelist>
|
|
<member>RSH_COMMAND: ssh ${root}@${system} ${command}</member>
|
|
|
|
<member>RCP_COMMAND: scp ${files}
|
|
${root}@${system}:${destination}</member>
|
|
</simplelist>Shell variables that will be set when the commands
|
|
are envoked are as follows:<simplelist>
|
|
<member><replaceable>root</replaceable> - root user. Normally
|
|
<option>root</option> but may be overridden using the '-r'
|
|
option.</member>
|
|
|
|
<member><replaceable>system</replaceable> - The name/IP address
|
|
of the remote firewall system.</member>
|
|
|
|
<member><replaceable>command</replaceable> - For RSH_COMMAND,
|
|
the command to be executed on the firewall system.</member>
|
|
|
|
<member><replaceable>files</replaceable> - For RCP_COMMAND, a
|
|
space-separated list of files to be copied to the remote
|
|
firewall system.</member>
|
|
|
|
<member><replaceable>destination</replaceable> - The directory
|
|
on the remote system that the files are to be copied
|
|
into.</member>
|
|
</simplelist></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RESTOREFILE=</emphasis><emphasis>filename</emphasis></term>
|
|
|
|
<listitem>
|
|
<para>Specifies the simple name of a file in /var/lib/shorewall to
|
|
be used as the default restore script in the <emphasis
|
|
role="bold">shorewall save</emphasis>, <emphasis
|
|
role="bold">shorewall restore</emphasis>, <emphasis
|
|
role="bold">shorewall forget </emphasis>and <emphasis
|
|
role="bold">shorewall -f start</emphasis> commands.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">RETAIN_ALIASES=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>During <emphasis role="bold">shorewall star</emphasis>t, IP
|
|
addresses to be added as a consequence of ADD_IP_ALIASES=Yes and
|
|
ADD_SNAT_ALIASES=Yes are quietly deleted when <ulink
|
|
url="shorewall-nat.html">shorewall-nat</ulink>(5) and <ulink
|
|
url="shorewall-masq.html">shorewall-masq</ulink>(5) are processed
|
|
then 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.
|
|
When RETAIN_ALIASES is set to Yes, existing addresses will not be
|
|
deleted. Regardless of the setting of RETAIN_ALIASES, addresses
|
|
added during <emphasis role="bold">shorewall start</emphasis> are
|
|
still deleted at a subsequent <emphasis role="bold">shorewall
|
|
stop</emphasis> or <emphasis role="bold">shorewall
|
|
restart</emphasis>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">RFC1918_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter determines the level at which packets logged
|
|
under the <emphasis role="bold">norfc1918</emphasis> mechanism are
|
|
logged. The value must be a valid syslog level and if no level is
|
|
given, then info is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">RFC1918_STRICT=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>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 this entry in
|
|
<ulink
|
|
url="shorewall-rfc1918.html">shorewall-rfc1918</ulink>(5):</para>
|
|
|
|
<programlisting> #SUBNETS TARGET
|
|
192.168.1.0/24 RETURN</programlisting>
|
|
|
|
<para>then traffic from 192.168.1.4 to 10.0.3.9 will be accepted
|
|
even though you also have:</para>
|
|
|
|
<programlisting> #SUBNETS TARGET
|
|
10.0.0.0/8 logdrop</programlisting>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>If not specified or specified as empty (e.g.,
|
|
RFC1918_STRICT="") then RFC1918_STRICT=No is assumed.</para>
|
|
|
|
<warning>
|
|
<para>RFC1918_STRICT=Yes requires that your kernel and iptables
|
|
support 'Connection Tracking' match.</para>
|
|
</warning>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ROUTE_FILTER=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis
|
|
role="bold">No</emphasis>|Keep]</term>
|
|
|
|
<listitem>
|
|
<para>If this parameter is given the value <emphasis
|
|
role="bold">Yes</emphasis> or <emphasis role="bold">yes</emphasis>
|
|
then route filtering (anti-spoofing) is enabled on all network
|
|
interfaces which are brought up while Shorewall is in the started
|
|
state. The default value is <emphasis
|
|
role="bold">no</emphasis>.</para>
|
|
|
|
<para>The value <emphasis role="bold">Keep</emphasis> is only
|
|
allowed under Shorewall-perl. It causes Shorewall to ignore the
|
|
option. If the option is set to <emphasis
|
|
role="bold">Yes</emphasis>, then route filtering occurs on all
|
|
interfaces. If the option is set to <emphasis
|
|
role="bold">No</emphasis>, then route filtering is disabled on all
|
|
interfaces except those specified in <ulink
|
|
url="shorewall-interfaces.html">shorewall-interfaces</ulink>(5).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">SAVE_IPSETS=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>If SAVE_IPSETS=Yes, then the current contents of your ipsets
|
|
will be saved by the <emphasis role="bold">shorewall save</emphasis>
|
|
command. Regardless of the setting of SAVE_IPSETS, if saved ipset
|
|
contents are available then they will be restored by <emphasis
|
|
role="bold">shorewall restore</emphasis>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">SHOREWALL_COMPILER=</emphasis>{<emphasis
|
|
role="bold">perl</emphasis>|<emphasis
|
|
role="bold">shell</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Specifies the compiler to use to generate a firewall script.
|
|
The value of this option can be either perl or shell.</para>
|
|
|
|
<para>If you add 'SHOREWALL_COMPILER=perl' to
|
|
<filename>/etc/shorewall/shorewall.conf</filename> then by default,
|
|
the Shorewall-perl compiler will be used on the system. If you add
|
|
it to <filename>shorewall.conf</filename> in a separate directory
|
|
(such as a Shorewall-lite export directory) then the Shorewall-perl
|
|
compiler will only be used when you compile from that
|
|
directory.</para>
|
|
|
|
<para>If you only install one compiler, it is suggested that you do
|
|
not set SHOREWALL_COMPILER.</para>
|
|
|
|
<para>This setting may be overriden using the -C command option (see
|
|
<ulink url="shorewall.html">shorewall</ulink>(8)).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">SHOREWALL_SHELL=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This option is used to specify the shell program to be used to
|
|
run the Shorewall compiler and to interpret the compiled script. If
|
|
not specified or specified as a null value, /bin/sh is assumed.
|
|
Using a light-weight shell such as ash or dash can significantly
|
|
improve performance.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">SMURF_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Specifies the logging level for smurf packets (see the
|
|
nosmurfs option in <ulink
|
|
url="shorewall-interfaces.html">shorewall-interfaces</ulink>(5)). If
|
|
set to the empty value ( SMURF_LOG_LEVEL="" ) then smurfs are not
|
|
logged.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">STARTUP_ENABLED=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>Determines if Shorewall is allowed to start. As released from
|
|
shorewall.net, this option is set to <emphasis
|
|
role="bold">No</emphasis>. When set to <emphasis
|
|
role="bold">Yes</emphasis> or <emphasis role="bold">yes</emphasis>,
|
|
Shorewall may be started. Used as a guard against Shorewall being
|
|
accidentally started before it has been configured.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">SUBSYSLOCK=</emphasis>[<emphasis>pathname</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>This parameter should be set to the name of a file that the
|
|
firewall should create if it starts successfully and remove when it
|
|
stops. Creating and removing this file allows Shorewall to work with
|
|
your distribution's initscripts. For RedHat, this should be set to
|
|
/var/lock/subsys/shorewall. For Debian, the value is
|
|
/var/state/shorewall and in LEAF it is /var/run/shorwall.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">TC_ENABLED=</emphasis>[<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis
|
|
role="bold">No</emphasis>|<emphasis
|
|
role="bold">Internal</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>If you say <emphasis role="bold">Yes</emphasis> or <emphasis
|
|
role="bold">yes</emphasis> here, Shorewall will use a script that
|
|
you supply to configure traffic shaping. The script must be named
|
|
'tcstart' and must be placed in a directory on your
|
|
CONFIG_PATH.</para>
|
|
|
|
<para>If you say <emphasis role="bold">No</emphasis> or <emphasis
|
|
role="bold">no</emphasis> then traffic shaping is not
|
|
enabled.</para>
|
|
|
|
<para>If you set TC_ENABLED=Internal or internal or leave the option
|
|
empty then Shorewall will use its builtin traffic shaper
|
|
(tc4shorewall written by Arne Bernin.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">TC_EXPERT=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>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 <ulink
|
|
url="shorewall-providers.html">shorewall-providers</ulink>(5).</para>
|
|
|
|
<para>If you know what you are doing, you can set TC_EXPERT=Yes and
|
|
Shorewall will not include these cautionary checks.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">TCP_FLAGS_DISPOSITION=</emphasis>[<emphasis
|
|
role="bold">ACCEPT</emphasis>|<emphasis
|
|
role="bold">DROP</emphasis>|<emphasis
|
|
role="bold">REJECT</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Determines the disposition of TCP packets that fail the checks
|
|
enabled by the <emphasis role="bold">tcpflags</emphasis> interface
|
|
option (see <ulink
|
|
url="shorewall-interfaces.html">shorewall-interfaces</ulink>(5)) and
|
|
must have a value of ACCEPT (accept the packet), REJECT (send an RST
|
|
response) or DROP (ignore the packet). If not set or if set to the
|
|
empty value (e.g., TCP_FLAGS_DISPOSITION="") then
|
|
TCP_FLAGS_DISPOSITION=DROP is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">TCP_FLAGS_LOG_LEVEL=</emphasis>[<emphasis>log-level</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Determines the syslog level for logging packets that fail the
|
|
checks enabled by the tcpflags interface option. The value must be a
|
|
valid syslogd log level. If you don't want to log these packets, set
|
|
to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">USE_ACTIONS=</emphasis>{<emphasis
|
|
role="bold">Yes</emphasis>|<emphasis role="bold">No</emphasis>}</term>
|
|
|
|
<listitem>
|
|
<para>While Shorewall Actions can be very useful, they also require
|
|
a sizable amount of code to implement. By setting USE_ACTIONS=No,
|
|
embedded Shorewall installations can omit the large library
|
|
/usr/share/shorewall/lib.actions.</para>
|
|
|
|
<note>
|
|
<para>USE_ACTIONS=No is not supported by Shorewall-perl.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis
|
|
role="bold">VERBOSITY=</emphasis>[<emphasis>number</emphasis>]</term>
|
|
|
|
<listitem>
|
|
<para>Shorewall has traditionally been very noisy (produced lots of
|
|
output). You may set the default level of verbosity using the
|
|
VERBOSITY OPTION.</para>
|
|
|
|
<para>Values are:</para>
|
|
|
|
<simplelist>
|
|
<member>0 — Silent. You may make it more verbose using the -v
|
|
option</member>
|
|
|
|
<member>1 — Major progress messages displayed</member>
|
|
|
|
<member>2 — All progress messages displayed (pre Shorewall-3.2.0
|
|
behavior)</member>
|
|
</simplelist>
|
|
|
|
<para>If not specified, then 2 is assumed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>FILES</title>
|
|
|
|
<para>/etc/shorewall/shorewall.conf</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See ALSO</title>
|
|
|
|
<para><ulink
|
|
url="http://www.shorewall.net/Documentation.htm#Conf">http://www.shorewall.net/Documentation.htm#Conf</ulink></para>
|
|
|
|
<para>shorewall(8), shorewall-accounting(5), shorewall-actions(5),
|
|
shorewall-blacklist(5), shorewall-hosts(5), shorewall-interfaces(5),
|
|
shorewall-ipsec(5), shorewall-maclist(5), shorewall-masq(5),
|
|
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
|
|
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
|
|
shorewall-route_rules(5), shorewall-routestopped(5), shorewall-rules(5),
|
|
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
|
|
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)</para>
|
|
</refsect1>
|
|
</refentry> |