Il File Integrity Monitoring diventa utile quando non si limita a dire che “qualcosa è cambiato”, ma ci aiuta a stabilire che cosa, quando, con quali permessi e se la modifica era attesa. L’IR Stack descritto qui nasce proprio per trasformare modifiche sensibili e anomalie operative in eventi investigabili.
Componenti dello stack
Nel nostro ambiente lo stack combina auditd, unità systemd .path e .timer, un identity checker, un watcher dello stack, un alert sugli accessi SSH, un guardian dei servizi e un comando unico di controllo: newvoip-irctl.
systemctl status auditd
systemctl status newvoip-identity-incident.path
systemctl status newvoip-identity-incident.timer
systemctl status newvoip-ir-stack-watch.path
systemctl status newvoip-ssh-login-alert.timer
systemctl status newvoip-ir-guardians-watchdog.timerCosa monitoriamo
Il primo gruppo comprende identità e privilegi: /etc/passwd, /etc/group, sudoers, configurazione SSH e chiavi sensibili. Il secondo comprende lo stesso stack IR, i suoi helper e le unità systemd che potrebbero essere alterate per disattivarlo. A questi si aggiungono i file applicativi o di sicurezza che, in un determinato server, non dovrebbero cambiare fuori da un deploy.
Fingerprint: contenuto e permessi
Lo schema di fingerprint usato è la versione 2: per ogni path salviamo almeno percorso, mode Unix e SHA256. Questo permette di rilevare sia una modifica del contenuto sia un cambio di permessi.
stat -c '%n %a %U %G' /etc/passwd
sha256sum /etc/passwd
stat -c '%n %a %U %G' /etc/ssh/sshd_config
sha256sum /etc/ssh/sshd_configComando operativo
newvoip-irctl status
newvoip-irctl audit
newvoip-irctl logs
newvoip-irctl check
newvoip-irctl test-path
newvoip-irctl test-ir
newvoip-irctl test-watch
newvoip-irctl test-guardian
newvoip-irctl test-maintenancestatus serve per capire in pochi secondi se i watcher sono armati; check forza un controllo delle impronte; i test verificano separatamente la catena path → evento → alert, il guardian e la modalità manutenzione.
Auditd: vedere chi ha toccato il file
auditctl -l
systemctl status auditd
ausearch --start recent -m PATH,CONFIG_CHANGE,USER_CMDIl fingerprint ci dice che il file è diverso. Auditd aggiunge il contesto: utente, processo e timestamp. Le chiavi audit vanno scelte coerentemente con la propria configurazione, senza trasformare il sistema in una macchina da rumore.
Maintenance window
Un deploy legittimo può modificare decine di file. Invece di disattivare il monitoraggio, lo stack usa un marker temporaneo: /run/newvoip/ir-maintenance-until. Il monitor resta vivo ma sa che, fino a quella scadenza, alcune modifiche sono attese.
cat /run/newvoip/ir-maintenance-until 2>/dev/null || echo "nessuna manutenzione attiva"
newvoip-irctl test-maintenanceGuardian dei servizi
Sul PBX vengono verificati i guardian dello stack; sull’Edge Kamailio, RTPengine, dSIPRouter, firewalld e Fail2Ban sono monitorati in modalità alert-only: un servizio critico che cade genera un evento, ma il guardian non deve necessariamente riavviarlo alla cieca.
newvoip-irctl test-guardian
journalctl --since "-30 min" | grep -E 'IR STACK|guardian|incident'Lockdown e rollback
Lo stack dispone anche dei comandi lockdown e rollback, ma il lockdown resta una funzione separata e va abilitata deliberatamente. Sul nostro Edge la configurazione parte con ENABLE_LOCKDOWN="no": rilevare automaticamente un evento non significa che il sistema debba isolarsi automaticamente.
newvoip-irctl lockdown
newvoip-irctl rollback
ls -l /var/lib/newvoip-incident-response/lock*Quando arriva un alert
Il flusso di indagine consigliato è: 1) leggere il path segnalato; 2) confrontare mode e hash; 3) verificare la maintenance window; 4) interrogare auditd e journal; 5) controllare deploy o aggiornamenti contemporanei; 6) solo dopo decidere se aggiornare la baseline oppure trattare l’evento come incidente.
Gli oggetti mail sono normalizzati, per esempio [IR STACK] - modifica sensibile - HOST, accesso ssh, servizio down o anomalia identita. Questo rende filtrabili e correlabili gli eventi.
