Open Source SIEM: 7 Free Tools for Your Home Lab (2026)

An open source SIEM is a security information and event management platform whose code you can read, modify and self-host under an open license, with no per-endpoint fee. For a home lab in 2026, start with Wazuh (GPLv2), add OpenSearch Security Analytics for Sigma rules, and use Security Onion (free, source-available) for network visibility.

You get the same core capability as a commercial platform (log collection, correlation rules, alerting, and threat detection) in exchange for owning the infrastructure and the tuning yourself. The deeper reason to run one is transferable. Every commercial console you will meet on the job is different, but the underlying model is the same: how ingestion works, why a rule fires, what separates a raw event from a correlated alert. You learn it by operating a SIEM, not by reading about one.

Which one first?

• Building your first home lab? Start with Wazuh. Five commands, modest hardware, and the detection concepts map directly to what commercial SIEMs do under the hood.
• Targeting network/NSM roles? Deploy Security Onion. Zeek logs and Suricata rule-writing are the skills that move you from Tier 1 into Tier 2 network investigations.
• Want to run Sigma rules without converting them? Stand up OpenSearch with Security Analytics. It ships prepackaged Sigma rules and maps them to your log fields.
• Already comfortable with host-based detection? Add Elastic Security as your second platform. EQL transfers to production Elastic deployments and the query model sharpens your detection engineering skills.

The seven tools below cover the realistic range of what you can self-host on a Linux box or VM in 2026. For each one, this guide covers how difficult it is to install, what hardware the vendor actually asks for, what skills it builds, and who it is best for. The comparison table at the end lets you pick quickly, and the license column tells you which ones are open source and which are only free.

Free SIEM vs Open Source SIEM: Not the Same Thing

"Free" describes the price. "Open source" describes the license, and only an OSI-approved license (GPL, Apache, AGPL) earns the label. Several popular free SIEMs fail that test, which matters if you plan to modify the code or build a product on top of it. For a home lab it mostly doesn't.

• Open source: Wazuh (GPLv2), OSSEC (GPLv2), OpenSearch and its Security Analytics plugin (Apache 2.0), Clear NDR Community (GPLv3 or later), UTMStack (AGPLv3).
• Free but source-available: Security Onion (its own components and the Elastic ones ship under the Elastic License 2.0), Graylog Open (Server Side Public License), and Elastic's free Basic tier. Elastic added AGPLv3 as an option for the free parts of the Elasticsearch and Kibana source in 2024, but its releases still ship under the Elastic License.
• Free but proprietary: Splunk Free. It caps indexing at 500 MB a day, has no users or roles, and switches alerting off. Three license warnings in a rolling 30 days and search stops. It is a fine place to practice SPL, but without alerts it is not a SIEM in any sense a SOC would recognize.

1. Wazuh

Wazuh is a full-stack, open source security monitoring platform covering SIEM, XDR, and compliance in a single deployment.

Wazuh earns the first slot because it is the closest thing the open source world has to an enterprise SIEM that a single analyst can operate. It consists of three components: the Wazuh indexer (an OpenSearch fork that stores events), the Wazuh server (the analysis engine and rule processor), and the Wazuh dashboard (a Kibana-based UI). Agents run on monitored endpoints and ship logs, file integrity data, vulnerability information, and system inventory to the server.

The quickest path to a running single-node lab instance is Docker on a Linux host (or Windows with Docker Desktop and WSL 2). The official Docker guide boils down to this:

sudo sysctl -w vm.max_map_count=262144   # the indexer fails without it
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.8
cd wazuh-docker/single-node
docker compose -f generate-indexer-certs.yml run --rm generator
docker compose up -d

Older tutorials skip the certificate step, but the docs require certificates for every node before you bring the stack up. The dashboard comes up on https://<docker-host> with the documented default login admin / SecretPassword. Change it before you expose the dashboard to anything outside your lab network.

The lab also exposes a blind spot early. An agent on the host sees the Docker daemon, not the inside of each container, so a command run with docker exec does not arrive as a process launch that belongs to anybody. The container runtime and the orchestrator keep their own audit trails, and wiring those in is a separate job from installing the agent.

Hardware requirements for a functional lab are modest. Wazuh's documentation asks for at least 4 CPU cores, 8 GB of RAM and 50 GB of disk for the single-node Docker stack, on AMD64 or ARM64. A dedicated machine is ideal, but a VM on a host with 16 GB of RAM leaves enough headroom for the monitored endpoints next to it.

What Wazuh teaches you is broad and directly applicable to employment. Wazuh rules are XML and Sigma rules are YAML, but the parts line up: a match on decoded log fields, a severity level, and ATT&CK technique IDs (a <mitre><id> block in Wazuh, attack.t tags in Sigma). Once you can read one, the Sigma rules guide reads like a translation exercise. The out-of-the-box rule set covers MITRE ATT&CK techniques with explicit tagging, which means you can trace any alert back to a tactic and technique without additional tooling. File integrity monitoring (FIM) teaches you how host-based detection differs from network detection, a distinction that matters when you are triaging alerts that mix both. FIM also happens to be the one cheap handle on malicious browser extensions, which land as ordinary files in a user profile and never produce a binary for anything to scan. You have to aim it there on purpose, though. Stock FIM policies watch system paths and skip profile directories entirely. The compliance modules (PCI DSS, HIPAA, NIST 800-53, CIS benchmarks) give you early exposure to the compliance vocabulary that comes up in every enterprise SOC role.

Wazuh's official documentation is thorough and actively maintained. The Wazuh community Slack is the fastest route to answers when something does not work.

Best for: Anyone building their first home lab SIEM. The deployment is fast, the UI is intuitive, and the detection coverage closest to what employers want to see on a resume.

Wazuh →

2. Security Onion

Security Onion is a free Linux distribution purpose-built for network security monitoring, combining Zeek, Suricata, Elasticsearch, Kibana, and a suite of investigation tools into a single installable image.

Where Wazuh centers on host-based telemetry, Security Onion centers on the network. It ingests traffic from a span port or tap, generates connection logs (Zeek), runs intrusion detection rules (Suricata), indexes everything into Elasticsearch, and surfaces it all through a unified investigation interface called Security Onion Console (SOC, which is an excellent irony for the audience). It also ships with Kibana, CyberChef, and network artifact extraction.

Installation is via a downloadable ISO, now on the 3.x release line. The Eval mode runs on a single machine and is the one the project itself describes as meant for homelab installations on a budget. The hardware table lists 4 CPU cores, 8 GB of RAM, 200 GB of disk and 2 NICs (one for management, one to sniff) as the bare minimum for Eval, and warns that requirements climb fast as you enable services. Treat 16 GB as the comfortable number. Disk matters more here than in any other tool on this list because it stores full packet captures by default.

One licensing note: Security Onion is free, but its own components and the bundled Elastic components ship under the Elastic License 2.0, so it belongs in the free column rather than the open source one.

What Security Onion teaches is the network investigation workflow. You will write Suricata rules (which are syntactically close to Snort rules, still the industry standard), read Zeek logs to reconstruct session-level activity, correlate DNS queries with connection logs, and extract artifacts from captured traffic. When initial access was a drive-by compromise, that artifact is the payload the page served, and the request that fetched it is often the clearest record of how the host got infected. The payload was sitting on that page before your user ever browsed there, which ATT&CK tracks as staging capabilities: carving the file out of the capture gives you the staged artifact's hash and URL, and retro-hunting both across the rest of your stored traffic answers the question that scopes the incident, whether anyone else fetched it. Pivoting from an alert to a full packet capture for the same session is a skill tier-2 analysts use constantly, and Security Onion makes it straightforward to practice.

The Security Onion documentation is organized by use case rather than by component, which makes it approachable. For help, the Security Onion discussions on GitHub are the community support channel the docs point you to.

Best for: Analysts who want to build network forensics depth, particularly those targeting NSM or tier-2 investigation roles.

Security Onion →

3. Elastic Security (Free Basic Tier)

Elastic Security is the SIEM and security analytics layer built into the Elastic Stack, available at no cost in the self-hosted Basic tier.

Elastic Security is not a separate product. It is a set of capabilities built into Kibana and the Elastic Stack that you enable when you stand up your own Elasticsearch cluster. The free tier gives you the core SIEM features: timeline investigation, detection rules (including pre-built rules mapped to MITRE ATT&CK), case management, and the full power of the EQL (Event Query Language) query engine. Elastic's pre-built detection rules are published on GitHub and actively maintained. The downloads ship under the Elastic License, so this one is free rather than open source, even though the free parts of the source are now also offered under AGPLv3.

A minimal single-node Elastic Stack deployment can be stood up with Docker:

# Elastic's start-local script: Elasticsearch + Kibana on localhost, local testing only
curl -fsSL https://elastic.co/start-local | sh

Read the start-local README before you rely on it. It is for local testing only, runs with HTTPS disabled, and starts with a one-month license that unlocks every paid feature before falling back to the free Basic tier. Build your detections against what Basic includes, or some of what you lean on will disappear a month in.

The honest hardware caveat is that Elasticsearch is memory-hungry. The script itself only asks for Docker and 5 GB of free disk, but a lab machine that runs the full stack plus agents is comfortable at 16 GB of total RAM. That makes it more demanding than Wazuh but less demanding than Security Onion at full packet capture scale.

What Elastic Security teaches is EQL, one of the most transferable detection skills you can develop. Splunk uses SPL, Sentinel uses KQL, and Elastic uses EQL, but the underlying pattern-based event correlation model is the same across all of them. Learning to write an EQL sequence query that links a parent process to a network connection to a file write teaches how behavioral detection works at a level that transfers to every other platform. That same shape is how exploitation of a client application reads in logs: the exploit itself leaves little, and the trail is a document reader spawning a child, calling out, then dropping a file. Sequences earn their keep again on indirect command execution, where the payload starts under forfiles.exe or pcalua.exe. The launch itself is one event: the launcher and its child sit in the same process-creation record, which is exactly what a single-event rule matches. What the sequence adds is the rest of the story, whether that child then called out or wrote a file, which separates a delivery step from a maintenance script. The Elastic Security documentation covers the query language thoroughly.

Best for: Analysts who want to understand enterprise SIEM internals and query-language-based detection. Good second step after Wazuh.

Elastic Security →

4. OpenSearch Security Analytics

OpenSearch Security Analytics is the SIEM plugin of OpenSearch, the Apache 2.0 fork of Elasticsearch, and the one tool on this list that runs Sigma rules natively.

OpenSearch doesn't market itself as a SIEM, which makes it easy to overlook. Security Analytics ships with every OpenSearch distribution and uses prepackaged, open source Sigma rules as its detection content. You create a detector for a log type (Windows, DNS, CloudTrail, network and others), map your index fields to the Sigma rule fields, and the detector raises findings and alerts. Rules you write or import in Sigma format run as they are, with no conversion step.

Most of the work is field mapping. OpenSearch derives the rule field names from the Sigma standard and aliases them to the Elastic Common Schema, with OCSF for CloudTrail, DNS and VPC Flow Logs. Getting a detector to fire means understanding exactly which field in your raw logs a rule expects, and that is the same normalization problem every SIEM migration runs into.

The official quickstart is Docker Compose:

sudo sysctl -w vm.max_map_count=262144
curl -O https://raw.githubusercontent.com/opensearch-project/documentation-website/3.8/assets/examples/docker-compose.yml
echo "OPENSEARCH_INITIAL_ADMIN_PASSWORD=<a-strong-password>" > .env
docker compose up -d

That brings up a two-node cluster plus OpenSearch Dashboards on port 5601, with the Security Analytics plugin already installed. Log in as admin with the password you set. The sample file pins each node's Java heap at 512 MB, and the docs ask Docker Desktop users to give Docker at least 4 GB of host memory. Plan for 8 GB on the host so there is room left for log shippers.

Best for: Analysts who want to write and test Sigma rules against real log fields, and anyone who wants a fully Apache-licensed stack.

OpenSearch Security Analytics →

5. Graylog Open

Graylog Open is a free, source-available log management platform focused on high-throughput log ingestion, structured search, and alert-driven workflows.

Graylog takes a different approach than Wazuh or Elastic. Its strength is log management at volume: it ingests from virtually anything (syslog, GELF, Beats, REST API, Kafka), provides fast full-text search on an OpenSearch-based backend, and exposes a clean pipeline-based processing model that lets you parse, enrich, and route logs before they land in the index. The alerting system is built around saved searches and event definitions rather than pre-built rule sets.

Graylog Open is self-hosted and free, licensed under the Server Side Public License rather than an OSI license. The commercial editions add compliance reporting and security content, but the Open edition is capable for lab use. The Docker installation guide recommends starting from Graylog's example Compose file, which runs three containers: MongoDB, Graylog Data Node (the search backend) and the Graylog server.

What Graylog teaches is log pipeline architecture. Understanding how to normalize logs from different sources into a consistent schema, how to write pipeline rules that parse custom log formats, and how to route high-volume log streams to different indexes based on content are skills that apply directly to detection engineering and SIEM administration roles. The alert workflow teaches event correlation at the search level rather than through a pre-built rule engine, which develops a different and valuable muscle.

Best for: Analysts interested in detection engineering or SIEM administration, and anyone who wants to understand log normalization pipelines.

Graylog Open →

6. OSSEC

OSSEC is a veteran open source host-based intrusion detection system (HIDS) that pioneered many concepts now standard in modern SIEMs.

OSSEC predates most of the platforms on this list by a decade. It covers file integrity monitoring, log analysis, rootkit detection, and active response (automatically blocking IPs, disabling accounts) from a central manager with agents deployed on endpoints. OSSEC's rule syntax is the direct ancestor of Wazuh's, which is not coincidental: Wazuh started as an OSSEC fork.

The installation story is more manual than Wazuh or Elastic. There is no first-class Docker deployment; you compile from source or install from packages. The web interface options (Kibana integration, Splunk app) are community-maintained and less polished than in newer platforms. Hardware requirements are light: OSSEC itself is deliberately minimal.

What OSSEC teaches is the HIDS conceptual foundation. Log decoding, rule grouping, alert levels, and active response are all concepts you will encounter in every modern SIEM, and OSSEC exposes them with less abstraction than Wazuh does. If you want to understand why a rule fires, reading OSSEC's rule files is a better tutorial than any documentation. The active response module teaches you how automated remediation decisions work, which is relevant to SOAR platforms.

Best for: Analysts who want to understand HIDS fundamentals at the source level, or who are specifically studying OSSEC deployments in legacy environments.

OSSEC →

7. Clear NDR Community (formerly SELKS)

Clear NDR Community is Stamus Networks' free, GPLv3 network detection platform built around Suricata, and the successor to the SELKS distribution.

If you followed an older home lab guide that told you to boot SELKS, this is where it went. Stamus Networks replaced SELKS with Clear NDR Community, which keeps the idea (Suricata plus a ready-made UI for hunting through its output) and swaps the parts: OpenSearch instead of Elasticsearch, Fluentd for collection, Arkime for packet capture, EveBox for alert triage, and Scirius for ruleset management. It is deliberately focused on intrusion detection and network monitoring rather than broad SIEM functionality.

Installation is Docker-first. You download the stamusctl binary, run stamusctl compose init (it asks which interface to sniff), then stamusctl compose up -d. The getting-started guide sets the floor at 2 cores and 9 GB of memory, amd64 only, so a Raspberry Pi or an Apple Silicon VM is out. Stamus lists a Debian-based ISO as coming soon, for anyone who wants a dedicated sensor box.

What it teaches is Suricata rule writing. Suricata rules (in the Snort rule format) are the most widely deployed open source network detection signature format in the world. Writing a rule that matches a specific HTTP user agent, TLS certificate field, or DNS response pattern is a skill that applies to commercial NGFWs, IDS appliances, and cloud-native detection platforms. Scirius lets you enable, disable and tune rules from the browser.

Best for: Analysts focused on network intrusion detection, rule writing, and traffic analysis.

Clear NDR Community →

Others Worth Knowing (and One to Skip)

UTMStack is an AGPLv3 platform that combines SIEM and XDR, with correlation rules kept in a public repository. It is actively developed (v11 in 2026), but it is sized for small organizations rather than laptops: the installation notes start at 4 cores, 16 GB of RAM and 150 GB of disk on Ubuntu 22.04 for 50 data sources. Worth a look once your lab has a dedicated server.

AlienVault OSSIM still tops a lot of "open source SIEM" lists, and it shouldn't. LevelBlue (the former AT&T Cybersecurity) retired it, and the company's own blog carries the note that "OSSIM is no longer in use". Don't build a 2026 lab on an unmaintained appliance. The Open Threat Exchange threat intelligence feed that made OSSIM distinctive is still online.

Self-Hosting Checklist: Linux, Docker and Memory

Almost every stack above is containerized now, and they fail in the same few places:

• vm.max_map_count. Anything built on OpenSearch or Elasticsearch (Wazuh's indexer, OpenSearch, Graylog Data Node) needs the kernel limit raised to 262144. The Wazuh, OpenSearch and Graylog Docker guides all call for it; add it to /etc/sysctl.conf so it survives a reboot.
• Windows hosts. Run the stack inside WSL 2 with Docker Desktop, and set the sysctl inside WSL, not in PowerShell.
• CPU architecture. Wazuh and OpenSearch publish ARM64 images. Clear NDR Community is amd64 only.
• A second NIC for network tools. Security Onion Eval and Clear NDR want an interface that only listens to a SPAN port or tap. A managed switch with port mirroring is the cheapest way to feed one.
• Default credentials. Wazuh ships admin / SecretPassword; OpenSearch makes you set one in .env. Change or set them before anything outside your lab can reach port 443 or 5601.

Comparison Table

The Wazuh, Security Onion and Clear NDR memory figures are the vendors' documented minimums. The rest are our sizing for a single-node lab with a handful of endpoints, since those projects don't publish a lab floor.

The Honest Case for a Home Lab (And Its Limits)

Running your own SIEM teaches you things that no training platform can fully replicate: dependency hell, disk pressure at 3 AM, a misconfigured parser that silently drops 40% of your events. Operational friction is a feature. It is the same friction you will encounter in production, compressed into a low-stakes environment.

At the same time, the home lab has a structural gap that matters for your career preparation. It trains you to maintain tooling, not to triage alerts at volume. Real SOC work is not about keeping the SIEM running. It is about processing a queue of several hundred alerts per shift with enough speed and accuracy to separate the handful of real threats from the noise. That skill requires a different kind of practice: repetitions on realistic alert queues, with verdict feedback, at realistic base rates.

Both skills are necessary. The SOCSimulator training environment is designed for the triage side of that equation: realistic SIEM, XDR, and firewall alerts in a queue you actually have to work, scored against the same verdicts a real analyst would make. Run it alongside your lab. The home lab builds the infrastructure understanding, the simulated console builds the triage instinct, and neither substitutes for the other.

For more on how triage skill develops in practice, the alert triage guide covers the framework in detail. If you are still mapping out your path to a SOC role, the how to become a SOC analyst guide covers the broader roadmap, and the best SIEM tools comparison covers the commercial landscape you will encounter once you are employed.