The authentication and security directives discussed in the following sections enable you to define authentication and access restrictions for your Web server. You can use username- and password-based authentication to restrict access to certain parts of your Web site. Also, you can use username-, IP address-, or hostname-based access control to ensure that only valid users or systems are allowed access to portions of your Web site.
AllowOverride
The AllowOverridedirective tells the server which directives declared in an .htaccessfile (as specified by AccessFileName) can override earlier directives found in configuration files. When Overrideis set to None, the server does not read the file specified by AccessFileName(default .htaccess). This could speed up the response time of the server, because the server does not have to look for an AccessFileNamespecified file for each request (see the AccessFileNamesection for details).
Syntax: AllowOverride option1 option2 ...
Default setting: AllowOverride All Context: directory
If you do want to allow AccessFileName-based control, you can specify one or more of the options. The override options are:
✦AuthConfig— Enables use of the authorization directives (such as AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, and Require).
✦FileInfo— Enables use of the directives controlling document types (such as AddEncoding, AddLanguage, AddType, DefaultType, ErrorDocument, and LanguagePriority).
✦Indexes— Enables use of the directives controlling directory indexing (such as AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, and ReadmeName).
✦Limit— Enables use of the directives controlling host access (Allow, Deny, and Order).
✦Options— Enables use of the directives controlling specific directory features (Optionsand XBitHack).
Note
AuthName
The AuthNamedirective sets the authentication realm name for a resource (such as a directory) that requires authentication. The realm is usually displayed by a Web browser in a pop-up dialog window when prompting for a user name and password to access the requested (controlled) resource. There is no default realm name. The primary purpose of this label is to inform users on the client side about what resource they are trying to access.
Syntax: AuthName “authentication_realm_name Default setting: None
Context: directory, .per-directory config
Override: AuthConfig
For example, “AuthName Secured Game Zone”informs users that they are requesting to enter the Secured Game Zone area of a site. Note that for this direc-tive to work, it must be accompanied by AuthType, Require, AuthUserFileand AuthGroupFile directives.
AuthType
The AuthTypedirective selects the user authentication type for a directory.
Currently, only BasicHTTP authentication or Digestauthentication types are implemented in Apache. The Basicauthentication should not be used for serious needs; the password and username are transmitted in clear (plain) text. The pass-word and username is retransmitted for each subsequent request that maps in the same restricted directory or its subdirectories. The Digestauthentication is more secure than the Basicbut it is not readily available for all Web browsers. See Chapter 7 for details. The AuthTypedirective must be accompanied by AuthName and requires other directives, such as AuthUserFileand AuthGroupFile, to work.
Syntax: AuthType Basic | Digest Default setting: None
Context: directory, per-directory config Override: AuthConfig
HostNameLookups
The HostNameLookupsdirective instructs Apache to enable or disable a DNS lookup for each request. When enabled, Apache stores the host name of the client in the REMOTE_HOSTenvironment variable of each CGI and SSI process it runs.
Syntax: HostNameLookups on | off | double Default setting: HostNameLookups off
Context: Server, virtual host, directory, per-directory config
The onand offvalues do what their names imply. The doublevalue refers to doing a double-reverse DNS lookup — that is, after a reverse lookup is performed, a for-ward lookup is then performed on that result. At least one of the IP addresses in the forward lookup must match the original address. However, the CGI and SSI pro-cesses do not get the results from the double DNS lookups.
No matter what you set this directive to, when mod_access(see Chapter 7) is used to control access by host name, a double-reverse lookup is performed, which is not fast but necessary for ensuring security
I recommend that you keep the default setting for this directive. This will remove a lot of unnecessary DNS traffic from the net. If you want to turn it on just so your log files contain IP names instead of IP addresses, you may want to consider another option, such as running the logresolveutility to resolve IP addresses to IP names.
IdentityCheck
The IdentityCheckdirective tells Apache to log remote usernames by interacting with the remote user’s identd(identification daemon) process, or an RFC1413-compliant server. This is rarely a useful directive because it will not work for all systems. Most systems do not run identdprocesses to provide user identifications to remote servers.
Syntax: IdentityCheck On | Off Default setting: IdentityCheck Off
Context: server config, virtual host, directory, .per-directory config
If you decide to use this directive in your configuration, be aware that the informa-tion you log is not to be trusted in any way except for usage tracking. This directive can also cause major performance problems because the server has to perform checking for each request. Also, when a remote user is either not providing an identdservice or is behind a firewall or proxy, the checking process has to time out.
<Limit>
The <Limit> container directive is used to enclose a group of access control direc-tives, which will then apply only to the specified HTTP methods. The method names listed can be one or more of the following: GET, POST, PUT, DELETE, CONNECT, and OPTIONS. If GETis used, it will also restrict HEADrequests. If you wish to limit all methods, do not include any method in the <Limit>directive at all. Note that Caution
Note
this container cannot be nested, and neither can a <Directory>container appear within it. Method names are case-sensitive.
Syntax: <Limit method method ... > ... </Limit>
Default setting: None Context:All
<LimitExcept>
The <LimitExcept>container directive is used as the complete opposite of
<Limit>directive (<limit> limits named (i.e. arguments) methods and
<LimitExcept> limits everything otherthan the arguments). All the methods that are not listed as arguments are limited.
Syntax: <LimitExcept method method ... > ... </LimitExcept>
Default setting: None Context:All
In the following example, the limit applies to all HTTP methods except GET.
<LimitExcept GET>
# directives
</LimitExcept>
LimitRequestBody
The LimitRequestBodydirective enables you to set a limit on the size of the HTTP request that Apache will service. The default limit is 0, which means unlimited. You can set this limit from 0 to 2147483647 (2GB).
Syntax: LimitRequestBody bytes Default setting: LimitRequestBody 0
Context: Server config, virtual host, directory, per-directory
Setting a limit is recommended only if you have experienced HTTP-based denial of service attacks that try to overwhelm the server with large HTTP requests. This is a useful directive to enhance server security.
LimitRequestFields
The LimitRequestFieldsdirective allows you to limit number of request header fields allowed in a single HTTP request. This limit can be 0 to 32767 (32K). This directive can help you implement a security measure against large request based denial of service attacks.
Syntax: LimitRequestFields number Default setting: LimitRequestFields 100 Context:Server config
LimitRequestFieldsize
The LimitRequestFieldsizedirective enables you to limit the size (in bytes) of a request header field. The default size of 8190 (8K) is more than enough for most sit-uations. However, if you experience a large HTTP request-based denial of service attack, you can change this to a smaller number to deny requests that exceed the limit. A value of 0 sets the limit to unlimited.
Syntax: LimitRequestFieldsize bytes Default setting: LimitRequestFieldsize 8190 Context: Server config
LimitRequestLine
The LimitRequestLinedirective sets the limit on the size of the request line. This effectively limits the size of the URL that can be sent to the server. The default limit should be sufficient for most situations. If you experience a denial of service attack that uses long URLs designed to waste resources on your server, you can reduce the limit to reject such requests.
Syntax: LimitRequestLine bytes Default setting: LimitRequestLine 8190 Context: Server config
Require
By using the Requiredirective, Apache determines which users or group can access a restricted directory. There are three types of entity names available: user, group, valid-user. For example, require user joe jennytells Apache to allow only joe or jenny to enter the area after successful authentication. Only the named users can access the directory.
Syntax: Require entity_name entity_name...
Default setting: None
Context: directory, per-directory config Override: AuthConfig
As an example of a group-based access requirement, only users in the named groups can access the directory in the following:
Require group my-group your-group his-group her-group With the following line, all valid users can access the directory.
require valid-user
If the require directive appears in a <Limit>section, then it restricts access to the named methods; otherwise, it restricts access for all methods. For example:
AuthType Basic
AuthName “Game Zone Drop Box”
AuthUserFile /www/netgames/.users AuthGroupFile /www/ntgames/.groups
<Limit GET>
require group coders
</Limit>
If the preceding configuration is found in an .htaccessfile in a directory, only a group called coders is allowed access to the directory to retrieve files via the HTTP GETmethod. To work correctly, the Requiredirective must be accompanied by AuthNameand AuthTypedirectives, and by directives such as AuthUserFileand AuthGroupFile.
See Chapter 7 for details on authentication.
Satisfy
If you have created a basic HTTP authentication configuration in which both Allow and Requiredirectives are used, you can use the Satisfydirective to tell Apache what authentication requirements will be sufficient.
Syntax: Satisfy Any | All Default setting: Satisfy all Context: directory, per-directory
The value of the Satisfydirective can be either allor any. If the value is all, then the authentication succeeds only if both Allowand Requiresucceed. If the value is any, then the authentication succeeds if either Allowor Requiresucceeds.
The Satisfydirective is useful only if access to a particular area is being restricted by both the username/password and the client host address. In this case, the
Cross-Reference
default behavior (all) requires that the client pass the address access restriction and enter a valid username and password. With the anyoption, the client is granted access if the user either passes the host restriction or enters a valid username and password. This directive can be used to restrict access to an area by using pass-words, while simultaneously giving access to all clients from a particular IP address pool (that is, a set of IP addresses) without requiring them to enter passwords.
ScriptInterpreterSource
The ScriptInterpreterSourcedirective allows you to specify how Windows finds the interpreter for a script. Normally, the script interpreter is detected using the #!line found in a script. However, setting this directive to registry will force Windows to lookup the registry for the script’s extension to find the associated program (that is, interpreter) for it.
Syntax: ScriptInterpreterSource Registry | Script Default setting: ScriptInterpreterSource script Context: directory, .htaccess