Cisco NAC Profiler Installation and Configuration Guide, Release 3.1.1
Using Advanced XML Rules
Downloads: This chapterpdf (PDF - 546.0KB) The complete bookPDF (PDF - 15.68MB) | Feedback

Using Advanced XML Rules

Table Of Contents

Using Advanced XML Rules

Overview

Why and when are Advanced XML rules necessary or recommended?

Endpoint Profiling using DHCP Options & Requested Option List Rules

Network Stack Information Rules

Advanced XML Rule Creation via the Advanced Rule Editor (ARE)

Nesting Logical Operators using the ARE

Traffic Rule Creation Using the ARE

Active Directory Domain (Distinguished) Name Creation Using the ARE

Advanced XML Rules in Depth

Profile Rule XML Syntax

Advanced Rule Structure and Syntax

Special Consideration for the Use of Web URL Rules Within Advanced Rules

More Advanced XML Rule Examples

The Cisco NAC Profiler Profile Rule Document Type Definition (DTD)


Using Advanced XML Rules


This chapter contains the following topics:

Overview

Advanced XML Rule Creation via the Advanced Rule Editor (ARE)

Advanced XML Rules in Depth

More Advanced XML Rule Examples

The Cisco NAC Profiler Profile Rule Document Type Definition (DTD)

Overview

Chapter 9, "Endpoint Profile Configuration: Part 1" and Chapter 10, "Endpoint Profile Configuration: Part 2" outlined rule creation through the UI and outlined the procedures for the configuration of most of the rule types. This chapter outlines the Advanced XML Rule option and procedures for the configuration of Advanced XML rules within Endpoint Profiles.

The Advanced XML Rule is not a rule type per se, rather it provides an alternative approach to the configuration of Endpoint Profile rules unlocking access to more advanced profile rule creation techniques, as well as providing the ability to utilize the three profile rule types listed earlier that are not currently accessible through the UI Profile create/edit forms.

The Advanced XML rule creation process allows access to any and all of the rule types, and allows the use of the logical operators AND, OR and NOT within compound rules using multiple rules and multiple rule types within a single advanced rule and a single Certainty Factor.

Why and when are Advanced XML rules necessary or recommended?

For many Cisco NAC Profiler systems, Profile creation and tuning can be accomplished through the procedure outlined in Chapter 9, "Endpoint Profile Configuration: Part 1" and Chapter 10, "Endpoint Profile Configuration: Part 2".

Endpoint Profiles with single and multiple rules added using the Add Rule options on the Save Profile form can be created/modified that are capable of providing the endpoint profiling and identity monitoring functions on most enterprise networks.

As the name suggests the usage of Advanced XML rules is typically reserved for advanced Cisco NAC Profiler administrators that need access to the logical operators, OR, AND, NOT when the desire or need exists to combine multiple logical blocks in a single profile rule, or to access the rule types that cannot be configured via the existing profile configuration forms: DHCP Option, DHCP Requested Option, and Network Stack Information Rules.Before going into the mechanics of Advanced XML rules, the three rule types accessible only via Advanced XML Rules are described.

Endpoint Profiling using DHCP Options & Requested Option List Rules

Most DHCP packets sent by endpoints will contain a list of DHCP options as defined in RFC 2132 and supported by the client implementation running on the endpoint sending the packet. In many cases, the DHCP option list for endpoints of a particular type is consistent, and particularly when combined with other attributes can be a reliable indicator of endpoint identity. The DHCP Option list rule enables Cisco NAC Profiler to Profile endpoints based on observing their DHCP packets and matching the list of options in the packet to the list specified in the rule to identify endpoints.

Within the DHCP options that may be in a specific option, option 55, that is itself another list of DHCP options (see paragraph 9.8 of rfc 2132). This option is used by a DHCP client to request values for specified configuration parameters from the DHCP Server. The list of requested parameters is specified as n octets, where each octet is a valid DHCP option code as defined by rfc 2132. For some endpoints the list of requested options specified for option 55 can be another reliable indicator of endpoint identity dependent upon their uniqueness, particularly used with another attribute.

Therefore, when an endpoint sends a DHCP request that is analyzed by NetWatch with option 55 enabled, the system logs the list of requested options along with the list of all options the DHCP client on the endpoint supports. The DHCP Requested Option List rule is used to identify endpoints supporting option 55, based on the requested list of options. Later in this chapter, examples of DHCP Option List rules are provided for reference purposes.

Network Stack Information Rules

Network Stack Information rules can utilize attributes of the stack information displayed by an endpoint for the purposes of Profiling. When NetWatch observes network stack information for an endpoint, it adds the following stack-related information to the database for the endpoint: the TTL value, Window size, and TCP options. Network stack rules can be used to identify endpoints displaying specific values for these parameters.

Like TCP Open Ports, when Profiler is able to analyze endpoint traffic via NetWatch, it will also promiscuously collect the following stack information about each endpoint; the TTL, window size, and options list as displayed in the endpoints' network traffic. No specific collection needs to be configured for stack info to be collected by NetWatch. One very important difference however is that in order for Profiler to collect Network Stack Information for an endpoint, it must observe the endpoint establishing a TCP connection with another endpoint.


Note An important caveat regarding the TTL value collected by NetWatch as part of the stack data for endpoints: NetWatch will auto-adjust the TTL value observed in network traffic for an endpoint if the value is not divisible by 8. If the traffic from the endpoint has traversed one or more routers before being received on a monitor interface, this mechanism is designed to reset the TTL to the original value set by the stack on the endpoint itself. This is designed to prevent having to write rules using multiple values: <OR><... ttl="32".../><... ttl="31"...>...</OR>, etc. Eight was chosen as some standard TTLs are not always a power of 2. Some older systems use 48 and 60. Any TTL value observed in a packet >= 256 will be automatically reset to 255.


Network Stack Information is collected by NetWatch for endpoints by default from traffic received on a Collector NetWatch monitor port. To view Network Stack Information for an endpoint, click on the endpoint MAC address link in the UI to display the Endpoint Summary for the endpoint, then click on the View Profile Data. For endpoints that have had Network Stack Information collected by NetWatch, the Table of Other Data will include the following network stack information as illustrated in:

Time to Live (TTL) (in hops)

Window Size (in bytes)

Don't Fragment Bit setting (the number 0,1,2,or 3 shown in parentheses immediately after the Window size value)

TCP Options List

Figure 11-1 Viewing Network Stack Information for an Endpoint

Network Stack Information rules, at a minimum require the specification of a TCP Options List and TTL match to function correctly; the window size and DF bit setting are optional components. The TCP Stack and or Network Stack Info rule creation form of the Advanced Rule Editor indicates mandatory fields by highlighting the field in red as shown in Figure 11-2.

Figure 11-2 Create a TCP Stack or Network Stack Info Rule

To create a stack information rule that requires only a match of a specified TTL or Options List parameter, a Regular Expression that matches all can be specified for either of the minimum parameters.

For example to specify only a match of a specific TTL value, 64 in the example, the stack information rule would be created using the form shown in the figure.

Figure 11-3 Stack Rule Specifying Only TTL (Match All Options Lists)

The rule in Figure 11-3 would match any endpoint observed with Network Stack Information having a TTL equal to 64 hops, with any TCP Options list, Window Size or DF bit setting. Similarly, to match any endpoints having a specified TCP Option List, 2,1,1,4 in the example and any value in the other stack info parameters, the rule syntax would be as follows:

<StackRule list="/^2,1,1,4/" ttl="/.*/"/>

Advanced XML Rule Creation via the Advanced Rule Editor (ARE)

Previous to version 3.1 of Cisco NAC Profiler, creation of Advanced XML Rules within Endpoint Profiles required the creation of the entire XML rule within a free-form text editor. Although this method provides the ultimate in flexibility, it was non-intuitive and cumbersome for those not familiar with XML and the Profiler-specific profile rule syntax requirements. In version 3.1, the ability to edit most of the raw XML is maintained but is augmented with the Advanced Rule Editor (ARE) which automates some of the XML creation and assists the user in the creation of Advanced XML rules via a graphical user interface.

The addition of an Advanced Rule to an endpoint profile starts the ARE automatically. While viewing the Save Profile form, if the Add Profile selector drop-down is used to select Advanced and the Add Rule button is selected, the ARE opens automatically to allow the addition of an Advanced XML Rule to the Endpoint Profile currently being configured.

The Advance Rule Editor when used to create a new Advanced XML rule appears as illustrated inFigure 11-4.

Figure 11-4 Advanced Rule Editor: Creating a New Advanced XML Rule

Complete the following steps to create a new Advanced XML Rule using the ARE:


Step 1 Enter a name for the Advanced XML Rule in the Rule Name Field.

The Rule Name is used primarily for documentation of the Advanced XML Rule, so a name that describes the purpose and function of the rule is suggested.

Step 2 Assign a Certainty Factor for the advanced XML rule to be created. Note that the CF for Advanced XML Rules is discrete, and assigned to endpoints matching the entire rule (for example, for which the entire logic of the Advanced XML rule tests true.

Step 3 Select a Template for the Advanced XML Rule to be created, then select the Add button.

In order to assist with the creation of the Advanced XML Rule, several predefined templates have been created that automatically create the required Logical Block necessary for compound rules (for example, rules that test multiple sub rules according to specified logic). The templates available are as follows:

Must meet All Conditions - used to create compound rules that match endpoints that have identity attributes matching those specified for two or more parameters (for example, MAC address and DHCP Vendor Class Identifier). This template uses an AND logical operator on multiple rules of the same or different types specified by the user.

Must meet Any Condition - used to create compound rules that match endpoints having at least one identity attribute of a list of two or more. This template uses the OR logical operator on multiple rules (for example, endpoints that have a host address on one of the following subnets...) of the same or different types.

Must not meet all conditions - used to match endpoints that are known NOT to have ALL of one or more specified attributes.

Must not meet any conditions - used to match endpoints that are known NOT to have ANY of the specified attributes.

Upon selection of the desired template, the Diagram for the Rule is populated as illustrated in Figure 11-5.

Figure 11-5 ARE Showing Populated Rule Diagram: Must Meet All Conditions

Step 4 Complete the rule definitions in the logical block. For each rule in the block, complete the following sub-steps:

a. Double-click the rule or select the edit button at the end of the rule statement. This opens a new dialog (Figure 11-6) that allows for the selection of the desired rule type and entry of the required rule parameters.

Figure 11-6 Create/Edit Rule in Advanced Rule via ARE

b. Use the drop-down to change the rule-type for the rule from ''Undefined'' to the proper type or comment. All available Profiler rule types can be selected from the drop-down menu, or Comment may be selected to add text commands.

For rule types with single parameters (for example, a field for entry of the match parameter is provided). For rule types with multiple parameters (e.g. IP Address rule which requires an IP and Mask to be specified), the fields for required parameters are outlined in red on the form.

Select the Update button when required rule parameters have been added to the form.


Tip Several buttons are provided in the Diagram portion of the form. The X button allows the deletion of a selected rule. The Clone button adds another copy of the selected rule to the diagram. Rules can be clicked and dragged to other locations within the diagram. Clear All will remove the entire diagram, retaining only the Rule Name and Certainty for the advanced rule.


Step 5 Edit, add or delete remaining rules in the logic block as desired using the controls as required as described in Step 4 above.

Step 6 Use the Save button to save any changes made to the Advanced XML rule. The Save button can be used at any time after the Rule Name and Certainty fields have been completed.


Tip The Raw XML version of the rule can be viewed (and edited) by selecting the Edit Raw button.


Step 7 When the Advanced Rule has been completed, ensure latest changes have been saved, then select Close to return to the Save Profile form. A complete Advanced XML Rule is shown in Figure 11-7.

Figure 11-7 Completed Advanced XML Rule


Figure 11-8 shows an Endpoint Profile that has had an Advanced XML Rule saved to it. Note that the name of the Advanced Rule selected when created is shown.


Tip Version 3.1 of Cisco NAC Profiler also included a change to simplify the use of Traffic Rules in Advanced XML Rules. Traffic Rules in Advanced XML rules now contain a parameter "isSource" that allows the direction of the Traffic Rule to be captured in the XML allowing the automatic creation of the Collection rule. "Collection Rules" created in the UI to program NetMap/NetRelay for Specific Collection are no longer required for Traffic Rules in Advanced XML rules, they are only necessary for Web URL rules as of version 3.1. See Special Consideration for the Use of Web URL Rules Within Advanced Rules.


Figure 11-8 Endpoint Profile with Advanced XML Rule Added

Advanced XML rules added to an Endpoint Profile can be edited and removed in the same manner as other profile rules.

When Edit is selected, the ARE is re-opened to show the current configuration of the rule (see Figure 11-7 for an example). All the controls used for creating an Advanced Rule as described above in this section can be utilized to edit Advanced Rules.

Nesting Logical Operators using the ARE

The ARE allows for the creation of sophisticated advanced rules with "nested" logical operators. For example, if it was desirable to nest an OR block within a larger AND block, to perform pre-screening of traffic rule attributes as described later in this chapter, the following steps would be used to nest the OR block within the AND. The same technique is used when nesting any of the available logical operators is desired.


Step 1 If the top-level (AND in the example shown in Figure 11-9) operator is not currently in the diagram, click on the logical operator and drag it into the diagram at the desired position.


Tip The Advanced Rule construction can also begun with adding a Template to the diagram as described earlier.


Step 2 Click on the operator to be nested (OR in the example) and drag into diagram, placing the new operator on top of the existing one to indicate that it should be nested underneath.

Step 3 Mouse-over the nested-operator so that it is highlighted and use the Add Rule button to add rules to the nested block.


Tip Note that the logical operator itself can be edited by highlighting and clicking Edit. This provides access to the remaining logical operators beyond AND and OR.



Traffic Rule Creation Using the ARE

The Traffic Rule add/edit form within the ARE was modified in this release (3.1.1) to parallel the UI Traffic Rule creation form. Beginning with this version, adding a Traffic Rule to an Advanced XML rule is done via the form illustrated in Figure 11-9.

Figure 11-9 Adding Traffic Rules to Advanced XML Rules using the ARE

The proper use of each of these fields is described as follows:

IP Address

Allows the specification of an IP host address

Source/Destination Radio

Specifies that the IP address provided in the previous field will be the source or destination IP address in traffic of interest (i.e, traffic that potentially contains a match to the Traffic Rule.

Version 3.1 and later releases support selecting this radio button, which sets the "isSource" parameter used to create the Collection rule for the NetWatch and NetRelay modules system wide.

When the radio is set to `Destination' (isSource = 0), the modules are configured to Collect traffic(flows) that have the destination IP specified, or any destination if 0.0.0.0 is specified in the IP address field. Conversely, if the radio is set to `Source', the Collection rule specifies traffic with a source IP (or any) with the source or destination port specified further in the rule be collected.

Source Port/Destination Port

Further refines the rule by specifying that the traffic of interest will have either the specified Source or Destination port number (discrete port number only--not ranges). 0 in this field is interpreted as `any'.

noCollectionRule

This should only be checked when it is desirable to include "pre-screening" rules that are used only for modeling, not for collection of traffic. The use of the pre-screening technique with traffic rules is outlined later in this chapter.

Active Directory Domain (Distinguished) Name Creation Using the ARE

AD Domain Name rules can also be configured via the Advanced Rule Editor and used in Advanced XML Rules. In order to provided maximum flexibility however, the domain name field for the Advanced Rule Editor is not "post-processed" as it is for rules of these types added via the UI.

In the case of Advanced Rules, the distinguishedName field accepts either a string or Regular Expression that is defined to specify matches to Domain Names in the standard AD format, for example: DC=ad,DC=mysubdomain,DC=mydomain,DC=com, which is how the collected information is stored in the database. When creating/editing Active Directory Domain Name rules with the ARE, this format and or Regular Expression based on this format must be used when populating the distinguishedName field of the Active Directory Distinguished Name rule.

For example, to all computers that are members of a specific AD subdomain (such as mysubdomain) of mydomain.com (endpoints that have an FQDN at ad.mysubdomain.mydomain.com), the following would be entered in the distinguishedName field: DC=ad,DC=mysubdomain,DC=mydomain,DC=com. If computers that are members of ALL subdomains of mydomain, the following would be entered: DC=mydomain,DC=com.

Advanced XML Rules in Depth

The ARE introduced in version 3.1 of Cisco NAC Profiler provides a much improved user experience in the creation and maintenance of Endpoint Profiles employing Advanced XML Rules. In deployments where the use of Advanced XML rules is required or desired, the ARE will provide the majority of what is required to design, implement and maintain Advanced XML rules.

In the interest of completeness, the remaining information in this chapter provides a more indepth treatment of the syntax of Advanced XML rules for experienced NAC Profiler Users. Several examples of Advanced XML rules used in the past are provided, as well as the DTD which serves as a primary XML reference for profile rules.

Profile Rule XML Syntax

As mentioned previously, all the available Profile rule types are available for use in Advanced Rules. As illustrated in the examples later in this appendix, it is common to construct advanced rules that evaluate multiple endpoint attributes for matches. When using the ARE to construct individual rules within Advanced rules, the UI prompts the user for the required minimum parameters (outlined in red) and optional parameters of the rule.

Table 11-1 Rule Types and Example XML Syntax 

Profile Rule Type
Advanced XML Rule Example Syntax

MAC Address Rule

<Vendor vendor="/Cisco Systems/i"/>

IP Address Rule

<AddressRule ipaddr="192.168.208.208" 
mask="255.255.255.240"/>

Open TCP Port Rule

<PortRule port="9100"/>

Traffic Rule

<TrafficRule ipaddr="10.4.1.5" sport="0" dport="5000"/>

Web User Agent Rule

<WebClient banner="/SunOS/i"/>

Web URL Rule

<WebURL url="/yahoo/i"/>

Web Server Type

<WebServer banner="/IIS|Apache/"/>

SMTP Server Banner

<SMTPServer banner="ESMTP"/>

Network Stack Info

<StackRule list="/^2$/" ttl="32" window="8192" df="2"/>

DHCP Vendor Class

<DHCPVendor vendor="/^XBOX 1.0$/"/>

DHCP Host Name

<DHCPHost name="/^L[0-9]{7}/"/>

DHCP Options

<DHCPOptions option-list="/^53,61,12,60,50,55,255/"/>

DHCP Requested Options

<DHCPReqOptions option-list="/^1,3,15,6,44,46,47,43/"/>

DNS Name

<DNS name="/^printer[0-9]{4}/"/> 

Static MAC

<StaticMACRule>
     <StaticMAC mac="00:00:1a:2b:3c:bf"/>
</StaticMACRule>

Static IP

<StaticIPRule>
     <StaticIP ipaddr="10.1.1.1"/>
</StaticIPRule>

RADIUS Username

<RadiusUser username="jpsmith"/

CDP Platform

<CdpRule platform="/phone/i"/

Active Directory Member

<ActiveDirComputerMembership isMember="1"/>

Active Directory Computer Name

<ActiveDirComputerName name="lab-laptop"/

Active Directory Computer OS Name

<ActiveDirComputerOS name="XP"/

Active Directory OS Version

<ActiveDirComputerOSVer version="5.1"/

Active Directory OS Service Pack

<ActiveDirComputerSP servicepack="3"/

SNMP Description

<SNMP description="/cisco/"/>


Note A list of multiple MAC/IP addresses can be specified for a Static MAC/IP rule, repeat the syntax shown in the example for multiple rules in the Static MAC or Static IP rule block.


Advanced Rule Structure and Syntax

The XML rule editor will perform basic checking of the rule structure in terms of compliance with basic XML structure when the rule is saved; however there is not currently validation of created rules against the DTD requiring that the administrator provide that validation manually to ensure that the syntax outlined in the table above and described further in this section is maintained. Consistency of spelling and case are all important. The following is an example of a simple advanced rule as it appears in the Modeler configuration (Model.xml file):


<Rule name="MacOSAdv">
<RuleEntity entity="Mac OS" cf="0.75"/>
<AND>
<Vendor vendor="/^Apple/i"/>
<DHCPReqOptions option-list="/^1,3,6,15,112,113,78,79,95/"/>
</AND>
</Rule>

In an Advanced Rule, the rule name syntax, <Rule name=''MACOSAdv''> in the example, placed on the first line is unused by the NAC Profiler modeler and is used only to name the rule so that it can be identified in the Modeler configuration (Model.xml) to enable differentiation between rules. When creating Advanced Rules, they may be named as desired by the NAC Profiler administrator but it is highly recommended to pick a descriptive name if possible for the sake of system documentation.

The second line of an Advanced XML Rule is critical: this line directs the Profiler Modeling Engine ("Modeler") to associate each Advanced Rule to the Profile that it is bound to, along with the certainty for the rule. In version 3.1 and greater of Cisco NAC Profiler, this line of the Advanced XML Rule is created automatically by the ARE as an advanced XML rule is added to an endpoint profile.


Tip When viewing the XML via the Edit Raw button, the Rule Name and RuleEntity lines are omitted and not displayed--only the rule logic is displayed as the ARE manages this part of the XML for the user.


The second line of each Advanced Rule must use the following syntax:


<RuleEntity entity="[Profile-Name]" cf="x"/>

where [Profile-Name] is replaced with the name of the Profile (case sensitive)

and

''x'' is replaced with the certainty value for this rule, a number between .01 and 1 (1 and 100% certainty for this rule)

For example,


<RuleEntity entity="Advanced Printer" cf="0.65"/>

Would be interpreted as this Advanced Rule was bound to the Profile named Advanced Printer, and any endpoint for which the logic of the Advanced Rule tested true would be placed in the Advanced Printer profile with a certainty of 65%.

It is important to note that Advanced Rules can be combined with rules created as described in Chapter 8, "Managing Network Devices" and Chapter 9, "Endpoint Profile Configuration: Part 1" using the Add Rule Type buttons. When this is done the profile certainty is calculated precisely the same way, combining the certainties for the individual rules using the algorithm outlined in Chapter 8, "Managing Network Devices", including the use of the Certainty Calculator form available in the Save profile form.

Immediately following the "entity=" line of the advanced rule, the syntax of the rule which defines the rule logic is entered in accordance with proper XML syntax which will be covered below, ensuring that the rule syntax shown in the table for each rule type is maintained for each rule included in the Advanced Rule.

Note that comment lines can be added to an Advanced Rule using the following syntax:

<!-- comment text -->

Inserting comments in the Advanced Rule can greatly improve the documentation of the rule such that others can understand the underlying logic of the rule without assistance from the person who originally authored the rule. The proper documentation of Advanced Rules is highly recommended. Comments can be added to Advanced Rules from the ARE. Simply add a rule using the Add Rule option, then select Edit. In the Rule Type drop-down, select Comment which opens a text box that allows you to enter your comment text as shown in Figure 11-10. The comment text enter will be placed in the XML using the correct syntax.

Figure 11-10 Adding a Comment to an XML Rule using the ARE

One of the primary advantages of using Advanced Rules is the ability to utilize the other available logical operators within the rule logic: AND, NOT, etc., and the different rule types (for example, MAC Vendor, DHCP Vendor Class, etc.) in a single rule. In contrast, the GUI Profile editor allows multiple rules to be added to Profiles however the individual rules are added to the Modeler as distinct entities. During a remodel, the modeler must evaluate each of the rules specified in the enabled Profiles individually through the standard Profile creation process.

When multiple rules are added to a Profile using the GUI, the default logical operator is an ''implied OR'' meaning that for each multi-rule profile, each rule must be evaluated, and for those that test true for a given endpoint, the profile certainty is calculated for the composite value. Again the key concept to consider regarding using the GUI for defining multiple rules in a Profile is that they are evaluated by the Modeler independently.

An advanced rule can have multiple logic blocks using the logical operators, and those logic blocks can be nested within additional operators providing maximum flexibility in the creation of advanced rules. However, in the case of Advanced Rules the logic embedded in the rule is evaluated sequentially according to the specified logical operation.

If for example, there are two or more logical blocks nested within an AND operator, if the first block tests false, the Modeler ceases to evaluate the remaining logical blocks as the AND requires all blocks to test true. Similarly if two or more logical blocks are nested within an OR, as soon as one logical block tests true, the condition of the Advanced Rule is met and the Modeler ceases to evaluate the remaining logic.

Therefore, Advanced Rules can be defined that are much more efficient when multiple criteria are tested, more efficient than specifying multiple rules using the UI when the Advanced Rule versions are constructed properly giving consideration to the order of operations outlined earlier and other techniques outlined later in this section. When Profiles with multiple rules are created using the UI, the modeler must sequentially evaluate each rule in the profile, calculating the certainty value as described earlier in this chapter when multiple rule matches for a given endpoint occur.

It is through this requirement to evaluate each rule individually that the implicit OR result alluded to earlier when discussing Profiles constructed via the UI by adding separate rules. When there are large numbers of multiple-rule Profiles on a system with a large number of endpoints, a re-model of the entire endpoint database (which occurs only when an Apply Changes -> Update Modules, or Re-model is commanded), can take a significant period of time. Converting Profiles with multiple rules into Advanced Rules using the guidance provided in this section can increase the efficiency of the Cisco NAC Profiler modeling engine.

When creating Advanced Rule logic, prefix notation is used. In prefix notation, the logic operator (for example, AND, OR, NOT) is specified to the outside of the items (rules) that are to have the logic applied. For example, consider the following logical block taken from an Advanced Rule used for profiling printers:


<OR>
    <TrafficRule ipaddr="010.01.01.1" isSource="0" sport="0" dport="51510000" 
noCollectionRule="0"/>
    <TrafficRule ipaddr="0192.0168.01.180" isSource="0" sport="0" dport="9100443" 
noCollectionRule="0"/>
</OR>

In the logic block example above, two traffic rules are defined inside an OR operator (for example, between the <OR> and </OR>). When evaluating this rule the Modeler would evaluate the first rule and then the second rule only if necessary. Because the logical operator is OR this logic block would test true if either of the Traffic Rules were true, so if the first rule in the list tested true, the Modeler would not go forward to check the remaining rule: this block of logic would test true for the target of evaluation and the Modeler could go on to the next block, or next individual rule specified in the Advanced Rule. If these two traffic rules had been added to a profile individually using the Add Rule buttons (for example, not the Advanced Rule), the modeler would have to evaluate each rule independently-even though they are attributes associated with the same type of endpoints (printers).

This highlights a key concept in efficient rule design: when multiple rules are specified within a logic block using the OR operator, it is a best practice to order the rules such that any rules that are more likely to test true are defined at the very top of the list of rules to be OR'ed. Similarly, if two or logic blocks are nested within an OR, the logic blocks should be ordered such that those most likely to test true are ordered first such that the Modeler finds the hit and exits evaluation of the Advanced Rule as efficiently as possible.

This principle holds true in the proper design of Advanced Rules in general. Because the AND operator requires all rules (or nested logic blocks) to test true, strategic use of AND can greatly improve the efficiency of rules. The AND logical operator can be used within Advanced Rules to create logic blocks that are "pre-qualifiers" for the rule to increase efficiency and performance of the Modeler.

The following is an example of how this principle can be used in practice defining an efficient Advanced Rule. Returning to the Printer Advanced Rule mentioned earlier, the full rule includes a series of traffic rules that match traffic from the print servers specified in MyNetwork to endpoints on ports 9100 to 515, the standard print ports. The primary logic block in this system-generated Advanced Rule is created by using the OR operator on two traffic rules for each known print server IP address as shown in the following example:

<OR>

<TrafficRule ipaddr="1.1.2.50" isSource="1" sport="0" dport="515" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.50" isSource="1" sport="0" dport="9100" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.51" isSource="1" sport="0" dport="515" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.51" isSource="1" sport="0" dport="91009100 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.52" isSource="1" sport="0" dport="515" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.52" isSource="1" sport="0" dport="9100" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.53" isSource="1" sport="0" dport="515" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.53" isSource="1" sport="0" dport="9100" 
noCollectionRule="0"/>

</OR>

In this example, there are 4 print servers known to be at the following addresses and entered in the MyNetwork configuration of the Profiler system:


1.1.2.50
1.1.2.51
1.1.2.52
1.1.2.53

As outlined above, if the logic block of Traffic Rules with the OR was used by itself, the Modeler would evaluate each of the traffic rules until a match occurred. On the first match, the Modeler would exit with the result that the Advanced Rule tested true for the Target of Evaluation (ToE), a network printer.

The efficiency of the Advanced Rule could however be significantly improved in the following manner using the AND operator with this specific logic block and a new, more general "pre-screening" logic block as shown in the following example:



<AND>
<OR>
<TrafficRule ipaddr="0.0.0.0" isSource="1" sport="0" dport="515" 
noCollectionRule="1"/>
<TrafficRule ipaddr="0.0.0.0" isSource="1" sport="0" dport="9100" 
noCollectionRule="1"/>
</OR>
<OR>
<TrafficRule ipaddr="1.1.2.50" isSource="1" sport="0" dport="515" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.50" isSource="1" sport="0" dport="9100" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.51" isSource="1" sport="0" dport="515" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.51" isSource="1" sport="0" dport="91009100 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.52" isSource="1" sport="0" dport="515" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.52" isSource="1" sport="0" dport="9100" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.53" isSource="1" sport="0" dport="515" 
noCollectionRule="0"/>
<TrafficRule ipaddr="1.1.2.53" isSource="1" sport="0" dport="9100" 
noCollectionRule="0"/>
</OR>
</AND>

Note the addition of the AND operator and the new OR logic block that has been added to the original logic block discussed above that specifically matches the traffic from the known print servers outlined above.

The addition of the new logic block which checks to see that the traffic data being evaluated is print traffic, in conjunction with the AND operator ensures that prior to the evaluation of traffic to be from a specified list of print servers, that it should be first screened to determine if the traffic is in fact traffic related to printing via its port numbers first before doing the more intensive evaluation to see if it is in fact from one of the known print servers.


Note It is essential that the "pre-screening" rules described in this section be created with the noCollectionRule option checked. This prevents the NetWatch and NetRelay modules from having to Collect traffic from any source host address to any destination with destination port numbers of 515 and 9100. This would likely negate any efficiency gained in modeling by forcing the system to collect and evaluate additional data.


When used in conjunction with the AND operator, this technique provides a pre-screening function for the advanced rule including the evaluation of endpoint traffic: because both of the logic blocks (the general AND specific) have to test true to satisfy the conditional. So when the general logic block tests false (such as the traffic is not on the port numbers known to be associated with printing) the Modeler will exit out of the rule and move on-not wasting the cycles to this data to determine if it includes one of the specific IP addresses known to be the print servers on the network.

It should be intuitively obvious that using such a technique could substantially increase performance, particularly in situations where there were multiple active Traffic Rules resulting in collection of traffic data by the system with multiple source/destination ports, and when the specific logic block contained many entries (for example, several dozen print servers). The design of the rule using the pre-screening block would ensure the Modeler would only evaluate collected traffic associated with printing (on destination ports 9100 or 515), potentially avoiding evaluating non-conforming traffic to determine if it was from the print servers.

Using the NOT operator in Advanced Rules is similar to the other logical operators, and logical blocks using the NOT operator in conjunction with AND and OR is common. NOT can be used to exclude endpoints that match specific criteria from those that share common attributes.

For example, if an Advanced Rule was needed to match all endpoints on a given subnet (10.180.0.0/24 in the example) EXCLUDING the endpoints with host address (last octet) of .1 through .10 and the subnet broadcast (.255) addresses, the following rule syntax using the NOT operator could be used:


<AND>
<AddressRule ipaddr="10.180.0.0" mask="255.255.255.0"/> 
<NOT>
<OR>
<AddressRule ipaddr="10.180.0.0" mask="255.255.255.248"/> 
<AddressRule ipaddr="10.180.0.8" mask="255.255.255.255"/>
<AddressRule ipaddr="10.180.0.9" mask="255.255.255.255"/>
<AddressRule ipaddr="10.180.0.10" mask="255.255.255.255"/>
<AddressRule ipaddr="10.180.0.255" mask="255.255.255.255"/>
</OR>
</NOT>
</AND>

The NOT operator has nested within it the logical block using the OR with rules that will match the specific addresses desired to be excluded from matching this rule. Again, both logical blocks within the AND operator: the first that matches all host addresses on the 10.180.0 subnet and the negation of the logical block interpreted as any host address not .1 through .10 and .255 must test true for the Modeler to match a ToE to this rule.

Another example of using NOT in an Advanced Rule to exclude certain endpoints was used in practice to match endpoints known to not be connecting wirelessly (based on host IP address using an Address Rule) communicating with a known Novell server. In the example, endpoints connected via wireless are known to be assigned host addresses on the 10.200.0.0/21 subnet. Accordingly the NOT operator is used to exclude hosts with an address on this subnet from the hosts matching a traffic rule indicating communication with a specified Novell server on the designated port number (for example, using a Traffic Rule):


<Rule name="Novell Employee">
<RuleEntity entity="Novell_Employee" cf="0.90"/>
<AND>
<NOT>
<AddressRule ipaddr="10.200.0.0" mask="255.255.248.0"/>
</NOT>
<TrafficRule ipaddr="192.168.1.101" isSource="0" sport="0" dport="524" 
sportnoCollectionRule="0"/>
</AND>
</Rule>

Special Consideration for the Use of Web URL Rules Within Advanced Rules

Web URL Application Rule type require the NAC Profiler system to perform collection of specific network traffic: traffic meeting certain criteria specified in the Profile rules themselves. This requires NetWatch modules to be configured to collect traffic that the Modeler will in turn evaluate for rule matches in enabled Profiles utilizing these rule types.

When the UI is used to create Web URL Application Rules within Profiles as described in Chapter 10, "Endpoint Profile Configuration: Part 2", it automatically makes the necessary configuration changes to the NetWatch modules throughout the system necessary for the Profiler to begin collecting this network traffic from the Collector monitor ports, or via NetFlow on Collectors running NetRelay.

During the Apply Changes -> Update Modules that must follow the addition/enablement of Profiles using Web URL Application Rules, the new XML configuration files for all NetWatch modules in the system are generated and upon module restart, the system begins collecting this endpoint data via NetWatch so that the Modeler can begin examining port 80 traffic for Web URL rule matches.

The UI however does not parse the Advanced XML Rules for Web URL rules in version 3.1 and earlier as outlined earlier. Therefore, if Web URL application rules are used in Advanced Rules, the configuration of the NetWatch for collection of specific network traffic for evaluation against these rules is not automated, and must be done manually. This can be accomplished most simply by creating an additional rule using the GUI within the Profile(s) using the Advanced Rule containing Web URL rules with a low level of certainty (1% typically will suffice).

More Advanced XML Rule Examples

The example Cisco NAC Profiler Advanced Rules provided in this section are designed to provide the reader with additional examples of Advanced Rule construction to further illustrate the concepts outlined in this appendix.

The rules provided in this section although properly constructed are not necessarily useful in all environments as-is. They are provided primarily as examples of how the rule types and logic available in Advanced Rules might be combined to Profile certain endpoints.

In the first example, the use of the AND operator with multiple logic blocks: one consisting of a single MAC Vendor rule, and the other multiple Address Rules with the OR operator applied is illustrated. The devices that will match this rule must have a MAC address with an OUI containing Cisco (case-insensitive) and have an IP address on one of the 17 specified subnets of the 192.168.208.0 network.


<Rule name="CiscoRouterAdv">
<RuleEntity entity="Cisco Infrastructure" cf="0.6"/>
<AND>
<Vendor vendor="/^cisco/i"/>
<OR>
<AddressRule ipaddr="192.168.208.0" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.16" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.48" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.64" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.80" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.96" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.112" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.128" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.144" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.160" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.176" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.192" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.208" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.224" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.208.240" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.209.0" mask="255.255.255.240"/>
<AddressRule ipaddr="192.168.209.16" mask="255.255.255.240"/>
</OR>
</AND>
</Rule>

This next example Advanced Rule was designed to profile any Wireless Access Point that is attempting to communicate with a central wireless switch with IP address 10.4.1.5 communicating on port 5000 (the default tunnel port for the Enterasys/Trapeze APs), and observed by Cisco NAC Profiler sending a DHCP request with any of the following DHCP Vendor Classes: WIRELESS-AP:AP1002, WIRELESS-AP:AP3000/I, or WIRELESS-AP:AP4102.

<Rule name="Advanced Access Points"><RuleEntity entity="ETS Access Points" cf="0.90"/>
<AND>
<TrafficRule ipaddr="10.4.1.5" isSource="0" sport="0" dport="5000" 
noCollectionRule="0"/>
<OR>
<DHCPVendor vendor="/WIRELESS-AP:AP1002/i"/>
<DHCPVendor vendor="/WIRELESS-AP:AP3000/i"/>
<DHCPVendor vendor="/WIRELESS-AP:AP4102/i"/>
</OR>
</AND>
</Rule>

Some examples using the rule types available only in Advanced XML rules are illustrated in the following examples, one for detecting Apple machines via the requested DHCP options (MAC OS does not include a recognizable DHCP Vendor Class in DHCP requests), and a second one designed to detect endpoints running Microsoft Windows version 3.1.


<Rule name="MacOSAdv">
<RuleEntity entity="Mac OS" cf="0.75"/>
<AND>
<Vendor vendor="/^Apple/i"/>
<DHCPReqOptions option-list="/^1,3,6,15,112,113,78,79,95/"/>
</AND>
</Rule>

<Rule name="Win31Adv">
<RuleEntity entity="Windows 3.1" cf="0.50"/>
<AND>
<StackRule list="/^2$/" ttl="32" window="8192" df="2"/>
<DHCPReqOptions option-list="/^1,3,15,6,44,46,47,43/"/>
</AND>
</Rule>


The Cisco NAC Profiler Profile Rule Document Type Definition (DTD)

The purpose of a DTD is to define the legal building blocks of an XML document. It defines the document structure with a list of legal elements and attributes. The DTD for Cisco NAC Profiler profile rules and events is provided as a reference in this section.

In the current versions of Cisco NAC Profiler, Advanced Rules defined by the administrator are not validated against the DTD. However, beginning in version 2.1.8 an XML parser was added to provide basic XML syntax checking for the Advanced Rule editor.


Warning Improper XML syntax used in an Advanced Rule that is committed to the system configuration will result in a Server module failure on the system upon restart of the system via Apply Changes -> Update Modules.


Before an Advanced XML Rule is saved to the configuration, the syntax is checked and if the Advanced Rule is not valid XML format, an error is displayed. It is a roadmap item for a future release for the Advanced Rule editor to perform XML syntax checking and validate each user-defined Advanced Rule for compliance with the DTD.

Until that functionality is added to the system, it is highly recommended that the Cisco NAC Profiler administrator familiarize her/himself the DTD along with the examples in this document when authoring Advanced XML rules to ensure validity of the XML and compliance with the DTD.

By reviewing the Profiler DTD, the reader can review the different types of rules that are available via the Advanced XML Rule option and the data that must be provided.

The Cisco NAC Profiler Profile Rule DTD is provided below.

<!ELEMENT ModelConfiguration ( Entity+,
Rule+,
Event*,
CCARule* ) >
<!ELEMENT Entity EMPTY >
<!ATTLIST Entity name CDATA #required
description CDATA #implied
user ( t | f ) "f" >
<!ELEMENT Rule ( RuleEntity,
AddressRule*,
Vendor*,
DHCPHost*,
DHCPVendor*,
DHCPReqOptions*,
DHCPOptions*,
WebServer*,
WebClient*,
SMTPServer*,
DNS*,
SNMP*,
CTNBT*,
FTPServer*,
SSHServer*,
WebURL*,
StackRule*,
TrafficRule*,
PortRule*,
AND*,
OR*,
NOT* ) >
<!ATTLIST Rule name CDATA #implied >
<!ELEMENT AND ( AddressRule*,
Vendor*,
DHCPHost*,
DHCPVendor*,
DHCPReqOptions*,
DHCPOptions*,
WebServer*,
WebClient*,
SMTPServer*,
DNS*,
SNMP*,
CTNBT*,
FTPServer*,
SSHServer*,
WebURL*,
StackRule*,
TrafficRule*,
PortRule* ) >
<!ELEMENT OR ( AddressRule*,
Vendor*,
DHCPHost*,
DHCPVendor*,
DHCPReqOptions*,
DHCPOptions*,
WebServer*,
WebClient*,
SMTPServer*,
DNS*,
SNMP*,
CTNBT*,
FTPServer*,
SSHServer*,
WebURL*,
StackRule*,
TrafficRule*,
PortRule* ) >
<!ELEMENT NOT ( AddressRule*,
Vendor*,
DHCPHost*,
DHCPVendor*,
DHCPReqOptions*,
DHCPOptions*,
WebServer*,
WebClient*,
SMTPServer*,
DNS*,
SNMP*,
CTNBT*,
FTPServer*,
SSHServer*,
WebURL*,
StackRule*,
TrafficRule*,
PortRule* ) >
<!ELEMENT RuleEntity EMPTY>
<!ATTLIST RuleEntity name CDATA #required
cf CDATA #required>
<!ELEMENT AddressRule EMPTY>
<!ATTLIST AddressRule ipaddr CDATA #required
mask CDATA #required >
<!ELEMENT Vendor EMPTY>
<!ATTLIST Vendor vendor CDATA #required >
<!ELEMENT DHCPHost EMPTY>
<!ATTLIST DHCPHost name CDATA #required >
<!ELEMENT DHCPVendor EMPTY>
<!ATTLIST DHCPVendor vendor CDATA #required >
<!ELEMENT DHCPReqOptions EMPTY>
<!ATTLIST DHCPReqOptions option-list CDATA #required >
<!ELEMENT DHCPOptions EMPTY>
<!ATTLIST DHCPOptions option-list CDATA #required >
<!ELEMENT WebServer EMPTY>
<!ATTLIST WebServer banner CDATA #required >
<!ELEMENT WebClient EMPTY>
<!ATTLIST WebClient banner CDATA #required >
<!ELEMENT SMTPServer EMPTY>
<!ATTLIST SMTPServer banner CDATA #required >
<!ELEMENT DNS EMPTY>
<!ATTLIST DNS name CDATA #required >
<!ELEMENT SNMP EMPTY>
<!ATTLIST SNMP description CDATA #required >
<!ELEMENT CTNBT EMPTY>
<!ATTLIST CTNBT nbt CDATA #required >
<!ELEMENT FTPServer EMPTY>
<!ATTLIST FTPServer banner CDATA #required >
<!ELEMENT SSHServer EMPTY>
<!ATTLIST SSHServer banner CDATA #required >
<!ELEMENT WebURL EMPTY>
<!ATTLIST WebURL url CDATA #required >
<!ELEMENT StackRule EMPTY>
<!ATTLIST StackRule ttl CDATA #implied
df CDATA #implied
scale CDATA #implied
mss CDATA #implied
window CDATA #implied
list CDATA #implied >
<!ELEMENT TrafficRule EMPTY>
<!ATTLIST TrafficRule ipaddr CDATA #required
sport CDATA #required
dport CDATA #required >
<!ELEMENT PortRule EMPTY>
<!ATTLIST PortRule port CDATA #required >
<!-- Events -->
<!ELEMENT Event EMPTY>
<!ATTLIST Event name CDATA #required
valid CDATA #required
id CDATA #required
level CDATA #required
fauth ( t | f ) "f"
snmp ( t | f ) "f"
web ( t | f ) "f"
syslog ( t | f ) "f"
asm ( t | f ) "f" >
<!-- CCA Rules -->
<!ELEMENT CCARule EMPTY>
<!ATTLIST CCARule name CDATA #required
match CDATA #required
cf CDATA #required
type CDATA #required

role CDATA #required >