On 6/17/07, Bob <bob@xxxxxxxxxxxxxxx> wrote:
Thank you for the info. I read through link you provided on the "GET http" request. But I don't feel it answered my question. My interpretation of the 404 response means the "GET http" request was processed and packets where sent to the URL contained in the request and the remote server replied back with 404 no file found. So in a nut shell these "GET http" request types are consuming resources on my server.
They are only consuming the minimal resources needed to send a 404 response. There is no way to make apache consume substantially less resources on a request, no matter what you do. (Apache never simply drops requests. That is not an acceptable thing for an HTTP server to do.)
Reading the link you posted above talks about the "GET http" request being processed by the mod_proxy module. I used the default http-config file to customize and I have commented out the loadmodule & addmodule statements for proxy as well as commented out all the other statements in the default http-config file that have to do with the proxy. To me this means the proxy module is completely disabled and is not a player in why the "GET http" request is being processed. Further more, the mentioned link says the file size which is 300 in the above log record should match the file size of my default file I serve up. The default file I serve up is index.php and the ls -l command shows it's size to be 7812. Matter of fact I have no files sized smaller than 900.
Read the FAQ entry again. I know it is a little complicated, but this issue is a little complicated. Note that the FAQ entry says "If you see a status code of 404 (file not found) in the log, then you know that the request failed." That is exactly what you want: a failed request. So there is nothing more you need do. If you read further on, you'll see exactly what apache is doing: "it will serve requests for unknown sites locally by stripping off the hostname and using the default server or virtual host." So apache is looking for a file named /cgi-bin/jenv.cgi on your server, and properly sending back a 404. The remote server is never involved.
The CONNECT request has a http status code of 200 which means this request was serviced by apache and packets were exchanged between my apache server and the remote targeted server. I do have php5 enabled in my apache. Is this one of those situations of who has final control of the CONNECT request, (apache or php)?
As I said, by default, apache denies CONNECT requests. So it is really the php configuration that needs to be adjusted here. I believe you can set http.allowed_methods in your php config to the list of methods php should handle. (GET and POST would be a good basic list.) You can also likely control this from apache, but it makes more sense to limit what php handles (especially from a security viewpoint).
The goal here is to Deny CONNECT & GET http requests before they generate any public internet traffic.
That goal can only be met by going and finding all the botnet machines sending this traffic and unplugging them from their power outlets. As I said, apache doesn't drop requests, and even if it did, the request is already using up resources. You could perhaps configure your firewall (or maybe mod_security) to drop the requests with no response at all, but the gain in resources would be minimal. 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
|