Re: mysql schema & multiple snort versions & sensors

[Erek Adams <erek () theadamsfamily net>]

[Warning, last little bit is a bit lengthy...]

On Wed, 3 Apr 2002, Phil Lyons wrote:

> I have multiple snort sensors.  They are running 1.8.1.  Now I would like to
> add 1.8.3 snort on the next group of sensors.

If you hang on a little bit, you can go to 1.8.5.  :)  Lotsa little annoyances
fixed...

> Is the mysql DB schema backward compatible?

Some are.  In 104 -> 105 is was only the schema version number. :)

> Or am I best off migrating all sensors to one release of snort, and
> synchronizing with the mysql version?  (I believe Erek recommended rdist for
> such snort distributions ).

See below...

> Also, is it recommended to keep the OS hosting these sensors on the same
> release as well?  Currently I have Red Hat 7.0, moving to 7.2

You have my deepest sympathies.

> Apologies in advance if the schema question has been asked before - I
> haven't been able to find it in my deja searches.  And as this environment
> grows, I am searching for better ways to manage it.

Management of _any_ sort of large scale architechture can be a pain for the
admin.

Let suspend reality for a moment.  We're going to build a "perfect world"
where everthing is automagical.  Now, my perfect world may not be like your
ideas, but it works for me...  :)

1)  We've got all the same boxes for each sensor.
2)  We've got the same OS and patches on each sensor.
3)  We've got the boxes configured identically.
4)  Each box has 2 disks.  One for the OS, laid out in whatever standard
fashion you wish.  The second will be for "what's special about this box".  I
tend to use /local.

With those factors, we've now got 'throw away' boxes.  If a box dies for some
reason, build another and remove the /local disk and put it in the new
machine, you're back up where you were in a matter of minutes instead of
days/hours.

You also need three other boxes:  One 'test box', one 'build box', and one
'sync box'.  TestBox should be used for that.  Try and upgrade the OS with
your configs.  See if it breaks.  Try new versions of snort.  Whatever...
It's for _testing_.  BuildBox is where you actually get into the edge of your
production setup.  It should be the box that the binaries get built on (No
compiler on your sensors...), where all the tweaks and config changes are
made.  SyncBox (No, it's not the newest 'boy band' ;-) should be never
touched.  Anyone who touches it should be flogged.  It's kinda like "The One
Ring", binding all your other sensors.  SyncBox _must_ be backedup reguarly.
Once something passes TestBox, then works out ok on BuildBox, it's ready to be
placed on SyncBox.  Then via some automation scripts and ssh, use rsync over
ssh to sync up your sensors to the sync box.  That way you can build and test
in a private area, then sync your production to the private area as needed.
If for some reason, you have to roll back the whole sensor net, use the
backups to restore SyncBox and then resync.  One sensor dies?  Either replace
the whole box and sync it, or repair the disk, then sync.

And yes, you can setup things like this.  I've done it before in another life.
:)  It makes management of large scale stuff so much easier!

Hope that helps!

-----
Erek Adams
Nifty-Type-Guy
TheAdamsFamily.Net


_______________________________________________
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