Re: Network config monitoring and auditing software

[Kevin Halgren <kevin.halgren () WASHBURN EDU>]

Justin,

 Thanks for your thoughtful response.  I think you really hit the nail
on the head here regarding the "why" issue.  I have a number of options
to do further research into now, I'll let everyone know what we come up
with.

 Thanks all for your input.

Kevin

Justin Azoff wrote:
> On Mon, Sep 14, 2009 at 01:50:24PM -0500, Kevin Halgren wrote:
>
> > We're looking at software to help with monitoring and auditing changes
> > to firewall and switch configurations.
>
> Two things to look for/pitfalls to avoid...
>
> I built a simple system for this a few years ago.  At first it worked
> somewhat like RANCID: configs were pulled down, superfluous changes were
> removed, and the files were commited to CVS(later SVN).
>
> This worked fine for about a year, but then I started noticing some problems:
> * svn log/svn blame output was useless.  You could tell when something changed,
>   and maybe who changed it, but not *why*.
> * Whenever multiple devices were changed around the same time for unrelated
>   issues, it wasn't possible to tell which of the changes went together.
>
> thus, thing to look for #1: The ability to not only keep track of configuration
> changes, but to be able to group them together and comment on why the change was made.
>
> The current system uses a simple web frontend to svn diff/svn commit that lets
> someone in our group select the recent changes and commit them, optionally
> entering a trouble ticket number to send the resulting diff too.  This makes it
> possible to go from 'svn log' to a ticket, or from a ticket to the specific
> change.
>
> I think this is still an issue with something like RANCID, but it may be
> possible to combine it with something like 'Review Board'.
>
> Thing to look for #2: The ability to export the changes to another system.  In
> our system this is done automatically with post-commit hooks, but minimally if
> you can copy and paste a diff into a trouble ticket you should be covered.
> What you don't want is the configuration history locked in binary blob somewhere.
>
> Basically what I'm trying to say is that monitoring for configuration changes
> is the easy part, keeping track of the changes over time and relating them to
> trouble tickets is the hard part.  If whatever system you end up using does not
> have a way to annotate the changes as they are made, you will run into problems
> as soon as you need to find out why something was changed a year ago.

--
Kevin Halgren
Assistant Director - Systems and Network Services
Washburn University
(785) 670-2341
kevin.halgren () washburn edu