httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allan Liska <al...@allan.org>
Subject [PATCH] security_tips.html III
Date Tue, 02 Oct 2001 03:53:23 GMT

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>
-&lt;Directory /&gt; <BR>
-AllowOverride None <BR>
-Options None <BR>
-Allow from all <BR>
-&lt;/Directory&gt; <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>&lt;Directory /&gt;<br />
+       AllowOverride None<br />
+       Options None<br />
+       Allow from all<br />
+       &lt;/Directory&gt;<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>
  &lt;Directory /&gt;
      Order Deny,Allow
      Deny from all
  &lt;/Directory&gt;
-</PRE>
-<P>
-This will forbid default access to filesystem locations.  Add
-appropriate
-<A
- HREF="../mod/core.html#directory"
-><SAMP>&lt;Directory&gt;</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>&lt;Directory&gt;</samp></a>
+    blocks to allow access only in those areas you wish. For
+    example,</p>
+<pre>
  &lt;Directory /usr/users/*/public_html&gt;
      Order Deny,Allow
      Allow from all
@@ -186,46 +202,39 @@
      Order Deny,Allow
      Allow from all
  &lt;/Directory&gt;
-</PRE>
-<P>
-Pay particular attention to the interactions of
-<A
- HREF="../mod/core.html#location"
-><SAMP>&lt;Location&gt;</SAMP></A>
-and
-<A
- HREF="../mod/core.html#directory"
-><SAMP>&lt;Directory&gt;</SAMP></A>
-directives; for instance, even if <SAMP>&lt;Directory /&gt;</SAMP>
-denies access, a <SAMP>&lt;Location /&gt;</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>&quot;./&quot;</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&nbsp;disabled&nbsp;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>&lt;Location&gt;</samp></a>
+    and <a
+    href="../mod/core.html#directory"><samp>&lt;Directory&gt;</samp></a>
+    directives; for instance, even if <samp>&lt;Directory
+    /&gt;</samp> denies access, a <samp>&lt;Location /&gt;</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&nbsp;disabled&nbsp;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


Mime
View raw message