Webserver use, configuration and management
(see Nobles (2001), Chapter 28, Laurie (1999 or 2003), Chapter 5 or Arnold (2000), Chapter 6)
Access control relies on a number of
Apache modules, so the first step is to check that these are loaded and added
into the active working set for your current configuration. In an earlier
practical session we added a few modules. Make sure that you have
mod_auth installed and enabled.
The next task is to set up the
necessary subdirectories of the website. Create a directory called
private within your document root. The aim is to control access to files contained within that folder. Create a file (
index.htm will do) in that folder and also a link to it from a page in the parent directory.
The first test is to check it works normally before adding in the access control. Check that you can navigate to the file you created.
Assuming it is fine, then the next task is to try out the
access control based on <Directory
….> settings in the
httpd.conf file. Firstly, we will set up a user based access control with a
Add in the
following directive block. Notice that I have assumed that the user passwords
are in a file in a
users subdirectory, not part
of the webspace, i.e. alongside the
<Directory "N:/WebRoot/Roger4/htdocs/private"> AuthName "RogerPrivate" AuthType Basic AuthUserFile "N:/WebRoot/Roger4/users/users.pwd" require valid-user </Directory>
Having specified a password file, we need to create it. Note that the password file contains an encrypted password, but it is still a text file and may be opened with a text editor.
To do this use the
htpasswd utility included in the
C:\Apache\bin directory. As this directory is not on the path by default, you need to use its full
path in the command line, assuming that your current directory is set up as
–c argument on
htpasswd command instructs it to create a
new file; omit it to simply add a new name to an existing file. Repeating the command with the same user name
updates the password.
Notice that it uses the MD5 encryption method to add in user roger to the password file. Add one or more of your own users to test.
Now when you access a document in the
private directory, you are challenged (in a browser pop up window) to provide a username and password. (If you are not, trying refreshing the page.)
Having employed a user file, it is also possible to set up a file containing group definitions so that identification can be customised more easily. Groups are also a good way of implementing role-based access controls (RBAC).
The group file is a plain text file listing the members of each group, and would normally be located in the same directory as the user file, though it doesn't have to be. Note that the group file is only to make management easier; users are still validated via the user file. An example is given below. Be as creative as you like in setting out some groups for your users. Clearly in real life you would need to have designed the user groups with as much care as the directory structure – they often relate!
In my case I used the same extension as the password file, calling it groups.pwd.
staff: roger bill steve zoe annette students: clive janice xavia
The syntax is reasonably obvious! The next step is to add the group definition into the <Directory …> directive, and make use of it in the require clause. Note that you still need the password file as the users in the selected group still identify themselves via their password.
<Directory "N:/WebRoot/Roger4/htdocs/private"> AuthName "RogerPrivate" AuthType Basic AuthUserFile "N:/Apache/Roger/users/users.pwd" AuthGroupFile "N:/Apache/Roger/users/groups.pwd" require group staff </Directory>
Remember that all users mentioned in
your groups file should exist in your password file – else authorisation will
fail on the name. Whenever you make changes to the
httpd.conf file remember to restart the Apache webserver. Test your setup with a variety of
different logins, both staff and students. Remember to clear the caches and
restart the browser to clear the password. How would you check what was
happening? What logs would be worth looking at? Do you need to use a custom
log in place of the standard transfer log?
As an experiment it would be illuminating to try out switching
the AuthType to Digest. The modules needed to deal
with digest authentication are not included by default, so if you just change
the above part of the
httpd.conf file you
should get an “Internal Server Error” response. Including the relevant LoadModule and AddModule directives will cure this problem, but is
insufficient. You also need to add an extra
in place of the
htdigest in place of
htpasswd to construct the password
In order to test access control via a per directory user
managed htaccess file you need to first of all remove (or comment out) the
access control from
httpd.conf, viz. the <Directory
…> block, the AuthName
etc. These directives need to be in the
file instead. Create a plain text file called
and copy the body of the directory block to it (do not include the Directory directive). You can use
either the user or group version. Save this file to the private directory, or what ever you have called it
in your test structure.
If you test at this point it will totally ignore all of your
crafted access control, as Apache does not yet know that an
htaccess.hta file controls access, or that it
should let it. Open
httpd.conf in your
text editor and add the following lines. The
directive is necessary to permit the user to change the default site wide
behaviour on a per directory basis. In this case we want permission to
override the access control mechanism and substitute our more restrictive set
of rules. We could equally be relaxing the rules.
<Directory "N:/WebRoot/Roger4/htdocs/private"> AllowOverride Limit AuthConfig </Directory> AccessFileName htaccess.hta
Restart Apache, clear out the browser’s caches and try again. All should work as before, but with access control being directed by the htaccess.hta file. However, if you try and download the access control file itself, at present you can, clearly a security hole.
Any attempt would be logged (try it and check the logs!), but at present Apache would deliver the file.
You need a <Files
…> directive to block this particular file from transfer. Add the
following into the
httpd.conf file and
try again. What do the logs record? Could you modify the custom log to
catch the attempts?
#block access to the access control file in any directory! <Files "htaccess.hta"> Order allow,deny Deny from all </Files>
Having installed the deny clause, you should be prevented from viewing the potentially dangerous access control file. Every time a cracker gets detail of how your webserver is configured, then potential weaknesses are exposed.
This is one of the few parts of the course that cannot really be
undertaken without a real network – at least 2 machines - so you can have an external host to block
against. As the current state of the test
is set up for an access control file we will use that, but it works the same in
a Directory block.
Suppose that we wish to let users from a specific host have access to the private directory without the bother of a password, but for other users – perhaps working on un-trusted hosts outside the organisation, to have to identify themselves with a password.
Modify the htaccess.hta file to:
AuthName "RogerPrivate" AuthType Basic AuthUserFile "N:/WebRoot/Roger4/users/users.pwd" AuthGroupFile "N:/WebRoot/Roger4/users/groups.pwd" require group staff Order deny,allow Deny from all Allow from 192.168.27.55 #you would need to substitute a trusted colleague’s CommsLab IP Satisfy any
The Satisfy any lets users from 192.168.27.55 in without asking for a password, but demands a password from all other IP addresses, including its own. The alternative (and default) all is to only permit access if both host IP and password identification match.
Ben Laurie and Peter Laurie
Mark Arnold, Jeff Almeida & Clint Miller
Ben Laurie and Peter Laurie