Pinpointing Original DNS Requests that Trigger Alerts

[Jon Booth]

On my network, I have our WAN ports tapped as well as a port going to our main DNS servers that are access-listed to only allow DNS traffic. Every now and then I will get an alert about DNS queries to suspicious/malicious TLDs or nameservers (.io, .pw, no-ip, etc) that pops because one of the DNS servers is going out the WAN with those requests. My issue is, I am having a hard time correlating those requests to the internal requests that triggered the DNS server to go searching.

For instance, at the moment I have a few alerts for "ET INFO DYNAMIC_DNS Query to a Suspicious no-ip Domain". The caps show one of my nameservers requesting the records for ns1.no-ip.com, but doing searches in Kibana for "no-ip" or the returned IP yield no results other than those outbound requests. Obviously, I would like to see what query was made to my internal DNS server (and from which machine) that caused it to look up the ns1.no-ip.com records. I appreciate any help.

[Michael Gates]

On Friday, June 8, 2018 at 8:56:02 AM UTC-5, Jon Booth wrote:
> On my network, I have our WAN ports tapped as well as a port going to our main DNS servers that are access-listed to only allow DNS traffic. Every now and then I will get an alert about DNS queries to suspicious/malicious TLDs or nameservers (.io, .pw, no-ip, etc) that pops because one of the DNS servers is going out the WAN with those requests. My issue is, I am having a hard time correlating those requests to the internal requests that triggered the DNS server to go searching.
>
> For instance, at the moment I have a few alerts for "ET INFO DYNAMIC_DNS Query to a Suspicious no-ip Domain". The caps show one of my nameservers requesting the records for ns1.no-ip.com, but doing searches in Kibana for "no-ip" or the returned IP yield no results other than those outbound requests. Obviously, I would like to see what query was made to my internal DNS server (and from which machine) that caused it to look up the ns1.no-ip.com records. I appreciate any help.

So are you tapping the traffic between the LAN and your DNS servers? If not you'd either need to tap there, or enable logging on the servers to see what internal host made the request.

[Jon Booth]

On Friday, June 8, 2018 at 12:44:30 PM UTC-5, Michael Gates wrote:

> So are you tapping the traffic between the LAN and your DNS servers? If not you'd either need to tap there, or enable logging on the servers to see what internal host made the request.

Thanks for the reply, Michael. Yes, I am tapping each port going to our DNS servers and filtering that traffic for only DNS (through the use of an access-list on a Cisco device). I know that I am getting the internal traffic because I can do a tcpdump on the SecurityOnion Sensor interface and see all of it, I am just having trouble correlating these alerts to the original requests that led to them. Obviously the end user machine (or possibly server) that is responsible is not requesting "ns1.no-ip.com", but it's requesting something that nameserver handles, and I am trying to find out the best way to pinpoint that.

[Kevin Branch]

Hi Jon,

What I do is filter out DNS packets between my internal DNS servers and the outside from NIDS scrutiny, and then make sure that Snort/Suricata is monitoring the DNS requests between my inside hosts and my internal DNS servers.  Then the only DNS NIDS alerts you will see should be ones involving the original systems that formed the DNS queries.

Kevin

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.