Snort mailing list archives
Re: v2.8.4 incorrect logging to MySQL
From: Martin Roesch <roesch () sourcefire com>
Date: Tue, 14 Apr 2009 16:39:26 -0400
Loyal Moses: Sourcefire is limited on man power as is any organization that has limited supplies of time and money. Sourcefire does not use the spo_database plugin AT ALL in our commercial products because they impart unacceptable performance overhead into the product. We use the Unified2 logging infrastructure and our own log spooling system in the commercial products. The spo_database code was developed and supported by external contributors to the project back in the early 2000's who abandoned it and left it for us and the community to maintain. The biggest support item on the mailing list from the open source users for many years now has been the database plugin because it's complexity is so high. To my mind it makes a lot of sense to reduce the complexity of Snort configuration and improve the worst case performance of Snort by removing any code that's a constant maintenance headache and that doesn't relate to the core functionality of network traffic inspection. Less lines of code = less bugs = less security issues = less code audit = faster time to release code. In the limited number of hours that we have to write code I'd rather spend that time improving the detection capabilities and performance of Snort than maintaining a zoo of output plugins. If you've noticed, database connectivity isn't in the Snort 3.0 architecture (e.g. SnortSP Beta 3) at all, nor will it be in the distribution tarball. If someone wants to maintain an external patch to the system that's fine but there's no reason to put it in the distribution code base. That's MY call and I think it's a good one for the reasons I listed above. Using an external data spooler like Barnyard/Barnyard2/SnortUnified.pm is a better way because it maximizes the performance of Snort while lowering its runtime configuration and code complexity. You have the additional step of maintaining the spool directories but the complexity is moved out of Snort which is a win in my opinion. Jack Pepper: I believe the latency between detection and spooling to a database using the unified/Barnyard method is preferable to losing packets and missing detections altogether using the direct-to-database method. We use Unified2 here at Sourcefire for our commercial devices. Paul Schmehl: Now that Barnyard2 is available and being actively maintained I would consider Barnyard to be deprecated. There is no active development going on around Barnyard nor will there be unless someone can talk Andrew into doing some work on it. Given that the Barnyard2 group is active and motivated I would favor that route. Barnyard2 isn't "officially supported" but I think it's the better route to take ultimately. Danny Paul: I'd be interested to see your data around that, we haven't seen that sort of thing here but we use a different database schema and spooling infrastructure. Marty On Tue, Apr 14, 2009 at 3:35 PM, Loyal A Moses <loyalmoses () mac com> wrote:
Is Sourcefire limited on development skill or man power? It makes no sense at all to remove one of the most common facilities in use by snort users because it is "too complex". In the end, you'll do what you are going to do regardless of the community -- we've seen it before. But don't use "complexity" and "bugs" as the excuse. Sourcefire is a publicly traded company -- Is it smart to be taking votes on product development from a mailing list? I wouldn't think so. Loyal. On Apr 14, 2009, at 11:52 AM, Jason Brvenik wrote:I have an ulterior motive and it is simple. Many of the bugs and issues over time with snort have been in output plugins. Make one well supported, tested, unified method designed for best performance and while doing so it improves the supportability and maintainability of the code base. On Tue, Apr 14, 2009 at 2:39 PM, Loyal A Moses <loyalmoses () mac com> wrote:My vote is to provide as many output options as possible, to help keep snort used as a tool. The argument of code complexity being a good reason to remove output facilities is only valid if the code is written poorly and not modular. This wheel doesn't need re-invented and this conversation is kind of silly, unless there is ulterior motives for actually wanting to remove this support. Loyal. ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ 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------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ 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
-- Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616 Sourcefire - Security for the Real World - http://www.sourcefire.com Snort: Open Source IDP - http://www.snort.org ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ 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
Current thread:
- Re: open source vs. GPL, (continued)
- Re: open source vs. GPL Martin Roesch (Apr 14)
- Re: v2.8.4 incorrect logging to MySQL Paul Schmehl (Apr 14)
- Re: v2.8.4 incorrect logging to MySQL Loyal A Moses (Apr 14)
- Re: v2.8.4 incorrect logging to MySQL Martin Roesch (Apr 14)
- Re: v2.8.4 incorrect logging to MySQL Paul Schmehl (Apr 14)
- Re: v2.8.4 incorrect logging to MySQL Shirk Dog (Apr 14)
- Re: v2.8.4 incorrect logging to MySQL Randal T. Rioux (Apr 14)
- Message not available
- Re: v2.8.4 incorrect logging to MySQL Shirk Dog (Apr 14)
- Re: v2.8.4 incorrect logging to MySQL Alan Shimel (Apr 14)
- Re: v2.8.4 incorrect logging to MySQL Matt Watchinski (Apr 14)
- Re: v2.8.4 incorrect logging to MySQL Martin Roesch (Apr 14)
- Re: v2.8.4 incorrect logging to MySQL Jack Pepper (Apr 14)
- Re: v2.8.4 incorrect logging to MySQL Martin Roesch (Apr 14)