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.com
onTCP/443
(in Europeuser.emea.lastline.com
). -
update.lastline.com
onTCP/443
(in Europeupdate.emea.lastline.com
). -
ntp.lastline.com
onUDP/123
for 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.com
onTCP/443
(in Europelog.emea.lastline.com
). -
anonvpn.lastline.com
onUDP/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.sh
command when it is assigned an IP address.The
routing_interface_up.sh
command is needed to trigger the setup of packet routing. For OpenVPN connections, the command can be invoked using the--up
parameter. -
The interface must not be called
llanonvpn0
orllanonvpn1
. These interface names are reserved for connecting the Engine to the Manager and for interfaces in AnonVPNlastline
mode.
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/interfaces
to 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_uuid
from 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 typeCONFIGURE
should 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_uuid
from 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.
Set geolocation
By default, a geolocation database is used to define the physical location of each appliance. Although this technique for determining the location of the appliance is generally accurate, there might be cases where the databases are out of sync, and the appliance location is not exact. You can manually correct the appliance location.
Appliance actions
The Appliance list allows you to check license information and perform a number of actions with the Quick links button for each listed appliance. Perform the following tasks on the Overview tab:
View appliance status
The Status tab displays the current configuration of the selected appliance. This tab can directly accessed from the Overview tab by clicking the Quick links button. If you accessed this tab by clicking the Status tab, you must select an appliance using the . button
Information displayed on this tab includes:
-
The currently deployed version of the appliance.
-
The update status of the appliance.
-
The installed version and current status of a number of services that are running on the appliance.
Rows in the list may be highlighted in green, yellow, or red to indicate whether the appliance is functioning as expected. The icon next to an item indicates that more information is available. Click the icon to access the information.
Use appliance selector widget to select an appliance to view. If no appliance is initially selected, click the and select an appliance from the buttonSelect appliance pop-up.
At any time, you can click the
icon to refresh the appliance data.Some optional configuration actions for the appliance are available from this page. To access them, click the icon and then select an action from the pull-down menu. Select Reboot, Retrigger configuration, or Deregister.
When you need to replace hardware or otherwise need to change an appliance, you must first use the Deregister option to release its license. You can deregister the following appliances:
Data Node
Engine
Sensor
Instead of the icon, your configuration may display the icon. Click this icon to access the Sensor test page. Network traffic is created to test the sensor capabilities. Click the Start test button to start the test.
Configure the Manager
Use the different options on the Configuration tab to manage the settings of the Manager. The Manager settings are where you control the data retention rules for your installation as well as which data you are willing to share with the VMware backend.
Configure the Data Node
Use the options on the Configuration tab to manage the settings of the Data Node.
Configure the Engine
Use the options on the Configuration tab to manage the settings of the Engine.
Configure the Sensor
The main purpose of the Sensor is to perform active or passive inspection of your network traffic. The data and traffic it inspects ranges from file transfers and email messages to metadata on network activities. The Sensor settings are where you configure the detection and blocking rules, email processing, proxy capability, and system settings:
Configure detection and blocking
Use the Configuration: Detection and blocking tab to manage the Sensor detection and blocking options.
Configure email monitoring
The Sensor can be configured to passively sniff email traffic or to actively participate in the email processing chain in your environment. The Sensor supports sniffing SMTP traffic or running as an IMAP or POP3 client, an MTA end node, or an inline MTA relay.
Configure SMTP traffic sniffing
During registration, the Sensor is configured by default for passive sniffing (see the Sensor Installation and Administration guide for details about sniffing interfaces configuration). The Sensor uses the sniffing interface to examine the traffic available on the wire.
Configure IMAP/POP
You can configure the Sensor as an IMAP or POP3 client. Your MTA server must be configured to blind-copy all inbound messages to the designated user account on the Sensor. A major limitation of this method is that you can only see inbound messages.
All messages received by the monitoring account are deleted after analysis.
Configure MTA (no delivery)
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 your MTA server to FORK all inbound messages to the Sensor. A major limitation of this method is that you can only see inbound messages.
All messages received by the monitoring account are deleted after analysis.
Configure MTA relay
The most highly recommended configuration is active email monitoring. The Sensor is configured as an MTA relay. 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. In addition, it allows the Sensor to either quarantine messages with malicious content or to clean the malicious content from the messages before sending them onward to the next hop.
This mode requires that the email flow into your organization is configured to add the Sensor as an MTA hop in your email processing.
Configure proxy
Use the Configuration: Proxy tab to manage the proxy option for the Sensor. This option is used for detecting traffic going through web proxies. The Sensor supports ICAP.
Configure ICAP proxy
ICAP integration allows a third party proxy server or security appliance to use the ICAP protocol to offload its HTTP traffic to the Sensor for the analysis and blocking of malicious content. See VMware NSX Network Detection and Response ICAP Integration for more information.
Configure the ICAP options:
Configure system settings
Use the options on the Configuration: System tab to manage the Sensor monitoring interfaces and other system settings.
Monitor appliances
The User Portal provides logging and metrics information on the Appliances page.
-
The Appliances → Action logs tab displays status changes made to the current appliance.
-
The Appliances → Monitoring logs tab displays the monitoring logs from the selected appliance(s).
-
The Appliances → Metrics tab contains a number of sub-tabs that you use to monitor the VMware NSX Network Detection and Response. The sub-tabs display statistics about the state of the appliances, the artifacts and email messages that have been processed, network traffic that has been observed and processed, system loads, ICAP transactions, and the records used for network analysis.
Backup appliances
Use the tabs on the Admin → Backup page to configure and manage periodic backups, and if needed, restores, of the On-Premises installation of the VMware NSX Network Detection and Response. A backup consists of the user data stored on the Manager, including network events and traffic captures, analyzed files, and analysis results.
The Backup page consists of the following tabs:
-
Jobs tab — Display a list of backup jobs.
-
Restore tab — Select a backup and restore it on the system.
-
Configure backups tab — Configure a named backup process.
-
Configure storage tab — Configure and manage backup storage locations.
About the jobs tab
Use the Jobs tab to view the list of backup jobs. Set a range of dates.
Click the From or To
buttons to open a calendar widget. You can also enter a
date directly in the From or To textboxes using the
format YYYY-MM-DD
. Then click to
search for relevant backup jobs.
The Backups jobs list displays the backup jobs that were found in the selected date range. The list includes the following fields:
-
Start time — The date and time the backup was started.
-
Duration — The length of time the backup took.
-
Size — The size of the backup.
-
Job type — The type of job (for example, Backup or Restore).
-
Backup name — The name of the backup configuration.
-
Backup type — The type of backup (for example, Full or Incremental).
-
Job status — The status of the job (for example, Waiting, Running, Success, or Failed). Click the icon to refresh the list.
About the backups tab
Use the Configure backups tab to configure and manage your backups. If there is at least one backup, it displays the existing backup configurations in the Backup Configuration list. The list includes the following fields:
-
Name — The name of the backup configuration.
-
Storage — The name of the configured backup storage.
-
Last backup type — Either Full or Incremental.
-
Last backup start — The date and time the last backup started.
-
Last backup end — The date and time the last backup ended.
-
Last backup status — Possible values are Waiting, Running, Success, or Failed.
Use the quick search field above the Backup Configuration list to find a specific backup configuration.
You delete backup configurations from this tab. Deleting a configuration does not delete any of your backups. It only removes the access information.
About the storage tab
Use the Configure storage tab to define and manage the backup storage locations. VMware NSX Network Detection and Response backups can be stored to an Amazon S3 bucket or to an SSH server. The tab has two sections:
Storage configuration
The Storage configuration section may contain two lists: the SSH configurations list and the Amazon S3 configurations list. These lists are only displayed if there is at least one storage back-end of the corresponding type.
Use the quick search field above the lists to find a specific backup storage entry.
You delete backup storage configurations from this tab. Deleting a configuration does not delete any of your backups. It only removes the access information.
SSH
An SSH server can be used to store backups. Key-based authentication must be configured to allow the Manager to connect to the SSH server.
The server you select for your SSH storage backend must be running a Linux operating system. Ubuntu SSH servers have been tested and are supported. Using a Windows server is not supported.
Do not use the Managers or its child appliances to store the backups.
The SSH configurations list includes the following fields:
-
Storage name — The name of the storage location.
-
Server name — Hostname or IP address of the SSH server where backups will be stored.
-
Server base — Base path on the SSH server where the backups will be stored.
-
Username — User account used to access the SSH server.
-
SSH key — SSH Key used to authenticate to the SSH server.
-
SSH port — The port used to connect to the SSH server.
Amazon S3
Amazon Simple Storage Service (Amazon S3) is an object storage service of Amazon Web Services (AWS). You must have an IAM account that gives you full read and write access to the S3 bucket to be used as the data storage for your backups.
The Amazon S3 configurations list includes the following fields:
-
Storage name — The name of the storage location.
-
AWS key ID — The access ID generated by AWS for the authorized account.
-
Bucket name — The name of the S3 bucket.
SSH key management
If there is at least one SSH key, the SSH Key Management list is displayed. It includes the following fields:
-
Name — The name of the SSH key.
-
Public key — Clicking the View pub key button displays the public key in a pop-up.
-
Key size — The number of bits in the key.
Configure backups
The creation and management of VMware NSX Network Detection and Response backups is performed using the Configure backups and Configure storage tabs.
Before you can create a backup configuration, you must first define a backup storage location to use. The system supports storing backups to an Amazon S3 bucket or to an SSH server.
Restore a backup
The VMware NSX Network Detection and Response provides a mechanism to restore the system from a backup in the event of a critical data loss.
Depending on the amount of data in the backup, the restore process can take a considerable amount of time during which the User Portal interface will non-responsive. As soon as the process has completed successfully, you will be able to access the interface using one of the accounts that were restored by the backup.
The restore process reset credentials to their state at the time of backup. Any credentials that were added or modified after the time at which the backup was taken will need to be manually updated or recreated.
Recover from disaster
To recover from a disaster, you may need to restore a VMware NSX Network Detection and Response appliance from your backups. Contact VMware Support for assistance with licenses and other issues.
Restoring from a backup will overwrite any data on the appliance, replacing it with the data contained in the backup.
If the Manager was re-installed as part of
the backup restore process, the system might have invalidated API credentials, such as the
API-token used to access the Analyst-API. As a result, external Engine appliances need to be re-configured
using the lastline_engine_config -f
command. For details, refer to the
Engine Installation and
Administration guide.
Restoring from a backup is performed with the following steps:
Notifications
The VMware NSX Network Detection and Response can send notifications to various third party systems. Configure the required connections and triggers on the tabs of the Notifications page:
-
Email notification tab — Configure email notifications for the appliances.
-
Configure HTTP notifications — Configure HTTP/HTTPS
POST
notifications. -
Configure streaming notifications — Configure a notification stream.
-
Configure Syslog notifications — Configure a SIEM appliance and/or syslog server to receive notifications.
-
Configure TippingPoint notifications — Configure sending notifications to a TippingPoint Security Management System (SMS).
-
Configure detection reports — Configure and view reports that provide an overview of detections.
About notification triggers
Notifications can be triggered by different classes of events.
When configuring a notification, you must specify which trigger(s) will enable notifications. Each trigger can have customized settings. When the notification is first created, a default list of triggers will be selected with default settings.
A notification will have one or more trigger groups. A trigger group is a list of triggers.
Each row that is highlighted blue is an enabled trigger. Click to toggle the trigger to disabled. Click to modify the trigger parameters.
The entire trigger group can be toggled by clicking the Enabled button in the trigger group header. This collapses the trigger group and sets all the now hidden triggers to disabled. You cannot save the notification if it has only one trigger group and you have disabled it.
Modify trigger parameters
To modify a trigger, update the following:
- Min interval
-
The minimum amount of time between notifications. Select Minutes (the default) or Hours.
- Threshold
-
The minimum impact level which will trigger the notification. The impact level range is 30 to 100. Any event with an impact level below 30 is considered benign and will not trigger a notification.
- Max Daily
-
Maximum number of notifications that can be triggered over a 24 hour period.
When you are done, click the Update trigger button. The parameters are saved and the pop-up dismissed.
Click Reset to return the trigger to the previously saved parameters.
Click Defaults to reset the trigger parameters to default values.
Click Cancel to dismiss the pop-up without saving any changes.
Sensor group notifications
All members of a sensor group belong to the same license. The recommended method is to 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 (see About sensor groups).
-
Notifications for network events are sent from the individual sensors. For an On-Premises installation, you can 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.
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.
Configure email notifications
Configure email notifications for the VMware NSX Network Detection and Response appliances using the Email notification tab. These email notifications can be configured with various options, such as the frequency of alerts, maximum number of alerts in a day, and the types of alerts that trigger a notification. In addition to these settings, the syntax of the email subjects can be modified to your preference.
You can create a new notification or edit an existing notification.
Configure HTTP notifications
Configure HTTP or HTTPS notifications for the VMware NSX Network Detection and Response using the Generic HTTP notification tab. These notifications can be configured with various options, such as the frequency of alerts, maximum number of alerts in a day, and the types of alerts that trigger a notification.
See the VMware NSX Network Detection and Response HTTP Post Integration guide for additional configuration details.
You can create a new notification or edit an existing notification.
Configure streaming notifications
Create a notification stream that retrieves information about specific events which are selected based on trigger configurations using the Streaming API tab. Triggers, like in other notification types, can be tailored by frequency, quantity per day, and specific types of alerts.
See the VMware NSX Network Detection and Response Streaming API Integration guide for additional configuration details.
You can create a new notification or edit an existing notification.
Configure Syslog notifications
Use the Syslog tab to specify a Security Information and Event Management (SIEM) appliance and/or syslog server where VMware NSX Network Detection and Response events can be sent. These notifications can be configured with various options, such as the frequency of notifications, maximum amount of notifications in a day, and the types of alerts that trigger the notifications.
See the VMware NSX Network Detection and Response Syslog Integration guide for additional configuration details.
You can create a new notification or edit an existing notification.
Configure TippingPoint notifications
Configure integration with the TippingPoint Security Management System (SMS) using the TippingPoint tab. This integration allows a VMware NSX Network Detection and Response server to push reputation information to the TippingPoint SMS server based on the threats it detects on the monitored network.
When malicious network behavior is detected, an appliance will, depending on configuration, push to the SMS server reputation information about the source or destination host involved in the malicious traffic. A network administrator can use this information in the policies deployed by the SMS server, for example, to automatically block traffic to hosts that the system has detected are acting as Malware Command and Control servers. In the terminology of TippingPoint SMS, these policies are called Reputation Filters.
The reputation information about a host that the system can push to TippingPoint SMS is structured into the following five tag categories:
- Malware Class
-
String
in the format:{infected|malicious}:Malware Class Name
Malware Class Name
is the name of a Malware Class as displayed in the details of the detection in the VMware NSX Network Detection and Response interface.The prefix
infected:
is used for the client hosts (typically within the network) that are victim of the detected malware, such as an infected host that is calling out to a Command and Control server, or a client that was subject to a Drive-By attack.The prefix
malicious:
is used for server hosts (typically outside the network) that are hosting the detected Malware, such as a Command and Control server or a web server distributing exploits or Malware binaries. - Impact
-
Integer
in the range 1-100. The impact of the detected event. This corresponds to the impact score displayed in the event details. - Confidence
-
Integer
in the range 1-100. The confidence of the detection. - Last Seen
-
Datetime
. The timestamp of the most recent occurrence of the detected malicious behavior. - Event URL
-
URL
. A URL to the details about the detection in the system interface.
Before reputation information can be pushed to an SMS server, the tag categories used by the system need to be imported into the TippingPoint SMS Server. A definition of these five tag categories, plus the three additional tag categories used by TippingPoint Reputation DV, is available for download.
Configure detection reports
You can configure and view reports that provide an overview of detections by the Sensor. These reports might help you to determine the notifications you need to configure. The reporting settings allow you to specify email addresses and choose the frequency of reports for the email reporting function.
You can create a scheduled report, generated in PDF or HTML format, or an on-demand report in PDF format.
The Reports tab displays a list of Scheduled reports. The list contains the following fields:
-
Sensor — The sensor that is providing the data. This is displayed, for example, as
ABCDEFGHIJ0123456789:sensor-1
. -
Periodicity — The frequency that reports are generated and received. This can be on a daily, weekly, monthly, or quarterly basis.
-
Format — Scheduled reports are generated in HTML or PDF format.
-
Owner — The email address of the user that created the scheduled report. This is not necessarily the email address of the recipient.
-
Enabled — The status of the scheduled report.
Create a scheduled report with the following steps:
Generate on-demand reports
In the On-demand Report section, you can generate an on-demand report in PDF format.
Data sources
THe VMware NSX Network Detection and Response can interact with various third party systems, ingesting data and providing additional network visibility.
-
Active Directory integration — Active Directory integration enhances the system by providing user information from the Domain Controllers.
-
AWS integration — Configure credentials for Amazon AWS. You can authenticate to AWS using an access key or an IAM role. Use the credentials to configure collectors for Amazon VPC flow logs.
-
DHCP integration — Configure collectors that can receive and process DHCP records produced by an external generator.
-
Flow records integration — Configure collectors that can receive flow records from third-party devices.
Active Directory integration
The integration of Active Directory technology, developed by Microsoft for Windows operating systems, enhances VMware NSX Network Detection and Response by providing additional information extracted from the Domain Controllers. This information details the Windows users that are logged in on hosts in the network. The system is thus able to associate events that occur in the monitored network with the Windows users logged in on the host. You can then immediately identify the users that have been exposed to a detected threat and take appropriate measures.
Before the Sensor can pull information from Active Directory, the Windows network must be properly configured. See the VMware NSX Network Detection and Response Active Directory Integration guide for additional configuration details and requirements.
Once the configuration is complete and the system has had time to gather data, you can view user login events from the configured Domain Controller servers on the Network → Events page by clicking the User tab.
AWS integration
AWS Flow logs capture information about the IP traffic traversing an AWS VPC. The flow log data can be published to Amazon S3 logs and Amazon CloudWatch. You can then integrate the flow logs for ingestion by the VMware NSX Network Detection and Response.
Before the system can ingest flow logs, you must configure AWS credentials.
See the VMware NSX Network Detection and Response AWS flow logs guide for additional configuration details and requirements
Configure AWS credentials
To obtain the Access key ID and
Secret access key, login to your AWS IAM
dashboard and select the appropriate account. On the Summary
page, select the Security credentials tab. Click Create access
key to generate a new Access key ID and Secret
access key. Amazon encourages you to download these credentials in
csv
format. There is no subsequent way of obtaining the secret access
key. However, you can always create another key pair.
The IAM role should be configured with the minimal security policy recommended by ScoutSuite. An IAM role can only be used with a Sensor running as an AWS instance.
See the Sensor on AWS Deployment and Administration guide for further details.
Configure AWS authentication on the AWS credentials tab. These credentials are used for the collection of VPC flow logs or the acquisition of AWS Cloud Asset data. You can authenticate to AWS using an access key or an IAM role.
Configure an S3 collector
On AWS, configure your VPC to send flow logs to Amazon S3. See the guide for additional configuration details and requirements
Configure AWS credentials. You must configure Access and Secret Key credentials.
Configure the User Portal to ingest flow logs from Amazon S3.
Configure a CloudWatch collector
On AWS, configure your VPC to send flow logs to Amazon CloudWatch logs. See the VMware NSX Network Detection and Response AWS flow logs guide for additional configuration details and requirements
Configure AWS credentials. You must configure Access and Secret Key credentials.
Configure the User Portal to ingest flow logs from Amazon CloudWatch.
DHCP integration
You can forward DHCP logs to the VMware NSX Network Detection and Response for ingestion and processing. The primary reason to collect DHCP logs is the ability to correlate the origin of an event detected by the Sensor with the IP address a host was using at the same time.
Before the Sensor can pull DHCP logs, the Windows network must be properly configured. See the VMware NSX Network Detection and Response DHCP Integration guide for additional configuration details and requirements.
Saving the collector triggers a reconfiguration on the sensor, after which a DHCP ingestion process is ready to receive DHCP logs on the specified port number. The progress of the reconfiguration action can be followed on the Admin→Appliances→Monitoring logs tab.
Flow records integration
Configure the Sensor to receive flow records from third-party devices (for example, switches and routers) on the Flow collection tab. These records are then uploaded to the VMware backend for indexing and analysis.
Flow records describe a sequence of packets with common characteristics, such as the same source and destination IP address, transport layer port information, and type of protocol. Importing flow records from a third-party device is useful when you want the VMware NSX Network Detection and Response to have visibility into the traffic flowing in parts of the network that are not monitored by a Sensor (the Sensor generates flow records information of the traffic it monitors).
To configure a third-party device to generate flow records and send them to the Sensor, refer to the manufacturer's configuration guide. In general, ensure that:
-
The destination port configured on the third-party device matches the port number configured for the flow collector.
-
The protocol configured on the third-party device matches the protocol configured for the flow collector.
-
The flow type configured on the third-party device matches the flow type configured for the flow collector.
If there are issues with your flow collection configuration, refer to the following support article: Troubleshooting the flow integration.
Appendices
Installation and integration guides
For installation and initial configuration details, refer to the following guides:
For integration of VMware NSX Network Detection and Response with third-party solutions, refer to the following guides:
-
VMware NSX Network Detection and Response Active Directory Integration
-
VMware NSX Network Detection and Response HTTP Post Integration
-
VMware NSX Network Detection and Response RADIUS Integration
-
VMware NSX Network Detection and Response SAML Single Sign On
-
VMware NSX Network Detection and Response Streaming API Integration
-
VMware NSX Network Detection and Response Syslog Integration
For deployment of the Sensor to Azure and AWS cloud environments and initial configuration details, refer to the following guides:
Setup command options
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.
Command line arguments
The lastline_setup
command supports the
following command line arguments:
- Help
-
-h, --help
Print the help message and exit.
- Acquire lock
-
--lock-timeout TIME
The
lastline_setup
command has a configuration lock to prevent more than one user from accessing its database at the same time. Set the amount of TIME (in seconds) to allow for acquiring the lock. The default is 0 (zero) seconds.
Configuration options
The available options varies depending on the type of appliance. The Manager has an extensive set whereas the Sensor has fewer options. To view all the
supported options for the current appliance, use the help
option.
To view a detailed description of individual options, type help
topic
, where topic
is
the name of a specific option.
The lastline_setup
command supports the
following configuration options:
- Maximum file upload size
-
analysis_max_upload_filesize_mb [= size]
Display or set the maximum file size (in MB) the system will accept for analysis. With no argument, display the current maximum file size allowance. If an argument is provided, set maximum file size allowance to the specified value. The argument
size
must be numeric. - Length of analysis queue
-
analysis_queue_backlog [= days | unlimited]
Display or set the number of days to keep unprocessed tasks in the analysis queue. With no argument, display the current number of days. The default is
unlimited
. If an argument is provided, set the number of days to the specified value. The argumentdays
can numeric orunlimited
(or0
). - AnonVPN DNS server
-
anonvpn_dns_server_ip [= IPaddr | -]
You can configure a DNS server specifically for AnonVPN to assist with anonymizing client connections.
Display or set the IP address for the DNS server for AnonVPN. With no argument, display the current IP address of the AnonVPN DNS server. If an argument is provided and is an IP address, set the DNS server to the specified value. You must provide a valid IPv4 address for the DNS service. This address must be reachable via the AnonVPN interface. If the argument is
-
(dash), clear (unset) the DNS server address. - AnonVPN mode
-
anonvpn_mode [= lastline | honeypot | custom | -]
Display or set the AnonVPN mode. With no argument, display the current setting. If an argument is provided and is one of lastline, honeypot, or custom, set the mode to the specified value.
If the value is
-
(dash), clear the mode (set to an empty value). This argument should not be used. - AnonVPN gateway
-
anonvpn_upstream_gateway_ip [= IPaddr | -]
Display or set the AnonVPN upstream gateway address. With no argument, display the current IP address of the gateway. If an argument is provided and is an IP address, set the gateway to the specified value. Any valid IPv4 address can be used for the gateway. This address must be in the same subnet as the IP address assigned to the AnonVPN interface. If the provided argument is
-
(dash), clear (unset) the gateway address.This setting is not required for point-to-point tunnel connections (for example, OpenVPN).
- AnonVPN interface
-
anonvpn_upstream_ifname [= interface | -]
Display or set the AnonVPN upstream interface. With no argument, display the current interface name. If an argument is provided, set the interface name to the specified value. You can specify any valid interface name other than
llanonvpn0
orllanonvpn1
. If the argument is-
(dash), clear the interface name (set to an empty value). - Appliance state
-
appliance_state
Display the appliance state. For example,
active
,error
,offline
, etc. - Appliance UUID
-
appliance_uuid
Display the appliance UUID. For example,
0123456789abcdef0123456789abcdef
. - Cloud analysis
-
cloud_analysis [= on | off]
Display or set analysis support. With no argument, display the current status. If an argument is provided, set cloud analysis support to the specified value. Possible values are on or off. When enabled, hashes (MD5, SHA1, and SHA256) of the analyzed artifacts are shared with the NSX Cloud.
- Download metadata for cloud analysis
-
cloud_analysis_push_download_metadata [= on | off]
Display or set support to allow sending artifact metadata (download origin, filename, type, etc.) to the NSX Cloud. With no argument, display the current status. If an argument is provided, set the download support to the specified value. Possible values are on or off. When enabled, the URL the artifact was downloaded from (HTTP, FTP, and SMB downloads) is sent to the VMware backend.
- Download URL for cloud analysis
-
cloud_analysis_push_download_source [= on | off]
Display or set support to allow sending artifact download origin to the NSX Cloud. With no argument, display the current status. If an argument is provided, set the download support to the specified value. Possible values are on or off. When enabled, the IP address and host name of the server the artifact was downloaded from are sent to the VMware backend.
- Query URL reputation from cloud analysis
-
cloud_analysis_query_url_reputation [= on | off]
Display or set support to allow requesting URL reputation data from the NSX Cloud. With no argument, display the current status. If an argument is provided, set the URL classification support to the specified value. Possible values are on or off. When enabled, the VMware backend is queried for reputation metadata that can be used to classify a URL. The full URL is shared with the VMware backend.
- Data retention for code
-
data_retention_code [= days | unlimited]
Display or set the number of days to retain Web-code captured during an analysis run of a submitted URL. With no argument, display the current number of days. If an argument is provided, set the number of days to the specified value. The argument
days
can numeric orunlimited
(or0
). - Data retention for generated files
-
data_retention_generated_files [= days | unlimited]
Display or set the number of days to retain files generated by a program during a dynamic analysis run. With no argument, display the current number of days. If an argument is provided, set the number of days to the specified value. The argument
days
can numeric orunlimited
(or0
). - Data retention for memory dumps
-
data_retention_memory_dumps [= days | unlimited]
Display or set the number of days to retain memory buffers allocated by a program during a dynamic analysis run. With no argument, display the current number of days. If an argument is provided, set the number of days to the specified value. The argument
days
can numeric orunlimited
(or0
). - Data retention for process dumps
-
data_retention_process_dumps [= days | unlimited]
Display or set the number of days to retain full-process snapshots of a program during a dynamic analysis run. With no argument, display the current number of days. If an argument is provided, set the number of days to the specified value. The argument
days
can numeric orunlimited
(or0
). - Data retention for screenshots
-
data_retention_screenshots [= days | unlimited]
Display or set the number of days to retain screenshots taken during a dynamic analysis run. With no argument, display the current number of days. If an argument is provided, set the number of days to the specified value. The argument
days
can numeric orunlimited
(or0
). - Data retention for traffic captures
-
data_retention_traffic_captures [= days | unlimited]
Display or set the number of days to retain network traffic captured during a dynamic analysis run. With no argument, display the current number of days. If an argument is provided, set the number of days to the specified value. The argument
days
can numeric orunlimited
(or0
). - Data retention for uploads
-
data_retention_uploads [= days | unlimited]
Display or set the number of days to retain files uploaded for analysis. With no argument, display the current number of days. If an argument is provided, set the number of days to the specified value. The argument
days
can numeric orunlimited
(or0
). - Data retention for webpages
-
data_retention_webpages [= days | unlimited]
Display or set the number of days to retain Web page content captured during a dynamic analysis run. With no argument, display the current number of days. If an argument is provided, set the number of days to the specified value. The argument
days
can numeric orunlimited
(or0
). - Comment on analysis reports
-
disable_report_commenting [= true | false | -]
Display or set the ability to comment on analysis reports. With no argument, display the current status. If an argument is provided, set the ability to comment to the specified value. Possible values are
true
orfalse
. If the argument is-
(dash), clear the field (this is the same as setting the value tofalse
). - Disable the support channel
-
disable_support_channel [= true | false | -]
Display or set the support channel. With no argument, display the current status. If an argument is provided, set the support channel to the specified value. Possible values are
true
orfalse
. The default (false
) allows VMware Support to perform remote administration assistance at your request. If the argument is-
(dash), clear the field (this is the same as setting the value tofalse
). - Edit variables
-
edit [variable]
Edit the value stored for the entered variable. A prompt for entering a new value for the variable is displayed. If the variable being edited is a password variable, your input will not be displayed.
To view a list of the variables available for editing, run the
edit
option with no argument. - Email relay host
-
email_relay_host [= IPaddr | hostname | -]
Display or set the host name or IP address for the SMTP relay host. With no argument, display the current host. If an argument is provided, set the host to the specified value. If the argument is
-
(dash), clear (unset) the host. In this case, the VMware backend is used. - Email relay password
-
email_relay_password [= password | -]
Display or set the authentication password for the SMTP relay host. With no argument, display the current password. If an argument is provided, set the password to the specified value. If the argument is
-
(dash), clear (unset) the password. - Email relay port
-
email_relay_port [= port | -]
Display or set the port number for the SMTP relay host. With no argument, display the current port. If an argument is provided, set the port to the specified value. If the argument is
-
(dash), clear (unset) the port. - Email relay username
-
email_relay_username [= username | -]
Display or set the username for the SMTP relay host. With no argument, display the current username. If an argument is provided, set the username to the specified value. If the argument is
-
(dash), clear (unset) the username. - Email sender address
-
email_sender_address [= address | -]
Display or set the email address to be used for delivering email. With no argument, display the current email sender address. If an argument is provided, set the sender address to the specified value. If the argument is
-
(dash), clear (unset) the sender address. - Failover multicast address
-
failover_multicast_address [= address | -]
Display or set the multicast address needed by the tools used for managing the shared virtual IP between active and standby Manager in an active/standby configuration. With no argument, display the current value of the failover multicast address. If an argument is provided, set the address to the specified value. If the argument is
-
(dash), clear (unset) the failover multicast address. - Failover multicast port
-
failover_multicast_port [= address | -]
Display or set the multicast port needed by the tools used for managing the shared virtual IP between active and standby Manager in an active/standby configuration. With no argument, display the current value of the failover multicast port. If an argument is provided, set the port number to the specified value. If the argument is
-
(dash), clear (unset) the failover multicast port.There is no standard multicast port number. VMware NSX Network Detection and Response uses
5405
as its default. - Failover virtual IP address
-
failover_virtual_ip [= address | -]
Display or set the virtual IP address shared between active and standby Manager in an active/standby configuration. With no argument, display the current value of the virtual IP address. If an argument is provided, set the virtual IP address to the specified value. If the argument is
-
(dash), clear (unset) the virtual IP address. - Fully qualified domain name
-
fqdn
Display the fully qualified domain name of the appliance.
- Active manager priority
-
ha_active_priority [= priority | -]
Display or set the priority of the active Manager for the purposes of determining ownership of the shared virtual IP address in an active/standby configuration. Select a value higher than the highest priority recently used for this virtual IP address.
With no argument, display the current value of the active manager priority. If an argument is provided, set the priority to the specified value. If the argument is
-
(dash), clear (unset) the active manager priority. - Active manager password
-
ha_password [= password | -]
Display or set the password for managing the virtual IP address shared between active and standby Manager in an active/standby configuration. With no argument, display the current active/standby password (displayed as
***
). If an argument is provided, set the password to the specified value. If the argument is-
(dash), clear the active/standby password (set to empty value). - HTTPS proxy
-
https_proxy [= proxy_address:port | -]
Display or set the HTTPS proxy. With no argument, display the current proxy. If an argument is provided, set the proxy to the specified value. The HTTPS proxy must be in the format
proxy_address:port
(for example,proxy.example.com:8080
or192.168.0.1:443
). If the argument is-
(dash), clear (unset) the proxy. - Replace branding images
-
image_brand_replacement [= on | off]
This feature is provided for partners who wish to replace the VMware logo and other assets with their own.
Display or set the status of brand images replacement policy. With no argument, display the current status. If an argument is provided, set the policy to the specified value. Possible values are on or off. When enabled, the Manager will display the replacement visual assets in its hosted User Portal. These files must be located in the
/home/lastline/brand_replacement_files/
directory. - Inject interface
-
inject_interface [= interface | -]
Display or set the interface used for injecting blocking packets according to the configured modes, for example, TCP RST packet, DNS NXDOMAIN response, HTTP 302 redirect, etc. With no argument, display the current interface name. If an argument is provided, set the interface name to the specified value. You can specify any valid interface name, for example
eth1
. If the argument is-
(dash), clear the interface name (set to an empty value). - Inline interfaces
-
inline_interfaces [= interface-interface, interface-interface, ... | -]
Display or set the list of interface pairs used for inline mode. With no argument, display the current interface pairs. If an argument is provided, set the interfaces to the specified value. Specify a comma-separated list of interface pairs, for example
eth1-eth2, eth3-eth4
. If the argument is-
(dash), clear the interface pairs (set to an empty value). - License API token
-
license_api_token
Display the On-Premises license API token.
- License key
-
license_key
Display the On-Premises license key.
- Update server override
-
llama_images_server_override [= IPaddr | hostname | -]
Display or set the host name or IP address for the server from which to download LLAMA images. With no argument, display the current host. If an argument is provided, set the server to the specified value. If the argument is
-
(dash), clear (unset) the server.This option is provided for installations that must substitute another server for the default
update.lastline.com
. - Manager domain name
-
manager [= domain name | -]
Display or set the domain name of the Manager. With no argument, display the current value for
manager
. If an argument is provided, setmanager
to the specified value. If the argument is-
(dash), clear (unset) the server.In most instances, you should leave this field to its default value of
lastline.com
or for an On-Premises installation, the fqdn of the local Manager. If you must change this entry, enter the domain name of the Manager you want to connect to. If you uselastline.example.com
, for example,update.lastline.example.com
andlog.lastline.example.com
should be additional aliases for the same IP address in your default DNS server. - Monitoring user
-
monitoring_user_password [= password | -]
Enable or disable the monitoring user. With no argument, display the current state. If an argument is provided, set the monitoring user password to the specified value. If the argument is
-
(dash), disable password-based authentication. - Network parameters
-
network [= variable value]
Display or set the network parameters of the appliance. There are two network methods: DHCP or static. With no argument, display the current network settings. For example:
DHCP settings
network interface = eth0 network method = dhcp
Static settings
network dns_nameservers = 8.8.8.8 8.8.4.4 network gateway = 10.0.2.2 network netmask = 255.255.255.0 network address = 10.0.2.15 network interface = eth0 network method = static
The
network
option has a number of variables:-
network interface
— Set the interface used for network access.network interface interface
-
network method
— Set the network method. Fordhcp
, the appliance gets its address and other network information from a DHCP server. Forstatic
, you define all the network parameters.network method dhcp | static
-
network address
— For a static configuration, set the IPv4 address of the interface.network address IPaddr
-
network netmask
— For a static configuration, set the dotted-quad netmask of the interface.network netmask netmask
-
network gateway
— For a static configuration, set the IP address of the default gateway for network access. If the argument is-
(dash), set the gateway address toNone
.network gateway [IPaddr | -
-
network dns_nameservers
— For a static configuration, enter a list of space separated IP addresses for the DNS servers. If the argument is-
(dash), set the DNS servers toNone
.network dns_nameservers [IPaddr IPaddr ... | -
-
- Monitoring user
-
new_monitoring_user_password [= password | -]
Enable or disable access to the appliance for the monitoring user. With no argument, display the current monitoring user password (displayed as
***
). If an argument is provided, set the monitoring user password to the specified value. If the argument is-
(dash), clear the monitoring user password (set to empty value). - NTP servers
-
ntp_servers [= IPaddr,IPaddr,... | -
Display or set the NTP servers list. With no argument, display the current value for the NTP servers list. If an argument is provided, set the NTP servers list to the specified value. The NTP server addresses must be comma separated. If the argument is
-
(dash), clear (unset) the NTP servers list. - Offline mode
-
offline_mode
Display offline mode. This allows the appliance to work without an Internet connection.
- Save
-
save [skip_apply] [skip_network_restart]
Save your changes, apply the new configuration, and exit.
If
skip-restart-network
is specified, the network will not be restarted and therefore any changed network settings will be saved but not applied.If
skip_apply
is specified, the new configuration will be saved but not applied. You can later run thelastline_apply_config
command to make the new configuration effective. - Sensor subkey
-
sensor_subkey
Display the Sensor subkey. To change this value, the Sensor must be deregistered, and then re-registered using the
lastline_register
command. - Show configuration
-
show
Display the current configuration. For example, the configuration of a Sensor:
-> show anonymization_password = *** appliance_state = active appliance_uuid = 046cf54cb3d46eab0c3263724cd56b6a disable_support_channel = https_proxy = inject_interface = eth2 inline_interfaces = license_key = 0Z6LLNOU4ZP12BWBTOJ0 manager = manager.lastline.example.com monitoring_user_password: enabled network interface = eth0 network method = dhcp new_monitoring_user_password = *** ntp_server = update.lastline.com ntp_servers = update.lastline.com sensor_subkey = sensor01 sniffing_interfaces = eth2
- Sniffing interface
-
sniffing_interface [= interface, interface, ... | -]
Display or set the list of interfaces the Sensor should monitor. With no argument, display the current interfaces. If an argument is provided, set the interfaces to the specified value. Specify a comma-separated list of interface names, for example
eth1, eth2
. If the argument is-
(dash), clear the sniffing interfaces (set to an empty value). - Replace branding images
-
text_brand_replacement [= JSON]
This feature is provided for partners who wish to replace the VMware logo and other assets with their own.
Display or set the brand text replacement using JSON. With no argument, display the current JSON. If an argument is provided, set the brand text to the specified value.
Your JSON content should technically be a single line. For example:
text_brand_replacement = {"company_short_name_ascii":"llPartner","company_short_name_utf8":"エロパタナ"}
Exit options
To quit from the lastline_setup
command
without saving your changes, type exit
.
If you made changes that you want applied, you must use the save
option to update the appliance database and configuration.
It then quits the lastline_setup
command.
Terminology
- event
-
An event represents a security-relevant activity that has occurred in the monitored network. An event may involve multiple data flows (for example, TCP connections), but it represents a single type of activity occurring over a short period of time (at most one hour). Multiple events are automatically correlated into incidents.
- incident
-
An incident represents a security-relevant activity that has occurred in the monitored network. An incident may consist of a single event, or a number of events that have been automatically correlated, and that have been determined to be closely related.
- infection
-
An infection is an incident that has been determined to be critical. Infections should be dealt with without delay.
- intrusion
-
An intrusion is a correlated set of incidents that affect one or more devices over a period of time.
- nuisance
-
A nuisance is an incident of low risk. This typically corresponds to potentially unwanted/risky activity that does not necessarily indicate a compromise or infection on the monitored network. Nuisances are tracked since they contribute to provide a more comprehensive network situational awareness.
- watchlist
-
A watchlist is an incident that has been determined to be of medium risk. Such incidents, while indicating a potential risk, do not need immediate attention; they are kept under close watch in case new evidence appears that modifies their status.
For example, an incident involving an inoperative command and control infrastructure will be classified as watchlisted.