Quase todas as avaliações de segurança, testes de penetração ou conversas sobre arquitetura do AD acabam contendo a recomendação de «mudar do LDAP não seguro para o LDAPS» para o seu Active Directory (AD). Trabalhando para um fornecedor de software cujos produtos «fazem coisas com o AD», ouço a pergunta várias vezes por semana: «O seu produto XY suporta LDAPS? Se não, está nos planos?». Na maioria dos casos, a resposta correta é «Não, e isso não é uma preocupação de segurança». Vejamos as razões para essa resposta.
Qual é o problema com o LDAPS?
A Internet oferece literalmente milhares de artigos, blogs e vídeos sobre como criar e importar certificados TLS para os seus controladores de domínio (DCs) para que eles sirvam LDAP sobre TLS na porta 636/TCP. Para obter mais informações sobre o método que os DCs usam para selecionar o seu certificado LDAPS quando existem vários candidatos, pode ler esta publicação de Marc-André Moreau na AwakeCoding, mas, para recapitular, Moreau explica que:
“Habilitar e aplicar o LDAPS é uma tarefa comum de reforço de segurança nos ambientes do Windows Active Directory atualmente... Em teoria, tudo parece ótimo, até você perceber que não só [não é possível] selecionar explicitamente o certificado LDAPS a ser usado, como também não há logs para habilitar e nenhuma maneira de diagnosticar o problema.”
O que esses artigos sobre «implementar LDAPS» geralmente não dizem é o que fazer com o LDAPS depois de ativado. Uma coisa é certa, porém: os seus DCs continuarão a servir LDAP sem TLS na porta 389, e não é possível desativá-lo ou bloqueá-lo no firewall sem causar graves perturbações aos membros do AD.
Deixe-me repetir: um membro AD sempre usará a porta 389/3268 para quaisquer consultas LDAP/GC que precise realizar em virtude de ser um membro AD. Não há como alterar esse comportamento ou induzir uma máquina membro a usar o LDAPS com TLS na porta 636/3269, ponto final. Também não há uma maneira padronizada e universalmente confiável de fazer com que a infraestrutura anuncie o LDAPS aos aplicativos.
Por que as soluções alternativas LDAPS não funcionam
Como o único mecanismo conhecido para a descoberta de serviços LDAP é o DNS, as pessoas tentaram várias técnicas:
- Adicione um registo SRV para LDAPS, como _ldaps._tcp.domain.com, juntamente com _ldap e _gc.
- Altere o número da porta nos registos do serviço LDAP de 389 para 636 (e impeça que sejam atualizados pelos DCs).
- Substitua os registos SRV _ldap por _ldaps (ou seja, elimine os registos _ldap e _gc ).
O problema com essas abordagens é que elas não funcionam.
Adicionar um registo SRV para LDAPS não altera nada
Como o _ldaps não é um serviço padrão, nenhum aplicativo irá procurá-lo no DNS. Se criar um aplicativo que se beneficie do LDAP sobre TLS, pode implementar a descoberta do serviço LDAPS no seu código; ele funcionará como qualquer descoberta de serviço personalizada. Mas ele não é e nunca foi um padrão da indústria, portanto, nenhum outro aplicativo irá utilizá-lo.
Alterar o número da porta não funcionará
Alterar o número da porta não interromperá as comunicações dos membros do AD, pois a porta 389 está codificada no Windows. Essa ação pode interromper outros aplicativos que utilizam LDAP, pois mudar a porta de 389 para 636 não fará com que eles tentem estabelecer um handshake TLS antes de tentar uma ligação LDAP.
Eliminar registos _ldap e _gc = Simplesmente não o faça
A terceira abordagem é uma ótima maneira de interromper a descoberta de serviços para LDAP, incluindo a de membros do domínio. Não faça isso em casa (ou no trabalho... ou em qualquer lugar, na verdade).
Ligações simples vs ligações SASL
Então, o LDAP no Active Directory é simplesmente «inseguro por natureza»? Muito pelo contrário.
A razão pela qual foi recomendado mudar para LDAPS é proteger as credenciais em texto simples que o LDAP usa se você realizar uma ligação simples. O problema é que os membros do AD — e a maioria das aplicações que acedem ao AD via LDAP — não usam ligações simples. Em vez disso, eles usam ligações SASL, nas quais a autenticação é realizada pelo GSS-SPNEGO e a camada de criptografia LDAP é negociada com chaves de sessão trocadas durante o processo de autenticação.
Portanto, não só não há credenciais em texto simples para proteger, como a comunicação que ocorre já está, na verdade, encriptada, sem a necessidade de depender de certificados para a camada TLS. Este mecanismo não se limita aos membros do domínio. Qualquer aplicação pode fazer isso, independentemente do sistema operativo e da adesão ao domínio.
O que deve fazer para fortalecer o AD LDAP, se não bloquear a porta 389?
Se tiver a certeza de que nenhum aplicativo no seu ambiente realmente precisa de ligações simples com credenciais em texto simples, imponha a assinatura LDAP nos seus DCs definindo a Política de Grupo conforme descrito aqui. Além de... bem, ter as comunicações assinadas, o que impedirá uma variedade de ataques de retransmissão Kerberos e NTLM, os DCs também rejeitarão uma ligação simples através de uma conexão LDAP não criptografada.
Se quiser ter certeza absoluta de que não está a interromper nada, observe os registos de eventos dos seus DCs, conforme descrito neste artigo permanente do Learn sobre assinatura LDAP, vinculação de canal e LDAPS.
Se tiver aplicações que requerem uma ligação simples, force essas aplicações a utilizar a porta 636/3269, configurando esse comportamento (e a confiança nos certificados LDAPS) nas próprias aplicações.
[Nota do editor: este blog foi adaptado da publicação original do autor.]
