Using the wizard enables port-independent configuration and the detection of
malware command and control channels.  If the wizard is bound to a session, it
peeks at the initial payload to determine the service.  For example, 'GET'
would indicate HTTP and 'HELO' would indicate SMTP.  Upon finding a match, the
service bindings are reevaluated so the session can be handed off to the
appropriate inspector.  The wizard is still under development; if you find you
need to tweak the defaults please let us know.

==== Wizard patterns

Wizard supports 3 kinds of patterns:

    1. Hexes
    2. Spells
    3. Curses

Each kind of pattern has its own purpose and features.
It should be noted that the types of patterns are evaluated
exactly in the order in which they are described above. 
Thus, if some data matches a hex, it will not be 
processed by spells and curses.

The depth of search for a pattern in the data can be configured using
the `max_search_depth` option

'TCP' packets form a flow, so wizard checks all data
in the flow for a match. If no pattern matches
and 'max_search_depth' is reached, the flow is abandoned by wizard.

'UDP' packets form a "meta-flow" based on the addresses and ports of the packets.
However, unlike TCP processing, for UDP wizard only looks at the first arriving
packet from the meta-flow. If no pattern matches that packet or wizard's 'max_search_depth'
is reached, the meta-flow is abandoned by wizard.

==== Wizard patterns - Spells

Spell is a text based pattern. The best area of usage - text protocols: http, smtp, sip, etc.
Spells are:

    * Case insensitive
    * Whitespace sensitive
    * Able to match by a wildcard symbol

In order to match any sequence of characters in pattern, you should use
"`*`" (glob) symbol in pattern.

  Example:
    Pattern: '220-*FTP'
    Traffic that would match: '220- Hello world! It's a new FTP server'

To escape "`*`" symbol, put "`**`" in the pattern.

Spells are configured as a Lua array, each element of which can
contain following options:

  * 'service' - name of the service that would be assigned
  * 'proto' - protocol to scan
  * 'to_server' - list of text patterns to search in the data sent to the client
  * 'to_client' - list of text patterns to search in the data sent to the server

  Example of a spell definition in Lua:
    { 
      service = 'smtp', 
      proto = 'tcp',
      to_server = { 'HELO', 'EHLO' },
      to_client = { '220*SMTP', '220*MAIL' } 
    }

==== Wizard patterns - Hexes

Hexes can be used to match binary protocols: dnp3, http2, ssl, etc.
Hexes use hexadecimal representation of the data for pattern matching.

Wildcard in hex pattern is a placeholder for exactly one occurrence 
of any hexadecimal digit and denoted by the symbol "`?`".

  Example:
    Pattern: '|05 ?4|'
    Traffic that would match: '|05 84|'

Hexes are configured in the same way as spells and have an identical set of options.

  Example of a hex definition in Lua:
    { 
      service = 'dnp3',
      proto = 'tcp',
      to_server = { '|05 64|' },
      to_client = { '|05 64|' } 
    }

==== Wizard patterns - Curses

Curses are internal algorithms of service identification.
They are implemented as state machines in C++ code
and can have their own unique state information stored on the flow.

A list of available services can be obtained using `snort --help-config wizard | grep curses`.

  A configuration which enables some curses:
    curses = {'dce_udp', 'dce_tcp', 'dce_smb', 'sslv2'}

==== Additional Details:

* Note that usually more specific patterns have higher precedence.
    
  For example:
    The following spells against 'foobar' payload. The 3rd spell matches.
      { service = 'first',  to_server = { 'foo' } },
      { service = 'second',  to_server = { 'bar' } }
      { service = 'third',  to_server = { 'foobar' } }

* If the wizard and one or more service inspectors are configured w/o
  explicitly configuring the binder, default bindings will be generated which
  should work for most common cases.

* Also note that while Snort 2 bindings can only be configured in the
  default policy, each Snort 3 policy can contain a binder leading to an
  arbitrary hierarchy.

* The entire configuration can be reloaded and hot-swapped during run-time
  via signal or command in both Snort 2 and Snort 3.  Ultimately, Snort 3
  will support commands to update the binder on the fly, thus enabling
  incremental reloads of individual inspectors.

* Both Snort 2 and Snort 3 support server specific configurations via a hosts
  table (XML in Snort 2 and Lua in Snort 3).  The table allows you to
  map network, protocol, and port to a service and policy.  This table can
  be reloaded and hot-swapped separately from the config file.

* You can find the specifics on the binder, wizard, and hosts tables in the
  manual or command line like this:  snort --help-module binder, etc.

