NTLM Session - En los dos extremos

[loureed4]

Hola, me gustaría haceros una pregunta:

Tengo un escenario muy simple por un problema que tengo, el escenario:

Un 2003 Server y un XP SP3, mismo switch, 192.168.56.0 / 24

El caso es que he visto estas políticas, en las directivas locales:

"Network security: Minimum session security for NTLM SSP based (including secure RPC) clients"

y

"Network security: Minimum session security for NTLM SSP based (including secure RPC) Servers"


Entiendo dichas políticas, por lo que he podido averiguar, es para autenticar si le digo: \\equipo-xp desde el equipo con 2003 Server, y viceversa. Autenticaría por LM o NTLM o NTLM SSP, me parece entender. (No kerberos al no estar en dominio).

Nota: LM lo he desactivado con la política "No almacenar LM en la SAM en el proximo cambio de contraseña" , así no se almacena el hash LM, que como todos sabemos, es muy muy débil.

Pero lo curioso, y aquí es donde veo el problema, es que en uno de ellos tengo aplicadas las políticas o directivas que he escrito más arriba, con sus cuatro parámetros: Requerir integridad, confidencialidad, NTLMv2 y 128 bits en la encriptación.

Sin embargo en el otro equipo no tengo activado ninguna de estas políticas , con lo cual no sé como, haciendo \\equipo-xp , puedo logarme, cuando me está exigiendo NTLM2, 128 bits de cifrado, confidencialidad (cifrado de nuevo) e integridad.

Creía que en ambos extremos tenía que estar activadas las políticas.

Gracias por adelantado !

[moeb]

No sé si entiendo bien lo que pretendes preguntar... Arriesgaré :)

La política de conexión a recursos se establece en la máquina a cuyos recursos pretendas acceder... Y se aplica la que el otro pueda asumir.

Es decir, si en la máquina que actúa como servidor (la que exporta el recurso). restringes a que SOLO puedan conectarse máquinas qeu cumplan un determinado nivel de seguridad, cualquier máquina que pueda cumplir ese nivel (es decir, que entienda el protocolo exigido) puede realizar la conexión, usando siempre ese protocolo. No es necesario que la máquina que se conecta tenga ninguna directiva, basta con que sepa hablar el protocolo que le exiges (es decir, con esa configuración que comentas un win98 no se logearía correctamente).

Si no pones esa directiva como obligatoria, las máquinas podrían conectarse con un nivel de seguridad menor (aunque si conocen el protocolo más robusto intentarán usarlo primero).

Es decir... En una conexión concreta, quien marca la obligatoriedad o no de un nivel determinado de seguridad, y quien marca dicho nivel mínimo, es la máquina A LA QUE TE CONECTAS (la que exporta el servicio). La máquina que se conecta tan sólo debe ser capaz de usar ese nivel de seguridad (no tiene por qué estar "obligada" a hacerlo, porque podría conectarse tambien con un servidor que no requiriese ese nivel o que no pudiese usarlo, como un NT o un w98 exportando disco duro).

[loureed4]

Buenas,

Muchas gracias, de nuevo quedao agradecido por tu tiempo !

No he contestado antes porque estoy haciendo un "trouble-shooting" para comprender mejor estas políticas , ya que hay algo que se me está escapando.

Por cierto, muy muy aclaratoria tu explicación, muchas gracias ! .

Postearé con resultados porque hay cosas que no veo claras cuando combino estas políticas en el cliente y en el servidor, que, sino me equivoco, no tiene que ser el servidor un controlador de dominio, sino un servidor de archivos (por ejemplo) , osea un servidor smb. Digo smb porque estoy haciendo pruebas con Cain y veo que mete las password en ese apartado, en "smb" lo cual es lógico, ya que smb es el encargado de la compartición de archivos (CIFS en Microsoft). Pero como te comento, hay cosas que no me cuadran ya que, por ejemplo, si quito todas las políticas de mi pregunta, en el servidor y el cliente, y en ambos hago un gpupdate , Cain me dice que las contraseñas o autenticaciones son NTLM SSP, y yo he quitado como digo todas las políticas NTLM SSP a las que hago referencia en mi pregunta. No sé si es tema de refresco pero no porque reinicio las máquinas (virtuales).

Por otro lado estas políticas avisan de que van a depender de la política "Nivel de autenticación de LAN Manager" y en esas estoy, porque creo que si en ésta última pones una política, concretamente las más bajas, creo que las políticas de mi pregunta no tienen sentido.

Por otro lado, he activado la política de requerir confidencialidad, dentro de las 4 que hay en NTLM SSP, pero .... NTLM no va cifrado ya de por si ?. Hasta donde sé, LM, NTLM y NTLMv2 llevan cifrado, siendo NTLMv2 el más fuerte y LM sumamente débil.

Por cierto que Cain, cuando ve las contraseñas como NTLM SSP, y le aplico unas tablas que hice con el software WinRTGen (Rainbow Tables Generador para Win) para romper hashes NTLM, me dice que ninguno de las hashes son NTLM.

Por eso te comento que estoy con muchas pruebas con las dos máquinas.

Por cierto, me gusta mucho el software WinRTGen, pero para hacer tablas de 10 caracteres NTLM que mezclen Mayuculas, minusculas, números, y símbolos, se lleva días o he visto que semanas para crearlas y necesitas una máquina trabajando sólo para eso porque la CPU está al 100% . Pero tiene la posibilidad de crear tablas para MD5 (hay mucho software que tiene MD5) SHA-1 y SHA-2 y algunos más. Lo que no dice WinRTGen es si NTLM es eso o incluye NTLMv2 , me da que no porque también incluye en la lista LM, y no incluye explicitamente NTLMv2.

Gracias de nuevo !!

[loureed4]

Hola de nuevo, he estado haciendo pruebas, y:

1. Veo que van de la mano la política: "Seguridad de red: nivel de autenticación de LAN Manager" y las políticas de mi pregunta. Además , asi se indica en las políticas por la que abrí este hilo:

"Esta configuración de seguridad permite a un cliente requerir la negociación de la confidencialidad del mensaje (cifrado), la integridad del mensaje, el cifrado de 128 bits o la seguridad de sesión NTLMv2. Estos valores dependen del valor de la configuración de seguridad Nivel de autenticación de LAN Manager."

2.Tengo un poco un lío con la política : "Seguridad de red: nivel de autenticación de LAN Manager" , donde se pueden elegir varios niveles de seguridad. Yo siempre elijo esta:

"Enviar sólo respuesta NTLMv2 y rechazar LM: los clientes sólo usan la autenticación NTLMv2, así como la seguridad de sesión NTLMv2 si el servidor la admite; los controladores de dominio rechazan LM (sólo aceptan la autenticación NTLM y NTLMv2). " .

Y he aquí que es donde me lío con dos palabras clave: "autenticación y sesión". Autenticación es fácil, si accedo a \\equipo-xp he de identificarme, autenticarme con unas credenciales válidads en ese equipo.

Es en lo de sesión donde me lío, es decir, cuando dice: "seguridad de sesión NTLMv2 si el servidor lo admite" . No sé a que se refiere esto. Seguridad de sesión no me suena a la autenticación, entonces..¿que podría ser? .

Me sonaba sesión a que el intercambio de datos iba a ser seguro, con NTLM2, pero eso es IPSec e IPSec asegura todo el tráfico entre dos pc´s con clave precompartida, kerberos o certificados.

Mirando la ayuda de Windows no me aclaro la verdad, y la he leido y probado en el escenario que comento muchas veces esta mañana.

Las políticas de mi pregunta, acerca de requerir integridad (firmar los paquetes?), requerir confidencialidad (cifrado), NTLMv2 y 128 bits de encriptación ..... pero estas configuraciones.....cuando se usan? al autenticar un cliente smb en un servidor smb?

Perdón por el tocho, es por la confusión que tengo al respecto.

Gracias de antemano !

[moeb]

Las diferencias entre autenticación y sesión son las de siempre...

La autenticación se produce en el momento en que envías unas credenciales que son aceptadas por el otro punto... En ese momento se crea una llave de sesión, que sirve para firmar y sellar todos los paquetes de comunicación durante esa sesión (hasta que haces logoff).

Lo que quiere decir es que tanto para la autenticación, como para la sesión, se usará el nivel de seguridad más alto...

Es algo similar a lo que comentábamos el otro día sobre HTTPS y HTTP. Cuando mandas las ceredenciales puedes hacerlo vía HTTPS, y UNA VEZ OBTIENES UNA COOCKIE DE SESIÓN, pasas a http (ya no se transmiten credenciales) por ser más eficiente (sonsume menos recursos).

Con ésto podrías hacer algo similar. Exigir un nivel de NTLM superior (v2) para el trasiego de claves/desafio/respuesta (autenticación), y bajar el nivel una vez obtenidas las llaves de sesión...

Con tu directiva fuerzas a que toda la comunicación/sesión se establezca con NTLMv2 (según indicas).

[loureed4]

Gracias Moeb.

Bastante aclaratorio.

Osea, que nos quedamos siempre en el cifrado , integridad, NTLMv2, etc, pero de las credenciales, nunca de los datos, que eso ya sería cosa de IPSec sino me equivoco... ?

Me pregunto el porque de estas directivas, es decir, de requerir integridad (firma), confidencialidad (cifrado), NTLMv2 (el equivalente a mantener https siempre en la sesión) y 128 bits (otra vez cifrado).

¿Antes no existía esta seguridad? ¿Antes no había confidencialidad en el intercambio de credenciales mediante NTLMv2 ?. Creo que NTLMv2 es el protocolo con mayor cifrado para estas cosas (quitando Kerberos que es para enternos de dominio). ¿Antes no se requería integridad (firma)? . Digo esto porque veo que hay otro política en la que se van a firmar los paquetes por SMB, para evitar ataques man in the middle, o al menos para que se sepa que esos paquetes no se han alterado durante el camino. Esto no me garantiza que no haya un man in the middle porque el atacante puede ver credenciales, etc y no alterar el paquete....creo.

Muchas gracias !!

[moeb]

¿Antes no existía esta seguridad? ¿Antes no había confidencialidad en el intercambio de credenciales mediante NTLMv2 ?. Creo que NTLMv2 es el protocolo con mayor cifrado para estas cosas (quitando Kerberos que es para enternos de dominio). ¿Antes no se requería integridad (firma)? . Digo esto porque veo que hay otro política en la que se van a firmar los paquetes por SMB, para evitar ataques man in the middle, o al menos para que se sepa que esos paquetes no se han alterado durante el camino. Esto no me garantiza que no haya un man in the middle porque el atacante puede ver credenciales, etc y no alterar el paquete....creo.

Todo correcto, a mi entender.

Esas políticas existen para que puedas integrar o no sistemas windows antiguos (o MAC) que no soporten NTLMv2, dentro de tu red.

Si sabes que todos los clientes de tu red soportan NTLMv2, puedes forzar a que ningun cliente pueda conectarse si el nivel de seguridad al que llega es menor... Pero se mantiene la posibilidad por la compatibilidad hacia atrás.

Otra cosa es que POR DEFECTO deberían ser mucho más restrictivos y e nel caso de que alguien necesitase habilitar algo, que lo hiciese... Microsoft siempre ha sido lo contrario. Por defecto te dejaban todo abierto para "no complicar la vida al usuario" (en realidad, nos han complicado infinitamente más la vida a todos los que nos ocupamos de ésto a nivel profesional y a las empresas).

Tio... Te vas a hacer un experto en poco tiempo :)

[loureed4]

Gracias por contestar !

En su día tuve activado la opción de "Nivel de autenticación LAN Manager" al máximo, a sólo aceptar autenticaciones NTLMv2, pero me dio problemas y todos los equipos eran XP Pro y 2003 Enterprise Server SP2 , así que lo bajé a Permitir NTLMv2 y NTLM. No recuerdo la incidencia, creo que era a nivel de ciertas aplicaciones. Mal hecho por mi parte no documentarlo !!

No me cuadra una cosa que estoy probando :


En el lado del servidor smb, o servidor de ficheros, le aplico la política:

Seguridad de sesión mínima para servidores NTLM basados en SSP (incluyendo RPC). Activo las cuatro opciones que aparecen , pero enfoquo ahora en la de "Requerir seguridad de sesión NTLMv2: Se producirá un error en la conexión sino se negocia el protocolo NTLMv2"

En el lado cliente , donde escribiré \\servidor-ficheros , no activo la política: "Seguridad de sesión mínima para clientes NTLM basados en SSP (inluyendo RPC" .


Es decir, en el servidor estoy exigiendo que en cliente esté activa la política de negociar NTLM2, pero no la he activado .... y para mi gran sorpresa, el cliente se conecta a los recursos compartidos.


Para más inri , en el cliente tengo activada la directiva o política "Nivel de autenticación" en el nivel "enviar respuestas lm y ntlm" y en el servidor el nivel "Enviar NTLMv2\Rechazar LM" , por aqui entiendo que se "vean" porque tienen en común el protocolo de autenticación NTLM , pero en la política del cliente, la que he comentado de "enviar respuests lm y ntlm" , dice: "No usan nunca la seguridad de sesión NTLMv2" , y aquí es donde no entiendo cómo si el servidor exige sesión NTLMv2 , y el cliente dice que nunca ni lo intentará, se establece la comunicación.

Perdón por hacer el hilo tan largo, pero necesito saber las cosas porque la seguridad es muy importante para mi, me apasiona y me parece que la puerta de casa debe estar bien cerrada si tu barrio (internet) es peligroso.

Gracias por la paciencia !!

P.D: Gracias por lo de experto, yo creo que soy un newbie, jeje, pero me gusta mucha la Seguridad informática a nivel defensivo, para tener mi red bien fuerte.

Un saludo !

[loureed4]

Hola de nuevo,


Me autorespondo porque creo que sé donde está el problema:

Las directivas "nivel de autenticación de LAN Manager" y "Seguridad mínima para cliente/servidor basados en NTLM SSP (incluyendo RPC Seguro) van de la mano.

Entonces, la yo tener establecido que el cliente SMB transmita la autenticación por LM o NTLM y el servidor accepte NTLM (no acepta LM) pues no le puedo decir en la otra directiva (la de seguridad mínima de sesión) , que negocien NTLMv2 , ya que no hay NTLMv2 por ningún lado.......por eso conectan.

Esa es mi teoría, no le encuentro otra explicación y ésta la veo razonable.

Ahora empiezo a entender !!!! ....Por fin.

Muchas gracias por tu tiempo y paciencia Moeb !!