Re: Persistent problems with rule updates for Registerd Users

[Joel Esler <jesler () sourcefire com>]

That's something to consider.  We have some infrastructure work to do first.  But that's a consideration.

--
Joel Esler
Senior Research Engineer, VRT
OpenSource Community Manager
Sourcefire

On Jan 4, 2013, at 7:43 PM, Jeff Kell <jeff-kell () utc edu> wrote:

> 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 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> 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 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 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 exists.
> > >  
> > > Best regards,
> > > Michael...
> > >  
> > > From: Joel Esler [mailto:jesler () sourcefire com] 
> > > Sent: Friday, January 04, 2013 1:53 PM
> > > To: Michael Steele
> > > Cc: 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> 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!