This is not a security guide for Apache HTTP Server. Instead is a small guide that can be used as reference to protect some aspects of how the applications and pages are served. For security guides, you must look at other places. Well, I hope this approach would help a little in your administration tasks. All examples are not a copy/paste rules, you must think on them. I’ll never give you recipes… you always must think.
anonymous version
In Apache 2.X you can avoid of showing the server version and installed extensions, such as mod_php, mod_perl and others. This is an easy task, just add the both next directives — search for them and change their value.
# # This hides the server signature on error pages. # This means that the server version is not shown # on error pages. # ServerSignature Off # # This will hide the server version and installed # modules on the response headers. # ServerTokens Prod
limit requests
mod_rewrite is a good option to setup some filters on your server. If you enable this module, you can filter the request method and certain CGI enabled URLs.
mod_rewrite filters
If you serve dynamic web pages using some module as mod_perl or mod_php, you can filter only the used methods on your application, in example: HEAD, OPTIONS, GET and POST, and disable other methods, such as TRACE or WebDAV methods.
#
# this rule will block all request that differs from HEAD, OPTIONS,
# GET and POST
#
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} !^(HEAD|OPTIONS|GET|POST)$
RewriteRule (.*) [F,NS]
</IfModule>
You can build a better request block using directories, in example over upload directories.
#
# this rule will block every request method that differs from HEAD,
# OPTIONS and GET. also it will block any request in files that do
# not have the extensions jpg, png and gif. It also works with image
# directories ;)
#
<IfModule mod_rewrite.c>
<Directory "/var/www/site1/upload">
RewriteCond %{REQUEST_METHOD} !^(HEAD|OPTIONS|GET)$ [OR]
RewriteCond %{REQUEST_FILENAME} !^.*.(jpg|png|gif)$
RewriteRule (.*) [F,NS]
</Directory>
</IfModule>
You can play a lot with all those RewriteCond and RewriteRule. Also, you can block unwanted scripts, in example, if you are using PHP as your unique dynamic language to display your dynamic pages, you do not need to allow any Perl or Python scripts, you can block all other scripts that are unwanted on your site.
#
# this one will allow only PHP scripts, and also
# HTML pages and JavaScript
#
<IfModule mod_rewrite.c>
<Directory "/var/www/site1/">
RewriteCond %{REQUEST_METHOD} !^(HEAD|OPTIONS|GET|POST)$ [OR]
RewriteCond %{REQUEST_FILENAME} !^.*.(php|html|htm|js)$
RewriteRule (.*) [F,NS]
</Directory>
</IfModule>
And yet, there are a lot of useful rules that you can apply, just think on them to fit your needs. Well, also you can enable Apache to allow only preprocessed URLs, in example if you are using some kind of wrapper to deny direct access to all PHP scripts, why, because our application is a MVC based application.
#
# we deny access to all kind of scripts on our system
#
<IfModule mod_rewrite.c>
<Directory "/var/www/site1/">
RewriteCond %{REQUEST_METHOD} !^(HEAD|OPTIONS|GET|POST)$ [OR]
RewriteCond %{SCRIPT_FILENAME} !^.*.(jpg|png|gif|html|htm|js)$ [OR]
RewriteCond %{REQUEST_FILENAME} ^.*.(py|pl|cgi|php|php3|shtml)$
RewriteRule (.*) [F,NS]
#
# we allow jpg, png, gif, js and html
#
RewriteCond %{SCRIPT_FILENAME} !^.*.(jpg|png|gif|html|htm|js)$ [OR]
RewriteRule (.*) $1 [PT]
#
# and then we redirect all requests to the /index.php script ;)
# possibly the main controller on our application
#
RewriteCond %{REQUEST_METHOD} !^(HEAD|OPTIONS|GET|POST)$
RewriteRule (.*) /index.php?$1 [PT]
</Directory>
</IfModule>
You can play a lot with mod_rewrite rules and customize your application to allow users to have normal and browser based access to your application.
limit by location
Two helpful directives are Limit and LimitExcept. Those directives can allow you to limit the request method for certain Location.
#
# this will block other request method
# than HEAD GET POST OPTIONS, under Location
#
<Location />
<Limit HEAD GET POST OPTIONS>
Order allow,deny
Allow from all
</Limit>
<LimitExcept HEAD GET POST OPTIONS>
Order deny,allow
Deny from all
</LimitExcept>
</Location>
third party modules
Well here you have a list of modules that you can use. All of them will help you on protecting your application
disable unused modules
Make deep review on how many modules are you using. If you are not using certain module, just remove it from your configuration. In example, many sites have enabled the dav_module and dav_fs_module, when they really don’t need them. This will reduce all possible bugs that can be remotely attacked and will reduce the memory and processor usage ;)
on what can’t help?
Surely, there a lot of "responsibility of the user" issues on those those modules and rules can not help. In example, weak passwords, buggy applications, weak validations and wrong handled user privileges.
I’ve found an interesting paper on this topic, about the user authentication issue. It’s written by MIT researchers. Here is the abstract bellow.
Client authentication has been a continuous source of problems on the Web. Although many well studied techniques exist for authentication, Web sites continue to use extremely weak authentication schemes, especially in non enterprise environments such as store fronts. These weaknesses often result from careless use of authenticators within Web cookies. Of the twenty seven sites we investigated, we weakened the client authentication on two systems, gained unauthorized access on eight, and extracted the secret key used to mint authenticators from one.
We provide a description of the limitations, requirements, and security models specific to Web client authentication. This includes the introduction of the interrogative adversary, a surprisingly powerful adversary that can adaptively query a Web site.
We propose a set of hints for designing a secure client authentication scheme. Using these hints, we present the design and analysis of a simple authentication scheme secure against forgeries by the interrogative adversary. In conjunction with SSL, our scheme is secure against forgeries by the active adversary.
And here is the link to download it. I hope that all of those topics would help on your Web Site maintenance and development… And yet I know that I don’t cover some other issues, but that’s because I know that you can search for proper research and do security labs on your application ;)
Entries 