Project

General

Profile

Actions

Bug #6281

open

dns: structure of query differs between "alert" and "dns" event types

Added by Jason Ish 8 months ago. Updated 5 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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.


Related issues 4 (4 open0 closed)

Related to Suricata - Bug #6400: log of DNS answer is in wrong direction NewEric LeblondActions
Related to Suricata - Bug #6458: eve/http: discrepancy in http events and http objects logged in alertsNewOISF DevActions
Blocks Suricata - Feature #5773: Support DNS over HTTPS (DoH)In ReviewPhilippe AntoineActions
Blocks Suricata - Feature #6621: dns: add keyword for dns rcode: dns.rcodeResolvedHadiqa Alamdar BukhariActions
Actions #1

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.

Actions #2

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.

Actions #3

Updated by Philippe Antoine 5 months ago

Actions #4

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
Actions #5

Updated by Jason Ish 5 months ago

  • Blocked by deleted (Feature #6497: dns: new detection buffer: dns.query.name)
Actions #6

Updated by Jason Ish 5 months ago

  • Blocked by deleted (Feature #6496: dns: new detection buffer: dns.answer.name)
Actions #7

Updated by Jason Ish 5 months ago

  • Affected Versions 6.0.15, 7.0.2 added
Actions #8

Updated by Jason Ish 4 months ago

  • Related to Bug #6400: log of DNS answer is in wrong direction added
Actions #9

Updated by Philippe Antoine 4 months ago

  • Related to Bug #6458: eve/http: discrepancy in http events and http objects logged in alerts added
Actions #10

Updated by Philippe Antoine 4 months ago

  • Blocks Feature #6621: dns: add keyword for dns rcode: dns.rcode added
Actions

Also available in: Atom PDF