Feature #5784
closeddetect: allow cross buffer inspection on multi-buffer matches
Description
Cf calls to InspectionBufferSetupMulti to have the keywords which use multibuffer
If I have the rules
alert mqtt any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; mqtt.subscribe.topic; content:"topicX"; mqtt.subscribe.topic; content:"topicY"; sid:5;) alert mqtt any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; mqtt.subscribe.topic; content:"topicY"; sid:6;) alert mqtt any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; mqtt.subscribe.topic; content:"topicX"; sid:7;)
And run them on S-V test mqtt-sub-rules/mqtt5_sub_userpass.pcap
I get alerts for sid 6 and 7 on the same packet and transaction, but not for sid 5
In this pcap, there is a MQTT subscribe for these two different topics : topicX and topicY
But there is no topic which contain both content topicX and topicY at the same time
There is no such feature in the detection engine to have "multiple buffer" keywords have different contents for different buffers (and still have the ability to have multiple content for only one buffer)
The different contents for a unique sm_list (value can be g_http2_header_buffer_id) are aggregated in a single SigMatchData linked list
Victor, assigning to you as this requires deep design
Updated by Philippe Antoine almost 2 years ago
- Related to Bug #5780: HTTP/2 - FN when matching on multiple http2.header contents added
Updated by Victor Julien over 1 year ago
I think the fundamental issue is that when parsing a rule, the following statements are considered identical by Suricata:
dns.query; content:"abc"; content:"xyz"; dns.query; content:"abc"; dns.query; content:"xyz";
This leads to a "detection list" with 2 matches. The sig only matches if both match in the same buffer. Each DNS query is its own buffer, even if multiple queries are part of a single packet.
The expectation of rule writers seems to be that if the dns.query keyword is used multiple times, it "breaks" the list into 2. If a packet has a query containing "abc" and another query containing "xyz", the sig should match.
This same concept applies to all detection using the same "multi inspect buffer" logic, like certain http/2 keywords, mqtt keywords, etc.
Updated by Victor Julien over 1 year ago
- Subject changed from Have multi buffer be able to match on different content for different InspectionBuffer to detect: allow cross buffer inspection on multi-buffer matches
Updated by Victor Julien over 1 year ago
- Status changed from New to In Progress
- Target version changed from TBD to 7.0.0-rc2
I'm looking into this, but it seems the changes will be too intrusive and high risk for backporting. We'll have to make the final call when this work is done for master.
Updated by Philippe Antoine over 1 year ago
Victor Julien wrote in #note-2:
I think the fundamental issue is that when parsing a rule, the following statements are considered identical by Suricata:
I agree :-)
This leads to a "detection list" with 2 matches. The sig only matches if both match in the same buffer. Each DNS query is its own buffer, even if multiple queries are part of a single packet.
The expectation of rule writers seems to be that if the
dns.querykeyword is used multiple times, it "breaks" the list into 2. If a packet has a query containing "abc" and another query containing "xyz", the sig should match.This same concept applies to all detection using the same "multi inspect buffer" logic, like certain http/2 keywords, mqtt keywords, etc.
Thanks for taking on this :-)
Good to see a new feature for a more expressive signature language ;-)
Updated by Victor Julien over 1 year ago
- Status changed from In Progress to In Review
Updated by Victor Julien over 1 year ago
- Status changed from In Review to Closed
Updated by Philippe Antoine over 1 year ago
Still needs to be documented, right ?
cc @Juliana Fajardini Reichow
Updated by Victor Julien over 1 year ago
- Related to Documentation #6032: detect: document new multi-instance logic added