White space fix only. Translators can ignore.

Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne 2014-02-14 21:22:51 +00:00
parent d01a8ba4c4
commit e1f3a68162
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43930

View file

@ -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 -&gt; ($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 -&gt; 127.0.0.1 port 8021</programlisting>
<programlisting>rdr pass on $int_if proto tcp from any to any port ftp -&gt; 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>