White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
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
|
|
@ -545,85 +545,84 @@ options ALTQ_PRIQ # Priority Queuing (PRIQ)</programlisting>
|
||||||
real-world usage of <application>PF</application>'s many
|
real-world usage of <application>PF</application>'s many
|
||||||
features.</para>
|
features.</para>
|
||||||
|
|
||||||
<para>The simplest possible ruleset is for a single machine
|
<para>The simplest possible ruleset is for a single machine
|
||||||
that does not run any services and which needs access to one
|
that does not run any services and which needs access to one
|
||||||
network, which may be the Internet. To create this minimal
|
network, which may be the Internet. To create this minimal
|
||||||
ruleset, edit
|
ruleset, edit <filename>/etc/pf.conf</filename> so it looks
|
||||||
<filename>/etc/pf.conf</filename> so it looks like this:</para>
|
like this:</para>
|
||||||
|
|
||||||
<programlisting>block in all
|
<programlisting>block in all
|
||||||
pass out all keep state</programlisting>
|
pass out all keep state</programlisting>
|
||||||
|
|
||||||
<para>The first rule denies all incoming traffic by default.
|
<para>The first rule denies all incoming traffic by default.
|
||||||
The second rule allows
|
The second rule allows connections created by this system to
|
||||||
connections created by this system
|
pass out, while retaining state information on those
|
||||||
to pass out, while retaining state information on those
|
connections. This state information allows return traffic for
|
||||||
connections. This state information allows return
|
those connections to pass back and should only be used on
|
||||||
traffic for those connections to pass back and
|
machines that can be trusted. The ruleset can be loaded
|
||||||
should only be used on machines that can be
|
with:</para>
|
||||||
trusted. The ruleset can be loaded with:</para>
|
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>pfctl -e ; pfctl -f /etc/pf.conf</userinput></screen>
|
<screen>&prompt.root; <userinput>pfctl -e ; pfctl -f /etc/pf.conf</userinput></screen>
|
||||||
|
|
||||||
<para>In addition to keeping state,
|
<para>In addition to keeping state,
|
||||||
<application>PF</application> provides
|
<application>PF</application> provides
|
||||||
<firstterm>lists</firstterm> and
|
<firstterm>lists</firstterm> and
|
||||||
<firstterm>macros</firstterm> which can be defined for use
|
<firstterm>macros</firstterm> which can be defined for use
|
||||||
when creating rules. Macros can include lists and need to be defined
|
when creating rules. Macros can include lists and need to be
|
||||||
before use. As an example, insert these lines at the
|
defined before use. As an example, insert these lines at the
|
||||||
very top of the ruleset:</para>
|
very top of the ruleset:</para>
|
||||||
|
|
||||||
<programlisting>tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }"
|
<programlisting>tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }"
|
||||||
udp_services = "{ domain }"</programlisting>
|
udp_services = "{ domain }"</programlisting>
|
||||||
|
|
||||||
<para><application>PF</application> understands port
|
<para><application>PF</application> understands port names as
|
||||||
names as well as port numbers, as long as the names are listed
|
well as port numbers, as long as the names are listed in
|
||||||
in <filename>/etc/services</filename>. This example
|
<filename>/etc/services</filename>. This example creates two
|
||||||
creates two macros. The first is a list of seven
|
macros. The first is a list of seven
|
||||||
<acronym>TCP</acronym> port names and the second is one
|
<acronym>TCP</acronym> port names and the second is one
|
||||||
<acronym>UDP</acronym> port name. Once defined, macros can
|
<acronym>UDP</acronym> port name. Once defined, macros can be
|
||||||
be used in rules. In this example, all traffic is blocked
|
used in rules. In this example, all traffic is blocked except
|
||||||
except for the connections initiated by this system for the
|
for the connections initiated by this system for the seven
|
||||||
seven specified <acronym>TCP</acronym> services and the one
|
specified <acronym>TCP</acronym> services and the one
|
||||||
specified <acronym>UDP</acronym> service:</para>
|
specified <acronym>UDP</acronym> service:</para>
|
||||||
|
|
||||||
<programlisting>tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }"
|
<programlisting>tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }"
|
||||||
udp_services = "{ domain }"
|
udp_services = "{ domain }"
|
||||||
block all
|
block all
|
||||||
pass out proto tcp to any port $tcp_services keep state
|
pass out proto tcp to any port $tcp_services keep state
|
||||||
pass proto udp to any port $udp_services keep state</programlisting>
|
pass proto udp to any port $udp_services keep state</programlisting>
|
||||||
|
|
||||||
<para>Even though <acronym>UDP</acronym> is considered to be
|
<para>Even though <acronym>UDP</acronym> is considered to be a
|
||||||
a stateless protocol, <application>PF</application>
|
stateless protocol, <application>PF</application> is able to
|
||||||
is able to track some state information. For example, when a
|
track some state information. For example, when a
|
||||||
<acronym>UDP</acronym> request is passed which
|
<acronym>UDP</acronym> request is passed which asks a name
|
||||||
asks a name server about a domain name, <application>PF</application>
|
server about a domain name, <application>PF</application> will
|
||||||
will watch for the response in order to pass it back.</para>
|
watch for the response in order to pass it back.</para>
|
||||||
|
|
||||||
<para>Whenever an edit is made to a ruleset, the new rules
|
<para>Whenever an edit is made to a ruleset, the new rules must
|
||||||
must be loaded so they can be used:</para>
|
be loaded so they can be used:</para>
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>pfctl -f /etc/pf.conf</userinput></screen>
|
<screen>&prompt.root; <userinput>pfctl -f /etc/pf.conf</userinput></screen>
|
||||||
|
|
||||||
<para>If there are no syntax
|
<para>If there are no syntax errors, <command>pfctl</command>
|
||||||
errors, <command>pfctl</command> will not output any
|
will not output any messages during the rule load. Rules can
|
||||||
messages during the rule load. Rules can also be tested before attempting to load them:</para>
|
also be tested before attempting to load them:</para>
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>pfctl -nf /etc/pf.conf</userinput></screen>
|
<screen>&prompt.root; <userinput>pfctl -nf /etc/pf.conf</userinput></screen>
|
||||||
|
|
||||||
<para>Including <option>-n</option> causes the rules to be interpreted
|
<para>Including <option>-n</option> causes the rules to be
|
||||||
only, but not loaded. This provides an opportunity
|
interpreted only, but not loaded. This provides an
|
||||||
to correct any errors. At all times, the last
|
opportunity to correct any errors. At all times, the last
|
||||||
valid ruleset loaded will be enforced until either
|
valid ruleset loaded will be enforced until either
|
||||||
<application>PF</application> is disabled or a new ruleset
|
<application>PF</application> is disabled or a new ruleset is
|
||||||
is loaded.</para>
|
loaded.</para>
|
||||||
|
|
||||||
<tip>
|
<tip>
|
||||||
<para>Adding <option>-v</option> to a
|
<para>Adding <option>-v</option> to a <command>pfctl</command>
|
||||||
<command>pfctl</command> ruleset verify or load will display the fully parsed rules
|
ruleset verify or load will display the fully parsed rules
|
||||||
exactly the way they will be loaded. This is extremely
|
exactly the way they will be loaded. This is extremely
|
||||||
useful when debugging rules.</para>
|
useful when debugging rules.</para>
|
||||||
</tip>
|
</tip>
|
||||||
|
|
||||||
<sect3 xml:id="pftut-gateway">
|
<sect3 xml:id="pftut-gateway">
|
||||||
<title>A Simple Gateway with NAT</title>
|
<title>A Simple Gateway with NAT</title>
|
||||||
|
|
@ -635,111 +634,109 @@ pass proto udp to any port $udp_services keep state</programlisting>
|
||||||
separate network. For example, one connection is to the
|
separate network. For example, one connection is to the
|
||||||
Internet and the other is to the internal network.</para>
|
Internet and the other is to the internal network.</para>
|
||||||
|
|
||||||
<para>It is reasonable to think that for stateful traffic to
|
<para>It is reasonable to think that for stateful traffic to
|
||||||
pass from the network connected to
|
pass from the network connected to <filename>xl1</filename>
|
||||||
<filename>xl1</filename> to hosts on the network
|
to hosts on the network connected to
|
||||||
connected to <filename>xl0</filename>, a rule like
|
<filename>xl0</filename>, a rule like this is needed:</para>
|
||||||
this is needed:</para>
|
|
||||||
|
|
||||||
<programlisting>pass in on xl1 from xl1:network to xl0:network port $ports keep state</programlisting>
|
<programlisting>pass in on xl1 from xl1:network to xl0:network port $ports keep state</programlisting>
|
||||||
|
|
||||||
<para>However, the <quote>to</quote> keyword does
|
<para>However, the <quote>to</quote> keyword does
|
||||||
guarantee passage all the way from source to destination. This rule
|
guarantee passage all the way from source to destination.
|
||||||
only lets the traffic pass in to the gateway on
|
This rule only lets the traffic pass in to the gateway on
|
||||||
the internal interface. To let the packets go
|
the internal interface. To let the packets go further, a
|
||||||
further, a matching rule is needed:</para>
|
matching rule is needed:</para>
|
||||||
|
|
||||||
<programlisting>pass out on xl0 from xl1:network to xl0:network port $ports keep state</programlisting>
|
<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
|
<para>These rules will work, but they will not necessarily
|
||||||
achieve the desired effect.</para>
|
achieve the desired effect.</para>
|
||||||
|
|
||||||
<para>Rules this specific are rarely needed. A
|
<para>Rules this specific are rarely needed. A better rule
|
||||||
better rule says:</para>
|
says:</para>
|
||||||
|
|
||||||
<programlisting>pass from xl1:network to any port $ports keep state</programlisting>
|
<programlisting>pass from xl1:network to any port $ports keep state</programlisting>
|
||||||
|
|
||||||
<para>This provides local network access to the Internet and
|
<para>This provides local network access to the Internet and
|
||||||
leaves the detective work to the
|
leaves the detective work to the
|
||||||
<firstterm>antispoof</firstterm> and
|
<firstterm>antispoof</firstterm> and
|
||||||
<firstterm>scrub</firstterm> code.</para>
|
<firstterm>scrub</firstterm> code.</para>
|
||||||
|
|
||||||
<para>For a busy network admin, a readable ruleset is a
|
<para>For a busy network admin, a readable ruleset is a safer
|
||||||
safer ruleset. For the remainder of this section, with some
|
ruleset. For the remainder of this section, with some
|
||||||
exceptions, we will keep the rules as simple as possible
|
exceptions, we will keep the rules as simple as possible
|
||||||
for readability.</para>
|
for readability.</para>
|
||||||
|
|
||||||
<para>Above, we introduced the
|
<para>Above, we introduced the
|
||||||
<literal>interface:network</literal> notation. That is a
|
<literal>interface:network</literal> notation. That is a
|
||||||
nice piece of shorthand, but the ruleset can be made even
|
nice piece of shorthand, but the ruleset can be made even
|
||||||
more readable and maintainable by taking the macro use a
|
more readable and maintainable by taking the macro use a
|
||||||
tiny bit further.</para>
|
tiny bit further.</para>
|
||||||
|
|
||||||
<para>For example, a <literal>$localnet</literal> macro
|
<para>For example, a <literal>$localnet</literal> macro could
|
||||||
could be defined as the network directly attached to your
|
be defined as the network directly attached to your
|
||||||
internal interface (<literal>$xl1:network</literal> in the
|
internal interface (<literal>$xl1:network</literal> in the
|
||||||
examples above).</para>
|
examples above).</para>
|
||||||
|
|
||||||
<para>Alternatively, the definition of
|
<para>Alternatively, the definition of
|
||||||
<literal>$localnet</literal> could be changed to an
|
<literal>$localnet</literal> could be changed to an
|
||||||
<emphasis>IP address/netmask</emphasis> notation to denote
|
<emphasis>IP address/netmask</emphasis> notation to denote
|
||||||
a network, such as <literal>192.168.100.1/24</literal> for
|
a network, such as <literal>192.168.100.1/24</literal> for
|
||||||
a subnet of private addresses.</para>
|
a subnet of private addresses.</para>
|
||||||
|
|
||||||
<para>If required, <literal>$localnet</literal> could even
|
<para>If required, <literal>$localnet</literal> could even be
|
||||||
be defined as a list of networks. Whatever the specific
|
defined as a list of networks. Whatever the specific needs,
|
||||||
needs, a sensible <literal>$localnet</literal> definition
|
a sensible <literal>$localnet</literal> definition and a
|
||||||
and a typical pass rule of the type</para>
|
typical pass rule of the type</para>
|
||||||
|
|
||||||
<programlisting>pass from $localnet to any port $ports keep state</programlisting>
|
<programlisting>pass from $localnet to any port $ports keep state</programlisting>
|
||||||
|
|
||||||
<para>could end up saving you a few headaches. We will
|
<para>could end up saving you a few headaches. We will stick
|
||||||
stick to that convention from here on.</para>
|
to that convention from here on.</para>
|
||||||
|
|
||||||
<para>First, we need to turn on gatewaying in order to let
|
<para>First, we need to turn on gatewaying in order to let the
|
||||||
the machine forward the network traffic it receives on one
|
machine forward the network traffic it receives on one
|
||||||
interface to other networks via a separate interface.
|
interface to other networks via a separate interface.
|
||||||
Initially we will do this on the command line with
|
Initially we will do this on the command line with
|
||||||
&man.sysctl.8;, for traditional
|
&man.sysctl.8;, for traditional <emphasis>IP version
|
||||||
<emphasis>IP version four</emphasis>.</para>
|
four</emphasis>.</para>
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>sysctl net.inet.ip.forwarding=1</userinput></screen>
|
<screen>&prompt.root; <userinput>sysctl net.inet.ip.forwarding=1</userinput></screen>
|
||||||
|
|
||||||
<para>If we need to forward <emphasis>IP version
|
<para>If we need to forward <emphasis>IP version
|
||||||
six</emphasis> traffic, the command is</para>
|
six</emphasis> traffic, the command is</para>
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>sysctl net.inet6.ip6.forwarding=1</userinput></screen>
|
<screen>&prompt.root; <userinput>sysctl net.inet6.ip6.forwarding=1</userinput></screen>
|
||||||
|
|
||||||
<para>In order for this to continue working after the
|
<para>In order for this to continue working after the
|
||||||
computer has been restarted at some time in the future,
|
computer has been restarted at some time in the future,
|
||||||
enter these settings into
|
enter these settings into
|
||||||
<filename>/etc/rc.conf</filename>:</para>
|
<filename>/etc/rc.conf</filename>:</para>
|
||||||
|
|
||||||
<programlisting>gateway_enable="YES" #for ipv4
|
<programlisting>gateway_enable="YES" #for ipv4
|
||||||
ipv6_gateway_enable="YES" #for ipv6</programlisting>
|
ipv6_gateway_enable="YES" #for ipv6</programlisting>
|
||||||
|
|
||||||
<para>Use <command>ifconfig -a</command>, or
|
<para>Use <command>ifconfig -a</command>, or
|
||||||
<command>ifconfig
|
<command>ifconfig interface_name</command> to find out if
|
||||||
interface_name</command> to
|
both of the interfaces to be used are up and
|
||||||
find out if both of the interfaces to be used are up and
|
running.</para>
|
||||||
running.</para>
|
|
||||||
|
|
||||||
<para>If all traffic initiated by machines on the inside is
|
<para>If all traffic initiated by machines on the inside is to
|
||||||
to be allowed, <filename>/etc/pf.conf</filename> could
|
be allowed, <filename>/etc/pf.conf</filename> could look
|
||||||
look roughly like this
|
roughly like this
|
||||||
<footnote>
|
<footnote>
|
||||||
<para>For dialup users, the external interface is the
|
<para>For dialup users, the external interface is the
|
||||||
<filename>tun0</filename> pseudo-device. Broadband
|
<filename>tun0</filename> pseudo-device. Broadband
|
||||||
users such as ADSL subscribers tend to have an
|
users such as ADSL subscribers tend to have an
|
||||||
Ethernet interface to play with, however for a
|
Ethernet interface to play with, however for a
|
||||||
significant subset of ADSL users, specifically those
|
significant subset of ADSL users, specifically those
|
||||||
using PPP over Ethernet (PPPoE), the correct external
|
using PPP over Ethernet (PPPoE), the correct external
|
||||||
interface will be the <filename>tun0</filename>
|
interface will be the <filename>tun0</filename>
|
||||||
pseudo-device, not the physical Ethernet
|
pseudo-device, not the physical Ethernet
|
||||||
interface.</para>
|
interface.</para>
|
||||||
</footnote>:</para>
|
</footnote>:</para>
|
||||||
|
|
||||||
<programlisting>ext_if = "xl0" # macro for external interface - use tun0 for PPPoE
|
<programlisting>ext_if = "xl0" # macro for external interface - use tun0 for PPPoE
|
||||||
int_if = "xl1" # macro for internal interface
|
int_if = "xl1" # macro for internal interface
|
||||||
localnet = $int_if:network
|
localnet = $int_if:network
|
||||||
# ext_if IP address could be dynamic, hence ($ext_if)
|
# ext_if IP address could be dynamic, hence ($ext_if)
|
||||||
|
|
@ -747,77 +744,77 @@ nat on $ext_if from $localnet to any -> ($ext_if)
|
||||||
block all
|
block all
|
||||||
pass from { lo0, $localnet } to any keep state</programlisting>
|
pass from { lo0, $localnet } to any keep state</programlisting>
|
||||||
|
|
||||||
<para>Note the use of macros to assign logical names to the
|
<para>Note the use of macros to assign logical names to the
|
||||||
network interfaces. Here 3Com cards are used, but this is
|
network interfaces. Here 3Com cards are used, but this is
|
||||||
the last time during this tutorial we will find this of
|
the last time during this tutorial we will find this of
|
||||||
any interest whatsoever. In truly simple setups like this
|
any interest whatsoever. In truly simple setups like this
|
||||||
one, we may not gain very much by using macros like these,
|
one, we may not gain very much by using macros like these,
|
||||||
but once the rulesets grow somewhat larger, you will
|
but once the rulesets grow somewhat larger, you will
|
||||||
learn to appreciate the readability this provides.</para>
|
learn to appreciate the readability this provides.</para>
|
||||||
|
|
||||||
<para>Also note the <literal>nat</literal> rule. This is
|
<para>Also note the <literal>nat</literal> rule. This is
|
||||||
where we handle the network address translation from the
|
where we handle the network address translation from the
|
||||||
non-routable address inside the local net to the sole
|
non-routable address inside the local net to the sole
|
||||||
official address we assume has been assigned.</para>
|
official address we assume has been assigned.</para>
|
||||||
|
|
||||||
<para>The parentheses surrounding the last part of the nat
|
<para>The parentheses surrounding the last part of the nat
|
||||||
rule <literal>($ext_if)</literal> are there to compensate
|
rule <literal>($ext_if)</literal> are there to compensate
|
||||||
for the possibility that the IP address of the external
|
for the possibility that the IP address of the external
|
||||||
interface may be dynamically assigned. This detail will
|
interface may be dynamically assigned. This detail will
|
||||||
ensure that network traffic runs without serious
|
ensure that network traffic runs without serious
|
||||||
interruptions even if the external IP address
|
interruptions even if the external IP address
|
||||||
changes.</para>
|
changes.</para>
|
||||||
|
|
||||||
<para>On the other hand, this ruleset probably allows more
|
<para>On the other hand, this ruleset probably allows more
|
||||||
traffic to pass out of the network than actually desired.
|
traffic to pass out of the network than actually desired.
|
||||||
One reasonable setup could contain the macro</para>
|
One reasonable setup could contain the macro</para>
|
||||||
|
|
||||||
<programlisting>client_out = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \
|
<programlisting>client_out = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \
|
||||||
https, cvspserver, 2628, 5999, 8000, 8080 }"</programlisting>
|
https, cvspserver, 2628, 5999, 8000, 8080 }"</programlisting>
|
||||||
|
|
||||||
<para>and the main pass rule</para>
|
<para>and the main pass rule</para>
|
||||||
|
|
||||||
<programlisting>pass inet proto tcp from $localnet to any port $client_out \
|
<programlisting>pass inet proto tcp from $localnet to any port $client_out \
|
||||||
flags S/SA keep state</programlisting>
|
flags S/SA keep state</programlisting>
|
||||||
|
|
||||||
<para>In addition, we have a few other pass rules. One pass rule which is useful for
|
<para>In addition, we have a few other pass rules. One pass
|
||||||
administering machines remotely
|
rule which is useful for administering machines remotely
|
||||||
is:</para>
|
is:</para>
|
||||||
|
|
||||||
<programlisting>pass in inet proto tcp to $ext_if port ssh</programlisting>
|
<programlisting>pass in inet proto tcp to $ext_if port ssh</programlisting>
|
||||||
|
|
||||||
<para>Lastly we need to make the
|
<para>Lastly we need to make the name service work for our
|
||||||
name service work for our clients:</para>
|
clients:</para>
|
||||||
|
|
||||||
<programlisting>udp_services = "{ domain, ntp }"</programlisting>
|
<programlisting>udp_services = "{ domain, ntp }"</programlisting>
|
||||||
|
|
||||||
<para>This is supplemented with a rule which passes the
|
<para>This is supplemented with a rule which passes the
|
||||||
traffic we want through our firewall:</para>
|
traffic we want through our firewall:</para>
|
||||||
|
|
||||||
<programlisting>pass quick inet proto { tcp, udp } to any port $udp_services keep state</programlisting>
|
<programlisting>pass quick inet proto { tcp, udp } to any port $udp_services keep state</programlisting>
|
||||||
|
|
||||||
<para>Note the <literal>quick</literal> keyword in this
|
<para>Note the <literal>quick</literal> keyword in this
|
||||||
rule. We have started writing rulesets which consist of
|
rule. We have started writing rulesets which consist of
|
||||||
several rules, and it is time to take a look at the
|
several rules, and it is time to take a look at the
|
||||||
relationships between the rules in a ruleset. The rules
|
relationships between the rules in a ruleset. The rules
|
||||||
are evaluated from top to bottom, in the sequence they are
|
are evaluated from top to bottom, in the sequence they are
|
||||||
written in the configuration file. For each packet or
|
written in the configuration file. For each packet or
|
||||||
connection evaluated by <application>PF</application>,
|
connection evaluated by <application>PF</application>,
|
||||||
<emphasis>the last matching rule</emphasis> in the rule
|
<emphasis>the last matching rule</emphasis> in the rule
|
||||||
set is the one which is applied. The
|
set is the one which is applied. The
|
||||||
<literal>quick</literal> keyword offers an escape from the
|
<literal>quick</literal> keyword offers an escape from the
|
||||||
ordinary sequence. When a packet matches a quick rule,
|
ordinary sequence. When a packet matches a quick rule,
|
||||||
the packet is treated according to the present rule. The
|
the packet is treated according to the present rule. The
|
||||||
rule processing stops without considering any further
|
rule processing stops without considering any further
|
||||||
rules which might have matched the packet. This is very
|
rules which might have matched the packet. This is very
|
||||||
useful when a few isolated exceptions to the general rules
|
useful when a few isolated exceptions to the general rules
|
||||||
are needed.</para>
|
are needed.</para>
|
||||||
|
|
||||||
<para>This rule also takes care of <acronym>NTP</acronym>,
|
<para>This rule also takes care of <acronym>NTP</acronym>,
|
||||||
which is used for time synchronization. One thing common
|
which is used for time synchronization. One thing common
|
||||||
to both protocols is that they may under certain
|
to both protocols is that they may under certain
|
||||||
circumstances communicate alternately over TCP and
|
circumstances communicate alternately over TCP and
|
||||||
UDP.</para>
|
UDP.</para>
|
||||||
</sect3>
|
</sect3>
|
||||||
|
|
||||||
<sect3 xml:id="pftut-ftp">
|
<sect3 xml:id="pftut-ftp">
|
||||||
|
|
@ -870,94 +867,94 @@ pass from { lo0, $localnet } to any keep state</programlisting>
|
||||||
program which is written specifically for this
|
program which is written specifically for this
|
||||||
purpose.</para>
|
purpose.</para>
|
||||||
|
|
||||||
<para>Enabling <acronym>FTP</acronym> transfers through your
|
<para>Enabling <acronym>FTP</acronym> transfers through your
|
||||||
gateway is amazingly simple, thanks to the
|
gateway is amazingly simple, thanks to the
|
||||||
<acronym>FTP</acronym> proxy program (called
|
<acronym>FTP</acronym> proxy program (called
|
||||||
&man.ftp-proxy.8;) included in the base system on &os; and
|
&man.ftp-proxy.8;) included in the base system on &os; and
|
||||||
other systems which offer
|
other systems which offer
|
||||||
<application>PF</application>.</para>
|
<application>PF</application>.</para>
|
||||||
|
|
||||||
<para>The <acronym>FTP</acronym> protocol being what it is,
|
<para>The <acronym>FTP</acronym> protocol being what it is,
|
||||||
the proxy needs to dynamically insert rules in your rule
|
the proxy needs to dynamically insert rules in your rule
|
||||||
set. &man.ftp-proxy.8; interacts with your configuration
|
set. &man.ftp-proxy.8; interacts with your configuration
|
||||||
via a set of anchors where the proxy inserts and deletes
|
via a set of anchors where the proxy inserts and deletes
|
||||||
the rules it constructs to handle your
|
the rules it constructs to handle your
|
||||||
<acronym>FTP</acronym> traffic.</para>
|
<acronym>FTP</acronym> traffic.</para>
|
||||||
|
|
||||||
<para>To enable &man.ftp-proxy.8;, add this line to
|
<para>To enable &man.ftp-proxy.8;, add this line to
|
||||||
<filename>/etc/rc.conf</filename>:</para>
|
<filename>/etc/rc.conf</filename>:</para>
|
||||||
|
|
||||||
<programlisting>ftpproxy_enable="YES"</programlisting>
|
<programlisting>ftpproxy_enable="YES"</programlisting>
|
||||||
|
|
||||||
<para>Starting the proxy manually by running
|
<para>Starting the proxy manually by running
|
||||||
<command>/usr/sbin/ftp-proxy</command> allows testing of
|
<command>/usr/sbin/ftp-proxy</command> allows testing of
|
||||||
the <application>PF</application> configuration changes we
|
the <application>PF</application> configuration changes we
|
||||||
are about to make.</para>
|
are about to make.</para>
|
||||||
|
|
||||||
<para>For a basic configuration, only three elements need to
|
<para>For a basic configuration, only three elements need to
|
||||||
be added to <filename>/etc/pf.conf</filename>. First, the
|
be added to <filename>/etc/pf.conf</filename>. First, the
|
||||||
anchors:</para>
|
anchors:</para>
|
||||||
|
|
||||||
<programlisting>nat-anchor "ftp-proxy/*"
|
<programlisting>nat-anchor "ftp-proxy/*"
|
||||||
rdr-anchor "ftp-proxy/*"</programlisting>
|
rdr-anchor "ftp-proxy/*"</programlisting>
|
||||||
|
|
||||||
<para>The proxy will insert the rules it generates for the
|
<para>The proxy will insert the rules it generates for the
|
||||||
<acronym>FTP</acronym> sessions here. A pass rule is
|
<acronym>FTP</acronym> sessions here. A pass rule is
|
||||||
needed to let <acronym>FTP</acronym> traffic in to the
|
needed to let <acronym>FTP</acronym> traffic in to the
|
||||||
proxy.</para>
|
proxy.</para>
|
||||||
|
|
||||||
<para>Now for the actual redirection. Redirection rules and
|
<para>Now for the actual redirection. Redirection rules and
|
||||||
<acronym>NAT</acronym> rules fall into the same rule
|
<acronym>NAT</acronym> rules fall into the same rule
|
||||||
class. These rules may be referenced directly by other
|
class. These rules may be referenced directly by other
|
||||||
rules, and filtering rules may depend on these rules.
|
rules, and filtering rules may depend on these rules.
|
||||||
Logically, <literal>rdr</literal> and
|
Logically, <literal>rdr</literal> and
|
||||||
<literal>nat</literal> rules need to be defined before the
|
<literal>nat</literal> rules need to be defined before the
|
||||||
filtering rules.</para>
|
filtering rules.</para>
|
||||||
|
|
||||||
<para>We insert our <literal>rdr</literal> rule immediately
|
<para>We insert our <literal>rdr</literal> rule immediately
|
||||||
after the <literal>nat</literal> rule in
|
after the <literal>nat</literal> rule in
|
||||||
<filename>/etc/pf.conf</filename></para>
|
<filename>/etc/pf.conf</filename></para>
|
||||||
|
|
||||||
<programlisting>rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021</programlisting>
|
<programlisting>rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021</programlisting>
|
||||||
|
|
||||||
<para>In addition, the redirected traffic must be allowed to
|
<para>In addition, the redirected traffic must be allowed to
|
||||||
pass. We achieve this with</para>
|
pass. We achieve this with</para>
|
||||||
|
|
||||||
<programlisting>pass out proto tcp from $proxy to any port ftp</programlisting>
|
<programlisting>pass out proto tcp from $proxy to any port ftp</programlisting>
|
||||||
|
|
||||||
<para>where <literal>$proxy</literal> expands to the address
|
<para>where <literal>$proxy</literal> expands to the address
|
||||||
the proxy daemon is bound to.</para>
|
the proxy daemon is bound to.</para>
|
||||||
|
|
||||||
<para>Save <filename>pf.conf</filename>, then load the new
|
<para>Save <filename>pf.conf</filename>, then load the new
|
||||||
rules with</para>
|
rules with</para>
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>pfctl -f /etc/pf.conf</userinput></screen>
|
<screen>&prompt.root; <userinput>pfctl -f /etc/pf.conf</userinput></screen>
|
||||||
|
|
||||||
<para>At this point, users will probably begin noticing
|
<para>At this point, users will probably begin noticing
|
||||||
that <acronym>FTP</acronym> works before they have been
|
that <acronym>FTP</acronym> works before they have been
|
||||||
told.</para>
|
told.</para>
|
||||||
|
|
||||||
<para>This example covers a basic setup where the clients in
|
<para>This example covers a basic setup where the clients in
|
||||||
the local net need to contact <acronym>FTP</acronym>
|
the local net need to contact <acronym>FTP</acronym>
|
||||||
servers elsewhere. The basic configuration here should
|
servers elsewhere. The basic configuration here should
|
||||||
work well with most combinations of <acronym>FTP</acronym>
|
work well with most combinations of <acronym>FTP</acronym>
|
||||||
clients and servers. As shown in the man page, the
|
clients and servers. As shown in the man page, the
|
||||||
proxy's behavior can be changed in various ways by adding
|
proxy's behavior can be changed in various ways by adding
|
||||||
options to the <literal>ftpproxy_flags=</literal> line.
|
options to the <literal>ftpproxy_flags=</literal> line.
|
||||||
Some clients or servers may have specific quirks that must
|
Some clients or servers may have specific quirks that must
|
||||||
be compensated for in the configuration, or there may be a
|
be compensated for in the configuration, or there may be a
|
||||||
need to integrate the proxy in specific ways such as
|
need to integrate the proxy in specific ways such as
|
||||||
assigning <acronym>FTP</acronym> traffic to a specific
|
assigning <acronym>FTP</acronym> traffic to a specific
|
||||||
queue. For these and other finer points of
|
queue. For these and other finer points of
|
||||||
&man.ftp-proxy.8; configuration, start by studying the man
|
&man.ftp-proxy.8; configuration, start by studying the man
|
||||||
page.</para>
|
page.</para>
|
||||||
|
|
||||||
<para>For ways to run an <acronym>FTP</acronym> server
|
<para>For ways to run an <acronym>FTP</acronym> server
|
||||||
protected by <application>PF</application> and
|
protected by <application>PF</application> and
|
||||||
&man.ftp-proxy.8;, look into running a separate
|
&man.ftp-proxy.8;, look into running a separate
|
||||||
<command>ftp-proxy</command> in reverse mode (using
|
<command>ftp-proxy</command> in reverse mode (using
|
||||||
<option>-R</option>), on a separate port with its own
|
<option>-R</option>), on a separate port with its own
|
||||||
redirecting pass rule.</para>
|
redirecting pass rule.</para>
|
||||||
</sect3>
|
</sect3>
|
||||||
|
|
||||||
<sect3 xml:id="pftut-icmp">
|
<sect3 xml:id="pftut-icmp">
|
||||||
|
|
@ -1011,36 +1008,36 @@ rdr-anchor "ftp-proxy/*"</programlisting>
|
||||||
these rulesets have been around for roughly fifteen years,
|
these rulesets have been around for roughly fifteen years,
|
||||||
and the people who put them there are still scared.</para>
|
and the people who put them there are still scared.</para>
|
||||||
|
|
||||||
<para>The obvious question then becomes, if
|
<para>The obvious question then becomes, if
|
||||||
<acronym>ICMP</acronym> is such a good and useful thing,
|
<acronym>ICMP</acronym> is such a good and useful thing,
|
||||||
should we not let it all through, all the time? The
|
should we not let it all through, all the time? The
|
||||||
answer is <quote>It depends</quote>.</para>
|
answer is <quote>It depends</quote>.</para>
|
||||||
|
|
||||||
<para>Letting diagnostic traffic pass unconditionally of
|
<para>Letting diagnostic traffic pass unconditionally of
|
||||||
course makes debugging easier, but also makes it
|
course makes debugging easier, but also makes it
|
||||||
relatively easy for others to extract information about
|
relatively easy for others to extract information about
|
||||||
your network. That means that a rule like</para>
|
your network. That means that a rule like</para>
|
||||||
|
|
||||||
<programlisting>pass inet proto icmp from any to any</programlisting>
|
<programlisting>pass inet proto icmp from any to any</programlisting>
|
||||||
|
|
||||||
<para>might not be optimal if the internal workings of the
|
<para>might not be optimal if the internal workings of the
|
||||||
local network should be cloaked in a bit of mystery. In
|
local network should be cloaked in a bit of mystery. In
|
||||||
all fairness it should also be said that some
|
all fairness it should also be said that some
|
||||||
<acronym>ICMP</acronym> traffic might be found quite
|
<acronym>ICMP</acronym> traffic might be found quite
|
||||||
harmlessly riding piggyback on
|
harmlessly riding piggyback on
|
||||||
<literal>keep state</literal> rules.</para>
|
<literal>keep state</literal> rules.</para>
|
||||||
|
|
||||||
<para>The easiest solution could very well be to let all
|
<para>The easiest solution could very well be to let all
|
||||||
<acronym>ICMP</acronym> traffic from the local net through
|
<acronym>ICMP</acronym> traffic from the local net through
|
||||||
and stop probes from elsewhere at the gateway:</para>
|
and stop probes from elsewhere at the gateway:</para>
|
||||||
|
|
||||||
<programlisting>pass inet proto icmp from $localnet to any keep state
|
<programlisting>pass inet proto icmp from $localnet to any keep state
|
||||||
pass inet proto icmp from any to $ext_if keep state</programlisting>
|
pass inet proto icmp from any to $ext_if keep state</programlisting>
|
||||||
|
|
||||||
<para>Stopping probes at the gateway might be an attractive
|
<para>Stopping probes at the gateway might be an attractive
|
||||||
option anyway, but let us have a look at a few other
|
option anyway, but let us have a look at a few other
|
||||||
options which will show some of
|
options which will show some of
|
||||||
<application>PF</application>'s flexibility.</para>
|
<application>PF</application>'s flexibility.</para>
|
||||||
|
|
||||||
<sect4 xml:id="pftut-letpingthru">
|
<sect4 xml:id="pftut-letpingthru">
|
||||||
<title>Letting <command>ping</command> Through</title>
|
<title>Letting <command>ping</command> Through</title>
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue