I’ve spent years on the defensive side of firewall logs, IDS alerts, and manual log pulls, but very little hands-on time with a proper SIEM. Splunk shows up in nearly every security architecture diagram and every “tools you should know” list. I wanted to actually use one, not just read about it. So I decided to build a lab and find out what it’s like from the inside.
The plan was simple. An old ASUS VivoBook 15 (AMD R7-3700U, 8GB RAM, 512GB SSD) becomes a dedicated SIEM server running Proxmox as a bare-metal hypervisor. My M5 MacBook Pro runs Kali through UTM as the attacker side. Defender and attacker, cleanly separated, a small self-contained range to break things and watch what the logs say about it.
Day one did not go as planned. Day one went considerably longer than planned. Here’s what happened.
The BIOS That Did Not Want to Cooperate
Step one of any Proxmox install is getting into the BIOS to boot from USB. Step one took about forty-five minutes.
ASUS Fast Boot apparently means “fast boot, and also no, you may not press F2.” Or Esc. Or F12. I mashed every function key combination known to laptop manufacturers and got nothing but a Windows login screen that loaded faster than my keystrokes could register.
The fix, eventually: boot into Windows, hold Shift, click Restart, and navigate to UEFI Firmware Settings from the recovery menu. From there, Secure Boot off, boot order changed, and we were finally looking at a Proxmox installer.
Forty-five minutes to press a button that didn’t want to be pressed. Welcome to home labbing.
The Backup I Almost Skipped
Installer running, options selected, about to commit to wiping the drive, and I had a thought: did I actually back up anything on this laptop first?
I had not.
Paused the install mid-stream, backed up photos, code, and documents to external storage, then went back and finished. This is the kind of thing that’s obvious in retrospect and very easy to skip in the moment when you’re three steps into an install and feeling momentum. Five minutes of backup versus however many hours of “wait, was that file actually important” later. Worth the pause.
The Great Ethernet Adapter Hunt
The VivoBook has no ethernet port. Obviously. It’s 2026, nobody puts ethernet ports on laptops anymore, and Proxmox really wants a wired connection during initial network configuration.
USB-C to ethernet adapter number one: dead. Not “doesn’t work with Proxmox,” just dead. A 10Mbps relic that I think predates some of the cables I own.
Several adapters later, a multi-port USB-C dock finally gave Proxmox a network interface it was happy with. I now own what feels like a small museum of USB-to-ethernet adapters, spanning multiple speed ratings and at least two form factors, exactly one of which works reliably.
The Enterprise Repo 401s
With Proxmox installed and networked, the next obstacle was apt update throwing 401 errors against the enterprise repositories. Proxmox VE without a subscription doesn’t have access to the enterprise repos, which is expected, but Proxmox 9 switched to the new .sources deb822 format, so the fix isn’t quite the same as older guides describe.
The fix: remove pve-enterprise.sources and ceph.sources from /etc/apt/sources.list.d/, leaving only the no-subscription repo. Updates started working immediately after.
Lid Closed, Lights On
Since this is now a headless server living under a desk, closing the lid without the whole thing going to sleep was non-negotiable. A quick edit to /etc/systemd/logind.conf to set the lid switch behavior to ignore, and the VivoBook now runs as a small, warm, slightly confused box that thinks it’s still a laptop but behaves like a server.
Splunk, Finally
Created a Debian 13 VM inside Proxmox, installed Splunk Enterprise 10.4.0. Hit the now-standard “running as root is deprecated” warning, sidestepped it with --run-as-root for now, a “for now” that I’m aware is doing a lot of work in that sentence, and will need a proper service account setup eventually.
Then static IP configuration, which should have been a five-minute task. DHCP kept reasserting itself after every reboot, no matter what I changed in the interfaces config. Turned out the ifupdown changes needed a full reboot to actually take, not just a network service restart. One more reboot, problem solved, lesson filed away for next time: when network config changes don’t seem to stick, the answer might just be “did you actually reboot.”
The Reboot That Made My Stomach Drop
Partway through swapping ethernet adapters (see: the museum), the entire Proxmox host went unreachable. Not the VM. Not Splunk. The hypervisor itself, gone, no web UI, no ping, nothing.
For about five minutes I sat there running through worst-case scenarios. Corrupted install. Bad USB enumeration taking down something critical. A very bad afternoon ahead of me.
It was USB enumeration taking down something, just not critical enough to require a reinstall. A host reboot brought everything back clean, Proxmox and the Splunk VM both intact. Whatever got confused during the adapter swap got un-confused by a restart. I’m choosing to interpret this as the universe’s way of testing whether I’d actually documented anything yet. I had, mostly.
The Win
After all of that: configured rsyslog on the Proxmox host to forward logs via UDP 514, set up a corresponding UDP input in Splunk, and watched live syslog data start flowing in.
First real data in the SIEM. Small thing, technically. Everything up to this point was infrastructure, plumbing, getting the box to a state where it could do the one thing it exists to do. Watching log entries actually appear in Splunk’s search interface, in real time, from a system I built from a dead laptop and a pile of mismatched adapters, was a genuinely good moment.
To Be Continued
The attacker side is not yet online. Kali 2026.1 ARM64 running through UTM on the MacBook is currently stuck on a display and boot hang that I have not solved. That’s a problem for next time.
Defender side: built, networked, ingesting logs. Attacker side: a black screen and my patience running thin. Part 2 when Kali decides to cooperate.
This is part of an ongoing series documenting a home lab build for hands-on SIEM and security tooling experience. Posts will follow as the lab develops.