Overview

netAnalyzer has a signature engine build in, quite similar to the one you found in signature based IDS but for application protocol information extraction. Signature syntax was inspirated by the one found in nmap service-signature. However because we have extended this format with many functionnalities and templates, they can't be imported directly. In particular we rely on rule priority rather than softmatch. An import script is available however.

This engine aim to provides a flexible and convinient but yet powerful mean to gather advanced information on ongoing network flows. It allows administrator to gather specific information from application layer protocol without modifiying the analyzer code. This particulary useful as it provide an efficent and simple mean for the administrator to add it own evens or error triggers.

What information can be reported ?

Information that can be capturated range from simple thing such as protocol detection where no specifique information are captured to more advanced one such as client software version identification. Rules are compiled by netAnalyzer at runtime or when it receive a SIGUP signal. Reporting Events and Errors can be done in any signature using special templates See SignatureError.

How signature are triggered ?

The rule engine is build on top of the traffic engine. The traffic engine is responsible to trigger appropriatly each set of rules. By detecting for instance if it's a control or a data packet. If your are interessted in the engine by it self see engine.

Signature Generic syntax

Rules are written to use full perl regular expression power (in intern the analyzer use the PCRE library). Every rule must be in the forme:

signatureType protocol i'Regexp' data_1/value_1/ data_2/value_2/... data_n/value_n/ optionname:optionvalue optionname:optionvalue

where

• signatureType what this rule is about. By example the keyword 'scmatch' indicate to match sofware information in a control packet.
• protocol is the protocol used for the session: ex pop3, smtp ..
• Regexp the regular expression that need to be matched.
• data is the keyword used to specify in which field the value need to be stored for later interpretation.
• value can contains plain english and $1...$n regular expression variables to gather informations.
• modifier is a group of option used to modify the behavior of the analyzer. See SignatureBehavior for more details

Signature type

There is mainly two groups of signature :

1. Control signature are used to gather informations exchanged during protocol operation such as handshake or data requests.
2. Content signature are used to gather informations about the files exchanged during the session.

To be more readable, signatures are regrouped into files, but this is the syntax of the signature by itself that determines how it will be interpreted. However keeping signature of different type separated makes the database more clear. It also helps to prevents unwanted signature overlapping. The signature type keyword always end up by the term match.

NetAnalyzer use the following type of signatures to gather information from the control and the content part of the session. Control part is intuitively the set of packets used to etablish the session and request or acknowledge files. Every sig that are triggered during control phases have a sigType that end with "cmatch", the c standing for control whereas every signature that are triggered during data phases have a sigType that end with "dmatch", the d standing for data. the content part allow to spot inconsitency between the file headers and it's true nature but also to gather additionnal information such as the one contained in the file headers.

• Protocol information (control-protocol.rules file). sigType is either 'pcmatch' or 'pdmatch'
• Client information (control-client.rules file). sigType is either 'ccmatch' or 'cdmatch'
• Server information (control-server.rules file) sigType is either 'scmatch' or 'sdmatch'
• File information (control-file.rules file) to get information from the file request. sigType is either 'fcmatch' or 'fdmatch'
• User information (control-file.rules file) to detect who users are using the network. sigType is either 'ucmatch' or 'udmatch'
• Users relations information (control-user_to_user.rules file) to discover User to User relation. sigType is either 'rcmatch' or 'rdmatch

Signature options

options are applicable for any king of signature. They allow to modify how the analyzer will treat match and add extra information. Options include signature priority and matching policy. Here is a quick list of the options available. See [[Signature_option| Signature options]] for a more detailed explanation of each one.

Options List

• confidence:1-100 confidence in the rule (100 means sur of it). Used by protocol detection algorithm. Default is 100.
• dissector:string add to the session a dissector to perform advanced analysis. Various dissectors are availables. They are used when regexp language expressiveness is not sufficient.
• depth:1-n restric the match to the n bytes
• [hint:control|data] to provide feedback to the phase detection
• [nature:(req|rep|err)] type of the packet. Used for stats
• noreport does not output the match. Usefull for signature dedicated to statistique or protocol identification.
• offset:1-n start matching at the N bytes of the payload
• [policy:continue|stop] is used to modify the analyzer global matching policy for a given signature.
• priority:n rules match order priority. 0 equal parsing order, positive value for higher priority, negative value for lesser priority

Not yet implemented

• bitflows:name use state