Step 6. Files and Directories

Install Windows 2000 on partitions formatted with the NTFS file system so that you benefit from NTFS permissions to restrict access. Use strong access controls to protect sensitive files and directories. In most situations, an approach that allows access to specific accounts is more effective than one that denies access to specific accounts. Set access at the directory level whenever possible. As files are added to the folder they inherit permissions from the folder, so you need to take no further action.

During this step, you:

• Restrict the Everyone group .

• Restrict the anonymous Web account(s) .

• Secure or remove tools, utilities, and SDKs .

• Remove sample files .

Restrict the Everyone Group

The default NTFS permissions for Windows 2000 grant members of the Everyone group full control access to a number of key locations, including the root directory, \inetpub, and \inetpub\scripts.

First grant FULL CONTROL to the Administrator account to the root (\), then remove access rights for the Everyone group from the following directories.

• Root (\)

• System directory (\WINNT\system32)

• Framework tools directory (\WINNT\Microsoft.NET\Framework\{version})

• Web site root directory and all content directories (the default is \inetpub\*)

Restrict Access to the IIS Anonymous Account

The anonymous account is well known. Attackers target this well known account to perform malicious actions. To secure the anonymous account:

• Deny write access to Web content directories .

  Make sure that it is not possible for this account to write to content directories, for example, to deface Web sites.

• Restrict access to System tools .

  In particular, restrict access to command-line tools located in \WINNT\System32.

• Assign permissions to groups instead of individual accounts .

  Assigning users to groups and applying permissions to groups instead of individual accounts is good practice. For the anonymous account, create a group and add the anonymous account to it and then explicitly deny access to the group for key directories and files. Assigning permissions to a group allows you to more easily change the anonymous account or create additional anonymous accounts because you do not need to recreate the permissions.

  Note  

  IISLockdown denies write access to content directories for the anonymous account by applying a deny write access control entry (ACE) for the Web Anonymous Users and Web Applications groups. It also adds a deny execute ACL on command-line tools.

• Use separate accounts for separate applications .

  If your Web server hosts multiple applications, use a separate anonymous account for each application. Add the accounts to an anonymous Web users group, for example, the Web Anonymous Users group created by IISLockdown, and then configure NTFS permissions using this group.

  For more information about using multiple anonymous accounts and hosting multiple applications, see Chapter 20, "Hosting Multiple ASP.NET Applications."

Secure or Remove Tools, Utilities and SDKs

SDKs and resource kits should not be installed on a production Web server. Remove them if they are present.

• Ensure that only the .NET Framework Redistributable package is installed on the server and no SDK utilities are installed. Do not install Visual Studio .NET on production servers.

• Ensure that access to powerful system tools and utilities, such as those contained in the \Program Files directory, is restricted. IISLockdown does this for you.

• Debugging tools should not be available on the Web server. If production debugging is necessary, then you should create a CD that contains the necessary debugging tools.

Remove Sample Files

Sample applications are typically not configured with high degrees of security. It is possible that an attacker could exploit an inherent weakness in a sample application or in its configuration to attack your Web site. Remove sample applications to reduce the areas where your Web server can be attacked .

Additional Considerations

Also consider removing unnecessary Data Source Names (DSNs). These contain clear text connection details used by applications to connect to OLE DB data sources. Only those DSNs required by Web applications should be installed on the Web server.