search

tempesta-tech / tempesta

All-in-one solution for high performance web content delivery and advanced protection against DDoS and web attacks
https://tempesta-tech.com/
GNU General Public License v2.0
613 stars 103 forks source link

Sessions rate limit #598

Open krizhanovsky opened 8 years ago

krizhanovsky commented 8 years ago

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 commented 6 years ago

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:

avbelov23 commented 5 years ago

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 commented 5 years ago

Comment https://github.com/tempesta-tech/tempesta/issues/598#issuecomment-463230068 is essentially about https://github.com/tempesta-tech/tempesta/issues/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 commented 4 years ago

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

vankoven commented 4 years ago

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.