• Choose a category
• All
• Classic-Fiction

By Root 2035 0

is to include other files from the main httpd.conf file using the Include directive. This is terribly insecure! You have no control over what is written in the included file, so whoever holds write access to that file holds control over Apache.

* * *

Access file usage is controlled with the AllowOverride directive. I discussed this directive in Chapter 2, where I recommended a None setting by default:

AllowOverride None

This setting tells Apache not to look for .htaccess files and gives maximum performance and maximum security. To give someone maximum control over a configuration in a particular folder, you can use:

AllowOverride All

* * *

Warning

Configuration errors in access files will not be detected when Apache starts. Instead, they will result in the server responding with status code 500 (Internal Server Error) and placing a log message in the error log.

* * *

Situations when you will give maximum control over a configuration are rare. More often than not you will want to give users limited privileges. In the following example, user ivanr is only allowed to use access control configuration directives:

AllowOverride AuthConfig Limit

You must understand what you are giving your users. In addition to None and All, there are five groups of AllowOverride options (AuthConfig, FileInfo, Indexes, Limit, and Options). Giving away control for each of these five groups gives away some of the overall Apache security. Usage of AllowOverride Options is an obvious danger, giving users the power to enable Apache to follow symbolic links (potentially exposing any file on the server) and to place executable content wherever they please. Some AllowOverride and Options directive options (also discussed in Chapter 2), used with other Apache modules, can also lead to unforeseen possibilities:

If FollowSymLinks (an Options directive option) is allowed, a user can create a symbolic link to any other file on the server (e.g., /etc/passwd). Using SymLinksIfOwnerMatch is better.

The mod_rewrite module can be used to achieve the same effect as a symbolic link. Interestingly, that is why mod_rewrite requires FollowSymLinks to work in the .htaccess context.

If PHP is running as a web server user, the PHP auto_prepend option can be used to make it fetch any file on the server.

If AllowOverride FileInfo is specified, users can execute a file through any module (and filter in Apache 2) available. For example, if you have the server configured to execute PHP through suEXEC, users can reroute requests through a running PHP module instead.

More dangerously, AllowOverride FileInfo allows the use of the SetHandler directive, and that can be exploited to map the output of special-purpose modules (such as mod_status or mod_info) into users' web spaces.

It is possible to use mod_security (described in Chapter 12) to prevent users who can assign handlers from using certain sensitive handlers. The following two rules will detect an attempt to use the special handlers and will only allow the request if it is sent to a particular domain name:

SecFilterSelective HANDLER ^(server-status|server-info)$ chain

SecFilterSelective SERVER_NAME !^www\.apachesecurity\.net$ deny,log,status:404

Securing Dynamic Requests

Securing dynamic requests is a problem facing most Apache administrators. In this section, I discuss how to enable CGI and PHP scripts and make them run securely and with acceptable performance.

Enabling Script Execution

Because of the inherent danger executable files introduce, execution should always be disabled by default (as discussed in Chapter 2). Enable execution in a controlled manner and only where necessary. Execution can be enabled using one of four main methods:

Using the ScriptAlias directive

Explicitly by configuration

Through server-side includes

By assigning a handler, type, or filter

ScriptAlias versus script enabling by configuration