Check data pools for changes or manipulation

Integrit

You can get integrit either via the system's package management (e.g., with Debian, Ubuntu, Linux Mint, and Raspbian) or directly from the project's website [7]. After the installation, integrit doesn't constantly run as a daemon in the background, but you execute it explicitly for an analysis with admin rights.

To make the program know where to look, you specify a concrete job in a configuration file. You can freely choose the file name – in my example, I used integrit.conf (Listing 8). Your best bet is to save the file in the directory /root/integrit/ or /etc/integrit/ and set adequate access permissions to hinder curious users from fiddling with it.

known=/root/integrit/known.cdb
current=/root/integrit/current.cdb
root=/data/original

Integrit requires three lines in a configuration file: the path to the inventory database, the path to the database of the current state, and the directory that shall be monitored (line 3). The same as goes for the paths and names of the databases – the definition of name and path are up to you and can be set according to local circumstances.

In the next step, you initialize the inventory database. For this, you execute integrit with the three switches -u for update, -v for verbose, and -C <configuration> (see Listing 9).

# integrit -uv -C integrit.conf
integrit: ---- integrit, version 4.1 -----------------
integrit:            output : human-readable
integrit:         conf file : integrit.conf
integrit:          known db : /root/integrit/known.cdb
integrit:        current db : /root/integrit/current.cdb
integrit:              root : /data/original
integrit:          do check : no
integrit:         do update : yes
integrit: current-state db RMD160 --------------
integrit: a6fb12c69b773038f03987b7130ae07c0846fe02  /root/integrit/current.cdb

As you defined in the config file, integrit "remembers" the current state in the file current.cdb . Now you can copy this state with

cp current.cdb known.cdb

to the inventory in the file known.cdb . This file can now be used as reference by integrit to detect modifications.

Make some changes in the monitored directory. In the following example, I amended content and extended user permissions. In the next step, I let integrit compare the state of the directory with the previously registered inventory. For that, you execute it with the switch -c for changes, and with -C followed by the name of the configuration file (Listing 10).

# integrit -c -C integrit.conf
integrit: ---- integrit, version 4.1 -----------------
integrit:            output : human-readable
integrit:         conf file : integrit.conf
integrit:          known db : /root/integrit/known.cdb
integrit:        current db : /root/integrit/current.cdb
integrit:              root : /data/original
integrit:          do check : yes
integrit:         do update : no
changed: /data/original/file2   s(9c1185a5c5e9fc54612808977ee8f548b2258d31:b17ae69f081657c9f0b5e810affbce44b1f7593f)
changed: /data/original/file2   p(0644:0654) m(20160602-175113:20160606-194552) c(20160602-175113:20160606-194610)
integrit: not doing update, so no check for missing files

The result of the comparison shows multiple modifications. In the last block of line 10, the s (for size ) marks a change in size in the file /data/original/file2 , which is also highlighted by the different hash values in brackets next to it. Furthermore you can find a p (for permissions ) in the last block of line 11 because I changed the user permissions from 0644 to 0654. The letter m (for modification date ) marks the date of modification, in this case, June 6, 2016 at 19:45.

In the last file, integrit also notifies you that it doesn't update the inventory database in the same step but only checks it for modifications. If you also want to adopt all changes to the inventory, use the -u (update) switch when executing.

Load Comparison

Each tool generates a certain load to fulfill its tasks. On systems in production, the integrity check must by no means overload the system. That is why I tested rsync and integrit under normal everyday conditions by filing and analyzing 16GB of saved data on an internal SSD.

In the course of the test, I saw that the parity test (as described in Listing 3) took an average of between one and two seconds. If rsync is supposed to calculate the checksum too (see Listing 4), then around one minute goes by. If you use other storage devices – e.g., connected via USB or network – you have to schedule more time. The same goes for SATA hard-disk drives, SD cards, and CDs/DVDs.

Integrit on the other hand requires around 150 seconds for the database inventory (see Listing 9) and writes 24MB of data during this step. As shown in Listing 10, the check for modifications on average lasts about the same time. For the additional update of the database, you'll have to schedule 5 to 10 percent more time.