[Snort-devel] de-logging tagged packets to an acid database with barnyard
Dirk_Geschke at ...802...
Tue Aug 9 18:22:53 EDT 2005
> I have found that I need to store roughly 20X the number of events
> when I store tagged packets in the database. So for performance
> reasons, I don't log tagged packets into the database. Instead I'm
> using barnyard to parse the unified logs into pcap files, which I can
> analyze offline with tcpdump when the need arises.
> So given all of that, does this code make sense, or is there a better
> way to do it?
but if you only store 5% of the alerting packet it would be not
very helpful for analysis. You probably will not see the alerting
part of the network packet. Furthermore, you will not see that it
is really a part of a ueberpacket. So finally you will believe
that there is a bug in snort...
Or otherwise if there is a bug in snort you will not see it.
Of course you can store the whole packet in pcap files. But this
will result in a headache, for every alert you find in the database
you have to find the according pcap file and analyze it in a different
environment. Sounce not like a practical way...
One thing I never understood was the reason why it is not optional
to decompose the ueberpacket into smaller ones. In earlier versions
the whole ueberpacket was stored in the database as one event, now
only the first packet is stored as the regular event and the further
parts are stored as tagged packets.
It would be smarter to make the behaviour configurable and this is
done by one additional line of source code...
And maybe a better way could be FLoP, depending on the environment
you are using...
If you use several snort sensors and one central server running
the database then FLoP would be an option. It is similar to barnyard
with the acid output plugin but all inserts and selects are made on
the central server and not on the snort machine...
You can find FLoP at
Maybe this is an option for you...
More information about the Snort-devel