anchor.diff:  
   ==== Rule Based Inspection
   
  -IronBee provides a generic framework for scheduling and executing operators and performing actions via rules - a rule engine. The state diagram indicates where the rule engine executes rules.  These points are called ``phases''. While most rule systems use the rule engine, this is not required. Note that the term ``Rules'' is used loosely here as IronBee does not limit what functionality a rule can provide nor syntax for defining rules. A rule is defined generically as some meta data, an operation to perform (typically on some data, such as a regular expression) and one or more actions to execute based on the results of this operation. A number of different rule systems and syntax exist; all with different goals. These different systems are encapsulated into modules that can be loaded into IronBee, which means that you only need to load the functionality that you need. To perform inspection, however, you need to choose what techniques to use (e.g., what modules to load).
  +IronBee provides a generic framework for scheduling and executing operators against input data and performing actions via rules - a rule engine. The state diagram indicates where the rule engine executes rules.  These points are called ``phases''. While most rule systems use the rule engine, this is not required. Note that the term ``Rules'' is used loosely here as IronBee does not limit what functionality a rule can provide nor syntax for defining rules. A rule is defined generically as some meta data, an operation to perform (typically on some data, such as a regular expression) and one or more actions to execute based on the results of this operation. A number of different rule systems and syntax exist; all with different goals. These different systems are encapsulated into modules that can be loaded into IronBee, which means that you only need to load the functionality that you need. To perform inspection, however, you need to choose what techniques to use (e.g., what modules to load).
  +
  +The IronBee Reference Manual has a section that defines all modules, what objects they register (directives, operators, transformations, actions, etc.) To use this functionality, you just need to load the module into IronBee. For example, to use the regular expression operator in rules, you must first load the _pcre_ module, which registers the _rx_ operator.
   
   ===== Configuration Based Rules
   
  
positive.code: 
  XRules::
  
  XRules (eXtended Rules), loaded via the `xrules` module, allow writing simple rules to perform common tasks. XRules do not use the rule execution engine, but instead use normal module state hooks. Because of this, they avoid some complexity by making assumptions based on the type of rule. For example, you do not have to specify a phase as that phase is inherit in the type of rule.  Additionally XRules are designed for fast execution and the same type of rules are often combined together into a larger, but more efficient operation. XRules are typically used to perform firewall like operations, allow dynamic configuration to control inspection, and perform exceptions for other rule systems.
  +
  A good example of all of this is IP based blocking rules. These are done via the `XRuleIPv4` and `XRuleIPv6` directives. No phase is needed as these rules will run as early as possible. And to be efficient, all IP based rules are combined together into a single IP set matching algorithm, so no matter how many IP based rules you create, they will all be combined into a single matching operation.
  +
  
negative.code: 
  Inspecting data in IronBee is powerful, but with this power comes some complexity. There are numerous methods for inspecting traffic in IronBee. While, this allows great flexibility, it also comes with the cost of having to make some decisions. Different inspection techniques lend to different methods. This guide explains the various inspection methods in order to make it easier to decide which techniques to use.
  
  In addition to different inspection techniques, IronBee supplies you with a number of tools to aid writing and testing inspection. While looking at the inspection techniques these tools will be introduced and then discussed in depth.
  
  === State Machine
  
  In order to fully understand inspection, you must first understand how IronBee processes data. IronBee flows through a state machine during each transaction. An idealized diagram of this state machine is below. In addition to the idealized state flow, the diagram indicates where rule modules hook into IronBee. Note that this diagram shows only a single transaction within a connection. The transaction states can repeat many times within a single connection.
  
  There are several state types. While there is currently no limitations for what these states can be used for, it is useful to note the typical uses of each state type.
  
  Server States::
  
  These states are high level states triggered by a server. The IronBee engine uses these states as trigger points for other states. These states correspond to the generic connection and transaction lifcycles.
  
  Module States::
  
  These states are where typical IronBee modules will hook into the engine to handle typicall needs for modules. Because of this, these states are all prefixed with "handle_".
  
  Extended States::
  
  At times some more granularity is required for modules. Typically this will be initializing routines, setting up dependencies, etc. These states are triggered at various points prior to the Module States so that modules can avoid ordering issues when loading. These iextended states allow modules to execute code at points before typical modules will execute.
  
  Rule Execution Points::
  
  While not technically states, these rule execution points are where the rules systems interact with the state machine. Theay are labeled here to help module and rule writers better understand when rule execution may occur.
  
  .IronBee States
  image::images/ironbee-states.png[link="images/ironbee-states.png" window="_blank"]
  
  The server is required to notify IronBee when the server reaches certain states. These are the Server States, which drive the IronBee engine through the state machine. Modules play a more passive role and hook into states to perform any processing. Modules can further parse transaction data (e.g., exposing new data fields for inspection), register additional directives, operators or transformation functions, perform inspection and just about anything else imaginable. For example, typical inspection will be through rules. The syntax for these rules is implemented by modules, primarily _rules_, _xrules_ and the _lua_ modules, which register directives and hook into the IronBee engine to allow defining rules and then execute these rules at the indicated points in the state machine.
  
  NOTE: The LogEvent state is a rather special state that can be triggered at any time (and multiple times) during a transaction. It allows for post-processing events triggered by rules and other modules.  While the functionality of this state will remain, the state may be removed from the state machine in favor of a making it just a generic hook through the logevent API.
  
  