160 lines
11 KiB
HTML
160 lines
11 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<!DOCTYPE html
|
||
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
<html lang="en-us" xml:lang="en-us">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
<meta name="security" content="public" />
|
||
<meta name="Robots" content="index,follow" />
|
||
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
<meta name="DC.Type" content="concept" />
|
||
<meta name="DC.Title" content="Protect resources" />
|
||
<meta name="abstract" content="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." />
|
||
<meta name="description" content="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." />
|
||
<meta name="DC.Relation" scheme="URI" content="rzamvtcpcontrolhttp.htm" />
|
||
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
|
||
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
|
||
<meta name="DC.Format" content="XHTML" />
|
||
<meta name="DC.Identifier" content="tcpresourcehttp" />
|
||
<meta name="DC.Language" content="en-us" />
|
||
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
<!-- US Government Users Restricted Rights -->
|
||
<!-- Use, duplication or disclosure restricted by -->
|
||
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
<title>Protect resources</title>
|
||
</head>
|
||
<body id="tcpresourcehttp"><a name="tcpresourcehttp"><!-- --></a>
|
||
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
<h1 class="topictitle1">Protect resources</h1>
|
||
<div><p>The IBM<sup>®</sup> 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.</p>
|
||
<div class="p">Following are some suggestions for using HTTP directives:<ul><li>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). </li>
|
||
<li>You can use protection directives to require a user ID and password before
|
||
accepting a request for some or all of your resources.<ul><li>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. <p>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.</p>
|
||
</li>
|
||
<li>You have three options for how the system handles user IDs and passwords
|
||
(specified in the protection directives):<ol><li>You can use normal system user profile and password validation. This is
|
||
most commonly used to protect resources in an intranet (secure network). </li>
|
||
<li>You can create <span class="q">"Internet users"</span>: 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 <span class="q">"validation list"</span>. Validation list objects contain
|
||
lists of users and passwords that are specifically defined for use with a
|
||
particular application.<p>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. </p>
|
||
<p>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.</p>
|
||
</li>
|
||
<li>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.<div class="note"><span class="notetitle">Notes:</span> <ul><li>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 <span class="q">"sniffer"</span>,
|
||
a sophisticated sniffer probably has tools to attempt to decode them. </li>
|
||
<li>The system stores the validation object in a protected system area. You
|
||
can access it only with defined system interfaces (APIs) and proper authorization.</li>
|
||
</ul>
|
||
</div>
|
||
</li>
|
||
</ol>
|
||
</li>
|
||
<li>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.</li>
|
||
</ul>
|
||
</li>
|
||
<li>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:<ul><li>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. </li>
|
||
<li>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).</li>
|
||
</ul>
|
||
</li>
|
||
<li>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:<ul><li>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. </li>
|
||
<li>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. </li>
|
||
<li>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. </li>
|
||
<li>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. </li>
|
||
<li>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.</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
<div class="tip"><span class="tiptitle">Tip:</span> If your server provides multiple logical Web sites, you might
|
||
want to set up a separate library for the CGI programs for each site.</div>
|
||
<div class="section" id="tcpresourcehttp__tcpotherhttp"><a name="tcpresourcehttp__tcpotherhttp"><!-- --></a><h4 class="sectiontitle">Other security considerations</h4><div class="p">Following
|
||
are additional security considerations: <ul><li>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<sup>®</sup> 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.</li>
|
||
<li>The HTTP server provides an access log that you can use to monitor both
|
||
accesses and attempted accesses through the server.</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div>
|
||
<div class="familylinks">
|
||
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzamvtcpcontrolhttp.htm" title="This article discusses considerations for protecting the contents of your Web site.">Control access to the HTTP server</a></div>
|
||
</div>
|
||
</div>
|
||
</body>
|
||
</html> |