Bug #6400
openlog of DNS answer is in wrong direction
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.
Updated by Eric Leblond over 1 year ago
It seems to be the same with dnp3 protocol.
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.
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.
Updated by Eric Leblond over 1 year ago
Code is here: https://github.com/regit/suricata/tree/issue-6400
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.
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?
Updated by Eric Leblond over 1 year ago
Ticket open to address the IP/mac match https://redmine.openinfosecfoundation.org/issues/6405
Updated by Jason Ish over 1 year ago
- Related to Bug #6281: dns: structure of query differs between "alert" and "dns" event types added
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
Updated by Philippe Antoine over 1 year ago
- Related to Optimization #3827: output: clean up logging initialization code added
Updated by Philippe Antoine over 1 year ago
https://github.com/OISF/suricata/pull/9654 was a draft for this
Updated by Victor Julien over 1 year ago
- Target version changed from TBD to 8.0.0-beta1
Updated by Victor Julien over 1 year ago
- Related to Task #2167: tracking: eve enhancements added
Updated by Victor Julien 2 months ago
- Target version changed from 8.0.0-beta1 to 8.0.0-rc1
Updated by Philippe Antoine 17 days 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
?
Updated by Jason Ish 4 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);
usingLOG_DIR_FLOW
instead ofLOG_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.
Updated by Jason Ish 1 day 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);
usingLOG_DIR_FLOW
instead ofLOG_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.
Updated by Philippe Antoine about 17 hours ago
- Assignee changed from Eric Leblond to Jason Ish
@Jason Ish assiging to you as it is DNS, is it ok ?
Updated by Victor Julien about 15 hours ago
- Status changed from New to Assigned
- Priority changed from Normal to High
Updated by Jason Ish about 14 hours ago
- Status changed from Assigned to In Progress
Updated by Jason Ish about 12 hours ago
- Status changed from In Progress to In Review
Pull request: https://github.com/OISF/suricata/pull/13380