[rabbitmq-discuss] DOS protection

[Carl Hörberg]

On Monday 8 July 2013 at 12:19, Matthias Radestock wrote:

> On 08/07/13 10:57, carlhoerberg wrote:
> > Ok, is it something you would consider in the core? Today it's pretty
> > easy to crash a RabbitMQ server with a very small amount of traffic.
> 
> 
> 
> It's been on our todo list for a long time; I don't expect it will get 
> resolved soon. As you may have guessed, figuring out what exactly to 
> limit and when is quite tricky.
> 
> Would you mind explaining what you had in mind for "monitor[ing] new 
> channels/consumers/declarations in real-time and block (disconnect) if 
> too many are made in a short amount of time?"
> 
> Specifically...
> 
> - what entities do you want to monitor? You mention channels, consumers 
> and declarations (presumably by that you mean exchanges, queues, and 
> bindings). Any others?

That, plus connection count.  
> 
> - do you want to monitor rates (e.g. "channels created per second") or 
> totals ("number of existing channels")? From your description ("too many 
> ... in time" it sounds like rates, but rates are more a proxy for CPU 
> and network usage, whereas memory is a mostly a function of the totals.

Total, we haven't seen CPU problems, only suffered sudden memory exhaustion. 
> 
> - at what granularity would the limits (the "too many" part) be set? 
> globally? per vhost? per user? per connection?

Per vhost and global. 

We do limit per vhost today, but it's the sudden bursts of queue declarations or channels openings that we can't protect us from today. 

A global limit would be sufficient for the time being, just for protection, so that the cluster doesn't dies before we can see who has done what. 
> Note that the finer grained the limits the lower the limits need to be 
> if you want to have a high chance of preventing undesirable behaviour 
> globally, e.g. for per user limits you'd have to assume that every user 
> connecting to a single rabbit will hit the limit along each of the 
> dimensions - channels, consumers, exchanges, queues, etc.
> 
I guess a combination would be ideal, so that you can limit both per cluster/server and per vhost.. But that's not necessary for us today, as the mgmt http api allow us to do that, for slow growth in queues/channels/consumers.
> 
> 
> Regards,
> 
> Matthias.