选择 Web 服务器软件以确保安全

Question

Nginx 是市场上相对较新的开源 Web 服务器，最近引起了一些兴趣，在过去几年中在某些基准测试中表现非常出色。

在为可公开访问的业务应用程序选择服务器软件时，我一直在想，从安全角度来看，使用可能缺乏普遍性的服务器软件（例如 Nginx）是否是不负责任的。

在光谱的另一端，Apache 经过多年的公开审查，修复了许多漏洞，并拥有一个安全团队。

以下是我对我的两个候选服务器在市场份额、社区和一般开发环境方面差异巨大的优势的看法。

Nginx 优势

• 无处不在。在我看来，不太容易成为目标和作为一个小玩家的组合已经帮助一些软件产品不太可能成为有针对性的攻击的受害者。一个很好的例子是 Apple 的 Mac OS X 平台，与最近的 Window 相比，该平台的尝试相对较少。

  Netcraft 服务器 2009 年 6 月的市场份额数据表明，Nginx 和 Apache 的竞争对手分别占据了 4% 和 50% 的市场份额。

• 更小的代码库，更少的错误。这只是一个假设；我没有查看任何一个代码库，但假设代码与错误率相似，较小的代码库可能会导致更少的漏洞利用。

  据 Ohloh 称，代码库大小为 635:75，较大的是 Apache。我不确定这是否包括模块，但考虑到巨大的增量，它可能包括。（当然，这会导致非常不正确的结论，因为如果安全是您的重点，您将只运行您需要的模块。）

阿帕奇的优势

• 安全团队。Apache 软件基金会似乎拥有相当先进的安全基础设施。
• 经验。多年来，Apache HTTP Server 项目经历了无数次攻击，毫无疑问，它们已经制定了如何最好地快速处理问题的策略。
• 无处不在。这可以很容易地成为专业人士，也可以成为骗子。这意味着更多的关注代码，但它没有说明好眼睛与坏眼睛的比例。

• 到期。正如我之前提到的，该项目经历了无数次漏洞利用和大量公众审查。

  这可能会导致零日漏洞利用的风险略低，因为漏洞问题可能不太可能被遗漏。这也可能意味着新的漏洞利用将不那么重要。

  快速搜索并未显示 Apache 是否受到安全审计。

• 文档。错误配置可以创建攻击向量。对于 Apache，这似乎不太可能，因为它提供了大量关于如何保护服务器的出版物（书籍和文章等）。
• 安全模块的数量。通过浏览两台服务器的站点，我感觉 Apache 在安全增强模块方面的数量远远超过 Nginx。

无处不在似乎是一把双刃剑。普遍性通常是好是坏可能不是线性关系（并且可能包括其他因素，例如您是否极易受到攻击）。我非常怀疑是否有关于对安全漏洞的普遍影响的研究，尽管我承认尝试过搜索。

如果我们谈论的是社交应用程序、新闻站点或在与业务应用程序分离的服务器上提供服务的媒体，我可能不会对此感到疑惑。对于处理付款、个人信息和信用卡号的应用程序，我当前的信息倾向于 Apache。

由于我不是安全专家，而且我的想法没有经过科学的收集，因此可能不是结论性的，我很感激有关哪些因素应该影响这样的决定的意见。如果不出意外，这仍然供处于相同位置的其他人考虑。

Answer 1

nginx 托管着全球网站数量的百分之几，因此它远非晦涩难懂。那是数十万甚至数百万个站点，因此 nginx 足够大，可以成为值得利用的目标。

nginx 已经存在安全问题，开源社区已经向作者披露了漏洞，作者已经修复了这些漏洞。在变更日志中搜索“security”，你会看到有一个工作流程：http : //nginx.net/CHANGES-0.6

因此，nginx 修复安全问题的过程与 Apache 几乎相同。它可能是一个较小的团队，不太正式，但它的工作方式大致相同。

从安全角度来看，拥有一个小而紧凑的代码库，以及一个干净简单的架构，是一项重大改进。更少的代码 = 统计上更少的错误。经验表明，随着代码库变大，错误数量的增长超过线性。假设代码错误率相似，较小的代码库将导致较少的漏洞利用。

由于其较小的用户群，从安全角度来看，使用 nginx 是否不负责任？我绝对不会回答，nginx 是一个非常好的选择，也是出于安全考虑。

然而，我建议以稍微不同的方式看待 HTTP 服务器安全性。http 守护进程中存在缓冲区溢出问题，这可能导致对 http 守护进程本身的攻击。对于大多数设计，通过使用操作系统级工具（例如 jails/croot/virtual）来“容器化”http 守护进程并限制成功攻击的影响，可以相当容易地将其影响降到最低。

针对 Web 应用程序的攻击可能会更糟，而且更为常见，尤其是对于内部开发的 Web 应用程序，这些应用程序通常未经专家安全审核。例如使用交叉脚本或 SQL 注入对用户数据做坏事、取钱、窃取用户名和密码数据库等。

Apache 在 webapp 安全领域有一个主要优势，即 3rd 方 mod_security 模块。将其视为 HTTP 请求的巨大正则表达式引擎，它允许您对 HTTP 调用的任何部分进行模式匹配和过滤。这可用于显着减少针对您自己的 webapp 代码的攻击面。

对于具有安全意识的开源 webapp 堆栈，我可能会使用：

• 用于负载平衡的容器化 nginx 实例，位于 Web 服务器前面的单独物理或虚拟服务器上，将 HTTP 请求代理到后端 Web 服务器。
• Apache 为网络服务器提供 mod_security。

你也可以反过来做——Apache 与 mod_security 在 nginx 网络服务器的前端执行负载平衡。这在很大程度上是您希望 CPU 负载在哪里的问题——使用 mod_security 的 HTTP 过滤需要相当数量的 CPU 资源，因此具有 mod_security 的 Apache 负载平衡器可能无法处理超过少数的后端网络服务器。如果负载均衡器是一个小型、快速的 nginx 实例，并且网络服务器进行自己的 mod_security 过滤，则负载均衡器上的拥塞会大大减少。

这为您提供了一个容器化的 HTTP 代理作为公共 Internet 和您的 web 应用程序之间的间接层，并将 mod_security 作为您的 web 应用程序代码前面的可扩展 HTTP 级别防火墙。但是要为此做好准备，尤其是 mod_security，需要花费大量时间进行设置并完全正常工作，而不会产生不必要的副作用。