IWAM and IUSR Accounts
The IWAM and IUSR accounts are special-purpose accounts that handle requests from anonymous Web users. The IUSR account handles anonymous requests for Web resources; therefore, the NTFS permissions determine who can access what. For example, if you deny the IUSR account read access to index.html, anonymous Web users won't be able to access that file. Any COM components or processes that ASP code shells will also run under this user context. The IWAM account hosts Web instances that use medium or high application protection. It also runs out-of-process applications such as COM+ applications.
The IWAM and IUSR accounts are low-privilege accounts. Although they're supposed to be Guest accounts, they're also members of the built-in Users and Authenticated Users groups. The IIS Lockdown tool creates a Web Anonymous Users group that contains the IWAM and IUSR accounts, so when you set file permissions, use this group rather than the specific user accounts. Following this procedure makes it much easier to specifically block anonymous Web users from accessing certain files. Because this practice is highly recommended, this article will refer to the Web Anonymous Users group rather that the individual IWAM and IUSR accounts.
Other Accounts
Depending on your system configuration, you probably have other user accounts and roles. For example, you might have multiple Web site authors and administrators. You might also have users who log on to your Web site but who should otherwise have limited access to the system. Furthermore, some applications might install additional service accounts. Understanding the role particular users play and determining exactly which files they need to access are therefore important considerations.
Protecting the Webroot
Files in the webroot directory can be the most sensitive files on a Web server. These files are exposed to the public and often contain sensitive code that intruders can use to gather information and possibly compromise the Web server. For example, your server-side code might contain database-connection information, including passwords, that an intruder could use to compromise your server. Your code might also contain references to files and directories that an intruder might find useful. If someone gains access to this source code through a file-viewing vulnerability, your server is at great risk.
You can use the Internet Services Manager (ISM) to set read, write, and directory-browsing permissions for Web applications, but those permissions aren't the same as NTFS permissions. The Web application permissions control how IIS handles Web user requests; NTFS permissions provide a higher level of control and regulate what IIS can access. If ISM discovers a vulnerability that causes IIS to reveal server-side code, the NTFS permissions will take precedence and block access to the file. Although this article discusses NTFS permissions, you should also carefully select the permissions assigned in the ISM.
To secure the Web root, first remove the inherited permissions. Right-click the webroot directory, select properties, then select the Security tab. Clear the Allow inheritable permissions from parent to propagate to this object option. When the system prompts you for instructions for handling the existing permissions, click Remove. This important step ensures that the Web directories don't inadvertently inherit unwanted permissions from parent directories.
Next, limit the Web Anonymous Users group's permissions; don't let this group Write to any Web directories. For the most part, you don't want Web Anonymous Users to write to the file system. If you have an application that requires Write permissions, add that permission to only those directories that require it. This rule is also true for Execute permissions; remove execute permissions from all Web directories unless absolutely necessary for a Web application. If you have directories that contain DLL or executable files, the applications will run correctly only if anonymous users have Execute permissions. Script files, such as ASP code, don't need NTFS Execute permissions.
Most people advise that you put writable and executable files in their own directories, separated from other types of content. For example, you should place all executable files in a directory named \CGI or \BIN. You can give the directory Execute permissions, but when a directory has Execute permissions, any programs that you add to that directory will also be executable. So, instead of giving the directory Execute permissions, consider giving Execute permissions to only the particular files your Web application needs. That way, any new files you put into the directory won't automatically inherit Execute permissions.
Many Web-based attacks involve uploading some program to the Web that lets the attacker gain additional access to the system. For example, the CodeRed worm uploaded the file root.exe to the Scripts directory of a victim's Web site. By giving execute permissions on the file level alone, you prevent any new files from becoming executable just by being placed in the right directory. This technique alone could have greatly limited the effects of the CodeRed worm and its variants.
You should also restrict the System account's access to the Web directories. IIS has been vulnerable to several types of buffer overflow attacks that let intruders gain System-level access, and similar vulnerabilities will probably be exposed in the future. Limiting what the System account can do to the webroot will greatly reduce exposure to such attacks. Although the System account can change NTFS permissions set on any file, doing so requires a more complex approach, thus limiting exposure to only the more sophisticated attacks. Keep in mind, however, that if you're using the Indexing Service, the System account needs to be able to read the webroot to create an index.
Prev. page
1
[2]
3
4
next page 
