A SIEM is the centerpiece of almost every security home lab, and for good reason: it is where you see attacks happen, write detections and practice the work a security operations center (SOC) analyst does every day. The good news is that every serious option is free for home use. The real choice is about how much memory you have and what you want to learn.
This guide compares the free SIEMs people actually run at home, with the hardware each one needs, then walks through a weekend project that gets you from an empty server to your first detected attack. We build UTMStack, one of the options, so weigh our view with that in mind.
The short answer:
- Best all-in-one SOC experience: UTMStack, if you can give it 16 GB of memory.
- Lightest full SIEM: Wazuh, which runs in 8 GB.
- Best for network traffic and packet capture: Security Onion.
- Best for learning search and detection engineering: Elastic Security on the free Basic license.
- Best if you want the skill on job postings: Splunk Free, within its 500 MB a day limit.
- Best for plain log collection: Graylog Open.
The options at a glance
| SIEM | Memory to plan for | What you learn | Limits at home |
|---|---|---|---|
| UTMStack | 16 GB (4 cores, 150 GB disk) | Alerts, incidents, automated response, threat intelligence and compliance reports in one console | Wants a dedicated VM |
| Wazuh | 8 GB (4 vCPU, 50 GB disk) for up to 25 agents | Endpoint monitoring, file integrity, configuration checks | Response and cases need extra tools |
| Security Onion | 8 GB for evaluation; 24 GB or more for standalone | Network detection with Suricata and Zeek, packet capture, hunting | Heaviest of the group |
| Elastic Security | Depends on how you build it | Search, detection rules, investigation timeline | More assembly; some features paid |
| Splunk Free | Light | The Splunk search language | 500 MB a day, no alerting, single user |
| Graylog Open | Moderate | Log collection, parsing pipelines, dashboards | Correlation and Sigma rules are paid |
1. UTMStack
UTMStack gives you the closest thing to a real SOC console in one install: logs from agents, syslog and cloud accounts are checked against 600+ detection rules as they arrive, related events become one alert, alerts become incidents, and response flows can block an address or isolate a host through the agent. It also has a SQL-style log search, dashboards, and compliance reports, so you can see how monitoring turns into audit evidence.
- Hardware: 4 cores, 16 GB of memory and 150 GB of disk on Ubuntu 24.04 or a Red Hat compatible system. One installer sets everything up in 15 to 30 minutes.
- Why it is good for a lab: you practice the whole loop, detect, investigate, respond and report, without wiring five tools together.
- Trade-off: it wants a dedicated VM, and its community is smaller than Wazuh’s or Elastic’s.
Install the free edition, or try the live demo in your browser first.
2. Wazuh
Wazuh is the lightest complete option. Its agent watches files, configuration and installed software on each machine, and its quickstart sizes an all-in-one server at 4 vCPUs, 8 GB of memory and 50 GB of disk for up to 25 agents, which covers any home lab.
- Why it is good for a lab: low hardware needs, a huge community and lots of tutorials.
- Trade-off: rules are XML, and playbooks or case management mean adding tools such as Shuffle.
3. Security Onion
Security Onion is a whole Linux distribution for network security monitoring: Suricata alerts, Zeek metadata, full packet capture and an analyst console for hunting and cases.
- Hardware: the evaluation mode needs 4 cores, 8 GB of memory and 200 GB of disk, but it is not meant for real use; a standalone install needs 24 GB of memory or more.
- Why it is good for a lab: nothing else teaches network detection and packet analysis as well.
- Trade-off: it is the heaviest option, and it needs a network tap or a mirrored switch port to see traffic.
4. Elastic Security
Elastic’s free Basic license for self-managed deployments includes the detection engine, prebuilt detection rules, the investigation timeline and case management. Machine learning features need a paid subscription.
- Why it is good for a lab: detection engineering. Elastic’s public rule repository is a great way to learn how detections are written and tested.
- Trade-off: you assemble and size the stack yourself, and it uses memory generously.
5. Splunk Free
Splunk appears in a lot of SOC job postings, so many people want it in their lab. Splunk Free indexes up to 500 MB a day and never expires, but it has no alerting and no user accounts. Go over the limit more than three times in 30 days and search is disabled until you are back under.
- Why it is good for a lab: learning the Splunk search language.
- Trade-off: without alerting it is a search tool, not a working SIEM, and 500 MB a day fills quickly once a domain controller is sending logs.
6. Graylog Open
Graylog Open is quick to install and good at collecting, parsing and searching logs, with dashboards and basic alerting.
- Why it is good for a lab: learning log pipelines and parsing.
- Trade-off: correlation rules, Sigma rules and anomaly detection are in the paid Graylog Security edition.
Memory each SIEM needs at home
From each project's own sizing guide
What hardware do you need?
A single mini PC or used workstation with 32 GB of memory runs a useful lab; 64 GB lets you add Security Onion next to your main SIEM. A typical layout on a free hypervisor such as Proxmox VE:
| Virtual machine | Memory | Purpose |
|---|---|---|
| SIEM | 8 to 16 GB | UTMStack or Wazuh |
| Windows Server | 4 GB | Domain controller (Microsoft offers free evaluation copies) |
| Windows 11 client | 4 GB | A user’s workstation to attack |
| Linux server | 2 GB | A web server or SSH target |
| Virtual firewall | 1 to 2 GB | pfSense or OPNsense, sending logs over syslog |
A complete lab on one 32 GB machine
Everything that attacks or gets attacked stays on its own virtual network
Use SSD storage; SIEMs are disk-heavy. If your home router or gateway can forward logs over syslog, as many UniFi, pfSense and OPNsense setups can, point it at the SIEM too.
A weekend project: from empty server to first detection
The weekend plan
Six blocks from an empty server to your first detection
- Sat morningBuild the network
- Sat afternoonBuild a small domain
- Sat eveningInstall the SIEM and agents
- Sun morningTurn on the right logging
- Sun afternoonAttack yourself
- Sun eveningRespond and improve
Saturday morning: build the network. Create an isolated virtual network for the lab, with the virtual firewall as its gateway. Keep attack tools inside it, never on your home network or a work laptop. Take snapshots of every VM before you start.
Saturday afternoon: build a small domain. Promote the Windows Server to a domain controller, join the Windows 11 client, and create a few users, including one service account with a weak password for later.
Saturday evening: install the SIEM and its agents. Install your SIEM, then its agent on the domain controller, the client and the Linux server. Point the firewall’s syslog at the SIEM. Check that every source shows up and keeps sending.
Sunday morning: turn on the right logging. Default Windows auditing misses most attacks. Enable the Advanced Audit Policy settings for Kerberos, logons, account and group management and directory service changes on the domain controller; our list of Active Directory SIEM use cases shows which settings each detection needs.
Sunday afternoon: attack yourself. Atomic Red Team, an open source library of small attack tests maintained by Red Canary under the MIT license, maps each test to a MITRE ATT&CK technique. Good first tests:
- Brute force a user’s password against the domain (T1110).
- Kerberoast the weak service account (T1558.003).
- Dump credentials from LSASS memory on the client (T1003.001).
- Clear the Security log (T1070.001).
After each test, find the alert, open the raw events behind it, and write down what you saw.
Sunday evening: respond and improve. Set up an automated response, such as blocking the attacking address, and test it. Then write one custom rule for something the SIEM missed. That last step is the one interviewers ask about.
Ideas for your next projects
- Send Microsoft 365 or Google Workspace audit logs from a free developer tenant and detect suspicious inbox rules.
- Add Suricata or Zeek on the firewall to see network alerts next to endpoint ones.
- Build a dashboard of failed logons by country, and an alert for logons outside working hours.
- Run a compliance report and see which controls your lab fails, then fix them.
- Write up each project on a blog or GitHub. A documented lab is a strong answer to “tell me about your experience”.
Frequently asked questions
What is the best free SIEM for a home lab? UTMStack if you want a complete SOC workflow and have 16 GB of memory for it; Wazuh if you want the lightest full SIEM; Security Onion if network traffic is your focus.
How much RAM do I need for a SIEM home lab? 8 GB for Wazuh alone, 16 GB for UTMStack, and 24 GB or more for a standalone Security Onion. With a domain controller, a client and a firewall alongside, 32 GB for the whole lab is a comfortable minimum.
Can I run a SIEM on a Raspberry Pi? Not a full one. A Raspberry Pi can collect and forward logs, or run a lightweight intrusion detection sensor, but the SIEM itself needs more memory and fast disks.
Is Splunk Free enough for a home lab? For learning its search language, yes. For practicing detection and response, no: Splunk Free has no alerting and caps indexing at 500 MB a day.
Will a home lab SIEM help me get a SOC job? It helps most when you can explain what you built: which logs you collected, which attacks you ran, what fired, what did not, and what rule you wrote to close the gap.
