phillipp
commented
7 years ago Btw: the quick fix was raising an error in the SNI HTTP server for the attacked domain name, so bud closes the connection after receiving the HTTP 500 and doesn't spend time on the handshake ;-)
Hi, we have now had 2 DDoS attacks on HTTPS specifically and I must say, it wasn't easy to mitigate at all. Both incidents had a connection rate of > 10k incoming connections/s and bud was stomped by the attacker. I recognize that this is not the fault of bud, but of SSL by design.
We're now looking into possible mitigation strategies. The most important thing is quality of service (multi-tenant environment): if one customer (= backend) is attacked, and another is not, the shared frontend for both should not go down.
So we'll be looking into setting limits per hostname/sni name/context/whatever plus we need to log the connections with SNI name and source address for filtering (before the handshake occurs). Maybe it's even possible to implement quotas (eg handshakes/s or CPU seconds used per minute) either per CIDR or per hostname/backend/etc.
My point is: do you have any plans on looking into this? Do you think this is part of the projects scope? With a growing share of HTTPS connection in web traffic, this could be a major feature that would distinguish bud from all other solutions. DDoS will be a persistent problem and there are no great solutions for HTTPS mitigation that I know of.