“Logon Anônimo” vs “NTLM V1” O que desabilitar?

5

Trabalhando na eliminação de logins NTLM V1 em conjunto no ambiente do AD; Encontrei muitos eventos, quase todos eles do usuário "Anonymous Logon" (4624 eventos) outros 1 (4624 eventos) por cento provenientes de alguns usuários. Então, aqui tenho algumas perguntas.

  • É melhor desativar o "logon anônimo" (por meio de 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 são principalmente provenientes 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 assumir que ele está definitivamente usando o NTLM V1?
  • Qual é exatamente a diferença entre os eventos de logon anônimos 540 e 4624? - > Nota: O nível funcional é 2008 R2

Por favor, deixe-me saber se alguma informação adicional é necessária.

    
por Darktux 15.05.2014 / 05:44

1 resposta

6

A questão que você colocou, "É melhor desabilitar" logon anônimo "(via configurações de segurança do GPO) ou bloquear" NTLM V1 ", não é uma pergunta muito boa, porque essas duas coisas não são mutuamente exclusivos. Você pode fazer as duas coisas, nenhuma ou apenas uma, e em vários graus. Há vários tons de cinza aqui e você não pode condensá-la em preto e branco.

Desativar o NTLMv1 é geralmente uma boa ideia. Isso é feito com a configuração do registro LmCompatibilityLevel ou via Política de Grupo. Tenha em atenção que a mesma definição tem um comportamento ligeiramente diferente, consoante a máquina seja um controlador de domínio ou um membro do domínio.

link

O risco potencial em desabilitar o NTLMv1 aqui está quebrando a compatibilidade com muito antigos clientes Windows, e mais provavelmente com clientes não-Microsoft que não falam NTLMv2. Você teria que testar isso. Qualquer versão razoavelmente moderna e com patches do Windows lidará com o NTLMv2 com Segurança de Sessão com zero problemas (estamos falando como qualquer coisa do Server 2000 ou melhor.)

Desabilitar o logon anônimo é algo totalmente diferente. Você pode desativar a capacidade de usuários anônimos enumerarem compartilhamentos, contas SAM, chaves de registro, todas ou nenhuma dessas coisas ou uma combinação. Quanto mais você restringe o logon Anônimo, você 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 é o melhor . 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 através do netwok. Também é um ID de evento no estilo 2003 do Win. Você pode dizer porque são apenas 3 dígitos. Eventos correspondentes no Vista / 2008 foram convertidos em IDs de 4 dígitos:

Eric Fitzgerald said: I've written twice (here and here) about the relationship between the "old" event IDs (5xx-6xx) in WS03 and earlier versions of Windows, and between the "new" security event IDs (4xxx-5xxx) in Vista and beyond.

In short, EventID(WS03) + 4096 = EventID(WS08) for almost all security events in WS03.

The exceptions are the logon events. The logon success events (540, 528) were collapsed into a single event 4624 (=528 + 4096). The logon failure events (529-537, 539) were collapsed into a single event 4625 (=529+4096).

Other than that, there are cases where old events were deprecated (IPsec IIRC), and there are cases where new events were added (DS Change). These are all new instrumentation and there is no “mapping” possible- e.g. the new DS Change audit events are complementary to the old DS Access events; they record something different than the old events so you can’t say that the old event xxx = the new event yyy because they aren’t equivalent. The old event means one thing and the new event means another thing; they represent different points of instrumentation in the OS, not just formatting changes in the event representation in the log.

Of course I explained earlier why we renumbered the events, and (in the same place) why the difference is "+4096" instead of something more human-friendly like "+1000". The bottom line is that the event schema is different, so by changing the event IDs (and not re-using any), we force existing automation to be updated rather than just misinterpreting events when the automation doesn't know the version of Windows that produced the event. We realized it would be painful but it is nowhere near as painful as if every event consumer had to be aware of, and have special casing for, pre-Vista events and post-Vista events with the same IDs but different schema.

So if you happen to know the pre-Vista security events, then you can quickly translate your existing knowledge to Vista by adding 4000, adding 100, and subtracting 4. You can do this in your head.

However if you're trying to implement some automation, you should avoid trying to make a chart with "=Vista" columns of event ID numbers, because this will likely result in mis-parsing one set of events, and because you'll find it frustrating that there is not a 1:1 mapping (and in some cases no mapping at all).

Eric

link

    
por 15.05.2014 / 15:57