Listen to this Post
Introduction:
Security Information and Event Management (SIEM) platforms like Splunk are critical for enterprise threat detection, but building a realistic multi-node cluster typically requires expensive hardware or cloud instances. By combining consumer-grade PCs, free virtualization, Zero Trust Network Access (ZTNA), and a Raspberry Pi for out-of-band management, you can create a fully functional Splunk lab with 14 virtual machines that mimics a production enterprise environment—all while keeping electricity costs near zero by powering it down when not in use.
Learning Objectives:
- Deploy a distributed Splunk Enterprise cluster (Cluster Manager, Indexers, Search Heads, Heavy Forwarders) on VMware Workstation with bridge networking and static DHCP.
- Implement secure remote access using Twingate ZTNA without opening any inbound firewall ports, plus Wake-on-LAN via Raspberry Pi.
- Harden Linux/Windows VMs against unauthorized access (disable root login, enforce key-based SSH, configure EDR firewall rules).
You Should Know:
- Hardware & Network Foundation: Bridge Mode, Static MAC Binding, and Firewall Segmentation
The lab uses two physical PCs running VMware Workstation Pro. All VMs are connected via virtual network adapters in bridge mode, allowing each VM to obtain an IP directly from the home firewall (Checkpoint). The firewall’s DHCP server assigns static IPs based on MAC addresses. The host PC cannot reach the VMs via the bridged network; only a separate “host-only” adapter allows local access. For remote access, the author uses another PC on a different network (even different cities).
Step‑by‑step guide:
- In VMware, set each VM’s network adapter to “Bridged” (not NAT or Host-only).
- On your firewall/router, note each VM’s MAC address (e.g., `ip a` or `ifconfig` on Linux, `ipconfig /all` on Windows).
- Configure static DHCP leases: map each MAC to a fixed IP (e.g., 192.168.1.100–192.168.1.120).
- On the firewall, create rules to allow traffic only on required ports between VMs (e.g., Splunk management port 8089, indexing port 9997, KV store 8191).
- To isolate the host from VMs (security best practice), add a second virtual NIC in “Host-only” mode on the host PC. Use that interface for local management.
Commands to verify bridge mode on Linux VM:
Show bridge interfaces bridge link show List IPs and confirm they belong to your main LAN subnet ip addr show Test connectivity to another VM ping 192.168.1.101
Windows command to check network adapter status:
wmic nic where "NetEnabled=true" get Name, Index, MACAddress
- Wake-on-LAN (WoL) with Raspberry Pi for Remote Power Management
The physical PCs are shut down most of the time to save power. A Raspberry Pi (configured to auto‑power on after an outage) stays awake and receives WoL magic packets. The author uses Zoho Assist for remote control, but any WoL sender works.
Step‑by‑step guide:
- Enable WoL in your PC’s BIOS (look for “Wake on LAN” or “Power On by PCIe”).
- In Windows, enable WoL in network adapter properties: Device Manager → Network Adapter → Power Management → “Allow this device to wake the computer”.
- On the Raspberry Pi (running Raspberry Pi OS), install `wol` or
etherwake:sudo apt update && sudo apt install etherwake
- Send a magic packet to the target PC’s MAC address:
sudo etherwake -i eth0 00:11:22:33:44:55
- To automate, create a systemd service that listens for a trigger (e.g., SSH command) or run Zoho Assist’s remote power-on feature.
Alternative using Python script on RPi:
import socket
def send_magic_packet(mac):
data = b'\xff' 6 + (bytes.fromhex(mac.replace(':', '')) 16)
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.sendto(data, ('<broadcast>', 9))
send_magic_packet("00:11:22:33:44:55")
- Zero Trust Remote Access with Twingate ZTNA (No Open Firewall Ports)
Instead of exposing the lab to the internet with port forwarding, the author installed a Twingate Connector on a Linux VM that acts as an outbound‑only gateway. The Twingate service creates encrypted tunnels, and the user connects selectively to web interfaces and SSH via their laptop. DNS entries point to local IPs, and self‑signed certificates are used for Splunk web traffic.
Step‑by‑step guide:
- Sign up for a free Twingate account (developer tier).
- Deploy a Linux VM (Ubuntu 20.04+) – this will run the Connector.
3. Install Docker, then run the Twingate Connector:
curl -s https://binaries.twingate.com/client/linux/install.sh | sudo bash sudo twingate setup --network=your_network_name --token=YOUR_TOKEN
(Or use the Docker image: docker run -e TWINGATE_NETWORK=... -e TWINGATE_ACCESS_TOKEN=... twingate/connector)
4. In Twingate Admin Console, define “Resources” – e.g., Splunk web UI at https://splunk-sh.local:8000`, SSH atssh://splunk-idx1.local:22`.
5. On the firewall, ensure outbound HTTPS to Twingate domains is allowed (disable DPI for these domains to avoid SSL inspection breaks).
6. On the client laptop, install the Twingate client and authenticate. You can now reach your lab resources securely without any inbound firewall rule.
Security hardening:
- On the Linux Connector VM, restrict root login and use key‑based authentication only (edit
/etc/ssh/sshd_config):PermitRootLogin no PasswordAuthentication no
- Generate and copy SSH key:
ssh-keygen -t ed25519 ssh-copy-id -i ~/.ssh/id_ed25519.pub user@connector-vm
- Splunk Cluster Architecture on 14 VMs: Roles, Commands, and Self-Signed Certs
The lab includes: Cluster Manager, 3 Indexers, Deployer, 3 Search Heads (with Enterprise Security 8.3), Heavy Forwarder, Deployment Server, SC4S (Syslog Connector for Splunk), License Manager + Monitoring Console, plus log‑generating Linux and Windows VMs. Each VM uses a self‑signed certificate mapped to a local DNS record on the firewall.
Step‑by‑step guide to configure a Search Head:
1. Install Splunk Enterprise via `.deb` or `.rpm`:
wget -O splunk.tgz 'https://download.splunk.com/products/splunk/releases/9.0.0/linux/splunk-9.0.0-xxx-Linux-x86_64.tgz' tar -xzvf splunk.tgz -C /opt
2. Start Splunk and accept license:
cd /opt/splunk/bin ./splunk start --accept-license
3. Enable boot‑start:
./splunk enable boot-start -user splunk
4. Configure as a Search Head in a cluster:
./splunk set deploy-poll <deployer_IP>:8089 ./splunk set indexing-disabled true Search heads should not index
5. Generate a self‑signed certificate for the local domain (e.g., sh1.lab.local):
openssl req -x509 -newkey rsa:4096 -keyout sh1.key -out sh1.crt -days 365 -nodes -subj "/CN=sh1.lab.local"
6. Configure Splunk web to use the cert: edit $SPLUNK_HOME/etc/system/local/web.conf:
[bash] enableSplunkWebSSL = true privKeyPath = /opt/splunk/etc/auth/sh1.key serverCert = /opt/splunk/etc/auth/sh1.crt
7. Restart Splunk: `./splunk restart`
Cluster Manager configuration snippet (on CM):
./splunk edit cluster-config -mode master -replication_factor 3 -search_factor 2 -auth admin:pass ./splunk restart
On each Indexer:
./splunk edit cluster-config -mode slave -master_uri https://cm.lab.local:8089
- Log Ingestion: Heavy Forwarder, SC4S, and Air‑Gapped Simulation
One Linux VM sends logs via Universal Forwarder (UF) to a Heavy Forwarder (HF), and also via rsyslog to SC4S. A Windows VM runs SolarWinds Event Forwarder to a Kiwi syslog server, which then forwards to SC4S – simulating an air‑gapped environment where logs must hop through intermediate systems.
Step‑by‑step for UF to HF:
1. On the Linux log generator, install UF:
./splunk install -mode universal-forwarder -answer-file answers.txt
2. Configure outputs to HF:
./splunk add forward-server hf.lab.local:9997 -auth admin:pass
3. Add a monitor for `/var/log/syslog`:
./splunk add monitor /var/log/syslog -index main
For SC4S (Splunk Connect for Syslog) – run as Docker container:
docker run -p 514:514/udp -p 6514:6514/tcp \ -e SPLUNK_HEC_URL=https://hec.splunkcloud.com:8088/services/collector \ -e SPLUNK_HEC_TOKEN=your_token \ -e SC4S_DEST_SPLUNK_HEC_GLOBAL=true \ splunk/sc4s:latest
Windows firewall rule to allow syslog outbound:
New-NetFirewallRule -DisplayName "Allow Syslog" -Direction Outbound -Protocol UDP -LocalPort 514 -Action Allow
- Home User Alternative: Wazuh on AWS EC2 with Custom Rules
The author notes that for home users, Splunk’s free license has severe limitations (500 MB/day indexing, no authentication, no clustering). Instead, he recommends Wazuh – an open‑source SIEM. His personal family monitoring setup runs Wazuh on an AWS EC2 t3.medium (minimum 8 GB RAM, 2 vCPUs) with over 500 custom rules published on his GitHub.
Step‑by‑step to deploy Wazuh on EC2 (Ubuntu 22.04):
- Launch EC2 (t3.large for production, t3.medium for testing) with 20 GB SSD.
- SSH into the instance and run the quickstart installer:
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh sudo bash wazuh-install.sh --generate-config-files sudo bash wazuh-install.sh --wazuh-indexer node-1 sudo bash wazuh-install.sh --start-cluster
- Access Wazuh dashboard at `https://
:443` (default credentials: admin/admin). - Install Wazuh agent on a home Linux machine:
curl -s https://packages.wazuh.com/4.x/install-agent.sh | bash sudo /var/ossec/bin/agent-auth -m <WAZUH_SERVER_IP> -A home-pc sudo systemctl restart wazuh-agent
- Add custom rules (e.g., SSH brute force detection) to `/var/ossec/etc/rules/local_rules.xml` and restart manager.
Resource monitoring commands:
Check memory and CPU usage on Wazuh server htop free -h Check agent connection status /var/ossec/bin/agent_control -l
What Undercode Say:
- Key Takeaway 1: An enterprise‑grade Splunk cluster with 14 VMs can run on two refurbished PCs by leveraging bridge networking, static DHCP, and out‑of‑band WoL – no cloud costs required. The key innovation is separating management traffic (host‑only) from lab traffic (bridged) to prevent accidental interference.
- Key Takeaway 2: Zero Trust Network Access (ZTNA) tools like Twingate eliminate the need to open firewall ports or expose SSH/RDP to the internet, while enabling seamless remote access from anywhere. Combined with a Raspberry Pi as a persistent WoL gateway, you get a secure, power‑efficient home lab that behaves like a production environment.
Analysis (10 lines): The post demonstrates a shift in how security professionals build home labs: away from always‑on cloud instances that incur monthly fees, and toward hybrid architectures where physical hardware is powered only when needed. By integrating ZTNA, the author solves the classic “remote access” problem without compromising security – a critical lesson for SOC analysts who need to test correlation rules on realistic data volumes. The use of self‑signed certificates mapped to local DNS shows awareness of TLS hygiene even in isolated environments. For home users, the frank comparison with Wazuh provides a practical alternative for those without Splunk dev licenses. The Raspberry Pi as a WoL proxy is a low‑cost, high‑impact technique worth adopting. This blueprint can be replicated for other SIEMs (QRadar, Sentinel) or even cyber ranges for red/blue team training.
Expected Output:
After following the above steps, you will have:
- A 14‑VM Splunk cluster with cluster manager, three indexers, three search heads (Enterprise Security enabled), heavy forwarder, deployment server, SC4S, and log generators.
- Remote wake‑on‑LAN capability via a Raspberry Pi that survives power outages.
- Zero‑trust remote access through Twingate, accessing Splunk Web and SSH without any inbound firewall rules.
- Hardened Linux VMs with root login disabled, key‑only SSH, and outbound‑only connectivity for the Twingate connector.
- (Optional) A Wazuh SIEM on AWS EC2 for family/homelab monitoring, with 500+ custom detection rules.
Prediction:
As cloud costs continue to rise, we will see more security engineers adopt hybrid home labs combining cheap physical hardware, ZTNA, and orchestration scripts (Ansible/Terraform) to provision SIEM clusters on demand. Twingate, Tailscale, and Cloudflare Tunnel will replace traditional VPNs for lab access. Meanwhile, open‑source SIEMs like Wazuh and OpenSearch will erode Splunk’s dominance in the training and testing space, forcing Splunk to offer more generous developer licenses or lightweight containerized editions. The Raspberry Pi’s role will expand from WoL gateway to full‑fledged out‑of‑band management controller (like a poor man’s iDRAC), enabling global remote power cycling and OS recovery. Ultimately, these DIY approaches will lower the barrier to entry for aspiring SOC analysts, democratizing enterprise‑grade security training.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Nir Roitman – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
