Policies are used to verify network device configurations and to enforce consistency of configurations across the network. NetMRI can perform analysis when it detects device configuration changes, or on an ad hoc basis for past, present or future configuration files. Policies drive a key feature of NetMRI— called Policy Compliance.
A configuration Policy consists of one or more rules. Rules use different forms of XML-based regular expression pattern matching against configuration files — and tests of other data NetMRI has collected — to verify that the configuration of the device meets the rule(s). Each rule has a severity level, and can define a device filter to limit the types of devices to which it applies. You may freely re-use rules in different policies.
NetMRI provides a library containing numerous pre-packaged policies. As an example, DISA policies provide the top-level overview of the network's adherence to security and network infrastructure mandates from the Department of Defense. Because networks managed by NetMRI are normally enterprise or data center, Defense Information Systems Agency (DISA)-based Policy Compliance is advisory in nature; DISA guidelines provide a baseline framework for establishing a secure network. NetMRI bases many policies upon published DISA implementation guides. Other policy sets include the use of PCI 3.0 rules to help NetMRI users in commercial businesses to support a baseline of technical and operational security requirements for payment card transactions.
The main vehicle for creating and maintaining Policies is called the Policy Design Center.
...
Policies are defined in the Policy Design Center, then deployed against specific device groups. As NetMRI collects configuration files, SNMP data and other data from devices, it validates through policies deployed against devices for which configuration changes are detected.
Results of policy-based analysis are listed in the Network Analysis –> Policy Compliance tab.
Policy analysis results are also available in two reports:
- The Policy Compliance Summary report provides an overview of the compliance status for all policies and the network devices against which they are deployed.
- The Policy Compliance Details report lists all policies and policy rules, with the devices passing and failing, and the specific reasons for policy violations.
...
Note: Although only the last running configuration collected from each network device is analyzed during routine policy checks, you can perform an ad hoc analysis of any archived configuration file (or even a future configuration file) for a device by using the test function at Config Management –> Policy Design Center side tab –> Policies.
...
NetMRI provides a set of sample policies for developing new policies based on organization, industry or government best practice guidelines or from local expertise. In all cases, you can refine the templates to suit your deployment.
The sample policies are read-only. This prevents any changes you make from being lost when Infoblox releases newer policy versions. Before making changes, copy policies or rules using the Copy button, then modify the copy. When you copy a policy, it still references the same rules as the original policy (copying a policy doesn't copy the rules it references). This allows you to copy the policy, then change only those rules that require them, or add new ones.
...
If you wish to create custom rules, you can use different methods of editing to create them. You can use graphical blocks of rule logic to perform mixing-and-matching of rule components, or define rules through a full XML code editor backed by a dedicated XML schema. All rules are based on defining the device configuration strings, or entire sections of device configurations, that the rule will match against to perform policy operations.
Four rule editors are provided in the Rules tab:
...
Once you save a new rule, and it was not created in the Raw XML Editor, you can change the rule's editor to the Raw XML Editor. If you create a rule from, for example, the Rule Logic Builder, will see the XML generated by the previous rule editor when you open it in the Raw XML editor. The reverse is not true: If you create a new rule in the Raw XML Editor, and decide to open it in another editor type, the results will not be the same and changes will be lost, because XML code is likely to differ from the output of the other editor types.
You can gain a better understanding of how to formulate rules by examining the example rules included with your appliance.
...
/^banner motd my banner/i
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
Matches
| Anchor | ||||
|---|---|---|---|---|
|
...
For the most part, config file matches look almost exactly like configuration commands, with the possible use of wildcards and regular expressions instead of hard-coded arguments. For example, the following config file match specifies an exact match that requires a specific ACL command to be included in the configuration file:
...
The regular expression shown above matches more than just “10.76.4.x” because the “.” is a special symbol that matches any single character. In practice, this expression will still match what you want it to match because only dotted decimal notation will appear in this rule.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
Terms
| Anchor | ||||
|---|---|---|---|---|
|
...
Each of the arguments (or tokens) defined in a given config file match can be either a fixed value (e.g., “10”) or a wildcard term (e.g., “[0-9]+”) to match multiple values. By combining multiple wildcard terms in the same config file match, very powerful (and sometimes complex) expressions can be specified. For example, consider the following config file match:
...
indicates that every interface, regardless of type, must have a defined interface description.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
You use the Rules tab (Config Management –> Policy Design Center –> Rules tab) to create and manage rules that are referenced in policies. Policies cannot operate without at least one Rule. All factory-defined rules in this page are read-only. You can also define your own custom rules, using your choice of editing tools.
Rules provide substantial extensions in capabilities for XML rule creation. For more information, see the following subsection, Policy Rule XML Capabilities.
Rule editing features are enabled only when creating a new rule. All other Rules are read-only and can be used only to create new Rules.
Rules are the critical element in building all Policies. To build Rules effectively, Infoblox recommends detailed knowledge of the given networking technologies or protocols involved in defining the rule.
Also see Additional Rule Examples for information showing how rules appear in practice.
...
<Expr op='concat'> <Expr value='First'> </Expr> result value <First> <Expr value='Second'> </Expr> result value <Second> </Expr> result value <FirstSecond>
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
Policies
| Anchor | ||||
|---|---|---|---|---|
|
...
Build and test policies in the Policies tab (Config Management tab –> Policy Design Center side tab –> Policies tab).
...
Policies can be tested against devices within device groups, against device attributes and against a configuration file, and tested against a template. New policies can also be written in XML format and then imported into the NetMRI Policy system.
To test a policy, do the following:
- In the Policies panel, select the policy to be tested.
- Click Test Policy in the lower right corner. The Test Policy dialog appears.
- In the Test Policy dialog, select a corresponding tab to specify what you want to test against:. See the following procedures for each test tab.
- Click Test. Results appear in the pop-up Test Results window.
To test against a device group:
...
- Click the Test Against Template tab.
- Select the template you want to test against.Click the Test button. Results appear in the pop-up Test Results window.
Importing and Exporting Policies
You can import policy XML files (as generated by exporting a policy) or legacy NetMRI CPD files. The latter is automatically converted to the newer format.
To import a Policy file, do the following:
...
- In the Policies panel, select the policy you want to print.
- Click Print in the upper left corner.
- In the Print dialog, specify print parameters, then click the Print button.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
Policies
| Anchor | ||||
|---|---|---|---|---|
|
...
Deploy policies in the Policy Deployment tab (Config Management –> Policy Design Center side tab –> Policy Deployment tab). In this tab, you associate policies with device groups (or vice versa). Policy deployments remain in effect until they are deactivated.
To specify a policy and deploy it against selected device groups:
...
- Minimum password length: enforced to be at least 7 characters long.
- Password strength: Password should contain numeric and alphabetic characters or password strength validation should be enabled
- Disabled Small TCP and Small UDP services
- Disabled Finger, BOOTP, and Identd services on Cisco IOS devices
- Disabled CDP, HTTP, NTP on Cisco IOS and Cisco Nexus devices
Exec-timeouton console port and on VTY port should be set to 15 minutes or less on IOS and Nexus- Enable login on console port;
- Allow Enable passwords on console port;
- Two factor authorization is activated;
- Enable Logging timestamp;
- Disable MOP on all Ethernet interfaces;
- Disable Packet assembler/disassembler (PAD) on X.25 links on IOS.
- Disable configuration autoloading for IOS devices;
- Disable source routing on IOS and Nexus;
- Inbound access class should be set on VTY ports;
- SSH only transport should be set on VTY ports for IOS;
- AAA authentication should be enabled for VTY ports on IOS;
- Secrets should be used for local users on IOS and Nexus;
- SNMP v1 and v2c should be disabled on IOS and Nexus.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
Examples
| Anchor | ||||
|---|---|---|---|---|
|
...
With some practice, rules can be written by anyone experienced with the underlying configuration files being analyzed. This topic presents several examples of relatively simple, yet effective rules that ensure consistency and correctness across a range of devices.
...
For Rules in the Policy Design Center, simply use a comma-separated format.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
Builder
| Anchor | ||||
|---|---|---|---|---|
|
...
The Rule Logic Builder provides an environment for creating rules by combining config file matches with logic to produce a result when the rule executes. Rule Logic consists of two primary building blocks:
...
At the top of the Rule Logic Builder panel, you see an Enforce This Rule field. Here, you use Boolean AND and OR operators to enforce the logic trail employed by the rule. For example, consider a rule that has three elements: two Config File Matches and a device attribute as the third element.
You enter Config File Matches and Device Attributes one at a time, in any order, in the logic builder. You cannot rearrange them after they are added to the block list; each block provides an Action menu through which you edit or delete each block.
To create a new rule using the Rule Logic Builder:
...
Note: When creating a rule to evaluate a block of config in a specified order, note that the “all of these lines in specified order” logic implies that each line is present and in that order, and there can be other lines in between. In this case the rule passes. If you do not want to allow other lines in between, use the “Contains This BLOCK” option. Also, in both the “Config File Must Contain” and “Config File May Not Contain” sections, each entered line is considered a regular expression to be matched against the configuration file. If you select one of the BLOCK options, the entire content of the field is considered a regular expression.
...
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
Editor
| Anchor | ||||
|---|---|---|---|---|
|
...
As its name implies, the Simple Rule Editor provides an easy way to create and edit rules. It establishes a structure in which you can easily add config file matches corresponding to specific configuration commands.
In the Simple Rule Editor, a rule may consist of one or both of the following sections:
...
Note: When creating a rule to evaluate a block of config in a specified order, note that the “all of these lines in specified order” logic implies that each line is present and in that order, and there can be other lines in between. In this case the rule passes. If you do not want to allow other lines in between, use the “Contains This BLOCK” option. Also, in both the “Config File Must Contain” and “Config File May Not Contain” sections, each entered line is considered a regular expression to be matched against the configuration file. If you select one of the BLOCK options, the entire content of the field is considered a regular expression.
...
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
Editor
| Anchor | ||||
|---|---|---|---|---|
|
...
...
Note: Infoblox recommends using alternative editing methods for creating new policy rules. The CPD editor is provided for compatibility with older releases of NetMRI.
...