¿Existe alguna manera, utilizando un firewall, una configuración de política de grupo u otro control, para evitar que alguien que haya iniciado sesión en un miembro del dominio pueda ejecutar código de forma remota en un controlador de dominio (al que de otro modo no tendría acceso a la red), dado que ¿Podrían haber robado las credenciales de administrador de dominio de alguien? ¿O el acceso a la red necesario para la membresía rutinaria de AD es para siempre e inseparablemente el mismo que el acceso a la red necesario para la ejecución remota con, por ejemplo,PsExeco PowerShell?
Para esbozar un ejemplo:
- El servidor de Windows "miembro1" es un miembro de dominio para un dominio AD simple
- Los servidores de Windows "dc1" y "dc2" son los controladores de dominio para este dominio simple
- existe un firewall de hardware entre el miembro 1 y los DC, y solo aquellosPuertos TCP y UDPque se requieren para ser miembro del dominio están permitidos entre el miembro1 y los DC.
- El usuario "Jack" es un usuario en "miembro1" y, además del acceso descrito en el punto anterior, no tiene acceso a la red de los DC.
- Jack es astuto y puede obtener las credenciales del administrador de dominio "Jill" mediante un ataque de ingeniería social u otro método.
- Jack obtiene estas credenciales, inicia sesión en member1 y puede ejecutar código de forma remota en dc1 o dc2, usando quizásPsExeco PowerShell incluso simplemente utiliza su propia utilidad con .NET, porque el acceso a la red necesario para ser miembro del dominio incluye el acceso a la red necesario para realizar llamadas remotas como estas.
Quiero detener este ataque asegurándome de que el miembro1 solo pueda realizar funciones AD de rutina (autenticación, actualización de la política de grupo, sincronización horaria, etc.) en el dominio y evitar otras acciones como la ejecución remota de procesos en los DC.
Respuesta1
Esto no es posible. Si se une a un dominio, el dominio puede registrar usuarios para que existan en su computadora y aplicarles GPO. Los GPO pueden provocar que se instale software desde la red y modificar entradas arbitrarias del registro.
El uso de un RODC en el enclave protegerá el dominio de su enclave, pero no protegerá el enclave de su dominio. Sin embargo, puede usar esto al revés para aumentar la seguridad y hacer que todas sus computadoras administradas se comuniquen solo con los RODC y permitir que solo otros DC accedan a los DC grabables.
Si tiene computadoras confidenciales que desea proteger de un compromiso en su dominio, considere crear un dominio separado (en un bosque separado) para esos hosts y administrarlos por separado; Esto es muy común cuando se requieren enclaves seguros. También puedes considerar no unirlos a ningún dominio, especialmente si hay muy pocos.
Al observar sus comentarios, realmente no estoy seguro de cuál es su modelo de amenaza.
Lo que haga exactamente dependerá en gran medida de su modelo de amenaza. Sin embargo, normalmente los miembros del dominio y los usuarios arbitrarios no tienen ejecución de código en los controladores de dominio. Si lo que le preocupa son los exploits, aplicar parches es una buena política y, en cualquier caso, el uso de un RODC puede ayudar a limitar el impacto, ya que los RODC no pueden cambiar nada en el dominio.
Si le preocupa que los usuarios ejecuten comandos de forma remota o inicien sesión en el controlador de dominio (lo que no les daría ningún derecho para hacer cosas como implementar software en el dominio sin que también utilicen algún tipo de exploit de escalada de privilegios o similar), puede evitar que lo hagan. de iniciar sesión en los DC según la política de grupo.
La configuración para esto se encuentra en el GPO que se aplica a los DC, en Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment... si eso es lo que está intentando hacer.
Los usuarios (y otros principios de seguridad) están vinculados al dominio o a la máquina, pero no a ambos. Realmente no se pueden hacer cosas como denegar derechos de administrador de dominio según la computadora desde la que se conectan en AD. Pero lo que puede hacer es restringir el acceso a la red a los DC que no sean RODC, y esto probablemente debería ser suficiente (dependiendo de su modelo de amenaza) para evitar acciones administrativas desde estaciones de trabajo de usuarios aleatorios. Si desea evitar que los usuarios utilicen RODC como puntos de pivote (¿es eso lo que desea hacer?), supongo que podría negarles todos los derechos de inicio de sesión, pero eso dificultaría bastante la administración; en su lugar, recomendaría permitir solo los puertos de replicación de DS en un firewall entre el RODC y otros DC.
Los puertos que debes abrir son los identificados en la documentación para el despliegue de RODC; consulte la sección "Puertos de comunicación necesarios" enhttps://technet.microsoft.com/library/dd728028%28v=ws.10%29.aspx. Pero, por desgracia, se debe permitir RPC, y así es como funciona psexec. Esto sólo le permitirá prohibir el inicio de sesión mediante cosas como RDP.
Para completarlo y evitar el uso de psexec con credenciales robadas, siempre puede prohibir a los administradores de dominio iniciar sesión en trabajos por lotes a través del GPO antes mencionado en los controladores de dominio grabables. Eso reducirá ligeramente la manejabilidad, pero es una decisión que puedes tomar. Hay un documento realmente bueno sobre este y otros consejos para la seguridad de la cuenta de administrador de dominio enhttps://technet.microsoft.com/en-us/library/dn487454.aspx. Using delegated access, where administrative accounts are granted specific administrative rights through delegation instead of blanket domain admin, might also be an option for you.
Respuesta2
What do you need to access from the domain controller? Since you have a firewall between member1 and the domain controller, you could block all access to dc1 and dc2, then put something like a read-only domain controller or a web front end on the outside of the firewall that member1 can access.
Respuesta3
You could attack this problem from another direction, by simply blocking all executables (exe, bat, ps1, etc.) from running on your DCs using either SRP or AppLocker, except those you approve beforehand. That way even if they do get access, they would be seriously hindered.
But assuming someone does have Admin privileges, they can do anything they want to your domain from most computers - the DC is there mostly for authentication...
And, as Todd said, if you can't trust Jill, you better remove here rights...
Respuesta4
Simply put, a Domain Admin can do whatever he wants to do (hence domain admin!). There is no way to block someone who has stolen domain admin credential. He can override whatever security measure you put in place.