Re: Distributed Snort management

[Richard DeYoung <webmaster () verticept com>]

Ben,
Just a few suggestions....read below.


On Wed, 2003-05-21 at 21:15, 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, 
        I'm currently running with multiple sensors, geographically 
        distributed across various sections of the country and all
        sending alerts via an SSL tunnel back to the MySQL database. I
        don't yet have any need to provide an additional layer of
        redundancy by incorporating a MySQL instance in proximity to
        each sensor, but I am considering "tacking up" and instance to
        provide convergence for a few (two or three) sensors in each
        part of the country. 

    but what if a sensor loses connectivity to the MySQL server?  
       Then either your sensor traffic routing pathways need to be
       reconfigured in your network topology *or* you can look
       at implementing a MySQL instance as I mentioned above. If
       reconfiguring isn't feasible (due to political issues, or 
       other factors beyond your control), then the second option may
       provide more of what you're looking to achieve.
          In other words, you'll need to run a quick risk assessment,
       taking into account such things as 
             1) How often do you lose network connectivity to various
                part of your network topology?, 
             2) What are your organizations requirements with 
                regard to real-time and historical data analysis? and 
             3) How much latitude are you being given in how and where
                you're going to be able to place your sensors and
                databases?

    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?)  
    You may lose alerts for that time frame but depending on how you
    how you've configured your portscan preprocessors, you should
    still be able to monitor some of what's happening on your network.

     If you go with logging to two separate outputs, you'll want to
     look at implementing barnyard to help with the back-end MySQL   
     processing.
    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).  
          Sounds like a great idea. I understand that MySQL v4.x
          natively supports SSL connections but I haven't had the time
          to run any tests in my current environment.
    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.....

           I'm attaching two scripts I use to help setup my stunnel
           tunnels, along with a "readme". HTH.
    .having ACID loaded onto EVERY sensor seems like a waste (not to
    mention a pain to check regularly).
           Not to mention the application and network security
           configurations that go along with that kind of setup ;-)

           Thanks,
           R. DeYoung
           webmaster at verticept dot com

Attachment: stunnel
Description:

Attachment: stunnel_readme.txt
Description:

Attachment: init_d_stunnel
Description: