mirror of
https://github.com/apache/httpd.git
synced 2025-05-17 15:21:13 +03:00
97318f9e20
All directives are now consistently capitalized. PR: Obtained from: Submitted by: Rich Bowen <rbowen@rcbowen.com> Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86205 13f79535-47bb-0310-9956-ffa450edef68
232 lines
7.4 KiB
HTML
232 lines
7.4 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<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>
|
|
|
|
<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.
|
|
|
|
<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/core.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:
|
|
|
|
<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>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>Server Side Includes</H2>
|
|
<P>Server side includes (SSI) can be configured so that users can execute
|
|
arbitrary programs on the server. That thought alone should send a shiver
|
|
down the spine of any sys-admin.<P>
|
|
|
|
One solution is to disable that part of SSI. To do that you use the
|
|
IncludesNOEXEC option to the <A HREF="../mod/core.html#options">Options</A>
|
|
directive.<P>
|
|
|
|
<HR>
|
|
|
|
<H2>Non Script Aliased CGI</H2>
|
|
<P>Allowing users to execute <STRONG>CGI</STRONG> scripts in any directory
|
|
should only
|
|
be considered if;
|
|
<OL>
|
|
<LI>You trust your users not to write scripts which will deliberately or
|
|
accidentally expose your system to an attack.
|
|
<LI>You consider security at your site to be so feeble in other areas, as to
|
|
make one more potential hole irrelevant.
|
|
<LI>You have no users, and nobody ever visits your server.
|
|
</OL><P>
|
|
<HR>
|
|
|
|
<H2>Script Alias'ed CGI</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>
|
|
|
|
Most sites choose this option over the non script aliased CGI approach.<P>
|
|
|
|
<HR>
|
|
<H2>CGI in general</H2>
|
|
<P>Always remember that you must trust the writers of the CGI script/programs
|
|
or your ability to spot potential security holes in CGI, whether they were
|
|
deliberate or accidental.<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>
|
|
|
|
<HR>
|
|
|
|
|
|
<H2>Stopping users overriding system wide settings...</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>
|
|
|
|
In the server configuration file, put
|
|
<BLOCKQUOTE><CODE>
|
|
<Directory /> <BR>
|
|
AllowOverride None <BR>
|
|
Options None <BR>
|
|
Allow from all <BR>
|
|
</Directory> <BR>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Then setup for specific directories<P>
|
|
|
|
This stops all overrides, Includes and accesses in all directories apart
|
|
from those named.<P>
|
|
<HR>
|
|
<H2>
|
|
Protect server files by default
|
|
</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>
|
|
|
|
<HR>
|
|
<P>Please send any other useful security tips to The Apache Group
|
|
by filling out a
|
|
<A HREF="http://www.apache.org/bug_report.html">problem report</A>.
|
|
If you are confident you have found a security bug in the Apache
|
|
source code itself, <A
|
|
HREF="http://www.apache.org/security_report.html">please let us
|
|
know</A>.
|
|
|
|
<P>
|
|
|
|
<!--#include virtual="footer.html" -->
|
|
</BODY>
|
|
</HTML>
|