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
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
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
Snort-devel mailing list
Snort-devel () lists sourceforge net
Re: [Emerging-Sigs] New Proposed Classification.config file setup Frank Knobbe (Dec 27)
Re: New Proposed Classification.config file setup Crusty Saint (Dec 28)
- Re: New Proposed Classification.config file setup, (continued)