Date: Fri, 14 Feb 2014 21:22:51 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43930 - head/en_US.ISO8859-1/books/handbook/firewalls Message-ID: <201402142122.s1ELMpNH042236@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402142122.s1ELMpNH042236>