Architecture

If you’re going to deploy Security Onion, you should first decide on what type of deployment you want. This could be anything from a temporary Import installation in a small virtual machine on your personal laptop all the way to a large scalable enterprise deployment consisting of a manager node, multiple search nodes, and lots of forward nodes. This section will discuss what those different deployment types look like from an architecture perspective.

Import

The simplest architecture is an Import node. An import node is a single standalone box that runs just enough components to be able to import pcap files using so-import-pcap or evtx files using so-import-evtx. You can then view those logs in Security Onion Console (SOC).

Evaluation

The next architecture is Evaluation. It’s a little more complicated than Import because it has a network interface dedicated to sniffing live traffic from a TAP or span port. Processes monitor the traffic on that sniffing interface and generate logs. Filebeat collects those logs and sends them directly to Elasticsearch where they are parsed and indexed. Evaluation mode is designed for a quick installation to temporarily test out Security Onion. It is not designed for production usage at all.

Standalone

Standalone is similar to Evaluation in that all components run on one box. However, instead of Filebeat sending logs directly to Elasticsearch, it sends them to Logstash, which sends them to Redis for queuing. A second Logstash pipeline pulls the logs out of Redis and sends them to Elasticsearch, where they are parsed and indexed.

This type of deployment is typically used for testing, labs, POCs, or very low-throughput environments. It’s not as scalable as a distributed deployment.

Distributed

A standard distributed deployment includes a manager node, one or more forward nodes running network sensor components, and one or more search nodes running Elastic search components. This architecture may cost more upfront, but it provides for greater scalability and performance, as you can simply add more nodes to handle more traffic or log sources.

• Recommended deployment type
• Consists of a manager node, one or more forward nodes, and one or more search nodes

Note

If you install a dedicated manager node, you must also deploy one or more search nodes. Otherwise, all logs will queue on the manager and have no place to be stored. If you are limited on the number of nodes you can deploy, you can install a manager search node so that your manager node can act as a search node and store those logs. However, please keep in mind that overall performance and scalability of a manager search node will be lower compared to our recommended architecture of dedicated manager node and separate search nodes.

There is also an option to have a manager node and one or more heavy nodes.

Warning

Heavy nodes are NOT recommended for most users due to performance reasons, and should only be used for testing purposes or in low-throughput environments.

• Recommended only if a standard distributed deployment is not possible
• Consists of a manager node and one or more heavy nodes

Note

Heavy nodes do not consume from the Redis queue on the manager. This means that if you just have a manager and heavy nodes, then the Redis queue on the manager will grow and never be drained. To avoid this, you have two options. If you are starting a new deployment, you can make your manager a manager search so that it will drain its own Redis queue. Alternatively, if you have an existing deployment with a manager and want to avoid rebuilding, then you can add a separate search node (NOT heavy node) to consume from the Redis queue on the manager.

Node Types

Management

The manager node runs Security Onion Console (SOC) and Kibana. It has its own local instance of Elasticsearch, but that’s mainly used for storing Cases data and central configuration. An analyst connects to the manager node from a client workstation (perhaps an Analyst VM) to execute queries and retrieve data. Please keep in mind that a dedicated manager node requires separate search nodes.

The manager node runs the following components:

• Security Onion Console (SOC)
• Elasticsearch
• Logstash
• Kibana
• Curator
• ElastAlert
• Redis
• Wazuh

Search Node

Search nodes pull logs from the Redis queue on the manager node and then parse and index those logs. When a user queries the manager node, the manager node then queries the search nodes, and they return search results.

Security Onion can add search nodes using cross cluster search where each search node is independent or using traditional Elastic clustering where all search nodes join to form a single cluster.

Search Nodes run the following components:

• Elasticsearch
• Logstash
• Curator
• Wazuh

Manager Search

A manager search node is both a manager node and a search node at the same time. Since it is parsing, indexing, and searching data, it has higher hardware requirements than a normal manager node.

A manager search node runs the following components:

• Security Onion Console (SOC)
• Elasticsearch
• Logstash
• Kibana
• Curator
• ElastAlert
• Redis
• Wazuh

Forward Node

A forward node is a sensor that forwards all logs via Filebeat to Logstash on the manager node, where they are stored in Elasticsearch on the manager node or a search node (if the manager node has been configured to use a search node).

Forward nodes run the following components:

• Zeek
• Suricata
• Stenographer
• Wazuh

Heavy Node

Warning

Heavy nodes are NOT recommended for most users.

Heavy nodes perform sensor duties and store their own logs in their own local Elasticsearch instance. This results in higher hardware requirements and lower performance. Heavy nodes do NOT pull logs from the redis queue on the manager like search nodes do.

Heavy Nodes run the following components:

• Elasticsearch
• Logstash
• Curator
• Zeek
• Suricata
• Stenographer
• Wazuh

Fleet Standalone Node

A FleetDM Standalone Node is ideal when there are a large amount of osquery endpoints deployed. It reduces the amount of overhead on the manager node by transferring the workload associated with managing osquery endpoints to a dedicated system. It is also useful for off-network osquery endpoints that do not have remote access to the Manager node as it can be deployed to the DMZ and TCP/8090 made accessible to your off-network osquery endpoints.

If the Manager Node was originally setup with FleetDM, your grid will automatically switch over to using the FleetDM Standalone Node instead as a grid can only have one FleetDM instance active at a time.

FleetDM Standalone Nodes run the following components:

• FleetDM

Receiver Node

Security Onion includes a Receiver Node option. The Receiver Node runs Logstash and Redis and allows for events to continue to be processed by search nodes in the event the manager node is offline. When a receiver node joins the grid, Filebeat on all nodes adds this new address as a load balanced Logstash output. The search nodes add this new node as another Logstash input. Receiver nodes are “active-active” and you can add as many as you want (within reason) and events will be balanced among them.

Intrusion Detection Honeypot (IDH) Node

Security Onion includes an Intrusion Detection Honeypot Node option. This allows you to build a node that mimics common services such as HTTP, FTP, and SSH. Any interaction with these fake services will automatically result in an alert.