Tom Diehl tdiehl@rogueind.com wrote:
they are pulling the whole web site I see about 255 httpd processes.
I believe that this is the default number of connections that Apache on CentOS allows. From the sound of it, your machine has plenty of power, and you could increase this number. That may or may not help, because it also sounds like the company pulling your content is not doing so in a very polite way and is using a client that opens many, many more connections than an average browser would. I would talk to them about this, personally.
robert
On Sat, 21 Oct 2006, Robert Becker Cope wrote:
Tom Diehl tdiehl@rogueind.com wrote:
they are pulling the whole web site I see about 255 httpd processes.
I believe that this is the default number of connections that Apache on CentOS allows. From the sound of it, your machine has plenty of power, and you could increase this number. That may or may not help, because it also sounds like the company pulling your content is not doing so in a very polite way and is using a client that opens many, many more connections than an average browser would. I would talk to them about this, personally.
I agree they are not being polite about it and I have spoken to them. It was necessary for me to block them at the firewall to get their attention. Once they could not sync, they contacted their customer who in turn called me. Funny how that kind of thing works. :-))
The thing I am concerned about is, what if someone decides to do this because they want to bring the server down? This seems like a trivial way to execute a DOS.
So my question really is how do I prevent un-polite people from bringing the server down? httpd appears to be consuming all of the available memory when this occurs. If I increase the max https processes will that not aggrivate the situation? If I need to add more memory I can do that but I am trying to understand exactly what is going on here.
One of the things that confuses me even more is the fact that the machine does not swap nor do I get OOM killing processes. Is their something about httpd processes that makes them behave like this?
Regards,
The thing I am concerned about is, what if someone decides to do this because they want to bring the server down? This seems like a trivial way to execute a DOS.
So my question really is how do I prevent un-polite people from bringing the server down? httpd appears to be consuming all of the available memory when this occurs. If I increase the max https processes will that not aggrivate the situation? If I need to add more memory I can do that but I am trying to understand exactly what is going on here.
More memory will not help. You want to restrict the max number of concurrent http connections from each IP. This will not prevent a full-scale DOS attack, which could potentially involve tens of thousands of zombie machines attacking your server.
On Sun, 22 Oct 2006, DamianS wrote:
The thing I am concerned about is, what if someone decides to do this because they want to bring the server down? This seems like a trivial way to execute a DOS.
So my question really is how do I prevent un-polite people from bringing the server down? httpd appears to be consuming all of the available memory when this occurs. If I increase the max https processes will that not aggrivate the situation? If I need to add more memory I can do that but I am trying to understand exactly what is going on here.
More memory will not help. You want to restrict the max number of concurrent http connections from each IP.
Well that sounds reasonable but is there some place where this is explained. What is the correct number to limit it to? Is this based on something besides trial and error??
This will not prevent a full-scale DOS attack, which could potentially involve tens of thousands of zombie machines attacking your server.
That part I understand. AFAIK there is no way to stop that kind of thing without the help from the upstream provider.
Regards,
That part I understand. AFAIK there is no way to stop that kind of thing without the help from the upstream provider.
There's also an apache module you can use which may help. While it won't stop everything, it may help a bit with your current situation. http://www.zdziarski.com/projects/mod_evasive/ It's designed to help apache deal with brute force DOS attempts.
Jim Perrin wrote:
That part I understand. AFAIK there is no way to stop that kind of thing without the help from the upstream provider.
There's also an apache module you can use which may help. While it won't stop everything, it may help a bit with your current situation. http://www.zdziarski.com/projects/mod_evasive/ It's designed to help apache deal with brute force DOS attempts.
But do be careful with that one. Though it is designed to look for "X-Forwarded-For"-Headers by caching proxies, not all proxies set that header. So you might deny access to people using those proxies. And you have to look at traffic patterns for your website first, so that you do not set the access limits too low and deny regular traffic to your website (if you - for example - have many small images on your website).
Cheers,
Ralph
Ralph Angenendt wrote:
Jim Perrin wrote:
That part I understand. AFAIK there is no way to stop that kind of thing without the help from the upstream provider.
There's also an apache module you can use which may help. While it won't stop everything, it may help a bit with your current situation. http://www.zdziarski.com/projects/mod_evasive/ It's designed to help apache deal with brute force DOS attempts.
But do be careful with that one. Though it is designed to look for "X-Forwarded-For"-Headers by caching proxies, not all proxies set that header. So you might deny access to people using those proxies. And you have to look at traffic patterns for your website first, so that you do not set the access limits too low and deny regular traffic to your website (if you - for example - have many small images on your website).
I agree. I think the solution to this problem is not to lock down the server, but to have a conversation with the "client" and let them know that the marketing company is knowingly (whether it's through laziness or stupidity is really irrelevant) causing performance problems for the server hosting their website. Explain to the client that the marketing company has been unresponsive and that it would possibly be helpful if the client would pass those concerns on to their marketing people. That would be my first mode of "attack" here. If that doesn't work, it might be simpler to set up a quick iptable filter to limit the maximum number of connections from the naughty netblock (assuming they always mug you from the same place).
Cheers,
On 22/10/06, chrism@imntv.com chrism@imntv.com wrote:
I agree. I think the solution to this problem is not to lock down the server, but to have a conversation with the "client" and let them know that the marketing company is knowingly (whether it's through laziness or stupidity is really irrelevant) causing performance problems for the server hosting their website.
Likewise. He could also consider arranging an alternative, more suitable transfer mechnism for the content the marketoids want. Like tar-ing it up uncompressed and emailing it to them ;)
Or, more considerately, FTP/SFTP or something.
Will.
-
chrism＠imntv.com -
DamianS -
Jim Perrin -
Ralph Angenendt -
Robert Becker Cope -
Tom Diehl -
Will McDonald