[Snort-users] Snort/Barnyard2 performance with remote DB
Jason_Haar at ...15306...
Wed Feb 29 16:47:47 EST 2012
On 01/03/12 04:25, Mike Lococo wrote:
> A factor of 10 doesn't make a meaningful difference for me. For local
> DB's with lan latency, barnyard2 is already plenty fast for my use.
> For remote DB's with 200ms of latency to be feasible I'd need to see a
> factor of 100 improvement (remember we're starting from ~1 alert/sec
> for a link with over 200ms latency).
This is a great topic, as lately I've been thinking about centralizing
our world-wide SQL databases and this issue with latency will kill us.
How about this as a feature request? Get snort to rotate unified output
files after either a time or size threshold (like daemonlogger does),
and then use rsync to move those closed files to a central server, where
barnyard can then move them into the DB? Certainly not realtime anymore
- but if you are talking about centralizing high-latency separated
sensors into a single DB, I think we can safely say realtime isn't a
primary motivator anymore... Tricks with dnotify/etc could minimize the
Actually, this could all be treated as a barnyard feature request?i.e. a
new output option for barnyard - unique filenames that another process
(rsync loop) manages. This would have the advantage that the local
barnyard could still do the realtime syslog alerting - it would just be
the DB entries that would lag...?
Hmmm, barnyard2 already has a tcpdump output option - could all this be
done with existing code? i.e. the "leaf node" barnyard2 does the syslog
and tcpdump output, we rsync the tcpdump files to the central server,
*somehow* turn them back into unified2 format and the central barnyard2
pushes them in (with the original sensor names of course).
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
More information about the Snort-users