Since the Internet came into existence, we have been working with FTP. It was in the limelight even when the Internet was still a closed network used by the government and other corporate organizations.
FTP uses the TCP protocol to initiate and transfer files over a designated channel. There will be two channels created; one is the command channel, and the other one is specifically a data channel. The command channel will be used to send and receive the commands and their responses. The data channel is used to send data between the client and the server.
Commonly, port 21 is used by the FTP server to listen for the connection, and any random port on the client to send and receive data. As per the standard, port 21 will be used for the command channel and port 20 for the data channel. However, you will observe random port numbers used to transfer TCP data segments.
There are two types of mode a client uses to communicate with the server: active and passive. Both of them have a different approach to send and receive data. In earlier versions, active mode was in use by default, but these days, you can see passive mode in use by default. I will discuss each of them using my own virtual network where I have a FTP server (VSFTPD) configured on the 172.16.136.129 IP and a client at 172.16.136.1. The following sections described the flow and show how the client and server will behave in the active and passive modes.
- The client sends a
SYNrequest to the server running at port21. - The client receives
SYN/ACKfrom the server over a temporary port used. - The client sends
ACKto the server to confirm that the channel will be used for sending commands. Refer to the following screenshot:
- Now, the client will be shown a welcome banner and will be asked for the assigned credentials:
Figure 4.5: Server showing welcome banner and asking for credentials
- Normally, passive mode must be on by default. Performing a directory listing will tell you that the Extended passive (ESPV) mode is in use. In this mode, the client requests the server to listen on the data port and wait for the connection. In return, the server informs the client about the TCP port number used for the connection. Please refer to the below screenshot.
Figure 4.6: client sends ACK to the server
In frame
42, the server informs about the IP address and the port number that the client has to use while creating any data connection to the server. - In frame
42, the server informs us about the IP address and the port number that the client has to use while creating any data connection to the server. Followed by a sequence ofSYN,SYN/ACK, andACK, packets which us required to create a data channel between both the devices. After this, theLISTcommand is executed as seen in frame46. Then data is transferred using the temporary ports used by both the client and the server. - As soon as the data transfer is complete, the sending host closes the connection by transmitting a
FINpacket which is addressed by the receiving side using anACKpacket. The receiving side also sends aFINpacket that is acknowledged too. If both the devices want to share more data, then a new data channel will be created using random port numbers.
- The client sends a
SYNrequest to the server running at port21. - The client receives
SYN/ACKfrom the server over a temporary port used by the client. - The client sends
ACKto the server to confirm that the channel will be used to send commands. Refer to the following screenshot:
- Now, the client will be shown a welcome banner and will be asked for the assigned credentials:
Figure 4.7: Client is shown a welcome banner and asked for credentials
- Now, we have to turn passive mode off, because, as usual, it will be on by default. Once done, we can create a data channel for transferring purposes, refer to the following screenshot:
Figure 4.8 Creating data channel for transferring purpose
Frame
40shows that the client is requesting to switch the passive mode off using theEPRT |1|172.16.136.1|57197|command. Extended Port (EPRT) helps in specifying an extended address that can be used for data connection. The command accepts three arguments: network protocol, network address, and the port number. - Now, whenever the client tries to initiate a connection, it has to be destined for the particular address specified by the EPRT command. Before, every data connection server informed the client about the temporary port to be used.
You learned about the active and passive modes of communication that the FTP servers support. You also learned how they behave. Whenever troubleshooting any FTP connection, checking the mode will be useful and saves time.
In general, every request sent from the client is a specific command set to which the server responds with a numerical value followed by a text message. See the following screenshot:
As you can see, the server requested for the password, which the client provides. It can be seen over the wire in plain text in the list pane itself. Once the server receives and verifies that the password is correct, the respective message will be shown. In our case, the password is correct, so the client receives 230 as a response code followed by a Login Successful message.
The command issued from the client side can have arguments or no arguments, and the data flowing across between the devices can be simply seen in the TCP header of the packet. Refer to the following Figure 4.9:
Figure 4.9: FTP-DATA returned
Frame 43 shows that the client issued the LIST command that was processed by the server, and 262 bytes of data was returned back to us. Select frame 50 to further investigate the contents of the TCP header. One of the biggest disadvantages of using FTP is that all data travels in plain text, even the usernames and passwords.
Reassembling the FTP data stream is easy because except the data, there is nothing that travels around. There is no code or command that gets appended to the packets travelling, thus making it easy for Wireshark and the user to understand things easily. To reassemble the TCP stream of FTP packets, just right-click on the selected packet, choose the Follow TCP Stream option, and view it in raw form. Refer to the following Figure 4.10:
Figure 4.10: FTP stream
The entire communication between the client and the server that happened over the data and command channels is translated into human-readable format. Text in red color is what the client sent, and text in blue color is what the client received. These days, we have a couple of advanced protocols that can create an encrypted channel. One of them is Secure File Transfer Protocol (SFTP).
There can be multiple scenarios, which generate FTP traffic of an unusual type. I will use a couple of scenarios to explain this and will show you how a certain traffic type looks. An example would be brute force attacks where a malicious user tries different passwords again and again, until the exact password is matched. This is the most common traffic type that you will see while working with FTP. Applying a ftp.request.command=="PASS" filter will show all the password attempts that have been made to your server. If you see an unusual number of attempts in a short span of time, then it can be a brute-force attempt against your server. Refer to the following screenshot:
Figure 4.11: FTP brute force
I applied the same display filter mentioned earlier, and you can see the results. Someone was trying to brute force my FTP server. To secure your server from such brute force or dictionary attacks, you can limit the server to maximum login attempts, after which the server should lock down the respective account for a particular amount of time.
You could also colorize the brute force traffic if you want. This will eventually give you a better overview of your capture file or live traffic. Try it out using the code that the server sends back to the clients in response.
Another example is a malicious device that is infected by some malware. Due to the malware, the device is trying to contact a command and control-center server to download some payload, perhaps for privilege escalation purpose or to launch further attacks. There is even a possibility where an attacker sitting on the other side is trying to download or upload something. Let me take an example to explain. I have a Kali Linux box running at 192.168.1.105 and a Windows box at 192.168.1.104. Through Kali, I created a small malware that was downloaded and installed by the victim (Windows). Once executed, we will get the shell from the device. Then, we can launch FTP from within the shell to connect our Kali box for privilege escalation purposes.
Refer to the following screenshot that captures the FTP traffic between the attacker and the victim:
Figure 4.12: victim FTP capture
As you can clearly see, the attacker connected to the FTP server and downloaded the payload.txt file, which might be used to gain root privileges over the box.
If something of this nature is able to bypass your firewalls and other security appliances in place, then consider improvising the configuration you created and try to avoid these things in future. Sometimes, activity of this kind can be legitimate as well, but it should not stop you from investigating further. A small file of a few kbs is enough to compromise your whole network.