亚马逊云科技 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日志存储桶里看到。

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

对于日志量小于100TBytes/月的情况, 推荐使用Kinesis Firehose Delivery Stream。该选择不仅实时性高，价格也比直接写入S3便宜。
对于日志量大于100TBytes/月的, 且延时要求不高的, 可以考虑使用S3 Bucket, 每5分钟/75 MB产生一次日志。
*该部分内容在2022年10月20日根据实际实验的价格对比做过修正。
*直接写入S3费用高于Firehose Stream是因为WAF直接写入S3会需要CloudWatch做Vended Logs 转换处理。从而产生CloudWatch的费用。
具体细节可以参考 CloudWatch价格, Vended Logs部分: https://thinkwithwp.com/cloudwatch/pricing/

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

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

确保WAF日志的设置如下:

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

步骤二: 创建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/latest/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排在头部。