Increase Security Posture and Troubleshoot Service Delivery with Splunk & New AWS WAF Full Logs Feature

Today, we’re showcasing how Splunk works in concert with Amazon Web Services (AWS) Web Application Firewall (WAF) Full Logs to enhance security of services hosted in AWS and facilitate troubleshooting.

AWS WAF is able to increase the security posture of a service by filtering web traffic, blocking malicious requests, and more. It does this by leveraging a flexible rule language and is available for content delivered via Amazon’s CloudFront (Amazon’s Content Delivery Network) and routed through the Application Load Balancer (ALB).

This complements other AWS protections such as GuardDuty, which analyzes VPC flow data, CloudTrail events, and DNS logs to detect threats & anomalies and report them.

WAF Full Logs makes it easier to aggregate all of these findings into Splunk, which can enrich the events and provide additional context from other data sources and knowledge objects. This is useful for improving security and troubleshooting service delivery problems.

Ingesting WAF Full Logs into Splunk is quick and easy.

Step 1:
Enable Splunk to receive Kinesis data via the Splunk Add-on for AWS (select sourcetype=aws:waf). Detailed instructions can be found on Splunk Docs.

NB: WAF Full Logs requires having a Kinesis Data Firehose with a name that starts with the prefix aws-waf-logs-.

Step 2:
Add these settings to props.conf of your Splunk Search Head(s) and Splunk HTTP Event Collector(s).

TIME_PREFIX = "timestamp":
KV_MODE = json


Step 3:
Enable stream to Kinesis from WAF via the AWS Console.

Step 4:
Report & Investigate! Perform an ad hoc search request in Splunk (“sourcetype=aws:waf”), or create custom dashboards to show information that's useful for your security analysts. A dashboard could show the number of actions allowed vs. blocked, top 5 targets, and a map of sources:

We can drill down further into any of the visualizations to find the original event from WAF Full Logs.

Once in Splunk, it would be easy to enrich the data with additional human readable information. A terminatingRuleId could be complemented with a description to reveal a request was blocked because the source originated from an embargoed country.

This would be useful from a security context and could also be used to troubleshoot problems with connectivity to business services. It's now possible to easily discover a rule was misconfigured versus a problem with underlying service.

Happy Splunking with AWS. We hope to see you at our upcoming .conf18 in Orlando, and at our booth at re:Invent after that!

Brian Wooden

Posted by