7.3. Access Rights

In this section, I will introduce to you the main parameters of the /etc/httpd/conf/ httpd.conf configuration file. These parameters specify access rights to directories and have the following format:

 <Directory /var/www/html>           Order allow, deny           Allow from all       </Directory>

They can also look similar to the following:

 <Location /server-status>    SetHandler server-status    Order deny, allow    Deny from all    Allow from .your-domain.com </Location>

The first block of code sets permissions for a certain directory on the disk (in this case, the /var/www/html directory); the second block of code limits permissions for a virtual directory (in this example, the / servername /server-status directory). If you are familiar with HTML, you should already understand the preceding declarations. For those who do not have this knowledge, I will provide a few explanations for the directory example. The declaration code starts with the following line:

 <Directory Path>

In the angle brackets, the keyword Directory is specified, followed by the path to the directory, for which the permissions have to be set. Afterward, commands defining the permissions follow. The block ends with the line:

 </Directory>

The permissions for a directory can be described not only in the /etc/httpd/conf/httpd.conf file but also in the .htaccess file located in the specified directory. The file itself is considered in detail in Section 7.5.1 ; for now, it will suffice for you to know that the permissions specified in the Web server configuration can be redefined.

The permissions are specified using the following directives:

Allow from parameter Indicates, from which hosts the specified directories can be accessed. The parameter value can be one of the following:
- all Indicates that access is allowed to all hosts.
- domain name Specifies the domain name, from which the directory can be accessed. For example, specifying domain.com will allow only users of this domain to access the directory from the Web. If you want to protect some files, you can limit access to the folder containing them to your domain or only to the local machine like this: allow from localhost.
- IP-address Restricts access to the directory to the specified IP address. This is handy if your computer has a static address and you want to restrict access to the directory containing administrating scripts only to yourself. The restriction can be to a single computer or to a network, in which case only the network part of the address is specified.
- env = VariableName If the specified environmental variable is defined, access is allowed. The full format of the directive is the following: allow from env = VariableName.
Deny from parameter Denies access to the specified directory. The parameters are the same as those for the allow from directive, only in this case access is denied from the specified addresses, domains, and so on.
Order parameter The order, in which the allow and deny directives are applied. The following three combinations are possible:
- Order deny, allow Initially, access is allowed to all; then prohibitions are applied, followed by permissions. It is advisable to use this combination for shared directories, to which users can upload files.
- Order allow, deny Initially, access is denied to all; then permissions are applied, followed by prohibitions. It is advisable to use this combination for all directories containing scripts.
- Order mutual-failure Initially, access is denied to all but those listed in the allow from and not in the deny from directive. I recommend using this combination for all directories storing files used by a certain group of users, for example, administration scripts.
Require parameter Specifies users who are allowed access to the directory. The parameter value can be one of the following:
- user The name of users (or their IDs) allowed access to the directory. For example, Require user robert FlenovM.
- group The names of groups whose users are allowed access to the directory. The directive works the same as the user directive.
- valid-user Access to the directory is allowed to any user that has been authenticated.
Satisfy parameter If set to any , access is restricted by using either a login/password procedure or an IP address. To identify users using both procedures, the value should be set to all.
AllowOverwrite parameter Specifies, which directives from the .htaccess files in the specified directory can overwrite the server configuration. The parameter value can be one of the following: None, All, AuthConfig, FileInfo, Indexes, Limit, or Options.
AuthName The authorization domain to be used by the client for verifying the user name and password.
Options [+ -] parameter Indicates the Web server features available in the specified directory. If you have a directory on your server, into which the users are allowed to upload files, for example, images, it would be logical to disallow execution of any scripts in this directory. Do not rely on being able to prohibit programmatically the uploading of files of types other than images. Hackers will always find a way to upload malicious code to your system and execute it. But you can use the options to disable the Web server from executing scripts.

The keyword option is followed by a plus or minus sign, which corresponds to the option being enabled or disabled, respectively. The parameter value can be one of the following:
- All Permits all except Multiview. The Option + All directive allows execution of any other scripts.
- ExecCGI Allows execution of CGI scripts. Most often a separate directory, /cgi-bin, is used for CGI scripts, but even in this directory, execution can be disallowed for individual subdirectories.
- FollowSymLinks Allows symbolic links. Make sure that the directory does not contain dangerous links and that the links in it do not have excessive rights. It was already mentioned in Section 3.1.3 that links are inherently dangerous; therefore, they should be handled with care wherever they are found.
- SymLinksIfOwnerMatch Follow symbolic links only if the owners of the target file and the link match. When symbolic links are used, it is better to specify this parameter instead of FollowSymLinks in the given directory. If a hacker creates a link to the /etc directory and follows it from the Web browser, this will create serious security problems.
- Includes Use Server Side Include (SSI).
- IncludesNOEXEC Use all SSI except exec and include. If you do not use these commands in CGI scripts, it is better to use this option than the previous one.
- Indexes Display the contents of the directory if there is no default file. Users mostly enter Internet addresses in the reduced format, for example, www.cydsoft.com . Here, the file to load is not specified. The full URL is the following: www.cydsoft.com/index.htm . When the reduced format is used, the server opens the default file. This may be index.htm, index.html, index.asp, index.php, default.htm, and the like. When the server does not find any such files at the specified path, if the Indexes option is enabled, the directory tree will be displayed; otherwise , the error page will be opened. I recommend disabling this option, because too much information is revealed about the structure of the directory and its contents, which can be misused by nefarious individuals.
- Multiviews The view depends on the client's preferences.

All of the directives just described can be used not only in the /etc/httpd/conf/ httpd.conf file but also in the .htaccess files, which can be placed in individual directories and define the permissions for their corresponding directories.

Access rights can be defined not only for directories but also for individual files. The files access rights are defined between the following two entries:

 <Files FileName> </Files>

This declaration is, in turn , placed inside the directory access rights definition, for example, as follows:

 <Directory /var/www/html>          Order allow, deny          Allow from all          <Files "/var/www/html/admin.php">             Deny from all          </Files>       </Directory>

The directives for files are the same as for directories. In the preceding example, all users are allowed access to the /var/www/html directory; nobody, however, can access the /var/www/html/admin.php file in this directory.

In addition to limiting access rights to directories and files, HTTP methods (GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK) can be limited. How can this be useful? Suppose that your Web page contains a script, to which the parameters are sent by users. This can be done using either POST or GET. If you know that the programmer uses only the GET method, you can prohibit the other method so as not to let hackers take advantage of a potential vulnerability in the script by replacing the method.

Also, sometimes only selected users can send data to the server. For example, everyone can execute scripts in a specified directory, but only administrators can load information to the server. This problem is easily solved by separating the rights to use the HTTP methods.

The rights to use the methods are described as follows:

 <limit MethodName> Rights </limit>

As you can see, the process is similar to defining file and directory access rights. Even the same access-rights terms are used, which are placed within the <Directory> or <Location> definition blocks and affect only the specified directory.

For example, the following definition block can be used to prohibit any data transfers to the server's /home directory:

 <Directory /home>   <Limit GET POST>     Deny from all   </Limit> </Directory>

Within the rights definition block for the /home directory, the GET and POST methods are limited.

Your task as the administrator is to configure the access parameters for directories and files so that they are minimally sufficient. Users should not be allowed to take any step without your permission. For this, you should base your actions on the "Everything not permitted is prohibited " principle.

Always, first prohibit everything that you can and only then start gradually setting permissions so that all scripts will operate properly. It is better to specify an extra explicit prohibition than to let a permission slip through that can be used by hackers to destroy your server.