Potential Firewall concerns with NetWare FTP Server

Note that firewalls could exist either/both on the FTP client and FTP server side of the Internet, so the following discussions can apply to both sides.

 

 

People are usually aware of the FTP control connection.  By default, FTP listens for this type of connection on port 21.  Any firewall between the client and server must be allowing connections to come _from_ any port on the FTP client side _to_ port 21 on the FTP server.  All commands (including user name and password) are sent over this control connection.  Typically, the responses to these commands come back on this connection as well.  The exceptions are:  Directory listings and file transfers occur on a separate data connection, even though the commands which initiate them go over the control connection.

 

 

When an FTP client wants to send or retrieve a file, or obtain a directory listing, an additional connection is established to accomplish this.  There are two possible approaches to forming this data connection.  The client gives a command which lets the server know which type of data connection it wants.  Some FTP clients can only do one type of data connection.  Others can do either.  Check your FTP client configuration options if you wish to configure which type the client asks for.

 

Active Data Connections

 

If the client wants to "listen" on a port and have the server initiate the new connection back to the client, that is known as a "active" data connection, because the server is the "active" party in creating the connection, meaning it sends the first TCP SYN packet.  Seeing a "PORT" command passed from the FTP client to the FTP server is the sign that the client wants this type of connection.  The PORT command will tell the server what IP address and port number the client is listening on.  Then the server will initiate a connection from it's own <control port number minus one>, typically 20, to the client's listening port.

 

For firewalls to allow active connections, they must allow connections to come _from_ port 20 on the FTP server, and go _to_ any port on the FTP client.

 

Passive Data Connections

 

If the client wants the server to listen on a port, so the client can initiate a new connection to the server, then this is known as a "passive" data connection, because the server is the passive participant in the new connection.  The "PASV" command is what a client will give when it wants this type.  The server will give a PASV reply announcing it's own listening IP address / port combination.

 

Some firewalls will allow passive connections without much special configuration.  Some will see the "PASV" negotiation going on, and will dynamically open up the port and allow the connection through.  If the firewall does not have this option, then a range of passive ports will need to be decided upon.  Then two things must be configured:  (1) the firewall must create an opening for connections to be initiated _from_ any port on the client side_to_ the selected range of ports on the FTP server.  (2)  The FTP server must be configured to only use that range of ports for passive connection.  In NetWare FTP server, this is done it sys:\etc\ftpserv.cfg, with the PASSIVE_PORT_MIN and PASSIVE_PORT_MAX settings.

 

Other concerns:

 

A.  If the firewall is a NAT (Network Address Translation) device, then typically is will treat FTP sessions a little differently than strict NAT rules would imply.  Normally, NAT only looks in the TCP header of a packet and translates the IP Address there from private to public or vice versa.  However, most NAT devices will watch FTP communication and when they find a private address inside a PORT or PASV negotiation, they will translate that to the proper public address as well.  This typically works by default, without any concern or special configuration.

 

However, this can become a large concern if the FTP session is being put inside an encrypted SSL tunnel.  This is also known as FTPS, or FTP-SSL.  If the FTP portion of a packet is encrypted, then the NAT device cannot see PORT or PASV activity going on, and cannot automatically translate those addresses. 

 

The solution to this type of dilemma is that the FTP server or FTP client (or both) may have to be configured to know their public side address, so they can put it in the PORT or PASV command, instead of their private address.  This is a feature above and beyond anything defined in the FTP RFC.  Some clients and servers may be able to do this; some may not.  The NetWare FTP Server can do this with the FORCE_PASSIVE_ADDR setting in the sys:etc\ftpserv.cfg file.  Proper usage of that feature takes some planning.  See TID 3931251 for a detailed explanation.

 

B.  Another concern exists when FTP-SSL is in use, even if NAT is not used.  Imagine that the firewall is using the feature of watching for PASV negotiations and dynamically opening the necessary port.  If the FTP communication is encrypted in SSL, the firewall can no longer see this activity and won't know to open up additional ports.  This will make it necessary to chose a and configure a range of ports for use, as discussed in the "Passive Data Connections" section above.