Tuxvador's Blog
Automated Daily CrowdSec Reports via Email Managing DNS Programmatically with the IONOS API Getting Started with Proxmox VE for Your Home Lab My Proxmox VE Homelab: Infrastructure Overview Monitoring Your Homelab with Grafana, Loki, and CrowdSec

Harden Your LXC Containers: Security Essentials for Proxmox


Running a homelab means you’re responsible for your own security. While LXC containers share the host kernel, there’s plenty you can do to isolate workloads and reduce attack surface. Here’s my standard hardening checklist.

1. Always Use Unprivileged Containers

This is the single most important security decision for LXC. An unprivileged container runs as a non-root user on the host (UID mapping via subuid/subgid), so even a container escape won’t give root on the host.

In Proxmox, check --unprivileged 1 when creating a CT via CLI, or toggle the “Unprivileged container” checkbox in the web UI. There’s almost no reason to run privileged containers in a homelab.

2. SSH Key-Only Authentication

Disable password auth in every container:

sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd

Better yet, inject your SSH key at container creation time with --ssh-public-keys so you never need a password in the first place.

3. Remove Unnecessary Packages

Each container should have one job. Don’t install compilers, editors, or network tools on containers that don’t need them. An attack can only use what’s installed:

apt purge -y nano vim-tiny perl python3  # if not needed
apt autoremove -y

4. Resource Limits via cgroups

Prevent a compromised container from consuming all host resources. Set limits at creation:

pct set 200 --memory 512 --swap 256 --cores 2

Or via the web UI under the container’s Resources tab. This is also good practice for preventing runaway processes from affecting other containers.

5. AppArmor Profiles

Proxmox applies AppArmor profiles to LXC containers by default. Verify they’re active:

aa-status | grep lxc

You should see lxc-container-default profiles loaded. Don’t disable these unless you have a specific reason.

6. Read-Only Rootfs Where Possible

For containers that don’t need to write to disk (reverse proxies, DNS servers), mount the root filesystem as read-only after initial configuration:

pct set 202 --rootfs local-lvm:4,ro=1

This prevents an attacker from modifying binaries or configuration even if they gain access.

7. Network Isolation

Use separate bridges or VLANs to isolate containers from each other. In Proxmox, create additional Linux bridges and attach containers based on trust level:

  • Public-facing containers (reverse proxy) on a DMZ bridge
  • Internal services on a trusted bridge
  • Test/experimental containers on an isolated bridge with no internet access

8. Regular Updates

Automate updates. I use a cron job in each container or a central Ansible playbook:

apt update && apt upgrade -y

At minimum, set up unattended-upgrades for security patches:

apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

The Principle

None of these steps are complex, but together they raise the bar significantly. In a homelab, you’re not defending against nation-state actors — you’re preventing automated scanners, cryptominers, and misconfigurations from ruining your day. These basics cover that threat model effectively.