• Cloud, Guide, Sicurezza
• 11 Novembre 2026

Microsoft Sentinel è una soluzione di Security Information and Event Management (SIEM) e Security Orchestration, Automation, and Response (SOAR) basata su Cloud Microsoft.

A tal proposito vi riporto l’articolo di Nicola Ferrini, dove parla, attraverso una guida, all’introduzione di Microsoft Sentinel Introduzione a Microsoft Sentinel – ICT Power.

Vi riporto inoltre la categoria legata a questo workload Microsoft della community dove potete trovare tutte le guide inerenti a questa soluzione Microsoft Sentinel – ICT Power

Ho parlato inoltre in diversi articoli di come poter eseguire Ingestion dei log dai dispositivi per poi creare tutte le regole che permettono poi di generare gli allarmi che verranno analizzati dagli analisti SOC, vi riporto l’articolo più “vicino” a quello di cui vorrei parlarvi oggi Eseguire il Parsing degli Audit Log di Libra Esva in Microsoft Sentinel – ICT Power così da darvi l’opportunità di entrare meglio all’interno del discorso.

Nelle ultime settimane, mi sono imbattuto in alcune macchine Linux, che venivano “sfruttate” come Server VPN attraverso OpenVPN e vorrei rendervi partecipi di come poter collezionare i log di questo sistema per poi procedere alla creazione delle regole per generare appunto degli incident per attività considerate non lecite.

Effettuare Log Collection di un software VPN riveste un’importanza fondamentale nella gestione della sicurezza aziendale. Attraverso l’infrastruttura VPN transitano infatti dati sensibili: le informazioni degli utenti che si connettono, gli indirizzi IP pubblici di origine delle connessioni e, più in generale, l’intero traffico che collega gli utenti remoti alla rete interna.

La criticità è evidente: qualora un malintenzionato riuscisse a compromettere una connessione VPN, otterrebbe un canale di accesso privilegiato all’infrastruttura aziendale, con la possibilità di muoversi lateralmente all’interno della rete e comprometterne le risorse.

Nel presente articolo illustrerò volutamente uno scenario “worst case”, ovvero una configurazione priva di misure di protezione avanzate, è bene precisare che, in un contesto di produzione, per una connessione VPN si raccomanda l’adozione di best practice di sicurezza consolidate, a partire dall’implementazione dell’autenticazione a più fattori (MFA), affiancata da ulteriori standard e controlli di sicurezza.

Quale è quindi lo scenario a cui di troviamo davanti?

Come primo punto abbiamo una macchina Ubuntu 24.04 in cui è installato OpenVPN Server in Hosting presso Microsoft Azure

Figura 1: Virtual Machine Ubuntu 24.04 che ospita OpenVPN Server

Figura 2: OpenVPN server installato sulla macchina Ubuntu

Ora procederemo a creare la DCR (Data Collection Rule) per permettere a Microsoft Sentinel di ricevere i logs dalla macchina in cui è presente OpenVPN, rechiamoci quindi all’interno del portale di Microsoft Defender, resta sottinteso che dovrà essere installato il connettore Syslog per Microsoft Sentinel e avere un’istanza sentinel attiva

Figura 3: Configurazione SysLog Connector per log Ingestion da macchina Linux

Figura 4: Procediamo a creare una Data Collection Rule

Figura 5: Scegliete un nome parlante per la DCR la Subscription ed il resource group in cui inserirla

Figura 6: Selezioniamo la macchina Linux in cui è presente OpenVPN Server

Figura 7: Selezionato LOG_DAEMON con LOG_INFO e proseguite con la configurazione

Ora sarà necessario attendere del tempo, nel mio caso all’incirca una mezz’oretta, prima che la Data Collection Rule installi Azure Monitoring Agent, per vederlo basta semplicemente recarsi all’interno della macchina Virtuale:

Figura 8: Estensione AMA correttamente installata all’interno della macchina Virtuale

Per verificare che ci sia traffico di Logs è possibile verificarlo mediante una KQL (Kusto Query)

Figura 9: Eventi Syslog che arrivano correttamente in Microsoft Sentinel

Per evitare di creare “rumore” all’interno dei log vi consiglio di inserire un filtro all’interno della DCR

Figura 10: Creiamo una “trasformazione” all’interno della DCR creata in precedenza

Figura 11: In questo modo inseriamo una KQL che “recepisce” solo i Syslog provenienti da OpenVPN e non tutti i “demoni” della Virtual Machine

Figura 12: Inseriamo Add processors e configuriamo un filtro basic con “Ident contains openvpn” e poi click su Save

Per eseguire un test che tutto funzioni nel modo corretto eseguiamo la seguente KQL “Syslog | where ProcessName has “openvpn” | take 10″

Figura 13: La trasformation funziona nel modo corretto

Ora possiamo procedere a creare una Analytics Rule per generare degli eventi, nel mio caso, per semplicità, genererò un incident ogni volta che l’IP di collegamento alla VPN proviene dall’Italia

Prima di procedere alla creazione della Analytics Rule, vorrei darvi evidenza della KQL, spiegandovi l’utilità della stessa

Ecco nel dettaglio la spiegazione di tutti i comandi

Syslog

Parte dalla tabella Syslog, dove finiscono i log dei sistemi Linux/Unix inviati a Sentinel

| where ProcessName has “openvpn”

Tiene solo i log generati dal processo openvpn, scartando tutto il resto (SSH, cron, ecc.)

| where SyslogMessage has “Peer Connection Initiated”

Filtra i messaggi che segnalano una nuova connessione client avviata. È il momento in cui qualcuno si sta collegando alla VPN

| extend ClientIP = extract(…)

Usa una espressione regolare per pescare l’indirizzo IP (formato 1.2.3.4:porta) dal testo del messaggio e lo mette in una nuova colonna ClientIP, prende solo la parte IP, non la porta

| extend CommonName = extract(@”\[(.*?)\]”, 1, SyslogMessage)

Estrae ciò che sta tra parentesi quadre […] nel messaggio. In OpenVPN lì c’è di solito il Common Name del certificato, cioè l’identità dell’utente/client che si connette

| where isnotempty(ClientIP)

Scarta le righe dove l’IP non è stato trovato (rete di sicurezza contro estrazioni fallite)

| where not(ipv4_is_private(ClientIP))

Tiene solo gli IP pubblici, eliminando quelli privati (10.x, 192.168.x, ecc.). Interessano le connessioni da Internet

| extend GeoInfo = geo_info_from_ip_address(ClientIP)

Funzione integrata che fa la geolocalizzazione dell’IP e restituisce un oggetto con paese, città, coordinate ecc.

| extend Country = …, City = …

Estrae da quell’oggetto i due campi che servono, paese e città, convertendoli in testo

| where Country == “Italy”

Il vero filtro dell’indagine: solo connessioni geolocalizzate in Italia

| project TimeGenerated, HostName, CommonName, ClientIP, Country, City

Mostra alla fine solo le colonne utili: quando, quale server, quale identità, da quale IP, e da dove

Figura 14: Procediamo alla creazione di una Scheduled Query Rule

Figura 15: Forniamo in nome parlante ed una descrizione alla regola e inseriamo come tattica “Initial Access”

Figura 16: Inseriamo la KQL che abbiamo visto in precedenza

Figura 17: Configurazione Entity Mapping

Figura 18: Configurazione di Query Scheduling e Alert Threshold

Figura 19: Configurazione Incident Settings

Figura 20: Nel mio caso ho una regola di Automazione che mi invia una mail con i dettagli dell’Incident

Ora una volta creata ed effettuate delle connessioni VPN con IP sorgente italiano verrà generato un Incident

Figura 21: IP di Collegamento sorgente che è italiano

Figura 22: Collegamento VPN effettuato

Figura 23: Mail che mi avvisa della creazione dell’Incident

Figura 24: Incident presente in console XDR

Possiamo modificare la KQL per generare Incident quando il collegamento avviene fuori dall’ Italia?

Certamente, è un’operazione molto semplice, in quanto all’interno della Kusto Query che abbiamo visto in precedenza basta cambiare il seguente filtro:

da così | where Country == “Italy”

a così | where Country != “Italy”

C’è però qualcosa di cui vi devo avvertire, quando l’operatore “geo_info_from_ip_address()”, non riesce ad identificare l’indirizzo IP potrebbe restituire un valore null o vuoto e quindi l’operatore !=”Italy” lo identificherebbe come IP non appartenente alla country Italia, cosa che comunque succederebbe anche quando l’operatore è ==”Italy”.

Conclusioni

Avere a disposizione strumenti di questo potenziale per creare regole Custom, e avere la possibilità di eseguire Trasformation eseguendo ingestion mirata di solo quello che ci serve a mio avviso è fondamentale per risparmiare sui costi del mondo cloud e per avere detection sempre più precise.

Inoltre, monitorare attraverso un SIEM le connessioni VPN al giorno d’oggi è fondamentale, compromettere un’utenza VPN potrebbe voler dire spalancare le porte della vostra organizzazione ad un attaccante che poterebbe eseguire lateral movement e compromettere Asset Aziendali Critici, elevare gli standard di sicurezza e avere un sistema proattivo di Detection e Response al giorno d’oggi è un must per le organizzazioni.