[Snort-users] Persistent problems with rule updates for Registerd Users
jeff-kell at ...6282...
Fri Jan 4 19:43:46 EST 2013
Can you pick a "cutoff" sid# and let that cutoff number have the 30-day
roll? Then dynamically generate the rules files for anything with an
sid# < cutoff?
Yes, requires a new approach as opposed to the "frozen" copy, but
maintains your VRT edge while keeping everything else current.
On 1/4/2013 7:32 PM, Joel Esler wrote:
> Okay, so basically, what we are doing already.
> Except you want us to go back and change the Registered tar balls,
> which, unless we change the entire infrastructure of how it works.
> Not saying we won't, I'm saying that I'm not planning to yet. I have
> other things on the horizon that will fix /some/ of this, but not
> everything you are saying.
> So for now, we'll do what we can to make sure that we are using the
> same files across the board and minimize any differences.
> The Registered ruleset is current as of the ruleset that it is in, the
> snort.confs that are on snort.org <http://snort.org> are the most
> updated version at all times, regardless of release.
> We used to not put these out at all, and that was one thing we've fixed.
> *Joel Esler*
> Senior Research Engineer, VRT
> OpenSource Community Manager
> On Jan 4, 2013, at 6:53 PM, "Michael Steele" <michaels at ...9077...
> <mailto:michaels at ...9077...>> wrote:
>> There is no reason to do item 1. Once the new Snort update has been
>> released to the public, and it contains the current configurations
>> for that day, then there is no need to update it again until the next
>> Snort release.
>> There is no reason to do item 2. As long as the rule sets contain the
>> most current configurations at all times.
>> When a new Snort version is released to the public, the new Snort
>> release, the Subscribers rule set, and the Registered Users rule set
>> should all have the same CURRENT configuration files, the absolute
>> After the initial Snort release there is no need to update the Snort
>> executable until the next Snort release, just the Subscriber rule
>> set, and the registered User rule set need to be updated keeping the
>> configuration files always current between initial Snort releases.
>> The two configuration files that are being maintained on
>> the Snort.org <http://Snort.org> site are available for those that
>> prefer not to download the full set of rules just for one of those
>> configuration files. However, both of those files should always match
>> what is found in either set of rules.
>> Not sure how people would be notified that if they only require the
>> snort executable that they might need to go onto the snort.org
>> <http://snort.org> site and update the snort.conf, and the
>> classification.config, as they may be outdated between snort releases?
>> I don’t want to automate anything that is not absolutely necessary. I
>> could automate the complete Windows Intrusion Detection System
>> (WinIDS) installation process, but nobody learns anything, and that’s
>> the whole point behind why WinSnort.com <http://WinSnort.com> exists.
>> Best regards,
>> *From:* Joel Esler [mailto:jesler at ...1935...
>> *Sent:* Friday, January 04, 2013 1:53 PM
>> *To:* Michael Steele
>> *Cc:* snort-users at lists.sourceforge.net
>> <mailto:snort-users at lists.sourceforge.net>; 'Jeff Kell'
>> *Subject:* Re: [Snort-users] Persistent problems with rule updates
>> for Registerd Users
>> On Jan 4, 2013, at 12:55 PM, "Michael Steele"
>> <michaels at ...9077...<mailto:michaels at ...9077...>> wrote:
>> On the day Sourcefire released Snort 18.104.22.168 to the general
>> public all distributions, including the rule set for both groups
>> should have contained the very latest ‘CURRENT’ configuration
>> files for Snort 22.214.171.124, but they didn’t (snort.conf contained
>> reference to ‘output database’, and there were missing port
>> I simply forgot to delete those lines. I apologize on behalf of
>> Sourcefire for forgetting to remove those non-functional lines.
>> Sorry if that sounds a little snarky, but they were nonfunctional.
>> As far as missing port assignments, I'm quite sure that they weren't
>> missing port assignments at the time of release. They are */now/*,
>> as I've added ports since the time of release, but those changes
>> would only affect a very small number of rules (probably 5 or 6) that
>> aren't going to be in the registered rule release anyway until the
>> snort.conf that goes with those rules rolls into registered anyway
>> and everything is good to go. We aren't going to reroll the tarball
>> every time I make a change to the snort.confs.
>> So, here's our alternatives.
>> 1. We can subtract the snort.conf, classification, threshold,
>> reference, etc, from the tarball and distribute it only with the
>> rules, which means that you
>> A) can't get a working Snort out of the box
>> B) MUST download the VRT rules in order to get Snort to work
>> C) Neither of these solutions would work for anyone.
>> 2. We can subtract the snort.conf, classification, etc, from the
>> rule tarball and distribute it only with the Snort tarball, which
>> means that
>> A) We have no way to update it detection once Snort has been shipped.
>> B) Everyone gets screwed.
>> 3. We can prevent different snort.confs, classification, etc from
>> existing. We'll work on that.
>> 4. We can make Snort easier to set up by automating a lot of this.
>> Unfortunately, we won't be doing that for Windows users, as we're
>> not going to compile our Shared Object rules for the Windows
>> platform. Should be easy enough for you to batch script up something
>> for your "WinIDS" users though.
>> After the initial release of Snort 126.96.36.199; 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.
>> Not sure what you mean here.
>> When we release a new version of Snort the snort.conf that is shipped
>> with the tarball should be up to date with the VRT snort.conf and
>> that VRT snort.conf is what is in the tarball and what I put on the
>> website. I have a bug into development now to see if we can rectify
>> this in the future so it can't happen anymore.
>> 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.
>> They can. I don't see what you are saying here.
>> *Joel Esler*
>> Senior Research Engineer, VRT
>> OpenSource Community Manager
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-users