MicroApache Tips and Tricks

Home | Root | Official Apache 1.3 Manual | Official Apache 2.0 Manual | Official Apache 2.2 Manual

Contents

• Setting up Public Directory Access On Your Apache Server
  Access Configuration Without Using .htaccess Files
  Protecting Critical System Folders
  
• Restricting Access to Public Webserver Directories (Folders)
  Password Protection (Basic Authentication)
  Allowing IP Addresses to Secure Areas
  Denying IP Addresses in Specified Areas

Setting up Public Directory Access On Your Server

Configuration of MicroApache is exactly the same as for Standard Apache. If you intend to use MicroApache on any public-facing website you should spend some time carefully considering your site design then ensuring you configure it properly to ensure public access is limited only to the areas you want to be made visible

By default Apache makes everything public and visible to anyone, so the first task should be to lock-down access by setting a very restrictive access policy to the root directory of your server then finally, relaxing this on a one-by-one basis for directories you want to grant public access to.

You can control access by use of either <Directory > statements in your httpd.conf configuration file or using .htaccess files. It is strongly suggested that you never use .htaccess files unless you have a very special reason for doing so such as specialised PHP or blog software which is inherently dependent on them. The guys at Apache.org recommend that .htaccess files are used only where you don't have full access to the main server httpd.conf file. With MicroApache you should have full access to this file so there will be no need to use anything but the main configuration file to control access.

If you decide to use .htaccess files then ensure you have relevant "AllowOverride All" statements (or suitable variant) applying to the relevant folders where .htaccess files will apply. With no AllowOverride statement present at all the default setting Apache will use is "AllowOverride All". This will force Apache search for .htaccess files in every sub-folder unless there are directives which specify otherwise. You should have spotted the problem here; that searching for .htaccess files in every folder of a large site will slow down your server and this will happen even where you don't use .htaccess files. More information on using .htaccess files can be found on this page should you need to use them.

One thing to note is right from the start, that you need to use "Unix" (Linux) style directory slash characters in your config file. That is "/" in place of "\". If you use the Windows/DOS backslash in your configuration you will get an error and the server will fail to start. Note also that in many cases you must specify the complete DOS/Windows path including the drive-letter, otherwise not only can confusion arise but Apache may, again, fail to load with a configuration error. Using DOS backslash characters in the server config is a main cause for new Apache admins to run into problems but it's such an "old hat" issue that most people don't bother to mention it.

Don't get too confused by the "#" characters in examples below. These characters simply prefix comments in any httpd.conf file. Anything after the # on a line is ignored by Apache

Access Configuration Without Using .htaccess Files

The best policy for a public-facing server is to specify "AllowOverride None" for the top-level "root" (/) folder and ignore .htaccess files altogether. It is important to note that directives "inherit" downwards so if you specify a restrictive directive for a top-level folder then this will apply to all subsequent subfolders. This allows you to set a such a restrictive overall policy then override or "relax" this for specific folders on a one-by-one basis as required. To set a restrictive global policy at root which can be overridden by distinct <Directory> blocks at a lower-level use -

<Directory />
  # Restrict access completely from ROOT downwards
  AllowOverride None
  Order Allow,Deny
  Deny from All
</Directory>

This safe and restrictive policy denys everyone from all access and prevents such settings being overridden unless by other <Directory> statements such as the following which allows public access to /webroot (c:\webroot) and relax the restrictive global policy on a one-by-one basis for each folder.

<Directory c:/webroot>
  # ALLOW access in this folder, overriding any inherited restrictions from higher-up
  AllowOverride None
  Order Allow,Deny
  Allow from All
</Directory>

If you configure your server this way the only areas which should be visible are those where you have specifically granted access. You should pay attention to the "Order" statement. Using "Order Allow, Deny" is more-secure than "Order Deny, Allow" since on failure access is denied by default with the former and granted by default with the latter. The issue is discussed on this Apache page. Generally you will need to use only "Order Allow, Deny"

Protecting Critical System Folders

Regardless of what strategy you choose you should ensure that certain sensitive system directories are protected. Your distro of MicroApache may be supplied with a very relaxed access policy as it's main purpose is to provide personal webserver access to floppy disks, USB drives or CD/DVD-ROM media. In these cases you would be reasonably happy at having full-access to the entire media and the server would not be "public-facing" or online for any length of time. MicroApache was never intended to be used as a primary production webserver. If you find you are tempted to do this you should really be considering installing a full and complete copy of the latest Apache Win32 binary and spending a considerable amount of time on security design. However, key-directories where the public should never have access include -

The server root itself and then under this...
BIN (if present)
CGI-BIN (protected when you define it as the cgi script directory)
CONF
LOGS
MODULES
ERROR

If you have specifically set up a restrictive configuration from root (/) which is inherited down into every subfolder you shouldn't need to specifically protect the critical system areas above. However if you need to protect them you can use an entry with a relative-path such as -

<Directory logs>
  # DENY access in this folder, overriding any *permissive* restrictions set from higher-up
  AllowOverride None
  Order Allow,Deny
  Deny from All
</Directory>

The CGI-BIN script directory is protected when it is defined as the script area using the following ScriptAlias entry. Unless this is present your CGI scripts won't work. If present Apache will interpret ANY file found in this directory as a script and try it's best to run it.

ScriptAlias /cgi-bin/ "cgi-bin/"

Alternately you could simply deny access globally in the current MicroApache directory (".") and then enable public access to the CGI-BIN only as follows -

<Directory .>
AllowOverride None
Order Deny,Allow
Deny from All
</Directory>

<Directory cgi-bin>
# Override deny from "."
AllowOverride None
Order Deny,Allow
Allow from All
</Directory>

If you browse your "site" using the above to view say, the contents of a USB pen-drive then you should note that your MicroApache folder has now disappeared from any listing but you should still be able to run CGI scripts in http://server/cgi-bin/

You should test the server to ensure that members of the public cannot gain access to these critical system folders or your server (and network) may be compromised by hackers.

You can specify two core directory configuration options. These are ServerRoot and DocumentRoot. The ServerRoot is where Apache and it's system folders or files reside. The DocumentRoot may or may not be the same folder. Generally it is good practice to ensure that the DocumentRoot is in a separate "directory-tree" to the Apache program. Better still if this is set to a completely different disk or volume. However, if you are using Apache simply to share a CDROM or USB-stick on a private home network this may not be of importance to you.

Both the ServerRoot and DocumentRoot may take a range of useful parameters. Note that on earlier versions of Apache such as Apache 1.3.x you may not be able to use all of these - in particular driveless paths from root such as /wwwroot may not always work in Win32/Apache.

.The above examples apply equally to ServerRoot and DocumentRoot statements

Restricting Access to Public Webserver Directories (Folders)

You can add (or relax) additional restrictions to public-facing directories by password-protecting or limiting access to specified IP addresses or alternately blocking known addresses or address-ranges. Again, you can do this using .htaccess files but this isn't recommended. The best way to do this is to use properly-configured <Directory> blocks in your httpd.conf server configuration file.

Password Protection (Basic Authentication)

To password-protect a directory (folder) using "Basic Authentication" you must first set up a password file. You will need the password utility called HTPASSWD.EXE from a standard install of Apache.

First, create a folder to hold your password file. It is important that this should NEVER be placed within your webserver "root tree". Ideally it should be in a completely separate location such as C:/PASSWORD where your Apache server is in C:/PORTABLEAPPS/APACHE/ and your DocumentRoot is in C:/WWWROOT. This means that the only way a hacker can get to your password file is by gaining access to the "root" folder (C:\) in order to traverse across and then back down into your password folder.

Now you will need to create users with passwords using the HTPASSWD.EXE program. I prefer to drive this with a simple batch file called ADDUSER.BAT which can be called with the syntax adduser username. The htpasswd program will prompt you to enter a password for the new user.

@echo off
REM Adduser.bat
echo Adding user [%1]
htpasswd htpasswd.txt %1

Once users are added to your password file (as specified manually or in adduser.bat) you need to add an authentication section to a <Directory> block in your httpd.conf configuration file which tells Apache how to authenticate and which password file to reference.

<Directory "c:/wwwroot/private">
  AuthType Basic
  AuthName "Private Area"
  AuthUserFile c:/password/htpasswd.txt
  Require user fred
  Satisfy All
<Directory>

Note that other configuration options such as AllowOverride have been omitted from the above example. You may specify multiple users by separating them with white-space e.g. "Require user fred sid jack". Note also that any specified user MUST exist. You can also specify any user by using the statement "Require valid-user" in place of "Require user fred". The "Satisfy All" statement ensures that Apache satisfies ALL other security requirements you may enter in this <Directory> config block such as IP-address limits or permissions. Other user-access alternatives include "Require valid-user" to allow any use you have created It is also possible to set up groups and group-access but this is an advanced topic covered in more detail in the Apache manual.

Allowing IP Addresses to Secure Areas

You will almost certainly want to allow your own administration machine or local network to have unfettered access to password restricted folders. It can be a pain having to enter passwords which are intended to restrict public access. You can achieve this by adding an Allow From <IP address> entry to your configured <Directory> block placed in your httpd.conf file. Taking the last example we get...

<Directory "c:/wwwroot/private">
  AuthType Basic
  AuthName "Private Area"
  AuthUserFile c:/password/htpasswd.txt
  Require user fred
  Allow from 192.168.1.
  Satisfy Any
<Directory>

We have allowed anyone on private subnet 192.168.2.* to enter the "../private" area without entering a password. Note that the Satisfy clause has now been changed to "Satisfy Any" so that either of the cases can apply. You could leave it set to "Satisfy All" but that would mean that password protection and IP address restrictions would apply IF you had also had additional IP address restrictions limiting access. In other words, only those on subnet 192.168.2.* would be able to gain password-protected access, for example as in -

<Directory "c:/wwwroot/private">
  Order Allow, Deny
  AllowOverride None
  # Ultimate restriction follows on next line...
  Deny from All
  AuthType Basic
  AuthName "Private Area"
  AuthUserFile c:/password/htpasswd.txt
  Require user fred
  # Fred can ONLY log-in from subnet 192.168.1.*
  Allow from 192.168.1.
  Satisfy All
<Directory>

Allowing specified IP addresses to areas where access is otherwise blocked is just as easy. For example, to allow only one machine access to a secret directory you could use -

<Directory "c:/wwwroot/secret">
  Order Allow, Deny
  AllowOverride None
  Deny from All
  Allow from 192.168.1.128
<Directory>

Denying IP Addresses in Specified Areas

You can deny access to individual IP addresses, subnets, domain names or machine names using the Deny From statement.

<Directory c:/wwroot/my-photos>
  # For example ONLY
  AllowOverride None
  Order Deny,Allow
  # Allow public access to all
  Allow from All
  #But deny access to the following visitors to this folder
  # Chinese domains
  Deny from .cn
  # A LACNIC area
  Deny from 200.
  # An APNIC area
  Deny from 218.
  # Known pest domains running bots and malware
  Deny from .reverse.theplanet.com
  Deny from .keymachine.de
  # Deny access to some fictitious hackers
  Deny from 12.34.56.78
  Deny from 1-2-dsl-dialup-town-78-56-34-12.someisp.com
  # Deny a whole spy-subnet using CIDR bit-masking (first 18 bits must match the mask)
  Deny from 66.160.198.0/18
</Directory>

These Deny statements can also be combined with "Allow From" or other authentication statements to provide fine-grained control over who gets access to specific areas. Here, the ordering of the "Order" directive becomes important. The "Allow" directives are analysed first then the "Deny" directives applied afterwards. You can use this with any combination of blocked addresses such as the following where 192.168.1.128 is guaranteed access regardless of whatever other subnets or addresses have been blocked -

<Directory "c:/wwwroot/secret">
  Order Allow, Deny
  AllowOverride None
  Deny from .keymachines.de
  Deny from .reverse.theplanet.com
  Deny from .cn
  Deny from 200.
  Deny from 194.200.
  Deny from 10.2.8.33
  Deny from 192.168.1.
  Allow from 192.168.1.128
  Allow from .google.com
  Allow from .myisp.com
  Allow from .friendlyisp.com
<Directory>

If Deny/Allow conditions are used together with authentication then you will need to select the most appropriate "Satisfy" clause to ensure the various conditions work together in the way you intended. Notice that Deny/Allow matches are made using a simple string matching rather than by numeric analysis of addresses. This means it can be important to use trailing dots   to ensure you match the intended part of any string. Also, these can be full or partial domain names as well as numeric ip-addresses. Using domain names you can block everyone from "troublesome" parts of the internet. You can read more about how <Directory> blocks work on this page and more about Allow/Deny and Satisfy on this page

More articles will be added as soon as time permits - please provide feedback or corrections

Top of Page

Text Copyright (C) M Shaw - 2007 - Page best viewed at 1024x768 - last updated on 25 February 2021