Project

General

Profile

Optimization #2272

Analyze DNS response if query is not present

Added by Chris Knott over 2 years ago. Updated 4 months ago.

Status:
Assigned
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

A DNS event should be logged in the eve.json file if the DNS response is available in the packet stream only (meaning that the DNS query to the response is missing). At the moment DNS queries are always generating a DNS event entry. DNS responses are only generating an entry if the appropriate DNS query is present in the packet stream. This behavior is the same in the C and in the RUST implementation of the DNS plugin.
The test PCAP attached:
dns.pcap: 2 packets, a DNS query and the corresponding response; generating 2 DNS event entires in the eve.json file
dnsquery.pcap: Only the query contained in dns.pcap; generating 1 DNS even entry in the eve.json file
dnsresponse.pcap: Only the response contained in dns.pcap; generating 0 DNS event entries in the eve.json file (should generate 1 entry)


Files

dns.pcap (208 Bytes) dns.pcap Chris Knott, 11/16/2017 03:47 PM
dnsquery.pcap (108 Bytes) dnsquery.pcap Chris Knott, 11/16/2017 03:47 PM
dnsresponse.pcap (124 Bytes) dnsresponse.pcap Chris Knott, 11/16/2017 03:47 PM

Related issues

Related to Support #2309: SuriCon 2017 brainstormNew12/01/2017Victor JulienActions
Related to Task #2278: tracking: failing betterNewOISF DevActions
Related to Bug #2146: DNS answer not logged with eve-logClosedJason IshActions
Related to Support #3288: Suricon 2019 brainstormNewVictor JulienActions
Blocked by Feature #2572: extend protocol detection to specify flow directionClosedVictor JulienActions
#1

Updated by Andreas Herz about 2 years ago

  • Assignee set to Anonymous
  • Target version set to TBD

Is this something we should change or make it an config option?

#2

Updated by Chris Knott about 2 years ago

My suggestion would be that single sided DNS should work if, in the "stream" section of the configuration, "midstream" and/or "async-oneside" is "true". I was talking to Jason during Suricon ... he meant that the problem seems to be in stream/flow handling and not in the DNS plugin itself (the DNS plugin does not see the DNS packet if the DNS response is sent without the DNS query)

#3

Updated by Victor Julien about 2 years ago

The biggest problem is the protocol detection currently. A stream where we see only the reply side would not be properly detected.

#4

Updated by Victor Julien about 2 years ago

#5

Updated by Victor Julien almost 2 years ago

  • Related to Task #2278: tracking: failing better added
#6

Updated by Victor Julien over 1 year ago

  • Related to Bug #2146: DNS answer not logged with eve-log added
#7

Updated by Andreas Herz about 1 year ago

  • Assignee set to Community Ticket
#8

Updated by Victor Julien about 1 year ago

  • Blocked by Feature #2572: extend protocol detection to specify flow direction added
#9

Updated by Victor Julien about 1 year ago

  • Status changed from New to Assigned
  • Assignee changed from Community Ticket to Jason Ish

When protocol detection for midstream and async is improved, the dns parser should be updated/tested to handle this.

#10

Updated by Victor Julien 5 months ago

Protocol detection is now capable of picking up DNS midstream regardless of what direction it sees first. Logging handles this. I think detection will not. The dns.query keyword is only called for TS packets. Maybe it would be possible to create some kind of flag that indicates that on async a keyword needs to inspect the opposing direction as well.

#11

Updated by Jason Ish 4 months ago

Victor Julien wrote:

Protocol detection is now capable of picking up DNS midstream regardless of what direction it sees first. Logging handles this. I think detection will not. The dns.query keyword is only called for TS packets. Maybe it would be possible to create some kind of flag that indicates that on async a keyword needs to inspect the opposing direction as well.

I'm wondering if we can close this or not.

In general, this seems to be solved as long as mid-stream detection is one. The comment above appears to be about doing a dns.query match on the response, right? I think its by design that this match is only done on the request. So I guess this is only an issue if we have to flip the direction of a request. Would that be something we ever have to do?

#12

Updated by Victor Julien 4 months ago

So if we only see the response, and we pick it up midstream (fixing the direction while at it), do we take the query from the response and make dns.query match on it? Do we have a SV test for this?

#13

Updated by Jason Ish 4 months ago

Victor Julien wrote:

So if we only see the response, and we pick it up midstream (fixing the direction while at it), do we take the query from the response and make dns.query match on it? Do we have a SV test for this?

No we don't. I'm more wondering if we should or shouldn't.

Say its async traffic, the operator can see both sides, but Suricata can't. Then you would not want to look at the response as a request, as you would have looked at the request elsewhere already. While I'm not sure, I think sometimes single sided is more about where Suricata can be placed. Not that the operators only ever see one side.

Then of course there is the case of a lost request, or truly where one side is all the operator can see.

So I think this issue is closed. Analyzing the query in the response, when the request is absent is probably another issue.

#14

Updated by Victor Julien 4 months ago

Jason Ish wrote:

So I think this issue is closed. Analyzing the query in the response, when the request is absent is probably another issue.

I'm a bit confused by this statement. What would be the difference from this ticket?

#15

Updated by Victor Julien 4 months ago

Also available in: Atom PDF