inoticed: Detecting file changes on Linux servers without drowning in alerts

A server changes all the time. Updates rewrite program files, services create temporary files, logs grow, backups appear and disappear again. Somewhere in between sits the one change that does not belong there: a replaced program, a new login, a script in a directory where nobody put anything.

inoticed is a small tool that answers exactly one question: What has just changed on my server? It reports file changes by mail in real time, groups the noise, and says openly when it could not see everything itself. It is open source, free of charge and runs on common Linux servers.

The real problem is not detection Link to heading

A Linux system has been able to report that a file changed for more than twenty years. Tools for this exist. For years I used one of them, iwatch. It reliably noticed what changed, and it sent one mail for every single change.

A routine system update produced about 20,000 mails within a few seconds.

That is like a burglar alarm that goes off for every passing car. After the third night you either switch it off or stop listening, and both amount to the same thing. An alarm nobody reads protects nothing.

Then there was the configuration. It consisted of exceptions written in two different ways that affected each other. At some point I stopped maintaining it. A monitoring tool whose settings nobody touches anymore ends up watching the wrong things.

So I built a new one.

One report instead of a thousand mails Link to heading

inoticed collects changes for a few seconds and then sends one report. The 20,000 mails of an update become a handful. This is what such a report looks like:

[inoticed] server1 #1: 6 changes

6 changes on server1

2026-09-12T14:02:11+02:00  modified                   /etc/passwd
2026-09-12T14:02:14+02:00  created,attrib(2),deleted  /tmp/scan.7f3a
2026-09-12T14:02:19+02:00  deleted                    /etc/fstab
2026-09-12T14:02:23+02:00  moved-in                   /etc/nsswitch.conf

The first line concerns the file that holds a system’s user accounts. Anyone who sees it changed unexpectedly should ask why.

The second line is the interesting one. A file was created, changed and deleted again, all within the same second. Tools that check once a day never see something like that. By the next morning the file is gone and everything looks as before. Yet that is how many attacks work: drop something, run it, clean up.

Leaving out the noise without going blind Link to heading

Grouping alone is not enough. A mail server writes mail to disk all day, a database changes its files constantly. That is normal and does not belong in a security report.

The settings of inoticed therefore consist of two simple lists: what is watched and what is not.

include = ["/etc/**", "/usr/**", "/boot/**"]
exclude = ["/etc/.git/**"]

There is no order to keep in your head. Whatever is in exclude always wins. This simplicity is deliberate: a configuration you understand at a glance is one that gets maintained.

For widely used services such as mail servers, web servers, databases or virus scanners there are ready-made filters that hide exactly their normal behaviour. Each filter also states what stays watched.

Not every kind of change is treated the same, either. A log file grows all day, and nobody needs to hear about it. If it is deleted, though, that is interesting, because attackers like to cover their tracks. This can be set per path:

[[rule]]
match = "/var/log/**"
events = ["delete"]

It works the other way round as well. For the file holding a system’s password hashes, every single read can be reported. For the whole system that would be useless; for this one file it is a very targeted alarm.

Listen for a week, then decide Link to heading

Every server is different. Instead of hunting down all exceptions by hand, you can put inoticed into a learning phase. During it, for a week for example, it records everything it would report. Afterwards it suggests what keeps recurring and is therefore probably normal.

What matters is what it does not do. It does not apply its own suggestions. The draft stays locked until a person has reviewed and approved it. Suggestions for particularly sensitive areas, such as the system configuration or users’ access keys, only appear as commented-out hints.

The reason is written as a warning at the top of every draft: if an attacker was already active during the learning phase, their changes look normal in it. A machine can suggest; the decision belongs to someone who knows the server.

Silence is not a good sign Link to heading

Most monitoring tools share an uncomfortable trait. When they report nothing, that can mean two things: nothing happened, or they are no longer running. Both look the same in the inbox.

inoticed treats this as the core problem:

• Sign of life. Once a day a mail arrives, even if nothing happened. If it does not arrive, something is wrong.
• Numbered reports. Every mail carries a running number. If one is missing, it got lost on the way.
• Honest gaps. If the system had so many changes at once that inoticed could not catch all of them, the subject says INCOMPLETE. The report does not pretend to be complete.
• Delay instead of loss. If the mail server is unreachable, nothing is lost. The report arrives later and says that it is late.
• Alarm when blind. If a large part of the monitoring drops away, for example because a disk was unmounted, inoticed says so explicitly instead of quietly carrying on with half its coverage.

This leads to the most important advice in this article, whatever tool you use: do not only react to alerts, also react when an expected report fails to arrive. Only then does silence become information.

Where inoticed fits Link to heading

Watching files, known as file integrity monitoring, is not a job for a single tool. The well-known programs answer different questions. Comparing them to a building helps:

inoticed replaces none of them. It complements them. The stocktake is thorough, but it comes once a day. The alarm reacts at once, but it cannot tell whether a file’s content is exactly the same again after a change. Together they give a useful picture.

Anyone looking after many servers centrally is better served by a platform like Wazuh. inoticed is aimed at individual servers and smaller environments where a mail to the administrator is the alerting path and no extra infrastructure should be built for it.

A security tool has to be secure itself Link to heading

A program that is meant to watch the whole system needs far-reaching rights. That makes it a target in its own right. During development I therefore paid attention to four things above all:

The settings are protected. inoticed refuses to start if its configuration could be changed by anyone other than the administrator. Additional filters can only hide things; they can never widen what is watched or change which program sends the mails.

A report cannot be forged. Anyone allowed to create files on a server can choose their names freely, line breaks included. Without precautions, that could be used to slip fake lines into a report or redirect the mail to further recipients. inoticed prevents this.

It cannot be flooded. Whoever generates lots of changes cannot make inoticed use up the memory, the mailbox or the system’s monitoring capacity. There are limits for all of it, and reaching a limit is reported.

It is verifiable. The source code is open, every published version is cryptographically signed, and the program carries the list of its components inside it. Years later you can still check whether an installed version is affected by a known vulnerability.

inoticed is written in Rust, a programming language that rules out entire classes of memory errors that regularly lead to security holes in C programs. I had never written Rust before. Java, C and thirty years of Linux, but no Rust. For a tool that runs with the highest privileges on a server, it was still the obvious choice.

Testing is correspondingly thorough: with thousands of automatically generated inputs, with deliberately planted bugs to check whether the tests find them, and with installation tests on fresh systems.

What inoticed cannot do Link to heading

A tool that hides its limits invites a false sense of security. So, plainly:

• inoticed tells you what changed, not who did it.
• It does not check content. Whether a changed file has its old content again is a question for the stocktake, not the alarm.
• It does not see what happens while it is not running. The sign of life makes an outage visible, nothing more.
• An attacker with full privileges can switch it off, like any other service. Then the next report is missing, and someone should notice.
• It is an early warning, not a defence. It stops no one; it makes sure you find out.

Frequently asked questions Link to heading

Who is inoticed for? Link to heading

For administrators of individual Linux servers and small environments who want to know when something unexpected happens on their systems, without building a central security platform for it.

What does it cost? Link to heading

Nothing. inoticed is open source under the MIT licence and may be used freely, commercially too.

Does inoticed replace a virus scanner or a firewall? Link to heading

No. A firewall and a virus scanner try to prevent an attack. inoticed reports when something happened anyway. Neither replaces the other.

Is inoticed a replacement for iwatch? Link to heading

Yes, that is why it was built. It uses the same technique, but it groups the reports, is easier to set up, and reports when it could not see everything itself.

Which systems does it run on? Link to heading

On Linux servers with Debian, Ubuntu, Rocky Linux, AlmaLinux and Red Hat Enterprise Linux. For Debian and Ubuntu there are ready-made filters for many common services.

Wasn’t it called fwatchd? Link to heading

Yes. Up to version 0.7 the project was called fwatchd. The name was already taken in Rust’s central package registry, so since version 0.8 it has been called inoticed.

Installation, configuration and all technical details are in the wiki. Source code and packages: codeberg.org/randomDuderus/inoticed, MIT licence. Questions, corrections and your own experiences are welcome in the comments.