The paths that actually matter
Watching the whole filesystem produces noise proportional to how busy the server is. A useful configuration concentrates on the places where compromise has to leave a mark.
- Authentication and accounts: /etc/passwd, /etc/shadow, /etc/group and /etc/gshadow, where a new user or a changed privilege shows up.
- SSH: /etc/ssh/sshd_config and its drop-in directory, plus authorized_keys files, where persistent access is granted.
- Scheduled execution: /etc/crontab, /etc/cron.d and per-user crontabs, plus systemd units and timers.
- Privilege: the sudoers configuration, setuid binaries, and preload files such as ld.so.preload.
- Name resolution: /etc/hosts and /etc/nsswitch.conf, which are quietly effective redirection targets.
- Web content: served directories, where webshells and injected scripts land, including WordPress core, plugins and themes.
Expected change versus suspicious change
This is the entire problem. A routine apt upgrade rewrites a large number of files in a burst, all of them legitimate. A configuration management run does the same. If every one of those is an alert, the signal is buried within a week and the system is switched off shortly after.
Useful discrimination comes from context rather than from the change itself: whether the change coincided with a package operation, whether the file is one that legitimately changes, whether it arrived alongside other suspicious activity such as a new process or an SSH login from an unusual address.
This is where SecAI leans on correlation. A modified sshd_config on its own is worth knowing about. A modified sshd_config twenty seconds after a successful login from an address that had been failing repeatedly is an incident.
What FIM catches that nothing else does
Its particular value is persistence. An attacker who gains access wants to keep it, and keeping it almost always means writing something: a key, a cron entry, a unit file, a modified binary.
That is also why it is the piece that makes cleanup succeed. Removing a webshell without finding the cron entry that restores it produces a server that is compromised again in days, and file monitoring across the persistence paths is how the second half gets found.
WordPress and web content
On a server hosting websites, the web root is where compromise usually becomes visible first. SecAI covers WordPress core, plugin and theme files specifically, which matters because those have a knowable expected state: core files should match the released version, and a modified core file is unambiguous in a way that a modified application file is not.
Automated WordPress file integrity monitoring is included on the Pro plan and above.
The audit trail
Because changes are recorded with what changed and when, the history is usable as evidence: a timeline of modifications to sensitive files, rather than an assertion that monitoring exists. That history feeds the compliance reports, which support an audit programme without claiming to constitute compliance by themselves.