5

Is it possible to list every file on the system that does not belong to a package? or if they have been modified?

Might need to use something like: apt-get, apt-files, dpkg-query, etc

For context, imagine inheriting an old server that can't be formatted, and you want to check that every file is as it should be... I know this won't be the case when upgrading between versions of Debian, or after removing a package without "--purge", as it seems to leave allot of (typically config) files behind.

Likewise if that server was to be replaced with a new server, you want to make sure all of the configuration differences (compared to the base install) have been transferred (or ignored if no longer relevant - e.g. a rouge "Port" line being added to sshd_config).

It would also help identify if anything has been installed without the use of apt-get.

Craig Francis
  • 633
  • 1
  • 8
  • 23

4 Answers4

5

All the files installed by a package can by seen by looking at the list cat /var/lib/dpkg/info/*.list. Most packages include md5sums for the file content which can be seen by look at cat /var/lib/dpkg/info/*.md5sums. Some packages do not include these sums though.

If you install the package debsums you can run the program like debsums -a this will check the md5sum of all the installed files and configurations.

Please note that some packages do not install the configuration files or content. Instead these files are created by those packages at install time. These files will not be in the file list associated with the package or the md5sums list. As far as the package system is concerned, these are data files that it doesn't own.

Likewise if that server was to be replaced with a new server, you want to make sure all of the configuration differences (compared to the base install) have been transferred (or ignored if no longer relevant - e.g. a rouge "Port" line being added to sshd_config).

I think you should install the etckeeper package first thing after you install the system. This package basically puts /etc into a version control system of your choosing (I prefer git). With this in place you can see exactly what changed when. It easy easy to clone this repository over to a new system and then do diffs against the new system. So you can see exactly what is different been a source and destination system in a single command.

Zoredache
  • 130,897
  • 41
  • 276
  • 420
  • For etc files, it might be the good time to look at chef/puppet instead of etckeeper. Good answer though ! – mveroone Jan 19 '14 at 10:15
  • 1
    @Kwaio Configuration Management is great, I highly recommend it. But even on my puppet controlled systems I have etckeeper running. It can be very useful to see a log of what changed, and how it got changed over time. – Zoredache Jan 19 '14 at 11:16
  • It's really a matter of tools overlapping, I use Samhain to keep trace of file changes. The idea of version-controlling /etc is good though I'll think about it. – mveroone Jan 20 '14 at 09:54
  • I will try Chef/Puppet again in the future, but at the moment I find both of them severely lacking, and not much better than the shell scripts I've been using for the past 10+ years (I shall be raising issues via the proper channels though, as I know this is not their intention... but then again, I have many individual servers doing completely different things, not many servers doing the same thing, so editing a sed line is much easier than understanding ruby and the many options, which don't really cover all of the edge cases)... anyway, I have a newly inherited server to look at (thanks) – Craig Francis Jan 22 '14 at 10:28
2

cruft / etckeeper / debsums

Package: cruft
Description-en: program that finds any cruft built up on your system
 cruft is a program to look over your system for anything that shouldn't
 be there, but is; or for anything that should be there, but isn't..
 It bases most of its results on dpkg's database, as well as a list of
 `extra files' that can appear during the lifetime of various packages.
 cruft is still in pre-release; your assistance in improving its accuracy
 and performance is appreciated.

Package: debsums
Description-en: tool for verification of installed package files against MD5 checksums
 debsums can verify the integrity of installed package files against
 MD5 checksums installed by the package, or generated from a .deb
 archive.

Package: etckeeper
Description-en: store /etc in git, mercurial, bzr or darcs
 The etckeeper program is a tool to let /etc be stored in a git, mercurial,
 bzr or darcs repository. It hooks into APT to automatically commit changes
 made to /etc during package upgrades. It tracks file metadata that version
 control systems do not normally support, but that is important for /etc, such
 as the permissions of /etc/shadow. It's quite modular and configurable, while
 also being simple to use if you understand the basics of working with version
 control.
dfc
  • 1,341
  • 8
  • 16
  • Thanks dfc... good to see you have come to the same conclusion as Zoredache... also cruft does look like a good way to automate most of this checking. – Craig Francis Jan 22 '14 at 10:43
  • The nice thing about cruft is that you can use it now. debsums and etckeeper will only identify things going forward. Protip for etckeeper: have all your machines push to different branches of the same repository. That way you can easilly reference how you have set up /etc/xyz.conf on other machines in the past. – dfc Jan 22 '14 at 17:18
1

Both tiger and rkhunter will report files that do not belong to any installed package, amongst other things.

You may also want to have a look at debsums that checks files for modificatons since their installation through the package manager.

These programs have pretty good manual pages, so read them before use and you should be fine.

mp04
  • 187
  • 8
0

To see if any non-configuration files from debian packages have been modified since the package you can use debsums.

Seeing if third party packages have been installed is trickier, you could probablly compare vernsion numbers and checksums against information from packages.debian.org but i'm not sure how difficult it would be to automate that.

Checking for configuration file modifications is difficult because configuration files can be managed in several different ways. If they are "conffiles" then dpkg will know if they are been modified but many configuration files are not.

If the server is kept up to date then cross comparing with a fresh install of the same version of debian with the same packages installed may be a good option. Obviously that doesn't work so well if you don't want to update the server (I guess you coul make an image of the server and update that but that opens up a can of worms of it's own).

Peter Green
  • 4,211
  • 12
  • 30