aboutsummaryrefslogtreecommitdiff
path: root/en_US.ISO8859-1/books
diff options
context:
space:
mode:
authorDru Lavigne <dru@FreeBSD.org>2014-02-21 18:39:20 +0000
committerDru Lavigne <dru@FreeBSD.org>2014-02-21 18:39:20 +0000
commit52b27f712ce745e092add894bd58d970086a0758 (patch)
tree5af3569fc95b67724226ecc78d5aa245688cbcfb /en_US.ISO8859-1/books
parenta9db80d1caf6f92c7e4d08e0f4e8d347fa6e6620 (diff)
downloaddoc-52b27f712ce745e092add894bd58d970086a0758.tar.gz
doc-52b27f712ce745e092add894bd58d970086a0758.zip
This section is reeeeeally out of date.
Modernize the first few keywords. Much more to come. Sponsored by: iXsystems
Notes
Notes: svn path=/head/; revision=44018
Diffstat (limited to 'en_US.ISO8859-1/books')
-rw-r--r--en_US.ISO8859-1/books/handbook/firewalls/chapter.xml69
1 files changed, 43 insertions, 26 deletions
diff --git a/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml b/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
index c2096b6597..8220cb7903 100644
--- a/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
+++ b/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
@@ -1659,7 +1659,7 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<programlisting>&prompt.root; <userinput>service ipfilter start</userinput></programlisting>
- <para>To load the ruleset file, specify the name of the file using <command>ipf</command>.
+ <para>To load the firewall rules, specify the name of the ruleset file using <command>ipf</command>.
The following command can
be used to replace the currently running firewall
rules:</para>
@@ -1691,9 +1691,13 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
</indexterm>
<para>This section describes the <application>IPF</application> rule syntax
- used to create stateful rules where the <quote>first
- matching rule wins</quote>. Refer to &man.ipf.8; for more details, including the legacy
- rule syntax.</para>
+ used to create stateful rules. When creating rules, keep in
+ mind that the default way in which filter rules are applied
+ is for the <emphasis>last matching rule</emphasis> to be
+ used. Even if the first rule to match a packet is a
+ <literal>pass</literal>, if there is a later matching rule
+ that is a <literal>block</literal>, the packet will be dropped.
+ Refer to &man.ipf.5; for more details about rule syntax.</para>
<para>When creating rules, a <literal>#</literal> character is used to mark the
start of a comment and may appear at the end of a rule, to explain its function,
@@ -1718,38 +1722,51 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<term>ACTION</term>
<listitem>
<para>The action keyword indicates what to do with the
- packet if it matches the rest of the filter rule. Each
+ packet if it matches that rule. Every
rule <emphasis>must</emphasis> have an action. The
following actions are recognized:</para>
- <para><literal>block</literal> indicates that the packet
- should be dropped if the selection parameters match the
- packet.</para>
+ <para><literal>block</literal>: drops the packet.</para>
+
+ <para><literal>pass</literal>: allows the packet.</para>
+
+ <para><literal>log</literal>: generates a log record.</para>
+
+ <para><literal>count</literal>: counts the number of
+ packets and bytes which can provide an indication of
+ how often a rule is used.</para>
+
+ <para><literal>auth</literal>: queues the packet for
+ further processing by another program.</para>
- <para><literal>pass</literal> indicates that the packet
- should exit the firewall if the selection parameters
- match the packet.</para>
+ <para><literal>call</literal>: provides access to
+ functions built into <application>IPF</application> that
+ allow more complex actions.</para>
+
+ <para><literal>decapsulate</literal>: removes any headers
+ in order to process the contents of the packet.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>IN-OUT</term>
<listitem>
- <para>A mandatory requirement is that each filter rule
- explicitly state which side of the I/O it is to be used
- on. The next keyword must be either
- <literal>in</literal> or <literal>out</literal> and one
- or the other has to be included or the rule will not
- pass syntax checks.</para>
-
- <para><literal>in</literal> means this rule is being
- applied against an inbound packet which has just been
- received on the interface facing the public
- Internet.</para>
-
- <para><literal>out</literal> means this rule is being
- applied against an outbound packet destined for the
- interface facing the public Internet.</para>
+ <para>Next, each rule must
+ explicitly state the direction of traffic using one of
+ these keywords:</para>
+
+ <para><literal>in</literal>: the rule is
+ applied against an inbound packet.</para>
+
+ <para><literal>out</literal>: the rule is
+ applied against an outbound packet.</para>
+
+ <para><literal>all</literal>: the rule applies to either
+ direction.</para>
+
+ <para>If the system has multiple interfaces, the interface
+ can be specified along with the direction. An example would
+ be <literal>in on fxp0</literal>.</para>
</listitem>
</varlistentry>