DEV Community

Syed Masood Shah
Syed Masood Shah

Posted on

The server got hit and I only knew because a file quietly changed itself

Nobody ever gets excited about file integrity monitoring. It's the security control you configure once, forget about, and only remember exists when the auditor asks for a change log. I get it. It's not shiny. But last month it's the only thing that told me something was wrong.

I run a small business infrastructure stack — a few self-hosted services, a couple of public-facing containers, the usual. One morning I got an alert that a binary inside a running container had been modified. Not by a deploy. Not by me. A base image hash had changed when nothing in the pipeline had pushed.

That single alert started it. I dug in, found the container needed patching, and it turned out to be a legit supply-chain issue on the image. Harmless in the end. But the point stuck with me: the whole time, not one log line screamed. The firewall didn't care. The IDS didn't flinch. The only evidence was a file that changed when it shouldn't have.

That's what file integrity monitoring actually buys you. It's not watching logs. It's watching the filesystem and saying "this hash is not what it was, and nothing authorized changed it."

I use Wazuh for this. It runs as a Docker stack, which is the only way I'd get a small business to adopt it at all. Wazuh does the agent-side monitoring, so each host reports what files changed, when, and against what baseline. It keeps a running collection of known-good hashes and flags anything that drifts.

The part I care about as an admin is that I can tune it. Left alone, FIM alerts on everything and you get a wall of noise that teaches you to ignore it. So I lay out the known-good paths first, then scope the monitoring to the things that actually matter: binaries, config files, web root. Cron thinks it owns /tmp? I don't want ten thousand alerts a day about it.

For a small shop the realistic pattern is: install the agent on the hosts you care about, let it build a baseline for a few days, then set alerts on checksum changes and new files appearing in sensitive directories. Keep the frequency sane. Every second is overkill; once a minute is plenty to catch a compromise without melting the disk.

The other thing FIM doubles as is an audit trail that most small businesses don't have. When the auditor asks what changed on your server in the last 30 days, a Wazuh dashboard beats a shrug and a hope. You can pull up exactly the file, the timestamp, and who was on the box.

This is one of the three stacks in the SMB Security Pack I sell — SIEM, an IPS with a Grafana dashboard, and encrypted restic backups. All Docker, all self-hosted, one-time $15. The FIM piece is buried in the SIEM stack and it's the quietest part of the setup, but it's the one that earns its keep when something sneaks through everything else.

If you run servers for a business and your only alarm is reading logs after the fact, that's a gap. FIM is cheap to set up and it covers a blind spot nobody else does.

Top comments (0)