From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4gDYJl6c5Vz33gK for ; Mon, 11 May 2026 08:47:51 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4gDYJh4SVfz2xPX for ; Mon, 11 May 2026 08:47:48 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4gDYJg4l7Wz10N; Mon, 11 May 2026 08:47:47 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1778489267; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9dp3SOCMEHNJkBkf0n/oEWqXqKTvfKhaXKg5w6v0dOs=; b=XdXuxizFKLvGD1Kdx0FymhZwiIRvhZfrcavQHhBqWMIjrQCbH2IQpcT3s5hhPMDobX/bQx YElkwlTiMQEQ/0BQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1778489267; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9dp3SOCMEHNJkBkf0n/oEWqXqKTvfKhaXKg5w6v0dOs=; b=geBaOik5+Il1LS0rtwlYLnv80Dc38VWjJ+JMdhE4/cS6ak2IpV8nrUp4thOwS0CukovMoq L/djwBnfevcMfhgYjUck0j87W/yG3o0veH/MOrVOLg56Biz65ZabGEP257YcZvxl3viVH8 XfdUxiIxWkbbF8Zyxw+foakgQGsqqvxrx9A5eSkceIeWXnloEPEU4cjzfnVLVAxBa1W1zy ayOnmeh+d1jWdrpKiaqvzWD+IdE8r7swR5Dq7cmIdn4+U49KE6Y5sjQ6Oza0ojwO31KBSJ uiGYlVJJKCrAYQLz4wyF61oW0Ag8Sm7p9LwkCDGRB29hPMTlr9/pcXI49452WA== Message-ID: <3375b023-970c-4cfa-8d3e-db1f64d23a04@ipfire.org> Date: Mon, 11 May 2026 10:47:40 +0200 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Subject: Re: IDS / Snort/VRT GPLv2 Community-Rules : Error parsing signature... - but I can't deactivate specific rule(s) To: Matthias Fischer References: Content-Language: en-GB Cc: "IPFire: Development-List" From: Adolf Belka In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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 >>> >>> >>> >> > >