Untangling Web Security: Getting the Most from IIS Security

Article
07/21/2008

James Morey, Web Technology Writer
Internet Information Services Documentation Team
Microsoft Corporation

January 5, 1999

Contents

Windows NT and IIS IIS Security Up Close IP Address and Domain Name Restriction SSL Mysteries Glossary More Information

This article contains detailed explanations of some of the misunderstood security features in Microsoft® Internet Information Server (IIS) 4.0, including client certificate mapping, IP address restrictions, Secure Sockets Layer (SSL) server bindings, and Web permissions. You'll not only find out how these features work, but also how to optimize their configuration.

Before reading this article you should have a basic understanding of both IIS and Microsoft Windows NT® 4.0 security including public key infrastructure, the SSL protocol, security credentials, and authentication. To better understand these concepts, see the IIS documentation on your server at https://localhost/iisHelp/iis/misc/default.asp. I'll begin by discussing the relationship between Windows NT and IIS security, then move on to IIS-specific issues such as authentication, IP restrictions, SSL, and Web permissions. At the end of the article there's a brief glossary of important security terms and a list of resources you can turn to for more information.

Windows NT and IIS

IIS 4.0 is a service that runs on top of Windows NT. Therefore, it relies heavily on Windows NT user accounts and the Windows NT File System.

User Accounts

At the heart of Windows NT security is the user account and its logical extension, the user group. When IIS is installed, it creates two user accounts, assigns them specific user rights, and places them in specific user groups. These two accounts are IUSR_computername and IWAM_computername. The IUSR_computername account is used by IIS to grant anonymous access to Web resources. IWAM_computername is the account used by Microsoft Transaction Server (MTS) and various IIS entities to provide programmatic and transactional functions. For the purpose of this article, I'll focus on the first account, IUSR_computername.

The IUSR_computername account needs to have the Logon Locally set correctly. This is because it acts within IIS, which is a service that acts locally, as if it were a user physically logged on to the server. If you use an account other than IUSR_computername for anonymous access, choose the rights you assign to it very carefully. Every anonymous visitor to your site will be given the rights granted to the IUSR_computername account.

IIS also depends upon user accounts while providing Basic and Windows Challenge/Response authentication. In order to complete successfully, both of these methods require that valid user accounts are in place. This is necessary because although IIS creates and configures the IUSR_computername account, which is used for anonymous authentication, it doesn't create any accounts for Basic authentication. IIS assumes that you have created, or will create, Windows NT accounts for use with Basic and Challenge/Response.

Note You must have valid Windows NT accounts to use with Basic and Challenge/Response authentication. Neither Windows NT nor IIS will create them for you. Without such accounts these authentication methods will not work.

The Windows NT File System

Although IIS can function just fine on a File Allocation Table (FAT) hard drive, you should consider changing the format to Windows NT File System (NTFS). Here's why:

Unlike FAT, NTFS is not visible to DOS. This makes your resources more secure from attacks using DOS commands.
NTFS allows you to configure the Access Control List (ACL) to grant or deny various forms of access to user and group accounts.
The NTFS file system is more efficient with hard drive space.

In the second point, I mentioned Access Control Lists (ACLs). An ACL is a list of user accounts, user groups, and their privileges associated with a particular resource, such as a directory or file. For example, the file MyISAPI.dll would have a list of user accounts and user groups that can access it and what level of access they are granted to the file, such as Read, Write, or Execute. ACLs are another core feature of the Windows NT security model, and allow flexible and precise access control to resources on the hard disk. Each directory and file has its own ACL that defines who can do what and where. Each ACL even has an ACL that specifies who can view and change the ACL itself.

NTFS and ACLs give you the basis for securing your server resources. To convert a partition or hard drive to NTFS, type the following at the Command prompt:

 CONVERT <drive>: /FS:NTFS

**Caution **Once a drive or partition has been converted to NTFS using the CONVERT Command line utility, it cannot be converted back using this utility. There are third party utilities that will convert it back.

IIS Security Up Close

This section will cover in-depth discussions of Web permissions, authentication, client certificate mapping, IP address and domain name restriction, and Secure Sockets Layer (SSL) encryption.

Web Permissions vs. NTFS Permissions

IIS has Web permissions such as Read and Write. NTFS also has its own permissions, such as Read or Write. Not surprisingly, this can get confusing. The key to understanding the difference between the two is this: Web permissions really control which HTTP verbs are allowed to be executed for HTTP resources. NTFS permissions control which user accounts have what type of access to resources on the hard disk.

HTTP verbs are commands that are sent in headers from browsers requesting actions on resources. For example, a user may say, "I want to Read (GET) this Web page." The header that is sent will specify the resource, and where it is located in cyberspace. Additionally, it will send the GET verb. This verb tells IIS that the requestor wants to "Read" the resource. The FTP world is more familiar with writing to a server, but you can also do this over an HTTP connection.

This is what the Read and Write check boxes on the Web Site tab in IIS are all about. They control which HTTP verbs are allowed for the resources. They do not control the NTFS file system permissions for the resources.

Which Witch Is Which?

If you enable read-only Web permissions are you setting read-only in NTFS as well? The answer is no. This is because Web permissions only control which HTTP verbs can be used in HTTP requests. If I set read-only in NTFS, am I setting read-only in IIS? This time the answer is a resounding yes. Even if Web permissions are set at Read and Write, if NTFS has read-only, the HTTP Write request will fail.

If Web and NTFS permissions do not agree, the more restrictive of the two will be used for HTTP requests. For example, suppose you set up "SiteB" as a Web site that points to the folder "Site_B" on an NTFS drive. You then set Web permissions as Read and Write and NTFS permissions as Read.

When a user tries to Write to https://www.SiteB.com, the request will fail. Even though IIS says it's all right to Write to the Web site "SiteB", and therefore to the folder "Site_B", NTFS says it's not OK. If someone on the SiteB network tries to paste a file into Site_B, the same thing will happen.

Now let's try switching the permissions around: NTFS is Read and Write and Web is read-only. The result is that the Web user still can't write to the Web site because denies permission. However, the network client can paste the file with ease because NTFS doesn't care what IIS has to say. IIS can only talk about HTTP requests, not file system requests.

The Permissions Mantra: If Web and NTFS permissions do not agree, the more restrictive of the two will be used for HTTP requests.

Choosing the Right Authentication Method

Anonymous authentication is appropriate for a public Web site, because it allows everyone to have access to the resources on that site. For sites that contain confidential information, however, you'll want to control access more carefully. In this case, you have four authentication options: Windows NT Challenge/Response authentication, Basic authentication, client certificate mapping, or a custom authentication application such as an ISAPI filter.

Windows NT Challenge/Response

Windows NT Challenge/Response authentication uses Windows NT user accounts directly, and does not transmit logon information, such as the user name and password, over the network. This is very important if you want to safeguard the user names and passwords of your clients. Also, because this type of authentication uses individual user accounts, you can have a great deal of flexibility over the access level of those clients.

Challenge/Response authentication uses hashing technology to transmit credential information. In the hashing process, a copy of a plain text message is run through a mathematical operation and results in a hash value that's usually 128 - 160 bits long. The hash value is said to be one-way, that is, it's computationally infeasible to derive the original message from it Challenge/Response authentication uses a series of these hashed exchanges between the server and the client to establish the identity of the user before granting access to resources.

Here's why hash values work so well for security:

All hash values from a particular hashing algorithm are the same size. This means that if you take a five-word message and a complete set of encyclopedias and run both through the same hashing algorithm, the resulting value of each would be the same size.
Hash values from very similar messages are very different. Let's say that you were to take a complete set of encyclopedias and run it through a hashing algorithm. Then you add one single character to one of the volumes and run it through the same hashing algorithm. The two values derived from this, other than being the same length, would not look at all similar.
One hash value may have an almost infinite number of messages that could have produced it. This fact is why it is computationally infeasible to derive the original message from a hash value of that message.

Because both the client and the server are being authenticated during the cryptographic exchange, no one can step in and impersonate the server—users know who they're dealing with. Despite the effectiveness of this process, there are two limitations:

Challenge/Response does not work well on a secure extranet because it cannot operate over a proxy server or other firewall application. That said, Challenge/Response works great in intranet scenarios.
The only browser that supports Challenge/Response is Internet Explorer, version 2.0 and later. This may restrict the clientele that you can service on the Internet if this is the only type of authentication you use.

Basic Authentication

Basic authentication transmits the user name and password over the wire with Base64 encoding. If you are going to use Basic authentication, keep the following things in mind:

Utilities to decode Base64 encoded packages are readily available. This means that intercepting these packages over the Internet is fairly simple. Once the IP packets are intercepted and decoded, the password of the account being used is plainly visible. IP packets are the unit by which information is sent over networks, like a letter in an envelope.
At no time is the user assured that they are sending their password information to the correct server. In other words, there is no server authentication with Basic authentication.
It is possible to create programs that can "spoof" the Basic logon dialog and capture user logon information, such as their account password.

Basic authentication is widely used on the Internet because it's easy to implement; it's supported by most browsers; and higher levels of security are not needed. In reality, unless your site is of interest to hackers, you probably won't have a lot of people waiting to intercept your IP packets.

Making Basic Authentication More Secure

You may be wondering at this point how you can achieve a secure authentication method that is supported by most browsers. The answer is to use Basic authentication encrypted by SSL. This combination will help you achieve tight access control to your sensitive information without the fear of logon information being intercepted and used maliciously. It also allows you to authenticate your server so that users can be confident about your identity. For more detailed information, see the section "SSL Mysteries."

To set up Basic authentication with SSL:

Obtain a server certificate (I'll talk about server certificates later).
Require Secure Channel when accessing this resourceto the resource (I'll talk about this later, too).
Use only Basic authentication; that is, turn off Anonymous and Challenge/Response.
Tell the visitors to the secured areas of your site to use the https URL format.

Using "https://" tells IIS to open an SSL-encrypted session. After the secure connection is completed, IIS uses Basic authentication. The user information is now secure from intruders.

Note that encrypting Web pages uses more server resources than normal Web content and encrypted transactions take longer to occur. Keep your encrypted Web pages simple—don't include any large graphics or multimedia.

Using Basic authentication with SSL works well if you really need to monitor who gets access to your site. If all of this doesn't sound ideal to you, there is another way to authenticate securely that you might want to consider: client certificate mapping.

Client certificate mapping

A client certificate is a piece of digital ID for the users accessing your site. It contains information about the user and is "signed" with a digital signature form the certification authority (CA) that issued the certificate. A digital signature is basically a hash of a message, in this case the certificate, that is encrypted with the sender's private key. The sender in this case is the CA. For a brief discussion about private keys, see the section "What is a key pair?".

IIS can be configured to ignore, accept, or require client certificates. It's important to understand how each setting changes how IIS responds to client certificates:

Ignore certificates: IIS doesn't care if a user sends their certificate with a request; IIS will simply authenticate the user using another method, such as Challenge/Response.

Accept certificates: if a client certificate is sent, IIS will use this certificate information to authenticate them. If no certificate is sent, IIS will use another method.

Require certificates: IIS will only fulfill requests from users with valid certificates.

IIS client certificate mapping associates, or maps, client certificate information with Windows NT user accounts. This form of authentication can be very secure and flexible, and most newer browsers support the use of client certificates.

There are two methods that IIS uses to map client certificates to these accounts: many-to-one and one-to-one. The biggest difference between them is that one-to-one uses the actual certificate, whereas many-to-one only uses certain information contained in the certificate, such as who the certificate issuer is. With one-to-one mapping, if a user gets a new certificate, the old mapping will fail and a new mapping will have to be made for the new certificate. With many-to-one mapping, if the user gets a new certificate using the same information, the mapping will accept it as it did the old certificate.

For example, Bob gets a client certificate using Microsoft for the company, MyUnit for the organizational unit, MyCity for the city, and MyState for the state. When he gets the certificate back from his CA, it will contain all of the information that he gave them, plus some other special information (see the section "What is in a certificate?"). Bob's certificate gets mapped to his user account using both one-to-one and many-to-one mapping. Both mappings work well.

Sometime later, Bob gets another certificate, using information identical to that listed above. The certificate he gets contains all of the same information as the first one (Microsoft, and so on), but the special information is slightly different. The old many-to-one mapping works because it doesn't care about the special information, it looks only for the information input by Bob (such as Microsoft). The one-to-one mapping will fail because it uses the special information during the authentication process.

Many-to-one mapping will see Bob's new certificate as being identical to the old one. One-to-one mapping will see the new certificate as an entirely new certificate and, therefore, no longer valid. A new one-to-one mapping will have to be made for Bob's new certificate.

What is in a certificate?

A certificate is a special text file that contains two sections: a clear text (readable by humans) section containing the information about the owner, issuer, and so on, and an encrypted (not readable by humans) section that contains the digital signature and public key of the certification authority.

The text file is given the .cer extension so that when you open it the operating system uses whatever certificate utility it has to view the file. If you open one of these files in Notepad it will look like this:

Many-to-one mapping

Many-to-one mapping uses only certain information contained in the certificate, such as who the certificate was issued by or who it was issued to. You can set wildcard rules, such as, "Accept all certificates from such-and-such a certification authority." You can be as specific or as general as you want to be. You can easily and quickly map many certificates to a single user account this way. Also, there is no need to have a copy of the client certificate on your server. If the user gets a new certificate that has the same information as before, the old mapping will still work.

One-to-one mapping

Because one-to-one uses special information that is unique to every certificate, you can be confident about the user's identity. This is because one-to-one uses a cryptographic exchange, much like Challenge/Response, involving the key pair of the client certificate. During this exchange the server needs to compare the information sent by the user's browser to a copy of the client's certificate on the server. Therefore, the server must have a copy of every client certificate used for one-to-one mapping.

Because the server uses an actual copy of the client certificate to make this comparison, a copy of that certificate will have to be obtained and a new mapping will have to be made if the client gets another certificate. This is true even if the exact same user information is used to generate the certificate. This is because the key pair for each certificate is absolutely unique.

What is a key pair?

Encryption and other security methods involve the use of unique values called keys. The most widely used encryption schemes use something called a key pair. As the name suggests, a key pair consists of two keys. One is called a public key and can be shared with a number of individuals. The other key, the private key, is only known to the owner of the certificate, whether it be a server certificate or a client certificate. The private key and public key form an asymmetric key pair, where the two keys on either end of the cryptographic transmission are different from one another. If you encrypt a message with the private key, only the public key can decrypt it. If you encrypt a message with the public key, only the private key can decrypt it.

Using these keys, you can establish the identity of the party sending you a message. Suppose you receive a message from Alice that is encrypted with her private key. Since you know her public key, you can decrypt the message and be confident that Alice was really the sender. If Alice's public key will not decrypt the message, you know that it was sent by someone else. If you send a message to Alice and encrypt it with her public key, only she can decrypt and read it.

Obtaining and storing client certificates

The obvious question is: How, exactly, do I get the copy of the client certificate onto my server?

You can extract the needed certificate information using a script from the Windows NT Option Pack documentation at https://localhost/iishelp/iis/htm/core/iicrtsc.htm. You can use this script in your Default.asp to copy client certificate information to your server in a text file.

The certificates themselves can be extracted from the text file, by copying the information to Notepad and saving it as a certificate file (.cer). Copy each section of text, including the -----BEGIN CERTIFICATE----- to the -----END CERTIFICATE----- lines. You can now perform the change below if needed.

To be usable in IIS client certificate mapping, these certificate files must be in the Base64 Encoded X.509 format. They might already be in the correct format, but since there is no easy way to tell, it's best to convert them now, just to be sure. If you have installed Service Pack 4, you can convert them this way:

Right-click on the certificate file and Open it.
Click the Details tab and click Export.
This will bring up the Certificate Export Wizard. Follow the wizard directions. Choose the Base64 Encoded X.509 (*.Cer) export file option.

Note This script copies every single instance of every single client certificate that is sent to your site. So, for example, if Bob sends you his certificate 100 times in a day, the script will create 100 copies of Bob's certificate. This means that the text file that the script creates can get really large in a short time. To correct this, you could either write a script or an ISAPI filter that saves each certificate to a separate text file.

Custom Authentication Application

If you have an existing database of user information and you want to use it for authentication, you should consider creating a custom application. Custom authentication applications can be Active Server Pages (ASP) applications, ISAPI filters, Java applets, Microsoft ActiveX™ controls, or COM objects. You can create a custom application to perform many security-related functions, such as authentication, IP address restriction, or access control.

For example, it can authenticate a user by using client certificates, prompting the user for their user name and password, or authenticating the user against a user information database. The actual creation of custom applications is beyond the scope of this article. For more information about building ISAPI filters, see Building ISAPI Filters and the CVTDOC Sample at . The MSDN Library at is also a great resource.

IP Address and Domain Name Restriction

IP addresses are unique numbers identifying computers on a network. The IP address of the computer the user is making a request from is always sent along with the request. Therefore, you can either grant or deny access to server resources based upon the IP address of the requesting party. By selecting Grant Access in the Internet Service Manger, you are saying: "I want to grant access to everyone except the IP addresses I will list below." By selecting Deny Access, you are saying: "I want to deny access to everyone except the IP addresses I will list below."

You can specify IP addresses individually or in groups by using a network ID and a subnet mask, both of which are defined below. You can also specify a domain or domain name system (DNS) name. Using a domain name, such as MyCompetitor.com, is convenient, but causes a reverse DNS lookup every time authentication in called for. This can affect the performance of your server.

DNS Lookups

A DNS lookup is a call to the DNS server to identify the domain name given and then provide the IP address for it. This IP address is returned to IIS and IIS uses it for IP address exclusion. This is a problem for performance.

There are two factors that affect performance. The first is the physical location of your DNS server. If it's on the other side of the world, the roundtrip used to get the IP address for IIS can take some time. If the DNS server is on the computer that is running IIS, the roundtrip is spared but the lookup still uses CPU and memory resources. The second factor is the sheer size of your network. If you have DNS names on your network, it's no big deal. If you have 450,000 DNS names on your network, the reverse lookup will take a while.

The Network ID and Subnet Mask

The network ID is a base IP address that is used to compare the IP addresses of incoming requests. The subnet mask is a number that specifies which bits of the network ID will be used in a bit-wise AND operation of IP addresses coming in. Got it?

Usually, the network ID is the IP address of a particular IP router. An IP router is a computer or other device that "knows" which IP addresses it services or routes to. When the network ID receives a request, it either passes the request to its node or says, "Nope, no one here by that name." Usually is the operative word here. The network ID structure for your company is one of those "job security" items in the realm of your network administrator¯if you need to know what particular network ID to use, you'll probably have to ask your network admin. To see the IP address, network ID, and subnet mask of your computer, type "ipconfig /all" at the command line.

The network IDS and subnet mask work like this: Suppose you have a group of IP addresses from your accounting department that you don't want to access your R&D site. You would use the Grant Access option to grant access to everyone, except the IP addresses you specified.

Let's say that the network ID for the accounting department is 172.21.13.45. In order to restrict every single IP address from that department, you would use the subnet mask 255.255.255.0. It's a bit like using wildcards and typing 157.112.189.* so that any IP address that starts with 172.21.13 will be excluded. Another way to think of it is, "Exclude the IP address range 172.21.13.0 to 172.21.13.255." If you were to use the subnet mask 255.255.0.0, then every IP address that starts 172.21 would be excluded. Note that the subnet mask is not an IP address.

How Network ID and Subnet Masks Really Work

IP addresses consist of four sets of 8 bits. Consequently, the IP address 172.21.13.45 would look like:

 172.21.13.45   10101100.00010101.00001101.00101101

A subnet mask is used to "mask" the bit-wise comparison, which is a AND operation. The subnet mask's bit pattern acts like a screen that either allows or denies the bit comparison. For example, if you were to compare the Network ID above using the subnet mask 255.255.255.0 it would look like this:

 Network ID   10101100.00010101.00001101.00101101
 Subnet mask   yyyyyyyy.yyyyyyyy.yyyyyyyy.nnnnnnnn
 Matching pattern  10101100.00010101.00001101.xxxxxxxx

Wherever there is an "n," the bit of the incoming IP address will not be compared. Where there is a "y," it will be. The result is that any IP address with the matching bit pattern will be excluded. The "x" in the matching bit pattern means "ignore this bit." By using really weird subnet masking, such as 255.107.0.0, you can exclude (or include) any range of IP addresses you want to.

Be careful with the subnet mask! If I had used the subnet mask 0.0.0.255, any IP addresses ending in 00101101 (45) would have been excluded. This represents 4,294,967,296 IP addresses. It's very important to know what subnet mask to use and to be sure that you are not granting access when you want to deny it.

SSL Mysteries

Secure Sockets Layer (SSL) is the most widely-used method of creating secure transactions on the Web today. Basically, the method uses public key cryptography to securely generate and exchange a commonly-held key, called the session key, that is used for symmetric encryption. The SSL features in IIS cannot be used until a server certificate has been obtained and bound to the Web site.

By binding, I mean that IIS associates the certificate with a particular IP address : port number combination. This combination might be "Any unassigned" : "Any unassigned", which can cover all of the possible Web sites your server can contain, or as specific as 172.21.13.45:80, which refers to a specific Web site.

As with all security issues, SSL can seem complex. For example, how should you bind the server certificate¯one certificate for each site or the same certificate for all sites? Do you require encryption? What bit-strength should you use? How can you back up your server certificate?

Server Bindings and Your Server Certificate

By default, IIS uses port 443 as the SSL port. You can, however, use any port you want for SSL. You can have many sites, each with a non-SSL port number and an SSL-port number. For example, you might have a site called ExampleSite. It might have port 90 as the non-SSL port and port 445 as the SSL-port. Users would enter https://www.ExampleSite.com to access the non-SSL version. To access the SSL version, they would use https://www.ExampleSite.com. They could also use the IP:port number: https://www.Example.com:445.

The "s" in https:// is very important because it tells the user's browser to use the SSL port. If you were to use https://www.Example.com:445, nothing would happen and the browser would keep cranking away but never produce anything. A similar thing would happen if you tried to use https with a non-SSL port, such as https://www.ExampleSite.com:90.

When you select "Any unassigned" as the IP allocation, the certificate is bound to all Web sites that have not previously had a server certificate bound to them¯even sites with assigned ports, such as the Default Web site and Administration Web site that are installed by IIS. If none of your sites have certificates assigned to them, then the certificate effectively binds to the WWW service. This is OK, and your server will function just fine.

Bit-Length and That Sort of Thing

When you are creating a certificate request and key pair with Key Manager and it asks you what key bit-length to use, it's asking for the bit-length of the server certificate's private key. This key is only known by the server. Different certification authorities (CAs) have different key-length capabilities. Check with the CA about the key-lengths available. It's advisable to select the longest bit-length available from your CA and by export restrictions. Typically, this is 1024-bit for domestic versions and 512-bit for export versions.

The key length that is under export restriction is the actual key used to encrypt and decrypt messages. In SSL, this is the session key and is restricted in export versions of IIS to a 40-bit length. Therefore, if you are using an export version of IIS, you will not be able to use 128-bit session keys. You can, however, still use 512-bit server private keys. Key-length can be set in the Secure Communications dialog box.

Requiring a Secure Connection

Two of the most frequently-asked questions with regard to secure connections are: "How can I have SSL on for one virtual directory and off for another?", and "If I don't have Require Secure Channel when accessing this resource enabled, is SSL working?"

Let me coin two terms here that will help answer these questions: SSL-enabled and SSL-required.

SSL-enabled means that users requesting resources on your server can do so using the https:// format. That is, they can establish a secure SSL connection with your server, but they're not required to. They can still use the https:// format for the resources over a non-encrypted connection. SSL is enabled as soon as you bind a server certificate to the site, or your WWW service.

SSL-required means that only SSL connections can be made for the resources—https:// will not work at all. This happens only when you select the Require Secure Channel when accessing this resource option in the Secure Communications dialog box.

The Require Secure Channel when accessing this resource option can be selected at the Master, site, virtual directory, or file level. However, as soon as you bind a server certificate to a site, every resource included in that site, that is all virtual directories and files, are SSL-enabled even if you have not selected the Require Secure Channel when accessing this resource option. All the Require setting does is force the users to establish an SSL connection.

The "One Certificate" Trick

Binding a server certificate at the Master Properties level using "Any unassigned IP address" and "Any unassigned port" will effectively bind the certificate to every Web site that has not previously been bound to a certificate. If this is your first server certificate, it means that it is effectively bound to the entire Web service. You can also do this by individually binding the same server certificate to each site.

The Easiest Way to Make Your Site Completely Unreachable

At this point, you may be wondering if you can set the Require Secure Channel when accessing this resource option at the Master Properties level. The answer is yes. Is this a good idea? Probably not. When you set Require Secure Channel when accessing this resource at the Master level, you are setting it for all sites, even those not bound to a server certificate and therefore not SSL-enabled. This means that the sites are now unreachable by your users. If they use the https:// format, they will be told that SSL is required for the resources. If they then use the https:// format, they will be told that the page cannot be loaded because there is no server certificate bound to the site. Basically, what happens is this: You need to use https://…. Oh, yeah, https:// doesn't work.

You can't configure SSL at the Master Properties level without a server certificate. IIS is smart enough to make you get one before you can set SSL at all. However, once you have a server certificate you can set Require Secure Channel when accessing this resource at the Master level, even for sites that do not have a certificate bound to them.

The trick here is to pay attention to the Inheritance Overrides dialog box that comes up when you choose Require Secure Channel when accessing this resource at the Master level. It will list all of your Web sites. Select only the ones that have a certificate bound to them.

Note Setting anything at the Master Properties level should be done with caution, as the results can be propagated down to every site, virtual directory, and file for the WWW service. SSL is no exception to this. I would strongly suggest that SSL be set at the site or virtual directory level only, and not at the Master level. It's too easy to inadvertently make your entire Web server unavailable to users. Also, setting SSL at the Master level means that every single https request will be encrypted. This can significantly affect the performance of your server.

Wrapping Up

I hope that this information has helped you to better understand Web security and some of the security features of IIS. Stay tuned to the MSDN Library for more information about server technologies.

Glossary

Access Control List (ACL) A list of user accounts and user groups and their privileges that is associated with a particular resource.

Asymmetric encryption One key is used to encrypt and another, different key to decrypt.

Binding An IP Address:port number combination that IIS associates with a server certificate.

Certification authority (CA) A mutually-trusted third party that issues certificates; for example, VeriSign.

Client certificate A piece of digital ID for the users accessing your site. It contains information about the user and is "signed" with a digital signature from the certification authority that issued it.

Default site Any Web site that is bound to port 80.

Digital signature A hash of a message that is encrypted with the sender's private key.

Hashing The process whereby a copy of a plain text message is run through a mathematical operation that results in a hash value which is usually 160 bits long. It is computationally infeasible to derive the original message from the hash value.

HTTP verb HTTP verbs are sent by the user's browser and tell IIS what the user wants to do with the file they requested. They can Read (GET) the file or Write (POST) to the file.

IP packets The unit by which information is sent over networks.

IP router A computer, or other device, that "knows" which IP addresses it services or routes to.

ISAPI filter An application, usually a DLL, that sits on the front of IIS and acts as a filter for requests coming into IIS.

Key bit-length (or bit-strength) The length, in binary bits, of a key. Messages encrypted by longer keys are significantly harder to break than with shorter keys.

Key pair A pair of unique values that are used to establish an SSL connection, encrypt data being transmitted, or both. In public key cryptography there is a private key and a public key. Messages that the private key encrypts can only be decrypted with the public key, and vice-versa.

Network ID A base IP address that is used as a starting point to compare the IP addresses of incoming requests to.

Public key encryption A common encryption method that uses an asymmetric key pair to encrypt and decrypt messages.

Server certificate A piece of digital ID for your server. It contains information about the server and is "signed" with a digital signature from the certification authority that issued it. It also contains a key used in forming an SSL connection. You must have a server certificate bound to your server in order to use SSL.

Session key An encryption key created during the SSL connection establishment. This key is known only to the user and the server and is used for symmetric encryption.

Subnet mask A number that specifies which bits of the Network ID will be used in a bit-wise AND operation with IP addresses that accompany requests.

Symmetric encryption Where the same key is used to encrypt and decrypt messages.

More Information

There's a seemingly endless supply of information regarding Web security available—it's impossible to read it all. The resources listed below are intended as a starting point.

The IIS online documentation is a complete source of information about IIS, including security. If you are at the computer where IIS is installed and the server is running, use the local URL https://localhost/iishelp to view the documentation.

The book Microsoft Internet Information Server Resource Kit is another great resource. The chapter on security discusses some of the attacks that might be used against your site, and what to do about them.

The book

Microsoft Windows NT Server 4.0 Resource Kit contains a plethora of ideas, information, and suggestions on Windows NT security. I would highly recommend it for your security team.

The Microsoft Security Site is one of the best resources for up-to-date and archived information. The site offers a wide variety of security information on many Microsoft products.

The article "How to Troubleshoot Permissions in IIS 4.0" is a great troubleshooting resource for one of the most important IIS issues.

Microsoft TechNet has articles about Web security that are aimed at IT professionals. It also has peer discussion groups.

The Trusted Systems Web site has some really detailed information that evolved from a one-year research project that was done for the National Security Agency (NSA).

The SANS Organization is another resource with a wide variety of materials. It has technical papers, posts about security holes and attacks, software tools, links to other great resources, and more.

The Windows NT Security Site has up-to-date information of security issues in Windows NT and much more.

The RSA site is one of those places where the idea of Web security began. If you need information about encryption, this is a good place to look. The site includes some very technical information on encryption, as well as a complete set of all of the more common encryption standards.