Building Configuration Policy Checks, Part 1

Author
Terry Slattery
Principal Architect

I’m building configuration policy checks for a customer and realized that it would be beneficial to share the design choices and implementation details that I encountered. The tool that I used is NetMRI’s Configuration Policy, but the same thing would work for other tools that have similar configuration policy mechanisms.

This customer recently implemented a new Cisco ACS server and new AAA configurations needed to be installed in all the network devices. We were able to use NetMRI to determine if there were any devices that did not have the new configurations installed by checking for the contents of a new banner that was applied at the same time. That was pretty easy, but it didn’t validate that the configurations were actually correct. The update process was manual and even though they used cut-and-paste, there was still a chance of error. So we built a configuration policy to verify that the correct configuration existed.

There are several significant benefits from performing configuration policy checking.

  • It assures configuration consistency across the network. Consistent configurations allow you to more easily perform updates because you know what exists in the current configurations.
  • With the same configurations, there are fewer problems due to inconsistency. A difference in a QoS policy, for example, might cause important traffic to be improperly classified and marked, resulting in undesirable prioritization of certain traffic. The affected traffic may not be the improperly classified traffic – a large volume of improperly classified traffic could impact the flow of more important traffic.
  • Consistent policies increase network security. The policy in this case, the AAA configuration, has security implications. The stated policy is that all changes are to be tracked in the ACS server so that there is an audit log of network changes and who made them. It is critical that all network devices receive an authorization confirmation from ACS before allowing a network administrator to change a configuration and to log the specifics of the change.

When configuring network policies, I find that it makes sense to start with a policy written in sentences. This establishes intent, which is not communicated in the policies themselves. For example, the AAA policy says:

All configuration commands must be authorized and logged in the ACS server so that an audit trail of configuration changes is created.

This policy results in a specific set of AAA commands that we verify are contained within all the network devices. Automating the configuration command check makes sure that any exceptions are noted when they occur. Any future change that isn’t consistent with the policy is identified and an alert regarding the exception is created.

Consistent configuration policies can also reduce troubleshooting time. Let’s look at a policy for edge ports.

Configure edge ports with portfast, auto/auto for speed/duplex setting, bpdu-guard, and error-disable timeout set to 90 seconds.

If non-edge ports are identified with tags (see my post on Device and Interface Tagging), then any port that’s not tagged is an edge port and should be configured as such. I recently found a pair of edge interfaces on a switch where someone had “cleaned up” the cabling in a room by plugging the dangling end of a cable into another wall jack. This created a loop, but fortunately, one of the ports went into the blocking state instead of creating a spanning tree loop. A better configuration would have been for the ports to go into the err-disable state with a timer specified to re-enable the ports when the cabling error is corrected. In the above case, a field technician had to be dispatched to solve the cabling problem when it would have been better to have the switch disable the ports and just ignore the cabling error. The customers in the area would have eventually corrected the problem when connectivity was eventually needed. Duplex mismatches and native vlan mismatches also come to mind as examples where a consistent configuration avoids problems that require troubleshooting.

In the next post, I’ll talk about building configuration policy rules from the written policies.

-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

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.