🌙
 

Subscribe to the Taegis™ VDR Documentation RSS Feed at .

Learn more about RSS readers or RSS browser extensions.

Fingerprinting and Asset Tracking

General Principles

The main objective for Secureworks® Taegis™ VDR asset fingerprinting and tracking is to be able to track and reconcile assets (devices) on very dynamic networks—for example, on DHCP networks—through the intelligent combination of data elements accessible from the network layer without relying on an agent or specific local hardware data (MAC address, CPU ID, etc.) from within the machine that could be invalidated because of local network configuration or inaccessible through unauthenticated scans.

VDR’s asset fingerprinting and tracking is available at https://github.com/delvelabs/dab. It can also be installed using Pip or a similar Python package manager; for example, if using Pip: pip install dab==1.0.0.

Different Fingerprints with Different Weights

In order to track assets from a changing network environment, with sometimes only partial elements to track, VDR uses multiple data elements and combines them into a single fingerprint; different weights are assigned to each data element based on its typical reliability over time.

The list of data elements that are included in a fingerprint are currently as follows, with more weight given to the ones at the top of the list:

Fingerprint Data Element Description
hostname The hostname of the machine on the network as returned by the local DNS
nbt_hostname The Netbios hostname of the machine as returned by the SMB service
ssh_xxxx_sha256 SHA256 hash of the SSH service key fingerprint for the xxxx algorithm (e.g., ecdsa_256)
ssh_xxxx_md5 MD5 hash of the SSH service key fingerprint for the xxxx algorithm
ssl SSL/TLS Certificate Fingerprint
SAN Hostnames Subject Alternative Names from SSL Certificates

The fingerprints can be accessed within VDR by selecting the fingerprint icon present on every asset in the Servers view.

From there, you can consult which fingerprints were discovered on the asset at the last Discovery and at the last Scan.

Fingerprints

Fingerprints

Asset Re-assignment Through Auto-Discovery

Assets in VDR are re-assigned during the discovery phase. None are made during the scan phase—hence the importance of running discovery more frequently than scans for smooth processing. By default, VDR does daily discoveries and weekly scans.

When running discoveries, VDR attempts re-assigning currently visible assets to previously visible ones, using whichever IP they are reachable at. This is akin to the Pigeonhole Principle and as such:

All matching is done using the fingerprints gathered during discovery and/or scanning.

Unreachable Assets

It is possible that a different responding asset is given the IP of a disconnected asset. In that case, VDR may list these two assets with the same IP: one with a connected icon (green dot) and one with a disconnected icon (since it is unreachable).

Scan Safeguards

Before running a scan, VDR attempts to find the appropriate asset by performing a hostname lookup based on hostname combinations found within the fingerprints. The asset with the best fingerprint match found is used as the scan target or it will fall back to the last known IP address. In the event an nbt_hostname is found at discovery, it will be required for the scanned asset to have the same value.

Note

Certain network configurations (see Addressing Asset Duplication Issues) might cause some issues with asset discovery and cause situations where the nbt_hostname and hostname do not match. Since this is an exception, VDR will raise the visibility of the nbt_hostname if this happens so you can better identify where the vulnerabilities are.

Searching for Fingerprints

Within the Servers view of VDR, you can search for certain fingerprints using the fingerprint: keyword. For more information on keywords, see Search Grammar.

E.g. to find the assets with an SSH key fingerprint of 00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F use fingerprint:00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F

Tip

This fingerprint search can be useful to identify assets that have duplicated keys or SSL certificates in your environment where that shouldn’t be the case.

Addressing Asset Duplication Issues

In order to avoid asset duplication issues, it is important to consider the following general guidelines when working with VDR’s fingerprinting mechanism

Local DNS Access

Make sure VDR has access to your local DNS to collect hostnames. The more detail about the assets that can be gathered from the network perspective or through running unauthenticated scans, the better VDR is at reconciling the assets as they change IPs over DHCP networks.

Increase TTL for DHCP

Increase the TTL for DHCP assignments. DHCP assignments can be short lived, but if an asset changes IP more frequently than auto-discoveries are run, it makes it harder for VDR to reconcile the assets at the right place.

Stale Record Scavenging

Increase the frequency of DNS stale records scavenging. Most DNS servers allow you to configure stale records scavenging when a hostname gets assigned a new IP on the network. Having a shorter time window for stale records scavenging ensures VDR does not see two different responses when looking up DNS records for particular network hosts. Because the hostname is an important part of fingerprints, if VDR can see two similar hostnames at different IP addresses, this may cause them to be added twice to VDR.

Allowlist VDR

Allowlist VDR against anti-scan features in your IPS/IDSes. Some network appliances come with anti-scan features that would either block Secureworks® Taegis™ VDR, send partial data, or most likely send back ficticious responses. This can also be the case for Internet proxies that return fake Web pages to Secureworks® Taegis™ VDR. These ficticious responses end up looking like real assets, which can cause duplicates or non-existent (ghost) assets to appear in Secureworks® Taegis™ VDR. Allowlisting Secureworks® Taegis™ VDR’s Edge Services IPs in these network appliances helps avoid these situations. See Addressing TCP Wrapping for more information.

 

On this page: