Linux Security Home Lab

OVERVIEW

Why I built the lab

I wanted an environment that would let me move beyond reading about Linux and cybersecurity concepts. The goal was to create an always-available system where I could safely practice commands, configure services, troubleshoot connectivity, examine logs, and test security controls.

A Raspberry Pi provided a dedicated Linux platform that could remain separate from my primary Windows and macOS computers. This made it useful for controlled experimentation while also requiring me to manage a real operating system and networked service.

Portfolio safety note: This case study is sanitized. It does not include passwords, private keys, exact IP addresses, usernames, internal network diagrams, or complete firewall rules.

OBJECTIVES

What the project needed to accomplish

Secure remote access

Administer the system remotely without exposing an SSH service directly to the public internet.

Reduce the attack surface

Identify listening services, restrict inbound access, and disable unnecessary exposure.

Improve visibility

Use logs, service-management tools, and packet-capture utilities to understand system and network behavior.

Support continued practice

Create a stable platform for Linux, networking, scripting, containers, and defensive-security exercises.

ARCHITECTURE

Remote-management path

Remote administration is performed through a private connectivity layer rather than by forwarding the SSH port from the home router to the public internet.

Administrative Device Windows or macOS client

Private Remote Access Tailscale connectivity

Linux Lab SSH, UFW, logging, and tools

SECURITY CONTROLS

Controls implemented

SSH key authentication

Configured public-key authentication for approved administrative devices and protected the authorized-key files with appropriate Linux permissions.

Root-login restriction

Confirmed that direct SSH login as the root account is disabled, requiring administration through an approved user and controlled privilege elevation.

Host firewall

Enabled UFW with a default-deny approach for unsolicited inbound traffic and limited SSH access to trusted network paths.

Private remote connectivity

Configured Tailscale so the system could be managed remotely without publicly exposing the SSH port.

Service inventory

Reviewed active services and listening ports using systemd, socket-inspection commands, and network-scanning tools.

Logging and validation

Used service status, journal logs, packet capture, and connection testing to verify that controls worked as intended.

IMPLEMENTATION

How I built and validated the environment

Established a system baseline

Confirmed the operating system, hardware, user context, network interfaces, active services, and listening ports before making security changes.
Configured administrative access

Created and tested SSH keys from approved client devices. Added the public keys to the Linux account and verified the permissions on the .ssh directory and authorized_keys file.
Hardened the SSH configuration

Reviewed the effective SSH settings, confirmed public-key support, disabled direct root login, and tested access before and after configuration changes.
Applied firewall restrictions

Enabled UFW, used a default-deny inbound policy, and allowed administrative traffic only through trusted local or private remote-access paths.
Added private remote access

Installed and authenticated Tailscale, verified the private interface, and tested SSH access from approved remote devices.
Installed security and network tools

Added tools for network discovery, packet capture, DNS testing, web enumeration, connectivity testing, version control, and container-based experimentation.
Validated the final configuration

Rechecked firewall status, listening services, remote connectivity, SSH logs, and packet activity instead of assuming the configuration worked.

VALIDATION

Example verification commands

These are representative commands used to validate the environment. They do not expose private addresses or sensitive configuration values.

systemctl status ssh
sudo ufw status verbose
ss -tulpen
tailscale status
sudo journalctl -u ssh --since today

TROUBLESHOOTING

Problems investigated

SSH public-key rejection

When a new client could not authenticate, I reviewed the public key, the authorized_keys entry, file ownership, and restrictive SSH-directory permissions.

Remote route conflict

Investigated failed remote connections when a travel router and commercial VPN altered routing behavior. I isolated the issue by reviewing VPN, LAN-access, kill-switch, and routing settings.

VPN-related DNS failure

Compared local network behavior, DNS resolution, and VPN configuration after a browser reported a DNS configuration failure.

Service verification

Used systemd status output, socket inspection, and packet capture to distinguish between a running service and one that was actually reachable.

OUTCOME

What the project demonstrates

The lab demonstrates more than installing security tools. It shows the ability to establish a baseline, make controlled configuration changes, validate those changes, investigate failures, and document the results.

Linux command-line administration
User, group, file, and permission management
SSH configuration and key management
Host-based firewall configuration
Service and port enumeration
Secure remote-connectivity troubleshooting
Log and packet analysis
Technical documentation

LESSONS LEARNED

Key takeaways

Validate every control

A configuration file can look correct while the effective service behavior is different. Status checks, logs, and connection tests provide stronger evidence.

Permissions affect authentication

Linux ownership and permission settings are directly connected to whether SSH accepts an authorized key.

Security layers interact

Host firewalls, router settings, VPNs, DNS, and private-overlay networking can each affect the same connection.

Documentation improves recovery

Recording changes and validation steps makes it easier to reverse a mistake and troubleshoot the next issue.

NEXT STEPS

Planned improvements

Evaluate disabling SSH password authentication after confirming that all approved devices and recovery methods work correctly.
Add automated update and patch-status reporting.
Centralize selected system and security logs for easier review.
Expand container-based practice while separating experimental services from the host.
Create repeatable configuration and validation checklists.

Return to featured projects