3.4 Securing Apache

As we go through the book, we discuss security issues involved with giving people access to a low port on your machine, but we can't go into all the details ”that would result in an almost 600-page book Hacking Linux Exposed [Hatch+ 02].

Most of the following configuration directives are optional; you can do as you wish for your setup, but you should be aware of the choices you're making. Remember, no decision is also a decision.

3.4.1 Set User and Group

Make sure the user and group are set to:

 User apache  Group apache 

The user and group could be apache or bozo or whatever. The important thing is that Apache doesn't run as root , which, if Apache were cracked, could allow someone to crack your box from the root Apache account (this is called rooting your box and is as bad as it gets). Red Hat defaults to apache . You could instead create a new user with useradd , with a locked account to run Apache, if you wish. For now, we recommend that you stay with the default. ^[8]

^[8] You might notice that if you do a ps aux grep httpd , the first process listed is owned by root ” this process binds the low port and spawns the apache -owned processes that actually handle the httpd requests .

3.4.2 Remove Online Manuals

If you did the default Red Hat install (as suggested in Chapter 2), the Apache manuals were installed in the html directory /var/www/html/manual/ , which can be accessed via file:///var/www/html/manual/ or http://localhost/manual/ , or www.your_web_site.com/manual/ .

If you leave these on your machine, a cracker could gain information about your machine and installation (such as the server version) by simply hitting this directory. It's a good idea to move the manuals someplace out of the web path :

 #  mv /var/www/html/manual /usr/doc/apache-1.3.24/  

Now you have the manual available to you (put the URL file:///usr/doc/apache-1.3.24/ in your browser), but it will not be served by Apache to any would-be cracker.

3.4.3 Consider Allowing Access to Local Documentation

Red Hat defines the following by default:

 Alias /doc/ /usr/share/doc/  <Location /doc>    order deny,allow    deny from all    allow from localhost .localdomain    Options Indexes FollowSymLinks  </Location> 

This directive allows access to the local documentation in /usr/share/doc . Even though this directive allows access to these files only from localhost and .localdomain , we suggest you don't allow Apache to serve up these documents, so comment out this directive.

3.4.4 Don't Allow public_html Web Sites (Unless You Want To)

The mod_user module allows users to serve Web content without having access to the main web directory tree. For example, the user jrl could create a directory called public_html in his home directory, which would be available at the URL http:// servername /~jrl/ .

You may want to consider whether to allow users (if you have any) to create these public_html sites. Nothing is inherently wrong with allowing public_html , but it should be something you decide to allow rather than just letting it happen by default. Quite a few directives are involved in the configuration of this feature, but if you locate the line:

 UserDir public_html 

and modify it as follows :

 UserDir disabled 

this feature is turned off.

3.4.5 .htaccess

You can allow access control of individual directories with the following configuration module:

 AccessFileName .htaccess  <Files ~ "  ^  \.ht">      Order allow,deny      Deny from all  </Files> 

The AccessFileName directive defines the name of the file Apache looks at to determine whether the client can view your web page or other parts of your site. The Files directive says that files beginning with .ht can't be seen by anyone even if they type the filename into their browser. Order and Deny determine how access is controlled. Sequence is important; the last command takes precedent. The rule here is to deny everything except that specifically allowed, a good rule of thumb. More on .htaccess later.

3.4.6 Remove server-status and server- info

The following directives allow clients to find out information about your machine and server. There's no reason to give crackers any more information than necessary. Comment this out for now:

 #<Location /server-status>  #    SetHandler server-status  #    Order deny,allow  #    Deny from all  #    Allow from .your_domain.com  #</Location> 

and this:

 #<Location /server-info>  #    SetHandler server-info  #    Order deny,allow  #    Deny from all  #    Allow from .your_domain.com  #</Location> 

If you decide to allow this information to be given out (perhaps for debugging from a remote site), change .your_domain.com to the specific sites you want to have access.

Disallow Symbolic Links

Allowing symbolic links from within your webserver document tree to other directories can cause content control problems. We suggest that you do not allow symbolic links unless you have to. ^[9] To disallow symbolic links, be sure that the Options directives do not include FollowSymLinks .

^[9] Symbolic links are good for making links to large files instead of having multiple copies, but bad because J. Random Luser could make a link to a sensitive file ”for instance, /etc/passwd . Disk space is cheap. Make copies.

Do Not Allow Directory Indexes

If you add Indexes to the Options directive, clients can access directory listings if they type in a directory with no index.html ”for example, www.example.com/directory/ . This is generally a bad idea because it lets people look at the directory structure, perhaps to see files that you didn't want served up ” .htaccess files, old versions, backups . Better to let them see only the files that you decided to serve up via the web page. Be sure Indexes is not part of your Options directive.

Don't Be a Proxy Server Unless You Want to Be

If you don't want to be a proxy server (if you don't know what this means, you don't want to be a proxy server), make sure the following sections are commented out:

 #LoadModule proxy_module        modules/libproxy.so 

and:

 #AddModule mod_proxy.c 

and:

 #<IfModule mod_proxy.c>  #ProxyRequests On  #  #<Directory proxy:*>  #    Order deny,allow  #    Deny from all  #    Allow from .your_domain.com  #</Directory>  #  # Enable/disable the handling of HTTP/1.1 "Via:" headers.  # ("Full" adds the server version; "Block" removes  # all outgoing Via: headers)  # Set to one of: Off  On  Full  Block  #  #ProxyVia On  #  # To enable the cache as well, edit and uncomment  # the following lines:  # (no caching without CacheRoot)  #  #CacheRoot "/var/cache/httpd"  #CacheSize 5  #CacheGcInterval 4  #CacheMaxExpire 24  #CacheLastModifiedFactor 0.1  #CacheDefaultExpire 1  #NoCache a_domain.com another_domain.edu joes.garage_sale.com  #</IfModule> 

Disable CGI Programs

We will talk more about CGI later, but for now, disable any CGI scripts that were shipped with Apache, as follows:

 #  chmod -x /var/www/cgi-bin/*  

Better yet, remove them:

 #  rm -rf /var/www/cgi-bin/*  

And don't download CGI scripts from the Web. Whether they are malicious or simply badly written, CGI scripts are an excellent way to get your system cracked. In Chapter 7, you'll learn to write your own scripts and how to avoid common problems with them, so that even if you do use a script from someplace such as the Comprehensive Perl Archive Network (CPAN) at www.cpan.org, you can vet it for security.

Reload the Configuration File

Now that we are finished securing Apache, let's reload the configuration file as follows:

 #  /etc/init.d/httpd graceful