多站点托管 - 错过重要漏洞以保护站点彼此之间的安全？

Question

编辑 #2 2015 年 7 月 23 日：寻找一个新的答案，以识别以下设置中遗漏的重要安全项目，或者可以让我们有理由相信一切都已涵盖。

编辑 #3 2015 年 7 月 29 日：我特别在寻找可能的错误配置，例如无意中允许可能被利用来规避安全限制的东西，或者更糟的是却留下了一些大的漏洞。

这是多站点/共享主机设置，我们希望使用共享 Apache 实例（即在一个用户帐户下运行），但 PHP/CGI 以每个网站的用户身份运行，以确保没有站点可以访问另一个站点的文件，我们希望确保没有遗漏任何内容（例如，如果我们不知道符号链接攻击预防）。

这是我到目前为止所拥有的：

• 确保 PHP 脚本作为网站的 Linux 用户帐户和组运行，并且被监禁（例如使用 CageFS）或至少使用 Linux 文件系统权限进行适当限制。
• 使用 suexec 确保 CGI 脚本不能以 Apache 用户身份运行。
• 如果需要服务器端包含支持（例如在 shtml 文件中），请使用Options IncludesNOEXEC以防止 CGI 在您不希望它运行时能够运行（尽管如果使用 suexec，这应该不是什么大问题）。
• 具有符号链接攻击保护，以便黑客无法欺骗 Apache 以纯文本形式提供另一个网站的文件并披露可利用的信息，例如数据库密码。
• 将AllowOverride/配置AllowOverrideList为仅允许黑客无法利用的任何指令。我认为如果上述项目做得正确，这就不那么重要了。

如果 MPM ITK 不是那么慢并且不是以 root 身份运行，我会选择它，但我们特别想使用共享的 Apache，但要确保它安全地完成。

我找到了http://httpd.apache.org/docs/2.4/misc/security_tips.html，但它在这个主题上并不全面。

如果有帮助的话，我们计划将 CloudLinux 与 CageFS 和 mod_lsapi 一起使用。

还有什么需要确保做或知道的吗？

编辑 2015 年 7 月 20 日：人们提交了一些很好的替代解决方案，这些解决方案通常很有价值，但请注意，此问题仅针对共享 Apache 设置的安全性。具体来说，是否有上面未涵盖的内容可以让一个站点访问另一个站点的文件或以某种方式危害其他站点？

谢谢！

Answer 1

我完全同意您目前拥有的项目。

几年前我曾经运行过这样的多用户设置，我基本上发现了相同的权衡：mod_php 很快（部分原因是所有内容都在同一个进程中运行），而 suexec 很慢但很安全（因为每个请求都会分叉一个新的过程）。我选择了 suexec，因为需要进行用户隔离。

目前，您可能会考虑第三种选择：为每个用户提供自己的 php-fpm 守护程序。这是否可行取决于用户数量，因为他们每个人都必须使用他们的用户帐户获得至少一个 php-fpm 进程（守护进程然后使用类似 prefork 的机制来扩展请求，因此进程的数量和它们的内存使用可能是限制因素）。您还需要一些自动配置生成，但这应该可以通过一些 shell 脚本来实现。

我没有在大型环境中使用过这种方法，但恕我直言，这是一个很好的解决方案，可以提供良好的 PHP 网站性能，同时仍然在进程级别隔离用户。