Project

General

Profile

Actions
Copy link

Bug #6281

closed
JI JI

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

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

Added by Jason Ish over 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Jason Ish
Target version:
8.0.0-beta1
Affected Versions:
6.0.15, 7.0.2
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 6 (1 open — 5 closed)

Related to Suricata - Bug #6400: eve: log of DNS answer is in wrong direction ClosedJason IshActions
Related to Suricata - Bug #6458: eve/http: discrepancy in http events and http objects logged in alertsNewOISF DevActions
Related to Suricata - Feature #3952: protocols: implement mDNSClosedJason IshActions
Related to Suricata - Feature #7011: dns: additional section parsing and loggingClosedNathan ScrivensActions
Blocks Suricata - Feature #5773: doh: support DNS over HTTPS (DoH)ClosedPhilippe AntoineActions
Blocks Suricata - Feature #6621: dns: add keyword for dns rcode: dns.rcodeClosedHadiqa Alamdar BukhariActions

SS Updated by Sascha Steinbiss over 2 years ago Actions
Copy link
 #1

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.

JI Updated by Jason Ish over 2 years ago Actions
Copy link
 #2

  • 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.

PA Updated by Philippe Antoine over 2 years ago Actions
Copy link
 #3

JI Updated by Jason Ish over 2 years ago Actions
Copy link
 #4

  • Blocked by Feature #6496: dns: new detection buffer: dns.answer.name added
  • Blocked by Feature #6497: dns: new detection buffer: dns.query.name added

JI Updated by Jason Ish over 2 years ago Actions
Copy link
 #5

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

JI Updated by Jason Ish over 2 years ago Actions
Copy link
 #6

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

JI Updated by Jason Ish over 2 years ago Actions
Copy link
 #7

  • Affected Versions 6.0.15, 7.0.2 added

JI Updated by Jason Ish over 2 years ago Actions
Copy link
 #8

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

PA Updated by Philippe Antoine about 2 years ago Actions
Copy link
 #9

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

PA Updated by Philippe Antoine about 2 years ago Actions
Copy link
 #10

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

JI Updated by Jason Ish almost 2 years ago ยท Edited Actions
Copy link
 #11

For DNS requests we'll see the following breaking change:

Before

{
  "timestamp": "2024-06-04T10:55:27.082147-0600",
  "flow_id": 2041670771398517,
  "pcap_cnt": 1,
  "event_type": "dns",
  "src_ip": "10.16.1.11",
  "src_port": 42106,
  "dest_ip": "1.1.1.1",
  "dest_port": 53,
  "proto": "UDP",
  "pkt_src": "wire/pcap",
  "dns": {
    "type": "query",
    "id": 0,
    "rrname": "forum.suricata.io",
    "rrtype": "A",
    "tx_id": 0,
    "opcode": 0
  }
}

After

{
  "timestamp": "2024-06-04T10:55:27.082147-0600",
  "flow_id": 2041670948131806,
  "pcap_cnt": 1,
  "event_type": "dns",
  "src_ip": "10.16.1.11",
  "src_port": 42106,
  "dest_ip": "1.1.1.1",
  "dest_port": 53,
  "proto": "UDP",
  "pkt_src": "wire/pcap",
  "dns": {
    "type": "request",
    "id": 0,
    "flags": "100",
    "rd": true,
    "opcode": 0,
    "rcode": "NOERROR",
    "queries": [
      {
        "rrname": "forum.suricata.io",
        "rrtype": "A" 
      }
    ]
  }
}

Changes:
- The DNS request is now an object inside the dns.queries array instead of just fields inside the dns object.
- This is how DNS queries are logged in an alert record.
- I did change the name from query as used in the alert record to queries to better reflect what is logged here since we're already making a breaking change.
- As we're breaking things, may as well change type to request and response to better match the specification and other tools like Wireshark.

Notes:
- This could present challenges for those building reports on DNS fields, or correlating DNS queries with other records.

VJ Updated by Victor Julien almost 2 years ago Actions
Copy link
 #12

Does this mean we're doing a version:3 record type?

JI Updated by Jason Ish almost 2 years ago Actions
Copy link
 #13

Victor Julien wrote in #note-12:

Does this mean we're doing a version:3 record type?

I suppose we should. We're breaking DNS requests when logged as part of a DNS event. We're also breaking DNS responses when part of an alert. Since we're breaking both its probably a good time for any additional cleanups as well.

JI Updated by Jason Ish almost 2 years ago Actions
Copy link
 #14

Theres also #6400 which is another reason for a version bump as well.

JI Updated by Jason Ish almost 2 years ago Actions
Copy link
 #15

Draft PR addressing requests: https://github.com/OISF/suricata/pull/11238

JI Updated by Jason Ish almost 2 years ago Actions
Copy link
 #16

JI Updated by Jason Ish almost 2 years ago Actions
Copy link
 #17

  • Status changed from In Progress to In Review

JI Updated by Jason Ish almost 2 years ago Actions
Copy link
 #18

Ping @Eric Leblond, as we started to talking about this over #6400 I think.

JI Updated by Jason Ish almost 2 years ago Actions
Copy link
 #19

  • Related to Feature #7011: dns: additional section parsing and logging added

JI Updated by Jason Ish over 1 year ago Actions
Copy link
 #20

  • Status changed from In Review to Closed
Actions
Copy link

Also available in: PDF Atom