Project

General

Profile

Actions
Copy link

Bug #6400

open

log of DNS answer is in wrong direction

Added by Eric Leblond about 1 year ago. Updated 11 months ago.

Status:
New
Priority:
Normal
Assignee:
Eric Leblond
Target version:
8.0.0-beta1
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: clean up logging initialization codeClosedPhilippe AntoineActions
Related to Suricata - Task #2167: tracking: eve enhancementsNewOISF DevActions
Actions
Copy link
 #1

Updated by Eric Leblond about 1 year ago

It seems to be the same with dnp3 protocol.

Actions
Copy link
 #2

Updated by Jason Ish about 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 about 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 about 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 about 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 about 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 almost 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 12 months 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 12 months ago

Actions
Copy link
 #12

Updated by Victor Julien 11 months ago

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

Updated by Victor Julien 11 months ago

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

Also available in: Atom PDF