Snort mailing list archives
Re: New Proposed Classification.config file setup
From: Crusty Saint <saintcrusty () gmail com>
Date: Tue, 28 Dec 2010 14:07:51 +0100
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
Current thread:
- Re: New Proposed Classification.config file setup, (continued)
- Re: New Proposed Classification.config file setup Martin Roesch (Dec 23)
- Re: New Proposed Classification.config file setup Joshua.Kinard (Dec 23)
- Re: New Proposed Classification.config file setup Joel Esler (Dec 23)
- Re: [Emerging-Sigs] New Proposed Classification.config file setup Martin Holste (Dec 26)
- Re: [Emerging-Sigs] New Proposed Classification.config file setup Martin Roesch (Dec 27)
- Re: [Emerging-Sigs] [Snort-devel] New Proposed Classification.config file setup Martin Holste (Dec 27)
- Re: [Emerging-Sigs] New Proposed Classification.config file setup Joshua.Kinard (Dec 27)
- Re: [Emerging-Sigs] New Proposed Classification.config file setup Martin Holste (Dec 28)
- Re: [Emerging-Sigs] New Proposed Classification.config file setup Gregory W. MacPherson (Dec 28)
- Re: New Proposed Classification.config file setup Joshua.Kinard (Dec 23)
- Re: New Proposed Classification.config file setup Martin Roesch (Dec 23)