})
Integrations
diff --git a/docs/cse/ingestion/ingestion-sources-for-cloud-siem/corelight-zeek.md b/docs/cse/ingestion/ingestion-sources-for-cloud-siem/corelight-zeek.md
index 0f4e8be796..0c1518db8c 100644
--- a/docs/cse/ingestion/ingestion-sources-for-cloud-siem/corelight-zeek.md
+++ b/docs/cse/ingestion/ingestion-sources-for-cloud-siem/corelight-zeek.md
@@ -11,6 +11,10 @@ This section has instructions for collecting Corelight Zeek log messages and sen
These instructions are for Corelight Zeek logs sent as JSON over syslog.
+:::note
+The Sumo Logic Product Team has continued our on-premise network sensor feature for Sumo Logic Cloud SIEM (see [release note](/release-notes-cse#cloud-siem-network-sensor-end-of-life)). This article describes how to use Zeek as a network sensor to provide equivalent monitoring of your network.
+:::
+
## Step 1: Configure collection
In this step, you configure a Syslog Source to collect Corelight Zeek log messages. You can configure the source on an existing Installed Collector or create a new collector. If you’re going to use an existing collector, jump to [Configure a Syslog Source](#configure-a-syslog-source) below. Otherwise, create a new collector as described in [Configure an Installed Collector](#configure-an-installed-collector) below, and then create the Syslog Source on the collector.
@@ -53,17 +57,83 @@ In this step, you configure a Syslog Source to collect Corelight Zeek log messag
In this step you configure Zeek to send log messages to the Sumo Logic platform. For instructions, see [Corelight JSON Streaming documentation](https://github.com/corelight/json-streaming-logs).
-## Step 3: Cloud SIEM Ingest Configuration
+## Step 3: Enable parsing and mapping of Zeek logs
+
+After configuring the appropriate source, use one of the methods described below to provide information Cloud SIEM requires to parse and map Zeek logs.
+
+This configuration step is required to ensure that Cloud SIEM knows how to parse incoming Zeek logs, correctly map the log fields to schema attributes, and create Cloud SIEM records. The most important bit of information is what type of data a particular log contains. Zeek has a variety of log types, for example `conn` for TCP/UDP/ICMP connections, `http` for HTTP requests and replies, and `ftp` for FTP activity.
+
+So, how to determine whether a Zeek log is a `conn`, `http`, `ftp`, or some other log type? Zeek logs do not contain a key that explicitly holds a value that is only the log type identifier. There are two options for dealing with this:
+
+* Use Corelight to add a field to each Zeek log that identifies its log type. See [Use Corelight](#use-corelight) below.
+* Use Sumo Logic Field Extraction Rules (FERs) to create fields that provide the log type and other data that enables Cloud SIEM to parse and map the logs. See [Use FERs](#use-fers).
+
+### Use Corelight
+
+With this method, you use Corelight’s [json-streaming-logs](https://github.com/corelight/json-streaming-logs), a Bro script package that creates JSON formatted logs, and adds an extension field, named _path that identifies the Zeek log type to each Zeek log. Then, you map that field to **Event ID** in a Sumo Logic ingest mapping.
+
+After installing the `json-streaming-logs` package, follow these instructions to set up the Sumo Logic mapping.
+
+1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the top menu select **Configuration**, and then under **Integrations** select **Sumo Logic**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the top menu select **Configuration**, and then under **Cloud SIEM Integrations** select **Ingest Mappings**. You can also click the **Go To...** menu at the top of the screen and select **Ingest Mappings**.
+1. On the **Ingest Mappings** tab, click **+ Add Ingest Mapping**.
})
+1. On the **Add Ingest Mapping** tab:
+ 1. **Source Category**. Enter the Source Category value you assigned to the Source you configured above.
+ 1. **Format**. Choose **Bro/Zeek JSON**.
+ 1. **Event ID**. Enter `{_path}`.
+ 1. **Enabled**. Use the slider to enable the mapping if you’re ready to receive Zeek logs.
+ 1. Click **Save**.
})
+
+### Use FERs
+
+With this method, you use Sumo Logic Field Extraction Rules (FERs) to extract fields from each Zeek log. The fields you extract will provide the information necessary for Cloud SIEM to correctly parse and map the logs.
+
+Here’s an example Bro log from the Security Onion platform.
+
+```
+{"TAGS":".source.s_bro_conn","SOURCEIP":"127.0.0.1","PROGRAM":"bro_conn","PRIORITY":"notice","MESSAGE":"{\"ts\":\"2020-05-28T10:32:51.997054Z\",\"uid\":\"Cu3KVA2TbWqZm1Z0S6\",\"id.orig_h\":\"1.2.3.4\",\"id.orig_p\":16030,\"id.resp_h\":\"5.6.7.8\",\"id.resp_p\":161,\"proto\":\"udp\",\"duration\":30.000317811965942,\"orig_bytes\":258,\"resp_bytes\":0,\"conn_state\":\"S0\",\"local_orig\":true,\"local_resp\":true,\"missed_bytes\":0,\"history\":\"D\",\"orig_pkts\":6,\"orig_ip_bytes\":426,\"resp_pkts\":0,\"resp_ip_bytes\":0,\"sensorname\":\"test\"}","ISODATE":"2020-05-28T10:34:24+00:00","HOST_FROM":"somehost","HOST":"somehost","FILE_NAME":"/nsm/bro/logs/current/conn.log","FACILITY":"user"}
+```
+
+In the log above, the content of the Bro log is the value of the `MESSAGE` key. Note that no key in the log explicitly states the log type, which is `conn`.
+
+To enable Cloud SIEM to successfully process the log, we need to create the following fields listed in the table below.
+
+
+
+ | Field |
+ Parse Expression |
+
+
+ _siemMessage |
+ json field=_raw "MESSAGE" as _siemMessage |
+
+
+ _siemEventId |
+ json field=_raw "PROGRAM" as _siemEventId | parse regex field=_siemEventId "bro_(?<_siemEventId>.*)" |
+
+
+ _siemFormat |
+ "bro" as _siemFormat |
+
+
+ _siemVendor |
+ "bro" as _siemVendor |
+
+
+ _siemProduct |
+ "bro" as _siemProduct |
+
+
-In this step, you configure a Sumo Logic Ingest Mapping in Cloud SIEM for the source category assigned to your source or collector you configured in [Step 1](#step-1-configure-collection). The mapping tells Cloud SIEM the information it needs to select the right mapper to process messages that have been tagged with that source category.
+Perform these steps for each of the FERs.
-1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the top menu select **Configuration**, and then and under **Integrations** select **Sumo Logic**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the top menu select **Configuration**, and then under **Cloud SIEM Integrations** select **Ingest Mappings**. You can also click the **Go To...** menu at the top of the screen and select **Ingest Mappings**.
-1. On the **Ingest Mappings** tab, click **+ Add Ingest Mapping**.
-1. On the **Add Ingest Mapping** popup:
- 1. **Source Category**. Enter the category you assigned to the HTTP Source or Hosted Collector in [Step 1](#step-1-configure-collection).
- 1. **Format**. Enter *Bro/Zeek JSON*.
- 1. **Event ID**. *`{_path}`*.
})
-1. Click **Create** to save the mapping.
+1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the main Sumo Logic menu, select **Manage Data > Logs > Field Extraction Rules**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the top menu select **Configuration**, and then under **Logs** select **Field Extraction Rules**. You can also click the **Go To...** menu at the top of the screen and select **Field Extraction Rules**.
+1. Click **Add Rule**.
+1. In the **Add Field Extraction Rule** pane:
+ 1. **Rule Name**. Enter a meaningful name for the rule.
+ 1. **Applied At**. Click Ingest Time.
+ 1. **Scope**. Click **Specific Data**.
+ 1. **Parse Expression**. Enter the parse expression shown in the table above for the field the rule will extract.
+1. Click **Save**.
})
## Step 4: Verify Ingestion
@@ -71,4 +141,4 @@ In this step, you verify that your logs are successfully making it into Cloud SI
1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the top menu select **Configuration**, and then under **Incoming Data** select **Log Mappings**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the top menu select **Configuration**, and then under **Cloud SIEM Integrations** select **Log Mappings**. You can also click the **Go To...** menu at the top of the screen and select **Log Mappings**.
1. On the **Log Mappings** tab search for "Zeek" and check the **Records** columns.
})
-1. For a more granular look at the incoming records, you can also search the Sumo Logic platform for Corelight Zeek security records.
})
+1. For a more granular look at the incoming records, you can also search the Sumo Logic platform for Corelight Zeek security records.
\ No newline at end of file
diff --git a/docs/cse/rules/import-yara-rules.md b/docs/cse/rules/import-yara-rules.md
index 097a3188fa..63ab4f9f35 100644
--- a/docs/cse/rules/import-yara-rules.md
+++ b/docs/cse/rules/import-yara-rules.md
@@ -13,7 +13,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
This section has instructions for importing YARA rules from GitHub into Cloud SIEM.
-YARA rules are an open source framework for identifying malware. Cloud SIEM runs YARA rules against files uploaded by the [network sensor](/docs/cse/sensors/network-sensor-deployment-guide). When a file matches a YARA rule, Cloud SIEM creates a special record which results in a “file analysis” signal being created. Once you’ve imported rules, Cloud SIEM will sync with the repository no less than every hour.
+YARA rules are an open source framework for identifying malware. Cloud SIEM runs YARA rules against files uploaded by the [network sensor](/docs/cse/ingestion/ingestion-sources-for-cloud-siem/corelight-zeek/). When a file matches a YARA rule, Cloud SIEM creates a special record which results in a “file analysis” signal being created. Once you’ve imported rules, Cloud SIEM will sync with the repository no less than every hour.
To import YARA rules:
diff --git a/docs/cse/sensors/index.md b/docs/cse/sensors/index.md
deleted file mode 100644
index 6ad1e09bd3..0000000000
--- a/docs/cse/sensors/index.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-slug: /cse/sensors
-title: Cloud SIEM Sensors
-description: Cloud SIEM Sensors collect log and event data from your infrastructure and applications.
----
-
-
-This guide has information about Cloud SIEM sensors, the components that collect log and event data from your infrastructure and applications.
-
-import useBaseUrl from '@docusaurus/useBaseUrl';
-
-In this section, we'll introduce the following concepts:
-
-
-
-
-
})
Ingest Zeek Logs
-
Learn how to collect Zeek (Bro) logs and ingest them to Cloud SIEM.
-
-
-
-
-
})
Sensor Download Locations
-
Learn about where to download the Cloud SIEM Network Sensor that's specific to your Cloud SIEM deployment.
-
-
-
-
-
-
diff --git a/docs/cse/sensors/ingest-zeek-logs.md b/docs/cse/sensors/ingest-zeek-logs.md
deleted file mode 100644
index f45560baf6..0000000000
--- a/docs/cse/sensors/ingest-zeek-logs.md
+++ /dev/null
@@ -1,146 +0,0 @@
----
-id: ingest-zeek-logs
-title: Ingest Zeek Logs
-description: Learn how to collect Zeek (Bro) logs and ingest them to Cloud SIEM.
----
-
-import useBaseUrl from '@docusaurus/useBaseUrl';
-
-This topic has instructions for ingesting Zeek logs into Cloud SIEM.
-
-## What is Zeek?
-
-Cloud SIEM uses [Zeek](https://zeek.org/) (formerly known as Bro) for network visibility. Zeek is an open source network analysis framework that organizes packets into flows, decodes common protocols, performs file extraction, SSL certificate validation, OS fingerprinting and more. Zeek can be extended through plugins for additional detection capabilities.
-
-## Supported collection method: Sumo Logic Source
-
-If you already have a Zeek deployment, you can collect logs using a Sumo Logic Collector and Source.
-
-:::note
-This method requires that your Zeek logs are in JSON format.
-:::
-
-### Configure a Sumo Logic Source
-
-In this step, you configure a Sumo Logic Source on an Sumo Logic Installed Collector. Choose the appropriate Source type based on:
-* If you already have a method of forwarding Zeek logs in JSON format in Syslog format to a collector in your environment, you can use a Syslog Source to ingest the logs.
-* If you’re not set up to use Syslog, and have Zeek log files stored on a filesystem, you can use a Local File Source to ingest the logs.
-
-After configuring the appropriate source, use one of the methods described in [Enable parsing and mapping of Zeek logs](#enable-parsing-and-mapping-of-zeek-logs) to provide information Cloud SIEM requires to parse and map Zeek logs.
-
-### Enable parsing and mapping of Zeek logs
-
-This configuration step is required to ensure that Cloud SIEM knows how to parse incoming Zeek logs, correctly map the log fields to schema attributes, and create Cloud SIEM records. The most important bit of information is what type of data a particular log contains. Zeek has a variety of log types, for example `conn` for TCP/UDP/ICMP connections, `http` for HTTP requests and replies, and `ftp` for FTP activity.
-
-So, how to determine whether a Zeek log is a `conn`, `http`, `ftp`, or some other log type? Zeek logs don’t contain a key that explicitly holds a value that is only the log type identifier. There are two options for dealing with this:
-
-* Use Corelight to add a field to each Zeek log that identifies its log type. See [Use Corelight](#use-corelight) below.
-* Use Sumo Logic Field Extraction Rules (FERs) to create fields that provide the log type and other data that enables Cloud SIEM to parse and map the logs. See [Use FERs](#use-fers).
-
-### Use Corelight
-
-With this method, you use Corelight’s [json-streaming-logs](https://github.com/corelight/json-streaming-logs), a Bro script package that creates JSON formatted logs, and adds an extension field, named _path that identifies the Zeek log type to each Zeek log. Then, you map that field to **Event ID** in a Sumo Logic ingest mapping.
-
-After installing the `json-streaming-logs` package, follow these instructions to set up the Sumo Logic mapping.
-
-1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the top menu select **Configuration**, and then under **Integrations** select **Sumo Logic**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the top menu select **Configuration**, and then under **Cloud SIEM Integrations** select **Ingest Mappings**. You can also click the **Go To...** menu at the top of the screen and select **Ingest Mappings**.
-1. On the **Ingest Mappings** tab, click **+ Add Ingest Mapping**.
-1. On the **Add Ingest Mapping** tab:
- 1. **Source Category**. Enter the Source Category value you assigned to the Source you configured above in [Configure a Sumo Logic Source](#configure-a-sumo-logic-source).
- 1. **Format**. Choose **Bro/Zeek JSON**.
- 1. **Event ID**. Enter `{_path}`.
- 1. **Enabled**. Use the slider to enable the mapping if you’re ready to receive Zeek logs.
- 1. Click **Create**.
-
-### Use FERs
-
-With this method, you use Sumo Logic Field Extraction Rules (FERs) to extract fields from each Zeek log. The fields you extract will provide the information necessary for Cloud SIEM to correctly parse and map the logs.
-
-Here’s an example Bro log from the Security Onion platform.
-
-```
-{"TAGS":".source.s_bro_conn","SOURCEIP":"127.0.0.1","PROGRAM":"bro_conn","PRIORITY":"notice","MESSAGE":"{\"ts\":\"2020-05-28T10:32:51.997054Z\",\"uid\":\"Cu3KVA2TbWqZm1Z0S6\",\"id.orig_h\":\"1.2.3.4\",\"id.orig_p\":16030,\"id.resp_h\":\"5.6.7.8\",\"id.resp_p\":161,\"proto\":\"udp\",\"duration\":30.000317811965942,\"orig_bytes\":258,\"resp_bytes\":0,\"conn_state\":\"S0\",\"local_orig\":true,\"local_resp\":true,\"missed_bytes\":0,\"history\":\"D\",\"orig_pkts\":6,\"orig_ip_bytes\":426,\"resp_pkts\":0,\"resp_ip_bytes\":0,\"sensorname\":\"test\"}","ISODATE":"2020-05-28T10:34:24+00:00","HOST_FROM":"somehost","HOST":"somehost","FILE_NAME":"/nsm/bro/logs/current/conn.log","FACILITY":"user"}
-```
-
-In the log above, the content of the Bro log is the value of the `MESSAGE` key. Note that no key in the log explicitly states the log type, which is `conn`.
-
-To enable Cloud SIEM to successfully process the log, we need to create the following fields listed in the table below.
-
-
-
- | Field |
- Parse Expression |
-
-
- _siemMessage |
- json field=_raw "MESSAGE" as _siemMessage |
-
-
- _siemEventId |
- json field=_raw "PROGRAM" as _siemEventId | parse regex field=_siemEventId "bro_(?<_siemEventId>.*)" |
-
-
- _siemFormat |
- "bro" as _siemFormat |
-
-
- _siemVendor |
- "bro" as _siemVendor |
-
-
- _siemProduct |
- "bro" as _siemProduct |
-
-
-
-Perform these steps for each of the FERs.
-
-1. [**Classic UI**](/docs/get-started/sumo-logic-ui-classic). In the main Sumo Logic menu, select **Manage Data > Logs > Field Extraction Rules**.
[**New UI**](/docs/get-started/sumo-logic-ui). In the top menu select **Configuration**, and then under **Logs** select **Field Extraction Rules**. You can also click the **Go To...** menu at the top of the screen and select **Field Extraction Rules**.
-1. Click **Add Rule**.
-1. In the **Add Field Extraction Rule** pane:
- 1. **Rule Name**. Enter a meaningful name for the rule.
- 1. **Applied At**. Click Ingest Time.
- 1. **Scope**. Click **Specific Data**.
- 1. **Parse Expression**. Enter the parse expression shown in the table above for the field the rule will extract.
-1. Click **Save**.
-
-
-## Unsupported collection method: Network Sensor
-
-:::warning End-of-Life
-This section describes using the Cloud SIEM Network Sensor. [Network Sensor has reached its end of life](/docs/cse/sensors/network-sensor-end-of-life/). Instead, use Zeek. For more information, see [Supported collection method: Sumo Logic Source](#supported-collection-method-sumo-logic-source) above.
-:::
-
-You can use Cloud SIEM’s Network Sensor to collect Zeek logs and upload them to an HTTP Source on a Sumo Logic Hosted Collector. This method ensures that supported Bro policies are enabled and that the supported Bro output format is configured. It also results in the creation of Cloud SIEM records from the raw Zeek log messages. For instructions, see [Network Sensor Deployment Guide](/docs/cse/sensors/network-sensor-deployment-guide).
-
-The Network Sensor extracts files observed over cleartext protocols that match selected MIME types. You can configure what types will be extracted using the [extracted_file_types](/docs/cse/sensors/network-sensor-deployment-guide) property in the Network Sensor’s configuration file, `trident-sensor.cfg`. By default the sensor will upload password-protected zip files and the following types of executables:
-
-* `application/x-dosexec`
-* `application/x-msdownload`
-* `application/x-msdos-program`
-
-:::note
-YARA [file analysis](/docs/cse/rules/import-yara-rules) is supported only for files extracted by the Network Sensor. If you use your own Zeek deployment and ingest logs using a Sumo Logic Source you can't also upload extracted files.
-:::
-
-### Filtering Zeek logs
-
-This section describes two methods you can use to filter the logs that the Network Sensor sends to Cloud SIEM.
-
-* You can configure a Berkeley Packet Filter (BPF) filter using the [filter](/docs/cse/sensors/network-sensor-deployment-guide) parameter in Network Sensor’s configuration file, `trident-sensor.cfg`. This is the most efficient filtering mechanism as it is performed before Network Sensor processing.
-
- The value of the `filter` parameter is an expression that begins with `not`. This example expression ensures the that the Network Sensor won't process any traffic involving host `a.b.c.com` or host `d.e.f.com`:
-
- `not ( host a.b.c.com ) and not ( host d.e.f.com )`
-
- For information about BPF filter syntax, see https://biot.com/capstats/bpf.html.
-
-* You can also filter by Zeek log type using the [skipped_log_types](/docs/cse/sensors/network-sensor-deployment-guide) property in `trident-sensor.cfg`. The default value of `skipped_log_types` is:
-
- ```
- dpd,weird,syslog,pe,tunnel,communication,conn-summary,known_hosts,software,stdout.stderr,loaded_scripts,ntp
- ```
-
- You can add additional Zeek log types to the list to exclude them.
-
-The BPF filter is applied before `skipped_log_types`. So, given the example BPF filter above, if you add `dns` to the `skipped_log_types` value, you won't ingest logs related to traffic involving hosts `a.b.c.com` or `d.e.f.com`, and you won't ingest DNS data.
\ No newline at end of file
diff --git a/docs/cse/sensors/log-sensor-troubleshooting.md b/docs/cse/sensors/log-sensor-troubleshooting.md
deleted file mode 100644
index ef7e9c43a3..0000000000
--- a/docs/cse/sensors/log-sensor-troubleshooting.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-id: log-sensor-troubleshooting
-title: Log Sensor Troubleshooting
-description: Learn how to collect Log Sensor status and data to support troubleshooting efforts.
----
-
-:::warning end-of-life
-The Cloud SIEM Log Sensor has reached end of life and is no longer supported. Please migrate to a Sumo Logic Hosted Collector or Installed Collector. For more information, see the [end of life notice](https://app.getbeamer.com/cloudsiementerprise/en/end-of-life-notice-_-cloud-siem-enterprise-sensors).
-:::
-
-The Cloud SIEM Log Sensor collects log data and sends it to the legacy Cloud SIEM server. (The Log Sensor does not send log data to the Sumo Logic platform. Sumo Logic collectors serve that purpose.)
-
-If your organization uses the Log Sensor, This section provides instructions for gathering troubleshooting information Cloud SIEM support may request if you have problems with the sensor.
-
-## Restart sensor
-
-The following command restarts the sensor. You need to restart the sensor after making changes to the sensor configuration file, `/opt/trident/log-sensor/conf/trident-sensor.cfg`.
-
-`$ systemctl restart trident_log_sensor`
-
-## Get sensor status
-
-This command returns the status of the Log Sensor.
-
-`$ systemctl status trident_log_sensor`
-
-
-## Show sensor listen ports
-
-The following command lists the sensor's listen ports, and state information for each.
-
-`$ ss -an | grep LIST | grep :::85.. `
-
-## View sensor configuration file
-
-This command lists the sensor’s configuration file.
-
-`$ cat /opt/trident/log-sensor/conf/trident-sensor.cfg`
-
-
-## Edit sensor configuration file
-
-This command opens the sensor’s configuration file in the vi editor.
-
-`$ vi /opt/trident/log-sensor/conf/trident-sensor.cfg `
-
-## View sensor log file
-
-This command tails the sensor’s log file, assuming that it is located in its default location.
-
-`$ tail -f /opt/trident/log-sensor/logs/trident-sensor.log`
-
-
-## View logs sent by the sensor to Cloud SIEM
-
-This command tails the sensor’s `output.log` file which contains logs that the sensor has sent to the Cloud SIEM server.
-
-`$ tail -f /opt/trident/log-sensor/output/log/output.log`
-
-## View count of logs sent by the sensor to Cloud SIEM
-
-This command returns a count of the logs sent by the sensor to the Cloud SIEM server.
-
-`$ ls -lh /opt/trident/log-sensor/output/log/`
-
-
diff --git a/docs/cse/sensors/network-sensor-deployment-guide.md b/docs/cse/sensors/network-sensor-deployment-guide.md
deleted file mode 100644
index e3a83a59f0..0000000000
--- a/docs/cse/sensors/network-sensor-deployment-guide.md
+++ /dev/null
@@ -1,701 +0,0 @@
----
-id: network-sensor-deployment-guide
-title: Network Sensor Deployment Guide
-sidebar_label: Network Sensor Deployment
-description: Learn about Network Sensor deployment planning, standard sensor placement, sensor requirements, installation, general configuration, and helpful commands.
----
-
-import useBaseUrl from '@docusaurus/useBaseUrl';
-import SensorEOL from '../../reuse/cloud-siem-network-sensor-eol.md';
-
-:::warning end-of-life
-
-:::
-
-This section has instructions for deploying the Cloud SIEM Network Sensor. It covers deployment planning, standard sensor placement, sensor requirements, installation, general configuration, and helpful commands.
-
-## Network Sensor overview
-
-The Cloud SIEM Network Sensor is a network security monitor. It uses Zeek, an open source network analysis framework to organize packets into flows, decode common protocols, perform file extraction, SSL certificate validation, OS fingerprinting and more.
-
-The Network Sensor monitors live network traffic, and produces [log files](https://docs.zeek.org/en/current/script-reference/log-files.html) that record a network’s activity in high-level terms. These logs record every connection seen on the wire, and application-layer transcripts, including all HTTP sessions with their requested URIs, key headers, MIME types, and server responses; DNS requests with replies; SSL certificates; key content of SMTP sessions. The log files generated by the sensor are ingested by Cloud SIEM.
-
-The Network Sensor has a file extraction policy, enabled by default, that saves files observed on the network (unencrypted transfers, e.g. over protocols including SMB and HTTP). Configuration of this policy includes mime-types (exe, zip, pdf, and so on) and maximum extracted file size.
-
-The sensor uses [PF_RING](https://www.ntop.org/products/packet-capture/pf_ring/) for flow-based load balancing across a number of processes that are monitoring/sniffing the same interface.
-
-## Deployment process overview
-
-1. Determine the appropriate location for each sensor, based on anticipated traffic.
-1. For each location you designate:
- 1. Determine the amount of throughput you will get with this placement.
- 1. Use the scaling guide to determine the CPU and memory requirements for the VM or hardware. Confirm that their firewall rules are in place.
- 1. Confirm that there is traffic flowing on the interface.
- 1. Install the sensor.
-1. Confirm the configuration and that data is flowing into the cluster.
-
-## Network Sensor positioning best practices
-
-Robust network defense is enabled by visibility into events happening on the network. Events affecting digital assets may occur without observable after effects.
-
-Cloud SIEM helps clients achieve a robust level of network security and surface insights from their environment through the Cloud SIEM platform and deployed sensors. A number of best practices apply to positioning these sensors for the best results. This section provides detailed guidance on optimal sensor visibility in the most common network environments.
-
-### Position sensor in front of forward proxies
-
-Forward proxies, such as HTTP web proxies, broker client connections to the internet and perform caching and content filtering. Because many threats are hosted on the web and delivered to internal clients by means of drive-by download attacks and similar methods, this outbound web pathway is critically important to security monitoring.
-
-The following diagram Illustrates optimal sensor positioning prior to a web proxy.
-
-
})
-
-Sumo Logic advises positioning Network Sensors for visibility at a monitoring point immediately in front of the proxy server(s). This allows the sensor to record client source addresses and to see all web requests prior to content filtering. This is an important factor for a number of Cloud SIEM’s rules and analytics, which rely on knowing the “true” source of requests. Because a number of threats beacon to remote internet servers, seeing even those requests that are filtered by a proxy server is important for monitoring and response.
-
-Positioning the Network Sensor after a forward proxy is not advised. This placement results in the sensor seeing all traffic sourced from the proxy and complicates (or renders impossible) the ability to determine which assets or users on the LAN were the origin of the traffic.
-
-#### Explicit versus transparent forward proxies and server access logs
-
-Forward proxies may be configured in an environment in either or both of the following ways:
-
-* Explicit. Explicit proxy settings configure clients to use a proxy server for web access. This is often configured by admin policies or by using mechanisms such as proxy auto-configuration (PAC) files or Web Proxy Auto-Discovery Protocol (WPAD).
-* Transparent. Transparent proxies intercept outbound web traffic with the assistance of network devices such as firewalls, routers, switches or load balancers, sometimes using Web Cache Communication Protocol (WCCP) to redirect and balance traffic flows. Clients that are transparently proxied require no configuration as the traffic is proxied upstream when it egresses the network.
-
-In an explicit proxy configuration, clients connect to the proxy server and issue requests. The proxy performs DNS resolution and connects to the remote (origin) server on behalf of the client, meaning the destination IP address for client requests is that of the proxy server rather than the remote server on the internet. In a transparent topology, clients are unaware of the proxy. They perform DNS resolution and attempt to connect to the remote (origin) server directly, meaning the destination IP address in request traffic is that of the remote server. In either case, pre-proxy sensor placement is recommended. A Network Sensor positioned after the proxy server sees the proxy server as the source IP address for all web traffic, masking the identity of
-the client.
-
-### Position sensor behind reverse proxies
-
-Reverse proxy servers are positioned in front of web servers and can provide caching, load balancing and request filtering capabilities. Many reverse proxies also provide SSL acceleration services to offload SSL/TLS processing from backend servers. Cloud SIEM recommends positioning Network Sensor behind reverse proxies, between them and the backend web servers. This positioning allows the sensor to see traffic that is decrypted (allowing it to inspect and collect metadata for the complete request/response) and allows the Network Sensor to collect the true destination address of the backend server behind the proxy. This is particularly useful when large pools of servers exist behind reverse proxies to help identify targeted and affected hosts accurately. Because positioning the sensor behind the reverse proxy causes the network traffic to carry the IP address of the proxy as the source, it is important to send the original client address in the RFC7239 Forwarded extension, X-Forwarded-For header, or whatever related standard is best supported by reverse proxies in the environment.
-
-### Position sensor inside perimeter firewalls and NATs
-
-In all cases, sensor visibility inside of firewalls and NAT devices is advised.
-
-#### Perimeter firewalls
-
-Perimeter firewalls are positioned at an organization’s network border and are often one of the last devices for traffic outbound from an organization or inbound to it from the internet. In both cases, Sumo Logic recommends Network Sensor placement inside the firewall.
-
-For outbound traffic, this ensures that the sensor can see traffic prior to Network Address Translation (NAT) and before any egress filters/ACLs are applied. As is the case with forward proxies, it is important to see outbound communication attempts from hosts on the network even if they are filtered upstream.
-
-The Network Sensor logs every connection attempt observed, even those consisting of only a single TCP SYN packet. For inbound traffic, it is important that the sensor inspects only traffic that is allowed through the firewall filter policy and/or ingress ACLs. Doing so eliminates unimportant internet background noise. It also reduces the amount of traffic inspected, both bits per second (bps) and packets per second (pps), which can reduce load on the Network Sensor. This has a positive effect on log volume. These simple steps make it easier to surface insights on the more meaningful traffic which successfully passes into the environment.
-
-#### NAT Devices
-
-Aside from the devices and configurations described above, similar challenges are presented any time a Network Sensor inspects traffic after application of Network Address Translation. (NAT). NAT may refer to port address translation (PAT), source or destination NATs. In any case that a NAT policy rewrites the source IP address of a connection, it can impact the ability for Cloud SIEM to analyze and identify affected assets and makes it difficult for operations teams to respond effectively. Sumo Logic recommends that Network Sensors have visibility in front of NAT.
-
-## Installation requirements
-
-This section describes resource requirements and prerequisites for Network Sensor deployment.
-
-### Host resource requirements
-
-We recommend installing the Network Sensor on a host with at least two interfaces - one for traffic monitoring and one for management. That way, the sensor doesn't process and upload traffic associated with sensor management for analysis.
-
-The system upon which you install the Network Sensor must have the following resources, at a minimum. Depending on expected throughput, additional core, memory, and storage resources may be required, as shown in [Throughput-dependent resource requirements](#throughput-dependent-resource-requirements)
-below.
-
-| Operating System | Cores (CPU) | Memory (RAM) | Storage (Disk) |
-|:------------------------------------|:-------------|:--------------|:----------------|
-| CentOS 7 or Ubuntu 16, 18, 20 | 4 | 4GB | 250GB |
-
-:::note
-Before you deploy the Network Sensor, make sure you know the TAP or SPAN interface upon which captured data is available.
-:::
-
-### Prerequisites for CentOS
-
-For CentOS, before running the install command, run these commands as root (or prefix with `sudo`):
-
-```
-yum update -y
-yum install -y kernel-$(uname -r) kernel-headers-$(uname -r) kernel-devel-$(uname -r) gcc*
-dnf install -y 'dnf-command(config-manager)'
-dnf config-manager --set-enabled powertools
-yum install -y elfutils-libelf-devel python3
-reboot
-```
-
-### Throughput-dependent resource requirements
-
-| Throughput Specs | Cores (CPU) | Memory (RAM) | Storage (Disk) |
-|:--|:--|:--|:--|
-| 250mbps | 4 | 4GB | 250GB |
-| 500mbps | 5 | 8GB | 250GB |
-| 750mbps | 6 | 12GB | 250GB |
-| 1gbps | 7 | 16GB | 500GB |
-| 1.25gbps | 8 | 20GB | 500GB |
-| 1.5gbps | 9 | 24GB | 500GB |
-| 1.75gbps | 10 | 28GB | 500GB |
-| 2gbps+ | Consult your SE. | Consult SE
(Estimate is 4GB per 250Mbs) | Consult your SE. |
-
-### Outbound firewall rules
-
-See [Securing access to Sumo Logic infrastructure via DNS name or IP address](/docs/api/getting-started#securing-access-to-sumo-logic-infrastructure-via-dns-name-or-ip-address) for information on how to configure your firewall for outbound access to Sumo Logic.
-
-### Interface considerations
-
-#### Offload Features
-
-Modern network chipsets utilize hardware features to offload work from the host CPU as a performance improvement. Most drivers utilize these features by default These features are often detrimental to the proper functioning of capture interfaces on network sensors.
-
-Verify information about the kernel module (driver) supporting the interface and view offload feature states for the NIC:
-
-```
-ethtool -i eno1
-ethtool -k eno1
-```
-
-A number of NIC offload features should be disabled on capture devices (interfaces that monitor traffic, but not the management interface). An example of interface configuration that disables such features is provided below in [Recommended interface configuration](#recommended-interface-configuration).
-
-#### NIC Hardware Buffer Queue Length
-
-The default size of the ring buffer on many NICs is conservative and in high traffic, scenarios may cause some frames to be dropped before they can be processed.
-
-Verify the ring parameters for the capture interface(s). The following example shows a maximum RX value of 4096, but an effective setting of
-256.
-
-**Input ring buffer queue length**
-
-```
-$ ethtool -g eno1
-Ring parameters for eno1:
-Pre-set maximums:
-RX: 4096
-RX Mini: 0
-RX Jumbo: 0
-TX: 4096
-Current hardware settings:
-RX: 256
-RX Mini: 0
-RX Jumbo: 0
-TX: 256
-```
-
-An example interface configuration which increases the RX ring buffer size is provided below.
-
-#### Recommended interface configuration
-
-The following stanza can be set as an *interface (5)* configuration in Debian or Ubuntu Linux sensors. Most often the file path is `/etc/network/interfaces` (some installations may use a file in `/etc/network/interfaces.d/`). These settings configure the network interface for optimized traffic capture as described above. Similar concepts apply to Red Hat-based distributions using interface setup configurations provided by the distribution.
-
-**/etc/network/interfaces (Debian/Ubuntu)**
-
-```
-iface eno1 inet manual
- # Increase MTU if required for jumbo frames, VLAN tags, etc.
- mtu 1500
- pre-up /sbin/ethtool -G $IFACE rx 4096 tx 0
- pre-up /sbin/ethtool -K $IFACE gro off gso off lro off rx off sg off tso off tx off ufo off
- pre-up /sbin/ethtool -A $IFACE rx off autoneg off
- up ip link set $IFACE arp off allmulticast on
- down ip link set $IFACE down
- post-down /sbin/ethtool -G $IFACE rx 256 tx 256
- post-down /sbin/ethtool -K $IFACE gro on gso on lro on rx on sg on tso on tx on ufo on
- post-down /sbin/ethtool -A $IFACE rx on autoneg on
-```
-
-The section below describes the settings configured above.
-
-#### Interface settings
-
-Link settings
-
-* `arp off` = disable ARP resolution on the interface. The only traffic forwarded to the interface will be a feed from the monitored network segment.
-* `allmulticast on` = enable IFF_ALLMULTI. The driver forwards all multicast packets to the kernel for handling.
-
-`-G`
-
-* `rx` = ring entries for Rx; NIC hardware buffer queue length
-* `tx` = Tx queue; transmission is not utilized on capture interfaces
-
-`-K`
-
-* `rx` = rx-checksumming; Receive checksumming
-* `tx` = tx-checksumming; Transmit checksumming
-* `sg` = scatter-gather
-* `tso` = tcp-segmentation-offload; TCP segmentation offload
-* `ufo` = udp-fragmentation-offload; UDP fragmentation offload
-* `gso` = generic-segmentation-offload; generic segmentation offload
-* `gro` = generic-receive-offload; generic receive offload
-* `lro` = large-receive-offload; large receive offload
-
-`-A`
-
-* `rx` = Rx pause frames; flow control
-* `autoneg` = autonegotiation pause frames
-
-## Install the Network Sensor
-
-Download the installer using the download link for your deployment shown on [Sensor Download Locations](/docs/cse/sensors/sensor-download-locations/). Start the installer using the command provided on that page, and then respond to the prompts as described below.
-
-## Uninstall the Network Sensor
-
-1. Before uninstalling the Network Sensor, make sure that the service is stopped: `sudo service trident_sensor stop`
-1. To remove the package:
-
- * On Ubuntu, using `dpkg`: `sudo dpkg -r trident-sensor`
- * On Ubuntu, using `apt` (removes dependencies): `sudo apt remove trident-sensor`
- * On Centos: `sudo yum remove trident-sensor`
-
-1. Remove remaining configuration and log files: `sudo rm -rf /opt/trident/sensor`
-
-## Network Sensor configuration settings
-
-This section describes the configuration options in the Network Sensor configuration file, ` /opt/trident/sensor/conf/trident-sensor.cfg`.
-
-We strongly recommend that you do not edit trident-sensor.cfg manually. Instead, you should run `/opt/trident/sensor/bin/configure.sh`, which is
-the wizard that runs when you install a Network Sensor. For some configuration options, the wizard updates both `/opt/trident/sensor/conf/trident-sensor.cfg` and `node.cfg`.
-
-If you do make manual updates to `trident-sensor.cfg`, you must restart the Network Sensor for the changes to take effect with this command:
-
-`sudo service trident_sensor restart`
-
-### compression
-
-**Description.** This option controls whether the sensor compresses the Bro output files stored in ` /opt/trident/sensor/output/`. By default, the sensor does compress the Bro files using gzip when the size of the Bro file exceeds the value of the `compression_threshold` option, described below. To turn compression off, set this option to “no”, or any value other than “gzip”. Compression occurs when the parameter is missing or set to gzip and the Bro output file is above the value set in `compression_threshold`.
-
-**Default Value.** gzip
-
-**Configured by wizard?** No
-
-### compression_threshold
-
-**Description.** Minimum file size for compression.
-
-**Default Value.** 50kB
-
-**Configured by wizard?** No
-
-### debug
-
-**Description.** The sensor writes messages about the upload process, that is, the process of uploading captured data to Sumo Logic. By default, this log file is `/opt/trident/sensor/logs/trident-shipper.log`. You can use the debug option to tell the sensor to write debug-level to the log file.
-
-**Default Value**. false
-
-**Configured by wizard?** No
-
-### extracted_file_directory
-
-Description. The directory to which the sensor writes files extracted from network traffic, in accordance with the `extracted_file_types` option.
-
-**Default Value.** `/opt/trident/sensor/output/extract_files`
-
-**Configured by wizard?** No
-
-### extracted_file_types
-
-**Description.** In the case that the sensor detects files in network traffic, this option controls what files the sensor will extract. Files that have the MIME types specified in this parameter will be extracted.
-
-
-**Default Value.**
-`application/x-dosexec,application/x-msdownload,application/zip,application/x-msdos-program`
-
-**Configured by wizard?** No
-
-### file_carving_enabled
-
-**Description.** Enables the sensor’s file extraction functionality, the extraction of files detected in network traffic, in accordance with the `extracted_file_types` option. Set to “false” to disable file extraction.
-
-**Default Value.** true
-
-**Configured by wizard?** no
-
-### filter
-
-**Description.** This option tells Bro not to capture network traffic between the sensor and the Sumo Logic. The sensor sends status reports and Bro output files to end points on the destination, which we don’t want Bro to capture.
-
-This option is populated when first you install the sensor, or when you reconfigure it by running `/opt/trident/sensor/bin/configure.sh. `
-
-**Default Value.** none
-
-**Configured by wizard?** No. The wizard does not prompt for this value, instead it determines the value based on the Sumo Logic HTTP Source URL you supply to the wizard.
-
-### input_directory
-
-**Description.** The directory which Bro log files will be written.
-
-**Default Value**. `/opt/trident/sensor/output`
-
-Configured by wizard? No
-
-### installation_directory
-
-**Description**. Directory where the sensor is installed; this is used for auto updating.
-
-**Default Value.** `/opt/trident/sensor`
-
-**Configured by wizard?** No
-
-### log_file
-
-**Description.** The log file that contains messages written by the process that sends the collected data to Sumo Logic.
-
-**Default Value**.` /opt/trident/sensor/logs/trident-shipper.log`
-
-**Configured by wizard?** The wizard does not prompt for this value, instead it determines the value based on the Sumo Logic HTTP Source URL you supply to the wizard.
-
-### maximum_extracted_file_size
-
-**Description.** The maximum size (in bytes) below which files will be extracted.
-
-**Default Value**. 10485760
-
-**Configured by wizard?** No
-
-### no_data_cutoff
-
-**Description.** Threshold used to determine when data is being captured by the Network Sensor (value is in records per second). When records per second is below this threshold for a status report interval (default is 5 minutes) the report will be counted towards [no_data_restart_threshold](#no_data_restart_threshold). Use this parameter to tune automatic restarts of the Network Sensor when no data is being captured/reported (requires `no_data_restart_threshold` to be set, the recommended value for this parameter is 3, as described below ).
-
-**Default value.** 3
-
-**Configured by wizard?** No
-
-### no_data_restart_threshold
-
-**Description.** Number of consecutive status reports with no data that should trigger a restart of the Network Sensor. This may be enabled to handle Zeek out-of-memory issues that causes capturing to stop occasionally. Recommended number to start with is 3 (a single status report with no data is normal).
-
-**Default value.** -1 (disabled)
-
-**Configured by wizard?** No
-
-### proxy_https
-
-**Description**. Whether or not the configured proxy is using SSL.
-
-**Default Value**. true
-
-**Configured by wizard?** Yes
-
-### proxy
-
-**Description.** The hostname and port of of the proxy server, required if `proxy_required` is set to true,
-
-**Default Value**. None
-
-**Configured by wizard?** No
-
-### proxy_auth_required
-
-**Description.** If a proxy is used, is authentication required?
-
-**Default Value.** false
-
-**Configured by wizard?** yes
-
-### proxy_password
-
-**Description.** Password to use when authenticating to the proxy; required if `proxy_auth_required` is set to true; note: do not edit the config file directly to change this, change it by re-running the configuration wizard.
-
-**Default Value**. None
-
-**Configured by wizard?** No
-
-### proxy_required
-
-**Description.** Whether or not a proxy is required to access the internet.
-
-**Default Value.** false
-
-**Configured by wizard?** yes
-
-### proxy_user
-
-**Description.** Username to use when authenticating to the proxy; required if `proxy_auth_required` is set to “true”.
-
-**Default Value.** No.
-
-**Configured by wizard?** Yes
-
-### sensor_id
-
-**Description.** Random uuid.
-
-**Default Value.** None.
-
-**Configured by wizard?** No, set automatically during installation.
-
-### sensor_iface
-
-**Description.** Interface on which bro will listen.
-
-**Default Value.** None
-
-**Configured by wizard?** Yes
-
-### sensor_name
-
-**Description.** The hostname of the system on which the sensor is installed.
-
-**Default Value.** None
-
-**Configured by wizard?** No, the wizard does not prompt for this value, it is set during installation. You can manually change it later if desired.
-
-### set_source_category
-
-**Description.** When this option is set to "true", the value of the `_sourceCategory` metadata field assigned to the data collected by the sensor is `cse/network/
`. If you set the option to "false", the `_sourceCategory` value will be the same as the `_sourceCategory` assigned the Sumo Logic collector.
-
-**Default Value**. true
-
-**Configured by wizard?** No, the wizard does not prompt for this value, it is set during installation. You can manually change it later if desired.
-
-### shipper_threads
-
-**Description.** The number of threads the process that sends the collected data to Sumo Logic will use to send files concurrently; setting this higher than 8 will have no impact.
-
-**Default Value.** Varies from 3 to 8; set dynamically based on the number of available CPUs.
-
-**Configured by wizard?** No
-
-### skipped_log_types
-
-**Description.** This option controls which log files are discarded and not uploaded by the sensor. (For a list of log files generated by Zeek, see [Log Files](https://docs.zeek.org/en/master/script-reference/log-files.html)).
-
-**Example**. To filter discard `ntp.log`, add the following parameter to `trident-sensor.cfg`:
-
-`skipped_log_types = dpd,weird,syslog,pe,tunnel,communication,conn-summary,known_hosts,software,stdout.stderr,loaded_scripts,ntp`
-
-**Default Value.**
-
-`dpd,weird,syslog,pe,tunnel,communication,conn-summary,known_hosts,software,stdout.stderr,loaded_scripts`
-
-### status_interval
-
-**Description.** The time interval (in seconds) at which the sensor status report will be sent; setting this to less than 60 seconds will have no impact.
-
-**Default Value.** 300
-
-**Configured by wizard?** No
-
-### version
-
-**Description.** Obsolete. Older sensor installations will have option, but it's not used in newer sensors.
-
-**Default Value.** None
-
-**Configured by wizard?** No
-
-### zip_password_protected_only
-
-**Description**. If application/zip files are extracted, should only password-protected zip files be kept (uploaded to the cluster)?
-
-**Default Value.** true
-
-**Configured by wizard?** no
-
-## Sample configuration files
-
-This section contains examples of the `trident-sensor.cfg` and `node.cfg` files.
-
-### Sensor configured to use a single worker
-
-This sample` /opt/trident/sensor/conf/trident-sensor.cfg` file specifies the use of a single worker.
-
-```
-log_file = /opt/trident/sensor/logs/trident-shipper.log
-input_directory = /opt/trident/sensor/output
-sensor_name = pontoon-ubuntu1804
-sensor_id = c4b6e2c7-d696-444a-9803-398cd9407fc4
-sensor_zone = default
-sensor_iface = enp0s3
-extracted_file_directory = /opt/trident/sensor/output/extract_files
-maximum_extracted_file_size = 10485760
-proxy_required = false
-proxy_https = true
-proxy_auth_required = false
-extracted_file_types = application/x-dosexec,application/x-msdownload,application/zip,application/x-msdos-program
-zip_password_protected_only = true
-status_interval = 300
-compression = gzip
-sumo_http_source_url = https://example.sumologic.com/receive..._and_numbers__
-cluster_config_file = /opt/trident/sensor/bro/etc/node.cfg
-filter = not ( host example.sumologic.com )
-cluster = true
-workers = 1
-```
-
-### Sensor configured to use four workers
-
-This sample `/opt/trident/sensor/conf/trident-sensor.cfg` file specifies
-the use of four workers.
-
-```
-log_file = /opt/trident/sensor/logs/trident-shipper.log
-input_directory = /opt/trident/sensor/output
-sensor_name = demo-sensor
-sensor_id = 99b63729-007v-038u-8t42-51dikn72j7g
-sensor_iface = eth0
-extracted_file_directory = /opt/trident/sensor/output/extract_files
-maximum_extracted_file_size = 10485760
-proxy_required = false
-proxy_auth_required = false
-extracted_file_types = application/x-dosexec,application/x-msdownload,application/zip,application/x-msdos-program
-zip_password_protected_only = true
-status_interval = 300
-sumo_http_source_url = https://example.sumologic.com/receive..._and_numbers__
-filter = not ( host example.sumologic.com )
-cluster = true
-workers = 4
-cluster_config_file = /opt/trident/sensor/bro/etc/node.cfg
-```
-
-### Sample node.cfg file (cluster configuration file)
-
-The `/opt/trident/sensor/bro/etc/node.cfg` file is automatically generated, based on the choices you make when running the configuration wizard at installation time.
-
-Typically you should not edit `node.cfg` without consulting Cloud SIEM support. Under some circumstances, edits may be necessary, for example, if you want to monitor more than one capture interface.
-
-If you do make manual updates to `node.cfg`, you must restart the Network Sensor for the changes to take effect with this command:
-`sudo service trident_sensor restart`
-
-```
-[manager]
-type=manager
-host=127.0.0.1
-
-[proxy-0]
-type=proxy
-host=127.0.0.1
-
-[worker-0]
-type=worker
-host=127.0.0.1
-interface=eth0
-lb_method=pf_ring
-lb_procs=1 # this can be changed to have multiple cores dedicated to it
-
-[worker-1]
-type=worker
-host=127.0.0.1
-interface=eth1
-lb_method=pf_ring
-lb_procs=1 # this can be changed to have multiple cores dedicated to it
-
-[worker-2]
-type=worker
-host=127.0.0.1
-interface=eth2
-lb_method=pf_ring
-lb_procs=1 # this can be changed to have multiple cores dedicated to it
-
-[worker-3]
-type=worker
-host=127.0.0.1
-interface=eth3
-lb_method=pf_ring
-lb_procs=1 # this can be changed to have multiple cores dedicated to it
-```
-
-## Useful Linux commands
-
-This section contains Linux command for working with the sensor and its configuration files.
-
-```
-# Restart sensor
-$ systemctl restart trident_sensor
-
-# Sensor status
-$ systemctl status trident_sensor
-
-# Standard Performance check 1
-$ top
-
-# Bro Control Access
-$ sudo /opt/trident/sensor/bro/bin/broctl # then you can run `help` to see all commands
-
-# View Trident Config
-$ cat /opt/trident/sensor/conf/trident-sensor.cfg
-
-# Edit Trident Config
-$ vi /opt/trident/sensor/conf/trident-sensor.cfg
-
-# View Node Config
-$ cat /opt/trident/sensor/bro/etc/node.cfg
-
-# Edit Node Config
-$ vi /opt/trident/sensor/bro/etc/node.cfg
-
-# View Logs
-$ tail -f /opt/trident/sensor/logs/trident-sensor.log
-
-# View Data Flow Logs
-$ tail -f /opt/trident/sensor/logs/trident-shipper.log
-
-# View Outputs
-$ ls -lh /opt/trident/sensor/output/
-
-# TCPDump to verify the monitoring interface is seeing traffic
-$ sudo tcpdump -c 20 -i <> Or $ sudo tcpdump -c 20 -i <> port 80
-```
-
-## Troubleshooting
-
-### Interface status
-
-If an Ubuntu VM (possibly other Linux distributions) does not show both interfaces (one for traffic monitoring and one for management) that have been assigned when using the `ifconfig` command, but does show both interfaces when running an `ip link show` then the second interface is not currently in an UP state.
-
-You can temporarily put the interface in the UP state, using the following command:
-
-`$ ip link set\<> up`
-
-To make the UP state persist through a reboot or service restart, edit the `/etc/network/interfaces` file with your choice of editor. Remember to use sudo. Add the following line to this file:
-
-`auto\<>`
-
-After you save this file, clear any existing IPs from the interface by running:
-
-`$ sudo ip addr flush\<>`
-
-### Troubleshoot Bro/Zeek
-
-Diagnose issues with Bro/Zeek using the following command:
-
-`/opt/trident/sensor/bro/bin/broctl diag`
-
-The output of this command shows any fatal errors observed when one or more workers crashed.
-
-There’s also a `crash-diagscript` you can run for the node that had an issue (The output below is from intentionally crashing Bro worker-0-1 node with an invalid pcap filter):
-
-```
-[root@localhost ~]# /opt/trident/sensor/bro/share/broctl/scripts/crash-diag /opt/trident/sensor/output/worker-0-1/
-
-No core file found.
-
-Bro 2.6-255
-Linux 3.10.0-1062.18.1.el7.x86_64
-
-Bro plugins: (none found)
-
-==== No reporter.log
-
-==== stderr.log
-warning in /opt/trident/sensor/output/installed-scripts-do-not-touch/site/osdetect.bro, line 24: deprecated (bro_init)
-warning in /opt/trident/sensor/output/installed-scripts-do-not-touch/site/exploit-kit.bro, line 14: Use of deprecated attribute: &synchronized
-warning in /opt/trident/sensor/output/installed-scripts-do-not-touch/site/exploit-kit.bro, line 14: Use of deprecated attribute: &mergeable
-warning in /opt/trident/sensor/output/installed-scripts-do-not-touch/site/ja3.bro, line 59: deprecated (bro_init)
-warning in /opt/trident/sensor/output/installed-scripts-do-not-touch/site/ja3s.zeek, line 41: deprecated (bro_init)
-listening on enp0s3
-
-fatal error in /opt/trident/sensor/bro/share/bro/base/frameworks/packet-filter/./main.zeek, line 282: Bad pcap filter 'not ( host https://localhost ) and not ( dst port 514 )'
-
-==== stdout.log
-max memory size (kbytes, -m) unlimited
-data seg size (kbytes, -d) unlimited
-virtual memory (kbytes, -v) unlimited
-core file size (blocks, -c) unlimited
-
-==== .cmdline
--i enp0s3 -U .status -p broctl -p broctl-live -p local -p worker-0-1 trident-sensor.bro broctl base/frameworks/cluster broctl/auto -C
-
-==== .env_vars
-PATH=/opt/trident/sensor/bro/bin:/opt/trident/sensor/bro/share/broctl/scripts:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
-BROPATH=/opt/trident/sensor/output/installed-scripts-do-not-touch/site::/opt/trident/sensor/output/installed-scripts-do-not-touch/auto:/opt/trident/sensor/bro/share/bro:/opt/trident/sensor/bro/share/bro/policy:/opt/trident/sensor/bro/share/bro/site
-CLUSTER_NODE=worker-0-1
-
-==== .status
-TERMINATED [atexit]
-
-==== No prof.log
-
-==== No packet_filter.log
-
-==== No loaded_scripts.log
-[root@localhost ~]#
-```
diff --git a/docs/cse/sensors/network-sensor-end-of-life.md b/docs/cse/sensors/network-sensor-end-of-life.md
index 1508f1407e..106ca56c17 100644
--- a/docs/cse/sensors/network-sensor-end-of-life.md
+++ b/docs/cse/sensors/network-sensor-end-of-life.md
@@ -14,7 +14,7 @@ At Sumo Logic, we pride ourselves on being a leading SaaS log analytics company
We’re always looking at ways to innovate, drive more value, and provide a seamless experience for our customers. In this vein we are discontinuing our on-premise network sensor feature for Sumo Logic Cloud SIEM. This end-of-life notification for Sumo Logic's network sensor means the feature will no longer receive support or updates based on the timelines listed below. We believe this to be the best course of action to keep our development focus on delivering world class detection and response capabilities.
-We fully recognize that this decision may have implications for your business operations, and we are committed to planning with you and your security team to minimize disruptions. We fully support a customer or partner managed [Zeek network sensor](/docs/cse/sensors/ingest-zeek-logs/) as a data source for our Cloud SIEM product that will provide equivalent monitoring of your network.
+We fully recognize that this decision may have implications for your business operations, and we are committed to planning with you and your security team to minimize disruptions. We fully support a customer or partner managed [Zeek network sensor](/docs/cse/ingestion/ingestion-sources-for-cloud-siem/corelight-zeek/) as a data source for our Cloud SIEM product that will provide equivalent monitoring of your network.
We're confident that our highly scalable, cloud-native security solutions can continue to support your security operations. Let's discuss how we can help you achieve your security goals.
diff --git a/docs/cse/sensors/network-sensor-troubleshooting.md b/docs/cse/sensors/network-sensor-troubleshooting.md
deleted file mode 100644
index 0ab46b9f12..0000000000
--- a/docs/cse/sensors/network-sensor-troubleshooting.md
+++ /dev/null
@@ -1,196 +0,0 @@
----
-id: network-sensor-troubleshooting
-title: Network Sensor Troubleshooting
-description: Learn how to troubleshoot problems with the Cloud SIEM Network Sensor.
----
-
-import useBaseUrl from '@docusaurus/useBaseUrl';
-import SensorEOL from '../../reuse/cloud-siem-network-sensor-eol.md';
-
-:::warning end-of-life
-
-:::
-
-The Cloud SIEM Network Sensor is a flexible network security monitor that monitors IP networks and collects flow and protocol session data, building audit records of network communications. As with all Network Sensors, performance is a key consideration for proper operation and comprehensive data collection. The installation of the Cloud SIEM Network Sensor configures the sensor with reasonable defaults for many environments. For other environments, such as high throughput deployments, Sumo Logic advises the use of a supported 3rd party Bro/Zeek sensor offering or a custom Zeek cluster deployment.
-
-## General Troubleshooting
-
-### Interface Errors
-
-Various conditions may cause a network interface to drop frames. Interface counters should be monitored to identify faults.
-
-Errors may be monitored using `ip-link(8)`: `ip -s link show`
-
-Confirm that the RX line shows incrementing bytes/packets but that the `errors`, `dropped` and `overrun` fields do not increment. It is useful to run the command several times with some delay in between.
-
-The following example shows an interface where errors and drops are occurring:
-
-**Interface errors**
-
-```
-$ ip -s link show dev eno1
-2: eno1: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
- link/ether 94:c6:91:1f:60:30 brd ff:ff:ff:ff:ff:ff
- RX: bytes packets errors dropped overrun mcast
- 447245477940 794895966 382828 2308804 0 7956512
- TX: bytes packets errors dropped carrier collsns
- 0 0 0 0 0 0
-```
-
-Additional detailed NIC and driver statistics are available using `ethtool(8)`:
-
-`ethtool -S eno1`
-
-A number of statistics named with “errors” are available. All of them ideally show 0 count and should not be incrementing. Incrementing error counters may be caused by faults discussed (and corrected) below.
-
-### PF_RING
-
-PF_RING enables accelerated network packet capture under Linux and is included in the default Cloud SIEM Network Sensor installation.
-
-PF_RING configuration information is available in `/proc/net/pf_ring/info`. Information on interfaces may be found in `/proc/net/pf_ring/dev//info`.
-
-PF_RING also keeps statistics and information in files such as `/proc/net/pf_ring/27240-ens192.9`, where the leading part of the filename is a PF_RING enabled capture program PID on the system. Among other information in these files are various packet counters.
-
-Further system tuning related to ring buffer parameters and queues may be possible (refer to PF_RING and Bro/Zeek documentation).
-
-It can be helpful to verify that Bro is linked against the PF_RING enabled libpcap library. The following command pipeline will output "PF_RING enabled" if Bro/Zeek is linked against PF_RING enabled drivers, otherwise there will be no output (indicating acceleration is not enabled).
-
-```
-$(ldd /opt/trident/sensor/bro/bin/zeek | awk '{print $3}' | grep libpcap) >/dev/null && echo "PF_RING enabled"
-```
-
-### Network sensor stops capturing traffic
-
-Zeek can get into a state where it runs out of memory and stops processing traffic but does not crash. This has been observed on RHEL 7.9. To automatically restart the sensor when consecutive status reports with low records per second is observed use [no_data_restart_threshold](/docs/cse/sensors/network-sensor-deployment-guide#no_data_restart_threshold) (recommended value 3), and [no_data_cutoff](/docs/cse/sensors/network-sensor-deployment-guide#no_data_cutoff) to tune the record threshold if needed.
-
-## Monitoring Capture Performance
-
-Security monitoring can be complex. Network data capture is a system with many layers, and degradation or faults at one layer can affect the whole. Performance starts at the initial traffic acquisition source (i.e. TAPs, SPANs/port mirrors) and ends with the monitoring software itself (Bro/Zeek). Along the way a number of hardware and software components are involved, such as cabling, capture network interface cards, CPU, memory, drivers, OS kernel, memory buffers, and numerous settings. Some work fine as defaults and others must be tuned correctly. All components must be monitored and validated for proper operation. This document provides an overview of how to properly configure and monitor some of the important components in a Network Sensor deployment.
-
-Sumo Logic recommends that Network Sensor admins monitor and collect performance statistics from deployed sensors. Doing so can help with tracking and spotting faults when they occur and help plan for adequate system resources.
-
-In the examples below, we use `eno1` as the example interface name. Substitute the proper interface name(s) on your sensor as needed.
-
-## Capture Interfaces
-
-Several considerations apply for passive network capture interfaces on an IDS sensor. Capture interfaces are those that are connected to a system supplying a copy of network traffic for monitoring. Network sensors typically have a standard management network interface and one or more additional capture interfaces receiving traffic.
-
-### IP Configuration
-
-Passive capture interfaces should be receive only and need not have an IP configuration. ARP may be disabled and no IP address should be configured on the interface. The monitoring software (i.e. Bro/Zeek in this case) will set the interface to the promiscuous mode when it initializes capture on the interface; this does not have to be done in the interface configuration. To operate correctly, the interface should be in an up/active/enabled state.
-
-A recommended capture interface configuration is provided later in this document.
-
-### Link Negotiation and MTU
-
-Sumo Logic recommends the use of network TAPs where possible over port mirrors/SPANs on switches. Port mirrors operate in software, do not reliably copy all traffic to analyzers, and may be temporarily disabled by the switch when system load increases. Port mirrors are best suited for temporary or short term troubleshooting. TAPs are purpose-built for permanent monitoring applications and deliver a reliable copy of traffic to analyzers. Most TAPs are also designed to fail open, ensuring that they do not impact network functionality even when faulting.
-
-Verify that the link speed and duplex settings between the sensor's capture interface(s) and any connected network devices match and are negotiated correctly on both ends. Modern devices should auto-negotiate link settings correctly in all cases and it is recommended to allow devices to negotiate speed and duplex. Avoid scenarios where one device is set to auto-negotiate but the neighbor is forced to a certain speed/duplex; this results in a mismatch and can result in packet loss or completely dropped frames. Related devices may include any that are supplying traffic to the sensor, including switches, TAPs, link aggregators and flow-based load balancers. It's possible that devices such as splitters and couplers may cause faults with link negotiation. High-quality TAPs or other link aggregators or flow-based load balancers should work reliably.
-
-To check interface link negotiation use `ethtool`:
-
-`ethtool eno1`
-
-The Speed and Duplex fields indicate the active link settings. For a gigabit ethernet link, those are expected to show `1000Mb/s` and `Full`.
-
-MTU (maximum transmission units) is another setting that should match up between connected devices. If all devices use the standard Ethernet MTU size of 1500 bytes, issues are unlikely. If jumbo frames are in use on the network and an upstream device is using a large MTU (e.g. 9000, 9216, etc.), the capture interface MTU should also be adjusted to
-match.
-
-To check the interface MTU:
-
-`ip link show dev eno1`
-
-## Bro/Zeek
-
-Having verified performance of the data delivery path, the next focus area is Bro/Zeek. As with any network intrusion detection system, the primary concern is ensuring that the software is able to keep up with the traffic rate being monitored without dropping packets. One thing to be aware of is that Zeek is capable of reporting on its performance and logs notices relating to observed capture loss rates over a certain threshold.
-
-## CaptureLoss
-
-An important metric Zeek log that is collected from the Cloud SIEM Network Sensor is the notice `CaptureLoss::Too_Much_Loss`. Zeek internally tracks loss rates by observing when streams arrive with gaps indicating missing segments in the stream. Because this metric relates directly to traffic monitored by Zeek, it may either indicate packet loss in Zeek itself, or a loss condition happening elsewhere upstream from Zeek (anywhere along the line). This notice is logged on a periodic basis when a configured threshold is exceeded and is the topic of a key FAQ. https://www.zeek.org/documentation/faq.html#how-can-i-reduce-the-amount-of-captureloss-or-dropped-packets-notice It is possible to analyze occurrences of CaptureLoss notices in Cloud SIEM using the following query in an Sumo Logic log search tab.
-
-`_sourceCategory = "cse/network/notice" | where note = "CaptureLoss::Too_Much_Loss"`
-
-})
-
-### Capstats
-
-Capstats is a utility that can be used to monitor in real-time the capture statistics from a NIC, reporting on throughput rates and NIC drop rates most importantly. For example:
-
-`/opt/trident/sensor/bro/bin/capstats -i eno1 -I 1 -n 10`
-
-### Bro/Zeek
-
-A number of diagnostic commands are implemented in [ZeekControl (zeekctl)](https://github.com/zeek/zeekctl), a utility to control Zeek cluster installations.
-
-**Snaplen**
-
-Report on the configured value of the Pcap::Snaplen variable on all workers:
-
-`/opt/trident/sensor/bro/bin/zeekctl print Pcap::snaplen`
-
-**Status**
-
-Report on the overall cluster status:
-
-`/opt/trident/sensor/bro/bin/zeekctl status`
-
-**Node Report**
-
-Report on the status of nodes in the cluster:
-
-`/opt/trident/sensor/bro/bin/zeekctl nodes`
-
-**Process Overview**
-
-Report on Zeek cluster processes:
-
-`/opt/trident/sensor/bro/bin/zeekctl ps.bro`
-
-**Process Runtime State**
-
-Show a real-time running task view of the cluster:
-
-`/opt/trident/sensor/bro/bin/zeekctl top`
-
-**Cluster Disk Utilization**
-
-Report on disk utilization for the cluster:
-
-`/opt/trident/sensor/bro/bin/zeekctl df`
-
-**Capture Stats**
-
-Run capstats on the cluster:
-
-`/opt/trident/sensor/bro/bin/zeekctl capstats`
-
-**Netstats Report**
-
-`/opt/trident/sensor/bro/bin/zeekctl netstats`
-
-Sample output:
-
-```
-BroControl Netstats Output
-worker-0-1: 1554221834.239908 recvd=16074588 dropped=0 link=16074588
-worker-0-2: 1554221834.439788 recvd=16074086 dropped=0 link=16074086
-worker-0-3: 1554221834.643677 recvd=16075191 dropped=0 link=16075191
-worker-0-4: 1554221834.843662 recvd=16074657 dropped=0 link=16074657
-```
-
-The netstats command may require the installation of the Broccoli module. In Ubuntu Linux, this can be installed as follows:
-
-`apt-get install libbroccoli5 libbroccoli-dev python-broccoli`
-
-**Zeek Diagnostics**
-
-Several diagnostic outputs may be collected.
-
-`/opt/trident/sensor/bro/bin/zeekctl diag`
-
-## References
-
-* https://cromwell-intl.com/open-source/performance-tuning/ethernet.html
-* https://www.zeek.org/documentation/faq.html#capture-loss-without-dropped-packets
-* http://www.draconyx.net/articles/configuring-a-network-monitoring-system-sensor-w-pf_ring-on-ubuntu-server-1-04-part-1-interface-configuration.html
-
diff --git a/docs/cse/sensors/sensor-download-locations.md b/docs/cse/sensors/sensor-download-locations.md
deleted file mode 100644
index fff3cdeae3..0000000000
--- a/docs/cse/sensors/sensor-download-locations.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-id: sensor-download-locations
-title: Sensor Download Locations
-description: The Cloud SIEM Network Sensor can be downloaded from a static URL that is specific to your Cloud SIEM deployment.
----
-
-import useBaseUrl from '@docusaurus/useBaseUrl';
-import SensorEOL from '../../reuse/cloud-siem-network-sensor-eol.md';
-
-:::warning end-of-life
-
-:::
-
-The Cloud SIEM Network Sensor can be downloaded from a static URL that is specific to your Cloud SIEM deployment. Each Sumo Logic deployment has URLs used to download sensor software. If you are not sure which endpoint to use, see How can I determine which endpoint I should use?
-
-## Installing the Network Sensor
-
-After downloading the Network Sensor appropriate for your system architecture, run this command:
-
-```bash
-sudo wget -q -O - | sudo /bin/bash
-```
-
-For information about the installer prompts, see [Network Sensor Deployment Guide](/docs/cse/sensors/network-sensor-deployment-guide).
-
-## Sensor download URLs for the AU region
-
-| Sensor | URL |
-|:-------------------------|:------------------------------------------------------------------|
-| Network Sensor Ubuntu18 | https://collectors.au.sumologic.com/rest/sec/download/ubuntu18 |
-| Network Sensor Ubuntu20 | https://collectors.au.sumologic.com/rest/sec/download/ubuntu20 |
-| Network Sensor CentOS7 | https://collectors.au.sumologic.com/rest/sec/download/centos7 |
-| Network Sensor CentOS8 | https://collectors.au.sumologic.com/rest/sec/download/centos8 |
-
-## Sensor download URLs for the CA region
-
-| Sensor | URL |
-|:-------------------------|:------------------------------------------------------------------|
-| Network Sensor Ubuntu18 | https://collectors.ca.sumologic.com/rest/sec/download/ubuntu18 |
-| Network Sensor Ubuntu20 | https://collectors.ca.sumologic.com/rest/sec/download/ubuntu20 |
-| Network Sensor CentOS7 | https://collectors.ca.sumologic.com/rest/sec/download/centos7 |
-| Network Sensor CentOS8 | https://collectors.ca.sumologic.com/rest/sec/download/centos8 |
-
-## Sensor download URLs for the US2 region
-
-| Sensor | URL |
-|:-------------------------|:-------------------------------------------------------------------|
-| Network Sensor Ubuntu18 | https://collectors.us2.sumologic.com/rest/sec/download/ubuntu18 |
-| Network Sensor Ubuntu20 | https://collectors.us2.sumologic.com/rest/sec/download/ubuntu20 |
-| Network Sensor CentOS7 | https://collectors.us2.sumologic.com/rest/sec/download/centos7 |
-| Network Sensor CentOS8 | https://collectors.us2.sumologic.com/rest/sec/download/centos8 |
diff --git a/docs/reuse/cloud-siem-network-sensor-eol.md b/docs/reuse/cloud-siem-network-sensor-eol.md
deleted file mode 100644
index fe7873258e..0000000000
--- a/docs/reuse/cloud-siem-network-sensor-eol.md
+++ /dev/null
@@ -1 +0,0 @@
-This article describes using the Cloud SIEM Network Sensor. [The Network Sensor has reached its end of life](/docs/cse/sensors/network-sensor-end-of-life/). Instead, use Zeek. For more information, see [Ingest Zeek Logs](/docs/cse/sensors/ingest-zeek-logs/).
\ No newline at end of file
diff --git a/sidebars.ts b/sidebars.ts
index 2f840e1fc2..5122bc3cb1 100644
--- a/sidebars.ts
+++ b/sidebars.ts
@@ -2900,20 +2900,6 @@ integrations: [
'cse/schema/username-and-hostname-normalization',
],
},
- {
- type: 'category',
- label: 'Sensors',
- collapsible: true,
- collapsed: true,
- link: {type: 'doc', id: 'cse/sensors/index'},
- items: [
- 'cse/sensors/ingest-zeek-logs',
- 'cse/sensors/sensor-download-locations',
- 'cse/sensors/network-sensor-deployment-guide',
- 'cse/sensors/network-sensor-troubleshooting',
- 'cse/sensors/log-sensor-troubleshooting',
- ],
- },
{
type: 'category',
label: 'Integrations',
}){kind=icon}
}){kind=icon}
}){kind=icon}