svn commit: r43980 - head/en_US.ISO8859-1/books/handbook/firewalls
Dru Lavigne
dru at FreeBSD.org
Tue Feb 18 18:08:55 UTC 2014
Author: dru
Date: Tue Feb 18 18:08:55 2014
New Revision: 43980
URL: http://svnweb.freebsd.org/changeset/doc/43980
Log:
Clarify the section on FTP proxy.
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 Tue Feb 18 18:07:00 2014 (r43979)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 18:08:55 2014 (r43980)
@@ -777,140 +777,105 @@ pass quick inet proto { tcp, udp } to an
<sect3 xml:id="pftut-ftp">
<title>Creating an <acronym>FTP</acronym> Proxy</title>
- <para>The short list of real life <acronym>TCP</acronym> ports
- above contained, among other things, <acronym>FTP</acronym>.
- <acronym>FTP</acronym> is a sad old thing and a problem
- child, emphatically so for anyone trying to combine
- <acronym>FTP</acronym> and firewalls.
- <acronym>FTP</acronym> is an old and weird protocol, with a
- lot to not like. The most common points against it
- are</para>
+ <para>Configuring working <acronym>FTP</acronym> rules can be
+ problematic due to the nature of the <acronym>FTP</acronym>
+ protocol. <acronym>FTP</acronym> pre-dates firewalls by
+ several decades and is insecure in its design. The most
+ common points against using <acronym>FTP</acronym> include:</para>
<itemizedlist>
<listitem>
- <para>Passwords are transferred in the clear</para>
+ <para>Passwords are transferred in the clear.</para>
</listitem>
<listitem>
<para>The protocol demands the use of at least two
<acronym>TCP</acronym> connections (control and data) on
- separate ports</para>
+ separate ports.</para>
</listitem>
<listitem>
<para>When a session is established, data is communicated
- via ports selected at random</para>
+ using randomly selected ports.</para>
</listitem>
</itemizedlist>
- <para>All of these points make for challenges security-wise,
- even before considering any potential weaknesses in client
- or server software which may lead to security issues. These
- things have tended to happen.</para>
-
- <para>Under any circumstances, other more modern and more
- secure options for file transfer exist, such as &man.sftp.1;
- or &man.scp.1;, which feature both authentication and data
- transfer via encrypted connections. Competent
- <acronym>IT</acronym> professionals should have a preference
- for some other form of file transfer than
- <acronym>FTP</acronym>.</para>
-
- <para>Regardless of our professionalism and preferences, we
- are all too aware that at times we will need to handle
- things we would prefer not to. In the case of
- <acronym>FTP</acronym> through firewalls, the main part of
- our handling consists of redirecting the traffic to a small
- 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
+ <para>All of these points present security challenges,
+ even before considering any potential security weaknesses in client
+ or server software. More
+ secure alternatives for file transfer exist, such as &man.sftp.1;
+ or &man.scp.1;, which both feature authentication and data
+ transfer over encrypted connections..</para>
+
+ <para>For those situations when <acronym>FTP</acronym> is
+ required, <application>PF</application> provides
+ redirection of <acronym>FTP</acronym> traffic to a small
+ proxy program called
+ &man.ftp-proxy.8;, which is included in the base system of &os;.
+ The role of
+ the proxy is to dynamically insert and delete rules in the ruleset, using
+ a set of anchors, in order to correctly handle
<acronym>FTP</acronym> traffic.</para>
- <para>To enable &man.ftp-proxy.8;, add this line to
+ <para>To enable the <acronym>FTP</acronym> proxy, add this line to
<filename>/etc/rc.conf</filename>:</para>
<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>Then start the proxy by running
+ <command>service ftp-proxy start</command>.</para>
- <para>For a basic configuration, only three elements need to
+ <para>For a basic configuration, three elements need to
be added to <filename>/etc/pf.conf</filename>. First, the
- anchors:</para>
+ anchors which the proxy will use to insert the rules it generates for the
+ <acronym>FTP</acronym> sessions:</para>
<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
+ <para>Second, a pass rule is
+ needed to allow <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>
+ <para>Third, redirection and <acronym>NAT</acronym> rules need
+ to be defined before the
+ filtering rules. Insert this <literal>rdr</literal> rule immediately
+ after the <literal>nat</literal> rule:</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>
+ <para>Finally, allow the redirected traffic to
+ pass:</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>
+ <para>Save <filename>/etc/pf.conf</filename>, load the new
+ rules, and verify from a client that <acronym>FTP</acronym>
+ connections are working:</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
+ the local network need to contact <acronym>FTP</acronym>
+ servers elsewhere. This basic configuration should
work well with most combinations of <acronym>FTP</acronym>
- clients and servers. As shown in the man page, the
+ clients and servers. As shown in &man.ftp-proxy.8;, 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>
+ queue.</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
+ &man.ftp-proxy.8;, configure 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>
More information about the svn-doc-all
mailing list