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 Evaluation 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.
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 a pcap using so-import-pcap. When you run so-import-pcap, it analyzes the pcap using Suricata and Zeek and the resulting logs are picked up by Filebeat and sent to Elasticsearch where they are parsed and indexed. You can then view those logs in Security Onion Console (SOC).
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 quick installations to temporarily test out Security Onion. It is not designed for production usage at all.
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.
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
There is the option to utilize only two node types – the manager node and one or more heavy nodes, however, this is not recommended due to performance reasons, and should only be used for testing purposes or in low-throughput environments.
Heavy nodes are NOT recommended for most users.
- Recommended only if a standard distributed deployment is not possible
- Consists of a manager node and one or more heavy nodes
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 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.
manager node runs its own local copy of Elasticsearch, which manages cross-cluster search configuration for the deployment. This includes configuration for heavy nodes and search nodes (where applicable), but not forward nodes (since they do not run Elasticsearch). An analyst connects to the manager node from a client workstation (typically a Security Onion virtual machine installation) to execute queries and retrieve data.
The manager node runs the following components:
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). From there, the data can be queried through the use of cross-cluster search.
Forward Nodes run the following components:
When using a
search node, Security Onion implements distributed deployments using Elasticsearch’s cross cluster search. When you run Setup and choose
Search Node, it will create a local Elasticsearch instance and then configure the manager node to query that instance. This is done by updating _cluster/settings on the manager node so that it will query the local Elasticsearch instance.
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 storage nodes, and they return search results.
Search Nodes run the following components:
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:
Heavy nodes are NOT recommended for most users.
Similar to search nodes, heavy nodes extend the storage and processing capabilities of the manager node. However, heavy nodes also perform sensor duties and thus have lower performance overall.
Heavy Nodes run the following components:
Fleet Standalone Node¶
A Fleet 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.
Fleet Standalone Nodes run the following components: