Protect resources

The IBM^® HTTP server includes HTTP directives that can provide detailed control of the information assets that the server uses. You can use directives to control from which directories the Web server serves URLs for both HTML files and CGI programs, to swap to other user profiles, and to require authentication for some resources.

Following are some suggestions for using HTTP directives:

The HTTP server starts from the basis of ″explicit authority.″ The server does not accept a request unless that request is explicitly defined in the directives. In other words, the server immediately rejects any request for a URL unless that URL is defined in the directives (either by name or generically).
You can use protection directives to require a user ID and password before accepting a request for some or all of your resources.
- When a user (client) requests a protected resource, the server challenges the browser for a user ID and password. The browser prompts the user to enter a user ID and password, and then sends the information to the server. Some browsers store the user ID and password and send them automatically with subsequent requests. This frees the user from repeatedly entering the same user ID and password on each request.
  Because some browsers store the user ID and password, you have the same user education task that you have when users enter your system through the system Sign On display or through a router. An unattended browser session represents a potential security exposure.
- You have three options for how the system handles user IDs and passwords (specified in the protection directives):
  1. You can use normal system user profile and password validation. This is most commonly used to protect resources in an intranet (secure network).
  2. You can create "Internet users": users that can be validated but do not have a user profile on the system. Internet users are implemented through a system object called a "validation list". Validation list objects contain lists of users and passwords that are specifically defined for use with a particular application.
    You decide how Internet user IDs and passwords are supplied (such as by an application, or by an administrator in response to an e-mail request), as well as how to manage Internet users. Use the HTTP server’s browser-based interface to set this up.
    
    For nonsecure networks (the Internet), using Internet users provides better overall protection than using normal user profiles and passwords. The unique set of user IDs and passwords creates a built-in limitation on what those users can do. The user IDs and passwords are not available for normal sign-on (such as with TELNET or FTP). In addition, you are not exposing normal user IDs and passwords to sniffing.
  3. Lightweight directory access protocol (LDAP) is a directory service protocol that provides access to a directory over a Transmission Control Protocol (TCP). It lets you store information in that directory service and query it. LDAP is now supported as a choice for user authentication.
    Notes:
    - When the browser sends the user ID and the password (whether for an user profile or an Internet user), they are encoded, not encrypted. The encoding scheme is an industry standard, and thus commonly known among the hacker community. Although the encoding is not easily understood by the casual "sniffer", a sophisticated sniffer probably has tools to attempt to decode them.
    - The system stores the validation object in a protected system area. You can access it only with defined system interfaces (APIs) and proper authorization.
- You can use Digital Certificate Manager (DCM) to create your own intranet Certificate Authority. Digital Certificate automatically associates a certificate with the owner’s user profile. The certificate has the same authorizations and permissions as the associated profile.
When the server accepts a request, normal system resource security takes over. The user profile that requests the resource must have authority to the resource (such as the folder or source physical file that contains the HTML document). By default, jobs run under the QTMHHTTP user profile. You can use a directive to swap to a different user profile. The system then uses that user profile’s authority to access objects. Following are some considerations for this support:
- Swapping user profiles can be particularly useful when your server provides more than one logical Web site. You can associate a different user profile with the directives for each Web site, and thus use normal system resource security to protect the documents for each site.
- You can use the ability to swap user profiles in combination with the validation object. The server uses a unique user ID and password (separate from your normal user ID and password) to evaluate the initial request. After the server has authenticated the user, the system then swaps to a different user profile and thus takes advantage of resource security. The user is, thus, not aware of the true user profile name and cannot attempt to use it in other ways (such as FTP).
Some HTTP server requests need to run a program on the HTTP server. For example, a program might access data on your system. Before the program can run, the server administrator must map the request (URL) to a specific user-defined program that conforms to CGI user-interface standards. Following are some considerations for CGI programs:
- You can use the protection directives for CGI programs just as you do for HTML documents. Thus, you can require a user ID and password before running the program.
- By default, CGI programs run under the QTMHHTP1 user profile. You can swap to a different user profile before running the program. Therefore, you can set up normal system resource security for the resources that your CGI programs access.
- As security administrator, you should perform a security review before authorizing the use of any CGI program on your system. You should know where the program came from and what functions the CGI program performs. You should also monitor the capabilities of the user profiles under which you run CGI programs. You should also perform testing with CGI programs to determine, for example, whether you can gain access to a command line. Treat CGI programs with the same vigilance that you treat programs that adopt authority.
- In addition, be sure to evaluate what sensitive objects might have inappropriate public authority. A poorly designed CGI program might, in rare cases, allow a knowledgeable, devious user to attempt to roam your system.
- Use a specific user library, such as CGILIB, to hold all your CGI programs. Use object authority to control both who can place new objects in this library and who can run programs in this library. Use the directives to limit the HTTP server to running CGI programs that are in this library.

Tip: If your server provides multiple logical Web sites, you might want to set up a separate library for the CGI programs for each site.

Other security considerations

Following are additional security considerations:

HTTP provides read-only access to your system. HTTP server requests cannot update or delete data on your system directly. However, you might have CGI programs that update data. Additionally, you can enable the Net.Data^® CGI program to access your system database. The system uses a script (which is similar to an exit program) to evaluate requests to the Net.Data program. Therefore, the system administrator can control what actions the Net.Data program can take.
The HTTP server provides an access log that you can use to monitor both accesses and attempted accesses through the server.