Setting Permissions in Apache

In this third part of a six-part series on Apache installation and configuration, you will learn how to set security-related permissions. This article is excerpted from chapter two of Apache Security, written by Ivan Ristic (O’Reilly; ISBN: 0596007248). Copyright © 2006 O’Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O’Reilly Media.

Setting Apache Binary File Permissions 

After creating the new user account your first impulse might be to assign ownership over the Apache installation to it. I see that often, but do not do it. For Apache to run on port 80, it must be started by the user root. Allowing any other account to have write access to the httpd binary would give that account privileges to execute anything as root.

This problem would occur, for example, if an attacker broke into the system. Work ing as the Apache user (httpd), he would be able to replace the httpd binary with something else and shut the web server down. The administrator, thinking the web server had crashed, would log in and attempt to start it again and would have fallen into the trap of executing a Trojan program.

That is why we make sure only root has write access:

  # chown -R root:root /usr/local/apache
  # find /usr/local/apache -type d | xargs chmod 755
  # find /usr/local/apache -type f | xargs chmod 644

No reason exists why anyone else other than the root user should be able to read the Apache configuration or the logs:

  # chmod -R go-r   /usr/local/apache/conf
  # chmod -R go-r  /usr/local/apache/logs

Configuring Secure Defaults

Unless told otherwise, Apache will serve any file it can access. This is probably not what most people want; a configuration error could accidentally expose vital system files to anyone caring to look. To change this, we would deny access to the complete filesystem and then allow access to the document root only by placing the following directives in the httpd.conf configuration file:

  <Directory />
      Order Deny,Allow
      Deny from all
  <Directory /var/www/htdocs>
      Order Allow,Deny
      Allow from all

{mospagebreak title=Options directive}

This sort of protection will not help with incorrectly or maliciously placed symbolic links that point outside the /var/www/htdocs web server root. System users could create symbolic links to resources they do not own. If someone creates such a link and the web server can read the resource, it will accept a request to serve the resource to the public. Symbolic link usage and other file access restrictions are controlled with the Options directive (inside a <Directory> directive). The Options directive can have one or more of the following values:

All options listed below except MultiViews . This is the default setting.

None of the options will be enabled.

Allows execution of CGI scripts.

Allows symbolic links to be followed.

Allows server-side includes.

   Allows SSIs but not the exec command, which is used
   to execute external scripts. (This setting does not
   affect CGI script execution.)

Allows the server to generate the list of files in a
      directory when a default index file is absent.

Allows content negotiation.

   Allows symbolic links to be followed if the owner of
   the link is the same as the owner of the file it points

The following configuration directive will disable symbolic link usage in Apache:

  Options -FollowSymLinks

The minus sign before the option name instructs Apache to keep the existing configuration and disable the listed option. The plus character is used to add an option to an existing configuration.

The Apache syntax for adding and removing options can be confusing. If all option names in a given Options statement for a particular directory are preceded with a plus or minus character, then the new configuration will be merged with the existing configuration, with the new configuration overriding the old values. In all other cases, the old values will be ignored, and only the new values will be used.

If you need symbolic links consider using the Alias directive, which tells Apache to incorporate an external folder into the web server tree. It serves the same purpose but is more secure. For example, it is used in the default configuration to allow access to the Apache manual:

  Alias /manual/ /usr/local/apache/manual/

If you want to keep symbolic links, it is advisable to turn ownership verification on by setting the SymLinksIfOwnerMatch option. After this change, Apache will follow symbolic links if the target and the destination belong to the same user:

  Options -FollowSymLinks +SymLinksIfOwnerMatch

Other features you do not want to allow include the ability to have scripts and server-side includes executed anywhere in the web server tree. Scripts should always be placed in special folders, where they can be monitored and controlled.

  Options -Includes -ExecCGI

If you do not intend to use content negotiation (to have Apache choose a file to serve based on the client’s language preference), you can (and should) turn all of these features off in one go:

  Options None

Modules sometimes use the settings determined with the Options directive to allow or deny access to their features. For example, to be able to use mod_rewrite in per-directory configuration files, the FollowSymLinks option must be turned on.

{mospagebreak title=AllowOverride directive}

In addition to serving any file it can access by default, Apache also by default allows parts of configuration data to be placed under the web server tree, in files normally named .htaccess. Configuration information in such files can override the information in the httpd.conf configuration file. Though this can be useful, it slows down the server (because Apache is forced to check whether the file exists in any of the sub-folders it serves) and allows anyone who controls the web server tree to have limited control of the web server. This feature is controlled with the AllowOverride directive, which, like Options, appears within the <Directory> directive specifying the directory to which the options apply. The AllowOverride directive supports the following options:

Allows use (in .htaccess files) of the authorization
      directives (explained in Chapter 7)

Allows use of the directives controlling document

Allows use of the directives controlling directory

Allows use of the directives controlling host access

Allows use of the directives controlling specific
      directory functions (the Options and XbitHack

Allows all options listed

Ignores .htaccess configuration files

For our default configuration, we choose the None option. So, our <Directory> directives are now:

  <Directory / >
      Order Deny,Allow
      Deny from all
      Options None
      AllowOverride None

  <Directory /var/www/htdocs>
      Order Allow,Deny
      Allow from all

Modules sometimes use AllowOverride settings to make other deci sions as to whether something should be allowed. Therefore, a change to a setting can have unexpected consequences. As an example, including Options as one of the AllowOverride options will allow PHP configuration directives to be used in .htaccess files. In theory, every directive of every module should fit into one of the AllowOverride settings, but in practice it depends on whether their respective developers have considered it.

{mospagebreak title=Enabling CGI Scripts}

Only enable CGI scripts when you need them. When you do, a good practice is to have all scripts grouped in a single folder (typically named cgi-bin). That way you will know what is executed on the server. The alternative solution is to enable script execution across the web server tree, but then it is impossible to control script execution; a developer may install a script you may not know about. To allow execution of scripts in the /var/www/cgi-bin directory, include the following <Directory> directive in the configuration file:

  <Directory /var/www/cgi-bin >
      Options ExecCGI
      SetHandler cgi-script

An alternative is to use the ScriptAlias directive, which has a similar effect:

  ScriptAlias /cgi-bin/ /var/www/cgi-bin/

There is a subtle but important difference between these two approaches. In the first approach, you are setting the configuration for a directory directly. In the second, a virtual directory is created and configured, and the original directory is still left with out a configuration. In the examples above, there is no difference because the names of the two directories are the same, and the virtual directory effectively hides the real one. But if the name of the virtual directory is different (e.g., my-cgi-bin/), the real directory will remain visible under its own name and you would end up with one web site directory where files are treated like scripts (my-cgi-bin/) and with one where files are treated as files (cgi-bin/). Someone could download the source code of all scripts from the latter. Using the <Directory> directive approach is recommended when the directory with scripts is under the web server tree. In other cases, you may use ScriptAlias safely.


Having a record of web server activity is of utmost importance. Logs tell you which content is popular and whether your server is underutilized, overutilized, misconfigured, or misused. This subject is so important that a complete chapter is dedicated to it. Here I will only bring your attention to two details: explaining how to configure logging and how not to lose valuable information. It is not important to understand all of the meaning of logging directives at this point. When you are ready, proceed to Chapter 8 for a full coverage.

Two types of logs exist. The access log is a record of all requests sent to a particular web server or web site. To create an access log, you need two steps. First, use the LogFormat directive to define a logging format. Then, use the CustomLog directive to create an access log in that format:

  LogFormat "%h %l %u %t "%r" %>s %b  "%{Referer}i"  "%{User-Agent}i"" combined
  CustomLog /var/www/logs/access_log combined

The error log contains a record of all system events (such as web server startup and shutdown) and a record of errors that occurred during request processing. For example, a request for a resource that does not exist generates an HTTP 404 response for the client, one entry in the access log, and one entry in the error log. Two directives are required to set up the error log, just as for the access log. The following LogLevel directive increases the logging detail from a default value of notice to info . The ErrorLog directive creates the actual log file:

  LogLevel inf o
  ErrorLog /var/www/logs/error_log

Please check back next week for the continuation of this article.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye