[Snort-sigs] [Emerging-Sigs] [Snort-devel] Snort 22.214.171.124 Now Available
l0rdch0de1m0rt at ...2420...
Thu Nov 4 13:44:17 EDT 2010
Hello. Good points Mike. One thing I want to make clear is that I
consider a bug that affects packet reassembly dependent detection as a
non-trivial security bug since it can lead to easier IDS/IPS evasion.
Specifically, this is the HTTP pre-processor issue I and others have
brought up and apparently affects 126.96.36.199, 188.8.131.52, and probably more
(I don't think I had the same problems with 2.8.5, though). However,
SourceFire has chosen not to fix this bug in recent versions of snort
other than the latest minor release -- 184.108.40.206. Be aware.
On Thu, Nov 4, 2010 at 11:50 AM, Mike Lococo <mikelococo at ...2420...> wrote:
> On 11/03/2010 09:48 PM, Joel Esler wrote:
>> What versioning in Snort rules do you all find to be acceptable?
>> Take into account that there is no way we can maintain every version
>> of every build and I am committing to nothing, I would just like to
>> hear some constructive ideas.
> I imagine my take is pretty clear by now, but for the record:
> * 2.9.latest and 2.8.latest is actually a good policy for rule
> availability (n.latest and n-1.latest for *major* versions).
> * Security-fix availability should be synced with rule-availability.
> Remote-exploits don't happen that often in snort, but SF should commit
> to releasing fixes for 2.8.latest until it's EOL'ed. (ET-Pro may be
> releasing rules for 2.4, but will anyone fix vulnerabilities for it?)
> * Don't release disruptive new features, or features that break
> backwards compatibility within a major-series. Wait for 2.10 or 3.0. We
> shouldn't have to worry about a ruleset for 220.127.116.11 causing 18.104.22.168 to
> fail on startup a month and a half after 22.214.171.124 was released.
> * Release new major-series on a semi-regular basis (once per year or
> once per 6-months), even if the changes in it aren't earth-shaking. This
> will get folks on a predictable upgrade schedule that they can plan for
> in advance.
> Support of any kind for 2.6 or earlier is a waste, IMO. 2.8 was
> released over three years ago, and anyone who hasn't been able to
> engineer an upgrade in that time period has problems that SF can't solve.
> Determining how to support different minor versions like 2.8.6 vs 2.8.5
> wouldn't be an issue if you adopted the versioning guidelines above
> since minor and patch releases within a major-series would be
> essentially interchangeable except for bug/security-fixes and
> optional-use new-features. I imagine that you'd satisfy the 80/20 rule
> with a cutoff at 2.8.latest, but that going back to 2.8.5 would make
> some additional folks happy.
> Mike Lococo
> Emerging-sigs mailing list
> Emerging-sigs at ...3335...
> Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards
More information about the Snort-sigs