Security 如何在恶意云环境中保护memcached/beanstalk？

以下是我的服务器（在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 | / __________________________ 服务器1服务器2服务器3 __________________________ _____________________ _______________ |云监视器守护程序| | Memcached守护程序| | | beanstalkd| || | Memcached守护进程|________________ |“恶意”用户进程|/| Memcached守护进程| |“恶意”用户进程|/| Memcached守护进程| |“恶意”用户进程|/| Memcached守护进程| |“恶意”用户进程|/______________________ |“恶意”用户进程/ __________________________ 一台服务器上有多个用户进程。然后，每个用户都有自己的memcached实例在（单独的）服务器上运行（与许多其他memcached实例一起）。在没有任何安全性的情况下（默认情况下），用户进程B可以猜测用户A的memcached实例的端口并访问它。如何保护此系统，使用户C只能访问memcached实例C而不能访问其他实例（即使memcached实例都在同一台服务器上）？我的用户不必做任何事情来利用安全性（只需像往常一样继续连接到memcached端口），这一切都应该由系统自动完成

---

此外，服务器上的云监控守护程序以及“恶意”用户进程需要能够访问远程beanstalkd服务器。Beanstalkd也没有身份验证，因此如果我的监视器守护进程可以访问Beanstalkd，“恶意”用户进程也可以访问Beanstalkd，我不希望这样。如何保护此部件？

我最近提到了一些保护内存缓存的技巧。对于你的情况，SASL可能会有很大帮助

我不知道beanstalk是否获得过SASL支持，但那是一种不同的应用程序

---

当然，您可以构建VPN或启用IPSEC以在节点级别控制对所有计算机上所有服务的访问。

您可以在Server3本地IP（127.0.0.1）上启动beanstalkd 然后使用从服务器1到服务器3的SSH隧道。

---

将它与inetd和ssh密钥结合起来以实现故障保护。

我最终选择了普通的旧iptable。允许我执行每uid规则，并且很容易通过编程进行配置。最重要的是，用户不需要参与这个过程，他们可以继续使用标准协议，而不必处理身份验证，iptables将丢弃任何不该丢弃的“顽皮”数据包。

几周前亚马逊宣布了（虚拟私有云）我们用它来保护memcached和beanstalkd

---

很好！认真地复述；减少了我们自己的开销。

我昨天花了几个小时尝试构建一个客户端，发现SASL+memcached二进制协议非常难使用。此外，beanstalkd不支持SASL，因此我考虑在beanstalkd周围创建一个服务器“代理”包装器（只有代理可以直接访问beanstalkd服务器）。我可能会对memcached执行同样的操作，并禁用SASL。这将在整个平台上一致地处理身份验证。您正在尝试哪个客户端？显然，我们想让它们更容易使用，但我们还没有做到所有这些。类似地，我们有moxi将本地主机未经身份验证的客户端连接到远程身份验证的服务器（尽管这显然会降低您的速度）。