I have a fairly simple apache 2.4.7 config on CentOS 6.5 Linux and an active web server. No PHP or CGI, just some static pages and a proxypass to a different server tier.

I'm doing some security probing and purposely sending invalid data in the form of URL's with ~usernames that don't exist. I expect to get a 405 error.

HTTP/1.1 405 Method Not Allowed
Date: Fri, 27 Feb 2015 21:28:51 GMT
Server: Apache-Coyote/1.1
X-Frame-Options: SAMEORIGIN
X-Frame-Options: SAMEORIGIN

And that's what I get 90-95% of the time. But about 1 in 20-30 tries get a 200 return code with an otherwise blank page.

200 27/Feb/2015:21:02:50
HTTP/1.1 200 OK
Date: Fri, 27 Feb 2015 21:28:50 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
Content-Length: 1

If it was a simple configuration issue, I would expect every call to either fail or work, not 3-5% failing.

I only see this on the SSL port, the http port is also configured (though not open to the public) and it does NOT show the same issue. I can send hundreds of calls though http with no errors, but get at least one or two every 50 calls are so on https.

Some of the tests I've already tried unsuccessfully, are:

Logs just report the fact that either a 405 or a 200 was sent but no apparent difference in the url. Or any errors.

Eliminate any inbound firewall issues, by trying call on local loopback, same issue.

Eliminate issue with outbound load balancer by calling proxy connection directly. My reasoning for this test, is there nothing in this tier layer to handle ~username calls and it likely being ignored and passed by the wildcard proxypass to the next layer. Next sever layer is responding perfectly. No errors even with hundreds of calls in test blast.

Ran same test on Development environment which is configured exactly the same (AWS image is the same so differences is only in IP addresses) No errors, so volume in production maybe issue, but not a very helpful one. Server is currently averaging around 5-10 hits/sec with short peeks up to 25. CPU load is 0.00 to 0.02 with over 2G of 7G free memory and no disk issues.

I don't want to post the full configuration file here, but it's pretty vanilla with the relevant parts of the VirtualHost reading. (URL's changed to protect the innocent and keep stackexchange from thinking they're links)

Listen 443
SSLCipherSuite    ***REDACTED***
SSLHonorCipherOrder on
SSLSessionCache        "shmcb:/opt/httpd/logs/ssl_scache(512000)"
SSLSessionCacheTimeout  300
SSLProtocol ALL -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLCompression Off

SSLEngine on
SSLCertificateFile ***REDACTED***
SSLCertificateKeyFile ***REDACTED***
SSLCertificateChainFile ***REDACTED***

BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
CustomLog "/opt/httpd/logs/ssl_request_log" \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

 Order deny,allow
 Allow from all

SSLProxyEngine on

ProxyPass /terms !
ProxyPass /static !
ProxyPass /images !
ProxyPass /terms_ccm !
ProxyPass /pay/ https ://pay.ACME.COM/payment/
ProxyPassReverse /payment/ https ://pay.ACME.COM/payment/
ProxyPass / http: //mbg.ACME.COM/mobgate/
ProxyPassReverse http: //mbg.ACME.com/mobgate /

  • the http response you pasted in the question: the first 405 comes from tomcat (it has been proxypassed) the latter 200 from httpd. – guido Feb 27 '15 at 22:46
  • Yes, that does seem to be true, but I'm not sure why the same message would take two different paths. The default 'ProxyPass' seems to cover all fall throughs, so I'd expect the 200 to come from tomcat as well, but it doesn't. – Cosmo F Mar 2 '15 at 14:29
  • Apps deployed to tomcat wont respond to HEAD requests unless the code deployed handles them (they generate 405 codes), where as Apache will happily respond correctly. So it's worth checking if your security probing software is making head requests at all. – Unbeliever Oct 2 '16 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.