A real business need for network traffic analysis: File activity monitoring!
For many people network traffic analysis is seen as a troubleshooting tool, something for the packet experts who spend their time in Wireshark. However, network packets are an excellent source of user and application metadata.
Metadata can be defined as the human readable portions of the network packets. Filenames, web domains, SQL queries, and IP addresses are examples. While you can extract this metadata using tools like Wireshark, it can be a struggle if you are aiming to capture traffic just by packets.
SMB and NFS
Server Messaging block (SMB) and Network File System (NFS) are two most popular protocols for accessing files and folders on network shares. SMB is typically used on networks with Windows clients and NFS is typically used by non-Windows operating systems, such as Linux. While SMB can support encryption, most implementations are not configured to use this.
Are log files enough?
It is possible to enable file activity auditing on a Windows fileserver. However, you must specify what folders to monitor and it will generate thousands of events and so is not scaleable. The data from these logs could be fed into a SIEM. SIEMs also have limitations, starting with the fact they are only as good as the log events being fed. If the log records are incomplete or someone disables logging, then you lose your audit trail.
A common issue I come across is systems such as NAS servers do not have native logging options. They are designed to serve up large quantities of files and folders securely. Auditing and logging can slow these systems down which means most will not have auditing capabilities.
Log files will also miss security type information such as clients using SMBv1 or the ability to generate an alert if a client suddenly started to rename large numbers of files. This can be the sign of Ransomware activity.
Capturing SMB or NFS metadata from network traffic
As the adage goes, packets never lie. For users to access files on a network share, their network device must establish a connection for packets to flow. User actions such as read, write, and delete can be extracted from this network traffic. You can use the approach for both SMB and NFS, you just need to know where to look. The image below shows an example of SMB metadata captured in Wireshark.
While Wireshark is useful for troubleshooting activity associated with a single client, it is not ideal for capturing a real-time and historical record of all file and folder activity for an extended period. This requires a dedicated solution to monitor network traffic 24/7.
A network traffic analysis application that includes application awareness of protocols like SMB or NFS is ideal for scaleable file and folder activity monitoring. Deploying is typically a two-stage process. You install an appliance, or a software install, and you hook it up to a TAP or SPAN port. This approach does not require any software agents or changes on the file servers.
The image below shows a typical setup. A copy of the traffic going to and from the file server is sent to a network traffic analysis tool. In this case our own product, LANGuardian.
As I mentioned previously you can also use a network TAP to get a source of data. For file servers deployed on virtual platforms such as VMWare ESX you can capture network packets using virtual port groups. You just need to enable promiscuous mode on the port group and this gets rid of the need for any physical hardware or network connection.
The screenshot below is an example of a file activity report from our own network traffic analysis tool, LANGuardian. It includes both a SMB and NFS decoder which can generate file and folder activity audit trails as well as detect SMBv1 if you want to root out weak protocol use on your network.
For LAN Guardian Demo - Click here
Monitoring network traffic to your file servers can address a range of business needs. Anything from compliance standards such as NIST to getting alerts if users access sensitive data hosted on network file shares. This approach is vendor agnostic so you can get an audit trail even if your file server does not support logging.