You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Allan Liska <al...@allan.org> on 2001/10/02 05:47:19 UTC
[PATCH] security_tips.html II
I added a navigation menu at the top of the page, to make it easier to
work your way through the document.
Index: httpd-docs-1.3/htdocs/manual/misc/security_tips.html
===================================================================
RCS file: /home/cvspublic/httpd-docs-1.3/htdocs/manual/misc/security_tips.html,v
retrieving revision 1.23
diff -u -r1.23 security_tips.html
--- httpd-docs-1.3/htdocs/manual/misc/security_tips.html 2001/09/24 01:36:41 1.23
+++ httpd-docs-1.3/htdocs/manual/misc/security_tips.html 2001/10/02 03:52:19
@@ -15,6 +15,23 @@
<!--#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><a href="#nsaliasedcgi">Non Script Aliased CGI</a></li>
+
+<li><a href="#saliasedcgi">Script Aliased CGI</a></li>
+
+<li><a href="#cgi">CGI in General</a></li>
+
+<li><a href="#systemsettings">Protecting System Settings</a></li>
+
+<li><a href="#protectserverfiles">Protect Server Files by Default</a></li>
+</ul>
+
<HR>
<P>Some hints and tips on security issues in setting up a web server. Some of
@@ -69,7 +86,7 @@
may be able to overwrite the log itself with bogus data.
<P>
<HR>
-<H2>Server Side Includes</H2>
+<h2><a name="ssi">Server Side Includes</a></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>
@@ -80,7 +97,7 @@
<HR>
-<H2>Non Script Aliased CGI</H2>
+<h2><a 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;
@@ -93,7 +110,7 @@
</OL><P>
<HR>
-<H2>Script Alias'ed CGI</H2>
+<h2><a 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
@@ -104,7 +121,7 @@
Most sites choose this option over the non script aliased CGI approach.<P>
<HR>
-<H2>CGI in general</H2>
+<h2><a name="cgi">CGI in General</a></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>
@@ -121,7 +138,7 @@
<HR>
-<H2>Stopping users overriding system wide settings...</H2>
+<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>
@@ -141,7 +158,7 @@
from those named.<P>
<HR>
<H2>
- Protect server files by default
+<a name="protectserverfiles">Protect Server Files by Default</a>
</H2>
<P>
One aspect of Apache which is occasionally misunderstood is the feature
--
Allan Liska
allan@allan.org
http://www.allan.org
---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org
[PATCH] security_tips.html III
Posted by Allan Liska <al...@allan.org>.
Final patch, for now. I converted the document to standard XML using
Tidy and Rich Bowen's recommended command set: tidy -mi -asxml file.html
Please let me know if you have any questions, or if I should handle the
three patches in a different manner.
Thanks!
Index: httpd-docs-1.3/htdocs/manual/misc/security_tips.html
===================================================================
RCS file: /home/cvspublic/httpd-docs-1.3/htdocs/manual/misc/security_tips.html,v
retrieving revision 1.23
diff -u -r1.23 security_tips.html
--- httpd-docs-1.3/htdocs/manual/misc/security_tips.html 2001/09/24 01:36:41 1.23
+++ httpd-docs-1.3/htdocs/manual/misc/security_tips.html 2001/10/02 03:57:00
@@ -1,183 +1,199 @@
-<!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:
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<BLOCKQUOTE><PRE>
+<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>
+ <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/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:</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:
+</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>
+ <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>
+</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>
+ <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>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>
+
+ <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>
+
+ <p></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;</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>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>
+
+ <p>Most sites choose this option over the non script aliased
+ CGI approach.</p>
+
+ <p></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>
+
+ <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>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>
+
+ <p>In the server configuration file, put</p>
+
+ <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>
+</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
@@ -186,46 +202,39 @@
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://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>
+</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://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>
+
+ <p><!--#include virtual="footer.html" -->
+ </p>
+ </body>
+</html>
+
--
Allan Liska
allan@allan.org
http://www.allan.org
---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org