File Control Filter Driver SDK

Download  EaseFilter File Security SDK Setup File
Download  EaseFilter File Security SDK Zip File

What is the File Control Filter Driver SDK

The EaseFilter File Control Filter Driver SDK is a kernel-mode development kit designed to monitor and control file I/O activities at the file system level in real time. By intercepting file system requests, this SDK allows developers to log, modify, or prevent I/O operations across one or more file systems. This capability enables the development of robust file security applications that can authorize or deny file access to specific users or processes, thereby safeguarding sensitive data from unauthorized access.

Understand File System Filter Driver

A file system filter driver operates within the Windows kernel, intercepting requests directed at a file system or another filter driver. By capturing these requests before they reach their intended targets, the filter driver can extend or replace the functionality provided by the original target. This mechanism is essential for implementing advanced file security measures.

File Access Control Mechanism

The EaseFilter control filter driver can intercept file I/O operations both before they are processed by the file system (pre-operation) and after they have been processed (post-operation). This dual interception capability allows for comprehensive monitoring and control of file access.

How File Access Control Works

In Windows, file access involves I/O operations such as reading and writing. To access a file, applications invoke Win32 APIs like CreateFile, ReadFile, WriteFile, MoveFile, and DeleteFile. The I/O manager intercepts these calls, sets up I/O request packets (IRPs), and routes them through layered drivers to physical devices. If a file system filter driver is installed and registered with the volume containing the file, it can intercept these I/O requests. The filter driver can then choose to pass the request to the next layer, modify it, or complete it without passing it down, effectively controlling the file access.

I/O operations are layered, when a user application invokes a Win32 API, the I/O manager intercepts this call, sets up one or more I/O request packets (IRPs), and routes them through possibly layered drivers to physical devices, if a file system filter driver was installed and registered with the volume which the file was located, it can intercept this I/O, then the filter driver can pass through this I/O to next layer driver or complete this I/O. If the filter driver passes through this I/O, the filter driver can intercept this I/O request which comes back from the Windows file system if the post I/O operation was registered. If the filter driver completes this I/O, the request will not pass down to the Windows file system, the filter driver can return your won status and appropriate data to the user application.

The filter driver can register a preoperation callback routine, a postoperation callback routine, or both. When the filter driver intercepts the I/O request, it can get the caller’s process name, user’s SID (Security Identifier) which it can decode the user name, domain name, the filter driver also can get the current I/O information, the I/O type (create, read, write, rename, delete…), the file name and the file information ( file size, file time, file attributes…). If the filter driver only wants to monitor this I/O request, it can send those informations to the user, if the filter driver wants to control this I/O request, it can denied this I/O request, or modify the I/O data and return status.

Pre-Operation Blocking

With the file system filter driver, you can prevent unauthorized file modifications by blocking file operations before they reach the file system—a process known as pre-operation (pre-IO) interception. For instance, to block file creation, deletion, writing, or renaming, the filter driver can complete the file operation with an "access denied" status before it proceeds to the file system.

Filter Rule Configuration

The SDK allows for the setup of filter rules to define file access policies easily. These rules can specify access rights for specific users or processes, enabling authorization or denial of file access based on defined criteria. This granular control ensures that only authorized entities can interact with sensitive files.

Zero-Trust File Access Control

Implementing a zero-trust file access security solution is simple with the EaseFilter SDK. In a zero-trust model, all users and processes are denied access to files by default. With the EaseFilter File Control SDK, you can enable zero-trust protection by simply setting up a file control filter rule with zero access rights. This ensures that no one can access your files unless explicitly authorized.

File Access Control with Blacklisting and Whitelisting

In a zero-trust environment, all users and processes are effectively on the blacklist by default—meaning they are denied access unless granted permission. This approach protects your files from unauthorized access and mitigates the risk of attacks from malicious software.

To allow access, you can create a whitelist of trusted users or processes by assigning specific access rights. This way, only approved entities are permitted to access protected files, ensuring secure and controlled file sharing.

File Hiding with Filter Masks

With the EaseFilter SDK, you can define filter rules to hide files using file filter masks. Files can be hidden from unauthorized users or processes, making sensitive data invisible and inaccessible to anyone without proper authorization. This adds an extra layer of security by concealing critical files from prying eyes.

File Reparse with Filter Masks

The EaseFilter SDK also supports file reparse rules, allowing you to redirect file open operations from one folder to another. For example, a request to open a file in Folder1 can be transparently redirected to Folder2. This feature enables flexible file access redirection and isolation without modifying application behavior.

File Protection with C#

The EaseFilter SDK offers an API interface that mirrors the familiar Win32 API, making it accessible to any programming language that can interact with the Windows API. Currently, the SDK includes C++ and C# demo source code, allowing developers to quickly integrate EaseFilter capabilities into their Windows applications.

The following C# example demonstrates how to create a filter rule to protect a specified directory at runtime. The rule is configured to prevent files within the directory from being:

• Renamed

• Deleted

• Written to

The filter rule is registered to listen for create and delete I/O callback events. When a file is opened or deleted, an event is triggered, allowing your application to allow or deny the operation based on your custom logic.

For a more comprehensive demonstration of the SDK’s features, you can refer to the FileProtector example included in the SDK package.

  		
using System;
using EaseFilter.FilterControl;

namespace FileProtectorConsole
{
    class Program
    {
        static FilterControl filterControl = new FilterControl();

        static void Main(string[] args)
        {
            string lastError = string.Empty;
            string licenseKey = "Email us to request a trial key: [email protected]";

            FilterAPI.FilterType filterType = FilterAPI.FilterType.MONITOR_FILTER|FilterAPI.FilterType.CONTROL_FILTER
                |FilterAPI.FilterType.PROCESS_FILTER|FilterAPI.FilterType.REGISTRY_FILTER|FilterAPI.FilterType.ENCRYPTION_FILTER;

            int serviceThreads = 5;
            int connectionTimeOut = 10; //seconds

            try
            {
                //copy the right Dlls to the current folder.
                Utils.CopyOSPlatformDependentFiles(ref lastError);

                if (!filterControl.StartFilter(filterType, serviceThreads, connectionTimeOut, licenseKey, ref lastError))
                {
                    Console.WriteLine("Start Filter Service failed with error:" + lastError);
                    return;
                }

                //the watch path can use wildcard to be the file path filter mask.i.e. '*.txt' only monitor text file.
                string watchPath = "c:\\test\\*";

                if (args.Length > 0)
                {
                    watchPath = args[0];
                }

                //create a file protector filter rule, every filter rule must have the unique watch path. 
                FileFilter fileProtectorFilter = new FileFilter(watchPath);

                //configure the access right for the protected folder

                //prevent the file from being deleted.
                fileProtectorFilter.EnableDeleteFile = false;

                //prevent the file from being renamed.
                fileProtectorFilter.EnableRenameOrMoveFile = false;

                //prevent the file from being written.
                fileProtectorFilter.EnableWriteToFile = false;

                //authorize process with full access right
                fileProtectorFilter.ProcessNameAccessRightList.Add("notepad.exe", FilterAPI.ALLOW_MAX_RIGHT_ACCESS);

                //you can enable/disalbe more access right by setting the properties of the fileProtectorFilter.

                //Filter the callback file IO events, here get callback before the file was opened/created, and file was deleted.
                fileProtectorFilter.ControlFileIOEventFilter = (ulong)(ControlFileIOEvents.OnPreFileCreate | ControlFileIOEvents.OnPreDeleteFile);

                fileProtectorFilter.OnPreCreateFile += OnPreCreateFile;
                fileProtectorFilter.OnPreDeleteFile += OnPreDeleteFile;

                filterControl.AddFilter(fileProtectorFilter);

                if (!filterControl.SendConfigSettingsToFilter(ref lastError))
                {
                    Console.WriteLine("SendConfigSettingsToFilter failed." + lastError);
                    return;
                }

                Console.WriteLine("Start filter service succeeded.");

                // Wait for the user to quit the program.
                Console.WriteLine("Press 'q' to quit the sample.");
                while (Console.Read() != 'q') ;

                filterControl.StopFilter();

            }
            catch (Exception ex)
            {
                Console.WriteLine("Start filter service failed with error:" + ex.Message);
            }

        }

        /// 

        /// Fires this event before the file was opened. 
        /// 

        static void OnPreCreateFile(object sender, FileCreateEventArgs e)
        {
            Console.WriteLine("OnPreCreateFile:" + e.FileName + ",userName:" + e.UserName + ",processName:" + e.ProcessName);

            //you can block the file open here by returning below status.
            e.ReturnStatus = NtStatus.Status.AccessDenied;

        }

        /// 

        /// Fires this event before the file was deleted.
        /// 

        static void OnPreDeleteFile(object sender, FileIOEventArgs e)
        {
            Console.WriteLine("OnPreDeleteFile:" + e.FileName  + ",userName:" + e.UserName + ",processName:" + e.ProcessName);

            //you can block the file being deleted here by returning below status.
            e.ReturnStatus = NtStatus.Status.AccessDenied;
        }
    }
}