Snort fatal error after emerging.rules update
-
Woke up this morning with >200 emails in my inbox ... Service watchdog tried every minute to restart Snort and sent me an email.
Great to have the solution already, thanks!
-
Thank you!! I just hit this issue this morning too - over 300 service watchdog errors. Just fixed it now. thank you!
-
@bmeeks said in Snort fatal error after emerging.rules update:
They will release an updated rules archive for those rules pretty soon is my guess
new rules. Go to: Services / Snort / Updates
Force Update
Now working fine
-
I'm seeing a different rule failing than anyone else in this thread so far:
FATAL ERROR: /usr/local/etc/snort/snort_4851_ix0/rules/snort.rules:19567: Can't use flow: stateless option with other optionsForce Update has not fixed it for me.
When I look in the file I don't see a rule 19567, the nearest match is sid 2019567:
alert udp $HOME_NET any -> any 53 (msg:"ET TROJAN Sofacy DNS Lookup checkmalware.info"; content:"|01|"; offset:2; depth:1; content:"|00 01 00 00 00 00 00|"; distance:1; within:7; content:"|0c|checkmalware|04|info|00|"; fast_pattern; nocase; distance:0; reference:url,fireeye.com/resources/pdfs/apt28.pdf; classtype:trojan-activity; sid:2019567; rev:3; metadata:created_at 2014_10_29, former_category MALWARE, updated_at 2020_09_17;)Not sure if this is a match ? Seems strange that multiple different rules would all break on the same update ?
-
@theroot thanks
-
So I've disabled rule 2019567 and now its complaining about a different one:
FATAL ERROR: /usr/local/etc/snort/snort_4851_ix0/rules/snort.rules:19566: Can't use flow: stateless option with other optionsIs "can't use flow: stateless option with other options" actually a problem with the rules, or are the rules just incompatible with some general setting I have in Snort ?
-
After playing a game of whack a mole with half a dozen rules I've ended up disabling the entire "emerging-trojan.rules" rule category from ET Open Rules for now - seems like a really bad update has been pushed for these rules that has broken numerous rules, as every time I disable one rule it finds another one to complain about.
Will try enabling it again in a couple of days...
-
@mzawolski For me still not working
-
@demux Did you try disabling the entire category ? That's what I had to do.
If you run Snort on more than one interface (I don't) you'll need to make the same change on all interfaces.
-
Hi,
it works for me by disabling emerging-trojan.rules & snort_malware-cnc.rules categories
ps: It took me a long time to post my solution on this forum, I almost gave up
-
@DBMandrake said in Snort fatal error after emerging.rules update:
When I look in the file I don't see a rule 19567, the nearest match is sid 2019567:
The number shown at the end of the error message is the line number within the rules text file that is at fault. So the problem is with the rule text on line 19567 in the
snort.rulestext file in the subdirectory listed in the error. -
@DBMandrake said in Snort fatal error after emerging.rules update:
Is "can't use flow: stateless option with other options" actually a problem with the rules, or are the rules just incompatible with some general setting I have in Snort ?
Someone on the Emerging Threats team made a major boo-boo creating one or more of the latest rule archive updates. They will get it fixed and post new rules.
I have not actually checked to verify this hunch, but my first wild guess would be somebody accidentally packaged Snort3 rules in those Category files. The rule keywords and options differ between Snort 2.9.x (which we use on pfSense) and Snort3.
-
@jacotec said in Snort fatal error after emerging.rules update:
Service watchdog tried every minute to restart Snort and sent me an email.
@jagradang said in Snort fatal error after emerging.rules update:
over 300 service watchdog errors.
@jacotec and @jagradang:
Do NOT use Service Watchdog with the Snort or Suricata packages! It will eventually result in you having multiple Snort instances running on the same interface.Service Watchdog is a very primitive package. It simply looks for a running process with the name you give it, and when that process is not running, it calls the shell startup script for that process to attempt a start. There are multiple problems with this level of simplicity when it comes to the IDS/IPS packages.
First, Service Watchdog has no way of knowing about nor interpreting multiple Snort instances - with each running on a different interface. So long as one single Snort instance is running on any single interface, Service Watchdog is happily unaware that any other Snort instances configured are down. So, if you have Snort running on the WAN, LAN, and DMZ, then Service Watchdog will be totally clueless if two out of the three configured Snort instances fail.
Second, Service Watchdog does not understand that Snort periodically stops and restarts itself during rules updates. Service Watchdog just blindly monitors for a process name, and when that process disappears from memory it immediately attempts a restart of it. But during rules updates, Snort purposefully shuts itself down and restarts to load the new rules. It is very possible that during that brief restart interval Service Watchdog tries to start Snort as well. That can lead to duplicate processes running on the same interface and what I've tagged as "zombie Snort processes". Zombie Snort processes will cause you no end of grief and confusion as they will continue to run and block but not respond to anything you do in the GUI.
-
@mzawolski for me no love
-
I was able to get it to load by disabling the following ET Pro rules released last night.
Edit: bmeeks post about disabling rules in bulk, https://forum.netgate.com/topic/81700/mass-disable-snort-rules
2046273 - ET MALWARE [Mandiant] UNC4841 SEASPY Backdoor Activity M1 (malware.rules)
2046274 - ET MALWARE [Mandiant] UNC4841 SEASPY Backdoor Activity M2 (malware.rules)
2046275 - ET MALWARE [Mandiant] UNC4841 SEASPY Backdoor Activity M3 (malware.rules)
2046276 - ET MALWARE [Mandiant] UNC4841 SEASPY Backdoor Activity M4 (malware.rules)
2046277 - ET MALWARE [Mandiant] UNC4841 SEASPY Backdoor Activity M5 (malware.rules)
2046278 - ET MALWARE [Mandiant] UNC4841 SEASPY Backdoor Activity M6 (malware.rules)
2046279 - ET MALWARE [Mandiant] UNC4841 SEASPY Backdoor Activity M7 (malware.rules)The release notes for the rules have this comment, it looks like they might have missed part of the range of rules that don't work with Snort 2.9.
Hey folks, I thought I’d add a little bit more context for tonight’s rule release:
Rules
2046275 - 2046279 (SEASPY) are only available for Suricata 5+. This is due to detection engine limitations – neither Suricata 4.x nor Snort 2.9 have the tcp.hdr option to perform content matching in the TCP header portion of network traffic.Please refer to: Barracuda ESG Zero-Day Vulnerability (CVE-2023-2868) Exploited Globally by Aggressive and Skilled Actor, Suspected Links to China | Mandiant 2
It appears that a number of the SEASPY detection rules rely on analyzing specific TCP OPTIONS.
Take a look at the documentation for tcp.hdr for more information: 5.3. IP Keywords — Suricata unknown documentation 2
-
@zoomequipd have you seen this bug?
-
@bmeeks you should make a Redmine request about this package with your findings, that way it will get fixed.
-
@JonathanLee said in Snort fatal error after emerging.rules update:
@bmeeks you should make a Redmine request about this package with your findings, that way it will get fixed.
I am the package developer/maintainer for both Snort and Suricata on pfSense. I maintain both packages, not Netgate. A Redmine ticket makes no sense for this issue.
This is not a "bug" in the package. It is an error in the Emerging Threats rule package produced by other parties (in this case Proofpoint, who bought Emerging Threats a few years ago). The creators of the rules package will fix this problem. This is not the first time an error has been introduced by a rules package update from a vendor.
-
@bmeeks said in Snort fatal error after emerging.rules update:
@JonathanLee said in Snort fatal error after emerging.rules update:
@bmeeks you should make a Redmine request about this package with your findings, that way it will get fixed.
I am the package developer/maintainer for both Snort and Suricata on pfSense. I maintain both packages, not Netgate. A Redmine ticket makes no sense for this issue.
This is not a "bug" in the package. It is an error in the Emerging Threats rule package produced by other parties (in this case Proofpoint, who bought Emerging Threats a few years ago). The creators of the rules package will fix this problem. This is not the first time an error has been introduced by a rules package update from a vendor.
Thx for the update!
I hope we will know when it will be resolved...
-
Emerging threats released out of band rules update to resolve.
https://community.emergingthreats.net/t/ruleset-update-summary-2023-06-15-v10349/656/4
This problem was due to two rules using the syntax flow:stateless,to_server for the snort version of two of the SEASPY rules. Snort does not like having flow:stateless combined with other flow options and throws an error. The error isn’t formatted like any of the other errors Snort typically throws regarding rule syntax errors, and our QA systems missed it. Our QA system has been updated to account for this error, and we’ve released an emergency out of band update that is available now to fix this problem.
We apologize for any inconvenience this has caused you or any other netgate customers, and have made necessary precautions to prevent it from happening in the future. If there is anything else I can do for you, please let me know.
