20.2 Controlling Access with Apache

only for RuBoard - do not distribute or recompile

One of the most common ways to restrict access to web-based information is to protect it using usernames and passwords. Although different servers support many different ways of password-protecting web information, one of the most common techniques is with the <Limit> server configuration directive present in the Apache web server.

Using <Limit>, you can control which files on your web server can be accessed and by whom. The Apache server gives you two locations where you can place your access control information:

You can place the restrictions for any given directory (and all of its subdirectories) in a special file located in that directory. Traditionally the name of this file is .htaccess, although you can change the name in the server's configuration file.
Alternatively, you can place all of the access control restrictions in a single configuration file. The Apache server allows you to place access control information in the server's single httpd.conf file.

Whether you choose to use many access files or a single file is up to you. It is certainly more convenient to have a file in each directory. It also makes it easier to move directories within your web server, as you do not need to update the master access control file. Furthermore, you do not need to restart your server whenever you make a change to the access control list the server will notice that there is a new .htaccess file and behave appropriately.

On the other hand, having an access file in each directory means there are more files that you need to check to see whether the directories are protected. There is also the possibility that an attacker will be able to convince your web server (or another server running on the same computer) to fetch this file directly. Although the attacker's possession of the .htaccess file doesn't ruin your system's security, it gives an attacker additional information that might be used to find other holes.

20.2.1 Enforcing Access Control Restrictions with the .htaccess File

Here is a simple file that restricts access to registered users whose usernames appear in the file /ws/adm/users:

% cat .htaccess AuthType Basic AuthName Web Solutions AuthUserFile /ws/adm/users  <Limit GET POST> require valid-user </Limit>  %

The .htaccess file consists of two parts. At the beginning of the file is a set of commands that allow you to specify the authorization parameters for the given directory. The second half of the file contains a <Limit . . .> . . . </Limit> block containing security parameters that are enforced for the HTTP GET and POST commands.

The .htaccess file needs to be placed in the directory on the web server that you wish to protect. For example, if your web server is named www.ex.com and has a document root of /usr/local/etc/httpd/htdocs, naming this file in the directory /usr/local/etc/httpd/htdocs/internal/.htaccess would restrict all information prefixed by the URL http://www.ex.com/internal/ so that it could only be accessed by authorized users.

20.2.2 Enforcing Access Control Restrictions with the Web Server's Configuration File

The access restrictions described in the .htaccess file can also be placed in the configuration file of the Apache web server. In this case, the commands would be enclosed within a pair of <Directory directoryname > and </Directory> tags. The directoryname parameter should be the directory's full pathname and not the directory within the web server's document root or the directory name as referenced by a symbolic link. For example:

... <Directory /usr/local/etc/httpd/htdocs/internal> AuthType Basic AuthName Web Solutions AuthUserFile /ws/adm/users  <Limit GET POST> require valid-user </Limit>  </Directory> ...

The format of the user account files (/ws/adm/users in this example) is similar to the Unix password file, but only contains usernames and encrypted passwords. It is described in detail later in this chapter in Section 20.2.5.

20.2.3 Commands Before the <Limit>. . . </Limit> Directive

The following commands can be placed before the <Limit>. . .</Limit> block of most web servers:

AllowOverride what

Specifies which directives can be overridden with directory-based access files. This command is only used for access information placed in system-wide configuration files such as conf/access.conf or conf/httpd.conf.

AuthName name

Sets the name of the Authorization Realm for the directory. The name of the realm is displayed by the web browser when it asks for a username and password. It is also used by the web browser to cache usernames and passwords.

AuthRealm realm

Sets the name of the Authorization Realm for the directory; this command is used instead of AuthName by older web servers.

AuthType type

Specifies the type of authentication used by the server. Most web servers only support "basic," which is standard usernames and passwords.

AuthUserFile absolute_pathname

Specifies the pathname of the httpd password file. This password file is created and maintained with a special password program; in the case of the Apache web server, use the htpasswd program. Note that the web server's password file is not stored in the same format as /etc/passwd. The format is described in Section 20.2.6 later in this chapter.

AuthGroupFile absolute_pathname

Specifies the pathname of the httpd group file. This group file is a regular text file. Note that this file is not in the format of the Unix /etc/group file. Instead, each line begins with a group name and a colon and then lists the members, separating the member names with spaces. For example:

stooges: larry moe curley staff: sascha wendy ian

Limit methods to limit

Begins a section that lists the limitations on the directory. For more information on the Limit section, see the next section of this chapter.

Options opt1 opt2 opt3 . . .

Turns on or off individual options within a particular directory. Options available are listed in the following table.

Option	Meaning
`ExecCGI`	Allows CGI scripts to be executed within this directory.
`FollowSymLinks`	Allows the web server to follow symbolic links within this directory.
`Includes`	Allows server-side include files.
`Indexes`	Allows automatic indexing of the directory if an index file (such as index.html ) is not present.
`IncludesNoExec`	Allows server-side includes, but disables CGI scripts in the includes.
`SymLinksIfOwnerMatch`	Allows symbolic links to be followed only if the target of the file or the directory containing the target file matches the owner of the link.
`All`	Turns on all options.
`None`	Turns off all options.

20.2.4 Commands Within the <Limit>. . . </Limit> Block

The <Limit> directive is the heart of the Apache access control system. It is used to specify the actual hosts and/or the users that are to be allowed or to be denied access to the directory.

The format of the <Limit> directive is straightforward:

<Limit HTTP commands> directives </Limit>

Normally, you will want to limit both GET and POST commands.

The following directives may be present within a <Limit> block:

order options: Specifies the order in which allow and deny statements are evaluated. Specify "order deny,allow" to cause the deny entries to be evaluated first; servers that match both the "deny" and "allow" lists are allowed.

Specify "allow,deny" to check the allow entries first; servers that match both are denied.

Specify "mutual-failure" to cause hosts on the allow list to be allowed, those on the deny list to be denied, and all others to be denied.

allow from host1 host2 ...: Specifies hosts that are allowed access.
deny from host1 host2 ...: Specifies hosts that are denied access.
require user user1 user2 user: Only the specified users "user1, user2, and user3 . . ." are granted access.
require group group1 group2 ...: Any user who is in one of the specified groups may be granted access.
require valid-user: Any user that is listed in the AuthUserFile will be granted access.

Hosts in the allow and deny statements may be any of the following:

A domain name, such as .vineyard.net (note the leading "." character)
A fully qualified hostname such as nc.vineyard.net
An IP address such as 204.17.195.100
A partial IP address such as 204.17.195, which matches any host on that subnet
The keyword "all", which matches all hosts

20.2.5 <Limit> Examples

If you wish to restrict access to a directory's files to everyone on the 204.17.195 subnet, you could add the following lines to your access.conf file:

<Directory /usr/local/etc/httpd/htdocs/special> <Limit GET POST> order deny,allow deny from all allow from 204.17.195 </Limit> </Directory>

If you then wish to allow only the authenticated users wendy and sascha to access the files, and only when they are on subnet 204.17.195, you could add these lines:

AuthType Basic AuthName The-T-Directory AuthUserFile /etc/web/auth <Limit GET POST> order deny,allow deny from all allow from 204.17.195 require user sascha wendy </Limit>

If you wish to allow the users wendy and sascha to access the files from anywhere on the Internet, provided they type the correct username and password, try this:

AuthType Basic AuthName The-T-Directory AuthUserFile /etc/web/auth <Limit GET POST> require user sascha wendy </Limit>

If you wish to allow any registered user to access files on your system in a given directory, place this .htaccess file in that directory:

AuthType Basic AuthName The-T-Group AuthUserFile /etc/web/auth <Limit GET POST> require valid-user </Limit>

After modifying your .htaccess file, test it by attempting to access the information in the protected directory with both a valid account and an invalid account.

20.2.6 Manually Setting Up Web Users and Passwords

To use authenticated users, you need to create a password file. You can do this with the htpasswd program, using the "-c" option to create the file. For example:

# ./htpasswd -c /usr/local/etc/httpd/pw/auth sascha Adding password for sascha. New password:deus333 Re-type new password:deus333 #

You can add additional users and passwords with the htpasswd program. When you add additional users, do not use the "-c" option, or you will erase all of the users who are currently in the file:

# ./htpasswd /usr/local/etc/httpd/pw/auth wendy Adding password for wendy. New password:excom22 Re-type new password:excom22 #

The password file is similar, but not identical, to the standard /etc/passwd file:

# cat /usr/local/etc/httpd/pw/auth sascha:ZdZ2f8MOeVcNY wendy:ukJTIFYWHKwtA #

Because the web server uses crypt -style passwords, it is important that the password file be inaccessible to normal users on the server (and to users over the Web) to prevent an ambitious attacker from trying to guess passwords using a program like Crack.

20.2.7 Advanced User Management

If you need to manage more than a few users, you will want to implement a more sophisticated user management system.

20.2.7.1 Use a database

Instead of storing users, passwords, and groups in a single file, you can store them in a database such as MySQL. The Apache web server can then be programmed to refer to this database to determine whether users are valid. The user authentication database can be on the same computer as the web server, or it can be located on a central database server.

20.2.7.2 Use RADIUS or LDAP

RADIUS is a remote authentication protocol originally developed by Livingston and now used widely throughout the Internet industry. Radius provides for centralized username/password management. To use Radius, your web server is configured to validate username/password authentication requests with a remote RADIUS server.

LDAP is a general-purpose directory system that is increasingly being used for remote authentication. As with RADIUS, if you configure your web server to use LDAP for authentication, username/password pairs are sent to the remote LDAP server for validation. LDAP offers considerably more flexibility than RADIUS, such as the ability to manage groups and more easily handle authentication tokens. However, unlike RADIUS, LDAP sends usernames and passwords without encryption. If you wish to use an LDAP server, you need to protect usernames and passwords that are sent by either having them sent on a segregated network or having the transmissions encrypted by using LDAP over SSL.

20.2.7.3 Use PKI and digital certificates

Instead of using a username and password to authenticate a user, you can use a digital certificate that is stored on the user's hard disk.

To make use of digital certificates, a web site user must first create a public key and a secret key. The public key is then signed by a certification authority, which returns to the user a certificate that consists of the user's public key, a distinguished name (DN), and the certification authority's signature. You then configure your web server so that it will allow access to any user who has a valid certificate.

The advantage of using PKI and digital certificates is that you do not need to distribute valid user accounts to the web server you only need to distribute the public key for the certification authority and a list of revoked certificates. This isn't a great advantage when you are running a single web server, but it can be tremendously advantageous when you are running hundreds or thousands of web servers.

For further information on digital certificates, see Chapter 21.

only for RuBoard - do not distribute or recompile