In my last post, I discussed how to monitor SSL traffic. Today, I thought I would continue down the road of traffic monitoring by taking a look at FTP traffic. Specifically, I would like to discuss how you can monitor FTP traffic, and how you can use NetFlow and metadata to understand what traffic is being sent over FTP. I will also provide some details on integration in Scrutinizer that will provide additional details relating to the FTP traffic.

What is FTP?

To start, let’s first define FTP and why you should be monitoring FTP traffic. According to Wikipedia, “the File Transfer Protocol (FTP) is a standard network protocol used for the transfer of computer files between a client and server on a computer network.” Most of your network traffic connections likely are HTTP/S (port 80 and 443) connections. Files like pictures, video, and other shareable content tend to be done over these protocols. When you notice that a user on your network is connecting over FTP, it should raise a red flag because what they are transfering may not be shareable content.  Additionally, FTP is an inherently insecure protocol (unless additional measures are taken) for transferring files between devices and so the likely-nonshareable content being transfered over FTP can be viewed by packet capture devices and sniffers.

How to monitor FTP traffic

Monitoring for FTP traffic can be done by enabling NetFlow/IPFIX on your network’s routers, switches, firewalls, and other devices that export flow and metadata. By enabling these exports, you will be able to see where FTP traffic is happening on your network. Specifically, you will know (at a minimum) the source and destination IP address, the amount of traffic being transferred, and when the transfer took place.

With the above in mind, let’s take a look at what a report from this NetFlow and metadata looks like in Scrutinizer. Scrutinizer has a new algorithm called “Rogue FTP.” This algorithm looks for FTP traffic on devices that don’t typically make connections via FPT, or when FTP connections are made to new locations. This algorithm works in line with Scrutinizer’s baselining technology to provide accurate reporting of, what we’ve defined as, Rogue FTP.

If we look in the alarms section of Scrutinizer, I can see that there is an event triggered for Rogue FTP.

rogue_ftp_alarms

From this view, I can see that the violator is IP address 10.1.15.19 and that the connection was made to the host ec2-34-205-25-88.compute-1.amazonaws.com. The user connected to the violating machine is tomp. If I select the dropdown carret on the left and select the default report option, I can see the specific connection details in Scrutinizer. Let’s take a look.

rogue_ftp_aws

As the alarm indicated, I can see that this FTP connection is bi-directional to the Amazon AWS server. Since I know the source IP and the username details for this file transfer, I can now go and ask the user, tomp, what file was being transfered; now, I will know if the traffic was wanted or unwanted.

But wait! Isn’t there a better way to do this than going to the user directly? If you have Endace probes on your network, you can. Scrutinizer has a built in feature called Pivot2Vision. With this feature, you can pass the details from the conversation over to EndaceVision, which will allow you to see the packet capture that Endace has for that conversation. Let’s take a quick look.

So, if I am in the same report above, I can select (click) the source IP address 10.1.15.19. A list of available reports will appear. At the bottom of the report list is Other Options. Hovering over this option will provide a second list of reports from which to choose.

pivot2vision

If you select the Pivot2Vision option, you will be connected to your EndaceVision interface with the details from the report passed over.

endace_vision

With EndaceVision, I can download the packet capture and view it in wireshark, or I can view the packet capture directly from within the interface. As I mentioned earlier, since most FTP connections are insecure, I can take the data from the packet capture and save the file to review the data that was being uploaded. Now I know what was being uploaded without ever needing to confront the violator. If the data being uploaded is in violation of your company’s policies, you can take appropriate action; otherwise, you can move on without the uploader being any the wiser.

Hopefully, that gives you a better understanding of how you can monitor FTP traffic, and the many benefits that Scrutinizer can bring with regard to the traffic on your network. To learn more about the many features and integration in our latest release of Scrutinizer, join us for our upcoming webinar, Scrutinizer v17 New Features.

Justin

Justin Jett is Director of Audit and Compliance at Plixer with roles ranging from system administration of web services to technical product marketing for Plixer’s incident response system, Scrutinizer. Jett, a graduate of the University of Maine at Farmington, is an avid learner of all things security, with a particular interest in TLS and DNS attacks.

Related

Leave a Reply