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

小提示：您能找到这篇{轻松便捷为AWS WAF部署一套仪表板}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的轻松便捷为AWS WAF部署一套仪表板内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">在本文中，我们将向大家介绍如何在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上的仪表板。

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

< ">< font-size: 18px;">步骤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登录密码。

< ">< font-size: 18px;">步骤2：等待

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

图三：CloudFormation模板启动完成

< ">< font-size: 18px;">步骤3：验证Kibana与仪表板是否正常工作

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

图四：输出CloudFormation模板

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

图五：空白Kibana仪表板

< ">< font-size: 18px;">步骤4：接入AWS WAF日志

< ">< font-size: 18px;">

图六：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

< ">< font-size: 18px;">步骤5：最终验证

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

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

< ">< font-size: 18px;">示例场景

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

图九：Java the Dog网站主页

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

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

< color: rgb(127, 127, 127);">图十：Kibana仪表板，以及来自美国、日本、德国与印度的访问请求

< color: rgb(127, 127, 127);">图十一：仅观察来自印度的网站访问请求

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

< color: rgb(127, 127, 127);">图十二：Kibana仪表板中的Visualize选项卡

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

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

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

< color: rgb(127, 127, 127);">图十三：被阻止的可疑请求

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

< color: rgb(127, 127, 127);">图十四：运行“wget”命令后的命令行截屏

< ">< font-size: 18px;">总结

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

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

< font-size: 14px; color: rgb(127, 127, 127);">Original URL:https://aws.amazon.com/cn/blogs/security/deploy-dashboard-for-aws-waf-minimal-effort/

本篇作者

Tomasz Stachlewski

Tomasz是AWS公司高级解决方案架构经理，他负责帮助不同规模的企业（从初创公司到大型巨头）推进云探索之旅。他是无服务器架构等创新型技术的忠实拥趸，致力于运用这些技术帮助组织加速数字化转型的步伐。