Web Server Security

This section discusses how to achieve Web server security with the three most popular Web servers: Microsoft's Internet Information Server (IIS), Apache HTTP Server, and Sun ONE Web Server.

NOTE

The information in this section refers to ColdFusion server when integrated with an external web serverIIS, Apache, or Sun ONE. For information on configuring ColdFusion with an external web server see the Web Server Management section of the Configuring and Administering ColdFusion MX at http://livedocs.macromedia.com/coldfusion/7/htmldocs/00001750.htm.

Microsoft Internet Information Server (IIS)

Because IIS is an integrated part of the Windows 2003 and XP operating systems, the two work closely together to enable the securing of resources. This combination allows administrators to create user accounts on the Web server, with granted or denied access individually. By default, most directories and files are left available to anonymous access, meaning no authentication or authorization is required.

IIS offers two types of security:

• Determining the type of file access available (read, write, script). ColdFusion requires only script access by default, but might need read or write access if tags such as <cffile>, <cfdirectory>, <cfcontent>, or <cfftp> are to be used.

• Anonymous access and authentication controls. These let you determine on a directory-by-directory basis whether to allow anonymous access and, if not, what type of authentication to use.

To set the access permissions for a particular directory in IIS, do the following:

1.	Open the Microsoft Management Console (MMC) for IIS by selecting Start > Programs > Administrative Tools > Internet Services Manager (ISM).
2.	Within the MMC, explore the applications, expanding the menus to find the directory you want to explore. Figure 8.5 shows the CFIDE directory highlighted in the ISM. Figure 8.5. The Microsoft Management Console is used to apply security via IIS.
3.	Right-click the directory name and select Properties from the context menu. This opens the properties sheet for the directory (Figure 8.6). Figure 8.6. Read Access Permissions and Scripts Only execute permissions can be granted from the Directory tab within IIS.
4.	In the Directory tab of the properties sheet, select the check boxes to designate whether you want to allow read or write access.
5.	In the Execute Permissions list box, choose whether you want to allow Scripts Only, or Scripts and Executables.
6.	Click Apply to execute your changes, and then click OK.

Similarly, use the ISM to integrate Web permissions with the appropriate NTFS access controls. To change a directory from allowing anonymous access to allowing access only to members of the domain-level Administrators group, follow these steps:

1.	Open the ISM, as previously described.
2.	Find the directory from which you want to remove anonymous access.
3.	Right-click the directory name and select Properties.
4.	Select the Directory Security tab (Figure 8.7). Figure 8.7. The directory's Directory Security tab allows administrators to control whether the directory is accessible from the Web root.
5.	In the Authentication And Access Control section (or for Windows XP, the Anonymous Access And Authentication Control section), click the Edit button. This opens the Authentication Methods dialog box shown in Figure 8.8. Figure 8.8. The IIS Authentication Methods dialog box lets administrators determine who can access the directory and what authentication method to use.
6.	Uncheck the Enable Anonymous Access option (or Anonymous Access for Windows XP).
7.	Select a check box to indicate whether you want to use Basic authentication or Integrated Windows authentication. These are described in the section that follows, "Basic Authentication vs. Integrated Windows Authentication."
8.	Click OK to close the Authentication Methods dialog box.
9.	In the directory's properties sheet, click the Edit button in the IP Address And Domain Name Restrictions section. This opens the dialog box shown in Figure 8.9. Figure 8.9. Enter IP addresses to deny or grant access to the IIS resource.
10.	Use the IP Address Access Restriction dialog box to enable or limit access to all IP addresses or a specific subset. You can also either grant or deny access to all IP addresses by default: To deny access to a single address or group of addresses, select Granted Access and click the Add button. In the next dialog box (Figure 8.10), enter IP addresses to deny access. Click OK to close. Figure 8.10. Enter IP addresses to deny access. To grant access to a single address or group of addresses, select Denied Access and click the Add button. In the next dialog box (Figure 8.11), enter IP addresses to grant access. Click OK to close. Figure 8.11. Enter IP addresses to grant access.
11.	Click OK to close IP Address and Domain Name Restrictions, and again to close the properties sheet.

Basic Authentication vs. Integrated Windows Authentication

Microsoft offers two methods of authentication. Basic authentications works with all browsers, but unless the request is made through the Secure Socket Layer (SSL), the user name and password are sent in cleartext. This makes the user name and password vulnerable to hackers. In general, you should try to force any Basic authentication logins to use SSL.

Integrated Windows authentication (a.k.a. Windows NT Challenge/Response, or NTLM, in previous IIS versions) is more secure because it uses a cryptographic hash to send authentication information to the Web server. However, this type of authentication is available only to Microsoft Internet Explorer (IE) users. Integrated Windows authentication uses IE's knowledge of the current Windows user's account information to provide authenticationbypassing the need to prompt for username and password. If this initial authentication exchange fails, IE will then prompt for a valid Windows user login.

TIP

ColdFusion's RDS (Remote Development Services) is not supported over Integrated Windows Authentication/NTLM.

You must choose carefully which type of authentication you will offer on a site. Each type has its own benefits and liabilities.

CAUTION

A third authentication method is available to domain controller (DC) serversDigest authentication. However, because Macromedia does not recommend installing ColdFusion on DCs, we do not discuss this method.

Apache HTTP Server

Apache offers several ways to restrict file access. Access control is provided by the mod_access and mod_auth modules. However there are also several other modules that provide authentication and authorization, such as mod_auth_dbm, mod_auth_digest, and mod_auth_ldap. Administrators can use the directives provided by these modules in the <Directory>, <Files>, or <Location> sections main configuration file (httpd.conf) or a distributed configuration file (.htaccess) at the directory level. This section will explore access control provided by the mod_access and mod_auth modules within the <Directory> section of httpd.conf and the .htaccess file.

NOTE

For more information on securing resources with Apache, including additional modules, information on creating and using user group files, and storing user information in a database file, see the documentation for your Apache HTTP server at http://httpd.apache.org/docs-project/.

Using htpasswd

To enable user authentication in Apache, you must create a file that contains user names and passwords. Then you must tell the server must which files or directories are protected and which users are allowed to access the protected files. The user name and password file will have a format very similar to that of a standard Unix password filethe user name is separated by a colon (:) from the encrypted version of the user's password.

Apache ships with a command-line program called htpasswd, which is used to create a user file or to add, edit, or delete a user from that file. You can find htpasswd in the support directory of your Apache distribution. You might need to modify its makefile to reflect any changes made in your compilation of Apache, and then compile htpasswd and move the binary into a directory in your path.

To create a new users file and add the users ben, jeff, and dave, follow these steps:

1.	Open a command prompt. If it is not already in the system path, navigate to the apache_root/bin directory, for example: /opt/apache2/bin
2.	At the command prompt, enter the following: htpasswd c /opt/etc/httpd/users jeff CAUTION For security reasons, this user file should not be created under the Web root.
3.	Enter a password for jeff and press Enter. Confirm the password and press Enter.
4.	To add the user ben, enter: htpasswd /opt/etc/httpd/users ben NOTE The -c switch is only used to create the password file. Once the file is created do not use it to add users to the existing file.
5.	Enter and confirm a password for ben.
6.	Repeat step four above replacing ben with dave.
7.	Enter and confirm a password for dave.

The -c argument used in step 2 tells htpasswd to create a new users file. When this is run, you are prompted to enter a password for the new user and to confirm it. Information for each subsequent user is created in the same way, but without the -c argument. Running the htpasswd command with a user name already in the file allows the user's password to be changed.

After adding jeff, ben, and dave, the file looks similar to this:

 jeff:rJTLLCFs05E98 ben:QgJ132JSTlc08 dave:nO43dREW69iDG 

You can see that the file is simply the user name followed by a colon and the encrypted password.

Restricting Access

After you have created a users file, you can use the mod_access and mod_auth directive to declare security directives for an entire directory tree in the <Directory> section of the httpd.conf or in individual distributed configuration files. The mod_access module provides access control based on the client's:

• Host name or domain name ( www.ows.com)

• Full or partial IP address (192.168.1.120 or 192.168)

• IP address and subnet mask (192.168.0.0/255.255.0.0)

• IP address and CIDR (Class-less Inter-Domain Routing) address (192.168.0.0/16)

• Environment variables in the Request header

TIP

Apache performs double reverse-lookups on host and domain names to translate them to IP addresses. This can be a lengthy process, particularly if the server's DNS is not properly configured. Use IP addresses instead of host or domain names to circumvent this overhead.

Table 8.2 describes the mod_access directives.

Table 8.2. mod_access Directives

DIRECTIVE	DESCRIPTION
Allow	Specifies which hosts to grant access the web server
Deny	Specifies which hosts to deny access to the web server
Order	Specifies the default web server access permission, and the order in which the Allow and Deny are evaluated

The mod_auth module provides access restriction via HTTP Basic Authentication. In this section we will use the AuthUserFile directive to specify the name of the file containing the user names and passwords for authentication. Table 8.3 describes the mod_auth directives.

Table 8.3. mod_auth Directives

DIRECTIVE	DESCRIPTION
AuthAuthoritative	Specifies whether to pass authorization and authentication to lower-level modules
AuthGroupFile	Specifies the name of the file containing user groups
AuthUserFile	Specifies the name of the file containing user names and passwords

The <Directory> section is read at startup and provides default access control. The <Directory> container has the following syntax: <Directory directory-path> ... </Directory>. Administrators specify directives between the <Directory> and </Directory> tags that they want to apply to the named directory and its subdirectories. The following is a simple <Directory> section for securing ColdFusion's CFIDE directory:

 <Directory /CFIDE>   Options Index FollowSymLinks   AllowOverride None </Directory> 

The distributed configuration file is a text file containing Apache directives or instructions about the security settings for the directory in which it is located, and any subdirectories below it. In order to use distributed configuration files within a directory, you must specify the AllowOverride directive in the <Directory> section. AllowOverride determines which directives to permit in the distributed configuration file for the specified directory path. Like most things in Apache, the distributed configuration file's filename is configurable. You can specify the filename that will be used to control access by using the AccessFileName directive in the server's httpd.conf file. By default, you will find the directive:

 AccessFileName .htaccess 

in your httpd.conf, but you are free to change this to any other name you want. For instance, changing it to:

 AccessFilename jeff.acl 

tells Apache to use the settings in a file called jeff.acl for security directives.

CAUTION

If you change the default access file name you should also add a <Files> directive to prevent web access to the file. Consult your Apache HTTP server documentation for more information on the <Files> directive at http://httpd.apache.org/docs-project/.

To use the access restrictions specified in an .htaccess file for the CFIDE directory, create a <Directory> section in your httpd.conf file like the following:

 <Directory /CFIDE>   Options Index FollowSymLinks   AllowOverride AuthConfig </Directory> 

Now restrict access to only those users listed in the user file by creating an .htaccess file in the CFIDE directory and add the following commands:

 AuthName "authenticated users only" AuthType Basic AuthUserFile /opt/etc/httpd/users require valid-user 

The first directive, AuthName, specifies a realm name. After a user has been authenticated for a particular realm, they need not be re-authenticated for that realm for the remainder of their session.

TIP

Directives like AccessFileName, AllowOverride, AuthName, and Options are part of the Apache core features and are always available. Consult your Apache HTTP server documentation for more information on the <Files> directive at http://httpd.apache.org/docs-project/.

The AuthType directive tells the server which protocol is to be used for authentication. Basic and digest authentication are the only accepted values. Basic authentication sends the authenticated user's name and password in clear text with each request.

AuthUserFile tells the server which user file to use. In this case, the user file created earlier in this chapter is specified.

The server now knows that this resource is restricted to valid users. The final step is to identify which users within this user file are authorized to access these resources. In this example, the argument valid-user tells the server that any user name in the user file can be employed. If you wanted to allow access only to ben, you would change the final line to this:

 require user ben 

To specify multiple users, put a space between their names.

To use the host-based restrictions provided by the mod_access module, specify the Allow or Deny directives within the .htaccess or the <Directory> section. The Allow and Deny directives permit or restrict access for each client. The Order directive determines their precedence in which Allow and Deny are applied.

The following code will restrict access to the CFIDE directory to the user sarge on a specific internal network:

 SetEnvIfNoCase Remote_User "sarge" Sweet <Directory /CFIDE>   Order Allow,Deny   Allow from 10.6.0.0/255.255.0.0   Deny from env!=Sweet </Directory> 

<Directory> vs. .htaccess

Both the <Directory> section of the httpd.conf file and distributed configuration files (.htaccess) provide authorization and authentication directives. However, using the <Directory> is the preferred method. There are two reasons for this:

1. Apache takes a performance hit when using distributed configuration files. For each file request in a protected directory path, Apache must traverse the entire directory structure looking for configuration files and compile the directives in all configuration files it finds within the directory structure. Conversely, a <Directory> section can be created for any directory you would consider using an .htaccess file and the <Directory> section is loaded at startup.

2. The <Directory> also gives administrators greater control over security on the server. Administrators must grant users permission to create .htaccess files, and tell them which directives they have specified to the AllowOverride directive.

The optimal reason for using .htaccess files is to provide make per-directory configuration changes when access to the httpd.conf is not available. Administrators still have to permit configuration file changes with the AllowOverride directive in the <Directory> of httpd.conf.

Sun ONE Web Server

Configuring access control for the iPlanet Web server is the same for both Unix/Linux and Windows. Access control settings are saved in text filessimilar to Apachethat exist in the sunone_root\Servers\httpacl folder, with the following naming convention:

 generated<server_root_name>.acl 

For example:

 generated.https-adminserv.acl 

You can modify these files by hand, but the Web Administration interface is more commonly used.

There are a myriad of access control configurations availablefrom global access control via ACLs (access control lists), to directory- and file-level access control using .htaccess files. You can limit access to your server by IP address and/or host name, by date and time, and even by requiring X.509 certificates for user authentication. The Web Administration provides several venues for implementing these configurations, but here we will focus on setting a configuration style on the CFIDE virtual directory.

NOTE

There are several ways to configure access control on the CFIDE directory. This example assumes you have a populated LDAP integrated with your Sun ONE Web Server. See the Sun online help documentation for information on configuring users and groups, and other methods of configuring access controls.

1.	Log in to the Sun ONE Web Server Administration Server (Figure 8.12). In the drop-down list, select the server instance you want to secure, and click Manage. Figure 8.12. Choose the virtual server you want to secure.
2.	Click the Class Manager link in the top frame.
3.	Click the Styles tab to access the Create Style form shown in Figure 8.13. Enter CFIDE and click OK. Figure 8.13. Create the new CFIDE style.
4.	Click the <server name> link in the top frame to return to the Server Manager (Fig ure 8.12). Click the Restrict Access link in the left frame to open the Edit ACL screen shown in Figure 8.14. Figure 8.14. Edit the default ACL file.
5.	Click OK to edit your virtual server's default generated ACL file, and click OK to the message prompt. Next you'll see the Access Control List Management form (Figure 8.15). The CFIDE style is selected under section A. Figure 8.15. Choose the access control method to edit.
6.	In section A, "Pick a resource," click the Edit Access Control button in order to edit the access control for the CFIDE style. If prompted for a password, enter the same login information you used in step 1. Figure 8.16 shows the Access Control Rules for the CFIDE style. Figure 8.16. The default access control setting for the CFIDE style.
7.	Click the check box to enable access control. In the next form, Figure 8.17, click New Line. This adds line 2 to the form Figure 8.17. Enable access control for the CFIDE style.
8.	On line 2, click the Deny link. Select Allow in the lower frame and click Update. Your form should now look like Figure 8.18. Figure 8.18. Change the control to Allow, to give anyone access.
9.	Click the anyone link on line 2 to open the User/Group form shown in Figure 8.19. Figure 8.19. Enable authentication and select the authentication method and database.
10.	Select Authenticated People Only. Then choose either "All in the authentication database" or "Only the following people." If you choose "Only the following people," specify the Group and/or User that you want to have access to this resource.
11.	For both Authentication Method and Authentication Database, choose the Default option. Click the Update button. TIP Choosing Default for the authentication method allows you to globally change the authentication methods for all your ACLs in the obj.conf file. The globally configured LDAP server is the default authentication database.
12.	Now the Access Control Rules form shows IP address and file-level access permissions (Figure 8.20). Figure 8.20. Allow all authenticated users Read access to this resource from the local server. TIP To restrict access to a list of host names or IP addresses, click Anyplace on line 2 of the Access Control Rules. To enable directory- and file-level access rights, click the all link under Rights in line 2. Only Read access is needed for basic Web browsing (Get, Head, and Post operations).
13.	Click Submit to return to the Edit Style form for the CFIDE style. Click OK at the prompt.
14.	Click Apply in the top frame. In the Apply Changes form (Figure 8.21), click Load Configuration Files. Click OK at the prompt. The window refreshes and your changes are saved. Figure 8.21. Apply configuration file changes.
15.	Click the Class Manager link in the top frame. Then click the Content Mgmt tab.
16.	Click the Additional Documents Directories link in the left frame.
17.	Enter /CFIDE as the URL prefix. In the Map to Directory text field, enter the absolute path to your CFIDE directory. Select CFIDE from the Style drop-down, as shown in Figure 8.22. Figure 8.22. Assign the CFIDE style to the /CFIDE URL path.
18.	Click OK to dismiss the prompt.
19.	Click the Apply link in the top frame. Click Apply Changes to restart your server and load the configuration changes. Click OK at the prompt.

Access to the ColdFusion Administrator is now restricted to members of your user database. The browser will now issue a username/password challenge (Figure 8.23) when a user tries to access the /CFIDE directory for the first time.

Figure 8.23. Basic authentication challenge to enter the ColdFusion Administrator.