1. General Concepts

1.1. Introduction

Collector is part of NEXThink V3. It is basically a lightweight driver of about 120kB that runs on end-users’ computers. This driver passively identifies user activities (Endpoint Activity Mapping), which are then reported to NEXThink Engine.

The following figure depicts the functioning of Collector as part of the whole NEXThink solution.

1.2. Collector Components

Collector is more than just a Windows driver. Depending on your needs, you may use some of the following components, which are integral parts of NEXThink Collector:

• Driver. This is the core of Collector. It is responsible for analyzing users’ and applications' activities and reporting them to the Engine.

• Control Panel extension (optional). This element is used for viewing the Windows driver and update agent status, and change their respective configurations.

These 3 elements are packaged within a single MSI installer that is used both for single-machine and network-wide installations.

1.3. Requirements

1.3.1. Operating System

Collector can be installed on the following platforms:

• Windows 2000 SP4

• Windows XP, all Service Packs, all editions

• Windows Server 2003, all Service Packs

• Windows Vista, all Service Packs, all editions

• Windows Server 2008, all Service Packs

• Windows 7, all Service Packs, all editions

32-bit and 64-bit of these operating systems are supported.

Note: all our software components are Windows Vista UAC compliant.

1.3.2. Software Dependencies

The MSI package providing Collect depends on Windows Installer 2.0 or later, which is shipped with all aforementioned supported Windows flavors.

Moreover, only NEXThink Engine can decode information transmitted by Collector. For more details on NEXThink software dependencies, refer to the different components Release Notes.

1.3.3. Deployment effort

The recommended deployment strategy, depending on the number of machines where Collector must be installed:

1. Week 1: Preparation, Unitary testing

2. Week 2: Verification, mass testing

3. Week 3-6: Verification, network-wide deployment

More details about this deployment strategy will follow in the section advanced/Testing and Deploying Collector.

1.4. Obtaining Collector

Collect MSI package can be downloaded on http://support.nexthink.com.

Please make sure to read the associated Release Note before any further action.

2. Data Gathering

The Windows driver is the core component of Collector. It is responsible for identifying users’ and applications' activities on endpoints and reporting such activities to NEXThink Engine. In the rest of this section, we first cover the general functioning of the Collector. Its information gathering and transmission processes are then detailed.

2.1. Configurable Behavior

Many of the Collector driver settings can be changed either at installation or at run-time. For the sack of simplicity, the content of this chapter refers to the behavior of the Collector driver when configured with its default parameters values. However, for making it clear to the reader that these values may be changed, such references have been highlighted in italic.

2.2. General Functioning

The Collector driver enables a service on the target machine. The associated service name is nxtdrv. This section gives a sample sequence of events concerning the Collector driver so that the reader can get a better understanding of its functioning.

1. The machine the Collector driver is installed on is started by its owner.
2. At early boot-time (when the Windows splash screen is still visible), the Collector driver is loaded. It immediately starts collecting information about the machine activities. This means that even processes being started very early by Windows (e.g. winlogon.exe, lsass.exe) are reported throughout their complete life-time by nxtdrv. A description of gathered data and intercepted events is given in the next section.
3. When the network becomes ready, and after having waited for a random delay (not more than 30 seconds), collected information is sent to the Engine with UDP packets. The Engine is then able store the machine activity context to make it available through NEXThink Finder and Portal.
4. Collected information is periodically resent as UDP is a best-effort protocol and some packets may get lost.
5. When the machine is switched off, the Collector driver is one of the last components to be unloaded, meaning that no information is missing in the machine context.

The Collector driver is defined as a Windows component that is necessary for the proper execution of the operating system. As such, any installation, upgrade or removal of this component requires a computer reboot.

Note: When booting in Windows "safe mode" the Collector driver is not loaded.

2.3. Information gathering and transmission

2.3.1. Events interception

The following events are intercepted by the Collector driver:

• Machine power on and off
• Hardware information
• User logging in and logging out
• Process creation and termination
• Connection establishment and closing
• Data transmission (TCP in/out, UDP in/out)
• Installed packages and patches
• Machine and process performance data

This gives a complete visibility of the machine activity through its complete life-time.

2.3.2. Gathered information

The following tables details information that are sent to the NEXThink Engine by the Collector driver.

2.3.2.1. Machine

2.3.2.2. User

2.3.2.3. Connection

2.3.2.4. Process

2.3.2.5. Package

2.3.2.6. Hardware

2.3.2.7. Antivirus

2.3.2.8. Security

2.3.2.9. Print job

Notes:

• NEXThink Collector does not report its own activity to the Engine.
• Traffic generated by kernel-mode software (e.g. drivers) is reported as a fake process, whose attributes are depicted in the following figure:

2.3.3. Information transmission

If an event listed in the previous section is detected by the Collector driver, associated information is saved momentarily in an internal buffer. Information about existing objects (i.e. machine, users, applications, connections), as well as traffic volumes and objects status, are also pushed to this buffer every 15 minutes and 5 minutes, respectively, so that the Engine can follow the target machines evolution. This buffer is then emptied and its content is sent to the Engine every minute. Data fields are encapsulated in UDP packets up to a maximum payload size of 1460 bytes.

Note: if booted after the endpoints, the Engine may need up to 30 minutes (2 x 15 minutes) to build its representation of a given machine context.

3. Other Functionalities

Collector driver also includes the following major functionalities:

• CrashGuard feature: as the Collector driver is a kernel-mode component, any error in its internals can lead to system instabilities. Even if NEXThink put as much attention to deliver bug-free software as possible, the principle of precaution holds. The CrashGuard feature detects whether the system did crash. If this is the case, and if this happened for more than 3 times in a row, the Collector driver disables itself.

• Kernel traffic interception: some applications may send and receive data to and from the network using kernel-mode components (Windows drivers). The Collector driver is able to detect such traffic and reports them.

• Paths aliasing: for commonly used paths (e.g. C:\WINDOWS\, C:\Program Files\) and other special mount locations (removable mount points, network drives), paths aliases are used. For example, if the DVD-Rom drive is mounted under D:, an application “setup.exe” being launched from this media will be reported as %RemovableDrive%\setup.exe.

• Engine presence detection: if the Collector driver detects that the Engine is not reachable because it is not available on its local network (ARP request is failing), it disables itself for 10 minutes.

• Network interfaces watching: if a network interface appears or disappears on the machine, the Collector driver detects this event and resends its whole machine context to the Engine.

• Windows Event logging: main events and errors are logged in Windows event logs.

• On-the-fly configuration: the Collector driver parameters can be changed through the Collector Control Panel extension. There is no need to restart the computer for changes to become effective.

4. Limitations

Limitations There are some known limitations to the Collector driver:

• USB keys aliasing under Windows Vista: applications launched from USB keys under Windows Vista are not reported to be used from a %RemovableDrive% path. Aliasing does not work.

• Source IP is not reported: the source IP of established connections is always set to 0.0.0.0. This does not affect the capabilities of the Engine.
• Low-level firewalls may block Collector driver traffic: these firewalls must be configured for accepting the Collector driver traffic.
• Applications may supersede others: some applications impersonate other processes. For example, Avast Web Shield takes the place of well known web browsers (Firefox, MS Internet Explorer, etc). Connections established by the later are reported by the Collector driver as coming from Avast Web Shield instead of the original application.

5. Impact on Machine Performances

A typical Collector driver usage consumes in average about 300kB of RAM and less than 0.05% of CPU time. However, if a lot of processes are being created, CPU utilization may rise as SHA1 and MD5 checksums are computed for all launched binaries (.exe). Experiments have shown that such test cases induce about 2% of CPU utilization. As Windows Vista launches about 50% more system processes than Windows XP, the memory footprint of the Collector driver is consequently about 50% higher than the one experienced under XP.

5.1. Impact on Network

As the Collector driver sends information to the engine by the mean of UDP packets, it has an impact on the company network. It is hardly estimable as it highly depends on your endpoints configuration: the traffic generated by the Collector driver directly depends on the number of running processes on target machines. However, when using the default driver parameters, the following average throughput per machine have been observed (Windows XP):

• Base traffic (30 processes): 130 bits/second
• Normal traffic (50 processes): 260 bits/second
• Heavy activity (75 processes): 500 bits/second

Again, as Windows Vista launches more system processes than Windows XP, it can be roughly estimated that a normal activity under Windows Vista corresponds to a heavy activity under Windows XP from traffic point of view. Note: configuring nTop on the Engine side can help you monitor Collector traffic. nTop configuration is detailed in the Console Admin Guide.

6. Control Panel Extension

6.1. Introduction

The Collector driver allows collection and transmission of information about the machine where it is installed. However, it must be configured. This can be done at installation-time (see advanced/InstallingCollector), but also at run-time, using the Collector Control Panel extension. This tool is also helpful for watching the Collector driver status and activity.

6.2. Intended Audience

The present Control Panel extension can be used by any person responsible for evaluating and deploying Collector. However, NEXThink does not recommend installing it on end-users machines as it is an administration tool.

6.3. Generalities

These facts hold :

• Running the Collector Control Panel extension requires administrative rights.

• If the Collector Control Panel extension is installed, nxtpanel.cpl can be found in %SystemRoot%/system32/

• It is also a standalone application: double-clicking the nxtpanel.cpl will execute the applet as if it was launched from the Windows Control Panel.
• Any change to the driver configuration is applied on-the-fly (i.e. without requiring a computer restart) after having pressed the Apply or OK buttons.
• The Collector Control Panel extension is aimed to work with a specific Collector driver version.

6.4. Content Description

The different tabs of the Collector Control Panel extension are depicted hereafter. Numbers in textual descriptions refer to the screenshot.

6.4.1. Status tab

1. These radio buttons allow the user to disable or enable the Collector driver. The driver is not unloaded when being disabled by this mean, but enters the so-called pass-through mode: events interception, information collection and packets transmission are suspended.

2. The status text field contains key information regarding the Collector driver. First, it gives its currently installed version and installation date. Second, it provides the user with the current status (running, stopped, etc). Its also contains information about the CrashGuard feature and the destination of Collector driver packets (the Engine).

3. The Start button can be used for loading the Collector driver if it was not already done (e.g. after an initial installation). Loading the driver by this mean is not recommended because the complete machine life-cycle will not be reported to the Engine and some information may be missing (e.g. processes created earlier). It is however recommended to reboot the machine after initial installation.

6.4.2. General tab

1. IP address: specifies the IP address of the Engine.

2. Port: specifies the port number of the Engine.

3. CrashGuard count: if this number is equal to the maximum CrashGuard count (see 5. below), driver loading is cancelled.

4. This resets the CrashGuard count back to 0. If it was previously not loaded (because of CrashGuard count exceeding the maximum CrashGuard value), the Collector driver is not automatically reloaded.

5. Protected execution: the CrashGuard feature does protect the computer against crashes for the specified period. If a crash happens after this duration, the CrashGuard count will not be incremented. Set to 0 for incrementing the counter whenever a crash should happen during the machine life-time.

6. Max. CrashGuard count: this is the threshold until which the Collector driver will be running (see CrashGuard feature in Chapter 3).

7. Logging mode: this setting is used for enabling Collector driver logs, which are used for troubleshooting potential issues. The possible values are:

   1. Silent: setting the logging mode to Silent disables the Collector driver logging facility. This is the default value.

   2. Verbose: this value allows Collector driver troubleshooting. As its resource consumption is reasonable, it can be used for off-site watching of the Collector driver.

   3. Debug: the setting allows intensive logging of the Collector driver activities. It is CPU demanding and should therefore only be activated when troubleshooting the driver on-site.

8. Checking this box will instruct the Collector driver to resend all collected information to the Engine if a new network adapter appears or disappears on the machine. This allows the Engine to be able to directly reconstruct the complete machine context rather than having to wait for all information to be sent, which may take up to 30 minutes.

6.4.3. Advanced tab

• Maximum payload size: this setting sets the maximum number of bytes to be embedded within a single UDP packet. This value should be adapted if the network MTU is lower than the default 1460 bytes.

• Block creation interval: information regarding objects (i.e. machine, users, applications, connections) will be pushed in the internal buffer after this number of seconds. Default: 900 seconds.

• Update block creation interval: traffic volumes and objects status will be pushed in the internal buffer after this number of seconds. Default: 300 seconds.

• Queue flushing interval: if some data are present in the internal buffer, they are sent to the Engine periodically. This setting specifies this sending interval. Default: 60 seconds.

• Inter-packet delay: Collector driver will wait for this amount of milliseconds between each packet sending. This settings therefore acts as a bandwidth limiter. Default: 30 milliseconds.

• Maximum IO stack usage: if Collector driver uses more than this amount of IO stack, the operation causing this consumption is cancelled. This protection mechanism is only for Windows Vista. Default: 2048 bytes.

• Maximum boot-time delay: Collector driver will not send packets to the Engine before a random delay, whose maximum value is specified by this setting. Default: 30 seconds.

• ARP timeout duration: an ARP request is considered to have timed out if there is no reply after this number of seconds. Default: 2 seconds.

• Self deactivation duration: if an ARP timeout occurs, Collector driver will deactivate itself for the specified number of seconds. Default: 600 seconds.

---

• CategoryCollector CategoryV3 CategoryV4