[rabbitmq-discuss] Securing RabbitMQ

[Bell, Paul M.]

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