Verify Permissions On /etc/ipsec.conf File
Ensures /etc/ipsec.conf is not writable by group or other and carries no executable, setuid, setgid or sticky bits.
Checked against the content of a persistent configuration file, the source of truth that survives reboots.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
/etc/ipsec.conf holds the Libreswan/strongSwan IPsec configuration: connection definitions, peers, phases and cipher choices for the VPN tunnels protecting traffic. If it is writable by group or other, an attacker can redirect a tunnel, downgrade its ciphers or disable a connection, undermining the confidentiality of everything carried over IPsec. Restricting writes to root keeps the VPN policy under exclusive administrative control.
What Pavois checks
Pavois reads the real inode permissions of /etc/ipsec.conf with the InSpec file resource (a stat), under only_if so hosts without an IPsec stack are skipped. It forbids group-write, other-write and any execute/setuid/setgid/sticky bit, effectively requiring a mode no looser than 0644 root:root. Inspecting the live permissions catches drift introduced by a manual edit or a config-management run that a packaged-default assumption would miss.
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 }
endHow to verify it is applied
Run stat -c '%a %U %G' /etc/ipsec.conf. Expected output is mode 644 (or stricter) owned by root root, e.g. 644 root root. Any group/other write or special bit fails the rule.
Inspect & investigate
IPsec activity and config (re)loads are logged by the daemon: journalctl -u ipsec (Libreswan) or journalctl -u strongswan, and ipsec status / ipsec statusall show active tunnels. After an edit, reload with ipsec reload and confirm tunnels stay up.
Remediation
No automated remediation is defined, so apply it manually: chmod u-x,go-wx /etc/ipsec.conf && chown root:root /etc/ipsec.conf (target 0644 root:root), then ipsec reload to pick up any concurrent change cleanly.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0644 |
|---|---|
| path | /etc/ipsec.conf |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Tightening to 0644 root:root is low-risk, the IPsec daemon runs as root. The permission change alone cannot drop a tunnel. Precaution: avoid editing connection content while hardening; a syntax error in ipsec.conf can prevent a tunnel from establishing on the next reload, which could cut connectivity that depends on the VPN. Verify with ipsec status afterwards. Leaving the file group/other-writable lets a non-root user tamper with VPN policy.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.