Hi, On Wed, Jun 24, 2015 at 12:03:39PM -0600, Shawn Heisey wrote: > On 6/24/2015 11:12 AM, Willy Tarreau wrote: > > The problem with configs posted on a blog is that people blindly copy-paste > > them without understanding and then break a lot of things and ask for help. > > Baptiste takes care of explaining how things work so that people can pick > > what they need. There's no universal anti-ddos config, we've built a lot of > > different ones in the past. Each config is almost unique in fact, depending > > on business cases. You need to keep in mind that fighting DDoS consists in > > differenciating what looks like a regular visitor *in your case* and what > > is not. Quite commonly it's extremely tricky and even between various > > applications hosted behind the same LB you can apply different mechanisms. > > For example for certain apps it's totally abnormal to have more than X > > concurrent connections from a single IP address while in other cases it's > > normal, even to have a lot of requests using a same cookie (think completion > > for example). > > > > So it is important to understand the concepts, how the tools work and can > > help, then to analyse what happens in your situation and how to fight when > > the problem happens. You'll even notice that you'll change your protections > > from one attack to another. > > I always treat sample configs as a starting point that will need > significant tweaking for my specific situation. For instance, I already > know that 10 connections from one IP address won't be enough for several > of our websites, partly because there are some customers who have > several users in one location who will almost certainly be connecting > from the same public IP address.
OK, that's the principle indeed. > That said, I know that there are plenty of people out there who will > copy/paste a sample config and expect it to make their bed and fillet > their fish. I get irritated with those people who won't make an effort > to actually understand what their systems are doing. Yes and these ones then pollute everyone's valuable time. > For this specific situation, I'm hoping to learn how to successfully > combine the techniques on the blog post into one config without screwing > it up. If I run into trouble, I will try to solve it on my own before I > come back here to ask for help, and if that's required, I will try to > ask intelligent questions and provide all relevant information at the start. The principle will be to declare various tables to track whatever you need, and put your rules together. > > The subject is really vast. You could have one week full of training on the > > subject and still feel naked at the end. > > I've gotten that impression. I use a number of other open source > projects which have even steeper learning curves. The basics of haproxy > were quite easy to grasp, but I know that there's a lot of unexplored > depth, some of which I may never use. We have a problem, the architecture manual is almost 10 years old and covers haproxy 1.1. Since then we've got a huge amount of new features and other ways to solve common issues, but they're not documented except on some blogs. These features would be much better used with some updated doc. > Thank you for everything you do. You are one of the unsung heroes who > make the guts of the Internet possible. Hehe don't feel like you're exagerating a bit here ? :-) Willy
