Beginning with version 3 of Message Sniffer (SNF), the core features of the system are packaged in a chunk of software called the SNFMulti engine. SNFServer, the MDaemon plugin, the SDKs, and other upcoming SNF packages all use the SNFMulti engine in some way.

The SNFMulti engine is configured through an XML based file that is typically named snf_engine.xml. For the MDaemon plugin the file is named snfmdplugin.xml. Other products that use the SNFMulti engine may use other names also.

The XML code used in the configuration file has been designed so that "ordinary humans" using a plain-old text editor should be able to find their way around and understand what they are doing. Of course, a nice XML aware editor can help quite a bit if you have one.

A SNFMulti configuration file usually represents the configuration for a single SNF node. The <node/> element identifies the node either directly or more commonly through an identity.xml file. The major components and features of the SNFMulti engine for that node are described in subordinate elements.

It is not strictly necessary for all of the possible elements to be present in an SNFMulti configuration file. If an element is missing then the defaults defined for that section will be used by the program. This helps when new features are added later because it means that new features will use their default settings (or be turned off) until they are configured otherwise -- so if an older configuration file is in place then the software _should_ work as expected even after an upgrade.

The major sub-sections of the configuration file are:

<paths/> - This section controls where the SNFMulti engine will be running, where it will find its rulebase, and where it should write its log files. In most installations these are all the same location. It's important to note that this is not the only place in the configuration where paths are important. Other features may have their own path references such as the <node/> element which may point to the identity.xml file, and the <update-script/> element which may point to the location of a script. As a general rule, it is best to provide full paths.

<logs/> - This section controls which log files will be generated, how they will be formatted, and whether they will be rotated (using a date stamp in their names).

<network/> - This section controls how this SNF node will connect with its peers. Other functions related to this network are also defined here, such as the update-script feature which is driven by network SYNC events.

<xci/> - This section controls the XCI service option. The XCI service listens for XCI requests on the local machine when enabled. Some installations may want to change how this feature operates or may even want to disable it. For example - if the SNFMulti engine is embedded in another software and all requests are made directly to the API then the XCI service option might be redundant or undesriable.

<gbudb/> - This section controls how the GBUdb subsystem is managed, trained, and tuned. This includes maintenance features that regulate condensation events and database snap-shots, GBUdb regions and how they interact with the scanning engine, and training features.

<rule-panics/> - This section contains any user-defined rule-panic entries. A rule-panic entry identifies a specific pattern rule by its ID and renders it inert. This is designed to provide immediate relief from false positives.

<platform/> - This section provides platform specific configuration data. This data may be different from one platform to another. Information about data in this area will usually be found in the documentation provided for a specific application / platform. For example, the MDaemon plugin uses configuration options in this section to control it's IP Scanning feature.

<msg-file/> - This section defines the message file format expected by the SNFMulti engine.

Please email support@armresearch.com with any questions.