Connecting computers to the Internet or an intranet provides for some very powerful and useful scenarios. When you connect to the Internet, you can communicate with millions of people and computers worldwide using Transfer Control Protocol/Internet Protocol (TCP/IP). This broad flexibility imposes a degree of risk not only can you communicate with people and other systems, it is also possible for users to attempt to initiate communication with your system. Although connecting to Web servers on the Internet or on an intranet 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.
Although security is important even for a personal Web site that is accessed only by members of your work group, your security configuration is crucial for safe operation of your system on the Internet. Although it is unlikely that your site will be maliciously tampered with, Internet servers are available to the general public and there may be some degree of public intrusion. This chapter will help you effectively use Windows NT security and Peer Web Services 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 source before installing your site on the Internet.
This chapter explains:
Windows NT provides user-account security and Windows NT File System (NTFS) file-system security. You can use the following topics as a checklist to ensure you have effectively used User Accounts and NTFS to secure Windows NT. Additionally, you can prevent security breaches by properly configuring the services running on your computer.
Windows NT security helps you protect your computer and its resources by requiring assigned user accounts. You can control access to all computer resources by limiting the user rights of these accounts.
Every operation on a computer running Windows NT identifies who is doing the operation. For example, the username and password that you use to log on to Windows NT identifies who you are and defines what you are authorized to do on that computer.
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 right to Log on locally, which is required for users to use Internet services.
An anonymous connection is processed when a client request does not contain a username and password. This occurs in the following cases:
Each Internet service maintains a Windows NT username and password to be used for the processing of anonymous requests. When an anonymous request is received, the service impersonates the user configured as the anonymous logon user. The request will succeed if the anonymous logon user has permission to access the requested resource, as determined by the resources Access Control List (ACL). For the WWW service only, if the user does not have permission to access the resource, the response returned to the client contains a list of supported authentication schemes for gaining access to the resource, based on system configuration.
The anonymous logon user account can be viewed and modified on the Service property sheet of each Internet service. Each Internet service running on the same computer can use the same, or different, anonymous logon user accounts. Including the anonymous logon user account in file or directory ACLs allows for precise control of the resources available to anonymous clients.
The anonymous logon user account specified must be a valid Windows NT user account on the Web server, and the password specified must match the password for this user in that computers user database. User accounts and passwords are configured using the Windows NT User Manager. The anonymous logon user account must have the user right (in the User Manager Policies Menu) to Log on Locally.
The IUSR_computername account is created during Internet services 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 using the IUSR_computername account. The IUSR_computername account is permitted only to log on locally on the system providing the Internet services. No network rights are granted that could allow an unauthorized user to damage your server or its files.
This account will, in most cases, give anonymous client requests access to public content published on the server. Run the Network applet in Control Panel to see the computer name configured for the Windows NT computer.
A randomly generated password is created for the IUSR_computername account. If you need to change the password for this account, you must specify the new password for the account in User Manager, and then on the Service sheet of the Internet Service Manager, for each Internet service installed.
When Peer Web Services for Windows NT is installed, the account is created on the local computer.
If you restrict Internet services to authenticated clients, users must supply a valid Windows NT username and password. The WWW service provides two forms of authentication: Basic and NT Challenge/Response (sometimes referred to as NTLM).
Basic authentication does not encrypt your username and password before transmission.
Microsoft recommends the Windows NT Challenge/Response method of password authentication.
Windows NT authentication, currently supported only by Microsoft Internet Explorer version 2.0 or later, encrypts the username and password, providing secure transmission of usernames and passwords over the network.
With both basic authentication and Windows NT authentication, no access is permitted unless a valid username and password is supplied. Password authentication is useful if you want only authorized individuals to access your Web site or specific portions controlled by NTFS. You can have both IUSR_computername access and authenticated access enabled at the same time.
A request containing credentials is one of the following:
When an Internet service receives a client request that contains credentials (a username and password), the anonymous logon user account is not used in processing the request. Instead, the username and password received by the client are used by the service. If the service is not granted permission to access the requested resource while using the specified username and password, the request fails, and an error notification is returned to the client.
For the WWW (HTTP) service only, 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 service supports. This is determined by the configuration of the WWW services authentication features. If the response indicates to the client that the service is configured to support HTTP basic authentication, most Web browsers will display a username and password dialog box, and reissue the anonymous request as a request with credentials, including the username 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 username and encrypted password from the client to the service. The client request will then be reprocessed, using the clients user information. 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 Web server computer, 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.
In addition to the anonymous logon username and password fields, the Service property sheet of Internet Service Manager contains the following authentication options:
The easiest way for someone to gain unauthorized access to your system is with a stolen or easily guessed password. Make sure that all passwords used on the system, especially those with administrative rights, have difficult-to-guess passwords. In particular make sure to 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 the User Manager utility, or at the system logon prompt.
The User Manager utility provides a way for the system administrator to specify how quickly account passwords expire (which forces users to regularly change passwords), and other policies such as how many bad logon attempts will be tolerated before locking a user out. Use these policies to manage your accounts, particularly those with administrative access, to prevent exhaustive or random password attacks.
By limiting the members of the Administrator group, you limit the number of users who might choose bad passwords and expose your system.
When creating a Web publishing directory in Internet Service Manager, three access permissions can be selected via check boxes on the Directories dialog box. The setting of these access permissions applies to the defined home directory or virtual directory, and all of its subdirectories. The permissions are:
In order for files stored in a directory (home directory or virtual directory) to be downloaded to a client, the directorys Read permission must be enabled. If a client sends a request for a file that is in a directory without Read permission, the Web server will return an error. Directories containing information to publish (HTML files, for example) would typically have this permission enabled. Directories containing Common Gateway Interface (CGI) applications and Internet Server Application Program Interface (ISAPI) DLLs would typically have this permission disabled, to prevent clients from downloading the application files.
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 (in this example, \Scripts), and the directory 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 is stored in a directory of the Web publishing tree that has the Execute permission enabled. The service, upon receiving the request, will use the filename-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. Please see filename-extension mapping for more information.
This option must be selected to require encrypted communication for a directory. For more information on Secure Sockets Layer (SSL), see Securing Data Transmissions with Secure Sockets Layer (SSL), later in this chapter.
The WWW, gopher, and FTP services are fully integrated with Windows NT user accounts and file access permissions.
Every access to a resource, such as a file, an HTML page, or an Internet Server API (ISAPI), is done by the services on behalf of a Windows NT user. The service uses that users username and password in the attempt to read or execute the resource for the client.
In addition to user accounts, you should place your data files on an NTFS partition. NTFS provides security and access control for your data files. You can limit access to portions of your file system for specific users and services by using NTFS. In particular, it is a good idea to apply Access Control Lists (ACLs) to your data files for any Internet publishing service.
The NTFS file system allows ACLs to be assigned to files and directories. ACLs grant or deny access to the associated file or directory 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 directory ACLs are configured by using the Windows NT File Manager.
The NTFS file system gives you very granular 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 Peer Web Services settings, the strictest setttings will be used.
You should review the security settings for all Microsoft Peer Web Services directories and adjust them appropriately. Generally you should use the settings in the following table:
Directory Type | Suggested Access |
content | Read access |
programs | Read and Execute access |
databases | Read and Write access |
2. In the Windows NT File Manager, select the directory you want to secure (select your site root to secure the entire site).
3. From the Security menu, choose Permissions.
4. In the Directory Permissions dialog box, click Add to add users and groups.
5. In the Add Users and Groups dialog box, add the users that you want to grant access to.
6. Click OK.
7. In the Directory Permissions dialog box, select the users and groups that you want to assign permission to.
8. From the Type of Access list box, choose the permission level you want for the selected user or group.
9. Click OK.
You can enable auditing of NTFS files and directories on Windows NT through the File Manager. You can review the audit records periodically to ensure that no one has gained unauthorized access to sensitive files.
You should review all of the network services that you are using on any computer connected to the Internet.
The fewer services you are running on your system, the less likely a mistake will be made in administration that could be exploited. Use the Services applet in Control Panel to disable any services not absolutely necessary on your Internet server.
Use the Bindings feature in the Network applet in Control Panel to unbind any unnecessary services from any network adapter cards connected to the Internet. For example, you might use the Server service to copy new images and documents from computers in your internal network, but you might not want remote users to have direct access to the Server service from the Internet. 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.
If you are running the Server service on your Internet adapter cards, be sure to double-check the permissions set on the shares you have created on the system. It is also wise to double-check the permissions set on the files contained in the shares directories to ensure that you have set them correctly.
Peer Web Services for Windows NT integrates Windows NT authentication (username and password) security and NTFS file system security.
A simple overview of the security process used on each request is presented in the following illustration.
By default, all requests use anonymous access through the IUSR_computername user account created during Peer Web Services setup. This account is a user account and is granted the right to log on locally.
Username authentication is probably most useful if you want to control access to your server by individual user or group.
When creating a Web publishing directory in Internet Service Manager, three access permissions can be selected by selecting or clearing check boxes on the Directories dialog box. The setting of these access permissions applies to the defined home directory or virtual directory, and all of its subdirectories. The permissions are:
In order for files stored in a directory (home directory or virtual directory) to be downloaded to a client, the directorys Read permission must be enabled. If a client sends a request for a file that is in a directory without Read permission, the Internet service will return an error. Directories containing information to publish (HTML files, for example) would typically have this permission enabled. Directories containing CGI applications and Internet Server Application Program Interface (ISAPI) DLLs would typically have this permission disabled, to prevent clients from downloading the application files.
A client request can invoke a CGI application or 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 (in this example, \Scripts), and the directory 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 is stored in a directory of the Web publishing tree that has the Execute permission enabled. The service, upon receiving the request, will use the filename-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. Please see Associating Interpreters with Applications (Script Mapping) in Chapter 10, Configuring Registry Entries, for more information.
This option must be selected to require encrypted communication for a directory. For more information on Secure Sockets Layer (SSL), see Securing Data Transmissions with Secure Sockets Layer (SSL), later in this chapter.
Note that neither the FTP nor gopher services support SSL.
On NTFS drives you must also ensure that similar permissions are set on directories.
In addition to implementing the previous suggestions on securing Windows NT, you can further enhance your security by using Internet Service Manager to configure the WWW service.
To gain access to files, users must be identified with a valid username and password.
If you are allowing anonymous logon using the IUSR_computername account, you should first ensure that computer-wide User Rights (in the User Manager Policies menu) do not allow the IUSR_computername account, the Guests group, or the Everyone group any right other than to Log on Locally. Next, ensure that the file permissions set in the Windows NT File Manager are appropriate for all content directories used by Microsoft Peer Web Services.
If you allow basic or Windows NT Challenge/Response password authentication, users can supply a username and password to gain access to areas that require specific authorization. The usernames must be valid usernames on the computer running Peer Web Services, or in a Windows NT domain accessible from that computer.
2. In the Anonymous Logon box, type the username and password to be used by the WWW service when accessing resources on behalf of an anonymous client.
Basic (clear text)
Windows NT Challenge/Response for encrypted authentication. This option works only for clients using Internet Explorer version 2.0 (or later).
Unless it is part of your strategy, you should disable directory browsing on the Directories property sheet. Directory browsing exposes the entire file structure; if it is not configured correctly, you run the risk of exposing program files or other files to unauthorized access.
This section gives further suggestions for securing your Web site.
In User Manager, when configuring a Windows NT user account to be used either as the Peer Web Services anonymous logon account, or as a user account specified by client requests using HTTP Basic authentication, be sure that the user account is granted the Log on locally User Right. This is specified in the Policies menu of the User Manager.
If you need a WWW request authentication scheme not supported by the service directly, obtain a copy of the ActiveX Software Development Kit (SDK), and read the ISAPI Filters specification on how to develop user-written ISAPI Filter dynamic-link libraries (DLLs) that handle request authentication. The ActiveX SDK can be found at http://www.microsoft.com/intdev.
Previous sections of this chapter have dealt with securing your Web service from unauthorized access. This section discusses protocols that use cryptography to secure data transmissions to and from your server.
Peer Web Services for Windows NT 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 World Wide 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 (usernames 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.
Enabling SSL security on a Web server involves 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 directory.
As part of the process of enabling Secure Sockets Layer (SSL) security on your Internet server, you need to generate a key pair and then acquire an SSL certificate. The new Key Manager application (installed with the product and located in the Peer Web Services program group) simplifies this procedure.
Use Key Manager to create two files. The first file is a key file containing the key pair. The second file is a certificate request file.
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:
Password
Bits
Organization
Organizational Unit
Common Name
Country
State/Province
Locality
Request File
4. Click OK.
5. When prompted, retype the password you typed in the form, and click OK.
The key generated by Key Manager is not valid for use on the Internet until you obtain a valid key certificate for it from a key authority. Send the certificate request file to your key authority service to obtain a valid certificate. Until you do so, the key will exist on its host computer, but cannot be used.
Contact a certifying authority such as VeriSign. Instructions for acquiring a VeriSign certificate can be found on VeriSigns Web site, www.verisign.com.
After you complete your certificate request, you will receive a signed certificate from the certification authority (consult your certification authority for complete details). It will look something like the following example:
JIEBSDSCEXoCHQEwLQMJSoZILvoNVQECSQAwcSETMRkOAMUTBhMuVrM
------END CERTIFICATE----------BEGIN CERTIFICATE-----
mIoAnBdNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYDVQ
QLExNQZXJzb25hIENlcnRpZmljYXRlMSQwIgYDVQQDExtPcGVuIE1hc
mtldCBUZXN0IFNlcnZlciAxMTAwHhcNOTUwNzE5MjAyNzMwWhcNOTYw
NTE0MjAyOTEwWjBzMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIER
hdGEgU2VjdXJpdHksIEluYy4xHDAaBgNVBAsTE1BlcnNvbmEgQ2VydG
lmaWNhdGUxJDAiBgNVBAMTG09wZW4gTWFya2V0IFRlc3QgU2VydmVyI
DExMDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDU/7lrgR6vkVNX40BA
q1poGdSmGkD1iN3sEPfSTGxNJXY58XH3JoZ4nrF7mIfvpghNi1taYim
vhbBPNqYe4yLPAgMBAAEwDQYJKoZIhvcNAQECBQADQQBqyCpws9EaAj
KKAefuNP+z+8NY8khckgyHN2LLpfhv+iP8m+bF66HNDUlFz8ZrVOu3W
QapgLPV90kIskNKXX3a
Copy and save the text to a file, using a tool such as Notepad, giving it a name you can remember (for example, Certif.txt). Then use Key Manager to install your signed certificate on the server.
2. From the Key menu, choose Install Key Certificate.
3. Follow the on-screen instructions.
10.191.28.45
Once the certificate has been applied, the SSL feature is enabled from Internet Service Manager for the WWW services. SSL can be required on any virtual directory available through the Internet server and is configured on the Directories pane of the Service property sheet.
Microsoft recommends that you use separate content directories for secure and public content (for example, C:\Inetsrv\Wwwroot\Secure-Content and C:\InetsrvWwwroot\Public-Content). It is important to avoid having a server directory not protected by SSL as a parent for a secure directory.
It is suggested that you 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.