[Snort-users] Persistent problems with rule updates for Registerd Users

Jeff Kell 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
> Sourcefire
> 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
>> latest.
>> 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,
>> Michael...
>> *From:* Joel Esler [mailto:jesler at ...1935...
>> <http://sourcefire.com>] 
>> *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 to the general
>>     public all distributions, including the rule set for both groups
>>     should have contained the very latest ‘CURRENT’ configuration
>>     files for Snort, but they didn’t (snort.conf contained
>>     reference to ‘output database’, and there were missing port
>>     assignments).
>> 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; 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
>> Sourcefire

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20130104/33a58e0b/attachment.html>

More information about the Snort-users mailing list