efficiency.love
← Field Notes
2026-02-19 · Security Lab · 6 min read

I locked the doors before I hung the cameras.

Nobody puts up security cameras in a house that still leaves the front door unlocked. This session was the boring, load-bearing half of a home lab: first I pulled every password out of my server-automation scripts, then I stood up the very first dashboard so the lab could actually watch itself. Neither job is glamorous. Both are the reason anything interesting can happen next.

There is a rite of passage in building a security lab, and it is not the fun part. Before you get to hunt for intruders, you have to stop being your own intruder. My automation was talking to a remote Ubuntu server over SSH (the encrypted remote-login channel, the tunnel you use to run commands on a machine that lives somewhere else) and that server runs Splunk Enterprise, the log-crunching engine at the heart of the lab. The problem was how my scripts were logging in. They were shoving a password down the pipe.

Three Python scripts were doing the same ugly thing: echo '{password}' | sudo -S, which literally pipes your admin password as plain text into a privileged command. Two problems, one pattern. The obvious one is that the password now lives in a command string where anything can read it, which is exactly the credential hygiene sin you are supposed to avoid: not leaving keys and passwords lying around. The subtler one is that this pattern looks so much like malware that it tripped my endpoint protection, which is the loose thread from an earlier Windows Defender false-positive investigation I still owed a fix on.

Killing the password out of the pipeline

The fix is the correct one, and it is old and dull, which is how you know it is right. Swap password login for key-based authentication: generate a cryptographic key pair, keep the private half on my machine, plant the public half on the server, and let the math prove who I am instead of a secret I have to keep typing. Then remove the need for a password on the privileged side entirely with passwordless sudo, scoped to the one automation user. No password anywhere in the pipeline means nothing to leak and nothing to look like malware.

the SSH hardening, start to finish
generate → ssh-keygen -t ed25519 -C "homelab-automation"
deploy key → public half → server authorized_keys
lock down → chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys
no password → /etc/sudoers.d/flux-nopasswd (flux NOPASSWD: ALL)
refactor → 3 scripts → paramiko key discovery, no more sudo -S
defender → Leonem!rfn alerts ActionSuccess: True, all cleared

The three offenders, ssh_diag.py, ssh_fix_secondbrain.py, and ssh_fix2.py, were rewritten to let paramiko (the Python SSH library) find the key on its own, so the password piping is simply gone. Then I closed the Defender thread properly: the earlier Trojan:Win32/Leonem!rfn alerts came back confirmed resolved, and I added a folder exclusion scoped to exactly the automation scripts directory and nothing wider. That last restraint matters. A broad exclusion would have been easier and would have blinded Defender across half my work. Least privilege means you carve the smallest hole that solves the problem.

Before you can hunt for an intruder, you have to stop being your own. Locking your own doors is the least glamorous engineering there is, and skipping it is how labs quietly rot.

Then I gave the lab its first eyes

Doors locked, now the cameras. A SOC dashboard (security operations center, the at-a-glance view a security team stares at all day) is where you go to see, in one screen, what is happening across your network. Mine lives inside the SIEM, the log-search-and-alert system, in this case Splunk, that hoovers up event logs and lets you query them. The lab had already been quietly collecting: 30,909 Windows event-log records were sitting in there waiting for someone to actually look at them, the bulk of them (28,577) security events, with system and application logs making up the rest.

So I built a four-panel dashboard aimed at the one question that matters most in a Windows Active Directory domain: who is logging in, and should they be? Each panel is a saved search over the exact events that tell that story.

SOC Overview: what the four panels watch
4625 → failed logins → 2, both from 192.168.56.1 (a clean baseline)
4624 → successful logins, human interactive only → Administrator
4672 → privileged activity → Administrator, 74 events
4624+4625 → logins over time → timechart, span 1h

The point of a first dashboard is not to catch an attacker on day one. It is to learn what normal looks like, so abnormal has something to stand out against. The failed-login panel found just two attempts, both from the VirtualBox host adapter on my own box, which is exactly the quiet you want: any real spike in failures would now mean someone is guessing passwords. The successful-login panel filters out machine-to-machine noise (the accounts ending in $, which are computers, not people) so only human logins surface, and the only human here is Administrator. The privileged-activity panel, machine accounts stripped out the same way, shows Administrator with 74 privilege grants across old sessions, which is boring, and boring is correct. The last panel just plots logins over time, and its bursts track exactly when I was working the lab, flat where the virtual machines were switched off.

Why the dull half is the real half

If you are reading this to size me up, here is the honest shape of it. Neither of these tasks is a headline. One was deleting passwords from three scripts; the other was four saved searches on a screen. But this is the work that everything else stands on. The hardening shrinks the attack surface and quiets the false alarms that were burying the real signal. The dashboard turns a pile of 30,909 unread logs into something a human can actually watch. Locking the doors and hanging the cameras, in that order, on purpose, because the interesting security work is meaningless until both are done.

// Security Lab is the honest story behind a home lab built in the open. Real systems, real logs, the unglamorous foundations left in on purpose. Migrated from an earlier security-lab writeup.

One entry in a longer build log.

See the build log
// or reach me at hello@efficiency.love