Here are some sample Protect statements:

• Protect /Private/Snookums/* conf/snookums.setup: This defines the file snookums.setup in the /usr/local/etc/httpd/conf directory as the setup file for any URL requested from the /Private/Snookums tree.
• Protect /spider/private/* conf/spider.setup spider.www: This defines the file spider.setup as the setup file for any URL requested from the /spider/private tree. Also, when these documents are served, the server is instructed to run as the user spider and the group www.

DefProt

You also can configure a default setup file for your Protect statements. The DefProt directive allows you to provide the file's name when it is omitted from any Protect statement.

For example:

DefProt /Private/* conf/private.setup
Protect /Private/Snookums/* conf/snookums.setup
Protect /Private/Spider/*
Protect /Private/Sweetie/*

The DefProt defines the default setup file as conf/private.setup. This file is the setup file for all files under the /Private tree.

The first Protect statement defines conf/snookums.setup as the setup file for the /Private/Snookums tree. The file is specified and, therefore, the default is ignored.

The second and third Protect statements, however, have no setup file specified. This is where the DefProt statement kicks in. These two statements will have the conf/private.setup file used as their protection setup files.

Protection Setup Files

Specifying the DefProt and Protect directives for your URLs is only half the job. The other half is creating the protection setup files. These files define the authentication scheme, password and group files, and the password server's ID.

These items are specified through directives. Here is a sample protection setup file:

AuthType      Basic
ServerId      SnookumsSetup
PasswordFile  /usr/local/etc/httpd/admin/passwd
GroupFile     /usr/local/etc/httpd/admin/group

As you can see, there are four basic directives:

• AuthType <auth_scheme>: This specifies the authentication scheme. Currently, only Basic is supported.
• ServerId <name>: This specifies the name of the password server. This name is nothing more than an identifier that is sent to the client. This allows smart browsers to remember your password when pages are revisited. This can be the same for your entire site or different for each protection scheme. It is up to you.
• PasswordFile <filename>: This specifies the full path and filename of the password file.
• GroupFile <filename>: This specifies the full path and filename of the group file.

The following are additional directives that can be used for embedded protection:

• UserId <user>: The user to run as.
• GroupId <group>: The group to run as.
• GetMask <group syntax>: This sets the group of entities that are granted access.

Creating Users and Passwords

The password file is created with a utility program called htadm. This program is bundled with the server when you download it. The htadm program has the following options and parameters:

• htadm -adduser <passwordfile> [<username> [<password> [<realname>]]]: This command adds a user to the password file <passwordfile>. <username> and <password> are optional. If they are not specified, you are prompted for the information. <realname> is an optional parameter to specify the user's real name.
• htadm -deluser <passwordfile> [<username>]: This command deletes user <username> from the password file <passwordfile>. <username> is optional. If it is not specified, you are prompted for the information.
• htadm -passwd <passwordfile> [<username> [<password>]]: This command changes the password of user <username> to <password> in <passwordfile> . <username> and <password> are optional. If they are not specified, you are prompted for the information.
• htadm -check <passwordfile> [<username> [<password>]]: This command checks a user's password in a password file. <username> and <password> are optional. If they are not specified, you are prompted for the information. htadm returns zero if the password is correct, and non-zero if it is not correct. The program will also write the words Correct or Incorrect to standard output.
• htadm -create <passwordfile>: This creates an empty password file <passwordfile>.

Creating Groups

You can configure your server to serve files only to people who belong to a certain group. These groups are maintained in the file called a group file. If used, this file-like the password file-can exist in any directory you wish. The format is similar to that of the password file:

<group name>:<member1> <member2> ... <membern>

<group name> is what you want to call the group. The <member#> is the user name or mask that you wish to be part of the group. This user name is from the Protect password file, not the system passwd file. You can specify multiple members per group.

The following is a list of the entities that can be members of groups:

• User name: Any user's name.
• Group name: You can specify another group to be a member of a group.
• IP address: You can specify an IP address or partial IP address as a group member.
• User or group at an IP address: You can specify a user or group of users at an IP address or partial IP address.

The best way to understand the group file syntax is to see one. This is the sample group file used in the CERN documentation for the server:

.www_acl

It is possible to specify even more protection than the Protect statement provides. This is done with the .www_acl file. This file specifies the files, methods, and users allowed access inside a directory. The format of the file is as follows:

Embedded Protection

Instead of using protection setup files, you can embed your protection setup into your configuration file. This is done with the Protection directive. The format is as follows:

Examples of Protections

This configuration might seem a bit difficult at first. However, working through a few examples could help you better understand the nature of CERN protection.

Restrict by IP Address or Domain Name

The following is an example of protecting an entire directory tree for a particular IP address. This can be used to prevent a certain set of hosts from accessing part of your site. The example will allow only hosts from snookums.com and sweetie.com into the directory tree /Private/Secret. Note that there is no password or group file involved in this type of setup. It is a simple restriction based on an IP address. Therefore, the user will never be prompted for a user name or password.

Protection     IPRESTRICT {
     UserID          www
     GroupID         www
     AuthType        Basic
     GetMask         @(*.snookums.com,*.sweetie.com)
}

     Protect         /Private/Secret/*     IPRESTRICT

Restrict by User

The second example builds on the first. In addition to IP address protection, you're going to add user protection. Only certain users at snookums.com or sweetie.com are allowed access to the /Private/Secret tree.

Protection      USERRESTRICT {
     UserID          wwwadmin
     GroupID         www
     AuthType        Basic
     ServerID        AdminPassword
     PasswordFile    /usr/local/etc/httpd/admin/passwd
     GroupFile       /usr/local/etc/httpd/admin/group
     GetMask         admins@(*.snookums.com,*.sweetie.com)
}

     Protect         /Private/Secret/*     USERRESTRICT

Restrict Individual Files

The final example shows how to use the .www_acl files to restrict access to individual files. I'll build on the last two examples for this one. So far, you have restricted access to the /Private/Secret directory tree to only administrative users from snookums.com or sweetie.com. You can do the same thing using the ACL files. To do this, simply move a portion of the GetMask from the main configuration down to the directory of the files.

For your example, the configuration file would look like the following:

The .htaccess file can be configured many different ways. These directives are as follows:

• AuthUserFile: This specifies the location and name of the file from which to read passwords.
• AuthGroupFile: This specifies the location and name of the file from which to read groups. You can combine users into groups and allow access by group.
• AuthName: This specifies the identification of this screen, which is displayed at the client end.
• AuthType: This specifies the method of authentication. These types can be Basic, PEM, PGP, KerberosV4, KerberosV5, or Digest. Basic is the most commonly used method because it requires no special software on the client.
• Limit: This describes the allowed or denied HTTP methods (POST, GET, and so on) and remote hosts.
• Options: This describes which server features are supported.

The following .htaccess file is from the Web page shown in Figure 15.4. It is from the NCSA Web site. This page allows access only to the user fido with a password of bones.

AuthUserFile    /X11/mosaic/public/auth-tutorial/examples/by-password/.htpasswd
AuthGroupFile   /dev/null
AuthName        ExampleByPassword
AuthType        Basic

<Limit GET>
require user fido
</Limit>

From the configuration file, you can see that the password file is stored in

/X11/mosaic/public/auth-tutorial/examples/by-password/.htpasswd

You can also see that there is no group file, and the page requires user fido.

Here is the file from the preceding configuration:

/X11/mosaic/public/auth-tutorial/examples/by-password/.htpasswd

It is similar to the UNIX password file, but contains less information:

fido:h5HhgnhegqFIw

You have the option to place the entirety of this file in the global access file. To do this, you use the Directory directive. This is a blocking or sectioning directive. The format is as follows:

Options

The Options directive controls the server features that can be done in your directory. These features are as follows:

• FollowSymLinks: This allows the following of symbolic links.
• SymLinksIfOwnerMatch: This allows symbolic links to be followed only if the target file or directory's owner matches that of the link.
• ExecCGI: This allows the execution of CGI scripts.
• Includes: This allows server-side include files.
• Indexes: This allows a user to request indexes of this directory. Disabling this feature only stops the server from generating the index. If an index file exists (specified by the DirectoryIndex directive), it will still be sent.
• IncludesNoExec: This allows server-side includes, but disallows the exec feature of them.
• All: This allows all of the features listed here.
• None: This allows none of the features listed here.

Creating Users and Passwords

The password file can be created with a utility program called htpasswd. This program is bundled with the server when you download it. The syntax of the htpasswd program is as follows:

htpasswd [-c] <file> <user>

<file> is the path and name of the password file to work with. <user> is the user to create the password for. The -c option will create the file if it does not exist.

When run, this program asks you to enter the password for the user specified. You must enter it a second time to verify. The record is then written to the file specified. This new file can then be used for user authentication.

.htgroup

You can configure your server to serve files only to people that belong to a certain group. These groups are maintained in the file .htgroup. If used, this file-like the password file-can exist in any directory you wish. The format is similar to that of the password file:

<group name>:<member1> <member2> ... <membern>

<group name> is what you want to call the group. The <member#> is the user name that should be part of the group. This user name is from the .htpasswd file, not the system /etc/passwd file. You can specify multiple members per group.

Here is a sample .htgroup file:

snookcust: ren stimpy sven

In the group snookcust, there are three users: ren, stimpy, and sven.

Here is a sample .htaccess file using groups:

AuthUserFile     /usr/local/etc/httpd/passwords/.htpasswd
AuthGroupFile    / usr/local/etc/httpd/passwords/.htgroup
AuthName         Password
AuthType         Basic

<Limit GET>
require group snookcust
</Limit>

This requires the user to be in the group snookcust. Therefore, only the users ren, stimpy, and sven are allowed access.

Personal HTML Directories

If you are running an intranet site that enables users to have their own home pages, you need to configure your server to allow this. Both the CERN and NCSA servers have the UserDir directive. This directive enables the server to jump to a user's home directory when only the user's name is specified with a preceding tilde (~). On a UNIX system, you can reference any user's home directory by placing a tilde in front of that user's name. For example, to list the files in the home directory of the user teddy, the command would be

munster@honey:~$ ls -l ~teddy

Your intranet server can be configured to do the same thing. When a request comes in for the home page of the user teddy, it will usually look like the following:

http://www.snookums.com/~teddy/home.html

The UserDir directive enables the server to look for user files in a special subdirectory in its home directory tree.

The format of the UserDir directive is as follows:

UserDir <directory>

<directory> is the directory under the user's home directory tree to search for documents. It is similar to automatically specifying a sub-DocumentRoot for each user.

On the CERN server, you must specify the UserDir directive to enable this feature.

The NCSA server, on the other hand, enables this feature and by default points to the directory public_html. To disable this feature on the NCSA server, you must use the following command:

UserDir DISABLED

Here are some examples:

• UserDir /: If a request for /~teddy/index.html was received, the file ~teddy/index.html would be served.
• UserDir public_html: If a request for /~teddy/stuff.html was received, the file ~teddy/public_html/stuff.html would be served.

Be sure to inform your users to take the same precautions that you use to secure your files in the server's root directory tree: make the files readable and writeable only by themselves.

User Access to CGI Scripts

Your users might request that they be allowed to create their own CGI scripts. Besides the management headache that this causes, you probably don't want users writing programs that run on your server. Any script the user creates could potentially run as the root user and wreak major havoc on your system.

Only you know the capabilities of your users, but, generally, most systems have a mix ranging from gurus to newbies. Although you might not be worried about your gurus writing CGI code, your newbies will probably be the ones that ask for it. Unfortunately, these little snippets of code need to be as secure as your intranet server itself.

There are two ways to allow users access to your CGI scripts. Both methods are simple. The first is to restrict script directory access to a certain group of people (that is, admin users). Then, simply add users to that group so they can then create and test their own scripts.

The second method is to enable scripts in that user's directory.

Enabling CGI Scripts in Directories Other than /cgi-bin

To configure your server to enable CGI scripts in directories other than the main /cgi-bin directory, you need to add more configuration directives. This differs slightly between the CERN and NCSA servers.

CERN Configuration

The Exec directive is used to map URLs to scripts. When you place executable scripts on your server, the server needs to know where the scripts are and the fact that they are executable. The format is as follows:

Exec <template> <result>

This directive differs in its use of wildcards. The Exec directive must include wildcards in both the template and the result. This is because many scripts take arguments that are passed along at the end of the URL. If no wildcard was used, the arguments would not be passed on properly.

Here is an example of the Exec directive:

Exec     /cgi-bin/*     /usr/local/etc/httpd/cgi-bin/*

This will inform your server that any URL beginning with /cgi-bin is an executable script that it can be found in this directory:

/usr/local/etc/httpd/cgi-bin/

Simply use this directive for each place that you want to allow scripts to execute.

NCSA Configuration

The ScriptAlias directive specifies a directory where executable scripts live on your server. Multiple ScriptAlias directives can be used in the srm.conf file. The format of the ScriptAlias directive is as follows:

ScriptAlias <template> <path>

When used, the ScriptAlias directive effectively remaps the location of template to path.

Here is an example of the ScriptAlias directive:

ScriptAlias     /cgi-bin     /usr/local/etc/httpd/cgi-bin

All requests for documents that begin with /cgi-bin will be rerouted through /usr/local/etc/httpd/cgi-bin and the output of the script will be returned to the requesting client.

Simply use this directive for each place that you want to allow scripts to execute.

Access to Server-Side Includes

Server-side includes, or SSIs, are a way to include other programs or HTML files into a document before it is served to the client. This allows for customization of the file on-the-fly. Types of information that you can provide include the following:

• current date and time
• Last modification date and time
• Remote user
• Remote host
• Hit counts

Allowing SSIs can be costly to your server's performance. It slows your server down to parse through a second HTML file while sending the original. To reduce this performance cost, you should only allow SSIs with files of a certain extension. This will cause the server to only parse the included file, not both files. If you don't care about the performance, this restriction is not needed.

Enabling Server-Side Includes

To enable SSIs, you first need to add a MIME type to your global configuration or local directory configuration file. This will inform the server of the extension that you wish to use for all SSIs. The server internally uses the magic MIME type of text/x-server-parsed-html to identify these types of documents. You must bind an extension to this MIME type. Use the AddType directive to do so:

AddType text/x-server-parsed-html .shtml

This specifies that files ending in .shtml will be the only candidates for inclusion.

Alternatively, if you don't care about server performance, use this AddType directive instead:

AddType text/x-server-parsed-html .html

Allowing Access

By default, all users have access to SSIs. You might want to restrict access to a few people or only allow SSIs from certain directories.

If you do not want to allow access to server-side includes, you must modify the Options for the global access file, access.conf. By default, all options are enabled for all directories. You must make an entry in your global access file or your directory's .htaccess file. See the earlier section regarding the format.

Summary

After reading this chapter, you should have a better understanding of the methods available to you for securing your intranet site. These include restrictions based on user, IP address, and domain name. You also should have some ideas about what you want to allow users to do. You now might or might not want to let them have access to CGI scripts or server-side includes. Hopefully, I've offered enough insight for you to make these decisions.