httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sl...@apache.org
Subject cvs commit: httpd-docs-1.3/htdocs/manual/misc security_tips.html
Date Tue, 02 Oct 2001 15:40:07 GMT
slive       01/10/02 08:40:07

  Modified:    htdocs/manual/misc security_tips.html
  Log:
  Tidy.
  
  Submitted by:	Allan Liska <allan@allan.org>
  
  Revision  Changes    Path
  1.25      +234 -222  httpd-docs-1.3/htdocs/manual/misc/security_tips.html
  
  Index: security_tips.html
  ===================================================================
  RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/misc/security_tips.html,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -d -b -u -r1.24 -r1.25
  --- security_tips.html	2001/10/02 15:37:34	1.24
  +++ security_tips.html	2001/10/02 15:40:07	1.25
  @@ -1,200 +1,221 @@
  -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
  -<HTML>
  -<HEAD>
  -<TITLE>Apache HTTP Server: Security Tips</TITLE>
  -</HEAD>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   
  -<!-- 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>
  +<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" -->
   
  -<ul>
  -<li><a href="#serverroot">Permissions on ServerRoot Directories</a></li>
  +    <h1 align="CENTER">Security Tips for Server Configuration</h1>
   
  -<li><a href="#ssi">Server Side Includes</a>
  +    <ul>
  +      <li><a href="#serverroot">Permissions on ServerRoot
  +      Directories</a></li>
   
  -<li><a href="#nsaliasedcgi">Non Script Aliased CGI</a></li>
  +      <li><a href="#ssi">Server Side Includes</a></li>
   
  -<li><a href="#saliasedcgi">Script Aliased CGI</a></li>
  +      <li><a href="#nsaliasedcgi">Non Script Aliased CGI</a></li>
   
  -<li><a href="#cgi">CGI in General</a></li>
  +      <li><a href="#saliasedcgi">Script Aliased CGI</a></li>
   
  -<li><a href="#systemsettings">Protecting System Settings</a></li>
  +      <li><a href="#cgi">CGI in General</a></li>
   
  -<li><a href="#protectserverfiles">Protect Server Files by Default</a></li>
  -</ul>
  +      <li><a href="#systemsettings">Protecting System
  +      Settings</a></li>
   
  -<HR>
  +      <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
  -the suggestions will be general, others specific to Apache.
  +    <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 />
   
  -<HR>
  +    <h2><a id="serverroot" name="serverroot">Permissions on
  +    ServerRoot Directories</a></h2>
   
  -<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:
  +    <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>
  +    <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>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 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>
  +    <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 />
   
  -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>
  +    <h2><a id="ssi" name="ssi">Server Side Includes</a></h2>
   
  -<HR>
  +    <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>
   
  -<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;
  -<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>
  +    <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>
   
  -<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
  -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></p>
  +    <hr />
   
  -Most sites choose this option over the non script aliased CGI approach.<P>
  +    <h2><a id="nsaliasedcgi" name="nsaliasedcgi">Non Script Aliased
  +    CGI</a></h2>
   
  -<HR>
  -<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>
  +    <p>Allowing users to execute <strong>CGI</strong> scripts in
  +    any directory should only be considered if;</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>
  +    <ol>
  +      <li>You trust your users not to write scripts which will
  +      deliberately or accidentally expose your system to an
  +      attack.</li>
   
  -<HR>
  +      <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 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>
  +    <h2><a id="saliasedcgi" name="saliasedcgi">Script Aliased
  +    CGI</a></h2>
   
  -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>
  +    <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>
   
  -Then setup for specific directories<P>
  +    <p>Most sites choose this option over the non script aliased
  +    CGI approach.</p>
   
  -This stops all overrides, Includes and accesses in all directories apart
  -from those named.<P>
  -<HR>
  -<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>
  -<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></p>
  +    <hr />
  +
  +    <h2><a id="cgi" 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>
  +
  +    <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="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>&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><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>
    &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
  @@ -203,46 +224,37 @@
        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>
  +</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>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>
  +    <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>
   
  -<!--#include virtual="footer.html" -->
  -</BODY>
  -</HTML>
  +    <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>
  +
  
  
  

Mime
View raw message