forked from extern/shorewall_code
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
parent
8cfe659c26
commit
3379252b88
359
manpages/shorewall-rules.xml
Normal file
359
manpages/shorewall-rules.xml
Normal 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 <chain>". 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>
|
||||
Loading…
Reference in New Issue
Block a user