CHAPTER 5

Securing Your Site Against Intruders

How Internet Information Server Security Works
Controlling Anonymous Access
Controlling Access by User or Group
Setting Folder and File Permissions
Setting WWW Directory Access
Controlling Access by IP Address
Running Other Network Services
Securing Data Transmissions with Secure Sockets Layer (SSL)

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:

• How Internet Information Server security works.

• Controlling anonymous access to your Web site.

• Controlling access by user name or group name.

• Requiring a user name and password for authenticated access.

• Controlling access by setting folder and file permissions.

• Securing data transmissions with SSL.

How Internet Information Server Security Works

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.

Controlling Anonymous Access

• An FTP client logs on with the user name “anonymous.”

• All gopher requests.

• A Web browser request does not contain a user name and password in the HTTP header (this is the default on new Web connections with most browsers).

Configuring the Anonymous User Account

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 computer’s 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.

To allow anonymous access

1. In Internet Service Manager, double-click the WWW service or the FTP service to display its property sheets, then click the Service tab.

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.

To change the account or password used for anonymous access

1. In Internet Service Manager, double-click the service to display its property sheets, then click the Service tab.

2. In the Anonymous Logon user name box, type the new user name.

The default user account is IUSR_computername, where computername is the name of your server. This account is created automatically when you set up Internet Information Server.

3. In the Password box, type the new password.

A randomly generated password is automatically created for the IUSR_computername account.

Note   If you change the password for this account, you must also specify the new password for the account in User Manager.

4. Click OK.

Using the Anonymous Account on Domain Controllers

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:

• In User Manager for Domains, create a new anonymous logon user account in the domain. Be sure that this account is made a member of appropriate groups, given a secure password, and is given the User Right (in the Policies menu) to log on locally.

• On the Service property sheet of Internet Service Manager, specify the new anonymous logon user name and password. You must do this for each Internet Information Server service running on all primary and secondary domain controllers in the domain.

• When later installing Internet Information Server on other domain controllers in the domain, be sure to use Internet Service Manager to modify the anonymous logon user name and password to match those created with User Manager for Domains. Do this for each Internet Information Server service installed.

Controlling Access by User or Group

Setting Up User Accounts

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:

• Do not give the IUSR_computername account, the Guests group, or the Everyone group any right other than the Log on Locally or the Access the computer from this network right.

• Make sure that all user accounts on the system, especially those with administrative rights, have difficult-to-guess passwords. In particular, select a good administrator password (a long, mixed-case, alphanumeric password is best) and set the appropriate account policies. Passwords can be set by using User Manager, or by typing at the system logon prompt.

• Make sure that you specify how quickly account passwords expire (which forces users to regularly change passwords), and set other policies such as how many bad logon attempts will be tolerated before locking a user out. Use these policies to prevent exhaustive or random password attacks, especially on accounts with administrative access. You can set these policies by using User Manager.

• Limit the membership of the Administrator group to trusted individuals.

• If you use the predefined Windows NT user accounts INTERACTIVE and NETWORK for access control, make sure files in your Web site are accessible to these user accounts. In order for a file to be accessed by anonymous client requests or client requests using Basic authentication, the requested file must be accessible by the INTERACTIVE user. In order for a file to be accessible by a client request that uses Windows NT Challenge/Response authentication protocol, the file must be accessible by the NETWORK user.

Requiring a User Name and Password

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 client’s 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.

To enable authentication for the WWW service

1. In Internet Service Manager, double-click the WWW service to display its property sheets, then click the Service tab.

2. Select Basic (Clear Text), Windows NT Challenge/Response, or both.

3. Click OK.

To enable authentication for the FTP service

1. In Internet Service Manager, double-click the FTP service to display its property sheets, then click the Service tab.

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.

How Anonymous Logons and Client Authentication Interact

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.

WWW Service

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 client’s 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.

FTP Service

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.

Creating Customized Authentication Schemes

Setting Folder and File Permissions

• By setting access permissions in the Windows NT File System (NTFS)

• By setting access permissions in the Internet Service Manager

Setting NTFS Permissions

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
content	Read access
programs	Read and Execute access
databases	Read and Write access

To secure your files on an NTFS drive

1. Put your files on your NTFS drive and add them to your Web site by using the Directories property sheet in Internet Service Manager.

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.

Auditing File Access

For more information on setting the audit policy for files and folders, see the Windows NT documentation.

Setting WWW Directory Access

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:

• The file name of the CGI executable or the ISAPI DLL can be specified in the request (URL). An example URL would be:

http://inetsrvr.microsoft.com/scripts/httpodbc.dll/scripts/pubs.idc?lname=Smith

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.

• The other way to configure CGI and ISAPI applications is to use the Web File Extension Mapping feature, which allows your executables and DLLs to be stored somewhere other than the Web publishing tree. An example URL would be:

http://inetsrvr.microsoft.com/scripts/pubs.idc?lname=Smith

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.

To set access permissions for a directory

1. In Internet Service Manager, double-click the WWW service to display its property sheets, then click the Directories tab.

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.

Controlling Access by IP Address

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.

To deny access to a specific computer or group of computers

1. In the Advanced property sheet of Internet Service Manager, choose the Granted Access button.

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.

To deny access to a group of computers, select Group of Computers. In the IP Address and Subnet Mask boxes, type the IP address and the subnet mask for a group to be denied access.

4. Click OK.

Access will be granted to all computers except the ones in the window with an Access status of Denied.

5. In the Advanced property sheet, click OK.

To grant access to only a specific computer or group of computers

1. In the Advanced property sheet of the Internet Service Manager, choose the Denied Access button.

This step denies access to all computers except those you specifically grant access to.

2. Click Add.

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.

To grant access to a specific group of computers, select Group of Computers. In the IP Address and Subnet Mask boxes, type the IP address and the subnet mask for the group to be granted access.

4. Click OK.

Access will be denied to all computers except those in the window with an Access status of Granted.

5. In the Advanced property sheet, click OK.

Running Other Network Services

Run Only the Services that You Need

Unbind Unnecessary Services from Your Internet Adapter Cards

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.

Check Permissions on Network Shares

Do Not Enable Directory Browsing

Securing Data Transmissions with Secure Sockets Layer (SSL)

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, SSL’s 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:

1. Generate a key pair file and a request file.

2. Request a certificate from a certification authority.

3. Install the certificate on your server.

4. Activate SSL security on a WWW service folder.

• You can enable SSL security on the root of your Web site (\InetPub\Wwwroot by default) or on one or more virtual folders.

• Once enabled and properly configured, only SSL-enabled clients will be able to communicate with the SSL-enabled WWW folders.

• URLs that point to documents on a SSL-enabled WWW folder must use “https://” instead of “http://” in the URL. Any links using “http://” in the URL will not work on a secure folder.

Generating a Key Pair

To generate a key pair

1. In the Microsoft Internet Server submenu, click Key Manager, or click the Key Manager icon on the Internet Service Manager toolbar.

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:

Key Name

Assign a name to the key you are creating.

Password

Specify a password to encrypt the private key.

Bits

By default, Key Manager generates a key pair 1024 bits long. To specify a key that is 512 or 768 bits long, make the proper selection in this box. The more bits you specify, the greater your security. In international versions, the size of each key you create is 512 bits

Organization

Preferably International Organization for Standardization (ISO)-registered, top-level organization or company name.

Organizational Unit

Your department within your company, such as Marketing.

Common Name

The domain name of the server, for example, www. mycompany.com.

Country

Two-letter ISO Country designation, for example, US, FR, AU, UK, and so on.

State/Province

For example, Washington, Alberta, California, and so on.

Locality

The city where your company is located, such as Redmond or Toronto.

Request File

Type the name of the request file that will be created.

4. After filling out the form, click OK.

5. When prompted, retype the password you typed in the form, and click OK.

An icon appears as the key is being created. When the key has been created, a screen appears giving you information about new keys and how to obtain a certificate.

6. After reading the New Key Information screen, 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.

Generating a Key Pair on Another Server

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.”

Acquiring a Certificate

Installing a Certificate with a Key Pair

-----BEGIN CERTIFICATE-----

JIEBSDSCEXoCHQEwLQMJSoZILvoNVQECSQAwcSETMRkOAMUTBhMuVrM
mIoAnBdNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYDVQ
QLExNQZXJzb25hIENlcnRpZmljYXRlMSQwIgYDVQQDExtPcGVuIE1hc
mtldCBUZXN0IFNlcnZlciAxMTAwHhcNOTUwNzE5MjAyNzMwWhcNOTYw
NTE0MjAyOTEwWjBzMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIER
hdGEgU2VjdXJpdHksIEluYy4xHDAaBgNVBAsTE1BlcnNvbmEgQ2VydG
lmaWNhdGUxJDAiBgNVBAMTG09wZW4gTWFya2V0IFRlc3QgU2VydmVyI
DExMDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDU/7lrgR6vkVNX40BA
q1poGdSmGkD1iN3sEPfSTGxNJXY58XH3JoZ4nrF7mIfvpghNi1taYim
vhbBPNqYe4yLPAgMBAAEwDQYJKoZIhvcNAQECBQADQQBqyCpws9EaAj
KKAefuNP+z+8NY8khckgyHN2LLpfhv+iP8m+bF66HNDUlFz8ZrVOu3W
QapgLPV90kIskNKXX3a

------END CERTIFICATE-----

To install a certificate

1. In the Internet Server program group, click Key Manager.

2. In the Key Manager window, select the key pair that matches your signed certificate.

If you had backed up the key pair file, you have to load it first. For instructions, see “Loading a Key Pair File” earlier in this chapter.

3. From the Key menu, choose Install Key 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.

The key and certificate are combined and stored in the registry of the server.

6. From the Servers menu, choose Commit Changes Now.

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:

10.191.28.45

Configuring a Directory to Require SSL

To require SSL

1. In Internet Service Manager, double-click the WWW service to display its property sheets, then click the Directories tab.

2. Select the folder that requires SSL security, then click Edit Properties.

3. Select the Require secure SSL channel option, and then click OK.

Moving a Key Pair to Another Server

To move a key pair to another server

1. From the Servers menu, click Connect to Server, type the name of the server you want to move the key pair to, and click OK.

The server name appears in the list of servers (the left column).

2. Select the key you want to move.

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.

Backing Up Keys

To back up a key or a private key pair file

1. From the Key menu in Key Manager, choose Export Key and then Backup File.

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.

The file is given a .req file-name extension and is saved to your hard disk drive. You can then copy it or move it to a floppy disk or magnetic tape.

Loading Backed Up Keys

To load a backed-up key

1. From the Key menu in Key Manager, choose Import Key and then Backup File.

2. Select the file name from the list, and click Open.

Loading a Key Created with Keygen.exe and Setkey.exe

To load a key

1. From the Key menu in Key Manager, choose Import Key and then KeySet.

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.

Suggestions for SSL Configuration and Operation

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.