Bug #3354
closedeve-log dns (possibly others) alerts miss metadata for all but first packet
Description
It looks like eve-log alerts are slightly broken/miss metadata for DNS (might affect other protocols too).
I think it is caused by PacketAlertAppend(det_ctx, s, p, 0, alert_flags) call in DetectRulePacketRules which has argument of txid=0 to the appended alert. In my tests it seems to cause the effect that first DNS packet (query) has metadata on alert but response does not.
Ruleset I am using is simply:
alert dns any any -> any any (msg: "test"; sid: 1;)
And the produced EVE-json is
{ "timestamp": "2019-11-18T14:22:35.840789+0200", "flow_id": 1847130361418837, "pcap_cnt": 1, "event_type": "alert", "src_ip": "100.70.16.62", "src_port": 50073, "dest_ip": "1.0.0.1", "dest_port": 53, "proto": "UDP", "alert": { "action": "allowed", "gid": 1, "signature_id": 1, "rev": 0, "signature": "test", "category": "", "severity": 3 }, "dns": { "query": [ { "type": "query", "id": 12920, "rrname": "b.fi", "rrtype": "A", "tx_id": 0 } ] }, "app_proto": "dns", "flow": { "pkts_toserver": 1, "pkts_toclient": 0, "bytes_toserver": 64, "bytes_toclient": 0, "start": "2019-11-18T14:22:35.840789+0200" }, "payload": "MngBAAABAAAAAAAAAWICZmkAAAEAAQ==", "stream": 0 } { "timestamp": "2019-11-18T14:22:35.856384+0200", "flow_id": 1847130361418837, "pcap_cnt": 2, "event_type": "alert", "src_ip": "1.0.0.1", "src_port": 53, "dest_ip": "100.70.16.62", "dest_port": 50073, "proto": "UDP", "alert": { "action": "allowed", "gid": 1, "signature_id": 1, "rev": 0, "signature": "test", "category": "", "severity": 3 }, "app_proto": "dns", "flow": { "pkts_toserver": 1, "pkts_toclient": 1, "bytes_toserver": 64, "bytes_toclient": 80, "start": "2019-11-18T14:22:35.840789+0200" }, "payload": "MniBgAABAAEAAAAAAWICZmkAAAEAAcAMAAEAAQAAJF4ABMKSaho=", "stream": 0 }
Files
Updated by Andreas Herz about 5 years ago
- Assignee set to OISF Dev
- Target version set to TBD
Updated by Victor Julien about 5 years ago
- Status changed from New to Feedback
- Assignee changed from OISF Dev to Antti Tönkyrä
Can you submit a Suricata-Verify test for this case?
Updated by Antti Tönkyrä about 5 years ago
Updated by Antti Tönkyrä about 5 years ago
- File flowtx.patch flowtx.patch added
I'm not sure if the correct fix would be to add looking up TX like we do in stateless sigs at https://github.com/OISF/suricata/blob/3887f8d1f3d2816b3f46fb48560f9de57ae66314/src/detect.c#L1292
to https://github.com/OISF/suricata/blob/3887f8d1f3d2816b3f46fb48560f9de57ae66314/src/detect.c#L807
The necessary information to call the function GetDetectTx to obtain the correct TX seems to be there and I made a quick hack which seemed to fix the issue (patch as attachment). I wonder if this is the correct way to fix the issue? If so I can do a PR with some cleanup done.
Updated by Victor Julien about 4 years ago
- Target version changed from TBD to 6.0.2
Updated by Victor Julien almost 4 years ago
- Target version changed from 6.0.2 to 7.0.0-beta1
Updated by Philippe Antoine over 3 years ago
- Status changed from Feedback to In Review
- Affected Versions 6.0.2 added
- Affected Versions deleted (
5.0.0)
Updated by Philippe Antoine over 3 years ago
Antti, these alerts do not happen in transaction, but in packets, so we cannot know for sure which transaction we should log...
Do you want to add dns keywords to this signature to match on a transaction ? cf https://suricata.readthedocs.io/en/suricata-6.0.0/rules/dns-keywords.html
Updated by Philippe Antoine over 3 years ago
- Status changed from In Review to Feedback
Updated by Philippe Antoine over 3 years ago
- Target version changed from 7.0.0-beta1 to TBD
Updated by Antti Tönkyrä over 1 year ago
- Assignee changed from Antti Tönkyrä to Philippe Antoine
I think based on the discussion in the verify PR and related issue we can close this one for now. Sorry for not getting back to you sooner.
Updated by Philippe Antoine over 1 year ago
- Status changed from Feedback to Closed
Thanks for getting back