VMware NSX Network Detection and Response System Administration Operations
This document describes the system administration of VMware NSX Network Detection and Response appliances mostly focused on an On-Premises installation.
About Appliances
The VMware NSX Network Detection and Response deploys a three-tier architecture. It provides a monitoring tier with the Sensor, an analysis tier provided by the Engine and Data Node, and a management tier where the Manager coordinates activity and connections across the installation. In an On-Premises installation, you install all three tiers in your data center. For the Hosted environment, you only install the monitoring tier, with the VMware backend providing the analysis and management tiers, accessed through your account on the User Portal at https://user.lastline.com/ (for EMEA customers https://user.emea.lastline.com/).
Manager
The Manager collects information from Sensor appliances, processes the data, and finally presents it to the user. Artifacts (such as executables and documents) that are attached to email messages or provided in URLs are passed to the Engine for immediate analysis. Data is also shared with the Data Node.
The Manager provides a local instance of the User Portal, a comprehensive Web interface. You use its dashboards and other pages to view the activity detected within your environment and manage the VMware NSX Network Detection and Response appliances.
See the Manager Installation and Administration guide for installation and initial configuration details.
Sensor
The Sensor performs active or passive inspection of your network traffic to identify events that are of interest to the system. This ranges from file transfers (for example, executables, documents, or email messages) to metadata on network activities observed in the environment (for example, netflow, pdns, or webrequests). The information extracted by the Sensor is streamed to the VMware backend for processing.
See the Sensor Installation and Administration guide for installation and initial configuration details.
The Sensor can also be deployed to AWS and Azure cloud environments. See the Sensor on AWS Deployment and Administration and Sensor on Azure Deployment and Administration guides for details.
Engine
The Engine simulates an entire host (including the CPU, system memory, and all peripherals) and its operating environment to analyze unknown files, such as executables and documents, and URLs. These data are submitted from the Manager and other sources. The Engine then runs the artifacts and returns the results of its analysis to the Manager.
See the Engine Installation and Administration guide for installation and initial configuration details.
Data Node
The Data Node receives data records (such as netflow, passive DNS, and webrequest records) collected by the Sensor as well as from third party solutions, such as network switches and routers, security devices, and dedicated netflow probes. It stores these data and analyzes them. It then returns analysis results to the Manager.
See the Data Node Installation and Administration guide for installation and initial configuration details.
Before you begin
Before you can successfully deploy the VMware NSX Network Detection and Response in your data center, there are a number of requirements that must be met. Your network infrastructure must allow the default connections needed by the VMware appliances. You must determine the optimal placement of the Sensor appliances to gain the greatest visibility into the traffic entering and leaving your network. Finally, you must determine which system features you wish to enable and license your installation accordingly.
Connectivity requirements
In an On-Premises installation, the Manager must be able to access the VMware backend to obtain threat intelligence, software, and license updates. In addition, the VMware backend optionally (dependent on your license and system settings) returns cloud analysis results from suspicious samples you uploaded and supports on-demand queries to the Knowledge Base and other data sources. The VMware backend facilitates other essential services to ensure your installation is running correctly to provide maximum protection.
The Sensor in the Hosted environment must also be able to access the VMware backend.
In the event of disconnection, the Sensor, in either a Hosted or On-Premises environment, will continue to work autonomously using its current threat intelligence data. Detected events are stored locally. When connectivity is re-established, the data is uploaded with the correct timestamp.
Domain name services
The VMware NSX Network Detection and Response appliances require access to domain name servers (DNS) that can resolve external names, including the VMware backend as well as internal names.
External domain names
The Manager must be able to access:
-
user.lastline.comonTCP/443(in Europeuser.emea.lastline.com). -
update.lastline.comonTCP/443(in Europeupdate.emea.lastline.com). -
ntp.lastline.comonUDP/123for time synchronization (in Europentp.emea.lastline.com). It can be replaced with a local NTP server. Access to an NTP server is required for the correct operation of the system. -
log.lastline.comonTCP/443(in Europelog.emea.lastline.com). -
anonvpn.lastline.comonUDP/1194.
External IP addresses
The domain names above currently resolve to IP addresses within the following CIDR blocks:
-
38.95.226.0/24 -
38.142.33.16/28 -
199.91.71.80/28 -
46.244.5.64/28 -
66.170.109.0/24
Adjust your firewall rules to allow connections to these address ranges.
Internal domain names
The system appliances, the Sensor, the Engine, and the Data Node depend on the Manager to provide the VMware backend services. You should assign a local domain
name to the Manager. Assuming your organization
has the example.com domain and that lastline.example.com
is the FQDN of the Manager, the following domain
names should be additional aliases for the same IP address:
-
user.lastline.example.com -
update.lastline.example.com -
log.lastline.example.com
CDN usage
To increase availability and reduce download times, the VMware NSX Network Detection and Response installation can be configured to download large files from content distribution network (CDN) servers. As such hosts are geographically distributed, the contacted hosts may vary from system to system. CDN servers outside the documented list of IP addresses may be contacted for downloads.
The use of CDNs is enabled by default during installation or upgrade. You can also
explicitly enable or disable this feature with the lastline_register
command.
If you explicitly enable the use of CDNs or choose to accept the default, ensure that you adjust your firewall rules to allow access to the CDN servers.
Internal connections
Data Node cluster communication
The Data Node needs to access TCP port 9200 and 9300 on every other Data Node appliance in order to create an Elasticsearch cluster. TCP port 9200 is used for REST traffic and TCP port 9300 is used for Data Node communication. The Manager must also be able to communicate with the Data Node on TCP port 9200.
To obtain data records from the RabbitMQ broker running on
log.lastline.example.com, access to port 5671 (encrypted channel) and
port 5672 (non-encrypted channel) is required.
Local communication network
The VMware
NSX Network Detection and
Response appliances employ a number of Docker containers to provide services. These containers require an internal
network to use for communication. By default, this network is defined to use
169.254.64.0/20, a portion of the IPv4 link-local address space. This network does not need to be
reachable from outside services or hosts.
Proxy server
The Manager in an On-Premises installation or the Sensor in the Hosted environment must be able to access the VMware backend.
If a network proxy is deployed in your environment, you need the IP address or FQDN of the
proxy server and its port number before you install the VMware
NSX Network Detection and
Response appliances. Authentication must be disabled
for the appliances that utilize the proxy server. If the proxy server limits the domains
that can be accessed, *.lastline.com must be allowed or, at a bare minimum,
allow access to the listed FQDN.
Examples of valid proxy configurations: proxy.example.com:3128 or
192.168.0.1:8080
The VMware NSX Network Detection and Response appliances cannot communicate through Sophos Transparent or through Microsoft Forefront proxies.
Network Time (NTP)
To accurately report events, incidents, and intrusions, the VMware
NSX Network Detection and
Response appliances need to keep their clocks in
close synchronization. By default, the installer selects ntp.lastline.com
for time synchronization. During installation, or afterward with the lastline_setup command, you can replace this with
another NTP server.
The selected NTP server, whether it is on your local network or an external device, must be reachable over UDP port 123. Without NTP access, the system cannot work correctly.
SSL/TLS certificate
The VMware NSX Network Detection and Response appliances provide most of their services through HTTPS. During installation, the Manager generates and then uses a self-signed SSL certificate. This requires all the managed appliances to store and trust this certificate during the registration phase.
When you access the User Portal hosted on the Manager, your browser also needs to trust the certificate.
Replace the certificate
You can optionally replace the SSL/TLS certificate on the Manager. This can be your own self-signed
certificate or a certificate signed by the certificate authority (CA) for your organization.
Assuming a FQDN of lastline.example.com, the certificate needs to be valid
for:
-
user.lastline.example.com -
update.lastline.example.com -
log.lastline.example.com
If you deploy an active-standby configuration, the certificate should also be valid for
user.standby.lastline.example.com
In this scenario, you should use user.lastline.example.com as the
commonName for the certificate. Then specify the above domain names as
Subject Alternative Name (SAN). This way user.lastline.example.com will
work even for clients that do not support SAN. The certificate needs to be in x509
format. Intermediate CA certificates need to be appended to the server certificate file.
See the Deploy a New Certificate topic in the Manager Installation and Administration guide for instructions.
Email monitoring options
The VMware NSX Network Detection and Response provides a number of methods for monitoring email in your network and preventing attacks with the Sensor:
- Passive
-
-
Sniff SMTP traffic
-
POP3/IMAP
-
MTA (no delivery)
-
- Active
-
-
MTA inline
-
Passive monitoring
Passive email monitoring allows you to see email traffic on your network and obtain reports that can be used for further action.
You can configure the Sensor to sniff all network traffic. In this mode, it processes any SMTP packets it sees on the wire. A major limitation with this method is that any email that is encrypted at transport level (SMTP/TLS) cannot be inspected. In addition, the Sensor can only see traffic that traverses its network segment and cannot compensate for errors seen by its SPAN or TAP interface. Sensor placement location is critical. One of the few advantages of using SMTP sniffing is that it can see both inbound and outbound traffic on the network segment.
Alternatively you can configure the Sensor as an IMAP or POP3 client. This mode requires that you also configure the email flow into your organization to blind-copy all inbound messages to the designated user account on the Sensor. All messages received by this account are deleted after analysis.
The recommended mode for passive monitoring is to configure the Sensor as an MTA (no delivery) endpoint. This mode provides visibility into all email messages that are accepted by the downstream MTA server, including those sent over TLS. The connection is also reliable, using TCP retries for any network errors. This mode requires that you configure the email flow into your organization to FORK all inbound messages to the Sensor. All messages received by this account are deleted after analysis.
Active monitoring
The most highly recommended configuration is active email monitoring. As above, this also provides visibility into all email traffic on your network. In addition, it allows you to either quarantine messages with malicious content or to clean the malicious content from the messages before sending them onward to the next hop. Configure the Sensor as an MTA relay. This mode requires that the email flow into your organization is configured to add the Sensor as an MTA hop in your email processing.
Appliance placement
The VMware NSX Network Detection and Response provides the best protection when the Sensor appliances have complete visibility across your entire network. It is recommended that you deploy a Sensor on all the critical segments of your network:
-
Network borders for Internet, extranet, and VPN.
-
Core data center segments.
-
Cloud workloads (AWS VPCs or Azure Virtual Networks).
-
IOT/ICS/SCADA infrastructure.
-
End user segments.
Command line configuration tools
The VMware NSX Network Detection and Response provides a number of command line utilities to assist you with the configuration and management of the appliances.
During the installation and registration process, you use the lastline_register command. It defines the essential
parameters of the appliance, including the critical network connections, then applies your
licenses to the installation.
Once the appliance is registered and running, you can use the lastline_setup command to adjust certain settings.
There are certain parameters that can only be changed from this command line application.
See Setup command options for a detailed breakdown of the
options available with the lastline_setup
command.
Enable SSH access
By
default, the Manager is configured to allow
key-based authentication. To use this feature, you must add your public SSH key to the
lastline user account to enable future SSH access.
An alternative remote access method to the VMware NSX Network Detection and Response appliance is to enable the monitoring user.
Configuration command
The lastline_setup command
provides a number of configuration options that are used to administer and manage the VMware
NSX Network Detection and
Response appliances. Its basic usage is
illustrated with the help option.
Enable the monitoring user
As an alternative to the lastline user, the VMware
NSX Network Detection and
Response offers the monitoring
user. This account can access the appliances using console or via SSH (password only without
using the SSH key). Once enabled, the monitoring user has the same level of
system privileges as the lastline user.
To enable the monitoring user, use the new_monitoring_user_password option of the lastline_setup command.
Throughout the rest of this guide, you can substitute the monitoring user
wherever the lastline user is required.
Network Configuration
The VMware NSX Network Detection and Response supports easily changing the network configuration of its appliances. This update may be required if assigned IP addresses change (for example, upon a reconfiguration of the network) or if you choose to switch from static addressing to DHCP or vice versa.
Reconfigure for DHCP
To reconfigure the network configuration of a VMware
NSX Network Detection and
Response appliance to DHCP, use the network
option of the lastline_setup command.
Reconfigure for Static Addressing
To reconfigure the network configuration of a to use a static IP address or to update to a
new IP address, you must provide or replace values for the address,
netmask, gateway, and
dns_nameservers parameters. Use the network
option of the lastline_setup command to
make these changes.
SMTP notifications
The Manager can be configured to send
notifications or reset account passwords using email. To configure the way email messages
are sent, use the email options of the lastline_setup command.
The Sensor can be configured to either passively or actively monitor and/or filter all email traffic into your network. See Configure email monitoring for further details and configuration options.
Configure Analysis Traffic Routing
The VMware NSX Network Detection and Response provides an analysis sandbox running on the Manager and Engine to examine suspicious files or URLs. The sandbox simulates various environments, including Windows 7, Windows 10, Microsoft Office, Chrome, a generic browser, and a PDF file viewer. Inside the simulated environment, the sandbox attempts to run the potentially malicious file or URL and analyzes the results of the execution.
In many cases, the runtime environment attempts to access resources on the Internet. To protect your environment and anonymize the public IP address of your client connections, the Manager is configured by default to route traffic generated inside its analysis sandbox to the Internet via a secure tunnel. This tunnel component is called AnonVPN (Anonymization VPN).
In addition to anonymizing the public IP address, AnonVPN periodically rotates the IP address with which connections to the Internet are made to avoid getting blocked when connecting to malware command-and-control infrastructure. The tunnel also prevents malware running inside the sandbox from accessing services in the local network. By routing traffic to outside the local network, only services reachable via public IP addresses are accessible to programs running inside the sandbox.
If your installation uses the Engine to perform suspicious content analysis, AnonVPN routes analysis traffic generated inside in its sandbox through the Manager to the Internet. AnonVPN only needs to be configured on Manager.
If you cannot make use of the AnonVPN feature, the
lastline_setup command allows you to
specify an alternate method for routing network connections. The following three modes are
supported:
-
lastline — Analysis traffic is routed via a secure tunnel. This is the default configuration.
-
honeypot — Analysis traffic is not routed to the Internet. Instead any connections established inside the sandbox are redirected to a honeypot on the appliance.
-
custom — Analysis traffic is routed via a dedicated interface that you have configured.
Configure Default AnonVPN
Manager uses AnonVPN to route traffic originating in the analysis sandbox. The VPN routes only outgoing connections and response packets. It blocks any in-bound connections.
The lastline mode of AnonVPN is
the system default. It only needs to be configured if you had previously implemented one of
the other modes.
Configure Honeypot AnonVPN
The VMware
NSX Network Detection and
Response provides a secure tunnel for traffic
generated inside the analysis sandbox, AnonVPN (Anonymization VPN), anonymizing the public IP address of client connections. For installations that cannot
use the VMware infrastructure due to security or
privacy requirements, a honeypot mode is available.
In this mode, analysis traffic is not routed to the Internet. Instead any connections established inside the sandbox are redirected to the honeypot on the appliance. This supports the analysis of artifacts in a completely isolated network, without any outgoing connectivity. Because samples undergoing analysis may attempt to access resources on the Internet, the system emulates a set of services that use well-known protocols, such as (but not limited to) DNS, FTP, HTTP, HTTPS, and SMTP.
Any outgoing traffic using an unknown protocol is blocked to avoid accessing services in the local network.
In honeypot mode, the analysis of URLs in the sandbox will fail. Since
no traffic is allowed out to the Internet, when a sample attempts to access a URL, the
connection fails, and an error is reported. As a consequence, the URL analysis fails and
no report is generated.
When running a honeypot without connectivity to the VMware backend, you should disable the cloud analysis component to avoid the timeout waiting for analysis metadata.
Configure Custom AnonVPN
To customize routing of analysis traffic, you must configure a dedicated network interface
on the system hosting the Manager using its
/etc/network/interfaces configuration file (see the interfaces.5 man page).
The dedicated interface can be a physical interface (such as eth3) or a
virtual interface (such as an OpenVPN tunnel interface tun0).
This interface has the following requirements:
-
The interface must be configured in
/etc/network/interfaces. -
The interface must use IPv4.
-
The interface must either use a static IP address or configured to invoke the
/etc/anonvpn/routing_interface_up.shcommand when it is assigned an IP address.The
routing_interface_up.shcommand is needed to trigger the setup of packet routing. For OpenVPN connections, the command can be invoked using the--upparameter. -
The interface must not be called
llanonvpn0orllanonvpn1. These interface names are reserved for connecting the Engine to the Manager and for interfaces in AnonVPNlastlinemode.
In addition to the interface configuration, you must provide the following information to enable custom routing:
- DNS server IP address
-
The IPv4 address of the DNS server which will be used for resolving domains inside the analysis sandbox. The DNS server must be reachable over the provided interface. DNS requests from the analysis engine will be routed over the same link as other analysis traffic.
- Gateway IP address
-
The IPv4 address of the gateway for routing packets on the custom interface. The gateway address must not be configured via
/etc/network/interfacesto avoid routing non-analysis traffic via this interface.
To switch to a custom network interface for the analysis sandbox, ensure that the dedicated
interface is up (use ifup interface-name, for example,
ifup tun0) and then configure the
AnonVPN options of the
lastline_setup command.
It is possible to route analysis traffic via the primary network interface on Manager. This configuration is highly discouraged as it gives the sample under analysis full access to your local network. It is your responsibility to block any potentially malicious connections routed this way.
The routing of analysis traffic via a custom network interface does not use a proxy even if one is configured.
Configure the Manager to use a custom VPN connection to route traffic originating inside the analysis sandbox. This VPN only routes outgoing connections and response packets. Thus, the VPN blocks any in-bound connections.
Configure the Analysis Upload-Size Limit
By default, the VMware NSX Network Detection and Response rejects uploads of files for analysis that are larger than 10 MB. This value provides a reasonable compromise between the ability to analyze the vast majority of malicious artifacts and having to store overly large files. If required, you can modify this limit up to 200 MB.
Configure Data Retention
The VMware NSX Network Detection and Response tracks all of the stored files on the appliance and issues a notification through the User Portal interface when usage of the local file-system disk exceeds certain thresholds.
Periodically, large analysis artifacts (such as the metadata that an analysis generates),
are deleted according to data-retention policies that can be updated using the lastline_setup command. The following is a full
list of data-retention options:
-
data_retention_uploads— Files uploaded for analysis. -
data_retention_screenshots— Screenshots taken during the dynamic analysis of a file submitted for analysis. -
data_retention_traffic_captures— Network traffic captured during the dynamic analysis of a file submitted for analysis. -
data_retention_generated_files— Files generated by a program during the dynamic analysis of a file submitted for analysis. -
data_retention_memory_dumps— Memory allocation by a program during the dynamic analysis of a file submitted for analysis. -
data_retention_process_dumps— Full-process snapshot of a program during the dynamic analysis of a file submitted for analysis. -
data_retention_webpages— Web-page content captured during the analysis of a URL submitted for analysis. -
data_retention_code— Web-code captured during the analysis of a URL submitted for analysis.
To avoid specific file-types from being affected by the data-retention policies, you can
use the value unlimited (or 0).
The following steps show how to define your configuration to discard files generated during an analysis run after 90 days, but to keep files uploaded for analysis indefinitely:
Configure Cloud Analysis
The VMware NSX Network Detection and Response cloud analysis component extends analysis results generated in the local On-Premises installation by querying and sharing data with the VMware backend.
This component allows an individual installation to contribute to and benefit from the global intelligence collected by VMware, Inc.. As a consequence, the analysis results generated when cloud analysis is enabled may be more accurate and may contain additional pieces of information (such as, file origin information, threat classification, more up-to-date analysis results). At the same time, sharing data with VMware, Inc. may not be desirable or even allowed in certain situations. Therefore, the cloud analysis component offers a number of configuration options to let you decide exactly what information gets shared.
-
cloud_analysis— When this option is enabled, your installation shares the hashes (MD5, SHA1, and SHA256) of the analyzed artifacts with the VMware backend. For file artifacts, the actual content is not uploaded to the VMware backend. -
cloud_analysis_push_download_source— When this option is enabled, your installation shares the IP address and hostname of the server where the artifact was downloaded from with the VMware backend. -
cloud_analysis_push_download_metadata— When this option is enabled, your installation shares the URL where the artifact was downloaded from (HTTP, FTP, and SMB downloads) with the VMware backend. In the case of HTTP downloads, the referrer information is also shared, if available. -
cloud_analysis_query_url_reputation— When this option is enabled, your installation queries the VMware backend for metadata that can be included in the URL classification. Note that the full URL is shared with the VMware backend.
When the analysis system detects a malicious file or URL, it is possible to notify the VMware backend about the detection by uploading the artifact content. Sharing this information helps us and the security community by increasing the global intelligence, while limiting your sharing to malicious files minimizes the risk of exposing sensitive files.
To configure the sharing of malicious files, review the Data sharing tab of the Appliances → Configuration pages provided by the User Portal running on your Manager.
Configure the Analysis Queue
In certain situations, it can be convenient to automatically drop tasks scheduled for analysis from the queue. This way even systems with limited resources can guarantee analyzing submitted artifacts in a timely manner, even when temporarily overloaded with a large number of submission.
The VMware NSX Network Detection and Response allows this by a configuration option that automatically deletes tasks from the analysis queue that have been pending for more than the specified number of days.
Configure Remote Assistance
By default, VMware
NSX Network Detection and
Response provides a mechanism to
allow the VMware Support team to perform remote
administration assistance on your Manager,
when requested. You can disable this access with the lastline_setup command.
Should you need to contact VMware Support, the VMware, Inc. technician will probably request that you temporarily re-enable the support channel.
Show the configuration
To view the current configuration of the VMware
NSX Network Detection and
Response
appliance, use the show option of the lastline_setup command.
Update Fully Qualified Domain Name
You can update the FQDN of the VMware NSX Network Detection and Response appliances. On the Manager, this update creates a new self-signed certificate associated with the FQDN.
After you complete the following steps on the Manager, you must update all the appliances managed by Manager to use its new FQDN (see 2).
This process does not allow you to move appliances from one Manager to another.
Applying an FQDN to other appliances such as the Data Node or Engine is entirely optional. These appliances are already known to the Manager. Most direct access is at best undesirable.
Appliance Management API
The VMware NSX Network Detection and Response provides the Appliance Management API as an interface to configure or re-trigger a configuration on an appliance.
The easiest way to invoke the Appliance Management API is to download and use the NSX PAPI client implementation.
Enable shell timeout
The setting interactive_shell_timeout allows a configurable timeout
for the duration that an interactive shell can idle before Bash terminates it.
By default the value is set to 0 which means no timeout.
Note that setting a shell timeout can lead to long running commands running in
interactive shells being interrupted before they can complete. Therefore, if this setting
is configured, we recommend that administrative tasks that require running any potentially
long-running shell commands be run within a tool such as screen or
tmux that can allow the commands to complete even after the shell times
out.
The setting can be configured using the Lastline Appliance Management API method
appliance_mgmt.action_request by providing the setting
interactive_shell_timeout with a value in seconds.
The following API parameter values are required:
-
appliance_uuid— You can obtain theappliance_uuidfrom the User Portal. Navigate to the Admin→Appliances→Status page. Scroll down to the Appliance UUID entry. The UUID can also be retrieved using the accounting API. -
action_type— The action typeCONFIGUREshould be used to configure an appliance. -
action_parameters— The JSON encoded object:'{"settings": {"appliance::user::interactive_shell_timeout": 600}}'
An example of using the Lastline Appliance Management API to configure this setting would look like the
following command using curl:
$ curl --cookie lastline-cookie \
--data 'appliance_uuid=a2a241d655f741969d12fbaadae795ac' \
--data 'action_type=CONFIGURE' \
--data 'action_parameters={"settings": {"appliance::user::interactive_shell_timeout": 600}}' \
--request POST 'https://<FQDN>/papi/appliance_mgmt/action/request'The session cookie (--cookie lastline-cookie) can be obtained by following the
Authentication Quick-Start guide.
Alternatively, you can use the NSX PAPI software from the User Portal with the following command:
client.appliance_mgmt.configure(
appliance_uuid=appliance_uuid,
settings={
"appliance::user::interactive_shell_timeout": 600, # 10 minute timeout
}
)The following API parameter values are required:
-
appliance_uuid— You can obtain theappliance_uuidfrom the User Portal. Navigate to the Admin→Appliances→Status page. Scroll down to the Appliance UUID entry. The UUID can also be retrieved using the accounting API. -
settings— Type and version specific settings to configure on the appliance.
User Portal
The User Portal (Web UI) provides support for both the Administrator and the Analyst roles. The Administrator uses the User Portal for configuration and management tasks.
Login to the User Portal
You access the User Portal with your web browser. The VMware NSX Network Detection and Response supports the following browsers:
-
Google Chrome on Windows, Linux, and macOS.
-
Mozilla Firefox on Windows, Linux, and macOS.
-
Microsoft Edge on Windows.
-
Safari on macOS.
You must use a recent version of your selected browser to ensure compatibility plus the most up-to-date security patches. The system is tested and warranted to work correctly with the listed browsers. Other modern browsers might also work correctly however VMware cannot support any issues you may encounter when using unsupported software.
Dashboard pages
The dashboard pages provide a general overview of the status of the VMware NSX Network Detection and Response installation and its observed events. The various widgets and lists on these pages display a high-level view of all relevant information related to your setup and the observed events.
You are redirected to the dashboard pages at each login to the User Portal. There are four predefined dashboard pages:
- Overview
- Network
- Files
Most of the widgets and lists are intended to help the Analysts role. The dashboard widget designed to be the most useful for the Administrator is the Sensors Status widget.
Sensors status widget
The Sensors Status widget provides a quick snapshot of the status of the Sensor appliances deployed in your VMware NSX Network Detection and Response installation. Each of the status field buttons — Up, Monitoring, ICAP, Mail, or Integrations — displays a ratio of status:server and are also color-coded.
Click the button to display a list of the deployed appliances. You can also click any of the status field buttons to toggle the display of the list.
Click the button to refresh the display.
Status list
The Sensor appliances list displays the following fields:
-
Name — Displays the name of the Sensor. Click the button to display a detailed view of the appliance.
-
Up — Displays the running status: Running, The sensor is offline, etc.
-
Monitoring — Displays the monitoring status.
-
ICAP — Displays the ICAP status.
-
Mail — Displays the email filtering status.
-
Integration — Displays the status of integrations with services such as Active Directory, SIEM servers, etc.
Manage users
Use the Admin → Accounts page to add and manage users on the User Portal.
The VMware NSX Network Detection and Response supports two basic user roles: the Administrator and the Analyst. In addition, there is a Read only role. You edit users to assign one of the roles to their accounts. Alternatively, you can use permissions to assign more granular access to users.
The Accounts page consists of the following tabs:
-
My account — Administer your user account and permissions.
-
All accounts — Manage existing accounts.
-
Add account — Create a new user account.
-
Audit log — View user access and actions.
About roles
A Role defines a set of permissions that you can apply to user accounts on the User Portal. A set of built-in roles are provided.
Using the Lastline API, you can create custom roles.
Roles descriptions
- Administrator
-
This role is for an administrator. It provides full read-write access to all functions of the User Portal. This role has the following permissions:
- Administrator — Can manage users
- Analyst
-
This role is for a full-fledged analyst. A user with this role can view most of data on system and operate on network/detection data. This role has the following permissions:
- Can access alerts
- Can access analyzed files
- Can access pcaps
- Can access sensitive analyzed files
- Can be workflow assignee
- Can manage custom threat intelligence entries
- Can manage intelligence alerting rules
- Can manage labels
- Can manage appliances
- Can view benign emails
- Can view custom threat intelligence entries
- Can view emails
- Can view intelligence alerting rules
- Read only
-
This role is for read-only access. It provides broad access to view the configuration and detection data, but no ability to make any kind of modifications. This role has the following permissions:
About permissions
Permissions define the specific system access rights granted to a user. These permissions can be fined tuned to different levels of granularity. Editing an account allows you to set specific permissions for each user.
Permissions are tiered. Each permission tier supersedes the tier below.
- Customer
-
Permissions set on the customer tier will grant an account these permissions globally across your environment and on all licenses and subkeys.
- License
-
Permissions set on a license will grant an account these permissions on that license and all its subkeys.
See About licenses for details about licensing.
- Subkey
-
Permissions set on a subkey will grant an account permissions on that subkey only.
See About licenses for details about licensing.
Permission descriptions
- Administrator
-
Tiers: Customer
Allows a user to manage other user accounts, such as creating new accounts, modifying or blocking existing accounts, and changing the password of other accounts. It also allows a user to manage licensing. This includes editing license details as well as creating new Sensor subkeys.
The Administrator permission implies all other permissions, so administrator accounts can perform all operations available through the User Portal and API.
- Can access alerts
-
Tiers: Customer License Subkey
Allows a user to view alerts and statistics from protected networks. It also allows viewing the status, monitoring logs and metrics from Sensor appliances. This permission can be granted globally, or limited to specific licenses or subkeys.
- Can access analyzed files
-
Tiers: Customer
Allows a user to download the original files submitted for analysis, when these are of a file type that is considered less sensitive, such as executables and scripts.
- Can access Kibana
-
Tiers: Customer
Allows a user to access network traffic analysis records using the Kibana visualization tool.
- Can access pcaps
-
Tiers: Customer License Subkey
Provides access to additional information collected from a protected network. Currently, this controls access to traffic captures (PCAPS) as well as the associated DNS data.
This permission can be granted globally, or limited to specific licenses or subkeys. It can be granted in addition to Can access alerts.
- Can access sensitive analyzed files
-
Tiers: Customer
Allows a user to download the original files submitted for analysis when these are of a file type that is considered more sensitive, such as Office or PDF documents.
This permission can be granted in addition to Can access analyzed files.
- Can be workflow assignee
-
Tiers: Customer License Subkey
Ability to be assignee for workflow items (for example, campaigns).
- Can manage appliances
-
Tiers: Customer License Subkey
Allows a user to view and manage appliance configurations. It also allows a user to install new appliances, as well as re-register or de-register existing appliances.
This permission can be granted in addition to Can view appliances.
- Can manage custom threat intelligence entries
-
Tiers: Customer
Ability to manage custom intelligence entries.
- Can manage intelligence alerting rules
-
Tiers: Customer
Permission to manage rules set to alert a customer when a matching artifact is indexed by the intelligence platform.
- Can manage labels
-
Tiers: Customer License Subkey
Controls access to several features:
-
Allows a user to make use of the incident workflow functionality available in the incidents tab, such as the ability to close and open incidents.
-
Allows a user to configure network-related display settings. These are the Home Network, the silenced IP Range and the host labels.
-
Allows a user to configure notification integrations for sending notification by email, syslog, or other mechanisms when an event happens.
-
Allows a user account to push detection information about a monitored network into the system through the Push Detection API. This can be used for integration with third party products.
This permission can be granted globally, or limited to specific licenses or subkeys.
-
- Can set password
-
Tiers: Customer
Allows the user to set, change, or reset the account password. This permission is usually set by default.
- Can view appliances
-
Tiers: Customer License Subkey
Allows a user to view the status of appliances. This includes access to the status, log, and metrics views of the appliance management UI.
- Can view benign emails
-
Tiers: Customer
Ability to view information about benign emails observed in a protected network.
- Can view custom threat intelligence entries
-
Tiers: Customer
Ability to get a listing of all custom threat intelligence entries and full information on individual entries.
- Can view emails
-
Tiers: Customer License Subkey
Ability to view information about emails observed in a protected network.
- Can view intelligence alerting rules
-
Tiers: Customer
Ability to view matches and rules set to alert a customer when a matching artifact is indexed by the intelligence platform.
View users
The All accounts tab displays a list of the users defined on the User Portal.
Add a user
Create a new user account on the Add account tab.
Set primary customer account
Each VMware customer, whether Hosted or On-Premises, is represented by a Primary customer account. The primary customer account is shown on the Admin → Accounts → License information tab. This information is used by VMware for billing notifications, to send out information about product updates and, if required, as the main contact person regarding questions about your VMware NSX Network Detection and Response installation.
Configure role and permissions
A new user account is assigned default permissions. You must update the account to add a role or to add or modify its permissions.
The Roles section allows you to set or remove the roles assigned to a user account. See About roles for details about the different roles available.
The Permissions section allows you to modify the individual permissions for a user account. See About permissions for details about the different permissions available.
You modify the role and permissions of the user account on the Account Settings page. This page is loaded after you click create on the Add account tab or when you click the icon for a specific user on the All accounts tab.
Edit a user
You edit user accounts on the Account Settings page. Change the password, update the email address, etc. This page is loaded after you click create on the Add account tab or when you click the icon for a specific user on the All accounts tab.
Also see Set primary customer account and Configure role and permissions.
Audit users
The Audit log tab allows you to view the access and actions of all of the users of the User Portal.
You can apply filters to the audit log list. Select an item to Filter by from the pull-down menu.
Use the Quick search field to display only those entries that have text, in any field, that matches your query string.
Scroll through the list to find audit events that of interest. Click the icon (or anywhere on an entry row) to expand a specific entry.
Manage licenses
Use the Admin → Licensing page to manage the licenses of your VMware NSX Network Detection and Response installation.
Your account will have at least one license provisioned by VMware. Depending on the layout and scale of your installation, you may have multiple VMware provisioned licenses.
You can subsequently create any number of subkeys from any VMware provisioned license. Each subkey is used to add a Sensor to your installation. They are also referred to as sensor licenses. The subkey always belongs to a specific license.
The Licensing page consists of the following tabs:
-
Licenses tab — View a list of all licenses for this installation.
-
License information tab — View and modify the current license information.
-
Sensors tab — View and modify all the available subkey licenses. You can also create a subkey license.
-
Sensor groups tab — View, create, and modify sensor groups.
View licenses
The Licenses tab displays all the licenses associated to this installation. The list includes the following fields:
License key — The unique identifier for the license.
-
Product — The product type associated to the license. Products hosted in the NSX Cloud are denoted with a icon.
-
License type — The type of license.
-
Installation key — Identifies the main license of an On-Premises installation.
-
Start date — The date when the license was initialized.
-
Expiration date — The date when the license expires.
Manage sensors
The Sensors tab displays all the available Sensor licenses. A Sensor license consists of a Sensor
key, which is a string you create, concatenated to your VMware generated customer License
key (for example, ABCDEFGHIJ0123456789:sensor-1). This license structure
allows the On-Premises
Manager or the VMware backend to quickly and correctly identify the Sensor when it connects.
About sensor groups
A sensor group is a correlation domain; a mechanism to correlate data from multiple sensors under a single identifying Sensor. All incidents and campaigns belong to the sensor group. The sensor group correlates events from its member sensors into incidents and campaigns. All events are detected by individual sensors and attributed to them. Incidents and campaigns are attributed to the sensor group. Events from sensors that are not part of the sensor group are not combined or correlated (however, they are combined within the sensor, allowing campaigns to be derived).
If a sensor is not part of a sensor group or if an incident was detected before the sensor was configured to be a member of a sensor group, that incident will be attributed to the individual sensor.
Some guidelines and features of sensor groups:
-
A group will only start aggregating new incidents after it is created. This means there won't immediately be any incidents or events for a new group.
-
A group is identified by a sensor. This sensor is the group identifier and is always listed first in the listing of sensors the group contains. It cannot be removed.
-
The group identifier should be an existing sensor, associated with an actual appliance. Select Existing sensor key when you create a group (see below).
-
A group name can only be changed by changing the name of its identifying sensor.
Sensor groups and notifications
The VMware NSX Network Detection and Response can be configured to send notifications to various third party systems. Notifications are triggered by different classes of events.
-
Notifications for network events are sent from the individual sensors. For an On-Premises installation, you can instead configure notifications to be sent from the manager.
-
Notifications for the intrusions are sent from the main sensor for the sensor group.
-
There are no separate notifications for incidents.
All members of a sensor group belong to the same license. You should apply the notification parameters to the license. Alternatively, you must individually configure the notification parameters for each sensor in the sensor group. Using a sensor group to configure notifications for a set of sensors is not supported.
Under certain circumstances, intrusion notifications may not work correctly:
-
If notifications are sent from the sensors
-
The sensors belong to a sensor group
-
The group identifier is tied to a virtual sensor or to a sensor that is currently not running
The workaround is to ensure the group identifier source is an existing physical sensor.
Manage sensor groups
Manage your sensor groups on the Sensor groups tab.
Manage appliances
Use the tabs on the Admin → Appliances page to manage the appliances of your VMware NSX Network Detection and Response installation. You can view an overview of the active appliances, inspect the configuration of a selected appliance and make changes, and view the logs and other metrics for all appliances or a specified appliance.
For a On-Premises environment, you will have at least one Manager, as well as Data Node, Engine, and Sensor appliances.
For a Hosted environment, you will have one or more Sensor appliances to manage.
The Appliances page consists of the following tabs:
-
Overview tab — View a map showing the locations of all the appliances in this installation. This tab also displays a listing with information about each of the appliances.
-
Status tab — View the current status of a selected appliance.
-
Configuration tab — Modify the configuration settings of a selected appliance.
-
Action logs tab — View status changes made to the selected appliance.
-
Monitoring logs tab — View the monitoring logs from the selected appliance or appliances.
-
Metrics tab — View performance metrics of the User Portal and the various appliances.
View appliances
The Overview tab displays the locations of the active appliances in your VMware NSX Network Detection and Response installation on a map. It also displays a listing with information about the appliances.