Re: New Proposed Classification.config file setup

[Crusty Saint <saintcrusty () gmail com>]

Sorry for cutting in like this in a copy-past fashion.

> > On Mon, Dec 27, 2010 at 11:41 AM, Martin Holste <mcholste () gmail com> wrote:
> >
> > I'm really pushing for tagging because there will be such an
> > immediate benefit to getting something simple going.  Being able
> > to just reliably grep something like "zeus" and "check-in" from
> > the alerts will make such an impact for communicating to NOC
> > staff which events are important enough to alert the SIRT in the
> > middle of the night.  I value my sleep, gentlemen!
> >
> > The tag values won't need to be included in unified2 output in the
> > same way that sig names are not included.  It's up to the app to do
> > the lookup to resolve ints to strings.

>

> Martin's idea offers a _lot_ of power, assuming he's refering to a >
blog-like tagging feature. The "tag" keyword is already specific to >
another function, however, so I'd suggest these be called "labels" >
instead. Require definition of a label in a config file first (not >
arbitrarily created), and continue to append a priority value to them > like
'classtype', but not a description field: > etc/labels.config: > config
label: zeus,1

> config label: smtp,2

>     config label: ddos,1

>   config label: http,3

> config label: botnet,2

> Then in a rule, allow the use of as many of the defined labels as needed
> to clarify what the rule is doing:
  > labels:ddos,http,botnet; - for a rule looking for DDoS attacks over

> HTTP by a botnet.

> Unless the rule contains an existing "priority" keyword (which
> overrides), then the rule's priority is determined by the
> highest-priority label in the keyword's parameters.  Since 'ddos' is
> specified, the rule's overall priority is '1', overriding the lower
> values of the 'http' and 'botnet' priorities.

>

>

>

> Sidenote: I'd like to avoid extending "metadata" any -- internally, >
we've had problems with appending extraneous keywords to that parameter >
due to several parsing bugs in the SourceFire GUI (which are now fixed). >
I'd like to avoid any more of these getting created :)

>

>

> Cheers, > --J

What about this ... hoping the idea would not outgrow the
time/resource budget for this feature

Labels are classes which serve as a primary level identifiers (
protocol, port, vendor ... ) One or more labels can be added / rule.
In turn labels contain tags which provide more detail
(http/smtp/https/cookie/cert.... ), it would be *really* convenient if
some kind of cronological labeling/tagging (timestamp) could be in
place. Maybe just as an invisible field but exportable for
machine-analysis/visualisation.

IMHO this could describe threats in a novel way and allow for
super-easy 'mapping' of specific threats. There could be actual
time-based signatures emerging for specific attacks.


Just my 2cents.

------------------------------------------------------------------------------
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