Posts Tagged ‘Disable Apache HTTP TRACE method to improve Apache security’

Disable Apache HTTP TRACE method to improve Apache security

Thursday, April 22nd, 2010

I’m doing a security web audit on a server. To get more accurate data about the current Linux powered serversecurity Level.
I’m intending to combine both automated scannings with softwares like Paros Proxy , Nessus , nmap as well as some more modern day web server scanners like:
Nikto . By the last mentioned Nikto is not something brand new, but it’s partly based on a on older web sever scanner called Whisker which nowadays is a depreceated piece of software though for it’s time it was a real buzz.

Anyways the audit I’m into is not the major topic of this post.
During some of the scans with the softwares forementioned I was warned by the security scanners that the HTTP TRACE on the webserver is enabled and this could possibly pose a security threat.
At first I had absolutely no idea what is HTTP TRACE and after some reading online I got it. It’s really simple and let me save you some time in Googling in researching.
What HTTP TRACE is is simply an integrated ECHO like service in the Apache server.
The Nikto web security scanner has identified that the Apache server I was auditing has an enabled HTTP TRACE method and warned that this could pose a security risk on the server.
At first I thought nikto is wrong and it’s reporting a false positive. However after checking out my Apache for HTTP TRACE method I realized the security scanner is right.

I wondered how such a tiny thing as HTTP TRACE could introduce a security threat and after reconsidering the issue I understood that having it enabled on the Webserver could be beneficial for an attacker if he tries to exercise Denial of Service or Distributed Denial of Service on the Apache Webserver.

So having that in mind I should confess the security scanners are right to point the HTTP TRACE as a possible security leak.

Here is an example on how to check your webserver if HTTP TRACE is enabled.

debian-server:~# telnet 80
Connected to
Escape character is '^]'.
Here Press ENTER twice!

HTTP/1.1 200 OK
Date: Thu, 22 Apr 2010 10:36:58 GMT
Server: Apache
Connection: close
Content-Type: message/http


Connection closed by foreign host.

If after the check you receive some HTTP TRACE output which is like the one above, then positively HTTP TRACE is enabled on your Apache and for security reasons it’s best to disable it.

There are two ways to do that:

1. You can either use a mod rewrite rule like the following and put it in your httpd.conf,apache2.conf (on Debian) or as an .htaccess file rules:

RewriteEngine On
RewriteRule .* - [F]

However note that this method is a real performance killer since, each and every request to the server will pass through the mod rewrite rule chain.

2. Or use the TraceEnable off Apache directive which is available on Apache 1.3.34 and on All Apache Servers versions 2.0.55 or higher.
The TraceEnable off Apache directive is also working on Apache 2.2.x including the current stable Debian Apache (2.2.9-10+lenny7).
Take in mind that in my case as I disired to disable the HTTP TRACE on a Debian server putting TraceEnable Off in /etc/apache2/apache2.conf didn’t disabled the HTTP TRACE for the Apache server.

To be able to disable it I had to edit my /etc/apache2/sites-enabled/000-default and put the TraceEnable Off variable in it.

If you want to make sure Apache HTTP TRACE method after using one of the forementioned methods for disabling it.
You should once again execute:

debian-server:~# telnet cadia 80Trying
Connected to cadia.
Escape character is '^]'.
Press Enter Twice!

You should then receive a responce from Apache like:

HTTP/1.1 405 Method Not Allowed
Date: Thu, 22 Apr 2010 10:52:09 GMT
Server: Apache
Vary: Accept-Encoding
Content-Length: 223
Content-Type: text/html; charset=iso-8859-1

Method Not Allowed

The requested method TRACE is not allowed for the URL

That’s all, now your Apache should be a bit more secure than before!