¿Por qué debería deshabilitar el inicio de sesión de red para cuentas locales?


8

Esta pregunta hace referencia al hilo de Twitter de @ SwiftOnSecurity: https://twitter.com/SwiftOnSecurity/status/655208224572882944

Después de leer el hilo, todavía no entiendo por qué querría deshabilitar el inicio de sesión de red para cuentas locales.

Así que aquí está lo que estoy pensando, corrígeme donde estoy equivocado:

Digamos que tengo un AD configurado con un DC y varios clientes. Uno de los clientes es John. Por la mañana, John se pone a trabajar y se conecta a su PC de escritorio con las credenciales de AD. Al mediodía, John se dirige a una reunión y 'bloquea' su computadora (windows + L). Luego necesita conectarse a su PC en la oficina utilizando su computadora portátil personal de forma remota (a través de RDP o algo así). Sin embargo, utilizando esta nueva política, no podrá hacerlo.

La explicación que da Securitay es que las contraseñas no son saladas. Sin embargo, ¿cómo podría un atacante obtener acceso en este caso? ¿En qué extremo no se sala la contraseña? ¿O la situación que tengo en mi mente no tiene relación alguna con lo que está tratando de decir? Si este es el caso, ¿qué está tratando de decir realmente?


No estoy seguro de cuál es el problema descrito, pero en su escenario ninguna de las cuentas utilizadas son cuentas locales. ¿Derecha?
Martijn Heemels

44
No por nada y sin ofender, pero ¿por qué no le preguntas al autor de la publicación? "Someone on the internet said something. Let me ask someone else on the internet what the first person meant."
joeqwerty

44
@joeqwerty el autor está ocupado actuando y no responde a menudo.
tedder42

1
@joeqwerty Ella está en su gira de 1989, así que está bastante ocupada ...
The Man

¿Es realmente necesario deshabilitar el inicio de sesión de red para cuentas locales? ¿No está deshabilitado por Remote UAC de forma predeterminada?
Chris

Respuestas:


10

Permitir el inicio de sesión en la red para cuentas locales es peligroso y una práctica de seguridad deficiente. Para los miembros del grupo de administradores, en realidad lo caracterizaría como negligencia. Permite el movimiento lateral y es difícil de detectar y auditar debido a que los inicios de sesión de la cuenta no se registran centralmente (en los controladores de dominio).

Para mitigar esta amenaza, Microsoft creó dos nuevos identificadores de seguridad incorporados para agregar al derecho de usuario "Denegar acceso a esta computadora desde la red":

S-1-5-113: NT AUTHORITY\Local account  
S-1-5-114: NT AUTHORITY\Local account and member of Administrators group  

http://blogs.technet.com/b/secguide/archive/2014/09/02/blocking-remote-use-of-local-accounts.aspx

http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspx


Gracias por responder. Así que déjame entenderlo correctamente:
The Man

Digamos que tengo un DC (SERVER1) con RDP habilitado. En mi computadora portátil personal (no conectada al dominio AD), tengo el mismo nombre de usuario y contraseña de administrador. Entonces, cuando quiero administrar SERVER1, me conecto a través de RDP desde mi computadora portátil personal. Sin embargo, un día, me robaron mi computadora portátil personal y el ladrón pudo acceder a mi computadora portátil con permisos de administrador. A partir de ahí, puede ver el hash de contraseña del usuario local y usar el mismo hash para conectarse al servidor. ¿Sería este escenario correcto entonces?
El hombre

Sin embargo (si este escenario es correcto), esto generó más preguntas. ¿No habría ningún riesgo si simplemente hubiera usado diferentes contraseñas para diferentes usuarios? Además, ¿cómo será importante tener el inicio de sesión de red habilitado en este caso? ¿Es solo porque el atacante puede obtener acceso y configurarlo sin tener acceso físico?
El hombre

2
Sí a ambos, pero dudo que un auditor acepte tener contraseñas diferentes como un control compensatorio suficiente para este riesgo. Tener cuentas de administrador local habilitadas para el inicio de sesión en la red es el tipo de movimiento lateral que hunde tu acorazado cuando eres atacado. Las cuentas de administrador local solo deben ser de acceso local y nunca a través de la red.
Greg Askew

Solo para aclarar algunas cosas. Por sí a ambos, quiere decir que el escenario más nuevo que sugerí es correcto, ¿verdad? Además, ¿qué tan mal serían las cosas si los inicios de sesión de red están habilitados? Pregunto esto ya que todavía no puedo ver cómo habilitar el inicio de sesión de red permitiría el acceso de los atacantes. Además, si desactivo el inicio de sesión en la red, ¿el acceso físico es la única forma de interactuar / configurar el servidor?
El hombre

3

No, su escenario de ejemplo es incorrecto. Si está usando credenciales de AD para iniciar sesión, todo está bien. El problema es con las cuentas locales, es decir, las que se crean en computadoras individuales y existen solo en ellas. Por ejemplo,. \ Administrator, pero esto se aplica a cualquier cuenta en el dominio de la computadora (COMPUTERNAME \ USERNAME). El riesgo de seguridad ", AIUI, es que si las cuentas locales (por ejemplo, el administrador local) comparten la misma contraseña en varias máquinas, es posible extraer los hash de contraseña de la computadora y reutilizarlos en algunos casos para (como una infestación de malware u otro atacante) se mueven lateralmente entre las computadoras.


Gracias por responder. Sin embargo, ¿puede dar un escenario de ejemplo sobre cómo se puede comprometer la seguridad?
El hombre

Contoso utiliza una contraseña de administrador local fija. Contoso no impide el inicio de sesión en la red para cuentas locales. El usuario recibe algún tipo de malware, que llega al punto donde se ejecuta con derechos de administrador. Extrae los hashes de la contraseña. Si no me equivoco, hay formas de usar un hash para la autenticación en algunas circunstancias. O tal vez el hash es fácil de descifrar, o en una mesa arcoiris, o algo así. El malware luego se conecta a todas las máquinas y se propaga a ellas. No solo eso, sino que es difícil saber qué está sucediendo, porque esto no se registra en el DC o en cualquier lugar central, solo en las PC individuales.
Micha
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.