Project

General

Profile

Actions
Copy link

Bug #6400

closed

eve: log of DNS answer is in wrong direction

Added by Eric Leblond over 1 year ago. Updated 18 days ago.

Status:
Closed
Priority:
High
Assignee:
Jason Ish
Target version:
8.0.0-rc1
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 open — 2 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
Actions
Copy link
 #1

Updated by Eric Leblond over 1 year ago

It seems to be the same with dnp3 protocol.

Actions
Copy link
 #2

Updated by Jason Ish over 1 year ago

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.

Actions
Copy link
 #3

Updated by Eric Leblond over 1 year ago

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.

Actions
Copy link
 #5

Updated by Eric Leblond over 1 year ago

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

Actions
Copy link
 #6

Updated by Jason Ish over 1 year ago

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?

Actions
Copy link
 #7

Updated by Eric Leblond over 1 year ago

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

Actions
Copy link
 #8

Updated by Jason Ish over 1 year ago

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

Updated by Philippe Antoine over 1 year ago

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

Actions
Copy link
 #10

Updated by Philippe Antoine over 1 year ago

Actions
Copy link
 #12

Updated by Victor Julien over 1 year ago

  • Target version changed from TBD to 8.0.0-beta1
Actions
Copy link
 #13

Updated by Victor Julien over 1 year ago

  • Related to Task #2167: tracking: eve enhancements added
Actions
Copy link
 #14

Updated by Victor Julien 3 months ago

  • Target version changed from 8.0.0-beta1 to 8.0.0-rc1
Actions
Copy link
 #15

Updated by Philippe Antoine about 1 month ago

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 ?

Actions
Copy link
 #16

Updated by Jason Ish 28 days ago

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.

Actions
Copy link
 #17

Updated by Jason Ish 26 days ago

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.

Actions
Copy link
 #18

Updated by Philippe Antoine 25 days ago

  • Assignee changed from Eric Leblond to Jason Ish

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

Actions
Copy link
 #19

Updated by Victor Julien 25 days ago

  • Status changed from New to Assigned
  • Priority changed from Normal to High
Actions
Copy link
 #20

Updated by Jason Ish 25 days ago

  • Status changed from Assigned to In Progress
Actions
Copy link
 #21

Updated by Jason Ish 25 days ago

  • Status changed from In Progress to In Review
Actions
Copy link
 #22

Updated by Philippe Antoine 20 days ago

  • Status changed from In Review to Resolved
Actions
Copy link
 #23

Updated by Jason Ish 20 days ago

  • Status changed from Resolved to Closed
Actions
Copy link
 #24

Updated by Victor Julien 18 days ago

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

Also available in: Atom PDF