Re: Snort XML Output

[Chris Green <cmg () uab edu>]

I've visited them all but XML and ended up at 'we need an inline
format' which I think Marty may be working on.

Joe McAlerney <joey () SiliconDefense com> writes:

> Hello Jason,
>
> "Jason M. Frey" wrote:
> > Trying to determine the best management methods for
> > logs and alerts.  Can anyone offer some advice on the
> > following methods/tools?

Depends entirely on how much traffic you see.  The more processing
done at log time, the less effective your sensor can be with the
current

see -> <alert> -> resume seeing approach.  The more you do at the
alert, the more you can miss packets ( it's not that big of a problem
with small amounts of code in <alert> but for big values of alert, you
can spend more time there than your buffers can be cleaned out (
atleast I think thats how the network <- pcap -> snort stuff goes ).

> > XML Output?
>
> Very customizable.  You can take advantage of a number of XML enabled
> tools out there.  Alerts can be transported over a secure connection. 
> There is more information in the README.xml file.

Lack of snort specific tools rules this out for most people though.
It seems to be sidelined, possibly waiting for outcomes of IDWG
stuffs.   

> > ACID?
>
> Real time viewing of events.  PHP front end to a database.  Alert
> management.  Detailed searching options.  Graphing of alert groups (one
> of my favorites).  Support for multiple Snort sensors.  Quick links to a
> breakdown by protocol, alert, address, time.  See the following link for
> more information:  http://www.cert.org/kb/acid/

Can be very neat but it does a LOT of work IMO on the backend for
every thing it logs last time I read through it.  On even medium speed
connections, it may be a bottle neck. select, convert, insert, insert,
insert lather rinse repeat.


> > SnortSnarf?
>
> Parses Snort alert files into HTML pages.  Multiple sorting options. 
> Displays the original rule that triggered the alert.  This is helpful in
> determining whether or not an alert is a false positive.  Annotations
> support.  SPADE anomaly detection section.  Incident storage and
> response.

Very nice script but it can use a lot of memory to generate the
reports if you have a lot of data.  It can be a bit hard to add on to
though as James really knows his perl :).  He broke it down in to
modules to make it easier. 

> > logs - tcpdump vs. full
>
> tcpdump - Greatly reduces the chance of packets being dropped.  Can be
> re-read into Snort and output again in another format (XML, Database,
> Full alert, etc.).

This is a necessity to me.  Lets me use ethereal to go through and
quickly analyze whats been captured, especially with dynamic rules.

> full - The files are instantly produced in a format that is parseable by
> SnortSnarf, or other log file parsers.  This format is often nice to
> archive using tar with compression.

Takes a long time to process - best done in very low bandwidth
environments and whatnot.

Using fast + binary seems to be at the top of the options list -
enough to quickly grep through for what alerts have been seen and you
can run SnortSnarf on it to aggregate things up for human based
processing.

The binary ones are there for you to be able to fully analyze with
whatever tools, including rerunning it through snort.

I've currently got some scripts together to rotate hourly and run
snortsnarf on the fast alerts.  Then, daily, I run snortsnarf on all
the day's alerts and use pcapmerge to put everything together ( I've
had better luck w/ pcapmerge than tcpslice ).

Then I scroll through with ethereal filters and snortsnarf listings to
find out whats been happening with alerts.  It's the most effecient
setup I've got going so far though there is plenty of room for
improvement.

IDS support for notes and whatnot in ethereal or perhaps external
bindings for ethereal's abilities.

I'd be interested to hear what other homebrew solutions people are
doing.
-- 
Chris Green <cmg () uab edu>
 "Not everyone holds these truths to be self-evident, so we've worked
                  up a proof of them as Appendix A." --  Paul Prescod

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
http://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users