多站点托管-错过了使站点彼此安全的重要漏洞吗？

编辑＃2，2015年7月23日：寻找一个新的答案，以识别在以下设置中缺少的重要安全项目，或者可以给出理由相信所有内容均已涵盖。

编辑＃3，2015年7月29日：我特别在寻找可能的配置错误，例如无意中允许某些可被利用来规避安全限制或更糟的东西，但仍未解决的问题。

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

这是我到目前为止的内容：

• 确保PHP脚本以网站的Linux用户帐户和组身份运行，并且被监禁（例如使用CageFS）或至少使用Linux文件系统权限进行了适当限制。
• 使用suexec以确保CGI脚本不能以Apache用户身份运行。
• 如果需要服务器端包含支持（例如shtml文件中的支持），请使用它Options IncludesNOEXEC来防止CGI在您不希望的时候运行（尽管使用suexec并不会引起太大的关注）。
• 拥有symlink攻击保护功能，这样黑客就不会欺骗Apache以纯文本形式提供另一个网站的文件，也不会泄露DB密码之类的可利用信息。
• 配置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设置的安全性。特别是上面没有提到的东西可以使一个站点访问另一个站点的文件或以某种方式危害其他站点吗？

谢谢！

我完全同意您到目前为止的项目。

几年前，我曾经运行过这样的多用户安装程序，但我基本上发现了一个折衷方案：mod_php速度很快（部分是因为所有内容都在同一进程中运行），而suexec速度却很慢但很安全（因为每个请求都会派生一个新的）处理）。我使用suexec，因为需要用户隔离。

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

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

到目前为止，您所拥有的一切似乎都经过深思熟虑。我唯一看到的问题是大多数漏洞利用一种或另一种方式获取根访问权限的事实。因此，即使每个站点及其相应的过程和脚本都被正确监禁并且所有内容都有其自己的用户和权限，具有root用户的黑客也不会在意，他们只会避开您已设置的所有内容。

我的建议是使用某种VM软件（VMware，VirtualBox，Qemu等）为每个站点分配自己的OS监狱。作为系统管理员，这使您不必担心单个受感染的站点。如果黑客通过利用站点VM上的php（或任何其他软件）获得根源，则只需暂停VM并稍后对其进行剖析，应用修补程序或恢复到不间断状态。这还允许站点管理员将特定的软件或安全设置应用于其特定的站点环境（这可能会破坏另一个站点）。

唯一的限制是您的硬件，但要有一个不错的服务器和正确的内核扩展，这很容易处理。我已经成功地在Linode上运行了这种类型的设置，因为主机和来宾都非常稀疏。如果您对我认为的命令行感到满意，那么您应该不会有任何问题。

这种类型的设置减少了您必须监视的攻击媒介的数量，并使您可以专注于主机安全性并逐站点处理其他所有事件。

我建议让每个站点都在其自己的Apache守护程序下运行，并根目录Apache。由于Apache chroot环境无法访问/ bin / sh，因此所有系统php功能都将失败。这也意味着php的mail（）函数也无法正常工作，但是，如果您使用外部邮件提供商从电子邮件应用程序发送邮件，那么这对您来说就不成问题。

SELinux可能对有所帮助mod_selinux。这里有一个快速的howto：

如何使用SELinux限制PHP脚本？

由于说明有些过时，因此我检查了它是否适用于RHEL 7.1：

我使用了Fedora 19的版本，并针对RHEL 7.1 + EPEL进行了模拟编译。

YMMV（如果您使用基本的epel config模拟程序附带）：

[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>

接下来，在每个主机的文档根目录中，将其文档根目录重新标记为与httpd配置中标记的目录相同的类别。

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

如果您想重新标记系统而使标记获得荣誉，则最好也更新本地策略！

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服务器的安全提示），但是我仍然想在这里提及关于安全性的另一个重要方面（从另一个角度来看）：安全性是一个过程。我相信您已经考虑过了，但是我仍然希望有时重新考虑它可能对其他读者也有用。

例如，在您的问题中，您主要集中在技术措施上：“此问题仅针对共享Apache安装程序的安全性。具体来说，是否有重要的安全步骤需要执行，但在运行共享时会从上面的列表中丢失Apache和PHP。”

在这里以及我提到的其他两个问题上，几乎所有答案似乎都是纯技术性的（建议不要更新）。从我的角度来看，这可能会使一些读者产生误解，如果您根据最佳实践配置服务器一次，则将永远保持安全。因此，请不要忘记我在答案中遗漏的要点：

1. 首先，请不要忘记，安全性是一个过程，尤其是有关“计划-执行-检查-行动”周期的过程，正如许多标准（包括ISO 27001）所建议的那样（http://www.isaca.org/ Journal / archives / 2011 / Volume-4 / Pages / Planning-for-and-Implementing-ISO27001.aspx）。基本上，这意味着您需要定期修改安全措施，进行更新和测试。

2. 定期更新您的系统。这将无助于使用零日漏洞的有针对性的攻击，但将有助于抵御几乎所有自动攻击。

3. 监视您的系统。我真的在答案中缺少这一点。从我的角度来看，尽快通知您的系统问题非常重要。

   这就是统计数据所说的：“从渗透到发现的平均时间为173.5天”（http://www.triumfant.com/detection.html），“ 从检测到发现前的中位数为205天”（https：// www2 .fireeye.com / rs / fireye / images / rpt-m-trends-2015.pdf）。我希望这些数字不是我们所有人想要的。

   有很多解决方案（包括免费），不仅可以监视服务状态（如Nagios），而且还可以监视入侵检测系统（OSSEC，Snort）和SIEM系统（OSSIM，Splunk）。如果变得太复杂，则至少可以启用“ fail2ban”之类的功能和/或将日志转发到单独的syslog服务器，并获得有关重要事件的电子邮件通知。

   同样，这里最重要的一点不是您选择哪个监视系统，最重要的是您有一些监视并根据“计划-执行-检查-执行”周期定期进行修改。

4. 注意漏洞。与监视相同。当发现Apache或其他对您的设置很重要的服务的某个严重漏洞时，只需订阅一些漏洞列表即可得到通知。我们的目标是在您下一次计划的更新之前通知您最重要的事情。

5. 制定一个计划以防万一发生事故（并根据您的“计划-执行-检查-执行”周期定期进行更新和修订）。如果您询问有关安全配置的问题，则意味着系统的安全性对您来说很重要。但是，如果采取了所有安全措施，如果系统被黑客入侵，该怎么办？同样，我在这里并不是仅指“重新安装操作系统”之类的技术措施：根据适用法律，您应该在哪里报告事故？是否允许您立即关闭/断开服务器的连接（对您的公司来说要花费多少钱）？如果主要负责人正在休假/生病，应与谁联系？

6. 拥有备份，存档和/或替换/复制服务器。安全性还意味着服务的可用性。定期检查备份/存档/复制，并定期测试还原过程。

7. 渗透测试？（同样，请参阅“计划-执行-检查-执行”循环：）如果感觉太多，您至少可以尝试一些免费的在线工具，该工具会扫描Web服务中的恶意软件和安全性问题。

您的用例非常适合docker容器。

每个容器可以代表一个客户或客户，并为每个Apache容器组分配唯一的用户ID，以增加安全性。关键是在启动apache堆栈之前，在容器启动时放弃root特权。每个客户都可以使用自己的唯一密码获得自己的数据库服务，而不必忍受站起来的数十个虚拟机，每个虚拟机都需要自己的专用雪花内核和其他开销。毕竟，docker的核心是chroot。如果管理得当，我每天都会把它放在一个典型的虚拟集群上。

这里已经有很多好的建议。到目前为止，在讨论中仍然遗漏了一些东西。

注意那些作为服务网页的一部分运行的进程之外的进程。即，确保所有涉及不受信任数据的cron作业都以适当的用户身份在适当的监狱中运行，无论这些作业是否由用户定义。

以我的经验，当由托管服务提供日志分析之类的东西时，它几乎几乎没有以root身份运行，并且日志分析软件没有像我们所希望的那样进行安全审核。做到这一点有些棘手，并且取决于安装程序。一方面，您不希望您的根所有者（即父进程）的apache进程写入用户可能会破坏的任何目录。那可能意味着不直接写进监狱。另一方面，您需要使这些文件可用于监狱中的进程以进行分析，并且您希望该文件尽可能接近实时。如果您可以让监狱使用日志访问文件系统的只读装载，那应该很好。

PHP应用程序通常不提供自己的静态文件，如果您有一个共享的apache进程，那么我猜您的apache进程正在从主机环境中直接读取文件吗？如果是这样，那么就会带来各种各样的担忧。

.htaccess文件是显而易见的文件，您需要非常小心允许的内容。许多（如果不是大多数）实质性的php应用程序都非常依赖.htaccess文件的排列方式，而如果不破坏计划的方案，您可能不允许这样做。

不太明显的是，Apache如何确定什么是静态文件。例如，对*.php.gif或*.php.en文件有什么作用？如果此机制或其他机制愚弄了关于什么是静态文件的歧视，那么apache是​​否有可能从监狱外部完全运行php？我将为静态内容设置一个单独的轻量级Web服务器，该服务器未配置任何用于执行动态内容的模块，并且有一个负载平衡器来决定将哪些请求发送到静态服务器，将哪些请求发送到动态服务器。

关于Stefan的Docker建议，有可能有一个位于容器外部的Web服务器，该服务器与每个容器中的php守护进程进行通信以获取动态内容，同时还有另一个Web服务器位于Docker容器中，并且它共享各自用于其内容的卷，因此能够提供静态内容，这与上一段非常相似。我推荐docker使用各种监狱类型的方法，但是使用这种或其他监狱类型的方法，您将遇到很多其他问题。文件上传如何工作？您是否将文件传输守护程序放在每个容器中？您是否采用基于PAAS风格的git方法？如何使容器内部生成的日志可访问，滚过来 您如何管理和运行Cron作业？您是否要为用户提供任何类型的Shell访问权限，如果可以，容器中是否还有另一个守护程序？等等等

我没有看到的第一件事是进程管理，因此一个进程不会饿死另一个进程的CPU或RAM（或I / O，尽管您的文件系统可能是为防止这种情况而设计的）。与尝试在一个“ OS”映像上运行所有实例相比，对您的PHP实例采用“容器”方法的一个主要优点是可以更好地限制资源利用率。我知道这不是您的设计，但这是需要考虑的事情。

无论如何，回到在Apache后面运行的PHP的用例中，它基本上起着代理的作用。suexec的并没有阻止一些运行于Apache的用户-它提供的能力，以其他用户身份运行。因此，一个问题是要确保一切都正确完成-它的文档页面指出了潜在的危险：https : //httpd.apache.org/docs/2.2/suexec.html。所以，你知道，盐粒等等。

从安全角度来看它可以是有帮助的受限制的用户二进制文件工作，（这cagefs用品），尤其是当它们以不同方式或针对不同的库编译（例如，一个不包括那些不需要的功能），但在危险在于，此时您将不再遵循已知的更新分发，而是针对PHP安装（至少在用户空间工具方面）遵循不同的分发（cagefs）。尽管由于您可能已经在使用cloudlinux进行特定的发行，这是一个增加的风险，但不一定一定会很有趣。

我会将AllowOverride留在您可能打算使用的地方。深度防御背后的核心思想是不依赖单个层来保护您的整个堆栈。始终假设可能会出问题。缓解这种情况。重复该步骤，直到您缓解得最好为止，即使您的站点前只有一个栅栏也是如此。

日志管理将成为关键。如果在隔离的文件系统中运行多个服务，那么如果您没有从头开始设置问题，那么集成活动以在出现问题时进行关联可能会遇到轻微的麻烦。

那是我的脑筋。希望那里有些隐约有用的东西。:)