duplicated intel logs DNS::IN_REQUEST

Zeek
1

Hi everybody,

I am having an issue with the intel.log file, I am getting duplicated lines for the same dns request such as:

#fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p seen.indicator seen.indicator_type seen.where seen.node matched sources fuid file_mime_type file_desc cif.tags cif.confidence cif.source cif.description cif.firstseen cif.lastseen

#types time string addr port addr port string enum enum string set[enum] set[string] string string string string double string string string string

1570105259.197420 CP1BZx1QgzdPpfEyda 172.17.0.186 43283 172.16.1.10 53 opencalphad.com Intel::DOMAIN DNS::IN_REQUEST worker-1 Intel::DOMAIN 0 - - - - 85.0 - - - -

1570105259.197420 CP1BZx1QgzdPpfEyda 172.17.0.186 43283 172.16.1.10 53 opencalphad.com Intel::DOMAIN DNS::IN_REQUEST worker-1 Intel::DOMAIN 0 - - - - 85.0 - - - -

1570105259.207335 CJZASAQTB2qgPSYw7 172.17.0.186 59553 172.16.1.10 53 opencalphad.com Intel::DOMAIN DNS::IN_REQUEST worker-1 Intel::DOMAIN 0 - - - - 85.0 - - - -

1570105259.211927 CJZASAQTB2qgPSYw7 172.17.0.186 59553 172.16.1.10 53 opencalphad.com Intel::DOMAIN DNS::IN_REQUEST worker-1 Intel::DOMAIN 0 - - - - 85.0 - -

As you can see, some lines are identical, same uid, same worker, same timestamp, etc…

I have the same issue on different machines and I tried both bro v.2.6.1 and latest zeek from github.

Does anyone have a clue about what is happening?

Thanks,

Mauro

2

Would it be possible to grab a pcap that recreates this behavior? Certainly not the correct behavior and it sounds like you've thought through the potential issues pretty thoroughly already and I agree with your thoughts. We might be at the point of just needing the PCAP to see what's causing it.

   .Seth

3

It turned out that there is an issue in our network and we are in fact getting duplicated dns packets on the span port...

So bro sees only one dns session in dns.log (and only one uid in conn.log), but the event dns_request is raised more than once and hence we get multiple intel matches.

Thanks and sorry for the false alarm...

Mauro

-----Messaggio originale-----

4

The usual case for this is that you are tapping the same traffic twice. If you look up the CP1BZx1QgzdPpfEyda connection in the conn.log and look at orig_pkts and resp_pkts you should see 1 and 1. If you see 2,2 or 2,1 then you are seeing duplicate packets.

justin@mbp:/tmp/b$ cat dns.log |bro-cut uid qtype_name query
Cu1Xq04w0nXaBiFiD A opencalphad.com
CJYuzY33KkZubxHXMc AAAA opencalphad.com
CdgXOb43ML2PJSv84a MX opencalphad.com
justin@mbp:/tmp/b$ cat conn.log |bro-cut uid orig_pkts resp_pkts |fgrep Cu1Xq04w0nXaBiFiD
Cu1Xq04w0nXaBiFiD 1 1

5

Hi Justin,

I am in fact seeing 2,2 or 2,0 as orig_pkts and resp_pkts. And I confirmed this with tcpdump. So I believe it is an issue with the network we are tapping as I see these duplicated packets only for dns.

Thnaks

Mauro

Inviato: giovedì 3 ottobre 2019 17:58

6

Possibly, but you may have duplicates everywhere. The tcp reassembler can use the sequence numbers to avoid analyzing the same traffic twice, but UDP doesn’t have anything like that. DNS is just the place you tend to notice the duplicate traffic the most.