Add rules man page (incomplete)

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4888 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2006-11-15 21:02:04 +00:00
parent 8cfe659c26
commit 3379252b88

View File

@ -0,0 +1,359 @@
<?xml version="1.0" encoding="UTF-8"?>
<refentry>
<refmeta>
<refentrytitle>shorewall-rules</refentrytitle>
<manvolnum>5</manvolnum>
</refmeta>
<refnamediv>
<refname>rules</refname>
<refpurpose>Shorewall rules file</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>/etc/shorewall/rules</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>Rules in this file govern connection establishment. Requests and
responses are automatically allowed using connection tracking. For any
particular (source,dest) pair of zones, the rules are evaluated in the
order in which they appear in this file and the first match is the one
that determines the disposition of the request.</para>
<para>In most places where an IP address or subnet is allowed, you can
preceed the address/subnet with "!" (e.g., !192.168.1.0/24) to indicate
that the rule matches all addresses except the address/subnet given.
Notice that no white space is permitted between "!" and the
address/subnet.</para>
<warning>
<para>If you masquerade or use SNAT from a local system to the internet,
you cannot use an ACCEPT rule to allow traffic from the internet to that
system. You *must* use a DNAT rule instead.</para>
</warning>
<para>The rules file is divided into sections. Each section is introduced
by a "Section Header" which is a line beginning with SECTION followed by
the section name.</para>
<para>Sections are as follows and must appear in the order listed:</para>
<variablelist>
<varlistentry>
<term>ESTABLISHED</term>
<listitem>
<para>Packets in the ESTABLISHED state are processed by rules in
this section.</para>
<para>The only ACTIONs allowed in this section are ACCEPT, DROP,
REJECT, LOG and QUEUE</para>
<para>There is an implicit ACCEPT rule inserted at the end of this
section.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>RELATED</term>
<listitem>
<para>Packets in the RELATED state are processed by rules in this
section.</para>
<para>The only ACTIONs allowed in this section are ACCEPT, DROP,
REJECT, LOG and QUEUE</para>
<para>There is an implicit ACCEPT rule inserted at the end of this
section.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>NEW</term>
<listitem>
<para>Packets in the NEW and INVALID states are processed by rules
in this section.</para>
</listitem>
</varlistentry>
</variablelist>
<note>
<para>If you are not familiar with Netfilter to the point where you are
comfortable with the differences between the various connection tracking
states, then I suggest that you omit the ESTABLISHED and RELATED
sections and place all of your rules in the NEW section (That's after
the line that reads SECTION NEW').</para>
</note>
<warning>
<para>If you specify FASTACCEPT=Yes in shorewall.conf(5) then the
ESTABLISHED and RELATED sections must be empty.</para>
</warning>
<para>You may omit any section that you don't need. If no Section Headers
appear in the file then all rules are assumed to be in the NEW section.
</para>
<para>The columns in the file are as follows.</para>
<variablelist>
<varlistentry>
<term>ACTION</term>
<listitem>
<para> ACCEPT, DROP, REJECT, DNAT, DNAT-, REDIRECT, CONTINUE, LOG,
QUEUE, COMMENT, a <emphasis>macro</emphasis>, or an
<emphasis>action</emphasis>.</para>
<variablelist>
<varlistentry>
<term>ACCEPT</term>
<listitem>
<para>Allow the connection request.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ACCEPT+</term>
<listitem>
<para>like ACCEPT but also excludes the connection from any
subsequent DNAT[-] or REDIRECT[-] rules</para>
</listitem>
</varlistentry>
<varlistentry>
<term>NONAT</term>
<listitem>
<para>Excludes the connection from any subsequent <emphasis
role="bold">DNAT</emphasis>[-] or <emphasis
role="bold">REDIRECT</emphasis>[-] rules but doesn't generate
a rule to accept the traffic.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DROP</term>
<listitem>
<para>Ignore the request.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>REJECT</term>
<listitem>
<para>disallow the request and return an icmp-unreachable or
an RST packet.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DNAT</term>
<listitem>
<para>Forward the request to another system (and optionally
another port).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DNAT-</term>
<listitem>
<para>Advanced users only.</para>
<para> Like DNAT but only generates the DNAT iptables rule and
not the companion ACCEPT rule.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SAME</term>
<listitem>
<para>Similar to DNAT except that the port may not be remapped
and when multiple server addresses are listed, all requests
from a given remote system go to the same server.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SAME-</term>
<listitem>
<para>Advanced users only.</para>
<para>Like SAME but only generates the NAT iptables rule and
not the companion ACCEPT rule.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>REDIRECT</term>
<listitem>
<para>Redirect the request to a server on the firewall.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>REDIRECT-</term>
<listitem>
<para>Advanced users only.</para>
<para>Like REDIRET but only generates the REDIRECT iptables
rule and not the companion ACCEPT rule.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>CONTINUE</term>
<listitem>
<para> For experts only.</para>
<para>Do not process any of the following rules for this
(source zone,destination zone). If the source and/or
destination IP address falls into a zone defined later in
shorewall-zones(5), this connection request will be passed to
the rules defined for that (those) zone(s).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LOG</term>
<listitem>
<para>Simply log the packet and continue.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>QUEUE</term>
<listitem>
<para>Queue the packet to a user-space application such as
ftwall (http://p2pwall.sf.net).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>COMMENT</term>
<listitem>
<para>the rest of the line will be attached as a comment to
the Netfilter rule(s) generated by the following entres. The
comment will appear delimited by "/* ... */" in the output of
"shorewall show &lt;chain&gt;". To stop the comment from being
attached to further rules, simply include COMMENT on a line by
itself.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>action</emphasis></term>
<listitem>
<para>The name of an <emphasis>action</emphasis> defined in
shorewall.actions(5) or in
/usr/share/shorewall/actions.std.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>macro</emphasis></term>
<listitem>
<para>The name of a macro defined in a file named macro.If the
macro accepts an action parameter (Look at the macro source to
see if it has PARAM in the TARGET column) then the
<emphasis>macro</emphasis> name is followed by "/" and the
action (ACCEPT, DROP, REJECT, ...) to be substituted for the
parameter.</para>
<para>Example: FTP/ACCEPT.</para>
</listitem>
</varlistentry>
</variablelist>
<para>The ACTION may optionally be followed by ":" and a syslog log
level (e.g, REJECT:info or DNAT:debug). This causes the packet to be
logged at the specified level.</para>
<para>If the ACTION names an <emphasis>action</emphasis> defined in
shorewall.actions(5) or in /usr/share/shorewall/actions.std
then:</para>
<itemizedlist>
<listitem>
<para>If the log level is followed by "!' then all rules in the
action are logged at the log level.</para>
</listitem>
<listitem>
<para>If the log level is not followed by "!" then only those
rules in the action that do not specify logging are logged at
the specified level.</para>
</listitem>
<listitem>
<para>The special log level 'none!' suppresses logging by the
action.</para>
</listitem>
</itemizedlist>
<para>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
(http://www.gnumonks.org/projects/ulogd).</para>
<para>Actions specifying logging may be followed by a log tag (a
string of alphanumeric characters) are appended to the string
generated by the LOGPREFIX (in shorewall.conf(5)).</para>
<para>Example: ACCEPT:info:ftp would include 'ftp ' at the end of
the log prefix generated by the LOGPREFIX setting.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Example</title>
<para></para>
</refsect1>
<refsect1>
<title>FILES</title>
<para>/etc/shorewall/</para>
</refsect1>
<refsect1>
<title>See ALSO</title>
<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_routes(5), shorewall-routestopped(5), shorewall.conf(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)</para>
</refsect1>
</refentry>