svn commit: r44053 - head/en_US.ISO8859-1/books/handbook/firewalls
Dru Lavigne
dru at FreeBSD.org
Tue Feb 25 17:38:33 UTC 2014
Author: dru
Date: Tue Feb 25 17:38:33 2014
New Revision: 44053
URL: http://svnweb.freebsd.org/changeset/doc/44053
Log:
Move the IPF chapter after the IPFW chapter.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 25 17:30:26 2014 (r44052)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 25 17:38:33 2014 (r44053)
@@ -79,9 +79,8 @@
<para>&os; has three firewalls built into the base system:
<application>PF</application>,
- <application>IPFILTER</application>, also known as
- <application>IPF</application>, and
- <application>IPFW</application>.
+ <application>IPFW</application>, and <application>IPFILTER</application>, also known as
+ <application>IPF</application>.
&os; also provides two traffic shapers for controlling bandwidth
usage: &man.altq.4; and &man.dummynet.4;.
<application>ALTQ</application> has
@@ -117,12 +116,12 @@
<listitem>
<para>How to use and configure the
- <application>IPFILTER</application> firewall.</para>
+ <application>IPFW</application> firewall.</para>
</listitem>
<listitem>
<para>How to use and configure the
- <application>IPFW</application> firewall.</para>
+ <application>IPFILTER</application> firewall.</para>
</listitem>
</itemizedlist>
@@ -1585,2294 +1584,2294 @@ block drop out quick on $ext_if from any
</sect2>
</sect1>
- <sect1 xml:id="firewalls-ipf">
- <title>IPFILTER (IPF)</title>
+ <sect1 xml:id="firewalls-ipfw">
+ <title>IPFW</title>
<indexterm>
<primary>firewall</primary>
- <secondary><application>IPFILTER</application></secondary>
+ <secondary>IPFW</secondary>
</indexterm>
- <para><application>IPFILTER</application>, also known as
- <application>IPF</application>, is a cross-platform, open source
- firewall which has been ported to several operating systems,
- including &os;, NetBSD, OpenBSD, and &solaris;.</para>
-
- <para><application>IPFILTER</application> is a kernel-side
- firewall and <acronym>NAT</acronym> mechanism that can be
- controlled and monitored by userland programs. Firewall rules
- can be set or deleted using <application>ipf</application>,
- <acronym>NAT</acronym> rules can be set or deleted using
- <application>ipnat</application>, run-time statistics for the
- kernel parts of <application>IPFILTER</application> can be
- printed using <application>ipfstat</application>, and
- <application>ipmon</application> can be used to log
- <application>IPFILTER</application> actions to the system log
- files.</para>
-
- <para><application>IPF</application> was originally written using
- a rule processing logic of <quote>the last matching rule
- wins</quote> and only used stateless rules. Since then,
- <application>IPF</application> has been enhanced to include the
- <literal>quick</literal> and <literal>keep state</literal>
- options.</para>
-
- <para>For a detailed explanation of the legacy rules processing
- method, refer to <uri
- xlink:href="http://coombs.anu.edu.au/~avalon/ip-filter.html">http://coombs.anu.edu.au/~avalon/ip-filter.html</uri>.</para>
+ <para><acronym>IPFW</acronym> is a stateful firewall written for
+ &os; which also provides a traffic shaper, packet scheduler,
+ and in-kernel NAT.</para>
- <para>The <application>IPF</application> FAQ is at <uri
- xlink:href="http://www.phildev.net/ipf/index.html">http://www.phildev.net/ipf/index.html</uri>.
- A searchable archive of the IPFilter mailing list is available
- at <uri
- xlink:href="http://marc.info/?l=ipfilter">http://marc.info/?l=ipfilter</uri>.</para>
+ <para>&os; provides a sample ruleset in
+ <filename>/etc/rc.firewall</filename>. The sample ruleset
+ define several firewall types for common scenarios to assist
+ novice users in generating an appropriate ruleset.
+ &man.ipfw.8; provides a powerful syntax which advanced users can
+ use to craft customized rulesets that meet the security
+ requirements of a given environment.</para>
- <para>This section of the Handbook focuses on
- <application>IPF</application> as it pertains to FreeBSD. It
- provides examples of rules that contain the
- <literal>quick</literal> and <literal>keep state</literal>
- options.</para>
+ <para>IPFW is composed of several components: the kernel firewall
+ filter rule processor and its integrated packet accounting
+ facility, the logging facility, the
+ <literal>divert</literal> rule which triggers
+ <acronym>NAT</acronym>, the dummynet traffic shaper facilities,
+ the <literal>fwd rule</literal> forward facility, the bridge
+ facility, and the ipstealth facility. IPFW supports both IPv4
+ and IPv6.</para>
- <sect2>
- <title>Enabling <application>IPF</application></title>
+ <sect2 xml:id="firewalls-ipfw-enable">
+ <title>Enabling IPFW</title>
<indexterm>
- <primary><application>IPFILTER</application></primary>
+ <primary>IPFW</primary>
<secondary>enabling</secondary>
</indexterm>
- <para><application>IPF</application> is included in the basic
- &os; install as a kernel loadable module, meaning that a
- custom kernel is not needed in order to enable
- <application>IPF</application>.</para>
+ <para>IPFW is included in the basic &os; install as a run time
+ loadable module. The system will dynamically load the kernel
+ module when <filename>rc.conf</filename> contains the
+ statement <literal>firewall_enable="YES"</literal>. After
+ rebooting the system, the following white highlighted message
+ is displayed on the screen as part of the boot process:</para>
+
+ <screen>ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled</screen>
+
+ <para>The loadable module includes logging ability. To enable
+ logging and set the verbose logging limit, add these
+ statements to
+ <filename>/etc/sysctl.conf</filename> before rebooting:</para>
+
+ <programlisting>net.inet.ip.fw.verbose=1
+net.inet.ip.fw.verbose_limit=5</programlisting>
+ </sect2>
+
+ <sect2 xml:id="firewalls-ipfw-kernel">
+ <title>Kernel Options</title>
<indexterm>
<primary>kernel options</primary>
- <secondary><application>IPFILTER</application></secondary>
+ <secondary>IPFIREWALL</secondary>
</indexterm>
<indexterm>
<primary>kernel options</primary>
- <secondary>IPFILTER_LOG</secondary>
+ <secondary>IPFIREWALL_VERBOSE</secondary>
</indexterm>
<indexterm>
<primary>kernel options</primary>
- <secondary>IPFILTER_DEFAULT_BLOCK</secondary>
+ <secondary>IPFIREWALL_VERBOSE_LIMIT</secondary>
</indexterm>
<indexterm>
- <primary><application>IPFILTER</application></primary>
+ <primary>IPFW</primary>
<secondary>kernel options</secondary>
</indexterm>
- <para>For users who prefer to statically compile
- <application>IPF</application> support into a custom kernel,
- refer to the instructions in <xref linkend="kernelconfig"/>.
- The following kernel options are available:</para>
-
- <programlisting>options IPFILTER
-options IPFILTER_LOG
-options IPFILTER_LOOKUP
-options IPFILTER_DEFAULT_BLOCK</programlisting>
-
- <para>where <literal>options IPFILTER</literal> enables support
- for <application>IPFILTER</application>,
- <literal>options IPFILTER_LOG</literal> enables
- <application>IPF</application> logging using the
- <filename>ipl</filename> packet logging pseudo-device for
- every rule that has the <literal>log</literal> keyword,
- <literal>IPFILTER_LOOKUP</literal> enables
- <acronym>IP</acronym> pools in order to speed up
- <acronym>IP</acronym> lookups, and <literal>options
- IPFILTER_DEFAULT_BLOCK</literal> changes the default
- behavior so that any packet not matching a firewall
- <literal>pass</literal> rule gets blocked.</para>
-
- <para>To configure the system to enable
- <application>IPF</application> at boot time, add the following
- entries to <filename>/etc/rc.conf</filename>. These entries
- will also enable logging and <literal>default pass
- all</literal>. To change the default policy to
- <literal>block all</literal> without compiling a custom
- kernel, remember to add a <literal>block all</literal> rule at
- the end of the ruleset.</para>
-
- <programlisting>ipfilter_enable="YES" # Start ipf firewall
-ipfilter_rules="/etc/ipf.rules" # loads rules definition text file
-ipmon_enable="YES" # Start IP monitor log
-ipmon_flags="-Ds" # D = start as daemon
- # s = log to syslog
- # v = log tcp window, ack, seq
- # n = map IP & port to names</programlisting>
+ <para>For those users who wish to statically compile kernel
+ IPFW support, the following options are available for the
+ custom kernel configuration file:</para>
- <para>If <acronym>NAT</acronym> functionality is needed, also
- add these lines:</para>
+ <programlisting>options IPFIREWALL</programlisting>
- <programlisting>gateway_enable="YES" # Enable as LAN gateway
-ipnat_enable="YES" # Start ipnat function
-ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlisting>
+ <para>This option enables IPFW as part of the kernel.</para>
- <para>Then, to start <application>IPF</application> now:</para>
+ <programlisting>options IPFIREWALL_VERBOSE</programlisting>
- <programlisting>&prompt.root; <userinput>service ipfilter start</userinput></programlisting>
+ <para>This option enables logging of packets that pass through
+ IPFW and have the <literal>log</literal> keyword specified in
+ the ruleset.</para>
- <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>
+ <programlisting>options IPFIREWALL_VERBOSE_LIMIT=5</programlisting>
- <screen>&prompt.root; <userinput>ipf -Fa -f /etc/ipf.rules</userinput></screen>
+ <para>This option limits the number of packets logged through
+ &man.syslogd.8;, on a per-entry basis. This option may be
+ used in hostile environments, when firewall activity logging
+ is desired. This will close a possible denial of service
+ attack via syslog flooding.</para>
- <para>where <option>-Fa</option> flushes all the internal rules
- tables and <option>-f</option> specifies the file containing
- the rules to load.</para>
+ <indexterm>
+ <primary>kernel options</primary>
- <para>This provides the ability to make changes to a custom
- ruleset and update the running firewall with a fresh copy of
- the rules without having to reboot the system. This method is
- convenient for testing new rules as the procedure can be
- executed as many times as needed.</para>
+ <secondary>IPFIREWALL_DEFAULT_TO_ACCEPT</secondary>
+ </indexterm>
- <para>Refer to &man.ipf.8; for details on the other flags
- available with this command.</para>
- </sect2>
+ <programlisting>options IPFIREWALL_DEFAULT_TO_ACCEPT</programlisting>
- <sect2>
- <title><application>IPF</application> Rule Syntax</title>
+ <para>This option allows everything to pass through the firewall
+ by default, which is a good idea when the firewall is being
+ set up for the first time.</para>
<indexterm>
- <primary><application>IPFILTER</application></primary>
+ <primary>kernel options</primary>
- <secondary>rule syntax</secondary>
+ <secondary>IPDIVERT</secondary>
</indexterm>
- <para>This section describes the <application>IPF</application>
- rule syntax used to create stateful rules. When creating
- rules, keep in mind that unless the <literal>quick</literal>
- keyword appears in a rule, every rule is read in order, with
- the <emphasis>last matching rule</emphasis> being the one
- that is applied. This means that 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. Sample rulesets can be found in
- <filename
- class="directory">/usr/share/examples/ipfilter</filename>.</para>
+ <programlisting>options IPDIVERT</programlisting>
- <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 that rule's function, or on its own
- line. Any blank lines are ignored.</para>
+ <para>This option enables the use of <acronym>NAT</acronym>
+ functionality.</para>
- <para>The keywords which are used in rules must be written in a
- specific order, from left to right. Some keywords are
- mandatory while others are optional. Some keywords have
- sub-options which may be keywords themselves and also include
- more sub-options. The keyword order is as follows, where the
- words shown in uppercase represent a variable and the words
- shown in lowercase must precede the variable that follows
- it:</para>
+ <note>
+ <para>The firewall will block all incoming and outgoing
+ packets if either the
+ <literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal> kernel
+ option or a rule to explicitly allow these connections is
+ missing.</para>
+ </note>
+ </sect2>
- <para><replaceable>ACTION DIRECTION OPTIONS proto PROTO_TYPE
- from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT
- TCP_FLAG|ICMP_TYPE keep state STATE</replaceable></para>
+ <sect2 xml:id="firewalls-ipfw-rc">
+ <title><filename>/etc/rc.conf</filename> Options</title>
- <para>This section describes each of these keywords and their
- options. It is not an exhaustive list of every possible
- option. Refer to &man.ipf.5; for a complete description of
- the rule syntax that can be used when creating
- <application>IPF</application> rules and examples for using
- each keyword.</para>
+ <para>Enables the firewall:</para>
- <variablelist>
- <varlistentry>
- <term>ACTION</term>
- <listitem>
- <para>The action keyword indicates what to do with the
- packet if it matches that rule. Every rule
- <emphasis>must</emphasis> have an action. The
- following actions are recognized:</para>
+ <programlisting>firewall_enable="YES"</programlisting>
- <para><literal>block</literal>: drops the packet.</para>
+ <para>To select one of the default firewall types provided by
+ &os;, select one by reading
+ <filename>/etc/rc.firewall</filename> and specify it in
+ the following:</para>
- <para><literal>pass</literal>: allows the packet.</para>
+ <programlisting>firewall_type="open"</programlisting>
- <para><literal>log</literal>: generates a log
- record.</para>
+ <para>Available values for this setting are:</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>
+ <itemizedlist>
+ <listitem>
+ <para><literal>open</literal>: passes all traffic.</para>
+ </listitem>
+ <listitem>
+ <para><literal>client</literal>: protects only this
+ machine.</para>
+ </listitem>
+ <listitem>
+ <para><literal>simple</literal>: protects the whole
+ network.</para>
+ </listitem>
+ <listitem>
+ <para><literal>closed</literal>: entirely disables IP
+ traffic except for the loopback interface.</para>
+ </listitem>
+ <listitem>
+ <para><literal>UNKNOWN</literal>: disables the loading of
+ firewall rules.</para>
+ </listitem>
+ <listitem>
+ <para><filename>filename</filename>:
+ absolute path of the file containing the firewall
+ rules.</para>
+ </listitem>
+ </itemizedlist>
- <para><literal>auth</literal>: queues the packet for
- further processing by another program.</para>
+ <para>Two methods are available for loading custom
+ <application>ipfw</application> rules. One is to set the
+ <literal>firewall_type</literal> variable to the absolute
+ path of the file which contains the firewall rules.</para>
- <para><literal>call</literal>: provides access to
- functions built into <application>IPF</application> that
- allow more complex actions.</para>
+ <para>The other method is to set the
+ <literal>firewall_script</literal> variable to the absolute
+ path of an executable script that includes
+ <command>ipfw</command> commands. A ruleset script that
+ blocks all incoming and outgoing traffic would look like
+ this:</para>
- <para><literal>decapsulate</literal>: removes any headers
- in order to process the contents of the packet.</para>
- </listitem>
- </varlistentry>
+ <programlisting>#!/bin/sh
- <varlistentry>
- <term>DIRECTION</term>
- <listitem>
- <para>Next, each rule must explicitly state the direction
- of traffic using one of these keywords:</para>
+ipfw -q flush
- <para><literal>in</literal>: the rule is applied against
- an inbound packet.</para>
+ipfw add deny in
+ipfw add deny out</programlisting>
- <para><literal>out</literal>: the rule is applied against
- an outbound packet.</para>
+ <note>
+ <para>If <literal>firewall_type</literal> is set to either
+ <literal>client</literal> or <literal>simple</literal>,
+ modify the default rules found in
+ <filename>/etc/rc.firewall</filename> to fit the
+ configuration of the system. The examples used in this
+ section assume that the <literal>firewall_script</literal>
+ is set to <filename>/etc/ipfw.rules</filename>.</para>
+ </note>
- <para><literal>all</literal>: the rule applies to either
- direction.</para>
+ <para>Enable logging:</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>
+ <programlisting>firewall_logging="YES"</programlisting>
- <varlistentry>
- <term>OPTIONS</term>
- <listitem>
- <para>Options are optional. However, if multiple options
- are specified, they must be used in the order shown
- here.</para>
+ <warning>
+ <para><varname>firewall_logging</varname> sets the
+ <varname>net.inet.ip.fw.verbose</varname> sysctl
+ variable to the value of <literal>1</literal>. There is no
+ <filename>rc.conf</filename> variable to set log
+ limitations, but the desired value can be set using
+ <command>sysctl</command> or by adding the following
+ variable and desired value to
+ <filename>/etc/sysctl.conf</filename>:</para>
- <para><literal>log</literal>: when performing the
- specified ACTION, the contents of the packet's headers
- will be written to the &man.ipl.4; packet log
- pseudo-device.</para>
+ <programlisting>net.inet.ip.fw.verbose_limit=5</programlisting>
+ </warning>
- <para><literal>quick</literal>: if a packet matches this
- rule, the ACTION specified by the rule occurs and no
- further processing of any following rules will occur for
- this packet.</para>
+ <para>If the machine is acting as a gateway providing
+ <acronym>NAT</acronym> using &man.natd.8;,
+ refer to <xref linkend="network-natd"/> for information
+ regarding the required <filename>/etc/rc.conf</filename>
+ options.</para>
+ </sect2>
- <para><literal>on</literal>: must be followed by the
- interface name as displayed by &man.ifconfig.8;. The
- rule will only match if the packet is going through the
- specified interface in the specified direction.</para>
+ <sect2 xml:id="firewalls-ipfw-cmd">
+ <title>The IPFW Command</title>
- <para>When using the
- <literal>log</literal> keyword, the following qualifiers
- may be used in this order:</para>
+ <indexterm><primary><command>ipfw</command></primary></indexterm>
- <para><literal>body</literal>: indicates that the first
- 128 bytes of the packet contents will be logged after
- the headers.</para>
+ <para><command>ipfw</command> can be used to make manual,
+ single rule additions or deletions to the active firewall
+ while it is running. The problem with using this method is
+ that all the changes are lost when the system reboots. It is
+ recommended to instead write all the rules in a file and to
+ use that file to load the rules at boot time and to replace
+ the currently running firewall rules whenever that file
+ changes.</para>
- <para><literal>first</literal>: if the
- <literal>log</literal> keyword is being used in
- conjunction with a <literal>keep state</literal> option,
- this option is recommended so that only the triggering
- packet is logged and not every packet which matches the
- stateful connection.</para>
+ <para><command>ipfw</command> is a useful way to display the
+ running firewall rules to the console screen. The IPFW
+ accounting facility dynamically creates a counter for each
+ rule that counts each packet that matches the rule. During
+ the process of testing a rule, listing the rule with its
+ counter is one way to determine if the rule is
+ functioning as expected.</para>
- <para>Additional options are available to specify error
- return messages. Refer to &man.ipf.5; for more
- details.</para>
+ <para>To list all the running rules in sequence:</para>
- </listitem>
- </varlistentry>
+ <screen>&prompt.root; <userinput>ipfw list</userinput></screen>
- <varlistentry>
- <term>PROTO_TYPE</term>
- <listitem>
- <para>The protocol type is optional. However, it is
- mandatory if the rule needs to specify a SRC_PORT or
- a DST_PORT as it defines the type of protocol. When
- specifying the type of protocol, use the
- <literal>proto</literal> keyword followed by either a
- protocol number or name from
- <filename>/etc/protocols</filename>.
- Example protocol names include <literal>tcp</literal>,
- <literal>udp</literal>, or <literal>icmp</literal>. If
- PROTO_TYPE is specified but no SRC_PORT or DST_PORT is
- specified, all port numbers for that protocol will match
- that rule.</para>
- </listitem>
- </varlistentry>
+ <para>To list all the running rules with a time stamp of when
+ the last time the rule was matched:</para>
- <varlistentry>
- <term>SRC_ADDR</term>
- <listitem>
- <para>The <literal>from</literal> keyword is mandatory and
- is followed by a keyword which represents the source of
- the packet. The source can be a hostname, an
- <acronym>IP</acronym> address followed by the
- <acronym>CIDR</acronym> mask, an address pool, or the
- keyword <literal>all</literal>. Refer to &man.ipf.5;
- for examples.</para>
+ <screen>&prompt.root; <userinput>ipfw -t list</userinput></screen>
- <para>There is no way to match ranges of
- <acronym>IP</acronym> addresses which do not express
- themselves easily using the dotted numeric form /
- mask-length notation. The
- <package>net-mgmt/ipcalc</package> package or port may
- be used to ease the calculation of the
- <acronym>CIDR</acronym> mask. Additional information is
- available at the utility's web page: <uri
- xlink:href="http://jodies.de/ipcalc">http://jodies.de/ipcalc</uri>.</para>
- </listitem>
- </varlistentry>
+ <para>The next example lists accounting information and the
+ packet count for matched rules along with the rules
+ themselves. The first column is the rule number, followed by
+ the number of matched packets and bytes, followed by the rule
+ itself.</para>
- <varlistentry>
- <term>SRC_PORT</term>
- <listitem>
- <para>The port number of the source is optional. However,
- if it is used, it requires PROTO_TYPE to be first
- defined in the rule. The port number must also be
- preceded by the <literal>proto</literal> keyword.</para>
+ <screen>&prompt.root; <userinput>ipfw -a list</userinput></screen>
- <para>A number of different comparison operators are
- supported: <literal>=</literal> (equal to),
- <literal>!=</literal> (not equal to),
- <literal><</literal> (less than),
- <literal>></literal> (greater than),
- <literal><=</literal> (less than or equal to), and
- <literal>>=</literal> (greater than or equal
- to).</para>
+ <para>To list dynamic rules in addition to static rules:</para>
- <para>To specify port ranges, place the two port numbers
- between <literal><></literal> (less than and
- greater than ), <literal>><</literal> (greater
- than and less than ), or <literal>:</literal> (greater
- than or equal to and less than or equal to).</para>
- </listitem>
- </varlistentry>
+ <screen>&prompt.root; <userinput>ipfw -d list</userinput></screen>
- <varlistentry>
- <term>DST_ADDR</term>
- <listitem>
- <para>The <literal>to</literal> keyword is mandatory and
- is followed by a keyword which represents the
- destination of the packet. Similar to SRC_ADDR, it can
- be a hostname, an <acronym>IP</acronym> address
- followed by the <acronym>CIDR</acronym> mask, an address
- pool, or the keyword <literal>all</literal>.</para>
- </listitem>
- </varlistentry>
+ <para>To also show the expired dynamic rules:</para>
- <varlistentry>
- <term>DST_PORT</term>
- <listitem>
- <para>Similar to SRC_PORT, the port number of the
- destination is optional. However, if it is used, it
- requires PROTO_TYPE to be first defined in the rule.
- The port number must also be preceded by the
- <literal>proto</literal> keyword.</para>
- </listitem>
- </varlistentry>
+ <screen>&prompt.root; <userinput>ipfw -d -e list</userinput></screen>
- <varlistentry>
- <term>TCP_FLAG|ICMP_TYPE</term>
- <listitem>
- <para>If <literal>tcp</literal> is specifed as the
- PROTO_TYPE, flags can be specified as letters, where
- each letter represents one of the possible
- <acronym>TCP</acronym> flags used to determine the state
- of a connection. Possible values are:
- <literal>S</literal> (SYN),
- <literal>A</literal> (ACK),
- <literal>P</literal> (PSH),
- <literal>F</literal> (FIN),
- <literal>U</literal> (URG),
- <literal>R</literal> (RST),
- <literal>C</literal> (CWN), and
- <literal>E</literal> (ECN).</para>
-
- <para>If <literal>icmp</literal> is specifed as the
- PROTO_TYPE, the <acronym>ICMP</acronym> type to match
- can be specified. Refer to &man.ipf.5; for the
- allowable types.</para>
- </listitem>
- </varlistentry>
+ <para>To zero the counters:</para>
- <varlistentry>
- <term>STATE</term>
- <listitem>
- <para>If a <literal>pass</literal> rule contains
- <literal>keep state</literal>,
- <application>IPF</application> will add an entry to its
- dynamic state table and allow subsequent packets that
- match the connection.
- <application>IPF</application> can track state for
- <acronym>TCP</acronym>, <acronym>UDP</acronym>, and
- <acronym>ICMP</acronym> sessions. Any packet that
- <application>IPF</application> can be certain is part of
- an active session, even if it is a different protocol,
- will be allowed.</para>
+ <screen>&prompt.root; <userinput>ipfw zero</userinput></screen>
- <para>In <application>IPF</application>, packets destined
- to go out through the interface connected to the public
- Internet are first checked against the dynamic state
- table. If the packet matches the next expected packet
- comprising an active session conversation, it exits the
- firewall and the state of the session conversation flow
- is updated in the dynamic state table. Packets that do
- not belong to an already active session are checked
- against the outbound ruleset. Packets coming in from
- the interface connected to the public Internet are first
- checked against the dynamic state table. If the packet
- matches the next expected packet comprising an active
- session, it exits the firewall and the state of the
- session conversation flow is updated in the dynamic
- state table. Packets that do not belong to an already
- active session are checked against the inbound
- ruleset.</para>
+ <para>To zero the counters for just the rule with number
+ <replaceable>NUM</replaceable>:</para>
- <para>Several keywords can be added after
- <literal>keep state</literal>. If used, these keywords
- set various options that control stateful filtering,
- such as setting connection limits or connection age.
- Refer to &man.ipf.5; for the list of available options
- and their descriptions.</para>
- </listitem>
- </varlistentry>
- </variablelist>
+ <screen>&prompt.root; <userinput>ipfw zero NUM</userinput></screen>
</sect2>
- <sect2>
- <title>Example Ruleset</title>
+ <sect2 xml:id="firewalls-ipfw-rules">
+ <title>IPFW Rulesets</title>
- <para>This section demonstrates how to create an example ruleset
- which only allows services matching
- <literal>pass</literal> rules and blocks all others.</para>
+ <indexterm>
+ <primary>IPFW</primary>
- <para>&os; uses the loopback interface
- (<filename>lo0</filename>) and the <acronym>IP</acronym>
- address <systemitem class="ipaddress">127.0.0.1</systemitem>
- for internal communication. The firewall ruleset must contain
- rules to allow free movement of these internally used
- packets:</para>
+ <secondary>rule processing order</secondary>
+ </indexterm>
- <programlisting># no restrictions on loopback interface
-pass in quick on lo0 all
-pass out quick on lo0 all</programlisting>
+ <para>When a packet enters the <acronym>IPFW</acronym> firewall,
+ it is compared against the first rule in the ruleset and
+ progresses one rule at a time, moving from top to bottom of
+ the set in ascending rule number sequence order. When the
+ packet matches the selection parameters of a rule, the rule's
+ action field value is executed and the search of the ruleset
+ terminates for that packet. This is referred to as
+ <quote>first match wins</quote>. If the packet does not match
+ any of the rules, it gets caught by the mandatory IPFW default
+ rule, number 65535, which denies all packets and silently
+ discards them. However, if the packet matches a rule that
+ contains the <literal>count</literal>,
+ <literal>skipto</literal>, or <literal>tee</literal> keywords,
+ the search continues. Refer to &man.ipfw.8; for details on
+ how these keywords affect rule processing.</para>
- <para>The public interface connected to the Internet is used to
- authorize and control access of all outbound and inbound
- connections. If one or more interfaces are cabled to private
- networks, those internal interfaces may require rules to allow
- packets originating from the <acronym>LAN</acronym> to flow
- between the internal networks or to the interface attached to
- the Internet. The ruleset should be organized into three
- major sections: any trusted internal interfaces, outbound
- connections through the public interface, and inbound
- connections through the public interface.</para>
+ <para>The examples in this section create an inclusive type
+ firewall ruleset containing the stateful <literal>keep
+ state</literal>, <literal>limit</literal>,
+ <literal>in</literal>, <literal>out</literal> and
+ <literal>via</literal> options. For a complete rule syntax
+ description, refer to &man.ipfw.8;.</para>
- <para>These two rules allow all traffic to pass through a
- trusted <acronym>LAN</acronym> interface named
- <filename>xl0</filename>:</para>
+ <warning>
+ <para>Be careful when working with firewall rules, as it is
+ easy to lock out even the administrator.</para>
+ </warning>
- <programlisting># no restrictions on inside LAN interface for private network
-pass out quick on xl0 all
-pass in quick on xl0 all</programlisting>
+ <sect3 xml:id="firewalls-ipfw-rules-syntax">
+ <title>Rule Syntax</title>
- <para>The rules for the public interface's outbound and inbound
- sections should have the most frequently matched rules placed
- before less commonly matched rules, with the last rule in the
- section blocking and logging all packets for that interface
- and direction.</para>
+ <indexterm>
+ <primary>IPFW</primary>
- <para>This set of rules defines the outbound section of the
- public interface named <filename>dc0</filename>. These rules
- keep state and identify the specific services that internal
- systems are authorized for public Internet access. All the
- rules use <literal>quick</literal> and specify the
- appropriate port numbers and, where applicable, destination
- addresses.</para>
+ <secondary>rule syntax</secondary>
+ </indexterm>
- <programlisting># interface facing Internet (outbound)
-# Matches session start requests originating from or behind the
-# firewall, destined for the Internet.
+ <para>This section describes the keywords which comprise an
+ <acronym>IPFW</acronym> rule. Keywords must be written in
+ the following order. <literal>#</literal> is used to mark
+ the start of a comment and may appear at the end of a rule
+ line or on its own line. Blank lines are ignored.</para>
-# Allow outbound access to public DNS servers.
-# Replace x.x.x. with address listed in /etc/resolv.conf.
-# Repeat for each DNS server.
-pass out quick on dc0 proto tcp from any to x.x.x. port = 53 flags S keep state
-pass out quick on dc0 proto udp from any to xxx port = 53 keep state
+ <para><replaceable>CMD RULE_NUMBER ACTION LOGGING SELECTION
+ STATEFUL</replaceable></para>
-# Allow access to ISP's specified DHCP server for cable or DSL networks.
-# Use the first rule, then check log for the IP address of DHCP server.
-# Then, uncomment the second rule, replace z.z.z.z with the IP address,
-# and comment out the first rule
-pass out log quick on dc0 proto udp from any to any port = 67 keep state
-#pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state
+ <sect4>
+ <title>CMD</title>
-# Allow HTTP and HTTPS
-pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state
-pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state
+ <para>Each new rule has to be prefixed with
+ <parameter>add</parameter> to add the rule to the internal
+ table.</para>
+ </sect4>
-# Allow email
-pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state
-pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state
+ <sect4>
+ <title>RULE_NUMBER</title>
-# Allow NTP
-pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state
+ <para>Each rule is associated with a rule_number in the
+ range of <literal>1</literal> to
+ <literal>65535</literal>.</para>
+ </sect4>
-# Allow FTP
-pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state
+ <sect4>
+ <title>ACTION</title>
-# Allow SSH
-pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state
+ <para>A rule can be associated with one of the following
+ actions. The specified action will be executed when the
+ packet matches the selection criterion of the rule.</para>
-# Allow ping
-pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state
+ <para><parameter>allow | accept | pass |
+ permit</parameter></para>
-# Block and log everything else
-block out log first quick on dc0 all</programlisting>
+ <para>These keywords are equivalent as they allow packets
+ that match the rule to exit the firewall rule processing.
+ The search terminates at this rule.</para>
- <para>This example of the rules in the inbound section of the
- public interface blocks all undesirable packets first. This
- reduces the number of packets that are logged by the last
- rule.</para>
+ <para><parameter>check-state</parameter></para>
- <programlisting># interface facing Internet (inbound)
-# Block all inbound traffic from non-routable or reserved address spaces
-block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918 private IP
-block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918 private IP
-block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918 private IP
-block in quick on dc0 from 127.0.0.0/8 to any #loopback
-block in quick on dc0 from 0.0.0.0/8 to any #loopback
-block in quick on dc0 from 169.254.0.0/16 to any #DHCP auto-config
-block in quick on dc0 from 192.0.2.0/24 to any #reserved for docs
-block in quick on dc0 from 204.152.64.0/23 to any #Sun cluster interconnect
-block in quick on dc0 from 224.0.0.0/3 to any #Class D & E multicast
+ <para>Checks the packet against the dynamic rules table.
+ If a match is found, execute the action associated with
+ the rule which generated this dynamic rule, otherwise
+ move to the next rule. A <literal>check-state</literal>
+ rule does not have selection criterion. If no
+ <literal>check-state</literal> rule is present in the
+ ruleset, the dynamic rules table is checked at the first
+ <literal>keep-state</literal> or <literal>limit</literal>
+ rule.</para>
-# Block fragments and too short tcp packets
-block in quick on dc0 all with frags
-block in quick on dc0 proto tcp all with short
+ <para><parameter>deny | drop</parameter></para>
-# block source routed packets
-block in quick on dc0 all with opt lsrr
-block in quick on dc0 all with opt ssrr
+ <para>Both words mean the same thing, which is to discard
+ packets that match this rule. The search
+ terminates.</para>
+ </sect4>
-# Block OS fingerprint attempts and log first occurrence
-block in log first quick on dc0 proto tcp from any to any flags FUP
+ <sect4>
+ <title>Logging</title>
-# Block anything with special options
-block in quick on dc0 all with ipopts
+ <para>When a packet matches a rule with the
+ <literal>log</literal> keyword, a message will be logged
+ to &man.syslogd.8; with a facility name of
+ <literal>SECURITY</literal>. Logging only occurs if the
+ number of packets logged for that particular rule does not
+ exceed the <literal>logamount</literal> parameter. If no
+ <literal>logamount</literal> is specified, the limit is
+ taken from the <command>sysctl</command> value of
+ <varname>net.inet.ip.fw.verbose_limit</varname>. In both
+ cases, a value of zero removes the logging limit. Once
+ the limit is reached, logging can be re-enabled by
+ clearing the logging counter or the packet counter for
+ that rule, using <command>ipfw reset log</command>.</para>
-# Block public pings and ident
-block in quick on dc0 proto icmp all icmp-type 8
-block in quick on dc0 proto tcp from any to any port = 113
+ <note>
+ <para>Logging is done after all other packet matching
+ conditions have been met, and before performing the
+ final action on the packet. The administrator decides
+ which rules to enable logging on.</para>
+ </note>
+ </sect4>
-# Block incoming Netbios services
-block in log first quick on dc0 proto tcp/udp from any to any port = 137
-block in log first quick on dc0 proto tcp/udp from any to any port = 138
-block in log first quick on dc0 proto tcp/udp from any to any port = 139
-block in log first quick on dc0 proto tcp/udp from any to any port = 81</programlisting>
+ <sect4>
+ <title>Selection</title>
- <para>Any time there are logged messages on a rule with
- the <literal>log first</literal> option, run
- <command>ipfstat -hio</command> to evaluate how many times the
- rule has been matched. A large number of matches may indicate
- that the system is under attack.</para>
+ <para>The keywords described in this section are used to
+ describe attributes of the packet to be checked when
+ determining whether rules match the packet or not.
+ The following general-purpose attributes are provided for
+ matching, and must be used in this order:</para>
- <para>The rest of the rules in the inbound section define which
- connections are allowed to be initiated from the Internet.
- The last rule denies all connections which were not explicitly
- allowed by previous rules in this section.</para>
+ <para><parameter>udp | tcp | icmp</parameter></para>
- <programlisting># Allow traffic in from ISP's DHCP server. Replace z.z.z.z with
-# the same IP address used in the outbound section.
-pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state
+ <para>Any other protocol names found in
+ <filename>/etc/protocols</filename> can be used. The
+ value specified is the protocol to be matched against.
+ This is a mandatory keyword.</para>
-# Allow public connections to specified internal web server
-pass in quick on dc0 proto tcp from any to x.x.x.x port = 80 flags S keep state
+ <para><parameter>from src to dst</parameter></para>
-# Block and log only first occurrence of all remaining traffic.
-block in log first quick on dc0 all</programlisting>
- </sect2>
+ <para>The <literal>from</literal> and <literal>to</literal>
+ keywords are used to match against IP addresses. Rules
+ must specify <emphasis>both</emphasis> source and
+ destination parameters. <literal>any</literal> is a
+ special keyword that matches any IP address.
+ <literal>me</literal> is a special keyword that matches
+ any IP address configured on an interface in the &os;
+ system to represent the PC the firewall is running on.
+ Example usage includes <literal>from me to any</literal>,
+ <literal>from any to me</literal>,
+ <literal>from 0.0.0.0/0 to any</literal>,
+ <literal>from any to 0.0.0.0/0</literal>,
+ <literal>from 0.0.0.0 to any</literal>,
+ <literal>from any to 0.0.0.0</literal>,
+ and <literal>from me to 0.0.0.0</literal>. IP addresses
+ are specified in dotted IP address format followed by the
+ mask in CIDR notation, or as a single host in dotted IP
+ address format. This keyword is a mandatory requirement.
+ The <package>net-mgmt/ipcalc</package> port may be used to
+ assist the mask calculation.</para>
- <sect2>
- <title>Configuring <acronym>NAT</acronym></title>
+ <para><parameter>port number</parameter></para>
- <indexterm><primary>NAT</primary></indexterm>
+ <para>For protocols which support port numbers, such as
+ <acronym>TCP</acronym> and <acronym>UDP</acronym>, it
+ is mandatory to include the port number of the service
+ that will be matched. Service names from
+ <filename>/etc/services</filename> may be used instead
+ of numeric port values.</para>
- <indexterm>
- <primary>IP masquerading</primary>
+ <para><parameter>in | out</parameter></para>
- <see>NAT</see>
- </indexterm>
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-head
mailing list