Re: Persistent problems with rule updates for Registerd Users

[Joel Esler <jesler () sourcefire com>]

It has nothing to do with "pettiness".  It simply has to do with how the infrastructure is set up currently.  

I don't think anything further is going to come out of this discussion that is productive.    I have some bugs in to 
fix a few things short term, and longer term we're going to be examining how this is set up.

I'd like to thank everyone for their input, and I'll see what we can do.  First things first though.  There are two big 
projects that must take place before we can make any movement as far as the suggestions noted below.

Thanks again.

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

On Jan 4, 2013, at 7:58 PM, "Michael Steele" <michaels () winsnort com> wrote:

> If a rule has been updated (usually means it was broke) for whatever reason, and the Registered Users group has 
> access to this rule, I just don’t understand how Sourcefire can deny that rule to them after it has been updated.
>  
> Allowing the Registered Users to run a buggy rule for 30 days, knowingly. Seems kind of petty to me.
>  
> Best regards,
> Michael...
>  
> From: Jeff Kell [mailto:jeff-kell () utc edu] 
> Sent: Friday, January 04, 2013 7:04 PM
> To: Michael Steele
> Cc: 'Joel Esler'; snort-users () lists sourceforge net
> Subject: Re: [Snort-users] Persistent problems with rule updates for Registerd Users
>  
> The one missing piece I would like to see that wasn't addressed in this discussion...
>
> Subscriber rules are obviously current.  Registered rules are apparently a 30-day delayed tarball of whatever was 
> current 30-days ago.  This makes perfect sense for NEW rules.  It does not make sense for UPDATED rules.
>
> If there is a revision update to an existing rule, it should be updated in ALL the branches, not just the VRT one.  
> Currently the revision updates are also delayed 30 days.
>
> I suppose the same logic could be applied to the other peripheral files discussed below... it would make sense to me 
> that the only difference between subscriber and registered access is the "new" rules.  Everything else should be 
> consistent (snort.conf, classification, reference, etc) across the board.
>
> I realize this is much more difficult that just freezing a few tarballs and holding them for 30 days; you'd have to 
> update the frozen copies with changes to the files (other than the "new" rules).
>
> Jeff
>
> On 1/4/2013 6:53 PM, Michael Steele 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!