Snort fatal error after emerging.rules update
-
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.
-
@valete3 said in Snort fatal error after emerging.rules update:
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.
Thanks @valete3 for the status update and getting the issue resolved
. -
@bmeeks Hello thanks for the reply, Sorry I should have been more clear with this. I did not mean the Snort package, I was talking about the Watchdog package, you seemed to have a lot to say about that package as well as knowledge on a direction on what needs to be done to fix it/improve it. Back to Snort, it seems has no code written for error conditions such as this. I assumed that if such errors occured in the past and still continues to occur once and a while that some type of code/function could be implemented to catch this error. That way it could at least bring Snort into an active state again. Right now as it sits we can agree that this error condition has the ability to offline and degrade a firewalls whole IPS/IDS security system. This error flat took it offline and disabled it. Therefore the Snort pfSense IPS/IDS package's uptime took a massive hit. It degraded performance that drastically within the firewall. Cisco ASA and Firepower, Palo Alto IPS/IDS, Juniper, Ciena, Riverbed, and even smaller Meraki systems would see this as a major security concern as a couple rules in this set did have the ability to offline the security system.
It's the weak point in the wall.
We need a backup plan like tar and feathers type code.. .Make sure to upvote
-
-
@JonathanLee said in Snort fatal error after emerging.rules update:
I assumed that if such errors occured in the past and still continues to occur once and a while that some type of code/function could be implemented to catch this error.
And exactly how should the Snort GUI package PHP code identify what's wrong and fix it? How in the world can the PHP code know what's wrong within the third-party Snort binary?
All it knows is the binary threw an error starting up and aborted. The PHP code can do nothing at that point.
If uptime is such a huge concern, then the very first rule of reliability is never, ever let a system perform automatic unattended updates. You can never know what might get pushed out. For high reliability installs, you should personally manage all updates (including for IDS rules) in person at the firewall so you are there to take remedial action if necessary. And most every large outfit I've been involved with has a dedicated test system that is a duplicate of production, and they thoroughly test all updates in that test system prior to rolling them out to production.
-
@bmeeks What about it keeps the old ruleset if it fails with such a condition reload the old rules and stop for a period of a sometime like 8 hours and try again. Log the errors so everyone can see with a log that says loading prior rule set with a date and time? It pointed to a rule after it updated, so it should in theory be able to catch the error and do an if statement.
You like the castle don't you
