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
|
@ -545,85 +545,84 @@ options ALTQ_PRIQ # Priority Queuing (PRIQ)</programlisting>
|
|||
real-world usage of <application>PF</application>'s many
|
||||
features.</para>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<programlisting>block in all
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<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,
|
||||
<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
|
||||
very top of the ruleset:</para>
|
||||
<para>In addition to keeping state,
|
||||
<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
|
||||
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>
|
||||
|
||||
<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
|
||||
specified <acronym>UDP</acronym> service:</para>
|
||||
<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
|
||||
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 }"
|
||||
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>
|
||||
<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>
|
||||
<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
|
||||
valid ruleset loaded will be enforced until either
|
||||
<application>PF</application> is disabled or a new ruleset
|
||||
is loaded.</para>
|
||||
<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>
|
||||
|
||||
<tip>
|
||||
<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>
|
||||
<tip>
|
||||
<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>
|
||||
|
||||
<sect3 xml:id="pftut-gateway">
|
||||
<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
|
||||
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>
|
||||
<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>
|
||||
|
||||
<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
|
||||
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>
|
||||
<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>
|
||||
|
||||
<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
|
||||
achieve the desired effect.</para>
|
||||
<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>
|
||||
<programlisting>pass from xl1:network to any port $ports keep state</programlisting>
|
||||
|
||||
<para>This provides local network access to the Internet and
|
||||
leaves the detective work to the
|
||||
<firstterm>antispoof</firstterm> and
|
||||
<firstterm>scrub</firstterm> code.</para>
|
||||
<para>This provides local network access to the Internet and
|
||||
leaves the detective work to the
|
||||
<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
|
||||
exceptions, we will keep the rules as simple as possible
|
||||
for readability.</para>
|
||||
<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>
|
||||
|
||||
<para>Above, we introduced the
|
||||
<literal>interface:network</literal> notation. That is a
|
||||
nice piece of shorthand, but the ruleset can be made even
|
||||
more readable and maintainable by taking the macro use a
|
||||
tiny bit further.</para>
|
||||
<para>Above, we introduced the
|
||||
<literal>interface:network</literal> notation. That is a
|
||||
nice piece of shorthand, but the ruleset can be made even
|
||||
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
|
||||
internal interface (<literal>$xl1:network</literal> in the
|
||||
examples above).</para>
|
||||
<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>
|
||||
|
||||
<para>Alternatively, the definition of
|
||||
<literal>$localnet</literal> could be changed to an
|
||||
<emphasis>IP address/netmask</emphasis> notation to denote
|
||||
a network, such as <literal>192.168.100.1/24</literal> for
|
||||
a subnet of private addresses.</para>
|
||||
<para>Alternatively, the definition of
|
||||
<literal>$localnet</literal> could be changed to an
|
||||
<emphasis>IP address/netmask</emphasis> notation to denote
|
||||
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>
|
||||
<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
|
||||
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>
|
||||
<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>
|
||||
|
||||
<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
|
||||
six</emphasis> traffic, the command is</para>
|
||||
<para>If we need to forward <emphasis>IP version
|
||||
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
|
||||
computer has been restarted at some time in the future,
|
||||
enter these settings into
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
<para>In order for this to continue working after the
|
||||
computer has been restarted at some time in the future,
|
||||
enter these settings into
|
||||
<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>
|
||||
|
||||
<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
|
||||
running.</para>
|
||||
<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
|
||||
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
|
||||
<footnote>
|
||||
<para>For dialup users, the external interface is the
|
||||
<filename>tun0</filename> pseudo-device. Broadband
|
||||
users such as ADSL subscribers tend to have an
|
||||
Ethernet interface to play with, however for a
|
||||
significant subset of ADSL users, specifically those
|
||||
using PPP over Ethernet (PPPoE), the correct external
|
||||
interface will be the <filename>tun0</filename>
|
||||
pseudo-device, not the physical Ethernet
|
||||
interface.</para>
|
||||
</footnote>:</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
|
||||
<footnote>
|
||||
<para>For dialup users, the external interface is the
|
||||
<filename>tun0</filename> pseudo-device. Broadband
|
||||
users such as ADSL subscribers tend to have an
|
||||
Ethernet interface to play with, however for a
|
||||
significant subset of ADSL users, specifically those
|
||||
using PPP over Ethernet (PPPoE), the correct external
|
||||
interface will be the <filename>tun0</filename>
|
||||
pseudo-device, not the physical Ethernet
|
||||
interface.</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
|
||||
localnet = $int_if:network
|
||||
# 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
|
||||
pass from { lo0, $localnet } to any keep state</programlisting>
|
||||
|
||||
<para>Note the use of macros to assign logical names to the
|
||||
network interfaces. Here 3Com cards are used, but this is
|
||||
the last time during this tutorial we will find this of
|
||||
any interest whatsoever. In truly simple setups like this
|
||||
one, we may not gain very much by using macros like these,
|
||||
but once the rulesets grow somewhat larger, you will
|
||||
learn to appreciate the readability this provides.</para>
|
||||
<para>Note the use of macros to assign logical names to the
|
||||
network interfaces. Here 3Com cards are used, but this is
|
||||
the last time during this tutorial we will find this of
|
||||
any interest whatsoever. In truly simple setups like this
|
||||
one, we may not gain very much by using macros like these,
|
||||
but once the rulesets grow somewhat larger, you will
|
||||
learn to appreciate the readability this provides.</para>
|
||||
|
||||
<para>Also note the <literal>nat</literal> rule. This is
|
||||
where we handle the network address translation from the
|
||||
non-routable address inside the local net to the sole
|
||||
official address we assume has been assigned.</para>
|
||||
<para>Also note the <literal>nat</literal> rule. This is
|
||||
where we handle the network address translation from the
|
||||
non-routable address inside the local net to the sole
|
||||
official address we assume has been assigned.</para>
|
||||
|
||||
<para>The parentheses surrounding the last part of the nat
|
||||
rule <literal>($ext_if)</literal> are there to compensate
|
||||
for the possibility that the IP address of the external
|
||||
interface may be dynamically assigned. This detail will
|
||||
ensure that network traffic runs without serious
|
||||
interruptions even if the external IP address
|
||||
changes.</para>
|
||||
<para>The parentheses surrounding the last part of the nat
|
||||
rule <literal>($ext_if)</literal> are there to compensate
|
||||
for the possibility that the IP address of the external
|
||||
interface may be dynamically assigned. This detail will
|
||||
ensure that network traffic runs without serious
|
||||
interruptions even if the external IP address
|
||||
changes.</para>
|
||||
|
||||
<para>On the other hand, this ruleset probably allows more
|
||||
traffic to pass out of the network than actually desired.
|
||||
One reasonable setup could contain the macro</para>
|
||||
<para>On the other hand, this ruleset probably allows more
|
||||
traffic to pass out of the network than actually desired.
|
||||
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>
|
||||
|
||||
<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>
|
||||
|
||||
<para>In addition, we have a few other pass rules. One pass rule which is useful for
|
||||
administering machines remotely
|
||||
is:</para>
|
||||
<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>
|
||||
<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>
|
||||
<programlisting>udp_services = "{ domain, ntp }"</programlisting>
|
||||
|
||||
<para>This is supplemented with a rule which passes the
|
||||
traffic we want through our firewall:</para>
|
||||
<para>This is supplemented with a rule which passes the
|
||||
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
|
||||
rule. We have started writing rulesets which consist of
|
||||
several rules, and it is time to take a look at the
|
||||
relationships between the rules in a ruleset. The rules
|
||||
are evaluated from top to bottom, in the sequence they are
|
||||
written in the configuration file. For each packet or
|
||||
connection evaluated by <application>PF</application>,
|
||||
<emphasis>the last matching rule</emphasis> in the rule
|
||||
set is the one which is applied. The
|
||||
<literal>quick</literal> keyword offers an escape from the
|
||||
ordinary sequence. When a packet matches a quick rule,
|
||||
the packet is treated according to the present rule. The
|
||||
rule processing stops without considering any further
|
||||
rules which might have matched the packet. This is very
|
||||
useful when a few isolated exceptions to the general rules
|
||||
are needed.</para>
|
||||
<para>Note the <literal>quick</literal> keyword in this
|
||||
rule. We have started writing rulesets which consist of
|
||||
several rules, and it is time to take a look at the
|
||||
relationships between the rules in a ruleset. The rules
|
||||
are evaluated from top to bottom, in the sequence they are
|
||||
written in the configuration file. For each packet or
|
||||
connection evaluated by <application>PF</application>,
|
||||
<emphasis>the last matching rule</emphasis> in the rule
|
||||
set is the one which is applied. The
|
||||
<literal>quick</literal> keyword offers an escape from the
|
||||
ordinary sequence. When a packet matches a quick rule,
|
||||
the packet is treated according to the present rule. The
|
||||
rule processing stops without considering any further
|
||||
rules which might have matched the packet. This is very
|
||||
useful when a few isolated exceptions to the general rules
|
||||
are needed.</para>
|
||||
|
||||
<para>This rule also takes care of <acronym>NTP</acronym>,
|
||||
which is used for time synchronization. One thing common
|
||||
to both protocols is that they may under certain
|
||||
circumstances communicate alternately over TCP and
|
||||
UDP.</para>
|
||||
<para>This rule also takes care of <acronym>NTP</acronym>,
|
||||
which is used for time synchronization. One thing common
|
||||
to both protocols is that they may under certain
|
||||
circumstances communicate alternately over TCP and
|
||||
UDP.</para>
|
||||
</sect3>
|
||||
|
||||
<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
|
||||
purpose.</para>
|
||||
|
||||
<para>Enabling <acronym>FTP</acronym> transfers through your
|
||||
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>
|
||||
<para>Enabling <acronym>FTP</acronym> transfers through your
|
||||
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>
|
||||
|
||||
<para>The <acronym>FTP</acronym> protocol being what it is,
|
||||
the proxy needs to dynamically insert rules in your rule
|
||||
set. &man.ftp-proxy.8; interacts with your configuration
|
||||
via a set of anchors where the proxy inserts and deletes
|
||||
the rules it constructs to handle your
|
||||
<acronym>FTP</acronym> traffic.</para>
|
||||
<para>The <acronym>FTP</acronym> protocol being what it is,
|
||||
the proxy needs to dynamically insert rules in your rule
|
||||
set. &man.ftp-proxy.8; interacts with your configuration
|
||||
via a set of anchors where the proxy inserts and deletes
|
||||
the rules it constructs to handle your
|
||||
<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>
|
||||
|
||||
<programlisting>ftpproxy_enable="YES"</programlisting>
|
||||
<programlisting>ftpproxy_enable="YES"</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>
|
||||
<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>
|
||||
|
||||
<para>For a basic configuration, only three elements need to
|
||||
be added to <filename>/etc/pf.conf</filename>. First, the
|
||||
anchors:</para>
|
||||
<para>For a basic configuration, only three elements need to
|
||||
be added to <filename>/etc/pf.conf</filename>. First, the
|
||||
anchors:</para>
|
||||
|
||||
<programlisting>nat-anchor "ftp-proxy/*"
|
||||
<programlisting>nat-anchor "ftp-proxy/*"
|
||||
rdr-anchor "ftp-proxy/*"</programlisting>
|
||||
|
||||
<para>The proxy will insert the rules it generates for the
|
||||
<acronym>FTP</acronym> sessions here. A pass rule is
|
||||
needed to let <acronym>FTP</acronym> traffic in to the
|
||||
proxy.</para>
|
||||
<para>The proxy will insert the rules it generates for the
|
||||
<acronym>FTP</acronym> sessions here. A pass rule is
|
||||
needed to let <acronym>FTP</acronym> traffic in to the
|
||||
proxy.</para>
|
||||
|
||||
<para>Now for the actual redirection. Redirection rules and
|
||||
<acronym>NAT</acronym> rules fall into the same rule
|
||||
class. These rules may be referenced directly by other
|
||||
rules, and filtering rules may depend on these rules.
|
||||
Logically, <literal>rdr</literal> and
|
||||
<literal>nat</literal> rules need to be defined before the
|
||||
filtering rules.</para>
|
||||
<para>Now for the actual redirection. Redirection rules and
|
||||
<acronym>NAT</acronym> rules fall into the same rule
|
||||
class. These rules may be referenced directly by other
|
||||
rules, and filtering rules may depend on these rules.
|
||||
Logically, <literal>rdr</literal> and
|
||||
<literal>nat</literal> rules need to be defined before the
|
||||
filtering rules.</para>
|
||||
|
||||
<para>We insert our <literal>rdr</literal> rule immediately
|
||||
after the <literal>nat</literal> rule in
|
||||
<filename>/etc/pf.conf</filename></para>
|
||||
<para>We insert our <literal>rdr</literal> rule immediately
|
||||
after the <literal>nat</literal> rule in
|
||||
<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
|
||||
pass. We achieve this with</para>
|
||||
<para>In addition, the redirected traffic must be allowed to
|
||||
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
|
||||
the proxy daemon is bound to.</para>
|
||||
<para>where <literal>$proxy</literal> expands to the address
|
||||
the proxy daemon is bound to.</para>
|
||||
|
||||
<para>Save <filename>pf.conf</filename>, then load the new
|
||||
rules with</para>
|
||||
<para>Save <filename>pf.conf</filename>, then load the new
|
||||
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
|
||||
that <acronym>FTP</acronym> works before they have been
|
||||
told.</para>
|
||||
<para>At this point, users will probably begin noticing
|
||||
that <acronym>FTP</acronym> works before they have been
|
||||
told.</para>
|
||||
|
||||
<para>This example covers a basic setup where the clients in
|
||||
the local net need to contact <acronym>FTP</acronym>
|
||||
servers elsewhere. The basic configuration here should
|
||||
work well with most combinations of <acronym>FTP</acronym>
|
||||
clients and servers. As shown in the man page, the
|
||||
proxy's behavior can be changed in various ways by adding
|
||||
options to the <literal>ftpproxy_flags=</literal> line.
|
||||
Some clients or servers may have specific quirks that must
|
||||
be compensated for in the configuration, or there may be a
|
||||
need to integrate the proxy in specific ways such as
|
||||
assigning <acronym>FTP</acronym> traffic to a specific
|
||||
queue. For these and other finer points of
|
||||
&man.ftp-proxy.8; configuration, start by studying the man
|
||||
page.</para>
|
||||
<para>This example covers a basic setup where the clients in
|
||||
the local net need to contact <acronym>FTP</acronym>
|
||||
servers elsewhere. The basic configuration here should
|
||||
work well with most combinations of <acronym>FTP</acronym>
|
||||
clients and servers. As shown in the man page, the
|
||||
proxy's behavior can be changed in various ways by adding
|
||||
options to the <literal>ftpproxy_flags=</literal> line.
|
||||
Some clients or servers may have specific quirks that must
|
||||
be compensated for in the configuration, or there may be a
|
||||
need to integrate the proxy in specific ways such as
|
||||
assigning <acronym>FTP</acronym> traffic to a specific
|
||||
queue. For these and other finer points of
|
||||
&man.ftp-proxy.8; configuration, start by studying the man
|
||||
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>
|
||||
<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>
|
||||
</sect3>
|
||||
|
||||
<sect3 xml:id="pftut-icmp">
|
||||
|
@ -1011,36 +1008,36 @@ rdr-anchor "ftp-proxy/*"</programlisting>
|
|||
these rulesets have been around for roughly fifteen years,
|
||||
and the people who put them there are still scared.</para>
|
||||
|
||||
<para>The obvious question then becomes, if
|
||||
<acronym>ICMP</acronym> is such a good and useful thing,
|
||||
should we not let it all through, all the time? The
|
||||
answer is <quote>It depends</quote>.</para>
|
||||
<para>The obvious question then becomes, if
|
||||
<acronym>ICMP</acronym> is such a good and useful thing,
|
||||
should we not let it all through, all the time? The
|
||||
answer is <quote>It depends</quote>.</para>
|
||||
|
||||
<para>Letting diagnostic traffic pass unconditionally of
|
||||
course makes debugging easier, but also makes it
|
||||
relatively easy for others to extract information about
|
||||
your network. That means that a rule like</para>
|
||||
<para>Letting diagnostic traffic pass unconditionally of
|
||||
course makes debugging easier, but also makes it
|
||||
relatively easy for others to extract information about
|
||||
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
|
||||
local network should be cloaked in a bit of mystery. In
|
||||
all fairness it should also be said that some
|
||||
<acronym>ICMP</acronym> traffic might be found quite
|
||||
harmlessly riding piggyback on
|
||||
<literal>keep state</literal> rules.</para>
|
||||
<para>might not be optimal if the internal workings of the
|
||||
local network should be cloaked in a bit of mystery. In
|
||||
all fairness it should also be said that some
|
||||
<acronym>ICMP</acronym> traffic might be found quite
|
||||
harmlessly riding piggyback on
|
||||
<literal>keep state</literal> rules.</para>
|
||||
|
||||
<para>The easiest solution could very well be to let all
|
||||
<acronym>ICMP</acronym> traffic from the local net through
|
||||
and stop probes from elsewhere at the gateway:</para>
|
||||
<para>The easiest solution could very well be to let all
|
||||
<acronym>ICMP</acronym> traffic from the local net through
|
||||
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>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<sect4 xml:id="pftut-letpingthru">
|
||||
<title>Letting <command>ping</command> Through</title>
|
||||
|
|
Loading…
Reference in a new issue