[Snort-users] Snort XML Output
cmg at ...671...
Tue Jun 5 14:15:09 EDT 2001
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 at ...47...> 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
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
> 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.
> 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
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
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
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
Chris Green <cmg at ...671...>
"Not everyone holds these truths to be self-evident, so we've worked
up a proof of them as Appendix A." -- Paul Prescod
More information about the Snort-users