19 Consejos C onsejos inteligentes inteligentes para asegurar a Active Directory Di rectory ¿Active Directory no le deja dormir? Se puede entender fácilmente el motivo. Es quizá el sistema distribuido más grande y más importante en su empresa. empresa. Junto con la recuperación de desastres, desastres, la seguridad segur idad de Active Active Dir ectory® ectory® es prioritari pri oritario o en la lista lis ta de temas temas que le q uitan el sueño a un administrador. Sin embargo, se puede hacer mucho para mejorar su seguridad de Active Directory y quizás usted ya tomó algunas medidas. A continuación aparece una lista de consejos útiles para que su i nstalación de Active Active Dir ectory sea más más segura. Primero abordo la seguridad seguri dad administrativa, administrativa, después después las contraseñas contraseñas y la seguridad segur idad de grupo gr upo,, para terminar con algunos consejos para la seguridad seg uridad del controlador de dominios. 1. Documente lo que tiene
El primer paso es documentar su configuración de Active Directory. No es un trabajo muy emocionante, pero no puede decidir hacia dónde se debe dirig ir si no sabe dónde está ahora. ahora. Un buen comienzo comienzo es con las estructuras de alto nivel, como la configuración configuraci ón de bosques o dominios, dominios, la l a estructura de la unidad organizativa (OU), la seguridad seg uridad del directori o de alto nivel y las relaciones de confianza existentes. existentes. Documente Documente la topología topologí a de su siti o enumerando los sitios, las configuraciones de cada sitio, los vínculos del sitio si tio y sus configuraciones, la lista l ista de subredes ysus configuraciones, así como cualquier cualqui er objeto de conexión conexión creado manualmente y sus configuraciones. configur aciones. Documente sus Objetos de Política Polí tica de Grupo (GPOs) con una herramienta de de Políti ca de Grupo, como la Consola de Administración inistr ación de Política Polític a de Grupo (GPMC),disponible (GPMC),disponible desde desde las descarg as de Micr osoft osoft(En (En Inglés) e incluida en Windows Server™ 2003 R2. La documentación que elabore debe incluir las políticas de contraseña y auditoría, sin olvidar anotar a qué están vinculados los GPOs y quién tiene derechos sobre ellos. Asegúrese de tener una lista de todos los cambios que ha hecho al esquema de Active Directory, de preferencia en la forma de un archivo de Formato de Intercambio de Directorio Ligero (LDIF). Hay una secuencia de comandos GPMC incluida en la l a descarga para ayudarle ayudarle a empezar, empezar, localizada en el dir ectorio %progr amfiles%\g amfiles%\gpmc\scripts, pmc\scripts, llam ll amada ada GetReportsForAllGPOs.wsf. Cuando elabore esto, también enumere sus controladores de dominio y sus nombres, sus versiones de sistema operativo y el software para explorar virus y sus versiones. Registre los métodos de respaldo que utiliza y con qué frecuencia se ejecutan, además de cuánto tiempo guarda los respaldos. Si utili za respaldos en discos, registr e dónde dónde guarda de manera manera segura l os archivos respaldados. respaldados. Si emplea emplea Window Windows® s® DNS, DN S, utilice DNSCMD D NSCMD y DNSLINT para docume documentar ntar su config uración. Anote si está integr ado con Active Active Dir ectory, ectory, si utiliza divisiones de las aplicaciones y cómo cómo están configuradas. 2. Controle su administración
La seguridad de Active Directory empieza en la parte superior; su modelo de administración. Controlar su administración es la acción fundamental para asegurar asegur ar su bosque bosq ue yquizá qui zá también es la más más difí cil . Todos desean tener una parte de Active Directory, Dir ectory, pero un modelo modelo de bosque bien asegur ado no lo puede permitir permitir.. Si la instalación de su empresa es similar a la mayorí mayoría, a, su diseño lógico lóg ico de Active Directory ya está establecido, establecido, por l o que debe trabajar dentro de sus restricciones. restric ciones. De lo contrario, tiene la oportunidad oportunidad de crear Active Directory desde el el pri ncipio. El bosque es la única frontera de seguri dad real dentro de Active Active Directory. Los dominios se deben utilizar para facil itar l a infraestructura de soporte informático y réplica de su empresa, mientras que las unidades organizativas se deben usar para delegar la administración dentro de un dominio. Si tiene restricciones restri cciones de seguridad estrictas estri ctas entre dos partes de su compañí compañí a, considere implementar implementar otro bosque. Consulte "Consideraciones Consideraciones de bosques múltiples en Windows 2000 y Windows Server 2003" 2003" (En ( En Inglés) para alg unas recomenda recomendaciones. ciones. Si es necesario, agreg ue un bosque bosque confiable con filtro de seguridad para comunicarse comunicarse con su primer bosque (consulte (c onsulte "Planear Planear e implementar bosques federados en Windows Server 2003"" (En Inglés) para obtener más información). Si sus dominios ya están administrados por diferentes grupos, observe que el acceso administrativo a 2003 cualquier controlador de dominio en el bosque puede poner en peligro a todo el bosque. Como resultado, debe trabajar de cerca con los equipos administrativos de los otros dominios para asegurar que tengan un modelo uniforme de administración de controlador de dominios en todo el bosque. Para conocer más detalles sobre este tema, lea "Consideracione "Consideracioness de diseño para delegar la administración en Active Directory" (En Inglés). 3. Limite el número de administradores
Dentro de su bosque, debe hacer todo lo posible para limitar el número de administradores. Aunque el modelo de seguridad de Active Directory es mucho mejor que el de Windows NT® 4.0, aún tiene un punto débil: usted no puede administrar totalmente un controlador de dominios sin ser un administrador del dominio. Esto significa que en una implementación básica de Active Directory, los operadores de PC en ubicaciones que contienen controladores de dominio, usualmente son miembros de la Administración del dominio y pueden realizar todas las funciones de mantenimiento en estos servidores. ¡No haga esto! Ha entregado las claves de su bosque de Active Directory a un grupo de empleados potencialmente grande con antecedente antecedentess y calificaciones califi caciones de seguridad desconocidos. desconocidos. En lugar de esto siga la práctica, avalada avalada por el tiem ti empo, po, de establecer establecer primero pr imero los r equisitos y después crear una solución basada en dichos requisitos. Reúnase con la gerencia de operaciones para definir exactamente qué tareas necesitan realizar en los controladores de dominio. Después diseñe una solución mediante una combinación de Políticas de Grupo y herramientas de terceros para otorgarles tantos derechos como sea posible, sin ascenderlos a Administradores de dominio. Finalmente, su equipo de administración debe asumir las tareas que no puede delegar con seguridad al área de operaciones. Ésta es una cuestión muy delicada, pues pues usted retir a responsabili responsabilidade dadess al área de operaciones, operaciones, pero adquiere el gran gr an compromiso compromiso de la seguri dad de la información. 4. Pruebe las configuraciones de las Políticas de grup o
Ésta es una buena oportunidad para comentar algo sobre la Política de grupo. Es la herramienta única más poderosa para controlar la seguridad de su bosque. Precisamente por su potencia, se debe asegurar de probar estas configuraciones en un ambiente controlado antes de implementarlas. Puede usar un ambiente de prueba de fondo duplicado, ya sea físi co o vir virtual tual (con ( con un software de virtuali zación, como Virtual Virt ual Server 2006). Asimismo, Asimis mo, puede puede aplicar estas políticas en etapas, vinculando primero los nuevos GPOs más seguros a las unidades organizativas individuales, después al dominio completo. 5. Utilice Util ice cuentas administrativas separadas
Una vez que reduzca el número de administradores, asegúrese de que todos los empleados que realizan operaciones con privilegios elevados utilicen cuentas administrativas separadas. Estas cuentas deben tener una convención de nombre distinta a las cuentas estándar y residir en su propia unidad organizativa para que les aplique GPOs únicos. Puede agr agrupar upar estas cuentas cuentas por los roles r oles que r ealizan y asignar derechos a estos g rupos, en vez vez de a individuos. Por ejemplo, los miembros del departamento de soporte técnico responsables de administrar las cuentas deben tener sus cuentas administrativas en un grupo llamado "Administradores de cuentas" y este grupo se debe agregar al grupo integrado de Operadores de cuentas.
1 de 3
6. Restrinja los grupos int egrados elevados
Si su modelo de seguridad sigue las recomendaciones antes citadas, es relativamente fácil colocar a todos los grupos integrados elevados dentro de la función Grupos Restri ngidos de las Polí ticas de gr upo. Con esto se asegura q ue la membresía al grupo se refuerce cada cinco minutos, limitando la opción de que un administrador inconforme pueda insertar su cuenta. Utilice Grupos Restring idos para mantener vacíos ciertos gr upos, como Administradores de esquemas, y limitar a una cifra pequeña a los Administradores empresariales. 7. Utilice un Terminal Server for Administration dedicado
Los administradores de servicio (responsables de ejecutar los servicios esenciales de Active Directory, tales como controladores de dominio, sitios y el esquema) deben realizar todas sus tareas desde puntos de administración del Terminal Server (TSAPs) dedicados y no desde sus escritorios. Ésta es una práctica mucho más segura, q ue minimiza cualquier fi ltrado del malware del escritori o, simplifica el hecho de trabajar con una cuenta administrativa separada y aporta un punto de administración personalizado y cerrado. Mantenga estos TSAPs en sus propias unidades organizativas y utilice l os GPOs para evitar el acceso a Internet, restring ir el inicio de sesión local sólo a cuentas administrativas, aumentar los procesos de auditoría e instalar un protector de pantalla protegido por contraseña. Si actualiza su TSAP a Windows Server 2003 entonces que sus herramientas de administración de Active Directory van a regi strar y codificar el tráfico del Protocolo de acceso a directorio lig ero (LDAP) entre éste y sus controladores de dominio de Windows Server 2003. 8. Deshabilite al invitado yrenombre al administrador
Las medidas básicas de seguridad para las cuentas consisten en deshabilitar la cuenta del invitado y renombrar la cuenta del administrador. Probablemente ya efectuó esto. De cualquier manera, no olvide retirar también la descripción predeterminada de dichas cuentas, pues personas malintencionadas la pueden buscar con facilidad. La mayoría de los ataques a programas usan el Identificador de seguridad de la cuenta (SID) que es bien conocido en vez de su nombre, por lo que renombrar al Administrador es realmente limitado. Sin embargo, demuestra que usted aplica la debida dilig encia para auditorías de seguridad. La política de renombrar también puede servir para crear una cuenta de Administrador como trampa para agresores. Ésta es una cuenta llamada Administrador (después de renombrar la cuenta actual) que tiene permitido un alto nivel de auditoría. Si alg uien trata de iniciar sesión en esta cuenta adivinando la contraseña, el intento se registrará. Si hay una función para supervisar el registro del evento, también puede desencadenar una alerta. 9. Limite el acceso a la cuenta del administrador
Debe limitar severamente el número de personas que tienen acceso a su actual cuenta de Administrador y contraseña. Para el nivel más alto de seguridad, considere la opción de contraseña nuclear: dos (o más) administradores generan dos (o más) contraseñas seguras, aleatorias, de ocho dígitos diferentes entre sí; después cada administrador ingresa su contraseña en el campo de contraseñas. (Para un buen generador de contraseñas, consulte www.winguides.com/security/password.php) (En Inglés). La cuenta ahora tiene una contraseña de 16 dígitos o más, y requiere por lo menos dos administradores para i niciar sesión, un solo administrador no lo puede hacer. 10. Vigile la contraseña DSRM
Una contraseña que a menudo se descuida, pero es muy importante, es la contraseña de Modo de restauración del servicio de directorio (DSRM) en los controladores de dominios. La contraseña DSRM, única para cada DC, se utili za para iniciar sesión en un DC que se ha reiniciado en el modo DSRM para tomar su copia de Active Directory fuera de línea. Usted debe actualizar la contraseña de DSRM regularmente, pues con esta contraseña un operador local puede copiar la NTDS.DIT (la base de datos de Active Directory) del servidor y reiniciar antes de que alguien l o note. Cuando se inició Windows 2000, la única forma de cambiar la contraseña era iniciar sesión y modificarla manualmente, algo impráctico si tiene más de dos DCs. Windows 2000 Service Pack 2 introdujo el comando SETPWD (ver el artículo de la Base del conocimiento "Configurar su asistente de servidor establece una contraseña de modo de recuperación en blanco") para actualizar remotamente la contraseña DSRM. El comando NTDSUTIL en Windows 2003 tiene la capacidad de cambiarla de manera remota (consulte "Cómo reconfigurar la contraseña de la cuenta de administrador en modo de restauración de los servicios de directorio en Windows Server 2003"). Elabore una secuencia de comandos para ejecutar esta operación contra sus DCs y ejecútela regularmente. 11. Refuerce las reglas de contraseñas seguras
Hoy en día todos conocen los beneficios de las contraseñas seguras, pero quizá es demasiado esperar que sus usuarios las utilicen de forma voluntaria. Para logr arlo, realmente debe reforzar las reglas de contraseñas seguras en su dominio (consulte "Habilitar la funcionalidad de contraseñas seguras en Windows 2000"). Puede ayudar a sus usuarios sugiriendo ciertas estrategias de contraseña, como el uso de una frase en vez de combinaciones confusas de palabra/número/carácter. 12. Proteja la contraseña de la cuenta de servicio
Como sabe, las cuentas de servicio son otro asunto delicado. La naturaleza de las cuentas de servicio, usadas en los servidores de aplicaciones para dar servicio a una aplicación, dificulta el cambio de una contraseña de bajo impacto y por ello usualmente la contraseña se establece para que nunca expire. Debido a que la cuenta controla un servicio importante (a menudo en muchos servidores), arriesgar la contraseña de la cuenta de servicio es algo que no desea. Aunque puede ser complicado resolver el problema de cambiar la contraseña, puede hacer algunas cosas para mitigar el riesgo de ataques o cambios accidentales. Otorgue a las cuentas una convención de nombre que las identifique como cuentas de servicio y sugiera para qué se usarán. Coloque todas estas cuentas en un grupo con un nombre similar a "Cuentas de Servicio" y establezca una política en sus servidores de aplicaciones para que rechacen la políti ca de "Iniciar sesión localmente", pero acepten "Iniciar sesión como un servicio". Manténgalas en su propia unidad organizativa para que pueda aplicar GPOs únicos para sus requisitos. 13. Confirme que cada controlador de dominio esté f ísicamente seguro
Los controladores de dominio conforman el aspecto físico de Active Directory. Distribuidos a través de toda su empresa, cada controlador de dominio tiene su propia copia de la base de datos NTDS.DIT de Active Directory. Esto signifi ca que una acción fundamental de seguridad es confirmar que cada controlador de dominio esté fí sicamente seguro. Si uno de ellos es sustraído, el ladrón tendrá acceso físico al árbol de información del directorio (DIT) y podrá ejecutar programas de intrusión contra él para obtener nombres de usuario y contraseñas. Por lo tanto, debe tener configurado un plan de reacción para cambiar todas las contraseñas en un dominio en caso de que uno de sus controladores de dominio sea robado. Una función propuesta para la próxima versión de Windows Server (con nombre de código "Longhorn") tiene como objeto mitigar radicalmente el riesgo de este escenario con el controlador de dominios de sólo lectura (RODC), un controlador de dominio cuyo DIT no contiene contraseñas de usuario. Los
2 de 3
usuarios inician sesión a través de una remisión de Kerberos desde un controlador de dominio completo; usted puede configurar el RODC para poner en caché las contraseñas de los usuarios que lo usan para autenticación. En un escenario de sucursales, sólo los usuarios de la sucursal tendrán sus contraseñas de caché en el RODC, de forma que si está en riesgo éstas serán las únicas contraseñas que se deben cambiar de inmediato. La config uración en caché del RODC es muyflexible; también incl uye una forma para determinar quién tenía su contraseña en caché dentro de éste. Sin embargo, como todos los análisis sobre software de preliberación, esto está sujeto a cambio. 14. Minimice los servicios innecesarios yabra puertos
El Asistente de configuración de seguridad de Windows Server 2003 SP1 puede consolidar rápidamente sus controladores de dominio en este aspecto al guiarlo con un asistente para cerrar esto. Un ataque del q ue se debe cuidar, llamado negación de servicio de clasificaciones, consiste en llenar el espacio en disco disponible en un controlador de dominio. Existen dos formas para ejecutar este ataque. La primera es tratar de saturar Active Directory con objetos. Debido a que Active Directory es altamente escalable, es poco probable que se pare totalmente en este escenario, pero al saturar a Active Directory con objetos se aumenta el tamaño de la base de datos hasta que llena la división del disco. Además de confirmar que el DIT esté en una división con mucho espacio libre, considere implementar cuotas de directorio a través de la DIVISIÓN DSMOD o l a CUOTA DSMOD. Esto evita q ue alguien agr egue demasiados objetos al directorio y mantiene la seguridad esencial. Otro ataque de negación de servicio consiste en saturar la carpeta SYSVOL con archivos, causando que se llene la división de arranque y se pare totalmente el controlador de dominio. Usted no puede usar un sistema de cuota en este caso, pero puede crear archivos de reserva sencillo para tomar el espacio libre en disco existente. Si encuentra esta situación de llenado en el disco, simplemente borre los archivos de reserva, uno a la vez, para mantener el espacio libre en disco hasta que solucione la causa desde la raíz. Puede crear fácilmente archivos de reserva con el comando FSUTIL FILE CREATENEW. 16. Audite los eventos importantes
Usted debe habilitar la auditoría en un GPO al nivel de dominio, sin anulación, para asegurar que cada sistema en su dominio pueda rastrear los eventos importantes. Debe auditar las fallas la iniciar sesión, la administración de cuentas exitosas y fallidas, el acceso a objetos y los cambios de políticas. Util ice el mismo GPO para mejorar el tamaño del registro de seguri dad, pues con el aumento de auditoría será necesario. 17. Utilice IPsec
Muchas empresas han diferido la implementación de IPsec debido a las complejas reglas que deben construir, pero es bastante fácil instalarlo sólo para la comunicación entre controladores de dominio. En cuanto a las comunicaciones de los controladores de dominio a los clientes, hay varias opciones a considerar. Por predeterminación, los controladores de dominio de Windows Server 2003 tienen habilitado el registro de SMB, lo cual significa q ue ellos registran todas sus comunicaciones con el cliente para evitar imitaciones. Su políti ca se enumera como "Servidor de red de Microsoft: registrar digitalmente las comunicaciones (siempre)". Esté consciente de este cambio al actualizar y no lo deshabilite si no es necesario. 18. No almacene Valores hash del administrador LAN
Si es posible, trate de eliminar los hash de contraseña de LM (Administrador LAN); muchos crackers de contraseñas atacan el hash de LM débil y después deducen el hash de NTLM más fuerte. La política que necesita es "No almacenar un Valor hash de Administrador LAN en el siguiente cambio de contraseña". También considere habilitar "Enviar sólo la respuesta NTLM v2, rechazar LM y NTLM". La mayoría de los clientes de bajo nivel se pueden configurar para utilizar NTLMv2. Quizá esto sería imposible en implementaciones de Active Directory en ambientes de fábrica u otras instalaciones que utilizan Windows incrustado. Pruebe estas configuraciones con cuidado, pues pueden invalidar a los clientes de bajo nivel. Es importante recordar que estos clientes no sólo incluyen Windows NT 4.0 y Windows Me, sino también otros clientes de red habilitados por Server Message Block (SMB), como dispositivos de almacenamiento unidos a la red (NAS), clientes UNIX que ejecutan SAMBA o dispositivos incrustados de Windows, como controladores de estaciones de fábricas. El ar tículo de la Knowledge Base "Incompatibilidades de cliente, servicio y programa que pueden ocurrir cuando modifica las configuraciones de seguridad y las asig naciones de derechos de usuario" enumera los consejos para la mayoría de las configuraciones de seguridad y derechos de usuario de un controlador de dominio. 19. No olv ide sus prácticas de negocios
Maneje las emergencias y documente los procedimientos para afrontar si tuaciones como contraseñas en pelig ro, ataques generales a Active Directory y recuperación de desastres de Active Directory. Microsoft ya realizó mucho de este trabajo para usted en la " Guía de mejores prácticas para asegurar las instalaciones de Active Directory" (En Inglés) y "Mejores prácticas: Recuperación del bosque de Active Directory" (En Inglés). La información pre-liberada en este artículo está sujeta a cambio. Sean Deubyes ingeniero de diseño con Intel Corporation, donde es miembro senior del equipo de servicios de identidad y directorio. Es autor de
muchos artículos y presentaciones sobre Active Directory y Windows Server; éste es su tercer año como MVP de Servicios de directorio con Microsoft.
3 de 3