Suricata

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)

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

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.

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?

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?

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.

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?

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.

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.

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