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 inse开发者_Go百科rt 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.
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?
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.
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.
精彩评论