Configuration Policy Functionality

Author
Terry Slattery
Principal Architect

I’ve been working with several network configuration management systems recently and have run into some surprising deficiencies.  Let’s start by looking at the set of necessary functions.

Device grouping is essential.  The administrator needs to be able to specify group membership by different criteria, including device names or by IP addresses.  A useful addition is to be able to group devices by configuration contents.  For example, you may want to identify all the routers that have the commands ‘ntp peer‘ in their configurations (as contrasted with ‘ntp server‘).

The grouping mechanisms should allow boolean operations on the criteria.  For example, I may want to specify all devices whose name contains ‘core-rtr’ except for the routers that have IP addresses 10.1.1.1 or 10.2.1.1.  For example:

sysName contains 'core-rtr' AND NOT (10.1.1.1 OR 10.2.1.1)

Another useful function is the ability to group devices by configuration contents.  Lets say that you wanted to identify the group of provider routers in an MPLS network.  These routers would not contain any MPLS configuration statements.  This grouping could be done with the following:

deviceType == 'router' AND NOT (configuration contains 'mpls')

Another configuration contents example is keying off the IP address of any interface on the device, versus the management IP address of the device (most management systems don’t look at all addresses – they tend to key off the management IP address only).

The other function involves configuration policy checking.  Obviously, it is useful to identify configurations that are missing important statements.  For example, the AAA configuration in a router or switch.  But what about configurations that contain undesirable statements, like an extra username command, or a second snmp RW community string, both of which create ‘backdoors’ into the device?  The configuration policy checking mechanism needs a way to identify these extra commands.

Back to the surprising deficiencies in the products I’ve evaluated.  In the first product, it couldn’t create a device group that included all devices except two.  I was building a check for NTP and wanted to include all the routers and switches except the two that were talking to Stratum 1 clock sources.  The boolean logic didn’t include the NOT function that I needed to exclude the two devices by sysName.  The workaround was to suppress the alerts on those two devices for that policy.

The other product couldn’t identify configurations that had extraneous username statements beyond the two that were permitted in the configuration.  The lack of ability to identify back door security holes knocked it out of contention in my evaluation.

I think that both of these deficiencies have a common cause.  The developers have never run networks before and don’t think of all the logic that is needed to do proper configuration policy validation.  Perhaps through this blog and making people aware of the requirement, we can get vendors to provide the needed functionality.

-Terry

_____________________________________________________________________________________________

Re-posted with Permission 

NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html

infoblox-logo

Leave a Reply