• Cloud, Guide, Sicurezza, Sistemi Operativi
• 14 Settembre 2023

Microsoft Sentinel è una soluzione Cloud Based scalabile di Microsoft e vi permette di:

• Gestire le informazioni e gli eventi di sicurezza (SIEM)
• Orchestrare e rispondere in modo automatizzato ad eventi di sicurezza (SOAR)

Per l’implementazione di Microsoft Sentinel vi rimando all’articolo di Nicola Ferrini Azure Sentinel: il nuovo SIEM as a Service – ICT Power

Questa soluzione, come vedrete nell’articolo, permette in modo veramente semplice eseguire l’invio di log e/o eventi di sistemi operativi Windows e Linux, ma anche di altri dispositivi che supportino SYSLOG o che abbiamo la configurazione nativa con Microsoft Sentinel.

In questo articolo vedrete come configurare un Gateway Analytics Windows e un server SYSLOG Linux, che avranno il ruolo di “raggruppare” tutti i log per poi spedirli a Microsoft Sentinel. È possibile comunque inviare i log a Sentinel in modo nativo, ma molte volte non si vogliono esporre verso internet macchine sensibili, come ad esempio i domain controller, e quindi si configurano i proxy/gateway che inviano i log di queste macchine per poi inviarli al SIEM, in modo tale che solo essi siano esposti in internet.

Scenario

In questo articolo vedrete sostanzialmente 4 macchine virtuali:

• Macchina LINUX à Sarà il Proxy per tutti i dispositivi Linux
• Macchina SRVDC à Sarà il Gateway per le macchine Windows
• SERVER LINUX à Sarà la macchina Linux che invierà i log al Proxy
• VM365 à Sarà la macchina Windows che invierà i log al Gateway Windows

Specifico che Proxy e Macchina Linux nel mio caso sono Ubuntu LTS; quindi, i comandi presenti sono per questa versione di sistema operativo.

Così potrete vedere diverse fonti che inviano i log, vedrete la configurazione di tutte le macchine e per ultimo vedrete anche la visualizzazione degli stessi all’interno della dashboard di Microsoft Sentinel.

L’unico prerequisito da rispettare è quello di essere in possesso di una sottoscrizione Azure a consumo per poter creare il Workspace, ovvero il “contenitore” che racchiude tutte le configurazioni ed i log inviati al Siem di Microsoft.

Gli step che andrete a vedere in questo articolo saranno i seguenti:

• Configurazione Connettori in Microsoft Sentinel
• Installazione Proxy Linux sulla macchina LINUX
• Installazione SYSLOG sulla macchina SERVERLINUX
• Installazione Gateway sulla macchina SRVDC
• Installazione Log Analytics Agent sulla macchina VM365

Ora che avete chiaro tutti i passaggi che vedrete, entrate all’interno del portale di Azure con credenziali di Global Admin Home – Microsoft Azure e aprite il servizio di Microsoft Sentinel.

Figura 1: Microsoft Sentinel

Cliccate ora sul nome del Workspace:

Figura 2: Microsoft Sentinel

Ora dovrete installare il connettore SYSLOG per poi procedere alla configurazione dello stesso:

Figura 3: Installazione Connettore Syslog

Attendete qualche secondo per l’installazione del connettore (nel mio caso sono bastati 10 secondi) ed il connettore sarà pronto per essere configurato.

Figura 4: Configurazione Connettore Syslog

Figura 5: Configurazione Connettore Syslog

Linux Server Proxy

Figura 6:Download Agent Linux

A questo punto copiate la stringa del punto numero 2 ed eseguite il comando nel vostro server Linux che ospiterà il Proxy Collector:

Figura 7:Installazione Agent Server Linux Proxy

Ora verificate che il servizio Syslog sia attivo: “sudo service rsyslog status”

Figura 8:Verifica Servizio Syslog

Se doveste riscontrare il servizio Syslog non attivo potete eseguire questo comando: “sudo service rsyslog start”

Ora che il servizio rsyslog è attivo, procedete alla configurazione del file che permetterà di creare una cartella all’interno del proxy divisa per hostname delle macchine che invieranno log. Questo non è obbligatorio, ma è fortemente consigliato in modo che abbiate una situazione più pulita e ordinata.

sudo nano /etc/rsyslog.conf

Inserite nel punto 1 della schermata sottostante questa stringa:

$template FILENAME,”/var/log/%HOSTNAME%/syslog.log”

*.* ?FILENAME

Inoltre, è fondamentale che rimuoviate i commenti dei punti 2 e 3, questo permetterà al server Proxy di rimanere in ascolto sulla porta 514 sia UDP che TCP per la ricezione dei log, una volta completata la modifica del file basta che cliccate CTRL+X à Y à ENTER

Figura 9:Configurazione File Syslog

Ora non vi rimane che aprire sul firewall linux la porta 514 TCP/UPD:

sudo ufw allow 514/tcp

sudo ufw allow 514/udp

di fondamentale importante è riavviare il servizio Syslog dopo aver eseguito modifiche al file di configurazione, per farlo basta che eseguite questo comando: sudo service rsyslog restart

Ora siete pronti per configurare la macchina Linux che dovrà inviare i log al server proxy che avete appena ultimato di configurare.

Linux Client

Loggatevi in SSH alla macchina da configurare, in questo caso io ho utilizzato una sessione con Putty:

Figura 10:Sessione SSH Macchina Linux

Rsyslog di default è già installato all’interno di macchina Linux, per verificarlo basta che eseguite il comando visto in precedenza:

Figura 11: Servizio Syslog Linux

Se non dovesse essere presente procedete all’installazione con il seguente comando: sudo apt-get install rsyslog -y

In questo dovendo mandare i log ad un proxy non dovete eseguire l’installazione dell’agent, ma configurare il file syslog per farlo “puntare” al server proxy che si occuperà poi di inviare i log a Microsoft
Sentinel, aprite quindi in modalità di modifica il file di configurazione sudo nano /ect/rsyslog.conf a questo punto inserite questa stringa all’inizio del file *.* INDIRIZZOIPSERVERPROXY:514 , specifico che “*.*” serve per inviare qualsiasi log alla macchina proxy, ma in caso di necessità è possibile inserire solo determinate tipologia di log, in questo caso non è necessario rimuovere i commenti dalle parte evidenzata, in quanto dovrà inviare log e non riceverli:

Figura 12:Configurazione LInux per invio Log

Per eseguire il salvataggio del file vi ricordo i comandi: CTR+X à Y à ENTER

Ora come ultimo punto eseguite un riavvio del servizio Rsyslog: sudo service rsyslog restart

A questo punto recatevi all’interno del worksapce di Sentinel per vedere se effettivamente il SIEM stà ricevendo i log Microsoft Sentinel – Microsoft Azure

Figura 13: Microsoft Sentinel

Figura 14: Syslog Macchina Linux

Nell’eventualità che vogliate approfondire l’installazione dell’Agent lato Linux vi rimando alla documentazione ufficiale Microsoft Install Log Analytics agent on Linux computers – Azure Monitor | Microsoft Learn

Windows Gateway

Ora che avete inserito sotto monitoraggio dispositivi Linux, passiamo all’installazione del Gateway su una macchina Windows, nel mio caso SRVDC è una macchina con Windows Server 2022. Recatevi quindi nella sezione di Microsoft Sentinel, come avete già fatto in precedenza per la parte Linux, ma questa volta selezionate Windows Server:

Figura 15: Download Log Analytics Gateway

Eseguite il programma appena scaricato:

Figura 16: Installer Log Analytics Gateway

Figura 17:Installazione Log Analytics Gateway

Ora dovrete configurare una porta con cui il gateway rimanga in ascolto, nel mio caso ho scelto la 8080:

Figura 18: Installazione Gateway

Ora avrete terminato l’installazione, una volta ultimata procedete a scaricare l’Agent, sempre dal portale di Microsoft Sentinel, stessa schermata che avete usato per scaricare l’installare di OMS:

Figura 19: Installazione Windows Agent

Scaricate il programma ed eseguitelo, preferibile farlo tramite il Runas Administrator:

Figura 20: Installazione Windows Agent

Figura 21:Installazione Windows Agent

Figura 22:Installazione Windows Agent

Figura 23:Installazione Windows Agent

Figura 24:Installazione Windows Agent

Ora dovrete inserire WORKSPACE ID e CHIAVE PRIMARIA, recuperabili dalla pagina di Microsoft Sentinel dove avete scaricato l’agent e successivamente cliccare su “Avanzate”:

Figura 25:Installazione Windows Agent

Figura 26:Installazione Windows Agent

Quando avrete inserito Workspace ID e Primary Key e aver cliccato su Avanzate, vi permetterà se avete un proxy di navigazione di configurarlo:

Figura 27:Installazione Windows Agent

Per verificare che la configurazione del Gateway sia andata a buon fine aprite il pannello di controllo della macchina Gateway:

Figura 28:Installazione Windows Gateway

Ora dovrete eseguire I seguenti comandi PowerShell in modalità Runas administrator:

Add-OMSGatewayAllowedHost -Host global.handler.control.monitor.azure.com

Add-OMSGatewayAllowedHost -Host <gateway-server-region-name>.handler.control.monitor.azure.com

Add-OMSGatewayAllowedHost -Host <log-analytics-workspace-id>.ods.opinsights.azure.com

Per quanto riguarda GATEWAY-SERVER-REGIONE-NAME nel caso di westeurope inserirlo nel seguente modo westeurope.handler.control.monitor.azure.com

Per log-analytics-workspace-id copiarlo dalla console di Sentinel.

Riavviate il servizio Gateway:

Stop-Service -Name <gateway-name>

Start-Service -Name <gateway-name>

Per eventuali approfondimenti vi rimando al link Microsoft ufficiale Configurazione di Microsoft Monitoring Agent | Microsoft Learn

Microsoft Monitoring Agent (Lato Client)

Ora potete procedure alla configurazione dei dispositivi Windows che invieranno i log al gateway, l’installare è sempre Windows Agent, potete utilizzare anche quanto scaricato nel precedente passaggio, mi raccomando tenete sotto mano WORKSPACEID e CHIAVE PRIMARIA:

Figura 29: Installazione MMA Agent

Figura 30:Installazione MMA Agent

Figura 31:Installazione MMA Agent

Figura 32:Installazione MMA Agent

Figura 33:Installazione MMA Agent

Figura 34:Installazione MMA Agent

Figura 35:Installazione MMA Agent

Dopo aver selezionato “Avanzate” nel caso di macchine “Lato Client” e quindi che devono inviare i log al gateway dovrete inserire l’indirizzo IP del server Gateway (o fqdn) con relativa porta configurata che nel mio caso è la 8080:

Figura 36:Installazione MMA Agent

Specifico che in ogni caso la configurazione è modificale anche in un secondo momento dal pannello di controllo della macchina, ora cliccate su Next e terminate la configurazione, recandovi successivamente nel pannello di controllo:

Figura 37:Installazione MMA Agent

Figura 38:Proxy Server correttamente Configurato

Figura 39: Agent MMA Funzionante

A questo punto la macchina che avete configurato sta correttamente inviando i propri log al Gateway che si occuperà di inviarli a Microsoft Sentinel, come fatto per Linux, andate a verificare ora sul portale di Sentinel con la KQL che effettivamente i log compaiano:

Figura 40: Visualizzazione Log Windows

La query può essere strutturata in questo modo: union Event | where Computer contains “VM365” sostituito VM365 con il nome macchina che avete scelto del vostro server/computer:

Figura 41: Visualizzazione Eventi Windows

Ora che avete collezionato i log da varie fonti come fate a fare ad effettuare delle ricerche su di essi ?

Microsoft Sentinel utilizza un linguaggio chiamato KQL (Kusto Query) che vi permette di eseguire delle ricerche all’interno dei dati che ora risiedono all’interno del SIEM Microsoft, a tal proposito vi lascio il link ufficiale Microsoft dove potete approfondire il linguaggio appena descritto Linguaggio di query Kusto in Microsoft Sentinel | Microsoft Learn.

Per eseguire KQL dovrete recarvi all’interno del worksapce di Sentinel che abbiamo visto insieme all’inizio di questo articolo.

Figure 42: Creazione KQL

Avete a disposizione anche Github dove la community mette a disposizione delle KQL già compilate e divise per categorie di Servizio Microsoft 365 GitHub – reprise99/Sentinel-Queries: Collection of KQL queries, il linguaggio di Sentinel, è per voi di fondamentale importanza perché vi permette di avere export puntuali per esempio sulle Login Fallite da un determinato indirizzo IP. Vorrei in questo articolo anche spiegarvi la struttura di questo linguaggio e darvi dimostrazione di una KQL per eseguire la ricerca delle login effettuate 3 giorni fa dal mio account di Microsoft 365.

Figure 43: Esempio KQL

Come potete notare la prima parte “SigninLogs” è la tabella di Microsoft Sentinel in cui eseguire la ricerca, nel mio caso cercando le Login di Azure Active Directory ho selezionato questa tabella, vi riporto per completezza di informazioni la lista della tabelle disponibili Microsoft Sentinel data source schema reference | Microsoft Learn

Nella seconda riga andate a selezionare l’arco temporale della ricerca nel mio caso “where TimeGenerated > ago(14d)” ovvero ricerco i log degli ultimi 14 giorni.

Nella terza riga invece con il comando “where UserPrincipalName == [email protected]” specificate alla query di trovare i registri in cui lo username che ha effettuato l’accesso è uguale a [email protected], specifico che dovete sostituire dominio.com con il dominio corretto da ricercare.

Nella quarta riga con il comando “where ResultType == 0” ricercate solo ed esclusivamente le login in stato di Success di quello specifico utente.

Nell’ultima riga invece con il comando “project TimeGenerated, Location, IPAddress, UserAgent” andate a selezionare solo determinati parametri che volete avere nel risultato, nel mio caso in sequenza: Ora/Data di generazione del log, Stato (Nazione), IP Address e User Agent.

Naturalmente questa è una KQL molto semplice per darvi evidenza della struttura di questo linguaggio, ma sono estremamente personalizzabili in base alla ricerca che dovete effettuare, proprio per questo all’inizio di questo paragrafo vi ho dato evidenza del repository github.

E se volete generare un incident e avere via mail la segnalazione ?

Microsoft Sentinel mette a disposizione la possibilità, in base alla KQL che andrete a scrivere di generare un Alert o un Incident e di conseguenza tramite una Logic App di Azure generare una mail ai destinatari che avrete scelto.

Nel mio caso, per darvi evidenza di questa possibilità, andrò a creare una KQL che mi cercherà l’evento di Login Failed, tramite Syslog di una delle mie macchine Linux.

Per procedere con questa configurazione dovrete recarvi, come per il punto precedente, all’interno del Microsoft Sentinel per eseguire la KQL che vi permette di estrapolare appunto i login Failed delle Macchine Linux, lascio per vostra comodità la query utilizzata:

Syslog

| where SyslogMessage startswith “Failed Password”

| order by EventTime desc

Come prima cosa dovrete procedere a creare un Playbook, che vi permetterà di inviare la mail tramite logic app quando verrà creato l’incident:

Figura 42: Creazione Logic App

Figura 43: Creazione Logic App

Figura 44: Creazione Logic App

Figura 45: Creazione Logic App

Figura 46: Creazione Logic App

Figura 47: Creazione Logic App

Figura 48: Creazione WorkFlows

Figura 49: Creazione Flusso

Eseguite il login all’interno del flusso con l’account che deve inviare la mail:

Figura 50: Creazione Flusso

Create ora il template della email in base ai placeholder che volete inserire nel corpo della stessa, io per esempio nell’oggetto ho voluto inserire il titolo dell’incident, nel corpo la “severity” e l’url dell’incident:

Figura 51: Creazione Email Template

Figura 52: Salvataggio Flusso

Figura 53: KQL Microsoft Sentinel

Ora date un nome alla Rule Analytics una “severità” e procedete al next step:

Figura 54: Rule Analytics

Figura 55: KQL in Rule Analytics

Figura 56: Rule Analytics

Figura 57: Automated Response

Figura 58: Automated Response

Figura 59: Automated Response

Figura 60: Automated Response

Vi lascio anche l’esempio della e-mail ricevuta quando viene generato l’incident, che contiene le informazioni che avrete selezionato:

Figura 61: Esempio Email

Conclusioni

Come avete potuto notare, questa configurazione è veramente semplice e intuitiva; in questo modo potete estendere la vita dei log presenti all’interno dei vostri sistemi, conservandoli al di fuori della vostra organizzazione e rispettando i maggiori standard di sicurezza disponibili sul mercato.

Lo scopo di Microsoft è quello di mettere a disposizione degli strumenti al reparto IT che consentano in modo semplice di configurare i servizi e questa attività ne è la prova; vero è che una volta che Microsoft Sentinel ha ricevuto i log, poi è possibile configurare della automazioni con le Logic App di Azure per inviare mail quando viene scatenato un determinato evento come avete visto in questo articolo.

L’implementazione di queste automazione è veramente semplice e permette di avere in tempo reale una notifica che potrebbe aiutarvi nell’identificare una determinata vulnerabilità o una compromissione dei vostri sistemi che magari è in atto.

Il fatto di avere delle automazioni, permette di “risparmiare” tempo e bloccare dei tentativi di accesso non autorizzati in tempo reale diminuendo il tempo di analisi e rendendo il vostro ambiente e la vostra infrastruttura ancora più sicura.