On 6/20/07, Tony Anecito <adanecito@xxxxxxxxx> wrote:
Hi Guys, I am very interested in what you are talking about. Especially the CONNECT/POST discussion. I have what I believe is a spammer doing the CONNECT/POST and getting a status 200 from apache. Is this truely a php issue? Should I drop using php? Do you both agree and the apache group that this http 200 status response means the connect to another server (they are trying to connect back to thier server) is failing to connect yet the status 200 occurs? I am considering dropping php and or Apache because of this drive a Mac truck through it security hole in Apache/php. I tried the suggestions here on the Apache forum but they do not appear to fix the spammer issue. If this is a php issue I really would like a fix.
Did you read the whole thread? I've explained this several times already, and it is also explained at http://httpd.apache.org/docs/1.3/misc/FAQ.html#proxyscan but let me start again from the beginning: 1. If you have disabled mod_proxy or you have set ProxyRequests Off then it is highly unlikely that these requests are getting through to a remote server. To be really really sure, you can point your browser's proxy settings at apache and try some requests for foreign servers, or you can use telnet to test this type of request. For example: telnet yourhost 80 CONNECT foreign.host.example.com:25 HTTP/1.0 [enter][enter] 2. Then why is the reponse code 200? Because the HTTP/1.1 spec requires apache to accept requests that look like proxy requests even when it isn't in proxy mode. It handles these requests by stripping off the foreign hostname and attempting to serve them as if they were a request for your local server. 3. But why does apache handle CONNECT requests when it isn't in proxy mode? It doesn't by default. Try issuing a request like the one above to www.apache.org and you'll see what I mean. But some modules like php choose to take over processing for all request methods. And if your php script doesn't have any special per-method handling, then all methods will be treated exactly like GET and serve your basic homepage. I personally think this is a bad design decision for the default configuration of php. It leaves php scripts open to some subtle security problems. But it is obviously not a tremendously serious problem, because millions of php installs run just fine in this config. (And less than 50% of them have been hacked ;-) 4. What if I don't want php handling all methods? Two choices: Change your php config to specify the acceptable methods as I've described earlier in the thread. Or change your php script to check the method and bail out if it isn't the expected one. 5. Can I handle this from the apache config? Sure. The cleanest way to deal with these attempted proxy attacks is by setting up a default virtual host that will catch all unknown hostnames and either reject them or redirect them to your canonical hostname. See the example in the FAQ item referenced above. It is also not a bad idea to restrict the type of methods that will be handled by apache. For example, you can use <Location /> <LimitExcept GET POST> Order allow,deny Deny from all </LimitExcept> </Location> But be careful with this config since it will override any other host-based access controls in your config file. So if you have other controls, you'll need to merge this config in the appropriate context. 6. Do I need to bother with all that if the requests aren't reaching the remote server anyway? No. If the proxy attempt is not succeeding because the requests are being served locally, you can just ignore these requests even if the status code is 200. The above config suggestions are just best-practices to make your server more restrictive in general about the types of things it will response to. I certainly hope that helps. Joshua. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|