tuxvador@blog:~/blog/fr/harden-lxc-containers-proxmox$

~/blog/fr/harden-lxc-containers-proxmox

Renforcez vos conteneurs LXC : Essentiels de sécurité pour Proxmox

3 min de lectureMis à jour le Read in English →

#security#proxmox#linux#lxc#homelab

Gérer un laboratoire maison signifie que vous êtes responsable de votre propre sécurité. Bien que les conteneurs LXC partagent le noyau de l’hôte, il y a beaucoup de choses que vous pouvez faire pour isoler les charges de travail et réduire la surface d’attaque. Voici ma liste de vérification standard pour le durcissement.

1. Utilisez toujours des conteneurs non privilégiés

C’est la décision de sécurité la plus importante pour LXC. Un conteneur non privilégié s’exécute en tant qu’utilisateur non root sur l’hôte (mappage d’UID via subuid/subgid), donc même une évasion de conteneur ne donnera pas l’accès root à l’hôte.

Dans Proxmox, cochez --unprivileged 1 lors de la création d’un CT via la CLI, ou activez la case « Unprivileged container » dans l’interface web. Il n’y a presque aucune raison d’utiliser des conteneurs privilégiés dans un laboratoire maison.

2. Authentification SSH par clé uniquement

Désactivez l’authentification par mot de passe dans chaque conteneur :

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

Mieux encore, injectez votre clé SSH lors de la création du conteneur avec --ssh-public-keys pour n’avoir jamais besoin de mot de passe.

3. Supprimez les paquets inutiles

Chaque conteneur devrait avoir une seule tâche. N’installez pas de compilateurs, d’éditeurs ou d’outils réseau sur les conteneurs qui n’en ont pas besoin. Une attaque ne peut utiliser que ce qui est installé :

apt purge -y nano vim-tiny perl python3  # si non nécessaire
apt autoremove -y

4. Limites de ressources via cgroups

Empêchez un conteneur compromis de consommer toutes les ressources de l’hôte. Définissez des limites à la création :

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

Ou via l’interface web sous l’onglet Resources du conteneur. C’est aussi une bonne pratique pour éviter que des processus incontrôlés n’affectent d’autres conteneurs.

5. Profils AppArmor

Proxmox applique des profils AppArmor aux conteneurs LXC par défaut. Vérifiez qu’ils sont actifs :

aa-status | grep lxc

Vous devriez voir les profils lxc-container-default chargés. Ne les désactivez pas sauf raison spécifique.

6. Système de fichiers root en lecture seule si possible

Pour les conteneurs qui n’ont pas besoin d’écrire sur le disque (proxys inverses, serveurs DNS), montez le système de fichiers root en lecture seule après la configuration initiale :

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

Cela empêche un attaquant de modifier les binaires ou la configuration même s’il obtient l’accès.

7. Isolation réseau

Utilisez des bridges ou VLANs séparés pour isoler les conteneurs les uns des autres. Dans Proxmox, créez des bridges Linux supplémentaires et attachez les conteneurs selon le niveau de confiance :

  • Conteneurs exposés au public (proxy inverse) sur un bridge DMZ
  • Services internes sur un bridge de confiance
  • Conteneurs de test/expérimentation sur un bridge isolé sans accès internet

8. Mises à jour régulières

Automatisez les mises à jour de sécurité, et décidez délibérément pour tout le reste. Mes conteneurs installent eux-mêmes les mises à jour Debian-Security chaque matin ; l’hôte Proxmox et tout ce qui vient d’un dépôt tiers attendent un playbook Ansible que je lance moi-même :

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

Par défaut, unattended-upgrades prend aussi les versions intermédiaires. Pour le limiter à la sécurité, remplacez ses origines dans un fichier complémentaire, et vérifiez ce qu’il autorise avec unattended-upgrade --dry-run --debug. La configuration complète, y compris les métriques qui montrent un hôte qui prend du retard, est dans Mettre à jour un homelab.

N’installez pas de paquets de noyau dans un conteneur : il fait tourner le noyau de l’hôte, donc ils ne démarrent jamais, et un scanner de vulnérabilités comptera quand même chacune de leurs CVE. Certains métapaquets (wireguard, par exemple) tirent un noyau en dépendance ; vérifiez avec dpkg -l 'linux-image-*'.

Le principe

Aucune de ces étapes n’est complexe, mais ensemble, elles élèvent considérablement le niveau de sécurité. Dans un laboratoire maison, vous ne vous défendez pas contre des acteurs étatiques — vous empêchez les scanners automatisés, les cryptomineurs et les erreurs de configuration de gâcher votre journée. Ces bases couvrent efficacement ce modèle de menace.

cd ~/blog