Tracking and Controlling Access To Network Resources with CBFS Filter

One crucial step in protecting sensitive data from leaks is controlling access to remote network resources. This access can be managed using various Internet protocols, such as HTTP, FTP, and WebDAV, or through local network protocols like SMB and NFS. While Internet protocols are beyond the scope of this article, our focus will be on local network protocols.

When remote filesystems are accessed via a local network, operations are handled through standard filesystem mechanisms. The client of the network protocol functions as a system component that acts like a filesystem for all local purposes. This means that a filesystem filter driver can control the operations performed by the local operating system, system components, and user-mode processes on this filesystem.

CBFilter provides powerful mechanisms to track, monitor, and control filesystem operations, whether they originate locally or from other systems over the network.

The system component responsible for standard network-based filesystems is known as MUP (an abbreviation for Multiple UNC Provider, where UNC stands for Universal Naming Convention). Therefore, we should monitor filesystem requests directed to MUP, as it will forward them to network-based filesystems.

Suppose we need to log all access to remote files and directories. In this case, we can add the following rule:

filter.AddFilterRule("\\Device\\Mup\\*.*", Constants.ACCESS_NONE, Constants.FS_CE_NONE, Constants.FS_NE_ALL);

Next, we should handle all Notify* events provided by CBFilter by defining the appropriate event handlers. These event handlers will log the filename and request parameters, with a particular focus on the filenames.

If an application has to block or in other way control the requests going to the outside the system. In this case, we add the following rule:

filter.AddFilterRule("\\Device\\Mup\\*.*", Constants.ACCESS_NONE, Constants.FS_CE_BEFORE_CREATE | Constants.FS_CE_BEFORE_OPEN /* and maybe other FS_CE_BEFORE_* flags here*/, Constants.FS_NE_NONE);

Next, we handle the Before* events of CBFilter that correspond to the flags we added (in the above example, these are BeforeCreateFile and BeforeOpenFile events). These event handlers can deny file creation/opening requests either unconditionally or after evaluating the request parameters.

When analyzing the name of a file or directory passed to the event handler, it is vital to take the following specifics into account.

The operating system does not rely on traditional “drive letters” as its primary identifier. Instead, it uses NT-native paths. By default, the CBFilter component translates these paths into more familiar ones based on drive letters. While this translation is not always possible, in most cases, the value you see in the Filename parameter of the events reflects this translation.

Translation can be disabled with the following call:

filter.Config("ResolveNtDeviceToDriveLetter=False");

What does this have to do with network access?

The NT-native format for remote file names is

\Device\Mup\{prefix};{lots-of-information-here}\filename.ext

. The information within the NT-native path is specific to the redirector; different protocols like SMB, NFS, VMWare HGFS, and WebDAV client each use distinct formats.

The prefix is the name provided by the redirector that allows MUP to determine where to route a file open request for a path containing a specific prefix. For example, the common network sharing protocol via SMB uses the prefix “LanmanRedirector,” VMWare uses “hgfs,” and the “Csc” prefix is used by the Offline Files service in Windows.

If a remote resource is mapped and accessed via a local drive letter, the translated path received by the application in the event handlers would be as simple as M:\path\to\filename.ext, where M: represents the mapped network drive. Note that the filter rule set for \Device\Mup\*.* will still function correctly because name matching occurs in the kernel, independent of path translation. Additionally, if you create a rule for "M:\path", it will work as long as M: is a valid drive letter when the rule is sent to the driver (this happens when filtering is initiated or when the rule is added to the active filter).

If path translation fails, the application will receive the name in the NT-native format.

This way, once an event is fired, you can be confident that the network access is a part of the operation.

Note: Some supplementary requests and administrative operations are conducted by opening pseudo-shares and pseudo-paths, allowing the resulting handle to be used to talk to drivers or remote systems. One such pseudo-share is the “IPC$” share, used by the system for communication. These supplementary requests should not be blocked. However, the responsibility of determining which requests are applicable for each remote access protocol lies with the application developer; additional testing is necessary if blocking is involved.

Getting Started with CBFilter

You can find an evaluation version of the SDK for your platform and programming language in the Download Center. After downloading and installing the SDK, you will receive a library, sample code, and comprehensive documentation on your system. The documentation includes a "Getting Started" section with programming instructions. Additionally, free technical support is available during the evaluation phase.