Ri-Utilizzo di Certificati Rilasciati Da Let’s Encrypt

In diverse occasioni, nella community ICTPOWER.it ci siamo occupati di Let’s Encrypt, questa breve guida ha lo scopo di evidenziare come dal client Win-Acme, almeno nella versione attuale (2.1.0), è possibile recuperare il certificato rilasciato dalla CA per un sito Web IIS ed utilizzarlo per altri servizi.

Qui di seguito una serie di articoli che ne spiegano l’utilizzo in contesti differenti

Let’s Encrypt rilascia un certificato pubblico, ne salva il formato .pfx e la relativa chiave in una cartella di appoggio in %ProgramData%\win-acme\ dove
all’interno sono disponibili anche altre informazioni, quali una cartella contenente i log dell’applicazione, un file .json con un riepilogo relativo al certificato rilasciato compreso il Thumbprint ed altre informazioni utili in caso di troubleshooting.

 

Figura 1 log file di Win-Acme

Figura 2 File Json relativo al certificato rilasciato

Se vogliamo utilizzare il certificato ottenuto da LE, lo troviamo nella sottocartella Certificates dove è salvata anche la CSR (Certificate Signing Request ) in formato .PEM

Figura 3 Contenuto della cartella Certificates

 

È da notare che il certificato avrà il nome che corrisponde ad un valore numerico che corrisponde all’ID di rilascio della CA

A questo punto, individuato il file sarà possibile utilizzarlo anche per altri servizi, che chiaramente devono corrispondere all’FQDN per il quale il certificato stesso è stato emesso, ad esempio con una serie di cmd-let Powershell potrebbe essere installato in una Farm RDS per i vari ruoli che la compongono.

Tuttavia un certificato .PFX come in questo caso è protetto da password che è necessario fornire per poterlo utilizzare. L’identificazione della password a protezione del Certificato è possibile rilanciando l’utility wacs.exe e selezionando l’opzione relativa alla visualizzazione della Schedulazione di rinnovo

Identificando poi il Binding IIS per il quale il certificato era stato richiesto

 

Completando il comando con invio vengono visualizzate tutte le informazioni relative al certificato stesso tra cui la password a protezione del PFX che è adesso possibile utilizzare in altri servizi dell’HOST

SMBv2 Guest Access Disabilitato di Default in Win10

Dalla versione 1709 di Windows 10, SMBv1 è disabilitato per default, e rimangono disponibili le versioni v2 e v3 del protocollo.

La versione v1 è nota per avere diverse vulnerabilità e questo è il motivo principale della sua dismissione

Tuttavia, sempre per ragioni di sicurezza, come spiegato in questo articolo la versione v2 di SMB ha disabilitato per default l’accesso guest, ossia senza autenticazione.

In alcuni casi, a prescindere dalle considerazioni sulla sicurezza, in termini più operativi questo comportamento può rivelarsi un ostacolo alle normali funzionalità di accesso a device che espongono tramite questo protocollo Share e servizi di rete.

Ad esempio, macchine fotocopiatrici multifunzione non legate in qualche modo a dominio od a servizi di autenticazione impediscono di fatto l’accesso alle loro aree di archiviazione dove sono salvati ad esempio il file oggetto delle scansioni effettuate.

In prima battuta un client (windows 10) che tenta di accedere ad una share di questo tipo proporrà all’utente un errore poco “parlante”

 

Figura 1 errore notificato in accesso

Che può lasciare spazio a numerose interpretazioni di ordine tecnico, se si utilizza il comando net share per la mappatura della risorsa condivisa, l’errore viene notificato in modo più preciso e circostanziato riportando il seguente messaggio

Errore di sistema 1272

Non puoi accedere a questa cartella condivisa perché i criteri di sicurezza dell’organizzazione bloccano l’accesso guest non autenticato.

Questi criteri garantiscono la protezione del PC da dispositivi non sicuri o dannosi nella rete.

 

Figura 2 errore 1272

L’evento è anche riportato all’interno del registro eventi nel ramo Applicazione e Servizi/Microsoft/Windows/SMBClient/Security dove è possibile rilevare l’Event ID 31017

 

Figura 3 Registro Eventi ID 31017

 

Il testo del messaggio riporta le seguenti Informazioni Aggiuntive:

Informazioni aggiuntive:

Questo evento indica che il server ha tentato di eseguire l’accesso dell’utente come Guest non autenticato e l’operazione è stata rifiutata dal client.

Gli accessi come Guest non supportano funzionalità di sicurezza standard come la firma e la crittografia.

Come risultato, gli accessi come Guest sono vulnerabili ad attacchi man-in-the-middle che possono esporre dati sensibili nella rete.

In Windows, gli accessi non sicuri come Guest sono disabilitati per impostazione predefinita. Microsoft sconsiglia di abilitare gli accessi non sicuri come Guest.

 

Che fornisce una più chiara descrizione del contesto di sicurezza e delle motivazioni della scelta da parte di Microcoft

 

Soluzione

A prescindere dalle considerazioni relative alla sicurezza, è possibile modificare questo comportamento tramite GPO o policy Locale

Figura 4 definizione della GPO

L’impostazione Abilita gli accessi guest non sicuri che deve essere portata in stato Abilitato è configurabile in Computer/Modelli Amministrativi/Rete/Workstation LANMAN

In generale prima di abilitare questa impostazione è bene effettuare un’attenta analisi della sicurezza all’interno dell’ambiente in cui viene attivata, infatti quando è attiva, nel registro eventi visto in precedenza è presente l’evento ID 31018

 

Figura 5 Event ID 31018

 

Che riporta in dettaglio quali chiavi di registro sono state modificate

Il valore del Registro di sistema AllowInsecureGuestAuth non è configurato con le impostazioni predefinite.

 

Valore del Registro di sistema:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]

“AllowInsecureGuestAuth”=dword:0

Valore del Registro di sistema configurato:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]

“AllowInsecureGuestAuth”=dword:1

 

E le relative informazioni Aggiuntive

 

Informazioni aggiuntive:

Questo evento indica che un amministratore ha abilitato gli accessi non sicuri come Guest. Un accesso non sicuro come Guest si verifica quando un server esegue l’accesso dell’utente come Guest non autenticato, in genere in risposta a un errore di autenticazione. Gli accessi come Guest non supportano funzionalità di sicurezza standard come la firma e la crittografia. Come risultato, consentire gli accessi come Guest rende il client vulnerabile ad attacchi man-in-the-middle che possono esporre dati sensibili nella rete. In Windows, gli accessi non sicuri come Guest sono disabilitati per impostazione predefinita. Microsoft sconsiglia di abilitare gli accessi non sicuri come Guest.

 

 

Gestione delle Sessioni RDS Disconnesse

La configurazione dell’ambiente RDS permette la gestione delle sessioni utente che risultano disconnesse.

È possibile definire un intervallo di tempo entro il quale il server Session Host termina le sessioni disconnesse, questo valore è impostato direttamente nel pannello di configurazione del servizio RDS e prevede una serie di intervalli di tempo selezionabili

Dallo stesso pannello è possibile gestire più in generale i limiti delle sessioni di connessione al di là della sessione disconnessa si può definire il comportamento sia per le sessioni attive che inattive. Una sessione è da considerarsi inattiva quando al suo interno non è presente alcuna attività

Figura 1 time out Sessione disconnessa

Il minimo intervallo di tempo impostabile per terminare una sessione disconnessa è di 1 minuto. In alcuni scenari di impiego di un sistema RDS questo valore può non essere sufficiente.

Sebbene non sia raccomandato, come riportato in questo articolo l’utilizzo di un utente comune di accesso, può essere una scelta implementativa, ed in questo caso la possibilità che in caso di disconnessione i vari utenti accedano a sessioni attive in attesa della terminazione è reale.

Intercettando sul Session Host la sessione disconnessa, è possibile intervenire tramite uno script per forzarne la chiusura, per questo scopo è possibile utilizzare i comandi

  • qwinsta
  • reset

il primo permette di rilevare lo stato delle sessioni RDP, mentre il secondo ne permette il reset sulla base dell’ID, qui di seguito è riportato uno script che avviato con una frequenza maggiore di un minuto intercetta le sessioni in stato disconnesso e ne effettua il reset

### Script per la rilevazione ed il reset di sessioni disconnesse
# Impostare il nome del server Session Host di cui effettuare il controllo delle sessioni Disconnesse
$RdsServer=”rdsh01srv.ictpower.local”
# Comando per la rilevazione delle Sessioni ed il parsing di quelle Disconnesse NON vengono rilevate quelle nelle condizioni dello Statement REGEX tra ()
$RdsSessions=(qwinsta /server:$RdsServer)| Select-String -pattern ‘^(?!.*(services|Conn|rdp-tcp)).*$’
# rilevazione dei soli valori numerici dall’array creato sopra
$IDSessions = $RdsSessions -replace “[^0-9]” ,””
# definizione del comando di reset della sessione
$ResetCmd=”reset.exe “
# definizione del LogFile
$LogFile = “C:\GestioneRds\KillSessionDiconnected\Log\$RdsServer.log”
# Creazione della Funzione di Log
Function LogWrite
{
Param ([string]$LogString)
Add-content $LogFile -value $LogString
}
# Ciclo di lettura dell’Array con il solo ID numerico delle sessioni da cancellare
foreach ($IDSession in $IDSessions)
{
# Controllo della presenza di valori numerici nella variabile ed uscita in caso di variabile non numerica
if ($IDSession -match ‘\d’ )
{
#Formazione della stringa di log
$LogEvent = (Get-Date -Uformat %d-%m-%Y” Ora “%H.%M) + ” Kill ID Sessione “+ $IDSession + ” ” + $RdsServer
Write-Output $LogEvent
# Scrittura ed esecuzione del reset della Sessione
LogWrite $LogEvent
&$ResetCmd session /Server:$RdsServer $IDSession

}
else
{

}

}

Questo script può essere richiamato tramite un ulteriore script PS che è responsabile della sua esecuzione con l’intervallo desiderato, La sola operazione pianificata non può essere utilizzata in quanto anch’essa non permette intervalli di esecuzione minori di un minuto.

#lancio PS di kill RDS session su Session HOST
for ($i=0; $i -le 4)
{
invoke-expression -Command C:\GestioneRDS\KillSessionDiconnected\ResetDisconnectedSession-rdsh01srv.ps1
sleep 10
$i++
}
}

 

SqlServer Creazione di un Linked Server Oracle ed errore 7302

 

Durante la creazione di un Linked Server Oracle all’interno di SqlServer è possibile incorrere nell’errore 7302 in fase di validazione

 

 

L’errore può presentarsi a prescindere dalla versione di SqlServer e dalla versione del Client Oracle utilizzato.

In questa condizione l’errore si presenta ancora prima della verifica delle credenziali fornite all’atto della definizione del Server Collegato.

Per poter “risolvere” l’inconveniente è necessario abilitare la proprietà AllowInprocess relativa al Provider di connessione OraOLEDB.Oracle.

Questa proprietà non è abilitata di default

 

Applicazione di GPO sulla base di appartenenza ad una Subnet (Vlan)

In Active Directory è possibile definire l’applicazione di determinate GPO sulla base dell’appartenenza a Siti differenti, tuttavia nel caso in cui in un sito siano presenti più subnet e sia necessaria l’applicazione di una GPO ad una sola di queste è necessario ricorrere ad un filtro WMI che permetta di applicare la Group Policy in modo puntuale.

Partendo dalla tabella di routing di una postazione è possibile identificare la rete in cui il sistema operativo è collocato, il comando che visualizza la tabella è route print

 

Figura 1 visualizzazione tabella di routing

Il sistema è configurato per un indirizzo ip 10.69.143.187 ed una subnet 255.255.255.248 e gli indirizzi di subnet e broadcast sono rispettivamente 10.69.143.184 e 10.69.143.191

Le informazioni contenute nella tabella sono leggibili anche tramite una semplice query WMI

select * from Win32_IP4RouteTable Where Destination =’10.69.143.184′ and Mask=’255.255.255.248′

con il comando WBEMTEST è possibile verificare la correttezza sintattica della query ed il risultato ottenuto

 

Figura 2 output Wbemtest

 

A questo punto essendo certi che la query è corretta possiamo creare un filtro WMI da applicare poi alle GPO che devono essere attive per la porzione di rete in cui ci troviamo.

La GPO verrà applicata in caso di un confronto positivo del filtro basato sulla query

 

Figura 3struttura del filtro WMI

 

Figura 4 GPO con filtro Wmi applicato

 

Riferimenti:

https://docs.microsoft.com/it-it/windows/security/threat-protection/windows-firewall/create-wmi-filters-for-the-gpo

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wmiiprouteprov/win32-ip4routetable

 

 

 

 

 

 

Identificare la tipologia di Sistema Operativo tramite WMI

 

Nell’applicazione delle Group Policy, piuttosto che in ambiti differenti, può essere necessario applicare determinate impostazioni, o rilevare in modo puntuale la tipologia di Sistema Operativo.

Tramite un apposito filtro applicato all’ambiente WMI è possibile rilevare se il sistema è un Client, un server e se si tratta di un server, se questo è un Domain Controller oppure un sistema Server comune

Il valore da identificare è la Proprietà Product_Type relativa alla classe Win32_OperatingSystem il cui contenuto è un valore di tipo uint32

La proprietà può contenere i seguenti valori

  • 1 Work Station
  • 2 Domain Controller
  • 3 Server

Una semplice query può essere strutturata in questo modo

select ProductType from Win32_OperatingSystem

e può essere eseguita con il tool WbemTest

Figura 1 risultato della query su un DC

Ed è inoltre possibile rilevare lo stesso valore tramite il comando VMIC

wmic os get ProductType /value

 

Figura 2 valore rilevato con WMIC

 

 

Definizione di un Filtro WMI da applicare ad una GPO

Avendo presente la struttura WMI interrogabile con i due tool riportati sopra è possibile costruire una query che verrà applicata ad una GPO, in modo che questa venga applicata esclusivamente in caso di un confronto positivo con la query effettuata

select * from Win32_OperatingSystem where ProductType=”1″

la query sopra su un filtro WMI applicato ad una GPO permette l’applicazione della stessa solo in caso di un sistema operativo di tipo “Client”

 

Figura 3

Figura 4 creazione del filtro e relativa query

 

 

Riferimenti

https://docs.microsoft.com/en-us/windows/desktop/CIMWin32Prov/win32-operatingsystem

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc947846(v=ws.10)

https://blogs.technet.microsoft.com/askperf/2012/02/17/useful-wmic-queries/

 

 

GESTIONE DELLE REGOLE DI CONSERVAZIONE DEI DATI SU AZURE LOG ANALITYCS

 

Azure Log Analitycs è la soluzione di gestione dei vari log collezionati localmente o sulle infrastrutture in cloud, che matte a disposizione dell’utilizzatore un motore di analisi e di ispezione dei log stessi molto potente.

All’atto della sua attivazione viene configurata con un piano di tariffazione per GB di dati inviati dai collector, all’atto dell’attivazione di soluzioni di analisi avanzate, quali ad esempio la Soluzione di Security and Audit, la tariffazione avviene per nodo.

Da notare che i primi 60 giorni sono gratuiti.

Al di la della soluzione adottata è possibile comunque variare il periodo di conservazione dei dati archiviati che di default è di 31 giorni, anche la conservazione dei dati di log ha una sua tariffazione che è basata sulla quantità di dati inviati, secondo lo schema qui sotto.

 

Figura 1 tariffazione mensile Azure Log Analitycs

I primi 5 Gb mensili sono gratuiti così come la conservazione base di 31 giorni, solamente gli sforamenti in termine di periodo di conservazione e spazio occupato avranno un costo che varia, in misura minima, a seconda delle region di allocazione del servizio.

 

Per poter modficare il periodo di conservazione dei dati, così come la quantità giornaliera archiviata, è sufficiente collegarsi al portale di Azure https://portal.azure.com, accedere alla soluzione di monitoring selezionare la funzione relativa a “Utilizzo e Costi Stimati”

Figura 2 visualizzazione dei consumi e costi attuali

 

e da questa pagina accedere alle impostazioni di “Gestione del Volume dei Dati” e selezionare le impostazioni volute.

Si possono mantenere i dati in linea per un periodo massimo di due anni, ed è possibile anche impostare un limite di upload giornaliero

 

Figura 3 impostazione dei limiti di archiviazione

È possibile anche impostare un’ora del giorno a cui vengono applicati i limiti di archiviazione in termini utilizzo di dati

Riferimenti

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