White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
parent
56696223fd
commit
fcb53eaa02
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43912
1 changed files with 128 additions and 115 deletions
|
@ -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; 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; 8.<replaceable>X</replaceable> is using the same
|
||||
version of <application>PF</application> as OpenBSD 4.1.
|
||||
&os; 9.<replaceable>X</replaceable> and later is using
|
||||
the same version of <application>PF</application> as
|
||||
OpenBSD 4.5.</para>
|
||||
version of <application>PF</application>
|
||||
OpenBSD 4.1. &os; 9.<replaceable>X</replaceable>
|
||||
and later is using the same version of
|
||||
<application>PF</application> as OpenBSD 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 >< 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 >< 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>< ></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>< ></literal>, like
|
||||
this:</para>
|
||||
|
||||
<programlisting>table <clients> { 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 !<spamd-white> 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 !<spamd-white> 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>
|
||||
|
||||
|
|
Loading…
Reference in a new issue