diff options
Diffstat (limited to 'APACHE_1_3_42/htdocs/manual/misc/security_tips.html')
| -rw-r--r-- | APACHE_1_3_42/htdocs/manual/misc/security_tips.html | 302 |
1 files changed, 302 insertions, 0 deletions
diff --git a/APACHE_1_3_42/htdocs/manual/misc/security_tips.html b/APACHE_1_3_42/htdocs/manual/misc/security_tips.html new file mode 100644 index 0000000000..fb5d2849bc --- /dev/null +++ b/APACHE_1_3_42/htdocs/manual/misc/security_tips.html @@ -0,0 +1,302 @@ +<!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="#nsaliasedcgi">Non Script Aliased CGI</a></li> + + <li><a href="#saliasedcgi">Script Aliased CGI</a></li> + + <li><a href="#cgi">CGI in General</a></li> + + <li><a href="#dynamic">Other sources of dynamic content</a></li> + + <li><a href="#systemsettings">Protecting System + Settings</a></li> + + <li><a href="#protectserverfiles">Protect Server Files by + Default</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/core.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 also 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="../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 + designated by a <a + href="../mod/mod_alias.html#scriptalias">ScriptAlias</a> + directive.</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> + <hr /> + + <h2><a id="cgi" name="cgi">CGI in General</a></h2> + + <p>Always remember that you must trust the writers of the CGI + script/programs or your ability to spot potential security + holes in CGI, whether they were deliberate or accidental.</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> + <hr /> + + <h2><a id="dynamic" name="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 <a href="../mod/core.html#user">User</a> +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> +<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> + <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> + + <p><!--#include virtual="footer.html" --></p> + </body> +</html> + |