Sending custom fingerprints to paired Scan Engines

If you develop custom fingerprints, you can have the Security Console distribute them automatically to any paired Scan Engine that is currently in use when a scan is run. To do so, simply copy the fingerprint files to the [installation_directory]/plugins/fp/custom/ directory on your Security Console host.

You do not have to restart the Security Console afterward. The NSC.log file, located in the [installation_directory]/nsc/logs/ directory, will display a message indicating the location and number of the newly added fingperprints.

Ensuring correct formatting for the fingerprints

Custom fingerprint XML files must meet certain formatting criteria in order to work properly, as in the following example:

 
1
<?xml version="1.0"?>
2
<fingerprints matches="ssh.banner">
3
<fingerprint pattern="^RomSShell_([\d\.]+)$">
4
<description>Allegro RomSShell SSH</description>
5
<example service.version="4.62">RomSShell_4.62</example>
6
<param pos="0" name="service.vendor" value="Allegro"/>
7
<param pos="0" name="service.product" value="RomSShell"/>
8
<param pos="1" name="service.version"/>
9
</fingerprint>
10
</fingerprints>

The first line consists of the XML version declaration.

The first element is a fingerprints block with a matches attribute indicating what data the fingerprint file is intended to match.

The matches attribute is normally in the form of protocol.field.

The fingerprints element contains one or more fingerprint elements.

Every fingerprint contains a pattern attribute with the regular expression to match against the data.

An optional flags attribute controls how the regular expression is to be interpreted. See the Recog documentation for FLAG_MAP for more information.

Each fingerprint contains a description element with a human-readable string describing the fingerprint.

At least one example element is included, though multiple example elements are preferable. These elements are used in test coverage present in rspec, which validates that the provided data matches the specified regular expression. Additionally, if the fingerprint is using the param elements to extract field values from the data, you can add these expected extractions as attributes for the example elements. In the preceding example the string

 
1
<example service.version="4.62">RomSShell_4.62</example>

tests that RomSShell_4.62 matches the provided regular expression and that the value of service.version is 4.62.

Each param elements contains a pos attribute that indicates what capture field from the pattern should be extracted, or 0 for a static string.

The name attribute is the key that will be reported in a successful match, and the value will either be a static string for pos values of 0 or missing and taken from the captured field.

Best practices for creating fingerprints

Create a single fingerprint for each product as long as the pattern remains clear and readable. If that is not possible, separate the pattern logically into additional fingerprints.

Create regular expressions that allow flexible version number matching. This ensures greater probability of matching a product. For example, all known public releases of a product report either major.minor or major.minor.build format version numbers. If the fingerprint strictly matches this version number format, it would fail to match a modified build of the product that reports only a major version number format.

Testing custom fingerprints via command line

You can test fingerprints via command line by entering executing bin/recog_verify against the fingerprint file:

 
1
$ bin/recog_verify xml/ssh_banners.xml

You can test matches via command line similarly:

 
1
$ echo 'OpenSSH_6.6p1 Ubuntu-2ubuntu1' | bin/recog_match xml/ssh_banners.xml -
2
MATCH: {"service.version"=>"6.6p1", "openssh.comment"=>"Ubuntu-2ubuntu1", "service.vendor"=