[Snort-devel] Outputting info about a rule that fires

Hammerle, Tye F. Tye.F.Hammerle at ...161...
Fri Feb 23 18:22:20 EST 2001


Having snort push that extra output seems like too much overhead that would
detract from the basic purpose and performance. Maybe that sort of thing is
best left to another piece of software like snortsnarf. Perhaps instead of
adding this to snort you wrote a utility that scans the alert file and
produces a summary file with the info you listed below. Though it seems that
snortsnarf already does that. Maybe snortsnarf could be modified to output
this format too or it could read the file produced by the utility. Then
snort wouldn't need fattening.

Tye



-----Original Message-----
From: James Hoagland [mailto:hoagland at ...63...]
Sent: Friday, February 23, 2001 4:47 PM
To: snort-devel at lists.sourceforge.net
Cc: hoagland at ...63...
Subject: [Snort-devel] Outputting info about a rule that fires


Hello all,

There has been quite a bit of discussion of late about making 
information about a particular alert rule that fired available to the 
user.  This information includes:

+ reference information from reference rule option as a URL and/or as 
source and ID field
+ priority level
+ etc.

(The last bullet seems pretty fertile.)

People have been wondering how best to add this information to the 
alert that is produced.  This is particularly troublesome for a 
textual output of the alert, since it can significantly bloat the 
size of the message, making it hard to read.  Also, the information 
contained would be presented with each instance of a match to a 
particular rule, so you would be seeing the same information over and 
over again.  Not to mention the burden it puts on tools such as 
SnortSnarf to parse this.

I have a proposal for a solution to this.  Why don't we output this 
information to a separate file?   This file would contain a 
"paragraph" for each rule that has fired and have a blank line in 
between paragraphs.  This paragraph can be extensible and might look 
something like (using only currently available information:

Message: dns-zone-transfer
Ref: arachNIDS:212, CVE:CAN-1999-0532, bugtraq:123
http://www.whitehats.com/IDS/IDS212
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-0532
http://www.all-about-zone-transfers.com/
http://advice.networkice.com/Advice/Intrusions/2000401/

Other information if somehow available (lets leave the "how" to a 
separate thread) could be added each to its own line with a label at 
the start.  Other information that someone might want includes:

+ priority level
+ the pattern that was matched (could be formated similar to rule but 
exclude rule options that are not related to a pattern that was 
matched and instantiate all variables, for example, "alert tcp 
!10.0.0.0/24 any -> 10.0.0.0/24 53 (flags: A+; content: "|FC|"; 
offset:13;)")
+ a short text description of the rule
+ a local note about the rule
+ a catagorization of the rule e.g., scan, web, buffer overflow

(Note that I am not nec. advocating these.  Well, excluding that 
second one. :))

The information in this file would be limited to what things that 
remain the same with every match of the rule.  This would allow the 
particular paragraph for a rule to appear exactly once.  The rules 
that have not fired (this is the vast majority) would not appear at 
all in this file.


If someone where browsing through their alerts manually and came 
across an alert from a rule they were not familiar with, they would 
then look in this separate file.  Otherwise this information would be 
sitting unobtrusively to the side.

For those that use SnortSnarf, SnortSnarf could be (and would be) 
enhanced at some point to read this file and present the information 
contained therein on an appropriate page.


The problem of passing along the extra information seems easier for 
the database output methods.  I suppose you could pass it as 
additional fields in an alert or maintain a separate table for rules. 
Not sure about this since I have looked at the database output too 
much.  (SnortSnarf will read databases at some point.  Really.  It 
should be easier with the modularized SnortSnarf since one would just 
need to write an input module.)


I guess that is enough rambling.  Comments/questions?

Regards,

   Jim
-- 
|*   Jim Hoagland, Associate Researcher, Silicon Defense    *|
|*               hoagland at ...60...                *|
|*              http://www.silicondefense.com/              *|
|*  Voice: (530) 756-7317              Fax: (707) 445-4222  *|

_______________________________________________
Snort-devel mailing list
Snort-devel at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/snort-devel




More information about the Snort-devel mailing list