Rogue DNS kinda reminds of me of a crime scene show I saw once.  The killer was hijacking the GPS mapping system in the rental cars of their victims.

Imagine that who you think is your valid DNS server actually isn’t.  Yeah… i know – scary.   If you are not familiar with the term “Rogue DNS”, maybe you might know the exposure via other terms like DNS hijacking or DNS redirection to name just a few. No matter what you call it, it isn’t a good thing. 

In this blog I’m not going to teach about what Rogue DNS… DNS hijacking… or DNS redirection. Nor am I going to talk about solutions like OpenDNS (Cisco’s Umbrella).  I’m going to just show you how you can use Stealthwatch to get visibility into what is REALLY going on in your network in reference to DNS.  We are going to cover 2 situations where having a tool like Stealthwatch could help you with your DNS.

1. Finding Rogue DNS
2. DNS Server Cutover:  Checking Reality before Decommissioning DNS Servers

How does Stealthwatch do this?  I refer to Stealthwatch as “Your Network Detective Command Center”.  If there are rogue DNS in your network and your end devices are communicating with them…. then all you need to do is get the visibility into that.  How?  Easy… enlist your network.  If 2 end hosts in your network are talking with each other in your network….  they are going through your network devices.  Easy then…. just “deputize” your network devices to report into the Network Detective what they see.  🙂 

Finding Rogue DNS

In my environment above I have

1. Stealthwatch Management Console (SMC) version 7 running as a VM
2. Stealthwatch Flow Collector (FC) version 7 running as a VM
3. Four Cisco devices doing exactly what they were configured to do before… just now they have also been “deputized” to “report in” what they see (via Netflow in this specific example)

In other…. I am set and ready to proceed. 

Now what?  Well “Rogue” DNS would imply DNS that aren’t your official DNS servers.  So let’s start there.  We are looking for 

• Devices
• Not in your approved list of DNS Servers
• Serving up DNS (UDP 53) in your network

We have all the information we need cause we have “deputized the network” so it is easy to search for UDP 53.  In order to figure out which devices in your network are serving up DNS and not approved DNS servers, we need to know what your approved DNS servers are of course

We only need to do 3 things:

1. Create A Stealthwatch Host Group for our Approved DNS Servers
2. Create A Stealthwatch Flow Search Query asking for all flows with a peer IP that is serving up DNS and is not in the approved DNS Servers group
3. Run the Query 

.

Create A Stealthwatch Host Group

In my lab environment I went into Stealthwatch and defined a Host Group I called “DNS Servers” and I assigned 2 subnets to be associated with that host group – 10.1.103.0/24 and 10.2.203.0/24.  These are the 2 subnets in my environment where I have my “approved” DNS servers.   Since the area you fill out is just “IP addresses and Ranges” …  while I did 2 /24s this could be anything.  You could have just list out a bunch of hosts (/32s).

Create A Stealthwatch Flow Search Query

What to do now?  Super simple.  In Stealthwatch create a Flow Search Query  of all traffic to peer protocol UDP 53 that are not in your approved DNS Server host group.  

The below is what this would look like.  In fact since you might want to run this flow search query again in the future, you can save the search just like I did.  I called it “DNS 24 Hours and !DNS Server Host Group” and saved this specific search off to the saved searches so I can quickly and easily run it again in the future.

Run The Query

Clicking “Search” now in the upper right hand corner to run this search gives us….. drumroll please…. 417 flow search results.  Yup.  There is definitely some DNS going on that is outside of our approved DNS Servers.  You have officially found “Rogue DNS Servers”.  

417 flow search results is, admittedly, a bunch to go through.   Fortunately, Stealthwatch has a bunch of ways you can quickly get through this to find the list of all the rogue DNS servers AND the devices that are going to them.  

One thing I adore are the little white boxes at the top.  See them?  Go to the pic below.  See?  Across the top of the columns are the column names as well as a nice little box at the top of each column right below the name.  I love these little boxes!  🙂    

So we have 417 flow search results right?  We can see some of them are 8.8.8.8 (google DNS).   Let’s type in “!8.8.8.8” in the little box below Peer IP address.  What does this do?  It filters out 8.8.8.8 from the search results.  Leaving us with whatever is !8.8.8.8 and also is !DNS Servers and is serving up DNS (udp 53) in our environment.  

Another thing you could have done sorting through the 417 is to toggle the “Peer IP address” column so it toggles the sort –  ascending and descending – and then just eyeball it and write down all your Rogue DNS and then build a query to see if your eyeballing missed anything.

What do I mean?  Well we saw 8.8.8.8 and also 198.18.133.1.  Let’s say you think those are the only two you saw.  Easy.   Do a flow search like below. 

Yup.  Flow search results for the past 24 hours confirm there were no other Rogue DNS in the environment except for 8.8.8.8 and 198.18.133.1.  

Now that you can see how simple it is to do a search.  Why not use Stealthwatch next time you are considering doing something like decommissioning DNS servers you think aren’t being used any more.  Why not check first?  🙂

DNS Cutover: Checking Reality Before Decommissioning

Let’s say you are going to decommission all the DNS Servers in subnet 10.2.203.0/24.    But first before doing that might I suggest the following…..

1. Edit the Stealthwatch host group, DNS Servers, to no longer have 10.2.203.0/24 in it. 
2. Create a new flow search that just searches for peer IP 10.2.203.0/24 and UDP 53
3. Save this flow search
4. Check every now and again if anyone is using them

Once the coast looks clear… THEN decommission them.

Why the suggestion to remove 10.2.203.0/24 from the DNS Servers Host group?  It isn’t necessary.  But my view is if you are planning to decommission them… why not take them out so if you run the saved “Rogue DNS” flow search and 10.2.203.0 is being used… it will show up.

As we can see below…. there are 80 flow search results for devices still using 10.2.203.0/24 subnet for their DNS Servers.   You might want to sort these out prior to decommissioning.  🙂

Super easy eh?  🙂 

Note:  The information I covered  in this blog is based on a YouTube I did titled  “Stealthwatch and Your DNS”.   

Side note:  If you also decide to watch the video… um…. sorry for them not exactly being my usual YouTube quality.  I needed to, by the Friday after Thanksgiving, have 4 videos done for something internal at Cisco.  Being completely transparent I was trying to meet that deadline… wasn’t in my own house… and a family member was in the hospital getting a pacemaker in.   When I saw the videos I decided I wasn’t going to put them up on YouTube cause I wasn’t my usual upbeat self in teaching and I also was talking very softly.  Then I thought… ya know what… The content for the 4 videos  (IOT, ETA, DNS, and Segmentation) is important and I should upload them to YouTube for others even if I’m not overly keen on the audio portion. 

Jan 17, 2019 Update:  The DNS YouTube has been updated.   It is called “Find Rogue DNS Servers with Stealthwatch“

Categories: Security, Stealthwatch

Tags: dns hijacking, dns redirection, DNSChanger, Operation Ghost Click, rogue dns, rogue dns server, rogue dns servers, Stealthwatch