[rabbitmq-discuss] Securing RabbitMQ

Sun Jan 29 20:23:48 GMT 2012

Hi Paul,

Cool architecture.

> If an attacker has access to queue storage (the Mnesia directory?) 

Yes, the queues are stored in the Mnesia directory (but they're not
really a Mnesia database; it doesn't matter in this case).

> If an attacker has access to queue storage (the Mnesia directory?) he might be able to deconstruct the clear text messages and reconstruct spurious messages of his own making. 

I'd like to point out that if he actually has access to the machine and
rabbitmq account (and not just the disk), he could do a lot worse; for
instance, he could stop RabbitMQ, reconfigure it or replace it with
something else; or he could create new RabbitMQ users to facilitate
further attacks.  I don't think there's much you could do in this
situation.

If you're just protecting the disks, an encrypted file system is
probably the way to go.

> If he then had access to RabbitMQ, i.e., could connect and login to it, he could insert spurious messages into the queue.

Ok, I see.

> But there are other security issues here: 
> 
> a. securing the broker password. I routinely see the "guest/guest" examples where the password is stored in code. I know these are examples and, as such, provide needful and simple instruction. But in the real world, we can't be storing passwords in code. As usual, the storing/securing of keys and passwords is the hard part of security.

You could just not use passwords.  If you use SSL connections, RabbitMQ
can authenticate users by the certificate they provide.

See the auth-mechanism-ssl plugin for details:
  http://hg.rabbitmq.com/rabbitmq-auth-mechanism-ssl/file/default/README

If you still decide to use username/passwords, you could make the system
more flexible by delegating the task of authenticating users to an LDAP
server.  See the auth-backend-ldap plugin for details:
  http://hg.rabbitmq.com/rabbitmq-auth-backend-ldap/file/default/README

These don't solve the problem, but they make it a lot harder for an
attacker to forge user credentials.

That said, yes, securing credentials on user's systems is hard.  But is
RabbitMQ dealing with users directly here?  My understanding is that
your broker only talks to consumers that are under your control (and are
driven by events from the REST web service).  So you'd only have to
authenticate the consumers (let's call them clients from now on) and 
trust that they speak on behalf of users.

I don't think there's much you can do preventively in order to stop
a compromised consumer from sending spurious messages to the queues.
You could use the access control features to limit the damage an attacker
could cause.  See the access control guide for more details:
  http://www.rabbitmq.com/access-control.html

If it's acceptable, you could also set a TTL for messages on the queues.
That way, RabbitMQ will discard messages not consumed in some time-frame
(this is giving in to the DoS, but at least it limits the extent of the
overloaded services):
  http://www.rabbitmq.com/extensions.html#lifetimes

> b. then there's the matter of the web services themselves: they are, presumably, publicly accessible via  a web browser. If you know the URL you can try to invoke these services, whether or not you put anything in the queue via an authenticated log in.

No comments on that.  The web messaging people would be more qualified
to comment.

Cheers,
Alex

On Sun, Jan 29, 2012 at 11:58:25AM -0500, Bell, Paul M. wrote:
> Hi Alex,
> 
> Thanks very much for your instructive reply.
> 
> By way of background, I am working on a layered architecture. One of these layers, sitting just above the business services, is an AMQP consumer as it faces up. Facing down, it is a REST web service client. Suppose that the enqueued messages look pretty much like RESTful URIs (e.g., http://<host>:<port>/<appContextPath>/users meaning something like "return a list of users"). The consumer pulls such a message and presents it via customary servlet container infrastructure (e.g., Tomcat + Spring) to the appropriate business service where the real work is done.
> 
> Such messages were produced in the first place by an authenticated user at a UI. (It is interesting to me that, despite the significant advantages of decoupling layers via a queue, the queue itself becomes almost like another login point. That is, just as input can come from the UI, input can come also from the queue.) Ideally, only an authenticated user (or process) can place messages into the queue. And that's where one of the security issues arises.
> 
> If an attacker has access to queue storage (the Mnesia directory?) he might be able to deconstruct the clear text messages and reconstruct spurious messages of his own making. If he then had access to RabbitMQ, i.e., could connect and login to it, he could insert spurious messages into the queue.
> 
> So that's why I was thinking along the lines of messages being encrypted in the queue. 
> 
> But there are other security issues here: 
> 
> a. securing the broker password. I routinely see the "guest/guest" examples where the password is stored in code. I know these are examples and, as such, provide needful and simple instruction. But in the real world, we can't be storing passwords in code. As usual, the storing/securing of keys and passwords is the hard part of security.
> 
> b. then there's the matter of the web services themselves: they are, presumably, publicly accessible via  a web browser. If you know the URL you can try to invoke these services, whether or not you put anything in the queue via an authenticated log in.
> 
> I would like to hear your and others' thoughts about these issues.
> 
> Thanks again.
> 
> -Paul 
> ________________________________________
> From: Alexandru Scvorţov [scvalex at gmail.com] On Behalf Of Alexandru Scvorţov [alexandru at rabbitmq.com]
> Sent: Saturday, January 28, 2012 12:11 PM
> To: Bell, Paul M.
> Cc: rabbitmq-discuss at lists.rabbitmq.com
> Subject: Re: [rabbitmq-discuss] Securing RabbitMQ
> 
> Hi Paul,
> 
> > Is there any in-built support for encrypting/decrypting the at-rest messages in the queue? I suppose that producer could encrypt and consumer decrypt. But I was hoping to avoid a "roll your own" approach.
> 
> No, there isn't any in-built RabbitMQ feature to encrypt at-rest
> messages.  You'll have to roll your own.  As a rule, RabbitMQ does *not*
> modify (or inspect) the contents of received messages.
> 
> If you use SSL on both the producer and consumer sides, the only way for
> an attacker to get the messages would be to gain access to machine
> hosting RabbitMQ or to the network the RabbitMQ cluster is running on
> (if there is a cluster).
> 
> So, are you planning against an attacker who has gotten his hands on an
> offline machine with RabbitMQ on it?  I haven't tried, but I suppose you
> could use an encrypted file system.  RabbitMQ stores messages and state
> only in its mnesia database directory, so if you encrypt that, you
> should be secure.
> 
> > I am trying to think about a rogue producer injecting meaningful messages into the queue, i.e., a message whose processing might return a valuable data resource. Then there's also the need to prevent someone from inspecting the queue with an eye to reverse-engineering message syntax.
> 
> I'm not quite sure I follow.  Could you elaborate?
> 
> Cheers,
> Alex
> 
> 
> On Sat, Jan 28, 2012 at 11:40:33AM -0500, Bell, Paul M. wrote:
> > Hello again,
> >
> >
> >
> > I have started reading http://www.rabbitmq.com/ssl.html, and it looks....reassuring. :)
> >
> >
> >
> > Is there any in-built support for encrypting/decrypting the at-rest messages in the queue? I suppose that producer could encrypt and consumer decrypt. But I was hoping to avoid a "roll your own" approach.
> >
> >
> >
> > I am trying to think about a rogue producer injecting meaningful messages into the queue, i.e., a message whose processing might return a valuable data resource. Then there's also the need to prevent someone from inspecting the queue with an eye to reverse-engineering message syntax.
> >
> >
> >
> > Thanks.
> >
> >
> >
> > -Paul
> >
> > ________________________________
> >
> >
> > ATTENTION: -----
> >
> > The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.
> 
> > _______________________________________________
> > rabbitmq-discuss mailing list
> > rabbitmq-discuss at lists.rabbitmq.com
> > https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss