views:

98

answers:

3

So what I like about beanstalkd: small, lightweight, has priorities for messages, has a great set of clients, easy to use.

What I dislike about beanstalkd: the lack of authentication menaing if you can connect to the port you can insert messages into it.

So my thoughts are to either firewall it to trusted systems (which is a pain to maintain and external to the application adding another layer of stuff to do) or to wrap it in TLS/SSL using something like stunnel (which will incur a good chunk of overhead with respect to establishing connections and whatnot). I did think of maybe signing jobs (MD5 or SHA of job string+time value+secret appended to the job), but if an attacker were to flood the server with bogus jobs I'd still be in trouble. Can anyone think of any other methods to secure the beanstalkd against insertion of bogus messages from an attacker? Especially those that don't incur a lot of overhead computationally or administratively.

A: 

This question really belongs on the beanstalkd talk list.

I added SASL support to memcached recently for a similar reason. The overhead is almost irrelevant in practice since you only authenticate at connect time (and you hold connections open indefinitely).

If authentication is something you need, I'd recommend bringing it up there where people are likely to help you solve your problems.

Dustin
That's not always possible (holding a connection open forever). In any event the reason I ask here is it's not a complete deal breaker, and I also want a solution I can apply now, this is also for an article I'm writing and saying "here's how to secure it.." is a lot better than "the devs are thinking of adding support for foo... someday maybe. Until then good luck!" =) Editors hate that sort of stuff (a.k.a. "This is left as an exercise to the reader").
Kurt
+1  A: 

I have to disagree about the practice of just having connections being held open indefinitely, since I use BeanstalkD from a web-scripting language (php) for various events. The overhead of opening a secure connection would be something I would have to think very carefully over.

Like Memcached, beanstalkd is designed for use in a trusted environment - behind the firewall. If you don't control the entire private network, then limiting access to a set of machines (by IP address) would be a typical way of controlling that. Putting in a security hash to then throw away invalid jobs is not difficult, and has little work or overhead to check, but wouldn't stop a flood of jobs being sent.

The questions to ask are 'How often are your machines likely to be added to (at random IP addresses outside of a given range), and how likely is a third party that is also on the local network would want to inject random jobs to your queues?'. The first part is about how much work is it to firewall the machines off, the latter is about do you need to anyway?

Alister Bulman
I like things to be closed up and as secure as possible by default, onion layer security. I would like to avoid adding a layer of administrative overhead that's in a totally different system (i.e. firewall) and keep the access controls within beanstalkd/application or do it in such a way that you don't have to fiddle with system settings everytime you want a change (i.e. with SSL the stunnel needs to be fiddled, which is an application level issue, the firewall is a system level issue).
Kurt
A: 

I do two things that reduce the issue you are refererring to:

First I always run beanstalkd on 127.0.0.1

Second, I normally serialize the job structure, and load a "secret key" encrypted base64 digest as the job string. Only workers that can decrypt the job string correctly can parse jobs.

I know that this is certainly not a substitute for authentication. But I hope they do minimize to some extent some one hijacking enqueued jobs.

Gurunandan
Running it on localhost only also means I can't remotely access it without adding another layer like OpenSSH or something to do a port redirect. If I only needed it locally I'd just use a Python queue.
Kurt
Clearly then, running the service on localhost cannot be an option for you. Does serializing and encrypting help?
Gurunandan