APACHE_1_3_42/htdocs/manual/misc/security_tips.html - httpd - Git at Google

 <!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 &lt;--#include virtual="..." --&gt; 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>&lt;Directory /&gt;<br />
        AllowOverride None<br />
        &lt;/Directory&gt;<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>
  &lt;Directory /&gt;
      Order Deny,Allow
      Deny from all
  &lt;/Directory&gt;
 </pre>

     <p>This will forbid default access to filesystem locations. Add
     appropriate <a
     href="../mod/core.html#directory"><samp>&lt;Directory&gt;</samp></a>
     blocks to allow access only in those areas you wish. For
     example,</p>
 <pre>
  &lt;Directory /usr/users/*/public_html&gt;
      Order Deny,Allow
      Allow from all
  &lt;/Directory&gt;
  &lt;Directory /usr/local/httpd&gt;
      Order Deny,Allow
      Allow from all
  &lt;/Directory&gt;
 </pre>

     <p>Pay particular attention to the interactions of <a
     href="../mod/core.html#location"><samp>&lt;Location&gt;</samp></a>
     and <a
     href="../mod/core.html#directory"><samp>&lt;Directory&gt;</samp></a>
     directives; for instance, even if <samp>&lt;Directory
     /&gt;</samp> denies access, a <samp>&lt;Location /&gt;</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&nbsp;disabled&nbsp;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>
	<!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>