Hi Matthias,
Snort rules have a syntax that is different from Suricata rules and the basis
of creation is slightly different as well and of course over time the
differences increase as Snort follow their path for their IPS.
Generally most of the snort rules will work with suricata but some of them
won't without the rule being modified. That rule you have flagged has a snort
syntax that suricata can't parse correctly.
That is why I don't use any of the Snort rules. I just use the Emerging Threats
rules which are created with the suricata syntax.
I am not in favour of modifying the code in the IPFire IPS because how can we
be sure that the modification to allow working with the Snort rules will
continue to work correctly with the Suricata rules.
I would think that the rules giving the problem need to be edited to work with
suricata. Suricata does not allow relative keywords around a fast_pattern only
content and if I am correct in my understanding that Snort rule does not follow
that suricata requirement.
You can find similar issues raised in the Netgate and OPNsense forums where
they also have a lot of parsing errors for Snort rules on Suricata
It might be worth for @Stefan to have a look at the problem and see if the code
can be modified to at least disable those Snort rules while still working
correctly for all the Suricata based rules.
Regards,
Adolf.
On 11/05/2026 09:32, Matthias Fischer wrote:
On 11.05.2026 03:04, Jay Lubomirski wrote:
Hi Matthias,
Hi Jay,
tested. Seems to work. This was odd...
Before I tested your patch, I checked
'/var/ipfire/community-modifications', which contained the appropriate
SID: '26470=disabled'.
But no chance. After applying your patch, the file hasn't changed, but
line 2581 in /var/lib/suricata/community-community.rules' now starts
with a "#".
=> Works. Rule is unchecked and stays that way. Will test further...
Thanks!
Matthias
I've been using this patch to fix the can't uncheck a rule problem:
# /var/ipfire/ids-functions.pl
#
--- ids-functions.pl.old
+++ ids-functions.pl.new
@@ -614,8 +614,8 @@
# Check if the Provider is set so IPS mode.
if ($providers_mode{$provider} eq "IPS") {
# Replacements for sourcefire rules.
- $line =~
s/^#\s*(?:alert|drop)(.+policy balanced-ips alert)/alert${1}/;
- $line =~
s/^#\s*(?:alert|drop)(.+policy balanced-ips drop)/drop${1}/;
+ $line =~ s/^(?:alert|drop)(.+policy
balanced-ips alert)/alert${1}/;
+ $line =~ s/^(?:alert|drop)(.+policy
balanced-ips drop)/drop${1}/;
# Replacements for generic rules.
$line =~
s/^(#?)\s*(?:alert|drop)/${1}drop/;
Can you see if that helps in your situation?
Jay Lubomirski
On Sat, May 9, 2026 at 12:12 PM Matthias Fischer <
[email protected]> wrote:
Hi list,
IDS is running with several rulesets, no seen problems, but one set
always throws this error:
***SNIP***
[1433] <Error> -- error parsing signature "drop tcp $EXTERNAL_NET
$HTTP_PORTS -> $HOME_NET any (msg:"MALWARE-OTHER Win.Trojan.Zeus Spam
2013 dated zip/exe HTTP Response - potential malware download";
flow:to_client,established; content:"-2013.zip|0D 0A|";
fast_pattern:only; content:"-2013.zip|0D 0A|"; http_header; content:"-";
within:1; distance:-14; http_header; file_data; content:"-2013.exe";
content:"-"; within:1; distance:-14; metadata:impact_flag red, policy
balanced-ips drop, policy max-detect-ips drop, policy security-ips drop,
ruleset community, service http;
reference:url,
www.virustotal.com/en/file/2eff3ee6ac7f5bf85e4ebcbe51974d0708cef666581ef1385c628233614b22c0/analysis/
;
classtype:trojan-activity; sid:26470; rev:2;)" from file
/var/lib/suricata/community-community.rules at line 2581
***SNAP***
Everything is working fine - except for this error message.
So I tried to deactivate this rule - but I can't. Every time I uncheck
this rule, it gets checked again. No chance. There are others —
apparently not every rule — who also refuse to get unchecked.
Can anyone confirm?
Best
Matthias
