Internet Server Security

Having taken a brief tour of the security features of Windows NT Server, we shall now discuss how security is applied to users accessing our web site and see how we need to change our view of network security when we come to connect to the Internet.

In this section, we move on to see how security issues apply to Active Server Pages.

File Access Controls

The IIS 4.0, ISAPI and ASP facilities are built upon the NTDS security model. This means that all files and directories are protected by ACL permissions, applied as described above. All users accessing the IIS 4.0 WWW service are either given guest access or authenticated (as we will see shortly), and then given appropriate access to the various objects.

In Chapter one we saw that the WWW service restricts the files on the server that can be accessed to those that are resident in the home directory, any virtual directories and any subdirectories in the hierarchy beneath.

The Directory's Access Permissions allows Read and Write permissions to be applied to the contents of IIS 4.0 directories. Enabling these checkboxes allows:

• Read—when enabled, the Web users may read or download files located in the directory
  
  
• Write—when enabled, the Web users may upload files or change the content of files located in the directory

Furthermore, the Application Settings Permissions specify whether applications located in this directory may be executed. The options are:

• None—no items located in this directory may be invoked
  
  
• Script—only scripts, such as ASP documents, located in this directory may be invoked
  
  
• Execute—any application located in this directory may be invoked

IP Access Security Issues

This section describes some of the security options available for TCP/IP (Transmission Control Protocol/Internet Protocol). This is the communications protocol used by the Internet or an Intranet. Most of the protocol's configuration is complex, and well beyond the scope of this book. This chapter's focus is intended to highlight the security options available, and not get sucked into any of the low-level complexities of data communications—there are numerous books available dedicated exclusively to TCP/IP. What we are interested in, is what we need to do to ensure secure operation.

All machines on the Internet (or an Intranet) are uniquely identified by four 8-bit numbers collectively known as an IP address. IIS 4.0 can be configured to either allow or deny access from any particular IP addresses. At first glance, you might think that this would provide a good mechanism for providing access control. However, the lack of available IP addresses has meant that many networks use techniques for randomly allocating IP addresses from an available pool, such as DHCP, when the client first starts—so in this case, you could not guarantee the identity of the user from the IP address.

The configuration of allowed/denied IP addresses is done using the IP Address and Domain Name Restrictions Manager section of the Directory Security property sheet.

In addition to IP addresses, all communication channels over the Internet / Intranet are identified by a number called a port. The value of the port number identifies the type of service operating on the channel. Some port numbers are reserved for common Internet services, for example:

Beginning with version 4.0, NT has the ability to filter IP protocol packets—allowing Internet services on particular ports to be either allowed or denied. Since you can use this to disable superfluous Internet services, NT can act in a similar way to a simple firewall. For example, you could configure NT with two network cards: one used to connect to the Internet, and the other to your LAN. Internet services on the Internet network card could be restricted to, for example, port

80

21

IP port filtering is enabled by means of the Network Control Panel. Select TCP/IP Properties on the Protocols tab. This provides an Advanced button, which displays a dialog including the Enable Security checkbox and a Configure button. This button finally produces another dialog where you can specify the filtering of ports.

To ensure that the TCP/IP stack does not transfer packets between the two network cards, the Enable IP Forwarding option on the TCP/IP properties must be unchecked.

If the clients accessing our site are within a known set of approved users, or a closed user group, we can make life awkward for casual surfers by changing the port number of our WWW service. The port number is configured using the Web Site property sheet. Users can access the HTTP service on a different port by specifying the port number as part of the URL. For example,

http://hornet.wrox.com:8080/

would be a web HTTP request on port

8080

User Authentication by the Web Server

In order to apply NT security to the access of HTML, Active Server Pages, and other files, every user accessing the web site must be associated with an NT user account. The process of determining the user's identity, and having confidence that it really is that person, is known as authentication.

Looking back at Authentication Methods dialog on the Directory Security property sheet, we can see that the WWW Properties page allows the following different authentication mechanisms to be configured

The checkboxes for all of these methods work independently, meaning that it is possible to enable multiple authentication mechanisms, and the appropriate one is then automatically used for a request.

The IUSR Account – Anonymous Authentication

When IIS 4.0 is installed, it creates a user account called IUSR_sysname where sysname is the computer name of the NT system, as specified in the Identification tab of the Network Control Panel. This account is assigned to the Guests account group, allocated a random password, and given the user right to Log On Locally—which is a prerequisite to access the IIS 4.0 WWW services. Provided that Anonymous authentication has been enabled, users accessing WWW services are allowed access to those resources with the permissions allocated to the IUSR_sysname account.

The Edit button on the Authentication Methods dialog allows the configuration of the Anonymous user.

The IIS 4.0 installation also creates another user account called IWAM_sysname. When we create Web applications that use process isolation, IIS 4.0 creates an MTS package that is set to run under the IWAM_sysname identity. This is discussed in Chapter 1.

Basic and Challenge/Response Authentication

Both the Basic Authentication and the Windows NT Challenge / Response mechanism, work in a similar fashion. If the user requests a resource for which the IUSR_sysname user account does not have the appropriate permissions, the request is rejected with a 401 Access Denied message, and the browser is informed through HTTP what authentication methods the server will support.

Provided that a least one of these two authentication methods has been enabled, most modern browsers will then prompt the user for a user name and password, and submit these details with another request for the same resource. IIS 4.0 will then validate the user account details supplied, and if successful invoke the request under the identity of this user rather than the IUSR_sysname account—thus having access to those resources for which the user account has permissions assigned. The difference between Basic Authentication and Windows NT Challenge/Response is that the latter provides encryption of the user name and password, whereas Basic Authentication sends this information as normal 'clear' text. At the time of writing, the only browser to support NT Challenge/Response is Microsoft's Internet Explorer.

The undesirable transmission of user names and passwords as clear text can be overcome using Secure Channel Services encryption – which we will meet shortly.

Another big advantage of using NT Challenge/Response methods and Internet Explorer in an Intranet environment is that, should the user be currently logged on to an NT domain, their user account name and password will automatically be tried. This avoids the need to duplicate any logon process when retrieving files. Hence, access by different users to different sets of files and information can be secured—transparently and automatically in a normal LAN-like manner.

Authentication in Action

The following HTTP trace files show WWW authentication in action. Firstly, Anonymous Authentication, where IUSR_sysname has Read permission for the file

/rich/rhnav.htm

-----------------------------------------------

Here, the request contains no account information about the user, just the usual HTTP Host IP address. The server logs on to NT using the IUSR_sysname account, and finds that it can access and retrieve the file—so it can return it to the requestor.

Next, we will see how Basic Authentication works. Both Anonymous Authentication and Basic Authentication have been enabled in the WWW Properties dialog. The difference this time is that the IUSR_sysname account does not have Read permission for the file:

-----------------------------------------------

-----------------------------------------------

-----------------------------------------------

-----------------------------------------------

So this process allows the web server to access files for which it does not have permissions, by simply passing on the user's ID and password. Providing that user has the correct permissions, NT then allows the web server to access the file, because it is acting on behalf of that user—this is called impersonation.

Lastly, let us look at the most complex of the three methods, Windows NT Challenge/Response. This time, all three types of authentication have been enabled in the WWW Properties dialog, and again the IUSR_sysname does not have Read permission for the file:

-----------------------------------------------

-----------------------------------------------

-----------------------------------------------

-----------------------------------------------

-----------------------------------------------

At this point, the user ID and password that user logged into their workstation, LAN or domain with, is used by the web server to access the file, instead of the IUSR_systemname account information. If the user has permission for the file, it will now be returned—just like Basic Authentication. In our example, however, things are not that simple. Let us assume that the user does not have permission for the file with the details they logged on to the LAN with. NT, and therefore the web server, will again deny the request:

-----------------------------------------------

-----------------------------------------------

-----------------------------------------------

-----------------------------------------------

-----------------------------------------------

It is only after the user has entered details of a user account, that the web server is granted permission to retrieve the file and return the contents back to the browser. This allows the administrator to effectively divide up the resources on the site. Some can be available to individual users, who have to supply the relevant passwords before they can access them, while others will be freely available to everyone.

Delegation

We shall now highlight one security pitfall that IIS 4.0 Web site designers frequently encounter. When a Web user is authenticated using the NT Challenge/Response mechanism, IIS 4.0 does not actually receive a copy of the user's password in the clear—instead IIS 4.0 receives an encrypted copy of the password which it passes onto the domain controller for verification.

The problem that this can cause is if there is any ASP logic that requires access to a resource on another Windows NT machine. The remote machine will initially challenge IIS 4.0 for proof of identification—however IIS 4.0 will be unable to participate in this authentication protocol because it does not have a copy of the users password and so cannot generate the appropriate messages. Microsoft claims that a solution to this will be available with Windows NT 5.0.

© 1998 by Wrox Press. All rights reserved.