Setting Up a Home SIEM with Splunk: My Hands-On Guide

One of the most valuable skills you can build as a cybersecurity student — or professional — is knowing how to set up and use a SIEM. Security Information and Event Management tools are the nerve center of any SOC (Security Operations Center). They ingest logs from across your environment, correlate events, and surface the signals that matter from the noise.

I set up my own Splunk environment at home while studying for my Google Cybersecurity Certificate, and later expanded it significantly in my coursework at Boston University. Here's exactly how I did it and what I learned along the way.

Why Splunk?

There are several SIEM options out there — Elastic SIEM, IBM QRadar, Microsoft Sentinel, Wazuh. I chose Splunk for several reasons:

1. Industry prevalence: Splunk is widely deployed in enterprise environments. Job postings for SOC analysts and security engineers consistently list Splunk as a required skill.
2. Free tier: Splunk offers a free license that allows up to 500MB of data ingestion per day — more than enough for a home lab.
3. Ecosystem: The Splunk app marketplace (Splunkbase) has hundreds of pre-built apps for threat intelligence, compliance reporting, and technology-specific log parsing.
4. Documentation: Splunk's documentation and community are excellent.

Architecture Overview

For a home SIEM lab, you need three components:

• Splunk Enterprise: The core platform — log ingestion, indexing, search, dashboards, and alerting
• Universal Forwarders: Lightweight agents installed on endpoints that forward logs to Splunk
• Data Sources: The systems and applications generating logs you want to monitor

My home lab setup:

• Splunk Enterprise running on a Ubuntu 22.04 VM (4 cores, 8GB RAM, 50GB disk)
• Universal Forwarders on two additional VMs: a Windows 10 machine and a Kali Linux instance
• Syslog inputs from a pfSense firewall

Installation

Setting Up Splunk Enterprise

Download Splunk Enterprise from splunk.com (free account required). On Ubuntu:

wget -O splunk-enterprise.deb 'https://download.splunk.com/...'
sudo dpkg -i splunk-enterprise.deb
sudo /opt/splunk/bin/splunk start --accept-license

Splunk will start and be accessible at http://localhost:8000. Set your admin credentials on first login.

Installing Universal Forwarders

On your endpoint machines, install the Universal Forwarder:

# On Linux
wget -O splunkforwarder.deb 'https://download.splunk.com/...'
sudo dpkg -i splunkforwarder.deb
sudo /opt/splunkforwarder/bin/splunk start --accept-license --answer-yes --gen-and-print-passwd

Then configure the forwarder to send data to your Splunk server:

sudo /opt/splunkforwarder/bin/splunk add forward-server YOUR_SPLUNK_IP:9997

Enable receiving on the Splunk server side under Settings > Forwarding and Receiving > Configure Receiving > New Receiving Port > 9997.

Configuring Data Inputs

The real value of a SIEM comes from what you feed it. Here's what I ingest in my home lab:

Linux System Logs

Add a monitor stanza in /opt/splunkforwarder/etc/system/local/inputs.conf:

[monitor:///var/log/auth.log]
index = linux_logs
sourcetype = linux_secure

[monitor:///var/log/syslog]
index = linux_logs
sourcetype = syslog

These capture authentication events (login attempts, sudo usage, SSH sessions) and general system activity.

Windows Event Logs

For the Windows VM, the Universal Forwarder automatically picks up Windows Event Logs when you configure it. I specifically monitor:

• Security Event Log (authentication, account management, policy changes)
• System Event Log (service start/stop, driver issues)
• Application Event Log (application errors and warnings)

Firewall Logs

pfSense can send syslog data directly to Splunk. Under Services > System Logs in pfSense, set the remote log host to your Splunk IP on port 514. Then in Splunk, add a UDP 514 listener under Settings > Data Inputs > UDP.

Building Useful Searches

Splunk's query language is SPL (Search Processing Language). Here are searches I use regularly:

Failed SSH login attempts:

index=linux_logs sourcetype=linux_secure "Failed password"
| stats count by src_ip, user
| sort -count

Windows logon failures:

index=windows EventCode=4625
| stats count by Account_Name, Workstation_Name, Failure_Reason
| sort -count

Port scan detection from firewall logs:

index=firewall_logs action=block
| stats dc(dest_port) as port_count by src_ip
| where port_count > 20
| sort -port_count

Sudo command usage (for insider threat monitoring):

index=linux_logs sourcetype=linux_secure "sudo"
| rex "sudo:\s+(?<user>\w+)\s.*COMMAND=(?<command>.+)"
| table _time, host, user, command

Creating Alerts

Searches are powerful, but manual searching isn't scalable. Alerts run your searches on a schedule and notify you when conditions are met.

In Splunk, save any search as an Alert:

1. Run your search
2. Click Save As > Alert
3. Set schedule (e.g., every 5 minutes, or in real time)
4. Define trigger conditions (e.g., number of results > 0)
5. Set alert action (email, webhook, log to index)

Alerts I have configured:

• Brute Force: More than 10 failed logins from a single IP in 5 minutes
• Privilege Escalation: Any sudo command execution on a production machine
• After-hours Access: Any successful login between midnight and 6am
• Large Data Transfer: Any outbound connection transferring more than 100MB

Dashboards

Dashboards make your SIEM operationally useful at a glance. I built a Security Overview dashboard with panels for:

• Login activity over the last 24 hours (line chart)
• Top talkers by source IP (bar chart)
• Recent failed authentications (table)
• Firewall blocks by country (choropleth map using the Lookup Editor app)
• Alert history (last 7 days)

Splunk's dashboard studio makes this fairly straightforward — drag panels, write SPL, and visualize.

What I Learned

Running this SIEM lab taught me things I couldn't learn from documentation alone.

Log volume is real: Even a small lab generates thousands of events per day. Without good searches and filtering, it's overwhelming. This is why alert tuning — reducing false positives without missing real threats — is a specialized skill.

Context matters more than events: A single failed login is noise. Fifty failed logins from the same IP against ten different accounts in two minutes is a credential stuffing attack. SIEMs find the signal by providing context — and building good context requires good data.

The gap between detection and response: My SIEM detects events. Acting on them — investigating, containing, remediating — requires a whole additional skillset. This is where incident response playbooks come in, and that's a topic for a separate post.

If you're a student looking to build practical blue team skills, I'd strongly encourage you to set up a SIEM lab. The time investment is worth it, and it gives you something concrete and technical to talk about in interviews.

---

My Splunk skills were further developed through the Google Cybersecurity Professional Certificate program and my coursework in Enterprise Cybersecurity Management at Boston University.