轻松便捷为 AWS WAF 部署一套仪表板

Original URL: https://aws.amazon.com/cn/blogs/security/deploy-dashboard-for-aws-waf-minimal-effort/

在本文中，我们将向大家介绍如何在Amazon Web Services (AWS)账户中部署一套解决方案，通过 AWS Web Application Firewall (WAF) 服务提供全自动仪表板。这套解决方案使用由AWS WAF生成并收集到的日志记录，并通过用户友好型仪表板显示相关结果，具体如图一所示。

图一：AWS WAF 的用户友好型仪表板

此仪表板提供多种图表，可供您随时参考、筛选及调整。图一为我们使用样本网页中的数据创建出的示例仪表板，您可以在其中查看：

• 已执行的AWS WAF规则
• 全部请求数量
• 被阻止的请求数量
• 允许及被阻止的请求数量对比
• 来自不同国家的请求数量
• HTTP 方法
• HTTP版本
• 特定IP计数
• 请求计数
• 访问量前10的IP地址
• 访问量前10的国家
• 访问量前10的用户代理
• 访问量前10的主机
• 访问量前10的WebACL

此仪表板由Kibana创建而成，您可以向其中添加新的可视化图表，充分发挥其功能灵活性。

AWS WAF是一套Web应用程序防火墙。它有助于保护您的Web应用程序或API免受各类常见Web攻击活动对其可用性、安全性以及资源消耗量的负面影响。只需几个步骤，您就可以将AWS WAF部署至应用程序负载均衡器、Amazon CloudFront分配或者Amazon API Gateway阶段当中。在本文中，我们将共同了解如何深入了解AWS WAF层的运行情况。AWS WAF提供两种服务版本：AWS WAF（版本2）与AWS WAF经典。这里，我们建议您使用AWS WAF版本2以保持最新功能，因为AWS WAF经典已经不再更新。当然，本文中描述的解决方案可同时支持这两种AWS WAF版本。

这套解决方案能够快速实现部署：不到一个小时之内，仪表板即可准备就绪。该解决方案使用多项AWS服务构建而成，具体包括Amazon Elasticsearch (Amazon ES), AWS Lambda, Amazon Kinesis Data Firehose, Amazon Cognito, Amazon EventBridge等等。当然，大家无需了解这些服务的详细信息，即可轻松完成仪表板的构建与使用。在这里我们准备了一套CloudFormation模板，您可以在AWS控制台进行部署，借此在您的AWS账户上自动设置整个解决方案。您也可以在我们的AWS Github上找到完整解决方案。此方案属于开源成果，因此您可以随意使用与编辑，满足您希望达成的任何需求。

此解决方案的架构可以分为7个步骤，如图二所示。

图二：构建仪表板时的交互点

各交互点如下：

1. AWS WAF服务的一项重要功能为AWS WAF日志。此日志能够捕捉关于被阻止及允许的请求的相关信息，结果将被转发至Kinesis Data Firehose服务。
2. Kinesis Data Firehose缓冲区接收信息，而后将其发送至作为解决方案核心的Amazon ES处。
3. 部分信息——例如AWS WAF Web ACL中的名称——不会被记录在AWS WAF日志当中。为了使整个解决方案对于用户更加友好，我在这里使用了EventBridge；每当用户更改其AWS WAF配置时，都会调用EventBridge。
4. 在创建新规则时，EventBridge将调用Lambda函数。
5. Lambda将检索关于全部现有规则的信息，并更新规则ID及其名称在Amazon ES集群中的映射。
6. 为了让整个解决方案更加安全，这里使用Amazon Cognito服务存储被授权使用仪表板用户的凭证。
7. 用户输入凭证以访问安装在Amazon ES集群中Kibana上的仪表板。

现在，让我们部署解决方案并查看其工作效果。

步骤1：使用CloudFormation模板部署解决方案

点击Launch Stack在您的账户内启动一个CloudFormation堆栈，借此部署解决方案。

您将被重新定向至美国北弗吉尼亚州CloudFormation服务，该区域为与CloudFront相关联的AWS WAF WebACL在部署此解决方案时使用的默认区域。您也可以根据需要更改具体区域。此模板将启动多项云资源，包括但不限于：

• 内置Kibana的Amazon ES集群，用于存储数据并显示仪表板。
• Amazon Cognito用户池，外加一套包含用于指示仪表板访问权限的用户注册表。
• Kinesis Data Firehose，用于将日志流式传输至Amazon ES。

在向导程序中，系统会要求您修改或者提供四项不同参数，分别为：

• DataNodeEBSVolumeSize: 待创建的Amazon ES集群的存储大小，您可以直接保留默认值。
• ElasticSearchDomainName: Amazon ES集群域的名称。您可以直接保留默认值。
• NodeType: 用于创建Amazon ES集群的实例类型。您可以根据需求进行修改，也可以直接保留默认值。
• UserEmail: 您需要更新此参数。这项参数所指示的电子邮件地址将负责收取Kibana登录密码。

步骤2：等待

我将本示例中的模板命名为aws-waf-dashboard，其启动过程大概需要20到30分钟。您可以休息一会儿，直到该堆栈的状态转换为CREATE_COMPLETE。

图三：CloudFormation模板启动完成

步骤3：验证Kibana与仪表板是否正常工作

检查您的邮件。您应该已经收到包含所需密码的电子邮件，并可借此登录至Kibana仪表板。请记录密码内容，而后返回CloudFormation服务并选择aws-waf-dashboard模板。在Output选项卡中的Value列中，您应能看到一项参数及其附带的指向仪表板的链接。

图四：输出CloudFormation模板

在Kibana当中，选择Dashboard选项卡，如图五所示，而后选择表中的WAFDashboard。此项操作将调用AWS WAF仪表板。目前的仪表板应该还没有内容，因为其尚未与AWS WAF连接。

图五：空白Kibana仪表板

步骤4：接入AWS WAF日志

图六：WAF & Shield

如果您还没有启用AWS WAF日志，则需要立即进行操作以继续下一步。请在Web ACL中选择Logging and metrics，而后选择Enable logging，如图七所示。

图七：启用AWS WAF日志

在Amazon Kinesis Data Firehose Delivery Stream之下选择下拉列表，而后选择由模板在步骤2中创建完成的Kinesis Firehose。其名称以aws-waf-logs开头。保存您的更改。

图八：选择创建好的Kinesis Firehose

步骤5：最终验证

您的AWS WAF日志将通过Kinesis Data Firehose从AWS WAF服务直接被发送至Amazon ES集群，并通过Kibana仪表板供您使用。几分钟之后，您应该会在仪表板上看到类似于图一中的截屏数据。

本轮演练成功完成！如大家所见，只需要几个简单步骤，我们就构建并部署了一套解决方案，可以使用此方案检查我们的AWS WAF配置，同时查看其正在发出哪些请求、以及这些请求是否被阻止/允许。

示例场景

下面，让我们从示例场景出发，看看这套解决方案的使用方法。我为自己的小狗创建了一个简单网站，并配置CloudFront以加快网站速度、提升安全水平。

图九：Java the Dog网站主页

接下来，我们配置一个AWS WAF Web ACL，并将其附加至当前CloudFront分配当中，这也是我这个小网站的入口点。在AWS WAF Web ACL中，我没有添加任何规则，即允许所有请求流入。这样一来，我就能够记录所有请求并准确了解谁在访问我的网站。接下来，按照前文中提到的步骤配置AWS WAF仪表板。

根据设想，我以为这个网站的用户应该主要来自美国、德国和日本，因为这法国斗牛犬在这三个国家特别受欢迎。但通过实际观察，我发现来自印度的用户相当多，这确实有些出乎意料。在图十中可以看到，AWS WAF仪表板提供包含所有四个国家的统计数据，而指向此网站的访问请求超过11000次。

图十：Kibana仪表板，以及来自美国、日本、德国与印度的访问请求

图十一：仅观察来自印度的网站访问请求

仪表板显示，前一个小时内我的网站收到700多条来自印度的请求。这对我这个小网站无疑是个巨大的成功……但遗憾的是，所有请求都来自同一个IP地址。此外，其中大多带有可疑的用户代理标头：“secret-hacker-agent”。我们可以在Kibana的Visualize选项卡中看到这部分信息，如图十二所示。

图十二：Kibana仪表板中的Visualize选项卡

看起来情况不妙，所以我决定使用AWS WAF阻止这些请求。

那么，新的问题来了——我们到底该屏蔽掉什么？我当然可以直接阻断所有来自印度的请求，但这显然不是最好的方法，因为可能还有其他来自印度的真正法国斗牛犬爱好者想看我的网站。我也可以直接阻止当前恶意IP地址，但黑客完全可以使用其他IP继续攻击我的网站。最后，我决定创建一项用于检查用户代理标头的AWS WAF规则。如果用户代理标头包含“secret-hacker-agent”，则该请求将被规则所阻止。

在AWS WAF规则部署完成的几分钟内，我注意到网站仍有来自印度的请求，但这一次，带有可疑用户代理标头的请求再也没有出现！如图十三所示，随后出现了约2700项请求，但其中约2000项被阻止。

图十三：被阻止的可疑请求

实际上，为了展示，我自己就是那个以secret-hacker-agent攻击自己网站的坏人～大家可以通过以下命令行截屏看到，我那个带有可疑用户代理标头的请求（使用wget实现）被正确阻止（接收到「403 Forbidden」消息）。而在使用其他标头（「good-agent」）时，请求则可成功通过AWS WAF规则的过滤。

图十四：运行“wget”命令后的命令行截屏

总结

在本文中，我们详细介绍了如何通过几个步骤为AWS WAF部署仪表板，以及如何利用它发现并阻止Web应用程序攻击。现在，您可以采用同样的基本思路为自己的应用程序部署这套解决方案了。如果您对本文中的解决方案及仪表板有任何建议或反馈，请在下方评论区或者项目的GitHub页面上与我们交流。

本文的创造灵感，源自我的好友Tom Adamski此前撰写的另一篇博文，他在其中描述了如何使用Kibana与Amazon ES实现AWS WAF日志可视化。另外，也感谢Achraf Souk在AWS边缘服务方面向我提供的帮助。

希望了解AWS Security发布的指南内容、新闻资讯以及功能公告？请在 Twitter上关注我们。

本篇作者