Vérifier les permissions du fichier /etc/ipsec.secrets
Garantit que /etc/ipsec.secrets n'est ni modifiable ni exécutable par le groupe ou les autres et exempt des bits setuid, setgid ou sticky (mode cible 0600 root:root).
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
/etc/ipsec.secrets stocke les secrets d'authentification IPsec, clés pré-partagées (PSK) et références aux clés privées servant à authentifier les pairs VPN. Quiconque peut le lire peut usurper une extrémité de tunnel ou déchiffrer du trafic capturé ; quiconque peut l'écrire peut y substituer son propre secret. Il doit être restreint à root (idéalement 0600) pour garder les identifiants VPN confidentiels et authentiques.
Ce que vérifie Pavois
Pavois lit les permissions réelles de l'inode /etc/ipsec.secrets avec la ressource InSpec file (un stat), sous only_if. Elle interdit l'écriture et l'exécution groupe/autres ainsi que tout bit setuid/setgid/sticky. Comme ce fichier contient des secrets, la cible recommandée est 0600 root:root (le contrôle impose au moins l'absence d'écriture/exécution groupe/autres ; complétez par un chmod 0600 manuel pour retirer aussi la lecture). Lire le mode réel détecte une dérive qu'un contrôle de défaut de paquet manquerait.
only_if { file('/etc/ipsec.secrets').exist? }
describe file('/etc/ipsec.secrets') do
it { should_not be_executable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%a %U %G' /etc/ipsec.secrets. La sortie attendue est le mode 600 appartenant à root root, soit 600 root root. Toute lecture, écriture ou exécution groupe/autres, ou un bit spécial, signale un problème.
Inspecter et investiguer
Le chargement des secrets et les résultats d'authentification sont journalisés par le démon : journalctl -u ipsec / journalctl -u strongswan ; ipsec status confirme l'authentification des tunnels. Après modification des secrets, exécutez ipsec secrets (Libreswan) pour les recharger et vérifiez l'absence d'erreurs d'authentification.
Remédiation
Aucune remédiation automatique n'est définie ; appliquez-la manuellement : chmod 0600 /etc/ipsec.secrets && chown root:root /etc/ipsec.secrets, puis rechargez les secrets avec ipsec secrets (ou ipsec reload).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0644 |
|---|---|
| path | /etc/ipsec.secrets |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Le mode 0600 root:root est sûr, le démon IPsec lit les secrets en root. Le changement de permissions ne peut pas couper un tunnel à lui seul. Précaution : ne modifiez pas les valeurs des secrets pendant le durcissement ; une PSK ou une référence de clé invalide provoquera des échecs d'authentification et les tunnels ne s'établiront pas au prochain rechargement. Vérifiez ensuite avec ipsec status. Laisser le fichier lisible permet à un utilisateur local de voler les PSK et d'usurper un pair.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.