diff options
author | Dru Lavigne <dru@FreeBSD.org> | 2014-02-21 18:39:20 +0000 |
---|---|---|
committer | Dru Lavigne <dru@FreeBSD.org> | 2014-02-21 18:39:20 +0000 |
commit | 52b27f712ce745e092add894bd58d970086a0758 (patch) | |
tree | 5af3569fc95b67724226ecc78d5aa245688cbcfb /en_US.ISO8859-1/books | |
parent | a9db80d1caf6f92c7e4d08e0f4e8d347fa6e6620 (diff) | |
download | doc-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.xml | 69 |
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> |