Part of the Self-Hosting Security series.
Four warnings came back from the rootkit scan, and for about twenty minutes my evening was ruined. Warnings from a rootkit checker have a particular smell to them — something on the box is not what it claims to be, and the scan is telling you it noticed. Here is what the report actually said:
/usr/.qwen
/dev/shm/PostgreSQL.*
/root/.local/bin/env
/usr/bin/.summarizer-*All four were mine. Every one of them was something my own tooling had created, and every one of them was eventually whitelisted in /etc/rkhunter.conf. The scan was not lying, and it was not compromised. It was doing exactly what it was built to do, against a host I had filled with things that look structurally like what it hunts.
Why these four in particular
Look at the shape of them instead of the names. Three are dot-prefixed entries sitting in directories where a dot-prefixed entry has no business being — a hidden tool directory directly under /usr, hidden binaries in /usr/bin. That is the classic rootkit hiding pattern: a directory that does not show up in a plain listing, holding a payload. rkhunter’s hidden-file and hidden-directory checks key on precisely that, on purpose. If they stopped flagging it, they would stop catching the real thing.
The fourth is different and worth understanding separately. /dev/shm is shared memory — it is normal for it to be populated by whatever is running, and a PostgreSQL instance leaves its segments there. Those entries are not files anyone installed; they are memory. But a hidden, oddly-named entry in a world-writable tmpfs is also a favourite place for a payload to sit where nothing gets cleaned up, so the check fires. Both readings are correct. Only one of them is about my machine.
The decision: whitelist, but narrowly
Whitelisting has a bad reputation and it deserves some of it. The reflex to silence a scanner the moment it complains is how people end up with a security tool that reports nothing and proves nothing. So I made the decision on a rule rather than on convenience: I would whitelist the exact paths, and nothing wider.
That distinction matters because of what it preserves. If I had told rkhunter to stop caring about hidden directories under /usr, I would have bought quiet at the price of the check itself — a genuinely planted hidden directory would pass silently. Whitelisting the four specific entries leaves the check armed. The next hidden directory under /usr that I did not create still trips it, and that is the entire value of running the scan.
A scanner that cries wolf is worse than no scanner, because it trains you to skim its output. That is the real reason to do the whitelist work rather than the reason people usually give. It is about keeping the warnings meaningful, so that the day one of them is real, I read it instead of scrolling past it.
Lynis is a different animal
Lynis gets mentioned in the same breath as rkhunter and it should not, because it fails differently. It is a hardening audit, not a signature scan — it grades configuration and returns suggestions, so disagreeing with it is routine and is not a false positive in the same sense. rkhunter is the one that points at a path and says this is suspicious, which means it is the one where you have to know your own machine well enough to answer it.
What I do before deciding anything
I no longer start from “is this a compromise.” I start from “did I put this here,” and I answer it with three things: what the path is, when it appeared, and which user owns it. That ordering is the whole lesson. Checking those first is cheap. Treating a shared-memory segment as evidence of an intrusion is not — it costs an evening, and it costs something worse, which is attention that should have gone to the parts of the report that were actually about risk.
Know your false positives before you trust the scan. Not so you can dismiss the scan — so that when it speaks, you believe it.
Related
- SSH Brute-Force to Crypto Miner: Hardening a VPS the Hard Way
- The Miner in ps Wasn’t Ollama, It Was a Container
- Don’t Panic Over Docker’s Exec Artifacts
Guides & explainers
Filed under: Cybersecurity, Linux, Security Hardening, VPS