Pentesting Your Own Network: A Home Lab Security Foundation

Pentesting Your Own Network

August 2023 was when I stopped thinking about home network security as “router with a password” and started treating it like actual infrastructure.

This post covers what I learned building a security testing lab: the tools, the traps, the legal landmines, and the architecture that keeps it all contained.

The Lab Architecture

Before you pentest anything, you need somewhere safe to do it. A vulnerable VM on your production network is a liability.

Network Isolation

The lab lives on its own VLAN:

VLAN 10: Production (192.168.10.0/24)
  - Workstations
  - NAS
  - Normal stuff

VLAN 20: DMZ (192.168.20.0/24)
  - Public-facing services
  - Monitored heavily

VLAN 40: Vulnerable Lab (192.168.40.0/24)
  - Metasploitable
  - DVWA
  - Intentionally broken things

Firewall Rules

The critical rule: VLAN 40 cannot reach anything else.

RULE: Block VLAN40 → Any
Interface: VLAN40
Action: Block
Source: 192.168.40.0/24
Destination: Any

If something on the vulnerable VLAN gets compromised (by you, by accident, by malware in a VM), it can’t pivot to production. The blast radius is contained.

The only allowed traffic:

RULE: Allow Internal → VLAN40 (for testing)
Action: Pass
Source: 192.168.10.0/24
Destination: 192.168.40.0/24

You can reach in. Nothing can reach out.

Honeypots: Learning From Attackers

A honeypot looks like a vulnerable system. When attackers hit it, you learn their techniques.

Cowrie for SSH

Most attacks on home networks are SSH brute-force. Cowrie answers on port 22, accepts every password, and logs everything.

docker run -d \
  -p 22:2222 \
  -v cowrie-log:/cowrie/var/log \
  cowrie/cowrie

Move your real SSH to port 2222. Point 22 at Cowrie.

Within 24 hours of exposing port 22 to the internet:

  • 847 brute-force attempts
  • Top passwords: admin, root, 123456, password, admin123
  • One attacker successfully “logged in” and tried to download a cryptominer

The cryptominer was captured, analyzed, and added to my threat intel. Educational.

Dionaea for Malware

If you want to catch exploit payloads, Dionaea simulates vulnerable services:

  • SMB (port 445)
  • HTTP
  • FTP
  • MSSQL

When someone tries to exploit EternalBlue against your fake SMB server, Dionaea captures the payload.

Warning: You’re now storing malware samples on your network. Keep Dionaea isolated.

T-Pot for Everything

T-Pot bundles multiple honeypots with an ELK stack for visualization. It’s a VM image you deploy and expose.

Components:

  • Cowrie (SSH/Telnet)
  • Dionaea (malware)
  • Honeytrap (generic service emulation)
  • Suricata (IDS)
  • Elasticsearch + Kibana (analysis)

Run T-Pot for a week and you’ll have a dashboard showing every attack attempt, categorized and visualized.

Burp Suite: Web Application Testing

For testing web apps, Burp Suite Professional is the standard. Here’s how I use it:

Scan Configuration

A comprehensive scan:

  1. Target Scope - Define exactly which domains/paths are in-scope
  2. Crawl Settings - How deep, how aggressive
  3. Audit Settings - Which vulnerability checks to run
Target: https://app.example.com/*
Excluded: https://app.example.com/logout
Excluded: https://app.example.com/api/dangerous-endpoint

Always exclude logout (don’t kill your session) and any endpoints that might cause damage.

Common Findings

The typical Burp scan on a home project reveals:

Low Severity:

  • Vulnerable JavaScript dependencies (outdated libraries)
  • Open redirection vulnerabilities
  • Missing HttpOnly flags on cookies
  • Password autocomplete enabled

Medium Severity:

  • Cross-site scripting (XSS) in input fields
  • CSRF vulnerabilities on state-changing actions

High Severity (fix immediately):

  • SQL injection
  • Server-side request forgery (SSRF)
  • Authentication bypass

Generating Reports

Burp generates HTML/PDF reports. For client work, I clean up the output:

  1. Remove false positives (manual verification)
  2. Add remediation steps specific to their stack
  3. Prioritize by actual risk, not just severity

Pentesting without authorization is a federal crime. Even on “your own” infrastructure, there are gotchas.

What You Need

Written authorization from the system owner. For home lab, that’s you. For anything else, get it signed.

Scope definition:

  • Which systems are in-scope
  • Which are explicitly out-of-scope
  • What testing methods are allowed
  • Time windows

Get-out-of-jail letter: If law enforcement asks why you were “attacking” a system, you show them the signed scope.

The Home IP Problem

When you run tests from home, your residential IP ends up in logs. If you test a client’s system and something goes wrong, that IP traces back to your house.

For any professional testing, use a VPN or a dedicated testing infrastructure. Don’t test from your home connection without understanding the trail you’re leaving.

VPN Access to the Lab

I access the lab remotely via OpenVPN on pfSense.

Restricted Routes

VPN clients shouldn’t see the whole network. They should see:

  • The vulnerable VLAN (for testing)
  • Maybe the NAS (for tools)
  • Nothing else

OpenVPN server config:

push "route 192.168.40.0 255.255.255.0"

Only push routes to the lab VLAN. Don’t push the production network.

Firewall Rules for VPN

# VPN clients can reach the lab
PASS: VPN Subnet → 192.168.40.0/24

# VPN clients can reach the NAS on specific ports
PASS: VPN Subnet → 192.168.10.10 (TCP 445)

# VPN clients cannot reach anything else
BLOCK: VPN Subnet → Any

Even if VPN credentials are compromised, the attacker lands in a restricted zone.

The Vulnerable VMs

For practice, I run:

Metasploitable

The classic deliberately-vulnerable Linux box. Comes with:

  • Weak SSH credentials
  • Vulnerable web apps
  • Exploitable services
# In the vulnerable VLAN, start Metasploitable VM
# Then from Kali:
nmap -sV 192.168.40.10

DVWA (Damn Vulnerable Web App)

Practice web attacks:

  • SQL injection
  • XSS
  • File inclusion
  • Command injection

Run in Docker:

docker run -d -p 80:80 vulnerables/web-dvwa

VulnHub Images

VulnHub.com has hundreds of deliberately-vulnerable VMs. Download, import into your hypervisor, and practice.

Lessons Learned

Isolation is non-negotiable. Vulnerable systems in a lab need to be firewalled from production. No exceptions.

Honeypots are intelligence. Every attacker you catch teaches you something. Run Cowrie at minimum.

Authorization before action. Even for personal projects, document what you’re testing and why.

The tools are the easy part. Burp, Metasploit, nmap - anyone can run them. Understanding what the output means and how to remediate findings is the skill.

The Current State

The security lab has evolved since August 2023:

  • Honeypots run 24/7, feeding into a SIEM
  • Vulnerable VMs cycle through VulnHub challenges
  • Burp Suite handles web app testing for personal projects
  • The vulnerable VLAN has grown to include Windows AD labs

What started as “I should learn pentesting” became a permanent security monitoring infrastructure. The lab watches the network. The network is safer for it.

The best way to defend a network is to know how to attack it. Build the lab. Learn the tools. Stay legal.