Package Integrity Drift Audit (rpm -V / debsums) Prompt
Decode the output of rpm -Va or debsums and separate benign, expected file changes from tampering, corruption, or undocumented manual edits that could break the next patch.
- Target user
- Linux admins auditing inherited or drifted hosts for integrity before patching
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior Linux engineer who audits package integrity to find files that have drifted from their distribution-shipped state — distinguishing harmless config edits from corruption or tampering. I will provide: - Distro/version and whether RPM-based (`rpm -Va`) or Debian-based (`debsums -c -a` / `debsums -s`) - The raw verification output (it can be long — process all of it) - Whether this host is being prepped for a patch, investigated post-incident, or onboarded as an unknown inherited box - Any known config-management tool (Ansible/Puppet/Chef) that legitimately edits files Your job: 1. **Decode the verify flags** — for rpm, explain each character position in the `SM5DLUGT c` mask (Size, Mode, MD5/digest, Device, Link, User, Group, mTime, capabilities) and the `c`/`d`/`g` config-file markers. For debsums, explain what a failing checksum means and its limits (only checks files with shipped md5sums). 2. **Triage by risk** — bucket every reported change into: (a) EXPECTED — config files marked `c` whose content you'd obviously edit (`/etc/ssh/sshd_config`, `/etc/fstab`); (b) SUSPICIOUS — binaries, libraries, or setuid files under `/usr/bin`, `/usr/sbin`, `/usr/lib` with `5` (digest) or `M` (mode) changes; (c) BENIGN-NOISE — mtime-only (`T`) differences and missing docs. 3. **Hunt the real signals** — flag any *executable* or *library* with a digest mismatch as a tampering/corruption candidate, any setuid/setgid mode change, and any file owned by an unexpected user. 4. **Confirm before alarming** — for each suspicious item, give the command to confirm: re-download and diff (`rpm -qf`, `dnf reinstall`, `apt-get install --reinstall`), compare against a known-good host, or check package signature. 5. **Explain the blind spots** — both tools verify against the *local* package DB, which an attacker could also alter; note when a trusted offline source (AIDE baseline, image) is needed instead. Output as: (a) a categorized table (EXPECTED / SUSPICIOUS / NOISE) with the file, the flags, and one-line reasoning, (b) the prioritized list of files to confirm by reinstall/diff with exact commands, (c) a one-paragraph integrity verdict, (d) a recommendation on whether to trust this host for the upcoming patch. Verify before acting: never `reinstall` or overwrite a drifted file until you've captured its current contents — a manual fix or local patch may be load-bearing and undocumented.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
rpm -Va and debsums are the fastest way to ask a box “which of your files no longer match what the distribution shipped?” — but their raw output is a wall of cryptic flag masks that buries the three or four lines that actually matter under hundreds of harmless mtime and config-file differences. This prompt makes the AI do the tedious decoding (every position of the S.5....T. mask) and, crucially, triage by risk so a changed /etc/sudoers reads differently from a changed /usr/bin/sudo.
The risk bucketing is the real value. An edited config file marked c is expected and boring; a digest (5) change on a binary, library, or setuid file is a tampering-or-corruption signal that deserves immediate confirmation. By forcing the model to separate EXPECTED config drift from SUSPICIOUS executable drift from BENIGN mtime noise, you go from “200 lines changed” to “these 3 binaries need a reinstall-and-diff right now.”
The prompt also keeps you honest about the tools’ limits and keeps a human in the loop on remediation. Both utilities verify against the local package database, which is exactly what an attacker who rooted the box would tamper with — so the AI is told to recommend an offline AIDE baseline or clean image when integrity is genuinely in doubt. And before anything gets reinstalled, it insists you capture the current file contents, because a hand-edited, undocumented local fix that’s been holding production together is depressingly common. The AI decodes and prioritizes; you confirm before overwriting.
Related prompts
-
AIDE File Integrity Monitoring Setup Prompt
Design an AIDE file-integrity baseline and check schedule that watches the right paths, suppresses expected churn, and stores the database offline so a compromised host cannot rewrite its own baseline.
-
SetUID/SetGID Binary Audit Prompt
Inventory every setuid and setgid binary on a host, classify each as expected, removable, or suspicious, and propose a least-privilege remediation plan that uses capabilities instead of full root.
-
etckeeper Config Drift Tracking Prompt
Set up etckeeper to version-control /etc with git, capture every package-manager and manual change, and produce readable drift reports so you can answer who changed what configuration and when.
-
Linux bcache SSD Caching Setup Prompt
Design a bcache SSD-in-front-of-HDD caching tier with the right cache mode, write policy, and sequential-bypass tuning, and plan the attach/detach and failure behavior so a cache device loss never means data loss.
More Linux Admins prompts & error guides
Browse every Linux Admins prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.