Building network and host monitoring from separate open source tools takes months of integration work, and many teams stall before analysts see a single useful alert. Security Onion packages network sensors, host telemetry, packet capture, search and case management into one platform, described by its maintainers as "a free and open platform built by defenders for defenders". This guide explains what it bundles, how its standalone and distributed architectures differ, how to size and deploy it safely, what its Elastic License 2.0 terms mean, and how it supports threat hunting and incident response. It is written for SOC leads, detection engineers and security architects evaluating or running the platform, and it is based on the official Security Onion 2.4 documentation.
Key takeaways
- One platform, many engines: Suricata, Zeek, Stenographer packet capture, Strelka file analysis, Elastic Agent, osquery and Elasticsearch sit behind a single console with Alerts, Hunt, Dashboards, PCAP and Cases.
- Distributed is the production design: standalone suits labs and very low throughput; production grids separate manager, search and sensor nodes and scale by adding nodes.
- Size sensors by traffic, not by minimums: plan about 200 Mbps per Suricata or Zeek worker and budget disk for packet capture, which runs to hundreds of gigabytes a day on modest links.
- Read the licence before you build a service: Security Onion and Elastic components use the Elastic License 2.0, which prohibits offering the software to third parties as a hosted or managed service.
- Tuning is continuous: NIDS, Sigma and YARA rules are managed in the Detections module, and every suppression and threshold needs an owner.
What the tool does
Security Onion was started by Doug Burks in 2008; Security Onion Solutions, LLC, founded in 2014, maintains it and is the only official provider of its appliances, training and professional services. The platform delivers network visibility, host visibility, intrusion detection honeypots, log management and case management. It installs from an ISO image (or cloud images for Amazon, Azure and Google Cloud) and supports x86-64 hardware only.
| Component | Role in the platform |
|---|---|
| Suricata | Network IDS alerts, network metadata, file extraction. See the Suricata IDS Guide. |
| Zeek | Network protocol metadata and file extraction. See the Zeek Network Monitoring Guide. |
| Stenographer | Full packet capture, retrieved from the PCAP interface; captures stay on the sensor |
| Strelka | File analysis of extracted files, including YARA rules |
| Elastic Agent and Fleet | Host log collection from Windows, macOS and Linux endpoints and transport from grid nodes |
| osquery | Live queries against endpoints through Osquery Manager |
| Elasticsearch, Logstash, Redis, Kibana | Storage, parsing, queuing and search of all events |
| ElastAlert 2 | Runs Sigma rules managed in Detections |
| Security Onion Console (SOC) | Alerts, Hunt, Dashboards, Cases, PCAP, Detections and CyberChef for decoding artefacts |
| Intrusion Detection Honeypot (IDH) | Fake HTTP, FTP and SSH services where any interaction raises an alert |
Licensing
The documentation states that Elastic components and Security Onion components are licensed under the Elastic License 2.0 (ELv2), which you accept during installation; much of the other bundled software uses open source licences (Suricata, for example, is GPLv2). ELv2 is a source available licence, not an OSI open source licence. Its published terms say you may not provide the software to third parties as a hosted or managed service, may not move, change, disable or circumvent licence key functionality, and must keep licensing and copyright notices. For internal use by your own SOC this is rarely a constraint. For an MSSP, a managed detection offering or a product that exposes the console to customers, obtain legal advice before you design the service.
Defender use cases
- Network security monitoring: Suricata alerts and Zeek logs from TAP or SPAN feeds give a record of every connection, DNS query, TLS handshake and file transfer on monitored segments. See the NDR Guide.
- Threat hunting: Hunt and Dashboards let analysts pivot from an indicator to every host that touched it, then down to packets with PCAP. See the Threat Hunting Guide.
- Incident response: Cases records observables, evidence and analyst notes; osquery live queries check endpoint state during scoping; CyberChef decodes encoded payloads found in logs.
- Retrospective analysis: Import mode ingests PCAP or EVTX files for a one off investigation on an isolated box, without deploying sensors.
- Deception: IDH nodes in server zones give high fidelity alerts because no legitimate user should touch them.
- Training and labs: Evaluation mode on one machine lets analysts practise with real tools before production. Many teams also use it as an open source SIEM; see the SIEM Guide.
| Investigation question | Where the answer comes from | ATT&CK technique it helps detect |
|---|---|---|
| Which hosts beaconed to this domain? | Zeek and Suricata DNS, TLS and HTTP records in Hunt | T1071.001 Web Protocols, T1071.004 DNS |
| Was data sent out over the same channel? | Connection byte counts, PCAP for the session | T1041 Exfiltration Over C2 Channel |
| Who scanned the server VLAN? | Suricata alerts, Zeek connection logs, IDH alerts | T1046 Network Service Discovery |
| Is there encrypted traffic on an odd port? | Protocol detection independent of port, TLS metadata | T1571 Non-Standard Port, T1573 Encrypted Channel |
| What did the dropped file do? | Strelka results and YARA matches | Supports malware triage |
Deployment and safe use
Architectures
| Deployment | What runs where | Use it for |
|---|---|---|
| Import | Single box, minimal components, PCAP or EVTX import only | One off forensic analysis |
| Evaluation | Single box with sniffing interface, Elastic Agent writes directly to Elasticsearch, no Logstash | Short term testing, not production |
| Standalone | All components on one box, with Logstash and Redis in the pipeline | Labs, proofs of concept, very low throughput sites |
| Distributed | Manager (SOC, Kibana, Elasticsearch, Logstash, ElastAlert 2, Redis), search nodes, sensor nodes; optional receiver, fleet, IDH nodes | The recommended production design, scales by adding nodes |
| Heavy node | Sensor with its own Elasticsearch cluster, queried by cross cluster search | Rare cases only; the docs do not recommend it for most deployments |
Elastic Agent from endpoints needs Logstash, so it only works with standalone or distributed grids, and in distributed grids agents send to the manager or a receiver, never to a sensor. Receiver nodes keep events flowing to search nodes if the manager goes offline; fleet nodes help with large endpoint counts and agents off the corporate network.
Hardware sizing
| Node type | Minimum CPU cores | Minimum RAM | Minimum storage | NICs |
|---|---|---|---|---|
| Standalone | 4 | 24 GB | 200 GB | 2 |
| Manager | 4 | 16 GB | 200 GB | 1 |
| Search node | 4 | 16 GB | 200 GB | 1 |
| Sensor | 4 | 12 GB | 200 GB | 2 |
| Receiver | 2 | 8 GB | 200 GB | 1 |
| IDH | 2 | 1 GB | 12 GB | 1 |
These are bare minimums that the documentation warns may be too low for real use. Its sizing guidance is more useful:
- Sensor CPU: about 200 Mbps per Suricata or Zeek worker; a saturated 1 Gbps link running both needs at least 5 workers of each, so 10 cores before overhead.
- Sensor RAM: 16 GB or more up to 100 Mbps, 16 to 128 GB for 100 Mbps to 1 Gbps, 128 to 256 GB for 1 to 10 Gbps; over provision so swap can be disabled. Standalone boxes should have 32 GB or more if they monitor any traffic.
- Packet capture disk: a link averaging 50 Mbps produces about 540 GB a day; multiply by the days of PCAP you need.
- Search storage: local SSD or fast disks in RAID 10 for /nsm/elasticsearch, with no more than about 30 days of hot indices.
- Interfaces: one wired management interface with a static address; sniffing interfaces have no IP address, and the installer disables tso, gso and gro offloading on them. Wireless is not supported.
Phased rollout
- Decide scope and data rules: which segments and endpoints are monitored, who may view packets and logs (they include URLs, file contents and possibly clear text credentials), and retention for PCAP and indices. Align with your monitoring policy and privacy obligations.
- Evaluate first: build an Evaluation or Standalone box on a SPAN port in a lab or one low traffic segment.
- Verify and install: always verify the ISO checksum before booting, and set the final hostname before Setup, because certificates are generated from it and changing it later is not supported.
- Build the distributed grid: manager and search nodes first, then sensors per monitored zone, then receivers or fleet nodes if needed.
- Open only required access: the host firewall is locked down by default and managed by Salt through host groups and port groups. Add analyst networks to the
analysthost group (HTTPS on 443) and endpoints toelastic_agent_endpoint; between nodes allow the documented ports such as 443, 4505, 4506, 5055, 8220 and 8443 to the manager and 9200 and 9300 between Elastic nodes. Do not edit iptables by hand. - Onboard endpoints in rings: deploy Elastic Agent installers from the SOC Downloads page to a pilot group, confirm data in Hunt, then widen.
- Tune detections: in Detections, choose Suricata sources (ETOPEN, ETPRO, custom URL or local directory), Sigma and YARA repositories, then disable, suppress or threshold noisy NIDS rules and add custom filters to Sigma rules.
- Plan rollback and recovery: keep configuration exports, test restoring the manager, and snapshot virtual nodes before upgrades so a failed update can be reverted.
Where identity fits
The grid holds powerful credentials: Elastic Agent enrolment tokens, Salt keys that control every node, and administrator accounts for SOC and Kibana. Treat them as privileged non-human identities: restrict who can download installers with embedded tokens, rotate tokens after a pilot, enforce MFA for console administrators, and alert on new grid members or accounts. See the SIEM Buyer's Guide for the access control questions to ask of any monitoring platform.
Detection and hardening value
What to monitor
- Grid health: node status, Redis queue depth on the manager or receivers, and Elasticsearch cluster health.
- Sensor loss: packet drop statistics for Suricata, Zeek and Stenographer per interface.
- Rule sync: Detections engine status (Synchronizing, Sync Failed, Rule Mismatch, OK) and the age of the last rule update.
- Retention: days of PCAP and of searchable indices actually available versus policy.
- Platform access: console logins, firewall host group changes and new agents.
Metrics that show it is working
| KPI | Target to aim for |
|---|---|
| Monitored egress and critical zones | 100 percent of internet links, named list of internal zones |
| Sensor drop rate at peak | Below 1 percent |
| PCAP retention achieved | At or above the incident response requirement, for example 7 days |
| Endpoints reporting through Elastic Agent | Above 95 percent of in scope assets |
| Alerts escalated to Cases that were true positives | Rising as tuning matures |
| Rule sync failures | Zero open for more than 24 hours |
Framework mapping
| Framework | Reference | How Security Onion contributes |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01, DE.AE-02, DE.AE-03, RS.AN-03 | Network monitoring, event analysis, correlation across sources, incident analysis |
| NIST SP 800-53 Rev. 5 | SI-4, SI-4(4), AU-6, AU-11, IR-4 | System and traffic monitoring, log review, retention, incident handling |
| CIS Controls v8.1 | Control 8 Audit Log Management, Control 13 Network Monitoring and Defense | Central log collection and network intrusion detection |
| ISO/IEC 27001:2022 | Annex A 8.15 Logging, 8.16 Monitoring activities | Evidence of logging and monitoring |
| MITRE D3FEND | D3-NTA Network Traffic Analysis, D3-NTSA Network Traffic Signature Analysis | Metadata and signature based traffic analysis |
Common failure patterns
- Production on a standalone box: one overloaded machine drops packets and stalls searches as traffic grows.
- Undersized PCAP disk: packet capture rolls over in hours, so the packets are gone by the time an alert is triaged.
- Wrong hostname at install: certificates are bound to it and the node has to be rebuilt.
- Console exposed widely: analyst host groups opened to whole networks, giving attackers a searchable map of the estate.
- No tuning owner: default rules left untouched, alert fatigue sets in and Cases stop being used.
- Licence assumed open source: a provider builds a customer facing service and only later reviews the ELv2 hosted service restriction.
Alternatives
| Option | Approach | When it fits better |
|---|---|---|
| Self built Suricata and Zeek with a SIEM | Engines feed an existing log platform | Teams that already run a SIEM and want only sensors. See the IDS and IPS Guide. |
| Wazuh | Open source host based detection, file integrity and log analysis | Host focused programmes; often paired with network sensors. See the Wazuh Guide. |
| Elastic Security on its own | SIEM and endpoint security without bundled network sensors | Endpoint and log focus. See the Elastic Security Guide. |
| Commercial NDR or SIEM | Managed content, analytics and vendor support | Limited engineering staff or contractual support needs. See the NDR Buyer's Guide. |
Small teams get the most from a single standalone or small distributed grid on the internet link plus key servers, using default content. Large organisations need distributed grids per region, receiver nodes for resilience, a detection engineering workflow with Sigma rules in version control (see the Sigma Rules Guide) and a clear decision on ELv2 if any third party will use the service. For a wider comparison see the Open Source SIEM and Detection Tools Landscape Guide.
Practitioner checklist
- Choose the deployment type deliberately: Evaluation for testing, distributed for production.
- Size sensors at about 200 Mbps per Suricata or Zeek worker and calculate PCAP disk from average link throughput.
- Verify the ISO checksum and set the final hostname before running Setup.
- Keep sniffing interfaces without IP addresses and the management interface on a dedicated network.
- Restrict the analyst and elastic_agent_endpoint host groups to named networks and enforce MFA for administrators.
- Protect and rotate Elastic Agent enrolment tokens and alert on new grid members.
- Assign an owner for Detections tuning and review suppressions and thresholds quarterly.
- Monitor drops, Redis queue depth, rule sync status and retention against policy.
- Review the Elastic License 2.0 terms before offering any service to third parties.
Standards and references
- Security Onion Solutions: Security Onion Introduction
- Security Onion Solutions: Architecture
- Security Onion Solutions: Hardware Requirements
- Security Onion Solutions: Detections
- Security Onion Solutions: Firewall
- Security Onion Solutions: Elastic License 2.0
- OISF: What is Suricata
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Suricata IDS Guide · NDR Guide · SIEM Guide · Threat Hunting Guide · Zeek Network Monitoring Guide