Chapter 9 - Security

The purpose of security is to minimize threats to resources and assets through a combination of policy, hardware, and software. This chapter addresses how to configure a secure Web server that is running Microsoft® Windows® 2000 Server and Internet Information Services (IIS) 5.0 for use on the Internet or an intranet. It is assumed that the reader is familiar with the IIS 5.0 security material in the Windows 2000 online product documentation.

This chapter begins with a discussion of core security principles and explains how the operating system adheres to those principles. It goes on to explore IIS 5.0 security, showing how IIS builds upon Microsoft® Windows® security. Once you have familiarized yourself with the security principles covered in this chapter, you will probably want to read "Site Security Planning" in this book, which describes how to set policies for securing Web resources, applications, and data in an intranet and over the Internet.

On This Page

Foundations of Computer Security
Using the Built-in Security Features of Windows 2000 Server
Configuring IIS 5.0 Security
An End-to-End Troubleshooting Example
Defending Against Malicious Attacks
Auditing Access with IIS 5.0 Logs
IIS 5.0 Security Checklist
Additional Resources

Foundations of Computer Security

What does it really mean to say that a computer is secure? To answer this, it is important to understand the core components of computer security:

• Authentication

• Authorization

• Privacy

• Integrity

• Availability

• Auditing

• Nonrepudiation

The following sections define each category of security. (The specific technologies discussed in these sections will be explained in further detail later in the chapter.)

Authentication

Authentication, sometimes referred to as identification, allows initial access to an operating system (such as Windows). The first step in authentication is presenting credentials, followed by system validation of those credentials. Once these are validated, the user can access resources controlled by the system. Today, most authentication credentials take the form of user names and passwords. However, Windows 2000 Server also supports credentials such as certificates held on smart cards. For more details about smart card authentication, see "Authentication" in the Microsoft® Windows® 2000 Server Resource Kit Distributed Systems Guide.

Different authentication schemes provide differing degrees of security. For example, passwords are a fairly insecure means of identification because they are relatively easy to guess. Certificates, which are discussed later in this chapter, are very difficult to forge and thus provide a greater degree of security.

Authorization

Once a user has been authenticated, he or she will want access to certain resources maintained by the system such as files, printers, and database tables. Authorization is determined by verifying that the authenticated user has access to the resource.

Note: For authorization to succeed, authentication must be performed first.

Access is resolved by comparing information about the user with access control information associated with the resource. If Cheryl is given full access, she can read, write, and delete a file called Info.txt. But suppose Alice has read-only access to this same file. If Alice attempts to write to or delete the file, she will be denied access.

Privacy

Privacy, sometimes referred to as confidentiality, is the prevention of message flow to anyone other than the intended recipients. Alice may want the session between her workstation and the network printer to be private so that anyone using a network protocol analyzer (often referred to as a network sniffer), such as Microsoft® Network Monitor, cannot see what Alice is printing. This privacy is often achieved by encrypting or scrambling the data as it flows between the two computers. (Encryption is discussed later in this chapter.)

Privacy is optional; it does not require authentication or authorization.

Integrity

Integrity refers to the ability to protect data from being deleted or changed without the permission of its owner.

If Alice orders 100 widgets from Bob, she does not want the order to be modified en route to Bob (by a malicious attacker) to an order for 1,000 widgets. Like privacy, integrity is optional; it does not require any form of access control mechanisms.

Availability

In principle, availability is somewhat similar to integrity, but it applies to the flow of data and the accessibility of the system. For example, an attack that makes a system crash has made the system unavailable. These types of attacks, often called denial-of-service attacks, are extremely hard to prepare for and predict. All systems should offer a degree of availability, based on the necessity of the services a system provides.

Auditing

Auditing refers to maintaining a secure list of all the events on your system, such as who logged on and when, what files a user accessed, and so on. Auditing is considered mandatory in secure systems.

Nonrepudiation

Nonrepudiation is a method of proving either that a user performed an action (such as enrolling in a stock plan or applying for a car loan), or that the user sent or received some information at a particular time. This prevents the individual from fraudulently reneging on a transaction. By comparison, if you purchase an item, you might have to sign for the item upon receipt. If you decide to renege on the deal, the vendor can simply show you the signed receipt.

A comprehensive nonrepudiation plan usually requires authentication, authorization, data integrity, and auditing. In addition, nonrepudiation requires a message on the Web page, warning that the action the user is about to take is legally binding. This does not make the Web server more secure, but it does make Web transactions (such as purchasing an item) more secure.

Today, electronic nonrepudiation across the Internet is new and there is little in the way of legal precedent. This is sure to change as more business is performed across the Web.

Threats, Vulnerabilities, and Attacks

When considering the security of a system you will need to determine all the possible threats, vulnerabilities, and attacks. You will also need to consider the appropriate tradeoffs between security on one hand, and usability and cost on the other. For more information, see "The Bottom-Line Cost of Security" later in this chapter.

Threats

A threat is the possibility of system compromise. For example, a threat could be the potential for unauthorized people to gain access to sensitive information, such as credit card information or health records. Threats usually involve confidential information.

Vulnerabilities

A vulnerability is a weakness in a system that might allow a threat to become realized. For example, if a secure server is left unlocked, it might be possible for a malicious user to physically access the computer and copy files to a floppy disk.

Vulnerabilities in computer systems could be bugs in the software or hardware, or they could be the result of administrative error. Examples of administrative errors include choosing a weak password (one that someone can easily guess) for the Administrator account, or accidentally setting an insecure discretionary access control list (DACL) on a confidential file.

Attacks

An attack takes advantage of an existing vulnerability. For example, suppose a malicious user knows that some users have weak passwords and tries guessing them until gaining access to restricted resources.

Types of Attack

It is important to realize the different types of security attacks you might encounter. Once you understand these, you will learn the appropriate countermeasures to take.

The three main types of attack are:

• Disclosure of data

• Corruption of data

• Denial of service

Disclosure of Data

Disclosure refers to unauthorized or inappropriate access to sensitive data. This is probably the most common form of attack. An example of disclosure is a file that holds confidential payroll information. If this file finds its way into the hands of someone who should not be privy to the data, then the data has been disclosed.

Corruption of Data

This is a particularly insidious attack, especially if the victim has very poor backup policy. Data corruption is mainly the realm of the computer virus, rather than that of intruders. Very few intruders actually wish to destroy data; most attack computer systems for entertainment and for the intellectual challenge.

If data is corrupted, the only real remedy is restoration from a previous backup.

Denial of Service

Denial-of-service attacks have become one of the most common forms of attack on the Internet today because many can be started remotely.

There are two types:

• The first occurs when a system is so utterly consumed that it cannot spare any further resources for other users.

• The second occurs when a system is made to crash and hence it cannot service other users.

An example of the first type of denial of service is a program that swamps all the printers in an organization with massive high-priority print jobs. This will prevent all other users from printing any documents and, in the case of a company that relies on printing to perform its core business function, could result in a loss of earnings.

An example of the second type of denial of service is a program that sends a large block of data to a remote program, knowing that the server will fail when it attempts to process the data. This is often referred to as a "buffer overflow" attack.

The Bottom-Line Cost of Security

Practically all data held on computers has some value. Sometimes this value is small, such as simple e-mail messages between friends saying "Hi!" Other times the value is great, such as documents pertaining to military secrets or to business tactics and strategies.

When determining the appropriate level of security for your Web servers, you need to consider the following:

• The value of the data (the cost to create it, as well as the cost to the organization if the data is leaked to malicious users)

• The cost of securing the data

• Usability tradeoffs

Note: The cost to the organization if data is leaked also includes the intangible cost involving loss of client or shareholder faith.

As shown in Figure 9.1, as a system becomes more secure, it also becomes less usable. At some point you might realize that a system is so secure that your intended audience cannot access your service.

Figure 9.1 The Tradeoff Between Usability and Security

Also note that there is a point at which it is not worth further securing the system, as the cost of deploying the security becomes greater than the cost associated with the risk of a security attack. Is it worth spending $100,000 to secure data valued at only $25,000?

Once you understand the value of your data, the deployment cost, and the usability tradeoffs, you can begin planning how to secure your system. This is a very large field and is beyond the scope of this book. For more information about assessing values and costs, see "Additional Resources" at the end of this chapter.

Using the Built-in Security Features of Windows 2000 Server

This section covers the following topics:

• Authentication in Windows 2000 Server

• Authorization in Windows 2000 Server

• Privacy and Integrity Mechanisms in Windows 2000 Server

• Availability in Windows 2000 Server

• Auditing in Windows 2000 Server

Authentication in Windows 2000 Server

Windows 2000 Server supports authenticated logon, meaning that the user must present credentials (usually a combination of user name and password) for identification. Once the user is authenticated by the operating system, a security token is attached to all applications that the user runs. All processes (applications) must have a token associated with them that identifies the user and the Windows groups to which that user belongs. The token contains the user's security identifier (SID) and the SIDs of all the groups to which the user belongs. An SID uniquely identifies all users and groups (of users) in the Microsoft® Windows® operating system.

In order to log on, the user must have an account in either the security account manager (SAM) database or in the Microsoft® Active Directory" directory service.

What Does an SID Look Like?

Fortunately, most administrators will never have to deal with SIDs directly. Here is a sample SID:

S-1-5-21-2127521184-1604012920-1887927527-1004 

The first part, S-1-5, identifies Windows 2000 Server; the next four blocks of numbers identify the Windows domain or workgroup; and the last number identifies the particular user or group.

Well-Known SIDs

Each and every account and group in the Windows operating system has a unique SID, which is also unique to that domain of servers. However, some SIDs are termed well-known. In other words, they are the same regardless of what domain you use. These SIDs include:

Account	SID	Comment
LocalSystem	S-1-5-18	The account which most system services use
Everyone	S-1-1-0	All users; the Everyone group
Interactive	S-1-5-4	Users who can log on for interactive operation
Network	S-1-5-2	Users who can log on across a network

Logon Types and Token Types

Accounts can log on to a Windows server if they have the appropriate privilege.

You can set logon types using the Group Policy editor, shown in Figure 9.2. The Group Policy editor is accessed by loading the Computer Management administrative tool from Start/Programs/Administrative Tools.

Figure 9.2 Setting Logon Privileges Using the Group Policy Editor

When a user with the appropriate privilege is authenticated and the security token is generated, the token has a logon type. The most common logon types in Windows are the following:

• Interactive logon

• Network logon

• Batch logon

Interactive Logon

An interactive logon is generated when the user is physically present at the computer while entering credentials. The account logging on must have the Log on locally privilege; if it does not, the account will fail to log on. An example of an interactive logon is pressing CTRL-ALT-DEL at the Windows prompt, then entering a user name and password.

Also note that a user can be logged on interactively (as if present at the computer) across the network. Most user accounts are logged onto IIS 5.0 interactively.

Network Logon

A network logon is generated when the user is connecting to a network computer. The account logging on must have the Access this computer from network privilege. If it does not, the account will fail to log on.

An example of a network logon is when the user is logged on to a computer and then accesses a resource, such as a printer, on a network computer that is running Windows. When the user attempts to connect to the network resource, the Windows operating system will automatically attempt a network logon.

Batch Logon

A batch logon is rarely used in the Windows operating system because it is usually reserved for applications that run as batches, such as bank account reconciliation and big print spools. The account logging on must have the logon as a batch job privilege. If it does not, the account will fail to log on.

Note: If you are familiar with Microsoft® Windows NT® 4.0, you will notice four new logon privileges in Windows 2000 Server: deny logon locally, deny network logon, deny batch logon and deny service logon. They provide the ability to deny logon privileges. For example, you can allow a group of users the ability to log on locally but not allow one specific, nontrusted account to do so.

Services and Service Security

The Windows operating system can run special applications called services, which are similar to UNIX daemons. Services generally start along with the operating system and run in the background, without any user interface. Examples include Microsoft® SQL Server, the Spooler, IIS Web Server, and the Windows® Event Log. Because they are applications, services must run in the context of a user account. The LocalSystem account, discussed below, is set aside for this purpose.

Services pose some interesting security issues that you must be aware of, most notably:

• Services, as mentioned, usually have no user interface. Therefore, any component that might work correctly from, for example, Microsoft® Visual Basic® might not work correctly from IIS 5.0, if the component expects a user interface.

• IIS 5.0 might be running under a different user account than the logged-on user, and thus might not have access to the same registry settings. A common example of this is Open Database Connectivity (ODBC) Data Source Names (DSNs); by default these are set per user. To make DSNs work with IIS 5.0, they should be System DSNs.

The LocalSystem Account

The LocalSystem account has no password, and no one can log on under this account. On the local computer, LocalSystem account can perform many tasks required of administrators. It has very few privileges beyond the boundaries of the server on which it is being used, thus helping to prevent attacks if an attempt is made to compromise a service.

LocalSystem is the most common account under which Windows services are run.

Important: Changing the Log on as option from the LocalSystem account to another user account can cause a service to fail on startup. IIS 5.0 requires the startup account to be LocalSystem.

Privileges and Attack Prevention

When a process runs, it does so in the context of a user account. If the process is running as a highly privileged account (such as the Administrator), and is compromised, any malicious attack will be in the context of the Administrator account, thereby making the potential for damage greater. Because of this, it is recommended that you always run in a low-privilege account. This is known as the principle of least privilege.

Discretionary Access Control Lists

To determine whether the user of an application is permitted access to a resource such as a file or a printer, the Windows operating system takes the user information from the security token associated with the application, and compares this information with the discretionary access control lists (DACLs) associated with that resource. A DACL is a list of access control entries (ACEs) that contain a user name or group, and include which permission that user or group has for each resource.

To use and set DACLs on files you must be using the NTFS file system.

The comparison of DACLs and user information is what determines who can gain access to a resource in the Windows operating system. If the DACL and the user information in the token are not the same, the user is denied access to that resource.

Impersonation

The Windows operating system also supports the ability to impersonate another user. Impersonation is useful in a distributed environment when servers must pass client requests to other servers or to the operating system. This way, the operating system can perform the request as if the original client had made it. You don't have to maintain a set of user accounts and passwords on the network server, nor do you have to ask the user to log on again in order to access the network resource.

Why Is Impersonation Important?

Impersonation reduces the number of times a user is required to enter a password. However, most services run as LocalSystem, which allows full access. This being the case, how does a service access a resource (such as a file) securely on behalf of the client?

Here's an example of how impersonation works. Cheryl wants to delete a file called Data.asp. The file is protected so that only the operating system (LocalSystem), administrators, and certain trusted users can access it. Since Cheryl is not on this list of trusted users, it would seem that she cannot access the file.

However, Cheryl can, in fact, delete the file because the application through which she deletes it is actually running under LocalSystem. Since Cheryl has full access, this is obviously not a safe, secure environment.

To safeguard against the file being deleted, all server processes should be configured to impersonate the requesting user before accessing the resource. If the server processes are configured in this way, the server will then impersonate Cheryl and attempt to delete the file. However, this will fail because she does not have delete permission or any other permissions to the file.

Authentication Methods in Windows 2000 Server

Windows 2000 Server supports a number of authentication schemes, most notably:

• Windows NT Challenge Response (now known as integrated Windows authentication)

• Kerberos v5 authentication

• Client authentication certificates

Windows NT Challenge Response authentication was the default authentication used prior to Windows 2000 Server. In Windows 2000 Server, Kerberos v5 has replaced Windows NT Challenge Response authentication (now known as integrated Windows authentication) as the default mechanism. For most users the differences between the two are transparent.

Windows 2000 Server also supports client authentication certificates (explained later in this chapter) as a means to provide authentication credentials. Rather than using a password to gain access information stored in the client certificate, the public key is used. Regardless of whether Windows 2000 Server uses Kerberos v5 authentication, or a client authentication certificate, the result is the same: a user token.

Authorization in Windows 2000 Server

Authorization is determined by using DACLs. These can be set on any Windows object, but the most common are DACLS on files, as well as on registry nodes, and Active Directory nodes. For more information about using the Windows DACL Editor, see "Access Control" in the Distributed Systems Guide.

To demonstrate how access is determined, it is necessary to look at how DACLs are structured. As mentioned previously, a DACL is a series, or list, of ACEs; each ACE contains the SID of a user or group account and indicates whether that account has access to the object in question. For example, a DACL may contain four ACEs:

• Guests (No access)

• System (Full access)

• Administrator (Full access)

• Everyone (Read access)

  Note: The deny access ACE is placed first. No matter in what order you place the ACEs when you set permissions on an object, for speed reasons Windows 2000 Server will always move deny access ahead of allow access.

When determining access, Windows 2000 Server looks at the DACL on the object and compares the user SID and group membership SIDs in the calling token to see if this SID is listed in the DACL. If a SID matches the SID in an ACE and if the ACE allows access, then access to the object is granted. Otherwise, it is denied.

Privacy and Integrity Mechanisms in Windows 2000 Server

Windows 2000 Server supports three major privacy and integrity protocols: Secure Sockets Layer (SSL), Transport Layer Security (TLS), and IP Security (IPSec). Data privacy and data integrity are usually provided through encryption.

A Brief Overview of Public and Symmetric Key Cryptography

Cryptography is a set of standards and protocols for encoding data and messages, so that they can be stored and transmitted securely. The following introduces the basic terminology of cryptography and explains some of the common methods used.

• Cryptography allows you to achieve secure communications, even when the transmission medium (for example, the Internet) is untrustworthy. You can also use it to encrypt your sensitive files, so that an intruder cannot understand them.

• Cryptography can be used to ensure data integrity as well as to maintain secrecy.

• Cryptography makes it possible to verify the origin of data and messages, by using digital signatures and certificates.

• When you use cryptographic methods, the cryptographic keys must remain secret. The algorithms, key sizes, and file formats can be made public without compromising security.

The two fundamental operations of cryptography are encryption and decryption. Encryption involves scrambling the data in such a way that it becomes infeasible to deduce the original information, unless you have access to the appropriate key. Decryption is the reverse process scrambled data is turned into the original text by using a key.

In order to encrypt and decrypt, you need an encryption algorithm and a key. Many encryption algorithms exist, including Data Encryption Standard (DES), Rivest­Sharmir­Adleman (RSA) encryption, RC2, and RC5. A key is used in conjunction with the algorithm to convert the plaintext (readable by humans) into ciphertext (scrambled, unreadable by humans).

DES, RC2, and RC5 are known as symmetric key technology because the key used to encrypt the data is the same one used to decrypt it. Hence the key must be a shared secret between the party encrypting the data and the party decrypting it. You can use public key technology to pass the key securely to the other party.

RSA is known as public key, or asymmetric, technology, because two keys are used: a public and a private key. The keys are mathematically related, but it is infeasible to deduce one without knowing the other. The private key is kept private only the party generating the key pair should have access to it. The public key can be freely shared over an insecure medium such as the Internet.

With public key systems, there is no shared secret between the two parties. If the public key is used to encrypt the data, then only the private key can decrypt it. Similarly, if the private key is used to encrypt the data, then only the public key can decrypt it. The following scenario provides a simple example of how public keys are used.

A Public Key Scenario

In this scenario, Alice wants to send Bob a message, but she wants to make sure only Bob can read it. To do this, the following steps are performed:

• Alice gets a copy of Bob's public key, possibly from the directory, a Web site, or an e-mail message.

• She uses this key to encrypt the data.

• She sends the encrypted data to Bob. Because the data was encrypted using his public key, only his private key can be used to decrypt it.

• Bob uses his private key to decrypt the data, and reads Alice's message.

Secure Sockets Layer

The SSL protocol provides communications privacy, authentication, and message integrity by using a combination of public-key and symmetric encryption. By using this protocol, clients and servers can communicate in a way that prevents eavesdropping, tampering, or message forgery.

In the case of an SSL connection between a Web browser and Web server, you must enter HTTPS rather than HTTP as the protocol type in the URL. This will instruct the Web browser to use a different port for the communication; the Web server will be listening on this port for SSL requests. By default, Web data (HTTP) uses Transmission Control Protocol (TCP) port 80, while SSL (HTTPS) uses TCP port 443.

Transport Layer Security

TLS is very similar to SSL in that it provides communications privacy, authentication, and message integrity by using a combination of public-key and symmetric encryption. In fact, TLS supports the option of reverting to SSL support, if need be. However, there are some important differences. TLS supports different encryption algorithms than SSL and is an Internet Engineering Task Force (IETF) draft standard. Many people view TLS as the likely successor to SSL in the long term.

Because TLS is designed to be a replacement for SSL, using either protocol should be transparent to the user. However, the software must be TLS- and SSL-aware.

IP Security

IETF developed IPSec as the security protocol for Internet Protocol (IP). In fact, IPSec was designed for the next generation of IP, which is IPv6. However, IPSec can be used with the current implementation of IP, which is IPv4.

Note: One of the issues with Transmission Control Protocol/Internet Protocol (TCP/IP) is that it was not designed with security in mind; for example, TCP/IP does not accommodate authentication or privacy.

IP Security and Authentication

It is easy for an unauthorized user to spoof IP packets, that is, to make packets appear to have come from another destination. This is achieved by writing applications that build complete, but invalid, IP packets and then sending them to a target computer. The packets are invalid in that the source IP address is incorrect, does not exist, or is unreachable because of router settings. The target computer attempts to set up a connection with the unreachable source but fails, and in so doing (although the target will wait for a while to accommodate latencies in the network), the target must allocate memory for the connection anyway. If the system receives a large number of the invalid packets, the target will eventually run out of memory and probably stop responding. This is a denial-of-service attack.

IPSec can provide strong authentication of packet data in order to help alleviate many of these common spoofing attacks.

IP Security and Privacy

No data is encrypted at the TCP or IP layers; it is up to higher-level protocols such as SSL and TLS to perform this work. Because the data is unencrypted, it is very easy to gather important information like user names and passwords by sniffing the network. IPSec can encrypt data in order to help prevent data sniffing.

For more information about IPSec, see "Internet Protocol Security (IPSec)" in the Microsoft® Windows® 2000 Server Resource Kit TCP/IP Core Networking Guide.

When to Use SSL, TLS, or IPSec

At first glance it appears that Windows 2000 Server supports three protocols that do the same thing: provide authentication, data privacy, and data integrity. IPSec, which is lower in the network stack shown in Figure 9.3, secures all data flowing from one computer to another. Applications do not need to be modified to support IPSec, whereas they do need modification in order to support SSL and TLS. Refer to the TCP/IP books listed in "Additional Resources" at the end of this chapter.

In summary, SSL and TLS are easier to use than IPSec because there is no complex user setup, but applications need to be SSL- and TLS-aware. IPSec is more difficult to implement, but is totally transparent to all applications because it is lower in the network stack.

Figure 9.3 SSL, TLS, and IPSec in the TPC/IP Protocol Stack

Availability in Windows 2000 Server

A computer is available if its resources are accessible in a timely fashion. Denial-of-service attacks are designed to make a system unavailable by slowing it down, exhausting resources, or stopping it from running.

Windows 2000 Server has a number of features to support availability: most notably, NTFS disk quotas and clustering.

Windows NTFS Disk Quotas

Windows 2000 Server supports the use of disk quotas for NTFS disk volumes. You can use disk quotas to monitor and limit disk space use on a per-user, per-volume basis; users are charged only for the files they own.

If a malicious user could use up all available disk space on a Web server, this would either prevent the server from running correctly or prevent other users from being able to use the server. This malicious consumption of resources is a denial-of-service attack, of which quotas can help reduce the chance.

When you enable NTFS disk quotas, you set two values: a quota limit and a quota-warning threshold. The threshold specifies a warning disk space usage. Events are automatically logged in the Windows Event Log when users exceed these limits.

For example, you can limit a user's quota to 20 megabytes (MB) and the quota threshold to 18 MB. In this case, the user can store no more than 20 MB of files on the volume. If the user stores more than 18 MB of files, the quota system logs a system event as a warning.

Figure 9.4 Setting Default NTFS Disk Quotas

Using Disk Quotas with IIS 5.0

When using disk quotas in conjunction with IIS 5.0, you need to consider which authentication scheme you will use and how much disk space you will allot to each user.

For example, if your computer has two Web sites such as reskit.microsoft.com and reskit2.microsoft.com that map to two different directories, as shown in Table 9.1, you could configure each to have a different anonymous user account and then set quotas on these accounts:

Table 9.1 Examples of Disk Quotas

Site	Directory	Anonymous User Account	Disk Quota
reskit.microsoft.com	C:\InetPub\reskit	IUSR_reskit	Administrators: No Limit IUSR_reskit: 20Mb
reskit2.microsoft.com	C:\InetPub\reskit2	IUSR_reskit2	Administrators: No Limit IUSR_ reskit2: 10Mb

Clustering Service

A cluster is a group of independent systems that work together as a single system. A client interacts with a cluster as though it were a single server. Cluster configurations increase the availability of a system's resources. If a system or application in the cluster fails, the cluster software responds by restarting the failed application or dispersing the work from the failed system to the remaining systems in the cluster.

Microsoft® Windows® 2000 Advanced Server supports clustering. For more information about Clustering Service, see the documentation included with your Windows 2000 Advanced Server software.

Auditing in Windows 2000 Server

The Event Viewer in Windows 2000 provides auditing information. Windows can be configured to audit certain events (such as when users are logged on), when they access resources (such as files), or when they attempt to use special privileges (such as the ability to debug an application or perform a data backup).

Auditing can be turned on and off by using the Computer Management tool and by selecting System Tools/Group Policy/Computer Configuration/Windows Settings/Local Policies/Auditing Policies.

For a server running IIS 5.0, it is recommended you audit by using the following: "Audit Events," which is the event name you are interested in; "Audit success attempts," which indicates that you are interested in successful events; and "Audit failed attempts," which indicates that you are interested in failures when that event is performed. "On" means the event is being audited, while "off" means it is not. Table 9.2 provides examples for various events:

Table 9.2 Auditing Events in Windows 2000 Server

Audit Event	Audit Success Attempts	Audit Failed Attempts
Account Logon	On	On
Account Management	Off	On
Directory Service Access	Off	On
Logon	On	On
Object Access	Off	Off
Policy Change	On	On
Privilege Use	Off	On
Process Tracking	Off	Off
System	Off	Off

For example, it is quite normal to audit for successful and failed events You might want to see when users are logging on, as well as when people might be attempting to log on by guessing someone else's password.

Note that in Windows 2000 Server there are two types of logon/logoff events: Account Logon/Logoff and Logon/Logoff.

For an excellent summary of how to audit logon events, see "Auditing User Authentication" at https://support.microsoft.com/default.aspx?scid=kb;en-us;174073&sd=tech.

Configuring IIS 5.0 Security

This section covers the following topics:

• IIS 5.0 Authentication Modes

• Extending IIS 5.0 Security

• File and Directory Security

• Virtual Directory Security

• Secure Communications with SSL and TLS

• How Access is Determined

• Troubleshooting Permissions

IIS 5.0 Authentication Modes

All users must be authenticated before they can gain access to resources in IIS 5.0. Each HTTP request from a browser runs on IIS 5.0 in the security context of a user account on the Windows operating system. IIS 5.0 executes the request in a thread that impersonates the user's security context. An application, such as IIS 5.0, can have many simultaneous threads of execution internally, each acting on behalf of different users.

The operations that are performed during the execution of the HTTP request are limited by the capabilities granted to that user account in Windows. The user account needs to be created either on the IIS 5.0 server or in a domain of which the server running IIS 5.0 is a member. The latter is more common in intranet applications.

IIS 5.0 supports five Web authentication models:

• Anonymous

• Basic

• Integrated Windows authentication

• Digest

• Client Certificate Mapping

There are also two FTP authentication models:

• Anonymous

• Do Not Allow Anonymous

Before looking at each authentication scheme in detail, an explanation of Web authentication is necessary.

How Web Authentication Works

Web authentication is a communication between the browser and the server, involving a small number of HTTP headers and error messages.

The flow of communication is:

1. The Web browser makes a request (for example, an HTTP GET).

2. The Web server performs an authentication check. If this fails because authentication is required, then the server sends back an error message (usually a 401 Access Denied), along with information so that the Web browser can resubmit the request as an authenticated request.

3. The Web browser uses the server's response to construct a new request that contains authentication information.

4. The Web server performs an authentication check. If the check is successful, the server sends the data that was initially requested back to the Web browser.

Anonymous Web Authentication

The Windows operating system is configured to accept only valid users. Because the Internet is extremely anonymous in that very few Web sites prompt visitors for a user name and password IIS 5.0 creates the IUSR_computername account so that real Windows accounts can be used in an anonymous Internet. This account is granted to anonymous users who then use a random password, defined when IIS 5.0 is set up, on the local computer. This account gives anonymous users the right to log on locally. Anonymous user access can be reset to use any valid Windows account.

Note: With IIS 5.0 you can set up different anonymous accounts for different Web sites, virtual directories, directories, and files. This provides a great deal of flexibility and fine control, telling what accounts will be used where within the site.

If the computer running Windows is a stand-alone server, the IUSR_computername account is on the local server. If the server is a Domain Controller, the IUSR_computername account is defined for the domain.

Windows uses IUSR*_computername* when a user is authenticated by IIS 5.0 with Anonymous authentication. In other words, a real Windows user account is being used for all nontrusted anonymous access.

Figure 9.5 shows an example of what is entered into the Event Viewer in Windows 2000 when Anonymous authentication is used. Note that the logon process is performed by IIS 5.0 itself and that the logon is a network logon (the logon type is 3 in the audit log entry). This is because the Allow IIS to control password option is enabled. If this option were disabled, the logon would be interactive (the logon type would be 2 in the audit log entry).

Figure 9.5 Event Log Entry for an Anonymous Logon

Anonymous Authentication Header Flow

Figure 9.6 shows the flow of HTTP headers when using Anonymous authentication.

Figure 9.6 Anonymous Access to a Resource

Note: If there is a DACL conflict while trying to access the resource (for example, if the IUSR_computername account does not have access to Default.htm), the Web server will not return a 200 status. The status will be a 403, which prompts the user to enter a user name and password.

Anonymous Authentication and Allow IIS to Control Password

Prior to IIS 4.0, the administrator had to make sure the anonymous user account passwords were the same in both the Internet Services Manager tool and the Windows User Manager. Failure to do so led to logon failures. To solve this dilemma, Password Synchronization was introduced in IIS 4.0 in order to make administration easier.

Password Synchronization uses a slightly different logon method, which has some side effects that will be explained in detail later. By default, IIS password control is enabled. Figure 9.7 shows the password control option.

Figure 9.7 The IIS 5.0 Password Control Option

Allowing IIS 5.0 to Control the Anonymous Password

Authentication is performed differently when this option is enabled because IIS 5.0 has to inform Windows that the password is correct. A subauthenticator can perform this task. Windows allows subauthenticators implemented as subauthentication dynamic-link libraries (DLLs) to be used in conjunction with the normal Windows authentication system.

A subauthentication DLL allows the authentication and validation criteria stored in the Windows user account database to be replaced. For instance, a particular server might supply a subauthentication DLL that validates a user's password via a different algorithm, that uses a different granularity of logon hours, or that specifies workstation restrictions in a different format. All of this can be accomplished using subauthentication DLLs, without sacrificing use of the Windows user account database and thereby losing its administration tools.

IIS 5.0 supplies a subauthentication DLL called Iissuba.dll. The function of this DLL, in terms of Anonymous authentication, is to verify that the password is correct, inform the Windows operating system that the password is valid, and hence log on the user.

You can find more information about Windows subauthentication in the Microsoft® Visual Studio® 6.0 online product documentation. Visual Studio 6.0 ships with a subauthentication sample called SubAuth.

Not Allowing IIS to Control the Anonymous Password

When the password control option is not enabled, IIS 5.0 calls the LogonUser() Application Programming Interface (API) in Windows to log on the account. IIS passes in the user name and password configured by the administrator. If this matches the user name and password set up in Windows User Manager, the account is successfully logged on, the security token is cached by IIS 5.0, and the account is impersonated.

The Side Effect of Allowing IIS to Control the Anonymous Password

Subauthentication DLLs require a network logon, which can produce problems compared to a batch or interactive logon. The most notable is, in some cases, the inability to access resources such as files or Microsoft® Access databases on a network computer. If you see this problem, turn the password control option off; this will force IIS 5.0 to use normal authentication and to log the account on locally.

Basic Authentication

Basic authentication, part of the HTTP 1.0 specification, is the method supported by most Web servers and Web browsers. With Basic authentication, you can restrict access to files on the server that is running IIS 5.0, by using NTFS security. This requires the user to enter credentials, which allows tracking of who has access to what (based on the user ID). You can use this method in order to restrict access to some parts of the Web server when:

• You cannot guarantee that the user's browser supports integrated Windows authentication (Microsoft® Internet Explorer 2.0 or later supports this).

• You need to authenticate through a proxy server.

To use Basic authentication, grant each user account the Log on locally user right on the IIS 5.0 server. These accounts should have file access controlled; place them in a user group that has access only to the required files that are on the server.

When using Basic authentication, the browser prompts the user for a user name and password. This information is then transmitted across HTTP where it is lightly scrambled using Base64 encoding (You can get more information about Base64 encoding from the Internet standard RFC1521.) IIS 5.0 takes this user name and password and authenticates the user as the corresponding Windows user.

Keep the following in mind when using Basic authentication:

• Basic authentication will not succeed if the user doesn't have local logon rights at the Web server. This is the default; it can be changed to a network logon, for example, if you set the LogonMethod appropriately. Refer to the IIS 5.0 online product documentation or the Microsoft® Active Directory" Service Interfaces (ADSI) sample at the end of this chapter for more information about LogonMethod.

• A user who can obtain physical access to the host that is running the Web server will be permitted to start an interactive session at the computer. This is because the user has local logon rights. Be sure to set the appropriate NTFS file protections in order to control this.

Basic authentication is inherently insecure. Passwords are encoded but not securely encrypted. As a result, a simple network sniffer can watch for the HTTP authentication headers and Base64 decode this data to obtain the real password. Figure 9.8 shows an example of a network sniff.

Figure 9.8 Partial Network Trace of HTTP Basic Authentication

In the bottom line, shown in Figure 9.8, the Authorization header indicates the use of Basic authentication followed by some Base64 encoded data. If you were to decode the VGVzdFVzZXI6Tm9uZSE= string, you would find this is the TestUser account using a password of None! to access this Web server.

To make passwords more secure, and hence Basic authentication more secure, you can use SSL support in order to establish a secure session. This way, the password will still be encoded, but the HTTP session carrying the data will be encrypted using cryptographically-secure mechanisms. However, keep in mind that SSL negatively affects performance because all data in the requested page must be encrypted.

Basic Authentication Header Flow

Figure 9.9 shows the flow of HTTP headers when you use Basic authentication.

Figure 9.9 Basic Access to a Resource

Integrated Windows Authentication

Integrated Windows authentication formerly known as both NT LAN Manager (or NTLM) and Windows NT Challenge/Response authentication is more secure than Basic authentication. This authentication scheme works especially well in an intranet environment where users have Windows domain accounts.

In integrated Windows authentication, the browser attempts to use the current user's credentials from a domain logon. If those credentials are rejected, integrated Windows authentication will prompt the user for a user name and password by means of a dialog box. When integrated Windows authentication is used, the user's password is not passed from the client to the server. If a user has logged on as a domain user on a local computer, the user won't have to be authenticated again when accessing a network computer in that domain.

The user is not prompted for a user name and password for each HTTP request; rather, this will happen only when the cached credentials do not have sufficient permissions to access a specific page or file.

The Role of Negotiation

Prior to Windows 2000 Server, Windows security was limited to just NTLM, but now Windows 2000 Server supports both NTLM and Kerberos v5 authentication. In essence, integrated Windows authentication is NTLM or Kerberos v5. Rather than sending both an NTLM and Kerberos v5 challenge (random data produced by the server) to the client, Windows 2000 Server sends a Negotiate header. This allows the client and server to negotiate a suitable authentication protocol. A response (the challenge modified with user name and password information supplied by the client) is then sent.

Integrated Windows authentication has the following limitations:

• It cannot be performed through a firewall via a proxy.

• Currently, it is supported only by Microsoft® Internet Explorer 2.0 and later.

• It might not support delegation to other servers. In other words, the user's credentials cannot be passed on to another computer. For example, when a request comes in to IIS 5.0, the user account credentials cannot be passed to SQL Server on another Windows computer. However, this is only the case if NTLM is chosen as the authentication protocol during the negotiation phase; if integrated Windows Authentication is chosen, delegation is supported.

Integrated Windows Authentication Header Flow

Figure 9.10 shows the flow of HTTP headers when you use integrated Windows authentication.

Figure 9.10 Integrated Windows Access to a Resource

Digest Authentication

Digest authentication addresses many of the weaknesses of Basic authentication. Most notably, the password is not in clear text when you use Digest authentication. In addition, Digest authentication can work through proxy servers, unlike integrated Windows authentication.

At the time of this writing, digest authentication is not a completed standard; it is still a draft. The version of digest authentication used in IIS 5.0 follows RFC2069, with some extensions from the IETF draft specification that can be found at https://www.ietf.org/.

Because Digest authentication is a challenge/response mechanism like integrated Windows authentication, passwords are not sent unencrypted, as in Basic authentication.

How to Configure Digest Authentication

In order for you to correctly use Digest authentication, the following must be set up on the server:

• Windows 2000 Server must be in a domain.

• A file called IISUBA.DLL must be installed on the domain controller. This is copied automatically during Windows 2000 Server setup.

• All user accounts must be configured to have the Save password as encrypted clear text option enabled, as shown in Figure 9.11. This is an option on each user object in the Active Directory. Setting this option requires the password to be reset or re-entered.

IIS 5.0 must be configured to use Digest authentication. See Figure 9.12.

Figure 9.11 Setting the Save password as encrypted clear text Option

Figure 9.12 Setting IIS 5.0 to Support Digest Authentication

Digest Authentication Header Flow

Figure 9.13 shows the flow of HTTP headers when you use Digest authentication.

Figure 9.13 Digest Authentication Access to a Resource

Client Certificate Mapping

Traditionally, computer systems have used a centralized accounts database to manage users, their privileges, and their access controls. This technique has worked well and is readily understood. However, as systems become more and more distributed with hundreds of thousands to even millions of users this form of centralized control becomes unwieldy. The problem ranges from trying to verify an account against a database located on the other side of the Internet to administering a very large list of users.

Certificates can often simplify these problems. They can be widely distributed, issued by numerous parties, and verified by simply examining the certificate, without having to refer to a centralized database. Sometimes a server might need to refer to a central site in order to gather certificate revocation information, but this data is cached.

Existing operating systems and administration tools can only deal with accounts, not certificates. The simple solution one that maintains the advantages of both certificates and user accounts is to create an association (or mapping) between a certificate and a user account. This allows the operating system to continue using accounts, while the larger "system" and the user take advantage of certificates. In this model, a user presents a certificate; the system then looks at the mapping in order to determine which user account should be logged on. For more information about public key certificates, see "Public Key Infrastructure" in the Distributed Systems Guide.

Mapping a certificate to a Windows user account can be done in one of two ways:

1. With Microsoft® Active Directory" directory service.

2. With rules defined in IIS 5.0.

Note: Windows Active Directory Mapping and IIS 5.0 Native Mapping are mutually exclusive service-wide. You cannot use rules defined in one form of mapping in the other mapping form.

What Is a Client Certificate?

Client certificates contain information that identifies the user, as well as information about the organization that issued the certificate. For example, a standard X.509 certificate contains at least the following:

• Version

• Serial number

• Signature algorithm ID

• Issuer name

• Validity period

• Subject (user) name

• Subject public key information

• Signature on the fields just listed

Figure 9.14 shows an example of a client authentication certificate in Microsoft® Internet Explorer 5:

Figure 9.14 A Client Authentication Certificate

A user obtains a client certificate from a trusted third-party organization such as VeriSign ( https://www.verisign.com) or Thawte Consulting ( https://www.verisign.comhttps://www.thawte.com). These organizations are usually referred to as certification authorities or CAs.

If you have Microsoft® Windows® 2000 Certificate Services installed, your site can issue its own certificates to users on the intranet or to business partners.

A Brief Overview of Certificate Services

The role of Certificate Services is to issue and manage certificates, which are used in software security systems that employ public key technologies.

The role of Certificate Services is to create a CA that receives certificate requests from clients and servers, verifies the information in the request, and issues a corresponding X.509 certificate. The Certificate Services Manager administration tool enables you to administer Certificate Services.

The CA receives requests for new certificates over transports such as HTTP or e-mail. It then checks each request against predefined policies, sets optional properties for the certificate, and issues the certificate. With Certificate Services, administrators can add certificates to a Certificate Revocation List (CRL), as well as publish a signed CRL to a published file share or to the Active Directory on a regular basis.

Certificate Services supports issuing certificates for Secure/Multipurpose Internet Mail Extensions (S/MIME), and digital signatures for use in SSL and TLS.

Programmable interfaces are included, so developers can create support for additional transports, policies, and certificate properties and formats.

A Quick Detour: X.509, DER, PKCS Explained

You'll notice references to X.509, Distinguished Encoding Rules (DER) encoding, (Public Key Cryptography Standards) PKCS #7, and Base64 when you use or administer certificate-based solutions.

X.509 is the industry-standard certificate type. You can find more information at https://www.ietf.org/rfc/rfc2459.txt.

DER is a binary encoding format for certificates.

PKCS #7, developed by RSA Data Security, is a binary format for defining encrypted and signed data, such as certificates. You can find more information at https://www.rsasecurity.com/rsalabs/node.asp?id=2129.

Base64 encoding is a text-based encoding system for binary data. It is the same coding scheme used in Basic authentication, and is defined in the Internet standard RFC1521.

IIS 5.0 Native Mapping

IIS 5.0 mapping is similar to the mapping capability that shipped with IIS 4.0. It allows the administrator to set up a rule or group of rules that determine how a client authentication certificate is mapped to a Windows user account, without requiring the use of Basic or any other form of authentication. There are two possible IIS 5.0 native mapping modes: one­to­one and many-to-one.

One-to-One Mapping

In one-to-one mapping, the administrator selects the client authentication certificate for mapping and enters the user name and password associated with the certificate. The form displayed on the client certificate in Figure 9.15 is Base64 encoded X.509. This is a standard client authentication certificate that is encoded using Base64, rather than binary. Base64 encoding enables older e-mail servers to handle the data easily, since many older e­mail servers cannot relay binary data.

Figure 9.15 Using the Certificate Manager Export Wizard to Export a Client Authentication Certificate

You can also access a user's client authentication certificate from the Active Directory, as shown in Figure 9.16. A client authentication certificate is an optional UserCertificate property on the User object. The following Visual Basic code will access the UserCertificate object:

Dim oUser, vCert 
Dim strName, strDN 
StrName = "CN=Baggins" 
StrDN = "CN=Users,DC=iis,DC=nttest,DC=microsoft,DC=com" 
Set oUser = GetObject("LDAP://" & strName & "," & strDN) 
vCert = oUser.userCertificate 
Set oUser = Nothing 

You can set a user's client authentication certificate by using the Directory Management administration tool. If Certificate Services is installed in the enterprise, the certificate is automatically added to the user's list of certificates in the Active Directory, when the client requests a certificate.

Figure 9.16 A User's Client Authentication Certificate in the Active Directory

Note: To view or add a user's client authentication certificate in the Active Directory user interface, you must have Advanced Features enabled. To do this, load the Directory Management administration tool, select View and check the Advanced Features option.

Many-to-One Mapping

Many-to-one mapping is the mapping of many certificates to a single user account. For example, assume you have a partnership with an agency that provides temporary workers for your job openings. You would like to allow the agency personnel to view Web pages describing current job openings that are otherwise accessible only to company employees. The agency has its own trusted CA that it uses to issue certificates to its employees. After installing the agency CA's root certificate (a certificate at the top of the certification hierarchy) that is trusted in your enterprise, you can set a rule that maps all certificates issued by that CA to a single Windows account. You then set NTFS access rights so that the account can access the Web pages. Typically, you will choose a Windows account name that reflects the role or company name of the trusted company, for example TempAgency.

Now, when employees from the agency connect to the agency's Web server and provide their certificates, they are mapped to the same account and can access those pages and no others. This is nice from an administrative viewpoint because the agency can now issue certificates and manage its users, without requiring you to do any more work.

Windows Active Directory Mapping

A Windows 2000 Active Directory installation automatically sets up one-to-one mappings for the certificates it issues. Any logon certificate should automatically be mapped to the account it represents.

If you wish to perform many-to-one mapping or use a CA other than Certificate Services, you will need to use the Name Mappings option in the Active Directory management tool. For more information, refer to the Windows documentation.

Certificate Trust Lists

When using certificate mapping you will need to configure IIS 5.0 to only trust a limited number of CAs. In Windows 2000 Server and IIS 5.0, this is performed through certificate trust lists (CTLs).

A CTL is a set of certificates determined as trustworthy by an administrator. For a client authentication certificate to be used successfully, it must be signed (issued) by a trusted CA listed in the CTL.

For example, if you only trusted certain certificates issued by two CAs, such as ExplorationAir Corp. CA and VeriSign, then you could define a CTL that only lists these CAs. If a user attempts to connect to your Web server using a client authentication certificate issued by any other CA, access will be denied.

Caching and the Windows Audit Log

By default, IIS 5.0 caches security tokens for accounts that are logged on locally, such as IUSR_computername. You might not see multiple logon entries in the audit logs because the token is already accessible to IIS 5.0. The default cache time is 15 minutes.

The following ADSI code, callable from Visual Basic, Microsoft® Windows® Script Host (WSH), or Active Server Pages (ASP), will change the cache time for the default Web server (Web server 1), on a computer called Baggins, to two minutes.

Dim oIIS 
Set oIIS = GetObject("IIS://Baggins/W3SVC/1") 
oIIS.PasswordCacheTTL = 2 
oIIS.SetInfo 
Set oIIS = Nothing 

Web Authentication Summary

Table 9.3 shows a brief summary of all the possible Web authentication schemes built into IIS 5.0:

Table 9.3 Web Authentication Schemes in IIS 5.0

Scheme	Requires SSL	Works with Internet Explorer 4	Works with Internet Explorer 5	Works with Other Browsers	Comment
Anonymous	No	Yes	Yes	Yes	No authentication
Basic	No	Yes	Yes	Yes	Insecure: consider using SSL to protect user name/password
Integrated Windows	No	Yes	Yes	No	Does not work through proxy servers
Digest	No	No	Yes	Varies	Requires Active Directory
Certificate Mapping	Yes	Yes	Yes	Varies	Very scalable and secure, but a little cumbersome to configure

FTP Authentication

Users must log on in order to gain access to the FTP server. The IIS 5.0 FTP services can use the Windows account database to authenticate users logging on. However, all FTP transmissions are in clear text, thus exposing user names and passwords, as seen in Figure 9.17.

Figure 9.17 Two Packets of FTP Data, Showing the User Name and Password in Clear Text

In order to eliminate exposed passwords, you can configure your FTP server to permit anonymous logons. This type of logon requires the user to type "anonymous" as the user name and the user's Internet e-mail address as the password. Anonymous users can gain access to files under the IUSR_computername account.

You can also allow anonymous-only logons to the FTP service. Anonymous-only logons are useful because they prevent real passwords from being revealed on a public network. In IIS 5.0, the FTP service is configured for anonymous-only access by default.

Extending IIS 5.0 Security

Although it is possible to extend IIS 5.0 security schemes by using Internet Server Application Programming Interface (ISAPI) filters, ASP pages, or Microsoft® Component Object Model (COM) components, you should seriously consider the tradeoffs.

The advantage of using alternate authentication mechanisms is flexibility; if you write your own authentication code, you have complete control of those mechanisms. For example, you might decide to check the existence of a user account in an online database.

The disadvantage is that you now have security policy and enforcement in multiple places. If you update your corporate security policy, such as who is allowed access to what resources, then you may need to update the Web server as well. Eventually, this will become difficult to maintain and could lead to security vulnerabilities.

Extending IIS 5.0 Security with ISAPI Filters

The most common way to extend IIS 5.0 security is to use ISAPI filters. These allow you to receive notifications of various events, such as authentication, during the processing of HTTP requests. Filters, implemented as DLLs, are loaded when you start IIS 5.0, and are kept in memory until you shut down IIS 5.0. Once a filter is loaded, it indicates the events that IIS 5.0 should send notification about. Subsequently, IIS 5.0 will notify the filter each time one of the registered events occurs.

If you want to write an ISAPI filter in order to perform authentication, you will need to review the SF_Notify_Authentication event in the IIS 5.0 online product documentation.

Extending IIS 5.0 Security with ASP Code

You can also create custom security schemes by using ASP code. For example, you could programmatically deny access to a page with the following code used as part of a POST. In this example, the original page prompted the user to enter a user name and password in a FORM:

<%  
Dim strName, strPassword 
strName = Request.Form("Name") 
strPassword = Request.Form("Password") 
'Do a database lookup and set fAllowAccess based on the query. 
If fAllowAccess = False Then 
Response.AddHeader("401   Access Denied") 
End If 
%> 

The assumption in this case is that there is a database with user names and passwords, which are both used as the basis to perform the security check.

Please note that this mechanism is very insecure. First, you must POST the data over a secure channel by using SSL; otherwise, intruders might be able to gather the user name and password as it goes in plaintext from the browser to the Web server. Also, if this page is circumvented, no access check can be performed whatsoever.

File and Directory Security

IIS 5.0 uses Windows 2000 Server security throughout, including DACLs in the Windows File System, NTFS. It is recommended that you place your data files on an NTFS partition because NTFS provides security and access control for your data files.

DACLs grant or deny access to the associated file or folder by specific Windows 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.

You can use IIS 5.0 virtual directory access control combined with Windows accounts and NTFS file ACLs in order to configure access to specific files within a Web site. After a user is authenticated for the IIS 5.0 virtual directory, IIS uses the context of the requesting user (Anonymous or specific) to gain access to the NTFS file based on the user account, user rights policy, and file permissions.

It is possible to use the Windows Interactive user and Network user accounts in order to provide broad access control for files available to IIS 5.0. The Interactive user is a special user account representing any user who is logged on interactively. In other words, this is someone who has the Log on locally privilege and has been logged on locally. The Network user account is similar, but applies to users with the Network logon privilege.

• If the Interactive user is given Special (Read) permission for a file, the anonymous user (if Allow IIS to control password is disabled) or any client authenticated by Basic authentication will be able to access the file. This is because these accounts are being logged on locally (in other words, they are interactive).

• If the Network user is given Special (Read) permission for a file, the anonymous user (if Allow IIS to control password is enabled) or any client authenticated by Digest authentication or integrated Windows authentication will be able to gain access to the file. This is because these accounts are logged on as network accounts.

Directories Containing DLLs Needed by the System

Since programs are usually made up of an executable and many DLLs, you must be able to execute the DLLs as well as the main executable. Set directories and files to Read (RX) access for the IUSR_computername account and for all accounts that have specific authentication for the following directories:

• %WinDir%\System32 (and all subdirectories)

• \Program Files\Common Files (and all subdirectories)

Directories Corresponding to Web Virtual Directories

• Special (R): If the directory contains only static .htm or .asp files.

• Special (X): If the directory contains only executable files (for example, .dll).

• Read (RX): If the directory is a mix of readable and executable files.

• Special (RW): If the directory contains a file database (for example, .mdb).

• Change (RWXD): If developers need to be able to modify or delete the files. (This is not recommended due to the security risk.)

You will need to set different permissions on files for individual users, depending on the authentication schemes you use:

• IUSR_computername: If Anonymous access is being used.

• Interactive: If you are allowing access to all users authenticated by Basic authentication and if the default logon method is Log on locally.

• Network: If you are allowing access to all users authenticated by integrated Windows authentication or Digest authentication.

• Specific users and groups: Ensure that they have the correct user rights profiles.

  Note: If you are not using the server for any other file access, restrict access to all files to only Administrators, System, and in less secure environments Power Users.

Virtual Directory Security

In order to publish from any directory not contained within your home directory, create a virtual directory. A virtual directory is a directory that is not contained in the home directory, but which appears to client browsers as though it were. Virtual directories have a small number of options for controlling access and content control:

• Read

• Write

• Log Access

• Directory Browsing

• Index This Directory

• Microsoft® FrontPage® Web (Web site only)

The default settings are Read, Log Access, Index This Directory, and FrontPage Web (for a Web site only).

Note: Write access can be performed only with a browser that supports the PUT feature of the HTTP 1.1 protocol standard.

IIS also supports application settings that determine how executable content such as ASP pages operate. The three options are:

• None: Doesn't allow any programs or scripts to run in this directory.

• Script: Enables applications mapped to a script engine to run in this directory, without having the Execute permission set. Use Script permission for directories that contain scripts in ASP pages, Internet Database Connector (IDC) scripts, or other scripts. Script permission is safer than Execute permission because you can limit the applications that can be run in the directory.

• Execute: Allows any application to run in this directory, including applications mapped to script engines and Windows binaries (.dll and .exe files). It is suggested that you use this option with care.

If a virtual directory is on an NTFS drive, the settings for the directory must match these application settings. If they don't, the most restrictive settings take effect. For example, if you give a directory Write permission but only give a particular user group Read access permissions in NTFS, the user group will not be able to write files to the directory because the Read permission is more restrictive.

Using the Permissions Wizard

The combination of NTFS DACLs and Web Permissions can be somewhat daunting at first. The Permissions Wizard in IIS 5.0 allows you to set the root of a virtual server to a known state, thus alleviating you of most of the burden. The wizard does this by asking questions and setting all the appropriate permissions based on your answers. If you still have problems accessing your site, you might need to troubleshoot your permissions.

Accessing Resources on Network Servers

Windows NT 4.0 does not allow delegation of security credentials. That is, it does not allow a server to pass your security information onto another server. Windows 2000 Server, in contrast, allows credential delegation in certain situations.

A common scenario is when IIS 5.0 is trying to access a resource on a network server such as an Access database while using integrated Windows authentication, Anonymous, or Basic authentication, regardless of particular DACL issues. See Figure 9.18.

Figure 9.18 Accessing a Remote Access Database from a Browser

Table 9.4 shows which authentication protocols allow access to remote resources:

Table 9.4 Authentication Protocols That Can Access Remote Resources

Protocol	Access Remote Resource?	Comment
Anonymous (IIS control password enabled)	No	Windows subauthentication DLL does not allow this.
Anonymous (IIS control password disabled)	Yes	Can make one "hop" onto a remote server.
Basic	Yes	Can make one "hop" onto a remote server.
Integrated Windows	Depends	No, if NTLM is used; yes, if the Kerberos v5 authentication protocol is used. If Kerberos v5 is used throughout, then the request can be fully delegated to many remote servers.
Digest	No	Windows subauthentication DLL does not allow this.
Certificate Mapping (IIS 5.0 mapper)	Yes	Can make one "hop" onto a remote server.
Certificate Mapping (Windows Mapper)	No	Windows mapping does not allow access to the user's password, so the password cannot be delegated.

Trusted for Delegation

To allow delegation of security credentials, you must also set the Computer is trusted for delegation option on each computer that will be used by the Web application.

To set the Computer is trusted for delegation option

1. On the Tools menu, click Active Directory Users and Computers.

2. Click the domain name node to expand it.

3. Click the Computers node to expand it.

4. Right-click on the computer in question.

5. Select Properties*.*

6. Select Computer is trusted for delegation.

Perform these steps on the Domain Controllers node also.

You can override this option on a per-user account basis. For example, it is considered bad security practice to enable account delegation for the Administrator account, because this account is a highly trusted account.

To override the Computer is trusted for delegation option

1. On the Tools menu, click Active Directory Manager.

2. Click the Users node to expand it.

3. Right-click on the user account in question.

4. Select Properties.

5. Click the Account tab.

6. Deselect Account is sensitive, do not delegate in the Account options.

Pass-through to UNC-Shared Web Content

In IIS 5.0 you can set the location of a virtual directory to be on a network computer by using a UNC (Uniform Naming Convention) name such as \\MyServer\WebDocs. See Figure 9.19. (Due to delegation issues in IIS 4.0, you had to provide a user name and password in order to connect to the remote share.)

Figure 9.19 Setting the User Name/Password to Access Web Content on a UNC resource

This method has some limitations; most notably you cannot use DACLs correctly on the network share. This is because you are essentially using the user account provided in the IIS 5.0 administration tools and not the real user account in order to access the network resource.

IIS 5.0 introduces the ability to pass user information through user accounts, if the underlying authentication scheme supports credential delegation. However, this ability is not in the user interface. The following script will allow user credentials to be passed through to the remote resource on a virtual directory called Content located on the default Web server:

Dim oVdir 
Set oVdir = GetObject("IIS://localhost/W3SVC/1/Root/Content") 
oVdir.UNCAuthenticationPassThrough = True 
oVdir.SetInfo 
Set oVdir = Nothing 

See Table 9.3 for a list of authentication schemes and whether they will support delegation. If this pass-through option is set and if the authentication scheme you use does not support delegation, the account defined in the Network Directory Security Credentials is used instead.

Secure Communications with SSL and TLS

As previously mentioned, SSL and TLS are ways means to authenticate, detect tampering, and encrypt communication between a server and a client. IIS 5.0 will attempt to use TLS before attempting to use SSL, because it is more secure.

In order to use SSL or TLS, the Web server must have a server authentication certificate issued by a trusted CA.

Authentication and Trust

Checking that the server's certificate is valid and was issued by a trusted CA gives a high degree of confidence that the server you are communicating with is the correct one. Trusted in this case means trusted by both the server and the client.

You trust the third-party CA if you have the issuer's root certificate in your client software, such as your browser. For example, if the server you wish to communicate with has a certificate issued by VeriSign, then you must have the appropriate VeriSign root certificate in your browser.

To check for root certificates

1. Open Internet Explorer.

2. On the Tools menu, select Internet Options.

3. Click the Content tab.

4. Click the Certificate button.

5. Select the Trusted Root Certification Authorities tab.

You will then see a list of company root certificates. This list determines which CAs you trust.

Note: If you do not trust or do not recognize a company named in this list, you should remove the certificate.

Encryption

Various cryptographic algorithms provide tamper detection and encryption; SSL and TLS can use protocols such as RC2, RC4, DES, 3DES, SkipJack and IDEA for encryption, and MD5 or SHA1 for tamper detection. For more information about these encryption protocols, see the books mentioned in "Additional Resources" at the end of this chapter. For more information about SSL and TLS, see https://www.ietf.org/ids.by.wg/tls.html.

Enabling SSL

In the context of a Web server, SSL is most effectively used when encrypting only communications that contain private data, such as credit card numbers, phone numbers, or company records. Because SSL uses complex encryption, and because encryption requires considerable processor resources, it takes much longer to retrieve and send data from SSL-enabled directories. Therefore, you should place only those pages that will contain or receive sensitive information into your SSL-enabled directory. Also, keep the pages free of elements that consume resources, such as images.

To use SSL on IIS 5.0

1. Request and install a server certificate. You can acquire a server certificate from a trusted third party such as VeriSign, or from Certificate Services by using the Web Server Certificate Wizard in IIS 5.0 to request a server certificate. (Web Server Certificate Wizard is the replacement for Key Manager in previous versions of IIS.)

2. Enable the appropriate settings in the Secure Communications dialog box. This dialog box will not appear unless you have a server certificate installed.

   Note: When requesting a certificate from Certificate Services, you must decide whether you want the private key to be exportable or not. (The Web Server Certificate Wizard in IIS marks the keys as exportable.)

   If you want to be able to back up your key, you must have an exportable private key. However, an exportable key is sometimes viewed as a security risk because the key could be compromised, and having access to the private key means an attacker can pose as the real user.

A Web server can only have one server certificate assigned to it. For example, reskit.microsoft.com can have a certificate labeled reskit.microsoft.com; it cannot have another certificate labeled reskit-10.microsoft.com. This is because a certificate is an identity and a Web server, just as a real person cannot have more than one identity.

IIS 5.0, SSL, and Fortezza

Fortezza® is a registered trademark of the National Security Agency (NSA). It describes a family of computer security products, most notably PCMCIA-based cryptography cards, designed to meet the needs of U.S. federal agencies.

Fortezza is a piece of a broader Microsoft® Federal Security Initiative. Through this initiative, Microsoft is demonstrating its commitment to meeting the ongoing security needs of its federal customers.

Like many other forms of encryption technology in the Windows operating system, Fortezza is implemented as a Cryptography API Security Provider (CSP). However, this CSP does not ship with Windows 2000 Server or IIS 5.0, but it is available from https://www.spyrus.com.

Configuring IIS 5.0 and Fortezza

SSL has a Fortezza mode that is of benefit to IIS 5.0. All Fortezza cards (PCMCIA cards) contain user certificates that authenticate the card user in much the same way that server or client certificates work in IIS 5.0. These user certificates must be copied over to a secure store on the computer where the card logs on. This makes the certificates available to IIS 5.0. In order to configure IIS 5.0 to use Fortezza, you must be using a domestic version of Windows 2000 Server.

To configure IIS 5.0 for Fortezza

1. Install the card reading equipment and its drivers. For information, see the card reader documentation.

2. Install the Cryptographic API Service Provider (CSP) provided by the equipment supplier. For information, see the card reader documentation.

3. Run the command line utility %windir%\system32\inetsrv\Fortutil.exe.

The Fortutil.exe utility provides functions that can install, confirm, and delete the card certificate and other associated information. To enable these features, type the appropriate commands at the command line, as shown in Table 9.5:

Table 9.5 Commands for Enabling Fortutil.exe Features

Action	Command	Parameters
Add Certificate	Fortutil /a	Web site name; card serial number; PIN; card personality
Confirm Certificate	Fortutil /q	Web site name
Delete Certificate	Fortutil /d	Web site name
Get Help	Fortutil /?	None

Certificate Revocation Lists

A CRL (often pronounced "KRILL") is a list of certificates that have been revoked before their scheduled expiration date. A certificate might need to be revoked if its associated private key has been compromised, or if the user no longer works for the company in question.

You can configure Internet Explorer 5 and IIS 5.0 to check CRLs.

To enable CRL-checking in Internet Explorer 5

1. On the Tools menu, select the Internet Options menu option.

2. Select the Advanced tab.

3. Click the Security node to expand it.

4. Check the Check for server certificate revocation option.

CRL-Checking in IIS 5.0

CRL-checking is enabled in IIS 5.0 by default. The following Visual Basic code shows how to enable or disable CRL-checking on the default Web server.

Set oIIS = GetObject("IIS://localhost/W3SVC/1") 
oIIS.CertCheckCRL = True ' False to disable CRL checking 
oIIS.SetInfo 
Set oIIS = Nothing 

Certificates and CryptoAPI

Unlike previous versions of IIS, IIS 5.0 uses Microsoft® CryptoAPI (CAPI) 2.0 for all encryption and certificate functions. You can use all the certificate tools that are built into Windows 2000 Server in order to perform routine certificate work.

For normal SSL/TLS work, the server certificates are stored in the Local Computer certificate store. For Fortezza, the certificate is held on the PCMCIA card (and then copied to the local computer using Fortutil.exe).

For more information about CryptoAPI, see https://www.microsoft.com/security/default.asp.

How to Back Up Your Web Server Certificate

Because IIS 5.0 leverages Windows security and security tools, you can use the Certificate Manager tool in Windows 2000 Server to export your IIS 5.0 certificates. Historically, the Key Manager tool performed a backup; however, Key Manager is no longer used by IIS 5.0.

First you need to make sure you are looking at the correct Local Computer certificate store. If you are not, you will have to set this up before you can export certificates.

To view the correct certificate store

1. Open Microsoft® Management Console.

2. Select the Add/Remove Snap-in option on the Console menu.

3. Click Add.

4. Select the Certificate Manager tool.

5. Click Add.

6. Select the Computer account option.

7. Select the Local computer option.

8. Click Finish, Close, then OK.

You are now looking at the correct certificate store.

To export a certificate

1. Click the Certificate Manager (Local Computer) node to expand it.

2. Click the Personal node to expand it, and then expand the Certificates node.

3. Right-click the certificate in question.

4. Select Export from the All tasks menu option.

5. Click Next.

6. Select Yes to export the private key.

7. Choose the PKCS #12 format and enable strong encryption.

8. Type and confirm your password.

9. Enter a file name.

10. Click Next, then click Finish.

How to Restore Your Web Server Certificate

You can restore certificates by simply double-clicking the PKCS #12 certificate file just created.

How Access Is Determined

When a user attempts to access a resource through IIS 5.0, a number of technologies come into play. Figure 9.20 provides an overview of this process:

Figure 9.20 IIS 5.0 Access Logic

In the interest of simplicity, Figure 9.20 shows many paths leading to Access Denied. In fact, some paths yield a 401 or 403 HTTP error. A real Access Denied message can prompt the user to re-enter the user name and password; a 401 or 403 cannot.

IP Address Access Control

IIS 5.0 can be configured to grant or deny access to specific IP addresses. For example, you can prevent a company or individual from accessing your site by listing the appropriate IP address, IP address range, or Domain Name System (DNS) name (IIS 5.0 checks the IP address first, then the DNS name). You can even prevent entire networks from gaining access to your server. Conversely, you can allow only specific sites or IP addresses to have access to your service.

If IIS 5.0 is configured to allow access by all IP addresses except those listed as exceptions to that rule, then access is denied to any computer with an IP address included in that list. Conversely, if IIS 5.0 is configured to deny all IP addresses, access is denied to all remote users except those whose IP addresses have been specifically granted access. IP address access restrictions are available for each of the IIS 5.0 services.

When controlling access by IP address, be aware that many Web users will be passing through a proxy server or a firewall. The incoming connection to your Web server will appear to have originated from the proxy server or firewall itself (in other words, the IP address of the originator will be that of the proxy server or firewall). This might be useful in a corporate network as an added security measure, in order to prevent access by anyone from outside your IP address domain.

User Access Control

There are five criteria for a successful logon:

• Valid user name and password supplied

• Windows account restrictions, such as time of day allowed to log on

• Account is not disabled or locked out

• Account password has not expired

• The applicable logon policy (for example, Log on locally or Access this computer from the Network)

By default, on a server running Windows, ordinary users (in other words, those who don't belong to the Administrator group) do not have the Log on locally user right. If FTP or WWW Basic Authentication is used, IIS 5.0 attempts to log on the user as a local user by default.

IIS 5.0 Access Control

Once a user has been granted access, the server examines both the URL and the type of request. It then checks the permissions and the SSL Client Authentication Certificate.

For WWW service, the request can indicate a Read, Write, Execute, or Script action. The applicable WWW virtual directory must have the appropriate permission enabled. Otherwise, the WWW service returns a "403.x: Access Forbidden" error, where "x" represents the type of access attempted.

IIS 5.0 might require a valid client authentication certificate before access to a resource is permitted. If such a certificate is not passed to the server, IIS 5.0 will return a "403.7: Forbidden client certificate required" error.

Also note that the certificate might not be valid. For example, it could have expired, or the CA that issued the certificate might not be trusted.

Custom Authentication

Custom authentication means that you must create your own authentication mechanisms such as ISAPI authentication filters, ASP pages, or Common Gateway Interface (CGI) applications. The techniques involved with creating custom authentication schemes are many, varied, and thus beyond the scope of this chapter.

NTFS File System Permissions

IIS 5.0 attempts to gain access to the specified resource (usually a file) by using the security context of the authenticated user. For anonymous access, this is typically the IUSR*_computername* account. If authentication has been performed, it will be a valid Windows user account.

Troubleshooting Permissions

As you can see, access to resources such as files and databases can be a complex issue when you are securing your Web server. Site administrators often work blindly when trying to troubleshoot access problems. Monitoring how the server is being used is a good place to start, which requires you to set up auditing.

The following outlines how to set up auditing and logging for troubleshooting.

To set up auditing for user logons and file access

1. Open the Global Policy Editor for the computer or domain in question.

2. Go to Computer Configuration, Windows Settings, Security Settings, Local Policies and then Audit Policy.

3. Set Audit successful attempts and Audit failed attempts to Yes under the Audit Logon Events category.

4. Set Audit failed attempts to Yes under the Audit Object Access category.

To choose the file to audit

1. Open Windows Explorer.

2. Select the file or folder that you want to audit.

3. Right-click the file or folder and select Properties.

4. Click the Security tab and the Advanced button, and then click the Auditing button.

5. Click the Add button.

6. Select Everyone, click Add, and then click OK.

   Select Successful and Failed for the following:

   • Traverse folder/Execute file

   • List folder/Read data

   • Create files/Write data

7. Click OK.

Much of this process is shown in Figure 9.21.

Figure 9.21 Auditing Access to a Single File

To enable Web Logging

1. Open the Computer Management administration tool.

2. Click Server Applicationsand Services to expand it and click IIS 5.0 to do the same.

3. Select the Web server in question.

4. Right-click on the Web site and select Properties.

5. Select Enable Logging.

6. Click the Properties button.

7. Click the Extended Properties tab.

8. Select (at least) the following: Date, Time, Client IP Address, User Name, Method, HTTP status, and Win32 status.

9. Click OK to exit the logging properties.

10. Click OK to exit the Web site properties.

11. Now that basic auditing is in place, clear any cached logon information (remember, for performance purposes IIS 5.0 can cache logon information) by typing the following at the command prompt:

    NET STOP IISADMIN /Y This stops all IIS 5.0 services.

    NET START W3SVC This starts the Web service, if installed.

    NET START MSFTPSVC This starts the File Transfer Protocol (FTP) service, if installed.

    NET START NNTPSVC This starts the Network News Transfer Protocol (NNTP) service, if installed.

    NET START SMTPSVC This starts the Simple Mail Transfer Protocol (SMTP) service, if installed.

12. Open the Event Viewer.

13. Clear the Security log by right-clicking the Security log and selecting Clear all events.

Troubleshooting the Web Server

After all these steps have been performed, try to access the resource from a browser. If you refresh the security log in the Event Viewer, a series of audited events will be listed. Examine the security log entries and answer these questions:

• Are there any access-denied errors in the audit log?

• What account is being logged on? Is it what you expected?

• Does this account have access to the file in question? You can check this by looking at the file access entries in the audit log.

• Does this account have the correct privilege to log on (Log on locally or network logon)?

• Does this account have a deny-logon privilege (for example deny logon locally or deny network logon)?

• Are there any 401s or 403s in the W3C log? If so, why are they there?

The following are some tips regarding permissions and IIS 5.0:

• If Anonymous authentication is turned on, this will usually be used before other authentication schemes.

• If Anonymous authentication is turned on and the IUSR_computername account is not allowed access to the resource in question, you might see a user name/password dialog box appear in the browser.

• If you are using Anonymous authentication, check whether the anonymous account is valid (correct password and logon times) and enabled. Right-click the virtual server in question, and select Properties, Directory Security, Anonymous Access and Authentication Control, Edit, and Edit.

• If you are accessing data from within an ASP file, the account being used must have access to the Microsoft® ActiveX® Date Objects (ADO) and ODBC directories.

• If you are using a page count component or a component that accesses files or the registry, the account logging on must have write and possibly delete access to the file or registry entry that it uses to persist its count.

• Any account used for Anonymous authentication when Allow IIS to control password is disabled must have the Log on locally privilege.

• Any account used for Anonymous authentication when Allow IIS to control password is enabled must have the Network logon privilege.

• Any account used for Basic authentication must have the Log on locally privilege.

• Any account used for integrated Windows authentication or Digest authentication must have the Network logon privilege.

• You can change the privilege type in the items just mentioned to Batch or Network, by using the LogonMethod ADSI property. The following ADSI code snippet shows how to do this:

Dim oIIS Const LOGON_LOCAL = 0x0 Const LOGON_BATCH = 0x1 Const LOGON_NETWORK = 0x2 Set oIIS = GetObject("IIS://Baggins/W3SVC/1") oIIS. LogonMethod = LOGON_BATCH oIIS.SetInfo Set oIIS=Nothing

• Accessing a network computer from an IIS 5.0 computer might fail, because Windows 2000 Server might not be configured to pass the user's security information to the other computer. To verify the configuration, perform the auditing steps (listed earlier) on the network computer in question, as well as on the IIS 5.0 computer.

• Microsoft® Internet Explorer 4.0 or later can be configured to support only certain authentication protocols. You can set these protocols by going to the Edit (Internet Explorer 4.0) or Tools (Internet Explorer 5) menu and selecting Internet Properties, Security, Custom, Settings, and UserAuthentication. If you select AnonymousLogon, the browser will not support any authentication schemes other than Anonymous.

• Check the IP and Domain Restrictions. Right-click the virtual server in question, and select Properties, Directory Security, IP Address and Domain Name Restrictions, and Edit.

• If you are using <!-- #include --!> statements, errors might be caused, since access is denied on the included file, but not on the main file. For example, if Default.asp includes Tools.asp, but Tools.asp has a restrictive DACL, an error may be reported on Default.asp, even though the logged-on account has access to it. To check for this, you might wish to temporarily comment out #include statements until you have successfully resolved the situation.

An End-to-End Troubleshooting Example

In the following scenario, a travel site called Exploration Air has developed a Web-based employee benefits application that uses IIS 5.0. The application can be accessed from the Internet and corporate intranet. Because the application is open to the Internet, security must be high.

All employees are validated before gaining access to the server and all data is encrypted to prevent people from "sniffing" the data as it moves across the Internet. The benefits application in this scenario deals with medical, dental, and legal assistance, as well as stock options, stock purchase plans, investment, and relocation benefits.

To access these resources, the Web application requires data from several sources:

• A Microsoft® SQL Server 7.0 database that contains all the corporate online benefits data. This is a complex database schema including 181 tables, 27 stored procedures, and 12 triggers. The database is approximately 6.5 gigabytes (GB) in size and grows about 250 MB per month.

• A legacy Oracle database on UNIX that contains the original Human Resources information, including payroll. For the purposes of this application, it is read-only and is used to verify the user.

• The IIS Configuration Store that is used to gather configuration details about the server, which it then displays on the benefits homepage.

• A "hit count" file that lists the number of times the home page has been accessed.

Figure 9.22 Anatomy of Web Application Benefits at Exploration Air

This scenario describes eight main steps, which are depicted in Figure 9.22:

1. The user logs on.

2. An ISAPI authentication filter is called.

3. IIS 5.0 attempts to authenticate the user.

4. IIS 5.0 loads the logon page Logon.asp.

5. Logon.asp attempts to read data from the configuration store.

6. ADO performs a lookup on the Human Resources page.

7. A data access component written in Microsoft® Visual Basic® 5.0 performs a complex update.

8. The page count is updated using a Page Count component.

In each step, issues that could prevent you from proceeding to the next step are outlined.

Step 1: The User Logs On

The user is prompted to enter some sort of user-authentication information on a page called Default.asp. The information is collected in an HTML form and posted to the server using an SSL session. Security problems at this stage are unlikely.

Issues to consider (see Figure 9.23):

• With SSL, use the HTTPS protocol rather than HTTP. Failure to do so will yield a 403.4 error (SSL required).

• Make sure that the server certificate is not out of date, or the browser could reject it.

• If the server certificate is from a CA unknown to the browser, the browser might fail to connect to the server.

• If the name in the server certificate is not the same as the name of the server you wish to communicate with, the browser might fail to connect to the server.

  

  Figure 9.23 Internet Explorer 5 Message Warning That a Server Certificate Has an Incorrect Name and That It Is Issued by an Unknown CA

• Problems can occur if the administrator has set up .asp files so that they won't process HTTP POST methods. Although this is unlikely, with IIS 5.0 you can restrict HTTP method types if necessary, as shown in Figure 9.24.

  

  Figure 9.24 Setting HTTP Method Exclusion

  Note: This functionality has changed from IIS 4.0, in which you select the HTTP verbs you do not want to allow. In IIS 5.0, you select the HTTP verbs you want to allow.

Step 2: An ISAPI Authentication Filter Is Called

Implemented as DLLs, ISAPI filters are quite common for custom logging and authentication.

You can use an ISAPI filter to receive notification of various events during the processing of HTTP requests. Filters are loaded when you start IIS 5.0, and are kept in memory until you shut down IIS 5.0. Once a filter is loaded, it indicates the events that IIS 5.0 should send notification about. Subsequently, IIS 5.0 will notify the filter each time one of the registered events occurs.

One type of notification is the Authentication notification. The ISAPI filter is notified when the client makes an initial request, and can then make decisions about whether to allow or deny access to the server. In the case of Exploration Air, this filter takes the user name and password entered in step 1 and uses this to perform a database query. If the name and password combination is correct, the user is allowed access to the Benefits Web application.

Problems can occur if:

• The ISAPI filter rejects the user for some reason, probably based on some data in the Human Resources database.

• The user types in a name or password incorrectly, or the database is out of synch.

• The UNIX server has crashed or the SQL*Net connection is failing. Check the Oracle database logs for any further clues, and use Oracle Trace for low-level information.

Step 3: IIS 5.0 Attempts to Authenticate the User

There are a number of steps that take place here, including IP and domain name restrictions.

Issue to consider:

• At this point, the user will be logged on as either an anonymous user or as a normal Windows account. You can verify this by looking in the Windows Audit Log.

Step 4: IIS 5.0 Loads the Logon Page Logon.asp

Logon.asp is loaded by IIS 5.0 in a separate memory space. This is done for reliability reasons. Eventually, this option will be turned off, once the Web administrators have deemed the code trustworthy and safe. You may wish to run newly written code that has not been thoroughly tested in a separate process. If this code should crash, it will only crash its own process and not the IIS 5.0 process.

Also, Logon.asp includes the following at the top of the page:

<%@ Transaction = Requires_New %> 

This tells IIS 5.0 that it must start a new transaction for any component or data access that supports transactions. In the case of Logon.asp, this includes the Microsoft® Visual Basic® 6.0 data access component and the ADO code performing the Oracle query. Component Services is used to control the transaction.

Issues to consider:

• Any Web application that is marked to run in a separate memory space (out-of-process) runs in the security context of a special user account called IWAM_computername. However, the process will impersonate the calling user (for example, IUSR_computername) before accessing any resource. You can verify this in the Windows Audit Log.

• While not a security limitation per se, keep in mind the transaction semantics that are now in place. If a transactional component fails or explicitly rolls back its part of the transaction, other transactional components will lose their changes.

Step 5: Logon.asp Attempts to Read Data from Configuration Store

Using ADSI, the page tries to read data from the configuration store. The code looks like this:

<% 
Dim oWebApp 
Dim strAppName 
Set oWebApp = GetObject("IIS://LocalHost/W3SVC/1/Benefits") 
StrAppName = oWebApp.AppFriendlyName 
Set oWebApp = Nothing 
%> 

This code has the friendly name "Benefits application." If an administrator decides to change a comment about the application by using the IIS 5.0 administration tools, it will be reflected automatically in the Logon.asp page. Once again, you can verify this in the Windows Audit Log.

This can fail because:

• Accessing the Configuration Store requires Administration privileges on the Web site in question.

Step 6: ADO Performs a Lookup on the Human Resources Page

This is a straightforward database lookup, similar to that performed by the ISAPI filter in step 2.

Issues to consider:

• Problems can occur if the user does not have access to the database being queried.

• If the database connection is being performed with ODBC, use the ODBC Trace tool to check for any access problems. Check the Oracle database logs for further clues. Use Oracle Trace for low-level information.

Step 7: Data Access Component Written in Visual Basic 6.0 Performs a Complex Update

This section assumes knowledge of a relational database management system (RDBMS) such as SQL Server.

The Visual Basic 6.0 component is a Microsoft® ActiveX® DLL that is transaction-aware. The component contains data-access code that was written using ADO, in order to access a SQL Server 7.0 stored procedure.

The stored procedure performs a SELECT from two tables and then an INSERT into another. The last table also has an INSERT trigger.

Issues to consider:

• If you are attempting to access SQL Server using Windows-only security (this was called Integrated security in Microsoft® SQL Server 6.5) from an ASP application, you can have security problems. This is because the account that was used to log you on to IIS 5.0 might not be valid on SQL Server.

• The user account might not have access to the appropriate SQL Server objects (tables, stored procedures, and so on). Check the Object Properties dialog box in SQL Server 7.0 Enterprise Manager, shown in Figure 9.25.

  

  Figure 9.25 Object Permissions in SQL Server 7.0

• Enable Auditing in the SQL Enterprise Manager for successful and failed SQL Server logon.

• If the database connection is being performed with ODBC, then use the ODBC Trace tool to check for any access problems.

• Check the SQL Server Error Log.

• Use the SQL Trace tool to check low-level traffic.

• The INSERT trigger could be failing. For example, it could be performing some business-rule check that is failing, so the insert is rolled back. Check the trigger by right-clicking on the table in question and selecting Manage Triggers.

Step 8: Page Count is Updated Using a Page Count Component

Web pages are often counted. Normally when a user accesses a page, some server code is executed to open a file, increment a count in that file, and then resave it.

Issues to consider:

• This can be a cause of failure because the user account performing the request might not have access to the file on the server where the page-hit information is stored. Remedy this by allowing Everyone (both Read and Write) access. You can verify this by auditing for file/object access.

Defending Against Malicious Attacks

The need to safeguard corporate data is great, and while most Web users are benign, many are not. This section addresses some of the low-level security settings required in a Windows 2000 Server and IIS 5.0 environment.

To secure any computer system such as Windows requires a good deal of underlying system knowledge, as well as knowledge of the latest security fixes.

Historically, securing a Windows server has required setting security options in many areas, such as:

• The file system

• The registry

• Networking protocols

• Application settings

• User and group accounts

• Account policies

• System services

Setting all these policies by hand is both tedious and error-prone. Windows 2000 Server includes a tool called the Security Configuration and Analysis in order to alleviate this problem. Its primary goal is to provide a single point of administration for Windows system security.

Security Configuration and Analysis allows an administrator to:

• Define one or more security policies based on the role of the computer.

• Configure a server to match a security policy.

• Audit against an existing policy and report differences.

Using the Security Templates

The Resource Kit companion CD includes two IIS 5.0 specific security templates to be used with Security Configuration and Analysis in Windows 2000:

• Secure Internet Web Server

• Secure Intranet Web Server

Once the policy is updated to meet your requirements, you can import the appropriate template into Security Configuration and Analysis and audit against it or apply the template. It is preferable to audit first, in order to see how misconfigured your servers are.

It is important to note that these templates are starting guidelines. Each will require a little updating in order to reflect your corporate security policy.

Table 9.6 lists some areas to which you should pay close attention:

Table 9.6 Updating Policies to Meet Corporate Requirements

Policy	Comment
Allow storage of passwords under reversible encryption.	Enable only if you are using digest authentication.
User Rights Assignment.	Update the following to include the IUSR_ and IWAM_ accounts: Log on locally. Access this computer from the network.
Change Administrator account name to...	Consider changing the administrator account to some other name.
Change Guest account name to...	Consider changing the Guest account to some other name.
Enable digital signing of secure channel network traffic.	Enable, if you are in an intranet.
Enable encryption of secure channel network traffic.	Enable, if you are in an intranet.
Require secure channel traffic to be signed or encrypted.	Enable, if you are in an intranet.
Send downlevel LanMan compatible password.	If you are using Windows throughout, set this to NotCompatible.

You should also keep abreast of security issues as they arise by regularly checking https://www.microsoft.com/security/default.asp.

Auditing Access with IIS 5.0 Logs

You can use IIS 5.0 logs in order to track access to your server. Logging is very flexible and can be used in conjunction with a log file analysis tool (such as WebTrends from https://www.webtrends.com) to detect suspicious activity such as:

• Multiple failed commands, especially to the /Scripts directory, or to another directory configured for executable files.

• Attempts to upload files to the /Script directory, or to another directory configured for executable files.

• Attempts to access .bat, .exe or .cmd files and subvert their purpose.

• Attempts to send .bat or .cmd commands to the /Scripts directory, or to another directory configured for executable files.

• Excessive requests from a single IP address attempting to overload or cause a denial­of-service attack.

For more information about logging, see "Monitoring and Tuning Your Server" in this book.

Useful IIS Admin Objects/ADSI Security Settings

Configuring Web services can be time consuming, due to the number of parameters that often need to be set. The IIS Admin Objects (IISAO) can help reduce this work by allowing you to write scripts that automate the process.

The IIS Admin Objects are an ADSI implementation for accessing and setting IIS 5.0 settings. They are COM Automation-based, and can be used with any language that supports Automation, such as Microsoft® Visual Basic® Scripting Edition (VBScript) or Microsoft® JScript®, Visual Basic, Java, or C++.

Table 9.7 lists some useful IISAO security-related settings:

Table 9.7 Security Settiings with IISAO

IISAO Property/Object	Comment
AccessFlags	Sets access permissions such as Read, Write, and Script.
AccessSSLFlags	Sets SSL properties such as SSL required, requires 128-bit SSL, and requires client authentication certificate.
AnonymousPasswordSync	Supports Allow IIS to control password option.
AnonymousUserName & AnonymousUserPass	Allows anonymous user name and password.
AuthFlags	Specifies what sort of authentication scheme will be used.
IIsCertMapper	Manages mapping of client certificates to Windows user accounts.
LogonMethod	Specifies the logon method for Basic and Anonymous authentication.
PasswordCacheTTL	Specifies the amount of time in seconds that an expired password will be held in the memory cache.
UNCAuthenticationPassThrough	Enables user authentication pass-through for UNC virtual root access. This applies to authentication schemes that support delegation.

For more information about these settings, see the IIS 5.0 online product documentation.

IIS 5.0 Security Checklist

This section outlines some of the steps you should take to secure a Windows 2000 Server that is running IIS 5.0 on the Internet. Note that this document does not take into consideration firewalls or proxy servers. It also assumes the company has a security policy in place.

You will notice that this list is quite small, because most of the work is performed by Security Configuration and Analysis.

Step 1: General Information

Server Name			Manufacturer
Asset #			Location
Setup Date			Set up by

Step 2: Background Work

	Read your corporate security policy.		Configure hardware to meet security policy.
	Read the IIS 5.0 Resource Guide "Security" chapter.		Check https://www.microsoft.com/security.

Step 3: Windows 2000 Server Settings

	Apply latest Service Pack and hot-fixes from ftp.microsoft.com.		Format hard disk(s) to NTFS.
	Review appropriate Secure Configuration Template settings.		Apply appropriate Secure Configuration Template settings.
	Turn off NTFS 8.3 name generation.		Set appropriate NTFS DACLs.
	Set system start time to zero seconds.		Set domain controller type to: _____.
	Remove OS/2 subsystem.		Remove POSIX subsystem.
	Remove all net shares.		Disable Guest account.
	Check user accounts, group membership, and privileges.		Set a very strong password for Admin account (at least nine characters).
	Unbind NetBIOS from TCP/IP.		Disable IP routing.

Step 4: IIS 5.0 Settings

	Install minimal Internet services required.		Set appropriate authentication methods.
	Set appropriate virtual directory permissions and partition Web application space.		Place executable content in Execute (X)-only location.
	Set IP address/DNS address restrictions.		Validate executable content for trustworthiness.
	Set up SSL if appropriate.		Enable Logging.
	Map Client Auth Certificates to Windows accounts if appropriate.		Set Indexing Service to only index documentation.
	Lock down Microsoft Certificate Services ASP enrollment pages with DACLs.		Disable or remove all sample applications.

Step 5: Install Scanner/Intrusion Software

Regularly run a security scanner on your Web server, by using software from one of the companies listed at https://www.microsoft.com/backofficeserver/.

Step 6: Update the Emergency Repair Disk (ERD)

You should regularly update the ERD.

To update the ERD

1. Run the Backup tool by clicking Start, Run, and then typing ntbackup.

2. Select the Tools menu.

3. Select Create an Emergency Repair Disk.

Additional Resources

The following books provide additional information about IIS 5.0 and about other features of Windows 2000 Server.

Books

Security Theory

Fundamentals of Computer Security Technology by E. Amoroso, 1994, Upper Saddle River: Prentice Hall.

Computer Security by D. Gollman, 1999, New York: Wiley.

Firewalls and Proxy Servers

PCWeek Intranet & Internet Firewall Strategies by E. Amoroso and R. Sharp, 1996, Indianapolis: ZD Press.

Firewalls & Internet Security: Repelling the Wily Hacker by W.R. Cheswick and S.M. Bellovin, 1994, Reading: Addison Wesley.

Internet Security Risk Analysis, Strategies & Firewalls by O. Kyas, 1996, Washington, D.C.: Thomson.

Web Proxy Servers by A. Luotonen, 1997, Upper Saddle River: Prentice Hall.

System Intrusion

Maximum Security: A Hacker's Guide to Protecting your Internet Site and Network Second Edition, anonymous, 1998, Indianapolis: Sams.

Intrusion Detection by T. Escamilla, 1998, New York: Wily.

The Cuckoo's Egg by C. Stoll, 1995, Sydney: Pan MacMillan.

General Security

Database Security by S. Castano, M. Fugini, G. Martella, et al., 1994, Reading: Addison Wesley.

Security Protocols by B. Christianson, et al., 1997, Berlin: Springer.

Davis, P.T., ed. Securing Client/Server Networks by P.T. Davis, ed., 1996, Maidenhead: McGraw-Hill.

Protecting Yourself Online by Electronic Frontier Foundation, 1998, New York: HarperCollins.

Digital Certificates by J. Feghhi, et al., 1998, Reading: Addison Wesley.

Secure Electronic Commerce by W. Ford and M.S. Baum, 1997, Upper Saddle River: Prentice Hall.

Computer Communications Security by W. Ford, 1994, Upper Saddle River: Prentice Hall.

Practical Unix & Internet Security by S. Garfinkel and G. Spafford, 1996, Sebastopol: O'Reilly & Associates.

Web Security & Commerce, 1997, Sebastopol: O'Reilly & Associates.

Actually Useful Internet Security Techniques by L. Hughes, 1995, Indianapolis: New Riders.

Computer Security Reference Book by K.M. Jackson and J. Hruska, 1992, Perth: CRC.

Java Security, Hostile Applets, Holes & Antidotes by G. McGraw and E. Felten, 1996, New York: Wiley.

Computer Related Risks by P. Neumann, 1995, Reading: Addison Wesley.

Internet & TCP/IP Network Security by U.O. Pabrai and V.K. Gurbani, 1996, Maidenhead: McGraw Hill.

Web Security Sourcebook by A.D. Rubin, D. Geer, and M.J. Ranum, 1997, New York: Wiley.

Computer Security Basics by D. Russell and G.T. Gangemi, 1991, Sebastopol: O'Reilly & Associates.

Digital Money by D.C. Lynch and L. Lundquist, 1995, New York: Wiley.

Web Security A Matter of Trust,by a collection of authors,Summer 1997, World Wide Web Journal, Vol. No. 3, Sebastopol: O'Reilly & Associates.

Information Security Policies Made Easy by C.C. Wood, 1998, Sausalito: Baseline Software.

Secure Computing Threats and Safeguards by R.C. Summers, 1997,Maidenhead: McGraw-Hill.

Encryption

Cracking DES, Electronic Frontier Foundation, 1998, Sebastopol: O'Reilly & Assoc.

Applied Cryptography, Second Edition by B. Schneier, 1996, New York: Wiley.

Cryptography and Network Security Principles and Practice by W. Stallings, 1998, Upper Saddle River: Prentice Hall.

Protect Your Privacy by R.B. Gelman and S. McCandish, 1995, Upper Saddle River: Prentice Hall.

Windows NT Security

Internet Security with Windows NT by M.J. Edwards, 1998, Loveland: Duke Press.

Microsoft Windows NT 4.0 Security, Audit, and Control by J.G. Jumes, et al, 1998, Redmond: Microsoft Press.

Windows NT Security Programming Easy-to-Use Security Options by N. Okuntseff, 1997, Gilroy: R&D Books.

NCSA Guide to Windows NT Security by C.B. Rutstein, 1997, Maidenhead: McGraw-Hill.

General Networking

Internetworking with TCP/IP, Volume I, Second Edition by E.C. Comer and D.L. Stevens, 1994, Upper Saddle Hill: Prentice Hall.

Internetworking with TCP/IP, Volume II, Second Edition by E.C. Comer and D.L. Stevens, 1994, Upper Saddle Hill: Prentice Hall.

Internetworking with TCP/IP, Volume III, Second Edition by E.C. Comer and D.L. Stevens, 1994, Upper Saddle Hill: Prentice Hall.

Internetworking with TCP/IP, Volume I, Second Edition,Windows Sockets Version by E.C. Comer and D.L. Stevens, 1997, Upper Saddle Hill: Prentice Hall.

Windows NT TCP/IP by K.S. Siyan, 1998, Indianapolis: New Riders.