 | Chapter 18 WWW Security |  |
| Chapter 18 WWW Security | |
Many sites are interested in limiting the scope of the information that they distribute with their Web servers. This may be because a Web server is used by an organization to distribute both internal data, such as employee handbooks or phone books, and external data, such as how to reach the organization's headquarters by mass transit. To provide for this requirement, many Web servers have a system for restricting access to Web documents.
Most servers support two primary techniques for controlling access to files and directories:
Restricting access to particular IP addresses, subnets, or DNS domains.
Restricting access to particular users. Users are authenticated through the use of a password that is stored on the server.
Servers that are equipped with the necessary software for public key cryptography (usually, servers that are purchased for commercial purposes) have a third technique for restricting access:
Restricting access to users who present public keys that are signed by an appropriate certification authority.
Each of these techniques has advantages and disadvantages. Restricting to IP address is relatively simple within an organization, although it leaves you open to attacks based on "IP spoofing." Using hostnames, instead of IP addresses, further opens your server to the risk of DNS spoofing. And usernames and passwords, unless you use a server and clients that support encryption, are sent in the clear over the network.
Of these three techniques, restricting access to people who present properly signed certificates is probably the most secure, provided that you trust your certification authority. (See below.)
The NCSA server allows you to place all of your global access restrictions in a single file called conf/access.conf. Alternatively, you can place the restrictions in each directory using the name specified by the AccessFileName in the configuration file conf/srm.conf. The per-directory default file name is .htaccess, but you can change this name if you wish.
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 that there are more files that you need to check to see whether the directories are protected or not. There is also a bug with some Web servers that allows the access file to be directly fetched (see the Note below). As a result, most Web professionals recommend against per-directory access control files.
The contents of the access.conf file looks like HTML. Accesses for each directory are bracketed with two tags, <Directory directoryname> and </Directory>. For example:
<Directory /nsa/manual> <Limit GET> order deny,allow deny from all allow from .nsa.mil </Limit> </Directory>
If you are using the per-directory access control, do not include the <Directory> and </Directory> tags. For example:
<Limit GET> order deny,allow deny from all allow from .nsa.mil </Limit>
NOTE: There is a bug in many Web servers (including the NCSA server) that allows the .htaccess file to be fetched as a URL. This is bad, because it lets an attacker learn the details of your authentication system. For this reason, if you do use per-directory access control files, give them a name other than .htaccess by specifying a different AccessFileName in the srm.conf file, as shown below:
# AccessFileName: The name of the file to look for in each directory # for access control information. AccessFileName .ap
As the above examples illustrate, a number of commands are allowed within the <Directory> blocks. The commands that are useful for restricting access[2] are:
[2] Other commands that can be inserted within a <Directory> block can be found in NCSA's online documentation at http://hoohoo.ncsa.uiuc.edu/docs/setup/access/Overview.html.
Use the Options command for turning on or off individual options within a particular directory. Options available are FollowSymLinks (follows symbolic links), SymLinksIfOwnerMatch (follows symbolic links if the owner of the link's target is the same as the owner of the link), ExecCGI (turns on execution of CGI scripts), Includes (turns on server-side includes), Index (allows the server to respond to requests to generate a file list for the directory), and IncludesNoExec (enables server-side includes, but disables CGI scripts in the includes.)
Specifies which directives can be overridden with directory-based access files.
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.
Specifies the type of authentication used by the server. When this book was written, NCSA's httpd only supported the Basic authentication system (usernames and passwords.)
Specifies the pathname of the httpd password file. This password file is created and maintained with the NCSA htpasswd program. This password file is not stored in the same format as /etc/passwd. The format is described in the section called "Setting up Web Users and Passwords" later in this chapter.
This specifies the pathname of the httpd group file. This group file is a regular text file. It 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 each member with a space. For example:
stooges: larry moe curley
Begins a section that lists the limitations on the directory. In Version 1.42, this command can only be used to limit the GET and POST directives. Within the Limit section, you may have the following directives:
Directive Usage | Meaning |
|---|---|
order ord | Specifies the order in which allow and deny statements should be checked. Specify "deny,allow" to check the deny entries 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 should be denied access. |
require user user1 user2 user3... require group group1 group2... require valid-user | Specifies that access should be granted to a specific user or group. If "valid-user" is specified, then any user that appears in the user file will be allowed. |
Hosts in the allow and deny statements may be any of the following:
A domain name, such as .vineyard.net.
A fully qualified host name, 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 the subnet.
The keyword "all," which matches all hosts.
For example, if you wish to restrict access to a directory's files to everyone on the subnet 204.17.195.*, 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 wanted to allow only the authenticated users beth and simson 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 /tmp/auth <Limit GET POST> order deny,allow deny from all allow from 204.17.195 require user simson beth </Limit>
Of course, the first three lines could as easily go in the server's access.conf file.
If you wish to allow the users beth and simson to access the files from anywhere on the Internet, provided that they type the correct username and password, try this:
AuthType Basic AuthName The-T-Directory AuthUserFile /tmp/auth <Limit GET POST> require user simson beth </Limit>
To use authenticated users, you will 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 simsong Adding password for simsong. New password:foo1234 Re-type new password:foo1234 #
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 beth Adding password for beth. New password:luvsim Re-type new password:luvsim #
The password file is similar, but not identical, to the standard /etc/passwd file:
# cat /usr/local/etc/httpd/pw/auth simsong:ZdZ2f8MOeVcNY beth: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 such as Crack.
|  | |
| 18.2 Running a Secure Server |  | 18.4 Avoiding the Risks of Eavesdropping |