亚马逊AWS官方博客

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

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

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

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

  1. WAF 写日志到S3桶 (直接写入或通过Kinesis Firehose写入)
  2. WAF日志以文件形式Put到S3存储桶的事件被发送到SQS
  3. SQS 调用Log Processor Lambda函数去读取日志文件并处理 (此处使用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这个函数的执行日志里找到线索。也可以尝试用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排在头部。

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表来检查WAF阻断明细:

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

总结:

通过以上的步骤,我们使用Log hub快速部署方案创建了一个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等边缘云安全相关产品有深入了解。在计算机安全,数据中心和网络领域有多年的工作经验。

孙健

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

戴晓斌

亚马逊云科技创新解决方案架构师,主要负责云上解决方案的设计与研发。在无服务器,容器,数据分析等方面有丰富的经验。