In un precedente articolo – Microsoft Sentinel + Azure Arc: attivare la raccolta degli audit log – abbiamo visto come attivare la cattura log tramite Azure Arc. In questo articolo vedremo come raccogliere i log generati da Veeam Backup & Replication.
Prima di poter cominciare, è necessario aver già effettuato le seguenti operazioni:
- Installare Azure Arc su una macchina Linux con la funzione di log forward
- Attivare il syslog all’interno di Veeam Backup & Replication
- Creare una Data Collections Rule legata al server Linux bridge
Configurazione rsyslog Linux
Azure Arc permette di collezionare i log da macchine Windows e Linux, tuttavia i device di rete non hanno la possibilità di installare questo agente, quindi è possibile sfruttare un ponte tramite una macchina Linux che facendo da rsyslog invierà i dati verso Log Analytics. Quante macchine bridge sono necessarie in nella mia infrastruttura? Dipende dalla complessità della vostra infrastruttura ma anche dalla mole di log generati.
I passaggi per configurare sono riportati nel seguente articolo – Collect Syslog events with Azure Monitor Agent – Azure Monitor | Microsoft Learn
Configurazione Veeam
La versione 12.1 di Veeam Backup & Replication ha introdotto l’integrazione nativa con i SIEM, al fine di poter collezionare in un repository centralizzato, gli eventi legati ai job ed alla gestione della piattaforma. Quello che poi fa questa “integrazione” è raccogliere gli eventi scritti in Windows e mandarli dentro un syslog con un formato RFC 5424.
Alcuni aspetti chiave dell’integrazione SIEM con il backup includono il monitoraggio degli eventi relativi al backup, la correlazione dei dati per identificare più efficientemente minacce o violazioni della sicurezza legate alle operazioni di backup, e l’implementazione di allarmi in tempo reale per attività sospette o insolite legate al backup.
Vero è anche che Veeam ONE consente di avere degli alert sui comportamenti non standard della componente di backup, ma attraverso un SIEM è possibile attuare politiche più estese di protezione, sfruttando la logica del SOAR – che ci potrebbe permettere di isolare il server oppure isolare chi sta effettuando l’operazione malevola da remoto.
Per chi non avesse ancora un SIEM o non usasse Log Analytics, in PowerShell è possibile fare delle query, come riportato in questo nostro articolo – Veeam Backup & Replication: Audit Attività Amministratori.
Configurazione Log Analytics
Il salvataggio dei log in Log Analytics, poter costruire delle viste di quello che viene fatto, avere una zona dove visualizzare le attività degli amministratori e, volendo, generare degli allarmi su potenziali problemi (magari più fronte security che job fail).
Importante è andare a creare una Data Collection Rule che prelevi i log relativi a Veeam che, almeno per ora, fanno capo alla facility Log_User.
Passate un po’ di ore dall’attivazione della DCR, sarà possibile eseguire le query tipo la seguente: Syslog | where Computer contains “bck01” -> modificate il nome computer con il vostro Veeam.
La cosa che si nota subito è che, a differenza del mondo Windows, si va a chiamare la classe Syslog che racchiude tutto quello che riguarda il mondo Linux e che può essere filtrata per il nome dell’oggetto per cui ci interessa recuperare i log.
Come faccio a vedere solo le colonne che mi interessano? Dopo aver eseguito la vostra query, potrete usare il comando Project per scegliere le colonne che intendete visualizzare. Ad esempio potete usare questa query: Syslog | where Computer contains “bck01” | project EventTime, SeverityLevel, SyslogMessage, ProcessName
Kusto Query Language Power
Come ogni volta che abbiamo a che fare con KQL, ci possiamo sbizzarrire nella personalizzazione delle query per avere una veste grafica più gradevole. Questa query è la chiusura di quanto abbiamo trattato in questo articolo, con annesse personalizzazioni fronte icone e colonne:
Syslog | where Computer contains “bck01”
| extend BackupStatus = iif(SyslogMessage contains “has been completed” and SeverityLevel == “info”, “✅”,
iif(SyslogMessage contains “has been completed” and SeverityLevel == “warn”, “⚠️”,
iif(SyslogMessage contains “has not been completed” and SeverityLevel == “error”, “❌”, “”)))
| extend SeverityLevel = case(SeverityLevel contains “info”, ‘✅ Success’, SeverityLevel contains “warn”, ‘⚠️ Warning’, SeverityLevel contains “error”, ‘❌ Failure’, ‘none’)
| extend CleanedSyslogMessage = replace(“Session”, “”, SyslogMessage)
| project EventTime, BackupStatus, SeverityLevel, CleanedSyslogMessage
I Limiti
Utilizzando questa integrazione si nota ancora la mancanza di diversi aspetti, come l’auditing amministrativo (chi ha fatto cosa) ed altre informazioni che dovrebbero essere presenti in un SIEM. Queste mancanze, lato Veeam, si spera vengano colmate presto con i prossimi update.
Conclusioni
Azure Arc, integrato con Veeam Backup & Replication, è sicuramente la soluzione ideale per il monitoraggio dei backup della nostra infrastruttura. L’utilizzo avanzato di KQL aiuta gli IT Admin a tenere sotto controllo tutte le operazioni eseguite dagli utenti ma anche dei processi e servizi.