From owner-svn-doc-all@FreeBSD.ORG Tue Feb 18 18:08:55 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B74ADEED; Tue, 18 Feb 2014 18:08:55 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9751B12A2; Tue, 18 Feb 2014 18:08:55 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1II8tnE074895; Tue, 18 Feb 2014 18:08:55 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1II8tvq074894; Tue, 18 Feb 2014 18:08:55 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402181808.s1II8tvq074894@svn.freebsd.org> From: Dru Lavigne Date: Tue, 18 Feb 2014 18:08:55 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43980 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:08:55 -0000 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 Creating an <acronym>FTP</acronym> Proxy - The short list of real life TCP ports - above contained, among other things, FTP. - FTP is a sad old thing and a problem - child, emphatically so for anyone trying to combine - FTP and firewalls. - FTP is an old and weird protocol, with a - lot to not like. The most common points against it - are + Configuring working FTP rules can be + problematic due to the nature of the FTP + protocol. FTP pre-dates firewalls by + several decades and is insecure in its design. The most + common points against using FTP include: - Passwords are transferred in the clear + Passwords are transferred in the clear. The protocol demands the use of at least two TCP connections (control and data) on - separate ports + separate ports. When a session is established, data is communicated - via ports selected at random + using randomly selected ports. - 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. - - 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 - IT professionals should have a preference - for some other form of file transfer than - FTP. - - 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 - FTP through firewalls, the main part of - our handling consists of redirecting the traffic to a small - program which is written specifically for this - purpose. - - Enabling FTP transfers through your - gateway is amazingly simple, thanks to the - FTP proxy program (called - &man.ftp-proxy.8;) included in the base system on &os; and - other systems which offer - PF. - - The FTP 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 + 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.. + + For those situations when FTP is + required, PF provides + redirection of FTP 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 FTP traffic. - To enable &man.ftp-proxy.8;, add this line to + To enable the FTP proxy, add this line to /etc/rc.conf: ftpproxy_enable="YES" - Starting the proxy manually by running - /usr/sbin/ftp-proxy allows testing of - the PF configuration changes we - are about to make. + Then start the proxy by running + service ftp-proxy start. - For a basic configuration, only three elements need to + For a basic configuration, three elements need to be added to /etc/pf.conf. First, the - anchors: + anchors which the proxy will use to insert the rules it generates for the + FTP sessions: nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*" - The proxy will insert the rules it generates for the - FTP sessions here. A pass rule is - needed to let FTP traffic in to the + Second, a pass rule is + needed to allow FTP traffic in to the proxy. - Now for the actual redirection. Redirection rules and - NAT 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, rdr and - nat rules need to be defined before the - filtering rules. - - We insert our rdr rule immediately - after the nat rule in - /etc/pf.conf + Third, redirection and NAT rules need + to be defined before the + filtering rules. Insert this rdr rule immediately + after the nat rule: rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 - In addition, the redirected traffic must be allowed to - pass. We achieve this with + Finally, allow the redirected traffic to + pass: pass out proto tcp from $proxy to any port ftp where $proxy expands to the address the proxy daemon is bound to. - Save pf.conf, then load the new - rules with + Save /etc/pf.conf, load the new + rules, and verify from a client that FTP + connections are working: &prompt.root; pfctl -f /etc/pf.conf - At this point, users will probably begin noticing - that FTP works before they have been - told. - This example covers a basic setup where the clients in - the local net need to contact FTP - servers elsewhere. The basic configuration here should + the local network need to contact FTP + servers elsewhere. This basic configuration should work well with most combinations of FTP - 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 ftpproxy_flags= 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 FTP traffic to a specific - queue. For these and other finer points of - &man.ftp-proxy.8; configuration, start by studying the man - page. + queue. For ways to run an FTP server protected by PF and - &man.ftp-proxy.8;, look into running a separate - ftp-proxy in reverse mode (using - ), on a separate port with its own + &man.ftp-proxy.8;, configure a separate + ftp-proxy in reverse mode, using + , on a separate port with its own redirecting pass rule.