Forum Moderators: phranque
Hello.
This is driving me nuts: I am attempting to disable the HTTP TRACE method as described here:
[apacheweek.com...]
and also here:
(I work for a web hosting company and one of our customers is using a banking/merchant service which uses a security scanner to test for PCI compliance).
However, no matter which way I slice it or dice it, I am unable to disable the HTTP TRACE method. For instance, if I place this code in httpd.conf:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^GET
RewriteRule .* - [F]
restart Apache and then load the web server's main URL in my web browser, then sure enough, the CentOS 403 forbidden page is the page that is served up. However, if I then replace GET in the above code with TRACE, restart Apache, and then reload the same URL, the site's main index.html page is served instead of CentOS' 403 page.
Furthermore, after placing the following directives in httpd.conf:
RewriteLog "/var/log/httpd/rewrite.log"
RewriteLogLevel 10
and then restarting Apache, then while rewrite.log is subsequently created under /var/log/httpd/, it remains empty regardless of whether or not I specify GET or TRACE in the RewriteCond rule and no matter how many times I restart Apache.
So as I said before: This is driving me batty. Any suggestions or tips would be greatly appreciated.
Thanks.
Are you trying to use a browser to send a TRACE request? You said "reload" there, and a browser is never going to send a TRACE request, just a GET or a POST, typically.
I suspect the problem is in the testing, not the implementation.
If you have no other tools, you could use telnet to connect to port 80 on your server and type in any HTTP-compliant requests you like, as long as the syntax is valid.
Jim
Thanks for your reply.
"Are you trying to use a browser to send a TRACE request? You said "reload" there, and a browser is never going to send a TRACE request, just a GET or a POST, typically."
Gah. Why on earth did I type that I was using a browser to test the TRACE method? Anyway, I am using actually using telnet to test the TRACE method as described on the IBM page which I mentioned previously:
Instead of getting 'Forbidden', the initial TRACE request and anything else that was typed prior to pressing the Enter key twice in succession is echoed in the telnet session after pressing the Enter key twice (in succession).
By the way, where you are placing these mod_rewrite directives, above/after/within what?
Thanks for your reply.
With regards to:
[httpd.apache.org...]
I actually have already tried specifying 'TraceEnable Off', but it did not work and I found out soon after that with regards to version 2.0.x of Apache: the TraceEnable directive it only works with version 2.0.55 and higher (which is what it says on the link that you posted). However, as I stated in my very first post, the version of Apache that we are using is Apache version 2.0.52-38.ent.centos4 (CentOS 4.6) and so specifying TraceEnable with that version of Apache will not work (and yes, I did try it in the vain hope that it would work, but it didn't).
"By the way, where you are placing these mod_rewrite directives, above/after/within what?"
I've placed them in /etc/httpd/conf/httpd.conf directly after:
<Directory "/var/www/html">
(with the DocumentRoot being set to "/var/www/html").
When I place the directives there, they work - but as previously stated, only if the REQUEST_METHOD is GET.
[edited by: encyclo at 2:47 am (utc) on Mar. 4, 2008]
[edit reason] fixed link [/edit]
I'm using similar code in many .htaccess files across many commercial name-based shared serrvers. However, the pusrpose of my "standard" code is to skip all subsequent RewriteRules for the TRACE, OPTIIONS, and PROPFIND methods.
I've never seen any anomalies in this code's execution, so I don't know why you might be having trouble. with yours -- Your code looks fine to me.
Jim
While the server makes use of NameVirtualHost, when telnetting, I am specifying the value that is specified for the ServerName directive in httpd.conf. i.e. Say for example that the ServerName is uncooperative.example.com.au. As such, I am issuing the following commands from another server:
telnet uncooperative.example.com.au 80
which then results in:
Trying x.x.x.x...
Connected to uncooperative.example.com.au (x.x.x.x).
Escape character is '^]'.
Then, following from the example given at publib.boulder.ibm.com, I enter the following and then press the Enter key twice:
TRACE / HTTP/1.0
host: uncooperative.example.com.au
A: b
C: d
and what is returned is this:
HTTP/1.1 200 OK
Date: Tue, 04 Mar 2008 04:16:19 GMT
Server: Apache/2.0.52 (CentOS)
Connection: close
Content-Type: message/http
TRACE / HTTP/1.0
host: uncooperative.example.com.au
A: b
C: d
Connection closed by foreign host.
Also, the result is the same if I use HTTP/1.1 instead of HTTP/1.0.
Now, if I replace ^GET with ^TRACE in httpd.conf, restart the web server, telnet in from the other server and then enter this:
GET / HTTP/1.0
host: uncooperative.example.com.au
after pressing the Enter key twice, what instead is returned is this:
HTTP/1.1 403 Forbidden
Date: Tue, 04 Mar 2008 04:24:53 GMT
Server: Apache/2.0.52 (CentOS)
Accept-Ranges: bytes
Content-Length: 5044
Connection: close
Content-Type: text/html
followed by the html code from the default CentOS 403 page.
Any ideas?
If I understand you well, the directives are within a <Directory> container, I'd suggest to move it outside of that, either to the main section of the config file, or into a VirtualHost container of the mentioned website (uncooperative.example.com.au).
Apologies for the delay in replying. Been flatout here. Anyhow, I tried moving the code outside of the <Directory> container but that did not help. However, we've decided not to worry about it for the time being.
CentOS actually do provide a version of Apache (2.0.59) for CentOS 4.6 in their centosplus respository that does support the TraceEnable directive, but unfortunately they do not provide version 2.0.59 of httpd-suexec (which we cannot do without). So hopefully, they will release httpd-suexec 2.0.59 sometime in the near future and we will see how that goes.
Cheers.