AWS Partner Network (APN) Blog

How to Leverage Amazon Route 53 VPC DNS Queries in Splunk on AWS

By Igor Alekseev, Partner Solutions Architect at AWS
By Karsten Ploesser, ISV Solutions Architect at AWS

Splunk-Logo-2
Splunk-APN-Badge-5
Connect with Splunk-1.1

Customers are always looking for new ways to improve operational efficiency and the security posture of applications running in their virtual private clouds (VPCs).

This is where ingesting logs from Amazon Web Service (AWS) plays a key role. Amazon Route 53 recently launched a Resolver Query Logs capability which lets customers log the DNS queries originating in their Amazon Virtual Private Cloud (Amazon VPC).

This post provides step-by-step instructions for logging VPC DNS queries in Route 53, ingesting them into Splunk, and then analyzing them with Splunk.

Splunk is an AWS Advanced Technology Partner with AWS Competencies in Data & Analytics, DevOps, Security, and more. Organizations use Splunk solutions to solve their toughest IT and security challenges.

Resolver Query Logs Overview

Customers concerned about security, and those under compliance mandates, need the ability to monitor, debug, search, and archive a record of the DNS lookups occurring inside their Amazon VPCs.

Amazon Route 53’s Resolver Query Logs let customers log the DNS queries originating in their VPCs. This launch allows customers to log information on queried domain names, source IPs of the query-making resources, and DNS response values (and many others).

Customers can even log the DNS queries made by their AWS Lambda functions, Amazon Elastic Kubernetes Service (Amazon EKS) clusters, and Amazon WorkSpaces instances.

Resolver Query Logging also provides flexible storage options for customers; logs can be sent to Amazon Simple Storage Service (Amazon S3), Amazon CloudWatch Logs, or Amazon Kinesis Data Firehose.

Splunk Overview

Splunk is a leading platform for operational intelligence, delivering an easy, fast, and secure way to search, analyze, and visualize the massive streams of machine data generated by IT systems and technology infrastructure—physical, virtual, and in the cloud.

With Splunk, you can collect and index any machine-generated data from virtually any source or location in real-time. Once collected and indexed in Splunk, organizations are able to search, monitor, analyze, and visualize machine-generated big data coming from websites, applications, servers, networks, sensors and mobile devices, and more.

Walkthrough

Next, we’ll show you how to get started with this new feature and what needs to be configured in Splunk to take advantage of it.

We’ll share some examples of use cases, including command and control activities, as well as exfiltration activity. These examples will help you identify and mitigate malicious actors or compromised instances.

In order to proceed, you will need a Splunk Enterprise or Splunk Cloud account.

First, you’ll need to configure the Splunk HTTP Event Collector (HEC) feature within your Splunk environment as described in the Splunk documentation. As you do so, make sure your HEC token is configured with aws:route53 as the source type.

Next, you’ll switch to the AWS Management Console to configure the Amazon Kinesis Data Firehose service to send DNS logs to Splunk. Configure your Kinesis Data Firehose delivery stream to send data to Splunk by following the instructions provided in the Kinesis Firehose documentation.

Now, enable VPC query logging to send to Kinesis Data Firehose. Finally, verify that data is being ingested into Splunk by doing a search specifying sourcetype=”aws:route53″.

The architecture diagram below shows the final configuration after we complete the steps.

Route-53-DNS-Splunk-1

Figure 1 – Route 53 DNS queries Splunk ingestion architecture.

Steps to Configure DNS Queries Ingestion Into Splunk

The following steps assume you have configured HEC in Splunk and Amazon Kinesis Data Firehouse delivery stream as described above. Now, we’ll describe how to configure DNS resolver logging itself in more detail.

  • Start by configuring VPC query logging to go the Kinesis Data Firehose delivery stream you set up in the previous step.
    .
  • In the Route 53 console, navigate to the Route 53 Resolver menu item and then Query Logging.

Route-53-DNS-Splunk-2

  • Click on Configure query logging and enter the configuration name.
    .
  • Make sure to select Kinesis Data Firehose delivery stream as the destination for your DNS query logs.

Route-53-DNS-Splunk-3

  • Next, click on the Browse button and select the Kinesis Data Firehose delivery stream you configured for Splunk ingestion.
    .
  • In our example below, this corresponds to the stream named “SplunkCloud.”

Route-53-DNS-Splunk-4

  • Click on Add VPC in the VPCs to log queries for section.

Route-53-DNS-Splunk-5

  • Complete your configuration by clicking Configure query logging at the bottom of the page.
    .
  • Your new configuration will now be listed below:

Route-53-DNS-Splunk-6

  • Do a search specifying sourcetype=”aws:route53″ in the Splunk search user interface to verify that data is being ingested into Splunk.

Route-53-DNS-Splunk-2.1

Figure 2 – Splunk search results for Route 53 DNS queries.

You can enable and configure query logging for specific VPCs using the Route 53 Resolver API or the Route 53 Resolver console. If you need to log queries across multiple accounts, share your query logging configurations by using AWS Resource Access Manager (RAM).

Analyzing Data in Splunk

Now that the Amazon Route 53 data is in Splunk, it’s simple to gain insights across IT, security, and other use cases.

Combining the logs with VPC Flow Logs, for example, makes full network visibility more accurate and troubleshooting simpler. Applying basic analytics can also uncover security issues and vulnerabilities.

Below, we provide a few security-relevant examples illustrating the benefit of the new Resolver Query Logs with Splunk. DNS can be the vector for attack, like data exfiltration, or it can provide invaluable context for incidents occurring via other avenues, such as phishing.

Splunk regularly publishes security content through Enterprise Security (ES), ES Content Updates, blogs, and more. The vulnerability hunting examples below are taken from Hunting Your DNS Dragons, a blog post by Splunk’s Derek King.

The first example is the base-level search to investigate how changes over time in request volumes for particular resource types can be uncovered. Changes over time might indicate command and control or exfiltration activity.

Route-53-DNS-Splunk-7

Figure 3 – Number of queries over time graph.

Our second example looks for potential beaconing to command and control infrastructure. We do so by calculating and visualizing the variance over time of queries.

Route-53-DNS-Splunk-8

Figure 4 – Variance of queries over time graph.

These are just two examples of searches from the above blog applied to Resolver Query Logs. Others are simple to implement as well. With Splunk and Resolver Query Logs, IT and security operations teams can gain valuable additional insight into their environments.

Conclusion

This post demonstrated the ease with which you ingest DNS query logs into Splunk. This feature provides customers with an important new data source to complement their Splunk SIEM toolbox.

DNS query logging is available in all commercial regions. There is no additional charge to use DNS query logging, although you may incur usage charges for Amazon S3 or Amazon Kinesis Data Firehose, depending on your configuration.

Try ingesting your Amazon Route 53 logs into Splunk Cloud to improve operational efficiency and the security posture of applications running in your VPCs.
.
Splunk-APN-Blog-CTA-1.1
.


Splunk – AWS Partner Spotlight

Splunk is an AWS Competency Partner. Their software and cloud services enable customers to search, monitor, analyze, and visualize machine-generated big data from websites, applications, servers, networks, IoT, and mobile devices.

Contact Splunk | Partner Overview | AWS Marketplace

*Already worked with Splunk? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.