diff options
| author | Erik Abele <erikabele@apache.org> | 2002-08-23 23:02:16 +0200 |
|---|---|---|
| committer | Erik Abele <erikabele@apache.org> | 2002-08-23 23:02:16 +0200 |
| commit | a7273e37bded9b8b709f8b24bf41d94075755df4 (patch) | |
| tree | ec9992e14dba930dc2aa12ca3a6277e025db2f73 /docs/manual/misc/security_tips.html.en | |
| parent | Make version strings work properly with update macro definitions (diff) | |
| download | apache2-a7273e37bded9b8b709f8b24bf41d94075755df4.tar.xz apache2-a7273e37bded9b8b709f8b24bf41d94075755df4.zip | |
New XML.
Submitted by: David Shane Holden <dpejesh@yahoo.com>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96505 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'docs/manual/misc/security_tips.html.en')
| -rw-r--r-- | docs/manual/misc/security_tips.html.en | 261 |
1 files changed, 261 insertions, 0 deletions
diff --git a/docs/manual/misc/security_tips.html.en b/docs/manual/misc/security_tips.html.en new file mode 100644 index 0000000000..abc898f7f8 --- /dev/null +++ b/docs/manual/misc/security_tips.html.en @@ -0,0 +1,261 @@ +<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 |