The cloud-first movement is taking over every facet of information technology, and DNS is not excluded. There are tons of vendors that provide solutions around DNS security. The use case this blog will cover can apply to many of them, but I’m choosing to focus on Cisco Umbrella because recently there have been a flood of questions with the same major theme:
“Cisco Umbrella sent me an alert that it blocked a malicious domain, but the host who tried to initiate the communication is my public address. How do I figure out who the user was?”
An oversimplified visualization of this traffic path might look like the below image. Inside the network, there is clear attribution of the user’s IP address. But since the DNS query travels to the internet for resolution, the private IP address is quickly obfuscated by the public NAT. By the time the event is blocked and alerted on, Cisco Umbrella only knows the public source address.
So there is some good news here, the bad traffic was stopped… but we are clearly left with big questions like:
- Who is the source IP address, and more specifically, who is the source user?
- What else was this user doing on my network leading up to and following the event?
To be fair, Cisco has thought about this problem and addressed it. They offer both an agent that can be installed on client workstations as well as internal DNS servers that would help to resolve this first question. However, this requires that we bring equipment/software on-prem for our cloud solution (not ideal). More importantly, we still can’t determine what else the user was doing.
Network metadata gives an interesting perspective.
Flow data has long been a great source of network forensics. If something happens on the network, then flow data is surely going to have a record of it. There is a problem though; most variants of flow data do not provide user attribution or visibility into DNS requests.
Plixer’s FlowPro Defender is a lightweight appliance that is designed to enhance network metadata and give users all the information they need to respond to events just like our initial user case. The FlowPro captures packet data and converts it to metadata, which can then be harvested by a network traffic analysis solution like Plixer’s Scrutinizer.
Adding a simple SPAN port on our switch gives us all the visibility we need to bind a DNS request to an internal IP address.
With this done, we can now see every request a client IP address is making and correlate it to alerts that our cloud DNS vendors are providing us. My last recommendation is to consider a flow solution that supports user attribution. The ability to correlate the IP address to a user speeds up investigations, especially in large DHCP environments. These topics have been covered in a variety of other blogs with products like Cisco ISE, Forescout Counteract, Microsoft AD, and more. We are passionate about visibility, and would be happy to help you in whatever goals you have concerning these types of initiatives. Reach out to us directly if this looks like something that could help your organization.
