security_tips.html.en

Apache官方在今天放出产品系列2.2的最新版本2.2.11的源码包 最流行的HTTP服务器软件之一

    <p>Allowing users to execute CGI scripts in any directory should only be
    considered if:</p>

    <ul>
      <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>
    </ul>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="saliasedcgi" id="saliasedcgi">Script Aliased CGI</a></h2>

    

    <p>Limiting CGI to special directories gives the admin control over what
    goes into those directories. This is inevitably more secure than non
    script aliased CGI, but only if users with write access to the
    directories are trusted 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>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="dynamic" id="dynamic">Other sources of dynamic content</a></h2>

  

  <p>
  Embedded scripting options which run as part of the server itself,
  such as <code>mod_php</code>, <code>mod_perl</code>, <code>mod_tcl</code>,
  and <code>mod_python</code>, run under the identity of the server itself
  (see the <code class="directive"><a href="../mod/mpm_common.html#user">User</a></code> directive), and
  therefore scripts executed by these engines potentially can access anything
  the server user can. Some scripting engines may provide restrictions, but
  it is better to be safe and assume not.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="systemsettings" id="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>

    <div class="example"><p><code>
      &lt;Directory /&gt; <br />
        AllowOverride None <br />
      &lt;/Directory&gt;
    </code></p></div>

    <p>This prevents the use of <code>.htaccess</code> files in all
    directories apart from those specifically enabled.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="protectserverfiles" id="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>

    <div class="example"><p><code>
      # cd /; ln -s / public_html <br />
      Accessing <code>http://localhost/~root/</code>
    </code></p></div>

    <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>

    <div class="example"><p><code>
      &lt;Directory /&gt; <br />
      Order Deny,Allow <br />
      Deny from all <br />
      &lt;/Directory&gt;
    </code></p></div>

    <p>This will forbid default access to filesystem locations. Add
    appropriate <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> blocks to
    allow access only in those areas you wish. For example,</p>

    <div class="example"><p><code>
      &lt;Directory /usr/users/*/public_html&gt; <br />
        Order Deny,Allow <br />
        Allow from all <br />
      &lt;/Directory&gt; <br />
      &lt;Directory /usr/local/httpd&gt; <br />
        Order Deny,Allow <br />
        Allow from all <br />
      &lt;/Directory&gt;
    </code></p></div>

    <p>Pay particular attention to the interactions of <code class="directive"><a href="../mod/core.html#location">Location</a></code> and <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> directives; for instance, even
    if <code>&lt;Directory /&gt;</code> denies access, a <code>
    &lt;Location /&gt;</code> directive might overturn it.</p>

    <p>Also be wary of playing games with the <code class="directive"><a href="../mod/mod_userdir.html#userdir">UserDir</a></code> directive; setting it to
    something like <code>./</code> 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>

    <div class="example"><p><code>
      UserDir disabled root
    </code></p></div>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="watchyourlogs" id="watchyourlogs">Watching Your Logs</a></h2>

    

    <p>To keep up-to-date with what is actually going on against your server
    you have to check the <a href="../logs.html">Log Files</a>.  Even though
    the log files only reports what has already happened, they will give you
    some understanding of what attacks is thrown against the server and
    allow you to check if the necessary level of security is present.</p>

    <p>A couple of examples:</p>

    <div class="example"><p><code>
      grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br />
      grep "client denied" error_log | tail -n 10
    </code></p></div>

    <p>The first example will list the number of attacks trying to exploit the
    <a href="http://online.securityfocus.com/bid/4876/info/">Apache Tomcat
    Source.JSP Malformed Request Information Disclosure Vulnerability</a>,
    the second example will list the ten last denied clients, for example:</p>

    <div class="example"><p><code>
      [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied
      by server configuration: /usr/local/apache/htdocs/.htpasswd
    </code></p></div>

    <p>As you can see, the log files only report what already has happened, so
    if the client had been able to access the <code>.htpasswd</code> file you
    would have seen something similar to:</p>

    <div class="example"><p><code>
      foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
    </code></p></div>

    <p>in your <a href="../logs.html#accesslog">Access Log</a>. This means
    you probably commented out the following in your server configuration
    file:</p>

    <div class="example"><p><code>
      &lt;Files ~ "^\.ht"&gt; <br />
        Order allow,deny <br />
        Deny from all <br />
      &lt;/Files&gt;
    </code></p></div>

  </div></div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="../en/misc/security_tips.html" title="English">&nbsp;en&nbsp;</a> |
<a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
<a href="../tr/misc/security_tips.html" hreflang="tr" rel="alternate" title="T黵k鏴">&nbsp;tr&nbsp;</a></p>
</div><div id="footer">
<p class="apache">Copyright 2008 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div>
</body></html>