This chapter is from the book
This chapter is from the book
This chapter is from the book
Web Site Security
Web sites are made available through the Web service component of Internet Information Services. Because these Web sites contain data, they need to be secured at one level or another (even if that security is to leave everything unsecured).
The following list outlines ways in which you can control access to your Web sites:
Changing the TCP port
Changing access permissions
Changing execute permissions for scripts and programs
Changing authentication methods (including enabling and disabling anonymous access)
Adding IP address and domain name restrictions
Adding server certificates for Secure Socket Layer (SSL) transmissions
Authenticating users with client certificates
These topics are discussed in the following sections.
Controlling Web Site Access Through the TCP Port Number
Most common TCP/IP protocols have specific TCP ports associated with them, and the software that enables you to use these expects the ports to conform to the standard defaults. However, similar to a TV channel, these ports can be changed. If a certain set of data is being broadcast on a certain port, and that port is not the default port for that utility (such as port 80 for HTTP traffic), the port must be determined to access the data. This might sound trivial, but because more than 65,000 TCP ports are available to choose from, you can hide your site from most casual users by choosing any TCP port other than 80.
Of course, this is not very robust security because if someone knows which port you are running on, that person will be able to return to your site. In addition, if you have a port sniffer or security scanner, you could easily determine the port that a particular Web server is running on. However, it is a good way to hide information from people who do not know what they are looking for.
If you change the TCP port for your Web site (to 8080, for example), any browser client who wants to access your site will have to manually type in the TCP port number along with the address of your site. For example, if your site was http://www.mydata.com and you were using TCP port 8080, a browser client would access your site with the following URL:
http://www.mydata.com:8080
Step By Step 3.5 showed you how to determine and change a Web site's TCP port.
Controlling Web Site Access Through Access Permissions
One of the most common ways to secure a Web site is to change the global settings for what all users can do. By making a Web site read-only, for example, you ensure that no one will be able to accidentally or purposefully make changes to the content of your site.
As you can see in Figure 3.10, four access rights can be controlled for the entire site: Script Source Access, Read, Write, and Directory Browsing.
)
Figure
3.10 Web access rights can be used to restrict the file-level permissions
of the files on a site.
Enabling script source access allows users to see the source code behind the Active Server Page they are currently viewing. This would enable users to access JavaScript and VBScript source code. That source code might contain sensitive information, such as the location of the database server or passwords that would be inappropriate for anyone other than the development team to have.
Read access allows users to look at the content of the Web page and download files. If read access is not enabled, no users will be able to access the content on the site.
Write access enables users to upload content to the site. This includes being able to modify the HTML or script content as well as placing new files into the site folder on your server.
Don't Let Others Supply the Code You Run
It's a bad idea to allow both execute access and write access to a directory. This enables a person to upload and execute potentially destructive programs.
Directory browsing allows users to see a file listing in your Web site's main folder. This would allow a user to know what the names of your files are and to navigate through your file path to subfolders in your Web site. If this is not enabled, users must connect through the HTML pages you have set up on your Web site. If no default HTML page has been configured, browser clients will not be able to navigate your Web site at all.
You will need to make choices about which of these rights you want to enable for your user community. Remember that these rights are global across all users of your Web site; they will not discriminate. If you want to allow some users to upload files and not others, you must give Web site rights to write and then control access using NTFS permissions on the local files or folders themselves.
You will notice in Figure 3.10 that a logging setting is also available. This setting, which is usually enabled, allows you to log all user interaction with this site. This log enables you to monitor who is connecting to your site and what she is doing. The logging options (including the location of the log file) can be configured on the Web Site tab of the Web site's Properties dialog box.
Step By Step 3.10 shows you how to adjust the site access permissions.
STEP BY STEP 3.10: Changing Site Access Permissions
From the Start menu, select Settings, Control Panel, Administrative Tools, Internet Services Manager.
In the IIS Console window, you can locate your Web site by expanding Console Root, Internet Information Services, and Your Server. When you see your Web site in the tree under the name of your server, right-click it and select Properties from the menu that appears.
In the Web Site Properties window, click the Home Directory tab. There you see check boxes under the Local Path field that you can use to set site access permissions. Select or deselect the appropriate rights.
Click OK to update the Web site's properties.
Controlling Web Site Access Through Execute Permissions
Another way to control site access is through execute permissions. Execute permissions (shown at the bottom of Figure 3.10) define what type of scripts or executables a browser client can invoke on your site. The execute permissions include None, Scripts Only, and Scripts and Executables.
If you select None, no scripts will run on this Web site. This is obviously problematic because it means that Active Server Page scripts will not run.
If you select Scripts Only, Active Server Page scripts will run on this Web site. However, executables—including ASAPI DLLs and CGIBIN applications—can't be invoked.
If you select Scripts and Executables, a user will be able to invoke any script or executable she can get at. Although this provides a lot of functionality to the user, it is the most dangerous option in terms of security.
Step By Step 3.11 demonstrates how to change a site's execute permissions.
STEP BY STEP 3.11: Changing Site Execute Permissions
From the Start menu, select Settings, Control Panel, Administrative Tools, Internet Services Manager.
In the IIS Console window, you can locate your Web site by expanding Console Root, Internet Information Services, and Your Server. When you see your Web site in the tree under the name of your server, right-click it and select Properties from the menu that appears.
-
In the Web Site Properties window, click the Home Directory tab. Click the Execute Permissions drop-down arrow to see the list of permissions (see Figure 3.11). Select the level of script execute privileges you want to give out for your site.
Figure
3.11 Execute permissions control the execution of programs and scripts on
your Web server. Click OK to update the Web site's properties.
)
Figure
3.11Controlling Web Site Access Through Authentication Methods
One of the strengths of using IIS as a Web server on a Windows 2000 Server is the capability to integrate Windows 2000 computer or domain security into Web access. Essentially, you have the ability to force users to provide names and passwords from the local machine accounts or from Active Directory to access Web sites. This eliminates the need to create your own security model.
Web authentication occurs at two levels: anonymous and authenticated. Anonymous access is the first method attempted when a user tries to connect to any Web site. If anonymous access is disabled, or if a Web user tries to access a function that can't be performed by an anonymous user, authenticated access is attempted. Anonymous access does not require a password. However, authenticated access always requires confirmation of identity, which can be in the form of a password challenge. But security information can be passed transparently (such as integrated Windows access or with client certificates, both of which are covered later).
Under IIS, anonymous access is mapped to a user account. Therefore, any attempt to access a Web site anonymously treats the user as though he were logged in as the anonymous IIS account. By default, the name of this account is IUSR_servername. That means that if your server were called Green, the anonymous user account would be called IUSR_Green unless you changed it to something else.
One way of securing your Web site is to disable anonymous access to the whole site. Then, for any attempted access, the browser client is prompted for a name and password to access the site. Another way to secure your site is to put NTFS security locally on some or all of your Web site. If you do this, for any attempted access of files or folders that do not allow anonymous access, a name and password is required (whether the user is prompted for it depends on the type of authentication you require and his other authentication information to the Web server).
If you do require that a user log on to your site (or some portion thereof), you can set the type of authenticated access you want to require. Three levels exist: basic authentication, digest authentication for Windows domain servers, and integrated Windows authentication.
Basic authentication is the least secure but most accessible across a variety of browsers. This type of authentication sends all login information in clear text. Unfortunately, if someone is watching your logon using a packet sniffer or other network analysis tool (Windows 2000 or NT Network Monitor, for example), she might be able to capture your username and password as you log on. Basic authentication is supported by all Web browsers, including non-Microsoft browsers. Although sending passwords in clear text is a security risk, this can be overcome by using server certificates and SSL (covered later).
When a user logs in using basic authentication, the user's combined name and password are checked against the directory IIS has been told to use (either local or an Active Directory for the domain). If the name and password pass authentication, local security is checked on the files the user is trying to access, and if the username has appropriate access in the ACL, access continues. If the name and password do not pass authentication, however, the user is prompted repeatedly until he cancels the login operation. If the username is not authorized to access the resource it is trying to access, it will pass authentication but be given an Access denied message.
Make the Message Meaningful
The exact message that is returned to the client can be controlled by setting custom errors for the Web site.
A second—and more secure—type of authentication is digest authentication. It is similar to basic authentication; however, it uses a hashing algorithm to encrypt data sent between the browser and server. This hashing algorithm is classed as one-way in that it can be used to encrypt but not decrypt the data. This type of authentication works only on browsers that support the HTTP 1.1 standard and can respond to the requests the IIS server is making. At this point, only IE4.x and greater support this authentication method. Although this method has some advantages over basic authentication, it has a major security flaw in that the password must be stored in clear text on the domain controller for the reverse encryption to be processed and compared. As a result, it is rarely used.
Configuration for Digest Authentication
Two things are required for this type of authentication to work. First, the IIS server must be a member of a domain. Second, each user who needs to authenticate through a browser must have her account to store the password using reversible encryption. To do this, that setting must be enabled in the properties for the user (Account tab), and then the password for the user must be reset.
If digest authentication is configured and either the user's browser is not capable of using this type of authentication or the user's account has not been configured properly (as described in the Note titled "Configuration for Digest Authentication"), the authentication will fail.
The final authentication method is integrated Windows authentication (formerly called NTLM or Windows NT Challenge/Response authentication). This method uses special encryption protocols to secure the authentication process. Unlike the other two authentication methods, IWA does not necessarily prompt for a username and password. Instead, it checks the Windows logon currently in force on the client's machine. If this can be determined and authenticated, the user might never know that any restrictions are in place on the site. If the user does not authenticate or a Windows logon name can't be determined, the browser displays a logon dialog box.
The benefit of this authentication method is its security. The disadvantages are that it works only on Internet Explorer 2.x or later (no Netscape support exists). This type of authentication is best used in an intranet environment where the browser type can be controlled.
Step By Step 3.12 demonstrates changing the type of user authentication required by your Web server.
STEP BY STEP 3.12: Changing Site Authentication Methods
From the Start menu, select Settings, Control Panel, Administrative Tools, Internet Services Manager.
In the IIS Console window, you can locate your Web site by expanding Console Root, Internet Information Services, and Your Server. When you see your Web site in the tree under the name of your server, right-click it and select Properties from the menu that appears.
-
In the Web Site Properties window, on the Directory Security tab, click the Edit button in the section labeled Anonymous Access and Authentication Control (see Figure 3.12).
Figure
3.12 You can configure access authentication from the Directory Security
tab of the Properties dialog box. -
From the Authentication Methods dialog box, select whether you want anonymous access to be configured (see Figure 3.13). If you do, you can choose to modify the account used for anonymous access or its password. To do that, click the Edit button and type in a new account name and password.
Figure
3.13 You can configure anonymous access and any of three authentication
methods. If you want to enable basic authentication, select the appropriate check box. When the Internet Service Manager warning comes up about the nature of basic authentication, click Yes to continue. Click Edit to define the location of the accounts used to authenticate Web users. If you leave it at the default, the local accounts for the server will be used. However, you can also enter a domain name to access Active Directory to use for authentication; both can't be used.
If you want to enable digest authentication or integrated Windows authentication, select the appropriate check box.
Click OK to update the Web site's properties.
Multiple Authentication Methods
If you select more than one authentication method, after attempting anonymous access, IIS attempts to authenticate using the most secure method (integrated Windows) first. Then, it tries less secure methods until all avenues of authentication have been exhausted.
)
Figure
3.12)
Figure
3.13Controlling Web Site Access Through IP Address and Domain Name Restrictions
You can control the access people have to your Web site to include only people with certain IP addresses (from within your company, for example) or to exclude people with certain addresses. By using IP address and domain name restrictions, you can ensure that even if someone obtains a username and password that is valid, that person can still be prevented from accessing data. This could enable company employees to access the intranet when they are at their desks (with known TCP/IP addresses) but prevent them from accessing the intranet from home (where they have unknown or unauthorized TCP/IP addresses).
When you restrict based on IP addresses or domain names, you can configure single IP addresses, multiple addresses based on a network ID and subnet mask, or addresses falling into a certain domain. If you choose to restrict based on domain (for example, to exclude all users whose IP addresses are registered to BADGUYS.com), your IIS server must do a reverse lookup on each IP address that traffic comes from. This is always very time and resource intensive and might not yield accurate results. Caution should be exercised when choosing this method.
In case you missed it, just because you can restrict access based on the client's domain affiliation doesn't mean that you should. The additional overhead of performing a reverse name lookup on an IP address is generally not justifiable.
Disallowing accesses using this method has precedence over all other access a user might have been given to the Web site.
This method for changing site address and name restrictions is covered in Step By Step 3.13.
STEP BY STEP 3.13: Changing Site IP Address and Domain Name Restrictions
From the Start menu, select Settings, Control Panel, Administrative Tools, Internet Services Manager.
In the IIS Console window, you can locate your Web site by expanding Console Root, Internet Information Services, and Your Server. When you see your Web site in the tree under the name of your server, right-click it and select Properties from the menu that appears.
-
In the Web Site Properties window, on the Directory Security tab, click the Edit button in the section labeled IP Address and Domain Name Restrictions (see Figure 3.14).
Figure
3.14 You can configure IP address and domain name restrictions from the
Directory Services tab of the Web site's Properties dialog box page. -
In the IP Address and Domain Name Restrictions dialog box, select whether you want to implicitly grant access except to listed addresses or to implicitly deny access except to listed addresses (see Figure 3.15). Then click the Add button.
Figure
3.15 You can explicitly grant or explicitly deny access by IP address or
domain name. -
From the Deny Access On or Allow Access On dialog box, as shown in Figure 3.16, select Single Computer and enter the IP address, select Group of Computers and enter the network address and subnet mask, or select Domain Name and enter the domain name. Then click OK to exit.
Figure
3.16 You can deny access by a specific IP address. Click OK until you exit back to the IIS Console.
)
Figure
3.14)
Figure
3.15)
Figure
3.16Securing Web Access Using Certificates
Certificates are a final way of securing Web access and authenticating users. In Windows 2000, the use of certificates is pervasive, as much of the security uses certificates in one way or another. As a result, the discussion of certificates here will be restricted to their use in Web transactions.
The idea of the certificate as it applies to Web transactions is that an entity (server or client) proves its identity to another using a piece of identification—the certificate. The passport provides an excellent example of how certificates work. As an American citizen, I have been issued an United States passport that verifies that I am a certain person and that I am a citizen of the United States. When I cross the border into Canada, I can show my passport to the Customs official as proof of my identification and citizenship. This passport is deemed to be valid only if two conditions are met: The passport must be authenticated by the United States government (which is done through special security coding on the passport documents), and the Customs official must recognize the United States government as being trusted to make assertions about me. If the passport is deemed to lack authenticity or if the Customs official does not recognize the United States government as a trusted authority in passport issues, my passport is not acceptable for the purposes of identification.
Computer certificates work in much the same way a passport does. A server certificate issued to a user, computer, or Web server identifies that server as being a particular entity. This certificate must be authenticated by a third party (not me and not the server itself). This authenticating party is referred to as the Certificate Authority (CA). An example of a CA that is commonly used is VeriSign.
The authentication is only half of the requirement to create a trusted environment; my Web browser must trust VeriSign to make assertions about servers. Fortunately, all current browsers are configured to trust certain so-called root CAs, of which VeriSign is one. After my browser and the Web server have verified that the server is who it says it is, a security negotiation can take place, thus enabling encrypted transmissions to occur.
Client certificates, on the other hand, are used to verify the identity of a person using a Web browser. Just as a server (computer) certificate allows a server to be identified, a client certificate allows a browser client to be identified. As with a server certificate, a client certificate must be authenticated by a third party, and that third party must be trusted by the server. If that is the case, the identity of a browser client can be established without sending a password over the Internet; all that is sent is the certificate information that identifies the particular user. This identification is made possible by incorporating the client certificate into the Web browser and then exporting the certificate to the IIS server. The certificate is then mapped to an account recognized by the IIS server and, when the certificate is seen in the future, it is recognized as being verification of a specific user. From that point, all permissions that apply to the user are applied to the holder of the certificate. Either certificates can be mapped on a one-to-one basis with each being mapped to a unique user account, or a group of certificates can be mapped to a single account that has access to a Web site or set of data.
The use of server certificates enables encryption of Web transmissions by way of Secure Sockets Layer (SSL). The use of client certificates enables password-free authentication of browser clients. These two certificate uses can be independently utilized, or they can be utilized together.
Certificates can be purchased from a third party or created by the Windows 2000 Certificate Services (a product that is a part of Windows 2000). For Internet applications, third-party certificates are most often used because all browsers trust a default set of third-party certificate vendors and, therefore, no browser configuration is required to trust the certificates. For intranet applications, you can use the Windows 2000 CA, but all your browsers must be configured to trust your root certifier.
Requesting an SSL Certificate
The most difficult process of getting an SSL certificate installed on your Web server is getting the certificate in the first place. There are several reasons for this difficulty:
Establishing identity—In most cases you must have an outside party actually provide the SSL certificate so browsers will trust it. This means establishing your identity in a "positive" way to the certification authority.
Delay—Because a third party is involved there is a delay. Most professionals are used to being able to complete activities without the involvement of third parties, and the delay they cause can be frustrating.
Multiple standards—A few standards are used to make certificate requests. Each certificate authority might require different request formats.
Despite these challenges, requesting and receiving a certificate is not particularly difficult. Step By Step 3.14 shows you how to generate the request.
STEP BY STEP 3.14: Generating a Certificate Request
From the Start menu, select Settings, Control Panel, Administrative Tools, Internet Services Manager.
Click the plus sign to the left of the computer name.
Right-click one of the Web sites. (It doesn't matter which one.)
Click the Directory Security tab.
Click the Server Certificate button.
Click the Next button in the IIS Certificate Wizard to bypass the Welcome screen.
Click the Next button again to accept the default and create a new certificate.
Select the option to Prepare the Request Now, but Send It Later. You can select Send the Request Immediately to an Online Certification Authority if you're willing to send your request to one of the Microsoft-selected certification authorities.
-
Click the Next button to move to the next step, as shown in Figure 3.17.
Figure
3.17 The longer the key, the harder it is to break. Enter the name for the certificate. The default will be the name of the Web site. You should make this an externally meaningful name. It will appear in the certificate.
Set the bit length of the key. The more sensitive the information that will be transmitted, the longer the key length should be.
Click the Next button to move on to the next step.
Enter the organization and organizational unit information. This information will be encoded in the certificate and available to any user who wants to review the certificate. Be sure this information is externally meaningful. For instance, XYZ Group probably won't be helpful to a consumer reading the certificate.
Click the Next button.
Enter the site's DNS name, called a common name in the wizard. Note that any difference between what you enter here and how the browser refers to the site will be flagged to the user. Therefore, if you enter http://www.thorprojects.com and the user enters thorprojects.com in her browser, she will receive a warning message.
Click the Next button.
Enter the country, state, and city. This information is also visible to the browser. You might want to use the location information of the nearest large city rather than the name of the suburb that you are actually in.
Click the Next button.
Enter the name of the certificate request. You can specify any name you want—as long as you remember what it is.
Click the Next button twice to generate the file.
Click the Finish button to complete the wizard.
Click the OK button to close the site properties.
Close the Internet Information Services window.
)
Figure
3.17Now that you have the request file, it's time to send it off to a certification authority. In the next section you'll learn how to issue your own certificate if you have certificate services loaded. This will enable you to learn how to issue certificates. Normally, you'll want to send your request off to one of the public root certificate authorities.
Issuing Your Own SSL Certificate
If you install certificate services on a server within your enterprise, you will be able to issue your own certificate. Although your certificate won't be trusted by Web browsers, by default you can use it to test SSL in your own environment.
The process for submitting a certificate request is shown in Step By Step 3.15. If you have the appropriate administrative authority and the certificate authority your referring to is a part of Active Directory, you'll be assigned the certificate immediately.
STEP BY STEP 3.15: Submitting a Certificate Request to a Windows 2000 Certificate Authority
Log on with an administrative account.
Open Internet Explorer.
-
Enter http://servername/certsrv in the address bar.
Confirm that the Request a Certificate option is selected, and then click the Next button.
Select Advanced Request.
Click the Next button.
Select Submit a Certificate Request Using a Base64 Encoded PKCS#10 File or a Renewal Request Using a Base64 Encoded PKCS#7 File. This is the file you created in the previous section.
Click the Next button.
Open the certificate request file in Notepad.
Select all of the text and copy it to the Clipboard.
Close Notepad.
Paste the contents of the request file into the Saved Request box.
Change the Certificate Template to Web Server.
Click the Submit button.
If you have administrative privileges, you'll be issued a certificate immediately. Click Download CA Certificate, and save the resulting file. If the certificate isn't automatically authorized, you must refer to the Microsoft documentation on how to approve pending certificate requests.
Now you have a file that contains the certificate. The next step is installing it on your Web server.
Implementing an SSL Certificate
The process of implementing the SSL certificate is comparatively much more straightforward than requesting the certificate in the first place. Step By Step 3.16 shows you how to implement the certificate you requested.
STEP BY STEP 3.16: Installing a Certificate
From the Start Menu, select Settings, Control Panel, Administrative Tools, Internet Services Manager.
Click the plus sign to the left of the computer name to expand the list of Web and FTP sites.
Right-click the Web site you want to install the certificate to, and select Properties from the context menu.
Click the Directory Security tab.
Click the Server Certificate button.
Click the Next button to move past the welcome step.
Click the Next button to confirm that you want to process the pending request and install the certificate.
Enter the name of the file in the Path and Filename box. You can browse to the certificate file if you don't remember the name of the file.
Click the Next button to continue to the confirmation step.
Click the Next button to confirm that the certificate is correct.
Click the Finish button to complete the wizard and install the certificate.
Click the OK button to close the Web site properties.
Close the Internet Information Services window.
The process of installing the server certificate might involve more than a few clicks, but most of those are just confirming that the certificate is correct. When you installed the certificate, Windows 2000 automatically enabled SSL for the Web site and set the SSL port to the default SSL port of 443.
Enabling Client Authentication Using Client Certificates
Client certificates are an alternative form of authentication to the ones described in the previous sections. What sets this form of authentication apart from the others is that no passwords are required by the client when a browser connects to a site requiring authenticated access. Instead, the browser sends certificate information the Web server has mapped to a certain user account. Using this method, any browser can be used to connect to a site requiring authentication, without having to allow clear-text passwords and without requiring the user to actually log on using a username and password.
The steps for configuring authentication using client certificates are straightforward. First, the server must have a certificate installed issued by the same CA that the clients' certificates are coming from. This enables you to set the configuration to allow for client certificates for authentication.
Next, your clients must have certificates installed on their browsers. Similar to server certificates, these certificates need to be authenticated by a trusted source. If the browsers are connecting to an intranet, you could use the certificate services to generate a root certifier and client certificates. If the connection is to an Internet site, the clients will most likely use a third-party certificate vendor, such as VeriSign.
Finally, after the clients have certificates installed, these must be exported to the Web server and mapped to user accounts. After the mapping has occurred, the server can authenticate the client as being a particular user simply by being shown the client certificate. When the user is authenticated, access to resources is the same as that of any other authenticated user.
Step By Step 3.17 shows how to enable client certificates for authentication.
STEP BY STEP 3.17: Configuring a Web Server to Accept Client Certificates for Authentication
Install a server certificate on your Web server (see Step By Step 3.16).
From the properties of the Web site for which you want to enable client certificate authentication, click the Directory Security tab.
On the Directory Security tab, click Edit in the Secure Communications section.
In the Secure Communications dialog box, you can select Accept Client Certificates or (if SSL has been enabled) Require Client Certificates. Accept Client Certificates allows but does not require a browser to attempt to authenticate with this Web server using a client certificate. Require Client Certificates forces a browser to attempt to authenticate with this Web server using a client certificate; failure or lack of a certificate causes authentication to fail.
In the Secure Communications dialog box, select the check box labeled Enable Client Certificate Mapping, and then click the Edit button next to it. You can then add mappings between exported client certificates (provided by the clients) and user accounts (one-to-one mapping), or you can add a mapping between a root certifier and a user account (many-to-one mapping). A mapping between a root certifier and a user account ensures that anyone authenticating with a certificate from a specific root certifier will be given the same access on the Web site.
In the Secure Communications dialog box, you can also enable a Certificate Trust List (CTL). A CTL is a list of certifiers you trust. If a client tries to authenticate with a certifier not in the CTL, that certificate is rejected.
When configuration is complete, click OK to exit.
Troubleshooting Web Site Access
Web site access is about two things: access to a running server and security.
Lack of access because of security issues revolves around all the topics that have been covered in this section. Look for TCP port incompatibilities and fix them if they are discovered.
If a user is getting Access denied messages, check for authentication methods and underlying NTFS permissions. In addition, check for client certificates and see whether they are required. IP address restrictions also can cause these types of messages, so check for these, too.
If a user can get to your site but can't do what is desired (such as upload files or execute scripts), check for those permissions and adjust them if necessary.