Home arrow Apache arrow Page 8 - Secure Installation and Configuration

Don’t Give Extra Information Away - Apache

This chapter provides Apache downloading steps and cautionary tips. Mobily recommends compiling most of the modules dynamically, and leaving the main server stripped to the bones. He covers the free tool Nikto and how to use it. Also see why he says to disable the TRACE method. (From the book Hardening Apache by Tony Mobily, Apress, 2004, ISBN: 1590593782.)

TABLE OF CONTENTS:
  1. Secure Installation and Configuration
  2. Asymmetric Encryption and GnuPG
  3. GnuPG and Apache Signatures
  4. Checking and Installing Apache
  5. Running Apache and Testing it with Nikto
  6. Secure Configuration
  7. File Permissions
  8. Don’t Give Extra Information Away
  9. Apache and SSL
  10. Generate Certificates
  11. Configuration
By: Apress Publishing
Rating: starstarstarstarstar / 31
August 17, 2004

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

Don’t let people know what version of Apache you are running by the HTTP response header. You can easily do this with this option (this will only display Apache, rather than Apache/2.0.48 (Unix)):

ServerTokens Minimal

Disable the Method TRACE

This is a controversial issue at the moment, because many system administrators are ready to swear that it’s only a client-side issue. However, it’s better to be safe than sorry. TRACE is supposed to make it possible to execute cross-site scripting attacks (see Chapter 4). You can disable TRACE with the following mod_rewrite directives (more on mod_rewrite in the next section):

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* [F]

Remember to place these directives in a <Location /> container, or outside all containers.

Running Nikto Again

You should now run Nikto again and see if the report is any different. Here is the result in my case:

[root@merc nikto-1.30]# ./nikto -h localhost
---------------------------------------------------------
- Nikto 1.30/1.15     -        
www.cirt.net
+ Target IP:       127.0.0.1
+ Target Hostname: localhost
+ Target Port:     80
+ Start Time:      Sun Aug 17 15:19:05 2003
---------------------------------------------------------
-Scan is dependent on "Server" string which can be faked, use -g to override
+ Server: Apache/2.0.48 (Unix)
+ No CGI Directories found (use -a to force check all possible dirs)
+ Allowed HTTP Methods: GET,HEAD,POST,OPTIONS,TRACE
+ HTTP method 'TRACE' is typically only used for debugging. It should be disabled.
+ 1137 items checked - 0 items found on remote host
+ End Time:        Sun Aug 17 15:21:08 2003 (123 seconds)
[root@merc nikto-1.30]#

Blocking Access to Your Site

Sometimes, you’ll need to block access to your web site (or sites) from particular IP addresses. Generally, there are two ways of doing this: using mod_access directives, or using mod_rewrite. mod_access is easier to use, but it’s limited. On the other hand, mod_rewrite is very powerful, but it’s notoriously hard to use.

Using mod_access

mod_access is described in detail at http://httpd.apache.org/docs2.0/mod/mod_access.html. It has three options: Allow, Deny, and Order. Here is an example taken from the httpd.conf file I presented earlier in this chapter:

<Directory "/usr/local/apache2/htdocs">
   
AllowOverride None 
   Order allow,deny 
   Allow from all
</Directory>

The Allow and Deny directives are always followed by from, and then either an IP address, or a string like env= env-variable (where env-variable is an environment variable such as REMOTE_HOST; the full list is at http://hoohoo.ncsa.uiuc.edu/cgi/env.html). Remember that you can also define arbitrary environment variables using setenvif, browsermatch, and rewriterule, and these can all be used in the env= clauses.

Order can have two parameters: Deny,Allow or Allow,Deny. The use of this directive is sometimes a source of confusion. The following is from the Apache documentation (the emphasis is mine):

  • Deny,Allow. The Deny directives are evaluated before the Allow directives. Access is allowed by default. Any client which does not match a Deny directive or does match an Allow directive will be allowed access to the server.

  • Allow,Deny. The Allow directives are evaluated before the Deny directives. Access is denied by default. Any client which does not match an Allow directive or does match a Deny directive will be denied access to the server.

If you are used to configuring firewalls, you must remember that here all the Allow and Deny directives are evaluated before making a decision. In the short example earlier, the order is allow,deny. This means that all the Allow directives will be evaluated first, and then all the Deny directives are evaluated (in this case, there aren’t any), even if some of the Allow directives are matched.

In the example the order is allow,deny. This means that the default is deny. Apache first evaluates the Allow directive, which is followed by all—that is, everybody is allowed. Because there are no Deny directives to evaluate, the access is granted.

Now consider the following code, taken from the same httpd.conf file:

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

This filter applies to files that match the pattern "^\.ht", that is, files whose names start with “.ht”. The order is Allow,Deny; therefore, the default status is Deny. The Allow directives are processed first—in this case, there aren’t any. Then, the Deny directive is processed: Deny from all. Consequently, the default status remains deny, and access to the resource is never granted.

To block any connection from hosts outside the network 192.168.1.0, you can write:

Order Deny,Allow
Deny from all
Allow from 192.168.1.0/24

To block a particular IP address you can use something like this:

Order Allow, Deny
Allow from all
Deny from bad_ip_address_here

For more comprehensive information about mod_access, consult http://httpd.apache.org/docs-2.0/mod/mod_access.html. Remember also that it’s always wiser to have access control from a firewall, rather than from Apache directly. However, you can use mod_access as a temporary solution in case of emergencies.

Using mod_rewrite

mod_rewrite is a module that lets you manipulate URLs. To use mod_rewrite, you need to master regular expressions. Explaining regular expressions is outside the scope of this book. They are very powerful, and if you don’t have much experience with them, it’s certainly worth your while to study them, because they are used extensively in Apache configuration. A search for “regular expressions tutorial” returned these interesting results:

After reading some tutorials, you could also extend your knowledge by studying the official documentation for Perl’s regular expressions: http://www.perldoc.com/perl5.8.0/pod/perlre.html. Remember that the library used by Perl for regular expressions is normally more powerful than the one used by Apache, and some of the features mentioned at that site might be missing in Apache. However, this URL above is an excellent read and fully explains regular expressions.

The most basic use of mod_rewrite is the following:

RewriteEngine on
RewriteRule ^/test$ /index.html

Any request to /test is “rewritten” into /index.html (in regular expressions, ^ and $ are the beginning and the end of a string, respectively). You can test this on your server: you should receive the index.html page when you request http://localhost/test.

Another common use of mod_rewrite is to deny access to a specific resource using a third parameter, [F], in the rewriting rule. Consider the following:

RewriteEngine on a
RewriteRule \.htaccess$ - [F]

In this case, access to any URL ending with .htaccess (.htaccess, foo.htaccess, anything.htaccess, and so on) will be forbidden. I had to escape the period character (.) with a backslash, because in a regular expression, a dot means “any character.” In this case what the URL is rewritten into (-) is irrelevant.

You can put a condition to your rule rewriting using the RewriteCond directive. For example, you could deny access to your site only to a specific IP address using REMOTE_ADDR:

RewriteEngine on
RewriteCond %{REMOTE_ADDR} ^192.168.0.200$
RewriteRule .* - [F]

You can also base such a check on any environment variable (that is, the ones that aren’t predefined and known to mod_rewrite) using the syntax %{ENV:any_arbitrary_variable}.

The RewriteRule directive that follows a RewriteCond is only executed if the condition in RewriteCond is satisfied. You can have several conditions:

RewriteCond %{REMOTE_ADDR} ^192.168.0.201$ RewriteRule /shop\.html - [F]

RewriteCond %{REMOTE_ADDR} ^192.168.0.200$
RewriteRule .* - [F]

192.168.0.201 will only be denied access to the page shop.html, whereas the IP 192.168.0.200 will be denied access to any URL (in regular expressions, . means “any character,” and * means “0 or more of the previous character”).

You can concatenate several RewriteCond directives as follows:

RewriteCond %{REMOTE_ADDR} ^192.168.0.200$ [OR]
RewriteCond %{REMOTE_ADDR} ^192.168.0.201$
RewriteRule .* - [F]

This will prevent access to any URL from the IPs 192.168.0.200 and 192.168.0.201. Using mod_rewrite, you can prevent other people from using images from your web site:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.your_site.com/images/.*$ [NC]
RewriteRule .*\.gif$ -[F]

The first RewriteCond directive is satisfied if the HTTP_REFERER variable is not empty (the ! means “not,” and ^$ is an empty string). The second condition is satisfied if the HTTP_REFERER variable is not http://www.your_site.com/images/ (NC stands for “case insensitive”). If both conditions are satisfied, the request is likely to be coming from a browser that is not visiting www.your_site.com. Therefore, any request of files ending with .gif is rejected. (Unfortunately the referrer is often spoofed or obscured, so this is not a very useful technique.)

This is only the very tip of the iceberg: mod_rewrite can do much more, and its rules and conditions are very elaborate. You can find extensive documentation on mod_rewrite here: http://httpd.apache.org/docs-2.0/mod/mod_rewrite.html. When you feel brave, you can have a look at http://httpd.apache.org/docs-2.0/misc/rewriteguide.html, which provides a number of practical solutions using mod_rewrite. At the URL http://www.promotiondata.com/sections.php?op=listarticles&secid=1, you will find a simple tutorial that should help you get started.

This chapter is from Hardening Apache, by Tony Mobily. (Apress, 2004, ISBN: 1590593782). Check it out at your favorite bookstore today. Buy this book now.



 
 
>>> More Apache Articles          >>> More By Apress Publishing
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

APACHE ARTICLES

- Apache Unveils Cassandra 1.2
- Apache on ARM Chips? Dell and Calxeda Help M...
- The Down Side of Open Source Software
- VMware Unveils Serengeti for Apache Hadoop
- SAP Takes Steps to Improve Hadoop Integration
- Looking to Hone Apache Hadoop Skills?
- How to Install Joomla on WAMPP
- Working with XAMPP and Wordpress
- GUI Available for Apache Camel
- Reduce Server Load for Apache and PHP Websit...
- Creating a VAMP (Vista, Apache, MySQL, PHP) ...
- Putting Apache in Jail
- Containing Intrusions in Apache
- Server Limits for Apache Security
- Setting Permissions in Apache

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: