# Welcome

This is the home page for docs.vectra.ai.

## Introduction

Welcome to the new home of documentation for Vectra AI.

Our documentation lives on this site, providing easy access to detailed guides and resources to help you navigate Vectra AI products seamlessly. Meanwhile, our Knowledge Base articles, support cases, and product downloads are hosted on our dedicated support portal at [support.vectra.ai](https://support.vectra.ai). This division ensures that users can quickly find in-depth documentation here while accessing KBs and technical assistance through our support portal.

For Vectra Fusion customers, the current documentation can be found at [docs.netography.com](https://docs.netography.com). As part of our integration roadmap, we will be working towards merging these resources with our comprehensive documentation here. This transition aims to provide a unified and streamlined experience, ensuring all users have access to consistent and consolidated information in one location. Keep an eye out for updates as we progress with this integration later this year.

## Docs vs KBs

**Docs (Documentation)** refers to comprehensive guides, user manuals, and detailed resources designed to help users understand and make the most of a product. They are typically structured, well-organized, and provides step-by-step instructions, ensuring that users can achieve specific tasks or solve complex issues independently.

**KBs (Knowledge Base articles)**, on the other hand, are focused on providing quick solutions to specific questions or common issues users may encounter. KBs are generally shorter than documentation, addressing particular problems, and often include advice for specific situations, troubleshooting steps, FAQs, etc.

In summary, while documentation offers in-depth educational content, KB articles provide immediate, targeted solutions, making it easier for users to find answers quickly during specific situations. Vectra support personnel may point you to docs or KBs depending on the issue you face.

## Future Plans

Vectra plans to enhance the [support portal](https://support.vectra.ai/) by introducing a unified search feature in a future update. This enhancement will allow users to easily locate answers by searching content on both this new documentation site and on the support portal. This unified search feature aims to streamline the search experience, ensuring users can efficiently find information from both comprehensive docs and targeted KB articles without navigating multiple resources. This documentation site will only search the content housed in it.

Vectra also plans to migrate live api documentation to this site in a future update. For now, continue to use [apidocs.vectra.ai](https://apidocs.vectra.ai/) for live documentation of v3 and higher versions of Vectra APIs. PDF documentation for Vectra's APIs, including v2.x APIs, can be found under [api-rux](/configuration/access/api-rux) and [api-qux](/configuration/access/api-qux) on this site.

Please check the [Release Notes](https://docs.vectra.ai/release-notes/) section for details on both Vectra Product updates and major updates to the documentation site.

## Have Feedback or Need a .pdf

Vectra is still working to update some of the content that previously was on the support site. As such you may find some formatting inconsistencies or other issues, and some articles will still provide a .pdf instead of being native articles. We will continue to enhance articles on the documentation site in future updates.

We are working to make as much content as possible available in a native format that doesn't require downloading a .pdf but some readers will still need a .pdf for reading offline.

**To provide article feedback:**

<div data-with-frame="true"><figure><img src="/files/wb5M6We2jL5wPNzkBjnI" alt="" width="257"><figcaption></figcaption></figure></div>

All articles have a **Was this helpful?** area in the table of contents for each article on the right hand side. After clicking on a level of emotion to associate with your feedback, you can enter text to accompany your feedback if desired. Be as verbose as necessary. Vectra will be reviewing this feedback and trying to address it.

If you feel that you need a more official response, feel free to open a ticket on the [support portal](https://support.vectra.ai/).

**To create .pdf from native articles for reading offline:**

All article pages have an AI Assistant button near the top right of the page.

<div data-with-frame="true"><figure><img src="/files/Ymi9kdgg37j2sKRnBr67" alt="" width="563"><figcaption></figcaption></figure></div>

Simply select **Export as PDF** to export the page and any sub-pages under it as a .pdf.


# Getting started

Quick links to core deployment guides, requirements, and architecture references.

{% content-ref url="/pages/8ef36yTH12WLNTiaG12Z" %}
[Analyst UX options (RUX vs QUX)](/deployment/getting-started/analyst-ux-options-rux-vs-qux)
{% endcontent-ref %}

{% content-ref url="/pages/LXf12XMOe2JNsNfyW47J" %}
[NDR / Network identity architecture](/deployment/getting-started/ndr-network-identity-architecture)
{% endcontent-ref %}

{% content-ref url="/pages/69eb9dde445e5f9e57e57466881b2657fb8b11e6" %}
[Respond UX deployment guide](/deployment/getting-started/respond-ux-deployment-guide)
{% endcontent-ref %}

{% content-ref url="/pages/PvlGfhasS30mwsBObUHK" %}
[Respond UX specific](/deployment/getting-started/respond-ux-deployment)
{% endcontent-ref %}

{% content-ref url="/pages/2rzCaPjb2RzvDdANBGVB" %}
[Quadrant UX deployment guide](/deployment/getting-started/quadrant-ux-deployment)
{% endcontent-ref %}

{% content-ref url="/pages/QqjhezgB1jfjSjQl0IVU" %}
[Firewall requirements](/deployment/getting-started/firewall-requirements)
{% endcontent-ref %}

{% content-ref url="/pages/pezQXiSb2um2Q3VTsCuA" %}
[Appliance specifications](/deployment/getting-started/appliance-specifications)
{% endcontent-ref %}

{% content-ref url="/pages/YMWiVGY1J5chc5NNhkKd" %}
[Default usernames and passwords](/deployment/getting-started/default-usernames-and-passwords)
{% endcontent-ref %}

{% content-ref url="/pages/AXkqnqPN9ACLyhWzSnOM" %}
[IPv6 management support for Vectra appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances)
{% endcontent-ref %}


# Analyst UX options (RUX vs QUX)

How to tell Respond UX from Quadrant UX and what differs across features and docs.

## Introduction

The Respond User Experience (Respond UX) and the Quadrant User Experience (Quadrant UX) are two different analyst user experiences that Vectra offers. When searching for documentation, it is important to differentiate between these two UX offerings as some documentation is specific to each UX type. One example is that SAML SSO claim requirements are different for use with the Respond UX and the same claim setup cannot be used for both the Respond UX and the Quadrant UX.

## Respond UX

* The Respond UX offers a unified view with AI-driven Prioritization and a single urgency score for all entities (hosts, accounts, etc) across all data sources (network, public cloud, SaaS, etc).
* Features such as Instant Investigation and Advanced Investigation are only available in the Respond UX.
* You are using the Respond UX if you access the Vectra AI platform using a URL that is constructed similar to this:
  * `https://[unique_customer_id].[region_code)].portal.vectra.ai/signIn`
  * In this case, the Respond UX Vectra UI is served from the Vectra AI platform.
    * For customers with network data sources (Sensors), a Brain appliance (linked to the Vectra AI platform) still manages paired Sensors and on-prem integrations such as AD, EDRs, Windows Event Log ingestion, Stream, etc

**Example Respond UX screenshot:**

<figure><img src="/files/U6cvOSpjxURDUCdHmisE" alt=""><figcaption></figcaption></figure>

## Quadrant UX

* The Quadrant UX is the classic experience that existing Detect for Network customers are familiar with.
* It offers separate threat and certainty scores with separate host and account prioritization.
* If your UI is served from a Brain appliance, then you are using the Quadrant UX.
  * The Brain appliance could be deployed in your IaaS public cloud account (such as AWS or Azure), or it could be a physical or a virtual appliance deployed in your network.
  * The URL to access the brain will vary based on your deployment and whether you access it by hostname or IP.
  * For customers with non-network data sources (Azure AD, M365, AWS – control plane data sources), the Vectra AI platform delivers detection data to your Brain for use with the Quadrant UX.

**Example Quadrant UX screenshot:**

<figure><img src="/files/wypm5dTnNB0u91aco3U7" alt=""><figcaption></figcaption></figure>

## Terminology

Some existing customers may have both UX's deployed as part of their overall implementation. Vectra's original product, Detect for Network, historically used what is now known as the Quadrant UX. When Vectra began offering SaaS based deployment of Detect for M365, Detect for Azure AD, and Detect for AWS, a version of the Quadrant UX that was served from the Vectra AI Platform was the default UX. After the launch of AI-driven Prioritization, the UX served from the Vectra AI Platform is now known as the Respond UX. The below definitions can help with naming changes and what older names you may have heard really refer to now.

<table><thead><tr><th width="213.2265625">Term</th><th width="115.3359375">Status</th><th width="220.34375">Description</th><th width="200.72265625">Former Terms</th></tr></thead><tbody><tr><td>Vectra AI Platform</td><td>Current</td><td>Vectra’s cloud platform, delivered as SaaS</td><td>Current</td></tr><tr><td>Respond UX</td><td>Current</td><td>Vectra’s analyst user experience that is served from the Vectra AI Platform</td><td>Current</td></tr><tr><td>Respond UX for Network</td><td>Current</td><td>This refers to using the Respond UX with network data sources (Sensors).</td><td>Current</td></tr><tr><td>Quadrant UX</td><td>Current</td><td>Vectra’s classic user experience that is served from a Brain appliance</td><td>On-prem UI, appliance UI, classic UI</td></tr><tr><td>Vectra SaaS / SaaS UI</td><td>Deprecated</td><td>Legacy terminology for the Vectra AI Platform or SaaS delivered analyst user experience</td><td>N/A</td></tr><tr><td>Vectra Cloud / Cloud UI</td><td>Deprecated</td><td>Legacy terminology for the Vectra AI Platform or SaaS delivered analyst user experience</td><td>N/A</td></tr><tr><td>Vectra CDR for M365</td><td>Current</td><td>Vectra's product that examines logs from M365</td><td>Detect for M365, Detect for Office 365</td></tr><tr><td>Vectra IDR for Azure AD</td><td>Current</td><td>Vectra's product that examines logs from Azure AD</td><td>Detect for Azure AD, Detect for Office 365</td></tr><tr><td>Vectra CDR for AWS</td><td>Current</td><td>Vectra product that examines logs from AWS</td><td>Detect for AWS</td></tr><tr><td>Vectra NDR</td><td>Current</td><td>Vectra's product that examines network traffic</td><td>Detect for Network</td></tr></tbody></table>


# NDR / Network identity architecture

High-level architecture overview for Vectra NDR and network identity.

**Attachments**

{% file src="/files/0gycfLrhvL6Y7bwHNhRP" %}


# Respond UX deployment guide

End-to-end guide for deploying Vectra Respond UX, including requirements, firewall rules, deployment steps, data source setup, initial configuration, and post-deploy next steps.


# Introduction and overview

Overview of RUX deployments, appliance modes, and requirements for adding network Sensors to the Vectra AI Platform.

## Introduction

This guide is intended to help customers or partners get started with a deployment of Vectra’s Respond User Experience (Respond UX). The User Interface (UI) for the Respond UX is served from Vectra’s cloud as part of the overall Vectra AI Platform.

{% hint style="info" %}
For users working with Vectra’s Quadrant UX (QUX), the UI is served locally from Vectra Brain appliance wherever it was installed in your environment. Please refer to the [Vectra Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment) if you are planning a QUX deployment. If you are unsure of your deployment type, please see [analyst UX options](/deployment/getting-started/analyst-ux-options-rux-vs-qux).
{% endhint %}

If you are migrating to the Respond UX from the Quadrant UX, please also see the migration guide that is attached to the [Why upgrade to RUX and how to migrate to it](/deployment/getting-started/respond-ux-deployment/why-migrate-to-rux-from-qux-migration-to-rux-from-qux) article. In addition to general migration guidance, additional firewall rules will be required to allow upload of configuration data needed during migration. Those rules are detailed in that guide.

This guide will include an overview of the platform including components and Vectra terminology. It will cover requirements, deployment, basic initial configuration, and recommended next steps.

This guide is meant to be used in conjunction with related guides in the deployment area of the overall documentation site. Here you will find guides that are relevant for deploying NDR physical, virtual, and cloud Sensors, other Vectra SaaS products such as CDR for AWS and Azure and Azure AD, IDR for M365, Match, and Stream.

## Vectra AI Platform Overview

A Respond UX deployment typically includes several components of the overall Vectra AI Platform:

* User interface (delivered as SaaS from Vectra’s cloud).
* Data sources such as Network (campus, data center, and IaaS clouds), Public cloud, SaaS, and Identity.

For deployments with network sensors, please see the [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture) for more details.

![](/files/d273429b4d8f3b1fec63d2fb3d997a1c7c5f6df6)

The above conceptual diagram shows the components of the Vectra AI Platform.

* Admins and analysts can access the Respond UX from anywhere.
* For customers choosing to deploy without network data sources, there is no requirement to deploy a Brain appliance (physical or virtual) in your premises.
  * All functionality can be delivered as SaaS using connections setup to collect log data from your various non-network data sources.
* When capturing network metadata as part of your Respond UX deployment, a Brain appliance (physical or virtual) will be installed in your premises (campus, datacenter, or IaaS cloud) and linked to Vectra.
  * The Brain’s graphical user interface (GUI) is served from Vectra’s cloud.
    * The Respond UX communicates with your Brain over a websocket connection.
  * Physical or Virtual Sensors will be deployed and paired with your Brain to capture network metadata across hybrid environments.
    * Vectra supports IaaS public clouds, datacenters, remote workers, and campuses.
  * AI detection algorithms process data locally in your Brain and post Detections and associated metadata to Vectra’s cloud for further processing and investigation with the Respond UX.
  * The Brain will also act as a conduit for services needing to be accessed on your local premises.
    * AD, vCenter, Stream metadata output to your data lake, etc.

### Appliance Modes

{% hint style="info" %}
This section only applies when you are using network data sources (network Sensors) with your RUX deployment. Appliances are not used when the data sources are all cloud based (such as CDR for M365, IDR for Azure AD, CDR for Azure, CDR for AWS, etc).
{% endhint %}

The 3 modes are Brain, Sensor, and Mixed. S-series appliances and virtual Sensors function only as Sensors. B-series appliances and virtual Brains function only as Brains. X-series appliances can be configured as Brains or Sensors. The X29 appliance can also function in mixed mode.

**Brain Mode**

* The Brain serves as the communications broker between Vectra’s cloud and any local integration points.
* The Brain pairs with Sensors (network data sources) and processes / deduplicates and optionally forwards the metadata received from Sensors (when licensed for Stream).

**Sensor Mode**

* Must be paired to a Brain.
* Captures / deduplicates raw network traffic.
* Forwards metadata to the Brain.
* Houses rolling capture buffer to enable PCAP retrieval when requested from the Brain.

**Mixed Mode**

* Performs both Brain and Sensor functions.

## Requirements for Network Data Sources

The following are general requirements for a deployment of the Vectra Respond UX that utilizes network data sources:

* A Brain appliance and at least one Sensor to provide network metadata to the Brain for analysis.
  * A mixed mode Brain can serve as both the Brain and Sensor for smaller environments.
* A login to the Vectra’s cloud to access the Respond UX.
  * The Brain appliance will be connected to the Vectra cloud during the overall deployment process and the UI (Respond UX) will also be served from Vectra's cloud. There will be no local UI served from the Brain.
  * Your initial login will need to be secured by MFA (Multi-Factor Authentication). Please see [Initial login - protecting your MFA secret key (RUX)](/deployment/getting-started/respond-ux-deployment/initial-login-protecting-your-mfa-secret-key-rux) for details on how to back up your secret key while performing your initial login.


# Firewall requirements

Firewall requirements for your Respond UX (RUX) deployment.

## Firewall Requirements Sections

[Important Notes](#important-notes)\
This section covers Respond UX vs Quadrant UX applicability. It also covers SSL inspection, internet/air-gap requirements, and remote support IP range conflicts.

[Vectra Cloud Connectivity](#vectra-cloud-connectivity)\
This section covers connectivity to Vectra services hosted in Vectra’s cloud. It is mainly for Respond UX deployments. The [Auth Gateways](#auth-gateways) section also applies to Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.

[Appliance Connectivity](#appliance-connectivity)\
This section covers connectivity required for Vectra appliances (physical or virtual). It applies to both RUX for Network and Quadrant UX deployments. This section also contains additional details regarding connectivity from Vectra appliances to the Vectra cloud.

## Important Notes

### Respond UX vs Quadrant UX Applicability

The Respond User Experience (Respond UX or RUX) and the Quadrant User Experience (Quadrant UX or QUX) are two different analyst user experiences that Vectra offers. It is important to differentiate between the different UX's when looking at requirements for FW rules. Some FW rules will only apply to deployments using the Respond UX and some will apply only to deployments using the Quadrant UX. For additional information please see: Vectra Analyst User Experiences (Respond vs Quadrant).

While the Respond UX is delivered from Vectra's cloud as part of the overall Vectra AI Platform, it can be used without traditional Brain and Sensor appliances when only non-network data sources are used. RUX for Network deployments (using network Sensors with the Respond UX) still require a Brain appliance to be installed in the customer environment (which can be in IaaS clouds or physical data centers, etc). Sensors will be deployed and paired with that Brain to capture network traffic for analysis.

Requirements listed below that apply only to RUX for Network deployments or only to QUX deployments will be labeled as such.

### Firewall/Proxy SSL Inspection

Please note that Vectra appliances validate SSL certificates for all HTTPS connections. For this reason, SSL/TLS inspection on firewall and proxy appliances must be disabled for these connections to work.

We have also identified that some firewall software transparently enables SSL inspection if certain filters (DNS hostname filtering) are enabled. This is not necessarily obvious to the administrator and should be investigated if connectivity issues are being observed.

### Internet Access From Vectra Brain

A Vectra Brain requires connectivity to the automatic update service for normal operation. This connectivity is used for automatic (including security) updates and to synchronize keys for cryptographic authentication of sensors.

The Brain requires Internet DNS resolution to obtain the IP addresses for these requests. The customer may choose public/Internet DNS servers or internal DNS servers; however, Internet DNS entries must be resolvable by the Brain. Please note that DNS is often considered to be a UDP-only protocol, however, TCP may be used depending on the type of DNS transaction. Both UDP and TCP use port 53 and should be permitted to all configured DNS servers.

Vectra can function in air-gapped environments when a Quadrant UX based deployment is done, but there will be some impacts such as:

* Vectra Threat Intelligence detections will be disabled.
* Suspect Domain Activity detection will be disabled.
* Context enrichments from external sources such as whois, etc that are displayed in certain models will not function.

Please see the [Vectra Quadrant UX Deployment Guide](https://support.vectra.ai/s/article/KB-VS-1077) for additional details about air gap environments including guidance for offline updates. Respond UX for Network is not possible in air-gapped environments since the Respond UX is delivered from Vectra's cloud and communicates with a locally installed Brain.

### Internet Access to Vectra Appliances

As with all security infrastructure Vectra appliances should be blocked from Internet access and access should only be granted from trusted workstations and/or authenticated sources.

### Management Network IP Address Range Conflicts with Remote Support

Customers should note that the following IP ranges will conflict with remote support capability:

* 192.168.72.0/21
* 192.168.80.0/21

If you will ever need Vectra to assist remotely (outside of screen sharing sessions), care should be taken to number the management network interface (MGT) used on any appliance (physical, virtual, or cloud - Brains or Network Data Sources/Sensors) outside of the above ranges. If your management network interface (MGT) is numbered in either of these ranges, remote support access will not function. Remote support connectivity with Vectra all goes through the Brain (even to access other appliances in your deployment) so firewall rules for remote support functionality only need to allow connectivity from the Brain to Vectra's cloud (Sensors must still allow connectivity to the Brain per the below charts).

## Vectra Cloud Connectivity

* For this document, the portions of the Vectra AI Platform that reside in Vectra’s cloud are referred to as the Vectra cloud.
  * This does not refer to any specific service offering.
* Please check each category below to see if it is applicable to your deployment and if rules are required in your environment to enable the required connectivity.
  * For rule categories that have multiple region options, it is only necessary to put rules in place to allow connectivity to the region that your Vectra tenant is deployed in. This region should be visible in the URL used to access the Respond UX.
    * i.e. `[tenant_id].ew1.prod.vectra-svc.ai` is used for EU deployments (ew1).
* RUX for Network refers to a RUX deployment that has enabled network data sources (sensors).
  * This means you have a Brain somewhere in your premises (data center or public cloud) that is connected to the Vectra cloud for use with the Respond UX and paired with network Sensors (virtual or physical) to capture network traffic and distill a metadata stream for processing by the Brain appliance.
  * Please refer to the [Vectra Respond UX Deployment Guide](https://support.vectra.ai/s/article/KB-VS-1696) for more details.
* Please refer to the table below to see applicability of the various categories.
* The **For Brain or User’s Browser** column should be interpreted as follows:
  * **Brain** – Rules required for the Brain to the Vectra Cloud.
  * **User’s Browser** – Rules required for the user’s web browser to the Vectra cloud.

<table data-header-hidden data-full-width="true"><thead><tr><th width="318.47265625"></th><th width="281.6796875"></th><th width="259.9375"></th></tr></thead><tbody><tr><td><strong>Rule Category</strong></td><td><strong>Required For</strong></td><td><strong>For Brain or User’s Browser</strong></td></tr><tr><td><a href="#rux-for-network-gui-synchronization">RUX for Network GUI Synchronization</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#auth-gateways">Auth Gateways</a></td><td><p>RUX for Network Deployments</p><p>Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.</p></td><td>Brain</td></tr><tr><td><a href="#rux-metadata-forwarding">RUX Metadata Forwarding</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#rux-research-metadata-forwarding">RUX Research Metadata Forwarding</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#section-2">RUX Analyst/Admin Access</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#_Respond_UX_(RUX)_1">RUX Static Asset CDN</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#_Respond_UX_Customer">RUX Customer File Upload</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#vectra-cloud-egress-ips">Vectra Cloud Egress IPs</a></td><td>Vectra Cloud connecting to configured SaaS data source connectors</td><td>N/A</td></tr></tbody></table>

### RUX for Network GUI Synchronization

* Required for:
  * All RUX for Network deployments.
* This is used to synchronize configurations between the Brain appliance and your Vectra tenant.
* This communications channel is initiated from the Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **Websocket and HTTPS over TCP/443**

<table data-header-hidden data-full-width="false"><thead><tr><th width="365.3203125" align="center"></th><th width="100" align="center"></th><th width="100" align="center"></th><th width="144.20703125" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">main-cbi-tunnel-uw2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-ew1.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-ec2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-cc1.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-as2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### Auth Gateways

* Required for:
  * All Respond UX for Network Deployments.
  * Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.
    * Your Brain must be able to securely access the Vectra cloud over TCP/443 HTTPS connections to enable detection events from these products to be reported to your UI.
* In Respond UX for Network deployments, the Brain forwards network detections, entities, host sessions, and any selective PCAPs (Vectra Packet Capture) to your Vectra tenant via this connection.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.

<table data-header-hidden data-full-width="true"><thead><tr><th width="383.625" align="center"></th><th width="149.61328125" align="center"></th><th width="148.4609375" align="center"></th><th width="121.22265625" align="center"></th><th width="137.1484375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">authgateway.uw2.public.app.prod.vectra-svc.ai</td><td align="center">54.245.33.175<br>52.42.70.176<br>100.21.109.72<br>52.26.91.157</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.ew1.public.app.prod.vectra-svc.ai</td><td align="center">54.171.40.108<br>54.246.213.148<br>54.75.47.147</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.ec2.public.app.prod.vectra-svc.ai</td><td align="center"><p>16.62.18.237</p><p>16.62.142.98</p><p>51.96.54.201</p></td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.cc1.public.app.prod.vectra-svc.ai</td><td align="center">3.96.112.208<br>52.60.211.221<br>15.222.69.161</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.as2.public.app.prod.vectra-svc.ai</td><td align="center">13.54.11.66<br>13.55.79.24<br>13.55.106.102</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Metadata Forwarding

* Required for:
  * All Respond UX for Network Deployments.
* Network metadata is forwarded to AWS S3 buckets and processed to make it available for features such as Instant Investigation and Advanced Investigation in the Respond UX.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="514.98046875" align="center"></th><th width="100" align="center"></th><th width="119.75390625" align="center"></th><th width="146.4296875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-uswt2-371371611652.s3-accesspoint.us-west-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-euwt1-371371611652.s3-accesspoint.eu-west-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-eucl2-371371611652.s3-accesspoint.eu-central-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-cacl1-371371611652.s3-accesspoint.ca-central-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-apse2-371371611652.s3-accesspoint.ap-southeast-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Research Metadata Forwarding

* Optional but highly recommended for:
  * All Respond UX for Network Deployments
* Research metadata from precursor algorithms are used to improve model quality and reduce detection noise.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="490.4140625" align="center"></th><th width="100" align="center"></th><th width="120.79296875" align="center"></th><th width="135.91796875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">cbo-upload-network-precursors-uswt2-371371611652.s3-accesspoint.us-west-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-euwt1-371371611652.s3-accesspoint.eu-west-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-eucl2-371371611652.s3-accesspoint.eu-central-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-cacl1-371371611652.s3-accesspoint.ca-central-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-apse2-371371611652.s3-accesspoint.ap-southeast-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Analyst/Admin Access

* Required for:
  * All Respond UX deployments.
* Any analyst or admin that wishes to access the Respond UX will need to ensure that their browser can reach their Vectra tenant to login and access the UI.
* This communications channel is initiated from the user’s host.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="340.640625" align="center"></th><th align="center"></th><th align="center"></th><th width="139.19921875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">[tenant_id].uw2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].ew1.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].ec2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].cc1.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].as2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">User’s Browser</td></tr></tbody></table>

### RUX Static Asset CDN

* Required for:
  * All Respond UX deployments.
* The Respond UX has certain static assets (HTML, CSS, JS) that are required to serve the web application hosted by a CDN (Content Delivery Network).
* This communications channel is initiated from the user’s host.

<table data-header-hidden data-full-width="true"><thead><tr><th width="313.40234375" align="center"></th><th width="153.4609375" align="center"></th><th width="100" align="center"></th><th width="100" align="center"></th><th width="142.07421875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center"><p>dd6462tdmvp79.cloudfront.net</p><p>dpew7prsvwbf0.cloudfront.net</p></td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">All</td><td align="center">User’s Browser</td></tr></tbody></table>

### RUX Customer File Upload

* Required for:
  * All Respond UX deployments.
* This communications channel is used for:
  * Vectra Match deployments and will allow upload of rulesets.
  * PCAP download from the Vectra Cloud for Selective PCAP (Vectra Packet Capture)
  * Additional capabilities are planned for future releases.
    * It is recommended to put rules in place even if you don’t use Match or Selective PCAP.
* This communications channel is initiated from the user’s host.

<table data-full-width="true"><thead><tr><th width="395.8828125" align="center"></th><th width="151.8515625" align="center"></th><th width="93.1875" align="center"></th><th width="84.61328125" align="center"></th><th width="144.1015625" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">prd-main-customerfiles-580786928539-uswt2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">US</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-euwt1.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-eucl2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-cacl1.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-apse2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">User’s Browser</td></tr></tbody></table>

### Vectra Cloud Egress IPs

When the Vectra Cloud connects externally to retrieve logs from configured data sources, it does so from the IPs listed at <https://ips.devops.vectra-svc.ai/ips.json>. The specific IPs used will be limited to the IPs listed for the regions in use for your Vectra deployment. For example, if you are only deployed in eu-west-1, then only the IPs from the list associated with eu-west-1 will be used. See the following table for details.

<table><thead><tr><th width="315.4375">Region Code</th><th width="297.0234375">Region</th></tr></thead><tbody><tr><td>ap-southeast-2</td><td>Australia</td></tr><tr><td>ca-central-1</td><td>Canada</td></tr><tr><td>eu-central-2</td><td>Switzerland</td></tr><tr><td>eu-west-1</td><td>EU</td></tr><tr><td>us-west-2</td><td>US</td></tr></tbody></table>

In most situations, customers do NOT need to configure any specific firewall rules to allow Vectra to reach the endpoints required. If you see the IPs in the list accessing your data in your logs, this is not a cause for concern. It is due to the fact that your configured data source connector is connecting to the endpoint to retrieve the data necessary to provide the service.

In the case of CDR for Azure, if private access is required for the Azure storage accounts that Vectra reads your Azure logs from, please see [Configuring Private Access for Azure Storage Accounts](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#configuring-private-access-for-azure-storage-accounts) in the CDR for Azure deployment guide. Details are provided for how to configure the Storage accounts used to only accept connections from the IPs associated with the Vectra Cloud.

## Appliance Connectivity

The [Vectra Cloud connectivity](#vectra-cloud-connectivity) section above primarily deals with connectivity required to deliver the Respond UX and detections from Vectra SaaS offerings to both RUX and QUX deployments, the content in this section also applies to any deployment using Vectra appliances (Brains, Sensors, and Stream) for RUX or QUX deployments.

### Vectra Cloud Appliance Connectivity

All communications with the Vectra Cloud occur over a TLS encrypted channel. Appliance devices (physical, virtual, cloud) authenticate using keys. Unique public/private keys are generated when a device is provisioned by Vectra. The corresponding public key is copied to the Vectra Cloud. Every device connecting to the Vectra Cloud authenticates using its own private key.

The Vectra Cloud houses several services:

* update2.vectranetworks.com
  * Used for delivering updates to the Vectra software.
  * [Offline updates](/operations/readme-1/offline-updates-v89) are also supported.
* api.vectranetworks.com
  * Used for lightweight health monitoring of the Vectra platform and for delivering additional context certain Detections may need.
  * Queries to external information sources to provide context are proxied through this connection.
  * If required, customers can block the platform from reporting health monitoring by blocking outbound connections on their firewall to api.vectranetworks.com.
* rp.vectranetworks.com
  * Used only for Brains deployed in IaaS clouds. Used for authentication and verification (integrity check of the file system).
* metadata.vectra.ai
  * Metadata sharing improves threat detection by contributing anonymized metadata sourced from Brain deployed in your organization. This is optional in QUX deployments.
* rs.vectranetworks.com
  * This enables remote support from authorized Vectra employees.
* SaaS product offerings such as Recall

#### Proxy Support

Vectra Cloud connectivity to update2.vectranetworks.com and api.vectranetworks.com supports connecting through a customer proxy. If a proxy connection is required for your Brain appliance to reach these endpoints, edit the proxy settings in *Configuration → Data Sources → Network → Brain Setup → Proxy & Status*.

* Note that [Remote Support](/configuration/access/vectra-remote-support) does not support proxy configuration by default. If this is the only option, please contact Vectra support to configure remote support to manually to use a proxy.

#### Lightweight Health Monitoring

The lightweight health monitoring includes the following statistics, only aggregate statistics are collected, no details are collected.

* System Health Metrics
  * Installed packages, running processes, system interface information, system usage, database usage, system error stats
* Environment Metrics
  * Host counts, traffic counts, Brain configuration, remote support status, notification status, metadata status
* Detection Metrics
  * Detection counts, PCAP stats, Triage stats

#### Metadata Sharing

[Why is Metadata Sharing Important](/reference/why-is-metadata-sharing-important)

* Full details are available at this link. There are optional additional levels of sharing also described.

Metadata Sharing Improves Threat Detection

* By contributing anonymized metadata sourced from the X-series platform deployed in your organization, you are contributing directly to the efficacy and accuracy of the Vectra software and the security of your network.
* Access to Detection metadata improves Vectra’s threat detection algorithms, enabling the Vectra software you use to be more effective in a constantly evolving threat landscape.
* Data is collected daily and includes:
  * Anonymized information about Detections that are triggered in your network.
  * Anonymized information about algorithms in the research and development phase (and not yet visible in the UI) that are triggered in your network.
  * Anonymized attribution of Detections to Hosts.
  * Anonymized information related to host identification efficacy.
* Vectra Secures and Limits Access to Metadata
  * Any metadata you contribute is anonymized by removing personal and network-specific information before it is sent to metadata.vectranetworks.com via an encrypted connection.
  * Vectra treats this metadata as highly confidential and only allows authorized research personnel to access the metadata.
  * Any metadata collected is securely deleted after a six-month period.
* Contact Vectra support if non-anonymized Full Metadata Sharing is desired
  * Algorithm development using non-anonymized metadata helps to ensure that new models function as efficiently as possible in your environment.

### Required Connectivity For Appliances

<table data-header-hidden data-full-width="true"><thead><tr><th width="131.375" align="center"></th><th width="253.46875" align="center"></th><th width="177.15234375" align="center"></th><th width="288.40234375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td><td align="center"><strong>Description</strong></td></tr><tr><td align="center">Administrator workstations</td><td align="center"><p>Brain</p><p>Sensors</p></td><td align="center">TCP/22 (SSH)</td><td align="center">Command-line management of the Brain and Sensor appliances.</td></tr><tr><td align="center">Administrator workstations</td><td align="center">Brain</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Web management of brain appliances.</td></tr><tr><td align="center">Brain</td><td align="center"><p>update2<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.156.238)</p></td><td align="center">TCP/443<br>(HTTPS)</td><td align="center"><p>Automatic updates.</p><p>Pairing keys for physical sensors.</p><p>See note above regarding SSL keys.</p></td></tr><tr><td align="center">Brain</td><td align="center"><p>api<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.5.9)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Health monitoring, algorithm support, reverse lookups for external IPs, Vectra Threat Intelligence, additional detection content. See note above regarding SSL keys.</td></tr><tr><td align="center">Brain (Cloud)</td><td align="center"><p>rp<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.156.238)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Used only for Brains deployed in IaaS clouds. Used for authentication and verification (integrity check of the file system)</td></tr><tr><td align="center">Brain</td><td align="center">DNS servers (as configured)</td><td align="center">TCP/53, UDP/53</td><td align="center">Both TCP and UDP are required for normal operation. See note above regarding DNS resolution.</td></tr><tr><td align="center">Brain</td><td align="center"><p>NTP servers (as configured)</p><p>Default is ntp.ubuntu.com</p></td><td align="center">UDP/123</td><td align="center">Time synchronization.</td></tr><tr><td align="center">Brain</td><td align="center">SMTP servers (as configured)</td><td align="center">TCP (as configured)</td><td align="center">Email alerting.</td></tr><tr><td align="center">Brain</td><td align="center">SMTP (OAuth)</td><td align="center">TCP/443<br>TCP/587</td><td align="center">Please see SMTP (OAuth) for Microsoft chart below.</td></tr><tr><td align="center">Brain</td><td align="center">Sensors, Stream</td><td align="center">TCP/22 (SSH)</td><td align="center">Remote management and troubleshooting.</td></tr><tr><td align="center">Sensors, Stream</td><td align="center">Brain</td><td align="center">TCP/22 (SSH), TCP/443 (HTTPS)</td><td align="center">Pairing, metadata transfer, and ongoing communication.</td></tr><tr><td align="center">Stream</td><td align="center">Data lake (as configured)</td><td align="center">TCP (as configured)</td><td align="center">Metadata stream to a data lake</td></tr></tbody></table>

### Additional (Feature Dependent) Connectivity

<table data-header-hidden data-full-width="true"><thead><tr><th width="132.6796875" align="center"></th><th width="395.2890625" align="center"></th><th width="167.9609375" align="center"></th><th width="339.06640625" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td><td align="center"><strong>Description</strong></td></tr><tr><td align="center">Brain</td><td align="center">content.user-telemetry.vectra.ai<br>data.user-telemetry.vectra.ai</td><td align="center">TCP/443<br>(HTTPS)</td><td align="center">Required for In-App support functionality.<br>See <a href="https://support.vectra.ai/s/article/KB-VS-1606">In-App Support KB</a> for more details.</td></tr><tr><td align="center">Administrator workstations</td><td align="center">Recall Kibana server</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Recall IP addresses are provided during implementation and may be requested at any time from Vectra Support.</td></tr><tr><td align="center">Brain</td><td align="center"><p>rs.vectranetworks.com</p><p>(74.201.86.229)</p></td><td align="center">TCP/443 or UDP/9970</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1045">Remote Support</a> access for remote troubleshooting. See note above regarding SSL inspection and other note about potential IP range conflicts with the MGT interface.</td></tr><tr><td align="center">Brain</td><td align="center"><p>metadata.vectra.ai</p><p>(100.20.236.31, 44.229.57.246, 44.228.37.60, 44.228.101.87)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Anonymized metadata sharing to contribute to future algorithm development.</td></tr><tr><td align="center">Brain</td><td align="center">Recall collector</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Recall IP addresses are provided during implementation and may be requested at any time from Vectra Support.</td></tr><tr><td align="center">Brain</td><td align="center">Syslog (as configured)</td><td align="center">TCP or UDP (as configured)</td><td align="center">CEF or standard Syslog format.</td></tr><tr><td align="center">Brain</td><td align="center">Kafka (as configured)</td><td align="center">TCP (as configured)</td><td align="center">CEF or standard Syslog format.</td></tr><tr><td align="center">Brain</td><td align="center"><p>Carbon Black Response</p><p>(as configured)</p></td><td align="center">TCP/443 (as configured)</td><td align="center">Carbon Black integration (requires API key).</td></tr><tr><td align="center">Brain</td><td align="center">api.crowdstrike.com</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Crowdstrike integration (Client ID and Client Secret).</td></tr><tr><td align="center">Brain</td><td align="center">vCenter (as configured)</td><td align="center">TCP (as configured)</td><td align="center">vCenter integration enables vSensor physical host view, augmented host identification, and vCenter alerts.</td></tr><tr><td align="center">Brain</td><td align="center">LDAP (as configured)</td><td align="center">TCP/389 STARTTLS/389</td><td align="center">LDAP authentication.</td></tr><tr><td align="center">Brain</td><td align="center">Radius (as configured)</td><td align="center">UDP/1812</td><td align="center">Radius (PAP) authentication.</td></tr><tr><td align="center">Brain</td><td align="center">TACACS (as configured)</td><td align="center">TCP/49</td><td align="center">TACACS (PAP or CHAP) authentication.</td></tr><tr><td align="center">Brain</td><td align="center">Backup server (as configured)</td><td align="center">TCP/22 (SSH)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1121">Automated backup (SCP or SFTP)</a>.</td></tr><tr><td align="center">Brain</td><td align="center">Brain</td><td align="center">TCP/22 (SSH), TCP/443 (HTTPS)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1121">Automated backup (brain-to-brain)</a>. Connectivity is bidirectional.</td></tr><tr><td align="center">Sensors, Stream</td><td align="center">update2.vectranetworks.com (54.200.156.238)</td><td align="center">TCP/443 (HTTPS)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1024">Required for automatic pairing</a>. Optional for manual (offline) pairing.</td></tr><tr><td align="center">SIEM/CLM log management</td><td align="center">Brain</td><td align="center">TCP or UDP (as configured)</td><td align="center">Log forwarding of DHCP/AD security events to augment host identification.</td></tr><tr><td align="center">Brain</td><td align="center"><p>login.windows.net</p><p>api.securitycenter.windows.com</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Required for <a href="https://support.vectra.ai/s/article/KB-VS-1236">ATP lockdown</a></td></tr><tr><td align="center">Brain</td><td align="center">EMEA customers (only)<br><br>authgateway.ew1.public.app.prod.vectra-svc.ai<br>(54.171.40.108 , 54.246.213.148 , 54.75.47.147 )<br><br>AMS/APJ customers (only)<br><br>authgateway.uw2.public.app.prod.vectra-svc.ai<br>(54.245.33.175, 52.42.70.176, 100.21.109.72 , 52.26.91.157)</td><td align="center">TCP/443<br>(HTTPS)</td><td align="center">Required for Vectra MDR Service for QUX Deployments. These endpoints are also required for RUX deployments that have network data sources (Sensors). These are already discussed in the <a href="#auth-gateways">Auth Gateways</a> section of this doc for RUX. Essentially, if your deployment has a Brain, it MUST be able to reach Vectra over these endpoints for Vectra MDR service.</td></tr><tr><td align="center">Sensor</td><td align="center">S3 and SQS AWS Regional Endpoints. Only required for ZIA enabled Sensor.</td><td align="center">TCP/443</td><td align="center">Required for ZIA SASE/SSE integration. See <a href="https://support.vectra.ai/s/article/KB-VS-1006">KB</a> for details.</td></tr></tbody></table>

### SMTP (OAuth) For Microsoft

**Quadrant UX Only**: *Configuration → RESPONSE → Notifications → SMTP*

Respond UX deployments do not require this as email notifications are sent from Vectra's cloud.

<table data-header-hidden data-full-width="true"><thead><tr><th width="282.41015625" align="center"></th><th width="223.69140625" align="center"></th><th width="145.71484375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Cloud Type</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td></tr><tr><td align="center">Public (office365<strong>.</strong>com)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>com<br>smtp<strong>.</strong>office365<strong>.</strong>com</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">US Government (office365<strong>.</strong>us)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>us<br>smtp<strong>.</strong>office365<strong>.</strong>us</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">German (office365<strong>.</strong>de)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>de<br>smtp<strong>.</strong>office365<strong>.</strong>de</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">China (office365<strong>.</strong>cn)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>cn<br>smtp<strong>.</strong>office365<strong>.</strong>cn</td><td align="center">TCP/443<br>TCP/587</td></tr></tbody></table>


# Deployment

Overview of the RUX deployment process, how to do your initial login, deployment steps along with requirements and documentation links.

## Deployment Process Overview

* A decision is made to engage in a Vectra Respond UX trial or purchase.
* A welcome email will be sent after Vectra deploys a customer specific tenant where you can access the Respond UX.
  * The customer admin should validate access and configure additional user accounts and/or set up SAML SSO and role mapping for additional users as required. See [Respond UX initial login](#respond-ux-initial-login) for details.
  * Non network data sources can be configured at any time.
* For network data sources
  * A Vectra Brain appliance is deployed by the customer or with the assistance of Vectra or a partner.
    * The Brain must either be deployed in a state ready to be linked to the Vectra cloud or Vectra will assist with conversion of Brain appliances to the ready state.
    * See [Converting Your Brain to Ready It for Linking to the Respond UX](#_Updating_to_version).
  * After the Brain is ready to be linked, Vectra links the Brain with your Vectra tenant.
  * All network data sources and graphical functionality are managed though the Respond UX.
    * There should be no requirement to access the Quadrant UX GUI before your Brain is linked to your Vectra tenant. The Quadrant UX is served from a Brain appliance locally before it is linked with Vectra for a Respond UX for Network deployment (using network data sources with the Respond UX).

{% hint style="warning" %}
Do **NOT** pair network Sensors or forward traffic to the Brain before it has been linked to the Vectra cloud.

* If you go into the Quadrant UX on your Brain locally to pair network Sensors before it has been linked with Vectra’s cloud, it is possible for state information to become out of sync between the local Brain and Vectra’s cloud during the linking process.

* As part of the linking process, a factory reset is issued to ensure that there will be no state sync issues.
  * All data on the local Brain that hasn’t been backed up elsewhere, will be lost.
  * IP configuration and remote support VPN state will be kept during a factory reset.
  * Any proxy configuration will be cleared as part of this reset proces&#x73;**.**
    * If proxy settings were previously configured, they will need to be reconfigured.
      {% endhint %}

* Sensors are added and network traffic capture is initiated.
  * This should be done **AFTER** linking your Brain with Vectra.

* **Backup configuration (required for network data sources)**
  * Some parts of your deployment (metadata, detections, triage rules, etc) are backed up in Vectra’s cloud but the Brain appliance must still be backed up locally in your environment.
  * Please see [Backing up your Brain](#_Backing_up_your) in [Recommended next steps](/deployment/getting-started/respond-ux-deployment-guide/recommended-next-steps) after deployment is completed for additional guidance.

## Respond UX Initial Login

Once your Vectra tenant has been created, you will receive a welcome email from <no-reply@vectra.ai> with initial login details for the Respond UX. This will include a temporary password that expires in 7 days.

* Please login within 7 days and create a permanent password.
  * Passwords must be between 15 and 128 characters and contain at least: 1 number, both lowercase and uppercase letters, and 1 symbol (e.g. \~!@#$%^&\*,.?-\_+=).

{% hint style="info" %}
**Please Note:**

The initial `admin` password sent from Vectra is 18 characters long. Any new accounts created in the RUX UI will follow the password rules above. It is a best practice to configure SSO for most accounts where the IdP controls all password rules based on your policies and to use a strong password tied to MFA for "local" login to RUX for at least this `admin` account.
{% endhint %}

* If SAML SSO is desired for admin and analyst access, please see either of the following articles to configure SAML 2.0 based SSO.
  * [Setup SAML SSO with any IdP (Respond UX)](/configuration/access/saml-sso-rux/any-idp-saml-rux)
  * [Setup SAML SSO with Azure AD (Respond UX)](/configuration/access/saml-sso-rux/entra-id-azure-ad-saml-rux)
  * [Setup SAML SSO with Okta (Respond UX)](/configuration/access/saml-sso-rux/okta-saml-rux)
  * [Setup SAML SSO with Keycloak (Respond UX)](/configuration/access/saml-sso-rux/keycloak-saml-rux)
  * [Setup SAML SSO with ADFS (Respond UX)](/configuration/access/saml-sso-rux/adfs-saml-rux)

## Brain Deployment

### Requirements and Documentation Links

Per the [introduction and overview](/deployment/getting-started/respond-ux-deployment-guide/introduction-and-overview) earlier, when using network data sources, a Brain appliance must be deployed in your environment. The Brain appliance can be physical or virtual.

* For physical Brain appliances:
  * You will need CLI (Command Line Interface) access to the appliance.
  * The initial configuration at the CLI is covered in the Quick Start Guide for your appliance.
  * Please refer to that guide to configure an IP address, network mask, default gateway, and proxy (if required) on the Brain.
  * See [NDR physical appliances](/deployment/ndr-physical-appliances) for quick start guides for appliances:
    * Physical appliances must be B-Series or X-Series to be used as a Brain or in Mixed-Mode.
    * The quick start physical appliance guides are meant just for getting the appliance installed and available on your network.
* For virtual Brains deployed in IaaS clouds:
  * CLI access will be required if a proxy needs to be set for the Brain to communicate with Vectra.
  * Please see the appropriate deployment guide below for your supported IaaS cloud:
    * [AWS Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-brain)
    * [Azure Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/azure-brain)
    * [GCP Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/gcp-brain)
    * All [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances)
* For virtual Brains deployed in traditional hypervisor environments such as VMware or Nutanix:
  * This will require CLI access to set a static IP and DNS if you used DHCP for the initial boot process or plan to use a proxy for Brain to Vectra communications.
  * You can set an IP and DNS statically during OVA deployment.
  * Please see the [VMware Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/vmware-brain) or [Nutanix Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/nutanix-brain)
    * All [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances)

You may have already configured DNS following the quickstart for your physical appliance or the deployment guide for your virtual Brain. If you did not configure DNS as part of your initial Brain deployment, this guide will cover configuration of DNS later in the [*Data Sources → Network → Brain Setup*](/deployment/getting-started/respond-ux-deployment-guide/initial-configuration#data-sources-greater-than-network-greater-than-brain-setup) section. It is recommended to have your Brain registered in your DNS to make failover scenarios easier to deal with and to enable reverse DNS lookup.

### Proxy Support

If a proxy is required in your environment to communicate with Vectra from your Brain, this can be set at the CLI of your Brain. Login to your Brain’s CLI is done using the `vectra` user account. The default password is `changethispassword` for a newly deployed Brain. For Brains deployed in IaaS clouds (AWS, Azure), part of the deployment process includes creating an SSH key pair for login as the `vectra` user. The deployment guides for Brains in IaaS clouds include instructions for how to create and use those key pairs to log in to the Brain’s CLI.

* Proxy commands (v7.9+)
  * `show proxy`
  * `set proxy config [IP or Hostname] [port] [USERNAME] [PASSWORD]`
  * `set proxy enable [on|off]`
  * Any of these with `-h` option will show command help with syntax.

Examples:

```
vscli > set proxy config 1.1.1.1 80 testuser testpass
Saving proxy config...
Proxy config updated

vscli > show proxy
Enabled: True
Host: 1.1.1.1
Port: 80
Authentication:
Authentication enabled: True
User: testuser
Password: **********
Method: basic

vscli > set proxy enable on
Updating proxy config...
Proxy enabled
```

### Converting Your Brain to Ready It for Linking to the Respond UX

Vectra engineering will convert your Brain into a different state from the base state (where it serves the Quadrant UX locally) into a state where it can be linked to the Vectra cloud for use with the Respond UX. Some virtual Brains have an option to deploy in a Respond UX ready state where they will not serve a local Quadrant UX UI. For Brains that are not put into this Respond UX ready state, the conversion/linking is kicked off by Vectra engineering after your Brain checks in with Vectra. After Vectra links to your Brain, the Respond UX (served from Vectra’s cloud) communicates with your locally installed Brain.

Once your Brain is installed (following the instructions from your Brain Quick Start or Deployment Guide, see links in the [Requirements and Documentation Links](#requirements-and-documentation-links) above), please ensure it can communicate with Vectra

Guidance:

* Ensure that if a proxy is required for communication with Vectra, it is configured per [Proxy Support](#_Proxy_Support) earlier.
* Use the `debug connectivity` command at your Brain’s CLI to check connectivity to the following endpoints (from the [firewall requirements](/deployment/getting-started/respond-ux-deployment-guide/firewall-requirements) earlier):
  * `update2.vectranetworks.com`
  * `api.vectranetworks.com`
  * `rp.vectranetworks.com`
  * `rs.vectranetworks.com`
  * You may also wish to check for connectivity to other Vectra cloud endpoints associated with the region of your RUX deployment. See endpoints in [firewall requirements](/deployment/getting-started/respond-ux-deployment-guide/firewall-requirements).
* Use the `show version` command at your Brain’s CLI to see the current version and whether an upgrade is currently being applied.
  * New Brain versions may be in the process of downloading and preparing to be installed even while the result of the show version command shows `Upgrading: False`.
  * Please work with your Vectra team for additional detail. If your Brain is successful in communicating with Vectra, additional detail about the current state will be available to Vectra team members.

Examples:

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT

Test TCP connectivity to destination host or IP through proxy if configured

Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.

vscli > debug connectivity api.vectranetworks.com 443 --ssl
Connectivity: Success
Proxy: False
SSL: True

vscli > debug connectivity update2.vectranetworks.com 443 --ssl
Connectivity: Success
Proxy: False
SSL: True

vscli > debug connectivity authgateway.uw2.public.app.prod.vectra-svc.ai 443 --ssl
Connectivity: Success
Proxy: False
SSL: True

vscli > debug connectivity main-authgateway-uw2.app.prod.vectra-svc.ai 443 --ssl
Connectivity: Success
Proxy: False
SSL: True

vscli > debug connectivity rp.vectranetworks.com 443 --ssl
Connectivity: Success
Proxy: False
SSL: True

vscli > debug connectivity rs.vectranetworks.com 443
Connectivity: Success
Proxy: False
SSL: False

vscli > debug connectivity rs.vectranetworks.com 9970
Connectivity: Success
Proxy: False
SSL: False

vscli > show version
Upgrading: False
Version: 8.0.0-12-32
```


# Initial configuration

Guidance for configuring settings in the "Configuration" menu in the Vectra UI after the initial deployment is complete for Respond UX and your data sources are connected.

## Introduction

This section of the RUX deployment guide provides guidance for configuring settings in the **Configuration** menu in the Vectra UI after initial deployment. It is arranged by areas shown in your UI and has guidance and links for deeper guidance when required.

## Configuration → COVERAGE

Contains configuration options related to specific data sources, threat feeds, and Vectra Match.

***Data Sources***

Add coverage for new or existing network, cloud, and identity data sources to your Vectra deployment. For non-network data sources, each data source selected will present a welcome page with links to documentation.

***Threat Feeds***

Allows configuration of 3rd party threat intelligence feeds in STIX format. For details, please see linked documentation at: [Threat Intel Integration Setup](/configuration/coverage/threat-feeds/external-threat-intel-integration)

[Vectra Threat Intelligence](/configuration/coverage/threat-feeds/vectra-threat-intelligence) is a set of threat intelligence feeds that is managed and curated by Vectra. It is available as an included part of your Vectra NDR (Detect for Network) license. See the linked documentation for details.

***Vectra Match***

Vectra Match utilizes the open source [Suricata](https://suricata.io/) IDS engine. Vectra’s Sensors (network data sources) are extremely high performance and adept at producing the proprietary metadata required to supply the AI-based behavioral models utilized by Vectra NDR. Match enables these same Sensors to also run a Suricata engine that is fed by the same capture buffers that feed the existing data processing pipeline.

For details, please see the [Vectra Match Deployment Guide](/deployment/match/deployment)

### Data Sources → Network → Brain Setup

This area contains settings that are specific to your Vectra Brain appliance. The full path for items in this section is *Configuration → COVERAGE → Data Sources → Network → Brain Setup.*

***Brain***

This area of the GUI displays various Brain specific settings and information, and also has **Restart** and **Shut Down** links.

* DNS Name
  * FQDN (Fully Qualified Domain Name) that can be used to pair Sensors and/or Stream to this Brain.
  * To use this value for pairing, change the pairing setting under *Configuration → COVERAGE* → *Data Sources → Network → Sensors → Sensor Configuration → Sensor Pairing and Registration* to **DNS Name**.
    * Additional guidance for pairing via IP or DNS is covered [later](#data-sources-network-sensors) in this document.
  * In general, it is recommended to configure your DNS with a proper hostname for the Brain.
* Alias
  * The label for this Brain within various areas of the Vectra AI platform.
* For linking in alerts/notifications (except AWS SecurityHub):
  * Choose either **DNS Name** or **Management IP Address**.
  * This will determine the format of links in alerts/notifications.

***CLI Access Controls***

This settings area becomes visible and replaces the **CLI Password (Brain)** setting if you have the feature flag for the new [SSH Login to CLI](/deployment/appliance-operations/ssh-login-process-for-cli) feature enabled in your deployment. This feature is currently in private preview and is planned to become generally available in a future release.

This area controls the password for the `vectra` user and allows you to disable this user entirely if desired. You can also control the SSH token (OTP) timeout value that non `vectra` users are subject to when they log in to the CLI of Vectra appliances. As linked article, users must have the **SSH Login to CLI** permission mapped to their assigned role to be able to login to any appliance CLI.

***CLI Password (Brain)***

This setting is replaced by **CLI Access Controls** when the feature flag for SSH Login to CLI is enabled in your Brain. This feature is currently in private preview and is planned to become generally available in a future release.

This setting allows you to set the password for the `vectra` user used to access the CLI of the Brain via SSH.

* Please note that accessing the CLI of a Brain deployed in an IaaS cloud requires authentication of SSH using the private key corresponding to the public key that was provided during deployment.
* Physical appliances and virtual Brains can authenticate using password.

***DNS Entries***

These DNS settings apply to the Brain only. Sensor DNS is set individually at the CLI or via a configuration string when deploying vSensors using the command line from the Brain.

* If you have not already configured DNS for the Brain at the CLI, please do so in this section of the UI.
* It is also highly recommended to enable Reverse DNS Lookup to improve host identification and context.
  * This is done by checking the checkbox in this area.

***IP Address Classification***

For proper algorithm operation and recognition of traffic directionality within Stream or Investigate metadata it is mandatory to accurately identify internal vs external IP space. By default, all RFC-1918 IP space is considered **internal**.

Additionally, Vectra NDR AI detection models do not analyze connections that originate from external IP space. Return traffic for connections that originated internally to external entities is analyzed. Metadata is still produced for Stream and Investigate functionality, and Match still processes externally originated connections through the underlying Suricata engine.

Please see the below for details on how each of the IP address classification settings will affect the system.

* RFC-1918 (Address Allocation for Private Internets) IP space
  * This is just a reminder about the networks that are reserved for internal use in RFC1918
  * <https://tools.ietf.org/html/rfc1918>
    * 10.0.0.0 - 10.255.255.255 (10/8 prefix)
    * 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
    * 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
    * fd00::/8 (IPv6)
* **Internal IP Addresses (CIDR)**
  * IP addresses or CIDR blocks entered here will be considered internal to your network.
  * Everything else will be considered external.
* **Exclude a Subset of Internal IP Addresses (CIDR)**
  * Use this area if you have a subset of internal IP addresses listed above that you want to be considered as external to your network.
  * For example, if you were going to simulate Command and Control behavior from an internal lab, you should configure the lab IP space as external (by adding it to this section). This allows Detect models properly identify the behavior.
* **Drop IP Addresses (CIDR)**
  * IP addresses or CIDR blocks entered here will be ignored.
  * Any traffic to or from these addresses will not be analyzed by NDR AI models by your system.
  * Ignoring traffic by VLAN is supported at the CLI using the `set capture-vlan` command.
* **Drop and Exclude Subnet Scenario Examples**
  * 10.10.0.0/16 set as Exclude, 10.10.50.0/24 and 10.10.70.0/23 set as Internal, Exclude setting will take precedence and both smaller subnets will be considered as Exclude.
  * Similarly, if 10.10.0.0/16 was set as Drop and the others external, the result would be Drop for all.
* **CLI Options for Setting Internal, Exclude, Drop**
  * After [logging into the CLI of your Brain](/deployment/appliance-operations/console-access-on-appliances), include, exclude, and drop networks/vlans can be configured by the below CLI commands.
  * The commands also have help that can be shown with the `--help` argument.

```
set capture-network [ networks ] < ( internal | external | drop ) >
set capture-vlan < vlan > drop
show capture-networks
show capture-vlans
```

* **Internal VPN IP Addresses (CIDR)**
  * Enter any IP ranges allocated to your VPN servers for remote end-user connections.
  * This will improve identification and detection model coverage for hosts connecting in via VPN by altering some characteristics of underlying models.
  * For more details on [optimizing your system for use with VPN clients](/configuration/coverage/remote-users/optimizing-vectra-for-use-with-vpn-clients), please follow the link.
* **Static IP Addresses (CIDR)**
  * In many customer environments, Vectra’s automated Host Identification (Host ID) is all that is required for customers to have all the pertinent hosts in their environment named and tracked. Generic hosts (IP-x.x.x.x) will inevitably be observed when a host first comes into the environment, but not enough artifacts have been observed to create a stable named host object or attribute its traffic to a previously created host. This can commonly happen when a user plugs in a laptop for the day, but the host is not recognized immediately. Vectra manages this on its own and will attribute traffic for this generic host to the named real host object once it is recognized.
  * Many customers also have statically assigned hosts and may not have hostnames in customer DNS. Additionally, Vectra may not directly observe enough artifacts of other types to name the host. If a stable host object never gets created, learning for several models cannot be anchored to generic hosts. This means that some Detections cannot fire and features such as the Host Role cannot function on these generic hosts.
  * Enter IP addresses or CIDR blocks representing the statically assigned hosts in your environment in this area.
  * Hosts on these IPs or ranges will show as **STATIC-x.x.x.x** in the Vectra UI and will no longer be generic hosts.
  * These hosts will have full support for learning and all Detections and features.
  * Statically defined hosts will not change name based on observed artifacts - they will remain static until they are no longer configured as such.
  * You are free to rename statically assigned hosts as you wish.

***NTP Entries***

Vectra provides defaults but please set your preferred time synchronization sources (up to 5) here.

***PCAP Generation***

PCAPs provide great value to analysts in a number of scenarios. PCAPs are assembled from the Sensor’s rolling capture buffer upon request from the Brain during the publishing of Detection alerts. In some circumstances, customers may not want to have PCAPs generated at all, or from certain Sensors that may be deployed in areas with stricter privacy controls that don’t allow for PCAP.

* Edit in this area to turn off PCAP generation entirely.
* To turn off PCAP generation on an individual Sensor go to *Configuration → Data Sources → Network → Sensors → Network Sensors*, select the Sensor you wish to edit, click the edit pencil, and then deselect the **Capture PCAPs for this Sensor** checkbox and **Save** your setting.

***Proxy & Status***

Edit this area to add or change proxy settings if required for your environment to be able to connect to endpoints needed in the [firewall requirements](/deployment/getting-started/respond-ux-deployment-guide/firewall-requirements). Also shows the status of connections.

* Please note that if you see green checkmarks for both the Statistics Destination and the Updater Destination, even if a warning stating **No proxy configured** is displayed, you do not need to setup a proxy for your platform.
* Proxy settings can also be viewed and configured at the CLI using the `show proxy` and `set proxy` commands at the CLI of your Brain appliance.
* For details on how Vectra works with proxies in your environment from a traffic capture/analysis standpoint as it relates to detections, please see [proxy handling in Vectra](/configuration/setup/proxies).
  * You can manage the northside proxy list under *Configuration → SETUP → Proxies.*

***Version***

Information about the version of your Vectra cloud platform will be displayed in this area.

### Data Sources → Network → Sensors

The full path for items in this area is *Configuration → COVERAGE → Data Sources → Network → Sensors.* In this area you can pair and manage network sensors, configure a number of options related to Sensor pairing and registration, and change the password for paired devices (Sensors or Stream).

***Network Sensors***

Sensor management and pairing is accomplished in this area. For details on pairing, please see [pairing appliances](/deployment/appliance-operations/pairing-appliances). Below is some detail that is also covered in more detail in the linked guide for pairing appliances.

***Sensor Configuration → Sensor Pairing and Registration***

Editing this area will allow you to alter the default way a Sensor will attempt to pair with a Vectra Brain and allow you to enable or disable Virtual Sensor Automatic Pairing. Additionally, this area provides a link to generate a new Sensor Registration Token

* **Pair using the Detect Brain**
  * If you have a DNS name configured in Configuration → COVERAGE → *Data Sources → Network → Brain Setup → Brain*, then the **Pair using the Detect brain** area will provide a choice between the configured DNS name and the Management IP (MGT1).
  * If you do not have a DNS name configured, there will only be one option present using the configured IP.
    * It may take a few minutes after adding a DNS name in your Brain setup for the choice to appear in this area.
  * Pairing via the Brain DNS Name makes Brain replacement or IP Address change events easier to manage.
  * This setting only affects the default pairing mode for Sensors used in future pairing operations.
    * Any previously paired devices will remain paired regardless of how they were paired.
    * Regardless of setting, the `set brain` command available at the CLI of the Sensor will allow you to attempt pairing via hostname or IP.
  * Should you choose to change the pairing method for previously paired devices, you will need to unpair the previously paired devices and re-pair them.
* **Virtual Sensor Automatic Pairing**
  * This setting allows you to choose if you want to automatically pair (auto pairing) with Sensors that have a valid Sensor Registration Token (SRT) configured.
    * Even though the setting name implies that this will only impact virtual Sensors, any Sensor, including physical appliances can auto pair if a valid SRT is configured when pairing is attempted.
  * It is recommended to allow auto pairing during initial setup or during large Sensor rollouts.
  * When you are done deploying vSensors, you may turn this off to enhance security posture.
* **Sensor Registration Token**
  * This is used to validate devices attempting to register to this Brain and resets after 24 hours.
  * It is required in the Registration Token field in the Sensor deployment template for cloud Sensors.
  * While the Sensor Registration Token (SRT) is required for cloud Sensor deployment, it is optional for physical Sensors and virtual Sensors.
  * Use of the SRT will allow you to pair a Sensor with any Brain in your organization. This can be useful for disaster recovery scenarios where a device may have been paired to another Brain previously.
  * After a Sensor registers with this Brain, it will appear in the Sensor list in *Configuration → COVERAGE → Data Sources → Network → Sensors* where its pairing can be managed.
  * Stream devices will show paring status in *Configuration → Setup → Stream → Pairing Status.*

***Sensor Configuration → CLI Password (Sensors)***

In this area you can change the password for all paired Sensor or Stream appliances to easily keep passwords in sync.

* If you require separate passwords for each Sensor or Stream appliance, the password for the `vectra` user may be changed individually using the `set password` command at the CLI of your Sensor.
* Please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) for more details.

### Data Sources → Network → Remote Users

The full path for this is *Configuration → COVERAGE → Data Sources* → Network → Remote Users. In this area you can configure Vectra’s vendor specific SASE/SSE integrations and IP pools to be used for remapping of remote users IP addresses that might otherwise conflict with IP address ranges used in corporate networks observed directly by Vectra network sensors.

Please see the externally linked [SASE/SSE Deployment Guide Links](/configuration/coverage/remote-users/remote-users-sase-sse) article for details and links to deployment guides for supported SASE/SSE vendors. Zscaler ZIA packet capture and Netskope Cloud Tap can be configured to provide network traffic to Vectra Sensors for remote user traffic that does not typically traverse other network Sensors deployed in your environment.

### Data Sources → Network → Network Identities

The full path for this is *Configuration → COVERAGE → Data Sources* → Network → Network Identities. In this area you can configure Windows Event Log Ingestion (WELI). WELI is an option available for Vectra NDR (Detect for Network) that helps with coverage by ingesting specific Kerberos messages in Windows event logs. Account and Host detections can fire as a result of this integration without having to have observed the actual network traffic associated with the Host or Account. Please see linked documentation at: [Windows Event Log Ingestion (WELI)](/configuration/coverage/network-identities-weli/windows-event-log-ingestion-weli).

## Configuration → SETUP

This area contains configuration settings that typically need to be configured one time during initial deployment or when new integration points are added to your environment and you want to configure Vectra to work with them.

***Account Association***

When using CDR for M365 & IDR for Azure AD, this area will allow you to manually map network realms to cloud domains. We recommend using automatic mapping by linking your Active Directory instance to your Vectra Brain, as this will link more robustly and with a greater success rate than manual mapping.

***EDR Integrations***

Configuring EDR integrations is considered a best practice if you have a supported EDR. It will enable Host Lockdown and provide added context to analysts for hosts running the EDR along with links to the EDR .

Please see linked documentation for these EDR integrations for details:

* [Microsoft Defender ATP (Endpoint)](/configuration/setup/edr-integrations/microsoft-defender-for-endpoint)
* [Carbon Black Response](/configuration/setup/edr-integrations/carbon-black-response)
* [Carbon Black Cloud](/configuration/setup/edr-integrations/carbon-black-cloud)
* [FireEye Endpoint Security (HX)](/configuration/setup/edr-integrations/trellix-fireeye-endpoint-security-hx)
* [SentinelOne](/configuration/setup/edr-integrations/sentinelone)
* [Cybereason](/configuration/setup/edr-integrations/cybereason)
* [Crowdstrike](/configuration/setup/edr-integrations/crowdstrike)

***Licensing***

See license status and perform license activation operations when required in this area.

***Metadata***

This setting allows you to configure behavior for connection state logging. This impacts the detail level of the **conn\_state** field shown in Advanced Investigation / Stream metadata. You can also control the volume of DNS metadata generated by logging or not logging DNS metadata only when a reply is observed in response to a request.

***Proxies***

Editing the configuration in this area allows you to manage automatically identified northside proxies in your environment. Identified southside proxies are not configurable but the list is viewable at the CLI of your Brain appliance. For details please see linked documentation at: [Proxy handling in Vectra](/configuration/setup/proxies)

***Stream***

Vectra Stream delivers security-enriched metadata to a data lake or SIEM of the customer’s choice. If licensed for Stream, you can configure Stream settings in this area. For details please see linked documentation at: [Stream Deployment Guide](/deployment/stream/deployment)

### Configuration → SETUP → External Connectors

External connectors add context enrichment to the Vectra AI Platform. For example, adding Active Directory as an external connector will:

* Add host and account details retrieved from Active Directory to your host and account details pages.
* Enable Active Directory Account Lockdown as a response option.
* Enable Vectra to automatically map cloud domains to network realms so that Vectra can associate cloud and network accounts.

***Active Directory***

Linked documentation available at: [Configuring Active Directory(AD) integration with Vectra NDR](/configuration/setup/external-connectors/active-directory)

***AWS***

This integration enables your Vectra deployment to add relevant context (host ID, OS, instance ID, tags, etc) about Amazon EC2 hosts when observed by Vectra. For configuration details please see either:

* [AWS Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-brain)
* [AWS vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-vsensor)
* [AWS HostID integration](/configuration/setup/external-connectors/aws-hostid-integration)

***Azure***

This integration enables your Vectra deployment to add relevant context (host ID, resource group, admin username, etc) about Azure VMs when observed by Vectra. For configuration details please see either:

* [Azure Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/azure-brain)
* [Azure vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/azure-vsensor)
* [Azure HostID integration](/configuration/setup/external-connectors/azure-hostid-integration)

***Google Cloud***

This integration enables your Vectra deployment to add relevant context (host ID, project, link to vm, etc) about GCP VMs when observed by Vectra. For configuration details please see either:

* [GCP Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/gcp-brain)
* [GCP vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/gcp-vsensor)
* [GCP HostID integration](/configuration/setup/external-connectors/gcp-hostid-integration)

***Reverse DNS Lookup (rDNS)***

Configuring DNS servers for your Brain appliance is required and enabling reverse DNS lookup is a best practice. Reverse DNS lookup is especially helpful for HostID naming processes. rDNS lookup respects TTL and is generally not expected to overload configured DNS servers.

***SIEM***

Configuring here enables your Vectra Brain appliance to listen for events forwarded from SIEMs or other systems that can send DHCP log data in Infoblox and other ISC standard syslog formats. This is useful to help feed Vectra HostID (automated host naming). For configuration details, please see linked documentation at: [Event Forwarding Reference Guide](/configuration/setup/external-connectors/siem-vectra-brain-ingesting-logs)

***vCenter***

Configuring vCenter integration allows your Vectra deployment to query VMware vCenter and enable the \_Network Stats → Virtual Infrastructure\_view. It also feeds Vectra HostID with artifacts that help automated identification of hosts in your VMware environment. For details, please linked documentation at:

* [VMware Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/vmware-brain)
* [VMware vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/vmware-vsensor)
* [vCenter integration](/configuration/setup/external-connectors/vcenter-integration-vmware)

***Zscaler Private Access (ZPA)***

Configuring ZPA integration allows your Vectra deployment to map traffic seen by your Vectra network sensors between Zscaler App Connectors and endpoints in your internal environment to the original ZPA user/host. For details, please see linked documentation at: [Zscaler Private Access (ZPA) Log Ingestion Configuration](/configuration/coverage/remote-users/zscaler-zpa)

### Configuration → SETUP → General Settings

***Auto-Refresh Threat Dashboard***

This setting determines if the Discover → Threat Surface → Threat Summary Dashboard auto-refreshes itself every 10 min. This might be useful in a SOC if a monitor is dedicated for displaying this dashboard.

{% hint style="info" %}
**Please Note:**

Secure default setting is: **Off**

Security Implications: Enabling this feature will keep the user logged in past the configured idle period
{% endhint %}

***Inactive User Timeout***

Configure up to a 12-hour limit before externally authenticated users must re-authenticate to access UI.

{% hint style="info" %}
**Please Note:**

Secure default setting:

* 8 hours for Respond UX Commercial region deployments
* 15 minutes for Respond UX Federal region deployments

Security Implications: Increasing the idle timeout will reduce the frequency of required user logins. It is recommended to configure this to organizational standards.
{% endhint %}

***Timezone***

Configure the Timezone for your Vectra deployment.

***New Close Workflow***

The New Close Workflow is enabled by default for all Vectra deployments unless a customer has specifically disabled it during the public preview. For details, please see linked documentation at: [New Close Workflow](/operations/analyst-guidance/new-close-workflow).

It is still possible to disable the New Close Workflow, but Vectra plans to fully remove the legacy workflow in a future update. Please contact Vectra to discuss if this will be problematic for your deployment.

## Configuration → RESPONSE

In this area you can response options such as Lockdown across a wide variety of options and configure notification settings such as email alerts and external app alerts (webhook notifications).

### Lockdown

The full path for items in this area is *Configuration → RESPONSE → Lockdown.*

***Active Directory Account Lockdown***

Account Lockdown enables analysts to temporarily disable network accounts during a security investigation. Please see linked documentation at: [Active Directory Account Lockdown](/configuration/response/lockdown/active-directory-account-lockdown). Please note that at least one AD must be integrated at *Configuration → SETUP → External Connectors → Active Directory* for Active Directory Account Lockdown to function.

***Azure AD (Entra ID) Account Lockdown***

AAD Account Lockdown enables analysts to disable or revoke the session of malicious Azure AD and M365 accounts during a security investigation. Please see linked documentation at: [Azure AD (Entra ID) Account Lockdown FAQ (Respond UX)](/configuration/response/lockdown/entra-id-azure-ad-account-lockdown-rux)

***Host Lockdown***

Host Lockdown enables analysts to temporarily disable network hosts during a security investigation. Host Lockdown is enforced through the use of an integrated EDR's host isolation capabilities. Please see linked documentation at: [EDR Host Lockdown Information](/configuration/response/lockdown/host-lockdown-edr). Please note that at least one EDR must be integrated at *Configuration → SETUP → EDR Integrations* for Host Lockdown to function.

***Traffic Lockdown***

Traffic Lockdown is a network-level containment feature that enables Vectra to automatically add compromised host IP addresses to an external blocklist that your firewalls can subscribe to. When a host is added to Traffic Lockdown (manually or automatically), its IP address is published to a plain-text threat feed that integrated firewall devices poll and use to block traffic from that host. Please see linked documentation at: [Traffic Lockdown](/configuration/response/lockdown/traffic-lockdown)

### Notifications

The full path for items in this area is *Configuration → RESPONSE → Notifications.*

***Email Alerts***

Alert emails can be sent to email addresses or aliases. Alert types:

* Entity alerts
  * These alerts are sent when an entity (host or account) crosses the configured scoring threshold.
  * The Urgency Score Threshold is configurable and is set independently from the Prioritization Threshold that you may have set under *Configuration → TUNING → Prioritization Threshold.*
* Detection alerts
  * These alerts are sent when any selected Detection occurs.
  * Some customers may want Detection alerts for specific Detections that they consider critical, such as *Ransomware*, regardless of the current Entity score.
* System alerts
  * Alerts related to system operations are sent.
  * Examples are when there is a change in Sensor connectivity, capture interface health, or disk health.
* vCenter alerts
  * Alert related to changes in vCenter, such as new physical hosts being spun up that do not have vSensor coverage.
  * This requires vCenter integration to be setup.

***External App Alerts***

External App Alerts enable Vectra to deliver real-time notifications to external collaboration tools when critical events occur — such as hosts or accounts crossing prioritization thresholds or system alerts being triggered. For details please see linked documentation at: [External App Alerts (webhook notifications)](/configuration/response/notifications/external-app-alerts-webhook)

## Configuration → TUNING

***Triage Filters***

Triage enables teams to manage known, expected, or previously reviewed detection behaviors in a structured and auditable way. By creating targeted filters, security teams ensure the platform reflects what truly matters, improving the precision of scoring and prioritization without suppressing visibility or requiring manual alert review. For details, please see linked documentation at: [Triage Best Practices](/configuration/tuning/triage-best-practices)

***Groups***

Consistent use of groups helps ease triage filter creation and maintenance. For example, rather than building a set of conditions for authorized domains in several triage filters, it is much easier to simply create a group that can be used as often as required. Also, when group membership changes, you only need to update the group and not every filter that would have used the same members as individual conditions. For additional details please see:

* [Active Directory (AD) Groups](/configuration/tuning/active-directory-ad-groups)
* [Dynamic Groups FAQ](/configuration/tuning/dynamic-groups)

***Prioritization Threshold***

Editing the prioritization threshold allows customization of the minimum score required for a host or account to be considered prioritized. For additional details see linked documentation at: [AI-driven Prioritization FAQ](/reference/ai-driven-priortization-faq)

## Configuration → ACCESS

***API Clients***

Add and see the status of API clients for accessing the REST API of your Vectra Respond UX deployment.

* [Vectra REST API Documentation Website](https://apidocs.vectra.ai/)
  * This is a live site with the ability to download the API spec in .yaml form and also try live queries against your Vectra tenant.
* [Vectra Platform API Guide v3.4](/configuration/access/api-rux/v34-api-guide-rux)
  * Legacy .pdf documentation article that will eventually be retired in favor of the live documentation site above
* [Vectra Platform API Quickstart Tutorial](/configuration/access/api-rux/rux-api-postman-quick-start-guide)
* [Vectra Platform API Public Postman Collection](https://www.postman.com/vectra-internal/workspace/vectra-ai/collection/1058623-cc38478b-7261-4e59-8768-1cf61a68ec5d)

***Users***

Add new users, see their status, and edit or delete settings for local users in your deployment. SAML users can also be seen here but SAML users are not added using the **Create New User** process. SAML users are controlled by the IdP that is integrated with Vectra. Please see **External Authentication** below for links to SAML integration guides.

***Roles***

See and manage the permissions for roles that are assigned to both local and external (SAML) users for your deployment. Roles can be edited and the default permissions assigned to each role can be modified.

***External Authentication***

Allows configuration of external authentication options for login to Vectra. SAML is the only supported option today. For integration guides please see:

* [Setup SAML SSO with any IdP (Respond UX)](/configuration/access/saml-sso-rux/any-idp-saml-rux)
* [Setup SAML SSO with Azure AD (Respond UX)](/configuration/access/saml-sso-rux/entra-id-azure-ad-saml-rux)
* [Setup SAML SSO with Okta (Respond UX)](/configuration/access/saml-sso-rux/okta-saml-rux)
* [Setup SAML SSO with Keycloak (Respond UX)](/configuration/access/saml-sso-rux/keycloak-saml-rux)
* [Setup SAML SSO with ADFS (Respond UX)](/configuration/access/saml-sso-rux/adfs-saml-rux)

***Remote Support***

This is optional and allows Vectra Support access to the Brain command line shell for remote support, debugging, address potential performance problems, verify software updates, and perform troubleshooting.

* Utilizes Open VPN on TCP:443 and UDP:9970.
* Access to the shell is two factor secured, requires a support ticket to be logged, and is audited.
* Please note that this can be toggled on and off as required if you would prefer to not leave it enabled.

For additional detail, please see [Vectra Remote Support](/configuration/access/vectra-remote-support).


# Configuring data sources

Links to deployment guides for network Sensors, traffic validation, and other cloud data sources deployment guidance.

## Network (Sensors)

Physical and Virtual Sensors (vSensors) collect raw traffic from your network, store it in a rolling capture buffer, and generate a metadata stream that the Brain processes further. When detections are created by the Brain, a PCAP (if enabled) is requested from the Sensor that saw the traffic in question so that it can be attached to the detection for viewing by the analyst. Sensors can also be instructed to perform [packet capture](/deployment/traffic-engineering-and-validation/using-vectra-packet-capture-pcap) based on configured parameters.

Sensor deployment and pairing with the Brain is covered in the following guides:

* [Physical appliance deployment quick start guides](/deployment/ndr-physical-appliances) (All)
  * [X-Series](/deployment/ndr-physical-appliances/x-series) appliances can be used in Brain or Mixed mode.
  * [B-Series](/deployment/ndr-physical-appliances/b-series) appliances can only be used in Brain mode.
  * [S-Series](/deployment/ndr-physical-appliances/s-series) appliances can only be used as Sensors.
  * [M-Series](/deployment/ndr-physical-appliances/m-series) appliances can only be used for Stream.
* Traditional Hypervisor vSensor Deployment and Pairing:
  * [VMware vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/vmware-vsensor)
  * [Hyper-V vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/hyper-v-vsensor)
  * [KVM vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/kvm-vsensor)
  * [Nutanix vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/nutanix-vsensor)
* Cloud IaaS vSensor Deployment and Pairing:
  * [AWS Sensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-vsensor)
  * [Azure Sensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/azure-vsensor)
  * [GCP Sensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/gcp-vsensor)
* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all Vectra Sensor or Stream appliances with any Vectra Brain.

## Traffic Validation

Once you have deployed and added network Sensors to your environment, the next step is to direct traffic at those Sensors so they can produce metadata for analysis by the Brain appliance. This is typically done via SPAN/COPY/MIRROR ports on switches, network TAPs, or packet brokers. Please see the following Vectra support articles for recommendations on network traffic that should be examined and excluded from analysis:

* [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture)
* [Vectra Platform Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations)

After sending traffic to your Sensors, it is a best practice to validate that the traffic observed meets quality standards required for accurate detection and processing. Vectra’s Enhanced Network Traffic Validation feature provides alarms and metrics that can be used to validate the quality of your traffic. Please see the following Vectra support article for details:

* [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv)

## IDR for Azure AD & CDR for M365

IDR for Azure AD and CDR for M365 can be deployed at any time once you are able to access the Vectra Respond UX. Some capabilities after enabling a connection to Azure AD and M365 are:

* See and stop attackers targeting Federated applications, the Azure AD backend and all your M365 applications like SharePoint, Exchange and Teams.
* Respond to threats immediately with zero-query investigations.
* See through the chaos and understand how attackers could be bypassing MFA and accessing your tenant.

To enable this data source in your Cloud UI, navigate to *Configuration >* *Data Sources > Azure AD & M365* and click the “Get Started” button in the top right. The [Vectra IDR for Azure AD and CDR for M365 Quickstart Guide](/deployment/idr-for-azure-ad-and-cdr-for-m365) is also linked from this page:

## CDR for AWS

CDR for AWS can be deployed at any time once you are able to access the Vectra Respond UX. Some capabilities after enabling an AWS CloudTrail connection are:

* Monitor AWS CloudTrail Management and Data events to detect changes to your AWS environment which malicious actors can exploit to impact your org.
* Rapidly detect threats against AWS infrastructure without relying on signatures, agents, V-Taps, or static policies.
* Agentless monitoring of applications, users, roles, serverless compute, and storage, through AWS CloudTrail logs.
* Automate response to attacks with native integrations into AWS and 3rd party solutions to automatically stop attacks without impact to service.

To enable this data source in your Respond UX, navigate to *Configuration >* *Data Sources > AWS CloudTrail* and click the “Get Started” button in the top right. The [CDR for AWS Deployment Guide](/deployment/cdr-for-aws/deployment) is also linked from this page:

## CDR for Azure

CDR for Azure can be deployed at any time once you are able to access the Vectra Respond UX. CDR for Azure monitors Azure Activity and Resource logs to detect suspicious activity in your environment Some capabilities after enabling a connection to Azure are:

* **Azure Detections** - High fidelity detections of malicious behaviors in your Azure tenants based on our proprietary ML and security analytics capabilities.
* **Azure Threat Surface Dashboard** - Insights to help you identify security related threat patterns in your Azure tenants.
* **Azure Investiage** - Curated Azure metadata that allows you to perform in-depth investigations on potential threats in your Azure tenant. This data consists of enriched metadata fields and all the existing Advanced Investigation capabilities to help you efficiently conduct an investigation.

To enable this data source in your Respond UX, navigate to *Configuration > Data Sources > Microsoft Azure* and click the “Get Started” button in the top right. The [CDR for Azure Deployment Guide](/deployment/cdr-for-azure/deployment) is also linked from this page.


# Recommended next steps

Recommended actions after an initial RUX deployment, including backups, integrations, and deployment best practices.

## Backing up your Brain

As discussed earlier in the [Deployment Process Overview](#_Deployment_Process_Overview), the Brain appliance should be backed up by the customer. The Vectra cloud platform stores detections, metadata, and triage filters but the configuration of the Brain is not backed up by Vectra. Care should be taken to ensure backup to a Windows server, SFTP/SCP, or AWS S3 bucket.

Please see the following Vectra support portal articles for more details:

* [Backup and Restore for Vectra Brain Appliances (v8.5+)](/operations/backup-restore-dr/backup-and-restore-v85)
* [Vectra Brain Appliance Disaster Recovery (DR) / Migration Recommendations (v8.5+)](/operations/backup-restore-dr/disaster-recovery-and-migration-v85)

## Recommended Next Steps

Vectra offers a variety of deployment services, consulting, or full MDR options for customers that need more help or expert analyst assistance. Please work with your Vectra account team for additional details.

This guide covered initial configuration of basic settings. Some recommended next steps are:

* Work on [traffic engineering](/deployment/traffic-engineering-and-validation) and getting traffic flowing to your Sensors or mixed mode Brain.
* Integrations that help with HostID or add context such as:
  * [vCenter integration](/configuration/setup/external-connectors/vcenter-integration-vmware) if you have a VMware environment
  * [SIEM Event Forwarding](/configuration/setup/external-connectors/siem-vectra-brain-ingesting-logs)
  * [Windows Event Log ingestion](/configuration/coverage/network-identities-weli/windows-event-log-ingestion-weli)
  * [EDR integration](/configuration/setup/edr-integrations)
  * [AD integration](/configuration/setup/external-connectors/active-directory)
* Integrations to enable taking action.
  * [AD](/configuration/setup/external-connectors/active-directory) and [EDR](/configuration/setup/edr-integrations) integration bring [host](/configuration/response/lockdown/host-lockdown-edr) and [account](/configuration/response/lockdown/active-directory-account-lockdown) Lockdown capability.
  * [Entra ID (Azure AD) Account Lockdown](/configuration/response/lockdown/entra-id-azure-ad-account-lockdown-rux) works with and Azure AD data source.
* Enabling [Stream](/deployment/stream).
* Setting up [SSO using SAML](/configuration/access/saml-sso-rux) if you have not already done so.
* Building groups and [triage rules](/configuration/tuning/triage-best-practices) to suppress unwanted detections for authorized behaviors.

## Best Practices

* Change default passwords for the 'admin' (GUI) and `vectra` (CLI and IPMI/iDRAC) users to strong versions.
  * See [ssh login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) for details on accessing the CLI of your Brain appliance.
  * Passwords must be between 8 and 128 characters and contain at least: 1 number, both lowercase and uppercase letters, and 1 symbol (e.g. \~!@#$%^&\*,.?-\_+=).
* Limit exposure to admin interfaces through firewall rules that permit communication only from appropriate nodes/networks (including Vectra required endpoints as well).
* IPMI / iDRAC interfaces should be on their own isolated networks when possible.
  * See [IPMI / iDRAC configuration](/deployment/appliance-operations/ipmi-idrac-configuration) for more details.


# Respond UX specific

Respond UX-only deployment and configuration guidance.

{% content-ref url="/pages/8p6aYZA3gq7nm3Ti2ruM" %}
[Initial login - protecting your MFA secret key (RUX)](/deployment/getting-started/respond-ux-deployment/initial-login-protecting-your-mfa-secret-key-rux)
{% endcontent-ref %}

{% content-ref url="/pages/u0xXzJJl62qOmKd27lo5" %}
[Global View](/deployment/getting-started/respond-ux-deployment/global-view)
{% endcontent-ref %}

{% content-ref url="/pages/WBvk2JXZg4tGDD7OZ2bb" %}
[SIEM connector (syslog intermediary)](/deployment/getting-started/respond-ux-deployment/siem-connector-syslog-intermediary)
{% endcontent-ref %}

{% content-ref url="/pages/04yTaarHnEHzS0w9GWYZ" %}
[Why migrate to RUX from QUX Migration to RUX from QUX](/deployment/getting-started/respond-ux-deployment/why-migrate-to-rux-from-qux-migration-to-rux-from-qux)
{% endcontent-ref %}


# Initial login - protecting your MFA secret key (RUX)

Secure your MFA secret during first login and avoid account lockouts.

Please note!! - This article is ONLY for customers using Vectra's Respond UX. If you are unsure which UX you are using, please see: [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux) for more information .

## Adding MFA with Secret Key Backup

When you first access the Vectra AI Platform, you will be prompted to set up multi-factor authentication on your mobile device. A prompt will appear to scan a QR code that contains a secret key.

![](/files/ptk2qR88F1Wrr95pGP4A)

Once the QR code is scanned, linked to your authenticator app, and the six-digit code inputted into the Vectra, you will receive a secret key. This secret should be saved to provide a backup for creating a different authenticator app for the user.

![](/files/AsOe9pLkRbgeceSRC5l2)

To use the Secret Key to register a new authenticator app, manually add the saved secret key when prompted in the app. The opportunity to register by secret key is prompted in the same flow as when a QR code is scanned. Account names are to help track what the key should be associated with.

![](/files/PM5jYifWBtxEVeULKhG1)


# Global View

Demo video, applicability, capabilities, onboarding/deployment, architecture, and answers to your frequently asked questions (FAQs) about Global View for RUX deployments.

## Global View Feature Release Demo

Please see the below link for a video release demo of the feature:

{% embed url="<https://youtu.be/6QCD1aAUgPw>" %}

## Applicability and Requirements

* You must have at least two Respond UX instances (deployments) if you want to use Global View.
  * If you are unsure of your deployment type, please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux).
* You must request a Global View "anchor" instance via your Vectra account team.
  * The account team will need the email address for a Super Admin user of the anchor instance.
  * A welcome email will be sent that provides local credentials for a Super Admin user.
  * SAML or local auth for additional users can be setup by this user once they log in to the anchor instance with the local account.
* For additional onboarding details please see the [Onboading-Deployment](#Onboading-Deployment) section.
  * After receiving the welcome email, onboarding child instances into the Global View anchor instance can be done in a self-serve manner.

## Capabilities

**What is Global View**

* Global View is a **free** feature for RUX deployments that enables a unified “Global Respond” view of prioritized entities in a new “anchor” instance of RUX that is created when a customer onboards to Global View.
  * The anchor instance only shows the Global Respond view. For functionality outside of the Global Respond screen, customers can drill into the child instance that contains the prioritized entity.

**What customer use cases does Global View address?**

* Global SOCs overseeing diverse regions or subsidiaries.
* Overcoming technical issues like IP overlap or data transfer costs.
* Scaling for those customers whose traffic engineering requirements require multiple Vectra Brains.
* Partners looking to centrally monitor their customers using Vectra.

**Can the view be filtered?**

* Yes, the view can be filtered by selecting various “Quick Filters” such as:
  * **Vectra Instances** – child instance label (representing each RUX deployment that is connected).
  * **Detections In** – Data sources such as (Network, Azure AD and M365, AWS Cloudtrail, Azure, etc).
  * **Entity Type** – Host or Account.
  * **Killchain** – Botnet Activity, Command and Control, Exfiltration, Lateral Movement, Reconnaissance.

**Can detections be displayed?**

* Yes, the Global Respond screen shows the same entity cards that you see in any child instance Respond screen.
* The “Show Active Detections” button on an entity card is visible to show summary information for detections attributed to the entity.
* If you need more than summary information from the entity card, you can drill into the child instance for full entity and detection pages.

**Do screens in Global View automatically refresh?**

* No, data is pulled live upon login to Global View and can be refreshed by reloading the page.

## Onboarding/Deployment

### **How does a customer onboard into Global View?**

* After receiving your welcome email and logging in to the Global View anchor instance, navigate to *Configuration > Child Instances* and click on "Add Child Instance".

<img src="/files/5kTulPbaIpG3ip4so3R4" alt="" width="563">

* After you have entered the URL for a child instance, click the "Generate Credentials" button.
  * Do not include anything after the .vectra.ai portion of the URL.
* A new tab will open for the child instance.
* If you do not already have an established session with the child instance that you are connecting, you will need to login to the child instance.
* You will be seeing a "Create Global View API Client Credentials" dialog with a default "Client Name" and "Update Instance Name" already filled in.
  * The **Client Name** is the name of the API client that is being created on the child instance.
    * This API client will be used by the anchor instance to retrieve data for display in the Global View.
  * **Update Instance Name** allows you to change the instance name for the child instance.
    * The instance name will be displayed in the Global View and can be used to help filter the view.
    * If you want to change the instance name in the future, you can do so at *Configuration > Setup > General Settings > Instance Name* in the child instance.
  * Optionally enter a description and then click "Generate Credentials"

<img src="/files/yavvvAEWujbOisX8r6nH" alt="" width="563">

* You should see a message at the top that says the Global View api client was created and be presented with another dialog with the Client ID and Secret Key.
* Use the "Copy" buttons to copy these one at a time to the appropriate fields in the anchor instance tab that has the not yet completed "Connect Child Instance to Global View" dialog.
  * The Secret Key will only be displayed while this dialog is open. Make sure you have either completed setup in the other tab or saved these values before clicking done.
  * If mistakes are made or errors occur, you can simply delete the API client from the child instance, and start again adding the child instance.

<img src="/files/bMKWkiF6B2SJ6WOa5egV" alt="" width="563">

* Once you have completed filling in the "Connect Child Instance to Global View" dialog on the anchor instance, click "Create Connection".

<img src="/files/OKH6rkPRedmTJOfkyAJd" alt="" width="563">

* You should receive a "Link Child Instance Successful" message at the top of your screen and see your new child instance in the list of connected child instances:

![](/files/2ifXaBYem1TqzjPo8Hk0)

* Repeat this process for any other child instances that you wish to add to Global View.

### Additional Onboarding Guidance

**Time zone** for the anchor instance

* This can be configured by a Super Admin in Configuration > SETUP > General *Settings > Timezone* in the anchor instance.
* This defaults to UTC.

**Additional Users and Authentication**.

* Super Admin users can configure additional users or authentication options.
  * Additional users for Global View must have the "Global Analyst" permission as part of their assigned role as detailed in "How is access to Global View controlled on existing RUX instances"
    * This applies to both the anchor instance and any child instance(s).
* Additional users can be configured by a Super Admin:
  * Authentication options are SAML (suggested), or direct login (local users).
  * Navigate to *Configuration > Users* (in the Global View "Anchor" instance) or *Configuration > Access > Users* (in a Child instance) to create new local users.
  * Navigate to *Configuration > External Authentication* (in the Global View "Anchor" instance) or *Configuration > Access > External Authentication* (in a Child instance) to configure SAML profiles.
    * SAML users are NOT added like local users are, the IdP configured in the SAML profile manages users, Vectra trusts the IdP and maps users and roles based on what is in the SAML assertion.
* SAML setup works the same as it does for any other RUX deployment. Please see the following KB articles for SAML setup guidance if required:
  * [Setup SAML SSO with any IdP (Respond UX)](/configuration/access/saml-sso-rux/any-idp-saml-rux)
  * [Setup SAML SSO with Azure AD (Respond UX)](/configuration/access/saml-sso-rux/entra-id-azure-ad-saml-rux)
  * [Setup SAML SSO with Okta (Respond UX)](/configuration/access/saml-sso-rux/okta-saml-rux)
  * [Setup SAML SSO with ADFS (Respond UX)](/configuration/access/saml-sso-rux/adfs-saml-rux)
  * [Setup SAML SSO with Keycloak (Respond UX)](/configuration/access/saml-sso-rux/keycloak-saml-rux)

## Additional Deployment FAQs

**How is access to Global View controlled on existing RUX instances?**

* A new permission called “Global Analyst” controls which users can see the Global View link in their RUX instances.
  * The “Global Analyst” permission is enabled by default on Admin, Super Admin, and Global Analyst roles.
  * “Global Analyst” is also a new default role on instances that can participate in Global View.

**What permissions does the Global Analyst role include?**

* By default, the role permissions for a Global Analyst are the same as for a Security Analyst with the exception of the individual “Global Analyst” permission. That is only available by default in the Global Analyst role.

**Can the Global Analyst role be modified?**

* Yes, but at a minimum, the role must contain the “Global Analyst” permission in order for the feature to function properly.
  * The API client used for Global View is mapped to the Global Analyst role.

**How does login to the anchor instance work?**

* Both SAML and direct(local) login are available and can be configured by a Super Admin user in the anchor instance.

**How does Global View deal with Brain replacements in RUX for Network deployments?**

* RUX for Network refers to deployments that involve network data sources (Sensors).
  * The Sensors are paired to a Brain appliance that is linked to the RUX instance.
* Global View interoperates with RUX instances only and all communications are contained withing the Vectra Cloud.
  * Global View has no knowledge of Brains that may be linked to child RUX instances.
* If a Brain, linked to a child RUX instance, is replaced in any kind of fail over, standby, etc scenario, the “--replace” option should be used during the restore to ensure the replacement Brain that was the target of the restore operation is properly linked to the existing child RUX instance.
  * Please see [Backup and Restore for Vectra Brain Appliances (v8.5+)](/operations/backup-restore-dr/backup-and-restore-v85)\*\* \*\*for details on backup and restore operations.
  * Please see [Vectra Brain Appliance Disaster Recovery (DR) / Migration Recommendations (v8.5+)](/operations/backup-restore-dr/disaster-recovery-and-migration-v85) for details on DR/Migration scenarios.
* Global View is not impacted, and the configuration of the anchor or any child RUX instance does not need to be updated.

## Architecture

![](/files/KtOEHw7yUAyJkuc77Z4q)

**How does Global View work?**

* A new anchor instance is provisioned in the Vectra region of your choice.
* Child tenants have API clients created for use by the anchor instance.
* The anchor tenant uses API calls to retrieve prioritized entities and detection details from the child instances for display in Global View when a user with the Global Analyst permission logs into the anchor instance.
* Global analysts can move back and forth from Global View to the child instances linked to Global View at will.

**Are ML learnings or host sessions shared between child instances?**

* No, each underlying child instance operates independently.
  * In this way, overlapping IP spaces are supported.
  * If the same traffic is seen by multiple Brains that are connected to child RUX instances, each child RUX instance will have its own set of ML learnings, host sessions, detections, entities, etc.

**What data is stored in the anchor instance?**

* No data is stored in the anchor instance.
  * All data is retrieved on demand when a user accesses Global View or refreshes the page in Global View.

**What firewall rules or special requirements are there for the child instances?**

* There are no firewall rules or special requirements for the child instances.
  * All communications are encrypted within the Vectra cloud and are between the RUX instances involved (anchor and child instances).
  * For customers with Network data sources, there is no need to communicate with the Vectra Brain and/or paired Sensors.

**What Vectra products are supported by Global View?**

* All Vectra products supported in RUX deployments are supported in Global View.

## Miscellaneous FAQs

**Can Global View help customers meet compliance or regulatory standards?**

* Yes, some customers are required to separate data for compliance reasons. No data is stored in the anchor instance, and data will remain separated in child instances.

**Are there any costs for Global View?**

* No, Global View is a free feature available to any customer using the Respond UX.

**How does support work for Global View?**

* Please open a support case on the [Vectra Support Portal](https://support.vectra.ai/).

**What are common issues that can occur?**

* If an API client for a child instance is deleted, then Global View will no longer function for data from that child instance.
* If the Global Analyst role is changed in a child instance and no longer contains the required Global Analyst permission, then Global view will fail for that child instance.


# SIEM connector (syslog intermediary)

How to configure a syslog intermediary server to poll the RUX API and then send data via syslog to a downstream collector.

## Introduction

As per the article summary, when using the Respond UX (RUX) to access the Vectra AI Platform, syslog is not natively supported and event retrieval is supported via API. If syslog output of Vectra events is required, the SIEM Connector installed in the customer environment can provide syslog output. It provides organizations with a turnkey solution to connect any log management solution or SIEM that supports syslog to the Vectra AI Platform (RUX).

This connector allows:

* Pulling data from the [Vectra Respond UX API](/configuration/access/api-rux/v33-api-guide-rux) at regular intervals.
* Storing and sending events to any syslog-aware solution.
* Support of TCP, UDP or TLS for syslog transport.

The events that are being pulled by the SIEM Connector are:

* Entity scoring events
* Detections events
* Audit events

All events are in JSON format. Only syslog headers are being added to the payload before being sent out.

## Native SIEM/SOAR Integrations

It is highly recommended to use a native integration that works with the RUX API when possible. Only use the SIEM connector when a API-based integration is not possible. Several integrations using the API have already been published such as:

* [Crowdstrike Falcon Next-Gen SIEM](https://falcon.crowdstrike.com/documentation/page/a7373282/vectra-respond-ux) (credentials for Crowstrike Falcon required to access Crowdstrike docs at link)
* [Splunk Integration Guide for Vectra XDR (Respond UX)](/configuration/response/siem/splunk-siem-vectra-integration-guide-start-here-for-rux) ​​​​​​
* [QRadar Integration Guide for Vectra XDR (Respond UX)](/configuration/response/siem/qradar-siem-integration-rux) ​​​​​​
* [Azure Sentinel Integration Guide for Vectra XDR (Respond UX)](/configuration/response/siem/azure-sentinel-siem-integration-rux) ​​​​​​
* [Splunk SOAR Integration Guide for Vectra XDR](/configuration/response/soar/splunk-soar-integration-rux)
* [Palo Alto XSOAR Integration Guide for Vectra XDR](/configuration/response/soar/palo-alto-xsoar-integration-rux)
* [ServiceNow SIR Integration Guide for Vectra XDR](/configuration/response/soar/servicenow-sir-soar-integration-rux)
* [ServiceNow ITSM Integration Guide for Vectra XDR](/configuration/response/ticketing/servicenow-itsm-ticketing-integration-rux)
* [Google SecOps Integration Guide for Vectra XDR (Respond UX)](/configuration/response/siem/google-secops-siem-integration-rux)

## Solution Overview

## Pre-requisites

<figure><img src="/files/xcZKbcQl6AEB5LoQEwxl" alt=""><figcaption></figcaption></figure>

Below are the prerequisites for setting up the Vectra SIEM connector.

* Users must have a Linux based server to provide as a host for the Docker container.
* Users must have access to a Vectra Respond UX tenant with `client_id` and `client_secret` for API authentication using the role Auditor.
  * Additional information about the API is available here: [Vectra SaaS API Guide v3.4](/configuration/access/api-rux/v33-api-guide-rux)
* Users must configure a syslog destination server to receive data over UDP, TCP or TLS.
* **Docker (version 24.0.5 minimum)**
  * Refer to <https://docs.docker.com/engine/install/#server> for installation instructions.
  * **​​​​​​**`$ docker version` - Will show the version to allow you to validate it.
* **Docker compose (version 2.20.2 minimum)**
  * Refer to <https://docs.docker.com/compose/install/linux/> for installation instructions.
  * `$ docker compose version` - Will show the version to allow you to validate it.

## Minimum System Requirements

To run the connector, the following are the minimum requirements where you will run the connector:

* 4 GB of RAM
* 20 GB of free storage

## Compatibility Matrix

| Compatibility Point           | Version Supported       |
| ----------------------------- | ----------------------- |
| Vectra AI Platform (SaaS) API | v3.3 and higher         |
| Operating System              | Windows, Linux (Ubuntu) |

## Download and Initial Setup

The connector is available in the "vectranetworks" GitHub: [Click here](https://github.com/vectranetworks/siem-connector/blob/main)\
Clone the repo to get started:

```ckeditor_codeblock
git clone https://github.com/vectranetworks/siem-connector.git
```

## Configuration

### Vectra API Configuration

The information relative to the API are being passed to the container through the [docker-compose file](https://github.com/vectranetworks/siem-connector/blob/main). Below is the relevant part for this configuration:

```ckeditor_codeblock
environment:
    BASE_URL: <VECTRA-TENANT-BASE-URL>
    CLIENT_ID: <VECTRA_CLIENT_ID>
    CLIENT_SECRET: <VECTRA_CLIENT_SECRET>
```

### Optional Configuration - No Triage

The default image retrieves all detection details including those that have been triaged. To prevent triaged detections from being ingested, modify line 19 of `docker-compose.yml` as follows and save before launching.

```
image: tmevectra/vectra-saas-siem-connector:no_triage
```

### Target Configuration

Then, provide destination server details and cron schedules for each APIs in the `config.json` file:

```ckeditor_codeblock
{
  "configuration": {
      "server": [
          {
              "name": "<server-name>",
              "server_protocol": "<server-protocol>",
              "server_host": "<destination-server-ip-or-host>",
              "server_port": <destination-server-port>
          }
      ],
      "scheduler": {
          "audit": "<cron-expression-for-audit>",
          "detections": "<cron-expression-for-detections>",
          "entity_scoring": "<cron-expression-for-entity-scoring>"
      },
      "retry_count": <retry-count>
  }
}
```

#### Description of each field:

|                                               |                                                                                                                                                                                                                                            |                                                |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------- |
| **Field**                                     | **Description**                                                                                                                                                                                                                            | **Possible Values**                            |
| <p><br><strong>Server Details</strong></p>    |                                                                                                                                                                                                                                            |                                                |
| name                                          | Destination server name                                                                                                                                                                                                                    | alphabets, number, \_ , -(Minimum 1 character) |
| server\_protocol                              | Protocol supported by destination server                                                                                                                                                                                                   | TCP, UDP, TLS, tcp, udp, tls                   |
| server\_host                                  | Destination server host or IP address                                                                                                                                                                                                      | Valid IP or hostname                           |
| server\_port                                  | Destination server port which is able to receive data on configured protocol                                                                                                                                                               | Min: 1Max: 65535                               |
| <p><br><strong>Scheduler Details</strong></p> |                                                                                                                                                                                                                                            |                                                |
| audit, detections, entity\_scoring            | API will fetch events on provided respective cron intervals                                                                                                                                                                                | Valid cron expression                          |
| retry\_count                                  | Number of times the connector will retry before exiting in case the server is not reachable (If a negative value is given, the connector will continue retrying until server is reachable). It is not recommended to use a negative value. | Positive or negative integer                   |
|                                               |                                                                                                                                                                                                                                            |                                                |

The *recommended* configuration for **cron** is to pull every minute and set a *retry\_count* to 2:

```ckeditor_codeblock
"scheduler": {
    "audit": "* * * * *",
    "detections": "* * * * *",
    "entity_scoring": "* * * * *"
},
"retry_count": 2
```

If desired, some guidance around setting cron expressions is available here: <https://crontab.guru/>

In case of TLS servers, provide a TLS configured server `certificate.pem` file in the `cert` folder.

{% hint style="info" %}
**Please Note:**

Certificate file name should be the same as the server name provided in `config.json`.
{% endhint %}

## Connector Management

### Start the Connector

The docker-compose configuration defines the two containers that are required for this solution:

* `rabbitmq` RabbitMQ as a queue mechanism which handles tasks and data preservation.
* `vectra-saas` Contains a Vectra Syslog Connector (python application) which will fetch data from Vectra API and push data to the configured syslog server.

Both images are being pulled from Docker Hub. There is no need to build the image for `vectra-saas` locally. To start the connector, run:

```ckeditor_codeblock
docker compose up -d
```

### Stop the Connector

In case you need to stop the connector, run:

```ckeditor_codeblock
docker compose stop
```

This would be required for example if the config file is modified.

### Terminate the Connector

In case you need to terminate the connector (this removes containers):

```ckeditor_codeblock
docker compose down
```

### Restart Policy

In case of any failure or restart of the server, the containers would be automatically restarted. This is controlled by docker-compose with the [restart policy.](https://docs.docker.com/config/containers/start-containers-automatically/)

## Output's log format

It follows [RFC 5234](https://www.rfc-editor.org/rfc/rfc5424.html) specifications. The Syslog message that is sent out has the following format:

```ckeditor_codeblock
<PRI> <TMESTAMP> <HOSTNAME>: <MSG>
```

Description:

* *PRI*: Facility and Severity. It is set to <14> (Facility=user-level and Severity=info)
* *TIMESTAMP*: Formalized timestamp
* *HOSTNAME*: The HOSTNAME is static and set to VECTRA-SYSLOG-CONNECTOR.
* *MSG*: JSON payload pulled from Vectra's AI Platform API

Example of a detection event:

```ckeditor_codeblock
<14>2023-11-02T00:18:01Z VECTRA-SYSLOG-CONNECTOR: {"id": 1098, "category": "reconnaissance", "threat": 40, "certainty": 40, "triaged": false, "detection_type": "AWS Suspect Escalation Reconnaissance", "d_type_vname": "AWS Suspect Escalation Reconnaissance", "detection_href": "https://<REDACTED>.cc1.portal.vectra.ai/detections/128?detail_id=1098", "entity_id": 31, "entity_type": "account", "type": "account", "url": "https://<REDACTED>.cc1.portal.vectra.ai/accounts/31", "severity": 4, "event_timestamp": "2023-09-14T16:56:07Z", "detection_id": 128, "entity_uid": "AWS:<REDACTED>", "detail": {"event_name": "ListAttachedRolePolicies", "event_id": "7e905780-ed55-40b1-bb79-ae82e4287a47", "account_id": "<REDACTED>", "src_external_host": {"ip": "74.201.86.232", "name": null}, "assumed_role": "SecurityAuditExtended", "access_key_id": "<REDACTED>", "aws_region": "us-east-1", "request_parameters": "{\"roleName\":\"AWSServiceRoleForApplicationAutoScaling_ECSService\"}", "response_elements": null, "error_code": null, "error_message": null, "role_sequence": ["AWS:<REDACTED>", "SecurityAuditExtended"], "user_agent": "aws-sdk-go-v2/1.20.1 os/linux lang/go#1.20.7 md/GOOS#linux md/GOARCH#amd64 api/iam#1.22.2", "identity_type": "AWS External Account", "last_timestamp": "2023-09-14T16:33:22Z"}}
```

## Logs and Common Error Messages

When using docker compose, it automatically maps a volume to access logs from the host (in same directory). They will be located in the `logs` folder and a new file will be created every day. This contains all the application logs and will be required to troubleshoot any issues that occurr. Some common errors are described below:

### Connection Refused Error

*Summary*: When syslog server is not reachable then connector will give the error of connector refused.

![](/files/nWdzWl9EZABGshJao0Kp)

### Vectra API Down Error Message

*Summary*: If the credentials are incorrect or the vectra APIs are offline, the connector will display the **Vectra API server is down** error.<br>

<figure><img src="/files/vspdcmDSQWkcCy5s7IMk" alt=""><figcaption></figcaption></figure>

### Validation Errors

*Case 1*: If the provided IP of the syslog server is invalid then it will give the IP validation error.\
\
\&#xNAN;*Case 2*: If provided cron expressions are invalid then it will give the cron expression validation error.<br>

<figure><img src="/files/cIktYIet7uhfj3TseEjN" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yVoNu7zgRQtepnqckVJ6" alt=""><figcaption></figcaption></figure>

### Too Many Requests Error

*Summary*: The connection will display the **Too Many Requests** warning if the Vectra API is too busy to authenticate.\
After 30 seconds, the connector will retry three times in the **Too many Requests** scenario.<br>

<figure><img src="/files/nJtjKv2Ao6L5gdVabegF" alt=""><figcaption></figcaption></figure>

### No Such File or Directory

*Summary*: The connector will fail with the **No such file or directory** error if the server name and certificate name are different in TLS protocol.

<figure><img src="/files/gOie4pQdCjmsT9kp2Ldn" alt=""><figcaption></figcaption></figure>

## Alternate Setup

Depending on your preferences and architecture, you could setup this connector without using `docker compose`. Vectra provides the source code to allow anyone to fork it and customize it the way they need. In addition to that, we provide the **`Dockerfile`** in the **`vectra-connector`** folder to either:

* Create the image locally without relying on Docker Hub
* Customize the image for your need.

## Resources

* Github project: <https://github.com/vectranetworks/siem-connector/tree/main>


# Why migrate to RUX from QUX Migration to RUX from QUX

Reasons to move from QUX to RUX, plus key workflow and feature changes.

The Vectra AI Platform is the integrated signal powering XDR providing hybrid attack surface coverage across identity, public cloud, SaaS, and data center networks; AI-driven Attack Signal Intelligence that prioritizes real attacks in real-time; and integrated, automated, and managed response to move at the speed and scale of hybrid attackers.

**Why Migrate to the Vectra AI Platform with Respond UX:**\
This document provides customers an overview of the Vectra AI Platform (with Respond UX) in comparison to the Vectra's appliance-based Detect platform (with Quadrant UX). In this document you will learn the differences between the two offerings and why migrating to the Vectra AI Platform promises to deliver additional value to your organization.

If you would like to migrate to the Vectra AI Platform with Response UX, reach out to your account team.

**Vectra AI Platform Migration Guide:**\
We have made the migration process to the Vectra AI Platform simple and straightforward. This document provides answers to common questions regarding migration and includes details on our 3-step migration process.

* !! Please note that there are firewall rules included in the migration guide that are required to be in place for successful migration to the Respond UX from the Quadrant UX.
* In addition to the migration guide, there is also a [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) that while intended for new deployments, some customers have appreciated reading in addition to the migration guide.

### Attachments

{% file src="/files/R1IWXKfhzRIGbeGK9llk" %}

{% file src="/files/q9iDA0o0t1zHIGZTQ8B4" %}


# Quadrant UX deployment guide

End-to-end guide for deploying Vectra Quadrant UX, including requirements, firewall rules, deployment steps, data source setup, initial configuration, and post-deploy next steps.


# Introduction and overview

Introduction and overview of the Vectra AI platform for Quadrant UX (QUX) deployments and appliance modes

## Introduction

This guide is intended to help customers or partners get started with a with a Quadrant User Experience (Quadrant UX or QUX) deployment of the Vectra AI Platform. The User Interface (UI) for a QUX deployment is served from a Brain appliance that is installed in your premises (physical data center, traditional hypervisor, or IaaS cloud).

{% hint style="info" %}
For users working with the Respond UX, the UI is served from Vectra’s cloud as part of the overall Vectra AI Platform. Please refer to the [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) if you are planning to deploy using the Respond UX. If you are unsure of your deployment type, please see [analyst UX options](/deployment/getting-started/analyst-ux-options-rux-vs-qux).
{% endhint %}

This guide will include an overview of the platform including components and Vectra terminology. It covers firewall rules that may be required in your environment, guidance for air-gapped deployments, initial settings, and recommended next steps. It is intended for use regardless of your deployment method (physical appliances, virtual appliances, cloud (IaaS), etc).

This guide is meant to be used in conjunction with related guides in the deployment area of the overall documentation site. Here you will find guides that are relevant for deploying NDR physical, virtual, and cloud Sensors, other Vectra SaaS products such as CDR for AWS and M365, IDR for M365, Match, and Stream.

## Vectra AI Platform Overview

A Quadrant UX deployment typically includes several components of the overall Vectra AI Platform:

* Brain appliance – installed in customer premises (physical or virtual datacenter or IaaS cloud).
* Data sources such as
  * Network (campus, data center, and IaaS clouds)
  * Public cloud
  * SaaS
  * Identity

![](/files/e9f477006d62ffafba88d5fdc7801cf1ae678788)

The diagram above shows a conceptual high-level deployment with Sensors in IaaS clouds, SaaS and Identity data sources, Sensors in physical locations, Vectra’s cloud, a SOC with a Brain installed locally that feeds a customer data lake via Vectra Stream, and integration with SOAR/SIEM that is done locally with the Brain. The simplest deployment is a single Vectra X-series appliance that is deployed in mixed mode and acts as both a Brain and Sensor.

The metadata that Vectra processes is valuable to customers for investigation, compliance, security posture assessment, and many other reasons. Metadata can be made available to customers via Stream and Recall.

* Admins and analysts login to the Brain locally to access the Quadrant UX.
  * Analysts can login from anywhere provided the customer has VPN or other access to the Brain from the analyst work locations.
* Physical or Virtual Sensors will be deployed and paired with your Brain to capture network metadata across hybrid environments.
  * Vectra supports IaaS public clouds, datacenters, remote workers, and campuses.
* Customer with non-network data sources must allow their Brain to connect to the Vectra cloud to retrieve detection data.
  * Detection processing for SaaS data sources happens in Vectra’s cloud.
* SOAR/SIEM/EDR/etc integration all happens from the customer Brain to these configured integrations.

### Appliance Modes

The 3 modes are Brain, Sensor, and Mixed. S-series appliances and virtual Sensors function only as Sensors. B-series appliances and virtual Brains function only as Brains. X-series appliances can be configured as Brains or Sensors. The X29 appliance can also function in mixed mode.

**Brain Mode**

* Serves as the central point of management for a Quadrant UX based deployment.
* Processes / deduplicates and optionally forwards metadata received from Sensors (when licensed for Recall or Stream).
* Runs NDR when licensed for it.

**Sensor Mode**

* Must be paired to Brain.
* Captures / deduplicates traffic.
* Forwards metadata to Brain.
* Houses rolling capture buffer to enable PCAP retrieval when requested from the Brain.

**Mixed Mode**

* Performs both Brain and Sensor functions.


# Firewall requirements

Firewall requirements for your Quadrant UX (QUX) deployment.

## Firewall Requirements Sections

[Important Notes](#important-notes)\
This section covers Respond UX vs Quadrant UX applicability. It also covers SSL inspection, internet/air-gap requirements, and remote support IP range conflicts.

[Vectra Cloud Connectivity](#vectra-cloud-connectivity)\
This section covers connectivity to Vectra services hosted in Vectra’s cloud. It is mainly for Respond UX deployments. The [Auth Gateways](#auth-gateways) section also applies to Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.

[Appliance Connectivity](#appliance-connectivity)\
This section covers connectivity required for Vectra appliances (physical or virtual). It applies to both RUX for Network and Quadrant UX deployments. This section also contains additional details regarding connectivity from Vectra appliances to the Vectra cloud.

## Important Notes

### Respond UX vs Quadrant UX Applicability

The Respond User Experience (Respond UX or RUX) and the Quadrant User Experience (Quadrant UX or QUX) are two different analyst user experiences that Vectra offers. It is important to differentiate between the different UX's when looking at requirements for FW rules. Some FW rules will only apply to deployments using the Respond UX and some will apply only to deployments using the Quadrant UX. For additional information please see: Vectra Analyst User Experiences (Respond vs Quadrant).

While the Respond UX is delivered from Vectra's cloud as part of the overall Vectra AI Platform, it can be used without traditional Brain and Sensor appliances when only non-network data sources are used. RUX for Network deployments (using network Sensors with the Respond UX) still require a Brain appliance to be installed in the customer environment (which can be in IaaS clouds or physical data centers, etc). Sensors will be deployed and paired with that Brain to capture network traffic for analysis.

Requirements listed below that apply only to RUX for Network deployments or only to QUX deployments will be labeled as such.

### Firewall/Proxy SSL Inspection

Please note that Vectra appliances validate SSL certificates for all HTTPS connections. For this reason, SSL/TLS inspection on firewall and proxy appliances must be disabled for these connections to work.

We have also identified that some firewall software transparently enables SSL inspection if certain filters (DNS hostname filtering) are enabled. This is not necessarily obvious to the administrator and should be investigated if connectivity issues are being observed.

### Internet Access From Vectra Brain

A Vectra Brain requires connectivity to the automatic update service for normal operation. This connectivity is used for automatic (including security) updates and to synchronize keys for cryptographic authentication of sensors.

The Brain requires Internet DNS resolution to obtain the IP addresses for these requests. The customer may choose public/Internet DNS servers or internal DNS servers; however, Internet DNS entries must be resolvable by the Brain. Please note that DNS is often considered to be a UDP-only protocol, however, TCP may be used depending on the type of DNS transaction. Both UDP and TCP use port 53 and should be permitted to all configured DNS servers.

Vectra can function in air-gapped environments when a Quadrant UX based deployment is done, but there will be some impacts such as:

* Vectra Threat Intelligence detections will be disabled.
* Suspect Domain Activity detection will be disabled.
* Context enrichments from external sources such as whois, etc that are displayed in certain models will not function.

Please see the [Vectra Quadrant UX Deployment Guide](https://support.vectra.ai/s/article/KB-VS-1077) for additional details about air gap environments including guidance for offline updates. Respond UX for Network is not possible in air-gapped environments since the Respond UX is delivered from Vectra's cloud and communicates with a locally installed Brain.

### Internet Access to Vectra Appliances

As with all security infrastructure Vectra appliances should be blocked from Internet access and access should only be granted from trusted workstations and/or authenticated sources.

### Management Network IP Address Range Conflicts with Remote Support

Customers should note that the following IP ranges will conflict with remote support capability:

* 192.168.72.0/21
* 192.168.80.0/21

If you will ever need Vectra to assist remotely (outside of screen sharing sessions), care should be taken to number the management network interface (MGT) used on any appliance (physical, virtual, or cloud - Brains or Network Data Sources/Sensors) outside of the above ranges. If your management network interface (MGT) is numbered in either of these ranges, remote support access will not function. Remote support connectivity with Vectra all goes through the Brain (even to access other appliances in your deployment) so firewall rules for remote support functionality only need to allow connectivity from the Brain to Vectra's cloud (Sensors must still allow connectivity to the Brain per the below charts).

## Vectra Cloud Connectivity

* For this document, the portions of the Vectra AI Platform that reside in Vectra’s cloud are referred to as the Vectra cloud.
  * This does not refer to any specific service offering.
* Please check each category below to see if it is applicable to your deployment and if rules are required in your environment to enable the required connectivity.
  * For rule categories that have multiple region options, it is only necessary to put rules in place to allow connectivity to the region that your Vectra tenant is deployed in. This region should be visible in the URL used to access the Respond UX.
    * i.e. `[tenant_id].ew1.prod.vectra-svc.ai` is used for EU deployments (ew1).
* RUX for Network refers to a RUX deployment that has enabled network data sources (sensors).
  * This means you have a Brain somewhere in your premises (data center or public cloud) that is connected to the Vectra cloud for use with the Respond UX and paired with network Sensors (virtual or physical) to capture network traffic and distill a metadata stream for processing by the Brain appliance.
  * Please refer to the [Vectra Respond UX Deployment Guide](https://support.vectra.ai/s/article/KB-VS-1696) for more details.
* Please refer to the table below to see applicability of the various categories.
* The **For Brain or User’s Browser** column should be interpreted as follows:
  * **Brain** – Rules required for the Brain to the Vectra Cloud.
  * **User’s Browser** – Rules required for the user’s web browser to the Vectra cloud.

<table data-header-hidden data-full-width="true"><thead><tr><th width="318.47265625"></th><th width="281.6796875"></th><th width="259.9375"></th></tr></thead><tbody><tr><td><strong>Rule Category</strong></td><td><strong>Required For</strong></td><td><strong>For Brain or User’s Browser</strong></td></tr><tr><td><a href="#rux-for-network-gui-synchronization">RUX for Network GUI Synchronization</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#auth-gateways">Auth Gateways</a></td><td><p>RUX for Network Deployments</p><p>Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.</p></td><td>Brain</td></tr><tr><td><a href="#rux-metadata-forwarding">RUX Metadata Forwarding</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#rux-research-metadata-forwarding">RUX Research Metadata Forwarding</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#section-2">RUX Analyst/Admin Access</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#_Respond_UX_(RUX)_1">RUX Static Asset CDN</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#_Respond_UX_Customer">RUX Customer File Upload</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#vectra-cloud-egress-ips">Vectra Cloud Egress IPs</a></td><td>Vectra Cloud connecting to configured SaaS data source connectors</td><td>N/A</td></tr></tbody></table>

### RUX for Network GUI Synchronization

* Required for:
  * All RUX for Network deployments.
* This is used to synchronize configurations between the Brain appliance and your Vectra tenant.
* This communications channel is initiated from the Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **Websocket and HTTPS over TCP/443**

<table data-header-hidden data-full-width="false"><thead><tr><th width="365.3203125" align="center"></th><th width="100" align="center"></th><th width="100" align="center"></th><th width="144.20703125" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">main-cbi-tunnel-uw2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-ew1.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-ec2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-cc1.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-as2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### Auth Gateways

* Required for:
  * All Respond UX for Network Deployments.
  * Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.
    * Your Brain must be able to securely access the Vectra cloud over TCP/443 HTTPS connections to enable detection events from these products to be reported to your UI.
* In Respond UX for Network deployments, the Brain forwards network detections, entities, host sessions, and any selective PCAPs (Vectra Packet Capture) to your Vectra tenant via this connection.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.

<table data-header-hidden data-full-width="true"><thead><tr><th width="383.625" align="center"></th><th width="149.61328125" align="center"></th><th width="148.4609375" align="center"></th><th width="121.22265625" align="center"></th><th width="137.1484375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">authgateway.uw2.public.app.prod.vectra-svc.ai</td><td align="center">54.245.33.175<br>52.42.70.176<br>100.21.109.72<br>52.26.91.157</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.ew1.public.app.prod.vectra-svc.ai</td><td align="center">54.171.40.108<br>54.246.213.148<br>54.75.47.147</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.ec2.public.app.prod.vectra-svc.ai</td><td align="center"><p>16.62.18.237</p><p>16.62.142.98</p><p>51.96.54.201</p></td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.cc1.public.app.prod.vectra-svc.ai</td><td align="center">3.96.112.208<br>52.60.211.221<br>15.222.69.161</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.as2.public.app.prod.vectra-svc.ai</td><td align="center">13.54.11.66<br>13.55.79.24<br>13.55.106.102</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Metadata Forwarding

* Required for:
  * All Respond UX for Network Deployments.
* Network metadata is forwarded to AWS S3 buckets and processed to make it available for features such as Instant Investigation and Advanced Investigation in the Respond UX.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="514.98046875" align="center"></th><th width="100" align="center"></th><th width="119.75390625" align="center"></th><th width="146.4296875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-uswt2-371371611652.s3-accesspoint.us-west-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-euwt1-371371611652.s3-accesspoint.eu-west-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-eucl2-371371611652.s3-accesspoint.eu-central-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-cacl1-371371611652.s3-accesspoint.ca-central-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-apse2-371371611652.s3-accesspoint.ap-southeast-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Research Metadata Forwarding

* Optional but highly recommended for:
  * All Respond UX for Network Deployments
* Research metadata from precursor algorithms are used to improve model quality and reduce detection noise.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="490.4140625" align="center"></th><th width="100" align="center"></th><th width="120.79296875" align="center"></th><th width="135.91796875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">cbo-upload-network-precursors-uswt2-371371611652.s3-accesspoint.us-west-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-euwt1-371371611652.s3-accesspoint.eu-west-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-eucl2-371371611652.s3-accesspoint.eu-central-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-cacl1-371371611652.s3-accesspoint.ca-central-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-apse2-371371611652.s3-accesspoint.ap-southeast-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Analyst/Admin Access

* Required for:
  * All Respond UX deployments.
* Any analyst or admin that wishes to access the Respond UX will need to ensure that their browser can reach their Vectra tenant to login and access the UI.
* This communications channel is initiated from the user’s host.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="340.640625" align="center"></th><th align="center"></th><th align="center"></th><th width="139.19921875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">[tenant_id].uw2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].ew1.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].ec2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].cc1.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].as2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">User’s Browser</td></tr></tbody></table>

### RUX Static Asset CDN

* Required for:
  * All Respond UX deployments.
* The Respond UX has certain static assets (HTML, CSS, JS) that are required to serve the web application hosted by a CDN (Content Delivery Network).
* This communications channel is initiated from the user’s host.

<table data-header-hidden data-full-width="true"><thead><tr><th width="313.40234375" align="center"></th><th width="153.4609375" align="center"></th><th width="100" align="center"></th><th width="100" align="center"></th><th width="142.07421875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center"><p>dd6462tdmvp79.cloudfront.net</p><p>dpew7prsvwbf0.cloudfront.net</p></td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">All</td><td align="center">User’s Browser</td></tr></tbody></table>

### RUX Customer File Upload

* Required for:
  * All Respond UX deployments.
* This communications channel is used for:
  * Vectra Match deployments and will allow upload of rulesets.
  * PCAP download from the Vectra Cloud for Selective PCAP (Vectra Packet Capture)
  * Additional capabilities are planned for future releases.
    * It is recommended to put rules in place even if you don’t use Match or Selective PCAP.
* This communications channel is initiated from the user’s host.

<table data-full-width="true"><thead><tr><th width="395.8828125" align="center"></th><th width="151.8515625" align="center"></th><th width="93.1875" align="center"></th><th width="84.61328125" align="center"></th><th width="144.1015625" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">prd-main-customerfiles-580786928539-uswt2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">US</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-euwt1.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-eucl2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-cacl1.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-apse2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">User’s Browser</td></tr></tbody></table>

### Vectra Cloud Egress IPs

When the Vectra Cloud connects externally to retrieve logs from configured data sources, it does so from the IPs listed at <https://ips.devops.vectra-svc.ai/ips.json>. The specific IPs used will be limited to the IPs listed for the regions in use for your Vectra deployment. For example, if you are only deployed in eu-west-1, then only the IPs from the list associated with eu-west-1 will be used. See the following table for details.

<table><thead><tr><th width="315.4375">Region Code</th><th width="297.0234375">Region</th></tr></thead><tbody><tr><td>ap-southeast-2</td><td>Australia</td></tr><tr><td>ca-central-1</td><td>Canada</td></tr><tr><td>eu-central-2</td><td>Switzerland</td></tr><tr><td>eu-west-1</td><td>EU</td></tr><tr><td>us-west-2</td><td>US</td></tr></tbody></table>

In most situations, customers do NOT need to configure any specific firewall rules to allow Vectra to reach the endpoints required. If you see the IPs in the list accessing your data in your logs, this is not a cause for concern. It is due to the fact that your configured data source connector is connecting to the endpoint to retrieve the data necessary to provide the service.

In the case of CDR for Azure, if private access is required for the Azure storage accounts that Vectra reads your Azure logs from, please see [Configuring Private Access for Azure Storage Accounts](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#configuring-private-access-for-azure-storage-accounts) in the CDR for Azure deployment guide. Details are provided for how to configure the Storage accounts used to only accept connections from the IPs associated with the Vectra Cloud.

## Appliance Connectivity

The [Vectra Cloud connectivity](#vectra-cloud-connectivity) section above primarily deals with connectivity required to deliver the Respond UX and detections from Vectra SaaS offerings to both RUX and QUX deployments, the content in this section also applies to any deployment using Vectra appliances (Brains, Sensors, and Stream) for RUX or QUX deployments.

### Vectra Cloud Appliance Connectivity

All communications with the Vectra Cloud occur over a TLS encrypted channel. Appliance devices (physical, virtual, cloud) authenticate using keys. Unique public/private keys are generated when a device is provisioned by Vectra. The corresponding public key is copied to the Vectra Cloud. Every device connecting to the Vectra Cloud authenticates using its own private key.

The Vectra Cloud houses several services:

* update2.vectranetworks.com
  * Used for delivering updates to the Vectra software.
  * [Offline updates](/operations/readme-1/offline-updates-v89) are also supported.
* api.vectranetworks.com
  * Used for lightweight health monitoring of the Vectra platform and for delivering additional context certain Detections may need.
  * Queries to external information sources to provide context are proxied through this connection.
  * If required, customers can block the platform from reporting health monitoring by blocking outbound connections on their firewall to api.vectranetworks.com.
* rp.vectranetworks.com
  * Used only for Brains deployed in IaaS clouds. Used for authentication and verification (integrity check of the file system).
* metadata.vectra.ai
  * Metadata sharing improves threat detection by contributing anonymized metadata sourced from Brain deployed in your organization. This is optional in QUX deployments.
* rs.vectranetworks.com
  * This enables remote support from authorized Vectra employees.
* SaaS product offerings such as Recall

#### Proxy Support

Vectra Cloud connectivity to update2.vectranetworks.com and api.vectranetworks.com supports connecting through a customer proxy. If a proxy connection is required for your Brain appliance to reach these endpoints, edit the proxy settings in *Configuration → Data Sources → Network → Brain Setup → Proxy & Status*.

* Note that [Remote Support](/configuration/access/vectra-remote-support) does not support proxy configuration by default. If this is the only option, please contact Vectra support to configure remote support to manually to use a proxy.

#### Lightweight Health Monitoring

The lightweight health monitoring includes the following statistics, only aggregate statistics are collected, no details are collected.

* System Health Metrics
  * Installed packages, running processes, system interface information, system usage, database usage, system error stats
* Environment Metrics
  * Host counts, traffic counts, Brain configuration, remote support status, notification status, metadata status
* Detection Metrics
  * Detection counts, PCAP stats, Triage stats

#### Metadata Sharing

[Why is Metadata Sharing Important](/reference/why-is-metadata-sharing-important)

* Full details are available at this link. There are optional additional levels of sharing also described.

Metadata Sharing Improves Threat Detection

* By contributing anonymized metadata sourced from the X-series platform deployed in your organization, you are contributing directly to the efficacy and accuracy of the Vectra software and the security of your network.
* Access to Detection metadata improves Vectra’s threat detection algorithms, enabling the Vectra software you use to be more effective in a constantly evolving threat landscape.
* Data is collected daily and includes:
  * Anonymized information about Detections that are triggered in your network.
  * Anonymized information about algorithms in the research and development phase (and not yet visible in the UI) that are triggered in your network.
  * Anonymized attribution of Detections to Hosts.
  * Anonymized information related to host identification efficacy.
* Vectra Secures and Limits Access to Metadata
  * Any metadata you contribute is anonymized by removing personal and network-specific information before it is sent to metadata.vectranetworks.com via an encrypted connection.
  * Vectra treats this metadata as highly confidential and only allows authorized research personnel to access the metadata.
  * Any metadata collected is securely deleted after a six-month period.
* Contact Vectra support if non-anonymized Full Metadata Sharing is desired
  * Algorithm development using non-anonymized metadata helps to ensure that new models function as efficiently as possible in your environment.

### Required Connectivity For Appliances

<table data-header-hidden data-full-width="true"><thead><tr><th width="131.375" align="center"></th><th width="253.46875" align="center"></th><th width="177.15234375" align="center"></th><th width="288.40234375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td><td align="center"><strong>Description</strong></td></tr><tr><td align="center">Administrator workstations</td><td align="center"><p>Brain</p><p>Sensors</p></td><td align="center">TCP/22 (SSH)</td><td align="center">Command-line management of the Brain and Sensor appliances.</td></tr><tr><td align="center">Administrator workstations</td><td align="center">Brain</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Web management of brain appliances.</td></tr><tr><td align="center">Brain</td><td align="center"><p>update2<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.156.238)</p></td><td align="center">TCP/443<br>(HTTPS)</td><td align="center"><p>Automatic updates.</p><p>Pairing keys for physical sensors.</p><p>See note above regarding SSL keys.</p></td></tr><tr><td align="center">Brain</td><td align="center"><p>api<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.5.9)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Health monitoring, algorithm support, reverse lookups for external IPs, Vectra Threat Intelligence, additional detection content. See note above regarding SSL keys.</td></tr><tr><td align="center">Brain (Cloud)</td><td align="center"><p>rp<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.156.238)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Used only for Brains deployed in IaaS clouds. Used for authentication and verification (integrity check of the file system)</td></tr><tr><td align="center">Brain</td><td align="center">DNS servers (as configured)</td><td align="center">TCP/53, UDP/53</td><td align="center">Both TCP and UDP are required for normal operation. See note above regarding DNS resolution.</td></tr><tr><td align="center">Brain</td><td align="center"><p>NTP servers (as configured)</p><p>Default is ntp.ubuntu.com</p></td><td align="center">UDP/123</td><td align="center">Time synchronization.</td></tr><tr><td align="center">Brain</td><td align="center">SMTP servers (as configured)</td><td align="center">TCP (as configured)</td><td align="center">Email alerting.</td></tr><tr><td align="center">Brain</td><td align="center">SMTP (OAuth)</td><td align="center">TCP/443<br>TCP/587</td><td align="center">Please see SMTP (OAuth) for Microsoft chart below.</td></tr><tr><td align="center">Brain</td><td align="center">Sensors, Stream</td><td align="center">TCP/22 (SSH)</td><td align="center">Remote management and troubleshooting.</td></tr><tr><td align="center">Sensors, Stream</td><td align="center">Brain</td><td align="center">TCP/22 (SSH), TCP/443 (HTTPS)</td><td align="center">Pairing, metadata transfer, and ongoing communication.</td></tr><tr><td align="center">Stream</td><td align="center">Data lake (as configured)</td><td align="center">TCP (as configured)</td><td align="center">Metadata stream to a data lake</td></tr></tbody></table>

### Additional (Feature Dependent) Connectivity

<table data-header-hidden data-full-width="true"><thead><tr><th width="132.6796875" align="center"></th><th width="395.2890625" align="center"></th><th width="167.9609375" align="center"></th><th width="339.06640625" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td><td align="center"><strong>Description</strong></td></tr><tr><td align="center">Brain</td><td align="center">content.user-telemetry.vectra.ai<br>data.user-telemetry.vectra.ai</td><td align="center">TCP/443<br>(HTTPS)</td><td align="center">Required for In-App support functionality.<br>See <a href="https://support.vectra.ai/s/article/KB-VS-1606">In-App Support KB</a> for more details.</td></tr><tr><td align="center">Administrator workstations</td><td align="center">Recall Kibana server</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Recall IP addresses are provided during implementation and may be requested at any time from Vectra Support.</td></tr><tr><td align="center">Brain</td><td align="center"><p>rs.vectranetworks.com</p><p>(74.201.86.229)</p></td><td align="center">TCP/443 or UDP/9970</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1045">Remote Support</a> access for remote troubleshooting. See note above regarding SSL inspection and other note about potential IP range conflicts with the MGT interface.</td></tr><tr><td align="center">Brain</td><td align="center"><p>metadata.vectra.ai</p><p>(100.20.236.31, 44.229.57.246, 44.228.37.60, 44.228.101.87)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Anonymized metadata sharing to contribute to future algorithm development.</td></tr><tr><td align="center">Brain</td><td align="center">Recall collector</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Recall IP addresses are provided during implementation and may be requested at any time from Vectra Support.</td></tr><tr><td align="center">Brain</td><td align="center">Syslog (as configured)</td><td align="center">TCP or UDP (as configured)</td><td align="center">CEF or standard Syslog format.</td></tr><tr><td align="center">Brain</td><td align="center">Kafka (as configured)</td><td align="center">TCP (as configured)</td><td align="center">CEF or standard Syslog format.</td></tr><tr><td align="center">Brain</td><td align="center"><p>Carbon Black Response</p><p>(as configured)</p></td><td align="center">TCP/443 (as configured)</td><td align="center">Carbon Black integration (requires API key).</td></tr><tr><td align="center">Brain</td><td align="center">api.crowdstrike.com</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Crowdstrike integration (Client ID and Client Secret).</td></tr><tr><td align="center">Brain</td><td align="center">vCenter (as configured)</td><td align="center">TCP (as configured)</td><td align="center">vCenter integration enables vSensor physical host view, augmented host identification, and vCenter alerts.</td></tr><tr><td align="center">Brain</td><td align="center">LDAP (as configured)</td><td align="center">TCP/389 STARTTLS/389</td><td align="center">LDAP authentication.</td></tr><tr><td align="center">Brain</td><td align="center">Radius (as configured)</td><td align="center">UDP/1812</td><td align="center">Radius (PAP) authentication.</td></tr><tr><td align="center">Brain</td><td align="center">TACACS (as configured)</td><td align="center">TCP/49</td><td align="center">TACACS (PAP or CHAP) authentication.</td></tr><tr><td align="center">Brain</td><td align="center">Backup server (as configured)</td><td align="center">TCP/22 (SSH)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1121">Automated backup (SCP or SFTP)</a>.</td></tr><tr><td align="center">Brain</td><td align="center">Brain</td><td align="center">TCP/22 (SSH), TCP/443 (HTTPS)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1121">Automated backup (brain-to-brain)</a>. Connectivity is bidirectional.</td></tr><tr><td align="center">Sensors, Stream</td><td align="center">update2.vectranetworks.com (54.200.156.238)</td><td align="center">TCP/443 (HTTPS)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1024">Required for automatic pairing</a>. Optional for manual (offline) pairing.</td></tr><tr><td align="center">SIEM/CLM log management</td><td align="center">Brain</td><td align="center">TCP or UDP (as configured)</td><td align="center">Log forwarding of DHCP/AD security events to augment host identification.</td></tr><tr><td align="center">Brain</td><td align="center"><p>login.windows.net</p><p>api.securitycenter.windows.com</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Required for <a href="https://support.vectra.ai/s/article/KB-VS-1236">ATP lockdown</a></td></tr><tr><td align="center">Brain</td><td align="center">EMEA customers (only)<br><br>authgateway.ew1.public.app.prod.vectra-svc.ai<br>(54.171.40.108 , 54.246.213.148 , 54.75.47.147 )<br><br>AMS/APJ customers (only)<br><br>authgateway.uw2.public.app.prod.vectra-svc.ai<br>(54.245.33.175, 52.42.70.176, 100.21.109.72 , 52.26.91.157)</td><td align="center">TCP/443<br>(HTTPS)</td><td align="center">Required for Vectra MDR Service for QUX Deployments. These endpoints are also required for RUX deployments that have network data sources (Sensors). These are already discussed in the <a href="#auth-gateways">Auth Gateways</a> section of this doc for RUX. Essentially, if your deployment has a Brain, it MUST be able to reach Vectra over these endpoints for Vectra MDR service.</td></tr><tr><td align="center">Sensor</td><td align="center">S3 and SQS AWS Regional Endpoints. Only required for ZIA enabled Sensor.</td><td align="center">TCP/443</td><td align="center">Required for ZIA SASE/SSE integration. See <a href="https://support.vectra.ai/s/article/KB-VS-1006">KB</a> for details.</td></tr></tbody></table>

### SMTP (OAuth) For Microsoft

**Quadrant UX Only**: *Configuration → RESPONSE → Notifications → SMTP*

Respond UX deployments do not require this as email notifications are sent from Vectra's cloud.

<table data-header-hidden data-full-width="true"><thead><tr><th width="282.41015625" align="center"></th><th width="223.69140625" align="center"></th><th width="145.71484375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Cloud Type</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td></tr><tr><td align="center">Public (office365<strong>.</strong>com)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>com<br>smtp<strong>.</strong>office365<strong>.</strong>com</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">US Government (office365<strong>.</strong>us)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>us<br>smtp<strong>.</strong>office365<strong>.</strong>us</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">German (office365<strong>.</strong>de)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>de<br>smtp<strong>.</strong>office365<strong>.</strong>de</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">China (office365<strong>.</strong>cn)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>cn<br>smtp<strong>.</strong>office365<strong>.</strong>cn</td><td align="center">TCP/443<br>TCP/587</td></tr></tbody></table>


# Brain deployment

Overview of the QUX deployment process, deployment steps along with requirements and documentation links, and how to do your initial login.

## Brain Deployment Process Overview

{% stepper %}
{% step %}

### A trial or purchase decision is made for a QUX deployment

Please work with your Vectra account team in either case.
{% endstep %}

{% step %}

### [Deploy a Brain appliance](#brain-deployment-documentation-links)

* Deployment can be done by the customer, partner, or with the assistance of Vectra.
  {% endstep %}

{% step %}

### [Login and change the admin password](#login-and-change-the-admin-password-1)

Once you can login to your Brain appliance QUX UI, changing the default **admin** administrator login password is recommended.
{% endstep %}

{% step %}

### Setup SAML SSO

Setup SSO if desired for admin and analyst access (links to guides below):

* [Setup SAML SSO with and IdP (Quadrant UX)](/configuration/access/saml-sso-qux/any-idp-saml-qux)
* [Setup SAML SSO with Azure AD (Quadrant UX)](/configuration/access/saml-sso-qux/entra-id-azure-ad-saml-qux)
* [Setup SAML SSO with Okta (Quadrant UX)](/configuration/access/saml-sso-qux/okta-saml-qux)
* [Setup SAML SSO with Ping Identity (Quadrant UX)](/configuration/access/saml-sso-qux/ping-identity-saml-qux)
* [Setup SAML SSO with ADFS (Quadrant UX)](/configuration/access/saml-sso-qux/adfs-saml-qux)

Additional external authentication options such as [LDAP](/configuration/access/external-authentication-qux/ldap-qux), [RADIUS](/configuration/access/external-authentication-qux/radius-qux), and [TACACS+](/configuration/access/external-authentication-qux/tacacs-qux) are available in *Configuration → ACCESS → Authentication.*
{% endstep %}

{% step %}

### [Configure initial settings](/deployment/getting-started/quadrant-ux-deployment/initial-configuration)

Guidance for intial QUX configuration settings in the next page of this guide.
{% endstep %}

{% step %}

### Cloud data sources can be added at any time

Cloud (non-network data sources) such as IDR for Azure AD (Entra ID), CDR for M365, and CDR for AWS can be added at any time. See [configuring data sources](/deployment/getting-started/quadrant-ux-deployment/configuring-data-sources) for details.
{% endstep %}

{% step %}

### Add network data sources (Sensors)

Network Sensors allow you to capture network traffic for analysis by your Vectra deployment. See [configuring data sources](/deployment/getting-started/quadrant-ux-deployment/configuring-data-sources) for details.

* Sensors are deployed and paired with your Vectra Brain.
* Traffic capture is initiated.
* Traffic is validated to ensure the observed traffic meets quality standards for algorithm processing.
  {% endstep %}

{% step %}

### [Perform recommended next steps](/deployment/getting-started/quadrant-ux-deployment/recommended-next-steps)

See this page of the guide for best practices, configuring backup for your Brain appliance, and other recommended next steps.
{% endstep %}
{% endstepper %}

## Login and Change the “admin” Password

Once an IP has been configured for the MGT1 interface of your Brain, you can access it using a modern browser such as Edge, Chrome, or Safari (see [Vectra UI Supported Browsers](/reference/vectra-ui-supported-browsers) for more detail) at <https://configured\\_IP> or the hostname (if configured in your DNS). The GUI can also be accessed via MGT2 (on physical appliances) at <https://169.254.0.10>. The default username is **admin** and the default password is **changethispassword** .

Please note that by default, Vectra uses a self-signed certificate to secure the user interface. As a result, the certificate causes SSL warnings in most web browsers. Instructions for how to replace this with a customer-provided signed certificate can be found in the following Vectra support portal article:

* [SSL Certificate Installation](/configuration/qux-specific/ssl-certificate-installation)

After logging in to the GUI, it is recommended to immediately change the **admin** password.

* Navigate to **My Profile** on the left-hand side of the screen
* Click on **Change Password** in the username/password area, fill in and save the form
* Password requirements - must be at least 8 characters long and contain at least
  * 1 digit (0-9), 1 upper case letter (A-Z), 1 lower case letter (a-z)
  * One symbol from: (\~!@#$%^&\*\_-+=\`| \ ( ){ }\[ ]:;”’<>,.?/)

## Brain Deployment / Documentation Links

Deploy your Brain appliance using one of the linked guides below. After deployment, come back here and continue.

* For physical Brain appliances
  * You will need CLI (Command Line Interface) access to the appliance.
  * The initial configuration at the CLI is covered in the Quick Start Guide for your appliance.
  * Please refer to that guide to configure an IP address, network mask, and default gateway.
    * If required, a proxy can also be configured at the CLI but can also be done later in the GUI.
  * Quick start guides for physical appliances that can support Brain or Mixed mode use are listed here:
    * [X-Series guides](/deployment/ndr-physical-appliances/x-series) - These appliances support Brain or Mixed mode deployment.
    * [B-Series guides](/deployment/ndr-physical-appliances/b-series) - These appliances only support Brain mode deployment.
    * The quick start physical appliance guides are meant just for getting the appliance installed and available on your network.
* For virtual Brains deployed in traditional hypervisor environments (VMware, Nutanix, etc) or in IaaS clouds (AWS, Azure, GCP, etc)
  * Please the Brain guide for your platform in [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).
  * Please see the appropriate deployment guide below for your supported IaaS cloud:
    * [AWS Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-brain)
    * [Azure Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/azure-brain)

You may have already configured DNS following the QuickStart for your physical appliance or the deployment guide for your virtual Brain. If you did not configure DNS as part of your initial Brain deployment, this guide will cover configuration of DNS later in the [Data Sources > Network > Brain Setup](/deployment/getting-started/quadrant-ux-deployment/initial-configuration#data-sources-greater-than-network-greater-than-brain-setup) section. It is recommended have your Brain registered in your DNS to make failover scenarios easier to deal with.


# Initial configuration

Configure QUX settings after initial deployment, with guidance for data sources and deeper configuration tasks.

## Introduction

This section of the QUX deployment guide provides guidance for configuring settings in the **Configuration** menu in the Vectra UI after initial deployment. It is arranged by areas shown in your UI and has guidance and links for deeper guidance when required.

## Configuration → COVERAGE

Contains configuration options related to specific data sources, threat feeds, and Vectra Match.

***Custom Models***

Custom Models enables you to create your own detections within the Vectra platform. They are built upon Vectra Recall saved searches. You must have a Vectra Recall subscription to use custom models. For more details please see:

* [Recall custom models - how to create detections (QUX)](/operations/analyst-guidance/recall-custom-models-how-to-create-detections-qux)
* [Recall deployment guide](/deployment/recall-qux-only)

***Data Sources***

Add coverage for new or existing network, cloud, and identity data sources to your Vectra deployment. For non-network data sources, each data source selected will present a welcome page with links to documentation.

***Threat Feeds***

Allows configuration of 3rd party threat intelligence feeds in STIX format. For details, please see linked documentation at: [Threat Intel Integration Setup](/configuration/coverage/threat-feeds/external-threat-intel-integration)

[Vectra Threat Intelligence](/configuration/coverage/threat-feeds/vectra-threat-intelligence) is a set of threat intelligence feeds that is managed and curated by Vectra. It is available as an included part of your Vectra NDR (Detect for Network) license. See the linked documentation for details.

***Vectra Match***

Vectra Match utilizes the open source [Suricata](https://suricata.io/) IDS engine. Vectra’s Sensors (network data sources) are extremely high performance and adept at producing the proprietary metadata required to supply the AI-based behavioral models utilized by Vectra NDR. Match enables these same Sensors to also run a Suricata engine that is fed by the same capture buffers that feed the existing data processing pipeline.

For details, please see the [Vectra Match Deployment Guide](/deployment/match/deployment)

### Data Sources → Network → Brain Setup

This area contains settings that are specific to your Vectra Brain appliance. The full path for items in this section is *Configuration → COVERAGE → Data Sources → Network → Brain Setup.*

***Brain***

This area of the GUI displays various Brain specific settings and information, and also has **Restart** and **Shut Down** links.

* DNS Name
  * FQDN (Fully Qualified Domain Name) that can be used to pair Sensors and/or Stream to this Brain.
  * To use this value for pairing, change the pairing setting under *Configuration → COVERAGE* → *Data Sources → Network → Sensors → Sensor Configuration → Sensor Pairing and Registration* to **DNS Name**.
    * Additional guidance for pairing via IP or DNS is covered [later](#data-sources-network-sensors) in this document.
  * In general, it is recommended to configure your DNS with a proper hostname for the Brain.
* Alias
  * The label for this Brain within various areas of the Vectra AI platform.
* For linking in alerts/notifications (except AWS SecurityHub):
  * Choose either **DNS Name** or **Management IP Address**.
  * This will determine the format of links in alerts/notifications.

***CLI Access Controls***

This settings area becomes visible and replaces the **CLI Password (Brain)** setting if you have the feature flag for the new [SSH Login to CLI](/deployment/appliance-operations/ssh-login-process-for-cli) feature enabled in your deployment. This feature is currently in private preview and is planned to become generally available in a future release.

This area controls the password for the `vectra` user and allows you to disable this user entirely if desired. You can also control the SSH token (OTP) timeout value that non `vectra` users are subject to when they log in to the CLI of Vectra appliances. As linked article, users must have the **SSH Login to CLI** permission mapped to their assigned role to be able to login to any appliance CLI.

***CLI Password (Brain)***

This setting is replaced by **CLI Access Controls** when the feature flag for SSH Login to CLI is enabled in your Brain. This feature is currently in private preview and is planned to become generally available in a future release.

This setting allows you to set the password for the `vectra` user used to access the CLI of the Brain via SSH.

* Please note that accessing the CLI of a Brain deployed in an IaaS cloud requires authentication of SSH using the private key corresponding to the public key that was provided during deployment.
* Physical appliances and virtual Brains can authenticate using password.

***DNS Entries***

These DNS settings apply to the Brain only. Sensor DNS is set individually at the CLI or via a configuration string when deploying vSensors using the command line from the Brain.

* If you have not already configured DNS for the Brain at the CLI, please do so in this section of the UI.
* It is also highly recommended to enable Reverse DNS Lookup to improve host identification and context.
  * This is done by checking the checkbox in this area.

***IP Address Classification***

For proper algorithm operation and recognition of traffic directionality within Stream or Investigate metadata it is mandatory to accurately identify internal vs external IP space. By default, all RFC-1918 IP space is considered **internal**.

Additionally, Vectra NDR AI detection models do not analyze connections that originate from external IP space. Return traffic for connections that originated internally to external entities is analyzed. Metadata is still produced for Stream and Investigate functionality, and Match still processes externally originated connections through the underlying Suricata engine.

Please see the below for details on how each of the IP address classification settings will affect the system.

* RFC-1918 (Address Allocation for Private Internets) IP space
  * This is just a reminder about the networks that are reserved for internal use in RFC1918
  * <https://tools.ietf.org/html/rfc1918>
    * 10.0.0.0 - 10.255.255.255 (10/8 prefix)
    * 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
    * 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
    * fd00::/8 (IPv6)
* **Internal IP Addresses (CIDR)**
  * IP addresses or CIDR blocks entered here will be considered internal to your network.
  * Everything else will be considered external.
* **Exclude a Subset of Internal IP Addresses (CIDR)**
  * Use this area if you have a subset of internal IP addresses listed above that you want to be considered as external to your network.
  * For example, if you were going to simulate Command and Control behavior from an internal lab, you should configure the lab IP space as external (by adding it to this section). This allows Detect models properly identify the behavior.
* **Drop IP Addresses (CIDR)**
  * IP addresses or CIDR blocks entered here will be ignored.
  * Any traffic to or from these addresses will not be analyzed by NDR AI models by your system.
  * Ignoring traffic by VLAN is supported at the CLI using the `set capture-vlan` command.
* **Drop and Exclude Subnet Scenario Examples**
  * 10.10.0.0/16 set as Exclude, 10.10.50.0/24 and 10.10.70.0/23 set as Internal, Exclude setting will take precedence and both smaller subnets will be considered as Exclude.
  * Similarly, if 10.10.0.0/16 was set as Drop and the others external, the result would be Drop for all.
* **CLI Options for Setting Internal, Exclude, Drop**
  * After [logging into the CLI of your Brain](/deployment/appliance-operations/console-access-on-appliances), include, exclude, and drop networks/vlans can be configured by the below CLI commands.
  * The commands also have help that can be shown with the `--help` argument.

```
set capture-network [ networks ] < ( internal | external | drop ) >
set capture-vlan < vlan > drop
show capture-networks
show capture-vlans
```

* **Internal VPN IP Addresses (CIDR)**
  * Enter any IP ranges allocated to your VPN servers for remote end-user connections.
  * This will improve identification and detection model coverage for hosts connecting in via VPN by altering some characteristics of underlying models.
  * For more details on [optimizing your system for use with VPN clients](/configuration/coverage/remote-users/optimizing-vectra-for-use-with-vpn-clients), please follow the link.
* **Static IP Addresses (CIDR)**
  * In many customer environments, Vectra’s automated Host Identification (Host ID) is all that is required for customers to have all the pertinent hosts in their environment named and tracked. Generic hosts (IP-x.x.x.x) will inevitably be observed when a host first comes into the environment, but not enough artifacts have been observed to create a stable named host object or attribute its traffic to a previously created host. This can commonly happen when a user plugs in a laptop for the day, but the host is not recognized immediately. Vectra manages this on its own and will attribute traffic for this generic host to the named real host object once it is recognized.
  * Many customers also have statically assigned hosts and may not have hostnames in customer DNS. Additionally, Vectra may not directly observe enough artifacts of other types to name the host. If a stable host object never gets created, learning for several models cannot be anchored to generic hosts. This means that some Detections cannot fire and features such as the Host Role cannot function on these generic hosts.
  * Enter IP addresses or CIDR blocks representing the statically assigned hosts in your environment in this area.
  * Hosts on these IPs or ranges will show as **STATIC-x.x.x.x** in the Vectra UI and will no longer be generic hosts.
  * These hosts will have full support for learning and all Detections and features.
  * Statically defined hosts will not change name based on observed artifacts - they will remain static until they are no longer configured as such.
  * You are free to rename statically assigned hosts as you wish.

***NTP Entries***

Vectra provides defaults but please set your preferred time synchronization sources (up to 5) here.

***PCAP Generation***

PCAPs provide great value to analysts in a number of scenarios. PCAPs are assembled from the Sensor’s rolling capture buffer upon request from the Brain during the publishing of Detection alerts. In some circumstances, customers may not want to have PCAPs generated at all, or from certain Sensors that may be deployed in areas with stricter privacy controls that don’t allow for PCAP.

* Edit in this area to turn off PCAP generation entirely.
* To turn off PCAP generation on an individual Sensor go to *Configuration → Data Sources → Network → Sensors → Network Sensors*, select the Sensor you wish to edit, click the edit pencil, and then deselect the **Capture PCAPs for this Sensor** checkbox and **Save** your setting.

***Proxy & Status***

Edit this area to add or change proxy settings if required for your environment to be able to connect to endpoints needed in the [firewall requirements](/deployment/getting-started/respond-ux-deployment-guide/firewall-requirements). Also shows the status of connections.

* Please note that if you see green checkmarks for both the Statistics Destination and the Updater Destination, even if a warning stating **No proxy configured** is displayed, you do not need to setup a proxy for your platform.
* Proxy settings can also be viewed and configured at the CLI using the `show proxy` and `set proxy` commands at the CLI of your Brain appliance.
* For details on how Vectra works with proxies in your environment from a traffic capture/analysis standpoint as it relates to detections, please see [proxy handling in Vectra](/configuration/setup/proxies).
  * You can manage the northside proxy list under *Configuration → SETUP → Proxies.*

***Version***

Information about the version of your Vectra platform will be displayed in this area. Editing the settings in this area allows you to set a preferred update window for automatic updates from Vectra. Automatic updates require a connection to updates2.vectranetworks.com. This area will have additional functionality if you have been enabled for offline updates. Please note the following for air gap scenarios:

* Offline updates must be enabled for your deployment by contacting your Vectra account team or Vectra Support.
* Once enabled for offline updates a **Manually update** link will appear in this area.
* For additional information about performing manual (offline) updates, please see [offline updates](/operations/readme-1/offline-updates-v89).

### Data Sources → Network → Sensors

The full path for items in this area is *Configuration → COVERAGE → Data Sources → Network → Sensors.* In this area you can pair and manage network sensors, configure a number of options related to Sensor pairing and registration, and change the password for paired devices (Sensors or Stream).

***Network Sensors***

Sensor management and pairing is accomplished in this area. For details on pairing, please see [pairing appliances](/deployment/appliance-operations/pairing-appliances). Below is some detail that is also covered in more detail in the linked guide for pairing appliances.

***Sensor Configuration → Sensor Pairing and Registration***

Editing this area will allow you to alter the default way a Sensor will attempt to pair with a Vectra Brain and allow you to enable or disable Virtual Sensor Automatic Pairing. Additionally, this area provides a link to generate a new Sensor Registration Token

* **Pair using the Detect Brain**
  * If you have a DNS name configured in Configuration → COVERAGE → *Data Sources → Network → Brain Setup → Brain*, then the **Pair using the Detect brain** area will provide a choice between the configured DNS name and the Management IP (MGT1).
  * If you do not have a DNS name configured, there will only be one option present using the configured IP.
    * It may take a few minutes after adding a DNS name in your Brain setup for the choice to appear in this area.
  * Pairing via the Brain DNS Name makes Brain replacement or IP Address change events easier to manage.
  * This setting only affects the default pairing mode for Sensors used in future pairing operations.
    * Any previously paired devices will remain paired regardless of how they were paired.
    * Regardless of setting, the `set brain` command available at the CLI of the Sensor will allow you to attempt pairing via hostname or IP.
  * Should you choose to change the pairing method for previously paired devices, you will need to unpair the previously paired devices and re-pair them.
* **Virtual Sensor Automatic Pairing**
  * This setting allows you to choose if you want to automatically pair (auto pairing) with Sensors that have a valid Sensor Registration Token (SRT) configured.
    * Even though the setting name implies that this will only impact virtual Sensors, any Sensor, including physical appliances can auto pair if a valid SRT is configured when pairing is attempted.
  * It is recommended to allow auto pairing during initial setup or during large Sensor rollouts.
  * When you are done deploying vSensors, you may turn this off to enhance security posture.
* **Sensor Registration Token**
  * This is used to validate devices attempting to register to this Brain and resets after 24 hours.
  * It is required in the Registration Token field in the Sensor deployment template for cloud Sensors.
  * While the Sensor Registration Token (SRT) is required for cloud Sensor deployment, it is optional for physical Sensors and virtual Sensors.
  * Use of the SRT will allow you to pair a Sensor with any Brain in your organization. This can be useful for disaster recovery scenarios where a device may have been paired to another Brain previously.
  * After a Sensor registers with this Brain, it will appear in the Sensor list in *Configuration → COVERAGE → Data Sources → Network → Sensors* where its pairing can be managed.
  * Stream devices will show paring status in *Configuration → Setup → Stream → Pairing Status.*

***Sensor Configuration → CLI Password (Sensors)***

In this area you can change the password for all paired Sensor or Stream appliances to easily keep passwords in sync.

* If you require separate passwords for each Sensor or Stream appliance, the password for the `vectra` user may be changed individually using the `set password` command at the CLI of your Sensor.
* Please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) for more details.

### Data Sources → Network → Network Identities

The full path for this is *Configuration → COVERAGE → Data Sources* → Network → Network Identities. In this area you can configure Windows Event Log Ingestion (WELI). WELI is an option available for Vectra NDR (Detect for Network) that helps with coverage by ingesting specific Kerberos messages in Windows event logs. Account and Host detections can fire as a result of this integration without having to have observed the actual network traffic associated with the Host or Account. Please see linked documentation at: [Windows Event Log Ingestion (WELI)](/configuration/coverage/network-identities-weli/windows-event-log-ingestion-weli).

## Configuration → SETUP

This area contains configuration settings that typically need to be configured one time during initial deployment or when new integration points are added to your environment and you want to configure Vectra to work with them.

***Account Association***

When using CDR for M365 & IDR for Azure AD, this area will allow you to manually map network realms to cloud domains. We recommend using automatic mapping by linking your Active Directory instance to your Vectra Brain, as this will link more robustly and with a greater success rate than manual mapping.

***EDR Integrations***

Configuring EDR integrations is considered a best practice if you have a supported EDR. It will enable Host Lockdown and provide added context to analysts for hosts running the EDR along with links to the EDR .

Please see linked documentation for these EDR integrations for details:

* [Microsoft Defender ATP (Endpoint)](/configuration/setup/edr-integrations/microsoft-defender-for-endpoint)
* [Carbon Black Response](/configuration/setup/edr-integrations/carbon-black-response)
* [Carbon Black Cloud](/configuration/setup/edr-integrations/carbon-black-cloud)
* [FireEye Endpoint Security (HX)](/configuration/setup/edr-integrations/trellix-fireeye-endpoint-security-hx)
* [SentinelOne](/configuration/setup/edr-integrations/sentinelone)
* [Cybereason](/configuration/setup/edr-integrations/cybereason)
* [Crowdstrike](/configuration/setup/edr-integrations/crowdstrike)

***Licensing***

See license status and perform license activation operations when required in this area.

***Metadata***

This setting allows you to configure behavior for connection state logging. This impacts the detail level of the **conn\_state** field shown in Advanced Investigation / Stream metadata. You can also control the volume of DNS metadata generated by logging or not logging DNS metadata only when a reply is observed in response to a request.

***Proxies***

Editing the configuration in this area allows you to manage automatically identified northside proxies in your environment. Identified southside proxies are not configurable but the list is viewable at the CLI of your Brain appliance. For details please see linked documentation at: [Proxy handling in Vectra](/configuration/setup/proxies)

***Recall***

This settings area allows you to see the state of a Vectra Recall license, turn on or off forwarding to Recall, recall collector and Kibana endpoints, and the health status of Recall.

***Stream***

Vectra Stream delivers security-enriched metadata to a data lake or SIEM of the customer’s choice. If licensed for Stream, you can configure Stream settings in this area. For details please see linked documentation at: [Stream Deployment Guide](/deployment/stream/deployment)

### Configuration → SETUP → External Connectors

External connectors add context enrichment to the Vectra AI Platform. For example, adding Active Directory as an external connector will:

* Add host and account details retrieved from Active Directory to your host and account details pages.
* Enable Active Directory Account Lockdown as a response option.
* Enable Vectra to automatically map cloud domains to network realms so that Vectra can associate cloud and network accounts.

***Active Directory***

Linked documentation available at: [Configuring Active Directory(AD) integration with Vectra NDR](/configuration/setup/external-connectors/active-directory)

***AWS***

This integration enables your Vectra deployment to add relevant context (host ID, OS, instance ID, tags, etc) about Amazon EC2 hosts when observed by Vectra. For configuration details please see either:

* [AWS Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-brain)
* [AWS vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-vsensor)
* [AWS HostID integration](/configuration/setup/external-connectors/aws-hostid-integration)

***Azure***

This integration enables your Vectra deployment to add relevant context (host ID, resource group, admin username, etc) about Azure VMs when observed by Vectra. For configuration details please see either:

* [Azure Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/azure-brain)
* [Azure vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/azure-vsensor)
* [Azure HostID integration](/configuration/setup/external-connectors/azure-hostid-integration)

***Google Cloud***

This integration enables your Vectra deployment to add relevant context (host ID, project, link to vm, etc) about GCP VMs when observed by Vectra. For configuration details please see either:

* [GCP Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/gcp-brain)
* [GCP vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/gcp-vsensor)
* [GCP HostID integration](/configuration/setup/external-connectors/gcp-hostid-integration)

***Reverse DNS Lookup***

Configuring DNS servers for your Brain appliance is required and enabling reverse DNS lookup is a best practice. Reverse DNS lookup is especially helpful for HostID naming processes. rDNS lookup respects TTL and is generally not expected to overload configured DNS servers.

***SIEM***

Configuring here enables your Vectra Brain appliance to listen for events forwarded from SIEMs or other systems that can send DHCP log data in Infoblox and other ISC standard syslog formats. This is useful to help feed Vectra HostID (automated host naming). For configuration details, please see linked documentation at: [Event Forwarding Reference Guide](/configuration/setup/external-connectors/siem-vectra-brain-ingesting-logs)

***vCenter***

Configuring vCenter integration allows your Vectra deployment to query VMware vCenter and enable the \_Network Stats → Virtual Infrastructure\_view. It also feeds Vectra HostID with artifacts that help automated identification of hosts in your VMware environment. For details, please linked documentation at:

* [VMware Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/vmware-brain)
* [VMware vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/vmware-vsensor)
* [vCenter integration](/configuration/setup/external-connectors/vcenter-integration-vmware)

***Zscaler Private Access (ZPA)***

Configuring ZPA integration allows your Vectra deployment to map traffic seen by your Vectra network sensors between Zscaler App Connectors and endpoints in your internal environment to the original ZPA user/host. For details, please see linked documentation at: [Zscaler Private Access (ZPA) Log Ingestion Configuration](/configuration/coverage/remote-users/zscaler-zpa).

### Configuration → SETUP → General Settings

***Account Lockout (Local Users)***

This setting allows you to enable and disable account lockout for local users. The maximum login failures allowed and lockout duration can also be configured.

***Auto-Refresh Threat Dashboard***

This setting determines if the Discover → Threat Surface → Threat Summary Dashboard auto-refreshes itself every 10 min. This might be useful in a SOC if a monitor is dedicated for displaying this dashboard.

***In-App Support***

This setting allows you disable or enable [In-App Support](/reference/in-app-support). In-App Support provides connected content to customers such as guided tours, links to articles, etc. It also provides anonymized usability data back to Vectra to help inform our development efforts for new features or gauge the success or usability of existing features.

***Inactive User Logout***

Configure up to a 12-hour limit before externally authenticated users must re-authenticate to access UI.

***Login Caption***

This setting allows you to configure a login caption that displays below the login box.

***Share Metadata with Vectra***

Metadata Sharing Improves Threat Detection

* By contributing anonymized metadata sourced from your Brain appliance, you are contributing directly to the efficacy and accuracy of the Vectra software and the security of your network.
* Access to Detection metadata improves Vectra’s threat detection algorithms, enabling the Vectra software you use to be more effective in a constantly evolving threat landscape.
* For more details, please see [Why is metadata sharing important](/reference/why-is-metadata-sharing-important).

***Timezone***

This setting allows you to configure the time zone used in your Quadrant UX deployment.

***Instance Name***

This allows. you to configure an instance name for your QUX deployment that you may see in various parts of the UI.

***User Password Policy***

This setting allows you to configure the minimum required password length and whether or not passwords will expire.

***New Close Workflow***

The New Close Workflow is enabled by default for all Vectra deployments unless a customer has specifically disabled it during the public preview. For details, please see linked documentation at: [New Close Workflow](/operations/analyst-guidance/new-close-workflow).

It is still possible to disable the New Close Workflow, but Vectra plans to fully remove the legacy workflow in a future update. Please contact Vectra to discuss if this will be problematic for your deployment.

## Configuration → RESPONSE

In this area you can response options such as Lockdown across a wide variety of options and configure notification settings such as email alerts and external app alerts (webhook notifications).

### Lockdown

The full path for items in this area is *Configuration → RESPONSE → Lockdown.*

***Active Directory Account Lockdown***

Account Lockdown enables analysts to temporarily disable network accounts during a security investigation. Please see linked documentation at: [Active Directory Account Lockdown](/configuration/response/lockdown/active-directory-account-lockdown). Please note that at least one AD must be integrated at *Configuration → SETUP → External Connectors → Active Directory* for Active Directory Account Lockdown to function.

***Host Lockdown***

Host Lockdown enables analysts to temporarily disable network hosts during a security investigation. Host Lockdown is enforced through the use of an integrated EDR's host isolation capabilities. Please see linked documentation at: [EDR Host Lockdown Information](/configuration/response/lockdown/host-lockdown-edr). Please note that at least one EDR must be integrated at *Configuration → SETUP → EDR Integrations* for Host Lockdown to function.

***Traffic Lockdown***

Traffic Lockdown is a network-level containment feature that enables Vectra to automatically add compromised host IP addresses to an external blocklist that your firewalls can subscribe to. When a host is added to Traffic Lockdown (manually or automatically), its IP address is published to a plain-text threat feed that integrated firewall devices poll and use to block traffic from that host. Please see linked documentation at: [Traffic Lockdown](/configuration/response/lockdown/traffic-lockdown)

### Notifications

The full path for items in this area is *Configuration → RESPONSE → Notifications.*

***AWS CloudWatch***

In this area you can configure AWS CloudWatch for publishing of health and audit logs to Amazon CloudWatch. Please see the [AWS Brain deployment guide](/deployment/ndr-virtual-cloud-appliances/aws-brain) for details.

***AWS Security Hub***

In this area you can configure AWS Security Hub integration for publishing of hosts scores involving AWS workloads in AWS Security Findings Format (ASFF) to the AWS Security Hub service. Please see the [AWS Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-brain) for details.

You can also configure alert and digest emails. Finally, you can configure [syslog](/configuration/response/notifications/syslog-guide-qux) or [Kafka](https://support.vectra.ai/s/global-search/kafka) output for log data.

***SMTP***

This area enables you to configure the settings for an SMTP connector to send alerts from your Vectra platform deployment. This must be setup before you are able to configure Alert or Digest Emails. Full details are available in the following KB:

* [How do I configure SMTP on a Brain? (Quadrant UX)](/configuration/qux-specific/smtp-configuration-qux)

Once you have saved your STMP settings, a “Test” link will appear under the edit button. Click this to see if the settings work and also check your email folder. If you do not get an error on the Vectra side and still do not receive your email, check you spam folder and adjust your spam filter settings to allow the message.

***Email Alerts***

Alert emails can be sent to email addresses or aliases. Enter the desired recipients in the top box. Alert types:

* Send campaign alerts
  * Attack Campaigns are formed when there is at least one active advanced command & control Detection, and several other hosts are observed to be communicating with the same domain or IP address.
  * These alerts are sent when a Campaign is created or closed.
* Send host alerts
  * These alerts are sent when a host crosses the scoring threshold that is configured.
  * Alerts are also sent when there is a Detection on a Host that is marked as a “Key Asset”. This alert does not rely on a threshold, only that the host is a “Key Asset” and has a new Detection.
  * The Threat and Certainty thresholds are configurable.
  * You may also choose to require that thresholds both be crossed or either crossed by clicking on blue pill between the thresholds thus selecting the “and” or “or” option.
* Send account alerts
  * These alerts are sent when an account crosses the scoring threshold that is configured.
  * Alerts are also sent when there is a Detection on an account that involves a Host that is marked as a “Key Asset”. This alert does not rely on a threshold, only that a host in the Detection details of the Account based Detection is a “Key Asset” and has a new Detection.
  * The Threat and Certainty thresholds are configurable.
  * You may also choose to require that thresholds both be crossed or either crossed by clicking on blue pill between the thresholds thus selecting the “and” or “or” option.
* Send detection alerts
  * These alerts are sent when any selected Detection scores above the configured certainty threshold.
  * For many customers, Host or Account scoring will drive prioritization for investigation by analysts.
  * Some customers may want Detection alerts for specific Detections that they consider critical, such as *Ransomware*, regardless of the current Host or Account score.
* Send system alerts
  * Alerts related to system operations are sent.
  * Examples are when there is a change in Sensor connectivity, capture interface health, or disk health.
* Send vCenter alerts
  * Alert related to changes in vCenter, such as new physical hosts being spun up that do not have vSensor coverage.
  * This requires vCenter integration to be setup.

***External App Alerts***

External App Alerts enable Vectra to deliver real-time notifications to external collaboration tools when critical events occur — such as hosts or accounts crossing prioritization thresholds or system alerts being triggered. For details please see linked documentation at: [External App Alerts (webhook)](/configuration/response/notifications/external-app-alerts-webhook)

***Digest Emails***

This setting may be deprecated in a future release. It allows you to enable or disable a daily digest of detection counts (by category) in the last 24 hours.

***Kafka***

This setting allows you to configured sending syslog to Kafka. What is sent is ssentially the same as for Syslog below but the transport and topic details can be configured for Kafka. For details please see the following articles:

* [Syslog sending to Kafka](/configuration/response/notifications/syslog-sending-to-kafka)
* [Syslog and Kafka message size limits](/configuration/response/notifications/syslog-and-kafka-message-size-limits-qux)

***Syslog***

Administrators can configure their QUX deployment to send host and Account scoring information, detection details, campaign details, and audit logs over syslog to external collectors for storage and analysis.

* [Syslog guide (QUX)](/configuration/response/notifications/syslog-guide-qux)

## Configuration → TUNING

***Triage Filters***

Triage enables teams to manage known, expected, or previously reviewed detection behaviors in a structured and auditable way. By creating targeted filters, security teams ensure the platform reflects what truly matters, improving the precision of scoring and prioritization without suppressing visibility or requiring manual alert review. For details, please see linked documentation at: [Triage Best Practices](/configuration/tuning/triage-best-practices)

***Groups***

Consistent use of groups helps ease triage filter creation and maintenance. For example, rather than building a set of conditions for authorized domains in several triage filters, it is much easier to simply create a group that can be used as often as required. Also, when group membership changes, you only need to update the group and not every filter that would have used the same members as individual conditions. For additional details please see:

* [Active Directory (AD) Groups](/configuration/tuning/active-directory-ad-groups)
* [Dynamic Groups FAQ](/configuration/tuning/dynamic-groups)

***AI Triage***

AI-Triage can be enabled and disable here. AI-Triage automatically triages some detections and enhances signal to noise ratio for analysts. It is a best practice to leave this enabled. For details please see [AI-Triage in detail](/operations/general/ai-triage-in-detail).

## Configuration → ACCESS

***API Clients***

Add and see the status of API clients for accessing the REST API of your Vectra Quadrant UX deployment.

Please see [API (QUX)](/configuration/access/api-qux) for all guides (including older API versions) related to the REST API for QUX. v2.5 guides are linked here:

* [v2.5 Postman quick start guide using OAuth2](/configuration/access/api-qux/v25-postman-quick-start-guide-using-oauth2)
* [v2.5 Postman quick start guide using token auth](/configuration/access/api-qux/v25-postman-quick-start-guide-using-token-auth)
* [v2.5 API guide (QUX)](/configuration/access/api-qux/v25-api-guide-qux)

***Users***

Add new users, see their status, and edit or delete settings for local users in your deployment. SAML users can also be seen here but SAML users are not added using the **Create New User** process. SAML users are controlled by the IdP that is integrated with Vectra. Please see **External Authentication** below for links to SAML integration guides.

***Roles***

See and manage the permissions for roles that are assigned to both local and external (SAML) users for your deployment. Roles can be edited and the default permissions assigned to each role can be modified.

***External Authentication***

Allows configuration of external authentication options for login to Vectra. SAML is the only supported option today. For integration guides please see:

* [SAML with any IdP (QUX)](/configuration/access/saml-sso-qux/any-idp-saml-qux)
* [SAML for ADFS (QUX)](/configuration/access/saml-sso-qux/adfs-saml-qux)
* [SAML for Entra ID (Azure AD) (QUX)](/configuration/access/saml-sso-qux/entra-id-azure-ad-saml-qux)
* [SAML for Okta (QUX)](/configuration/access/saml-sso-qux/okta-saml-qux)
* [SAML for Ping Identity (QUX)](/configuration/access/saml-sso-qux/ping-identity-saml-qux)

***Remote Support***

This is optional and allows Vectra Support access to the Brain command line shell for remote support, debugging, address potential performance problems, verify software updates, and perform troubleshooting.

* Utilizes Open VPN on TCP:443 and UDP:9970.
* Access to the shell is two factor secured, requires a support ticket to be logged, and is audited.
* Please note that this can be toggled on and off as required if you would prefer to not leave it enabled.

For additional detail, please see [Vectra Remote Support](/configuration/access/vectra-remote-support).


# Configuring data sources

Links to deployment guides for network Sensors, traffic validation, and guidance for other cloud data sources supported in QUX deployments.

## Network (Sensors)

Physical and Virtual Sensors (vSensors) collect raw traffic from your network, store it in a rolling capture buffer, and generate a metadata stream that the Brain processes further. When detections are created by the Brain, a PCAP (if enabled) is requested from the Sensor that saw the traffic in question so that it can be attached to the detection for viewing by the analyst. Sensors can also be instructed to perform [packet capture](/deployment/traffic-engineering-and-validation/using-vectra-packet-capture-pcap) based on configured parameters.

Sensor deployment and pairing with the Brain is covered in the following guides:

* [Physical appliance deployment quick start guides](/deployment/ndr-physical-appliances) (All)
  * [X-Series](/deployment/ndr-physical-appliances/x-series) appliances can be used in Brain or Mixed mode.
  * [B-Series](/deployment/ndr-physical-appliances/b-series) appliances can only be used in Brain mode.
  * [S-Series](/deployment/ndr-physical-appliances/s-series) appliances can only be used as Sensors.
  * [M-Series](/deployment/ndr-physical-appliances/m-series) appliances can only be used for Stream.
* Traditional Hypervisor vSensor Deployment and Pairing:
  * [VMware vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/vmware-vsensor)
  * [Hyper-V vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/hyper-v-vsensor)
  * [KVM vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/kvm-vsensor)
  * [Nutanix vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/nutanix-vsensor)
* Cloud IaaS vSensor Deployment and Pairing:
  * [AWS Sensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-vsensor)
  * [Azure Sensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/azure-vsensor)
  * [GCP Sensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/gcp-vsensor)
* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all Vectra Sensor or Stream appliances with any Vectra Brain.

### Traffic Validation

Once you have deployed and added network Sensors to your environment, the next step is to direct traffic at those Sensors so they can produce metadata for analysis by the Brain appliance. This is typically done via SPAN/COPY/MIRROR ports on switches, network TAPs, or packet brokers. Please see the following Vectra support articles for recommendations on network traffic that should be examined and excluded from analysis:

* [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture)
* [Vectra Platform Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations)

After sending traffic to your Sensors, it is a best practice to validate that the traffic observed meets quality standards required for accurate detection and processing. Vectra’s Enhanced Network Traffic Validation feature provides alarms and metrics that can be used to validate the quality of your traffic. Please see the following Vectra support article for details:

* [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv)

## Cloud Data Sources

### IDR for Azure AD & CDR for M365

IDR for Azure AD and CDR for M365 can be deployed at any time once you are able to access the Vectra Respond UX. Some capabilities after enabling a connection to Azure AD and M365 are:

* See and stop attackers targeting Federated applications, the Azure AD backend and all your M365 applications like SharePoint, Exchange and Teams.
* Respond to threats immediately with zero-query investigations.
* See through the chaos and understand how attackers could be bypassing MFA and accessing your tenant.

To enable this data source in your Cloud UI, navigate to *Configuration >* *Data Sources > Azure AD & M365* and click the “Get Started” button in the top right. The [Vectra IDR for Azure AD and CDR for M365 Quickstart Guide](/deployment/idr-for-azure-ad-and-cdr-for-m365) is also linked from this page:

### CDR for AWS

CDR for AWS can be deployed at any time once you are able to access the Vectra Respond UX. Some capabilities after enabling an AWS CloudTrail connection are:

* Monitor AWS CloudTrail Management and Data events to detect changes to your AWS environment which malicious actors can exploit to impact your org.
* Rapidly detect threats against AWS infrastructure without relying on signatures, agents, V-Taps, or static policies.
* Agentless monitoring of applications, users, roles, serverless compute, and storage, through AWS CloudTrail logs.
* Automate response to attacks with native integrations into AWS and 3rd party solutions to automatically stop attacks without impact to service.

To enable this data source in your Respond UX, navigate to *Configuration >* *Data Sources > AWS CloudTrail* and click the “Get Started” button in the top right. The [CDR for AWS Deployment Guide](/deployment/cdr-for-aws/deployment) is also linked from this page:


# Recommended next steps

Recommended actions after an initial QUX deployment, including backups, integrations, and deployment best practices.

## Backing up your Brain

As briefly mention before, the Brain appliance should be backed up by the customer. Care should be taken to ensure backup to a Windows server, SFTP/SCP, or AWS S3 bucket. Storing backups only locally on your Brain appliance is not recommended.

Please see the following Vectra support portal articles for more details:

* [Backup and Restore for Vectra Brain Appliances (v8.5+)](/operations/backup-restore-dr/backup-and-restore-v85)
* [Vectra Brain Appliance Disaster Recovery (DR) / Migration Recommendations (v8.5+)](/operations/backup-restore-dr/disaster-recovery-and-migration-v85)

## Recommended Next Steps

Vectra offers a variety of deployment services, consulting, or full MDR options for customers that need more help or expert analyst assistance. Please work with your Vectra account team for additional details.

This guide covered initial configuration of basic settings. Some recommended next steps are:

* Work on [traffic engineering](/deployment/traffic-engineering-and-validation) and getting traffic flowing to your Sensors or mixed mode Brain.
* Integrations that help with HostID or add context such as:
  * [vCenter integration](/configuration/setup/external-connectors/vcenter-integration-vmware) if you have a VMware environment
  * [SIEM Event Forwarding](/configuration/setup/external-connectors/siem-vectra-brain-ingesting-logs)
  * [Windows Event Log ingestion](/configuration/coverage/network-identities-weli/windows-event-log-ingestion-weli)
  * [EDR integration](/configuration/setup/edr-integrations)
  * [AD integration](/configuration/setup/external-connectors/active-directory)
* Integrations to enable taking action.
  * [AD](/configuration/setup/external-connectors/active-directory) and [EDR](/configuration/setup/edr-integrations) integration bring [host](/configuration/response/lockdown/host-lockdown-edr) and [account](/configuration/response/lockdown/active-directory-account-lockdown) Lockdown capability.
  * [Entra ID (Azure AD) Account Lockdown](/configuration/response/lockdown/entra-id-azure-ad-account-lockdown-rux) works with and Azure AD data source.
* Enabling [Stream](/deployment/stream).
* Setting up [SSO using SAML](/configuration/access/saml-sso-qux) if you have not already done so.
* Building groups and [triage rules](/configuration/tuning/triage-best-practices) to suppress unwanted detections for authorized behaviors.

## Best Practices

* Change default passwords for the 'admin' (GUI) and `vectra` (CLI and IPMI/iDRAC) users to strong versions.
  * See [ssh login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) for details on accessing the CLI of your Brain appliance.
  * Passwords must be between 8 and 128 characters and contain at least: 1 number, both lowercase and uppercase letters, and 1 symbol (e.g. \~!@#$%^&\*,.?-\_+=).
* Limit exposure to admin interfaces through firewall rules that permit communication only from appropriate nodes/networks (including Vectra required endpoints as well).
* IPMI / iDRAC interfaces should be on their own isolated networks when possible.
  * See [IPMI / iDRAC configuration](/deployment/appliance-operations/ipmi-idrac-configuration) for more details.


# Firewall requirements

Firewall connectivity requirements for Vectra RUX and QUX deployments.

## Firewall Requirements Sections

[Important Notes](#important-notes)\
This section covers Respond UX vs Quadrant UX applicability. It also covers SSL inspection, internet/air-gap requirements, and remote support IP range conflicts.

[Vectra Cloud Connectivity](#vectra-cloud-connectivity)\
This section covers connectivity to Vectra services hosted in Vectra’s cloud. It is mainly for Respond UX deployments. The [Auth Gateways](#auth-gateways) section also applies to Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.

[Appliance Connectivity](#appliance-connectivity)\
This section covers connectivity required for Vectra appliances (physical or virtual). It applies to both RUX for Network and Quadrant UX deployments. This section also contains additional details regarding connectivity from Vectra appliances to the Vectra cloud.

## Important Notes

### Respond UX vs Quadrant UX Applicability

The Respond User Experience (Respond UX or RUX) and the Quadrant User Experience (Quadrant UX or QUX) are two different analyst user experiences that Vectra offers. It is important to differentiate between the different UX's when looking at requirements for FW rules. Some FW rules will only apply to deployments using the Respond UX and some will apply only to deployments using the Quadrant UX. For additional information please see: Vectra Analyst User Experiences (Respond vs Quadrant).

While the Respond UX is delivered from Vectra's cloud as part of the overall Vectra AI Platform, it can be used without traditional Brain and Sensor appliances when only non-network data sources are used. RUX for Network deployments (using network Sensors with the Respond UX) still require a Brain appliance to be installed in the customer environment (which can be in IaaS clouds or physical data centers, etc). Sensors will be deployed and paired with that Brain to capture network traffic for analysis.

Requirements listed below that apply only to RUX for Network deployments or only to QUX deployments will be labeled as such.

### Firewall/Proxy SSL Inspection

Please note that Vectra appliances validate SSL certificates for all HTTPS connections. For this reason, SSL/TLS inspection on firewall and proxy appliances must be disabled for these connections to work.

We have also identified that some firewall software transparently enables SSL inspection if certain filters (DNS hostname filtering) are enabled. This is not necessarily obvious to the administrator and should be investigated if connectivity issues are being observed.

### Internet Access From Vectra Brain

A Vectra Brain requires connectivity to the automatic update service for normal operation. This connectivity is used for automatic (including security) updates and to synchronize keys for cryptographic authentication of sensors.

The Brain requires Internet DNS resolution to obtain the IP addresses for these requests. The customer may choose public/Internet DNS servers or internal DNS servers; however, Internet DNS entries must be resolvable by the Brain. Please note that DNS is often considered to be a UDP-only protocol, however, TCP may be used depending on the type of DNS transaction. Both UDP and TCP use port 53 and should be permitted to all configured DNS servers.

Vectra can function in air-gapped environments when a Quadrant UX based deployment is done, but there will be some impacts such as:

* Vectra Threat Intelligence detections will be disabled.
* Suspect Domain Activity detection will be disabled.
* Context enrichments from external sources such as whois, etc that are displayed in certain models will not function.

Please see the [Vectra Quadrant UX Deployment Guide](https://support.vectra.ai/s/article/KB-VS-1077) for additional details about air gap environments including guidance for offline updates. Respond UX for Network is not possible in air-gapped environments since the Respond UX is delivered from Vectra's cloud and communicates with a locally installed Brain.

### Internet Access to Vectra Appliances

As with all security infrastructure Vectra appliances should be blocked from Internet access and access should only be granted from trusted workstations and/or authenticated sources.

### Management Network IP Address Range Conflicts with Remote Support

Customers should note that the following IP ranges will conflict with remote support capability:

* 192.168.72.0/21
* 192.168.80.0/21

If you will ever need Vectra to assist remotely (outside of screen sharing sessions), care should be taken to number the management network interface (MGT) used on any appliance (physical, virtual, or cloud - Brains or Network Data Sources/Sensors) outside of the above ranges. If your management network interface (MGT) is numbered in either of these ranges, remote support access will not function. Remote support connectivity with Vectra all goes through the Brain (even to access other appliances in your deployment) so firewall rules for remote support functionality only need to allow connectivity from the Brain to Vectra's cloud (Sensors must still allow connectivity to the Brain per the below charts).

## Vectra Cloud Connectivity

* For this document, the portions of the Vectra AI Platform that reside in Vectra’s cloud are referred to as the Vectra cloud.
  * This does not refer to any specific service offering.
* Please check each category below to see if it is applicable to your deployment and if rules are required in your environment to enable the required connectivity.
  * For rule categories that have multiple region options, it is only necessary to put rules in place to allow connectivity to the region that your Vectra tenant is deployed in. This region should be visible in the URL used to access the Respond UX.
    * i.e. `[tenant_id].ew1.prod.vectra-svc.ai` is used for EU deployments (ew1).
* RUX for Network refers to a RUX deployment that has enabled network data sources (sensors).
  * This means you have a Brain somewhere in your premises (data center or public cloud) that is connected to the Vectra cloud for use with the Respond UX and paired with network Sensors (virtual or physical) to capture network traffic and distill a metadata stream for processing by the Brain appliance.
  * Please refer to the [Vectra Respond UX Deployment Guide](https://support.vectra.ai/s/article/KB-VS-1696) for more details.
* Please refer to the table below to see applicability of the various categories.
* The **For Brain or User’s Browser** column should be interpreted as follows:
  * **Brain** – Rules required for the Brain to the Vectra Cloud.
  * **User’s Browser** – Rules required for the user’s web browser to the Vectra cloud.

<table data-header-hidden data-full-width="true"><thead><tr><th width="318.47265625"></th><th width="281.6796875"></th><th width="259.9375"></th></tr></thead><tbody><tr><td><strong>Rule Category</strong></td><td><strong>Required For</strong></td><td><strong>For Brain or User’s Browser</strong></td></tr><tr><td><a href="#rux-for-network-gui-synchronization">RUX for Network GUI Synchronization</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#auth-gateways">Auth Gateways</a></td><td><p>RUX for Network Deployments</p><p>Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.</p></td><td>Brain</td></tr><tr><td><a href="#rux-metadata-forwarding">RUX Metadata Forwarding</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#rux-research-metadata-forwarding">RUX Research Metadata Forwarding</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#section-2">RUX Analyst/Admin Access</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#_Respond_UX_(RUX)_1">RUX Static Asset CDN</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#_Respond_UX_Customer">RUX Customer File Upload</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#vectra-cloud-egress-ips">Vectra Cloud Egress IPs</a></td><td>Vectra Cloud connecting to configured SaaS data source connectors</td><td>N/A</td></tr></tbody></table>

### RUX for Network GUI Synchronization

* Required for:
  * All RUX for Network deployments.
* This is used to synchronize configurations between the Brain appliance and your Vectra tenant.
* This communications channel is initiated from the Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **Websocket and HTTPS over TCP/443**

<table data-header-hidden data-full-width="false"><thead><tr><th width="365.3203125" align="center"></th><th width="100" align="center"></th><th width="100" align="center"></th><th width="144.20703125" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">main-cbi-tunnel-uw2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-ew1.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-ec2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-cc1.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-as2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### Auth Gateways

* Required for:
  * All Respond UX for Network Deployments.
  * Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.
    * Your Brain must be able to securely access the Vectra cloud over TCP/443 HTTPS connections to enable detection events from these products to be reported to your UI.
* In Respond UX for Network deployments, the Brain forwards network detections, entities, host sessions, and any selective PCAPs (Vectra Packet Capture) to your Vectra tenant via this connection.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.

<table data-header-hidden data-full-width="true"><thead><tr><th width="383.625" align="center"></th><th width="149.61328125" align="center"></th><th width="148.4609375" align="center"></th><th width="121.22265625" align="center"></th><th width="137.1484375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">authgateway.uw2.public.app.prod.vectra-svc.ai</td><td align="center">54.245.33.175<br>52.42.70.176<br>100.21.109.72<br>52.26.91.157</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.ew1.public.app.prod.vectra-svc.ai</td><td align="center">54.171.40.108<br>54.246.213.148<br>54.75.47.147</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.ec2.public.app.prod.vectra-svc.ai</td><td align="center"><p>16.62.18.237</p><p>16.62.142.98</p><p>51.96.54.201</p></td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.cc1.public.app.prod.vectra-svc.ai</td><td align="center">3.96.112.208<br>52.60.211.221<br>15.222.69.161</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.as2.public.app.prod.vectra-svc.ai</td><td align="center">13.54.11.66<br>13.55.79.24<br>13.55.106.102</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Metadata Forwarding

* Required for:
  * All Respond UX for Network Deployments.
* Network metadata is forwarded to AWS S3 buckets and processed to make it available for features such as Instant Investigation and Advanced Investigation in the Respond UX.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="514.98046875" align="center"></th><th width="100" align="center"></th><th width="119.75390625" align="center"></th><th width="146.4296875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-uswt2-371371611652.s3-accesspoint.us-west-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-euwt1-371371611652.s3-accesspoint.eu-west-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-eucl2-371371611652.s3-accesspoint.eu-central-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-cacl1-371371611652.s3-accesspoint.ca-central-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-apse2-371371611652.s3-accesspoint.ap-southeast-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Research Metadata Forwarding

* Optional but highly recommended for:
  * All Respond UX for Network Deployments
* Research metadata from precursor algorithms are used to improve model quality and reduce detection noise.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="490.4140625" align="center"></th><th width="100" align="center"></th><th width="120.79296875" align="center"></th><th width="135.91796875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">cbo-upload-network-precursors-uswt2-371371611652.s3-accesspoint.us-west-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-euwt1-371371611652.s3-accesspoint.eu-west-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-eucl2-371371611652.s3-accesspoint.eu-central-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-cacl1-371371611652.s3-accesspoint.ca-central-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-apse2-371371611652.s3-accesspoint.ap-southeast-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Analyst/Admin Access

* Required for:
  * All Respond UX deployments.
* Any analyst or admin that wishes to access the Respond UX will need to ensure that their browser can reach their Vectra tenant to login and access the UI.
* This communications channel is initiated from the user’s host.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="340.640625" align="center"></th><th align="center"></th><th align="center"></th><th width="139.19921875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">[tenant_id].uw2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].ew1.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].ec2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].cc1.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].as2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">User’s Browser</td></tr></tbody></table>

### RUX Static Asset CDN

* Required for:
  * All Respond UX deployments.
* The Respond UX has certain static assets (HTML, CSS, JS) that are required to serve the web application hosted by a CDN (Content Delivery Network).
* This communications channel is initiated from the user’s host.

<table data-header-hidden data-full-width="true"><thead><tr><th width="313.40234375" align="center"></th><th width="153.4609375" align="center"></th><th width="100" align="center"></th><th width="100" align="center"></th><th width="142.07421875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center"><p>dd6462tdmvp79.cloudfront.net</p><p>dpew7prsvwbf0.cloudfront.net</p></td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">All</td><td align="center">User’s Browser</td></tr></tbody></table>

### RUX Customer File Upload

* Required for:
  * All Respond UX deployments.
* This communications channel is used for:
  * Vectra Match deployments and will allow upload of rulesets.
  * PCAP download from the Vectra Cloud for Selective PCAP (Vectra Packet Capture)
  * Additional capabilities are planned for future releases.
    * It is recommended to put rules in place even if you don’t use Match or Selective PCAP.
* This communications channel is initiated from the user’s host.

<table data-full-width="true"><thead><tr><th width="395.8828125" align="center"></th><th width="151.8515625" align="center"></th><th width="93.1875" align="center"></th><th width="84.61328125" align="center"></th><th width="144.1015625" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">prd-main-customerfiles-580786928539-uswt2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">US</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-euwt1.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-eucl2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-cacl1.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-apse2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">User’s Browser</td></tr></tbody></table>

### Vectra Cloud Egress IPs

When the Vectra Cloud connects externally to retrieve logs from configured data sources, it does so from the IPs listed at <https://ips.devops.vectra-svc.ai/ips.json>. The specific IPs used will be limited to the IPs listed for the regions in use for your Vectra deployment. For example, if you are only deployed in eu-west-1, then only the IPs from the list associated with eu-west-1 will be used. See the following table for details.

<table><thead><tr><th width="315.4375">Region Code</th><th width="297.0234375">Region</th></tr></thead><tbody><tr><td>ap-southeast-2</td><td>Australia</td></tr><tr><td>ca-central-1</td><td>Canada</td></tr><tr><td>eu-central-2</td><td>Switzerland</td></tr><tr><td>eu-west-1</td><td>EU</td></tr><tr><td>us-west-2</td><td>US</td></tr></tbody></table>

In most situations, customers do NOT need to configure any specific firewall rules to allow Vectra to reach the endpoints required. If you see the IPs in the list accessing your data in your logs, this is not a cause for concern. It is due to the fact that your configured data source connector is connecting to the endpoint to retrieve the data necessary to provide the service.

In the case of CDR for Azure, if private access is required for the Azure storage accounts that Vectra reads your Azure logs from, please see [Configuring Private Access for Azure Storage Accounts](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#configuring-private-access-for-azure-storage-accounts) in the CDR for Azure deployment guide. Details are provided for how to configure the Storage accounts used to only accept connections from the IPs associated with the Vectra Cloud.

## Appliance Connectivity

The [Vectra Cloud connectivity](#vectra-cloud-connectivity) section above primarily deals with connectivity required to deliver the Respond UX and detections from Vectra SaaS offerings to both RUX and QUX deployments, the content in this section also applies to any deployment using Vectra appliances (Brains, Sensors, and Stream) for RUX or QUX deployments.

### Vectra Cloud Appliance Connectivity

All communications with the Vectra Cloud occur over a TLS encrypted channel. Appliance devices (physical, virtual, cloud) authenticate using keys. Unique public/private keys are generated when a device is provisioned by Vectra. The corresponding public key is copied to the Vectra Cloud. Every device connecting to the Vectra Cloud authenticates using its own private key.

The Vectra Cloud houses several services:

* update2.vectranetworks.com
  * Used for delivering updates to the Vectra software.
  * [Offline updates](/operations/readme-1/offline-updates-v89) are also supported.
* api.vectranetworks.com
  * Used for lightweight health monitoring of the Vectra platform and for delivering additional context certain Detections may need.
  * Queries to external information sources to provide context are proxied through this connection.
  * If required, customers can block the platform from reporting health monitoring by blocking outbound connections on their firewall to api.vectranetworks.com.
* rp.vectranetworks.com
  * Used only for Brains deployed in IaaS clouds. Used for authentication and verification (integrity check of the file system).
* metadata.vectra.ai
  * Metadata sharing improves threat detection by contributing anonymized metadata sourced from Brain deployed in your organization. This is optional in QUX deployments.
* rs.vectranetworks.com
  * This enables remote support from authorized Vectra employees.
* SaaS product offerings such as Recall

#### Proxy Support

Vectra Cloud connectivity to update2.vectranetworks.com and api.vectranetworks.com supports connecting through a customer proxy. If a proxy connection is required for your Brain appliance to reach these endpoints, edit the proxy settings in *Configuration → Data Sources → Network → Brain Setup → Proxy & Status*.

* Note that [Remote Support](/configuration/access/vectra-remote-support) does not support proxy configuration by default. If this is the only option, please contact Vectra support to configure remote support to manually to use a proxy.

#### Lightweight Health Monitoring

The lightweight health monitoring includes the following statistics, only aggregate statistics are collected, no details are collected.

* System Health Metrics
  * Installed packages, running processes, system interface information, system usage, database usage, system error stats
* Environment Metrics
  * Host counts, traffic counts, Brain configuration, remote support status, notification status, metadata status
* Detection Metrics
  * Detection counts, PCAP stats, Triage stats

#### Metadata Sharing

[Why is Metadata Sharing Important](/reference/why-is-metadata-sharing-important)

* Full details are available at this link. There are optional additional levels of sharing also described.

Metadata Sharing Improves Threat Detection

* By contributing anonymized metadata sourced from the X-series platform deployed in your organization, you are contributing directly to the efficacy and accuracy of the Vectra software and the security of your network.
* Access to Detection metadata improves Vectra’s threat detection algorithms, enabling the Vectra software you use to be more effective in a constantly evolving threat landscape.
* Data is collected daily and includes:
  * Anonymized information about Detections that are triggered in your network.
  * Anonymized information about algorithms in the research and development phase (and not yet visible in the UI) that are triggered in your network.
  * Anonymized attribution of Detections to Hosts.
  * Anonymized information related to host identification efficacy.
* Vectra Secures and Limits Access to Metadata
  * Any metadata you contribute is anonymized by removing personal and network-specific information before it is sent to metadata.vectranetworks.com via an encrypted connection.
  * Vectra treats this metadata as highly confidential and only allows authorized research personnel to access the metadata.
  * Any metadata collected is securely deleted after a six-month period.
* Contact Vectra support if non-anonymized Full Metadata Sharing is desired
  * Algorithm development using non-anonymized metadata helps to ensure that new models function as efficiently as possible in your environment.

### Required Connectivity For Appliances

<table data-header-hidden data-full-width="true"><thead><tr><th width="131.375" align="center"></th><th width="253.46875" align="center"></th><th width="177.15234375" align="center"></th><th width="288.40234375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td><td align="center"><strong>Description</strong></td></tr><tr><td align="center">Administrator workstations</td><td align="center"><p>Brain</p><p>Sensors</p></td><td align="center">TCP/22 (SSH)</td><td align="center">Command-line management of the Brain and Sensor appliances.</td></tr><tr><td align="center">Administrator workstations</td><td align="center">Brain</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Web management of brain appliances.</td></tr><tr><td align="center">Brain</td><td align="center"><p>update2<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.156.238)</p></td><td align="center">TCP/443<br>(HTTPS)</td><td align="center"><p>Automatic updates.</p><p>Pairing keys for physical sensors.</p><p>See note above regarding SSL keys.</p></td></tr><tr><td align="center">Brain</td><td align="center"><p>api<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.5.9)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Health monitoring, algorithm support, reverse lookups for external IPs, Vectra Threat Intelligence, additional detection content. See note above regarding SSL keys.</td></tr><tr><td align="center">Brain (Cloud)</td><td align="center"><p>rp<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.156.238)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Used only for Brains deployed in IaaS clouds. Used for authentication and verification (integrity check of the file system)</td></tr><tr><td align="center">Brain</td><td align="center">DNS servers (as configured)</td><td align="center">TCP/53, UDP/53</td><td align="center">Both TCP and UDP are required for normal operation. See note above regarding DNS resolution.</td></tr><tr><td align="center">Brain</td><td align="center"><p>NTP servers (as configured)</p><p>Default is ntp.ubuntu.com</p></td><td align="center">UDP/123</td><td align="center">Time synchronization.</td></tr><tr><td align="center">Brain</td><td align="center">SMTP servers (as configured)</td><td align="center">TCP (as configured)</td><td align="center">Email alerting.</td></tr><tr><td align="center">Brain</td><td align="center">SMTP (OAuth)</td><td align="center">TCP/443<br>TCP/587</td><td align="center">Please see SMTP (OAuth) for Microsoft chart below.</td></tr><tr><td align="center">Brain</td><td align="center">Sensors, Stream</td><td align="center">TCP/22 (SSH)</td><td align="center">Remote management and troubleshooting.</td></tr><tr><td align="center">Sensors, Stream</td><td align="center">Brain</td><td align="center">TCP/22 (SSH), TCP/443 (HTTPS)</td><td align="center">Pairing, metadata transfer, and ongoing communication.</td></tr><tr><td align="center">Stream</td><td align="center">Data lake (as configured)</td><td align="center">TCP (as configured)</td><td align="center">Metadata stream to a data lake</td></tr></tbody></table>

### Additional (Feature Dependent) Connectivity

<table data-header-hidden data-full-width="true"><thead><tr><th width="132.6796875" align="center"></th><th width="395.2890625" align="center"></th><th width="167.9609375" align="center"></th><th width="339.06640625" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td><td align="center"><strong>Description</strong></td></tr><tr><td align="center">Brain</td><td align="center">content.user-telemetry.vectra.ai<br>data.user-telemetry.vectra.ai</td><td align="center">TCP/443<br>(HTTPS)</td><td align="center">Required for In-App support functionality.<br>See <a href="https://support.vectra.ai/s/article/KB-VS-1606">In-App Support KB</a> for more details.</td></tr><tr><td align="center">Administrator workstations</td><td align="center">Recall Kibana server</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Recall IP addresses are provided during implementation and may be requested at any time from Vectra Support.</td></tr><tr><td align="center">Brain</td><td align="center"><p>rs.vectranetworks.com</p><p>(74.201.86.229)</p></td><td align="center">TCP/443 or UDP/9970</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1045">Remote Support</a> access for remote troubleshooting. See note above regarding SSL inspection and other note about potential IP range conflicts with the MGT interface.</td></tr><tr><td align="center">Brain</td><td align="center"><p>metadata.vectra.ai</p><p>(100.20.236.31, 44.229.57.246, 44.228.37.60, 44.228.101.87)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Anonymized metadata sharing to contribute to future algorithm development.</td></tr><tr><td align="center">Brain</td><td align="center">Recall collector</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Recall IP addresses are provided during implementation and may be requested at any time from Vectra Support.</td></tr><tr><td align="center">Brain</td><td align="center">Syslog (as configured)</td><td align="center">TCP or UDP (as configured)</td><td align="center">CEF or standard Syslog format.</td></tr><tr><td align="center">Brain</td><td align="center">Kafka (as configured)</td><td align="center">TCP (as configured)</td><td align="center">CEF or standard Syslog format.</td></tr><tr><td align="center">Brain</td><td align="center"><p>Carbon Black Response</p><p>(as configured)</p></td><td align="center">TCP/443 (as configured)</td><td align="center">Carbon Black integration (requires API key).</td></tr><tr><td align="center">Brain</td><td align="center">api.crowdstrike.com</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Crowdstrike integration (Client ID and Client Secret).</td></tr><tr><td align="center">Brain</td><td align="center">vCenter (as configured)</td><td align="center">TCP (as configured)</td><td align="center">vCenter integration enables vSensor physical host view, augmented host identification, and vCenter alerts.</td></tr><tr><td align="center">Brain</td><td align="center">LDAP (as configured)</td><td align="center">TCP/389 STARTTLS/389</td><td align="center">LDAP authentication.</td></tr><tr><td align="center">Brain</td><td align="center">Radius (as configured)</td><td align="center">UDP/1812</td><td align="center">Radius (PAP) authentication.</td></tr><tr><td align="center">Brain</td><td align="center">TACACS (as configured)</td><td align="center">TCP/49</td><td align="center">TACACS (PAP or CHAP) authentication.</td></tr><tr><td align="center">Brain</td><td align="center">Backup server (as configured)</td><td align="center">TCP/22 (SSH)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1121">Automated backup (SCP or SFTP)</a>.</td></tr><tr><td align="center">Brain</td><td align="center">Brain</td><td align="center">TCP/22 (SSH), TCP/443 (HTTPS)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1121">Automated backup (brain-to-brain)</a>. Connectivity is bidirectional.</td></tr><tr><td align="center">Sensors, Stream</td><td align="center">update2.vectranetworks.com (54.200.156.238)</td><td align="center">TCP/443 (HTTPS)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1024">Required for automatic pairing</a>. Optional for manual (offline) pairing.</td></tr><tr><td align="center">SIEM/CLM log management</td><td align="center">Brain</td><td align="center">TCP or UDP (as configured)</td><td align="center">Log forwarding of DHCP/AD security events to augment host identification.</td></tr><tr><td align="center">Brain</td><td align="center"><p>login.windows.net</p><p>api.securitycenter.windows.com</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Required for <a href="https://support.vectra.ai/s/article/KB-VS-1236">ATP lockdown</a></td></tr><tr><td align="center">Brain</td><td align="center">EMEA customers (only)<br><br>authgateway.ew1.public.app.prod.vectra-svc.ai<br>(54.171.40.108 , 54.246.213.148 , 54.75.47.147 )<br><br>AMS/APJ customers (only)<br><br>authgateway.uw2.public.app.prod.vectra-svc.ai<br>(54.245.33.175, 52.42.70.176, 100.21.109.72 , 52.26.91.157)</td><td align="center">TCP/443<br>(HTTPS)</td><td align="center">Required for Vectra MDR Service for QUX Deployments. These endpoints are also required for RUX deployments that have network data sources (Sensors). These are already discussed in the <a href="#auth-gateways">Auth Gateways</a> section of this doc for RUX. Essentially, if your deployment has a Brain, it MUST be able to reach Vectra over these endpoints for Vectra MDR service.</td></tr><tr><td align="center">Sensor</td><td align="center">S3 and SQS AWS Regional Endpoints. Only required for ZIA enabled Sensor.</td><td align="center">TCP/443</td><td align="center">Required for ZIA SASE/SSE integration. See <a href="https://support.vectra.ai/s/article/KB-VS-1006">KB</a> for details.</td></tr></tbody></table>

### SMTP (OAuth) For Microsoft

**Quadrant UX Only**: *Configuration → RESPONSE → Notifications → SMTP*

Respond UX deployments do not require this as email notifications are sent from Vectra's cloud.

<table data-header-hidden data-full-width="true"><thead><tr><th width="282.41015625" align="center"></th><th width="223.69140625" align="center"></th><th width="145.71484375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Cloud Type</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td></tr><tr><td align="center">Public (office365<strong>.</strong>com)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>com<br>smtp<strong>.</strong>office365<strong>.</strong>com</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">US Government (office365<strong>.</strong>us)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>us<br>smtp<strong>.</strong>office365<strong>.</strong>us</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">German (office365<strong>.</strong>de)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>de<br>smtp<strong>.</strong>office365<strong>.</strong>de</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">China (office365<strong>.</strong>cn)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>cn<br>smtp<strong>.</strong>office365<strong>.</strong>cn</td><td align="center">TCP/443<br>TCP/587</td></tr></tbody></table>


# Appliance specifications

Overview, performance, and specifications for Vectra AI's physical, virtual, and cloud appliances.

## Appliance and Sensor Specifications

The Vectra AI Platform provides coverage, clarity, and control across the entire modern network. Coverage for attackers’ moves across all of your network, identity, and cloud threat surfaces. AI signal clarity prioritizes attacks with AI assistants to automatically triage, correlate, and prioritize threats across domains. We put you in control with context to discover, hunt, investigate, and stop attacks early in their progression - all while spending less time prioritizing alerts.

Software updates, including new threat intelligence and detection algorithms, are included with your license. They are delivered to your system on a regular basis to ensure continuous protection from the latest threats. [Match](/deployment/match/deployment/introduction-and-requirements) customers can also choose to enable automated curated ruleset updates that provide signature updates.

Appliances are supported in traditional physical on-prem, virtual hypervisor, and IaaS cloud environments. Vectra AI supports AWS, Azure, and GCP clouds along with VMware, Hyper-V, Nutanix, and KVM hypervisors. We continually evaluates customer demand for support of new environments. Please check with your account team for questions on future plans.

X-Series and S-Series appliances can perform “Sensor” duties, passively capturing network traffic out-of-band and forwarding a metadata stream to the “Brain” appliance for further processing. B-Series and X-Series appliances can serve as the Brain for your deployment. They run network detection models locally and serve as customer side integration point for added coverage, response, and context enhancement options. The Brain appliance is connected to the Vectra AI cloud where the Respond UX provides the UI along with advanced features such as Instant Investigation and AI-Assisted Search. In Quadrant UX deployments, the Brain appliance serves the classic UI locally. If you are unsure of your deployment type, please see [Analyst UX options (RUX vs QUX)](/deployment/getting-started/analyst-ux-options-rux-vs-qux).

Network traffic can be directed to appliances through physical SPAN/Copy/Mirror ports, TAPs, and packet brokers. Native cloud packet forwarding options are supported such as VPC Traffic Mirroring (AWS), VTAP (Azure), and NSI (GCP). Hypervisor based packet forwarding options are also supported. Sensors support a variety of encapsulation methods such as ERSPAN, GRE, VXLAN and GENEVE. For additional detail, please see the [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture).

## Physical Appliance Specifications

### Definitions

{% hint style="info" %}
**Performance**

Refers to the amount of network traffic observed by Sensors that a Sensor can produce metadata for, or the amount of traffic observed by Sensors that a Brain can process metadata for including optional output to [Stream](/deployment/stream/introduction-and-requirements).

Match performance is the expected performance when [Match](/deployment/match/deployment/introduction-and-requirements) is enabled on a Sensor or mixed-mode appliance.

The performance numbers are based upon average throughput a given Sensor/Brain can process. Actual performance may vary depending on traffic composition. Please contact Vectra AI to discuss further.
{% endhint %}

{% hint style="info" %}
**Alternate Interface Configuration**

When an appliance lists an alternate interface configuration as an option in any below table, that means that it supports configuration changes that allow the management interface and/or capture interfaces to be changed from their default assignment.

For the [X29](/deployment/ndr-physical-appliances/x-series/x29)/[M29](/deployment/ndr-physical-appliances/m-series/m29) ,[X47](/deployment/ndr-physical-appliances/x-series/x47)/[M47](/deployment/ndr-physical-appliances/m-series/m47), and [S1v2](/deployment/ndr-physical-appliances/s-series/s1v2) appliances, one of the 10 GbE SFP+ ports that are normally used for capture traffic can be configured to be used as a management interface. When configured as such, the original MGT1 copper port would be unused.

For the [S1](/deployment/ndr-physical-appliances/s-series/s1) appliance there are [4 different port option settings](/deployment/ndr-physical-appliances/s-series/s1#port-option-settings) that vary what is available for use as the management interface and the capture interfaces.

Please see the quick start guides for these appliances for full details and how to configure the alternate interface configurations.
{% endhint %}

{% hint style="info" %}
**Paired Sensors**

Refers to how many Sensors (physical, virtual, or cloud) an appliance can pair with.
{% endhint %}

{% hint style="info" %}
**Tracked Hosts**

Refers to how many hosts the appliance running in Brain or Mixed mode can track simultaneously (open IP (host) sessions). Brains can typically retain and display data for larger numbers of hosts, this only refers to how many hosts the system can process metadata for simultaneously.
{% endhint %}

### Supported SFPs and QSFPs

For any appliance that supports SFP interface (SFP+, SFP28, QSFP, QSFP28, etc), please see the [supported SFPs and QSFPs](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) article for additional details about specific SFPs supported per physical appliance..

Please see the [quick start guides](/deployment/ndr-physical-appliances) for your physical appliance to see port diagrams showing the interfaces available. Some appliances offer options to configure a capture port SFP for use as the management port. Your appliance may support several, only one, or no SFPs.

{% hint style="info" %}
**Please Note (SFPs available at no cost or for an added cost):**

These purchasing guidelines apply to SFPs ordered as part of your appliance order:

* Up to 2 (if supported by your appliance model) SFP, SFP+, or SFP28 modules can be included at no additional cost in your Vectra appliance order.
  * This is valid for each appliance in your order.
* Additional SFP(s) of any type over the two specified above will incur additional cost.
* All 40/100G QSFPs will incur additional cost over the base price of the appliance.
  {% endhint %}

### X-Series Appliances

X-Series appliances can operate in Sensor, Brain, or Mixed mode deployments. For more details about appliance modes, please see [Physical appliance modes and switching between them](/deployment/ndr-physical-appliances/physical-appliance-modes-and-switching-between-them).

#### Interfaces and Capacity

| Specification                            | X3                                         | X29                                        | X47                                            |
| ---------------------------------------- | ------------------------------------------ | ------------------------------------------ | ---------------------------------------------- |
| Management Interfaces (MGT)              | 2 x 1GbE Copper                            | 2 x 1 GbE Copper                           | 2 x 1 GbE Copper                               |
| Capture Interfaces                       | <p>2 x 1 GbE Copper<br>2 x 10 GbE SFP+</p> | <p>2 x 1 GbE Copper<br>2 x 10 GbE SFP+</p> | <p>2 x 1 GbE Copper<br>2 x 10/25 GbE SFP28</p> |
| Alternate Interface Configuration        | N/A                                        | Yes[^1]                                    | Yes[^1]                                        |
| [Paired Sensors](#user-content-fn-2)[^2] | 150                                        | 150                                        | 150                                            |
| [Tracked Hosts](#user-content-fn-3)[^3]  | 100,000                                    | 150,000                                    | 150,000                                        |

#### Performance

<table><thead><tr><th width="259.0859375">Specification</th><th>X3</th><th>X29</th><th>X47</th></tr></thead><tbody><tr><td>Sensor Mode Performance</td><td>9 Gbps</td><td>15 Gbps</td><td>20 Gbps</td></tr><tr><td>Mixed Mode Performance</td><td>8 Gbps</td><td>8 Gbps</td><td>15 Gbps</td></tr><tr><td>Brain Mode Performance</td><td>14 Gbps</td><td>20 Gbps</td><td>30 Gbps</td></tr><tr><td>Match Performance — Sensor</td><td>3 Gbps</td><td>9 Gbps</td><td>13 Gbps</td></tr><tr><td>Match Performance — Mixed</td><td>1 Gbps</td><td>4.6 Gbps</td><td>6 Gbps</td></tr></tbody></table>

#### Power and Electrical

<table><thead><tr><th width="175.109375">Specification</th><th>X3</th><th>X29</th><th>X47</th></tr></thead><tbody><tr><td>Input Voltage</td><td>Dual power supplies, auto sensing 100-240 VAC, 50-60 Hz</td><td>Dual power supplies, auto sensing 100-240 VAC, 50-60 Hz</td><td>Dual power supplies, auto sensing 100-240 VAC, 50-60 Hz</td></tr><tr><td>Power — Normal</td><td>277 W (945 BTU/h)</td><td>296 W (1010 BTU/h)</td><td>602 W (2204 BTU/h)</td></tr><tr><td>Power — Max</td><td>392 W (1338 BTU/h)</td><td>337 W (1150 BTU/h)</td><td>866 W (2966 BTU/h)</td></tr><tr><td>Current — 110 VAC</td><td>3.5 A at 110 VAC</td><td>2.9 A at 110 VAC</td><td>8.0 A at 110 VAC</td></tr><tr><td>Current — 220 VAC</td><td>1.7 A at 220 VAC</td><td>1.5 A at 220 VAC</td><td>3.9 A at 220 VAC</td></tr></tbody></table>

#### Physical, Environment, and Reliability

<table><thead><tr><th width="231.22265625">Specification</th><th>X3</th><th>X29</th><th>X47</th></tr></thead><tbody><tr><td>Dimensions</td><td>42.8 mm (1.685 inches) H<br>482 mm (18.976 inches) W<br>662.19 mm (26.070 inches) D</td><td>42.8 mm (1.685 inches) H<br>482 mm (18.976 inches) W<br>787.04 mm (30.99 inches) D</td><td>42.8 mm (1.685 inches) H<br>482 mm (18.976 inches) W<br>787.04 mm (30.99 inches) D</td></tr><tr><td>Weight</td><td>16.6 kg (36.6 lb)</td><td>17.5 kg (38.6 lb)</td><td>20.3 kb (44.8 lb)</td></tr><tr><td>Operating temperature</td><td>10° to 35° C (50° to 95° F)</td><td>10° to 35° C (50° to 95° F)</td><td>10° to 35° C (50° to 95° F)</td></tr><tr><td>Non-operating temperature</td><td>-40° to 65° C (-40° to 149° F)</td><td>-40° to 65° C (-40° to 149° F)</td><td>-40° to 65° C (-40° to 149° F)</td></tr><tr><td>Airflow</td><td>Front to back, 12.3 l/s (26 CFM)</td><td>Front to back, 16.9 l/s (35.8 CFM)</td><td>Front to back, 52.8 l/s (111.8 CFM)</td></tr><tr><td>Sound Power</td><td>3.8 bels</td><td>7.2 bels</td><td>8.4 bels</td></tr><tr><td>MTBCF</td><td>45,700 hours</td><td>87,600 hours</td><td>97,300 hours</td></tr></tbody></table>

### M-Series Appliances

M-Series appliances share chassis with corresponding X-Series models, but are not equivalent in role. M-Series appliances are used for [Stream](/deployment/stream/introduction-and-requirements) deployments.

#### Interfaces and Performance

<table><thead><tr><th width="271.59375">Specification</th><th>M29</th><th>M47</th></tr></thead><tbody><tr><td>Management Interfaces (MGT)</td><td>2 x 1 GbE Copper</td><td>2 x 1 GbE Copper</td></tr><tr><td>Capture <a data-footnote-ref href="#user-content-fn-4">Interfaces</a></td><td>2 x 1 GbE Copper<br>2 x 10 GbE SFP+</td><td>2 x 1 GbE Copper<br>2 x 10/25 GbE SFP28</td></tr><tr><td>Alternate Interface Configuration</td><td><a data-footnote-ref href="#user-content-fn-1">Yes</a></td><td><a data-footnote-ref href="#user-content-fn-1">Yes</a></td></tr><tr><td>Stream Performance</td><td>75 Gbps</td><td>75 Gbps</td></tr></tbody></table>

#### Power and Electrical

<table><thead><tr><th width="172.40234375">Specification</th><th>M29</th><th>M47</th></tr></thead><tbody><tr><td>Input Voltage</td><td>Dual power supplies, auto sensing 100-240 VAC, 50-60 Hz</td><td>Dual power supplies, auto sensing 100-240 VAC, 50-60 Hz</td></tr><tr><td>Power — Normal</td><td>296 W (10010 BTU/h)</td><td>602 W (2204 BTU/h)</td></tr><tr><td>Power — Max</td><td>337 W (1150 BTU/h)</td><td>866 W (2966 BTU/h)</td></tr><tr><td>Current — 110 VAC</td><td>2.9 A at 110 VAC</td><td>8.0 A at 110 VAC</td></tr><tr><td>Current — 220 VAC</td><td>1.5 A at 220 VAC</td><td>3.9 A at 220 VAC</td></tr></tbody></table>

#### Physical, Environment, and Reliability

<table><thead><tr><th width="230.796875">Specification</th><th>M29</th><th>M47</th></tr></thead><tbody><tr><td>Dimensions</td><td>42.8 mm (1.685 inches) H<br>482 mm (18.976 inches) W<br>787.04 mm (30.99 inches) D</td><td>42.8 mm (1.685 inches) H<br>482 mm (18.976 inches) W<br>787.04 mm (30.99 inches) D</td></tr><tr><td>Weight</td><td>17.5 kg (38.6 lb)</td><td>20.3 kb (44.8 lb)</td></tr><tr><td>Operating temperature</td><td>10° to 35° C (50° to 95° F)</td><td>10° to 35° C (50° to 95° F)</td></tr><tr><td>Non-operating temperature</td><td>-40° to 65° C (-40° to 149° F)</td><td>-40° to 65° C (-40° to 149° F)</td></tr><tr><td>Airflow</td><td>Front to back, 16.9 l/s (35.8 CFM)</td><td>Front to back, 52.8 l/s (111.8 CFM)</td></tr><tr><td>Sound Power</td><td>7.2 bels</td><td>8.4 bels</td></tr><tr><td>MTBCF</td><td>87,600 hours</td><td>97,300 hours</td></tr></tbody></table>

### S-Series Appliances

S-Series appliances operate in Sensor mode only. For more details about appliance modes, please see [Physical appliance modes and switching between them](https://docs.vectra.ai/~/changes/335/deployment/ndr-physical-appliances/physical-appliance-modes-and-switching-between-them).

#### Interfaces and Capacity

| Specification                     | S1                                         | S1v2                                       | S11                         | S17                                         | S101                                                                                     | S127                                                            |
| --------------------------------- | ------------------------------------------ | ------------------------------------------ | --------------------------- | ------------------------------------------- | ---------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| Management Interfaces (MGT)       | 2 x 1 GbE Copper                           | 2 x 1 GbE Copper                           | 2 x 1 GbE Copper            | <p>1 x 10 GbE Copper<br>1x 1 GbE Copper</p> | 2 x 10 GbE SFP+                                                                          | 2 x 10/25 GbE SFP28                                             |
| Capture Interfaces                | <p>4 x 1 GbE Copper<br>2 x 10 GbE SFP+</p> | <p>2 x 1 GBE Copper<br>2 x 10 GbE SFP+</p> | <p>2 x 1 GbE Copper<br></p> | 1 x 10 GbE Copper                           | <p>2x 10 GbE SFP+<br>2 configurable to: 10/25 GbE SFP28, 40 GbE QSFP, 100 GbE QSFP28</p> | 2 configurable to: 10/25 GbE SFP28, 40 GbE QSFP, 100 GbE QSFP28 |
| Alternate Interface Configuration | Yes[^5]                                    | Yes[^6]                                    | N/A                         | N/A                                         | N/A                                                                                      | N/A                                                             |

#### Performance

| Specification             | S1       | S1v2     | S11      | S17      | S101    | S127    |
| ------------------------- | -------- | -------- | -------- | -------- | ------- | ------- |
| Sensor Mode Performance   | 1 Gbps   | 1 Gbps   | 2 Gbps   | 9 Gbps   | 50 Gbps | 58 Gbps |
| Match Enabled Performance | 600 Mbps | 400 Mbps | 1.2 Gbps | 2.5 Gbps | 33 Gbps | 30 Gbps |

#### Power and Electrical

| Specification     | S1                                                              | S1v2                                                                | S11                                                    | S17                                                    | S101                                                    | S127                                                    |
| ----------------- | --------------------------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------ | ------------------------------------------------------- | ------------------------------------------------------- |
| Input Voltage     | Single external power supply, auto-sensing 100-240VAC, 50-60 Hz | Single[^7] external power supply, auto-sensing 100-240VAC, 50-60 Hz | Single power supply, auto-sensing 100-240VAC, 50-60 Hz | Single power supply, auto-sensing 100-240VAC, 50-60 Hz | Dual power supplies, auto sensing 100-240 VAC, 50-60 Hz | Dual power supplies, auto sensing 100-240 VAC, 50-60 Hz |
| Power — Normal    | Not available                                                   | Not available                                                       | 152 W (519 BTU/h)                                      | Not available                                          | 615 W (2098 BTU/h)                                      | 769 W (2624 BTU/h)                                      |
| Power — Max       | 45W (154 BTU/h)                                                 | 150W (512 BTU/h)                                                    | 186 W (635 BTU/h)                                      | 196 W (669 BTU/h)                                      | 868 W (2962 BTU/h)                                      | 1073 W (3661 BTU/h)                                     |
| Current — 110 VAC | 2.0 A at 100 VAC                                                | 2.0 A at 110 VAC                                                    | 1.7 A at 110 VAC                                       | 1.8 A at 110 VAC                                       | 7.9 A at 110 VAC                                        | 9.8 amps at 110 VAC                                     |
| Current — 220 VAC | 1.0 A at 240 VAC                                                | 1.0 A at 220 VAC                                                    | 0.8 A at 220 VAC                                       | 0.9 A at 220 VAC                                       | 3.8 A at 220 VAC                                        | 4.8 amps at 220 VAC                                     |

#### Physical, Environment, and Reliability

| Specification             | S1                                                                                                                | S1v2                                                                     | S11                                                                                 | S17                                                                     | S101                                                                                    | S127                                                                                      |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Dimensions                | <p>52 mm (2.04 in) H<br>208 mm (8.18 in) W<br>200 mm (7.87 in) D</p>                                              | <p>43.7 mm (1.7 in) H<br>339.6 mm (13.3 in) W<br>241.1 mm (9.5 in) D</p> | <p>42.8 mm (1.685 inches) H<br>434 mm (17.1 inches) W<br>535 mm (22.6 inches) D</p> | <p>42.8 mm (1.685 in) H<br>434 mm (17.1 in) W<br>461 mm (18.2 in) D</p> | <p>42.8 mm (1.685 inches) H<br>482 mm (18.976 inches) W<br>808.5 mm (31.8 inches) D</p> | <p>42.8 mm (1.685 inches) H<br>482 mm (18.976 inches) W<br>787.04 mm (30.99 inches) D</p> |
| Weight                    | <p>Without power supply unit (PSU): 1.4 kg (3.1 lb)<br>Including power supply and packaging: 4.9 kg (10.8 lb)</p> | 4.5 kb (9.9 lb)                                                          | 12.2 kg (26.9 lb)                                                                   | 9.6 kg (21.2 lb)                                                        | 21 kg (46.3 lb)                                                                         | 20.3 kg (44.8 lb)                                                                         |
| Operating temperature     | 0° to 40° C (32° to 104° F)                                                                                       | 0° to 40° C (32° to 104° F)                                              | 0° to 40° C (32° to 104° F)                                                         | 5° to 40° C (41° to 104° F)                                             | 10° to 35° C (50° to 95° F)                                                             | 10° to 35° C (50° to 95° F)                                                               |
| Non-operating temperature | -40° to 70° C (-40° to 158° F)                                                                                    | -40° to 70° C (-40° to 158° F)                                           | -40° to 70° C (-40° to 158° F)                                                      | -40° to 65° C (-40° to 149° F)                                          | -40° to 65° C (-40° to 149° F)                                                          | -40° to 65° C (-40° to 149° F)                                                            |
| Airflow                   | In bottom, out sides and back, 4.7 l/s (10 CFM)                                                                   | In front/sides, out back, CFM not available                              | Front to back, 5.4 l/s (11.4 CFM)                                                   | Front to back, 11.0 l/s (23.4 CFM)                                      | Front to back, 29.1 l/s (61.6 CFM)                                                      | Front to back, 52.8 l/s (111.8 CFM)                                                       |
| Sound Power               | 4.8 bels                                                                                                          | Not available                                                            | 5.7 bels                                                                            | 7.6 bels                                                                | 7.6 bels                                                                                | 8.4 bels                                                                                  |
| MTBCF                     | 445,000 hours                                                                                                     | 117,700 (MTBF)                                                           | 109,000 hours                                                                       | TBD                                                                     | 107,000 hours                                                                           | 102,000 hours                                                                             |

### B-Series Appliances

B-Series appliances serve as Brain appliances only. For more details about appliance modes, please see [Physical appliance modes and switching between them](https://docs.vectra.ai/~/changes/335/deployment/ndr-physical-appliances/physical-appliance-modes-and-switching-between-them).

#### Interfaces and Capacity

<table><thead><tr><th width="272.8359375">Specification</th><th>B101</th><th>B127</th></tr></thead><tbody><tr><td>Management Interfaces (MGT)</td><td>2 x 10 GbE SFP+</td><td>2 x 10/25 GbE SFP28</td></tr><tr><td>Capture Interfaces</td><td>N/A</td><td>N/A</td></tr><tr><td>Alternate Interface Configuration</td><td>N/A</td><td>N/A</td></tr><tr><td><a data-footnote-ref href="#user-content-fn-2">Paired Sensors</a></td><td>500</td><td>500</td></tr><tr><td><a data-footnote-ref href="#user-content-fn-3">Tracked Hosts</a></td><td>300,000</td><td>300,000</td></tr></tbody></table>

#### Performance

<table><thead><tr><th width="213.26953125">Specification</th><th>B101</th><th>B127</th></tr></thead><tbody><tr><td>Brain Mode Performance</td><td>75 Gbps</td><td>75 Gbps</td></tr></tbody></table>

#### Power and Electrical

<table><thead><tr><th width="176.359375">Specification</th><th>B101</th><th>B127</th></tr></thead><tbody><tr><td>Input Voltage</td><td>Dual power supplies, auto sensing 100-240 VAC, 50-60 Hz</td><td>Dual power supplies, auto sensing 100-240 VAC, 50-60 Hz</td></tr><tr><td>Power — Normal</td><td>604 W (2061 BTU/h)</td><td>773 W (2638 BTU/h)</td></tr><tr><td>Power — Max</td><td>846 W (2887 BTU/h)</td><td>1149 W (3920 BTU/h)</td></tr><tr><td>Current — 110 VAC</td><td>7.7 amps at 110 VAC</td><td>10.7 amps at 110 VAC</td></tr><tr><td>Current — 220 VAC</td><td>3.7 amps at 220 VAC</td><td>5.3 amps at 220 VAC</td></tr></tbody></table>

#### Physical, Environment, and Reliability

<table><thead><tr><th width="231.55859375">Specification</th><th>B101</th><th>B127</th></tr></thead><tbody><tr><td>Dimensions</td><td>42.8 mm (1.685 inches) H<br>482 mm (18.976 inches) W<br>808.5 mm (31.8 inches) D</td><td>42.8 mm (1.685 inches) H<br>482 mm (18.976 inches) W<br>787.04 mm (30.99 inches) D</td></tr><tr><td>Weight</td><td>21 kg (46.3 lb)</td><td>20.3 kg (44.8 lb)</td></tr><tr><td>Operating temperature</td><td>10° to 35° C (50° to 95° F)</td><td>10° to 35° C (50° to 95° F)</td></tr><tr><td>Non-operating temperature</td><td>-40° to 65° C (-40° to 149° F)</td><td>-40° to 65° C (-40° to 149° F)</td></tr><tr><td>Airflow</td><td>Front to back, 61.6 CFM = 29.1 l/s</td><td>Front to back, 111.8 CFM = 52.8 l/s</td></tr><tr><td>Sound Power</td><td>7.6 bels</td><td>8.4 bels</td></tr><tr><td>MTBCF</td><td>109,000 hours</td><td>132,000 hours</td></tr></tbody></table>

## Customer Premise Virtual (Hypervisor) Deployment

These virtual appliances are deployed in traditional hypervisor enviroments such as VMware vSphere, Hyper-V, KVM, and Nutanix.

### Virtual Brains

<table><thead><tr><th width="115.05859375">Hypervisor</th><th width="181.578125">VM Type / Version</th><th width="75.015625" align="right">Cores</th><th width="82.2734375" align="right">Memory</th><th width="118.921875">Storage (OS, Data) in GB</th><th width="118.37109375" align="right">Paired Sensors</th><th width="126.82421875" align="right">Tracked Hosts</th><th width="138.11328125">Performance</th></tr></thead><tbody><tr><td>VMware</td><td>vSphere 6.5 or later</td><td align="right">4</td><td align="right">48GB</td><td>128,512</td><td align="right">5</td><td align="right">25,000</td><td>150 Mbps</td></tr><tr><td>VMware</td><td>vSphere 6.5 or later</td><td align="right">6</td><td align="right">48GB</td><td>128,512</td><td align="right">10</td><td align="right">37,500</td><td>500 Mbps</td></tr><tr><td>VMware</td><td>vSphere 6.5 or later</td><td align="right">8</td><td align="right">64GB</td><td>128,512</td><td align="right">15</td><td align="right">50,000</td><td>2 Gbps</td></tr><tr><td>VMware</td><td>vSphere 6.5 or later</td><td align="right">16</td><td align="right">128GB</td><td>128,512</td><td align="right">25</td><td align="right">50,000</td><td>4 Gbps</td></tr><tr><td>VMware</td><td>vSphere 6.5 or later</td><td align="right">32</td><td align="right">256GB</td><td>128,512</td><td align="right">100</td><td align="right">150,000</td><td>10 Gbps</td></tr><tr><td>Nutanix</td><td>AOS 6.8.1 and higher with Prism Central (and v3 API) available</td><td align="right">32</td><td align="right">256GB</td><td>128,512</td><td align="right">100</td><td align="right">150,000</td><td>10 Gbps</td></tr></tbody></table>

### Virtual Sensors

| Hypervisor | VM Type / Version                                                 | Cores | Memory | Storage    | Performance |
| ---------- | ----------------------------------------------------------------- | ----: | -----: | ---------- | ----------- |
| VMware     | vSphere 6.5 or later                                              |     2 |   8 GB | 100 GB     | 500 Mbps    |
| VMware     | vSphere 6.5 or later                                              |     4 |   8 GB | 150 GB     | 1 Gbps      |
| VMware     | vSphere 6.5 or later                                              |     8 |  16 GB | 150 GB     | 2 Gbps      |
| VMware     | vSphere 6.5 or later                                              |    16 |  64 GB | 600 GB[^8] | 5 Gbps      |
| VMware     | vSphere 6.5 or later                                              |    32 | 114 GB | 830 GB     | 20 Gbps     |
| Hyper-V    | Windows Server 2016 w/ HW v8 or higher                            |     2 |   8 GB | 100 GB     | 500 Mbps    |
| Hyper-V    | Windows Server 2016 w/ HW v8 or higher                            |     4 |   8 GB | 150 GB     | 1 Gbps      |
| Hyper-V    | Windows Server 2016 w/ HW v8 or higher                            |     8 |  16 GB | 150 GB     | 2 Gbps      |
| Hyper-V    | Windows Server 2016 w/ HW v8 or higher                            |    16 |  64 GB | 500 GB     | 5 Gbp       |
| KVM        | Standard PC (Q35 + ICH9, 2009)                                    |     2 |   8 GB | 100 GB     | 500 Mbps    |
| KVM        | Standard PC (Q35 + ICH9, 2009)                                    |     4 |   8 GB | 150 GB     | 1 Gbps      |
| KVM        | Standard PC (Q35 + ICH9, 2009)                                    |     8 |  16 GB | 150 GB     | 2 Gbps      |
| KVM        | Standard PC (Q35 + ICH9, 2009)                                    |    16 |  64 GB | 500 GB     | 5 Gbps      |
| Nutanix    | AOS Version: 5.20.3.5 or later; AHV Version 2021105.2267 or later |     2 |   8 GB | 100 GB     | 500 Mbps    |
| Nutanix    | AOS Version: 5.20.3.5 or later; AHV Version 2021105.2267 or later |     4 |   8 GB | 150 GB     | 1 Gbps      |
| Nutanix    | AOS Version: 5.20.3.5 or later; AHV Version 2021105.2267 or later |     8 |  16 GB | 150 GB     | 2 Gbps      |
| Nutanix    | AOS Version: 5.20.3.5 or later; AHV Version 2021105.2267 or later |    16 |  64 GB | 500 GB     | 5 Gbps      |
|            |                                                                   |       |        |            |             |

## Cloud - IaaS Deployment

These virtual appliances are deployed in IaaS clouds such as AWS, Azure, and GCP.

{% hint style="info" %}
**Please Note:**

Vectra product and engineering teams monitor the changing landscape of available IaaS cloud instance types. Occassionally customers will ask if a specific new instance type is supported.

There are a number of factors that can cause Vectra AI to stay with a specific instance type versus a newer one such as:

* Cost increase vs performance increase - sometimes a newer instance, for example, might cost 17% more but only increase performance by 10%.
* Availability - not all new instance types are always available in all the locations that Vectra AI supports.

Please reach out to your account team if you have questions about specific instance types that aren't supported.
{% endhint %}

### Virtual Brains (IaaS)

<table><thead><tr><th width="83.078125">Cloud</th><th width="158.83984375">VM Type</th><th width="76.2890625" align="right">Cores</th><th width="96.7421875" align="right">Memory</th><th width="255.15625">Storage in GB (OS, Data, Data, Data)</th><th width="121.13671875" align="right">Paired Sensors</th><th width="115.79296875" align="right">Tracked Hosts</th><th width="115.84765625">Performance</th></tr></thead><tbody><tr><td>AWS</td><td>r5d.2xlarge</td><td align="right">8</td><td align="right">64 GB</td><td>256, 64, 128, 256</td><td align="right">15</td><td align="right">50,000</td><td>2 Gbps</td></tr><tr><td>AWS</td><td>r5d.4xlarge</td><td align="right">16</td><td align="right">128 GB</td><td>256, 64, 128, 256</td><td align="right">25</td><td align="right">50,000</td><td>5 Gbps</td></tr><tr><td>AWS</td><td>r5d.8xlarge</td><td align="right">32</td><td align="right">256 GB</td><td>256, 64, 128, 256</td><td align="right">100</td><td align="right">150,000</td><td>15 Gbps</td></tr><tr><td>AWS</td><td>r5.16xlarge</td><td align="right">64</td><td align="right">512 GB</td><td><a data-footnote-ref href="#user-content-fn-9">256</a>, 64, 512, 512</td><td align="right">500</td><td align="right">500,000</td><td>50 Gbps</td></tr><tr><td>Azure</td><td>Standard_E16s_v3</td><td align="right">16</td><td align="right">128 GB</td><td>256, 64, 128, 256</td><td align="right">25</td><td align="right">50,000</td><td>5 Gbps</td></tr><tr><td>Azure</td><td>Standard_E32s_v3</td><td align="right">32</td><td align="right">256 GB</td><td>256, 64, 128, 256</td><td align="right">100</td><td align="right">150,000</td><td>15 Gbps</td></tr><tr><td>GCP</td><td>n2-highmem-16</td><td align="right">16</td><td align="right">128 GB</td><td>1 TB (single partition)</td><td align="right">25</td><td align="right">50,000</td><td>5 Gbps</td></tr><tr><td>GCP</td><td>n2-highmem-32</td><td align="right">32</td><td align="right">256 GB</td><td>1 TB (single partition)</td><td align="right">100</td><td align="right">150,000</td><td>15 Gbps</td></tr><tr><td>GCP</td><td>n2-highmem-64</td><td align="right">64</td><td align="right">512 GB</td><td>1.2 TB (single partition)</td><td align="right">100</td><td align="right">150,000</td><td>50 Gbps</td></tr><tr><td>GCP</td><td>n2-highmem-96</td><td align="right">96</td><td align="right">768 GB</td><td>4 TB (single partition)</td><td align="right">100</td><td align="right">500,000</td><td>85 Gbps</td></tr></tbody></table>

### Virtual Sensors (IaaS)

<table><thead><tr><th width="86.515625">Cloud</th><th width="167.875">VM Type</th><th width="90.953125" align="right">Cores</th><th width="122.22265625" align="right">Memory</th><th width="257.34765625">Storage (OS, Data) in GB)</th><th width="139.95703125">Performance</th></tr></thead><tbody><tr><td>AWS</td><td>r5(n).large</td><td align="right">2</td><td align="right">16 GB</td><td>50, 128</td><td>1 Gbps</td></tr><tr><td>AWS</td><td>r5(n).large</td><td align="right">4</td><td align="right">32 GB</td><td>50, 128</td><td>2 Gbps</td></tr><tr><td>AWS</td><td>r5(n).2xlarge</td><td align="right">8</td><td align="right">64 GB</td><td>50, 512</td><td>4 Gbps</td></tr><tr><td>AWS</td><td>r5(n).4xlarge</td><td align="right">16</td><td align="right">128 GB</td><td>50, 512</td><td>8 Gbps</td></tr><tr><td>AWS</td><td>c5n.18xlarge</td><td align="right">72</td><td align="right">192 GB</td><td>50, 128 (No PCAP capability)</td><td>Up to 10 Gbps</td></tr><tr><td>Azure</td><td>Standard_DS11_v2</td><td align="right">2</td><td align="right">14 GB</td><td>50, 128</td><td>1 Gbps</td></tr><tr><td>Azure</td><td>Standard_DS3_v2</td><td align="right">4</td><td align="right">14 GB</td><td>50, 128</td><td>2 Gbps</td></tr><tr><td>GCP</td><td>e2-standard-2</td><td align="right">2</td><td align="right">8 GB</td><td>50, 128</td><td>1 Gbps</td></tr><tr><td>GCP</td><td>e2-standard-4</td><td align="right">4</td><td align="right">16 GB</td><td>50, 128</td><td>2 Gbps</td></tr><tr><td>GCP</td><td>e2-standard-16</td><td align="right">16</td><td align="right">64 GB</td><td>50, 128</td><td>5 Gbps</td></tr><tr><td>GCP</td><td>e2-standard-32</td><td align="right">32</td><td align="right">128 GB</td><td>50, 128</td><td>10 Gbps</td></tr></tbody></table>

{% hint style="info" %}
**Please note regarding AWS instances:**

AWS vSensor configurations include both “n” and non “n” r5 instance types.

* Networking performance is quoted as “up to 10Gbps” on the r5 instances by AWS and can be influenced by neighboring instances allocated to the same physical hardware in AWS.
* Networking performance is quoted as “up to 25Gbps” on the r5n instances by AWS. These instances are still shared with neighbors but are optimized by AWS to have higher overall network throughput.
* Customers can work with AWS to utilize dedicated instances and distribute instances to provide the required networking throughput to their vSensor instances on that dedicated hardware.

The c5n.18x large vSensor instance type does not have a rolling capture buffer and can therefore not support PCAP generation for Detections that originate from traffic that is processed by those instances.

Due to variability in customer cloud network configurations and how mirroring may configured, it is not possible to guarantee performance on any instance with more than 2 cores (numbers are approximate and based on even distribution of packets across threads). Please contact Vectra to discuss further.

Vectra monitors instance types available from the supported IaaS vendors for cost, performance, and availability. If you have questions about specific instance types that are not supported, please contact your Vectra account team.
{% endhint %}

## Vectra Match Performance

<table><thead><tr><th width="571.83203125">Appliance</th><th width="85.62890625">Mode</th><th width="300.86328125">Match Performanc(Detect and Match)</th></tr></thead><tbody><tr><td>S1</td><td>Sensor</td><td>400 Mbps</td></tr><tr><td>S11</td><td>Sensor</td><td>1.2 Gbps</td></tr><tr><td>S101</td><td>Sensor</td><td>33 Gbps</td></tr><tr><td>S127</td><td>Sensor</td><td>30 Gbps</td></tr><tr><td>X3</td><td>Sensor</td><td>3 Gbps</td></tr><tr><td>X3</td><td>Mixed</td><td>1 Gbps</td></tr><tr><td>X29</td><td>Sensor</td><td>9 Gbps</td></tr><tr><td>X29</td><td>Mixed</td><td>4.6 Gbps</td></tr><tr><td>X47</td><td>Sensor</td><td>13 Gbps</td></tr><tr><td>X47</td><td>Mixed</td><td>6 Gbps</td></tr><tr><td>2 core vSensors (VMware, Hyper-V, KVM, Nutanix)</td><td>Sensor</td><td>250 Mbps</td></tr><tr><td>4 core vSensors (VMware, Hyper-V, KVM, Nutanix)</td><td>Sensor</td><td>500 Mbps</td></tr><tr><td>8 core vSensors (VMware, Hyper-V, KVM, Nutanix)</td><td>Sensor</td><td>1 Gbps</td></tr><tr><td>16 core vSensors (VMware, Hyper-V, KVM, Nutanix)</td><td>Sensor</td><td>2.5 Gbps</td></tr><tr><td>32 core vSensor (VMware)</td><td>Sensor</td><td>10 Gbps</td></tr><tr><td>2 core vSensors (AWS, Azure, GCP)</td><td>Sensor</td><td>500 Mbps</td></tr><tr><td>4 core vSensors (AWS, Azure, GCP)</td><td>Sensor</td><td>1 Gbps</td></tr><tr><td>8 core vSensors (AWS)</td><td>Sensor</td><td>2 Gbps</td></tr><tr><td>16 core vSensors (AWS)</td><td>Sensor</td><td>4 Gbps</td></tr><tr><td>16 core vSensor (GCP)</td><td>Sensor</td><td>2.5 Gbps</td></tr><tr><td>32 core vSensor (GCP)</td><td>Sensor</td><td>5 Gbps</td></tr></tbody></table>

## Stream Sizing and Performance

When considering sizing for Stream it is important to understand that the traffic mix at customer sites varies widely. Some customers have traffic mixes that skew towards larger flows (think file transfers), and some will skew towards smaller flows. Performance will be lower when the traffic mix skews towards smaller flows as there will be more metadata to process. The below are guidelines for average traffic mixes and should not be considered absolute. Throughput refers to the amount of traffic observed by Sensors that forward metadata to the Vectra platform.

**Virtual Appliances:**

<table><thead><tr><th width="138.95703125" align="center">Hypervisor / Cloud</th><th width="162.95703125" align="center">VM Type</th><th width="100" align="center">Cores</th><th width="105.6484375" align="center">Memory</th><th width="98.7421875" align="center">Storage</th><th width="141.7578125" align="center">~ Performance</th></tr></thead><tbody><tr><td align="center">VMware</td><td align="center">vSphere 6.5 or later</td><td align="center">2</td><td align="center">8 GB</td><td align="center">100 GB</td><td align="center">Up to 2.5 Gbps</td></tr><tr><td align="center">VMware</td><td align="center">vSphere 6.5 or later</td><td align="center">4</td><td align="center">8 GB</td><td align="center">150 GB</td><td align="center">2.5 to 5 Gbps</td></tr><tr><td align="center">VMware</td><td align="center">vSphere 6.5 or later</td><td align="center">8</td><td align="center">16 GB</td><td align="center">150 GB</td><td align="center">5 to 10 Gbps</td></tr><tr><td align="center">VMware</td><td align="center">vSphere 6.5 or later</td><td align="center">16</td><td align="center">64 GB</td><td align="center">150 GB</td><td align="center">10 to 20 Gbps</td></tr><tr><td align="center">Hyper-V</td><td align="center">Windows Server 2016 w/ HW v8 or higher</td><td align="center">2</td><td align="center">8 GB</td><td align="center">100 GB</td><td align="center">Up to 2.5 Gbps</td></tr><tr><td align="center">Hyper-V</td><td align="center">Windows Server 2016 w/ HW v8 or higher</td><td align="center">4</td><td align="center">8 GB</td><td align="center">150 GB</td><td align="center">2.5 to 5 Gbps</td></tr><tr><td align="center">Hyper-V</td><td align="center">Windows Server 2016 w/ HW v8 or higher</td><td align="center">8</td><td align="center">16 GB</td><td align="center">150 GB</td><td align="center">5 to 10 Gbps</td></tr><tr><td align="center">Hyper-V</td><td align="center">Windows Server 2016 w/ HW v8 or higher</td><td align="center">16</td><td align="center">64 GB</td><td align="center">500 GB</td><td align="center">10 to 20 Gbps</td></tr><tr><td align="center">KVM</td><td align="center">Standard PC (Q35 + ICH9, 2009)</td><td align="center">2</td><td align="center">8 GB</td><td align="center">100 GB</td><td align="center">Up to 2.5 Gbps</td></tr><tr><td align="center">KVM</td><td align="center">Standard PC (Q35 + ICH9, 2009)</td><td align="center">4</td><td align="center">8 GB</td><td align="center">150 GB</td><td align="center">2.5 to 5 Gbps</td></tr><tr><td align="center">KVM</td><td align="center">Standard PC (Q35 + ICH9, 2009)</td><td align="center">8</td><td align="center">16GB</td><td align="center">150 GB</td><td align="center">5 to 10 Gbps</td></tr><tr><td align="center">KVM</td><td align="center">Standard PC (Q35 + ICH9, 2009)</td><td align="center">16</td><td align="center">64 GB</td><td align="center">500 GB</td><td align="center">10 to 20 Gbps</td></tr><tr><td align="center">AWS</td><td align="center">c5.xlarge</td><td align="center">4</td><td align="center">8 GB</td><td align="center">50 GB</td><td align="center">Up to 5 Gbps</td></tr><tr><td align="center">AWS</td><td align="center">c5.2xlarge</td><td align="center">8</td><td align="center">16 GB</td><td align="center">50 GB</td><td align="center">5 to 10 Gbps</td></tr><tr><td align="center">AWS</td><td align="center">c5.4xlarge</td><td align="center">16</td><td align="center">32 GB</td><td align="center">50 GB</td><td align="center">10 to 20 Gbps</td></tr><tr><td align="center">Azure</td><td align="center">Standard_DS4_v2</td><td align="center">8</td><td align="center">28 GB</td><td align="center">50 GB</td><td align="center">Up to 10 Gbps</td></tr><tr><td align="center">Azure</td><td align="center">Standard_DS5_v2</td><td align="center">16</td><td align="center">56 GB</td><td align="center">50 GB</td><td align="center">10 to 20 Gbps</td></tr><tr><td align="center">GCP</td><td align="center">e2-standard-4</td><td align="center">4</td><td align="center">16 GB</td><td align="center">50 GB</td><td align="center">Up to 5 Gbps</td></tr><tr><td align="center">GCP</td><td align="center">e2-standard-8</td><td align="center">8</td><td align="center">32 GB</td><td align="center">50 GB</td><td align="center">5 to 10 Gbps</td></tr><tr><td align="center">GCP</td><td align="center">e2-standard-16</td><td align="center">16</td><td align="center">64 GB</td><td align="center">50 GB</td><td align="center">10 to 20 Gbps</td></tr></tbody></table>

**Vectra M Series Physical Appliances:**

The M series physical appliances can support up to \~75 Gbps of throughput.

{% hint style="info" %}
**Please Note:**

* Contact your account team or Vectra support for guidance on special situations, abnormal traffic mixes, or throughput needs outside of what is documented above.
* Vectra recommends that Stream VMs are configured to use storage local to the hypervisor and are not stored on a SAN. Stream VMs require extremely high throughput from their disk storage and this throughput cannot normally be sustained by SAN systems without impact to other SAN users.
* Please see [VMware deployment details and considerations](/deployment/ndr-virtual-cloud-appliances/vmware-vsensor/vmware-deployment-details-and-considerations) for guidance on supported CPUs, storage/SANs, networking requirements, vMotion, Enhanced vMotion compatibility, and unsupported hypervisors. While Sensor and VMware specific, this article applies to Stream VMs as well. The general guidance in the article also applies to Hyper-V and KVM deployments.
  {% endhint %}

[^1]: For the X29/M29 and X47/M47 appliances, one of the 10 GbE SFP+ ports that are normally used for capture traffic can be configured to be used as a management interface. When configured as such, the original MGT1 copper port would be unused. Please see the quick start guides for these appliances for full details and how to configure the alternate interface configurations.

[^2]: Refers to how many Sensors (physical, virtual, or cloud) an appliance can pair with.

[^3]: Refers to how many hosts the appliance running in Brain or Mixed mode can track simultaneously (open host sessions). Brains can typically retain and display data for larger numbers of hosts, this only refers to how many hosts the system can process metadata for simultaneously.

[^4]: For any appliance that supports SFP interface (SFP+, SFP28, QSFP, QSFP28, etc), please see the SFPs and QSFPs supported in Vectra appliances article on the Vectra support site for additional details and note the following regarding which can be included free as part of your order, or added to your order for an additional cost: Up to 2 (if supported by your appliance model), SFP, SFP+, or SFP28 modules can be included at no additional cost in your appliance order. This is valid for each appliance in your order. Additional SFPs above a count of the two per appliance specified above, will incur additional cost. All 40/100G QSFPs will incur additional cost over the base price of the appliance.

[^5]: For the S1 appliance, both management and capture ports can be configured to use one of the 10 GbE SFP+ ports for either management or capture use. In the default configuration, only the copper interfaces are used. This results in 4 different potential interface configurations for the S1 appliance. Please see the quick start guides for these appliances for full details and how to configure the alternate interface configurations.

[^6]: For the S1v2 one of the 10 GbE SFP+ ports that are normally used for capture traffic can be configured to be used as a management interface. When configured as such, the original MGT1 copper port would be unused.

[^7]: A 2nd power supply can be purchased and used for redundancy.

[^8]: VMware 16-core vSensor storage is shown as `600 GB*` in the source table.

[^9]: This disk has upgraded performance over standard EBS volumes.


# Default usernames and passwords

Default credentials for CLI, Web UI, and IPMI/iDRAC access.

The following table summarizes the default username/passwords for CLI, Web UI, and IPMI/iDRAC access.

{% hint style="info" %}
As of v9.8 software version, users other than the default `vectra` user can be given the permission to login to the CLI of your Vectra appliances. Please see details in [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli).
{% endhint %}

{% hint style="info" %}
IPMI/iDRAC login is still limited to only the `vectra` user as of v9.8.
{% endhint %}

|                |                                                            |                                                           |                                                            |
| -------------- | ---------------------------------------------------------- | --------------------------------------------------------- | ---------------------------------------------------------- |
| Vectra Version | Command Line Interface                                     | Web UI                                                    | IPMI/iDrac¹                                                |
| 5.4 and later  | <p>Username: vectra</p><p>Password: changethispassword</p> | <p>Username: admin</p><p>Password: changethispassword</p> | <p>Username: vectra</p><p>Password: changethispassword</p> |

Note 1: IPMI and iDrac access levels vary by platform according to platform capabilities and security hardening requirements. Dell iDrac access is available on X29 platforms with a serial number starting U22. iDrac access gives basic platform monitoring and operational support capabilities over an IPMI compatible interface.

Note 2: IPMI support formally arrived in the 5.4 release. The IPMI and iDrac passwords varied by platform and version prior to the 5.4 release. If you require IPMI access to a system running a version prior to this release please contact Vectra Support for assistance.

Note 3: vSensor images will have Sensor password from the Brain built-in, if this option is configured.


# IPv6 management support for Vectra appliances

Review IPv6 management support for Vectra appliances running version 8.5 or later.

## Applicability

IPv6 management of Vectra appliances is supported in versions 8.5 and above.

There are 3 main categories of appliances (physical, virtual, and cloud). "Cloud" appliances are also virtual, but for the purposes of this article, a cloud appliance is a Brain or Sensor deployed in a public cloud such as AWS, Azure, or GCP.

Please see the table below for IPv6 support by appliance category:

|                                   |                                                                      |                      |
| --------------------------------- | -------------------------------------------------------------------- | -------------------- |
| **Appliance Category**            | **Example Appliance Models (not all are listed)**                    | **IPv6 MGT Support** |
| Physical                          | S1, S11, S101, X29, B101, etc                                        | Yes                  |
| Virtual (Traditional Hypervisors) | VMware Brain/Sensor, Hyper-V Sensor, Nutanix Sensor, KVM Sensor, etc | Yes                  |
| Cloud (Supported Public Clouds)   | AWS Brain/Sensor, Azure Brain/Sensor                                 | **No**               |

## Enabling/Disabling IPv6 Support

The use of IPv6 for management of Vectra appliances is not enabled by default. It is controlled by a feature flag that must be set by the customer before an IPv6 address can be assigned.

To enable IPv6 support on an already running Vectra appliance, log in to the appliance as the `vectra` user using any supported method. Supported methods are detailed in [Console access on Vectra Cognito appliances](/deployment/appliance-operations/console-access-on-appliances). Users other than the `vectra` user can be used in v9.8 and higher (see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) for details).

The following commands can be used to enable and disable IPv6 support for MGT1 as well as check the status.

```language-markup
# show ipv6 enabled
IPv6 is disabled

# set ipv6 enabled
Response: ok

# show ipv6 enabled
IPv6 is enabled

# set ipv6 disabled
Response: ok
```

{% hint style="info" %}
After changing the feature flag status with the above commands, there are some back end processes that need to complete. The status of the feature flag will update immediately, but if a `show interface` command was used and you were set to DHCP in a dual stack environment, it may not be immediate that you see both the IPv4 and IPv6 addresses being output as a result. If it has been more than 5 minutes and the expected results are not being displayed, a support ticket should be opened.
{% endhint %}

## Dual Stack Support

Supported appliances can be used as IPv6 only, IPv4 only (default), or in dual stack mode. Please note the following about dual stack support

* In an IPv6 only environment, the customer network must have NAT64 and DNS64 available so that the Brain appliance can reach Vectra services because Vectra services are IPv4 only in Vectra's cloud.
  * This is not required for air gap deployments.
  * **NAT64** - Network Address Translation IPv6 to IPv4 (NAT64) translates IPv6 packets to IPv4 packets and vice versa. When an IPv6-only host wants to communicate with an IPv4 destination, the NAT64 device translates the IPv6 packets to IPv4 and forwards them to the IPv4 destination. When the response comes back, it translates the IPv4 packets back to IPv6 and sends them back to the IPv6-only host.
  * **DNS64** - DNS64 is used in conjunction with NAT64. When an IPv6-only host wants to resolve the IPv4 address of a domain name (which only has IPv4 records), the DNS64 server synthesizes an AAAA record (IPv6 address) using the IPv6 prefix of the NAT64 device and the IPv4 address obtained from the DNS A record. This synthesized AAAA record allows the IPv6-only host to communicate with IPv4-only servers via the NAT64 device.
* In an environment that supports both IPv4 and IPv6, please note the following:
  * Both the IPv4 and IPv6 stacks must be set to Static or DHCP, you cannot have one be Static and the other be DHCP.
  * When DHCP is configured using the `set interface` command, both stacks are automatically set to DHCP.
  * When setting a static IP using the `set interface` command, you must execute the command twice to set a static IP for each stack.
    * Set the IPv4 stack to a static IP using the syntax for an IPv4 address.
    * Set the IPv6 stack to a static IP using the syntax for an IPv6 address.
* If an IPv4 destination is configured for a supported integration or for pairing a Sensor to a Brain for example, the IPv4 stack will be used to initiate the connection in dual stack environments. Similarly, if an IPv6 destination is used for an integration or pairing, the IPv6 stack will be used to initiate the connection.

## Pairing Considerations

When a Sensor is paired to a Brain, it is a one to one mapping and the pairing will be specific to the stack that the pairing was done from (see Dual Stack Support above). In other words, you will be paired using IPv4 or IPv6, not both. If one network becomes unavailable, there is no automatic fallback to the other network. It is suggested to pair by hostname instead of IP to make failover scenarios easier to deal with.

## VMware Brains and vSensors

VMware Brains and Sensors are capable of automatically enabling the IPv6 feature flag and deploying directly with IPv6 support enabled if an IPv6 address is configured for the MGT interface when deploying the appliance. If dual stack support is desired, you must still configure the 2nd stack in the same manner described in the Dual Stack Support section above.

## MGT2 IPv6 Support

Some physical Vectra appliances have a MGT2 port that can be used to connect for console access. Please see more details about using MGT2 to connect to Vectra appliances [here](/deployment/appliance-operations/console-access-on-appliances). MGT2 defaults to an IPv4 address but can be configured to an IPv6 address if required. When IPv6 is enabled, there is no default IPv6 address assigned to MGT2. To configure MGT2 with an IPv6 address:

* Ensure IPv6 is enabled (see above).
* Use the `set interface mgt2` command to set a static IP for MGT2.

## Set Interface Command Details

For full details, please see: [Configuring the IP address of a new Brain or Sensor](/deployment/appliance-operations/configuring-ip-settings-for-appliances)

Once logged in to the appliance you can view command syntax for the `set interface` command as shown:

```ckeditor_codeblock
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]

  Sets network interfaces to either dhcp or static ip configuration

Options:
  -h, --help  Show this message and exit.
```

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```ckeditor_codeblock
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y

Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway

IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]

Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

## Additional Examples and the "Unset" Command

Imagine all of the commands were run, one after the other in this section.

* 1st we set DHCP and since we have both IPv4 and IPv6 DHCP in the environment, we now have a dual stack configuration.
* We then set MGT1 to a static IPv4 address and have moved to a single stack configuration.
* We then set MGT1 to a static IPv6 address and now we have a dual stack configuration.
* We then unset the IPv6 address and have moved back to a single stack IPv4 configuration.

### **Setting MGT1 to DHCP mode in a dual stack network and then showing the interface configuration**

```language-markup
vscli > set interface mgt1 dhcp
Interfaces updated successfully

vscli > show interface
mgt1:
    Running:
        Carrier: 1,
        Gateway: 172.16.48.1,
        Gatewayv6: fe80::250:56ff:fea2:94e7,
        Ip: 172.16.48.88,
        Ipv6: 2001:db8:6:0:250:56ff:fea2:e6f0,
        Mac: 00:50:56:a2:e6:f0,
        Mode: dhcp,
        Netmask: 255.255.255.0,
        Netmaskv6: ffff:ffff:ffff:ffff::/64,
        Speed: 10000
```

### **Setting MGT1 to a static IPv4 address and then setting a static IPv6 address**

Notice that since we moved from DHCP to static, the IPv6 address that was previously configured by DHCP is not configured until it is separately configured by the second use of the set interface command.

```language-markup
vscli > set interface mgt1 static 172.16.48.88 24 172.16.48.1
Interfaces updated successfully

vscli > show interface
mgt1:
    Running:
        Carrier: 1,
        Gateway: 172.16.48.1,
        Ip: 172.16.48.88,
        Mac: 00:50:56:a2:e6:f0,
        Mode: static,
        Netmask: 255.255.255.0,
        Speed: 10000

vscli > set interface mgt1 static 2001:db8:6:0:250:56ff:fea2:e6f0 64 fe80::250:56ff:fea2:94e7
Interfaces updated successfully

vscli > show interface
mgt1:
    Running:
        Carrier: 1,
        Gateway: 172.16.48.1,
        Gatewayv6: fe80::250:56ff:fea2:94e7,
        Ip: 172.16.48.88,
        Ipv6: 2001:db8:6:0:250:56ff:fea2:e6f0,
        Mac: 00:50:56:a2:e6:f0,
        Mode: static,
        Netmask: 255.255.255.0,
        Netmaskv6: 64,
        Speed: 10000
```

### **Using the "unset" command to remove a static assignment**

This is essentially going from a dual stack configuration to a single stack configuration.

```language-markup
vscli > unset static mgt1 ipv6
Interface updated successfully

vscli > show interface
mgt1:
    Running:
        Carrier: 1,
        Gateway: 172.16.48.1,
        Ip: 172.16.48.88,
        Mac: 00:50:56:a2:e6:f0,
        Mode: static,
        Netmask: 255.255.255.0,
        Speed: 10000
```


# IDR for Azure AD & CDR for M365

Deployment quick start guide for both IDR for Azure AD & CDR for M365 covering both RUX and QUX deployments.

## Introduction

It takes less than 10 minutes to set up data sources for Vectra’s CDR for M365 and IDR for Azure AD products. Once up and running, you will be able to see and stop attackers from abusing identities in Azure AD and M365. This document walks you through the steps for either a Respond UX (RUX) or Quadrant UX (QUX) deployment.

{% hint style="info" %}
**Please Note:**

Vectra’s CDR for M365 and IDR for Azure AD are licensed Vectra products. Please ensure you have the appropriate licenses before enabling the M365 and Azure AD data source or are engaged in a trial with your Vectra AI account team. If you are not licensed or in a trial, please contact your Vectra AI account team to initiate a trial.

* CDR for M365 was formerly known as Detect for M365.
* IDR for Azure AD was formerly known as Detect for Azure AD.
  {% endhint %}

**The process is easy:**

1. Create a data source connector in your Vectra UI.
2. Grant Vectra read-only access to your Azure AD and M365 data logs
   * Global Administrator permissions are required.

{% hint style="info" %}
**Please note:** The user needs to be a true Global Administrator and not receive the permissions via group membership.
{% endhint %}

{% hint style="warning" %}

* QUX Customers:
  * You must complete the [Network Setup](#network-setup-qux-only) before the [Onboarding](#onboarding).
* RUX UX Customers:
  * You can proceed directly to the [Onboarding](#onboarding).
* Please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux) if you are usure of your deployment type.
  {% endhint %}

{% hint style="info" %}
**Please Note:**

* If you are using a proxy to connect to the internet and the proxy you are using does not support CORS, then the connection setup link may not work.
* If you are currently using QUX and planning to migrate to RUX, be aware that the M365 sensor will only be automatically migrated when the RUX tenant was provisioned in the same region that your existing data source connector is deployed in. Otherwise, you will must to deploy a new connector in the region where the RUX tenant was deployed and a new seven day learning period will be required.
  {% endhint %}

Additional Information related to the following topics are presented at the end of this document.

* [Summary of Data and Access Requirements](#summary-of-data-and-access-requirements)
* [Opting Out of CDR for M365 and IDR for Azure AD](#opting-out-of-cdr-for-m365-and-idr-for-azure-ad)
* [Modifying Vectra’s OAuth Application Settings](#modifying-vectras-oauth-application-settings)
* [Detection Learning Times](#detection-learning-times)
* [Worldwide Support Contact Information](#worldwide-support-contact-information)

## Network Setup (QUX only)

This is only required for customers using the Quadrant UX. For customers using the Respond UX, there is no need to complete network setup.

Your Vectra Brain must be able to securely access Vectra’s managed resources over TCP/443 HTTPS connections to report detection events to your Vectra UI. Please configure your firewall and access rules accordingly.

{% hint style="info" %}
**Please Note!**

During initial configuration, ALL endpoints in the below chart must be allowed, after the data source connector is deployed, the endpoints not associated to the region of your deployment can be blocked.

This is because the data source connector dialog must populate the dropdown with the available choices and needs connection to them to display them. Only the selected region is actually used in your deployment.
{% endhint %}

<table data-header-hidden><thead><tr><th width="298.98046875"></th><th width="183.87109375" align="center"></th><th width="264.87890625"></th></tr></thead><tbody><tr><td><strong>FQDN Specific FW Rules</strong></td><td align="center"><strong>IP Specific FW Rules</strong></td><td><strong>Required For</strong></td></tr><tr><td>https://authgateway.uw2.public.app.prod.vectra-svc.ai/</td><td align="center"><p>54.245.33.175</p><p>52.42.70.176</p><p>100.21.109.72</p><p>52.26.91.157</p></td><td>Data Sources deployed in US</td></tr><tr><td>https://authgateway.ew1.public.app.prod.vectra-svc.ai/</td><td align="center"><p>54.171.40.108</p><p>54.246.213.148</p><p>54.75.47.147</p></td><td>Data Sources deployed in EU</td></tr><tr><td>https://authgateway.ec2.public.app.prod.vectra-svc.ai</td><td align="center"><p>16.62.18.237</p><p>16.62.142.98</p><p>51.96.54.201</p></td><td>Data Sources deployed in Switzerland</td></tr><tr><td>https://authgateway.cc1.public.app.prod.vectra-svc.ai/</td><td align="center"><p>3.96.112.208</p><p>52.60.211.221</p><p>15.222.69.161</p></td><td>Data Sources deployed in Canada</td></tr><tr><td>https://authgateway.as2.public.app.prod.vectra-svc.ai/</td><td align="center"><p>13.54.11.66</p><p>13.55.79.24</p><p>13.55.106.102</p></td><td>Data Sources deployed in Australia</td></tr></tbody></table>

## Onboarding

### Connection Setup

Move through the following steps to create a Data Source Connector in your Vectra UI.

{% stepper %}
{% step %}

### Start Creating Data Source Connector

* Navigate to *Configuration → Data Sources → Azure AD & M365*.
* Click **+ Create Azure AD & M365 Connection**

<figure><img src="/files/hNpKCUN9T7kYqFfrLpab" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Create Data Source Connector

* For both RUX and QUX deployments, choose your **API Endpoint Type**.
  * Standard, GCC, or GCC High
* Only QUX deployments will be presented with a **Region** selection box.
  * Please provide the region where data should reside.
    * Note that all Vectra data source connectors must reside in the same geographic region.
  * Respond UX customers do not need to select a region because one was already selected during initial setup of their RUX tenant.
* Provided a name for your connector and then **Create & Continue**.

<figure><img src="/files/1XSVfFOX017PXErROW53" alt="" width="563"><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Copy the "Connection Setup Link"

* Click the **Copy** link to copy the connection setup link so that you can provide it to a Global Administrator to authorize read-only access to your data.
* You can click **Save**, to save your connection and move on to [authorize read-only data access](#authorize-read-only-data-access).

{% hint style="warning" %}
**Please note**: If you are using a proxy to connect to the internet and the proxy you are using does not support CORS, then the connection setup link may not work.
{% endhint %}

<figure><img src="/files/H0XQPdUOPhl9PNSzNtSM" alt="" width="563"><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}

### Authorize Read-Only Data Access

After completing the [connection setup](#connection-setup), have your **Azure AD Global Admininistrator** follow the **Connection Setup Link** you copied earlier and authorize Vectra to collect logs.

{% stepper %}
{% step %}

### Continue and grant access

* Simply click the **Continue and grant access** button to begin authorizing Vectra to collect logs.

{% hint style="info" %}
If you are not already logged in, you will be asked to login.
{% endhint %}

<figure><img src="/files/6CGUlG2gklMu4xvw0ar5" alt="" width="563"><figcaption></figcaption></figure>
{% endstep %}

{% step %}

###

* Review the read-only access required by the **Vectra AI - IDR for Azure AD and CDR for M365** Enterprise Application (Service Principal) to validate your permissions.
  * `ActivityFeed.Read` (Office Management API)
  * `ActivityFeed.ReadDLP` (Office Management API)
  * `Directory.Read.ALL` (Graph API for Azure AD logs)
  * `AuditLog.Read.All` (Graph API for Azure AD logs)
  * `User.Read`
    * Added by default by Microsoft – this is not part of the ongoing app permissions, it is used only during this initial consent flow.
* Click **Accept** and you are done with the configuration.

<figure><img src="/files/tpPDBjWz9IqXdCpJ53m7" alt="" width="367"><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}

### Validate Data Collection

Once access is authorized the Status for your new data source connector should report **Forwarding**. This status may take 10 to 15 minutes to appear while the initial data is collected.

<figure><img src="/files/964899cd8f2b7c26f456e4f50393960c01862ea9" alt=""><figcaption></figcaption></figure>

## Additional Information

### Summary of Data and Access Requirements

The Management API is used to collect `Audit.AzureActiveDirectory`, `Audit.Exchang`e `Audit.SharePoint`, `Audit.General,` and `DLP.All` logs.

* Auditing via the Management Activity API is required for Vectra to provide coverage:
  * <https://docs.microsoft.com/en-us/microsoft-365/compliance/turn-audit-log-search-on-or-off?view=o365-worldwide>
* Additional details about the data collected can be found here:
  * <https://docs.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema>

The Microsoft Graph API is used to collect `directoryAudits` and `signIns` logs.

* Additional details about the data collected can be found here:
  * <https://docs.microsoft.com/en-us/graph/api/signin-list?view=graph-rest-1.0&tabs=http>
  * <https://docs.microsoft.com/en-us/graph/api/directoryaudit-list?view=graph-rest-1.0&tabs=http>

### Opting Out of CDR for M365 and IDR for Azure AD

If you wish to stop using CDR for M65 and IDR for Azure AD, any Application Admin / Global Admin can delete the application from the **Enterprise Applications** page in the **Microsoft Entra ID** part of the **Azure portal**.

{% stepper %}
{% step %}

### Find the Vectra Enterprise Application

* As an Application Administrator or Global Administrator login to [portal.azure.com](https://portal.azure.com)
* Navigate to **Microsoft Entra ID** and click on **Enterprise applications** from the left navigation bar.
* Search for **Vectra AI**.

<figure><img src="/files/pcRPrpPJoPaNdMUnCI6b" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Delete the App

Click on the **Vectra AI - IDR for Azure AD and CDR for M365** application, then click on **Properties,** and then click on **Delete** to delete the application.

<figure><img src="/files/UeSKYpGp06bkXLnQP7ux" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Remove the Data Source Connector in the Vectra UI

* Once the consent is pulled, the data source connector will report **CONSENT REVOKED** state in the Vectra UI and log collection will stop.
* The Sensor/Connector in the Vectra UI can be deleted before or after the consent is pulled.
  {% endstep %}
  {% endstepper %}

### Modifying Vectra’s OAuth Application Settings

The OAuth application used to collect data has been configured in alignment with Microsoft’s best practices. Changes to the application’s settings can disrupt Vectra’s access to the necessary logs and prevent detections. Customers may change the **Visible to users** toggle to off if desired.

### Detection Learning Times

Vectra uses multiple modeling techniques to detect attacker behaviors in your Azure AD and M365 environment. Some Vectra detections are designed to alert on threats immediately and can find active attacker behaviors in the first few hours of a deployment. Other detections may require an initial baseline period to become operational. All detections complete their initial baseline period after at most seven days. Detections that leverage baselines continue to learn after the initial period and improve their performance over time.


# CDR for AWS

Landing page for CDR for AWS deployment, sizing, and integration guidance.

{% content-ref url="/pages/omBYtqOhy11BXlxrUBxY" %}
[Deployment (CDR for AWS)](/deployment/cdr-for-aws/deployment)
{% endcontent-ref %}

{% content-ref url="/pages/dApCyRPxfPC0vg8PCwlR" %}
[Estimating Log Volume](/deployment/cdr-for-aws/estimating-log-volume)
{% endcontent-ref %}

{% content-ref url="/pages/xZ3sh1NFZGSabcGa3SPK" %}
[Amazon Security Lake Integration](/deployment/cdr-for-aws/amazon-security-lake-integration)
{% endcontent-ref %}


# Deployment (CDR for AWS)

Deploy CDR for AWS with CloudFormation or manual setup, including requirements, permissions, troubleshooting, and cost guidance.

## Demo Deployment Video

Vectra has created a video showing the most commonly used deployment method. In just 7 minutes, Gearóid Ó Fearghaíl from Vectra's Product Management team shows you how to deploy Detect for AWS (video links to Vimeo):

{% embed url="<https://vimeo.com/721173925/99d13ef2a6?share=copy&fl=sv&fe=ci>" %}

{% hint style="info" %}
Also attached to this article are policy files that can be used as examples when configuring AWS manually. See the main document for details.
{% endhint %}

## Attachments

These attachments are policy files that can be used as examples when [deploying CDR for AWS manually](/deployment/cdr-for-aws/deployment/appendix-2-manual-aws-deployment). Please proceed to [architecture and requirements](/deployment/cdr-for-aws/deployment/architecture-and-requirements) to read more about deployment options.

{% file src="/files/xREX9j8mq67FG4B6JAvx" %}

{% file src="/files/YIADeCKdmvfxOfi92OZI" %}


# Architecture and requirements

Intro and overview for CDR for AWS, general requirements, network setup requirements for QUX deployments, and deployment overview.

## Introduction

CDR for AWS offers advanced Threat Detection & Response coverage for your AWS control plane. We leverage AI & ML techniques to monitor all activity in your organization’s global AWS footprint for malicious behaviors.

CDR for AWS leverages CloudTrail logs and contextual IAM information to find malicious activity, and then attribute it to the malicious actor itself using Vectra’s Kingpin technology.

This guide will enable you to set up Vectra’s CloudTrail integration to allow us to offer protection for your organization. CDR for AWS is available in both Vectra’s Respond UX and the Quadrant UX. See [this article](/deployment/getting-started/analyst-ux-options-rux-vs-qux) for UX differences.

## Overview

AWS CloudTrail is a service automatically enabled for all AWS customers at no cost. Most customers create a "Trail" that saves AWS CloudTrail logs to an AWS S3 bucket, from which various consumers can pick up the logs for different use-cases. CDR for AWS leverages this model.

![](/files/c58946585cacdff7a6e53052c9b62d0f1efa9ec0)

* AWS CloudTrail logs events to an S3 bucket.
* Amazon SNS (Simple Notification Service) will be configured to notify Vectra when new logs are available.
* Vectra will then pull the log files from the S3 bucket.
* Vectra processes the management and data events through proprietary algorithms to generate Detections.

Vectra provides an AWS CloudFormation template to automate the setup of SNS and the authorized IAM role.

## General Requirements

* CDR for AWS requires an entitlement for the offering either through a purchase or a trial (POC/POV).
  * Click **See how it works** at [CDR for AWS](https://www.vectra.ai/products/cdr-for-aws) to schedule a demo or [Contact Us](https://www.vectra.ai/about/contact) to arrange a trial.
* CDR for AWS requires that CloudTrail logging to a single S3 bucket be enabled for your AWS account(s).
  * This includes multi-region setups, and we suggest setting up an organizational CloudTrail.
  * This [Getting started with AWS CloudTrail tutorial](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-tutorial.html) provides additional guidance if needed.
* Vectra requires **Management Events** and recommends S3 **Data Events** from AWS CloudTrail.
  * For Management events, AWS KMS events are **NOT** required.
    * The ability to stop logging these events was added by AWS recently and if you already have Trails setup, it is likely that this setting is enabled. You can disable this setting to save costs and reduce noise if you don’t need the data elsewhere. Vectra has determined that these logs don’t contain sufficient security value to justify their added costs.
  * S3 Data Events provide detail for actions within a S3 resource (e.g., objects copied to/from a bucket) and are often high-volume activities. Visibility into these events is pivotal to identify adversaries executing exfiltration or ransomware attacks.
  * S3 Data Events are recommended for all high-value S3 buckets within your organization.
  * For additional guidance on CloudTrail S3 Data Events please see [Guidance on CloudTrail S3 Data Events](/deployment/cdr-for-aws/deployment/appendix-1-aws-configuration-notes#guidance-on-cloudtrail-s3-data-events) and [Enabling and Validating S3 Data Events](/deployment/cdr-for-aws/deployment/appendix-1-aws-configuration-notes#enabling-and-validating-s3-data-events) later in this overall guide.
  * Logging S3 data events may result in higher CloudTrail costs for high usage S3 buckets. Please see [Appendix 4](/deployment/cdr-for-aws/deployment/appendix-4-aws-log-ingestion-cost-estimates) for more detail.
* When deploying in an AWS Region created after 2019 additional steps are required.
  * Please see [Enabling STS in AWS Regions Created After 2019](/deployment/cdr-for-aws/deployment/appendix-3-troubleshooting-issues-while-onboarding#enabling-sts-in-aws-regions-created-after-2019) in Appendix 3 for more detail.

## Network Setup (Quadrant UX deployments only)

This is only required for customers using Vectra’s Quadrant UX. Customers using the Respond UX do NOT need to set firewall rules for this. For more detail about the different UX’s, please see [this article](/deployment/getting-started/analyst-ux-options-rux-vs-qux).

Your Vectra Brain must be able to securely access Vectra’s managed resources over TCP/443 HTTPS connections to report detection events to your Vectra UI. Please configure your firewall rules accordingly.

<table data-header-hidden><thead><tr><th width="298.98046875"></th><th width="183.87109375" align="center"></th><th width="264.87890625"></th></tr></thead><tbody><tr><td><strong>FQDN Specific FW Rules</strong></td><td align="center"><strong>IP Specific FW Rules</strong></td><td><strong>Required For</strong></td></tr><tr><td>https://authgateway.uw2.public.app.prod.vectra-svc.ai/</td><td align="center"><p>54.245.33.175</p><p>52.42.70.176</p><p>100.21.109.72</p><p>52.26.91.157</p></td><td>Data Sources deployed in US</td></tr><tr><td>https://authgateway.ew1.public.app.prod.vectra-svc.ai/</td><td align="center"><p>54.171.40.108</p><p>54.246.213.148</p><p>54.75.47.147</p></td><td>Data Sources deployed in EU</td></tr><tr><td>https://authgateway.ec2.public.app.prod.vectra-svc.ai</td><td align="center"><p>16.62.18.237</p><p>16.62.142.98</p><p>51.96.54.201</p></td><td>Data Sources deployed in Switzerland</td></tr><tr><td>https://authgateway.cc1.public.app.prod.vectra-svc.ai/</td><td align="center"><p>3.96.112.208</p><p>52.60.211.221</p><p>15.222.69.161</p></td><td>Data Sources deployed in Canada</td></tr><tr><td>https://authgateway.as2.public.app.prod.vectra-svc.ai/</td><td align="center"><p>13.54.11.66</p><p>13.55.79.24</p><p>13.55.106.102</p></td><td>Data Sources deployed in Australia</td></tr></tbody></table>

## Deployment Overview

The simplest deployment method is to use a [Vectra provided CloudFormation template](/deployment/cdr-for-aws/deployment/deploy-via-cloudformation). This template automates tasks that would otherwise have to be done manually. Vectra links to this template from the onboarding flow. It is also available via request.

Please see the appendices for guidance on related topics or [deploying manually](/deployment/cdr-for-aws/deployment/appendix-2-manual-aws-deployment). In general, deployment consists of the following steps:

* Creating a CDR for AWS connection in the Vectra UI.
* Creating an SNS topic (or using an existing one) to notify Vectra when new logs are available to retrieve.
* Creating a role in your AWS account to allow Vectra to retrieve logs from the S3 bucket where your CloudTrail logs are located.
* Providing Vectra with the AWS role ARN, S3 bucket location, and SNS topic ARN.
  * Vectra will subscribe the SNS topic to your S3 Bucket after submitting these.

{% hint style="info" %}
**Please Note:**

After the data source connector for AWS CloudTrail has been fully configured, it can take several hours to a day for all AWS related detections to be able to fire and for enrichment (attribution to a specific source account at the bottom of a role chain) to be available for any detections that fire as a result of the new connector. This is because the data source connector might have been activated after the role chain was started and therefore Vectra might not have the full role chain in its forwarded data.
{% endhint %}


# Deploy via CloudFormation

End-to-end steps using the Vectra-provided CloudFormation template.

## Deployment via CloudFormation Template

The CloudFormation template automates the following:

* Creates an AWS IAM role that grants Vectra access to the customer’s AWS account, CloudTrail logs, and S3 bucket.
* Creates an SNS topic and policy.
* Allows the specification of a KMS Key and grants permission for decryption to Vectra.
  * This is optional but is required for customers who are using KMS encryption on their CloudTrail logs.

## Creating a CDR for AWS Connection

**Step 1**

* To create the CDR for AWS Connection, in the Vectra UI, navigate to *Configuration → Data Sources → AWS CloudTrail* and click the **Get Started** button.

![](/files/19ee2c524c315023b655b06086ca95bb30ef3549)

**Step 2**

* Give your connection name.
* Click “Create and Continue”.

<img src="/files/6f8bca80841d3f59c3c68da34ef1b16f0a983e09" alt="" width="563">

**Step 3**

* Please ensure that you are logged into the AWS account that you will deploying into.
* In your Vectra UI, select the region containing your S3 bucket - **Region where your AWS data resides**.
  * The CloudFormation script needs to run in the same region that contains your CloudTrail log bucket.
  * Please see [CloudTrail Log S3 Bucket Location and Region](/deployment/cdr-for-aws/deployment/appendix-1-aws-configuration-notes#cloudtrail-log-s3-bucket-location-and-region) in [Appendix 1](/deployment/cdr-for-aws/deployment/appendix-1-aws-configuration-notes) for details.
* Click on the **Run this CloudFormation script to connect your S3 bucket in \<region>** link.
  * An admin for your AWS account will be needed to execute this script.
  * If you are not authorized to run this script yourself, copy the link and supply it to a user who can.
  * After successfully running the script, you will return here to complete and authorize the configuration.

<img src="/files/cde6f21939acdc755d58abbf69710a75264453c0" alt="" width="563">

### CloudFormation Template Configuration

**Step 1**

You will be brought to CloudFormation on the **Stack Details** page with some information already filled in.

![](/files/c79387ba66239f9825800cde62db6d5d5dbff92a)

**Fill in the rest of the information required on this page:**

**CloudTrailS3BucketName**

* This is the only field that is required.
* **CloudTrailS3BucketName** – The S3 bucket that contains the CloudTrail logs.

The other fields are:

**Stack name** – Name for the AWS Stack.

* A default is provided, but this can be changed as desired within the syntax limitations of AWS.

**ExternalId** – A unique identifier for you as a customer in Vectra.

* This is created automatically for you by Vectra and should not be changed.

**KMSKey** – (Optional).

* If you use KMS to encrypt your CloudTrail logs, enter the ARN of the KMS key here.
* Leave empty if your CloudTrail logs are unencrypted.
* See [KMS Encrypted S3 Bucket Support](/deployment/cdr-for-aws/deployment/appendix-1-aws-configuration-notes#kms-encrypted-s3-bucket-support) in [Appendix 1](/deployment/cdr-for-aws/deployment/appendix-1-aws-configuration-notes) support for more details

**SNSTopicForS3Events** – (Optional).

* If you already have an SNS Topic configured for your S3 bucket, simply enter its ARN here.
  * The SNS topic needs to be deployed in the same region as the S3 bucket that contains your CloudTrail logs.
* If you do not already have an SNS Topic configured, the CloudFormation script will create one for you if you leave this empty.

**VectraAccountId** – Vectra’s AWS account ID (provided by CF template).

* We will assume the role to pull the log data from this account.
* Do not change this value.

**VectraIAMRoleName** - The name of the role which we will create in your Account to access CloudTrail Logs.

* A default name is provided but you can change this name if you wish.
* Click the checkbox acknowledging that AWS CloudFormation might create IAM resources with custom names.
* Click **Create stack**.

**Step 3**

* After the stack creation is complete, navigate to the **Outputs** tab of the stack and make note of the **CloudTrail S3 Bucket Name**, **SNS Topic for S3 Events ARN**, and **Vectra IAM Role ARN**.
  * These will be needed in the **Completing the Deployment in the Vectra UI** section below.
  * Specifically, Vectra needs the items in the **Value** column to be copied exactly as displayed.

![](/files/0205800cbd2ba983720b6da83714cc564273d6a1)

### Completing the Deployment in the Vectra UI

* After CloudFormation has completed the Stack, enter the output information you just gathered into the CDR for AWS UI and click **Authorize**.

<img src="/files/8734f14c770a150ad4b223540ff08c65a8e89a42" alt="" width="563">

![](/files/0cd722b65fc9e1d8aeec5b3cd186e428820613de)

{% hint style="success" %}
After entering the information and clicking **Authorize**, you have completed the configuration. The deployed Connection will be in a **Authorization in Progress** state until Vectra’s cloud is successfully retrieving logs.

**Please Note:**

After the data source connector for AWS CloudTrail has been fully configured, it can take several hours to a day for all AWS related detections to be able to fire and for enrichment (attribution to a specific source account at the bottom of a role chain) to be available for any detections that fire as a result of the new connector. This is because the data source connector might have been activated after the role chain was started and therefore Vectra might not have the full role chain in its forwarded data.
{% endhint %}


# Appendix 1 - AWS Configuration Notes

Required permissions, data events guidance, bucket location, and KMS notes.

## The Permissions Vectra Requires in your AWS Account

Vectra requires specific read-only permissions to monitor your AWS account. These permissions allow us to monitor your CloudTrail logs and contextual information.

### Vectra AWS IAM Role

In order for Vectra to access required information in your AWS account, an IAM role will need to be created for Vectra in your AWS account that grants Vectra external access. Your AWS account must be the account that contains the S3 bucket where your CloudTrail logs are stored. Access can be limited to our AWS account exclusively, and a required External ID provides another layer of security. Vectra will assume this role when pulling any information from your AWS account. The role for Vectra will need to allow access from a Vectra AWS account provided during the setup flow. Vectra’s role does not need access to any other account in your organization.

### About AWS External IDs

External IDs are uniquely associated with roles that are created to allow 3<sup>rd</sup> parties such as Vectra to access your organization’s AWS resources. This will be a secret identifier that will be known by both you and Vectra. You specify the ID when defining the trust policy for the role, and Vectra provides the ID when assuming the role. In any deployment method, Vectra creates the External ID for you, and it should not be changed. For additional information about creating AWS IAM roles and External IDs see the following AWS articles:

* [Creating a role to delegate permissions to an IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)
* [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)
* [How to use an external ID when granting access to your AWS resources to a third party](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)

### The Permissions required for Vectra CDR for AWS to Work Effectively

The role you create for Vectra in your AWS account will need some permissions to access specific data. These permissions are created automatically as part of the CloudFormation Template we offer in the setup process. Otherwise, you will need to manually add these permissions to the role you will grant Vectra access to.

#### List of Permissions

The table below explains the exact reason that each permissions is required:

| **Permission**            | **Comment**                                                                                                                                          | **Scope**                                      |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- |
| s3:GetObject              | This permission allows us to pull CloudTrail log data from the S3 bucket you specify.                                                                | The CloudTrail S3 bucket                       |
| s3:ListBucket             | This permission allows us to list the objects within an S3 bucket                                                                                    | The CloudTrail S3 bucket                       |
| s3:GetBucketNotification  | This allows us to confirm the SNS configuration of the customer’s S3 bucket is correct                                                               | The CloudTrail S3 bucket                       |
| s3:PutBucketNotification  | This allows us to add an SNS topic to the customer’s S3 bucket. This is optional if you already have a SNS notification topic setup for your bucket. | The CloudTrail S3 bucket                       |
| sns:Subscribe             | This allows us to subscribe our CDR for AWS Service to SNS updates from your CloudTrail S3 bucket                                                    | Your SNS topic                                 |
| sns:Unsubscribe           | This allows us to unsubscribe our service if you choose to delete our integration from the Vectra UI. Optional but recommended.                      | \*                                             |
| cloudtrail:GetTrail       | This allows us to get information about the CloudTrail logs that you have                                                                            | \*                                             |
| cloudtrail:ListTrails     | This allows us to get information about the CloudTrail trails that you have.                                                                         | \*                                             |
| cloudtrail:GetTrailStatus | This allows us to get information about the CloudTrail trails that you have.                                                                         | \*                                             |
| cloudtrail:DescribeTrails | This allows us to get information about the CloudTrail trails that you have                                                                          | \*                                             |
| kms:Decrypt               | This permission is only required if your CloudTrail S3 bucket is encrypted with KMS                                                                  | The KMS key used for your CloudTrail S3 bucket |
| iam:ListAccountAliases    | This permission allows us to offer better context around our detections                                                                              | \*                                             |
| iam:ListUsers             | This permission allows us to offer better context around our detections                                                                              | \*                                             |
| iam:ListRoles             | This permission allows us to offer better context around our detections                                                                              | \*                                             |

Vectra requires the Amazon Resource Name (ARN) for the role you have created, the S3 bucket you would like us to pull CloudTrail logs from, and the ARN for the SNS topic we will subscribe to.

## Guidance on CloudTrail S3 Data Events

S3 data events provide visibility into data plane activities within AWS S3. They cover actions within a S3 resource (e.g., objects copied to/from a bucket) and are often high-volume activities. Visibility into these events is pivotal to identify adversaries executing exfiltration or ransomware attacks.

Vectra currently recommends enabling only S3 data events for **all high-value** S3 buckets within your organization. This is in addition to the required management events discussed previously. In general, Vectra does not recommend logging data events for high use public or development buckets that contain no valuable data. S3 data events can be enabled for all buckets or specific buckets.

Please see [Appendix 4 – AWS Log Ingestion Cost Estimates](/deployment/cdr-for-aws/deployment/appendix-4-aws-log-ingestion-cost-estimates) for additional guidance on data event costs and lifecycle management of these events.

## Enabling and Validating S3 Data Events

To enable logging of S3 data events, you must create a new trail or reuse an existing trail and configure it to log S3 data events. To validate that you have this configured, follow the steps below but stop at step 3a.

1. First, sign in to the AWS Management Console and open the Amazon CloudTrail console at [https://console.aws.amazon.com/cloudtrail/](https://console.aws.amazon.com/cloudtrail/trails) and select **Trails** in the left-hand panel.
2. In the Trails list, choose the name of the Trail.
3. Scroll down to **Data events**.
   1. If data events are already enabled, line items with details of the S3 bucket and enabled operations will be visible.
   2. If data events are not enabled, click the **Edit** button to enable the Trail to log data events. Instructions can be found in [Enabling CloudTrail event logging for S3 buckets and objects](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html).

{% hint style="warning" %}
Please Note:

Vectra requires centralization of CloudTrail logs. All management events and data events must be stored in the same S3 bucket. If your organization chooses to adopt multiple trails for logging, all trails must be configured to deposit logs into the same S3 bucket configured for the Vectra CDR for AWS connection.
{% endhint %}

## CloudTrail Log S3 Bucket Location and Region

Regardless of the chosen deployment method (CloudFormation Template or manual), Vectra will need the location of your S3 bucket (including Region) that is being used to store the CloudTrail logs. Your CDR for AWS connection must be deployed in the same Region that houses the S3 bucket storing your CloudTrail logs. Please see the steps below to find this location:

* Navigate to the AWS CloudTrail service and click on **Trails**.
* Find the Trail containing your AWS Management and Data Events.
* Make note of the S3 bucket name and Region so that it can be provided during setup.
  * See the example below of which fields to make note of:

![](/files/9c4f2c34b37a77528cd0c7b3aefd4f4e08c6924d)

## KMS Encrypted S3 Bucket Support

CDR for AWS supports the use of KMS encrypted S3 buckets. The KMS key must be provided to Vectra in the CloudFormation template or if you are doing manual AWS configuration, you must give the Vectra IAM role `kms:Decrypt` permissions against the specific KMS key used for your S3 bucket. Vectra simply requests the log data from S3 after notification via SNS and AWS does the decryption call against KMS as required.

Architecture with KMS Encryption

![](/files/1ae060ae95c96b0090c5a6ffac79f24e68bebc6a)

Additional AWS KMS Information

* Additional general documentation about the AWS Key Management Service is available here:
  * <https://docs.aws.amazon.com/kms/index.html>
* Using AWS S3 Bucket Keys.
  * <https://docs.amazonaws.cn/en_us/AmazonS3/latest/userguide/bucket-key.html>
* Finding the Key ID and ARN.
  * Navigate in AWS to *CloudTrail > Trails > Your specific Trail > AWS KMS Key* and copy it for use with the CloudFormation template.

![](/files/bee70380b6d4e052581acecc7e8289fe04f46706)

* Vectra does not currently support decrypting data with different KMS keys being used in the same S3 bucket.
  * Please get in touch with us if this is a requirement for your organization.


# Appendix 2 - Manual AWS Deployment

Create the SNS topic and IAM role yourself, then authorize in Vectra.

## Creating a CDR for AWS Connection

**Step 1**

* To create the CDR for AWS Connection, in the Vectra UI, navigate to *Data Sources > AWS CloudTrail* and click the **Get Started** button.

![](/files/19ee2c524c315023b655b06086ca95bb30ef3549)

**Step 2**

* Give your connection name.
* Click **Create and Continue**.

<img src="/files/6f8bca80841d3f59c3c68da34ef1b16f0a983e09" alt="" width="563">

## Manual AWS Configuration

<img src="/files/f3e81b0157ee3eb564f5a033b7ba358929edc315" alt="" width="563">

**Step 1**

* Click the dropdown **Create roles manually**.
* Make note of **Vectra’s AWS Account ID** and **External ID** that has been provided for you.
  * You will need these to create a working AWS IAM role.
* You are currently reading the **CDR for AWS Deployment Guide** (formerly known as Detect for AWS) that is mentioned below the Account ID.

**Step 2**

In this step we will be creating an AWS Simple Notification Service (SNS) topic that Vectra can subscribe to. An existing topic can be re-used if one already exists. This must be in the same region as the S3 bucket that contains the CloudTrail logs.

* Navigate to the SNS service in AWS.
* Select **Topics**.
* Click **Create Topic** and fill in the following information:
  * Select the **Standard** type.
  * Give it a name.
  * Ensure that encryption is disabled (this is the default).
  * Open the Access Policy section and select the **Advanced** type.
  * Remove any sample policy and paste in the below, JSON formatted, SNS Topic Policy.
  * Click **Create topic**.
* Make note of the ARN in your newly created topic so that it can be provided during setup.

P→lease note that Vectra will automatically subscribe this SNS topic to your CloudTrail S3 bucket when you complete the deployment in the Vectra UI, so you do not need to perform that action manually.

{% hint style="info" %}
**Please Note:**

Example policies below are also available to download as [attachments to this article](/deployment/cdr-for-aws/deployment).
{% endhint %}

**SNS Topic Access Policy for Step 2**

```
{
  "Version": "2012-10-17",
  "Id": "SNSPolicyDocument",
  "Statement": [
    {
      "Sid": "allowS3ToPublish",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "*"
    }
  ]
} 
```

**Step 3**

* Create an AWS IAM role (using the External ID provided) for Vectra to use for the CDR for AWS service.
* Make note of the ARN for the role so that it can be provided during setup.
  * The ARN for the role can be found in *AWS IAM → Roles → The role you created for Vectra → Role ARN.*

**Required Role Permissions for Step 3:**

* Account information in IAM
  * `iam:ListAccountAliases`
  * `iam:ListUsers`
  * `iam:ListRoles`
* CloudTrail log S3 bucket permissions
  * `s3:GetObject`
  * `s3:GetBucketNotification`
  * `s3:ListBucket`
  * `s3:PutBucketNotification`
* SNS Topic information
  * `sns:Subscribe`
  * `sns:Unsubscribe`
* CloudTrail information
  * `cloudtrail:GetTrail`
  * `cloudtrail:ListTrails`
  * `cloudtrail:GetTrailStatus`
  * `cloudtrail:DescribeTrials`
* KMS decryption permissions exclusively for the KMS key encrypting
  * `kms:Decrypt`

**Sample IAM Role Policy for Step 3**:

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "arn:aws:kms:us-west-2:AWSACCOUNT:key/UUID",
            "Effect": "Allow"
        },
        {
            "Action": [
                "iam:ListAccountAliases",
                "iam:ListUsers",
                "iam:ListRoles",
                "cloudtrail:GetTrail",
                "cloudtrail:ListTrails",
                "cloudtrail:GetTrailStatus",
                "cloudtrail:DescribeTrails",
                "sns:Unsubscribe"
            ],
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "s3:GetObject",
                "s3:GetBucketNotification",
                "s3:ListBucket",
                "s3:PutBucketNotification"
            ],
            "Resource": [
                "arn:aws:s3:::aws-cloudtrail-logs-example",
                "arn:aws:s3:::aws-cloudtrail-logs-example/*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "sns:Subscribe"
            ],
            "Resource": "arn:aws:sns:us-west-2:AWSACCOUNT:vectraStack-SnsTopic-ARN",
            "Effect": "Allow"
        }
    ]
}
```

## Completing the Deployment in the Vectra UI

After creation of IAM roles and SNS Topic either via CloudFormation template or manually, the following information will need to be entered into the Vectra UI to complete the deployment:

* SNS topic ARN
* ARN for the role
* S3 Bucket

<img src="/files/73a809e085fdb7b60246943b24e649fe1b451ed3" alt="" width="563">

![](/files/62fc682ec1c10b7f572896791a522fc96b59f856)

{% hint style="success" %}
After entering the information and clicking **Authorize**, you have completed the configuration. The deployed Connection will be in a **Authorization in Progress** state until Vectra’s cloud is successfully retrieving logs.
{% endhint %}


# Appendix 3 – Troubleshooting Issues While Onboarding

Common errors during CloudFormation/manual setup and how to resolve them.

During onboarding, a number of issues may arise. These may occur during the CloudFormation setup step, or they may occur after finishing the connection setup.

## CloudFormation Link is Malformed

In some cases, where CloudFormation links are sent via Teams chat, the URL becomes malformed, and the fields will not correctly copy over from Vectra Detect. In these cases, you can enter the field values manually by copying them from the manual entry section.

Some customers may also utilize URL rewriting that can be applied to links sent via email and other methods. In rare cases, URL rewriting and subsequent decoding can impact the integrity of the URL. If you have issues with the URL, please compare the original URL as copied and the subsequent URL after decoding in an editor that shows all formatting to eliminate any potential malformation.

## CloudTrail S3 Bucket has Pre-existing Event Notifications Enabled

In the case where your CloudTrail S3 Bucket already has a subscription to it, then you will need to perform some small work to support this.

If the pre-existing event notification is an SNS topic, then Vectra can subscribe to this same SNS topic, just specify the SNS topic ARN in the CloudFormation setup step or reference it in the credential submission step if following the manual flow.

If the pre-existing event notification is an SQS topic, then you should:

* Create a new SNS topic.
* Subscribe your existing SQS topic to your new SNS topic.
* Unsubscribe your SQS topic from your S3 bucket.
* Subscribe your new SNS topic to the S3 bucket.
* Reference this new SNS topic in the CDR for AWS Setup.

This may result in a short downtime in event notifications going to your SQS topic. If this is unacceptable, bucket replication may be a feasible solution instead.

## Connection Error Messages

You may see **Logs not flowing** or other error messages from an AWS CloudTrail connection. You can hover over this message to see the full reason. Some are self explanatory, while others have additional guidance below:

**We could not subscribe the SNS topic to your CloudTrail S3 bucket, please confirm the Vectra role has the required permissions.**

**We were not able to fetch logs from the CloudTrail S3 bucket, please confirm the Vectra role has the required permissions to access or decrypt this data.**

**Invalid IAM Role. Please check that the External ID and Vectra's AWS Account ID were correctly entered in AWS.**

* If the details are correct, please try the following:
  * The IAM role may not be configured correctly.

    Review the [The Permissions Vectra Requires in your AWS Account](/deployment/cdr-for-aws/deployment/appendix-1-aws-configuration-notes#the-permissions-vectra-requires-in-your-aws-account) and correct any misconfigurations in the IAM role and then resubmit the details in the AWS data source connector.

    To resubmit the details, edit the connector, re-add the details, and click **Save**.

**The SNS topic is not in the same region as the S3 bucket. Please ensure the CloudFormation script runs on the same region that the S3 bucket was created on, or if it was created manually, make sure to create the SNS topic on the same region.**

**Unable to add SNS topic subscription to this S3 bucket due to a pre-existing subscription. Please specify this in the CloudFormation setup, otherwise, follow instructions in the CDR for AWS Deployment Guide.**

* See the pre-existing notifications section above.

**We weren't able to subscribe to the SNS topic specified, please confirm the Vectra role has the required permissions.**

**Something went wrong with the connection to AWS. Contact Vectra support to fix this issue.**

**Logs Flowing, but Filtering Detected**

* If you see this status message, it means that the connection is successful, and Vectra is now processing CloudTrail logs.
* However, we have noticed that a filter is applied to this SNS topic, which means that we may not be notified of all new CloudTrail logs being added to your S3 bucket.
* Frequently, this is caused by a filter on the SNS topic which specifies only to alert for files in the CloudTrail format of `json.gz`, but we would recommend confirming this.
* If the filter is limiting which CloudTrail log data we are notified of, your security coverage will be reduced.

## Enabling STS in AWS Regions Created After 2019

Session tokens from the global AWS Security Token Service (STS) endpoint are not valid in AWS Regions created after 2019 by default. The resolution is to change the region compatibility of session tokens for global endpoints to **Valid in all AWS Regions** if you will deploy in any of the following Regions (AWS could add additional Regions to this list in the future).

* Africa (Cape Town)
* Asia Pacific (Hong Kong)
* Europe (Milan)
* Middle East (Bahrain)

To enable or check the status of STS for your Region:

* In the IAM Console, navigate to **Account Settings** under **Access Management**.
* Navigate to **Security Token Services (STS)**.
* Find the **Global endpoint** option.
* Check if this is **Valid in all AWS Regions** or **Only valid in AWS Regions enabled by default**.
* Select **Valid in all AWS Regions** if needed and **Save Changes**.


# Appendix 4 – AWS Log Ingestion Cost Estimates

CloudTrail, S3, SNS, data events, retention, and transfer costs.

You will incur some costs outside of Vectra's pricing as part of this solution, these costs should be quite small.

For a medium sized organization who have Management & Data events enabled, we estimate around 300GB of CloudTrail logs per month will be generated. The total costs for this much log data should be \~$22.80 per month.

## AWS CloudTrail Management Events

AWS CloudTrail records management that happen on your system, and Vectra uses these events to detect malicious activity.

CloudTrail is free for your first copy of management events, and is $2.00 per 100,000 extra copies of management events.

For a medium sized organization, generating around 300GB of CloudTrail logs per month, the total cost would be $12.

## S3 Bucket Storage

CloudTrail logs events to an S3 Bucket, and you will need to pay for storage and API requests.

CloudTrail will make an API call to S3 every 5 minutes, 8760 per month. Vectra will also make GET requests at a similar speed. This will cost $0.10 per S3 CloudTrail log.

S3 Storage itself costs $0.0023 per GB per month.

For a medium sized organization, generating around 300GB of CloudTrail logs per month, the total cost would be $1.80.

## SNS Topic

Vectra will use an SNS Topic on your Account to notify us when new CloudTrail events have been generated.

A new notification should be published every 5 minutes (8760 per month), and you are allowed 1 million free requests per month, and costs $0.50 per million notifications after that.

For a medium sized organization, which is generating around 300GB of CloudTrail logs per month, the total cost would be $3.00.

## S3 Data Event Cost

For S3 Data Events, the volume is not easily predictable by Vectra and will vary by organization and usage patterns. Customers will pay $0.10 per 100,000 events. Vectra would not recommend logging be enabled for publicly accessible or high usage S3 buckets unless the use case dictates the level of analysis that Vectra provides.

## Managing storage of CloudTrail Data Events

By default, all log files in a S3 bucket will be stored indefinitely. Vectra does not require the data events to be stored after ingestion by Vectra for analysis. It is a best practice for organizations to retain CloudTrail logs per their IT policies. Log ingestion by Vectra is quick process. 7 day retention in AWS is more than adequate for Vectra’s use, but your organization’s polices may require longer retention.

For long term retention and cost-effective storage, the organization can leverage S3 Object Lifecycle Management. [Guidance can be found here](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html).

## Transfer Costs to the Vectra Cloud

The way the system is architected, there are no costs for the customer to transfer this data.


# Estimating Log Volume

Guidance to estimate AWS log volume and expected ingestion impact for CDR for AWS.

You can view how much data Vectra will monitor by reviewing the daily volume of CloudTrail trail logs added to S3 via the AWS Cloudtrail management page. As long as you have permissions to view the S3 bucket which your CloudTrail logs are ingested to, its simple to determine the usage.

* In AWS, navigate to your CloudTrail management page.
* Select the trail which you want CDR for AWS to monitor.
  * Generally, we recommend creating a single organization trail which logs activity from all of your AWS accounts.
* You should see a view like this screenshot below. Take note of the “Trail Log Location” name.

![Example organizational trail showing Trail Log Location](/files/P8ngfK0UJq9bFWCmv8DE)

* Click on the Trail Log Location to be taken to S3.
* In the left hand Menu, click on “Dashboards” Under “Storage Lens”.
* You should see a “default-account-dashboard”.

![Navigating to the S3 bucket data added per day data](/files/Nv15QZiC0lfq4dZaQWIn)

* Open this Dashboard, and click on the “Bucket” tab.
* You should see a graph “Trend of Buckets”, showing activity for all of your buckets.
  * Drill down to your CloudTrail S3 bucket by deselecting any S3 buckets without the name you noted in Step 3.
* You may need to change “Top N Buckets” to show more buckets.
* Once you only have your CloudTrail S3 bucket selected, you should see a graph like this screenshot below:

![Example graph showing S3 bucket data growth in last 30 days](/files/6tjuqZYv2pV5qT1NAyUv)

* Note the difference in size between 2 points in time, and divide this difference by the number of days between these points to calculate your average daily ingestion.

## Troubleshooting

### The number is smaller than expected, I suspect we are using lifecycle management:

If your CloudTrail log S3 bucket deletes management events after a certain time period, then this graph may not reflect actual usage. In this case, you can measure total expected volume by checking the total storage volume in your S3 and measuring how long these logs are retained for, and calculating the average daily usage from that.

* Using the steps above, measure the total storage in your CloudTrail S3 bucket.
* Navigate to your CloudTrail S3 bucket.
* Select the “Management Tab”, and note the lifecycle rules for this S3 bucket.
* It may say something like “Expire objects after 90 days” or similar.

![S3 bucket management tab showing lifecycle rules](/files/hUQc6DAOAUNNW8I64P6p)

* To get your daily log volume, divide the total storage in your S3 bucket by the number of days before expiry.

#### Example

* If the total storage in your CloudTrail S3 Bucket is 900GB.
* And you have a lifecycle management policy of 90 days.
* Then your CloudTrail logs would come to 10GB per day.

### I cannot see my S3 bucket in the Top N buckets:

You may need to create a new Storage Lens Dashboard, to see CloudTrail management event activity.

* Navigate to “Storage Lens Dashboards”, and click “Create Dashboard”.
* Name your dashboard.
* In “Dashboard Scope”, untick “include all buckets”.
* Select the Cloudtrail S3 bucket you noted in step 3 above, click “Create Dashboard”.
* The dashboard will take some time to populate data, once this is done, follow the steps above.


# Amazon Security Lake Integration

Integrate Vectra Detect for AWS with Amazon Security Lake.

## Introduction

Detect for AWS offers advanced Threat Detection & Response coverage for your AWS control plane. We leverage AI & ML techniques to monitor all activity in your organization’s global AWS footprint for malicious behaviors. Detect for AWS leverages CloudTrail logs and contextual IAM information to find malicious activity, and then attribute it to the malicious actor itself using Vectra’s Kingpin technology.

Amazon Security Lake is a data lake for security logs, built in the customer’s AWS account. The data lake is backed by an S3 bucket and organizes data as a set of Lake Formation tables. Core to the Amazon Security Lake mission is simplifying the storage, retrieval, and consumption of security logs through application of a common schema. The Open Cybersecurity Schema Framework (OCSF) is a collaborative open-source effort between AWS and partners.

Vectra supports integration with Amazon Security Lake and the OCSF. Vectra’s integration allows feeding of any new Vectra account scoring events to a custom source Amazon Security Lake S3 bucket. This enables customers using Amazon Security Lake to have a high quality source of behavior detection in Detect for AWS, along with any other security event Amazon Security Lake they may be ingesting.

## Requirements

* An active trial or existing licensing for Detect for AWS
* A configured data source for Detect for AWS
* A Vectra SaaS API client with minimum permissions of:
  * View – Accounts
  * Edit – Notes
* Access to Amazon Security Lake
* An Amazon Security Lake Custom Source

## Joining Vectra Detect for AWS

Existing customers of Vectra Detect for AWS with a valid license are supported. If you do not already have a license for Detect for AWS, a trial license is also supported. To begin a [free trial of Vectra Detect for AWS please follow the link.](https://info.vectra.ai/detect-aws-free-trial) The [Vectra Detect for AWS Deployment Guide](/deployment/cdr-for-aws/deployment) on the Vectra Support portal will walk you through deployment.

## Creating a Vectra Detect for AWS Data Source

Full details are available in the [Vectra Detect for AWS Deployment Guide](/deployment/cdr-for-aws/deployment) (including troubleshooting steps) but below is a short summary of steps. Vectra enables automated deployment via a CloudFormation template but also details manual steps if desired:

* Creating a Detect for AWS connection in the Vectra UI.
* Creating an SNS topic (or using an existing one) to notify Vectra when new logs are available to retrieve.
* Creating a role in your AWS account to allow Vectra to retrieve logs from the S3 bucket where your CloudTrail logs are located.
* Providing Vectra with the AWS role ARN, S3 bucket location, and SNS topic ARN.
  * Vectra will subscribe the SNS topic to your S3 Bucket after submitting these.

## Creating Vectra SaaS API Client

To create a Vectra SaaS API client:

* Log in to your instance and navigate to *Manage > API Clients*.
* Click “Add API Client”.
* Give your client a name and a role that allows for at least “View – Account” and “Edit – Notes” permissions.
  * Roles can be seen in *Manage > Roles*.
  * The following built in roles contain the necessary permissions:
    * Admin, Restricted Admin, Security Analyst, Setting Admin, and Super Admin.
* Additional documentation about the SaaS API can be found in the following articles:
  * [Vectra SaaS API Guide](/configuration/access/api-rux/v30-api-guide-rux)
  * [Vectra SaaS API Quickstart Tutorial](/configuration/access/api-rux/rux-api-postman-quick-start-guide)

## Creating an Amazon Security Lake Custom Source

Before ingesting into a custom source, that source must be registered with Amazon Security Lake using the console or API method. Amazon Security Lake will assign a unique prefix within the Amazon Security Lake S3 bucket in the customer’s account, which will prevent collision with other sources.

Please follow the [Collecting data from custom sources](https://docs.aws.amazon.com/security-lake/latest/userguide/custom-sources.html) documentation from AWS for creation of the Amazon Security Lake Custom Source for use with Vectra’s Detect for AWS data. Vectra’s CloudFormation template will ask for the S3 bucket and unique prefix of the Amazon Security Lake Custom Source you have created before the template can be run. Please keep in mind the following when creating the custom source:

* In the “OCSF Event class” dropdown, select “Security Finding”.
* For the “Account ID”, please enter a delegated administrator Account ID that has rights to write logs and events to the data lake.

## Running the Amazon Security Lake Integration Deployment Script

Vectra’s CloudFormation script will create several resources:

* An execution role based on the service-role "AWSLambdaBasicExecutionRole".
* An event trigger which will be used to invoke the lambda every 5 minutes.
* Appropriate permissions to allow the lambda to be run by the scheduled trigger.
* A [lambda layer](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) containing the AWS *Wrangler* library for python 3.9.
* A DynamoDB Table to keep the state of the lambda executions.
* A Lambda execution role with appropriate permissions on S3 and DynamoDB.
* The actual lambda function which talks to the Vectra SaaS API to do the actual accounts enrichment.

The following link will take you to CloudFormation and open a Quick create stack page where you can fill in the details. If you are not already logged in to AWS, you will need to log in. The script will default to running in US-West-2 and must be run from US-West-2.

* [CloudFormation Deployment Script](https://console.aws.amazon.com/cloudformation/home?region=us-west-2#/stacks/new?stackName=VectraAmazonSecurityLakeIntegration\&templateURL=https://vectra-amazon-security-lake-integration.s3.us-west-2.amazonaws.com/VectraAmazonSecurityLakeIntegration.yml)

On the next page you will see an example of the stack configuration page you will need to complete. Keep in mind:

* The stack name is pre-set but can be changed if you desire.
* The Vectra URL, ClientID, and ClientSecret refer to your Vectra SaaS instance that you will retrieve the data from.
  * The Vectra URL should be formatted as follows: <https://123123123123.uw2.portal.vectra.ai>
  * The ClientID and ClientSecret should be pasted exactly as you copied them from the [Creating Vectra SaaS API Client](#creating-vectra-saas-api-client) step previously.
* The AWSAccountID and AWSRegion are used for partitioning of data in your Amazon Security Lake instance. Think of these being used like directory names.
  * The AWSAccountID must be 12 digits.
  * The AWSRegion should be formatted as follows: us-east-1 (use your appropriate region)
* The AmazonSecurityLakeS3Bucket and AmazonSecurityLakeS3BucketPrefix should match what you created for the custom data source in Amazon Security Lake for Vectra.

When done filling out the form, create the stack to begin ingesting Vectra Detect for AWS data into Amazon Security Lake.

![](/files/2702152bbbfc4f9afd75d5b1201d416223cd1af8)

## OCSF Field Mapping Table

| **Field**                                         | **Details**                                                                        |
| ------------------------------------------------- | ---------------------------------------------------------------------------------- |
| activity                                          | Set statically to "Generate" as this always corresponds to a new finding           |
| activity\_id                                      | Set statically to "1" as this is the ID corresponding to "Generate"                |
| category\_name                                    | Set statically to "Findings" as we're generating a security finding                |
| category\_uid                                     | Set statically to 2 corresponding to "Findings"                                    |
| class\_name                                       | Set statically to "Security Findings" as we're generating a security finding       |
| class\_uid                                        | Set statically to 2001 corresponding                                               |
| finding.title                                     | Set statically to "Generate"                                                       |
| finding.src\_url                                  | Point to the URL of the impacted account on the Vectra SaaS UI                     |
| finding.uid                                       | Points to the account ID of the impacted account on the Vectra SaaS UI             |
| finding.supporting\_data.assignment               | User to whom the account has been assigned for investigation (if any)              |
| finding.supporting\_data.last\_detection\_href    | URL pointing to the last detection on this account on the Vectra SaaS UI           |
| finding.supporting\_data.last\_detection\_type    | Type/model of the last detection alerted on this account                           |
| finding.supporting\_data.last\_detection\_id      | ID of the last detection alerted on this account                                   |
| finding.supporting\_data.active\_detection\_types | Array of all active detections on this account                                     |
| message                                           | Type of alert, typically "Account Host Score Change"                               |
| metadata.version                                  | Set statically to "1.0.0" on the first iteration of this integration               |
| metadata.product.lang                             | Set statically to "en" as Vectra only exists in English                            |
| metadata.product.uid                              | Unique identifies of the Vectra SaaS UI                                            |
| metadata.product.vendor\_name                     | Set statically to "Vectra AI"                                                      |
| metadata.product.name                             | Set statically to "Vectra Detect"                                                  |
| time                                              | The original timestamp of the event from the Vectra brain                          |
| severity                                          | Severity of the account, as in the Vectra quadrant, between "Low" and "Critical"   |
| severity\_id                                      | Severity score of the account, based on the Vectra account score, between 2 and 5. |
| status\_detail                                    | Whether this is a score increase or decrease.                                      |
| state\_id                                         | Set statically to 1, as alerts will always be about new events                     |
| type\_uid                                         | Set statically to "200101" corresponding to "Security Finding: Generate"           |
| type\_name                                        | Set statically to "Security Finding: Generate"                                     |

* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# CDR for Azure

Landing page for CDR for Azure deployment and sizing guidance.

{% content-ref url="/pages/7678bfce34dfc8d5d424d19b0c53beaf6620496c" %}
[Estimating usage](/deployment/cdr-for-azure/estimating-usage)
{% endcontent-ref %}

{% content-ref url="/pages/eHvxrLJqabpPPFKn1Kfc" %}
[Deployment](/deployment/cdr-for-azure/deployment)
{% endcontent-ref %}


# Estimating usage

Gather Azure CDR sizing data to help estimate service costs for Vectra deployments.

## Introduction

This knowledge base article describes how to collect a summary of Azure resources grouped by resource type using the current Azure portal experience. Vectra requires a count of Azure resources by resource type across one or more subscriptions in order to estimate pricing. The steps below explain how to generate this information and export it as a CSV file using Azure Resource Graph. The exported CSV will contain one row per Azure resource type with a corresponding count. This file can be provided directly to the Vectra sales or support team.

## Requirements

* Access to the Azure Portal
* Permissions to view resources across the relevant subscriptions

## Steps to Follow

* Log into the [Azure portal](https://portal.azure.com/).
* In the top search bar, search for and the select **All Resources**.
* Ensure the **Subscription** filter includes all relevant subscriptions.
  * Leave **Resource Group**, **Type**, and **Location** set to **All**.

![](/files/224945b9bf84eaad256f855aa835129aa6fda381)

* From the top command bar, select **Open query**. This will open the Azure Resource Graph Explorer.
* Click **New query** to clear any existing query.
* Paste in the following to generate a summary of resource types, ordered by count.

```markup
Resources
| summarize count() by type
| order by count_ desc
```

![](/files/28aa78488f53ae746be22358de6504bf33c6d187)

* Next click **Run query** to run the query.

![](/files/5b260a732ebea3de1050fb6f4190910a9dc345e5)

* Finally, click **Download formatted results as CSV**.
* Provide the .csv file to your Vectra account team so they can produce a pricing estimate for you.


# Deployment

CDR for Azure Deployment anchor page with demo video and product related announcements.

## Deployment Demo Video

* The video below provides an overview of the architecture and deployment process, how to validate that you have the required permissions, shows you how to collect required information, and finally takes you through a complete deployment. It is meant to be a companion to the deployment guide (available below). The deployment guide provides deeper guidance and additional information not contained in this demo.

{% embed url="<https://vimeo.com/927271588/a8be207b73>" %}

* 00:00 - Introduction
* 00:13 - Architecture overview
* 00:43 - Getting started (beginning data source connector setup, deployment guide intro)
* 01:40 - Deployment process overview
* 03:11 - Permissions required and validation
* 05:28 - Consent workflow (instantiate Azure Enterprise Application)
* 05:48 - Gather required information
* 08:13 - Main ARM template deployment
* 09:27 - Remediation ARM template deployment
* 10:39 - Completing the data source connector setup in the Vectra UI

## New Coverage

In late September 2025, Vectra added support for Azure Storage Account log ingestion.

* The deployment guide has been updated to include details.
* In particular, please see Appendix 2 which covers adding additional locations or resources.
  * If your original deployment was before storage account ingestion was part of the product, then you will need to rerun the main deployment and the remediation as described in the deployment guide.
  * Deployment is an idempotent process and running these parts of the deployment again will add the new policies for Azure Storage Account Log ingestion and not affect the already working parts of the original deployment.


# Introduction, architecture, and requirements

What CDR for Azure provides, how it works, and what you need before deploying.

## Introduction

CDR for Azure offers advanced threat detection and response coverage for your Microsoft Azure tenants. Vectra AI is providing this guide to help their customers deploy this solution to leverage this coverage. To do this, Vectra AI needs to ingest your Microsoft Azure tenant platform logs, and following this deployment you will have:

* **Azure Detections** - High fidelity detections of malicious behaviors in your Azure tenants based on our proprietary ML and security analytics capabilities.
* **Azure Threat Surface Dashboard** - Insights to help you identify security related threat patterns in your Azure tenants.
* **Azure Investigate** - Curated Azure metadata that allows you to perform in-depth investigations on potential threats in your Azure tenant. This data consists of enriched metadata fields and all the existing *Investigate* capabilities to help you efficiently conduct an investigation.

This guide will enable you to configure the Azure Data Source connector in your Vectra AI Platform. It also provides you with the details to ensure your Azure tenant platform logs are being forwarded to dedicated storage accounts accessible to the Vectra AI Platform for data ingestion.

## Architecture Overview

This Data Source leverages Activity logs and Diagnostic Resource logs to detect suspicious activity in your environment. This logging is managed by Azure Monitor but is not enabled by default in Azure environments.

This deployment guide will help you grant Vectra access to the data it requires to offer comprehensive detection coverage and, if required, to deploy broad logging in your Azure environment.

![](/files/d637206b1aba3bc03ba0fb49b66304d64c6611ee)

* Subscriptions and Resources in your environment log to Storage Accounts in your Azure tenant.
* Vectra leverages a role in your environment to periodically scan these storage accounts.
* When new logs are detected, Vectra copies these logs to the Vectra cloud.
* Vectra processes these log events through proprietary algorithms to generate detections.

## General Requirements

* Vectra Respond UX tenant.
* Azure permissions required only during deployment:
  * Granting Vectra access to your Azure tenant (Consent Workflow):
    * Global Administrator
  * Setup logging and grant Vectra access to the logs (Log Enablement Workflow):
    * Global Administrator
    * Resource Policy Contributor at management group level
    * User Access Administrator at management group level
      * This can be a temporary privilege elevation used only during log enablement.
  * Full list of ongoing Azure permissions required are in [Appendix 1 - Azure configuration notes](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes).
* Choose one of the below methods for deployment:
  * Automated Deployment via ARM template – Step specific prerequisites (if required) are listed in each step of the [Automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment) section.
  * Manual Deployment – Some customers prefer to deploy without using the automated deployment process that uses ARM templates or may already have a logging setup that can be used with Vectra CDR for Azure. Please see [Manual deployment](/deployment/cdr-for-azure/deployment/manual-deployment) for requirements and guidance.


# Automated deployment

Deploy CDR for Azure using the Vectra-provided ARM templates. This is the "Automated" deployment method and is recommended for most Vectra customers.

## Starting Data Source Connector Setup

This will be done in your Vectra UI at *Configuration → Data Sources → Microsoft Azure* and begins the process of enabling Vectra to pull logs from your Azure tenant.

* Navigate in your Vectra UI (Respond UX) to *Configuration → Data Sources > Microsoft Azure* and click the **+ Create Azure Connector** button in the top right.
  * You can expand the **Resources** area below for links and a demo deployment video.
* If Microsoft Azure is not listed as an available Data Source to deploy in your UI, please contact your Vectra account team.

<figure><img src="/files/wTMbMALPJWeDJRBN1RSx" alt=""><figcaption></figcaption></figure>

* Give your connector a name and then click **Create and Continue**.

<figure><img src="/files/Wh11vefSdMe6JcOusWCv" alt="" width="563"><figcaption></figcaption></figure>

* After clicking **Create and Continue** you will be in a **Configuring Azure Connector** flow that guides you through the remaining steps that are needed to complete the overall Azure Data Source Connector setup.
* If you need to complete other work before your deployment is complete, it’s ok to close this window or just open another browser tab for the other work. You can come back and complete deployment later.

## Configuring Azure Connector Overview

{% stepper %}
{% step %}

#### [Grant Vectra Access](#id-2.-granting-vectra-access-to-your-azure-tenant)

* After creating the Azure data source connector name, a link will be given to follow a consent process that creates an Enterprise application (Service Principal) in your Microsoft Azure tenant.
* When Vectra collects logs from the storage accounts, we assume this Service Principal in order to read any generated logs.
  {% endstep %}

{% step %}

#### [Select Coverage](#select-coverage-1)

* In a future update, Vectra will be adding Azure Flow and DNS logs as additional coverage options for Azure. You will be able to choose the desired coverage for your connector with the choices made on this screen.
  {% endstep %}

{% step %}

#### [Deploy to Azure](#id-3.-deploy-to-azure)

* Vectra creates storage accounts (with 4-day retention) to temporarily store your logs prior to ingestion.
* Vectra creates Azure policy initiatives, policies, and assignments that enforce diagnostic settings on your Azure resources to enable logging store them in the storage accounts.
  {% endstep %}

{% step %}

#### [Wait 24 Hours](#id-4.-wait-24-hours)

* After step 3, Azure will initiate an automated compliance scan to determine which resources are not in compliance with the polices that were just put in place.
* There is no set amount of time required or easy way to determine if this scan has been completed.
* Vectra can an automated email notification if desired to help keep track of the time.
  {% endstep %}

{% step %}

#### [Remediate Policies](#id-5.-remediate-policies)

* After waiting 24 hours for automated Azure policy compliance scans to complete, remediation tasks are run to remediate pre-existing resources so that they log properly.
  {% endstep %}

{% step %}

#### [Provide Log Location](#id-6.-provide-log-location)

* After completing step 5, you will input the resource group that contains the storage locations in the Data Source Connector setup dialog to complete the initial deployment process.
* Vectra then begins to collect log data from the storage accounts.
* Any resources created after the initial deployment are automatically remediated for the supported log types and locations that were configured in the initial deployment.
* When new locations are added or Vectra adds additional supported log types, simply re-run step 3 to step 5 to enable support for the new locations or log types. Deployment is an idempotent process.
  {% endstep %}
  {% endstepper %}

## 1. Grant Vectra Access

In this step you will follow a consent process that allows Vectra to ingest Azure platform logs from the storage locations that will be created in the next step. This consent process creates a trust relationship between your Azure tenant and the Vectra AI Platform using Microsoft’s best practices as described in this [Microsoft Document](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app). It uses the Microsoft app registration process and creates an Enterprise Application (aka Service Principal) in your Azure tenant.

* Permissions required by the user who will perform the consent process:
  * Global Administrator in Entra ID (Azure AD)
* Please see [Appendix 1 - Azure configuration notes](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes) for full details about:
  * The [required permissions during deployment](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#required-permissions-during-deployment).
  * The [permissions required post deployment](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#permissions-required-post-deployment).
  * What [Vectra creates in Azure and why](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#what-vectra-creates-in-azure-and-why).

<figure><img src="/files/xw6tnsZh4lfogKIV6jAS" alt=""><figcaption></figcaption></figure>

* Click either on **Authorize Vectra in Azure** or **Copy Authorization Link.**
  * **Authorize Vectra in Azure** - Opens the link in new tab.
  * **Copy Authorization** - Copies the link so you can provide it to someone else.
    * This is useful when you may not have the required privileges to complete this step.
    * Remember, you need Global Administrator privileges in Entra ID to accomplish this step.
* Step though the following pages, choosing an appropriate entity and logging in if required.

| ![](/files/b6f85b96fb3451196ccec89ab799440f2a8578c5) | ![](/files/8e183a544752f0a21005c3c6044523dd5cef55f0) |
| ---------------------------------------------------- | ---------------------------------------------------- |
| ![](/files/5acb2298caed1e6c77c2736850bde45e68e0e8a7) | ![](/files/c3e9bcf2c6a41b444afa92c1c4341329d8820ca8) |

{% hint style="success" %}
You have completed this step when you see the checkmark with **Permission granted successfully!**
{% endhint %}

## 2. Select Coverage

<figure><img src="/files/ybW429dhz34oq6bYRO1x" alt=""><figcaption></figcaption></figure>

As per the [configuring Azure connector](#configuring-azure-connector-steps) steps above, in a future update, Vectra will be adding Azure Flow and DNS logs as additional coverage options for Azure. You will be able to choose the desired coverage for your connector with the choices made on this screen.

If you wish to participate in this prior to it being generally available, please contact your Vectra account team.

For now, please ensure that **Azure CDR (Control Plane)** is selected and then move on.

## 3. Deploy to Azure

A Vectra provided ARM template will execute the main deployment which includes:

* Creating Resource Group
* Creating Storage Accounts
* Creating User Assigned Managed Identity
* Creating Policy Definitions and Assignments

For additional details please see [what Vectra creates in Azure and why](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#what-vectra-creates-in-azure-and-why) in [Appendix 1](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes).

### Prerequisites

Prior to running the automated deployment template there are several prerequisites that need to be completed. Gather the following parameters that will later be input as parameters for the ARM template deployments in step 3 (this step) and step 5 (remediating policies).

**Management Group** – This is the scope of coverage you desire for your tenant.

* Vectra will configure all subscriptions and locations (that have any resources deployed in them) that are included in the selected management group for Vectra CDR for Azure.
  * Please see [Unsupported Azure Locations](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#unsupported-azure-locations) for details on unsupported locations.

{% hint style="info" %}
Vectra’s automated deployment relies on management group functionality. If you do not use management groups, please get in touch with your account team to discuss options.
{% endhint %}

* Existing management groups can be used, and per [Microsoft Guidance](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups), it is suggested to use an Intermediate Root Management Group that is located directly under the Tenant Root Group to ensure full coverage of all resources in your Azure Tenant. Our example deployment uses the Tenant Root Group. This is supported but is not a best practice.
* Management groups can be retrieved from [*https://portal.azure.com*](https://portal.azure.com/) *> Management groups.*

![](/files/e95787c7d83ad80215ca61cac63f8b7830633144)

* Copy the **ID** of the management group you wish to use for deployment.

{% hint style="danger" %}
**DO NOT** use a subscription ID from this page. Use only a management group. Be careful as both ID types are in the same column.
{% endhint %}

**Region** – Default region for the deployment.

* It is recommended to choose where you typically deploy the majority of your resources.
  * Please see [Unsupported Azure Locations](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#unsupported-azure-locations) for details on unsupported locations.
* As an example, the storage account used for global Azure activity logs will be created here.

**Target Logging Subscription ID** – Which subscription you want the Vectra resources deployed to.

* This should be a pre-existing subscription and is where Vectra will create a resource group.
* Example: `01234567-0123-4567-89ab-0123456789ab`
* Look in [*https://portal.azure.com*](https://portal.azure.com/) *> Subscriptions* or *Management groups.*

![](/files/75be5be929c40f7e4f003a66c93715a77bf1fae4)

{% hint style="danger" %}
**DO NOT** use a management group ID from this page. Use only a subscription ID. Be careful as both ID types are in the same column.
{% endhint %}

**Enterprise App Object ID** - This should be the Service Principal Object ID of the Enterprise Application created in [1. Grant Vectra Access](#id-1.-grant-vectra-access). If you have not completed this step, you will not find the app.

* This can be found in [https://portal.azure.com](https://portal.azure.com/) *> Microsoft Entra ID > Enterprise applications*. Search for **Vectra AI – CDR for Azure** and copy the **Object ID** field for later use.

![](/files/e6d747f783d2ade6e20b5cfef1cb316407f3bfa2)

**Optional Target Logging Locations** – Optional array of Azure locations to configure logging for.

* The standard process is to leave this at the default of `[]` which is an empty set.
  * Vectra’s ARM template will determine the locations that are being used in all subscriptions in the selected management group and configure logging for them.

{% hint style="warning" %}
**Please Note:**

Some customer Azure architectures can interfere with the automated location discovery process used by the ARM template deployment.

* If after [executing the main deployment](#executing-main-deployment), the **Outputs** tab of the deployment shows an `installLocations` of `[]` then you must execute the main deployment again.

* For the subsequent deployment, the Optional Target Logging Locations array should be configured with an array of desired locations for the deployment.
  {% endhint %}

* Example format: `["ukwest", "westeurope", "westus"]`

* As an example, the following command at the Azure CLI showed locations that were active in our test deployment:

```
$ az resource list --query "[].location" --output tsv | sort | uniq
australiaeast
centralus
eastus
eastus2
francecentral
germanywestcentral
global
japaneast
koreacentral
northeurope
southcentralus
southeastasia
switzerlandnorth
uaenorth
uksouth
westeurope
westus
westus2
```

{% hint style="info" %}
One option to easily produce the required format is a site such as:

* <https://capitalizemytitle.com/tools/column-to-comma-separated-list/>
* Simply paste the desired list of locations in the left box, choose a delimiter of a comma, use an item prefix and suffix of a double quote, a list prefix of a left bracket, and list suffix of a right bracket.
  {% endhint %}

Ensure you have the following permissions in Azure before executing the deployment template:

* **Global Administrator**
* **Resource Policy Contributor** – at the management group level you will be deploying at.
* **User Access Administrator** – at the management group level you will be deploying at.
  * This can be a temporary elevation.
* If you are unsure if you have the proper permissions or need to elevate some of your permissions to do the deployment, please see [Appendix 1 - Azure configuration notes](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes).

### Executing Main Deployment

* As per the [Prerequisites](#prerequisites) section, please ensure you have gathered all the required information. You will also need to have the required permissions before continuing.

<figure><img src="/files/bbg3BW3wHE1Ksb7DMlXL" alt=""><figcaption></figcaption></figure>

* Click either on **Open Deployment Template in Azure** or **Copy Deployment Template Link.**
  * **Open Deployment Template in Azure** - Opens the link in new tab.
  * **Copy Deployment Template Link** - Copies the link so you can provide it to someone else.
    * This is useful when you may not have the required privileges to complete this step.
* This will open a **Deploy a custom template** (also known as **Custom deployment**) page in your Azure portal where you can fill in the information that you collected from the [Prerequisites](#prerequisites) section earlier.
* Fill in the required information and proceed through the template deployment.

{% hint style="info" %}
**Please Note!**

If you require configuration of private access for the storage accounts created that will be created during this step, please see [Configuring Private Access for Azure Storage Accounts](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#configuring-private-access-for-azure-storage-accounts) for details.
{% endhint %}

| ![](/files/e2eca84d902682149ff8c1b5782e067fb1ec2c43) | ![](/files/294d1f6ce607d7cecda856c6e6417a9293cd30c8) |
| ---------------------------------------------------- | ---------------------------------------------------- |

* The template deployment will proceed with progress updates being provided with Azure. In our test environment, it took around 10 minutes to deploy. Deployment time will vary based on the size of your deployment.

| ![](/files/75e044773cf8b1e03887351b8dd220b323ac1f32) | ![](/files/565148fee9f82c019e6d7fb425e0bb89c1c9ba7e) |
| ---------------------------------------------------- | ---------------------------------------------------- |

* Once the deployment is complete, navigate to the **Outputs** page (green arrow in the right screenshot above) and copy the `resourceGroupId` (see screenshot below)for later use in the Vectra Data Source Connector setup dialog.
  * Do **NOT** complete the Data Source Connector setup until completing **Remediate Policies**.
  * It is ok to close the Data Source Connector setup dialog and come back to complete it later.

![](/files/3f654221b1c338150c8e4fe82279fd5a02450bc6)

{% hint style="warning" %}
If after the ARM template deployment completes and the `installLocations` shows `[]` (an empty set], as per the [Prerequisites](#prerequisites), you must do this deployment again but supply locations as an array in the **Optional Target Logging Locations** input.
{% endhint %}

{% hint style="info" %}
You may want to also copy the `installLocations` to keep a record of which locations were covered during the template deployment. This is not needed to complete deployment now, but if you add additional locations in the future, it may be useful to know which locations are already covered by Vectra CDR for Azure.

* See [Appendix 2 - Adding additional locations or resources](/deployment/cdr-for-azure/deployment/appendix-2-adding-additional-locations-or-resources) for more details.
  {% endhint %}

{% hint style="success" %}
Once you see **Your deployment is complete**, and your are happy wit the `installLocations` ,and you have made note of the `resourceGroupId` for later completion of the data source connector setup, you have completed this step.
{% endhint %}

## 4. Wait 24 Hours

After completing the prior step (Executing the main deployment (Deploy to Azure)), Azure will initiate an automated compliance scan to determine which resources are not in compliance with the polices that were just put in place.

* There is no set amount of time required or easy way to determine if this scan has been completed.
* Vectra recommends **waiting for 24 hours** before continuing with this step to ensure that the scan has completed. If you run the remediation ARM before the automated compliance scan has completed, Azure will not know which resources need to be remediated, and pre-existing resources will not be remediated

<figure><img src="/files/kNutx3sEf2yOWwEhoVsP" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
If you wish to be reminded via email when 24 hours has elapsed, please enter an email address and submit it as per the screenshot above.
{% endhint %}

**Example Reminder Email:**

<figure><img src="/files/F4u3KO3Hrk07bnmZpHQq" alt="" width="563"><figcaption></figcaption></figure>

## 5. Remediate Policies

**General Remediation Guidance**

Existing resources in your environment need to be remediated to be compliant with the policies for logging that Vectra created in the step 3. Any new resources (of the types supported by Vectra) that are deployed (in the `installLocations` ) after you have completed your Vectra CDR for Azure deployment will automatically be made compliant by Azure with the polices that Vectra put in place and will not need remediation.

Vectra CDR for Azure supports the following Azure platform logs:

* Global Azure subscription activity Logs
* Resource logs for the following resource types: Automation Account, Key Vault, and Storage Accounts.

{% hint style="info" %}
As Vectra continually does security research, additional log types may be supported in the future. Running the ARM template deployment process is an idempotent process. The same steps can be run again in the future, and nothing will change with resources that Vectra has already deployed.

If you add any new Azure regions/locations to your deployment or if Vectra adds additional supported resource types, simply re-run steps 3 to 5.
{% endhint %}

**Remediating Policies**

<figure><img src="/files/IlVATogevSPidYBaKKB2" alt=""><figcaption></figcaption></figure>

* Click either on **Open Remediation Template in Azure** or **Copy Remediation Template Link.**
  * **Open Remediation Template in Azure** - Opens the link in new tab.
  * **Copy Remediation Template Link** - Copies the link so you can provide it to someone else.
    * This is useful when you may not have the required privileges to complete this step.
* This will open a **Deploy a custom template** (also known as **Custom deployment**) page in your Azure portal where you can fill in some of the information that you collected from the [Prerequisites](#prerequisites) section earlier.
* Fill in the required information and proceed through the template deployment.

{% hint style="info" %}

* If your initial execution of [executing the main deployment](#executing-main-deployment) worked without having to do the do a subsequent run where you supplied Optional Target Logging Locations, then you can leave that field blank here.
* If you had to supply Optional Target Logging Locations previously, you should supply the same location array as before.
  {% endhint %}

| ![](/files/04d9c1543900e973ffda82dd883d5917284c0949) | ![](/files/df95c6c357c44ffebc478147a0473aeec7ca6e6d) |
| ---------------------------------------------------- | ---------------------------------------------------- |

* The template deployment will proceed with progress updates being provided with Azure. In our test environment, it took around 10 minutes to deploy. Deployment time will vary based on the size of your deployment.

| ![](/files/f5f4505473984adcd1cf5b88e622f118917fc144) | ![](/files/27f95840d80f2b93149662201ee920af5f75f074) |
| ---------------------------------------------------- | ---------------------------------------------------- |

{% hint style="success" %}
Once you see **Your deployment is complete**, all resources that required remediation, in all the deployed locations, have been remediated. Said simply, diagnostics settings have been applied to them that direct logs to be stored in the appropriate storage accounts for retrieval by Vectra.
{% endhint %}

## 6. Provide Log Location

Now that the Azure side of the deployment is completed, we need to complete the setup of the Vectra Azure Data Source connector that we began earlier.

* You should have already copied the `resourceGroupId` during the Executing the main deployment (Deploy to Azure) step but if misplaced, you can easily retrieve it:
  * Navigate to [*https://portal.azure.com*](https://portal.azure.com/) *> Resource Groups.*
  * Search for or scroll to the `rg-vectra-cdr` resource group and click into it.
  * Click the **JSON View** link in the top right.
  * Click the copy button in the Resource ID field.

<figure><img src="/files/b2110212cd6c72cecbeb4b291241ba464a6307d8" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/933a56494c404d16e32e0e1e7e8cd02bfed069fa" alt=""><figcaption></figcaption></figure>

* To complete the deployment in the Vectra UI, paste the resourceGroupId you copied earlier into the **Azure Log Location** field and click **Save and Complete Setup**.

<figure><img src="/files/iRnSnNSJgCcjfNCc2s4t" alt=""><figcaption></figcaption></figure>

* You should see a **Setup complete, awaiting first logs** message and then a **Logs flowing** message once Vectra begins processing your logs.

![](/files/48cfa3a8f462c5bc8a5da43c073f79ef0f99a4ab)

![](/files/86d0b98a0fcb343a0ca71cac747287e58f5c43a5)

![](/files/30900e790bc0bc89c03ba288c7672f7944b13bed)

{% hint style="success" %}
Congratulations, you have completed the automated deployment process. Additional detail can be seen by expanding the connection name or hovering over the status message.
{% endhint %}


# Manual deployment

Deploy CDR for Azure manually without the aid of Vectra provided ARM templates.

Vectra highly recommends the [Automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment) method for most customers.

If you have an existing Azure logging setup that you wish to utilize to provide the required logs to Vectra, then the manual deployment method may be desirable. Other customers may have a desire to manually configure the required logging and not use the Vectra provided ARM templates to automate the process.

Please keep in mind the following if you are interested in the manual deployment method:

{% hint style="info" %}
The ARM templates used in the [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment) process are readable before deploying them. You can look at what will be done before executing the deployment if you have any concerns about the content of the templates.
{% endhint %}

{% hint style="info" %}
When using the [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment), any new resources (of the types supported by Vectra) that are deployed after you have completed your automated deployment will automatically be made compliant by Azure with the polices that Vectra put in place and will not need remediation.

* This means that they will automatically be set to log to the storage account for the location/region the resource resides in.
  {% endhint %}

{% hint style="warning" %}
If manual deployment is used, it is up to the customer to configure logging to point to the storage accounts.

* This applies to any existing subscription or resource at initial deployment, and for any subscription or resource added after initial deployment.
  {% endhint %}

{% hint style="info" %}
For customers who are wondering if Vectra can retrieve the required logs from Azure Log Analytics if they are already being stored there:

* No, this is not possible as the required information is not available when logging is done in this manner.
  {% endhint %}

## Requirements

For manual deployment, please ensure the [General Requirements](/deployment/cdr-for-azure/deployment/introduction-architecture-and-requirements#general-requirements) specified earlier have been satisfied.

The requirements below are specific to manual deployment and describe what will need to be created in Azure:

* **Resource Group**
  * A resource group to contain the storage accounts that will be used to temporarily hold the logs prior to Vectra ingesting them.
* **Storage Accounts**
  * Vectra recommends that customers configure 4-day retention for all storage accounts.
    * When using Vectra's [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment) this is set automatically.
  * One storage account that can be used for all subscription activity logs.
  * A storage account for each location/region that has supported resources deployed in it.
    * When writing logs to a storage account, Azure requires that the storage account be in the region that the resource resides in.
    * Supported resource types are Automation Accounts, Key Vaults, and Storage Accounts.
* **Vectra AI - CDR for Azure**
  * This enterprise application / service principal is still required in the manual deployment method.
  * It requires a role assigned to it that allows it to read from the resource group that was created to contain the storage accounts.
    * See [permissions required post deployment](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes) for more details on specific role requirements.
* **Diagnostic Settings**
  * Need to be applied to each subscription and supported resource:
    * Any subscription you desire to be monitored by Vectra CDR for Azure should have its platform activity logs sent to the same storage account you created for this purpose.
      * For subscription logs - include all log categories.
    * Any supported resource you desire to be monitored by CDR for Azure should have its logs sent to the storage account you setup for the region/location the resource is deployed in.
      * For Automation Accounts - only the **AuditEvent** log type is required.
      * For Key Vaults - include **Audit Logs** and **Azure Policy Evaluation Details**.
      * For Storage Accounts - only the **Audit** category group is required.
        * This includes **Storage Read**, **Storage Write**, and **Storage Delete** categories.

## Starting Data Source Connector Setup

This will be done in your Vectra UI at *Configuration → Data Sources → Microsoft Azure* and begins the process of enabling Vectra to pull logs from your Azure tenant.

* Navigate in your Vectra UI (Respond UX) to *Configuration → Data Sources > Microsoft Azure* and click the **+ Create Azure Connector** button in the top right.
  * You can expand the **Resources** area below for links and a demo deployment video.
* If Microsoft Azure is not listed as an available Data Source to deploy in your UI, please contact your Vectra account team.

<figure><img src="/files/wTMbMALPJWeDJRBN1RSx" alt=""><figcaption></figcaption></figure>

* Give your connector a name and then click **Create and Continue**.

<figure><img src="/files/Wh11vefSdMe6JcOusWCv" alt="" width="563"><figcaption></figcaption></figure>

* After clicking **Create and Continue** you will be in a **Configuring Azure Connector** flow that guides you through the remaining steps that are needed to complete the overall Azure Data Source Connector setup.
* If you need to complete other work before your deployment is complete, it’s ok to close this window or just open another browser tab for the other work. You can come back and complete deployment later.

## Configuring Azure Connector Overview

{% hint style="warning" %}
When doing a CDR for Azure manual deployment, the same **Configuring Azure Connector** flow that appears for the automated deployment is shown when adding a CDR for Azure data source connector.

Take care to only complete the steps as described below. Some of the steps are skipped for manual deployment and are described separately.
{% endhint %}

{% stepper %}
{% step %}

#### [Grant Vectra Access](#id-2.-granting-vectra-access-to-your-azure-tenant)

* This is the same step as in the [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment).
* After creating the Azure data source connector name, a link will be given to follow a consent process that creates an Enterprise application (Service Principal) in your Microsoft Azure tenant.
* When Vectra collects logs from the storage accounts, we assume this Service Principal in order to read any generated logs.
  {% endstep %}

{% step %}

#### [Select Coverage](#select-coverage-1)

* In a future update, Vectra will be adding Azure Flow and DNS logs as additional coverage options for Azure. You will be able to choose the desired coverage for your connector with the choices made on this screen.
  {% endstep %}

{% step %}

#### [Deploy to Azure](#id-3.-deploy-to-azure)

{% hint style="warning" %}
Please ignore this step in the UI for manual deployment. Vectra's main ARM template is linked here and this will not be used when manually deploying CDR for Azure.

Follow the steps outlined in Deploy to Azure below and NOT the instructions in step 3 in your Vectra UI.
{% endhint %}

**For Manual Deployment:**

* Create resource groups and storage accounts.
* Create an assign role to the **Vectra AI - CDR for Azure** enterprise application.
* Setup logging.
  {% endstep %}

{% step %}

#### [Wait 24 Hours](#id-4.-wait-24-hours)

Even though Vectra's [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment) is not being used when deploying CDR for Azure manually, if your manual deployment uses Azure policy to set diagnostic resources, the same concepts still apply.

* When a new policy is put in place, Azure will initiate an automated compliance scan to determine which resources are not in compliance with the polices that were just put in place.
* There is no set amount of time required or easy way to determine if this scan has been completed.
  {% endstep %}

{% step %}

#### Remediate Policies

{% hint style="warning" %}
Please ignore this step entirely in the UI for manual deployment. Vectra's remediation ARM template is linked here and this will not be used when manually deploying CDR for Azure.

Customers should still remediate any resources that aren't compliant if they use Azure policy for their manual deployment, but due to the nature of manual deployment, Vectra does not provide instructions for this.
{% endhint %}
{% endstep %}

{% step %}

#### [Provide Log Location](#id-6.-provide-log-location)

* The resource group that contains the storage locations for you Azure logs needs to entered in the Data Source Connector setup dialog to complete the initial deployment process.
* Vectra then begins to collect log data from the storage accounts.

{% hint style="warning" %}

* Any subscriptions or supported resources created after your initial deployment will need to have their diagnostic settings updated manually or via customer provided Azure policy to write logs to the appropriate storage accounts.
* Similarly, if any new locations are added or Vectra adds any new supported resource types, the customer is responsible fully for updating their configuration to collect the new logs in storage accounts in the resource group that was configured previously.
  {% endhint %}
  {% endstep %}
  {% endstepper %}

## 1. Grant Vectra Access

In this step you will follow a consent process that allows Vectra to ingest Azure platform logs from the storage locations that will be created in the next step. This consent process creates a trust relationship between your Azure tenant and the Vectra AI Platform using Microsoft’s best practices as described in this [Microsoft Document](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app). It uses the Microsoft app registration process and creates an Enterprise Application (aka Service Principal) in your Azure tenant.

* Permissions required by the user who will perform the consent process:
  * Global Administrator in Entra ID (Azure AD)
* Please see [Appendix 1 - Azure configuration notes](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes) for full details about:
  * The [required permissions during deployment](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#required-permissions-during-deployment).
  * The [permissions required post deployment](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#permissions-required-post-deployment).
  * What [Vectra creates in Azure and why](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#what-vectra-creates-in-azure-and-why).

<figure><img src="/files/xw6tnsZh4lfogKIV6jAS" alt=""><figcaption></figcaption></figure>

* Click either on **Authorize Vectra in Azure** or **Copy Authorization Link.**
  * **Authorize Vectra in Azure** - Opens the link in new tab.
  * **Copy Authorization** - Copies the link so you can provide it to someone else.
    * This is useful when you may not have the required privileges to complete this step.
    * Remember, you need Global Administrator privileges in Entra ID to accomplish this step.
* Step though the following pages, choosing an appropriate entity and logging in if required.

| ![](/files/b6f85b96fb3451196ccec89ab799440f2a8578c5) | ![](/files/8e183a544752f0a21005c3c6044523dd5cef55f0) |
| ---------------------------------------------------- | ---------------------------------------------------- |
| ![](/files/5acb2298caed1e6c77c2736850bde45e68e0e8a7) | ![](/files/c3e9bcf2c6a41b444afa92c1c4341329d8820ca8) |

{% hint style="success" %}
You have completed this step when you see the checkmark with **Permission granted successfully!**
{% endhint %}

## 2. Select Coverage

<figure><img src="/files/ybW429dhz34oq6bYRO1x" alt=""><figcaption></figcaption></figure>

As per the [configuring Azure connector](#configuring-azure-connector-steps) steps above, in a future update, Vectra will be adding Azure Flow and DNS logs as additional coverage options for Azure. You will be able to choose the desired coverage for your connector with the choices made on this screen.

If you wish to participate in this prior to it being generally available, please contact your Vectra account team.

For now, please ensure that **Azure CDR (Control Plane)** is selected and then move on.

## 3. Deploy to Azure

### Create Resource Group and Storage Accounts

Use any method you desire (Azure CLI / Cloud Shell, Azure Portal, custom tooling, etc) to create the required resource group and storage accounts that were specified in the manual deployment requirements. Please note the following:

* The naming convention you choose for the resource group and storage accounts does not matter to Vectra. Vectra will read all logs from any storage account in the resource group.
* The `resourceGroupId` will be required later to complete the Vectra Data Source Connector setup that you began in step 1. See below for the format to use (this is just an example):
  * `/subscriptions/b3fobfus-cate-dfor-securityeb01ff43e/resourceGroups/rg-vectra-cdr`
* If you require configuration of private access for the storage accounts created, please see [Configuring Private Access for Azure Storage Accounts](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#configuring-private-access-for-azure-storage-accounts) for details.

### Create and Assign Role for Vectra Enterprise App

The **Vectra AI - CDR for Azure** Enterprise application needs a role with specific permissions assigned to it so that it can read from the storage accounts that you created to temporarily hold the logs to be ingested by CDR for Azure.

Use any method you desire (Azure CLI / Cloud Shell, Azure Portal, custom tooling, etc) to create the required role and assign it to the **Vectra AI - CDR for Azure** Enterprise application.

The [permissions required post deployment](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#permissions-required-post-deployment) are what need to be assigned to the role. If you have permissions issues, full guidance is available in [Appendix 1](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes).

### Set up Logging

Use any method you desire (Azure CLI / Cloud Shell, Azure Portal, custom tooling, etc) to create the required diagnostic settings for the Azure platform logs you wish Vectra to analyze.

As per the manual deployment requirements all subscription activity logs for any subscription you want Vectra to monitor should go to the same storage account in the resource group.

Also, remember that Azure will require each supported resource to log to a storage account that is in the same location/region that the resource is deployed in.

The log types required for subscriptions and for supported resources is in the table below:

| **Subscription or Resource Type** | **Log Categories Required**                                                  | **Example**                                          |
| --------------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------- |
| Subscription                      | All                                                                          | ![](/files/0473b6d2a76d72e5829702d81cf728661d6ad1d4) |
| Automation Account                | AuditEvent                                                                   | ![](/files/1aef05e01a3df43621cf47a43d22cb900716efe7) |
| Key Vault                         | Audit Logs Azure Policy Evaluation Details                                   | ![](/files/83d0bfd94459e6897dfd0a092d2b27eea153eb4a) |
| Storage Accounts                  | “audit” category gives Read/Write/Delete (all required) for storage accounts | ![](/files/4919e745236dbba194e2e2bdd950632d9db2ad80) |

## 4. Wait 24 Hours

Even though Vectra's [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment) is not being used when deploying CDR for Azure manually, if your manual deployment uses Azure policy to set diagnostic resources, the same concepts could still apply.

* When a new policy is put in place, Azure will initiate an automated compliance scan to determine which resources are not in compliance with the polices that were just put in place.
* There is no set amount of time required or easy way to determine if this scan has been completed.
* Vectra recommends **waiting for 24 hours** before continuing with this step to ensure that the scan has completed if you will be using remediation policies in your manual deployment to remediate and resources that are not compliant with policy.

<figure><img src="/files/kNutx3sEf2yOWwEhoVsP" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
If you wish to be reminded via email when 24 hours has elapsed, please enter an email address and submit it as per the screenshot above.
{% endhint %}

**Example Reminder Email:**

<figure><img src="/files/F4u3KO3Hrk07bnmZpHQq" alt="" width="563"><figcaption></figcaption></figure>

## 5. Remediate Policies

{% hint style="warning" %}
Please ignore this step entirely in the UI for manual deployment. Vectra's remediation ARM template is NOT used when a customer chooses manual deployment.

Customers should still remediate any resources that aren't compliant if they use Azure policy for their manual deployment, but due to the nature of manual deployment, Vectra does not provide instructions for this.
{% endhint %}

## 6. Provide Log Location

* To complete the deployment in the Vectra UI, paste the `resourceGroupId` from [step 3](#id-3.-deploy-to-azure) earlier in the **Azure Log Location** field and click **Save and Complete Setup**.

<figure><img src="/files/iRnSnNSJgCcjfNCc2s4t" alt=""><figcaption></figcaption></figure>

* You should see a **Setup complete, awaiting first logs** message and then a **Logs flowing** message once Vectra begins processing your logs.

![](/files/48cfa3a8f462c5bc8a5da43c073f79ef0f99a4ab)

![](/files/86d0b98a0fcb343a0ca71cac747287e58f5c43a5)

![](/files/30900e790bc0bc89c03ba288c7672f7944b13bed)

{% hint style="success" %}
Congratulations, you have completed the manual deployment process. Additional detail can be seen by expanding the connection name or hovering over the status message.
{% endhint %}


# Appendix 1 - Azure configuration notes

Azure permissions, objects created by Vectra, and related operational notes to help with permissions issues.

## Required Permissions During Deployment

The permissions a user requires in Azure to enable CDR for Azure (during deployment).

**To grant Vectra access to your Azure tenant (Consent Workflow):**

* `Global Administrator` - Enterprise app is created that requires lower permissions for ongoing use.
  * See permissions required post deployment below for the ongoing permissions required by the **Vectra AI - CDR for Azure** enterprise app.

**To setup logging and grant Vectra access to the logs (Log Enablement Workflow):**

These permissions are required during [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment) and includes both [executing the main deployment](/deployment/cdr-for-azure/deployment/automated-deployment#executing-main-deployment) and [remediating policies](https://docs.vectra.ai/deployment/cdr-for-azure/deployment/pages/skUrE7j6vzCo416qJqr9#id-5.-remediate-policies) flows.

* `Global Administrator`
* `Resource Policy Contributor` at management group level
* `User Access Administrator` at management group level
  * This can be a temporary privilege elevation used only during the creation of Vectra resources.

## Permissions Required Post Deployment

These are the ongoing permissions required post deployment for CDR for Azure.

**Enterprise App / Service Principal**

Role permissions defined at the Vectra specific resource group level:

* `Microsoft.Storage/storageAccounts/read`
* `Microsoft.Storage/storageAccounts/blobServices/containers/read`
* `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
* `Microsoft.Resources/subscriptions/resources/read`
  * At the management group level used for deployment.

**User-Assigned Managed Identity**

For resource remediation that sets logging and retention policies at the management group level:

* `Monitoring Contributor Role` and `Storage Account Contributor Role`
  * This is only required for the [Automated Deployment ](/deployment/cdr-for-azure/deployment/automated-deployment)method. Manual deployment details are at the discretion of the customer.

## What Vectra Creates in Azure and Why

This applies fully to the Automated Deployment method and partially to the Manual Deployment method (only the **Vectra AI - CDR for Azure** enterprise app is shared with the manual deployment process)

<table data-header-hidden><thead><tr><th width="126.96875"></th><th width="431.4453125"></th><th></th></tr></thead><tbody><tr><td><strong>Item</strong></td><td><strong>Name</strong></td><td><strong>How to Find</strong><br><strong>(from Azure portal)</strong></td></tr><tr><td>Resource Group</td><td>rg-vectra-cdr</td><td>Resource groups > Click into “rg-vectra-cdr”</td></tr><tr><td>Enterprise Application / Service Principal</td><td>Vectra AI – CDR for Azure</td><td>Microsoft Entra ID > Enterprise applications > search for “Vectra AI” or “CDR”</td></tr><tr><td>Enterprise Application / Service Principal Role</td><td>Vectra Azure CDR Connector Role<br>Vectra Azure CDR Audit Role</td><td>Resource groups > Click into “rg-vectra-cdr” > Access control (IAM) > Roles > Search for “cdr”</td></tr><tr><td>User-Assigned Managed Identity</td><td>id-vectra</td><td>Resource groups > Click into “rg-vectra-cdr”</td></tr><tr><td>Storage Accounts</td><td>Vectra[unique_identifier] - These have 4-day retention set.</td><td>Resource groups > Click into “rg-vectra-cdr”</td></tr><tr><td>Policy Initiatives and Policies</td><td>Vectra Initiative Manage Resource Group<br>Vectra Initiative Collect Location Logs<br>Vectra Initiative Collect Subscription Activity Logs Vectra Storage Account Retention<br>Vectra Policy Collect Activity Logs<br>Vectra Policy Collect Key Vault Logs<br>Vectra Policy Collect Automation Account Logs<br>Vectra Policy Collect Storage Account Blob Logs<br>Vectra Policy Collect Storage Account File Logs</td><td>Policy > Definitions > Search for “Vectra”</td></tr><tr><td>Policy Assignments</td><td>Vectra Initiative Manage Resource Group Assignment Vectra Initiative Collect Subscription Activity Logs Assignment Vectra Initiative Collect Location Logs for [location| Assignment</td><td>Policy > Assignments > Search for “Vectra”</td></tr></tbody></table>

### Enterprise Application - SP and Associated Role

Enterprise Applications and Service Principals are essentially the same thing. Typically, the term Enterprise Application is used to describe an application integration while the Service Principal is the security principal for the application that is used to grant permissions or consent to resources.

Vectra uses Microsoft’s App Registration process to instantiate a copy of `Vectra AI – CDR for Azure` in your directory. The Application ID of this Enterprise Application / Service Principal refers to Vectra’s App Registration which resides in Vectra’s directory. The Service Principal Object ID refers to the instantiated instance in your directory and is what Vectra refers to as the `enterpriseAppPrincipalID` during deployment.

[This article](https://marileeturscak.medium.com/the-difference-between-app-registrations-enterprise-applications-and-service-principals-in-azure-4f70b9a80fe5) gives details on differences between App Registrations, Enterprise Applications, and Service Principals.

**Enterprise Application Name** - `Vectra AI – CDR for Azure`

**How is it created** – This is created during [1. Grant Vectra Access](https://docs.vectra.ai/deployment/cdr-for-azure/deployment/pages/skUrE7j6vzCo416qJqr9#id-1.-grant-vectra-access) to your Azure tenant.

**Associated roles** – Assigned during [executing the main deployment](/deployment/cdr-for-azure/deployment/automated-deployment#executing-main-deployment) using ARM templates.

* `Vectra Azure CDR Connector Role` is assigned to the `Vectra AI – CDR for Azure` Service Principal
  * The scope of the role assignment is the `rg-vectra-cdr` resource group.
  * The permissions of the role are:
    * `Microsoft.Storage/storageAccounts/read`
    * `Microsoft.Storage/storageAccounts/blobServices/containers/read`
    * `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
* `Vectra Azure CDR Audit Role` is assigned to the `Vectra AI – CDR for Azure` Service Principal
  * The scope of the role assignment is the management group used for deployment.
  * The permission of the role is `Microsoft.Resources/subscriptions/resources/read`

**What does the Enterprise Application / Service Principal do?**

* When Vectra’s LogFlow ingestion process collects log data from your Azure tenant, it assumes the Service Principal which has the role assignment/permissions mentioned in the prior bullet. The Service Principal is only permitted to read the log data that exists in the storage accounts that were created in the `rg-vectra-cdr` resource group. It can also collect counts of resources for billing.

### Resource Group - Storage Accounts - Managed Identity

Vectra creates a resource group, storage accounts, and a user-assigned managed identity.

**Resource Group** - Name: `rg-vectra-cdr`

**How it is created?**

* It is automatically created during [executing the main deployment](/deployment/cdr-for-azure/deployment/automated-deployment#executing-main-deployment) using ARM templates.

**What does it contain?**

* A storage account for each location specified during the deployment and a storage account used to store subscription activity logs. These are set to have a 4-day retention period.
  * Name format: `vectra[unique_identifier]`
* User-Assigned Managed Identity
  * Name: `id-vectra`

**Why does Vectra create a storage account for each location we deployed CDR for Azure to?**

* Azure requires that the diagnostic setting that writes resource logs to a storage account write to a storage account that is located in the same location as the resource.

**Can the storage accounts be configured for private access?**

* Yes, after the main deployment runs, the storage accounts can have restrictions put in place to only allow access to them from specific IP addresses used by Vectra in the region your Vectra tenant is deployed in.
* Please see [Configuring Private Access for Azure Storage Accounts](#configuring-private-access-for-azure-storage-accounts) for details if this is required.

**What is the purpose of the** `id-vectra` **managed identity?**

* The policy remediation tasks are run by the managed identity.

**What are the scope and permissions of the** `id-vectra` **managed identity?**

* The scope is the management group that was selected for deployment.
* The permissions are given by built-in Azure roles:
  * `Monitoring Contributor Role`
  * `Storage Account Contributor Role`

{% hint style="info" %}
**Please Note:**

* The `id-vectra` managed identity can only execute actions that are part of the policy definitions and assignments discussed in the next section.
* It does not partake in any part of the log ingestion process.
* The policy details can easily be viewed by the customer.
  {% endhint %}

### Policy Definitions, Assignments, and Remediation Tasks

Vectra uses Azure policy definitions at both the initiative and policy level along with policy assignments to enable a diagnostic setting on the supported resources. The diagnostic setting directs logs to be stored in the storage accounts so that Vectra can retrieve the logs for analysis.

Initiatives are a collection of Azure policy definitions that are grouped together towards a specific goal or purpose. Policies enforce and control the properties of a resource. Assignments are a policy definition or initiative that has been assigned to a specific scope. More information about Azure policy is available [here](https://learn.microsoft.com/en-us/azure/governance/policy/overview).

The Azure policy definitions and assignments are created during [executing the main deployment](/deployment/cdr-for-azure/deployment/automated-deployment#executing-main-deployment).

Vectra creates 2 initiative definitions:

* **Vectra Initiative Collection Subscription Activity Logs**
  * Contains 1 policy definition that enables a diagnostic setting to send subscription activity logs to a storage account in the `rg-vectra-cdr` resource group.
  * All subscriptions in the management group chosen for deployment log these subscription activity logs to the same storage account in the resource group.
  * Policy name – **Vectra Policy Collect Activity Logs**
* **Vectra Initiative Collect Location Logs**
  * Contains 2 policy definitions, one for each currently supported resource type, that enable a diagnostic setting to send resource logs to storage accounts in the `rg-vectra-cdr` resource group.
  * The resource logs are stored in specific individual storage accounts for each location that was configured during [executing the main deployment](/deployment/cdr-for-azure/deployment/automated-deployment#executing-main-deployment).
  * Policy names: **Vectra Policy Collect Automation Account Logs**, **Vectra Policy Collect Key Vault Logs**, **Vectra Policy Collect Storage Account Blob Logs**, **Vectra Policy Collect Storage Account File Logs**.

Vectra creates the following Policy Assignments:

* **Vectra Initiative Collect Subscription Activity Logs Assignment**
* **Vectra Initiative Collect Location Logs for \[location] Assignment**
  * Vectra creates a policy assignment that is specific for each location that was configured.

During [5. Remediate Policies](https://docs.vectra.ai/deployment/cdr-for-azure/deployment/pages/skUrE7j6vzCo416qJqr9#id-5.-remediate-policies), Vectra creates remediation tasks to remediate any existing resources in your environment that need to be made compliant with the policies for logging that Vectra created when [executing the main deployment](/deployment/cdr-for-azure/deployment/automated-deployment#executing-main-deployment). These remediation tasks can be viewed in your Azure portal at *Policy > Remedation > Remediation tasks* (be sure to check that the scope matches the management group you used for deployment). Any Vectra supported resources that are deployed after you have fully completed your Vectra CDR for Azure deployment will automatically be made compliant by Azure with the polices that Vectra put in place.

As Vectra continues development, additional log types may be supported. Running the ARM template deployment process is an idempotent process. The same steps can be run again in the future, and nothing will change with resources that Vectra has already deployed. If you add any new Azure regions/locations to your deployment or if Vectra adds additional supported resource types, simply redo the main deployment and remediation steps as outlined in the [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment).

## Configuring Private Access for Azure Storage Accounts

If it is required to setup private access for the storage accounts used by CDR for Azure, please follow these instructions. This must be completed after the storage accounts have been created.

Performing this step will add IP level restrictions to the storage accounts so that only Vectra IPs in the same region as your Vectra tenant will be able to access the storage accounts.

When using the Automated Deployment this can be after [executing the main deployment](/deployment/cdr-for-azure/deployment/automated-deployment#executing-main-deployment) has completed. When using Manual Deployment this would be after [3. Deploy to Azure](https://docs.vectra.ai/deployment/cdr-for-azure/deployment/pages/2nukC9GVIa4bnj5Fyigj#id-3.-deploy-to-azure) has been completed.

If you add additional locations or resources to your deployment, any new storage accounts created during that process would also need to again be configured as per these instructions below.

To configure private access for your Azure storage accounts used by CDR for Azure:

* Navigate to the resource group containing your storage accounts used for CDR for Azure.
  * If using the automated deployment, it will be named `rg-vectra-cdr` and in the region you specified during deployment.
* Click on one of the storage accounts.
* Open the **Security + networking** menu on the left and click on **Networking**.
* Select the **Enabled from selected virtual networks and IP addresses** option.
* Under the **Firewall** section, add the IPs corresponding to the region of your Vectra tenant from the list of IPs available here:
  * <https://ips.devops.vectra-svc.ai/ips.json>
  * For example, if your Vectra URL is like this: `https://[unique_identifier].uw2.portal.vectra.ai/` then you would use the `us-west-2` entries from the above list.
    * `uw2` = `us-west-2`
    * `ew1` = `eu-west-1`
    * `cc1` = `ca-central-1`
    * `ec2` = `eu-central-2`
    * `as2` = `ap-southeast-2`
* Click **Save**.
* Repeat these steps for any additional storage accounts in your CDR for Azure deployment. An example is shown below:

![](/files/328abf2f89ebd12c23f9fced14c5b5e00d000aa5)

## Checking and Resolving Permissions Issues

As discussed in [required permissions during deployment](#required-permissions-during-deployment), performing the deployment in Azure requires specific permissions:

* **Global Administrator** in Microsoft Entra ID (Azure AD).
* **Resource Policy Contributor** at management group level.
* **User Access Administrator** at management group level.
  * This can be a temporary privilege elevation used only during the creation of Vectra resources.

This section will discuss how to check if you have the required permissions, how to gain the permissions, and how to remove the permissions after deployment.

{% hint style="danger" %}
This guidance should NOT be used in place of, or bypass any of your organization’s internal processes or rules that apply to managing permissions within your Azure environment.
{% endhint %}

{% hint style="info" %}
Prior to performing any permission elevation, you should check the access you currently have. You may already have the required RBAC permissions and may not need to elevate permissions or you may not have sufficient permissions to perform the elevation flow. If you cannot validate or add the permissions that are required, please work with someone in your organization who can perform the deployment or provide you with the necessary permissions.
{% endhint %}

### Check for Global Administrator Role in Microsoft Entra ID

* In the Azure portal, navigate to *Microsoft Entra ID.*
* Click on **Users** in the menu to the left.
* Search for the user who will be performing the install and click on their name.
* From the user page, click **Assigned Roles** in the menu to the left and verify that you see **Global Administrator** in the list of roles.

![](/files/142bcfb7e72e3346491348ca0eb1d90e1f36194d)

* If the user who will be performing the deployment does not have this role, please work with your IT team and internal process to be assigned this role.
  * Alternatively, you can also navigate to *Microsoft Entra ID → Roles and administrators →* search for **Global Administrator** and click on it.
  * The **Active Assignments** column will contain a list of users who have this role and could potentially perform the deployment.

### Check for User Access Administrator and Resource Policy Contributor Role

The [User Access Administrator](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#user-access-administrator) role enables the user to grant themselves and other users access to Azure resources. This role will be required throughout the installation process.

The [Resource Policy Contributo](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#resource-policy-contributor)r role gives users the rights to create and modify resource policy. This will be required to deploy the initial template and during the policy remediation stage of the deployment.

* In the Azure Portal, navigate to *Management Groups*.
* Select the management group you wish to deploy Vectra CDR for Azure in.
  * If you cannot select the Management Group and instead see a message stating, **You are not authorized to view this Management Group**, then you do not have any roles assigned to you within that Management Group.
  * In this case, work with a colleague, or if you are a Global Administrator, you should be able to Elevate Permissions as Global Administrator.
    * After elevating permissions, you should be able to Assign Resource Policy Contributor Role.
    * After elevating permissions and assigning the Resource Policy Contributor role, you can come back here and perform the check as described below.
  * If you do not use management groups, please get in touch with your account team to discuss options.
* Click into *Access Control (IAM)* in the left menu.
* Click on the **View my access** button if you will be doing the installation or the **Check access** button to then search for the user who will be doing the installation.
* On the assignments screen, check for both the **Resource Policy Contributor** and **User Access Administrator** roles.
  * They should both have a scope of **This resource** which refers to the management group that you chose earlier.
  * If you have this role at the **Root** scope, this will suffice as well.

![](/files/5cf5c727cc1bff7999095d9e69071f7a934b2d5a)

* If you are missing either of these roles, you will need to either add these roles (following your organization’s internal process) or use the instructions below. The User Access Administrator role can be a temporary elevation that is used only for the deployment, or it can be a role assignment.
  * If you determine that it is necessary to add the User Access Administrator role, we will assume this to be a temporary elevation use case in our below instructions.

### Elevate Permissions as Global Administrator

Performing this step will add the User Access Administrator role at the root level in Azure. This is a highly privileged role that allows for a wide range of actions related to user permissions across all subscriptions and management groups. It is a best practice to assign this temporarily and then remove the role assignment after you have performed the deployment. Please see [this Microsoft article](https://learn.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin?tabs=azure-portal) for additional details.

* In the Azure portal, navigate to *Microsoft Entra ID.*
* Click **Properties** in the menu to the left.
* Toggle the **Access management for Azure resources** setting to **Yes** and **Save**.

![](/files/7ba0eb517611f366c4fad4231ea21352ffea133a)

* A success notification will appear in the corner once complete.
* There may be a short delay in propagating this setting. Vectra recommends logging out and back into the Azure tenant to help refresh user credentials.
* Once elevated per the above instructions, you should be able to assign the Resource Policy Contributor role.

### Assign Resource Policy Contributor Role

* In the Azure Portal, navigate to *Management Groups*.
* Select the management group you wish to deploy Vectra CDR for Azure in.
* Click into *Access Control (IAM)* in the menu to the left.
* Click **+ Add** and the click **Add role assignment**.

![](/files/d97797752dbac8493861c01443be0a5ccda3ce5b)

* In the search bar, type **Resource Policy Contributor**, click on its line, and then click **Next**.

![](/files/e5da6b5d6dc75bb108956b45a46ff7cdc2710bc8)

* In the **Members** tab, ensure **User, group, or service principal** is selected, click **+ Select members** and then search for the name/email address of the user who will perform the installation. Select the user from the list that appears and click the **Select** button.

![](/files/bdae8dc4d038e07480001467427275c8546ec571)

* Click **Next twice** to move to the **Review + assign** screen, confirm the details are correct, and then click the **Review + assign** button.

![](/files/5ecb90a0fbca6570f589db49f7e0bb6ed82a48a1)

* A success notification will appear in the corner once complete.
* There may be a short delay in propagating this setting. Vectra recommends logging out and back into the Azure tenant to help refresh user credentials.
* After adding the Resource Policy Contributor role, it is recommended to check your permissions per the earlier instructions before continuing with the deployment.

### Recommended Order of Operations for Permissions Cleanup

If it was required to elevate permissions or add roles as part of the deployment, it is recommended to remove these permissions when they are no longer required.

Vectra’s recommended sequencing is:

1. The user performing the deployment should perform De-Elevating Permissions as Global Administrator after Executing the main deployment (Deploy to Azure). This will ensure the deployment user will not have unnecessary permissions during the wait for the automated Azure policy compliance scan to complete.
2. After 24 hours, the user should perform the remediation as per Ensure pre-existing resources are remediated to log correctly (Remediate Policies).
3. After successful remediation, the user should again Elevate Permissions as Global Administrator so that they can Remove the Resource Policy Contributor Role that was required to be in place for the remediation step.
4. Remove the Resource Policy Contributor Role.
5. Finally, the user should perform De-Elevating Permissions as Global Administrator as shown below.

### De-Elevating Permissions as Global Administrator

This will remove the User Access Administrator role that was temporarily added. Keep in mind that to be able to Remove the Resource Policy Contributor Role, you must have the User Access Administrator role that doing this step removes. It is recommended to follow the Recommended Order of Operations for Permissions Cleanup.

* In the Azure portal, navigate to *Microsoft Entra ID.*
* Click **Properties** in the menu to the left.
* Toggle the **Access management for Azure resources** setting to **No**, and click **Save**.

![](/files/62068b30fa024be2efb153acbd7f41d170ac1df0)

* A success notification will appear in the corner once complete.
* There may be a short delay in propagating this setting. Vectra recommends logging out and back into the Azure tenant to help refresh user credentials.

### Remove the Resource Policy Contributor Role

To remove the Resource Policy Contributor role, the user needs to have the User Access Administrator role that was granted earlier through permission elevation.

* In the Azure Portal, navigate to *Management Groups*.
* Select the management group you deployed Vectra CDR for Azure into.
* Click into *Access Control (IAM)* in the left menu.
* Click the **Role Assignments** tab and then click on the **Role** filter button and select the **Resource Policy Contributor** role.

![](/files/81c996303494aa894e417a49c4a61ea72fa31341)

* Select the checkbox next to the user you wish to remove the role from, click **X Remove** and then click **Yes** in the modal that appears.

![](/files/eb4b4c8cc44c4132fe79f8675382587068ec67c9)

* There may be a short delay in propagating this setting. Vectra recommends logging out and back into the Azure tenant to help refresh user credentials.

## Unsupported Azure Locations

**Location** or **Region** terminology is often used interchangeably in Azure documentation. One example is that when using the Azure CLI command of `az account list-locations`, the output is technically a list of regions. In this documentation, **Location** or **Region** is also used interchangeably.

Due to differences in capabilities that Azure offers in each Location/Region, Vectra CDR for Azure will not be able to ingest logs in some Locations. Additionally, some Locations cannot serve as the default Region for the deployment during [executing the main deployment](/deployment/cdr-for-azure/deployment/automated-deployment#executing-main-deployment).

Please see the below table for details:

* The column on the left, **Unsupported Locations/Regions**, are locations that storage accounts currently cannot be created in.
  * If your Azure deployment is using any of these locations, Vectra CDR for Azure will not be able to collect logs from these locations. There will not be any errors generated during deployment because of this.
* The column on the right, **Locations/Regions Unsupported as Primary**, if one of these Regions is selected when choosing the **Region** for the ARM template deployment, an error will occur during deployment. An example of such an error is included below:

![](/files/cc2d343b290109f7aeceed40283271da31e9510b)

| **Unsupported Locations/Regions** | **Locations/Regions Unsupported as Primary** |
| --------------------------------- | -------------------------------------------- |
| australiacentral2                 | australiacentral                             |
| brazilsoutheast                   | israelcentral                                |
| francesouth                       | westindia                                    |
| germanynorth                      |                                              |
| norwaywest                        |                                              |
| southafricawest                   |                                              |
| switzerlandwest                   |                                              |
| uaecentral                        |                                              |


# Appendix 2 - Adding additional locations or resources

Guidance for re-running deployment when you add regions, locations, or Vectra adds new supported resource types.

Vectra CDR for Azure supports the following Azure platform logs:

* Global Azure subscription activity Logs
* Resource logs for the following resource types:
  * Automation Account
  * Key Vault
  * Storage Accounts
    * These were added by Vectra after the initial availability of CDR for Azure. As per the below guidance, run the main deployment and remediation steps again to add ingestion for these if your original deployment did not include Storage Account ingestion.

As Vectra continually does security research, additional log types may be supported in the future. Running the ARM template deployment process is an idempotent process. The same steps can be run again in the future, and nothing will change with resources that Vectra has already deployed. Below you will find guidance for specific situations you may encounter.

## Remediation of newly deployed supported resources

Situation:

* You are adding new resources to azure locations/regions that were covered during a previous deployment of Vectra CDR for Azure. These new resources also are of a type that was already supported by Vectra during a previous deployment of Vectra CDR for Azure.

Outcome:

* If you used the [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment):
  * The new resources are automatically made compliant by Azure because the policies that Vectra put in place apply to the supported resources in these locations/regions. No action needs to be taken by administrators.
* If you used the [manual deployment](/deployment/cdr-for-azure/deployment/manual-deployment):
  * You must ensure that logs for the new resources are being written to the storage accounts that were setup during deployment. You may be using Azure Policy to do this and if so, it might be automatic but do to the nature of manual deployment, Vectra cannot guarantee that the new resources are logging properly and CDR for Azure is ingesting their logs.

## Adding newly supported resource types for log collection

Situation:

* Vectra has added new supported resource types to Vectra CDR for Azure, and you want to make sure that these new resource types are covered by Vectra CDR for Azure.

Required Action:

* If you used the [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment):
  * Execute the main deployment and remediation steps again as outlined in the [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment).
* If you used the [manual deployment](/deployment/cdr-for-azure/deployment/manual-deployment):
  * Repeat the steps you did for manual deployment, ensuring that you are logging the new resource logs to the correct storage accounts for ingestion into CDR for Azure.

## Adding new locations/regions to your Azure deployment

Situation:

* Your organization has added new locations/regions to your overall Azure deployment, and you want to make sure that they are covered by Vectra CDR for Azure.

Required Action:

* If you used the [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment):
  * Execute the main deployment and remediation steps again as outlined in the [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment).
* If you used the [manual deployment](/deployment/cdr-for-azure/deployment/manual-deployment):
  * Repeat the steps you did for manual deployment, ensuring that you are logging correctly for the new locations/regions and supported resources to the correct storage accounts for ingestion into CDR for Azure.


# Appendix 3 - Troubleshooting issues while onboarding

Common onboarding issues, policy conflicts, and ARM template deployment errors.

## Azure Policies That May Interfere With Deployment

Some Azure built-in policies that may be in place in the deployment environment may interfere with successful completion of Vectra’s deployment templates. Policies that should be temporarily disabled during deployment are below:

1. **Storage accounts should have infrastructure encryption**
   * **Policy definition name**: AuditStorageAccountsInfrastructureEncryption
   * **Description**: Ensures that storage accounts have infrastructure encryption enabled, providing enhanced security.
2. **Storage accounts should prevent shared key access**
   * **Policy definition name**: AuditStorageAccountDisableSharedKeyAccess
   * **Description**: Audits if storage accounts allow shared key access, which is considered less secure than Azure AD-based authentication.
3. **Storage accounts should disable public network access**
   * **Policy definition name**: AuditStorageAccountsPublicNetworkAccess
   * **Description**: Evaluates if public network access is disabled to reduce the attack surface.

Vectra has instructions for [Configuring Private Access for Azure Storage Accounts](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#configuring-private-access-for-azure-storage-accounts) which will ensure that the deployment is compliant with item 3 above.

If your team has concerns with disabling any of the other policies above, please contact your Vectra account team.

## Azure Template Deployment Errors

This section covers errors that you may see during [automated deployment](/deployment/cdr-for-azure/deployment/automated-deployment) and includes both [executing the main deployment](/deployment/cdr-for-azure/deployment/automated-deployment#executing-main-deployment) and [remediating policies](https://docs.vectra.ai/deployment/cdr-for-azure/deployment/pages/skUrE7j6vzCo416qJqr9#id-5.-remediate-policies).

### Validation failed

**With "c is undefined":**

If you see this message when attempting to deploy either template, it typically means that you did not select the Management Group before template validation occurred. Simply go back, select the Management Group, and try again.

![](/files/5920af3e57af30ea7d42b205c18178142091d3c7)

### Your deployment failed

**And the error details provided by Azure do not show the real failure reason:**

If you see a **Your deployment failed** message and the details provided by Azure for the failure are not helpful, it may still be possible to find the real reason by looking in the Activity Log for the Management Group or Subscription.

![](/files/b9d1c7708ae3022fbcf63d65b1d2d79cf6a34bc9)

In this example above, the error details simply say that **The resource write operation failed to complete successfully, because it reached terminal provisioning state ‘Failed’**. This message is not very helpful. A more useful approach is to make use of Activity Logs in either (or both) Subscription Activity Logs or Management Group Activity Logs.

* In the Azure portal, navigate to *Management Groups*, and choose the Subscription or Management group that you specified in the deployment.
* Click on **Activity log** from the menu on the left.
* Adjust the **Timespan** filter as needed to look in a time range around your deployment.
* Policy template related deployments will typically have a `deployIfNotExists` policy action to look under.
  * In this case we can see that a previous deployment has re-used a deployment name that already exists in a different location. This is an example of a name collision during deployment.

![](/files/99c392ad17fd5486bf991b0bada9e73e6fbf7746)

### Resolving Name Collisions During Deployment

This error is not likely to occur for most customers who only do deployment against a single Azure region. This does not mean that you deployment does not cover other regions/locations. It only refers to the region choice that was made during [executing the main deployment](/deployment/cdr-for-azure/deployment/automated-deployment#executing-main-deployment).

The most likely scenario is that you have done a deployment to a lab that exists in one region and have now decided to do the production deployment in a different region. The screenshot above is an example of such a case that happened during policy deployment. In this case, the first time the remediation task was created in **westus** and then the second time it was created in **eastus**. This causes a name collision. The easiest solution is to remove the previous deployment.

* From the Activity Log (see above), copy the duplicate name that is causing the error.
  * In this case it is `PolicyDeployment_9064182556784760002`.
* You will see from the resource name that you need to look at the subscription level for this deployment.
* In your Azure Portal, navigate to the subscription and then click into **Deployments** and search for this deployment name and **Delete** it.

![](/files/315a6b32b1baaa0b5f4996e2739019bc99275fb1)

* Now you should be able to retry the deployment step where this name collision occurred.

### Azure has a limit of 5 diagnostic settings for a resource.

Vectra does not expect this limitation to be an issue for most customers. If you run into this issue, please contact your account team to discuss options.

## Azure Data Source Connector Potential Issues

You may see a variety to status messages on your Microsoft Azure Data Source connection. A green checkmark means all is well. Other status messages may require attention.

**Connection is paired and Last Seen / Last Log Received is recent.**

<div align="left"><img src="/files/9ff0daab75d5ce392140e51d51bf6e012ea5e0ae" alt="" width="163"></div>

Last Seen: Feb 20 2020, 13:02

Last Log Received: Feb 20 2020

This condition is not an issue and is the expected state when all is well.

***

**Connection has been created, but not paired:**

<div align="left"><img src="/files/c176052104a5f2ea2d10fc38d24907d853d259f5" alt="" width="261"></div>

Edit this connection and use the Connection Setup Link to authorize Vectra to analyze your CDR for Azure logs.

***

**Permissions upgrade case:**

<div align="left"><img src="/files/ec49a948a8e5f8699508ebf2150b136ac7c5f516" alt="" width="236"></div>

This connection is working but its logs are degraded due to missing privileges. To fix this issue, edit this connection and use the setup link.

***

**Connection is paired but not forwarding:**

<div align="left"><img src="/files/059a74560f3a4fc398b0aa2f1fa05cc56e1bb7dc" alt="" width="353"></div>

There is an issue in connecting Vectra with the consent service. Please reach out to your Vectra admin or try again later.

<div align="left"><img src="/files/174f14bee0ead95e9367392eebb1598e4f8c76be" alt="" width="195"></div>

Consent for CDR for Azure is revoked. To fix, edit this connection, copy the link use to [1. Grant Vectra Access](https://docs.vectra.ai/deployment/cdr-for-azure/deployment/pages/skUrE7j6vzCo416qJqr9#id-1.-grant-vectra-access), and send it to your Azure administrator.

<div align="left"><img src="/files/cb8e3c920878acfe368e8e7953ae9880b13d6f1b" alt="" width="294"></div>

It has been more than X minutes since this connection has been seen. Last Seen: Feb 20 2020, 13:02

<div align="left"><img src="/files/888fd4e1fe452fcb07758f87f93c8da875c56c78" alt="" width="225"></div>

It has been more than X minutes since a log has been received. Last Log Received: Feb 20 2020, 13:02

<div align="left"><img src="/files/80f3c8c33cbaf4db20fbd40d5bd89f7f3946c7d5" alt="" width="327"></div>

The token returned by the consent service has insufficient permissions. Please ensure that consent has been granted and try again.

<div align="left"><img src="/files/a3249d72df24c0c734b889d493986025f3ca89e3" alt="" width="263"></div>

There was an error during the token validation process. Please ensure that consent has been granted and try again.


# NDR physical appliances

Quick start and hardware guidance for physical Brain and Sensor appliances.

{% content-ref url="/pages/XyGxRDuiuFsHqkpIBLqV" %}
[Supported SFPs and QSFPs](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps)
{% endcontent-ref %}

{% content-ref url="/pages/jaXws7PQs4aA0QiQT5MO" %}
[Physical appliance modes and switching between them](/deployment/ndr-physical-appliances/physical-appliance-modes-and-switching-between-them)
{% endcontent-ref %}

{% content-ref url="/pages/jJ4gIn5XsN5bpEMyO40U" %}
[X-Series](/deployment/ndr-physical-appliances/x-series)
{% endcontent-ref %}

{% content-ref url="/pages/xQ2RZLMghXmJE77wtPNn" %}
[B-Series](/deployment/ndr-physical-appliances/b-series)
{% endcontent-ref %}

{% content-ref url="/pages/oxHdk3i0XcRjRu5CGn7t" %}
[S-Series](/deployment/ndr-physical-appliances/s-series)
{% endcontent-ref %}

{% content-ref url="/pages/2WTllSyWglIUyN8rDH43" %}
[M-Series](/deployment/ndr-physical-appliances/m-series)
{% endcontent-ref %}


# Supported SFPs and QSFPs

Supported SFP/QSFP transceivers for Vectra physical appliances.

## Applicability and Supporting Information

Please refer to the [Appliance and Sensor Specifications](/deployment/getting-started/appliance-specifications) article for details on the various Vectra physical appliances and types of interfaces offered by each model. When selecting SFPs to be supplied by Vectra as part of an order, or when sourcing SFPs from other vendors, it is important to match the SFP module to the SFPs supported in your target appliance.

### Nomenclature for SFP Types

Many people refer to all different SFP types as "SFPs" but in reality there are many different types such as SFP, SFP+, SFP28, QSFP, QSFP+, etc. The specific name refers to specifications supported, and typically the bandwidth supported is the main differentiating factor. When Vectra generically speaks of an "SFP" it is typically referring the overall category of SFPs and not a specific variant.

There are 2 main physical sizes: SFP and QSFP

* QSFPs are both wider and deeper than SFPs but they are both the same height.
* Some backwards compatibility exists between the different standards as well.
  * For example, a QSFP28 slot can be filled with a QSFP28 transceiver module, but it could also take a QSFP+ or even a SFP+ module (SFP+ requires a physical adapter to make it fit into a QSFP size slot).

For more details on the different standards, please see this Wikipedia article: <https://en.wikipedia.org/wiki/Small_Form-factor_Pluggable>

From a Vectra perspective, the main thing to keep in mind is what size slot you have and the maximum bandwidth supported in the port. This can be found in the [Supported SFP Modules per Physical Appliance Model](#supported-sfp-modules-per-physical-appliance-model) below and is also in the [Appliance and Sensor Specifications](/deployment/getting-started/appliance-specifications) article.

## Supported SFP Transceivers

Vectra recommends using only Vectra supported SFPs in Vectra appliances.

{% hint style="info" %}
**Please Note:**

Each table below lists modules that have been validated and are supported by Vectra when purchased through Vectra.

They also label if the module is available for purchase through Vectra "**Vectra supplied"**, or if the module has been validated by Vectra but must be purchased through other channels **"procured elsewhere"**.
{% endhint %}

{% hint style="info" %}
**Please Note:**

Vectra cannot guarantee successful operation for SFP transceivers not listed below. Genuine SFPs from reputable vendors which are fully compliant with all relevant specifications are expected to work normally and reliably. When using a module that is not supported by Vectra, support advice will be on a best effort basis.
{% endhint %}

#### SFP or SFP+ - Supported modules (Vectra supplied)

|                  |                  |               |                                                                                                                             |
| ---------------- | ---------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **SFP Type**     | **Manufacturer** | **Model**     | **Specifications Link**                                                                                                     |
| 10 GbE SR SFP+   | Intel            | E10GSFPSR     | [CDW Product Page](https://www.cdw.com/product/intel-sfp-transceiver-module/1957390#PO)                                     |
| 10 GbE LR SFP+   | Intel            | E10GSFPLR     | [CDW Product Page](https://www.cdw.com/product/intel-ethernet-sfp-lr-optics-sfp-transceiver-module-gige-10-gige/1994896#PO) |
| 1 GbE Copper SFP | Finisar          | FCLF8522P2BTL | [CDW Product Page](https://www.cdw.com/product/finisar-fclf8522p2btl-sfp-mini-gbic-transceiver-module-gige/2542897#PO)      |

#### SFP28 - Supported modules (Vectra supplied)

| SFP28 Type      | Manufacturer | Model    | Specifications Link                                                                                                                                                                                                                                                                                  |
| --------------- | ------------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 25 GbE SR SFP28 | Dell         | 407-BCHI | [Dell Product Page](https://www.dell.com/en-us/shop/dell-emc-poweredge-25gbe-sfp28-sr-85c-optic-customer-install/apd/407-bchi/networking?gacd=9646510-1028-5761040-266706306-0\&dgc=st\&ds_rl=1282789\&gclid=EAIaIQobChMIirP5sI7Z8AIVsyitBh0r8AMMEAAYASAAEgJgKPD_BwE\&gclsrc=aw.ds#overview_section) |

#### QSFP+ or QSFP28 - Supported modules (Vectra supplied)

<table><thead><tr><th width="183.84765625">QSFP Type</th><th width="139.953125">Manufacturer</th><th width="157.0546875">Model(s)</th><th width="276.04296875">Specifications Link</th></tr></thead><tbody><tr><td><p>40 GbE SR QSFP+</p><p>40 GbE SR QSFP+<br>40 GbE SR QSFP+</p></td><td><p>Dell</p><p>Finisar<br>Mellanox</p></td><td><p>407-BBOZ</p><p>FTL410QE4C<br>MMA1B00-B150D</p></td><td><p><a href="https://www.dell.com/en-us/shop/dell-networking-transceiver-40gbe-qsfp-sr-optics-850nm-wavelength-100-150m-reach-on-om3-om4/apd/407-bboz/networking?gacd=9646510-1028-5761040-266706306-0&#x26;dgc=st&#x26;ds_rl=1282789?gclid=EAIaIQobChMI5fCdyJHZ8AIV7h-tBh2SSAJoEAAYAiAAEgJ5N_D_BwE&#x26;gclid=EAIaIQobChMI5fCdyJHZ8AIV7h&#x26;gclsrc=aw.ds#tabs_section">Dell Product Page</a></p><p><a href="https://www.coherent.com/networking/transceivers/datacom/FTL410QE4C">Datasheet</a><br><a href="https://docs.nvidia.com/networking/display/mma1b00b150dspec">Datasheet</a></p></td></tr><tr><td>40 GbE LR QSFP+</td><td>Mellanox</td><td>MC2210511-LR4</td><td><a href="https://network.nvidia.com/pdf/prod_cables/PB_MC2210511-LR4_40Gbps_QSFP+_SMF_Transceiver.pdf">NVIDIA Specifications PDF</a><br>(NVIDIA owns Mellanox)</td></tr><tr><td>100 GbE SR QSFP28</td><td>Dell</td><td>407-BCEX</td><td><a href="https://www.dell.com/en-us/work/shop/dell-emc-poweredge-qsfp28-sr4-100gbe-85c-optic-customer-install/apd/407-bcex/networking">Dell Product Page</a></td></tr><tr><td>100 GbE LR QSFP28</td><td>Mellanox</td><td>MMA1L10-CR</td><td><a href="https://network.nvidia.com/pdf/prod_cables/PB_MMA1L10-CR_100GbE_QSFP28_LR4_Transceiver.pdf">NVIDIA Specifications PDF</a><br>(NVIDIA owns Mellanox)</td></tr></tbody></table>

#### QSPFP+ or QSFP28 BiDi - Supported modules (procured elsewhere)

{% hint style="info" %}
**Please Note:**

The 40 and 100 GbE BiDi QSFPs listed below were only validated for use in the S101 appliance. They have not been validated by Vectra for supported use in any other appliance.

These modules were previously available for purchase through Vectra but due to low demand, Vectra no longer offers these modules for purchase. If you wish to use either, you must procure them elsewhere and support will be on a best effort basis.
{% endhint %}

<table><thead><tr><th width="212.4296875">QSFP Type</th><th>Manufacturer</th><th>Model(s)</th><th>Specifications Link</th></tr></thead><tbody><tr><td>40 GbE SR BiDi QSFP+</td><td>Cisco</td><td>QSFP-40G-SR-BD</td><td><a href="https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/data_sheet_c78-660083.html">Cisco Data Sheet</a></td></tr><tr><td>100 GbE SR BiDi QSFP28</td><td>Cisco</td><td>QSFP-40/100-SRBD</td><td><a href="https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/at-a-glance-c45-740242.pdf">Cisco Data Sheet</a></td></tr></tbody></table>

#### SFP+ 10 GbE Copper - Supported modules (procured elsewhere)

<table><thead><tr><th width="229.54296875">SFP Type</th><th width="136.7265625">Manufacturer</th><th width="140.703125">Model</th><th>Specifications Link</th></tr></thead><tbody><tr><td>10 GbE Copper SFP+ 30m</td><td>FS</td><td>SFP-10G-T-30</td><td><a href="https://www.fs.com/products/89577.html">FS #89577 Product Page</a></td></tr><tr><td>10 GbE Copper SFP+ 80m</td><td>FS</td><td>SFP-10G-T-80</td><td><a href="https://www.fs.com/products/200049.html">FS #200049 Product Page</a></td></tr><tr><td>10 GbE Copper SFP+ 30m</td><td>FS</td><td>SFP-10G-T-30I</td><td><a href="https://www.fs.com/products/111943.html">FS #111943 Product Page</a> (“I” is for Industrial variant)</td></tr><tr><td>10 GbE Copper SFP+ 100m</td><td>FS</td><td>SFP-10G-T-100</td><td><a href="https://www.fs.com/products/154924.html">FS #154924 Product Page</a></td></tr></tbody></table>

#### SFP+ Data Diodes - Supported modules (must be procured elsewhere)

| SFP Type                  | Manufacturer | Model             | Specifications Link                                     |
| ------------------------- | ------------ | ----------------- | ------------------------------------------------------- |
| 10 GbE Singlemode RX SFP+ | Patton       | SFX-SC92DR-0031-A | [Patton Product Page](https://www.patton.com/sfx-10dd/) |
| 10 GbE Singlemode TX SFP+ | Patton       | SFX-SC92DT-3100-A |                                                         |

* Please see [Sensor Data Diode SFP+ Support](#Data_Diode) for additional details if a data diode is required for your deployment.

### Supported SFP Modules per Physical Appliance Model

Please see the quick start guides for your specific physical appliance to see port diagrams showing the interfaces available. Some appliances offer options to configure a capture port SFP for use as the management port. Your appliance may support several, only one, or no SFPs.

{% hint style="info" %}
**Please Note (SFPs available at no cost or for an added cost):**

These purchasing guidelines apply to SFPs ordered as part of your appliance order:

* Up to 2 (if supported by your appliance model) SFP, SFP+, or SFP28 modules can be included at no additional cost in your Vectra appliance order.
  * This is valid for each appliance in your order.
* Additional SFP(s) of any type over the two specified above will incur additional cost.
* All 40/100G QSFPs will incur additional cost over the base price of the appliance.
  {% endhint %}

{% hint style="info" %}
**Please Note (SFP module compatibility in each appliance):**

In general, all supported SFPs in the charts above are supported for use with any appliance that has a port capable of holding the SFP in question. The exception to this rule is that the BiDi SFPs are only supported for use with the S101 appliance.

* SFP, SFP+, and SFP28 SFPs are all the same size.
  * SFP and SFP+ SFPs will function in an SFP28 slot.
* QSFP slots are physically larger but Vectra can supply an adapter with your appliance order if you need to use an SFP, SFP+, SFP28, or QSPF+ SFP in your QSFP28 slot.

**Example:**

If you have an S127 appliance and need to use a copper capture port, you can get a 1 GbE copper SFP through Vectra that will fit into a 10/25 GbE SFP28 slot, or you can ask for an adapter for a QSFP28 slot to allow that adapter to fit into the QSFP28 slot. You could also purchase a supported 10 GbE copper SFP+ through a 3rd party and also fit it similarly.
{% endhint %}

<table><thead><tr><th width="114.609375" align="center">Appliance</th><th width="252.8828125" align="center">SFP MGT Interfaces</th><th width="394.53125" align="center">SFP Capture Interfaces</th></tr></thead><tbody><tr><td align="center">S1</td><td align="center">1 x 10 GbE SFP+<br>If <code>management</code> set to <code>sfp</code></td><td align="center">Up to 2 x 10 GbE SFP+<br>If <code>capture</code> is set to <code>SFP</code></td></tr><tr><td align="center">S1v2</td><td align="center">1 x 10 GbE SFP+<br>If <code>management</code> set to <code>sfp</code></td><td align="center">2 x 10 GbE SFP+</td></tr><tr><td align="center">S11</td><td align="center">N/A<br>(copper only, no SFPs)</td><td align="center">N/A<br>(copper only, no SFPs)</td></tr><tr><td align="center">S101</td><td align="center">2 x 10 GbE SFP+</td><td align="center">2 x 10 GbE SFP+<br>2 x 10/25 GbE SFP28</td></tr><tr><td align="center">S127</td><td align="center">2 x 10/25 GbE SFP28</td><td align="center">2 x 10/25 GbE SFP28<br>2 x 10/25/40/100 QSFP28</td></tr><tr><td align="center">X3</td><td align="center">N/A</td><td align="center">2 x 10 GbE SFP+</td></tr><tr><td align="center">X29</td><td align="center">1 x 10 GbE SFP+<br>If <code>management</code> set to <code>sfp</code></td><td align="center">2 x 10 GbE SFP+<br>Only 1 SFP+ if <code>management</code> set to <code>sfp</code></td></tr><tr><td align="center">X47</td><td align="center">1 x 10/25 GbE SFP+<br>If <code>management</code> set to <code>sfp</code></td><td align="center">2 x 10/25 GbE SFP28<br>Only 1 SFP28 if <code>management</code> set to <code>sfp</code></td></tr><tr><td align="center">B101</td><td align="center">2 x 10 GbE SFP+</td><td align="center">N/A<br>(Brain only, no capture support)</td></tr><tr><td align="center">B127</td><td align="center">2 x 10/25 GbE SFP28</td><td align="center">N/A<br>(Brain only, no capture support)</td></tr><tr><td align="center">M29</td><td align="center">1 x 10 GbE SFP+<br>If <code>management</code> set to <code>sfp</code></td><td align="center">N/A<br>(Stream only, no capture support)</td></tr><tr><td align="center">M47</td><td align="center">1 x 10 GbE SFP+<br>If <code>management</code> set to <code>sfp</code></td><td align="center">N/A<br>(Stream only, no capture support)</td></tr></tbody></table>

## Speed Negotiation for SFP Interfaces

The Intel NICs used in Vectra appliances do not support dual-speed negotiation for SFP+ interfaces. For this reason, the capture port NICs will only operate at the highest speed available for the inserted SFP and will not attempt to negotiate a lower speed. For example, a 1G/10G SFP+ module inserted into a 10G SFP+ socket will only support 10G link speeds, even if the underlying SFP+ supports link speed negotiation down to 1G link speeds.

Should a dual-speed SFP be installed in a Vectra appliance, and be connected to a 1G interface one of the following symptoms may occur. These symptoms may not be consistent and depend on the specific SFP installed:

* The port may not bring the link up correctly and may show link down.
* The port may bring the link up inconsistently at 1G or 10G.
* The port state may be reset during appliance reboot or software upgrade, after which it may present either of the above symptoms.

These issues are a result of underlying hardware constraint for the Intel NIC and cannot be resolved with future software updates.

Single-speed SFPs (1G or 10G) do not exhibit these symptoms and for this reason, Vectra recommends that all customers order SFPs to match the expected link speed for the peer device.

## Direct-Attach-Copper cables

* The Intel NICs used in Vectra appliances are expected to be compatible with SFP+ passive or active limiting direct attach copper cables that comply with the SFF-8431 v4.1 and SFF-8472 v10.4 specifications.
  * Cables up to 7m in length are expected to work.
* Only SFP+ (10G) DAC are compatible with Vectra NICs.
  * SFP (1G) DAC will not operate in any circumstances in Vectra interface ports.
* Vectra does not actively test DAC cables with Vectra appliances.
  * If you wish for Vectra to test specific cables in advance of purchasing a Vectra appliance please contact your account team or Vectra Support to discuss your requirements.

## Cloned or Low-Quality SFP Transceivers

Customers should note that many unbranded or clone optics are readily available which are not compliant with all specifications or illegitimately claim to be manufactured by another vendor. In these cases performance, reliability and compatibility are likely to suffer and in many cases, the link will not come up. Customers may find that rebooting the appliance resets the link state for these SFPs and may cause these SFPs to successfully negotiate links that they did not before. Illegally cloned transceivers claiming to be Intel SFPs will cause the Intel NIC to shut down all ports until they are removed. We cannot recommend the use of these transceivers in any Vectra device.

## Guidance for QSFP Interfaces

Some Vectra appliances, like the S101v2, include QSFP28 interfaces and can support SFPs that work up to 100 Gbps. This does not necessarily mean that the appliance can process 100 Gbps of traffic just because the physical interface supports 100 Gbps. The maximum performance of the given appliance is specified in the [Appliance and Sensor Specifications](/deployment/getting-started/appliance-specifications) article. Please expand or collapse the section below to learn more about QSFP support and such options as using break out cables.

<details>

<summary>Expand/Collapse for details</summary>

The QSFP interfaces on the S101v2 platform support 10G SFP+ (with adapter), 25G SFP28 (with adapter), 40G QSFP+ or 100G QSFP28 that fully comply with all standards. Deployments may freely connect any combination of these ports, including multiple 40G ports in combination with multiple 10G ports (depending on number of interfaces in the appliance).

For supported SFPs, please see the tables in the [Supported SFP Transceivers](#Supported_SFPs) section above.

When using multiple ports, for example on an S101v2, where the total Ethernet bandwidth available exceeds 50G the total traffic throughput of the system across all ports should not be allowed to exceed 50G.

The QSFP interfaces on the S101v2 platform with a 40G QSFP+ may only be configured as a single port using all four 10G lanes.

QSFP breakout cables are supported, but they have extremely limited use cases and are unlikely to be a practical option. The use of breakout cables require that all 4 SFP+ modules be connected to a single switch with the four ports configured to operate as a single 40G interface. Typically a single 40Gb QSFP+ link or individual 10Gb links across multiple interfaces will be a superior solution.

For this reason there is usually no benefit in connecting breakout cables to the 40G interfaces. Breakout cables may still be used but only where the four 10G lanes are connected to an appropriate endpoint also configured in 1x40G mode. The four 10G lanes cannot be configured in 4 x 10G mode as four separate interfaces.

For customers requiring four 10G interfaces the S101v2 may be configured to use the two 10G ports in 10G mode and the two 40G interfaces in 10G mode using appropriate 10G SFPs. Vectra does not provide any recommendations for 10G SFPs compatible with QSFP ports however can confirm that we have tested the combination of the Mellanox MAM1Q00A-QSA28-S and the Intel E10GSFPSR. This combination is known to be fully compatible. Vectra does expect for any high quality solutions from well reputed vendors to work without issue.

It is exceptionally important to note the comments in the section above for cloned or low quality SFPs. Third party SFPs have an increased chance of being non-compliant with standards and an increased chance of interface instability or errors.

Vectra cannot recommend the use of any SFPs not fully compliant with all relevant SFP standards and expects for these SFPs to offer inconsistent and unpredictable behaviors.

</details>

## Sensor Data Diode SFP+ Support

Certain customers in highly secure environments require support for data diodes that allow network traffic to flow only in one direction. Vectra expects that Data Diode support will typically only be required in certain government or military environments where data diode use is enforced by policy. Please expand the section below to see details about Data Diode support in a FAQ.

<details>

<summary>Expand/Collapse for details</summary>

**What is a Data Diode?**

According to Wikipedia: A unidirectional network (also referred to as a unidirectional gateway or data diode) is a network appliance or device that allows data to travel in only one direction. Data diodes can be found most commonly in high security environments, such as defense, where they serve as connections between two or more networks of differing security classifications. Given the rise of industrial IoT and digitization, this technology can now be found at the industrial control level for such facilities as nuclear power plants, power generation and safety critical systems like railway networks.

![](/files/3zot3IAAIDKj8vC31OAM)

**How does Vectra support Data Diode requirements?**

Vectra supports data diodes on any of our physical appliance Sensor capture ports that support SFP+ 10 Gbps connections. Please see [Supported\_SFPs](#Supported_SFPs) for details.

The method of support is that Vectra has validated specific SFP+ modules that function as data diodes. These SFP+ modules will always be deployed in pairs:

* One RX module in the Vectra Sensor.
* One TX module in the switch or packet broker, etc that feeds the Sensor network traffic.

Vectra physical appliance capture ports already operate in a manner where they do not get an IP from the local network and do not communicate on the customer network. Using a data diode SFP+ makes it physically impossible for the Sensor to send any traffic and complies with specifications that require data diodes.\
The use of a data diode is essentially invisible to the Vectra software and all functions behave normally.\
Traditional SFP+ modules often require a hardware handshake over a TX/RX pair of fibers. Data diode SFP+ modules do not require a handshake and do not even have 2 fiber connectors as seen below:\
![](/files/uskatHs67X3fX1wGf0mM)

**Which SFP+ modules does Vectra officially support?**

Vectra has validated the following Patton data diode modules:

* SFX-SC92DR-0031-A
  * Single Mode RX for your Vectra Sensor
* SFX-SC92DT-3100-A
  * Single Mode TX for your switch, packet broker, etc

Additional information can be found at <https://www.patton.com/sfx-10dd/>\
Modules that Vectra has not validated may work but Vectra has not tested them and if issues are encountered support will be a best effort. If you have needs for other validated modules, please work with you Vectra account team to prioritize module validation with Vectra's product management and engineering teams.

**Can Vectra supply the Data Diode SFP+ modules?**

Vectra does not offer Data Diodes on their price list. Customers requiring them will need to procure and install them separately.

</details>


# Physical appliance modes and switching between them

The article describes the Brain, Sensor, and Mixed modes and how to switch between them for physical Vectra appliances.

## **Available Appliance Modes**

Vectra physical appliances operate in one of three modes:

<table><thead><tr><th width="100" align="center"></th><th></th></tr></thead><tbody><tr><td align="center"><strong>Mode</strong></td><td><strong>Description</strong></td></tr><tr><td align="center">Sensor</td><td><ul><li>Captures / deduplicates raw network traffic.</li><li>Houses rolling capture buffer to enable PCAP retrieval when requested from the Brain.</li><li>Forwards metadata to the Brain.</li><li>Must be paired to a Brain.</li></ul></td></tr><tr><td align="center">Brain</td><td><ul><li>Pairs with Sensors (network data sources) and processes / deduplicates forwarded metadata.</li><li>Optionally forwards the metadata received from Sensors when licensed for Stream (RUX and QUX) or Recall (QUX only).</li><li>Communicates with the Vectra Cloud in RUX deployments.</li><li>Communicates with local integration points.</li><li>Serves the UI in QUX deployments.</li></ul></td></tr><tr><td align="center">Mixed</td><td><ul><li>Performs both Brain and Sensor functions.</li></ul></td></tr></tbody></table>

* [B-Series appliances](/deployment/ndr-physical-appliances/b-series) can only be deployed in Brain mode.
* [S-Series appliances](/deployment/ndr-physical-appliances/s-series) can only be deployed in Sensor mode.
* [X-Series appliances](/deployment/ndr-physical-appliances/x-series) can be deployed in Brain, Sensor, or Mixed modes.
* All [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances) support only Brain or Sensor mode.
  * Virtual appliances do NOT support Mixed mode.

## **Determining the Current Mode**

To display the current mode of a Vectra appliance:

* Login on the appliance cli as the user `vectra` .
  * See [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) for more details.
* Run the command `show mode` .

Example Below:

```ckeditor_codeblock
vscli > show mode
Mode: mixed
```

## **Switching Between Modes**

The method for converting a Vectra appliance from one mode to another depends on the appliance's present mode. The following table summarizes the supported mode conversion:

<table><thead><tr><th width="139.83984375" align="center">Current Mode</th><th width="137.2109375" align="center">Desired Mode</th><th>Applicability and Guidance</th></tr></thead><tbody><tr><td align="center">Brain</td><td align="center">Sensor</td><td><p>Contact Vectra Support</p><ul><li>Brain data will be lost during conversion.</li><li>Appliance will reboot and come up in Sensor mode.</li></ul></td></tr><tr><td align="center">Brain</td><td align="center">Mixed</td><td><p>Perform <code>set mode mixed</code> at the CLI of your Brain.</p><ul><li>There will be no data loss.</li></ul></td></tr><tr><td align="center">Sensor</td><td align="center">Brain</td><td>Not supported</td></tr><tr><td align="center">Sensor</td><td align="center">Mixed</td><td>Not supported</td></tr><tr><td align="center">Mixed</td><td align="center">Brain</td><td><p>Perform <code>set mode brain</code> at the CLI of your Brain.</p><ul><li>There will be no data loss.</li><li>Match must be disabled on the Mixed mode appliance before attempting conversion. See <strong>Please Note:</strong> box below for more details.</li></ul></td></tr><tr><td align="center">Mixed</td><td align="center">Sensor</td><td><p>Contact Vectra Support</p><ul><li>Brain data will be lost during conversion</li><li>Appliance will reboot and come up in Sensor mode</li></ul></td></tr></tbody></table>

**As you can see from the above table:**

* It is straightforward to toggle an appliance between Mixed-mode and Brain mode.
  * The provided commands should be entered at the CLI while logged in as the `vectra` user.
* Vectra Support will need to be engaged to convert a Brain or Mixed-mode appliance to Sensor mode.

{% hint style="warning" %}
**Please Note:**

* Conversion to Sensor mode is a one way process.
* Once an appliance has been converted to Sensor mode, it cannot later be reverted or converted back to Brain or Mixed mode.
* Conversion from Mixed to Brain mode is NOT supported when Match is enabled on the Mixed mode appliance.
  * Please disable Match on the Mixed mode appliance before attempting conversion.
  * Vectra plans to add a warning about this to the CLI command in v9.12 and above and disallow conversion attempts with Match enabled.
    {% endhint %}


# X-Series

Quick start guides and lifecycle notes for X-Series appliances.

{% content-ref url="/pages/y2UOXUpYWbXiAUChvVjx" %}
[X3](/deployment/ndr-physical-appliances/x-series/x3)
{% endcontent-ref %}

{% content-ref url="/pages/HhOXVHFwONvBNGv065Iw" %}
[X47](/deployment/ndr-physical-appliances/x-series/x47)
{% endcontent-ref %}

{% content-ref url="/pages/fepau5vpVAsWhYYWK47c" %}
[X29 (EOS)](/deployment/ndr-physical-appliances/x-series/x29)
{% endcontent-ref %}

{% content-ref url="/pages/C1ogJnC4LmaGRm68qkIj" %}
[X80 (EOL)](/deployment/ndr-physical-appliances/x-series/x80)
{% endcontent-ref %}


# X3

The X3 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

This document is intended to help customers or partners with the initial configuration of a physical Vectra X-Series appliance.

X-Series appliances can be used in Vectra deployments that use either the Respond UX or the Quadrant UX. The Respond UX is served from Vectra’s cloud and the Quadrant UX is served locally from the Brain appliance. For more detail on Respond UX vs Quadrant UX please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux).

X-Series appliances can be deployed in 3 modes (Brain, Sensor, or Mixed). Modes are discussed further in your deployment guide (see links below) and in [Physical appliance modes](/deployment/ndr-physical-appliances/physical-appliance-modes-and-switching-between-them).

The initial setup of the networking connectivity for an X-Series appliance will be nearly identical for all 3 modes. The only difference will be that for an X-Series appliance in Sensor mode, DNS can only be configured at the command line. For Brain or Mixed mode deployment, DNS can be configured at the command line or in the GUI.

One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your X-Series appliance following this guide, you can move on to [pairing appliances](/deployment/appliance-operations/pairing-appliances) or other recommended [next steps](#next-steps).

Guides for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## X3 Package Contents

* 1 X3 system with rail kit
* 2 power supply cords (matching requested type)
* Vectra bezel
* SFPs and QSFPs (matching details of your order)
  * See [SFPs and QSFPs supported in Vectra appliances](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) for options and additional detail.

## Physical Connections

![X3 Back Panel (click to enlarge)](/files/669c6f725d4de17302baf4ef3865c371c29eb5ed)

![X3 Front Panel (click to enlarge and see disk numbers)](/files/f5982fba596e732619d4a4a3d90ef343b9f5648e)

### Physical Connections Added Guidance

* If you have questions on rail installation, watch this video: <https://www.youtube.com/watch?v=JfOTnRMeE5w>
* If an X3 is used in Brain mode, the capture ports are not supported. Only the MGT interfaces will function.
* There is an additional USB port on the front right-hand side that can be used for KVM.
  * You can use these or the rear USB ports for KVM.
  * The iDRAC Direct micro port under this front USB port is not supported. Please use the ethernet iDRAC port on the rear of the chassis for iDRAC/IPMI use.
* The X3 has four 960 GB SSD drives.
  * Should any ever need replacing, contact Vectra support and refer to the diagram above for location.

### Minimum Connections

* Power
  * The X3 has dual auto sensing power supplies supporting 100-240 VAC supply at 50 or 60 Hz.
  * It is recommended to connect both power supplies for redundancy.
* MGT1 - RJ-45 ethernet (1 Gbps copper)
  * This is the port that will need to be configured with an IP address in your network.
* Capture - RJ-45 ethernet (1 Gbps copper), or SFP+ if deploying in Mixed or Sensor mode.
  * At least one of the capture interfaces (ports) must be connected when you are ready to begin capturing traffic for analysis.

## Performance

| **Brain Mode** | **Sensor Mode** | **Mixed Mode** | **Sensor (Match) Mode** | **Mixed (Match) Mode** |
| :------------: | :-------------: | :------------: | :---------------------: | :--------------------: |
|     15 Gbps    |      9 Gbps     |     8 Gbps     |          3 Gbps         |         1 Gbps         |

**Definitions:**

* For an appliance in Sensor mode:
  * Bandwidth number shown refers to the amount of network traffic observed that the appliance can produce metadata for (capture bandwidth).
* For an appliance in Brain or Mixed mode:
  * Bandwidth number shown refers to the aggregate amount of traffic observed by paired Sensors and the Mixed mode Brain that the appliance can process metadata for (aggregate bandwidth).
* **Brain Mode** - Appliance set to Brain mode, all traffic captured by paired Sensors.
* **Sensor Mode** - Appliance set to Sensor mode, no Brain functions performed by this X3.
* **Mixed Mode** - Appliance set to Mixed mode and performs both Brain and Sensor functions.
* **Sensor (Match) Mode** - Appliance set to Sensor mode with [Match](/deployment/match) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.
* **Mixed (Match) Mode** - Appliance set to Mixed mode with [Match](/deployment/match) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.

{% hint style="info" %}
**Please Note:**

While considering performance for the appliance it is important to understand that the traffic mix at customer sites varies widely. Some customers have traffic mixes that skew towards larger flows (think file transfers), and some will skew towards smaller flows (think DNS).

* Performance may be higher when the traffic mix skews towards larger flows.
* Performance will be lower when the traffic mix skews towards smaller flows as this produces more metadata for analysis.
* The stated performance is for average traffic mixes and should not be considered absolute.
  {% endhint %}

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1, S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the "set interface" command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

Instructions for configuring the DNS settings using the management GUI can be found in [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) or [Vectra Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment). This is only supported for Brain or Mixed mode configurations.

### Brain and Sensor Communications Requirements

A Sensor can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that the Sensor will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for the Sensor will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

It is recommended to check connectivity to the Brain from Sensors at the Sensor CLI. For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

To validate that you can connect to Vectra services, it is also recommended to use the `debug connectivity` command at your Brain’s CLI to check connectivity to the following endpoints:

* update2.vectranetworks.com
* api.vectranetworks.com
* Vectra Cloud Gateways that correspond to the region your tenant is deployed in when using the Respond UX (see the [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) for more details)
* rp.vectranetworks.com
* rs.vectranetworks.com

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity api.vectranetworks.com 443 --ssl
Connectivity: Success
Proxy: False
SSL: True
```

## Next Steps

### Proxy Support

If a proxy is required in your environment to reach Vectra’s Updater service (update2.vectranetworks.com or 54.200.156.238), a Sensor mode appliance will not be able to retrieve the Brain location from the Vectra Cloud to use online pairing. You will need to manually set the Brain IP or hostname when attempting pairing with your Brain because setting a proxy is not supported for Sensors. Instructions for pairing, including setting the Brain IP or hostname to pair with, is in [pairing appliances](/deployment/appliance-operations/pairing-appliances).

{% hint style="info" %}
This remainder of this section refers to appliances deployed in Brain mode or in Mixed mode.

Sensor mode appliances do not support communication through proxies to the Brain.
{% endhint %}

If a proxy is required in your environment to communicate with the Vectra cloud when deployed in Brain or Mixed mode, this can be set at the CLI of your appliance.

Login to the CLI is done using the `vectra` user account. The default password is `changethispassword` for a newly deployed Brain or mixed mode appliance. For more details see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli).

* Proxy commands:
  * `show proxy`
  * `set proxy config [IP or Hostname] [port] [USERNAME] [PASSWORD]`
  * `set proxy enable [on|off]`
  * Any of these with `-h` option will show command help with syntax.

Examples:

```
vscli > set proxy config 1.1.1.1 80 testuser testpass
Saving proxy config...
Proxy config updated
 
vscli > show proxy
Enabled: True
Host: 1.1.1.1
Port: 80
Authentication:
Authentication enabled: True
User: testuser
Password: **********
Method: basic
 
vscli > set proxy enable on
Updating proxy config...
Proxy enabled
```

### Pairing the Sensor to the Brain

After initial configuration, it is suggested to pair your Sensor with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.

### Traffic Capture Guidance

{% hint style="info" %}
This section applies to Mixed or Sensor mode configurations only.
{% endhint %}

{% hint style="info" %}
If capture ports are connected before pairing is completed, the Sensor will not buffer any traffic.
{% endhint %}

Simply point the traffic to be captured to your Sensor capture interfaces (ports). The Sensor will begin creating a metadata stream that will be analyzed by your Brain appliance. Sensors also have a rolling capture buffer that the Brain will request PCAPs from. The PCAPs will be attached as evidence with network detections as they are created.

Additionally, [Vectra packet capture](/deployment/traffic-engineering-and-validation/using-vectra-packet-capture-pcap) allows users to configure PCAPs to be downloaded from the Brain for analysis with 3rd party tools such as Wireshark.

**Guidance:**

* See [physical connections](#physical-connections) for the interfaces supported for capture use.
* Out of band deployment is the only supported method of traffic capture.
  * There is no inline mode for currently supported Vectra Sensor appliances.
* Traffic is typically forwarded to the Sensor via SPAN/COPY/MIRROR, traditional network TAPs, or 3rd party packet brokers.
* Capture ports do not get assigned IP addresses.
* The `show traffic stats` command, available at the Sensor’s CLI, may be useful to see if your traffic capture is successful before you can see the traffic graphs in your Brain’s GUI.
  * See [Traffic Graph showing no traffic (0 Mbps)](https://support.vectra.ai/vectra/article/KB-VS-1177) for more details.
* See [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture) for architecture guidance.
* See [Vectra Platform Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations) for what to capture.
* See [Asymmetry concerns in Vectra sensor feeds](/deployment/traffic-engineering-and-validation/asymmetry-concerns) for guidance around asymmetric flows.
* See [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv) for details on validating your traffic quality.

If required, Sensors can be configued to not allow PCAP creation when there are regulatory or privacy concerns. Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors* in your Vectra UI and edit the desired Sensor. Ensure the checkbox shown below is checked for Sensors you do not wish to perform any PCAP functions and then save your Sensor configuration:

<figure><img src="/files/bEcXhXME25EjIexgeAos" alt="" width="375"><figcaption></figcaption></figure>

### Logging in to the GUI (N/A in Sensor mode)

{% hint style="info" %}
For RUX deployments, you should not log in to the local GUI before connecting with the Vectra cloud. All UI based configuration for RUX deployments should be done in the RUX UI that is served from Vectra's cloud. For more details, please see the [Respond UX deployment guide](/deployment/getting-started/respond-ux-deployment-guide).
{% endhint %}

For QUX deployments, once an IP has been configured for the MGT1 interface of your Brain, you can access it using a modern browser such as Edge, Chrome, or Safari at <https://configured\\_IP> or the hostname if you have configured a hostname in your DNS for the Brain. The GUI can also be accessed via MGT2 at [https://169.254.0.10](https://169.254.0.10/) via direct connection. The default username is `admin` and the default password is `changethispassword`**.**

Please note that by default, Vectra uses a self-signed certificate to secure the user interface. As a result, the certificate causes SSL warning in most web browsers. Instructions for how to replace this with a customer-provided signed certificate can be found in [SSL certificate installation](/configuration/qux-specific/ssl-certificate-installation).

**For both the Respond UX and the Quadrant UX:**

After logging in to the GUI (for the Respond UX you will login to your Vectra tenant identified in your welcome letter), it is recommended to immediately change the `admin` password.

* Navigate to **My Profile** on the left-hand side of the screen
* Click on **Change Password** in the username/password area, fill in and save the form
* Password requirements - must be at least 8 characters long and contain at least
  * 1 digit (0-9), 1 upper case letter (A-Z), 1 lower case letter (a-z)
  * One symbol (\~!@#$%^&\*\_-+=\`| \ ( ){ }\[ ]:;”’<>,.?/)
* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# X47

The X47 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

This document is intended to help customers or partners with the initial configuration of a physical Vectra X-Series appliance.

X-Series appliances can be used in Vectra deployments that use either the Respond UX or the Quadrant UX. The Respond UX is served from Vectra’s cloud and the Quadrant UX is served locally from the Brain appliance. For more detail on Respond UX vs Quadrant UX please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux).

X-Series appliances can be deployed in 3 modes (Brain, Sensor, or Mixed). Modes are discussed further in your deployment guide (see links below) and in [Physical appliance modes](/deployment/ndr-physical-appliances/physical-appliance-modes-and-switching-between-them).

The initial setup of the networking connectivity for an X-Series appliance will be nearly identical for all 3 modes. The only difference will be that for an X-Series appliance in Sensor mode, DNS can only be configured at the command line. For Brain or Mixed mode deployment, DNS can be configured at the command line or in the GUI.

One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your X-Series appliance following this guide, you can move on to [pairing appliances](/deployment/appliance-operations/pairing-appliances) or other recommended [next steps](#next-steps).

Guides for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## X47 Package Contents

* 1 X47 system
* 1 Rail kit
* 2 Power supply cords (matching requested type)
* 1 Vectra bezel
* SFPs (matching details of your order)
  * See [SFPs and QSFPs supported in Vectra appliances](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) for options and additional detail.

## Physical Connections

<figure><img src="/files/ufecKPnxE4yxCzqccuQM" alt=""><figcaption><p>X47 Back Panel (click to enlarge)</p></figcaption></figure>

![X47 Front Panel (click to enlarge)](/files/bd17e523d7bb47bc126388136a849a2519a5ecdd)

### Physical Connections Added Guidance

* There is an additional USB and VGA port on the front right-hand side that can be used for console access.
  * You can use these or the rear USB ports for console access.
  * The iDRAC Direct micro port under this front USB port is not supported. Please use the ethernet iDRAC port on the rear of the chassis for iDRAC/IPMI use.
* The X47 has two 800 GB and four 1.92 TB SSD drives.
  * Should any ever need replacing, contact Vectra support and refer to the disk numbers on the chassis.
* See [SFP28 Management Option](#sfp28-management-option) for details on using the eth2 SFP28 port for management instead of capture.

### Minimum Connections

* Power
  * The X47 has dual auto sensing power supplies supporting 100-240 VAC supply at 50 or 60 Hz.
  * It is recommended to connect both power supplies for redundancy.
* MGT1 - 1 GbE copper RJ45 (default) or SFP28 10/25 GbE
  * Either of these ports will need to be configured with an IP address in your network.
  * The X47 can be configured by the customer to allow the port labeled as eth2 (10/25 GbE SFP28) on the back of the appliance to function as the MGT1 port.
    * See [SFP28 Management Option](#sfp28-management-option) if fiber is required)
* Capture
  * RJ-45 ethernet (1 Gbps copper) or SFP28 10/25 GbE if deploying in Mixed or Sensor mode.
  * At least one of the capture interfaces (ports) must be connected when you are ready to begin capturing traffic for analysis.

### SFP28 Management Option

The X47 can be configured by the customer to allow the port labeled as eth2 (10/25 GbE SFP28) on the back of the appliance to function as the MGT1 port. This will not give any performance benefit and is intended for use by customers who do not have any 1 GbE copper interfaces available for use as the MGT1 interface in the location in which they will deploy the X47 appliance.

<details>

<summary>Please expand for details if you wish to enable this option:</summary>

{% hint style="info" %}
Please note the following:

* Making this change will reduce the number of capture ports on the X47 appliance to 3 (1 x 10/25GbE SFP29 and 2x1 GbE copper interfaces) because one of the 10/25 SFP28 ports is now used for MGT1.
* It is recommended to use KVM, serial console, MGT2, or iDRAC/IPMI to connect to the appliance command line to make the change because unlike a SSH session, these will be unaffected by the change. See [Accessing the CLI](#accessing-the-cli) for details.
* For example, if you were connected to MGT1 in a staging area to make the change before moving into your data center where the 10 Gbps SFP+ was required, when the change is made your session would break and you would need to login again to configure a static address for the new MGT1 port.
* After making the change, physical port labels on the back of the appliance would no longer match how Vectra software displays the ports.
  * The port labeled as MGT1 changes to being unused by the Vectra software.
  * The port labeled as eth2 becomes MGT1.
  * The port labeled as eth3 becomes eth2.
* The `show interface` command at the CLI can be used to show the actual negotiated speed and state of MGT interfaces.
  {% endhint %}

CLI commands to show configured MGT1 interface speed setting and change speed setting:

```
show management
set management <default|sfp>

Examples:
vscli > show management
Management interface is set to default. See `show interface` for more information.

vscli > set management sfp
vscli > show management
Management interface is set to sfp. See `show interface` for more information.
```

{% hint style="info" %}

* Please note that after the change is made it will take up to a minute for the `show traffic stats` cli command to accurately reflect the reduced number of capture ports and the new eth numbering assignments.
* It will take the UI around 5 minutes to accurately reflect the reduced number of capture ports and the new eth numbering assignments.
  {% endhint %}

</details>

## Performance

| **Brain Mode** | **Sensor Mode** | **Mixed Mode** | **Sensor (Match) Mode** | **Mixed (Match) Mode** |
| :------------: | :-------------: | :------------: | :---------------------: | :--------------------: |
|     30 Gbps    |     20 Gbps     |     15 Gbps    |         13 Gbps         |         6 Gbps         |

**Definitions:**

* For an appliance in Sensor mode:
  * Bandwidth number shown refers to the amount of network traffic observed that the appliance can produce metadata for (capture bandwidth).
* For an appliance in Brain or Mixed mode:
  * Bandwidth number shown refers to the aggregate amount of traffic observed by paired Sensors and the Mixed mode Brain that the appliance can process metadata for (aggregate bandwidth).
* **Brain Mode** - Appliance set to Brain mode, all traffic captured by paired Sensors.
* **Sensor Mode** - Appliance set to Sensor mode, no Brain functions performed by this X3.
* **Mixed Mode** - Appliance set to Mixed mode and performs both Brain and Sensor functions.
* **Sensor (Match) Mode** - Appliance set to Sensor mode with [Match](/deployment/match) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.
* **Mixed (Match) Mode** - Appliance set to Mixed mode with [Match](/deployment/match) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.

{% hint style="info" %}
**Please Note:**

While considering performance for the appliance it is important to understand that the traffic mix at customer sites varies widely. Some customers have traffic mixes that skew towards larger flows (think file transfers), and some will skew towards smaller flows (think DNS).

* Performance may be higher when the traffic mix skews towards larger flows.
* Performance will be lower when the traffic mix skews towards smaller flows as this produces more metadata for analysis.
* The stated performance is for average traffic mixes and should not be considered absolute.
  {% endhint %}

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1, S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the "set interface" command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

Instructions for configuring the DNS settings using the management GUI can be found in [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) or [Vectra Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment). This is only supported for Brain or Mixed mode configurations.

### Brain and Sensor Communications Requirements

A Sensor can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that the Sensor will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for the Sensor will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

It is recommended to check connectivity to the Brain from Sensors at the Sensor CLI. For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

To validate that you can connect to Vectra services, it is also recommended to use the `debug connectivity` command at your Brain’s CLI to check connectivity to the following endpoints:

* update2.vectranetworks.com
* api.vectranetworks.com
* Vectra Cloud Gateways that correspond to the region your tenant is deployed in when using the Respond UX (see the [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) for more details)
* rp.vectranetworks.com
* rs.vectranetworks.com

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity api.vectranetworks.com 443 --ssl
Connectivity: Success
Proxy: False
SSL: True
```

## Next Steps

### Proxy Support

If a proxy is required in your environment to reach Vectra’s Updater service (update2.vectranetworks.com or 54.200.156.238), a Sensor mode appliance will not be able to retrieve the Brain location from the Vectra Cloud to use online pairing. You will need to manually set the Brain IP or hostname when attempting pairing with your Brain because setting a proxy is not supported for Sensors. Instructions for pairing, including setting the Brain IP or hostname to pair with, is in [pairing appliances](/deployment/appliance-operations/pairing-appliances).

{% hint style="info" %}
This remainder of this section refers to appliances deployed in Brain mode or in Mixed mode.

Sensor mode appliances do not support communication through proxies to the Brain.
{% endhint %}

If a proxy is required in your environment to communicate with the Vectra cloud when deployed in Brain or Mixed mode, this can be set at the CLI of your appliance.

Login to the CLI is done using the `vectra` user account. The default password is `changethispassword` for a newly deployed Brain or mixed mode appliance. For more details see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli).

* Proxy commands:
  * `show proxy`
  * `set proxy config [IP or Hostname] [port] [USERNAME] [PASSWORD]`
  * `set proxy enable [on|off]`
  * Any of these with `-h` option will show command help with syntax.

Examples:

```
vscli > set proxy config 1.1.1.1 80 testuser testpass
Saving proxy config...
Proxy config updated
 
vscli > show proxy
Enabled: True
Host: 1.1.1.1
Port: 80
Authentication:
Authentication enabled: True
User: testuser
Password: **********
Method: basic
 
vscli > set proxy enable on
Updating proxy config...
Proxy enabled
```

### Pairing the Sensor to the Brain

After initial configuration, it is suggested to pair your Sensor with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.

### Traffic Capture Guidance

{% hint style="info" %}
This section applies to Mixed or Sensor mode configurations only.
{% endhint %}

{% hint style="info" %}
If capture ports are connected before pairing is completed, the Sensor will not buffer any traffic.
{% endhint %}

Simply point the traffic to be captured to your Sensor capture interfaces (ports). The Sensor will begin creating a metadata stream that will be analyzed by your Brain appliance. Sensors also have a rolling capture buffer that the Brain will request PCAPs from. The PCAPs will be attached as evidence with network detections as they are created.

Additionally, [Vectra packet capture](/deployment/traffic-engineering-and-validation/using-vectra-packet-capture-pcap) allows users to configure PCAPs to be downloaded from the Brain for analysis with 3rd party tools such as Wireshark.

**Guidance:**

* See [physical connections](#physical-connections) for the interfaces supported for capture use.
* Out of band deployment is the only supported method of traffic capture.
  * There is no inline mode for currently supported Vectra Sensor appliances.
* Traffic is typically forwarded to the Sensor via SPAN/COPY/MIRROR, traditional network TAPs, or 3rd party packet brokers.
* Capture ports do not get assigned IP addresses.
* The `show traffic stats` command, available at the Sensor’s CLI, may be useful to see if your traffic capture is successful before you can see the traffic graphs in your Brain’s GUI.
  * See [Traffic Graph showing no traffic (0 Mbps)](https://support.vectra.ai/vectra/article/KB-VS-1177) for more details.
* See [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture) for architecture guidance.
* See [Vectra Platform Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations) for what to capture.
* See [Asymmetry concerns in Vectra sensor feeds](/deployment/traffic-engineering-and-validation/asymmetry-concerns) for guidance around asymmetric flows.
* See [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv) for details on validating your traffic quality.

If required, Sensors can be configued to not allow PCAP creation when there are regulatory or privacy concerns. Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors* in your Vectra UI and edit the desired Sensor. Ensure the checkbox shown below is checked for Sensors you do not wish to perform any PCAP functions and then save your Sensor configuration:

<figure><img src="/files/bEcXhXME25EjIexgeAos" alt="" width="375"><figcaption></figcaption></figure>

### Logging in to the GUI (N/A in Sensor mode)

{% hint style="info" %}
For RUX deployments, you should not log in to the local GUI before connecting with the Vectra cloud. All UI based configuration for RUX deployments should be done in the RUX UI that is served from Vectra's cloud. For more details, please see the [Respond UX deployment guide](/deployment/getting-started/respond-ux-deployment-guide).
{% endhint %}

For QUX deployments, once an IP has been configured for the MGT1 interface of your Brain, you can access it using a modern browser such as Edge, Chrome, or Safari at <https://configured\\_IP> or the hostname if you have configured a hostname in your DNS for the Brain. The GUI can also be accessed via MGT2 at [https://169.254.0.10](https://169.254.0.10/) via direct connection. The default username is `admin` and the default password is `changethispassword`**.**

Please note that by default, Vectra uses a self-signed certificate to secure the user interface. As a result, the certificate causes SSL warning in most web browsers. Instructions for how to replace this with a customer-provided signed certificate can be found in [SSL certificate installation](/configuration/qux-specific/ssl-certificate-installation).

**For both the Respond UX and the Quadrant UX:**

After logging in to the GUI (for the Respond UX you will login to your Vectra tenant identified in your welcome letter), it is recommended to immediately change the `admin` password.

* Navigate to **My Profile** on the left-hand side of the screen
* Click on **Change Password** in the username/password area, fill in and save the form
* Password requirements - must be at least 8 characters long and contain at least
  * 1 digit (0-9), 1 upper case letter (A-Z), 1 lower case letter (a-z)
  * One symbol (\~!@#$%^&\*\_-+=\`| \ ( ){ }\[ ]:;”’<>,.?/)
* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# X29 (EOS)

The X29 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

{% hint style="info" %}
The X29 appliance has reached EOS (End-of-Sale). Please see the [appliance EOS / EOL policy](/reference/appliance-eos-eol-policy) for additional details.
{% endhint %}

This document is intended to help customers or partners with the initial configuration of a physical Vectra X-Series appliance.

X-Series appliances can be used in Vectra deployments that use either the Respond UX or the Quadrant UX. The Respond UX is served from Vectra’s cloud and the Quadrant UX is served locally from the Brain appliance. For more detail on Respond UX vs Quadrant UX please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux).

X-Series appliances can be deployed in 3 modes (Brain, Sensor, or Mixed). Modes are discussed further in your deployment guide (see links below) and in [Physical appliance modes](/deployment/ndr-physical-appliances/physical-appliance-modes-and-switching-between-them).

The initial setup of the networking connectivity for an X-Series appliance will be nearly identical for all 3 modes. The only difference will be that for an X-Series appliance in Sensor mode, DNS can only be configured at the command line. For Brain or Mixed mode deployment, DNS can be configured at the command line or in the GUI.

One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your X-Series appliance following this guide, you can move on to [pairing appliances](/deployment/appliance-operations/pairing-appliances) or other recommended [next steps](#next-steps).

Guides for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## Package Contents

* 1 X29 system
* 1 Rail kit
* 2 Power supply cords (matching requested type)
* 1 Vectra bezel
* SFPs (matching details of your order)
  * See [SFPs and QSFPs supported in Vectra appliances](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) for options and additional detail.

## Physical Connections

<figure><img src="/files/jEUh2zxg0Gezfm9LzbuV" alt=""><figcaption><p>X29 Back Panel (click to enlarge)</p></figcaption></figure>

![X29 Front Panel (click to enlarge)](/files/b8zyBKCtLhuDsqd6MirG)

### Physical Connections Added Guidance

* Due to supply chain fluctuations, Vectra has begun to ship X29 models with a 4 port ethernet card in place of the 2 port ethernet card shown in the port diagram above.
  * Both 2 port and 4 port capture cards perform identically from a performance perspective.
  * For customers with 4 port capture cards, the left two ports are unused, and the right two ports are eth3, and eth2 (from left to right).
* Disks removed from any X29 model can't be read outside of the system they were removed from because of the use of encryption that is specific to each system.
* If an X29 is used in Brain mode, the capture ports are not supported. Only the MGT interfaces will function
* If you have questions about rail installation, watch this video:
  * <https://www.youtube.com/watch?v=JfOTnRMeE5w>

### Minimum Connections

* Power
  * The X29 has two redundant power supplies. It is recommended to connect both.
* MGT1 - RJ-45 ethernet (1 Gbps copper) or SFP+ (10 Gbps)
  * Either of these ports will need to be configured with an IP address in your network.
  * The X29 can be configured by the customer to allow the port labeled as eth0 (10 Gbps SFP+) on the back of the appliance to function as the MGT1 port.
    * See [10 Gbps MGT1 Option](#gbps-mgt1-option) below for details on how to enable this.
* Capture - RJ-45 ethernet (1 Gbps copper), or SFP+ if deploying in Mixed or Sensor mode.
  * At least one of the capture interfaces (ports) must be connected when you are ready to begin capturing traffic for analysis.

### 10 Gbps MGT1 Option

The X29 can be configured by the customer to allow the port labeled as eth0 (10 Gbps SFP+) on the back of the appliance to function as the MGT1 port. This will not give any performance benefit and is intended for use by customers who do not have any 1 Gbps copper interfaces available for use as the MGT1 interface in the location in which they will deploy the X29 appliance.

<details>

<summary>Please expand for details if you wish to enable this option:</summary>

{% hint style="info" %}
**Please note the following:**

* Making this change will reduce the number of capture ports on the X29 appliance to 3 (1x10 Gbps SFP+ and 2x1 Gbps copper interfaces) because one of the 10 Gbps SFP+ ports is now used for MGT1.
* It is recommended to use KVM, serial console, MGT2, or iDRAC/IPMI to connect to the appliance command line to make the change because unlike a SSH session, these will be unaffected by the change. See [Accessing the CLI](#accessing-the-cli) for details.
* For example, if you were connected to MGT1 in a staging area to make the change before moving into your data center where the 10 Gbps SFP+ was required, when the change is made your session would break and you would need to login again to configure a static address for the new MGT1 port.
* After making the change, physical port labels on the back of the appliance would no longer match how Vectra software displays the ports.
  * The port physically labeled as MGT1 changes to being unused by the Vectra software.
  * The port physically labeled as eth0 becomes MGT1.
  * What is physically labeled eth1 becomes eth0, eth2 becomes eth1, and eth3 becomes eth2.
* The `show interface` command at the CLI can be used to show the actual negotiated speed and state of MGT interfaces.
  {% endhint %}

CLI commands to show configured MGT1 interface speed setting and change speed setting:

```
show management
set management <default|sfp>

Examples:
vscli > show management
Management interface is set to default. See `show interface` for more information.

vscli > set management sfp
vscli > show management
Management interface is set to sfp. See `show interface` for more information.
```

{% hint style="info" %}

* Please note that after the change is made it will take up to a minute for the `show traffic stats` cli command to accurately reflect the reduced number of capture ports and the new eth numbering assignments.
* It will take the UI around 5 minutes to accurately reflect the reduced number of capture ports and the new eth numbering assignments.
  {% endhint %}

</details>

## Performance

| **Brain Mode** | **Sensor Mode** | **Mixed Mode** | **Sensor (Match) Mode** | **Mixed (Match) Mode** |
| :------------: | :-------------: | :------------: | :---------------------: | :--------------------: |
|     20 Gbps    |     15 Gbps     |     8 Gbps     |          9 Gbps         |        4.6 Gbps        |

**Definitions:**

* For an appliance in Sensor mode:
  * Bandwidth number shown refers to the amount of network traffic observed that the appliance can produce metadata for (capture bandwidth).
* For an appliance in Brain or Mixed mode:
  * Bandwidth number shown refers to the aggregate amount of traffic observed by paired Sensors and the Mixed mode Brain that the appliance can process metadata for (aggregate bandwidth).
* **Brain Mode** - Appliance set to Brain mode, all traffic captured by paired Sensors.
* **Sensor Mode** - Appliance set to Sensor mode, no Brain functions performed by this X3.
* **Mixed Mode** - Appliance set to Mixed mode and performs both Brain and Sensor functions.
* **Sensor (Match) Mode** - Appliance set to Sensor mode with [Match](/deployment/match) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.
* **Mixed (Match) Mode** - Appliance set to Mixed mode with [Match](/deployment/match) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.

{% hint style="info" %}
**Please Note:**

While considering performance for the appliance it is important to understand that the traffic mix at customer sites varies widely. Some customers have traffic mixes that skew towards larger flows (think file transfers), and some will skew towards smaller flows (think DNS).

* Performance may be higher when the traffic mix skews towards larger flows.
* Performance will be lower when the traffic mix skews towards smaller flows as this produces more metadata for analysis.
* The stated performance is for average traffic mixes and should not be considered absolute.
  {% endhint %}

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1, S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the "set interface" command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

Instructions for configuring the DNS settings using the management GUI can be found in [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) or [Vectra Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment). This is only supported for Brain or Mixed mode configurations.

### Brain and Sensor Communications Requirements

A Sensor can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that the Sensor will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for the Sensor will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

It is recommended to check connectivity to the Brain from Sensors at the Sensor CLI. For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

To validate that you can connect to Vectra services, it is also recommended to use the `debug connectivity` command at your Brain’s CLI to check connectivity to the following endpoints:

* update2.vectranetworks.com
* api.vectranetworks.com
* Vectra Cloud Gateways that correspond to the region your tenant is deployed in when using the Respond UX (see the [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) for more details)
* rp.vectranetworks.com
* rs.vectranetworks.com

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity api.vectranetworks.com 443 --ssl
Connectivity: Success
Proxy: False
SSL: True
```

## Next Steps

### Proxy Support

If a proxy is required in your environment to reach Vectra’s Updater service (update2.vectranetworks.com or 54.200.156.238), a Sensor mode appliance will not be able to retrieve the Brain location from the Vectra Cloud to use online pairing. You will need to manually set the Brain IP or hostname when attempting pairing with your Brain because setting a proxy is not supported for Sensors. Instructions for pairing, including setting the Brain IP or hostname to pair with, is in [pairing appliances](/deployment/appliance-operations/pairing-appliances).

{% hint style="info" %}
This remainder of this section refers to appliances deployed in Brain mode or in Mixed mode.

Sensor mode appliances do not support communication through proxies to the Brain.
{% endhint %}

If a proxy is required in your environment to communicate with the Vectra cloud when deployed in Brain or Mixed mode, this can be set at the CLI of your appliance.

Login to the CLI is done using the `vectra` user account. The default password is `changethispassword` for a newly deployed Brain or mixed mode appliance. For more details see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli).

* Proxy commands:
  * `show proxy`
  * `set proxy config [IP or Hostname] [port] [USERNAME] [PASSWORD]`
  * `set proxy enable [on|off]`
  * Any of these with `-h` option will show command help with syntax.

Examples:

```
vscli > set proxy config 1.1.1.1 80 testuser testpass
Saving proxy config...
Proxy config updated
 
vscli > show proxy
Enabled: True
Host: 1.1.1.1
Port: 80
Authentication:
Authentication enabled: True
User: testuser
Password: **********
Method: basic
 
vscli > set proxy enable on
Updating proxy config...
Proxy enabled
```

### Pairing the Sensor to the Brain

After initial configuration, it is suggested to pair your Sensor with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.

### Traffic Capture Guidance

{% hint style="info" %}
This section applies to Mixed or Sensor mode configurations only.
{% endhint %}

{% hint style="info" %}
If capture ports are connected before pairing is completed, the Sensor will not buffer any traffic.
{% endhint %}

Simply point the traffic to be captured to your Sensor capture interfaces (ports). The Sensor will begin creating a metadata stream that will be analyzed by your Brain appliance. Sensors also have a rolling capture buffer that the Brain will request PCAPs from. The PCAPs will be attached as evidence with network detections as they are created.

Additionally, [Vectra packet capture](/deployment/traffic-engineering-and-validation/using-vectra-packet-capture-pcap) allows users to configure PCAPs to be downloaded from the Brain for analysis with 3rd party tools such as Wireshark.

**Guidance:**

* See [physical connections](#physical-connections) for the interfaces supported for capture use.
* Out of band deployment is the only supported method of traffic capture.
  * There is no inline mode for currently supported Vectra Sensor appliances.
* Traffic is typically forwarded to the Sensor via SPAN/COPY/MIRROR, traditional network TAPs, or 3rd party packet brokers.
* Capture ports do not get assigned IP addresses.
* The `show traffic stats` command, available at the Sensor’s CLI, may be useful to see if your traffic capture is successful before you can see the traffic graphs in your Brain’s GUI.
  * See [Traffic Graph showing no traffic (0 Mbps)](https://support.vectra.ai/vectra/article/KB-VS-1177) for more details.
* See [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture) for architecture guidance.
* See [Vectra Platform Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations) for what to capture.
* See [Asymmetry concerns in Vectra sensor feeds](/deployment/traffic-engineering-and-validation/asymmetry-concerns) for guidance around asymmetric flows.
* See [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv) for details on validating your traffic quality.

If required, Sensors can be configued to not allow PCAP creation when there are regulatory or privacy concerns. Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors* in your Vectra UI and edit the desired Sensor. Ensure the checkbox shown below is checked for Sensors you do not wish to perform any PCAP functions and then save your Sensor configuration:

<figure><img src="/files/bEcXhXME25EjIexgeAos" alt="" width="375"><figcaption></figcaption></figure>

### Logging in to the GUI (N/A in Sensor mode)

{% hint style="info" %}
For RUX deployments, you should not log in to the local GUI before connecting with the Vectra cloud. All UI based configuration for RUX deployments should be done in the RUX UI that is served from Vectra's cloud. For more details, please see the [Respond UX deployment guide](/deployment/getting-started/respond-ux-deployment-guide).
{% endhint %}

For QUX deployments, once an IP has been configured for the MGT1 interface of your Brain, you can access it using a modern browser such as Edge, Chrome, or Safari at <https://configured\\_IP> or the hostname if you have configured a hostname in your DNS for the Brain. The GUI can also be accessed via MGT2 at [https://169.254.0.10](https://169.254.0.10/) via direct connection. The default username is `admin` and the default password is `changethispassword`**.**

Please note that by default, Vectra uses a self-signed certificate to secure the user interface. As a result, the certificate causes SSL warning in most web browsers. Instructions for how to replace this with a customer-provided signed certificate can be found in [SSL certificate installation](/configuration/qux-specific/ssl-certificate-installation).

**For both the Respond UX and the Quadrant UX:**

After logging in to the GUI (for the Respond UX you will login to your Vectra tenant identified in your welcome letter), it is recommended to immediately change the `admin` password.

* Navigate to **My Profile** on the left-hand side of the screen
* Click on **Change Password** in the username/password area, fill in and save the form
* Password requirements - must be at least 8 characters long and contain at least
  * 1 digit (0-9), 1 upper case letter (A-Z), 1 lower case letter (a-z)
  * One symbol (\~!@#$%^&\*\_-+=\`| \ ( ){ }\[ ]:;”’<>,.?/)
* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# X80 (EOL)

The X80 quick start guide provides guidance for initial connection to your network.

{% hint style="info" %}
**Please Note:**

The X80 has reached EOL as of January 7, 2025 per Vectra's [Appliance EOS / EOL policy](/reference/appliance-eos-eol-policy).
{% endhint %}

### Attachments

{% file src="/files/RlCnim2BYLZSr4qRmcuH" %}

### Contains

* Package Contents
* Physical Connections (and disk numbering)
  * Connections Required for Initial Configuration of MGT Port
  * Additional Cabling/Racking Notes of Interest
* X80 Initial Configuration
  * DHCP Quick Start
  * Static Addressing Quick Start
    * Configuration Checklist for Static Addressing
    * Accessing the Command Line Interface (CLI) of the X80 Appliance
    * Setting at Static IP Address
* Worldwide Support Contact Information


# B-Series

Quick start guides and lifecycle notes for B-Series appliances.

{% content-ref url="/pages/DCiMG34hNeng2MVqHOnJ" %}
[B127](/deployment/ndr-physical-appliances/b-series/b127)
{% endcontent-ref %}

{% content-ref url="/pages/b2oHfYCnJc6f7gNRLILf" %}
[B101 (EOS)](/deployment/ndr-physical-appliances/b-series/b101)
{% endcontent-ref %}


# B127

The B127 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

This document is intended to help customers or partners with the initial configuration of a physical Vectra B-Series appliance.

B-Series appliances can be used in Vectra deployments that use either the Respond UX or the Quadrant UX. The Respond UX is served from Vectra’s cloud and the Quadrant UX is served locally from the Brain appliance. For more detail on Respond UX vs Quadrant UX please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux).

B-Series appliances can only be deployed in Brain mode. Modes are discussed further in your deployment guide (see links below) and in [Physical appliance modes](/deployment/ndr-physical-appliances/physical-appliance-modes-and-switching-between-them).

One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your B-Series appliance following this guide, you can move on to [pairing appliances](/deployment/appliance-operations/pairing-appliances) or other recommended [next steps](#next-steps).

Guides for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## Package Contents

* 1 B127 system with rail kit
* 2 power supply cords (matching requested type)
* Vectra bezel
* SFPs and QSFPs (matching details of your order)
  * See [SFPs and QSFPs supported in Vectra appliances](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) for options and additional detail.

## Physical Connections

<figure><img src="/files/0Yb1MAvVgtPYfJ0jxi73" alt=""><figcaption><p>B127 Back Panel (click to enlarge)</p></figcaption></figure>

![B127 Front Panel (click to enlarge)](/files/ab65fbafc91380e66f3a36e6bb97988b4c4e3345)

### Physical Connections Added Guidance

* There is an additional USB and VGA port on the front right-hand side that can be used for console access.
  * You can use these or the rear USB ports for console access.
  * The iDRAC Direct micro port under this front USB port is not supported. Please use the ethernet iDRAC port on the rear of the chassis for iDRAC/IPMI use.
* The B127 has two 3.2 TB SSD drives.
  * Should any ever need replacing, contact Vectra support and refer to the disk numbers on the chassis.
* If you have questions on rail installation, watch this [video](https://www.youtube.com/watch?v=JfOTnRMeE5w).

### Minium Connections

Any SFPs that were included in your order will be in the top cardboard tray above the appliance itself.

* Power
  * The B127 has dual auto sensing power supplies that support 100-240 VAC supply at 50 or 60 Hz.
  * It is recommended to connect both power supplies for redundancy.
* MGT1 – 10/25 GbE SFP28
  * This is the port that will need to be configured with an IP address in your network.
  * This port serves the CLI (RUX and QUX) and GUI (QUX only), and paired Sensors connect to it.
* MGT2 – 10/25 GbE SFP28
  * MGT2 can be used in place of MGT1 for initial configuration. MGT1 should be used for production.

## B127 Performance

| **Brain Mode** | **Paired Sensors** | **Tracked Hosts** |
| :------------: | :----------------: | :---------------: |
|     75 Gbps    |         500        |      300,000      |

**Guidance and Definitions:**

{% hint style="info" %}
B-Series appliances do not support Mixed or Sensor mode usage

* They can only operate in Brain mode and are intended to provide the highest possible performance for high throughput environments.

* To capture traffic, Sensors must be deployed and paired to any B-Series appliance.
  {% endhint %}

* **Brain Mode**
  * Bandwidth number shown refers to the aggregate amount of traffic observed by paired Sensors that the B-Series appliance can process metadata for (aggregate bandwidth).

* **Paired Sensors**
  * Up to 500 Sensors can be paired to the B-Series appliance.

* **Tracked Hosts**
  * Refers to how many hosts the B-Series appliance can track simultaneously (open host sessions). Brains can typically retain and display data for much larger numbers of hosts, this only refers to how many hosts the system can process metadata for simultaneously. Host sessions expire after 2 hours of inactivity.

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1, S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the "set interface" command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

Instructions for configuring the DNS settings using the management GUI can be found in [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) or [Vectra Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment). This is only supported for Brain or Mixed mode configurations.

### Brain and Sensor Communications Requirements

A Sensor can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that any Sensors will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for Sensors will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

It is recommended to check connectivity to the Brain from Sensors at the Sensor CLI. For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

To validate that you can connect to Vectra services, it is also recommended to use the `debug connectivity` command at your Brain’s CLI to check connectivity to the following endpoints:

* update2.vectranetworks.com
* api.vectranetworks.com
* Vectra Cloud Gateways that correspond to the region your tenant is deployed in when using the Respond UX (see the [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) for more details)
* rp.vectranetworks.com
* rs.vectranetworks.com

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity api.vectranetworks.com 443 --ssl
Connectivity: Success
Proxy: False
SSL: True
```

## Next Steps

### Proxy Support

If a proxy is required in your environment for your Brain appliance to communicate with the Vectra cloud, this can be set at the CLI (during initial deployment) or in your Vectra UI (after initial deployment).

{% hint style="info" %}
For RUX deployments, you should not log in to the local GUI before connecting with the Vectra cloud. All UI based configuration for RUX deployments should be done in the RUX UI that is served from Vectra's cloud. For more details, please see the [Respond UX deployment guide](/deployment/getting-started/respond-ux-deployment-guide).

See [logging in to the UI ](#logging-in-to-the-ui-n-a-in-sensor-mode)for more details.
{% endhint %}

Login to the CLI is done using the `vectra` user account. The default password is `changethispassword` for a newly deployed Brain or mixed mode appliance. For more details see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli).

* Proxy commands:
  * `show proxy`
  * `set proxy config [IP or Hostname] [port] [USERNAME] [PASSWORD]`
  * `set proxy enable [on|off]`
  * Any of these with `-h` option will show command help with syntax.

Examples:

```
vscli > set proxy config 1.1.1.1 80 testuser testpass
Saving proxy config...
Proxy config updated
 
vscli > show proxy
Enabled: True
Host: 1.1.1.1
Port: 80
Authentication:
Authentication enabled: True
User: testuser
Password: **********
Method: basic
 
vscli > set proxy enable on
Updating proxy config...
Proxy enabled
```

### Logging in to the UI

{% hint style="info" %}
For RUX deployments, you should not log in to the local UI before connecting with the Vectra cloud. All UI based configuration for RUX deployments should be done in the RUX UI that is served from Vectra's cloud. For more details, please see the [Respond UX deployment guide](/deployment/getting-started/respond-ux-deployment-guide).
{% endhint %}

For QUX deployments, once an IP has been configured for the MGT1 interface of your Brain, you can access it using a modern browser such as Edge, Chrome, or Safari at <https://configured\\_IP> or the hostname if you have configured a hostname in your DNS for the Brain. The GUI can also be accessed via MGT2 at [https://169.254.0.10](https://169.254.0.10/) via direct connection. The default username is `admin` and the default password is `changethispassword`**.**

Please note that by default, Vectra uses a self-signed certificate to secure the user interface. As a result, the certificate causes SSL warning in most web browsers. Instructions for how to replace this with a customer-provided signed certificate can be found in [SSL certificate installation](/configuration/qux-specific/ssl-certificate-installation).

**For both the Respond UX and the Quadrant UX:**

After logging in to the UI (for the Respond UX you will login to your Vectra tenant identified in your welcome letter), it is recommended to immediately change the `admin` password.

* Navigate to **My Profile** on the left-hand side of the screen
* Click on **Change Password** in the username/password area, fill in and save the form
* Password requirements - must be at least 8 characters long and contain at least
  * 1 digit (0-9), 1 upper case letter (A-Z), 1 lower case letter (a-z)
  * One symbol (\~!@#$%^&\*\_-+=\`| \ ( ){ }\[ ]:;”’<>,.?/)

### Pairing Sensors to the Brain

After initial configuration, it is suggested to pair any Sensors your deployment will need with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.
* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# B101 (EOS)

The B101 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

{% hint style="info" %}
The B101 appliance has reached EOS (End-of-Sale). Please see the [appliance EOS / EOL policy](/reference/appliance-eos-eol-policy) for additional details.
{% endhint %}

This document is intended to help customers or partners with the initial configuration of a physical Vectra B-Series appliance.

B-Series appliances can be used in Vectra deployments that use either the Respond UX or the Quadrant UX. The Respond UX is served from Vectra’s cloud and the Quadrant UX is served locally from the Brain appliance. For more detail on Respond UX vs Quadrant UX please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux).

B-Series appliances can only be deployed in Brain mode. Modes are discussed further in your deployment guide (see links below) and in [Physical appliance modes](/deployment/ndr-physical-appliances/physical-appliance-modes-and-switching-between-them).

One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your B-Series appliance following this guide, you can move on to [pairing appliances](/deployment/appliance-operations/pairing-appliances) or other recommended [next steps](#next-steps).

Guides for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## Package Contents

* 1 B101 system with rail kit
* 2 power supply cords (matching requested type)
* 1 Vectra bezel
* SFPs (matching details of your order)
  * See [SFPs and QSFPs supported in Vectra appliances](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) for options and additional detail.

## Physical Connections

![B101 Back Panel (click to enlarge)](/files/5eeb8828ca6f4272f96cf013ca0b403ecae42428)

![B101 Front Panel (click to enlarge)](/files/cef005d06997baf879a7f418d3829f0387b3d709)

### Physical Connections Added Guidance

* The B127 has two drives.
  * Should any ever need replacing, contact Vectra support and refer to the disk numbers on the chassis.
* If you have questions on rail installation, watch this [video](https://www.youtube.com/watch?v=JfOTnRMeE5w).

### Minimum Connections

Any SFPs that were included in your order will be in the top cardboard tray above the appliance itself.

* Power
  * The B101 has dual auto sensing power supplies that support 100-240 VAC supply at 50 or 60 Hz.
  * It is recommended to connect both power supplies for redundancy.
* MGT1 – 10 GbE SFP+
  * This is the port that will need to be configured with an IP address in your network.
  * This port serves the CLI and GUI (Quadrant UX only), and is also what your Sensors connect to.
* MGT2 – 10/100/1000 Copper Ethernet
  * MGT2 can be used in place of MGT1 for initial configuration. MGT1 should be used for production.

### B101 Performance <a href="#b127-performance" id="b127-performance"></a>

| **Brain Mode** | **Paired Sensors** | **Tracked Hosts** |
| -------------- | ------------------ | ----------------- |
| 75 Gbps        | 500                | 300,000           |

**Guidance and Definitions:**

{% hint style="info" %}
B-Series appliances do not support Mixed or Sensor mode usage

* They can only operate in Brain mode and are intended to provide the highest possible performance for high throughput environments.

* To capture traffic, Sensors must be deployed and paired to any B-Series appliance.
  {% endhint %}

* **Brain Mode**
  * Bandwidth number shown refers to the aggregate amount of traffic observed by paired Sensors that the B-Series appliance can process metadata for (aggregate bandwidth).

* **Paired Sensors**
  * Up to 500 Sensors can be paired to the B-Series appliance.

* **Tracked Hosts**
  * Refers to how many hosts the B-Series appliance can track simultaneously (open host sessions). Brains can typically retain and display data for much larger numbers of hosts, this only refers to how many hosts the system can process metadata for simultaneously. Host sessions expire after 2 hours of inactivity.

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1, S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the "set interface" command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

Instructions for configuring the DNS settings using the management GUI can be found in [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) or [Vectra Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment). This is only supported for Brain or Mixed mode configurations.

### Brain and Sensor Communications Requirements

A Sensor can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that any Sensors will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for Sensors will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

It is recommended to check connectivity to the Brain from Sensors at the Sensor CLI. For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

To validate that you can connect to Vectra services, it is also recommended to use the `debug connectivity` command at your Brain’s CLI to check connectivity to the following endpoints:

* update2.vectranetworks.com
* api.vectranetworks.com
* Vectra Cloud Gateways that correspond to the region your tenant is deployed in when using the Respond UX (see the [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) for more details)
* rp.vectranetworks.com
* rs.vectranetworks.com

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity api.vectranetworks.com 443 --ssl
Connectivity: Success
Proxy: False
SSL: True
```

## Next Steps

### Proxy Support

If a proxy is required in your environment for your Brain appliance to communicate with the Vectra cloud, this can be set at the CLI (during initial deployment) or in your Vectra UI (after initial deployment).

{% hint style="info" %}
For RUX deployments, you should not log in to the local GUI before connecting with the Vectra cloud. All UI based configuration for RUX deployments should be done in the RUX UI that is served from Vectra's cloud. For more details, please see the [Respond UX deployment guide](/deployment/getting-started/respond-ux-deployment-guide).

See [logging in to the UI ](#logging-in-to-the-ui-n-a-in-sensor-mode)for more details.
{% endhint %}

Login to the CLI is done using the `vectra` user account. The default password is `changethispassword` for a newly deployed Brain or mixed mode appliance. For more details see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli).

* Proxy commands:
  * `show proxy`
  * `set proxy config [IP or Hostname] [port] [USERNAME] [PASSWORD]`
  * `set proxy enable [on|off]`
  * Any of these with `-h` option will show command help with syntax.

Examples:

```
vscli > set proxy config 1.1.1.1 80 testuser testpass
Saving proxy config...
Proxy config updated
 
vscli > show proxy
Enabled: True
Host: 1.1.1.1
Port: 80
Authentication:
Authentication enabled: True
User: testuser
Password: **********
Method: basic
 
vscli > set proxy enable on
Updating proxy config...
Proxy enabled
```

### Logging in to the UI

{% hint style="info" %}
For RUX deployments, you should not log in to the local UI before connecting with the Vectra cloud. All UI based configuration for RUX deployments should be done in the RUX UI that is served from Vectra's cloud. For more details, please see the [Respond UX deployment guide](/deployment/getting-started/respond-ux-deployment-guide).
{% endhint %}

For QUX deployments, once an IP has been configured for the MGT1 interface of your Brain, you can access it using a modern browser such as Edge, Chrome, or Safari at <https://configured\\_IP> or the hostname if you have configured a hostname in your DNS for the Brain. The GUI can also be accessed via MGT2 at [https://169.254.0.10](https://169.254.0.10/) via direct connection. The default username is `admin` and the default password is `changethispassword`**.**

Please note that by default, Vectra uses a self-signed certificate to secure the user interface. As a result, the certificate causes SSL warning in most web browsers. Instructions for how to replace this with a customer-provided signed certificate can be found in [SSL certificate installation](/configuration/qux-specific/ssl-certificate-installation).

**For both the Respond UX and the Quadrant UX:**

After logging in to the UI (for the Respond UX you will login to your Vectra tenant identified in your welcome letter), it is recommended to immediately change the `admin` password.

* Navigate to **My Profile** on the left-hand side of the screen
* Click on **Change Password** in the username/password area, fill in and save the form
* Password requirements - must be at least 8 characters long and contain at least
  * 1 digit (0-9), 1 upper case letter (A-Z), 1 lower case letter (a-z)
  * One symbol (\~!@#$%^&\*\_-+=\`| \ ( ){ }\[ ]:;”’<>,.?/)

### Pairing Sensors to the Brain

After initial configuration, it is suggested to pair any Sensors your deployment will need with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.
* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# S-Series

Quick start guides and lifecycle notes for S-Series appliances.

{% content-ref url="/pages/DoCle0yyHlJ4lo661ltX" %}
[S1](/deployment/ndr-physical-appliances/s-series/s1)
{% endcontent-ref %}

{% content-ref url="/pages/wSKJGBOA0jvlqGyCQeEi" %}
[S1v2](/deployment/ndr-physical-appliances/s-series/s1v2)
{% endcontent-ref %}

{% content-ref url="/pages/jZIZqRdQxLLQQtmftgkJ" %}
[S11](/deployment/ndr-physical-appliances/s-series/s11)
{% endcontent-ref %}

{% content-ref url="/pages/B3pd8z3XtlynA0Vps46n" %}
[S17](/deployment/ndr-physical-appliances/s-series/s17)
{% endcontent-ref %}

{% content-ref url="/pages/IC7LwRHcT6PjmTMTRRiG" %}
[S101](/deployment/ndr-physical-appliances/s-series/s101)
{% endcontent-ref %}

{% content-ref url="/pages/e8dGlJ6litMgFBckawaA" %}
[S127](/deployment/ndr-physical-appliances/s-series/s127)
{% endcontent-ref %}

{% content-ref url="/pages/h6CBGvjWGuOsig3JEI02" %}
[S2 (EOL)](/deployment/ndr-physical-appliances/s-series/s2)
{% endcontent-ref %}


# S1

The S1 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

This document is intended to help customers or partners with the initial configuration of a physical Vectra Sensor appliance. This is limited to basic network connectivity. This appliance can only be deployed in Sensor mode. Modes are discussed further in the deployment guide for your chosen UX. One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your Sensor following this guide, you can move on to paring your Sensor with your Brain appliance. Pairing for all Vectra appliances is covered in [pairing appliances](/deployment/appliance-operations/pairing-appliances).

Guide for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## Package Contents

* 1 S1 system
* 1 Wall mount bracket
* 1 Micro USB to USB-A cable for serial console access
* 1 External power supply unit
* SFPs (matching details of your order)
  * See [SFPs and QSFPs supported in Vectra appliances](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) for options and additional detail.

## Physical Connections

<figure><img src="/files/Ar9pnTNm5f75LZnom0Fm" alt=""><figcaption><p>S1 Back Panel (click to enlarge), Mangement Default, Capture Default</p></figcaption></figure>

{% hint style="warning" %}
Please note that there are 2 fans in the system that pull air in the bottom of the unit and push it out the back and sides. Take care to not block the airflow to ensure proper cooling of the system.
{% endhint %}

{% hint style="info" %}
Please see [Port Option Settings](#port-option-settings) for details on additional port configuration options to allow the SFP+ ports to be used for management and/or capture.
{% endhint %}

### Status Light

On the front panel of the S1 on the right side there is a status light. Please see the following table for details on the various states of the status light.

<table><thead><tr><th width="247.89453125">Color</th><th width="496.12109375">Status</th></tr></thead><tbody><tr><td>Red</td><td>Power on</td></tr><tr><td>White</td><td>System booting</td></tr><tr><td>Green</td><td>Operating system loaded</td></tr><tr><td>Blue</td><td>Reset button pressed for more than 5 seconds<br>(Reset button is on back panel to the left of the SFP+ ports)</td></tr></tbody></table>

**Reset Button Behavior:**

* When system is powered off, pressing the reset button will power on the system.
* When system is powered on, pressing the reset button for more than 5 seconds will cause the system to reboot.

### Physical Connections Added Guidance

* For details on mounting options (desktop placement, wall mount, and rack mount option), please see [Virtual Edge Platform (VEP) 1405 Series Technology Guide (Chassis mounting)](https://www.dell.com/support/manuals/en-us/dell-emc-networking-vep1445-vep1485/vep1405-technology-guide-rev-a03/rack-mounted-installation?guid=guid-ad6f30ab-19c1-480b-adee-efe3e23bda2c\&lang=en-us).
* The 10 GbE SFP+ ports can be configured to support MGT1 and/or capture capability.
  * Please see [Port Option Settings](#port-option-settings) below for details on how to configure this and what the interface assignments would become after configuration. The diagram above only represents the default port options that the S1 appliance comes setup for.
* There are additional USB ports on sides that are unused and can be ignored.
* The S1 has a single 960 GB SSD drive.
  * Should it ever require replacement, please work with Vectra support.
* If you will use USB serial console for initial configuration, please see the following external articles:
  * [How to access console port of Dell EMC Networking Virtual Edge Platform 1405 Series](https://www.dell.com/support/kbdoc/en-us/000134440/how-to-access-console-port-of-dell-emc-networking-virtual-edge-platform-1405-series)
  * [CP210x USB to UART Bridge VCP Drivers](https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers) (if required for your application)

### Minimum Connections Required

Any SFPs that were included in your order will be in the top cardboard tray above the appliance itself.

* Power
  * The S1 has an external 65W power supply. Auto-sensing, 100-240 VAC, at 50 or 60 Hz.
* MGT1 - RJ-45 ethernet (1 Gbps copper)
  * This is the port that will need to be configured with an IP address in your network for communication with your Vectra Brain.
* Capture - RJ-45 ethernet (1 Gbps copper), or SFP+ depending on your port option settings.
  * At least one of the capture interfaces (ports) must be connected when you are ready to begin capturing traffic for analysis.

## Performance

| **Sensor Mode** | **Sensor (Match) Mode** |
| :-------------: | :---------------------: |
|      1 Gbps     |         400 Mbps        |

{% hint style="warning" %}
**Please Note:**

Even though there are multiple capture ports on the S1 appliance and you can configure the [Port Option Settings](#port-option-settings) to allow the SFP+ ports to be used for capture, any combination of capture interfaces used still have the above limitations for the overall performance for the S1 appliance. Care should be taken to only send a supported amount of traffic to the capture ports to avoid incomplete analysis.
{% endhint %}

**Definitions:**

* **Sensor Mode** – Bandwidth number shown refers to the amount of network traffic observed that the appliance can produce metadata for (capture bandwidth).
* **Sensor (Match) Mode** – Performance as a Sensor with [Match](/deployment/match/deployment) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.

{% hint style="info" %}
**Please Note:**

While considering performance for the Sensor it is important to understand that the traffic mix at customer sites varies widely. Some customers have traffic mixes that skew towards larger flows (think file transfers), and some will skew towards smaller flows (think DNS).

* Performance may be higher when the traffic mix skews towards larger flows.
* Performance will be lower when the traffic mix skews towards smaller flows as this produces more metadata for analysis.
* The stated performance is for average traffic mixes and should not be considered absolute.
  {% endhint %}

## Port Option Settings

While the S1 appliance supports a maximum throughput of 1Gbps for traffic capture and analysis, some customers may not have 1 GbE cooper connections available for management or capture in the deployment location. The S1 supports reconfiguring the assignment of the interfaces shown in the diagram at the start of the [Physical Connections](#physical-connections) section. This will allow the configuration of the SFP+ interfaces that are unused in the default configuration to be assigned to management (MGT1) and/or capture use.

This reconfiguration is accomplished by two commands that create a total of 4 different port mappings (4 total configurations including the default):

* `set management`
  * Can be used to set the management port (MGT1) to SFP or default.
* `show management`
  * Will show the configuration of SFP or default.
* `set capture`
  * Can be used to set SFP+ port(s) to be used for capture (SFP) or the default of unused.
* `show capture`
  * Will show the configuration of SFP or default.

{% hint style="info" %}
Using any of the capture ports (SFP+ or copper) does not change the max [performance](#performance) supported by the S1 appliance. Even though the interface might support 10 Gbps, the max throughput of the appliance is lower than the line speed of the interface, and care should be taken to only send a supported amount of traffic to the capture ports to avoid incomplete analysis.
{% endhint %}

{% hint style="info" %}
When configuring any of the options to change management or capture, other ports that are supported in the default configuration will change. The diagrams below will show the assignment of each port in each supported port option configuration.
{% endhint %}

To make any of the changes, you will first need to [acces the CLI](#accessing-the-cli) so that you can execute the commands.

Please see below the syntax for using these commands:

```
vscli > set management --help
Usage: set management < ( default | sfp ) >

  Set Management Interface speed command

Options:
  -h, --help  Show this message and exit.

 
vscli > set capture --help
Usage: set capture < ( default | sfp ) >

  Set Capture Interface speed command

Options:
  -h, --help  Show this message and exit. 
```

Example Usage:

```
vscli > set management sfp
vscli > set capture sfp
vscli > show management
Management interface is set to SFP. See `show interface` for more information.
vscli > show capture
Capture interfaces are set to SFP where possible. See `show interface` for more information.
```

### Management Default, Capture Default

This is the default configuration of the appliance, and the interface assignments are shown in the diagram at the start of the [Physical Connections](#physical-connections) section.

### Management SFP, Capture Default

In this configuration, MGT1 is now the right SFP+ port. The port that was MGT1 in the default configuration is now assigned as eth4 and is unused.

<figure><img src="/files/iOnGkb7yuAOo0l3uXeZm" alt=""><figcaption><p>Management SFP, Capture Default</p></figcaption></figure>

### Management Default, Capture SFP

In this configuration, both SFP+ ports are configured for capture, and are assigned eth3 and eth2 from left to right. The copper ports that were eth2 and eth3 in the default configuration are now assigned eth4 and eth5 from top to bottom and are unused.

<figure><img src="/files/s7yOWtlJYWBLnbEp9xFc" alt=""><figcaption><p>Management Default, Capture SFP</p></figcaption></figure>

### Management SFP, Capture SFP

In this configuration, MGT1 is the right SFP+ port, the left SFP+ port is assigned to eth3 and is configured for capture. The port that was eth3 in the default configuration is now assigned to eth5 and is unused. The port that was MGT1 in the default configuration is now assigned to eth4 and is unused.

<figure><img src="/files/9qZm5cmjkyfIvw7FnNH6" alt=""><figcaption><p>Management SFP, Capture SFP</p></figcaption></figure>

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1 (not S1v2), S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the `set interface` command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

If your Sensor is already configured with an IP, it is recommended to ping the Brain IP to verify reachability before attempting pairing. Sensors must have port 22 and 443 open from the Sensor to your Brain for successful pairing and ongoing communication. Connectivity can be tested with the `debug connectivity` command.

* For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity yourbrainIP.customernetwork.com 443 –no-ssl
Connectivity: Success
Proxy: False
SSL: False
```

## Next Steps

### Brain and Sensor Communications Requirements

A Sensor (or Stream appliance) can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that the Sensor will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for the Sensor will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Pairing the Sensor to the Brain

After base configuration, it is suggested to pair your Sensor with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.

### Traffic Capture Guidance

{% hint style="info" %}
If capture ports are connected before pairing is completed, the Sensor will not buffer any traffic.
{% endhint %}

Simply point the traffic to be captured to your Sensor capture interfaces (ports). The Sensor will begin creating a metadata stream that will be analyzed by your Brain appliance. Sensors also have a rolling capture buffer that the Brain will request PCAPs from. The PCAPs will be attached as evidence with network detections as they are created.

Additionally, [Vectra packet capture](/deployment/traffic-engineering-and-validation/using-vectra-packet-capture-pcap) allows users to configure PCAPs to be downloaded from the Brain for analysis with 3rd party tools such as Wireshark.

**Guidance:**

* See [physical connections](#physical-connections) for the interfaces supported for capture use.
* Out of band deployment is the only supported method of traffic capture.
  * There is no inline mode for currently supported Vectra Sensor appliances.
* Traffic is typically forwarded to the Sensor via SPAN/COPY/MIRROR, traditional network TAPs, or 3rd party packet brokers.
* Capture ports do not get assigned IP addresses.
* The `show traffic stats` command, available at the Sensor’s CLI, may be useful to see if your traffic capture is successful before you can see the traffic graphs in your Brain’s GUI.
  * See [Traffic Graph showing no traffic (0 Mbps)](https://support.vectra.ai/vectra/article/KB-VS-1177) for more details.
* See [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture) for architecture guidance.
* See [Vectra Platform Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations) for what to capture.
* See [Asymmetry concerns in Vectra sensor feeds](/deployment/traffic-engineering-and-validation/asymmetry-concerns) for guidance around asymmetric flows.
* See [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv) for details on validating your traffic quality.

If required, Sensors can be configued to not allow PCAP creation when there are regulatory or privacy concerns. Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors* in your Vectra UI and edit the desired Sensor. Ensure the checkbox shown below is checked for Sensors you do not wish to perform any PCAP functions and then save your Sensor configuration:

<figure><img src="/files/bEcXhXME25EjIexgeAos" alt="" width="375"><figcaption></figcaption></figure>

* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# S1v2

The S1v2 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

{% hint style="info" %}
**Please Note regarding S1 vs S1v2 variants:**

Due to a sudden supply chain change, the original configuration of the S1 appliance is no longer available. Vectra has sourced a new base appliance from a different manufacturer and integrated it as the S1v2 variant. Below are the major differences.

**Port Option Settings**

There are some changes to the port options in the S1v2 variant:

* Up to four 1 GbE Copper capture interfaces can still be used if copper SFPs are installed.
  * These can be ordered with your appliance. See [supported SFPs and QSFPs](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) for details.
* There is no `set capture sfp` command as the S1v2 already has SFP+ ports enabled for capture use.
* This means there are only two possible port option settings versus the four in the original S1.

**Power and Mounting Differences**

The S1v2 ships with a single auto-sensing power supply but has the ability to accept input from two power supplies for redundancy. Only one power supply is required and if desired a second power supply can be purchased.

The S1v2 does not ship with a wall mount bracket like the original S1, but a rack mount kit is available for purchase.
{% endhint %}

This document is intended to help customers or partners with the initial configuration of a physical Vectra Sensor appliance. This is limited to basic network connectivity. This appliance can only be deployed in Sensor mode. Modes are discussed further in the deployment guide for your chosen UX. One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your Sensor following this guide, you can move on to paring your Sensor with your Brain appliance. Pairing for all Vectra appliances is covered in [pairing appliances](/deployment/appliance-operations/pairing-appliances).

Guide for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## Package Contents

* 1 S1v2 system
* 1 External power supply unit with AC cable matching locality from your order
* SFPs (matching details of your order)
  * See [SFPs and QSFPs supported in Vectra appliances](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) for options and additional detail.

## Physical Connections

<figure><img src="/files/HvcOnkEd0jdjy9YHgb89" alt=""><figcaption><p>S1v2 Front Panel - "Default" MGT1 Configuration (click to enlarge)</p></figcaption></figure>

{% hint style="info" %}
Please see [SFP+ Management Option](#sfp-management-option) for details on how to configure one of the SFP+ ports to be used for as the MGT1 management interface.
{% endhint %}

<figure><img src="/files/ygM8mfvwh01AE1bJt3p7" alt=""><figcaption><p>S1v2 Back Panel (click to enlarge)</p></figcaption></figure>

{% hint style="warning" %}
Please take care to not block any air holes in the chassis or the fan exhaust to ensure proper cooling of the system.
{% endhint %}

### Physical Connections Added Guidance

* One of the 10 GbE SFP+ ports can be configured as the MGT1 port.
  * Please see [SFP+ Management Option](#sfp-management-option) below for details on how to configure this and what the interface assignments would become after configuration. The diagram above only represents the default port options that the S1v2 appliance comes setup for.
* There are USB ports on the front and a VGA port on the back that can be used for keyboard and monitor for console (CLI) access to the appliance. This will work through KVM devices as well.
* The serial console port (RJ45 above the USB ports) is NOT supported by Vectra for console access.
* The IPMI port is NOT supported by Vectra for SOL console access.
* The S1 has a single 953 GB SSD drive.
  * Should it ever require replacement, please work with Vectra support.

### Minimum Connections Required

* Power
  * The S1 has an external 150W power supply. Auto-sensing, 100-240 VAC, at 50 or 60 Hz.
* MGT1 - RJ-45 ethernet (1 Gbps copper)
  * This is the port that will need to be configured with an IP address in your network for communication with your Vectra Brain.
* Capture - RJ-45 ethernet (1 Gbps copper), or SFP+ depending on your requirements.
  * At least one of the capture interfaces (ports) must be connected when you are ready to begin capturing traffic for analysis.

## Performance

| **Sensor Mode** | **Sensor (Match) Mode** |
| :-------------: | :---------------------: |
|      1 Gbps     |         400 Mbps        |

{% hint style="warning" %}
**Please Note:**

Even though there are multiple capture ports on the S1 appliance and you can configure the [Port Option Settings](#port-option-settings) to allow the SFP+ ports to be used for capture, any combination of capture interfaces used still have the above limitations for the overall performance for the S1 appliance. Care should be taken to only send a supported amount of traffic to the capture ports to avoid incomplete analysis.
{% endhint %}

**Definitions:**

* **Sensor Mode** – Bandwidth number shown refers to the amount of network traffic observed that the appliance can produce metadata for (capture bandwidth).
* **Sensor (Match) Mode** – Performance as a Sensor with [Match](/deployment/match/deployment) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.

{% hint style="info" %}
**Please Note:**

While considering performance for the Sensor it is important to understand that the traffic mix at customer sites varies widely. Some customers have traffic mixes that skew towards larger flows (think file transfers), and some will skew towards smaller flows (think DNS).

* Performance may be higher when the traffic mix skews towards larger flows.
* Performance will be lower when the traffic mix skews towards smaller flows as this produces more metadata for analysis.
* The stated performance is for average traffic mixes and should not be considered absolute.
  {% endhint %}

## SFP+ Management Option

While the S1v2 appliance supports a maximum throughput of 1Gbps for traffic capture and analysis, some customers may not have 1 GbE cooper connections available for management in the deployment location. The S1v2 supports a SFP+ management option that alters the default interface configuration to support this requirement:

{% hint style="info" %}
Using any of the capture ports (SFP+ or copper) does not change the max [performance](#performance) supported by the S1v2 appliance. Even though the interface might support 10 Gbps, the max throughput of the appliance is lower than the line speed of the interface, and care should be taken to only send a supported amount of traffic to the capture ports to avoid incomplete analysis.

While the physical ports are SFP+ interfaces, the terms SFP and SFP+ are used interchangeably below.
{% endhint %}

### Management Set to Default

This is the default configuration of the appliance, and the interface assignments are as shown in the diagram at the start of the [Physical Connections](#physical-connections) section.

### Management Set to SFP

After issuing the `set management sfp` command, the interface assignments become the following:

* MGT1 is now the bottom left of the four SFP+ ports.
* The port that was MGT1 in the default configuration is no longer used.
* The top left for the four SFP+ ports physically labeled eth3 has become eth2 in software.
* The bottom right of the four SFP+ ports that was unused in the default configuration has now been activated and can be used for capture as eth3.

Please see the below diagram port diagram that represents the new interface assignments:

<figure><img src="/files/pZ4q4DBc0gX0HzIp47YS" alt=""><figcaption><p>S1v2 Front Panel - "SFP" MGT1 Configuration (click to enlarge)</p></figcaption></figure>

{% hint style="info" %}
**Please Note:**

The physical labels on the appliance no longer are accurate for all ports when `set management sfp` is the configuration.
{% endhint %}

To change or check the management interface option, use the following commands:

* `set management`
  * Can be used to set the management port (MGT1) to `sfp` or `default`.
* `show management`
  * Will show the management interface configuration of `sfp` or `default`.

To make any of the changes, you will first need to [acces the CLI](#accessing-the-cli) so that you can execute the commands.

Please see below the syntax for using these commands:

```
vscli > set management --help
Usage: set management < ( default | sfp ) >

  Set Management Interface speed command

Options:
  -h, --help  Show this message and exit.
```

Example Usage:

```
vscli > set management sfp
vscli > show management
Management interface is set to SFP. See `show interface` for more information.
```

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* MGT1 port once configured

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the `set interface` command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

If your Sensor is already configured with an IP, it is recommended to ping the Brain IP to verify reachability before attempting pairing. Sensors must have port 22 and 443 open from the Sensor to your Brain for successful pairing and ongoing communication. Connectivity can be tested with the `debug connectivity` command.

* For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity yourbrainIP.customernetwork.com 443 –no-ssl
Connectivity: Success
Proxy: False
SSL: False
```

## Next Steps

### Brain and Sensor Communications Requirements

A Sensor (or Stream appliance) can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that the Sensor will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for the Sensor will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Pairing the Sensor to the Brain

After base configuration, it is suggested to pair your Sensor with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.

### Traffic Capture Guidance

{% hint style="info" %}
If capture ports are connected before pairing is completed, the Sensor will not buffer any traffic.
{% endhint %}

Simply point the traffic to be captured to your Sensor capture interfaces (ports). The Sensor will begin creating a metadata stream that will be analyzed by your Brain appliance. Sensors also have a rolling capture buffer that the Brain will request PCAPs from. The PCAPs will be attached as evidence with network detections as they are created.

Additionally, [Vectra packet capture](/deployment/traffic-engineering-and-validation/using-vectra-packet-capture-pcap) allows users to configure PCAPs to be downloaded from the Brain for analysis with 3rd party tools such as Wireshark.

**Guidance:**

* See [physical connections](#physical-connections) for the interfaces supported for capture use.
* Out of band deployment is the only supported method of traffic capture.
  * There is no inline mode for currently supported Vectra Sensor appliances.
* Traffic is typically forwarded to the Sensor via SPAN/COPY/MIRROR, traditional network TAPs, or 3rd party packet brokers.
* Capture ports do not get assigned IP addresses.
* The `show traffic stats` command, available at the Sensor’s CLI, may be useful to see if your traffic capture is successful before you can see the traffic graphs in your Brain’s GUI.
  * See [Traffic Graph showing no traffic (0 Mbps)](https://support.vectra.ai/vectra/article/KB-VS-1177) for more details.
* See [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture) for architecture guidance.
* See [Vectra Platform Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations) for what to capture.
* See [Asymmetry concerns in Vectra sensor feeds](/deployment/traffic-engineering-and-validation/asymmetry-concerns) for guidance around asymmetric flows.
* See [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv) for details on validating your traffic quality.

If required, Sensors can be configued to not allow PCAP creation when there are regulatory or privacy concerns. Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors* in your Vectra UI and edit the desired Sensor. Ensure the checkbox shown below is checked for Sensors you do not wish to perform any PCAP functions and then save your Sensor configuration:

<figure><img src="/files/bEcXhXME25EjIexgeAos" alt="" width="375"><figcaption></figcaption></figure>

* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# S11

The S11 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

This document is intended to help customers or partners with the initial configuration of a physical Vectra Sensor appliance. This is limited to basic network connectivity. This appliance can only be deployed in Sensor mode. Modes are discussed further in the deployment guide for your chosen UX. One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your Sensor following this guide, you can move on to paring your Sensor with your Brain appliance. Pairing for all Vectra appliances is covered in [pairing appliances](/deployment/appliance-operations/pairing-appliances).

Guide for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## Package Contents

* 1 S11 system
* 1 Rail kit
* 1 Power supply cord (matching requested type)
* 1 Vectra bezel
* SFPs (matching details of your order)
  * See [SFPs and QSFPs supported in Vectra appliances](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) for options and additional detail.

## Physical Connections

<figure><img src="/files/k9jVwO9C9dSoClkUK7g2" alt=""><figcaption><p>S11 Back Panel (click to enlarge)</p></figcaption></figure>

![S11 Front Panel (click to enlarge)](/files/946cbe73673b4096689f6f1bb2837ccd9e70fbf0)

### Physical Connections Added Guidance

* There are additional front USB ports on the right-hand side that can be used for KVM
  * You can use these or the rear USB ports for KVM
* The S11 has a single 480 GB SSD drive.
  * Should it ever need replacing, it is located on the left-hand side of the front.
* If you have questions about rail installation, watch this video:
  * <https://www.youtube.com/watch?v=JfOTnRMeE5w>
* Due to supply chain fluctuations, you may receive an S11 with a 4 port ethernet card in place of the 2 port ethernet card shown in the port diagram above..
  * Both 2 port and 4 port capture cards perform identically from a performance perspective.
  * For customers with 4 port capture cards, the left two ports are eth0 and eth1, the other two ports are inactive and can be ignored.

### Minimum Connections Required

Any SFPs that were included in your order will be in the top cardboard tray above the appliance itself.

* Power
  * The S11 has a 450W auto sensing power supply that supports 100-240 VAC supply at 50 or 60 Hz.
* MGT1 - RJ-45 ethernet (1 Gbps copper)
  * This is the port that will need to be configured with an IP address in your network for communication with your Cognito platform (Brain).
* Capture
  * At least one of the capture ports (eth0, eth1) must be connected to your traffic source when you are ready to begin traffic capture.

## Performance

| **Sensor Mode** | **Sensor (Match) Mode** |
| :-------------: | :---------------------: |
|      2 Gbps     |         1.2 Gbps        |

**Definitions:**

* **Sensor Mode** – Bandwidth number shown refers to the amount of network traffic observed that the appliance can produce metadata for (capture bandwidth).
* **Sensor (Match) Mode** – Performance as a Sensor with [Match](/deployment/match/deployment) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.

{% hint style="info" %}
**Please Note:**

While considering performance for the Sensor it is important to understand that the traffic mix at customer sites varies widely. Some customers have traffic mixes that skew towards larger flows (think file transfers), and some will skew towards smaller flows (think DNS).

* Performance may be higher when the traffic mix skews towards larger flows.
* Performance will be lower when the traffic mix skews towards smaller flows as this produces more metadata for analysis.
* The stated performance is for average traffic mixes and should not be considered absolute.
  {% endhint %}

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1 (not S1v2), S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the `set interface` command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

If your Sensor is already configured with an IP, it is recommended to ping the Brain IP to verify reachability before attempting pairing. Sensors must have port 22 and 443 open from the Sensor to your Brain for successful pairing and ongoing communication. Connectivity can be tested with the `debug connectivity` command.

* For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity yourbrainIP.customernetwork.com 443 –no-ssl
Connectivity: Success
Proxy: False
SSL: False
```

## Next Steps

### Brain and Sensor Communications Requirements

A Sensor (or Stream appliance) can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that the Sensor will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for the Sensor will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Pairing the Sensor to the Brain

After base configuration, it is suggested to pair your Sensor with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.

### Traffic Capture Guidance

{% hint style="info" %}
If capture ports are connected before pairing is completed, the Sensor will not buffer any traffic.
{% endhint %}

Simply point the traffic to be captured to your Sensor capture interfaces (ports). The Sensor will begin creating a metadata stream that will be analyzed by your Brain appliance. Sensors also have a rolling capture buffer that the Brain will request PCAPs from. The PCAPs will be attached as evidence with network detections as they are created.

Additionally, [Vectra packet capture](/deployment/traffic-engineering-and-validation/using-vectra-packet-capture-pcap) allows users to configure PCAPs to be downloaded from the Brain for analysis with 3rd party tools such as Wireshark.

**Guidance:**

* See [physical connections](#physical-connections) for the interfaces supported for capture use.
* Out of band deployment is the only supported method of traffic capture.
  * There is no inline mode for currently supported Vectra Sensor appliances.
* Traffic is typically forwarded to the Sensor via SPAN/COPY/MIRROR, traditional network TAPs, or 3rd party packet brokers.
* Capture ports do not get assigned IP addresses.
* The `show traffic stats` command, available at the Sensor’s CLI, may be useful to see if your traffic capture is successful before you can see the traffic graphs in your Brain’s GUI.
  * See [Traffic Graph showing no traffic (0 Mbps)](https://support.vectra.ai/vectra/article/KB-VS-1177) for more details.
* See [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture) for architecture guidance.
* See [Vectra Platform Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations) for what to capture.
* See [Asymmetry concerns in Vectra sensor feeds](/deployment/traffic-engineering-and-validation/asymmetry-concerns) for guidance around asymmetric flows.
* See [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv) for details on validating your traffic quality.

If required, Sensors can be configued to not allow PCAP creation when there are regulatory or privacy concerns. Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors* in your Vectra UI and edit the desired Sensor. Ensure the checkbox shown below is checked for Sensors you do not wish to perform any PCAP functions and then save your Sensor configuration:

<figure><img src="/files/bEcXhXME25EjIexgeAos" alt="" width="375"><figcaption></figcaption></figure>

* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# S17

The S17 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

{% hint style="info" %}
**Please Note:**

The S17 appliance is coming soon. Please talk with your Vectra account team for more details.
{% endhint %}

This document is intended to help customers or partners with the initial configuration of a physical Vectra Sensor appliance. This is limited to basic network connectivity. This appliance can only be deployed in Sensor mode. Modes are discussed further in the deployment guide for your chosen UX. One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your Sensor following this guide, you can move on to paring your Sensor with your Brain appliance. Pairing for all Vectra appliances is covered in [pairing appliances](/deployment/appliance-operations/pairing-appliances).

Guide for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## Package Contents

* 1 S17 system
* 1 Rail kit
* 1 Power supply cord (matching requested type)
* 1 Vectra bezel

## Physical Connections

<figure><img src="/files/F8W3qslb5OEKhLjUONib" alt=""><figcaption><p>S17 Back Panel (click to enlarge)</p></figcaption></figure>

<figure><img src="/files/AD6fBK7JPbAOaE69QGbe" alt=""><figcaption><p>S17 Front Panel (click to enlarge)</p></figcaption></figure>

### Physical Connections Added Guidance

* There are additional front USB ports on the right-hand side that can be used for KVM
  * You can use these or the rear USB ports for KVM
* The S17 has a two 800 GB (744 GiB) SSD drives configured in a RAID 1 mirror.
  * Should either ever need replacing, refer to disk numbers on the chassis.
* If you have questions about rail installation, watch this video:
  * <https://www.youtube.com/watch?v=JfOTnRMeE5w>

### Minimum Connections Required

Power

* The S17 has a 450W auto sensing power supply that supports 100-240 VAC supply at 50 or 60 Hz.

MGT1 - RJ-45 ethernet (1 Gbps copper)

* This is the port that will need to be configured with an IP address in your network for communication with your Cognito platform (Brain).

Capture

* The capture ports (eth0 must be connected to your traffic source when you are ready to begin traffic capture.

## Performance

| **Sensor Mode** | **Sensor (Match) Mode** |
| :-------------: | :---------------------: |
|      9 Gbps     |         2.5 Gbps        |

**Definitions:**

* **Sensor Mode** – Bandwidth number shown refers to the amount of network traffic observed that the appliance can produce metadata for (capture bandwidth).
* **Sensor (Match) Mode** – Performance as a Sensor with [Match](/deployment/match/deployment) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.

{% hint style="info" %}
**Please Note:**

While considering performance for the Sensor it is important to understand that the traffic mix at customer sites varies widely. Some customers have traffic mixes that skew towards larger flows (think file transfers), and some will skew towards smaller flows (think DNS).

* Performance may be higher when the traffic mix skews towards larger flows.
* Performance will be lower when the traffic mix skews towards smaller flows as this produces more metadata for analysis.
* The stated performance is for average traffic mixes and should not be considered absolute.
  {% endhint %}

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1 (not S1v2), S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the `set interface` command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

If your Sensor is already configured with an IP, it is recommended to ping the Brain IP to verify reachability before attempting pairing. Sensors must have port 22 and 443 open from the Sensor to your Brain for successful pairing and ongoing communication. Connectivity can be tested with the `debug connectivity` command.

* For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity yourbrainIP.customernetwork.com 443 –no-ssl
Connectivity: Success
Proxy: False
SSL: False
```

## Next Steps

### Brain and Sensor Communications Requirements

A Sensor (or Stream appliance) can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that the Sensor will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for the Sensor will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Pairing the Sensor to the Brain

After base configuration, it is suggested to pair your Sensor with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.

### Traffic Capture Guidance

{% hint style="info" %}
If capture ports are connected before pairing is completed, the Sensor will not buffer any traffic.
{% endhint %}

Simply point the traffic to be captured to your Sensor capture interfaces (ports). The Sensor will begin creating a metadata stream that will be analyzed by your Brain appliance. Sensors also have a rolling capture buffer that the Brain will request PCAPs from. The PCAPs will be attached as evidence with network detections as they are created.

Additionally, [Vectra packet capture](/deployment/traffic-engineering-and-validation/using-vectra-packet-capture-pcap) allows users to configure PCAPs to be downloaded from the Brain for analysis with 3rd party tools such as Wireshark.

**Guidance:**

* See [physical connections](#physical-connections) for the interfaces supported for capture use.
* Out of band deployment is the only supported method of traffic capture.
  * There is no inline mode for currently supported Vectra Sensor appliances.
* Traffic is typically forwarded to the Sensor via SPAN/COPY/MIRROR, traditional network TAPs, or 3rd party packet brokers.
* Capture ports do not get assigned IP addresses.
* The `show traffic stats` command, available at the Sensor’s CLI, may be useful to see if your traffic capture is successful before you can see the traffic graphs in your Brain’s GUI.
  * See [Traffic Graph showing no traffic (0 Mbps)](https://support.vectra.ai/vectra/article/KB-VS-1177) for more details.
* See [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture) for architecture guidance.
* See [Vectra Platform Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations) for what to capture.
* See [Asymmetry concerns in Vectra sensor feeds](/deployment/traffic-engineering-and-validation/asymmetry-concerns) for guidance around asymmetric flows.
* See [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv) for details on validating your traffic quality.

If required, Sensors can be configued to not allow PCAP creation when there are regulatory or privacy concerns. Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors* in your Vectra UI and edit the desired Sensor. Ensure the checkbox shown below is checked for Sensors you do not wish to perform any PCAP functions and then save your Sensor configuration:

<figure><img src="/files/bEcXhXME25EjIexgeAos" alt="" width="375"><figcaption></figcaption></figure>

* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# S101

Deploy an S101 appliance, verify connectivity, and review next steps for v1 and v2 hardware variants.

This document is intended to help customers or partners with the initial configuration of a physical Vectra Sensor appliance. This is limited to basic network connectivity. This appliance can only be deployed in Sensor mode. Modes are discussed further in the deployment guide for your chosen UX. One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your Sensor following this guide, you can move on to paring your Sensor with your Brain appliance. Pairing for all Vectra appliances is covered in [pairing appliances](/deployment/appliance-operations/pairing-appliances).

Guide for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## S101v1 vs S101v2

This document is for the S101v2. These models have serial numbers that start with “U2302”. The overall capabilities of the appliance are nearly identical regardless of the version. Capture port options and throughput are the same. S101v1 models included a serial port that was enabled for console access.

* Vectra no longer officially supports serial console access for S101v1 models
  * It is highly recommended to connect the iDRAC / IPMI interface and use it for any console access that cannot be accomplished via the normal MGT1 / MGT2 ports, or KVM.
  * Please see accessing the CLI for details on connecting to the CLI.

If you are configuring an S101v1 model, please see the attached guide below:

{% file src="/files/Ob8iys5W0ItP6Gfw3Eoc" %}

## Package Contents

* 1 S101 system with rail kit
* 2 power supply cords (matching requested type)
* 1 Vectra bezel
* SFPs and QSFPs (matching details of your order)
  * See [SFPs and QSFPs supported in Vectra appliances](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) for options and additional detail.

## Physical Connections

<figure><img src="/files/ICpLWsWz7uJ5cbZSrq2J" alt=""><figcaption><p>S101v2 Back Panel (click to enlarge)</p></figcaption></figure>

{% hint style="info" %}
**Please Note:**

Regarding interface labeling for the eth capture ports (eth0, eth1, eth2, eth3):

* The interfaces are given names by the OS as they become available, and they do not always become available in the same order. You may see capture interface names that are inconsistent with hardware labels after reboots. This does not impact capture performance or security efficacy and is no cause for alarm.

Regarding SFPs/QSFPs:

* SFP28 interfaces are only supported in the physical ports labeled eth2/eth3 above.
  * Even though an SFP28 is the same size as SFP+, they cannot function in the SFP+ slots on an S101 appliance.
* To use a SFP+ or SFP28 in a QSFP slot requires an adapter designed for either case. Please ask for this with your order if required.
  {% endhint %}

<figure><img src="/files/e4eb7a48f8204428da5b67183b7005c1dc031b3f" alt=""><figcaption><p>S101v2 Front Panel (click to enlarge)</p></figcaption></figure>

### Physical Connections Added Guidance

* If you have questions about rail installation, please watch this [video](https://www.youtube.com/watch?v=JfOTnRMeE5w).
* The S101 has drives on the front left side and front right side of the appliance. See the diagram for disk numbers
  * Should any drive ever require replacement, please work with Vectra support.
* Sensor appliances do NOT have a Graphical User Interface, please see [Accessing the CLI](#accessing-the-cli) for details on how to connect to the CLI.
  * Once paired to a Brain, most Sensor management is done via the Vectra UI in *Configuration → COVERAGE → Data Sources → Network → Sensors*.

### Minimum Connections Required

Any SFPs that were included in your order will be in the top cardboard tray above the appliance itself.

* Power
  * The S101 has two redundant power supplies. It is recommended to connect both.
* MGT1 – SFP28
  * This is the port that will need to be configured with an IP address in your network for pairing and ongoing communication with your Vectra Brain.
* Capture - QSFP28
  * At least one of the capture interfaces (ports) must have a supported SFP installed in it.

## Performance

| **Sensor Mode** | **Sensor (Match) Mode** |
| :-------------: | :---------------------: |
|     50 Gbps     |         33 Gbps         |

**Definitions:**

* **Sensor Mode** – Bandwidth number shown refers to the amount of network traffic observed that the appliance can produce metadata for (capture bandwidth).
* **Sensor (Match) Mode** – Performance as a Sensor with [Match](/deployment/match/deployment) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.

{% hint style="info" %}
**Please Note:**

While considering performance for the Sensor it is important to understand that the traffic mix at customer sites varies widely. Some customers have traffic mixes that skew towards larger flows (think file transfers), and some will skew towards smaller flows (think DNS).

* Performance may be higher when the traffic mix skews towards larger flows.
* Performance will be lower when the traffic mix skews towards smaller flows as this produces more metadata for analysis.
* The stated performance is for average traffic mixes and should not be considered absolute.
  {% endhint %}

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1 (not S1v2), S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the `set interface` command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

If your Sensor is already configured with an IP, it is recommended to ping the Brain IP to verify reachability before attempting pairing. Sensors must have port 22 and 443 open from the Sensor to your Brain for successful pairing and ongoing communication. Connectivity can be tested with the `debug connectivity` command.

* For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity yourbrainIP.customernetwork.com 443 –no-ssl
Connectivity: Success
Proxy: False
SSL: False
```

## Next Steps

### Brain and Sensor Communications Requirements

A Sensor (or Stream appliance) can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that the Sensor will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for the Sensor will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Pairing the Sensor to the Brain

After base configuration, it is suggested to pair your Sensor with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.

### Traffic Capture Guidance

{% hint style="info" %}
If capture ports are connected before pairing is completed, the Sensor will not buffer any traffic.
{% endhint %}

Simply point the traffic to be captured to your Sensor capture interfaces (ports). The Sensor will begin creating a metadata stream that will be analyzed by your Brain appliance. Sensors also have a rolling capture buffer that the Brain will request PCAPs from. The PCAPs will be attached as evidence with network detections as they are created.

Additionally, [Vectra packet capture](/deployment/traffic-engineering-and-validation/using-vectra-packet-capture-pcap) allows users to configure PCAPs to be downloaded from the Brain for analysis with 3rd party tools such as Wireshark.

**Guidance:**

* See [physical connections](#physical-connections) for the interfaces supported for capture use.
* Out of band deployment is the only supported method of traffic capture.
  * There is no inline mode for currently supported Vectra Sensor appliances.
* Traffic is typically forwarded to the Sensor via SPAN/COPY/MIRROR, traditional network TAPs, or 3rd party packet brokers.
* Capture ports do not get assigned IP addresses.
* The `show traffic stats` command, available at the Sensor’s CLI, may be useful to see if your traffic capture is successful before you can see the traffic graphs in your Brain’s GUI.
  * See [Traffic Graph showing no traffic (0 Mbps)](https://support.vectra.ai/vectra/article/KB-VS-1177) for more details.
* See [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture) for architecture guidance.
* See [Vectra Platform Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations) for what to capture.
* See [Asymmetry concerns in Vectra sensor feeds](/deployment/traffic-engineering-and-validation/asymmetry-concerns) for guidance around asymmetric flows.
* See [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv) for details on validating your traffic quality.

If required, Sensors can be configued to not allow PCAP creation when there are regulatory or privacy concerns. Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors* in your Vectra UI and edit the desired Sensor. Ensure the checkbox shown below is checked for Sensors you do not wish to perform any PCAP functions and then save your Sensor configuration:

<figure><img src="/files/bEcXhXME25EjIexgeAos" alt="" width="375"><figcaption></figcaption></figure>

* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# S127

The S127 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

This document is intended to help customers or partners with the initial configuration of a physical Vectra Sensor appliance. This is limited to basic network connectivity. This appliance can only be deployed in Sensor mode. Modes are discussed further in the deployment guide for your chosen UX. One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your Sensor following this guide, you can move on to paring your Sensor with your Brain appliance. Pairing for all Vectra appliances is covered in [pairing appliances](/deployment/appliance-operations/pairing-appliances).

Guide for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## S127 Package Contents

* 1 S127 system with rail kit
* 2 power supply cords (matching requested type)
* Vectra bezel
* SFPs and QSFPs (matching details of your order)
  * See [SFPs and QSFPs supported in Vectra appliances](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps) for options and additional detail.

## Physical Connections

<figure><img src="/files/xsUzvA13Fq9nNrH4g7mN" alt=""><figcaption><p>S127 Back Panel (click to enlarge)</p></figcaption></figure>

![S127 Front Panel (click to enlarge)](/files/1a9c9016bdfeaabc5e40c47b122d05df81795659)

### Physical Connections Added Guidance

* If you have questions about rail installation, please watch this [video](https://www.youtube.com/watch?v=JfOTnRMeE5w).
* The S127 has two SSDs on the front left side of the appliance. They are numbered 0 and 1, top to bottom.
  * Should either drive ever require replacement, please work with Vectra support.
* Sensor appliances do NOT have a Graphical User Interface, please see [Accessing the CLI](#accessing-the-cli) for details on how to connect to the CLI.
  * Once paired to a Brain, most Sensor management is done via the Vectra UI in *Configuration → COVERAGE → Data Sources → Network → Sensors*.

### Minimum Connections Required

Any SFPs that were included in your order will be in the top cardboard tray above the appliance itself.

* Power
  * The S127 has two redundant power supplies. It is recommended to connect both.
* MGT1 – SFP28
  * This is the port that will need to be configured with an IP address in your network for pairing and ongoing communication with your Vectra Brain.
* Capture - QSFP28
  * At least one of the capture interfaces (ports) must have a supported SFP installed in it.

## Performance

| **Sensor Mode** | **Sensor (Match) Mode** |
| :-------------: | :---------------------: |
|     58 Gbps     |         30 Gbps         |

**Definitions:**

* **Sensor Mode** – Bandwidth number shown refers to the amount of network traffic observed that the appliance can produce metadata for (capture bandwidth).
* **Sensor (Match) Mode** – Performance as a Sensor with [Match](/deployment/match/deployment) or [Suspect Protocol Activity Detections](/operations/general/suspect-protocol-activity-detections-feature-overview) enabled.

{% hint style="info" %}
**Please Note:**

While considering performance for the Sensor it is important to understand that the traffic mix at customer sites varies widely. Some customers have traffic mixes that skew towards larger flows (think file transfers), and some will skew towards smaller flows (think DNS).

* Performance may be higher when the traffic mix skews towards larger flows.
* Performance will be lower when the traffic mix skews towards smaller flows as this produces more metadata for analysis.
* The stated performance is for average traffic mixes and should not be considered absolute.
  {% endhint %}

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1 (not S1v2), S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the `set interface` command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

If your Sensor is already configured with an IP, it is recommended to ping the Brain IP to verify reachability before attempting pairing. Sensors must have port 22 and 443 open from the Sensor to your Brain for successful pairing and ongoing communication. Connectivity can be tested with the `debug connectivity` command.

* For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity yourbrainIP.customernetwork.com 443 –no-ssl
Connectivity: Success
Proxy: False
SSL: False
```

## Next Steps

### Brain and Sensor Communications Requirements

A Sensor (or Stream appliance) can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that the Sensor will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for the Sensor will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Pairing the Sensor to the Brain

After base configuration, it is suggested to pair your Sensor with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.

### Traffic Capture Guidance

{% hint style="info" %}
If capture ports are connected before pairing is completed, the Sensor will not buffer any traffic.
{% endhint %}

Simply point the traffic to be captured to your Sensor capture interfaces (ports). The Sensor will begin creating a metadata stream that will be analyzed by your Brain appliance. Sensors also have a rolling capture buffer that the Brain will request PCAPs from. The PCAPs will be attached as evidence with network detections as they are created.

Additionally, [Vectra packet capture](/deployment/traffic-engineering-and-validation/using-vectra-packet-capture-pcap) allows users to configure PCAPs to be downloaded from the Brain for analysis with 3rd party tools such as Wireshark.

**Guidance:**

* See [physical connections](#physical-connections) for the interfaces supported for capture use.
* Out of band deployment is the only supported method of traffic capture.
  * There is no inline mode for currently supported Vectra Sensor appliances.
* Traffic is typically forwarded to the Sensor via SPAN/COPY/MIRROR, traditional network TAPs, or 3rd party packet brokers.
* Capture ports do not get assigned IP addresses.
* The `show traffic stats` command, available at the Sensor’s CLI, may be useful to see if your traffic capture is successful before you can see the traffic graphs in your Brain’s GUI.
  * See [Traffic Graph showing no traffic (0 Mbps)](https://support.vectra.ai/vectra/article/KB-VS-1177) for more details.
* See [Vectra NDR (Detect) and Network Identity Architecture Overview](/deployment/getting-started/ndr-network-identity-architecture) for architecture guidance.
* See [Vectra Platform Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations) for what to capture.
* See [Asymmetry concerns in Vectra sensor feeds](/deployment/traffic-engineering-and-validation/asymmetry-concerns) for guidance around asymmetric flows.
* See [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv) for details on validating your traffic quality.

If required, Sensors can be configued to not allow PCAP creation when there are regulatory or privacy concerns. Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors* in your Vectra UI and edit the desired Sensor. Ensure the checkbox shown below is checked for Sensors you do not wish to perform any PCAP functions and then save your Sensor configuration:

<figure><img src="/files/bEcXhXME25EjIexgeAos" alt="" width="375"><figcaption></figcaption></figure>

* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# S2 (EOL)

The S2 quick start guide provides guidance for connecting your appliance to your network.

{% hint style="info" %}
**Please Note:**

**S2 sensors** have now reached their **End of Life** as of **07-Jan-2025** and therefore, are no longer supported by Vectra.

* End-of-Life - The date Vectra stops supporting an appliance.
  * The appliance will no longer be able to receive version updates or patches to the Vectra software and therefore will not receive new features, algorithm enhancements, bug fixes or any other update.
  * The appliance will no longer be eligible for technical support.
  * The appliance will no longer be covered for hardware break-fix (RMA or spare parts).

For further clarification on available hardware models and their lifecycle, please refer to the [Appliance EOS / EOL policy](/reference/appliance-eos-eol-policy).
{% endhint %}

### Guide

{% file src="/files/WiT89CGQkHZk0wxAqfmR" %}

## Contains

* Package Contents
* Physical Connections
  * Connections Required for Initial Configuration of MGT Port
  * Console Port Pinout
  * Additional Cabling Notes of Interest
* S2 Initial Configuration
  * DHCP Quick Start
  * Static Addressing Quick Start
    * Configuration Checklist for Static Addressing
    * Access the Command Line Interface (CLI) of the S2 Sensor
    * Setting a Static IP Address
* Worldwide Support Contact Information


# M-Series

Quick start guides and lifecycle notes for M-Series appliances.

{% content-ref url="/pages/chW5R3gPQq7Z4FTeBulO" %}
[M47](/deployment/ndr-physical-appliances/m-series/m47)
{% endcontent-ref %}

{% content-ref url="/pages/iS9OEiAX6C9z47dsw7Cj" %}
[M29 (EOS)](/deployment/ndr-physical-appliances/m-series/m29)
{% endcontent-ref %}


# M47

The M47 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

An M-Series appliance is used in place of a virtual appliance for Vectra Stream deployment. This document is intended to help customers or partners with the initial configuration.

One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your M-Series (Stream) appliance following this guide, you can move on to paring Stream with your Brain appliance. From a pairing perspective, Stream functions similarly to other Vectra physical Sensors. The [Stream Deployment Guide](/deployment/stream/deployment) covers full deployment details for Vectra Stream. Pairing for all Vectra appliances is also covered in [pairing appliances](/deployment/appliance-operations/pairing-appliances).

Guide for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## M47 Package Contents

* 1 M47 system
* 1 Rail kit
* 2 Power supply cords (matching requested type)
* 1 Vectra bezel
* SFPs (matching details of your order)
  * See [supported SFPs, and QSFPs ](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps)for details on options.

## Physical Connections

M47 hardware is identical to X47 hardware but with a different software load. Because of this, the X47 has more ports that are unused than an X47.

<figure><img src="/files/AuSPv34lJOpdV2Nfmwa5" alt=""><figcaption><p>M47 Back Panel (click to enlarge)</p></figcaption></figure>

![M47 Front Panel (click to enlarge)](/files/bd17e523d7bb47bc126388136a849a2519a5ecdd)

### Physical Connections Added Guidance

* There is an additional USB and VGA port on the front right-hand side that can be used for console access.
  * You can use these or the rear USB ports for console access.
  * The iDRAC Direct micro port under this front USB port is not supported. Please use the ethernet iDRAC port on the rear of the chassis for iDRAC/IPMI use.
* The M47 has two 800 GB and four 1.92 TB SSD drives.
  * Should any ever need replacing, contact Vectra support and refer to the disk numbers on the chassis.
* If you have questions on rail installation, watch this video: <https://www.youtube.com/watch?v=JfOTnRMeE5w>
* See [SFP28 Management Option](#sfp28-management-option) for details on using the eth2 SFP28 port for management instead of capture.

### Minimum Connections

* Power
  * The X47 has dual auto sensing power supplies supporting 100-240 VAC supply at 50 or 60 Hz.
  * It is recommended to connect both power supplies for redundancy.
* MGT1 - 1 GbE copper RJ45 (default) or SFP28 10/25 GbE
  * Either of these ports will need to be configured with an IP address in your network.
  * The X47 can be configured by the customer to allow the port labeled as eth2 (10/25 GbE SFP28) on the back of the appliance to function as the MGT1 port.
    * See [SFP28 Management Option](#sfp28-management-option) if fiber is required)

### SFP28 Management Option

The M47 can be configured by the customer to allow the port labeled as eth2 (10/25 GbE SFP28) on the back of the appliance to function as the MGT1 port. This will not give any performance benefit and is intended for use by customers who do not have any 1 GbE copper interfaces available for use as the MGT1 interface in the location in which they will deploy the M47 appliance.

<details>

<summary>Please expand for details if you wish to enable this option:</summary>

{% hint style="info" %}
Please note the following:

* It is recommended to use KVM, serial console, MGT2, or iDRAC/IPMI to connect to the appliance command line to make the change because unlike a SSH session, these will be unaffected by the change. See [Accessing the CLI](#accessing-the-cli) for details.
* For example, if you were connected to MGT1 in a staging area to make the change before moving into your data center where the 10 Gbps SFP+ was required, when the change is made your session would break and you would need to login again to configure a static address for the new MGT1 port.
* After making the change, physical port labels on the back of the appliance would no longer match how Vectra software displays the ports.
  * The port labeled as MGT1 changes to being unused by the Vectra software.
  * The port labeled as eth2 becomes MGT1.
  * The port labeled as eth3 becomes eth2 and remains unused in M47 configurations.
* The `show interface` command at the CLI can be used to show the actual negotiated speed and state of MGT interfaces.
  {% endhint %}

CLI commands to show configured MGT1 interface speed setting and change speed setting:

```
show management
set management <default|sfp>

Examples:
vscli > show management
Management interface is set to default. See `show interface` for more information.

vscli > set management sfp
vscli > show management
Management interface is set to sfp. See `show interface` for more information.
```

</details>

## Performance

An M47 system supports Stream performance of up to 75 Gbps. Actual bandwidth used to the downstream data lake will be a fraction of this number. This number represents how much traffic can be processed by Sensors attached to the Brain that the Stream appliance is paired to. Stream sends the enhanced and distilled metadata to the data lake.

{% hint style="info" %}
**Please Note:**

While considering performance for the appliance it is important to understand that the traffic mix at customer sites varies widely. Some customers have traffic mixes that skew towards larger flows (think file transfers), and some will skew towards smaller flows (think DNS).

* Performance may be higher when the traffic mix skews towards larger flows.
* Performance will be lower when the traffic mix skews towards smaller flows as this produces more metadata for analysis.
* The stated performance is for average traffic mixes and should not be considered absolute.
  {% endhint %}

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1, S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the "set interface" command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

If your Stream appliance is already configured with an IP, it is recommended to ping the Brain IP to verify reachability before attempting pairing. Stream must have port 22 and 443 open from the applaince to your Brain for successful pairing and ongoing communication. Connectivity can be tested with the `debug connectivity` command.

* For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity yourbrainIP.customernetwork.com 443 –no-ssl
Connectivity: Success
Proxy: False
SSL: False
```

## Next Steps

### Brain and Stream Communications Requirements

A Stream appliance can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Stream must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Stream discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Stream connections.

Additionally, for online pairing (physical Stream only), both Stream and the Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that Stream will be able to initiate a connection to the Brain. Stream only communicates with the Vectra Brain (and configured downstream data lake or SIEM) and does not need to communicate to Vectra directly. Software updates for Stream will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Pairing Stream to the Brain

After base configuration, it is suggested to pair Stream with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.
* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# M29 (EOS)

The M29 quick start guide provides guidance for initial deployment, verifying connectivity, and next steps to take after the appliance is connected to your network.

{% hint style="info" %}
The M29 appliance has reached EOS (End-of-Sale). Please see the [appliance EOS / EOL policy](/reference/appliance-eos-eol-policy) for additional details.
{% endhint %}

An M-Series appliance is used in place of a virtual appliance for Vectra Stream deployment. This document is intended to help customers or partners with the initial configuration.

One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

Full details on firewall requirements for your entire Vectra deployment are available in those guides or in [firewall requirements](/deployment/getting-started/firewall-requirements).

After you have completed the initial deployment of your M-Series (Stream) appliance following this guide, you can move on to paring Stream with your Brain appliance. From a pairing perspective, Stream functions similarly to other Vectra physical Sensors. The [Stream Deployment Guide](/deployment/stream/deployment) covers full deployment details for Vectra Stream. Pairing for all Vectra appliances is also covered in [pairing appliances](/deployment/appliance-operations/pairing-appliances).

Guide for other appliances are located in [NDR physical appliances](/deployment/ndr-physical-appliances) and [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances).

## Package Contents

* 1 M29 system
* 1 Rail kit
* 2 Power supply cords (matching requested type)
* 1 Vectra bezel
* SFPs (matching details of your order)
  * See [supported SFPs, and QSFPs ](/deployment/ndr-physical-appliances/supported-sfps-and-qsfps)for details on options.

## Physical Connections

{% hint style="info" %}
X29 pictures are used below (X29 and M29 are identical hardware with different software loads).
{% endhint %}

<figure><img src="/files/jEUh2zxg0Gezfm9LzbuV" alt=""><figcaption><p>X29 Back Panel (click to enlarge)</p></figcaption></figure>

![X29 Front Panel (click to enlarge)](/files/b8zyBKCtLhuDsqd6MirG)

### Physical Connections Added Guidance

* Only the MGT1 port 1 is used for M29 deployment. The M29 does not capture traffic. The M29 receives metadata from the Brain, coverts it to Zeek format, and forwards it to the customer’s data lake or SIEM.
* Due to supply chain fluctuations, shipped M29 models with a 4 port ethernet card in place of the 2 port ethernet card shown in the port diagram above.
  * These ports were only used for capture and are therefore irrelevant for M29 use since the M29 only performs Stream functionality and does not perform and Sensor functions.
* Disks removed from any M29 model can't be read outside of the system they were removed from because of the use of encryption that is specific to each system.
* If you have questions about rail installation, watch this video:
  * <https://www.youtube.com/watch?v=JfOTnRMeE5w>

### Minimum Connections

* Power
  * The M29 has two redundant power supplies. It is recommended to connect both.
* MGT1 - 1 GbE copper RJ45 (default) or SFP+ 10 GbE
  * Either of these ports will need to be configured with an IP address in your network.
  * The M47 can be configured by the customer to allow the port labeled as eth0 (10 Gbps SFP+) on the back of the appliance to function as the MGT1 port.
    * See the 10 Gbps MGT1 option below if fiber is required)

### 10 Gbps MGT1 Option

The M29 can be configured by the customer to allow the port labeled as eth0 (10 Gbps SFP+) on the back of the appliance to function as the MGT1 port. This will not give any performance benefit and is intended for use by customers who do not have any 1 Gbps copper interfaces available for use as the MGT1 interface in the location in which they will deploy the M29 appliance.

<details>

<summary>Please expand for details if you wish to enable this option:</summary>

{% hint style="info" %}
**Please note the following:**

* It is recommended to use KVM, serial console, MGT2, or iDRAC/IPMI to connect to the appliance command line to make the change because unlike a SSH session, these will be unaffected by the change. See [Accessing the CLI](#accessing-the-cli) for details.
* For example, if you were connected to MGT1 in a staging area to make the change before moving into your data center where the 10 Gbps SFP+ was required, when the change is made your session would break and you would need to login again to configure a static address for the new MGT1 port.
* After making the change, physical port labels on the back of the appliance would no longer match how Vectra software displays the ports.
  * The port physically labeled as MGT1 changes to being unused by the Vectra software.
  * The port physically labeled as eth0 becomes MGT1.
  * What is physically labeled eth1 becomes eth0, eth2 becomes eth1, and eth3 becomes eth2.
    * These ports are unused in the M29 configuration (there is no traffic capture).
* The `show interface` command at the CLI can be used to show the actual negotiated speed and state of MGT interfaces.
  {% endhint %}

CLI commands to show configured MGT1 interface speed setting and change speed setting:

```
show management
set management <default|sfp>

Examples:
vscli > show management
Management interface is set to default. See `show interface` for more information.

vscli > set management sfp
vscli > show management
Management interface is set to sfp. See `show interface` for more information.
```

</details>

## Accessing the CLI

The Command Line Interface (CLI) of a physical Vectra appliance is accessible in multiple ways. All appliances will not always have all methods available. See [physical connections](#physical-connections) to see the options available for your specific model.

* KVM or “crash cart”
* Direct connection to "Support" (MGT2) port
* iDRAC/IPMI - not all appliance types will have iDRAC/IPMI
* MGT1 port once configured
* Serial console - only supported officially on S1, S2 (EOL), X29/M29, and the X80 (EOL) appliances.

Once you have connected to the CLI login prompt on the appliance, use the default credentials to login.

* Username: `vectra` and password: `changethispassword`
  * Please change the password immediately after logging in using the `set password` command.

### KVM or “crash cart”

If your appliance has USB and VGA ports, a KVM (Keyboard, Video, Mouse) switch or “crash cart” can be used to connect to the appliance console.

### Direct Connection to "Support" (MGT2) Port

A direct connection to the MGT2 port on your appliance.

* If you can physically connect to your MGT2 port, then you can direct connect to the MGT2 port via SSH to do the initial configuration.
* The appliance MGT2 port is factory configured with a 169.254.0.10/16 (255.255.0.0) address.
* Configure your host’s IP to 169.254.0.11 with subnet mask of 255.255.0.0.
* Use SSH to connect to the appliance from your host using the default credentials from above.

### iDRAC/IPMI

If your appliance has a built in Dell iDRAC / IPMI interface you can access the CLI through it.

{% hint style="info" %}
Vectra strongly recommends that customers configure iDRAC / IPMI access permanently for all platforms supporting this interface.

Benefits:

* Easier access in case of network connectivity issues or DHCP mishaps.
* Simpler remote IP address changes.
* Reduced resolution time during Vectra support engagements requiring console access.
  {% endhint %}

<details>

<summary>Please expand for iDRAC/IPMI configuration details:</summary>

The default username / password for iDRAC/IPMI is `vectra` / `changethispassword`.

To access the interface, point your web browser to **<http://your\\_iDRAC\\_IP>**

* Initially, your iDRAC interface will default to DHCP.

At the login screen enter your credentials:

<img src="/files/RS8NcHAZdp0q0iRdZ0sH" alt="Example iDRAC Login Screen" width="563">

Click on the **Virtual Console**:

<img src="/files/aG9jOjr7TOJEZJ5at7V3" alt="Virtual Console &#x22;Button&#x22; in iDRAC UI" width="563">

And you will be presented with a login prompt for the CLI:

![Example Login Prompt](/files/FMZHKVQDhB4SvnXR8BiL)

To set a static IP for iDRAC you must 1<sup>st</sup> be logged in to the CLI of the Sensor as the `vectra` user:

```
Command:
show ipmi_interface
 
Example Output:
Gateway: 10.2.0.1
Ip: 10.2.2.32
Mac: d0:94:66:48:0a:ad
Mode: static
Netmask: 255.255.0.0

To set the IPMI / iDRAC interface the command syntax and an example are shown below:

Syntax example:
set ipmi_interface -h
Usage: set ipmi_interface [OPTIONS] [dhcp|static] [IP_ADDRESS] [SUBNET_MASK] [GATEWAY_ADDRESS]
 
Set the ipmi interface config
 
Options:
-h, --help Show this message and exit.
 
Command Example (Static Addressing):
set ipmi_interface static 10.2.2.34 255.255.248.0 10.2.0.1
IPMI Interface Change: success
 
Command Example (DHCP):
set ipmi_interace dhcp
IPMI Interface Change: Success
```

</details>

### Serial Console

{% hint style="info" %}
Serial console is only supported on S1, S2 (EOL), X29/M29, and X80 (EOL) appliances.
{% endhint %}

If supported on your appliance model, the serial settings should be 115,200, 8, N, 1

* 115,200 baud data rate
* 8 data bits
* No parity bit
* 1 stop bit
* Do not enable flow control

## Initial Network Configuration

### DHCP

The appliance can obtain its network configuration from a DHCP server in your network. The MGT1 port functions as a DHCP client by default.

* Connect the management port (MGT1) of the appliance to the network switch.
* Find the IP address that was assigned to MGT1 from your DHCP server logs.
* You can also find the IP address at the CLI of your appliance if you can access it another way .
  * Use the `show interface` command to display the address that was assigned to MGT1 via DHCP once you are logged onto the appliance.
  * See Accessing the Command Line Interface (CLI) of the Appliance above for instructions on how to log on).

### Static Addressing

#### Configuration Checklist for Static Addressing

Below is a list of information needed for the initial configuration:

* IP address to be used for the MGT1 interface
* Default gateway IP address
* DNS nameserver IP addresses
  * DNS servers for the Sensor must be configured at the CLI if you are not using DHCP. This cannot be done in your Brain.

#### Setting a Static MGT1 IP Address

Once logged in to the appliance you can view the syntax for the "set interface" command:

```
set interface -h
Usage: set interface [OPTIONS] {mgt1|mgt2} {dhcp|static} [IP] [SUBNET_MASK]
                     [GATEWAY_ADDRESS]
 
  Sets network interfaces to either dhcp or static ip configuration
 
Options:
  -h, --help  Show this message and exit.
```

Setting the IP address example:

```
set interface mgt1 static 10.50.10.10 255.255.255.0 10.50.10.1
```

#### IPv6 Support:

IPv6 is supported for the MGT1 and MGT2 interfaces. For full details, including information regarding dual stack support, please [IPv6 Management Support for Vectra Appliances](/deployment/getting-started/ipv6-management-support-for-vectra-appliances) on the Vectra support portal. Below we will show how to enable IPv6 support (its off by default) and the syntax to use when setting an IPv6 address.

To enable/disable IPv6 support:

```
# show ipv6 enabled
IPv6 is disabled
 
# set ipv6 enabled
Response: ok
 
# show ipv6 enabled
IPv6 is enabled
 
# set ipv6 disabled
Response: ok
```

Setting IPv4 and IPv6 syntax examples:

Execute the following command to set the MGT1 or MGT2 (a gateway address cannot be configured for MGT2, the gateway on MGT1 will be used) interface to the desired static IP address:

```
IPv4 Syntax:
set interface mgt1 static x.x.x.x y.y.y.y z.z.z.z
set interface mgt2 static x.x.x.x y.y.y.y
 
Where:
x.x.x.x is the desired interface IP address
y.y.y.y is the desired interface network mask
z.z.z.z is the desired gateway
 
IPv6 Syntax:
set interface mgt1 static [IPv6 IP] [Subnet Mask] [Gateway]
 
Example:
set interface mgt1 static 2001:0db8:0:f101::25 64 2001:0db8:0:f101::1
```

#### Configuring DNS for the appliance:

Command syntax to set DNS (up to 3 nameservers are supported):

```
set dns [nameserver1 <ip>] [nameserver2 <ip>] [nameserver3 <ip>]
```

Configuring DNS Example:

```
set dns 10.50.10.101 10.50.10.102
```

Verifying DNS Configuration:

```
show dns
```

### Verifying your Connectivity:

Once you have configured an IP statically or via DHCP you can verify connectivity by pinging known IPs in your environment from the CLI with the `debug ping` command.

If your Stream appliance is already configured with an IP, it is recommended to ping the Brain IP to verify reachability before attempting pairing. Stream must have port 22 and 443 open from the applaince to your Brain for successful pairing and ongoing communication. Connectivity can be tested with the `debug connectivity` command.

* For more detail, please see [Checking brain or sensor network connectivity](https://support.vectra.ai/vectra/article/KB-VS-1280).

**Example:**

```
vscli > debug connectivity -h
Usage: debug connectivity [OPTIONS] HOST PORT
 
Test TCP connectivity to destination host or IP through proxy if configured
 
Options:
--bypass-proxy / --dont-bypass-proxy
Bypass proxy while testing connectivity if
proxy is configured
--ssl / --no-ssl Test connectivity to host using SSL
--timeout FLOAT Seconds to attempt a connection to host and
proxy if configured [default: 5]
-h, --help Show this message and exit.
 
vscli > debug connectivity yourbrainIP.customernetwork.com 443 –no-ssl
Connectivity: Success
Proxy: False
SSL: False
```

## Next Steps

### Brain and Stream Communications Requirements

A Stream appliance can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Stream must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Stream discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Stream connections.

Additionally, for online pairing (physical Stream only), both Stream and the Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that Stream will be able to initiate a connection to the Brain. Stream only communicates with the Vectra Brain (and configured downstream data lake or SIEM) and does not need to communicate to Vectra directly. Software updates for Stream will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Pairing Stream to the Brain

After base configuration, it is suggested to pair Stream with your Brain appliance.

* [Pairing appliances](/deployment/appliance-operations/pairing-appliances) covers pairing of all physical Vectra appliances.
* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# NDR virtual / cloud appliances

Deploy Brains and vSensors in virtualized and public cloud environments.


# AWS Brain

Deploy a Vectra Brain in an AWS account for RUX or QUX deployments.

## Introduction

Please see the sub pages of this page for the AWS Brain deployment guide contents.

## Attachments

Attached to this article there are 5 files that are used for integration with AWS from the Brain for Host ID, Security Hub integration (QUX deployments only) and CloudWatch integration (QUX deployments only). Please see [enabling integrations](/deployment/ndr-virtual-cloud-appliances/aws-brain/enabling-aws-integrations) in the guide for more details.

**HostIdTemplate.yml**- Used for integration with the AWS Resource Manager to collect artifacts that provide details to Vectra's automated HostID capability.

{% file src="/files/F4xUtybGpCH3nWLhGBOA" %}

**HostIdFederatedParentTemplate.yml** - Used for HostID in Federated AWS setups

{% file src="/files/Zmxi8lnqqMbkTyK8Tmls" %}

**HostIdFederatedChildTemplate.yml** - Used for HostID in Federated AWS setups

{% file src="/files/Y7HPxmMOXnTw5geMpzbE" %}

**SecurityHubTemplate** - (QUX deployments only) - Used for integration with AWS Security Hub

{% file src="/files/H2NeZ0tXa6IjOc8s9Nep" %}

**CloudwatchLogsTemplate** - (QUX deployments only) - Used for integration with AWS CloudWatch

{% file src="/files/y8r7PU0vCM3vAXVYcYun" %}

The files can also be downloaded from your Brain after deployment from the following locations:

* https\://\<brain\_hostname\_or\_IP>/resources/HostIdTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/HostIdFederatedParentTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/HostIdFederatedChildTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/SecurityHubTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/CloudwatchLogsTemplate.yaml/serve\_file


# Introduction and requirements

Prerequisites and deployment workflow for an AWS Brain.

## Introduction

This document outlines the steps to deploy a Vectra Brain in the customer’s AWS account. The Brain is distributed as an Amazon Machine Image (AMI) with an AWS CloudFormation Template (CFT). The AMI and CFT may be procured via private share to your AWS account or can be purchased from the AWS Marketplace. Please contact your Vectra sales team for details regarding a private offer for the AWS Marketplace option.

AWS Brains can be used in both Respond UX and Quadrant UX deployments. For more detail on Respond UX vs Quadrant UX please see [Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux). One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment).

## Deployment Process Overview

The steps involved in deploying the Brain include:

{% stepper %}
{% step %}

#### Preparing for deployment

Please ensure you meet all of the following:

* [Vectra Requirements](#vectra-requirements)
* [AWS Requirements](#aws-requirements)
* [Firewall requirements](/deployment/ndr-virtual-cloud-appliances/aws-brain/firewall-requirements)
  {% endstep %}

{% step %}

#### [Deploying the AMI](/deployment/ndr-virtual-cloud-appliances/aws-brain/deploying-the-ami)

This involves deploying the Brain image through a CloudFormation template. It is possible to deploy from the AWS Marketplace, but most customers deploy after receiving the template link from Vectra after their account has been whitelisted so their account can see the private image.
{% endstep %}

{% step %}

#### [Enabling integrations](/deployment/ndr-virtual-cloud-appliances/aws-brain/enabling-aws-integrations)

Vectra has integrations for HostID, Security Hub, and CloudWatch.
{% endstep %}

{% step %}

#### [Pairing Sensors or Stream](/deployment/ndr-virtual-cloud-appliances/aws-brain/pairing-sensors-or-stream)

Sensor appliances must be pairing with your Brain for NDR functionality. Sensors capture network traffic and distill a metadata stream that is analyzed by your Brain appliance.
{% endstep %}
{% endstepper %}

## Vectra Requirements

### Whitelisting

Purchases made through the AWS Marketplace do not require whitelisting. Determine the account and region where the Brain will be deployed and provide that information to Vectra. That account will be whitelisted by Vectra so that you will be able to see the Brain image in *Amazon EC2 > AMI > Private images*. AWS CloudFormation will be used to deploy, and it will need to be able to reach this image from your account. Seeing the image available means that the CFT deployment should be successful.

### Provisioning Token

Vectra will provide you with a provisioning token to use for deployments that are not done via the AWS Marketplace.

### Brain Sizing

When determining what size Brain should be deployed, this decision should be based on the amount of aggregate traffic that will be captured by the Brain’s paired Sensors that will then be sent as metadata to the Brain for analysis. Vectra currently offers four different sizes of Brains in AWS:

* 2 Gbps aggregate traffic / 50K IP addresses max, 15 Sensors max - r5d.2xlarge
* 5 Gbps aggregate traffic / 50K IP addresses max, 25 Sensors max - r5d.4xlarge
* 15 Gbps aggregate traffic / 150K IP addresses max, 100 Sensors max - r5d.8xlarge
* 50 Gbps aggregate traffic / 500K IP addresses max, 500 Sensors max – r5.16xlarge (v8.0 and higher only)
  * Please note that when deploying the 50 Gbps instance type, extra steps are required to modify the throughput of the /dev/sda1 disk through the AWS management console.
  * Please see [50 Gbps Brain Storage Throughput Modification](/deployment/ndr-virtual-cloud-appliances/aws-brain/deploying-the-ami#50-gbps-brain-storage-throughput-modification) for details.

{% hint style="info" %}
**Please Note:**

Vectra product and engineering teams monitor the changing landscape of available IaaS cloud instance types. Occassionally customers will ask if a specific new instance type is supported.

There are a number of factors that can cause Vectra AI to stay with a specific instance type versus a newer one such as:

* Cost increase vs performance increase - sometimes a newer instance, for example, might cost 17% more but only increase performance by 10%.
* Availability - not all new instance types are always available in all the locations that Vectra AI supports.

Please reach out to your account team if you have questions about specific instance types that aren't supported.
{% endhint %}

In some environments, you may wish to start with a smaller Brain instance and then later move to a larger Brain instance to handle additional load (metadata coming from paired sensors or additional paired sensors).

* Please see: [Resizing Virtual Sensors and Brains](/deployment/appliance-operations/resizing-virtual-appliances) for details.

## AWS Requirements

The services required for deploying a Vectra Brain are compute (Amazon EC2) with storage (Amazon EBS) and networking (AWS ENI), and identity and access management (AWS IAM) to enable integrations.

### VPC and Subnet

You will either need to create a new VPC and Subnet for use with the Brain you are deploying or re-use an existing one. You will choose these when filling out the CloudFormation template. Some AWS documentation is available at the following links:

* [What is Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
* [Overview of VPCs and subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html)
* [Create VPCs and subnets](https://docs.aws.amazon.com/vpc/latest/userguide/build-create-work-with.html)

### Security Group

The CloudFormation template will create an empty security group, or you may select an existing security group to use. The security group must allow port 443 and port 22 access from the administrator’s network, from the Vectra vSensor subnets and to the Vectra-hosted services listed in the [firewall requirements](/deployment/ndr-virtual-cloud-appliances/aws-brain/firewall-requirements).

### SSH Key Pair

An SSH key pair will need to be created for the Brain to allow an administrator to login to the CLI as the `vectra` user. The public key will need to be chosen in the CloudFormation template. Guidance for key pair generation is here:

* <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html?icmpid=docs_ec2_console>

After the Brain is deployed and registered with Vectra, you can login to the Brain CLI via SSH using the private key:

* You may need to make the key readable to you using a command such as:
  * `chmod 400 VectraBrainPrivateKey.pem`
* Example login command:
  * `ssh -i <private key path> vectra@BrainHostnameOrIP`

### AWS Connectivity Requirements

In addition to all the standard [firewall requirements](/deployment/ndr-virtual-cloud-appliances/aws-brain/firewall-requirements), please note the following that are specific to AWS deployments:

DNS resolution is provided by AWS by default. You do not need to list DNS servers for AWS unless you want to use something other than AWS provided defaults. An example would be when you want to pair by hostname and hostnames are only in your DNS and are not resolvable via AWS’s DNS. More detail about paring by hostname or IP is included in [Pairing Sensors or Stream](/deployment/ndr-virtual-cloud-appliances/aws-brain/pairing-sensors-or-stream).

NTP defaults to Ubuntu’s servers for all Vectra Brains, but the default can be changed as desired in *Configuration → COVERAGE → Network → Data Sources > Network > Brain Setup > NTP Entries*.


# Firewall requirements

Connectivity and security group rules for AWS Brain deployments.

## Firewall Requirements Sections

[Important Notes](#important-notes)\
This section covers Respond UX vs Quadrant UX applicability. It also covers SSL inspection, internet/air-gap requirements, and remote support IP range conflicts.

[Vectra Cloud Connectivity](#vectra-cloud-connectivity)\
This section covers connectivity to Vectra services hosted in Vectra’s cloud. It is mainly for Respond UX deployments. The [Auth Gateways](#auth-gateways) section also applies to Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.

[Appliance Connectivity](#appliance-connectivity)\
This section covers connectivity required for Vectra appliances (physical or virtual). It applies to both RUX for Network and Quadrant UX deployments. This section also contains additional details regarding connectivity from Vectra appliances to the Vectra cloud.

## Important Notes

### Respond UX vs Quadrant UX Applicability

The Respond User Experience (Respond UX or RUX) and the Quadrant User Experience (Quadrant UX or QUX) are two different analyst user experiences that Vectra offers. It is important to differentiate between the different UX's when looking at requirements for FW rules. Some FW rules will only apply to deployments using the Respond UX and some will apply only to deployments using the Quadrant UX. For additional information please see: Vectra Analyst User Experiences (Respond vs Quadrant).

While the Respond UX is delivered from Vectra's cloud as part of the overall Vectra AI Platform, it can be used without traditional Brain and Sensor appliances when only non-network data sources are used. RUX for Network deployments (using network Sensors with the Respond UX) still require a Brain appliance to be installed in the customer environment (which can be in IaaS clouds or physical data centers, etc). Sensors will be deployed and paired with that Brain to capture network traffic for analysis.

Requirements listed below that apply only to RUX for Network deployments or only to QUX deployments will be labeled as such.

### Firewall/Proxy SSL Inspection

Please note that Vectra appliances validate SSL certificates for all HTTPS connections. For this reason, SSL/TLS inspection on firewall and proxy appliances must be disabled for these connections to work.

We have also identified that some firewall software transparently enables SSL inspection if certain filters (DNS hostname filtering) are enabled. This is not necessarily obvious to the administrator and should be investigated if connectivity issues are being observed.

### Internet Access From Vectra Brain

A Vectra Brain requires connectivity to the automatic update service for normal operation. This connectivity is used for automatic (including security) updates and to synchronize keys for cryptographic authentication of sensors.

The Brain requires Internet DNS resolution to obtain the IP addresses for these requests. The customer may choose public/Internet DNS servers or internal DNS servers; however, Internet DNS entries must be resolvable by the Brain. Please note that DNS is often considered to be a UDP-only protocol, however, TCP may be used depending on the type of DNS transaction. Both UDP and TCP use port 53 and should be permitted to all configured DNS servers.

Vectra can function in air-gapped environments when a Quadrant UX based deployment is done, but there will be some impacts such as:

* Vectra Threat Intelligence detections will be disabled.
* Suspect Domain Activity detection will be disabled.
* Context enrichments from external sources such as whois, etc that are displayed in certain models will not function.

Please see the [Vectra Quadrant UX Deployment Guide](https://support.vectra.ai/s/article/KB-VS-1077) for additional details about air gap environments including guidance for offline updates. Respond UX for Network is not possible in air-gapped environments since the Respond UX is delivered from Vectra's cloud and communicates with a locally installed Brain.

### Internet Access to Vectra Appliances

As with all security infrastructure Vectra appliances should be blocked from Internet access and access should only be granted from trusted workstations and/or authenticated sources.

### Management Network IP Address Range Conflicts with Remote Support

Customers should note that the following IP ranges will conflict with remote support capability:

* 192.168.72.0/21
* 192.168.80.0/21

If you will ever need Vectra to assist remotely (outside of screen sharing sessions), care should be taken to number the management network interface (MGT) used on any appliance (physical, virtual, or cloud - Brains or Network Data Sources/Sensors) outside of the above ranges. If your management network interface (MGT) is numbered in either of these ranges, remote support access will not function. Remote support connectivity with Vectra all goes through the Brain (even to access other appliances in your deployment) so firewall rules for remote support functionality only need to allow connectivity from the Brain to Vectra's cloud (Sensors must still allow connectivity to the Brain per the below charts).

## Vectra Cloud Connectivity

* For this document, the portions of the Vectra AI Platform that reside in Vectra’s cloud are referred to as the Vectra cloud.
  * This does not refer to any specific service offering.
* Please check each category below to see if it is applicable to your deployment and if rules are required in your environment to enable the required connectivity.
  * For rule categories that have multiple region options, it is only necessary to put rules in place to allow connectivity to the region that your Vectra tenant is deployed in. This region should be visible in the URL used to access the Respond UX.
    * i.e. `[tenant_id].ew1.prod.vectra-svc.ai` is used for EU deployments (ew1).
* RUX for Network refers to a RUX deployment that has enabled network data sources (sensors).
  * This means you have a Brain somewhere in your premises (data center or public cloud) that is connected to the Vectra cloud for use with the Respond UX and paired with network Sensors (virtual or physical) to capture network traffic and distill a metadata stream for processing by the Brain appliance.
  * Please refer to the [Vectra Respond UX Deployment Guide](https://support.vectra.ai/s/article/KB-VS-1696) for more details.
* Please refer to the table below to see applicability of the various categories.
* The **For Brain or User’s Browser** column should be interpreted as follows:
  * **Brain** – Rules required for the Brain to the Vectra Cloud.
  * **User’s Browser** – Rules required for the user’s web browser to the Vectra cloud.

<table data-header-hidden data-full-width="true"><thead><tr><th width="318.47265625"></th><th width="281.6796875"></th><th width="259.9375"></th></tr></thead><tbody><tr><td><strong>Rule Category</strong></td><td><strong>Required For</strong></td><td><strong>For Brain or User’s Browser</strong></td></tr><tr><td><a href="#rux-for-network-gui-synchronization">RUX for Network GUI Synchronization</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#auth-gateways">Auth Gateways</a></td><td><p>RUX for Network Deployments</p><p>Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.</p></td><td>Brain</td></tr><tr><td><a href="#rux-metadata-forwarding">RUX Metadata Forwarding</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#rux-research-metadata-forwarding">RUX Research Metadata Forwarding</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#section-2">RUX Analyst/Admin Access</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#_Respond_UX_(RUX)_1">RUX Static Asset CDN</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#_Respond_UX_Customer">RUX Customer File Upload</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#vectra-cloud-egress-ips">Vectra Cloud Egress IPs</a></td><td>Vectra Cloud connecting to configured SaaS data source connectors</td><td>N/A</td></tr></tbody></table>

### RUX for Network GUI Synchronization

* Required for:
  * All RUX for Network deployments.
* This is used to synchronize configurations between the Brain appliance and your Vectra tenant.
* This communications channel is initiated from the Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **Websocket and HTTPS over TCP/443**

<table data-header-hidden data-full-width="false"><thead><tr><th width="365.3203125" align="center"></th><th width="100" align="center"></th><th width="100" align="center"></th><th width="144.20703125" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">main-cbi-tunnel-uw2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-ew1.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-ec2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-cc1.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-as2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### Auth Gateways

* Required for:
  * All Respond UX for Network Deployments.
  * Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.
    * Your Brain must be able to securely access the Vectra cloud over TCP/443 HTTPS connections to enable detection events from these products to be reported to your UI.
* In Respond UX for Network deployments, the Brain forwards network detections, entities, host sessions, and any selective PCAPs (Vectra Packet Capture) to your Vectra tenant via this connection.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.

<table data-header-hidden data-full-width="true"><thead><tr><th width="383.625" align="center"></th><th width="149.61328125" align="center"></th><th width="148.4609375" align="center"></th><th width="121.22265625" align="center"></th><th width="137.1484375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">authgateway.uw2.public.app.prod.vectra-svc.ai</td><td align="center">54.245.33.175<br>52.42.70.176<br>100.21.109.72<br>52.26.91.157</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.ew1.public.app.prod.vectra-svc.ai</td><td align="center">54.171.40.108<br>54.246.213.148<br>54.75.47.147</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.ec2.public.app.prod.vectra-svc.ai</td><td align="center"><p>16.62.18.237</p><p>16.62.142.98</p><p>51.96.54.201</p></td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.cc1.public.app.prod.vectra-svc.ai</td><td align="center">3.96.112.208<br>52.60.211.221<br>15.222.69.161</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.as2.public.app.prod.vectra-svc.ai</td><td align="center">13.54.11.66<br>13.55.79.24<br>13.55.106.102</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Metadata Forwarding

* Required for:
  * All Respond UX for Network Deployments.
* Network metadata is forwarded to AWS S3 buckets and processed to make it available for features such as Instant Investigation and Advanced Investigation in the Respond UX.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="514.98046875" align="center"></th><th width="100" align="center"></th><th width="119.75390625" align="center"></th><th width="146.4296875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-uswt2-371371611652.s3-accesspoint.us-west-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-euwt1-371371611652.s3-accesspoint.eu-west-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-eucl2-371371611652.s3-accesspoint.eu-central-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-cacl1-371371611652.s3-accesspoint.ca-central-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-apse2-371371611652.s3-accesspoint.ap-southeast-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Research Metadata Forwarding

* Optional but highly recommended for:
  * All Respond UX for Network Deployments
* Research metadata from precursor algorithms are used to improve model quality and reduce detection noise.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="490.4140625" align="center"></th><th width="100" align="center"></th><th width="120.79296875" align="center"></th><th width="135.91796875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">cbo-upload-network-precursors-uswt2-371371611652.s3-accesspoint.us-west-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-euwt1-371371611652.s3-accesspoint.eu-west-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-eucl2-371371611652.s3-accesspoint.eu-central-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-cacl1-371371611652.s3-accesspoint.ca-central-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-apse2-371371611652.s3-accesspoint.ap-southeast-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Analyst/Admin Access

* Required for:
  * All Respond UX deployments.
* Any analyst or admin that wishes to access the Respond UX will need to ensure that their browser can reach their Vectra tenant to login and access the UI.
* This communications channel is initiated from the user’s host.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="340.640625" align="center"></th><th align="center"></th><th align="center"></th><th width="139.19921875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">[tenant_id].uw2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].ew1.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].ec2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].cc1.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].as2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">User’s Browser</td></tr></tbody></table>

### RUX Static Asset CDN

* Required for:
  * All Respond UX deployments.
* The Respond UX has certain static assets (HTML, CSS, JS) that are required to serve the web application hosted by a CDN (Content Delivery Network).
* This communications channel is initiated from the user’s host.

<table data-header-hidden data-full-width="true"><thead><tr><th width="313.40234375" align="center"></th><th width="153.4609375" align="center"></th><th width="100" align="center"></th><th width="100" align="center"></th><th width="142.07421875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center"><p>dd6462tdmvp79.cloudfront.net</p><p>dpew7prsvwbf0.cloudfront.net</p></td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">All</td><td align="center">User’s Browser</td></tr></tbody></table>

### RUX Customer File Upload

* Required for:
  * All Respond UX deployments.
* This communications channel is used for:
  * Vectra Match deployments and will allow upload of rulesets.
  * PCAP download from the Vectra Cloud for Selective PCAP (Vectra Packet Capture)
  * Additional capabilities are planned for future releases.
    * It is recommended to put rules in place even if you don’t use Match or Selective PCAP.
* This communications channel is initiated from the user’s host.

<table data-full-width="true"><thead><tr><th width="395.8828125" align="center"></th><th width="151.8515625" align="center"></th><th width="93.1875" align="center"></th><th width="84.61328125" align="center"></th><th width="144.1015625" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">prd-main-customerfiles-580786928539-uswt2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">US</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-euwt1.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-eucl2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-cacl1.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-apse2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">User’s Browser</td></tr></tbody></table>

### Vectra Cloud Egress IPs

When the Vectra Cloud connects externally to retrieve logs from configured data sources, it does so from the IPs listed at <https://ips.devops.vectra-svc.ai/ips.json>. The specific IPs used will be limited to the IPs listed for the regions in use for your Vectra deployment. For example, if you are only deployed in eu-west-1, then only the IPs from the list associated with eu-west-1 will be used. See the following table for details.

<table><thead><tr><th width="315.4375">Region Code</th><th width="297.0234375">Region</th></tr></thead><tbody><tr><td>ap-southeast-2</td><td>Australia</td></tr><tr><td>ca-central-1</td><td>Canada</td></tr><tr><td>eu-central-2</td><td>Switzerland</td></tr><tr><td>eu-west-1</td><td>EU</td></tr><tr><td>us-west-2</td><td>US</td></tr></tbody></table>

In most situations, customers do NOT need to configure any specific firewall rules to allow Vectra to reach the endpoints required. If you see the IPs in the list accessing your data in your logs, this is not a cause for concern. It is due to the fact that your configured data source connector is connecting to the endpoint to retrieve the data necessary to provide the service.

In the case of CDR for Azure, if private access is required for the Azure storage accounts that Vectra reads your Azure logs from, please see [Configuring Private Access for Azure Storage Accounts](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#configuring-private-access-for-azure-storage-accounts) in the CDR for Azure deployment guide. Details are provided for how to configure the Storage accounts used to only accept connections from the IPs associated with the Vectra Cloud.

## Appliance Connectivity

The [Vectra Cloud connectivity](#vectra-cloud-connectivity) section above primarily deals with connectivity required to deliver the Respond UX and detections from Vectra SaaS offerings to both RUX and QUX deployments, the content in this section also applies to any deployment using Vectra appliances (Brains, Sensors, and Stream) for RUX or QUX deployments.

### Vectra Cloud Appliance Connectivity

All communications with the Vectra Cloud occur over a TLS encrypted channel. Appliance devices (physical, virtual, cloud) authenticate using keys. Unique public/private keys are generated when a device is provisioned by Vectra. The corresponding public key is copied to the Vectra Cloud. Every device connecting to the Vectra Cloud authenticates using its own private key.

The Vectra Cloud houses several services:

* update2.vectranetworks.com
  * Used for delivering updates to the Vectra software.
  * [Offline updates](/operations/readme-1/offline-updates-v89) are also supported.
* api.vectranetworks.com
  * Used for lightweight health monitoring of the Vectra platform and for delivering additional context certain Detections may need.
  * Queries to external information sources to provide context are proxied through this connection.
  * If required, customers can block the platform from reporting health monitoring by blocking outbound connections on their firewall to api.vectranetworks.com.
* rp.vectranetworks.com
  * Used only for Brains deployed in IaaS clouds. Used for authentication and verification (integrity check of the file system).
* metadata.vectra.ai
  * Metadata sharing improves threat detection by contributing anonymized metadata sourced from Brain deployed in your organization. This is optional in QUX deployments.
* rs.vectranetworks.com
  * This enables remote support from authorized Vectra employees.
* SaaS product offerings such as Recall

#### Proxy Support

Vectra Cloud connectivity to update2.vectranetworks.com and api.vectranetworks.com supports connecting through a customer proxy. If a proxy connection is required for your Brain appliance to reach these endpoints, edit the proxy settings in *Configuration → Data Sources → Network → Brain Setup → Proxy & Status*.

* Note that [Remote Support](/configuration/access/vectra-remote-support) does not support proxy configuration by default. If this is the only option, please contact Vectra support to configure remote support to manually to use a proxy.

#### Lightweight Health Monitoring

The lightweight health monitoring includes the following statistics, only aggregate statistics are collected, no details are collected.

* System Health Metrics
  * Installed packages, running processes, system interface information, system usage, database usage, system error stats
* Environment Metrics
  * Host counts, traffic counts, Brain configuration, remote support status, notification status, metadata status
* Detection Metrics
  * Detection counts, PCAP stats, Triage stats

#### Metadata Sharing

[Why is Metadata Sharing Important](/reference/why-is-metadata-sharing-important)

* Full details are available at this link. There are optional additional levels of sharing also described.

Metadata Sharing Improves Threat Detection

* By contributing anonymized metadata sourced from the X-series platform deployed in your organization, you are contributing directly to the efficacy and accuracy of the Vectra software and the security of your network.
* Access to Detection metadata improves Vectra’s threat detection algorithms, enabling the Vectra software you use to be more effective in a constantly evolving threat landscape.
* Data is collected daily and includes:
  * Anonymized information about Detections that are triggered in your network.
  * Anonymized information about algorithms in the research and development phase (and not yet visible in the UI) that are triggered in your network.
  * Anonymized attribution of Detections to Hosts.
  * Anonymized information related to host identification efficacy.
* Vectra Secures and Limits Access to Metadata
  * Any metadata you contribute is anonymized by removing personal and network-specific information before it is sent to metadata.vectranetworks.com via an encrypted connection.
  * Vectra treats this metadata as highly confidential and only allows authorized research personnel to access the metadata.
  * Any metadata collected is securely deleted after a six-month period.
* Contact Vectra support if non-anonymized Full Metadata Sharing is desired
  * Algorithm development using non-anonymized metadata helps to ensure that new models function as efficiently as possible in your environment.

### Required Connectivity For Appliances

<table data-header-hidden data-full-width="true"><thead><tr><th width="131.375" align="center"></th><th width="253.46875" align="center"></th><th width="177.15234375" align="center"></th><th width="288.40234375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td><td align="center"><strong>Description</strong></td></tr><tr><td align="center">Administrator workstations</td><td align="center"><p>Brain</p><p>Sensors</p></td><td align="center">TCP/22 (SSH)</td><td align="center">Command-line management of the Brain and Sensor appliances.</td></tr><tr><td align="center">Administrator workstations</td><td align="center">Brain</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Web management of brain appliances.</td></tr><tr><td align="center">Brain</td><td align="center"><p>update2<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.156.238)</p></td><td align="center">TCP/443<br>(HTTPS)</td><td align="center"><p>Automatic updates.</p><p>Pairing keys for physical sensors.</p><p>See note above regarding SSL keys.</p></td></tr><tr><td align="center">Brain</td><td align="center"><p>api<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.5.9)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Health monitoring, algorithm support, reverse lookups for external IPs, Vectra Threat Intelligence, additional detection content. See note above regarding SSL keys.</td></tr><tr><td align="center">Brain (Cloud)</td><td align="center"><p>rp<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.156.238)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Used only for Brains deployed in IaaS clouds. Used for authentication and verification (integrity check of the file system)</td></tr><tr><td align="center">Brain</td><td align="center">DNS servers (as configured)</td><td align="center">TCP/53, UDP/53</td><td align="center">Both TCP and UDP are required for normal operation. See note above regarding DNS resolution.</td></tr><tr><td align="center">Brain</td><td align="center"><p>NTP servers (as configured)</p><p>Default is ntp.ubuntu.com</p></td><td align="center">UDP/123</td><td align="center">Time synchronization.</td></tr><tr><td align="center">Brain</td><td align="center">SMTP servers (as configured)</td><td align="center">TCP (as configured)</td><td align="center">Email alerting.</td></tr><tr><td align="center">Brain</td><td align="center">SMTP (OAuth)</td><td align="center">TCP/443<br>TCP/587</td><td align="center">Please see SMTP (OAuth) for Microsoft chart below.</td></tr><tr><td align="center">Brain</td><td align="center">Sensors, Stream</td><td align="center">TCP/22 (SSH)</td><td align="center">Remote management and troubleshooting.</td></tr><tr><td align="center">Sensors, Stream</td><td align="center">Brain</td><td align="center">TCP/22 (SSH), TCP/443 (HTTPS)</td><td align="center">Pairing, metadata transfer, and ongoing communication.</td></tr><tr><td align="center">Stream</td><td align="center">Data lake (as configured)</td><td align="center">TCP (as configured)</td><td align="center">Metadata stream to a data lake</td></tr></tbody></table>

### Additional (Feature Dependent) Connectivity

<table data-header-hidden data-full-width="true"><thead><tr><th width="132.6796875" align="center"></th><th width="395.2890625" align="center"></th><th width="167.9609375" align="center"></th><th width="339.06640625" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td><td align="center"><strong>Description</strong></td></tr><tr><td align="center">Brain</td><td align="center">content.user-telemetry.vectra.ai<br>data.user-telemetry.vectra.ai</td><td align="center">TCP/443<br>(HTTPS)</td><td align="center">Required for In-App support functionality.<br>See <a href="https://support.vectra.ai/s/article/KB-VS-1606">In-App Support KB</a> for more details.</td></tr><tr><td align="center">Administrator workstations</td><td align="center">Recall Kibana server</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Recall IP addresses are provided during implementation and may be requested at any time from Vectra Support.</td></tr><tr><td align="center">Brain</td><td align="center"><p>rs.vectranetworks.com</p><p>(74.201.86.229)</p></td><td align="center">TCP/443 or UDP/9970</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1045">Remote Support</a> access for remote troubleshooting. See note above regarding SSL inspection and other note about potential IP range conflicts with the MGT interface.</td></tr><tr><td align="center">Brain</td><td align="center"><p>metadata.vectra.ai</p><p>(100.20.236.31, 44.229.57.246, 44.228.37.60, 44.228.101.87)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Anonymized metadata sharing to contribute to future algorithm development.</td></tr><tr><td align="center">Brain</td><td align="center">Recall collector</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Recall IP addresses are provided during implementation and may be requested at any time from Vectra Support.</td></tr><tr><td align="center">Brain</td><td align="center">Syslog (as configured)</td><td align="center">TCP or UDP (as configured)</td><td align="center">CEF or standard Syslog format.</td></tr><tr><td align="center">Brain</td><td align="center">Kafka (as configured)</td><td align="center">TCP (as configured)</td><td align="center">CEF or standard Syslog format.</td></tr><tr><td align="center">Brain</td><td align="center"><p>Carbon Black Response</p><p>(as configured)</p></td><td align="center">TCP/443 (as configured)</td><td align="center">Carbon Black integration (requires API key).</td></tr><tr><td align="center">Brain</td><td align="center">api.crowdstrike.com</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Crowdstrike integration (Client ID and Client Secret).</td></tr><tr><td align="center">Brain</td><td align="center">vCenter (as configured)</td><td align="center">TCP (as configured)</td><td align="center">vCenter integration enables vSensor physical host view, augmented host identification, and vCenter alerts.</td></tr><tr><td align="center">Brain</td><td align="center">LDAP (as configured)</td><td align="center">TCP/389 STARTTLS/389</td><td align="center">LDAP authentication.</td></tr><tr><td align="center">Brain</td><td align="center">Radius (as configured)</td><td align="center">UDP/1812</td><td align="center">Radius (PAP) authentication.</td></tr><tr><td align="center">Brain</td><td align="center">TACACS (as configured)</td><td align="center">TCP/49</td><td align="center">TACACS (PAP or CHAP) authentication.</td></tr><tr><td align="center">Brain</td><td align="center">Backup server (as configured)</td><td align="center">TCP/22 (SSH)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1121">Automated backup (SCP or SFTP)</a>.</td></tr><tr><td align="center">Brain</td><td align="center">Brain</td><td align="center">TCP/22 (SSH), TCP/443 (HTTPS)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1121">Automated backup (brain-to-brain)</a>. Connectivity is bidirectional.</td></tr><tr><td align="center">Sensors, Stream</td><td align="center">update2.vectranetworks.com (54.200.156.238)</td><td align="center">TCP/443 (HTTPS)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1024">Required for automatic pairing</a>. Optional for manual (offline) pairing.</td></tr><tr><td align="center">SIEM/CLM log management</td><td align="center">Brain</td><td align="center">TCP or UDP (as configured)</td><td align="center">Log forwarding of DHCP/AD security events to augment host identification.</td></tr><tr><td align="center">Brain</td><td align="center"><p>login.windows.net</p><p>api.securitycenter.windows.com</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Required for <a href="https://support.vectra.ai/s/article/KB-VS-1236">ATP lockdown</a></td></tr><tr><td align="center">Brain</td><td align="center">EMEA customers (only)<br><br>authgateway.ew1.public.app.prod.vectra-svc.ai<br>(54.171.40.108 , 54.246.213.148 , 54.75.47.147 )<br><br>AMS/APJ customers (only)<br><br>authgateway.uw2.public.app.prod.vectra-svc.ai<br>(54.245.33.175, 52.42.70.176, 100.21.109.72 , 52.26.91.157)</td><td align="center">TCP/443<br>(HTTPS)</td><td align="center">Required for Vectra MDR Service for QUX Deployments. These endpoints are also required for RUX deployments that have network data sources (Sensors). These are already discussed in the <a href="#auth-gateways">Auth Gateways</a> section of this doc for RUX. Essentially, if your deployment has a Brain, it MUST be able to reach Vectra over these endpoints for Vectra MDR service.</td></tr><tr><td align="center">Sensor</td><td align="center">S3 and SQS AWS Regional Endpoints. Only required for ZIA enabled Sensor.</td><td align="center">TCP/443</td><td align="center">Required for ZIA SASE/SSE integration. See <a href="https://support.vectra.ai/s/article/KB-VS-1006">KB</a> for details.</td></tr></tbody></table>

### SMTP (OAuth) For Microsoft

**Quadrant UX Only**: *Configuration → RESPONSE → Notifications → SMTP*

Respond UX deployments do not require this as email notifications are sent from Vectra's cloud.

<table data-header-hidden data-full-width="true"><thead><tr><th width="282.41015625" align="center"></th><th width="223.69140625" align="center"></th><th width="145.71484375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Cloud Type</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td></tr><tr><td align="center">Public (office365<strong>.</strong>com)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>com<br>smtp<strong>.</strong>office365<strong>.</strong>com</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">US Government (office365<strong>.</strong>us)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>us<br>smtp<strong>.</strong>office365<strong>.</strong>us</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">German (office365<strong>.</strong>de)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>de<br>smtp<strong>.</strong>office365<strong>.</strong>de</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">China (office365<strong>.</strong>cn)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>cn<br>smtp<strong>.</strong>office365<strong>.</strong>cn</td><td align="center">TCP/443<br>TCP/587</td></tr></tbody></table>


# Deploying the AMI

Deploy the AWS Brain AMI using CloudFormation or AWS Marketplace.

## Deploying the AMI

* Please await confirmation from Vectra that your AWS account has been whitelisted if you are not deploying from the marketplace.
  * You will receive the latest AWS CloudFormation template (CFT) as part of that confirmation.
* Using the AWS CloudFormation service deploy the template.
  * Click the **Create stack** button and select the **With new resources (standard)** option.
  * You may use JSON or YAML format for the template.

![](/files/25ee31a142cf278bc4f05c483bdf748f79020247)

During this process you will be asked to fill in the following fields:

* **Stack name** - The Stack name can contain letters, numbers and dashes only and cannot conflict with any other existing stacks.
  * Fill out a Stack name.
* **amID** – this is the actual ID of the AMI that will be launched by the template.
  * This is built into the template and can be left as a default value of `AWS::NoValue`.
* **backupBrainToken** – This is used only if this is going be a backup Brain used for Brain to Brain backup.
* **baseName** - This should be a value related to the Stack name.
  * The base name will be prepended to all objects created with the template.
  * Enter a baseName like `CompanyXYZ-`.
* **instanceType** - Currently there are 4 options – r5d.2xlarge, r5d.4xlarge, r5d.8xlarge, and r5.16xlarge.
  * The r5d.2xlarge is rated for up to 15 sensors, 2 Gbps of network bandwidth and 50k IPs.
  * The r5d.4xlarge is rated for up to 25 sensors, 5 Gbps of network bandwidth and 50k IPs.
  * The r5d.8xlarge is rated for up to 100 sensors, 15 Gbps of network bandwidth and 150k IPs.
  * The r5.16xlarge is rather for up to 500 sensors, 50 Gbps of network bandwidth and 500k IPs.
* **mgtPrivateIP** - If you choose the default value of AWS::NoValue your Brain will get a DHCP IP address that will change each time the server is restarted.
  * It is recommended to use a static assignment.
* **mgtSecurityGroup** – The template will create an empty security group.
  * You may change it to a group you want to use now, or soon after deployment.
* **mgtSubnet**- This is the subnet that will be assigned to the Brain’s AWS ENI (Elastic Network Adaptor).
* **mgtVpc** - This is the Amazon VPC that contains the subnet from above.
  * Select the proper subnet on the pulldown.

{% hint style="warning" %}
Please make sure that the Amazon VPC you select contains the subnet from the mgtSubnet pulldown, otherwise the deployment will fail
{% endhint %}

* **provisioningToken** – This is required for deployments outside of the AWS Marketplace.
  * A provisioning token allows the Brain to register with Vectra for service integrity checks and subsequent updates.
  * This should have been provided to you by Vectra prior to attempting deployment.
* **publicIP** - If you would like to run your Brain in a public subnet with an EIP you can set that EIP here.
  * You can also choose to associate an Elastic IP after deployment.
* **sshKey** – You should have created an Amazon EC2 key pair that you would like to use for this AMI previously
  * Select your key pair
  * This private key will need to be used during SSH login to the CLI of the Brain as the `vectra` user
* **Tenancy** - Select default
* Then click **Next** – An example dialog is below:

![](/files/6fa22c70e8d7116494a1fa8ab6142dee3fc0bead)

![](/files/e3231ff6627a1e28e2f33af3be9280cdb078d0eb)

* All fields on the above page are optional.
  * You may wish to configure tags as an example.
* Click **Next**.
* Verify all settings and click **Create stack**.

![](/files/c635ceb2ee5e0732ca1316ebacc669c592e19d04)

* Once the security group stack creation is complete, you can edit the Amazon EC2 security group if it was not previously selected.
  * You can easily reach this Amazon EC2 security group from the **Resources** tab of the completed Stack.
  * If you have already closed this, you can go to the Amazon EC2 service, right click on the instance from the list, select Networking, and edit the Amazon EC2 security group to add the required rules.
* Once your point of management has reachability to the Brain IP, you can browse to its IP or hostname using HTTPS.

### Completing the Brain Deployment

Once you bypass a warning for the self-signed certificate that is created by default on the Brain, you will be presented with information relaying the status of the Brain’s progress as it continues through the deployment process. It will proceed through the following stages:

* Authenticating and verifying the file system of the virtual Brain appliance.
* Rebooting.
* Decryption of the file system.
* Connecting to the Vectra provisioning server and provisioning.

Example screenshots:

![](/files/Yc9qZKqKbtHh9936pPsm) ![](/files/AdA3zmZ3yPUmrLW1FoLr)

If a proxy is required to access Vectra in your AWS environment, this can be configured during this time by clicking on the **Set Proxy Configuration** link on any of these status screens.

{% hint style="info" %}
**Please Note:**

* This proxy configuration screen is only used to communicate with Vectra’s provisioning server and must utilize an HTTPS proxy. HTTP only proxies are not supported for this use.
* Other proxy configuration in the main Vectra UI after deployment accepts HTTP proxies and is used by non-provisioning related services and integrations.
  * *Configuration* → COVERAGE → Data Sources > Network > Brain Setup > Proxy & Status
    {% endhint %}

{% hint style="info" %}
**Please Note:**

If you are doing a Respond UX deployment and require a proxy for non-provisioning related services and integrations (this includes linking to Vectra’s cloud for use with the Respond UX), you should configure that proxy at the CLI of your Brain AFTER you progress through this initial configuration and get to the **Success!** message at the end of this section. Please see the [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) in the [*Deployment > Proxy Support*](/deployment/getting-started/respond-ux-deployment-guide/deployment#proxy-support) section for more detail.
{% endhint %}

Once complete, you will see the following:

![](/files/yN87JosoMar5DqCw1REA)

Clicking on the blue **Login** button will take you to the login page of the Brain (Quadrant UX). If you are doing a Respond UX deployment, you should **NOT** login to the local GUI (which is the Quadrant UX) before linking your Brain with Vectra. Once linked with Vectra per the [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide), your Brain will no longer show a Quadrant UX login screen when you browse to its IP or hostname and it will instead show a page the instructs you to login to the Respond UX in Vectra’s cloud or a status page.

{% hint style="warning" %}
**Please Note:**

The Brain may require several updates to become current with Vectra’s latest generally available version.

* Please do not power off the Brain during the initial AWS deployment prior to login or during the updating process as the Brain becomes current.
* If powered off during initial deployment the Brain may become unresponsive and require redeployment.
* During this time the UI may become unresponsive, or you may be disconnected but it is safe to configure platform settings.
* Periodically, the Brain image is updated and when deploying a new Brain, always check with Vectra for the latest base image available for your deployment.
  {% endhint %}

### 50 Gbps Brain Storage Throughput Modification

The 50Gbps brain uses a faster EBS drive (storage) than our other Brains for the root drive. All but one necessary setting will be set automatically by the deployment template. The other setting, **Throughput**, will need to be set manually in the AWS management console. This only needs to be done once per deployment. The instance will remember the settings once set.

Here is the value that needs to be set for the Brain:

* Drives: `/dev/sda1`
* Throughput: `300 Mb/s`

This value can be modified immediately after finishing the CloudFormation template deployment has completed and the Brain is building and provisioning with Vectra. This modification can be done at any time and as per the deployment guidance above, you should not power off the Brain during the initial deployment process. The modification does not require a reboot.

To modify the value, please perform the following steps:

* Open the instance summary page for your Brain instance and select the **Storage** tab:

![](/files/e6cec9fd23a8e4f4fd374c3cc73ba37f97c03730)

* Select the entry for the `/dev/sda1` device:

![](/files/5975626a93d41334c8dd5bc34f66d01728685784)

* After selecting the entry, click on the **Volume ID**:

![](/files/1b77ba7d22ffef9788dbfc0f583329b49c28e2c8)

* On the **Details** page for the volume, click **Modify** in the top right:

![](/files/cef254bcdf8bb5a908160e48fd646a071a85d6f6)

* Change the **Throughput** value to `300`.
  * No other values need validation or modification.
  * This can be done with the Brain running as per the earlier guidance.
    * If done while the instance is stopped, it will typically take around 5 minutes to complete.
    * If done while the Brain is running, it will typically take 10-30 minutes.
    * The AWS UI will give a status of **migrating (%)** until it is finished.
  * Before and during the migration process, the Brain’s ability to process traffic may be less than during normal operations. Essentially, until this process is completed the Brain will not be able to process the full 50 Gbps of aggregate traffic seen by its paired Sensors.

![](/files/6d8670b2809b6ceb8520cd028f56e1db786c451f)

### Default login credentials

The default credentials to login to the Vectra Brain GUI (Quadrant UX only) in AWS are:

* Username: `admin`
* Password: EC2 instance ID as copied from the Amazon EC2 console, beginning with `i-`

Logging in at the CLI can be done via SSH using the Amazon EC2 private key that was assigned to this stack and the `vectra` username.

Please ensure Amazon EC2 security groups are updated to allow CLI and GUI access as per earlier guidance.

### Configuring Initial Brain Settings

For more details around initial settings for the Brain after successfully deploying it in AWS, see the [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) or [Vectra Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment) that is available on the Vectra Support portal.


# Enabling AWS integrations

Enable AWS HostID and optional Security Hub and CloudWatch integrations.

## Vectra AWS Integrations

In addition to all the standard integrations available in the hardware appliance version of the Vectra Brain, the AWS Brain allows native integrations with various AWS services with the goal of either gathering context or publishing alerts. Vectra AWS integrations require adding AWS IAM users, roles, and policies.

Security Hub publishing (Quadrant UX deployments only) will only publish Host scores involving AWS workloads. CloudWatch health and audit logs (Quadrant UX deployments only) are typically only desired in AWS for customers whose Brain is deployed in AWS.

Vectra has 3 AWS integrations:

* **HostID**
  * This is the most common AWS integration and configuring it is considered a best practice.
  * Instructions are provide below.
  * Adding relevant context (Host ID, OS, instance ID, tags, etc) about Amazon EC2 hosts when observed by Vectra.
  * While technically optional, it is a best practice is to enable this integration when you have Hosts deployed in AWS that are monitored by Vectra. Detections in Vectra are tied to a Host or Account entity. To be more easily actionable and for some algorithms to support learning, Detections must be attributable to a Host (including statically defined hosts), rather than a generic Host IP address or other similar network artifact – especially as many of these network artifacts are transient in the cloud. To this end, the Vectra Brain can directly query the describe instance APIs in AWS to extract the instance identifier, tags, Amazon VPC and other metadata for Amazon EC2 VMs.
  * The AWS account used for this integration may be set up as a standalone account or as a federated organization with a parent account and multiple child accounts.
* **AWS Security Hub** (Quadrant UX deployments only)
  * Please see [AWS Security Hub integration](/deployment/ndr-virtual-cloud-appliances/aws-security-hub-integration-qux-only) for configuration details.
    * Please note that it is required to configure AWS HostID integration before configuring Security Hub integration.
  * The Vectra Brain can natively publish Host scores involving AWS workloads in AWS Security Findings Format (ASFF) to the AWS Security Hub service. This is optional.
* **CloudWatch** (Quadrant UX deployments only)
  * Instructions are provided below.
  * Publishing health and audit logs to Amazon CoudWatch. This is optional.

## AWS HostID Integration

### AWS Host ID Integration Introduction

* The Host ID integration for AWS VPCs enables adding relevant context (Host ID, OS, instance ID, tags, etc) about Amazon EC2 hosts when observed by Vectra.
* Detections in Vectra are tied to a Host or Account entity.
  * To be more easily actionable and for some algorithms to support learning, Vectra detections must be attributable to a Host (including statically defined hosts), rather than a generic Host IP address or other similar network artifact – especially as many of these network artifacts are transient in the cloud.
  * To this end, the Vectra Brain can directly query the describe instance APIs in AWS to extract the instance identifier, tags, Amazon VPC and other metadata for Amazon EC2 VMs.
* While technically optional, it is a best practice is to enable this integration when you have Hosts deployed in AWS that are monitored by Vectra.
  * This may be because you have vSensors deployed in AWS, or if you have connectivity to AWS that allows any of your other Vectra Sensors to observe communications with hosts deployed in AWS.
* The integration will provide additional artifacts that help with Host ID's automated naming of hosts in your environment.
  * For more details on Host ID, please see [Understanding Vectra Detect Host Naming](/reference/understanding-vectra-host-naming).
* The AWS account used for this integration may be set up as a standalone account or as a federated organization with a parent account and multiple child accounts.

### Supporting Materials

Vectra makes CloudFormation templates available to enable easy creation of the users, roles and policies required.

**HostIdTemplate.yml**- Used for integration with the AWS Resource Manager to collect artifacts that provide details to Vectra's automated Host ID capability.

{% file src="/files/F4xUtybGpCH3nWLhGBOA" %}

**HostIdFederatedParentTemplate.yml** - Used for Host ID in Federated AWS setups

{% file src="/files/Zmxi8lnqqMbkTyK8Tmls" %}

**HostIdFederatedChildTemplate.yml** - Used for Host ID in Federated AWS setups

{% file src="/files/Y7HPxmMOXnTw5geMpzbE" %}

The files can also be downloaded from your Brain after deployment from the following locations:

* https\://\<brain\_hostname\_or\_IP>/resources/HostIdTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/HostIdFederatedParentTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/HostIdFederatedChildTemplate.yaml/serve\_file

### Firewall Requirements

For **AWS** **Host ID integration only**, the Vectra Brain needs **outbound HTTPS/TCP 443** to these AWS API endpoints:

| Purpose                                   | AWS endpoints to allow       |
| ----------------------------------------- | ---------------------------- |
| Caller identity / account validation      | `sts.<region>.amazonaws.com` |
| IAM account alias + permission simulation | `iam.amazonaws.com`          |
| EC2 inventory / VPC discovery             | `ec2.<region>.amazonaws.com` |

**Summary:**

Allow outbound TCP/443 from Vectra Brain to AWS STS, IAM, and EC2 API endpoints for the AWS regions being monitored.

The Host ID templates reference these AWS actions: `sts:GetCallerIdentity`, `iam:ListAccountAliases`, `iam:SimulatePrincipalPolicy`, and EC2 `Describe*` calls for instances, regions, subnets, VPCs, VPC peering, and traffic mirror resources.

### Configuration

The AWS account may be set up as a standalone account or as a federated organization with a parent account and multiple child accounts.

#### Standalone Accounts

If the deployment involves just a single AWS account, use CloudFormation to create the `VectraCognitoHostIDv1` IAM user using the `HostIdTemplate.yml`. The template is also shown in an expandable code block below. Users can also be created manually if desired using the template as guide for the permissions required.

{% code expandable="true" %}

```
AWSTemplateFormatVersion: '2010-09-09'
Description: Vectra HostID User version 1
Resources:
  user:
    Properties:
      Policies:
        - PolicyDocument:
            Statement:
              - Action:
                  - iam:ListAccountAliases
                  - iam:SimulatePrincipalPolicy
                  - ec2:DescribeInstances
                  - ec2:DescribeRegions
                  - ec2:DescribeSubnets
                  - ec2:DescribeTrafficMirrorTargets
                  - ec2:DescribeTrafficMirrorSessions
                  - ec2:DescribeVpcPeeringConnections
                  - ec2:DescribeVpcs
                  - sts:GetCallerIdentity
                Effect: Allow
                Resource:
                  - '*'
            Version: '2012-10-17'
          PolicyName: vectra_hostid_permissions
      UserName: VectraCognitoHostIDv1
    Type: AWS::IAM::User
```

{% endcode %}

You may add as many credential sets as required if you have multiple AWS accounts that you wish to treat as standalone accounts. Once you have created the IAM user you must create a new Access key in AWS for the user. AWS has some documentation available [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html).

* Navigate to the user `VectraCognitoHostIDv1` in the Identity and Access Management service.
* Click on the **Security credentials** tab and the **Create Access key** button.
  * This will generate a credential pair similar to the below screenshot.
  * Please take note of these credentials for later use in the Vectra UI.

<img src="/files/21WvgCZjAJ8sLMZ2EXEe" alt="" width="563">

* In the Vectra UI, navigate to *Configuration > SETUP > External Connectors > AWS* and click **Edit**.
* Turn **On** the **Enable integration with AWS**.
* Click **Add Credential** and fill out the form using the values you just noted and the appropriate Cloud Type.
  * The **Alias** can be any identifier you wish to use for this set of credentials in Vectra’s UI.
  * Enter access key ID and secret access key corresponding to the `VectraCognitoHostIDv1` IAM user.

<img src="/files/PyKK3rPZvEdV80ocSKIv" alt="" width="563">

* Click **Add**.

<figure><img src="/files/NPtr8D0M7awubf1yXnMC" alt=""><figcaption></figcaption></figure>

* Click **Save** on the **Enable integration with AWS Resource Manager** configuration area.
* Look for the green check mark and a status of **Connected**.

#### Federated AWS Organizations with Parent and Child Accounts

For these types of organizations, Vectra supports role assumption at the child account level using an IAM user that is created at the parent account level.

* Use CloudFormation to create the `VectraCognitoHostIDFederated` IAM user in the parent account using the `HostIdFederatedParentTemplate.yml` file.
  * The user can also be created manually if desired using the template as guide for the permissions required.
  * The template is also shown in an expandable code block below.

{% code expandable="true" %}

```
AWSTemplateFormatVersion: '2010-09-09'
Description: Vectra HostID Federated User version 1
Outputs:
  ChildAccountRole:
    Description: The role name that will be assumed in all child AWS accounts
    Value: !Ref 'ChildAccountRole'
  ParentAccountUser:
    Description: The user name in the parent AWS account
    Value: !Ref 'ParentAccountUser'
Parameters:
  ChildAccountRole:
    Default: VectraCognitoHostID
    Description: The role name that will be assumed in all child AWS accounts
    MaxLength: '64'
    MinLength: '6'
    Type: String
  ParentAccountUser:
    Default: VectraCognitoHostIDFederated
    Description: The user name in the parent AWS account
    MaxLength: '64'
    MinLength: '6'
    Type: String
Resources:
  user:
    Properties:
      Policies:
        - PolicyDocument:
            Statement:
              - Action:
                  - sts:AssumeRole
                Effect: Allow
                Resource:
                  - !Join
                    - ''
                    - - arn:aws:iam::*:role/
                      - !Ref 'ChildAccountRole'
            Version: '2012-10-17'
          PolicyName: VectraCognitoHostID
      UserName: !Ref 'ParentAccountUser'
    Type: AWS::IAM::User
```

{% endcode %}

* Navigate to the user `VectraCognitoHostIDFederated` in the Identity and Access Management service.
* Click on the **Security credentials** tab and the **Create Access key** button.
  * This will generate a credential pair similar to the below screenshot.
  * Please take note of these credentials for later use in the Vectra UI.

<img src="/files/21WvgCZjAJ8sLMZ2EXEe" alt="" width="563">

* Use CloudFormation to create the `VectraCognitoHostID` role in each child account where Vectra vSensors will be deployed.
  * Use the `HostIdFederatedChildTemplate.yml` attached at the bottom of this page.
  * The user can also be created manually if desired using the template as guide for the permissions required.
  * The template is also shown in an expandable code block below.

{% code expandable="true" %}

```
AWSTemplateFormatVersion: '2010-09-09'
Description: Vectra HostID Federated Assume Role version 1
Outputs:
  ChildAccountRole:
    Description: The role name that will be assumed in all child AWS accounts
    Value: !Ref 'ChildAccountRole'
  ParentAccount:
    Description: The AWS account ID of the parent account
    Value: !Ref 'ParentAccount'
  ParentAccountUser:
    Description: The user name in the parent AWS account
    Value: !Ref 'ParentAccountUser'
Parameters:
  ChildAccountRole:
    Default: VectraCognitoHostID
    Description: The role name that will be assumed in all child AWS accounts
    MaxLength: '64'
    MinLength: '6'
    Type: String
  ParentAccount:
    AllowedPattern: '[0-9]{12}'
    Description: The AWS account ID of the parent account
    Type: String
  ParentAccountUser:
    Default: VectraCognitoHostIDFederated
    Description: The user name in the parent AWS account
    MaxLength: '64'
    MinLength: '6'
    Type: String
Resources:
  role:
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Action:
              - sts:AssumeRole
            Effect: Allow
            Principal:
              AWS:
                - !Join
                  - ''
                  - - 'arn:aws:iam::'
                    - !Ref 'ParentAccount'
                    - :user/
                    - !Ref 'ParentAccountUser'
      MaxSessionDuration: 7200
      Path: /
      Policies:
        - PolicyDocument:
            Statement:
              - Action:
                  - iam:ListAccountAliases
                  - iam:SimulatePrincipalPolicy
                  - ec2:DescribeInstances
                  - ec2:DescribeRegions
                  - ec2:DescribeSubnets
                  - ec2:DescribeTrafficMirrorTargets
                  - ec2:DescribeTrafficMirrorSessions
                  - ec2:DescribeVpcPeeringConnections
                  - ec2:DescribeVpcs
                  - sts:GetCallerIdentity
                Effect: Allow
                Resource:
                  - '*'
            Version: '2012-10-17'
          PolicyName: VectraCognitoHostIDPolicy
      RoleName: !Ref 'ChildAccountRole'
    Type: AWS::IAM::Role
```

{% endcode %}

* In the Vectra UI, navigate to *Configuration > Setup > External Connectors > AWS* and click **Edit**.
* Turn **On** the **Enable integration with AWS setting.**
* Click Add Credential and fill out the form using the values you just noted and the appropriate Cloud Type.
  * Enter the access key ID and secret access key corresponding to the `VectraCognitoHostIDFederated` user you created earlier in the parent account.
  * The **Alias** can be any identifier you wish to use for this set of credentials in Vectra’s UI.

<img src="/files/Ev55HwJfcVSHOBuS5Ltf" alt="" width="563">

* Click the **Multi-Account Credential** checkbox to enable multi-account credential entry.
* **Role to Assume** should default to **VectraCognitoHostID** and can be left as is unless any of the templates have been modified.
* List all the **AWS Account Numbers** (account IDs) to be covered.
  * You can hit enter after each account or paste in multiple account numbers separated by a comma.
* You may test access using the **Test Account** link.
* Click **Add**.
* **Save** your connector configuration
* Look for the green check mark and a status of **Connected**.

<figure><img src="/files/vpAuPMRYWleht578OH1v" alt=""><figcaption></figcaption></figure>

### Viewing and Modifying Virtual Networks Considered by the Connector

The connector will only look at virtual machines that belong to some VPCs, not necessarily all VPCs that the credentials have access to. Specifically, by default, the connector will only look for virtual machines with network interfaces in the VPCs where a Vectra AWS Sensor traffic interface is deployed into, and all the VPCs peered to it. If a virtual machine has multiple network interfaces, the connector will provide host identification only for the IP addresses belonging to interfaces on monitored VPCs.

Vectra limits the scope of the connector to only virtual networks that can reach an AWS Sensor for the following reasons:

* Vectra wants to avoid an excessive number of connections to the AWS resource manager.
* To improve performance, Vectra wants to avoid storing unnecessary information in the platform for resources that we are not monitoring.
* In the cloud it is possible that you may have some isolated virtual networks that are not monitored by Vectra Sensors but have overlapping IP space with some other networks that are monitored. Duplicate IPs are not supported by Vectra. To avoid Host ID issues, we only consider virtual machines on the networks that appear reachable by our Sensors.

If you want to add or remove some virtual networks from the set of virtual networks that Vectra monitors, you can do so through the CLI (ssh to the Brain as the `vectra` user). This functionality is not available in the Vectra UI. The use case for adding or removing virtual networks could be any of the following:

* If you have some tunneling or forwarding enabled and Vectra AWS Sensors see traffic from VPCs that are NOT directly connected to our Sensor:
  * You will want to add the networks to the monitored networks list to extend Host ID coverage to the tunneled/forwarded traffic’s associated Hosts.
* If you do NOT have any AWS Sensors deployed, but mirror AWS traffic into your data center where you have Vectra physical or virtual Sensor coverage:
  * You will want to add the networks to the monitored networks list to extend Host ID coverage to the mirrored traffic.
* If you do have some overlapping IP space on a network that appears reachable by our Sensor, but it is not monitored by our Sensor:
  * You will want to remove the overlapping networks from the monitored networks to avoid any Host ID issues.
* If you have a lot of peered VPCs but only some are monitored by the Sensor:
  * You will want to remove the non-monitored networks from the monitored networks list to increase performance and reduce load on the AWS resource manager.

The command to include or exclude specific virtual networks from the Vectra CLI is `set aws hostid config`. Without turning on the `aws hostid config` at the CLI, the connector will operate in a default manner. Think of this command as customization beyond the default behavior described above, not a full replacement for it. You must turn on the `aws hostid config` at the CLI to enable any include/exclude customizations that you configure.

The command has a help message illustrating its use:

```language-markup
vscli > set aws hostid config --help
Usage: set aws hostid config [ --clear-exclude ] [ --clear-include ] [ --on-off ( on | off ) ] [ -i include ] [ -e exclude ]

Options:
  --clear-exclude     set if you want to wipe the list of vpcs to exclude
  --clear-include     set if you want to wipe the list of vpcs to include
  --on-off [on|off]
  -i, --include TEXT  comma separated list of vpc id's to add to the include
                      list
  -e, --exclude TEXT  comma separated list of vpc id's to add to the exclude
                      list
  -h, --help          Show this message and exit.
```

The command `show aws hostid config` will show if customization is enabled for the default Host ID configuration, and any included or excluded VPCs that you want to be considered or not considered by the connector.

Example of usage:

```language-markup
vscli > set aws hostid config -i vpc-0830d0eef7c5d27fc
vscli > set aws hostid config --on-off on
successfully set aws hostid configuration

vscli > show aws hostid config
enabled: True
exclude:
include:
    vpc-0abc356d,
    vpc-0830d0eef7c5d27fc
```

## CloudWatch Integration

The Vectra Brain can publish system health and audit logs to the CloudWatch service (Quadrant UX deployment only). This is optional.

### Supporting Materials

**CloudwatchLogsTemplate** - (QUX deployments only) - Used for integration with AWS CloudWatch

{% file src="/files/y8r7PU0vCM3vAXVYcYun" %}

This file can also be downloaded from your Brain after deployment from the following location:

* https\://\<brain\_hostname\_or\_IP>/resources/CloudwatchLogsTemplate.yaml/serve\_file

## Firewall Requirements

For **AWS CloudWatch Logs integration only**, the Vectra Brain needs **outbound HTTPS/TCP 443** to these AWS API endpoints:

| Purpose                                 | AWS endpoints to allow        |
| --------------------------------------- | ----------------------------- |
| Caller identity / account validation    | `sts.<region>.amazonaws.com`  |
| IAM permission simulation               | `iam.amazonaws.com`           |
| CloudWatch Logs collection / management | `logs.<region>.amazonaws.com` |

**Summary:**

Allow outbound TCP/443 from Vectra Brain to AWS STS, IAM, and CloudWatch Logs API endpoints for the AWS regions being monitored.

The CloudWatch Logs template references these AWS actions: `sts:GetCallerIdentity`, `iam:SimulatePrincipalPolicy`, and CloudWatch Logs actions for creating, describing, filtering, and managing log groups, log streams, and log events.

### Configuration

To configure this integration:

* Use CloudFormation to create the `VectraCognitoCloudwatchLogsv1` IAM user using the `CloudwatchLogsTemplate.yml` .
* The template is also shown in an expandable code block below.

{% code expandable="true" %}

```
AWSTemplateFormatVersion: '2010-09-09'
Description: Vectra Cloudwatch Logs User version 1.2
Resources:
  user:
    Properties:
      Policies:
        - PolicyDocument:
            Statement:
              - Action:
                  - logs:CreateLogStream
                  - logs:DeleteLogStream
                  - logs:DescribeLogStreams
                  - logs:GetLogEvents
                  - logs:PutLogEvents
                  - logs:DeleteLogGroup
                  - logs:GetLogEvents
                  - logs:PutRetentionPolicy
                Effect: Allow
                Resource:
                  - !Join
                    - ''
                    - - 'arn:'
                      - !Ref 'AWS::Partition'
                      - :logs:*:*:log-group:/vectra/cognito/*
                Sid: CreateDeleteAndRetrieveVectraCloudwatchGroupLogEvents
              - Action:
                  - iam:SimulatePrincipalPolicy
                  - logs:DeleteLogGroup
                  - logs:CreateLogGroup
                  - sts:GetCallerIdentity
                Effect: Allow
                Resource:
                  - '*'
                Sid: CreateVectraLogs
            Version: '2012-10-17'
          PolicyName: vectra_cloudwatch_log_permissions
      UserName: VectraCognitoCloudwatchLogsv1
    Type: AWS::IAM::User
```

{% endcode %}

* Browse to the Identity and Access Management service.
* Navigate to the user `VectraCognitoCloudwatchLogsv1` in the Identity and Access Management service.
* Click on the **Security credentials** tab and the **Create Access key** button.
  * This will generate a credential pair similar to the below (make note of these for use in the Vectra UI):

![](/files/21WvgCZjAJ8sLMZ2EXEe)

* Navigate on the Vectra UI to *Configuration → RESPONSE > Notifications > AWS CloudWatch.*
* Click **Edit**.

![](/files/5c2e946d39e7d5d7c3dc7bcc1ac4b0c9ad8fbfa3)

* Enter the credentials and the fields related to the AWS account, including Amazon CloudWatch fields like Group Name and Stream name, and the format.
* Select the log types you wish to forward from Vectra.
* Click **Save**.


# Pairing Sensors or Stream

Pair Sensors or Stream to an AWS Brain after provisioning.

## AWS Sensor or Stream Pairing

The same content available on this documentation site under *Deployment → Appliance Operations →* [*Pairing appliances*](/deployment/appliance-operations/pairing-appliances) is shown below.

An AWS Brain can pair with any type of Sensor or Stream appliance. They can be physical, or virtual in cloud or traditional hypervisor environments.

Please note that AWS vSensors and Stream appliances do NOT support online pairing and that content below that is specific to physical Sensors or traditional hypervisor based vSensors does not apply to AWS vSensors or Stream.

## About Sensor and Stream Pairing

Sensors and Stream appliances behave the same way from a pairing perspective. Because of this, you may see the **Sensor** term used in this document, your Vectra UI, or at the CLI of a Vectra appliance when sometimes the appliance in question is a Stream appliance.

Multiple Sensors can be attached to a single Brain while the Brain supports a single Stream appliance at a time. The exact limits for how many appliances can be paired to your Brain will depend on the Brain model or configuration. Please see [appliance specifications](/deployment/getting-started/appliance-specifications) for details.

{% hint style="info" %}
**Please Note:**

* From this point forward, the term "Sensor" will be used to represent both Sensor or Stream appliance types in this document.
  {% endhint %}

## Pairing Overview

Pairing is the process that allows Sensors to communicate with the Brain. All network sessions between an appliance and the Brain are initiated from the Sensor side.

There are three basic ways to pair a Sensor or Stream appliance with a Brain:

{% tabs %}
{% tab title="Using a Sensor Registration Token" %}
Using a Sensor Registration Token (SRT) works for any appliance type and is required for Sensors deployed in IaaS cloud environments such as AWS, Azure, and GCP.

* A Sensor Registration Token (SRT) is generated on the Brain and then configured on the Sensor or Stream appliance.
* Once the Sensor is configured with a Brain IP address or hostname, it will annouce itself to the Brain if powered on.
* The Brain will recognize the validity of the token and allow the Sensor to become available for pairing.
* A user will initiate pairing or use auto pairing (2nd tab above) if enabled.
  {% endtab %}

{% tab title="Auto Pairing" %}
Auto pairing is an option that can be enabled by administrators that allows some Sensor configurations to automatically pair with your Brain. If either of the two below states is true, and the Sensor can reach the Brain, pairing will be completed automatically when auto pairing is enabled.

* You have a vSensor for traditional hypervisor deployment (VMware, Hyper-V, Nutanix, KVM, etc) that was downloaded from your Brain, and is preconfigured with the location of the Brain and the registration information required for pairing.
* Appliances (physical and virtual) that are configured with a Sensor Registration Token can also auto pair with a Brain.
  {% endtab %}

{% tab title="Online Pairing (Physical Sensors Only)" %}
Online pairing is only supported for Vectra physical appliances that can reach the Vectra updater service and the Brain. If the Brain is behind NAT and not reachable via its configured IP, see [online pairing](#online-pairing-physical-sensors-only-1) for more details (the `set brain` command at the Sensor CLI will need to be used).

* Appliances are provisioned by Vectra and then shipped to a customer.
  * They are also associated to the customer account.
  * The Brain retrieves the list of provisioned Sensors from Vectra periodically.
* Sensors will retrieve the location of your Brain from Vectra when they come online.
* In the Brain UI, provisioned Sensors will show as **Available** for pairing.
* When pairing is attempted by the user, the Brain and Sensor will retrieve the required registration information from Vectra and complete the pairing process.
  {% endtab %}
  {% endtabs %}

Pairing is also supported in air-gapped environments and physical appliances can also be paired "offline" when required. For details please see [Pairing in an Air-Gapped Environment vs Pairing Offline](#pairing-in-an-air-gapped-environment-vs-pairing-offline).

### Pairing by Hostname vs IP Address

Sensors need to know the location of the Brain appliance so that they know what hostname or IP address to communicate with. Pairing by hostname is generally preferred over pairing by IP address for the following reasons:

* Failover scenarios are easier to manage because a replacement Brain can be setup with the same hostname as the original Brain even if the IP address will be different. Paired Sensors will be able to automatically re-pair with the new Brain once the DNS is changed (if the old Brain is offline, see [pairing to new or changed Brains](#pairing-to-new-or-changed-brains) for more details). This is because the backup contains Sensor state information.
* If your Brain appliance is configured with a DHCP address for its management port instead of a static IP address and you have paired by hostname, even if the IP address of the Brain changes, Sensors will still be able to communicate with the Brain they are paired to.

## Sensor Pairing and Registration Settings

The ***Configuration*****&#x20;→&#x20;*****COVERAGE*****&#x20;→&#x20;*****Data Sources → Network → Sensors*** area of your Vectra UI allows you to pair and manage network Sensors, configure a number of options related to Sensor pairing and registration, and change the CLI `vectra` user password for paired devices (Sensors and Stream). For more details, please see the [Respond UX deployment](/deployment/getting-started/respond-ux-deployment-guide) or [Quadrant UX deployment ](/deployment/getting-started/quadrant-ux-deployment)guides.

Navigate in this area to ***Sensor Configuration > Sensor Pairing and Registration.***

Editing this area will allow you to alter the default way a Sensor will attempt to pair with a Vectra Brain and allow you to enable or disable Virtual Sensor Automatic Pairing (Auto Pairing). Additionally, this area provides a link to generate a new Sensor Registration Token (SRT) or to copy an existing SRT.

### Pair using the Detect Brain

<figure><img src="/files/QUwDKDJ7oBhkn3gaAtu7" alt="" width="563"><figcaption></figcaption></figure>

* If you have a DNS name configured in *Configuration → COVERAGE → Data Sources → Network → Brain Setup → Brain*, then the **Pair using the Detect brain** area will provide a choice between the configured DNS name and the management IP address (MGT1).
* If you do not have a DNS name configured, there will only be one option present using the configured IP for the management interface of your Brain.
  * It may take a few minutes after adding a DNS name in your Brain setup for the choice to appear in this area.
* This setting only affects the default pairing mode for Sensors used in future pairing operations.
  * Any previously paired devices will remain paired in the same manner they were originally paired.
  * Regardless of setting, the `set brain` command available at the CLI of the Sensor will allow you to attempt pairing via hostname or IP.
* Should you choose to change the pairing method for previously paired devices, you will need to unpair the previously paired devices and re-pair them.

### Virtual Sensor Automatic Pairing "Auto Pairing"

* This setting allows you to choose if you want to automatically pair (auto pairing) with Sensors that have a valid Sensor Registration Token (SRT) configured.
  * Even though the setting name implies that this will only impact virtual Sensors, any Sensor, including physical appliances can auto pair if a valid SRT is configured when pairing is attempted.
* It is recommended to allow auto pairing during initial setup or during large Sensor rollouts.
* When you are done deploying vSensors, you may turn this off to enhance security posture.

### Sensor Registration Token (SRT)

<figure><img src="/files/2N4eoIUR3ZgQgx9JZj4T" alt="" width="563"><figcaption></figcaption></figure>

* Use this area to see the status of SRTs (how long before an SRT expires), copy a SRT, and to generate new SRTs.
* SRTs are used to validate Sensors attempting to register to a Brain and reset after 24 hours.
* SRTs are used in the **Registration Token** field in the Sensor deployment template for Sensors deployed in IaaS clouds such as AWS, Azure, and GCP.
* While the SRT is required for cloud Sensor deployment, it is optional for physical Sensors and virtual Sensors.
* Use of a SRT will allow you to pair a Sensor with any Brain in your organization. This can be useful for disaster recovery scenarios where a device may have been paired to another Brain previously.

**SRT Retrieval and Generation at the CLI**

SRT retrieval and generation can also be accomplished at the CLI of your Brain. For details on how to access the CLI of your Brain, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for CLI SRT retrieval and generation example.</summary>

Use the `show registration-token` command as shown below:

```
vscli > show registration-token --help
Usage: show registration-token [ -g ]

  Get registration token.

Options:
  -g, --generate  Generate new token
  -h, --help      Show this message and exit.

vscli > show registration-token
Output:
    Error: registration token not found

vscli > show registration-token -g
Output:
    Expiration: 2026-01-30T18:49:35.518524+00:00,
    Token: nvxfrxzknbchrbztyvlchkbnhwlxhdvz
```

</details>

## Configuring the Brain Location and SRT on a Sensor

Sensors can have the Brain location (Hostname or IP Address) used for pairing configured automatically or manually. Additionally, the Sensor Registration Token (SRT) can be set to allow a Sensor to pair with any Brain type as long as the SRT is valid.

### Automatic Configuration Scenarios

**vSensors for traditional hypervisors**

* These are used in platforms such as VMware, Nutanix, KVM, Hyper-V, etc.
* When a vSensor image is downloaded from your Brain, it is preconfigured with the location of the Brain it was downloaded from.
* The location encoded into the image is based on the hostname or IP address that was selected in the [Sensor Pairing and Registration](#sensor-pairing-and-registration-settings) settings area above.
* The SRT is not required as registration information is encoded into the vSensor image that was downloaded.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**Physical Sensors**

* An online Vectra Brain will update the Vectra cloud with its location.
* The location is based on if you have selected to pair via the management IP or hostname in the [Sensor Pairing and Registration](#sensor-pairing-and-registration-settings) settings area above.
* When an online Sensor connects to the Vectra cloud, the location will be provided to the Sensor so that it can announce itself as available for pairing to the Brain.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

### Manual Configuration Scenarios

**vSensors for IaaS clouds such as AWS, Azure, and GCP**

* Since all cloud vSensors are either deployed from the cloud provider marketplace or via a generic image shared directly to you prior to deployment, all cloud vSensor images are identical and are not preconfigured with registration information or a Brain location.
* The Brain location and Sensor Registration Token are configured as part of the deployment process for each cloud vSensor. This is typically done through a customizing a template in the cloud provider or a editing a template prior to deployment using a CLI command.
  * For more details, please see [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances) for the deployment guide for you vSensor.
* Post deployment
  * If you are able to reach the command line of the vSensor and log in, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**vSensors for traditional hypervisors**

* These are used in platforms such as VMware, Nutanix, KVM, Hyper-V, etc.
* As discussed in the [automatic configuration scenarios](#automatic-configuration-scenarios) above, these vSensor images are preconfigured with registration information and Brain location unique to the Brain that the image was downloaded from, and cannot normally be paired to other Brains in your environment unless a new Brain location and SRT are configured.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**Physical Sensors**

* As discussed in the [automatic configuration scenarios](#automatic-configuration-scenarios) and [pairing overview](#pairing-overview) above, online physical Sensors can retrieve location and registration information from the Vectra cloud.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

### Manual Configuration Steps

To manually configure a Sensor with a Brain location or Sensor Registration Token (SRT) you must first access the command line interface (CLI) of the Sensor. For details on how to access the CLI of your vSensor, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for manual configuration details.</summary>

#### Showing and Setting Brain Location

Use the `show brain` and `set brain` commands as shown below:

```
vscli > show brain
Brain IP: 172.16.12.10

vscli > set brain --help
Usage: set brain < ip_or_hostname >

  Set brain to the specified IP or hostname

Options:
  -h, --help  Show this message and exit.

vscli > set brain 172.16.12.12
Brain IP: 172.16.12.12
Set Brain IP: success
```

#### Showing and Setting the SRT

Use the show registration-token and set registration-token commands as shown below:

```
vscli > show registration-token --help
Usage: show registration-token

  Show current registration token

Options:
  -h, --help  Show this message and exit.

vscli > show registration-token
Output:
    Token: dtkwwbctkzfmppjblchgthkgjcvhcxnv

vscli > set registration-token --help
Usage: set registration-token < token >

  Set current registration token

Options:
  -h, --help  Show this message and exit.

vscli > set registration-token nvxfrxzknbchrbztyvlchkbnhwlxhdvz
Unpair: successful
Registration token has been set
```

</details>

## Pairing Sensors

### Communications Requirements

In order to pair with a Brain, per the [firewall requirements](/deployment/getting-started/firewall-requirements), Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

### Pairing Timing Expectations

Some processes related to pairing happen on regular intervals and are not immediate. It is normal for a Sensor to take a few minutes to show up in the Vectra UI as **Available** and move through different pairing states. For example, check in to the Vectra cloud happens every 5 minutes for a physical Sensor that has not yet communicated with the Vectra cloud. Other processes related to pairing can also take some time.

If a Sensor does not appear in the Brain *Configuration → Data Sources → Network → Sensors* page, check that the vSensor has IP connectivity and that TCP port 443 (HTTPS) is permitted through your firewall.

If pairing has begun, i.e. you see **Pairing** in the UI or CLI, and pairing has not completed in 5 to 10 minutes, the most likely scenario is that firewall rules are not allowing TCP/22 (SSH) from the Sensor to the Brain. In such a scenario, you should click the cancel pairing button in the UI, which will reset the Sensor status to **Available**, address connectivity issues, and reinitiate the pairing process.

For more near real-time status than what is shown in the UI served from Vectra's cloud in RUX deployments, or the UI served locally from your Brain in QUX deployments, the `show sensors` command can be used at the CLI of the Brain.

### Sensor Pairing States and Status

Admins can see the list of Sensors in the Vectra UI under *Configuration* → *Data Sources → Network → Sensors.* The Brain will attempt to query the Vectra cloud at <https://update2.vectranetworks.com> as the page loads.

**Sensor Pairing States**

* Available
  * Physical Sensor has contacted the Vectra cloud and Brain successfully and is available for pairing.
  * Physical Sensor with valid SRT has announced itself successfully to the Brain and is available for Pairing.
  * vSensor (cloud or traditional hypervisor deployed) has announced itself successfully to the Brain and is available for pairing.
* Pairing
  * A pairing request has been sent to the Vectra cloud from the Brain for online physical Sensors.
  * Any other Sensor type with a valid SRT is in the process of pairing.
* Paired
  * A Sensor has successfully paired with the Brain.
* Unpairing
  * A Sensor is in the process of unpairing.

**Sensor Status**

* Connected
* Not Connected
* Unpairing

<figure><img src="/files/2jZubc39RMt1py9uWFj9" alt=""><figcaption></figcaption></figure>

Pairing states and the list of Sensors can also been at the CLI of your Brain appliance. For details on how to access the CLI of your Brain, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for example using the <code>show sensors</code> CLI command.</summary>

```
vscli > show sensors -h
Usage: show sensors [ filter ]

  Show associated sensors

  FILTER is an optional query string to limit the results displayed. By
  default, all columns are searched but the query can be limited by using the
  format <column name>:<query>

Options:
  -h, --help  Show this message and exit.
v
scli > show sensors
Name                             |Ip            |Pairing  |Location              |Version    |Last Seen          |Luid    |Serial Number
V2b2db52176334e968c27a5d2a33720c0 192.168.54.201 available None                   9.0.0-18-57 2025-10-22 12:50:05 53a71kvk V2b2db52176334e968c27a5d2a33720c0
TB - Traffic Mirroring            192.168.55.239 paired    TB-Traffic Mirror Test 9.4.3-1-32  2026-01-29 19:37:09 qx70f0wr V11dd189d440e4e93b6bd6b5f5d1d484b
```

</details>

### Sensor Registration Token Pairing

<figure><img src="/files/mvpnCMNae5dh5GXjfTp2" alt=""><figcaption></figcaption></figure>

When a Sensor is configured with a valid [Sensor Registration Token (SRT)](#sensor-registration-token-srt), once a Sensor of any type is able to reach the Brain (see [communications requirements](#communications-requirements)), and shows as **Available,** click the pairing button as shown in the above screenshot to open a pairing dialog box.

<figure><img src="/files/Waq8H2P6yfgI2d7U6Tvy" alt="" width="375"><figcaption></figcaption></figure>

Click **Pair Sensor** to begin pairing. The Sensor will move through **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

### Auto Pairing

If [auto pairing](#virtual-sensor-automatic-pairing) is enabled, and the Sensor has a valid Sensor Registration Token, once the Brain sees the Sensor as available, pairing will be completed automatically.

Once a Brain sees the Sensor as **Availabl**e, Sensors will move through **Available**, **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

{% hint style="info" %}
**Please Note:**

* Physical appliances cannot engage in auto-pairing immediately out of the box. They must first be configured with a valid Sensor Registration Token (SRT).
* If a physical appliance shows as **Available** for pairing, and the admin initiates pairing, pairing will complete automatically if online pairing is possible.
  {% endhint %}

### Online Pairing (Physical Sensors Only)

<figure><img src="/files/mvpnCMNae5dh5GXjfTp2" alt=""><figcaption><p>Screenshot is from a vSensor. The <strong>TYPE</strong> would show the model number for physical appliances.</p></figcaption></figure>

Out of the box, physical Sensors will attempt to reach out to the Vectra cloud once they are online.

Once a physical Sensor/Stream appliance shows as **Available** in your Vectra UI, click the pairing button as shown in the above screenshot to open a pairing dialog box.

{% hint style="info" %}
When a physical appliance cannot reach Vectra's updater service because a proxy is required in the customer’s environment to reach outside destinations, the `set brain` command should be used to set the Brain IP or hostname that the Sensor or Stream appliance will attempt to pair with. Sensors do not support proxy configuration.
{% endhint %}

You will then be presented with a dialog box where you can start the pairing process.

* Click the **Pair Sensor** button to begin pairing.
* The Brain will update the Vectra Cloud with its MGT1 IP address or hostname (depending on if you have selected to [pair by hostname or IP](#pair-using-the-detect-brain) and posts a request for the Sensor to initiate the pairing process.
* If the Sensor has access to the Vectra Cloud, upon its next check in (every 5 min), it will now retrieve the location of the Brain from the Vectra cloud and attempt to connect to the Brain.
* If the Sensor does not have access to the Vectra Cloud or is unable to contact the Brain (e.g. the Sensor cannot reach the Brain's IP address in a NAT or proxy environment), the Sensor should be manually instructed to pair with the Brain from the Sensor CLI using the `set brain` command using an IP address for the Brain's MGT1 that will reach the Brain's NAT address from the Sensor or hostname of the Brain.

The Sensor will move through **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

**Online Pairing Summary:**

Appliance serial numbers and keying information are associated with customer accounts during provisioning. Under normal circumstances, if both the Brain and physical Sensor or Stream can reach Vectra’s updater service at `https://update2.vectranetworks.com`, the following high-level diagram explains the standard pairing process:

![](/files/vEenppEFOpLU964W9XJR)

### Pairing in an Air-Gapped Environment vs Offline Pairing

While true air gap environments are typically relatively rare, customers may still need to deploy in environments where none of the components in your deployment can reach the Vectra cloud. A cloud deployed vSensor that can't reach the internet from its VPC could still be consided an air gap deployment from that perspective.

#### **Air-Gapped Pairing**

**Physical Appliances**

While Vectra NDR and Stream can function in full air gapped environments, this does mean that a Sensor Registration Token (SRT) will be required to pair physical Sensors.

**Traditional Hypervisor vSensors**

Traditional hypervisor based vSensors are not impacted because the virtual machine image downloaded from the Brain comes with the keying information needed to allow vSensors to communicate to the Brain. As long as the vSensors can contact the Brain they can pair automatically or via user initiated pairing. They can also use a SRT to authenticate pairing.

**Cloud vSensors**

Similarly, cloud vSensors are required to use a SRT for pairing and only need to be able to contact the Brain to pair and do not need to talk to the Vectra cloud.

**To pair in an air gap environment:**

* Retrieve or generate a current [Sensor Registration Token](#sensor-registration-token-srt).
* Perform the `set registration-token <token>` command at the Sensor CLI.
* Finally perform the `set brain <IP or Hostname>` command at the Sensor CLI.
  * `set brain` should also delete existing brain location information but if there are any issues, the `del brain` command at the Sensor CLI can be used.
* The Sensor should become **Available** for pairing on the Brain.

#### **Offline Pairing (Physical Sensors Only)**

In offline pairing scenarios, if a Sensor is behind a proxy or firewall and cannot connect to the Vectra cloud, then a Sensor Registration Token (SRT) will be required to complete pairing.

The **Pair Sensor** button can be used to begin pairing. A valid Sensor Registration Token (SRT) must be configured. You must also configure the Brain location with the `set brain` command at the CLI of the Sensor.

## Additional Pairing Guidance

### Stream Appliance "Sensor" Pairing Details

As discussed in [about Sensor and Stream pairing](#about-sensor-and-stream-pairing), Stream devices pair in the same manner as Sensor devices. There are some post pairing differences:

A Stream appliance does not show in the Vectra UI on the normal Sensor management screen located at *Configuration → Data Sources → Network → Sensors*. Pairing status for a Stream appliance is available in *Configuration > Setup > Stream* in the *Pairing Status* area:

<figure><img src="/files/CnwbT7Q5NvuMIX5iPZL2" alt="" width="563"><figcaption></figcaption></figure>

A Stream appliance will show its' status if you use the `show sensors` command at the CLI.

### Post Pairing Guidance

Once paired, Sensors will attempt to synchronize software versions by downloading the latest update from the Brain and immediately applying it. The Sensor may become temporarily unavailable while this update is applied. This should only take a few minutes to complete.

Certain vSensor CLI functions and traffic functions will become available only after the vSensor has fully updated. Depending on the specific version of the vSensor, you may see errors or warnings when running CLI functions during the period of time when the vSensor is still updating.

Sensors can be renamed or have their location labeled as desired by clicking on the pencil icon <img src="/files/A2Jl6Dr98rpqroDTzDga" alt="" data-size="line">on the right of the vSensor and editing the details.

### Pairing to New or Changed Brains

#### Pairing to Brain With Changed Location

If the Brain location must be changed there are two processes that can be used to associated existing Sensors with a new Brain:

**Preferred Method:**

* Change the Brain IP address or hostname.
* Redirect all Sensors to the new Brain location using the `set brain` command at the CLI of the Sensor.
  * Previously paired Sensors can simply be redirected because the Brain already has the required registration information for these Sensors.
    * This is also the same for new or different Brains restored from Backups.
  * Unpaired Sensors can use the Sensor Registration Token if needed.
    * For example: The new Brain isn’t restored from backup, is air-gapped, etc

**Alternate Method:**

You can also unpair all Sensors, change the Brain location (hostname or IP address), and then pair all Sensors again. This could cause some buffered data on the Sensors to be lost.

#### Pairing to a Different Brain

* If you have a Brain that will not be restored from backup that you wish to pair an existing Sensor to, this is possible via the use of a Sensor Registration Token.
  * Retrieve or generate a current [Sensor Registration Token](#sensor-registration-token-srt).
  * Perform the `set registration-token <token>` command at the Sensor CLI.
  * Finally perform the `set brain <IP or Hostname>` command at the Sensor CLI.
    * `set brain` should also delete existing brain location information but if there are any issues, the `del brain` command at the Sensor CLI can be used.
  * The Sensor should become **Available** for pairing on the new Brain and will pair automatically if [auto pairing](#virtual-sensor-automatic-pairing) is enabled.

#### Terminating Existing Sensor / Brain Tunnels

In all cases, existing tunnels have to terminate to re-establish connection to a new Brain. This can be accomplished a few different ways.

* Naturally, because the original Brain is no longer reachable due to firewall change, hardware or software failure, etc.
* Using the `set brain` command at the CLI will terminate an existing tunnel and attempt to start pairing with a new Brain.
  * `del brain` can be used to break the tunnel but not set a new Brain location.
* In normal operation, the Sensor can simply be unpaired from its existing Brain. To use the **Unpair** option, the Brain must be connected to the Vectra Cloud and the Sensor must be powered on with an active tunnel to the original Brain.
  * Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors*, click on the Sensor you wish to unpair and click on the **Unpair** button.
  * After unpairing which could take a few minutes, the status of the Sensor should change to **Available**.

<figure><img src="/files/zVRwJeWDyoWKyYcJV4cy" alt=""><figcaption></figcaption></figure>

* Using the **Force Unpair** option in your Vectra UI for the target Sensor.
  * This will unpair the Sensor from the original Brain and when the Sensor attempts communication to the original Brain the tunnel will not function.
  * **Force Unpair** is the same as deleting for a vSensor. You cannot delete a physical Sensor (talk to Vectra Support if this is required).


# AWS vSensor

Parent page for AWS vSensor deployment and includes attachments used by the deployment.

Please see the sub pages of this page for the AWS vSensor deployment guide contents.

## Attachments

Attached to this article is a `loadBlanacerTemplate.json` file that you can use with CloudFormation to deploy a load balancer in front of your Sensor to bypass AWS limitations on traffic mirror sessions for certain instance types.

{% file src="/files/Fnby471yFdZrAi1E77d5" %}

Also attached to this article there are 3 files that are used for integration with AWS from the Brain for HostID (see the guide for more details):

**HostIdTemplate.yml**- Used for integration with the AWS Resource Manager to collect Host ID information

{% file src="/files/F4xUtybGpCH3nWLhGBOA" %}

**HostIdFederatedParentTemplate.yml** - Used for HostID in Federated AWS setups

{% file src="/files/Zmxi8lnqqMbkTyK8Tmls" %}

**HostIdFederatedChildTemplate.yml** - Used for HostID in Federated AWS setups

{% file src="/files/Y7HPxmMOXnTw5geMpzbE" %}

These files can also be downloaded from your Brain after deployment at the following locations:

* https\://\<brain\_hostname\_or\_IP>/resources/HostIdTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/HostIdFederatedParentTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/HostIdFederatedChildTemplate.yaml/serve\_file


# Introduction and requirements

Prerequisites and sizing guidance for deploying Vectra AWS vSensors, including sizing, SRT setup, VPC/subnet planning, and security group requirements.

## Introduction

This document describes the pre-requisites, specifications, and steps required to deploy a Vectra Sensor in an AWS account to monitor cloud Infrastructure-as-a-Service workloads. These Sensors can be paired to Vectra Brains of any type (physical, virtual, cloud) if the required connectivity is in place.

The input to an AWS Sensor can be Amazon VPC traffic mirroring set up on an Amazon elastic network interface or from a VXLAN-based 3rd party packet brokers.

AWS vSensors can be used in both Respond UX and Quadrant UX deployments. For more detail on Respond UX vs Quadrant UX please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux). One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

For additional guidance for AWS IaaS deployments of Vectra, see the following:

* [Vectra AWS IaaS Best Practices Guide](/deployment/ndr-virtual-cloud-appliances/aws-best-practices)
* [Vectra AWS Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-brain)

## Requirements and Preparation

### Supported AWS Regions

Please see [Supported regions for AWS vSensor deployment](/deployment/ndr-virtual-cloud-appliances/aws-vsensor/aws-vsensor-faqs#supported-regions-for-vectra-aws-vsensor-deployment) in the [AWS vSensor FAQs](/deployment/ndr-virtual-cloud-appliances/aws-vsensor/aws-vsensor-faqs) if when deploying from the AWS Marketplace you do not see your desired region. Most regions customers require are already supported.

Vectra periodically updates supported regions. If your desired region is not available, please contact your Vectra account team to request it.

### Sensor Registration Token (SRT)

The ***Configuration*****&#x20;→&#x20;*****COVERAGE*****&#x20;→&#x20;*****Data Sources → Network → Sensors*** area of your Vectra UI allows you to pair and manage network Sensors, configure a number of options related to Sensor pairing and registration, and change the CLI `vectra` user password for paired devices (Sensors and Stream). Navigate in this area to ***Sensor Configuration > Sensor Pairing and Registration.***

<figure><img src="/files/2N4eoIUR3ZgQgx9JZj4T" alt="" width="563"><figcaption></figcaption></figure>

* During Sensor deployment a valid Sensor registration token must be presented to the Brain so that the Sensor can become **Available** to Pair. This token can be created in the Vectra UI or at the CLI of the Brain. It is valid for 24 hours and can be regenerated at any time.
* For full details on pairing processes, please see [pairing appliances](/deployment/appliance-operations/pairing-appliances).
* If you have a valid token, you can **Copy** it here for later use using the link.
  * Otherwise, click the **Generate New Sensor Registration Token** link.
  * Use this token for Sensor deployment (tokens expire 24 hours after generation).

### Sensor Sizing

AWS Sensors are available in a variety of sizes:

* r5.large / r5n.large – 1 Gbps
* r5.xlarge / r5n.xlarge – 2 Gbps
* r5.2xlarge / r5n.2xlarge – 4 Gbps
* r5.4xlarge / r5n.4xlarge – 8 Gbps
* c5n.18xlarge – up to \~10 Gbps (Contact your Vectra sales team for guidance)

The r5n instances guarantee networking performance and as a result it is recommended, but may not be available in all AWS regions. The r5 instances deliver the same performance without the guarantee. The c5n.18xlarge instance is a dedicated instance which also has the benefit of a 100 session traffic mirror destination limit vs the 10 session limit on the other instances. The c5n.18xlarge may not hit 10 Gbps in some scenarios as there are many factors to consider. Please engage your Vectra sales team for additional guidance for your specific network architecture.

Vectra periodically updates our AWS Marketplace listing to include additional instance choices. Please work with your Vectra account team for guidance on new options.

The Sensor instances can be deployed either stand alone, or with a Network Load Balancer (Vectra currently supports 1 Sensor per NLB). Currently, multiple Sensors cannot be deployed in a single Auto Scale Group.

{% hint style="info" %}
**Please Note:**

Vectra product and engineering teams monitor the changing landscape of available IaaS cloud instance types. Occassionally customers will ask if a specific new instance type is supported.

There are a number of factors that can cause Vectra AI to stay with a specific instance type versus a newer one such as:

* Cost increase vs performance increase - sometimes a newer instance, for example, might cost 17% more but only increase performance by 10%.
* Availability - not all new instance types are always available in all the locations that Vectra AI supports.

Please reach out to your account team if you have questions about specific instance types that aren't supported.
{% endhint %}

### SSH Key Pair

An SSH key pair will need to be created for the Sensor to allow an administrator to SSH to the CLI as the “vectra” user. The public key will be set in the CloudFormation template during deployment. Guidance for key pair generation is here: [Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html?icmpid=docs_ec2_console)

* After the Sensor is deployed, you can login to the Sensor CLI via SSH using the private key:
  * You may need to make the key readable to you using a command such as:
    * `chmod 400 VectraSensorPrivateKey.pem`
  * Example login command:
    * `ssh -i <private key path> vectra@SensorHostnameOrIP`

### VPC and Subnets

You will either need to create a new VPC and Management / Traffic Subnets for use with the Sensor you are deploying or re-use an existing one. You will choose these when filling out the CloudFormation template. Some AWS documentation is available at the following links:

* [What is Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
* [Overview of VPCs and subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html)
* [Create VPCs and subnets](https://docs.aws.amazon.com/vpc/latest/userguide/build-create-work-with.html)

### Security Groups

The CloudFormation template will create empty security groups, or you may select existing security groups to use.

* **mgtSecurityGroup** - Used for the management interface of the Sensor.
  * This security group must allow inbound TCP/22 from the Brain and allow outbound TCP/443 and TCP/22 to the Brain for management.
* **trafficSecurityGroup** - Used for the traffic capture interface of the Sensor.
  * In case of ingesting from a packet broker, ensure that VxLAN traffic is permitted inbound on UDP/4789.
  * If deploying a Network Load Balancer in front of the Sensor, inbound TCP/80 must also be permitted from the NLB for the health-check from the load balancer to succeed.


# Deployment from AWS Marketplace

Step-by-step AWS Marketplace and CloudFormation deployment for AWS vSensors, including key template parameters and post-deploy checks.

## Subscribing and Launching CFN

The Sensor software is available as an Amazon Machine Image along with an AWS CloudFormation template that enables easy deployment as follows:

* Browse to the AWS Marketplace Subscriptions service on the AWS Management Console.
* Click **Discover Products** and search for **Vectra**.

![](/files/1335c373f96d75498ce562679fe952ecee1fa6aa)

* Select **Vectra Sensor**.

![](/files/c5a4548d007a5d7c449c1a43c34ed5f863995dc8)

* Click **Continue to Subscribe**.
  * There is no additional cost for this step.
  * All Vectra licensing is handled by Vectra.

![](/files/0f876869d424e3940822fc032513c3b63fc500dd)

* Click **Accept Terms**.
* AWS will process the subscription before enabling next steps.
* Once completed, AWS will allow you to **Continue to Configuratio**n.
* Select the region to deploy the Sensor in.

![](/files/428614dfe5ea01a4a4e814a27018cc29032a1ff5)

* Click **Continue to Launch**.
* Under Choose Action, select **Launch CloudFormation**.

![](/files/e37ea2e1c594572bb6d5aae155ad578d0e688463)

* You will be presented the AWS CloudFormation screen pre-populated with the Template and Amazon S3 URL for the Vectra Sensor AMI.

![](/files/03d3ccc683597f0a0f69d6f2d441a7f3433a4d54)

* Click **Next**.

## Specifying Stack Details

* Fill out the **Specify stack details** screen that is presented using the instructions below the screenshot.

![](/files/1c9060aa2b17f17775e3e0454e6daf58d557170c)

In the **Specify stack details** screen you will be asked to fill in the following fields:

* **Stack name** - The Stack name must be unique and can contain letters, numbers, and dashes only.
* **baseName** - This name will be prepended to the individual resources that are deployed for the template.
* **brainIP** - The IP address or the Fully Qualified Domain Name (FQDN hostname) of the Vectra Brain.
  * This address must be reachable from the Sensor’s management subnet over port 22 and 443.
* **instanceType** - Select from the options offered (for options not displayed, contact Vectra).
  * Please see the [Vectra AWS IaaS Best Practices Guide](/deployment/ndr-virtual-cloud-appliances/aws-best-practices) for more information.
  * r5.large / r5n.large – 1 Gbps
  * r5.xlarge / r5n.xlarge – 2 Gbps
  * r5.2xlarge / r5n.2xlarge – 4 Gbps
  * r5.4xlarge / r5n.4xlarge – 8 Gbps
  * c5n.18xlarge – up to \~10 Gbps
* **mgtPrivateIP**- Private Management IP address to assume on launch (NoValue to use DHCP)
* **mgtSecurityGroup** - This setting determines what access is permitted for the Sensor.
  * If left blank, the template will auto-create a security group, and rules must be added after.
  * If there is an existing security group, add it here.
  * This security group must allow inbound TCP/22 from the Brain and allow outbound TCP/443 and TCP/22 to the Brain for management.
* **mgtSubnet** - This specifies the subnet which the Sensor will use to communicate with the Brain.
* **mgtVPC** - This specifies the Amazon VPC where the management interface of the Sensor is located.
* **networkLB** - If using a load-balancer deployed in front of the traffic ingestion interface, specify its ARN here.
  * If left blank, the Sensor will assume no load-balancer.
  * Without a load-balancer, AWS restricts that a maximum of 10 traffic mirror sessions can feed the mirror destination (Sensor) for all Sensors except the c5n.18xlarge which has a 100 session limit.
  * Vectra supplies a CloudFormation template to create this load-balancer as an attachment to the [AWS vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-vsensor) support article (loadBlanacerTemplate.json). The subnet specified in the load balancer CloudFormation template should be the subnet that will contain your traffic interface.
  * **Please Note:** This configuration must be added pre-deployment or the Sensor must be re-deployed.
* **registrationToken** - This token must be copied from the *Configuration → COVERAGE → Data Sources > Network > Sensors > Sensor Registration and Pairing* page of the Vectra UI. Tokens are valid for 24 hours.
  * A valid token is required for the Sensor to register with the Brain and become **Available** for pairing.
  * Instructions to generate a Sensor registration token are in [Sensor Registration Token](/deployment/ndr-virtual-cloud-appliances/aws-vsensor/introduction-and-requirements#sensor-registration-token-srt).
* **sshKey** - AWS recommends use of the Amazon EC2 key pair feature to manage access to the Sensor VM.
  * This field allows the user to add a public key to the Sensor for SSH to the CLI with the `vectra` user.
  * This key pair should have been created previously.
* **tenancy** - Tenancy attribute for the AWS instance. Controls if this machine should be on a dedicated VM.
  * Default selection utilizes shared hardware.
* **trafficPrivateIP** - Specify an IP for the traffic capture interface or allow a DHCP address as default.
* **trafficSecurityGroup** - Vectra’s CloudFormation template will create this automatically for you if you leave this at the default of `AWS::NoValue`. If creating your own, please keep the following in mind.
  * Typically, this should allow all incoming traffic from your sources (traffic mirrors or packet brokers).
  * In case of ingesting from a packet broker, ensure that VxLAN traffic is permitted in on UDP/4789.
  * If deploying a Network Load Balancer in front of the Sensor, inbound TCP/80 must also be permitted from the NLB for the health-check from the load balancer to succeed.
  * **Please note** - Direct traffic mirroring bypasses this security group setting. If using a load balancer, make sure to allow traffic from the IP ranges associated with the subnets where the load balancer is placed. Note that load balancer IPs are not fixed.
* **trafficSubnet** - This is the Amazon Subnet in which the traffic ingestion interface is placed.
* **trafficVPC** - This is the Amazon VPC in which the traffic ingestion interface is placed.
* Click **Next**.
* All fields in the next screen are optional - You may wish to configure tags as an example.
* Click **Next**.

![](/files/574b333ab02442ac33a654f5a57fa2da388c845b)

* If one desires to create multiple stacks with mostly identical configuration, click the **Quick-create link** and use for subsequent stacks.
* Click **Create Stack**.
* At this point, the stack creation should proceed through to completion.

![](/files/8ccfc8f789c0d371751cc6ee4fdcdd45347c2feb)

## Next Steps

* Once the deployment is complete, the vSensor will automatically boot up and reach out to the Vectra Brain.
  * If the Brain is configured for automatic pairing for virtual Sensors, the Sensor will register with the Brain and then attempt to Pair with the Brain and finally will update its software from the Brain.
* The Sensor will show up in the *Configuration → COVERAGE → Data Sources > Network > Sensors* tab of the Vectra UI just like a physical Sensor would.
  * Once you see the Sensor here and it is current with the Brain’s software version, it is ready for operation.
* You can now move on to [AWS integrations](/deployment/ndr-virtual-cloud-appliances/aws-vsensor/aws-integrations) or if you need more pairing help, please see [pairing AWS vSensors](/deployment/ndr-virtual-cloud-appliances/aws-vsensor/pairing-aws-vsensors).


# AWS integrations

Configure AWS integrations for Vectra (HostID, optional Security Hub, optional CloudWatch), including required IAM users/roles/policies.

## Vectra AWS Integrations

If you are using an AWS Brain and followed its [deployment guide](/deployment/ndr-virtual-cloud-appliances/aws-brain), you may have already configured your Brain to be able to retrieve additional context about Amazon EC2 hosts and can skip the below AWS IAM and Host ID configuration steps. AWS Sensors can pair with any Brain (not just those deployed in AWS). We are including steps for Host ID integration in this guide for those not using an AWS Brain.

Vectra AWS integrations require adding AWS IAM users, roles, and policies. Security Hub publishing (Quadrant UX deployments only) will only publish Host scores involving AWS workloads. CloudWatch health and audit logs are typically only desired in AWS for customers whose Brain is deployed in AWS. Vectra has 3 AWS integrations:

* **HostID**
  * This is the most common AWS integration and configuring it is considered a best practice.
  * Instructions are provide below.
  * Adding relevant context (Host ID, OS, instance ID, tags, etc) about Amazon EC2 hosts when observed by Vectra.
  * While technically optional, it is a best practice is to enable this integration when you have Hosts deployed in AWS that are monitored by Vectra. Detections in Vectra are tied to a Host or Account entity. To be more easily actionable and for some algorithms to support learning, Detections must be attributable to a Host (including statically defined hosts), rather than a generic Host IP address or other similar network artifact – especially as many of these network artifacts are transient in the cloud. To this end, the Vectra Brain can directly query the describe instance APIs in AWS to extract the instance identifier, tags, Amazon VPC and other metadata for Amazon EC2 VMs.
  * The AWS account used for this integration may be set up as a standalone account or as a federated organization with a parent account and multiple child accounts.
* **AWS Security Hub (Quadrant UX only)**
  * Please see [AWS Security Hub integration](/deployment/ndr-virtual-cloud-appliances/aws-security-hub-integration-qux-only) for configuration details.
    * Please note that it is required to configure AWS HostID integration before configuring Security Hub integration.
  * The Vectra Brain can natively publish Host scores involving AWS workloads in AWS Security Findings Format (ASFF) to the AWS Security Hub service. This is optional.
* **CloudWatch**
  * Please see the [AWS Brain deployment guide](/deployment/ndr-virtual-cloud-appliances/aws-brain) for configuration details.
  * Publishing health and audit logs to Amazon CoudWatch. This is optional.

### AWS Host ID Integration Introduction

* The Host ID integration for AWS VPCs enables adding relevant context (Host ID, OS, instance ID, tags, etc) about Amazon EC2 hosts when observed by Vectra.
* Detections in Vectra are tied to a Host or Account entity.
  * To be more easily actionable and for some algorithms to support learning, Vectra detections must be attributable to a Host (including statically defined hosts), rather than a generic Host IP address or other similar network artifact – especially as many of these network artifacts are transient in the cloud.
  * To this end, the Vectra Brain can directly query the describe instance APIs in AWS to extract the instance identifier, tags, Amazon VPC and other metadata for Amazon EC2 VMs.
* While technically optional, it is a best practice is to enable this integration when you have Hosts deployed in AWS that are monitored by Vectra.
  * This may be because you have vSensors deployed in AWS, or if you have connectivity to AWS that allows any of your other Vectra Sensors to observe communications with hosts deployed in AWS.
* The integration will provide additional artifacts that help with Host ID's automated naming of hosts in your environment.
  * For more details on Host ID, please see [Understanding Vectra Detect Host Naming](/reference/understanding-vectra-host-naming).
* The AWS account used for this integration may be set up as a standalone account or as a federated organization with a parent account and multiple child accounts.

### Supporting Materials

Vectra makes CloudFormation templates available to enable easy creation of the users, roles and policies required.

**HostIdTemplate.yml**- Used for integration with the AWS Resource Manager to collect artifacts that provide details to Vectra's automated Host ID capability.

{% file src="/files/F4xUtybGpCH3nWLhGBOA" %}

**HostIdFederatedParentTemplate.yml** - Used for Host ID in Federated AWS setups

{% file src="/files/Zmxi8lnqqMbkTyK8Tmls" %}

**HostIdFederatedChildTemplate.yml** - Used for Host ID in Federated AWS setups

{% file src="/files/Y7HPxmMOXnTw5geMpzbE" %}

The files can also be downloaded from your Brain after deployment from the following locations:

* https\://\<brain\_hostname\_or\_IP>/resources/HostIdTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/HostIdFederatedParentTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/HostIdFederatedChildTemplate.yaml/serve\_file

### Firewall Requirements

For **AWS** **Host ID integration only**, the Vectra Brain needs **outbound HTTPS/TCP 443** to these AWS API endpoints:

| Purpose                                   | AWS endpoints to allow       |
| ----------------------------------------- | ---------------------------- |
| Caller identity / account validation      | `sts.<region>.amazonaws.com` |
| IAM account alias + permission simulation | `iam.amazonaws.com`          |
| EC2 inventory / VPC discovery             | `ec2.<region>.amazonaws.com` |

**Summary:**

Allow outbound TCP/443 from Vectra Brain to AWS STS, IAM, and EC2 API endpoints for the AWS regions being monitored.

The Host ID templates reference these AWS actions: `sts:GetCallerIdentity`, `iam:ListAccountAliases`, `iam:SimulatePrincipalPolicy`, and EC2 `Describe*` calls for instances, regions, subnets, VPCs, VPC peering, and traffic mirror resources.

### Configuration

The AWS account may be set up as a standalone account or as a federated organization with a parent account and multiple child accounts.

#### Standalone Accounts

If the deployment involves just a single AWS account, use CloudFormation to create the `VectraCognitoHostIDv1` IAM user using the `HostIdTemplate.yml`. The template is also shown in an expandable code block below. Users can also be created manually if desired using the template as guide for the permissions required.

{% code expandable="true" %}

```
AWSTemplateFormatVersion: '2010-09-09'
Description: Vectra HostID User version 1
Resources:
  user:
    Properties:
      Policies:
        - PolicyDocument:
            Statement:
              - Action:
                  - iam:ListAccountAliases
                  - iam:SimulatePrincipalPolicy
                  - ec2:DescribeInstances
                  - ec2:DescribeRegions
                  - ec2:DescribeSubnets
                  - ec2:DescribeTrafficMirrorTargets
                  - ec2:DescribeTrafficMirrorSessions
                  - ec2:DescribeVpcPeeringConnections
                  - ec2:DescribeVpcs
                  - sts:GetCallerIdentity
                Effect: Allow
                Resource:
                  - '*'
            Version: '2012-10-17'
          PolicyName: vectra_hostid_permissions
      UserName: VectraCognitoHostIDv1
    Type: AWS::IAM::User
```

{% endcode %}

You may add as many credential sets as required if you have multiple AWS accounts that you wish to treat as standalone accounts. Once you have created the IAM user you must create a new Access key in AWS for the user. AWS has some documentation available [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html).

* Navigate to the user `VectraCognitoHostIDv1` in the Identity and Access Management service.
* Click on the **Security credentials** tab and the **Create Access key** button.
  * This will generate a credential pair similar to the below screenshot.
  * Please take note of these credentials for later use in the Vectra UI.

<img src="/files/21WvgCZjAJ8sLMZ2EXEe" alt="" width="563">

* In the Vectra UI, navigate to *Configuration > SETUP > External Connectors > AWS* and click **Edit**.
* Turn **On** the **Enable integration with AWS**.
* Click **Add Credential** and fill out the form using the values you just noted and the appropriate Cloud Type.
  * The **Alias** can be any identifier you wish to use for this set of credentials in Vectra’s UI.
  * Enter access key ID and secret access key corresponding to the `VectraCognitoHostIDv1` IAM user.

<img src="/files/PyKK3rPZvEdV80ocSKIv" alt="" width="563">

* Click **Add**.

<figure><img src="/files/NPtr8D0M7awubf1yXnMC" alt=""><figcaption></figcaption></figure>

* Click **Save** on the **Enable integration with AWS Resource Manager** configuration area.
* Look for the green check mark and a status of **Connected**.

#### Federated AWS Organizations with Parent and Child Accounts

For these types of organizations, Vectra supports role assumption at the child account level using an IAM user that is created at the parent account level.

* Use CloudFormation to create the `VectraCognitoHostIDFederated` IAM user in the parent account using the `HostIdFederatedParentTemplate.yml` file.
  * The user can also be created manually if desired using the template as guide for the permissions required.
  * The template is also shown in an expandable code block below.

{% code expandable="true" %}

```
AWSTemplateFormatVersion: '2010-09-09'
Description: Vectra HostID Federated User version 1
Outputs:
  ChildAccountRole:
    Description: The role name that will be assumed in all child AWS accounts
    Value: !Ref 'ChildAccountRole'
  ParentAccountUser:
    Description: The user name in the parent AWS account
    Value: !Ref 'ParentAccountUser'
Parameters:
  ChildAccountRole:
    Default: VectraCognitoHostID
    Description: The role name that will be assumed in all child AWS accounts
    MaxLength: '64'
    MinLength: '6'
    Type: String
  ParentAccountUser:
    Default: VectraCognitoHostIDFederated
    Description: The user name in the parent AWS account
    MaxLength: '64'
    MinLength: '6'
    Type: String
Resources:
  user:
    Properties:
      Policies:
        - PolicyDocument:
            Statement:
              - Action:
                  - sts:AssumeRole
                Effect: Allow
                Resource:
                  - !Join
                    - ''
                    - - arn:aws:iam::*:role/
                      - !Ref 'ChildAccountRole'
            Version: '2012-10-17'
          PolicyName: VectraCognitoHostID
      UserName: !Ref 'ParentAccountUser'
    Type: AWS::IAM::User
```

{% endcode %}

* Navigate to the user `VectraCognitoHostIDFederated` in the Identity and Access Management service.
* Click on the **Security credentials** tab and the **Create Access key** button.
  * This will generate a credential pair similar to the below screenshot.
  * Please take note of these credentials for later use in the Vectra UI.

<img src="/files/21WvgCZjAJ8sLMZ2EXEe" alt="" width="563">

* Use CloudFormation to create the `VectraCognitoHostID` role in each child account where Vectra vSensors will be deployed.
  * Use the `HostIdFederatedChildTemplate.yml` attached at the bottom of this page.
  * The user can also be created manually if desired using the template as guide for the permissions required.
  * The template is also shown in an expandable code block below.

{% code expandable="true" %}

```
AWSTemplateFormatVersion: '2010-09-09'
Description: Vectra HostID Federated Assume Role version 1
Outputs:
  ChildAccountRole:
    Description: The role name that will be assumed in all child AWS accounts
    Value: !Ref 'ChildAccountRole'
  ParentAccount:
    Description: The AWS account ID of the parent account
    Value: !Ref 'ParentAccount'
  ParentAccountUser:
    Description: The user name in the parent AWS account
    Value: !Ref 'ParentAccountUser'
Parameters:
  ChildAccountRole:
    Default: VectraCognitoHostID
    Description: The role name that will be assumed in all child AWS accounts
    MaxLength: '64'
    MinLength: '6'
    Type: String
  ParentAccount:
    AllowedPattern: '[0-9]{12}'
    Description: The AWS account ID of the parent account
    Type: String
  ParentAccountUser:
    Default: VectraCognitoHostIDFederated
    Description: The user name in the parent AWS account
    MaxLength: '64'
    MinLength: '6'
    Type: String
Resources:
  role:
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Action:
              - sts:AssumeRole
            Effect: Allow
            Principal:
              AWS:
                - !Join
                  - ''
                  - - 'arn:aws:iam::'
                    - !Ref 'ParentAccount'
                    - :user/
                    - !Ref 'ParentAccountUser'
      MaxSessionDuration: 7200
      Path: /
      Policies:
        - PolicyDocument:
            Statement:
              - Action:
                  - iam:ListAccountAliases
                  - iam:SimulatePrincipalPolicy
                  - ec2:DescribeInstances
                  - ec2:DescribeRegions
                  - ec2:DescribeSubnets
                  - ec2:DescribeTrafficMirrorTargets
                  - ec2:DescribeTrafficMirrorSessions
                  - ec2:DescribeVpcPeeringConnections
                  - ec2:DescribeVpcs
                  - sts:GetCallerIdentity
                Effect: Allow
                Resource:
                  - '*'
            Version: '2012-10-17'
          PolicyName: VectraCognitoHostIDPolicy
      RoleName: !Ref 'ChildAccountRole'
    Type: AWS::IAM::Role
```

{% endcode %}

* In the Vectra UI, navigate to *Configuration > Setup > External Connectors > AWS* and click **Edit**.
* Turn **On** the **Enable integration with AWS setting.**
* Click Add Credential and fill out the form using the values you just noted and the appropriate Cloud Type.
  * Enter the access key ID and secret access key corresponding to the `VectraCognitoHostIDFederated` user you created earlier in the parent account.
  * The **Alias** can be any identifier you wish to use for this set of credentials in Vectra’s UI.

<img src="/files/Ev55HwJfcVSHOBuS5Ltf" alt="" width="563">

* Click the **Multi-Account Credential** checkbox to enable multi-account credential entry.
* **Role to Assume** should default to **VectraCognitoHostID** and can be left as is unless any of the templates have been modified.
* List all the **AWS Account Numbers** (account IDs) to be covered.
  * You can hit enter after each account or paste in multiple account numbers separated by a comma.
* You may test access using the **Test Account** link.
* Click **Add**.
* **Save** your connector configuration
* Look for the green check mark and a status of **Connected**.

<figure><img src="/files/vpAuPMRYWleht578OH1v" alt=""><figcaption></figcaption></figure>

### Viewing and Modifying Virtual Networks Considered by the Connector

The connector will only look at virtual machines that belong to some VPCs, not necessarily all VPCs that the credentials have access to. Specifically, by default, the connector will only look for virtual machines with network interfaces in the VPCs where a Vectra AWS Sensor traffic interface is deployed into, and all the VPCs peered to it. If a virtual machine has multiple network interfaces, the connector will provide host identification only for the IP addresses belonging to interfaces on monitored VPCs.

Vectra limits the scope of the connector to only virtual networks that can reach an AWS Sensor for the following reasons:

* Vectra wants to avoid an excessive number of connections to the AWS resource manager.
* To improve performance, Vectra wants to avoid storing unnecessary information in the platform for resources that we are not monitoring.
* In the cloud it is possible that you may have some isolated virtual networks that are not monitored by Vectra Sensors but have overlapping IP space with some other networks that are monitored. Duplicate IPs are not supported by Vectra. To avoid Host ID issues, we only consider virtual machines on the networks that appear reachable by our Sensors.

If you want to add or remove some virtual networks from the set of virtual networks that Vectra monitors, you can do so through the CLI (ssh to the Brain as the `vectra` user). This functionality is not available in the Vectra UI. The use case for adding or removing virtual networks could be any of the following:

* If you have some tunneling or forwarding enabled and Vectra AWS Sensors see traffic from VPCs that are NOT directly connected to our Sensor:
  * You will want to add the networks to the monitored networks list to extend Host ID coverage to the tunneled/forwarded traffic’s associated Hosts.
* If you do NOT have any AWS Sensors deployed, but mirror AWS traffic into your data center where you have Vectra physical or virtual Sensor coverage:
  * You will want to add the networks to the monitored networks list to extend Host ID coverage to the mirrored traffic.
* If you do have some overlapping IP space on a network that appears reachable by our Sensor, but it is not monitored by our Sensor:
  * You will want to remove the overlapping networks from the monitored networks to avoid any Host ID issues.
* If you have a lot of peered VPCs but only some are monitored by the Sensor:
  * You will want to remove the non-monitored networks from the monitored networks list to increase performance and reduce load on the AWS resource manager.

The command to include or exclude specific virtual networks from the Vectra CLI is `set aws hostid config`. Without turning on the `aws hostid config` at the CLI, the connector will operate in a default manner. Think of this command as customization beyond the default behavior described above, not a full replacement for it. You must turn on the `aws hostid config` at the CLI to enable any include/exclude customizations that you configure.

The command has a help message illustrating its use:

```language-markup
vscli > set aws hostid config --help
Usage: set aws hostid config [ --clear-exclude ] [ --clear-include ] [ --on-off ( on | off ) ] [ -i include ] [ -e exclude ]

Options:
  --clear-exclude     set if you want to wipe the list of vpcs to exclude
  --clear-include     set if you want to wipe the list of vpcs to include
  --on-off [on|off]
  -i, --include TEXT  comma separated list of vpc id's to add to the include
                      list
  -e, --exclude TEXT  comma separated list of vpc id's to add to the exclude
                      list
  -h, --help          Show this message and exit.
```

The command `show aws hostid config` will show if customization is enabled for the default Host ID configuration, and any included or excluded VPCs that you want to be considered or not considered by the connector.

Example of usage:

```language-markup
vscli > set aws hostid config -i vpc-0830d0eef7c5d27fc
vscli > set aws hostid config --on-off on
successfully set aws hostid configuration

vscli > show aws hostid config
enabled: True
exclude:
include:
    vpc-0abc356d,
    vpc-0830d0eef7c5d27fc
```


# Pairing AWS vSensors

Pair AWS vSensors to a Brain using the Sensor Registration Token workflow (AWS vSensors do not support online pairing).

## AWS vSensor Pairing

The same content available on this documentation site under *Deployment → Appliance Operations →* [*Pairing appliances*](/deployment/appliance-operations/pairing-appliances) is shown below. Please note that AWS vSensors do NOT support online pairing and that content below specific to physical Sensors or traditional hypervisor based vSensors does not apply to AWS vSensors.

## About Sensor and Stream Pairing

Sensors and Stream appliances behave the same way from a pairing perspective. Because of this, you may see the **Sensor** term used in this document, your Vectra UI, or at the CLI of a Vectra appliance when sometimes the appliance in question is a Stream appliance.

Multiple Sensors can be attached to a single Brain while the Brain supports a single Stream appliance at a time. The exact limits for how many appliances can be paired to your Brain will depend on the Brain model or configuration. Please see [appliance specifications](/deployment/getting-started/appliance-specifications) for details.

{% hint style="info" %}
**Please Note:**

* From this point forward, the term "Sensor" will be used to represent both Sensor or Stream appliance types in this document.
  {% endhint %}

## Pairing Overview

Pairing is the process that allows Sensors to communicate with the Brain. All network sessions between an appliance and the Brain are initiated from the Sensor side.

There are three basic ways to pair a Sensor or Stream appliance with a Brain:

{% tabs %}
{% tab title="Using a Sensor Registration Token" %}
Using a Sensor Registration Token (SRT) works for any appliance type and is required for Sensors deployed in IaaS cloud environments such as AWS, Azure, and GCP.

* A Sensor Registration Token (SRT) is generated on the Brain and then configured on the Sensor or Stream appliance.
* Once the Sensor is configured with a Brain IP address or hostname, it will annouce itself to the Brain if powered on.
* The Brain will recognize the validity of the token and allow the Sensor to become available for pairing.
* A user will initiate pairing or use auto pairing (2nd tab above) if enabled.
  {% endtab %}

{% tab title="Auto Pairing" %}
Auto pairing is an option that can be enabled by administrators that allows some Sensor configurations to automatically pair with your Brain. If either of the two below states is true, and the Sensor can reach the Brain, pairing will be completed automatically when auto pairing is enabled.

* You have a vSensor for traditional hypervisor deployment (VMware, Hyper-V, Nutanix, KVM, etc) that was downloaded from your Brain, and is preconfigured with the location of the Brain and the registration information required for pairing.
* Appliances (physical and virtual) that are configured with a Sensor Registration Token can also auto pair with a Brain.
  {% endtab %}

{% tab title="Online Pairing (Physical Sensors Only)" %}
Online pairing is only supported for Vectra physical appliances that can reach the Vectra updater service and the Brain. If the Brain is behind NAT and not reachable via its configured IP, see [online pairing](#online-pairing-physical-sensors-only-1) for more details (the `set brain` command at the Sensor CLI will need to be used).

* Appliances are provisioned by Vectra and then shipped to a customer.
  * They are also associated to the customer account.
  * The Brain retrieves the list of provisioned Sensors from Vectra periodically.
* Sensors will retrieve the location of your Brain from Vectra when they come online.
* In the Brain UI, provisioned Sensors will show as **Available** for pairing.
* When pairing is attempted by the user, the Brain and Sensor will retrieve the required registration information from Vectra and complete the pairing process.
  {% endtab %}
  {% endtabs %}

Pairing is also supported in air-gapped environments and physical appliances can also be paired "offline" when required. For details please see [Pairing in an Air-Gapped Environment vs Pairing Offline](#pairing-in-an-air-gapped-environment-vs-pairing-offline).

### Pairing by Hostname vs IP Address

Sensors need to know the location of the Brain appliance so that they know what hostname or IP address to communicate with. Pairing by hostname is generally preferred over pairing by IP address for the following reasons:

* Failover scenarios are easier to manage because a replacement Brain can be setup with the same hostname as the original Brain even if the IP address will be different. Paired Sensors will be able to automatically re-pair with the new Brain once the DNS is changed (if the old Brain is offline, see [pairing to new or changed Brains](#pairing-to-new-or-changed-brains) for more details). This is because the backup contains Sensor state information.
* If your Brain appliance is configured with a DHCP address for its management port instead of a static IP address and you have paired by hostname, even if the IP address of the Brain changes, Sensors will still be able to communicate with the Brain they are paired to.

## Sensor Pairing and Registration Settings

The ***Configuration*****&#x20;→&#x20;*****COVERAGE*****&#x20;→&#x20;*****Data Sources → Network → Sensors*** area of your Vectra UI allows you to pair and manage network Sensors, configure a number of options related to Sensor pairing and registration, and change the CLI `vectra` user password for paired devices (Sensors and Stream). For more details, please see the [Respond UX deployment](/deployment/getting-started/respond-ux-deployment-guide) or [Quadrant UX deployment ](/deployment/getting-started/quadrant-ux-deployment)guides.

Navigate in this area to ***Sensor Configuration > Sensor Pairing and Registration.***

Editing this area will allow you to alter the default way a Sensor will attempt to pair with a Vectra Brain and allow you to enable or disable Virtual Sensor Automatic Pairing (Auto Pairing). Additionally, this area provides a link to generate a new Sensor Registration Token (SRT) or to copy an existing SRT.

### Pair using the Detect Brain

<figure><img src="/files/QUwDKDJ7oBhkn3gaAtu7" alt="" width="563"><figcaption></figcaption></figure>

* If you have a DNS name configured in *Configuration → COVERAGE → Data Sources → Network → Brain Setup → Brain*, then the **Pair using the Detect brain** area will provide a choice between the configured DNS name and the management IP address (MGT1).
* If you do not have a DNS name configured, there will only be one option present using the configured IP for the management interface of your Brain.
  * It may take a few minutes after adding a DNS name in your Brain setup for the choice to appear in this area.
* This setting only affects the default pairing mode for Sensors used in future pairing operations.
  * Any previously paired devices will remain paired in the same manner they were originally paired.
  * Regardless of setting, the `set brain` command available at the CLI of the Sensor will allow you to attempt pairing via hostname or IP.
* Should you choose to change the pairing method for previously paired devices, you will need to unpair the previously paired devices and re-pair them.

### Virtual Sensor Automatic Pairing "Auto Pairing"

* This setting allows you to choose if you want to automatically pair (auto pairing) with Sensors that have a valid Sensor Registration Token (SRT) configured.
  * Even though the setting name implies that this will only impact virtual Sensors, any Sensor, including physical appliances can auto pair if a valid SRT is configured when pairing is attempted.
* It is recommended to allow auto pairing during initial setup or during large Sensor rollouts.
* When you are done deploying vSensors, you may turn this off to enhance security posture.

### Sensor Registration Token (SRT)

<figure><img src="/files/2N4eoIUR3ZgQgx9JZj4T" alt="" width="563"><figcaption></figcaption></figure>

* Use this area to see the status of SRTs (how long before an SRT expires), copy a SRT, and to generate new SRTs.
* SRTs are used to validate Sensors attempting to register to a Brain and reset after 24 hours.
* SRTs are used in the **Registration Token** field in the Sensor deployment template for Sensors deployed in IaaS clouds such as AWS, Azure, and GCP.
* While the SRT is required for cloud Sensor deployment, it is optional for physical Sensors and virtual Sensors.
* Use of a SRT will allow you to pair a Sensor with any Brain in your organization. This can be useful for disaster recovery scenarios where a device may have been paired to another Brain previously.

**SRT Retrieval and Generation at the CLI**

SRT retrieval and generation can also be accomplished at the CLI of your Brain. For details on how to access the CLI of your Brain, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for CLI SRT retrieval and generation example.</summary>

Use the `show registration-token` command as shown below:

```
vscli > show registration-token --help
Usage: show registration-token [ -g ]

  Get registration token.

Options:
  -g, --generate  Generate new token
  -h, --help      Show this message and exit.

vscli > show registration-token
Output:
    Error: registration token not found

vscli > show registration-token -g
Output:
    Expiration: 2026-01-30T18:49:35.518524+00:00,
    Token: nvxfrxzknbchrbztyvlchkbnhwlxhdvz
```

</details>

## Configuring the Brain Location and SRT on a Sensor

Sensors can have the Brain location (Hostname or IP Address) used for pairing configured automatically or manually. Additionally, the Sensor Registration Token (SRT) can be set to allow a Sensor to pair with any Brain type as long as the SRT is valid.

### Automatic Configuration Scenarios

**vSensors for traditional hypervisors**

* These are used in platforms such as VMware, Nutanix, KVM, Hyper-V, etc.
* When a vSensor image is downloaded from your Brain, it is preconfigured with the location of the Brain it was downloaded from.
* The location encoded into the image is based on the hostname or IP address that was selected in the [Sensor Pairing and Registration](#sensor-pairing-and-registration-settings) settings area above.
* The SRT is not required as registration information is encoded into the vSensor image that was downloaded.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**Physical Sensors**

* An online Vectra Brain will update the Vectra cloud with its location.
* The location is based on if you have selected to pair via the management IP or hostname in the [Sensor Pairing and Registration](#sensor-pairing-and-registration-settings) settings area above.
* When an online Sensor connects to the Vectra cloud, the location will be provided to the Sensor so that it can announce itself as available for pairing to the Brain.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

### Manual Configuration Scenarios

**vSensors for IaaS clouds such as AWS, Azure, and GCP**

* Since all cloud vSensors are either deployed from the cloud provider marketplace or via a generic image shared directly to you prior to deployment, all cloud vSensor images are identical and are not preconfigured with registration information or a Brain location.
* The Brain location and Sensor Registration Token are configured as part of the deployment process for each cloud vSensor. This is typically done through a customizing a template in the cloud provider or a editing a template prior to deployment using a CLI command.
  * For more details, please see [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances) for the deployment guide for you vSensor.
* Post deployment
  * If you are able to reach the command line of the vSensor and log in, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**vSensors for traditional hypervisors**

* These are used in platforms such as VMware, Nutanix, KVM, Hyper-V, etc.
* As discussed in the [automatic configuration scenarios](#automatic-configuration-scenarios) above, these vSensor images are preconfigured with registration information and Brain location unique to the Brain that the image was downloaded from, and cannot normally be paired to other Brains in your environment unless a new Brain location and SRT are configured.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**Physical Sensors**

* As discussed in the [automatic configuration scenarios](#automatic-configuration-scenarios) and [pairing overview](#pairing-overview) above, online physical Sensors can retrieve location and registration information from the Vectra cloud.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

### Manual Configuration Steps

To manually configure a Sensor with a Brain location or Sensor Registration Token (SRT) you must first access the command line interface (CLI) of the Sensor. For details on how to access the CLI of your vSensor, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for manual configuration details.</summary>

#### Showing and Setting Brain Location

Use the `show brain` and `set brain` commands as shown below:

```
vscli > show brain
Brain IP: 172.16.12.10

vscli > set brain --help
Usage: set brain < ip_or_hostname >

  Set brain to the specified IP or hostname

Options:
  -h, --help  Show this message and exit.

vscli > set brain 172.16.12.12
Brain IP: 172.16.12.12
Set Brain IP: success
```

#### Showing and Setting the SRT

Use the show registration-token and set registration-token commands as shown below:

```
vscli > show registration-token --help
Usage: show registration-token

  Show current registration token

Options:
  -h, --help  Show this message and exit.

vscli > show registration-token
Output:
    Token: dtkwwbctkzfmppjblchgthkgjcvhcxnv

vscli > set registration-token --help
Usage: set registration-token < token >

  Set current registration token

Options:
  -h, --help  Show this message and exit.

vscli > set registration-token nvxfrxzknbchrbztyvlchkbnhwlxhdvz
Unpair: successful
Registration token has been set
```

</details>

## Pairing Sensors

### Communications Requirements

In order to pair with a Brain, per the [firewall requirements](/deployment/getting-started/firewall-requirements), Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

### Pairing Timing Expectations

Some processes related to pairing happen on regular intervals and are not immediate. It is normal for a Sensor to take a few minutes to show up in the Vectra UI as **Available** and move through different pairing states. For example, check in to the Vectra cloud happens every 5 minutes for a physical Sensor that has not yet communicated with the Vectra cloud. Other processes related to pairing can also take some time.

If a Sensor does not appear in the Brain *Configuration → Data Sources → Network → Sensors* page, check that the vSensor has IP connectivity and that TCP port 443 (HTTPS) is permitted through your firewall.

If pairing has begun, i.e. you see **Pairing** in the UI or CLI, and pairing has not completed in 5 to 10 minutes, the most likely scenario is that firewall rules are not allowing TCP/22 (SSH) from the Sensor to the Brain. In such a scenario, you should click the cancel pairing button in the UI, which will reset the Sensor status to **Available**, address connectivity issues, and reinitiate the pairing process.

For more near real-time status than what is shown in the UI served from Vectra's cloud in RUX deployments, or the UI served locally from your Brain in QUX deployments, the `show sensors` command can be used at the CLI of the Brain.

### Sensor Pairing States and Status

Admins can see the list of Sensors in the Vectra UI under *Configuration* → *Data Sources → Network → Sensors.* The Brain will attempt to query the Vectra cloud at <https://update2.vectranetworks.com> as the page loads.

**Sensor Pairing States**

* Available
  * Physical Sensor has contacted the Vectra cloud and Brain successfully and is available for pairing.
  * Physical Sensor with valid SRT has announced itself successfully to the Brain and is available for Pairing.
  * vSensor (cloud or traditional hypervisor deployed) has announced itself successfully to the Brain and is available for pairing.
* Pairing
  * A pairing request has been sent to the Vectra cloud from the Brain for online physical Sensors.
  * Any other Sensor type with a valid SRT is in the process of pairing.
* Paired
  * A Sensor has successfully paired with the Brain.
* Unpairing
  * A Sensor is in the process of unpairing.

**Sensor Status**

* Connected
* Not Connected
* Unpairing

<figure><img src="/files/2jZubc39RMt1py9uWFj9" alt=""><figcaption></figcaption></figure>

Pairing states and the list of Sensors can also been at the CLI of your Brain appliance. For details on how to access the CLI of your Brain, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for example using the <code>show sensors</code> CLI command.</summary>

```
vscli > show sensors -h
Usage: show sensors [ filter ]

  Show associated sensors

  FILTER is an optional query string to limit the results displayed. By
  default, all columns are searched but the query can be limited by using the
  format <column name>:<query>

Options:
  -h, --help  Show this message and exit.
v
scli > show sensors
Name                             |Ip            |Pairing  |Location              |Version    |Last Seen          |Luid    |Serial Number
V2b2db52176334e968c27a5d2a33720c0 192.168.54.201 available None                   9.0.0-18-57 2025-10-22 12:50:05 53a71kvk V2b2db52176334e968c27a5d2a33720c0
TB - Traffic Mirroring            192.168.55.239 paired    TB-Traffic Mirror Test 9.4.3-1-32  2026-01-29 19:37:09 qx70f0wr V11dd189d440e4e93b6bd6b5f5d1d484b
```

</details>

### Sensor Registration Token Pairing

<figure><img src="/files/mvpnCMNae5dh5GXjfTp2" alt=""><figcaption></figcaption></figure>

When a Sensor is configured with a valid [Sensor Registration Token (SRT)](#sensor-registration-token-srt), once a Sensor of any type is able to reach the Brain (see [communications requirements](#communications-requirements)), and shows as **Available,** click the pairing button as shown in the above screenshot to open a pairing dialog box.

<figure><img src="/files/Waq8H2P6yfgI2d7U6Tvy" alt="" width="375"><figcaption></figcaption></figure>

Click **Pair Sensor** to begin pairing. The Sensor will move through **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

### Auto Pairing

If [auto pairing](#virtual-sensor-automatic-pairing) is enabled, and the Sensor has a valid Sensor Registration Token, once the Brain sees the Sensor as available, pairing will be completed automatically.

Once a Brain sees the Sensor as **Availabl**e, Sensors will move through **Available**, **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

{% hint style="info" %}
**Please Note:**

* Physical appliances cannot engage in auto-pairing immediately out of the box. They must first be configured with a valid Sensor Registration Token (SRT).
* If a physical appliance shows as **Available** for pairing, and the admin initiates pairing, pairing will complete automatically if online pairing is possible.
  {% endhint %}

### Online Pairing (Physical Sensors Only)

<figure><img src="/files/mvpnCMNae5dh5GXjfTp2" alt=""><figcaption><p>Screenshot is from a vSensor. The <strong>TYPE</strong> would show the model number for physical appliances.</p></figcaption></figure>

Out of the box, physical Sensors will attempt to reach out to the Vectra cloud once they are online.

Once a physical Sensor/Stream appliance shows as **Available** in your Vectra UI, click the pairing button as shown in the above screenshot to open a pairing dialog box.

{% hint style="info" %}
When a physical appliance cannot reach Vectra's updater service because a proxy is required in the customer’s environment to reach outside destinations, the `set brain` command should be used to set the Brain IP or hostname that the Sensor or Stream appliance will attempt to pair with. Sensors do not support proxy configuration.
{% endhint %}

You will then be presented with a dialog box where you can start the pairing process.

* Click the **Pair Sensor** button to begin pairing.
* The Brain will update the Vectra Cloud with its MGT1 IP address or hostname (depending on if you have selected to [pair by hostname or IP](#pair-using-the-detect-brain) and posts a request for the Sensor to initiate the pairing process.
* If the Sensor has access to the Vectra Cloud, upon its next check in (every 5 min), it will now retrieve the location of the Brain from the Vectra cloud and attempt to connect to the Brain.
* If the Sensor does not have access to the Vectra Cloud or is unable to contact the Brain (e.g. the Sensor cannot reach the Brain's IP address in a NAT or proxy environment), the Sensor should be manually instructed to pair with the Brain from the Sensor CLI using the `set brain` command using an IP address for the Brain's MGT1 that will reach the Brain's NAT address from the Sensor or hostname of the Brain.

The Sensor will move through **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

**Online Pairing Summary:**

Appliance serial numbers and keying information are associated with customer accounts during provisioning. Under normal circumstances, if both the Brain and physical Sensor or Stream can reach Vectra’s updater service at `https://update2.vectranetworks.com`, the following high-level diagram explains the standard pairing process:

![](/files/vEenppEFOpLU964W9XJR)

### Pairing in an Air-Gapped Environment vs Offline Pairing

While true air gap environments are typically relatively rare, customers may still need to deploy in environments where none of the components in your deployment can reach the Vectra cloud. A cloud deployed vSensor that can't reach the internet from its VPC could still be consided an air gap deployment from that perspective.

#### **Air-Gapped Pairing**

**Physical Appliances**

While Vectra NDR and Stream can function in full air gapped environments, this does mean that a Sensor Registration Token (SRT) will be required to pair physical Sensors.

**Traditional Hypervisor vSensors**

Traditional hypervisor based vSensors are not impacted because the virtual machine image downloaded from the Brain comes with the keying information needed to allow vSensors to communicate to the Brain. As long as the vSensors can contact the Brain they can pair automatically or via user initiated pairing. They can also use a SRT to authenticate pairing.

**Cloud vSensors**

Similarly, cloud vSensors are required to use a SRT for pairing and only need to be able to contact the Brain to pair and do not need to talk to the Vectra cloud.

**To pair in an air gap environment:**

* Retrieve or generate a current [Sensor Registration Token](#sensor-registration-token-srt).
* Perform the `set registration-token <token>` command at the Sensor CLI.
* Finally perform the `set brain <IP or Hostname>` command at the Sensor CLI.
  * `set brain` should also delete existing brain location information but if there are any issues, the `del brain` command at the Sensor CLI can be used.
* The Sensor should become **Available** for pairing on the Brain.

#### **Offline Pairing (Physical Sensors Only)**

In offline pairing scenarios, if a Sensor is behind a proxy or firewall and cannot connect to the Vectra cloud, then a Sensor Registration Token (SRT) will be required to complete pairing.

The **Pair Sensor** button can be used to begin pairing. A valid Sensor Registration Token (SRT) must be configured. You must also configure the Brain location with the `set brain` command at the CLI of the Sensor.

## Additional Pairing Guidance

### Stream Appliance "Sensor" Pairing Details

As discussed in [about Sensor and Stream pairing](#about-sensor-and-stream-pairing), Stream devices pair in the same manner as Sensor devices. There are some post pairing differences:

A Stream appliance does not show in the Vectra UI on the normal Sensor management screen located at *Configuration → Data Sources → Network → Sensors*. Pairing status for a Stream appliance is available in *Configuration > Setup > Stream* in the *Pairing Status* area:

<figure><img src="/files/CnwbT7Q5NvuMIX5iPZL2" alt="" width="563"><figcaption></figcaption></figure>

A Stream appliance will show its' status if you use the `show sensors` command at the CLI.

### Post Pairing Guidance

Once paired, Sensors will attempt to synchronize software versions by downloading the latest update from the Brain and immediately applying it. The Sensor may become temporarily unavailable while this update is applied. This should only take a few minutes to complete.

Certain vSensor CLI functions and traffic functions will become available only after the vSensor has fully updated. Depending on the specific version of the vSensor, you may see errors or warnings when running CLI functions during the period of time when the vSensor is still updating.

Sensors can be renamed or have their location labeled as desired by clicking on the pencil icon <img src="/files/A2Jl6Dr98rpqroDTzDga" alt="" data-size="line">on the right of the vSensor and editing the details.

### Pairing to New or Changed Brains

#### Pairing to Brain With Changed Location

If the Brain location must be changed there are two processes that can be used to associated existing Sensors with a new Brain:

**Preferred Method:**

* Change the Brain IP address or hostname.
* Redirect all Sensors to the new Brain location using the `set brain` command at the CLI of the Sensor.
  * Previously paired Sensors can simply be redirected because the Brain already has the required registration information for these Sensors.
    * This is also the same for new or different Brains restored from Backups.
  * Unpaired Sensors can use the Sensor Registration Token if needed.
    * For example: The new Brain isn’t restored from backup, is air-gapped, etc

**Alternate Method:**

You can also unpair all Sensors, change the Brain location (hostname or IP address), and then pair all Sensors again. This could cause some buffered data on the Sensors to be lost.

#### Pairing to a Different Brain

* If you have a Brain that will not be restored from backup that you wish to pair an existing Sensor to, this is possible via the use of a Sensor Registration Token.
  * Retrieve or generate a current [Sensor Registration Token](#sensor-registration-token-srt).
  * Perform the `set registration-token <token>` command at the Sensor CLI.
  * Finally perform the `set brain <IP or Hostname>` command at the Sensor CLI.
    * `set brain` should also delete existing brain location information but if there are any issues, the `del brain` command at the Sensor CLI can be used.
  * The Sensor should become **Available** for pairing on the new Brain and will pair automatically if [auto pairing](#virtual-sensor-automatic-pairing) is enabled.

#### Terminating Existing Sensor / Brain Tunnels

In all cases, existing tunnels have to terminate to re-establish connection to a new Brain. This can be accomplished a few different ways.

* Naturally, because the original Brain is no longer reachable due to firewall change, hardware or software failure, etc.
* Using the `set brain` command at the CLI will terminate an existing tunnel and attempt to start pairing with a new Brain.
  * `del brain` can be used to break the tunnel but not set a new Brain location.
* In normal operation, the Sensor can simply be unpaired from its existing Brain. To use the **Unpair** option, the Brain must be connected to the Vectra Cloud and the Sensor must be powered on with an active tunnel to the original Brain.
  * Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors*, click on the Sensor you wish to unpair and click on the **Unpair** button.
  * After unpairing which could take a few minutes, the status of the Sensor should change to **Available**.

<figure><img src="/files/zVRwJeWDyoWKyYcJV4cy" alt=""><figcaption></figcaption></figure>

* Using the **Force Unpair** option in your Vectra UI for the target Sensor.
  * This will unpair the Sensor from the original Brain and when the Sensor attempts communication to the original Brain the tunnel will not function.
  * **Force Unpair** is the same as deleting for a vSensor. You cannot delete a physical Sensor (talk to Vectra Support if this is required).


# Directing traffic to AWS vSensor

Configure AWS VPC Traffic Mirroring to send EC2 traffic to a vSensor (mirror filters, mirror targets, and mirror sessions).

## Traffic Mirroring Configuration

Traffic mirroring can be accomplished using AWS VPC Traffic Mirroring or using 3<sup>rd</sup> party packet brokers using VXLAN. 3<sup>rd</sup> party packet brokers are not covered in this guide. Please work with that vendor and ensure that traffic is directed to the Sensor over UDP 4789.

AWS Traffic Mirror documentation is available here:

* [What is traffic mirroring](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)

VPC Traffic Mirror functionality was release by Amazon Web Services released in June 2019. The VPC Traffic Mirror function emulates a more traditional SPAN or TAP that companies have been using on-premises for decades, now in the cloud. The traffic is delivered encapsulated in VXLAN packets delivered by Amazon Web Services directly to the TMT or Traffic Mirror Target over UDP port 4789. Additional information about VPC Traffic Mirroring is available here:

* [Using vpc traffic mirroring to monitor and secure your AWS infrastructure](https://aws.amazon.com/blogs/networking-and-content-delivery/using-vpc-traffic-mirroring-to-monitor-and-secure-your-aws-infrastructure/)

There are a few caveats with the current implementation that we should discuss. Some points to keep in mind:

* Not all Nitro based instances are supported as a traffic mirror source:
  * <https://aws.amazon.com/about-aws/whats-new/2021/02/amazon-vpc-traffic-mirroring-supported-select-non-nitro-instance-types/>
* Traffic mirrors need to be deployed manually, or they can be automated:
  * As a part of your deployment tooling, supported by both CloudFormation and Terraform.
  * They can be added as part of a lambda automation that is triggered by EC2 events:
    * <https://github.com/aws-samples/aws-vpc-traffic-mirroring-source-automation>
  * They can be added by some Python code:
    * <https://github.com/vectranetworks/AWS-Traffic-Mirroring-Session-Manager>
* A packet can only be delivered once.
  * This means that if there is more than one packet mirror destination, a packet can only be delivered to ONE destination.
  * That is determined by the session number setting in the mirror session itself.
  * Lower values take precedence.
  * <https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-session.html>

To configure the VPC traffic mirror, you need to setup three different objects within AWS. Our recommendation is that you configure them in the following order:

1. Create a single Mirror Filter.
2. Create a Mirror Target for each Sensor or network load balancer you have deployed.
3. Create a Mirror Session for each workload you would like to monitor.

### Create a Mirror Filter

The VPC Traffic Mirror Filter will determine what packets from the source workload will be mirrored to the Traffic Mirror Target.

To create a Mirror Filter in one of your AWS accounts, select VPC, then Mirror Filters under Traffic Mirroring. You can provide a Name Description for the filter. The logic of the filter is most important. We recommend you check amazon-dns under Network Services – optional. Then create an inbound and outbound rule with these values.

* Rule action – accept
* Protocol – All Protocols
* Source CIDR – 0.0.0.0/0
* Destination CIDR – 0.0.0.0/0

This one Mirror Filter can be used for all the mirrors in your deployment.

Click create to commit this Traffic Filter. This filter will copy all the traffic from the source ENI to the TMT.

### Creating a Mirror Target

Mirror Targets need to be created for each Sensor you deploy. The Mirror Target, once created, will create a TMT or a Traffic Mirror Target object. The TMT will then be used for each Mirror Session created.

If we look at an AWS vSensor you will see there are two ENIs on each one.

On the Vectra AWS vSensor each interface serves the following purpose:

| **Interface** | **Purpose**          | **Default Security Group**     |
| ------------- | -------------------- | ------------------------------ |
| eth0          | Capture Interface    | Sensor-TrafficSecurityGroup    |
| eth1          | Management Interface | Sensor-ManagementSecurityGroup |

Create the Mirror Target using the Name and Description of your choice and point it to either the Network Interface or Network Load Balancer of your Sensor.

### Creating a Mirror Session

Traffic Mirror Sessions are what instructs AWS to actually send traffic from the instances to the configured Mirror Target.

* Select a **Name** and **Description**.
* Select a **Mirror Source** (ENI of the instance that will send its traffic).
* Select the **Mirror Target** you have created for your Sensor.
* Session can just be set to **1** and all other options left blank.
* Select the Mirror Filter you created earlier and then click **Create**.


# AWS vSensor FAQs

Common questions and troubleshooting for AWS vSensor deployments, including regional limits, validation, updates, and service quotas.

### Supported Regions for Vectra AWS vSensor Deployment

| Region Name               | Region Code    |
| ------------------------- | -------------- |
| Africa (Cape Town)        | af-south-1     |
| Asia Pacific (Hong Kong)  | ap-east-1      |
| Asia Pacific (Tokyo)      | ap-northeast-1 |
| Asia Pacific (Seoul)      | ap-northeast-2 |
| Asia Pacific (Osaka)      | ap-northeast-3 |
| Asia Pacific (Mumbai)     | ap-south-1     |
| Asia Pacific (Hyderabad)  | ap-south-2     |
| Asia Pacific (Singapore)  | ap-southeast-1 |
| Asia Pacific (Sydney)     | ap-southeast-2 |
| Asia Pacific (Jakarta)    | ap-southeast-3 |
| Asia Pacific (Melbourne)  | ap-southeast-4 |
| Canada (Central)          | ca-central-1   |
| Canada West (Calgary)     | ca-west-1      |
| Europe (Frankfurt)        | eu-central-1   |
| Europe (Zurich)           | eu-central-2   |
| Europe (Stockholm)        | eu-north-1     |
| Europe (Milan)            | eu-south-1     |
| Europe (Spain)            | eu-south-2     |
| Europe (Ireland)          | eu-west-1      |
| Europe (London)           | eu-west-2      |
| Europe (Paris)            | eu-west-3      |
| Israel (Tel Aviv)         | il-central-1   |
| Middle East (UAE)         | me-central-1   |
| Middle East (Bahrain)     | me-south-1     |
| South America (Sao Paulo) | sa-east-1      |
| US East (N. Virginia)     | us-east-1      |
| US East (Ohio)            | us-east-2      |
| AWS GovCloud (US-East)    | us-gov-east-1  |
| AWS GovCloud (US-West)    | us-gov-west-1  |
| US West (N. California)   | us-west-1      |
| US West (Oregon)          | us-west-2      |

### What should I do if the requested instance type is not supported in my region?

* Not every AWS region will have all Vectra supported instance types available. If you encounter this error, you may need to choose another supported instance type or region to deploy into. For additional information please see the following AWS documentation:
* <https://docs.aws.amazon.com/autoscaling/ec2/userguide/ts-as-instancelaunchfailure.html#ts-as-instancelaunchfailure-3>

### What should I do if traffic mirroring is not available in my region?

* AWS may not have Traffic Mirroring available in every region. Please check at the below URL under **Network Analysis** to ensure traffic mirroring is available in the region of your choice:
* <https://aws.amazon.com/vpc/pricing/>
* If it is not available, you may need to work with a 3<sup>rd</sup> party packet broker to direct traffic to your Vectra Sensor(s).

### How do I create and manage my Amazon EC2 key pairs?

* Please refer to this AWS article for how to create and manage your Amazon EC2 key pairs:
* <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html>

### How to I validate that my vSensor is deployed correctly?

* From the Vectra Brain, once the vSensor has been paired, the vSensor will show as **Forwarding** from the *Configuration → COVERAGE → Data Sources → Network → Sensors* page.

### How do I update a deployed vSensor?

* vSensors are updated automatically from the Vectra Brain.

### How do I repair a broken deployment?

* Please follow these steps:
  1. Delete the vSensor.
  2. Re-deploy using the AWS CloudFormation template.
  3. Validate that the vSensor is working as expected.
* If you continue to have issues, please contact Vectra Support for assistance.

### How do I rotate my Amazon EC2 key pairs?

* Please refer to the "Add or replace a key pair for your instance" section of the following AWS article on managing Amazon EC2 key pairs:

<https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html>

### How do I manage my AWS Service limits?

* If you already have a number of resources deployed within your AWS footprint, then it's possible that during deployment you will encounter an AWS service limit. If you encounter such a limit, please refer to the following AWS document on how to request an increase to your service limits:
* <https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html>

### How do I validate that traffic is being seen by my AWS Sensor?

* To see that packets are being receive by the traffic interface, use SSH to login to the CLI of the Sensor as the `vectra` user and use the `show traffic stats` command.
  * Some guidance was shared in the [SSH Key Pair](/deployment/ndr-virtual-cloud-appliances/aws-vsensor/introduction-and-requirements#ssh-key-pair) section.
  * Run the `show traffic stats` several times to see that packet counts are increasing.

![](/files/xErdp0kfoDeKZyJe6Zsv)

* In the Vectra UI if you navigate to *Network Stats → Ingested Traffic*, you can see the traffic graph for your Sensor.
  * For this graph to display, there must be at least 1 Mbps of traffic being captured.
  * Once traffic capture begins, it will take a few minutes for this graph to be populated. Use the CLI of the Sensor as shown above to validate that packets are flowing first.

![](/files/493933fbbf128ce0e25f69aaa5c2f8b0e79197fa)

* Please see the following Vectra support article for recommendations on network traffic that should be examined and excluded from analysis:
  * [Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations)
* After sending traffic to your Sensors, it is a best practice to validate that the traffic observed meets quality standards required for accurate detection and processing. Vectra’s Enhanced Network Traffic Validation feature provides alarms and metrics that can be used to validate the quality of your traffic. Please see the following Vectra support article for details:
  * [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv)
* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# AWS Security Hub integration (QUX only)

Set up AWS Security Hub integration for Vectra QUX deployments.

## Introduction

AWS Security Hub is a service that provides a comprehensive view of high-priority security alerts and compliance status across all AWS accounts. These alerts may be originated by other AWS services like Amazon GuardDuty, Amazon Macie or Amazon Inspector, or by partner solutions like Vectra NDR (formerly Detect for Network).

This document provides the steps necessary to enable this integration in your Vectra deployment that uses the Quadrant UX. AWS Security Hub integration is not available in the Respond UX. If you are unsure of your deployment type, please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux).

## Security Hub Publishing Details

### Schema for Vectra-generated Security Hub findings

This is also attached to the bottom of this article.

```
{
  "SchemaVersion": "Vectra release-based",
  "Id": "Vectra Brain identifier",
  "ProductArn": "AWS ARN including AWS account ID",
  "GeneratorId": "host",
  "AwsAccountId": "AWS account ID",
  "Types": [
    "Unusual Behaviors/Network Flow"
  ],
  "CreatedAt": "First host alert timestamp",
  "UpdatedAt": "Latest host alert timestamp",
  "Severity": {
    "Product": Normalized Score divided by 10,
    "Normalized": Normalized score for Vectra host based on Threat and Certainty
  },
  "Confidence": Certainty score of Vectra Host
  "Criticality": Threat score of Vectra Host,
  "Title": "Vectra Cognito Detect: hostID - thresholds",
  "Description": "Cognito host alert for hostID",
  "SourceUrl": "URL to Vectra Host in the Cognito UI �" hostname or vectra.brain",
  "ProductFields": {
    "aws/securityhub/FindingId": " Security Hub finding ID",
    "aws/securityhub/SeverityLabel": "Mapping",
    "aws/securityhub/ProductName": "Detect",
    "aws/securityhub/CompanyName": "Vectra"
  },
  "Resources": [
    {
      "Type": "AwsEc2Instance",
      "Id": "AWS Resource Name",
      "Details": {
        "Other": {
          "Hostname": "Vectra hostID"
        }
      }
    }
  ],
  "WorkflowState": "New",
  "RecordState": "Active"
}
```

* The score, along with other details are published in the AWS Security Finding Format (ASFF), a sample of which is above and attached to this article.
* The Vectra Brain publishes Host scores to AWS Security Hub when a Host’s threat and certainty score exceed a customer-defined threshold.
  * The scoring for a Host is automatically updated when there are changes.
* The Vectra Brain posts findings to the AWS Security Hub only for AWS Hosts.
  * On-premise Hosts that are monitored by your Vectra Brain do not have findings posted.

### Severity Mapping

The severity mapping that Vectra reports to Security Hub is derived as a function of Vectra’s threat score and certainty score for the Host.

| **Vectra Threat Score** | **Vectra Certainty Score** | **AWS Security Hub Severity** |
| :---------------------: | :------------------------: | :---------------------------: |
|            0            |              0             |         Informational         |
|           < 50          |            < 50            |              Low              |
|          <= 50          |            > 50            |             Medium            |
|           > 50          |            <= 50           |              High             |
|           > 50          |            > 50            |            Critical           |

## Prerequisites

### AWS HostID Integration

Integration with Security Hub requires that [AWS HostID integration](/configuration/setup/external-connectors/aws-hostid-integration) is configured in your Brain appliance. This requires that IAM is configured in AWS to enable retrieval of Host information. IAM configuration is also required to publish findings to Security Hub. If you are using a Vectra Brain deployed in AWS, you may have already done the HostID integration with instructions in the following guides:

* [AWS HostID Integration](/configuration/setup/external-connectors/aws-hostid-integration)
* [AWS Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-brain)
* [AWS Sensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-vsensor)

Customers can also monitor AWS Hosts with an on-premise Brain. If you are using an on-premise physical or virtual Brain appliance, please follow the steps in [AWS HostID Integration](/configuration/setup/external-connectors/aws-hostid-integration) to enable HostID integration before continuing on with Security Hub integration configuration.

AWS IAM Users, Roles, and Policies allow Vectra to make requests against the AWS management API on your behalf. Vectra supplies CloudFormation templates to allow easy creation of these users, or you can create them yourself and apply your own policy to them.

## Firewall Requirements

For **AWS Security Hub integration only**, the Vectra Brain needs **outbound HTTPS/TCP 443** to these AWS API endpoints:

| Purpose                                      | AWS endpoints to allow               |
| -------------------------------------------- | ------------------------------------ |
| Caller identity / account validation         | `sts.<region>.amazonaws.com`         |
| IAM permission simulation                    | `iam.amazonaws.com`                  |
| Security Hub findings import / update / read | `securityhub.<region>.amazonaws.com` |

**Summary:**

Allow outbound TCP/443 from Vectra Brain to AWS STS, IAM, and Security Hub API endpoints for the AWS regions being monitored.

The Security Hub template references these AWS actions: `sts:GetCallerIdentity`, `iam:SimulatePrincipalPolicy`, and Security Hub `BatchImportFindings`, `BatchUpdateFindings`, and `GetFindings`.

### Security Hub IAM User

For Security Hub integration the user that should be created is called: `VectraCognitoSecurityHubv1`.

To automatically create this user, import the Vectra `SecurityHubTemplate.yml` CloudFormation template into CloudFormation and it will be created with a restrictive policy applied. The Access key can be created in IAM/User/Security. The access key will need to be added to the Vectra UI.

IAM users can also be manually added using the template as a source to understand the required permissions.

Create the following IAM user to allow the Brain to publish Host scores to Security Hub as Findings.

```
AWSTemplateFormatVersion: '2010-09-09'
Description: Vectra Security Hub User version 1.2
Resources:
  user:
    Properties:
      Policies:
        - PolicyDocument:
            Statement:
              - Action:
                  - securityhub:BatchImportFindings
                  - securityhub:GetFindings
                  - securityhub:UpdateFindings
                Effect: Allow
                Resource:
                  - '*'
                Sid: CreateDeleteAndRetrieveSecurityHubFindings
              - Action:
                  - sts:GetCallerIdentity
                  - iam:SimulatePrincipalPolicy
                  - securityhub:DescribeProducts
                  - securityhub:ListEnabledProductsForImport
                Effect: Allow
                Resource:
                  - '*'
                Sid: GetCallerIdentity
              - Action:
                  - securityhub:EnableImportFindingsForProduct
                  - securityhub:DisableImportFindingsForProduct
                Effect: Allow
                Resource:
                  - !Join
                    - ''
                    - - 'arn:'
                      - !Ref 'AWS::Partition'
                      - ':securityhub:*:'
                      - !Ref 'AWS::AccountId'
                      - :hub/default
                Sid: EnableVectraProduct
            Version: '2012-10-17'
          PolicyName: vectra_security_hub_permissions
      UserName: VectraCognitoSecurityHubv1
    Type: AWS::IAM::User
```

## Configuration

* Browse to the Identity and Access Management service.
* Generate access key ID and secret access key for the `VectraCognitoCloudwatchLogsv1` user created as part of the pre-requisite.
  * This is done similarly to how the keys for [AWS HostID integration](/configuration/setup/external-connectors/aws-hostid-integration) were created.
* Navigate on the Vectra UI to *Configuration → RESPONSE → Notifications > AWS Security Hub.*
* Click **Edit**.

![](/files/44b2a3eaabac38e907e7f11f587a12e1a626e72f)

* Enter the credentials and select the thresholds for which host score Findings should be sent to Security Hub.
* Click **Save**.

## Example Finding

<figure><img src="/files/qc2Wv0JzIZZzdOz6lISJ" alt="" width="426"><figcaption></figcaption></figure>

## Locating Findings in AWS

Findings on AWS can be located using the Finding ID. Host alerts are sent using a prefix that includes the serial number of the Vectra Brain. This field is searchable as Id within the AWS console. Additionally, the finding will contain a SourceURL that includes the hostname, as configured in *Configuration → COVERAGE → Data Sources → Network → Brain Setup > Brain*. If no hostname is configured for notifications, SourceURL will use `vectra.brain`.

## Attachments

**SecurityHubTemplate.yml**

* AWS CloudFormation Template used for integration with AWS Security Hub
* This file can also be downloaded from your Brain after deployment at the following location:
  * https\://\<brain\_hostname\_or\_IP>/resources/SecurityHubTemplate.yaml/serve\_file

{% file src="/files/H2NeZ0tXa6IjOc8s9Nep" %}

**Vectra AWS Security Hub Schema.json**

* The schema that Vectra uses for publishing to AWS Security Hub is also attached to this article.

{% file src="/files/55komWK3KKxAAcTLBgtb" %}

* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# AWS best practices

AWS configuration and operational best practices for Vectra appliances and integrations.

## Vectra for AWS

Various Public Cloud providers are offering technologies that allow Security Architects to deploy Vectra® into the public cloud. However, architecting solutions like Vectra in the cloud are very different from architecting and deploying an on-premises version of the solution. This paper will look at some of the issues and challenges you may encounter as you are building your Vectra deployment.

## Differences Between On-Premises and the Cloud

The Vectra Brain itself functions similarly when deployed on-premises and in the Public IaaS Cloud. However, collection of the packet data required is quite different. When deployed on-premises, Vectra uses physical and/or virtual Sensors to collect packet data from network taps or spans. In the Public Cloud Vectra can’t use physical taps and spans as they are not available. Instead, the options are:

* Cloud Virtual Taps
* Cloud Workload Agents
* Cloud Packet Brokers

By utilizing one or more of these technologies, it’s easy to extend the reach of Vectra from an on-premises deployment into a hybrid deployment that covers the premises as well as one or more Public Cloud providers.

## Developing a Deployment Architecture

When determining how to deploy Vectra into your organization’s AWS environment, we need to evaluate four major items:

1. Sizing and placement of the Brain
2. Sizing, number, and placement of the Sensors
3. Establishing and maintaining the traffic mirrors
4. Integration with Amazon AWS Services

Let’s look at each of these aspects in a bit more detail.

## Sizing and Placement of the Brain

Within a Vectra deployment, the main system that manages the complete operation of the solution is called the Brain. The Brain consumes the metadata that the Sensors generate, produces Detections from that metadata, and serves the UI in Quadrant UX deployments, etc. In Respond UX deployments, the UI is served from Vectra’s cloud but still communicates with the Brain.

Generally, when architecting a solution, consideration is needed around the Brain placement and connectivity first. The Brain requires that it be protected, as any other security related system, in your environment. However, Sensors require access to the Brain to upload collected metadata. The required connectivity is HTTPS and SSH from the Sensors to the Brain.

From a connectivity perspective, the Brain requires several types of access to be allowed. First from the Sensors to the Brain:

* SSH - FROM the Sensor TO the Brain on TCP/22
* HTTPS - FROM the Sensor TO the Brain on TCP/443

Connections are established from the Sensor to the Brain but data flows both ways and for troubleshooting reasons it is recommended to enable SSH and HTTPs bidirectionally between the Sensor and the Brain.

Additionally, we would want to allow:

* Access to the Internet to download updates and share health statistics, etc.
  * [https://update2.vectranetworks.com](https://update2.vectranetworks.com/)
  * [https://api.vectranetworks.com](https://api.vectranetworks.com/)
* UI access for the security team
  * HTTP to the Brain (only needed if a redirect to HTTPS is desired)
  * HTTPS to the Brain (for GUI access in Quadrant UX deployments only)
* API access between other tools and systems
  * HTTPS
* Access to the AWS Management Layer API
  * HTTPS

For full connectivity details for a complete deployment see: [Firewall requirements for Vectra appliances](/deployment/getting-started/firewall-requirements)

When determining what size Brain should be deployed, this decision should be based on the amount of aggregate traffic that will be captured by the Brain’s paired Sensors that will then be sent as metadata to the Brain for analysis. Vectra currently offers three different sizes of Brains in AWS:

* 2 Gbps aggregate traffic / 50K IP addresses max, 15 Sensors max - r5d.2xlarge
* 5 Gbps aggregate traffic / 50K IP addresses max, 25 Sensors max - r5d.4xlarge
* 15 Gbps aggregate traffic / 150K IP addresses max, 100 Sensors max - r5d.8xlarge
* 50 Gbps aggregate traffic / 500K IP addresses max, 500 Sensors max - r5.16xlarge (v8.0 and later)

We will explore placement in more depth below.

## Sizing and Placement of Sensors

While only a single Brain is generally deployed (backup Brains or multiple Brains feeding a SIEM are exceptions), multiple Sensors in a variety of locations may be required to provide complete coverage. Sensors are available in an assortment of forms such as physical, virtual (VMware, Hyper-V, KVM, and Nutanix), and cloud (AWS, Azure, and GCP). All these Sensors can be combined in any way required to provide complete coverage, and all these Sensors can be paired to either an on-premises or a cloud Brain.

Generally, the decision on adding an additional cloud Sensor – or not – depends on several points:

* The number of remaining traffic mirror sessions on the existing Sensors.
* The quantity of mirror data each workload is generating.
* The amount of data transferred (data transfer charges) vs. cost of another Sensor.

Let’s look at these in a little more depth. The number of remaining traffic mirror sessions relates to the existing soft limits that are in place. The limit is based on the destination type for the mirror packets.

| **Traffic Mirror Destination**  | **Max Session Limit** |
| ------------------------------- | --------------------- |
| Standard Non-Dedicated Instance | 10 Sessions           |
| Dedicated Instance              | 100 Sessions          |
| Network Load Balancer           | Unlimited             |

AWS Sensors are available in a variety of sizes:

* r5.large / r5n.large – 1 Gbps
* r5.xlarge / r5n.xlarge – 2 Gbps
* r5.2xlarge / r5n.2xlarge – 4 Gbps
* r5.4xlarge / r5n.4xlarge – 8 Gbps
* c5n.18xlarge – up to \~10 Gbps (Contact your Vectra sales team for guidance)

The r5n instances guarantee networking performance and as a result it is recommended, but may not be available in all AWS regions. The r5 instances deliver the same performance without the guarantee. The c5n.18xlarge instance is a dedicated instance which also has the benefit of a 100 session traffic mirror destination limit vs the 10 session limit on the other instances. The c5n.18xlarge may not hit 10 Gbps in some scenarios as there are many factors to consider. Please engage your Vectra sales team for additional guidance for your specific network architecture.

Vectra periodically updates our AWS Marketplace listing to include additional instance choices. Please work with your Vectra account team for guidance on new options.

The Sensor instances can be deployed either stand alone, or with a Network Load Balancer (Vectra currently supports 1 Sensor per NLB). Currently, multiple Sensors cannot be deployed in a single Auto Scale Group.

Based on the chart above, and with an understanding of how much traffic an existing workload generates, we can make the decisions on spinning up additional Sensors vs. adding additional traffic mirrors to existing Sensors. We will discuss this in much greater depth below.

## Example Deployment Scenarios

### Single VPC

<figure><img src="/files/d5a9a3ceeb0e7197accbfb85776f870060e64951" alt="" width="563"><figcaption></figcaption></figure>

Architecture

* In this architecture we are looking at a single VPC as a standalone enclave that may be hosting a single application stack.
* The Brain is made publicly accessible since there is no other way to provide private access in this scenario.
  * The ENI of the Brain must be protected in this case using security groups/NACLS to limit access.
* The Brain could also be placed in the private subnet if there was another access method to allow access to the Brain UI, for example a VPN.
  * In this example there is a NAT gateway to allow outgoing connections from the Brain.
* The Sensor is deployed to the Private subnet in this configuration as access is never required from the outside.
  * This allows us to protect the appliance from attack.
* All Traffic Mirrors are pointed at ETH0 of the Sensor.
  * This ENI is configured to allow incoming VXLAN.
* All Brain/Sensor interactions are sourced from ETH1 of the Sensor.
  * Configure a Security Group on that ENI that allows communications between the Brain and Sensor only.

Recommendations

* Ensure protection of your Brain appliance by creating automated backups to an S3 bucket or other destination.
* If the number of workloads is approaching the soft limits for traffic mirrors, you can add an NLB to this configuration to remove that limit.

Traffic Mirrors

* Since this is a small environment, it’s likely Cloud Engineers would choose to manually deploy the Traffic Mirrors manually in the environment.
  * To read more details, see Appendix A.
* As changes to an environment like this are likely small, maintaining the mirrors might be a manual operation going forward.

### Multi VPC

<figure><img src="/files/a3e3dfd2475c23370fe4b86defc7c0088e905b51" alt="" width="563"><figcaption></figcaption></figure>

#### Architecture

This is an expanded architecture from the example above. In this architecture, we added some more VPCs, some VPC Peering Connections and Routes to allow all the VPCs to communicate. However, we only added two Sensors to the four new VPCs:

* Based on an evaluation of the workloads running in all four new VPCs it was determined that new Sensors would be required in two of those VPCs. The decision criteria were:
  * The volume of traffic (approaching 3Gbps)
  * The large number of workloads in those VPCs
* Since the volume of traffic from the other two VPCs was very low, those workloads could be supported by the original Sensor.
* As the number of VPC Traffic Mirrors on the original Sensor increases, make sure that you do not attempt to pass the soft limits on Mirror Sessions.
  * If necessary, you can redeploy the original Sensor and add an NLB to remove that limit completely.
* More and more VPCs and Sensors can be added up to the maximum capacity of the selected Brain appliance.
  * If a larger Brain is needed, a shutdown, change to larger instance type, and start will work.

#### Recommendations

* In larger environments like this it’s likely there are other types of access to the environment, for example a client VPN.
  * If that is available, the first change is to take the Brain out of the public subnet and protect it in a private isolated subnet.
  * However, make sure the Brain has access to the internet via a NAT or other method.
* Sensors can continue to be added in this fashion up to a maximum number based on the Brain appliance deployed:
  * r5d.2xlarge total of 15 Sensors
  * r5d.4xlarge total of 25 Sensors
  * r5d.8xlarge total of 100 Sensors
  * r5.16xlarge total of 500 Sensors

#### Traffic Mirrors

* In larger environments like this, the velocity of change is much higher. Therefore, we will want to look at automation to help us make sure that workloads that require a Traffic Mirror have one.
* One simple option is Vectra’s AWS Traffic Mirroring Session Manager available from GitHub at <https://github.com/vectranetworks/AWS-Traffic-Mirroring-Session-Manager>
  * This is some simple Python that will allow Cloud Engineers to create all missing Traffic Mirrors with a single script.
  * It can be run anytime or run automatically to ensure that all workloads are covered.

### Multi Account

<figure><img src="/files/414abbd91ecd4630ca574fbca7d6b8bae01986f6" alt="" width="563"><figcaption></figcaption></figure>

#### Architecture

As an organization’s cloud journey progresses, they inevitably add more and more accounts. These are designed to reduce blast radius of an incident, increase security, and allow for easier cost allocation. Vectra can easily handle a multi account configuration.

As you combine multiple accounts to build a larger AWS footprint, you will use services like Organizations, Landing Zones, and the AWS Resource Access Manager. We will use the same services to extend Vectra to this larger environment.

* To support this multi-account structure, we will use the AWS Resource Access Manager to share out the Traffic Mirror Targets of the Sensors that will be deployed into the environment.
  * In this case in the Security Account. <https://docs.aws.amazon.com/vpc/latest/mirroring/cross-account-trafficmirroring-targets.html>
* To support an unlimited number of incoming Mirror Sessions, each Sensor will have a Network Load Balancer placed in front of it.
* AWS Config Custom Rules can be used to ensure that traffic mirrors are enabled on all workloads. <https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules.html>

#### Recommendations

At this level of Cloud use it’s safe to assume site to site VPN or Direct Connect use. Therefore, we can consider the use of a Physical and/or Cloud Brain based on requirements. This would allow us to build:

1. A configuration where we centralize all Cloud and on-premises metadata on a Cloud Brain
2. A configuration where we centralize all Cloud and on-premises metadata on an on-premises Brain.
3. A distributed solution where each environment is kept local to itself. In these cases, we will generally centralize on a SIEM or another log aggregator.

Traffic Mirrors

At this size of implementation, we need to look at full automation to ensure all workloads have the required Traffic Mirrors. Here we will use an AWS supplied Lambda to enforce this for us. The project is available for download from:

* <https://github.com/aws-samples/aws-vpc-traffic-mirroring-source-automation>

By deploying this lambda, you can monitor all EC2 Instance Launch Events and the Lambda will create the traffic mirror automatically.

### Multi Region

<figure><img src="/files/9025ca9a3ae12f9398e62bb5b43638f66f0e6746" alt=""><figcaption></figcaption></figure>

#### Architecture

As environments grow to cover larger and larger geographies, it’s going to be more difficult (and less efficient) to use a single Brain. You have a lot of freedom as to where to place each Brain within your architecture. Some things to think about are:

* Often from a Security and access perspective, it’s a good idea to use things like a Shared Services or Management VPC.
  * These are often used to allow access to larger pieces of the infrastructure.
* Sensors will need to be deployed to multiple AZs and VPCs within the region to support all the workloads.
* Keep costs of cross AZ data transfer charges in mind as you build out your infrastructure.
  * The data transfer between a Brain and Sensor is about 0.5% of the traffic captured by the Sensor

#### Recommendations

The larger your environment, the more you will want to use additional AWS integrations that Vectra offers. These include:

* AWS Management API – When Vectra is running on-premises the Sensors will capture “local” network objects.
  * Things like DHCP request and response packets, Client web browser cookies, Kerberos logins and other things that are generally NOT available to us in the Cloud.
  * These objects drive the Vectra Host ID protocol which is core to its operation.
  * To allow Host ID to function in the cloud we make ec2::Describe\* calls against the AWS API. These calls allow Vectra to collect identifying information about your workloads in the cloud. Things like:
    * Instance ID
    * Instance Type
    * Operating System
    * Subnet ID
    * Tags and more
* CloudWatch Logs – Our CloudWatch Logs integration allows Vectra to send all system audit and health log events into CloudWatch Logs.
  * Any issues can be remediated using CloudWatch Events and Lambda, Step Functions, SNS, SQS or other method.
* Security Hub – This integration allows Vectra to send Third Party Findings into AWS Security Hub.
  * These findings can then also generate actions. This is only available for Quadrant UX deployments.

#### Traffic Mirrors

At this scale, we can assume that this cloud is managed mostly / completely via tooling, and so should your Traffic Mirrors. Both AWS CloudFormation and [HashiCorp Terraform](https://www.hashicorp.com/products/terraform) support creating VPC Traffic Mirrors as part of system provisioning or updates.

### Hybrid Cloud

<figure><img src="/files/86b9b07102ce58a5201d9af07d61d128fe615485" alt="" width="563"><figcaption></figcaption></figure>

#### Architecture

This is the pinnacle of cloud architecture: an on-premises cloud combined with multiple public cloud providers, all driven by full automation. It’s hard to give any specific advice at this level of Public/Private Cloud. Everything that we have discussed previously remains valid. It comes down to understanding Vectra capabilities and limitations and building within those.

Please do not hesitate to contact us for additional assistance.

## Integrating with AWS Services

Vectra is writing an expanding list of integrations into Amazon Web Services itself. This allows us to more deeply integrate both solutions. We will explore four main topics below. Security Groups, IAM, CloudWatch, and Security Hub.

### Security Groups

When you deploy Vectra appliances with CloudFormation, each appliance will create some ENIs and possibly some security groups as well. Here are the defaults for all appliances:

| **Appliance** | **Name of Interface** | **Default Security Group Suffix** |
| ------------- | --------------------- | --------------------------------- |
| Vectra Brain  | eth0                  | MgtSecurityGroup                  |
| Vectra Sensor | eth0                  | TrafficSecurityGroup              |
| Vectra Sensor | eth1                  | MgtSecurityGroup                  |
| Vectra Stream | eth0                  | MgtSecurityGroup                  |

The full security group name is a combination of your CloudFormation stack name plus the suffix. For example, if you deploy a Brain and the stack name is test-stack the security group name will be ‘test-stack-mgtsecuritygroup’.

You can also supply the id of a security group that you would like the template to use. In that case simply replace the AWS::NoValue with the security group id i.e. ‘sg-0d58928f23e33f59d‘.

All default security groups that the CloudFormation templates build are blank. Therefore, no traffic will pass until we add some rules to the groups. Here are the recommended minimum rule sets for all appliances:

Brain Security Group Settings eth0 – Incoming – Minimum Required

| **Type** | **Protocol** | **Port Range** | **Source**                   |
| -------- | ------------ | -------------- | ---------------------------- |
| HTTP     | TCP          | 80             | All Users                    |
| HTTPS    | TCP          | 443            | All Users / Sensors / Stream |
| SSH      | TCP          | 22             | All Sensors / All Stream     |

Sensor Security Group Settings eth0 – Incoming – Minimum Required

| **Type**   | **Protocol** | **Port Range** | **Source** |
| ---------- | ------------ | -------------- | ---------- |
| Custom UDP | UDP          | 4789           | 0.0.0.0/0  |

Sensor Security Group Settings eth1 – Incoming – Minimum Required

| **Type** | **Protocol** | **Port Range** | **Source**  |
| -------- | ------------ | -------------- | ----------- |
| SSH      | TCP          | 22             | IP of Brain |

Stream Security Group Settings eth0 – Incoming – Minimum Required

| **Type** | **Protocol** | **Port Range** | **Source**  |
| -------- | ------------ | -------------- | ----------- |
| HTTP     | TCP          | 80             | IP of Brain |
| HTTPS    | TCP          | 443            | IP of Brain |
| SSH      | TCP          | 22             | IP of Brain |

We have not specified outgoing rules for the security groups, as we typically use the default of 0.0.0.0/0

### IAM – Users, Roles, and Policies

Adding AWS IAM users, roles, and policies enables additional context and integrations to further enable analysts. The below integrations can technically be done from any Brain to AWS (not only from those Brains deployed in AWS). Customers may have a Brains deployed elsewhere that also monitor Hosts deployed in AWS. Security Hub publishing will only publish Host scores involving AWS workloads. CloudWatch health and audit logs are typically only desired in AWS for customers whose Brain is deployed in AWS. Integrations:

* Host ID
  * Adding relevant context (Host ID, OS, instance ID, tags, etc) about Amazon EC2 hosts when observed by Vectra.
  * While technically optional, it is a best practice is to enable this integration when you have Hosts deployed in AWS that are monitored by Vectra. Detections in Vectra are tied to a Host or an Account. To be more easily actionable and for some algorithms to support learning, Detections must be attributable to a Host (including statically defined hosts), rather than a generic Host IP address or other similar network artifact – especially as many of these network artifacts are transient in the cloud. To this end, the Vectra platform (Brain) can directly query the describe instance APIs in AWS to extract the instance identifier, tags, Amazon VPC and other metadata for Amazon EC2 VMs.
  * The AWS account may be set up as a standalone account or as a federated organization with a parent account and multiple child accounts.
* AWS Security Hub
  * The Vectra Brain can natively publish Host scores involving AWS workloads in AWS Security Findings Format (ASFF) to the AWS Security Hub service. This is optional and for Quadrant UX deployments only.
* Cloudwatch
  * Publishing health and audit logs to Amazon CoudWatch. This is optional.

Vectra makes CloudFormation templates available to enable easy creation of the users, roles and policies required. The templates are available from Vectra support as attachments to the [Vectra AWS Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-brain) support article. The files can also be downloaded from your Brain after deployment from the following locations:

* https\://\<brain\_hostname\_or\_IP>/resources/HostIdTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/HostIdFederatedParentTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/HostIdFederatedChildTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/SecurityHubTemplate.yaml/serve\_file
* https\://\<brain\_hostname\_or\_IP>/resources/CloudwatchLogsTemplate.yaml/serve\_file

Full details for the configuration of these integrations are in the [Vectra AWS Brain Deployment Guide](/deployment/ndr-virtual-cloud-appliances/aws-brain).

Let’s look at the policy for the VectraCognitoHostIDv1 user first (HostIdTemplate.yaml):

AWSTemplateFormatVersion: '2010-09-09'

Description: Vectra HostID User version 1

Resources:

user:

Properties:

Policies:

\- PolicyDocument:

Statement:

\- Action:

\- iam:ListAccountAliases

\- iam:SimulatePrincipalPolicy

\- ec2:DescribeInstances

\- ec2:DescribeRegions

\- ec2:DescribeSubnets

\- ec2:DescribeTrafficMirrorTargets

\- ec2:DescribeTrafficMirrorSessions

\- ec2:DescribeVpcPeeringConnections

\- ec2:DescribeVpcs

\- sts:GetCallerIdentity

Effect: Allow

Resource:

\- '\*'

Version: '2012-10-17'

PolicyName: vectra\_hostid\_permissions

UserName: VectraCognitoHostIDv1

Type: AWS::IAM::User

You see that all the rights we are requesting a Describe\*calls against ec2:\* resources. This allows Vectra to collect and display host information like this:

This is tracked for every workload in EC2 and is updated automatically throughout the day.

The policy for the CloudWatchLogs user is as shown (CloudwatchLogsTemplate.yaml):

AWSTemplateFormatVersion: '2010-09-09'

Description: Vectra Cloudwatch Logs User version 1.3

Resources:

user:

Properties:

Policies:

\- PolicyDocument:

Statement:

\- Action:

\- logs:CreateLogStream

\- logs:DeleteLogStream

\- logs:DescribeLogStreams

\- logs:GetLogEvents

\- logs:PutLogEvents

\- logs:DeleteLogGroup

\- logs:GetLogEvents

\- logs:PutRetentionPolicy

Effect: Allow

Resource:

\- !Join

\- ''

\- - 'arn:'

\- !Ref 'AWS::Partition'

\- :logs:\*:\*:log-group\:/vectra/cognito/\*

\- !Join

\- ''

\- - 'arn:'

\- !Ref 'AWS::Partition'

\- :logs:\*:\*:log-group\:/vectra/cognito/\*:log-stream:\*

Sid: CreateDeleteAndRetrieveVectraCloudwatchGroupLogEvents

\- Action:

\- iam:SimulatePrincipalPolicy

\- logs:DeleteLogGroup

\- logs:CreateLogGroup

\- sts:GetCallerIdentity

Effect: Allow

Resource:

\- '\*'

Sid: CreateVectraLogs

Version: '2012-10-17'

PolicyName: vectra\_cloudwatch\_log\_permissions

UserName: VectraCognitoCloudwatchLogsv1

Type: AWS::IAM::User

This policy allows Vectra to send its access and healthlogs into CloudWatch Logs. The data in CloudWatch logs looks like this:

Lastly is the Security Hub policy document (SecurityHubTemplate.yaml):

AWSTemplateFormatVersion: '2010-09-09'

Description: Vectra Security Hub User version 1.2

Resources:

user:

Properties:

Policies:

\- PolicyDocument:

Statement:

\- Action:

\- securityhub:BatchImportFindings

\- securityhub:GetFindings

\- securityhub:UpdateFindings

Effect: Allow

Resource:

\- '\*'

Sid: CreateDeleteAndRetrieveSecurityHubFindings

\- Action:

\- sts:GetCallerIdentity

\- iam:SimulatePrincipalPolicy

\- securityhub:DescribeProducts

\- securityhub:ListEnabledProductsForImport

Effect: Allow

Resource:

\- '\*'

Sid: GetCallerIdentity

\- Action:

\- securityhub:EnableImportFindingsForProduct

\- securityhub:DisableImportFindingsForProduct

Effect: Allow

Resource:

\- !Join

\- ''

\- - 'arn:'

\- !Ref 'AWS::Partition'

\- ':securityhub:\*:'

\- !Ref 'AWS::AccountId'

\- :hub/default

Sid: EnableVectraProduct

Version: '2012-10-17'

PolicyName: vectra\_security\_hub\_permissions

UserName: VectraCognitoSecurityHubv1

Type: AWS::IAM::User

This policy allows Vectra to create Host Scoring events within AWS security Hub. An example is below:

### Fitting into your DevOps Workflow

Automation is key to a successful cloud workflow; however, automation that does not account for security can easily open the environment for attack. The Vectra platform can take part in your automation in a number of ways, including:

* Automated deployment of VPC Traffic Mirrors with CloudFormation and Terraform.
* Automated deployment of VPC Traffic Mirrors with Lambda.
* Automated remediation driven by AWS and Vectra events.
* Integration with Slack for ChatSecOps.
* Vectra Rest API.

### Automated Deployment of VPC Traffic Mirrors

VPC Traffic Mirrors can be added as workloads are deployed with both CloudFormation and Terraform. Let’s look at both.

In CloudFormation you want to add the AWS::EC2::TrafficMirrorSession object to your templates to create a mirror session. The syntax is like this:

This configuration is fully documented here. <https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-trafficmirrorsession.html>

In Terraform, we need to create an aws\_ec2\_traffic\_mirror\_session within our configuration. That looks something like this:

The Terraform configuration is fully documented here: <https://www.terraform.io/docs/providers/aws/r/ec2_traffic_mirror_session.html>

### Automated Deployment of VPC Traffic Mirrors with Lambda

One of the best features of the AWS Cloud is its event driven nature. We can hook events of interest and then perform an automation when one of those events happen. Lambda is a great way of performing an action when triggered by an event, like starting a new EC2 instance.

That is exactly what Amazon released with this project:

The code can be downloaded from GitHub. It uses Python 3 and the AWS SAM or Serverless Application Model to deploy a Lambda that will attach a VPC Traffic Mirror to every newly launched instance, automatically.

### Integration with Slack for ChatSecOps

Another way to integrate Vectra into your DevOps workflow is to integrate Vectra and Slack or other chat system. This would allow your team to send commands into Vectra and receive notifications and alerts into the chat system from Vectra. An example of this integration is available as [CogBot and is available here](https://github.com/vectranetworks/CogBot).

### Vectra REST API

Vectra provides separate APIs for use with Respond UX or Quadrant UX deployments. The Respond UX offers a unified view with AI-driven Prioritization and a single urgency score for all entities (hosts, accounts, etc) across all data sources (network, public cloud, SaaS, etc). The Quadrant UX is the classic experience that existing Vectra NDR (formerly Detect for Network) customers are familiar with. It offers separate threat and certainty scores with separate host and account prioritization.

Please see the following resources on the Vectra support site:

* Respond UX
  * [Vectra SaaS API Quickstart Tutorial](/configuration/access/api-rux/rux-api-postman-quick-start-guide)
  * [Vectra SaaS API Guide v3.3](/configuration/access/api-rux/v33-api-guide-rux)
  * [Vectra SaaS API Public Postman Collection](https://www.postman.com/planetary-trinity-669963/workspace/vectra-ai/collection/1058623-cc38478b-7261-4e59-8768-1cf61a68ec5d)
* Quadrant UX
  * [How to query Vectra REST API using Postman platform](/configuration/access/api-qux/v25-postman-quick-start-guide-using-token-auth)
  * [REST API Guide v2.5](/configuration/access/api-qux/v25-api-guide-qux)
  * [Vectra Public Postman Collection](https://www.postman.com/planetary-trinity-669963/workspace/vectra-ai/collection/7429442-509c593b-8de4-4aa3-ac05-e07934eb9f17)

## Appendix A – Establishing Traffic Mirrors

It is the VPC Traffic Mirror functionality that Amazon Web Services released in June 2019 that allows Vectra to function within the AWS cloud. The VPC Traffic Mirror function emulates a more traditional SPAN or TAP that companies have been using on-premises for decades, now in the cloud. The traffic is delivered encapsulated in VXLAN packets delivered by Amazon Web Services directly to the TMT or Traffic Mirror Target. Additional information about VPC Traffic Mirroring is available here:

<https://aws.amazon.com/blogs/networking-and-content-delivery/using-vpc-traffic-mirroring-to-monitor-and-secure-your-aws-infrastructure/>

There are a few caveats with the current implementation that we should discuss. Some points to keep in mind:

* Not all Nitro based instances are supported as a traffic mirror source:
  * <https://aws.amazon.com/about-aws/whats-new/2021/02/amazon-vpc-traffic-mirroring-supported-select-non-nitro-instance-types/>
* Traffic mirrors need to be deployed manually, or they can be automated:
  * As a part of your deployment tooling, supported by both CloudFormation and Terraform.
  * They can be added as part of a lambda automation that is triggered by EC2 events:
    * <https://github.com/aws-samples/aws-vpc-traffic-mirroring-source-automation>
  * They can be added by some Python code:
    * <https://github.com/vectranetworks/AWS-Traffic-Mirroring-Session-Manager>
* A packet can only be delivered once.
  * This means that if there is more than one packet mirror destination, a packet can only be delivered to ONE destination.
  * That is determined by the session number setting in the mirror session itself.
  * Lower values take precedence.
  * <https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-session.html>

It is expected that these shortcomings will be addressed in the next few quarters.

To configure the VPC traffic mirror, you need to setup three different objects within AWS. Our recommendation is that you configure them in the following order:

1. Create a single Mirror Filter.
2. Create a Mirror Target for each Sensor or network load balancer you have deployed.
3. Create a Mirror Session for each workload you would like to monitor.

Create a Mirror Filter

The VPC Traffic Mirror Filter will determine what packets from the source workload will be mirrored to the Traffic Mirror Target.

To create a Mirror Filter in one of your AWS accounts, select VPC, then Mirror Filters under Traffic Mirroring. You can provide a Name Description for the filter. The logic of the filter is most important. We recommend you check amazon-dns under Network Services – optional. Then create an inbound and outbound rule with these values.

* Rule action – accept
* Protocol – All Protocols
* Source CIDR – 0.0.0.0/0
* Destination CIDR – 0.0.0.0/0

This one Mirror Filter can be used for all the mirrors in your deployment.

Click create to commit this Traffic Filter. This filter will copy all the traffic from the source ENI to the TMT.

Creating a Mirror Target

Mirror Targets need to be created for each Sensor you deploy. The Mirror Target, once created, will create a TMT or a Traffic Mirror Target object. The TMT will then be used for each Mirror Session created.

If we look at a Sensor you will see there are two ENIs on each one.

On the Vectra AWS Sensor each interface serves the following purpose:

| **Interface** | **Purpose**          | **Default Security Group**     |
| ------------- | -------------------- | ------------------------------ |
| eth0          | Capture Interface    | Sensor-TrafficSecurityGroup    |
| eth1          | Management Interface | Sensor-ManagementSecurityGroup |

Create the Mirror Target using the Name and Description of your choice and point it to either the Network Interface or Network Load Balancer of your Sensor.

Creating a Mirror Session

Traffic Mirror Sessions are what instructs AWS to actually send traffic from the instances to the configured Mirror Target.

* Select a Name and Description
* Select a Mirror Source (ENI of the instance that will send its traffic)
* Select the Mirror Target you have created for your Sensor
* Session can just be set to “1” and all other options left blank
* Select the Mirror Filter you created earlier and then click “Create”


# Azure Brain

Deploy a Vectra Brain in an Azure subscription for RUX or QUX deployments.


# Introduction and requirements

Prerequisites and high-level workflow for deploying an Azure Brain, including required permissions and Azure resources.

## Introduction

This document outlines the steps to deploy a Vectra Brain in a customer’s Azure subscription. The Brain is deployed using the Azure CLI with a template provided by Vectra. The template references a Brain image that is made available to individual Azure logins via a shared image gallery.

Azure Brains can be used in both Respond UX and Quadrant UX deployments. For more detail on Respond UX vs Quadrant UX please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux). One of the below guides should be the starting point for your overall Vectra deployment:

* [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Vectra Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

## Deployment Process Overview

The steps involved in deploying the Brain include:

{% stepper %}
{% step %}

#### Preparing for deployment

Please ensure you meet all of the following:

* [Vectra Requirements](#vectra-requirements)
* [AWS Requirements](#aws-requirements)
* [Firewall requirements](/deployment/ndr-virtual-cloud-appliances/azure-brain/firewall-requirements)
  {% endstep %}

{% step %}

#### [Deploying the Brain Image](/deployment/ndr-virtual-cloud-appliances/azure-brain/deploying-the-brain-image)

The Brain is deployed using the Azure CLI with a template provided by Vectra.
{% endstep %}

{% step %}

#### [Enabling Azure HostID Integration](/deployment/ndr-virtual-cloud-appliances/azure-brain/azure-hostid-integration)

Vectra has an integration with Azure that queries the API offered by the Azure Resource Manager to gather additional information about hosts running in Azure. This information contributes to Vectra’s automated Host identification (Host ID) and adds information to the Host entity details screen.
{% endstep %}

{% step %}

#### [Pairing Sensors or Stream](/deployment/ndr-virtual-cloud-appliances/aws-brain/pairing-sensors-or-stream)

Sensor appliances must be pairing with your Brain for NDR functionality. Sensors capture network traffic and distill a metadata stream that is analyzed by your Brain appliance.
{% endstep %}
{% endstepper %}

## Vectra Requirements

Vectra will provide the following information:

* **Image share acceptance link** – click this link to accept the Azure image share.
  * An image share must be accepted to that you can reach the Vectra Brain image for later deployment into your Azure subscription.
  * When Vectra shares the image with you, your Azure login will be sent an invite from Microsoft that contains a link you can use to accept the share.
  * Alternatively, if your Azure login is not email enabled, Vectra provides an image acceptance link that can be sent to any alternate corporate email address.
  * See [Accepting the Organization Invite from Vectra](#accepting-the-organization-invite-from-vectra) for more detail.
* **Template URI** – publicly accessible location housing the current Generally Available (GA) template to be used for deployment.
* **Brain Image** – Azure resource identifier for the shared image.
* **Provisioning Token** – allows the Brain to register with Vectra.
  * Please note that provisioning tokens expire after 7 days. Vectra can provide new ones if you don’t have a chance to deploy before the initial one expires.

## Azure Requirements

* A user with sufficient permissions in Azure who is available to deploy using the template.
  * Details on permissions required will be explained below in the [Azure Permissions Required ](#azure-permissions-required)section.
* Images are shared to an individual Azure login, not to the company, subscription, organization, etc.

{% hint style="info" %}
**Please Note:**

* Only **work** or **school** account types are supported, no personal **Microsoft** accounts are allowed.

* Vectra does not support accounts that are managed by other accounts.
  {% endhint %}

* Access to the Azure CLI is required to deploy an image that resides in another subscription.
  * Installing Azure CLI instructions: <https://docs.microsoft.com/en-us/cli/azure/install-azure-cli>.

{% hint style="info" %}
**Please Note:**

Deployment via the Azure portal is not supported by Microsoft. Notably, the Azure Cloud Shell will also give an error if attempting the installation using it. The Azure CLI MUST be used.

* <https://learn.microsoft.com/en-us/azure/virtual-machines/share-using-app-registration>

* From the linked article above, Microsoft has this below statement:
  * "You cannot use the portal to deploy a VM from an image in another azure tenant. To create a VM from an image shared between tenants, you must use the Azure CLI or Powershell."
    {% endhint %}

* You will need an Azure resource group, virtual network, subnet, and SSH key pair that can be used, or new ones will need to be created.
  * See [Creating Azure Resources](#creating-azure-resources) for more detail.

* Your security group in Azure will need to meet all [firewall requirements](/deployment/ndr-virtual-cloud-appliances/azure-brain/firewall-requirements) for Brain communication.

### Azure Permissions Required

The user who will deploy using the Azure CLI should have permissions in their assigned role that allows deployment via ARM template to the resource group they will deploy into. The **Owner** or **Contributor** roles should suffice. Specific permissions required are:

* `Microsoft.Resources/deployments/read`
* `Microsoft.Resources/deployments/write`
* `Microsoft.Resources/deployments/delete`
* `Microsoft.Resources/deployments/cancel/action`
* `Microsoft.Resources/deployments/validate/action`
* `Microsoft.Resources/deployments/whatIf/action`
* `Microsoft.Resources/deployments/exportTemplate/action`
* `Microsoft.Resources/deployments/operations/read`
* `Microsoft.Resources/deployments/operationstatuses/read`
* `Microsoft.Resources/deploymentScripts/read`
* `Microsoft.Resources/deploymentScripts/write`
* `Microsoft.Resources/deploymentScripts/delete`
* `Microsoft.Resources/deploymentScripts/logs/read`

### Accepting the Organization Invite from Vectra

If your Azure login is enabled for email, you will receive an email from **Microsoft Invitations on behalf of Vectra AI <<invites@microsoft.com>>** saying that you have been invited to access applications. Alternatively, if your Azure login is not enabled for email, Vectra provides an acceptance link that can be sent to your corporate email address.

* Please click the **Accept Invitation link** and then authenticate to Microsoft. It should look similar to the below sample:

![](/files/6dca7ab7cbd988bff667a8740ab033a047c99b36)

* You will need to authenticate with Microsoft using your Azure login credentials (not your email credentials) as part of the acceptance process.
  * This will require you to setup MFA for the Vectra tenant.
  * You can use any authenticator app you like (Microsoft is suggested).
* Once accepted you should have access to the Brain image, but you will likely need to login again at your Azure CLI before deploying.
  * Login to Azure a second time using:
    * The `az login --tenant a6cc66bc-f419-45c2-a9c2-8ff4ab685f2d` command.
    * This will force Azure to use the MFA that you just setup. You can then use `az account list` at the Azure CLI and should be able to see Vectra’s tenantID (in the lower section of JSON below).

{% hint style="warning" %}
Deployment will not succeed without seeing Vectra’s tenantID available via your login.
{% endhint %}

![](/files/009142b1cccf795b348965b5db0d2cc519ff0109)

{% hint style="info" %}
**Please Note:**

One of the subscriptions you can see when executing `az account list` will be designated as your default subscription (the top green arrow shows this in the above screenshot). If this is not the subscription that you intend to deploy into, you will need to use the `--subscription` option to specify the subscription that you wish to deploy into when executing the deployment command later.
{% endhint %}

### Creating Azure Resources

#### Creating a Resource Group

A resource group is a container that holds related resources for an Azure solution. Please see the following Microsoft docs for information regarding creating resource groups using the Azure CLI or the Azure portal:

* <https://docs.microsoft.com/en-us/cli/azure/manage-azure-groups-azure-cli>
* <https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal>

Save the name of the resource group for later use in the deployment.

#### Creating a Virtual Network (VNET) and Subnet

Please see the following Microsoft docs for information regarding creating a VNET and Subnet using the Azure CLI or the Azure portal:

* <https://docs.microsoft.com/en-us/azure/virtual-network/quick-create-cli>
* <https://docs.microsoft.com/en-us/azure/virtual-network/quick-create-portal>

After creating the VNET and Subnet, copy the subnet ID for later use during deployment from the JSON representation of the VNET using either the Azure portal or the CLI. To view this subnet ID in the Azure portal, navigate to your VNET and click on the **JSON View**:

![](/files/af94767513505673f38a520ba9d82f1957743da9)

Copy all of the subnet **id** that is inside of the quote marks. The entire ID is not visible in the screenshot but as an example it would begin with `/subscriptions/` and continue until the last character before the closing quotation mark.

![](/files/262a38f88824d376a38ee9f373962a29366d43ce)

The subnet ID can also be retrieved from the Azure CLI by using the following command:

* `az network vnet list -g Resource_Group`

An example is shown below:

![](/files/12a9cbc3d1eec30cc45c3718b3c24918981826f3)

#### Creating an SSH Key Pair

An RSA SSH key pair will need to be created for the Brain to allow an administrator to login to the CLI as the `vectra` user. See [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) for more details. These can be generated using any standard tool. Azure has some options documented:

* <https://docs.microsoft.com/en-us/azure/virtual-machines/ssh-keys-portal>
* <https://docs.microsoft.com/en-us/azure/virtual-machines/linux/mac-create-ssh-keys>

The public key will need to be copied for later use during deployment so that it can be assigned to the Brain. After the Brain is deployed and registered with Vectra, you can login to the Brain CLI via SSH:

* You may need to make the key readable to you using a command such as:
  * `chmod 400 vectra.pem`
* Example login command:
  * `ssh -i <private key path> vectra@BrainHostnameOrIP`


# Firewall requirements

Azure-specific connectivity guidance for Azure Brain deployments, including NSG rules, DNS, and NTP notes.

## Azure Specific Connectivity Guidance

After deployment, the Brain will have a default Azure Security Group configured as seen below:

![](/files/5a3366dcd5699e391f9a76ea34ce651992b47255)

Customers can modify this as required for their deployment. For example, if a public IP address was assigned, you may want to add a rule that allows HTTPS and SSH connectivity from Sensors that need to reach the Brain over the internet. Or you may want to allow HTTPS and SSH from a specific home IP that enables administrator access.

DNS resolution is provided by Azure by default. You do not need to list DNS servers for Azure unless you want to use something other than Azure provided defaults. An example would be when you want to pair by hostname and hostnames are only in your DNS and are not resolvable via Azure’s DNS.

NTP defaults to Ubuntu’s servers but can be changed as desired in *Configuration → COVERAGE → Data Sources > Network > Brain Setup > NTP Entries*.

## Firewall Requirements Sections

[Important Notes](#important-notes)\
This section covers Respond UX vs Quadrant UX applicability. It also covers SSL inspection, internet/air-gap requirements, and remote support IP range conflicts.

[Vectra Cloud Connectivity](#vectra-cloud-connectivity)\
This section covers connectivity to Vectra services hosted in Vectra’s cloud. It is mainly for Respond UX deployments. The [Auth Gateways](#auth-gateways) section also applies to Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.

[Appliance Connectivity](#appliance-connectivity)\
This section covers connectivity required for Vectra appliances (physical or virtual). It applies to both RUX for Network and Quadrant UX deployments. This section also contains additional details regarding connectivity from Vectra appliances to the Vectra cloud.

## Important Notes

### Respond UX vs Quadrant UX Applicability

The Respond User Experience (Respond UX or RUX) and the Quadrant User Experience (Quadrant UX or QUX) are two different analyst user experiences that Vectra offers. It is important to differentiate between the different UX's when looking at requirements for FW rules. Some FW rules will only apply to deployments using the Respond UX and some will apply only to deployments using the Quadrant UX. For additional information please see: Vectra Analyst User Experiences (Respond vs Quadrant).

While the Respond UX is delivered from Vectra's cloud as part of the overall Vectra AI Platform, it can be used without traditional Brain and Sensor appliances when only non-network data sources are used. RUX for Network deployments (using network Sensors with the Respond UX) still require a Brain appliance to be installed in the customer environment (which can be in IaaS clouds or physical data centers, etc). Sensors will be deployed and paired with that Brain to capture network traffic for analysis.

Requirements listed below that apply only to RUX for Network deployments or only to QUX deployments will be labeled as such.

### Firewall/Proxy SSL Inspection

Please note that Vectra appliances validate SSL certificates for all HTTPS connections. For this reason, SSL/TLS inspection on firewall and proxy appliances must be disabled for these connections to work.

We have also identified that some firewall software transparently enables SSL inspection if certain filters (DNS hostname filtering) are enabled. This is not necessarily obvious to the administrator and should be investigated if connectivity issues are being observed.

### Internet Access From Vectra Brain

A Vectra Brain requires connectivity to the automatic update service for normal operation. This connectivity is used for automatic (including security) updates and to synchronize keys for cryptographic authentication of sensors.

The Brain requires Internet DNS resolution to obtain the IP addresses for these requests. The customer may choose public/Internet DNS servers or internal DNS servers; however, Internet DNS entries must be resolvable by the Brain. Please note that DNS is often considered to be a UDP-only protocol, however, TCP may be used depending on the type of DNS transaction. Both UDP and TCP use port 53 and should be permitted to all configured DNS servers.

Vectra can function in air-gapped environments when a Quadrant UX based deployment is done, but there will be some impacts such as:

* Vectra Threat Intelligence detections will be disabled.
* Suspect Domain Activity detection will be disabled.
* Context enrichments from external sources such as whois, etc that are displayed in certain models will not function.

Please see the [Vectra Quadrant UX Deployment Guide](https://support.vectra.ai/s/article/KB-VS-1077) for additional details about air gap environments including guidance for offline updates. Respond UX for Network is not possible in air-gapped environments since the Respond UX is delivered from Vectra's cloud and communicates with a locally installed Brain.

### Internet Access to Vectra Appliances

As with all security infrastructure Vectra appliances should be blocked from Internet access and access should only be granted from trusted workstations and/or authenticated sources.

### Management Network IP Address Range Conflicts with Remote Support

Customers should note that the following IP ranges will conflict with remote support capability:

* 192.168.72.0/21
* 192.168.80.0/21

If you will ever need Vectra to assist remotely (outside of screen sharing sessions), care should be taken to number the management network interface (MGT) used on any appliance (physical, virtual, or cloud - Brains or Network Data Sources/Sensors) outside of the above ranges. If your management network interface (MGT) is numbered in either of these ranges, remote support access will not function. Remote support connectivity with Vectra all goes through the Brain (even to access other appliances in your deployment) so firewall rules for remote support functionality only need to allow connectivity from the Brain to Vectra's cloud (Sensors must still allow connectivity to the Brain per the below charts).

## Vectra Cloud Connectivity

* For this document, the portions of the Vectra AI Platform that reside in Vectra’s cloud are referred to as the Vectra cloud.
  * This does not refer to any specific service offering.
* Please check each category below to see if it is applicable to your deployment and if rules are required in your environment to enable the required connectivity.
  * For rule categories that have multiple region options, it is only necessary to put rules in place to allow connectivity to the region that your Vectra tenant is deployed in. This region should be visible in the URL used to access the Respond UX.
    * i.e. `[tenant_id].ew1.prod.vectra-svc.ai` is used for EU deployments (ew1).
* RUX for Network refers to a RUX deployment that has enabled network data sources (sensors).
  * This means you have a Brain somewhere in your premises (data center or public cloud) that is connected to the Vectra cloud for use with the Respond UX and paired with network Sensors (virtual or physical) to capture network traffic and distill a metadata stream for processing by the Brain appliance.
  * Please refer to the [Vectra Respond UX Deployment Guide](https://support.vectra.ai/s/article/KB-VS-1696) for more details.
* Please refer to the table below to see applicability of the various categories.
* The **For Brain or User’s Browser** column should be interpreted as follows:
  * **Brain** – Rules required for the Brain to the Vectra Cloud.
  * **User’s Browser** – Rules required for the user’s web browser to the Vectra cloud.

<table data-header-hidden data-full-width="true"><thead><tr><th width="318.47265625"></th><th width="281.6796875"></th><th width="259.9375"></th></tr></thead><tbody><tr><td><strong>Rule Category</strong></td><td><strong>Required For</strong></td><td><strong>For Brain or User’s Browser</strong></td></tr><tr><td><a href="#rux-for-network-gui-synchronization">RUX for Network GUI Synchronization</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#auth-gateways">Auth Gateways</a></td><td><p>RUX for Network Deployments</p><p>Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.</p></td><td>Brain</td></tr><tr><td><a href="#rux-metadata-forwarding">RUX Metadata Forwarding</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#rux-research-metadata-forwarding">RUX Research Metadata Forwarding</a></td><td>RUX for Network Deployments</td><td>Brain</td></tr><tr><td><a href="#section-2">RUX Analyst/Admin Access</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#_Respond_UX_(RUX)_1">RUX Static Asset CDN</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#_Respond_UX_Customer">RUX Customer File Upload</a></td><td>All RUX Deployments</td><td>User’s Browser</td></tr><tr><td><a href="#vectra-cloud-egress-ips">Vectra Cloud Egress IPs</a></td><td>Vectra Cloud connecting to configured SaaS data source connectors</td><td>N/A</td></tr></tbody></table>

### RUX for Network GUI Synchronization

* Required for:
  * All RUX for Network deployments.
* This is used to synchronize configurations between the Brain appliance and your Vectra tenant.
* This communications channel is initiated from the Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **Websocket and HTTPS over TCP/443**

<table data-header-hidden data-full-width="false"><thead><tr><th width="365.3203125" align="center"></th><th width="100" align="center"></th><th width="100" align="center"></th><th width="144.20703125" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">main-cbi-tunnel-uw2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-ew1.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-ec2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-cc1.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">main-cbi-tunnel-as2.app.prod.vectra-svc.ai</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### Auth Gateways

* Required for:
  * All Respond UX for Network Deployments.
  * Quadrant UX deployments of CDR for M365, IDR for Azure AD, and CDR for AWS.
    * Your Brain must be able to securely access the Vectra cloud over TCP/443 HTTPS connections to enable detection events from these products to be reported to your UI.
* In Respond UX for Network deployments, the Brain forwards network detections, entities, host sessions, and any selective PCAPs (Vectra Packet Capture) to your Vectra tenant via this connection.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.

<table data-header-hidden data-full-width="true"><thead><tr><th width="383.625" align="center"></th><th width="149.61328125" align="center"></th><th width="148.4609375" align="center"></th><th width="121.22265625" align="center"></th><th width="137.1484375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">authgateway.uw2.public.app.prod.vectra-svc.ai</td><td align="center">54.245.33.175<br>52.42.70.176<br>100.21.109.72<br>52.26.91.157</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.ew1.public.app.prod.vectra-svc.ai</td><td align="center">54.171.40.108<br>54.246.213.148<br>54.75.47.147</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.ec2.public.app.prod.vectra-svc.ai</td><td align="center"><p>16.62.18.237</p><p>16.62.142.98</p><p>51.96.54.201</p></td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.cc1.public.app.prod.vectra-svc.ai</td><td align="center">3.96.112.208<br>52.60.211.221<br>15.222.69.161</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">authgateway.as2.public.app.prod.vectra-svc.ai</td><td align="center">13.54.11.66<br>13.55.79.24<br>13.55.106.102</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Metadata Forwarding

* Required for:
  * All Respond UX for Network Deployments.
* Network metadata is forwarded to AWS S3 buckets and processed to make it available for features such as Instant Investigation and Advanced Investigation in the Respond UX.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="514.98046875" align="center"></th><th width="100" align="center"></th><th width="119.75390625" align="center"></th><th width="146.4296875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-uswt2-371371611652.s3-accesspoint.us-west-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-euwt1-371371611652.s3-accesspoint.eu-west-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-eucl2-371371611652.s3-accesspoint.eu-central-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-cacl1-371371611652.s3-accesspoint.ca-central-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-metadata-forwarder-apse2-371371611652.s3-accesspoint.ap-southeast-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Research Metadata Forwarding

* Optional but highly recommended for:
  * All Respond UX for Network Deployments
* Research metadata from precursor algorithms are used to improve model quality and reduce detection noise.
* This communications channel is initiated from your Brain to the endpoint in your Vectra tenant’s region.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="490.4140625" align="center"></th><th width="100" align="center"></th><th width="120.79296875" align="center"></th><th width="135.91796875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">cbo-upload-network-precursors-uswt2-371371611652.s3-accesspoint.us-west-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-euwt1-371371611652.s3-accesspoint.eu-west-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-eucl2-371371611652.s3-accesspoint.eu-central-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-cacl1-371371611652.s3-accesspoint.ca-central-1.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">Brain</td></tr><tr><td align="center">cbo-upload-network-precursors-apse2-371371611652.s3-accesspoint.ap-southeast-2.amazonaws.com</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">Brain</td></tr></tbody></table>

### RUX Analyst/Admin Access

* Required for:
  * All Respond UX deployments.
* Any analyst or admin that wishes to access the Respond UX will need to ensure that their browser can reach their Vectra tenant to login and access the UI.
* This communications channel is initiated from the user’s host.
* The protocol and ports in use for each entry is the same: **HTTPS over TCP/443**

<table data-header-hidden data-full-width="true"><thead><tr><th width="340.640625" align="center"></th><th align="center"></th><th align="center"></th><th width="139.19921875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">[tenant_id].uw2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">US</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].ew1.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].ec2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].cc1.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">User’s Browser</td></tr><tr><td align="center">[tenant_id].as2.portal.vectra.ai</td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">User’s Browser</td></tr></tbody></table>

### RUX Static Asset CDN

* Required for:
  * All Respond UX deployments.
* The Respond UX has certain static assets (HTML, CSS, JS) that are required to serve the web application hosted by a CDN (Content Delivery Network).
* This communications channel is initiated from the user’s host.

<table data-header-hidden data-full-width="true"><thead><tr><th width="313.40234375" align="center"></th><th width="153.4609375" align="center"></th><th width="100" align="center"></th><th width="100" align="center"></th><th width="142.07421875" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center"><p>dd6462tdmvp79.cloudfront.net</p><p>dpew7prsvwbf0.cloudfront.net</p></td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">All</td><td align="center">User’s Browser</td></tr></tbody></table>

### RUX Customer File Upload

* Required for:
  * All Respond UX deployments.
* This communications channel is used for:
  * Vectra Match deployments and will allow upload of rulesets.
  * PCAP download from the Vectra Cloud for Selective PCAP (Vectra Packet Capture)
  * Additional capabilities are planned for future releases.
    * It is recommended to put rules in place even if you don’t use Match or Selective PCAP.
* This communications channel is initiated from the user’s host.

<table data-full-width="true"><thead><tr><th width="395.8828125" align="center"></th><th width="151.8515625" align="center"></th><th width="93.1875" align="center"></th><th width="84.61328125" align="center"></th><th width="144.1015625" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Fully Qualified Domain Name (FQDN)</strong></td><td align="center"><strong>Protocol / Ports</strong></td><td align="center"><strong>IP(s)</strong></td><td align="center"><strong>Region</strong></td><td align="center"><strong>Initiated From</strong></td></tr><tr><td align="center">prd-main-customerfiles-580786928539-uswt2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">US</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-euwt1.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">EU</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-eucl2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Switzerland</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-cacl1.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Canada</td><td align="center">User’s Browser</td></tr><tr><td align="center">prd-main-customerfiles-580786928539-apse2.s3.amazonaws.com</td><td align="center"><p>HTTPS</p><p>TCP/443</p></td><td align="center">Dynamic</td><td align="center">Australia</td><td align="center">User’s Browser</td></tr></tbody></table>

### Vectra Cloud Egress IPs

When the Vectra Cloud connects externally to retrieve logs from configured data sources, it does so from the IPs listed at <https://ips.devops.vectra-svc.ai/ips.json>. The specific IPs used will be limited to the IPs listed for the regions in use for your Vectra deployment. For example, if you are only deployed in eu-west-1, then only the IPs from the list associated with eu-west-1 will be used. See the following table for details.

<table><thead><tr><th width="315.4375">Region Code</th><th width="297.0234375">Region</th></tr></thead><tbody><tr><td>ap-southeast-2</td><td>Australia</td></tr><tr><td>ca-central-1</td><td>Canada</td></tr><tr><td>eu-central-2</td><td>Switzerland</td></tr><tr><td>eu-west-1</td><td>EU</td></tr><tr><td>us-west-2</td><td>US</td></tr></tbody></table>

In most situations, customers do NOT need to configure any specific firewall rules to allow Vectra to reach the endpoints required. If you see the IPs in the list accessing your data in your logs, this is not a cause for concern. It is due to the fact that your configured data source connector is connecting to the endpoint to retrieve the data necessary to provide the service.

In the case of CDR for Azure, if private access is required for the Azure storage accounts that Vectra reads your Azure logs from, please see [Configuring Private Access for Azure Storage Accounts](/deployment/cdr-for-azure/deployment/appendix-1-azure-configuration-notes#configuring-private-access-for-azure-storage-accounts) in the CDR for Azure deployment guide. Details are provided for how to configure the Storage accounts used to only accept connections from the IPs associated with the Vectra Cloud.

## Appliance Connectivity

The [Vectra Cloud connectivity](#vectra-cloud-connectivity) section above primarily deals with connectivity required to deliver the Respond UX and detections from Vectra SaaS offerings to both RUX and QUX deployments, the content in this section also applies to any deployment using Vectra appliances (Brains, Sensors, and Stream) for RUX or QUX deployments.

### Vectra Cloud Appliance Connectivity

All communications with the Vectra Cloud occur over a TLS encrypted channel. Appliance devices (physical, virtual, cloud) authenticate using keys. Unique public/private keys are generated when a device is provisioned by Vectra. The corresponding public key is copied to the Vectra Cloud. Every device connecting to the Vectra Cloud authenticates using its own private key.

The Vectra Cloud houses several services:

* update2.vectranetworks.com
  * Used for delivering updates to the Vectra software.
  * [Offline updates](/operations/readme-1/offline-updates-v89) are also supported.
* api.vectranetworks.com
  * Used for lightweight health monitoring of the Vectra platform and for delivering additional context certain Detections may need.
  * Queries to external information sources to provide context are proxied through this connection.
  * If required, customers can block the platform from reporting health monitoring by blocking outbound connections on their firewall to api.vectranetworks.com.
* rp.vectranetworks.com
  * Used only for Brains deployed in IaaS clouds. Used for authentication and verification (integrity check of the file system).
* metadata.vectra.ai
  * Metadata sharing improves threat detection by contributing anonymized metadata sourced from Brain deployed in your organization. This is optional in QUX deployments.
* rs.vectranetworks.com
  * This enables remote support from authorized Vectra employees.
* SaaS product offerings such as Recall

#### Proxy Support

Vectra Cloud connectivity to update2.vectranetworks.com and api.vectranetworks.com supports connecting through a customer proxy. If a proxy connection is required for your Brain appliance to reach these endpoints, edit the proxy settings in *Configuration → Data Sources → Network → Brain Setup → Proxy & Status*.

* Note that [Remote Support](/configuration/access/vectra-remote-support) does not support proxy configuration by default. If this is the only option, please contact Vectra support to configure remote support to manually to use a proxy.

#### Lightweight Health Monitoring

The lightweight health monitoring includes the following statistics, only aggregate statistics are collected, no details are collected.

* System Health Metrics
  * Installed packages, running processes, system interface information, system usage, database usage, system error stats
* Environment Metrics
  * Host counts, traffic counts, Brain configuration, remote support status, notification status, metadata status
* Detection Metrics
  * Detection counts, PCAP stats, Triage stats

#### Metadata Sharing

[Why is Metadata Sharing Important](/reference/why-is-metadata-sharing-important)

* Full details are available at this link. There are optional additional levels of sharing also described.

Metadata Sharing Improves Threat Detection

* By contributing anonymized metadata sourced from the X-series platform deployed in your organization, you are contributing directly to the efficacy and accuracy of the Vectra software and the security of your network.
* Access to Detection metadata improves Vectra’s threat detection algorithms, enabling the Vectra software you use to be more effective in a constantly evolving threat landscape.
* Data is collected daily and includes:
  * Anonymized information about Detections that are triggered in your network.
  * Anonymized information about algorithms in the research and development phase (and not yet visible in the UI) that are triggered in your network.
  * Anonymized attribution of Detections to Hosts.
  * Anonymized information related to host identification efficacy.
* Vectra Secures and Limits Access to Metadata
  * Any metadata you contribute is anonymized by removing personal and network-specific information before it is sent to metadata.vectranetworks.com via an encrypted connection.
  * Vectra treats this metadata as highly confidential and only allows authorized research personnel to access the metadata.
  * Any metadata collected is securely deleted after a six-month period.
* Contact Vectra support if non-anonymized Full Metadata Sharing is desired
  * Algorithm development using non-anonymized metadata helps to ensure that new models function as efficiently as possible in your environment.

### Required Connectivity For Appliances

<table data-header-hidden data-full-width="true"><thead><tr><th width="131.375" align="center"></th><th width="253.46875" align="center"></th><th width="177.15234375" align="center"></th><th width="288.40234375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td><td align="center"><strong>Description</strong></td></tr><tr><td align="center">Administrator workstations</td><td align="center"><p>Brain</p><p>Sensors</p></td><td align="center">TCP/22 (SSH)</td><td align="center">Command-line management of the Brain and Sensor appliances.</td></tr><tr><td align="center">Administrator workstations</td><td align="center">Brain</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Web management of brain appliances.</td></tr><tr><td align="center">Brain</td><td align="center"><p>update2<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.156.238)</p></td><td align="center">TCP/443<br>(HTTPS)</td><td align="center"><p>Automatic updates.</p><p>Pairing keys for physical sensors.</p><p>See note above regarding SSL keys.</p></td></tr><tr><td align="center">Brain</td><td align="center"><p>api<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.5.9)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Health monitoring, algorithm support, reverse lookups for external IPs, Vectra Threat Intelligence, additional detection content. See note above regarding SSL keys.</td></tr><tr><td align="center">Brain (Cloud)</td><td align="center"><p>rp<strong>.</strong>vectranetworks<strong>.</strong>com</p><p>(54.200.156.238)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Used only for Brains deployed in IaaS clouds. Used for authentication and verification (integrity check of the file system)</td></tr><tr><td align="center">Brain</td><td align="center">DNS servers (as configured)</td><td align="center">TCP/53, UDP/53</td><td align="center">Both TCP and UDP are required for normal operation. See note above regarding DNS resolution.</td></tr><tr><td align="center">Brain</td><td align="center"><p>NTP servers (as configured)</p><p>Default is ntp.ubuntu.com</p></td><td align="center">UDP/123</td><td align="center">Time synchronization.</td></tr><tr><td align="center">Brain</td><td align="center">SMTP servers (as configured)</td><td align="center">TCP (as configured)</td><td align="center">Email alerting.</td></tr><tr><td align="center">Brain</td><td align="center">SMTP (OAuth)</td><td align="center">TCP/443<br>TCP/587</td><td align="center">Please see SMTP (OAuth) for Microsoft chart below.</td></tr><tr><td align="center">Brain</td><td align="center">Sensors, Stream</td><td align="center">TCP/22 (SSH)</td><td align="center">Remote management and troubleshooting.</td></tr><tr><td align="center">Sensors, Stream</td><td align="center">Brain</td><td align="center">TCP/22 (SSH), TCP/443 (HTTPS)</td><td align="center">Pairing, metadata transfer, and ongoing communication.</td></tr><tr><td align="center">Stream</td><td align="center">Data lake (as configured)</td><td align="center">TCP (as configured)</td><td align="center">Metadata stream to a data lake</td></tr></tbody></table>

### Additional (Feature Dependent) Connectivity

<table data-header-hidden data-full-width="true"><thead><tr><th width="132.6796875" align="center"></th><th width="395.2890625" align="center"></th><th width="167.9609375" align="center"></th><th width="339.06640625" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td><td align="center"><strong>Description</strong></td></tr><tr><td align="center">Brain</td><td align="center">content.user-telemetry.vectra.ai<br>data.user-telemetry.vectra.ai</td><td align="center">TCP/443<br>(HTTPS)</td><td align="center">Required for In-App support functionality.<br>See <a href="https://support.vectra.ai/s/article/KB-VS-1606">In-App Support KB</a> for more details.</td></tr><tr><td align="center">Administrator workstations</td><td align="center">Recall Kibana server</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Recall IP addresses are provided during implementation and may be requested at any time from Vectra Support.</td></tr><tr><td align="center">Brain</td><td align="center"><p>rs.vectranetworks.com</p><p>(74.201.86.229)</p></td><td align="center">TCP/443 or UDP/9970</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1045">Remote Support</a> access for remote troubleshooting. See note above regarding SSL inspection and other note about potential IP range conflicts with the MGT interface.</td></tr><tr><td align="center">Brain</td><td align="center"><p>metadata.vectra.ai</p><p>(100.20.236.31, 44.229.57.246, 44.228.37.60, 44.228.101.87)</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Anonymized metadata sharing to contribute to future algorithm development.</td></tr><tr><td align="center">Brain</td><td align="center">Recall collector</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Recall IP addresses are provided during implementation and may be requested at any time from Vectra Support.</td></tr><tr><td align="center">Brain</td><td align="center">Syslog (as configured)</td><td align="center">TCP or UDP (as configured)</td><td align="center">CEF or standard Syslog format.</td></tr><tr><td align="center">Brain</td><td align="center">Kafka (as configured)</td><td align="center">TCP (as configured)</td><td align="center">CEF or standard Syslog format.</td></tr><tr><td align="center">Brain</td><td align="center"><p>Carbon Black Response</p><p>(as configured)</p></td><td align="center">TCP/443 (as configured)</td><td align="center">Carbon Black integration (requires API key).</td></tr><tr><td align="center">Brain</td><td align="center">api.crowdstrike.com</td><td align="center">TCP/443 (HTTPS)</td><td align="center">Crowdstrike integration (Client ID and Client Secret).</td></tr><tr><td align="center">Brain</td><td align="center">vCenter (as configured)</td><td align="center">TCP (as configured)</td><td align="center">vCenter integration enables vSensor physical host view, augmented host identification, and vCenter alerts.</td></tr><tr><td align="center">Brain</td><td align="center">LDAP (as configured)</td><td align="center">TCP/389 STARTTLS/389</td><td align="center">LDAP authentication.</td></tr><tr><td align="center">Brain</td><td align="center">Radius (as configured)</td><td align="center">UDP/1812</td><td align="center">Radius (PAP) authentication.</td></tr><tr><td align="center">Brain</td><td align="center">TACACS (as configured)</td><td align="center">TCP/49</td><td align="center">TACACS (PAP or CHAP) authentication.</td></tr><tr><td align="center">Brain</td><td align="center">Backup server (as configured)</td><td align="center">TCP/22 (SSH)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1121">Automated backup (SCP or SFTP)</a>.</td></tr><tr><td align="center">Brain</td><td align="center">Brain</td><td align="center">TCP/22 (SSH), TCP/443 (HTTPS)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1121">Automated backup (brain-to-brain)</a>. Connectivity is bidirectional.</td></tr><tr><td align="center">Sensors, Stream</td><td align="center">update2.vectranetworks.com (54.200.156.238)</td><td align="center">TCP/443 (HTTPS)</td><td align="center"><a href="https://support.vectra.ai/s/article/KB-VS-1024">Required for automatic pairing</a>. Optional for manual (offline) pairing.</td></tr><tr><td align="center">SIEM/CLM log management</td><td align="center">Brain</td><td align="center">TCP or UDP (as configured)</td><td align="center">Log forwarding of DHCP/AD security events to augment host identification.</td></tr><tr><td align="center">Brain</td><td align="center"><p>login.windows.net</p><p>api.securitycenter.windows.com</p></td><td align="center">TCP/443 (HTTPS)</td><td align="center">Required for <a href="https://support.vectra.ai/s/article/KB-VS-1236">ATP lockdown</a></td></tr><tr><td align="center">Brain</td><td align="center">EMEA customers (only)<br><br>authgateway.ew1.public.app.prod.vectra-svc.ai<br>(54.171.40.108 , 54.246.213.148 , 54.75.47.147 )<br><br>AMS/APJ customers (only)<br><br>authgateway.uw2.public.app.prod.vectra-svc.ai<br>(54.245.33.175, 52.42.70.176, 100.21.109.72 , 52.26.91.157)</td><td align="center">TCP/443<br>(HTTPS)</td><td align="center">Required for Vectra MDR Service for QUX Deployments. These endpoints are also required for RUX deployments that have network data sources (Sensors). These are already discussed in the <a href="#auth-gateways">Auth Gateways</a> section of this doc for RUX. Essentially, if your deployment has a Brain, it MUST be able to reach Vectra over these endpoints for Vectra MDR service.</td></tr><tr><td align="center">Sensor</td><td align="center">S3 and SQS AWS Regional Endpoints. Only required for ZIA enabled Sensor.</td><td align="center">TCP/443</td><td align="center">Required for ZIA SASE/SSE integration. See <a href="https://support.vectra.ai/s/article/KB-VS-1006">KB</a> for details.</td></tr></tbody></table>

### SMTP (OAuth) For Microsoft

**Quadrant UX Only**: *Configuration → RESPONSE → Notifications → SMTP*

Respond UX deployments do not require this as email notifications are sent from Vectra's cloud.

<table data-header-hidden data-full-width="true"><thead><tr><th width="282.41015625" align="center"></th><th width="223.69140625" align="center"></th><th width="145.71484375" align="center"></th></tr></thead><tbody><tr><td align="center"><strong>Cloud Type</strong></td><td align="center"><strong>Destination</strong></td><td align="center"><strong>Protocol/Port</strong></td></tr><tr><td align="center">Public (office365<strong>.</strong>com)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>com<br>smtp<strong>.</strong>office365<strong>.</strong>com</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">US Government (office365<strong>.</strong>us)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>us<br>smtp<strong>.</strong>office365<strong>.</strong>us</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">German (office365<strong>.</strong>de)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>de<br>smtp<strong>.</strong>office365<strong>.</strong>de</td><td align="center">TCP/443<br>TCP/587</td></tr><tr><td align="center">China (office365<strong>.</strong>cn)</td><td align="center">login<strong>.</strong>microsoftonline<strong>.</strong>cn<br>smtp<strong>.</strong>office365<strong>.</strong>cn</td><td align="center">TCP/443<br>TCP/587</td></tr></tbody></table>


# Deploying the Brain image

Deploy the Vectra Brain VM in Azure using the Azure CLI, including required inputs, sizing, and post-deploy access steps.

## Deployment Introduction

After validating that you have the information required for deployment (shown below), choose either the [Interactive Deployment](#interactive-deployment) or the [Parameter File-Based Deployment](#parameter-file-based-deployment) option.

{% hint style="warning" %}
**Please Note:**

Both the interactive and parameter file-based deployment options will utilize a `-- aux-tenants` option to specify Vectra’s tenant that houses the image you will deploy in your subscription.

**Do not change this tenant!**
{% endhint %}

The Vectra Brain for Azure is currently available in 2 sizes:

<table data-header-hidden><thead><tr><th width="233.62890625"></th><th width="115.61328125" align="center"></th><th width="91.98046875" align="center"></th><th width="307.44140625"></th></tr></thead><tbody><tr><td><strong>VM Type</strong></td><td align="center"><strong>CPU Cores</strong></td><td align="center"><strong>Memory</strong></td><td><strong>Approximate Throughput</strong></td></tr><tr><td>Standard_E32s_v3 (Default)</td><td align="center">32</td><td align="center">256</td><td>~ 15 Gbps, up to 150,000 IPs monitored, 100 sensors</td></tr><tr><td>Standard_E16s_v3</td><td align="center">16</td><td align="center">128</td><td>~ 5 Gbps, up to 50,000 IPs monitored, 25 sensors</td></tr></tbody></table>

Vectra strives to make the Brain image available in the Azure regions needed by our customers. In some situations, Azure does not have these image types available in certain regions. When requesting the image from Vectra, work with your account team to ensure the region you wish to deploy in is supported. If you encounter Azure quota restrictions in a supported region, please see the following links for information regarding quota increase requests:

* <https://docs.microsoft.com/en-us/azure/azure-portal/supportability/per-vm-quota-requests>
* <https://docs.microsoft.com/en-us/azure/azure-portal/supportability/regional-quota-requests>

{% hint style="info" %}
**Please Note:**

Vectra product and engineering teams monitor the changing landscape of available IaaS cloud instance types. Occassionally customers will ask if a specific new instance type is supported.

There are a number of factors that can cause Vectra AI to stay with a specific instance type versus a newer one such as:

* Cost increase vs performance increase - sometimes a newer instance, for example, might cost 17% more but only increase performance by 10%.
* Availability - not all new instance types are always available in all the locations that Vectra AI supports.

Please reach out to your account team if you have questions about specific instance types that aren't supported.
{% endhint %}

The Azure CLI `az deployment group create` command will be used for deployment. Additional information about deploying via the Azure CLI and that specific command is available here:

* <https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-cli>
* <https://docs.microsoft.com/en-us/cli/azure/deployment/group?view=azure-cli-latest#az_deployment_group_create>

### Information required before proceeding with Brain deployment via Azure CLI

* **Resource group** – Name of the Azure resource group to deploy the Brain virtual machine into.
  * See [Creating a Resource Group](/deployment/ndr-virtual-cloud-appliances/azure-brain/introduction-and-requirements#creating-a-resource-group) for more detail.
* **Template URI (template-uri)** – Template URI location as provided by Vectra.
  * Example template URI (always use the current one that Vectra provided you before deployment):
    * `https://cognito-public-deployment-tools.s3.us-west-2.amazonaws.com/AzureBrain/6.16/mainTemplate.json`
* **Base Name (baseName)** – Specifies the base name used for all resources created as part of this deployment.
  * Requirements:
    * May contain only letters (a–z, A–Z), numbers (0–9), and hyphens (-).
    * Must begin and end with a letter or number.
    * Must not contain spaces or the following characters:

      `` ` ~ ! @ # $ % ^ & * ( ) = + _ [ ] { } \ | ; : ' , < > / ? . ``
    * This value is also used as the default GUI login password and should be changed immediately after deployment.
* **Brain Image (brainImage)** – Resource ID for the Vectra Brain image. This will be provided by Vectra.
  * Example Brain Image (always use the current one that Vectra provided you before deployment):
    * `/subscriptions/ac63f844-2350-4db1-9655-35817d1347a8/resourceGroups/vectra-dev-WestUS2/providers/Microsoft.Compute/galleries/Production/images/Cognito-6.16/versions/6.16.0`
* **Provisioning Token (provisionToken)** – Token that will allow the Brain to register with Vectra.
  * This will be provided by Vectra. Example shown below (non functional):
    * `9442fd6d-f582-4e6f-9509-edf85f207589`
  * Please note that provisioning tokens expire after 7 days. Vectra can provide a new one if you don’t have a chance to deploy before the initial token expires.
* **Public SSH Key (sshKey)** – Generate an RSA SSH key pair using any standard tool.
  * Enter the public key in this field.
  * See [Creating an SSH Key Pair](/deployment/ndr-virtual-cloud-appliances/azure-brain/introduction-and-requirements#creating-an-ssh-key-pair) above for more detail.
* **Subnet ID (subnetwork)** – Azure ID of the subnet that you will deploy the Brain into.
  * See [Creating a Virtual Network (VNET) and Subnet](/deployment/ndr-virtual-cloud-appliances/azure-brain/introduction-and-requirements#creating-a-virtual-network-vnet-and-subnet) above for more detail.

### Optional information for deployment when additional customization of options is desired

If you wish to deploy a Brain size other than the default or to provision without a public IP address, you must use the [Parameter File-Based Deployment](#parameter-file-based-deployment). You will be able to control the following in this method:

* **Creating a Public IP (createPublicAddress) –** Whether or not to assign a public IP address to the instance.
  * This defaults to true when using an interactive deployment.
* **Brain Size (instanceSize) –** Size of the Brain to deploy.
  * This defaults to `Standard_E32s_v3` when using an interactive deployment.
* **Location (location) –** Azure region where the resources are to be deployed.
  * This must be specified when using a parameter file-based deployment but defaults to the resource group location when using an interactive deployment.
* **Subscription** – All resources in an Azure subscription are billed together
  * When running `az account list` from the Azure CLI, if you have multiple subscriptions, one of them will be listed as `"isDefault": true`
  * Deployment will target this subscription unless the `–-subscription Subscription_ID` argument is used when executing the Azure CLI.
  * This can be specified using either the interactive or the parameter file-based deployment method.

## Interactive Deployment

This deployment method can be used when you will deploy the larger (default) `Standard_E16s_v3` size and desire to configure a public IP address. You can either specify the template URI or reference a local copy of the template file.

CLI command syntax using template URI:

```
az deployment group create --resource-group Your_Resource_Group --template-uri Template_URI_Given_By_Vectra --aux-tenants a6cc66bc-f419-45c2-a9c2-8ff4ab685f2d
```

CLI command syntax using locally downloaded template file:

```
az deployment group create --resource-group Your_Resource_Group --template-file Locally_Available_Brain_Template --aux-tenants a6cc66bc-f419-45c2-a9c2-8ff4ab685f2d
```

Example:

```
az deployment group create --resource-group tbilen-test_azure_brain --template-file Brain.json --aux-tenants a6cc66bc-f419-45c2-a9c2-8ff4ab685f2d
Please provide string value for 'baseName' (? for help): BrainTest
Please provide string value for 'brainImage' (? for help): /subscriptions/ac63f844-2350-4db1-9655-35817d1347a8/resourceGroups/vectra-dev-WestUS2/providers/Microsoft.Compute/galleries/Production/images/Cognito-6.10/versions/6.10.0
Please provide string value for 'provisionToken' (? for help): f6e5e488-343e-4d71-b96d-f167fcb3d6c9
Please provide string value for 'sshKey' (? for help): ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDHQMyfVlu/FUFuKMXXVvCTpTPuw/TOkgf3Myfuf/IFu9mnyDCjM9T0wrxjHMrwq3fIIY2PXSfNfHVMcJrJ+uLiaZo8vSGwVEtkOIeA20EXgUaAS7l3KVzztPmT9vs0TPZlj4iYRKA71T/e47H/dccNLM1zrf1F36iiJXBxcX09Xe1qhwCgnpoC8vjJIFSAaczqWShisHXXk2Q9ybsi3Vv3xxfa/SYp2PrBWtbej3XXwmIvAcJlXEbUxf1u14Jgd9JNcdPkdvh6cPfbrqcP6pmxgxNh92Uf8mKID3tnVd32rTl8aXxzd0FtFDN3N6R5/chPHlFF4aXkUJjmySPzCK9HOQTYoJytuJe0BuGS199qaZZ+xKzSsVAnPwiGmkHDWRozveWRU5aYKEfMUla1kHelTQvdriGJ/MtnFOUEZZS8VJYxNKoLAS2HJ8RXZosIugHqlD3D4HQWp/igu87vUJndMB0/rDDYUzN+SAmC74AmA1njaufg0TpvXLuUml2yl8E= generated-by-azure
Please provide string value for 'subnetwork' (? for help): /subscriptions/b3fe75ab-94a2-4322-84af-016eb01ff43e/resourceGroups/tbilen-test_azure_brain/providers/Microsoft.Network/virtualNetworks/tbilen_brain_test/subnets/tbilen_test
```

## Parameter File-Based Deployment

This deployment method can be used when you need to customize the VM size deployed or choose to not configure a public IP address. This method MUST use a locally available parameter file that will be passed as an argument to the CLI command.

Syntax for the parameter file (use any filename you wish):

```
{
    "baseName": {
        "value": "VALUE"
    },
    "brainImage": {
        "value": "VALUE"
    },
    "createPublicAddress": {
         "value": "true/false"
    },
    "instanceSize": {
        "value": "Standard_E16s_v3/Standard_E32s_v3"    
    },
    "location": {
        "value": "VALUE"
    },
    "provisionToken": {
        "value": "VALUE"
    },
    "sshKey": {
        "value": "VALUE"    
    },
    "sshKeyUser": {
        "value": "vectra"
    },
    "subnetwork": {
        "value": "VALUE"
    }
}
```

Example populated file:

```
{
    "baseName": {
        "value": "TMEBrain08102021"
    },
    "brainImage": {
        "value": "/subscriptions/ac63f844-2350-4db1-9655-35817d1347a8/resourceGroups/vectra-dev-WestUS2/providers/Microsoft.Compute/galleries/Production/images/Cognito-6.10/versions/6.10.0"
    },
    "createPublicAddress": {
         "value": "true"
    },
    "instanceSize": {
        "value": "Standard_E16s_v3"    
    },
    "location": {
        "value": "eastus"
    },
    "provisionToken": {
        "value": "d329fa9a-200b-41c5-8307-6eb1c99da8a1"
    },
    "sshKey": {
        "value": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDnhsku8A/HNN4S53D3QBcHcgeEvDcRVnHQjaf9FFih9ZH+k3LoB0IpuP6Gt47k/CSvJN6DpvhbQSwkm7ZfJNgNPyiDYFGwIeRI5dIr5jk+nEXJvXHd+8WqCfd/cWjwPaLjUUzUZ+lnJxcNG09BxQ+snjTlYDpmq89Vpq1xPKAEuTaUpxnbAeZr+JIRJKOsp2PH9lnCAo0Pz3VIRFexvm4JqzqjyXpYZLZp8PXCZDeK2K7DSM8gG+RQiTJX/D9eathGaQ67Z2K5oQwF0BkXwYtv5PXdGvfRwYjRdHJVL4SsvnVPcxh7t3xIag6qX4X0WILmVPO3tyxAAhLZCDQ49hO8RqFQZc0vGM4LtRJNvjlpPLJJXEh224aMm/MzqKbnVJgwMdAx9fbIbmPG5mgKn5rzLsKJZSKo8qoiUM6LwApuWbZUo7VZaCP/Rm8pvj0YqXObx9uKUsj3c5PuuthmFnQbS8NgOzlOlt9dllcBw658Iu9bbFiHrNXP2uz0vkOEciE= generated-by-azure"    
    },
    "sshKeyUser": {
        "value": "vectra"
    },
    "subnetwork": {
        "value": "/subscriptions/b3fe75ab-94a2-4322-84af-016eb01ff43e/resourceGroups/TME_Cognito_Test/providers/Microsoft.Network/virtualNetworks/Platform_Network/subnets/Platform_Subnet"
    }
}
```

CLI command syntax for parameter file-based deployment:

```
az deployment group create --resource-group RESOURCE_GROUP --template-uri Template_URI_Given_By_Vectra --aux-tenants a6cc66bc-f419-45c2-a9c2-8ff4ab685f2d --parameters File_Containing_Parameters
```

Example of a successful command string using this deployment type:

```
az deployment group create --resource-group TME_Cognito_Test --template-file Brain.json --aux-tenants a6cc66bc-f419-45c2-a9c2-8ff4ab685f2d --parameters myparameters.json --debug
```

The above example also used a `--debug` switch that instructs the Azure CLI to output much more information during execution. This may be useful in troubleshooting.

## Completing the Brain Deployment

It can take 5-10 minutes for Azure to complete the initial deployment. Both the interactive and the parameter file-based deployment will output some information at the CLI after completion that details the various resources that have been created. You may wish to save this information for later reference.

Once the deployment is complete at the CLI, you can now monitor the rest of the deployment using your web browser. Browsing to the public IP, if assigned during deployment, will be blocked initially. You can also connect to the private IP that was assigned if you have private connectivity in place. In the resource group that you deployed in, modify the inbound security group to allow HTTPS (TCP/443) and SSH (TCP/22) inbound from where you will connect to the Brain from.

Once you bypass a warning for the self-signed certificate that is created by default on the Brain, you will be presented with information relaying the status of the Brain’s progress as it continues through the deployment process. It will proceed through the following stages:

* Authenticating and verifying the file system of the virtual Brain appliance.
* Rebooting.
* Decryption of the file system.
* Connecting to the Vectra provisioning server and provisioning.

Example screenshots:

![](/files/Yc9qZKqKbtHh9936pPsm) ![](/files/AdA3zmZ3yPUmrLW1FoLr)

If a proxy is required to access Vectra in your Azure environment, this can be configured during this time by clicking on the **Set Proxy Configuration** link on any of these status screens.

{% hint style="info" %}
**Please Note:**

* This proxy configuration screen is only used to communicate with Vectra’s provisioning server and must utilize an HTTPS proxy. HTTP only proxies are not supported for this use.
* Other proxy configuration in the main Vectra UI after deployment accepts HTTP proxies and is used by non-provisioning related services and integrations.
  * *Configuration* → COVERAGE → Data Sources > Network > Brain Setup > Proxy & Status
    {% endhint %}

{% hint style="info" %}
**Please Note:**

If you are doing a Respond UX deployment and require a proxy for non-provisioning related services and integrations (this includes linking to Vectra’s cloud for use with the Respond UX), you should configure that proxy at the CLI of your Brain AFTER you progress through this initial configuration and get to the **Success!** message at the end of this section. Please see the [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) in the [*Deployment > Proxy Support*](/deployment/getting-started/respond-ux-deployment-guide/deployment#proxy-support) section for more detail.
{% endhint %}

Once complete, you will see the following:

![](/files/yN87JosoMar5DqCw1REA)

Clicking on the blue **Login** button will take you to the login page of the Brain (Quadrant UX). If you are doing a Respond UX deployment, you should **NOT** login to the local GUI (which is the Quadrant UX) before linking your Brain with Vectra. Once linked with Vectra per the [Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide), your Brain will no longer show a Quadrant UX login screen when you browse to its IP or hostname and it will instead show a page the instructs you to login to the Respond UX in Vectra’s cloud or a status page.

{% hint style="warning" %}
**Please Note:**

The Brain may require several updates to become current with Vectra’s latest generally available version.

* Please do not power off the Brain during the initial Azure deployment prior to login or during the updating process as the Brain becomes current.
* If powered off during initial deployment the Brain may become unresponsive and require redeployment.
* During this time the UI may become unresponsive, or you may be disconnected but it is safe to configure platform settings.
* Periodically, the Brain image is updated and when deploying a new Brain, always check with Vectra for the latest base image available for your deployment.
  {% endhint %}

### Default login credentials

The default credentials to login to the Vectra Brain GUI (Quadrant UX only) over HTTPs in Azure are

* Username: `admin`
* Password: Virtual Machine Name (visible in Azure after deployment)

Logging in at the CLI can be done via SSH using the private key corresponding to the public key that was assigned to this stack and the `vectra` username. Login to the CLI is supported for both Quadrant UX and Respond UX deployment types. Please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) for more details.

Please ensure Security Groups are updated to allow CLI and GUI access as per earlier guidance.

### Public IP Address Options

Vectra can create a **Basic SKU** dynamically assigned public IP address during deployment if the user chooses to do so. That IP will remain consistent through any reboots but can change when a virtual machine is stopped (deallocated), then started again. If you wish to change this to a static assignment, please do the following:

* **Dissociate** the assigned public IP from the NIC of the Brain.
* **Modify** the configuration of the IP to static assignment.
* **Associate** the IP with the NIC of the Brain.
  * This will very likely be a new IP that is different from the last assignment.

You may also wish to upgrade the Basic SKU to a Standard SKU public IP address. Some links from Microsoft explain the differences and give more information about public IPs in general:

* Public IP pricing:
  * <https://azure.microsoft.com/en-us/pricing/details/ip-addresses/>
* Public IP information and difference between Basic and Standard SKUs:
  * <https://docs.microsoft.com/en-us/azure/virtual-network/public-ip-addresses>
* Dissociating a public IP:
  * <https://docs.microsoft.com/en-us/azure/virtual-network/remove-public-ip-address-vm>
* Associating a public IP:
  * <https://docs.microsoft.com/en-us/azure/virtual-network/associate-public-ip-address-vm>

### Resizing the Brain

In some environments, you may wish to start with a smaller Brain instance and then later move to a larger Brain instance to handle additional load (metadata coming from paired sensors or additional paired sensors).

* Please see: [Resizing virtual appliances](/deployment/appliance-operations/resizing-virtual-appliances) for details

### Configuring Initial Brain Settings

For more details around initial settings for the Brain after successfully deploying it in Azure, see the [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide) or [Vectra Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment) that is available on the Vectra Support portal.


# Azure Host ID integration

Enable the Azure HostID integration to enrich hosts using Azure Resource Manager metadata.

## Introduction

To enable efficient investigation of cloud hosts, the Vectra NDR can be configured to periodically query the API offered by the Azure Resource Manager to gather additional information about hosts running in Azure. This information contributes to Vectra’s automated Host identification (Host ID) and adds information to the Host entity details screen.

It is a best practice is to enable this integration. Vectra NDR attributes detections to a Host or an Account. For some algorithms that support learning, detections must be attributable to a Host (including statically defined hosts), rather than a generic Host container (denoted by **IP-x.x.x.x** in the Vectra UI). Enabling this integration can help contribute to more complete detection as a result.

Please see this example screenshot (Quadrant UX) below of a host in Azure where additional context was pulled through API calls:

![](/files/ZXvWSPrGOTd2NRbQU2Q8)

As you can see, the integration provided the following (viewable by drilling down to the Host and then the Details tab):

* Host ID artifacts including a unique identifier and hostname
* Resource group, Admin, NICs, and Last Seen date/time
* Summary information on the left-hand side including OS, Host Name, and Location

## Requirements

Creating an Azure AD application and service principal that can read Azure management APIs is required. At minimum, read access to the following endpoints of the Azure resource manager will be required:

* <https://management.azure.com/subscriptions>
* <https://management.azure.com/subscriptions/SUBSCRIPTION/providers/Microsoft.Network/networkInterfaces>
* <https://management.azure.com/subscriptions/SUBSCRIPTION/providers/Microsoft.Compute/virtualMachines>
* <https://management.azure.com/subscriptions/SUBSCRIPTION/providers/Microsoft.Compute/virtualMachineScaleSets>

An alternative is to provide the Vectra Brain permissions to query the following APIs (this is a wider scope):

* `Microsoft.Network//read`
* `Microsoft.Compute//read`

The simplest way to accomplish this is to apply the built-in Azure **Reader** role to the application. This will allow your Vectra Brain to view all resources but does not allow it to make any changes.

Once created, you will then enter the Application (client) ID, Directory (tenant) ID, and Application Secret value into the Vectra UI to enable the integration. Multiple credential sets can be added if required.

## Configuration Example

**Resources**

* Full instructions for creating Azure AD application and service principal are available from Microsoft here:
  * <https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal>
* Details regarding Azure built-in roles are available from Microsoft here:
  * <https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles>

### Azure Steps

To enable this functionality, the following steps need to be completed for every Azure subscription where there are Sensors deployed. In this example we will apply the “Reader” role at the Azure Subscription level.

* After signing in to the [Azure AD portal](https://aad.portal.azure.com/), navigate to *Azure Active Directory > App registrations* and select **New registration**.
* Give the application a **Name** of your choosing and choose a supported account type.
* A Redirect URI is not required.

![](/files/QZxxTNZ1L85I9MBv4xvD)

* Click **Register** and then copy the **Application (client) ID** and **Directory (tenant) ID** for later use:

![](/files/9GgCqwa2zMrXUtxJOVC4)

* Now we will assign an Azure role to the application.
* In the [Azure portal](https://portal.azure.com/) select **Subscriptions** and select which subscription to apply the role to by clicking on it.
* Select **Access control (IAM)**, then click **+ Add**, and then click **Add role assignment**.

![](/files/DFyRj40YbQvnGemZ0C0O)

* Select **Reader** under Role.
* Leave **Assign access to** unchanged (it should say **User, group, or service principal**)
* Search for your application and select it.
* Click **Save**.

![](/files/Phcw3SBFAsq8FarcSwN3)

* Next we will create a new application secret.
* In the [Azure AD portal](https://aad.portal.azure.com/), navigate to *App registrations* and select your application.
* Select **Certificates & secrets**, click **+ New client secret**, enter a **Description** and select and when you want this to expire:

![](/files/DgiSjWECqV1sCoAeeyuv)

* Click **Add**.
* Once created, you must copy the **Value** before navigating away from this screen as you cannot retrieve it later.

![](/files/irl8IPiF8rb59TKJ7uXE)

### Vectra Steps

* To complete the integration, in the Vectra UI, browse to *Configuration >* *SETUP > External Connectors*.
* Click on the pencil or **Edit** link for Azure.
* Toggle the integration to **On** and fill in the **Application (client) ID**, **Directory (tenant) ID**, and **Application secret values** that you created above:
* Click **Save**. Multiple sets of credentials can be configured if required for different subscriptions.

![](/files/zeqFAa2BZJmwyXsYZ1tx)

* The connection will best tested and if successful, you will see a green checkmark showing that Azure Resource Manager integration has been completed.

![](/files/jJUBkx5PJeCMpC5SsT7U)

## Viewing and Modifying Virtual Networks Considered by the Connector

The connector will only look at virtual machines or virtual machine scale sets that belong to some virtual networks, not necessarily all virtual networks that the credentials have access to. Specifically, by default, the connector will only look for virtual machines with network interfaces in the virtual networks where a Vectra Azure vSensor traffic/capture interface is deployed into, and all the virtual networks with a "double peering" to it (if the Sensor traffic interface lives in virtual network A, and virtual network A is peered with virtual network B and C, but only virtual network B is peered with virtual network A, then the connector will look for virtual machines in virtual networks A and B only). If a virtual machine has multiple network interfaces, the connector will provide host identification only for the IP addresses belonging to interfaces on monitored virtual networks.

Vectra limits the scope of the connector to only virtual networks that can reach an Azure vSensor for the following reasons:

* Vectra wants to avoid an excessive number of connections to the Azure resource manager.
* To improve performance, Vectra wants to avoid storing unnecessary information in the platform for resources that we are not monitoring.
* In the cloud it is possible that you may have some isolated virtual networks that are not monitored by Vectra Sensors but have overlapping IP space with some other networks that are monitored. Duplicate IPs are not supported by Vectra. To avoid Host ID issues, we only consider virtual machines on the networks that appear reachable by our Sensors.

If you want to add or remove some virtual networks from the set of virtual networks that Vectra monitors, you can do so through the CLI (ssh to the Brain as the “vectra” user). This functionality is not available in the Vectra UI. The use case for adding or removing virtual networks could be the following:

* If you have some tunneling or forwarding enabled and Vectra Azure vSensors see traffic from virtual networks that are NOT directly connected to our vSensor:
  * You will want to add the networks to the monitored networks list to extend Host ID coverage to the tunneled/forwarded traffic’s associated Hosts.
* If you do NOT have any Azure vSensors deployed, but mirror Azure traffic into your data center where you have Vectra physical or virtual Sensor coverage:
  * You will want to add the networks to the monitored networks list to extend Host ID coverage to the mirrored traffic.
* If you do have some overlapping IP space on a network that appears reachable by our vSensor, but that it is not monitored by our vSensor:
  * You will want to remove the overlapping networks from the monitored networks to avoid any Host ID issues.
* If you have a lot of peered networks but only some are monitored by the vSensor:
  * You will want to remove the non-monitored networks from the monitored networks list to increase performance and reduce load on the Azure resource manager.

The command to add or remove virtual network from the Vectra CLI is "**set azure vnets**". The command has a very helpful help message illustrating its use:

<img src="/files/0Rdp1MwmFL0DDTsBuyDW" alt="" width="563">

The command `show azure vnets` will show the virtual networks configuration, including the whitelist (networks to ADD), the blacklist (networks to REMOVE), the Sensors network, and finally the overall monitored networks, which is simply computed as ((Sensors networks + peered) + whitelist) - blacklist. It may take up to 10 minutes for the summarized `monitored networks` to update in the `show azure vnets` command output. Example of usage:

![](/files/GEBbSggd5a5cA8bzokX4)


# Pairing Sensors or Stream

Pair Sensors or Stream to an Azure Brain, with notes on Azure vSensor/Stream pairing limitations.

## Azure Sensor or Stream Pairing

The same content available on this documentation site under *Deployment → Appliance Operations →* [*Pairing appliances*](/deployment/appliance-operations/pairing-appliances) is shown below.

An Azure Brain can pair with any type of Sensor or Stream appliance. They can be physical, or virtual in cloud or traditional hypervisor environments.

Please note that Azure vSensors and Stream appliances do NOT support online pairing and that content below that is specific to physical Sensors or traditional hypervisor based vSensors does not apply to Azure vSensors or Stream.

## About Sensor and Stream Pairing

Sensors and Stream appliances behave the same way from a pairing perspective. Because of this, you may see the **Sensor** term used in this document, your Vectra UI, or at the CLI of a Vectra appliance when sometimes the appliance in question is a Stream appliance.

Multiple Sensors can be attached to a single Brain while the Brain supports a single Stream appliance at a time. The exact limits for how many appliances can be paired to your Brain will depend on the Brain model or configuration. Please see [appliance specifications](/deployment/getting-started/appliance-specifications) for details.

{% hint style="info" %}
**Please Note:**

* From this point forward, the term "Sensor" will be used to represent both Sensor or Stream appliance types in this document.
  {% endhint %}

## Pairing Overview

Pairing is the process that allows Sensors to communicate with the Brain. All network sessions between an appliance and the Brain are initiated from the Sensor side.

There are three basic ways to pair a Sensor or Stream appliance with a Brain:

{% tabs %}
{% tab title="Using a Sensor Registration Token" %}
Using a Sensor Registration Token (SRT) works for any appliance type and is required for Sensors deployed in IaaS cloud environments such as AWS, Azure, and GCP.

* A Sensor Registration Token (SRT) is generated on the Brain and then configured on the Sensor or Stream appliance.
* Once the Sensor is configured with a Brain IP address or hostname, it will annouce itself to the Brain if powered on.
* The Brain will recognize the validity of the token and allow the Sensor to become available for pairing.
* A user will initiate pairing or use auto pairing (2nd tab above) if enabled.
  {% endtab %}

{% tab title="Auto Pairing" %}
Auto pairing is an option that can be enabled by administrators that allows some Sensor configurations to automatically pair with your Brain. If either of the two below states is true, and the Sensor can reach the Brain, pairing will be completed automatically when auto pairing is enabled.

* You have a vSensor for traditional hypervisor deployment (VMware, Hyper-V, Nutanix, KVM, etc) that was downloaded from your Brain, and is preconfigured with the location of the Brain and the registration information required for pairing.
* Appliances (physical and virtual) that are configured with a Sensor Registration Token can also auto pair with a Brain.
  {% endtab %}

{% tab title="Online Pairing (Physical Sensors Only)" %}
Online pairing is only supported for Vectra physical appliances that can reach the Vectra updater service and the Brain. If the Brain is behind NAT and not reachable via its configured IP, see [online pairing](#online-pairing-physical-sensors-only-1) for more details (the `set brain` command at the Sensor CLI will need to be used).

* Appliances are provisioned by Vectra and then shipped to a customer.
  * They are also associated to the customer account.
  * The Brain retrieves the list of provisioned Sensors from Vectra periodically.
* Sensors will retrieve the location of your Brain from Vectra when they come online.
* In the Brain UI, provisioned Sensors will show as **Available** for pairing.
* When pairing is attempted by the user, the Brain and Sensor will retrieve the required registration information from Vectra and complete the pairing process.
  {% endtab %}
  {% endtabs %}

Pairing is also supported in air-gapped environments and physical appliances can also be paired "offline" when required. For details please see [Pairing in an Air-Gapped Environment vs Pairing Offline](#pairing-in-an-air-gapped-environment-vs-pairing-offline).

### Pairing by Hostname vs IP Address

Sensors need to know the location of the Brain appliance so that they know what hostname or IP address to communicate with. Pairing by hostname is generally preferred over pairing by IP address for the following reasons:

* Failover scenarios are easier to manage because a replacement Brain can be setup with the same hostname as the original Brain even if the IP address will be different. Paired Sensors will be able to automatically re-pair with the new Brain once the DNS is changed (if the old Brain is offline, see [pairing to new or changed Brains](#pairing-to-new-or-changed-brains) for more details). This is because the backup contains Sensor state information.
* If your Brain appliance is configured with a DHCP address for its management port instead of a static IP address and you have paired by hostname, even if the IP address of the Brain changes, Sensors will still be able to communicate with the Brain they are paired to.

## Sensor Pairing and Registration Settings

The ***Configuration*****&#x20;→&#x20;*****COVERAGE*****&#x20;→&#x20;*****Data Sources → Network → Sensors*** area of your Vectra UI allows you to pair and manage network Sensors, configure a number of options related to Sensor pairing and registration, and change the CLI `vectra` user password for paired devices (Sensors and Stream). For more details, please see the [Respond UX deployment](/deployment/getting-started/respond-ux-deployment-guide) or [Quadrant UX deployment ](/deployment/getting-started/quadrant-ux-deployment)guides.

Navigate in this area to ***Sensor Configuration > Sensor Pairing and Registration.***

Editing this area will allow you to alter the default way a Sensor will attempt to pair with a Vectra Brain and allow you to enable or disable Virtual Sensor Automatic Pairing (Auto Pairing). Additionally, this area provides a link to generate a new Sensor Registration Token (SRT) or to copy an existing SRT.

### Pair using the Detect Brain

<figure><img src="/files/QUwDKDJ7oBhkn3gaAtu7" alt="" width="563"><figcaption></figcaption></figure>

* If you have a DNS name configured in *Configuration → COVERAGE → Data Sources → Network → Brain Setup → Brain*, then the **Pair using the Detect brain** area will provide a choice between the configured DNS name and the management IP address (MGT1).
* If you do not have a DNS name configured, there will only be one option present using the configured IP for the management interface of your Brain.
  * It may take a few minutes after adding a DNS name in your Brain setup for the choice to appear in this area.
* This setting only affects the default pairing mode for Sensors used in future pairing operations.
  * Any previously paired devices will remain paired in the same manner they were originally paired.
  * Regardless of setting, the `set brain` command available at the CLI of the Sensor will allow you to attempt pairing via hostname or IP.
* Should you choose to change the pairing method for previously paired devices, you will need to unpair the previously paired devices and re-pair them.

### Virtual Sensor Automatic Pairing "Auto Pairing"

* This setting allows you to choose if you want to automatically pair (auto pairing) with Sensors that have a valid Sensor Registration Token (SRT) configured.
  * Even though the setting name implies that this will only impact virtual Sensors, any Sensor, including physical appliances can auto pair if a valid SRT is configured when pairing is attempted.
* It is recommended to allow auto pairing during initial setup or during large Sensor rollouts.
* When you are done deploying vSensors, you may turn this off to enhance security posture.

### Sensor Registration Token (SRT)

<figure><img src="/files/2N4eoIUR3ZgQgx9JZj4T" alt="" width="563"><figcaption></figcaption></figure>

* Use this area to see the status of SRTs (how long before an SRT expires), copy a SRT, and to generate new SRTs.
* SRTs are used to validate Sensors attempting to register to a Brain and reset after 24 hours.
* SRTs are used in the **Registration Token** field in the Sensor deployment template for Sensors deployed in IaaS clouds such as AWS, Azure, and GCP.
* While the SRT is required for cloud Sensor deployment, it is optional for physical Sensors and virtual Sensors.
* Use of a SRT will allow you to pair a Sensor with any Brain in your organization. This can be useful for disaster recovery scenarios where a device may have been paired to another Brain previously.

**SRT Retrieval and Generation at the CLI**

SRT retrieval and generation can also be accomplished at the CLI of your Brain. For details on how to access the CLI of your Brain, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for CLI SRT retrieval and generation example.</summary>

Use the `show registration-token` command as shown below:

```
vscli > show registration-token --help
Usage: show registration-token [ -g ]

  Get registration token.

Options:
  -g, --generate  Generate new token
  -h, --help      Show this message and exit.

vscli > show registration-token
Output:
    Error: registration token not found

vscli > show registration-token -g
Output:
    Expiration: 2026-01-30T18:49:35.518524+00:00,
    Token: nvxfrxzknbchrbztyvlchkbnhwlxhdvz
```

</details>

## Configuring the Brain Location and SRT on a Sensor

Sensors can have the Brain location (Hostname or IP Address) used for pairing configured automatically or manually. Additionally, the Sensor Registration Token (SRT) can be set to allow a Sensor to pair with any Brain type as long as the SRT is valid.

### Automatic Configuration Scenarios

**vSensors for traditional hypervisors**

* These are used in platforms such as VMware, Nutanix, KVM, Hyper-V, etc.
* When a vSensor image is downloaded from your Brain, it is preconfigured with the location of the Brain it was downloaded from.
* The location encoded into the image is based on the hostname or IP address that was selected in the [Sensor Pairing and Registration](#sensor-pairing-and-registration-settings) settings area above.
* The SRT is not required as registration information is encoded into the vSensor image that was downloaded.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**Physical Sensors**

* An online Vectra Brain will update the Vectra cloud with its location.
* The location is based on if you have selected to pair via the management IP or hostname in the [Sensor Pairing and Registration](#sensor-pairing-and-registration-settings) settings area above.
* When an online Sensor connects to the Vectra cloud, the location will be provided to the Sensor so that it can announce itself as available for pairing to the Brain.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

### Manual Configuration Scenarios

**vSensors for IaaS clouds such as AWS, Azure, and GCP**

* Since all cloud vSensors are either deployed from the cloud provider marketplace or via a generic image shared directly to you prior to deployment, all cloud vSensor images are identical and are not preconfigured with registration information or a Brain location.
* The Brain location and Sensor Registration Token are configured as part of the deployment process for each cloud vSensor. This is typically done through a customizing a template in the cloud provider or a editing a template prior to deployment using a CLI command.
  * For more details, please see [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances) for the deployment guide for you vSensor.
* Post deployment
  * If you are able to reach the command line of the vSensor and log in, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**vSensors for traditional hypervisors**

* These are used in platforms such as VMware, Nutanix, KVM, Hyper-V, etc.
* As discussed in the [automatic configuration scenarios](#automatic-configuration-scenarios) above, these vSensor images are preconfigured with registration information and Brain location unique to the Brain that the image was downloaded from, and cannot normally be paired to other Brains in your environment unless a new Brain location and SRT are configured.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**Physical Sensors**

* As discussed in the [automatic configuration scenarios](#automatic-configuration-scenarios) and [pairing overview](#pairing-overview) above, online physical Sensors can retrieve location and registration information from the Vectra cloud.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

### Manual Configuration Steps

To manually configure a Sensor with a Brain location or Sensor Registration Token (SRT) you must first access the command line interface (CLI) of the Sensor. For details on how to access the CLI of your vSensor, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for manual configuration details.</summary>

#### Showing and Setting Brain Location

Use the `show brain` and `set brain` commands as shown below:

```
vscli > show brain
Brain IP: 172.16.12.10

vscli > set brain --help
Usage: set brain < ip_or_hostname >

  Set brain to the specified IP or hostname

Options:
  -h, --help  Show this message and exit.

vscli > set brain 172.16.12.12
Brain IP: 172.16.12.12
Set Brain IP: success
```

#### Showing and Setting the SRT

Use the show registration-token and set registration-token commands as shown below:

```
vscli > show registration-token --help
Usage: show registration-token

  Show current registration token

Options:
  -h, --help  Show this message and exit.

vscli > show registration-token
Output:
    Token: dtkwwbctkzfmppjblchgthkgjcvhcxnv

vscli > set registration-token --help
Usage: set registration-token < token >

  Set current registration token

Options:
  -h, --help  Show this message and exit.

vscli > set registration-token nvxfrxzknbchrbztyvlchkbnhwlxhdvz
Unpair: successful
Registration token has been set
```

</details>

## Pairing Sensors

### Communications Requirements

In order to pair with a Brain, per the [firewall requirements](/deployment/getting-started/firewall-requirements), Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

### Pairing Timing Expectations

Some processes related to pairing happen on regular intervals and are not immediate. It is normal for a Sensor to take a few minutes to show up in the Vectra UI as **Available** and move through different pairing states. For example, check in to the Vectra cloud happens every 5 minutes for a physical Sensor that has not yet communicated with the Vectra cloud. Other processes related to pairing can also take some time.

If a Sensor does not appear in the Brain *Configuration → Data Sources → Network → Sensors* page, check that the vSensor has IP connectivity and that TCP port 443 (HTTPS) is permitted through your firewall.

If pairing has begun, i.e. you see **Pairing** in the UI or CLI, and pairing has not completed in 5 to 10 minutes, the most likely scenario is that firewall rules are not allowing TCP/22 (SSH) from the Sensor to the Brain. In such a scenario, you should click the cancel pairing button in the UI, which will reset the Sensor status to **Available**, address connectivity issues, and reinitiate the pairing process.

For more near real-time status than what is shown in the UI served from Vectra's cloud in RUX deployments, or the UI served locally from your Brain in QUX deployments, the `show sensors` command can be used at the CLI of the Brain.

### Sensor Pairing States and Status

Admins can see the list of Sensors in the Vectra UI under *Configuration* → *Data Sources → Network → Sensors.* The Brain will attempt to query the Vectra cloud at <https://update2.vectranetworks.com> as the page loads.

**Sensor Pairing States**

* Available
  * Physical Sensor has contacted the Vectra cloud and Brain successfully and is available for pairing.
  * Physical Sensor with valid SRT has announced itself successfully to the Brain and is available for Pairing.
  * vSensor (cloud or traditional hypervisor deployed) has announced itself successfully to the Brain and is available for pairing.
* Pairing
  * A pairing request has been sent to the Vectra cloud from the Brain for online physical Sensors.
  * Any other Sensor type with a valid SRT is in the process of pairing.
* Paired
  * A Sensor has successfully paired with the Brain.
* Unpairing
  * A Sensor is in the process of unpairing.

**Sensor Status**

* Connected
* Not Connected
* Unpairing

<figure><img src="/files/2jZubc39RMt1py9uWFj9" alt=""><figcaption></figcaption></figure>

Pairing states and the list of Sensors can also been at the CLI of your Brain appliance. For details on how to access the CLI of your Brain, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for example using the <code>show sensors</code> CLI command.</summary>

```
vscli > show sensors -h
Usage: show sensors [ filter ]

  Show associated sensors

  FILTER is an optional query string to limit the results displayed. By
  default, all columns are searched but the query can be limited by using the
  format <column name>:<query>

Options:
  -h, --help  Show this message and exit.
v
scli > show sensors
Name                             |Ip            |Pairing  |Location              |Version    |Last Seen          |Luid    |Serial Number
V2b2db52176334e968c27a5d2a33720c0 192.168.54.201 available None                   9.0.0-18-57 2025-10-22 12:50:05 53a71kvk V2b2db52176334e968c27a5d2a33720c0
TB - Traffic Mirroring            192.168.55.239 paired    TB-Traffic Mirror Test 9.4.3-1-32  2026-01-29 19:37:09 qx70f0wr V11dd189d440e4e93b6bd6b5f5d1d484b
```

</details>

### Sensor Registration Token Pairing

<figure><img src="/files/mvpnCMNae5dh5GXjfTp2" alt=""><figcaption></figcaption></figure>

When a Sensor is configured with a valid [Sensor Registration Token (SRT)](#sensor-registration-token-srt), once a Sensor of any type is able to reach the Brain (see [communications requirements](#communications-requirements)), and shows as **Available,** click the pairing button as shown in the above screenshot to open a pairing dialog box.

<figure><img src="/files/Waq8H2P6yfgI2d7U6Tvy" alt="" width="375"><figcaption></figcaption></figure>

Click **Pair Sensor** to begin pairing. The Sensor will move through **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

### Auto Pairing

If [auto pairing](#virtual-sensor-automatic-pairing) is enabled, and the Sensor has a valid Sensor Registration Token, once the Brain sees the Sensor as available, pairing will be completed automatically.

Once a Brain sees the Sensor as **Availabl**e, Sensors will move through **Available**, **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

{% hint style="info" %}
**Please Note:**

* Physical appliances cannot engage in auto-pairing immediately out of the box. They must first be configured with a valid Sensor Registration Token (SRT).
* If a physical appliance shows as **Available** for pairing, and the admin initiates pairing, pairing will complete automatically if online pairing is possible.
  {% endhint %}

### Online Pairing (Physical Sensors Only)

<figure><img src="/files/mvpnCMNae5dh5GXjfTp2" alt=""><figcaption><p>Screenshot is from a vSensor. The <strong>TYPE</strong> would show the model number for physical appliances.</p></figcaption></figure>

Out of the box, physical Sensors will attempt to reach out to the Vectra cloud once they are online.

Once a physical Sensor/Stream appliance shows as **Available** in your Vectra UI, click the pairing button as shown in the above screenshot to open a pairing dialog box.

{% hint style="info" %}
When a physical appliance cannot reach Vectra's updater service because a proxy is required in the customer’s environment to reach outside destinations, the `set brain` command should be used to set the Brain IP or hostname that the Sensor or Stream appliance will attempt to pair with. Sensors do not support proxy configuration.
{% endhint %}

You will then be presented with a dialog box where you can start the pairing process.

* Click the **Pair Sensor** button to begin pairing.
* The Brain will update the Vectra Cloud with its MGT1 IP address or hostname (depending on if you have selected to [pair by hostname or IP](#pair-using-the-detect-brain) and posts a request for the Sensor to initiate the pairing process.
* If the Sensor has access to the Vectra Cloud, upon its next check in (every 5 min), it will now retrieve the location of the Brain from the Vectra cloud and attempt to connect to the Brain.
* If the Sensor does not have access to the Vectra Cloud or is unable to contact the Brain (e.g. the Sensor cannot reach the Brain's IP address in a NAT or proxy environment), the Sensor should be manually instructed to pair with the Brain from the Sensor CLI using the `set brain` command using an IP address for the Brain's MGT1 that will reach the Brain's NAT address from the Sensor or hostname of the Brain.

The Sensor will move through **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

**Online Pairing Summary:**

Appliance serial numbers and keying information are associated with customer accounts during provisioning. Under normal circumstances, if both the Brain and physical Sensor or Stream can reach Vectra’s updater service at `https://update2.vectranetworks.com`, the following high-level diagram explains the standard pairing process:

![](/files/vEenppEFOpLU964W9XJR)

### Pairing in an Air-Gapped Environment vs Offline Pairing

While true air gap environments are typically relatively rare, customers may still need to deploy in environments where none of the components in your deployment can reach the Vectra cloud. A cloud deployed vSensor that can't reach the internet from its VPC could still be consided an air gap deployment from that perspective.

#### **Air-Gapped Pairing**

**Physical Appliances**

While Vectra NDR and Stream can function in full air gapped environments, this does mean that a Sensor Registration Token (SRT) will be required to pair physical Sensors.

**Traditional Hypervisor vSensors**

Traditional hypervisor based vSensors are not impacted because the virtual machine image downloaded from the Brain comes with the keying information needed to allow vSensors to communicate to the Brain. As long as the vSensors can contact the Brain they can pair automatically or via user initiated pairing. They can also use a SRT to authenticate pairing.

**Cloud vSensors**

Similarly, cloud vSensors are required to use a SRT for pairing and only need to be able to contact the Brain to pair and do not need to talk to the Vectra cloud.

**To pair in an air gap environment:**

* Retrieve or generate a current [Sensor Registration Token](#sensor-registration-token-srt).
* Perform the `set registration-token <token>` command at the Sensor CLI.
* Finally perform the `set brain <IP or Hostname>` command at the Sensor CLI.
  * `set brain` should also delete existing brain location information but if there are any issues, the `del brain` command at the Sensor CLI can be used.
* The Sensor should become **Available** for pairing on the Brain.

#### **Offline Pairing (Physical Sensors Only)**

In offline pairing scenarios, if a Sensor is behind a proxy or firewall and cannot connect to the Vectra cloud, then a Sensor Registration Token (SRT) will be required to complete pairing.

The **Pair Sensor** button can be used to begin pairing. A valid Sensor Registration Token (SRT) must be configured. You must also configure the Brain location with the `set brain` command at the CLI of the Sensor.

## Additional Pairing Guidance

### Stream Appliance "Sensor" Pairing Details

As discussed in [about Sensor and Stream pairing](#about-sensor-and-stream-pairing), Stream devices pair in the same manner as Sensor devices. There are some post pairing differences:

A Stream appliance does not show in the Vectra UI on the normal Sensor management screen located at *Configuration → Data Sources → Network → Sensors*. Pairing status for a Stream appliance is available in *Configuration > Setup > Stream* in the *Pairing Status* area:

<figure><img src="/files/CnwbT7Q5NvuMIX5iPZL2" alt="" width="563"><figcaption></figcaption></figure>

A Stream appliance will show its' status if you use the `show sensors` command at the CLI.

### Post Pairing Guidance

Once paired, Sensors will attempt to synchronize software versions by downloading the latest update from the Brain and immediately applying it. The Sensor may become temporarily unavailable while this update is applied. This should only take a few minutes to complete.

Certain vSensor CLI functions and traffic functions will become available only after the vSensor has fully updated. Depending on the specific version of the vSensor, you may see errors or warnings when running CLI functions during the period of time when the vSensor is still updating.

Sensors can be renamed or have their location labeled as desired by clicking on the pencil icon <img src="/files/A2Jl6Dr98rpqroDTzDga" alt="" data-size="line">on the right of the vSensor and editing the details.

### Pairing to New or Changed Brains

#### Pairing to Brain With Changed Location

If the Brain location must be changed there are two processes that can be used to associated existing Sensors with a new Brain:

**Preferred Method:**

* Change the Brain IP address or hostname.
* Redirect all Sensors to the new Brain location using the `set brain` command at the CLI of the Sensor.
  * Previously paired Sensors can simply be redirected because the Brain already has the required registration information for these Sensors.
    * This is also the same for new or different Brains restored from Backups.
  * Unpaired Sensors can use the Sensor Registration Token if needed.
    * For example: The new Brain isn’t restored from backup, is air-gapped, etc

**Alternate Method:**

You can also unpair all Sensors, change the Brain location (hostname or IP address), and then pair all Sensors again. This could cause some buffered data on the Sensors to be lost.

#### Pairing to a Different Brain

* If you have a Brain that will not be restored from backup that you wish to pair an existing Sensor to, this is possible via the use of a Sensor Registration Token.
  * Retrieve or generate a current [Sensor Registration Token](#sensor-registration-token-srt).
  * Perform the `set registration-token <token>` command at the Sensor CLI.
  * Finally perform the `set brain <IP or Hostname>` command at the Sensor CLI.
    * `set brain` should also delete existing brain location information but if there are any issues, the `del brain` command at the Sensor CLI can be used.
  * The Sensor should become **Available** for pairing on the new Brain and will pair automatically if [auto pairing](#virtual-sensor-automatic-pairing) is enabled.

#### Terminating Existing Sensor / Brain Tunnels

In all cases, existing tunnels have to terminate to re-establish connection to a new Brain. This can be accomplished a few different ways.

* Naturally, because the original Brain is no longer reachable due to firewall change, hardware or software failure, etc.
* Using the `set brain` command at the CLI will terminate an existing tunnel and attempt to start pairing with a new Brain.
  * `del brain` can be used to break the tunnel but not set a new Brain location.
* In normal operation, the Sensor can simply be unpaired from its existing Brain. To use the **Unpair** option, the Brain must be connected to the Vectra Cloud and the Sensor must be powered on with an active tunnel to the original Brain.
  * Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors*, click on the Sensor you wish to unpair and click on the **Unpair** button.
  * After unpairing which could take a few minutes, the status of the Sensor should change to **Available**.

<figure><img src="/files/zVRwJeWDyoWKyYcJV4cy" alt=""><figcaption></figcaption></figure>

* Using the **Force Unpair** option in your Vectra UI for the target Sensor.
  * This will unpair the Sensor from the original Brain and when the Sensor attempts communication to the original Brain the tunnel will not function.
  * **Force Unpair** is the same as deleting for a vSensor. You cannot delete a physical Sensor (talk to Vectra Support if this is required).


# Azure vSensor

Deploy and pair Vectra vSensors in Microsoft Azure environments.


# Introduction and requirements

Azure vSensor deployment introduction and requirements including Sensor Registration Token, Brain and Sensor communications requirements, and Azure requirements.

## Introduction

This document describes the pre-requisites, specifications, and steps required to deploy a Vectra NDR (formerly Detect for Network) Virtual Sensor (vSensor) in an Azure subscription to monitor cloud Infrastructure-as-a-Service workloads. These Sensors can be paired with Brains of any type.

Azure Sensors can be deployed in configurations that support up to 1 Gbps or 2 Gbps of network throughput per Sensor. The input to the Sensor can be from any VxLAN-based 3rd party packet broker or the Microsoft virtual network tap (VTAP) when it becomes available in your region.

Azure Sensors can be used in both Respond UX and Quadrant UX deployments. For more detail on Respond UX vs Quadrant UX please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux). One of the below guides should be the starting point for your overall Vectra deployment:

* [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Vectra Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

{% hint style="info" %}
**Special Note:**

**Regarding Azure Load Balancer changes and prior Vectra Azure vSensor deployments:**

Microsoft no longer supports basic load balancer deployment as of March 2025. For more details, please see this [Microsoft Azure update](https://azure.microsoft.com/en-us/updates?id=azure-basic-load-balancer-will-be-retired-on-30-september-2025-upgrade-to-standard-load-balancer).

Vectra’s previous version of the Azure vSensor deployed with an Azure Basic Load Balancer. The current version does not deploy with any Azure load balancer and is simply a VM with mgt and traffic (capture) NICs. To redeploy, deploy the new vSensor, redirect traffic to its capture port, and then delete the old vSensor.
{% endhint %}

## Requirements and Preparation

### Sensor Registration Token (SRT)

The ***Configuration*****&#x20;→&#x20;*****COVERAGE*****&#x20;→&#x20;*****Data Sources → Network → Sensors*** area of your Vectra UI allows you to pair and manage network Sensors, configure a number of options related to Sensor pairing and registration, and change the CLI `vectra` user password for paired devices (Sensors and Stream). Navigate in this area to ***Sensor Configuration > Sensor Pairing and Registration.***

<figure><img src="/files/2N4eoIUR3ZgQgx9JZj4T" alt="" width="563"><figcaption></figcaption></figure>

* During Sensor deployment a valid Sensor registration token must be presented to the Brain so that the Sensor can become **Available** to Pair. This token can be created in the Vectra UI or at the CLI of the Brain. It is valid for 24 hours and can be regenerated at any time.
* For full details on pairing processes, please see [Pairing Azure vSensors](/deployment/ndr-virtual-cloud-appliances/azure-vsensor/pairing-azure-vsensors).
* If you have a valid token, you can **Copy** it here for later use using the link.
  * Otherwise, click the **Generate New Sensor Registration Token** link.
  * Use this token for Sensor deployment (tokens expire 24 hours after generation).

### Brain and Sensor Communications Requirements

A Sensor (or Stream appliance) can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.

Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

Please work with your security and networking contacts to ensure that the Sensor will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for the Sensor will come from the Brain.

For full details on all potential firewall requirements in Vectra deployments, please see [firewall requirements](/deployment/getting-started/firewall-requirements).

### Azure Requirements

To deploy from the Azure marketplace, you will require several pieces of information. The deployment section will provide additional details.

* **Subscription** – The subscription you wish to deploy into.
* **Resource group** – The resource group you wish to deploy into
* **Region** – The region you wish to deploy into.
* **Base Name** – Base name for all the resources that will be created as part of this deployment.
* **Instance Size** – VM instance size for Detect for Network Sensor. DS3\_v2 supports approximately 2 Gbps and Ds11\_v2 supports approximately 1 Gbps.

![](/files/eeb331d4b0bc252b87b2f8802c35eea55f4365d5)

{% hint style="info" %}
**Please Note:**

Vectra product and engineering teams monitor the changing landscape of available IaaS cloud instance types. Occassionally customers will ask if a specific new instance type is supported.

There are a number of factors that can cause Vectra AI to stay with a specific instance type versus a newer one such as:

* Cost increase vs performance increase - sometimes a newer instance, for example, might cost 17% more but only increase performance by 10%.
* Availability - not all new instance types are always available in all the locations that Vectra AI supports.

Please reach out to your account team if you have questions about specific instance types that aren't supported.
{% endhint %}

* **Virtual network** – The virtual network to deploy the vSensor into.
* **Management Subnet** - Subnet for the managment interface. This will communicate with your Brain appliance after pairing is completed.
* **Traffic Subnet** - Subnet for the traffic interface. Traffic to analyze will be pointed here.
* **Brain Hostname or IP Address** - The IP address or the Fully Qualified Domain Name (FQDN hostname) of the Vectra Brain.
  * This address must be reachable from the Sensor’s management subnet over port 22 and 443.
* **Registration Token** - The SRT created in [Sensor Registration Token](#sensor-registration-token-srt) earlier.
* **Public SSH Key** – Generate an RSA SSH key pair using any standard tool. Enter the public key in this field. Retain the private key safely for SSH access to the Sensor. For more details on logging in to a Sensor at the CLI see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli).
  * This will allow the `vectra` user to log into the Sensor’s command line interface.
  * Azure has a SSH Keys function that can be loaded in another tab to generate a key pair.
  * You may need to make the key readable to you using a command such as:
    * `chmod 400 vectra.pem`
  * Example login command:
    * `ssh -i vectra@BrainHostnameOrIP`
* **SSH user** (only `vectra` will work) – Leave this at the default.

### **Azure Network Security Group Considerations**

The vSensor deployment does not create any Azure Network Security Groups. If you choose to apply a security group, ensure the following connectivity is allowed.

<table data-header-hidden><thead><tr><th width="131.1640625"></th><th width="166.765625"></th><th width="163.6015625"></th><th width="288.1875"></th></tr></thead><tbody><tr><td><strong>Source</strong></td><td><strong>Destination</strong></td><td><strong>Protocol/Port</strong></td><td><strong>Description</strong></td></tr><tr><td>Admin Hosts</td><td>vSensors</td><td>TCP/22 (SSH)</td><td>CLI access to vSensor</td></tr><tr><td>Brain</td><td>vSensors</td><td>TCP/22 (SSH)</td><td>Remote management and troubleshooting</td></tr><tr><td>vSensors</td><td>Brain</td><td>TCP/22 (SSH) TCP/443 (HTTPS)</td><td>Pairing, metadata transfer, and ongoing communication</td></tr><tr><td>Traffic Source</td><td>Front end IP for LB</td><td>VXLAN 4789</td><td>Allows traffic to the Front end IP of the Load Balancer created during vSensor deployment.</td></tr></tbody></table>


# Deployment from Azure marketplace

Deploying the Azure vSensor image from the Azure marketplace.

* Browse to the Azure Marketplace and search for **Vectra**.
* Under the **Vectra Sensor & Stream for Azure** offering, click on **Create** and select the **Cognito Sensor**.

![](/files/cffe873499e8b7173323075decf0f44461afc2b7)

* You will now need to fill in details on the **Create Vectra Sensor & Stream for Azure** screen that follows.

<img src="/files/2a15ea29b1322c09a6628c3c84b7d316e4805f8f" alt="" width="563">

During this process you will be asked to fill in the following fields:

* **Subscription** – This should default to your current subscription. All resources in an Azure subscription are billed together.
* **Resource group** – Each Sensor must be deployed in a different resource group. Either select an existing resource group that is empty (Azure requirement), or create a new resource group using the **Create new** link.

{% hint style="warning" %}
**Please Note:**

Azure requires that the selected resource group be empty when deploying a VM image from the Azure Marketplace.
{% endhint %}

* **Region** – Select the region to deploy the Sensor into. To optimize costs, always keep the source and target (Sensor and Brain) in the same region.
* **Base Name** – Base name for all the resources that will be created as part of this deployment.
* **Instance Size** – VM instance size for Detect for Network Sensor. DS3\_v2 supports approximately 2 Gbps and Ds11\_v2 supports approximately 1 Gbps.

![](/files/eeb331d4b0bc252b87b2f8802c35eea55f4365d5)

* **Virtual network** – Select an existing virtual network (VNet) or choose the **Create new** option and create a new VNet to deploy the Sensor into.

{% hint style="warning" %}
**Please Note:**

When choosing the “Create new” option, Azure previously defaulted the traffic subnet to be out of range with respect to the VNet address space. In the screenshot example below, this could be remedied by simply editing the traffic subnet to 10.3.0.64/26.

If the chose subnets are not within the address space of the overal virtual network, the deployment will fail. Please choose appropriate ranges for the VNet, Management Subnet, and Traffic Subnet are selected. Edit if necessary.
{% endhint %}

![](/files/45708ddf42bf478182c215e3ec1dfb604433e031)

* **Management Subnet** - The Sensor must be able to reach your Vectra Brain over HTTPS (443) and SSH (22). Select a management subnet that can enable this reachability.
* **Traffic Subnet** - This is the subnet where the Sensor can receive traffic from the packet broker over VxLAN (UDP 4789) or directly from the Azure VTAP (when available in your region).
* **Brain Hostname or IP Address** - The IP address or the Fully Qualified Domain Name (FQDN hostname) of the Vectra Brain.
  * This address must be reachable from the Sensor’s management subnet over port 22 and 443.
* **Registration Token** - Please input the [Sensor Registration Token](/deployment/ndr-virtual-cloud-appliances/azure-vsensor/introduction-and-requirements#sensor-registration-token-srt) you collected earlier from your Brain appliance.
* **Public SSH Key** – Input the [public SSH key you generated earlier](/deployment/ndr-virtual-cloud-appliances/azure-vsensor/introduction-and-requirements#azure-requirements).
* **SSH user** (only `vectra` will work) – This must be left at the default.
* Click **Review + create** and you’ll be presented with a screen where you can review your configuration before creating.

<img src="/files/45892f0125f9700394fe5fba134cbc8d2a3f2dc0" alt="" width="563">

* Click **Create**.
  * Some status messages will appear on the top right and then you will see another screen with full details as the deployment progresses and then completes.

![](/files/7f8d20cdf8efa8a12e0ba24ded5069150f168e63)


# Azure Host ID integration

Configuring HostID integration between your Vectra Brain and the Azure Resource Manager.

## Introduction

To enable efficient investigation of cloud hosts, the Vectra NDR can be configured to periodically query the API offered by the Azure Resource Manager to gather additional information about hosts running in Azure. This information contributes to Vectra’s automated Host identification (Host ID) and adds information to the Host entity details screen.

It is a best practice is to enable this integration. Vectra NDR attributes detections to a Host or an Account. For some algorithms that support learning, detections must be attributable to a Host (including statically defined hosts), rather than a generic Host container (denoted by **IP-x.x.x.x** in the Vectra UI). Enabling this integration can help contribute to more complete detection as a result.

Please see this example screenshot (Quadrant UX) below of a host in Azure where additional context was pulled through API calls:

![](/files/ZXvWSPrGOTd2NRbQU2Q8)

As you can see, the integration provided the following (viewable by drilling down to the Host and then the Details tab):

* Host ID artifacts including a unique identifier and hostname
* Resource group, Admin, NICs, and Last Seen date/time
* Summary information on the left-hand side including OS, Host Name, and Location

## Requirements

Creating an Azure AD application and service principal that can read Azure management APIs is required. At minimum, read access to the following endpoints of the Azure resource manager will be required:

* <https://management.azure.com/subscriptions>
* <https://management.azure.com/subscriptions/SUBSCRIPTION/providers/Microsoft.Network/networkInterfaces>
* <https://management.azure.com/subscriptions/SUBSCRIPTION/providers/Microsoft.Compute/virtualMachines>
* <https://management.azure.com/subscriptions/SUBSCRIPTION/providers/Microsoft.Compute/virtualMachineScaleSets>

An alternative is to provide the Vectra Brain permissions to query the following APIs (this is a wider scope):

* `Microsoft.Network//read`
* `Microsoft.Compute//read`

The simplest way to accomplish this is to apply the built-in Azure **Reader** role to the application. This will allow your Vectra Brain to view all resources but does not allow it to make any changes.

Once created, you will then enter the Application (client) ID, Directory (tenant) ID, and Application Secret value into the Vectra UI to enable the integration. Multiple credential sets can be added if required.

## Configuration Example

**Resources**

* Full instructions for creating Azure AD application and service principal are available from Microsoft here:
  * <https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal>
* Details regarding Azure built-in roles are available from Microsoft here:
  * <https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles>

### Azure Steps

To enable this functionality, the following steps need to be completed for every Azure subscription where there are Sensors deployed. In this example we will apply the “Reader” role at the Azure Subscription level.

* After signing in to the [Azure AD portal](https://aad.portal.azure.com/), navigate to *Azure Active Directory > App registrations* and select **New registration**.
* Give the application a **Name** of your choosing and choose a supported account type.
* A Redirect URI is not required.

![](/files/QZxxTNZ1L85I9MBv4xvD)

* Click **Register** and then copy the **Application (client) ID** and **Directory (tenant) ID** for later use:

![](/files/9GgCqwa2zMrXUtxJOVC4)

* Now we will assign an Azure role to the application.
* In the [Azure portal](https://portal.azure.com/) select **Subscriptions** and select which subscription to apply the role to by clicking on it.
* Select **Access control (IAM)**, then click **+ Add**, and then click **Add role assignment**.

![](/files/DFyRj40YbQvnGemZ0C0O)

* Select **Reader** under Role.
* Leave **Assign access to** unchanged (it should say **User, group, or service principal**)
* Search for your application and select it.
* Click **Save**.

![](/files/Phcw3SBFAsq8FarcSwN3)

* Next we will create a new application secret.
* In the [Azure AD portal](https://aad.portal.azure.com/), navigate to *App registrations* and select your application.
* Select **Certificates & secrets**, click **+ New client secret**, enter a **Description** and select and when you want this to expire:

![](/files/DgiSjWECqV1sCoAeeyuv)

* Click **Add**.
* Once created, you must copy the **Value** before navigating away from this screen as you cannot retrieve it later.

![](/files/irl8IPiF8rb59TKJ7uXE)

### Vectra Steps

* To complete the integration, in the Vectra UI, browse to *Configuration >* *SETUP > External Connectors*.
* Click on the pencil or **Edit** link for Azure.
* Toggle the integration to **On** and fill in the **Application (client) ID**, **Directory (tenant) ID**, and **Application secret values** that you created above:
* Click **Save**. Multiple sets of credentials can be configured if required for different subscriptions.

![](/files/zeqFAa2BZJmwyXsYZ1tx)

* The connection will best tested and if successful, you will see a green checkmark showing that Azure Resource Manager integration has been completed.

![](/files/jJUBkx5PJeCMpC5SsT7U)

## Viewing and Modifying Virtual Networks Considered by the Connector

The connector will only look at virtual machines or virtual machine scale sets that belong to some virtual networks, not necessarily all virtual networks that the credentials have access to. Specifically, by default, the connector will only look for virtual machines with network interfaces in the virtual networks where a Vectra Azure vSensor traffic/capture interface is deployed into, and all the virtual networks with a "double peering" to it (if the Sensor traffic interface lives in virtual network A, and virtual network A is peered with virtual network B and C, but only virtual network B is peered with virtual network A, then the connector will look for virtual machines in virtual networks A and B only). If a virtual machine has multiple network interfaces, the connector will provide host identification only for the IP addresses belonging to interfaces on monitored virtual networks.

Vectra limits the scope of the connector to only virtual networks that can reach an Azure vSensor for the following reasons:

* Vectra wants to avoid an excessive number of connections to the Azure resource manager.
* To improve performance, Vectra wants to avoid storing unnecessary information in the platform for resources that we are not monitoring.
* In the cloud it is possible that you may have some isolated virtual networks that are not monitored by Vectra Sensors but have overlapping IP space with some other networks that are monitored. Duplicate IPs are not supported by Vectra. To avoid Host ID issues, we only consider virtual machines on the networks that appear reachable by our Sensors.

If you want to add or remove some virtual networks from the set of virtual networks that Vectra monitors, you can do so through the CLI (ssh to the Brain as the “vectra” user). This functionality is not available in the Vectra UI. The use case for adding or removing virtual networks could be the following:

* If you have some tunneling or forwarding enabled and Vectra Azure vSensors see traffic from virtual networks that are NOT directly connected to our vSensor:
  * You will want to add the networks to the monitored networks list to extend Host ID coverage to the tunneled/forwarded traffic’s associated Hosts.
* If you do NOT have any Azure vSensors deployed, but mirror Azure traffic into your data center where you have Vectra physical or virtual Sensor coverage:
  * You will want to add the networks to the monitored networks list to extend Host ID coverage to the mirrored traffic.
* If you do have some overlapping IP space on a network that appears reachable by our vSensor, but that it is not monitored by our vSensor:
  * You will want to remove the overlapping networks from the monitored networks to avoid any Host ID issues.
* If you have a lot of peered networks but only some are monitored by the vSensor:
  * You will want to remove the non-monitored networks from the monitored networks list to increase performance and reduce load on the Azure resource manager.

The command to add or remove virtual network from the Vectra CLI is "**set azure vnets**". The command has a very helpful help message illustrating its use:

<img src="/files/0Rdp1MwmFL0DDTsBuyDW" alt="" width="563">

The command `show azure vnets` will show the virtual networks configuration, including the whitelist (networks to ADD), the blacklist (networks to REMOVE), the Sensors network, and finally the overall monitored networks, which is simply computed as ((Sensors networks + peered) + whitelist) - blacklist. It may take up to 10 minutes for the summarized `monitored networks` to update in the `show azure vnets` command output. Example of usage:

![](/files/GEBbSggd5a5cA8bzokX4)


# Pairing Azure vSensors

Pair Azure vSensors to a Brain using the Sensor Registration Token workflow (Azure vSensors do not support online pairing).

## Azure vSensor Pairing

The same content available on this documentation site under *Deployment → Appliance Operations →* [*Pairing appliances*](/deployment/appliance-operations/pairing-appliances) is shown below. Please note that Azure vSensors do NOT support online pairing and that content below specific to physical Sensors or traditional hypervisor based vSensors does not apply to Azure vSensors.

## About Sensor and Stream Pairing

Sensors and Stream appliances behave the same way from a pairing perspective. Because of this, you may see the **Sensor** term used in this document, your Vectra UI, or at the CLI of a Vectra appliance when sometimes the appliance in question is a Stream appliance.

Multiple Sensors can be attached to a single Brain while the Brain supports a single Stream appliance at a time. The exact limits for how many appliances can be paired to your Brain will depend on the Brain model or configuration. Please see [appliance specifications](/deployment/getting-started/appliance-specifications) for details.

{% hint style="info" %}
**Please Note:**

* From this point forward, the term "Sensor" will be used to represent both Sensor or Stream appliance types in this document.
  {% endhint %}

## Pairing Overview

Pairing is the process that allows Sensors to communicate with the Brain. All network sessions between an appliance and the Brain are initiated from the Sensor side.

There are three basic ways to pair a Sensor or Stream appliance with a Brain:

{% tabs %}
{% tab title="Using a Sensor Registration Token" %}
Using a Sensor Registration Token (SRT) works for any appliance type and is required for Sensors deployed in IaaS cloud environments such as AWS, Azure, and GCP.

* A Sensor Registration Token (SRT) is generated on the Brain and then configured on the Sensor or Stream appliance.
* Once the Sensor is configured with a Brain IP address or hostname, it will annouce itself to the Brain if powered on.
* The Brain will recognize the validity of the token and allow the Sensor to become available for pairing.
* A user will initiate pairing or use auto pairing (2nd tab above) if enabled.
  {% endtab %}

{% tab title="Auto Pairing" %}
Auto pairing is an option that can be enabled by administrators that allows some Sensor configurations to automatically pair with your Brain. If either of the two below states is true, and the Sensor can reach the Brain, pairing will be completed automatically when auto pairing is enabled.

* You have a vSensor for traditional hypervisor deployment (VMware, Hyper-V, Nutanix, KVM, etc) that was downloaded from your Brain, and is preconfigured with the location of the Brain and the registration information required for pairing.
* Appliances (physical and virtual) that are configured with a Sensor Registration Token can also auto pair with a Brain.
  {% endtab %}

{% tab title="Online Pairing (Physical Sensors Only)" %}
Online pairing is only supported for Vectra physical appliances that can reach the Vectra updater service and the Brain. If the Brain is behind NAT and not reachable via its configured IP, see [online pairing](#online-pairing-physical-sensors-only-1) for more details (the `set brain` command at the Sensor CLI will need to be used).

* Appliances are provisioned by Vectra and then shipped to a customer.
  * They are also associated to the customer account.
  * The Brain retrieves the list of provisioned Sensors from Vectra periodically.
* Sensors will retrieve the location of your Brain from Vectra when they come online.
* In the Brain UI, provisioned Sensors will show as **Available** for pairing.
* When pairing is attempted by the user, the Brain and Sensor will retrieve the required registration information from Vectra and complete the pairing process.
  {% endtab %}
  {% endtabs %}

Pairing is also supported in air-gapped environments and physical appliances can also be paired "offline" when required. For details please see [Pairing in an Air-Gapped Environment vs Pairing Offline](#pairing-in-an-air-gapped-environment-vs-pairing-offline).

### Pairing by Hostname vs IP Address

Sensors need to know the location of the Brain appliance so that they know what hostname or IP address to communicate with. Pairing by hostname is generally preferred over pairing by IP address for the following reasons:

* Failover scenarios are easier to manage because a replacement Brain can be setup with the same hostname as the original Brain even if the IP address will be different. Paired Sensors will be able to automatically re-pair with the new Brain once the DNS is changed (if the old Brain is offline, see [pairing to new or changed Brains](#pairing-to-new-or-changed-brains) for more details). This is because the backup contains Sensor state information.
* If your Brain appliance is configured with a DHCP address for its management port instead of a static IP address and you have paired by hostname, even if the IP address of the Brain changes, Sensors will still be able to communicate with the Brain they are paired to.

## Sensor Pairing and Registration Settings

The ***Configuration*****&#x20;→&#x20;*****COVERAGE*****&#x20;→&#x20;*****Data Sources → Network → Sensors*** area of your Vectra UI allows you to pair and manage network Sensors, configure a number of options related to Sensor pairing and registration, and change the CLI `vectra` user password for paired devices (Sensors and Stream). For more details, please see the [Respond UX deployment](/deployment/getting-started/respond-ux-deployment-guide) or [Quadrant UX deployment ](/deployment/getting-started/quadrant-ux-deployment)guides.

Navigate in this area to ***Sensor Configuration > Sensor Pairing and Registration.***

Editing this area will allow you to alter the default way a Sensor will attempt to pair with a Vectra Brain and allow you to enable or disable Virtual Sensor Automatic Pairing (Auto Pairing). Additionally, this area provides a link to generate a new Sensor Registration Token (SRT) or to copy an existing SRT.

### Pair using the Detect Brain

<figure><img src="/files/QUwDKDJ7oBhkn3gaAtu7" alt="" width="563"><figcaption></figcaption></figure>

* If you have a DNS name configured in *Configuration → COVERAGE → Data Sources → Network → Brain Setup → Brain*, then the **Pair using the Detect brain** area will provide a choice between the configured DNS name and the management IP address (MGT1).
* If you do not have a DNS name configured, there will only be one option present using the configured IP for the management interface of your Brain.
  * It may take a few minutes after adding a DNS name in your Brain setup for the choice to appear in this area.
* This setting only affects the default pairing mode for Sensors used in future pairing operations.
  * Any previously paired devices will remain paired in the same manner they were originally paired.
  * Regardless of setting, the `set brain` command available at the CLI of the Sensor will allow you to attempt pairing via hostname or IP.
* Should you choose to change the pairing method for previously paired devices, you will need to unpair the previously paired devices and re-pair them.

### Virtual Sensor Automatic Pairing "Auto Pairing"

* This setting allows you to choose if you want to automatically pair (auto pairing) with Sensors that have a valid Sensor Registration Token (SRT) configured.
  * Even though the setting name implies that this will only impact virtual Sensors, any Sensor, including physical appliances can auto pair if a valid SRT is configured when pairing is attempted.
* It is recommended to allow auto pairing during initial setup or during large Sensor rollouts.
* When you are done deploying vSensors, you may turn this off to enhance security posture.

### Sensor Registration Token (SRT)

<figure><img src="/files/2N4eoIUR3ZgQgx9JZj4T" alt="" width="563"><figcaption></figcaption></figure>

* Use this area to see the status of SRTs (how long before an SRT expires), copy a SRT, and to generate new SRTs.
* SRTs are used to validate Sensors attempting to register to a Brain and reset after 24 hours.
* SRTs are used in the **Registration Token** field in the Sensor deployment template for Sensors deployed in IaaS clouds such as AWS, Azure, and GCP.
* While the SRT is required for cloud Sensor deployment, it is optional for physical Sensors and virtual Sensors.
* Use of a SRT will allow you to pair a Sensor with any Brain in your organization. This can be useful for disaster recovery scenarios where a device may have been paired to another Brain previously.

**SRT Retrieval and Generation at the CLI**

SRT retrieval and generation can also be accomplished at the CLI of your Brain. For details on how to access the CLI of your Brain, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for CLI SRT retrieval and generation example.</summary>

Use the `show registration-token` command as shown below:

```
vscli > show registration-token --help
Usage: show registration-token [ -g ]

  Get registration token.

Options:
  -g, --generate  Generate new token
  -h, --help      Show this message and exit.

vscli > show registration-token
Output:
    Error: registration token not found

vscli > show registration-token -g
Output:
    Expiration: 2026-01-30T18:49:35.518524+00:00,
    Token: nvxfrxzknbchrbztyvlchkbnhwlxhdvz
```

</details>

## Configuring the Brain Location and SRT on a Sensor

Sensors can have the Brain location (Hostname or IP Address) used for pairing configured automatically or manually. Additionally, the Sensor Registration Token (SRT) can be set to allow a Sensor to pair with any Brain type as long as the SRT is valid.

### Automatic Configuration Scenarios

**vSensors for traditional hypervisors**

* These are used in platforms such as VMware, Nutanix, KVM, Hyper-V, etc.
* When a vSensor image is downloaded from your Brain, it is preconfigured with the location of the Brain it was downloaded from.
* The location encoded into the image is based on the hostname or IP address that was selected in the [Sensor Pairing and Registration](#sensor-pairing-and-registration-settings) settings area above.
* The SRT is not required as registration information is encoded into the vSensor image that was downloaded.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**Physical Sensors**

* An online Vectra Brain will update the Vectra cloud with its location.
* The location is based on if you have selected to pair via the management IP or hostname in the [Sensor Pairing and Registration](#sensor-pairing-and-registration-settings) settings area above.
* When an online Sensor connects to the Vectra cloud, the location will be provided to the Sensor so that it can announce itself as available for pairing to the Brain.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

### Manual Configuration Scenarios

**vSensors for IaaS clouds such as AWS, Azure, and GCP**

* Since all cloud vSensors are either deployed from the cloud provider marketplace or via a generic image shared directly to you prior to deployment, all cloud vSensor images are identical and are not preconfigured with registration information or a Brain location.
* The Brain location and Sensor Registration Token are configured as part of the deployment process for each cloud vSensor. This is typically done through a customizing a template in the cloud provider or a editing a template prior to deployment using a CLI command.
  * For more details, please see [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances) for the deployment guide for you vSensor.
* Post deployment
  * If you are able to reach the command line of the vSensor and log in, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**vSensors for traditional hypervisors**

* These are used in platforms such as VMware, Nutanix, KVM, Hyper-V, etc.
* As discussed in the [automatic configuration scenarios](#automatic-configuration-scenarios) above, these vSensor images are preconfigured with registration information and Brain location unique to the Brain that the image was downloaded from, and cannot normally be paired to other Brains in your environment unless a new Brain location and SRT are configured.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

**Physical Sensors**

* As discussed in the [automatic configuration scenarios](#automatic-configuration-scenarios) and [pairing overview](#pairing-overview) above, online physical Sensors can retrieve location and registration information from the Vectra cloud.
* If desired, the Brain location and SRT can be changed by following the [manual configuration steps](#manual-configuration-steps).

### Manual Configuration Steps

To manually configure a Sensor with a Brain location or Sensor Registration Token (SRT) you must first access the command line interface (CLI) of the Sensor. For details on how to access the CLI of your vSensor, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for manual configuration details.</summary>

#### Showing and Setting Brain Location

Use the `show brain` and `set brain` commands as shown below:

```
vscli > show brain
Brain IP: 172.16.12.10

vscli > set brain --help
Usage: set brain < ip_or_hostname >

  Set brain to the specified IP or hostname

Options:
  -h, --help  Show this message and exit.

vscli > set brain 172.16.12.12
Brain IP: 172.16.12.12
Set Brain IP: success
```

#### Showing and Setting the SRT

Use the show registration-token and set registration-token commands as shown below:

```
vscli > show registration-token --help
Usage: show registration-token

  Show current registration token

Options:
  -h, --help  Show this message and exit.

vscli > show registration-token
Output:
    Token: dtkwwbctkzfmppjblchgthkgjcvhcxnv

vscli > set registration-token --help
Usage: set registration-token < token >

  Set current registration token

Options:
  -h, --help  Show this message and exit.

vscli > set registration-token nvxfrxzknbchrbztyvlchkbnhwlxhdvz
Unpair: successful
Registration token has been set
```

</details>

## Pairing Sensors

### Communications Requirements

In order to pair with a Brain, per the [firewall requirements](/deployment/getting-started/firewall-requirements), Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.

* TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
* TCP/22 (SSH) - Used for Paired Sensor connections.

Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:

* update&#x32;**.**&#x76;ectranetwork&#x73;**.**&#x63;om or 54.200.156.238 over TCP/443 (HTTPS)

### Pairing Timing Expectations

Some processes related to pairing happen on regular intervals and are not immediate. It is normal for a Sensor to take a few minutes to show up in the Vectra UI as **Available** and move through different pairing states. For example, check in to the Vectra cloud happens every 5 minutes for a physical Sensor that has not yet communicated with the Vectra cloud. Other processes related to pairing can also take some time.

If a Sensor does not appear in the Brain *Configuration → Data Sources → Network → Sensors* page, check that the vSensor has IP connectivity and that TCP port 443 (HTTPS) is permitted through your firewall.

If pairing has begun, i.e. you see **Pairing** in the UI or CLI, and pairing has not completed in 5 to 10 minutes, the most likely scenario is that firewall rules are not allowing TCP/22 (SSH) from the Sensor to the Brain. In such a scenario, you should click the cancel pairing button in the UI, which will reset the Sensor status to **Available**, address connectivity issues, and reinitiate the pairing process.

For more near real-time status than what is shown in the UI served from Vectra's cloud in RUX deployments, or the UI served locally from your Brain in QUX deployments, the `show sensors` command can be used at the CLI of the Brain.

### Sensor Pairing States and Status

Admins can see the list of Sensors in the Vectra UI under *Configuration* → *Data Sources → Network → Sensors.* The Brain will attempt to query the Vectra cloud at <https://update2.vectranetworks.com> as the page loads.

**Sensor Pairing States**

* Available
  * Physical Sensor has contacted the Vectra cloud and Brain successfully and is available for pairing.
  * Physical Sensor with valid SRT has announced itself successfully to the Brain and is available for Pairing.
  * vSensor (cloud or traditional hypervisor deployed) has announced itself successfully to the Brain and is available for pairing.
* Pairing
  * A pairing request has been sent to the Vectra cloud from the Brain for online physical Sensors.
  * Any other Sensor type with a valid SRT is in the process of pairing.
* Paired
  * A Sensor has successfully paired with the Brain.
* Unpairing
  * A Sensor is in the process of unpairing.

**Sensor Status**

* Connected
* Not Connected
* Unpairing

<figure><img src="/files/2jZubc39RMt1py9uWFj9" alt=""><figcaption></figcaption></figure>

Pairing states and the list of Sensors can also been at the CLI of your Brain appliance. For details on how to access the CLI of your Brain, please see [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) or [console access on appliances](/deployment/appliance-operations/console-access-on-appliances).

<details>

<summary>Please expand for example using the <code>show sensors</code> CLI command.</summary>

```
vscli > show sensors -h
Usage: show sensors [ filter ]

  Show associated sensors

  FILTER is an optional query string to limit the results displayed. By
  default, all columns are searched but the query can be limited by using the
  format <column name>:<query>

Options:
  -h, --help  Show this message and exit.
v
scli > show sensors
Name                             |Ip            |Pairing  |Location              |Version    |Last Seen          |Luid    |Serial Number
V2b2db52176334e968c27a5d2a33720c0 192.168.54.201 available None                   9.0.0-18-57 2025-10-22 12:50:05 53a71kvk V2b2db52176334e968c27a5d2a33720c0
TB - Traffic Mirroring            192.168.55.239 paired    TB-Traffic Mirror Test 9.4.3-1-32  2026-01-29 19:37:09 qx70f0wr V11dd189d440e4e93b6bd6b5f5d1d484b
```

</details>

### Sensor Registration Token Pairing

<figure><img src="/files/mvpnCMNae5dh5GXjfTp2" alt=""><figcaption></figcaption></figure>

When a Sensor is configured with a valid [Sensor Registration Token (SRT)](#sensor-registration-token-srt), once a Sensor of any type is able to reach the Brain (see [communications requirements](#communications-requirements)), and shows as **Available,** click the pairing button as shown in the above screenshot to open a pairing dialog box.

<figure><img src="/files/Waq8H2P6yfgI2d7U6Tvy" alt="" width="375"><figcaption></figcaption></figure>

Click **Pair Sensor** to begin pairing. The Sensor will move through **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

### Auto Pairing

If [auto pairing](#virtual-sensor-automatic-pairing) is enabled, and the Sensor has a valid Sensor Registration Token, once the Brain sees the Sensor as available, pairing will be completed automatically.

Once a Brain sees the Sensor as **Availabl**e, Sensors will move through **Available**, **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

{% hint style="info" %}
**Please Note:**

* Physical appliances cannot engage in auto-pairing immediately out of the box. They must first be configured with a valid Sensor Registration Token (SRT).
* If a physical appliance shows as **Available** for pairing, and the admin initiates pairing, pairing will complete automatically if online pairing is possible.
  {% endhint %}

### Online Pairing (Physical Sensors Only)

<figure><img src="/files/mvpnCMNae5dh5GXjfTp2" alt=""><figcaption><p>Screenshot is from a vSensor. The <strong>TYPE</strong> would show the model number for physical appliances.</p></figcaption></figure>

Out of the box, physical Sensors will attempt to reach out to the Vectra cloud once they are online.

Once a physical Sensor/Stream appliance shows as **Available** in your Vectra UI, click the pairing button as shown in the above screenshot to open a pairing dialog box.

{% hint style="info" %}
When a physical appliance cannot reach Vectra's updater service because a proxy is required in the customer’s environment to reach outside destinations, the `set brain` command should be used to set the Brain IP or hostname that the Sensor or Stream appliance will attempt to pair with. Sensors do not support proxy configuration.
{% endhint %}

You will then be presented with a dialog box where you can start the pairing process.

* Click the **Pair Sensor** button to begin pairing.
* The Brain will update the Vectra Cloud with its MGT1 IP address or hostname (depending on if you have selected to [pair by hostname or IP](#pair-using-the-detect-brain) and posts a request for the Sensor to initiate the pairing process.
* If the Sensor has access to the Vectra Cloud, upon its next check in (every 5 min), it will now retrieve the location of the Brain from the Vectra cloud and attempt to connect to the Brain.
* If the Sensor does not have access to the Vectra Cloud or is unable to contact the Brain (e.g. the Sensor cannot reach the Brain's IP address in a NAT or proxy environment), the Sensor should be manually instructed to pair with the Brain from the Sensor CLI using the `set brain` command using an IP address for the Brain's MGT1 that will reach the Brain's NAT address from the Sensor or hostname of the Brain.

The Sensor will move through **Pairing**, and **Paired** states automatically and then finally show **Connected** as a status when the Sensor is ready to begin forwarding data to the Brain for analysis.

**Online Pairing Summary:**

Appliance serial numbers and keying information are associated with customer accounts during provisioning. Under normal circumstances, if both the Brain and physical Sensor or Stream can reach Vectra’s updater service at `https://update2.vectranetworks.com`, the following high-level diagram explains the standard pairing process:

![](/files/vEenppEFOpLU964W9XJR)

### Pairing in an Air-Gapped Environment vs Offline Pairing

While true air gap environments are typically relatively rare, customers may still need to deploy in environments where none of the components in your deployment can reach the Vectra cloud. A cloud deployed vSensor that can't reach the internet from its VPC could still be consided an air gap deployment from that perspective.

#### **Air-Gapped Pairing**

**Physical Appliances**

While Vectra NDR and Stream can function in full air gapped environments, this does mean that a Sensor Registration Token (SRT) will be required to pair physical Sensors.

**Traditional Hypervisor vSensors**

Traditional hypervisor based vSensors are not impacted because the virtual machine image downloaded from the Brain comes with the keying information needed to allow vSensors to communicate to the Brain. As long as the vSensors can contact the Brain they can pair automatically or via user initiated pairing. They can also use a SRT to authenticate pairing.

**Cloud vSensors**

Similarly, cloud vSensors are required to use a SRT for pairing and only need to be able to contact the Brain to pair and do not need to talk to the Vectra cloud.

**To pair in an air gap environment:**

* Retrieve or generate a current [Sensor Registration Token](#sensor-registration-token-srt).
* Perform the `set registration-token <token>` command at the Sensor CLI.
* Finally perform the `set brain <IP or Hostname>` command at the Sensor CLI.
  * `set brain` should also delete existing brain location information but if there are any issues, the `del brain` command at the Sensor CLI can be used.
* The Sensor should become **Available** for pairing on the Brain.

#### **Offline Pairing (Physical Sensors Only)**

In offline pairing scenarios, if a Sensor is behind a proxy or firewall and cannot connect to the Vectra cloud, then a Sensor Registration Token (SRT) will be required to complete pairing.

The **Pair Sensor** button can be used to begin pairing. A valid Sensor Registration Token (SRT) must be configured. You must also configure the Brain location with the `set brain` command at the CLI of the Sensor.

## Additional Pairing Guidance

### Stream Appliance "Sensor" Pairing Details

As discussed in [about Sensor and Stream pairing](#about-sensor-and-stream-pairing), Stream devices pair in the same manner as Sensor devices. There are some post pairing differences:

A Stream appliance does not show in the Vectra UI on the normal Sensor management screen located at *Configuration → Data Sources → Network → Sensors*. Pairing status for a Stream appliance is available in *Configuration > Setup > Stream* in the *Pairing Status* area:

<figure><img src="/files/CnwbT7Q5NvuMIX5iPZL2" alt="" width="563"><figcaption></figcaption></figure>

A Stream appliance will show its' status if you use the `show sensors` command at the CLI.

### Post Pairing Guidance

Once paired, Sensors will attempt to synchronize software versions by downloading the latest update from the Brain and immediately applying it. The Sensor may become temporarily unavailable while this update is applied. This should only take a few minutes to complete.

Certain vSensor CLI functions and traffic functions will become available only after the vSensor has fully updated. Depending on the specific version of the vSensor, you may see errors or warnings when running CLI functions during the period of time when the vSensor is still updating.

Sensors can be renamed or have their location labeled as desired by clicking on the pencil icon <img src="/files/A2Jl6Dr98rpqroDTzDga" alt="" data-size="line">on the right of the vSensor and editing the details.

### Pairing to New or Changed Brains

#### Pairing to Brain With Changed Location

If the Brain location must be changed there are two processes that can be used to associated existing Sensors with a new Brain:

**Preferred Method:**

* Change the Brain IP address or hostname.
* Redirect all Sensors to the new Brain location using the `set brain` command at the CLI of the Sensor.
  * Previously paired Sensors can simply be redirected because the Brain already has the required registration information for these Sensors.
    * This is also the same for new or different Brains restored from Backups.
  * Unpaired Sensors can use the Sensor Registration Token if needed.
    * For example: The new Brain isn’t restored from backup, is air-gapped, etc

**Alternate Method:**

You can also unpair all Sensors, change the Brain location (hostname or IP address), and then pair all Sensors again. This could cause some buffered data on the Sensors to be lost.

#### Pairing to a Different Brain

* If you have a Brain that will not be restored from backup that you wish to pair an existing Sensor to, this is possible via the use of a Sensor Registration Token.
  * Retrieve or generate a current [Sensor Registration Token](#sensor-registration-token-srt).
  * Perform the `set registration-token <token>` command at the Sensor CLI.
  * Finally perform the `set brain <IP or Hostname>` command at the Sensor CLI.
    * `set brain` should also delete existing brain location information but if there are any issues, the `del brain` command at the Sensor CLI can be used.
  * The Sensor should become **Available** for pairing on the new Brain and will pair automatically if [auto pairing](#virtual-sensor-automatic-pairing) is enabled.

#### Terminating Existing Sensor / Brain Tunnels

In all cases, existing tunnels have to terminate to re-establish connection to a new Brain. This can be accomplished a few different ways.

* Naturally, because the original Brain is no longer reachable due to firewall change, hardware or software failure, etc.
* Using the `set brain` command at the CLI will terminate an existing tunnel and attempt to start pairing with a new Brain.
  * `del brain` can be used to break the tunnel but not set a new Brain location.
* In normal operation, the Sensor can simply be unpaired from its existing Brain. To use the **Unpair** option, the Brain must be connected to the Vectra Cloud and the Sensor must be powered on with an active tunnel to the original Brain.
  * Navigate to *Configuration → COVERAGE → Data Sources → Network → Sensors*, click on the Sensor you wish to unpair and click on the **Unpair** button.
  * After unpairing which could take a few minutes, the status of the Sensor should change to **Available**.

<figure><img src="/files/zVRwJeWDyoWKyYcJV4cy" alt=""><figcaption></figcaption></figure>

* Using the **Force Unpair** option in your Vectra UI for the target Sensor.
  * This will unpair the Sensor from the original Brain and when the Sensor attempts communication to the original Brain the tunnel will not function.
  * **Force Unpair** is the same as deleting for a vSensor. You cannot delete a physical Sensor (talk to Vectra Support if this is required).


# Directing traffic to Azure vSensor

How to direct traffic to Azure vSensors.

## Forwarding Traffic to Azure vSensors

If you wish to use 3<sup>rd</sup> party tools to direct traffic at the vSensor capture port, it should be VXLAN encapsulated and sent on port 4789. When using such tools, to ensure accurate metadata generation and session reconstruction, traffic distribution to Vectra sensors must maintain flow-level persistence — that is, all packets from a single network session must be seen by the same sensor. Azure standard load balancers cannot be used because the vSensor cannot respond to required Azure standard load balancer health checks. It only listens for traffic coming inbound.

To find the IP assigned during deployment to your traffic NIC, go to your Azure resource group that was used during deployment, click on the traffic NIC (it will be the interface that ends with **trafficnic**), and there you will see the private IP that was assigned to the traffic NIC (capture interface of your newly deployed vSensor).

{% hint style="info" %}
**Summary:**

You can use any method or third party tool you want to direct traffic to Vectra vSensors as long as:

* It is forwarded to the traffic NIC.
* It is VXLAN encapsulated over port 4789.
* Flow-level persistence is maintained. That is, all packets from a single network session must be seen by the same Vectra Sensor.
  {% endhint %}

## Azure Virtual Network TAP (VTAP)

Azure VTAP is still in public preview and may not be available in all regions.

For Microsoft's guidance on using Microsoft VTAP to direct traffic, please see [Virtual network TAP](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-tap-overview) at Microsoft. They also have portal and CLI instructions here:

* [Work with a virtual network TAP using the Azure portal](https://learn.microsoft.com/en-us/azure/virtual-network/tutorial-virtual-network-tap-portal)
* [Work with a virtual network TAP using the Azure CLI](https://learn.microsoft.com/en-us/azure/virtual-network/tutorial-tap-virtual-network-cli)

Vectra professional services can also assist in Azure deployments. Please contact your Vectra account team for details.

## cPacket cVu-V Integration

Vectra created a deployment guide to customers wishing to use cPacket cVu-V technology to forward Azure traffic to Vectra vSensors deployed in Azure. Please work with your cPacket team on the deployment and see Vectra's guide here: [Azure cPacket cVu-V](/deployment/ndr-virtual-cloud-appliances/azure-vsensor/azure-cpacket-cvu-v).

## Traffic Validation

Please see the following Vectra support article for recommendations on network traffic that should be examined and excluded from analysis:

* [Network Traffic Recommendations](/deployment/traffic-engineering-and-validation/network-traffic-recommendations)

After sending traffic to your Sensors, it is a best practice to validate that the traffic observed meets quality standards required for accurate detection and processing. Vectra’s Network Traffic Validation feature provides alarms and metrics that can be used to validate the quality of your traffic. Please see the following Vectra support article for details:

* [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv)

Once you have directed traffic at your Sensor’s capture interface though either 3<sup>rd</sup> party traffic broker or [Azure VTAP](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-tap-overview) and have traffic flowing to the Sensor you can validate the traffic flow.

To validate flow from the Vectra side there are several methods:

* To see that packets are being receive by the traffic interface, use ssh to login to the CLI of the Sensor as the `vectra` user and use the `show traffic stats` command. See [SSH login process for CLI](/deployment/appliance-operations/ssh-login-process-for-cli) for details on accessing the CLI.

  * Run `show traffic stats` several times to see that packet counts are increasing.

  <img src="/files/xErdp0kfoDeKZyJe6Zsv" alt="" width="375">

  * In the Vectra GUI if you navigate to *Network Stats > Ingested Traffic*, you can see the traffic graph for your Sensor.
    * For this graph to display, there must be at least 1 Mbps of traffic being captured.
    * Once traffic capture begins, it will take a few minutes for this graph to be populated. Use the CLI of the Sensor as shown above to validate that packets are flowing 1<sup>st</sup>.

![](/files/493933fbbf128ce0e25f69aaa5c2f8b0e79197fa)

* The Network Stats > Observed IPs page shows the subnets being observed and numbers of hosts seen:

<img src="/files/2JImX8qcFbZJtlsGcTZy" alt="" width="563">


# Azure cPacket cVu-V

Optionally deploy cPacket cVu-V in Azure to feed traffic for a Vectra vSensor for packet capture and NDR visibility.

{% hint style="info" %}
**Please Note:**

cPacket is a 3rd party solution that can be used to feed traffic to a Vectra vSensor. Always check with cPacket for any updates that may have happened after this guide was created.
{% endhint %}

## Overview

For enterprises pursuing a lift-n-shift approach to the Microsoft Azure cloud, a key consideration is ensuring the same level of visibility, detection and response for their Azure footprint, as they have for their on-premise footprint. Vectra is the leader in network detection and response, leveraging artificial intelligence to analyze network traffic and detect advanced attacks in real-time.

Key to this solution is the ability to get packets from the network – which is challenging since the network virtual tap feature is not generally available to Microsoft Azure customers. To this end, Vectra proposes a joint solution with cPacket Networks that offers an agentless, scalable, easy-to-deploy approach to deliver packets to Vectra Sensors in Azure.

## Solution

The Vectra solution for Azure IaaS environments comprises of a footprint of Sensors deployed across the subscription. The Sensors ingest VxLAN encapsulated traffic from cPacket, extract rich metadata about every session and forward the metadata to a Vectra Brain for analytics.

Detections are accessible using the Vectra UI and metadata can be further forwarded either to the Vectra Recall service ([Vectra Quadrant UX deployments](/deployment/getting-started/quadrant-ux-deployment) only) or to the customer’s data lake using Vectra Stream. [Vectra Respond UX deployments](/deployment/getting-started/respond-ux-deployment-guide) can further analyze metadata using Instant and [Advanced Investigation](/operations/analyst-guidance/investigate-quick-start-guide-prior-to-sql-search) features integrated into the Respond UX.

This allows the Vectra solution to analyze all traffic leaving a subnet in Azure to any other subnet or leaving the cloud and identify attacks in any phase. The question is, how does network traffic reach the Vectra Sensors.

cPacket has products in a variety of areas that are complementary to Vectra deployments. cVu network packet broker products consolidate, monitor and forward packet data to Vectra. cTap provides test access point capability to forward wire data to Vectra. cStor packet capture appliances capture, record, and analyze network traffic for security and performance use cases. The cProbe flow generator generates and exports network flow data for customers requiring flow data in other tools. The cClear analytics engine provides single pane of glass dashboards and consistent workflows across the cPacket product line. Vectra can interoperate with both physical and virtual or cloud deployed cPacket products.

Typically, multiple cPacket cVu-v virtual appliances must be deployed across the Azure footprint. Traffic from Azure VMs gets forwarded in accordance with the Azure route tables for the Virtual Network. User Defined Routes (UDR) assigned to the subnet send all traffic from the Azure VMs in that subnet to the cVu-V virtual appliance.

Once deployed, a cVu-V instance receives packets that were forwarded to it from the Azure network. The cVu-V acts as a bump in the wire that will forward all traffic received from the network to the destination.

For each packet received, cVu-V 's internal packet processing engine inspects the packet and compares it to a set of configured Rules and Filters to determine if the replica should then be forwarded to one or more downstream Endpoints (tools like Vectra Sensors or cStor-v packet capture) or dropped. The replica is encapsulated using a VxLAN header and forwarded to the Vectra Sensor.

This document will cover the example use case of capturing traffic in Azure IaaS environments and forwarding it via cVu-V to a Vectra vSensor that will produce and send a metadata stream to the Vectra Cognito Platform. It is not meant to replace deployment guides from cPacket, and Vectra recommends that customers work jointly with your Vectra account team and cPacket to ensure the smoothest deployment possible.

## High Level Deployment Examples

**Basic Concept**

![](/files/7c3dfa6103892163c613fdca5c49775a392c97d7)

Deploying cPacket to feed packets to a Vectra Sensor is very straightforward. Looking at the example above:

* Clients C1 through C4 on the left in Network A have an Azure route table with UDRs that point all traffic destined for Network B to the IP address assigned to cVu-V.
* When cVu-V receives a packet, it forwards it to a Vectra Sensor using VXLAN encapsulation.
  * It also forwards the traffic on to the destination server.
* Servers S1 through S4 on the right in Network B have an Azure route table with URDs that point all traffic destined for Network A to the IP address assigned to cVu-V

**Additional Detail with Azure Standard Load Balancer**

![](/files/b5c8a039f8b4a9a941bf99ad48784cc999da7afe)

In the example above we have a more detailed scenario including an Azure standard load balancer front ending the cVu-V instances.

* Workload A instances have an Azure route table with UDRs for Workload B and Workload C subnets that points to the IP address assigned to the Azure standard load balancer.
* Workload B instances have an Azure route table with UDRs for Workload A and Workload C subnets that points to the IP address assigned to the Azure standard load balancer.
* Workload C instances have an Azure route table with UDRs for Workload A and Workload B subnets that points to the IP address assigned to the Azure standard load balancer.
* Vectra Sensors would also need a load balancer deployed in front of them but in this diagram all of that is just represented by “Vectra” in the diagram.
* This example also shows cStor-V for packet capture and cClear-V for centralized dashboarding.

**Example with ExpressRoute**

![](/files/ff79dd9baa734b213d903f44ebdcd526a26f957c)

In the example above, we have a scenario with ExpressRoute connectivity between an on-premises network and an Azure deployment.

* In the gateway subnet, an Azure route table with UDRs would point traffic destined for the Web tier to the cCloud (cVu-V) deployment.
* In the Web tier subnet, an Azure route table with UDRs would point traffic destined for the on-premises network to the cCloud (cVu-V) deployment.
* Similar configurations could be applied for the Business tier and Data tiers.

**Example Deployment Discussed in this Deployment Guide**

![](/files/e8168d9d0679fa67b26a4cf00fb74748dfb937f7)

* The Brain used in this example is deployed in AWS but it could be in other supported clouds or a physical Brain appliance. It just needs to be reachable from the vSensor and where you want to log into it from.
* There is one VNET in Azure with 4 subnets.
  * An attacker subnet with a single ubuntu instance deployed in it.
  * A victim subnet with a single ubuntu instance deployed in it.
  * A monitor subnet that houses cVu-V and the traffic interface of the Vectra vSensor
    * The traffic interface is not required to be in the same subnet as cVu-V, just reachable from cVu-V.
  * A Sensor subnet that houses the management interface of the Vectra vSensor.
* User defined routes in Azure that are assigned to the attacker and victim subnets direct traffic to flow to cVu-V which then forwards VXLAN encapsulated copies of the traffic to the traffic capture interface of the Vectra vSensor.
* The Vectra vSensor then forwards metadata to the Vectra Brain

## Scaling and High Availability

cVu-V appliances are deployable in sizes that support 1 Gbps to 30 Gbps per appliances. Multiple subnets can be pointed to the same appliance. A single cVu-v virtual appliance can forward replicated traffic to multiple Vectra vSensors.

Vectra Azure vSensors are available in 1 or 2 Gbps sizes. You can deploy as many Sensors or cVu-V appliances as needed to cover the required Azure footprint.

Deploying cVu-V with UDRs to redirect traffic is less complicated than commonplace firewall deployments. This implementation only needs changes to routes and does not introduce complex rulesets. In the event of any issues, you can simply dissociate any route table from its associated subnet to return to a prior state before implementing cVu-V.

## Prerequisites

### Vectra

One of the below guides should be the starting point for your overall Vectra deployment:

* [Vectra Respond UX Deployment Guide](/deployment/getting-started/respond-ux-deployment-guide)
* [Vectra Quadrant UX Deployment Guide](/deployment/getting-started/quadrant-ux-deployment)

For more detail on Respond UX vs Quadrant UX please see [Vectra Analyst User Experiences (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux). Either of the above guides cover basic firewall rules needed for the overall deployment and initial platform settings.

You will also need a Vectra Sensor deployed in Azure for this solution. Please refer to the following deployment guide for assistance:

* [Azure vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/azure-vsensor)

### cPacket

The Azure CLI must be installed.

* Instructions are available here: <https://docs.microsoft.com/en-us/cli/azure/install-azure-cli>.
* cPacket also supports PowerShell instead of the Azure CLI
* Please work with cPacket if this is a requirement for your organization.

cPacket will require an Azure account login email from you so that they can share the cVu-V image with your Azure subscription via **Shared Image Gallery** functionality.

* This must the login email that is use for access to Azure and not a separate corporate email address that the user might have.
* Once cPacket shares the appliance images with you, you will receive an organization invite from Microsoft on behalf of cPacket that looks similar to the below:

<img src="/files/cf81fb37fe5709a2378634a4770acc351c68a9e6" alt="" width="563">

* This is the same process that Vectra uses for access to the Azure Brain image.
* Click the **Accept invitation** link and follow the steps presented by Microsoft.
* On a machine with the Azure CLI installed, you must re-login using the Azure CLI by running the `az login` command.
  * This process will have you authenticate in your browser and then when you return to the shell you should see the Azure subscriptions that you have access to.
  * Please ensure that the login process shows you the following subscription (you can also run **“az account list”** to see the list at any time you are logged in)

```
{
    "cloudName": "AzureCloud",
    "homeTenantId": "6c826f92-18d2-4705-bec4-7a9257f96733",
    "id": "93004638-8c6b-4e33-ba58-946afd57efdf",
    "isDefault": false,
    "managedByTenants": [],
    "name": "cPacket Azure Root",
    "state": "Enabled",
    "tenantId": "6c826f92-18d2-4705-bec4-7a9257f96733",
    "user": {
      "name": "tbilen@demolab.vectra.ai",
      "type": "user"
    }
```

* You can list the appliance images that cPacket has shared with as follows:

```
az sig image-definition list -o table \
--gallery-name cpacketccloudpre \
-g cstor-aidsinga-rg1 \
--subscription "93004638-8c6b-4e33-ba58-946afd57efdf"
```

Approximate output:

```
HyperVGeneration    Location    Name           OsState      OsType    ProvisioningState    ResourceGroup
------------------  ----------  -------------  -----------  --------  -------------------  ------------------
V1                  eastus2     cclearvpre     Generalized  Linux     Succeeded            cstor-aidsinga-rg1
V1                  eastus2     cstorvpre      Generalized  Linux     Succeeded            cstor-aidsinga-rg1
V1                  eastus2     cvuvinlinepre  Generalized  Linux     Succeeded            cstor-aidsinga-rg1
```

cPacket’s deployment requires that NICs be pre-created that you will use with the cCloud family of appliances.

* They require at least one Azure NIC for each of cVu-V, cStor-V, and cClear-V.
* You will need the names of these NICs for use in the cPacket deployment scripts.
* Additional NIC configuration steps
  * On any cCloud appliance VM, the NICs should be configured to enable network acceleration. Also, on the cVu-V appliance, IP forwarding must be enabled for its NIC.
  * Note that network acceleration, while not strictly required, will allow the cCloud appliances to achieve close to the maximum performance available to the VM.
  * Setting NIC Acceleration:
    * To enable this, Microsoft recommends that any VM that the NIC is associated with must first be stopped and deallocated.
    * This can be enabled in the Azure portal by finding your NIC and then clicking on **Enable accelerated networking**.

<img src="/files/436731f7400f4a6d4ed50abbea8d6dc838df3869" alt="" width="563">

* This can also be enabled from the Azure CLI. Example syntax below:

```
az network nic update \
--name "YOUR_NIC_NAME" \
--resource-group "YOUR_RESOURCE_GROUP" \
--accelerated-networking true
```

* Enabling IP forwarding
  * Some additional guidance from Microsoft is available [here](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface#enable-or-disable-ip-forwarding).
  * This can be enabled in the Azure portal if you change the setting to “Enabled” under IP forwarding settings in the IP configurations section of the NIC:

![](/files/9750b190325add90d47182d3674f45372c365a33)

* This can also be enabled using the Azure CLI:

```
az network nic update \
--name "YOUR_NIC_NAME" \
--resource-group "YOUR_RESOURCE_GROUP" \
--ip-forwarding true
```

Subnets

* For Layer 3 setup (forcing IP packets to cVu-V using User Defined Routes):
  * Within the VNET, a subnet must be created for use by cPacket’s appliances.
    * This is referred to as a the **Monitoring Network**.
* For Layer 4 setup (cVu-V behind an Azure Standard Load Balancer):
  * cPacket also recommends that cCloud appliances be on their own monitoring network.
    * This allows flexibility in terms of using both layer 3 and layer 4 traffic flows.
    * That said, for strictly layer 4 configurations with load balancers, a separate monitoring subnet is not required.

An Azure **Standard Load Balancer** must be created when designing a fault tolerant solution.

* Even when a single cVu-V could handle the load, it is a best practice to use multiple appliances for fault tolerance.
* This can be a **public** load balancer or an **internal** load balancer that front ends multiple cVu-V appliances.
  * When configuring an Azure Standard Load Balancer you have a choice of NIC or IP address for the Backend Pool Configuration. This should be set to **IP address**.
  * See <https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview> for additional detail.

Create a storage account for cPacket virtual machine diagnostics:

* Type: Storage (general purpose v1)

Network Security Groups

* Azure NSGs should be used to lock down access to the cCloud appliances to only those networks and machines that require access.

Inbound configuration:

<table data-header-hidden><thead><tr><th width="134.08984375" align="center"></th><th width="167.78515625" align="center"></th><th width="145.36328125" align="center"></th><th width="301.60546875"></th></tr></thead><tbody><tr><td align="center"><strong>Port/Protocol</strong></td><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td><strong>Notes</strong></td></tr><tr><td align="center">443 / HTTPS</td><td align="center">Specific IPs or networks for management staff</td><td align="center">VirtualNetwork</td><td>Web management UI</td></tr><tr><td align="center">22 / SSH</td><td align="center">Specific IPs or networks for management staff</td><td align="center">VirtualNetwork</td><td>Only required during tech support with cPacket technical staff</td></tr><tr><td align="center">ICMP</td><td align="center">VirtualNetwork, other management networks</td><td align="center">VirtualNetwork</td><td></td></tr><tr><td align="center">Any/Any</td><td align="center">UDRs or VirtualNetwork</td><td align="center">UDRs or VirtualNetwork</td><td>Limit to sources that have been established with UDRs, or if desired, the broader rule to allow all on the current VNET with “VirtualNetwork”</td></tr></tbody></table>

Outbound configuration:

<table data-header-hidden><thead><tr><th width="129.96875" align="center"></th><th width="139.8515625" align="center"></th><th width="139.15234375" align="center"></th><th width="340.171875"></th></tr></thead><tbody><tr><td align="center"><strong>Port/Protocol</strong></td><td align="center"><strong>Source</strong></td><td align="center"><strong>Destination</strong></td><td><strong>Notes</strong></td></tr><tr><td align="center">Any/Any</td><td align="center">UDRs or VirtualNetwork</td><td align="center">UDRs or VirtualNetwork</td><td>Limit to sources that have been established with UDRs, or if desired, the broader rule to allow all on the current VNET with “VirtualNetwork”</td></tr></tbody></table>

SSH keys

* An RSA SSH key pair will need to be created, or reuse an existing pair, for the cVu-v to allow an administrator to login to the CLI as the `ubuntu` user.
* These can be generated using any standard tool.
* The public key will need to be saved to a file so that it can be passed as an argument to the deployment command for cVu-V.
* After cVu-V is deployed, you can login to the CLI via SSH using the private key that corresponds to the public key.
* You may need to make the private key readable to you using a command such as:
  * `chmod 400 cPacket_SSH_Key.pem`
* Example login command:

```
ssh -i cPacket_SSH_Key.pem ubuntu@xxx.xxx.xxx.xxx
Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 5.4.0-1026-azure x86_64)
     ____            _        _     _   _      _                      _
 ___|  _ \ __ _  ___| | _____| |_  | \ | | ___| |___      _____  _ __| | _____
/ __| |_) / _` |/ __| |/ / _ \ __| |  \| |/ _ \ __\ \ /\ / / _ \| '__| |/ / __|
 (__|  __/ (_| | (__|   <  __/ |_  | |\  |  __/ |_ \ V  V / (_) | |  |   <\__ \
\___|_|   \__,_|\___|_|\_\___|\__| |_| \_|\___|\__| \_/\_/ \___/|_|  |_|\_\___/

Last login: Tue Sep 21 19:45:48 2021 from 216.246.25.68
ubuntu@cVu-VTest:~$
```

cPacket recommends the [Dsv3-series](https://docs.microsoft.com/en-us/azure/virtual-machines/dv3-dsv3-series#dsv3-series) of VMs for deployment. They provide a variety of network bandwidth options suitable for high throughput packet processing. Sizing is beyond the scope of this document and Vectra recommends that you work with your cPacket account team for sizing of their solution.

* The Dsv3-series of VMs supports 1 to 30 Gbps of throughput
* Other Microsoft VM types may be feasible, but you should work with you cPacket technical rep to discuss requirements.
* Our example deployment did not require high throughput so we will use the Standard\_D2s\_v3 type.

## cPacket Deployment

`cvuv-azure-launcher.sh`

* This is an optional script that can be used to add the full `az vm create` command to bash history.
* You can then up arrow to edit and/or run the command.
* For more information about using this command, please see cPacket’s documentation.

`userdata-cvuv.txt`

* This file is passed as one of the arguments to the `az vm create` command.
* It contains values to be used during the deployment of the cPacket cVu-V VM.
* The key items in this file as it relates to a joint Vectra / cPacket deployment are:
* `YOUR_CVUV_IP` – IP address of the cVu-V VM
* `REMOTE_TOOL_IP` – IP address assigned in the Frontend IP configuration of the load balancer that is deployed by default with the Vectra vSensor

Here is an unconfigured example of `userdata-cvuv.txt`:

```
#!/bin/bash

# cVu-V-k inline mode config example

# cvuv_nat_xxx values define NAT passthroughs - up to 4 allowed
#   (suffix _0,_1,_2, _3)
#    NOTE : local RESERVED ports 443,80,22,161,162
# cvuv_nat_loc_ip, cvuv_nat_dst_ip : emptry strings ('') will disable that nat port

# for cvuv_vxlan_srcip, cvuv_vxlan_remoteip : empty strings ('') will disable
# the vxlan output port.

# make writable so that next boot can overwrite if need be
chmod ug+w /home/cpacket/boot_config.txt

# cVu-V-k inline 
cat <<EOF_BOOTCFG >/home/cpacket/boot_config.txt
{
'vm_mode'               : 'microsoft',
'capture_mode'          : 'cvuv',
'cvuv_mode'             : 'inline',
'cvuv_inline_mode'      : 'tctap',

'cvuv_mirror_eth_0'     : 'eth0',

'cvuv_vxlan_id_0'       : '1337',
'cvuv_vxlan_srcip_0'    : 'YOUR_CVUV_IP',
'cvuv_vxlan_remoteip_0' : 'REMOTE_TOOL_IP',

'cvuv_vxlan_id_1'       : '1338',
'cvuv_vxlan_srcip_1'    : 'YOUR_CVUV_IP',
'cvuv_vxlan_remoteip_1' : 'REMOTE_TOOL_IP',

'cvuv_nat_loc_proto_0'  : 'tcp',
'cvuv_nat_loc_ip_0'     : 'YOUR_CVUV_IP',
'cvuv_nat_loc_port_0'   : 'LOCAL_PORT',
'cvuv_nat_dst_ip_0'     : 'NEXT_HOP_IP',
'cvuv_nat_dst_port_0'   : 'NEXT_HOP_PORT',

'burnside_mode'         : False,
'cstor_lite_mode'       : False,
'ssh'                   : {'enabled': True},
}
EOF_BOOTCFG

#

echo "cloud-init ran user-data at: " $(date) >>/home/cpacket/prebootmsg.txt
```

We save a new version of this file to use for deployment and enter the IPs for cVu-V and the Sensor LB.

In our example deployment, we only have a single Vectra Sensor running in Azure that our cVu-V needs to send data to, so we removed the second section of three lines relating to `cvu-v_vxlan` from this example before running the `az vm create` command.

`az vm create` command syntax:

```
az vm create \
--image "$IMAGE" \
--resource-group "$RES_GROUP" \
--name "$NEW_VM_NAME" \
--size "$VM_SIZE" \
--admin-username "$ADMIN_USER" \
--authentication-type ssh \
--ssh-key-values @"$KEYS_FILE" \
--custom-data @"$USERDATA_FILE" \
--boot-diagnostics-storage "$BOOT_DIAGS_STOR" \
--nics "$NIC_LIST" \
--specialized false \
--validate
```

* `image` – cVu-V image location that was shared by cPacket
  * /subscriptions/93004638-8c6b-4e33-ba58-946afd57efdf/resourceGroups/cstor-aidsinga-rg1/providers/Microsoft.Compute/galleries/cpacketccloudpre/images/cvuvinlinepre
* `resource-group` – Azure resource group to deploy into.
* `name` – Name you want the VM to have.
* `size` – VM type (cPacket recommends you choose from [Dsv3-series](https://docs.microsoft.com/en-us/azure/virtual-machines/dv3-dsv3-series#dsv3-series)
* `admin-username` – “ubuntu” should be used
* `authentication-type` – ssh should be chosen
* `ssh-key-values` – File where you stored the public key
* `custom-data` – This should be your userdata-cvuv.txt file
* `boot-diagnostics-storage` – Name of the storage account created to store diagnostics
* `nics`– Nics created for the cVu-V VM
* `specialized` – This should be left as false unless directed otherwise by cPacket
* `validate` – Optional parameter to validate that the deployment will be successful before executing

Example output from a successful deployment:

```
az vm create \
--image "/subscriptions/93004638-8c6b-4e33-ba58-946afd57efdf/resourceGroups/cstor-aidsinga-rg1/providers/Microsoft.Compute/galleries/cpacketccloudpre/images/cvuvinlinepre" \
--resource-group "cPacket_Test" \
--name "cVu-V_Test" \
--size "Standard_D2s_v3" \
--admin-username "ubuntu" \
--authentication-type ssh \
--ssh-key-values @"./cpacketsshkey.txt" \
--custom-data @"./userdata-cvuv.txt" \
--boot-diagnostics-storage "cpacketstorage" \
--nics "cVu-V_NIC" \
--specialized false
It is recommended to use parameter "--public-ip-sku Standard" to create new VM with Standard public IP. Please note that the default public IP used for VM creation will be changed from Basic to Standard in the future.
{
  "fqdns": "",
  "id": "/subscriptions/b3fe75ab-94a2-4322-84af-016eb01ff43e/resourceGroups/cPacket_Test/providers/Microsoft.Compute/virtualMachines/cVu-V_Test",
  "location": "eastus",
  "macAddress": "00-0D-3A-15-50-0F",
  "powerState": "VM running",
  "privateIpAddress": "10.0.2.10",
  "publicIpAddress": "",
  "resourceGroup": "cPacket_Test",
  "zones": ""
}
```

## Post Deployment Steps

<figure><img src="/files/e8168d9d0679fa67b26a4cf00fb74748dfb937f7" alt=""><figcaption></figcaption></figure>

As a reminder, the above diagram is the example deployment we are discussing in this guide. We are primarily detailing the setup of cVu-V and the User Defined Routes (UDRs) required to route traffic through the cVu-V so that the Vectra Sensor can monitor the network traffic between the Attacker and Victim subnets.

This guide does not detail the setup of the subnets, the attacker and victim machines, or the Vectra Brain and vSensor. Please refer to the guides referenced in the [Prerequisites](#prerequisites) section for more detail on deploying the Vectra Brain and any needed Sensors.

### Configuring User Defined Routes (UDRs)

Microsoft provides some background information and instructions related to UDRs here:

* [Virtual network traffic routing: User-defined](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#user-defined)
* [Tutorial: Route network traffic with a route table using the Azure portal](https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal)

Subnets in our example

* **Vectra\_Sensor** – 10.0.0.0/24
  * Used for the management interface of the Vectra vSensor.
* **Attacker** – 10.0.1.0/24
  * Used for the interface of an **Attacker** ubuntu instance.
* **Monitor** – 10.0.2.0/24
  * Used for the interface of the cVu-V VM.
  * Used for the capture interface of the Vectra vSensor.
* **Victim** – 10.0.3.0/24
  * Used for the interface of a **Victim** ubuntu instance.

**Steps in our example configuration:**

* Create a route table and add UDR’s for each of the subnets that we want to monitor traffic to/from (Attacker and Victim subnets) so that traffic will route through the cVu-V VM.
  * Microsoft has a tutorial available [here](https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal). Example route table is below:

![](/files/9b5dea629365dc96f0cefc98b728c53f3d8fb6e0)

* This route table is associated to the **Attacker** subnet and routes all traffic destined for the 10.0.3.0/24 **Victim** subnet to the cVu-V whose NIC has the 10.0.2.10 IP address.
* A similar route table that is associated to the **Victim** subnet should be constructed that routes all traffic destined for the 10.0.1.0/24 **Attacker** subnet also to the cVu-V VM.
* When adding a route to the route table, the next hop type should be set to **Virtual appliance** for both layer 3 (forcing IP packets to cVu-V using User Defined Routing) and layer 4 (cVu-V behind and Azure Standard Load Balancer) setups.
* When creating a route table, there is an option called **Propagate gateway routes**.
  * Microsoft has some guidance available [here](https://go.microsoft.com/fwlink/?linkid=2120624).
  * Of particular note is the section on [Border gateway protocol (BGP)](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#border-gateway-protocol).
  * It refers to another [Microsoft routing article](https://docs.microsoft.com/en-us/azure/virtual-network/manage-route-table#create-a-route-table) that states:
    * “If you plan to associate the route table to a subnet in a virtual network that's connected to your on-premises network through a VPN gateway, and you don't want to propagate your on-premises routes to the network interfaces in the subnet, set Virtual network gateway route propagation to Disabled.”
  * Some customers may need **Propagate gateway routes** set to **Yes** and others may require **No**.
    * Please work with your networking team if you are usure of which option to choose.

### Vectra Supplied UDR Script

Vectra has created a shell script that automates the creation of user defined routes to aid in deployments involving cPacket and Vectra. If you would like a copy of this script, please request it from your Vectra account team.

This script was created by the Vectra Sales Engineering team, and it is not supported by Vectra’s support team.

### Lateral Visibility in Subnets

If lateral visibility inside certain subnets is required, it is possible to add individual /32 routes for IPs. This adds complexity to UDR provisioning and upkeep though and many customers choose to keep visibility at a subnet-to-subnet level in the Cloud. You should also keep in mind the service limits Microsoft has for route table entries if pursuing this:

* [Networking limits - Azure Resource Manager](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#azure-resource-manager-virtual-networking-limits)

### Validating Traffic Flow

#### Accessing the cVu-V web management interface

Once you’re cVu-V appliance is up and running, you can access the management interface at:

* `https://YOUR_VM_IP`

Note that a security notice may appear in the browser. This is due to the default SSL cert packaged in the appliance being self-signed.

The login screen will prompt you for a username and password which is provided to you by your cPacket technical rep. We advise that the default password be changed after first login for improved security.

* Default username / password as of this documents publishing are: `cvuv` / `cvuvpw`

Note that since you started the cVu-V virtual machine with configuration data (`userdata.txt` above), it should already be handling traffic and tapping/mirroring packets to downstream tools.

#### Verifying traffic through cVu-V

To get a quick sense of activity flowing through the cVu-V, review the **Runtime Information** screen:

#### Verifying network configuration

If you don’t see any TX traffic on the vxlan0 interface, check the Admin screen to verify configuration. The Local IP should be the IP of the cVu-V appliance and the Remote IP should be IP address assigned in the Frontend IP configuration of the load balancer that is deployed by default with the Vectra vSensor.

<img src="/files/905506bcb417df60dfddb4576f5f13872b20275d" alt="" width="563">

#### Validating traffic flow in Vectra

For a quick spot check to see that you are receiving any traffic at all via the vSensor you many want to check the GUI and/or CLI for statistics. If the vSensor is seeing more than 1 Mbps of traffic, this will show in the GUI under *Network Stats > Ingested Traffic* after a few minutes.

![](/files/8edWbEEADxvSmGVo99GX)

You can see traffic flow immediately at the CLI of the Sensor using the `show traffic stats` command.

* Please note that this command will only function after the vSensor has been paired and updated from the Brain. For details, please see details about the intial embryo state of vSensors in your vSensor deployment guide.

Execute this command a few times in a row to see increasing packet counts.

<img src="/files/xErdp0kfoDeKZyJe6Zsv" alt="" width="389">

After sending traffic to your Sensors, it is a best practice to validate that the traffic observed meets quality standards required for accurate detection and processing. Vectra’s Network Traffic Validation feature provides alarms and metrics that can be used to validate the quality of your traffic. See [Traffic Validation (ENTV)](/deployment/traffic-engineering-and-validation/traffic-validation-entv) for details on validating your traffic quality.

* **Support portal:** [https://support.vectra.ai](https://support.vectra.ai/)
* **Email:** <support@vectra.ai> (preferred contact method)
* **Additional information:** <https://www.vectra.ai/support>


# GCP Brain

Deploy a Vectra NDR virtual Brain in a Google Cloud project.


# Introduction and requirements

Overview of the GCP Brain deployment and prerequisites, including required access, tooling, and Vectra-provided resources.

## Introduction

This document outlines the steps to deploy a Vectra NDR virtual Brain in a customer’s Google Cloud Platform (GCP) project. The Brain is deployed using the [gcloud command line tool](https://cloud.google.com/sdk/gcloud) with a template provided by Vectra. The template references a Brain image that is shared by Vectra with the Compute Image User referenced by the project number. The GCP Brain supports up to 85 Gbps network traffic captured by paired Sensors. GCP Sensor deployment and pairing is covered in the [GCP vSensor Deployment Guide](/deployment/ndr-virtual-cloud-appliances/gcp-vsensor).

The GCP Brain can be used in both Respond UX (RUX) and Quadrant UX (QUX) deployments. For more detail on Respond UX vs Quadrant UX please see [analyst UX options (Respond vs Quadrant)](/deployment/getting-started/analyst-ux-options-rux-vs-qux). One of the below guides should be the starting point for your overall Vectra deployment:

* [Respond UX deployment](/deployment/getting-started/respond-ux-deployment)
* [Quadrant UX deployment](/deployment/getting-started/quadrant-ux-deployment)

Either of the above guides cover the overall deployment and initial platform settings. Virtual Sensor (VMware, Hyper-V, KVM, Nutanix, AWS, Amazon, and GCP) deployment is covered in [NDR virtual / cloud appliances](/deployment/ndr-virtual-cloud-appliances). Physical appliance deployment is covered in [NDR physical appliances](/deployment/ndr-physical-appliances). Pairing of all appliance types is covered in [pairing appliances](/deployment/appliance-operations/pairing-appliances). Please see other guides in the deployment section for guidance for other appliances and products you may want to include in your overall deployment.

## General Requirements

* User with sufficient permissions in GCP who is available to deploy using the Vectra provided template.
  * User will need to be able to create a project or have access to a project they can use.
  * User will need to be able to create VPCs, subnets, firewall rules, and VMs or use existing ones.
* Access to gcloud command line tool either via GCP SDK or cloud shell.
* Vectra will provide the following information in a welcome email after receiving the GCP project number:
  * **Image path for Brain** - This will be entered in the deployment template and references the current GCP Brain image shared by Vectra.
  * **Deployment Template** - Link to download the deployment template.
  * **Provisioning Token** – Allows the Brain to register with Vectra.
    * Please note that provisioning tokens expire after 14 days. Vectra can provide a new one if you don’t have a chance to deploy before the initial one expires.
* The Preparation section below contains additional requirements that must be sufficed to ensure successful deployment of the Brain image in GCP.




---

[Next Page](/llms-full.txt/1)