mailing list archives
Re: [Emerging-Sigs] [Snort-devel] Snort 22.214.171.124 Now Available
From: L0rd Ch0de1m0rt <l0rdch0de1m0rt () gmail com>
Date: Thu, 4 Nov 2010 12:44:17 -0500
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 () gmail com> 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
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.
Emerging-sigs mailing list
Emerging-sigs () emergingthreats net
Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
Snort-sigs mailing list
Snort-sigs () lists sourceforge net