granicus.if.org Git - apache/blob - docs/manual/misc/security_tips.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3
   4 <html xmlns="http://www.w3.org/1999/xhtml">
   5   <head>
   6     <meta name="generator" content="HTML Tidy, see www.w3.org" />
   7
   8     <title>Apache HTTP Server: Security Tips</title>
   9   </head>
  10   <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  11
  12   <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  13   vlink="#000080" alink="#FF0000">
  14     <!--#include virtual="header.html" -->
  15
  16     <h1 align="CENTER">Security Tips for Server Configuration</h1>
  17     <hr />
  18
  19     <p>Some hints and tips on security issues in setting up a web
  20     server. Some of the suggestions will be general, others
  21     specific to Apache.</p>
  22     <hr />
  23
  24     <h2><a id="serverroot" name="serverroot">Permissions on
  25     ServerRoot Directories</a></h2>
  26
  27     <p>In typical operation, Apache is started by the root user,
  28     and it switches to the user defined by the <a
  29     href="../mod/core.html#user"><strong>User</strong></a>
  30     directive to serve hits. As is the case with any command that
  31     root executes, you must take care that it is protected from
  32     modification by non-root users. Not only must the files
  33     themselves be writeable only by root, but so must the
  34     directories, and parents of all directories. For example, if
  35     you choose to place ServerRoot in
  36     <code>/usr/local/apache</code> then it is suggested that you
  37     create that directory as root, with commands like these:</p>
  38
  39     <blockquote>
  40 <pre>
  41     mkdir /usr/local/apache
  42     cd /usr/local/apache
  43     mkdir bin conf logs
  44     chown 0 . bin conf logs
  45     chgrp 0 . bin conf logs
  46     chmod 755 . bin conf logs
  47 </pre>
  48     </blockquote>
  49     It is assumed that /, /usr, and /usr/local are only modifiable
  50     by root. When you install the httpd executable, you should
  51     ensure that it is similarly protected:
  52
  53     <blockquote>
  54 <pre>
  55     cp httpd /usr/local/apache/bin
  56     chown 0 /usr/local/apache/bin/httpd
  57     chgrp 0 /usr/local/apache/bin/httpd
  58     chmod 511 /usr/local/apache/bin/httpd
  59 </pre>
  60     </blockquote>
  61
  62     <p>You can create an htdocs subdirectory which is modifiable by
  63     other users -- since root never executes any files out of
  64     there, and shouldn't be creating files in there.</p>
  65
  66     <p>If you allow non-root users to modify any files that root
  67     either executes or writes on then you open your system to root
  68     compromises. For example, someone could replace the httpd
  69     binary so that the next time you start it, it will execute some
  70     arbitrary code. If the logs directory is writeable (by a
  71     non-root user), someone could replace a log file with a symlink
  72     to some other system file, and then root might overwrite that
  73     file with arbitrary data. If the log files themselves are
  74     writeable (by a non-root user), then someone may be able to
  75     overwrite the log itself with bogus data.</p>
  76     <hr />
  77
  78     <h2>Server Side Includes</h2>
  79
  80     <p>Server side includes (SSI) can be configured so that users
  81     can execute arbitrary programs on the server. That thought
  82     alone should send a shiver down the spine of any sys-admin.</p>
  83
  84     <p>One solution is to disable that part of SSI. To do that you
  85     use the IncludesNOEXEC option to the <a
  86     href="../mod/core.html#options">Options</a> directive.</p>
  87     <hr />
  88
  89     <h2>Non Script Aliased CGI</h2>
  90
  91     <p>Allowing users to execute <strong>CGI</strong> scripts in
  92     any directory should only be considered if;</p>
  93
  94     <ol>
  95       <li>You trust your users not to write scripts which will
  96       deliberately or accidentally expose your system to an
  97       attack.</li>
  98
  99       <li>You consider security at your site to be so feeble in
 100       other areas, as to make one more potential hole
 101       irrelevant.</li>
 102
 103       <li>You have no users, and nobody ever visits your
 104       server.</li>
 105     </ol>
 106     <hr />
 107
 108     <h2>Script Alias'ed CGI</h2>
 109
 110     <p>Limiting <strong>CGI</strong> to special directories gives
 111     the admin control over what goes into those directories. This
 112     is inevitably more secure than non script aliased CGI, but
 113     <strong>only if users with write access to the directories are
 114     trusted</strong> or the admin is willing to test each new CGI
 115     script/program for potential security holes.</p>
 116
 117     <p>Most sites choose this option over the non script aliased
 118     CGI approach.</p>
 119     <hr />
 120
 121     <h2>CGI in general</h2>
 122
 123     <p>Always remember that you must trust the writers of the CGI
 124     script/programs or your ability to spot potential security
 125     holes in CGI, whether they were deliberate or accidental.</p>
 126
 127     <p>All the CGI scripts will run as the same user, so they have
 128     potential to conflict (accidentally or deliberately) with other
 129     scripts <em>e.g.</em> User A hates User B, so he writes a
 130     script to trash User B's CGI database. One program which can be
 131     used to allow scripts to run as different users is <a
 132     href="../suexec.html">suEXEC</a> which is included with Apache
 133     as of 1.2 and is called from special hooks in the Apache server
 134     code. Another popular way of doing this is with <a
 135     href="http://wwwcgi.umr.edu/~cgiwrap/">CGIWrap</a>.</p>
 136     <hr />
 137
 138     <h2>Stopping users overriding system wide settings...</h2>
 139
 140     <p>To run a really tight ship, you'll want to stop users from
 141     setting up <code>.htaccess</code> files which can override
 142     security features you've configured. Here's one way to do
 143     it...</p>
 144
 145     <p>In the server configuration file, put</p>
 146
 147     <blockquote>
 148       <code>&lt;Directory /&gt;<br />
 149        AllowOverride None<br />
 150        Options None<br />
 151        Allow from all<br />
 152        &lt;/Directory&gt;<br />
 153       </code>
 154     </blockquote>
 155     Then setup for specific directories
 156
 157     <p>This stops all overrides, Includes and accesses in all
 158     directories apart from those named.</p>
 159     <hr />
 160
 161     <h2>Protect server files by default</h2>
 162
 163     <p>One aspect of Apache which is occasionally misunderstood is
 164     the feature of default access. That is, unless you take steps
 165     to change it, if the server can find its way to a file through
 166     normal URL mapping rules, it can serve it to clients.</p>
 167
 168     <p>For instance, consider the following example:</p>
 169
 170     <ol>
 171       <li><samp># cd /; ln -s / public_html</samp></li>
 172
 173       <li>Accessing <samp>http://localhost/~root/</samp></li>
 174     </ol>
 175
 176     <p>This would allow clients to walk through the entire
 177     filesystem. To work around this, add the following block to
 178     your server's configuration:</p>
 179 <pre>
 180  &lt;Directory /&gt;
 181      Order Deny,Allow
 182      Deny from all
 183  &lt;/Directory&gt;
 184 </pre>
 185
 186     <p>This will forbid default access to filesystem locations. Add
 187     appropriate <a
 188     href="../mod/core.html#directory"><samp>&lt;Directory&gt;</samp></a>
 189     blocks to allow access only in those areas you wish. For
 190     example,</p>
 191 <pre>
 192  &lt;Directory /usr/users/*/public_html&gt;
 193      Order Deny,Allow
 194      Allow from all
 195  &lt;/Directory&gt;
 196  &lt;Directory /usr/local/httpd&gt;
 197      Order Deny,Allow
 198      Allow from all
 199  &lt;/Directory&gt;
 200 </pre>
 201
 202     <p>Pay particular attention to the interactions of <a
 203     href="../mod/core.html#location"><samp>&lt;Location&gt;</samp></a>
 204     and <a
 205     href="../mod/core.html#directory"><samp>&lt;Directory&gt;</samp></a>
 206     directives; for instance, even if <samp>&lt;Directory
 207     /&gt;</samp> denies access, a <samp>&lt;Location /&gt;</samp>
 208     directive might overturn it.</p>
 209
 210     <p>Also be wary of playing games with the <a
 211     href="../mod/mod_userdir.html#userdir">UserDir</a> directive;
 212     setting it to something like <samp>"./"</samp> would have the
 213     same effect, for root, as the first example above. If you are
 214     using Apache 1.3 or above, we strongly recommend that you
 215     include the following line in your server configuration
 216     files:</p>
 217
 218     <dl>
 219       <dd><samp>UserDir&nbsp;disabled&nbsp;root</samp></dd>
 220     </dl>
 221     <hr />
 222
 223     <p>Please send any other useful security tips to The Apache
 224     Group by filling out a <a
 225     href="http://bugs.apache.org/">problem
 226     report</a>. If you are confident you have found a security bug
 227     in the Apache source code itself, <a
 228     href="http://httpd.apache.org/bug_report.html">please let us
 229     know</a>.</p>
 230
 231     <p><!--#include virtual="footer.html" -->
 232     </p>
 233   </body>
 234 </html>
 235