Project

General

Profile

Actions

Bug #6400

closed
EL JI

eve: log of DNS answer is in wrong direction

Bug #6400: eve: log of DNS answer is in wrong direction

Added by Eric Leblond over 2 years ago. Updated 10 months ago.

Status:
Closed
Priority:
High
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

I think we did already discuss this issue but I can still not understand this. In DNS request and answer the source and destination IP are the same. This does not appear to be logic as we are facing communication in opposite direction.

For example, on a pcap replay we have:

{
  "timestamp": "2019-07-05T22:10:33.164698+0200",
  "flow_id": 425900207853173,
  "pcap_cnt": 48630,
  "event_type": "dns",
  "src_ip": "10.7.5.101",
  "src_port": 50643,
  "dest_ip": "10.7.5.5",
  "dest_port": 53,
  "proto": "UDP",
  "pkt_src": "wire/pcap",
  "ether": {
    "src_mac": "00:08:02:1c:47:ae",
    "dest_mac": "a4:1f:72:c2:09:6a" 
  },
  "community_id": "1:kTeBZP87R9S9OU6Vd9RX0LnViA8=",
  "dns": {
    "type": "query",
    "id": 62832,
    "rrname": "germakhya.xyz",
    "rrtype": "A",
    "tx_id": 0,
    "opcode": 0
  }
}
{
  "timestamp": "2019-07-05T22:10:33.369515+0200",
  "flow_id": 425900207853173,
  "pcap_cnt": 48631,
  "event_type": "dns",
  "src_ip": "10.7.5.101",
  "src_port": 50643,
  "dest_ip": "10.7.5.5",
  "dest_port": 53,
  "proto": "UDP",
  "pkt_src": "wire/pcap",
  "ether": {
    "src_mac": "a4:1f:72:c2:09:6a",
    "dest_mac": "00:08:02:1c:47:ae" 
  },
  "community_id": "1:kTeBZP87R9S9OU6Vd9RX0LnViA8=",
  "dns": {
    "version": 2,
    "type": "answer",
    "id": 62832,
    "flags": "8180",
    "qr": true,
    "rd": true,
    "ra": true,
    "opcode": 0,
    "rrname": "germakhya.xyz",
    "rrtype": "A",
    "rcode": "NOERROR",
    "answers": [
      {
        "rrname": "germakhya.xyz",
        "rrtype": "A",
        "ttl": 599,
        "rdata": "95.142.46.236" 
      }
    ],
    "grouped": {
      "A": [
        "95.142.46.236" 
      ]
    }
  }
}

And if you look at the ethernet address you can see that they are reverted between the request and the answer. This is not making sense at all.


Related issues 3 (1 open2 closed)

Related to Suricata - Bug #6281: dns: structure of query differs between "alert" and "dns" event typesClosedJason IshActions
Related to Suricata - Optimization #3827: output: clean up logging initialization codeClosedPhilippe AntoineActions
Related to Suricata - Task #2167: tracking: eve enhancementsNewOISF DevActions

EL Updated by Eric Leblond over 2 years ago Actions #1

It seems to be the same with dnp3 protocol.

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

I think this is due to the original DNS implementation doing this as well. While it did log requests and replies as separate records, it did so only after completing the transaction, so all were logged with the flow originator as the source. DNP3 also followed this convention. It looks like MQTT may have broke away from this convention?

At one time I did try to change it, but it wasn't consistent with IPS vs IDS modes.

But it would be good to get some uniform convention here:
- If log record is a correlation of the request and response (ie: HTTP) use the flow origination as the src IP
- If the log record is a message, respect the packet direction

This would be a breaking change, so maybe for 8.0. And we should make sure its a sweeping change so everything matches that convention.

EL Updated by Eric Leblond over 2 years ago Actions #3

Fully agree with you on the definition of direction we should move to.

This would be a breaking change, so maybe for 8.0. And we should make sure its a sweeping change so everything matches that convention.

I've worked on a code that uses a version tag (per protocol) so we can introduce it in a non breaking way. I'm wondering if it should not be done at the eve level so we have one single flag to set.

EL Updated by Eric Leblond over 2 years ago Actions #5

I'm wondering if we should fix the ethernet address logging in 7 as minimal change as this one is completely wrong.

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

Eric Leblond wrote in #note-5:

I'm wondering if we should fix the ethernet address logging in 7 as minimal change as this one is completely wrong.

If wrong, and not just an odd convention like the DNS, then yes it should probably be fixed. Can you create a new ticket?

EL Updated by Eric Leblond over 2 years ago Actions #7

Ticket open to address the IP/mac match https://redmine.openinfosecfoundation.org/issues/6405

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

  • Related to Bug #6281: dns: structure of query differs between "alert" and "dns" event types added

PA Updated by Philippe Antoine over 2 years ago Actions #9

But it would be good to get some uniform convention here:
- If log record is a correlation of the request and response (ie: HTTP) use the flow origination as the src IP
- If the log record is a message, respect the packet direction

For information, this is fixed for SSH by https://github.com/OISF/suricata/pull/9870

PA Updated by Philippe Antoine over 2 years ago Actions #10

VJ Updated by Victor Julien about 2 years ago Actions #12

  • Target version changed from TBD to 8.0.0-beta1

VJ Updated by Victor Julien about 2 years ago Actions #13

  • Related to Task #2167: tracking: eve enhancements added

VJ Updated by Victor Julien about 1 year ago Actions #14

  • Target version changed from 8.0.0-beta1 to 8.0.0-rc1

PA Updated by Philippe Antoine 11 months ago Actions #15

jish is this about @SCJsonBuilder *jb = CreateEveHeader(p, LOG_DIR_FLOW, "dns", NULL, dnslog_ctx->eve_ctx); using LOG_DIR_FLOW instead of LOG_DIR_PACKET ?

JI Updated by Jason Ish 10 months ago Actions #16

Philippe Antoine wrote in #note-15:

jish is this about @SCJsonBuilder *jb = CreateEveHeader(p, LOG_DIR_FLOW, "dns", NULL, dnslog_ctx->eve_ctx); using LOG_DIR_FLOW instead of LOG_DIR_PACKET ?

Technicaly yes, but its log this way intentionally. So this is more about whether we should be making the switch and deal with the breaking changes involved to end users.

JI Updated by Jason Ish 10 months ago Actions #17

IPS

Jason Ish wrote in #note-16:

Philippe Antoine wrote in #note-15:

jish is this about @SCJsonBuilder *jb = CreateEveHeader(p, LOG_DIR_FLOW, "dns", NULL, dnslog_ctx->eve_ctx); using LOG_DIR_FLOW instead of LOG_DIR_PACKET ?

Technicaly yes, but its log this way intentionally. So this is more about whether we should be making the switch and deal with the breaking changes involved to end users.

Correction, its not that simple. For UDP DNS is work, but for TCP DNS it works, the addresses are swapped as its the ack packet flushing things through.

PA Updated by Philippe Antoine 10 months ago Actions #18

  • Assignee changed from Eric Leblond to Jason Ish

@Jason Ish assiging to you as it is DNS, is it ok ?

VJ Updated by Victor Julien 10 months ago Actions #19

  • Status changed from New to Assigned
  • Priority changed from Normal to High

JI Updated by Jason Ish 10 months ago Actions #20

  • Status changed from Assigned to In Progress

JI Updated by Jason Ish 10 months ago Actions #21

  • Status changed from In Progress to In Review

PA Updated by Philippe Antoine 10 months ago Actions #22

  • Status changed from In Review to Resolved

JI Updated by Jason Ish 10 months ago Actions #23

  • Status changed from Resolved to Closed

VJ Updated by Victor Julien 10 months ago Actions #24

  • Subject changed from log of DNS answer is in wrong direction to eve: log of DNS answer is in wrong direction
Actions

Also available in: PDF Atom