Secure Installation and Configuration - Don’t Give Extra Information Away (Page 8 of 11 )
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.
|
Next: Apache and SSL >>
More Apache Articles
More By Apress Publishing
/ 29 
