Trabalhando para se livrar dos logins NTLM V1 no ambiente AD; encontrei muitos eventos, quase todos do usuário "Logon anônimo" (4.624 eventos), outros 1 (4.624 eventos) por cento provenientes de alguns usuários. Então, aqui eu tenho algumas perguntas.
- É melhor desabilitar o "logon anônimo" (por meio das configurações de segurança do GPO) ou bloquear conexões "NTLM V1"? quais são os riscos para um ou ambos? Esses eventos de logon vêm principalmente de outros servidores membros da Microsoft.
- O logon anônimo usa "NTLM V1" 100% do tempo? ou seja, se eu vir um logon anônimo, posso presumir que ele está definitivamente usando o NTLM V1?
- Qual é exatamente a diferença entre os eventos de logon anônimo 540 e 4624? -> Obs: O nível funcional é 2008 R2
Por favor, deixe-me saber se alguma informação adicional é necessária.
Responder1
A pergunta que você fez,"É melhor desabilitar o "logon anônimo" (por meio das configurações de segurança do GPO) ou bloquear o "NTLM V1", não é uma pergunta muito boa, porque essas duas coisas não são mutuamente exclusivas. Você pode fazer ambos, nenhum ou apenas um, e em vários graus. Existem muitos tons de cinza aqui e você não pode condensá-los em preto e branco.
Desativar o NTLMv1 geralmente é uma boa ideia. Isso é feito com a LmCompatibilityLevelconfiguração do registro ou por meio da Política de Grupo. Esteja ciente de que a mesma configuração tem um comportamento ligeiramente diferente dependendo se a máquina é um controlador de domínio ou um membro do domínio.
http://technet.microsoft.com/en-us/library/cc960646.aspx
O risco potencial de desabilitar o NTLMv1 aqui é quebrar a compatibilidade com versões anterioresmuitoclientes Windows antigos e, mais provavelmente, com clientes que não são da Microsoft e que não falam NTLMv2. Você teria que testá-los. Qualquer versão razoavelmente moderna e corrigida do Windows lidará com NTLMv2 com segurança de sessão sem problemas (estamos falando como qualquer coisa do Server 2000 ou melhor).
Desativar o logon anônimo é algo completamente diferente. Você pode desativar a capacidade de usuários anônimos de enumerar compartilhamentos, contas SAM, chaves de registro, todas ou nenhuma dessas coisas ou uma combinação. Quanto mais você restringe o logon anônimo, hipoteticamente aumenta sua postura de segurança, enquanto perde facilidade de uso e conveniência. (por exemplo, seus usuários podem perder a capacidade de enumerar compartilhamentos de arquivos ou impressoras em um servidor, etc.)
Então você não pode realmente dizer qual émelhorar.Ambos são dois mecanismos diferentes que fazem duas coisas totalmente diferentes.
O evento 540 é específico para um logon de "Rede", como um usuário se conectando a uma pasta ou impressora compartilhada pela rede. É também um ID de evento no estilo Win 2003. Você pode dizer porque são apenas 3 dígitos. Os eventos correspondentes no Vista/2008 foram convertidos em IDs de 4 dígitos:
Eric Fitzgerald disse: Escrevi duas vezes (aqui e aqui) sobre o relacionamento entre os "antigos" IDs de eventos (5xx-6xx) no WS03 e versões anteriores do Windows e entre os "novos" IDs de eventos de segurança (4xxx-5xxx ) no Vista e além.
Resumindo, EventID(WS03) + 4096 = EventID(WS08) para quase todos os eventos de segurança no WS03.
As exceções são os eventos de logon. Os eventos de logon bem-sucedidos (540, 528) foram recolhidos em um único evento 4624 (=528 + 4096). Os eventos de falha de logon (529-537, 539) foram recolhidos em um único evento 4625 (=529+4096).
Fora isso, há casos em que eventos antigos foram descontinuados (IPsec IIRC), e há casos em que novos eventos foram adicionados (DS Change). Todos estes são instrumentos novos e não há “mapeamento” possível – por exemplo, os novos eventos de auditoria DS Change são complementares aos antigos eventos DS Access; eles gravam algo diferente dos eventos antigos, então você não pode dizer que o evento antigo xxx = o novo evento yyy porque eles não são equivalentes. O evento antigo significa uma coisa e o novo evento significa outra coisa; eles representam diferentes pontos de instrumentação no sistema operacional, não apenas alterações de formatação na representação de eventos no log.
É claro que expliquei anteriormente porque renumeramos os eventos e (no mesmo lugar) porque a diferença é "+4096" em vez de algo mais amigável como "+1000". O resultado final é que o esquema do evento é diferente, portanto, ao alterar os IDs dos eventos (e não reutilizar nenhum), forçamos a atualização da automação existente, em vez de apenas interpretar mal os eventos quando a automação não conhece a versão do Windows que produziu o evento. Percebemos que seria doloroso, mas não é tão doloroso como se cada consumidor de eventos tivesse que estar ciente e ter um case especial para eventos pré-Vista e eventos pós-Vista com os mesmos IDs, mas esquema diferente.
Portanto, se você conhece os eventos de segurança pré-Vista, pode traduzir rapidamente seu conhecimento existente para o Vista adicionando 4.000, adicionando 100 e subtraindo 4. Você pode fazer isso mentalmente.
No entanto, se você estiver tentando implementar alguma automação, evite tentar criar um gráfico com colunas "=Vista" de números de ID de evento, porque isso provavelmente resultará na análise incorreta de um conjunto de eventos e porque você encontrará é frustrante que não exista um mapeamento 1:1 (e, em alguns casos, nenhum mapeamento).
Érico