|
This Issue
This article is a reprint of chapter 19, by Nelson Howell , in a new book called 'Using Microsoft Internet Information Server 4' from Que Education & Training (ISBN 0789712636) due for publication in early March 1998. This chapter covers advanced security concepts. Including: how to secure content Enforce security permissions for sensitive and private content and configuring user authentication understand and use authentication methods for securing content.
Introduction
Roadmap
- How to secure content
Enforce security permissions for sensitive and private content.
- Configuring user authentication
Understand and use authentication methods for securing content.
- Restricting user access
Use TCP/IP restrictions to limit the group of users who have access.
- Apply content rating
Material on your site may dictate that you need to use content rating features.
Perhaps the most important part of your server besides content is security. If there are no security measures in place, the safety of your data is at risk.
Many Internet and intranet sites use password authentication to limit the users who have access to specific content. Moreover, site administrators take advantage of features that provide Internet protocol (IP) address validation to secure content.
No matter what level of security you decided to use, you should have a firm grasp on the methods for securing the content hosted on your server.
This chapter explains the details behind security options available with Internet Information Server (IIS) 4.0. At the least, you'll be able to apply security restrictions with user accounts and passwords.
After that, you'll master using TCP/IP restrictions and authentication methods to secure your Web and/or FTP site.
Using the Security Accounts
Whether you're interacting with IIS as a user or as a possible administrator, you must have a Windows NT account with the proper rights.
IIS is no exception when it comes to interacting with the Windows NT operating system. You must supply a valid user name and password for interaction with IIS services and the file system. This is done using a special Windows NT account that has the proper access rights.
This account and other security accounts in IIS will be covered in this section.
Configuring the Anonymous User
You have the option to allow anonymous access to your site. If you want Internet or intranet users to connect without a user name and password, you'll need to provide anonymous access.
If, however, you want to enforce users to authenticate to the server, you must configure IIS appropriately. The section on "Using Authentication Methods" in this chapter details how to configure IIS in this way.
So, you've found yourself providing anonymous access to your site. As with everything in Windows NT, access to files and folders requires a valid user name and password. With IIS, the same theory holds true. To read a folder or file, IIS must have permission. You'll notice that the installation of IIS creates a user in the local domain named IUSR_servername. This special account is used by IIS to access the file system for anonymous connections to your site.
When IIS receives a request for an object, it uses this account to validate its access to Windows NT. So if you intend to provide anonymous access, you must make sure that this account is configured correctly in IIS.
To change the anonymous user setup for IIS, do the following:
- Open the Microsoft Management Console (MMC) if it's not already active.
- Activate the Computer Properties dialog by selecting the local server and choosing Properties from the Active menu.
- To configure your Web services, choose the WWW Service option from the Master Properties list box.
- Click the Edit button to activate the WWW Service Master Properties dialog for the local server.
- By default, the MMC displays the Web Site page. Click the tab labeled Security Accounts to view the Security Accounts page (see Figure 22.1).
Figure 22.1
Looking at the security accounts configuration for IIS.
Click Here For Figure
In the Anonymous User section of the Security Accounts page, you see the input boxes for the Username and Password of the anonymous IIS user. By default, IIS uses this specially created IUSR_servername account.
When the account was created, the IIS installation assigned the account a random password. Since the anonymous account will be used by IIS for anonymous connections, the account must have the right to log on locally. During creation, the account was granted this right to log on locally, which can be done manually through the user manager. This is needed since the account is used to access files and folders.
Note
When anonymous access is allowed for the FTP service, the inbound user is prompted to provide an e-mail address as a password. This e-mail address is not verified but it's used to help track the users of the FTP services.
You'll notice that no password is given in the password check box. This doesn't mean that the anonymous user has an empty password. Instead, IIS enables automatic password synchronization.
When this check box is active, you can't type the password for the anonymous user. IIS synchronizes the password, eliminating the need to provide the password explicitly.
This feature is beneficial when the password changes for the anonymous user. If you don't use automatic password synchronization, you must change the password in both User Manager for Domains and Internet Service Manager.
Note
The anonymous account must always have a non-null password. Even if you use password synchronization, the anonymous user can't be assigned a blank password.
If you decide to use a different account as the anonymous user, you can choose the account by clicking the Browse button from the WWW Service Properties dialog (see Figure 22.1).
Allowing Only Anonymous Connections for the FTP Server
With the FTP service, you can force all connections to be made anonymously. Using this feature, you can configure an Anonymous FTP Server. As noted before, even anonymous connections in FTP have to provide some information for logging.
To enable this feature, you'll go to the FTP Service Master Properties:
- Open the MMC if it's not already active.
- Activate the Computer Properties dialog by selecting the local server and choosing Properties from the Active menu.
- To configure your FTP services, choose the FTP Service option from the Master Properties list box.
- Click the Edit button to activate the FTP Service Master Properties dialog for the local server.
- By default, the MMC displays the FTP Site page. Click the tab labeled Security Accounts to view the Security Accounts page (see Figure 22.2).
Figure 22.2
Looking at the security accounts configuration for IIS.
Click Here For Figure
At the Security Accounts dialog, you see the check box labeled Allow only anonymous connections. When this checkbox is active, only anonymous connections are allowed. Even if the user connecting via-FTP inputs a valid NT account and password, the login is rejected.
To provide access for NT accounts, you must either clear this do the latter, you can clear the check box labeled Allow Anonymous Connections at the top of the dialog.
Note
Allowing connections that are not anonymous forces users to enter NT user names and passwords when connecting. These accounts must be created using the user manager utility. This alternative method is a security risk since non-anonymous connections transmit user names and passwords in clear-text.
Careful comparison of Figure 22.2 with Figure 22.1 reveals something interesting. Unlike the FTP service, the Security Accounts dialog can't disallow anonymous connections for the WWW service.
For the WWW service, disabling anonymous connections is made possible by changing the allowable authentication methods.
Adding Web Site Operators
Some of the administration of your site may seem complex but really very isn't. For example, you might encounter one or more of the following situations:
- As an administrator, you don't always administer the IIS services from the machine where IIS is installed. Instead, you work from another secure machine using the MMC for basic remote administration.
- A group of users are responsible for the administration of the site. Those Windows NT users must be able to do basic administrative tasks for IIS to perform their duties.
- The same group of users who are responsible for site administration shouldn't have any privileges outside of IIS. So they're not given the administrator password for the machine where IIS is installed.
These issues can be dealt with using the Web Site Operators function. The Web Site Operators are a group of Windows NT user accounts or groups that are given some administrative control over the IIS services.
These accounts or groups need not be part of the local administrator's group. These operators are restricted in the activities they're allowed. They can do tasks such as:
- Configure server access permissions.
- Enable and disable logging.
- Configure features, including custom HTTP headers, content ratings, and content expiration.
The operators, however, can't do tasks that need a higher level of security. The following tasks can't be done by the operators:
- Configure performance tuning such as the bandwidth throttle.
- Change virtual folder paths.
- Create new virtual folders.
- Change the Anonymous User configuration.
You can change the Web Site Operators list from the Security Accounts page shown in Figure 22.1. Use the Add and Remove buttons to add or remove Windows NT accounts and groups, respectively.
It's important to note that the users must have access to the MMC application. The MMC allows the users to connect to the IIS services remotely once they've been added to the group of Web Site Operators.
Tip
It's generally a good idea to create a local group of users who should have operator privileges for the IIS services. Once you've created a group in Windows NT, you can add that local group to the list of Web Site Operators.
Changing File and Folder Permissions
Once access is granted to the file system, you can dictate what level of access is allowed. In Windows NT, you can do this for an account and/or group. A similar restriction is configurable on a folder basis, file basis, or for your whole site.
The access restrictions in IIS are not a replacement for but a complement to those in Windows NT. The two sets of rules work together to provide the highest level of security you're seeking.
Access Permissions
When you configure access through IIS to a local folder or network share, you can set the read and control access for folders and files. The set of permissions are fairly simple:
- Read
The user can read the file or folder in question.
- Write
The user can create content in the folder in question. Similarly, if write permission is given on a file, the user can change the contents of the file, including the ability to overwrite the file.
Don't forget about the NTFS permissions if the folder or file is located on an NTFS volume. When IIS checks the access rights to determine what security level the users should have, the IIS settings and NTFS permissions are merged.
They are merged, however, to provide the most restrictive access rule. Let's say that you allow a user to have write access on a file in IIS, while providing only read access in the NTFS permissions.
When IIS enforces security, the user can only read the file since the NTFS permissions are more strict than the IIS security settings. The same most-restrictive rule holds true even when the NTFS permissions grant more rights than IIS.
Tip
It's generally a good idea to disable Read access (within IIS) for folders holding Active Server Page (ASP) scripts, common gateway interface (CGI) applications, or Internet services application interface (ISAPI) applications. If Read access is enabled, that client can download the program instead of executing it. The NTFS permissions, however, must include Read access at the system level.
To change the state of read and write access permissions, let's go back to the MMC:
- Open the MMC if it's not already active.
- Activate the Computer Properties dialog by selecting the local server and choosing Properties from the Active menu.
- To configure your Web services, choose the WWW Service option from the Master Properties list box.
- Click the Edit button to activate the WWW Service Master Properties dialog for the local server.
- Click the tab labeled Home Directory to view the Home Directory page (see Figure 22.3).
Figure 22.3
Configuring the access permission for the WWW services.
Click Here For Figure
Toward the middle of the page on the left-hand side, you see the Read and Write check boxes. By default, IIS provides read access to all files and folders. To enable or disable these permissions, activate or clear the appropriate check boxes, respectively.
When you look at the Home Directories page for the WWW or for the FTP service, you'll see the same options for read and write permissions. In both services, you can also enable these permissions for files and folders.
From your MMC, you can view the Properties of an individual file or folder. When you open the Properties dialog, you have the same set of check boxes available to set Access Permissions.
Note
The write permission for the WWW service depends on the use of HTTP 1.1 by the client's browser. The HTTP 1.1 specification uses the PUT request type and must be accepted by the client for the write permissions to be useful.
Content Control and Application Settings
In addition to providing users read and write access, IIS allows the configuration of content control and custom application settings for the WWW service. In general, content control covers features that dictate how content is managed and displayed.
Web masters will enable some of the following options depending on what is needed:
- Access Logging
Detailed log information is recorded on requests made for specific files and folders.
- FrontPage Web
The content within the Web site can be modified and maintained using Microsoft FrontPage.
- Folder Browsing
Users are allowed to "browse" folders within the web site, as opposed to seeing only HTML pages.
The content control feature most related to security is the ability to browse server folders.
Setting the Default Page
Browsing folders is convenient but it's a potential security risk. If you allow folder browsing, a user can view the contents of a folder as in Windows NT Explorer.
To provide this ability, activate the check box labeled Directory browsing allowed on the Home Directory page shown in Figure 22.3.
If you don't want to allow folder browsing, you must configure IIS to use a default document. The default document name is used when the WWW service gets a request for a folder without a file name included.
For example, a URL might take the form:
http://servername/documents/private/
When the Web server gets this request, it only knows what path the user has requested. The user hasn't requested any specific document in that folder, just the main document.
Another example is a more common URL:
http://www.companyname.com/
These WWW addresses don't hold any information about a specific page. The user is trying to say "give me the main document for this folder." This main (default) document is the page displayed by the WWW server.
On most UNIX systems, Web servers use index.html as the default name for a document. IIS gives you a way to configure several default document names.
Let's step through an example to configure the default document names:
- Open the MMC if it's not already active.
- Activate the Computer Properties dialog by selecting the local server and choosing Properties from the Active menu.
- To configure your Web services, choose the WWW Service option from the Master Properties list box.
- Click the Edit button to activate the WWW Service Master Properties dialog for the local server.
- Click the tab labeled Documents to view the Documents page (see Figure 22.4).
- IIS provides the default document names Default.asp and Default.htm. To configure an additional default document name, click the Add button to open the Add Default Document dialog. Or click the Remove button to delete default document names you don't want.
Tip
You can use the MMC to set default document names for individual folders. In the MMC, view the properties of a folder and go to the Documents page. There, you can configure default document names specific to that folder.
- Enter the default document name (including extension) and click the OK button to apply your addition.
- You'll notice the arrows on the left-hand side of the dialog. These are used to rank the preference for each of the default document names.
If you want the WWW service to search for Default.asp before Default.htm, use the arrows to move the ranking for Default.asp.
- When you've finished, click the Apply button and the OK button to return to the MMC.
Figure 22.4
Investigating the default document settings for the WWW service.
Click Here For Figure
Note
You can't remove all the default document names from the list. You must provide at least one default document name for a folder.
Configuring Application Settings
Later in the book, we'll discuss the creation of custom applications and how the user interacts with these applications. Before that, however, we'll take a brief look at the security involved with making these applications available on your Web site.
The Home Directory page shown in Figure 22.3 has a section for Application Settings. You'll notice that three radio buttons toward the bottom of the Application Settings describe the permissions available for custom scripts and applications.
Table 22.1 shows the security options for scripts and applications.
Table 22.1
Security Options for Scripts and Applications
| Option | Description |
|---|
|
None | This option disables the execute abilities for the folder in question. Apply this option to any folders in which scripts and applications are not present.
|
|
Scripts | Any scripts that use a scripting engine (IDC and ASP scripts) can run in the given folder. This means you don't need to enable the Execute permission at an NTFS level.
This option is safer since it limits access to scripting engines exclusively, without needing the Execute permission.
|
|
Execute | This allows any script or binary to be executed in the given folder. All .EXE or .DLL files can be executed.
This option may be insecure, depending on what binaries are in the given folder.
|
Taking a closer look at Figure 22.3, you see the check box labeled Run in separate memory space. For scripts or applications you develop, IIS offers a feature to run those scripts and applications in a separate memory space.
Although the option is grayed out, once you create an application setting, it becomes visible.
Choosing to run scripts and applications in a separate memory space is something you should consider. When this option is enabled, any script or executable is placed in a memory space outside the memory space occupied by IIS.
Thus, if your script or application freezes, the IIS services are unaffected. If, however, you don't take advantage of this feature, you run the risk of your custom applications affecting your IIS services.
Caution
Sharing the IIS memory space with scripts can be very dangerous. For example, if your scripts fail or loop without end, your IIS services stop. Moreover, if the script failure is serious enough, your machine might need to be restarted to recover from the errors.
Publishing Content from Network Shares
Let's say you have another file server that automatically generates reports. These reports reside on that server, available through a file share in Windows NT.
You've decided that you want to publish these reports to your Web site even though the files don't reside on the local drive.
You have two options:
- Copy the reports from the remote server to the local server. Since you don't want to have a duplicate copy on the local machine, you don't pursue this route.
- Find a way to publish the content from the network file share without making a local copy.
With IIS, you're not limited to publishing content that only resides locally. You can instruct the WWW service to display content that's available from a local network share.
From the Home Directory page (see Figure 22.3), the WWW service asks where the content should come from when connecting to the given resource.
Let's step through an example of publishing information from a shared folder:
- Open the Home Directory page if it's not already active (see Figure 22.3).
- Click the radio button labeled A share located on another computer. Notice that the Local Path text box changes to Network Directory. Similarly, the Browse button changes to a Connect As button.
- In the Network Path text box, give the name of a file share. The WWW service expects a file share in the form of \\servername\sharepoint.
- Click the Connect As button to view the Network Directory Security Credentials dialog.
- Fill in the Username and Password text boxes, and click the OK button to apply the changes.
- Click the Apply button and then the OK button to finish your configuration changes.
Note
When you enter the information for Network Directory and the appropriate security credentials, no validation is done. If any of the information was incorrect, you won't know until you try to connect through a Web browser.
As an alternative, manually try making a connection to the share with the given user name and password. You can use the command line utility net in Windows NT to make a connection, or by using "Map Network Drive" option available from Windows Explorer.
For more information, type "net use /?" at the command prompt.
When the WWW service tries to publish information from the share folder, it treats the request like all others. The only exception is the user name and password. This security information is used to make a secure connection from the IIS server to the remote file server.
Caution
Depending on your network configuration, publishing content from a shared folder can be slow. Since the content isn't on the local disk, it must be transferred from the remote machine to the IIS server over the network.
The WWW service still tries to use caching techniques to improve performance until the cached content becomes outdated.
Understanding File and Folder Security
The folder security options are different from those mentioned already. The options we'll discuss involve authentication, encryption, and other methods of validity checking.
Using the MMC, you can set options for encryption and authentication per page or per folder for your WWW service. In addition, TCP/IP restrictions can be enforced for your WWW and FTP services.
Although not discussed in this chapter, you can configure secure communications for your WWW services. Secure communications provide encrypting of all data transferred between your server and a user's browser.
Chapter U, "Secure Transmissions with IIS (HTTPS)" discusses the benefits of Secure Sockets Layer (SSL) and how to configure your server to use SSL.
Here we discuss permissions in terms of the first stage of connection to the server. Read and write permissions, covered earlier in this chapter, are used after the connection is made.
Using Authentication Methods
Authentication is done when the HTTP request is received by the Web server. Before a client can access WWW services, the authentication must be successful.
The advantage is that secure content can be protected using Windows NT accounts for authentication. Each method of authentication in IIS has benefits and drawbacks.
To configure an authentication method, let's go back to the MMC:
- Open the MMC if it's not already active.
- Activate the Computer Properties dialog by selecting the local server and choosing Properties from the Active menu.
- Choose the WWW Service option from the Master Properties list box.
- Click the Edit button to activate the WWW Service Master Properties dialog for the local server.
- Click the tab labeled Directory Security to view the Directory Security page (see Figure 22.5).
- Click the Edit button in the Password Authentication Method area to view the Authentication Methods dialog (see Figure 22.6).
Figure 22.5
Looking at the security options in the IIS WWW service.
Click Here For Figure
Figure 22.6
Inspecting authentication methods in the WWW service.
Click Here For Figure
Note
The authentication methods discussed next (with the exception of anonymous access) apply only to the WWW service. The FTP service provides only anonymous access or secured access with a user name and password authentication scheme.
Note that the user name and password authentication in the FTP service passes information in an unencrypted format over the network.
Anonymous Access
As described before, anonymous access for WWW services is used to provide open access to your WWW content. If you intend to allow users to browse HTML documents and ASP scripts without authentication, you must enable this check box.
The drawback to this option is the lack of security. Any user can gain access without a password. If the content you're serving is not private, this won't be a drawback. For private content, use Basic Authentication or NT Challenge/Response.
You can configure all three authentication types to be present. The Basic Authentication and Challenge Response methods are enforced when anonymous access fails for an object request.
IIS first tries authentication using Windows NT Challenge/Response, if the client accepts it. If authentication using Challenge/Response fails, IIS tries the Basic Authentication. If both authentication attempts fail, the user is denied access and gets an error message.
Note
To use authentication methods other than Anonymous, you must have IIS installed on an NTFS partition. Without the assignment of NT permissions, IIS can't enforce the authentication methods that need special access.
Basic Authentication
Basic Authentication secures private content by requiring the user to authenticate with the WWW service at the first request. Basic Authentication is initiated in only one of two circumstances:
- Anonymous access is not allowed
- Anonymous access is allowed, but the NTFS permissions on the request object need authentication and the attempt to use NT Challenge/Response failed because it wasn't configured or the client didn't accept it.
When IIS begins Basic Authentication, the user's client prompts for a user name and password. This user name must be a valid Windows NT account that has enough NTFS permissions to carry out the object request.
This means if a user gives the user name METAMOR\PLUMMER, they at least needs read access at the NTFS level. To verify that the NTFS permissions are correct, inspect the permissions on the given file or folder to see what accounts or groups have access.
Note
When enabling Basic Authentication, you'll be prompted with a dialog box warning you of the implications. Any user names and passwords sent with Basic Authentication are done so in an unencrypted, clear-text format.
Inspection of this information could reveal NT accounts and passwords that would risk the security of your network. To avoid this security problem, consider using NT Challenge/Response for a fully encrypted authentication.
When Basic Authentication is enabled, an Edit button is visible (see Figure 22.6). Clicking this button opens the Basic Authentication Dialog (see Figure 22.7). This dialog allows you to specify what the default authentication domain should be.
Notice that the sample user name was METAMOR\PLUMMER. The METAMOR portion specifies the Windows NT domain, whereas PLUMMER describes the Windows NT account.
Configuring a default domain eliminates the need for users to type a domain name and back slash.
Figure 22.7
Specifying the default domain for Basic Authentication.
Click Here For Figure
Windows NT Challenge/Response
You've noted some problem areas with authentication where encryption is concerned. Windows NT Challenge/Response authentication provides the functionality sought in Basic Authentication but with encryption.
Challenge/Response is engaged when:
- Anonymous access is not allowed
or
- Anonymous access is allowed but the NTFS permissions on the request object need authentication
During authentication, IIS participates in an information exchange with the browser using a special cryptography. The user doesn't have to enter any user name or password information.
Instead, this automatic exchange of information doesn't send user names and passwords over the network but authenticates the client in a highly encrypted form.
Note
Windows NT Challenge/Response authentication only works with the Microsoft Internet Explorer (IE) browser, versions 2.0 and later. Moreover, it's necessary for the user to have logged onto the local computer via the Windows NT network.
Changing NTFS Permissions
For your WWW service to enforce Basic Authentication or Windows NT Challenge/Response, you must change NTFS permissions on the files and folders you want protect. The NTFS permissions serve as an Access Control List (ACL) that Windows NT and IIS use to grant permissions to users and groups.
These permissions give your trusted users a way to access to your confidential data. At the same time, the permissions protect your data from untrusted accounts or groups.
Let's step through an example of placing NTFS permissions on some files and folders.
- Open a Windows NT Explorer window. Traverse the folder structure of your machine until you reach the InetPub folder.
- Select a subfolder of InetPub and choose Properties from the File menu to open the Properties dialog.
- By default, the properties dialog shows the General page. Click the tab labeled Security to view the Security page.
- Click the Permissions button to show the Directory Permissions dialog (see Figure 22.8). If you're setting permissions for a specific file, you'll see the File Permissions dialog.
Figure 22.8
Looking at the Directory Permissions for a folder on an NTFS partition.
Click Here For Figure
As you can see, some sample permissions have been set for this test folder. You learn about the permissions and what happens in terms of authentication.
- Administrators (Full Control)
For administration, the local administrators have full rights over the files. In terms of WWW access, if members of this group connect to the site, they can read all the files there unless individual file or subfolder permissions prohibit such access.
Moreover, if write access was configured through IIS, a member of the administrators group can use the PUT method to place files in this folder.
- IUSR_METAMOR (No Access)
This keeps the anonymous user from accessing the files and subfolders. Typically, you can achieve the same purpose by removing any permissions for the IUSR_Servername account.
The purpose of specifying no access here is to make sure that the anonymous user doesn't have access as a part of the Web users group. Just in case the anonymous account is part of this group, specifying no access prevents any anonymous connections to this folder.
- Web Operators (Add and Read)
For my test system, I have some operators who are allowed to add content and read content. To authenticate, any member of this group can read all the files and subfolders.
Also, if Write access is enabled for this folder, members of the Web operators group can use the PUT method to upload content to this folder.
- Web Users (Read)
This group of users allows read access to all the files and folders. This general group has a listing of NT user accounts that I've found acceptable for authentication.
When connecting to the WWW service, these users can only read documents in this folder unless otherwise specified on a file level.
Tip
It's generally unadvisable to provide write access (through IIS) to folders in your WWW site structure. If users on your NT network need to update content, they should do so through file shares, a more secure method of connection. If you find it necessary to use the PUT method through write access, use a special folder in your site.
Using TCP/IP Restrictions
Another way to secure your server and content is through IP address restrictions. Since IIS knows the IP address of the computer issuing the request, IIS can use this information to make decisions about security. The TCP/IP restrictions are processed before any attempt for authentication is made.
Using TCP/IP restrictions gives you a way single out a group of users, or a single user, who should have access to your server's content. You may, for example, have an intranet site that should only be accessible from a group of IP addresses.
As a first line of security, you can configure IIS to reject all requests that don't fit the IP address criteria. You can grant or deny access for the following criteria:
- Any computer connecting from a single IP address.
- Any computer connecting from a range of IP addresses (including subnet mask).
- Any computer connecting from a single host name.
- Any computer connecting from a particular domain name.
Let's make some TCP/IP restrictions to see what your exceptions will look like:
- Open the MMC if it's not already active.
- Activate the Computer Properties dialog by selecting the local server and choosing Properties from the Active menu.
- Choose the WWW Service option from the Master Properties list box.
- Click the Edit button to activate the WWW Service Master Properties dialog for the local server.
- Click the tab labeled Directory Security to view the Directory Security page (see Figure 22.5).
- You're going to put some astringent security restrictions on this site. Mark the radio button to indicate that By Default all computers are Denied Access.
- To add access for your users, click the Add button to bring up the Grant Access on dialog.
- Select the option to grant access to a Single Computer, and provide the proper information (see Figure 22.9).
- Now grant access for a user from a domain name. Repeat Step 7 but provide a domain name instead. You'll see a dialog warning you of the performance implications of using a domain-name TCP/IP restriction.
Note
The warning tells you that using a domain name or host name may result in a degradation of performance. When IIS restricts connections based on a name that needs reverse DNS resolution, it must wait until an answer is received to translate the IP address of the inbound machine into a host name or domain name. Typically, it's better to stick with TCP/IP restrictions based on IP addresses.
Figure 22.9
Granting access for a single computer with the TCP/IP restrictions.
Click Here For Figure
- Once you've entered the proper information, the Properties dialog comes back into view. The dialog (see Figure 22.10) shows you the TCP/IP restrictions you've put in place.
Figure 22.10
Inspecting the TCP/IP restrictions after making changes.
Click Here For Figure
Now you've added access for a particular group of users. Any user connecting from metamor.com or the IP address 10.15.23.4 is granted access.
Any other clients making requests are denied and given an error message. The same level of TCP/IP restrictions can be configured for the FTP service.
Enforcing Content Rating
The IIS features include a way to apply content ratings to your site. You can secure your site from others if they're unwilling to explore the content your site provides.
The content ratings for your WWW services were determined by the Recreational Software Advisory Council (RSAC). This council rates content on four criteria, including violence, nudity, sex, and language.
The WWW service in IIS enforces these criteria through a Platform for Internet Content Selection (PICS).When users connect to your site, if Content Rating is enabled, the ratings are passed to the client in the headers.
Let's take a look at what the content rating system has to offer:
- Open the MMC if it's not already active.
- Activate the Computer Properties dialog by selecting the local server and choosing Properties from the Active menu.
- Choose the WWW Service option from the Master Properties list box.
- Click the Edit button to activate the WWW Service Master Properties dialog for the local server.
- Click the tab labeled HTTP Headers to view the HTTP Headers page.
- Click the Edit Ratings button to view the Content Ratings dialog. The default page for this dialog, Rating Service, provides buttons that point to URL links for further information on the rating process.
- Click the tab labeled Ratings to view the Ratings page (see Figure 22.11).
Figure 22.11
Setting the content ratings for the WWW service.
Click Here For Figure
- To make some sample ratings, click the check box labeled Enable Ratings for this resource. When enabled, the remaining fields in the dialog box become viewable.
- If you select one of the ratings, a slide control becomes viewable in the area labeled Rating. As you move the slide control, a level appears with an appropriate title.
- You can give your e-mail address if you're the person responsible for administration of the WWW server.
- Click the Date button to show the Select Date to Expire dialog. In this dialog, you can select the date when the given ratings expire.
This is especially useful if the content you need to rate will only be posted to your WWW site for a short period of time.
The Content Ratings are shown in Table 22.2, including the levels of each rating.
Table 22.2
Content Ratings and the Appropriate Levels
| Content Rating | Level | Description |
|---|
| Violence | 0 | None |
| 1 | Fighting |
| 2 | Killing |
| 3 | Killing with Blood and Gore |
| 4 | Wanton and Gratuitous Violence |
| Sex | 0 | None |
| 1 | Passionate Kissing |
| 2 | Clothed Sexual Touching |
| 3 | Non-Explicit Sexual Touching |
| 4 | Explicit Sexual Activity |
| Nudity | 0 | None |
| 1 | Revealing Attire |
| 2 | Partial Nudity |
| 3 | Frontal Nudity |
| 4 | Provocative Frontal Nudity |
| Language | 0 | None |
| 1 | Mild Expletives |
| 2 | Moderate Expletives |
| 3 | Obscene Gestures |
| 4 | Explicit or Crude Languages |
For more information on the RSAC organization or content rating, visit the URL http://www.rsac.org/.
From Here
This chapter gave you an overview of advanced security features available with IIS. With this knowledge, you'll be able to secure your WWW and FTP services. The TCP/IP restrictions we covered will allow you to enforce a basic level of security for users connecting to your site. The advanced examples covered security permissions and authentication that you'll use to secure your site and content.
This chapter ends with details on the use of the content rating features of IIS. Other chapters will cover Active Server Pages (ASP) and database access that will employ the use of the security features covered in this chapter.
- Chapter 3, "Understanding Windows NT and IIS," gives you an overview of the integration between Windows NT and IIS.
- Chapter 21, "Secure Transactions with IIS (HTTPs)," covers the security advantages using SSL, in addition to the other features already discussed.
- Chapter 24, "Using Active Server Pages on Your Site," discusses creating applications for your site using VBScript and HTML.
- Chapter 27, "Building Database Access with the Internet Database Connector," is a discussion of IDC applications and providing dynamic content from databases.
|
