File integrity and secure destruction

Why this matters

Two ends of a system's life. Integrity monitoring tells you that something on a running machine has changed when it should not have — the modified binary, the added SSH key, the edited configuration. Secure destruction makes sure that when a disk leaves your control, the data on it does not.

The destruction half contains one fact that overturns the intuitive answer: shred does not reliably work on modern storage. It was written for magnetic disks, and on an SSD it may overwrite entirely different blocks from the ones holding your data.

The lesson

AIDE

AIDE — the Advanced Intrusion Detection Environment — records a baseline of every monitored file's hash, size, permissions, ownership and timestamps, then reports what has changed since.

dnf install aide
aide --init                                     # build the baseline
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
aide --check                                    # compare against it
aide --update                                   # check, then write a new baseline

# /etc/aide.conf
/bin      NORMAL
/sbin     NORMAL
/usr/bin  NORMAL
/etc      NORMAL
!/var/log/.*          # exclude what legitimately changes
!/etc/mtab

The output names each change and what about it changed — content, permissions, ownership, timestamps.

The baseline must be stored off the machine. An attacker with root can update the database as easily as the files, and then aide --check reports clean forever. Keep the database on read-only media or a separate host and copy it in for each run; a baseline sitting beside the files it protects is a formality rather than a control.

Build the baseline immediately after installation, before the machine is exposed. A baseline taken from an already-compromised system enshrines the compromise as normal.

Expect noise at first. Tune the exclusions until a clean run means something — a report nobody reads because it always has fifty entries provides no security at all.

rkhunter

Rootkit Hunter looks specifically for rootkits, backdoors and local exploits, using known signatures plus heuristics.

dnf install rkhunter
rkhunter --update                    # signature database
rkhunter --propupd                   # baseline of file properties
rkhunter --check
rkhunter --check --skip-keypress --report-warnings-only

It checks for known rootkit files, wrong permissions on binaries, hidden files and directories, suspicious strings inside kernel modules, and — usefully — processes listening on ports that no package accounts for.

Run --propupd after legitimate updates, or every patch cycle produces a page of warnings and you stop reading them. That habit of tuning until the report is meaningful is the whole discipline here.

chkrootkit is a similar tool; running both is common, since their signature sets differ.

Package verification

The package manager already holds a signed record of what every file should look like, which makes it a file-integrity tool you did not have to install.

rpm -V nginx                 # verify one package
rpm -Va                      # verify EVERYTHING installed
rpm -Va --nofiles --nodigest # faster, metadata only

debsums -c                   # Debian: files whose checksums differ
debsums -a

rpm -V output codes: S size, M mode, 5 checksum, L symlink, U user, G group, T time, c marks a config file.

S.5....T.  c /etc/nginx/nginx.conf     # config you edited — expected
..5....T.    /usr/sbin/nginx           # the BINARY changed — investigate now

A changed configuration file is normal. A changed binary is not, and rpm -Va finding one is among the strongest signals available.

Signed package verification is the other half — proving a package came from who it claims before installing:

rpm --checksig package.rpm
rpm -qa gpg-pubkey*                # which keys are trusted
dpkg-sig --verify package.deb

This is the software supply chain control. Attacks there — a compromised build server, a hijacked maintainer account, a malicious dependency — deliver malware through the update mechanism you trust. Signature checking is the defence, which is why gpgcheck=0 is never an acceptable fix for a repository that will not install.

The XZ Utils backdoor (CVE-2024-3094) is the case worth knowing: a maintainer inserted a backdoor into a compression library used by SSH, and it reached distribution beta channels before being caught by someone investigating a half-second login delay. Signatures were all valid — the signer was the problem. Supply chain risk is not fully solved by signing; signing raises the bar to compromising a maintainer rather than a mirror.

Secure data destruction

Deleting a file removes its directory entry. The data stays on the disk until those blocks are reused, which is why undelete tools work.

shred overwrites a file's blocks repeatedly:

shred -vfz -n 3 /dev/sdb          # 3 passes, then zero, whole device
shred -u secret.txt               # overwrite then remove the file

The critical limitation. shred assumes overwriting a block replaces its contents, which is true of magnetic disks and not true of SSDs. Flash controllers do wear levelling: a write goes to a different physical cell and the old one is marked stale but still holds your data. shred on an SSD overwrites blocks that may have nothing to do with the file, while the original contents remain readable to anyone who addresses the flash directly.

The same reasoning defeats shred on any copy-on-write or journalling filesystem, on RAID, on thin-provisioned SAN volumes, and on VM disk images.

So, by medium:

Magnetic disks — shred, or a single pass of zeroes or random data:

dd if=/dev/zero of=/dev/sdb bs=1M status=progress
dd if=/dev/urandom of=/dev/sdb bs=1M status=progress
badblocks -wsv /dev/sdb          # destructive write test: also overwrites everything

badblocks -w is really a disk test — it writes patterns across the device and reads them back — but it overwrites everything in the process, so it both sanitises and tells you whether the drive is healthy.

One pass is sufficient on modern drives. The old thirty-five-pass advice comes from research on drive encodings that have not existed for decades.

SSDs — use the drive's own secure-erase, which the controller implements across all cells including spares:

hdparm -I /dev/sda | grep -i erase           # supported? how long?
hdparm --user-master u --security-set-pass p /dev/sda
hdparm --user-master u --security-erase p /dev/sda

nvme format /dev/nvme0n1 --ses=1             # NVMe secure erase
nvme sanitize /dev/nvme0n1 --sanact=2
blkdiscard -s /dev/sda                       # secure discard/TRIM

Cryptographic destruction is the most reliable answer and the easiest: encrypt the disk when you deploy it, and to destroy the data, destroy the key.

cryptsetup luksErase /dev/sdb                # wipe ALL key slots

The ciphertext remains and is unreadable, permanently, because the key that could decrypt it no longer exists anywhere. It takes a second regardless of disk size, works identically on SSDs and magnetic disks, and sidesteps every wear-levelling problem above.

That is the strongest argument for full-disk encryption on everything — not the theft scenario people usually cite, but decommissioning. It converts an hours-long, medium-specific, unverifiable erase into an instant and complete one.

For media that must be destroyed physically, or where regulation demands it, degaussing and shredding are the fallbacks — and a certificate of destruction is what auditors want to see.

Security banners

Legal notices displayed at and after login. Their purpose is jurisdictional: in several countries, prosecuting unauthorised access is easier when the system stated that access was restricted.

# /etc/issue.net
This system is for authorised users only. All activity may be
monitored and recorded. Disconnect immediately if you are not an
authorised user.

# /etc/ssh/sshd_config
Banner /etc/issue.net

sshd does not display /etc/issue.net unless you set Banner. Writing the file and assuming it appears is a common audit finding.

Do not put the hostname, OS or version in a pre-login banner. Several distributions ship /etc/issue containing \n and \r escapes that print exactly that, which is free reconnaissance for anyone who connects.

/etc/motd is after authentication, so it is for your own users — maintenance windows, contact details, which environment this is. On many systems it is assembled from /etc/update-motd.d/ scripts.

On the exam

• AIDE builds a hash baseline and reports changes; the database must be stored off the machine, or an attacker updates it too.
• Build the baseline before the system is exposed.
• rpm -Va verifies every installed file. A changed binary is a strong compromise indicator; a changed config file usually is not.
• Signed package verification is the supply-chain control; gpgcheck=0 is never the fix.
• shred is unreliable on SSDs because wear levelling means the overwrite may not touch the original cells. Use the drive's secure erase, or cryptographic destruction.
• cryptsetup luksErase destroys the key and therefore the data, instantly and regardless of medium.
• /etc/issue is pre-login local, /etc/issue.net pre-login network, /etc/motd post-login — and sshd needs Banner set to show issue.net.