Aye, but since webdip is on a server hosted by a hosting company and sharing the same box with a lot of other customers, it would be the hosting company's responsibility to pay for, configure, and maintain the anti-DoS appliance. Is that in their budget, I wonder? I don't know a whole lot about standards and practices of the web hosting business, but it wouldn't surprise me if they simply dump customers hit by DoS attacks... I don't know how much Kestas is paying, but I can easily see customers getting thrown under the bus if they're only paying $10-20/month and it would cost tens of thousands of dollars for an anti-DoS appliance to deal with an attack on their site.

Most malicious hackers do their evil deeds for money nowadays - since webdip doesn't charge anything and is certainly not a money machine, I think it will fall very safely under the radar of professional cybervillians...

Don't underestimate the maddening power of a stab, Tolstoy :P

We've had a DoS attack of sorts before, when someone got bitter and wrote a script to automatically create accounts and flood the forum with comments. In the end that was why a captcha was added to the new account signup page

Someone could DoS the site, search in particular is vulnerable to this sort of thing because it uses a lot of resources (this is why forums will often limit the number of searches you can make, or require you register before searching), and I am planning on adding code to make sure that the resource intensive stuff can't be abused

That's interesting. Thanks.

What is a DOS?

I thought DOS was a pre-windows operating system.

It stands for "denial of service", its computer speak for "being an asshole". Maybe someone uncovers a bug that makes a server unusable, or maybe someone intentionally uses so much server resources that no-one else can make proper use of the server

I wouldn't understand Kestas's answer if I didn't know what it already meant so i'll add this:

It's basically coding a bot that keeps sending requests to the server so that the server gets overloaded.

And a DDoS does it with bots running on different computers around the nation or even the world, sometimes without their owners' knowledge. That's why the term Distributed is at the beginning.

Kestas, even if you write code, a DoS or DDoS is as simple as forcing the box to respond and process anything. Sending back a "Sorry, better luck next time" can still be used in a DoS. The best way is to have a screening appliance that doesn't allow the same IP to make multiple requests in less than a second.

Who do you use as a hosting company? I know Rackspace kept one of those appliances inline on our account when I worked for Road ID (www.roadid.com, wearable identification: I wrote the interactive voice system for it). But then we paid several grand a month in hosting fees and had 4 servers: 2 SQL and 2 IIS in geographically distinct locations (one pair each) with autofailover of everything in place so that if a bomb dropped on one location, the other automatically took over. I'm sure you aren't wanting to spend that kind of cash for a gaming site...

Detecting a DoS from within a web-app requires almost as many resources as generating a typical page (e.g. the forum). This means it's up to Dreamhost to guard against attacks that just overpower servers with requests (and they do).

But for things like search or loading all of a user's forum posts, which use more resources than usual, a DoS check uses much less resources than the rest of the page, and it'd take far fewer requests than usual to bring the server down, so that is the sort of thing I'd want to protect against myself.
(Decided that since we're discussing this it'd be a good idea to add some basic checks to the most resource-intensive scripts now)

"Detecting a DoS from within a web-app requires almost as many resources as generating a typical page (e.g. the forum)."
To clarify; by the time you're at a point in the web script where you can detect a DoS you've already used most of the resources a lightweight script will use, so it's already too late to prevent the larger part of the resource use

simply hitting a web server requesting their homepage a thousand times a second will bring down many servers. If a thousand chinese computer science students do this to the CIA's homepage you can bring down that site (which it's agents use to log in to get information, preventing them accessing the info) It's is actually really hard to protect against, but you'd want to do it at the server level rather than in a script...

Actually, it works best to have a gateway appliance reject those requests based on a set of rules than to let the requests even get through to the server. That keeps the traffic off your DMZ and aborts it before it can even affect the server. They have high-speed gateway appliances that can do just this, for a price of course.