File integrity monitoring and YARA
Two of the agent’s security probes look at files rather than processes. File integrity monitoring (FIM) notices when a watched file changes and tells you who changed it. YARA scans executables and changed files against malware signatures. Both run on Linux hosts with the eBPF module, both feed the security event stream, and both need nothing installed beyond the agent.
File integrity monitoring
Section titled “File integrity monitoring”What is watched
Section titled “What is watched”FIM turns on when the File Integrity policy is enabled for a host (it is enabled by default; see Customizing detection rules). The default watch list is the places an intruder or a bad deploy writes:
/usr/bin /usr/sbin /bin /sbin /usr/local/bin /usr/local/sbin /etcwith these files excluded because they change on their own:
/etc/mtab, /etc/resolv.conf, /etc/ld.so.cache, /etc/adjtime,
/etc/machine-id, /etc/.updated, /etc/.pwd.lock.
Files are hashed with SHA-256 on first sight and re-hashed when the kernel reports a write-intent open, unlink, rename, chmod, chown, an extended-attribute change, a timestamp change, or a link or symlink creation. Bursts are debounced (750 ms) so a single edit is one event. Only hashes are kept; the agent never uploads file contents.
The event
Section titled “The event”A change produces one of three events, all with source: fim:
| Event | Priority | When |
|---|---|---|
| File Integrity Violation | critical | A watched file changed outside any expected context |
| Expected File Change | informational | The writing process was a package manager (apt, dpkg, yum, dnf, rpm, zypper) and package-manager suppression is on, which it is by default |
| Maintenance Window Change | informational | The change happened inside an open maintenance window or change on that host |
Each event records the path, the kind of change, the old and new hash, the hash algorithm, and the process and PID that made the change - which is usually the answer to “was this us?”. FIM events bypass the agent’s noise filter; they always reach the stream, and a violation raises an alert through the security alert bridge.
Reviewing changes
Section titled “Reviewing changes”Every violation is also listed on the host’s File Integrity section under Security, then Servers, with a status of pending or approved. Two actions:
- Approve the selected paths: the current hashes become the new baseline for those files and the pending rows clear. Use it after a deploy you recognise.
- Rebaseline the host: every watched file is re-hashed as the new known-good state. Use it once after installing the agent on a host that was mid-change, or after a large planned rebuild.
Both are queued to the agent over its connection and confirmed on the same card. The same list is what change verification reads: after a change request completes, the paths changed inside its window are compared with what the change declared.
Adding paths
Section titled “Adding paths”The watch list, excludes, hash algorithm, and debounce are part of the
host’s agent configuration, pushed from the Detections page. Add an
application directory (/opt/app/bin, /srv/www/current) when you
want deploys to show up as expected or unexpected changes; leave data
directories and log directories out, or every write will be an event.
What is scanned
Section titled “What is scanned”With the file integrity policy active, the agent also runs YARA:
- on every executable at the moment it is executed;
- on every file FIM reports as added or modified.
Scans are de-duplicated by path and modification time, run on a bounded
worker so a burst cannot starve the host, and use a yara binary
bundled with the agent (/usr/lib/alertkick-agent/bin/yara), falling
back to one on the path.
A curated base pack of permissively licensed rules ships to every
workspace. Your own rules go under Security, then YARA Rules: give
the rule a name and paste its content (it must contain at least one
rule block). Workspace rules are appended to the base pack; the bundle
is versioned by its SHA-256 and pushed to every host with the security
module over the agent’s authenticated connection - no keys on hosts,
nothing to copy around. Adding or deleting a rule fans the new bundle
out automatically; Sync rules on a host’s File Integrity card forces
a resend. The card shows whether YARA is enabled and available, the
binary path, the rules hash, and when the host last synced.
Rules live at /var/lib/alertkick-agent/yara/rules.yar on the host and
are hot-swapped without restarting the agent.
The event
Section titled “The event”A match raises a YARA Match event at critical priority with
category: malware, the file path, the rule set version, and the
matched rule name. It goes through the same AI triage
and alerting as any other critical detection.
To test the pipeline end to end, the base pack includes the EICAR test
signature: writing the EICAR string to a file under /tmp and marking
it executable should produce a match within seconds.
Where the settings live
Section titled “Where the settings live”| Setting | Where |
|---|---|
| Turn FIM and YARA on or off per host | Security, then Detections: the File Integrity policy, and the per-host override tab |
| Watch paths, excludes, hash algorithm | Host agent configuration on the Detections page |
| Package-manager suppression | Forced on; expected changes are recorded as informational events |
| Approve or rebaseline | The host’s File Integrity card under Security, then Servers |
| YARA rules | Security, then YARA Rules |
Next steps
Section titled “Next steps”- Change tracking and change control for verifying declared changes against FIM
- Security events for reading the stream
- Customizing detection rules for policies and per-rule severity