Re: [tlug] DDB/CJKV-E Web Host under DDOS attack

[Curt Sampson <cjs@example.com>]

On 2016-01-07 07:41 +1100 (Thu), Jim Breen wrote:

> On looking at it more closely I realise that wwwjdic is probably
> not a good CDN candidate after all. It doesn't have static content;
> everything is coming out of dictionary files with a humungous number
> of potential query terms. I don't think there really are identifiable
> common queries, or at least not enough to pre-compose.

I thought you were right, for a bit, but then I had an idea. The
individual dictionary entries are all fairly constant, most of them
rarely changing, right? One could set up a query system that returns
only the set of entry IDs of interest (as some small JSON object, no
doubt) and then have the page itself (i.e., JavaScript running in the
browser) pull these entries from the CDN servers (that would store them
as static files) and arrange them nicely on the page.

This would minimize data served by the servers that actually do
searches. How useful this would be, I'm still not sure.

Certainly it makes DOS attacks more difficult. You could effectively
limit the bandwidth of every IP of a potential attacker to something
negligible, meaning that he's going to have to have a lot of IP
addresses available to run up your CPU and/or IO load to a problematic
level. (You can safely limit an individual IP to something like 10
requests/minute, so a single query server should be able to handle
O(100,000) clients without difficulty.)

And the client-side JS code could not only randomize the query server
used, but also remember which ones have been slow recently, so an
attacker would have to take down all query servers to seriously affect
real clients.

Plus there are a few minor tricks you could pull that might force the
attacker to do actual analysis and coding work to do the DOS. For
example, the query request does nothing but return a token that has to
be given to a different URL to actually run the query, meaning that the
attacker can't effectively DOS the query servers with a static URL. (But
I dunno, maybe attackers just use the actual web browser on whatever
machine they took over, anyway.)

However, there are other issues. I don't know how many folks out there
are still using browsers on non-smartphones that might not be able to
run the client-side JS. I can see how to split that on to different
servers, but not how to mitigate DOS attacks on those servers, taking
down the non-JS browser site. There's probably other stuff, too.

Thoughts, anyone? I think this is actually a pretty interesting problem.

cjs
-- 
Curt Sampson         <cjs@example.com>         +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch