Snort fatal error after emerging.rules update

chudak

I see that too.

Thought maybe it relates to the global attack today, but not sure now.

So snort update broke this? Any fix?

TIA

chudak

@theroot said in Snort fatal error after emerging.rules update:

@InstanceExtension
I came across this a couple hours ago too. There's two rules causing it, SID 2046273 and 2046274. You'll find them under Wan Rules -> Category : emerging-trojan.rules . Disabling these two rules should resolve.

That seemed to have helped!

Thx!!!

bmeeks

This will have to be fixed by the Emerging Threats rule writers. They will release an updated rules archive for those rules pretty soon is my guess. As others have mentioned, you can temporarily work around it by disabling the culprit rules.

If something similar happens in the future, the error message can help you narrow down the rule. For this case, the error message gives you the rules file being processed and what line number in the file caused a problem.

/usr/local/etc/snort/snort_3612_ix1/rules/snort.rules:26779

Open the given file in a text editor and locate line #26779. The rule on that line will be the one causing the problem.

The Snort package collects all the active enabled rules and writes them into a snort.rules file for each configured Snort interface. Each configured interface has its configuration info provided in a separate subdirectory under /usr/local/etc/snort/.

demux

Thank you for this thread. It started tonight. And this morning I know what to do. Great!

jacotec

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!

jagradang

Thank you!! I just hit this issue this morning too - over 300 service watchdog errors. Just fixed it now. thank you!

mzawolski

@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

DBMandrake

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 options

Force 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 ?

JonathanLee

@theroot thanks

DBMandrake

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 options

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 ?

DBMandrake

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...

demux

@mzawolski For me still not working

DBMandrake

@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.

pitmacaloway

@DBMandrake

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

bmeeks

@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.rules text file in the subdirectory listed in the error.

bmeeks

@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.

bmeeks

@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.

chudak

@mzawolski for me no love

valete3

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

JonathanLee

@zoomequipd have you seen this bug?