It appears that there are a couple of items that have been discussed here
that are broken in the way Sourcefire distributes rules and configurations
to all groups.
Only time will tell if this discussion has made any difference at all.
BTW; I understand the way the rules works, it's the way the configuration
files are distributed that's the problem.
On the day Sourcefire released Snort 2.9.4.0 to the general public all
distributions, including the rule set for both groups should have contained
the very latest 'CURRENT' configuration files for Snort 2.9.4.0, but they
didn't (snort.conf contained reference to 'output database', and there were
missing port assignments).
After the initial release of Snort 2.9.4.0; to make SURE the end users have
access to all the 'CURRENT' configurations files on any given day, why not
just merge all the 'CURRENT' configuration files when new rules are added to
each group.
There should be no reason why a new user can't just grab the Snort
executable, latest rule set (they are entitled to), install Snort, extract
the rule set into the snort folder, and end up with all 'CURRENT'
configuration files that were relevant from the previous day.
-----
IMO, any known buggy rules that Sourcefire repairs, should be released to
whichever group has access to the buggy rule. It's pretty clear any user
running a rule that is deemed buggy, should be entitled to the fix when it's
released. Seems kind of petty to fix the rule only to release it to paid
subscribers, and allow non-paying user to continue to run a buggy rule for
30 days before they receive the fix.
Best regards,
Michael...
From: Joel Esler [mailto:jesler at ...1935...]
Sent: Friday, January 04, 2013 10:28 AM
To: Jeff Kell
Cc: Michael Steele; <snort-users at lists.sourceforge.net>
Subject: Re: [Snort-users] Persistent problems with rule updates for
Registerd Users
On Jan 3, 2013, at 11:51 PM, Jeff Kell <jeff-kell at ...6282...
<mailto:jeff-kell at ...6282...> > wrote:
On 1/3/2013 11:40 PM, Joel Esler wrote:
The registered rule set package doesn't change from the time we
package it as a subscriber set, and the time it rolls over to
registered. It's the same package, same Ruleset, the complete Ruleset,
a delayed version, not a forked version.
And if there are any "buggy" rules in the original set, you won't get
the "fixes" for 30 days either. Fixes/revisions aren't retroactive.
(Going to try and reply to this whole thread at once)
That is correct. Again, The free product is a delayed tarball.
Think of it like this. (This isn't how it actually works, but it's a
simplistic explanation)
We have a directory dated "20130104", in there contains the 4 current rule
tarball builds. After 30 days, that directory is then made available to the
registered users download. Essentially if you think of it like a shell
script that just moves the directory to a different place. Again, not how
it works, but hopefully you get the point.
The rules will stay there until there is no more space on the drive, then
they are cleaned up, oldest first.
For instance, we've had thousands of downloads of the 2912 ruleset in the
past 60 days from people whom have not upgraded or have not changed
pulledpork/oinkmaster to point at the new version. We leave them there even
after EOL until we can't hold them anymore. They just are no longer updated
after EOL. Heck, one of our most popular rulesets is 2923, and that will be
EOL at the end of February.
Most people are one version back. (current is 2940, so I mean 2931 in this
case). Either this is because they are downloading the 2931 ruleset because
they haven't upgraded yet, haven't changed their pulledpork/oinkmaster
config (this is usually the reason I've found) or they just haven't plain
upgraded. We even have people that haven't changed the format of their
download url yet (like: snortrules-snapshot-2931_s.tar.gz, if you remember
the _s nomenclature for downloading), hundreds of people.
Now, when we release a new version (2.9.4.0), we release the subscriber set
right away of course. The registered users get the ruleset for that specific
version 30 days later. The plaintext 2931 ruleset will still work in 2940.
I say plaintext because sometimes there is a compatibility upgrade in the
few SO rules that we have that won't work in a newer version, but most of
the time, they will still work.
We've considering fixing this a number of ways, but no way we have come up
with either makes it simpler for the user or doesn't align with our current
business model.
I say current because it may not always be that way. We are making some
changes soon that will help out the vast majority of users (especially in
terms of what Jeff is referencing above). I don't have a release date for
this yet, but rest assured when it comes out, I'll make a big noise about
it.
It may not always be this way, and we are looking at ways to improve the
process for users. We've heard the complaints from people that it's just
too difficult to get Snort up and running. There's some work we can do here
at Sourcefire to make it easy for people, and we are going to do that, but
at the end of the day, this is an IPS. This is something you have to
maintain and groom. It will require changing from time to time to keep pace
with current threats and upgrades. I try to keep everyone as informed as I
can via the Snort blog, this mailing list and Twitter. I don't know how
else to possibly alert you to changes.
Please, if you have a suggestion I am all ears.
--
Joel Esler
Senior Research Engineer, VRT
OpenSource Community Manager
Sourcefire
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20130104/4c605f32/attachment.html>