os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

White space fix only. Translators can ignore.

Browse source 
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne 2014-02-19 21:58:48 +00:00
parent dd0a14165c
commit ec7e896314
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=43998
1 changed files with 278 additions and 260 deletions
Download patch file Download diff file Expand all files Collapse all files

334
en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
View file

@ -1508,26 +1508,28 @@ block drop out quick on $ext_if from any to $martians</programlisting>
</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>
<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
<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>
<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><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
@ -1535,15 +1537,16 @@ block drop out quick on $ext_if from any to $martians</programlisting>
<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
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>This section of the Handbook focuses on
<application>IPF</application> as it pertains to FreeBSD.
It provides examples which uses
rules that contain the <literal>quick</literal> and
<literal>keep state</literal> options.</para>
<application>IPF</application> as it pertains to FreeBSD. It
provides examples which uses rules that contain the
<literal>quick</literal> and <literal>keep state</literal>
options.</para>
<sect2>
<title>Enabling <application>IPF</application></title>
@ -1553,9 +1556,10 @@ block drop out quick on $ext_if from any to $martians</programlisting>
<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><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>
<indexterm>
<primary>kernel options</primary>
@ -1581,35 +1585,37 @@ block drop out quick on $ext_if from any to $martians</programlisting>
<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>
<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>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>
<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
@ -1619,8 +1625,8 @@ ipmon_flags="-Ds" # D = start as daemon
# v = log tcp window, ack, seq
# n = map IP &amp; port to names</programlisting>
<para>If <acronym>NAT</acronym>
functionality is needed, also add these lines:</para>
<para>If <acronym>NAT</acronym> functionality is needed, also
add these lines:</para>
<programlisting>gateway_enable="YES" # Enable as LAN gateway
ipnat_enable="YES" # Start ipnat function
@ -1629,7 +1635,6 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<para>Then, to start <application>IPF</application> now:</para>
<programlisting>&prompt.root; <command>service ipfilter start</command></programlisting>
</sect2>
<sect2>
@ -1640,8 +1645,8 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
The bi-directional exchange of packets between hosts comprises
a session conversation. The firewall ruleset processes both
the packets arriving from the public Internet, as well as the
packets produced by the system as a response to them.
Each <acronym>TCP/IP</acronym> service is predefined by its
packets produced by the system as a response to them. Each
<acronym>TCP/IP</acronym> service is predefined by its
protocol and listening port. Packets destined for a specific
service originate from the source address using an
unprivileged port and target the specific service port on the
@ -1730,18 +1735,18 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<varlistentry>
<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 rule
<emphasis>must</emphasis> have an action. The following
actions are recognized:</para>
<para>The action keyword indicates what to do with the
packet if it matches the rest of the filter rule. Each
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>pass</literal> indicates that the packet should
exit the firewall if the selection parameters match the
packet.</para>
<para><literal>pass</literal> indicates that the packet
should exit the firewall if the selection parameters
match the packet.</para>
</listitem>
</varlistentry>
@ -1750,17 +1755,19 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<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>
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>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><literal>out</literal> means this rule is being
applied against an outbound packet destined for the
interface facing the public Internet.</para>
</listitem>
</varlistentry>
@ -1772,35 +1779,39 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
here.</para>
</note>
<para><literal>log</literal> indicates that the packet header
will be written to the &man.ipl.4; packet log pseudo-device
if the selection parameters match the packet.</para>
<para><literal>log</literal> indicates that the packet
header will be written to the &man.ipl.4; packet log
pseudo-device if the selection parameters match the
packet.</para>
<para><literal>quick</literal> indicates that if the selection
parameters match the packet, this rule will be the last
rule checked, and no further processing of any following
rules will occur for this packet.</para>
<para><literal>quick</literal> indicates that if the
selection parameters match the packet, this rule will be
the last rule checked, and no further processing of any
following rules will occur for this packet.</para>
<para><literal>on</literal> indicates the interface name to
be incorporated into the selection parameters. Interface
names are as displayed by &man.ifconfig.8;. Using this
option, the rule will only match if the packet is going
through that interface in the specified direction.</para>
<para><literal>on</literal> indicates the interface name
to be incorporated into the selection parameters.
Interface names are as displayed by &man.ifconfig.8;.
Using this option, the rule will only match if the
packet is going through that interface in the specified
direction.</para>
<para>When a packet is logged, the headers of the packet are
written to the &man.ipl.4; packet logging pseudo-device.
Immediately following the <literal>log</literal> keyword,
the following qualifiers may be used in this order:</para>
<para>When a packet is logged, the headers of the packet
are written to the &man.ipl.4; packet logging
pseudo-device. Immediately following the
<literal>log</literal> keyword, the following qualifiers
may be used in this order:</para>
<para><literal>body</literal> indicates that the first 128
bytes of the packet contents will be logged after the
headers.</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><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>
</listitem>
</varlistentry>
@ -1812,24 +1823,25 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
determining whether or not rules match. There is a
keyword subject, and it has sub-option keywords, one of
which has to be selected. The following general-purpose
attributes are provided for matching, and must be used in
this order:</para>
attributes are provided for matching, and must be used
in this order:</para>
</listitem>
</varlistentry>
<varlistentry>
<term>PROTO</term>
<listitem>
<para><literal>proto</literal> is the subject keyword which
must include one of its corresponding keyword sub-option
values. The sub-option indicates a specific protocol to be
matched against.</para>
<para><literal>proto</literal> is the subject keyword
which must include one of its corresponding keyword
sub-option values. The sub-option indicates a specific
protocol to be matched against.</para>
<para><literal>tcp/udp | udp | tcp | icmp</literal> or any
protocol names found in <filename>/etc/protocols</filename>
are recognized and may be used. The special protocol
keyword <literal>tcp/udp</literal> may be used to match
either a <acronym>TCP</acronym> or a <acronym>UDP</acronym>
protocol names found in
<filename>/etc/protocols</filename> are recognized and
may be used. The special protocol keyword
<literal>tcp/udp</literal> may be used to match either a
<acronym>TCP</acronym> or a <acronym>UDP</acronym>
packet, and has been added as a convenience to save
duplication of otherwise identical rules.</para>
</listitem>
@ -1846,20 +1858,20 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<literal>from</literal> and <literal>to</literal>
keywords are used to match against IP addresses. Rules
must specify <emphasis>both</emphasis> the source and
destination parameters. <literal>any</literal> is a special
keyword that matches any IP address. Examples include:
<literal>from any to any</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
destination parameters. <literal>any</literal> is a
special keyword that matches any IP address. Examples
include: <literal>from any to any</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>, and <literal>from any to
0.0.0.0</literal>.</para>
<para>There is no way to match ranges of IP addresses which
do not express themselves easily using the dotted numeric
form / mask-length notation. The
<package>net-mgmt/ipcalc</package> port may be used to ease
the calculation. Additional information is available at the
utility's web page: <uri
<para>There is no way to match ranges of IP addresses
which do not express themselves easily using the dotted
numeric form / mask-length notation. The
<package>net-mgmt/ipcalc</package> port may be used to
ease the calculation. 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>
@ -1869,25 +1881,26 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<listitem>
<para>If a port match is included, for either or both of
source and destination, it is only applied to
<acronym>TCP</acronym> and <acronym>UDP</acronym> packets.
When composing port comparisons, either the service name
from <filename>/etc/services</filename> or an integer port
number may be used. When the port appears as part of the
<literal>from</literal> object, it matches the source port
number. When it appears as part of the
<literal>to</literal> object, it matches the destination
port number. An example usage is
<acronym>TCP</acronym> and <acronym>UDP</acronym>
packets. When composing port comparisons, either the
service name from <filename>/etc/services</filename> or
an integer port number may be used. When the port
appears as part of the <literal>from</literal> object,
it matches the source port number. When it appears as
part of the <literal>to</literal> object, it matches the
destination port number. An example usage is
<literal>from any to any port = 80</literal></para>
<para>Single port comparisons may be done in a number of ways,
using a number of different comparison operators. Instead
of the <literal>=</literal> shown in the example above,
the following operators may be used: <literal>!=</literal>,
<literal>&lt;</literal>, <literal>&gt;</literal>,
<literal>&lt;=</literal>, <literal>&gt;=</literal>,
<literal>eq</literal>, <literal>ne</literal>,
<literal>lt</literal>, <literal>gt</literal>,
<literal>le</literal>, and <literal>ge</literal>.</para>
<para>Single port comparisons may be done in a number of
ways, using a number of different comparison operators.
Instead of the <literal>=</literal> shown in the example
above, the following operators may be used:
<literal>!=</literal>, <literal>&lt;</literal>,
<literal>&gt;</literal>, <literal>&lt;=</literal>,
<literal>&gt;=</literal>, <literal>eq</literal>,
<literal>ne</literal>, <literal>lt</literal>,
<literal>gt</literal>, <literal>le</literal>, and
<literal>ge</literal>.</para>
<para>To specify port ranges, place the two port numbers
between <literal>&lt;&gt;</literal> or
@ -1899,9 +1912,9 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<term><acronym>TCP</acronym>_FLAG</term>
<listitem>
<para>Flags are only effective for <acronym>TCP</acronym>
filtering. The letters represent one of the possible flags
that can be matched against the <acronym>TCP</acronym>
packet header.</para>
filtering. The letters represent one of the possible
flags that can be matched against the
<acronym>TCP</acronym> packet header.</para>
<para>The modernized rules processing logic uses the
<literal>flags S</literal> parameter to identify the TCP
@ -1912,9 +1925,10 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<varlistentry>
<term>STATEFUL</term>
<listitem>
<para><literal>keep state</literal> indicates that on a pass
rule, any packets that match the rules selection parameters
should activate the stateful filtering facility.</para>
<para><literal>keep state</literal> indicates that on a
pass rule, any packets that match the rules selection
parameters should activate the stateful filtering
facility.</para>
</listitem>
</varlistentry>
</variablelist>
@ -2332,8 +2346,9 @@ EOF
</listitem>
<listitem>
<para>Disable <application>IPFILTER</application> in the system startup scripts by
adding <literal>ipfilter_enable="NO"</literal>to
<para>Disable <application>IPFILTER</application> in the
system startup scripts by adding
<literal>ipfilter_enable="NO"</literal>to
<filename>/etc/rc.conf</filename>.</para>
<para>Then, add a script like the following to
@ -2513,15 +2528,16 @@ sh /etc/ipf.rules.script</programlisting>
<sect3>
<title><acronym>NAT</acronym> for a Large LAN</title>
<para>For networks that have large numbers of systems on the LAN
or networks with more than a single LAN, the process of
funneling all those private IP addresses into a single public
IP address becomes a resource problem that may cause problems
with the same port numbers being used many times across many
connections, causing collisions. This section describes two ways to
relieve this resource problem.</para>
<para>For networks that have large numbers of systems on the
LAN or networks with more than a single LAN, the process of
funneling all those private IP addresses into a single
public IP address becomes a resource problem that may cause
problems with the same port numbers being used many times
across many connections, causing collisions. This section
describes two ways to relieve this resource problem.</para>
<para>The first method is to assign ports to use. A normal NAT rule would look like:</para>
<para>The first method is to assign ports to use. A normal
NAT rule would look like:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32</programlisting>
@ -2541,7 +2557,8 @@ sh /etc/ipf.rules.script</programlisting>
<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp auto</programlisting>
<para>The second method is to use a pool of public addresses. In very large LANs there comes a point where there are
<para>The second method is to use a pool of public addresses.
In very large LANs there comes a point where there are
just too many LAN addresses to fit into a single public
address. If a block of public IP addresses is available,
these addresses can be used as a <quote>pool</quote>, and
@ -2568,15 +2585,16 @@ sh /etc/ipf.rules.script</programlisting>
<title>Port Redirection</title>
<para>A common practice is to have a web server, email server,
database server, and DNS server each segregated to a different
system on the LAN. In this case, the traffic from these
servers still has to undergo <acronym>NAT</acronym>, but there
has to be some way to direct the inbound traffic to the
correct server. For example, a web server operating on LAN
address <systemitem class="ipaddress">10.0.10.25</systemitem>
and using a single public IP address of
<systemitem class="ipaddress">20.20.20.5</systemitem>, would
use this rule:</para>
database server, and DNS server each segregated to a
different system on the LAN. In this case, the traffic from
these servers still has to undergo <acronym>NAT</acronym>,
but there has to be some way to direct the inbound traffic
to the correct server. For example, a web server operating
on LAN address <systemitem
class="ipaddress">10.0.10.25</systemitem> and using a
single public IP address of <systemitem
class="ipaddress">20.20.20.5</systemitem>, would use this
rule:</para>
<programlisting>rdr dc0 20.20.20.5/32 port 80 -&gt; 10.0.10.25 port 80</programlisting>
@ -2597,8 +2615,8 @@ sh /etc/ipf.rules.script</programlisting>
<para>FTP has two modes: active mode and passive mode. The
difference is in how the data channel is acquired. Passive
mode is more secure as the data channel is acquired by the
ordinal ftp session requester. For a good explanation of FTP
and the different modes, see <uri
ordinal ftp session requester. For a good explanation of
FTP and the different modes, see <uri
xlink:href="http://www.slacksite.com/other/ftp.html">http://www.slacksite.com/other/ftp.html</uri>.</para>
<para>IP<acronym>NAT</acronym> has a built in FTP proxy option
@ -2797,9 +2815,9 @@ LOG_ERR - packets which have been logged and which can be considered short</scre
<!-- XXX: "can be considered short" == "with incomplete header" -->
<para>In order to setup <application>IPFILTER</application> to log all data to
<filename>/var/log/ipfilter.log</filename>, first
create the empty file:</para>
<para>In order to setup <application>IPFILTER</application> to
log all data to <filename>/var/log/ipfilter.log</filename>,
first create the empty file:</para>
<screen>&prompt.root; <userinput>touch /var/log/ipfilter.log</userinput></screen>