This topic describes functions in FTP that enable you to use FTP sessions that are secured by SSL/TLS using both network address translation (NAT) and filtering firewalls.
FTP requires the following TCP connections to transfer a file:
- Control connection
- Data connection
The control connection is established from the FTP client to the FTP server (default port 21). The data connection is established either from the FTP client to the FTP server, or from the FTP server to the FTP client; the direction is based on whether the client selects active mode or passive mode FTP.
- Active mode
With active mode FTP, the data connection is established from the FTP server to the FTP client, which is the opposite direction of the control connection. The active mode data connection is established from a well-known port on the server host (default port 20) to an ephemeral port on the client host.
- Passive mode
With passive mode FTP, the data connection is established from the FTP client to the FTP server, which is the same direction as the control connection. The data connection is established from an ephemeral port on the server host to an ephemeral port on the client host.
Passive mode is also referred to as firewall-friendly FTP. An intranet FTP client connecting to an Internet FTP server can establish connections outbound through the company firewall, but not inbound through the firewall. With passive mode, both the control and data connections are established outbound through the firewall to the Internet.
The FTP client user decides which mode to use. Active mode is the default, but the user can usually change to passive mode. The z/OS® FTP client user can switch between active and passive modes by issuing the LOCSITE subcommand with the NOFWFRIENDLY and FWFRIENDLY parameters.
Both active mode and passive mode FTP require the exchange of IP address and port information over the control connection. For active mode, the FTP client sends a PORT command specifying the IP address and port number to which the server must connect to establish the data connection. For passive mode, the FTP client sends a PASV command to the server, and the server replies with the IP address and port number to which the client should connect to establish the data connection.
Firewalls are often aware of FTP; they monitor the exchanges over the FTP control connection to learn the IP address and port number to which the data connection is to be established. NAT firewalls change the IP addresses on the PORT command or in the PASV reply. Filtering firewalls install dynamic filters based on the IP addresses and port information to enable the data connection to be established.
When you use SSL/TLS for FTP, the control connection is typically encrypted, so firewalls between the FTP client and server cannot see the data that is exchanged on the PORT command and the PASV reply. The firewalls cannot perform NAT successfully and they cannot install dynamic filters for the data connection, so the result is that your data connection very likely fails.
z/OS FTP includes the following support for functions that are specifically aimed at enabling FTP sessions through such firewalls:
- Extended passive mode (EPSV)
Extended passive mode works very much like passive mode. Instead of sending a PASV command to the server, the client sends an EPSV command to the server. The server EPSV reply includes only a port number. The client always uses the same IP address for the data connection that it used for the control connection. A z/OS FTP client user switches to extended passive mode for IPv4 connections by issuing the LOCSITE subcommand with the EPSV4 and FWFRIENDLY parameters. These options can also be configured in the z/OS FTP client FTP.DATA file.
EPSV allows sessions secured by SSL/TLS through NAT firewalls, but EPSV alone does not allow FTP sessions that are secured by SSL/TLS through firewalls that also implement dynamic filters.
- The PASSIVEIGNOREADDR configuration option
This z/OS FTP client option directs the z/OS FTP client to ignore the IP address in the PASV reply and use only the port number when FTP is in passive mode. The client uses the same IP address that it used to log in to the FTP server for the data connection. A z/OS FTP client user enables this support by issuing a LOCSITE subcommand with the PASSIVEIGNOREADDR option. You can also configure this option in the z/OS FTP client FTP.DATA file.
The PASSIVEIGNOREADDR configuration enables sessions secured by SSL/TLS through NAT firewalls in the same way that extended passive mode enables them, subject to the same limitations. You can use the PASSIVEIGNOREADDR option when the server does not support the EPSV command.
- The PASSIVEDATAPORTS statement in FTP.DATA
This z/OS FTP server option enables you to define a range of port numbers that the z/OS FTP server can use in PASV and EPSV replies for passive mode data connections. If the PASSIVEDATAPORTS statement on the z/OS FTP server is used in combination with EPSV from the FTP client, the two techniques together allow FTP sessions secured with SSL/TLS through NAT firewalls that also implement static IP filters, assuming that the firewall administrators add static filter rules that allow FTP data connections access to one or more of the ports in the PASSIVEDATAPORTS range.
- The clear command channel (CCC) command
The CCC command can be used on a control connection secured by SSL/TLS to disable SSL/TLS security. The control connection starts out as secured by SSL/TLS, and stays that way until a user ID and password or password phrase have been exchanged with the server. At that point, the FTP client can send a CCC command to the server, which disables SSL/TLS for the control connection and enables PORT commands and replies to PASV and EPSV commands to flow in the clear on the control connection. When these exchanges occur in the clear, firewalls between the FTP client and FTP server can perform NAT processing and dynamic filter processing as if the connection is not secured with SSL/TLS. The CCC command does not turn off security for the data connection.
To enable the z/OS FTP server to accept the CCC command, configure TLSRFCLEVEL RFC4217 or TLSRFCLEVEL CCCNONOTIFY at the FTP server.
To enable the z/OS FTP client to support the CCC command, configure TLSRFCLEVEL RFC4217 or TLSRFCLEVEL CCCNONOTIFY at the FTP client, matching the client TLSRFCLEVEL value to the server TLSRFCLEVEL value. You can use the LOCSITE subcommand to change the TLSRFCLEVEL value. When TLSRFCLEVEL RFC4217 or TLSRFCLEVEL CCCNONOTIFY is configured at the z/OS FTP client, use the CCC subcommand after logging in to the FTP server to send a CCC command to the FTP server.
The support that you use depends on your network topology. The following scenarios are a few selected scenarios to consider for making sure that FTP sessions secured by SSL/TLS can get through your network. The scenarios assume that z/OS is at least one of the endpoints of the secure FTP session. The partner endpoint can be z/OS or any secure FTP product on the market that supports the same RFC levels as z/OS (primarily RFC 4217).
- Your firewall performs NAT only (minimal or no filtering), your
FTP client is in a private network behind the NAT firewall, and the
FTP server is in a public network such as the Internet, as shown in Figure 1. Figure 1. SSL/TLS-secured FTP session scenario 1
Normal passive mode (PASV) usually works in such a scenario. Extended passive mode (EPSV) also works, but is generally not required.
- Your firewalls perform NAT only (minimal or no filtering), your
FTP client is in one private network, your FTP server is in another
private network, and you have two NAT firewalls between the client
and server networks that are connected over a public network, as shown
in Figure 2. Figure 2. SSL/TLS-secured FTP session scenario 2
If your partner's secure FTP product supports extended passive mode, use extended passive mode (EPSV) from the FTP client. If the FTP client is the z/OS FTP client and the partner's secure FTP server product does not support EPSV, configure the PASSIVEIGNOREADDR option at your z/OS FTP client to simulate EPSV processing.
- Your firewall performs NAT and static filtering (predefined filter
rules). Your FTP client is in a private network behind the NAT firewall,
with a z/OS FTP server that
is in a public network such as the Internet, as shown in Figure 3. Figure 3. SSL/TLS-secured FTP session scenario 3
Use the PASSIVEDATAPORTS statement in the z/OS FTP server's FTP.DATA file to predefine a range of port numbers that the z/OS FTP server can use for data connections. Your firewall administrator needs to add static filter rules for the passive data port range. Normal passive mode (PASV) usually works in such a scenario, but extended passive mode (EPSV) can also be used if supported by the FTP client.
- Your firewalls perform NAT and static filtering (predefined filter
rules). Your FTP client is in one private network, your z/OS FTP server is in another private network,
and you have two NAT firewalls between the client and server networks
that are connected over a public network, as shown in Figure 4. Figure 4. SSL/TLS-secured FTP session scenario 4
Use the PASSIVEDATAPORTS statement in the z/OS FTP server's FTP.DATA file to predefine a range of port numbers that the z/OS FTP server can use for data connections. Your firewall administrator needs to add static filter rules for the passive data port range. In this case, you must use extended passive mode. If the FTP client does not support extended passive mode, this scenario is not likely to work.
- Your firewalls perform dynamic filtering (with or without NAT)
and your partner's secure FTP product supports the CCC command, as
shown in Figure 5. Figure 5. SSL/TLS-secured FTP session scenario 5
Use the CCC command from the FTP client. This scenario is not likely to work without CCC command support.
- You do not know what your firewalls do and your partner's secure
FTP product does support the CCC command, as shown in Figure 6. Figure 6. SSL/TLS-secured FTP session scenario 6
Use the CCC command from the FTP client. This scenario is not likely to work without CCC command support.
Firewalls reject FTP sessions secured by SSL/TLS in the following additional scenarios:
- Some firewalls are known to apply various validity checks on the FTP control connection data stream. One known check verifies that all interactions on the FTP control connection are terminated with an ASCII newline (NL) character. Most of these checks fail when the control connection is secured with SSL/TLS, because the data is encrypted. If you use the information in this topic and still run into problems establishing FTP sessions secured by SSL/TLS through firewalls, verify with your firewall administrators whether your firewalls implement such validity checks on the FTP control connection, and consider disabling those validity checks.
- Some firewalls are known to disable active mode data connections by default, and block all active mode data connections. Use passive mode or extended passive mode FTP instead.
- Many firewalls monitor activity on TCP connections and terminate connections that are idle for a certain period of time. During a large data transfer over an FTP data connection, the FTP control connection is idle. To avoid having firewalls terminate idle FTP connections, consider coding the FTPKEEPALIVE statement in the z/OS FTP.DATA file for the client or the server. For more information about the FTPKEEPALIVE statement, see Configuring PROFILE.TCPIP for FTP.