Integrity monitoring has an awkward property: it needs a reference taken from a system known to be clean. If the server has been running for three years and the question of a break-in only came up today, taking that reference is already too late — you would be recording whatever is there as normal.

On Debian and Ubuntu, though, the reference already exists, and it is not yours: every installed package carries the checksums of its own files. Comparing against them requires no setup and no prior snapshot, and works on any system at any moment. The tool is called debsums.

Using it

sudo apt install debsums
sudo debsums -c

The -c flag prints only the files that did not match the reference. Without it the output is a line-by-line report on every file in the system, tens of thousands of lines.

The check takes a few minutes and loads the disk, so on a working server it is worth running with lowered priority:

sudo ionice -c3 nice -n19 debsums -c

How to read the result

Empty output means every checked file matches what the distribution installed. Non-empty output needs examining, and the findings fall into two very different classes.

Configuration files under /etc. Changing them is normal work: you edited sshd_config, configured nginx, added kernel parameters. Such differences are expected. To keep them out of the way there is a separate mode:

sudo debsums -e -c

-e checks configuration files only — occasionally useful for seeing the list of everything you have changed on this machine.

Executables and libraries. A difference in /usr/bin, /usr/sbin, /bin or /usr/lib is what the check was run for. There are legitimate causes, but not many: the file was edited by hand while debugging, a third-party patch was applied, the package was being upgraded during the check. If none of those fits, it is time to look into it seriously.

The classic targets for replacement are ls, ps, netstat, ss, find, sshd. A replaced version hides the lines that matter from its output, and every subsequent check of yours stops telling the truth.

The coverage is incomplete — and you need to know that

A limitation that usually goes unmentioned: not every package ships checksums. Files from such packages are not checked at all and will never appear in the report under any circumstances. You can see the list like this:

sudo debsums -l

A clean debsums report therefore means "everything is in order in the part that was checked", not "the system has not been modified". The same goes for everything installed outside the package manager: compiled from source, downloaded as a binary, installed by a script from the developer's site — debsums does not watch any of that by definition, and that is exactly where AIDE is needed.

Running it regularly

The package ships a ready-made job, enabled in /etc/default/debsums:

CRON_CHECK=weekly

Once a week is a sensible frequency: the check noticeably loads the disk, and system files rarely change between updates. Running it daily adds nothing but load.

If a file really has been replaced

The first impulse is to reinstall the package and get the original back:

sudo apt install --reinstall coreutils

The command is right, but not as the first action. A replaced system binary means somebody had root, and restoring the file does not solve that problem — it only destroys the traces. The order should be the other way round: first keep a copy of the suspicious file and its modification time, look at what else changed in the same period, check the cron jobs, the SSH keys and the list of users. Restore only after that.

It is also worth remembering the limits of the method: if the system is deeply compromised, then debsums itself and the libraries it uses may have been replaced along with everything else. A check from inside cannot give an absolute guarantee — that is done by booting from external media. For everyday work, though, this is enough: the overwhelming majority of attacks are automated and not that sophisticated.

Its place in the overall picture

debsums is good because it needs nothing and works immediately — which makes it a convenient starting point for a server whose history you do not know. Its weakness is incomplete coverage and no knowledge of anything installed outside packages. The pair "debsums plus AIDE" closes both sides: the distribution's ready-made reference for system files, and your own snapshot for the rest.

As usual, the point is not running it but having the latest result in plain view together with its date. What that looks like is on the demo below.