Date: Tue, 25 Feb 2014 17:38:33 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44053 - head/en_US.ISO8859-1/books/handbook/firewalls Message-ID: <201402251738.s1PHcXZR026969@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402251738.s1PHcXZR026969>