92 est la moitié de 99

Proxmox Best Practice Partie 4 – Sécurité: Protéger les systèmes contre diverses menaces

Mises à jour système et gestion des correctifs: Les fondements de la sécurité

Pourquoi les mises à jour sont-elles si critiques?

Les logiciels obsolètes sont l'une des portes d'entrée les plus courantes pour les attaquants. Chaque jour, de nouvelles failles de sécurité (CVE) sont découvertes et publiées – un système non corrigé est comme une maison avec des portes et des fenêtres ouvertes. Proxmox s'ajoute au fait qu'il s'agit d'une plate-forme de virtualisation complexe qui a un accès direct aux ressources matérielles. Un hyperviseur compromis avec succès signifie que les attaquants peuvent obtenir un accès complet à toutes les machines virtuelles et à tous les conteneurs qui s'y trouvent. Ce pire cas doit être évité à tout prix.

Les principaux risques associés aux systèmes non corrigés sont les vulnérabilités Remote Code Execution (RCE), les attaques Privilege Escalation ou encore les frameworks Known-Exploit tels que Metasploit, qui recherchent automatiquement les systèmes vulnérables. Les exploits zero-day deviennent particulièrement critiques: les administrateurs n’ont souvent que des heures ou des jours avant le début des attaques automatisées.

Configuration du référentiel: Stabilité vs. actualité

Choisir le bon référentiel est un conflit classique entre sécurité et stabilité. Proxmox propose différentes options de référentiel, chacune ayant des avantages et des inconvénients différents.

Enterprise Repository – L’étalon-or pour les environnements de production:

L'Enterprise Repository est soumis à un processus d'assurance qualité en plusieurs étapes. Les mises à jour sont d'abord testées en interne, puis validées dans des environnements contrôlés et ne sont libérées qu'après des tests approfondis. Cela minimise le risque que les mises à jour elles-mêmes entraînent des pannes du système, un scénario qui peut être dévastateur dans les environnements de production critiques.

Le principal inconvénient, bien sûr, n'est pas le facteur de coût, mais le retard dans la disponibilité des mises à jour de sécurité. Dans les cas extrêmes, il peut s'écouler des semaines avant que des correctifs critiques ne soient disponibles. Cependant, pour les organisations ayant des exigences de conformité strictes ou des systèmes de production critiques, ce délai peut également être un compromis acceptable pour la stabilité supplémentaire.

#v8 # Activer le référentiel d'entreprise cat > /etc/apt/sources.list.d/pve-enterprise.list << 'EOF' deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise EOF

#v9 #File #/etc/apt/sources.list.d/pve-enterprise.sources Types: deb URIs: https://enterprise.proxmox.com/debian/pve Suites: trixie Components: pve-enterprise Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

No-Subscription Repository – L’équilibre entre les coûts et les risques:

Le référentiel gratuit reçoit les mises à jour plus rapidement, mais celles-ci passent par des tests moins rigoureux. Il peut s’agir de «bugs de régression», c’est-à-dire de mises à jour qui endommagent les fonctionnalités existantes ou introduisent de nouvelles vulnérabilités. Pour les environnements Homelab ou les systèmes de test, cela est généralement acceptable, car la défaillance n'est pas critique pour l'entreprise.

Un risque particulier réside dans le fait que le référentiel No-Subscription contient parfois des caractéristiques expérimentales. Cela peut entraîner des failles de sécurité inattendues ou des instabilités. Les administrateurs doivent être particulièrement attentifs et commencer par valider les mises à jour dans les environnements de test. Un trade-off qui vaut la peine, surtout avec les lacunes de ZeroDay. En effet, le No-Sub Repo est disponible plus rapidement lorsqu'il brûle.

v8 # Activer le dépôt sans abonnement cat > /etc/apt/sources.list.d/pve-no-subscription.list << 'EOF' deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription EOF # Dépôts Debian par défaut pour les mises à jour de sécurité cat > /etc/apt/sources.list << 'EOF' deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware deb http:///deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware EOF

v9 # Activer le dépôt sans abonnement Types: deb deb-src URIs: http://deb.debian.org/debian/ Suites: trixie trixie-updates Components: main non-free-firmware Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg Types: deb deb-src URIs: http://security.debian.org/debian-security/ Suites: trixie-security Components: main non-free-firmware Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Mises à jour de sécurité automatiques: Confort vs. contrôle

Les mises à jour automatiques sont une épée à double tranchant. D’une part, ils réduisent considérablement la fenêtre d’attaque – la plupart des compromissions réussies du système reposent sur des vulnérabilités pour lesquelles des correctifs étaient déjà disponibles. D'autre part, les mises à jour automatiques peuvent entraîner des pannes imprévues si une mise à jour est incompatible avec les configurations existantes.

Le plus grand risque de mises à jour automatiques réside dans le manque de contrôle sur le moment. Une mise à jour pourrait faire planter une application importante pendant les heures d'ouverture critiques. Cela est particulièrement problématique pour les mises à jour du noyau nécessitant un redémarrage ou pour les mises à jour de services critiques tels que Proxmox Cluster Stack.

La configuration présentée ici adopte donc également une approche plutôt conservatrice: Seules les mises à jour de sécurité sont installées automatiquement et les redémarrages automatiques sont désactivés. Cela offre un bon compromis entre la sécurité et le contrôle.

# Installation et configuration des mises à niveau non attendues apt update && apt install -y unattended-upgrades apt-listchanges # Créer une configuration détaillée cat > /etc/apt/apt.conf.d/50unattended-upgrades << 'EOF' // Mises à jour automatiques uniquement pour les correctifs de sécurité Mise à niveau non attendue::Patterns d'origine { "origin=Debian,codename=${distro_codename},label=Debian-Security"; "origin=Proxmox,codename=${distro_codename}"; }; // Redémarrer les services système importants après les mises à jour Mise à niveau Unattended::Redémarrage automatique "false"; Mise à niveau Unattended ::Automatic-Reboot-WithUsers "false"; Mise à niveau Unattended ::Remove-Unused-Kernel-Packages "true"; Mise à niveau Unattended::Remove-Unused-Dependencies "true"; // Notifications et journalisation Mise à niveau non attendue ::Mail "admin@example.com"; Mise à niveau sans attente ::MailReport "on-change"; Mise à niveau Unattended ::AutoFixInterruptedDpkg "true"; Mise à niveau sans attente ::MinimalSteps "true"; // Débogage en cas de problèmes Mise à niveau Unattended::Debug "false"; EOF # Activer les mises à jour automatiques cat > /etc/apt/apt.conf.d/20auto-upgrades << 'EOF' APT::Periodic::Update-Package-Lists "1"; APT ::Periodic ::Unattended-Upgrade "1"; APT ::Periodic ::AutocleanInterval "7"; EOF # Démarrer et activer le service systemctl enable --now unattended-upgrades

Considérations importantes concernant les mises à jour automatiques:

Les notifications par courrier électronique sont essentielles: les administrateurs doivent être informés des mises à jour installées afin de pouvoir réagir rapidement en cas de problème. L'option MailReport "on-change" veille à ce que les e-mails ne soient envoyés qu'en cas de modifications réelles, ce qui réduit le spam.

Suppression automatique des paquets inutilisés (Remove-Unused-Dependencies "true") réduit la surface d'attaque, mais peut, dans de rares cas, entraîner des problèmes inattendus si les dépendances sont détectées de manière incorrecte. Assurez-vous de garder un œil sur eux!

Configuration du pare-feu: Défense à Depth

Le concept de défense multicouche

Un seul niveau de pare-feu ne suffit plus dans les environnements informatiques modernes. Le principe de défense en profondeur exige plusieurs niveaux de sécurité qui se complètent et se protègent mutuellement. Chez Proxmox, nous avons trois niveaux de pare-feu naturels: Centre de données (à l'échelle du cluster), nœud (spécifique à l'hôte) et machine virtuelle/conteneur (spécifique à l'invité).

L'avantage de cette approche réside dans la redondance: Même si un calque est compromis ou mal configuré, les autres calques offrent toujours une protection. Dans le même temps, il permet un contrôle granulaire – différentes machines virtuelles peuvent avoir des politiques de sécurité différentes sans compromettre la sécurité à l’échelle du cluster.

Pare-feu de niveau datacenter: Le mur de protection externe

Le pare-feu du centre de données agit comme la première ligne de défense et définit des politiques de sécurité de base pour l'ensemble du cluster. Ici, nous mettons en œuvre le principe du dentifrice par défaut: Tout est bloqué par défaut, seul le trafic explicitement autorisé est autorisé.

Les attaques qui sont évitées:

  • Analyse des ports des attaquants externes
  • Accès non autorisé aux interfaces de gestion
  • Mouvement latéral entre clusters
  • Exfiltration de données via des ports inhabituels

Inconvénients potentiels: La politique restrictive par défaut peut entraîner des problèmes de connectivité lors de l'ajout de nouveaux services. Les administrateurs doivent créer consciemment de nouvelles règles, ce qui peut prendre beaucoup de temps au début. En cas de mauvaise configuration, les administrateurs peuvent se verrouiller eux-mêmes, c'est pourquoi les modifications du pare-feu doivent toujours être effectuées par un deuxième moyen d'accès (par exemple IPMI/iLO). 

# Activer le pare-feu du centre de données via l'interface de ligne de commande pvesh set /cluster/firewall/options --enable 1 # Définir la politique par défaut (Drop by default, explicitement autoriser) pvesh set /cluster/firewall/options --policy_in DROP pvesh set /cluster/firewall/options --policy_out ACCEPT # Assurer l'accès à la gestion pvesh create /cluster/firewall/rules --pos 0 --action ACCEPT --type in --proto tcp --dport 22 --comment "SSH Management" pvesh create /cluster/firewall/rules --pos 1 --action ACCEPT --type in --proto tcp --dport 8006 --comment "Proxmox Web Interface" # VNC/SPICE pour les consoles de machines virtuelles (facultatif, uniquement si nécessaire) pvesh create /cluster/firewall/rules --pos 2 --action ACCEPT --type in --proto tcp --dport 5900:5999 --comment "VNC Console Access" # Communication en cluster (uniquement entre nœuds connus) pvesh create /cluster/firewall/rules --pos 3 --action ACCEPT --source 192.168.1.0/24 --type in --proto tcp --dport 22000:22050 --comment "Cluster Communication" # ICMP pour Network-Troubleshooting pvesh create /cluster/firewall/rules --pos 4 --action ACCEPT --type in --proto icmp --comment "ICMP Ping"

Considérations particulières concernant la règle VNC: L'accès VNC (ports 5900-5999) permet aux consoles d'accéder aux machines virtuelles, mais constitue également un risque potentiel pour la sécurité. Par défaut, le trafic VNC n'est pas crypté et peut être intercepté. Dans les environnements de production, VNC ne doit être utilisé que via VPN ou avec un cryptage TLS supplémentaire.

Pare-feu de niveau node: Sécurité spécialisée

Chaque nœud Proxmox peut avoir des rôles spécifiques: nœud de stockage, nœud de calcul, nœud de sauvegarde, etc. Le pare-feu de niveau nœud permet de refléter ces rôles dans les politiques de sécurité.

Avantages en matière de sécurité:

  • Isolation des services spécifiques aux nœuds
  • Contrôle granulaire de l'accès au stockage
  • Meilleur confinement en cas de compromission de nœuds individuels

Risques de complexité: Au fur et à mesure que le nombre de nœuds augmente, la gestion du pare-feu devient complexe. Des règles incohérentes entre les nœuds peuvent entraîner des problèmes de réseau difficiles à diagnostiquer. Une documentation centralisée et des processus de déploiement automatisés deviennent essentiels.

# Activer le pare-feu spécifique au nœud pvesh set /nodes/$(hostname)/firewall/options --enable 1 # Règles spécifiques au nœud (exemple de serveur de sauvegarde) pvesh create /nodes/$(hostname)/firewall/rules --action ACCEPT --type in --proto tcp --dport 8007 --comment "Proxmox Backup Server" # Accès au stockage (NFS, iSCSI, etc.) pvesh create /nodes/$(hostname)/firewall/rules --action ACCEPT --source 192.168.1.0/24 --type in --proto tcp --dport 2049 --comment "NFS Storage"

Pare-feu de niveau VM: microsegmentation

Le pare-feu de niveau VM implémente la microsegmentation – chaque VM est traitée comme une zone de sécurité distincte. Ceci est particulièrement important dans les environnements multi-locataires ou lors de l'isolement d'applications critiques.

Protection contre le mouvement latéral: Lorsqu'un attaquant compromet une machine virtuelle, le pare-feu au niveau de la machine virtuelle empêche sa propagation automatique à d'autres systèmes. C'est l'un des mécanismes de protection les plus efficaces contre les attaques APT (Advanced Persistent Threats) modernes.

Considérations de performance: Chaque règle de pare-feu entraîne une charge CPU supplémentaire. Dans les environnements comportant de nombreuses machines virtuelles et des ensembles de règles complexes, cela peut affecter les performances. Le moteur de pare-feu de Proxmox est optimisé, mais avec des centaines de machines virtuelles avec des dizaines de règles chacune, cela peut être perceptible.

# Activer le pare-feu VM (pour VM ID 100) qm set 100 --firewall 1 # Règles du serveur web pvesh create /nodes/$(nom d'hôte)/qemu/100/firewall/rules --action ACCEPT --type in --proto tcp --dport 80 --comment "HTTP" pvesh create /nodes/$(nom d'hôte)/qemu/100/firewall/rules --action ACCEPT --type in --proto tcp --dport 443 --comment "HTTPS" pvesh create /nodes/$(nom d'hôte)/qemu/100/firewall/rules --action DROP --type in --comment "Deny all other traffic"

Authentification avancée: Plus que des mots de passe

Le problème de l'authentification par mot de passe

Les mots de passe seuls sont totalement insuffisants dans le paysage des menaces d'aujourd'hui. La plupart des cambriolages réussis commencent par des identifiants compromis, qu’il s’agisse de phishing, de credential stuffing ou d’attaques par force brute. Dans un système comme Proxmox, qui permet un accès administratif complet à l'infrastructure critique, l'impact d'un compte compromis est dévastateur.

Les attaquants modernes utilisent des techniques sophistiquées: Ils utilisent des listes de milliards de mots de passe déjà divulgués, utilisent des attaques basées sur l'IA et ont accès à du matériel spécialisé pour les attaques par force brute. Un seul mot de passe, même complexe, est malheureusement impuissant face à ces menaces, du moins à long terme.

Authentification multifactorielle: Le Game Changer

L'authentification multifacteur (MFA) est l'une des mesures de sécurité les plus efficaces. Même si un mot de passe est compromis, un attaquant ne peut pas y accéder sans le deuxième facteur. Proxmox VE prend en charge les mots de passe TOTP (Time-based One-Time Passwords) qui fonctionnent avec des applications telles que Google Authenticator, Authy ou andUOTP.

Avantages en matière de sécurité:

  • Protection contre 99,9% Toutes les attaques automatisées
  • Avertissement de compromission (échec des tentatives d’AMF)
  • Conformité (de nombreuses normes exigent l'AMF)

Défis opérationnels: MFA peut réduire la facilité d'utilisation et compliquer les processus de configuration initiale. En cas de perte de l'appareil MFA, les utilisateurs peuvent se verrouiller eux-mêmes. Les codes d'urgence ou les méthodes d'authentification alternatives sont essentiels, mais ils augmentent à nouveau la complexité.

# Activer 2FA pour les utilisateurs (via l'interface Web ou l'interface de ligne de commande) # Datacenter → Authentication → Two Factor # Exemple : Configurer TOTP pour les utilisateurs pvesh create /access/tfa --userid admin@pam --type totp --description "Admin TOTP Token"

Gestion centralisée des utilisateurs: LDAP et Active Directory

Dans les grandes organisations, la gestion décentralisée des utilisateurs est un risque pour la sécurité. Les employés changent de rôle, quittent l’entreprise ou ont besoin d’un accès temporaire – tous ces changements doivent être reflétés rapidement dans tous les systèmes. La gestion centralisée des utilisateurs résout ce problème grâce à l'authentification unique (SSO) et au contrôle centralisé des droits.

Avantages en matière de sécurité:

  • Blocage immédiat en cas de changement de personnel
  • Politiques unifiées en matière de mots de passe
  • Audit centralisé et conformité
  • Réduction du nombre de comptes à gérer

Risques de mise en œuvre: La gestion centralisée des utilisateurs crée un point de défaillance unique. Si le serveur LDAP/AD tombe en panne, les utilisateurs ne peuvent plus se connecter. Le partitionnement réseau entre Proxmox et le serveur d'authentification entraîne les mêmes problèmes. Un compte d'urgence local avec une authentification forte est donc indispensable. Certains d’entre vous le connaissent peut-être sous le nom de «Oh-Shit Account», dont le jeton/mot de passe/carte à puce se trouve dans un coffre-fort. ⁇

# Intégration LDAP via CLI pvesh create /access/domains --realm company.local --type ldap \ --server ldap.company.local --port 636 --secure 1 \ --base-dn "dc=company,dc=local" \ --user-attr sAMAccountName \ --bind-dn "cn=proxmox,ou=service-accounts,dc=company,dc=local" # Alternativement: Intégration Active Directory pvesh create /access/domains --realm company.local --type ad \ --server ad.company.local --port 636 --secure 1 \ --domain company.local

Contrôle d'accès basé sur les rôles: Le principe de l'autorisation minimale

Le principe du privilège minimum (Least Privilege) est fondamental pour les systèmes sécurisés. Les utilisateurs ne devraient recevoir que les droits dont ils ont besoin pour accomplir leurs tâches, ni plus ni moins. Dans Proxmox, le système basé sur les rôles permet un contrôle très granulaire des autorisations.

Définitions typiques des rôles:

  • Opérateur de VM: Peut démarrer/arrêter/gérer des machines virtuelles, mais pas en créer de nouvelles
  • Administrateur de stockage: Accès complet à la configuration du stockage, mais pas aux droits des machines virtuelles
  • Utilisateur de moniteur: Accès en lecture seule pour la surveillance et le reporting
  • Opérateur de sauvegarde: Peut créer et restaurer des sauvegardes

Gestion de la complexité: Au fur et à mesure que la taille de l'organisation augmente, la gestion des rôles devient complexe. Les dépendances rôle-à-rôle, les autorisations temporaires et les rôles de travail changeants nécessitent des examens réguliers. Une documentation claire et des processus de provisionnement automatisés sont essentiels.

# Créer un rôle personnalisé pour les opérateurs de machines virtuelles pvesh create /access/roles --roleid VMOperator \ --privs "VM.Allocate,VM.Config.Disk,VM.Config.Memory,VM.Console,VM.PowerMgmt,VM.Monitor" # Rôle limité pour la surveillance pvesh create /access/roles --roleid Monitor \ --privs "Sys.Audit,VM.Audit,Datastore.Audit" # Attribution de rôle utilisateur avec limitation de chemin pvesh create /access/acl --path /vms/100 --users operator@company.local --roles VMOperator pvesh create /access/acl --path /nodes/proxmox1 --users monitoring@company.local --roles Monitor

Durcissement de SSH: Le talon d'Achille de nombreux systèmes

Pourquoi SSH est la cible principale

SSH (Secure Shell) est activé par défaut sur la plupart des systèmes Linux et fournit un accès direct au shell avec l'autorisation root. Pour les attaquants, il s'agit de la cible la plus attractive: Un accès SSH compromis avec succès signifie souvent un contrôle complet du système.

La plupart des attaques SSH se produisent via:

  • Attaques par force brute contre les mots de passe faibles
  • Credential Stuffing avec des bases de données de mots de passe divulguées
  • Exploitation des vulnérabilités SSH connues
  • Attaques Man-in-the-Middle sur des connexions non cryptées
  • Ingénierie sociale pour obtenir des clés SSH

Les statistiques montrent la réalité: Les services SSH non protégés sont attaqués dans les minutes qui suivent leur mise en ligne. Les botnets automatisés analysent en permanence Internet à la recherche de ports SSH ouverts et lancent immédiatement des attaques avec les noms d'utilisateur et les mots de passe les plus courants.

Configuration complète de la sécurité SSH

La configuration SSH par défaut est optimisée pour la compatibilité, pas pour la sécurité. Une configuration durcie élimine la plupart des vecteurs d'attaque, mais nécessite une planification minutieuse afin de ne pas verrouiller les administrateurs.

Mesures de sécurité critiques expliquées:

Interdiction de connexion root: Direct Root Login est un risque de sécurité massif. Les attaquants connaissent le nom d'utilisateur racine et n'ont qu'à craquer le mot de passe. Avec PermitRootLogin no Les attaquants doivent connaître à la fois un nom d'utilisateur et un mot de passe valides, puis procéder à l'escalade des privilèges.

Authentification par clé publique: Les clés SSH sont beaucoup plus puissantes cryptographiquement que les mots de passe. Une clé RSA 2048 bits correspond approximativement à un mot de passe de 256 caractères. Les clés ne peuvent pas être craquées par force brute, mais sont vulnérables au vol si elles sont stockées de manière non sécurisée.

Restrictions de l'algorithme: Les algorithmes SSH plus anciens ont des vulnérabilités connues. La configuration est limitée à des algorithmes modernes et sécurisés tels que Curve25519 et ChaCha20-Poly1305.

# Sauvegarde de la configuration d'origine cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup # Créer une configuration SSH sécurisée cat > /etc/ssh/sshd_config << 'EOF' # Protocole et cryptage Protocole 2 Port 22 #Port 2222 # Autre solution: Utiliser un port non standard # Clés d'hôte (algorithmes sécurisés uniquement) HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key # Paramètres cryptographiques KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group16-sha512 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512 # Authentification PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no UsePAM yes # Authorized Keys Configuration PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-256,rsa-sha2-512 AuthorizedKeysFile .ssh/authorized_keys # Gestion des sessions MaxAuthTries 3 MaxStartups 3:30:10 LoginGraceTime 60 ClientAliveInterval 300 ClientAliveCountMax 2 MaxSessions 2 # Restrictions d'accès AllowUsers admin@192.168.1.0/24 operator@192.168.1.0/24 # AllowGroups ssh-users # Journalisation et surveillance SyslogFacility AUTH LogLevel VERBOSE # Fonctionnalités de sécurité StrictModes yes IgnoreRhosts yes HostbasedAuthentication no PermitUserEnvironment no AllowAgentForwarding no AllowTcpForwarding no X11Forwarding no PrintMotd no TCPKeepAlive no Compression no EOF # Tester la configuration SSH sshd -t && systemctl reload sshd

Considérations importantes sur le durcissement SSH:

Changement de port: Changer le port SSH de 22 à un port non standard réduit considérablement les attaques automatisées. Cependant, il s'agit d'une sécurité par obscurité et n'offre aucune protection contre les attaques ciblées. Les scanners de ports trouvent rapidement des ports alternatifs.

Paramètres de délai d'expiration: ClientAliveInterval 300 et ClientAliveCountMax 2 Fermer les connexions inactives après 10 minutes. Cela empêche les attaquants de détourner les connexions existantes à long terme, mais peut être gênant pour les administrateurs ayant de longues tâches de maintenance.

Restrictions de transfert: AllowTcpForwarding no et AllowAgentForwarding no empêcher l'utilisation de SSH comme tunnel pour d'autres services. Cependant, cela peut entraver les tâches administratives souhaitées, telles que les connexions sécurisées à des bases de données via des tunnels SSH.

Authentification SSH basée sur des jetons: L'étalon-or

La méthode la plus sûre pour accéder à SSH est l'utilisation exclusive de clés SSH (tokens) combinée à la désactivation complète de l'authentification par mot de passe. Cette méthode élimine pratiquement toutes les attaques par force brute et offre une sécurité nettement supérieure à celle des mots de passe les plus puissants.

Pourquoi l'authentification par jeton est supérieure:

Les clés SSH sont basées sur une cryptographie asymétrique avec des longueurs de clé de 2048 à 4096 bits (RSA) ou des algorithmes de courbe elliptique modernes tels que Ed25519. Une clé RSA de 2048 bits équivaut à un mot de passe à 617 chiffres, ce qui est pratiquement impossible à déchiffrer par force brute. Les clés Ed25519 sont encore plus sûres et nettement plus performantes.

Les attaques qui sont évitées:

  • Le credential stuffing: Les bases de données de mots de passe divulguées ne valent rien
  • Phishing: Les clés SSH ne peuvent pas être capturées par l'ingénierie sociale
  • Enregistreur de frappe: Les logiciels malveillants sur les systèmes clients ne peuvent pas enregistrer les clés
  • Force brute: Mathématiquement impossible avec une longueur de clé correcte
  • Attaques de table arc-en-ciel: Les attaques pré-computées ne fonctionnent pas contre les clés

Considérations de sécurité opérationnelle:

Le principal inconvénient de l'authentification par jeton réside dans la gestion des clés. Si un administrateur perd sa clé privée, il est définitivement verrouillé. Dans le même temps, la clé privée doit être conservée en toute sécurité – une clé compromise donne un accès immédiat et complet.

La meilleure pratique consiste à utiliser des modules de sécurité matérielle (HSM) ou au moins des clés privées protégées par mot de passe. YubiKeys ou des jetons matériels similaires offrent une sécurité supplémentaire, car la clé privée ne quitte jamais l'appareil.

# Génération sécurisée de clés SSH (sur le système client) # Ed25519 - courbe moderne et sûre ssh-keygen -t ed25519 -C "admin@company.com" -f ~/.ssh/proxmox_ed25519 # Alternativement: RSA 4096 bits (pour les systèmes plus anciens) ssh-keygen -t rsa -b 4096 -C "admin@company.com" -f ~/.ssh/proxmox_rsa # Protéger la clé avec une phrase de passe forte (recommandé) ssh-keygen -t ed25519 -C "admin@company.com" -f ~/.ssh/proxmox_ed25519 -N "$(openssl rand -base64 32)" # Transférer la clé publique vers le serveur Proxmox ssh-copy-id -i ~/.ssh/proxmox_ed25519.pub admin@proxmox-server.local # Alternativement: Téléchargement manuel de la clé publique cat ~/.ssh/proxmox_ed25519.pub | ssh admin@proxmox-server.local "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys && chmod 700 ~/.ssh"

Stratégies avancées de gestion des clés:

Pour les environnements de production, les clés SSH doivent être gérées de manière centralisée. Cela permet de verrouiller rapidement les clés compromises et de simplifier les processus de rotation.

# Gestion centralisée des clés avec authorized_keys Options cat > /home/admin/.ssh/authorized_keys << 'EOF' # Emergency Admin Key - uniquement à partir du réseau de gestion from="192.168.100.0/24",no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILx... emergency-admin@company.com # Clé d'administration par défaut - limitée dans le temps from="192.168.1.0/24",no-port-forwarding,command="/usr/local/bin/admin-shell" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc... admin@company.com # Clé de surveillance - seules les commandes spécifiques from="192.168.1.100",no-pty,no-port-forwarding,command="/usr/bin/monitoring-script" ssh-rsa AAAAB3NzaC1yc2EAAAA... monitoring@company.com EOF chmod 600 /home/admin/.ssh/authorized_keys

authorized_keys options explique:

  • from="IP/réseau": Limite l'utilisation des clés à des IP sources spécifiques
  • command="commande": Exécute uniquement la commande spécifiée, ignore les requêtes client
  • no-port-forwarding: Empêche le tunneling SSH
  • no-pty: Empêche les sessions de terminal interactives
  • no-X11-forwarding: Désactive le forwarding X11

Contrôle d'accès SSH basé sur le réseau: Défense à Depth

Même avec une configuration SSH parfaite, il est logique de limiter l'accès au niveau du réseau. Cela fournit une couche de sécurité supplémentaire et réduit considérablement la surface d'attaque.

Restrictions géographiques:

Si les administrateurs n'accèdent qu'à partir de certains pays ou régions, des blocs IP géographiques peuvent être implémentés. Cela arrête la plupart des attaques automatisées, car elles proviennent souvent de certains pays.

Avantages de la segmentation du réseau:

  • Surface d'attaque réduite: SSH n'est accessible que pour les réseaux autorisés
  • Détection précoce: Les accès provenant de réseaux non autorisés sont immédiatement suspects
  • Conformité: De nombreux frameworks exigent une segmentation du réseau
  • Performance: Moins d'Attempts de connexion pour réduire la charge CPU

Inconvénients et défis:

  • Mobilité: Le travail à distance devient plus difficile
  • Urgences: L'accès à partir de réseaux inattendus peut être bloqué
  • IP dynamiques: Les changements de FAI peuvent verrouiller les administrateurs
  • Maintenance requise: Les listes IP doivent être tenues à jour
# 1. Restriction SSH basée sur le pare-feu (iptables/nftables) # Autoriser uniquement le réseau de gestion iptables -A INPUT -p tcp --dport 22 -s 192.168.100.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT # IPs d'administrateur spécifiques iptables -A INPUT -p tcp --dport 22 -s 203.0.113.10 -j ACCEPT # Admin Home Office iptables -A INPUT -p tcp --dport 22 -s 198.51.100.50 -j ACCEPT # Backup Admin # Rejeter toutes les autres connexions SSH iptables -A INPUT -p tcp --dport 22 -j DROP # 2. Intégration du pare-feu Proxmox # À propos de l'interface web: Node → Pare-feu → Add Rule # Ou via CLI: pvesh create /nodes/$(hostname)/firewall/rules --type in --action ACCEPT \ --proto tcp --dport 22 --source 192.168.100.0/24 --comment "Management SSH" pvesh create /nodes/$(hostname)/firewall/rules --type in --action ACCEPT \ --proto tcp --dport 22 --source 203.0.113.10 --comment "Admin Home Office" pvesh create /nodes/$(hostname)/firewall/rules --type in --action DROP \ --proto tcp --dport 22 --comment "Block all other SSH"

Accès SSH basé sur VPN: La solution de sécurité ultime

Pour une sécurité maximale, SSH ne devrait être accessible que via des connexions VPN. Cela combine les avantages de la segmentation du réseau avec un cryptage et une authentification forts.

Avantages de l'architecture VPN SSH:

  • Double cryptage: VPN + SSH offrent un cryptage redondant
  • Authentification centralisée: Un serveur VPN peut forcer la MFA
  • Itinéraire d'audit: Tous les accès s'effectuent via une passerelle VPN contrôlée
  • Déconnecter en cas d'urgence: La connexion VPN peut être déconnectée de manière centralisée

Options de mise en œuvre:

# 1. Solution basée sur OpenVPN # Autoriser SSH uniquement via l'interface VPN iptables -A INPUT -p tcp --dport 22 -i tun0 -j ACCEPT # Interface VPN iptables -A INPUT -p tcp --dport 22 -i lo -j ACCEPT # Loopback iptables -A INPUT -p tcp --dport 22 -j DROP # Tous les autres # 2. Solution basée sur WireGuard (alternative moderne) # Seuls les homologues WireGuard autorisent SSH iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j ACCEPT # Réseau WireGuard iptables -A INPUT -p tcp --dport 22 -j DROP # 3. Solution basée sur IPSec (Enterprise) # SSH uniquement via le tunnel IPSec iptables -A INPUT -p tcp --dport 22 -m policy --dir in --pol ipsec -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP

Restrictions géographiques IP: Intégration de GeoIP

Pour les organisations avec des emplacements géographiques clairement définis, des restrictions basées sur GeoIP peuvent être mises en œuvre. Cela bloque automatiquement les accès provenant de pays inattendus.

Mise en œuvre avec GeoIP:

# Installation des bases de données GeoIP apt install -y geoip-database-contrib xtables-addons-common # Chargement de modules GeoIP modprobe xt_geoip # Autoriser uniquement certains pays (codes ISO) iptables -A INPUT -p tcp --dport 22 -m geoip --src-cc FR,AT,CH -j ACCEPT # Région DACH iptables -A INPUT -p tcp --dport 22 -m geoip ! --src-cc FR,AT,CH -j DROP # Bloquer le reste # Logging pour les pays bloqués iptables -A INPUT -p tcp --dport 22 -m geoip ! --src-cc FR,AT,CH -j LOG --log-prefix "SSH-GeoBlock: "

Contrôle d'accès dynamique SSH: Port Knocking

Port Knocking peut être implémenté pour les environnements particulièrement critiques pour la sécurité. SSH est bloqué par défaut et ne s'ouvre qu'après une séquence spécifique de paquets réseau.

Avantages de port knocking:

  • Mode furtif: Le port SSH est invisible pour l'analyse des ports
  • Authentification supplémentaire: La séquence Knock agit comme une pré-authentification
  • Délais d'attente automatiques: L'accès se ferme à nouveau après une période définie

Inconvénients:

  • Complexité: Augmente considérablement la complexité administrative
  • Point de défaillance unique: Le knocking mal configuré bloque tout le monde
  • Débogage: Les problèmes de réseau sont plus difficiles à diagnostiquer
# knockd Installation et configuration apt install -y knockd # knockd Configuration cat > /etc/knockd.conf << 'EOF' [options] UseSyslog [openSSH] sequence = 7000,8000,9000 seq_timeout = 5 command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn [closeSSH] sequence = 9000,8000,7000 seq_timeout = 5 command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn EOF # knockd Activer le service systemctl enable --now knockd # Utilisation côté client knock proxmox-server.local 7000 8000 9000 # Ouvrir SSH ssh admin@proxmox-server.local # Connexion SSH knock proxmox-server.local 9000 8000 7000 # Fermer SSH

SSH-Session-Monitoring et Alerting

En plus des restrictions d'accès, toutes les sessions SSH doivent être surveillées et les activités suspectes signalées.

# Extension de l'enregistrement des sessions SSH cat >> /etc/ssh/sshd_config << 'EOF' # Logging détaillé LogLevel VERBOSE SyslogFacility AUTH # Enregistrement de session (si autorisé par la loi) ForceCommand /usr/local/bin/ssh-session-logger EOF # Script d'enregistreur de session (exemple) cat > /usr/local/bin/ssh-session-logger << 'EOF' #!/bin/bash SESSION_ID=$(date +%Y%m%d_%H%M%S)_$ LOG_DIR="/var/log/ssh-sessions" mkdir -p "$LOG_DIR" # Informations de session loggen echo "$(date): SSH Session Start - Utilisateur: $USER, From: $SSH_CLIENT, TTY: $SSH_TTY" >> "$LOG_DIR/session_$SESSION_ID.log" # Démarrer le shell d'origine (avec enregistrement facultatif) if [ -n "$SSH_ORIGINAL_COMMAND" ]; then exec $SSH_ORIGINAL_COMMAND else exec $SHELL fi EOF chmod +x /usr/local/bin/ssh-session-logger

Ces mesures de sécurité SSH avancées offrent une défense multicouche contre divers vecteurs d'attaque. La combinaison de l'authentification par jeton, de la segmentation du réseau et de la surveillance crée une architecture de sécurité robuste qui résiste étonnamment aux attaques sophistiquées.

Détection d'intrusion: Reconnaître l'ennemi

Fail2Ban - Le videur automatique

Fail2Ban est un système de prévention des intrusions qui surveille les fichiers journaux en temps réel et bloque automatiquement les adresses IP en cas d'activité suspecte. Il est particulièrement efficace contre les attaques par force brute, car il bloque les attaquants après quelques tentatives infructueuses.

Fonctionnement et avantages: Fail2Ban analyse les fichiers journaux avec des expressions régulières (Regex) et détecte les modèles d'attaque. Avec SSH, les tentatives de connexion ont échoué, avec Proxmox Web-Interface Authentication-Failures. Les attaquants détectés sont bloqués pendant un temps configurable, ce qui arrête la plupart des attaques automatisées.

Limites et inconvénients: Fail2Ban est réactif – la première tentative d’attaque est toujours couronnée de succès. Par exemple, les attaquants utilisent également des attaques distribuées provenant de nombreuses adresses IP, ce qui les maintient en dessous des seuils de détection. Et n'oublions pas: Fail2Ban peut également bloquer les utilisateurs légitimes s'ils saisissent plusieurs fois des mots de passe incorrects.

# Installation de Fail2Ban apt update && apt install -y fail2ban # Créer une configuration spécifique à Proxmox cat > /etc/fail2ban/jail.local << 'EOF' [DEFAULT] # Paramètres de base bantime = 3600 findtime = 600 maxretry = 3 backend = systemd ignoreip = 127.0.0.1/8 192.168.1.0/24 # Notifications par e-mail destemail = admin@example.com sendername = Fail2Ban mta = sendmail action = %(action_mwl)s # SSH Protection [sshd] enabled = true mode = port agressif = ssh logpath = %(sshd_log)s banaction = iptables-multiport maxretry = 2 findtime = 3600 bantime = 86400 # Proxmox Web Interface Protection [proxmox] enabled = true port = https,http,8006 filter = proxmox backend = systemd maxretry = 3 findtime = 3600 bantime = 3600 EOF # Créer un filtre Proxmox cat > /etc/fail2ban/filter.d/proxmox.conf << 'EOF' [définition] failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.* ignoreregex = EOF # Démarrer et activer systemctl enable --now fail2ban # Vérifier l'état fail2ban-client status

Les optimisations de configuration expliquent:

Stratégie de Bantime: Un blocage d'une heure (Bantime = 3600) est suffisant pour la plupart des attaques automatisées. Des verrous plus longs peuvent devenir problématiques si des utilisateurs légitimes sont verrouillés accidentellement. SSH utilise un verrouillage 24 heures sur 24, car les attaques SSH sont généralement plus ciblées.

Politique d'escalade: La configuration utilise des verrous progressifs – les attaques SSH entraînent des verrous plus longs que les attaques d’interface web, car SSH permet un accès direct au système et est donc plus critique.

Gestion de liste blanche: Les ignoreip-Le paramètre empêche le blocage des adresses IP internes. Ceci est important pour les réseaux administratifs, mais peut également être exploité par des attaquants déjà présents sur le réseau interne.

Surveillance du système avec Auditd: Le médico-légal numérique

Auditd (Linux Audit Daemon) est le sous-système d'audit de sécurité Linux officiel. Il enregistre les appels système, l'accès aux fichiers, l'exécution des processus et d'autres événements liés à la sécurité au niveau du noyau. Ces journaux sont essentiels pour l'analyse médico-légale, la vérification de la conformité et la détection des menaces persistantes avancées (APT).

Pourquoi Auditd est particulièrement important chez Proxmox: Proxmox gère les infrastructures critiques - machines virtuelles, stockage, configurations réseau. Un hyperviseur compromis peut affecter des dizaines ou des centaines de systèmes invités. Auditd aide à détecter les activités suspectes avant qu'elles ne se propagent.

Aspects de conformité: De nombreux cadres de conformité (PCI-DSS, HIPAA, SOX) exigent des journaux d'audit détaillés. Auditd peut répondre à ces exigences, mais génère également d'importantes quantités de données. Attention : Un système typique peut produire des journaux d'audit par gigaoctets tous les jours.

Impact sur les performances: Auditd fonctionne au niveau du noyau et peut affecter les performances du système. Les charges de travail particulièrement intensives en E/S peuvent être sensiblement plus lentes. La configuration présentée ici se concentre sur les événements critiques pour la sécurité afin de minimiser l'impact sur les performances.

# Auditd installer apt install -y auditd audispd-plugins # Créer des règles d'audit pour Proxmox cat > /etc/audit/rules.d/proxmox.rules << 'EOF' # Surveillance des fichiers de configuration Proxmox -w /etc/pve/ -p wa -k proxmox-config -w /etc/systemd/system/pve*.service -p wa -k proxmox-services # Surveiller les opérations VM/conteneur -w /usr/bin/qm -p x -k vm-management -w /usr/bin/pct -p x -k container-management # Surveiller les commandes privilégiées -a always,exit -F arch=b64 -S execve -F euid=0 -k root-commands -a always,exit -F arch=b32 -S execve -F euid=0 -k root-commands # Surveiller la configuration du réseau -w /etc/network/interfaces -p wa -k network-config -a always,exit -F arch=b64 -S socket -F success=1 -k network-socket EOF # Redémarrer le système d'audit systemctl enable --now auditd yeux règles --load

Règles d'audit en détail:

Surveillance des fichiers (-w): Ces règles surveillent les modifications apportées aux fichiers de configuration critiques. /etc/pve/ contient toute la configuration du cluster, /etc/network/interfaces les paramètres du réseau. Chaque modification est enregistrée, y compris le processus déclencheur et l'utilisateur.

Surveillance des appels système (-a always,exit): Ces règles surveillent les appels système spécifiques. execve est appelé à chaque exécution du programme – le suivi des exécutions racine (euid=0) aide à détecter les attaques d'escalade des privilèges.

Défis de gestion des journaux: Les journaux d'audit se développent rapidement et peuvent épuiser l'espace de stockage. La rotation et l'archivage automatiques sont essentiels. Dans le même temps, les journaux doivent être protégés contre toute manipulation – un compte administrateur compromis pourrait tenter d’effacer ses traces.

Certificats TLS/SSL: Confiance dans un monde indigne de confiance

Le problème des certificats auto-signés

Lors de l'installation, Proxmox crée automatiquement des certificats TLS auto-signés pour l'interface Web et la communication en cluster. Ceux-ci fournissent un cryptage, mais pas d’authentification – les utilisateurs ne peuvent pas vérifier qu’ils communiquent réellement avec le véritable serveur Proxmox.

Risques de sécurité des certificats auto-signés:

  • Attaques de type man-in-the-middle: Les attaquants peuvent créer de faux certificats et se faire passer pour des serveurs Proxmox
  • Impossible d'épingler le certificat: Les clients ne peuvent pas faire la distinction en toute sécurité entre les certificats authentiques et les certificats falsifiés
  • Comportement de l'utilisateur: Les alertes constantes du navigateur incitent les utilisateurs à ignorer les alertes de sécurité

Problèmes de conformité: De nombreuses politiques de sécurité et cadres de conformité interdisent les certificats auto-signés dans les environnements de production. Par exemple, PCI-DSS exige explicitement des certificats de confiance pour tous les services accessibles au public.

Mise en œuvre de certificats de confiance

Pour les services internes, plusieurs options s'offrent à vous: sa propre autorité de certification (AC), Let’s Encrypt pour les services accessibles au public, ou des certificats commerciaux pour une compatibilité maximale.

Intégration de Let’s Encrypt: Let’s Encrypt propose des certificats gratuits et automatiquement renouvelés. Proxmox dispose d'une prise en charge ACME intégrée qui automatise l'ensemble du processus. L'inconvénient: Let’s Encrypt nécessite une résolution DNS publique ou une accessibilité HTTP, ce qui n’est pas toujours possible ou souhaité.

Propre CA pour les services internes: Une autorité de certification dédiée offre un contrôle total et fonctionne également sur des réseaux isolés. Cependant, les certificats CA-Root doivent être installés sur tous les systèmes clients, ce qui devient complexe dans les grands environnements.

# Let's Encrypt Certificat pour l'interface Web Proxmox # Tout d'abord, configurer le plug-in ACME (via l'interface Web: Centre de données → ACME) # Alternativement: Intégrer votre propre certificat CA # 1. Copier le certificat et la clé vers /etc/ssl/certs/ # 2. À propos de l'interface web: Node → Certificats → Upload Custom Certificate # Configuration TLS pour pveproxy härtfen cat >> /etc/default/pveproxy << 'EOF' # Paramètres de sécurité TLS CIPHER_SUITE="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256" PROTOCOL="TLSv1.2,TLSv1.3" EOF systemctl restart pveproxy

Le durcissement de la configuration TLS explique:

Limitation de la suite Cipher: La configuration est limitée aux algorithmes de cryptage modernes et sécurisés. Les calculateurs plus anciens tels que RC4, 3DES ou les algorithmes basés sur MD5 sont connus pour être faibles et exclus.

Restriction de protocole: TLS 1.0 et 1.1 ont des vulnérabilités connues et ne doivent plus être utilisées. La limitation à TLS 1.2 et 1.3 élimine ces risques, mais peut entraîner des problèmes de compatibilité avec les clients très anciens.

Sécurité de sauvegarde: Protection contre le pire

Pourquoi le chiffrement de sauvegarde est essentiel

Les sauvegardes contiennent toutes les données sensibles du système d’origine – mots de passe, configurations, données utilisateur, secrets commerciaux. Les sauvegardes non cryptées constituent un risque majeur pour la sécurité, en particulier lorsqu'elles sont stockées sur des supports externes ou dans le cloud.

Vectors d'attaque sur les sauvegardes:

  • Physical Theft: Les médias de sauvegarde volés permettent des attaques hors ligne
  • Brèches dans le cloud: Les comptes de stockage cloud compromis exposent toutes les sauvegardes
  • Threats d'initiés: Les administrateurs disposant d'un accès de sauvegarde peuvent extraire des données sensibles
  • Ransomware: Les variantes modernes de ransomware détruisent délibérément les sauvegardes avant le chiffrement

Exigences de conformité: GDPR/GDPR exige explicitement la protection des données personnelles, même dans les sauvegardes. Les sauvegardes non cryptées peuvent entraîner des amendes importantes. Des exigences similaires peuvent être trouvées dans HIPAA, PCI-DSS et d'autres frameworks.

Stratégies de sauvegarde cryptées

Proxmox offre un chiffrement de sauvegarde intégré avec AES-256. La mise en œuvre se fait au niveau des tâches de sauvegarde et est transparente pour les systèmes invités.

Défis de gestion des clés: La clé de chiffrement de sauvegarde est le point de défaillance unique pour toutes les sauvegardes. Si vous perdez la clé, toutes les sauvegardes sont inutilisables. Dans le même temps, la clé doit être stockée de manière suffisamment sécurisée pour que les attaquants ne puissent pas l'obtenir. Un module de sécurité matérielle (HSM) ou un service de gestion des clés (KMS) est recommandé pour les environnements critiques.

# Créer une clé de chiffrement de sauvegarde pvesm set <storage-id> --encryption-key /etc/pve/backup-encryption.key # Configurer les sauvegardes chiffrées automatiques cat > /etc/cron.d/proxmox-backup << 'EOF' # Sauvegardes de VM cryptées quotidiennes à 2h00 0 2 * * root /usr/bin/vzdump --all --compress zstd --encrypt 1 --storage backup-storage EOF

Stockage de sauvegarde immutable: Protection contre les ransomwares

Les sauvegardes inaltérables (immutables) ne peuvent plus être modifiées ou supprimées après leur création. C'est la protection la plus efficace contre les attaques de ransomware, car même un administrateur complètement compromis ne peut pas détruire les sauvegardes.

Options de mise en œuvre:

  • Proxmox Backup Server: Fournit des fonctionnalités d'immutabilité natives
  • Stockage d'objets: Stockage compatible S3 avec Object Lock
  • WORM-Media: Solutions matérielles Write-Once-Read-Many
  • Systèmes Air-Gapped: Systèmes de sauvegarde physiquement séparés

Retention Policy Considerations: Les sauvegardes immutables nécessitent une planification minutieuse des temps de conservation. Les temps de rétention trop courts offrent peu de protection et trop longtemps entraînent des coûts de stockage élevés. La règle de sauvegarde 3-2-1 (3 copies, 2 supports différents, 1 hors site) doit toujours être suivie.

# Configurer Proxmox Backup Server avec des politiques de rétention # (À propos de l'interface Web PBS: Datastore → Prune & GC) # Exemple pour retention policy cat > /etc/proxmox-backup/prune-jobs.json << 'EOF' { "keep-daily": 7, « Keep-weekly »: 4, « Keep-monthly »: 6, « Keep-yearly »: 1 } EOF

Audits de conformité et de sécurité: Mesurer ce qui compte

Audits de sécurité automatisés avec Des outils comme Lynis

Les contrôles de sécurité manuels prennent du temps et sont sujets aux erreurs. Outils automatisés Comme Lynis, il est possible de vérifier systématiquement des centaines d'aspects de la sécurité et d'identifier les vulnérabilités que les gens ignoreraient.

Ce que fait Lynis: Lynis effectue plus de 300 tests de sécurité différents, allant des paramètres du noyau aux autorisations de fichiers, en passant par les configurations réseau. Il détecte non seulement les vulnérabilités connues, mais aussi les erreurs de configuration et les violations des meilleures pratiques.

Limites des audits automatisés: Les outils automatisés ne peuvent détecter que les problèmes connus. Ils ne comprennent pas le contexte de l'application et peuvent donc générer de faux positifs. Une règle de pare-feu critiquée par Lynis comme étant «trop permissive» pourrait être correcte pour le cas d’utilisation spécifique.

# Lynis installer apt install -y lynis # Effectuer une analyse complète de la sécurité lynis audit system --cronjob --logfile /var/log/lynis.log # Analyser les résultats grep "Suggestion" /var/log/lynis.log

Intégration dans les pipelines CI/CD: Lynis peut être intégré dans des pipelines de déploiement automatisés. Les nouveaux déploiements système sont automatiquement analysés pour détecter les problèmes de sécurité avant leur mise en production. Cela permet une «sécurité dès la conception» plutôt qu’un durcissement ultérieur.

CIS Benchmark Implementation: Respecter les normes de l'industrie

Le Center for Internet Security (CIS) publie des benchmarks de sécurité détaillés pour tous les systèmes d'exploitation et applications courants. Ces benchmarks sont basés sur le consensus des experts en cybersécurité et reflètent les meilleures pratiques.

Pourquoi les benchmarks CIS sont importants:

  • Protection juridique: De nombreuses cyber-assurances exigent la conformité CIS
  • Cadres de conformité: NIST, ISO 27001 et d'autres font référence aux référentiels CIS
  • Approche systématique: Plus de 100 points de contrôle spécifiques pour les systèmes Linux
  • Risk-Based: Chaque contrôle est classé en fonction du risque et de l'impact

Défis de mise en œuvre: La conformité CIS complète peut rendre les systèmes inutilisables. De nombreux contrôles sont trop restrictifs pour des cas d'utilisation spécifiques. Une approche pragmatique sélectionne les contrôles les plus importants et documente les exceptions délibérées. Cela peut ressembler à ceci:

# Paramètres du noyau conformes à la norme CIS cat >> /etc/sysctl.d/99-cis-hardening.conf << 'EOF' # Network Security net.ipv4.ip_forward = 1 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.all.log_martians = 1 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.def.ault_filter_p = 1 net.ipv4.icmp_cynies = 1 net. # IPv6 Security (si activé) net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 EOF sysctl -p /etc/sysctl.d/99-cis-hardening.conf

Paramètres du noyau en détail:

IP Forwarding: Chez Proxmox, il faut net.ipv4.ip_forward = 1 Restez activé, car la fonctionnalité Bridge l'exige. Les configurations CIS standard désactiveraient cela.

ICMP Redirects: La désactivation des redirections ICMP empêche certaines attaques de routage, mais peut entraîner des problèmes de connectivité dans les topologies réseau complexes.

Filtrage inversé du chemin: rp_filter = 1 active un contrôle strict du chemin inverse et empêche les attaques d'usurpation d'adresse IP. Cependant, cela peut causer des problèmes avec le routage asymétrique.

Suivi et réponse aux incidents: Savoir ce qui se passe

Stratégies de journalisation centralisées

Dans les environnements informatiques modernes, des millions de logs sont créés chaque jour. Sans agrégation centralisée et analyse intelligente, il est impossible de détecter les événements liés à la sécurité. Une stratégie de journalisation bien pensée est donc fondamentale pour une sécurité efficace.

Agrégation des logs avec Syslog: Syslog est la norme pour les systèmes Unix/Linux, mais la configuration par défaut n'est pas optimisée pour la surveillance de la sécurité. Les événements importants peuvent être submergés par le flot de messages de débogage. Une catégorisation structurée selon Severity et Facility est essentielle.

Intégration du SIEM: Les systèmes SIEM (Security Information and Event Management) peuvent corréler les données des journaux et détecter les anomalies. Cependant, ils sont complexes à configurer et nécessitent des processus de tuning continus pour réduire les faux positifs.

# Configurer Rsyslog pour la redirection centralisée des logs cat >> /etc/rsyslog.conf << 'EOF' # Enregistrement à distance pour les événements de sécurité *.info;mail.none;authpriv.none;cron.none @@syslog-server.company.local:514 authpriv.* @@syslog-server.company.local:514 EOF systemctl restart rsyslog

Protection des données et conservation des journaux: Les journaux peuvent contenir des données personnelles et sont donc soumis à la réglementation GDPR/RGPD. Une politique de rétention claire et des stratégies d'anonymisation sont juridiquement nécessaires. Dans le même temps, les journaux doivent rester disponibles pour les analyses médico-légales, ce qui constitue un exercice d’équilibre difficile. Pour ce faire, nous pourrions probablement créer plusieurs articles distincts.

Surveillance basée sur des métriques avec l'exemple de Prometheus

Alors que les journaux documentent les événements, les métriques fournissent des informations continues sur l'état et les performances du système. Les anomalies dans les mesures peuvent être des indicateurs précoces de problèmes de sécurité. À titre d'exemple, j'aime prendre une charge CPU inhabituelle ici, cela pourrait indiquer l'exploitation minière cryptographique. En revanche, un trafic réseau anormal indiquerait une exfiltration de données.

Avantages de l'architecture Prometheus:

  • Pull-based: Prometheus interroge activement les mesures, ce qui est plus robuste que les modèles push
  • Time-Series: Les données historiques permettent l'analyse des tendances et la création de lignes de base
  • Alerte flexible: Des règles d'alerte complexes basées sur plusieurs métriques possibles

Défis de mise à l'échelle: Prometheus stocke toutes les données localement, ce qui entraîne des problèmes de stockage dans les environnements de grande taille. Les configurations fédérées ou les solutions de stockage à distance deviennent complexes. L'interrogation de longues périodes peut devenir très gourmande en ressources.

# Installer un exportateur de nœuds pour les métriques système apt install -y prometheus-node-exporter # Exporter les mesures spécifiques à Proxmox cat > /etc/systemd/system/pve-exporter.service << 'EOF' [Unit] Description=Proxmox VE Exporter After=network.target [Service] Type=simple ExecStart=/usr/bin/pve-exporter Restart=always User=prometheus [Install] WantedBy=multi-user.target EOF

Plan de maintenance et sécurité opérationnelle

Le rythme de la sécurité

Vous le savez, je le répète quand même: La sécurité n'est pas un projet unique, mais un processus continu. Sans maintenance et mises à jour régulières, même le meilleur concept de sécurité dégénère. Votre plan de maintenance structuré garantit que tous les aspects sont vérifiés régulièrement!

Tâches de sécurité quotidiennes: Ces tâches doivent être automatisées ou effectuées dans le cadre de la routine quotidienne. Ils servent à détecter les problèmes à un stade précoce avant qu'ils ne deviennent critiques.

  • Fail2Ban-Logs Review: Des modèles d'attaque inhabituels peuvent indiquer des attaques ciblées
  • Statut de sauvegarde: L'échec des sauvegardes est un risque critique pour la sécurité
  • Suivi des ressources: Des anomalies peuvent indiquer des compromissions

Approfondissement hebdomadaire: Les tâches hebdomadaires nécessitent plus de temps et d'attention, mais fournissent des informations plus approfondies sur l'état de la sécurité.

  • Analyse du journal d'audit: Détecter les tendances et les anomalies dans le comportement des utilisateurs
  • Revue de mise à jour de sécurité: Évaluer les mises à jour disponibles et planifier le déploiement
  • Tests d'intégrité de sauvegarde: Effectuer un test de récupération aléatoire

Examens stratégiques mensuels: Ces tâches nécessitent souvent une collaboration entre les équipes et peuvent entraîner des changements majeurs.

  • Tests de pénétration: Tests de sécurité externes ou internes
  • Révisions de la règle du pare-feu: Identifier les règles obsolètes ou trop permissives
  • Surveillance des certificats: Renouveler les certificats arrivant à expiration à temps
  • Revues d'accès utilisateur: Vérification des autorisations des utilisateurs

Analyses trimestrielles de profondeur: Ces examens approfondis garantissent que la stratégie de sécurité suit l'évolution des menaces et des besoins de l'entreprise.

  • Tests de reprise après sinistre: Jouer des scénarios DR complets
  • Mises à jour de réponse aux incidents: Intégrer les leçons tirées des incidents
  • Formation à la sensibilisation à la sécurité: Informer les employés des nouvelles menaces
  • Examens du contrôle d'accès basé sur les rôles: Ajuster les définitions des rôles aux changements organisationnels

Gestion du changement et documentation

Tout changement de sécurité doit être documenté et compréhensible. Les modifications non documentées présentent un risque important: elles peuvent être annulées par inadvertance ou prêter à confusion en cas de changement de personnel.

Meilleures pratiques de documentation:

  • rationnel: Pourquoi la modification a-t-elle été apportée?
  • Évaluation de l'impact: Quels systèmes sont concernés?
  • Plan de rollback: Comment annuler la modification?
  • Résultats de test: Comment la modification a-t-elle été validée?

Principe des quatre yeux: Les modifications critiques pour la sécurité doivent toujours être validées par un deuxième administrateur. Cela réduit les erreurs et vous offre également une sécurité supplémentaire, par exemple contre les menaces internes.

Résumé: Des environnements Proxmox sécurisés en pratique

Les mesures de sécurité présentées ici constituent un système complet de défense en profondeur. Aucune mesure individuelle n'est parfaite, mais en combinaison, ils offrent une protection robuste contre la plupart des menaces.

Stratégie de mise en œuvre: Mettez en œuvre ces mesures progressivement, en commençant par les plus basiques (mises à jour, pare-feu, durcissement SSH), puis travaillez sur des systèmes plus complexes (surveillance, conformité). N'oubliez pas: Teste soigneusement chaque changement d'abord dans un environnement de stage/laboratoire.

Équilibre entre sécurité et facilité d'utilisation: Des mesures de sécurité excessives peuvent rendre les systèmes inutilisables et inciter les utilisateurs à contourner les contrôles de sécurité. Trouvez le bon équilibre pour votre environnement et le paysage de menaces correspondant.

Amélioration continue: Le paysage des menaces ne cesse d'évoluer. Ce qui est sûr aujourd'hui peut être vulnérable demain. Restez informé des nouvelles menaces et technologies de sécurité et adaptez votre stratégie en conséquence.

Remarque importante concernant la mise en œuvre: Toutes les configurations présentées ici doivent être adaptées à votre environnement spécifique. Assurez-vous de bien tester chaque changement avant de l'appliquer en production. Conservez également des sauvegardes à jour de votre configuration et documentez soigneusement toutes les modifications.

Et oui, là aussi, je me répète probablement pour la drölften fois: La sécurité de l'infrastructure Proxmox est aussi un marathon, pas un sprint. Avec les pratiques présentées ici et une approche disciplinée, vous pouvez construire et exploiter une plate-forme de virtualisation robuste et sécurisée.

Les autres parties de cette série d'articles, je vous les ai reliées ici: Partie 1: réseau | Deuxième partie: Stockage | Troisième partie: Sauvegarde | Partie 4 : sécurité | Cinquième partie: performance

Stephan
|
| | | | | |
vers le haut | accueil | pour la recherche