RPC seguro no RDP: verificar a origem da política

O que é a verificação de RPC seguro no RDP?

A verificação de RPC seguro no RDP começa com uma distinção: uma política que protege a interface de administração dos Remote Desktop Services responde a uma pergunta diferente da encriptação utilizada por uma ligação de ambiente de trabalho remoto. Um resultado de auditoria pode identificar valores de políticas recolhidos que merecem investigação. Para o encerrar, são necessárias provas relativas ao mesmo servidor, com a origem e a aplicabilidade de cada definição registadas.

O resultado prático é uma revisão do anfitrião: que computador recebe a política de RPC, de onde vem o seu nível de encriptação RDP nativa e o que continua por esclarecer sobre uma ligação real. Mantenha estas conclusões separadas. Uma recolha à escala do domínio pode conter dois valores tranquilizadores sem demonstrar que algum deles protege o servidor em análise.

Para as decisões mais abrangentes sobre autenticação e delegação de credenciais, consulte o nosso guia que distingue NLA, a camada de segurança RDP e o modo Restricted Admin. Este procedimento centra-se na política de RPC administrativo e na proveniência da definição de encriptação.

Como funciona: administração, políticas e provas da ligação

A referência do Policy CSP RemoteDesktopServices da Microsoft descreve RequireSecureRPCCommunication como uma proteção da interface RPC utilizada para administrar e configurar RDS. Enabled exige pedidos autenticados e encriptados; Disabled permite clientes não seguros que não respondem ao pedido de segurança; Not Configured permite comunicação não segura. O mapeamento ADMX identifica fEncryptRPCTraffic em SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.

A mesma referência indica que ClientConnectionEncryptionLevel se aplica à encriptação RDP nativa, não à encriptação SSL. O seu nome de apresentação é Set client connection encryption level. Ambas as políticas estão em Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.

Utilize três categorias de provas na revisão. Trata-se de um método de revisão proposto, não de um quadro de conformidade da Microsoft:

Deteção: verificar o mesmo anfitrião RDS

Escolha um destino Windows identificado e registe o nome do anfitrião, o sistema operativo, o âmbito previsto da política, o responsável pela revisão e a hora da recolha. Repita a revisão para outros âmbitos, em vez de considerar um servidor representativo de todas as implementações RDS. Os comandos abaixo são exemplos baseados na documentação; não foi testado nenhum endpoint Windows nem nenhum domínio real para este artigo.

Execute cada comando separadamente no destino com uma conta autorizada a ler a configuração relevante. Preserve os erros e as saídas em falta. Uma leitura falhada é uma lacuna de provas, não um valor inseguro nem uma verificação bem-sucedida.

Passo 1: estabelecer a aplicabilidade das políticas do computador

A referência de gpresult da Microsoft documenta RSoP no âmbito do computador e saídas de resumo, detalhadas e em HTML. Comece por:

gpresult /scope computer /r

Espere informações sobre as políticas do computador e as GPOs aplicadas. Um resumo fornece contexto; não resolve a proveniência de cada definição individual. Recolha informações detalhadas ao comparar as políticas candidatas:

gpresult /scope computer /z

Anexe à revisão os detalhes relevantes da definição. Identifique que GPO fornece a política de RPC e qual fornece a política do nível de encriptação. As duas definições podem legitimamente vir de GPOs diferentes, desde que ambas sejam comprovadamente aplicáveis a este mesmo anfitrião. Se o relatório não permitir determinar a origem prevalecente, deixe essa parte da revisão por resolver.

O nosso guia de quatro verificações de GPO sobre valores de políticas, computadores destinatários e proteção real utiliza a mesma distinção no destino para LLMNR, WSUS, proteção LSA e acesso à partilha de políticas. Esses controlos permanecem separados desta revisão de RPC.

Passo 2: ler o valor da política de RPC administrativo

Este comando concretiza a sintaxe documentada de reg query da Microsoft com o mapeamento do registo indicado pelo CSP:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fEncryptRPCTraffic

Guarde a chave, o tipo de valor, os dados e o texto de erro exatamente como foram devolvidos. Numa revisão que vise uma política ativada, confronte o valor do destino com o relatório de políticas e a declaração de GPO recolhida. O predicado de etc-collector aceita um valor recolhido de pelo menos 1; um valor inesperado acima de 1 deve continuar visível para revisão, em vez de ser normalizado para um booleano presumido.

Um valor ausente não é a mesma observação que uma política explicitamente desativada. Determine se a política estava configurada e era aplicável antes de decidir o que alterar. Não substitua as provas da política administrativa pelas provas da encriptação de uma ligação de ambiente de trabalho.

Passo 3: ler a configuração de encriptação e a sua origem

Leia o valor da política separadamente:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v MinEncryptionLevel

Depois, consulte as definições de terminal do destino. O exemplo seguinte combina a sintaxe documentada de Get-CimInstance com o namespace e a classe da referência Win32_TSGeneralSetting da Microsoft:

Get-CimInstance -Namespace root/CIMV2/TerminalServices -ClassName Win32_TSGeneralSetting

Sem um parâmetro de computador remoto ou sessão CIM, o cmdlet lê a WMI local. Guarde os objetos devolvidos e identifique o TerminalName relevante; não utilize silenciosamente a primeira instância. Examine MinEncryptionLevel, PolicySourceMinEncryptionLevel, SecurityLayer e PolicySourceSecurityLayer.

A classe documenta os níveis de encriptação 1 Low, 2 Client Compatible, 3 High e 4 FIPS Compliant. Os seus campos de origem de política utilizam 0 para configuração do servidor, 1 para Group Policy e 2 para predefinição. Estes campos descrevem a proveniência, não uma GPO prevalecente específica. A propriedade SecurityLayer utiliza 1 para RDP nativo, 2 para Negotiate e 3 para SSL; não confunda a escala desta propriedade com uma escala do registo ou de um setter. A classe também documenta a privacidade dos pacotes para ligações ao seu namespace. Preserve um erro do fornecedor ou de acesso sem enfraquecer a segurança para obter uma saída.

A saída esperada significa aqui propriedades de configuração identificadas pelo nome para examinar, não uma transcrição inventada de uma verificação aprovada. Compare o nível e a origem devolvidos com o relatório de políticas, mantendo as divergências para investigação.

Passo 4: indicar o que se sabe sobre a ligação

A classe analisada descreve a configuração do terminal e as origens de políticas. Não é uma transcrição de um handshake TLS específico. Registe o mecanismo indicado pela configuração separadamente de quaisquer provas sobre uma ligação real.

Antes de recolher provas adicionais, decida o que pode ser observado sem alterar o serviço. Utilize provas existentes e autorizadas da ligação, quando disponíveis; associe-as ao servidor, cliente e momento previstos. Indique se realmente estabelecem RDP nativo ou TLS para essa troca. Este artigo não prescreve um ID de evento não documentado, uma afirmação sobre cifras ou uma receita universal de captura.

Se não houver provas específicas da sessão, registe negociação da ligação não demonstrada. Não reinicie RDS, não altere a sua camada de segurança e não crie uma ligação experimental apenas para fazer uma leitura incompleta parecer conclusiva. Planeie a validação adicional como uma tarefa operacional separada e aprovada.

Remediação: decidir, aplicar e voltar a verificar por anfitrião (Remediation)

Resolver as provas antes de alterar as políticas

Utilize as perguntas seguintes como pontos de decisão explícitos:

1. Ambos os valores vêm de GPOs efetivamente aplicáveis a este mesmo servidor RDS? Anexe as provas da origem de cada um, mesmo que as GPOs sejam diferentes.
2. Que mecanismo protege a ligação, RDP nativo ou TLS, e que provas podem ser recolhidas sem modificar o serviço? Marque como desconhecida qualquer negociação não observada.
3. Que conclusão deve ser mantida se o identificador histórico ou a designação do catálogo diferir do código atual? Preserve o identificador para rastreabilidade e descreva separadamente a verificação implementada.

Uma revisão útil pode terminar com uma tarefa de obtenção de provas por resolver. Evite encerrá-la como protegida apenas porque o collector deixa de comunicar um resultado. Inversamente, uma lacuna na recolha de políticas, por si só, não estabelece que o servidor está exposto.

Aplicar a definição de RPC administrativo ao âmbito previsto

Quando a revisão estabelecer que RPC administrativo seguro é necessário e não está configurado como previsto, utilize Require secure RPC communication = Enabled no caminho de política documentado acima. Identifique o responsável pela GPO, os computadores afetados e os clientes de gestão antes da implementação. Planeie a validação de compatibilidade e o acesso de recuperação para o âmbito piloto.

Depois de a alteração chegar ao destino, repita as leituras de gpresult e fEncryptRPCTraffic apresentadas em Deteção. Anexe provas de antes e depois e registe qualquer falha de um cliente administrativo. Uma declaração de política alterada sem provas do destino deixa em aberto a questão da aplicabilidade.

Tratar a definição de encriptação nativa segundo a sua aplicabilidade

Onde RDP nativo continuar a ser relevante, selecione o nível previsto através de Set client connection encryption level, documentando a decisão sobre compatibilidade dos clientes. Considere o teste >=3 do collector como o limiar da sua implementação, não como um requisito universal de conformidade. Onde SSL/TLS proteger a ligação, mantenha a aplicabilidade da política nativa e a proteção da ligação como decisões separadas.

Repita as leituras de MinEncryptionLevel e CIM após uma alteração de política. Registe se a configuração ou a proveniência mudou, se a origem corresponde ao canal de gestão previsto e que questão sobre a ligação ainda necessita de provas. Não altere o nível de encriptação apenas para suprimir o resultado sem compreender a sua aplicabilidade.

Preservar um registo de decisão que possa ser revisto

Para cada anfitrião, preserve o resultado original e a hora da recolha; os nomes e identificadores das GPOs aplicáveis; a saída bruta do registo; a instância do terminal e os campos de origem de política; as provas da ligação ou a sua ausência; e o responsável, a justificação e o seguimento da decisão. Mantenha as exceções associadas a um âmbito identificado e a uma data de revisão. Distinga a remediação da configuração da conclusão da validação da ligação.

Como a EtcSec deteta esta situação

A única verificação do catálogo associada aqui é ANSSI_R79_RDP_NOT_HARDENED. Na implementação de etc-collector revista no commit bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, Detect() avalia os RegistrySettings das GPOs recolhidas:

O fornecedor lê ficheiros de GPO de máquina a partir de SYSVOL; o parser de Registry.pol mapeia os dois valores DWORD de Terminal Services para os campos utilizados por esta verificação. O detetor agrega-os entre as GPOs recolhidas. Não estabelece a política efetiva de um anfitrião RDS individual, não exige ambos os valores no mesmo âmbito aplicável e não examina sessões negociadas. Count 1 descreve o resultado, não um número medido de servidores expostos.

ANSSI_R79 é um identificador histórico. O código declara explicitamente que não mede R79, mantendo o identificador inalterado; o catálogo do blogue revisto ainda apresenta uma designação mais antiga orientada para o cliente. Mantenha essa discrepância no registo da revisão. Não transforme a etiqueta num veredito de conformidade com a ANSSI.

O texto explicativo do resultado menciona cenários de downgrade e MITM, mas o seu predicado não observa um ataque de rede nem a negociação da sessão. Este resultado não confirma MITM, comprometimento ou uma sessão de ambiente de trabalho sem encriptação. Utilize-o para abrir a tarefa de verificação do anfitrião e, depois, preserve as provas e a decisão para cada questão de proteção distinta.