Advanced XML Rules

Advanced XML Rules

This appendix contains the following topics:

•Advanced XML Rules Syntax

•Using Traffic and Web URL Rules within Advanced Rules

•Advanced Rule Examples

•Cisco NAC Profiler Document Type Definition (DTD)

Note See also Advanced Rules, page 9-17 for additional information.

The Cisco NAC Profiler Advanced Rule option offers the ability to define custom rules using Extensible Markup Language (XML) to combine the Profiler rule types using the Boolean logic operators OR, AND and NOT. You can combine multiple rules of a single type, and different types of rules, into a single Advanced Rule to evaluate any endpoint data collected by Cisco NAC Profiler via the NetMap, NetWatch and NetRelay (for Traffic Rules) modules.

This appendix expands the information provided in Advanced Rules, page 9-17 to assist advanced Profiler administrators with the design and configuration of Advanced Rules, an advanced feature of the product. When designed properly, Advanced Rules significantly increase the flexibility of Cisco NAC Profiler. However, invalid XML configuration in Advanced Rules can also prevent the Server module of the Profiler Server from starting, and poorly constructed rule logic can negatively impact overall system performance. In the current version, the Advanced Rule editor checks Advanced Rules for valid XML prior to saving the rule to the configuration, which provides some level of error checking.

Like any advanced technique, Cisco recommends approaching Advanced Rules with the requisite level of attention to the documentation and requirements specific to the Cisco NAC Profiler product. For example, although the Profiler leverages techniques similar to those used in other applications, such as Intrusion Prevention, Cisco NAC Profiler was not designed to be an IPS. It is important to consider this when configuring Profiles using these advanced techniques and when designing a Cisco NAC Profiler deployment. If questions regarding the design of an Advanced Rule or potential performance impacts arise, it is best to contact Cisco NAC Profiler Technical Support for assistance and guidance.

Advanced XML Rules Syntax

Advanced Rules are configured using valid XML syntax conforming to the Profiler Document Type Description (DTD) as described in Cisco NAC Profiler Document Type Definition (DTD). The general format of an Advanced Rule is as follows:

<Rule name="Advanced Rule">

<RuleEntity entity="Profile Name" cf="certainty_value"/>

<logical_operator 1>

Rule 1

Rule n

</logical_operator 1>

</Rule>

For the purposes of this document, a logic block is defined as the one or more rules enclosed by a logical operator: AND, OR or NOT. It is acceptable to "nest" multiple logic blocks within logical operators to create complex rules that check multiple criteria. The NOT operator can be designed to exclude other criteria.

In an Advanced Rule, the Profiler Modeling Engine ("Modeler") does not use the Rule name syntax on the first line itself. This is used only to name the rule so that it can be identified. When creating Advanced Rules, Cisco highly recommends choosing a descriptive name to facilitate system description, although you can name the rule anything that you like.

The RuleEntity on second line of an Advanced Rule is critical. This line directs the Modeler to associate each Advanced Rule to the Profile to which it is bound.

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)

•x is replaced with the certainty value for this rule, a number between .01 and 1

In the following example, the named Advanced Rule is interpreted as bound to the Profile named Advanced Printer. Any endpoint for which the logic of this Advanced Rule tests true will be placed in the Advanced Printer profile with a certainty of 65%:

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

Immediately following the "entity=" line of the Advanced Rule, the syntax of the rule which defines the rule logic is entered with proper XML format, as described in the sections which follow.

Note Cisco highly recommends inserting comments into Advanced Rules to properly document them so others can understand the underlying logic of the rule without assistance from the original author of the rule. You can add comment lines to an Advanced Rule using the following syntax:
<!-- comment text -->

Multiple Logic Blocks

One of the primary advantages of using Advanced Rules is the ability to use other available logical operators within the rule logic, such as AND and NOT, and different rule types, such as MAC Vendor and DHCP Vendor Class, in a single rule.

When multiple rules are added to Profiles via the GUI Profile editor of the Profiler Server, 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 OR. Because individual rules in a Profile are evaluated independently, it is possible for multiple rules to test true and therefore the certainty algorithm that represents the combined certainty resulting from the match of multiple rules is used. 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.

In contrast, 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. However, in the case of Advanced Rules, the logic embedded in the rule is evaluated sequentially according to the specified logical operation. For example, if there are two or more logical blocks nested within an AND operator, and if the first block tests false, the Modeler ceases to evaluate the remaining logical blocks in the rule because 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 (that is, at least one condition tests true), and the Modeler ceases to evaluate the remaining logic in the Advanced Rule.

Therefore, when testing against multiple criteria, you can define Advanced Rules (when properly constructed) that are much more efficient than if you specified multiple rules using the GUI.

OR Operator and Order of Rules/Logic Blocks

When creating Advanced Rule logic, prefix notation is used. In prefix notation, you specify the logic operator (e.g., AND, OR, NOT) to the outside of the items (rules) to which the logic will apply. For example, consider the following logical block taken from the system-generated Advanced Rule for the Generic Printer Profile:

<OR>

  <TrafficRule ipaddr="0.0.0.0" sport="0" dport="515"/>

  <TrafficRule ipaddr="0.0.0.0" sport="0" dport="9100"/>

</OR>

In the logic block example above, two traffic rules are defined inside an OR operator— that is, between the <OR> and </OR>. When evaluating this rule, the Modeler evaluates the first rule and then the second rule, only if necessary, in the order implied by the rule itself. Because the logical operator is OR, this logic block will test true if either of the Traffic Rules is true. Therefore, if the first rule in the list tests true, the Modeler does not continue to check the remaining rule. This block of logic will test true for the Target of Evaluation (TOE) and the Modeler will continue to the next block, or next rule.

When multiple rules are specified within a logic block using the OR operator, it is good practice to order the rules in the logic block so that any rules more likely to test true are defined in the logic block at the very top of the list. Similarly, if logic blocks are nested within an OR, the logic blocks most likely to test true should be placed first so that the Modeler finds the hit and exits the Advanced Rule as efficiently as possible.

This highlights a key general concept in efficient design of Advanced Rules. 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.

Generic Printer Rule

The following is an example of how this principle can be used in practice. The Generic Printer rule is an Advanced Rule that 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 printer 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 (added to MyNetwork configuration) as shown in the following example:

        <OR>

         <TrafficRule ipaddr="1.1.2.50" sport="0" dport="515"/>

         <TrafficRule ipaddr="1.1.2.50" sport="0" dport="9100"/>

         <TrafficRule ipaddr="1.1.2.51" sport="0" dport="515"/>

         <TrafficRule ipaddr="1.1.2.51" sport="0" dport="9100"/>

         <TrafficRule ipaddr="1.1.2.52" sport="0" dport="515"/>

         <TrafficRule ipaddr="1.1.2.52" sport="0" dport="9100"/>

         <TrafficRule ipaddr="1.1.2.53" sport="0" dport="515"/>

         <TrafficRule ipaddr="1.1.2.53" sport="0" dport="9100"/>

        </OR>

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

1.1.2.50

1.1.2.51

1.1.2.52

1.1.2.53

As outlined above, if this logic block is used by itself, the Modeler evaluates each of the traffic rules until a match occurs. On the first match, the Modeler will exit with the result that the Advanced Rule tested true for the Target of Evaluation (ToE).

AND Operator

You can increase the efficiency of the Advanced Rule using the AND operator with a specific logic block (as described in Generic Printer Rule) and a new, more general "pre-screening" logic block as shown in the following example. This example illustrates how the system-generated Advanced Rule for Generic Printer is constructed in practice in the current Profiler version:

Pre-Screen AND Logic Block

<AND>

        <OR>

         <TrafficRule ipaddr="0.0.0.0" sport="0" dport="515"/>

         <TrafficRule ipaddr="0.0.0.0" sport="0" dport="9100"/>

        </OR>

        <OR>

         <TrafficRule ipaddr="1.1.2.50" sport="0" dport="515"/>

         <TrafficRule ipaddr="1.1.2.50" sport="0" dport="9100"/>

         <TrafficRule ipaddr="1.1.2.51" sport="0" dport="515"/>

         <TrafficRule ipaddr="1.1.2.51" sport="0" dport="9100"/>

         <TrafficRule ipaddr="1.1.2.52" sport="0" dport="515"/>

         <TrafficRule ipaddr="1.1.2.52" sport="0" dport="9100"/>

         <TrafficRule ipaddr="1.1.2.53" sport="0" dport="515"/>

         <TrafficRule ipaddr="1.1.2.53" sport="0" dport="9100"/>

        </OR>

       </AND>

The AND operator and the new OR logic block is added to the original logic block that specifically matches the traffic from the known print servers as described in Generic Printer Rule.

The new logic block in conjunction with the AND operator ensures that the traffic comes from one of the desired port numbers associated with printing before it is evaluated for whether it comes from the specified list of print servers (i.e., the original OR logic block). When used in conjunction with the AND operator, this technique provides a pre-screening function for the Advanced Rule. Both of the logic blocks, the general AND specific, have to test true to satisfy the conditional. When the general logic block tests false (e.g., 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 verify if this is traffic from a specific IP address on the specified ports. This technique can substantially increase performance, particularly in situations where the specific logic block contains many entries, for example several hundred print servers. The design of the rule using the pre-screening block ensures the Modeler only evaluates traffic known to be associated with printing, potentially avoiding evaluating non-conforming traffic.

NOT Operator

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

For example, if an Advanced Rule is needed to match all endpoints on a given subnet, excluding devices with host address (last octet) of .1 through .10 and the subnet broadcast (.255) addresses, the following logic block employing the NOT operator can 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>

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

The following example shows how to use NOT in an Advanced Rule to exclude certain endpoints known to not connect wirelessly (based on host IP address using an Address Rule) when 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 (e.g., 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" dport="524" sport="0"/>

  </AND>

</Rule>

Using REGEX Within Advanced Rules

Many of the rule types that are used within the logic blocks of Advanced Rules utilize a Regular Expression (REGEX) for the matching data, like the standard rules defined through the GUI. Many of the examples in this document illustrate the use of REGEX within their logic blocks.

Using Traffic and Web URL Rules within Advanced Rules

As described in Chapter 9, "Configuring Endpoint Profiles," Traffic Rules and the Web URL Application Rule type require Cisco NAC Profiler to perform collection of specific network traffic—traffic meeting certain criteria specified in the Profile rules themselves. This requires both the NetWatch and NetRelay (in the case of Traffic Rules only) 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 GUI is used to create Traffic Rules and/or Web URL Application Rules within Profiles, it automatically makes the necessary configuration changes to the NetWatch and NetRelay 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/enabling of Profiles using Traffic or Web URL Application Rules, the new XML configuration files for all NetWatch and NetRelay modules in the system are generated and upon module restart, the system begins collecting this data so that the Modeler can begin examining it for rule matches.

Note In the case of URL rules, there is no configuration change to NetRelay, only to NetWatch. Traffic Rules require configuration of both modules for specific collection.

However, the GUI does not parse the Advanced XML Rules in version 2.1.8 and earlier. Therefore, if Traffic Rules or Web URL application rules are used in Advanced Rules, the configuration of the NetWatch and NetRelay for collection of specific network traffic for evaluation against these rules is not automated, and must be done manually. This can be accomplished simply by creating an additional rule using the GUI. A standard Traffic or Web URL rule is added to the Profile containing the Advanced Rule containing Traffic or Web URL rule(s). The standard rule which acts as a "collection rule" is added with a low level of certainty (1% typically will suffice). Its intended purpose is to activate the specific collection needed so the Profiler begins collecting traffic via NetWatch and or NetRelay to evaluate against the Advanced Rule.

The construction of these "collection rules" for Traffic Rules in particular can have performance implications as described earlier in this document: each time a standard rule is added using the GUI, it must be evaluated by the Modeler. Therefore a technique that may be employed is to make these collection rules open and not attempt to add a standard rule for the specific destination or source addresses of interest—that is use the IP address of 0.0.0.0 for the source or destination IP in the collection rule as applicable. This will result in the system collecting all traffic observed on the designated source or destination port number. The Advanced Rule logic will be used to identify the desired match. It is good practice to avoid configuring a list of collection rules with specific hosts identified and forcing the Modeler to evaluate each of the collection rules and the Advanced Rule.

To illustrate this concept, consider the Advanced Rule discussed under NOT Operator that includes a Traffic Rule that is designed to match endpoints communicating with a Novell Server IP on port 524. In the same Profile (Profile name Novell_Employee in the example), a standard Traffic Rule is defined using the GUI to act as a collection rule for the Advanced Rule. That Traffic Rule has the following parameters to ensure the set up of NetWatch and NetRelay modules in the system for traffic collection:

0.0.0.0

Dest IP

Src Port 0

Dest Port 524

Certainty 1%

After adding the standard Traffic Rule used as a collection rule and the Advanced Rule to the Novell_Employee Profile and enabling the Profile, an Apply Changes -> Update Modules needs to be executed to generate the NetWatch and NetRelay configurations and begin collection of the traffic needed to match the Advanced Rule. After the restart, as endpoints are observed matching the criteria: communicating with the Novell Server on port 524 but not having a wireless host address, they are added to the Novell_Employee Profile with a certainty of 90% (as specified in the Advanced Rule above).

If the step of adding the collection rule as well as the Advanced Rule to the Novell_Employee Profile is not taken, NetWatch and NetRelay are not programmed to collect this traffic, and no matches will occur.

Advanced Rule Examples

The example 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 section.

Note Although properly constructed, the rules in this section 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.

AND Operator with Multiple Logic Blocks

This first example illustrates 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. The devices that 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.240.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>

Access Point / DHCP Vendor Classes

This next example Advanced Rule profiles any Access Point that:

•Attempts 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)

•Is observed by Profiler to send 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" sport="0" dport="5000"/>

     <OR>

      <DHCPVendor vendor="/WIRELESS-AP:AP1002/i"/>

      <DHCPVendor vendor="/WIRELESS-AP:AP3000/i"/>

      <DHCPVendor vendor="/WIRELESS-AP:AP4102/i"/>

     </OR>

    </AND>

   </Rule>

Wireless Windows Endpoints

This example identifies endpoints running a version of Windows known to be attached via wireless based on having host addresses on the wireless subnets. The WebClient/Web User Agent rule is used to identify devices displaying a web client associated with the Windows OS. This rule illustrates one of the principles outlined earlier regarding the ordering of rules within a logic block: the wireless network subnets should be ordered from most populated to least populated to ensure an early match and exit from the logic block.

<Rule name="Win User Wireless">

      <RuleEntity entity="Windows Users - Wireless" cf="0.85"/>

    <AND>

     <OR>

      <AddressRule ipaddr="10.1.0.0" mask="255.255.255.0"/>

      <AddressRule ipaddr="10.1.1.0" mask="255.255.255.0"/>

      <AddressRule ipaddr="10.1.2.0" mask="255.255.255.0"/>

      <AddressRule ipaddr="10.1.4.0" mask="255.255.252.0"/>

      <AddressRule ipaddr="10.2.0.0" mask="255.255.255.0"/>

      <AddressRule ipaddr="10.2.1.0" mask="255.255.255.0"/>

      <AddressRule ipaddr="10.2.2.0" mask="255.255.255.0"/>

      <AddressRule ipaddr="10.2.4.0" mask="255.255.252.0"/>

     </OR>

     <OR>

      <WebClient banner="/Windows|Win32/i"/>

      <DHCPVendor vendor="MSFT 5.0"/>

      <DHCPVendor vendor="MSFT 98"/>

      <DHCPVendor vendor="Microsoft Windows CE"/>

     </OR>

    </AND>

   </Rule>

Cisco NAC Profiler 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 rules and events is provided as a reference in Profiler DTD for Rules and Events.

In the current versions of Cisco NAC Profiler, Advanced Rules defined by the administrator are not validated against the DTD. However, in version 2.1.8 an XML parser is 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. Cisco highly recommends using the DTD in Profiler DTD for Rules and Events 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. Note that in addition to the use of the logical operators reviewed earlier in this document, there are also several rule types that can be used in Advanced Rules that are not available through the GUI in the current releases of Profiler. Some examples of rules available only through the Advanced Rule include:

•DHCP Options, which allow rules to be defined based upon either the Requested or Assigned DHCP options

•StackRules, which allow rules to be defined based on several Network Stack Info attributes of endpoints such as TTL, Window Size, TCP options, etc.

Note An important caveat regarding the TTL value: 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 of2. Some older systems use 48 and 60. Any TTL value observed in a packet >= 256 will be automatically reset to 255.

These two 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>

Profiler DTD for Rules and Events

This section provides the DTD for Cisco NAC Profiler rules and events as a reference.

<!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 >