svn commit: r43930 - head/en_US.ISO8859-1/books/handbook/firewalls
Dru Lavigne
dru at FreeBSD.org
Fri Feb 14 21:22:51 UTC 2014
Author: dru
Date: Fri Feb 14 21:22:51 2014
New Revision: 43930
URL: http://svnweb.freebsd.org/changeset/doc/43930
Log:
White space fix only. Translators can ignore.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 14 21:04:15 2014 (r43929)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 14 21:22:51 2014 (r43930)
@@ -545,85 +545,84 @@ options ALTQ_PRIQ # Priori
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>
-
- <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>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>
+
+ <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>Whenever an edit is made to a ruleset, the new rules
- must be loaded so they can be used:</para>
-
- <screen>&prompt.root; <userinput>pfctl -f /etc/pf.conf</userinput></screen>
+ <para>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>
+
+ <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>
+
+ <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>If there are no syntax
- errors, <command>pfctl</command> will not output any
- messages during the rule load. Rules can also be tested before attempting to load them:</para>
-
- <screen>&prompt.root; <userinput>pfctl -nf /etc/pf.conf</userinput></screen>
-
- <para>Including <option>-n</option> causes the rules to be interpreted
- only, but not loaded. This provides an opportunity
- to correct any errors. At all times, the last
- 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
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>
-
- <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>
-
- <programlisting>pass out on xl0 from xl1:network to xl0:network port $ports keep state</programlisting>
-
- <para>These rules will work, but they will not necessarily
- achieve the desired effect.</para>
-
- <para>Rules this specific are rarely needed. A
- better rule says:</para>
-
- <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>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>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>If required, <literal>$localnet</literal> could even
- be defined as a list of networks. Whatever the specific
- needs, a sensible <literal>$localnet</literal> definition
- and a typical pass rule of the type</para>
-
- <programlisting>pass from $localnet to any port $ports keep state</programlisting>
-
- <para>could end up saving you a few headaches. We will
- stick to that convention from here on.</para>
-
- <para>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>
-
- <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>
-
- <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>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>
+
+ <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>
+
+ <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>
+
+ <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>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>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>If required, <literal>$localnet</literal> could even be
+ defined as a list of networks. Whatever the specific needs,
+ a sensible <literal>$localnet</literal> definition and a
+ typical pass rule of the type</para>
+
+ <programlisting>pass from $localnet to any port $ports keep state</programlisting>
+
+ <para>could end up saving you a few headaches. We will stick
+ to that convention from here on.</para>
+
+ <para>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>
+
+ <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>
+
+ <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>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>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>
- <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 -&g
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>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>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>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>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>
- <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>
-
- <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>
-
- <programlisting>udp_services = "{ domain, ntp }"</programlisting>
-
- <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>
-
- <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>In addition, we have a few other pass rules. One pass
+ rule which is useful for administering machines remotely
+ is:</para>
+
+ <programlisting>pass in inet proto tcp to $ext_if port ssh</programlisting>
+
+ <para>Lastly we need to make the name service work for our
+ clients:</para>
+
+ <programlisting>udp_services = "{ domain, ntp }"</programlisting>
+
+ <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>
+
+ <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>
</sect3>
<sect3 xml:id="pftut-ftp">
@@ -870,94 +867,94 @@ pass from { lo0, $localnet } to any keep
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>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>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>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>For a basic configuration, only three elements need to
- be added to <filename>/etc/pf.conf</filename>. First, the
- anchors:</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>
- <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>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>
-
- <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>
-
- <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>Save <filename>pf.conf</filename>, then load the new
- rules with</para>
-
- <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>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>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>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>
+
+ <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>
+
+ <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>
+
+ <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>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>
</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>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>
-
- <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 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>
+
+ <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>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>
More information about the svn-doc-all
mailing list