方案介绍
动态资源和数据资源丰富的网站,由于对攻击者具有比较大的吸引力。需要根据安全事件响应的要求开展专业的安全运营工作。这时我们就需要一个安全日志分析系统(SIEM)来帮助我们更高效的完成日常的安全日志初步分析,以及深入分析的工作。由于这些工作对于这一类组织发生的频度较高。所以通常由承担安全运营职责的专职人员来完成,而且用户通常会选择以图形化菜单操作为主的方式完成日志分析和调查的工作。从而提高每一个安全事件响应调查的效率。满足组织对安全调查响应的服务时效要求。
Amazon WAF 可以支持与主流的图形化调查 SIEM 产品如OpenSearch, Elastic Search, Splunk, Sumo Logic 的集成。本文我们将主要介绍如何快速的启用亚马逊云科技的 OpenSearch 作为 WAF 的 SIEM 平台。快速开展安全运营工作。
内容简介
本文分为六个步骤为您讲述如何创建使用 OpenSearch 进行WAF安全调查的环境。
步骤一: 完成 WAF 的部署,确保通过 WAF 能够访问后端的 Echo-Server 网页。
步骤二: 创建 OpenSearch 访问环境。
步骤三: 导入 OpenSearch Dashboard
步骤四: 创建 Kinesis Firehose, 将 WAF 日志转发到 OpenSearch 集群中
步骤五: 映射 Firehose IAM Role 到 OpenSearch 用户
步骤六: 使用 OpenSearch Dashboard,开展 WAF 日志调查工作
架构图
步骤一:完成 Amazon WAF 的部署
确保通过 WAF 能够访问后端的 Echo-Server 网页。
步骤二:创建 OpenSearch 访问环境
1. 登录亚马逊云科技控制台,选择 OpenSearch 服务,选择 Create domain:
2. 选择 Production (生产环境),并选择1.1版本
3. 等待15分钟左右,OpenSearch 节点准备好了以后进行下一步
4. 完成以后得到 OpenSearch Dashboards URL:
5. 点击Dashboard URL进入 login 状态。输入创建 dashboard 时输入的用户名密码
6. 选择 Global tanent:
注意如果选错了,可以到右上角切换 tenant 改过来。Private tenant 各用户的数据不能共享。不适合 SIEM 的场景。
这样我们就准备好了 OpenSearch 的日志存储集群。
步骤三:导入 OpenSearch Dashboard
准备好了 OpenSearch 的集群,我们就拥有了一个可以通过 HTTP API 接口注入日志由 OpenSearch 进行索引的日志搜索平台。纯日志的搜索已经可以通过 Discover 菜单开展了。为了使得安全日志可以使用图形化界面进行搜索。我们需要导入 dashboard, 为图形化日志分析做准备:
1. 如果你有现成的 ndjson 文件,倒入即可
我尝试寻找一些开源,最终使用了,但他不是最好的,需要自己修改
https://github.com/aws-samples/aws-waf-ops-dashboards/blob/main/awswaf-es-index.ndjson
点击导入的 dashboard,已经可以看到 WAF dashboard 的框架。下面我们再把 OpenSearch 的输入 Index Template 设定一下:
步骤四: Index Template 的设定
Index Template 的设定是让 OpenSearch 在对 WAF 输入的日志进行索引写入的时候。对每个 json 单元做不同的数据类型设定。以便后面查询的时候可以根据特定字段来进行查询和汇总。这个部分如果预先不设定好,有些 Dashboard 的图形化显示会不能正常工作。
*注意我们下周即将发布的 WAF 部署小指南 (四) 的 Log hub 解决方案里这部分工作都是自动完成的。有兴趣大家可以尝试。
*如果 Mapping 设置未完成而日志已经写入。则已经写入的日志不能有效搜索。需要等下一个 index 周期(一小时或者一天)以后,新的 index 生成才能生效。
1. 点击 OpenSearch 的 Dev Tool。
2. 在左边边框输入我们准备好的 Mapping 设置,得到“Acknowledged”表示设置成功了。
*注意我们这里的 json 设置是对每个 WAF 日志字段做过精细调整的。目的是把 WAF 日志的可搜索性再提高一些。所以设置的 json 文件会比较长。
我的设置是粗略的
PUT _template/waf_logs_template
{
"index_patterns": [
"aws-waf-logs-*"
],
"mappings": {
"properties": {
"timestamp": {
"type": "date"
}
}
}
}
至此,我们的 OpenSearch 分析日志的准备工作基本完成。可以开始做 WAF 日志的设定,把日志引入 OpenSearch 了。
步骤五: 创建 Kinesis Firehose, 将 WAF 日志转发到 OpenSearch 集群中
1. 找到我们在 WAF 部署小指南 (一) 准备的 WAF Web ACL。把日志输出转到步骤二创建的 OpenSearch 集群里。
2. 创建一个新的 Kinesis Data Firehose Delivery stream:
注意这里的 Delivery stream 的名称仍然需要以 aws-waf-logs- 开始。
等待2分钟左右 Delivery Stream 创建完毕。
3. 创建好以后关联到 WAF logging 设置里。
步骤六:映射 Firehose IAM Role 到 OpenSearch 用户
完成这个工作以后,我们需要把 Firehose Delivery Stream 的 IAM Role 映射到 OpenSearch 的用户里。从而使得 Firehose 写入 OpenSearch 日志的动作不被拒绝。
1. 获取 Kinesis Delivery Stream 的 IAM Role ARN:
2. 点击 IAM Role 进入 IAM 界面拷贝 Role ARN。
得到类似arn:aws:iam::123456789000:role/service-role/KinesisFirehoseServiceRole-aws-waf-logs-us-east-1-1234567890406 的 IAM Role ARN。这是 Firehose 做写入动作的服务角色。下面需要在 OpenSearch 里赋予它写入 OpenSearch 的能力。
3. 进入之前的 OpenSearch 左侧菜单点击 Management – Security – Roles – all_access:
4. 点击 Mapped users:
5. 进入 Manage Mapping 设置加入 Kinesis Firehose 的 IAM ARN
6. 添加 Backend roles,填入之前的 Firehose IAM Role ARN “arn:aws:iam::123456789000:role/service-role/KinesisFirehoseServiceRole-aws-waf-logs—us-east-1-1234567890406”. 点击 Map ,完成添加动作。
注意以上步骤如果不做,我们的 OpenSearch 内部是看不到日志的。并且会在 Delivery Stream 的如下位置看到 OpenSearch 返回的错误信息:
具体错误信息如下:
Error received from the Amazon OpenSearch Service cluster. {"error":{"root_cause":[{"type":"security_exception","reason":"no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::123456789000:role/service-role/KinesisFirehoseServiceRole-aws-waf-logs—us-east-1-1234567890000, backend_roles=[arn:aws:iam::123456789000:role/service-role/KinesisFirehoseServiceRole-aws-waf-logs—us-east-1-1234567890000], requestedTenant=null]"}],"type":"security_exception","reason":"no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::123456789000:role/service-role/KinesisFirehoseServiceRole-aws-waf-logs—us-east-1-1234567890000, backend_roles=[arn:aws:iam::123456789000:role/service-role/KinesisFirehoseServiceRole-aws-waf-logs—us-east-1-1234567890000], requestedTenant=null]"},"status":403}
我们在配置中遇到这个错误的技术人员不在少数。虽然大家经过仔细分析,最终都解决了这个问题。但也花了不少时间。所以特别在这里着重强调一下。
步骤七:使用 OpenSearch Dashboard,开展 WAF 日志调查工作
完成以上工作以后,我们的 WAF 日志分析系统就基本完成了。
现在来看看整体的 Dashboard 效果:
1. 首先我们会有全局的一个了解。知道 WAF 在过去的特定时间段允许和拒绝的请求情况。并且可以根据 WAF ACL Rule 的匹配来做特定的检查。注意这里我们是全量的日志分析。
2. 然后,对于要进行深入安全调查工作的人员,我们主要会使用下面一个表:
3. 现在我们来用点击的方式制作几个过滤条件来做组合查询。
首先选择 Block 的 WAF 请求:
然后选择表中的 httpRequest.country。点击浮窗里的+号。即过滤同是来自法国的请求。
然后我们添加第三个条件,选择 httpRequest.clientIp。点击浮窗里的 – 号。即过滤除了来自92.42.109.58 的 client 请求。
三个过滤条件叠加查询的结果,让我们了解到来自法国被阻断的请求中还有21条来自另外一个 clientIp 的请求:
值得一说的是,Dashboard 里的构成的三个过滤条件,都是以 DQL 这种 json 格式的查询语句来构成的。执行下面的操作可以看到这些语句:
可以看到,每一个条件都是以 DSL 的 json 格式表达出来的。有了 dashboard, 我们就可以把灵活的查询语言以拖拉拽的方式组合成一个复杂的查询策略。完成我们每天不同的查询任务。