os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Clarify the section on FTP proxy.

Browse source 
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne 2014-02-18 18:08:55 +00:00
parent f7900dd366
commit 7cd62ad42f
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=43980
1 changed files with 46 additions and 81 deletions

127
en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
View file

@ -777,140 +777,105 @@ pass quick inet proto { tcp, udp } to any port $udp_services keep state</program
<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>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>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>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 -&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>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>