mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-09 01:04:06 +01:00
531800538d
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5134 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
559 lines
22 KiB
XML
559 lines
22 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">
|
|
<article>
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>Actions</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2005</year>
|
|
|
|
<holder>Thomas M. Eastep</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 url="GnuCopyright.htm">GNU Free Documentation
|
|
License</ulink></quote>.</para>
|
|
</legalnotice>
|
|
</articleinfo>
|
|
|
|
<caution>
|
|
<para>This article applies to Shorewall 3.0 and later. If you are running
|
|
a version of Shorewall earlier than Shorewall 3.0.0 then please see the
|
|
documentation for that release.</para>
|
|
</caution>
|
|
|
|
<section>
|
|
<title>What are Shorewall Actions?</title>
|
|
|
|
<para>Shorewall actions allow a symbolic name to be associated with a
|
|
series of one or more iptables rules. The symbolic name may appear in the
|
|
ACTION column of an <filename><ulink
|
|
url="Documentation.htm#Rules">/etc/shorewall/rules</ulink></filename> file
|
|
entry in which case, the traffic matching that rules file entry will be
|
|
passed to the series of iptables rules named by the action.</para>
|
|
|
|
<para>Actions can be thought of as templates. When an action is invoked in
|
|
an <filename>/etc/shorewall/rules</filename> entry, it may be qualified by
|
|
a logging specification (log level and optionally a log tag). The presence
|
|
of the log level/tag causes a modified series of rules to be generated in
|
|
which each packet/rule match within the action causes a log message to be
|
|
generated.</para>
|
|
|
|
<para>There are three types of Shorewall actions:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Built-in Actions. These actions are known by the Shorewall code
|
|
itself. They are listed in the comments at the top of the file
|
|
<filename>/usr/share/shorewall/actions.std</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Standard Actions. These actions are released as part of
|
|
Shorewall. They are listed in the file
|
|
<filename>/usr/share/shorewall/actions.std</filename> and are defined
|
|
in the corresponding action.* files in <filename
|
|
class="directory">/usr/share/shorewall</filename>. Each
|
|
<filename>action.*</filename> file has a comment at the beginning of
|
|
the file that describes what the action does. As an example, here is
|
|
the definition of the <firstterm>AllowSMB</firstterm> standard action
|
|
from Shorewall version 2.2.</para>
|
|
|
|
<programlisting>#
|
|
# Shorewall 2.2 /usr/share/shorewall/action.AllowSMB
|
|
#
|
|
# Allow Microsoft SMB traffic. You need to invoke this action in
|
|
# both directions.
|
|
#
|
|
######################################################################################
|
|
#TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/
|
|
# PORT PORT(S) LIMIT GROUP
|
|
ACCEPT - - udp 135,445
|
|
ACCEPT - - udp 137:139
|
|
ACCEPT - - udp 1024: 137
|
|
ACCEPT - - tcp 135,139,445
|
|
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
|
|
|
|
<para>If you wish to modify one of the standard actions, do not modify
|
|
the definition in /usr/share/shorewall. Rather, copy the file to
|
|
<filename class="directory">/etc/shorewall</filename> (or somewhere
|
|
else on your CONFIG_PATH) and modify the copy.</para>
|
|
|
|
<para>Standard Actions have been largely replaced by <ulink
|
|
url="Macros.html">macros</ulink> in Shorewall 3.0 and later major
|
|
versions.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>User-defined Actions. These actions are created by end-users.
|
|
They are listed in the file /etc/shorewall/actions and are defined in
|
|
action.* files in /etc/shorewall or in another directory listed in
|
|
your CONFIG_PATH (defined in <ulink
|
|
url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>).</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Enabling the Use of Actions</title>
|
|
|
|
<para>In Shorewall version 3.4 and later, to make use of any of the three
|
|
types of actions you must set the USE_ACTIONS option to Yes in
|
|
<filename>/etc/shorewall/shorewall.conf</filename>.</para>
|
|
</section>
|
|
|
|
<section id="Default">
|
|
<title>Default Actions (Formerly Common Actions)</title>
|
|
|
|
<para>Shorewall allows the association of a <firstterm>default
|
|
action</firstterm> with policies. A separate default action may be
|
|
associated with ACCEPT, DROP and REJECT policies. Default actions provide
|
|
a way to invoke a set of common rules just before the policy is enforced.
|
|
Default actions accomplish two goals:</para>
|
|
|
|
<orderedlist>
|
|
<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>Ensure correct operation. Default actions can also avoid common
|
|
pitfalls like dropping connection requests on port 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<footnote>
|
|
<para>AUTH is actually pretty silly on today's internet but it's
|
|
amazing how many servers still employ it.</para>
|
|
</footnote>.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>If you are running Shorewall 3.2 or earlier, then:</para>
|
|
|
|
<blockquote>
|
|
<para>Shorewall provides default actions for the REJECT and DROP
|
|
policies. The default action for REJECT is named
|
|
<firstterm>Reject</firstterm> and the default action for DROP is named
|
|
<firstterm>Drop</firstterm>. These associations are made through two
|
|
entries in /usr/share/shorewall/actions.std:</para>
|
|
|
|
<programlisting>Drop:DROP #Default Action for DROP policy
|
|
Reject:REJECT #Default Action for REJECT policy</programlisting>
|
|
|
|
<para>These may be overridden by entries in your /etc/shorewall/actions
|
|
file.</para>
|
|
</blockquote>
|
|
|
|
<para>If you are running Shorewall 3.4 or later, then:</para>
|
|
|
|
<blockquote>
|
|
<para>Shorewall supports default actions for the ACCEPT, REJECT, DROP
|
|
and QUEUE policies. These default actions are specified in the
|
|
/etc/shorewall/shorewall.conf file using the ACCEPT_DEFAULT,
|
|
REJECT_DEFAULT, DROP_DEFAULT and QUEUE_DEFAULT options respectively.
|
|
Policies whose default is set to a value of "none" have no default
|
|
action.</para>
|
|
|
|
<para>In addition, the default specified in
|
|
/etc/shorewall/shorewall.conf may be overridden by specifying a
|
|
different default in the POLICY column of <ulink
|
|
url="Documentation.htm#Policy">/etc/shorewall/policy</ulink>.</para>
|
|
</blockquote>
|
|
|
|
<warning>
|
|
<para>Entries in the DROP and REJECT default actions <emphasis
|
|
role="bold">ARE NOT THE CAUSE OF CONNECTION PROBLEMS</emphasis>.
|
|
Remember — default actions are only invoked immediately before the
|
|
packet is going to be dropped or rejected anyway!!!</para>
|
|
</warning>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Defining your own Actions</title>
|
|
|
|
<para>Before defining a new action, you should evaluate whether your goal
|
|
can be best accomplished using an action or a
|
|
<firstterm>macro</firstterm>. See <ulink url="Macros.html">this
|
|
article</ulink> for details.</para>
|
|
|
|
<para>To define a new action:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Add a line to
|
|
<filename><filename>/etc/shorewall/actions</filename></filename> that
|
|
names your new action. Action names must be valid shell variable names
|
|
((must begin with a letter and be composed of letters, digits and
|
|
underscore characters) as well as valid Netfilter chain names. If you
|
|
intend to log from the action, the name must have a maximum of 11
|
|
characters. It is recommended that the name you select for a new
|
|
action begins with a capital letter; that way, the name won't conflict
|
|
with a Shorewall-defined chain name.</para>
|
|
|
|
<para>The name of the action may be optionally followed by a colon
|
|
(<quote>:</quote>) and ACCEPT, DROP or REJECT. When this is done, the
|
|
named action will become the <emphasis>default action </emphasis>for
|
|
policies of type ACCEPT, DROP or REJECT respectively. The default
|
|
action is applied immediately before the policy is enforced (before
|
|
any logging is done under that policy) and is used mainly to suppress
|
|
logging of uninteresting traffic which would otherwise clog your logs.
|
|
The same policy name can appear in multiple actions; the last such
|
|
action for each policy name is the one which Shorewall will
|
|
use.</para>
|
|
|
|
<para>Shorewall includes pre-defined actions for DROP and REJECT --
|
|
see above.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Once you have defined your new action name (ActionName), then
|
|
copy /usr/share/shorewall/action.template to
|
|
<filename>/etc/shorewall/action.ActionName</filename> (for example, if
|
|
your new action name is <quote>Foo</quote> then copy
|
|
<filename>/usr/share/shorewall/action.template</filename> to
|
|
<filename>/etc/shorewall/action.Foo</filename>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Now modify the new file to define the new action.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Columns in the action.template file are as follows:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>TARGET - Must be ACCEPT, DROP, REJECT, LOG, CONTINUE, QUEUE or
|
|
<<emphasis>action</emphasis>> where
|
|
<<emphasis>action</emphasis>> is a previously-defined action
|
|
(that is, it must precede the action being defined in this file in
|
|
your <filename>/etc/shorewall/actions</filename> file). These actions
|
|
have the same meaning as they do in the
|
|
<filename>/etc/shorewall/rules</filename> file (CONTINUE terminates
|
|
processing of the current action and returns to the point where that
|
|
action was invoked). The TARGET may optionally be followed by a colon
|
|
(<quote>:</quote>) and a syslog log level (e.g, REJECT:info or
|
|
ACCEPT:debugging). This causes the packet to be logged at the
|
|
specified level. You may also specify ULOG (must be in upper case) as
|
|
a log level. This will log to the ULOG target for routing to a
|
|
separate log through use of ulogd (<ulink
|
|
url="http://www.netfilter.org/projects/ulogd/index.html">http://www.netfilter.org/projects/ulogd/index.html</ulink>).</para>
|
|
|
|
<para>You may also use a <ulink url="Macros.html">macro</ulink> in
|
|
your action provided that the macro's expansion only results in the
|
|
ACTIONs ACCEPT, DROP, REJECT, LOG, CONTINUE, or QUEUE. See
|
|
<filename>/usr/share/shorewall/Drop</filename> for an example of an
|
|
action that users macros extensively.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>SOURCE - Source hosts to which the rule applies. A
|
|
comma-separated list of subnets and/or hosts. Hosts may be specified
|
|
by IP or MAC address; mac addresses must begin with <quote>~</quote>
|
|
and must use <quote>-</quote> as a separator.</para>
|
|
|
|
<para>Alternatively, clients may be specified by interface name. For
|
|
example, eth1 specifies a client that communicates with the firewall
|
|
system through eth1. This may be optionally followed by another colon
|
|
(<quote>:</quote>) and an IP/MAC/subnet address as described above
|
|
(e.g., eth1:192.168.1.5).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>DEST - Location of Server. Same as above with the exception that
|
|
MAC addresses are not allowed.</para>
|
|
|
|
<para>Unlike in the SOURCE column, you may specify a range of up to
|
|
256 IP addresses using the syntax <<emphasis>first
|
|
ip</emphasis>>-<<emphasis>last ip</emphasis>>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>PROTO - Protocol - Must be <quote>tcp</quote>,
|
|
<quote>udp</quote>, <quote>icmp</quote>, a number, or
|
|
<quote>all</quote>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>DEST PORT(S) - Destination Ports. A comma-separated list of Port
|
|
names (from <filename>/etc/services</filename>), port numbers or port
|
|
ranges; if the protocol is <quote>icmp</quote>, this column is
|
|
interpreted as the destination icmp-type(s).</para>
|
|
|
|
<para>A port range is expressed as <<emphasis>low
|
|
port</emphasis>>:<<emphasis>high port</emphasis>>.</para>
|
|
|
|
<para>This column is ignored if PROTOCOL = all but must be entered if
|
|
any of the following fields are supplied. In that case, it is
|
|
suggested that this field contain <quote>-</quote>.</para>
|
|
|
|
<para>If your kernel contains multi-port match support, then only a
|
|
single Netfilter rule will be generated if in this list and in the
|
|
CLIENT PORT(S) list below:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>There are 15 or less ports listed.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>No port ranges are included.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Otherwise, a separate rule will be generated for each
|
|
port.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>SOURCE PORT(S) - Port(s) used by the client. If omitted, any
|
|
source port is acceptable. Specified as a comma-separated list of port
|
|
names, port numbers or port ranges.</para>
|
|
|
|
<para>If you don't want to restrict client ports but need to specify
|
|
an ADDRESS in the next column, then place "-" in this column.</para>
|
|
|
|
<para>If your kernel contains multi-port match support, then only a
|
|
single Netfilter rule will be generated if in this list and in the
|
|
DEST PORT(S) list above:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>There are 15 or less ports listed.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>No port ranges are included.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Otherwise, a separate rule will be generated for each
|
|
port.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RATE LIMIT - You may rate-limit the rule by placing a value in
|
|
this column:</para>
|
|
|
|
<para><programlisting> <<emphasis>rate</emphasis>>/<<emphasis>interval</emphasis>>[:<<emphasis>burst</emphasis>>]</programlisting>where
|
|
<<emphasis>rate</emphasis>> is the number of connections per
|
|
<<emphasis>interval</emphasis>> (<quote>sec</quote> or
|
|
<quote>min</quote>) and <<emphasis>burst</emphasis>> is the
|
|
largest burst permitted. If no <<emphasis>burst</emphasis>> is
|
|
given, a value of 5 is assumed. There may be no whitespace embedded in
|
|
the specification.</para>
|
|
|
|
<para><programlisting> Example: 10/sec:20</programlisting></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>USER/GROUP - For output rules (those with the firewall as their
|
|
source), you may control connections based on the effective UID and/or
|
|
GID of the process requesting the connection. This column can contain
|
|
any of the following:</para>
|
|
|
|
<simplelist>
|
|
<member>[!]<<emphasis>user number</emphasis>>[:]</member>
|
|
|
|
<member>[!]<<emphasis>user name</emphasis>>[:]</member>
|
|
|
|
<member>[!]:<<emphasis>group number</emphasis>></member>
|
|
|
|
<member>[!]:<<emphasis>group name</emphasis>></member>
|
|
|
|
<member>[!]<<emphasis>user
|
|
number</emphasis>>:<<emphasis>group
|
|
number</emphasis>></member>
|
|
|
|
<member>[!]<<emphasis>user
|
|
name</emphasis>>:<<emphasis>group
|
|
number</emphasis>></member>
|
|
|
|
<member>[!]<<emphasis>user
|
|
inumber</emphasis>>:<<emphasis>group
|
|
name</emphasis>></member>
|
|
|
|
<member>[!]<<emphasis>user
|
|
name</emphasis>>:<<emphasis>group name</emphasis>></member>
|
|
|
|
<member>[!]+<<emphasis>program name</emphasis>> (Note: support
|
|
for this form was removed from Netfilter in kernel version
|
|
2.6.14).</member>
|
|
</simplelist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Omitted column entries should be entered using a dash ("-:).</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<para><filename>/etc/shorewall/actions</filename>:</para>
|
|
|
|
<para><programlisting> LogAndAccept</programlisting><phrase><filename>/etc/shorewall/action.LogAndAccept</filename></phrase><programlisting> LOG:info
|
|
ACCEPT</programlisting></para>
|
|
|
|
<para>To use your action, in <filename>/etc/shorewall/rules</filename> you
|
|
might do something like:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
LogAndAccept loc $FW tcp 22</programlisting>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Actions and Logging</title>
|
|
|
|
<para>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).</para>
|
|
|
|
<para>The extent to which logging of action rules occur is governed by the
|
|
following:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>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.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<para>/etc/shorewall/action.foo</para>
|
|
|
|
<programlisting>#TARGET SOURCE DEST PROTO DEST PORT(S)
|
|
ACCEPT - - tcp 22
|
|
bar:info</programlisting>
|
|
|
|
<para>/etc/shorewall/rules:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
foo:debug $FW net</programlisting>
|
|
|
|
<para>Logging in the invoke 'foo' action will be as if foo had been
|
|
defined as:</para>
|
|
|
|
<programlisting>#TARGET SOURCE DEST PROTO DEST PORT(S)
|
|
ACCEPT:debug - - tcp 22
|
|
bar:info</programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you follow the log level with "!" then logging will be at
|
|
that level for all rules recursively invoked by the action.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<para>/etc/shorewall/action.foo</para>
|
|
|
|
<programlisting>#TARGET SOURCE DEST PROTO DEST PORT(S)
|
|
ACCEPT - - tcp 22
|
|
bar:info</programlisting>
|
|
|
|
<para>/etc/shorewall/rules:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
foo:debug! $FW net</programlisting>
|
|
|
|
<para>Logging in the invoke 'foo' action will be as if foo had been
|
|
defined as:</para>
|
|
|
|
<programlisting>#TARGET SOURCE DEST PROTO DEST PORT(S)
|
|
ACCEPT:debug - - tcp 22
|
|
bar:debug</programlisting>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>The change in Shorewall 2.1.2 has an effect on extension scripts
|
|
used with user-defined actions. If you define an action 'acton' and you
|
|
have an <filename>/etc/shorewall/acton</filename> script then when that
|
|
script is invoked, the following three variables will be set for use by
|
|
the script:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>$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.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>$LEVEL = Log level. If empty, no logging was specified.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>$TAG = Log Tag.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Example:</para>
|
|
|
|
<para><filename>/etc/shorewall/rules</filename>:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST
|
|
acton:info:test $FW net</programlisting>
|
|
|
|
<para>Your /etc/shorewall/acton file will be run with:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>$CHAIN="%acton1"</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>$LEVEL="info"</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>$TAG="test"</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>For an example of how to use these variables, see <ulink
|
|
url="PortKnocking.html">this article</ulink>.</para>
|
|
</section>
|
|
|
|
<section id="Extension">
|
|
<title>Creating an Action using an Extension Script</title>
|
|
|
|
<para>There may be cases where you wish to create a chain with rules that
|
|
can't be constructed using the tools defined in the action.template. In
|
|
that case, you can use an extension script.<note>
|
|
<para>If you actually need an action to drop broadcast packets, use
|
|
the <command>dropBcast</command> standard action rather than create
|
|
one like this.</para>
|
|
</note></para>
|
|
|
|
<example>
|
|
<title>An action to drop all broadcast packets</title>
|
|
|
|
<para>/etc/shorewall/actions<programlisting>DropBcasts</programlisting></para>
|
|
|
|
<para>/etc/shorewall/action.DropBcasts<programlisting># This file is empty</programlisting></para>
|
|
|
|
<para>/etc/shorewall/DropBcasts<programlisting>run_iptables -A DropBcasts -m pkttype --pkttype broadcast -j DROP</programlisting></para>
|
|
</example>
|
|
|
|
<para>For a richer example, see <ulink url="PortKnocking.html">this
|
|
article</ulink>.</para>
|
|
</section>
|
|
</article> |