Thanks Joshua you answered all my questions even the one about testing. All I 
got was the last message and it only referenced the php/CONNECT not the whole 
discussion.
  I will try these things immediately. The Seattle company which is trying the 
CONNECT/POST test is really annoying.
   
  Regards,
  -Tony

Joshua Slive <[EMAIL PROTECTED]> wrote:
  On 6/20/07, Tony Anecito 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



Order allow,deny
Deny from all



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 for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



       
---------------------------------
Pinpoint customers who are looking for what you sell. 

Reply via email to