Paul Ford-Hutchinson IBM UK Ltd INTERNET-DRAFT (draft) 19th June, 2002 This document expires on 19th December, 2002 FTP/TLS Friendly Firewalls Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Ford-Hutchinson FORMFEED[Page 1] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 Index 1. .......... Abstract 2. .......... Introduction 3. .......... Audience 4. .......... Problem Statement 5. .......... Technical Description 5.1. ........... Establishing a Data Connection 5.2. ........... Data connection behaviour for FTP 5.3. ........... Port numbers 6. .......... Firewalls 6.1. ........... Port Filtering Firewalls 6.2. ........... Content Aware Firewalls 6.3. ........... Network Address Translators 6.4. ........... Application Layer Gateways 7. .......... Trying to secure FTP with TLS over firewalls 7.1. ........... Port Filtering Firewalls 7.2. ........... Content Aware Firewalls 7.3. ........... Network Address Translators 7.4. ........... Application Layer Gateways 8. .......... Premature Control Termination 9. .......... midcom 10. ......... Security Considerations 11. ......... IANA Considerations 12. ......... Network Management 13. ......... Internationalization 14. ......... Scalability & Limits 15. ......... Acknowledgements 16. ......... References 17. ......... Authors' Contact Address Appendix A. .......... Firewall rule summary Ford-Hutchinson FORMFEED[Page 2] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 1. Abstract This document discusses some of the issues with running FTP, secured with TLS as defined in [FTP-TLS], through firewalls. FTP is known to be a bit of a problem for firewalls (see [RFC-1579] for a discussion of normal FTP and firewalls). Some of the problems have been fixed by adding intelligence into the firewall. With secured FTP, where the control connection is encrypted, some of these techniques fail. Whilst this document confines itself to issues of FTP over TLS, the issues will probably be relevant for most secured FTP protocols that conform to [RFC-2228]. Some of the discussions will also be relevant to any protocol that firewalls do clever things with. 2. Introduction This document is presented as a discussion of secure FTP behaviour as viewed by a firewall. It discusses some of the techniques that firewalls use to provide a path for the FTP protocol and how those are affected by layering FTP on TLS. 3. Audience This document is aimed at designers of firewall software and people involved in deploying firewalls in an environment where FTP over TLS needs to traverse them. 4. Problem Statement The FTP protocol has two troublesome features that cause headaches when trying to pass over boundary firewall devices. - There are two distinct connections used - The information used to establish the second connection is dynamically created and passed between the entities over the first connection. The two connections are the Control Connection and the Data Connection. In practice, there is usually one Control Connection per session and numerous Data Connections. The operation of FTP defines that the following data transfers take place on a Data Connection: - File sending, using the STOR command Ford-Hutchinson FORMFEED[Page 3] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 - File retrieval, using the RETR command - Listings, using the NLST and LIST commands (and the MLST command) Implementations usually establish a data connection for each of the data transfers. The protocol documentation [RFC-959] does not specify this behaviour, but does allow for it. A note about Transmission Modes: FTP [RFC-959] defines three modes of data transfer, Stream, Block and Compressed. In practice Stream mode, the only one required by [RFC-1123] and the default mode, is the most widely used. [RFC-1123] states that clients that use Stream mode SHOULD use a PORT command. Stream mode data transfers are ended by closing the data connection, effectively forcing one data connection per data transfer. 5. Technical Description For the discussions below, assume that a Client has connected from port 'U' to the FTP port 'L' on the Server. (The well known port for FTP is '21', thus, normally, 'L' is '21'). Also assume that the transmission mode is 'Stream'. 5.1. Establishing a Data Connection A Data Connection needs to be established for the data transfer commands (STOR, RETR, NLST, LIST and MLST) to operate. When the server receives one of these commands, it replies with an intermediate reply ('150') indicating that it is ready to transfer the data. The Data Connection is established and the data transfer happens. 5.2. Data connection behaviour for FTP If no PORT or PASV command is issued, the Client should listen for a connection from the Server on the same port as the control connection ('U'). The Server should initiate the Data Connection from the default Data Port, which is 'L - 1' ('20'). If a PORT command is to be issued then the Client should obtain a port number and pass that to the Server in the PORT command (as a comma separated list "h1,h2,h3,h4,p1,p2" where h1 is the high order 8 bits of the internet host address.) The Server should then establish a connection to the Client on the Address and Port indicated, from the Server's Default Data Port ('L - 1'). Note: This does not need to be on the host at the other end of the Control Connection. Ford-Hutchinson FORMFEED[Page 4] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 If the Client wishes to use Firewall Friendly FTP [RFC-1579] then the Client issues a PASV command, which causes the Server to listen on a port (not the default data port). The Server indicates which port it is listening on, in the 227 response to the PASV command (see [RFC-1123]). This time the Data Connection is initiated from a port on the Client to the port indicated by the Server. Note: This does not need to be on the host at the other end of the Control Connection. 5.3. Port numbers The TCP and UDP addressing mechanism has two parts. A Host Address and a Port number. In IPv4 a host address is a long integer (32 bits) and a port number is a short integer (16 bits). Each host may use those port numbers to originate or listen to connections. At a 'C' coding level, there are three basic ways to get a port for a connection. - get a socket and then connect to a remote host - get a socket, bind to port 0 and then query the socket information to find out which port number you were given. - get a socket and bind to a specific port number. The first mechanism is only really useful for obtaining a port to originate a connection; the second two mechanisms are suitable for obtaining a port for originating or for listening for a connection. There are three ranges of port numbers: - Well known ports. These are the port numbers less than 1024. On Unix systems, it is usually a restriction that these ports are only accessible to a process running with 'root' privilege. It was therefore assumed that services running in this port range would be system services, running with the consent of the system administrator, and therefore trustable. With the advent of home linux systems and Windows systems that do not have a 'root' user - this basis of 'trust' is not reliable. Widely used Internet protocols will usually be on ports <1024, user processes will not normally (even on Windows machines) be allocated ports under 1024 unless specifically requested. - Registered ports. These are the port numbers in the range 1024-49151. These are for services that do not need to be run with root privilege, but do need to have a port number agreed by both the client and server. Ford-Hutchinson FORMFEED[Page 5] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 - Dynamic and/or Private Ports. These are the ports from 49152 through 65535. 6. Firewalls Simple port filters rely on the 'well known port' system that underpins much of the establishment of TCP (and UDP) based protocol conversations. Each service has a well known port and a client and server should expect to find each other on those ports. Examples of the common ports are: 80 for http; 443 for https; 25 for SMTP; 23 for telnet and 21 for FTP. Such firewalls boldly assume that machines on either side will be well behaved and only offer the correct service on the correct port. In this way, they are able to filter unwanted traffic between hosts by examining the source address/port and destination address/port and deciding if the hosts are allowed to use the service indicated. For the FTP protocol, two rules must be set up in the Firewall. The first rule allows the client to connect to the Server for the Control Connection. The second rule is for the Data Connection and will depend if Normal or Firewall Friendly FTP is to be used (or both). 6.1. Port Filtering Firewalls The problem that simply using port filtering for FTP generates is that the data connection rule tends to open up quite a large hole in the Firewall and many implementors do not wish to define it. The more general problem with simple port filtering is the issue of port number misuse. To fix both of these issues, a Content Aware firewall may be deployed. 6.2. Content Aware Firewalls In addition to port filtering rules, Content Aware firewalls will also look at the content of the conversation and may perform actions based on what they observe. This has two impacts for the FTP protocol. Firstly, it allows the firewall to observe the content of the Control Connection and make decisions based upon it. Secondly, it allows the firewall to open up temporary holes for the Data Connection, based upon the content of the PORT command and/or PASV response. Content Aware firewalls: Ford-Hutchinson FORMFEED[Page 6] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 - may only allow certain FTP commands to be used - may have restrictions in the parameters to certain commands (e.g. STOR, RETR, CWD, NLST and LIST preventing any directories with a certain name being accessed) - may insist that all commands conform to some expected criteria, such as being ended by CRLF delimiters. When a Content Aware firewall observes a PORT command or the 227 reply to the PASV command, it may dynamically create a rule to allow the indicated Data Connection to pass through. This removes the requirement for the quite wide definitions that would otherwise be needed to allow the data connection to be established. 6.3. Network Address Translators One step up from Content Aware firewalls are boundary devices which allow addresses to be hidden from the outside world. There are two major reasons for this. The first is to hide any network topology information; the second is to allow the use of private network addresses (see [RFC-1918]). For the FTP protocol, Network Address Translators need to read and modify PORT commands and/or PASV responses to substitute their own address and port for those indicated on the Control Connection. 6.4. Application Layer Gateways These types of boundary devices actually understand the FTP protocol and act as a application layer proxy between the two hosts. To the Client it acts as a server, to the Server it acts as a client. 7. Trying to secure FTP with TLS over firewalls If we look at our four category of devices, we can examine the effect of deploying [FTP-SSL] secured FTP over TLS. 7.1. Port Filtering Firewalls FTP over TLS will not affect the operation of the FTP protocol as viewed by a simple port filtering firewall. The connections and the ports are exactly the same 7.2. Content Aware Firewalls Content aware firewalls will no longer be able to understand the Ford-Hutchinson FORMFEED[Page 7] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 content of the Control connection. This means that - Any packet on the control connection that cannot be inspected, must be configured to be passed through. - Normal port filtering firewall rules must be in place for the Data Connection, as the firewall will not be able to open up the pinholes, based on examination of the Control Connection. 7.3. Network Address Translators NAT firewalls will not work for secure FTP if the NAT will affect the PORT address or the PASV response address. An FTP Client on a NATted network should be able to use secure FTP over TLS in firewall friendly mode to a Server that has a real Internet IP address. An FTP Client with a real Internet IP address should be able to use an FTP Server that is on a NATted network in normal mode (assuming there is some mechanism for the Client to establish a Control Connection). 7.4. Application Layer Gateways In general Client-Server secured FTP will not work at all with an ALG. However, It may be possible to configure an ALG as one of the endpoints of the secured FTP session as it flows over a hostile network. 8. Premature Control Termination Another issue with firewalls and FTP is connected to the problem of timeouts. Due to the two-connection model of FTP, there is a high likelihood that the Control connection will have no activity during a data transfer. In the case that the data transfer is long, the firewall may incorrectly assume that the Control connection is no longer needed and close it down. Thus, the data transfer will complete correctly, but the 226 reply on the control connection will no be received and the client and server will, eventually, time out independently. 9. midcom One approach to help solve the issue is the MiddleBox communications working group. Their aim is to create a model and set of protocols to define a communications protocol between endpoints and boundary devices, such as firewalls, that will allow the client or server to request a path through the firewall without the firewall itself needing to be able to understand the protocol that it is passing Ford-Hutchinson FORMFEED[Page 8] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 through. 10. Security Considerations This document attempts to explain how the FTP protocol operates from a firewall's perspective; how a firewall can be configured to allow FTP (and secure FTP) to traverse it and how some of the more advanced features of firewalls and application layer gateways can make life hard for secured protocols. 11. IANA Considerations {FTP-PORT} - The port assigned to the FTP control connection is 21. 12. Network Management NONE 13. Internationalization NONE 14. Scalability & Limits NONE 15. Acknowledgements Ford-Hutchinson FORMFEED[Page 9] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 16. References [RFC-959] J. Postel, "File Transfer Protocol" RFC 959, October 1985. [RFC-1579] S. Bellovin, "Firewall-Friendly FTP" RFC 1579, February 1994. [RFC-2228] M. Horowitz, S. Lunt, "FTP Security Extensions" RFC 2228, October 1997. [RFC-2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0" RFC 2246, January 1999. [RFC-2577] M Allman, S Ostermann, "FTP Security Considerations" RFC 2577, May 1999. [RFC-2817] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1" RFC 2817, May 2000. [RFC-2818] E. Rescorla, "HTTP Over TLS" RFC 2818, May 2000. [FTP-EXT] R Elz, P Hethmon "Extensions to FTP" draft-ietf-ftpext-mlst-12.txt, September 2000. [FTP-TLS] "Securing FTP with TLS" draft-murray-auth-ftp-ssl-08.txt, October 2001. Ford-Hutchinson FORMFEED[Page 10] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 17. Authors' Contact Address The FTP-TLS draft information site is at http://www.ford- hutchinson.com/~fh-1-pfh/ftps-ext.html Please send comments to Paul Ford-Hutchinson at the address below Paul Ford-Hutchinson IBM UK Ltd PO Box 31 Birmingham Road Warwick United Kingdom tel - +44 1926 462005 fax - +44 1926 496482 email - paulfordh@uk.ibm.com Ford-Hutchinson FORMFEED[Page 11] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 Appendix A. Firewall rule summary As long Application Layer Gateways (or proxys) are not used, a packet filtering firewall should be able to pass secured FTP. The following guidelines should help trying to configure one. Control Connection - Allow any port on the client to connect to port 21 on the server - Disable any rules that parse and/or impose any rules on the commands and/or responses on the control stream. (Note - there is one major firewall vendor who claim this is a security issue and make it very hard for you to do this) - Ensure the idle timeout of the control connection is longer than it will take to transfer the largest file on the data connection Data Connection Normal (active or PORT) FTP - Allow port 20 on the server to connect to any port on the client Firewall-Friendly (passive or PASV) FTP - Allow any port on the client to connect to any high port(*) on the server. (*) This may be able to be configured on the server to be a range of ports and not 'any high port'. Note: A firewall may allow both Normal and Firewall-Friendly FTP, the choice is not exclusive. NAT firewalls should be able to allow Firewall friendly FTP through, as long as these rules can be followed. Ford-Hutchinson FORMFEED[Page 12] Internet-Draft Secure FTP Friendly Firewalls 19th June, 2002 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This document expires on 19th December, 2002 Ford-Hutchinson FORMFEED[Page 13]