Table of Contents

1. 1. Introduction
2. 2. How notifications work
3. 3. Key points to look for in your environment and examples of misconfigurations
4. 4. Other misconfiguration examples
5. 5. Conclusion

1. Introduction

If you are using WafCharm for AWS, you might also use WafCharm’s Reporting and Notification feature. Because the reports are generated monthly, you may not notice there were misconfigurations until next month.
This post will introduce key points to look for when configuring to use the feature and misconfiguration examples.

Set up manuals

If you want to use Kinesis Data Firehose to output logs, refer to:
https://docs.wafcharm.com/manual/new_aws_waf/new_aws_waf_reporting_and_notification_EN.pdf

If you want to send logs to S3 buckets directly, refer to:
https://docs.wafcharm.com/manual/new_aws_waf/new_aws_waf_reporting_and_notification_EN_S3_version.pdf

Note:
On May 11th, 2022 (JST), WafCharm was updated to accept WAF logs directly published to an S3 bucket for our Reporting & Notification feature.

Previously, WAF logs had to be sent through Kinesis Data Firehose to enable Reporting & Notification feature. With this update, you can publish WAF logs directly to S3 to use the same function.

Refer to the blog post below for more information.
How to change the setting in Reporting & Notification feature in WafCharm to only use S3 instead of Kinesis Data Firehose

Key points to look out for are the same regardless of the method you choose to send WAF logs. If you are using the new S3 method, you can also continue referring to this post.

2. How notifications work

Below is a diagram that shows how transferring of WAF log works in WafCharm’s Reporting & Notification feature if you are using Kinesis Data Firehose.
*Refer to the manual above to see the diagram for the S3 method.

Processes executed in your environment if you are using Kinesis Data Firehose are as follows.

1. Send WAF logs to your S3 buckets using Kinesis Data Firehose
2. Lambda is triggered when WAF log is sent to your S3 bucket to put the WAF logs to WafCharm envinronment

3. Key points to look for in your environment and examples of misconfigurations

There are two main key points to check:

• WAF logs are outputted
• Lambda function is working as intended

3-1. WAF logs are outputted

Check your S3 bucket to see if WAF logs are delivered.
If the logs are not there, make sure you have correctly attached the intended Kinesis Data Firehose in your AWS WAF logging destination setting and adjust if necessary.

3-2. Lambda function is working as intended

Check Lambda’s logs to make sure the Lambda function is working properly.

You can see the logs by following the steps:

1. Open CloudWatch
2. Click Log groups on the left side menu
3. Click the function name (Example: “/aws/lambda/wafcharm-waflog” if you have set it up just like the manual)
4. Look at the latest Log Stream (the first one on the list)
5. Check if there are any ERROR messages

If you see an error, check the message and resolve it accordingly.

The common mistake seen in regards to Lambda is the IAM permission setting for Lambda. Wrong values are entered into Resources often; there may be an extra “/” before the S3 bucket name, or you might be missing “∗” at the end. Sometimes, specified resources could also be incorrect, so please check the Resources value you’ve entered.

Example of a correct value:
“arn:aws:s3:::csc-waftest/waflog/∗”

Examples of wrong values:
“arn:aws:s3:::/csc-waftest/waflog/∗”
“arn:aws:s3:::csc-waftest/waflog/ _”

In addition, you are required to specify WafCharm’s Resources when configuring a policy to put logs in S3 of WafCharm’s environment. However, sometimes you could accidentally set your S3 bucket, so please make sure you have given WafCharm’s resources where necessary.

After you’ve edited the IAM permissions listed above, those changes may not be applied to running Lambda. Add a blank line at the end of index.mjs and deploy again to ensure the changes are applied.

4. Other misconfiguration examples

There could be unintentional spaces at the beginning or the end of the S3 bucket prefix for the Kinesis Data Firehose configuration. This is not easy to spot, so if permissions are correctly given, and you’ve made sure everything else is set up correctly but still find issues, we recommend you to check for unnecessary spaces placed in the Resources.

5. Conclusion

We’ve introduced common mistakes seen in configuration with specific examples.
If you’ve gone through everything explained above but still have issues, we are happy to help and check if your WAF logs have been transferred. In such a case, please contact the Support team with the information below.

If you are using Kinesis Data Firehose, provide the Web ACL and Delivery Stream Name.

If you are sending WAF logs directly to S3, provide the Web ACL ID and log file prefix.