如何在敌对的云环境中保护 memcached/beanstalkd 的安全？
我的服务器（在 Amazon EC2 中）如下所示：
Server 1 Server 2 Server 3 __________________________ _____________________ _______________ | Cloud Monitor Daemon | | Memcached daemon | | beanstalkd | | | | Memcached daemon | ________________ | "Hostile" user process | / | Memcached daemon | | "Hostile" user process | / | Memcached daemon | | "Hostile" user process | / | Memcached daemon | | "Hostile" user process | / ______________________ | "Hostile" user process | / __________________________
一台服务器上有多个用户进程。然后，每个用户都有自己的 memcached 实例在（单独的）服务器上运行（以及许多其他 memcached 实例）。如果没有任何类型的安全性（默认情况下），用户进程 B 可以猜测用户 A 的 memcached 实例的端口并访问它。我如何保护该系统，以便用户 C 只能访问 memcached 实例 C 而不能访问其他实例（即使 memcached 实例都在同一服务器上）？我的用户不需要做任何事情来利用安全性（只需像往常一样继续连接到 memcached 端口），这一切都应该由系统自动发生。
此外，服务器上的云监控守护进程以及“敌对”用户进程需要能够访问远程 beanstalkd 服务器。 Beanstalkd 也没有身份验证，因此如果我的监视器守护进程可以访问 beanstalkd，“敌对”用户进程也可以访问，但我不希望这样。我怎样才能保护这部分？
Here's how my servers (in Amazon EC2) would look like:
Server 1 Server 2 Server 3
__________________________ _____________________ _______________
| Cloud Monitor Daemon | | Memcached daemon | | beanstalkd |
| | | Memcached daemon | ________________
| "Hostile" user process | / | Memcached daemon |
| "Hostile" user process | / | Memcached daemon |
| "Hostile" user process | / | Memcached daemon |
| "Hostile" user process | / ______________________
| "Hostile" user process | /
__________________________
There's multiple user processes on one server. Each user then has their own memcached instance running on a (separate) server (with many other memcached instances). Without any sort of security (as it is by default), user process B could guess the port of the memcached instance of user A and access it. How can I secure this system so that user C could only access memcached instance C and no other (even though the memcached instances are all on the same server)? My user should not have to do anything to make use of the security (just continue connecting to the memcached port as usual), it should all happen automatically by the system.
Also, the Cloud Monitor Daemon on the server along with the "hostile" user processes needs to be able to access a remote beanstalkd server. Beanstalkd has no authentication either, so if my Monitor Daemon can access beanstalkd, so can the "hostile" user processes, and I don't want that. How can I secure this part?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我最近在博客文章中提到了一些有关保护 memcached 的提示。对于您的情况，SASL 可能会有很大帮助。
我不知道 beanstalk 是否获得了 SASL 支持，但那是一个不同的应用程序。
当然，您可以构建VPN或启用IPSEC来控制对节点级别的所有计算机上的所有服务的访问。
I mentioned some tips on securing memcached in a blog post recently. For your case, SASL will probably help a lot.
I don't know if beanstalk ever got SASL support, but that's kind of a different app.
You could build a VPN or enable IPSEC to control access to all services on all machines at the node level, of course.
您可以在Server3本地IP（127.0.0.1）上启动beanstalkd
然后使用从服务器 1 到服务器 3 的 SSH 隧道。
将其与 inetd 和 ssh-keys 结合起来以确保故障安全。
You can start beanstalkd on Server3 local IP (127.0.0.1)
and then use SSH Tunnels from the Server 1 to Server 3.
Combine it with inetd and ssh-keys to be failsafe.
我最终选择了普通的旧 iptables。允许我执行每个 uid 的规则，并且非常容易以编程方式配置。最重要的是，用户不需要参与这个过程，他们可以继续使用标准协议，而不必处理身份验证，并且 iptables 会丢弃任何不该发送到的“顽皮”数据包。
I ended up going with plain old iptables. Allows me to do per-uid rules and is very easy to configure programatically. Most importantly, the users don't need to be involved in the process, they can continue using the standard protocols and not have to deal with authentication, and iptables will drop any "naughty" packets that are going where they shouldn't.
几周前，Amazon 宣布推出 Amazon VPC（虚拟私有云），我们用它来保护 memcached和豆茎。
效果很好！认真推荐它；减少我们自己处理的开销。
A couple weeks ago Amazon has announced the Amazon VPC (Virtual Private Cloud) which we are using to secure memcached and beanstalkd.
Works great! Seriously reccomend it; one less overhead to have to deal with ourselves.