White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
parent
d01a8ba4c4
commit
e1f3a68162
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43930
1 changed files with 283 additions and 286 deletions
|
@ -548,20 +548,19 @@ options ALTQ_PRIQ # Priority Queuing (PRIQ)</programlisting>
|
|||
<para>The simplest possible ruleset is for a single machine
|
||||
that does not run any services and which needs access to one
|
||||
network, which may be the Internet. To create this minimal
|
||||
ruleset, edit
|
||||
<filename>/etc/pf.conf</filename> so it looks like this:</para>
|
||||
ruleset, edit <filename>/etc/pf.conf</filename> so it looks
|
||||
like this:</para>
|
||||
|
||||
<programlisting>block in all
|
||||
pass out all keep state</programlisting>
|
||||
|
||||
<para>The first rule denies all incoming traffic by default.
|
||||
The second rule allows
|
||||
connections created by this system
|
||||
to pass out, while retaining state information on those
|
||||
connections. This state information allows return
|
||||
traffic for those connections to pass back and
|
||||
should only be used on machines that can be
|
||||
trusted. The ruleset can be loaded with:</para>
|
||||
The second rule allows connections created by this system to
|
||||
pass out, while retaining state information on those
|
||||
connections. This state information allows return traffic for
|
||||
those connections to pass back and should only be used on
|
||||
machines that can be trusted. The ruleset can be loaded
|
||||
with:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>pfctl -e ; pfctl -f /etc/pf.conf</userinput></screen>
|
||||
|
||||
|
@ -569,22 +568,22 @@ pass out all keep state</programlisting>
|
|||
<application>PF</application> provides
|
||||
<firstterm>lists</firstterm> and
|
||||
<firstterm>macros</firstterm> which can be defined for use
|
||||
when creating rules. Macros can include lists and need to be defined
|
||||
before use. As an example, insert these lines at the
|
||||
when creating rules. Macros can include lists and need to be
|
||||
defined before use. As an example, insert these lines at the
|
||||
very top of the ruleset:</para>
|
||||
|
||||
<programlisting>tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }"
|
||||
udp_services = "{ domain }"</programlisting>
|
||||
|
||||
<para><application>PF</application> understands port
|
||||
names as well as port numbers, as long as the names are listed
|
||||
in <filename>/etc/services</filename>. This example
|
||||
creates two macros. The first is a list of seven
|
||||
<para><application>PF</application> understands port names as
|
||||
well as port numbers, as long as the names are listed in
|
||||
<filename>/etc/services</filename>. This example creates two
|
||||
macros. The first is a list of seven
|
||||
<acronym>TCP</acronym> port names and the second is one
|
||||
<acronym>UDP</acronym> port name. Once defined, macros can
|
||||
be used in rules. In this example, all traffic is blocked
|
||||
except for the connections initiated by this system for the
|
||||
seven specified <acronym>TCP</acronym> services and the one
|
||||
<acronym>UDP</acronym> port name. Once defined, macros can be
|
||||
used in rules. In this example, all traffic is blocked except
|
||||
for the connections initiated by this system for the seven
|
||||
specified <acronym>TCP</acronym> services and the one
|
||||
specified <acronym>UDP</acronym> service:</para>
|
||||
|
||||
<programlisting>tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }"
|
||||
|
@ -593,34 +592,34 @@ block all
|
|||
pass out proto tcp to any port $tcp_services keep state
|
||||
pass proto udp to any port $udp_services keep state</programlisting>
|
||||
|
||||
<para>Even though <acronym>UDP</acronym> is considered to be
|
||||
a stateless protocol, <application>PF</application>
|
||||
is able to track some state information. For example, when a
|
||||
<acronym>UDP</acronym> request is passed which
|
||||
asks a name server about a domain name, <application>PF</application>
|
||||
will watch for the response in order to pass it back.</para>
|
||||
<para>Even though <acronym>UDP</acronym> is considered to be a
|
||||
stateless protocol, <application>PF</application> is able to
|
||||
track some state information. For example, when a
|
||||
<acronym>UDP</acronym> request is passed which asks a name
|
||||
server about a domain name, <application>PF</application> will
|
||||
watch for the response in order to pass it back.</para>
|
||||
|
||||
<para>Whenever an edit is made to a ruleset, the new rules
|
||||
must be loaded so they can be used:</para>
|
||||
<para>Whenever an edit is made to a ruleset, the new rules must
|
||||
be loaded so they can be used:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>pfctl -f /etc/pf.conf</userinput></screen>
|
||||
|
||||
<para>If there are no syntax
|
||||
errors, <command>pfctl</command> will not output any
|
||||
messages during the rule load. Rules can also be tested before attempting to load them:</para>
|
||||
<para>If there are no syntax errors, <command>pfctl</command>
|
||||
will not output any messages during the rule load. Rules can
|
||||
also be tested before attempting to load them:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>pfctl -nf /etc/pf.conf</userinput></screen>
|
||||
|
||||
<para>Including <option>-n</option> causes the rules to be interpreted
|
||||
only, but not loaded. This provides an opportunity
|
||||
to correct any errors. At all times, the last
|
||||
<para>Including <option>-n</option> causes the rules to be
|
||||
interpreted only, but not loaded. This provides an
|
||||
opportunity to correct any errors. At all times, the last
|
||||
valid ruleset loaded will be enforced until either
|
||||
<application>PF</application> is disabled or a new ruleset
|
||||
is loaded.</para>
|
||||
<application>PF</application> is disabled or a new ruleset is
|
||||
loaded.</para>
|
||||
|
||||
<tip>
|
||||
<para>Adding <option>-v</option> to a
|
||||
<command>pfctl</command> ruleset verify or load will display the fully parsed rules
|
||||
<para>Adding <option>-v</option> to a <command>pfctl</command>
|
||||
ruleset verify or load will display the fully parsed rules
|
||||
exactly the way they will be loaded. This is extremely
|
||||
useful when debugging rules.</para>
|
||||
</tip>
|
||||
|
@ -636,26 +635,25 @@ pass proto udp to any port $udp_services keep state</programlisting>
|
|||
Internet and the other is to the internal network.</para>
|
||||
|
||||
<para>It is reasonable to think that for stateful traffic to
|
||||
pass from the network connected to
|
||||
<filename>xl1</filename> to hosts on the network
|
||||
connected to <filename>xl0</filename>, a rule like
|
||||
this is needed:</para>
|
||||
pass from the network connected to <filename>xl1</filename>
|
||||
to hosts on the network connected to
|
||||
<filename>xl0</filename>, a rule like this is needed:</para>
|
||||
|
||||
<programlisting>pass in on xl1 from xl1:network to xl0:network port $ports keep state</programlisting>
|
||||
|
||||
<para>However, the <quote>to</quote> keyword does
|
||||
guarantee passage all the way from source to destination. This rule
|
||||
only lets the traffic pass in to the gateway on
|
||||
the internal interface. To let the packets go
|
||||
further, a matching rule is needed:</para>
|
||||
guarantee passage all the way from source to destination.
|
||||
This rule only lets the traffic pass in to the gateway on
|
||||
the internal interface. To let the packets go further, a
|
||||
matching rule is needed:</para>
|
||||
|
||||
<programlisting>pass out on xl0 from xl1:network to xl0:network port $ports keep state</programlisting>
|
||||
|
||||
<para>These rules will work, but they will not necessarily
|
||||
achieve the desired effect.</para>
|
||||
|
||||
<para>Rules this specific are rarely needed. A
|
||||
better rule says:</para>
|
||||
<para>Rules this specific are rarely needed. A better rule
|
||||
says:</para>
|
||||
|
||||
<programlisting>pass from xl1:network to any port $ports keep state</programlisting>
|
||||
|
||||
|
@ -664,8 +662,8 @@ pass proto udp to any port $udp_services keep state</programlisting>
|
|||
<firstterm>antispoof</firstterm> and
|
||||
<firstterm>scrub</firstterm> code.</para>
|
||||
|
||||
<para>For a busy network admin, a readable ruleset is a
|
||||
safer ruleset. For the remainder of this section, with some
|
||||
<para>For a busy network admin, a readable ruleset is a safer
|
||||
ruleset. For the remainder of this section, with some
|
||||
exceptions, we will keep the rules as simple as possible
|
||||
for readability.</para>
|
||||
|
||||
|
@ -675,8 +673,8 @@ pass proto udp to any port $udp_services keep state</programlisting>
|
|||
more readable and maintainable by taking the macro use a
|
||||
tiny bit further.</para>
|
||||
|
||||
<para>For example, a <literal>$localnet</literal> macro
|
||||
could be defined as the network directly attached to your
|
||||
<para>For example, a <literal>$localnet</literal> macro could
|
||||
be defined as the network directly attached to your
|
||||
internal interface (<literal>$xl1:network</literal> in the
|
||||
examples above).</para>
|
||||
|
||||
|
@ -686,22 +684,22 @@ pass proto udp to any port $udp_services keep state</programlisting>
|
|||
a network, such as <literal>192.168.100.1/24</literal> for
|
||||
a subnet of private addresses.</para>
|
||||
|
||||
<para>If required, <literal>$localnet</literal> could even
|
||||
be defined as a list of networks. Whatever the specific
|
||||
needs, a sensible <literal>$localnet</literal> definition
|
||||
and a typical pass rule of the type</para>
|
||||
<para>If required, <literal>$localnet</literal> could even be
|
||||
defined as a list of networks. Whatever the specific needs,
|
||||
a sensible <literal>$localnet</literal> definition and a
|
||||
typical pass rule of the type</para>
|
||||
|
||||
<programlisting>pass from $localnet to any port $ports keep state</programlisting>
|
||||
|
||||
<para>could end up saving you a few headaches. We will
|
||||
stick to that convention from here on.</para>
|
||||
<para>could end up saving you a few headaches. We will stick
|
||||
to that convention from here on.</para>
|
||||
|
||||
<para>First, we need to turn on gatewaying in order to let
|
||||
the machine forward the network traffic it receives on one
|
||||
<para>First, we need to turn on gatewaying in order to let the
|
||||
machine forward the network traffic it receives on one
|
||||
interface to other networks via a separate interface.
|
||||
Initially we will do this on the command line with
|
||||
&man.sysctl.8;, for traditional
|
||||
<emphasis>IP version four</emphasis>.</para>
|
||||
&man.sysctl.8;, for traditional <emphasis>IP version
|
||||
four</emphasis>.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>sysctl net.inet.ip.forwarding=1</userinput></screen>
|
||||
|
||||
|
@ -719,14 +717,13 @@ pass proto udp to any port $udp_services keep state</programlisting>
|
|||
ipv6_gateway_enable="YES" #for ipv6</programlisting>
|
||||
|
||||
<para>Use <command>ifconfig -a</command>, or
|
||||
<command>ifconfig
|
||||
interface_name</command> to
|
||||
find out if both of the interfaces to be used are up and
|
||||
<command>ifconfig interface_name</command> to find out if
|
||||
both of the interfaces to be used are up and
|
||||
running.</para>
|
||||
|
||||
<para>If all traffic initiated by machines on the inside is
|
||||
to be allowed, <filename>/etc/pf.conf</filename> could
|
||||
look roughly like this
|
||||
<para>If all traffic initiated by machines on the inside is to
|
||||
be allowed, <filename>/etc/pf.conf</filename> could look
|
||||
roughly like this
|
||||
<footnote>
|
||||
<para>For dialup users, the external interface is the
|
||||
<filename>tun0</filename> pseudo-device. Broadband
|
||||
|
@ -780,14 +777,14 @@ pass from { lo0, $localnet } to any keep state</programlisting>
|
|||
<programlisting>pass inet proto tcp from $localnet to any port $client_out \
|
||||
flags S/SA keep state</programlisting>
|
||||
|
||||
<para>In addition, we have a few other pass rules. One pass rule which is useful for
|
||||
administering machines remotely
|
||||
<para>In addition, we have a few other pass rules. One pass
|
||||
rule which is useful for administering machines remotely
|
||||
is:</para>
|
||||
|
||||
<programlisting>pass in inet proto tcp to $ext_if port ssh</programlisting>
|
||||
|
||||
<para>Lastly we need to make the
|
||||
name service work for our clients:</para>
|
||||
<para>Lastly we need to make the name service work for our
|
||||
clients:</para>
|
||||
|
||||
<programlisting>udp_services = "{ domain, ntp }"</programlisting>
|
||||
|
||||
|
|
Loading…
Reference in a new issue