mirror of
https://github.com/apache/httpd.git
synced 2025-06-03 10:42:03 +03:00
a7273e37bd
Submitted by: David Shane Holden <dpejesh@yahoo.com> git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96505 13f79535-47bb-0310-9956-ffa450edef68
261 lines
13 KiB
Plaintext
261 lines
13 KiB
Plaintext
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><!--
|
|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
This file is generated from xml source: DO NOT EDIT
|
|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
--><title>Security Tips - Apache HTTP Server</title><link href="../style/manual.css" type="text/css" rel="stylesheet"></head><body><blockquote><div align="center"><img src="../images/sub.gif" alt="[APACHE DOCUMENTATION]"><h3>Apache HTTP Server Version 2.0</h3></div><h1 align="center">Security Tips</h1>
|
|
<p>Some hints and tips on security issues in setting up a web server.
|
|
Some of the suggestions will be general, others specific to Apache.</p>
|
|
<ul><li><a href="#serverroot">Permissions on ServerRoot Directories</a></li><li><a href="#ssi">Server Side Includes</a></li><li><a href="#cgi">CGI in General</a></li><li><a href="#nsaliasedcgi">Non Script Aliased CGI</a></li><li><a href="#saliasedcgi">Script Aliased CGI</a></li><li><a href="#systemsettings">Protecting System Settings</a></li><li><a href="#protectserverfiles">Protect Server Files by Default</a></li><li><a href="#watchyourlogs">Watching Your Logs</a></li></ul><hr><h2><a name="serverroot">Permissions on ServerRoot Directories</a></h2>
|
|
|
|
|
|
|
|
<p>In typical operation, Apache is started by the root user, and it
|
|
switches to the user defined by the <a href="../mod/mpm_common.html#user" class="directive"><code class="directive">User</code></a> directive to serve hits. As is the
|
|
case with any command that root executes, you must take care that it is
|
|
protected from modification by non-root users. Not only must the files
|
|
themselves be writeable only by root, but so must the directories, and
|
|
parents of all directories. For example, if you choose to place
|
|
ServerRoot in /usr/local/apache then it is suggested that you create
|
|
that directory as root, with commands like these:</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
mkdir /usr/local/apache <br>
|
|
cd /usr/local/apache <br>
|
|
mkdir bin conf logs <br>
|
|
chown 0 . bin conf logs <br>
|
|
chgrp 0 . bin conf logs <br>
|
|
chmod 755 . bin conf logs
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>It is assumed that /, /usr, and /usr/local are only modifiable by
|
|
root. When you install the httpd executable, you should ensure that
|
|
it is similarly protected:</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
cp httpd /usr/local/apache/bin <br>
|
|
chown 0 /usr/local/apache/bin/httpd <br>
|
|
chgrp 0 /usr/local/apache/bin/httpd <br>
|
|
chmod 511 /usr/local/apache/bin/httpd
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>You can create an htdocs subdirectory which is modifiable by other
|
|
users -- since root never executes any files out of there, and shouldn't
|
|
be creating files in there.</p>
|
|
|
|
<p>If you allow non-root users to modify any files that root either
|
|
executes or writes on then you open your system to root compromises.
|
|
For example, someone could replace the httpd binary so that the next
|
|
time you start it, it will execute some arbitrary code. If the logs
|
|
directory is writeable (by a non-root user), someone could replace
|
|
a log file with a symlink to some other system file, and then root
|
|
might overwrite that file with arbitrary data. If the log files
|
|
themselves are writeable (by a non-root user), then someone may be
|
|
able to overwrite the log itself with bogus data.</p>
|
|
|
|
<h2><a name="ssi">Server Side Includes</a></h2>
|
|
|
|
|
|
|
|
<p>Server Side Includes (SSI) present a server administrator with
|
|
several potential security risks.</p>
|
|
|
|
<p>The first risk is the increased load on the server. All
|
|
SSI-enabled files have to be parsed by Apache, whether or not
|
|
there are any SSI directives included within the files. While this
|
|
load increase is minor, in a shared server environment it can become
|
|
significant.</p>
|
|
|
|
<p>SSI files also pose the same risks that are associated with CGI
|
|
scripts in general. Using the "exec cmd" element, SSI-enabled files
|
|
can execute any CGI script or program under the permissions of the
|
|
user and group Apache runs as, as configured in httpd.conf.</p>
|
|
|
|
<p>There are ways to enhance the security of SSI files while still
|
|
taking advantage of the benefits they provide.</p>
|
|
|
|
<p>To isolate the damage a wayward SSI file can cause, a server
|
|
administrator can enable <a href="../suexec.html">suexec</a> as
|
|
described in the <a href="#cgi">CGI in General</a> section</p>
|
|
|
|
<p>Enabling SSI for files with .html or .htm extensions can be
|
|
dangerous. This is especially true in a shared, or high traffic,
|
|
server environment. SSI-enabled files should have a separate extension,
|
|
such as the conventional .shtml. This helps keep server load at a
|
|
minimum and allows for easier management of risk.</p>
|
|
|
|
<p>Another solution is to disable the ability to run scripts and
|
|
programs from SSI pages. To do this replace <code>Includes</code>
|
|
with <code>IncludesNOEXEC</code> in the <a href="../mod/core.html#options" class="directive"><code class="directive">Options</code></a> directive. Note that users may
|
|
still use >--#include virtual="..." --< to execute CGI scripts if
|
|
these scripts are in directories desginated by a <a href="../mod/mod_alias.html#scriptalias" class="directive"><code class="directive">ScriptAlias</code></a> directive.</p>
|
|
|
|
<h2><a name="cgi">CGI in General</a></h2>
|
|
|
|
|
|
|
|
<p>First of all, you always have to remember that you must trust the
|
|
writers of the CGI scripts/programs or your ability to spot potential
|
|
security holes in CGI, whether they were deliberate or accidental. CGI
|
|
scripts can run essentially arbitrary commands on your system with the
|
|
permissions of the web server user and can therefore be extremely
|
|
dangerous if they are not carefully checked.</p>
|
|
|
|
<p>All the CGI scripts will run as the same user, so they have potential
|
|
to conflict (accidentally or deliberately) with other scripts e.g. User
|
|
A hates User B, so he writes a script to trash User B's CGI database. One
|
|
program which can be used to allow scripts to run as different users is
|
|
<a href="../suexec.html">suEXEC</a> which is included with Apache as of
|
|
1.2 and is called from special hooks in the Apache server code. Another
|
|
popular way of doing this is with
|
|
<a href="http://cgiwrap.unixtools.org/">CGIWrap</a>.</p>
|
|
|
|
<h2><a name="nsaliasedcgi">Non Script Aliased CGI</a></h2>
|
|
|
|
|
|
|
|
<p>Allowing users to execute CGI scripts in any directory should only be
|
|
considered if;</p>
|
|
|
|
<ul>
|
|
<li>You trust your users not to write scripts which will deliberately
|
|
or accidentally expose your system to an attack.</li>
|
|
<li>You consider security at your site to be so feeble in other areas,
|
|
as to make one more potential hole irrelevant.</li>
|
|
<li>You have no users, and nobody ever visits your server.</li>
|
|
</ul>
|
|
|
|
<h2><a name="saliasedcgi">Script Aliased CGI</a></h2>
|
|
|
|
|
|
|
|
<p>Limiting CGI to special directories gives the admin control over what
|
|
goes into those directories. This is inevitably more secure than non
|
|
script aliased CGI, but only if users with write access to the
|
|
directories are trusted or the admin is willing to test each
|
|
new CGI script/program for potential security holes.</p>
|
|
|
|
<p>Most sites choose this option over the non script aliased CGI
|
|
approach.</p>
|
|
|
|
<h2><a name="systemsettings">Protecting System Settings</a></h2>
|
|
|
|
|
|
|
|
<p>To run a really tight ship, you'll want to stop users from setting
|
|
up <code>.htaccess</code> files which can override security features
|
|
you've configured. Here's one way to do it.</p>
|
|
|
|
<p>In the server configuration file, put</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
<Directory /> <br>
|
|
AllowOverride None <br>
|
|
</Directory>
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>This prevents the use of <code>.htaccess</code> files in all
|
|
directories apart from those specifically enabled.</p>
|
|
|
|
<h2><a name="protectserverfiles">Protect Server Files by Default</a></h2>
|
|
|
|
|
|
|
|
<p>One aspect of Apache which is occasionally misunderstood is the
|
|
feature of default access. That is, unless you take steps to change it,
|
|
if the server can find its way to a file through normal URL mapping
|
|
rules, it can serve it to clients.</p>
|
|
|
|
<p>For instance, consider the following example:</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
# cd /; ln -s / public_html <br>
|
|
Accessing <code>http://localhost/~root/</code>
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>This would allow clients to walk through the entire filesystem. To
|
|
work around this, add the following block to your server's
|
|
configuration:</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
<Directory /> <br>
|
|
Order Deny,Allow <br>
|
|
Deny from all <br>
|
|
</Directory>
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>This will forbid default access to filesystem locations. Add
|
|
appropriate <a href="../mod/core.html#directory" class="directive"><code class="directive">Directory</code></a> blocks to
|
|
allow access only in those areas you wish. For example,</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
<Directory /usr/users/*/public_html> <br>
|
|
Order Deny,Allow <br>
|
|
Allow from all <br>
|
|
</Directory> <br>
|
|
<Directory /usr/local/httpd> <br>
|
|
Order Deny,Allow <br>
|
|
Allow from all <br>
|
|
</Directory>
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>Pay particular attention to the interactions of <a href="../mod/core.html#location" class="directive"><code class="directive">Location</code></a> and <a href="../mod/core.html#directory" class="directive"><code class="directive">Directory</code></a> directives; for instance, even
|
|
if <code><Directory /></code> denies access, a <code>
|
|
<Location /></code> directive might overturn it</p>
|
|
|
|
<p>Also be wary of playing games with the <a href="../mod/mod_userdir.html#userdir" class="directive"><code class="directive">UserDir</code></a> directive; setting it to
|
|
something like "./" would have the same effect, for root, as the first
|
|
example above. If you are using Apache 1.3 or above, we strongly
|
|
recommend that you include the following line in your server
|
|
configuration files:</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
UserDir disabled root
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<h2><a 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>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br>
|
|
grep "client denied" error_log | tail -n 10
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>The first example will list the number of attacks trying to exploit the
|
|
<a href="http://online.securityfocus.com/bid/4876/info/">Apache Tomcat
|
|
Source.JSP Malformed Request Information Disclosure Vulnerability</a>,
|
|
the second example will list the ten last denied clients, for example:</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
[Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied
|
|
by server configuration: /usr/local/apache/htdocs/.htpasswd
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>As you can see, the log files only report what already has happend, so
|
|
if the client had been able to access the <code>.htpasswd</code> file you
|
|
would have seen something similar to:</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>in your <a href="../logs.html#accesslog">Access Log</a>. This means
|
|
you probably commented out the following in your server configuration
|
|
file:</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
<Files ~ "^\.ht"> <br>
|
|
Order allow,deny <br>
|
|
Deny from all <br>
|
|
<Files>
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<hr></blockquote><h3 align="center">Apache HTTP Server Version 2.0</h3><a href="./"><img src="../images/index.gif" alt="Index"></a><a href="../"><img src="../images/home.gif" alt="Home"></a></body></html> |