Allowing FTP through Firewall by Inspecting traffic

Problem statement:-

FTP traffic needs to be allowed through the firewall. Basic details about FTP can be found here. This cannot be done by simply allowing the traffic for control connection ( by default port 21 ) and not taking care for the data-connection. For this, one needs to analyze the FTP control path (control connection) data to get the details about the data-path (data connection). Once the data-path details are known, one just needs to create embryonic flow entries for the data-connection.

Embryonic flow: A flow entry created for the traffic-flow before there is actual traffic flowing which matches the flow specifications.

flowID: This is a five-tuple field to differentiate the various connections.

Control path activities for a particular FTP request are as follows :-

For Active Mode

For Passive Mode 

  

Out of these 8 packets on control-path, ignoring ACK, we have ‘Five’ generic packets in our flow. We can list these requests/responses in terms of states.

These states are:-
1.    Opening
2.    Opened
3.    command_sent
4.    execution_started
5.    execution_complete

One needs to keep track of FTP control connection’s state and the data-connection details negotiated. This can be done by storing the details in a table called “flow table”.

Flow table column’s are as follows :-
1.    Command Type
2.    IP Address exchanged for data-connection( required for creating embryonic flow )
3.    Port number exchanged for data-connection( required for creating embryonic flow )
4.    Response_code of the command
5.    State of the FTP connection

When a new FTP connection is initiated (is in opening state), one entry is made in the flow table. It then goes through all the states; when it reaches to the state of execution_complete, that entry is removed.

STATE TRANSITIONS FOR PORT COMMANDS:-

Now lets consider the case for PORT command. Five request/response actions occur in this. These are:-

( Client[XYZ] to Server[FTP 21] ) – FTP Request: PORT          -> OPENING
( Server[FTP 21] to Client[XYZ] ) – Response: 200 PORT      ->  OPENED
( Client[XYZ] to Server[FTP 21] ) – FTP Request: <CMD>    ->  CMD_SENT
( Server[FTP 21] to Client[XYZ] ) – Response: 150                ->  EXEC_STARTED
( Server[FTP 21] to Client[XYZ] ) – Response: 226                ->  EXEC_COMP

Steps followed for each of the above requests/responses:-

Packet1:-

First packet sent is the packet with PORT command from client to server.

 

When this packet is received, a flow-entry is made and IP_Address and PORT negotiated are calculated from the message. Also the state is changed to OPENING.

Packet 2:-

Second packet is the response to the PORT command.

Once it is received, Response code is calculated from the message. If  the response-code is positive ( like 200), a flow-entry is present in the flow_table for this packet’s flowID and state is OPENING, then the state is changed from OPENING to OPENED.

Packet 3:-

On the next packet if flow table has a entry for its flowID and is in the OPENED state with the direction from Client to server, then it’s a request from Client to server to perform a specified operation.

After receiving this packet, the state is now changed from OPENED to CMD_SENT.

In case of PORT commands, TCP 3-way handshake for the data-connection occurs after this packet is received by the server. Therefore, embryonic-flow-entry is made in the allowed-connections table on the firewall so that this data-connection traffic is not blocked by the firewall.

Packet4:-

Next packet for the particular flow is the response from the server. Based on the response code received, the state will be changed.

If the response from the server is positive preliminary reply and the state for the particular flow-entry is CMD_SENT, then the state is changed to EXEC_STARTED. If the response is negative, then the flow-entry is deleted, embryonic-flow-entry is also deleted.

Packet5:-

This is the last packet received indicating the status of the FTP command.

If the response code is ‘226’, this means the transfer has occurred successfully. If the previous state was EXEC_STARTED, the state is now changed to EXEC_COMP and the embryonic-flow-entry and flow-entry can be deleted from the respective tables. If some negative reply is received, even then the embryonic-flow-entry and the flow-entry are deleted from the tables.

STATE TRANSITIONS FOR PASV COMMANDS:-

For passive commands, it again goes through the five states mentioned below:-
( Client[XYZ] to Server[FTP 21] ) – FTP Request: PASV                   ->   OPENING
( Server[FTP 21] to Client[XYZ] ) – Response: 227 (port_no)         ->   OPENED
( Client[XYZ] to Server[FTP 21] ) – FTP Request: <CMD>             ->   CMD_SENT
( Server[FTP 21] to Client[XYZ] ) – Response: 150                         ->   EXEC_STARTED
( Server[FTP 21] to Client[XYZ] ) – Response: 226                         ->   EXEC_COMP

Steps followed for each of the above requests/responses:-

Packet1:-

First packet sent is the packet with PASV command.

Once it is received, a flow-entry is made in the flow_table. Also the state is changed to OPENING.

Packet 2:-

Second packet is the response to the PASV command. If a flow-entry is present in the flow_table for the packet’s flowID and its state is OPENING and the direction is from server to client, then its a response from the server.

Once it is received, Response code and PORT negotiated is calculated. According to the response code received, a particular action is taken. Suppose if its 227, then the state is changed from OPENING to OPENED.

In case of PASV commands, TCP 3-way handshake on the data-connection occurs after this packet is received by the client. Therefore, an embryonic flow-entry is made in the firewall’s allowed-connections table with the data-connection details.

Packet 3:-

If the next packet for the particular flowID is from Client to server and state is OPENED, then it is a request from Client to server to perform some operation.

After receiving this packet, the state is now changed from OPENED to CMD_SENT.

Packet4:-

Next packet for the particular flowID would be response from the server.

If the response from the server is positive and state is CMD_SENT, then the state is changed from CMD_SENT to EXEC_STARTED. If the response is negative, then the flow-entry and embryonic-flow-entry are deleted  from the respective tables.

Packet5:-

This is the last packet received indicating the status of the FTP command.

If the response code is ‘226’ and state is EXEC_STARTED, this means the transfer has occurred successfully, state is changed to EXEC_COMP and the flow-entry and embryonic-flow-entry can now be deleted from the respective tables. In case of negative replies also, the same action is taken.

Conclusion:-

This approach can be followed in all the cases where you have the data-path created dynamically and its information is negotiated on the control-path. Above example listed how this can be applied to FTP. Similarly, one can use it for RSH, MSRPC with different set of columns in flow_table( as per the protocol needs).