[Snort-users] Distributed Snort management

Michael L. Artz dragon at ...8731...
Wed May 21 20:53:09 EDT 2003


Haven't actually tried it myself, but I have heard good things about 
prelude (prelude-ids.org).  There is even a patch for snort to have it 
integrate directly with libprelude.  Prelude has the notion of multiple 
levels of "managers", which function to both collect and relay events 
via ssl-ed binary IDMEF.  I believe that there is also some decent 
failover support through the use of local storage until the network 
connection becomes available.  An additional draw is the ability to 
integrate other types of sensors/logs through the use of prelude-LML, 
which can function as either a syslog consumer or a local log-scraper agent.

Like I said, I haven't actually played around with it in a production 
environment, but I would be interested to hear what others have to say 
about it.

-Mike

Nelson, Ben wrote:

>I have many snort sensors that are distributed across large geographic boundaries.  Maintaining and monitoring these installations is starting to become trouble-some.  I have started using SnortCenter to manage and push out rules (which is working great BTW), but I need to figure out a good way to centralize the data and alerts that Snort comes up with.
>
>At first I thought that I could just make all of the sensors log to a centralized MySQL server (all logging to the same database) over stunnel or something like that, but what if a sensor loses connectivity to the MySQL server?  I'd lose all of the alerts generated during that time frame(I guess I could log them to flat files on disk as well, but that would defeat the purpose of using a database...no?)  
>
>Then I though maybe I could set up TWO output directives to log all alerts to two separate databases (one local to the sensor and the remote one), but then re-synchronizing the sensor's database to the main MySQL server becomes a problem when connectivity is re-established.  
>
>I could also just use MySQL's built in replication (over stunnel again).  That would solve my problem of re-synchronizing databases when connectivity came back (MySQL handles all of that), but then I'd have to have a separate database for each sensor since MySQL doesn't support replication of multiple masters to a single slave (does any database supported by snort do this?).  Ideally, I'd like to have all alerts from all sensors go into the SAME database.
>
>Is anyone else in a similar situation?  What did you do to centralize your alerts?  I'm really open to suggestions......having ACID loaded onto EVERY sensor seems like a waste (not to mention a pain to check regularly).
>
>Thanks,
>--Ben
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>Snort-users mailing list
>Snort-users at 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=ort-users
>  
>






More information about the Snort-users mailing list