Chapter 5 - Managing Web Server Security

In this chapter, you learn how to manage World Wide Web server security. Web servers have different security considerations from those of standard Microsoft Windows servers. On a Web server, you have two levels of security:

• Windows security At the operating system level, you create user accounts, configure access permissions for files and directories, and set policies.

• IIS security At the level of Internet Information Services (IIS), you set content permissions, authentication controls, and operator privileges.

Windows security and IIS security can be completely integrated. The integrated security model allows you to use authentication based on user and group membership as well as standard Internet-based authentication. It also allows you to use a layered permission model to determine access rights and permissions for content. Before users can access files and directories, you must ensure that the appropriate users and groups have access at the operating system level. Then you must set IIS security permissions that grant permissions for content that IIS controls.

You will use the security discussion in this chapter as a stepping stone to later discussions that cover security for other IIS resources, including File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), and Network News Transfer Protocol (NNTP). Later discussions focus on what's different rather than rehashing what's already been discussed in this chapter.

On This Page

Managing Windows Security Managing IIS Security More Tips for Enhancing Web Server Security

Managing Windows Security

Before setting IIS security permissions, you use operating system security settings to do the following tasks:

• Create and manage accounts for users and groups

• Configure access permissions for files and folders

• Set group policies for users and groups

Each of these topics is discussed in the sections that follow.

Working with User and Group Accounts

Microsoft Windows 2000 provides user accounts and group accounts. User accounts determine permissions and privileges for individuals. Group accounts determine permissions and privileges for multiple users.

IIS User and Group Essentials

User and group accounts can be set at the local computer level or the domain level. Local accounts are specific to an individual computer and are not valid on other machines or in a domain unless you specifically grant permissions. Domain accounts, on the other hand, are valid throughout a domain, which makes resources in the domain available to the account. Typically, you'll use specific accounts for specific purposes:

• Use local accounts when your IIS servers aren't part of a domain or you want to limit access to a specific computer.

• Use domain accounts when the servers are part of a Windows domain and you want users to be able to access resources throughout that domain.

User accounts that are important on IIS servers include:

• Local System By default, all IIS and Indexing Service users log on using the local system account. This allows the services to interact with the operating system.

• IUSR_ComputerName Internet guest account used by anonymous users to access Internet sites. If this account is disabled or locked out, anonymous users will not be able to access Internet services.

• IWAM_ComputerName Web application account used to run out-of-process applications. If this account is disabled or locked out, out-of-process applications will not be able to start.

The Internet Guest and Web application accounts are members of the Guests group and have a password that never expires and cannot be changed by users. You can make changes to these accounts if necessary. For added security, you can configure IIS to use different accounts from the standard accounts provided. You can also create additional accounts

Managing the IIS and Indexing Service Logon Accounts

IIS and Indexing Service use the local system account to log on to the server. Using the local system account allows the services to run system processes and perform system-level tasks. You really shouldn't change this configuration unless you have very specific needs or want to have strict control over the privileges and rights of the IIS logon account. If you decide not to use this account, you can reconfigure the logon account for IIS and Indexing Service by completing the following steps:

1. Start the Computer Management console. Select Start, then Programs, then Administrative Tools, and finally Computer Management.

2. In the Computer Management console, connect to the computer whose services you want to manage.

3. Expand the Services And Applications node by clicking the plus sign (+) next to it, and then select Services.

4. Right-click the service you want to configure and then choose Properties.

5. Select the Log On tab, as shown in Figure 5-1.

   

   Figure 5-1: Use the Log On tab to configure the service logon account.

6. Select Local System Account if the service should log on using the system account (the default for most services).

7. Select This Account if the service should log on using a specific user account. Be sure to type an account name and password in the fields provided. Use the Browse button to search for a user account if necessary.

8. Click OK.

Note: If you don't use the local system account, you'll need to assign privileges and logon rights to the account you use. For more information on these and other account permissions, see Chapter 3, "Monitoring Processes, Services, and Events," in the Microsoft Windows 2000 Administrator's Pocket Consultant.

Managing the Internet Guest Account

You manage the Internet Guest account at the IIS security level and at the Windows security level. At the IIS security level you will do the following:

• Specify the user account to use for anonymous access. Normally, anonymous access is managed at the site level, and all files and directories within the site inherit the settings you use. You can change this behavior for individual files and directories as necessary.

• Specify how the password for the anonymous user account is managed. Either you manage the password or IIS manages the password. You should only synchronize passwords for anonymous user accounts that are defined locally. If the account is defined on another computer, you should manually control the password.

To change the configuration of the anonymous user account for all Web sites and directories on a Web server, complete the following steps:

1. In the Internet Information Services snap-in, right-click the icon for the computer you want to work with, and then select Properties. This displays a Properties dialog box.

2. Select WWW Service on the Master Properties selection list, and then click Edit. This opens the WWW Service Master Properties dialog box for the computer.

3. Click the Directory Security tab or File Security tab as appropriate, and then click Edit on the Anonymous Access And Authentication Control panel.

   Note: When Anonymous Access is enabled, users don't have to log on using a username and password. IIS automatically logs the user on using the anonymous account information provided for the resource. If the Anonymous Access check box is not selected, the resource is configured for named account access only. You can enable anonymous access by selecting this check box. However, you should only do this if you are sure the resource does not need to be protected.

4. The Username field specifies the account used for anonymous access to the resource. If you desire, type the account name you want to use instead of the existing account, or click Browse to display the Select User dialog box.

5. Allow IIS To Control Password determines whether IIS controls the password for the anonymous access account or you do. In most cases, you'll want IIS to control the account if it is defined on the local system. If this is the case, select this check box. Otherwise, clear this check box and type in the password for the anonymous access account.

6. Click OK twice and then click OK again to save your changes.

To change the configuration of the anonymous user account at the site, directory, or file level, complete the following steps:

1. In the Internet Information Services snap-in, right-click the Web site, directory, or file you want to work with, and then choose Properties.

2. Follow steps 3 to 6 in the previous listing.

At the Windows security level you perform all other account management tasks, including:

• Enabling or disabling accounts

• Unlocking the account after it has been locked out

• Changing group membership

For details on working with user and group accounts, see Chapter 7, "Understanding User and Group Accounts," Chapter 8, "Creating User and Group Accounts," and Chapter 9, "Managing Existing User and Group Accounts," in the Microsoft Windows 2000 Administrator's Pocket Consultant.

Managing the Web Application Account

You manage the Web application account at the IIS security and Windows security levels only. At the IIS security level, you use the Component Services snap-in to specify the account used by out-of-process applications (both pooled and isolated). Pooled applications all use the same account. Isolated applications each can use a different account.

You access the Component Services snap-in by completing the following steps:

1. Open the Run dialog box by clicking Start and then clicking Run.

2. Type MMC in the Open field and then click OK. This opens the Microsoft Management Console (MMC).

3. In MMC, click Console and then click Add/Remove Snap-In. This opens the Add/Remove Snap-In dialog box.

4. On the Standalone tab, click Add.

5. In the Add Standalone Snap-In dialog box, click Component Services, and then click Add.

6. Close the Add Standalone Snap-In dialog box by clicking Close, and then click OK.

Once you've started the Component Services snap-in, you can manage the account for pooled applications by completing the following steps:

1. Expand the Component Services node by clicking the plus sign (+) next to it. You should now see the Computers node.

2. If you're connecting to a remote computer, right-click Computers, point to New, and then select Computer. Type the name of the computer you want to manage and then click OK. If you don't know the computer name, click Browse, and then use the Select Computer dialog box to select a computer.

3. Expand the node for the computer and then expand the COM+ Applications node.

4. Right-click IIS Out-Of-Process Pooled Applications, select Properties, and then click the Identity tab.

5. As shown in Figure 5-2, select This User and then, in the User field, type the account name you want to use instead of the existing account, or click Browse to display the Select User dialog box.

6. In the Password and Confirm Password fields, type the password for the account.

7. Click OK.

Figure 5-2: Set the Web application account identity in the Component Services snap-in.

You manage the account identity for isolated applications using a similar technique. The only difference is that instead of right-clicking IIS Out-Of-Process

Pooled Applications, you right-click the entry for the isolated application. Each isolated application is listed by metabase path with the prefix IIS-. For example, if you created an isolated application on the Default Web Site and it was located at /Apps/Data, the associated entry would be named IIS-{Default Web Site//Root/Apps/Data}.

At the Windows security level you perform all other account management tasks for the Web application account. These tasks include the following:

• Enabling or disabling the account

• Unlocking the account after it has been locked out

• Changing group membership

For details on working with user and group accounts, see Chapter 7, "Understanding User and Group Accounts," Chapter 8, "Creating User and Group Accounts," and Chapter 9, "Managing Existing User and Group Accounts," in the Microsoft Windows 2000 Administrator's Pocket Consultant.

Working with File and Folder Permissions

Every folder and file used by IIS can have different access permissions. These access permissions are set at the Windows security level. The sections that follow provide an overview of permissions. You'll learn the basics, including how to view permissions and how to set permissions.

File and Folder Permission Essentials

The basic permissions you can assign to files and folders are summarized in Table 5-1. The basic permissions are created by combining special permissions, such as traverse folder and execute file, into a single easily managed permission. If you want granular control over file or folder access, you can use advanced permissions to assign special permissions individually. For more information on special permissions, see Chapter 13, "Data Sharing, Security, and Auditing," in the Microsoft Windows 2000 Administrator's Pocket Consultant.

Table 5-1 File and Folder Permissions Used by Windows 2000

Permission	Meaning for Folders	Meaning for Files
Read	Permits viewing and listing files and subfolders	Permits viewing or accessing the file's contents
Write	Permits adding files and subfolders	Permits writing to a file
Read & Execute	Permits viewing and listing files and subfolders as well as executing files; inherited by files and folders	Permits viewing and accessing the file's contents as well as executing the file
List Folder Contents	Permits viewing and listing files and subfolders as well as executing files; inherited by folders only	N/A
Modify	Permits reading and writing of files and subfolders; allows deletion of the folder	Permits reading and writing of the file; allows deletion of the file
Full Control	Permits reading, writing, changing, and deleting files and subfolders	Permits reading, writing, changing, and deleting the file

Anytime you work with file and folder permissions, you should keep the following in mind:

• Read is the only permission needed to run scripts. Execute permission only applies to executables.

• Read access is required to access a shortcut and its target.

• Giving a user permission to write to a file but not to delete it doesn't prevent the user from deleting the file's contents. A user can still delete the contents.

• If a user has full control over a folder, the user can delete files in the folder regardless of the permission on the files.

The following users and groups are used by IIS to configure file and folder access:

• Administrators This allows administrators to access IIS resources.

• Creator Owner This allows the account that created a resource to access the resource.

• System This allows the local system to access the resource.

• Everyone This allows interactive, dial-up, network, and authenticated users to access the content. IIS uses this group when the Web server is part of a Windows domain.

• Users This allows named accounts to access the resource (including the Internet Guest and Web Application accounts, which are user accounts). IIS uses this group when the Web server is part of a workgroup.

When you grant Read permission to these users and groups, anyone who has access to your Internet or intranet Web site will be able to access the files and folders. If you want to restrict access to certain files and folders, you should set specific user and group permissions and then use authenticated access rather than anonymous access. With authenticated access, IIS authenticates the user before granting access and then uses the Windows permissions to determine what files and folders the user can access.

As you evaluate the permissions you may want to use for files and folders used by IIS, you should refer to Table 5-2. This table provides general guidelines for assigning permissions based on content type.

Table 5-2 General Guidelines for Permissions Based on Content Type

File Type	File Extension	Permission
Common Gateway Interface (CGI) scripts and executables	.exe, .DLL, .cmd	Everyone (Execute) Administrators (Full Control) System (Full Control)
Dynamic content	.asp, .vbs, .js, .pl	Everyone (Read Only) Administrators (Full Control) System (Full Control)
Include files	.inc, .shtm, .shtml, .stm	Everyone (Read Only) Administrators (Full Control) System (Full Control)
Static content	.txt, .rtf, .gif, .jpg, .jpeg, .htm, .html, .doc, .ppt, .xls	Everyone (Read Only) Administrators (Full Control) System (Full Control)

Instead of setting permissions on individual files, you should organize content by type in subdirectories. For example, if your Web site used static, script, and dynamic content, you could create subdirectories called WebStatic, WebScripts, and WebDynamic. You would then store static, script, and dynamic content in these directories and assign permissions on a per-directory basis.

Viewing File and Folder Permissions

You view security permissions for files and folders by completing the following steps:

1. In Microsoft Windows Explorer, right-click the file or folder you want to work with.

2. From the pop-up menu, select Properties, and then, in the Properties dialog box, click the Security tab.

3. In the Name list box, select the user, contact, computer, or group whose permissions you want to view. If the permissions are dimmed, it means the permissions are inherited from a parent object.

Setting File and Folder Permissions

You can set permissions for files and folders by completing the following steps:

1. In Windows Explorer, right-click the file or folder you want to work with.

2. From the pop-up menu, select Properties, and then, in the Properties dialog box, click the Security tab, shown in Figure 5-3.

   

   Figure 5-3: Use the Security tab to configure basic permissions for the file or folder.

   Users or groups that already have access to the file or folder are listed in the Name list box. You can change permissions for these users and groups by doing the following:

   • Select the user or group you want to change.

   • Use the Permissions list box to grant or deny access permissions.

   Note: Inherited permissions are shaded. If you want to override an inherited permission, select the opposite permission.

3. Click Add to set access permissions for additional users, contacts, computers, or groups. This displays the Select Users, Computers, Or Groups dialog box shown in Figure 5-4.

   Use the Select Users, Computers, Or Groups dialog box to select the users, computers, or groups for which you want to set access permissions. You can use the fields of this dialog box as follows:

   • Look In This drop-down list box allows you to access account names from other domains. Click Look In to see a list of the current domain, trusted domains, and other resources that you can access. Select Entire Directory to view all the account names in the folder.

   • Name This column shows the available accounts of the currently selected domain or resource.

   • Add This button adds selected names to the selection list.

   • Check Names This button validates the user, and group names entered in the selection list. This is useful if you type names in manually and want to make sure they're available.

   

   Figure 5-4: Select users, computers, and groups that should be granted or denied access.

4. In the Name list box, select the user, computer, or group you want to configure, and then use the fields in the Permissions area to allow or deny permissions. Repeat for other users, computers, or groups.

5. Click OK when you're finished.

Working with Group Policies

Group policies are another aspect of Windows security that you need to understand. You'll use group policies to automate key security administration tasks and to more effectively manage IIS resources.

Group Policy Essentials

Group policies provide central control over privileges, permissions, and capabilities of users and computers. You can think of a policy as a set of rules that can be applied to multiple computers and to multiple users. Because computers can be a part of larger organizational groups, multiple policies can be applied. The order in which policies are applied is extremely important in determining which rules are enforced and which rules are not.

When multiple policies are in place, the policies are applied in the following order:

1. Microsoft Windows NT 4.0 policies from NTCONFIG.POL files

2. Local group policies that affect the local computer only

3. Site group policies that affect all computers that are part of the same site, which can include multiple domains

4. Domain polices that affect all computers in a specific domain

5. Organizational unit policies that affect all computers in an organizational unit

6. Child organizational unit policies that affect all computers in a subcomponent of an organizational unit

As successive policies are applied, the rules in those policies override the rules set in the previous policy. For example, domain policy settings have precedence over the local group policy settings. Exceptions allow you to block, override, and disable policy settings; a discussion of exceptions is outside the scope of this book.

Policy settings are divided into two broad categories: those that affect computers and those that affect users. Computer policies are applied during system startup. User policies are applied during logon. You configure policies with the Group Policy snap-in. To access this snap-in to manage policies for sites, domains, and organizational units, follow these steps:

1. For sites, start the Group Policy snap-in from the Active Directory Sites And Services console. Open the Active Directory Sites And Services console.

2. For domains and organizational units, start the Group Policy snap-in from the Active Directory Users And Computers console. Open the Active Directory Users And Computers console.

3. In the console root, right-click the site, domain, or unit in which you want to create or manage a group policy. Then, from the shortcut menu, select Properties. This opens a Properties dialog box.

4. In the Properties dialog box, select the Group Policy tab. As Figure 5-5 shows, existing policies are listed in the Group Policy Object Links list.

5. To create a new policy or edit an existing policy, click New. You can now configure the policy.

6. To edit an existing policy, select the policy, and then click Edit. You can now edit the policy.

7. To change the priority of a policy, use the Up or Down buttons to change its position in the Group Policy Object Links list.

   

   Figure 5-5: Use the Group Policy tab to create and edit policies.

You manage local group policies for an individual computer by completing the following steps:

1. Open the Run dialog box by clicking Start and then clicking Run.

2. Type MMC in the Open field and then click OK. This opens the Microsoft Management Console (MMC).

3. In MMC, click Console, and then click Add/Remove Snap-In. This opens the Add/Remove Snap-In dialog box.

4. On the Standalone tab, click Add.

5. In the Add Snap-In dialog box, click Group Policy, and then click Add. This opens the Select Group Policy Object dialog box.

6. Click Local Computer to edit the local policy on your computer or browse to find the local policy on another computer.

7. Click Finish, and then click Close.

8. Click OK. You can now manage the local policy on the selected computer.

Group policies for passwords, account lockout, and auditing are essential to the security of your Web server. Guidelines for password policies are as follows:

• Set a minimum password age for all accounts. I recommend 2-3 days.

• Set a maximum password age for all accounts. I recommend 30 days.

• Set a minimum password length. I suggest the minimum be set at 8 characters to start.

• Enable secure passwords by enforcing password complexity requirements.

• Enforce password history. Use a value of 5 or more.

Guidelines for account lockout polices include the following:

• Set an account lockout threshold. In most cases, accounts should be locked after five bad attempts.

• Set account lockout duration. In most cases, you'll want to lock out accounts indefinitely.

• Reset the lockout threshold after 30 to 60 minutes.

Guidelines for auditing include the following:

• Audit system event success and failure

• Audit logon event success and failure

• Audit failed object access attempts

• Audit successful and failed policy changes

• Audit successful and failed account management

• Audit successful and failed account logon

Techniques for managing these policies are examined in the sections that follow. For more detailed information on policy management, see Chapter 4, "Automating Administrative Tasks, Policies, and Procedures," in Microsoft Windows 2000 Administrator's Pocket Consultant.

Setting Account Policies for IIS Servers

You can set account policies by completing the following steps:

1. Access the group policy container you want to work with. Expand Computer Configuration, then Windows Settings, then Security Settings, and then Account Policies.

2. As shown in Figure 5-6, you can now manage account policies through the Password Policy, Account Lockout Policy, and Kerberos Policy nodes.

3. To configure a policy, double-click its entry, or right-click on it and select Security. This opens a Properties dialog box for the policy.

   

   Figure 5-6: Set policies for passwords and general account use.

4. For a local policy, the Properties dialog box is similar to the one shown in Figure 5-7. The effective policy for the computer is displayed but you can't change it. You can change the local policy settings, however. Use the fields provided to configure the local policy. Skip the remaining steps; those steps apply to global group policies.

   

   Figure 5-7: With local policies, you'll see the effective policy as well as the local policy.

5. For a site, domain, or organizational unit, the Properties dialog box is similar to the one shown in Figure 5-8.

6. All policies are either defined or not defined—that is, they are either configured for use or not configured for use. A policy that isn't defined in the current container could be inherited from another container.

7. Select or clear the Define This Policy Setting check box to determine whether a policy is defined.

   Policies can have additional fields for configuring the policy. Often, these fields are option buttons labeled Enabled and Disabled.

   • Enabled turns on the policy restriction.

   • Disabled turns off the policy restriction.

   

   Figure 5-8: Define and configure global group policies using the Properties dialog box.

Setting Auditing Policies

Auditing is the best way to track what's happening on your IIS server. You can use auditing to collect information related to resource usage, such as file access, system logon, and system configuration changes. Anytime an action occurs that you've configured for auditing, the action is written to the system's security log, where it's stored for your review. The security log is accessible from Event Viewer.

You can set auditing policies by completing the following steps:

1. Access the group policy container you want to work with. Expand Computer Configuration, Windows Settings, Security Settings, and Local Policies. Then select Audit Policy, as shown in Figure 5-9.

   You can now have access to the following auditing options:

   • Audit Account Logon Events Tracks events related to user logon and logoff.

     

     Figure 5-9: Set auditing policies using the Audit Policy node in Group Policy.

   • Audit Account Management Tracks account management. Events are generated anytime user, computer, or group accounts are created, modified, or deleted.

   • Audit Directory Service Access Tracks access to the Active Directory. Events are generated anytime users or computers access the directory.

   • Audit Logon Events Tracks events related to user logon, logoff, and remote connections to network systems.

   • Audit Object Access Tracks system resource usage for files, directories, shares, printers, and Active Directory objects.

   • Audit Policy Change Tracks changes to user rights, auditing, and trust relationships.

   • Audit Privilege Use Tracks the use of user rights and privileges, such as the right to back up files and directories, but doesn't track system logon or logoff.

   • Audit Process Tracking Tracks system processes and the resources they use.

   • Audit System Events Tracks system startup, shutdown, and restart, as well as actions that affect system security or the security log.

2. To configure an auditing policy, double-click its entry, or right-click and select Security. This opens a Properties dialog box for the policy.

3. Select Define These Policy Settings, and then select either the Success check box or the Failure check box, or both. Success logs successful events, such as successful logon attempts. Failure logs failed events, such as failed logon attempts.

4. Click OK when you're finished.

Managing IIS Security

After setting operating system security, use IIS security to

• Set the Web server and execute permissions for content

• Configure distributed authoring and versioning

• Configure authentication methods

• Control access by IP address or Internet domain name

• Manage Web site operator privileges

Each of these topics is discussed in the sections that follow.

Setting Web Server Permissions

Sites, directories, and files have permissions in IIS in addition to the Windows security settings. These permissions are set the same for all users. This means you cannot set different permissions for different users at the Web content level. You can, however, create secure areas of your Web site and then use Windows file and folder permissions to provide the necessary additional controls.

Understanding Web Server Permissions

The permissions you assign to Web content are applied in combination with the authentication methods and access restrictions currently being enforced for the resource. This means user requests must meet the requirements for Web content permissions, authentication, and access before they are executed. Keep in mind that all directories and files within the site inherit permissions set at the site level, and that you can override site-level permissions by setting permissions on individual directories and files.

Web server permissions also set the permissible actions for Web Distributed Authoring And Versioning (WebDAV). WebDAV publishing allows remote users to publish, lock, and manage resources on a Web server through a Hypertext Transfer Protocol (HTTP) connection. Windows 2000, Microsoft Office 2000, and Internet Explorer 5.0 or later are all WebDAV-enabled. If you have WebDAV-enabled applications, use Web server permissions to determine permitted actions for these applications and their users. You'll find more detailed information on WebDAV in the "Configuring Distributed Authoring and Versioning," section of this chapter.

You can set Web server permissions in two different ways:

• Globally Global permissions are configured using the WWW Server Master Properties dialog box. When you set Web server permissions in the master properties, you must also specify how these properties are inherited. When a site or directory has settings that conflict with permission changes you've made, you are given the opportunity to override the site or directory permissions with the global permissions. If you override permissions, the global permissions are applied to the site or directory and its contents. If you do not override permissions, the original settings for the site or directory are maintained.

• Locally Local permissions are configured at the site, directory, or file level. As with global permissions, local permissions for sites and directories can be inherited. Because of this, when you make permission changes that conflict with existing permissions on a subdirectory, you are given the opportunity to override the site or directory permissions with the local permissions. If you override permissions, the local permissions are applied to the site or directory and its contents. If you do not override permissions, the original settings for the site or directory are maintained.

IIS manages inheritance of permissions changes at the node level. Because of this, the top-level directory for a site and the individual directories within a site are seen as separate nodes. If you apply changes to a site node, the permissions are applied to the site's root folder and to files in this folder. Changes are not applied to subdirectories within the site unless you specify that they should be.

Setting Web Server Permissions Globally

To manage Web server permissions globally, complete the following steps:

1. In the Internet Information Services snap-in, right-click the icon for the computer you want to work with, and then select Properties. This displays a Properties dialog box.

2. Select WWW Service on the Master Properties selection list and then click Edit. This opens the WWW Service Master Properties dialog box for the computer.

   As shown in Figure 5-10, click the Home Directory tab, and then use the following fields to set the Web server permissions that you want sites and directories on this computer to inherit:

   • Directory Browsing Allows users to view a list of files and subdirectories within the designated directory.

   • Index This Resource Allows the Indexing Service to index the resource. Indexing allows users to perform keyword searches for information contained in the resource.

   • Log Visits Used with server logging to log requests related for resource files.

   • Read Allows users to view the resource. For a directory, this grants the user access to the directory. For a file, this means the user can read the file and display it.

   • Script Source Access Allows users to access source code, including scripts in ASPs. If Read permission is also selected, users will be able to read the source file. If Write permission is also selected, users will be able to write to the source file.

     

     Figure 5-10: Use the Properties dialog box to configure Web server permissions.

     Caution: Be careful when granting Script Source Access on production servers that are on the public Internet. With this permission, anyone will be able to read the contents of your scripts, and this may open your servers to mischievous users. Because of this, you should only enable this feature in a directory that requires users to authenticate themselves before being granted access.

   • Write Allows users to change the resource. For a directory, this allows the user to create or publish files. For a file, this allows the user to change the content.

     Caution: Write permission should be granted only to a limited number of resources. If possible, you should create separate subdirectories that contain only writeable files, or you should write-enable individual files rather than entire directories. To execute application files, you must assign Read permission to all files used by the application or to the site or directory used to store these files. If the application posts content to a file on the site, you must also assign Write permission (but you should limit this to a specific file or directory).

   If the selected resource is part of an IIS application, you may also want to set the level of program execution that is allowed for the application. To do this, use the Execute Permissions selection list to choose one of the following options:

   • None Only static files, such as .html or .gif files, can be accessed.

   • Scripts Only Only scripts, such as ASP scripts, can be run.

   • Scripts And Executables All file types can be accessed and executed.

3. Click Apply. Before applying permission changes, IIS checks the existing permissions in use for all Web sites and directories within Web sites. Each time a site or directory node uses a different value for a permission, an Inheritance Overrides dialog box is displayed. Use this dialog box to select the site and directory nodes, which should use the new permission value, and then click OK.

Setting Web Server Permissions Locally

To set content permissions for a site, directory, or file, complete the following steps:

1. In the Internet Information Services snap-in, right-click the site, directory, or file that you want to work with, and select Properties.

   Click the Home Directory, Directory, or Virtual Directory tab as appropriate. This displays the dialog box shown in Figure 5-11. Then use the following fields to set the permissions for the selected resource:

   • Directory Browsing Allows users to view a list of files and subdirectories within the designated directory.

     

     Figure 5-11: Use the Properties dialog box to configure Web server permissions.

   • Index This Resource Allows the Indexing Service to index the resource. Indexing allows users to perform keyword searches for information contained in the resource.

   • Log Visits Used with server logging to log requests related for resource files.

   • Read Allows users to view the resource. For a directory, this grants the user access to the directory. For a file, this means the user can read the file and display it.

   • Script Source Access Allows users to access source code, including scripts in ASP pages. If Read permission is also selected, users will be able to read the source file. If Write permission is also selected, users will be able to write to the source file.

     Caution: Be careful when granting Script Source Access on production servers that are on the public Internet. With this permission, anyone will be able to read the contents of your scripts, and this may open your servers to mischievous users. Because of this, you should only enable this feature in a directory that requires users to authenticate themselves before being granted access.

   • Write Allows users to change the resource. For a directory, this allows the user to create or publish files. For a file, this allows the user to change the content.

     Caution: Write permission should be granted to only a limited number of resources. If possible, you should create separate subdirectories that contain only writeable files, or you should write-enable individual files rather than entire directories. To execute application files, you must assign Read permission to all files used by the application or to the site or directory used to store these files. If the application posts content to a file on the site, you must also assign Write permission (but you should limit this to a specific file or directory).

   If the selected resource is part of an IIS application, you may also want to set the level of program execution that is allowed for the application. To do this, use the Execute Permissions selection list to choose one of the following options:

   • None Only static files, such as .html or .gif files, can be accessed.

   • Scripts Only Only scripts, such as ASP scripts, can be run.

   • Scripts And Executables All file types can be accessed and executed.

2. Click Apply. Before applying permission changes, IIS checks the existing permissions in use for all Web sites and directories within Web sites. Each time a site or directory node uses a different value for a permission, an Inheritance Overrides dialog box is displayed. Use this dialog box to select the site and directory nodes, which should use the new permission value, and then click OK.

Configuring Distributed Authoring and Versioning

WebDAV is an extension to the HTTP 1.1 protocol that allows remote users to manage Web server resources. Using WebDAV, clients can

• Perform standard file operations, such as cut, copy, and paste

• Create and edit files and their properties at the operating system level

• Create and edit directories and their properties at the operating system level

• Lock and unlock resources to allow only one person to modify a resource while allowing multiple users to read the resource

• Search the contents and properties of files in a directory

Because WebDAV is integrated into IIS, all Web site directories on your IIS server are accessible for distributed authoring and versioning. This makes it easy to access and publish documents to your IIS server.

Permitting Distributed Authoring and Versioning

You control the permitted actions for WebDAV application using the standard Web server permissions. The Web server permissions that are directly applicable to WebDAV are

• Directory Browsing Allows WebDAV clients to view the contents of directories.

• Index This Resource If your Web server is running the Indexing Service, WebDAV clients can search the directory using special search utilities.

• Read Allows WebDAV clients to view and run files and subdirectories within the WebDAV directory.

• Script Source Access Allows WebDAV clients to download source files for scripts.

• Write Allows WebDAV clients to create files or directories and to write to existing files.

To publish to a directory and see a list of files in that directory, users need Read, Write, and Browse access permissions. If users need to update script files, you must also grant Script Source Access permission. To protect your Web content, you should grant these permissions only in directories that require users to authenticate themselves. For example, you could create a directory called ForPublishing and then configure permissions on this directory so that anonymous access is not allowed, and then configure the necessary authoring and publishing permissions (Read, Write, and Browse).

When you allow script source access, you need to ensure that your source code and executables are protected. Any extension designated in the Application Mappings for the site is considered a script source file. Files with extensions that aren't mapped are treated as static .html or text files. Files with the .DLL and .exe extension are also treated as static files, unless the Scripts And Executables permission is set, which means they could be overwritten even if Script Source Access is not enabled. When the Scripts And Executables permission is set, .DLL and .exe files are not treated as static files—they are treated as executable files, and they can only be overwritten when Script Source Access is enabled.

Accessing and Publishing Documents with WebDAV

Windows 2000 and Office 2000 are both WebDAV-enabled, and you can connect to Web directories on IIS servers quite easily. In Windows 2000, you can connect to a Web directory on an IIS server by completing the following steps:

1. Double-click the My Network Places icon on your desktop, and then double-click Add Network Place. This starts the Add Network Place Wizard.

2. In the Add Network Place Wizard, type the URL of the WebDAV directory to which you want to connect, such as https://www.microsoft.com/data/.

3. Click Next, and then type a descriptive name for the directory.

4. When you complete the process by clicking Finish, Windows 2000 automatically accesses the directory. The next time you want to access the directory, double-click My Network Places on the desktop and then double-click the folder for the directory.

Once you've created a network place for the WebDAV directory, you can easily publish documents to it from Office 2000. Simply create a document in any Office 2000 application, then follow these steps:

1. Select Save As from the File menu and then, in the left column of the Save As dialog box, click My Network Places.

2. Select the shortcut for the WebDAV directory you want to use, or type the URL, and then click OK.

You can also connect to WebDAV directories through Internet Explorer 5.0 on the Microsoft Windows 95, Microsoft Windows 98, Windows NT 4.0, or Windows 2000 operating systems. Simply complete the following steps:

1. Start Internet Explorer 5.0 or later, and then display the Open dialog box by selecting Open from the File menu.

2. In the Open dialog box, type the URL for the WebDAV directory to which you want to connect, such as https://www.microsoft.com/data/.

3. Select the Open As Web Folder check box and then click OK.

Setting Authentication Modes

Authentication modes control access to IIS resources. You can use authentication to allow anonymous access to public resources, to create secure areas within a Web site, and to create controlled access Web sites. When authentication is enabled, IIS uses the account credentials supplied by a user to determine whether or not the user has access to a resource, and to determine which permissions the user has been granted.

Understanding Authentication

Four authentication modes are available. These modes are:

• Anonymous Authentication With anonymous authentication, IIS automatically logs users on with an anonymous or guest account. This allows users to access resources without being prompted for username and password information.

• Basic Authentication With basic authentication, users are prompted for logon information. When it's entered, this information is transmitted unencrypted across the network. If you've configured secure communications on the server as described in the "Working with SSL" section of Chapter 6, "Managing Microsoft Certificate Services and SSL," you can require clients to use Secure Sockets Layer (SSL). When you use SSL with basic authentication, the logon information is encrypted before transmission.

• Integrated Windows Authentication With integrated Windows authentication, IIS uses standard Windows security to validate the user's identity. Instead of prompting for a username and password, clients relay the logon credentials that users supply when they log on to Windows. These credentials are fully encrypted without the need for SSL, and they include the username and password needed to log on to the network. Only Internet Explorer browsers support this feature.

• Digest Authentication With digest authentication, user credentials are transmitted securely between clients and servers. Digest authentication is a feature of HTTP 1.1 and uses a technique that cannot be easily intercepted and decrypted. This feature is available only when the IIS server is a domain controller and the request was made by Internet Explorer 5.0 or later.

By default, both anonymous and integrated Windows authentication are enabled for IIS resources. Because of this, the default authentication process looks like this:

1. IIS attempts to access the resource using the Internet Guest account. If this has the appropriate access permissions, the user is allowed to access the resource.

2. If validation of the credentials fails or the account is disabled or locked, IIS attempts to use the user's current account credentials. If the credentials can be validated and the user has the appropriate access permissions, the user is allowed to access the resource.

3. If validation fails or the user doesn't have appropriate access permissions, the user is denied access to the resource.

As with Web server permissions, you can apply authentication on a global or local basis. Global authentication modes are configured using the master WWW properties. Local authentication modes are set using site, directory, or file properties. Anytime you make changes that conflict with existing settings IIS displays a dialog box that allows you to specify which resources inherit the new settings.

Before you start working with authentication modes, you should keep the following in mind:

• When you combine anonymous access with authenticated access, users have full access to resources that are accessible to the Internet Guest account. If this account does not have access to a resource, IIS attempts to authenticate the user using the authentication techniques you've specified. If these authentication methods fail, the user is denied access to the resource.

• When you disable anonymous access, you are telling IIS that all user requests must be authenticated using the authentication modes you've specified. Once the user is authenticated, IIS uses the user's account credentials to determine access rights.

• When you combine basic authentication with integrated or digest authentication, Internet Explorer will attempt to use integrated Windows authentication or digest authentication before using basic authentication. This means users who can be authenticated using their current account credentials won't be prompted for a username and password.

Additionally, before you can use digest authentication, you must enable reversible password encryption for each account that will connect to the server using this authentication technique. IIS and the user's Web browser use reversible encryption to manage secure transmission and unencryption of user information. To enable reversible encryption, follow these steps:

1. Start Active Directory Users And Computers. Click Start, point to Programs, point to Administrative Tools, and then select Active Directory Users And Computers.

2. Double-click the username that you want to use with Digest Authentication.

3. In Account Options, select Store Password Using Reversible Encryption.

4. Click OK. Repeat steps 1 to 4 for each account that you want to use digest authentication on.

Enabling and Disabling Authentication

You can enable or disable anonymous access to resources at the server, site, directory, or file level. If you enable anonymous access, users can access resources without having to authenticate themselves (provided the Windows permissions on the resource allow this). If you disable anonymous access, users must authenticate themselves before accessing resources. Authentication can occur automatically or manually depending on the browser used and the account credentials previously entered by the user.

You can enable or disable authentication at the server level by completing the following steps:

1. In the Internet Information Services snap-in, right-click the icon for the computer you want to work with, and then select Properties. This displays a Properties dialog box.

2. Select WWW Service on the Master Properties selection list and then click Edit. This opens the WWW Service Master Properties dialog box for the computer.

3. Select the Directory Security tab and then click Edit on the Anonymous Access And Authentication Control panel. This displays the Authentication Methods dialog box shown in Figure 5-12.

   

   Figure 5-12: Use the Authentication Methods dialog box to enable or disable authentication methods to meet the needs of your organization. With basic authentication, it's often helpful to set a default domain as well.

4. To enable anonymous access, select the Anonymous Access check box. To disable anonymous access, clear this check box.

5. Select or clear Basic Authentication to enable or disable this authentication method. If you disable basic authentication, keep in mind that this may prevent some clients from accessing resources remotely. Clients can log on only when you enable an authentication method that they support.

6. A default domain isn't set automatically. If you enable basic authentication, you can choose to set a default domain that should be used when no domain information is supplied during the logon process. Setting the default domain is useful when you want to ensure that clients authenticate properly.

7. Select or clear Digest Authentication to enable or disable this authentication method. If the computer you are working with isn't a domain controller, this option will not be available.

8. Select or clear Integrated Windows Authentication to enable or disable this authentication method.

9. Click OK. Before applying changes, IIS checks the existing authentication methods in use for all Web sites and directories within Web sites. If a site or directory node uses a different value, an Inheritance Overrides dialog box is displayed. Use this dialog box to select the site and directory nodes that should use the new setting, and then click OK.

You can enable or disable authentication at the site, directory, or file level by completing these steps:

1. In the Internet Information Services snap-in, right-click the site, directory, or file that you want to work with, and then select Properties. This displays a Properties dialog box.

2. Select the Directory Security tab and then click Edit on the Anonymous Access And Authentication Control panel. This displays the Authentication Methods dialog box shown previously in Figure 5-12.

3. To enable anonymous access, select the Anonymous Access check box. To disable anonymous access, clear this check box.

4. Select or clear Basic Authentication to enable or disable this authentication method. If you disable basic authentication, keep in mind that this may prevent some clients from accessing resources remotely. Clients can log on only when you enable an authentication method that they support.

5. A default domain isn't set automatically. If you enable basic authentication, you can choose to set a default domain that should be used when no domain information is supplied during the logon process. Setting the default domain is useful when you want to ensure that clients authenticate properly.

6. Select or clear Digest Authentication to enable or disable this authentication method. If the computer you are working with isn't a domain controller, this option will not be available.

7. Select or clear Integrated Windows Authentication to enable or disable this authentication method.

8. Click OK. Before applying changes, IIS checks the existing authentication methods in use for all child nodes of the selected resource (if any). If a child node uses a different value, an Inheritance Overrides dialog box is displayed. Use this dialog box to select the site and directory nodes that should use the new setting, and then click OK.

Configuring IP Address and Domain Name Restrictions

By default, IIS resources are accessible to all IP addresses, computers, and domains, which presents a security risk that may allow your server to be misused. To control use of resources, you may want to grant or deny access by IP address, network ID, or domain. As with other Web server settings, restrictions can be applied through the Master WWW server properties or through the properties for individual sites, directories, and files.

• Granting access allows a computer to make requests for resources but doesn't necessarily allow users to work with resources. If you require authentication, users still need to authenticate themselves.

• Denying access to resources prevents a computer from accessing those resources. Therefore, users of the computer can't access the resources—even if they could have authenticated themselves with a username and password.

You can establish or remove restrictions globally through the Master WWW server properties by completing the following steps:

1. In the Internet Information Services snap-in, right-click the icon for the computer you want to work with, and then select Properties. This displays a Properties dialog box.

2. Select WWW Service on the Master Properties selection list and then click Edit. This opens the WWW Service Master Properties dialog box for the computer.

3. Select the Directory Security tab and then click Edit on the IP Address And Domain Name Restrictions panel. This displays the IP Address And Domain Name Restrictions dialog box shown in Figure 5-13.

   

   Figure 5-13: You can grant or deny access by IP address, network ID, and domain.

4. Select Granted Access to grant access to specific computers and deny access to all others.

5. Select Denied Access to deny access to specific computers and grant access to all others.

   Create the grant or deny list. Click Add and then, in the Computer dialog box, specify Single Computer, Group Of Computers, or Domain.

   • For a single computer, type the IP address for the computer, such as 192.168.5.50.

   • For groups of computers, type the subnet address, such as 192.168.0.0, and the subnet mask, such as 255.255.0.0.

   • For a domain name, type the fully qualified domain name, such as eng.domain.com.

     Caution: When you grant or deny by domain, IIS must perform a reverse Domain Name System (DNS) lookup on each connection to determine whether the connection comes from the domain. These reverse lookups can severely increase response times for the first query each user sends to your site.

6. If you want to remove an entry from the grant or deny list, select the related entry in the Computers list, and then click Remove.

7. Click Apply. Before applying changes, IIS checks the existing restrictions for all Web sites and directories within Web sites. If a site or directory node uses a different value, an Inheritance Overrides dialog box is displayed. Use this dialog box to select the site and directory nodes that should use the new setting, and then click OK.

You can establish or remove restrictions at the site, directory, or file level by completing these steps:

1. In the Internet Information Services snap-in, right-click the site, directory, or file that you want to work with, and choose Properties. This displays a Properties dialog box.

2. Select the Directory Security tab and then click Edit on the IP Address And Domain Name Restrictions panel. This displays the IP Address And Domain Name Restrictions dialog box shown previously in Figure 5-13.

3. Select Granted Access to grant access to specific computers and deny access to all others.

4. Select Denied Access to deny access to specific computers and grant access to all others.

   Create the grant or deny list. Click Add and then, in the Computer dialog box, specify Single Computer, Group Of Computers, or Domain.

   • For a single computer, type the IP address for the computer, such as 192.168.5.50.

   • For groups of computers, type the subnet address, such as 192.168.0.0, and the subnet mask, such as 255.255.0.0.

   • For a domain name, type the fully qualified domain name, such as eng.domain.com.

5. If you want to remove an entry from the grant or deny list, select the related entry in the Computers list, and then click Remove.

6. Click Apply. Before applying changes, IIS checks the existing restrictions for all child nodes of the selected resource (if any). If a child node uses a different value, an Inheritance Overrides dialog box is displayed. Use this dialog box to select the site and directory nodes that should use the new setting, and then click OK.

Configuring Web Site Operators

You can designate Web site operators for each Web site on your server. Operators can then manage the site remotely.

Understanding Web Site Operators

Web site operators are a special group of users who have administrative privileges. Operators can perform the following tasks:

• Manage directories on a Web site through standard create, rename, and delete procedures.

• Manage properties of directories including directory permissions, default documents, directory security, HTTP headers, and error messages.

• Manage properties of a site including site permissions, operator assignment, performance, Internet Server Application Interface (ISAPI) filters, home directory properties, default documents, directory security, HTTP headers, and error messages.

Operators cannot configure properties that affect IIS, the host computer, or the network. These limits on operators are designed to enhance security.

Note: Operator privileges do not extend to the Administration Web site. Users must be members of the Administrators group before they can remotely manage IIS using the Administration Web site.

Remote operator administration is made possible by the scripts, components, and applications defined in the IISAdmin directory. The IISAdmin directory must be configured for any Web site that you want operators to be able to control remotely. By default this directory is located in \%SystemRoot%\System32\Inetsrv\Iisadmin.

Operators connect to Web sites that they want to manage through a standard browser, such as Internet Explorer 5.0. The URL they type is the site's domain name followed by the name of the virtual directory used for operator administration. For example, if the server's domain name is dev.microsoft.com and the administration directory is named ops, you could connect to the operator area by typing the following URL into your browser window:

https://dev.microsoft.com/ops/

The technique used to authenticate the operator's credentials depends on the authentication methods you've enabled for the administration directory. You should never allow anonymous access to the administration directory.

You can specify accounts that have operator privileges globally or locally. Global operator assignments are automatically applied to all Web sites on the server. Local operator assignments apply only to an individual Web site.

Permitting Operator Administration of a Web Site

To permit operator administration of a Web site, you must do the following:

1. Configure a virtual directory that maps to the physical location of the IISAdmin directory.

2. Create a pooled IIS application with the designated virtual directory as the starting point. A pooled IIS application isolates the administration tasks from the main IIS processes.

3. Set Execute permissions for the administration directory to Scripts Only or Scripts And Executables.

Assigning Operators to All Web Sites on a Server

To specify operator assignments for all Web sites on a server, complete the following steps:

1. In the Internet Information Services snap-in, right-click the icon for the computer you want to work with, and then select Properties. This displays a Properties dialog box.

2. Select WWW Service on the Master Properties selection list and then click Edit. This opens the WWW Service Master Properties dialog box for the computer.

3. Select the Operators tab. The Operators list box shows the currently configured operators. The global group Administrators is the only operator configured by default.

4. To add an operator, click Add. This displays the Select Users Or Groups dialog box, which you can use to select users and groups that should be configured as operators.

5. To remove an operator, select the operator in the Operators list box, and then click Remove.

6. Click OK three times to complete the operator assignment.

Assigning Operators to an Individual Web Site

To specify operator assignments for a specific Web site, complete these steps:

1. In the Internet Information Services snap-in, right-click the site, directory, or file that you want to work with. This displays a Properties dialog box.

2. Select the Operators tab. The Operators list box shows the currently configured operators. The global group Administrators is the only operator configured by default.

3. To add an operator, click Add. This displays the Select Users Or Groups dialog box, which you can use to select users and groups that should be configured as operators.

4. To remove an operator, select the operator in the Operators list box and then click Remove.

5. Click OK twice to complete the operator assignment.

More Tips for Enhancing Web Server Security

Your Web server is only as secure as you make it. To improve the security of your server, read the additional tips provided here, and apply the ones that make sense for your server environment.

Using Firewalls

Maintaining the security of your Web server is an ongoing task that requires continual vigilance. To shield your Web servers from attacks, you need a firewall, such as the Microsoft Internet Security and Acceleration Server or the Cisco PIX 515 Firewall. When you install a firewall, close all ports that you aren't using and only open ports that are needed.

The ports you'll want to open depend on the types of IIS resources you are using. FTP uses ports 21 and 23. SMTP uses port 25 and may require port 53 for DNS resolution. HTTP uses ports 80 and 443. NNTP uses ports 119 and 563.

Renaming the Administrator Account

The Administrator account is a known account that has extensive privileges on your Web server. Malicious users often target this account in an attempt to take control of the server. You can deter malicious users by changing the name of this account. Simply select a new name for the account and then rename it using Active Directory Users and Computers. You may want to tell other administrators in your company the new name for the administrator account.

Disabling the Default Web Site

The default Web site shouldn't be used in production environments. The site has many preconfigured applications that use system resources and allow execution of the related scripts and executables. The site also automatically allows remote administration through a directory that is well known to malicious users. All of these issues can pose a security risk to your server.

To disable the default Web site, follow these steps:

1. In the Internet Information Services snap-in, right-click the default Web site, and then select Stop.

2. Exit the IIS snap-in to save this configuration state.

3. From now on, the default Web site should be stopped when you or other administrators access the Internet Information Services snap-in.

Note: You can also delete the default Web site to prevent its use in the future.

Disabling Remote Administration from the Web

As you know from previous discussions, Web sites can be managed remotely through a browser. Operators connect to individual sites through the IISAdmin directory. Administrators connect to IIS through the Administration Web site. If you want to tightly control access to your server, you should disable remote administration from the Web and only allow access to the server through the IIS snap-in.

To disable remote administration from the Web, you should:

1. Stop the Administration Web site.

2. Delete the administration directory (normally named IISAdmin) or set the Execute permissions for this directory to None.

Disabling Directory Browsing

Directory browsing allows users to see the contents of directories. Most users don't need to see directory contents, so you should disable directory browsing globally. To do this, clear this Web server permission in the Master WWW Service Properties dialog box.

Creating Legal Notices

Every user who logs on to the Web server locally or through a telnet session should see a legal notice that tells the user this is a private computer system and its use is restricted to authorized personnel only. Legal notices have a caption and message text. You set the caption using the Registry key:

HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Windows
\CurrentVersion
\Policies
\System
\LegalNoticeCaption

You set the message text using the Registry key:

HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Windows
\CurrentVersion
\Policies
\System
\LegalNoticeText

Both keys can be created and modified using Registry Editor or a Windows script. If you create these keys, be sure to set the value type to REG_SZ. The REG_SZ value type is used to identify a string value type that contains a sequence of characters. When you set the key value, type a 1, followed by a comma, followed by the caption or message text, such as:

1,This is a private system. Use of this system is restricted to authorized
personnel only.

Applying Service Packs, Hot Fixes, and Templates

Microsoft regularly provides service packs and hot fixes for the Windows operating system. To maintain the security of the server, you should apply the service packs and hot fixes to production servers as soon as you've had a chance to review and test these updates on similarly configured test servers.

Microsoft also publishes security templates that can be applied to your Web servers. Security templates are available in all Windows 2000 server installations. You can preview existing templates and create your own templates using the Security Templates snap-in. You apply a template and analyze its security constraints using the Security Configuration And Analysis snap-in. These snap-ins can be accessed by completing the following steps:

1. Open the Run dialog box by clicking Start and then clicking Run.

2. Type MMC in the Open field and then click OK. This opens the Microsoft Management Console (MMC).

3. In MMC, click Console, and then click Add/Remove Snap-In. This opens the Add/Remove Snap-In dialog box.

4. On the Standalone tab, click Add.

5. In the Add Snap-In dialog box, click Security Templates, and then click Add.

6. Next, click Security Configuration And Analysis, and then click Add.

7. Close the Add Standalone Snap-In dialog box by clicking Close, and then click OK.

The security templates that you'll want to use are securews and hisecws. Securews is a template for Web servers that need strong security. Hisecws is a template for Web servers that need very strong security. As shown in Figure 5-14, these templates configure security for the following:

• Password, account lockout, and Kerberos policies

• Auditing, user rights assignment, and security options policies

• Event logs, system services, and file system permissions

• Registry keys for the local machine and the current user

Figure 5-14: Use the Security Templates snap-in to access existing security templates and to create new ones.

After you select the template that you want to use, you should go through each setting that the template will apply and evaluate how the setting will affect your environment. If a setting doesn't make sense, you should modify or delete it as appropriate. When you are ready to configure and analyze the settings, complete the following steps:

1. Access the Security Configuration And Analysis snap-in in an MMC.

2. Right-click the Security Configuration And Analysis node and then select Open Database. This displays the Open Database dialog box.

3. Type a new database name in the File Name field and then click Open.

4. The Import Template dialog box is displayed next. Select the security template that you want to use and then click Open.

5. Right-click the Security Configuration And Analysis node, and then choose Analyze Computer Now. When prompted to set the error log path, click OK. The default path should be just fine.

6. Wait for the snap-in to complete the analysis of the template. Afterward, review the findings, and update the template as necessary. You can view the error log by right-clicking the Security Configuration And Analysis node and choosing View Log file.

7. When you are ready to apply the template, right-click the Security Configuration And Analysis node and choose Configure Computer Now. When prompted to set the error log path, click OK. The default path should be just fine.

8. View the configuration error log by right-clicking the Security Configuration And Analysis node and choosing View Log file. Note any problems and act as necessary.

Removing the IISADMPWD Virtual Directory

The IISADMPWD virtual directory allows you to reset Windows NT and Windows 2000 passwords. It was designed for intranets and is not installed as part of an IIS 5.0 or later installation. However, if you upgraded from IIS 4.0, this directory is not removed and it may still be available on your server. If the Web server is accessible to the Internet, you should delete this directory.

Checking for Malicious Input in Forms and Query Strings

The text that users type into forms may contain values designed to cause problems on your system. If you pass this input directly to a script or ASP page, you may allow a malicious user to gain access to the system and cause problems. To prevent this, you should check all input before passing it to a script or ASP page.

One way to ensure that input contains only text and numbers is to remove characters that aren't alphanumeric. You can do this with the following Microsoft Visual Basic Scripting Edition (VBScript) example:

'Start a regular expression
Set reg = New RegExp
'Check for characters that aren't 0-9a-zA-Z or '_'
reg.Pattern = "\W+"
'Remove invalid characters from input string
goodString = reg.Replace(inputString, "")

If you want users to be able to enter punctuation but do not want to permit possible malicious input, you should check for and remove the pipe character (|). The pipe character is used to string commands together, which could allow a user to execute a command on your server. The following command removes the pipe character and all text that follows it from an input string:

'Start a regular expression
Set reg = New RegExp
'Check for the pipe character
reg.Pattern = "^(.+)\|(.+)"
'Remove pipe character and any text after it
goodString = reg.Replace(inputString, "$1")

Many other techniques for checking user input before using it are available. Check the Microsoft TechNet at https://www.microsoft.com/technet/ for more information.

Removing Unused Application Mappings

Application mappings are used to specify the ISAPI extensions and CGI programs that are available to applications. IIS is preconfigured to support many common ISAPI applications including ASPs, Internet Database Connector, and Index Server. If your Web site doesn't use some of these ISAPI applications, you can enhance security by removing the associated application mappings. Mappings that you may want to remove are the following:

• .htr, which is used for Web-based password reset

• .htw, .ida, and .idq, which are used by Index Server

• .idc, which is used for the Internet Database Connector

• .printer, which is used for Internet Printing

• .stm, .shtm, and .shtml, which are used for server-side includes

To remove application mappings globally for all Web sites on a server, follow these steps:

1. In the Internet Information Services snap-in, right-click the icon for the computer you want to work with, and then select Properties. This displays a Properties dialog box.

2. Select WWW Service on the Master Properties selection list and then click Edit. This opens the WWW Service Master Properties dialog box for the computer.

3. Select the Home Directory tab and then click Configuration on the Application Settings panel. This displays the Application Configuration dialog box.

4. On the App Mappings tab, select the application mappings that you want to remove, and then click Remove. When prompted to confirm the action, click Yes.

5. Click Apply. Before applying any changes, IIS checks the existing settings for all Web sites and directories within Web sites. Each time a site or directory node uses a different value, an Inheritance Overrides dialog box is displayed. Use this dialog box to select the site and directory nodes that should use the revised application mappings, and then click OK.

Click to order