Project

General

Profile

Actions

Optimization #2272

open

Analyze DNS response if query is not present

Added by Chris Knott over 6 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 7 (4 open3 closed)

Related to Suricata - Task #2309: SuriCon 2017 brainstormAssignedVictor JulienActions
Related to Suricata - Task #2278: tracking: failing betterNewOISF DevActions
Related to Suricata - Bug #2146: DNS answer not logged with eve-logClosedJason IshActions
Related to Suricata - Task #3288: Suricon 2019 brainstormAssignedVictor JulienActions
Related to Suricata - Bug #4135: dns: response only udp not detected as dnsAssignedJason IshActions
Related to Suricata - Feature #6497: dns: new detection buffer: dns.query.nameClosedJason IshActions
Blocked by Suricata - Feature #2572: extend protocol detection to specify flow directionClosedVictor JulienActions
Actions #1

Updated by Andreas Herz over 6 years ago

  • Assignee set to Anonymous
  • Target version set to TBD

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

Actions #2

Updated by Chris Knott over 6 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)

Actions #3

Updated by Victor Julien over 6 years ago

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

Actions #4

Updated by Victor Julien over 6 years ago

  • Related to Task #2309: SuriCon 2017 brainstorm added
Actions #5

Updated by Victor Julien almost 6 years ago

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

Updated by Victor Julien over 5 years ago

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

Updated by Andreas Herz about 5 years ago

  • Assignee set to Community Ticket
Actions #8

Updated by Victor Julien about 5 years ago

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

Updated by Victor Julien about 5 years 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.

Actions #10

Updated by Victor Julien over 4 years 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.

Actions #11

Updated by Jason Ish over 4 years 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?

Actions #12

Updated by Victor Julien over 4 years 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?

Actions #13

Updated by Jason Ish over 4 years 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.

Actions #14

Updated by Victor Julien over 4 years 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?

Actions #15

Updated by Victor Julien over 4 years ago

  • Related to Task #3288: Suricon 2019 brainstorm added
Actions #16

Updated by Jason Ish over 3 years ago

The initial problem with analyzing the response if they query wasn't present is that DNS is stateless, and doesn't map responses to requests, so the trivial implementation would result in an alert being logged for the request and the response.

With the addition of conditional logging, we now have a lightweight mechanism to map responses to requests that we could probably leverage to do this in a nice way.

Actions #17

Updated by Jason Ish over 3 years ago

  • Target version changed from TBD to 7.0.0-beta1
Actions #18

Updated by Victor Julien over 3 years ago

  • Related to Bug #4135: dns: response only udp not detected as dns added
Actions #19

Updated by Jason Ish over 3 years ago

Some generic way to die together "unidirectional" decoding of "messages" to a higher level transaction that is the combination of request/response would make this easier. Lightly discussed at the 2020 Brainstorm.

Actions #20

Updated by Victor Julien over 2 years ago

  • Target version changed from 7.0.0-beta1 to 8.0.0-beta1
Actions #21

Updated by Jason Ish 4 months ago

  • Related to Feature #6497: dns: new detection buffer: dns.query.name added
Actions #22

Updated by Jason Ish 4 months ago

I propose we reject this issue as extending dns.query_name to run on responses could lead to many unintended alerts. Instead I'm suggesting a new keyword, dns.query.name that is bidirectional: #6497

Actions

Also available in: Atom PDF