Re: IDS / Snort/VRT GPLv2 Community-Rules : Error parsing signature... - but I can't deactivate specific rule(s)

[Adolf Belka <adolf.belka@ipfire.org>]

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 <
>> matthias.fischer@ipfire.org> 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
>>>
>>>
>>>
>>
> 
>