Your Daily Source for Apache News and Information  
Breaking News Preferences Contribute Triggers Link Us Search About
Apache Today [Your Apache News Source] To

Achieving Maximum Reliability, Availability, Scalability and Performance

Apache HTTPD Links
Apache Project
The Jakarta Project
Apache XML Project
The Java Apache Project
Apache-Perl Integration Project
PHP Server Side Scripting
Apache-Related Projects
The Apache Software Foundation
Apache Module Registry
The Apache FAQ
The Linux Channel at
Linux Planet
Linux Central
Linux Today
Just Linux
Enterprise Linux Today
BSD Central
BSD Today
Linux Start
Linux Apps
All Linux Devices
Apache Today
Linux Programming
Apache Guide: mod_access: Restricting Access by Host
Nov 13, 2000, 15 :51 UTC (5 Talkback[s]) (15864 reads) (Other stories by Rich Bowen)


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.


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:

     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
     Deny from
     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 will deny all access to hosts on the network, but people on the 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
     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
     Deny from

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


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

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

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.


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)

  Current Newswire:
Apache 1.3.23 released

wdvl: Build Your Own Database Driven Website Using PHP and MySQL: Part 4

Business 2.0: Find High Tech in the Bargain Basement

Another mod_xslt added to the Apache Module Registry database

Netcraft Web Server Survey for December is available

O'Reilly: Apache Web-Serving with Mac OS X: Part 1

WDVL: Perl for Web Site Management: Part 3

Retro web application framework V1.1.0 release

Leveraging open standards such as Java, JSP, XML,J2EE, Expresso and Struts.

Netcraft Web Server Survey for November is available

 Talkback(s) Name  Date
Please give some information code about ASP, PHP, VBScript, Javascript and Cold ...   My Request   
  Nov 15, 2000, 07:31:07
Hello, I send you this message because I need your help. I ask you if I can make ...   HELP   
  Nov 17, 2000, 20:30:55
How do I allow users from one groupto view a content of a directory and deny acc ...   directory content restriction   
  Dec 12, 2000, 19:44:48
Great article. Very easy to understand. One question though.What if you want to ...   Deny #.#.#.#   
  Sep 19, 2001, 22:30:32
ICan I configure my Apache server authentification combinating username and IP a ...   Authentification with user name and IP   
  Dec 11, 2001, 22:54:19
Enter your comments below.
Your Name: Your Email Address:

Subject: CC: [will also send this talkback to an E-Mail address]

See our talkback-policy for or guidelines on talkback content.

About Triggers Media Kit Security Triggers Login

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.