Microsoft recommends using Windows Authentication for Web applications as your user authentication mechanism because it is integrated with Windows and Active Directory Domain Services (AD DS). By turning Windows Authentication on and Anonymous Authentication off, only authenticated users can access Web applications. You can use the following procedures to install, enable, and disable these authentication mechanisms.
To install Windows Authentication
Click Start and then click Server Manager.
In the Server Manager pane, expand Roles, and then click Web Server (IIS).
In the Role Services box, click Add Role Services.
In the Add Role Services wizard, select Windows Authentication, and then click Next.
On the Confirm Installation Selections page, click Install.
On the Installation Results page, click Close.
To enable Windows Authentication
In the Server Manager pane, click Internet Information Services (IIS) Manager.
In the Connections pane, click the server name, and then in the Home pane, double-click Authentication.
Figure 6.2 Enabling Windows Authentication in IIS Manager
In the Authentication pane, click Windows Authentication, and then in the Actions pane, click Enable.
To disable Anonymous Authentication
1. In the IIS Manager Authentication pane, click Anonymous Authentication.
2. In the Actions pane, click Disable.
Important This procedure turns Anonymous Authentication off for the entire IIS Web Server. If you have other Web applications that need anonymous access you might have to turn the setting back on for those Web applications.
It is also possible to disable Anonymous Authentication using the command line. This can be useful when using a script to configure the Web server.
To disable Anonymous Authentication via the command line, at the command prompt, use the following syntax:
%windir%\system32\inetsrv\appcmd set config -section:anonymousAuthentication -enabled:false
Remove Unused IIS Components
At this point in the Web Server role configuration process, review the IIS 7.0 components installed on the server to ensure that all of those that your installation requires are present. You must explicitly install all role services and features provided by IIS 7.0. The only way a service you do not need can install on your Web server is if you install it. Refer to the "Attack Surface" section earlier in this chapter to determine the role services that your Web server requires, add any that your applications require, and remove any that you do not require.
Some typical areas in which to check for components include:
Default Common HTTP modules installed by the IIS 7.0 Setup program.
Unused development environments.
Management features.
Configure a Unique Binding
By default, the IIS Web site listens on all configured IP addresses of the Web server for connections. The site also serves all requests that use port 80, regardless of the host header specified. Malicious software, such as viruses or worms, can attempt to iterate through a range of IP addresses to find new Web servers to infect. You can reduce the risk or such attacks by configuring the default Web site to only listen to a specific host name, which is called a unique binding.
For example, if you configure a host name as, *:80:myWebServer, instead of listening to all host names (*:80:*), such a configuration can prevent automated attacks that only use an IP address to attempt to access a server. An automated attack would usually attempt to iterate through the IP address namespace. For example, it could first try 1.1.1.1, then 1.1.1.2, 1.1.1.3, and so on.
Without a host name configured as a unique binding, your Web site would eventually receive a network packet from the attack. However, if you configure the server to require a host name, the automated attack will fail because the request to the IP address will fail, and the worm cannot determine the host name of the server without including more complex code to resolve host names. You can use the following procedure to configure a unique binding.
To configure a unique binding
Open Internet Information Services (IIS) Manager.
Select the name of your Web server, and then under the Sites node, right-click the required Web site.
From the context menu select Edit Bindings.
In the Edit Site Binding dialog box, select http in type list, and then click Edit.
Select the required IP address for the server's Web site, and then configure the Host header to match your required host name as shown in the following figure.
Figure 6.3 The Edit Site Binding dialog box
Based on the information in the previous figure, only applications that request the full URL for "http://contoso" can access the site. If an automated Internet worm tries to access the site using an IP address, for example "http://10.10.10.20," the connection attempt will fail.
You also can configure this setting from a command line using the following syntax:
%windir%\system32\inetsrv\appcmd set site "Default Web Site" -bindings:http/10.10.10.20:80:contoso
Move Root Directories to a Separate Data Partition
Past security vulnerabilities allowed an attacker to traverse from the URL namespace into the file system directories of the operating system. For example, if http://contoso/cgi.exe mapped to C:\inetpub\wwwroot\cgi.exe, without safeguards, an attacker could use the URL to execute the Windows command processor cmd.exe instead of the CGI program cgi.exe to access the following location:
http://contoso/../../windows/system32/cmd.exe.
IIS 7.0 is designed to prevent this type of attack by default. However, it is a best practice to move your Web site content on to a separate data partition from the one that the operating system uses. Although not required, many organizations choose to store Web site content on a dedicated data partition. This can provide both performance and security benefits. The following steps explain how to move Web site content to a new partition.
To move Web site content to a new partition
Open Internet Information Services (IIS) Manager.
Click the name of your Web server, and then underneath Sites, right-click Default Web Site.
Select Manage Web Site, and then select Advanced Settings.
Change the Physical Path property to a directory on the new data partition.
This process does not move the Web site's content or change the permission for the Web folder, so you also must transfer those resources across to complete the move.
You can change the default physical path for the Web site by executing the following command line:
%windir%\system32\inetsrv\appcmd set vdir "Default Web Site/" -physicalPath:D:\Web
Note This command assumes your new Web site content directory is D:\Web.
Configuring User Account Permissions
Next, you must assign permissions on the Web site content directory and check the user accounts that will be allowed access to the Web site. To do this, grant access to the following security entities:
The account associated with the IIS worker process used for the Default Web Site.
By default, this is the NetworkService account. You must edit the Default Application Pool configuration settings to change this default. If you have changed this setting to a custom account, you must grant access to the custom account, not the NetworkService account.
Note Do not change the account to the LocalSystem or LocalService account. Each of these accounts has more permissions that Microsoft recommends granting to IIS worker processes.
The users who access your Web site.
In most cases, you can keep the default ComputerName\Users group permissions for the folder, which allows members of a domain to access the content folder. If there are any special permissions granted to the ComputerName\Users group, ensure to remove them.
The Web site administrators.
To configure the permissions for the Web site, you use the standard Windows file system permissions mechanism via Windows Explorer. This allows you to determine the exact security permissions for each security entity. You can use the following procedure to achieve this.
To set permissions on the D:\Web folder
Open Windows Explorer, right-click the Web content folder (D:\Web in the example in this chapter), and then click Properties.
Click the Security tab, click the Advanced button, and then select Edit.
Clear the checkbox for Include inheritable permission from this object's parent.
In the Windows Security dialog box, select the Copy checkbox to copy the inherited permission to the folder.
Select the checkbox for Replace all existing inheritable permissions on all descendants with inheritable permissions from this object.
Select each permission entry, and then click Remove, except for the following:
SYSTEM
Administrators
<ComputerName>\Users, for example WebServer1\Users
Click Add, and then in Enter the object name to select box, type Network Service.
Click Check Names to resolve the NETWORK SERVICE name. This is the IIS default worker process identity.
Click OK, then confirm that the list of permissions displayed in the following figure is selected under Allow in the Permission Entry box, and then click OK.
Figure 6.4 Setting ACLs for the Network Service Account
On the Advanced Security Settings dialog box, click Add, and then in the Enter the object name to select box, type <DomainName>\Users.
For the Contoso domain this example uses, you would type Contoso\Users.
Click Check Names to resolve the Domain Users name.
Note These are the users who you are allowing access to the Web site. For a site that has special security requirements, you may wish to assign permissions to a dedicated user group that contains users who are specifically added to the group as required. If possible, maintain the MachineName\Users group with read and execute permissions.
Click OK and then ensure that permissions are selected in the Permission Entry for Web dialog box as displayed in the following figure. Finally, click OK as needed to exit the Properties window.
Figure 6.5 Setting ACLs for domain users
Enable Secure Sockets Layer (SSL)
If the network communications between the Web server and the client computers passes over untrusted networks, Microsoft recommends enabling Secure Sockets Layer (SSL) to encrypt the traffic to help secure it from network sniffing and host spoofing.
SSL requires a certificate that proves the servers identity and that is trusted by the client browsers. If the Web server can only be accessed privately within the enterprise, this certificate can be obtained from the organization's existing public key infrastructure (PKI). However, if the Web server can be accessed from the Internet, Microsoft recommends obtaining a certificate from a public certificate authority. For testing purposes, you can also use a self-signed certificate to encrypt traffic.
IIS 7.0 supports several methods to install a SSL certificate including:
Using the IIS Manager GUI.
Using the Certificate Manager GUI.
Web and Auto-enrollment.
Using the appcmd command-line tool.
Programmatically through Microsoft.Web.Administration using Windows Management Instrumentation (WMI) scripts.
For more information about how to install a SSL certificate, see the How to Setup SSL on IIS 7.0 page on the Microsoft Internet Information Services (IIS) Web site.
Installing the SSL certificate hardens your Web server configuration to a level that provides elevated security while ensuring that you can manage a functional feature set for the server.
Consider Additional Specialized Security Configuration Measures
For environments that require added security, there are a few additional measures that you can take to further harden the Web server. However, it is important to note that these steps do increase management overhead and can create Web application compatibly issues. It is very important to conduct thorough testing of your Web applications in a test environment before attempting to implement these recommendations on a production server.
To further secure your Web server installation, you might consider using the following features:
Access control list (ACL) hardening. You can further limit access to your Web site by specifying particular users in the ACL for your content directory instead of allowing all domain users to access the site.
If you want a more user friendly feature to limit access to your Web site, you can use the built-in IIS7 URL Authorization feature. For more information about this feature, see the Understanding IIS7 URL Authorization page on the Microsoft IIS Web site.
The IPv4 Restriction Lists feature, which lets you restrict the IP addresses of the client browsers you allow to connect to the Web server.
The Request Filtering feature, which lets you control many HTTP features, such as HTTP verbs, HTTP headers and URL size. For more information about this feature, see the How to Use Request Filtering page on the Microsoft IIS Web site.
Client certificate mapping, which allows you to enforce strong authentication by requiring users to provide client certificates when requesting to access your site. For more information about this feature, see the How to Setup SSL on IIS 7.0 page on the Microsoft IIS Web site.
You can also change the site's identity by changing the Application Pool identity to a low privileged local account.
|
