DDoS mitigation testing

[vankoven]

There are some DDoS simulation tools available to evaluate system behaviour under DDoS attack:

• https://github.com/MatrixTM/MHDDoS (seems like quite an advanced suite)
• https://github.com/shekyan/slowhttptest
• https://github.com/markus-go/bonesi
• https://sourceforge.net/projects/ddosim/
• https://github.com/jseidl/GoldenEye
• https://github.com/palahsu/DDoS-Ripper

It would be nice to test DDoS mitigation effectiveness as a part of stress tests.

[krizhanovsky]

Tempesta emphasises L7 DDoS, which requires large (at least 100k) TCP connections with different source IP addresses. So ideally massive number of virtual IP interfaces are required.

Basically, we can just check correctness of ratelimits with #673 and do similar tests with wrk without rate limiting to estimate the system under the stress.

[krizhanovsky]

DDoS mitigation is a crucial feature, so the task is crucial as well. At least we must be sure that 100-1000 valid clients work just fine with 100-1000 bots sending malicious requests concurrently. We have tests for cookie and JS challenges, but we do not verify them in real life scenario:

• [ ] relatively complex web site, e.g. tempesta-tech.com
• [ ] concurrent realistic innocent clients with full browser emulation and performance analytics to catch not fully loaded or too slowly loaded pages
• [ ] many bot agents and correspondingly many filtering rules on Tempesta FW side
• [ ] a comprehensive HTTP rate limit test (linked with https://github.com/tempesta-tech/tempesta/issues/673)

At least these DDoS attacks must be emulated with appropriate HTTP limits in both the modes to block malicious IPs and reply:

• [ ] HTTP flood (basic GET / HTTP/1.1\nHost: foo.com\n\n, the same for HTTP/1.0 w/ Host)
• [ ] random URLs bypassing cache
• [ ] sloworis / slow connections
• [ ] many concurrent connections

[krizhanovsky]

To emulate a more or less close to a real life DDoS scenario, we need to run the DDoS agents on multiple network interfaces or interface aliases to assign each of them a designated IP. It seems Route the traffic over specific interface for a process in linux provides a good solution with the script. The script contains a lot of configuration and error handling code, so I'd propose to use it just as a reference.

We can use the loopback network 127.0.0.0/8 or create any big enough local network (I think 1024 addresses would be enough for the testing). Next you need to create the network interfaces or interface aliases. Lastly use network namespaces, netfilter marks and the routing tables as in the script.

[krizhanovsky]

Blocked by https://github.com/tempesta-tech/tempesta/issues/1464

[krizhanovsky]

Now is blocked again on https://github.com/tempesta-tech/tempesta/issues/2000