Snort/VRT GPLv2 Community Rules not customizable

I read this thread from Core 173/174-Testing Snort/VRT ruleset and I am having the exact same problem now in 176. I can add the list, but it is not customizable (it doesn’t appear when I click "Customize Ruleset)

Any pointers ?

I confirm that the Snort/vrt ruleset is not shown.

I have checked and the snort community ruleset tarball is downloaded into the correct location but it is not getting extracted for some reason.

Some other change must have occurred with the snort/vrt community ruleset as the previous bug fix is still present in IPFire CU176.

I think you should raise a new bug for this.

Your IPFire People email address and password will act as the logon credentials for the IPFire Bugzilla.

1 Like

On my CU176 system, it seems that dl_url in /var/ipfire/suricata/ruleset-sources for Community rules from sourcefire references However, the link shown on Snort website for community rules is …

I think that link must be redirected to the correct location because if you use that url from ruleset-sources then you get the snort3-community-rules.tar.gz file downloaded and I checked the file downloaded from both urls and it is the same file.

Both urls are re-directed to for the actual download anyway.

I replaced dl_url with the direct URL to the tar.gz file and while it looks like it is being extracted after I add it as a provider, I still cannot customize the ruleset for it afterwards. (I deleted the provider first, then re-added after I modified ruleset-sources)

Should I go forward and create a bug report as you suggested ?

Edit: Also, there are no files created in /var/ipfire/suricata for the Community Rules.

The downloaded tarball ends up in /var/cache/suricata

If the tarball is being extracted you would find snort3-community.rules in /var/lib/suricata

The url is working because the tarball is being downloaded. What is not happening is the extraction of the tarball. I suspect that they have changed something in the structure of the files in the tarball and the regex that was used to find the .rules files from an archive is no longer finding it.

However, I am not familiar enough with regex commands to see what needs to be modified/added.

Yes, I think you should.

1 Like

I have figured out the problem. Snort changed the name of the top level directory in the archive from community.rules to snort3-community.rules.

The IPS code is looking for code that has a top level directory called rules and the previous bug with snort had to have that changed to $provider-rules because snort started to use community-rules as the top level directory in the archive and now they have changed it again to snort3-community-rules.

In the code in line 575 where it has $provider-rules I changed that to snort3-$provider-rules and I was able to see the snort community rules again.

I will pick up that bug and submit a patch to fix this.


That is awesome!


I just took a look at the suricata logs, it appears all signatures are generating errors. Oooops.
I have hundreds of [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] all related to the Snort Community ruleset.

I sent a message to Adolf Belka.

(Edit1 : just did it and it worked! Thanks !

For anyone wondering how to do this, or if it happens again in the future:
(hello future me)

  1. enable ssh and log in, or go to your firewall screen
  2. nano /var/ipfire/
  3. press ctrl+/
  4. type 575
  5. immidiately before the part of the line that says “$provider-rules”, insert “snort3-” right before the “$”
  6. press ctrl-x
  7. press y and enter to save
  8. (exit ssh session and disable ssh)
  9. add the Snort/VRT ruleset provider in the web UI
  10. you can now actually use and customize the ruleset)

I didn’t look any further as thought the problem was only the extraction.

I will redo the change on my vm system and look at the logs.

All my future comments will be in the bug report so I don’t have to write everything twice.

@equex can you add your latest findings into the bug report.