Project

General

Profile

Actions

Bug #1424

closed

DNS EVE-log produces answers with incorrect direction

Added by Antti Tönkyrä over 6 years ago. Updated almost 5 years ago.

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

Description

EVE-Log sometimes produces DNS answers with incorrect direction (the server appears to be the dest when it should actually be the source).

Reproduced using

while [ 1 ]; do host pingtimeout.net ns1.pingtimeout.net; sleep 0.1; done

I have also attached pcap that replicates the issue on my local git head suricata. Below is an example of the wrong output.

{
    "alerts": [],
    "data": {
        "dest_ip": "81.90.68.112",
        "dest_port": 53,
        "dns": {
            "id": 31443,
            "rdata": "81.90.68.114",
            "rrname": "pingtimeout.net",
            "rrtype": "A",
            "ttl": 3600,
            "type": "answer" 
        },
        "event_type": "dns",
        "flow_id": 37465680,
        "pcap_cnt": 49,
        "proto": "UDP",
        "src_ip": "10.100.0.20",
        "src_port": 47589,
        "timestamp": "2015-03-19T17:05:17.163591" 
    },
    "source": "suricata",
    "tags": []
}
{
    "alerts": [],
    "data": {
        "dest_ip": "81.90.68.112",
        "dest_port": 53,
        "dns": {
            "id": 52955,
            "rdata": "81.90.68.114",
            "rrname": "pingtimeout.net",
            "rrtype": "A",
            "ttl": 3600,
            "type": "answer" 
        },
        "event_type": "dns",
        "flow_id": 37467504,
        "pcap_cnt": 61,
        "proto": "UDP",
        "src_ip": "10.100.0.20",
        "src_port": 53278,
        "timestamp": "2015-03-19T17:05:17.454712" 
    },
    "source": "suricata",
    "tags": []
}

Files

suritest.pcap (9.15 KB) suritest.pcap Antti Tönkyrä, 03/19/2015 12:13 PM
Actions #1

Updated by Antti Tönkyrä over 6 years ago

Note that normal suricata eve-log input is encapsulated in data key in my example out.

Actions #2

Updated by Antti Tönkyrä over 6 years ago

And version info:
2.1dev (rev e250040)

Actions #3

Updated by Antti Tönkyrä over 6 years ago

Also happens with 60a4965

Actions #4

Updated by Victor Julien over 6 years ago

  • Status changed from New to Assigned
  • Assignee set to David Cannings
  • Target version set to 3.0RC1
Actions #5

Updated by David Cannings over 6 years ago

Confirmed in both live and pcap mode. Packet captures were taken from the same physical interface but not at the same time.

From the same pcap, here's two example sessions (one with vlan tags, one without):

{"timestamp":"2015-05-21T11:30:00.962978+0100","flow_id":22189344,"pcap_cnt":6031,"event_type":"dns","src_ip":"10.X.X.X","src_port":65077,"dest_ip":"10.Y.Y.Y","dest_port":53,"proto":"UDP","dns":{"type":"answer","id":7442,"rcode":"NXDOMAIN","rrname":"u.03.s.sophosxl.net","rrtype":"SOA","ttl":9}}
{"timestamp":"2015-05-21T11:30:01.467133+0100","flow_id":22312464,"pcap_cnt":6078,"event_type":"dns","vlan":1,"src_ip":"10.X.X.X","src_port":50545,"dest_ip":"10.Y.Y.Y","dest_port":53,"proto":"UDP","dns":{"type":"answer","id":53770,"rcode":"NOERROR","rrname":"iplayerhelp.external.bbc.co.uk","rrtype":"CNAME","ttl":1797,"rdata":"bbciplayer.metafaq.com"}}

From live capture:

{"timestamp":"2015-05-21T10:17:27.866919","flow_id":140034661246416,"in_iface":"eth2","event_type":"dns","vlan":1,"src_ip":"10.X.X.X","src_port":41341,"dest_ip":"10.Y.Y.Y","dest_port":53,"proto":"UDP","dns":{"type":"answer","id":20985}}
{"timestamp":"2015-05-21T10:17:27.867699","flow_id":140034661247088,"in_iface":"eth2","event_type":"dns","src_ip":"10.X.X.X","src_port":39122,"dest_ip":"10.Z.Z.Z","dest_port":53,"proto":"UDP","dns":{"type":"answer","id":20985}}

Note that there are also correct log entries, for example:

{"timestamp":"2015-05-21T10:15:18.195891","flow_id":140034664754368,"in_iface":"eth2","event_type":"dns","vlan":1,"src_ip":"10.X.X.X","src_port":53,"dest_ip":"10.Y.Y.Y","dest_port":50494,"proto":"UDP","dns":{"type":"answer","id":61479,"rrname":"internalnameredacted.local","rrtype":"A","ttl":0,"rdata":"10.Z.Z.Z"}}

The incorrect log entries greatly outnumber the correct ones in pcap mode. My sample is small and not statistically significant. The below is from a 1.2MB pcap:

-> % jq -c 'select(.dns.type=="answer") | select(.src_port==53)' eve.json | wc -l
3 # correct

-> % jq -c 'select(.dns.type=="answer") | select(.dest_port==53)' eve.json | wc -l
9897 # incorrect

And from the live capture:

-> % jq -c 'select(.dns.type=="answer") | select(.src_port==53)' dns.log | wc -l
4149 # correct

-> % jq -c 'select(.dns.type=="answer") | select(.dest_port==53)' dns.log | wc -l
1164 # incorrect

Live capture used 2.1beta2, pcap used 2.1dev (rev 0e2a4c0).

Actions #6

Updated by Victor Julien almost 6 years ago

  • Target version changed from 3.0RC1 to 70
Actions #7

Updated by Jason Ish almost 5 years ago

I propose we close this. I confirmed that I could replicate it with rev 0e2a4c0, but I am not able to replicate with 3.2RC1.

Appears it was fixed by this commit 133485937952d8ed106eae840f517edf53024e19 (though I'm not sure why...)

Actions #8

Updated by Victor Julien almost 5 years ago

That commit shouldn't affect it, how did you determine that?

Actions #9

Updated by Jason Ish almost 5 years ago

You're right. I limited my back testing to commits on the dns files, it could have been in another commit leading up to that one. I'll re-check.

Actions #10

Updated by Victor Julien almost 5 years ago

Maybe a git bisect could be useful. It can be automated if you have a test case that returns good/bad.

Actions #12

Updated by Victor Julien almost 5 years ago

  • Status changed from Assigned to Closed
  • Assignee changed from David Cannings to Victor Julien
  • Target version deleted (70)

Guess I fixed it then ;)

Actions

Also available in: Atom PDF