+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<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>
-
- <ul>
- <li><a href="#serverroot">Permissions on ServerRoot
- Directories</a></li>
-
- <li><a href="#ssi">Server Side Includes</a></li>
-
- <li><a href="#cgi">CGI in General</a></li>
-
- <li><a href="#nsaliasedcgi">Non Script Aliased CGI</a></li>
-
- <li><a href="#saliasedcgi">Script Aliased CGI</a></li>
-
- <li><a href="#systemsettings">Protecting System
- Settings</a></li>
-
- <li><a href="#protectserverfiles">Protect Server Files by
- Default</a></li>
-
- <li><a href="#watchyourlogs">Watching Your Logs</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>
- <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/mpm_common.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:
-
- <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>
-
- <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 id="ssi" name="ssi">Server Side Includes</a></h2>
-
- <p>Server Side Includes (SSI) present a server administrator with
- several potential security risks.</p>
-
- <p>
- The first risk is the increased load on the server. All SSI-enabled
- files have to be parsed by Apache, whether or not there are any SSI
- directives included within the files. While this load increase is
- minor, in a shared server environment it can become significant.</p>
-
- <p>
- SSI files also pose the same risks that are associated with CGI
- scripts in general. Using the "exec cmd" element, SSI-enabled
- files can execute any CGI script or program under the permissions
- of the user and group Apache runs as, as configured in httpd.conf.
- That should definitely give server administrators pause.</p>
-
- <p>
- There are ways to enhance the security of SSI files while still taking
- advantage of the benefits they provide.</p>
-
- <p>To isolate the damage a wayward SSI file can cause, a server
- administrator can enable <a href="../docs/suexec.html"
- >suexec</a> as described in the <a href="#cgi">CGI in General</a>
- section.</p>
-
- <p>
- Enabling SSI for files with .html or .htm extensions can be
- dangerous. This is especially true in a shared, or high traffic,
- server environment. SSI-enabled files should have a separate
- extension, such as the conventional .shtml. This helps keep
- server load at a minimum and allows for easier management of
- risk.</p>
-
-
- <p>Another solution is to disable the ability to run scripts and
- programs from SSI pages. To do this replace <code>Includes</code>
- with <code>IncludesNOEXEC</code> in the <a
- href="../mod/core.html#options">Options</a> directive. Note that
- users may still use <--#include virtual="..." --> to execute
- CGI scripts if these scripts are in directories desginated by a <a
- href="../mod/mod_alias.html#ScriptAlias">ScriptAlias</a>
- directive.</p>
-
- <hr />
-
- <h2><a id="cgi" name="cgi">CGI in General</a></h2>
-
- <p>First of all, you always have to remember that you must trust
- the writers of the CGI scripts/programs or your ability to spot
- potential security holes in CGI, whether they were deliberate or
- accidental. CGI scripts can run essentially arbitrary commands
- on your system with the permissions of the web server user and can
- therefore be extremely dangerous if they are not carefully
- checked.</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="nsaliasedcgi" 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;</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><a id="saliasedcgi" 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>Most sites choose this option over the non script aliased
- CGI approach.</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><Directory /><br />
- AllowOverride None<br />
- </Directory><br />
- </code>
- </blockquote>
-
- <p>This prevents the use of <code>.htaccess</code> files in all
- directories apart from those specifically enabled.</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>
- <Directory />
- Order Deny,Allow
- Deny from all
- </Directory>
-</pre>
-
- <p>This will forbid default access to filesystem locations. Add
- appropriate <a href="../mod/core.html#directory"><samp>
- <Directory></samp></a> blocks to allow access only in
- those areas you wish. For example,</p>
-<pre>
- <Directory /usr/users/*/public_html>
- Order Deny,Allow
- Allow from all
- </Directory>
- <Directory /usr/local/httpd>
- Order Deny,Allow
- Allow from all
- </Directory>
-</pre>
-
- <p>Pay particular attention to the interactions of <a
- href="../mod/core.html#location"><samp>
- <Location></samp></a> and <a
- href="../mod/core.html#directory"><samp>
- <Directory></samp></a> directives; for instance, even if
- <samp><Directory /></samp> denies access, a <samp>
- <Location /></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 disabled root</samp></dd>
- </dl>
-
- <p></p>
- <hr />
-
- <h2><a id="watchyourlogs" name="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 happend,
- 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>
- <ol>
- <li><samp>grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??"
- access_log</samp></li> <li><samp>grep "client denied" error_log |
- tail -n 10 </samp></li>
- </ol>
-
- <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>
-
- <dl>
- <dd><samp>[Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com]
- client denied by server configuration:
- /usr/local/apache/htdocs/.htpasswd</samp></dd>
- </dl>
-
- <p>As you can see, the log files only report what already has
- happend, so if the client had been able to access the
- <samp>.htpasswd</samp> file you would have seen something similar
- to <samp>foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET
- /.htpasswd HTTP/1.1"</samp> in your <a
- href="../logs.html#accesslog">Access Log</a>. This means you
- probably commented out the following in your server configuration
- file:</p>
-
- <pre>
- <Files ~ "^\.ht">
- Order allow,deny
- Deny from all
- </Files>
- </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>
-
- <!--#include virtual="footer.html" -->
- </body>
-</html>
-
-
-
--- /dev/null
+<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><!--
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ This file is generated from xml source: DO NOT EDIT
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ --><title>Security Tips - Apache HTTP Server</title><link href="../style/manual.css" type="text/css" rel="stylesheet"></head><body><blockquote><div align="center"><img src="../images/sub.gif" alt="[APACHE DOCUMENTATION]"><h3>Apache HTTP Server Version 2.0</h3></div><h1 align="center">Security Tips</h1>
+ <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>
+ <ul><li><a href="#serverroot">Permissions on ServerRoot Directories</a></li><li><a href="#ssi">Server Side Includes</a></li><li><a href="#cgi">CGI in General</a></li><li><a href="#nsaliasedcgi">Non Script Aliased CGI</a></li><li><a href="#saliasedcgi">Script Aliased CGI</a></li><li><a href="#systemsettings">Protecting System Settings</a></li><li><a href="#protectserverfiles">Protect Server Files by Default</a></li><li><a href="#watchyourlogs">Watching Your Logs</a></li></ul><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/mpm_common.html#user" class="directive"><code class="directive">User</code></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 /usr/local/apache then it is suggested that you create
+ that directory as root, with commands like these:</p>
+
+ <blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
+ mkdir /usr/local/apache <br>
+ cd /usr/local/apache <br>
+ mkdir bin conf logs <br>
+ chown 0 . bin conf logs <br>
+ chgrp 0 . bin conf logs <br>
+ chmod 755 . bin conf logs
+ </code></td></tr></table></blockquote>
+
+ <p>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:</p>
+
+ <blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
+ cp httpd /usr/local/apache/bin <br>
+ chown 0 /usr/local/apache/bin/httpd <br>
+ chgrp 0 /usr/local/apache/bin/httpd <br>
+ chmod 511 /usr/local/apache/bin/httpd
+ </code></td></tr></table></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>
+
+ <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>
+
+ <h2><a name="ssi">Server Side Includes</a></h2>
+
+
+
+ <p>Server Side Includes (SSI) present a server administrator with
+ several potential security risks.</p>
+
+ <p>The first risk is the increased load on the server. All
+ SSI-enabled files have to be parsed by Apache, whether or not
+ there are any SSI directives included within the files. While this
+ load increase is minor, in a shared server environment it can become
+ significant.</p>
+
+ <p>SSI files also pose the same risks that are associated with CGI
+ scripts in general. Using the "exec cmd" element, SSI-enabled files
+ can execute any CGI script or program under the permissions of the
+ user and group Apache runs as, as configured in httpd.conf.</p>
+
+ <p>There are ways to enhance the security of SSI files while still
+ taking advantage of the benefits they provide.</p>
+
+ <p>To isolate the damage a wayward SSI file can cause, a server
+ administrator can enable <a href="../suexec.html">suexec</a> as
+ described in the <a href="#cgi">CGI in General</a> section</p>
+
+ <p>Enabling SSI for files with .html or .htm extensions can be
+ dangerous. This is especially true in a shared, or high traffic,
+ server environment. SSI-enabled files should have a separate extension,
+ such as the conventional .shtml. This helps keep server load at a
+ minimum and allows for easier management of risk.</p>
+
+ <p>Another solution is to disable the ability to run scripts and
+ programs from SSI pages. To do this replace <code>Includes</code>
+ with <code>IncludesNOEXEC</code> in the <a href="../mod/core.html#options" class="directive"><code class="directive">Options</code></a> directive. Note that users may
+ still use >--#include virtual="..." --< to execute CGI scripts if
+ these scripts are in directories desginated by a <a href="../mod/mod_alias.html#scriptalias" class="directive"><code class="directive">ScriptAlias</code></a> directive.</p>
+
+ <h2><a name="cgi">CGI in General</a></h2>
+
+
+
+ <p>First of all, you always have to remember that you must trust the
+ writers of the CGI scripts/programs or your ability to spot potential
+ security holes in CGI, whether they were deliberate or accidental. CGI
+ scripts can run essentially arbitrary commands on your system with the
+ permissions of the web server user and can therefore be extremely
+ dangerous if they are not carefully checked.</p>
+
+ <p>All the CGI scripts will run as the same user, so they have potential
+ to conflict (accidentally or deliberately) with other scripts e.g. 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://cgiwrap.unixtools.org/">CGIWrap</a>.</p>
+
+ <h2><a name="nsaliasedcgi">Non Script Aliased CGI</a></h2>
+
+
+
+ <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>
+
+ <h2><a name="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>
+
+ <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>
+
+ <p>In the server configuration file, put</p>
+
+ <blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
+ <Directory /> <br>
+ AllowOverride None <br>
+ </Directory>
+ </code></td></tr></table></blockquote>
+
+ <p>This prevents the use of <code>.htaccess</code> files in all
+ directories apart from those specifically enabled.</p>
+
+ <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>
+
+ <blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
+ # cd /; ln -s / public_html <br>
+ Accessing <code>http://localhost/~root/</code>
+ </code></td></tr></table></blockquote>
+
+ <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>
+
+ <blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
+ <Directory /> <br>
+ Order Deny,Allow <br>
+ Deny from all <br>
+ </Directory>
+ </code></td></tr></table></blockquote>
+
+ <p>This will forbid default access to filesystem locations. Add
+ appropriate <a href="../mod/core.html#directory" class="directive"><code class="directive">Directory</code></a> blocks to
+ allow access only in those areas you wish. For example,</p>
+
+ <blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
+ <Directory /usr/users/*/public_html> <br>
+ Order Deny,Allow <br>
+ Allow from all <br>
+ </Directory> <br>
+ <Directory /usr/local/httpd> <br>
+ Order Deny,Allow <br>
+ Allow from all <br>
+ </Directory>
+ </code></td></tr></table></blockquote>
+
+ <p>Pay particular attention to the interactions of <a href="../mod/core.html#location" class="directive"><code class="directive">Location</code></a> and <a href="../mod/core.html#directory" class="directive"><code class="directive">Directory</code></a> directives; for instance, even
+ if <code><Directory /></code> denies access, a <code>
+ <Location /></code> directive might overturn it</p>
+
+ <p>Also be wary of playing games with the <a href="../mod/mod_userdir.html#userdir" class="directive"><code class="directive">UserDir</code></a> 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>
+
+ <blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
+ UserDir disabled root
+ </code></td></tr></table></blockquote>
+
+ <h2><a name="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 happend, 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>
+
+ <blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
+ grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br>
+ grep "client denied" error_log | tail -n 10
+ </code></td></tr></table></blockquote>
+
+ <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>
+
+ <blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
+ [Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied
+ by server configuration: /usr/local/apache/htdocs/.htpasswd
+ </code></td></tr></table></blockquote>
+
+ <p>As you can see, the log files only report what already has happend, so
+ if the client had been able to access the <code>.htpasswd</code> file you
+ would have seen something similar to:</p>
+
+ <blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
+ foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
+ </code></td></tr></table></blockquote>
+
+ <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>
+
+ <blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
+ <Files ~ "^\.ht"> <br>
+ Order allow,deny <br>
+ Deny from all <br>
+ <Files>
+ </code></td></tr></table></blockquote>
+
+ <hr></blockquote><h3 align="center">Apache HTTP Server Version 2.0</h3><a href="./"><img src="../images/index.gif" alt="Index"></a><a href="../"><img src="../images/home.gif" alt="Home"></a></body></html>
\ No newline at end of file
--- /dev/null
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+
+<manualpage>
+ <relativepath href=".." />
+
+ <title>Security Tips</title>
+
+ <summary>
+ <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>
+ </summary>
+
+ <section id="serverroot">
+
+ <title>Permissions on ServerRoot Directories</title>
+
+ <p>In typical operation, Apache is started by the root user, and it
+ switches to the user defined by the <directive
+ module="mpm_common">User</directive> 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 /usr/local/apache then it is suggested that you create
+ that directory as root, with commands like these:</p>
+
+ <example>
+ mkdir /usr/local/apache <br />
+ cd /usr/local/apache <br />
+ mkdir bin conf logs <br />
+ chown 0 . bin conf logs <br />
+ chgrp 0 . bin conf logs <br />
+ chmod 755 . bin conf logs
+ </example>
+
+ <p>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:</p>
+
+ <example>
+ cp httpd /usr/local/apache/bin <br />
+ chown 0 /usr/local/apache/bin/httpd <br />
+ chgrp 0 /usr/local/apache/bin/httpd <br />
+ chmod 511 /usr/local/apache/bin/httpd
+ </example>
+
+ <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>
+
+ </section>
+
+ <section id="ssi">
+
+ <title>Server Side Includes</title>
+
+ <p>Server Side Includes (SSI) present a server administrator with
+ several potential security risks.</p>
+
+ <p>The first risk is the increased load on the server. All
+ SSI-enabled files have to be parsed by Apache, whether or not
+ there are any SSI directives included within the files. While this
+ load increase is minor, in a shared server environment it can become
+ significant.</p>
+
+ <p>SSI files also pose the same risks that are associated with CGI
+ scripts in general. Using the "exec cmd" element, SSI-enabled files
+ can execute any CGI script or program under the permissions of the
+ user and group Apache runs as, as configured in httpd.conf.</p>
+
+ <p>There are ways to enhance the security of SSI files while still
+ taking advantage of the benefits they provide.</p>
+
+ <p>To isolate the damage a wayward SSI file can cause, a server
+ administrator can enable <a href="../suexec.html">suexec</a> as
+ described in the <a href="#cgi">CGI in General</a> section</p>
+
+ <p>Enabling SSI for files with .html or .htm extensions can be
+ dangerous. This is especially true in a shared, or high traffic,
+ server environment. SSI-enabled files should have a separate extension,
+ such as the conventional .shtml. This helps keep server load at a
+ minimum and allows for easier management of risk.</p>
+
+ <p>Another solution is to disable the ability to run scripts and
+ programs from SSI pages. To do this replace <code>Includes</code>
+ with <code>IncludesNOEXEC</code> in the <directive
+ module="core">Options</directive> directive. Note that users may
+ still use >--#include virtual="..." --< to execute CGI scripts if
+ these scripts are in directories desginated by a <directive
+ module="mod_alias">ScriptAlias</directive> directive.</p>
+
+ </section>
+
+ <section id="cgi">
+
+ <title>CGI in General</title>
+
+ <p>First of all, you always have to remember that you must trust the
+ writers of the CGI scripts/programs or your ability to spot potential
+ security holes in CGI, whether they were deliberate or accidental. CGI
+ scripts can run essentially arbitrary commands on your system with the
+ permissions of the web server user and can therefore be extremely
+ dangerous if they are not carefully checked.</p>
+
+ <p>All the CGI scripts will run as the same user, so they have potential
+ to conflict (accidentally or deliberately) with other scripts e.g. 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://cgiwrap.unixtools.org/">CGIWrap</a>.</p>
+
+ </section>
+
+ <section id="nsaliasedcgi">
+
+ <title>Non Script Aliased CGI</title>
+
+ <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>
+
+ </section>
+
+ <section id="saliasedcgi">
+
+ <title>Script Aliased CGI</title>
+
+ <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>
+
+ </section>
+
+ <section id="systemsettings">
+
+ <title>Protecting System Settings</title>
+
+ <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>
+
+ <example>
+ <Directory /> <br />
+ AllowOverride None <br />
+ </Directory>
+ </example>
+
+ <p>This prevents the use of <code>.htaccess</code> files in all
+ directories apart from those specifically enabled.</p>
+
+ </section>
+
+ <section id="protectserverfiles">
+
+ <title>Protect Server Files by Default</title>
+
+ <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>
+
+ <example>
+ # cd /; ln -s / public_html <br />
+ Accessing <code>http://localhost/~root/</code>
+ </example>
+
+ <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>
+
+ <example>
+ <Directory /> <br />
+ Order Deny,Allow <br />
+ Deny from all <br />
+ </Directory>
+ </example>
+
+ <p>This will forbid default access to filesystem locations. Add
+ appropriate <directive module="core">Directory</directive> blocks to
+ allow access only in those areas you wish. For example,</p>
+
+ <example>
+ <Directory /usr/users/*/public_html> <br />
+ Order Deny,Allow <br />
+ Allow from all <br />
+ </Directory> <br />
+ <Directory /usr/local/httpd> <br />
+ Order Deny,Allow <br />
+ Allow from all <br />
+ </Directory>
+ </example>
+
+ <p>Pay particular attention to the interactions of <directive
+ module="core">Location</directive> and <directive
+ module="core">Directory</directive> directives; for instance, even
+ if <code><Directory /></code> denies access, a <code>
+ <Location /></code> directive might overturn it</p>
+
+ <p>Also be wary of playing games with the <directive
+ module="mod_userdir">UserDir</directive> 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>
+
+ <example>
+ UserDir disabled root
+ </example>
+
+ </section>
+
+ <section id="watchyourlogs">
+
+ <title>Watching Your Logs</title>
+
+ <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 happend, 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>
+
+ <example>
+ grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br />
+ grep "client denied" error_log | tail -n 10
+ </example>
+
+ <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>
+
+ <example>
+ [Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied
+ by server configuration: /usr/local/apache/htdocs/.htpasswd
+ </example>
+
+ <p>As you can see, the log files only report what already has happend, so
+ if the client had been able to access the <code>.htpasswd</code> file you
+ would have seen something similar to:</p>
+
+ <example>
+ foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
+ </example>
+
+ <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>
+
+ <example>
+ <Files ~ "^\.ht"> <br />
+ Order allow,deny <br />
+ Deny from all <br />
+ <Files>
+ </example>
+
+ </section>
+
+</manualpage>
projects / apache / commitdiff