On 2018/8/13 09:17, Aleksandar Lazic wrote: > On 11/08/2018 14:48, Patrick Hemmer wrote: >> > > [snipp] > >> To answer one of the earlier questions, I do plan on writing a blog >> article yes. The question is when. I'm considering backporting this >> feature to 1.8 for my own use at work, and if done, might wait for that >> so I have some real world usage to comment on. > > That sounds very good. Due to the fact that this is a new feature I'm > not sure if it will be back ported. It's not my decision but I think > this would be a nice feature in 1.8 also. It will not be officially backported to 1.8. The backport will be done by me personally for my own use.
> >> Willy's example use cases were spot on. But to add the use case which >> triggered me to write this code: The intent is more for layer 7 DOS >> mitigation. It's really hard to correctly identify bots vs real users. >> You can usually get it right, but mis-identification is very easy. So >> the idea here is that we would add a score to incoming requests based on >> things like the user having a cookie, are they a registered user, >> request rate, etc. Similar to how email spam filters work. Each one of >> these things would increment or decrement the score, and then they would >> be queued based on the result. Then when we do have a L7 attack, we only >> give compute resources to the attackers when there are no real users in >> the queue. Thus the users might see some slowdown, but it should be >> minimal. And since we're not actually blocking an attacker, it makes it >> much harder for them to figure out the criteria we're using to identify >> them and get around it. And also since we're not blocking, users which >> end up mis-identified as bots aren't impacted during normal operations, >> only when we're under attack. And even then it should be minimal since >> while a user might have triggered a few of the score rules, the bot >> would have hopefully triggered more. > > Full ack here. This is a difficult topic which can create a lot of > headache. > > Do you think to use one of the sample like DeviceAtlas or 51 or a more > specific solution? No. DeviceAtlas and 51degrees are not suitable for this task. All these libraries do is analyze the UserAgent header (which is trivially easy to fake). They do not do behavior analysis. > > Do you think about to use SPOE for the detection to offload the check > mechanism? SPOE can be utilized yes. There are many other services which can be utilized as well, even some which have official integration with haproxy such as Datadome <https://docs.datadome.co/docs/haproxy-setup>. The queuing mechanism is meant to be the action taken upon detection, while the detection itself can be anything, and is left up to the user. But the configuration will need to be tailored to the system utilizing it. > > If this question / answers are some business secret then I fully > understand when you can't answer it. > >> -Patrick > > Regards > Aleks
