Snort mailing list archives
Re: Snort/Barnyard2 performance with remote DB
From: Jason Haar <Jason_Haar () trimble com>
Date: Thu, 01 Mar 2012 10:47:47 +1300
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 delay too. 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). -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users Please visit http://blog.snort.org to stay current on all the latest Snort news!
Current thread:
- Re: Snort/Barnyard2 performance with remote DB, (continued)
- Re: Snort/Barnyard2 performance with remote DB Martin Holste (Feb 27)
- Re: Snort/Barnyard2 performance with remote DB turki (Feb 27)
- Re: Snort/Barnyard2 performance with remote DB Martin Holste (Feb 27)
- Re: Snort/Barnyard2 performance with remote DB Jan Seidl (Feb 27)
- Re: Snort/Barnyard2 performance with remote DB beenph (Feb 27)
- Re: Snort/Barnyard2 performance with remote DB turki (Feb 28)
- Re: Snort/Barnyard2 performance with remote DB Martin Holste (Feb 27)
- Re: Snort/Barnyard2 performance with remote DB Jan Seidl (Feb 27)
- Re: Snort/Barnyard2 performance with remote DB beenph (Feb 28)
- Re: Snort/Barnyard2 performance with remote DB Mike Lococo (Feb 29)
- Re: Snort/Barnyard2 performance with remote DB Jason Haar (Feb 29)
- Re: Snort/Barnyard2 performance with remote DB turki (Feb 29)
- Re: Snort/Barnyard2 performance with remote DB Jason Haar (Feb 29)
- Re: Snort/Barnyard2 performance with remote DB beenph (Feb 29)
- Re: Snort/Barnyard2 performance with remote DB beenph (Feb 29)
- Re: Snort/Barnyard2 performance with remote DB Jason Haar (Feb 29)
- Re: Snort/Barnyard2 performance with remote DB beenph (Feb 29)