This chapter describes how to protect the data and files on your server and includes the following topics:
For information on providing security for server data on the Internet, see Chapter 9. "Making your communications secure".
You announce to the world that you want people to come look at the documents on your server. But once you publicize your server to the Internet, you risk attracting unwanted attention to the system on which it runs. Unauthorized people may try to guess passwords, update files, execute files, or tap into confidential data. Part of the attraction of the World Wide Web is its openness. However, the Web is open to both positive use and abuse.
There are several ways that you can protect your system:
Packet filtering allows you to define where data can come from and where it can go. You can configure your system to reject certain source/destination combinations.
A firewall provides a way to separate an internal network from a publicly accessible network, such as the Internet. The firewall can be a group of computers or a single computer that acts as a gateway in both directions, regulating and tracking the traffic passing through it. An example of firewall software is the IBM Internet Connection Secured Network Gateway.
You can configure your server as a proxy server through a firewall. This way, internal users can get out to the Internet, but outside Internet travelers cannot get in. Using a proxy server also ensures that any access to the Internet by internal browsers is done anonymously. Because all of the requests to the Internet are made by the proxy server on the part of the internal user, the remote host does not have access to the name of the specific host that is on the inside of the firewall. For information on configuring your server as a caching proxy, see "Running your server as a proxy". For information on using your server on a firewall machine, see the documentation for your firewall software.
Using CGI scripts on a Web server can create a security exposure. If you use CGI scripts, you need to protect them by controlling who has access to them.
It is possible to write CGI scripts that display all environment variables. At times these variables may include sensitive data such as user IDs and passwords. So you must be careful about displaying environment variables in your CGI scripts and control access to your CGI scripts. Make sure you know what a CGI program does before you make it available on your server.
The following sections describe how you control who has access to the various files you keep on your server. The steps first tell you how to set up protection by editing the configuration file. When appropriate, the steps tell you which Configuration and Administration forms you can use to perform the same task.
The first step to controlling access to your server's resources is to activate protection. You activate protection based on the content of requests that clients send to your server.
This document refers to a request as the part of a full URL that follows your server host name. For example, if your server is named fine.feathers.com and a requester enters the following URL on a browser:
http://fine.feathers.com/waterfowl/schedule.html
The request your server receives is: /waterfowl/schedule.html
You can use Protect directives to specify which requests should activate protection. Each Protect directive has a request template. The server activates protection when it receives a request that matches a request template on a Protect directive. The Protect directive also either identifies or contains the protection setup to be used.
See "Access control - Set up access control for the server" for details on how to use Protect directives.
You can also use the Configuration and Administration forms to specify which requests should activate protection. From the Configuration and Administration forms page, click Document protection.
Besides activating protection for the requests, you must also tell your server which requests to accept for processing.
Use Pass and Exec directives to specify which requests you want your server to accept. The Pass and Exec directives map requests to actual directories and files on your server (the information you are protecting).
Like the Protect directive, each Pass and Exec directive contains a request template. After the server checks to see if a request activates protection, it goes through its list of Pass and Exec directives to determine if it should accept the request. If the request matches a request template on a Pass or Exec directive, the server accepts the request. If protection was activated, the server uses the protection setup to determine whether it should complete the request.
So for protection to work properly, you must ensure that your Pass and Exec directives accept the requests that your Protect directives activate protection for. Use Pass directives to accept document requests. Use Exec directives to accept CGI program requests.
See "Resource mapping - Redirect URLs" for details on how to use the Pass and Exec directives.
Attention: You must put your Protect directives before any Pass or Exec directives in your configuration file.
You can also use the Configuration and Administration forms to specify which requests to accept and how to map them to your actual resources. From the Configuration and Administration forms page, click Request Routing.
You can use two types of protection to control access to your resources through the server:
You can use one type of protection by itself or both together. You can use either or both types of protection in protection setups and Access Control List (ACL) files. It is helpful to understand these two different types of protection before you create your protection setups or ACL files.
The following two sections describe each type of protection. Following those two sections is a section describing how the server processes requests based on the type of protection being used.
With this type of protection, you create user names that you want requesters to use to access your protected resources. You define each user name and assign it a password in a password file.
After you define a user name, you can use it within protection setups and ACL files to specify which user names are valid for different types of requests.
When the server receives a request that activates this type of protection, the server prompts the requester for a user name and password. In order for the request to complete, the requester must return a user name and password that meet the following criteria:
With this type of protection, you use address templates to specify valid requester addresses for the different types of requests. You can use address templates in protection setups and ACL files.
When the server receives a request that activates this type of protection, it compares the address of the requester to the templates to determine if the request comes from a valid address. The server can use either the IP address of the requester (for example, 9.67.97.103) or the host name of the requester (for example, any.host.name.com) when comparing against the templates.
Note: In order to compare the requester host names against address templates, you must set the DNS-Lookup directive to On. If the DNS-Lookup directive is set to Off (the default), your server can compare only the IP address of the requester to the address templates. See "DNS-Lookup - Specify whether you want to look up host names of clients".
Following is a description of how the server processes a request that has already activated protection and been accepted by a Pass or Exec directive. The description assumes that all protection is defined in the protection setup (no ACL file exists on the protected directory).
Read over the description now to help you decide what type of protection you want to use. You may want to read again in more detail after going through the steps for creating protection setups.
Items that use only address template protection start with either @, Anybody@, Anyone@, or Anonymous@, followed by one or more address templates. Group names on the subdirective might also contain items that use only address template protection.
If there is a match, the server completes the request withoutprompting for a user name or password.
If there is not a match or no items use address template protection only, the process continues with the next step.
If there is a match, the process continues with the next step.
If there is not a match, the process ends and the server returns a message to the requester saying that authorization failed.
If there is a match, the process continues with the next step.
If there is not a match, the process ends and the server returns a message to the requester saying that authorization failed.
If there is a match, the process continues with the next step.
Note: It is important to note that the password file must contain an entry for the user name that the requester sends to the server. You make up the user names that are in the password file. The names themselves do not have any relation to the addresses of the requesters.
If there is not a match, the process ends and the server returns a message to the requester saying that authorization failed.
If there is a match, the server completes the request.
If there is not a match, the process ends and the server returns a message to the requester saying that authorization failed.
When a Protect directive activates protection for a request, it also either identifies the protection setup to use or defines the protection setup as part of the directive. A protection setup is a group of protection subdirectives. The subdirectives work together to define how the server should control access to the resources being protected. You can create protection setups three different ways:
When you create a protection setup on a Protection directive, you give the setup a label that you can point to later from Protect and DefProt directives.
When you create a protection setup on a DefProt or Protect directive, the protection setup is used only for that directive. The setup cannot be pointed to by other DefProt or Protect directives. This type of protection setup is called an in-line protection setup.
You indicate you are including a protection setup as part of a Protection, Protect, or DefProt directive by making the last character on the line that contains the directive a left brace character ({). On each following line you put one protection subdirective and its value. You indicate the end of the protection setup by putting a right brace character (}) by itself on the line following the last protection subdirective. You cannot use comments within the protection setup.
See "Access control - Set up access control for the server" for more information and examples of creating protection setups in the configuration file.
Within the protection setup, the protection subdirectives control access to the directory or files being protected. The following sections describe how to use each of the protection subdirectives.
For user name and password protection, use the ServerID subdirective to specify a name you want to use to identify the protection setup to requesters. The name does not need to be a real machine name.
When the server sends a requester a prompt for user name and password, it also includes the name you specify on ServerID. Most browsers display this name with the prompt. Because different protection setups can use different password files, having a name associated with the protection setup can help the requester decide which user name and password to send back. Many browsers also attempt to automatically send a user name and password if the requester has previously responded to a prompt from a protection setup with the same name.
Because some browsers such as NetScape cache userid/password by security realm (ServerId) within host, we suggest you follow these guidelines when specifying ServerId and password files in your protection setups:
If the protection setup is using address template protection only, you do not need to use the ServerID subdirective.
If you are using the Configuration and Administration forms, you specify this name in the Server identifier field on the Protection Setup form.
ServerID restricted
The AuthType subdirective specifies the type of authentication to use when a client sends a password to the server. For user name and password protection, you must use the AuthType subdirective with a value of Basic. With basic authentication, passwords are sent to the server as plain text. They are encoded, but not encrypted.
If the protection setup is using address template protection only, you do not need to use the AuthType subdirective.
AuthType Basic
For user name and password protection, use the PasswdFile subdirective to specify the path and name of the password file that you want the protection setup to use.
Each password file contains a list of user names and passwords. Each user name has one valid password defined for it. The requester must send back a user name and password that exactly matches a user name and password in the password file.
Because some browsers such as NetScape cache userid/password by security realm (ServerId) within host, we suggest you follow these guidelines when specifying ServerId and password files in your protection setups:
If the protection setup is using address template protection only, you do not need to use the PasswdFile subdirective.
If you are using the Configuration and Administration forms, you specify the file path and name of the password file in the Password file field on the Protection Setup form.
You create and maintain password files using the htadm command. See "htadm command" for information on how to create and maintain password files.
Note: The user names in the password file do not have any relation to the addresses of the requesters. You make up the user names and passwords.
PasswdFile c:\WWW\restrict.password
If you want to use group names in the protection setup, use the GroupFile subdirective to specify the path and file name of the server group file that contains the group definitions you want to use. The groups defined within the server group file can then be used by:
See "Using server group files" more information about server group files.
If you are using the Configuration and Administration forms, you specify the file path and name in the Group file field on the Protection Setup form.
GroupFile d:\docs\WWW\restrict.group
Use the mask subdirectives to specify valid user names, groups, and address templates for different types of requests. The mask subdirectives protect the entire directory that the request is mapped to.
Each request to your server contains an HTTP method field that identifies the type of request being made. See "Methods - Set method acceptance" for a description of the HTTP methods supported by the server. Choose which mask subdirectives to use based on the types of requests you want to authorize. For a protection setup to be valid, it must contain at least one of the following mask subdirectives:
Following are explanations and examples of the different ways you can specify user names, group names, and address templates on mask subdirectives. The same rules also apply for specifying user names, group names, and address templates in server group files and ACL files. If you are using the Configuration and Administration forms, the same rules apply to the values you can enter in the Get, Put, Post, Delete, and All fields on the Protection Setup form.
GetMask swandude
The address template can be based on either IP address or host name. Use the asterisk character (*) as a wildcard in any part or the template. To indicate you want to use address template protection only, precede the template with one of the following: @, Anybody@, Anyone@, or Anonymous@.
GetMask Anybody@123.45.2.* PostMask @96.*.*.* DeleteMask Anonymous@walden.pond.*.*
Note: In order to compare the requester host names against address templates, you must set the DNS-Lookup directive to On. If the DNS-Lookup directive is set to Off (the default), your server can compare only the IP address of the requester to the address templates. See "DNS-Lookup - Specify whether you want to look up host names of clients".
GetMask webfoot@96.96.*.* PostMask billface@*.ibm.com
GetMask All PostMask All@(96.*.*.*,*.ibm.com,123.45.2.*)
A group name can include user names, other group names, and address templates in any of the same formats allowed on masking subdirectives. To be valid, any user names included in the group name must also be defined in the protection setup password file. If the requester returns a valid user name and password and any address templates are matched, the server completes the request.
GetMask ducks PostMask geese
GetMask Anybody PutMask Anyone@(*)
GetMask swandude@96.96.*.*,geese,ducks,Anyone@walden.pond.*.*
GetMask swandude@96.96.*.*,webfoot@water.fowl.com,
geese,billface
GetMask (gooduser,webfoot)@96.96.*.*,
billface@(water.fowl.com,123.45.2.*),
(goosegg,bagel,elnada)@(98.*,146.*)
If you are using the Configuration and Administration forms, you specify user names, groups and address templates in the Delete mask, Get mask, Post mask, and Put mask fields on the Protection Setup form. You use the same rules as explained above.
Chapter 10. "Using Secure Sockets Layer (SSL)" describes how to use Secure Sockets Layer (SSL) with a secure server. If you set up your server for SSL client authentication, the server requests a certificate from any client making an https request. The server establishes a secure connection whether or not the client has a valid certificate.
You can restrict who can access documents by using password files and/or user or group authentication in protection setups as described in Chapter 7. "Protecting your server". You can further restrict who can access documents by coding SSL client authentication parameters on protection setups, ACL files, or both. (Coding SSL client authentication parameters on protection setups is described in this topic; coding them in ACL files is described in "Step 5. Limiting access to individual files".)
Using SSL client authentication parameters as subdirectives, you can specify that the client certificate is valid or you can specify all or part of the Distinguished Name (DN) of a client or of the certification authority (CA) who issued the client's certificate.
When you use SSL client authentication parameters, the server first checks to see if the client certificate is valid, as is. If not, it compares any DN information in a protection setup and then compares any DN information in an ACL file with the DN information in the client's certificate. If the DN information matches, the server serves the document.
You can use the Protection Setup Configuration and Administration form to specify the SSL client authentication parameters or you can specify the following on the Protection or Protect directive:
Protect /topsecret/* {
CommonName "Dr Sheila A. Jones"
Organization "RTP Quick Care Center"
Mask Anybody@(*)
}
In the above example of an inline Protect directive, SSL client authentication must be set up, and the client must be making an https request and have a certificate with a common name of Dr Sheila A. Jones and an organization of RTP Quick Care Center to access the document.
Perform this step only if you want to limit access to specific files on directories already protected by the protection setup.
To limit access to specific files on a protected directory, you create an Access Control List (ACL) file and place it on the directory. The ACL file must be named .www_acl.
Normally, the mask subdirectives in the protection setup define the first level of access control and then the ACL file further limits access. However, if you want all control to come from the ACL file, use the ACLOverride subdirective with a value of On in the protection setup. This causes the mask subdirectives in the protection setup to be ignored. All access control is passed to the ACL file.
See "Using Access Control List (ACL) files" for more information about ACL files.
If you are using the Configuration and Administration forms, you can specify that you want the protection setup to give all control to ACL files by checking the Allow ACL file to override masks box on the Protection Setup form.
You can use group files to classify users into groups.
Protection setups can point to a server group file. The protection setup can then use the groups defined in the server group file on mask subdirectives. If a protected directory contains an ACL file, the rules in the ACL file can also use the groups defined in the server group file.
You can create as many server group files as you need. Create each in a separate text file. Within the server group file, each line contains a group definition using the following format:
groupname : user1[,user2[,user3...]]
For user names to be valid, they must be defined in the password file that the protection setup points to. Group names must be defined on previous group definition statements in the same group file.
Generally, the items you specify have to follow the same rules described under "Rules for specifying user names, group names, and address templates".
ducks : (webfoot,billface)@96.96.3.1,swandude geese : goosegg,bagel@(walden.pond.*.*,123.*.*.*) flock : ducks,geese webbed : All@water.fowl.*
In the above example, notice that once the groups named ducks and geese are defined, they can be included as part of the group named flock.
This section describes how to "hand code" ACL files. You can also create ACL files using the Configuration and Administration forms. From the Configuration and Administration forms page, click Access Control Lists.
You can use ACL files to limit access to specific files on a protected directory.
Each protected directory can have only one ACL file. The ACL file must be named .www_acl and be present on the protected directory.
Normally, the mask subdirectives in the protection setup define the first level of access control and then the ACL file further limits access to individual files. However, if you want all control to come from the ACL file, use the ACLOverride subdirective with a value of On in the protection setup. This causes the mask subdirectives in the protection setup to be ignored when a protected directory contains an ACL file.
Within the ACL file, each line contains a rule limiting access based on file name, HTTP method, and authorized users, groups, or addresses. The server processes the rules in the ACL file from top to bottom. The server compares the three elements of each rule to the request until a match is found or until the end of the file is reached.
The format for rules in ACL files is:
file : method : [SSLauth,] user
The server denies any requests for files that are not listed or covered by a template.
The ACL can specify any of all of the following parts of the
For user names to be valid, they must be defined in the password file that the protection setup points to. Group names must be defined in the server group file the protection setup points to.
The items you specify have to follow the same rules as you use to specify user names, group names, and address templates on mask subdirectives. See "Rules for specifying user names, group names, and address templates".
* : GET : All *.html : GET,POST : geese golden.* : GET,POST : geese,@bean.stalk.* welcome.html : GET,POST,DELETE : webfoot@123.34.14.2
In the above example, any valid user name and password can be used to GET any file on the directory. User names defined for the group geese can be used to POST to any HTML files. From IP address 123.34.14.2, the user name webfoot can be used to DELETE the welcome.html file.
patientA.html : GET : !CommonName="Dr Shelia A. Jones"@9.67.*.*In the above example, SSL client authentication must be set up, and the client must be making an https request from an IP address beginning with 9.67 and have a client certificate with a common name of Dr Shelia A. Jones to access the patientA.html document.
patientA.html : GET : !CommonName=("Dr Shelia A. Jones","Dr Harry S. Smith")@9.67.*.*
In the above example, SSL client authentication must be set up, and
the client must be making an https request from an IP
address beginning with 9.67 and have a client certificate with a
common name of Dr Shelia A. Jones or Dr Harry S. Smith
to access the patientA.html document.
Following are examples of the files you can use for protecting your server resources. These files do not use any of the secure network communications functions. In the files where they are allowed, comments begin with the pound sign (#) in the first column.
Following is an example of the protection related portion of a server's configuration file.
Protection POND-PROT {
ServerID Feathered
Authtype Basic
PasswdFile C:\WINNT35\flying.pwd
GroupFile C:\WINNT35\nesters.group
GetMask All@*.swimmer.org
PutMask quacks,billface
DeleteMask bigbird@pond.hq.swimmer.org
}
#
# The above Protection directive defines a protection setup named
# POND-PROT. The Protection directive must be placed before any
# Protect or DefProt directives that point to it. The Mask
# subdirectives restrict access as follows:
# o Any requester from a host name ending with .swimmer.org can
# GET files. They must be able to enter any user name and
# password defined in the C:\WINNT35\flying.pwd password file.
# o To PUT files, the requester must match the restrictions
# defined for the group named quacks in the
# C:\WINNT35\nesters.group server group file.
# Or, the requester must enter the user name billface and the
# password defined for it in the C:\WINNT35\flying.pwd
# password file.
# o To DELETE files, the requester must be from the host named
# pond.hq.swimmer.org. The requester must enter the user name
# bigbird and the password defined for it in the
# C:\WINNT35\flying.pwd password file.
#
Protect /wetland/creatures/* POND-PROT
#
# Any request beginning with /wetland/creatures/
# activates protection as defined in the protection setup
# labeled POND-PROT
#
Protect /vegetation/* C:\WWW\proset\webster.setup
#
# Any request beginning with /vegetation/ activates protection
# defined in the separate protection setup file named
# C:\WWW\proset\webster.setup
#
Protect /flocks/* {
DeleteMask @9.67.84.5
MASK Anybody@9.67.*.*
}
#
# The above Protect directive contains an in-line protection setup.
# Any request beginning with /flocks/ activates protection
# defined as part of the Protect directive. The mask subdirectives
# restrict access as follows:
# o To delete files, the requester must be at the host with
# IP address 9.67.84.5
# o To use any other enabled HTTP method, the requester must
# be at a host with an IP address beginning with 9.67.
# (@ by itself and Anybody@ both mean the same thing.)
# Since only address protection is being used, there is no need for
# the Authtype, ServerID, PasswdFile, and GroupFile subdirectives.
#
Pass /wetland/creatures/* D:\freshwater\animals\*
#
# For requests beginning with /wetland/creatures/, the server
# goes to the d:\freshwater\animals\ directory to find the file.
#
Pass /* D:\SServer\HTML\*
#
# For any requests not matching other Pass directives, the server
# goes to the D:\SServer\HTML\ directory (the document root
# directory). For example, if the server received the request
# /vegetation/cattail.html, it would look for the cattail.html
# file on D:\SServer\HTML\vegetation.
#
Following is an example of what the c:\WWW\proset\webster.setup file might look like:
ServerID Webby Authtype Basic PasswdFile C:\WINNT35\flying.pwd GroupFile C:\WINNT35\nesters.group GetMask All@(123.45.*,water.*) PutMask goosegg,webfooter,nest DeleteMask (swandude,billface)@(water.fowl.com,123.45.2.*) ACLOverride On # # The mask subdirectives restrict access based on a combination of # user names and passwords and address templates. However, since # ACLOverride is on, these subdirectives are ignored and the ACL # file is used. For user name and password protection, the ACL file # must use the C:\WINNT35\flying.pwd password file and the # C:\WINNT35\nesters.group server group file. #
Following is an example of what the C:\WINNT35\flying.pwd file might look like:
bigbird:vfzDlIeUzFzCt:The big guy duckman:PVz1Y6YFI8IY3:The duck swandude:FexekemFhY7q8:Swanee billface:ZereWePF0YJqK:Orange nosed one goosegg:dh*ySyZJPOqrw:Shut out
Note: When you look at the contents of the password file, you cannot see the passwords because they are encrypted. To manage the password file you must use the htadm command. Do not edit password files with a text editor.
Following is an example of what the C:\WINNT35\nesters.group file might look like:
ducks : (webfoot,billface)@96.96.3.1,swandude geese : goosegg,bagel@(walden.pond.*.*,123.*.*.*) quacks : ducks,geese,Anybody@43.234.* nest : All@(water.fowl.*,nesting.*.*) # # The quacks group demonstrates how you can use previously # defined groups in a subsequent group definition. The quacks # group includes both the ducks and geese groups. Additionally, # the quacks group includes address template protection for any # requests from hosts with an IP address beginning with 43.234. # Requests from matching hosts would not be prompted for a user # name and password.
Following is an example of what the .www_acl file on D:\SServer\HTML\vegetation might look like.
* : GET : All *.html, : GET,POST : nest billed.html : GET,POST : duckman,geese welcome.html : GET,POST,DELETE : bigbird # # All restrictions come from the ACL file because the protection # setup specified ACLOverride On. The user names and groups used # in the ACL file must be defined in the password and server group # file identified in the protection setup.
You can restrict who can access documents by using password files and/or user or group authentication in protection setups as shown in the examples in "Protection example (without SSL client authentication)". You can further restrict who can access documents by coding SSL client authentication parameters in protection setups, ACL files, or both.
The following examples assume that SSL client authentication has been set up by specifying SSL client authentication on the Security Configuration form or by coding the SSLClientAuth directive in the configuration file.
Protection SSL_CLIENT_AUTH {
CommonName "Dr Sheila A. Jones"
Country US
Organization "RTP Quick Care"
Mask Anybody@(*)
}
For a server to serve the document, the server authenticates the client by requesting and ensuring the client has a valid certificate. In this case, for the certificate to be valid, the Distinguished Name of the client must be made up of a Common Name of Dr Sheila A. Jones, an organization of RTP Quick Care Center, and a country of US.
If you want to allow all persons with an organization unit of Pediatrics to access the documents protected by the SSL_CLIENT_AUTH protection setup, you could specify:
Protection SSL_CLIENT_AUTH {
OrgUnit=Pediatrics
}
The Protect directive that maps the request to the protection setup follows the protection setup:
Protect \secure_docs\* SSL_CLIENT_AUTH
Any request beginning with secure_docs activates protection as defined in the protection setup SSL_CLIENT_AUTH.
Note: If you code SSL client authentication parameters in ACL files and not in protection setups, you must also have a Protect statement like the one in the above example.