Audit TLS Debole LDAPS, Spooler Stampa, Sincronizzazione Oraria del Domain Controller: Checklist di Igiene di Rete

Questo è un audit di TLS debole su LDAPS, Spooler di Stampa e sincronizzazione oraria del domain controller: una checklist pratica per tre impostazioni di rete che le revisioni di Active Directory costruite attorno ad ACL e nesting dei gruppi tendono a saltare. Ognuna si verifica rapidamente, e ognuna compromette silenziosamente una garanzia di sicurezza diversa non appena un domain controller si allontana dalla propria baseline.

Audit TLS Debole su LDAPS, Spooler di Stampa, Sincronizzazione Oraria del Domain Controller

La maggior parte delle revisioni di hardening di Active Directory insegue ACL, nesting dei gruppi e percorsi di delega — tralasciando la superficie di rete propria del domain controller. Se si parte da un elenco di priorità più ampio, Hardening di Active Directory: cosa bloccare per primo spiega dove si colloca questo tipo di hardening di protocollo rispetto all'accesso privilegiato e ai segreti riutilizzabili. I tre finding seguenti compaiono raramente in un report sui permessi, ma ognuno è economico da verificare e correggere una volta saputo dove guardare:

Nessuno di questi tre finding è nuovo. Ciò che giustifica il raggrupparli in un'unica passata di revisione è che falliscono silenziosamente — un DC con un listener LDAPS degradato, uno spooler attivo o pochi minuti di disallineamento dell'orologio appare perfettamente sano in un controllo di stato standard, finché qualcosa non forza la situazione.

TLS Debole su LDAPS

Installare un certificato valido nell'archivio Personale del computer locale del DC abilita automaticamente LDAPS sulla porta 636 (e 3269 per il Global Catalog) — la guida Microsoft sulla configurazione dei certificati LDAP su SSL conferma che non è richiesta alcuna configurazione aggiuntiva del servizio una volta che il certificato è attendibile sia per il DC sia per i suoi client. Il problema è che «LDAPS è attivo» non dice nulla su quali versioni TLS e cipher suite continuerà ad accettare. Un DC su cui Schannel non è mai stato irrobustito negozierà TLS 1.0 o 1.1, e cipher suite CBC/SHA1 deboli, con qualsiasi client disposto a offrirle — come descritto nella guida di DSInternals su come forzare TLS 1.2+ per LDAPS sui domain controller. Questo conta perché i bind semplici LDAP trasportano credenziali sulla rete; un cifrario degradato sul canale cifrato pensato per proteggerle vanifica lo scopo stesso di eseguire LDAPS.

Rilevamento

Abilitate la registrazione diagnostica di Schannel prima di toccare qualsiasi cosa — serve evidenza di cosa si sta effettivamente connettendo prima di disabilitare una versione di protocollo:

# Registrazione dettagliata degli eventi Schannel (dettaglio protocollo/cifrario per connessione tramite Event ID 36880)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" `
  -Name "EventLogging" -Value 7 -PropertyType DWord -Force

# Enumerare le cipher suite attualmente abilitate per TLS su questo DC
Get-TlsCipherSuite | Select-Object Name, Certificate, Exchange, Cipher, Hash

Get-TlsCipherSuite restituisce l'elenco ordinato delle cipher suite che Windows negozierà — Microsoft documenta il riferimento completo del cmdlet in Get-TlsCipherSuite (TLS). Con EventLogging impostato, ogni handshake Schannel da e verso il DC finisce nel log di Sistema sotto l'Event ID 36880 con la versione di protocollo e la cipher suite negoziate esplicitamente indicate — questa è la prova di quali client o strumenti stanno ancora forzando un downgrade prima di disabilitare qualsiasi cosa.

Remediation

1. Confermate che nessun client legittimo necessiti ancora di TLS 1.0/1.1 usando l'evidenza dell'Event ID 36880 sopra.
2. Disabilitate TLS 1.0 e TLS 1.1 lato server tramite le chiavi di registro Protocols di Schannel, oppure usate Disable-TlsCipherSuite per rimuovere le cipher suite CBC/SHA1 deboli lasciando abilitate le suite della classe TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
3. Riavviate il DC — le modifiche al protocollo Schannel hanno effetto solo dopo il riavvio.
4. Rieseguite Get-TlsCipherSuite e ricontrollate l'Event ID 36880 per confermare che vengano negoziate solo suite forti.

Spooler di Stampa in Esecuzione su un Domain Controller

I domain controller non stampano nulla per se stessi, quindi il servizio Spooler di Stampa non ha alcuna ragione operativa per essere in esecuzione su uno di essi — eppure viene spedito abilitato di default. L'avviso PrintNightmare di CISA (CVE-2021-34527, CVSS 8.8) ha trasformato quel default in un percorso di esecuzione di codice remoto autenticato e a basso privilegio — lo scoring NVD (PR:L) conferma che basta un account di dominio standard, non diritti di amministratore — e la Direttiva di Emergenza 21-04 di CISA ha imposto alle agenzie federali di disabilitare lo spooler su ogni DC — non solo di applicare la patch.

Applicare la patch non elimina nemmeno il problema di progettazione sottostante. Dal 2018, il «Printer Bug» (un abuso della chiamata RpcRemoteFindFirstPrinterChangeNotification in MS-RPRN) consente a qualsiasi utente autenticato di costringere un DC con lo spooler attivo ad autenticarsi verso un host controllato dall'attaccante — documentato nell'articolo di Sean Metcalf Domain Controller Print Server + Unconstrained Kerberos Delegation. Concatenata con un account che dispone di delega non vincolata, questa coercizione consegna il materiale di credenziali dello stesso DC; concatenata con un relay, alimenta direttamente un attacco NTLM relay — la stessa famiglia di esposizione trattata in Firma SMB disabilitata: perché consente ancora l'NTLM relay. Microsoft Defender for Identity offre già questo come una valutazione di sicurezza permanente che raccomanda di disabilitare lo Spooler di Stampa sui DC.

Rilevamento

Controllate ogni DC del dominio in un solo passaggio — non fidatevi solo del DC che ricordate di aver configurato:

$dcs = Get-ADDomainController -Filter * | Sort-Object HostName
foreach ($dc in $dcs) {
    Get-Service -Name Spooler -ComputerName $dc.HostName |
        Select-Object @{N='DC';E={$dc.HostName}}, Status, StartType
}

Confermate anche che non ci siano code di stampa pubblicate che dipendono da un DC prima di intervenire:

Get-ADObject -Filter "ObjectCategory -eq 'printQueue'"

Remediation

1. Per ogni DC in cui Status è Running o StartType non è Disabled, fermate e disabilitate il servizio:

Set-Service -Name Spooler -StartupType Disabled -ComputerName $dc.HostName
Stop-Service -Name Spooler -ComputerName $dc.HostName

2. Applicatelo a livello di dominio con una GPO collegata all'OU Domain Controllers (Computer Configuration > Preferences > Control Panel Settings > Services, Spooler impostato su Stopped/Disabled) così che un riavvio o un riavvio manuale non lo riattivi silenziosamente.
3. Rieseguite il ciclo di rilevamento dopo il successivo aggiornamento della GPO per confermare che l'impostazione sia rimasta su tutti i DC, compresi quelli appena promossi — un DC appena promosso riparte con il servizio Spooler tornato al proprio stato predefinito (in esecuzione).

Disallineamento dell'Orologio che Nessuno Monitora

Kerberos appone un timestamp ai propri ticket per bloccare gli attacchi di replay, il che significa che l'autenticazione dipende dal fatto che l'orologio di ogni DC resti vicino alla fonte oraria del dominio. La tolleranza è governata dalla policy Kerberos Maximum tolerance for computer clock synchronization — 5 minuti di default, impostata sotto Default Domain Policy > Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy, secondo il riferimento delle policy di sicurezza di Microsoft. Oltre tale tolleranza, l'autenticazione Kerberos fallisce apertamente con una risposta KRB_AP_ERR_SKEW — che viene interpretata erroneamente come un problema applicativo o di rete molto più spesso di quanto venga diagnosticata correttamente come disallineamento dell'orologio.

La gerarchia oraria del dominio ha un'unica radice autorevole: l'emulatore PDC. Ogni altro DC si sincronizza da un pari nella gerarchia di dominio, e le workstation si sincronizzano dal DC che le autentica. Se l'emulatore PDC stesso non punta a una fonte esterna affidabile, l'intero dominio può derivare insieme senza nulla con cui confrontarsi — la modalità di guasto che la guida Microsoft su come configurare il PDC radice con una fonte oraria autorevole è scritta per prevenire. Un DC silenziosamente puntato verso una propria fonte NTP indipendente invece che verso la gerarchia di dominio è altrettanto problematico: diventa una seconda autorità oraria concorrente, che gli altri DC non hanno motivo di considerare più affidabile dell'emulatore PDC, e risolvere i conseguenti fallimenti Kerberos intermittenti senza questo contesto può far perdere ore prima che a qualcuno venga in mente di controllare w32tm.

Rilevamento

# Stato e fonte di sincronizzazione correnti su questo DC
w32tm /query /status

# Confrontare gli scostamenti su tutti i DC del dominio in un solo passaggio
w32tm /monitor

Monitorate il log di Sistema per l'Event ID 4713 (policy Kerberos modificata — solo DC, merita un alert se inatteso) insieme ai fallimenti di autenticazione che fanno riferimento a KRB_AP_ERR_SKEW; correlati, indicano direttamente un problema di sincronizzazione oraria piuttosto che un trust rotto o credenziali scadute.

Remediation

1. Identificate quale DC detiene il ruolo di emulatore PDC e confermate che sia configurato — non un DC pari — verso una fonte NTP esterna affidabile anziché verso l'orologio hardware interno.
2. Se l'emulatore PDC è in disallineamento o mal configurato, la guida alla remediation di grandi scostamenti orari di Microsoft descrive come correggere in sicurezza grandi scostamenti — un salto temporale brusco su un DC può di per sé rompere ticket Kerberos in corso.
3. Confermate che ogni altro DC eredita l'ora dalla gerarchia di dominio (NT5DS) anziché da una propria fonte indipendente.
4. Rieseguite w32tm /monitor dopo la convergenza e confermate che tutti gli scostamenti restino comodamente sotto la tolleranza Kerberos di 5 minuti, non appena sotto.

Trasformare Questo in un Controllo Ripetibile, non in una Correzione Una Tantum

Tutti e tre i finding sopra hanno l'abitudine di regredire silenziosamente: un DC appena promosso ripristina il servizio Spooler al proprio stato predefinito (in esecuzione), un certificato sostituito può reintrodurre silenziosamente un fallback a un cifrario debole, e un'appliance NTP dismessa può lasciare l'emulatore PDC senza preavviso. Nulla di tutto ciò viene rilevato a meno che le categorie di audit che lo registrerebbero non siano effettivamente abilitate — vedere Lacune nella Configurazione dei Criteri di Controllo di Active Directory se gli eventi di policy Schannel o Kerberos non compaiono dove previsto.

Trattate questa checklist come qualsiasi altro controllo soggetto a deriva: rieseguitela secondo una pianificazione, non solo dopo la prima correzione. Un passaggio trimestrale su tutti e tre i controlli — cipher suite, stato dello spooler e scostamenti orari — intercetta la regressione prima che diventi un incidente, con una frazione dello sforzo della remediation originale. I tre snippet PowerShell sopra sono abbastanza brevi da poter essere incapsulati in un'attività pianificata o in un job CI invece di essere eseguiti a mano ogni volta.

Come EtcSec Rileva Questo

La categoria Rete di EtcSec verifica tutti e tre questi finding a ogni audit AD: DC_LDAPS_WEAK_TLS segnala i domain controller il cui listener LDAPS negozia ancora una versione TLS debole, DC_SPOOLER_ACCESSIBLE segnala qualsiasi domain controller con il servizio Spooler di Stampa raggiungibile, e DC_TIME_SYNC_ISSUE (abbinato a NTP_NOT_CONFIGURED) segnala i DC in disallineamento rispetto alla fonte oraria autorevole del dominio o privi di un peer NTP configurato.