FAQ
This is a general Frequently Asked Questions (FAQ) article for Vectra Match.
General
Do I need to run Vectra Match on all Sensors?
No, you can enable Vectra Match on a Sensor by Sensor basis.
Will enabling or disabling Match on Sensor cause any downtime for the Sensor?
Yes, when a Sensor changes state (disabled to enabled, or enabled to disabled), the Sensor must reboot as part of its configuration process.
During this this time no traffic will be processed by the Sensor you are changing the state on.
This means metadata will not be passed to the Brain for further processing (Detect for Network, Recall, Stream, etc).
Sensor reboots generally take from 1 to 10 minutes depending on the Sensor model.
Match processes outside of the reboot can also take 5 to 10 minutes to complete when changing state.
These other configuration related processes will not impact the non-Match related duties performed by your Sensor.
There are no impacts to the Brain, Recall, Stream or other Sensors (that are not having their enablement state changed).
This ONLY impacts the Sensor that is changing enablement states.
You should plan enablement or disablement of Match on a Sensor for times where being unable to process traffic will have the least impact.
Does Vectra Match support IPv6?
Yes Suricata supports IPv6 detections.
Does Vectra Match support Datacenter deployments?
Yes, Vectra Match can be deployed in both internal and external (DMZ) datacenters to provide detection.
Does Vectra Match support air gap deployments?
Yes, Vectra Match can be deployed in air gap environments when used with Quadrant UX deployment. In Airgap deployments you may download the Vectra Match Curated rulesets from the Support portal, automatic ruleset downloads are not possible in Airgap deployments due to no connectivity.
Respond UX cannot be delivered in air gap environments, though this is a factor of Respond UX itself.
Do detections from Vectra Match show up in the Vectra UI?
This is possible for QUX deployments that are paired with Vectra Recall.
If a Recall Custom Model is configured, a detection can be created in QUX.
RUX deployments have Match metadata available in Investigate. This is not a detection and is not scored but the metadata is in RUX.
Today, the Vectra Match detections are sent out via several different mechanisms.
For QUX, matches can be sent to your logging system via Syslog/Kafka. They are also available in Recall or Stream.
For RUX, matches can be output via Stream.
What features of Suricata does Vectra Match not support?
Vectra Match supports the vast majority of Suricata features, and can fully load popular rulesets like ET Open or ETPro. There are a few exceptions of what Vectra Match does not support: Editing
Suricata.yaml,thresholds.conf,classification.config, File Store, Lua, GeoIP, Datasets, logging metadata, pcap-log (aka rolling pcap).
Is there a preferred protocol for sending Vectra Match Alerts?
For QUX deployments, Vectra Match supports both Syslog and Kafka protocols, including TCP and SSL for each. SSL is generally the preferred protocol because it is a reliable transport protocol and also provides encryption, confidentiality, and integrity.
Additionally, Vectra has observed that some detections can occur based on syslog alert traffic when sent over TCP if the provided signature is not well tuned. These can easily be tuned in the ruleset configuration, but leveraging SSL as the protocol avoids this possibility.
Vectra Steam (QUX and RUX) and Recall (QUX only) are highly reliable options.
Does Vectra add any proprietary data to Match log output in addition to what Suricata natively produces?
Yes, in addition to a Syslog producer header, as of Detect version 8.0, when the Include enhanced detail header is checked in your Syslog or Kafka configuration in Vectra, a new field called
vectrain included that allows analysts to see HostID information and Sensor (device) information related to the Match that occurred.This will make it easier for analysts to understand which Sensor observed the traffic where the Match occurred and track the originating and responding host by its Vectra Host object.
Vectra HostID is a proprietary process that takes into account network artifacts and other learned information to name hosts and track them more easily by this name rather than IP address which is often transient.
Additional information included in the
vectrafield:
Does Vectra have a Add-on and App for Splunk that supports Match log output?
For QUX see Splunk SIEM / Vectra integration guide (start here for QUX) for more details.
The Technical Add-on and the App for Vectra Detect have been updated to support parsing Match log and provide a new dashboard for customers using Vectra Match with Splunk.
Please ensure you are using 1.3.0 or later of the Add-on and 1.4.0 or later of the Detect App.
For RUX see Splunk SIEM / Vectra integration guide (start here for RUX) for more details.
How can I convert the Packet Data from the Alert log into PCAP format so I can view it in a tool like Wireshark?
Vectra Match will automatically record the packet payload associated with the detection in the Payload, Payload Printable, and Packet formats in the CEF/JSON based alerts. This information can be converted into PCAP using a tool like https://idstools.readthedocs.io/en/latest/tools/eve2pcap.html which will convert this information so it can be viewed in a tool like Wireshark.
Role Permission Details
Two new permissions, each with View or Edit rights, have been created to support Vectra Match:
Permission
Rights
Allowed Capabilities
Manage – Vectra Match Ruleset
View
Viewing ruleset assignments and information about ruleset files
Manage – Vectra Match Ruleset
Edit
Uploading, assigning, or deleting rulesets
Settings – Vectra Match
View
Viewing enablement state of a Sensor, stats, and status
Settings – Vectra Match
Edit
Enabling or disabling Match on a Sensor
The below permissions and rights are the defaults included in your deployment:
Predefined Roles
Rights
Permission
admins, super_admins, restricted_admins, setting_admins, read_only
View
Manage – Vectra Match Ruleset Settings – Vectra Match
admins, super_admins, restricted_admins, setting_admins
Edit
Manage – Vectra Match Ruleset
admins, super_admins, setting_admins
Edit
Settings – Vectra Match
Customers who have created their own roles will need to make sure that the user associated with the API token they will use for Match is assigned to a role with the required permissions for the operations they want to perform.
Licensing
Do I need a license to run Vectra Match?
Yes, Vectra Match is a licensed feature. You need a license to be able to leverage it. Please contact your account team who can provide additional information.
How is licensing enforced?
A valid license is required to:
Enable Match on a Sensor.
Download the Vectra Match Curated Ruleset
Upload ruleset files to the Brain.
Assign a ruleset file to a Sensor.
What happens when the Vectra Match license expires?
Any enabled Sensors will continue to run Match with any existing ruleset that has been assigned to them.
Match can be disabled on a device and ruleset assignments can also be deleted.
How can I view the status of my license?
To check the status of your Vectra Match license, log in as the
vectrauser at the CLI of your Brain and issue theshow licensecommand. License status is also available in the Vectra UI at Configuration > SETUP → Licensing. Below is an example:
Once a license is 30 days from expiration, your Brain will being to send syslog messages in the Audit logs with a count down until expiration. Once the license expires a new syslog message is sent. Here are examples:
How do I apply my license for new deployments or for license renewals?
Online systems (connected to the Vectra cloud)
License acquisition and renewal is an automated process that requires no user intervention.
Offline systems (not connected to Vectra or air-gapped)
For details please see the Vectra Match Deployment Guide's Licensing and Deployment section.
Suricata Configuration
What version of Suricata does Vectra Match use?
Vectra Match uses the Suricata 7.0 release
How does Vectra's Dropped IP Addresses (CIDR) list impact Vectra Match?
The Dropped IP Addresses (CIDR) setting that is available in your Brain UI at Configuration → COVERAGE → Data Sources → Network → Brain Setup → IP Address Classification does not impact Vectra Match. All traffic observed by your Sensor(s) will still be copied to Vectra Match.
If you would like to ignore traffic in Vectra Match, you can use the pass or bypass Suricata rule features in your ruleset.
What is the Suricata.yaml configuration that Vectra Match uses
Please see the Vectra Match Suricata Configuration article for details
Can I modify the Suricata.yaml, Thresholds.conf, or Classification.config files?
Today, customers cannot modify these files, please contact your account team to share your use case.
How does Vectra populate the HOME_NET variable?
Vectra automatically populates the
HOME_NETvariable based on the configuration defined in the:Internal IP Addresses (CIDR) - "Internal subnet"
Viewable in your Vectra UI at Configuration → COVERAGE → Data Sources → Network → Brain Setup → IP Address Classification
Excluded Subnet of Internal IP Addresses (CIDR) - "Excluded subnet"
Viewable in your Vectra UI at Configuration → COVERAGE → Data Sources → Network → Brain Setup → IP Address Classification
Automatically discovered Southside Proxy IPs
Viewable at the CLI of your Brain with
show proxy --southsidecommand.
For Example:
If you have 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 as your Internal subnets
And 10.0.0.1, 10.0.0.2, 10.0.0.3 as Southside Proxy IP's,
And you've excluded 10.254.1.0/24 in the Excluded subnet,
The HOME_NET variable would look like:
[10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,!PROXY_IPs,!EXCLUDE_NET]
With
PROXY_IPsbeing[10.0.0.1, 10.0.0.2, 10.0.0.3]And
EXCLUDE_NETwould be[10.254.1.0/24]
Does Vectra support setting other variables besides HOME_NET?
In addition to the
HOME_NETVariable, Vectra supports the following variables:EXTERNAL_NETvariable is[!HOME_NET, PROXY_IPs, EXCLUDE_NET]PROXY_IPsis a list of IP's that are automatically added to thePROXY_IPsvariable if detected by Vectra's Southside proxy detection.Northside proxies are not factored in here.
This variable was introduced in 9.0 and enables users to automatically treat any traffic sent to Proxies as External even if they have an internal address.
You can view the list of Southside proxies on the Brain CLI using
show proxy --southside
EXCLUDE_NETThe
EXCLUDE_NETvariable is automatically populated via the Excluded Subnet configuration under Configuration → COVERAGE → Data Sources → Network → Brain Setup → IP Address Classification
Customers may use any of the supported Variables (
HOME_NET,PROXY_IPs,EXCLUDE_NET, andEXTERNAL_NET) in your own rules.If you have further custom variables, you can always resolve them into the IP netblocks and use those in the rules instead, as this is all that Suricata does when a variable is in the
Suricata.yamlfile.
What protocols can I use for sending Alerts to my SIEM/SOAR?
You can use TCP or SSL Syslog and Kafka. UDP is not supported due to the log size limitations
For fomats, Vectra supports the standard syslog (Suricata Fast Log), CEF (Suricata EVE encoded into CEF format, and JSON (Suricata EVE).
Vectra Match alerts can be sent by Stream, so all Stream protocols are also supported there including Elastic, Kafka, Raw JSON, and Syslog
What protocols does Vectra Match support detection for?
L3/L4 Protocols: IPv4, IPv6, TCP, UDP, SCTP, ICMPv4, ICMPv6, GRE
L7 Protocols: HTTP, HTTP/2, SSL, TLS, SMB, DCERPC, SMTP, FTP, SSH, DNS, Modbus, ENIP/CIP, DNP3, NFS, NTP, DHCP, KRB5, IKEv2, SIP, SNMP, RDP, RFB, MQTT
Ruleset
Where can I get a Suricata ruleset?
Starting in 8.5, Vectra is including a Vectra curated version of the Proofpoint ETPro ruleset. For more information please see Vectra curated ruleset.
How many rulesets can I assign to a single Sensor?
Multiple rulesets can be assigned per sensor, but Vectra recommends using only one at a time. You can assign different rule files to different Sensors. Please see the Vectra Match Deployment guide for additional ruleset management guidance.
How can I manage my IDS ruleset?
Vectra supports managing rulesets and modifying rule thresholds natively in the UI. Vectra strongly recommends leveraging the UI to upload and manage rulesets.
Navigate to Configuration → COVERAGE → Vectra Match to manage rulesets within the UI.
Rule modifications made through the UI are automatically layered on top of the latest ruleset file so you no longer need to reapply them manually.
For additional details, please see Managing Vectra Match Rulesets.
For advanced use cases, customers can leverage tools like Suricata-Update, or tools and services like Lawmaker to manage their IDS ruleset. These files can then be uploaded to Vectra Match.
For advanced use cases, Vectra has created a script that utilizes Match APIs to automate ruleset management.
The script is available here: https://github.com/vectranetworks/vectra_match_workflow
Feel free to use the script as is, or copy/fork it and make your own modifications.
What ruleset IDs are supported in Match?
Rule IDs in a ruleset are required to be a positive 32-bit integer.
ET rules and the Vectra Match Curated Ruleset use IDs in the 1,000,000 to 2,999,999 range.
Rule IDs above 9,000,000 are reserved for Vectra use.
Customer IDs must be below 9,000,000.
Duplicate IDs should not be assigned to the same sensor, since the rule that will be loaded into Suricata will be arbitrarily chosen between the two.
What file size limits exist for rule files?
You can upload up to a 200MB rule file, and a max of 25 different files can be applied to sensors.
How can I tune the performance of my ruleset?
Please see the Performance and Ruleset Optimization Guidance article for details.
What happens if I upload an invalid signature?
Vectra Match will attempt to load the full ruleset file on the sensor. If there are any errors, Suricata will ignore the given signature but load the rest of the ruleset. The error for a given rule must be corrected before the given rule can be enabled.
You can see how many rules have been loaded and how many errors by using the Stats endpoint
{{baseUrl}}/vectra-match/stats?device_serial={{device_serial}}
Can I run Suricata decoder event rules with Vectra Match?
Yes, you can run the decoder event rules which are part of Suricata (https://github.com/OISF/suricata/blob/master/rules/decoder-events.rules). You simply need to include them in your
.rulesfile that you upload.
Why do alerts forwarded and rate limited stats reset to 0?
In the Stats endpoint, certain stats are reset on system events like ruleset upload, enable/disable Vectra Match, or reboots; with the ruleset upload typically being the most frequent event.
In the above output the events are reset upon ruleset upload, enable/disable of Vectra Match and Reboots.
alerts_dropped_for_rate_limit_this_houris also reset hourly
If a rule file is pushed while a sensor is disconnected, will it get the rule file once it is reconnected?
Yes, within 20 minutes of a system coming back online it should automatically receive the rules file which was pushed while it was offline. You can verify this by reviewing the
statsendpoint for the last_reload time.
Performance
How can I resize a virtual Sensor to allow for more throughput while running Match?
If you virtual Sensor does not have the resources to run Match in addition to its normal duties producing metadata for your Vectra platform, it can be resized to a larger configuration that supports more throughput. Alternatively, you can also redeploy the vSensor in a larger supported configuration. For details per supported platform, please see the guidance in the Resizing Virtual Sensors and Brains .
How does Vectra calculate the performance of Vectra Match
Please see the Vectra Match Performance and Ruleset Optimization Guidance article for details.
Does Vectra rate limit Suricata alerts?
Vectra does have reasonable limits to protect the Vectra platform from excessive alert rates to prevent downstream impacts of signatures that are not well optimized. When this occurs, you will receive an error message similar to the below via Syslog:
Please note that while this unhealthy status as a result of rate limiting is applied second by second, the unhealthy state is retained in a cache for 1 hour so that administrators who query the API will see that state and be aware of it. In versions prior to 7.8, this state was cached for 24 hours.
The unhealthy state will also be communicated via an alert email notification if System alerts are configured in Configuration → RESPONSE → Notifications.
The unhealthy state will also be communicated via syslog or Kafka if Vectra Match logs are configured to be sent to your log receiver.
Performing a GET against the status endpoint of the API for a device that is being rate limited would return as below:
The rate limits are performed on a second by second basis once the thresholds are exceeded. Check your logging system to see top hitting signatures to get a sense of which rules are triggering rapidly.
The Status output from the API call above output can be cached, for the latest status, you can check the stats output at the bottom of the output to see if there are any rate limits or recent rate limits. Note that this does get reset upon rule uploads, enabling/disabling Vectra Match, or Sensor Reboots:
Note that the alerts suppressed output of the Stats endpoint refers to alerts suppressed by the Suricata threshold/limit feature within rules, and not Vectra Match rate limiting. For instance if you use the Limit keyword: https://suricata.readthedocs.io/en/suricata-6.0.0/rules/thresholding.html#type-limit and alerts are limited by Suricata, then the
alerts suppressedmetric will increase, but not thealerts_dropped_for_rate_limit.
Does Vectra Match inspect the full payloads or are any traffic skipped/bypassed?
Vectra Match processes the full payloads.
Recall
Does Recall support Vectra Match?
Starting in 7.9, Customers with Recall and Vectra Match enabled will automatically receive metadata from Vectra Match in the new metadata index
metadata-match. For more information about the attributes in Vectra Match see Vectra AI platform metadata.
Does the Recall data include the enhanced detail for Host and Sensor information that was added in v8.0?
Yes, Recall data in v8.0 and higher will automatically include the enhanced detail described in the Does Vectra add any proprietary data to Match log output in addition to what Suricata natively produces? entry from the General section.
Do I need to configure anything for Vectra Match alerts to show up in Recall?
Any metadata associated with Vectra match will automatically be published to Recall, there is no action required once Vectra Match is enabled with a valid license and ruleset.
What Recall features are possible with Vectra Match?
Vectra Match in Recall will work just like any other metadata index including Discover searches, Dashboards, Saved Searches, Custom Models, Alerts, and Reports. Recall treats the Vectra Match as just another datasource.
Are Recall Custom Models supported with Vectra Match? Are their any limitations or best practices?
Yes, Recall Custom Models can be generated off of Vectra Match alerts. They are configured identically to any other Custom Model. Like traditional Custom Models, these are meant to be reserved for high value detections, and not for audit or informational behaviors.
We recommend that customers are selective about which alerts qualify as a custom model to ensure that the volume does not trigger built in Custom Model rate limit protections on the platform.
While any valid Recall query can be converted into a Custom Model, it is recommended that customers match on specific elements of alerts such as the Signature, Signature ID, or specific metadata fields of interest, rather than enabling detection on broad classes of signatures which may generate a high volume of custom models in a non-tuned ruleset.
Last updated
Was this helpful?