共计 4814 个字符，预计需要花费 13 分钟才能阅读完成。
概述
在本文中，咱们将为针对最近披露的 Log4j 破绽所影响的客户提供一些领导意见。内容包含如何限度破绽的危险，如何尝试辨认是否易受此问题影响，以及如何应用适当的补丁更新基础架构。
Log4j 破绽（CVE-2021-44228、CVE-2021-45046）是无处不在的日志平台 Apache Log4j 中的一个要害破绽（CVSS 3.1 根本分数为 10.0）。此破绽容许攻击者在易受攻击的平台上执行近程代码。介于版本 2.0-beta- 9 和 2.15.0 之间的 Log4j 版本 2 受影响。
该破绽应用 Java 命名和目录接口（JNDI），Java 程序应用该接口查找数据，通常通过目录查找数据，在呈现此破绽的状况下通常通过 LDAP 目录查找数据。
上面图 1 重点介绍了 Log4j JNDI 攻打流程。
图 1、Log4j 攻打过程。材料起源：GovCERT.ch，瑞士政府计算机应急响应小组（GovCERT）
本篇内容作为一个即时响应，心愿您关注这个设计用于应用任何 Log4j 2.0+ 对正在运行的 JVM 进行热补丁的工具。亚马逊云科技的首席信息安全官史蒂夫·施密特（Steve Schmidt）也探讨了这个热补丁。
进攻
客户能够应用多个亚马逊云科技提供的服务来帮忙限度来自 Log4j 破绽所带来的危险 / 裸露。客户能够建设分层管制办法，并 / 或抉择以下确定的管制办法，以帮忙限度他们的危险。
Amazon WAF
客户能够应用 Amazon WAF，遵循其相应的托管规定，以帮忙爱护其 Amazon CloudFront 散布、Amazon API Gateway REST API、Amazon ALB 或 Amazon AppSync GraphQL API 资源。
- AWSManagedRulesKnownBadInputsRuleSet esp.：Log4JRCE 规定，有助于查看申请中是否存在 Log4j 破绽。示例模式包含 ${jndi:ldap://example.com/}。
- AWSManagedRulesAnonymousIpList esp.：AnonymousIPList 规定，该规定有助于查看匿名化客户端信息的已知源的 IP 地址。
- AWSManagedRulesCommonRuleSet esp.：SizeRestrictions_BODY 规定，用于验证申请注释大小是否最多为 8 KB（8192 字节）。
对于应用 Amazon WAF Classic 的客户，您须要迁徙到 Amazon WAF 或创立自定义正则表达式匹配条件。
领有多个帐户的客户能够依照阐明应用 Amazon Firewall Manager 跨 Amazon Organization 集中部署 Amazon WAF 规定。
Amazon Network Firewall
客户能够在 Amazon Network Firewall 中应用与 Suricata 兼容的 IDS/IPS 规定来部署基于网络的检测和防护。可从 corelight、NCC Group、ET Labs 和 CrowdStrike 取得解决 Log4j 的开源 Suricata 规定。这些规定有助于辨认 Log4j 破绽的扫描和攻打后流动。因为目前存在大量良性扫描，咱们倡议客户首先关注潜在的攻打后流动，例如从其 VPC 向不受信赖的互联网目的地的发送出站 LDAP 流量。
咱们还倡议客户思考施行出站端口 / 协定执行规定，以监控或避免诸如 LDAP 之类的实例应用 53、80、123 和 443 等非标准 LDAP 端口。对于监控或避免应用端口 1389 出站，会有助于辨认由互联网扫描仪触发进行出站命令和管制呼叫的零碎。咱们还倡议，对于没有非法业务须要向互联网发动网络呼叫的零碎，在默认状况下不应被赋予该性能。出站网络流量过滤和监控不仅对 Log4j 十分有用，而且对其余类型的破绽也十分有用。
应用 IMDSv2
在 log4j 破绽呈现的晚期，钻研人员留神到，一旦主机受到初始 JDNI 破绽的危害，攻击者有时会尝试从主机获取凭据，并通过 LDAP、HTTP 或 DNS 查找等机制发送这些凭据。咱们倡议客户应用 IAM 角色而非应用长期拜访密钥，并且不要将凭据等敏感信息存储在环境变量中。客户还能够利用 Amazon Secrets Manager 来存储和主动轮换数据库凭证，而不是在主机的环境变量中存储长期数据库凭证。
为了在可能应用 Amazon EC2 角色时，帮忙 Amazon Web Services 防备此类攻打以及帮忙放弃所有 IMDS 数据的私密性，客户应该思考须要应用实例元数据服务版本 2（IMDSv2）。因为默认状况下启用了 IMDSv2，因而能够通过禁用 IMDSv1（默认状况下是启用的）来要求应用 IMDSv2。应用 IMDSv2，申请受到初始交互的爱护，在初始交互中，调用过程必须首先应用 HTTP PUT 获取会话令牌，而且后续申请必须在 HTTP 头中蕴含该令牌。这使得攻击者更难从 IMDS 获取凭据或任何其余数据。尽管所有最新的 Amazon SDK 和工具都反对 IMDSv2，但与任何可能非向后兼容的更改一样，在宽泛部署之前，请在代表性零碎上测试此更改。
检测
这篇文章介绍了如何潜在地限度攻打此破绽的能力。接下来，咱们将着重介绍哪些亚马逊云科技服务能够帮忙检测您环境中是否存在此破绽。
Amazon Inspector
如图 2 所示，Amazon Inspector 团队创立了一个覆盖范围，用于在 Amazon EC2 实例和 Amazon Elastic Container Registry Images (Amazon ECR)（Amazon ECR）中辨认此破绽的存在。利用新的 Amazon Inspector，扫描是自动化且继续的扫描。继续扫描受公布的新软件包、新实例和新的通用破绽披露（CVE）等事件驱动。
例如，一旦 Inspector 团队减少了对 Log4j 破绽的反对（CVE-2021-44228 和 CVE-2021-45046），Inspector 立刻开始在所有受反对的 Amazon Systems Manager 托管实例中查找此破绽，其中 Log4j 通过操作系统包管理器装置，并且此包存在于与 Maven 兼容的 Amazon ECR 容器映像中。如果存在此破绽，将开始显示发现后果，而无需任何手动操作。如果您应用的是 Inspector Classic，则须要确保针对所有 Amazon EC2 实例运行评估。您能够遵循文档，以确保为所有 Amazon EC2 实例创立评估指标。
GuardDuty
除了通过 Inspector 发现存在此破绽外，Amazon GuardDuty 团队还开始增加与攻打 Log4j 破绽相干的危害指标，并将持续这样做。GuardDuty 将监控试图拜访已知谬误 IP 地址或 DNS 条目标行为，还能够通过基于异样的行为后果来发现攻打后的流动。例如，如果 Amazon EC2 实例开始在异样端口上通信，GuardDuty 将检测此流动并创立查找行为：EC2/NetworkPortUnusual。不过，此流动并不限于 NetworkPortUnusual 后果。GuardDuty 有许多与攻打后流动相干的不同后果，这些后果可能是对受损亚马逊云科技资源的响应。
Security Hub
明天，许多客户还应用与 Inspector 和 GuardDuty 集成的 Amazon Security Hub 聚合警报并启用主动修复和响应。从短期来看，咱们建议您应用 Amazon Security Hub 通过 Amazon Chatbot、Amazon Simple Notification Service 或票务零碎设置警报，以便在 Inspector 在您的环境中发现此破绽时进行查看。从久远来看，咱们建议您在适当的时候应用平安核心来启用平安警报的主动修复和响应。这里是对于如何应用平安核心设置主动修复和响应的一些想法。
VPC flow logs
客户能够应用 Athena 或 CloudWatch Logs Insights queries 对其 VPC 流量日志进行查问，以帮忙辨认与 log4j 攻打后出站网络流动相干的 VPC 资源。VPC 流量日志的 Version 5 特地有用，因为它蕴含“流向”字段。咱们倡议客户首先特地留神应用指标端口 1389 的出站网络呼叫，因为该端口的出站应用在非法应用程序中不太常见。客户还应考察应用指标端口 389 向不受信赖的互联网指标 IP 地址发送的出站网络呼叫。收费套餐 IP 名誉服务，如 VirusTotal、GreyNoise、NOC.org 和 pinfo.io，能够提供与记录的流动中找到的公共 IP 地址相干的有用见解。
留神 ： 如果在查问的捕捉的 VPC flow logs 中有 Microsoft Active Directory 环境，则可能会因为应用端口 389 而呈现误报。
响应
前两局部探讨了帮忙避免潜在的攻打希图的办法，以及如何检测存在破绽和潜在的攻打希图。在本局部中，咱们将重点介绍您能够采取哪些步骤来缓解此破绽。正如咱们在概述中指出的，倡议立刻响应博客，并应用旨在用于应用任何 Log4j 2.0+ 对正在运行的 JVM 进行热补丁的工具。亚马逊云科技的首席信息安全官史蒂夫·施密特（Steve Schmidt）也探讨了这个热补丁。
Amazon Patch Manager
如果您应用 Amazon Systems Manager Patch Manager，并且已将要害补丁设置为立刻装置在补丁基线中，则您的 Amazon EC2 实例将曾经具备该补丁。值得注意的是，这一步您还没有实现。接下来，您须要在利用程序代码中应用库的任何地位更新类门路，以确保应用的是最新版本。
容器缓解
为了将概述中提到的热补丁装置到 Amazon EKS 集群工作节点上，亚马逊云科技开发了一个执行 JVM 级别热补丁的 RPM，该热补丁禁用来自 Log4j2 库的 JNDI 查找。ApacheLog4J2 节点代理是亚马逊云科技的 Kubernetes 团队构建的一个开源我的项目。
一旦确定，Amazon ECR 容器映像将须要更新以应用 Log4j 2.16.0 版本。在上游，您须要确保应用易受攻击的 Amazon ECR 容器映像构建的所有容器都已更新，以便尽快应用新映像。这可能会有所不同，具体取决于您用于部署这些映像的服务。例如，如果您应用的是 Amazon Elastic Container Service (Amazon ECS), 您可能心愿更新该服务以强制进行新部署，这将应用新的 Log4j 版本破坏映像。查看反对您用于部署容器的办法的文档。
咱们倡议客户在打补丁后立刻提供新的应用程序凭据并撤销现有凭据。
无奈降级时的缓解策略
如果您无奈降级到 2.16.0 版，该版本默认状况下禁用对 JDNI 的拜访，或者如果您仍在确定为您的环境打补丁的策略，则能够通过更改您的 Log4j 配置来缓解此破绽。要在 >=2.10 版本中施行此缓解措施，您须要从 classpath 中删除 JndiLookup 类：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
论断
在这篇文章中，咱们概述了要害的亚马逊云科技平安服务，这些服务使客户可能采纳分层办法来帮忙防备、检测和响应来自 Log4j 破绽的危险。咱们催促客户持续监控咱们的平安布告；咱们将持续通过咱们一方独特责任模式的修复措施更新咱们的布告。
鉴于该破绽的严重性，咱们催促客户亲密关注该破绽，并适当优先施行本博客中强调的控制措施。
本篇作者
马歇尔·琼斯（Marshall Jones）
亚马逊云科技的寰球平安专家解决方案架构师
他的背景是致力于亚马逊云科技咨询和平安架构，专一于边缘、威逼检测和合规性等各种平安畛域。明天，他专一于帮忙亚马逊云科技企业客户采纳和经营亚马逊云科技平安服务，以进步平安效率和升高危险。
赛义德·沙雷夫（Syed Shareef）
亚马逊云科技的高级平安解决方案架构师
他与大型金融机构单干，帮忙它们通过亚马逊云科技实现业务指标，同时合乎监管和平安要求。
扫描上方二维码即刻注册
