Amazon WAF部署小指南(四)：使用 Log Hub 自动部署方案进行 WAF 安全运营

前文提要

❖ 亚马逊云科技 WAF 部署小指南(一)：WAF 原理、默认部署及日志存储

❖ 亚马逊云科技 WAF 部署小指南(二)：使用经济实用的 Log Insights 进行日志分析

❖ 亚马逊云科技 WAF 部署小指南(三)：使用 OpenSearch 进行 WAF 安全调查

点击上方链接即可【阅读】！

内容简介

本文分为六个步骤为您讲述如何使用 Log Hub 自动部署方案进行 Amazon WAF 安全运营。

步骤一：按照前述骤完成 Amazon WAF 的部署

步骤二：创建 OpenSearch 集群

步骤三：为 VPC 添加 S3 Gateway endpoint 和 NAT Gateway

步骤四：部署 Log hub 方案的 CloudFormation 模板

步骤五：Log hub 流程解析

步骤六：使用 Log hub 部署的 OpenSearch Dashboard 开展 Amazon WAF 日志调查工作

附录一：平滑迁移已有的 OpenSearch 环境到 Log hub 环境

系统架构图：

步骤一：按照前述骤完成 Amazon WAF 的部署

请确保通过 Amazon WAF 能够访问后端的 Echo-Server 网页。并且 Amazon WAF 日志能够在 Amazon S3 日志存储桶里看到。

注意在这里，我们对于日志输入有两种选择:

1. 对于成本比较关注的, 且延时要求不高的, 推荐直接使用 Amazon S3 Bucket,  每 5 分钟/ 75  MB 产生一次日志

2. 对于实效性要求比较高的,  且日志量不大的情况, 推荐使用 Kinesis Data Firehose Stream

对于第一种选择，我们按照 WAF 部署小指南 (一) 的操作即可。

确保 Amazon WAF 日志的设置如下:

确认 Amazon WAF Bucket 里可以收到日志内容如下:

对于第二种选择，我们需要参照 WAF 部署小指南 (三) 步骤四创建 Kinesis Firehose Delivery Stream。并把 Delivery Stream 的目的地设定为一个新的 S3 存储桶

步骤二：创建 OpenSearch 集群

该步骤和 WAF 部署小指南 (三) 类似，唯一的不同是我们这里会将 OpenSearch 部署在 VPC 内部。

15 分钟左右 OpenSearch 集群会部署完毕。

注意部署完以后，我们是无法从 Internet 访问这个 OpenSearch 集群的。如果对 vpc-sample-waf-opensearch-vpc2-xxxx.us-east-1.es.amazonaws.com做 nslookup http://vpc-sample-waf-opensearch-vpc2-knms2fyekmwbafkugwarmthvgm.us-east-1.es.amazonaws.com/  会发现它解析成为 VPC 内部的私网 IP。

在正式的生产环境中，大多数企业已经能够通过 VPN 或者专线直接访问私网 VPC 的节点。这种情况下 OpenSearch 到这一步已经可以访问了。如果大家是在测试环境中使用，尚未具备直接连接 VPC 内部网络的架构。可以构建一个 ALB，由此访问 OpenSearch 的 Dashboard。如果您需要新建 ALB 以方便 OpenSearch 的访问。请参考附录里可选步骤一的操作。

步骤三：为 VPC 添加 Amazon S3 Gateway endpoint 和 NAT Gateway

本步骤是为了 Cloudformation 中的 Lambda 在不访问 Internet 的情况下从 Amazon S3 读取 Amazon WAF 日志。

以及让 Lambda 从 VPC 内部访问 OpenSearch API。

添加 NAT gateway（在 VPC 内部无法访问 Internet 时需要添加)

步骤四：部署 Log hub 方案的 CloudFormation 堆栈

1. 打开 CloudFormation 控制台

2. 启动 Log hub WAF Logs 的 template

https://aws-gcr-solutions.s3.amazonaws.com/log-hub/v0.2.0-dev/WAFLog.template

• Log Bucket Prefix 这里不要以/开头，会导致日志通知处理。

• 注意Backup Bucket 的桶名不能添加自定义前缀。Log hub 输送错误日志时会自动添加 Error 前缀，因此不会在 Bucket  根目录里产生过多文件。

检查 stack 配置:

大约 7 分钟后 CloudFormation 可以执行完成。

步骤五：Log hub 流程解析

这里解释一下 Log hub 的工作流程，如下图所示。Log hub 主要用 Log Processor 这个 Lambda 进行 OpenSearch 日志的注入工作。

我们前述的 CloudFormation 主要创建了 Lambda, 和  SQS 资源。日志注入 OpenSearch 过程分为以下几个步骤

1.  Amazon WAF  写日志到S3桶 (直接写入或通过 Kinesis Firehose 写入)

2.  Amazon WAF 日志以文件形式 Put 到 Amazon S3 存储桶的事件被发送到 SQS

3. SQS 调用 Log Processor Lambda 函数去读取日志文件并处理 (此处使用 Amazon S3 endpoint 可以节约流量费用)

4. Lambda 把处理过的日志通过 OpenSearch Web API 导入到 OpenSearch 索引库以供进一步分析

5. 无法处理的日志会被导出到失败日志存储桶里 (带错误原因)

上述架构图和流程里的最主要执行部件是下图的两个 Lambda 函数:

OpenSearchHelperFn 这个 Lambda 函数主要用来初始化 OpenSearch。其中在 WAF部署小指南 (三)  里的用户权限映射，Index Template 的创建。以及 Dashboard 的上传工作，都是这个函数完成的。如果 OpenSearch 和 VPC 的环境没有准备好导致 OpenSearch 初始化失败时。可以重新运行这个 Lambda 函数来再次初始化。初始化的错误消息也可以从该 Lambda 函数的执行日志里找到。

LogProcessor 这个 Lambda 函数如架构图所示，是 Log hub 部署完毕后日志注入的主要函数。如果没有看到注入日志，可以在 Log Processor 这个函数的执行日志里找到线索。也可以尝试用 Amazon S3 Put 的测试 Event 作为这个函数的输入，查看测试日志是否可以即刻注入到 OpenSearch 集群里。

步骤六：使用 Log hub 部署的 OpenSearch Dashboard 开展 WAF 日志调查工作

Log hub 部署完成后得到的 OpenSearch Dashboard 和 WAF 部署小指南 (三) 是基本一致的。由于 Log hub 在日志注入的时候，可以把嵌套的一些 HTTP 请求头字段如 User Agent 作为附加字段提取出来，因此在 Dashboard 处理方面能够更加灵活。除了能使用和 WAF 部署小指南 (三) 演示的方法相同的拖拉拽多重过滤操作。还可以使用下面的方法对 Amazon WAF 日志进行快速的汇总查询。

这里我演示一下最常用的按照 Host, URI 以及 Allow, Block 汇总迅速排查特定 Web 服务被误杀的情况：

1. 在 OpenSearch Dashboard  里找到 Block Allow Host Uri 这个图形统计表,按照 Count 倒序排列，使得访问量最大的 Host 排在头部。

2. 按照 Host 和 URI 再做排序。我们会发现访问量最大的站点是 3.210.215.137 这个站点(实际生产环境中多为站点的域名)。

访问这个站点最多的是根路径 “/”。

3. 现在我们调查一下这个站点的根路径访问阻断的 143 个请求。

把Host 3.210.215.137和 URI “/”  以及 Action Block 作为过滤条件 – “Filter for value”

此时 Dashboard 上只显示与这 143 条匹配日志相关的汇总和明细信息:

4. 转到 View By Matching Rule 表来检查 Amazon WAF 阻断明细:

可以迅速看到 Amazon WAF 日志的明细，快速判断这个特定阻断是由于没有 User Agent 请求头造成的:

总结

通过以上的步骤，我们使用 Log hub 快速部署方案创建了一个 Amazon WAF 的日志分析系统。这个系统，对于有安全运营需求的企业是非常必要的。通过快速部署这个系统，我们可以在一个比较成熟的企业云设施里更加快速地启用一个日志分析系统。

有了这个日志分析系统，我们基本可以用无代码的方式完成安全运营的工作了。本文的主要部署部分都是以 CloudFormation 部署完成，特别适合已经有 VPC 架构的成熟企业。

附录一

可选步骤一: 部署 ALB 以便从 Internet 访问 OpenSearch Dashboard。

创建 Target Group:

设定 ALB 转发 https 请求到 vpc-sample-waf-opensearch-vpc2-xxxx.us-east-1.es.amazonaws.com 所对应的私网IP 172.31.7.20。(nslookup 查询该域名可以得到私网 IP)

注意这里我们需要修改一下 health check 的 url 和 success code。

创建 ALB:

为 HTTPS Listener 添加证书:

配置完成以后，把 ALB 的域名加入到证书所对应的某个子域名的 cname。使得 url 访问时证书和域名匹配。

以 Route53 的域名配置为例，设置如下:

配置完成后，使用域名 https://sample-opensearch.xx.com/_dashboards/ 访问 OpenSearch dashboards，如果能够得到 OpenSearch 登录界面，即可进行下一步骤。

本篇作者

崔俊杰

亚马逊云科技解决方案架构师

负责亚马逊云科技边缘云安全相关的服务产品。为亚马逊云用户提供DDoS防御/网站前端安全防御/域名安全相关的产品咨询。对Cloudfront, Shield, WAF, Route53,Global Accelerator等边缘云安全相关产品有深入了解。在计算机安全，数据中心和网络领域有多年的工作经验。

戴晓斌

亚马逊云科技创新解决方案架构师

主要负责云上解决方案的设计与研发。在无服务器，容器，数据分析等方面有丰富的经验。

孙健

亚马逊云科技大数据解决方案架构师

负责基于亚马逊云科技的大数据解决方案的咨询与架构设计，同时致力于大数据方面的研究和推广。在大数据运维调优、容器解决方案，湖仓一体以及大数据企业应用等方面有着丰富的经验。

听说，点完下面4个按钮

就不会碰到bug了！