Problems with FTP

While FTP has been around since before the Internet ran on TCP/IP, every client and server seems to act a little differently. Stateful firewalls like FireWall-1, which expect things to happen only in certain ways, get tripped up by clients and servers that are RFC compliant, but choose to implement the RFCs differently. The following FAQs are related to FTP problems.

6.29 Problems with Newline Characters

Some FTP implementations send a PORT command in one packet and the newline character in another. By default, FireWall-1 assumes the PORT command and the newline will appear in the same packet. To enable checking for this, uncomment out the bolded #define statement (i.e., remove the // characters at the beginning of the line) in $FWDIR/lib/base.def on the management console and reinstall the security policy.

//    Use this if you do not want the FW-1 module to insist on a
// newline at the end of the PORT command:
// #define FTPPORT(match)       (call KFUNC_FTPPORT <(match)>)

Some other sites do not send out a proper newline at all. To resolve this, comment out the following line in $FWDIR/lib/base.def on the management console (i.e., add // at the beginning of the line) and reinstall the policy.

#define FTP_ENFORCE_NL

6.30 FTP on Ports Other Than 21

Some FTP servers use an alternate port for their control connection. By default, FireWall-1 knows how to handle FTP control connections only on port 21. To allow FTP using an alternate port, create a new service of type TCP. In the advanced configuration for the service, set the protocol type to FTP. Use this new service in a rule.

6.31 FTP Data Connections with a Random Source Port

Unfortunately, FireWall-1 NG does not currently allow for modification of INSPECT code to allow random FTP data port return traffic. The only existing workaround is the use of PASV transfers. Some FTP clients do not support passive mode, which means you may need to use a client that does.

6.32 FTP Servers Sending FIN Packets out of Sequence

It has been reported that Solaris clients cannot FTP to an NT SP6a platform. Microsoft's TCP/IP stack sends the FIN packets out of sequence. Installing the latest version of patch 105529 on Solaris resolves this issue.

6.33 FTP Servers That Require ident

Some FTP servers require a connection back to the FTP client on port 113 (ident). You will have to create an explicit rule permitting ident back to the client, which means that if you're using hide translation, you will simply not be able to access this FTP server.

6.34 Encrypting FTP Connections with SSL

Firewalls do not normally pass FTP connections encrypted with SSL?commonly referred to as FTP over SSL. The reason for this is simple: A firewall cannot inspect the FTP control connection because it is encrypted. FireWall-1 therefore cannot predict the FTP ports used by the FTP over SSL session.

Some people have been able to get this to work by simply applying FAQ 6.29, assuming the ports used are the standard TCP port 21 for control and 20 for data. Some variants of FTP over SSL operate over different ports?using port 990 for control and port 989 for data. In this case, you simply need to create the following TCP services:

• ftp-ssl-control: port 990

• ftp-ssl-data: port number higher than1024, source port 989

In other words, ftp-ssl-data accepts connections with a destination port of any TCP high port provided the source port is 989. The rulebase to permit access would look similar to Figure 6.1.

NOTE!

In no case will FTP over SSL be supported with hide NAT. This is because FireWall-1 is unable to see the control portion of the connection?it is, after all, encrypted. Thus the ports used by the control connection cannot be modified. FTP over SSL will work with static NAT.