Azure Arc: configurare un Linux rsyslog verso Log Analytics

Azure Arc Linux Syslog

Nuovo appuntamento relativo ad Azure Arc, dove andremo a vedere come funziona l’integrazione del mondo Linux in funzione dei device basati su firmware proprietari, o software particolari. In questo precedente articolo abbiamo visto come integrare la parte syslog di Veeam Backup & Replication, all’interno di Log Analytics per raccogliere tutto quello che viene fatto dagli amministratori, così come la parte di job history.

La la domanda che viene fatta più volte è: “Come si configura la macchina bridge per trasformarla in un rsyslog verso Log Analytics?” Prima di cominciare, è bene dire che la logica dietro le quinte non è cambiata molto, ma il vecchio Microsoft Management Agent (MMA), ereditato da System Center Operations Manager, è stato deprecato e ritirato pochi mesi fa in modo ufficiale, per fare posto a Azure Monitor Agent (AMA) che offre molte più funzionalità sul fronte della granularità, tra cui l’uso delle Data Rule Collection – argomento già trattato più volte nei vari articoli precedenti.

Ma perchè un rsyslog? Perchè i device come firewall, switch e storage, non hanno la capacità di scrivere direttamente in Log Analytics, avendo bisogno di un agent o delle API integrate per poter spostare i propri log. Syslog è uno “standard” universale, che qualsiasi piattaforma SIEM supporta e quindi viene più facile stare nel mezzo, piuttosto che costruire un adattamento che poi andrebbe fatto per tutti I vari vendor sul mercato.

Installazione

La macchina Linux rsyslog deve essere tra le SKU supportate da Azure Arc – Connected Machine agent prerequisites – Azure Arc | Microsoft Learn – mentre l’installazione dell’agent è quella classica disponibile dal portale di Arc.

Una volta completata l’installazione, e presentata la risorsa in Azure Arc, sarà possibile effettuare la creazione della Data Collection Rules (DCR), necessaria per raccogliere i log che ci interessano. Per ambienti piccoli è possibile usare un solo server di forward, ma per esigenze più spinte è suggerito avere più macchine a cui dovrete dividere il carico manualmente; non esiste oggi un sistema di bilanciamento, che consente di avere un solo FDQN o IP da raggiungere.

Il consiglio è di creare una DCR appositamente per la parte di forward log, per evitare il mischiarsi di altre regole, e necessità, in ambito Linux. Dopo aver impostato un nome, usando una naming convention appropriata, selezionate il server che avete appena configurato su Azure Arc.

La DCR elenca tutti quelli che sono le facilities recuperabili in Linux: questo campo da quanti device volete gestire. Il livello minimo per cui raccogliere le informazioni deve essere impostato su LOG_INFORMATION o LOG_NOTIFY; tutti gli altri attributi dovrebbe essere disattivati, per evitare il generare di eventi non necessari ma, soprattutto, per contenere i costi dati dal continuo upload di dati in Log Analytics.

Completata la parte di Data Source, selezionare la destination in cui salvare le informazioni – ovvero il Log Analytics Workspace che dovrete già aver creato.

Un altro elemento fondamentale per questo scope, è l’attivazione di Microsoft Sentinel, il SIEM di casa Microsoft, che preleva le informazioni raccolte da Log Analytics, per poterle analizzare e trattare al fine di notificare comportamenti pericolosi o non standard.

Di Sentinel, in modo approfondito, ne parleremo in un altro articolo, mentre per ora ci dedichiamo all’attivazione del Data Connector chiamato Syslog via AMA, da non confondere con Syslog via Legacy Agent – ovvero quello che usava MMA.

All’interno della pagina di configurazione, se avete creato correttamente la DCR, troverete la regola esposta ed un comando da lanciare dentro la macchina scelta per fare rsyslog. Questo passaggio è fondamentale per consentire il forward dei log da locale a Log Analytics.

Al termine di questa operazione, dopo circa 10 minuti, e dopo aver impostato come destination Syslog, dei vostri apparati, potete lanciare la query Syslog per vedere il risultato.

Finito! Per quanto riguarda Veeam Backup & Replication, vi rimando a quest’altro articolo per le query per sapere quali quale facility configurare e quali sono le query utilizzabili – Azure Arc & Log Analytics: raccogliere i log da Veeam Backup & Replication – WindowServer.it.

Conclusioni

L’utilizzo di una macchina Linux, configurata come rsyslog, consente di spostare un altro elemento della gestione infrastrutturale in cloud. E’ bene partire con piccole prove e soprattutto tarare correttamente la tipologia di log spostati dal device verso il bridge, per evitare sia l’ingestion esagerato, ed inutile, di informazioni sia per contenere I costi derivati dall’aumento della capacità del Log Analytics.