Che cos’è la verifica RPC RDP?
La verifica RPC RDP parte da una distinzione: un criterio che protegge l’interfaccia di amministrazione di Remote Desktop Services risponde a una domanda diversa rispetto alla crittografia utilizzata da una connessione desktop remoto. Un rilievo di audit può individuare valori di criterio raccolti che meritano un’indagine. Per chiuderlo servono evidenze relative allo stesso server, con l’origine e l’applicabilità di ogni impostazione registrate.
Il risultato concreto è una verifica per host: quale computer riceve il criterio RPC, da dove proviene il suo livello di crittografia RDP nativa e che cosa resta sconosciuto su una connessione reale. Tenete separate queste conclusioni. Una raccolta estesa all’intero dominio può contenere due valori rassicuranti senza dimostrare che uno dei due protegga il server esaminato.
Per le decisioni più ampie sull’autenticazione e sulla delega delle credenziali, consultate la nostra guida che distingue NLA, il livello di sicurezza RDP e la modalità Restricted Admin. Questa procedura si concentra sul criterio RPC di amministrazione e sulla provenienza dell’impostazione di crittografia.
Come funziona: amministrazione, criteri ed evidenze di connessione
La documentazione Microsoft del CSP dei criteri RemoteDesktopServices descrive RequireSecureRPCCommunication come una protezione dell’interfaccia RPC usata per amministrare e configurare RDS. Enabled richiede richieste autenticate e crittografate; Disabled consente client non sicuri che non rispondono alla richiesta di sicurezza; Not Configured consente comunicazioni non sicure. La sua mappatura ADMX indica fEncryptRPCTraffic in SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.
La stessa documentazione precisa che ClientConnectionEncryptionLevel si applica alla crittografia RDP nativa, non alla crittografia SSL. Il suo nome descrittivo è Set client connection encryption level. Entrambi i criteri si trovano in Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.
Usate tre categorie di evidenze nella verifica. Si tratta di un metodo di verifica proposto, non di un quadro di conformità Microsoft:
| Categoria di evidenze | Domanda di verifica | Conclusione da evitare |
|---|---|---|
| Dichiarazione GPO raccolta | Quale criterio raccolto contiene ciascun valore? | Entrambi i valori si applicano necessariamente a questo server |
| Configurazione e origine sul sistema di destinazione | Che cosa riporta questo server e da dove proviene l’impostazione? | L’origine di un criterio identifica il protocollo negoziato da una sessione |
| Osservazione della connessione | Quali evidenze descrivono lo specifico scambio tra client e server? | Un valore del livello di crittografia dimostra da solo l’uso di TLS |
Rilevamento: verificare lo stesso host RDS
Scegliete un sistema Windows identificato e registrate il nome host, il sistema operativo, l’ambito previsto del criterio, il responsabile della verifica e l’ora di raccolta. Ripetete la verifica per altri ambiti anziché considerare un server rappresentativo di tutte le distribuzioni RDS. I comandi seguenti sono esempi basati sulla documentazione; per questo articolo non sono stati testati né un endpoint Windows né un dominio reale.
Eseguite ogni comando separatamente sul sistema di destinazione con un account autorizzato a leggere la configurazione pertinente. Conservate gli errori e gli output mancanti. Una lettura non riuscita è una lacuna nelle evidenze, non un valore non sicuro né un controllo superato.
Passaggio 1: stabilire l’applicabilità dei criteri computer
La documentazione Microsoft di gpresult descrive il RSoP nell’ambito computer e gli output riepilogativi, dettagliati e HTML. Iniziate con:
gpresult /scope computer /r
Dovreste ottenere informazioni sui criteri computer e sulle GPO applicate. Un riepilogo fornisce contesto; non chiarisce la provenienza di ogni singola impostazione. Raccogliete informazioni dettagliate quando confrontate i criteri candidati:
gpresult /scope computer /z
Allegate alla verifica i dettagli dell’impostazione pertinente. Identificate quale GPO fornisce il criterio RPC e quale fornisce il criterio del livello di crittografia. Le due impostazioni possono legittimamente provenire da GPO diverse, purché entrambe siano dimostrabilmente applicabili a questo stesso host. Se il rapporto non consente di determinare l’origine prevalente, lasciate quella parte della verifica irrisolta.
La nostra guida GPO in quattro controlli sui valori dei criteri, i computer destinatari e la protezione effettiva usa la stessa distinzione sul sistema di destinazione per LLMNR, WSUS, la protezione LSA e l’accesso alla condivisione dei criteri. Questi controlli restano separati da questa verifica RPC.
Passaggio 2: leggere il valore del criterio RPC di amministrazione
Questo comando applica la sintassi di reg query documentata da Microsoft alla mappatura del registro del CSP:
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fEncryptRPCTraffic
Conservate la chiave, il tipo di valore, i dati e il testo di errore esattamente come vengono restituiti. Per una verifica che richiede un criterio abilitato, confrontate il valore del sistema di destinazione con il rapporto dei criteri e la dichiarazione GPO raccolta. Il predicato di etc-collector accetta un valore raccolto di almeno 1; un valore inatteso superiore a 1 deve restare visibile per la verifica anziché essere normalizzato in un booleano presunto.
Un valore assente non è la stessa osservazione di un criterio esplicitamente disabilitato. Determinate se il criterio era configurato e applicabile prima di decidere che cosa cambiare. Non sostituite le evidenze del criterio di amministrazione con quelle sulla crittografia di una connessione desktop.
Passaggio 3: leggere la configurazione di crittografia e la sua origine
Leggete separatamente il valore del criterio:
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v MinEncryptionLevel
Interrogate poi le impostazioni Terminal Services del sistema di destinazione. L’esempio seguente combina la sintassi documentata di Get-CimInstance con lo spazio dei nomi e la classe della documentazione Microsoft di Win32_TSGeneralSetting:
Get-CimInstance -Namespace root/CIMV2/TerminalServices -ClassName Win32_TSGeneralSetting
Senza un parametro di computer remoto o di sessione CIM, il cmdlet legge il WMI locale. Conservate gli oggetti restituiti e identificate il TerminalName pertinente; non usate implicitamente la prima istanza. Esaminate MinEncryptionLevel, PolicySourceMinEncryptionLevel, SecurityLayer e PolicySourceSecurityLayer.
La classe documenta i livelli di crittografia 1 Low, 2 Client Compatible, 3 High e 4 FIPS Compliant. I campi di origine del criterio usano 0 per la configurazione del server, 1 per Group Policy e 2 per il valore predefinito. Questi campi descrivono la provenienza, non una specifica GPO prevalente. La proprietà SecurityLayer usa 1 per RDP nativo, 2 per Negotiate e 3 per SSL; non confondete questa scala della proprietà con una scala del registro o di un metodo di impostazione. La classe documenta anche la riservatezza dei pacchetti per le connessioni al suo spazio dei nomi. Conservate qualsiasi errore del provider o di accesso senza indebolire la sicurezza per ottenere un output.
Qui, output atteso significa proprietà di configurazione con nome da esaminare, non una trascrizione inventata di un controllo superato. Confrontate il livello e l’origine restituiti con il rapporto dei criteri, conservando le discrepanze per l’indagine.
Passaggio 4: dichiarare ciò che si sa sulla connessione
La classe esaminata descrive la configurazione Terminal Services e le origini dei criteri. Non è la trascrizione di uno specifico handshake TLS. Registrate il meccanismo indicato dalla configurazione separatamente da qualsiasi evidenza su una connessione reale.
Prima di raccogliere ulteriori evidenze, decidete che cosa può essere osservato senza cambiare il servizio. Usate le evidenze di connessione esistenti e autorizzate quando disponibili; associatele al server previsto, al client e all’ora. Dichiarate se dimostrano effettivamente l’uso di RDP nativo o TLS per quello scambio. Questo articolo non prescrive un ID evento non documentato, un’affermazione su algoritmi di cifratura o una procedura universale di acquisizione.
Se le evidenze specifiche della sessione non sono disponibili, registrate negoziazione della connessione non dimostrata. Non riavviate RDS, non cambiate il suo livello di sicurezza e non create una connessione sperimentale soltanto per far apparire conclusiva una lettura incompleta. Pianificate un’ulteriore validazione come attività operativa separata e approvata.
Correzione: decidere, applicare e ricontrollare per host (Remediation)
Chiarire le evidenze prima di cambiare il criterio
Usate le domande seguenti come punti decisionali espliciti:
- Entrambi i valori provengono da GPO effettivamente applicabili a questo stesso server RDS? Allegate le evidenze dell’origine per ciascuno, anche se le GPO differiscono.
- Quale meccanismo protegge la connessione, RDP nativo o TLS, e quali evidenze possono essere raccolte senza modificare il servizio? Indicate come sconosciuta ogni negoziazione non osservata.
- Quale conclusione va conservata se l’identificatore storico o l’etichetta del catalogo differisce dal codice attuale? Preservate l’identificatore per la tracciabilità e descrivete separatamente il controllo implementato.
Una verifica utile può concludersi con un’attività di raccolta delle evidenze ancora irrisolta. Evitate di chiuderla con una conclusione di protezione soltanto perché il collector smette di segnalare un rilievo. Viceversa, una lacuna nella raccolta dei criteri da sola non dimostra che il server sia esposto.
Applicare l’impostazione RPC di amministrazione all’ambito previsto
Quando la verifica stabilisce che RPC di amministrazione sicuro è richiesto e non è configurato come previsto, usate Require secure RPC communication = Enabled nel percorso dei criteri documentato sopra. Identificate il proprietario della GPO, i computer interessati e i client di amministrazione prima del rilascio. Pianificate la validazione della compatibilità e l’accesso di recupero per l’ambito pilota.
Dopo che la modifica ha raggiunto il sistema di destinazione, ripetete le letture gpresult e fEncryptRPCTraffic mostrate nel Rilevamento. Allegate evidenze prima e dopo, e registrate qualsiasi errore dei client di amministrazione. Una dichiarazione di criterio modificata senza evidenze dal sistema di destinazione lascia aperta la questione dell’applicabilità.
Gestire l’impostazione di crittografia nativa secondo l’applicabilità
Quando RDP nativo resta pertinente, selezionate il livello previsto tramite Set client connection encryption level, documentando la decisione sulla compatibilità dei client. Considerate il test >=3 del collector come la soglia della sua implementazione, non come un requisito universale di conformità. Quando SSL/TLS protegge la connessione, mantenete l’applicabilità del criterio nativo e la protezione della connessione come decisioni separate.
Ripetete le letture MinEncryptionLevel e CIM dopo una modifica del criterio. Registrate se sono cambiate la configurazione o la provenienza, se l’origine corrisponde al canale di gestione previsto e quale domanda sulla connessione necessita ancora di evidenze. Non cambiate il livello di crittografia soltanto per sopprimere il rilievo senza comprenderne l’applicabilità.
Conservare un verbale di decisione verificabile
Per ogni host, conservate il rilievo originale e l’ora di raccolta; i nomi e gli identificatori delle GPO applicabili; l’output grezzo del registro; l’istanza Terminal Services e i campi di origine del criterio; le evidenze di connessione o la loro assenza; e il responsabile, la motivazione e il seguito della decisione. Collegate le eccezioni a un ambito identificato e a una data di verifica. Distinguete la correzione della configurazione dal completamento della validazione della connessione.
Come EtcSec rileva questo problema
L’unico controllo del catalogo associato qui è ANSSI_R79_RDP_NOT_HARDENED. Nell’implementazione di etc-collector esaminata al commit bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, Detect() valuta i RegistrySettings delle GPO raccolte:
| Condizione raccolta | Risultato implementato | Implicazione per la verifica |
|---|---|---|
Nessuna GPO ha un oggetto RegistrySettings non nil | Non restituisce alcun rilievo | I due segnali non sono stati stabiliti tramite questo controllo; non è un’evidenza di protezione dell’host |
Una qualsiasi GPO raccolta ha MinEncryptionLevel >= 3 e una qualsiasi GPO raccolta ha fEncryptRPCTraffic >= 1 | Non restituisce alcun rilievo | I due valori che superano i test possono provenire da ambiti incompatibili |
Esiste almeno un oggetto RegistrySettings, ma uno dei test aggregati fallisce | Rilievo di gravità Medium, Count 1 | Una sola GPO non pertinente con impostazioni del registro può attivare il controllo |
Il provider legge i file GPO computer da SYSVOL; il parser Registry.pol mappa i due valori DWORD di Terminal Services nei campi usati da questo controllo. Il rilevatore li aggrega tra le GPO raccolte. Non stabilisce il criterio effettivo di un singolo host RDS, non richiede entrambi i valori nello stesso ambito applicabile e non ispeziona le sessioni negoziate. Count 1 descrive il rilievo, non un numero misurato di server esposti.
ANSSI_R79 è un identificatore storico. Il codice dichiara esplicitamente di non misurare R79 pur lasciando invariato l’identificatore; il catalogo del blog esaminato mostra ancora una vecchia etichetta orientata al client. Conservate questa discrepanza nel verbale di verifica. Non trasformate il tag in un verdetto di conformità ANSSI.
Il testo esplicativo del rilievo menziona scenari di downgrade e MITM, ma il suo predicato non osserva né un attacco di rete né la negoziazione della sessione. Questo rilievo non conferma MITM, compromissione o una sessione desktop non crittografata. Usatelo per aprire l’attività di verifica dell’host, poi conservate le evidenze e la decisione per ogni distinta questione di protezione.
Esplora le pagine di identity security collegate a questo tema