/Quick-steps-to-prevent-Apache-Log4J-vulnerability-on-AWS

# Apache Log4J漏洞在AWS上的快速防护步骤(10分钟操作防护核弹级漏洞Log4J)

Apache Log4J漏洞在AWS上的快速防护步骤

(针对传统企业，从企业IT运维人员的角度，撰写了Apache Log4J漏洞的防护防范办法和步骤，供您参考 - 10分钟操作防护漏洞Log4J)

[本文github更新地址]

  • 目标用户：传统企业 on AWS（即复杂环境业务系统 - 无法短时间内调查清楚是否存在log4j2漏洞）
  • 本文出发点：以业务系统为基础，从IT运维人员的视角，如何去理解Log4J漏洞对企业业务的影响？
  • 解决方案：本文提供了漏洞防护方法和具体操作步骤（先防护再修复）；
  • 本文回答了3个核心问题：Log4J漏洞是否对我有影响？如何解决影响？要花多少钱？

一、背景说明

  • AWS密切关注开源Apache “log4j2”功能(CE4-2021-44228)有关的安全问题，并竭力为所有使用log4j2的用户提供解决方案。目前确认彻底的防护措施是官方升级Log4J版本 或利用操作系统的软件升级功能更新到最新版本。
  • Apache Log4j2 是一款优秀的 Java 日志框架，该组件广泛应用在各个 Java 程序中（您可能没直接用，但是你使用的三方jar包组件也可能间接引用了）。攻击者利用Log4j漏洞，可触发远程代码执行，利用漏洞进行恶意请求。影响范围大，排查难度和危害性高，可以预见这个漏洞会对各类业务系统造成长期的影响。
  • 对于复杂环境的业务系统、或委托第三方开发的业务系统，对其是否包含log4j2环境 - 很难在短时间内调查清楚。另外，对现有的log4j2环境升级，也需要有可停机的业务窗口和足够的升级验证时间。
  • 基于以上情况，您在AWS上部署的系统 - 无论是从公网访问还是内网互联，建议立即采用《AWS WAF服务》进行快速防护，给业务环境调研、软件版本升级验证争取更多的时间，从而避免调研升级期间Log4J漏洞所造成的损失。

二、使用 《AWS WAF服务》进行快速防护，优先考虑 “业务系统场景”：

  • 复杂环境的业务系统，由多部门协调开发和部署，无法短时间内调查清楚其内部包含的log4j2环境；
  • 历史久远的业务系统，无法短时间内理清架构设计，无法短时间内调查清楚其内部包含的log4j2环境；
  • 第三方开发的业务系统，系统为黑盒子形式交付给用户，不楚其内部包含的log4j2环境；
  • 业务系统已调查清楚其内部存在log4j2漏洞，但是需要等待原开发商提供重新打包售后服务来修复漏洞的；
  • 核心业务系统，近期不允许有业务中断的，或短时间内找不到升级窗口的；
  • 核心业务系统，未获得充分验证不允许进行组件升级的；
  • 更多以上同类情况的。。。

二、《AWS WAF服务》进行快速防护 所适用 “AWS架构环境”：

  • 使用了AWS 应用程序负载均衡器 (ALB)、CloudFront CDN服务、API Gateway服务 和 AppSync的；
  • 使用ALB做EC2、ECS容器服务、EKS容器服务做发布的；
  • 通过公网访问或通过企业专线内网访问的；
  • **区或海外区域皆适用；

三、《AWS WAF服务》进行快速防护 不适用 “AWS架构环境”：

  • 不支持直接对一个EC2的80、443、8080端口进行防护；
  • 不支持NLB网络负载均衡器；
  • 不适用场景可考虑修改为以上适用架构；

四、《AWS WAF服务》进行快速防护 的成本核算：

为了节省成本，多个业务系统支持共同使用一个WebACL，定价如下

image-20211213125143543

image-20211213125302747

五、《AWS WAF服务》进行进行快速防护 的具体操作步骤（耗时10分钟）

**一句话原理说明：**通过创建 WAF web ACL，添加 Managed Rules Known BadInputs RuleSet 到您的 web ACL，然后将 web ACL 与您的 CloudFront Distribution、ALB、API Gateway 或 AppSync GraphQL API 相关联，以检查 uri、请求体、常用标头，完成最终防护；

以下内容转载自PCMAN的技术博客：

(1) 为ALB开启WAF

进入WAF服务，请注意目前**区WAF操作界面只有英文。

点击右侧按钮创建Create web ACL。即可进入创建WAF界面。如下截图。

image-20211214142223909

如果此前曾经创建过WAF，那么需要在左侧菜单中点击Web ACLs按钮，进入Web ACLs界面，并在页面上方的Region位置选择正确的AWS Region。这是因为基于ALB的WAF是Regional区域性资源，必须与Region内的ALB对应才可以启用。然后点击创建按钮。如下截图。

image-20211214142424221

在创建页面上，分别填写Web ACL的Name名称，Description描述，CloudWatch metric name监控指标的名称。同时选择Resource Type资源类型是与ALB绑定的Regional类型，区域选择北京或者宁夏正确的区域。最后点击页面最下方那个的按钮缇娜家资源Add Amazon Web Services resources。如下截图。

image-20211214142448311

在上一步点击添加资源后，会弹出新的窗口，从Resource type资源类型中选择Application Load Balancer即ALB，然后从下方的负载均衡器清单中选择要绑定WAF的ALB名称，然后点击添加。如下截图。

image-20211214142510364

添加完毕后，页面返回到向导第一步，点击右下角的Next下一步按钮。将进入向导第二步。如下截图。

image-20211214143205454

现在进入向导第二步，添加WAF防护策略。点击页面中间的Add rules按钮，在弹出的下拉框中选择第一项Add managed rule groups。这一步将添加AWS提供的托管的WAF规则组，针对不同场景进行防护。如下截图。

image-20211214143305289

进入添加托管规则的页面，规则组默认在折叠状态没有显示详细清单。点击页面上的三角箭头，即可显示详细的清单。如下截图。

image-20211214143353781

在WAF托管规则界面，将页面向下滚动，在其中找到Known bad inputs，点击右侧的按钮Add to web ACL，按下后图标开关从灰色变成蓝色，表示处于启用状态。点击下方的Edit编辑按钮即可查看详情。如下截图。

image-20211214143422794

在上一步点击编辑界面后，即可查看Known bad inputs规则所包含的防护内容。接下来的操作不需要修改任何参数，本步骤只是用于确认防护是有效的。在页面中可以看到防护规则的版本Version位置显示Default。这表示将使用最新版本。在本界面上不需要修改任何参数。继续向下滚动页面。如下截图。

image-20211214143550960

继续向下滚动页面，查看规则详情，即可看到第一条规则就是针对Log4JRCE漏洞的防护。在这个界面上，不需要修改任何参数，本步骤只是用于确认防护是有效的。请注意Count选项一定不要打开。当前这个选项不打开时候，表示遇到攻击就会拦截。如果打开Count就意味着当遇到攻击时候只记录不拦截。因此请对照截图确认配置正确。点击Save rule返回上一步。如下截图。

image-20211214143607001

返回到规则配置界面后，确认下Known bad inputs是开启的，然后点击右下角Add rules按钮。如下截图。

image-20211214143640014

返回向导后，可以在Rules界面下看到刚才添加的AWS-AWSManagedRulesKnownBadInputsRuleSet规则。在右侧Capacity位置可以看到数字200表示此条防护规则消耗的计算力。页面中间位置Web ACL rule capacity units used参数表示本WAF防护使用的计算力不能超过1500，当前使用了200。在下方Default web ACL action for requests that don't match any rules位置默认选择Allow即可无需修改。在最下方Custom request部分默认是折叠起来的，不需要展开。最后点击右下角的Next下一步。如下截图。

image-20211214143750428

插播一下WAF配置的注意事项：

在上述步骤请注意，如果之前没有使用过WAF，本次新增WAF进行防护，那么同时选择多个规则可能会造成误杀导致应用访问不正常。因此如果大批量应用多条规则，一般需要进行应用功能测试后再对生产环境变更。本次只配置一条Log4J漏洞规则，一般不会导致应用兼容问题。

另外如果选择所有规则，那么消耗的总计算量会超过1500WCU，无法进行配置。建议可以部署一些常用防护：

  • Core rule set（OWASP常见漏洞）
  • Known bad inputs（包含本次Log4J漏洞）
  • Linux operating system（操作系统漏洞防护）
  • SQL database（SQL注入）

同时开启以上规则，使用的计算力是1300/1500WCU，未超过最大处理能力，可有效防护常见漏洞。

插播完毕，现在回到配置规则的话题。

在向导的下一个界面，如果有多条规则，可以调整其中的优先级和匹配顺序。当只有一条的时候无需调整。如果有多条，可以将AWS-AWSManagedRulesKnownBadInputsRuleSet规则放到优先级最高位置即可。如下截图。

image-20211214143805684

在监控Cloudwatch配置参数上，使用当前页面的默认值即可。点击右下角的Next下一步按钮继续。如下截图。

image-20211214143845009

在向导最后一步，回顾刚才所有设置，无需调整，将页面向下滚动。如下截图。

image-20211214143906809

点击右下角的Create web ACL按钮完成创建过程。如下截图。

image-20211214143920700

页面显示绿色的提示信息表示创建成功。如下截图。

image-20211214143940455

(2) 查看防护效果

为了确认防护生效，您可以通过WAF ACL界面的规则取样信息位置查看计数器，显示是否遇到攻击和有效防护。将页面向下滚动，可以显示更多Sampled requests访问记录取样。如下截图。

image-20211214144014225

为了测试生效，可以选择一个Windows、Linux、或者Mac环境，对ALB的入口发起操作，请求URI包含关键字${jndi:ldap:。注意这个关键字不是发起攻击造成溢出的完整字符串，不会导致被测试环境的问题。如下结果。

curl "http://alb-1435392491.cn-northwest-1.elb.amazonaws.com.cn/$\{jndi:ldap://a/"
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
</body>
</html>

可看到返回结果是403被禁止。这个403并非是目录没有权限被Web Server禁止，而是被WAF拦截的禁止。

现在回到WAF的ACL界面上，向下滚动，可以在Sampled requests位置中看到规则生效，并且触发了Block行为。如下截图。

image-20211214144039867

至此防护完成。

(3) 防御启动后的常见问题和回答

Q：开启了WAF防护之后，还需要升级吗？

A：建议客户第一时间开启WAF启用防御，在此基础上也不要忘记在合适时间进行log4j2的升级，两者结合才是彻底解决问题的办法。

Q：有Java下的最佳实践吗？

A：不要赋予Java程序以root或者其他admin身份运行，避免遭到入侵之后失去资源的掌控权，建议让java程序运行在某个特定的受限用户身份下。

Q：我按照AWS的Well Architec把所有相关服务全部放在了private subnets里，杜绝了与internet的直接接触，这种情况不开启WAF防护，也应该不受影响对吧？

A：JNDI会通过业务入口，间接到达私网内的资源，实现远程代码调用，所以依然受到log4j漏洞影响。

Q：**区WAF支持JNDI漏洞防御吗？

A： 支持。

Q：AWS的托管服务安全吗？

A：AWS托管服务会按批次升级log4j，保证服务与数据安全。

Q：有快捷的手工检测方法吗？

A：可以检索所有log4j日志中是否存在jndi字样。

六、Apache Log4j2漏洞简介及手工修复办法

  • Apache Log4j2 是一款优秀的 Java 日志框架。该工具重写了 Log4j 框架，并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发，用来记录日志信息。

  • 漏洞描述：Log4j2中存在JNDI注入漏洞，当程序将用户输入的数据进行日志记录时，即可触发此漏洞，成功利用此漏洞可以在目标服务器上执行任意代码。经验证，Spring-Boot-strater-log4j2, Apache Struts2, Apache Solr, Apache Flink, Apache Druid, ElasticSearch, Flume, Dubbo, Redis, Logstash, Kafka等众多组件与大型应用均受影响。

  • 影响范围：Apache Log4j 2.x < 2.15.0-rc2

  • 漏洞危害：攻击者可触发远程代码执行漏洞，利用漏洞进行恶意请求。

  • 手工修复办法：

    1. 可以升级的业务系统

      官方修复链接： https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

    2. 暂时无法升级的业务系统： A）修改log4j2.component.properties，将log4j2.formatMsgNoLookups设置true 或者 B）初始化logger之前，使用-Dlog4j2.formatMsgNoLookups=true 或者 C）重新打包，移除jndilookup zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

七、更多参考

  1. AWS官方说明（英文）：https://aws.amazon.com/cn/security/security-bulletins/AWS-2021-006/
  2. 博客 Apache log4j2亚马逊云科技的应对建议：https://mp.weixin.qq.com/s/no_gW8vy9hnTwgzWHgjm4A
  3. Apache官方升级，在环境中使用了Log4j2的客户更新Log4j2到最新版本，可以使用这个链接https://logging.apache.org/log4j/2.x/download.html 或是操作系统的软件更新机制；