Architecture for cloud Elastic Integration

[kspringer-maf]

Version

2.4.140

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Distributed

Location

on-prem with Internet access

Hardware Specs

Exceeds minimum requirements

CPU

Lots

RAM

Lots

Storage for /

Lots

Storage for /nsm

Lots

Network Traffic Collection

other (please provide detail below)

Network Traffic Speeds

1Gbps to 10Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

I need advice on adding the BitDefender integration. I've read through the instructions and I will have to expose a grid device on the DMZ to accept incoming logs from Bitdefender. My question is, can that be a 'Receiver' node or does it have to be the 'Manager'? Better yet would be a 'Sensor', but I'm not sure if that would even work. Can someone please advise the proper architecture for cloud integrations?

References:
Elastic integration.
https://www.elastic.co/guide/en/integrations/current/bitdefender.html
Bitdefender instructions about ports and DMZ IP access.
https://www.bitdefender.com/business/support/en/77209-135319-setpusheventsettings.html
SO basic instructions.
https://docs.securityonion.net/en/2.4/third-party-integrations.html#managing-third-party-integration-index-templates

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[kspringer-maf]

Grok's response:

To integrate Bitdefender with your Security Onion 2.4 distributed grid system, you’re looking to push events from Bitdefender GravityZone (likely via its Push Events API) into Security Onion for processing, storage, and analysis. The question of which node type—Receiver, Manager, or Sensor—should act as the "listening device" exposed on the DMZ requires careful consideration of Security Onion’s architecture, the integration mechanics, and security best practices. Let’s break this down and provide a clear recommendation, while also considering future cloud integrations.

Security Onion Distributed Grid Basics
In a Security Onion distributed deployment:

Manager Node: The central hub that coordinates the grid, runs services like Logstash and Redis (for event ingestion), hosts the Security Onion Console (SOC), and aggregates data from other nodes. It’s typically not designed to be exposed externally due to its critical role.
Receiver Node: A lightweight node running Logstash and Redis, designed to ingest events from Elastic Agents or other sources and forward them to Search Nodes via Redis queues. Receivers are built for load balancing and redundancy in event ingestion.
Sensor Node: Focused on network monitoring (e.g., Suricata, Zeek, Stenographer), capturing packets, and generating metadata. Sensors don’t inherently ingest external events like API pushes—they’re more about analyzing traffic mirrored from a TAP or SPAN port.
Search Node: Stores and indexes data in Elasticsearch, queried by the Manager for analysis. Not typically involved in ingestion directly.
Bitdefender’s integration involves pushing events (e.g., JSON-formatted logs) over HTTPS to a listening endpoint, which in this case will be a Security Onion node running Logstash to accept and process those events.

Integration Requirements
From the references you provided:

Bitdefender Push Events: You’ll configure GravityZone to send events to an HTTPS endpoint (default port 443, customizable per the Bitdefender docs). This requires the listening device to have a public-facing IP (or DMZ access) and a valid SSL certificate.
Elastic Integration Guide: Suggests using Logstash to receive events, with a sample pipeline to parse Bitdefender JSON data and send it to Elasticsearch.
Security Onion Third-Party Integration: Recommends using Logstash on the Manager or a Receiver to ingest third-party data, with custom index templates managed via SOC.
Given this, the listening device must run Logstash and be reachable from the Bitdefender cloud service.

Can It Be a Receiver Node?
Yes, a Receiver Node is a viable and recommended choice for this integration:

Why It Works: Receiver Nodes run Logstash and Redis, making them purpose-built for ingesting external events and distributing them to Search Nodes. They’re designed to handle incoming data pipelines, which aligns perfectly with Bitdefender’s push-based event delivery.
DMZ Suitability: Exposing a Receiver on the DMZ isolates the ingestion point from the Manager, reducing risk to the central system. Receivers are less critical to the grid’s overall operation, so if compromised, the impact is contained.
Scalability: Receivers operate in an “active-active” configuration, allowing you to add more for load balancing as you integrate additional cloud services (e.g., other third-party tools pushing events).
Setup Steps:

Deploy a Receiver Node (or repurpose an existing one) in the DMZ.
Configure its management interface to communicate internally with the Manager and Search Nodes (via a private network or VPN).
Assign a DMZ IP and open port 443 (or your chosen port) for HTTPS traffic from Bitdefender.
Install a valid SSL certificate on the Receiver for secure communication.
Configure a Logstash pipeline on the Receiver (based on the Elastic Bitdefender integration example) to accept HTTPS input, parse JSON events, and output to Redis for Search Node indexing.
Update Security Onion’s index templates via SOC to handle Bitdefender event fields (e.g., bitdefender-* indices).
Does It Have to Be the Manager?
No, it doesn’t have to be the Manager, and it’s generally not recommended:

Why It’s Possible: The Manager runs Logstash and Redis by default, so it could technically listen for Bitdefender events. The third-party integration docs suggest this as an option for simpler setups.
Why It’s Risky: Exposing the Manager to the DMZ puts the entire grid at risk. The Manager is the brain of the operation—handling configuration, SOC access, and data aggregation. A breach here could compromise the whole system.
When to Consider: Only if you have a very small deployment (e.g., a standalone or minimal distributed setup) where adding a Receiver isn’t feasible. Even then, use strict firewall rules and a reverse proxy to shield it.
Could It Be a Sensor?
Not practically, no:

Why It Doesn’t Fit: Sensor Nodes are optimized for network traffic analysis (e.g., packet capture, IDS/IPS), not for running Logstash to ingest external API events. They don’t natively support the ingestion pipeline needed for Bitdefender’s push events.
Workaround: You could theoretically install Logstash on a Sensor and configure it to listen, but this deviates from Security Onion’s intended architecture. It would also strain the Sensor’s resources, which are typically dedicated to packet processing.
Recommendation: Avoid this unless you’re in a lab environment testing a highly constrained setup. It’s not scalable or supported out of the box.

[reyesj2]

Elastic agent integrations can be used on any deployed agent.

So if you place a receiver node or standalone fleet node in your DMZ, you could configure the relevant fleet policy to use the integration you want. Then any agents in that policy would ingest the integration logs and forward to manager/receivers for ingest into Elasticsearch.

[kspringer-maf]

So if I understand your response correctly, I can expose my 'Receiver' required ports to the DMZ per the BitDefender integration instructions, choose the Elastic Policy to apply the integration to, setup the API configs per the instructions, and then have the BitDefender cloud send the data? Is there an additional Security Onion internal firewall step that I'm missing, or does adding the Integration magically start listening on the desired port? These integrations don't seem to be very well documented as far as all the specific things that need adjusted in SO.

[kspringer-maf]

I'll be using similar instructions that I got working for another integration.
#14310 (comment)

[kspringer-maf]

I've got a port opened up to my Receiver, whitelisted the BD IP's, and have configure the BitDefender Elastic integration per the instructions with the BD api key and Company ID. Although I have what I think is supposed to be active and running, I don't see any BD events. Has anyone got this working before? I must be missing a step somewhere.
@brazorfajeje was asking about this in another discussion post. Did you get it working?

[kspringer-maf]

I've got the Bitdefender integration working. It was "easy" once I figured out each required piece, but very specific in each step that needed completed. I ended up writing my own How-To.