[Snort-sigs] [Emerging-Sigs] [Snort-devel] New Proposed Classification.config file setup

Martin Roesch roesch at ...435...
Mon Dec 27 10:48:52 EST 2010


Yeah, I guess I didn't say it but I was recommending new keywords so
that we wouldn't break backwards compatibility.  I do favor mapping of
assigned enumeration values to strings though, I don't just want
random metadata because that can lead to a Tower of Babel situation
where people start baking up nonstandard things that break external
event processors.

Doing the metadata tag thing is fine in the near term as a "let's do
something now" solution for people who need it sooner rather than
later but I don't think adding new keywords should be all that tough
in this particular case.  Does info in the metadata fields even make
it into unified 2 output?  I'm not in a place where I can look it up
at the moment and I don't remember...

Marty


On Fri, Dec 24, 2010 at 1:28 PM, Martin Holste <mcholste at ...2420...> wrote:
> This is so simple to me it is exasperating:  Continue with the new
> classification system as proposed, add on metadata: tags=<csv of tags>
> as an interim tagging solution that supports full backward
> compatibility.  Mandate that only hyphens and commas are used in tags.
>  Don't worry about what the tags are for now, just start tossing
> something reasonable in there.  That's the whole point--they are
> extremely flexible and don't affect performance or parsing for
> existing tools.  Merry Snortmas!
>
> On Thu, Dec 23, 2010 at 11:52 PM, Joel Esler <jesler at ...435...> wrote:
>> I don't disagree. The thought was brought up to expand the classifications into something much more granular, and technically it was possible to replace the classifications we have with this more granular classification system with very little work.
>>
>> My biggest concern would be getting not only the internal Snort parsers fixed to accept it (which I am not saying isn't possible, just not currently slated on the build documents) but then getting all the output modules and gui's to recode to the new format. I'm all for backwards comparability where it makes sense.
>>
>> However, if there is a better idea the community has in order to make areas of Snort better, I'm all for it. I've heard Marty's idea, and I've heard s couple other ideas that have made it to me off list (if those people want to share their opinions on list, that would fuel the discussion as well)
>>
>> I'm definitely not the "decider" here, and I'd like to hear the community speak. I would love to see a fully dynamic classification system based upon contextual data, but i don't know if that's possible with the current code base.
>>
>> Maybe a simple replacement of the system we have now is a solution, maybe even just a short term one. Maybe we should redesign it totally as Marty (and others) have said. I think this is an important topic to bring up, and am glad ET and group did. It brings attention to an area of Snort that has really never changed since the beginning.
>>
>> Sent from my iPad
>>
>> On Dec 24, 2010, at 12:17 AM, <Joshua.Kinard at ...3546...> wrote:
>>
>>>
>>> Having a class & subclass mechanism would be really useful, IMHO.  It's
>>> cleaner-reading than constantly linking the two together via a hyphen
>>> and essentially repeating the class over and over again.  I can think of
>>> some saner categorization ways w/ a setup like this.
>>>
>>> --J
>>>
>>> -----Original Message-----
>>> From: Martin Roesch [mailto:roesch at ...435...]
>>> Sent: Thursday, December 23, 2010 10:54 PM
>>> To: Joel Esler
>>> Cc: snort-sigs at lists.sourceforge.net; Emerging Sigs;
>>> snort-users at lists.sourceforge.net; snort-devel at lists.sourceforge.net
>>> Subject: Re: [Snort-devel] New Proposed Classification.config file setup
>>>
>>> On Thu, Dec 23, 2010 at 5:27 PM, Joel Esler <jesler at ...435...>
>>> wrote:
>>>> As mentioned earlier, here's the proposed Classification.config file
>>>> setup posted and available for download here:
>>>> http://blog.snort.org/2010/12/new-proposed-classificationconfig-file.h
>>>> tml Please take a look, leave comments preferably on the blog, but
>>>> also here would be fine.
>>>
>>>
>>> It appears that there's two levels of information here, why not have a
>>> class and subclass?  For example:
>>>
>>> classification: exploit-shellcode
>>> classification: exploit-sql-injection
>>> classification: exploit-browser
>>>
>>> should maybe be
>>>
>>> category: exploit; class: shellcode;
>>> category: exploit; class: sql-injection;
>>> category: exploit; class: browser;
>>>
>>> Having the different levels of granularity could be useful for things
>>> list real-time response mechanisms that act on just the category or
>>> whatever.  Just thinking out loud here.
>>>
>>> Furthermore, maybe we should be thinking about really fixing the
>>> classification system with static value assignments for categories and
>>> classes and mappings between values and human readable strings.  I
>>> imagine this could make machine processing easier if we had output
>>> options that could generate either (more easily) machine readable or
>>> human readable data.  This would also make the runtime loading more
>>> sane, no more classification.config line order-dependent
>>> classifications.
>>>
>>> I mean, if we're going to fix it why not fix it right?
>>>
>>> Any log management/SIEM people paying attention on-list?  This is a
>>> chance to make your lives easier if you've got any input!
>>>
>>>
>>> Marty
>>>
>>>
>>> --
>>> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
>>> Sourcefire - Security for the Real World - http://www.sourcefire.com
>>> Snort: Open Source IDP - http://www.snort.org
>>>
>>> ------------------------------------------------------------------------
>>> ------
>>> Learn how Oracle Real Application Clusters (RAC) One Node allows
>>> customers to consolidate database storage, standardize their database
>>> environment, and, should the need arise, upgrade to a full multi-node
>>> Oracle RAC database without downtime or disruption
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Snort-devel mailing list
>>> Snort-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/snort-devel
>> _______________________________________________
>> Emerging-sigs mailing list
>> Emerging-sigs at ...3335...
>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>
>> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!
>>
>



-- 
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Security for the Real World - http://www.sourcefire.com
Snort: Open Source IDP - http://www.snort.org




More information about the Snort-sigs mailing list