Re: Persistent problems with rule updates for Registerd Users

[Jeff Kell <jeff-kell () utc edu>]

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.

Jeff

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 () winsnort com
> <mailto:michaels () winsnort com>> 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 () sourcefire com
> > <http://sourcefire.com>] 
> > *Sent:* Friday, January 04, 2013 1:53 PM
> > *To:* Michael Steele
> > *Cc:* snort-users () lists sourceforge net
> > <mailto:snort-users () 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 () winsnort com<mailto:michaels () winsnort com>> wrote:
> >
> >
> >     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).
> >
> >  
> > 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 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.
> >
> >  
> > 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

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!