AWS：WAF的WebACL日志和Logz.io集成

今天你吸猫了么
1,195 阅读6分钟

在第一篇文章--AWS。Web应用防火墙概述、配置及其监控- 我们谈到了它的主要组成部分，为它创建了一个WebACL和规则，并进行了基本的监控。

此外，我们还用AWS Kinesis配置了WebACL的日志收集，但现在是时候看看Logz.io了，因为CloudWatch Logs还不能用于它。

因此，在这篇文章中，我们将配置日志通过AWS Kinesis发送到AWS S3桶，然后将配置Logz.io从S3抓取这些日志，并将讲述日志内容以及如何使用它们来进行调试。

AWS WAF日志

除了CloudWatch指标，我们还可以对通过我们的WebACL传递的所有请求启用日志。

AWS WAF使用AWS Kinesis来发送数据，AWS S3来存储日志。

不幸的是，WAF和Kinesis不能使用CloudWatch日志（至少，在拧的那一刻，因为AWS技术支持告诉我，它计划启用它们）。

所以，让我们做以下工作。

  1. 配置一个Kinesis Firehouse流
  2. 配置一个WebACL来向该流发送数据
  3. Kinesis流将发送数据到一个AWS S3桶中
  4. 而Logz.io将使用其连接器从这个S3中获取日志。

AWS Kinesis

**注意：**一条AWS WAF日志相当于一条Kinesis Data Firehose记录。如果你通常每秒收到10,000个请求，请在Kinesis Data Firehose中设置每秒10,000条记录的限制以启用完整的日志记录。

进入AWS Kinesis，创建一个新的_Data Firehose交付流_，记住它的名字必须以 "aws-waf-logs-"为前缀。

选择_直接PUT或其他来源_，点击_下一步_。

在下一页跳过数据转换，点击_下一步_，然后在_目的地_中选择_S3_，并创建一个新的S3桶。

这里，我使用的是一个已经存在的桶。为了避免混合来自不同ACL的日志 - 添加一个前缀。

在下一页，保留所有的默认值。如果有什么事情会出错，Kinesis会通过CloudWatch发送一个消息。

要想获得这些消息，请将_错误日志_选项设为有效。

Check the settings, and create the stream:

等待几分钟后，流就会被创建。

或者直接进入一个WebACL。

WAF ACL的日志记录

进入ACL，在_日志和度量_标签上点击_启用日志_。

选择上面创建的流。

在这里我们也可以启用过滤器，下面会讲到它们。

Logz.io S3 Bucket

文档在这里>>。

首先，我们需要创建一个IAM策略和一个角色，它将提供对S3桶的日志的访问。检查它的文档在这里>>。

Logz.io将通过这个角色进行AssumeRole，以获得访问该桶的权限。

Logz.io S3配置

要到S3桶，点击_添加一个桶_。

选择_用一个角色进行认证_。

指定桶的名称，点击获取_角色政策。_

IAM政策

复制政策内容，到AWS IAM，创建一个新的政策。

从Logz.io中添加JSON。

保存该策略。

IAM角色

转到 в AWS IAM Roles, 创建一个新角色。

选择_另一个AWS账户_，指定来自Logz.io页面的账户ID和外部ID。

在_权限_页面，附上我们上面创建的策略。

保存该角色。

在_其受信任的实体_中，我们可以看到账户ID，它将能够承担该角色。

复制角色的ARN。

回到Logz.io，设置ARN，并选择一个AWS区域。

在数据类型中选择_其他_。

并将其值设置为_awswaf_（见这里的所有类型>>），这样ELK就能解析日志的JSON了。

点击_保存_，该桶被连接到你的Logz.io账户。

WAF日志--字段

现在，需要为WebACL附加一个ALB，等待流量在ACL的日志中看到一些东西。

将ACL附加到入口处 - alb.ingress.kubernetes.io/wafv2-acl-arn:

几分钟后，检查S3--一个带有我们的前缀的新目录将被创建，有一年的时间，这是由Kinesis添加的。

还有第一个日志文件。

再一次，等待几分钟，这样日志就会被传送到Kibana。

ELK会解析它的字段，我们可以在搜索中使用它们。

主要有两个字段：type: "awsfaw" ，观看所有日志，或webaclId ，只选择特定的WebACL的日志。

此外，值得在结果表中使用以下字段（见所有可用的文档>>>）。

  • httpRequest.clientIp ：一个请求来自的IP
  • httpRequest.uri: 请求中使用的URI
  • httpRequest.args ：它的论据
  • terminatingRuleId ：一个WebACL的规则，这是最后一个ALLOW或BLOCK的规则。
  • ruleGroupList ：一个WebACL的所有规则，对一个请求进行了检查。

让我们看看我们能在日志信息中找到什么。

首先，让我们检查一个被允许访问我们的应用程序的请求，即用ALLOW动作。

这是一个从IP_99.***.***.101_到URI_/***/126/like的_请求，它被ruleGroupList 链中指定的规则检查过，最后它被WebACL的Default_Action 允许。

此外，在ruleGroupList 中，我们可以看到有一条规则被应用于请求--SignalNonBrowserUserAgent ，但由于我们将该规则设置为_COUNT_动作，所以它被忽略了。

最后，在terminatingRuleId в，我们看到Default_Action 被应用，因为SignalNonBrowserUserAgent 由于COUNT动作而被排除。

如果一个请求被阻止了，那么在Default_Action ，我们会看到一个规则被应用到_BLOCK_动作中。

重删字段--从日志中排除数据

在日志中，我们可以得到一些我们不希望出现的数据，例如cookie信息或认证令牌。

要删除这些数据，请进入日志设置，然后在_重写字段_中选择需要被排除的字段。

在目前的情况下，它将是标题和其中的两个字段 -authorization 和cookie 。

应用更改，现在你会看到它们的值是_REDACTED。_

Logz.io的警报

另外，在块上获得通知是一个好主意。

让我们通过Logz.io与Opsgenie的集成创建一个警报，Opsgenie将向我们的Slack发送通知。

描述一个警报的条件，在_过滤器中添加_ action != ALLOW 。

选择一个渠道来发送警报，以及你想在信息中看到的字段。

等待Slack中的警报。

完成。

类似的帖子

The postAWS:WAF的WebACL日志和Logz.io集成首次出现在RTFM：Linux、DevOps和系统管理上。

avatar
文章
阅读
粉丝