Practical Guides

A homelab without security hardening is a botnet node waiting to happen. It is not a question of if your exposed SSH port gets probed — it is a question of how many times per hour.

"It is just a homelab" is the most dangerous sentence in self-hosting. Default passwords, open ports, and unpatched systems are how real breaches start. And the habits you build here are the habits you carry into your career. This chapter hardens your lab to a standard that would pass a basic security audit.

Common mistake: Assuming your homelab is safe because it is behind a consumer router. NAT is not a firewall. One compromised IoT device, one forwarded port you forgot about, one UPnP rule your router auto-created — and your unpatched Proxmox node is reachable. Harden it anyway.

Security Principles

Before we touch a single configuration file, internalize these:

1. Least privilege. Every service, user, and process gets the minimum permissions it needs. Nothing more.
2. Defense in depth. Multiple layers of protection. If one fails, the next catches the threat.
3. Assume breach. Design as if an attacker is already on your network. Limit lateral movement.
4. Audit and log. If you cannot see what happened, you cannot respond to it.

These are not academic principles. They are how every serious organization approaches security. Building them into your homelab makes them second nature.

SSH Hardening

SSH is the primary management interface for your entire lab. It must be locked down.

Key-Only Authentication (Review)

You set this up in Chapter 2. Verify it is still in effect on every host and container:

# Check on each node/container
grep -E "^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)" /etc/ssh/sshd_config

If PasswordAuthentication is present and set to yes, fix it:

sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
echo "PasswordAuthentication no" >> /etc/ssh/sshd_config  # If not present at all
systemctl restart sshd

Additional SSH Hardening

Edit /etc/ssh/sshd_config on each host:

# Disable unused authentication methods
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

# Disable X11 forwarding (not needed for server management)
X11Forwarding no

# Set a login grace period
LoginGraceTime 30

# Limit authentication attempts per connection
MaxAuthTries 3

# Log level (VERBOSE gives you more audit data)
LogLevel VERBOSE

# Validate config before restarting (prevents lockout from typos)
sshd -t

# If no errors, restart
systemctl restart sshd

Common mistake: Editing sshd_config and restarting without testing the config first. If you introduce a syntax error, SSH will refuse to start and you are locked out. Always run sshd -t before systemctl restart sshd. Keep a console session open as a fallback.

Fail2ban

Fail2ban monitors log files and bans IPs that show malicious behavior.

apt install -y fail2ban

Create /etc/fail2ban/jail.local:

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 3
backend = systemd

[sshd]
enabled = true
port    = ssh
filter  = sshd
logpath = /var/log/auth.log
maxretry = 3

[proxmox]
enabled = true
port    = https,http,8006
filter  = proxmox
logpath = /var/log/daemon.log
maxretry = 3

Fail2ban does not include a Proxmox filter by default. Create one:

cat > /etc/fail2ban/filter.d/proxmox.conf << 'EOF'
[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
EOF

systemctl enable --now fail2ban

Interview angle: "I hardened the environment with a defense-in-depth approach: SSH is key-only with password authentication disabled, the Proxmox cluster firewall runs default-deny with IP set-based rules, fail2ban monitors for brute-force attempts on both SSH and the Proxmox web UI, and unattended-upgrades handles security patches automatically across all containers."

This is roughly half of Chapter 7. The full chapter continues with Proxmox cluster firewall rules, container-level firewalls, unattended security upgrades, Tailscale VPN setup, certificate management, and a quarterly security audit checklist.

Every interviewer has heard these. They sound confident. They sound reasonable. And they are either wrong, dangerously incomplete, or a sign that the candidate is reciting buzzwords without understanding the underlying concepts.

This chapter is your inoculation. Read through these, recognize the pattern, and make sure you are not the candidate who says them.

1. "Just block the IP"

The question: "An alert fires showing repeated connection attempts from an external IP to your web server. What do you do?"

The "sounds right" answer: "I would block the IP on the firewall."

Why it is wrong: Blocking a single IP is whack-a-mole. Attackers do not use one IP — they use dozens, hundreds, or thousands. They rotate through cloud providers, VPNs, compromised hosts, and residential proxies. Blocking one IP gives you approximately 30 seconds of peace before the next one shows up.

More importantly, you skipped the entire investigation. Why were they connecting? Did they succeed? What were they targeting? Blocking the IP is a containment step — and a weak one at that — not a complete response.

The better answer: "I would first analyze what the connection attempts were targeting — port, protocol, and payload. I would check if any attempts succeeded by correlating with web server access logs, WAF logs, and EDR. If this is an active exploit attempt, I would block the IP as an immediate short-term containment step while investigating, but I would also look at the attack pattern to build a broader detection rule — because the attacker will come back from a different IP. The long-term fix is addressing whatever vulnerability they were targeting."

---

2. "Encryption means it is secure"

The question: "How do you ensure data is secure in transit?"

The "sounds right" answer: "We encrypt everything with TLS, so the data is secure."

Why it is wrong: Encryption protects confidentiality. That is one property of security. It does not protect against a compromised endpoint, a man-in-the-middle with a trusted certificate (like a corporate proxy doing TLS inspection), weak cipher suites, expired certificates, or an attacker who already has the decryption keys.

Also, "we encrypt everything" is not a security control — it is a vague aspiration. Encrypt with what? TLS 1.0? TLS 1.3? A self-signed cert? AES-256 or DES? The details matter enormously.

The better answer: "TLS encryption in transit is a baseline, but encryption alone is not sufficient. I would verify we are using TLS 1.2 or 1.3 with strong cipher suites, that certificates are valid and properly managed, and that we have certificate pinning where appropriate. I would also consider the endpoints — encryption does not help if the server is compromised. And for sensitive data, I would look at encryption at rest as well, key management practices, and access controls on who can decrypt."

---

3. "Zero trust means no firewall"

The question: "Explain zero trust architecture and how it changes security."

The "sounds right" answer: "Zero trust means we do not trust the network perimeter, so we do not need firewalls anymore. Everything is identity-based."

Why it is wrong: Zero trust does not mean "no perimeter." It means "do not assume the perimeter is enough." Firewalls still have a role — they just are not the only thing standing between you and the bad guys. Zero trust adds identity verification, device posture checks, micro-segmentation, and continuous validation on top of network controls. It is defense in depth, not defense instead of.

Saying "we do not need firewalls" in an interview is like saying "we have seatbelts so we do not need brakes." Both do different things. You want both.

The better answer: "Zero trust is a shift from implicit trust based on network location to explicit verification for every access request. It means that being on the corporate network does not automatically grant you access to resources — you still need to authenticate, your device needs to meet security requirements, and access is granted on a least-privilege basis. Firewalls still play a role in network segmentation and blocking known-bad traffic, but they are one layer in a broader architecture that includes identity providers, device management, micro-segmentation, and continuous monitoring."

---

The Pattern

Read back through these three mistakes. Notice something?

Almost every wrong answer shares the same flaw: it jumps to a single action without understanding the full picture.

Block the IP. Disable the account. Restore from backup. These are all actions. Some of them are even correct actions — but taken in isolation, without context, they range from incomplete to actively harmful.

What interviewers are looking for — and what separates a good analyst from a button-pusher — is the ability to think in systems. Every action has dependencies, side effects, and assumptions. When you are in an interview and a quick, confident answer pops into your head, pause for two seconds and ask yourself: "What am I not thinking about?"

This is 3 of 10 "sounds right but wrong" patterns. The full chapter continues with "hash passwords with MD5," "the SIEM will catch everything," "disable the user account immediately," "we use antivirus so we are protected," and more — plus a full mock interview scoring rubric with 30 practice questions across 3 simulated rounds.