"Inicio de sesión anónimo" frente a "NTLM V1" ¿Qué deshabilitar?

"Inicio de sesión anónimo" frente a "NTLM V1" ¿Qué deshabilitar?

Trabajando para deshacerse de los inicios de sesión NTLM V1 por completo en el entorno AD; Encontré muchos eventos, casi todos del usuario "Inicio de sesión anónimo" (4624 eventos), otro 1 (4624 eventos) por ciento proviene de algunos usuarios. Entonces aquí tengo algunas preguntas.

  • ¿Es mejor desactivar el "inicio de sesión anónimo" (a través de la configuración de seguridad de GPO) o bloquear las conexiones "NTLM V1"? ¿Cuáles son los riesgos para uno o ambos? Estos eventos de inicio de sesión provienen principalmente de otros servidores miembros de Microsoft.
  • ¿El inicio de sesión anónimo utiliza "NTLM V1" el 100 % del tiempo? es decir, si veo un inicio de sesión anónimo, ¿puedo asumir que definitivamente está usando NTLM V1?
  • ¿Cuál es exactamente la diferencia entre los eventos de inicio de sesión anónimos 540 y 4624? -> Nota: El nivel funcional es 2008 R2

Por favor, avíseme si necesita información adicional.

Respuesta1

La pregunta que planteaste,"¿Es mejor desactivar el "inicio de sesión anónimo" (a través de la configuración de seguridad de GPO) o bloquear "NTLM V1"?, no es una muy buena pregunta, porque esas dos cosas no son mutuamente excluyentes. Puedes hacer ambas cosas, ninguna o sólo una, y en distintos grados. Hay muchos tonos de gris aquí y no se pueden condensar en blanco y negro.

Deshabilitar NTLMv1 suele ser una buena idea. Se hace con la LmCompatibilityLevelconfiguración del registro o mediante la Política de grupo. Tenga en cuenta que la misma configuración tiene un comportamiento ligeramente diferente dependiendo de si la máquina es un controlador de dominio o un miembro del dominio.

Nivel de compatibilidad Lm

http://technet.microsoft.com/en-us/library/cc960646.aspx

El riesgo potencial al deshabilitar NTLMv1 aquí es romper la compatibilidad con versiones anterioresmuyclientes antiguos de Windows y, más probablemente, con clientes que no sean de Microsoft y que no hablan NTLMv2. Tendrías que probarlos. Cualquier versión razonablemente moderna y parcheada de Windows manejará NTLMv2 con seguridad de sesión sin problemas (estamos hablando como cualquier servidor 2000 o mejor).

Deshabilitar el inicio de sesión anónimo es algo completamente diferente. Puede desactivar la capacidad de los usuarios anónimos de enumerar recursos compartidos, cuentas SAM, claves de registro, todas o ninguna de esas cosas o una combinación. Cuanto más restrinjas el inicio de sesión anónimo, hipotéticamente aumentarás tu postura de seguridad, mientras pierdes facilidad de uso y conveniencia. (por ejemplo, sus usuarios podrían perder la capacidad de enumerar recursos compartidos de archivos o impresoras en un servidor, etc.)

Entonces realmente no puedes decir cuál esmejor.Ambos son dos mecanismos diferentes que hacen dos cosas totalmente diferentes.

El evento 540 es específico de un inicio de sesión de "Red", como un usuario que se conecta a una carpeta o impresora compartida a través de la red. También es un ID de evento estilo Win 2003. Se nota porque tiene solo 3 dígitos. Los eventos correspondientes en Vista/2008 se convirtieron en ID de 4 dígitos:

Eric Fitzgerald dijo: He escrito dos veces (aquí y aquí) sobre la relación entre los ID de eventos "antiguos" (5xx-6xx) en WS03 y versiones anteriores de Windows, y entre los ID de eventos de seguridad "nuevos" (4xxx-5xxx ) en Vista y más allá.

En resumen, EventID(WS03) + 4096 = EventID(WS08) para casi todos los eventos de seguridad en WS03.

Las excepciones son los eventos de inicio de sesión. Los eventos de inicio de sesión exitosos (540, 528) se colapsaron en un solo evento 4624 (=528 + 4096). Los eventos de falla de inicio de sesión (529-537, 539) se colapsaron en un solo evento 4625 (=529+4096).

Aparte de eso, hay casos en los que eventos antiguos quedaron obsoletos (IPsec IIRC) y hay casos en los que se agregaron nuevos eventos (DS Change). Todos estos son instrumentos nuevos y no hay ningún “mapeo” posible; por ejemplo, los nuevos eventos de auditoría de DS Change son complementarios a los antiguos eventos de DS Access; registran algo diferente a los eventos anteriores, por lo que no se puede decir que el evento anterior xxx = el evento nuevo yyy porque no son equivalentes. El antiguo acontecimiento significa una cosa y el nuevo acontecimiento significa otra cosa; representan diferentes puntos de instrumentación en el sistema operativo, no solo cambios de formato en la representación de eventos en el registro.

Por supuesto, expliqué anteriormente por qué renumeramos los eventos y (en el mismo lugar) por qué la diferencia es "+4096" en lugar de algo más amigable para los humanos como "+1000". La conclusión es que el esquema de eventos es diferente, por lo que al cambiar los ID de eventos (y no reutilizar ninguno), forzamos la actualización de la automatización existente en lugar de simplemente malinterpretar los eventos cuando la automatización no conoce la versión de Windows que produjo el evento. Nos dimos cuenta de que sería doloroso, pero no tanto como si cada consumidor de eventos tuviera que conocer y tener una carcasa especial para los eventos anteriores y posteriores a Vista con las mismas identificaciones pero con un esquema diferente.

Entonces, si conoce los eventos de seguridad anteriores a Vista, puede traducir rápidamente su conocimiento existente a Vista sumando 4000, sumando 100 y restando 4. Puede hacer esto en su cabeza.

Sin embargo, si está intentando implementar alguna automatización, debe evitar intentar crear un gráfico con columnas "=Vista" de números de ID de eventos, porque esto probablemente resultará en un análisis erróneo de un conjunto de eventos y porque encontrará Es frustrante que no haya un mapeo 1:1 (y en algunos casos, ningún mapeo).

eric

http://blogs.msdn.com/b/ericfitz/archive/2009/06/10/mapping-pre-vista-security-event-ids-to-security-event-ids-in-vista.aspx

información relacionada