亚马逊云科技 WAF 部署小指南（四）使用 Log Hub 自动部署方案进行 WAF 安全运营

方案介绍

在前述的 WAF 部署小指南（三）中，我们了解了如何使用 OpenSearch 作为 WAF 日志分析的平台。并部署了一个图形化分析 WAF 日志，开展 WAF 安全运维的环境。了解了 OpenSearch 分析 WAF 日志的原理和运维方法，大家对一个有安全运营需求的组织如何利用亚马逊云科技托管服务来完成 WAF 相关的安全运营应该有了系统的认识，只是从部署的效率上看，大家都还想要有更快的部署方法。

本文特别介绍亚马逊云科技的 Log hub 解决方案，来帮助大家进行这个方案的自动化部署，用更快的速度完成 WAF 部署小指南（三）所介绍的解决方案。

*Log hub 解决方案除了能处理 WAF 日志以外，还能处理很多其他的亚马逊云科技云原生服务的日志。本文主要介绍 Log hub WAF 日志相关的运用。

内容简介

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

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

步骤二：创建 OpenSearch 集群

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

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

步骤五：Log hub 流程解析

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

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

系统架构图

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

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

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

对于成本比较关注的，且延时要求不高的，推荐直接使用 S3 Bucket，每 5 分钟/75MB 产生一次日志
对于实效性要求比较高的，且日志量不大的情况，推荐使用 Kinesis Data Firehose Stream

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

确保 WAF 日志的设置如下：

确认 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 会发现它解析成为 VPC 内部的私网 IP。

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

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

本步骤是为了 Cloudformation 中的 Lambda 在不访问 Internet 的情况下从 S3 读取 WAF 日志，以及让 Lambda 从 VPC 内部访问 OpenSearch API。

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

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

打开 CloudFormation 控制台
启动 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 过程分为以下几个步骤：

WAF 写日志到 S3 桶（直接写入或通过 Kinesis Firehose 写入）。
WAF 日志以文件形式 Put 到 S3 存储桶的事件被发送到 SQS。
SQS 调用 Log Processor Lambda 函数去读取日志文件并处理（此处使用 S3 endpoint 可以节约流量费用）。
Lambda 把处理过的日志通过 OpenSearch Web API 导入到 OpenSearch 索引库以供进一步分析。
无法处理的日志会被导出到失败日志存储桶里（带错误原因）。

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

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

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

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

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

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

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