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.
NB: WAF Full Logs requires having a Kinesis Data Firehose with a name that starts with the prefix aws-waf-logs-.
Add these settings to props.conf of your Splunk Search Head(s) and Splunk HTTP Event Collector(s).
SHOULD_LINEMERGE = false
TIME_FORMAT = %s%Q
TIME_PREFIX = "timestamp":
KV_MODE = json
Enable stream to Kinesis from WAF via the AWS Console.
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.