mirror of
https://github.com/apache/httpd.git
synced 2025-06-06 09:01:00 +03:00
d78c998c6a
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96194 13f79535-47bb-0310-9956-ffa450edef68
351 lines
12 KiB
HTML
351 lines
12 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org" />
|
|
<title>Apache HTTP Server: Security Tips</title>
|
|
</head>
|
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
|
|
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
|
|
vlink="#000080" alink="#FF0000">
|
|
<!--#include virtual="header.html" -->
|
|
|
|
<h1 align="center">Security Tips for Server Configuration</h1>
|
|
|
|
<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 />
|
|
|
|
<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>
|
|
<hr />
|
|
|
|
<h2><a id="serverroot" 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"><strong>User</strong></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 <code>
|
|
/usr/local/apache</code> then it is suggested that you create
|
|
that directory as root, with commands like these:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
mkdir /usr/local/apache
|
|
cd /usr/local/apache
|
|
mkdir bin conf logs
|
|
chown 0 . bin conf logs
|
|
chgrp 0 . bin conf logs
|
|
chmod 755 . bin conf logs
|
|
</pre>
|
|
</blockquote>
|
|
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:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
cp httpd /usr/local/apache/bin
|
|
chown 0 /usr/local/apache/bin/httpd
|
|
chgrp 0 /usr/local/apache/bin/httpd
|
|
chmod 511 /usr/local/apache/bin/httpd
|
|
</pre>
|
|
</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>
|
|
<hr />
|
|
|
|
<h2><a id="ssi" 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.
|
|
That should definitely give server administrators pause.</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="../docs/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">Options</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">ScriptAlias</a>
|
|
directive.</p>
|
|
|
|
<hr />
|
|
|
|
<h2><a id="cgi" 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 <em>e.g.</em> 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://wwwcgi.umr.edu/~cgiwrap/">CGIWrap</a>.</p>
|
|
|
|
<p></p>
|
|
<hr />
|
|
|
|
<h2><a id="nsaliasedcgi" name="nsaliasedcgi">Non Script Aliased
|
|
CGI</a></h2>
|
|
|
|
<p>Allowing users to execute <strong>CGI</strong> scripts in
|
|
any directory should only be considered if;</p>
|
|
|
|
<ol>
|
|
<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>
|
|
</ol>
|
|
<hr />
|
|
|
|
<h2><a id="saliasedcgi" name="saliasedcgi">Script Aliased
|
|
CGI</a></h2>
|
|
|
|
<p>Limiting <strong>CGI</strong> to special directories gives
|
|
the admin control over what goes into those directories. This
|
|
is inevitably more secure than non script aliased CGI, but
|
|
<strong>only if users with write access to the directories are
|
|
trusted</strong> 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>
|
|
|
|
<p></p>
|
|
<hr />
|
|
|
|
<h2><a id="systemsettings" 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>
|
|
<code><Directory /><br />
|
|
AllowOverride None<br />
|
|
</Directory><br />
|
|
</code>
|
|
</blockquote>
|
|
|
|
<p>This prevents the use of <code>.htaccess</code> files in all
|
|
directories apart from those specifically enabled.</p>
|
|
<hr />
|
|
|
|
<h2><a id="protectserverfiles" 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>
|
|
|
|
<ol>
|
|
<li><samp># cd /; ln -s / public_html</samp></li>
|
|
|
|
<li>Accessing <samp>http://localhost/~root/</samp></li>
|
|
</ol>
|
|
|
|
<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>
|
|
<pre>
|
|
<Directory />
|
|
Order Deny,Allow
|
|
Deny from all
|
|
</Directory>
|
|
</pre>
|
|
|
|
<p>This will forbid default access to filesystem locations. Add
|
|
appropriate <a href="../mod/core.html#directory"><samp>
|
|
<Directory></samp></a> blocks to allow access only in
|
|
those areas you wish. For example,</p>
|
|
<pre>
|
|
<Directory /usr/users/*/public_html>
|
|
Order Deny,Allow
|
|
Allow from all
|
|
</Directory>
|
|
<Directory /usr/local/httpd>
|
|
Order Deny,Allow
|
|
Allow from all
|
|
</Directory>
|
|
</pre>
|
|
|
|
<p>Pay particular attention to the interactions of <a
|
|
href="../mod/core.html#location"><samp>
|
|
<Location></samp></a> and <a
|
|
href="../mod/core.html#directory"><samp>
|
|
<Directory></samp></a> directives; for instance, even if
|
|
<samp><Directory /></samp> denies access, a <samp>
|
|
<Location /></samp> directive might overturn it.</p>
|
|
|
|
<p>Also be wary of playing games with the <a
|
|
href="../mod/mod_userdir.html#userdir">UserDir</a> directive;
|
|
setting it to something like <samp>"./"</samp> 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>
|
|
|
|
<dl>
|
|
<dd><samp>UserDir disabled root</samp></dd>
|
|
</dl>
|
|
|
|
<p></p>
|
|
<hr />
|
|
|
|
<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>
|
|
<ol>
|
|
<li><samp>grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??"
|
|
access_log</samp></li> <li><samp>grep "client denied" error_log |
|
|
tail -n 10 </samp></li>
|
|
</ol>
|
|
|
|
<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>
|
|
|
|
<dl>
|
|
<dd><samp>[Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com]
|
|
client denied by server configuration:
|
|
/usr/local/apache/htdocs/.htpasswd</samp></dd>
|
|
</dl>
|
|
|
|
<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
|
|
to <samp>foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET
|
|
/.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
|
|
file:</p>
|
|
|
|
<pre>
|
|
<Files ~ "^\.ht">
|
|
Order allow,deny
|
|
Deny from all
|
|
</Files>
|
|
</pre>
|
|
|
|
<hr />
|
|
|
|
<p>Please send any other useful security tips to The Apache
|
|
Group by filling out a <a href="http://bugs.apache.org/">
|
|
problem report</a>. If you are confident you have found a
|
|
security bug in the Apache source code itself, <a
|
|
href="http://httpd.apache.org/bug_report.html">please let us
|
|
know</a>.</p>
|
|
|
|
<!--#include virtual="footer.html" -->
|
|
</body>
|
|
</html>
|
|
|
|
|
|
|