In January 26, 2000—nearly a month before the official release of Windows 2000—Microsoft released Security Bulletin MS00-006 (Patch Available for "Malformed Hit-Highlighting Argument" Vulnerability), which announced a Microsoft IIS vulnerability that could let an intruder view the source code of server-side documents, including Active Server Pages (ASP) scripts. This vulnerability is a risk because ASP code often contains sensitive information such as passwords or SQL statements that could be useful to intruders. Security experts advise that you set proper NTFS file permissions on your Web server hard disks. Since Win2K's release, Microsoft has released other similar advisories and has repeated the advice to set proper NTFS file permissions.
But which permissions should you set? Many administrators have had the experience of trying to tighten file permissions on a Web server only to discover that they've broken some feature of a Web application. Administrators are therefore wary of changing file permissions on servers that already function properly. But understanding how Web servers and their users interact with the file system will give you the knowledge and confidence to properly set permissions that greatly improve your Web server's security.
User Context
A typical Win2K system runs many processes at any given time. If you open Task Manager and select the Processes tab, you'll see a list of currently running processes. Open View, Select Columns, and you can select additional information about each process. Select the User Name check box and click OK to view a list similar to Figure 1, page 76, that shows which users own each process.
When a user launches a process, the process is launched in that user's context. If that process launches another process, the child process remains in the same user context as its parent. When a process accesses an NTFS volume, that file will always be accessed in that process's user context.
Some services, such as IIS, run under the System context but, for security reasons, will impersonate accounts with lesser privileges—called impersonation—by launching a new process under a different user context. As a result, the new process will make file requests under a different user context. Before you begin to lock down the system, you must first understand how each of these user roles comes into play.
The System Account
The System account, sometimes referred to as LocalSystem, is an internal account the OS uses primarily to launch Windows services. The System account doesn't show up in Local Users and Groups, and you can't remove it from the system. It's a member of the Administrators group, but you can't add it to any other groups. You can set NTFS permissions for the System account, but you can't assign it any user rights.
The System account is powerful. You can't deny the System account the right to change permissions. In other words, if you limit permissions for the System account, it can change those permissions back to the default settings. Microsoft designed this capability to ensure that the OS functions properly. On a default Win2K installation, the System account has full access to every file on an NTFS volume. If intruders can exploit a Windows service running under the System account, they can launch other processes or access files under the System context. Such access makes the System account an attractive target for intruders.
Microsoft recommends that you typically not remove the System account permissions from a file, but in some cases doing so will limit exposure to Win2K vulnerabilities that let intruders launch processes under the System context. One such vulnerability was the .Printer buffer overflow that Microsoft Security Bulletin MS01-023 (Unchecked Buffer in ISAPI Extension Could Enable Compromise of IIS 5.0 Server) mentions. Therefore, limiting which files the System account can access can sometimes be important.
The Administrator
The built-in Administrator account is another privileged account that you must guard closely. Because you don't want to put too many file restrictions on this account, avoid running services as Administrator and limit access to Web browsing and email when logged on with this account. The Administrator account is a member of the built-in Everyone, Administrators, Authenticated Users, and Users groups. And when you log on to the Administrator account from the console, the account is also a member of the built-in Interactive group.
Previous
Register
