Bounce Unwanted Files Out of Your Folders

When Microsoft released Windows Server 2003 Release 2 (R2), one of the features that first caught my attention was file screening. File screening is a filtering mechanism in the File Server Resource Manager toolset that lets you control—by file extension—which files users can save to a folder or volume. The most obvious uses for file screening are to help control viruses by limiting where users can save executables and to prevent users from wasting storage space with unwanted and potentially illegal music or video files.

As I looked closer, I realized that file screening has many more security uses. Being able to control the content of a directory is a huge step towards securing a server. You could, for example, strictly control what types of files users are able to save in public Web content directories. A simple filter could block attempts to save anything other than .htm or .jpg files—or whatever types of files you specify.

But file screening can do more than blocking. You can configure it to allow certain files and then notify you or take some action when these files appear. You could, for example, receive an email message when someone places a new file of a certain type on your FTP server. The combination of blocking and notification lets you build many filters to automate system management or security functions.With a basic understanding of file screening, you can start building filters for your own servers to address a variety of scenarios. Let me show you how to set up the filters I've mentioned.

Getting Started
To use file screening, you must have Windows 2003 R2 installed. File Server Resource Manager and its file screening component aren't installed by default with R2, so you must add them. In Control Panel, open the Add or Remove Programs applet, then click Add/Remove Windows Components. In the list of components, double-click Management and Monitoring Tools and select File Server Resource Manager. Click OK and Next to complete the installation.

Once File Server Resource Manager is installed, you can access it from Administrative Tools on the Start menu. From File Server Resource Manager, you can view or work with all the file screens on your system. You can also manage file screens by using the command-line tool filescrn.exe, which is what I'll do in most of the examples in this article.

Understanding File Screening
When you create a file screen, you define a path to monitor, the file types to watch for, and the actions to take when a file of one of the designated types shows up. You can create a file screen from one of several templates or set your own custom properties.

The key to triggering a file screen is the file group, which is a list of file extensions you wish to match. You can use one of the default groups already configured, such as Executable Files, or you can create your own custom group.

You can make any file screen active or passive. An active file screen prevents users from saving any matching file; passive screening lets users save the file, then performs one or more actions that you specify.

There are four basic actions: send an email message, create an event log entry, run a command, or generate a report. Of course, because you have the ability to run a command, the scope of actions you can take is limitless.

Typically, when you create a file screen, it applies to the folder you specify and all of that folder's subfolders. If you want the subfolders to have different rules, you can create new filters for those folders or create an exception for a certain type of file.

File screening does have some limitations. One problem is that for any given directory, you can create only one filter or filter exception. So you can't, for example, block all audio files in a specific directory and receive notification about any new executable file in that same directory. Nevertheless, there are ways around most of the problems. With these workarounds, file screening can be a powerful security tool. Following are some filter ideas that you might find useful.

Restricting Web Content
Almost every Web-based intrusion I've seen has involved somehow placing files in Web server content directories or exploiting files that were already there but shouldn’t have been. Leaving clutter in your Web directories is asking for trouble, yet controlling files in these directories is a task that some administrators have a problem keeping up with. File screening gives you the ability to strictly control the file types allowed on your Web server or at least receive notification of new files being added.

For Web content, you can use one of two strategies: either block certain types of files and allow everything else or allow certain files and block everything else. For maximum security, it's best to make a list of files to allow and block the rest.

File screening comes with a file group for Web pages and a file group for images. But I find these two file lists much broader than necessary, so I built my own by opening a command prompt and entering (all on one line) this command:

Filescrn filegroup add  /Filegroup:"Unapproved Web Content"  /Members:"*.*"  /Nonmembers:"*.htm|*.html|*.asp|  *.aspx|global.asa|web.config|*.css|  *.gif|*.jpg|*.jpeg"

This command creates a new file group that works somewhat in reverse. Rather than defining which files to block, the command blocks all files except those listed. You should modify the list to match the specific file types you want to allow on your server. Notice that in addition to file extensions, you can use any valid file mask, including full filenames. You could, for example, allow one specific executable file and block all others.

It's interesting to note that file screening prevents only the creation of new files—it does nothing about files that are already on your server. This can actually be useful, because you might want to allow an existing file—such as global.asa—but you don’t want to allow anyone to create a new file with that name.

Once you've set up the file group, it's simple to create the filter by entering the following command:

Filescrn screen add   /Path:"D:inetpubwwwroot"  /Add-Filegroup:"Unapproved   Web Content"

Then you can test your new file screen by placing a new file in your Web root directory by using this command:

Echo testing > d:inetpubwwwroottest.bat

The result will be:

Access is denied.

If you find that completely blocking files is too restrictive, you might want to take a softer approach and have the system simply notify you when files appear in your Web content directories. To do that, instead of creating the active screen listed above, you can create a passive screen that sends you an email message when unwanted files appear.

Before you do that, you need to set some default options for sending email. The easiest way is through File Server Resource Manager in Administrative Tools. Open File Server Resource Manager, right-click File Server Resource Manager (Local) in the left pane, and select Configure Options to open the dialog box shown in Figure 1. On the Email Notifications tab, complete all the fields with the appropriate information. The tab also gives you an option to send a test email message to make sure emailing works.

With these defaults in place, you need to create a template for the message you want to send. Create a new text file named sendmail.txt and enter the text shown in Listing 1 into it. You can customize this configuration file according to your preferences, then save it in the current directory. To see the full syntax of the configuration file, type

Filescrn notification /?

After you've completed the message template file, create the passive file screen with this command:

Filescrn screen add   /Path:"D:inetpubwwwroot"  /Add-Filegroup:"Unapproved   Web Content"   /Type:Passive  /Add-Notification:M,sendmail.txt

Test your configuration again by using the same command:

Echo testing > d:inetpubwwwroottest.bat

If the person you specified in sendmail.txt doesn't receive an email alert, check the Windows event logs for errors. After you've finished adding the file screen, you can delete the sendmail.txt file you created because it's been imported into the file screen.

Blocking Dangerous Files
Over the years, hackers have used some common tools while compromising a server. But sometimes hackers aren’t the only ones to blame. It's not uncommon for administrators or users to place potentially dangerous executables in Web content directories without considering the security implications. Files such as cmd.exe or perl.exe in your Web content area can quickly lead to a compromised server because hackers have a knack for finding these files and using them to execute commands on the server. You might need a way to allow some executables that you use but disallow potentially malicious executables. Although many antivirus applications identify potentially malicious executables, you can also accomplish this with a file-screening filter and have the ability to customize the list of executables for your needs. Keep in mind that a file screen isn’t a replacement for an antivirus application, it's just a way to catch some of the most common threats.

To block malicious files, we need to create a new file group that contains the filenames we want to block.To create a file group with a few examples of potentially malicious files, you can use the following command:

Filescrn filegroup add   /Filegroup:"Dangerous Files"   /Members:"*.*"  /Nonmembers:"cmd.exe|perl.exe|  telnet.exe|ping.exe|tftp.exe|  osql.exe|nc.exe"

Next, create a rule to block these files from Web content directories:

Filescrn screen add   /Path:"D:inetpubwwwroot"  /Add-Filegroup:"Dangerous Files"

To take this concept one step further, many people delete certain executables from the Windows directory as part of their hardening process. But sometimes those files have a way of working themselves back onto the system. The following file screen can prevent that:

Filescrn filegroup add   /Filegroup:"Deleted Executables"  /Members:"*.*"   /Nonmembers:"telnet.exe|  ping.exe|tftp.exe|finger.exe|  rsh.exe"

Of course you would want to edit that list of files to match your own policy, but after doing so, create the filter:

Filescrn screen add  /Path:"c:Windows"  /Add-Filegroup:"Deleted   Executables"

With this filter in place, the Deleted Executables files won't be able to reappear.

Handling New Content
If you provide an FTP server to which users can upload files, you might want to take certain actions on those files to make sure they're safe. You might, for example, have the system automatically scan new executable files for viruses.

To make this happen, you can use a file screen that has a command action. Create a new text file named command.txt in any directory and enter the text shown in Listing 2. Again, you can customize this file to your environment and preferences, such as setting the correct path to your antivirus software. Don't modify the Source File Path parameter because it's a placeholder that the file screen uses.

The RunLimitInterval parameter is an important item to include. To prevent accidental or intentional flooding of your system with multiple email alerts, file screens suppress multiple notifications for the same directory for a period of time, which by default is 60 minutes. That way, if you try to move hundreds of blocked files to a protected directory, you won’t receive hundreds of emails—just one for the first file. If you do want action taken on every file, you must set RunLimitInterval to 0 minutes to prevent the suppression of events.

To scan executables uploaded to the FTP server, you need to create an action to run a command-line virus scanner on all new executables. You don't want to block content in this instance, so you create this as a passive filter:

Filescrn screen add   /Path:"d:inetpubftproot"   /Add-Filegroup:"Executable Files"  /Type:Passive   /Add-Notification:C,command.txt

Note that in this case, the file screen uses the built-in Executable Files file group. It uses the command.txt file to pass the filename of any file that appears in the ftproot directory and that might contain executable content to the virus scanner to check for viruses.

When I publish new content to a Web server, I like taking certain actions to help maintain control of the directory. The basic steps I take are to set the files as Read Only, set strict NTFS permissions, then reset the timestamps to the current time.

To perform these steps by using a file screen, you create a file group to match any new files in the directory:

Filescrn screen add   /Path:"c:Windows"   /Add-Filegroup:"All Files"

Next, you create a file named newcontent.txt that contains the text in Listing 3. Note that a file screen can't run a batch file of commands directly, so the screen must call cmd.exe and run the batch file as a parameter by using the /c option. With the previous commands as your guide, you should be able to come up with this file screen on your own. Finally, you need to create a new batch file in the Windows directory named newcontent.cmd and include any commands you wish to run on new files.

Sometimes, you might need to modify the new files themselves to remove debugging code, insert metatags, change relative paths, or remove comments. Furthermore, in some cases, you might want to place new content in a staging area before making it available on the main server. However, as I mentioned earlier, you can have only one filter per directory. I've already mentioned several that you might want to include just on your Web content directories. You can't include all the filters I've mentioned here by using the standard file screen actions.

The solution is to create a passive filter that passes all new files to a Windows Script Host (WSH) script that takes different actions based on the file extension, path, or filename. Remember, however, that if you call a script, you don’t call the script directly; you call cscript.exe with your script name as an argument.

You could also use a script to perform more elaborate file checking. File screening identifies content only by its file extension. Some files, such as Microsoft Office documents, are opened by the correct application no matter what file extension they have. In these cases, filtering by file extension isn't enough. In certain environments with stringent security requirements, you could build an advanced script that accurately identifies files by searching for certain known file signatures.

Delayed Actions
One thing I was anxious to use file screening for was to eliminate much of the clutter that accumulates on my servers. Program log files, debug logs, temp files, and backups tend to accumulate over time. Often, older versions of these files contain information of little use to you but of much use to an intruder. Although you should have an appropriate backup and log archival system in place, some files you just might not need to leave lying around.

You can use file screens to simply prevent applications from creating these files, but I found that some programs complain if a file write process fails. My solution is to allow the files to be created, but run a command to schedule a file screen job to run a few minutes after a new file appears. This scheduled job simply deletes the specified file. The applications never complain, and my servers remain much cleaner.

Controlling Files that Don’t Exist
One feature that I've always wanted in Windows is the ability to set NTFS permissions or auditing for files that don’t yet exist. New files in a directory automatically inherit NTFS permissions from the parent folder, but sometimes I want to override these inherited permissions with specific permissions for specific files. To take that one step further, it would be helpful to be able to set unique permissions by file type. Once again, file screening is the answer. A simple file screen would allow you to either set NTFS permissions directly on certain types of files or to launch a script to perform more elaborate permissions settings per file type.

With a little creativity, you can design file screens to automate a good portion of the tedious daily tasks that might consume much of your time. File screening is still a little rough around the edges and could use some extra features such as the ability to create multiple filters on a single directory, but the structure is in place and the possibilities are endless.