Azure Log Analitycs Gestione dei campi Custom per ricerca e indicizzazione delle informazioni

 

Nei post precedenti relativi alla configurazione del servizio agent di OMS su Linux, ho avuto modo di illustrare come è possibile attivare le notifiche di Sicurezza relative ad Oracle verso Operations Management sul Cloud e come da Log Analitycs è possibile effettuarne la ricerca.

Di default vengono indicizzate le varie informazioni all’interno del messaggio Syslog generato dal sistema, mentre il testo vero e proprio del messaggio, quello generato dalla funzione audit del DB utilizzando la facilty local0 (nell’esempio), viene archiviato nella sua completezza.

in questo modo non è possibile effettuare una ricerca utilizzando come chiavi valori archiviati nel messaggio stesso.

All’interno di Log Analitycs è presente la possibilità di “costruire” filtri personalizzati andando ad indicizzare specifiche parti del messaggio Syslog in modo che queste possano poi essere usate come chiavi di ricerca.

In questo esempio si è fatto cenno ad un messaggio Syslog, in quanto per le esigenze specifiche si è utilizzata questa sorgente, ma la modalità operativa di indicizzazione dei messaggi è valida per qualunque “oggetto” all’interno di Log Analitycs.

L’indicizzazione di una parte del messaggio in archivio è attivabile selezionando

Immediatamente prima dell’inizio del messaggio vero e proprio, a questo punto come si vede nell’immagine sotto, viene evidenziato il testo, e la possibilità di estrarre i campi dal messaggio tramite “Extract Fileds from Syslog” dove Syslog è il nome del campo.

 

 

Selezionando questa opzione viene espanso ulteriormente il messaggio consentendo la manipolazione, o meglio la selezione di parte del contenuto, questa selezione, sarà poi ciò che verrà individuato ed “indicizzato” in ogni nuovo messaggio in arrivo.

 

È da tenere presente che l’operazione descritta sarà attiva solo per i nuovi messaggi, tutto quanto già immagazzinato non è interessato dalla nuova indicizzazione.

 

A questo punto si apre un ulteriore menù in cui è richiesto di specificare il nome del campo che sarà visualizzato nei report e la tipologia di dato, confermando con Extract, verrà presentata una Preview della selezione e la possibilità di salvarne l’impostazione.

 

L’elenco dei vari campi personalizzati che sono stati definiti è rilevabile nella console di OMS nella pagina delle impostazioni

Da qui è possibile la visualizzazione di tutti i campi Custom e la loro eventuale rimozione, selezionando Go To si ha disposizione una scorciatoia per l’attivazione rapida del filtro.

 

Da questo momento i dati in ingresso, sono indicizzati anche secondo questo criterio, ed il campo può essere interrogato direttamente dalla composizione della query di Log Analitycs

Lo strumento di reportistica a disposizione in Azure è sicuramente molto potente e può agevolmente sostituire costosi sistemi di archiviazione e gestione dei log la cui installazione finora è stata necessariamente on-prem.

 

Riferimenti:

https://azure.microsoft.com/it-it/services/log-analytics/

https://docs.microsoft.com/it-it/azure/log-analytics/log-analytics-overview

 

Gestione avanzata della Security tramite SDDL

Che cosa è SDDL

Un linguaggio destinato a permettere lo scambio di descrittori di sicurezza tra sistemi differenti (Windows) senza necessariamente avere un contesto identico tra i sistemi stessi.

SDDL permette quindi di strutturare una stringa testuale che può essere utilizzata da alcune funzioni al fine di definire un Security Descriptor, ossia una serie di informazioni di sicurezza che possono essere applicate ai vari oggetti di sistema.

Lettura del Log Eventi

In alcuni casi, ad esempio se si raccolgono centralmente gli eventi generati sui vari sistemi, può essere necessario consentire l’accesso ai registri sulle postazioni a determinati utenti o servizi, in questo caso è tramite il gruppo locale “Event Log Readers” è possibile fare si che un determinato account abbia accesso alla lettura dei vari registri.

Tuttavia può essere necessario permettere un accesso più granulare, l’appartenenza al gruppo consente l’accesso generalizzato a TUTTI i registri.

Per poter discriminare maggiormente chi può leggere e da quale registro è necessario utilizzare SDDL, (Structured Descriptor Definition Language)

Gestione della security tramite SDDL nei registri eventi

Ogni oggetto all’interno del sistema operativo deve sottostare a criteri di accesso definita dalle ACL, in questo senso non fanno eccezione i vari registri eventi per i quali come detto in precedenza il solo gruppo “Event Log Readers” può non essere sufficiente a “modellare” la security secondo le esigenze.

Vedremo più aventi come l’utility icacls è in grado di esportare ed impostare le varie ACL su file system a partire da stringhe in formato SDDL, l’utility analoga per il registro eventi è il tool wevtutil che permette una gestione completa del sistema di archiviazione eventi di Windows

Il comando wevtutil gl security ad esempio rileva le informazioni relative al log di sicurezza compresi i permessi di accesso al channel tramite il quale il registro è utilizzato sia in lettura che in scrittura.

Nell’esempio riportato sopra, vediamo un’impostazione di default su Windows 10 e possiamo notare che l’ultima parte della stringa SDDL riporta anche un SID che è quello del gruppo locale di “Event Log Readers” questo gruppo ed il suo Secure Identifier è documentato come Well-Known SID qui.

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

Con la scrittura di una stringa SDDL possiamo estendere o modificare i permessi di accesso ai singoli registri eventi applicandola poi al sistema.

Ad esempio se volessimo permettere ad un determinato utente l’accesso solo al registro security, dovremo dapprima recuperarne il SID e con questo comporre la stringa da impostare

wevtutil sl security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-21-3744379440-2296965582-3114473425-1003)

il comando sopra imposta il contesto di sicurezza del channel relativo al registro di Security per l’utente il cui sid è stato rilevato tramite il comando whoami /all

vediamo ora come, tramite SDDL possiamo impostare le varie Access Control Entries (ACE) sugli oggetti, ogni parentesi è assimilabile ad un blocco che definisce un preciso accesso ad un utente/gruppo dichiarato con il proprio SID.

Con l’esempio precedente abbiamo permesso all’utente l’accesso in LETTURA al registro SECURITY

Analisi di una stringa SDDL


La struttura della stringa è composta di alcune parti Owner, Gruppo e DACL (Discretionary Access Control List)

Quest’ultima è poi strutturata e strutturabile in diverse parti, tutte racchiuse tra parentesi, che contengono i permessi veri e propri per le varie entità, ognuna di queste parti prende il nome di ACE (Access Control Entry)

O:BAG:SYD: – la prima parte dichiara che l’Owner (O) è BA ossia il Built-In Administrator Account

O:BAG:SYD: – la seconda parte dichiara che il gruppo (G) è SY, identificato come LOCAL SYSTEM.

O:BAG:SYD: – la terza parte identificata con (D) formalmente dichiara l’inizio della DACL.

Composizione di una DACL

L’insieme di tutte le ACE prendono il nome di DACL, di default le prime due ACE sono relative al Local System (SY) e Built-in-Administrator (BA) entrambe riportano il permesso di accesso (A) con Read e Write consentiti da 0x5 e 0xf0005.

Struttura di una ACE

Analizzando la ACE relativa al SID S-1-5-32-573, che è l’identificativo del gruppo Event Log Readers, vediamo che è strutturata con A;;0x1;;;<SID>

La prima lettera A indica (A)llow ed il secondo gruppo indica i tipi di permesso di accesso secondo la tabella riportata qui sotto, nel nostro caso esclusivamente il permesso di lettura.

0x1=Read
0x2=Write
0x3=Read/Write
0x4 = Delete

Il messaggio che si otterrà nel caso si tenti di cancellare il registro con il solo permesso di Read è il seguente

È consigliabile prestare attenzione al privilegio minimo per cui si intende consentire l’accesso al registro, se per ipotesi volessimo permettere la sola cancellazione degli eventi, senza consentirne la visualizzazione, il minimo permesso dovrebbe essere 0x4 ossia Delete, in questo caso lo snap in di visualizzazione riporterebbe il seguente errore.

Anche per la sola cancellazione è necessario attribuire il permesso di Read, che risulterà in una ACE di questo tipo

(A;;0x5;;;S-1-5-21-3744379440-2296965582-3114473425-1003)

Dove 0x5 è appunto l’accesso in read + delete

Utilizzo di SDDL per la gestione delle ACL su Filesystem

L’utilizzo delle stringhe SDDL può anche essere utilizzato per rilevare ed eventualmente impostare la security sugli oggetti di un Filesystem. Tramite l’utility icacls una ACL relativa ad un file o ad una determinata cartella può essere “esportata” o per meglio dire tradotta in una stringa SDDL

Vediamo come:

Qui sopra è visualizzata una ACL dichiarata su una cartella contenente un file

Con il comando Icacls, possiamo visualizzarne la security

Icacls c:\SddlAcl

Viene riportata in modo analogo alla visualizzazione precedente la M (modifica) presente nella ACL

A questo punto sempre con Icacls è possibile esportare la security dell’intera struttura, operazione che eseguita poi in restore consentirà di reimpostare i permessi sull’intero albero di cartelle

icacls c:\SddlAcl /save c:\Temp\NtfsAcl.txt /t /c

Questo comando esporta la security di un oggetto salvandola in un file /T esporta i permessi delle sottocartelle /C continua in caso di errori

Questo è il risultato dell’esportazione, ossia una stringa in formato SDDL che può essere quindi facilmente interpretata e manipolata, ad esempio per ripristinare la security.

Eseguendo il comando

icacls c:\ /restore c:\Temp\NtfsAcl.txt

verrà ripristinata la security sull’intera struttura di file e cartelle.

Riferimenti

https://blogs.technet.microsoft.com/askds/2008/04/18/the-security-descriptor-definition-language-of-love-part-1/

https://blogs.technet.microsoft.com/askds/2008/05/07/the-security-descriptor-definition-language-of-love-part-2/

https://support.microsoft.com/en-us/help/323076/how-to-set-event-log-security-locally-or-by-using-group-policy

Utilizzare Certutil.exe per la verifica delle Revocation List

Certutil è uno strumento di gestione e manipolazione di certificati digitali

È utilizzato per la gestione dello store di certificati, ma può anche fornire indicazioni relativamente ad un certificato salvato in un file.

Ad esempio se vogliamo avere indicazioni complete sul certificato attualmente utilizzato da Google dobbiamo dapprima recuperarlo, aprendo la pagina del motore di ricerca, e poi  salvarlo in un file localmente al PC.

Selezioniamo il Lucchetto nella barra (1) e successivamente facendo click su “Visualizza Certificati” (2)

iexplorer1

In questo modo compaiono le informazioni relative al certificato utilizzato dal browser, è sufficiente salvarlo su un file in formato “Binario Codificato DER X509  (.CER) ”.

iexplorer2

Posizionandosi prima sul TAB Dettagli

Ora possiamo verificare con Certutil.exe il certificato salvato

  • certutil -f –urlfetch -verify C:\Temp\google.cer >GoogleCertResult.txt

 

Anche tramite la videata grafica qui sopra, è possibile visualizzarne le informazioni, ma in questo modo è possibile salvarle in un file di testo, semplificandone la consultazione delle varie proprietà.

All’interno del file, possiamo individuare le modalità di verifica dell’eventuale revoca del certificato.

In questo caso evidenziamo le due modalità

  • CRL ( Certificate Revocation List)
  • OCSP (Online Certificate Status Protocol)

Rispetto alle CRL, OCSP è più performante trasmettendo ad ogni richiesta di verifica meno dati della CRL.

Si rimanda ai link riportati sotto per approfondimenti ulteriori.

revocation1

Utilizzando ancora certutil.exe è possibile effettuare una verifica sulla revoca (eventuale) del certificato salvato.

certutil1

Prima di effettuare la verifica è necessario tramite “Seleziona” recuperare il file di certificato salvato prima ed individuare il metodo di verifica coerente con l’URL scelto.

Questa procedura è utile anche in caso di diagnostica di CA Aziendali “private” ad esempio per individuare problemi dovuti alla non corretta dichiarazione dell’URL della revocation list a seguito di migrazioni che prevedono la modifica del nome host.

Riferimenti:

https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol

https://en.wikipedia.org/wiki/Certificate_revocation_list

https://en.wikipedia.org/wiki/X.509

Gestione degli utenti sincronizzati con Azure Active Directory Connect

Può succedere che a seguito di sincronizzazioni incomplete o di indisponibilità del dominio on-premise, piuttosto che per comportamenti anomali di un qualche componente coinvolto, rimangano all’interno della directory in Azure oggetti senza riferimento sull’AD principale.

Normalmente la gestione della Azure Active Directory avviene completamente dal dominio on-premise, gestendo gli utenti come si fa normalmente.

Le varie operazioni di Cancellazione ridenominazioni assegnazioni a gruppi etc. vengono fatte on-prem e replicate poi nel cloud, tuttavia se, come può accadere, rimangono oggetti in Azure AD senza una corrispondenza sul dominio locale è necessario operare con Powershell per la loro rimozione.

Anche perché sul portale non è possibile agire in rimozione per questa tipologia di utenti

azure-ad-sync-userportal

Per prima cosa è necessario impostare l’ambiente PS in modo che abbia i moduli e le cmd-let necessarie alla connessione e gestione di Azure AD.

Questa pagina https://technet.microsoft.com/library/jj151815.aspx riporta le indicazioni necessarie alla configurazione dell’ambiente PowerShell per la connessione verso Azure.

Una volta correttamente importati e configurati i moduli PowerShell con il comando:

$msolcred = get-credential

connect-msolservice -credential $msolcred

ci si connette con le credenziali di un utente “Amministratore Globale” alla Directory di cui si vuole effettuare la gestione, a questo punto per identificare gli utenti presenti sulla Directory è utilizzabile il  cmd-let

  • Get-MsolUser

azure-ad-sync-get-msoluser

Mentre per la cancellazione dell’utente rimasto “orfano” è possibile usare il cmd-let

azure-ad-sync-remove-msoluser

Relativamente agli oggetti cancellati è bene sapere che è possibile “recuperarli” in quanto vengono, posti in un “cestino” per un periodo di 30 giorni.

In questo caso il cmd-let da usare è

 

Altra possibilità è quella di verificare l’elenco degli utenti “eliminati” ed ancora in cestino per ottenere l’elenco degli utenti cancellati si utilizza il comando

  • Get-MsolUser -ReturnDeletedUser

 

È anche possibile ottenere informazioni dettagliate sull’utente rimosso come ad esempio la data di cancellazione ed altro

  • Get-MsolUser -ReturnDeletedUser -UserPrincipalName utente02@<dom>.onmicrosoft.com | fl

 

azure-ad-sync-get-msoluser-returndeleteduser

 

Riferimenti:

Azure Active Directory

https://docs.microsoft.com/it-it/azure/active-directory/active-directory-whatis

Azure Active Directory Connect

https://docs.microsoft.com/it-it/azure/active-directory/active-directory-aadconnect

 

 

Connessione ad Azure Active Directory tramite proxy

Azure Active Directory è un servizio disponibile in Cloud che consente, tra i le altre opzioni,  anche la possibilità di sincronizzare oggetti di un dominio OnPremise verso il cloud stesso in modo da avere, se necessario, una corrispondenza con gli utenti on prem anche in Azure.

Al di là di quelle che sono le funzionalità disponibili , quando gli utenti sono replicati in cloud, ad esempio è possibile attivare le funzionalità di cambio password in modalità Self-Service per i vari uenti.

E’ possibile configurare Azure AD Connect per utilizzare  un proxy per le funzioni di “replica”.

Questa caratteristica è molto utile in quanto permette di sincronizzare la propria infrastruttura AD locale verso il cloud senza dover mettere mano ad impostazioni particolari sui firewall eventualmente attivi, sfruttando semplicemente la presenza di un proxy già presente in Azienda.

La configurazione è molto semplice, è sufficiente individuare ed aprire il file machine.config presente in

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config

ed aggiungere al fondo, prima del tag di chiusura della configurazione, alcune  righe come riportato sotto

 

               

                                <proxy

                                usesystemdefault=”true”

                                proxyaddress=”http://10.102.162.6:80&#8243;

                                bypassonlocal=”true”

                                />

               

 

il file in formato XML dovrà terminare con il tag di chiusura della configurazione

    

A questo punto se le impostazioni sono corrette per verificare se la configurazione funziona correttamente è sufficiente da PS richiamare

Invoke-WebRequest -Uri https://adminwebservice.microsoftonline.com/ProvisioningService.svc

 azure-ad-sync-ps-verification

Se il cmd-let restituisce Satus Code 200 allora la comunicazione avviene ed servizio di sincronizzazione può operare.

Nel caso in cui il test tramite il commandlet visto sopra non dovesse funzionare è possibile a questo link ottenere informazioni sui più comuni messaggi di errore dell’ambiente AD Connector

Problemi Riscontrati

E’ necessario fare attenzione alla versione di client AADConnect che si sta installando, in quanto se si utilizza la 1.1.370.0, soprattutto con connessioni via proxy, e non è aperta la porta TCP/9090 l’installazione fallisce con questo errore.

azure-ad-sync-error-proxy-connection

Il problema è stato risolto con la versione 1.1.371.0 come riportato in questo post: Azure AD Connect: Version Release History

Link alla pagina di download del client AADConnect

Ricostruzione delle zone DNS relative ad Active Directory

Per le cause più disparate può accadere che all’interno del DNS vi siano una o più zone non funzionanti o con errori.

Dal punto di vista della struttura DNS di un Domain Controller possiamo notare che di default vengono create due zone, ad esempio per il dominio test.local, dove questo è anche il Root Domain della foresta troveremo:

  • _msdcs.test.local
  • test.local

entrambe zone primarie ed integrate in AD

La prima zona è quella “di foresta” ossia la zona che viene creata con la promozione del primo DC che è anche il Root Domain Controller, mentre la seconda zona è quella relativa al dominio vero e proprio, che in questo caso essendo il primo dominio installato nella foresta prende anche il nome di Root Forest Domain.

 

dnsadreconstruction1

Come si può vedere nell’immagine il DNS contiene anche una seria di informazioni relative ad altri host connessi in rete, il DNS è quindi, come di solito avviene, utilizzato per il normale funzionamento dell’infrastuttura.

Nell’ambiente di test realizzato, per simulare un malfunzionamento, sono state rimosse le varie impostazioni relative alla zona di dominio test.local ed è stata anche rimossa la zona _msdcs.test.local relativa alla Foresta.

A questo punto il comando dcdiag /test:dns riportava diversi errori

                     Error:                     Missing SRV record at DNS server 192.168.1.30:      _kerberos._tcp.dc._msdcs.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:       _ldap._tcp.dc._msdcs.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:       _ldap._tcp.Default-First-Site-Name._sites.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:       _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:         _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:         _kerberos._tcp.Default-First-Site-Name._sites.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:            _ldap._tcp.gc._msdcs.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:               _gc._tcp.Default-First-Site-Name._sites.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:        _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.test.local
                     Error:     Missing SRV record at DNS server 192.168.1.30:  _ldap._tcp.pdc._msdcs.test.local
               Error: Record registrations cannot be found for all the network
                                                  Auth Basc Forw Del  Dyn  RReg Ext
           _________________________________________________________________
            Domain: test.local
               srvdc03                      PASS FAIL PASS PASS PASS FAIL n/a
         ……………………. test.local failed test DNS

Per ricreare automaticamente le zone non funzionanti è sufficiente riavviare il servizio Netlogon

Tuttavia se questo non avviene, o se le zone sono state rimosse completamente è necessario, prima ricrearle manualmente e solo successivamente effettuare un restart del servizio ( ricrearle nel senso di definire le due zone con il nome come visto sopra ed integrate in AD) la “popolazione” vera e propria delle zone verrà fatta da Netlogon 

dnsadreconstruction4

dnsadreconstruction5

 

A questo punto dopo che  Netlogon è riavviato vedremo le Zone completamente popolate.

Recupero dei dati contenuti all’interno di una zona DNS

Come visto in precedenza il DNS è utilizzato anche per le normali funzioni di rete e quindi la cancellazione della zona test.loc prima della sua rigenerazione potrebbe essere causa di malfunzionamenti, in questo caso è possibile PRIMA di eliminare la zona dal DNS effettuare un salvataggio del suo contenuto.

Per “esportare” i dati contenuti è sufficiente definire  la zona stessa come standard rimuovendo il flag che la imposta come integrata in AD

dnsadreconstruction2

Una volta rimosso il flag e salvate le impostazioni in %SystemRoot%\System32\DNS\ copiare il file relativo alla zona, al suo interno, in formato testo è presente l’intera struttura che prima era integrata in AD.

All’inizio del file troveremo alcune informazioni relative alle impostazioni TTL, SOA Seriale etc. questa parte del file potremo tranquillamente eliminarla, manterremo soltanto il contenuto vero e proprio relativo ai vari record A che definiscono le vere informazioni ancora mancanti nel DNS

Automazione dell’import dei Record tramite PoweShell

Una procedura automatizzata è possibile tramite PowerShell, per mezzo di questo ambiente con poche righe di istruzioni è possibile importare il contenuto del file testo.

Il commandlet Add-DnsServerResourceRecordA può essere utilizzato per questa operazione mentre con il commadlet Get-Content viene letto il contenuto del file di testo

 

$DnsRecord = Get-Content C:\temp\test.local.dns

foreach ($line in $DnsRecord)

{

 

$DnsHost = $line.Split()|where {$_}

Add-DnsServerResourceRecordA -Name $DnsHost[0] -IPv4Address $DnsHost[2] -ZoneName test.local

}

 

Se dovessero essere presenti record differenti rispetto al tipo “A” occorre modificare di conseguenza lo script in PS