在AWS中国区域启用WAF防护Log4J漏洞

一、背景

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

使用WAF防护的前提:

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

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行为。如下截图。

至此防护完成。

四、更多参考

请查看AWS官方说明(英文):

https://aws.amazon.com/cn/security/security-bulletins/AWS-2021-005/

使用AWS安全工具防护(英文):

https://aws.amazon.com/cn/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/