White space fix only. Translators can ignore.

Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne 2014-02-13 23:01:32 +00:00
parent 56696223fd
commit fcb53eaa02
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43912

View file

@ -78,24 +78,26 @@
</itemizedlist>
<para>&os; has three firewalls built into the base system:
<application>PF</application>, <application>IPFILTER</application>, also known as
<application>PF</application>,
<application>IPFILTER</application>, also known as
<application>IPF</application>, and
<application>IPFW</application>.
&os; also provides two traffic shapers for controlling bandwidth
usage: &man.altq.4; and &man.dummynet.4;.
<application>ALTQ</application> has
traditionally been closely tied with <application>PF</application> and
<application>dummynet</application> with <application>IPFW</application>.
Each
firewall uses rules to control the access of packets to and from
a &os; system, although they go about it in different ways and
each has a different rule syntax.</para>
traditionally been closely tied with
<application>PF</application> and
<application>dummynet</application> with
<application>IPFW</application>. Each firewall uses rules to
control the access of packets to and from a &os; system,
although they go about it in different ways and each has a
different rule syntax.</para>
<para>&os; provides multiple firewalls in order to meet the
different requirements and preferences for a wide variety of
users. Each user should evaluate which firewall best meets
their needs.</para>
<para>After reading this chapter, you will know:</para>
<itemizedlist>
@ -133,15 +135,15 @@
</itemizedlist>
<note>
<para>Since all firewalls are based on inspecting the values of
selected packet control fields, the creator of the firewall
ruleset must have an understanding of how
<acronym>TCP/IP</acronym> works, what the different values in
the packet control fields are, and how these values are used in
a normal session conversation. For a good introduction, refer
to
<link xlink:href="http://www.ipprimer.com/overview.cfm">Daryl's
TCP/IP Primer</link>.</para>
<para>Since all firewalls are based on inspecting the values of
selected packet control fields, the creator of the firewall
ruleset must have an understanding of how
<acronym>TCP/IP</acronym> works, what the different values in
the packet control fields are, and how these values are used
in a normal session conversation. For a good introduction,
refer to <link
xlink:href="http://www.ipprimer.com/overview.cfm">Daryl's
TCP/IP Primer</link>.</para>
</note>
</sect1>
@ -210,20 +212,21 @@
<para>Since &os;&nbsp;5.3, a ported version of OpenBSD's
<application>PF</application> firewall has been included as an
integrated part of the base system. <application>PF</application> is a
complete, full-featured firewall that has optional support for
integrated part of the base system.
<application>PF</application> is a complete, full-featured
firewall that has optional support for
<acronym>ALTQ</acronym> (Alternate Queuing), which provides
Quality of Service (<acronym>QoS</acronym>).</para>
<para>Since the OpenBSD Project maintains the definitive
reference for <application>PF</application> in the
<link xlink:href="http://www.openbsd.org/faq/pf/">PF FAQ</link>,
this section of the Handbook focuses on <application>PF</application> as
it pertains to &os;, while providing some general usage
information.</para>
reference for <application>PF</application> in the <link
xlink:href="http://www.openbsd.org/faq/pf/">PF FAQ</link>,
this section of the Handbook focuses on
<application>PF</application> as it pertains to &os;, while
providing some general usage information.</para>
<para>More information about porting <application>PF</application> to &os;
can be found at <uri
<para>More information about porting <application>PF</application>
to &os; can be found at <uri
xlink:href="http://pf4freebsd.love2party.net/">http://pf4freebsd.love2party.net/</uri>.</para>
<sect2>
@ -252,8 +255,8 @@
can be found in
<filename>/usr/share/examples/pf/</filename>.</para>
<para>The <application>PF</application> module can also be loaded
manually from the command line:</para>
<para>The <application>PF</application> module can also be
loaded manually from the command line:</para>
<screen>&prompt.root; <userinput>kldload pf.ko</userinput></screen>
@ -286,18 +289,20 @@
<secondary>device pfsync</secondary>
</indexterm>
<para>While it is not necessary to compile <application>PF</application>
support into the &os; kernel, some of PF's advanced features
are not included in the loadable module, namely
&man.pfsync.4;, which is a pseudo-device that exposes certain
changes to the state table used by <application>PF</application>. It
can be paired with &man.carp.4; to create failover firewalls
using <application>PF</application>. More information on
<acronym>CARP</acronym> can be found in
<link linkend="carp">of the Handbook</link>.</para>
<para>While it is not necessary to compile
<application>PF</application> support into the &os; kernel,
some of PF's advanced features are not included in the
loadable module, namely &man.pfsync.4;, which is a
pseudo-device that exposes certain changes to the state table
used by <application>PF</application>. It can be paired with
&man.carp.4; to create failover firewalls using
<application>PF</application>. More information on
<acronym>CARP</acronym> can be found in <link
linkend="carp">of the Handbook</link>.</para>
<para>The following <application>PF</application> kernel options can be
found in <filename>/usr/src/sys/conf/NOTES</filename>:</para>
<para>The following <application>PF</application> kernel options
can be found in
<filename>/usr/src/sys/conf/NOTES</filename>:</para>
<programlisting>device pf
device pflog
@ -340,15 +345,15 @@ pflog_flags="" # additional flags for pflogd startup</programli
<sect2>
<title>Creating Filtering Rules</title>
<para>By default, <application>PF</application> reads its configuration
rules from <filename>/etc/pf.conf</filename> and modifies,
drops, or passes packets according to the rules or definitions
specified in this file. The &os; installation includes
several sample files located in
<para>By default, <application>PF</application> reads its
configuration rules from <filename>/etc/pf.conf</filename> and
modifies, drops, or passes packets according to the rules or
definitions specified in this file. The &os; installation
includes several sample files located in
<filename>/usr/share/examples/pf/</filename>. Refer to the
<link xlink:href="http://www.openbsd.org/faq/pf/">PF
FAQ</link> for complete coverage of <application>PF</application>
rulesets.</para>
FAQ</link> for complete coverage of
<application>PF</application> rulesets.</para>
<warning>
<para>When reading the <link
@ -356,20 +361,20 @@ pflog_flags="" # additional flags for pflogd startup</programli
keep in mind that different versions of &os; contain
different versions of PF. Currently,
&os;&nbsp;8.<replaceable>X</replaceable> is using the same
version of <application>PF</application> as OpenBSD&nbsp;4.1.
&os;&nbsp;9.<replaceable>X</replaceable> and later is using
the same version of <application>PF</application> as
OpenBSD&nbsp;4.5.</para>
version of <application>PF</application>
OpenBSD&nbsp;4.1. &os;&nbsp;9.<replaceable>X</replaceable>
and later is using the same version of
<application>PF</application> as OpenBSD&nbsp;4.5.</para>
</warning>
<para>The &a.pf; is a good place to ask questions about
configuring and running the <application>PF</application> firewall.
Do not forget to check the mailing list archives before asking
questions.</para>
configuring and running the <application>PF</application>
firewall. Do not forget to check the mailing list archives
before asking questions.</para>
<para>To control <application>PF</application>, use &man.pfctl.8;.
Below are some useful options to this command. Review
&man.pfctl.8; for a description of all available
<para>To control <application>PF</application>, use
&man.pfctl.8;. Below are some useful options to this command.
Review &man.pfctl.8; for a description of all available
options:</para>
<informaltable frame="none" pgwide="1">
@ -482,7 +487,8 @@ options ALTQ_NOPCC # Required for SMP build</programlisting>
<sect2 xml:id="pf-tutorial">
<info>
<title><application>PF</application> Rule Sets and Tools</title>
<title><application>PF</application> Rule Sets and
Tools</title>
<authorgroup>
<author>
@ -497,9 +503,9 @@ options ALTQ_NOPCC # Required for SMP build</programlisting>
</info>
<para>This section demonstrates some useful
<application>PF</application> features and <application>PF</application>
related tools in a series of examples. A more thorough
tutorial is available at <link
<application>PF</application> features and
<application>PF</application> related tools in a series of
examples. A more thorough tutorial is available at <link
xlink:href="http://home.nuug.no/~peter/pf/">http://home.nuug.no/~peter/pf/</link>.</para>
<tip>
@ -563,9 +569,9 @@ udp_services = "{ domain }"</programlisting>
<para>Now we have demonstrated several things at once - what
macros look like, that macros may be lists, and that
<application>PF</application> understands rules using port names
equally well as it does port numbers. The names are the
ones listed in <filename>/etc/services</filename>. This
<application>PF</application> understands rules using port
names equally well as it does port numbers. The names are
the ones listed in <filename>/etc/services</filename>. This
gives us something to put in our rules, which we edit
slightly to look like this:</para>
@ -574,11 +580,11 @@ pass out proto tcp to any port $tcp_services keep state
pass proto udp to any port $udp_services keep state</programlisting>
<para>At this point some of us will point out that UDP is
stateless, but <application>PF</application> actually manages to
maintain state information despite this. Keeping state for
a UDP connection means that for example when you ask a name
server about a domain name, you will be able to receive its
answer.</para>
stateless, but <application>PF</application> actually
manages to maintain state information despite this. Keeping
state for a UDP connection means that for example when you
ask a name server about a domain name, you will be able to
receive its answer.</para>
<para>Since we have made changes to our
<filename>pf.conf</filename>, we load the new
@ -602,8 +608,8 @@ pass proto udp to any port $udp_services keep state</programlisting>
only, but does not load them. This provides an opportunity
to correct any errors. Under any circumstances, the last
valid rule set loaded will be in force until
<application>PF</application> is disabled or a new rule set is
loaded.</para>
<application>PF</application> is disabled or a new rule set
is loaded.</para>
<tip>
<title>Use <command>pfctl -v</command> to Show the Parsed
@ -623,8 +629,8 @@ pass proto udp to any port $udp_services keep state</programlisting>
<para>To most users, a single machine setup will be of limited
interest, and at this point we move on to more realistic or
at least more common setups, concentrating on a machine
which is running <application>PF</application> and also acts as a
gateway for at least one other machine.</para>
which is running <application>PF</application> and also acts
as a gateway for at least one other machine.</para>
<sect4 xml:id="pftut-gwpitfalls">
<title>Gateways and the Pitfalls of <literal>in</literal>,
@ -928,7 +934,8 @@ pass from { lo0, $localnet } to any keep state</programlisting>
gateway is amazingly simple, thanks to the
<acronym>FTP</acronym> proxy program (called
&man.ftp-proxy.8;) included in the base system on &os; and
other systems which offer <application>PF</application>.</para>
other systems which offer
<application>PF</application>.</para>
<para>The <acronym>FTP</acronym> protocol being what it is,
the proxy needs to dynamically insert rules in your rule
@ -944,8 +951,8 @@ pass from { lo0, $localnet } to any keep state</programlisting>
<para>Starting the proxy manually by running
<command>/usr/sbin/ftp-proxy</command> allows testing of
the <application>PF</application> configuration changes we are
about to make.</para>
the <application>PF</application> configuration changes we
are about to make.</para>
<para>For a basic configuration, only three elements need to
be added to <filename>/etc/pf.conf</filename>. First, the
@ -1006,10 +1013,11 @@ rdr-anchor "ftp-proxy/*"</programlisting>
page.</para>
<para>For ways to run an <acronym>FTP</acronym> server
protected by <application>PF</application> and &man.ftp-proxy.8;,
look into running a separate <command>ftp-proxy</command>
in reverse mode (using <option>-R</option>), on a separate
port with its own redirecting pass rule.</para>
protected by <application>PF</application> and
&man.ftp-proxy.8;, look into running a separate
<command>ftp-proxy</command> in reverse mode (using
<option>-R</option>), on a separate port with its own
redirecting pass rule.</para>
</sect4>
</sect3>
@ -1099,8 +1107,8 @@ pass inet proto icmp from any to $ext_if keep state</programlisting>
<para>Stopping probes at the gateway might be an attractive
option anyway, but let us have a look at a few other
options which will show some of <application>PF</application>'s
flexibility.</para>
options which will show some of
<application>PF</application>'s flexibility.</para>
</sect4>
<sect4 xml:id="pftut-letpingthru">
@ -1166,7 +1174,8 @@ pass out on $ext_if inet proto udp from any to any port 33433 &gt;&lt; 33626 kee
places from <link
xlink:href="http://marc.theaimsgroup.com/">http://marc.theaimsgroup.com/</link>),
to be a very valuable resource whenever you need OpenBSD
or <application>PF</application> related information.</para>
or <application>PF</application> related
information.</para>
</sect4>
<sect4 xml:id="pftut-pathmtudisc">
@ -1235,12 +1244,13 @@ pass out on $ext_if inet proto udp from any to any port 33433 &gt;&lt; 33626 kee
and rigid. There will after all be some kinds of data which
are relevant to filtering and redirection at a given time,
but do not deserve to be put into a configuration file!
Quite right, and <application>PF</application> offers mechanisms for
handling these situations as well. Tables are one such
feature, mainly useful as lists which can be manipulated
without needing to reload the entire rule set, and where
fast lookups are desirable. Table names are always enclosed
in <literal>&lt; &gt;</literal>, like this:</para>
Quite right, and <application>PF</application> offers
mechanisms for handling these situations as well. Tables
are one such feature, mainly useful as lists which can be
manipulated without needing to reload the entire rule set,
and where fast lookups are desirable. Table names are
always enclosed in <literal>&lt; &gt;</literal>, like
this:</para>
<programlisting>table &lt;clients&gt; { 192.168.2.0/24, !192.168.2.5 }</programlisting>
@ -1323,13 +1333,14 @@ Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from
22222 for a repeat performance.</para>
<para>Since OpenBSD 3.7, and soon after in &os; version 6.0,
<application>PF</application> has offered a slightly more elegant
solution. Pass rules can be written so they maintain
certain limits on what connecting hosts can do. For good
measure, violators can be banished to a table of addresses
which are denied some or all access. If desired, it is even
possible to drop all existing connections from machines
which overreach the limits. Here is how it is done:</para>
<application>PF</application> has offered a slightly more
elegant solution. Pass rules can be written so they
maintain certain limits on what connecting hosts can do.
For good measure, violators can be banished to a table of
addresses which are denied some or all access. If desired,
it is even possible to drop all existing connections from
machines which overreach the limits. Here is how it is
done:</para>
<para>First, set up the table. In the tables section,
add</para>
@ -1491,7 +1502,8 @@ Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from
<title>Other <application>PF</application> Tools</title>
<para>Over time, a number of tools have been developed which
interact with <application>PF</application> in various ways.</para>
interact with <application>PF</application> in various
ways.</para>
<sect4 xml:id="pftut-pftop">
<title>The <application>pftop</application> Traffic
@ -1819,13 +1831,14 @@ rdr pass on $ext_if inet proto tcp from !&lt;spamd-white&gt; to \
can be set in the <literal>options</literal> part of the
ruleset, which precedes the redirection and filtering
rules. This option determines which feedback, if any,
<application>PF</application> will give to hosts which try to
create connections which are subsequently blocked. The
option has two possible values, <literal>drop</literal>,
which drops blocked packets with no feedback, and
<literal>return</literal>, which returns with status
codes such as <computeroutput>Connection
refused</computeroutput> or similar.</para>
<application>PF</application> will give to hosts which
try to create connections which are subsequently
blocked. The option has two possible values,
<literal>drop</literal>, which drops blocked packets
with no feedback, and <literal>return</literal>, which
returns with status codes such as
<computeroutput>Connection refused</computeroutput> or
similar.</para>
<para>The correct strategy for block policies has been the
subject of rather a lot of discussion. We choose to
@ -1838,24 +1851,24 @@ rdr pass on $ext_if inet proto tcp from !&lt;spamd-white&gt; to \
<sect5 xml:id="pftut-scrub">
<title><literal>scrub</literal></title>
<para>In <application>PF</application> versions up to OpenBSD 4.5
inclusive, <literal>scrub</literal> is a keyword which
enables network packet normalization, causing fragmented
packets to be assembled and removing ambiguity.
Enabling <literal>scrub</literal> provides a measure of
protection against certain kinds of attacks based on
incorrect handling of packet fragments. A number of
supplementing options are available, but we choose the
simplest form which is suitable for most
<para>In <application>PF</application> versions up to
OpenBSD 4.5 inclusive, <literal>scrub</literal> is a
keyword which enables network packet normalization,
causing fragmented packets to be assembled and removing
ambiguity. Enabling <literal>scrub</literal> provides a
measure of protection against certain kinds of attacks
based on incorrect handling of packet fragments. A
number of supplementing options are available, but we
choose the simplest form which is suitable for most
configurations.</para>
<programlisting>scrub in all</programlisting>
<para>Some services, such as NFS, require some specific
fragment handling options. This is extensively
documented in the <application>PF</application> user guide and
man pages provide all the information you could
need.</para>
documented in the <application>PF</application> user
guide and man pages provide all the information you
could need.</para>
<para>One fairly common example is this,</para>