Bug #6281
opendns: structure of query differs between "alert" and "dns" event types
Description
In DNS query records, the dns
object is a flat object representing the request. Even though a DNS request could contain multiple queries this is not seen in practice, which is probably the reason for the easier-to-use flat object.
Note: DNS responses do place all the responses in an answers array as multiple answers to a single query are normal.
In alerts for DNS, the query
is (more correctly) placed in a query
array.
For example, a DNS event request:
"dns": { "type": "query", "id": 55380, "rrname": "google.de", "rrtype": "AAAA", "tx_id": 0, "opcode": 0 }
The DNS metadata in an alert:
"dns": { "query": [ { "type": "query", "id": 55380, "rrname": "google.de", "rrtype": "AAAA", "tx_id": 0, "opcode": 0 } ] },
And a DNS record for an answer:
dns: { answers: [ { rdata: "35.212.0.44", rrname: "suricata.io", rrtype: "A", ttl: 600 } ],
The question is how to resolve this going further. The DNS record type for requests looks clearly wrong, but I think there was some conscious decision to do that for the sake SIEMs, and changing that would probably break reports and other post-processing of the data.
Updated by Sascha Steinbiss 8 months ago
FWIW, in the case for the answers in the alerts the format appears to be identical to the "detailed" one in the DNS metadata events. So it really appears to be just a question of the queries.
Updated by Jason Ish 6 months ago
- Status changed from New to In Progress
- Assignee changed from OISF Dev to Jason Ish
- Target version changed from TBD to 8.0.0-beta1
Here's an alert on a DNS response. It is not in an array. If I had to guess, there was just a mix up during implementation and queries were put in an array when it was meant to put responses in the array:
{ "timestamp": "2023-10-24T22:14:56.664417+0000", "flow_id": 100796292290581, "pcap_cnt": 2, "event_type": "alert", "src_ip": "8.8.8.8", "src_port": 53, "dest_ip": "10.16.1.11", "dest_port": 34435, "proto": "UDP", "pkt_src": "wire/pcap", "tx_id": 1, "alert": { "action": "allowed", "gid": 1, "signature_id": 1, "rev": 1, "signature": "DNS TEST response answer name", "category": "", "severity": 3 }, "dns": { "answer": { "version": 2, "type": "answer", "id": 49971, "flags": "8180", "qr": true, "rd": true, "ra": true, "opcode": 0, "rrname": "suricata.io", "rrtype": "A", "rcode": "NOERROR" } }, "app_proto": "dns", "direction": "to_client" }
Given this is a bug that can result in loss of fidelity I'd like to consider it backport worthy, at least to 7.0.
Updated by Philippe Antoine 5 months ago
- Blocks Feature #5773: Support DNS over HTTPS (DoH) added
Updated by Jason Ish 5 months ago
- Blocked by Feature #6496: dns: new detection buffer: dns.answer.name added
- Blocked by Feature #6497: dns: new detection buffer: dns.query.name added
Updated by Jason Ish 5 months ago
- Blocked by deleted (Feature #6497: dns: new detection buffer: dns.query.name)
Updated by Jason Ish 5 months ago
- Blocked by deleted (Feature #6496: dns: new detection buffer: dns.answer.name)
Updated by Philippe Antoine 4 months ago
- Related to Bug #6458: eve/http: discrepancy in http events and http objects logged in alerts added
Updated by Philippe Antoine 4 months ago
- Blocks Feature #6621: dns: add keyword for dns rcode: dns.rcode added