Snort mailing list archives
Re: v2.8.4 incorrect logging to MySQL
From: Jack Pepper <pepperjack () afferentsecurity com>
Date: Tue, 14 Apr 2009 22:44:42 -0500
Quoting Martin Roesch <roesch () sourcefire com>:
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.
Yeah, I don't use direct to DB either. My earier comments were just to say that for a guy who has been programming real time embedded systems for 30 years, unified is not my thing. not bad code, just not my cup of tea. As I tell the young guys who come here, "any time you think loop polling for data sounds like a good idea, you have made a design error." And using a flat file on a journaled file system as a spooling pipe is creepy. it looks like ketchup on ice cream. But that's just me. If you want a pipe, why not use a pipe? I happen to really like writing weird realtime multi-threaded apps with lots of IPC stuff embedded in them. For my own use, I wrote a distributed correlator system wherein the snort output method writes to a shared memory handle where an external (non snort) process was waiting on the mutex. then it goes though a massively parallel system of "escalator" daemons that have a separate system and configuration elements for each type of event escalation (SMS, DB, text-to-skype (via festival), email, Full-Alert-Logging, tcpdump, syslog, etc) and each type of criticality. It's my own beast and it works only as long as snort doesn't change the handoff from detect to output. At the end of the escalation tree, everything goes to a remote DB on a central system where it gets mined for possible nuggets. (The mining code does not work nearly as well as it sounds). BTW Marty: I have been a loyal snort user since 1.6 and I think that if you wrote the code then you have to answer only to yourself for what kind of licence you put on the code. You should do what works for you. thanks for snort. Snort has made IDS and IPS real objects and not just sales blather. The Snort community has much to be proud of as a model of how the open source community is supposed to work. If people disagree with your direction, they should start a fork. jp -- Framework? I don't need no stinking framework! ---------------------------------------------------------------- @fferent Security Labs: Isolate/Insulate/Innovate http://www.afferentsecurity.com ------------------------------------------------------------------------------ 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: v2.8.4 incorrect logging to MySQL, (continued)
- 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)