在AWS中国区域启用WAF防护Log4J漏洞 – PCMAN的技术博客

一、背景

2021年12月爆出的高危漏洞 CVE-2021-44228 和CVE-2021 -45045漏洞，彻底的防护措施是升级Log4J版本到官方指定版本，临时措施是通过WAF进行一定程度的防护。建议升级到Log4J 2.17版本才可以满足安全要求。

使用WAF防护的前提：

中国区域和海外区域，已经使用EC2、ECS容器服务、EKS容器服务，且使用ALB作为发布点，此场景可使用WAF防护
海外区域，没有使用ALB发布但是使用Cloudfront CDN加速，则可使用基于Cloudfront的WAF防护
中国区域和海外区域的WAF都不支持直接对一个EC2的80、443、8080端口进行防护
不支持NLB网络负载均衡器，NLB后可嵌套接入ALB（此为2021年新发布新特性）

如果您已经配置过WAF并启用了，请参考这里的changelog确认后续更新。如果还没有启用WAF，请参考如下Step-by-step配置说明如下。

二、为ALB开启WAF

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

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

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

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

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

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

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

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

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

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

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

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

返回向导后，可以在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下一步。如下截图。

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

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

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

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

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

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

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

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

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

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

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

三、查看防护效果

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

为了测试生效，可以选择一个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行为。如下截图。