编辑＃2 2015年7月23日：寻找一个新的答案，确定一个重要的安全项目错过了在下面的设置或可以给出理由相信一切都涵盖。
编辑＃3 2015年7月29日：我正在寻找一种可能的错误configuration，比如无意中允许某些可能被利用来绕过安全限制或者更糟糕的事情而让事情变得更加严重。
这是多站点/共享主机设置，我们希望使用一个共享的Apache实例（即在一个用户帐户下运行），但PHP / CGI作为每个网站的用户运行，以确保没有网站可以访问另一个网站的文件，我们希望确保没有错过任何东西（例如，如果我们不知道符号链接攻击预防）。
以下是我到目前为止：
Options IncludesNOEXEC可以防止CGI在你不期望的情况下运行（尽pipe如果使用suexec，这应该不是那么重要）。 AllowOverride / AllowOverrideList只允许黑客无法利用的任何指令。 如果上述项目正确完成，我认为这不是一个问题。 如果不是很慢并且不能以root身份运行，我会select使用MPM ITK，但是我们特别想使用共享的Apache，但是确保它安全地完成。
我发现http://httpd.apache.org/docs/2.4/misc/security_tips.html ，但这个话题并不全面。
如果知道这很有帮助，我们打算将CloudLinux与CageFS和mod_lsapi配合使用。
还有什么可以确保要做或知道吗？
编辑2015年7月20日：人们已经提交了一些很有价值的替代解决scheme，但请注意，这个问题只针对共享Apache安装的安全性。 特别是有没有覆盖以上可以让一个网站访问另一个网站的文件或妥协其他网站？
谢谢！
我完全同意你到目前为止的项目。
我几年前运行这样的多用户设置，我基本上find了相同的权衡：mod_php是快速的（部分是因为一切运行在同一个进程内）和suexec是缓慢但安全的（因为每个请求都要求一个新的处理）。 我用suexec去，因为用户隔离是必需的。
目前还有第三个选项可以考虑：给每个用户自己的php-fpm守护进程。 这是否可行取决于用户的数量，因为他们每个人都必须使用他们的用户帐户至less获得一个php-fpm进程（守护进程然后使用类似prefork的机制来扩展请求，所以进程的数量和他们的内存使用可能是限制因素）。 您还需要一些自动化的configuration生成，但应该可以通过几个shell脚本来实现。
我没有在大型环境中使用这种方法，但恕我直言，这是一个很好的解决scheme，提供良好的PHP网站的性能，同时仍然隔离在过程级别的用户。
你到目前为止所做的一切似乎都经过深思熟虑 我能看到的唯一问题就是大多数的漏洞利用这种或那种方式获得根源。 所以，即使每个站点及其相应的进程和脚本都被正确监禁，并且每个站点都有自己的用户和权限，但是一个黑客根本无所谓，他们只会回避您设置的所有内容。
我的build议是使用某种虚拟机软件（VMware，VirtualBox，Qemu等）为每个站点提供自己的操作系统监狱。 这使得作为系统pipe理员，您不必担心单个受感染的站点。 如果黑客通过利用站点虚拟机上的php（或任何其他软件）获得root权限，则只需稍后暂停虚拟机并parsing该虚拟机，应用修复或回退到完整状态。 这也允许网站pipe理员将特定的软件或安全设置应用于其特定的网站环境（这可能会破坏另一个网站）。
唯一的限制是你的硬件，但有一个体面的服务器和正确的内核扩展这很容易处理。 我已经成功地在Linode上运行这种types的设置，同时授予Host和Guest都非常稀疏。 如果你对我所设想的命令行感到满意，那么你应该不会有任何问题。
这种types的设置减less了您必须监视的攻击媒介的数量，并允许您专注于主机安全性，并逐个网站地处理网站上的所有其他内容。
我build议让每个站点在自己的Apache守护进程下运行，并且chroot Apache。 由于Apache chroot环境将无法访问/ bin / sh，因此所有系统php函数都将失败。 这也意味着php的mail（）函数也不能工作，但是如果你使用外部邮件提供者从你的电子邮件应用程序发送邮件，那么这对你来说应该不成问题。
SELinux可能对mod_selinux有帮助。 这里有一个快速的说明：
我如何使用SELinux来限制PHP脚本？
由于说明有点过时，我检查了这是否适用于RHEL 7.1：
我已经使用了Fedora 19的版本 ，并对RHEL 7.1 + EPEL进行了模拟编译。
YMMV如果你使用基本的epel config mock附带：
[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \ mod_selinux-2.4.3-2.fc19.src.rpm
首先升级您的目标系统，以确保selinux-policy是最新的。
在目标框上安装（或先安装在本地镜像上）：
yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm
现在，你必须将每个虚拟主机分配给apache一个类别。 这是通过添加一个如下例所示的
selinuxDomainVal。<VirtualHost *:80> DocumentRoot /var/www/vhosts/host1 ServerName host1.virtual selinuxDomainVal *:s0:c0 </VirtualHost> <VirtualHost *:80> DocumentRoot /var/www/vhosts/host2 ServerName host2.virtual selinuxDomainVal *:s0:c1 </VirtualHost>接下来，在每个主机的文档根目录中，将它们的文档根目录重新标记为与httpdconfiguration中标记的类别相同的类别。
chcon -R -l s0:c0 /var/www/vhosts/host1 chcon -R -l s0:c1 /var/www/vhosts/host2如果你想使标签得到尊重，如果你做一个系统relabel，你最好更新本地政策！
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'
已经提供了很多很好的技术答案（请在这里看一下： https : //security.stackexchange.com/q/77/52572和保护LAMP服务器的技巧 ），但是我仍然想在这里提到（从另一个angular度来看）关于安全性的重要一点： 安全性是一个过程 。 我相信你已经考虑到了这一点，但是我仍然希望它有时候能够重新思考它（也适用于其他读者）。
例如，在你的问题中，你主要关注技术措施：“这个问题只针对共享Apache安全的安全问题，特别是在运行共享时，是否有任何重要的安全措施， Apache和PHP“。
几乎所有的答案在这里和我提到的其他两个问题似乎也是纯粹的技术（除了build议保持更新）。 而从我的angular度来看，这可能会让一些读者产生误解，如果您根据最佳实践configuration您的服务器，那么您将永远保持安全。 所以请不要忘记我在答案中想念的几点：
首先，不要忘记， 安全是一个过程 ，尤其是“计划 – 执行 – 检查 – 行动”周期的过程，正如包括ISO 27001（ http://www.isaca.org/）在内的许多标准所build议的那样。 Journal / archives / 2011 / Volume-4 / Pages / Planning-for-and-Implementing-ISO27001.aspx ）。 基本上，这意味着你需要定期修改你的安全措施，更新和testing它们 。
定期更新你的系统。 这不会有助于抵御使用零日漏洞的有针对性的攻击，但这将有助于抵御几乎所有的自动攻击。
监视你的系统。 我真的错过了这个答案。 从我的angular度来看，尽早通知您的系统存在一些问题是非常重要的。
统计数据显示：“从渗透到发现的平均时间为173.5天”（ http://www.triumfant.com/detection.html），“205检测前天数”（ https：// www2 .fireeye.com / rs / fireye / images / rpt-m-trends-2015.pdf ）。 我希望这些数字不是我们想要的。
有很多解决scheme（包括免费）不仅用于监控服务状态（如Nagios），还包括入侵检测系统（OSSEC，Snort）和SIEM系统（OSSIM，Splunk）。 如果过于复杂，至less可以启用“fail2ban”之类的function和/或将日志转发给单独的系统日志服务器，并且可以发送有关重要事件的电子邮件通知 。
再一次，这里最重要的一点不是你select哪个监控系统， 最重要的是你有一些监控，并根据你的“计划 – 执行 – 检查 – 行动”周期进行定期修改 。
注意漏洞。 同监视一样。 只要订阅了一些漏洞列表即可获得通知，当Apache或其他服务发现了一些重要的漏洞时，这些漏洞对您的设置很重要。 目标是通知您在下次计划更新之前出现的最重要的事情。
制定一个事件发生的计划（根据您的“计划 – 执行 – 检查 – 行动”周期定期更新和修改）。 如果您提出有关安全configuration的问题，则意味着系统的安全性对您而言变得重要。 但是，如果您的系统在所有安全措施下遭到黑客入侵，您应该怎么办？ 再说一次，我的意思不仅仅是“重新安装操作系统”这样的技术措施：根据适用法律你应该在哪里报告事故？ 您是否被允许立即closures/断开您的服务器（您的公司花费多less）？ 如果主要负责人在休假/生病，应该联系谁？
有备份，存档和/或replace/复制服务器。 安全性也意味着您的服务的可用性。 定期检查备份/归档/复制，并定期testing恢复过程。
渗透testing？ （再次参见“Plan-Do-Check-Act”循环:)如果感觉太多了，至less可以尝试一些免费的在线工具，它们会扫描您的Web服务以查找恶意软件和安全问题。
您的使用案例是docker集装箱的理想select。
每个容器都可以代表一个客户或客户端，为每个Apache容器组分配唯一的用户ID作为增加的安全性。 关键是在开始你的apache堆栈之前，在容器启动时删除root权限。 每个客户都拥有自己的数据库服务，并拥有自己独特的密码，而不必担心数十台虚拟机，每台虚拟机都需要自己的特殊雪花内核和其他开销。 毕竟，在docker的核心是chroot。 妥善pipe理，我会把它放在一个典型的虚拟集群上。
这里有很多好的build议。 到目前为止，在讨论中已经错过了一些东西。
请关注作为服务网页一部分运行的进程以外的进程。 即确保所有触及不可信数据的cron作业都以适当的用户身份运行，并在相应的监牢中运行，无论这些作业是否由用户定义。
根据我的经验，日志分析（如果由主机服务提供）以root身份运行，而日志分析软件的安全审计并不像我们想要的那样多。 这样做是有点棘手，并依赖于设置。 一方面，你不希望你的根拥有（即父进程）Apache进程写入任何目录，用户可能会妥协。 这可能意味着不直接向监狱写信。 另一方面，您需要将这些文件提供给监狱中的进程进行分析，并且希望尽可能接近实时。 如果你可以让你的监狱访问日志文件系统的只读安装，那应该是好的。
PHP应用程序通常不提供自己的静态文件，如果你有一个共享的apache进程，那么我猜你的apache进程正在从主机环境中直接从jails读取东西？ 如果是这样，那么这就引发了各种各样的担忧。
.htaccess文件是一个明显的，你需要非常小心你允许的。 许多如果不是最重要的PHP应用程序是非常依赖.htaccess文件安排，你可能不会允许不破坏你的计划scheme。
不太明显的是，apache如何决定什么是静态文件。 例如，它对一个*.php.gif或*.php.en文件做了什么？ 如果这个机制或者另一个愚弄什么是一个静态文件的歧视，是否有可能从监狱之外的所有Apache运行PHP？ 我将为静态内容设置一个单独的轻量级Web服务器，该服务器没有configuration任何用于执行dynamic内容的模块，并且负载平衡器决定将哪些请求发送到静态服务器，哪些请求发送到静态服务器。
关于Stefan的Dockerbuild议，可能有一个位于容器外的Web服务器，它与每个容器中的php守护进程对话以获取dynamic内容，同时还有一个位于Docker容器中的第二个Web服务器，以及它们共享各自用于其内容的卷，并因此能够提供静态内容，这与上一段中的内容大致相同。 我赞扬docker工人在各种监狱types的方法中，但有了这种或其他的监狱types的方法，你将有一堆其他问题的工作。 file upload如何工作？ 你把文件传输守护进程放在每个容器中吗？ 你采取PAAS风格的基于Git的方法？ 你如何使容器内部生成的日志可访问，并将它们翻转过来？ 你如何pipe理和运行cron作业？ 你是否要给用户任何types的shell访问权限，如果是的话，容器内的另一个守护进程？ 等等
我没有看到的第一件事就是进程pipe理，所以一个进程不能挨饿CPU或RAM的另一个进程（或者就此而言I / O，尽pipe你的文件系统可能被devise来防止这种进程）。 对于PHP实例，“容器”方法的一个主要优势在于，试图在一个“操作系统”映像上运行它们的一个主要优点是可以更好地限制资源利用率。 我知道这不是你的devise，但这是要考虑的事情。
无论如何，回到Apache后面运行的PHP的用例，基本上它是一个代理。 suexec不会阻止某些东西作为apache用户运行 – 它提供了以另一个用户身份运行的function 。 所以一个担心的事情就是要确保所有的工作都正确完成 – doc页面提出了潜在的危险： https ： //httpd.apache.org/docs/2.2/suexec.html 。 所以，你知道，盐和所有这一切。
从安全的angular度来看，有一组用户的二进制文件可以用来处理（哪些cagefs文件），特别是如果编译的方式不同或针对不同的库（例如不包含不需要的function的库）危险的是，在那个时候，你不再遵循一个已知的更新发布版本，你正在为PHP安装（至less在用户空间工具方面）遵循不同的发行版（cagefs）。 虽然您可能已经在使用cloudlinux进行特定的分发，但这是一个增量风险，并不一定有意思。
我会离开AllowOverride在你可能有意的地方。 深层防御的核心思想是不依靠单一层来保护你的整个堆栈。 总是假设一些事情可能会出错。 缓解这种情况。 重复，直到你减轻，即使你只有一个围栏在你的网站前。
日志pipe理将是关键。 由于多个服务运行在独立的文件系统中，如果您从一开始就没有设置这些服务，那么集成活动以便在出现问题时进行关联可能会造成轻微的麻烦。
这是我的头脑转储。 希望有一些在那里模糊的东西。 🙂