More on active ftp

Introduction to this web page

This web page provides some more ramblings on active ftp, and why it is destined to fail with a firewall that does network address translation.

There aren`t any updates to the firewall on this page.

Introduction to ftp

Ftp is a rather old and insecure protocol. It sits above tcp/ip

Ftp has two parts to it - a control session, and a data transfer session. The standards for ftp specify that both these sessions take place over the same connection - the computers at both ends of the connection must therefore switch synchronously between the control session and the data transfer session, and this switch has therefore has to be controlled by the control session.

The control dialogue is done by using a set of Telnet look-alike commands issued by the client, and a set of specific responses issued by the server.

Iana has specified that port 21 is used for the control session between the ftp client and the server - however nowadays, although the ftp server does use port 21 for the control session, the client workstation doesn`t.

Iana has also specified that port 20 is used for data transfer between the ftp client and the server - but it usually isn`t used by either the server or the client workstation.

Ftp has various modes of operation, but this web page concentrates on active ftp.

Active ftp

The thing that distinguishes active ftp from passive ftp is the use of the PORT command in active ftp.

The PORT command is issued by the client, and conveys three bits of information to the server -

It tells the server what ip address the client is using
It tells the server what port number the client is using
It tells the server that the server should initiate the data transfer session

Here is a typical sequence of the control session, then switching to the data transfer session. It was recorded using Windows XP as the client, and wu-ftp running on Red Hat Linux 7.2 as the ftp server, and the client and ftp server are on the same side of the firewall.

Note that :-

the client has the ip address of 192.168.100.53
the ftp server has the ip address of 192.168.100.150
the server has the host name of "Hawk"
the words in upper case are the specific commands from the client
the three digit numbers are the specific responses from the server

Here is the sequence as seen by the client :-

   Connecting to 192.168.100.150:21

   connected to 192.168.100.150 port 21

   220 Hawk FTP server ( version wu-2.6.1-18 ) ready

   USER user-1

   331 Password required for user-1

   PASS ( hidden )

   230 User user-1 logged in

   PWD

   257 "/home/user-1" is current directory

   SYST

   215 UNIX Type : L8

   Host type (S): UNIX (standard )

   PORT 192,168,100,53,12,52

   200 PORT command successful

   LIST

   150 Opening ASCII mode data connection for directory listing

   Received 382 bytes in 0.1 secs, ( 30.00 kbps ) transfer succeeded

   226 Transfer complete

In this session, you can see the client initiating the connection, the user logging in, and then the client requesting the address and the contents of the initial directory that the ftp server is looking at for that user.

Note the PORT command, with the attached ip address and the port of the client.

Now we move the ftp server to the outside of the firewall, which firewall is doing network address translation to the 10.0.0.0 network.

The ftp server now has the ip address of 10.0.0.75, and the client is the same as before.

   Connecting to 10.0.0.75:21

   connected to 10.0.0.75 port 21

   220 Hawk FTP server ( version wu-2.6.1-18 ) ready

   USER user-1

   331 Password required for user-1

   PASS ( hidden )

   230 User user-1 logged in

   PWD

   257 "/home/user-1" is current directory

   SYST

   215 UNIX Type : L8

   Host type (S): UNIX (standard )

   PORT 192,168,100,53,14,30

   502 Illegal PORT command

   ! Failed "port" :

   ! Retrieve of folder listing failed (0)

In this case, the ftp server has recognised that the PORT command is corrupt - ie, the ip address in the header is not the same as the ip address contained within the data section. The ftp server has issued the 502 response, which tells the client that the command has not been implemented.

Now here is the same situation with a different ftp server - in this case it is a Sun OS 5.8 server, again this is outside the firewall, on the 10.0.0.0 network :-

   connecting to 10.0.0.80.21

   connected to 10.0.0.80 port 21

   220 Buzzard FTP server ( Sun OS 5.8 ) ready

   USER user-1

   331 Password required for user-1

   PASS ( hidden )

   230 User user-1 logged in

   PWD

   257 "/Buzzard/users/homes/user-1" is current directory

   Host type (1): Unix ( standard )

   PORT 192,168,100,53,13,255

   200 PORT command successful

   LIST

At this point, the control session switches to the data transfer session, and as far as this session is concerned, this is where the whole process fails.

But it does appear that the ftp server on this Sun OS 5.8 server has accepted the PORT command, and has responded with the 200 response to say the PORT command was successful.

So different types of ftp server react differently to this corrupted PORT command, however this doesn`t really matter as there are another two reasons why active ftp is probably going to fail, where the firewall does network address translation.

Network topology

Most networks are nowadays constructed using utp and layer 3 switches. Layer 3 switching requires the switches to know where the various subnets are located. However as the firewall only sends out packets with the source ip address of eth0, the switches don`t get the opportunity to learn about the location of the secure subnet which is on eth1, so any packets that are posted on to the network with the destination ip address of the secure subnet will not get routed back to the firewall.

The firewall

The ruleset for the firewall has been set up to specifically exclude packets coming in from the public internet on eth0, which have ip addresses within the secure subnet network address.

So even if the ftp server sends one out, and the network topolgy does actually transmit it to the firewall, the firewall is going to drop any packets with an ip destination address on the secure subnet.

Return to the Firewall index page