slive 01/10/02 08:40:07 Modified: htdocs/manual/misc security_tips.html Log: Tidy. Submitted by: Allan Liska 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 @@ - - - -Apache HTTP Server: Security Tips - + - - - -

Security Tips for Server Configuration

+ + + + Apache HTTP Server: Security Tips + + + + - +
-

Some hints and tips on security issues in setting up a web server. Some of -the suggestions will be general, others specific to Apache. +

Some hints and tips on security issues in setting up a web + server. Some of the suggestions will be general, others + specific to Apache.

+
-
+

Permissions on + ServerRoot Directories

-

Permissions on ServerRoot Directories

-

In typical operation, Apache is started by the root -user, and it switches to the user defined by the User 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: +

In typical operation, Apache is started by the root user, + and it switches to the user defined by the User + 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:

-
  +    
+
       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
  -
- -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: +
+
+ 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: -
  +    
+
       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
  -
+
+
-

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. +

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.

-

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. -

-


-

Server Side Includes

-

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.

+

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.

+
-One solution is to disable that part of SSI. To do that you use the -IncludesNOEXEC option to the Options -directive.

+

Server Side Includes

-
+

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.

-

Non Script Aliased CGI

-

Allowing users to execute CGI scripts in any directory -should only -be considered if; -

    -
  1. You trust your users not to write scripts which will deliberately or -accidentally expose your system to an attack. -
  2. You consider security at your site to be so feeble in other areas, as to -make one more potential hole irrelevant. -
  3. You have no users, and nobody ever visits your server. -

-


+

One solution is to disable that part of SSI. To do that you + use the IncludesNOEXEC option to the Options directive.

-

Script Aliased CGI

-

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.

+

+
-Most sites choose this option over the non script aliased CGI approach.

+

Non Script Aliased + CGI

-
-

CGI in General

-

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.

+

Allowing users to execute CGI scripts in + any directory should only be considered if;

-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 suEXEC 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 -CGIWrap.

+

    +
  1. You trust your users not to write scripts which will + deliberately or accidentally expose your system to an + attack.
  2. -
    +
  3. You consider security at your site to be so feeble in + other areas, as to make one more potential hole + irrelevant.
  4. +
  5. You have no users, and nobody ever visits your + server.
  6. +
+
-

Protecting System Settings

-

To run a really tight ship, you'll want to stop users from setting -up .htaccess files which can override security features -you've configured. Here's one way to do it...

+

Script Aliased + CGI

-In the server configuration file, put -
-<Directory />
-AllowOverride None
-Options None
-Allow from all
-</Directory>
-
+

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.

-Then setup for specific directories

+

Most sites choose this option over the non script aliased + CGI approach.

-This stops all overrides, Includes and accesses in all directories apart -from those named.

-


-

-Protect Server Files by Default -

-

-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. -

-

-For instance, consider the following example: -

-
    -
  1. # cd /; ln -s / public_html -
  2. -
  3. Accessing http://localhost/~root/ -
  4. -
-

-This would allow clients to walk through the entire filesystem. To work -around this, add the following block to your server's configuration: -

-
  +    

+
+ +

CGI in General

+ +

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.

+ +

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 suEXEC 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 CGIWrap.

+ +

+
+ +

Protecting + System Settings

+ +

To run a really tight ship, you'll want to stop users from + setting up .htaccess files which can override + security features you've configured. Here's one way to do + it...

+ +

In the server configuration file, put

+ +
+ <Directory />
+ AllowOverride None
+ Options None
+ Allow from all
+ </Directory>
+
+
+ Then setup for specific directories + +

This stops all overrides, Includes and accesses in all + directories apart from those named.

+
+ +

+ Protect Server Files by Default

+ +

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.

+ +

For instance, consider the following example:

+ +
    +
  1. # cd /; ln -s / public_html
  2. + +
  3. Accessing http://localhost/~root/
  4. +
+ +

This would allow clients to walk through the entire + filesystem. To work around this, add the following block to + your server's configuration:

+
    <Directory />
        Order Deny,Allow
        Deny from all
    </Directory>
  -
-

-This will forbid default access to filesystem locations. Add -appropriate -<Directory> -blocks to allow access only -in those areas you wish. For example, -

-
  +
+ +

This will forbid default access to filesystem locations. Add + appropriate + <Directory> blocks to allow access only in + those areas you wish. For example,

+
    <Directory /usr/users/*/public_html>
        Order Deny,Allow
        Allow from all
  @@ -203,46 +224,37 @@
        Order Deny,Allow
        Allow from all
    </Directory>
  -
-

-Pay particular attention to the interactions of -<Location> -and -<Directory> -directives; for instance, even if <Directory /> -denies access, a <Location /> directive might -overturn it. -

-

-Also be wary of playing games with the -UserDir -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: -

-
-
UserDir disabled root -
-
+
-
-

Please send any other useful security tips to The Apache Group -by filling out a -problem report. -If you are confident you have found a security bug in the Apache -source code itself, please let us -know. +

Pay particular attention to the interactions of + <Location> and + <Directory> directives; for instance, even if + <Directory /> denies access, a + <Location /> directive might overturn it.

-

+

Also be wary of playing games with the UserDir 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:

- - - +
+
UserDir disabled root
+
+
+ +

Please send any other useful security tips to The Apache + Group by filling out a + problem report. If you are confident you have found a + security bug in the Apache source code itself, please let us + know.

+ +

+ + + --------------------------------------------------------------------- To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org For additional commands, e-mail: apache-docs-help@apache.org