Please include the following information with your help request:
Suricata version : 8.0.0
Operating system and/or Linux distribution : WSL2.0 , ubuntu 22.04
How you installed Suricata : from source
I have recently been testing a Network Intrusion Detection System (NIDS) and have used both Snort3 and Suricata to test the same HTTP network traffic. These packets were generated based on the official Snort rule set. However, after testing, I found that the same packet can trigger an alert in Snort3, but not in Suricata.
For example, the following rule exists in the official Snort2 rule set (snort2-browser-plugins.rules):
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"BROWSER-PLUGINS Microsoft Windows Image Acquisition Logger ActiveX clsid access"; flow:to_client,established; file_data; content:"A1E75357-881A-419E-83E2-BB16DB197C68"; fast_pattern:only; pcre:"/(<object\s*[^>]\sid\s*=\s*(?P<m1>\x22|\x27|)(?P<id1>.+?)(?P=m1)(\s|>)[^>]\sclassid\s*=\s*(?P<q1>\x22|\x27|)\sclsid\s\x3a\s*{?\sA1E75357-881A-419E-83E2-BB16DB197C68\s}?\s*(?P=q1)(\s|>).(?P=id1)\s.\s*(Save)|<object\s*[^>]\sclassid\s*=\s*(?P<q2>\x22|\x27|)\sclsid\s\x3a\s*{?\sA1E75357-881A-419E-83E2-BB16DB197C68\s}?\s*(?P=q2)(\s|>)[^>]\sid\s*=\s*(?P<m2>\x22|\x27|)(?P<id2>.+?)(?P=m2)(\s|>).(?P=id2).(Save))\s(/Osi"; metadata:policy max-detect-ips drop, service http; reference:bugtraq,31069; reference:cve,2008-3957; classtype:attempted-user; sid:14266; rev:12;)
The HTTP packet that should trigger these two alerts is:
GET /connecttest.txt HTTP/1.1
Connection: Close
User-Agent: Microsoft NCSI
Host: www.msftconnecttest.com
Content-Type: text
Content-Length: 227
<object
bPREYRU^2
id= fn+6e)*NE_B
classid =
clsid:
A1E75357-881A-419E-83E2-BB16DB197C68
}
<T;HBS:1FgQdW'C_fn+6e)*NE_B . \x53\x61\x76\x65
When using this HTTP packet for testing, I found that Snort3 can trigger the alert normally, but Snort2 cannot. Snort2 is using the default configuration.
I would like to ask if this is due to a problem with my environment setup, or if there are other reasons for this situations?
I appreciate you taking the time reading this topic . Please let me know if you have any insights or suggestions regarding the issue I’m facing with the Snort2 rule not being triggered. I sincerely appreciate any comments and I’m willing to provide more detailed informations if you need.
Is your question about Suricata alerting or not with Snort 2 and 3 rules?
When using this HTTP packet for testing, I found that Snort3 can trigger the alert normally, but Snort2 cannot
Or, are you asking a question about Snort 2 vs Snort 3?
THX for replying. I used snort2 rules for suricata and snort3 rules for snort3 software itself , which means that i set snort3 as an control condition. So the problem is that some http packets can be triggered by snort3 but not by suricata, and I was wandering that why this happened. Sorry that i haven’t explained clearly before.
i am so sorry that it seems i uploaded a wrong rule. The correct rule could be successfully loaded by suricata. And here is the correct one.
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"BROWSER-PLUGINS Microsoft Windows Image Acquisition Logger ActiveX clsid access"; flow:to_client,established; file_data; content:"A1E75357-881A-419E-83E2-BB16DB197C68"; fast_pattern:only; pcre:"/(<object\s*[^>]*\s*id\s*=\s*(?P<m1>\x22|\x27|)(?P<id1>.+?)(?P=m1)(\s|>)[^>]*\s*classid\s*=\s*(?P<q1>\x22|\x27|)\s*clsid\s*\x3a\s*{?\s*A1E75357-881A-419E-83E2-BB16DB197C68\s*}?\s*(?P=q1)(\s|>).*(?P=id1)\s*\.\s*(Save)|<object\s*[^>]*\s*classid\s*=\s*(?P<q2>\x22|\x27|)\s*clsid\s*\x3a\s*{?\s*A1E75357-881A-419E-83E2-BB16DB197C68\s*}?\s*(?P=q2)(\s|>)[^>]*\s*id\s*=\s*(?P<m2>\x22|\x27|)(?P<id2>.+?)(?P=m2)(\s|>).*(?P=id2)\.(Save))\s*\(/Osi"; metadata:policy max-detect-ips drop, service http; reference:bugtraq,31069; reference:cve,2008-3957; classtype:attempted-user; sid:14266; rev:12;)
This one could be loaded by suricata successfully, but still cannot trigger the alarm of the packet.
Notice: suricata: This is Suricata version 8.0.0-dev running in SYSTEM mode [LogVersion:suricata.c:1156]
Notice: suricata: Configuration provided was successfully loaded. Exiting. [SuricataInit:suricata.c:2966]
i don’t have a pcap that triggers the snort2 system. Like i said, the packet triggered the snort3 system but not triggered the snort2, and i had made some packet manually intend to triggered the snort2 rule but none of them succeed. These 2 days I am trying to use gdb to debug suricata but failed to find significant problems. I will try to build more simple packets to see if it could trigger the rule. And i will tell you if i have any new discovery.
Happy New Year! Sry to bother you in your holiday. I believe I may have identified the cause of this issue: there seems to be a potential problem with the rule’s matching logic for whitespace characters. To test this, I constructed two simple packets designed to trigger the rule. The .\s* part of the rule indicates that a dot can be followed by multiple whitespace characters. Below are the packets that did not trigger the rule and the one that did. The only difference is that approximately 60 whitespace characters were added after a dot in the latter.
When a small number of whitespace characters are added, the rule is still triggered; however, when the number of whitespace characters increases (to around several dozen), no alert is generated.
Here are the detailed PCAP packets. To reproduce the issue, you can use the following command:
test_sid14266.rules (837 Bytes) triggered.pcap (1.5 KB) untriggered.pcap (1.7 KB)
All configurations used are the default settings of Suricata. The Suricata version is 8.0.0-dev, and the testing environment is Ubuntu 22.04. I conducted the tests on a PC with an Intel i5-13600 CPU. I am not sure if this could have any impact on performance.I suspect that there might be a subtle flaw in Suricata’s handling of whitespace matching, which could be causing this issue. I would greatly appreciate your thoughts on this matter. Thank you once again for your attention to this issue!
Today, I sent the pcap file to several colleagues and asked them to verify the phenomenon on their own computers. The results showed that the issue was successfully reproduced on both version 8.0.0-dev and version 7.0.8. We will continue to analyze the root cause, but we believe that you are obviously more familiar with the source code. If you need more detailed information about the reproduction, I will do my best to provide it to you.
Sorry to bother you but long time no see!
Based on the issues I raised earlier, I have made some further modifications to the packets and uncovered more detailed problems. For specifics, please refer to this post .https://forum.suricata.io/t/suricata-may-have-issues-with-the-matching-of-in-some-pcre-patterns/5254. I believe it is necessary to keep you informed if you are still interested in this issue.