Home Security Lab

Doug Palmer

Planning for a home security lab to explore detection engineering

Home Security Lab

This post serves to provide a background, problem statement, and abstract solution to document the reasoning for the addition of a more comprehensive security stack in my home lab.

As I continue to learn more about cybersecurity fundamentals, I steadily became aware of how little visibility most home networks provide into their own security posture. Like many others, I initially underestimated how difficult it is to detect compromise without purposeful tooling. This really pushed me to start thinking about the design of
a home security lab focused on visibility, telemetry, and detection rather than perimeter defense alone.

This article serves as a foundational overview of a home security lab designed to explore detection engineering, network visibility, and security operations concepts. It’s going to serve as an informal sort of “project proposal” to hash out the general goals of the security infrastructure I want to build up in my home lab. It establishes architectural context and design intent for future, more focused projects.

A Home Lab in its Infancy

This section describes the initial state of the lab and the early architectural decisions that established basic segmentation and control. Configuration-level details are intentionally omitted.

Initial State and Early Decisions

In the not-too-distant past, my home network was an embarrassment. I was running a TP-Link router1 on an unsegmented network with a lot of default settings. I did change the credentials from the defaults, but that’s not near enough. I would say I was just a guy with average networking knowledge. I had some book knowledge, but at the time I had never really done anything. You could say I had surface-level understanding of networking at best. Something had to change.

The decision was easy to make: I could either shrug it off, which was becoming increasingly less likely as I learned more about different attack vectors and security fundamentals, or I could have a trial by fire and learn to secure my network. It was time to jump in the fire. I started to form a plan to make basic improvements. My home lab was born.

My first thought was to get rid of the TP-Link hardware2 and replace it with something with security as a priority throughout the development process. I eventually settled on OPNsense. OPNsense isn’t even technically a router. It’s not even router firmware. OPNsense is an entire operating system based on FreeBSD that functions, when installed on some x86 hardware with a couple NICs, as a firewall appliance. Sure, it functions as router in most senses of the word, but it’s so much more than that. It allows an admin to control just about everything one would want to at the network perimeter. OPNsense does it all (sort of, we’ll get to that shortly).

Establishing a Baseline Architecture

I bought an old Sophos firewall appliance, upgraded the memory, flashed it with OPNsense, and was suddenly at awe by everything I had been missing on my consumer router. Suddenly I could segment my network with VLANs and subnets to isolate IoT devices and place the kids firmly in their own network with its own set of controls. I could write arbitrary firewall rules between the WAN & LAN or between any of the other VLANS I created. I could filter based on block lists like Spamhaus. I finally felt like I was getting somewhere.

I continued by building up a pretty basic home-lab. I installed a managed switch to connect devices together and learned to make my own patch cables.3 I even fished a long run of ethernet through the walls to drop an access point running OpenWRT right in the middle of my house . I put together my own frankenstein NAS with an old Dell Optiplex tower and a stack of HDDs.4 I even put in a UPS to keep things running for an hour or so at idle in a blackout with a NUT server sending out shutdown commands if necessary.
I was living the home-lab high, albeit modest, life.

Sanitized Network Drawing. Communication between interfaces is handled at layer 3 and governed by OPNsense firewall rules. InterVLAN communication is set to deny by default. Guest and IoT networks restrict communication between devices. Specific interVLAN communication, like access to the NAS, for example, must be explicitly allowed.

A firewall and network segmentation is a good start, but it isn’t near enough. What happens if someone on a trusted device clicks on the wrong link or downloads something shady? What if they don’t update their systems and there’s a vulnerability being actively exploited in the wild? What happens if something gets past the firewall? A single layer of defense is a piss poor security model5.

Shifting Gears: From Perimeter Defense to Detection

I quickly began to realize the limitations of my current stack. At this point, it became clear that segmentation and enforcement alone do not provide situational awareness; meaningful security requires visibility, telemetry, and analysis. I want to take a more “defense in depth” approach to securing my home network. I’m going to be taking a lot of inspiration from the practices of industry leading SOCs. In order to do this, I need visibility into the network. There is no hope of securing anything if I can’t see what’s going on.

I need Logs.

I need Data.

I’m going to build a system that’s hungry for data; a system that can parse, analyze, and alert.

I need a logging pipeline that directs logs and other sources of telemetry to a single server. There, I need something to parse, clean, label, and arrange data into a structured, normalized, and consistent format. This “clean” data can then be fed into tunable analysis engines which can then feed a “single-pane-of-glass” type dashboard displaying alerts, charts, graphs, and other useful metrics.

Here’s the thing. I need to do this all on the cheap (or free if possible). Luckily, I have some hardware laying around. I’m sure I’ll be upgrading in the future, but for now I have an extreme budget of roughly $0.00 USD.

Rather than thinking of this as a quick installation of a single software solution, it’s important to understand that this is going to be a relatively complex stack of different components which work together cohesively to form a home security operations platform that is much greater than the sum of its parts. Modularity is key. Breaking this project down into smaller units that can act independently of one another can provide many benefits, including the ability to incrementally build, update, and modify the system as needed.

Design Goals and Constraints

Design Goals

Constraints

Current State vs. Target State

The purpose of this project is to enable myself to monitor, detect, analyze, and respond to events occuring within my home network. The following chart depicts the transition from a perimeter-focused home network to a visibility-driven security operations platform.

Current State Target State
Security Model Perimeter Security Defense in Depth
Visibility Minimal Centralized & Continuous
Telemetry Implicit, localized Explicit, aggregated
Analysis Manual Automated & tunable
Response Ad hoc Informed and repeatable

Abstract System Flow Diagram

This diagram shows an abstracted, high level, view of the proposed system. Rather than focusing on each tool that can be implemented, the following has a focus on the tasks across a layered system. Framing the lab in this way makes it possible to reason about coverage, gaps, and failure modes independently of specific tools. Each future component added to the lab can be evaluated by how it fits into this flow and what security questions it helps answer.

High-level system flow

What Comes Next

With a baseline network architecture in place and a clear understanding of its limitations, the focus of this project now shifts from perimeter control to visibility and detection. The abstract system flow outlined above serves as the guiding model for future work.

Related articles will delve into the following topics:

Subsequent articles will explore each stage of this pipeline in isolation—beginning with identifying high-value telemetry sources, designing a log ingestion and normalization strategy, and building analysis and detection capabilities on top of that data. Rather than treating this as a single monolithic deployment, the platform will be built incrementally, with each component evaluated by how it improves situational awareness and detection capability.

I didn’t want to dive too deep into platform selection, configuration details, or other details. This post is mainly focused of the direction that I intend to go with this project along with some broad goals. In the future, I plan to build up a more detailed architecture, compare different tools, make selections, and integrate them into my stack. The goal is to move a little bit closer to the end goal with each module that gets bolted on. Future posts will focus on implementation, tradeoffs, and lessons learned as the system evolves.

A high-level series map outlining future articles and system components will be maintained alongside this project.

  1. For those that are unaware, TP-Link has a reputation for serious security flaws, slow time-to-patch, and even national security concerns↩︎

  2. I considered flashing my old TP-Link router with OpenWRT, but it had a Broadcom chip. Poor planning.↩︎

  3. orange-white, orange, green-white, blue, blue-white, green, brown-white, brown↩︎

  4. The Optiplex NAS project was a fun one. I may do a writeup on it at some point. I gutted the DVD drive to make room for more drives.↩︎

  5. pardon↩︎