[Bro] DNS query logging

[Jeremy Hoel]

I had only sent this to Liam.. not the list; and he responded, so that
helped.   So this is just an FYI.

Also, I just noticed the timestamps in the entries..

>From the example, the client request (1378939466.342201) happens
before the forwarding lookup (1378939466.342353) but gets written
after (since it's waiting for the results.  So, now that makes sense
why it logs the way it does.

Thanks!



On Thu, Sep 12, 2013 at 2:28 AM, Jeremy Hoel <jthoel at gmail.com> wrote:
> Liam - It's 2.1 from the stable tgz.  I can test the git also.  Is
> there a rough ETA for 2.2?
>
>
> Anthony - Running bro via broctl on the 189.225 server.   This is off
> live traffic, sniffing a span port that is from the 189.225 server.
> This is a basic fresh install with nothing special except for turning
> off the logs I don't want; so no extra scripts.  The 10.85.30.71 is a
> server that requests are forwarded to from the 189.225 server (a
> windows dc) and yes, all traffic in and out is on one same interface.
>
> And I guess the other odd part is that in the log, the source of the
> second log is the original requesting client.  I guess I expected to
> see this more like how tcpdump would show the output vs how the logs
> are recording it.  maybe the git will make more sense.  I'll test it
> out tomorrow.
>
> Thanks for the responses!
>
> On Wed, Sep 11, 2013 at 7:52 PM, Liam Randall <liam.randall at gigaco.com> wrote:
>> Hey Jeremy,
>>
>> Are you on Bro 2.1 or SecurityOnion?
>>
>> Upgrade to Git Master; there was a bug fixed already:
>>
>> https://bro-tracker.atlassian.net/browse/BIT-1064
>>
>> Thanks,
>>
>> Liam Randall
>>
>>
>> On Wed, Sep 11, 2013 at 6:53 PM, Jeremy Hoel <jthoel at gmail.com> wrote:
>>>
>>> So I'm testing out bro for a limited use on recording dns queries and
>>> responses.  I have the logs coming in and that's great, but I don't
>>> think I'm not seeing all the dns traffic.
>>>
>>> Example:
>>>
>>> via tcpdump with a BPF for just a client I get:
>>>
>>> 22:44:26.342201 IP 10.10.189.40.36221 > 10.10.189.225.53: 58059+ A?
>>> nike.com. (26)
>>> 22:44:26.412863 IP 10.10.189.225.53 > 10.10.189.40.36221: 58059 1/0/0
>>> A 66.54.56.30 (42)
>>>
>>> That makes sense.. request, and reply.
>>>
>>> Yet in the dns.log I see
>>>
>>> 1378939466.342353 10.10.189.225 64592 10.85.30.71 53 udp 11033
>>> nike.com 0 NOERROR F T T 66.54.56.30
>>> 1378939466.342201 10.10.189.40 36221 10.10.189.225 53 udp 58059
>>> nike.com 0 NOERROR F T T 66.54.56.30
>>>
>>> which shows the dns server talking to it's upstream server (expected)
>>> and then issues the answer to the client, but the original request
>>> isn't in the dns log.
>>>
>>> So assuming you get a response back from an upstream server, you can
>>> infer that the original requester was the second entry, but I was
>>> expecting to see an entry for the actual request to the 189.225
>>> server.
>>>
>>> Or am I not understanding something right?  I could probably look at
>>> the conn.log, but I am trying to just log the dns request, so I have
>>> conn.log turned off.
>>> _______________________________________________
>>> Bro mailing list
>>> bro at bro-ids.org
>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>
>>