Your Daily Source for Apache News and Information

By

In earlier articles, I talked about restricting access to your web server based on a username and password provided by the user.

You can also restrict access based on the hostname or IP address from which the user is connecting to your site. The apache module mod_access provides this functionality.

There are three main directives that implement this functionality, and they are typically used in combination, rather than individually. I'll talk about each directive, and then we'll look at some ways that you can combine them to have the desired effects.

Deny

The Deny directive, as the name implies, denies access to resources, based on the address of the client machine. The syntax is simple:

     Deny from host

The host argument in this directive is extremely flexible. It can be any of the following:

all

     Deny from all

Does not permit any hosts to have access to the specified resource. This may seem a little silly at this point, but it has a valid use that we'll see later on.

A hostname, or a partial domain name

     Deny from evil.spammer.com
     Deny from h4x0rz.com
     Deny from .gov

Setting the host argument to a hostname, or a partial hostname, will deny access to any host whose name matches the argument, or ends in the argument.

Something important to note here is that this only matches complete elements. For example, the directive Deny from keys.com will deny all access to hosts on the keys.com network, but people on the monkeys.com network will still be able to get in.

You should also note that this is only going to be useful if you can, in fact, do a reverse lookup on the address in question. If, for example, someone is coming from a .gov address, but there is no reverse-zone record for their address, they will still be permitted to get in.

An IP address, or partial IP address

     Deny from 204.255.230.13
     Deny from 192.168.
     Deny from 9.

As expected, these will deny access to hosts from addresses matching the IP address ranges specified. In the three examples above, the directives deny access from a specific IP address, from all the IP addresses in the private 192.168.*.* IP range, and all IP addresses in the IBM 9.*.*.* range of addresses.

A network and netmask pair

     Deny from 10.1.0.0/16
     Deny from 10.1.1.0/255.255.0.0

For those that know a little more about how IP works, you can use a network and subnet mask pair to specify a range of addresses. The specifics of what these mean is beyond the scope of this article.

Finally, note that you can specify more than one host argument in this directive:

     Deny from evil.hacker.com monkey.loser.com

Allow

The counterpart to Deny is, of course, Allow, which specifies what hosts are to be allowed access. The arguments to Allow are exactly the same as those for Deny, so I won't spend a lot of time going through them.

     Allow from all
     Allow from 192.168.1.
     Allow from .edu

Order: Using Allow and Deny Together

In most real-world situations, you'll want to use Deny and Allow together to allow some folks in, or leave some folks out, and to have a degree of control over who those folks are.

This is where the Order directive comes in. The Order directive tells Apache in which order to process the Allow and Deny directives when they are used together. Order can be set to one of the following values:

Order Allow,Deny

Process the Allow directives first, and then the Deny directives.

Order Deny,Allow

Process the Deny directives first, and then the Allow directives.

Which one of these you use depends mostly on whether you are trying to restrict access to just a few people, or if you are trying to let almost everyone on.

For example, if you want to let everyone in, except for that nasty person that keeps posting unpleasant things on your message board, you'd do something like this:

     Order Allow,Deny
     Allow from all
     Deny from monkey.loser.com

On the other hand, if you're trying to make sure that nobody in the world can get to your site except for the small list of people that are connecting from your company, you'd do something like:

     Order Deny,Allow
     Deny from all
     Allow from friends.mycompany.com

Advanced Options with Allow and Deny

When combined with the SetEnvIf directive, you can do some even more powerful stuff with controlling who can get to your content.

SetEnvIf is a directive implemented by mod_setenvif, which allows you to set environment variables based on conditional statements. This is pretty cool, and can let you do some very neat stuff when combined with other directives.

In conjunction with the Allow and Deny directives, it can be made to allow or deny access to resources based on things other than host address.

Using SetEnvIf

The syntax for SetEnvIf is as follows:

     SetEnvIf attribute regex variable[=value]

If the regular expression matches the attribute (or environment variable) then the variable is set and placed into the environment. For example:

     SetEnvIf User-Agent MSIE InternetExplorer

If the User-Agent (browser) variable matches the regular expression MSIE -- that is, if the browser is Internet Explorer -- then the environment variable InternetExplorer will be set true and placed in the environment.

Using SetEnvIf with Allow and Deny

Allow and Deny have an alternate syntax that let them take advantage of environment variables set with SetEnvIf, as well as other environment variables:

     SetEnvIf User-Agent EvilRobot GoAway
     Order Allow,Deny
     Allow from all
     Deny from env=GoAway

In the above example, if the User-Agent variable matches the string EvilRobot, then the environment variable GoAway is set. The directive Deny from env=GoAway tells Apache to deny access from hosts for whom the GoAway environment variable is set.

Similarly, Allow from env= permits access based on variables that you can set with SetEnvIf.

Combining Allow, Deny, and Other Access-Control Techniques

You have content on your web site that you want to protect from prying eyes, so you put a password on it. But you don't want people in your company to have to use a password every time. Using the Satisfy directive, you can require either condition:

     Deny from all
     Allow from 192.101.
     Require group Company
     Satisfy any

Satisfy any specifies that either the user must come from the specified address range, or that they provide a password, but not necessarily both. Satisfy all would require that all the conditions be met - that the user come from the specified address range, and provide a password.

Summary

Using Allow and Deny lets you have a great deal of conrol over who can and who cannot have access to the content on your site.

Related Stories:
Apache Guide: Configuring Your Apache Compile with ./Configure(Nov 06, 2000)
Apache Guide: Generating Fancy Directory Listings with mod_autoindex(Oct 09, 2000)
Apache Guide: Logging, Part 5: Advanced Logging Techniques and Tips(Sep 25, 2000)
Apache Guide: Logging, Part 4 -- Log-File Analysis(Sep 18, 2000)
Apache Guide: Logging, Part 3 -- Custom Logs(Sep 05, 2000)
Apache Guide: Logging, Part II -- Error Logs(Aug 28, 2000)
Apache Guide: Logging with Apache--Understanding Your access_log(Aug 21, 2000)
Apache Guide: Apache Authentication, Part 4(Aug 14, 2000)
Apache Guide: Apache Authentication, Part 3(Aug 07, 2000)
Apache Guide: Apache Authentication, Part II(Jul 31, 2000)
Apache Guide: Apache Authentication, Part 1(Jul 24, 2000)
Apache Guide: Setting Up Virtual Hosts(Jul 17, 2000)
Apache Guide: Configuring Your Apache Server Installation(Jul 10, 2000)
Apache Guide: The Newbie's Guide to Installing Apache(Jul 03, 2000)
Apache Guide: Advanced SSI Techniques(Jun 26, 2000)
Apache Guide: Introduction to Server Side Includes, Part 2 (Jun 19, 2000)
Apache Guide: Introduction to Server Side Includes(Jun 12, 2000)
Apache Guide: Dynamic Content with CGI(Jun 05, 2000)

All times are recorded in UTC. Linux is a trademark of Linus Torvalds. Powered by Linux 2.4, Apache 1.3, and PHP 4 Copyright 2002 INT Media Group, Incorporated All Rights Reserved. Legal Notices,  Licensing, Reprints, & Permissions,  Privacy Policy.