Securing Your Site Against Intruders
Whether your Web server is handling millions of accesses directly over the Internet or maintaining departmental documents on your intranet, security is an important consideration. When you connect computers to an intranet or an Internet, you can communicate with people and computers worldwide. This broad flexibility imposes a degree of risk not only can you communicate with people on other networks, users on other networks can initiate communication with your network. Although connecting to Web servers is generally done with good intentions, there are malicious individuals who attempt to infiltrate internal networks.
The Windows NT operating system was designed to help you secure your system against intruders. Internet Information Server builds on the Windows NT security model and provides additional monitoring and security features. This chapter will help you effectively use Windows NT security and Internet Information Server security at your site. You should understand all of the information in this chapter before connecting your computer to a public network. If you do not understand the information, you should consult Windows NT documentation, an authorized Microsoft Solution Provider, or other qualified source before installing your site on the Internet.
This chapter explains:
In addition to the Windows NT security features, you can set Read-only or Execute-only virtual directories by using Internet Service Manager. Internet Information Server also provides a way to deny user access to computers with particular IP addresses. IIS supports the Secure Sockets Layer (SSL) protocol, which securely encrypts data transmissions between clients and servers.
When an IIS Web server receives a browser request for information, it determines whether the request is valid. A simple overview of the security process used on each request is presented in the following illustration.
The following sections explain how to configure Windows NT and the Internet services to protect your system.
The anonymous logon user account must be a valid Windows NT user account on the server providing the Web services, and the password must match the password for this user in that computers user database. User accounts and passwords are configured in the Windows NT User Manager by setting User Rights in the Policies menu. The anonymous logon user account must have the Log on Locally user right.
The IUSR_computername account is automatically created (with a randomly generated password) during Internet Information Server setup. For example, if the computer name is marketing1, then the anonymous access account name is IUSR_marketing1.
By default, all Web client requests use this account. In other words, Web clients are logged on to the computer by using the IUSR_computername account. The IUSR_computername account is permitted only to log on locally on the server providing the Web services.
Note The IUSR_computername account is also added to the group Guests. If you have changed the settings for the Guests group, those changes also apply to the IUSR_computername account. You should review the settings for the Guests group to ensure that they are appropriate for the IUSR_computername account.
For the WWW and FTP services, you can allow or prevent anonymous access (all gopher requests are anonymous). For each of the Web services (WWW, FTP, and gopher), you can change the user account used for anonymous requests and change the password for that account.
2. For the WWW service, select the Allow Anonymous check box. For the FTP service, select the Allow Anonymous Connections check box.
3. Click OK.
2. In the Anonymous Logon user name box, type the new user name.
If Internet Information Server is installed on multiple domain controllers of the same domain, a separate user account is created in the domain user database for each Internet server computer. This does not cause any conflicts because each user name is unique, containing the name of the associated computer. However, you may find it more convenient to create a single anonymous logon user account in the domain to use for all Internet Information Server domain controllers in the domain. This can simplify administration of ACLs. To do this, follow these steps:
What a user is authorized to do on a computer is configured in User Manager by setting user rights in the Policies menu. User rights authorize a user to perform certain actions on the system, including the Log on Locally right, which is required for users to use Internet services if Basic authentication is being used.
If you are using Windows NT Challenge/Response Authentication, then the Access this computer from network right is required for users to use Internet services. By default, everyone has this right.
To increase security, follow these guidelines:
The WWW service provides two forms of authentication: basic and Windows NT Challenge/Response (sometimes referred to as NTLM).
Basic authentication does not encrypt transmissions between the client and server. Because Basic authentication sends the clients Windows NT user name and password in essentially unencrypted over the networks, intruders could easily learn user names and passwords.
Windows NT Challenge/Response authentication, currently supported only by Microsoft Internet Explorer version 2.0 or later, protects the password, providing for secure logon over the network. In Windows NT Challenge/Response authentication, the user account obtained from the client is that with which the user is logged on to the client computer. Because this account, including its Windows NT domain, must be a valid account on the Windows NT-based server running Internet Information Server, Windows NT Challenge/Response authentication is very useful in an intranet environment, where the client and server computers are in the same, or trusted, domains. Because of the increased security, Microsoft recommends using the Windows NT Challenge/Response method of password authentication whenever possible.
You have both Basic and Windows NT Challenge/Response authentication enabled by default. If the browser supports Windows NT Challenge/Response, it uses that authentication method. Otherwise, it uses Basic authentication. Windows NT Challenge/Response authentication is currently supported only by Internet Explorer 2.0 or later.
You can require client authentication for all FTP service requests or only for anonymous requests that fail. The FTP service supports only Basic authentication; therefore, your site is more secure if you allow anonymous connections. Your site is most secure if you allow only anonymous FTP connections.
2. Select Basic (Clear Text), Windows NT Challenge/Response, or both.
3. Click OK.
2. To enable authentication for failed anonymous connections, clear (delete) the Allow only anonymous connections check box.
3. To require all client requests to be authenticated, clear the Allow Anonymous Connections check box.
Note that if client authentication is disallowed and anonymous connections are allowed, a client request that contains a user name and password is processed as an anonymous connection, and the server ignores the user name and password.
When an anonymous request fails because the anonymous logon user account does not have permission to access the desired resource, the response to the client indicates which authentication schemes the WWW service supports. If the response indicates to the client that the service is configured to support HTTP Basic authentication, most Web browsers will display a user name and password dialog box, and reissue the anonymous request as a request with credentials, including the user name and password entered by the user.
If a Web browser supports Windows NT Challenge/Response authentication protocol, and the WWW service is configured to support this protocol, an anonymous WWW request that fails due to inadequate permissions will result in automatic use of the Windows NT Challenge/Response authentication protocol. The browser will then send a user name and encrypted password from the client to the service. The client request is reprocessed, using the clients user information.
If the WWW service is configured to support both Basic and Windows NT Challenge/Response, the Web server returns both authentication methods in a header to the Web browser. The Web browser then chooses which authentication method to use. Because the Windows NT Challenge/Response protocol is listed first in the header, a browser that supports the Windows NT Challenge/Response protocol will use it. A browser that does not support the Windows NT Challenge/Response protocol will use Basic authentication. Currently, Windows NT Challenge/Response authentication is supported only by Internet Explorer 2.0 or later.
When an anonymous request fails because the anonymous logon user account does not have permission to access the desired resource, the server responds with an error message. Most Web browsers will display a user name and password dialog box, and reissue the anonymous request as a request with credentials, including the user name and password entered by the user.
ACLs grant or deny access to the associated file or folder by specific Windows NT user accounts, or groups of users. When an Internet service attempts to read or execute a file on behalf of a client request, the user account offered by the service must have permission, as determined by the ACL associated with the file, to read or execute the file, as appropriate. If the user account does not have permission to access the file, the request fails, and a response is returned, informing the client that access has been denied.
File and folder ACLs are configured by using the Windows NT Explorer. The NTFS file system gives you very fine control on files by specifying users and groups that are permitted access and what type of access they may have for specific files and directories. For example, some users may have Read-only access, while others may have Read, Change, and Write access. You should ensure that the IUSR_computername or authenticated accounts are granted or denied appropriate access to specific resources.
You should note that the group Everyone contains all users and groups, including the IUSR_computername account and the Guests group. By default the group Everyone has full control of all files created on an NTFS drive.
If there are conflicts between your NTFS settings and Microsoft Internet Information Server settings, the strictest settings will be used.
You should review the security settings for all folders in your Web site and adjust them appropriately. Generally you should use the settings in the following table:
|Directory Type||Suggested NTFS Access|
|programs||Read and Execute access|
|databases||Read and Write access|
2. In Windows NT Explorer, right-click the folder (directory) you want to secure (select your site root to secure the entire site), and choose Properties.
3. In the Properties dialog box, choose the Security tab.
4. In the Security dialog box, choose Permissions.
5. In the Directory Permissions dialog box, click Add to add users and groups.
6. In the Add Users and Groups dialog box, add the users that should have access.
7. Click OK.
8. In the Directory Permissions dialog box, select the users and groups that should have permissions.
9. From the Type of Access list box, choose the permission level you want for the selected user or group.
10. Click OK.
For more information on setting the audit policy for files and folders, see the Windows NT documentation.
Read Read permission enables Web clients to read or download files stored in a home directory or a virtual directory. If a client sends a request for a file that is in a directory without Read permission, the Web server returns an error. Generally, you should give directories containing information to publish (HTML files, for example) Read permission. You should disable Read permission for directories containing Common Gateway Interface (CGI) applications and Internet Server Application Program Interface (ISAPI) DLLs to prevent clients from downloading the application files.
Execute Execute permission enables a Web client to run programs and scripts stored in a home directory or a virtual directory. If a client sends a request to run a program or a script in a folder that does not have Execute permission, the Web server returns an error. For security purposes, do not give content folders Execute permission.
A client request can invoke a CGI application or an Internet Server Application Program Interface (ISAPI) application in one of two ways:
For this request to be valid, the file Httpodbc.dll must be stored somewhere in the Web publishing tree (the directory structure that contains your content files; in this example, in the Scripts folder), and the folder it is stored in must have the Execute permission selected. This way the administrator can permit applications (CGI or ISAPI) to be run from a small number of carefully monitored directories.
In this example, the script file (Pubs.idc) is stored in a folder of the Web publishing tree that has the Execute permission enabled. The service, upon receiving the request, will use the file-name extension mappings to determine where to find the application, which can be stored anywhere. This technique prevents users from invoking CGI and ISAPI applications directly by adding parameters in the URL. This is therefore a more secure mechanism, and useful for all Web applications and scripts. See Associating Interpreters with Applications (Script Mapping) in Chapter 10, Configuring Registry Entries, for more information.
2. Select the folder for which you want to set permissions.
3. Click Edit Properties.
4. To allow Web clients to read and download the contents of a folder, select the Read check box.
5. To allow Web clients to run programs and scripts in a folder, select the Execute check box.
6. Click OK, then click OK again.
Note We recommend you set either Execute access or Read access on a folder, but not both. Executable scripts and programs should be kept in a virtual root separate from static Web content.
The source IP address of every packet received is checked against the Internet Information Server settings in the Advanced property sheet. If Internet Information Server is configured to allow access by all computers except those listed as exceptions to that rule, access is denied to any computer with an IP address included in that list. Conversely, if Internet Information Server is configured to deny all IP addresses, access is denied to all remote users except those whose IP addresses have been specifically granted access.
2. Click Add.
3. In the IP Address box, type the IP address of the computer to be denied access to your site or click the button next to the IP Address box to use a DNS name, such as www.company.com.
3. In the IP Address box, type the IP address of the computer to be granted access, or click the button next to the IP Address box to use a DNS name, such as www.company.com.
If you need to use the Server service on your private network, disable the Server service binding to any network adapter cards connected to the Internet. You can use the Windows NT Server service over the Internet; however, you should fully understand the security implications and comply with Windows NT Server Licensing requirements issues.
When you are using the Windows NT Server service you are using Microsoft networking (the server message block [SMB] protocol rather than the HTTP protocol) and all Windows NT Server Licensing requirements still apply. HTTP connections do not apply to Windows NT Server licensing requirements.
Microsoft Internet Information Server offers a protocol for providing data security layered between its service protocols (HTTP) and TCP/IP. This security protocol, called Secure Sockets Layer (SSL), provides data encryption, server authentication, and message integrity for a TCP/IP connection.
SSL is a protocol submitted to the W3C working group on security for consideration as a standard security approach for Web browsers and servers on the Internet. SSL provides a security handshake that is used to initiate the TCP/IP connection. This handshake results in the client and server agreeing on the level of security that they will use and fulfills any authentication requirements for the connection. Thereafter, SSLs only role is to encrypt and decrypt the byte stream of the application protocol being used (for example, HTTP). This means that all the information in both the HTTP request and the HTTP response are fully encrypted, including the URL the client is requesting, any submitted form contents (such as credit card numbers), any HTTP access authorization information (user names and passwords), and all the data returned from the server to the client.
An SSL-enabled server can send and receive private communication across the Internet to SSL-enabled clients (browsers), such as Microsoft Internet Explorer version 2.0 or later.
SSL-encrypted transmissions are slower than unencrypted transmissions. To avoid reducing performance for your entire site, consider using SSL only for virtual folders that deal with highly sensitive information such as a form submission containing credit card information.
Enabling SSL security on a Web server requires the following steps:
2. Request a certificate from a certification authority.
3. Install the certificate on your server.
4. Activate SSL security on a WWW service folder.
2. From the Key menu, click Create New Key.
3. In the Create New Key and Certificate Request dialog box, fill in the requested information, as follows:
5. When prompted, retype the password you typed in the form, and click OK.
7. To save the new key, from the Servers menu choose Commit Changes Now.
8. When asked if you want to commit all changes now, click OK.
Your key will appear in the Key Manager window under the name of the computer for which you created the key. By default, a key is generated on your local computer.
Note Do not use commas in any field. Commas are interpreted as the end of that field and will generate an invalid request without warning.
Once you have generated a key pair, you must get a certificate and then install that certificate with the key pair. For information about getting a certificate, see Acquiring a Certificate and Installing a Certificate with a Key Pair.
2. In the Key Manager window, select the key pair that matches your signed certificate.
4. Select the Certificate file from the list (Certif.txt, for example), and click Open.
5. When prompted, type the password that you used in creating the key pair.
7. When asked if you want to commit all changes now, click OK.
You can back up a key and certificate combination by following the procedure under Backing Up Keys earlier in this chapter.
Note If you do not specify an IP address while installing your certificate, the same certificate will be applied to all virtual servers created on the system. If you are hosting multiple sites on a single server, you can specify that the certificate be used only for a particular server IP address by adding the IP address, for example:
2. Select the folder that requires SSL security, then click Edit Properties.
3. Select the Require secure SSL channel option, and then click OK.
3. From the Edit menu, click Cut.
4. Select the server you want to move the key pair to.
5. From the Edit menu, click Paste.
You can copy a key pair to another server with the same procedure by substituting the Copy command for Cut.
2. After reading the warning about downloading sensitive information to your hard disk, click OK.
3. Type the key name in the File Name box, and click Save.
2. Select the file name from the list, and click Open.
2. In the Private Key Pair File box, type the file name for the key pair or click Browse and select the file.
3. In the Certificate File box, type the file name for the certificate or click Browse and select the file.
4. Click OK.
5. Type the password for the private key in the Private Key Password box, and click OK.
Save your key file in a safe place in case you need it in the future. It is a good idea to store your key file on a floppy disk and remove it from the local system after completing all setup steps. Do not forget the password you assigned to the key file.
© 1996 by Microsoft Corporation. All rights reserved.