Vérifier les permissions du fichier /etc/ipsec.conf
Garantit que /etc/ipsec.conf n'est pas modifiable par le groupe ou les autres et ne porte aucun bit exécutable, setuid, setgid ou sticky.
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.conf contient la configuration IPsec de Libreswan/strongSwan : définitions de connexions, pairs, phases et choix de chiffrement des tunnels VPN qui protègent le trafic. S'il est modifiable par le groupe ou les autres, un attaquant peut rediriger un tunnel, abaisser ses algorithmes ou désactiver une connexion, compromettant la confidentialité de tout ce qui transite par IPsec. Restreindre l'écriture à root maintient la politique VPN sous contrôle administratif exclusif.
Ce que vérifie Pavois
Pavois lit les permissions réelles de l'inode /etc/ipsec.conf avec la ressource InSpec file (un stat), sous only_if pour ignorer les hôtes sans pile IPsec. Elle interdit l'écriture groupe, l'écriture autres et tout bit exécutable/setuid/setgid/sticky, exigeant de fait un mode au plus permissif égal à 0644 root:root. Inspecter les permissions réelles détecte une dérive introduite par une édition manuelle ou un passage de gestion de configuration qu'une hypothèse de défaut de paquet manquerait.
only_if { file('/etc/ipsec.conf').exist? }
describe file('/etc/ipsec.conf') 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.conf. La sortie attendue est le mode 644 (ou plus strict) appartenant à root root, par ex. 644 root root. Tout droit d'écriture groupe/autres ou bit spécial fait échouer la règle.
Inspecter et investiguer
L'activité IPsec et les (re)chargements de configuration sont journalisés par le démon : journalctl -u ipsec (Libreswan) ou journalctl -u strongswan, et ipsec status / ipsec statusall affichent les tunnels actifs. Après une modification, rechargez avec ipsec reload et confirmez que les tunnels restent actifs.
Remédiation
Aucune remédiation automatique n'est définie ; appliquez-la manuellement : chmod u-x,go-wx /etc/ipsec.conf && chown root:root /etc/ipsec.conf (cible 0644 root:root), puis ipsec reload pour prendre en compte proprement tout changement concurrent.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0644 |
|---|---|
| path | /etc/ipsec.conf |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Le durcissement à 0644 root:root est peu risqué, le démon IPsec s'exécute en root. Le seul changement de permissions ne peut pas couper un tunnel. Précaution : évitez de modifier le contenu des connexions pendant le durcissement ; une erreur de syntaxe dans ipsec.conf peut empêcher un tunnel de s'établir au prochain rechargement, ce qui pourrait couper une connectivité dépendante du VPN. Vérifiez ensuite avec ipsec status. Laisser le fichier modifiable par le groupe ou les autres permet à un non-root d'altérer la politique VPN.
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.