@briankrebs I guess the only feasible defense if blocking #HTTP2 or rate-limiting per IP adress allication block?
Top-level
@briankrebs I guess the only feasible defense if blocking #HTTP2 or rate-limiting per IP adress allication block? 4 comments
@hikhvar @briankrebs Just rate-limiting the number of connections per IP should work regardless if on a WebProxy, Chaching Server or Network (Security) Appliance... OFC those rate limits could be self-resetting/soft to quickly ban any attempted DoS attacks... Jist like one could traffic-shape per IP Adress... @kkarhan @briankrebs no, rate limiting connections will not help here. The request cancelation happens within the same TCP connection. @hikhvar @briankrebs Worst-case limiting over time, number of packets and bandwith would be an option... This should throttle down attackers... |
@kkarhan @briankrebs this would be the "Holzhammer". You need some rate limiter for created connections per client/connection in your Frontend http2 server, do you don't overload your backend with canceled requests. Or add some sort of tar-pit/cool down before proxing an incoming request to the backend. This will add latency, but you will not Proxy already canceled requests.