Since the release of Windows 2000, Microsoft has touted security templates as the best solution for automating and enforcing a consistent security policy. Microsoft has released sample security templates for various server roles, such as Web servers and domain controllers (DCs). Other parties, including the National Security Agency (NSA) and National Institute of Standards and Technology (NIST), have published similar templates. Although these templates are good, the full power of security templates remains largely untapped. In particular, file-system and registry security continues to be a largely misunderstood and underused portion of security templates. File-system and registry security plays such a vital role in Web server security that exploring how to read security templates and how to use them to selectively set permissions is well worth the time.
Security templates are text files that drive the implementation of a local or domain security policy. Security templates are a subset of Group Policy, so you can deploy security templates on standalone servers or distribute them as an organizational unit (OU) policy. The safest way to edit security templates is to use the Microsoft Management Console (MMC) Security Templates snap-in, but you can also use any text editor. Because the snap-in is somewhat quirky and inconsistent, I used a text editor to directly modify the security templates for all the examples in this article.
This article assumes you have some knowledge of security templates and a template with which to work. If you don't have a basic template, I recommend that you download Microsoft's security templates (http://download.microsoft.com/download/win2000srv/scm/1.0/nt5/en-us/hisecweb.exe) or NSA's security templates (http://nsa1.www.conxion.com/win2k/download.htm). If you're unfamiliar with security template basics, I recommend that you read Paula Sharick's January 2002 Web-exclusive sidebar "Building a Custom Security Template" (http://www.secadministrator.com, InstantDoc ID 23082).
How to Read Security Templates
If you open the basicws.inf security template that resides in the \%systemroot%\security\templates directory and scroll to the bottom, you'll see a long list of entries such as
"c:\boot.ini",2,"D:P(A;;GRGX;;;PU) (A;;GA;;;BA)(A;;GA;;;SY)"
(In the basicws.inf file, this entry would be on one line.) This part of the security template sets file-system security. For example, the sample entry I just gave sets permissions for the C:\boot.ini file.
The entries in the file-system security section consist of three parameters. The first parameter is the pathname (e.g., C:\boot.ini). The second parameter (e.g., 2) specifies how you want the Security Configuration Editor (SCE) to propagate the file's ACL. The possible values for the second parameter correspond to the options in the Template Security Policy Setting dialog box, which Figure 1 shows. The values are
- 0—corresponds to the Propagate inheritable permissions to all subfolders and files option
- 1—corresponds to the Do not allow permissions on this file or folder to be replaced option
- 2—corresponds to the Replace existing permissions on all subfolders and files with inheritable permissions option
Most often, you'll use the value of 2.
The last parameter—e.g., "D:P(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"—is a discretionary ACL (DACL) of a Security Descriptor (SD). This cryptic string uses the Security Descriptor Definition Language (SDDL) to specify the DACL in text format, which provides for easy storage of the SD. Although the DACL string might look confusing, with a little practice, you'll find that using this string to set permissions is much easier and more direct than using dialog boxes.
The basic format for a DACL string is D:DACL Flag(ACE Type;ACE Flags;Rights;Object GUID;Inherit Object GUID;Account SID). The string starts with D:, which specifies that you're setting a DACL. The value that follows D: is the DACL flag, which you use to specify whether you want to allow or protect against inheritable permissions. In the sample DACL string, the DACL flag is P, which denotes that you want to protect the DACL against modification by inherited access control entries (ACEs). Web Table 1 (http://www.windowswebsolutions.com, InstantDoc ID 25576) shows the values for the other two DACL flags that you can use.
After the DACL flag is a series of fields enclosed by parentheses. The information in these fields makes up an ACE. Notice that the sample DACL string has three sets of parentheses. Each set represents an ACE, so this boot.ini file has three ACEs.
Inside each set of parentheses, you can include up to six optional fields. The first field is ACE Type. As Web Table 2 shows, the commonly used ACE types include those that allow access to the DACL, deny access to the DACL, and enable auditing. In the sample DACL string, all three ACEs allow access, denoted by the A parameter.
You use the ACE Flag field to specify inheritance or auditing options. Web Table 3 shows a few of the possible values you can use. In the sample DACL string, the ACE Flag field is blank in all three ACEs because the DACL is protected against inheritable ACEs and auditing isn't enabled.
The Rights field assigns access rights to the ACE. Microsoft classifies the available rights into five categories: Directory Service (DS) access, file access, generic access, registry key access, and standard access. Web Table 4 shows the rights in the file access, generic access, and registry key access categories. In the sample DACL string, the first ACE has Generic Read and Generic Execute rights and the other two ACEs have Generic All rights.
If an ACE is object-specific, you can use the Object GUID and Inherit Object GUID fields to specify the object's globally unique identifier (GUID) and inherited object GUID, respectively. In the sample DACL string, these fields are empty in all three ACEs because the ACEs aren't object-specific.
In the last field, Account SID, a SID string identifies the account to which the ACE applies (i.e., the ACE's trustee). Web Table 5 lists some of the many system-provided accounts that you can specify by using a two-letter SID string. You can also specify a SID string that represents a specific account on your system. For a complete list of the two-letter SID strings, go to the Microsoft Developer Network (MSDN) Library (http://msdn.microsoft.com/library) and navigate to Security, Security (General), SDK Documentation, Authorization, About Authorization, Access Control, Security Descriptor Definition Language, SID Strings. To see the complete list of values for the ACE Types, ACE Flags, and Rights fields, click the ACE Strings link.
You set registry permissions the same way you set file-system permissions, except that instead of specifying a filename, you specify a registry key or subkey. For example, the DACL string "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip",2,"D:(A;CI;GR;;;WD)" allows everyone Generic Read access to the Tcpip subkey and its child containers. The basicws.inf security template also has examples of DACL strings that set registry permissions.
A little-known fact is that you can use a security template to set a file's owner and primary group. Instead of using the DACL string, you use the string "O:Owner SID" to assign a file owner and the string "G:Group SID" to assign a primary group. Both the Owner SID and the Group SID are SID strings. You can also use a security template to create a system ACL (SACL), which specifies an object's audit setting. SACL strings are identical to DACL strings, except they begin with S: instead of D:.
Now that you know how to read security template entries, let's explore some advanced uses for security templates. Specifically, let's look at how you can use security templates to limit file access, control component access, control file extensions, hide your tracks, hide drives, and protect sensitive files.
Limiting File Access
Perhaps the most common advice for how to secure Web servers is to tighten permissions on the file system. Because many of the files in a default IIS installation have the SID Account set to Everyone, the most important task is to deny Web users access to system and other sensitive files. Web users don't need to have Read (much less Write) access to anything outside the Web root. So, you need to make sure that your security template has entries denying Web users Read access to sensitive files and directories. In addition, you might want to deny Web users Write access to directories in the Web root.
Several IIS vulnerabilities have let intruders gain system access to a Web server's file system. To mitigate the effects of these attacks, you can deny SYSTEM users Write access to files and directories within the Web root. Going one step further, you can also prevent SYSTEM users from executing sensitive programs, such as telnet.exe or tftp.exe.
Controlling Component Access
The Microsoft Scripting Runtime Library's FileSystemObject object has long had a bad reputation, so administrators often unregister the Scripting Runtime Library on production Web servers. However, some applications require the FileSystemObject object. In addition, disabling the Scripting Runtime Library means that you can't use the Dictionary object, which some applications, including Microsoft Site Server, might require. Using security templates, you can keep the Dictionary object and still control access to the FileSystemObject object.
The FileSystemObject object is a COM component. When Win2K creates COM components, it gathers information from the registry. For the FileSystemObject object, this information is in the HKEY_CLASSES_ROOT\CLSID\\{0D43FE01-F093-11CF-8940-00A0C9054228\} subkey. This subkey contains information required to create the component. If this information is missing or inaccessible, Win2K can't create the component. By selectively choosing which users have Read access to this subkey, you can gain fine-grained control over the FileSystemObject object.
For example, suppose you have an intranet Web site and a public Web site, each of which has a different Anonymous user account. You can let the intranet user account access the FileSystemObject object but deny access to the public user account by selectively setting the specified registry subkey's permissions.
Another example of a potentially dangerous COM component is the WScript.Shell object. You can secure this object by setting the HKEY_CLASSES_ROOT \CLSID\\{72C24DD5-D70A-438B-8A42-98424B88AFB8\} subkey permissions so that only administrators can read the class identifier (CLSID) information. This security measure disables access to the component from the Anonymous user account in IIS but still lets an administrator use the object.
Conversely, your Web site might have a custom component that you don't want users outside the Web application to access. To block these users, you can change the component's CLSID information in the registry so that only the Anonymous user account has Read access to the component.
Controlling File Extensions
Some administrators recommend disabling scripting by unmapping the associations for file extensions such as .vbs and .js. Although this disablement might prevent some users from inadvertently running malicious Trojan horses, it makes the task of executing legitimate scripts cumbersome for administrators. Once again, security templates can help.
Like COM objects, file-extension mappings require a registry lookup. By limiting who has access to those extensions, you're effectively disabling the extensions for some users and keeping them intact for others. In the case of .vbs mappings, you can remove Read permissions on the HKEY_CLASSES_ROOT\.vbs subkey for all users except administrators. Keep in mind that this security measure doesn't completely disable VBScript. Instead, it removes the automatic association between the .vbs extension and Windows Script Host (WSH) for the regular users (i.e., users who aren't administrators), which prevents them from inadvertently running malicious Trojan horses or worms with .vbs extensions.
Hiding Your Tracks
One security measure that many administrators overlook is protecting the most recently used (MRU) lists on a system. This security measure might seem trivial, but these lists provide a wealth of information to intruders. MRU lists let intruders learn about the administrator's work patterns, discover important files, and assess the administrator's security awareness.
The registry is full of MRU lists for files opened, searches performed, and locations visited. Any of these lists might be a gold mine for an intruder. For example, suppose an intruder gains access to a Web server's file system through a new vulnerability. The Recent folder in the administrator's user profile might reveal important filenames and file locations. If an administrator recently edited a file, chances are good that the file is also of interest to the intruder. Checking out the recently edited file is certainly easier than rummaging through the entire file system.
Now suppose that same intruder comes back several days later. The intruder notices that the administrator has viewed many of the system's log files, which might make the intruder wonder whether the administrator suspects an intrusion. To see whether he has been detected, the intruder might check the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU subkey to see the commands recently executed from the Run window on the Start menu. Or the intruder might check the HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Explorer Bars\\{C4EE31F3-4768-11D2-BE5C-00A0C9A83DA1\} subkey to view recent searches in Windows Explorer.
If you want to truly protect the MRU lists in your file system, you need to do more than just deny Read access to them. Instead, you need to prevent the information from being written in the first place by clearing the MRU lists, then denying Write access to them. To deny Write access, you simply add DACL strings to your security template.
For registry entries, the process is similar. Search your registry for the strings recent and MRU to locate the various MRU lists. Clear each list, then create DACL strings in your security template to remove Write permissions to the registry subkeys.
Hiding Drives
Besides hiding your tracks, you can hide your drives. By selectively denying Read access in a registry subkey, you can hide drives from some users while keeping those same drives visible for other users. For example, in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDrives subkey, you can specify a bitmask to hide certain drive letters in Windows Explorer. If this registry subkey doesn't exist, no drives are hidden.
Suppose you want to hide a certain drive from regular users but not administrators. To implement this security measure, you first create the NoDrives subkey. Setting the bitmask so that a drive has the value of 0 makes the drive visible, whereas setting the bitmask so that a drive has the value of 1 hides the drive. However, if you set the bit value to 1, the drive is hidden from all users, including administrators. To fix that problem, you can create a DACL string that denies administrators Read permissions to that subkey but allows all other users full Read access. After you reboot the Web server, everything is set. When an administrator logs on to the Web server, Windows Explorer can't read the NoDrives subkey and therefore doesn't hide the drive. If a regular user logs on, Windows Explorer reads the subkey and consequently hides the drive. For more information about setting the bitmask to hide specific drives, see the article "Hide Drives in My Computer" (http://www.winguides.com/registry/display.php/148).
Windows XP has a similar registry setting in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoCDBurning subkey. You can use the NoCDBurning subkey to prevent users from using the built-in CD-ROM recording functions. By creating this subkey and setting it to a value of 1, you can prevent CD-ROM burning operations altogether. The absence of this subkey means CD-ROM burning is enabled. If you set the subkey to the value of 1 and deny administrators Read access to the subkey, the administrators will be able to burn CD-ROMs but the regular users won't.
Protecting Sensitive Files
One dilemma administrators face is what to do with sensitive system files, such as cmd.exe or tftp.exe. In the past, malicious worms such as Code Red and Nimda have exploited both of these files. However, removing the files isn't always the best solution. Administrators often need to use programs such as cmd.exe for legitimate systems administration purposes. Plus, if a missing file is inadvertently replaced, it might not have the proper security permissions. As an alternative, you might consider leaving the files but removing or limiting Execute access.
If you delete an executable because keeping it on your system is too risky, consider adding a DACL string in the security template in case the file is reinstalled inadvertently. That way, when the policy refreshes, the file will receive the proper permissions (or lack thereof). When securing sensitive executables, don't give permissions to the Administrators group. Instead, allow access to specific administrators who must use the appropriate commands.
Harden Your Web Server
Deleting files and creating registry settings are typically all-or-nothing solutions. If you want more control over your system's security settings, you can use security templates to selectively set permissions. If you explore your registry and file system and use some ingenuity, you'll find many security measures that you can take to harden your Web server. Best of all, by using security templates, you can be sure that your settings are constantly enforced and consistent across all servers.
