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: 
  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 discussed.
  
  === State Machine
  
  In order to fully understand inspection, you must understand how IronBee processes data. IronBee flows through a state machine during each transaction. An idealized diagram (of this state machine for a connection containing a single transaction) is below. In addition to the idealized states, 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 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 State::
      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 State::
      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 State::
      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::
      While not really 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 rules may trigger.
  
  .IronBee States
  image::images/ironbee-states.png[link="images/ironbee-states.png" window="_blank"]
  
  The server will trigger the Server States, advancing the IronBee engine through the state machine. Modules hook into these states to perform processing. Modules can further parse transaction data (e.g., exposing new 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 rule modules (e.g., rules and xrules modules) register directives to define 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.
  
  
negative.code: 
  IronBee Rule Language::
  
  The IronBee rule language, loaded via the _rules_ module, allows for defining simple rules within the IronBee configuration. These rules utilize the basic rule engine to provide linear execution of rules per execution phase. Due to the linear execution and limited syntax of the configuration language, these rules are typically only going to be useful for basic signature type rules.
  +
  .Basic Rule Directive Syntax:
  ----
  