AWS WAF Issue

[Lucas]

Hi, guys!

Wazuh is successfully fetching logs from bucket with no error or warning.

##ossec.conf

<wodle name="aws-s3">
  <disabled>no</disabled>
  <interval>10m</interval>
  <run_on_start>yes</run_on_start>
  <skip_on_error>yes</skip_on_error>

  <bucket type="waf">
    <name>xxxx-wazuh</name>
    <path>waf</path>
    <aws_profile>waf</aws_profile>
  </bucket>

  <bucket type="cloudtrail">
    <name>xxxx-wazuh</name>
    <path>cloudtrail</path>
    <aws_profile>cloudtrail</aws_profile>
  </bucket>

  <bucket type="guardduty">
    <name>xxxx-wazuh</name>
    <path>guardduty</path>
    <aws_profile>guardduty</aws_profile>
  </bucket>
</wodle>

-------------------------------

Unfortunately, the dashboard does not display only the WAF logs.

Kindly help me out in resolving this issue ASAP... 

PS. There are two types of WAFs, as shown in the file attached to "cloudwatch>Rules>Event Source".

And I made it by choosing the Web Application Firewall.

PS2.  I think there is no problem with the S3 Bucket path like the attached file.

And the logs are being saved well.

[carlos...@wazuh.com]

Hi Lucas,

Are you storing your AWS WAF logs into your S3 bucket using AWS Kinesis Data Firehose as explained in our official documentation?

Wazuh only supports the ingestion of WAF logs that have been stored via Kinesis, as it expects to find some fields that are only available when coming from Kinesis.

Please make sure you are following the steps provided in our documentation.

[Lucas]

Hi,  carlos!

I set it according to the official document.
The configuration file is attached with an image.

help me.

2022년 11월 28일 월요일 오후 4시 50분 26초 UTC+9에 carlos...@wazuh.com님이 작성:

[Lucas]

It's not mentioned in the official document, should I leave it disabled without setting logging in WAF?

2022년 11월 28일 월요일 오후 6시 3분 47초 UTC+9에 Lucas님이 작성:

[carlos...@wazuh.com]

It seems that the module is working correctly. However, it's possible that these WAF logs are not generating alerts. Take into account that not every WAF log you process will generate alerts, only those that match the rules, either default or custom, will trigger an alert. Having this in mind, let's see how we can check if the module is processing data and the data is triggering alerts.

Checking if logs are being processed
The easiest way to check if the logs are being processed, regardless of the type of bucket or service configured and regardless of whether alerts are being generated or not is by using the logall parameter. This parameter must be enabled in the ossec.conf configuration. You have to set this option to "yes" and then restart the wazuh service.

To understand how the logall parameter works it is necessary to learn about the flow that is followed when processing a log until the corresponding alert is displayed in the Wazuh UI. It is as follows:

1. The module downloads the logs available in AWS for the requested date and path.
2. The content of these logs is sent to the analysis engine in the form of an Event.
3. The analysis engine evaluates these events and compares them with the different rules available. If the event matches any of the rules an alert is generated, which is what ultimately is shown in the Wazuh UI.

With this in mind, it is possible to make use of the logall. When this option is enabled, Wazuh stores into "WAZUH_PATH/logs/archives/archives.log"  file every event sent to the analysis engine whether they tripped a rule or not. By checking this file it is possible to determine if the AWS events are being sent to the analysis engine and therefore working properly.

Note: Don't forget to disable the logall parameter once the troubleshooting has finished. Leaving it enabled could result in high disk space consumption.

Checking if a Event triggers a rule
If you have AWS logs available in your WAZUH_PATH/logs/archives/archives.log this means that the module is working, so it remains to check if there are no rules that match these logs. You can use our WAZUH_PATH/bin/wazuh-logtest tool for this. Copy one of the events in your archives.log file, run the logtest tool and paste it inside. 

The events in the archives.log shall appear in the following format:
2022 Nov 28 16:36:21 wazuh-master->Wazuh-AWS {"integration": "aws", "aws": {...}}

You must ignore everything to the left of the first curly bracket ("{"). That is, you must copy {"integration": "aws", "aws": {...}} to the end of the event, including the curly bracket.

The tool will validate your event and will show if there is rules that matches these kind of events.

Let me know if this was your case.

[Lucas]

I have a question.
Send data to kinesis from the Logging and metrics settings in AWS WAF > Web ACLs.
And
If you send data from cloudwatch to Kinesis via Event trigger, it seems to be a duplicate setting.

Is it right to set up AWS WAF > Web ACLs to send data to kinesis in Logging and metrics settings?
The AWS WAF setting part did not appear in the official document.

2022년 11월 29일 화요일 오전 1시 42분 44초 UTC+9에 carlos...@wazuh.com님이 작성:

[Lucas]

Hi, carlos

I tried wazuh-logtest as you told me.
It goes up to Phase 1 and 2, and it stops at Phase 2 and does not go up to Phase 3

2022년 11월 29일 화요일 오전 9시 48분 57초 UTC+9에 Lucas님이 작성:

[Lucas]

I tried it again and the result came out well.
What's the problem?

2022년 11월 29일 화요일 오전 11시 47분 16초 UTC+9에 Lucas님이 작성:

[carlos...@wazuh.com]

Your latest screenshot using wazuh-logtest confirm what I said in my previous message. Your WAF logs are being processed correctly, but they are not generating alerts because there is no reason to do so. Specifically, in your screenshot we can see that this particular log has triggered rule 80441, whose alert level is the lowest possible (0). That is why no alert has been generated. Alerts will not be generated unless the level of the triggered rules is equal or higher than the alert level specified in the ossec.conf.

In short, it is working correctly. If you still feel that these events should generate alerts, you can create your own custom rules that match your logs and have a higher alert level. Or you can create a rule that inherits from 80441 but has a higher alert level, so that your alerts are finally triggered.

I hope this helps clarifying how the alert level works.