Sessions rate limit

[krizhanovsky]

Depends on #235 , linked with #1045

To fight against cookie aware DDoS bots more efficiently Frang must implement new HTTP sessions rate limits: concurrent sessions from the peer, new sessions per time unit for the peer with burst control and maximum number/rate limit of wrong sticky cookie values (see comment in tfw_http_sticky_req_process()).

Please update Wiki documentation https://github.com/tempesta-tech/tempesta/wiki/DDoS-mitigation and https://github.com/tempesta-tech/tempesta/wiki/Frang . Also don't forget to create a test issue.

A functional test for this issue and #1045 is required.

[krizhanovsky]

Please add to the Wiki folliowing minutes from our discussion. We can not replace the limit by the combination of connection and request rate limiting because such limiting doesn't differentiate sessions with valid sticky cookie and sessions established w/o sticky cookie enforcement.

Also we came up with introducing hard and soft limits:

• switch on js_challenge on reaching soft limit
• block the client IP on reaching hard limit

[avbelov23]

Need drop the session, send a redirect request and require a new cookie for clients working through a proxy instead of closing the connection

[krizhanovsky]

Comment #598 (comment) is essentially about #1045 .

Please also note discussion https://github.com/tempesta-tech/tempesta/pull/1178/files#r255150323 : probably there is a dependency between session lifetime, sessions rate limit, and/or frang limits.

[krizhanovsky]

A good user experience in JS challenge requires soft and hard limits in #1102 , so mark the issue as crucial.

[vankoven]

We account not only HTTP sessions but also endpoint client hidden behind anonymous HTTP proxy. It makes sense to limit number of concurrent clients behind a proxy. Just to avoid unlimited population of the client database. Bit in the same time, each client behind proxy should receive it's own HTTP session and we don't need to introduce special limit for concurrent clients behind proxy.

Still it can be suspicious when multiple different clients behind proxy share the same sessions, no matter whether they're behind the same proxy or not.