Dateigrößen, Checksums und Integrität automatisiert prüfen

1. Warum Dateiintegrität automatisiert prüfen?

Die Dateiintegrität automatisiert prüfen zu wollen ist keine Paranoia, sondern eine operative Notwendigkeit. In produktiven Umgebungen ändern sich Dateien durch fehlerhafte Deployments, fehlerhafte Speichermedien, unbemerkte Eingriffe oder schlicht durch Übertragungsfehler beim Kopieren über das Netzwerk. Wer diese Veränderungen nicht systematisch erkennt, lebt mit einem blinden Fleck in der Infrastruktur. Die Folge: ein defektes Backup, das erst im Ernstfall auffällt, oder eine manipulierte Konfigurationsdatei, die wochenlang unentdeckt bleibt.

Checksums sind das Standard-Werkzeug, um Dateiintegrität automatisiert prüfen zu können. Ein kryptografischer Hash-Wert ist ein digitaler Fingerabdruck einer Datei – jede noch so kleine Änderung am Inhalt produziert einen völlig anderen Hash. Wird der Hash-Wert zusammen mit der Datei gespeichert oder übertragen, lässt sich zu jedem späteren Zeitpunkt mit einem einzigen Shell-Befehl verifizieren, ob die Datei unverändert ist. Bash bietet mit md5sum, sha256sum und sha512sum alle nötigen Werkzeuge, um diesen Prozess zu automatisieren.

Der Mehrwert liegt nicht im einzelnen Prüfvorgang, sondern in der Automatisierung. Ein Bash-Skript, das nach jedem Deployment Checksums vergleicht, nach jedem Backup-Lauf die archivierten Dateien verifiziert und täglich per Cron über Verzeichnisänderungen berichtet, schafft eine kontinuierliche Beobachtbarkeit der Dateisysteme. Das ist die Grundlage für nachvollziehbare, zuverlässige Automatisierung.

2. md5sum, sha256sum und sha512sum im Vergleich

Die drei gängigsten Tools zur Dateiintegrität automatisiert prüfen sind md5sum, sha256sum und sha512sum. MD5 produziert einen 128-Bit-Hash und ist extrem schnell, gilt aber als kryptografisch gebrochen – Kollisionen lassen sich berechnen. Für die Prüfung auf versehentliche Korruption oder einfache Übertragungsfehler ist MD5 weiterhin praktisch, weil kein Angreifer beteiligt ist. Für sicherheitsrelevante Prüfungen – etwa die Verifikation von Deployment-Artefakten oder Konfigurationsdateien, die nicht manipuliert worden sein dürfen – ist SHA-256 der aktuelle Standard.

SHA-512 ist rechnerisch etwas aufwändiger als SHA-256, bietet aber auf 64-Bit-Systemen oft vergleichbare oder sogar bessere Performance, weil es nativ in 64-Bit-Operationen implementiert ist. Für die tägliche Praxis der automatisierten Dateiintegrität prüfen empfiehlt sich SHA-256 als vernünftiger Kompromiss zwischen Sicherheit, Geschwindigkeit und breiter Toolchain-Unterstützung. Alle drei Tools folgen demselben Interface: Eingabe ist eine Liste von Dateipfaden, Ausgabe ist eine Zeile pro Datei mit Hash und Dateiname, getrennt durch zwei Leerzeichen.

#!/usr/bin/env bash
# integrity-check.sh — Generate and verify file checksums
set -euo pipefail
IFS=$'\n\t'

readonly CHECKSUM_DIR="/var/lib/integrity-checks"
readonly TARGET_DIR="${1:?Usage: $0 <target-directory>}"

# Generate SHA-256 checksums for all files in directory
generate_checksums() {
  local dir="$1"
  local output_file="$2"
  # find handles filenames with spaces and special characters safely
  find "$dir" -type f -print0 \
    | sort -z \
    | xargs -0 sha256sum \
    > "$output_file"
  echo "[OK] Generated $(wc -l < "$output_file") checksums -> $output_file"
}

# Verify checksums against previously stored baseline
verify_checksums() {
  local baseline="$1"
  local failed=0
  while IFS= read -r line; do
    expected_hash="${line%% *}"
    filepath="${line#*  }"
    if [[ -f "$filepath" ]]; then
      actual_hash="$(sha256sum "$filepath" | cut -d' ' -f1)"
      if [[ "$actual_hash" != "$expected_hash" ]]; then
        echo "[FAIL] CHANGED: $filepath" >&2
        (( failed++ )) || true
      fi
    else
      echo "[FAIL] MISSING: $filepath" >&2
      (( failed++ )) || true
    fi
  done < "$baseline"
  return "$failed"
}

mkdir -p "$CHECKSUM_DIR"
baseline="$CHECKSUM_DIR/$(basename "$TARGET_DIR")-$(date +%Y%m%d).sha256"
generate_checksums "$TARGET_DIR" "$baseline"

3. Checksum-Dateien erstellen und verifizieren

Das Erstellen einer Checksum-Datei mit sha256sum ist ein Zweizeiler – die automatisierte Verifizierung in einem robuste Bash-Skript zu verpacken ist die eigentliche Arbeit. Die eingebaute Verify-Option sha256sum --check checksums.sha256 liest die Checksum-Datei, prüft jede Datei und gibt eine kompakte Zusammenfassung aus. Diese Option ist für interaktive Prüfungen ideal, aber für skriptgesteuerte Automatisierung fehlt die Kontrolle über Exit-Codes und Fehlerdetails. Ein eigenes Skript, das die Checksum-Datei zeilenweise verarbeitet, gibt granulare Kontrolle darüber, wie auf fehlende, veränderte oder neue Dateien reagiert wird.

Ein bewährtes Muster für die automatisierte Dateiintegrität prüfen: Beim ersten Deployment oder nach einem bewussten Update wird eine Baseline-Checksum-Datei erstellt und versioniert. Bei jedem weiteren Deployment vergleicht das CI-System den aktuellen Zustand gegen diese Baseline. Abweichungen werden als Fehler behandelt und der Deploy wird abgebrochen. So fungiert die Checksum-Datei als unveränderliche Referenz – ähnlich einem Lock-File, aber für Dateisystem-Inhalte statt für Paketversionen.

#!/usr/bin/env bash
# deploy-verify.sh — Verify deployment artifacts before go-live
set -euo pipefail

readonly BASELINE="/etc/deploy/checksums-baseline.sha256"
readonly DEPLOY_DIR="/var/www/html"
readonly REPORT_FILE="/tmp/integrity-report-$(date +%Y%m%d-%H%M%S).txt"

declare -i changed=0 missing=0 extra=0

check_integrity() {
  # Verify all files in baseline still match
  while IFS="  " read -r expected_hash filepath; do
    if [[ ! -f "$filepath" ]]; then
      echo "MISSING: $filepath" | tee -a "$REPORT_FILE"
      (( missing++ )) || true
    else
      actual_hash="$(sha256sum "$filepath" | awk '{print $1}')"
      if [[ "$actual_hash" != "$expected_hash" ]]; then
        echo "CHANGED: $filepath (expected: ${expected_hash:0:12}... got: ${actual_hash:0:12}...)" \
          | tee -a "$REPORT_FILE"
        (( changed++ )) || true
      fi
    fi
  done < "$BASELINE"

  # Detect files not in baseline (potentially injected)
  while IFS= read -r -d '' f; do
    if ! grep -qF "  $f" "$BASELINE"; then
      echo "EXTRA: $f" | tee -a "$REPORT_FILE"
      (( extra++ )) || true
    fi
  done < <(find "$DEPLOY_DIR" -type f -print0)

  echo "--- Summary: changed=$changed missing=$missing extra=$extra ---" \
    | tee -a "$REPORT_FILE"
}

check_integrity
if (( changed + missing > 0 )); then
  echo "[ERROR] Integrity check failed — aborting deploy" >&2
  exit 1
fi
echo "[OK] All checksums verified"

4. Dateigrößen mit find filtern und überwachen

Neben Checksums ist die Überwachung von Dateigrößen ein eigenständiger Aspekt der Dateiintegrität automatisiert prüfen. Unerwartete Größenänderungen können auf Dateikorruption, ein hängendes Schreibprogramm oder versehentlich abgeschnittene Dateien hinweisen. find bietet mit -size einen direkten Filter für Dateigrößen: find /var/log -size +100M findet alle Logdateien über 100 Megabyte. Die Einheiten sind c für Bytes, k für Kilobytes, M für Megabytes und G für Gigabytes. Ohne Vorzeichen sucht find nach exakter Größe, mit + nach größer-als, mit - nach kleiner-als.

Die Kombination aus Größenfilter und Integritätsprüfung ist besonders in Backup-Szenarien wertvoll. Eine Backup-Datei, die kleiner ist als erwartet, ist verdächtig – sie könnte beim Schreiben abgebrochen sein. Ein Bash-Skript kann nach dem Backup-Lauf prüfen, ob die erzeugten Archive eine Mindestgröße haben, ob die Größe im erwarteten Bereich relativ zur Vorgänger-Sicherung liegt und ob die Checksum stimmt. Diese dreistufige Prüfung deckt die häufigsten Backup-Fehlertypen zuverlässig ab.

5. Duplikate erkennen und bereinigen

Doppelte Dateien sind ein häufiges Problem auf Servern, die über Jahre gewachsen sind: Backup-Kopien an falschen Stellen, mehrfach kopierte Deployment-Artefakte, oder Import-Pipelines, die dieselbe Datei mehrfach verarbeiten. Das effizienteste Muster, um Dateiintegrität automatisiert prüfen und dabei Duplikate zu erkennen, nutzt Checksums als Gruppierschlüssel. Alle Dateien mit identischem Hash sind Duplikate – unabhängig von Name und Pfad.

Der Ablauf in Bash: Checksums aller Dateien berechnen, nach Hash sortieren, Gruppen mit mehr als einem Eintrag isolieren. Das gelingt mit sort, uniq -d auf der Hash-Spalte und einer anschließenden Filterstufe. Für große Verzeichnisse lohnt es sich, zuerst nach Dateigröße zu gruppieren – Duplikate haben immer dieselbe Größe, und der Hash-Vergleich nur innerhalb der Größengruppe spart erheblich Rechenzeit. Dieses zweistufige Muster (erst Größe, dann Hash) ist der Standard in professionellen Duplikat-Scanner-Tools.

#!/usr/bin/env bash
# find-duplicates.sh — Detect duplicate files by content hash
set -euo pipefail

readonly SCAN_DIR="${1:?Usage: $0 <directory>}"
readonly MIN_SIZE="${2:-1k}"  # ignore files smaller than this

declare -i dup_groups=0 dup_files=0 freed_bytes=0

echo "[INFO] Scanning $SCAN_DIR for duplicates (min size: $MIN_SIZE)..."

# Step 1: group by size first (fast pre-filter)
declare -A size_groups
while IFS= read -r -d '' f; do
  size="$(stat -c '%s' "$f")"
  size_groups["$size"]+="$f"$'\0'
done < <(find "$SCAN_DIR" -type f -size +"$MIN_SIZE" -print0)

# Step 2: for each size group with multiple files, compare by hash
tmpfile="$(mktemp)"
trap 'rm -f "$tmpfile"' EXIT

for size in "${!size_groups[@]}"; do
  group_files=()
  while IFS= read -r -d '' f; do
    group_files+=("$f")
  done <<< "${size_groups[$size]}"

  if (( ${#group_files[@]} < 2 )); then continue; fi

  # Hash all files in this size group
  for f in "${group_files[@]}"; do
    sha256sum "$f" >> "$tmpfile"
  done
done

# Step 3: find duplicate hashes
sort "$tmpfile" | awk '{print $1}' | sort | uniq -d | while read -r dup_hash; do
  echo "=== Duplicate group (SHA-256: ${dup_hash:0:16}...) ==="
  grep "^$dup_hash" "$tmpfile" | awk '{print $2}' | while IFS= read -r f; do
    size_bytes="$(stat -c '%s' "$f")"
    echo "  $f  ($(numfmt --to=iec "$size_bytes"))"
    (( dup_files++ )) || true
    (( freed_bytes += size_bytes )) || true
  done
  (( dup_groups++ )) || true
done

echo ""
echo "[RESULT] $dup_groups duplicate groups, $dup_files files"
echo "[RESULT] Potential space saving: $(numfmt --to=iec "$freed_bytes")"

6. Kontinuierliche Integritätsüberwachung

Eine einmalige Checksum-Prüfung beim Deployment reicht nicht aus, um Dateiintegrität automatisiert prüfen im laufenden Betrieb sicherzustellen. Produktive Systeme benötigen eine kontinuierliche Überwachung, die Veränderungen im Dateisystem zeitnah meldet. Das klassische Werkzeug hierfür ist ein Cron-Job, der stündlich oder täglich die Checksums kritischer Verzeichnisse mit einer Baseline vergleicht und bei Abweichungen eine Benachrichtigung sendet.

Für eine effiziente kontinuierliche Überwachung ist es wichtig, die zu überwachenden Verzeichnisse sinnvoll zu priorisieren. Konfigurationsdateien unter /etc, Webserver-Dokumentenroots, Deployment-Artefakte und Binaries unter /usr/local/bin sind typische Kandidaten. Temporäre Verzeichnisse, Logs und Caches sollten ausgeschlossen werden – sie ändern sich per Design, und false positives führen dazu, dass echte Alarme übersehen werden. Die Baseline-Datei selbst muss read-only sein oder außerhalb des überwachten Systems gespeichert werden, damit ein Angreifer sie nicht zusammen mit den Dateien manipulieren kann.

#!/usr/bin/env bash
# integrity-monitor.sh — Continuous file integrity monitoring via cron
# Cron: */30 * * * * /usr/local/bin/integrity-monitor.sh >> /var/log/integrity.log 2>&1
set -euo pipefail

readonly BASELINE_DIR="/etc/integrity-baselines"
readonly ALERT_EMAIL="${ALERT_EMAIL:-admin@mironsoft.de}"
readonly STATE_DIR="/var/lib/integrity-monitor"
mkdir -p "$STATE_DIR"

declare -a WATCH_DIRS=(
  "/etc/nginx"
  "/etc/php"
  "/var/www/html/app/code"
  "/usr/local/bin"
)

declare -a ALERTS=()

check_directory() {
  local dir="$1"
  local safe_name
  safe_name="$(echo "$dir" | tr '/' '_' | tr -s '_' | sed 's/^_//')"
  local baseline="$BASELINE_DIR/${safe_name}.sha256"
  local current_checksums
  current_checksums="$(mktemp)"
  trap 'rm -f "$current_checksums"' RETURN

  # Build current state
  find "$dir" -type f -not -name "*.log" -not -name "*.tmp" -print0 \
    | sort -z \
    | xargs -0 sha256sum 2>/dev/null \
    > "$current_checksums"

  # First run: just store baseline
  if [[ ! -f "$baseline" ]]; then
    cp "$current_checksums" "$baseline"
    echo "[INFO] Baseline created for $dir"
    return
  fi

  # Compare against baseline
  local diff_output
  diff_output="$(diff "$baseline" "$current_checksums" 2>&1 || true)"
  if [[ -n "$diff_output" ]]; then
    ALERTS+=("[ALERT] Changes detected in $dir:"$'\n'"$diff_output")
  fi
}

for dir in "${WATCH_DIRS[@]}"; do
  [[ -d "$dir" ]] && check_directory "$dir"
done

if (( ${#ALERTS[@]} > 0 )); then
  report="$(printf '%s\n\n' "${ALERTS[@]}")"
  echo "$report"
  # Send alert email if mail command is available
  if command -v mail &>/dev/null; then
    echo "$report" | mail -s "[INTEGRITY] Changes detected on $(hostname)" "$ALERT_EMAIL"
  fi
  exit 1
fi

echo "[OK] Integrity check passed at $(date)"

7. Backup-Validierung mit Checksums

Die Validierung von Backup-Dateien ist einer der kritischsten Anwendungsfälle, um Dateiintegrität automatisiert prüfen zu implementieren. Ein Backup, dessen Integrität nicht verifiziert wird, ist kein verlässliches Backup – es ist eine ungeprüfte Hoffnung. Die klassische Schwachstelle: Das Backup-Skript läuft durch, gibt Erfolg zurück, aber die erzeugte Datei ist durch einen Schreibfehler, vollen Festplattenspeicher oder einen Absturz mitten im Prozess beschädigt. Das fällt erst auf, wenn der Restore gebraucht wird.

Ein robustes Backup-Skript, das Dateiintegrität automatisiert prüfen implementiert, kombiniert drei Stufen: Erstens wird ein Pre-Backup-Snapshot der Quelldateien erstellt. Zweitens wird die Backup-Datei erzeugt und eine Checksum davon berechnet. Drittens wird das Archiv probeweise entpackt und die Checksums der entpackten Inhalte gegen den Pre-Backup-Snapshot verglichen. Nur wenn alle drei Stufen übereinstimmen, gilt das Backup als valide. Diese dreigliedrige Prüfung deckt Fehler beim Schreiben, beim Komprimieren und beim Archivieren zuverlässig ab.

8. Performance: Checksums auf großen Verzeichnissen

Auf Servern mit Hunderttausenden von Dateien kann das vollständige Berechnen von Checksums Minuten dauern und erheblichen I/O-Druck erzeugen. Für eine performante automatisierte Dateiintegrität prüfen-Strategie gibt es mehrere Optimierungsansätze. Der erste Ansatz ist inkrementelles Hashing: Nur Dateien, die seit der letzten Prüfung modifiziert wurden (erkennbar an mtime oder ctime), werden neu gehasht. Unveränderte Dateien behalten ihren gecachten Hash. Das reduziert den Aufwand bei regelmäßigen Prüfungen auf einen kleinen Bruchteil des Ausgangswerts.

Der zweite Ansatz ist Parallelisierung. xargs -P 8 sha256sum verteilt die Hash-Berechnung auf acht parallele Prozesse und nutzt damit Mehrkernsysteme aus. Auf SSDs ist diese Parallelisierung fast immer ein Gewinn, da der Flaschenhals die CPU ist, nicht das Speichermedium. Auf mechanischen Festplatten kann zu viel Parallelität durch wahlfreien Zugriff kontraproduktiv sein – hier ist serielle Verarbeitung oft schneller. Der dritte Ansatz ist Priorisierung: Kritische Systemdateien werden stündlich geprüft, große Mediendateien täglich, Archiv-Daten wöchentlich. Das schafft ein abgestuftes Sicherheitsnetz, das den I/O-Druck auf sensible Stoßzeiten meidet.

9. Checksum-Tools im direkten Vergleich

Die Wahl des richtigen Tools für die automatisierte Dateiintegrität prüfen hängt von Sicherheitsanforderungen, Performance und Kompatibilität ab. Diese Tabelle zeigt die wichtigsten Unterschiede der gängigen Tools.

Für die alltägliche automatisierte Dateiintegrität prüfen-Praxis ist SHA-256 der Industriestandard. Er ist überall verfügbar, ausreichend schnell, kryptografisch sicher und wird von allen Build-Systemen, Paketmanagern und CI-Plattformen unterstützt. BLAKE2 (b2sum) ist eine moderne Alternative, die auf manchen Systemen noch nicht vorinstalliert ist – für neue Projekte ohne Legacy-Anforderungen aber eine exzellente Wahl.

10. Zusammenfassung

Die automatisierte Dateiintegrität prüfen mit Bash kombiniert drei Werkzeugklassen: Checksum-Tools wie sha256sum für kryptografische Fingerabdrücke, find mit Größenfiltern für strukturelle Anomalien und Hash-basierte Duplikaterkennung für redundante Speicherprobleme. Zusammen bilden sie ein vollständiges System zur Überwachung von Dateisystem-Zuständen, das sich vollständig in bestehende Shell-basierte Automatisierung einbetten lässt.

Der Schlüssel zur Wirksamkeit liegt nicht im Werkzeug, sondern in der Systematik. Checksums ohne Baseline sind wertlos. Eine Baseline ohne regelmäßigen Vergleich ist ein einmaliger Snapshot ohne Überwachung. Und eine Überwachung ohne klaren Eskalationspfad erzeugt Berichte, die niemand liest. Nur wenn alle drei Komponenten – Baseline, regelmäßige Prüfung und Alerting – zusammenspielen, entsteht echte Beobachtbarkeit der Dateiintegrität im Produktionsbetrieb.

11. FAQ: Dateigrößen, Checksums und Integrität automatisiert prüfen