Which open-source alternative to QRadar network flow monitoring fits your sensors
Security Onion is the main open-source replacement for QRadar flow collection, with Wazuh covering log-based detection alongside it. Security Onion bundles Zeek, Suricata and full packet capture, so the network metadata, alerts and packet record that QRadar flow licensing covers would be produced by sensors you run in your own network. Wazuh then ingests the logs and EVE JSON output from the same environment for rule-based detection. The two are complementary rather than a single product swap, so plan for both if you currently rely on QRadar for flows and events.
The replacement is a set of components rather than one license. Security Onion's recommended production design is Distributed, with a manager node, one or more sensor nodes and one or more search nodes, and the architecture docs note that search nodes stop indexing if the manager goes down. Your cost therefore shifts to hardware or cloud capacity for each role, storage sized for retained packet data, and the staff time to operate it. Confirm the sensor placement, expected traffic volume and packet retention period with your team before you size anything, because these drive the hardware and storage requirements in the hardware documentation.
Check the license before you commit. The Security Onion repository is licensed under the *Elastic License 2.0*, which is source-available rather than an OSI-approved open-source license. Self-managing the platform is permitted under those terms, but your legal and procurement teams should review them against your internal definition of open source and any policy on bundled third-party components. Security Onion Pro is a separate paid tier, so ask whether any features you need, such as single sign-on or FIPS mode, sit only in that tier.
How QRadar flow capabilities map to Security Onion, Zeek, Suricata and Wazuh
This table maps each QRadar flow capability to the open-source component that covers it, with the gaps stated plainly. Read it as a coverage check: where a row says partial or none, plan a design decision or a rebuild rather than assuming a like-for-like swap. Confirm every flow field against your own QRadar export before you sign off on the mapping.
| Capability | Open-source equivalent | Coverage notes and gaps |
|---|---|---|
| Flow collection | Zeek connection logs and Suricata EVE flow records, collected by Security Onion sensors | Zeek writes connection records by default in TSV or JSON. Suricata EVE JSON also records flows. Confirm which fields your QRadar flow records carry, such as byte and packet counts and flow direction, and check each one exists in Zeek or EVE output. |
| Flow-based network activity analysis | Zeek application logs (HTTP, DNS, SSL, SMTP) searched in Security Onion | Coverage is deeper than flow records alone because Zeek logs application-layer detail. It is not a direct copy of QRadar flow views, so analysts will need new searches and dashboards. |
| Signature-based detection on network traffic | Suricata rules, with Emerging Threats or VRT rulesets, managed in the Security Onion Console Detections interface | Suricata provides a full signature language and Lua scripting. Zeek is not a classic signature IDS and is not optimized for byte matching, so signature work belongs in Suricata. |
| Offense correlation on network data | Security Onion alerts combined with Wazuh rules and correlation logic your team writes | No one-to-one equivalent exists. QRadar offenses group related events automatically. Expect to design correlation rules, thresholds and alert grouping yourself, and to test them against known scenarios. |
| Custom network rules | Suricata custom rules, Zeek scripts and Sigma rules run through ElastAlert in Security Onion | Suricata rules and Zeek scripts are both written by hand. Zeek scripting is Turing-complete and covers default analyses, so it suits custom behavior that signatures cannot express. Confirm the rule syntax your team needs before migrating. |
| Packet retention | Full packet capture from Suricata in Security Onion 3.0.0 and later | Security Onion 3.0.0 replaced Stenographer with Suricata for full packet capture and supports only Oracle Linux 9. Check retention size, storage sizing and whether 2.4 installs can upgrade in your environment before relying on it. |
| Log-based detection | Wazuh server analyzing logs, with Suricata EVE JSON read by the Wazuh agent | Wazuh documents Suricata as a network IDS integration. Wazuh rules and decoders replace QRadar log-source detection, but log source coverage must be rebuilt and verified one source at a time. |
| Sensor resilience | Security Onion distributed design with manager, sensor and search nodes | If the manager goes down, search nodes stop indexing because they cannot reach Redis. Plan manager availability and receiver nodes for redundancy and load balancing. |
What changes when flow licensing stops setting your sensor design
Under QRadar, the flow license sets how much network visibility costs, and that cost moves with traffic volume and event rate. Under a self-hosted Security Onion design, the cost moves to components you buy and run: sensor hardware, search node storage, staff time to tune and maintain the stack, and any outside support you contract. Nothing in that list is a per-minute charge, so the cost you pay is driven by how you size the sensors and how long you keep data. Ask your QRadar account team for the flow rate you currently license and the basis on which it is counted, so you can compare it against the traffic you actually observe rather than against a generic figure.
Four design choices move the self-hosted cost most. Link speed determines how many sensor NICs, how much CPU and which capture method you need, since Security Onion sensors run Suricata and Zeek on x86-64 hardware and the minimum specifications in the hardware documentation are only a starting point for busy links. Which protocols you log matters because Zeek writes connection records, DNS, HTTP, SSL and SMTP logs by default, and each enabled log adds storage and search load. How long you keep full packet capture is usually the largest storage line, because pcap grows with traffic and retention multiplies it. How many search nodes you run depends on the indexing and query load that the first three choices create, and the architecture documentation notes that search nodes stop indexing if they cannot reach the manager, which makes the manager and its redundancy part of the same sizing decision.
Size the design from your own traffic. Measure peak and average throughput on the links you plan to monitor, the daily volume of Zeek and Suricata logs you expect, and the retention period your investigations and your regulators require, then ask each vendor or integrator to price against those numbers in writing. DeployOpen does not estimate prices. We scope the sensor, storage and node layout from the measurements you provide and quote from that written scope. Confirm current hardware minimums and support terms with the Security Onion project and your integrator before you commit budget, because the release line and end-of-life dates change.
Choosing between Security Onion, standalone Zeek, standalone Suricata and Wazuh with Suricata
Each option covers a different part of the QRadar flow question: a packaged sensor stack, network metadata for an existing SIEM, signature detection, or log-based detection. Choose by how much you want delivered as one product and how much your team will assemble and maintain itself.
Security Onion as a packaged stack
Security Onion bundles Suricata, Zeek, Suricata full packet capture and the Security Onion Console into one Linux distribution, which is the closest match to QRadar flow monitoring with packet access. Its repository is licensed under the Elastic License 2.0, a source-available license that legal teams should review before production use. Version 3.0.0 supports only Oracle Linux 9, and 2.4 reached end of life on October 1, 2026, so confirm your OS standard before planning an upgrade or fresh install.
Standalone Zeek for transcripts
Zeek writes connection records and application transcripts for HTTP, DNS, SSL certificates and SMTP to TSV or JSON logs that an existing SIEM can index. It fits teams that already run a log platform and want network metadata without a packaged console. Zeek is BSD-licensed, and it leaves signature alerts to a separate IDS such as Suricata. Plan for scripting work, since its default analyses are written as Zeek scripts, and confirm your team can maintain them.
Standalone Suricata for signatures
Suricata matches a full signature language against traffic, detects anomalies and writes its EVE output as JSON for Logstash or similar tools. It also logs HTTP requests, TLS certificates and DNS queries, and it extracts files from flows. Suricata is GPL-2.0 licensed, so review distribution obligations if you modify it. Throughput depends on hardware, capture method and rule set, so benchmark on your own traffic before sizing sensors. The Suricata 7 line is end of life, so new deployments should start on the 8.x line.
Wazuh reading Suricata EVE logs
Suricata runs on the monitored endpoint, the Wazuh agent reads its EVE JSON logs, and the Wazuh server analyzes them with its rules. This fits teams that want log-based detection, file integrity monitoring and compliance reporting in one platform. Wazuh is GPLv2 licensed. The trade-off is that Wazuh correlates Suricata events but does not provide full packet capture or Zeek transcripts, so you lose the flow-level depth QRadar offers unless you add those sensors.
Running Security Onion beside the rest of your QRadar suite
Most teams do not switch off QRadar on the day Security Onion goes live. The cards below cover the coexistence patterns we see most often, the duplication and ownership problems they create, and the manager dependency that determines how the distributed design must be monitored.
Keep QRadar for correlation
QRadar stays as the correlation and offense engine while Security Onion takes over flow-style network visibility through Zeek and Suricata. Security Onion's sensors send network metadata and alerts to a place where you can forward them to QRadar as log sources. Check which fields QRadar needs to build its offenses, because Zeek and Suricata record data in their own schemas and your existing rules may expect QRadar's flow fields.
Send Zeek and Suricata logs to QRadar
During a transition, forwarding Suricata EVE JSON and Zeek logs into QRadar lets analysts keep one console while the network content matures. Zeek writes tab-separated or JSON logs by default, and Suricata's EVE output is JSON, so you will need parsing and a QRadar log source definition for each. Confirm the event rate with your QRadar license before you turn on full sensor output, since verbose Zeek logs can add events quickly.
Move log-based detection to Wazuh first
Log-based detection from QRadar rules can often move to Wazuh before network visibility does, since Wazuh agents collect endpoint and server logs directly. Wazuh also reads Suricata EVE logs through its agent, so the network sensor and the log detections can share one pipeline. Sequence the move so each rule has one owner and one active alerting path at any time.
Dual alerting and duplicate events
Running both QRadar and Security Onion on the same traffic can produce two alerts for one event, once from a Suricata signature and again from a correlation rule built on the same log. Duplicates inflate queue volume and make analysts question which console is authoritative. Decide which system raises each alert class, and check that suppression or deduplication is configured on the side that should stay quiet.
Split ownership of rules
Security Onion's Detections interface manages NIDS rules in Suricata, Sigma rules in ElastAlert and YARA rules in Strelka, while QRadar holds its own rules and building blocks. Two rule sets covering the same behavior drift apart over time, and tuning done in one tool is invisible in the other. Name one owner for each detection, record where it lives, and review both consoles on a fixed cadence.
Monitor the manager and receivers
In the distributed design, if the manager goes down, search nodes stop indexing because they cannot reach Redis. Your monitoring must cover the manager host, its services and the path from sensors to search nodes, not just the sensors that generate alerts. Receiver nodes add pipeline redundancy and load balancing, so ask whether your design needs them and document how the team will respond to a manager outage.
Sizing Security Onion nodes by role and deployment type
A standalone node runs the full Security Onion stack on one machine. It is the simplest layout to build and test, but every role shares the same host, so the console, collection and indexing all compete for the same resources. The Security Onion hardware docs set the minimum for a standalone node at 4 cores, 24 GB RAM, 200 GB storage and 2 NICs.
- Memory floor: 24 GB RAM is the stated minimum, which is higher than the 16 GB listed for a manager or search node.
- Storage: 200 GB is the starting figure. Retention period and the volume of full packet capture drive the real need, so calculate it from your own data.
- Interfaces: two NICs are the minimum. One is typically kept for management and the other receives monitored traffic.
- Failure scope: because all roles share one host, an outage takes down collection, indexing and the console together.
- Architecture: confirm the processor is x86-64, since Security Onion supports only that architecture.
Before you commit to a single host, compare the storage minimum with the retention period and traffic volume your team expects to keep.
The architecture docs recommend the Distributed type for production. It uses a manager node, one or more sensor nodes and one or more search nodes. Each role is sized on its own, so you can add sensors at the network edges where traffic enters and add search nodes as indexing and query load grows.
- Manager node: 4 cores and 16 GB RAM minimum. It coordinates the deployment, so protect it closely. The architecture docs note that if the manager goes down, search nodes stop indexing because they cannot reach Redis.
- Search node: 4 cores and 16 GB RAM minimum, with storage sized to your retention target and query needs.
- Sensor node: 4 cores, 12 GB RAM and 2 NICs minimum, placed where each monitored segment can be mirrored or tapped.
- Receiver nodes: the architecture docs state that receivers add pipeline redundancy and load balancing. Plan them early if log volume or availability requirements are high.
- Node counts: the number of sensors and search nodes is a design decision. Confirm it against your traffic profile and your network team's mirroring options.
Size the manager and search nodes from retention and query load, and confirm sensor placement with your network team before ordering hardware.
Import and Evaluation deployments let teams test Security Onion before committing production hardware. The minimums for the standalone, manager, search and sensor roles are the figures to start from. Confirm with Security Onion Solutions whether Import or Evaluation installs carry different requirements before you build the test environment.
- Trial sizing: for a single-host evaluation, start from the standalone minimums of 24 GB RAM, 200 GB storage and 2 NICs.
- Traffic sample: test with a representative slice of production traffic. A quiet lab feed can hide the packet rate a production sensor will face.
- Platform match: Security Onion 3.0.0 supports only Oracle Linux 9, so test on that operating system if production will run it.
- Upgrade path: a 2.4 installation on Oracle Linux 9 can upgrade to 3 after full packet capture moves from Stenographer to Suricata. Other distributions need a fresh install, so plan for that during testing.
- Baseline capture: record CPU, memory, disk and packet rates during the trial.
Use the recorded baseline as the starting point for production sizing, and do not treat trial results as a final capacity estimate.
Moving flow collection off QRadar in stages
This sequence moves QRadar flow collection to Security Onion sensors and Wazuh in parallel, so each detection is proven against known test cases before QRadar flow licensing is retired.
Inventory QRadar flow sources and retention
The network team lists every flow source QRadar ingests today, including span ports, taps, flow exporters and firewalls, with the segment each one covers and the retention the security team relies on for investigations. The security lead records which offenses and reports depend on flow data, because those are the detections that must be rebuilt. The step is done when the list is signed off by both teams and each source has a named owner for the cutover.
Export flow and event samples from QRadar
Before any new sensor sees traffic, the team pulls representative flow and event samples from QRadar, using the Ariel API or Log Activity exports described in the export guide, and keeps them in a controlled evidence store. These samples become the reference set for later validation. The step is done when samples cover each source from the inventory and the team can point to the offenses they should reproduce.
Select the Security Onion version and operating system
Confirm the target release and host OS before buying hardware. Security Onion 3.0.0 supports only Oracle Linux 9, and 3.3.0 is the latest tagged release at the time of the source review, so check the GitHub releases and the end-of-life page for the version you plan to run. Confirm x86-64 hardware and the minimum specifications for each node role in the hardware documentation. The step is done when a written version, OS and hardware list is approved.
Build a lab with Import or Evaluation
Install a lab instance using the Import or Evaluation deployment type, which the architecture documentation describes for testing rather than production. Replay the exported PCAP or recorded traffic into it, confirm Suricata and Zeek logs appear in the Console, and check that Strelka receives extracted files where you need them. The step is done when the team can reproduce a sample flow record in the Console and document any parsing or sizing issues.
Deploy the distributed production design
Build the production layout the architecture documentation recommends: a manager node, one or more sensor nodes and one or more search nodes, with receiver nodes added where pipeline redundancy matters. Note that if the manager fails, search nodes stop indexing because they cannot reach Redis, so plan manager availability and backups accordingly. The step is done when all nodes report healthy and a test event flows from sensor to search node.
Mirror traffic to sensors in parallel with QRadar
Add SPAN or tap feeds to the new sensors while QRadar keeps receiving its existing flows, so both platforms see the same traffic for an agreed comparison period. Compare event volumes, protocol coverage and alert counts per segment, and record every gap. Confirm that the traffic mirror design does not overload the network devices that feed it. The step is done when the security team signs off that Security Onion sees the segments QRadar sees.
Rebuild detections in the Security Onion Console
Rebuild the offense logic in the Detections interface: load NIDS rules into Suricata, express log-based logic as Sigma rules loaded into ElastAlert, and apply modify, suppress and threshold tuning for NIDS rules. Start from the Emerging Threats or VRT rulesets where they match your use case, and document which QRadar rules have no equivalent. The step is done when each retained QRadar detection has a named Security Onion rule, a suppression record and an owner.
Connect Wazuh through EVE JSON
Where the Wazuh agent reads Suricata EVE JSON logs from the monitored endpoint, configure the agent to forward them to the Wazuh server, following the network IDS integration guide. Confirm the events are parsed and appear in the Wazuh dashboard alongside host logs. The step is done when a test alert raised in Suricata appears in Wazuh with the expected fields.
Validate detections against known test cases
Run known test traffic, such as recorded malicious samples or red team scenarios from your own testing, and the reference samples from earlier steps against both platforms. Record whether each expected detection fires in Security Onion or Wazuh, how long triage takes, and which false positives need tuning. Repeat after each tuning change. The step is done when every retained detection has a documented pass result and the remaining gaps are accepted in writing.
Retire QRadar flow collection in stages
Switch off QRadar flow feeds one segment at a time, starting with the segments that validated cleanly, and keep the exported archives under the retention rules set in step one. Update runbooks and incident playbooks, and confirm the compliance team accepts the evidence location. The step is done when QRadar no longer receives flow data for any segment, and the archive and retention records are filed.
What QRadar flow replacement costs and what it needs from your team
What drives the cost of replacing QRadar flow monitoring with Security Onion?
The main cost drivers are the hardware for sensor and search nodes, storage sized to your traffic and retention period, staff time to build and tune detections, and any outside support you buy. Security Onion itself carries no license fee for the free edition. Hardware and storage are mostly one-time purchases or a recurring cloud bill, depending on where you run it. Staff time is both one-time (deployment, tuning, detection content) and recurring (alert triage, upgrades, rule maintenance). Ask any quote to separate these lines so you can compare them with your current QRadar flow licensing and appliance renewals.
Can our own staff run Security Onion without outside help?
Yes, many teams run it in-house, but it requires Linux administration, network sensor placement, and Elastic-style search and dashboard skills. The documented production design is Distributed, with a manager node, one or more sensor nodes and one or more search nodes. Your team should confirm it has people who can operate that layout, handle hardware sizing for x86-64 servers, and keep up with upgrades. Security Onion's documentation also notes that if the manager goes down, search nodes stop indexing because they cannot reach Redis, so plan operational cover for that failure mode.
How long does a QRadar flow replacement take?
The duration depends on the number of sensor sites, the size of your network, how many flow and detection use cases you need to rebuild, and how much parallel running your operations team requires. DeployOpen does not publish a timeline, so ask for a written scope and timeline before work starts. Also confirm the release timing for the version you choose: Security Onion 3.0.0 was released on March 31, 2026, supports only Oracle Linux 9, and the latest tagged release on GitHub is 3.3.0, published September 11, 2026. Check that the version you deploy is still supported for the period you plan to run it.
What does the work need from our team during a migration?
Expect to supply network diagrams, the locations where traffic can be mirrored or tapped, the list of QRadar flow rules and reports you rely on, and named owners for detection tuning and alert response. You will also need hardware or cloud accounts, access to the networks where sensors sit, and change windows for mirror port and network changes. If you operate in an air-gapped environment, the Security Onion ISO carries packages and NIDS, YARA and Sigma rules, so plan how media moves into the network and how updates are applied with the soup tool.
Is Security Onion Pro required to replace QRadar flows?
No. The free Security Onion distribution includes Suricata, Zeek, the Elastic Stack components and Suricata full packet capture, which covers the core flow and network analysis use case. Security Onion Pro is a paid edition sold on 1 to 5 year terms. It adds OIDC single sign-on to the Console, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API, external notifications, Manager of Managers, an MCP server, the Onion AI assistant and professional support. Whether those features matter depends on your identity, encryption, accreditation and support requirements, so review them against your compliance obligations before deciding.
What does the Elastic License 2.0 mean for our organization?
The Security Onion repository is licensed under the Elastic License 2.0, which is source-available rather than an OSI-approved open-source license. In practice, you can read, use and self-host the software, but the license restricts some uses, such as offering it to third parties as a managed service. Have your legal or procurement team review the license text against your intended use, especially if you plan to run Security Onion for customers or affiliates. Confirm the terms with the vendor or your counsel rather than relying on this summary.
Which QRadar flow costs go away, and which ones stay?
QRadar flow licensing and the related appliance or Managed Virtual Server costs are the lines you replace. Security Onion removes the flow licence fee, but you keep recurring costs for power, rack or cloud compute, storage growth, staff time, support contracts and any Pro subscription. Ask a provider to show your current QRadar flow and appliance renewals next to a per-year estimate of the self-hosted lines, so the comparison covers the same traffic volume and retention period.
How DeployOpen scopes and delivers a network flow monitoring replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a QRadar flow replacement, we start from the flow sources and sensor placement you have today, then build a Security Onion deployment and its Wazuh log path to match, with a written scope agreed before work begins.
How we scope
- We inventory QRadar flow sources, flow licensing drivers and the network segments that need sensor coverage.
- We define which Security Onion deployment type fits your environment, such as Distributed with manager, sensor and search nodes.
- We agree in writing which detections, Wazuh log integrations and hardware or cloud sizing are in scope before work starts.
How we build
- We install Security Onion with Suricata, Zeek and full packet capture on sensors sized to the hardware requirements for each node role.
- We integrate Suricata EVE JSON and Zeek logs into Wazuh so network alerts sit alongside host and log-based detections.
- We tune NIDS rules, suppressions and thresholds in the Detections interface and test alerting against your known traffic patterns.
How we hand over
- We document the deployment, node layout, retention settings, rule sources and the procedures for upgrades and airgap updates.
- We deliver the analyst runbooks for hunting in Zeek and Suricata logs and for pivoting between flow, alert and packet data.
- We provide a handover session with your security operations and platform staff, and record open items and owners.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- We plan Security Onion upgrades against the project's end-of-life dates, including the move to the Oracle Linux 9 line.
- We run security testing of the deployed platform on request, so changes to sensors or rules are checked before production use.
