Why doesn't the linux community just rewrite the portions of SCO code they claim is being used, and screw SCO. SCO would have a much harder time laying claims to the IP protocol in general, as that would make any software that uses the Internet subject to them.
I agree, too many people out there who are technology whores, and most of their technology never really accomplishes anything useful for them. That is the reason I've given away about 6 PDA's, my talking billy mouth bass, and plenty of stuff from ThinkGeek. I'm much more productive with just my laptop and a wireless connection than an arsenal of useless gear to babysit.
Call me old fashioned, but I still thrive on human interaction regardless of how obsolete it may be these days. Really, given if we all had the money, I'm willing to bet there are more people like me who would get rid of all of their technology and live a more simple, fulfilling life.
Funny you should mention that. We released version 1.3 on the site that now has a separate threshhold for total hits per child per second. The default is 50 objects per child per second. Even if you have a large site and a fast client connection, a browser is going to open up four or more concurrent connections splitting the total number of objects up. Nevertheless if 50 is still too low you can always adjust it.
oh..and that would have to happen within 1 second's time. Apache's keep-alive defaults to 15 seconds, so unless each browser is requesting a "Connection: close" it's going to be impossible.
Remember these rules are instantiated on a per-listener basis, so you have to have not only the same IP requesting the same page but the same client, since just about any current browser has a keep-alive.
So if three people hit the server simultaneously, they would get 3 different listeners. The only way it'd deny them is if it hit the server one-after-the-other after each client disconnected and if it happened to hit the same child. This is extremely unlikely.
There are many different types of DoS attacks, and the kind you're describing have other methods of circumvention. The type of DoS this module was designed to fight/detect was a request-based attack where a website was flooded with requests to increase bandwidth and system load.
Just wanted to clear up a bit of misunderstanding about this module. First off, please forgive me for screwing up the story submission. What it *should* have said was "...This new module gives Apache the ability to deny (403) web page retrieval from clients requesting THE SAME FILES more than once or twice per second...". That's the way this tool works; if you request the same file more than once or twice per second, it adds you to a blacklist which prevents you from getting any web pages for 10 seconds; if you try and request more pages, it adds to that 10 seconds.
Second, I'd like to address the idea that we designed this as the "ultimate solution to DoSes". This tool should help in the event of your average DoS attack, however to be successful in heavy distributed attacks, you'll need to have an infrastructure capable of handling such an attack. A web server can only handle so many 403's before it'll stop servicing valid requests (but the # of 403's it can handle as opposed to web page or script retrievals is greater). It's our hope that anyone serious enough about circumventing a DoS attack will also have a distributed model and decentralized content, along with a network built for resisting DoS attacks.
This tool is not only useful for providing some initial frontline defense, but can (should) also be adapted to talk directly to a company's border routers or firewalls so that the blacklisted IPs can be handled before any more requests get to the server; e.g. it's a great detection tool for web-based DoS attacks.
Anyhow, please enjoy the tool, and I'd be very interested in hearing what kind of private adaptations people have made to it to talk to other requipment on the network.
Why doesn't the linux community just rewrite the portions of SCO code they claim is being used, and screw SCO. SCO would have a much harder time laying claims to the IP protocol in general, as that would make any software that uses the Internet subject to them.
I agree, too many people out there who are technology whores, and most of their technology never really accomplishes anything useful for them. That is the reason I've given away about 6 PDA's, my talking billy mouth bass, and plenty of stuff from ThinkGeek. I'm much more productive with just my laptop and a wireless connection than an arsenal of useless gear to babysit.
Call me old fashioned, but I still thrive on human interaction regardless of how obsolete it may be these days. Really, given if we all had the money, I'm willing to bet there are more people like me who would get rid of all of their technology and live a more simple, fulfilling life.
Funny you should mention that. We released version 1.3 on the site that now has a separate threshhold for total hits per child per second. The default is 50 objects per child per second. Even if you have a large site and a fast client connection, a browser is going to open up four or more concurrent connections splitting the total number of objects up. Nevertheless if 50 is still too low you can always adjust it.
oh..and that would have to happen within 1 second's time. Apache's keep-alive defaults to 15 seconds, so unless each browser is requesting a "Connection: close" it's going to be impossible.
Remember these rules are instantiated on a per-listener basis, so you have to have not only the same IP requesting the same page but the same client, since just about any current browser has a keep-alive. So if three people hit the server simultaneously, they would get 3 different listeners. The only way it'd deny them is if it hit the server one-after-the-other after each client disconnected and if it happened to hit the same child. This is extremely unlikely.
There are many different types of DoS attacks, and the kind you're describing have other methods of circumvention. The type of DoS this module was designed to fight/detect was a request-based attack where a website was flooded with requests to increase bandwidth and system load.
Hi there,
Just wanted to clear up a bit of misunderstanding about this module. First off, please forgive me for screwing up the story submission. What it *should* have said was "...This new module gives Apache the ability to deny (403) web page retrieval from clients requesting THE SAME FILES more than once or twice per second...". That's the way this tool works; if you request the same file more than once or twice per second, it adds you to a blacklist which prevents you from getting any web pages for 10 seconds; if you try and request more pages, it adds to that 10 seconds.
Second, I'd like to address the idea that we designed this as the "ultimate solution to DoSes". This tool should help in the event of your average DoS attack, however to be successful in heavy distributed attacks, you'll need to have an infrastructure capable of handling such an attack. A web server can only handle so many 403's before it'll stop servicing valid requests (but the # of 403's it can handle as opposed to web page or script retrievals is greater). It's our hope that anyone serious enough about circumventing a DoS attack will also have a distributed model and decentralized content, along with a network built for resisting DoS attacks.
This tool is not only useful for providing some initial frontline defense, but can (should) also be adapted to talk directly to a company's border routers or firewalls so that the blacklisted IPs can be handled before any more requests get to the server; e.g. it's a great detection tool for web-based DoS attacks.
Anyhow, please enjoy the tool, and I'd be very interested in hearing what kind of private adaptations people have made to it to talk to other requipment on the network.