Discussion on the Influence of firewall on FTP and troubleshooting

FTP is a common TCP-based network service. It uses two TCP connections to establish a logical communication channel, that is, control connections and data connections. When the client establishes an FTP session with the server, use TCP to create a persistent control connection to pass commands and responses. When sending files and other data, they are transmitted on an independent TCP data connection, which is created and removed as needed.

More complex, the FTP Standard specifies two different methods for creating data connections, namely normal (active) data connections and passive data connections. The FTP control connection is always initiated by the client first, the active data connection is initiated by the server, and the passive data connection is initiated by the client.

After a control connection is established successfully, the client sends the PORT command during the active connection. The address and port information are embedded in the command to inform the server of the connection, then, the server opens the default port 20 and establishes a data connection to the address and port notified by the client. When conducting a passive connection, the client uses the PASV command to tell the server to wait for the client to establish a data connection, and the server to respond, to tell the client what port on the server should be used for data transmission (randomly opened ). This kind of Working Mechanism brings about a serious problem: Passing IP addresses and port numbers in FTP commands (port or PASV) or answering them seriously conflicted with the network layering mechanism, if the NAT feature is enabled on the gateway device (firewall or router) between the communication channel between the FTP client and the server, the connectivity problem may occur.

The firewall has a profound impact on TCP applications connected to multiple ports like ftp. In a complex network environment, the diversity of devices and software may lead to unpredictable problems. As a network administrator, I have a deep understanding of the working principles of firewalls and FTP and the impact of firewalls on FTP in Nat environments, it is of great benefit to select FTP service software, install, deploy, manage and maintain FTP services, and eliminate FTP application faults in actual work. This article takes a common FTP deployment and application topology in the actual environment as an example to explain in detail the impact of firewall (with NAT enabled) on FTP. If any, please correct me.

I. Network Topology

2. Active Connection Analysis

As shown in the network topology in this example, the IP address is 192.168.1.1, and the client computer opens an available TCP port 1025, after Nat is converted to 1.1.1.1 and 1025 through the front-end firewall, a connection to port 21 with the target address 2.2.2.2 is established, then, the front-end firewall of the server transmits the connection information to port 21 at server 172.16.6.1, And the FTP control connection is established successfully.

The server returns data packets through the established logical connection channel and interacts with the client. Then, the client sends the PORT command and embeds the address information (IP: 192.168.1.1, Port: 1026) in the command to inform the server of data connection, open port 1026, and wait for the server to connect. When the packet carrying the PORT command arrives at the client's front-end firewall, the NAT table item is successfully created due to Nat, And the IP address and TCP port information of the packet are rewritten:

If the firewall does not recognize and check that the connection is an FTP application, it cannot rewrite the address and port information embedded in the PORT command, after the data packet is transmitted to the server through the control connection channel established previously, the server opens port 20 and establishes the data connection to port 1026 of 192.168.1.1.

Apparently, this connection packet is either discarded by the firewall at the front end, or immediately dropped after it enters the internet, and will never arrive at the client. In this case, the client is always in the control connection phase to send packets containing port instructions to establish a data connection, while the Server opens port 20, keep trying to establish a data connection to the client, but never receive the response.

The direct result is that the client successfully connects to the FTP server, but data transmission fails. There may also be a hidden security threat: If 192.168.1.1 is directly accessible to the server host, the server sends data packets to this computer, there is an inexplicable data flow between the two hosts. I will not discuss other situations that may be more concealed or worse.

If the firewall supports reviewing and tracking FTP applications at this time, that is, it can identify the content in the PORT command, and rewrite the embedded address information to (IP: 1.1.1.1, Port: 1026) and dynamically open port 1026, and create a new Nat translation table, wait for the connection, when the server receives the PORT command, Open Port 20, establish a connection to port 1026 on 1.1.1.1, after successful interaction, data can be transmitted.

Iii. Passive mode Connection Analysis

After the control connection is established, the client sends the PASV command to the server, and the server opens an available TCP port at random, and sends the address and port information (IP: 172.16.6.1, Port: 50000) return to the client to notify the client to use the information for data connection. When the packet containing the server address information reaches the firewall at the front end:

If the firewall cannot identify and check the application-layer data of this data packet, it cannot be determined that it is the return packet of the ftp pasv command, and rewrite the embedded address information, when this packet is returned to the client, the client will randomly open port 3000 to connect data with the destination address 172.16.6.1 and port 50000. Similarly, this connection packet will never reach the server.

In this case, the client will always try to establish a data connection, but cannot always receive a response. Hidden security threats, as described above.

If the firewall can review and track FTP applications and overwrite the server address information embedded in the returned package, it will convert it to (IP: 2.2.2.2, Port: 50000 ), create a new NAT table, dynamically open port 50000, and wait for the connection. When the return packet arrives at the client, the client opens port 3000 at random and creates a new connection with the destination address 2.2.2.2 and port 50000 to establish a data connection.

Based on the above analysis, in order to successfully transmit FTP data, the firewall at the client's front-end must be able to review and track FTP applications after Nat is enabled in active mode, identify and rewrite the client address information in the PORT command. in passive mode, the firewall at the front-end of the server is required to rewrite the server address information returned from the data packet after the server responds to the PASV command.

Of course, to ensure the normal use of FTP applications, we recommend that both firewalls support FTP identification and content review.

Iv. network firewall and FTP

The default access control policy for most network administrators to set firewalls is to allow all traffic from the internal to the external, and prohibit all traffic from the external to the internal.

For FTP applications, in order to simplify the configuration of firewall policies and meet the security policy requirements, it is better for the client to select the passive mode for data connection, you do not need to set a special access control policy for the front-end firewall, but require that the front-end firewall of the server be able to dynamically open the random ports required for data connections; the server should choose to actively connect, to allow access from the client, the access control policy of the front-end firewall only needs to explicitly open port 21, but the front-end firewall of the client needs to dynamically open the port required for data connection.

From the perspective of convenient use, since FTP service is provided, you must configure the server front-end firewall so that its access control policy can support the normal operation of FTP services in two modes.

If the client's front-end NAT device is a router, not a firewall, and cannot review and track FTP applications, we can infer from the previous analysis that there must be connectivity problems in the active mode, you must establish a data connection passively to successfully use the FTP service.

If the FTP control port is a custom TCP port (such as 2121), in this case, the front-end firewall of the server explicitly instructs the FTP control port through the configuration command, reviews and tracking are now available. However, even if the front-end firewall of the client can identify FTP applications under the default port, FTP services that control ports other than port 21 will be treated as common TCP applications. In this case, you cannot rewrite the client address and port information in active mode. As a result, the server fails to establish a data connection, but the client works normally in passive connection mode.

To sum up, it is most appropriate for the client to use a passive method to connect to the FTP server and minimize the connectivity problem. At the same time, it reduces the requirements for client front-end firewall backup, does not need to dynamically open random ports that are allowed to input as actively, and pushes possible security threats to the server. This may be the reason why Microsoft's Internet Explorer (Resource Manager) uses the passive mode by default. Table 2. In addition, in Windows command line, FTP uses active data connection by default.

V. host firewall and FTP

If you set up an FTP server on Windows Server 2008, the control connection established by the client to this ftp server will be blocked because it has built-in Windows Firewall and is enabled by default, in this case, you need to open the incoming connection to TCP port 21 on the firewall.

In passive mode, because the port number that the server uses to listen to client requests through the control channel is randomly generated, the incoming connection ports that need to be opened on the firewall are also random. As Windows Firewall does not dynamically open or close random ports required by FTP services as needed, it needs to open all possible random ports statically.

The default dynamic port range of Windows Server 2008 is 49152-65535, while the exception opening rule of Windows Firewall can only be opened for a single port. More than 10 thousand ports in the range of 49152-65535 must be opened, it is extremely impractical, but it poses a serious security threat to hosts running FTP servers.

Fortunately, the FTP server established based on iis7.0 allows the port number to be fixed in a self-specified range, such as 50000-50005. In this case, you only need to open the port in this small range, this greatly improves security and the efficiency of configuring Windows Firewall. If a third-party firewall is deployed on the server, you must carefully consider how to set it to ensure the normal operation of the FTP service.

Original article address:

Http://www.5iadmin.com/post/919.html

Http://zhidao.baidu.com/question/423752751.html

Windows built-in FTP command does not support passive mode http://blog.gdsyzx.edu.cn/sense? P = 736