Security and Apache: An Essential Primer - page 5

Maxwell's Demon and Hat Colour

Since the IP address is one of those aspects of a client-server HTTP relationship that cannot be changed mid-stream, and cannot be easily faked (without the cooperation of the intervening network systems), it's considered a nondiscretionary control. The Apache distribution includes a module for limiting access thusly, called mod_access.

The mod_access module allows you to specify what domains or addresses should or should not be allowed access, and in which order the two lists (allowed and denied) should be evaluated. The basic syntax of the Allow and Deny directives is:

    Allow from host-or-network

The host-or-network can be:

• a host or domain name (www.foo.com),
• an IP address (10.0.72.3),
• an IP address and subnet mask (10.0.0.0/255.0.0.0), or
• an IP address and CIDR mask size (10.73.128.0/18)

Whenever possible you should use IP addresses instead of domain names; using names means that the Apache server needs to do a double-reverse lookup on them to make the translation to the IP address of the client. (A double-reverse lookup, which is always done by Apache when dealing with host names in security-related situations, involves translating the name to an IP address, and then translating that IP address back to a list of names. If the translations don't work in both directions, Apache will consider the host/domain name match to have failed.)

As an added fillip, an alternate form of the Allow and Deny directives, "from�env=[!]envariable-name", allows you to make the go/no-go decision based upon the presence (or absence) of an environment variable. The envariable may have been set for the entire server environment, or it may have been set just for the current request by a module such as mod_setenvif.

The Order directive controls how the cumulative lists of Allow and Deny directives are interpreted. If the order is Allow,Deny (note that no spaces are permitted between the keywords!), then the initial state is the equivalent of Deny�from�All, the Allow conditions are processed, and then the Deny list is. For Order�Deny,Allow, the opposite is the case--the initial state is "allow everyone," then denials are handled, and then the allows are used to override them.

The easy way to remember the default state is to recall that it matches the last keyword: Deny,Allow means "allowed," and Allow,Deny means "denied."

There is a third possibility for the Order directive: mutual-failure. With this keyword, there is no "default state"--the only clients that will be allowed in are those that don't appear on any Deny directive, but do appear on at least one Allow directive.

Restricting by User Credentials
If you want to protect pages such that visitors need to enter a username and password, the mod_auth module is your tool. It is one of the simplest and easiest to use of the discretionary control modules.

The key directives in establishing access controls are those that define the location of the credential database and identify the authorized users. For mod_auth, the directives in question are AuthUserFile and Require. Other modules have similar directives.

The AuthUserFile directive simply takes a fully specified filename path (such as /home/foo/.htpasswd-foo), which tells the module where to find the text authentication file for the module to use in the current realm. No path-shortening or relative file specifications are permitted.

The Require directive is actually part of the core server rather than being specific to mod_auth, so it's documented (however sparsely) at <http://www.apache.org/docs/mod/core.html#require>. Require is covered in more detail shortly.