Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Apache Security

The main danger with Apache comes from cripts, especially PHP scripts, but server configuration plays important role

Among prudent measures are (see  NSA Secure Configuration of the Apache Web Server, Apache Server Version 1.3.3 on Red Hat Linux 5.1 ):

• Using a separate filesystem for webcontent and CGI directory. In no way this should be located in /usr directory
• Do not enable SSO for files with .html or htm extensions. such file should have a separate extension, for example, shtml. This helps keep server load at a minimum and allows for easier management of risk.
   
• 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.
      
• 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. In the server configuration file, put

  <Directory />
AllowOverride None
</Directory>

Apache lets you restrict access to your site based on IP addresses or hostnames. This is done through allow and deny directives in httpd.conf.  This prevents the use of .htaccess files in all directories apart from those specifically enabled.

Suppose you don't want anyone who does not have a DNS entry in your company DNS to access the directory /private You would add these lines to httpd.conf:

<Location /private>
    SetHandler private
    Order deny, allow
    Deny from all
    Allow from mycompany.com
</Location>

• all affects everyone.
• A full or partial IP address, such as 192.168.1.101 or 192.168.1.
• A full or partial host or domain name, such as susefan.com.
• A network/netmask pair such as 192.168.1.0/255.255.1.0.
• A network address in the classless interdomain routing (CIDR) form, such as 192.168.1.0/24.
• An environment variable, such as env=allowed_hosts.

Apache Basic Authentication is the most common authentication method used: when someone attempts to access a protected page, Apache asks for a username and a password. It then verifies the username and password and if successful, Apache serves the request. Basic Authentication is implemented with the mod_auth module; make sure this module is installed. The main deficiency is that the Basic Authentication does not encrypt the password when you type it in and thus you need to select a separate password so that the interception of  the Web password does not lead to compromise of your other accounts.  Basic Authentication requires creation of  a plain-text list of usernames and passwords using htpasswd2, a script included with the Apache2 package.  You should store these passwords away from your main Apache installation directory, for example /etc/httpd/passwd

Apache Digest Authentication is more secure as it is using SSL/TSL.

To create a new hidden password file, with the first user use:

./htpasswd -c /etc/httpd/.htpasswd joeuser

You'll be prompted twice for this user's password. To add new users to this file, use the same command without the -c switch (that creates a new file), for example:

./htpasswd /etc/httpd/.htpasswd webuser

You also need to configure Apache to refer to .htpasswd when serving a protected page iether in httpd.conf or by creating a special dot file (.htaccess) in each protected directory:

• In httpd.conf, you would create a new section labeled <Directory /pub>. Either way, the syntax is the same. Use these four directives:

  AuthType Basic
  AuthName "Members Only"
  AuthUserFile /etc/httpd/.htpasswd
  Require user joeuser
  

  Here the AuthType is Basic because we're using Basic Authentication (the option would be set to Digest if mod_auth-digest was used). The AuthName can be anything and identifies the "realm" or category of that page. In this case, all pages with the AuthName Members Only would have the same password. Thus, when the browser went to another page marked Members Only, it could deliver the same password without forcing the user to retype it in an endless series of pop-up dialog boxes. The AuthUserFile points to the .htpasswd file containing the usernames and passwords. The Require directive specifies the user(s) allowed to access the page.
   

• The .htaccess file should be located in the directory you want to protect

Often it is better to use weaker protection based on username only . In this case you can create a group of users with the same level of access, create a group file named .htgroup in any text editor with the Group Name and a list of users. Save it in the same directory as .htpasswd. The entry in .htgroup file should look like this:

Members: joeuser,webuser

The concept of the two files are similar to Linux's /etc/passwd and /etc/group files; .htpasswd stores each username and password hash, and .htgroup aggregates usernames into logical groups. Each group member needs to have a password listed in .htpasswd before access is allowed.

Now edit your .htaccess file so that your group has access.

AuthType Basic
AuthName "Members Only"
AuthUserFile /etc/httpd/.htpasswd
AuthGroupFile /etc/httpd/.htgroups
Require group Members

Everyone in the Members group would now have access to all pages with the "Members Only" realm.

Note: You can create as many groups as you want in your .htgroups file. Each entry is a single line listing all its members together, separated only by a space.

Old News ;-)

20 ways to Secure your Apache Configuration by Pete Freitag

Here are 20 things you can do to make your apache configuration more secure.

Disclaimer: The thing about security is that there are no guarantees or absolutes. These suggestions should make your server a bit tighter, but don't think your server is necessarily secure after following these suggestions.

Additionally some of these suggestions may decrease performance, or cause problems due to your environment. It is up to you to determine if any of the changes I suggest are not compatible with your requirements. In other words proceed at your own risk.

1. First, make sure you've installed latest security patches

   There is no sense in putting locks on the windows, if your door is wide open. As such, if you're not patched up there isn't really much point in continuing any longer on this list. Go ahead and bookmark this page so you can come back later, and patch your server.
    

2. Hide the Apache Version number, and other sensitive information.

   By default many Apache installations tell the world what version of Apache you're running, what operating system/version you're running, and even what Apache Modules are installed on the server. Attackers can use this information to their advantage when performing an attack. It also sends the message that you have left most defaults alone.
    

3. There are two directives that you need to add, or edit in your httpd.conf file:

   ServerSignature Off
   ServerTokens Prod

   The ServerSignature appears on the bottom of pages generated by apache such as 404 pages, directory listings, etc.

   The ServerTokens directive is used to determine what Apache will put in the Server HTTP response header. By setting it to Prod it sets the HTTP response header as follows:

   Server: Apache

   If you're super paranoid you could change this to something other than "Apache" by editing the source code, or by using mod_security (see below).
    

4. Make sure apache is running under its own user account and group

   Several apache installations have it run as the user nobody. So suppose both Apache, and your mail server were running as nobody an attack through Apache may allow the mail server to also be compromised, and vise versa.

   User apache
   Group apache

5. Ensure that files outside the web root are not served

   We don't want apache to be able to access any files out side of its web root. So assuming all your web sites are placed under one directory (we will call this /web), you would set it up as follows:

   <Directory />
     Order Deny,Allow
     Deny from all
     Options None
     AllowOverride None
   </Directory>
   <Directory /web>
     Order Allow,Deny
     Allow from all
   </Directory>

   Note that because we set Options None and AllowOverride None this will turn off all options and overrides for the server. You now have to add them explicitly for each directory that requires an Option or Override.

6. Turn off directory browsing

   You can do this with an Options directive inside a Directory tag. Set Options to either None or -Indexes

   Options -Indexes

7. Turn off server side includes

   This is also done with the Options directive inside a Directory tag. Set Options to either None or -Includes

   Options -Includes

8. Turn off CGI execution

   If you're not using CGI turn it off with the Options directive inside a Directory tag. Set Options to either None or -ExecCGI

   Options -ExecCGI

9. Don't allow apache to follow symbolic links

   This can again can be done using the Options directive inside a Directory tag. Set Options to either None or -FollowSymLinks

   Options -FollowSymLinks

10. Turning off multiple Options

    If you want to turn off all Options simply use:

    Options None

    If you only want to turn off some separate each option with a space in your Options directive:

    Options -ExecCGI -FollowSymLinks -Indexes

11. Turn off support for .htaccess files

    This is done in a Directory tag but with the AllowOverride directive. Set it to None.

    AllowOverride None

    If you require Overrides ensure that they cannot be downloaded, and/or change the name to something other than .htaccess. For example we could change it to .httpdoverride, and block all files that start with .ht from being downloaded as follows:

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

12. Run mod_security

    mod_security is a super handy Apache module written by Ivan Ristic, the author of Apache Security from O'Reilly press.

    You can do the following with mod_security:

    • Simple filtering
    • Regular Expression based filtering
    • URL Encoding Validation
    • Unicode Encoding Validation
    • Auditing
    • Null byte attack prevention
    • Upload memory limits
    • Server identity masking
    • Built in Chroot support
    • And more
13. Disable any unnecessary modules

    Apache typically comes with several modules installed. Go through the apache module documentation and learn what each module you have enabled actually does. Many times you will find that you don't need to have the said module enabled.

    Look for lines in your httpd.conf that contain LoadModule. To disable the module you can typically just add a # at the beginning of the line. To search for modules run:

    grep LoadModule httpd.conf

    Here are some modules that are typically enabled but often not needed: mod_imap, mod_include, mod_info, mod_userdir, mod_status, mod_cgi, mod_autoindex.
     

14. Make sure only root has read access to apache's config and binaries

    This can be done assuming your apache installation is located at /usr/local/apache as follows:

    chown -R root:root /usr/local/apache
    chmod -R o-rwx /usr/local/apache
    

15. Lower the Timeout value

    By default the Timeout directive is set to 300 seconds. You can decrease help mitigate the potential effects of a denial of service attack.

    Timeout 45

16. Limiting large requests

    Apache has several directives that allow you to limit the size of a request, this can also be useful for mitigating the effects of a denial of service attack.

    A good place to start is the LimitRequestBody directive. This directive is set to unlimited by default. If you are allowing file uploads of no larger than 1MB, you could set this setting to something like:

    LimitRequestBody 1048576

    If you're not allowing file uploads you can set it even smaller.

    Some other directives to look at are LimitRequestFields, LimitRequestFieldSize and LimitRequestLine. These directives are set to a reasonable defaults for most servers, but you may want to tweak them to best fit your needs. See the documentation for more info.
     

17. Limiting the size of an XML Body

    If you're running mod_dav (typically used with subversion) then you may want to limit the max size of an XML request body. The LimitXMLRequestBody directive is only available on Apache 2, and its default value is 1 million bytes (approx 1mb). Many tutorials will have you set this value to 0 which means files of any size may be uploaded, which may be necessary if you're using WebDAV to upload large files, but if you're simply using it for source control, you can probably get away with setting an upper bound, such as 10mb:

    LimitXMLRequestBody 10485760

18. Limiting Concurrency

    Apache has several configuration settings that can be used to adjust handling of concurrent requests. The MaxClients is the maximum number of child processes that will be created to serve requests. This may be set too high if your server doesn't have enough memory to handle a large number of concurrent requests.

    Other directives such as MaxSpareServers, MaxRequestsPerChild, and on Apache2 ThreadsPerChild, ServerLimit, and MaxSpareThreads are important to adjust to match your operating system, and hardware.
     

19. Restricting Access by IP

    If you have a resource that should only by accessed by a certain network, or IP address you can enforce this in your apache configuration. For instance if you want to restrict access to your intranet to allow only the 176.16 network:

    Order Deny,Allow
    Deny from all
    Allow from 176.16.0.0/16
    

    Or by IP:

    Order Deny,Allow
    Deny from all
    Allow from 127.0.0.1

20. Adjusting KeepAlive settings

    According to the Apache documentation using HTTP Keep Alive's can improve client performance by as much as 50%, so be careful before changing these settings, you will be trading performance for a slight denial of service mitigation.

    KeepAlive's are turned on by default and you should leave them on, but you may consider changing the MaxKeepAliveRequests which defaults to 100, and the KeepAliveTimeout which defaults to 15. Analyze your log files to determine the appropriate values.
     

Acknowledgments

I have found the book Apache Security to be a highly valuable resource for securing an apache web server. Some of the suggestions listed above were inspired by this book.

Related Entries

• Free Chapters in Apache Security - June 13, 2005
• Secure Browsing Mode - June 28, 2006
• Howto Backup your Mac incrementally over SSH - March 10, 2006
• Vi in a Nutshell - December 1, 2005
• CheatSheet for Apache - October 7, 2005

Comments

On 12/06/2005 at 12:20:01 PM MST Steven Erat wrote:

One could obfuscate server programm using error pages of other http server via

ErrorDocument 404 errors/404.html ErrorDocument 500 errors/500.html

polarizers 2cent http://www.codixx.de/polarizer.html

On 12/12/2005 at 12:19:05 PM MST Scorpion wrote:

Hi there, very interestig and useful tutorial. I have found a small error though. In the fourth part, you forgot the slash for the Directory tag. It should be like this: <Directory /> Order Deny,Allow Deny from all Options None AllowOverride None </Directory>

But I was still able to access any files out side of its web root with a simple php script, any ideas?

On 12/12/2005 at 12:24:27 PM MST Pete Freitag wrote:

Yes the apache configuration does not limit what PHP (or any cgi program) can do. I'm not sure if there is any way of limiting that, but I'm not a php guru.

Thanks for pointing out that typo as well, I'll fix it.

On 12/13/2005 at 2:58:49 AM MST polarizer wrote:

> I'm not sure if there is any way

>of limiting that.

What about running apache in a chroot jail.

polarizer http://www.codixx.de/polarizer.html

On 01/20/2006 at 3:19:28 PM MST Brian wrote:

For mod_security, the guys at gotroot.com make a very complete set of rules available that you can download and pop in to protect against all kinds of attacks. They update the rules every few days. An excellent way to help protect your application from known exploits, XSS and other attempts.

Brian

On 04/04/2006 at 6:18:29 PM MDT Fabián Arias wrote:

To restrict php to the web root you have to set the open_basedir variable in php.ini to your web root.

On 01/03/2007 at 5:53:46 AM MST Mueller Martin wrote:

Better way to set open_basedir for every host in apache, because setting in php.ini is global for all defined hosts in apache, so host1 could see directory of host2 and host3 ... It's mentioned here in Listing2: http://www.linux-magazin.de/Artikel/ausgabe/2004/10/php/php.html (Article in German language)

On 01/05/2007 at 6:07:22 PM MST Jok wrote:

If you don't want to use mod_security, and simply looks for hiding/masking Server: header, there's a tiny third part module that exists to do it on : http://jok.is-a-geek.net/blog/index.php?page=read&id=2006/01/090956

On 01/08/2007 at 5:46:44 AM MST Apache Dude wrote:

Awesome article man, very helpful. Here is a really good post dealing with securing SSL http://www.askapache.com/2006/htaccess/apache-ssl-in-htaccess-examples.html

On 10/23/2007 at 9:19:53 AM MDT cal wrote:

Thank you! :)

On 12/02/2007 at 6:29:10 PM MST Brontojoris wrote:

Hi, I know I'm a bit late to the party, but I just wanted to comment on Renan's query regarding .cfm files not being sent to the correct ErrorDocument location as set in Apache's config.

To have Apache catch .cfm files, instead of Coldfusion displaying an error, you need to update the IfModule mod_jrun22.c portion of the httpd.conf file for Apache. Change the 'JRunConfig Ignoresuffixmap false' to 'JRunConfig Ignoresuffixmap true'

On 05/23/2008 at 2:50:54 PM MDT Mario Barrera A. wrote:

Restricting Access by IP If you have a resource that should only by accessed by a certain network.

chroot isn't a security tool, and was never intended to be one. You can quite easily break out of a chroot jail, so relying on chroot for security is never a good idea.

On 08/01/2008 at 2:16:39 AM MDT Darko Bunic wrote:

Very well article. I would like to add the way you can exclude needless Apache modules. After commenting out needless candidate, run httpd.conf test, not httpd restart because httpd in case of error will not start. You should also comment depend modules. I describe whole procedure on www.redips.net so I hope you will find useful information there.

Debian Administration Intrustion detection and prevention for Apache with mod-security

How-To Apache web server basic security measures Debian-Ubuntu Tips & Tricks

A good start is to avoid displaying the software versions you are using.

Let me explain. When somebody request a page to a HTTP server, this one respond with headers such as Content-Type, Content-Length... as well as Server.

People don't usually see those headers, but if someone wants to hack your box, they might be looking for it. Why? Because known exploits usually work on specific software version.

Lets look at default HTTP headers on my ubuntu dapper box:

~$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 25 Jul 2006 10:47:13 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.4-1.dotdeb.2
Last-Modified: Mon, 20 Mar 2006 09:51:25 GMT
ETag: "3057-1f8-1a0f4140"
Accept-Ranges: bytes
Content-Length: 504
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Connection closed by foreign host.

As you can see from this excerpt, my box is running Apache 2.0.55 on an Ubuntu box and php-5.1.4 is used. This is perfect, if I want to hack that box, I simply have to look for known exploit for apache 2.0.55 or php 5.1.4 or even ubuntu.

The idea is to avoid telling too much, so we are going to make apache be less verbose.

2. Apache Configuration File:

In Apache, the ServerTokens directive allow the system administrator to set different type of Server HTTP response header:

• ServerTokens Prod[uctOnly] : this is the most restrictive, in our example, apache will respond:
  Server: Apache
• ServerTokens Major
  response -> Server: Apache/2
• ServerTokens Minor
  response -> Server: Apache/2.0
• ServerTokens Min[imal]
  response -> Server: Apache/2.0.55
• ServerTokens Os
  response -> Server: Apache/2.0.55 (Ubuntu)
• ServerTokens Full
  response -> Server: Apache/2.0.55 (Ubuntu) PHP/5.1.4-1.dotdeb.2 mymod1/X.Y mymod2/W.Z

By default, ServerTokens is set to Full, on my dapper box at least. To change that value, edit /etc/apache2/apache2.conf and look for the line containing ServerTokens.

Nota: On my ubuntu dapper box, ServerTokens was not set and was therefore taking the default value (Full), in that case, simply add this directive to apache2.conf.

I would recommend setting ServerTokens to Prod by adding this to apache2.conf:

ServerTokens Prod

Reload apache:

$sudo /etc/init.d/apache2 reload

and check for the new headers. Here are the headers sent back by my local server after setting ServerTokens to Prod:

$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 25 Jul 2006 11:33:09 GMT
Server: Apache
Last-Modified: Mon, 20 Mar 2006 09:51:25 GMT
ETag: "3057-1f8-1a0f4140"
Accept-Ranges: bytes
Content-Length: 504
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Connection closed by foreign host.

As you can see, apache does not tell anymore which version and modules are running

How-To Apache web server basic security measures -- page 2 Debian-Ubuntu Tips & Tricks

3. PHP:

Another way to hide which PHP version you are running can be achieved through php.ini.
Php as a directive of its own in order not to be too verbose, this is the variable called expose_php. Turning this one to Off will avoid php telling that it is running. In the following output, I had ServerTokens set to Full and expose_php to Off:

"Mod_security 1.7 has been released.

Mod_security is an open source intrusion detection and prevention engine for web applications. It operates embedded into the web server, acting as a powerful umbrella - shielding applications from attacks. The latest release adds output scanning to Apache 2.x; the ability to analyze cookies; functionality to change the identity of the web server; several new actions for rule grouping; new null-byte attack anti-evasion code."

A Guide to Building Secure Web Applications and Web Services

LinuxPlanet- Moving The Open Web Application Security Project Out Of The Shadows

Center for Internet Security - Apache Benchmark

• CIS_Apache_Benchmark_v1.6.pdf - the Benchmark document contains detailed instructions for implementing the steps necessary for CIS Level-1 and Level-2 security.>
• cis_score_tool_apache_v2.0.8.sh.gz - a Host-based Scoring Tool scores the security of a system against the Benchmark and creates a variance report.

eBook Preventing Web Attacks with Apache

Apache can be hacked. As companies have improved perimeter security, hackers have increasingly focused on attacking Apache Web servers and Web applications. Firewalls and SSL won't protect you: you must systematically harden your Web application environment. Preventing Web Attacks with Apache brings together all the information you'll need to do that: step-by-step guidance, hands-on examples, and tested configuration files.

Building on his groundbreaking SANS presentations on Apache security, Ryan C. Barnett reveals why your Web servers represent such a compelling target, how significant exploits are performed, and how they can be defended against. Exploits discussed include: buffer overflows, denial of service, attacks on vulnerable scripts and programs, credential sniffing and spoofing, client parameter manipulation, brute force attacks, web defacements, and more.

Barnett introduces the Center for Internet Security Apache Benchmarks, a set of best-practice Apache security configuration actions and settings he helped to create. He addresses issues related to IT processes and your underlying OS; Apache downloading, installation, and configuration; application hardening; monitoring, and more. He also presents a chapter-length case study using actual Web attack logs and data captured "in the wild."

For every sysadmin, Web professional, and security specialist responsible for Apache or Web application security.

With this book, you will learn to

• Address the OS-related flaws most likely to compromise Web server security

• Perform security-related tasks needed to safely download, configure, and install Apache

• Lock down your Apache httpd.conf file and install essential Apache security modules

• Test security with the CIS Apache Benchmark Scoring Tool

• Use the WASC Web Security Threat Classification to identify and mitigate application threats

• Test Apache mitigation settings against the Buggy Bank Web application

• Analyze an Open Web Proxy Honeypot to gather crucial intelligence about attackers

• Master advanced techniques for detecting and preventing intrusions

Solaris 10 Security How To Guides Eliminating Web Page Hijacking

This How to Guide instructs Solaris system administrators and security professionals in the process of securing common Web servers. By the end of the guide, an example configuration will be created that allows Web content to be maintained securely by content owners, while the Web server itself will run with a minimized set of privileges in its own secured Container.

Administrators are guided step-by-step through the process and at the end of the guide should be able to:

• Create a basic Solaris Container for hosting applications
• Configure the Apache2 Web server to run in a Solaris Container
• Use User and Process Rights Management to reduce application privileges
• Use the Solaris Service Manager to reduce security risk of a Container
• Share data securely between two Containers

This guide is not exhaustive and will not cover all optional features of these technologies. However, the reference section provided at the end of the document provides pointers to where administrators can learn more.

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.

Security Tips - Apache HTTP Server

The Apache HTTP Server has a good record for security and a developer community highly concerned about security issues. But it is inevitable that some ...

Apache Week. Apache security

The O'Reilly Network has teamed with Red Hat Apache Week, the leading commercial Apache site to offer comprehensive Apache information and resources.

Apache Security - The Complete Guide to Securing Your Apache Web ...

Apache Security is the complete guide to securing your apache web server.

Security and Apache: An Essential Primer ...

(LinuxPlanet) With Web security becoming a paramount concern in the face of several DoS attacks in prior weeks, securing your Apache/Linux installation should be the ...

ModSecurity (mod_security) - Open Source Web Application Firewall

Apache Security is a comprehensive Apache Security resource, written by Ivan Ristic for O'Reilly. One chapter (Apache Installation and Configuration) is ...

Debian Administration Intrustion detection and prevention for Apache with mod-security

How-To Apache web server basic security measures Debian-Ubuntu Tips & Tricks

A good start is to avoid displaying the software versions you are using.

Let me explain. When somebody request a page to a HTTP server, this one respond with headers such as Content-Type, Content-Length... as well as Server.

People don't usually see those headers, but if someone wants to hack your box, they might be looking for it. Why? Because known exploits usually work on specific software version.

Lets look at default HTTP headers on my ubuntu dapper box:

~$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 25 Jul 2006 10:47:13 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.4-1.dotdeb.2
Last-Modified: Mon, 20 Mar 2006 09:51:25 GMT
ETag: "3057-1f8-1a0f4140"
Accept-Ranges: bytes
Content-Length: 504
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Connection closed by foreign host.

As you can see from this excerpt, my box is running Apache 2.0.55 on an Ubuntu box and php-5.1.4 is used. This is perfect, if I want to hack that box, I simply have to look for known exploit for apache 2.0.55 or php 5.1.4 or even ubuntu.

The idea is to avoid telling too much, so we are going to make apache be less verbose.

2. Apache Configuration File:

In Apache, the ServerTokens directive allow the system administrator to set different type of Server HTTP response header:

• ServerTokens Prod[uctOnly] : this is the most restrictive, in our example, apache will respond:
  Server: Apache
• ServerTokens Major
  response -> Server: Apache/2
• ServerTokens Minor
  response -> Server: Apache/2.0
• ServerTokens Min[imal]
  response -> Server: Apache/2.0.55
• ServerTokens Os
  response -> Server: Apache/2.0.55 (Ubuntu)
• ServerTokens Full
  response -> Server: Apache/2.0.55 (Ubuntu) PHP/5.1.4-1.dotdeb.2 mymod1/X.Y mymod2/W.Z

By default, ServerTokens is set to Full, on my dapper box at least. To change that value, edit /etc/apache2/apache2.conf and look for the line containing ServerTokens.

Nota: On my ubuntu dapper box, ServerTokens was not set and was therefore taking the default value (Full), in that case, simply add this directive to apache2.conf.

I would recommend setting ServerTokens to Prod by adding this to apache2.conf:

ServerTokens Prod

Reload apache:

$sudo /etc/init.d/apache2 reload

and check for the new headers. Here are the headers sent back by my local server after setting ServerTokens to Prod:

$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 25 Jul 2006 11:33:09 GMT
Server: Apache
Last-Modified: Mon, 20 Mar 2006 09:51:25 GMT
ETag: "3057-1f8-1a0f4140"
Accept-Ranges: bytes
Content-Length: 504
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Connection closed by foreign host.

As you can see, apache does not tell anymore which version and modules are running

How-To Apache web server basic security measures -- page 2 Debian-Ubuntu Tips & Tricks

3. PHP:

Another way to hide which PHP version you are running can be achieved through php.ini.
Php as a directive of its own in order not to be too verbose, this is the variable called expose_php. Turning this one to Off will avoid php telling that it is running. In the following output, I had ServerTokens set to Full and expose_php to Off:

"Mod_security 1.7 has been released.

Mod_security is an open source intrusion detection and prevention engine for web applications. It operates embedded into the web server, acting as a powerful umbrella - shielding applications from attacks. The latest release adds output scanning to Apache 2.x; the ability to analyze cookies; functionality to change the identity of the web server; several new actions for rule grouping; new null-byte attack anti-evasion code."

A Guide to Building Secure Web Applications and Web Services

LinuxPlanet- Moving The Open Web Application Security Project Out Of The Shadows

Recommended Links

---

In case of broken links please try to use Google search. If you find the page please notify us about new location

***** NSA Guide to the Secure Configuration and Administration of iPlanet Web Server, Enterprise Edition 4.1 (425KB)

***** Secure Configuration of the Apache Web Server, Apache Server Version 1.3.3 on Red Hat Linux 5.1 (447KB)

How-To: Apache web server basic security measures | Debian/Ubuntu ...

Dot-Com Builder Web Services

• Introduction to Web Security -- Find out what you need to know to start developing using a security mind-set.
• Riddle Me This: Is Your XML Data Safe? -- Get the scoop on several new XML security specifications that could be essential to the development of XML-based applications.
• Lance Spitzner, Network Security Architect, Sun Professional Services
  What are the most common security mistakes people make? Spitzner explains, and describes the importance of developing secure code, understanding the state of your environment, and "knowing the enemy."

Dot-Com Builder Web Services -- Web security

• Apache HTTP Server Security Tips
• The WWW Security FAQ

Preventing Cross-site Scripting Attacks Paul Lindner, author of the mod_perl Cookbook, explains how to secure our sites against Cross-Site Scripting attacks using mod_perl and Apache::TaintRequest. [Perl.com]

• Apache HTTP Server Security Tips

Tutorials and Sample Chapters

Apache: The Definitive Guide Chapter 11: Security (PDF Format)

Apache: The Definitive Guide, 2nd Edition: Chapter 13 Security

Here we will look at how secure communication is built into Apache. ... You now have a secure version of Apache, httpsd; a site to use it on, site.ssl; ...

www.oreilly.com/catalog/apache2/chapter/ch13.html  - 113k - oreilly.com -- Online Catalog: Apache Security, First Edition

This all-purpose guide for locking down Apache arms readers with all the information they need to securely deploy applications.

Apache Security

Apache Security from AZ. Lincoln Stein. Open Source Conference, Version 3. For copies of this tutorial:. http://stein.cshl.org/~lstein ...

THE COMMON SENSE GUIDE TO APACHE SECURITY. As I clearly state in my Site Security Page, you are the biggest threat to your own site! ...