MeetUp TTG a Torino il 15 febbraio 2018

Io ed Ermanno Goletto giovedì saremo ospiti del meetup del 15 febbraio organizzato da Torino Technologies Group in cui analizzeranno in modo dettagliato i componenti di Active Directory e il loro impatto sul sistema in caso di malfunzionamento. Inoltre verranno approfondite le Best Practices e gli strumenti a disposizione nelle varie versioni di Windows Server per eseguire il troubleshooting e il disaster recovery di Active Directory.

Annunci

LastLogon, LastLogonTimeStamp, LastLogonDate. Utilizzo degli attributi per la rilevazione di oggetti “Stale” in AD PS CMD-LET Search-ADAccount

Ognuno degli attributi presenti è utile per la rilevazione di quelli che sono gli oggetti scaduti o Stale all’interno di un’infrastruttura AD.

Sono utili quindi per determinare se un utente o un computer hanno effettuato un logon al dominio e nel caso basarsi su questo valore temporale per eventualmente eliminare i vari oggetti utente o computer non più utilizzati e che possono essere fonte di brecce nella sicurezza di un’infrastruttura AD.

Gli oggetti utente e computer hanno diversi attributi che riportano informazioni relative ad eventi di logon/logoff

LastLogon

Prima della versione 2003 di Windows Server era disponibile l’attributo LastLogon per determinare il reale evento di logon di un utente o macchina.

Il valore era aggiornato solo nel Domain Controller che effettivamente validava la richiesta di accesso.

L’attributo, che è ancora presente nelle versioni successive, non è replicato, quindi per effettuare una verifica basandosi su questo è necessario effettuare una query su ogni DC del dominio e considerando il più recente come valido.

Con le successive versioni di Sistema Operativo il significato ed il meccanismo di replica di questo attributo non è stato modificato.

In buona sostanza il valore contenuto in LastLogon si può considerare come assoluto soltanto se si dispone di un dominio con un solo Domain Controller.

1 attributo LastLogon su ambiente con più di un DC ed autenticazione non avvenuta sul DC interessato dalla query

LastLognTimeStamp

Nelle versioni di Windows Server dalla 2003 in poi è disponibile un nuovo attributo che è replicato tra tutti i DC, questo riporta in modo univoco il valore temporale espresso in FILETime, ossia il numero di intervalli di 100 nanosecondi che intercorrono tra il “momento” attuale ed il 1° gennaio 1601 riferito ad UTC.

2 attributo LastLogonTimeStamp sul medesimo DC e per lo stesso evento di Logon

Troveremo quindi un valore numerico all’interno di una variabile di tipo INT64, tale valore dovrà poi essere elaborato per poter essere letto nel formato data/ora classico.

È possibile con il comando w32tm /ntte eseguire una rapida conversione del valore contenuto nell’attributo

Fatte le considerazioni precedenti, in relazione alla differenza tra i due attributi, è possibile verificare tramite l’utility Repadmin, l’effettiva replica su tutti i DC degli attributi visti prima.

repadmin /showattr * “CN=Utente Test,OU=Test,DC=dominio,DC=loc /attrs:lastLogontimeStamp”

3 replica dell’attributo lastLogonTimeStamp

Questo attributo è replicato sui vari DC e popolato con lo stesso valore

mentre il valore dell’attributo LastLogon rilevato sempre con Repadmin riporterà esclusivamente il DC che ha effettuato l’autenticazione dell’oggetto.

Questo attributo può riportare informazioni non attuali, infatti è replicato secondo il valore impostato in un ulteriore attributo

ms-DS-Logon-Time-Sync-Interval attributo espresso in giorni da 1 a
100.000

This attribute controls the granularity, in days, with which the last logon time for a user or computer, recorded in the lastLogonTimestamp attribute, is replicated to all DCs in a domain.

Di default questo non è impostato e per valore predefinito è considerato pari a 14 giorni, l’aggiornamento del dato avviene in caso di logon e se questo valore è precedente alla data/ora attuale diminuita del valore in msDS-LogonTimeSyncInterval,

La sincronizzazione iniziale dopo l’elevazione del livello funzionale del dominio è calcolata come 14 giorni diminuita di un valore percentuale casuale di 5 giorni

4 stato dell’attributo LastLogon su tutti i DC

(è da notare che l’utente scelto per questa dimostrazione è stato creato ex novo ed ha eseguito un solo accesso)

Tramite ADUC è possibile visualizzare il valore convertito di questo attributo

Per attivare la visualizzazione degli attributi è necessario attivare la funzionalità di visualizzazione avanzata all’interno di ADUC

 

 

 

 

 

 

ADUC riporta la conversione del valore numerico in formato data/ora mentre la visualizzazione diretta del contenuto evidenzia il valore numerico

LastLogonDate

Un ulteriore attributo messo a disposizione per rilevare le attività di accesso di un oggetto macchina oppure utente è LastLogonDate, che è un valore calcolato localmente in relazione alla replica dell’attributo LastLogonTimeStamp.

Viene cioè convertito in data/ora il valore numerico dell’attributo LastLogonTimeStamp localmente ad ogni server e salvato nell’attributo LastLogonDate, risulta quindi utile in quanto permette di calcolare direttamente le differenze data senza la conversione necessaria con LastLogonTimeStamp.

Ad esempio risulta più semplice rilevare con un calcolo dinamico rispetto alla data odierna gli utenti che non eseguono accesso da più di n giorni

get-aduser -filter -properties Name,LastLogonDate |
Where-Object {$_.LastLogonDate -ge (get-date).adddays(-400)}

Search-ADAccount Powershell Cmd-Let

Finora abbiamo visto come una serie di attributi ed i valori in essi contenuti ci possono aiutare per la rilevazione in AD di alcune anomalie, come ad esempio oggetti non utilizzati.

In questo contesto powershell ci ha permesso di interrogare gli attributi interessati e di rilevarne il valore per poi determinare le nostre azioni.

In modo più strutturato, in PS è disponibile un cmd-let che è in grado di rilevare agevolmente quelli che sono gli Stale-Object.

Il command-let Search-ADAccount è utile per rilevare le informazioni di scadenza, blocco etc. relative ad un oggetto che effettua attività di logon al dominio Utenti, Computer o Service Account

Esempi:

Rilevazione di oggetti computer non attivi da più di 90 giorni

Search-ADAccount -ComputersOnly -AccountInactive | ? { $_.LastLogonDate -lt (get-date).AddDays(-90) } | Select-Object Name,LastLogonDate,DistinguishedName

Rilevazione di oggetti utente non attivi per più di 90 giorni

Search-ADAccount -AccountInactive -UsersOnly | ? { $_.LastLogonDate -lt (get-date).AddDays(-90) } | Select-Object Name,SAMAccountName,LastLogonDate,Enabled,LockedOut,PasswordExpired

Riferimenti

Microsoft Virtual Academy considerazioni sugli oggetti scaduti

Attributo LasLogonTimeStamp

Attributo LastLogon

Articolo Technet

Utilizzare il Windows Certificate Store in Mozilla FireFox

La gestione dei certificati all’interno del Browser Mozilla Firefox e, in qualche modo, la sua limitazione da questo punto di vista, è nota da tempo.

Con Mozilla fino a poco tempo fa non è stato possibile utilizzare lo Store di Certificati macchina, ma soltanto quelli installati direttamente nello Store “privato” del Browser.

Come annunciato la versione 49, ha introdotto in beta questa caratteristica, che è diventata definitiva dalla versione 52.

 

As of version 52, Firefox will also search the registry locations HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates and HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates (corresponding to the API flags CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY and CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE, respectively

 

La funzionalità è utile, tra l’altro, per utilizzare apparati di controllo del traffico che effettuano anche l’ispezione dei flussi SSL, per i quali è necessario distribuire sulle postazioni un certificato Self-Signed generato sull’apparato stesso.

Tramite GPO è possibile distribuire sulle postazioni il certificato, ma mentre con IE e Chrome la funzione di inspection non generava problemi, con Firefox agi utenti veniva presentato un Warning relativo al certificato non valido.

Come detto in precedenza, in modo stabile la versione 52 di Firefox “attinge” allo store locale di macchina, tuttavia questa funzionalità non è immediatamente disponibile, ma richiede che venga abilitata tramite il parametro

security.enterprise_roots.enabled

FF-SecurityRootEnabled1

normalmente impostato a False e che è necessario quindi settare come True

 

Considerazioni ulteriori:

Se da un lato Firefox ha colmato il divario con gli altri browser permettendo l’accesso allo store di macchina, permane ancora il problema della gestione centralizzata del Browser stesso, per poter meglio comprendere come è possibile la gestione di FF in ambienti di dominio, si rimanda alla lettura di questo articolo che tratta l’argomento in relazione al progetto FrontMotion.

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