security_tips.html.en

Apache_2.0.59-Openssl_0.9 配置tomcat. Apache_2.0.59-Openssl_0.9 配置tomcat.

    <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 mod_php, mod_perl, mod_tcl, and mod_python, 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 "./" 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 
    allows 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.bar.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.bar.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></p>
</div><div id="footer">
<p class="apache">Copyright 2006 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>