1<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 3 4<html xmlns="http://www.w3.org/1999/xhtml"> 5 <head> 6 <meta name="generator" content="HTML Tidy, see www.w3.org" /> 7 8 <title>Apache HTTP Server: Security Tips</title> 9 </head> 10 <!-- Background white, links blue (unvisited), navy (visited), red (active) --> 11 12 <body bgcolor="#FFFFFF" text="#000000" link="#0000FF" 13 vlink="#000080" alink="#FF0000"> 14 <div align="CENTER"> 15 <img src="../images/sub.gif" alt="[APACHE DOCUMENTATION]" /> 16 17 <h3>Apache HTTP Server Version 1.3</h3> 18 </div> 19 20 21 <h1 align="CENTER">Security Tips for Server Configuration</h1> 22 23 <ul> 24 <li><a href="#serverroot">Permissions on ServerRoot 25 Directories</a></li> 26 27 <li><a href="#ssi">Server Side Includes</a></li> 28 29 <li><a href="#nsaliasedcgi">Non Script Aliased CGI</a></li> 30 31 <li><a href="#saliasedcgi">Script Aliased CGI</a></li> 32 33 <li><a href="#cgi">CGI in General</a></li> 34 35 <li><a href="#dynamic">Other sources of dynamic content</a></li> 36 37 <li><a href="#systemsettings">Protecting System 38 Settings</a></li> 39 40 <li><a href="#protectserverfiles">Protect Server Files by 41 Default</a></li> 42 </ul> 43 <hr /> 44 45 <p>Some hints and tips on security issues in setting up a web 46 server. Some of the suggestions will be general, others 47 specific to Apache.</p> 48 <hr /> 49 50 <h2><a id="serverroot" name="serverroot">Permissions on 51 ServerRoot Directories</a></h2> 52 53 <p>In typical operation, Apache is started by the root user, 54 and it switches to the user defined by the <a 55 href="../mod/core.html#user"><strong>User</strong></a> 56 directive to serve hits. As is the case with any command that 57 root executes, you must take care that it is protected from 58 modification by non-root users. Not only must the files 59 themselves be writeable only by root, but also the 60 directories and parents of all directories. For example, if 61 you choose to place ServerRoot in 62 <code>/usr/local/apache</code> then it is suggested that you 63 create that directory as root, with commands like these:</p> 64 65 <blockquote> 66<pre> 67 mkdir /usr/local/apache 68 cd /usr/local/apache 69 mkdir bin conf logs 70 chown 0 . bin conf logs 71 chgrp 0 . bin conf logs 72 chmod 755 . bin conf logs 73</pre> 74 </blockquote> 75 It is assumed that /, /usr, and /usr/local are only modifiable 76 by root. When you install the httpd executable, you should 77 ensure that it is similarly protected: 78 79 <blockquote> 80<pre> 81 cp httpd /usr/local/apache/bin 82 chown 0 /usr/local/apache/bin/httpd 83 chgrp 0 /usr/local/apache/bin/httpd 84 chmod 511 /usr/local/apache/bin/httpd 85</pre> 86 </blockquote> 87 88 <p>You can create an htdocs subdirectory which is modifiable by 89 other users -- since root never executes any files out of 90 there, and shouldn't be creating files in there.</p> 91 92 <p>If you allow non-root users to modify any files that root 93 either executes or writes on then you open your system to root 94 compromises. For example, someone could replace the httpd 95 binary so that the next time you start it, it will execute some 96 arbitrary code. If the logs directory is writeable (by a 97 non-root user), someone could replace a log file with a symlink 98 to some other system file, and then root might overwrite that 99 file with arbitrary data. If the log files themselves are 100 writeable (by a non-root user), then someone may be able to 101 overwrite the log itself with bogus data.</p> 102 <hr /> 103 104 <h2><a id="ssi" name="ssi">Server Side Includes</a></h2> 105 106 <p>Server Side Includes (SSI) present a server administrator 107 with several potential security risks.</p> 108 109 <p>The first risk is the increased load on the server. All 110 SSI-enabled files have to be parsed by Apache, whether or not 111 there are any SSI directives included within the files. While 112 this load increase is minor, in a shared server environment it 113 can become significant.</p> 114 115 <p>SSI files also pose the same risks that are associated with 116 CGI scripts in general. Using the "exec cmd" element, 117 SSI-enabled files can execute any CGI script or program under 118 the permissions of the user and group Apache runs as, as 119 configured in httpd.conf. That should definitely give server 120 administrators pause.</p> 121 122 <p>There are ways to enhance the security of SSI files while 123 still taking advantage of the benefits they provide.</p> 124 125 <p>To isolate the damage a wayward SSI file can cause, a server 126 administrator can enable <a 127 href="../suexec.html">suexec</a> as described in the <a 128 href="#cgi">CGI in General</a> section.</p> 129 130 <p>Enabling SSI for files with .html or .htm extensions can be 131 dangerous. This is especially true in a shared, or high 132 traffic, server environment. SSI-enabled files should have a 133 separate extension, such as the conventional .shtml. This helps 134 keep server load at a minimum and allows for easier management 135 of risk.</p> 136 137 <p>Another solution is to disable the ability to run scripts 138 and programs from SSI pages. To do this, replace 139 <code>Includes</code> with <code>IncludesNOEXEC</code> in the 140 <a href="../mod/core.html#options">Options</a> directive. Note 141 that users may still use <--#include virtual="..." --> to 142 execute CGI scripts if these scripts are in directories 143 designated by a <a 144 href="../mod/mod_alias.html#scriptalias">ScriptAlias</a> 145 directive.</p> 146 <hr /> 147 148 <h2><a id="nsaliasedcgi" name="nsaliasedcgi">Non Script Aliased 149 CGI</a></h2> 150 151 <p>Allowing users to execute <strong>CGI</strong> scripts in 152 any directory should only be considered if;</p> 153 154 <ol> 155 <li>You trust your users not to write scripts which will 156 deliberately or accidentally expose your system to an 157 attack.</li> 158 159 <li>You consider security at your site to be so feeble in 160 other areas, as to make one more potential hole 161 irrelevant.</li> 162 163 <li>You have no users, and nobody ever visits your 164 server.</li> 165 </ol> 166 <hr /> 167 168 <h2><a id="saliasedcgi" name="saliasedcgi">Script Aliased 169 CGI</a></h2> 170 171 <p>Limiting <strong>CGI</strong> to special directories gives 172 the admin control over what goes into those directories. This 173 is inevitably more secure than non script aliased CGI, but 174 <strong>only if users with write access to the directories are 175 trusted</strong> or the admin is willing to test each new CGI 176 script/program for potential security holes.</p> 177 178 <p>Most sites choose this option over the non script aliased 179 CGI approach.</p> 180 <hr /> 181 182 <h2><a id="cgi" name="cgi">CGI in General</a></h2> 183 184 <p>Always remember that you must trust the writers of the CGI 185 script/programs or your ability to spot potential security 186 holes in CGI, whether they were deliberate or accidental.</p> 187 188 <p>All the CGI scripts will run as the same user, so they have 189 potential to conflict (accidentally or deliberately) with other 190 scripts <em>e.g.</em> User A hates User B, so he writes a 191 script to trash User B's CGI database. One program which can be 192 used to allow scripts to run as different users is <a 193 href="../suexec.html">suEXEC</a> which is included with Apache 194 as of 1.2 and is called from special hooks in the Apache server 195 code. Another popular way of doing this is with <a 196 href="http://wwwcgi.umr.edu/~cgiwrap/">CGIWrap</a>.</p> 197 <hr /> 198 199 <h2><a id="dynamic" name="dynamic">Other sources of dynamic 200 content</a></h2> 201 202<p>Embedded scripting options which run as part of the server itself, such 203as mod_php, mod_perl, mod_tcl, and mod_python, run under the identity of 204the server itself (see the <a href="../mod/core.html#user">User</a> 205directive), and therefore scripts executed by these engines 206potentially can access anything the server user can. Some scripting 207engines may provide restrictions, but it is better to be safe and assume 208not.</p> 209<hr /> 210 211 <h2><a id="systemsettings" name="systemsettings">Protecting 212 System Settings</a></h2> 213 214 <p>To run a really tight ship, you'll want to stop users from 215 setting up <code>.htaccess</code> files which can override 216 security features you've configured. Here's one way to do 217 it.</p> 218 219 <p>In the server configuration file, put</p> 220 221 <blockquote> 222 <code><Directory /><br /> 223 AllowOverride None<br /> 224 </Directory><br /> 225 </code> 226 </blockquote> 227 228 <p>This prevents the use of <code>.htaccess</code> files in all 229 directories apart from those specifically enabled.</p> 230 <hr /> 231 232 <h2><a id="protectserverfiles" 233 name="protectserverfiles">Protect Server Files by 234 Default</a></h2> 235 236 <p>One aspect of Apache which is occasionally misunderstood is 237 the feature of default access. That is, unless you take steps 238 to change it, if the server can find its way to a file through 239 normal URL mapping rules, it can serve it to clients.</p> 240 241 <p>For instance, consider the following example:</p> 242 243 <ol> 244 <li><samp># cd /; ln -s / public_html</samp></li> 245 246 <li>Accessing <samp>http://localhost/~root/</samp></li> 247 </ol> 248 249 <p>This would allow clients to walk through the entire 250 filesystem. To work around this, add the following block to 251 your server's configuration:</p> 252<pre> 253 <Directory /> 254 Order Deny,Allow 255 Deny from all 256 </Directory> 257</pre> 258 259 <p>This will forbid default access to filesystem locations. Add 260 appropriate <a 261 href="../mod/core.html#directory"><samp><Directory></samp></a> 262 blocks to allow access only in those areas you wish. For 263 example,</p> 264<pre> 265 <Directory /usr/users/*/public_html> 266 Order Deny,Allow 267 Allow from all 268 </Directory> 269 <Directory /usr/local/httpd> 270 Order Deny,Allow 271 Allow from all 272 </Directory> 273</pre> 274 275 <p>Pay particular attention to the interactions of <a 276 href="../mod/core.html#location"><samp><Location></samp></a> 277 and <a 278 href="../mod/core.html#directory"><samp><Directory></samp></a> 279 directives; for instance, even if <samp><Directory 280 /></samp> denies access, a <samp><Location /></samp> 281 directive might overturn it.</p> 282 283 <p>Also be wary of playing games with the <a 284 href="../mod/mod_userdir.html#userdir">UserDir</a> directive; 285 setting it to something like <samp>"./"</samp> would have the 286 same effect, for root, as the first example above. If you are 287 using Apache 1.3 or above, we strongly recommend that you 288 include the following line in your server configuration 289 files:</p> 290 291 <dl> 292 <dd><samp>UserDir disabled root</samp></dd> 293 </dl> 294 <hr /> 295 296 <p>Please send any other useful security tips to The Apache 297 Group by filling out a <a 298 href="http://bugs.apache.org/">problem report</a>. If you are 299 confident you have found a security bug in the Apache source 300 code itself, <a 301 href="http://httpd.apache.org/bug_report.html">please let us 302 know</a>.</p> 303 304 <p> <hr /> 305 306 <h3 align="CENTER">Apache HTTP Server Version 1.3</h3> 307 <a href="./"><img src="../images/index.gif" alt="Index" /></a> 308 <a href="../"><img src="../images/home.gif" alt="Home" /></a> 309</p> 310 </body> 311</html> 312 313
