Home page logo
/

snort logo Snort mailing list archives

Re: [Emerging-Sigs] New Proposed Classification.config file setup
From: Martin Holste <mcholste () gmail com>
Date: Fri, 24 Dec 2010 12:28:16 -0600

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 () sourcefire com> 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 () us-cert gov> 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 () sourcefire com]
Sent: Thursday, December 23, 2010 10:54 PM
To: Joel Esler
Cc: snort-sigs () lists sourceforge net; Emerging Sigs;
snort-users () lists sourceforge net; snort-devel () 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 () sourcefire com>
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 () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
_______________________________________________
Emerging-sigs mailing list
Emerging-sigs () emergingthreats net
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!


------------------------------------------------------------------------------
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 () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]