Thank's for sharing this !
You are right lua in 1.6 will be, a better fit to handle this scenario.
For now I will add some features to my current solution but I will
give LUA a try.
Regards,
Muchal
2015-06-26 11:17 GMT+02:00 Willy Tarreau w...@1wt.eu:
Hi Michal,
On Fri, Jun 26, 2015 at 01:39:57AM +0200, Lazy wrote:
Hi All,
Some time ago I created a small patch for haproxy 1.5 which is acting
in a simmilar way to cloud anti dos CAPTHA pages
(https://github.com/lazy404/haproxy/compare/ddos)
The idea is that when the site is attacked by bots sending http requests,
haproxy sends them a webpage with some javascript which is setting a cookie
with a product of some simple calculations.
Usually simple ddos bot's aren't capable of passing this kind of
defences. Magic number
depends on bot ip address so adding a static cookie header won't do.
That's interesting, thanks for sharing this. I may have some elements to
place here because I've been doing such things for about 10 years to help
various web sites with varying degrees of success.
What I've seen all the time is that such mechanisms are efficient enough
to stop basic scripts which randomly spot your site. If the attacker
targets your protected site, then he switches to other tools, or modifies
the tools he uses. In your case this means that he will probably send the
pre-computed cookie all the time, or just grep for the few fields
he needs in the response to break your computation. Don't get me wrong,
what you have done *will* be efficient against blind attacks, there's
no doubt about it, as I've been doing it with some success for years, it's
just that it doesn't last long. If you're getting attacked for one hour or
more, you'll see that the attack changes a number of times and that your
defence will break.
The second point is that many attacks target specific products. The
simple fact that your mechanism would get merged would weaken it even
further. That's one of the reasons for having integrated Lua in 1.6,
it will allow everyone to build their own defence without being exposed
to well-known weaknesses. It's just like changing the lock on your door
when you realize that all the appartments in the building use the same
type of locks. If a guy comes in with a locksmith, he will open all doors
but will not want to waste his precious time on yours just because it's
different.
The third point is that you'll notice a very high number of DDoS attacks
come from infected browsers who easily pass through all these protections.
At Haproxy Tech, we have built a module which does similar things and
we purposely don't merge it so that it remains unexposed. In short, it
does more or less the same, but with some extra complexity for the
attacker :
- it randomly scrambles the javascript code with fake code and uses
random methods to compute the requested values in JS using constants,
functions, etc... in order to prevent extraction using simple parsers.
For example value 10 can also be expressed sqrt(4) / e(0) xor 12.
That's just to give an idea of course ;
- it employs methods I will not develop here to prevent pre-computation
of the challenges ;
- it ensures using various methods that it's running in a real browser and
not a smart script ;
- it makes use of cryptographic signatures with user-defined keys to
ensure that the cookie was not forged ;
- it does its best to prevent the attacking browser from sharing the cookie
with other nodes from the same botnet.
- it automatically rate-limits the attackers from the browser to ensure we
don't move the stress to the rest of the infrastructure.
Despite all this we've seen it defeated once (that's not much) by a huge
swarm of infected browsers, so we have added human detection to it in order
to also protect against these (I will not expand here either). We're quite
proud of it and our customers seem very happy with it now.
As any such tools, disclosing more about it could weaken it and reduce
some of our customers' protection level so you can easily understand that
I won't go into further details.
What I want you to understand with this is that I'd strongly encourage you
to port your work to Lua code using 1.6 and possibly to make it easily
configurable so that anyone can pick your code, adapt it to their needs
and avoids being exposed by not adopting a well-known behaviour.
That way your mechanism could be usable in mainline without requiring
patching, and could remain strong for everyone at the same time (and
flexible, which is absolutely needed in such circumstances).
Best regards,
Willy
