slive 01/10/02 08:40:07 Modified: htdocs/manual/misc security_tips.html Log: Tidy. Submitted by: Allan Liska <[EMAIL PROTECTED]> Revision Changes Path 1.25 +234 -222 httpd-docs-1.3/htdocs/manual/misc/security_tips.html Index: security_tips.html =================================================================== RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/misc/security_tips.html,v retrieving revision 1.24 retrieving revision 1.25 diff -u -d -b -u -r1.24 -r1.25 --- security_tips.html 2001/10/02 15:37:34 1.24 +++ security_tips.html 2001/10/02 15:40:07 1.25 @@ -1,200 +1,221 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> -<HTML> -<HEAD> -<TITLE>Apache HTTP Server: Security Tips</TITLE> -</HEAD> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> -<!-- 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> +<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" --> -<ul> -<li><a href="#serverroot">Permissions on ServerRoot Directories</a></li> + <h1 align="CENTER">Security Tips for Server Configuration</h1> -<li><a href="#ssi">Server Side Includes</a> + <ul> + <li><a href="#serverroot">Permissions on ServerRoot + Directories</a></li> -<li><a href="#nsaliasedcgi">Non Script Aliased CGI</a></li> + <li><a href="#ssi">Server Side Includes</a></li> -<li><a href="#saliasedcgi">Script Aliased CGI</a></li> + <li><a href="#nsaliasedcgi">Non Script Aliased CGI</a></li> -<li><a href="#cgi">CGI in General</a></li> + <li><a href="#saliasedcgi">Script Aliased CGI</a></li> -<li><a href="#systemsettings">Protecting System Settings</a></li> + <li><a href="#cgi">CGI in General</a></li> -<li><a href="#protectserverfiles">Protect Server Files by Default</a></li> -</ul> + <li><a href="#systemsettings">Protecting System + Settings</a></li> -<HR> + <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>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 /> -<HR> + <h2><a id="serverroot" name="serverroot">Permissions on + ServerRoot Directories</a></h2> -<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/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 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>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 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> + <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: +</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> + <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> +</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>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 name="ssi">Server Side Includes</a></h2> -<P>Server side includes (SSI) can be configured so that users can execute -arbitrary programs on the server. That thought alone should send a shiver -down the spine of any sys-admin.<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 /> -One solution is to disable that part of SSI. To do that you use the -IncludesNOEXEC option to the <A HREF="../mod/core.html#options">Options</A> -directive.<P> + <h2><a id="ssi" name="ssi">Server Side Includes</a></h2> -<HR> + <p>Server side includes (SSI) can be configured so that users + can execute arbitrary programs on the server. That thought + alone should send a shiver down the spine of any sys-admin.</p> -<h2><a 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; -<OL> - <LI>You trust your users not to write scripts which will deliberately or -accidentally expose your system to an attack. - <LI>You consider security at your site to be so feeble in other areas, as to -make one more potential hole irrelevant. - <LI>You have no users, and nobody ever visits your server. -</OL><P> -<HR> + <p>One solution is to disable that part of SSI. To do that you + use the IncludesNOEXEC option to the <a + href="../mod/core.html#options">Options</a> directive.</p> -<h2><a 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></p> + <hr /> -Most sites choose this option over the non script aliased CGI approach.<P> + <h2><a id="nsaliasedcgi" name="nsaliasedcgi">Non Script Aliased + CGI</a></h2> -<HR> -<h2><a 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>Allowing users to execute <strong>CGI</strong> scripts in + any directory should only be considered if;</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> + <ol> + <li>You trust your users not to write scripts which will + deliberately or accidentally expose your system to an + attack.</li> -<HR> + <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 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> + <h2><a id="saliasedcgi" name="saliasedcgi">Script Aliased + CGI</a></h2> -In the server configuration file, put -<BLOCKQUOTE><CODE> -<Directory /> <BR> -AllowOverride None <BR> -Options None <BR> -Allow from all <BR> -</Directory> <BR> -</CODE></BLOCKQUOTE> + <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> -Then setup for specific directories<P> + <p>Most sites choose this option over the non script aliased + CGI approach.</p> -This stops all overrides, Includes and accesses in all directories apart -from those named.<P> -<HR> -<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> -<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> + <p></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> + + <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 /> + Options None<br /> + Allow from all<br /> + </Directory><br /> + </code> + </blockquote> + Then setup for specific directories + + <p>This stops all overrides, Includes and accesses in all + directories apart from those named.</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> +</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 @@ -203,46 +224,37 @@ 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> +</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>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> + <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> -<!--#include virtual="footer.html" --> -</BODY> -</HTML> + <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> +
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
