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 <[email protected]>: > 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 >
