1276N/A<!
DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 1276N/A <
title>Apache HTTP Server: Security Tips</
title>
1276N/A <!-- Background white, links blue (unvisited), navy (visited), red (active) --> 1276N/A <
body bgcolor="#FFFFFF" text="#000000" link="#0000FF" 1276N/A vlink="#000080" alink="#FF0000">
1276N/A <
h1 align="center">Security Tips for Server Configuration</
h1>
1276N/A <
li><
a href="#serverroot">Permissions on ServerRoot
1276N/A <
li><
a href="#ssi">Server Side Includes</
a></
li>
1276N/A <
li><
a href="#cgi">CGI in General</
a></
li>
1276N/A <
li><
a href="#nsaliasedcgi">Non Script Aliased CGI</
a></
li>
1276N/A <
li><
a href="#saliasedcgi">Script Aliased CGI</
a></
li>
1276N/A <
li><
a href="#systemsettings">Protecting System
1276N/A <
li><
a href="#protectserverfiles">Protect Server Files by
1276N/A <
li><
a href="#watchyourlogs">Watching Your Logs</
a></
li>
1276N/A <
p>Some hints and tips on security issues in setting up a web
1276N/A server. Some of the suggestions will be general, others
1276N/A <
h2><
a id="serverroot" name="serverroot">Permissions on
1276N/A ServerRoot Directories</
a></
h2>
1276N/A <
p>In typical operation, Apache is started by the root user,
1276N/A and it switches to the user defined by the <
a 1276N/A directive to serve hits. As is the case with any command that
1276N/A root executes, you must take care that it is protected from
1276N/A modification by non-root users. Not only must the files
1276N/A themselves be writeable only by root, but so must the
1276N/A directories, and parents of all directories. For example, if
1276N/A you choose to place ServerRoot in <
code>
1276N/A that directory as root, with commands like these:</
p>
1276N/A by root. When you install the httpd executable, you should
1276N/A ensure that it is similarly protected:
1276N/A <
p>You can create an htdocs subdirectory which is modifiable by
1276N/A other users -- since root never executes any files out of
1276N/A there, and shouldn't be creating files in there.</
p>
1276N/A <
p>If you allow non-root users to modify any files that root
1276N/A either executes or writes on then you open your system to root
1276N/A compromises. For example, someone could replace the httpd
1276N/A binary so that the next time you start it, it will execute some
1276N/A arbitrary code. If the logs directory is writeable (by a
1276N/A non-root user), someone could replace a log file with a symlink
1276N/A to some other system file, and then root might overwrite that
1276N/A file with arbitrary data. If the log files themselves are
1276N/A writeable (by a non-root user), then someone may be able to
1276N/A overwrite the log itself with bogus data.</
p>
1276N/A <
h2><
a id="ssi" name="ssi">Server Side Includes</
a></
h2>
1276N/A <
p>Server Side Includes (SSI) present a server administrator with
1276N/A several potential security risks.</
p>
1276N/A The first risk is the increased load on the server. All SSI-enabled
1276N/A files have to be parsed by Apache, whether or not there are any SSI
1276N/A directives included within the files. While this load increase is
1276N/A minor, in a shared server environment it can become significant.</
p>
1276N/A SSI files also pose the same risks that are associated with CGI
1276N/A scripts in general. Using the "exec cmd" element, SSI-enabled
1276N/A files can execute any CGI script or program under the permissions
1276N/A That should definitely give server administrators pause.</
p>
1276N/A There are ways to enhance the security of SSI files while still taking
1276N/A advantage of the benefits they provide.</
p>
1276N/A <
p>To isolate the damage a wayward SSI file can cause, a server
1276N/A >suexec</
a> as described in the <
a href="#cgi">CGI in General</
a>
1276N/A Enabling SSI for files with .html or .htm extensions can be
1276N/A dangerous. This is especially true in a shared, or high traffic,
1276N/A server environment. SSI-enabled files should have a separate
1276N/A extension, such as the conventional .shtml. This helps keep
1276N/A server load at a minimum and allows for easier management of
1276N/A <
p>Another solution is to disable the ability to run scripts and
1276N/A programs from SSI pages. To do this replace <
code>Includes</
code>
1276N/A with <
code>IncludesNOEXEC</
code> in the <
a 1276N/A users may still use <--#include virtual="..." --> to execute
1276N/A CGI scripts if these scripts are in directories desginated by a <
a 1276N/A <
h2><
a id="cgi" name="cgi">CGI in General</
a></
h2>
1276N/A <
p>First of all, you always have to remember that you must trust
1276N/A potential security holes in CGI, whether they were deliberate or
1276N/A accidental. CGI scripts can run essentially arbitrary commands
1276N/A on your system with the permissions of the web server user and can
1276N/A therefore be extremely dangerous if they are not carefully
1276N/A <
p>All the CGI scripts will run as the same user, so they have
1276N/A potential to conflict (accidentally or deliberately) with other
1276N/A scripts <
em>
e.g.</
em> User A hates User B, so he writes a
1276N/A script to trash User B's CGI database. One program which can be
1276N/A used to allow scripts to run as different users is <
a 1276N/A as of 1.2 and is called from special hooks in the Apache server
1276N/A code. Another popular way of doing this is with <
a 1276N/A <
h2><
a id="nsaliasedcgi" name="nsaliasedcgi">Non Script Aliased
1276N/A <
p>Allowing users to execute <
strong>CGI</
strong> scripts in
1276N/A any directory should only be considered if;</
p>
1276N/A <
li>You trust your users not to write scripts which will
1276N/A deliberately or accidentally expose your system to an
1276N/A <
li>You consider security at your site to be so feeble in
1276N/A other areas, as to make one more potential hole
1276N/A <
li>You have no users, and nobody ever visits your
1276N/A <
h2><
a id="saliasedcgi" name="saliasedcgi">Script Aliased
1276N/A <
p>Limiting <
strong>CGI</
strong> to special directories gives
1276N/A the admin control over what goes into those directories. This
1276N/A is inevitably more secure than non script aliased CGI, but
1276N/A <
strong>only if users with write access to the directories are
1276N/A trusted</
strong> or the admin is willing to test each new CGI
1276N/A <
p>Most sites choose this option over the non script aliased
1276N/A <
h2><
a id="systemsettings" name="systemsettings">Protecting
1276N/A <
p>To run a really tight ship, you'll want to stop users from
1276N/A setting up <
code>.htaccess</
code> files which can override
1276N/A security features you've configured. Here's one way to do
1276N/A <
p>In the server configuration file, put</
p>
1276N/A <
code><Directory /><
br />
1276N/A <
p>This prevents the use of <
code>.htaccess</
code> files in all
1276N/A directories apart from those specifically enabled.</
p>
1276N/A <
h2><
a id="protectserverfiles" name="protectserverfiles">
1276N/A Protect Server Files by Default</
a></
h2>
1276N/A <
p>One aspect of Apache which is occasionally misunderstood is
1276N/A the feature of default access. That is, unless you take steps
1276N/A to change it, if the server can find its way to a file through
1276N/A normal URL mapping rules, it can serve it to clients.</
p>
1276N/A <
p>For instance, consider the following example:</
p>
1276N/A <
li><
samp># cd /; ln -s / public_html</
samp></
li>
1276N/A <
p>This would allow clients to walk through the entire
1276N/A filesystem. To work around this, add the following block to
1276N/A your server's configuration:</
p>
1276N/A <
p>This will forbid default access to filesystem locations. Add
1276N/A <Directory></
samp></
a> blocks to allow access only in
1276N/A those areas you wish. For example,</
p>
1276N/A <
p>Pay particular attention to the interactions of <
a 1276N/A <Location></
samp></
a> and <
a 1276N/A <Directory></
samp></
a> directives; for instance, even if
1276N/A <
samp><Directory /></
samp> denies access, a <
samp>
1276N/A <Location /></
samp> directive might overturn it.</
p>
1276N/A <
p>Also be wary of playing games with the <
a 1276N/A setting it to something like <
samp>"./"</
samp> would have the
1276N/A same effect, for root, as the first example above. If you are
1276N/A using Apache 1.3 or above, we strongly recommend that you
1276N/A include the following line in your server configuration
<
dd><
samp>UserDir disabled root</
samp></
dd>
<
h2><
a id="watchyourlogs" name="watchyourlogs">
Watching Your Logs</
a></
h2>
<
p>To keep up-to-date with what is actually going on against your
server you have to check the <
a href="/logs.html">Log Files</
a>.
Even though the log files only reports what has already happend,
they will give you some understanding of what attacks is thrown
against the server and allows you to check if the necessary level
of security is present.</
p>
<
p>A couple of examples:</
p>
access_log</
samp></
li> <
li><
samp>grep "client denied" error_log |
<
p>The first example will list the number of attacks trying to
Source.JSP Malformed Request Information Disclosure
Vulnerability</
a>, the second example will list the ten last denied
clients, for example:</
p>
<
dd><
samp>[Thu Jul 11 17:18:39 2002] [error] [client
foo.bar.com]
client denied by server configuration:
<
p>As you can see, the log files only report what already has
happend, so if the client had been able to access the
<
samp>.htpasswd</
samp> file you would have seen something similar
/.htpasswd
HTTP/
1.1"</
samp> in your <
a href="/logs.html#accesslog">Access Log</
a>. This means you
probably commented out the following in your server configuration
<
p>Please send any other useful security tips to The Apache
problem report</
a>. If you are confident you have found a
security bug in the Apache source code itself, <
a