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. J’utilise une tâche cron dans chaque conteneur ou un playbook Ansible centralisé :

apt update && apt upgrade -y

Au minimum, configurez unattended-upgrades pour les correctifs de sécurité :

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

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.