Automatizzare l'integrità delle configurazioni con AIDE/Tripwire e controllo delle modifiche basato su Git

Introduzione: Perché automatizzare l’integrità delle configurazioni?

Automatizzare l’integrità delle configurazioni non è un lusso, ma una necessità operativa: garantisce che i file di sistema, i file di configurazione e i file binari non vengano modificati, manipolati o rimossi senza essere notati. Gli amministratori conoscono le cause delle discrepanze di integrità: deploy di configurazioni non intenzionali, aggiornamenti automatizzati, roll‑out falliti o attacchi reali. L’obiettivo di questo contributo è fornire una guida pratica su come strumenti classici host‑based per il controllo dell’integrità dei file come AIDE o Tripwire possano essere combinati con un controllo delle modifiche basato su Git (baseline in Git, commit firmati, verifica CI) — incluse le specificità cloud, le tipiche insidie, i processi di verifica e di rollback.

Concetti di base e panoramica dell’architettura

Prima di entrare nella realizzazione, una breve definizione dei termini: AIDE (Advanced Intrusion Detection Environment) e Tripwire sono checker dell’integrità dei file basati sull’host (FIM). Generano valori di controllo (hash, permessi, dimensioni dei file) per un insieme di file configurato e li confrontano con un database baseline. Il change‑control basato su Git significa qui che queste baseline, le modifiche alle policy e le regole di eccezione vengono gestite, firmate e sottoposte ad audit in un sistema di controllo di versioni (Git). Tramite pipeline CI/CD è possibile realizzare verifiche automatiche e gestire in modo riproducibile deviazioni dannose o non intenzionali.

Componenti architetturali tipiche

• Agenti host: AIDE o Tripwire su ogni server rilevante con esecuzione di controllo locale.
• Repository della baseline: Git (es. GitLab/GitHub/Bitbucket o un Git self‑hosted) conserva dump del DB, regole ed eccezioni.
• Job CI di verifica: controllano che una nuova baseline sia firmata e consistente prima di essere promossa al ramo di produzione.
• Alerting / Ticketing: webhook o push verso SIEM, PagerDuty o portale amministrativo interno.
• Archivio offsite: opzionale object store (compatibile S3) per snapshot immutabili e prove forensi.

Perché Git per le baseline? Vantaggi e limiti

Un repository Git fornisce tracciabilità (chi ha fornito quale baseline e quando), pacchetti di modifica atomici e la possibilità di imporre firme (commit firmati GPG o branch protection). Questo è preferibile a dump ZIP sparsi. Limiti: Git memorizza fondamentalmente blob di testo e binari, ma non è un archivio WORM. Per la conservazione a lungo termine con valore legale è necessario un archivio offsite con versioning degli oggetti o funzionalità Write‑Once‑Read‑Many (WORM).

Fase di pianificazione: prerequisiti e progettazione della policy

Un’automazione efficace inizia con policy chiare. Definite:

• Quali percorsi vengono monitorati (es. /etc, /usr/local/bin, unità systemd),
• Quali attributi vengono verificati (algoritmo di hash, permessi, proprietario, link simbolici),
• Regole di esclusione (file temporanei, output di build, /var/run),
• Frequenza delle esecuzioni di controllo (ogni minuto, ogni ora, giornaliera) e
• Comportamento in caso di deviazioni (alerting, revert automatico, generazione ticket).

Nota: scope troppo ampi generano un’inondazione di falsi positivi. Scope troppo ristretti trascurano manipolazioni rilevanti. Per istanze cloud è particolarmente importante gestire le directory effimere e i mount dei container.

Pratica: inizializzare AIDE, esportare la baseline e importarla in Git

L’esempio seguente mostra i passaggi preparatori su un Linux‑server con AIDE. Inizializziamo un database, generiamo artefatti di verifica esportabili e li committiamo in Git. Le spiegazioni seguono il codice.

# Installieren (Debian/Ubuntu Beispiel)
sudo apt update && sudo apt install -y aide git gpg

# Beispiel minimaler aide.conf (lokal, nur als Ausgangspunkt)
cat > /etc/aide/aide.conf <<'EOF'
@@
# Überwache /etc vollständig, berücksichtige Modi, Owner, Group und SHA512
/etc     Rsha512+perm+uid+gid
EOF

# Initiale Datenbank erstellen
sudo aideinit --config /etc/aide/aide.conf
# Standardmäßig legt aideinit eine neue Datenbank unter /var/lib/aide/aide.db.new.gz an
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

# DB exportieren (entpacken, als Binärblob oder hexdump für Git-Repo)
sudo zcat /var/lib/aide/aide.db.gz > /tmp/aide.db

# Git-Repo vorbereiten
mkdir -p /srv/integrity-baselines && cd /srv/integrity-baselines
git init --bare
# Alternativ: push in remote Gitlab/Github

# Auf einem Admin-Rechner: Repo klonen, DB hinzufügen, GPG-signed Commit
git clone admin@example:/srv/integrity-baselines.git
cd integrity-baselines
cp /tmp/aide.db .
# Signieren Sie Commits mit einem dedizierten Schlüssel (siehe unten)
git add aide.db
git commit -S -m "Baseline: initial AIDE DB for server-01"
git push origin main

Perché così? AIDE crea un database compresso; questo DB è l’immagine di controllo dell’integrità attuale del sistema. Archiviando questo DB in Git e facendo commit firmati, create una prova tracciabile: chi ha creato la baseline e quando. La firma GPG protegge dall’inserimento non autorizzato di baseline false.

Istruzioni di configurazione importanti

• Algoritmo di hash: utilizzare algoritmi robusti (SHA‑256/512). Per AIDE configurare Rsha256/Rsha512.
• Grandi dati binari: se il DB diventa molto grande, valutare un object store invece dei Git‑Blobs (vedere la sezione Cloud).
• Gestione delle chiavi: le chiavi GPG per le firme dei commit devono essere gestite in modo sicuro (subkeys, token hardware) e distribuite all’interno dell’organizzazione.

Esecuzione di controllo automatica: timer systemd e gestione dei risultati

Per controlli regolari si raccomandano i timer systemd invece di cron, perché systemd offre una migliore gestione di avvio/arresto e logging. Esempio di timer e service:

# /etc/systemd/system/aide-check.service
[Unit]
Description=AIDE integrity check and report

[Service]
Type=oneshot
ExecStart=/usr/local/bin/aide-check-and-report.sh

# /etc/systemd/system/aide-check.timer
[Unit]
Description=Daily AIDE check

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Lo script vero e proprio dovrebbe eseguire il controllo AIDE, parsare l’output, in caso di differenze esportare gli artefatti, firmarli e collocarli in una directory temporanea, prima che un processo dedicato spinga i dati nel repository Git centrale o crei un incidente. In questo modo si evitano race conditions tra l’esecuzione del controllo e gli aggiornamenti della baseline.

Esempio: aide-check-and-report.sh (semplificato)

#!/bin/bash
set -euo pipefail
OUTDIR=/var/tmp/aide-checks/$(hostname)-$(date +%Y%m%d%H%M%S)
mkdir -p "$OUTDIR"

# Prüfen
sudo /usr/bin/aide --check --config /etc/aide/aide.conf | tee "$OUTDIR/aide.out"

# Wenn Abweichungen, exportieren und pushen
if grep -q "found differences" "$OUTDIR/aide.out"; then
  sudo zcat /var/lib/aide/aide.db.gz > "$OUTDIR/aide.db"
  # Signieren
  gpg --default-key admin@example.com --armor --output "$OUTDIR/aide.db.sig" --sign "$OUTDIR/aide.db"
  # Übergabe an zentralen Upload-Prozess (Webhook, scp, git-push agent)
  /usr/local/bin/integrity-uploader --dir "$OUTDIR"
fi

Importante: l’upload verso il Git‑repo dovrebbe essere eseguito da un account dedicato e ben controllato (es. un pull‑server), non direttamente dall’host di produzione, per ridurre il rischio di manipolazioni dirette.

Workflow Git e CI: protezione, verifica e deploy

Il workflow Git si basa sui seguenti principi: branch protetti, commit firmati, job CI per la validazione e uno strato di review per le modifiche alla baseline. Un esempio di flusso:

1. L’agente genera l’export del DB e crea un merge request in un repository di staging (o deposita un file in un branch PR).
2. Il job CI verifica l’integrità del DB, controlla la firma GPG, esegue test (es. Reproduce Check on Staging) e produce uno stato di risultato.
3. Dopo la review e i check verdi viene effettuato il merge del PR nel branch protected/main.
4. Gli host di produzione scaricano automaticamente la nuova baseline nel successivo ciclo di controllo o quando richiesto esplicitamente.

Esempio di job GitLab CI per la verifica di un DB AIDE (semplificato):

stages:
  - verify

verify_aide_db:
  stage: verify
  image: alpine
  script:
    - apk add --no-cache gpg
    - gpg --verify aide.db.sig aide.db
  only:
    - merge_requests

La verifica CI impedisce che baseline non autentiche o corrotte arrivino automaticamente in produzione. Attivate Branch Protection, pipeline CI obbligatorie e regole di reviewer strettamente necessarie.

Specificità Cloud: host effimeri, object store e IAM

Negli ambienti cloud esistono requisiti particolari: i server sono spesso di breve durata (Ephemeral), gli indirizzi IP cambiano e i DB‑Blob locali sono volatili. Strategie:

• Conservare Baselines persistenti in un object store centrale (S3, compatibile S3) invece di memorizzarle tutte come Git‑Blobs.
• Proteggere gli accessi al repo Git tramite deploy keys o Service Accounts; concedere privilegi elevati solo all’Upload‑Agent.
• Per l’Auto‑Scaling: al boot dell’istanza forzare un controllo iniziale AIDE rispetto alla baseline centrale oppure utilizzare immagini con baseline verificata a priori.
• Usare ruoli IAM (es. AWS IAM, GCP Service Account) invece di chiavi statiche e limitare i permessi in modo granulare.

Esempio: Upload in S3 und Commit‑metadaten in Git (Pseudocode):

# Upload aide.db und sig nach S3
aws s3 cp aide.db s3://integrity-archive/host-01/aide.db --acl private
aws s3 cp aide.db.sig s3://integrity-archive/host-01/aide.db.sig --acl private

# Commit Metadaten in Git
git add metadata/host-01/20260801.json
git commit -S -m "Baseline upload metadata host-01 2026-08-01"
git push origin main

Trappole tipiche e come evitarle

Alcuni errori operativi frequenti e come affrontarli:

• Falsi positivi dovuti a file temporanei: definire esclusioni precise (es. /var/run, /tmp) e testare le regole gradualmente.
• Manomissione della DB locale: non fare affidamento esclusivamente sulla DB locale; utilizzare Baselines firmate e memorizzate centralmente.
• Race condition durante deploy in corso: coordinare Deploy‑Windows con controlli o usare una breve fase di quarantena per i nuovi deploy.
• DB‑Blob di grandi dimensioni: usare esportazioni incrementali o object store invece di Git quando le dimensioni aumentano.
• Frequenza di controllo troppo bassa: per sistemi critici la verifica giornaliera spesso non è sufficiente; controlli orari o controlli attivati da eventi sono consigliabili.

Gestione degli incidenti: verificare, riprodurre, ripristinare

Un runbook chiaro previene decisioni errate. Proposta per la procedura di gestione di un incidente in caso di deviazioni:

1. Snapshot/Dump forense immediato della macchina interessata (memorydump se possibile) per preservare tracce volatili.
2. Confronto dell’output locale di AIDE con l’ultima Baseline firmata nel Git/object store.
3. Analisi: si tratta di una modifica pianificata (Deploy), di un aggiornamento involontario o di una possibile compromissione?
4. Se pianificato: marcare la deviazione come approved‑change e aggiornare la Baseline tramite il normale workflow Git/CI.
5. Se non pianificato o sospetto: isolare, ripristinare l’ultimo image/backup verificato, generare audit trail e avviare l’analisi forense.

Importante: revert automatici possono essere utili, ma sono rischiosi. Meglio avere allarmi chiari e approvazione umana, salvo in ambienti strettamente controllati con script di rollback testati.

Aspetti di sicurezza: firme, gestione delle chiavi e hardening

L’integrità non si basa solo sugli hash, ma sulle firme e sulla protezione delle chiavi di signing. Buone pratiche:

• Usare token hardware (HSM, YubiKey) per il GPG‑Signing, in particolare per le Baselines di produzione.
• Separare Upload‑Agent e host di produzione; ridurre i permessi al minimo.
• Proteggere i repo Git con Branch Protection, permessi di push minimi e pipeline di merge obbligatorie.
• Conservare i backup delle chiavi di firma in modo sicuro e pianificare la rotazione delle chiavi.

Test, validazione e metriche

La qualità misurabile è determinante. Metriche raccomandate:

• Numero di deviazioni per host per settimana (trend).
• Median‑Time‑to‑Detect (MTTD) e Median‑Time‑to‑Resolve (MTTR) per incidenti di integrità.
• Tasso di falsi positivi dopo modifiche alle regole.

Esecuzioni di test pianificate regolarmente (modifiche in stile chaos in staging) convalidano che il vostro workflow rilevi e gestisca correttamente le deviazioni. Eseguite i playbook e misurate i tempi fino all’analisi e al ripristino.

Esempio pratico: dalla richiesta di modifica della baseline alla produzione

Un amministratore deve distribuire una modifica legittima alla configurazione del demone SSH:

1. Sviluppare la modifica localmente e pushare in un repo/branch.
2. Creare MR/PR, eseguire i test CI (syntax, linter, simulazione RESTart del servizio).
3. Dopo la review fare merge nel ramo staging; deploy in Staging e AIDE/Tripwire verificano gli host di staging.
4. Se verificato, generare l’export della baseline dallo staging, firmarlo e creare MR in main.
5. Dopo la review fare merge in main; gli host di Production scaricano la nuova baseline o eseguono un controllo iniziale rispetto alla nuova baseline.

Questo flusso riduce il rischio che una baseline non testata arrivi in produzione e fornisce evidenza di audit chiara per la compliance.

Checklist per il rollout

• Lista scope definita per FIM (elenco dei percorsi, attributi).
• Politica di firma GPG e gestione delle chiavi implementate.
• Repository Git preparato con branch‑protection e job CI configurati.
• systemd‑Timer o Cron‑Job configurato con agent di upload.
• Alerting integrato (SIEM, ticketing, PagerDuty) e runbook disponibile.
• Test di rollback e processi per snapshot forense documentati.

Conclusione: l’integrità pratica richiede combinazione di strumenti e processi

Automatizzare l’integrità delle configurazioni è più che installare AIDE o Tripwire: è la combinazione di policy chiaramente definite, un controllo delle modifiche basato su Git auditabile, baseline firmate, pipeline CI verificanti e runbook di incidente ben definiti. In ambienti cloud si aggiungono requisiti come object store, IAM e host effimeri. Iniziate in piccolo (percorsi critici), misurate i falsi positivi e ampliate scope e automazione progressivamente. In questo modo otterrete una soluzione robusta che unisce sicurezza operativa, tracciabilità e conformità.

Risorse avanzate e collegamenti interni

Per implementazioni più approfondite è consigliabile consultare guide su GPG Key Management, integrazione CI/CD e Cloud IAM. Assicuratevi che i vostri runbook interni riflettano i passaggi descritti in questo articolo, affinché i team on‑call possano agire rapidamente e in sicurezza in caso di incidente.

FAQ

Anche File Integrity Monitoring e Git Change Control sono rilevanti per questo tema. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.