Windows 2000 Server.
Anuncio
SISTEMAS OPERATIVOS TRABAJO MONOGRÁFICO REALIZADO POR: ANITA ALEGRE LÓPEZ Y MIRIAM CAROLINA QUINTANA COMO ADSCRIPTAS A LA ASIGNATURA “SISTEMAS OPERATIVOS” OCTUBRE - 2002 CAPITULO 1: WINDOWS 2000 SERVER OPERACIONES DE RED SEGURAS CON EL USO DE LOS SERVICIOS DE SEGURIDAD DISTRIBUÍDA DE WINDOWS 2000 ....................................................................................... 8 Aspectos importantes.............................................................................................................. 9 Servicios de Seguridad Distribuída de Windows 2000 .......................................................... 10 El Directorio Activo y la Seguridad ...................................................................................... 12 Ventajas de la administración de cuentas de Directorio Activo ............................................. 13 Relación entre los servicios de directorio y la seguridad ....................................................... 14 Servicios de directorio y seguridad ....................................................................................... 14 Relaciones de confianza entre dominios ............................................................................... 15 Delegación de administración............................................................................................... 16 Derechos de acceso granulares ............................................................................................. 17 Herencia de los derechos de acceso ...................................................................................... 18 Múltiples Protocolos de Seguridad ....................................................................................... 19 Arquitectura para servicios de autenticación múltiple ........................................................... 21 Interfaz del Servidor de Soporte de Seguridad ...................................................................... 22 Protocolo de Autenticación Kerberos.................................................................................... 22 Antecedentes de Kerberos .................................................................................................... 23 Descripción general del protocolo de autenticación Kerberos ............................................... 24 Integración de Kerberos........................................................................................................ 24 Interoperabilidad Kerberos ................................................................................................... 25 Extensiones Kerberos para clave pública .............................................................................. 27 Seguridad de Internet para Windows 2000............................................................................ 27 Autenticación del cliente con SSL 3.0 .................................................................................. 29 Autenticación de usuarios externos....................................................................................... 31 Microsoft Certificate Server ................................................................................................. 31 CryptoAPI............................................................................................................................ 32 Acceso entre empresas: socios distribuídos........................................................................... 33 Credenciales NTLM ............................................................................................................. 35 Credenciales Kerberos.......................................................................................................... 35 Pares de claves privadas/públicas y certificados.................................................................... 35 Transición sin fallos ............................................................................................................. 36 INTRODUCCIÓN A LA ADMINISTRACIÓN DE CAMBIOS Y CONFIGURACIÓN DE WINDOWS 2000 ..................................................................................................................... 40 Windows 2000 y la Administración de cambios y configuración .......................................... 41 Intellimirror.......................................................................................................................... 44 Accesibilidad de los datos..................................................................................................... 45 PLANIFICAR LA MIGRACIÓN DE WINDOWS NT A WINDOWS 2000 ............................ 54 Introducción ......................................................................................................................... 54 Determinar la ruta de la migración........................................................................................ 54 Conceptos de la migración.................................................................................................... 54 Actualización del dominio .................................................................................................... 54 Consecuencias de la actualización del dominio..................................................................... 55 El Asistente de instalación de Active Directory (DCPromo.exe) ........................................... 55 PDC de Windows NT........................................................................................................... 55 El efecto de la actualización sobre el control de acceso......................................................... 55 Identificadores de seguridad (SID) ....................................................................................... 55 Autenticación y tokens de acceso.......................................................................................... 56 1 Autorización y descriptores de seguridad.............................................................................. 56 Uso de la autenticación NTLM............................................................................................. 58 Uso de la autenticación de Kerberos ..................................................................................... 58 Actualización y dominios de recursos................................................................................... 59 Actualización y administración............................................................................................. 60 Modo mixto y modo nativo .................................................................................................. 61 Modo mixto.......................................................................................................................... 61 Modo nativo ......................................................................................................................... 62 Cambiar a modo nativo......................................................................................................... 62 Grupos de Windows 2000..................................................................................................... 64 Grupos locales...................................................................................................................... 64 Grupos locales del dominio .................................................................................................. 65 Grupos globales.................................................................................................................... 65 Grupos universales ............................................................................................................... 65 Uso de los grupos universales............................................................................................... 65 Grupos universales y tokens de acceso.................................................................................. 66 Anidamiento de grupos......................................................................................................... 66 Efectos de la actualización sobre los grupos ......................................................................... 66 Tabla 2. Grupos y modo de los dominios. ......................................................................... 67 NetBIOS y Windows Internet Name Service (WINS) en Windows 2000 .............................. 67 Disponibilidad de LAN Manager Replication Service (LMRepl) .......................................... 68 El proceso LMRepl .............................................................................................................. 68 El proceso FRS..................................................................................................................... 69 Mantener los servicios de LMRepl en un entorno mixto ....................................................... 70 LMRepl y actualización........................................................................................................ 70 Usar Remote Access Services (RAS; Servicios de Acceso Remoto) en un entorno mixto ..... 70 Rutas de actualización soportadas......................................................................................... 71 Tabla 3. Rutas de actualización soportadas. ...................................................................... 71 Orden de la actualización de dominios.................................................................................. 72 Actualizar dominios de cuentas ............................................................................................ 73 Orden de los dominios de cuentas......................................................................................... 73 Orden de los dominios de recursos ....................................................................................... 73 Actualizar estaciones de trabajo y servidores ........................................................................ 73 Reestructuración de dominios............................................................................................... 73 ¿Cuándo debe reestructurar?............................................................................................. 74 ¿Por qué reestructurar? ..................................................................................................... 75 Consecuencias de la reestructuración de dominios ............................................................ 75 Efecto de mover principales de seguridad en los SID............................................................ 75 Mover los principales de seguridad....................................................................................... 76 Efectos del movimiento sobre la pertenencia de Bob al grupo global .................................... 76 Efectos del movimiento sobre las ACL que hacen referencia directamente a Bob ................. 77 SIDhistory............................................................................................................................ 77 Limitaciones del uso de MoveTree ....................................................................................... 78 Conjuntos cerrados y mover usuarios y grupos globales ....................................................... 79 Conjuntos cerrados y mover ordenadores.............................................................................. 79 Cómo trabajar con los conjuntos cerrados............................................................................. 79 Clonar principales de seguridad ............................................................................................ 80 ClonePrincipal...................................................................................................................... 80 Establecer relaciones de confianza........................................................................................ 80 Mover servidores.................................................................................................................. 80 Windows NT 3.51 y SIDhistory............................................................................................ 81 ClonePrincipal y resolución de SID ...................................................................................... 81 Perfiles y SIDhistory ............................................................................................................ 82 Migración de perfiles............................................................................................................ 82 2 Perfiles compartidos ............................................................................................................. 83 Tabla 4. Ventajas e inconvenientes de compartir perfiles. ................................................. 83 Migración de perfiles copiados ............................................................................................. 83 Tabla 5. Ventajas e inconvenientes de copiar perfiles........................................................ 83 Herramienta de Microsoft para la migración de dominios ..................................................... 83 Utilidades básicas para la migración de dominios y escenarios de la migración de dominios. 83 Escenarios de la migración de dominios ............................................................................... 84 Migrar usuarios paulatinamente de Windows NT a Windows 2000 ...................................... 84 Consolidar un dominio de recursos en una OU de Windows 2000 ........................................ 85 Fases del escenario ............................................................................................................... 85 Lista de comprobación de puntos de decisión ....................................................................... 87 Decisiones sobre la actualización.......................................................................................... 87 Decisiones sobre la reestructuración ..................................................................................... 88 Resumen .............................................................................................................................. 88 Para más información ........................................................................................................... 89 SEGURIDAD EN WINDOWS 2000 SERVER ........................................................................ 90 1. Introducción ..................................................................................................................... 90 Microsoft Operations Framework (MOF) ............................................................................. 90 Implementar y mantener la seguridad ................................................................................... 91 Implementar la seguridad ..................................................................................................... 92 Mantener la seguridad .......................................................................................................... 92 Ámbito de esta guía.............................................................................................................. 92 Esquema de los capítulos...................................................................................................... 94 Capítulo 2: Definición de riesgo de seguridad....................................................................... 94 Capítulo 3: Administrar la seguridad con la Directiva de grupo de Windows 2000 ............... 94 Capítulo 4: Asegurar servidores basándose en su función ..................................................... 94 Capítulo 5: Administrar revisiones ....................................................................................... 94 Capítulo 6: Auditoría y detección de intrusiones................................................................... 95 Capítulo 7: Responder a las incidencias ................................................................................ 95 Resumen .............................................................................................................................. 95 2. Definición de riesgo de seguridad ..................................................................................... 95 Administración de riesgos .................................................................................................... 95 Recursos............................................................................................................................... 96 Amenazas............................................................................................................................. 96 Vulnerabilidades................................................................................................................... 97 Explotación .......................................................................................................................... 97 Relación entre amenazas, vulnerabilidades y riesgo .............................................................. 98 Contramedidas ..................................................................................................................... 99 Defensa de datos................................................................................................................. 100 Defensa de aplicaciones...................................................................................................... 101 Defensa de hosts................................................................................................................. 101 Defensa de redes................................................................................................................. 102 Defensa de perímetros ........................................................................................................ 102 Seguridad física.................................................................................................................. 102 Directivas y procedimientos ............................................................................................... 103 Métodos de ataque comunes y medidas preventivas............................................................ 104 Obtención de información .................................................................................................. 104 3 . Administrar la seguridad con la Directiva de grupo de Windows 2000........................... 105 Importancia de utilizar la Directiva de grupo ...................................................................... 105 Cómo aplicar la Directiva de grupo .................................................................................... 106 Garantizar la aplicación de la Directiva de grupo................................................................ 107 Estructura de la Directiva de grupo..................................................................................... 107 Formato de las plantillas de seguridad ................................................................................ 108 Entorno de prueba .............................................................................................................. 109 3 Comprobar el entorno del dominio ..................................................................................... 109 Comprobar la configuración de DNS.................................................................................. 109 Replicación de controladores de dominio............................................................................ 110 Forzar y comprobar la replicación con Repadmin ............................................................... 110 Centralizar las plantillas de seguridad................................................................................. 111 Configuración temporal ...................................................................................................... 111 Diseño e implementación de directivas ............................................................................... 112 Funciones del servidor........................................................................................................ 113 Estructura de Active Directory para admitir las funciones del servidor ............................... 114 Directiva del nivel de dominios .......................................................................................... 115 Unidad organizativa de los servidores miembros ................................................................ 115 Unidad organizativa de los controladores de dominio ......................................................... 115 Unidades organizativas individuales de funciones del servidor ........................................... 116 Importar las plantillas de seguridad..................................................................................... 116 Importar la directiva de línea de base de controladores de dominio..................................... 116 Importar las directivas de servidores miembros .................................................................. 117 Mantener la seguridad de la configuración de la Directiva de grupo.................................... 118 Sucesos del Registro de sucesos ......................................................................................... 119 Comprobar la directiva con el MMC de la directiva de seguridad local............................... 119 Comprobar la directiva con herramientas de la línea de comandos...................................... 120 Auditar la Directiva de grupo ............................................................................................. 120 Solucionar problemas de la Directiva de grupo ................................................................... 120 Herramientas del kit de recursos ......................................................................................... 120 Errores del Registro de sucesos de la Directiva de grupo .................................................... 122 Resumen ............................................................................................................................ 123 Más información ................................................................................................................ 123 Directivas de dominio......................................................................................................... 124 Directiva de contraseñas ..................................................................................................... 124 Directiva de bloqueo de cuentas ......................................................................................... 125 Directivas de línea de base para los servidores miembros ................................................... 126 Directiva de grupo de línea de base para los servidores miembros ...................................... 126 Directiva de línea de base para la auditoría de servidores miembros ................................... 127 Directiva de línea de base para las opciones de seguridad de los servidores miembros........ 128 Restricciones adicionales para conexiones anónimas .......................................................... 131 Nivel de autenticación de LAN Manager ............................................................................ 131 Borrar el archivo de páginas de la memoria virtual al apagar el sistema .............................. 131 Firmar digitalmente la comunicación con el cliente o con el servidor.................................. 131 Otras opciones de seguridad ............................................................................................... 132 Consideraciones de seguridad para los ataques a la red ....................................................... 132 Deshabilitar la generación automática de nombres de archivo 8.3 ....................................... 133 Deshabilitar la creación de Lmhash .................................................................................... 134 Configuración de la seguridad NTLMSSP .......................................................................... 134 Deshabilitación de Autorun ................................................................................................ 135 Directiva de línea de base de listas de control de acceso al registro para servidores miembros ........................................................................................................................................... 135 Directiva de línea de base de listas de control de acceso a archivos para servidores miembros ........................................................................................................................................... 135 Directivas de línea de base de servicios para los servidores miembros ................................ 136 Servicios clave no incluidos en la línea de base de los servidores miembros ....................... 138 Servicio SNMP................................................................................................................... 138 Servicios WMI ................................................................................................................... 138 Servicios de mensajería y de alertas.................................................................................... 138 Directiva de línea de base para el controlador de dominio................................................... 139 4 Directiva de línea de base para las opciones de auditoría y seguridad del controlador de dominio.............................................................................................................................. 139 Directiva de línea de base de servicios para el controlador de dominio ............................... 139 Servicios clave no incluidos en la directiva de línea de base para los controladores de dominio ........................................................................................................................................... 140 Serv. de Prot. simple de transf. de correo (STMP) .............................................................. 140 Mensajería entre sitios........................................................................................................ 140 Servicio de administración de IIS ....................................................................................... 140 Otras tareas de seguridad de línea de base........................................................................... 141 Seguridad de la cuenta de administrador local..................................................................... 141 Seguridad de las cuentas de servicio ................................................................................... 141 Validación de la configuración de línea de base.................................................................. 142 Validación de la configuración de puertos .......................................................................... 142 Seguridad de cada función del servidor............................................................................... 143 Función de servidor de aplicaciones con Windows 2000..................................................... 143 Función de servidor de infraestructuras con Windows 2000................................................ 144 Función de servidor IIS con Windows 2000 ....................................................................... 144 La herramienta IISLockdown ............................................................................................. 145 Otros parámetros de seguridad de la función de servidor IIS............................................... 147 Configuración de restricciones para las direcciones IP y DNS ............................................ 147 Uso de una cuenta anónima local........................................................................................ 147 Implementación de filtros IPSec para servidores host múltiples .......................................... 147 Cambios al entorno recomendado ....................................................................................... 147 Cambios administrativos .................................................................................................... 148 Modificaciones de la seguridad si no se implementa HFNETCHK...................................... 148 Resumen ............................................................................................................................ 149 Más información ................................................................................................................ 149 5. Administrar revisiones.................................................................................................... 150 Terminología...................................................................................................................... 150 Service Packs ..................................................................................................................... 150 Revisiones o QFE............................................................................................................... 151 Revisiones de seguridad ..................................................................................................... 151 Administración de revisiones de la organización................................................................. 151 Evaluación del entorno actual ............................................................................................. 152 Sistemas de actualización de la seguridad ........................................................................... 152 Comunicación .................................................................................................................... 153 Administración de revisiones y de cambios ........................................................................ 153 Kit de herramientas de seguridad de Microsoft ................................................................... 153 Procesos de administración de revisiones............................................................................ 154 Análisis del entorno para detectar revisiones que faltan ...................................................... 155 Microsoft Network Security Hotfix Checker (Hfnetchk)..................................................... 155 Secuencia de comandos de administración de revisiones .................................................... 157 Para instalar y usar el archivo de comandos Hfnetchk.cmd en un Sistema de actualización de la seguridad ........................................................................................................................ 158 Uso de varias listas de servidores........................................................................................ 159 Programación de la secuencia de comandos de administración de revisiones ...................... 159 Otros métodos para determinar los niveles de revisión........................................................ 160 Plan.................................................................................................................................... 160 Clasificación de las revisiones ............................................................................................ 160 Realizar pruebas de las revisiones....................................................................................... 161 Evaluación de la revisión.................................................................................................... 162 Instalación.......................................................................................................................... 163 Operaciones del servidor .................................................................................................... 163 Operaciones de las aplicaciones.......................................................................................... 163 5 Desinstalación .................................................................................................................... 163 Creación de un plan de contingencias ................................................................................. 163 Instalación de las revisiones................................................................................................ 164 Manual ............................................................................................................................... 164 Directiva de grupo.............................................................................................................. 165 Archivos de comandos........................................................................................................ 166 Supervisión ........................................................................................................................ 166 Revisión ............................................................................................................................. 166 Administración de revisiones del lado del cliente................................................................ 166 Windows Update ................................................................................................................ 166 Windows Update Corporate Edition ................................................................................... 167 Microsoft Baseline Security Analyzer................................................................................. 167 Otras herramientas.............................................................................................................. 167 SMS ................................................................................................................................... 167 Herramientas de otros fabricantes ....................................................................................... 168 Resumen ............................................................................................................................ 168 Más información ................................................................................................................ 169 Referencias y vínculos........................................................................................................ 170 6. Auditoría y detección de intrusiones ............................................................................... 170 Auditoría ............................................................................................................................ 171 Cómo activar la auditoría.................................................................................................... 171 Definir la configuración del Registro de sucesos................................................................. 171 Para modificar la configuración del Registro de sucesos con la Directiva de grupo en una unidad organizativa ............................................................................................................ 172 Sucesos para auditar ........................................................................................................... 172 Sucesos de inicio de sesión ................................................................................................. 173 Sucesos de inicio de sesión de cuentas................................................................................ 175 Administración de cuentas.................................................................................................. 176 Acceso a objetos................................................................................................................. 178 Acceso del servicio de directorio ........................................................................................ 180 Uso de privilegios............................................................................................................... 180 Seguimiento de procesos .................................................................................................... 182 Sucesos del sistema ............................................................................................................ 183 Proteger registros de sucesos .............................................................................................. 186 Otras mejores prácticas de auditoría ................................................................................... 187 Programar revisiones regulares de los registros de sucesos ................................................. 187 Revisar otros archivos de registro de aplicaciones............................................................... 188 Supervisar los servicios y controladores instalados ............................................................. 188 Supervisar los puertos abiertos ........................................................................................... 189 Supervisar las intrusiones y los sucesos de seguridad.......................................................... 190 La importancia de la sincronización temporal ..................................................................... 191 Visor de sucesos................................................................................................................. 191 Para definir filtros en el Visor de sucesos ........................................................................... 191 La herramienta Dump Event Log (Dumpel.exe).................................................................. 192 EventCombMT................................................................................................................... 193 Instalar la herramienta ........................................................................................................ 193 Ejecutar la herramienta EventComb.................................................................................... 193 Especificar los registros de sucesos y los tipos de sucesos para la búsqueda........................ 195 Guardar búsquedas ............................................................................................................. 195 Archivos de resultados de la búsqueda................................................................................ 196 Ejemplos de uso de EventCombMT.................................................................................... 196 Para utilizar EventCombMT con el objeto de realizar búsquedas de reinicios de controladores de dominio ......................................................................................................................... 196 Para revisar las entradas del registro ................................................................................... 197 6 Para utilizar EventCombMT con el objeto de realizar búsquedas de Bloqueos de cuentas ... 198 Microsoft Operations Manager ........................................................................................... 199 Soluciones de terceros para la obtención de registros de sucesos......................................... 199 Inspeccionar el acceso HTTP con URLScan ....................................................................... 200 7. Responder a las incidencias ............................................................................................ 202 Minimizar el número y la gravedad de las incidencias de seguridad.................................... 202 Crear el equipo básico de respuesta a incidencias de seguridad informática ........................ 204 Responsable del equipo CSIRT .......................................................................................... 204 Responsable de incidencias del CSIRT ............................................................................... 204 Definir un plan de respuesta a incidencias .......................................................................... 207 Apéndices........................................................................................................................... 207 A. Achivos ......................................................................................................................... 207 B. Servicios de Windows 2000 predeterminados ................................................................ 212 C. Servicios adicionales...................................................................................................... 215 D. Instalación de una infraestructura básica ........................................................................ 216 Crear el entorno de prueba.................................................................................................. 216 Casos de prueba.................................................................................................................. 217 Ayuda de trabajo ................................................................................................................ 230 A. Tabla de análisis de amenazas y vulnerabilidades .......................................................... 230 B. Los 11 problemas de seguridad más frecuentes en el cliente........................................... 231 C. Los 8 problemas de seguridad más frecuentes en el servidor .......................................... 232 D. Ataques y contramedidas ............................................................................................... 233 E. Guía de referencia rápida de respuesta a incidencias....................................................... 238 7 OPERACIONES DE RED SEGURAS CON EL USO DE LOS SERVICIOS DE SEGURIDAD DISTRIBUÍDA DE WINDOWS 2000 En la actualidad, Microsoft® Windows NT® Server ofrece excelentes servicios de seguridad para la administración de cuentas y autenticación de red dentro de una empresa. Las grandes organizaciones requieren flexibilidad para delegar la administración de cuentas y manejar dominios complejos. La seguridad de Internet está relacionada con el manejo del desarrollo de la tecnología de seguridad de clave pública que debe estar integrada con la seguridad Windows. Para cumplir estas necesidades cada vez mayores, Microsoft ha desarrollado los Servicios de seguridad distribuída de Windows 2000. Este documento examina los componentes de los Servicios de seguridad distribuída de Windows 2000 y proporciona detalles sobre su implementación. 8 Introducción El sistema operativo Microsoft® Windows NT® cuenta con excelentes funciones de seguridad para una empresa. Un solo acceso al dominio de Windows NT permite que el usuario acceda a los recursos que se encuentran en cualquier parte de una red corporativa. Las herramientas del administrador fáciles de utilizar para la política de seguridad y administración de cuentas reducen los costes de implementación de Windows NT. El modelo de dominio Windows NT es flexible y soporta una amplia gama de configuraciones de red, desde un solo dominio en una ubicación a dominios multimaestros que hay en todo el mundo. Asimismo, Windows NT sienta las bases para una seguridad integrada para la familia BackOffice® de servicios de aplicación, incluyendo Microsoft Exchange, SQL Server™, SNA Server y Microsoft Systems Management Server. El modelo de seguridad de Windows NT proporciona un marco sólido para la instalación de aplicaciones cliente/servidor para la empresa. En la actualidad, las empresas utilizan cada vez más Internet. Los negocios necesitan interactuar con socios, proveedores y clientes, utilizando las tecnologías basadas en Internet. La seguridad es un punto muy importante para controlar el acceso a los recursos de una red empresarial, intranets y servidores basados en Internet. Cada vez más, las Intranets se están convirtiendo en la manera más eficaz de compartir información para las diversas relaciones empresariales. Ahora, el acceso a la información de negocios no pública por partes externas, se controla a través de la creación de cuentas de usuario para aquellos que forman parte de la amplia familia empresarial. Las asociaciones ayudan a definir las relaciones de confianza que alguna vez se aplicaron únicamente a los empleados que utilizaban activos corporativos, pero que ahora incluyen a más personas. Asimismo, las tecnologías de seguridad también cambian continuamente. Los certificados de clave pública y contraseñas dinámicas son dos áreas de la tecnología que van en aumento con el fin de cumplir con las necesidades de seguridad de nivel más alto del entorno actual. El acceso remoto sobre las redes públicas y el acceso a Internet para la comunicación de negocios interna están controlando la evolución de la tecnología de seguridad. La arquitectura de seguridad de Windows NT tiene una posición privilegiada para aprovechar estos y otros avances tecnológicos. Windows NT combina la facilidad de uso, excelentes herramientas de administración y una infraestructura de seguridad sólida, que soporta tanto a la empresa como a Internet. Aspectos importantes La Seguridad distribuída de Windows 2000 cuenta con varias funciones para simplificar la administración del dominio, mejorar el rendimiento, e integrar la tecnología de seguridad de Internet con base en la criptografía de clave pública. Los aspectos importantes de los Servicios de seguridad distribuída de Windows 2000 incluyen: 9 • La integración con el Directorio Activo de Windows 2000 con el fin de proporcionar una administración de cuenta escalable y flexible para grandes dominios, con control de acceso granular y delegación de administración. • Protocolo de autenticación Kerberos versión 5, un estándar de seguridad en Internet maduro, el cual ha sido implementado como el protocolo predeterminado para la autenticación de red; sienta las bases para la interoperabilidad de la autenticación. • Autenticación sólida mediante el uso de certificados de clave pública, canales seguros basados en el Secure Sockets Layer (SSL) 3.0 y CryptoAPI para proporcionar protocolos estándar en la industria para la integridad y privacidad de datos a través de redes públicas. Este documento describe la siguiente generación de seguridad distribuída de Windows, la cual proporciona las funciones para soportar las demandas empresariales basadas en Internet. La mayor parte del material que aquí se describe se proporciona en Windows 2000, aunque algunas de sus funciones ya han sido implementadas en Windows NT 4.0, como se describe en el texto. Servicios de Seguridad Distribuída de Windows 2000 Existen diversas áreas en las cuales se está adaptando la seguridad en Windows 2000 para soportar a las empresas basadas en Internet. Algunos de estos cambios reflejan los avances en el soporte que se proporciona a grandes organizaciones por medio del uso del Directorio Activo jerárquico de Windows 2000. Otros cambios aprovechan la flexibilidad de la arquitectura de seguridad de Windows para integrar la autenticación, utilizando certificados de clave pública de Internet. A continuación se presenta una lista de las nuevas funciones de seguridad Windows 2000: • El Directorio Activo proporciona almacenamiento para toda la información relativa a políticas de seguridad de dominios e información de cuentas. El Directorio Activo, el cual provee duplicación y disponibilidad de información de cuenta a múltiples Controladores de dominio, está disponible para la administración remota. • El Directorio Activo soporta un espacio de nombre jerárquico para el usuario, grupo e información de cuenta del PC. Las cuentas se pueden agrupar según las unidades organizacionales, en lugar de hacerlo según el espacio del nombre de la cuenta de dominio proporcionado en versiones anteriores de Windows NT. • Se pueden delegar derechos del administrador para crear y administrar cuentas del usuario o de grupo a nivel de unidades organizacionales. • Los derechos de acceso se pueden otorgar a propiedades individuales en objetos del usuario, con el fin de permitir, por ejemplo, que una persona o grupo específico tenga derecho a restablecer contraseñas, pero no a modificar otra información de la cuenta. 10 • La duplicación del Directorio Activo permite actualizaciones a las cuentas en cualquier controlador de dominio, y no únicamente para el controlador de dominio primario (PDC). Se actualizan y sincronizan de forma automática réplicas maestras múltiples de Directorio Activo en otros controladores de dominio, los cuales se conocen como controladores de dominio de respaldo (BDC). • Windows 2000 emplea un nuevo modelo de dominio que utiliza el Directorio Activo para soportar un árbol de dominios jerárquico de niveles múltiples. La administración de relaciones de confianza entre dominios se simplifica a través de confianzas transitorias a lo largo de los árboles que cubren todo el árbol del dominio. • La seguridad de Windows incluye nueva autenticación basada en los protocolos de seguridad estándar de Internet, incluyendo Kerberos versión 5 y Seguridad de niveles de transporte (TLS) para protocolos de seguridad distribuidos, además de soportar protocolos de autenticación del administrador LAN de Windows NT para compatibilidad. • La implementación de los protocolos de seguridad de canal seguros (SSL 3.0/TLS) soporta la autenticación sólida del cliente mediante la relación de credenciales del usuario en la forma de certificados de clave pública para las cuentas Windows NT existentes. Se utilizan herramientas de administración comunes para administrar la información de las cuentas y el control de acceso, ya sea utilizando la autenticación secreta compartida o la seguridad de clave pública. • Windows 2000 soporta el uso opcional de tarjetas inteligentes para la conexión interactiva, además de las contraseñas. Las tarjetas inteligentes soportan criptografía y almacenamiento seguro para claves y certificados privados, habilitando una autenticación sólida desde el escritorio al dominio. • Windows 2000 incluye Microsoft Certificate Server para que las organizaciones emitan certificados X.509 versión 3 a sus empleados o socios de negocios. • Esto incluye la introducción de CryptoAPI para la administración de certificados y módulos para manejar certificados de clave pública, incluyendo certificados de formato estándar emitidos por cualquier Autoridad de certificado comercial (CA), CA de terceros o Microsoft Certificate Server, incluido en Windows. Los administradores del sistema definen cuáles CAs son de confianza en su entorno y, de esta forma, cuáles certificados se aceptan para la autenticación del cliente y el acceso a los recursos. • Los usuarios externos que no tienen cuentas Windows 2000 pueden ser autenticados utilizando certificados de clave pública y relacionados a una cuenta Windows existente. Los derechos de acceso definidos para la cuenta Windows determinan los recursos que los usuarios externos pueden utilizar en el sistema. La autenticación del cliente, utilizando 11 certificados de clave pública, permite que Windows 2000 autentique usuarios externos, con base en certificados emitidos por Autoridades de certificados acreditadas. • Los usuarios de Windows 2000 cuentan con herramientas fáciles de usar y diálogos de interfaz comunes para la administración de pares de claves pública/privada y de certificados que se utilizan para acceder a los recursos basados en Internet. El almacenamiento de credenciales de seguridad personales, las cuales utilizan el almacenamiento basado en disco seguro, se transportan fácilmente con el protocolo estándar en la industria propuesto, Intercambio de información personal. Asimismo, el sistema operativo ha integrado soporte para los dispositivos de tarjeta inteligente. • La tecnología de encriptación está integrada dentro del sistema operativo en muchas formas, con el fin aprovechar el uso de firmas digitales para proporcionar flujos de datos autenticados. Además de los controles firmados ActiveX™ y Clases Java para Internet Explorer, Windows 2000 utiliza firmas digitales para la integridad de imágenes de una variedad de componentes del programa. Los desarrolladores internos también pueden crear software firmado para distribución y protección de virus. Además de estos cambios, se espera que terceros cuenten con servicios de autenticación de contraseña dinámicos en Windows 2000 Server, e integren contraseñas dinámicas con la autenticación de dominio de Windows 2000. Las API y la documentación para soportar estos productos de terceros están disponibles en SDK de la plataforma Microsoft. El Directorio Activo y la Seguridad Actualmente, la información de cuentas de Windows NT se mantiene utilizando una parte de registro segura en los controladores de dominio. Al utilizar dominio de confianza y acceso por autenticación, una jerarquía de dos niveles de dominios proporciona flexibilidad para organizar la administración de cuentas y los servidores de recursos. Sin embargo, dentro de un dominio, las cuentas se mantienen en un espacio de nombre plano, sin ninguna organización interna. Los Servicios de seguridad distribuída de Windows 2000 utilizan el Directorio Activo como el repositorio para la información de cuentas. El Directorio Activo proporciona una mejora importante sobre la implementación basada en el registro en las áreas de rendimiento y escalabilidad, y ofrece un entorno administrativo rico en funciones. El siguiente diagrama muestra la estructura jerárquica para un árbol de dominios de Windows 2000 y el contexto de nombre jerárquico dentro de cada dominio que utiliza unidades organizacionales (OU) como contenedores de objetos de directorio. Jerarquía de dominio: Árbol de dominio • Jerarquía de la unidad organizacional dentro de un dominio • Usuarios, grupos, máquinas, impresoras, etc. 12 Ventajas de la administración de cuentas de Directorio Activo Las ventajas de integrar la administración de cuentas de seguridad con el Directorio Activo son: • Cuentas para usuarios, grupos y máquinas, que pueden ser organizadas en los contenedores de directorio denominados unidades organizacionales (OU). Un dominio puede tener cualquier número de OU organizadas en espacios de nombre estructurados como un árbol. Las empresas pueden organizar el espacio de nombre para información de cuentas, con el fin de representar los departamentos y organizaciones en la compañía. Asimismo, las cuentas del usuario, al igual que las OU, son objetos de directorio que se pueden renombrar fácilmente dentro de un árbol de dominio, a medida que cambia la organización. • El Directorio Activo soporta un número mucho mayor de objetos de usuario (más de 1 millón de objetos) con un mejor rendimiento que el registro. La dimensión del dominio individual ya no estará limitada por el rendimiento del repositorio de seguridad. Un árbol de dominios conectados puede soportar estructuras organizacionales mucho más grandes y complejas. • La administración de la información de cuentas se mejora utilizando las herramientas gráficas avanzadas para la administración del Directorio Activo, así como a través del soporte OLE DS para lenguajes de script. Se pueden implementar tareas comunes utilizando scripts bach para automatizar la administración. • Los servicios de duplicación del directorio permiten realizar múltiples copias de la información de cuentas, en las cuales se pueden realizar actualizaciones en cualquier copia, no únicamente en el controlador de dominio primario designado. El The Lightweight Directory Access Protocol (LDAP) y el soporte de sincronización de directorio proporcionan los mecanismos para vincular el directorio de Windows con los demás directorios de la empresa. 13 Almacenar la información de la cuenta de seguridad en el Directorio Activo significa que los usuarios y grupos están representados como objetos en el directorio. El acceso de lectura y escritura a los objetos en el directorio se puede otorgar al objeto en su totalidad, o a propiedades individuales del mismo. Los administradores cuentan con un control granular sobre quién puede actualizar la información del usuario o grupo. Por ejemplo, se le puede otorgar a un grupo de operadores de telecomunicaciones el acceso de escritura únicamente para las propiedades de cuenta del usuario relacionadas con el equipo telefónico de oficina, sin requerir privilegios de Operador de cuenta o Administrador. Asimismo, el concepto de un grupo se simplifica, debido a que los grupos locales y globales están representados por objetos de grupo en el directorio. Las interfaces de programación existentes para los miembros de grupos locales aún siguen soportadas para compatibilidad completa hacia atrás. Sin embargo, los grupos definidos en el directorio pueden utilizarse para el control de acceso a los recursos en todo el dominio, o únicamente para fines de administración local en el controlador de dominio. Relación entre los servicios de directorio y la seguridad Existe una relación fundamental entre el Directorio Activo y los Servicios de seguridad integrados en el sistema operativo Windows 2000. El Directorio Activo almacena la información de políticas de seguridad de dominio, como son las restricciones de contraseña en todo el dominio y los privilegios de acceso al sistema, que afectan directamente el uso del sistema. Los objetos relacionados con la seguridad en el directorio deben administrarse de forma segura, con el fin de evitar cambios no autorizados que afecten la totalidad de la seguridad del sistema. El sistema operativo Windows 2000 implementa el modelo de seguridad basado en el objeto y el control de acceso a todos los objetos del Directorio Activo. Cada objeto que se encuentra en el Directorio Activo tiene un descriptor de seguridad único que define las actualizaciones de acceso que se requieren para leer o actualizar las propiedades de un objeto. El siguiente diagrama muestra la relación fundamental entre el Directorio Activo y los servicios de seguridad del sistema operativo. Servicios de directorio y seguridad 14 El Directorio Activo utiliza la personificación y verificación de acceso de Windows 2000 para determinar si un cliente del Directorio Activo puede leer o actualizar el objeto deseado. Esto significa que las solicitudes del cliente LDAP al directorio requieren que el sistema operativo aplique el control de acceso, en lugar de que el Directorio Activo mismo tome las decisiones de control de acceso. El modelo de seguridad de Windows 2000 proporciona una implementación unificada y consistente de control de acceso a todos los recursos del dominio, en base a la pertenencia al grupo. Los componentes de seguridad de Windows 2000 pueden confiar en la información relacionada con la seguridad almacenada en el directorio. Por ejemplo, el servicio de autenticación de Windows 2000 almacena la información de la contraseña encriptada en una parte segura de los objetos del usuario de directorio. El sistema operativo asegura que la información de la política de seguridad se almacene de forma segura y que las restricciones de cuenta o permisos de grupo no puedan ser cambiados por nadie sin acceso autorizado. Además, la información de política de seguridad para toda la administración del dominio se mantiene en el directorio. Esta relación fundamental de Seguridad y el Directorio Activo se logra únicamente mediante la integración completa del directorio con el sistema operativo Windows 2000 y no puede realizarse de otra manera. Relaciones de confianza entre dominios Los dominios Windows 2000 se pueden organizar en árboles de dominio jerárquicos. Las relaciones de confianza entre los dominios permiten a los usuarios con cuentas definidas en un 15 dominio que sean autenticadas por los servidores de recursos en otro dominio. En Windows NT 4.0 y versiones anteriores, las relaciones de confianza entre dominios se definen por cuentas de dominio de confianza, unidireccionales, entre los controladores de dominio. La administración de relaciones de confianza entre los dominios de cuenta y los dominios de recursos en una red grande es una tarea compleja. El Directorio Activo soporta dos formas de relaciones de confianza: • Las relaciones de confianza unidireccionales explícitas a los dominios Windows NT 4.0. • Administración transitoria bidireccional entre los dominios que forman parte del árbol de dominios de Windows 2000. El siguiente diagrama muestra los dos estilos de relaciones administrativas. Las confianzas transitorias entre los dominios simplifican la administración de cuentas de confianza entre los dominios. Los dominios que son miembros del árbol de dominio definen una relación de confianza bidireccional con el dominio predominante en el árbol. Todos los dominios confían de forma implícita en los demás dominios del árbol. Si existen dominios específicos que no participen en la confianza bidireccional, se pueden definir cuentas de confianza unidireccional explícitas. Para las organizaciones que cuentan con múltiples dominios, el número total de relaciones de confianza unidireccionales explícitas se reduce en gran medida. Delegación de administración La delegación de administración es una herramienta valiosa para que las organizaciones limiten la administración de seguridad para que se aplique únicamente a subgrupos definidos en el dominio de toda la organización. El requerimiento importante es otorgar los derechos de 16 administrar un grupo pequeño de usuarios o grupos dentro de su área de responsabilidad y, al mismo tiempo, no dar permisos para administrar cuentas en otras partes de la organización. La delegación de responsabilidad para crear nuevos usuarios o grupos se define en el nivel de una unidad organizacional (OU), o contenedor, donde se crean las cuentas. Los administradores de grupo para una unidad organizacional no tienen necesariamente la capacidad de crear y administrar cuentas para otra unidad organizacional dentro de un dominio. Sin embargo, las configuraciones de las políticas en todo el dominio y los derechos de acceso definidos en los niveles más altos en el árbol de directorio pueden aplicarse a través del árbol, utilizando la herencia de derechos de acceso. Existen tres formas de definir la delegación de las responsabilidades de administración: • Delegar permisos para cambiar propiedades en un contenedor particular, como es LocalDomainPolicies del objeto de dominio mismo. • Delegar permisos para crear y eliminar objetos hijo de un tipo específico debajo de una OU, tales como usuarios, grupos o impresoras. • Delegar permisos para actualizar propiedades específicas en objetos hijo de un tipo específico por debajo de una OU; por ejemplo, el derecho de establecer contraseñas en objetos del usuario. La interfaz de Administración de servicio de directorio facilita la visualización de la delegación de información definida para los contenedores. La suma de una nueva delegación de permisos es fácil de llevar a cabo mediante la selección de la persona a la que se desea delegarle el permiso y posteriormente asignar cuáles permisos son necesarios. Al integrar el repositorio de cuenta de seguridad con el Directorio Activo se logran beneficios reales para administrar una empresa. El resultado directo es el rendimiento, facilidad de administración y escalabilidad para grandes organizaciones. Las empresas basadas en Internet pueden utilizar árboles de dominio y OU jerárquicas para organizar cuentas para socios de negocios, clientes frecuentes o proveedores con derechos de acceso específicos al sistema. Derechos de acceso granulares Por lo regular, las grandes organizaciones dependen de varios individuos o grupos para asegurar y administrar la infraestructura de cuentas de la red. Necesitan la capacidad de otorgar derechos de acceso a operaciones específicas, como son la reconfiguración de contraseñas del usuario o la deshabilitación de cuentas para grupos específicos, sin otorgar también permisos para crear nuevas cuentas o cambiar otras propiedades de las cuentas del usuario. La arquitectura de seguridad de los objetos del Directorio Activo utiliza los descriptores de seguridad Windows 2000 para controlar el acceso a objetos. Cada objeto que se encuentra en el directorio cuenta con un descriptor de seguridad único. La Lista de control de acceso (ACL) en el descriptor de seguridad es una lista de entradas que otorgan o niegan derechos de acceso 17 específicos a individuos o grupos. Los derechos de acceso pueden ser otorgados o negados con diferentes niveles de enfoque en el objeto. Los derechos de acceso se pueden definir en cualquiera de los siguientes niveles: • Aplicar a los objetos como un todo, lo cual aplica a todas las propiedades del objeto. • Aplicar a una agrupación de propiedades definida de acuerdo con los grupos de propiedades que hay dentro de un objeto. • Aplicar a una propiedad individual del objeto. El permiso de acceso de lectura/escritura uniforme a todas las propiedades de un objeto es el permiso de acceso predeterminado para el creador del objeto. Otorgar o negar los permisos de acceso al objeto a un grupo de propiedad es una manera conveniente para definir permisos para un grupo de propiedades relacionadas. La agrupación de propiedades se define de acuerdo con el atributo del grupo de propiedad de una propiedad en el esquema. La relación de grupo de propiedad se puede personalizar cambiando el esquema. Por último, la definición de los derechos de acceso en un nivel según la propiedad, proporciona el nivel más alto de granularidad de permisos. La definición de acceso por propiedad está disponible en todos los objetos del Directorio Activo. Asimismo, los objetos del contenedor en el directorio soportan acceso granular con respecto a las personas que tienen permisos para crear objetos hijos y qué tipo de objetos hijos pueden crearse. Por ejemplo, el control de acceso definido en una unidad organizacional (OU) puede definir la persona que tiene autorización para crear objetos de Usuario (cuentas) en este contenedor. Otra entrada en el control de acceso para la OU puede definir quién tiene autorización de crear objetos de impresora. El control de acceso granular en los contenedores de directorio es una manera eficaz de mantener la organización del espacio de nombres del directorio. Una nueva implementación del Editor de Lista de control de acceso (ACL), el control de diálogo común para la visualización o cambio de autorizaciones de seguridad del objeto, proporciona una interfaz fácil de utilizar para definir derechos de acceso a los objetos de Directorio Activo, según el grupo de propiedades o propiedades individuales. De igual forma, el editor ACL soporta la definición de derechos de acceso, delegados en los objetos del contenedor que fluyen a los subobjetos que se encuentran en alguna parte del árbol del directorio. Herencia de los derechos de acceso Heredar los derechos de acceso se refiere a la manera en que la información de control de acceso definida en los niveles más altos de los contenedores del directorio fluye a los subcontenedores y ramas de objetos. Existen, por lo general, dos modelos para la implementación de derechos de acceso heredados: herencia dinámica y estática. 18 La herencia dinámica determina los derechos de acceso efectivos para un objeto mediante la evaluación de permisos definidos de forma explícita en el objeto y aquellos definidos para todos los objetos principales en el directorio. Esto permite flexibilidad para cambiar el control de acceso en algunas partes del árbol del directorio, al realizar cambios a un contenedor específico que afecta de forma automática todos los subcontenedores de los objetos de ramas. A cambio de esta flexibilidad se ofrece el coste de rendimiento para evaluar los derechos de acceso efectivos al momento en que un cliente solicita lectura/escritura a un objeto de directorio específico. Windows 2000 implementa una forma de herencia estática de los derechos de acceso, conocida como herencia Crear tiempo. Se puede definir la información de control de acceso que fluye hasta los objetos hijo del contenedor. Cuando se crea el objeto hijo, los derechos heredados de un contenedor se fusionan con los derechos de acceso predeterminados en el nuevo objeto. Cualquier cambio realizado a los derechos de acceso heredados en los niveles más altos del árbol debe propagarse hacia abajo, hasta todos los objetos hijo afectados. Los nuevos derechos de acceso heredados se propagan mediante el Directorio Activo hasta los objetos para los cuales aplican, en base con las opciones de la manera en que se definen los nuevos derechos. La verificación del rendimiento para el control de acceso es muy rápida, utilizando el modelo de herencia estático de los derechos de acceso. El sistema operativo está diseñado para optimizar las verificaciones de acceso que son operaciones frecuentes y necesarias, no sólo para el acceso del objeto de directorio, sino para el objeto del sistema de archivo y todos los demás objetos del sistema Windows 2000. Múltiples Protocolos de Seguridad Windows 2000 soporta múltiples protocolos de seguridad de red, debido a que cada protocolo proporciona ya sea compatibilidad para los clientes existentes, mecanismos de seguridad más efectivos, o funciones de interoperabilidad para redes heterogéneas como Internet. Existen varios protocolos de autenticación actualmente en uso en las redes corporativas y la arquitectura Windows 2000 no limita cuáles protocolos pueden ser soportados. Un protocolo de seguridad que se ajuste a todas las necesidades sería más simple, pero las configuraciones de red desde redes pequeñas de oficina a proveedores de contenido de Internet a gran escala no comparten los mismos requerimientos de seguridad. Los clientes necesitan tener opciones sobre cómo integrar la nueva tecnología de seguridad, como son contraseñas dinámicas o criptografía de clave pública, dentro de su entorno informático. Windows 2000 está diseñado para soportar varios protocolos de seguridad, un elemento esencial para el entorno de informática distribuída que existe en la actualidad. Al utilizar las API de seguridad Win32 para todo tipo de fines, el sistema operativo aísla las aplicaci ones soportadas de los detalles de protocolo de seguridad diferentes disponibles. La interfaz de aplicación de nivel 19 más alto proporcionada por RPC y DCOM autenticados permiten abstracciones con base en los parámetros de interfaz para utilizar los servicios de seguridad. La infraestructura de seguridad Windows 2000 soporta los siguientes protocolos de seguridad primarios: • El protocolo de autenticación Windows NT LAN Manager (NTLM) se utiliza en Windows NT 4.0 y versiones anteriores de Windows NT. NTLM seguirá recibiendo soporte y se utilizará para la autenticación de paso a través de la red, acceso de archivo remoto y conexiones RPC autenticadas para versiones anteriores de Windows NT. • El protocolo de autenticación Kerberos Versión 5 reemplaza a NTLM como el protocolo de seguridad primario para acceder a los recursos dentro o a través de los dominios Windows 2000. El protocolo de autenticación Kerberos es un estándar en la industria ya conocido, que tiene las ventajas de autenticación de red Windows. Algunos de los beneficios del protocolo Kerberos son la autenticación mutua, tanto del cliente como del servidor, carga del servidor reducida durante el establecimiento de la conexión y soporte para la delegación de autorización de clientes a servidores a través del uso de mecanismos proxy. • La Autenticación de contraseña distribuída (DPA) es el protocolo de autenticación secreta distribuída que utilizan las organizaciones que pertenecen a Internet más grandes, tales como son MSN y CompuServe. Este protocolo de autenticación forma parte de los servicios Microsoft Comercial Internet System (MCIS) y está diseñado de forma específica para que los usuarios utilicen la misma contraseña de acceso en Internet para conectarse a cualquier número de sitios en Internet que forman parte de la misma organización. Los servidores de contenido de Internet utilizan el servicio de autenticación MCIS como un servicio de Internet backend, y los usuarios pueden conectarse a múltiples sitios sin tener que volver a introducir sus contraseñas. • Los protocolos basados en clave pública proporcionan privacidad y confiabilidad sobre Internet. SSL es el estándar de facto actual para las conexiones entre los exploradores de Internet y los servidores de información en Internet. (Una definición próxima del protocolo estándar IETF basado en SSL3 se conoce actualmente como el Protocolo de seguridad de nivel de transporte o TLS). Estos protocolos, que utilizan certificados de clave pública para autenticar los clientes y servidores, dependen de una infraestructura de clave pública para uso general. Windows NT 4.0 proporciona servicios de seguridad de canal seguros que implementan los protocolos SSL/PCT. La seguridad de Windows 2000 cuenta con soporte de funciones más avanzadas para protocolos de clave pública, los cuales se describen posteriormente en este documento. La seguridad empresarial depende de tener la flexibilidad de utilizar los mecanismos de seguridad correctos, cuando sea necesario. La informática empresarial seguirá dependiendo de una amplia gama de servicios de red proporcionados por servidores de archivo e impresión 20 remotos, aplicaciones empresariales y servidores de datos, además de entornos de data warehousing y de procesamiento de transacción. El soporte para protocolos múltiples de seguridad de red permite que Windows 2000 Professional y Windows 2000 Server alojen una variedad de servicios de red, además de las tecnologías basadas en Internet. El diagrama siguiente muestra el soporte de arquitectura para múltiples protocolos de seguridad implementados en Windows 2000, utilizando la Interfaz del proveedor de soporte de seguridad (SSPI). Arquitectura para servicios de autenticación múltiple La interfaz de proveedor de soporte de seguridad es una API del sistema Win32 utilizada por varias aplicaciones y servicios del sistema, por ejemplo, Internet Explorer (IE) e Internet Information Server (IIS), para aislar los protocolos de nivel de aplicación de los protocolos de seguridad utilizados para la autenticación de red. Los proveedores de seguridad utilizan diferentes credenciales para autenticar al usuario, ya sea con certificados de secreto compartido o clave pública. Los protocolos de seguridad interactúan con diferentes servicios de autenticación y almacenes de información de cuentas. • El proveedor de seguridad NTLM utiliza el servicio de autenticación MSV1_0 y el servicio NetLogon en un controlador de dominio para autenticación del cliente e información de autorización. • El proveedor de seguridad Kerberos se conecta a un Centro de distribución de claves en línea (KDC) y la cuenta Directorio Activo se almacena para los resguardos de sesión. • DPA utiliza los servicios de seguridad MCIS para la autenticación de acceso e información de acceso específica del servidor. • Los servicios de canal seguros están basados en certificados de clave pública emitidos por autoridades certificadas de confianza; no requieren un servidor de autenticación en línea. 21 Interfaz del Servidor de Soporte de Seguridad Las APIs de seguridad de Windows para la autenticación de red están definidas a través de la Interfaz del proveedor de soporte de seguridad (SSPI), documentada en la plataforma SDK. La SSPI se comunica con una API de Win32 con base en la Interfaz del programa de aplicación de servicios de seguridad genérico (GSS-API) y proporciona una abstracción de interfaz similar para la administración de contexto de seguridad. Las aplicaciones y servicios Windows 2000 utilizan la SSPI para aislar los protocolos de nivel de aplicación de los detalles de los protocolos de seguridad de red. Windows 2000 soporta la interfaz SSPI para disminuir el código de nivel de aplicación necesario para soportar protocolos múltiples de autenticación. SSPI proporciona una abstracción genérica para soportar múltiples mecanismos de autenticación basados en protocolos de secreto compartido o clave pública. Las aplicaciones que utilizan la seguridad Windows 2000 integrada aprovechan al máximo la modularidad proporcionada por SSPI mediante la solicitud de directorios de rutina SSPI o mediante el uso de protocolos de administración de conexión de red de nivel más alto, proporcionados por RPC o DCOM autenticados. Protocolo de Autenticación Kerberos El protocolo de autenticación Kerberos define las interacciones entre un cliente y un Servicio de autenticación de red conocido como Centro de distribución de claves (KDC). Windows 2000 implementa un KDC como el servicio de autenticación en cada controlador de dominio. El dominio Windows 2000 es equivalente a un territorio Kerberos, pero continúa siendo referido como un dominio. La implementación de Kerberos en Windows 2000 está basada en la definición RFC 1510 de Internet del protocolo Kerberos. El tiempo de ejecución del cliente Kerberos se implementa como un proveedor de seguridad Windows 2000 basado en la SSPI. La autenticación inicial de Kerberos se integra con la arquitectura WinLogon de una sola firma. El servidor Kerberos (KDC), integrado con los servicios de seguridad Windows existentes que se ejecutan en el controlador de dominio, utiliza el Directorio Activo como la base de datos de cuentas para usuarios (principales) y grupos. El protocolo de autenticación Kerberos mejora las funciones de seguridad subyacentes de Windows 2000 y proporciona las funciones siguientes: • Rendimiento de autenticación de servidor más rápido durante el establecimiento de la conexión inicial. El servidor de aplicaciones no se tiene que conectar al controlador de dominio para autenticar al cliente. Esto permite a los servidores de aplicaciones escalar mejor, al manejar un mayor número de solicitudes de conexión de clientes. • Delegación de autenticación para arquitecturas de aplicación cliente/servidor de niveles múltiples. Cuando un cliente se conecta a un servidor, el servidor personifica al cliente en 22 el sistema. Sin embargo, si el servidor necesita realizar una conexión de red a otro servidor backend para completar la transacción del cliente, el protocolo Kerberos permite la delegación de autenticación para que el primer servidor se conecte con otro servidor a nombre del cliente. La delegación permite que el segundo servidor también personifique al cliente. • Relaciones de administración transitorias para la autenticación entre dominios. Los usuarios pueden autenticar los dominios en cualquier parte del árbol de dominio, ya que los servicios de autenticación (KDC) en cada dominio proporcionan confianza a los resguardos emitidos por otros KDC en el árbol. La administración transitoria simplifica la administración de dominio para grandes redes con dominios múltiples. El protocolo de autenticación Kerberos versión 5 definido en RFC 1510 ha pasado por amplios procesos de revisión en la industria y es bien conocido en los grupos de interesados en la seguridad. Antecedentes de Kerberos Kerberos es un protocolo de autenticación de secreto compartido, debido a que el usuario y el KDC conocen la contraseña del usuario o, en el caso del KDC, la contraseña encriptada unidireccional. El protocolo Kerberos define una serie de intercambios entre los clientes, el KDC y los servidores, para obtener y utilizar resguardos Kerberos. Cuando un usuario inicia una conexión a Windows, el SSP de Kerberos obtiene un resguardo Kerberos inicial (TGT) basado en un verificador encriptado de la contraseña del usuario. Windows 2000 almacena la TGT en el caché del resguardo en la estación de trabajo relacionada con el contexto de acceso del usuario. Cuando un programa del cliente trata de tener acceso a un servicio de red, el tiempo real Kerberos verifica el caché del resguardo para un resguardo de sesión válido para el servidor. Si un resguardo no está disponible, la TGT se envía en una solicitud al KDC para un resguardo de sesión que permita el acceso al servidor. El resguardo de sesión se añade al caché del resguardo y puede volver a utilizarse para conexiones futuras al mismo servidor hasta que el resguardo expire. El período de expiración del resguardo lo define la política de seguridad de dominio y por lo regular se establece para ocho horas. Si el resguardo de sesión expira en la mitad de una sesión activa, el proveedor de seguridad Kerberos regresa los valores de error adecuados que permiten que el cliente y el servidor vuelvan a generar el resguardo, generar una nueva clave de sesión y reanudar la conexión. El siguiente diagrama muestra la relación que existe entre el cliente, el KDC y el servidor de aplicaciones utilizando el protocolo de autenticación Kerberos. 23 Descripción general del protocolo de autenticación Kerberos El resguardo de sesión Kerberos se presenta al servicio remoto durante el mensaje de conexión inicial. Algunas partes del resguardo de sesión se encriptan utilizando una clave secreta compartida entre el servicio y el KDC. El servidor puede autenticar rápidamente al cliente verificando el resguardo de sesión sin ir al servicio de autenticación, ya que el tiempo real Kerberos para el servidor ha guardado una copia en la memoria de la clave secreta del servidor. La configuración de la conexión de sesión es mucho más rápida del lado del servidor que la autenticación NTLM. Con NTLM, el servidor obtendría las credenciales del usuario y después tendría que volver a autenticar al usuario a través del controlador de dominio, como parte del establecimiento de una conexión. Los resguardos de sesión Kerberos contienen una clave de sesión única creada por el KDC para que sea utilizada para la encriptación simétrica de la información de autenticación y los datos transferidos entre el cliente y el servidor. En el modelo Kerberos, se utiliza el KDC como un tercero de confianza en línea para generar una clave de sesión. Los servicios de autenticación en línea son muy eficaces para los servicios de aplicación distribuída disponibles en el entorno de red semejantes a un campus. Integración de Kerberos El protocolo Kerberos se integra totalmente con la arquitectura de seguridad Windows 2000 para la autenticación y el control de acceso. La conexión de dominio Windows inicial se proporciona con WinLogon. WinLogon utiliza el proveedor de seguridad Kerberos para obtener un resguardo Kerberos inicial. Otros componentes del sistema operativo, como son el redireccionador, utilizan la interfaz SSPI para que el proveedor de seguridad Kerberos obtenga un resguardo de sesión para conectarse al servidor SMB para acceso de archivo remoto. 24 El protocolo Kerberos versión 5 define un campo encriptado en el resguardo de sesión para portar datos de autorización, pero el uso del campo se deja a las aplicaciones. Windows 2000 utiliza los datos de autorización en los resguardos Kerberos para portar los ID de seguridad Windows que representan la pertenencia del usuario y grupo. El proveedor de seguridad Kerberos del lado del servidor de una conexión utiliza los datos de autorización para crear un registro de acceso de seguridad Windows que representa al usuario en ese sistema. El servidor sigue el modelo de personificación del cliente de seguridad Windows, utilizando el registro de acceso que representa al cliente, antes de intentar acceder a los recursos locales protegidos por las Listas de Control de Acceso (ACL). El protocolo Kerberos versión 5 soporta la delegación de autenticación utilizando los indicadores proxy y forwarding en los resguardos de sesión. Windows 2000 utiliza la función de delegación para permitir que los servidores obtengan otro resguardo de sesión para conectarse a servidores remotos a nombre del cliente. Interoperabilidad Kerberos El protocolo Kerberos versión 5 se implementa para una variedad de sistemas y se utiliza para proporcionar un servicio de autenticación único en una red distribuida. La interoperabilidad Kerberos proporciona un protocolo común que permite una base de datos de cuentas (posiblemente duplicada) para la autenticación de los usuarios en todas las plataformas informáticas de la empresa, para que puedan acceder a todos los servicios en un entorno heterogéneo. La interoperabilidad Kerberos se basa en las siguientes características: • Un protocolo de autenticación común utilizado para identificar el usuario o servicio a través del nombre principal en una conexión de red. • La capacidad de definir relaciones administrativas entre los territorios de Kerberos y de generar resguardos referentes a las solicitudes entre territorios. • Implementaciones que soportan los Requerimientos de interoperabilidad que se definen en el RFC 1510, relacionadas con las opciones de encriptar, algoritmos de revisión de suma, autenticación mutua y otras opciones de resguardo. • Soporte para los formatos token de seguridad Kerberos versión 5, para el establecimiento del contexto e intercambio por mensaje, como lo define el grupo de trabajo de Tecnología de autenticación común de IETF 3. El nombre principal en un resguardo Kerberos se utiliza para autentificar la identidad del usuario, pero la información de autorización adicional puede ser manejada en el sistema local para el control de acceso. La autenticación basada en la identidad proporciona un nivel elevado de interoperabilidad para los sistemas que soportan el protocolo Kerberos versión 5; sin embargo, no soporta la autorización del usuario. El protocolo Kerberos ofrece el transporte de 25 datos de autorización, pero el contenido en este campo se considera específico para el servicio de la aplicación. La implementación Microsoft del protocolo Kerberos soporta las características de interoperabilidad suficientes para la autenticación basada en la identidad. Además, Microsoft integra datos de autorización en forma de pertenencia al grupo Windows 2000 en los resguardos Kerberos, para transmitir la información de control de acceso a los servicios Windows 2000. La representación nativa de los datos de autorización se encuentra en los ID de seguridad Windows. Los servicios de Windows 2000 tienen cuentas de servicio definidas en el Directorio Activo, las cuales definen el secreto compartido que utiliza el KDC para encriptar los resguardos de sesión. Los clientes que intentan conectarse a los servicios Windows 2000 obtienen un resguardo de sesión para el servidor de destino del KDC que se encuentra en el dominio donde se define la cuenta de servicio. El proveedor de seguridad Kerberos que soporta un servicio Windows 2000 espera encontrar datos de autorización en los resguardos de sesión que se utilizan para crear un registro de acceso de seguridad. El servicio Windows 2000 personifica el contexto de seguridad del cliente, con base en los datos de autorización proporcionados en el resguardo de sesión. Los clientes que obtienen los resguardos TGT Kerberos iniciales del KDC en los sistemas que no son Windows 2000, utilizan el mecanismo de referencia de Kerberos para solicitar un resguardo de sesión del KDC en el dominio Windows 2000 Service. El resguardo de referencia se crea mediante relaciones de confianza entre territorios entre los KDC. Las solicitudes de resguardos que se originan a partir del servicio de autenticación Kerberos MIT en general no contienen datos de autorización. Cuando los resguardos de sesión no contienen datos de autorización, el proveedor de seguridad Kerberos en Windows 2000 trata de utilizar el nombre principal del resguardo y crear un registro de acceso de seguridad para una cuenta de usuario designado o utilizar una cuenta predeterminada definida para este fin. Actualmente Microsoft sigue investigando algunos aspectos de interoperabilidad con diferentes configuraciones Kerberos y seguirá dicho trabajo con un enfoque en la interoperabilidad total con Kerberos. Los Servicios de Seguridad DCE también están estratificados en el protocolo Kerberos. Los Servicios de Autenticación DCE utilizan la representación RPC de los mensajes de protocolo Kerberos. Además, DCE utiliza el campo de datos de autorización en los resguardos Kerberos para transmitir Certificados de atributos de privilegios extendidos (EPAC) que definen la identidad del usuario y la pertenencia al grupo. EPAC se utilizan como ID de seguridad Windows para la autorización y control de acceso del usuario. Los servicios Windows 2000 no pueden traducir los EPAC DCE en identificadores de usuario y grupo de Windows 2000. Esto no está relacionado con la interoperabilidad Kerberos, sino con la interoperabilidad que existe entre DCE y la información de control de acceso Windows 2000. Microsoft investigará las maneras de relacionar la autorización DCE con el modelo de seguridad Windows 2000. 26 Extensiones Kerberos para clave pública Asimismo, Windows 2000 implementa extensiones para que el protocolo Kerberos soporte autenticación basada en pares de clave privada/pública además de claves secretas compartidas. Las extensiones de autenticación de clave pública permiten a los clientes solicitar una TGT inicial utilizando la clave privada, al tiempo que KDC verifica la solicitud utilizando la clave pública obtenida desde un certificado X.509 almacenado en el objeto del usuario en el Directorio Activo. El certificado del usuario podría ser emitido por una Autoridad de certificados de terceros, como Digital ID de VeriSing o Microsoft Certificate Server en Windows 2000. Después de la autenticación de clave privada inicial los protocolos Kerberos estándar para la obtención de un resguardo de sesión se utilizan para conectarse a los servicios de red. Una propuesta de ampliar la especificación de protocolo Kerberos con el fin de proporcionar un método para el uso de criptografía de clave pública en la autenticación inicial ha sido presentada al grupo de trabajo IETF para su revisión. Actualmente, Microsoft participa en los procesos de estándares IETF y pretende soportar las extensiones de protocolo estándar para clave pública. Las extensiones de autenticación de clave pública para el protocolo Kerberos sientan las bases para una autenticación de red, utilizando la tecnología de tarjeta inteligente. Windows 2000 permite a los usuarios conectarse a una estación de trabajo mediante el uso de una tarjeta inteligente. Próximamente existirán varias opciones para obtener certificados para los usuarios, dependiendo de sus afiliaciones a organizaciones o requerimientos de trabajo. Windows 2000 proporciona un Certificate Server a las organizaciones que deseen emitir certificados de clave pública a sus usuarios sin depender de los servicios CA comerciales. La política del certificado es clara y directa: los certificados se emiten a los usuarios que cuentan con autenticación utilizando credenciales de cuenta de dominio válidas. En la sección siguiente se describe la forma en que dichos certificados se pueden utilizar para el acceso a los recursos de Windows 2000 a través de intranet o Internet. Seguridad de Internet para Windows 2000 Microsoft está desarrollando una infraestructura de seguridad de clave pública a fin de integrar la seguridad de clave pública con la seguridad de Windows 2000. La criptografía de clave pública es la tecnología de seguridad que permite una seguridad sólida para las comunicaciones empresariales y de Internet. Las tecnologías de seguridad de Internet de Microsoft incluyen un Certificate Server, un proveedor de seguridad de canal seguro que implementa los protocolos SSL/TLS, el protocolo de pago seguro SET para las transacciones de tarjeta de crédito y componentes CryptoAPI para la administración y manejo de certificados. 27 Los componentes de la infraestructura de seguridad de clave pública de Microsoft se muestran a continuación. La infraestructura de seguridad de Internet de Microsoft se basa en los estándares de la industria para la seguridad de clave pública, incluyendo el soporte para los formatos de certificado Publickey Cipher de RSA, X.509 y estándares PKCS. La versión 4.0 de Windows NT proporcionó los primeros componentes para la utilización de la seguridad de clave pública, entre ellos: • CryptoAPI, con soporte de programador para la generación e intercambio de claves, firmas digitales y encriptación de datos, con el uso de una arquitectura de proveedor con el fin de soportar los Proveedores de servicio criptográfico instalables. • Soporte CryptoAPI de certificados X509 y PKCS, los cuales fueron emitidos en el Service Pack 3 para Windows NT 4.0 y se utilizan en Internet Explorer 4.0 y Windows 2000. • Implementación de canal seguro de los protocolos de seguridad de clave pública Secure Socket Layer (SSL) versión 2.0, soporte del lado del cliente en la versión 3.0 y Private Communications Technology (PCT) versión 1.0. • Authenticode™, una solución estándar en la industria, que utiliza firmas digitales para verificar la integridad del software descargado de Internet y la identificación del editor de software. La infraestructura de seguridad de Internet de Microsoft se crea en estos componentes y proporciona funcionalidad adicional para soportar la seguridad de clave pública para plataformas Windows, incluyendo Windows 2000. Muchos de los componentes de seguridad de Internet se utilizan en Microsoft Internet Explorer e Internet Information Server. Las nuevas funciones de la 28 infraestructura de seguridad de Internet de Microsoft para Windows 2000 Distributed Security Services incluyen: • Autenticación del cliente con SSL 3.0 basado • Certificate Server para la emisión de en certificados de clave pública. certificados para cuentas de dominios Windows 2000. La seguridad Windows 2000 utiliza los estándares de Internet para la seguridad de clave pública con funciones incorporadas en el sistema operativo. Autenticación del cliente con SSL 3.0 Secure Socket Layer y Transport Layer Security son protocolos de seguridad basados en clave pública implementados por el proveedor de seguridad Secure Channel (Schannel). Estos protocolos de seguridad los utilizan los exploradores y servidores de Internet para autenticación mutua, integridad de mensajes y confidencialidad. La autenticación de Internet Server se realiza a través de Internet Explorer (el cliente) cuando se presenta el certificado del servidor como parte del establecimiento de canal seguro SSL/TLS. El programa del cliente acepta el certificado del servidor a través de la verificación de las firmas criptográficas en el certificado y cualquier certificado CA intermedio, para uno o más de los CA de raíz configurados o conocidos. Asimismo, la autenticación del cliente está soportada por SSL 3.0 y TLS. La autenticación del cliente que utiliza certificados de clave pública se complementa como parte de este establecimiento de sesión de canal seguro. La Figura 7 muestra los mensajes de saludo SSL 3.0 entre el cliente y servidor para el establecimiento de una conexión segura. 29 La autenticación del cliente por el servidor es el mismo proceso que se sigue con la autenticación del servidor. El servidor verifica las firmas criptográficas en el certificado del cliente y cualquier certificado CA intermedio, a un CA de origen conocido o verdadero. Sin embargo, una vez que se ha verificado la identidad del cliente a través de la verificación de certificado (autenticación del cliente), el servidor de la aplicación necesita establecer un contexto de seguridad con los derechos de acceso correspondientes definidos para el cliente. La información de control de acceso determina qué recursos se le permite utilizar al cliente en este servidor. En la arquitectura de seguridad Windows 2000, el control de acceso lo definen la pertenencia y privilegios de grupo en el registro de acceso de seguridad. La autenticación del cliente de clave pública utiliza la información que se encuentra en el certificado del mismo, para relacionarla con la información de control de acceso local. Esta relación determina qué autorización tiene el cliente para acceder a los recursos en el sistema del servidor. El soporte inicial para la autenticación del cliente a través de Microsoft Internet Information Server está disponible mediante la administración de la base de datos de autorización para relacionar al sujeto de certificado o al emisor de información con las cuentas Windows 2000. La base de datos de autorización puede ser tan simple o complicada, según sea necesario, para cumplir con los requerimientos de la aplicación. Windows 2000 proporciona soporte en el extranjero para la autenticación del cliente mediante la implementación de un servicio de seguridad que utiliza el Directorio Activo para relacionar la información de certificado con las cuentas Windows existentes. La relación se puede realizar utilizando una búsqueda del nombre del tema de certificado en el directorio Windows, o mediante la búsqueda de las propiedades de directorio que identifican el certificado del cliente. 30 El soporte Windows 2000 para la autenticación del cliente integra certificados de clave pública con la arquitectura de seguridad Windows 2000. No se requiere una base de datos separada para definir el acceso a los derechos relacionados con los certificados de clave pública. La información de control de acceso la mantienen miembros de grupo almacenados en el directorio Windows. Las herramientas de administración de servicio de directorio común de Windows se utilizan para dar derechos de acceso mediante el añadido de usuarios Windows a los grupos. Autenticación de usuarios externos El soporte para la autenticación de certificados de clave pública en Windows 2000 permite que las aplicaciones del cliente se conecten a servicios seguros a nombre de los usuarios que no tienen una cuenta de dominio en Windows 2000. Los usuarios que están autenticados con base en un certificado de clave pública emitido por una Autoridad certificada de confianza, pueden recibir acceso a los recursos Windows 2000. Las herramientas de administración de servicio de directorio permiten a los administradores o autoridades delegadas asociar a un usuario externo, o más, con una cuenta Windows 2000 existente para el control de acceso. El nombre del tema en el certificado X.509 versión 3 se utiliza para identificar al usuario externo que está relacionado con la cuenta. Las empresas pueden compartir información de forma segura con personas seleccionadas de otras organizaciones sin tener que crear varias cuentas individuales Windows 2000. La relación de muchos a uno de los certificados para los objetos de usuario Windows 2000 proporciona una autenticación sólida con base en los certificados de clave pública y las autorizaciones de control de acceso común. La autenticación de cliente de usuarios externos sigue requiriendo que el administrador del sistema configure la Autoridad de certificado para los certificados de usuarios externos como un CA de confianza. Esto evita que alguna persona que tenga un certificado emitido por una autoridad desconocida reciba autenticación en el sistema como alguien más. Microsoft Certificate Server Microsoft Certificate Server, incluido en Windows 2000 e IIS 4.0, proporciona servicios personalizables para la emisión y administración de certificados, para aplicaciones que utilizan criptografía de clave pública. Certificate Server puede desempeñar un papel central en la administración de dicho sistema para proporcionar comunicaciones seguras a través de Internet, intranets corporativas y otras redes no seguras. Microsoft Certificate Server es personalizable para soportar los requerimientos de las aplicaciones de diferentes organizaciones. Certificate Server recibe una solicitud de nuevos certificados sobre transportes, tales como RPC, HTTP o correo electrónico. Cada solicitud se verifica contra las políticas personalizadas específicas del sitio, grupos de propiedades opcionales del certificado que va a ser emitido y emisiones del certificado. De igual forma, permite que los administradores añadan elementos a la 31 lista de revocación de certificados (CRL) y publiquen una CRL firmada constantemente. Se incluyen interfaces programables para que sean utilizadas por los desarrolladores con el fin de crear soporte a transportes, políticas, propiedades de certificados y formatos adicionales. El módulo de políticas para Certificate Server utiliza la autenticación de red de solicitudes de certificado para emitir certificados a los usuarios que tengan cuentas de dominio Windows 2000. El módulo de política puede ser personalizado para satisfacer las necesidades de las publicaciones de la organización. Certificate Server genera certificados en un formato estándar X.509. Los certificados en formato X.509 se utilizan normalmente para autenticar servidores y clientes involucrados en comunicaciones seguras, utilizando ya sea los protocolos TLS o SSL. Las siguientes secciones describen los usos y algunas de las funciones clave de Certificate Server. En una intranet corporativa o en Internet, los servidores tales como Microsoft Internet Information Server pueden realizar la autenticación del cliente para comunicaciones seguras, utilizando los certificados generados por Certificate Server. De igual forma, Certificate Server genera certificados de servidor utilizados por IIS y otros servidores de Web para proporcionar la autenticación del servidor y asegurar a los clientes (exploradores) que se están comunicando con la entidad pretendida. CryptoAPI Windows NT 4.0 proporcionó el soporte de criptografía de nivel bajo y proveedores de servicio criptográfico modulares en CryptoAPI. Windows 2000 se beneficia por la introducción de la administración de certificado CryptoAPI para soportar la seguridad de clave pública. Entre algunas de las principales funciones de CryptoAPI se incluyen: • Soporte a los certificados X.509 versión 3 y CRLs X.509 versión 2.0 a través de funciones de codificación/decodificación común, análisis de certificado y verificación. • Soporte a solicitudes de certificado PKCS#10 y PKCS #7 para datos firmados y envueltos. • Añadir y recuperar certificados y CRL en los almacenes de certificados, localizar certificados por sus atributos y asociarlos con claves privadas. • Firma y verificación digital; así como soporte de encriptación de datos utilizando las funciones de nivel más alto disponibles para las aplicaciones en HTML, Java, Visual Basic® Scripting Edition (VBScript) y C/C++. Las funciones CryptoAPI se utilizan en los componentes del sistema operativo Windows 2000, como son Software Publisher Trust Provider para la verificación Authenticode. Otras aplicaciones y servicios del sistema utilizan CryptoAPI versión 2.0 para permitir que la funcionalidad común habilite la tecnología de seguridad de clave pública. 32 Acceso entre empresas: socios distribuídos Las empresas basadas en Internet ya están realizando negocios con clientes y socios a través de Internet. Los resellers, proveedores, distribuidores y cualquier persona que forme parte de un negocio amplio se puede conectar a intranets corporativas y acceder a información importante de la compañía. Los empleados y representantes en el campo utilizan cada vez más el acceso local a redes públicas y después se conectan a las fuentes de información corporativas remotas. La seguridad Windows NT está evolucionando con el fin de soportar las necesidades cambiantes de la informática distribuída a través de Internet. La informática distribuída entre empresas no está limitada a una arquitectura única y la tecnología de seguridad no deberá limitar a las compañías a una sola forma de acceder a la información. A medida que la tecnología de seguridad cambia rápidamente están disponibles muchos enfoques. Windows 2000 integra soporte para los protocolos de seguridad y modelos del usuario que se adapten mejor a las necesidades de la aplicación o de negocios. Lo que es más importante, Windows 2000 proporciona una migración de la seguridad empresarial actual con la oportunidad de utilizar totalmente la seguridad de clave pública de Internet, a medida que la infraestructura madura. A continuación se presentan algunas opciones que la seguridad Windows 2000 proporciona para la administración y soporte de relaciones entre empresas: • Un enfoque inicial que se utiliza ampliamente hoy es la creación de cuentas de usuario para que los socios de negocios puedan acceder a los servicios de información corporativa. Al integrar la seguridad Windows 2000 con el Directorio Activo se facilita la administración de estas cuentas especiales. Las unidades organizacionales que se encuentran en el directorio se pueden utilizar para agrupar cuentas relacionadas según el socio, proveedor u otras relaciones de negocios. La administración de estas cuentas se puede delegar a personas en la organización que administran tales relaciones con los socios. Las Redes Privadas Virtuales se establecen entre las organizaciones para encriptar tráfico de red a través de la red pública. Al utilizar este enfoque, los socios de negocios pueden utilizar acceso remoto a los servicios para obtener información corporativa, de la misma forma que cualquier otro empleado remoto. El acceso a las bases de datos o repositorios de información se puede controlar con un control de acceso Windows 2000. • Las relaciones administrativas de dominio son otra herramienta para el establecimiento de relaciones entre las empresas. El Directorio Activo proporciona mucho más flexibilidad para administrar un árbol de dominios jerárquicos. Con los nombres de dominio Windows 2000 integrados con la denominación DNS, el enrutamiento de Internet de la información entre dos dominios es fácil de configurar. Si así lo requiere la relación de negocios, el dominio se puede utilizar como una manera de configurar las aplicaciones cliente/servidor que también tienen las funciones de privacidad e integridad necesarias para comunicarse sobre Internet. Los usuarios 33 pueden utilizar ya sea los protocolos Kerberos o los de autenticación de clave pública para acceder a recursos compartidos en dominios remotos. • Las organizaciones pueden utilizar la infraestructura de seguridad Microsoft Internet para resolver problemas de seguridad en Internet. Las compañías pueden emitir certificados de clave pública para socios específicos que necesitan acceder a recursos de información específicos. En lugar de crear una cuenta de usuario o definir una relación de confianza de dominios, los certificados se pueden utilizar como una manera de proporcionar identificación y autorización al usuario. Los certificados de clave pública, así como la infraestructura necesaria para soportar la emisión de certificados y la verificación de revocación de certificado, son las maneras más eficaces para soportar las relaciones de empresa a empresa sobre Internet. Windows 2000 soporta certificados X.509 versión 3 emitidos por cualquier sistema de emisión de certificados. Los administradores del sistema en Windows 2000 definen qué Autoridades certificadas son de confianza. Asimismo, pueden relacionar usuarios externos autenticados a través de certificados de clave pública con cuentas de usuario Windows 2000 para definir los permisos de acceso relacionados con dichos usuarios. Registro único firma única para empresas y para Internet Windows 2000 administra las credenciales de seguridad de red del usuario de forma transparente después de un registro único satisfactorio. Al usuario no le preocupa si una conexión a un servidor de red utiliza NTLM, Kerberos o un protocolo de seguridad basado en una clave pública. Desde el punto de vista del usuario, se ha registrado en el sistema y ahora puede acceder a una amplia variedad de servicios de red. Dentro de la empresa, el acceso a los recursos se determina mediante los derechos otorgados a las cuentas del usuario, o a través de miembros del grupo. A través de Internet, un acceso del usuario se basa en su identidad probada por una operación de firma de clave privada y el certificado de clave pública correspondiente. Todos los protocolos de seguridad dependen en alguna forma de las credenciales del usuario, las cuales se presentan a un servidor cuando se establece la conexión. Windows 2000 administra esas credenciales del usuario y utiliza de forma automática el grupo de credenciales adecuado, basado en el protocolo de seguridad involucrado. El Directorio Activo de Windows 2000 soporta múltiples credenciales de seguridad como parte del uso seguro de la información de cuenta del usuario. Estas credenciales se utilizan para los servicios de autenticación empresarial que utilizan al controlador de dominio para la autenticación del usuario en línea. Los servidores de aplicaciones avanzadas pueden soportar la autenticación Windows 2000 integrada mediante el uso de la Interfaz del proveedor de servicio de seguridad para la autenticación de red. 34 Credenciales NTLM El protocolo de autenticación NTLM es utilizado por los clientes Windows 2000 para conectarse a los servidores que ejecutan versiones anteriores de Windows NT. Por ejemplo, la autenticación NTLM se utiliza para conectarse a un componente compartido de archivo remoto en Windows NT 4.0 Server, o para conectar a un cliente Windows NT 4.0 con un componente compartido de archivo Windows 2000. Las credenciales NTLM consisten en el nombre de dominio, el nombre del usuario y la contraseña encriptada introducida una vez durante el registro inicial. Los servicios de seguridad en un controlador de dominio administran una copia segura de las credenciales del usuario NTLM en el Directorio Activo que se utilizarán para la autenticación NTLM. Un cliente Windows 2000 administra las credenciales NTLM introducidas en el registro del sistema del lado del cliente, para que se utilicen cuando el cliente se conecte a los servidores Windows NT 4.0 utilizando la autenticación NTLM. El soporte para las credenciales NTLM en la seguridad Windows 2000 es el mismo que se utiliza para la compatibilidad con Windows NT 4.0. Credenciales Kerberos El protocolo de autenticación primario para el dominio Windows 2000 es la autenticación Kerberos. Las credenciales Kerberos consisten en el nombre de dominio y de su área (los cuales pueden estar en forma de sobrenombres en Internet, como son BobbyB@microsoft.com) y contraseñas encriptadas estilo Kerberos. Cuando el usuario se registra en un sistema, Windows 2000 obtiene uno o más resguardos Kerberos para conectar a los servicios de red. Los resguardos Kerberos representan las credenciales de red del usuario en la autenticación basada en Kerberos. Windows 2000 administra de forma automática el caché del resguardo Kerberos para las conexiones con todos los servicios de red. Los resguardos tienen tiempo de expiración y tienen que ser renovados con cierta frecuencia. La expiración y renovación del resguardo lo maneja el proveedor de seguridad Kerberos y los servicios de aplicación asociados. La mayoría de los servicios, tales como el redireccionador del sistema de archivo, mantienen actualizadas automáticamente los resguardos de sesión. La renovación regular de un resguardo añade seguridad a la sesión, mediante el cambio de clave de sesión periódicamente. Pares de claves privadas/públicas y certificados El usuario es quien administra las credenciales de Internet en forma de pares de claves privadas/públicas y certificados. El Directorio Activo se utiliza para publicar los certificados de clave pública para los usuarios y los protocolos de acceso al directorio estándar se utilizan para ubicarlos. Las claves privadas y los certificados emitidos para los usuarios se mantienen en un almacén seguro, ya sea en el sistema local o en una tarjeta inteligente. El almacenamiento seguro se proporciona con la tecnologías de seguridad de Internet y se conoce como Almacén protegido. 35 La implementación del Almacén protegido se basa en la arquitectura CryptoAPI para Windows NT. CryptoAPI proporciona la funcionalidad de administración de claves así como otras capacidades criptográficas para la creación de un almacén seguro, guardando los certificados en el Almacén de certificados. La implementación de Windows 2000 de protocolos de seguridad basados en clave pública utiliza claves y certificados accedidos desde un Almacén protegido y Almacén de certificados como credenciales de usuario para el acceso a servidores basados en Internet. En muchos casos, las propiedades definidas por el usuario de los certificados en el Almacén de certificados permiten que los protocolos de seguridad seleccionen y utilicen de forma automática el certificado correcto y la clave de firma. Los avances que existen en los protocolos de seguridad de Internet (SSL3/TLS) permiten que un servidor solicite credenciales específicas a un cliente, que se utilizan de forma automática desde el Almacén de certificados en caso de que estén disponibles. La información que se encuentra en el Almacén protegido y el Almacén de certificados está disponible para los usuarios roaming, ya que han sido implementadas de forma segura como parte del perfil del usuario. Cuando un usuario se conecta por primera vez al cliente Windows, la información del perfil del usuario se copia en este PC. Si el usuario obtiene claves y certificados nuevos durante esa sesión, se actualiza el perfil del usuario en el servidor central cuando el usuario sale del sistema. Transición sin fallos La transición de una autenticación NTLM utilizada en Windows NT 4.0 (y versiones anteriores de Windows NT) a la autenticación de dominio Kerberos será muy transparente. Los servicios Windows 2000 soportan las conexiones cliente o servidor utilizando ambos protocolos de seguridad. La negociación de seguridad, ya sea mediante el nivel SSPI u otro protocolo de aplicación, proporciona otra opción para seleccionar la mejor correspondencia de las opciones de protocolo de seguridad disponibles. La transición desde los servicios basados en una empresa que utiliza la autenticación Kerberos a servicios basados en Internet que utilizan autenticación de clave privada es completamente transparente para el usuario. El soporte Windows 2000 para múltiples credenciales del usuario hace posible que se utilice la tecnología de autenticación de clave secreta para los servicios de aplicación empresarial con un rendimiento muy alto y la tecnología de seguridad de clave pública al conectarse a servidores basados en Internet. La mayoría de los protocolos de aplicación, tales como LDAP, HTTP/HTTPS o RPC, soportan la autenticación y están diseñados para soportar múltiples servicios de autenticación y seleccionar dichos servicios durante el establecimiento de una conexión. 36 En lugar de depender de una sola tecnología de autenticación y un solo protocolo de autenticación, Windows 2000 utiliza múltiples protocolos, según sea necesario, para ajustar la aplicación y los requerimientos de comunidad del usuario para una informática de red segura. Proporcionar una migración transparente a la próxima generación de dominios La migración desde un entorno Windows NT 4.0 a los dominios Windows 2000 es sencilla, debido a la compatibilidad hacia atrás con los protocolos de duplicación de seguridad y cuentas de Windows. Una migración sin problemas está disponible, ya que Windows 2000 cuenta con las siguientes funciones de interoperabilidad: • Un controlador de dominio Windows 2000 puede desempeñar el papel de Windows NT 4.0 BDC y recibir la duplicación de la cuenta de dominio desde un Windows NT 4.0 PDC existente. • Las estaciones de trabajo Windows NT 4.0 pueden enviar solicitudes de autenticación de red utilizando el protocolo de autenticación NTLM al controlador de dominio Windows 2000, actuando como un BDC en el dominio Windows NT 4.0. • Los controladores de dominio Windows 2000 pueden establecer relaciones de confianza con los dominios Windows NT 4.0 y soportar la autenticación de pase entre los dominios. Esto significa que no se requiere que todos los dominios que existen en una empresa se actualicen a la seguridad de dominio Windows 2000 al mismo tiempo. A la larga, los controladores de dominio Windows 2000 pueden reemplazar a los controladores de dominio Windows NT 4.0 en una actualización gradual de los Windows NT 4.0 BDC a los controladores de dominio Windows 2000. Las herramientas de administración de cuentas de Windows NT 4.0 se utilizan en el controlador de dominio primario siempre que PDC se ejecute en Windows NT 4.0. Finalmente, se pueden actualizar todos los controladores de dominio para utilizar el Directorio Activo para la administración de cuentas y la duplicación de cuenta multimaestra. El soporte Windows 2000 para los protocolos de autenticación múltiple significa que desde un dominio único de acceso en el escritorio, los usuarios pueden acceder a los servicios Windows 2000 en cualquier entorno de dominio mezclado, como: • Un servidor Windows 2000 en la conexión o dominio local, utilizando resguardos de sesión Kerberos emitidos por el Centro de distribución de claves (KDC) en el controlador de dominio. • Un servidor Windows 2000 en un dominio de confianza, utilizando una referencia Kerberos para el KDC en el dominio de confianza, para emitir un resguardo de sesión al servidor remoto, o 37 • Un servidor Windows NT 4.0 en un dominio utilizando una autenticación de pase NTLM entre el cliente, el servidor Windows NT 4.0 y el controlador de dominio de confianza. Debido a que Windows 2000 sigue soportando la autenticación NTLM, los clientes Windows NT 4.0, que no utilizan la autenticación Kerberos, también pueden conectarse a los servidores de aplicación Windows 2000. Estas funciones de interoperabilidad permiten flexibilidad para que las organizaciones planifiquen e implementen una estrategia de migración a servidores Windows 2000 que se ajusten mejor con sus necesidades de crecimiento empresarial. Resumen Los Servicios de Seguridad Distribuidos de Windows 2000 proporcionan soluciones flexibles para la creación de aplicaciones seguras, distribuidas y escalables. La gestión de seguridad y administración cuentan con funciones más ricas para la delegación y control de cuenta granular. El Directorio Activo soporta dominios con un mayor número de cuentas en un entorno de nomenclatura estructurado en unidades organizacionales. La administración de confianza entre dominios es más simple, ya que proporciona mayor flexibilidad para utilizar los dominios en forma que refleje las necesidades de la empresa. Las API de seguridad Windows para la autenticación de red, privacidad de datos, firmas digitales y soporte de encriptación aseguran el desarrollo de la aplicación para la empresa e Internet. Las interfaces SSPI y CryptoAPI, así como las abstracciones de interfaz COM y DCOM de nivel más alto, hacen que todas las funciones de seguridad integradas en Windows 2000 estén disponibles para su uso por todas las aplicaciones. La arquitectura sólida de seguridad de Windows NT se utiliza de forma consistente a través de todos los componentes del sistema y será ampliada para soportar la autenticación sólida y la seguridad de clave pública. Estas funciones no tienen comparación con cualquier otra plataforma de aplicación distribuída disponible en la actualidad. Windows 2000 Distributed Security integra los estándares maduros de Internet para la autenticación, al tiempo que presenta la nueva tecnología de seguridad de clave pública basada en la dirección de la industria y estándares disponibles. La gran mayoría de los estándares de seguridad de clave pública en Internet aún se están creando. Microsoft participa en el desarrollo de estos estándares, pero reconoce que tienen que cambiar con el paso del tiempo. La arquitectura de seguridad Windows 2000 está diseñada específicamente para incorporar nueva tecnología de seguridad en forma de protocolos, proveedores de servicio criptográficos o 38 tecnología de autenticación de terceros. Los clientes que implementan Windows 2000 tienen opciones sobre qué tecnología de seguridad desean utilizar, cómo integrar la seguridad en su entorno de aplicaciones con el mínimo impacto y cuándo migrar a la nueva tecnología, a medida que esté disponible. En conjunto, todo esto convierte los Servicios de Seguridad Distribuída de Windows 2000 en las mejores bases para la informática segura y distribuída sobre Internet. Para más información • Para obtener la información más reciente de Windows 2000 y Windows NT Server, visite los sitios Web en http://www.microsoft.com/ntserver y el Windows NT Server Forum en Microsoft Network (GO WORD: MSNTS). • Para obtener más información del Directorio Activo de Windows 2000, consulte el White Paper Resumen técnico del Directorio Activo de Microsoft Windows NT. • Información adicional sobre seguridad Microsoft Internet está disponible en el sitio Web http://www.microsoft.com/security. • Información adicional sobre la arquitectura de seguridad Windows NT, interfaz de proveedor de soporte de seguridad, CryptoAPI y las API de seguridad Windows NT está disponible en las referencias en línea para el SDK de la plataforma Microsoft. 39 INTRODUCCIÓN A LA ADMINISTRACIÓN DE CAMBIOS Y CONFIGURACIÓN DE WINDOWS 2000 Este documento proporciona información más detallada sobre una de estas disciplinas: administración de cambios y configuración. Explica los conceptos de la administración del cambio y configuración y presenta información para los gerentes acerca de cómo utilizar las funciones de Administración de Cambios y Configuración del sistema operativo Windows 2000 para reducir el coste total de propiedad (TCO) de la organización. Proporciona una descripción general introductoria de las funciones y productos que Microsoft proporciona para cumplir con su iniciativa de Cero Administración de Windows : • Tecnologías de administración IntelliMirror™. • Instalación remota del sistema operativo. • Systems Management Server versión 2.0. Roles de administración. Dentro de muchas organizaciones, la tarea de administrar el sistema de informática se divide normalmente entre varios grupos, en donde cada grupo realiza un rol de administración específico. Tres de los roles que normalmente se encuentran en muchas organizaciones son la administración del escritorio, administración de la red y administración del centro de datos. Disciplinas de administración. Sin importar su rol, los administradores se preocupan de las siguientes disciplinas de administración: administración de cambios y configuración, administración de la seguridad, administración del rendimiento, administración de lote y salidas, administración de eventos, administración de problemas y administración del almacenamiento. Administración de cambios y configuración Como su nombre lo indica, la disciplina de Administración de Cambios y Configuración incluye la administración de cambios continuos y problemas de configuración que surgen conforme los administradores intentan asegurar que las personas sean productivas cuando utilizan sus PCs para realizar sus labores diarias. 40 Cambio Diferentes factores introducen el cambio en una organización y uno de los problemas de administración clave es administrar el cambio. Sin importar qué factor inicia el cambio, ya sea la configuración inicial para abordar los requerimientos del negocio o adaptarse a nuevos requerimientos de negocios, el impacto de nuevas tecnologías de hardware y software o la obsolescencia de los sistemas existentes, el cambio es inevitable para una organización creciente y dinámica. Configuración La configuración se refiere a los actos para instrumentar el cambio. Todos los grupos de soporte deben manejar el cambio, por lo tanto, la Administración de cambios y configuración es una disciplina importante para todos los grupos de soporte, sin importar su rol administrativo. Las nuevas configuraciones se tienen que desarrollar, probar e implementar, y éste es un proceso continuo. Windows 2000 y la Administración de cambios y configuración Las funciones de la Administración de cambios y configuración estándar en Windows 2000 proporcionan las siguientes ventajas: • Los administradores pueden definir de forma central las configuraciones del entorno de informática tanto para grupos de personas como de PCs. Luego pueden depender del sistema para reforzar esas configuraciones. • Los administradores pueden reemplazar rápidamente un PC y luego volver a generar este entorno automáticamente, restableciendo los datos, aplicaciones, preferencias y políticas administrativas de las personas. • Los administradores pueden permitir a los usuarios finales cambiarse a cualquier PC en su red y tener el mismo entorno de informática, incluyendo acceso a los datos, aplicaciones, y configuraciones de preferencia. • Los usuarios finales pueden encontrar rápidamente todos los archivos de datos de los usuarios y acceder a los archivos de la red aún cuando trabajen fuera de línea, los archivos se introducen en la memoria caché localmente y se sincronizan automáticamente entre el servidor y la versión local. • Los administradores pueden administrar de forma central la instalación, actualización y eliminación del software. Esto elimina la necesidad de intervención del usuario durante la instalación de su software al igual que las visitas del personal de soporte de ayuda del escritorio. • Los administradores pueden definir las opciones que permiten a las estaciones de trabajo instalar automáticamente archivos del sistema operativo en la unidad de disco duro local desde un servidor remoto. 41 Un concepto clave en Administración de cambios y configuración de Windows 2000 es que después de que los administradores instalan un entorno Windows 2000 pueden utilizar el Directorio Activo y crear entornos de informática administrados basados en políticas para grupos de usuarios y PCs. De está forma, reducen de forma significativa la necesidad de visitar los escritorios de las personas para instalar aplicaciones o sistema operativo, para realizar actualizaciones o para reparar cambios de configuración no autorizados o inesperados. Como resultado, pueden reducir substancialmente el coste total de propiedad. Aplicaciones que cumplen con los requerimientos del logotipo Diseñada para Microsoft Windows. Las aplicaciones incluso se pueden autorreparar de forma automática si los usuarios eliminan por descuido los archivos clave. Se requiere de hardware cliente de PC que soporte un entorno PXE. Para detalles, consulte “Instalación Remota del Sistema Operativo”. Funciones de la administración de cambios y configuración La administración de cambios y configuración consiste en las siguientes funciones incluidas en Windows 2000: IntelliMirror e Instalación Remota del Sistema Operativo. De forma adicional se proporcionan las funciones de la administración de cambios y configuración de valor añadido en Microsoft Systems Management Server 2.0. Funciones de Administración de cambios y configuración de Windows 2000 La siguiente tabla muestra las funciones de administración de cambios y configuración estándar que se incluyen en Windows 2000 y las tecnologías subyacentes que habilitan estas funciones. Los administradores pueden utilizar algunas o todas las funciones, dependiendo de los requerimientos de su negocio en particular. 42 * IntelliMirror es un atributo de estás funciones. Soluciones de valor añadido: Microsoft Systems Management Server 2.0 Systems Management Server 2.0, ahora rediseñado para hacer uso total de los servicios de administración de Windows, complementa la funcionalidad de administración incorporada de Windows 2000. Systems Management Server cuenta con un diseño altamente modular que permite que se utilice como una solución individual o como una parte integrada de una solución de administración más grande. En los entornos previos a Windows 2000, Systems Management Server 2.0 proporciona Administración de cambios y configuración avanzada a una amplia gama de sistemas basados en Windows, incluyendo sistemas operativos Windows 95 y Windows 98, Windows NT® versiones 3.51 y 4.0 y Windows Trabajo en Grupo. En los entornos Windows 2000 Server, Systems Management Server complementará a Directorio Activo, ampliando las funciones Administración de Cambios y Configuración estándar proporcionadas por 43 IntelliMirror, para ofrecer una solución de Administración de Cambios y Configuración a escala empresarial para los entornos Windows. Intellimirror IntelliMirror es un conjunto de funciones poderosas nativas de Windows 2000 para la administración de cambios y configuración de escritorio que combina las ventajas de la informática central con el rendimiento y flexibilidad de la informática distribuida. Al aprovechar las diferentes funciones, tanto en el servidor como en el cliente, IntelliMirror permite que los datos, aplicaciones y configuraciones del usuario lo sigan a través de su entorno. Todos los usuarios cuentan con datos y configuraciones que son específicas para cada uno de ellos. IntelliMirror incrementa la disponibilidad del PC del usuario y del entorno de informática al almacenar de forma inteligente información, configuraciones y aplicaciones basadas en las definiciones de las políticas. IntelliMirror puede recuperar, restaurar o reemplazar los datos, aplicaciones y configuraciones personales de los usuarios en un entorno de Windows 2000. Por lo tanto, los usuarios tienen acceso constante a toda su información y aplicaciones, ya sea que estén conectados o no a la red, con la seguridad de que sus datos se mantienen de forma segura y están disponibles desde el servidor. Con IntelliMirror, un tema común es “¡Sígueme!”, ya que se puede configurar para permitir que los datos del usuario, sus aplicaciones y sus configuraciones personales lo sigan a cualquier escritorio en la red. En el núcleo de IntelliMirror se encuentran tres funciones: • Administración de datos del usuario. • Instalación y mantenimiento de software. • Administración de configuraciones del usuario. Los administradores pueden utilizar estas funciones de IntelliMirror, ya sea por separado o juntas, dependiendo de los requerimientos del entorno. Cuando se implementa totalmente, IntelliMirror utiliza el Directorio Activo y las políticas de grupo para proporcionar administración basada en políticas de los escritorios de los usuarios. A través de las políticas definidas de forma central con base en los roles de negocios de los usuarios, los miembros de grupo y su ubicación, los escritorios Windows 2000 Professional se reconfigurarán automáticamente para satisfacer los requerimientos específicos de los usuarios cada vez que el usuario se conecte a la red. Administración de datos del usuario 44 Las funciones de Administración de datos del usuario aseguran que los datos de las personas (como archivos y documentos personales) sean accesibles fácilmente, estén disponibles rápidamente y estén siempre protegidos, de esta manera, los usuarios pueden acceder a sus datos desde cualquier PC ya sea que se conecten, estén en línea o fuera de línea. Las funciones de Administración de datos del usuario de IntelliMirror soportan la duplicación de datos de las personas para la red y el caché local de datos de red seleccionados. Estas funciones aseguran que los datos estén protegidos, estén disponibles fuera de línea y estén disponibles a partir de cualquier PC en la red. Se debe notar que los datos siguen al usuario únicamente si los datos se almacenan en una ubicación configurada para roaming, como en una carpeta Mis Documentos. Accesibilidad de los datos Con las funciones habilitadas de IntelliMirror, los datos pueden seguir a una persona cuando la persona se mueve a otro PC en la red. Esto proporciona una mayor accesibilidad ya que las personas pueden utilizar cualquier PC en la red para acceder a sus datos. Disponibilidad de los datos Los administradores pueden permitir que las funciones de Administración de datos del usuario de IntelliMirror aseguren que las versiones más actualizadas de los datos de las personas residan tanto en el PC local como en el servidor. La memoria caché local mantiene datos en el PC local aún cuando esté desconectada de la red para que los datos estén disponibles para las personas incluso cuando trabajen fuera de línea. Protección de los datos 45 Los administradores pueden proporcionar protección mejorada de datos del usuario al asegurar que los datos del usuario, aunque aparentemente local, también se redireccionan a una parte de la red y a través del respaldo manejado por el administrador de servidores de red. Instalación y mantenimiento de software La función de instalación y mantenimiento de software de Windows 2000 está diseñada para facilitar la instrumentación y administración basada en políticas de software a través de todo el ciclo de vida del software. La instalación y mantenimiento de software de Windows 2000 proporciona instalación de software justo a tiempo y robusta así como reparación automática de las aplicaciones para grupos de usuarios y PCs. Los administradores también pueden utilizar esta función para actualizar aplicaciones, retirar y eliminar aplicaciones anteriores que ya no se requieren, herramientas tanto Service Packs como actualizaciones del sistema operativo. Los administradores utilizan las Políticas de Grupo de Windows 2000 para definir las opciones de instalación de software que especifican qué software se debe instrumentar, actualizar o eliminar de un PC. Las políticas de instalación de software se pueden aplicar tanto a grupos de usuarios como de PCs. Estas políticas se definen con base en sitios, dominios y unidades organizacionales (OUs). Cada vez que se enciende un PC se evalúa, la política de grupo de instalación de software basada en el PC se actualiza. Cada vez que un usuario se conecta a un PC se evalúa, la política de grupo de instalación de software relacionada con el usuario se actualiza y el escritorio se actualiza para ofrecer las aplicaciones que se requieren. Una tecnología clave que se utiliza para realizar la instalación de software justo a tiempo es el servicio Windows Installer. Para utilizar la función Windows 2000 Software Installation and Maintenance, el software debe incluir la autoría o estar empaquetado para hacer uso de este servicio. El servicio Windows Installer automatiza completamente el proceso de instalación y configuración de software. Al utilizar la política de grupo y la instalación de software, los administradores pueden publicar o asignar software a grupos de usuarios y de PCs. El software publicado está disponible para los usuarios según ‘se requiera’. Los administradores pueden seleccionar qué software estará disponible para los usuarios con base en los requerimientos de negocios, técnicos o geográficos de cada grupo. Los usuarios pueden instalar software que se ha publicado para ellos utilizando la herramienta del Panel de control Agregar/eliminar programas y seleccionando el software a partir de una lista de aplicaciones publicadas. De forma alternativa, los usuarios también pueden abrir un archivo o documento que requiere una aplicación publicada y el software requerido será instalado automáticamente, la aplicación iniciará y el archivo se abrirá. 46 Las herramientas de autor y empaquetado para el servicio Windows Installer están disponibles de varias compañías incluyendo InstallShield, Seagate y Wyse. Además, System Management Server Installer, una función de Systems Management Server 2.0, dará soporte a la opción de reempaque de servicio de Windows Installer. En comparación con, asignar software a los usuarios y a los PCs, los administradores ordenan que se instale el software. Cuando los administradores asignan software a un PC, el software se instala la siguiente vez que el PC se vuelve a encender. Esta función también se puede utilizar para instrumentar Service Packs, actualizaciones del controlador y demás software relacionado con el PC. Cuando los administradores asignan software a un usuario final, el software aparece en el escritorio del usuario (por ejemplo, en el menú Inicio, accesos directos de escritorio, etcétera) la siguiente vez que el usuario se conecte a la red. El software se instala la primera vez que el usuario lo activa (seleccionándolo del menú Inicio, por ejemplo). Al utilizar las funciones del servicio Windows Installer después de que las aplicaciones están instaladas, se protegen contra una eliminación inadvertida de archivos de aplicación u otros recursos requeridos. Cada vez que se lanza una aplicación, el servicio Windows Installer realiza una verificación para asegurar que todos los archivos y componentes de la aplicación requerida estén disponibles. Si falta alguno, el servicio Windows Installer recupera e instala los componentes que faltan desde un punto de distribución predeterminado ya sea en el PC local o en la red como una división del sistema de archivo compartido (Dfs). Administración de las configuraciones del usuario y del PC Las ventajas de la administración de configuraciones del usuario del PC son que los administradores pueden definir centralmente los entornos de informática para grupos de usuarios y de PCs y éstos reciben automáticamente el entorno correcto. 47 Los administradores pueden añadir nuevos usuarios y PCs, definir configuraciones para grupos de personas y PCs y aplicar cambios para grupos de personas. Además, con la función IntelliMirror habilitada, los administradores pueden restaurar configuraciones del usuario en caso de que sus PCs fallen y asegurar que las configuraciones de escritorio del usuario sigan a la persona en caso de que se cambie a otro PC. La administración de cambios y configuración de Windows 2000 incluye una funcionalidad que permite a los administradores definir de forma central los entornos de informática específicos para grupos de usuarios y PCs. Esto incluye configuraciones para políticas de software, scripts, instalación de software, configuraciones personalizadas del usuario y seguridad. Los administradores pueden utilizar la política de grupo para definir configuraciones para grupos de usuarios y PCs. Estas configuraciones incluyen configuraciones de registro en el escritorio (como componentes y aplicaciones del sistema operativo), scripts (para inicio y apagado del PC, y conexión y desconexión del usuario), opciones de instalación de software (como aplicaciones que están disponibles a usuarios y aquellas que aparecen en su escritorio) y configuraciones de seguridad (como para PC, dominio y configuraciones de seguridad de red locales). Además, los administradores pueden redireccionar cualquiera de las carpetas especiales en un perfil de usuario hacia una red compartida para que los perfiles del usuario estén disponibles siempre que el usuario se conecte. Instalación remota del sistema operativo La instalación remota del sistema operativo utiliza la nueva tecnología de inicio remoto basada en la Configuración de Host Dinámica (DHCP) del Entorno de Ejecución de Preinicio (PXE) para iniciar la instalación de un sistema operativo a partir de una fuente remota hacia una unidad de disco duro local del cliente. La fuente remota, un servidor que soporta los nuevos Servicios de Instalación Remota (RIS), proporciona el equivalente de red de una instalación basada en el CD de Windows 2000 Professional e imágenes de escritorio Sysprep preconfiguradas. 48 • Instalación basada en el CD. La opción basada en el CD es similar a configurar una estación de trabajo directamente desde el disco compacto de Windows 2000 Professional; sin embargo, los archivos fuente residen a través de la red en servidores RIS disponibles. • Formato de imagen Sysprep. La opción de imagen Sysprep permite a un administrador de red clonar una configuración de escritorio estándar completa, con configuraciones del sistema operativo y personalizaciones de escritorio. Después de haber instalado y configurado por primera vez Windows 2000, sus servicios y cualesquiera aplicaciones estándar en una estación de trabajo, el administrador de red ejecuta un asistente que prepara la imagen de instalación y la duplica para los servidores RIS disponibles. Los PCs cliente habilitados por el inicio remoto pueden solicitar después que se instale esa imagen localmente desde los servidores RIS disponibles en la red. Ya sea el BIOS del PC cliente o un disco flexible de inicio remoto especial puede iniciar un arranque de servicio de red. Cuando se requiere el arranque de servicio de red, DHCP proporciona una dirección IP para el PC cliente y el cliente puede entonces descargar el asistente de instalación de cliente. En este momento, el asistente pedirá al usuario que se conecte y, dependiendo de las credenciales o acceso del grupo de seguridad del usuario, el asistente mostrará un menú que ofrece opciones de instalación del sistema operativo sin atención personalizadas, adecuadas, (el administrador de red utiliza configuraciones de políticas para determinar qué opciones de instalación están disponibles para un usuario, con base en la política definida por ese usuario en la máquina cliente que inició la solicitud de arranque de servicio de red). Requiere hardware que soporte ROM de inicio basado en DHCP del Entorno de Ejecución de Preinicio (PXE). El hardware que cumpla con los requerimientos de Net PC o de Office PC en PC 98 satisface estos requerimientos. 49 Systems Management Server Systems Management Server 2.0 proporciona administración de cambios y configuración escalable de PCs personales basadas en Windows en una empresa. Con base en la infraestructura de administración nativa proporcionada por los servicios de administración de Windows, Systems Management Server 2.0 permite que el personal de soporte de administración de escritorio central y regional trabajen juntos utilizando un conjunto integrado de herramientas que proporcionan una colección de inventario de hardware y software, distribución e instalación de software, medición de software además de diagnósticos y resolución de problemas desde el escritorio de ayuda. Systems Management Server se puede utilizar para complementar las funciones incorporadas de Administración de cambios y configuración de Windows 2000, además de poderse utilizar en entornos previos de Windows 2000. Systems Management Server soporta todos los escritorios de 16 y 32 bits de Windows, desde Windows 3.1 hasta Windows 2000, ya sea que operen en entornos Windows NT, NetWare 3.1 o NetWare NDS. Como un sistema de administración de escritorio individual o como el componente de administración de escritorio dentro de la solución de administración empresarial integrada, Systems Management Server 2.0 incluye las siguientes facilidades: Inventario de hardware y software: Systems Management Server utiliza Windows Management Instrumentation (WMI) y la nueva versión de los escáners de software de información de recursos para cargar una gran cantidad de información de inventarios de hardware y software detallados en el deposito de SQL Server™. Esto proporciona a los administradores un mecanismo eficiente y dinámico para obtener información de hardware y software de cualquier aplicación en cada una de las PCs. Además, se ha añadido un nuevo cumplimiento de la herramienta de base de datos comparativa que puede evaluar el inventario después de que recopila y genera informes en los estados de cumplimiento. Esto es especialmente útil para identificar aplicaciones del Año 2000. Distribución e instalación de software: Al utilizar Systems Management Server 2.0, los administradores pueden implementar aplicaciones a las máquinas, usuarios y grupos de usuarios. La distribución de software ahora se basa en reglas y los objetivos de distribución se evalúan dinámicamente. También está totalmente integrado con el inventario para permitir objetivos sofisticados. Systems Management Server 2.0 primero realiza una consulta del inventario de software y recolección de información, se enfoca a un público y luego implementa el software para ese público de acuerdo con las reglas definidas por el administrador. Por ejemplo, si un usuario nuevo se une a un grupo de usuarios, el software se le enviará ahora inmediatamente de acuerdo con la política del grupo. Con Systems Management Server 2.0, los 50 administradores pueden distribuir una aplicación. La tecnología Windows Management Instrumentation (WMI) es compatible con la iniciativa de administración empresarial basada en el Web (WBEM) de Desktop Management Task Force (DMTF). Aprovecha el modelo de información común (CIM) de DMTF para representar objetos administrados en entornos basados en Windows. Medición de Software: Los administradores con frecuencia requieren herramientas para rastrear el uso de software por parte de los usuarios, grupos, estaciones de trabajo, tiempo o cuota de licencia. Systems Management Server 2.0 puede supervisar, analizar y, de ser necesario, controlar el uso de las aplicaciones en los servidores y estaciones de trabajo. Estas herramientas proporcionan a los administradores varios niveles de control, desde alarmas sencillas hasta la capacidad de evitar que se ejecuten las aplicaciones. Diagnósticos y resolución de problemas: Además de informar del estado actual de una estación de trabajo o servidor y de proporcionar facilidades de control remoto, Systems Management Server también proporciona una amplia gama de herramientas de diagnóstico avanzadas. Estas incluyen herramientas como el monitor de red con tiempo real y expertos posteriores a la captura para analizar las condiciones y el rendimiento de la red además de una herramienta HealthMon del servidor que puede rastrear información de rendimiento importante en Windows NT Server y procesos de aplicaciones de la familia BackOffice®. Documentos de administración y descripción general La siguiente tabla enumera una serie de documentos que presentan los Servicios de Administración Windows de Microsoft y la Administración de Cambios y Configuración. Estos documentos tienen la intención de que los administradores y los encargados de tomar decisiones técnicas comprendan los requerimientos de negocios y los beneficios de las funciones de administración, así como la arquitectura de administración, herramientas y soluciones de Microsoft. Le recomendamos que lea los documentos en el siguiente orden. 51 Documentos técnicos La siguiente tabla enumera los documentos técnicos adicionales que están o estarán disponibles para los administradores y gerentes de informática (IT) que están interesados en comprender los detalles de las funciones y tecnologías de los servicios de administración de Windows. 52 53 PLANIFICAR LA MIGRACIÓN DE WINDOWS NT A WINDOWS 2000 Introducción Este trabajo pretende guiarle en la planificación de la migración de Windows NT 3.51 y Windows NT 4.0 a Windows 2000 en un entorno de empresa. Se centra principalmente en planificar la implementación del espacio de nombres de Active Directory a través de la actualización de los dominios de Windows NT; la planificación del espacio de nombres de Active Directory deberá haberse hecho casi toda antes. Determinar la ruta de la migración En cualquier proceso de planificación se toman decisiones importantes. A la hora de planificar la migración esas decisiones determinarán la disponibilidad de determinadas funciones del sistema operativo. Esta sección le ayudará a establecer las prioridades, ya que se ocupa de: • Los conceptos subyacentes de la migración, para que comprenda las decisiones que toma al establecer la ruta de la migración. • Sus repercusiones sobre los objetivos de la migración. Al final de esta sección tendrá información suficiente para elaborar el mapa de la migración y para conocer algunas áreas de riesgo para su proyecto. Conceptos de la migración Hay dos formas de llegar a la infraestructura deseada: • Actualización del dominio, a la que en ocasiones se denomina actualización in situ. • Reestructuración del dominio, a la que en ocasiones se denomina consolidación del dominio o colapso del dominio. La actualización y la reestructuración no son mutuamente excluyentes: algunas organizaciones pueden actualizarse primero y después reestructurarse, mientras que otras se reestructuran al principio. Actualización del dominio La actualización a Windows 2000 Server es la ruta de migración más sencilla y de menos riesgo. Podemos definir la actualización del dominio como el proceso de actualizar el software del Primary Domain Controller (PDC; Controlador Primario del Dominio) de un dominio y de actualizar una parte o la totalidad de los Backup Domain Controllers (BDC, Controladores de Copia de Seguridad) de Windows NT 4.0 a Windows 2000 Server. Puesto que Windows 2000 está diseñado para soportar redes mixtas que contengan Windows 9x, Windows NT 4.0 y Windows 2000 con plena interoperabilidad, no es preciso actualizar todos los sistemas del dominio para poder aprovechar las funciones de Windows 2000. Una vez dicho esto, la actualización del PDC debe verse sólo como la primera fase de la actualización, ya que se obtienen nuevos beneficios paulatinamente al actualizar los Backup Domain Controllers (BDC) y después los servidores miembros. Como se trata de una actualización del sistema operativo y no de una instalación, se mantienen la estructura, los usuarios y los grupos existentes en el dominio, aunque en el proceso se activarán nuevas funciones de Windows 2000. De hecho, la principal diferencia entre actualización y consolidación es que en la actualización conservamos la estructura actual del dominio. Cuando haya terminado la actualización y tenga acceso a las avanzadas herramientas y funciones de gestión de Windows 2000, tal vez desee reestructurar los dominios. Debe tener en cuenta que la reestructuración no es una tarea trivial y que exigirá más planificación e implementación, según se explica más adelante, en la sección dedicada a la reestructuración. Si el cambio estructural es para usted uno de los principales objetivos de la migración, tal vez desee estudiar un enfoque en el que la reestructuración se produzca durante la migración. 54 Consecuencias de la actualización del dominio La actualización es la ruta de migración más sencilla y de menos riesgo porque conserva la mayor parte de la configuración, las preferencias y las instalaciones de programas del sistema. En esta sección estudiaremos los efectos reales de la actualización sobre los DC (Controladores del Dominio) y los principales de seguridad y explicaremos su importancia a la hora de tomar las decisiones de planificación. El Asistente de instalación de Active Directory (DCPromo.exe) Después de forzar una sincronización de todos los BDC del dominio, de forma que estén totalmente actualizados con todos los cambios recientes que se hayan hecho en el PDC, podemos empezar la actualización del dominio de cuentas actualizando el PDC. Después de instalar el sistema operativo básico en el PDC, el programa de configuración detecta que está actualizándose un DC y pide al administrador que instale el Active Directory en el servidor ejecutando automáticamente el programa DCPROMO. DCPROMO ofrece al administrador la opción de crear el primer árbol de un bosque nuevo, crear un árbol nuevo en un bosque existente, crear una réplica de un dominio existente o instalar un dominio hijo. La elección que haga dependerá del resultado del proceso de planificación del espacio de nombres. Nota: No se pretende dar una descripción detallada del proceso. También deberá tomar en consideración actividades como la copia de seguridad del dominio por si surgen problemas graves y necesita recuperarlo. Podría optar por añadir un BDC más al dominio antes de la sincronización y la actualización y dejar este BDC fuera de línea mientras dure la actualización. Encontrará más detalles en la Guía de Planificación de la Instalación. PDC de Windows NT Como parte del proceso de instalación de Active Directory, el contenido de la base de datos de cuentas de Windows NT y el Security Account Manager (SAM, Administrador de Cuentas de Seguridad) se copian en Active Directory. Estos objetos son los principales de seguridad (cuentas de usuario, grupos locales y globales y cuentas de ordenadores). Tan pronto como se ha actualizado el PDC y se ha instalado Active Directory, el dominio está funcionando en modo mixto de Windows 2000. Para una descripción más detallada del modo mixto y del modo nativo, consulte más adelante la sección “Modo mixto y modo nativo”. A partir de este punto, el PDC de Windows 2000 Server utiliza Active Directory para almacenar objetos. Es plenamente compatible hacia atrás porque expone los datos como almacén plano a los BDC de Windows NT durante el replicado. Esto se manifiesta de varias formas: • El PDC aparece como un DC de Windows 2000 DC ante otros ordenadores con Windows 2000 y como PDC de Windows NT ante los ordenadores que no están aún actualizados. • Puede seguir usando el PDC para crear nuevos principales de seguridad y para replicar estos cambios en los BDC de Windows NT. • Las estaciones de trabajo de Windows NT y Windows 9x pueden utilizar el PDC como posible servidor de sesiones. • Si el PDC de Windows 2000 queda fuera de línea o si no está disponible por cualquier otro motivo y no hay otros CD de Windows 2000 en el dominio, un BDC de Windows NT puede funcionar como PDC. El efecto de la actualización sobre el control de acceso Después de trasladar los principales de seguridad a Active Directory como parte del proceso de actualización del PDC, una de las grandes preocupaciones es el efecto que esto tiene sobre el acceso a los recursos. Identificadores de seguridad (SID) El Modelo de Seguridad de Windows NT (la base de la seguridad para Windows NT y Windows 2000) identifica los objetos de cuentas como usuarios, grupos, máquinas y relaciones de confianza de dominios mediante los SID. Los SID son valores de dominio únicos, incorporados 55 al crear el usuario o el grupo, o cuando se registra en el dominio la máquina o la relación de confianza. Los componentes de un SID siguen una convención jerárquica: un SID contiene partes que identifican el número de revisión, la autoridad (por ejemplo, el dominio) que emitió el SID y un número variable de subautoridad o valores de identificador relativos que identifican de forma única el principal de seguridad en relación con la autoridad emisora. Aunque existen SID bien conocidos que identifican grupos y usuarios genéricos en todos los sistemas, la mayoría de los principales de seguridad a los que nos referimos se identifican en el contexto de un dominio y, por tanto, no pueden moverse entre dominios si no se cambian sus SID. Autenticación y tokens de acceso Un componente esencial del modelo de seguridad de Windows NT es la autenticación, por la que un usuario se identifica en el dominio presentando sus credenciales, que normalmente son un nombre de usuario y una contraseña. Si estas credenciales son aceptables, el sistema crea para el usuario un token de acceso que contiene el SID del usuario (SID primario) y los SID de todos los grupos del dominio de los que el usuario es miembro. Todos los procesos que cree el usuario, por ejemplo ejecutando una aplicación, tendrán el token de acceso de ese usuario. El sistema utiliza este token de acceso para determinar si debe concederse al usuario acceso a los recursos del sistema. Autorización y descriptores de seguridad El equivalente del token de acceso del usuario es el descriptor de seguridad unido a recursos como los archivos o las impresoras. Un descriptor de seguridad contiene una Access Control List (ACL, Lista de Control de Acceso), que consiste en una lista de las Access Control Entries (ACE, Entradas de Control de Acceso). Cada ACE está formada por un SID y por un indicador de si se ha concedido o denegado al principal de seguridad identificado por el SID algún tipo de acceso al recurso. De esta descripción puede deducirse que el efecto de la actualización de los SID tiene una importancia crucial: si se alteran los SID de cualquier modo durante la actualización, se vería afectado el acceso a los recursos. En la actualización, los principales de seguridad permanecen en el mismo dominio en el que fueron creados y también quedan sin cambios los SID que los identifican. El resultado es que el acceso a los recursos no se ve afectado por la actualización. 56 Efecto de la actualización sobre las relaciones de confianza Native Mode Domain HAYBUV.TLD Mixed Mode Domain w2kpro = Windows 2000 Professional ntws = Windows NT Workstation w2ksrv = Windows 2000 Server nts = Windows NT Server HAYBUV-ACCT HAYBUV-OTHER w2ksrv w2kpro nts ntws HAYBUV-ACCT2 HAYBUV-RES1 w2ksrv nts Figura 1. Ejemplo de dominio HAYBUV.TLD DCPROMO instala también el software Kerberos. Una vez instalado se ponen en marcha el servicio de autenticación y el servicio de concesión de tickets. Si el administrador ha decidido unir un árbol existente, se establece una relación de confianza transitiva y bidireccional de Kerberos. Seguirán existiendo todas las relaciones de confianza creadas antes de actualizar el PDC, pero tendrán la forma de una relación de confianza explícita unidireccional al estilo de las de Windows NT. A la larga, el DC del dominio padre copia toda la información de esquemas y configuración al nuevo dominio hijo. Cuando se ha replicado esta información, el dominio actualizado es miembro plenamente funcional del árbol de dominios de Active Directory, aunque permanecerá en modo mixto hasta que el administrador decida trasladar el dominio al modo nativo de Windows 2000. Los clientes que reconozcan Active Directory, como las estaciones de trabajo con Windows 2000 Professional o Windows 9x y Windows NT Workstation (con software cliente Active Directory) pueden utilizar ya Active Directory y efectuar acciones como consultar catálogos globales para buscar recursos y personas. Los clientes también podrán utilizar las relaciones de confianza que existen dentro del bosque para acceder a los recursos de todo este bosque. La forma de hacerlo dependerá de si el cliente utiliza el sistema operativo Windows 2000 o uno anterior, como Windows NT o Windows 9x, y del estado de actualización del dominio de destino. Puede accederse a los recursos del bosque a través de relaciones de confianza transitivas cuando los recursos residen en: Dominios en modo nativo. • • Dominios en modo mixto en los que se han actualizado todos los DC. • Dominios en modo mixto en los que se ha actualizado el DC que gestiona la solicitud de autenticación de Kerberos o NTLM. 57 En todos los demás casos, los clientes sólo tendrán acceso a los recursos disponibles a través de relaciones de confianza explícitas unidireccionales al estilo de las de Windows NT existentes, que no se ven alteradas como resultado de la actualización. Veamos algunos ejemplos en los que se describe cómo funciona la autenticación NTLM y Kerberos para aclarar conceptos. La figura 1 anterior ilustra la situación. Uso de la autenticación NTLM Imaginemos que un usuario se conecta al dominio haybuv-acct.haybuv.tld, que es un dominio en modo mixto, desde ntws de Windows NT Workstation, que está en el mismo dominio. El usuario intenta establecer una conexión de red con una máquina de Windows NT Server, nts, en el dominio haybuv-other.haybuv.tld, que es un dominio de Windows 2000 en modo nativo. Puesto que ntws es un cliente de Windows NT, utilizará el protocolo NTLM. Nts determinará que el nombre de dominio especificado en las credenciales recibidas, haybuvacct.haybuv.tld, no hace referencia a su propia base de datos de cuentas, de modo que envía la petición de conexión a un DC de su propio dominio para su autenticación. El DC comprueba el nombre del dominio y, como no coincide con el nombre del dominio del DC, éste comprueba si el dominio es de confianza. Los dominios haybuv-acct.haybuv.tld y haybuv-other.haybuv.tld son hijos de la misma raíz —haybuv.tld— por lo que existe una relación de confianza transitiva entre ambos y el DC traslada la petición de conexión a un DC del dominio de confianza. Este DC autentica el nombre de usuario y la contraseña contra su base de datos de cuentas y, si las credenciales coinciden, devuelve la información de identificación de la cuenta al DC que se puso en contacto con él, que a su vez la devuelve al servidor. Después, el servidor crea para el usuario un token de imitación que contiene el SID del usuario y los SID de todos los grupos del dominio de los que el usuario es miembro. Luego crea un hilo de imitación en el contexto de seguridad del usuario, con el token de imitación, e intenta acceder al recurso en nombre del usuario. Podemos ver que un cliente de un nivel bajo de un dominio en modo mixto puede acceder a un servidor de nivel bajo de otro dominio del árbol utilizando NTLM, siempre que el DC del dominio de destino utilice Windows 2000 y, en consecuencia, comprenda las relaciones de confianza transitivas. Puesto que todos los árboles del mismo bosque están vinculados por relaciones de confianza transitivas, ocurriría lo mismo aunque los dos dominios estuvieran en árboles distintos. Por extensión se deduce que si intentáramos acceder a un recurso de la máquina de nts de Windows NT Server en el dominio en modo mixto haybuv-res1.haybuv-other.haybuv.tld, siempre que el DC al que ese servidor trasladó la petición de conexión utilizase Windows 2000, podríamos acceder al recurso mediante una relación de confianza transitiva en todo el bosque. Uso de la autenticación de Kerberos Imaginemos ahora que un usuario se conecta al dominio haybuv-acct.haybuv.tld igual que antes, pero esta vez desde la máquina w2kpro del mismo dominio, que utiliza Windows 2000. El usuario quiere establecer una conexión de red con una máquina con Windows 2000 Server, w2ksrv, en el dominio haybuv-other.haybuv.tld. Puesto que w2kpro es cliente de Windows 2000, intentará usar el protocolo Kerberos. Kerberos es un protocolo basado en tickets, en el que los usuarios reciben Ticket Granting Tickets (TGT, Tickets de Concesión de Tickets) del servicio de concesión de tickets del Key Distribution Center (KDC, Centro de Distribución de Claves) que se ejecuta en el DC con Windows 2000, en la conexión inicial con el dominio. Los TGT contienen información de autenticación sobre el usuario encriptada en la clave maestra del dominio, que puede volver a presentarse al DC como parte de las solicitudes de más tickets de sesión para conectarse a otros servidores del dominio. Una vez que se concede un TGT al usuario, las comprobaciones posteriores son rápidas y eficaces, porque el DC sólo tiene que desencriptar el TGT para comprobar las credenciales del usuario. Los tickets de sesión son similares a los TGT, pero están encriptados usando una clave compartida por el servidor y el DC. 58 El protocolo Kerberos, igual que NTLM, puede operar entre fronteras de dominios. Un cliente de un dominio puede autenticarse ante un servidor de otro dominio si ambos tienen establecida una relación de confianza. Cuando los dominios establecen una relación de confianza, intercambian claves interdominios. El servicio de autenticación de cada dominio usa su clave interdominios para encriptar los tickets dirigidos al servicio de concesión de tickets del otro dominio. Cuando un cliente quiere acceder a un servidor de un dominio remoto, pide al CD de su dominio de origen un ticket de derivación, un TGT que puede presentar al servicio de concesión de tickets del CD del dominio remoto. El DC local contesta enviando un TGT encriptado con la clave interdominios del DC remoto. El cliente presenta el TGT de derivación al servicio de concesión de tickets del DC remoto y pide un ticket para un servidor de su dominio. El DC remoto desencripta el TGT del cliente con su clave interdominios. Si la desencriptación tiene éxito, el CD remoto confirma que el TGT fue emitido por una autoridad de confianza y concede al cliente un ticket para el servidor solicitado. En la figura 1, como haybuv-acct.haybuv.tld y haybuv-other.haybuv.tld son hijos de la misma raíz y como existen relaciones de confianza transitivas entre ambos dominios, puede establecerse una ruta de confianza entre ellos. Al recibir el TGT de derivación, el DC del dominio de destino comprobará si tiene una clave compartida para el servidor en cuestión y, si la tiene, emitirá al cliente un ticket de sesión. Puesto que w2ksrv es una máquina con Windows 2000, existirá una clave compartida, por lo que puede emitirse un ticket para w2kpro. De ello podemos deducir que los factores importantes en esta situación son la existencia de un DC en el dominio de destino que gestiona el servicio de concesión de tickets Kerberos y la existencia de una clave compartida por el DC y el servidor. Los DC de Windows 2000 tienen instalado el servicio Kerberos como parte del proceso de instalación de Active Directory y añadir un servidor miembro a un dominio de Windows 2000 implica la creación de una clave compartida. De ello se deduce que w2kpro podría acceder a w2ksrv.haybuv-res1.haybuvother.haybuv.tld usando Kerberos siempre que hubiera un DC de Windows 2000 para emitir el ticket de sesión. Si w2kpro intentara acceder a un recurso de una máquina de Windows NT, como nts.haybuvres1.haybuv-other.haybuv.tld, la autenticación de Kerberos fracasaría y el cliente volvería a intentar la autenticación NTLM según se ha descrito en la sección anterior. Actualización y dominios de recursos Un dominio de recursos es un tipo de dominio especial, creado para almacenar las cuentas de recursos, como servidores y estaciones de trabajo. Los dominios de recursos se crearon en Windows NT en general para resolver dos situaciones principales: • Limitación de tamaño del SAM. En Windows NT el tamaño máximo recomendado para la base de datos de cuentas del SAM son 40 megabytes (MB). En una organización que tenga instalados muchos servidores y estaciones de trabajo y también muchos grupos de seguridad, esto podría equivaler a mucho menos de esa cifra de 40.000 cuentas que a veces se señala. Para que una organización supere esta cifra se recomienda almacenar las cuentas de usuario y de máquinas en dominios independientes, a los que se denomina respectivamente dominio de cuentas o maestro y dominio de recursos. Normalmente puede pensarse que los dominios de recursos están creados como dominios de segundo nivel, con relaciones de confianza unidireccionales con un único dominio de cuentas (esta topología se denomina modelo de dominio maestro) o con varios dominios de cuentas (modelo de dominio multimaestro). • Proporcionar capacidad administrativa local. En una organización descentralizada con instalaciones muy alejadas geográficamente, muchas veces es preferible autorizar al personal local a administrar los recursos. Para delegar esta clase de responsabilidad en Windows NT se recomienda crear los dominios de recursos con su propia estructura administrativa. Igual que en el caso anterior, el resultado serían estructuras de dominio maestro o multimaestro con relaciones de confianza unidireccionales con los dominios de cuentas de la organización. 59 La naturaleza unidireccional de estas relaciones de confianza garantiza que los administradores del dominio de recursos tengan sólo, por defecto, capacidad de administración sobre el dominio de recursos. Una consideración importante cuando se evalúen los efectos de la actualización sobre un dominio de recursos es en cuál de los dos enfoques se basó más el diseñador a la hora de determinar la estructura del dominio. Si el dominio se creó para resolver la segunda situación, deseará conocer las consecuencias de actualizar un dominio de recursos sobre su modelo de administración, porque simplemente actualizar el dominio de recursos e incorporarlo a un bosque se traducirá en la creación de una relación de confianza transitiva bidireccional entre el dominio de recursos hijo y el dominio padre. Si los administradores locales no están muy capacitados o si no tiene previsto ampliarles los derechos administrativos en el bosque de Windows 2000, probablemente quiera estudiar las opciones siguientes: • Actualizar el dominio dentro del bosque y utilizar las funciones de delegación de Windows. Compruebe los grupos administrativos del dominio de recursos y elimine los que no sean administradores en los dominios maestros. Si sólo tiene administradores de dominio de recursos locales, añada uno o varios administradores de dominios maestros, que podrán administrar el dominio mientras está siendo actualizado. Como precaución complementaria debería comprobar que los administradores del dominio de recursos no tienen acceso administrativo a los DC a través de las cuentas de máquinas locales. Una vez actualizado el PDC, cree un nuevo grupo local en el dominio para contener los administradores de recursos y añada los usuarios que suprimió de los grupos administrativos, así como los grupos administrativos modificados. Cuando esté actualizado el PDC, utilice la administración delegada de Windows 2000 para delegar la autoridad correspondiente en el grupo de administradores de recursos recién creado. • Actualizar el dominio en un bosque nuevo. Puede optar por actualizar el dominio de recursos como árbol nuevo en un bosque nuevo y mantener el enlace con el dominio de cuentas mediante la relación de confianza explícita preexistente, que, como relación de confianza explícita de Windows NT, es unidireccional y no transitiva. Esto reflejaría de forma efectiva la estructura previa a la actualización. • Reestructuración en unidades organizativas (OU). Otra posibilidad es volver a estudiar la estructura del dominio y valorar la fusión de los dominios de recursos en el dominio maestro actualizado como OU más adelante. Esta última opción, lógicamente, influiría en su decisión respecto al orden de la actualización del dominio. Actualización y administración Una vez actualizado el PDC a Windows 2000 Server e instalado Active Directory, el administrador puede empezar a usar las nuevas herramientas que incluye Windows 2000 Server para crear nuevos objetos que sólo existen en Active Directory, como las unidades organizativas (OU). Si crea una OU, puede empezar a organizar su dominio poniendo objetos en él. Esta estructura sólo es visible para ordenadores con software cliente de Active Directory. Sin él, las OU no aparecen y el dominio aparece inalterado. El PDC sigue presentando los objetos como un almacén plano a los clientes de nivel bajo. Un administrador que trabaje en un cliente sin Active Directory sólo puede usar las herramientas de administración antiguas. 60 Modo mixto y modo nativo Figura 2. Fases de la actualización. Terminos Usados: ************************************************* PDC no actualizado. PDC actualizado pero no todos los BDC actualizados. PDC y todos los BDC actualizados: aún no se ha pasado a modo nativo. PDC y todos los BDC actualizados: se ha pasado a modo nativo. Dominio de Windows NT 4.0. Dominio en modo mixto. Dominio en modo mixto. Dominio en modo nativo. ************************************************** Modo mixto Desde el momento en que se actualiza el PDC hasta que el administrador decide llevar el dominio al modo nativo de Windows 2000, el dominio se encuentra en modo mixto. El modo mixto ofrece máxima compatibilidad con versiones anteriores del sistema operativo. Debe subrayarse que el modo mixto sólo tiene que ver con la infraestructura de autenticación de un dominio, es decir, los controladores del dominio. Aunque un dominio sólo tenga DC de Windows 2000 y haya pasado a modo nativo, podrán existir en él clientes y servidores con versiones anteriores de Windows NT y clientes con Windows 9x. Este entorno es el que se conoce como entorno mixto. Puede dejar el dominio funcionando en modo mixto indefinidamente, aunque haya actualizado todos los BDC del dominio y también el PDC. La tabla 1 siguiente resume las funciones de Windows 2000 disponibles en modo mixto y las que sólo pueden usarse cambiando a modo nativo. Si no está seguro de pasar al modo nativo, revise lo que pretende con la migración para determinar si sus objetivos se verían amenazados en caso de permanecer en el modo mixto y si hay compensaciones aceptables. Hablando en términos generales, las únicas razones para quedarse en el modo mixto son: • No es posible actualizar los BDC. En este caso hay unos BDC que, por alguna razón, no pueden actualizarse ni degradarse a servidores miembros. Esto podría ocurrir si tiene aplicaciones que deben ejecutarse en un BDC pero que, por algún motivo, no se ejecutarán en Windows 2000. • Seguridad física inadecuada de los BDC. Al estudiar la planificación de un dominio, la seguridad es una consideración importante. Un aspecto fundamental de la seguridad es la seguridad física de la propia máquina: cualquier máquina a la que sea fácil acceder físicamente es vulnerable a los ataques. En este caso debería estudiarse la diferencia entre la actualización de un maestro único del SAM por el PDC sólo y la actualización multimaestro de Active Directory de la base de datos de cuentas por todos los DC. Dada la naturaleza de maestro único de las actualizaciones de directorios en Windows NT, tal vez se sienta cómodo con una seguridad relativamente relajada en sus BDC. Si es éste el caso, tendrá que reconsiderar cuándo actualizarlos a DC de Windows 2000. Si no puede 61 actualizar adecuadamente la seguridad del BDC, podría pensar en degradar el BDC a servidor miembro durante la actualización, añadiendo un DC de Windows 2000 nuevo en otra ubicación, o posiblemente reconsiderar incluso la estructura propuesta para el dominio. • Sigue siendo necesario el fallback (retorno) a Windows NT. Una de las características del modo mixto, como ya se habrá visto, es el grado de compatibilidad hacia atrás. El modo mixto tiene la ventaja de que permite añadir BDC de Windows NT nuevos al dominio si surge algún problema. En esta situación, una vez que el BCD se haya unido al dominio, podría forzar una sincronización de la base de datos de cuentas. Después, mientras no haya DC de Windows 2000 en el dominio, podría ascender el BDC a PDC. Debería tener previsto un fallback (retorno a la versión anterior) o una recuperación, pero en un momento dado decidirá trasladarse por completo al nuevo entorno. Modo nativo Cuando se hayan actualizado todos los DC, puede cambiar el dominio del modo mixto al modo nativo. En este paso ocurren varias cosas: • El dominio sólo utiliza replicación multimaestro de Active Directory entre los DC, por lo que se interrumpe el soporte para la replicación de Netlogon. • Puesto que está anulada la replicación de Netlogon, ya no podrá añadir más BDC de Windows NT al dominio. • Puesto que está activada la replicación multimaestro, el PDC anterior ya no es el maestro del dominio y todos los DC pueden realizar ahora actualizaciones de directorios. Un aspecto que en ocasiones crea confusión es la existencia continuada del papel emulador del PDC. Pese a la naturaleza multimaestro de Active Directory, Windows 2000 tiene una serie de papeles denominados Flexible Single-Master Operations (FSMO, Operaciones de Maestro Único Flexibles) y PDC Emulator es un papel de FSMO. Normalmente el PDC anterior seguirá como soporte para FSMO de PDC Emulator, que en un entorno en modo nativo significa que los cambios de contraseña son replicados a él de forma preferente por otros DC. • Se activan los tipos de grupos de Windows 2000, como los grupos universales y locales del dominio y el anidamiento de grupos. Este cambio a modo nativo no se realiza automáticamente ejecutando DCPROMO. El cambio debe ser iniciado por el administrador a través de la interfaz administrativa. Aunque puede conseguir grandes beneficios al actualizar el PDC y los BDC y quedarse en modo mixto, en éste no están disponibles ciertas funciones muy interesantes, como los grupos universales o el anidamiento de grupos. El cambio a modo nativo debe hacerse lo más pronto posible. Cambiar a modo nativo Cambiar el modo del dominio de mixto a nativo es algo fácil de hacer pero imposible de deshacer, de forma que deberá tener en cuenta todos los factores expuestos para determinar cuándo se hará el cambio. No cambie el modo del dominio si tiene o va a tener DC de Windows NT. Para cambiar el modo del dominio: 1. Abra el cuadro Active Directory Domains and Trusts y haga clic con el botón derecho en el dominio que desee administrar, en el panel izquierdo de la vista de árboles. 2. Aparecerá un menú contextual. Elija Propiedades para ver un cuadro de diálogo con pestañas como el que se muestra en la figura 3. En la pestaña General, haga clic en Cambiar modo. 62 Figura 3. Cuadro de diálogo para cambio del modo del dominio. Tabla 1. Disponibilidad de las funciones de Windows 2000 en modo mixto. Objetivo Más posibilidades de administración. Función Relaciones de confianza transitiva de Kerberos. Active Directory. Unidades organizativas (OU) de Active Directory. ¿Disponible en modo mixto? Sí, pero consulte la sección “Efecto de la actualización sobre las relaciones de confianza” (más arriba). Sí. Sí, pero sólo es visible con herramientas de administración de Windows 2000. No puede administrarse desde BDC de Windows NT ni servidores miembros. No, sólo hay grupos globales y locales. Nuevos grupos de seguridad de Active Directory. Instalador de Sí. Windows. 63 Tabla 1, continuación. Mayor escalabilidad Seguridad mejorada Disponibilidad mejorada Escalabilidad de Sí, pero sólo cuando se hayan Active Directory. actualizado todos los BDC y estén ejecutando Active Directory. Debe ser prudente a la hora de usar esta función, ya que pueden seguir añadiéndose BDC de Windows NT mientras el dominio está en modo mixto. Es una función que podría ser una parte importante de la planificación de fallback, por lo que no debe ponerse en peligro. Autenticación de Sí, para máquinas con Kerberos. Windows 2000. Sí. Microsoft Management Console (MMC, consola de gestión de Microsoft). Política de grupos. Sí, para DC y otras máquinas con Windows 2000 del dominio. Sí. Security Configuration Manager (SCM, administrador de configuración de seguridad). Replicación Sí, entre PDC y BDC que multimaestro de hayan sido actualizados. Active Directory. Grupos de Windows 2000 En la sección anterior hemos mencionado la nueva y mejorada funcionalidad de grupos de seguridad en Windows 2000. Windows 2000 soporta cuatro tipos de grupos de seguridad: • Locales. • Locales del dominio. • Globales. • Universales. Grupos locales Los grupos locales siempre han existido en Windows NT. Por lo que se refiere a sus miembros, pueden tener miembros de cualquier punto del bosque, de otros bosques de confianza e incluso de dominios de nivel bajo de confianza. En cuanto a los permisos para recursos, en cambio, sólo tienen el ámbito de la máquina, en el sentido de que sólo pueden usarse para conceder permisos para la máquina en la que existen. Un caso especial de los grupos locales de las versiones anteriores de Windows NT tiene que ver con los grupos locales creados en un PDC, que, por la replicación del SAM del dominio entre los BDC, hacía que estos grupos estuvieran compartidos entre el PDC y los BDC. En el modo mixto, 64 los grupos locales actúan del mismo modo en Windows NT y en Windows 2000; en el modo nativo, los grupos locales de un DC se convierten en grupos locales del dominio (que se describen en la sección siguiente). Normalmente, los grupos locales se usan para conceder acceso ad hoc a recursos de una máquina local. Grupos locales del dominio Los grupos locales del dominio son una nueva función de Windows 2000, aunque son similares en concepto y en uso a los grupos locales creados en el PDC de un dominio de Windows NT 4.0 (descritos más arriba). Los grupos locales del dominio sólo están disponibles en dominios en modo nativo. En cuanto a sus miembros, pueden tener miembros de cualquier punto del bosque, de otros bosques de confianza e incluso de dominios de nivel bajo de confianza. Los grupos locales del dominio sólo tienen el ámbito de la máquina en cuanto a permisos para recursos, por lo que sólo pueden usarse para conceder permisos dentro del dominio en el que existen. Se diferencian de los grupos locales en que pueden usarse en cualquier máquina con Windows NT dentro del dominio en el que fueron creados. Normalmente, los grupos locales del dominio se usan para englobar los principales de seguridad de todo el bosque a fin de controlar el acceso a los recursos del dominio. Grupos globales Los grupos globales de Windows 2000 son en realidad lo mismo que los grupos globales de Windows NT. En cuanto a sus miembros, tienen ámbito de dominio, pero pueden concedérseles permisos en cualquier dominio, incluso en otros bosques y dominios de nivel bajo, siempre que exista una relación de confianza. Grupos universales Los grupos universales tienen ámbito de bosque, es decir, pueden contener miembros de cualquier dominio de Windows 2000 del bosque y pueden concedérseles permisos en cualquier dominio, incluso en otros bosques, siempre que exista una relación de confianza. Aunque los grupos universales pueden tener miembros de dominios en modo mixto del mismo bosque, en el caso de los miembros de estos dominios no se añadirá el grupo universal a su token de acceso porque los grupos universales no están disponibles en modo mixto. Aunque puede añadir usuarios a un grupo universal, le recomendamos que limite los miembros a grupos globales. Los grupos universales sólo están disponibles en dominios en modo nativo. Uso de los grupos universales Los grupos universales tienen varios usos importantes. Puede usarlos para crear grupos que realicen una función común dentro de una empresa: un ejemplo podrían ser los equipos virtuales. La calidad de miembros de estos equipos en una gran empresa probablemente sería de ámbito nacional o incluso mundial y los recursos de los equipos estarían distribuidos de forma similar. Los grupos universales podrían usarse en estas circunstancias como contenedor de los grupos globales de cada filial o departamento, mientras que los recursos de los equipos estarían protegidos por una Access Control Entry (ACE, Entrada de Control de Acceso) única para el grupo universal. En el uso de grupos universales hay un factor importante que debe tenerse en cuenta: mientras que los grupos globales y los grupos locales del dominio aparecen en el Global Catalog (GC, Catálogo Global), sus miembros no aparecen, en tanto que los grupos universales y sus miembros sí aparecen, hecho que tiene consecuencias en el tráfico de replicación del GC. Como orientación, si toda su red tiene conectividad de alta velocidad, puede sencillamente usar los grupos universales para todos sus grupos y aprovecharse de no tener que molestarse en la gestión de los grupos globales y de los grupos locales del dominio. Sin embargo, si su red se extiende 65 mediante redes de área extendida (WAN), puede mejorar el rendimiento de varias maneras usando los grupos locales y los grupos locales del dominio. Si usa grupos globales y grupos locales del dominio, también puede designar los grupos de uso corriente que rara vez cambian como grupos universales. Grupos universales y tokens de acceso Al hablar de los miembros de grupos universales hemos mencionado el hecho de que pueden contener miembros de dominios en modo mixto, pero que estos miembros no tendrán SID de grupo universal en su token de acceso. Esto es consecuencia de cómo se crean los tokens de acceso en Windows 2000. Cuando un usuario inicia una sesión en un dominio en modo nativo con Windows 2000 y ha sido autenticado, la Local Security Authority (LSA, Autoridad de Seguridad Local) del DC en el que se autenticó el usuario recupera los miembros del grupo global del usuario. La LSA pasa entonces esta información a la estación de trabajo, donde se usa para crear el token de acceso del usuario. Al mismo tiempo, la LSA consulta al GC sobre los miembros del grupo universal del usuario, información que también pasa a la estación de trabajo. Si un usuario es miembro de un grupo universal, el SID de ese grupo se incluye en el token de acceso de la estación de trabajo y se añade a los datos de autorización del TGT emitido por el KDC. Los grupos universales no se añaden a los tokens de acceso en ningún otro momento, por ejemplo, cuando se crean tokens de imitación en los servidores miembros. En consecuencia, si el SID del grupo universal no está disponible cuando el usuario inicia la sesión —por ejemplo, cuando el usuario inicia una sesión en un dominio en modo mixto— no se añadirá posteriormente. Anidamiento de grupos Le recomendamos que no cree grupos de más de 5.000 miembros. Esta recomendación se basa en que las actualizaciones del almacén Active Directory deben poder hacerse en una sola transacción. Puesto que los miembros del grupo se almacenan en un único atributo multivalor, un cambio en los miembros obligaría a actualizar en una única transacción todo el atributo, es decir, toda la lista de miembros. Microsoft ha probado y soporta grupos de hasta 5.000 miembros. Puede obviar esta limitación anidando grupos para aumentar el número efectivo de miembros. Otra consecuencia es que también reducirá el tráfico de replicación provocado por la replicación de cambios en los miembros de los grupos. Las opciones de anidamiento dependen de que el dominio esté en modo nativo o en modo mixto. La lista siguiente describe lo que puede haber en un grupo que existe en un dominio en modo nativo. Estas reglas están determinadas por el ámbito del grupo: • Los grupos universales pueden contener cuentas de usuario, cuentas de ordenadores, otros grupos universales y grupos globales de cualquier dominio. • Los grupos globales pueden contener cuentas de usuario del mismo dominio y otros grupos globales del mismo dominio. • Los grupos locales del dominio pueden contener cuentas de usuario, grupos universales y grupos globales de cualquier dominio. También pueden contener otros grupos locales del dominio pertenecientes al mismo dominio. Los grupos de seguridad de un dominio en modo mixto sólo pueden contener lo siguiente: • Los grupos locales pueden contener grupos globales y cuentas de usuario de dominios de confianza. • Los grupos globales sólo pueden contener cuentas de usuario. Efectos de la actualización sobre los grupos Actualizar un PDC a Windows 2000 no tiene ningún efecto inmediato sobre los grupos. Los grupos locales de Windows NT pasan a ser grupos locales de Windows 2000 y los grupos 66 globales de Windows NT pasan a ser grupos globales de Windows 2000. El verdadero cambio se produce cuando el dominio pasa a modo nativo, momento en el que los grupos locales del PDC pasan a ser grupos locales del dominio. Como ya se ha dicho, cuando se ha autenticado un usuario se crea un token de acceso para ese usuario que contiene el SID primario y los SID de todos los grupos a los que pertenece. Hemos señalado que los grupos locales del PDC son un caso especial en Windows NT, que se refleja en cómo es el token de acceso de un usuario miembro de uno de estos grupos cuando se crea en la estación de trabajo del usuario después de un inicio de sesión interactivo o en un DC con fines de imitación del usuario y para conceder acceso a los recursos. Puesto que los grupos locales del PDC no tienen alcance fuera del PDC y de los BDC del dominio, el token de acceso del usuario en la estación de trabajo no contiene el SID de ese grupo. Cuando el usuario intenta acceder a los recursos de un DC, sin embargo, el token de imitación creado para el usuario en el DC sí contiene los SID de los grupos locales del PDC de los que sea miembro el usuario. Cuando el dominio pasa a modo nativo y puesto que los grupos locales del dominio tienen ámbito en el dominio, los SID de los grupos locales del dominio de los que sea miembro el usuario se añaden al token de acceso del usuario, aunque el usuario esté iniciando la sesión de forma interactiva en una estación de trabajo. Tabla 2. Grupos y modo de los dominios. Tipo de grupo Miembros Ámbito ¿Disponible en modo mixto? Local. Miembros: • del mismo bosque. • de otros bosques de confianza. • de dominios de confianza de nivel bajo. Miembros del dominio local. Máquina. Sí. Cualquier dominio de confianza. El dominio local. Sí. Global. Local dominio. Universal. del Miembros: • del mismo bosque. • de otros bosques de confianza. • de dominios de nivel bajo de confianza. Miembros del mismo bosque. No. Cualquier No. dominio de confianza en modo nativo. NetBIOS y Windows Internet Name Service (WINS) en Windows 2000 NetBIOS es una interfaz de programación en red de alto nivel que se utiliza en los componentes de red de Microsoft desde finales de los años 80. Los recursos de red se identifican en el espacio 67 de nombres de NetBIOS mediante nombres de NetBIOS únicos. WINS es un servicio que se ofrece como parte de Windows NT Server para el registro de asignación dinámica de nombres de NetBIOS en direcciones de IO y para proporcionar resolución de nombres de NetBIOS. Con la aparición de Windows 2000, el soporte para la interfaz de asignación de nombres de NetBIOS ya no es necesaria para ordenadores en red y esto, unido al estrecho acoplamiento de Active Directory y Domain Naming System (DNS), hará que el uso de NetBIOS disminuya con el tiempo. Hasta entonces, la actualización del dominio a Windows 2000 no evita la necesidad de soporte de NetBIOS en su red ni afecta al grado de soporte que tiene actualmente. Después de la actualización puede pensar en abandonar el uso de NetBIOS y WINS si se cumplen las siguientes condiciones: • No hay clientes como Windows for Workgroups, Windows 9x o Windows NT 4.0 ni servidores con Windows NT 4.0 que usen NetBIOS. Es posible que su red necesite aún nombres de NetBIOS para proporcionar servicios básicos de archivos e impresión y soporte para muchas aplicaciones heredadas usadas en ordenadores cliente que usen versiones anteriores de los sistemas operativos Windows. Debe valorar el impacto de las aplicaciones y servicios heredados en su plan de prueba: • Tiene una red pura de Windows 2000 y está seguro de que todos los ordenadores y aplicaciones de su red pueden funcionar usando otro servicio de nombres, como DNS. Los nombres de red son un servicio vital para localizar ordenadores y recursos de la red, incluso donde no se precisen nombres de NetBIOS. El cliente WINS de Windows 2000 pone en caché los nombres resueltos localmente y utiliza un componente llamado Caching Resolver para mirar en esta caché antes de enviar una consulta a DNS. El archivo host se pone en caché tan pronto como se pone en marcha el cliente y cualquier actualización del archivo host se refleja en la caché inmediatamente. La secuencia de resolución de nombres es la siguiente: 1. Intentar la resolución de nombres desde la caché cliente. 2. Si falla la resolución desde el cliente, éste la intenta a través de DNS. 3. Si falla la resolución de nombres de DNS, el cliente la intenta a través de WINS. En consecuencia, suponiendo que haya implementado un control del cambio suficiente en los clientes al actualizarlos y una vez que se hayan eliminado todas las condiciones heredadas, el abandono de NetBIOS y WINS debería hacerse sin dificultades. Disponibilidad de LAN Manager Replication Service (LMRepl) Windows NT Server proporcionaba una función de replicación denominada LAN Manager Replication (LMRepl). LMRepl suele usarse para replicar las secuencias de comandos de inicio de sesión desde un DC de exportación a varios DC de importación del dominio. El File Replication Service (FRS, Servicio de Replicación de Archivos) sustituye a este servicio en Windows 2000 Server. Windows 2000 Server no soporta LMRepl en modo mixto ni nativo, por lo que si ha usado LMRepl tendrá que incluir en su plan de actualización una estrategia para usar FRS y proporcionar la misma funcionalidad. El proceso LMRepl LMRepl utiliza el concepto de directorios de importación y directorios de exportación. Un administrador puede configurar LMRepl seleccionando un servidor en el que alojar un directorio de exportación y varios servidores para alojar los directorios de importación. Los servidores que alojan los directorios no tienen por qué ser DC: pueden ser servidores miembros normales. 68 Figura 4. El proceso LMRepl ******************************************** Exportación: Exportación: Importación: Directorio1 Directorio1 Directorio2 Directorio2 Directorio3 Importación: Directorio3 BDC serv. 1 BDC serv. 2 Exportación: Exportación: Directorio3 Importación: Importación: Directorio1 Directorio1 Directorio2 Directorio2 Directorio3 PDC serv. 3 Miembro serv. 4 ******************************************** El proceso FRS El FRS (File Replication Service) de Windows 2000 Server se configura automáticamente de forma que todos los controladores del dominio tienen un System Volume (SYSVOL) replicado. Cualquier cambio que haga en un guión de inicio de sesión almacenado en el SYSVOL de cualquier controlador del dominio se replica de forma multimaestro en otros controladores del dominio. A diferencia de LMRepl y del alojamiento de directorios de importación y exportación, en FRS sólo los controladores del dominio pueden alojar el SYSVOL. 69 Figura 5. El proceso FRS. ******************************************** SYSVOL SYSVOL Serv. 5 Serv. 7 Controlador del dominio Controlador del dominio Configuración de Active Directory, conocimiento y topología SYSVOL SYSVOL Serv. 6 Serv.8 Controlador del dominio Controlador del dominio ******************************************** Mantener los servicios de LMRepl en un entorno mixto Como ya hemos visto, durante una actualización puede tener un entorno mixto de BDC y servidores de Windows NT 4.0 funcionando con controladores de dominio de Windows 2000. Puesto que Windows 2000 Server no soporta LMRepl, mantener los servicios de LMRepl en un entorno mixto puede suponer un problema. Para lograr este soporte tendrá que crear un puente entre LMRepl y FRS para que funcionen ambos servicios. Esto puede hacerse seleccionando un DC de Windows 2000 DC cuyo SYSVOL se usaría para popular el directorio de exportación del BDC de Windows NT que aloja LMRepl. Microsoft facilita un guión sencillo que puede programarse periódicamente para que realice la copia de archivos necesaria. LMRepl y actualización Para mantener la disponibilidad de LMRepl durante la actualización debe comprobar que el servidor que aloja el directorio de exportación se actualiza sólo después de haber actualizado los demás servidores que alojan los directorios de importación. Si el servidor que aloja el directorio de exportación es el PDC, debe seleccionar otro servidor de exportación y reconfigurar LMRepl. Usar Remote Access Services (RAS; Servicios de Acceso Remoto) en un entorno mixto Si utiliza RAS para proporcionar a los usuarios acceso remoto a la red corporativa, tal vez le interese estudiar la actualización de su servidor RAS en las primeras fases del proceso de actualización de los servidores miembros. La razón es que Windows NT comprueba las propiedades de RAS, como la disponibilidad del acceso a RAS o dial-back para un usuario. 70 RAS es un ejemplo de un servicio de Windows NT. Un servicio es un tipo de proceso en segundo plano, diseñado para funcionar continuamente sin interfaz de usuario, normalmente realizando alguna clase de función de servidor como servidor de Web o servidor de FTP. Puesto que el servicio debe funcionar incluso cuando no hay usuarios conectados al sistema, funciona en el contexto de seguridad de una cuenta de servicios especial, normalmente la cuenta de sistema, que también se conoce como LocalSystem. La cuenta de sistema es una cuenta especial que sólo conoce la máquina local y tiene todos los privilegios disponibles en el sistema operativo. Cuando un servicio se conecta como LocalSystem, se conecta con credenciales NULL. En otras palabras, no facilita nombre de usuario ni contraseña. Esto quiere decir que esta cuenta no puede usarse para acceder a los recursos de red que se basan en la autenticación NTLM a menos que la máquina remota permita el acceso con credenciales NULL (a esto suele llamarse sesión NULL). En Windows NT, RAS usa la cuenta LocalSystem. Por defecto, Active Directory no aceptará consultas de atributos de objetos a través de sesiones NULL, por lo que en un entorno mixto de un servidor RAS de Windows NT no podrá recuperar las propiedades RAS de un usuario a menos que se cumplan las siguientes condiciones: • El dominio está en modo mixto y el servidor RAS de Windows NT es también un BDC. En este caso RAS tendrá acceso local al SAM. • El dominio está en modo mixto y el servidor RAS de Windows NT se pone en contacto con un BDC de Windows NT, lo que daría lugar a un comportamiento idéntico al comportamiento actual en Windows NT. Esto podría dar lugar a ciertas incoherencias de comportamiento. • El dominio está en modo mixto o en modo nativo y la seguridad de Active Directory se ha reducido para conceder los permisos Everyone de personalidad incorporados para leer cualquier propiedad de cualquier objeto de usuario. El asistente de instalación de Active Directory (DCPROMO) permite al usuario seleccionar esta configuración mediante una opción de reducir los permisos para determinados objetos de Active Directory. Sólo debe recurrir a esta última solución después de estudiar cuidadosamente sus repercusiones sobre la seguridad de Active Directory. Si cree que entra en conflicto con sus requisitos de seguridad, deberá adoptar el enfoque recomendado, que es actualizar el servidor RAS de Windows NT a Windows 2000 y hacerlo miembro de un dominio mixto o nativo de Windows 2000. Esto tendría también la ventaja de evitar el comportamiento incoherente mientras el dominio está en modo mixto, según se describe en la segunda condición. En su plan de actualización debe tener en cuenta estos factores, porque una de las consecuencias es que deberá estudiar primero la actualización del servidor RAS dentro del proceso de actualización de servidores. Rutas de actualización soportadas Una consideración importante en la planificación de la actualización a Windows 2000 serán los sistemas operativos que ya tiene instalados en su empresa y si es posible actualizarlos directamente a Windows 2000. La tabla 3 siguiente contiene una lista de rutas de actualización soportadas para Windows 2000. En los casos en que se precise una actualización pero no sea posible la actualización directa, tendrá que hacerla a través de otro sistema operativo, como Windows 9x, Windows NT 3.51/4.0 para estaciones de trabajo o Windows NT 3.51/4.0 para servidores. Esto debe quedar reflejado en su plan de actualización. Tabla 3. Rutas de actualización soportadas. Plataforma. Actualización a Windows 2000 Professional. Actualización a Windows 2000 Server. 71 Windows 3.x Windows NT 3.1 Windows NT 3.1 Advanced Server Windows NT 3.51 Workstation Windows NT 3.51 Server Windows 9x Windows NT 4.0 Workstation Windows NT 4.0 Server No No No No No No Sí No No Sí Sí Sí No No No Sí Orden de la actualización de dominios Hasta ahora nos hemos ocupado del orden de la actualización de los DC de un dominio. En este aspecto no hay mucho que decir: primero hay que actualizar el PDC y luego los BDC. Es más problemática la cuestión de qué dominio actualizar primero y la respuesta puede variar en cada circunstancia. Por ejemplo, si está planificando que desaparezcan determinados dominios, no tendrá mucho sentido actualizarlos primero. Aunque su situación pueda ser otra, en general recomendamos tener presente el orden siguiente para la actualización de dominios: 1. Dominios de cuentas. 2. Dominios de recursos. 72 Actualizar dominios de cuentas Por norma general le resultará más beneficioso actualizar los dominios de cuentas antes, porque en la mayoría de los casos habrá que administrar más usuarios que ordenadores. Actualizando sus dominios de cuentas a Windows 2000 se beneficiará de: • Escalabilidad mejorada de Active Directory. Muchas organizaciones están sobrepasando los límites máximos de tamaño del SAM recomendados en su cifra actual de usuarios y de grupos. • Administración delegada. Posibilidad de delegar la capacidad administrativa con granularidad muy fina, sin que sea necesario otorgar poder absoluto. Orden de los dominios de cuentas Si tiene más de un dominio de cuentas, las directrices siguientes le ayudarán a elegir en qué orden actualizarlos: • Mantener el control. Aunque haya probado su estrategia de actualización en un laboratorio o en un programa piloto, la primera migración real será la más peligrosa. Para reducir los riesgos debería actualizar los dominios donde sea más sencillo el acceso a los DC. • Reducir los riesgos y las interrupciones. Si hay varios dominios entre los que elegir en determinada situación, actualice primero el más pequeño para reducir al mínimo las interrupciones para el mayor número posible de usuarios, sobre todo mientras va conociendo el proceso. • Hacer bien el trabajo. Cuando ya tenga experiencia y confianza en el proceso, pase a dominios de cuentas más grandes. • Destinos de la reestructuración de los dominios de cuentas. Si está planificando reestructurar sus dominios, deberá actualizar los destinos probables de la reestructuración en las primeras fases del proceso. No podrá consolidar dominios en un destino que no existe. Orden de los dominios de recursos Si tiene más de un dominio de recursos, las directrices siguientes le ayudarán a elegir en qué orden actualizarlos: • Proporcionar las funciones que necesitan las aplicaciones. Primero debe actualizar los dominios en los que tenga instaladas aplicaciones que precisen infraestructura o funciones de Windows 2000, como Active Directory, que precisa Microsoft Exchange Platinum (la próxima gran versión de Microsoft Exchange). • Dominios con muchas estaciones de trabajo. Después deberá actualizar los dominios con muchas estaciones de trabajo, para poder aprovechar la infraestructura de Windows 2000, como Microsoft IntelliMirror. • Destinos de la reestructuración de los dominios de recursos. Igual que con los dominios de cuentas, si está planificando reestructurar sus dominios, deberá actualizar los destinos probables de la reestructuración bastante al principio. Actualizar estaciones de trabajo y servidores Aunque este documento se centra principalmente en la actualización y la consolidación de dominios, no debe entenderse que las instalaciones de estaciones de trabajo y servidores miembros de Windows 2000 deba posponerse hasta haber actualizado la infraestructura de dominios. Usar estaciones de trabajo y servidores de Windows 2000 en un entorno existente de Windows NT seguirá ofreciendo varios beneficios. Reestructuración de dominios La actualización de dominios es un proceso diseñado para mantener en lo posible el entorno actual, incluida la estructura de dominios. La reestructuración de dominios, por otra parte, es un proceso diseñado para que pueda rediseñar el bosque según las necesidades de su organización. Aunque la reestructuración puede producir varios resultados distintos, normalmente el resultado 73 es una cierta racionalización de la estructura actual y tal vez el cambio a menos dominios grandes. Antes había distintas herramientas de terceros para la gestión de directorios que han proporcionado soporte para la reestructuración de dominios en Windows NT. Por primera vez Windows 2000 proporciona funcionalidad nativa para habilitar escenarios de reestructuración de dominios, como son: • Los principales de seguridad pueden trasladarse de un dominio a otro manteniendo al mismo tiempo el acceso a los recursos previo a este traslado. • Los DC pueden trasladarse de un dominio a otro sin la reinstalación completa del sistema operativo. Microsoft tiene una herramientas gráfica que facilita la reestructuración de dominios, junto con algunos componentes COM aptos para secuencias de comandos y líneas de comandos para simplificar las operaciones de reestructuración. Resultarán útiles a muchos clientes que vayan a implementar los escenarios que se describen a continuación. ¿Cuándo debe reestructurar? La reestructuración resulta apropiada en tres tipos de circunstancias: • Después de actualizar. El momento más habitual para que las organizaciones reestructuren sus dominios será en la segunda fase de migración a Windows 2000, después de una actualización. La actualización habrá abarcado casos de migración “más fáciles”, como los grupos de dominios en los que la estructura de confianza es esencialmente correcta y en los que no hay consecuencias administrativas. En estas circunstancias, la reestructuración probablemente se dirigirá a remodelar otras partes de la estructura de dominios para reducir su complejidad o bien a trasladar dominios de recursos con administradores sin relación de confianza al bosque de una manera segura. • En vez de actualizar. Es posible que algunas organizaciones crean que su estructura de dominios actual es, por alguna razón, irrecuperable o que no pueden permitirse poner en peligro la estabilidad del entorno de producción actual durante la migración. En estos casos, la ruta de migración más sencilla podría ser diseñar y construir un entorno ideal o prístino de Windows 2000 independiente del entorno de producción actual. En esta situación, el nuevo bosque de Windows 2000 está pensado para convertirse, con el tiempo, en entorno de producción. Una vez construido el nuevo bosque, la reestructuración comenzará con un programa piloto en el que se migran al nuevo entorno varios usuarios, grupos y recursos para actuar como avanzadilla y garantizar que la actividad puede desarrollarse como siempre en la nueva estructura. Cuando esta fase se culmina con éxito, el programa pasa a una migración en fases al nuevo entorno. En un momento dado Windows 2000 se convertirá en el entorno de producción. La estructura de dominios anterior dejará de usarse y volverán a instalarse los recursos restantes. • Después de la migración. En este caso la reestructuración se produce como parte de un rediseño general de los dominios en un entorno de Windows 2000 exclusivamente. Esto podría producirse al cabo de varios años, cuando, por algún motivo, como un cambio organizativo o una adquisición corporativa, la estructura existente resulta inadecuada. El contenido principal de este capítulo es la migración inicial de Windows NT 4.0 a Windows 2000, esto es, los dos primeros casos. 74 Figura 6. Cuándo puede producirse la reestructuración. Upgrade Upgrade Restructure Restructure ¿Por qué reestructurar? Puede haber varias razones por las que se desee realizar una reestructuración de los dominios, aunque Migration Post-migration probablemente el motivo Pre-migration Windows 2000 principal sea aprovechar Environment Native Mode las funciones de Windows 2000 que le permiten estructurar mejor sus dominios y así reflejar los requisitos de su organización, como son las siguientes: • Mayor escalabilidad. Es posible que hubiese diseñado su estructura anterior de dominios de Windows NT con las limitaciones de tamaño de la base de datos de cuentas del SAM, lo cual le llevaría a implementar un modelo de dominio maestro o multimaestro. Con el enorme aumento de escalabilidad de Active Directory, que escala literalmente a millones de cuentas o grupos de usuarios, podría reestructurar sus dominios actuales de Windows NT en menos dominios de Windows 2000 más grandes. Restructure • Granularidad más fina de la administración. Es posible que en su modelo actual haya implementado dominios de recursos para permitir la delegación de la responsabilidad administrativa. Las OU de Windows 2000 pueden contener cualquier tipo de principal de seguridad y la administración puede delegarse como corresponda. En muchos casos, la conversión de los dominios de recursos en OU será un método más adecuado para delegar la administración. • Administración más sencilla. Para permitir la delegación del modo que se ha descrito, o tal vez como resultado de una adquisición corporativa, es posible que su estructura de dominios deba conectarse mediante una compleja malla de relaciones de confianza. Algunos de estos dominios podrían estar mejor implementados como OU, lo que simplificaría la administración. También podría rediseñar el árbol de dominios y beneficiarse de tener menos relaciones de confianza transitivas bidireccionales. Los escenarios que describiremos no presuponen que haya terminado una actualización inicial. Consecuencias de la reestructuración de dominios Los factores fundamentales que posibilitan la reestructuración de escenarios son, como ya se ha dicho, la posibilidad de mover los principales de seguridad y los DC entre dominios. En esta sección estudiaremos las consecuencias de estas características y la repercusión que tienen sobre la planificación de la reestructuración. Efecto de mover principales de seguridad en los SID Antes hemos mencionado la naturaleza de los SID, que está relacionada con el dominio. Como consecuencia de ello, cuando mueva de un dominio a otro un principal de seguridad, como un usuario o un grupo, tendrá que emitirse un nuevo SID para el nuevo dominio. Como vimos en la sección sobre actualización, para que se produzca el acceso a los recursos en el modelo de seguridad de Windows NT, el sistema operativo consulta el token de acceso del usuario y evalúa el SID primario del usuario y los SID de todos los grupos de los que sea 75 miembro el usuario y hace una comparación con la ACL del descriptor de seguridad del recurso. Las ACL están constituidas por listas de SID que indican la concesión o la denegación del acceso al recurso para los principales de seguridad identificados por los SID. Así, el cambio del SID tiene consecuencias de gran alcance. Para ilustrar estas consecuencias, basándonos en lo que sabemos de la seguridad de Windows NT, recurriremos a un ejemplo. Bob trabaja en Hay Buv Toys y tiene una cuenta en el dominio maestro de Windows NT 4.0 HAYBUV-ACCT. Bob es miembro del grupo global Finance Analysts en este mismo dominio. Hay Buv Toys usa una aplicación financiera basada en Win32 que se ejecuta en varias máquinas con Windows NT Server en el dominio de recursos HAYBUV-RES1. Para aprovechar el hecho de que los grupos locales creados en el PDC están compartidos por todos los DC del dominio, los servidores en los que se ejecuta la aplicación funcionan como BDC en el dominio. Se ha creado en el PDC un grupo local compartido llamado Financial Resources que se usa en las ACL de los archivos que utiliza la aplicación. El grupo global HAYBUV-ACCT\Finance Analysts es miembro de HAYBUV-RES1\Financial Resources. Bob tiene acceso también a un servidor de archivos, FIN_FILES1, en el dominio de recursos. FIN_FILES1 es sencillamente una máquina con Windows NT Server que actúa como servidor miembro. FIN_FILES1 utiliza un grupo local llamado Finance Files en las ACL de archivos relacionados con el grupo de Bob. HAYBUV-ACCT\Finance Analysts es miembro de FIN_FILES1\Finance Files. Bob trabaja en algunos proyectos personales y tiene un directorio en FIN_FILES1 que está protegido para que sólo él pueda acceder a los archivos que contiene. Este directorio tiene una ACL que contiene una única entrada que permite a Bob tener control pleno del directorio. RESKIT-ACCT Figura 7. Ejemplo de acceso a los recursos. Access Token User: RESKIT-ACCT\Bob Groups: RESKIT-ACCT\ Finance Analysts …. Mover los principales de seguridad ACL Como ya se ha RESKIT-RES1 señalado, mover un BDC principal de seguridad ACL Finance BDC ACL Application FIN_FILES1 de un dominio a otro Finance Application hace que cambie el SID de ese principal de seguridad. Podemos comprobar las repercusiones de mover principales de seguridad viendo qué pasaría si la cuenta de Bob se moviera a otro dominio dentro de una migración que implique una reestructuración del dominio. Para este ejemplo imaginaremos que HAYBUV-ACCT ha sido actualizado a Windows 2000 y se ha unido al nuevo bosque de Windows 2000 de la corporación como hijo del dominio raíz HAYBUV.TLD. HAYBUV-ACCT se ha cambiado a modo nativo, pero está previsto reestructurarlo y mover sus miembros a un nuevo dominio de Windows 2000, HAYBUV-ACCT2, en otro punto del bosque. FIN_FILES1\Finance Files RESKIT-RES1\Finance Resources RESKIT-ACCT\Bob Efectos del movimiento sobre la pertenencia de Bob al grupo global HAYBUV-ACCT\Bob es miembro del grupo global HAYBUV-ACCT\Finance Analysts. Como un grupo global sólo puede contener miembros de su propio dominio, el movimiento de Bob al 76 nuevo dominio supondría que su nueva cuenta no podría formar parte de este grupo, lo cual implica que perdería el acceso a los recursos disponibles para este grupo. Suponiendo que existiera una relación de confianza suficiente entre el dominio nuevo y el dominio de recursos, vemos que podríamos resolver el problema de varias formas: • Añadiendo el nuevo SID de Bob a las ACL de recursos. Podríamos mantener el acceso a los recursos añadiendo el nuevo SID de Bob a las ACL de todos los recursos a los que antes tenía acceso como miembro del grupo. Esto llevaría mucho tiempo y sería complicado por varias razones: • Muchas operaciones de reestructuración de dominios se realizarán paulatinamente a lo largo de un tiempo y durante este período de transición no podríamos garantizar que no se crearan nuevos recursos para el grupo Finance Analysts. Debido a esto, tendríamos que seguir renovando los permisos durante los períodos de la migración mientras coexistieran los dos grupos. • Microsoft recomienda usar los grupos, en vez de los individuos, en las ACL. La razón es que la pertenencia a grupos que desarrollan trabajos específicos puede cambiar con el tiempo, y es más fácil sacar a un usuario del grupo que cambiar las ACL de muchos recursos que hacen referencia al usuario. ¿Qué ocurriría si el trabajo de Bob cambiara y ya no necesitara ser miembro del grupo Finance Analysts? • Moviendo el grupo. Igual que podemos mover principales de seguridad en Windows 2000, podríamos mover el propio grupo al nuevo dominio. Sin embargo, como las ACL que hacen referencia al grupo también hacen referencia a su SID, tendríamos que hacer algo parecido a lo que ocurría en la primera opción: tendríamos que renovar los permisos para los recursos que hacen referencia al nuevo SID. • Creando un grupo paralelo en el dominio de destino. Si moviéramos el grupo se produciría un problema si el plan de migración no contemplara mover todos los miembros del grupo en una sola transacción. Esto significaría que habría que mantener el grupo en el dominio antiguo y crear un grupo paralelo en el dominio nuevo. Se mantendría el acceso a los recursos para el grupo original y sus miembros, pero tendríamos que renovar el permiso para los recursos a fin de conceder acceso al nuevo grupo. Una vez más tendríamos que seguir renovando los permisos mientras el grupo existiera en ambos dominios. Efectos del movimiento sobre las ACL que hacen referencia directamente a Bob Bob tiene igualmente acceso a algunos recursos del servidor miembro FIN_FILES directamente. Su SID aparece en las ACL de esa máquina. Es perfectamente admisible añadir usuarios a las ACL de recursos, pero una de las consecuencias del movimiento de Bob parecería a primera vista que exige renovar los permisos sobre los recursos de ese servidor, añadiendo su SID del nuevo dominio. Microsoft siempre ha aconsejado usar grupos en vez de individuos en las ACL de recursos. En muchas organizaciones, sin embargo, puede que esto no se haya hecho, lo que se traduciría en la necesidad de buscar y actualizar todas las referencias a un usuario que se ha movido en todas las ACL de los recursos de toda la organización. SIDhistory En muchos casos, las actividades que acabamos de describir resultan innecesarias gracias a un nuevo atributo de directorios de Windows 2000 llamado SIDhistory. SIDhistory es un atributo de los principales de seguridad de Active Directory que se usa para almacenar los SID antiguos de los objetos movidos, como usuarios y grupos de seguridad. Cuando se mueve un usuario o un grupo usando las nuevas API de Win32 o las utilidades básicas proporcionadas por Microsoft y se construye encima de ellos, el atributo SIDhistory del objeto que lo representa en Active Directory se actualiza con su SID anterior como parte de la operación. Cuando el usuario inicia una sesión en el sistema, así como los grupos de los que el 77 usuario es miembro, el sistema recupera las entradas de SIDhistory del usuario y las añade al token de acceso del usuario. Como los grupos pueden moverse, el sistema recupera también los atributos de SIDhistory de todos los grupos de los que es miembro el usuario y los añade al token de acceso del usuario. Estas entradas de SIDhistory del token se presentan al sistema como pertenencia normal a grupos durante las comprobaciones de autorización, por lo que pueden conceder un acceso apropiado incluso en sistemas de nivel bajo que no usan Windows 2000 ni Active Directory. Access Token HAYBUV-ACCT2\Bob User: S-1-5-21-397955417-626881126-188441444-2812048 SIDhistory HAYBUV-ACCT\Bob Groups: S-1-5-21-1645522239-1957994488-725345543-1108 HAYBUV-ACCT2\Finance Analysts S-1-5-21-397955417-626881126-188441444-101018 SIDhistory HAYBUV-ACCT\Finance Analysts S-1-5-21-1645522239-1957994488-725345543-1109 …. SIDhistory grants access for moved user ACL on FIN_FILES1 Allow RW HAYBUV-ACCT\Bob Allow RW S-1-5-21-1645522239-1957994488-725345543-1108 Figura 8. Acceso a recursos concedido a través de SIDhistory Mover usuarios y grupos mientras se actualiza SIDhistory usando MoveTree.exe MoveTree es el nombre de una utilidad básica para migración de dominios disponible en Windows 2000 Beta 3. Permite mover objetos de directorios, incluidos los principales de seguridad, entre dominios de Windows 2000 del mismo bosque. Al propio tiempo, actualiza el SIDhistory de los usuarios o los grupos movidos. MoveTree moverá objetos como OU, grupos y cuentas de usuarios y de ordenadores. Limitaciones del uso de MoveTree El uso de MoveTree tiene algunas limitaciones. Esta utilidad precisa: ü Dominio de origen en modo mixto o nativo. El dominio desde el que va a moverse el objeto (origen) debe ser un dominio de Windows 2000 en modo mixto o nativo. ü Dominio de destino en modo nativo. El dominio al que va a moverse el objeto (destino) debe ser un dominio de Windows 2000 en modo nativo. ü Dominios de origen y de destino. Deben estar en el mismo bosque. ü Grupos globales vacíos. Aunque MoveTree moverá la OU y su contenido y, con un dominio de origen en modo nativo, grupos universales y su contenido, sólo moverá grupos globales vacíos. Por ahora, para usar MoveTree es necesario dejar vacíos los grupos globales antes de moverlos y luego volver a rellenarlos en el destino. ü Conjuntos cerrados. Los objetos deben estar en conjuntos cerrados. El significado de este término depende de que estemos refiriéndonos al movimiento de usuarios y grupos 78 globales o del movimiento de ordenadores, que podrían usar grupos locales compartidos en el caso de los DC de Windows NT o grupos locales del dominio en el caso de DC, servidores y estaciones de trabajo de Windows 2000 en un dominio en modo nativo. Conjuntos cerrados y mover usuarios y grupos globales Como vimos antes, un grupo global sólo contiene miembros de su propio dominio. Para mantener el acceso a recursos protegidos por ACL que hacen referencia a grupos globales, cuando un usuario se mueve de un dominio a otro también hay que mover todos los grupos globales de los que sea miembro el usuario. De ello se deduce que si se mueve un grupo global también hay que mover sus miembros. En este caso, un conjunto cerrado de usuarios y grupos locales es un conjunto en el que, por cada usuario que se mueve, se mueven también todos sus grupos globales y, por cada grupo que se mueve, se mueven también todos sus miembros. Si el dominio de origen es un dominio en modo nativo, los grupos globales podrán contener también otros grupos locales, en cuyo caso, por cada grupo anidado, deben moverse todos sus miembros y todos los grupos globales de los que aquéllos sean miembros. Conjuntos cerrados y mover ordenadores Los grupos locales compartidos y los grupos locales del dominio sólo tienen ámbito dentro del dominio en el que fueron creados. Si se mueve uno de estos grupos, no podrían resolverse las referencias al grupo en las ACL del dominio de origen. En este caso, un conjunto cerrado de ordenadores y grupos locales compartidos o del dominio es un conjunto en el que, por cada uno de estos grupos que se mueva, se mueven también todos los ordenadores del dominio que contengan ACL que referencien el grupo. Asimismo, por cada ordenador que se mueve, se mueven también todos los grupos locales compartidos o del dominio referenciados en ACL de sus recursos. Cómo trabajar con los conjuntos cerrados Las restricciones del movimiento de grupos globales populados y conjuntos cerrados son especialmente molestas. Despopular y repopular grandes grupos globales puede llevar mucho tiempo y, en algunos casos, el conjunto cerrado más pequeño que pueda conseguirse será el dominio de origen en su totalidad. En tales casos hay tres posibles formas de resolver el problema: • Grupos paralelos. Crear grupos globales paralelos en el dominio de destino por cada grupo que vaya a moverse, después localizar todos los recursos de la empresa que contengan ACL que hagan referencia al grupo original y renovar los permisos para incluir la referencia al grupo paralelo. Si se trata de mover grupos globales, caso en el que el grupo podría estar referenciado en recursos de cualquier dominio de confianza, o grupos locales del dominio de dominios de origen en modo nativo, donde los grupos locales del dominio pueden usarse en cualquier máquina de éste, es muy posible que la tarea resulte considerable. • Grupos universales. Cambiar el dominio de origen a modo nativo y cambiar después el tipo de grupo de los grupos que van a moverse a universal. Puesto que los grupos universales tienen ámbito en todo el bosque, cambiar los grupos a grupos universales significa que podrán moverse de forma segura manteniendo al mismo tiempo el acceso a los recursos que queden atrás. Si se usa esta solución hay que tener cuidado porque, como ya vimos antes, los miembros de un grupo universal se almacenan en el GC, lo cual repercute en el tráfico de replicación del GC. Debido a esto, tal vez prefiera usar esta solución como estrategia transitoria mientras se migran los usuarios y los grupos al nuevo dominio. Después, cuando se haya terminado la migración, los grupos vuelven a ser del mismo tipo que antes. 79 • Clonación. Clonar grupos del dominio de origen en el dominio de destino y conservar al mismo tiempo el SIDhistory. Esta técnica tiene ciertas limitaciones propias: nos ocupamos de ella en la sección “Clonar principales de seguridad”. Clonar principales de seguridad Hasta ahora hemos considerado que la reestructuración se puede realizar moviendo principales de seguridad. En ciertos sentidos, mover principales de seguridad puede entenderse como una operación destructiva, porque al mover el principal de seguridad estamos impidiendo el fallback a la cuenta antigua en caso de que se produzcan problemas durante la migración. Muchos clientes han manifestado su deseo de poder hacer una migración paulatina de los usuarios a un nuevo dominio de Windows 2000 y mantener al mismo tiempo las cuentas de usuarios antiguas en el dominio de origen para la recuperación de un desastre que pudiera producirse durante la migración piloto o en masa. Esta funcionalidad se denomina clonación, una función que Microsoft ha activado en Windows 2000 Beta 3. Microsoft proporciona algunas utilidades básicas denominadas ClonePrincipal, que permite clonar un usuario o un grupo de un dominio de origen de Windows NT 4.0 o Windows 2000 a un dominio en modo nativo de Windows 2000 sin suprimir la cuenta de origen. Al mismo tiempo, esta utilidad añade el SID de la cuenta original al SIDhistory de la nueva cuenta para mantener el acceso a los recursos. ClonePrincipal ClonePrincipal es un componente apto para secuencias de comandos que permite la clonación de principales de seguridad junto con secuencias de comandos de muestra utilizables que ilustran el uso del componente. Estas secuencias de comandos podrán ser personalizadas por aquellos administradores que tengan conocimientos de Microsoft Visual Basic (VB). Puesto que la clonación es una operación de seguridad delicada, el uso de ClonePrincipal tiene algunas limitaciones: • Los dominios de origen y de destino no pueden estar en el mismo bosque. • El SID de la cuenta de origen no debe existir ya en el bosque de destino como SID primario ni en el SIDhistory de ningún principal de seguridad. • Para ejecutar ClonePrincipal el usuario debe tener privilegios de administrador de dominio tanto en el dominio de origen como en el destino. • La auditoría debe estar activada en el dominio de destino. Se recomienda activarla también en el dominio de origen. Establecer relaciones de confianza En escenarios de clonación en los que los dominios de origen y de destino están en bosques distintos, establecer las relaciones de confianza necesarias para garantizar el acceso a los recursos será uno de los primeros pasos. Netdom.exe es una herramienta que se incluye en el kit de recursos de Windows 2000 Server para llevar a cabo tareas como enumerar las relaciones de confianza de los dominios y establecer otras nuevas. Esta herramienta es también útil para crear cuentas de máquinas y actualizar los miembros del dominio de una estación de trabajo o de una máquina servidor. Mover servidores En el ejemplo anterior, Bob tiene acceso a algunos recursos del servidor miembro FIN_FILES1, mediante las ACL que referencian un grupo local de máquinas, FIN_FILES1\Finance Files, y su cuenta de dominio directamente. Ya hemos visto las consecuencias de mover los DC, como la necesidad de garantizar que se mantienen los grupos locales compartidos y los grupos locales del dominio, pero, ¿qué consecuencias tiene mover un servidor miembro como FIN_FILES1 o una estación de trabajo?. Suponiendo que el servidor se moviera a un dominio con relación de confianza con el nuevo dominio de cuenta de Bob, hemos visto que SIDhistory garantizaría que Bob tuviera acceso a los 80 recursos con ACL que lo referencien directamente. Las ACL que hacen referencia al grupo local de máquinas también seguirían funcionando porque el grupo existe en la base de datos de cuentas de la máquina local. Así pues, no se ve afectado por el movimiento y no habría que cambiar su SID. Windows NT 3.51 y SIDhistory Cuando planifique la reestructuración de su dominio debe tener presente un problema conocido, relacionado con el uso de Windows NT 3.51 en dominios de Windows 2000. Este problema afecta a la autenticación y a la autorización, concretamente a cómo se construyen los tokens de acceso en Windows NT 3.51. Cuando se autentica un usuario, sea interactivamente en una estación de trabajo de Windows NT 3.51 o a través de la red en un servidor de Windows NT 3.51, el token de acceso se construye usando sólo SID relativos al dominio de cuentas del usuario y los grupos locales del servidor o de la estación de trabajo donde se produce la autenticación. El resultado es que los tokens de acceso de Windows NT 3.51 no pueden contener grupos universales de fuera del dominio de cuentas ni grupos locales del dominio pertenecientes al dominio de recursos. Puesto que por definición las entradas del SIDhistory del usuario o el SIDhistory de los grupos de los que sea miembro el usuario procederán de dominios que no son el dominio de cuentas, quedarán igualmente excluidas del token. La consecuencia de esto es que con Windows NT 3.51 los SID de dominios que no sean el dominio de cuentas del usuario que se conecta serán omitidos cuando se evalúen para el control del acceso. En la mayoría de los casos el resultado es que se deniega el acceso, aunque no sea éste el resultado que se desea. ClonePrincipal y resolución de SID Otro problema que debe tener presente cuando elabore su plan de reestructuración del dominio tiene que ver con la forma en que los SID se resuelven en nombres de usuarios. En ciertas circunstancias, cuando un usuario intenta ver las propiedades de seguridad de un archivo o de una carpeta en una partición de Windows NT File System (NTFS), los SID de los usuarios y de los grupos que han sido clonados puede que no estén resueltos y estarán etiquetados como Usuario desconocido. Esto podría provocar problemas de gestión, porque es posible que los administradores duden sobre editar las ACL, por temor a impedir el acceso legítimo a los recursos. Para comprender este problema es útil ver cómo intenta la resolución la API utilizada para resolver los SID. La API intenta la resolución en el orden siguiente: 1. Intenta encontrar un nombre para el SID comprobando primero una lista de SID bien conocidos. 2. Si el SID no corresponde a un SID bien conocido, la función comprueba las cuentas locales incorporadas y definidas administrativamente. 3. Después, la función comprueba el dominio primario. 4. Los SID no reconocidos por el dominio primario se comprueban con los dominios de confianza que correspondan a sus prefijos de SID. 5. Después, la función intentará comprobar el SID con los SID de todas las cuentas de todos los dominios del bosque de Windows 2000, incluidos los SID que sólo aparecen en el campo SIDhistory de una cuenta del bosque. Para realizar estas comprobaciones, la función debe tener capacidad para consultar el GC del bosque. Esto tiene distintas repercusiones: • Para poder resolver el nombre sin consultar el GC, la cuenta que fue clonada debe estar en un dominio de confianza y aún debe existir. • Sin embargo, para resolver el nombre según se describe en el paso 5 anterior, el ordenador desde el que la función intenta la comprobación debe usar Windows 2000 o bien estar en un 81 dominio en modo nativo de Windows 2000. Este problema no ocurrirá si los usuarios han sido movidos usando MoveTree. Estos movimientos están limitados al mismo bosque de Windows 2000, por lo que sólo se producirá cuando los usuarios hayan sido clonados entre bosques. Para evitar este problema deberá: • Migrar todas las estaciones de trabajo al bosque de destino en cuanto sea posible después de haber migrado los usuarios. • Renovar las ACL de los recursos de toda la empresa para suprimir las referencias a los SID antiguos. • Mantener la cuenta de origen en el dominio antiguo hasta que los recursos tengan ACL nuevas y se hayan suprimido todas las referencias a los SID antiguos. Perfiles y SIDhistory Cuando prepare su plan de reestructuración del dominio deberá tener presentes las consecuencias de que los usuarios migrados tengan SID nuevos sobre el uso de perfiles. Cuando un usuario se conecta a una estación de trabajo de Windows NT, el sistema cargará un perfil para ese usuario que contendrá información de configuración específica del usuario. El sistema localiza este perfil recogiendo el SID del usuario y buscando en el registro de la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList una clave designada como la representación de string del SID del usuario. Una consecuencia de esta acción es que un usuario que se conecte a la estación de trabajo después de la migración podría perder el acceso a su perfil de inicio de sesión, porque su SID primario habrá cambiado y el perfil antiguo estará almacenado dentro del SID primario. Cuando un usuario ha sido movido entre dominios de Windows 2000 en un mismo bosque usando una herramienta como MoveTree, no habrá problemas porque MoveTree conserva el GUID del usuario. Una característica nueva del código de manipulación de perfiles en el cliente Windows 2000 aprovecha esta invariabilidad del GUID, de forma que si no se encuentra el SID de un usuario en la clave ProfileList, el sistema recuperará el GUID del usuario y buscará en el registro de la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileGuid una clave designada como la representación de la cadena del GUID del usuario. Si encuentra esta clave, buscará en ella un valor llamado SidString, que proporciona una asignación de fallback del GUID del usuario con su SID. El sistema puede buscar luego en la clave ProfileList el SID contenido en SidString y, si lo encuentra, renombrar la clave según la representación de la cadena del nuevo SID del usuario. En este caso, el sistema cambiará también el valor SidString. De esta descripción puede deducirse que puede haber un problema de pérdida de perfiles en los casos siguientes: • Se ha clonado un usuario de un dominio de Windows NT 4.0. Se ha clonado un usuario de un dominio de Windows 2000. • • Se ha clonado un usuario de un dominio de Windows 2000, pero se conecta en una estación de trabajo de Windows NT 4.0. La sección siguiente describe algunas posibilidades para resolver estas situaciones. Migración de perfiles Hay dos métodos básicos para hacer que un perfil esté disponible para el usuario migrado y al mismo tiempo permitir una ruta de fallback: Perfiles compartidos. Hacer que el mismo perfil esté disponible en la cuenta original y • en la cuenta nueva del usuario. Ambas cuentas acceden y actualizan la misma copia del perfil. • Perfiles copiados. Copiar el perfil original de su ubicación actual en la clave designada como el SID original del usuario en una clave designada como el SID nuevo del usuario. Cada cuenta está asociada con su copia propia e independiente del perfil. Las actualizaciones en una no se reflejan en la otra. 82 Ambos métodos tienen sus ventajas y sus inconvenientes. Perfiles compartidos Tabla 4. Ventajas e inconvenientes de compartir perfiles. Ventajas Inconvenientes Las actualizaciones del perfil (por ejemplo, En los cambios entre la cuenta antigua y la cambios en Mis documentos, accesos directos, etc.) durante la conexión a una cuenta son accesibles en las conexiones posteriores a la otra cuenta. nueva, los resultados son impredecibles por ahora. Un ejemplo sería un perfil de cuenta nuevo en Windows 2000 que contuviera referencias de política de grupos que se usará en el fallback a una cuenta de origen en la que se ha instalado una política de grupos distinta (o no se haya instalado ninguna). Mantiene espacio en el disco porque sólo se almacena una copia del perfil. Disponibilidad de una utilidad para activar la posibilidad de compartir perfiles. Migración de perfiles copiados Tabla 5. Ventajas e inconvenientes de copiar perfiles Ventajas Inconvenientes El resultado es más predecible y, como los datos no están compartidos entre los perfiles, no hay peligro de “contaminar” el perfil de una cuenta con datos que sólo Puede haber resultados de fallback impredecibles por la política de instalación de aplicaciones en el dominio nuevo. Aunque el perfil de la cuenta antigua no quede alterado son apropiados para otra cuenta de un por la actividad en la cuenta de destino, las aplicaciones instaladas en el escritorio por la dominio y un bosque distintos. política de grupos del dominio de destino en algunos casos pueden tratar de desinstalarse ellas mismas o hacer otras cosas que no pueden predecirse. Consume más espacio en el disco porque hay almacenados dos perfiles. Herramienta de Microsoft para la migración de dominios Microsoft está trabajando en una herramienta de migración que podrá descargarse gratuitamente de la Web. Esta herramienta dará soporte gráfico para las operaciones descritas y soportará los escenarios de migración que se describen a continuación. Utilidades básicas para la migración de dominios y escenarios de la migración de dominios Ya hemos mencionado distintas utilidades básicas para la migración de dominios. Las utilidades básicas son una serie de objetos COM y secuencias de comandos de muestra diseñados para formar la base de las utilidades de administración adaptadas al cliente y para soportar diversos escenarios de migración de dominios que Microsoft ha documentado y probado. Los escenarios se han desarrollado basándose en la información facilitada por los clientes sobre sus necesidades de migración. Los escenarios de migración de dominios que Microsoft ha documentado se centran en facilitar el primer paso hacia Windows 2000. Microsoft ha colaborado con proveedores de software independientes para garantizar que las herramientas de los proveedores soportan estos escenarios, aunque es posible que incluyan otros enfoques distintos y que ofrezcan funciones más sofisticadas. 83 Escenarios de la migración de dominios Microsoft ha documentado dos escenarios de migración para Windows 2000 que responderán a las necesidades de reestructuración de casi todos los clientes. Los escenarios pretenden facilitar el movimiento de usuarios y máquinas de dominios de origen en Windows NT a destinos en Windows 2000 y son los siguientes: • Migrar usuarios paulatinamente de Windows NT a Windows 2000. • Consolidar un dominio de recursos en una OU de Windows 2000. Migrar usuarios paulatinamente de Windows NT a Windows 2000 El objetivo de este escenario es describir las fases y las utilidades básicas para que una organización migre sus usuarios paulatinamente a un entorno Windows 2000 prístino sin que ello afecte a su entorno de producción en Windows NT. La consecuencia de no afectar al entorno de producción existente es que éste permanece invariable durante la migración. Una de las repercusiones de ello es que durante la migración el cliente puede volver en cualquier momento al dominio de producción antiguo si lo necesita. Una vez terminada la migración quedará fuera de servicio el dominio de cuentas antiguo y se reasignarán los DC. Fases del escenario Las fases del escenario son las siguientes: 1. Crear el bosque de Windows 2000 prístino. Consiste sencillamente en utilizar un procedimiento estándar para crear un bosque de destino nuevo en Windows 2000 que refleje los requisitos y la estructura identificados en las actividades de planificación del espacio de nombres del cliente. Los dominios creados en el bosque nuevo serán dominios de Windows 2000 en modo nativo. 2. Establecer las relaciones de confianza necesarias para que el bosque mantenga el acceso a los recursos. Esta actividad supone utilizar NETDOM para consultar qué relaciones de confianza existen entre todos los dominios de recursos y el dominio de origen de Windows NT. Los resultados de NETDOM pueden compararse luego con la lista de relaciones de confianza que se ha determinado que son necesarias para activar el acceso a los recursos a usuarios y grupos del dominio de destino. NETDOM puede usarse para establecer todas las relaciones de confianza que aún no existan. 3. Clonar todos los grupos globales de origen en el dominio de destino. Como ya hemos dicho, la mayor parte de los recursos se protegerán usando las ACL que hacen referencia a grupos globales, normalmente a través de grupos compartidos o locales de máquinas. Una vez establecidas las relaciones de confianza, el siguiente paso es garantizar que los grupos globales correspondientes estén disponibles en el dominio de destino. La forma más sencilla de hacerlo es clonar todos los grupos globales usando ClonePrincipal. 4. Identificar y clonar conjuntos de usuarios. Una vez clonados los grupos globales de origen en el dominio de destino, puede empezar el trabajo de migración de los usuarios. Puesto que en la mayoría de los casos el cliente deseará mover los conjuntos de usuarios paulatinamente, ésta será una tarea iterativa que implica identificar los conjuntos de usuarios que van a migrarse y luego usar ClonePrincipal para clonar los usuarios de origen en el dominio de destino. Como parte de este trabajo, cada usuario migrado deberá añadirse a la copia de destino de todos los grupos globales de los que fuera miembro en el dominio de origen. 5. Quitar del servicio el dominio de origen. Cuando todos los usuarios y grupos hayan sido movidos de forma permanente al bosque de destino, la última tarea es quitar del servicio el dominio de origen, lo cual implica desconectar y eliminar los BDC del dominio de origen 84 y, por último, el PDC del dominio de origen. Si la intención es reasignar estos DC en el bosque nuevo, pueden actualizarse a Windows 2000 y ascenderlos a DC o dejarlos como servidores miembros de la forma que se ha explicado. Cada fase del escenario debe probarse, especialmente durante la migración de usuarios. Sería prudente probar el inicio de sesión de algunos usuarios en cada migración. Si se produce un error durante cualquiera de las fases antes de quitar del servicio el dominio, podrá suspenderse el proceso y el trabajo podrá continuar en el dominio de producción de origen. 1 5 3 Clone global groups 4 Clone sets of users Create new “pristine” Windows 2000 forest Decommission source Source Target 2 Resource Domain Establish trusts needed to maintain resource access Resource Domain ************************** 1 Crear un bosque nuevo “prístino” de Windows 2000. 2 Establecer las relaciones de confianza necesarias para mantener el acceso a los recursos. 3 Clonar los grupos globales Origen Destino. 4 Clonar los conjuntos de usuarios. 5 Quitar del servicio el dominio de origen. Dominio de recursos. ************************** Migrar usuarios paulatinamente de Windows NT a Windows 2000. Consolidar un dominio de recursos en una OU de Windows 2000 El objetivo de este escenario es describir las fases y las utilidades básicas necesarias para que una organización consolide varios dominios de recursos en una OU de un dominio de Windows 2000 en modo nativo. Normalmente se busca reducir los costes de la administración de relaciones de confianza complejas. Como parte de este escenario, los servidores de aplicaciones se convertirán en servidores miembros en la OU de destino. Se supone que los servidores de aplicación de todos los dominios utilizarán grupos locales compartidos y que los dominios pueden contener algunos servidores miembros y estaciones de trabajo. Una vez conseguida la reestructuración, la organización puede quitar del servicio los dominios antiguos. Fases del escenario Las fases del escenario son las siguientes: 1. Establecer las relaciones de confianza necesarias entre el dominio de destino y los dominios de cuentas fuera del bosque. Este escenario se diferencia del anterior en que son los dominios de recursos los que se llevan al bosque de destino y los dominios de cuentas quedan fuera del bosque, al menos por el momento. El principal, sin embargo, sigue siendo el mismo, de modo 85 que habrá que establecer relaciones de confianza entre el dominio de destino y los dominios de cuentas para mantener el acceso a los recursos. 2. Esta actividad implica usar NETDOM para consultar qué relaciones de confianza existen en ese momento entre los dominios de recursos y los dominios de cuentas. 3. Los resultados de NETDOM pueden compararse luego con las relaciones de confianza que ya existen entre el dominio de destino y los dominios de cuentas. NETDOM puede usarse después para establecer todas las relaciones de confianza que aún no existan. 4. Clonar todos los grupos locales compartidos. Como ya hemos visto antes, los grupos locales compartidos sólo tienen ámbito dentro del dominio en el que fueron creados y sólo están compartidos entre los CD de ese dominio. En este escenario no es preciso mover todos los DC al dominio de destino inmediatamente, de forma que para garantizar que se mantiene el acceso a los recursos mientras los DC y los recursos están repartidos entre el dominio de origen y el de destino, será necesario clonar los grupos locales compartidos en el dominio de destino usando ClonePrincipal. 5. Degradar los servidores de aplicaciones a servidores miembros. Cuando se hayan clonado todos los grupos locales compartidos será posible iniciar el proceso de convertir los servidores de aplicaciones en servidores miembros en la OU de destino. • En estos momentos hay ciertas limitaciones en la forma de actualizar los BDC. Uno de los efectos es que no hay ningún modo sencillo de actualizar un BDC y degradarlo a servidor miembro a menos que se haya actualizado previamente el PDC. Hay dos métodos para actualizar y degradar los BDC. • Si es posible, le recomendamos actualizar el PDC del dominio de recursos a Windows 2000 y ejecutar el dominio en modo mixto durante el período de transición. Entonces podrá actualizar todos los BDC que deban ser degradados. • Durante la actualización de cada BDC se lanzará DCPROMO y se le ofrecerá la posibilidad de convertir el BDC en una réplica en el dominio de Windows 2000 o en un servidor miembro del dominio. Tendrá que seleccionar esta segunda opción, de forma que la máquina es ahora un servidor miembro del dominio de recursos. • Si no es posible actualizar el PDC o no desea hacerlo, en cada actualización tendrá que poner el BDC fuera de línea y ascenderlo a PDC. Cuando haya ascendido el BDC a PDC podrá actualizar a Windows 2000, convirtiendo efectivamente el DC fuera de línea en PDC en un dominio en modo mixto de Windows 2000 clonado. Cuando el PDC se haya actualizado fuera de línea puede ejecutar DCPROMO para degradar el PDC a servidor miembro y unirlo al dominio de destino. 6. Mover servidores miembros (incluidos antiguos BDC) y estaciones de trabajo. Durante esta fase puede usar NETDOM para crear una cuenta de ordenador en una OU del dominio de destino para el servidor miembro o la estación de trabajo que va a mover y unir el ordenador al dominio de destino. 7. Quitar del servicio el dominio de origen. Cuando todos los grupos y máquinas hayan sido movidos de forma permanente al bosque de destino, la última tarea es quitar del servicio el dominio de origen, lo cual implica desconectar y eliminar los BDC del dominio de origen y, por último, el PDC del dominio de origen. Si la intención es reasignar estos DC en el bosque nuevo, puede actualizarlos a Windows 2000 y ascenderlos a DC o dejarlos como servidores miembros de la forma que se ha explicado. Debe señalarse que en este escenario, al degradar los BDC a servidores miembros, debe moverlos al dominio de destino lo más rápidamente posible. A menos que el dominio esté en modo nativo y los grupos locales compartidos se hayan convertido en grupos locales del 86 dominio, los recursos accesibles a través de estos grupos no estarán disponibles en los servidores miembros. 1 Establish trusts needed to maintain resource access Account Domain 2 Clone shared local groups 3 4 Resource Domain Target OU Demote application servers Move machines Source 5 Decommission source domains ************************** 1 Crear un bosque nuevo “prístino” de Windows 2000. 2 Establecer las relaciones de confianza necesarias para mantener el acceso a los recursos. 3 Clonar los grupos globales Origen Destino. 4 Clonar los conjuntos de usuarios. 5 Quitar del servicio el dominio de origen. Dominio de recursos. ************************** Figura 10. Consolidar un dominio de recursos en una OU de Windows 2000. Lista de comprobación de puntos de decisión El objetivo de esta sección es guiarle en sus decisiones para determinar la ruta de la migración ahora que ya conoce los conceptos principales de la misma. Decisiones sobre la actualización 1. ¿Es adecuada para usted la actualización?. Probablemente contestará que sí, si se cumplen algunas o todas las condiciones siguientes: • Está satisfecho con su estructura de dominios actual. 2. • Está satisfecho con buena parte de su estructura de dominios y puede hacer una migración en dos fases para actualizarla a Windows 2000 y luego reestructurarla para solucionar los posibles problemas. • Cree que puede gestionar la migración sin que ésta afecte a su entorno de producción. ¿En qué orden debería hacer la actualización?. La respuesta depende de si se refiere al orden para actualizar los DC o al orden para actualizar el dominio. 87 3. ¿En qué orden debería actualizar los DC?. Dentro de un dominio, el orden de la actualización es claro: primero tiene que actualizar el PDC, pero debe estar atento a posibles complicaciones, como el uso de LMRepl en el dominio que va a actualizarse, con el PDC que aloja el directorio de exportación. En este caso deberá realojar el directorio de exportación antes de actualizar el PDC. 4. ¿En qué orden debe actualizar los dominios?. En general notará más ventajas si actualiza primero los dominios de cuentas, ya que será mayor el número de “victorias rápidas” en cuanto a administración y delegación más sencillas. Luego deberá actualizar los dominios de recursos. 5. ¿En qué orden debe actualizar el servidor y las estaciones de trabajo?. Puede actualizar los servidores y las estaciones de trabajo en cualquier momento, ya que no depende de la existencia de una infraestructura de Windows 2000. Por lo que se refiere a los servidores miembros, si cree que relajar la seguridad de Active Directory para activar el uso de servidores RAS de Windows NT pondría en peligro su política de seguridad, debería actualizar primero los servidores. Si utiliza LMRepl para replicar secuencias de comandos dentro del dominio, debería actualizar en último lugar el servidor que aloja el directorio de exportación. 6. ¿Cuándo debe cambiar a modo nativo?. Debe cambiar a modo nativo lo más pronto posible para tener acceso a toda la funcionalidad de Windows 2000, como mejor escalabilidad de los directorios, grupos universales y locales del dominio y anidamiento de grupos. No puede cambiar a modo nativo hasta que se hayan actualizado todos los DC de un dominio. Decisiones sobre la reestructuración ¿Necesita reestructurarse?. 1. Probablemente contestará que sí, si se cumplen algunas o todas las condiciones siguientes: • Está satisfecho con buena parte de su estructura de dominios y puede hacer una migración en dos fases para actualizarla a Windows 2000 y luego reestructurarla para solucionar los posibles problemas. 1. • Está insatisfecho con su estructura de dominios actual. • Cree que no puede gestionar la migración sin que ésta afecte a su entorno de producción. ¿Cuándo debería reestructurarse?. La respuesta a esta pregunta depende en gran medida de la razón por la que vaya a reestructurarse (vea la pregunta anterior). Si puede resolver sus necesidades de migración haciendo una migración en dos fases, debería reestructurarse después de la actualización. Si cree que, por alguna razón, su estructura de dominios es irrecuperable o que no puede evitar que afecte a su entorno de producción, debería reestructurarse desde el principio. Resumen La migración de Windows NT 4.0 a Windows 2000 Active Directory puede conseguirse a través de la actualización y a través de la reestructuración. Microsoft proporciona una ruta de migración sencilla y de bajo riesgo en forma de actualización de dominios. Muchos clientes descubrirán que con ello se satisfacen todas sus necesidades de migración. Microsoft ha recibido comentarios de sus clientes y tiene el compromiso de proporcionar excelentes herramientas que soporten la reestructuración de dominios, sea como parte de la migración inicial o después de la migración para soportar operaciones corporativas como adquisiciones y desinversiones. La herramienta de migración y las utilidades básicas de Microsoft representan el primer paso. 88 Las herramientas y las utilidades de Microsoft son sólo una parte. Muchos clientes habrán establecido sólidas relaciones de trabajo con vendedores de herramientas independientes en este campo y querrán seguir usando las herramientas con las que ya están familiarizados. Microsoft ha trabajado con vendedores de software independientes para garantizar que sus herramientas para la reestructuración de dominios puedan usar funciones como SIDhistory y operaciones de clonación. Para más información Si quiere la última información sobre Windows 2000 Server, visite la página Web http://www.microsoft.com/windows2000/ . 89 SEGURIDAD EN WINDOWS 2000 SERVER 1. Introducción A medida que aumenta la interconexión global del planeta, se está convirtiendo en realidad el sueño futurista de disponer de la información en cualquier lugar, en cualquier momento y en cualquier dispositivo. Las empresas y sus clientes sólo almacenarán sus datos confidenciales en un entorno de este tipo si se les garantiza la seguridad del mismo. La encuesta sobre delitos y seguridad informáticos del 2001 (Computer Crime and Security Survey) publicada por el CSI (Computer Security Institute) y el FBI (Federal Bureau of Investigation) indica que el 85 por ciento de las grandes empresas y agencias del gobierno norteamericano detectaron infracciones de seguridad. El promedio de pérdidas anuales estimadas de los encuestados fue de más de 2 millones de dólares americanos. En los meses recientes se ha producido una lluvia de ataques a entornos informáticos, muchos de ellos a través de Internet y a equipos con el sistema operativo Microsoft® Windows®. Sin embargo, éstos son sólo los problemas de seguridad más notorios a los que se enfrentan las empresas en la actualidad. En esta guía se describen las distintas amenazas de seguridad para su entorno y se explica la mejor manera de protegerse. Independientemente de cuál sea su entorno, es muy recomendable tomarse en serio la seguridad. Muchas organizaciones cometen el error de subestimar el valor del entorno de tecnología de la información (TI), generalmente porque no tienen en cuenta costos indirectos importantes. Si el ataque es suficientemente grave, las pérdidas podrían ascender al valor de la organización. Por ejemplo, un ataque que modifique sutilmente el sitio Web corporativo para anunciar malas noticias falsas podría hundir el valor en bolsa de la corporación. Al evaluar los gastos de seguridad, se deben incluir también los costos indirectos asociados a cualquier ataque, así como los costos derivados de la pérdida de funcionalidad de los sistemas de TI. Los sistemas informáticos más seguros del mundo son los que están completamente aislados de los usuarios y de otros sistemas. Sin embargo, en el mundo real normalmente necesitamos sistemas informáticos que funcionen en red, a menudo en redes públicas. Esta guía le ayudará a identificar los riegos inherentes a un entorno de red y a determinar el nivel de seguridad apropiado para su entorno; también le indicará los pasos necesarios para alcanzar ese nivel de seguridad. Aunque está dirigida a clientes empresariales, gran parte de esta guía es válida para organizaciones de cualquier tamaño. Microsoft Operations Framework (MOF) Para que las operaciones del entorno funcionen de la forma más eficaz, debe administrarlas de forma efectiva. En este sentido, Microsoft ha desarrollado Microsoft Operations Framework (MOF). MOF es, en esencia, un conjunto de prácticas recomendadas, principios y modelos que le guiarán al realizar operaciones. Las instrucciones de MOF le ayudarán a garantizar la seguridad, la confiabilidad, la disponibilidad, el soporte y la capacidad de administración de sus sistemas de producción fundamentales mediante los productos de Microsoft. El modelo de procesos MOF se divide en cuatro cuadrantes integrados de la manera siguiente: Cambio. Funcionamiento. 90 Soporte. Optimizaci ón. Juntas, las fases forman un ciclo de vida en espiral (consulte la Ilustración 1.1) que se puede aplicar a todo, desde una aplicación específica a un entorno de operaciones completo con varios centros de datos. En este caso, utilizará MOF en el contexto de las operaciones de seguridad. Ilustración 1.1. Modelo de procesos MOF. El modelo de procesos se apoya en 20 funciones de administración de servicios (SMF, Service Management Functions) y un modelo de equipos y otro de riesgos, ambos integrados. Cada cuadrante se apoya en la revisión de administración de operaciones correspondiente (también denominada hito de revisión), en la que se valora la eficacia de las funciones de administración de servicios del cuadrante. No es imprescindible ser un experto en MOF para comprender y utilizar esta guía, pero unos conocimientos adecuados de los principios de MOF le ayudarán a administrar y mantener un entorno de operaciones confiable, disponible y estable. Implementar y mantener la seguridad En octubre de 2001, Microsoft lanzó una iniciativa denominada Programa Estratégico de Protección de Tecnología (STPP, Strategic Technology Protection Program). El objetivo de este programa es integrar los productos, los servicios y el soporte de Microsoft dedicados a la seguridad. Microsoft divide el proceso de mantener un entorno seguro en dos fases relacionadas: implementar la seguridad y mantener la seguridad. 91 Implementar la seguridad La primera fase se denomina Implementar la Seguridad (Get Secure). Para ayudar a su organización a alcanzar un nivel de seguridad apropiado, siga las recomendaciones de Implementar la Seguridad, especificadas en el Microsoft Security Tool Kit, al que puede tener acceso en línea. Mantener la seguridad La segunda fase se denomina Mantener la Seguridad (Stay Secure). Una cosa es crear un entorno inicialmente seguro. Otra cosa totalmente distinta es, cuando el sistema está configurado y en funcionamiento, mantener la seguridad, adoptar medidas preventivas contra las amenazas y responder con eficacia cuando se produzcan. Ámbito de esta guía Esta guía se centra explícitamente en las operaciones requeridas para crear y mantener un entorno seguro en servidores con Windows 2000. Se examinan funciones específicas definidas para los servidores, pero no se explica con detalles la manera de ejecutar aplicaciones específicas de forma segura. Al implementar la seguridad, se debe diseñar e implementar muchas áreas. El siguiente diagrama proporciona una vista de alto nivel de las mismas. Ilustración 1.2. Áreas de seguridad. El diagrama muestra los pasos necesarios para configurar la seguridad del servidor (Implementar la Seguridad) y mantenerla (Mantener la Seguridad). También muestra cómo puede lograr estos objetivos leyendo los capítulos de esta guía. 92 Ilustración 1.3. Diagrama de flujo del proceso de seguridad. 93 Nota: en este diagrama no se muestran todas las tareas implicadas en el mantenimiento de la seguridad de los procesos operativos, como la ejecución de un software antivirus o la creación periódica de copias de seguridad. El objetivo es, más bien, mostrar las tareas que se describirán con detalle en la guía. Debe utilizar esta guía como parte de su estrategia global de seguridad, no como una referencia completa para cubrir todos los aspectos de la creación y el mantenimiento de un entorno seguro. Esquema de los capítulos Esta guía consta de los siguientes capítulos, dedicados a describir las distintas partes del proceso de operaciones de seguridad. Se ha diseñado cada capítulo para que pueda leerlo entero o parcialmente, en función de sus necesidades. Capítulo 2: Definición de riesgo de seguridad Para poder implementar la seguridad en su entorno, debe conocer las amenazas, las vulnerabilidades, las explotaciones y las contramedidas en el contexto de la seguridad de TI. En este capítulo se describen estos temas y se examinan decisiones técnicas y de negocios que le ayudarán a administrar de forma más efectiva los riesgos para la seguridad del entorno. Capítulo 3: Administrar la seguridad con la Directiva de grupo de Windows 2000 Muchos de los valores de configuración de la seguridad se definen en Windows 2000 a través de la Directiva de grupos, cuyo fin es controlar el comportamiento de los objetos en el equipo local y en el servicio de directorio Active Directory™. Es importante asegurarse de que estas directivas están correctamente configuradas y de que se supervisan para que no las modifiquen sin autorización previa. En este capítulo se analizará en detalle la administración de la seguridad mediante la Directiva de grupos. Capítulo 4: Asegurar servidores basándose en su función Es necesario utilizar configuraciones distintas para los servidores de aplicaciones, los servidores de archivos y los servidores Web para maximizar su seguridad. En este capítulo se describen los controladores de dominio y varias funciones de servidor miembro distintas, así como los pasos necesarios para asegurarse de que cada una de estas funciones es lo más segura posible. Nota: esta guía asume que los servidores realizan funciones específicas bien definidas. Si los servidores no satisfacen estas funciones o si tiene servidores multiuso, debe utilizar las configuraciones definidas en esta guía como directiva para crear plantillas de seguridad que le ofrezcan la funcionalidad que necesita. Sin embargo, debe tener en cuenta que cuantas más funciones desempeñe cada servidor individual, más vulnerable será a los ataques. Capítulo 5: Administrar revisiones Una de las principales medidas de protección contra ataques es mantener el entorno actualizado con todas las revisiones de seguridad necesarias. Las revisiones pueden ser necesarias tanto para servidores como para clientes. En este capítulo se explica la forma de obtener lo antes posible las revisiones nuevas, implementarlas rápidamente y de forma confiable en toda la organización, y confirmar que están instaladas en todos los equipos. 94 Capítulo 6: Auditoría y detección de intrusiones No todos los ataques son evidentes. A veces, los ataques más sutiles son los más peligrosos, ya que pasan desapercibidos y es difícil determinar los cambios realizados. En este capítulo se muestra la forma de auditar el entorno para aumentar las posibilidades de detectar ataques y se describen los sistemas de detección de intrusos (programas diseñados específicamente para detectar comportamientos indicativos de que se está produciendo un ataque). Capítulo 7: Responder a las incidencias Independientemente de lo seguro que sea el entorno, siempre existe el riesgo de ataque. Cualquier estrategia de seguridad razonable debe incluir detalles sobre cómo responderá la organización a los distintos tipos de ataque. En este capítulo se describen las mejores técnicas para responder a distintos tipos de ataque y se incluyen los pasos que hay que realizar para notificar las incidencias de forma efectiva. También se incluye el análisis de un escenario posible en el que se explica una respuesta típica a una incidencia. Resumen Este capítulo le ha proporcionado una introducción a la guía y un resumen de los demás capítulos. También se le ha presentado el Programa Estratégico de Protección de Tecnología (STTP, Strategic Technology Protection Program). Ahora que conoce la estructura de la guía, puede decidir si desea leerla de principio a fin o sólo partes seleccionadas. Recuerde que las operaciones de seguridad efectivas y satisfactorias requieren un esfuerzo en todas las áreas, no sólo mejoras en una de ellas; por ello, es recomendable leer todos los capítulos. 2. Definición de riesgo de seguridad A medida que evolucionan los sistemas de TI, también lo hacen las amenazas a la seguridad que estos pueden sufrir. Para proteger su entorno de forma eficaz contra los ataques, necesita conocer con detalle los peligros con los que puede encontrarse. Al identificar las amenazas a la seguridad, debe tener en cuenta dos factores principales: 1) Los tipos de ataques que seguramente sufrirá y 2) los lugares donde pueden tener lugar. Muchas organizaciones no tienen en cuenta el segundo factor, pues asumen que un ataque grave sólo puede venir del exterior (normalmente, a través de su conexión a Internet). En CSI/FBI Computer Crime and Security Survey (encuesta sobre delitos y seguridad informáticos de CSI/FBI), el 31% de los encuestados citaron sus sistemas internos como un punto de ataque frecuente. Sin embargo, muchas empresas pueden no estar al corriente de que se están dando ataques internos, básicamente porque no comprueban si existen. En este capítulo examinaremos los tipos de ataques que puede sufrir. También estudiaremos algunas medidas, tanto empresariales como técnicas, que puede adoptar para minimizar las amenazas a su entorno. Administración de riesgos No existe un entorno de TI totalmente seguro y al mismo tiempo útil. Al examinar su entorno, deberá evaluar los riesgos que sufre actualmente, determinar un nivel de riesgo aceptable y mantener el riesgo a ese nivel o por debajo del mismo. Los riesgos se reducen aumentando la seguridad de su entorno. 95 Como norma general, cuanto más alto sea el nivel de seguridad de una organización, más costosa resultará su implementación y más posibilidades habrá de que se reduzca su funcionalidad. Tras evaluar los posibles riesgos, quizá tenga que reducir el nivel de seguridad para conseguir aumentar la funcionalidad y reducir el costo. Por ejemplo, imagine una empresa de tarjetas de crédito que se está planteando la posibilidad de implementar un sistema de prevención de fraude. Si el fraude supone para la empresa un gasto de 3 millones de dólares al año y la implementación y el mantenimiento del sistema de prevención de fraude conlleva un gasto de 5 millones de dólares anuales, la instalación del sistema no supone un beneficio financiero directo. Sin embargo, la empresa puede sufrir pérdidas indirectas valoradas en mucho más de 3 millones, como pérdida de reputación o de la confianza de los consumidores. Por lo tanto, los cálculos son, en realidad, mucho más complicados. En ocasiones, los niveles adicionales de seguridad darán como resultado sistemas más complejos para los usuarios. Un banco en línea puede decidir utilizar varios niveles de autenticación para sus usuarios cada vez que estos tengan acceso a su cuenta. No obstante, si el proceso de autenticación es demasiado complicado, algunos usuarios ni siquiera se molestarán en utilizar el sistema, lo que podría llegar a resultar más costoso que los ataques que el banco puede sufrir. Para entender los principios de la administración de riesgos, es necesario entender algunos términos básicos utilizados en el proceso de administración de riesgos. Estos incluyen recursos, amenazas, vulnerabilidades, explotaciones y contramedidas. Recursos Un recurso es cualquier elemento de su entorno que intente proteger. Puede tratarse de datos, aplicaciones, servidores, enrutadores e incluso personas. El objetivo de la seguridad es evitar que sus recursos sufran ataques. Una parte importante de la administración de riesgos consiste en determinar el valor de sus recursos. No utilizaría cerraduras normales y un sistema de alarma doméstico para guardar las Joyas de la Corona. De forma similar, el valor de sus recursos determinará, por lo general, el nivel de seguridad apropiado para protegerlos. Amenazas Una amenaza es una persona, un lugar o un elemento que puede tener acceso a los recursos y dañarlos. En esta tabla se muestran distintos tipos de amenazas con ejemplos. Tabla 2.1.: Amenazas a entornos informáticos. Tipo de amenaza Ejemplos Natural y física. Fuego, agua, viento, terremoto. Corte eléctrico. No intencionada. Empleados no informados. Clientes no informados. Intencionada. Atacantes. 96 Terroristas. Espías industriales. Gobiernos. Código malicioso. Vulnerabilidades Una vulnerabilidad es un punto en el que un recurso es susceptible de ser atacado. Se puede interpretar como un punto débil. Las vulnerabilidades se dividen a menudo en las categorías que se muestran en la siguiente tabla. Tabla 2.2.: Vulnerabilidades en entornos informáticos. Tipo de vulnerabilidad Ejemplos Física. Puertas sin cerrar. Natural. Sistema antiincendios averiado. De hardware y software. Software antivirus no actualizado. De medios. Interferencia eléctrica. De comunicación. Protocolos no cifrados. Humana. Procedimientos no seguros de asistencia técnica. Nota: es posible que los ejemplos que aparecen en las listas de amenazas y vulnerabilidades no sean aplicables a su organización, puesto que cada una es distinta. Explotación Una amenaza que se aprovecha de una vulnerabilidad de su entorno puede tener acceso a un recurso. Este tipo de ataque se denomina explotación. La explotación de recursos se puede realizar de varias maneras. En la siguiente tabla se incluyen algunas de las más comunes. Tabla 2.3.: Explotaciones en entornos informáticos. Tipo de explotación Ejemplo Explotación de vulnerabilidad técnica. Ataques a fuerza bruta. Desbordamiento del búfer. Problemas de configuración. Ataques repetidos. Secuestro de sesión. Obtención de información. Identificación de dirección. 97 Identificación de sistema operativo. Exploración de puertos. Búsqueda de servicios y aplicaciones. Exploración de vulnerabilidades. Análisis de respuestas. Enumeración de usuarios. Destrucción de documentos. Fuga de dispositivos inalámbricos. Ingeniería social. Denegación de servicio. Daño físico. Eliminación de recursos. Modificación de recursos. Saturación de recursos. Cuando una amenaza utiliza una vulnerabilidad para atacar un recurso, las consecuencias pueden ser graves. En esta tabla se muestran algunos de los resultados de explotaciones que pueden producirse en su entorno y algunos ejemplos. Tabla 2.4.: Resultados de explotaciones. Resultados de una explotación Ejemplos Pérdida de confidencialidad. Acceso no autorizado. Reasignación de privilegios. Personificación o robo de identidad. Pérdida de integridad. Daños en datos. Desinformación. Pérdida de disponibilidad. Denegación de servicio. Relación entre amenazas, vulnerabilidades y riesgo Las amenazas y vulnerabilidades identificadas en su organización se deben calificar y clasificar mediante un estándar; por ejemplo: baja, media o alta. La clasificación variará entre las organizaciones y a veces incluso dentro de una misma organización. Por ejemplo, la amenaza de terremotos es sustancialmente más elevada para las oficinas cercanas a una falla que para las que se encuentran en otros lugares. De manera similar, la vulnerabilidad de daños físicos a equipos sería muy alta para una organización de productos electrónicos altamente delicados y frágiles, mientras que una empresa de construcción puede tener un nivel de vulnerabilidad más bajo. 98 Nota: Ayuda de trabajo 1: La tabla de análisis de amenazas se puede utilizar como ayuda para evaluar las amenazas y el impacto que pueden tener en su organización. El nivel de riesgo de su organización aumenta con el nivel de amenazas y vulnerabilidad. Esto se muestra en el siguiente diagrama. Ilustración 2.1. Matriz de riesgos. Contramedidas Las contramedidas se aplican para contrarrestar las amenazas y vulnerabilidades y de este modo reducir el riesgo en su entorno. Por ejemplo, una organización de productos electrónicos frágiles puede aplicar contramedidas de seguridad física como fijar la maquinaria a los cimientos del edificio o agregar mecanismos de amortiguación. Estas contramedidas reducen la posibilidad de que un terremoto pueda causar daños físicos a sus bienes. Una vez aplicadas todas las contramedidas para reducir las amenazas y vulnerabilidades, sólo quedan riesgos residuales. Defensa en profundidad Para reducir el riesgo en su entorno, debe usar una estrategia de defensa en profundidad para proteger los recursos de amenazas externas e internas. El término defensa en profundidad (en ocasiones denominada seguridad en profundidad o seguridad multicapa) procede de un término militar utilizado para describir la aplicación de contramedidas de seguridad con el fin de formar un entorno de seguridad cohesivo sin un solo punto de error. Las capas de seguridad que forman la estrategia de defensa en profundidad incluyen el despliegue de medidas de protección desde los enrutadores externos hasta la ubicación de los recursos, pasando por todos los puntos intermedios. Con el despliegue de varias capas de seguridad, ayuda a garantizar que, si se pone en peligro una capa, las otras ofrecerán la seguridad necesaria para proteger sus recursos. Por ejemplo, que el 99 servidor de seguridad de una organización esté en peligro, no debe significar que un atacante pueda tener acceso sin trabas a los datos más confidenciales de la organización. En el caso ideal, cada capa debe proporcionar diferentes formas de contramedidas para evitar que se utilice el mismo método de explotación en varias capas. En este diagrama se muestra una estrategia de defensa en profundidad eficaz: Ilustración 2.1. Estrategia de defensa en profundidad. Es importante recordar que sus recursos no son sólo datos, sino que cualquier elemento de su entorno es susceptible de ser atacado. Como parte de su estrategia de administración de riesgos, debe examinar los recursos que protege y determinar si dispone de protección suficiente para todos. Por supuesto, la cantidad de medidas de seguridad que pueda aplicar dependerá de la evaluación de riesgos y el análisis de costos y beneficios de la aplicación de contramedidas. Sin embargo, el objetivo consiste en garantizar que un atacante necesitará unos conocimientos, tiempo y recursos significativos para superar todas las contramedidas y tener acceso a sus recursos. Nota: la forma exacta en la que se aplique la defensa en profundidad dependerá de las características propias de su entorno. Asegúrese de volver a evaluar la estrategia de defensa en profundidad cuando su entorno cambie. Vale la pena examinar cada capa de una estrategia de defensa en profundidad de forma más detallada. Defensa de datos Para muchas empresas, uno de los recursos más valiosos son los datos. Si estos datos cayeran en manos de la competencia o sufrieran daños, tendrían problemas importantes. 100 A nivel de cliente, los datos almacenados localmente son especialmente vulnerables. Si se roba un equipo portátil, es posible realizar copias de seguridad, restaurar y leer los datos en otro equipo, aunque el delincuente no pueda conectarse al sistema. Los datos se pueden proteger de varias formas, incluido el cifrado de datos mediante EFS (Encrypting File Service) o sistemas de cifrado de otros fabricantes y la modificación de las listas de control de acceso discrecional en los archivos. Defensa de aplicaciones Como una capa de defensa más, el refuerzo de las aplicaciones es una parte esencial de cualquier modelo de seguridad. Muchas aplicaciones utilizan el subsistema de seguridad de Windows 2000 para proporcionar seguridad. No obstante, es responsabilidad del programador incorporar la seguridad en la aplicación para proporcionar una protección adicional a las áreas de la arquitectura a las que la aplicación puede tener acceso. Una aplicación existe en el contexto del sistema, de modo que siempre se debe tener en cuenta la seguridad de todo el entorno al considerar la seguridad de una aplicación. Se debe probar en profundidad el cumplimiento de la seguridad de cada aplicación de la organización en un entorno de prueba antes de permitir que se ejecute en una configuración de producción. Defensa de hosts Debe evaluar cada host del entorno y crear directivas que limiten cada servidor sólo a las tareas que tenga que realizar. De este modo, se crea otra barrera de seguridad que un atacante deberá superar antes de poder provocar algún daño. El capítulo 4, "Asegurar servidores basándose en su función", incluye directivas que aumentan la seguridad para cinco funciones de servidor de Windows 2000 comunes. Un modo de hacerlo consiste en crear directivas individuales en función de la clasificación y el tipo de datos que contiene cada servidor. Por ejemplo, las directivas de una organización pueden estipular que todos los servidores Web son de uso público y, por lo tanto, sólo pueden contener información pública. Sus servidores de bases de datos están designados como confidenciales de la empresa, lo que significa que la información debe protegerse a cualquier precio. De ahí las clasificaciones que se muestran en la siguiente tabla. Tabla 2.5.: Clasificación de servidores. Valor Definición De uso público. La distribución de este material no está limitada. Incluye información de marketing, materiales de venta e información seleccionada para uso público. Los datos incluidos en servidores de Internet públicos deben ser de uso público. Sólo para interno. uso La revelación de esta información es segura para la distribución interna, pero puede provocar daños considerables a la organización si se hace pública. Debe colocarse por lo menos un servidor de seguridad entre esta información e Internet. Confidencial la empresa. de La revelación de esta información puede provocar daños graves a la organización en conjunto. Esta información es del tipo más 101 confidencial y sólo se expone si es absolutamente necesario. Deben colocarse por lo menos dos servidores de seguridad entre esta información e Internet. Defensa de redes Si dispone de una serie de redes en la organización, debe evaluarlas individualmente para asegurarse de que se ha establecido una seguridad apropiada. Si un enrutador sufre un ataque eficaz, puede denegar el servicio a partes enteras de la red. Debe examinar el tráfico admisible en sus redes y bloquear el que no sea necesario. También puede considerar el uso de IPSec para cifrar los paquetes en sus redes internas y SSL para las comunicaciones externas. Asimismo, debe supervisar la existencia de detectores de paquetes en la red, que sólo deben usarse bajo controles estrictos. Defensa de perímetros La protección del perímetro de su red es el aspecto más importante para detener los ataques externos. Si su perímetro permanece seguro, la red interna estará protegida de ataques externos. La organización debe disponer de algún tipo de dispositivo de seguridad para proteger cada punto de acceso a la red. Es necesario evaluar cada dispositivo, decidir qué tipos de tráfico se permiten y desarrollar un modelo de seguridad para bloquear el resto del tráfico. Los servidores de seguridad son una parte importante de la defensa del perímetro. Necesitará uno o más servidores de seguridad para asegurarse de minimizar los ataques externos, junto con la auditoría y la detección de intrusiones para estar seguro de detectar los ataques en caso de que se produzcan. Para obtener más información sobre la auditoría y la detección de intrusiones, consulte el capítulo 6, "Auditoría y detección de intrusiones". También debe recordar que, para las redes que permiten el acceso remoto, el perímetro puede incluir los equipos portátiles del personal e incluso los equipos domésticos. Deberá asegurarse de que estos equipos cumplen con los requisitos de seguridad antes de que se conecten a la red. Seguridad física Todo entorno en el que usuarios no autorizados puedan obtener acceso físico a equipos es inherentemente inseguro. Un ataque de denegación de servicio muy eficaz puede ser simplemente quitar el sistema de alimentación de un servidor o las unidades de disco. El robo de datos (y la denegación de servicio) puede producirse si alguien roba un servidor o incluso un equipo portátil. Debe considerar la seguridad física como un elemento fundamental para su estrategia de seguridad global. Una prioridad principal será la de establecer una seguridad física para las ubicaciones de los servidores. Puede tratarse de salas de servidores del edificio o de centros de datos enteros. También debe tener en cuenta los accesos a los edificios de la organización. Si alguien puede tener acceso a un edificio, puede tener oportunidades para llevar a cabo un ataque aunque ni siquiera pueda conectarse a la red. Estos ataques pueden incluir: La denegaci ón de servicio (por ejemplo, conectar un equipo portátil a la red como servidor DHCP o desconectar la alimentación de un servidor). El robo de datos (por ejemplo, robar un equipo port átil o detectar paquetes en la red interna). 102 La ejecuci ón de código malicioso (por ejemplo, activar un gusano desde el interior de la organización). El robo de informaci ón de seguridad crítica (por ejemplo, cintas de copia de seguridad, manuales de funcionamiento y diagramas de red). Como parte de la estrategia de administración de riesgos, debe determinar el nivel de seguridad física apropiado para su entorno. A continuación se enumeran algunas de las posibles medidas de seguridad física: Establecer seguridad f ísica para todas las áreas del edificio (esto puede incluir tarjetas de acceso, dispositivos biométricos y guardias de seguridad). Requerir a los visitantes que vayan acompa ñados en todo momento. Requerir a los visitantes que firmen un registro de entrada de todos los dispositivos informáticos. R equerir a todos los empleados que registren cualquier dispositivo portátil de su propiedad. Fijar f ísicamente todos los equipos de sobremesa y portátiles a las mesas. Requerir que se registren todos los dispositivos de almacenamiento de datos antes de del edificio. sacarlos Ubicar los servidores en salas separadas a las que s ólo tengan acceso los administradores. Conexiones a Internet, alimentaci ón, sistemas antiincendios, etc. Redundantes. Protecci ón contra desastres naturales y ataques terroristas. Establecer seguridad para las áreas en las que se puede dar un ataque por denegación de servicio (por ejemplo, las áreas en las que el cableado sale del edificio principal). Directivas y procedimientos Casi todas las medidas descritas hasta ahora están destinadas a evitar el acceso no autorizado a los sistemas. No obstante, está claro que habrá personas de su entorno que necesiten acceso de alto nivel a los sistemas. Toda estrategia de seguridad será imperfecta a menos que pueda garantizar que estas personas no van a hacer un uso indebido de los derechos que se les han concedido. Antes de contratar a nuevos empleados para la organización, debe asegurarse de que se someten a un proceso de investigación de seguridad, con una investigación más rigurosa para aquellos que vayan a tener un mayor acceso a los sistemas. Respecto a los empleados existentes, resulta esencial que sean conscientes de las directivas de seguridad y de lo que está permitido y prohibido (y, preferiblemente, también por qué). Esto es importante por dos razones. En primer lugar, si los empleados no son conscientes de lo que está prohibido, pueden llevar a cabo acciones que inconscientemente pongan en peligro la seguridad del entorno. En segundo lugar, si un empleado ataca adrede su entorno de TI y no se ha prohibido explícitamente en las directivas de la empresa, puede resultar muy difícil entablar una demanda contra esta persona. 103 En un entorno basado en Windows 2000, puede controlar de forma muy precisa los derechos administrativos de los usuarios. Debe asegurarse de definir detalladamente el alcance de los derechos administrativos que debe tener cada empleado de TI. Ningún empleado debe tener más acceso administrativo del que sea estrictamente necesario para realizar su trabajo. Puede notificar a sus usuarios acerca de la seguridad mediante un programa de orientación seguido de recordatorios a intervalos regulares y actualizaciones visiblemente expuestas de los procedimientos de seguridad. Resulta esencial que los empleados se den cuenta de que cada uno de ellos desempeña un papel en el mantenimiento de la seguridad. Nota: Ayuda de trabajo 2: Los problemas de seguridad más frecuentes incluyen una lista de problemas de seguridad comunes que pueden darse en una organización. Estos errores aumentarán significativamente el riesgo de la misma. Al definir las directivas de seguridad, deberá asegurarse de minimizar la posibilidad de que ocurran estos problemas. Métodos de ataque comunes y medidas preventivas Como parte de la estrategia de defensa en profundidad, debe comprender los métodos empleados por los atacantes y defenderse contra los ataques más comunes. En este apartado se estudia una serie de tipos de ataques y se sugieren medidas para proteger su entorno contra los mismos. Nota: Ayuda de trabajo 3: Los ataques y contramedidas incluyen una tabla de explotaciones de vulnerabilidades técnicas comunes y las contramedidas que se pueden aplicar para cada una de ellas. Obtención de información Los atacantes siempre intentan conseguir información sobre su entorno. A veces la información resulta útil por sí misma y en otras ocasiones es un medio para conseguir otras informaciones y otros recursos. La clave para evitar la obtención de información es restringir el acceso no autorizado a los recursos desde el exterior. Los métodos para conseguirlo incluyen: Asegurarse de que s ólo dispositivos específicos e identificados de la red permiten la conectividad mediante acceso remoto. Una utilidad de búsqueda de módems debe comprobar todos los prefijos de empresas para buscar dispositivos no autorizados. Los dispositivos de acceso remoto también se pueden detectar activando la detección de exploración en el sistema telefónico cuando esté disponible. Deshabilitar NetBIOS sobre TCP/IP, incluidos los puertos 13 5, 137, 139 y 445 en los equipos directamente conectados a Internet a través del servidor de seguridad externo. Esto hace más difícil para las personas externas la utilización de redes estándar para conectarse a servidores. Habilitar s ólo los puertos 80 y 443 en los adaptadores de red orientados a Internet y en el servidor de seguridad para el tráfico destinado a un conjunto de servidores Web. De este modo se elimina la mayor parte de las técnicas de reconocimiento basadas en puertos. Revisar la informa ción del sitio Web público para asegurarse de que: Las direcciones de correo electr ónico utilizadas en el sitio no son cuentas de administrador. No se ha especificado la tecnolog ía de la red. 104 La informaci ón general de la empresa publicada en el sitio es apropiada y no se puede utilizar para descubrir o deducir características del sistema de seguridad. Este tipo de información incluye sucesos actuales y recientes. Por ejemplo, si en el sitio Web se anuncia que su empresa acaba de adquirir otra firma, los atacantes pueden elegir a la nueva adquisición como objetivo pensando que su red se ha conectado precipitadamente a la nueva red corporativa y que, por lo tanto, es menos segura. Revisar las publicaciones de los empleados en grupos Usenet para evaluar el tipo de información que exponen. Administrar el tipo de contenido que contiene el c ódigo fuente del sitio Web para evitar que un atacante revise este código (una técnica en ocasiones denominada criba de código fuente) para obtener información valiosa. Algunos de los elementos que el equipo de seguridad debe buscar en el código fuente son los comentarios incorrectos, las contraseñas incrustadas y las etiquetas ocultas. Revisar la información proporcionada al público en general para su dirección IP y los registros de nombre de dominio. Asegurarse de que un atacante no puede interrogar al DNS para obtener la red de referencia o conseguir que realice una transferencia de zona completa. Mediante el volcado de todos los registros en el DNS, un atacante puede ver bien los equipos más fáciles de atacar. Para evitar que se interrogue al DNS, se pueden asignar derechos al servidor DNS de Windows 2000 mediante la opción Notificar y habilitando las transferencias de zona sólo para los servidores autorizados. Otro enfoque consiste en implementar un DNS de sólo lectura. 3 . Administrar la seguridad con la Directiva de grupo de Windows 2000 Una vez determinado el nivel de riesgo apropiado para el entorno y establecida la directiva de seguridad general, deberá empezar a asegurar el entorno. En un entorno basado en Windows 2000, esto se lleva a cabo principalmente por medio de la Directiva de grupo. En este capítulo, aprenderá a configurar Objetos de Directiva de Grupo (GPO) con plantillas de seguridad para definir la configuración de seguridad del entorno basado en Windows 2000 y se explicará una estructura de Unidad Organizativa (OU) sencilla para apoyar el uso de los GPO. Advertencia: antes de implementar en un entorno de producción las plantillas de seguridad tratadas en este capítulo, deberá probarlas de forma exhaustiva en un laboratorio para garantizar que los servidores sigan funcionando correctamente. Importancia de utilizar la Directiva de grupo El objetivo de las directivas de seguridad es definir los procedimientos de configuración y administración de la seguridad del entorno. La Directiva de grupo de Windows 2000 puede ayudarle a implementar las recomendaciones técnicas de la directiva de seguridad para todas las estaciones de trabajo y los servidores de los dominios de Active Directory. Puede utilizar la Directiva de grupo junto con la estructura de la unidad organizativa para definir una configuración de seguridad específica para determinadas funciones del servidor. Si utiliza la Directiva de grupo para implementar la configuración de seguridad, puede garantizar que todos los cambios realizados en una directiva se apliquen a todos los servidores que la utilizan y que los servidores nuevos obtengan automáticamente la nueva configuración. 105 Cómo aplicar la Directiva de grupo Para utilizar la Directiva de grupo de forma segura y eficaz, es especialmente importante comprender cómo aplicarla. Un objeto de usuario o de equipo puede estar sujeto a varios GPO. Éstos se aplican de forma secuencial y la configuración se acumula, excepto cuando se produce un conflicto, en cuyo caso la configuración de las directivas posteriores prevalecerá sobre la configuración de directivas anteriores de forma predeterminada. La primera directiva que se debe aplicar es el GPO local. Todos los equipos que ejecutan Windows 2000 tienen almacenado un GPO local. De forma predeterminada, sólo se configuran los nodos de Configuración de seguridad. Las opciones de configuración de otras partes del espacio de nombres del GPO local no se activan ni desactivan. El GPO local se almacena en cada servidor en %systemroot%\System32\GroupPolicy. Tras el GPO local, se aplican los GPO posteriores en el sitio, dominio, unidad organizativa primaria y finalmente en la unidad organizativa secundaria. En el siguiente diagrama se muestra cómo se aplica cada directiva: Ilustración 3.1. Jerarquía de aplicación de GPO. Si se han definido varios GPO en cada nivel, el administrador establecerá el orden en que se aplican. El usuario o el equipo aplicará la configuración definida en una Directiva de grupo si a) la Directiva de grupo se ha aplicado a su contenedor y b) se muestra en la DACL (Lista de Control de Acceso Discrecional) del GPO con un permiso Aplicar directiva de grupos como mínimo. Nota: el grupo integrado Usuarios autenticados tiene el permiso Aplicar directiva de grupos de forma predeterminada. Este grupo contiene todos los usuarios y equipos del dominio. 106 Garantizar la aplicación de la Directiva de grupo La configuración de la Directiva de grupo se encuentra situada (en parte) en Active Directory. Esto significa que los cambios realizados en la Directiva de grupo no se aplican inmediatamente. Primero los controladores de dominio deben replicar los cambios de la Directiva de grupo en otros controladores de dominio. Este proceso puede tardar hasta 15 minutos en un sitio y mucho más tiempo si la replicación se lleva a cabo en otros sitios. Una vez replicados los cambios, debe transcurrir todavía otro período de tiempo (cinco minutos para controladores de domino y 90 minutos más o menos un margen de 30 minutos para otros equipos) para que se actualicen los cambios de la directiva en el equipo de destino. Si lo desea, puede hacer que cualquiera de estas acciones se lleve a cabo de forma inmediata. * Para forzar la replicación de controladores de dominio Abra Sitios y servicios de Active Directory, expanda Sitios, expanda el <nombre del sitio> y, a continuación, expanda Servidores. Expanda <nombre del controlador de dominio 1> y <nombre del controlador de dominio 2> y, a continuación, seleccione Configuración NTDS para cada servidor. En el panel derecho, haga clic con el botón secundario del mouse (ratón) en el nombre del objeto de conexión y seleccione Replicar ahora. Así se forzará la replicación de forma inmediata entre los dos controladores de dominio. Repita los pasos 2 y 3 para cada controlador de dominio. * Para actualizar la directiva de forma manual en un servidor En el s ímbolo del sistema del servidor, escriba Secedit /refreshpolicy machine_policy /enforce. Este comando indica al servidor que compruebe si existen actualizaciones de la directiva en Active Directory y, en caso afirmativo, que las descargue inmediatamente. * Para comprobar la configuración de directiva efectiva Inicie la Directiva de seguridad local. En Configuración de seguridad, haga clic en Directivas locales y luego en Opciones de seguridad. En el panel derecho, examine la columna Configuración vigente para comprobar que se ha aplicado la configuración de seguridad correcta. Nota: puesto que va a aplicar la configuración de seguridad por medio de la Directiva de grupo, es muy importante que comprenda a la perfección sus propiedades e interacciones. Las notas del producto de Microsoft "Windows 2000 Group Policy" (en inglés) contienen información más detallada acerca de su implementación. Para obtener más detalles, consulte el apartado "Más información" que se halla al final de este capítulo. Estructura de la Directiva de grupo Las opciones de configuración de la Directiva de grupo se almacenan en dos ubicaciones: GPO – situados en Active Directory. 107 Archivos de plantillas de seguridad – situados en el sistema de archivos local. Los cambios realizados en el GPO se guardan directamente en Active Directory, mientras que los cambios realizados en los archivos de plantillas de seguridad se deben volver a importar al GPO dentro de Active Directory para poder aplicarlos. Nota: esta guía de operaciones incluye plantillas con las que puede modificar sus GPO. Si realiza cambios y modifica directamente los GPO, éstos no estarán sincronizados con los archivos de plantillas. Por lo tanto, se recomienda que modifique los archivos de plantillas y los vuelva a importar al GPO. Windows 2000 incluye varias plantillas de seguridad. Las siguientes plantillas pueden aplicarse en un entorno de baja seguridad. • Basicwk.inf – para Windows 2000 Professional. • Basicsv.inf – para Windows 2000 Server. • Basicdc.inf – para controladores de dominio basados en Windows 2000. Se incluyen todavía más plantillas para implementar una mayor seguridad en los equipos basados en Windows 2000. Éstas proporcionan opciones de configuración de seguridad adicionales con respecto a las plantillas básicas: • Securedc.inf y Hisecdc.inf – para controladores de dominio. • Securews.inf y Hisecws.inf – para servidores y estaciones de trabajo miembros. Estas plantillas se consideran plantillas incrementales porque, para poder agregarlas, primero se deben aplicar las plantillas básicas. Para esta guía se han creado nuevas plantillas de seguridad utilizando Hisecdc.inf y Hisecws.inf como puntos de partida. El objetivo es la creación de un entorno muy restrictivo que luego podrá abrir de forma selectiva para ofrecer la funcionalidad requerida y al mismo tiempo seguir dando la máxima prioridad a la seguridad. Nota: las plantillas de seguridad predeterminadas de Windows 2000 se encuentran almacenadas como archivos .inf en la carpeta %SystemRoot%\Security\Templates. Formato de las plantillas de seguridad Las plantillas de seguridad son archivos de texto. Para modificar los archivos de plantillas, se pueden utilizar las plantillas de seguridad del complemento de MMC o un editor de texto como el Bloc de Notas. La siguiente tabla muestra la asignación de las secciones de directivas a las secciones de los archivos de plantillas. Tabla 3.1.: Correspondencia de las secciones de las plantillas de seguridad con la configuración de la Directiva de grupo. Sección Directivas Sección Plantillas Directiva de cuentas. [System Access] Directiva de auditoria. [System Log] [Security Log] [Application Log] 108 Derechos de usuario. [Privilege Rights] Opciones de seguridad. [Registry Values] Registro de sucesos. [Event Audit] Grupos restringidos. [Group Membership] Servicios del sistema. [Service General Setting] Registro. [Registry Keys] Sistema de archivos. [File Security] Algunas secciones del archivo de plantillas de seguridad, como [File Security] y [Registry Keys], contienen listas de control de acceso (ACL) específicas. Estas ACL son cadenas de texto definidas por el SDDL (Security Descriptor Definition Language). Para obtener más información acerca de SDDL y de cómo modificar plantillas de seguridad, consulte MSDN. Para obtener más detalles, consulte el apartado "Más información" que se halla al final de este capítulo. Entorno de prueba Es imprescindible que evalúe detalladamente cualquier cambio realizado en la seguridad de los sistemas de TI en un entorno de prueba antes de realizar cambios en el entorno de producción. El entorno de prueba deberá reproducir el entorno de producción lo más exactamente posible. Como mínimo, deberá incluir varios controladores de dominio y todas las funciones de servidor miembro que se tenga en el entorno de producción. Las pruebas son necesarias para determinar si el entorno es funcional después de realizar los cambios, pero también es imprescindible para verificar si se ha aumentado el nivel de seguridad tal y como se había planeado. Deberá validar al máximo todos los cambios y llevar a cabo evaluaciones de vulnerabilidad en el entorno de prueba. Nota: antes de que alguien lleve a cabo evaluaciones de vulnerabilidad en la organización, deberá asegurarse de que haya obtenido el correspondiente permiso por escrito. Comprobar el entorno del dominio Para poder implementar la Directiva de grupo en el entorno de producción, es importante que el entorno del dominio sea estable y funcione correctamente. Entre las áreas clave de Active Directory que deben comprobarse, figuran los servidores DNS, la replicación de controladores de dominio y la sincronización temporal. También deberá utilizar un entorno de prueba para garantizar un entorno de producción estable. Comprobar la configuración de DNS La resolución de nombres de DNS resulta esencial para que funcionen correctamente los servidores y los controladores de dominio. Cuando se implementan varios servidores DNS para un dominio, se deberá comprobar cada uno de ellos. Deberá realizar las siguientes pruebas: En controladores de dominio: 109 Ejecute dcdiag /v y netdiag /v con la opci ón detallada para probar el DNS en cada controlador de dominio y verificar cualquier error que se produzca. DCDIAG y NETDIAG se incluyen en el directorio Support Tools del CD de instalación de Windows 2000. Detenga e inicie el servicio Inicio de sesi ón en la red y compruebe si se produjeron errores en el Registro de sucesos. El servicio Inicio de sesión en la red registrará dinámicamente los registros de servicio en el DNS para el controlador de dominio y generará mensajes de error si no consigue registrar correctamente los registros DNS. Estos registros se servicio figuran en el archivo netlogon.dns, que se encuentra en el directorio %SystemRoot%\System32\Config. En los servidores miembros, utilice nslookup o ejecute netdiag /v para comprobar que el DNS funciona correctamente. Replicación de controladores de dominio Es importante que la replicación entre varios controladores de dominio funcione correctamente antes de implementar la Directiva de grupo. Si la replicación no funciona correctamente, los cambios realizados en la Directiva de grupo no se aplicarán a todos los controladores de dominio. Esto puede crear incoherencias entre los servidores que busquen actualizaciones de la Directiva de grupo en los controladores de dominio. Los servidores se actualizarán si apuntan al controlador de dominio en el que se realizó el cambio, mientras que los servidores que apunten a los controladores de dominio que todavía están esperando a que se replique la Directiva de grupo no se actualizarán. Forzar y comprobar la replicación con Repadmin Repadmin es una herramienta de la línea de comandos que se incluye en el directorio Support del CD de Windows 2000. Puede utilizar repadmin para determinar los socios de replicación del directorio del servidor de destino y, a continuación, emitir un comando para sincronizar el servidor de origen con el de destino. Para ello, utilice el identificador único global (GUID) del objeto del servidor de origen. * Para utilizar repadmin con el fin de forzar la replicación entre dos controladores de dominio En el símbolo del sistema de un controlador de dominio, escriba lo siguiente: repadmin /showreps <nombre_servidor_destino> En la sección In bound Neighbors del resultado, busque la partición del directorio que debe sincronizarse y el servidor de origen con el que se debe sincronizar el servidor de destino. Anote el valor del GUID del objeto del servidor de origen. Escriba el siguiente coma ndo para iniciar la replicación: repadmin /sync <nombredominio_partición_directorio> <Guidobjeto_servidor_origen> <nombre_servidor_destino> Nota: una vez tenga el GUID del objeto de cada controlador de dominio, puede crear un archivo de comandos por lotes que utilice la herramienta repadmin para iniciar la replicación entre servidores y obtener el estado acerca de si se realizó correctamente la replicación. 110 Centralizar las plantillas de seguridad Es muy importante que las plantillas de seguridad utilizadas para la producción estén almacenadas en una ubicación segura a la que sólo puedan tener acceso los administradores responsables de implementar la Directiva de grupo. De forma predeterminada, las plantillas de seguridad están almacenadas en la carpeta %SystemRoot%\security\templates de cada controlador de dominio. Esta carpeta no se replica en varios controladores de dominio. Por lo tanto, deberá seleccionar un controlador de dominio para mantener la copia original de las plantillas de seguridad, de forma que no se produzcan problemas de control de versiones con las plantillas. Configuración temporal Es muy importante que la hora del sistema sea exacta y que todos los servidores utilicen la misma fuente temporal. El servicio W32Time de Windows 2000 proporciona sincronización temporal para equipos basados en Windows 2000 que se ejecuten en un dominio de Active Directory. El servicio W32Time garantiza que los relojes de los clientes basados en Windows 2000 estén sincronizados con los controladores de dominio de un dominio. Esto es necesario para la autenticación Kerberos, pero la sincronización temporal también resulta útil para el análisis de los registros de sucesos. El servicio W32Time sincroniza los relojes por medio de SNTP (Simple Network Time Protocol), tal y como se describe en RFC 1769. En un bosque de Windows 2000, la hora se sincroniza del siguiente modo: El maestro de operaciones del emulador del Controlador de Dominio Principal (PDC) en el dominio raíz del bosque es la fuente de tiempo autoritativa de la organización. Todos los maestros de operaciones del PDC de otros dominios del bosque siguen la jer arquía de dominios cuando se selecciona un emulador del PDC con el que sincronizar la hora. Todos los controladores de dominio de un dominio sincronizan la hora con el maestro de operaciones del emulador del PDC de su dominio como su socio temporal de entrada. Todos los servidores miembros y los equipos de escritorio cliente utilizan el controlador de dominio de autenticación como su socio temporal de entrada. Para garantizar la exactitud de la hora, el emulador del PDC del dominio raíz del bosque deberá estar sincronizado con un servidor temporal SNTP externo. Para configurarlo, ejecute el siguiente comando net time, en el que <lista_servidores> es su lista de servidores: net time /setsntp:<lista_servidores> Nota: si el emulador del PDC de la raíz del bosque se encuentra detrás de un servidor de seguridad, es posible que tenga que abrir el puerto UPD 123 del servidor de seguridad para permitir que el emulador del PDC se conecte a un servidor temporal SNTP de Internet. Si su red utiliza sistemas operativos Windows anteriores en esos equipos, los relojes pueden sincronizarse con el siguiente comando en una secuencia de comandos de inicio de sesión, en el que <equipotemporal> es un controlador de dominio de la red. net time \\<equipotemporal> /set /yes 111 Nota: los equipos que ejecuten un sistema operativo distinto de Windows también deberán sincronizar sus relojes con fuentes temporales externas para permitir el análisis de los sucesos registrados en función de la hora. Para obtener más información, consulte el artículo de Microsoft Knowledge Base Q216734, "How to Configure an Authoritative Time Server in Windows" (en inglés). Diseño e implementación de directivas Para utilizar la Directiva de grupo de forma eficiente, deberá determinar cuidadosamente su aplicación. Con el fin de simplificar el proceso de aplicación y comprobación de la configuración de seguridad de la Directiva de grupo, se recomienda aplicarla en dos niveles: Nivel de dominios. Para cumplir los requisitos de seguridad comunes, como las directivas de cuentas y de auditoría que deben respetarse para todos los servidores. Nivel de unidad organizativa. Para cumplir los requisitos de seguridad específicos de servidores que no son comunes a todos los servidores de la red. Por ejemplo, los requisitos de seguridad de los servidores de infraestructuras son distintos de los requisitos de los servidores que ejecutan IIS. Las opciones de configuración de la Directiva de grupo que afectan a la seguridad se encuentran divididas en varias secciones. Tabla 3.2.: Secciones de la Directiva de grupo y su finalidad. Sección Directivas Descripción Directiva de cuentas\Directiva de contraseñas. Duración, longitud y complejidad de la contraseña configuradas. Directiva de cuentas\Directiva de bloqueo de cuentas. Duración, umbral y contador de restablecimiento de bloqueo configurados. Directiva de cuentas\Directiva de Kerberos. Vigencias de vales configuradas. Directivas auditoría. locales\Directiva de Activar/Desactivar el registro de sucesos específicos. Directivas usuario. locales\Derechos de Definir derechos tales como el inicio de sesión local, el acceso desde la red, etc. Directivas locales\Opciones seguridad. de Modificar valores del registro específicos relacionados con la seguridad. Registro de sucesos. Supervisión de aciertos y errores activada. Grupos restringidos. Los administradores pueden controlar los miembros de grupos específicos. Servicios del sistema. Controla el modo de inicio de cada servicio. Registro. Configurar los permisos de claves de registro. 112 Sistema de archivos. Configurar los permisos de carpetas, subcarpetas y archivos. Todos los equipos tienen una directiva local predefinida. Al crear un dominio de Active Directory, se crean también directivas de dominios y de controladores de dominio predeterminadas. Antes de modificar cualquier directiva predeterminada, es importante documentar la configuración que contiene, de forma que se pueda volver fácilmente al estado anterior si se produce un problema. Funciones del servidor Para esta guía, se han definido varias funciones del servidor y se han creado plantillas de seguridad para aumentar la seguridad de estas funciones. Tabla 3.3.: Funciones de Windows 2000 Server. Función del servidor Descripción Plantillas de seguridad Controlador de dominio de Windows 2000. Controlador de dominio de Active Directory. BaselineDC.inf. Servidor de aplicaciones de Windows 2000. Servidor miembro bloqueado en el que se pueden instalar servicios como Exchange 2000. Para que el servicio funcione correctamente, será necesario disminuir la seguridad. Baseline.inf. Servidor de archivos e impresión de Windows 2000. Servidor de archivos impresión bloqueado. e Baseline.inf y File and Print Incremental.inf. Servidor de infraestructuras de Windows 2000. Servidor DNS, WINS (Windows Internet Name Service) y DHCP bloqueado. Baseline.inf e Infrastructure Incremental.inf. Servidor IIS de Windows 2000. Servidor IIS bloqueado. Baseline.inf e Incremental.inf. IIS Los requisitos de seguridad de cada una de estas funciones son distintos. La configuración de seguridad apropiada para cada función se trata en mayor detalle en el capítulo 4, "Asegurar servidores basándose en su función". Nota: esta guía asume que los servidores realizan funciones específicas bien definidas. Si los servidores no coinciden con estas funciones o tiene servidores multiuso, deberá utilizar las opciones de configuración aquí definidas como pauta para crear sus propias plantillas de seguridad. No obstante, deberá tener en cuenta que cuanto mayor sea el número de funciones realizadas por los servidores, más vulnerables serán a los ataques. 113 Estructura de Active Directory para admitir las funciones del servidor Tal y como se mencionó anteriormente, se puede aplicar la Directiva de grupo de muchas formas distintas, con varios GPO y en varios niveles distintos de jerarquía. Para esta guía, hemos definido varias opciones de configuración de la Directiva de grupo que se pueden utilizar para asegurar las distintas funciones del servidor. Deberá asegurarse de que su estructura de Active Directory le permite aplicar estas opciones de configuración. Para ayudarle a asegurar su entorno basado en Windows 2000, se han predefinido algunas plantillas de seguridad que se pueden importar a los GPO. No obstante, si se van a utilizar tal y como se proporcionan, deberá comprobar que tienen la estructura de Active Directory adecuada. Los GPO definidos en esta guía se han diseñado para utilizarlos con la estructura de unidad organizativa que se muestra en el diagrama. Ilustración 3.2. Estructura de unidad organizativa para el uso con GPO definidos. Nota: en este caso, la estructura del dominio no es relevante, puesto que las Directivas de grupo de dominios y de unidad organizativa sólo afectan a los dominios en los que se definieron. La estructura del sitio tampoco tiene importancia, puesto que en esta guía no se definen los GPO en el nivel de sitios. Para crear la estructura de unidad organizativa 1. Inicie Usuarios y equipos de Active Directory. 2. Haga clic con el botón secundario del mouse en el nombre del dominio, seleccione Nuevo y, a continuación, seleccione Unidad organizativa. 3. Escriba Servidores miembros y, a continuación, haga clic en Aceptar. 4. Haga clic con el botón secundario del mouse en Servidores miembros, seleccione Nuevo y, a continuación, seleccione Unidad organizativa. 5. Escriba Servidores de aplicaciones y, a continuación, haga clic en Aceptar. 6. Repita los pasos 5 y 6 para Servidores de archivos e impresión, Servidores IIS y Servidores de infraestructuras. 114 Es importante examinar de forma más detallada la estructura de unidad organizativa. Directiva del nivel de dominios Cuando se crea un dominio de Windows 2000, se crea una directiva de dominio predeterminada. Para la configuración de seguridad que desea aplicar a todo el dominio, puede: Crear una directiva adicional y vincularla sobre la directiva predeterminada. Modificar la directiva predeterminada existente. Normalmente, resulta más sencillo modificar la directiva existente; no obstante, la ventaja de crear una directiva de dominio adicional en lugar de modificar la predeterminada es que si se producen problemas con la adicional, puede desactivarse y dejar que la predeterminada vuelva a tomar el control. Tenga en cuenta que, a menudo, los dominios contienen usuarios y equipos cliente además de servidores. Por lo tanto, si desea bloquear servidores, a menudo resultará poco práctico definir la configuración específica en el nivel de dominios. En la práctica, suele ser mejor restringir las opciones de configuración de seguridad del servidor a las que se deben establecer en el nivel de dominios. En esta guía de operaciones, no se definen opciones de configuración específicas en el nivel de dominios, puesto que muchas de ellas, como la longitud de contraseñas, se modificarán en función de la directiva de seguridad general de la organización. No obstante, la guía contiene recomendaciones generales, que pueden consultarse en el capítulo 4, "Asegurar servidores basándose en su función". Nota: la directiva de contraseñas y de cuentas SÓLO afecta a las cuentas del dominio si éstas se han configurado en el nivel de dominios (de forma que sólo se puede configurar una directiva de contraseñas y de cuentas por dominio). Si las directivas se establecen en el nivel de unidad organizativa o en cualquier otro nivel, sólo afectarán a las cuentas locales. Para obtener más información, consulte el artículo de Knowledge Base Q259576,"Group Policy Application Rules for Domain Controllers" (en inglés). Unidad organizativa de los servidores miembros Muchas de las opciones de configuración de seguridad que se definen para los servidores miembros deberán aplicarse a todas las funciones de servidores miembros. Para simplificar este proceso, se ha creado una plantilla de seguridad de línea de base denominada Baseline.inf que puede importarse a un GPO y aplicarse a la unidad organizativa de los servidores miembros. Estas opciones de configuración se aplicarán tanto a la unidad organizativa de los servidores miembros como a cualquiera de las unidades organizativas secundarias. Unidad organizativa de los controladores de dominio Windows 2000 incluye una unidad organizativa de controladores de dominio. Cuando un servidor se convierte en un controlador de dominio, se ubica automáticamente en la unidad y no se debe eliminar, puesto que puede causar problemas de inicio de sesión y de acceso a los usuarios. Con esta guía, se proporciona una plantilla de seguridad denominada BaselineDC.inf, que puede importarse a un GPO y aplicarse a la unidad organizativa de los controladores de dominio. Puede 115 aplicarla al GPO de controladores de dominio predeterminado o simplemente modificar las opciones de configuración del GPO de controladores de dominio predeterminado. Unidades organizativas individuales de funciones del servidor Las unidades organizativas individuales de funciones del servidor son unidades organizativas secundarias de la unidad organizativa del servidor miembro. Por esta razón, estos servidores adoptarán las opciones de configuración definidas en la Directiva de línea de base para los servidores miembros de forma predeterminada. Si se utiliza la directiva de línea de base para asegurar los servidores miembros, se deberá llevar a cabo modificaciones que se aplicarán a cada función del servidor. Para ello, se puede asignar GPO a cada unidad organizativa de funciones del servidor. Con esta guía, se proporcionan plantillas de seguridad que se puede importar a GPO para cada unidad organizativa de funciones del servidor. Las funciones del servidor se tratan en mayor detalle en el capítulo 4, "Asegurar servidores basándose en su función". Importar las plantillas de seguridad El siguiente procedimiento importa las plantillas de seguridad proporcionadas con esta guía a la estructura de unidad organizativa propuesta en este capítulo. Para poder implementar el siguiente procedimiento en un controlador de dominio, se deberá extraer el contenido del archivo SecurityOps.exe file que se proporciona con esta guía. Advertencia: las plantillas de seguridad de esta guía se han diseñado para aumentar la seguridad del entorno. Es posible que, al instalar las plantillas proporcionadas con la guía, se pierda alguna funcionalidad del entorno. Esto puede incluir errores de aplicaciones fundamentales. Por lo tanto, es ESENCIAL que se pruebe al máximo estas plantillas antes de instalarlas en un entorno de producción y se realicen los cambios adecuados para el entorno. Antes de aplicar nuevas opciones de configuración de seguridad, realice una copia de seguridad de cada servidor y controlador de dominio. Asegúrese de incluir el estado del sistema en la copia de seguridad, puesto que en él se guardan los datos del registro y, que respecto a los controladores de dominio, también incluye todos los objetos de Active Directory. Nota: antes de continuar, si utiliza Windows 2000 Service Pack 2, deberá aplicar la revisión descrita en el artículo de Knowledge Base Q295444, "SCE Cannot Alter a Service's SACL Entry in the Registry" (en inglés). Si no se aplica esta revisión, las plantillas de la Directiva de grupo no podrán desactivar ningún servicio. Importar la directiva de línea de base de controladores de dominio 1. En Usuarios y Equipos de Active Directory, haga clic con el botón secundario del mouse en Controladores de Dominio y, a continuación, seleccione Propiedades. 2. En la ficha Directiva de grupo, haga clic en Nuevo para agregar un nuevo Objeto de directiva de grupo. 3. Escriba Directiva de línea de base de controladores de dominio y presione Entrar. 4. Haga clic con el botón secundario del mouse en Directiva de línea de base de controladores de dominio y seleccione No reemplazar. 116 Nota: se requiere esta opción de configuración porque la directiva de controladores de dominio predeterminada configura todas las opciones de configuración de directivas de auditoría como Sin auditoría, con la excepción de la administración de cuentas. Puesto que la directiva de controladores de dominio predeterminada tiene mayor prioridad, la opción de configuración Sin auditoría se convertirá en la opción de configuración válida. 5. Haga clic en Modificar. 6. Expanda la Configuración de Windows, haga clic en Configuración de seguridad con el botón secundario y seleccione Importar directiva. Nota: si Importar directiva no aparece en el menú, cierre la ventana Directiva de grupo y repita los pasos 4 y 5. 7. En el cuadro de diálogo Importar la directiva desde, desplácese a C:\SecurityOps\Templates y haga doble clic en BaselineDC.inf. 8. Cierre Directiva de grupo y haga clic en Cerrar. 9. Fuerce la réplica entre los controladores de dominio a fin de que todos los controladores dispongan de la directiva. 10. Compruebe en el Registro de sucesos que se ha descargado correctamente la directiva y que el servidor puede comunicarse con los otros controladores de dominio del dominio. 11. Reinicie todos los controladores de dominio de uno en uno para garantizar un reinicio correcto. Importar las directivas de servidores miembros 1. En Usuarios y equipos de Active Directory, haga clic con el botón secundario del mouse en Servidores miembros y, a continuación, seleccione Propiedades. 2. En la ficha Directiva de grupo, haga clic en Nuevo para agregar un nuevo Objeto de directiva de grupo. 3. Escriba Directiva de línea de base y presione Entrar. 4. Haga clic en Modificar. 5. Expanda la Configuración de Windows, haga clic en Configuración de seguridad con el botón secundario y seleccione Importar directiva. Nota: si Importar directiva no aparece en el menú, cierre la ventana Directiva de grupo y repita los pasos 4 y 5. 6. En el cuadro de diálogo Importar la directiva desde, desplácese a C:\SecurityOps\Templates y haga doble clic en Baseline.inf. 7. Cierre Directiva de grupo y haga clic en Cerrar. 8. Repita los pasos 1 a 7 con la unidad organizativa y los archivos de plantillas de seguridad siguientes: 117 Unidad organizativa Plantilla de seguridad Servidores de archivos e impresión File and Print Incremental.inf Servidores IIS IIS Incremental.inf Servidores de infraestructuras Infrastructure Incremental.inf 9. Fuerce la réplica entre los controladores de dominio a fin de que todos los controladores dispongan de la directiva. 10. Mueva un servidor para cada función a la unidad organizativa correspondiente y, en el servidor, descargue la directiva por medio del comando secedit. 11. Compruebe en el Registro de sucesos que se ha descargado correctamente la directiva y que el servidor puede comunicarse con los controladores de dominio y con otros servidores del dominio. Después de realizar pruebas con resultados satisfactorios en un servidor de la unidad organizativa, mueva los servidores restantes a la unidad organizativa y, a continuación, aplique la seguridad. 12. Reinicie cada servidor para asegurarse de que se reinician correctamente. Mantener la seguridad de la configuración de la Directiva de grupo Si aplica la configuración de seguridad por medio de la Directiva de grupo, es importante garantizar que la configuración sea lo más segura posible. Para ello, se suele comprobar que los permisos de los GPO y de las unidades organizativas y los dominios en los que se aplica se hayan configurado correctamente. Las plantillas proporcionadas con esta guía no modifican los permisos predeterminados de Active Directory, por lo que necesitará modificarlos de forma manual. Puede suceder que la configuración de la Directiva de grupo definida en contenedores de nivel superior sea reemplazada por la configuración de contenedores de nivel inferior. Para evitar que se reemplace la configuración de un contenedor de nivel superior, utilice la opción No reemplazar del GPO. Nota: no establezca No reemplazar en la directiva de línea de base para los servidores miembros. Si lo hace, las directivas de funciones del servidor no podrán activar los servicios y las opciones de configuración adecuados. Además de separar las funciones del servidor en el nivel de unidad organizativa, también deberá crear las funciones de administrador correspondientes por separado y asignarles derechos administrativos sobre las unidades organizativas que les correspondan. De este modo, si un intruso consigue hacerse con los derechos administrativos del servidor IIS, no podrá tener acceso a los servidores de infraestructuras y así sucesivamente. Sólo los administradores del nivel de dominios y superiores deben tener derechos para modificar los miembros de una unidad organizativa. Si un administrador del nivel de unidad organizativa puede eliminar un servidor de la misma, podrá modificar la configuración de seguridad de los servidores. Una vez aplicada la directiva a los servidores, todavía deberán llevarse a cabo varias tareas. Deberá comprobar los servidores regularmente para asegurarse de que: 118 Se ha aplicado la directiva correcta al servidor. Ning ún administrador ha cambiado una opción de configuración de la directiva y ha disminuido el nivel de seguridad de los servidores. Se han aplicado todos los cambios o las act ualizaciones a todos los servidores. Al comprobar que la configuración del GPO se ha aplicado a los servidores de forma correcta, sabrá que los servidores se han asegurado adecuadamente. Puede utilizar varios métodos para examinar la Directiva de grupo de un servidor y comprobar si se ha configurado correctamente. Sucesos del Registro de sucesos Si se descarga correctamente la directiva, se muestra un suceso del Registro de sucesos con la siguiente información: Tipo: información Id. de origen: SceCli Id. de suceso: 1704 Cadena de mensaje: la directiva de seguridad de los objetos de directiva de grupo se ha aplicado correctamente. Puede que el mensaje tarde varios minutos en aparecer tras haber aplicado la directiva. Si no recibe el mensaje, deberá ejecutar secedit /refreshpolicy machine_policy /enforce y, a continuación, reiniciar el servidor para forzar la descarga de la directiva. Vuelva a comprobar el Registro de sucesos tras haber reiniciado para asegurarse de que se ha descargado correctamente la directiva. Nota: cuando los servicios están establecidos como Deshabilitado en un GPO y se reinicia una vez el servidor, normalmente los servicios se habrán reiniciado antes de que se aplique la configuración definida en el GPO. Si vuelve a reiniciar el servidor, se garantiza que no se inicien los servicios establecidos como Deshabilitado. Comprobar la directiva con el MMC de la directiva de seguridad local Para comprobar si se ha aplicado correctamente la directiva, también puede revisar la configuración de directiva efectiva del servidor local. u Para comprobar la configuración de directiva efectiva 1. Inicie el MMC de la Directiva de seguridad local. 2. En Configuración de seguridad, haga clic en Directivas locales y luego en Opciones de seguridad. 3. En el panel derecho, muestre la columna Configuración vigente. La columna Configuración vigente deberá mostrar las opciones configuradas en la plantilla para la función del servidor seleccionado. 119 Comprobar la directiva con herramientas de la línea de comandos Existen también dos herramientas de la línea de comandos que sirven para comprobar la configuración de la directiva. Secedit Esta herramienta está incluida en Windows 2000 y sirve para mostrar las diferencias existentes entre el archivo de plantillas y la directiva del equipo. Para comparar una plantilla con la directiva actual de un equipo, utilice la siguiente línea de comandos: secedit /analyze /db secedit.sdb /cfg <nombre de la plantilla> Nota: si aplica las plantillas proporcionadas con esta guía y, a continuación, ejecuta el comando anterior, se generará un error de acceso denegado. Esto se debe a la seguridad adicional aplicada. También se generará un archivo de registro con los resultados del análisis. Gpresult Windows 2000 Server. Kit de recursos (Microsoft Press, ISBN: 1-57231-805-8) incluye una herramienta denominada GPResult que sirve para mostrar las directivas aplicadas en la actualidad a un servidor. Para obtener una lista de las directivas aplicadas a un servidor, utilice la siguiente línea de comandos: Gpresult /c Nota: Gpresult se trata en mayor detalle en el apartado "Solucionar problemas de la Directiva de grupo" más adelante en este capítulo. Auditar la Directiva de grupo Se pueden auditar los cambios de la Directiva de grupo. La auditoría de los cambios de la directiva puede servir para realizar un seguimiento de las personas que están modificando o intentando modificar la configuración de directiva. La auditoría de los aciertos y errores de los cambios de la directiva se activa en las plantillas de seguridad de línea de base. Solucionar problemas de la Directiva de grupo Aunque la Directiva de grupo se aplica de forma automática, es posible que la Directiva de grupo resultante de un servidor no sea la que se esperaba, principalmente porque puede configurarse en varios niveles. En este apartado se proporcionan instrucciones que pueden utilizarse para solucionar problemas de la Directiva de grupo. Nota: si se produce un problema específico de la Directiva de grupo que no se menciona en este capítulo, consulte Microsoft Knowledge Base. Algunos artículos importantes de Knowledge Base acerca de la Directiva de grupo figuran en el apartado "Más información" al final de este capítulo y en las notas del producto "Troubleshooting Group Policy" (en inglés). Herramientas del kit de recursos GPResult y GpoTool son dos herramientas de Windows 2000 Server. Kit de recursos que le ayudarán a solucionar problemas de la Directiva de grupo. 120 Nota: estas herramientas también se encuentran disponibles en línea; consulte el apartado "Más información" que se halla al final de este capítulo para obtener más detalles. GPResult Esta herramienta proporciona una lista de todos los GPO que se han aplicado a un equipo, el controlador de dominio del que proceden los GPO y la fecha y la hora en la que se aplicaron los GPO la última vez. Al ejecutar GPResult en un servidor para comprobar que tiene los GPO correctos, utilice el modificador /c para mostrar únicamente información acerca de la configuración del equipo. Cuando se utiliza GPResult con el modificador /c, proporciona la siguiente información general: Sistema operativo: Tipo (Professional, Server, controlador de dominio). N úmero de versión y detalles de Service Pack. Si est á instalado Servicios de Terminal Server y, en caso afirmativo, el modo que utiliza. Informaci ón del equipo: Nombre y ubicación del equipo en Active Directory (si corresponde). Nombre y tipo de dominio (Windows NT o Windows 2000). Nombre del sitio. GPResult con el modificador /c también proporciona la siguiente información acerca de la Directiva de grupo: Última vez que se aplicó la directiva y el controlador de dominio que la aplicó, para el usuario y el equipo. Lista completa de los Objetos de directiva de grupo y sus detalles, incluido un resumen de las extensiones que contiene cada Objeto de directiva de grupo. Configuraci ón del registro aplicada y sus detalles. Carpetas redirigidas y sus detalles. Informaci ón de gestión de software, incluidas las aplicaciones asignadas y publicadas. Informaci ón de la cuota de disco. Configuraci ón de seguridad IP. Archivos de comandos. GpoTool 121 Esta herramienta de la línea de comandos le permite comprobar las condiciones de los Objetos de directiva de grupo en controladores de dominio, entre ellas: Comprobar la coherencia de los Objetos de directiva de grupo. La herramienta lee las propiedades de los servicios de directorio obligatorias y opcionales (versión, nombre descriptivo, GUID de extensiones y datos del volumen del sistema [SYSVOL] de Windows 2000 [Gpt.ini]), compara números de versión de los servicios de directorio y SYSVOL y lleva a cabo otras comprobaciones de coherencia. Si la propiedad de las extensiones contiene algún GUID, la versión de funcionalidad debe ser 2 y la versión del usuario o equipo debe ser superior a 0. Comprobar la replicación del Objeto de directiva de grupo. Lee las instancias de GPO de cada controlador de dominio y las compara (propiedades seleccionadas del contenedor de la Directiva de grupo y comparación recursiva completa de la plantilla de la Directiva de grupo). Mostrar información acerca de un GPO determinado. Incluye propiedades a las que no se puede tener acceso mediante el complemento Directiva de grupo, como la versión de funcionalidad y los GUID de extensiones. Examinar GPO. Una opción de la línea de comandos permite realizar búsquedas de directivas en función del nombre descriptivo o el GUID. Es posible realizar búsquedas parciales del nombre o el GUID. Controladores de dominio preferidos. De forma predeterminada, se utilizarán todos los controladores disponibles en el dominio, aunque se puede omitir este comportamiento si se incluye en la línea de comandos una lista de los controladores de dominio preferidos. Ejecutar en distintos dominios. Existe una opción de la línea de comandos que permite comprobar las directivas de distintos dominios. Ejecutar en modo detallado. Si todas las directivas son correctas, la herramienta muestra un mensaje de validación; si hay errores, se imprime información acerca de las directivas dañadas. Una opción de la línea de comandos permite activar la información detallada para cada una de las directivas que se procesan. Utilice la siguiente línea de comandos para obtener detalles acerca de una Directiva de grupo y de si se detectan errores en la directiva: GPOTool /gpo:<nombre de gpo> Errores del Registro de sucesos de la Directiva de grupo Algunos errores del Registro de sucesos de la Directiva de grupo indican problemas específicos del entorno. Los dos siguientes no permiten que se aplique correctamente la Directiva de grupo: En un controlador de dominio, el suceso de advertencia 1202 combinado con el suceso de error 1000. Suele indicar que se ha movido un controlador de dominio de la unidad organizativa de controladores de dominio a otra unidad organizativa que no tiene vinculado el GPO de controladores de dominio predeterminado. Cuando un administrador intenta abrir uno de los GPO predeterminados, se devuelve el siguiente error: No se puede abrir el objeto de directiva de grupo. 122 Puede que no disponga de los derechos adecuados. Detalles: error no especificado. En el registro de sucesos, aparecen los sucesos 1000, 1001 y 1004. Esto se debe a un archivo registry.pol dañado. Los errores deberían desaparecer al eliminar el archivo registry.pol de SYSVOL, reiniciar y realizar un cambio en el servidor. Resumen La Directiva de grupo de Windows 2000 es un método útil para proporcionar una configuración coherente a todo el entorno basado en Windows 2000. Para aplicarla de forma eficaz, deberá saber dónde se aplican los GPO, comprobar que todos los servidores reciben la configuración adecuada y asegurarse de haber definido una seguridad apropiada para los GPO. Más información Notas del producto de Microsoft acerca de la Directiva de grupo: http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolwp.asp (en inglés). Notas del producto de Microsoft acerca de la solución de problemas de la Directiva de grupo: http://www.microsoft.com/Windows2000/techinfo/howitworks/management/gptshoot.asp inglés). (en Artículos de Knowledge Base acerca de la solución de problemas de la Directiva de grupo: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q250842 (en inglés). http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q216359 (en inglés). Formato del archivo de plantillas administrativas: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/policy/policyref_17hw.asp inglés). (en Lenguaje de definición del descriptor de seguridad: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/accctrl_757p.asp inglés). (en Para obtener herramientas adicionales e información acerca de la Directiva de grupo, consulte: Windows 2000 Server. Kit de recursos (Microsoft Press, ISBN: 1-57231-805-8) o en línea: http://www.microsoft.com/windows2000/techinfo/reskit/default.asp (en inglés). 4. Asegurar servidores basándose en su función En el capítulo anterior, observamos cómo se puede usar una directiva de grupo para definir la configuración de seguridad en los servidores. En este capítulo, veremos aspectos más específicos, como las directivas de línea de base que se pueden definir para todos los servidores 123 miembros y controladores de dominio de la organización, y otras modificaciones que puede aplicar a funciones específicas del servidor. Este enfoque permite que los administradores bloqueen los servidores por medio de directivas de línea de base centralizadas, aplicadas de forma coherente a todos los servidores de la organización. Las directivas de línea de base sólo permiten una funcionalidad mínima, pero sí permiten que los servidores se comuniquen con otros equipos en el mismo dominio y su autenticación a través de los controladores de dominio. A partir de este estado más seguro, se pueden aplicar otras directivas incrementales más, que permiten que cada servidor realice únicamente las tareas específicas definidas por su función. Su estrategia de administración de riesgos determinará si es apropiado para su entorno que lleve a cabo estos cambios. Estas operaciones guían la implementación de las directivas de particiones de la siguiente manera: Directiva para todo el dominio . Aborda los requisitos de seguridad comunes, como las directivas de cuentas que se deben aplicar para todos los servidores y estaciones de trabajo. Directivas para el controlador de dominio . Directivas que se aplican a la OU de los controladores de dominio. En particular, la configuración afecta a las directivas de auditoría, las opciones de seguridad y la configuración de servicios. Directivas de l ínea de base para los servidores miembros. La configuración común para todos los servidores miembros, como las directivas de auditoría, la configuración de servicios, las directivas que restringen el acceso al registro, el sistema de archivos y otros parámetros de seguridad específicos, como borrar el archivo de páginas de la memoria virtual al apagar el sistema. Directivas para la función del servidor. Se definen cuatro funciones distintas de servidor: servidores de aplicaciones, servidores de archivos y de impresión, servidores de infraestructura y servidores IIS. Para cada función, se describen necesidades y configuraciones de seguridad específicas. Este capítulo trata acerca de estas directivas y de otras configuraciones que se deben definir para determinadas funciones de servidor. Para obtener más información acerca del uso de las directivas de grupo para aplicar configuraciones de seguridad, consulte el capítulo 3, "Administrar la seguridad con la Directiva de grupo de Windows 2000". Directivas de dominio En este manual de operaciones, no se aplica una configuración específica en el nivel de dominio, ya que muchos de estos parámetros, como la longitud de la contraseña, varían dependiendo de las directivas de seguridad globales de la organización. No obstante, es muy importante que defina esta configuración de manera apropiada. Directiva de contraseñas De forma predeterminada, se aplica una directiva de contraseñas estándar a todos los servidores del dominio. La tabla muestra la configuración de una directiva de contraseñas estándar y los mínimos recomendados para su entorno. Tabla 4.1.: Directiva de contraseñas: configuración predeterminada y recomendada. 124 Directiva Configuración predeterminada Configuración mínima recomendada Forzar el historial de contraseñas 1 contraseña recordada 24 contraseñas recordadas Vigencia máxima de la contraseña 42 días 42 días Vigencia mínima de la contraseña 0 días 2 días Longitud mínima de la contraseña 0 caracteres 8 caracteres Las contraseñas deben cumplir los requisitos de complejidad Deshabilitado Habilitado Almacenar contraseña usando cifrado reversible para todos los usuarios del dominio Deshabilitado Deshabilitado Requisitos de complejidad Cuando está activada la opción Las contraseñas deben cumplir los requisitos de complejidad de la directiva de grupo, es necesario que las contraseñas tengan una longitud de al menos 6 caracteres (aunque se recomienda establecerla en 8 caracteres). También se necesita que las contraseñas contengan caracteres de al menos tres de estas clases: Letras del alfabeto ingl és en mayúsculas A, B, C… Z. Letras del alfabeto ingl és en minúsculas a, b, c… z. Números arábigos 0, 1, 2… 9. Caracteres que no sean alfanum éricos, como los signos de puntuación. Nota: la directiva de contraseñas no sólo debe aplicarse en los servidores que ejecutan Windows 2000, sino en todos los dispositivos que utilicen una contraseña para la autenticación. Los dispositivos de red, como los enrutadores y los conmutadores, son muy sensibles a los ataques si utilizan contraseñas simples. Los atacantes pueden intentar controlar estos dispositivos de red para superar los servidores de seguridad. Directiva de bloqueo de cuentas Una directiva eficaz de bloqueo de cuentas puede evitar que un atacante adivine las contraseñas de sus cuentas. La siguiente tabla muestra la configuración de una directiva de bloqueo de cuentas predeterminada y los requisitos mínimos recomendados para su entorno. Tabla 4.2.: Directiva de cuentas: configuración predeterminada y recomendada. Directiva Configuración predeterminada Configuración mínima recomendada Duración del bloqueo de No definido 30 minutos 125 cuenta Umbral cuenta de bloqueo de Restablecer el bloqueo de cuenta después de 0 5 intentos incorrectos de inicio de sesión No definido 30 minutos Con los mínimos recomendados que se indican aquí, una cuenta que tenga cinco intentos incorrectos de inicio de sesión en un plazo de 30 minutos se bloquea durante 30 minutos (transcurrido este tiempo, se restablece la configuración en 0 intentos incorrectos y se puede volver a intentar iniciar una sesión). La cuenta sólo se puede activar antes de que hayan transcurrido los 30 minutos si un administrador restablece el bloqueo. Para aumentar el nivel de seguridad de su organización, debe considerar la posibilidad de aumentar la duración del bloqueo de cuenta y disminuir el umbral de bloqueo. Nota: las directivas de contraseña y de cuentas deben establecerse en el nivel de dominio. Si se establecen en el nivel de la OU o en cualquier otro lugar de Active Directory, afectarán a las cuentas locales y no a las cuentas de dominio. Sólo se puede tener una directiva de cuentas de dominio; para obtener más información, consulte el artículo de Knowledge Base Q255550, "Configuring Account Policies in Active Directory" (en inglés). Directivas de línea de base para los servidores miembros Una vez establecida la configuración en el nivel de dominio, puede definir la configuración común para todos los servidores miembros. Esto se hace a través de un GPO en la OU del servidor miembro, conocido como directiva de línea de base. Un GPO común automatiza el proceso de configuración de parámetros de seguridad específicos en cada servidor. También deberá aplicar manualmente cierta configuración de seguridad adicional que no se puede aplicar mediante directivas de grupo. Directiva de grupo de línea de base para los servidores miembros La configuración de la directiva de línea de base que se utiliza en este manual se obtiene de la directiva hisecws.inf incluida en las instalaciones del servidor y de las estaciones de trabajo. Algunas de las áreas incluidas en hisecws.inf son: Directiva de auditoría. Determina cómo se lleva a cabo la auditoría en los servidores. Opciones de seguridad. Determina la configuración de seguridad específica mediante valores de registro. Listas de control de acceso a registros. Determinan quién tiene acceso a los registros. Listas de control de acceso a archivos. Determinan quién tiene acceso al sistema de archivos. Configuración de servicios. Determina qué servicios se inician, se detienen, se deshabilitan, etc. Para este manual, hemos modificado hisecws.inf para hacerlo más seguro. La Directiva de línea de base para los servidores miembros, baseline.inf, ayuda a crear un servidor notablemente más resistente a los ataques en los entornos de producción. Hisecws.inf se ha modificado agregándole: 126 Valores del registro relacionados con la seguridad. Configuraci ón de servicios. Listas de control de acceso a archivos m ás restringidas. Una configuraci ón de auditoría mejorada. Directiva de línea de base para la auditoría de servidores miembros La configuración de los registros de sucesos del sistema, de seguridad y de las aplicaciones se establece en la directiva y se aplica a todos los servidores miembros del dominio. El tamaño de cada uno de estos registros se establece en 10 megabytes (MB) y se configura cada registro para que no sobrescriba sucesos. Por lo tanto, es importante que un administrador los revise regularmente y los archive o los borre, según sea necesario. Nota: si un sistema de administración controla regularmente los registros para detectar sucesos específicos, y extrae y reenvía los detalles a una base de datos de administración, se capturarán los datos necesarios y, por lo tanto, podrá establecer que los archivos de registro se sobrescriban. La siguiente tabla muestra la configuración definida en la Directiva de línea de base para la auditoría de servidores miembros. Tabla 4.3.: Configuración de la Directiva de línea de base para la auditoría de servidores miembros. Directiva Configuración del equipo Auditar sucesos de inicio de sesión de cuenta Acierto, error Auditar la administración de cuentas Acierto, error Auditar el acceso al servicio de directorios Error Auditar sucesos de inicio de sesión Acierto, error Auditar el acceso a objetos Acierto, error Auditar el cambio de directivas Acierto, error Auditar el uso de privilegios Error Auditar el seguimiento de procesos No auditar Auditar sucesos del sistema Acierto, error Restringir el acceso de Invitado al registro de aplicaciones Habilitado Restringir el acceso de Invitado al registro de seguridad Habilitado 127 Restringir el acceso de Invitado al registro del sistema Habilitado Método de retención del registro de la aplicación No sobrescribir sucesos (limpiar el registro manualmente) Método de retención del registro de seguridad No sobrescribir sucesos (limpiar el registro manualmente) Método de retención del registro del sistema No sobrescribir sucesos (limpiar el registro manualmente) Apagar el equipo cuando se llene el registro de auditorías de seguridad No definido Nota: se muestra la configuración de la directiva para el método de retención Manualmente, lo que significa que no se sobrescribirán los sucesos (el registro se borrará manualmente). Directiva de línea de base para las opciones de seguridad de los servidores miembros Las siguientes opciones de seguridad están configuradas en la directiva de grupo de línea de base. Tabla 4.4.: Configuración de la directiva de línea de base para las opciones de seguridad de los servidores miembros. Opción Configuración Restricciones adicionales para conexiones anónimas No obtener acceso sin permisos anónimos explícitos Permitir a los operadores de servidor programar tareas (sólo controladores de dominio) Deshabilitado Permitir apagar el sistema sin tener que iniciar sesión Deshabilitado Permitir expulsar medios NTFS extraíbles Administradores Tiempo de inactividad requerido antes de desconectar la sesión 15 minutos Auditar el acceso de objetos globales del sistema Deshabilitado Auditar el uso del privilegio de copia de seguridad y restauración Deshabilitado Cerrar automáticamente la sesión de los usuarios cuando termine el tiempo de sesión No definido (vea la nota) 128 Cerrar automáticamente la sesión de los usuarios cuando termine el tiempo de sesión (local) Habilitado Borrar el archivo de páginas de la memoria virtual al apagar el sistema Habilitado Firmar digitalmente la comunicación con el cliente (siempre) Habilitado Firmar digitalmente la comunicación con el cliente (cuando sea posible) Habilitado Firmar digitalmente la comunicación con el servidor (siempre) Habilitado Firmar digitalmente la comunicación con el servidor (cuando sea posible) Habilitado Deshabilitar el requisito de presionar Ctrl+Alt+Supr para iniciar la sesión Deshabilitado No mostrar el último nombre de usuario en la pantalla de inicio de sesión Habilitado Nivel de autenticación de LAN Manager Enviar sólo respuestas NTLMv2, rechazar LM y NTLM Texto del mensaje para los usuarios que intentan conectarse Título del mensaje para los usuarios que intentan conectarse Núm. de inicios de sesión previos en la caché (en caso de que el controlador de dominio no esté disponible) 0 inicios de sesión Impedir el mantenimiento de la contraseña de la cuenta de equipo Deshabilitado Impedir que los usuarios controladores de impresora Habilitado instalen Pedir al usuario cambiar la contraseña antes de que caduque 14 días Consola de recuperación: permitir el inicio de sesión administrativo automático Deshabilitado Consola de recuperación: permitir la copia de disquetes y el acceso a todas las unidades y carpetas Deshabilitado 129 Cambiar el nombre de la cuenta de administrador No definido Cambiar el nombre de la cuenta de invitado No definido Restringir el acceso a la unidad de CD-ROM sólo al usuario con sesión iniciada localmente Habilitado Restringir el acceso a la unidad de disquete sólo al usuario con sesión iniciada localmente Habilitado Canal seguro: cifrar o firmar digitalmente datos de un canal seguro (siempre) Habilitado Canal seguro: cifrar digitalmente datos de un canal seguro (cuando sea posible) Habilitado Canal seguro: firmar digitalmente datos de un canal seguro (cuando sea posible) Habilitado Canal seguro: requerir clave de sesión protegida (Windows 2000 o posterior) Habilitado Partición segura del sistema (sólo para plataformas RISC) No definido Enviar contraseña no cifrada para conectar con servidores SMB de otros fabricantes Deshabilitado Apagar el sistema de inmediato si no puede registrar auditorías de seguridad Habilitado (vea la segunda nota) Comportamiento de extracción de tarjeta inteligente Bloquear estación de trabajo Reforzar los permisos predeterminados de los objetos globales del sistema (p.e. vínculos simbólicos) Habilitado Comportamiento de controlador no firmado No permitir la instalación instalación de Comportamiento de instalación de no controlador no firmado Avisar pero permitir la instalación Nota: La directiva de dominio predeterminada configura Cerrar automáticamente la sesión de los usuarios cuando termine el tiempo de sesión como deshabilitado. Para configurar esta opción, debe modificar la directiva de dominio predeterminada; por este motivo, no se define en las directivas de línea de base incluidas en este manual. 130 Nota: Si aumenta de manera importante el número de objetos para auditar, se corre el riesgo de que se llene el registro de seguridad y se fuerce el apagado del sistema. En este caso, no podrá usar el sistema hasta que un administrador borre el registro. Para evitar que esto ocurra, debe deshabilitar la opción de apagado del sistema que aparece en la tabla o bien, preferiblemente, aumentar el tamaño del registro de seguridad. Algunas de las opciones que se establecen aquí deben comentarse con más detalle, ya que afectan directamente a la manera en que los servidores se comunican entre sí en el dominio y también pueden afectar al rendimiento del servidor. Restricciones adicionales para conexiones anónimas De forma predeterminada, Windows 2000 permite que los usuarios anónimos realicen ciertas actividades, como enumerar los nombres de las cuentas de dominio y los recursos compartidos de la red. Esto permite que un atacante vea estas cuentas y comparta nombres en un servidor remoto sin tener que autenticarse con una cuenta de usuario. Para hacer más seguro el acceso anónimo, puede configurar No obtener acceso sin permisos anónimos explícitos. Esto hace que se elimine el grupo Todos del testigo de usuarios anónimos. No se permitirá el acceso anónimo al servidor y se necesitará un acceso explícito a todos los recursos. Nota: Para obtener más información acerca de cómo afectará esto a su entorno, consulte el artículo de Knowledge Base Q246261, "How to Use the RestrictAnonymous Registry Value in Windows 2000" (en inglés). Nivel de autenticación de LAN Manager Los sistemas operativos Microsoft Windows 9x y Windows NT® no pueden utilizar Kerberos para la autenticación y utilizan, de forma predeterminada, el protocolo NTLM para la autenticación de la red en un dominio Windows 2000. Puede utilizar un protocolo de autenticación más seguro para Windows 9x y Windows NT: NTLMv2. Para el proceso de inicio de sesión, NTLMv2 abre un canal seguro para proteger el proceso de autenticación. Nota: Si usa NTLMv2 para clientes y servidores heredados, los clientes y servidores basados en Windows 2000 seguirán autenticando con los controladores de dominio de Windows 2000 que utilizan Kerberos. Para obtener más información acerca de cómo habilitar NTLMv2, consulte el artículo de Knowledge Base Q239869, "How to Enable NTLM 2 Authentication for Windows 95/98/2000/NT" (en inglés). Windows NT 4.0 necesita el Service Pack 4 para ser compatible con NTLMv2 y las plataformas Windows 9x necesitan tener instalado el cliente del servicio de directorio para ser compatibles con NTLMv2. Borrar el archivo de páginas de la memoria virtual al apagar el sistema La información importante que se mantiene en la memoria real se puede volcar periódicamente al archivo de páginas. Esto ayuda a que Windows 2000 controle las funciones multitarea. Si habilita esta opción, Windows 2000 borra el archivo de páginas al apagar el sistema y quita toda la información almacenada en él. En función del tamaño del archivo, pueden pasar varios minutos antes de que se apague completamente el sistema. Firmar digitalmente la comunicación con el cliente o con el servidor La implementación de la firma digital en las redes de alta seguridad ayuda a evitar la suplantación de los clientes y servidores (lo que se conoce como secuestro de la sesión o ataque 131 de "alguien en medio"). La firma Bloque de mensaje de servidor (SMB) autentica tanto al usuario como al servidor que aloja los datos. Si la autenticación falla en cualquiera de los extremos, no se realiza la transmisión de datos. Cuando se implementa la firma SMB, se observa un exceso del rendimiento de hasta un 15% para firmar y verificar cada paquete entre los servidores. Para obtener más información acerca del efecto de exceso de rendimiento, consulte el artículo de Knowledge Base Q161372, "How to Enable SMB Signing in Windows NT" (en inglés). Otras opciones de seguridad Para este manual, se han agregado valores de registro adicionales al archivo de plantilla de seguridad de línea de base que no están definidos en el archivo de la plantilla administrativa (ADM). Esto significa que cuando se carga el complemento de las plantillas de seguridad MMC y se ve la plantilla baseline.inf, no se representan los valores del registro de las tablas 4.5 – 4.11. En su lugar, se puede agregar esta configuración al archivo .inf utilizando un editor de textos y se aplicará al servidor al descargar la directiva. Nota: para obtener más información acerca de la relación entre los archivos .inf y .adm, consulte el artículo de Knowledge Base Q228460, "Location of ADM (Administrative Template) Files in Windows" (en inglés). Esta configuración está incrustada en la plantilla de línea de seguridad Baseline.inf para automatizar los cambios. Si se quita la directiva, la configuración no se quita automáticamente y debe cambiarse de forma manual. Consideraciones de seguridad para los ataques a la red Algunos ataques de denegación de servicio pueden ser una amenaza para la pila de TCP/IP en los servidores basados en Windows 2000. Esta configuración del registro ayuda a aumentar la resistencia de la pila de TCP/IP de Windows 2000 a los ataques de denegación de servicio a la red de tipo estándar. Puede obtener información acerca de esta configuración en el artículo de Knowledge Base Q315669, "HOW TO: Harden the TCP/IP Stack in Windows 2000 Against Denial of Service" (en inglés). Se han agregado las siguientes claves de registro al archivo de plantilla como subclaves de HKLM\System\CurrentControlSet\Services\Tcpip|Parameters\: Tabla 4.5.: Parámetros de TCP/IP agregados al registro por la directiva de línea de base para los servidores miembros. Clave Formato Valor (decimal) EnableICMPRedirect DWORD 0 EnableSecurityFilters DWORD 1 SynAttackProtect DWORD 2 EnableDeadGWDetect DWORD 0 EnablePMTUDiscovery DWORD 0 KeepAliveTime DWORD 300.000 132 DisableIPSourceRouting DWORD 2 TcpMaxConnectResponseRetransmissions DWORD 2 TcpMaxDataRetransmissions DWORD 3 NoNameReleaseOnDemand DWORD 1 PerformRouterDiscovery DWORD 0 TCPMaxPortsExhausted DWORD 5 Afd.sys controla los intentos de conexión a las aplicaciones de Windows Sockets, como los servidores de FTP y de Web. Afd.sys se ha modificado para que admita un gran número de conexiones en estado semiabierto, sin denegar el acceso a los clientes legítimos. Esto se logra permitiendo que el administrador configure un registro dinámico. La nueva versión de Afd.sys admite cuatro nuevos parámetros del registro que se pueden usar para controlar el comportamiento del registro dinámico. Para obtener más información acerca de esta configuración, consulte el artículo de Knowledge Base Q142641, "Internet Server Unavailable Because of Malicious SYN Attacks" (en inglés). Se han agregado las siguientes claves de registro al archivo de plantilla como subclaves de HKLM\System\CurrentControlSet\Services\AFD\Parameters\: Tabla 4.6.: Configuración de Afd.sys agregada al registro por la directiva de línea de base para los servidores miembros. Clave Formato Valor (decimal) DynamicBacklogGrowthDelta DWORD 10 EnableDynamicBacklog DWORD 1 MinimumDynamicBacklog DWORD 20 MaximumDynamicBacklog DWORD 20000 Deshabilitar la generación automática de nombres de archivo 8.3 Windows 2000 admite los formatos de nombre de archivo 8.3 para compatibilidad con versiones anteriores de aplicaciones de 16 bits. Esto significa que un atacante sólo necesita 8 caracteres para hacer referencia a un archivo que puede tener 20 caracteres. Si no utiliza aplicaciones de 16 bits, puede desactivar esta función. Al deshabilitar la generación de nombres cortos en una partición NTFS también aumenta el rendimiento de enumeración del directorio. Se ha agregado la siguiente clave de registro al archivo de plantilla como subclave de HKLM\System\CurrentControlSet\Control\FileSystem\: Tabla 4.7.: Configuración para quitar la creación de nombres de archivo 8.3 agregada al registro por la directiva de línea de base para los servidores miembros. Clave Formato Valor (decimal) 133 NtfsDisable8dot3NameCreation DWORD 1 Nota: Si aplica esta configuración a un servidor existente que ya tenga archivos con nombres 8.3 generados automáticamente, estos archivos no se quitarán. Para quitar los nombres de archivo 8.3 existentes, deberá copiar esos archivos fuera del servidor, eliminarlos de su ubicación original y copiarlos de nuevo a sus ubicaciones originales. Deshabilitar la creación de Lmhash Los servidores basados en Windows 2000 pueden autenticar equipos que utilicen cualquier versión anterior de Windows. Sin embargo, las versiones anteriores de Windows no utilizan Kerberos para la autenticación; por lo tanto, Windows 2000 es compatible con Lan Manager (LM), Windows NT (NTLM) y NTLM versión 2 (NTLMv2). LM)hash es relativamente débil en comparación con el hash NTLM y, por tanto, es susceptible a los ataques rápidos mediante fuerza bruta. Si no tiene clientes que necesiten la autenticación LM, deshabilite el almacenamiento de hashes LM. Windows 2000 Service Pack 2 proporciona una configuración del registro para deshabilitar el almacenamiento de los hashes LM. Se ha agregado la siguiente clave de registro al archivo de plantilla como subclave de HKLM\SYSTEM\CurrentControlSet\Control\Lsa\: Tabla 4.8.: Configuración para deshabilitar la creación de Lmhash agregada al registro por la directiva de línea de base para los servidores miembros. Clave Formato Valor (decimal) NoLMHash DWORD 1 Nota: Para deshabilitar el almacenamiento de hashes LM con esta configuración del registro, debe estar ejecutando Windows 2000 Service Pack 2 o posterior. Para obtener más información, consulte el artículo de Microsoft Knowledge Base Q147706, "How to Disable LM Authentication on Windows NT" (en inglés). Configuración de la seguridad NTLMSSP El proveedor de servicios de seguridad NTLM (NTLMSSP) permite especificar la configuración de seguridad mínima necesaria para las conexiones de red del lado del servidor por aplicaciones. La directiva de línea de base para los servidores miembros garantiza que la conexión falle si se utiliza la confidencialidad de mensajes y no se negocia el cifrado de 128 bits. Se ha agregado la siguiente clave de registro al archivo de plantilla como subclave de HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\: Tabla 4.9.: Parámetro para configurar la seguridad NTLMSSP agregada al registro por la directiva de línea de base para los servidores miembros. Clave Formato Valor (hexadecimal) 134 NtlmMinServerSec DWORD 0x20000000 Deshabilitación de Autorun Autorun comienza a leer en una unidad en cuanto se inserta un medio en ella. Como resultado, el archivo de instalación de programas y el sonido de los medios de audio se inician inmediatamente. Para evitar que se inicie un posible programa malicioso al insertar un medio, la directiva de grupo deshabilita Autorun en todas las unidades. Se ha agregado la siguiente clave de registro al archivo de plantilla como subclave de HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\: Tabla 4.10.: Configuración para deshabilitar Autorun en todas las unidades, agregada al registro por la directiva de línea de base para los servidores miembros. Clave Formato Valor (hexadecimal) NoDriveTypeAutoRun DWORD 0xFF Directiva de línea de base de listas de control de acceso al registro para servidores miembros La directiva de línea de base para los servidores miembros no cambia las ACL del registro definidas en hisecws.inf. Debe realizar una comprobación cuidadosa en su entorno antes de realizar cambios. Las ACL definidas en hisecws.inf cambian principalmente el grupo Usuarios avanzados, que se crea de forma predeterminada para la compatibilidad con versiones anteriores de entornos basados en Windows NT 4.0. La plantilla garantiza que Usuarios avanzados tenga los mismos permisos que el grupo Usuarios de Windows 2000. Nota: El grupo Usuarios avanzados no está definido en los controladores de dominio. Directiva de línea de base de listas de control de acceso a archivos para servidores miembros Para aumentar la seguridad del sistema de archivos, debe asegurarse de que se apliquen permisos más restrictivos a los directorios y archivos comunes a todos los servidores miembros del dominio. La plantilla de seguridad de línea de base de los servidores miembros incorpora todas las listas de control de acceso a archivos incluidas con la plantilla hisecws.inf y agrega la configuración de varias carpetas y archivos. Nota: Para obtener más información acerca de los permisos predeterminados para el registro y los archivos en Windows 2000, consulte el documento "Default Access Control Settings in Windows 2000" (en inglés), disponible en TechNet. En el apartado "Más información", al final de este capítulo, encontrará el vínculo a estas notas del producto. La siguiente tabla muestra las otras carpetas aseguradas por la directiva de línea de base para los servidores miembros, además de las definidas por la configuración en hisecws.inf. Tabla 4.11.: Configuración para asegurar los directorios clave definidos en la directiva de línea de base para los servidores miembros. 135 Carpetas aseguradas Permisos aplicados %systemdrive%\ Administradores: Control total Sistema: Control total Usuarios autenticados: Leer y ejecutar, Listar el contenido de la carpeta y Leer %SystemRoot%\Repair Administradores: Control total %SystemRoot%\Security Creador/Propietario: Control total %SystemRoot%\Temp Sistema: Control total %SystemRoot%\system32\Config %SystemRoot%\system32\Logfiles %systemdrive%\Inetpub Administradores: Control total Sistema: Control total Todos: Leer y ejecutar, Listar el contenido de la carpeta y Leer Nota: %SystemRoot% define la ruta de acceso y el nombre de la carpeta en las que están ubicados los archivos del sistema de Windows y %SystemDrive% define la unidad que contiene %systemroot%. También hay un gran número de archivos instalados en el servidor que deben bloquearse aún con más detalle. La directiva de línea de base para los servidores miembros modificará las ACL de los archivos de inicio predeterminados de Windows y de muchos de los ejecutables que pueden ejecutarse desde el símbolo del sistema. Los archivos afectados se indican en el apéndice A. Directivas de línea de base de servicios para los servidores miembros Al instalar Windows 2000 Server por primera vez, se crean servicios predeterminados y se configuran para que se ejecuten al iniciar el sistema. Algunos de estos servicios no necesitan ejecutarse en distintos entornos y como todos los servicios son un posible punto de ataque, debe desactivar los que sean innecesarios. La directiva de línea de base para los servidores miembros sólo habilita los servicios necesarios para que un servidor miembro con Windows 2000 participe en un dominio de Windows 2000 y proporcione servicios de administración básicos. Tabla 4.12.: Servicios habilitados por la directiva de línea de base para los servidores miembros. Servicio Tipo inicio Servicios de sucesos COM+ Manual de Motivo para incluirlo en la línea de base del servidor miembro Permite la administración de los servicios de 136 componentes Cliente DHCP Automático Se necesita para actualizar los registros del DNS dinámico Cliente de seguimiento de vínculos distribuidos Automático Se utiliza para mantener los vínculos en los volúmenes NTFS Cliente DNS Automático Permite la resolución de los nombres del DNS Registro de sucesos Automático Permite ver los mensajes del registro de sucesos en el Registro de sucesos Automático Se necesita para garantizar que la información dinámica del disco esté actualizada Servicio del administrador de discos lógicos Manual Se necesita para la administración de discos Netlogon Automático Se necesita para la participación de los dominios Conexiones de red Manual Se necesita para la comunicación en la red Manual Recoge los datos de rendimiento del equipo y los anota en el registro o dispara alertas. Plug and Play Automático Se necesita para que Windows 2000 identifique y use el hardware del sistema Almacenamiento protegido Automático Se necesita para proteger los datos confidenciales, como las claves privadas. Llamada a procedimiento remoto (RPC) Automático Se necesita para los procesos internos en Windows 2000 Servicio de registro remoto Automático Es necesario para la utilidad hfnetchk (consulte la nota) Administrador de cuentas de seguridad Automático Almacena información de las cuentas de seguridad locales Servidor Automático Es necesario para la utilidad hfnetchk (consulte la nota) Notificación de sucesos del sistema Automático Se necesita para registrar las entradas en los registros de sucesos Servicio de ayuda TCP/IP NetBIOS Automático Se necesita para la distribución de software en la directiva de grupo (se puede usar para distribuir revisiones) Controlador instrumental de administración de Windows Manual Se necesita para implementar las alertas de rendimiento utilizando los registros y las alertas de Administrador lógicos Registros y rendimiento de discos alertas de 137 rendimiento Sincronización de tiempo de Windows Automático Se necesita para que la autenticación Kerberos funcione de manera coherente Estación de trabajo Automático Se necesita para participar en un dominio Nota: Hfnetchk es una herramienta que permite comprobar las revisiones instaladas en cada servidor de la organización. El uso de esta herramienta se recomienda en el capítulo 5 "Administrar revisiones". Esta configuración supone un entorno basado en Windows 2000 puro y estándar (con excepción de la herramienta hfnetchk). Si el entorno incluye Windows NT 4.0 (o tiene otras herramientas en todos los servidores miembros) es posible que necesite otros servicios para mantener la compatibilidad. Si habilita otros servicios, estos pueden tener, a su vez, dependencias que hagan necesarios servicios adicionales. Los servicios que se necesitan para una función de servidor específica se pueden agregar a la directiva para esa función de servidor. En el apéndice B se muestran todos los servicios presentes en una instalación predeterminada de Windows 2000 y en el apéndice C, los servicios adicionales que se pueden agregar a una instalación predeterminada. Servicios clave no incluidos en la línea de base de los servidores miembros El objetivo de la directiva de línea de base para los servidores miembros es ser lo más restrictiva posible. Por este motivo, varios servicios que pueden ser necesarios en su entorno están deshabilitados. Aquí se describen algunos de los más comunes. Servicio SNMP En muchos casos, las aplicaciones de administración necesitan que se instale un agente en cada servidor. Generalmente, estos agentes usan SNMP para reenviar las alertas de vuelta a un servidor de administración centralizado. Si necesita agentes de administración, debe comprobar si necesitan que se inicie el servicio SNMP. Servicios WMI El servicio Instrumental de Administración de Windows (WMI) está deshabilitado en la directiva de línea de base para los servidores miembros. Para administrar discos lógicos a través de la administración de equipos, es necesario habilitar el servicio WMI. Muchas otras aplicaciones y herramientas también utilizan WMI. Servicios de mensajería y de alertas Aunque no dependen explícitamente uno del otro, estos servicios funcionan conjuntamente para enviar alertas administrativas. El servicio de mensajería envía las alertas disparadas por el servicio de alertas. Si utiliza Registros y alertas de rendimiento para disparar las alertas, necesitará habilitar estos servicios. 138 Directiva de línea de base para el controlador de dominio Todos los controladores de dominio creados en el dominio se asignan automáticamente a la OU de controladores de dominio. Los controladores de dominio nunca deben moverse fuera de esta OU, ya que en ella se aplican ACL de seguridad específicas. La OU de controladores de dominio es una OU de nivel superior y, por tanto, no aplica la configuración definida en la directiva de línea de base para los servidores miembros. Por este motivo, se ha creado una directiva de línea de base distinta para los controladores de dominio. La configuración implementada en la directiva de línea de base para los controladores de dominio afecta a los apartados siguientes de la directiva: Directiva de auditor ía. Opciones de seguridad. Configuraci ón de servicios. Nota: Las ACL de archivos, con excepción de los archivos System32 indicados en el apéndice A, y las ACL del registro no se incluyen en esta directiva de grupo, ya que se definen y se implementan cuando el servidor que ejecuta Windows 2000 se promueve a un controlador de dominio. Durante la promoción de un servidor basado en Windows 2000 a un controlador de dominio, se aplica una plantilla de seguridad llamada Defltdc.inf. Esta plantilla aplica ACL al sistema de archivos y a las claves del registro para los servicios adicionales creados con el fin de proporcionar compatibilidad con un controlador de dominio. Directiva de línea de base para las opciones de auditoría y seguridad del controlador de dominio Las directivas de auditoría y las opciones de seguridad configuradas para los controladores de dominio son idénticas a la directiva de línea de base (consulte los detalles de la configuración en el apartado "Directivas de línea de base para los servidores miembros"). Directiva de línea de base de servicios para el controlador de dominio Los servicios configurados para el inicio son los que se definen en la configuración de línea de base del servidor miembro, más los servicios adicionales necesarios para la compatibilidad con las funciones del controlador de dominio. Tabla 4.13.: Servicios habilitados por la directiva de línea de base de servicios para el controlador de dominio, además de los establecidos por la directiva de línea de base para los servidores miembros. Servicio Sistema de distribuido Servidor DNS archivos Tipo de inicio Motivo para incluirlo en la línea de base del controlador de dominio Automático Se necesita para los recursos compartidos Sysvol de Active Directory Automático Se necesita para el DNS integrado de Active 139 Directory Réplica de archivos Automático Se necesita para la replicación de archivos entre los controladores de dominio Centro de distribución de claves Kerberos Automático Permite a los usuarios iniciar una sesión en la red mediante Kerberos v5 Proveedor de servicios de seguridad NTLM Automático Permite que los clientes inicien una sesión utilizando la autenticación NTLM Localizador de RPC Automático Permite al controlador de dominio proporcionar el servicio de nombres RPC Servicios clave no incluidos en la directiva de línea de base para los controladores de dominio El objetivo de la directiva de línea de base para los controladores de dominio es ser lo más restrictiva posible. Por este motivo, varios servicios que pueden ser necesarios en su entorno están deshabilitados. Aquí se describen algunos de los más comunes que puede necesitar. Serv. de Prot. simple de transf. de correo (STMP) La replicación entre sitios se puede realizar utilizando RPC o SMTP. Si utiliza SMTP para la replicación en su entorno, necesitará activar el servicio SMTP. Mensajería entre sitios Este servicio se utiliza para la replicación entre sitios a través del correo. Cada transporte que se va a utilizar para la replicación se define en una biblioteca de vínculos dinámicos (DLL) complementaria distinta. Estas DLL complementarias se cargan en el servicio de mensajería entre sitios. La mensajería entre sitios dirige las solicitudes enviadas y recibidas a las DLL complementarias de transporte apropiadas que, a su vez, enrutan los mensajes a la mensajería entre sitios del equipo de destino. Si utiliza SMTP para la replicación en su entorno, necesitará activar este servicio. Servicio de administración de IIS Si inicia el servicio SMTP, también deberá iniciar el servicio de administración de IIS, ya que el servicio SMTP depende de él. Servicio de servidor de seguimiento de vínculos distribuidos Este servicio se utiliza para realizar un seguimiento de los archivos en volúmenes NTFS en un dominio completo y se contacta por medio de equipos que ejecutan el servicio de cliente de seguimiento de vínculos distribuidos. Estos equipos intentarán periódicamente establecer contacto con el servicio de servidor de seguimiento de vínculos distribuidos, aunque esté deshabilitado. Nota: Si ejecuta la utilidad dcdiag desde las Herramientas de soporte de Windows 2000, se comprobarán todos los servicios que se ejecutan normalmente en los controladores de dominio que se van a iniciar. Como algunos servicios están deshabilitados en la directiva de línea de base para los controladores de dominio, dcdiag comunicará errores. Es normal que esto ocurra y no indica ningún problema con la configuración. 140 Otras tareas de seguridad de línea de base No es posible realizar todas las tareas necesarias para aumentar la seguridad de los servidores miembros y los controladores de dominio que utilizan la directiva de grupo. Hay varios pasos más que debe seguir para aumentar el nivel de seguridad global en todos los servidores. Seguridad de las cuentas integradas Windows 2000 tiene varias cuentas de usuario integradas que no se pueden eliminar pero se les puede cambiar el nombre. Dos de las cuentas integradas más conocidas de Windows 2000 son Invitado y Administrador. De forma predeterminada, la cuenta Invitado está deshabilitada en los servidores miembros y los controladores de dominio. No debe cambiar esta configuración. Para evitar ataques que utilicen un nombre conocido y pongan en peligro al servidor remoto, debe cambiar el nombre de la cuenta Administrador integrada y modificar su descripción. Muchas secuencias de comandos maliciosas utilizan la cuenta de administrador integrada como un primer intento para atacar el servidor. Nota: El nombre de la cuenta de administrador integrada se puede cambiar utilizando la directiva de grupo. No hemos implementado esta configuración en las directivas de línea de base porque debe elegir un nombre que no sea conocido. Seguridad de la cuenta de administrador local Cada servidor miembro tiene una base de datos de cuentas locales y una cuenta de administrador local que proporciona control total sobre el servidor. Por lo tanto, esta cuenta es muy importante. Debe cambiar el nombre de la misma y asegurarse de que tenga una contraseña compleja. También debe asegurarse de que las contraseñas del administrador local no se repliquen en los servidores miembros. Si fuera así, un atacante que obtuviera acceso a un servidor miembro podría obtener acceso a todos los demás con la misma contraseña. No debe hacer que las cuentas de administrador locales formen parte del grupo de administradores de dominio, ya que esto amplía sus capacidades más de lo necesario para administrar los servidores miembros. Por el mismo motivo, es importante asegurarse de que sólo se utilicen las cuentas locales para administrar los servidores miembros. Seguridad de las cuentas de servicio Los servicios de Windows 2000 se ejecutan generalmente en la cuenta del sistema local, aunque también se pueden ejecutar bajo un usuario de dominio o en una cuenta local. Siempre que sea posible, debe usar cuentas locales en lugar de las cuentas de usuario de dominio. Un servicio se ejecuta en el contexto de seguridad de su cuenta de servicio, por lo que si un ataque pone en peligro un servicio en un servidor miembro, la cuenta de servicio podría utilizarse para atacar un controlador de dominio. Al determinar qué cuenta se utilizará como cuenta de servicio, debe asegurarse de que los privilegios asignados se limiten a los necesarios para el correcto funcionamiento del servicio. En la tabla siguiente se explican los privilegios inherentes a cada tipo de cuenta de servicio. Tabla 4.14.: Privilegios de las cuentas de Windows 2000 en diferentes entornos. Autenticación cuando se ejecutan servicios en equipos basados en Windows 2000 Dentro del bosque únicamente, todos los servidores basados en Windows 2000 Aplicación con varios bosques y confianza NTLM entre dominios 141 Cuenta de servicio usuario local de Sin recursos de la red, acceso local sólo con privilegios de la cuenta asignados Sin recursos de la red, acceso local sólo con privilegios de la cuenta asignados Cuenta de servicio usuario de dominio de Acceso a la red como usuario del dominio, acceso local con privilegios de usuario Acceso a la red como usuario del dominio, acceso local con privilegios de usuario Acceso a la red como usuario autenticado en la cuenta de la máquina, acceso local con LocalSystem No hay recursos de la red que se extiendan a los bosques, acceso local con LocalSystem LocalSystem Todos los servicios predeterminados de Windows 2000 se ejecutan en LocalSystem y no esto no debe cambiarse. Todos los servicios adicionales agregados al sistema que requieran el uso de cuentas de dominio deben evaluarse con cuidado antes de implementarse. Validación de la configuración de línea de base Una vez aplicada la seguridad por primera vez a un servidor, es conveniente comprobar que los parámetros específicos de seguridad están configurados correctamente. Microsoft Security Baseline Analyzer Tool realizará una serie de comprobaciones en los servidores y le avisará de los problemas de seguridad con los que se puede encontrar. Validación de la configuración de puertos Es importante que valide la configuración final de los puertos y que comprenda a qué puertos TCP y UDP "escuchan" los servidores que ejecutan Windows 2000. Después de aplicar las directivas de línea de base, se puede ejecutar el comando netstat para ver a qué puertos sigue escuchando el servidor para cada tarjeta de interfaz de red. La tabla muestra el resultado esperado de netstat para un servidor miembro con la directiva de línea de base para los servidores miembros aplicada: Tabla 4.15.: Puertos a los que escuchará un servidor miembro después de aplicar la directiva de línea de base para los servidores miembros. Protocolo Dirección local Dirección externa Estado TCP 0.0.0.0:135 0.0.0.0:0 ESCUCHANDO TCP 0.0.0.0:445 0.0.0.0:0 ESCUCHANDO TCP <Dirección IP>:139 0.0.0.0:0 ESCUCHANDO UDP <Dirección IP>:137 *.* N/A UDP <Dirección IP>:138 *.* N/A UDP 0.0.0.0:445 *.* N/A 142 UDP 0.0.0.0:1027 *.* N/A UDP 0.0.0.0:1045 *.* N/A Seguridad de cada función del servidor Una vez aplicadas las directivas de línea de base, los servidores estarán notablemente más seguros. En este estado, puede que deba habilitar parámetros adicionales agregando funcionalidad a la línea de base. En este manual, se definen cuatro funciones distintas de los servidores miembros: Servidor de aplicaciones con Windows 2000. Ésta es la más segura y la más restringida de las funciones de servidor. El objetivo de esta función segura de servidor de aplicaciones es proporcionar un servidor sumamente restringido en el que puede instalar una aplicación, como Exchange o SQL. Esta función de servidor está diseñada de manera que lo único que puede hacer es comunicarse con los controladores de dominio para la autenticación. Esta función es la base de las demás funciones. Servidor de archivos y de impresión con Windows 2000. Diseñado para aumentar notablemente la seguridad de los servidores de archivos y de impresión. Servidor de infraestructura con Windows 2000. Diseñado para aumentar notablemente la seguridad de los servidores DNS, DHCP y WINS. Servidor de IIS con Windows 2000. Diseñado para aumentar notablemente la seguridad de los servidores de IIS. Esta función usa una versión modificada de la directiva para servidores de aplicaciones y las herramientas IIS Lockdown y URLScan. Nota: La función de servidor de aplicaciones está deliberadamente muy restringida. Para poder instalar y ejecutar determinadas aplicaciones, es posible que tenga que modificar la configuración de seguridad que se define aquí. Nota: Se pueden modificar las plantillas incluidas en este manual para crear plantillas para otras funciones. Si hace esto, es importante que compruebe completamente la plantilla modificada para asegurarse de que proporciona el nivel de seguridad deseado. Función de servidor de aplicaciones con Windows 2000 La configuración de la función de servidor de aplicaciones depende de la aplicación que desee implementar. Por este motivo, la configuración es igual a la de la línea de base de los servidores miembros. Esto significa que la función de servidor de aplicaciones está muy restringida; para instalar y ejecutar ciertas aplicaciones, tendrá que modificar la configuración de seguridad predeterminada que se define aquí. La forma más fácil de hacerlo es crear una nueva OU para la aplicación en la OU de servidores de aplicación. Después, se crea una directiva de grupo que modifique la configuración de la línea de base y se importa la directiva a la nueva OU. Función de servidor de archivos y de impresión con Windows 2000 Generalmente, todos los usuarios de un entorno corporativo obtienen acceso a los servicios de archivo y de impresión, por lo que puede resultar difícil garantizar la máxima seguridad para esta función de servidor. La directiva para servidores de archivos y de impresión: Habilita el servicio de cola de impresi ón, que se utiliza para imprimir. 143 Deshabilita la configuraci ón de directivas de seguridad Firmar digitalmente la comunicación con el cliente (siempre). Si no está deshabilitada, los clientes pueden imprimir, pero no pueden ver la cola de impresión. Cuando intenten ver la cola de impresión, recibirán el mensaje "No se puede conectar. Acceso denegado." Nota: El servicio de cola de impresión se utiliza en todos los equipos que inician un trabajo de impresión y en los servidores de impresión. La configuración predeterminada para las líneas de base de los servidores miembros y de los controladores de dominio impide emitir trabajos de impresión desde estos equipos. Función de servidor de infraestructuras con Windows 2000 La función de servidor de infraestructuras es compatible con los servicios de red DNS, DHCP y WINS. Para que los tres servicios se ejecuten en el mismo servidor miembro, la directiva de infraestructuras habilita los servicios siguientes, además de la directiva de línea de base para los servidores miembros. Tabla 4.16.: Servicios agregados por la directiva para la función de servidor de infraestructuras. Servicio Tipo de inicio Motivo para incluirlo en la directiva para la función de servidor de infraestructuras DHCPServer Automático Para proporcionar DHCP a los clientes DNS Automático Para proporcionar servicios de DNS a los clientes NTLMSSP Automático Para proporcionar seguridad a los programas RPC que utilizan medios de transporte que no sean canalizaciones con nombre WINS Automático Para proporcionar WINS a los clientes servicios servicios Función de servidor IIS con Windows 2000 La función de servidor IIS proporciona funcionalidad de servidor Web a un servidor basado en Windows 2000. La directiva de grupo para la función de servidor IIS agrega los servicios siguientes a la directiva de línea de base para los servidores miembros. Tabla 4.16.: Servicios agregados por la directiva para la función de servidor IIS. Servicio Tipo de inicio Motivo para incluirlo en la directiva para la función de servidor IIS IISAdmin Automático Administración del servidor Web W3SVC Automático Proporciona funcionalidad 144 de de de servidor Web Además, la directiva de grupo para la función de servidor IIS configura el valor del registro SynAttackProtect en 1. La herramienta IISLockdown Los servidores IIS proporcionan un gran número de funciones. Sin embargo, para que los servidores IIS sean lo más seguros posible, debe restringir esta funcionalidad a lo estrictamente necesario. La forma más sencilla de hacerlo es utilizando la herramienta IISLockdown. IISLockdown es una utilidad que se puede configurar en gran medida y permite especificar la naturaleza del servidor Web. Después, quita todas las funciones que ese servidor Web específico no necesita. Por supuesto, es necesario comprobar exhaustivamente todos los cambios antes de implementarlos en un entorno de producción. Nota: IISLockdown está disponible como parte del Kit de herramientas del programa de seguridad de Microsoft y en el sitio Web de seguridad de Microsoft. Para obtener información más detallada, consulte el apartado "Más información", al final de este capítulo. IISLockdown puede aplicar muchas medidas para hacer más seguros los servidores Web. Puede, por ejemplo: Bloquear archivos. Deshabilitar servicios y componentes. Instalar URLScan. Quitar las asignaciones de secuencias de comandos DLL ISAPI (Internet Server API) innecesarias. Quitar los directorios innecesarios. Cambiar las ACL. Puede usar IIS Lockdown para asegurar muchos tipos de funciones de servidor IIS. Para cada servidor, debe seleccionar la función más restrictiva que satisfaga las necesidades de su servidor Web. Para asegurar un servidor Web estático con IIS Lockdown 1. Inicie IISLockd.exe. 2. Haga clic en Next. 3. Seleccione I Agree y haga clic en Next. 4. Seleccione Static Web server y haga clic en Next. 5. Asegúrese de que Install URLScan filter on the server está seleccionado y haga clic en Next. 6. Haga clic en Next. 145 7. Si aparece el cuadro de diálogo Digital Signature Not Found, haga clic en Yes. 8. Haga clic en Next. 9. Haga clic en Finish. Si configura un servidor IIS como servidor Web estático, se realizarán los siguientes cambios: Se deshabilita la asignaci ón de las secuencias de comandos de la interfaz Web de Index Server (.idq, .htw, .ida). Se deshabilita la asignaci ón de las secuencias de comandos de Internet Data Connector (.idc). Se deshabilita la asignaci ón de secuencia de comandos de los archivos de inclusión del servidor (.shtml, .shtm, .stm). Se deshabilita la asignaci ón de la secuencia de comandos .HTR(.htr)'. Se deshabilita la asignaci ón de las secuencias de comandos de páginas de Active Server (.asp). Se deshabilita la asignaci ón de las secuencias de comandos de impresión de Internet (.printer). Se quita el directorio virtual de la impresora. Se deshabilita WebDAV (Creaci ón y control de versiones distribuidos en Web). Se establecen permisos de archivos para evitar que los usuarios an ónimos de IIS escriban en los directorios de contenido. Se establecen permisos de archivos para evitar que los usuarios an ónimos de IIS ejecuten utilidades del sistema. Se instala el filtro URLScan en el servidor. Se quita el directorio virtual Secuencias de comandos. Se quita el directorio virtual MSADC. Se quita el directorio virtual IIS Samples. Se quita el directorio virtual IISAdmin. Se quita el directorio virtual IISHelp. Nota: En el capítulo 6, "Auditoría y detección de intrusiones", encontrará más información acerca de URLScan. 146 Otros parámetros de seguridad de la función de servidor IIS La herramienta IIS Lockdown aumenta notablemente la seguridad de los servidores IIS. Sin embargo, hay otras medidas que se pueden tomar para aumentar aún más la seguridad de los servidores que ejecutan el servicio de IIS de Windows 2000. Configuración de restricciones para las direcciones IP y DNS Esta configuración garantiza que sólo los sistemas con direcciones IP o nombres de DNS específicos puedan tener acceso al servidor Web. No es habitual establecer restricciones a las direcciones IP y DNS, pero es una opción disponible para restringir los sitios Web a determinados usuarios. Sin embargo, si se utilizan nombres DNS en lugar de direcciones IP en las restricciones, IIS deberá realizar una búsqueda de DNS, lo que puede tardar algún tiempo. Uso de una cuenta anónima local De forma predeterminada, la cuenta anónima que se usa para tener acceso a IIS es una cuenta de dominio llamada IUSR_nombreequipo. Para más seguridad, puede deshabilitar la cuenta predeterminada y sustituirla por una cuenta local, que cumpla directivas de contraseña estrictas. De esta manera, si un atacante obtiene acceso a la cuenta, sólo tendrá acceso al sistema local. Es importante comprobar exhaustivamente todos los servidores IIS configurados de esta manera, ya que algunas aplicaciones Web necesitan una cuenta de dominio en lugar de una cuenta local). Nota: Puede eliminar la cuenta IUSR_nombreequipo; sin embargo, si sólo la desactiva, puede dejarla como una cuenta de señuelo. Implementación de filtros IPSec para servidores host múltiples El motor de directivas IPSec incluido con Windows 2000 es una herramienta útil para aumentar la seguridad global de la arquitectura de Web, en especial la seguridad de los servidores Web. La directiva IPSec se utiliza generalmente para crear una vía de comunicación segura entre dos hosts o dos sitios remotos. Sin embargo, también se pueden aprovechar sus capacidades de filtrado de puertos y protocolos. Puede usar las listas de filtros en combinación con acciones de filtrado para controlar el tráfico de entrada y salida en el servidor Web. Por ejemplo, puede crear listas con dos filtros, uno para el tráfico de todos los destinos que llegue al puerto 80 y otro para el tráfico de todos los destinos que llegue a cualquier puerto. Después, puede definir acciones de filtrado para permitir el paso del tráfico que cumpla las condiciones de la primera lista de filtrado y bloquear el tráfico que cumpla con la segunda lista de filtrado. Las directivas IPSec se implementan a través de las directivas de grupo. No están incluidas entre las directivas que se describen en este manual, ya que se implementan de diferente manera en función de las características específicas del entorno. Cambios al entorno recomendado El objetivo de las recomendaciones incluidas en este capítulo es crear un entorno notablemente más seguro para los servidores basados en Windows 2000. Sin embargo, es posible que algunos de estos cambios no sean apropiados para su organización. Vamos a plantear dos situaciones: 1) se necesita más capacidad administrativa y 2) no se usa la utilidad Hfnetchk. 147 Cambios administrativos Las directivas de línea de base predeterminadas para los servidores miembros y los controladores de dominio eliminan parte de la funcionalidad de administración remota y local del entorno. La administración remota a través del complemento de administración de equipos Microsoft Management Console (MMC) no funciona con las directivas de línea de base predeterminadas, ya que algunos de los servicios relacionados con MMC están deshabilitados. Las directivas de línea de base habilitan los servicios de servidor y de registro remoto. Esto permite que el complemento de administración de equipos se conecte desde una ubicación remota a otros equipos y administre los siguientes elementos: Carpetas compartidas. Usuarios y grupos locales. En Administraci ón de almacenamiento, todo excepto las unidades lógicas y los medios de almacenamiento extraíbles. Administrador de dispositivos de servicios. Visor de sucesos. Registros y alertas de rendimiento. WMI no está habilitado en las directivas de línea de base. Esto impide que se administren los siguientes elementos: WMI. En Administraci ón de Almacenamiento, las unidades lógicas. Si necesita administrar estas unidades de forma local o remota, debe habilitar el servicio WMI. No se puede tener acceso remoto a los medios de almacenamiento extraíbles si sólo se inician los servicios de la directiva de línea de base para los servidores miembros. Si no se inicia el servicio de medios de almacenamiento extraíbles en el servidor remoto, éste generará un mensaje de error DCOM en el registro de sucesos, para indicar que el servicio no está disponible. Nota: Al habilitar los servicios anteriores para permitir la administración, habilítelos únicamente en las directivas de función de servidor incremental que necesitan esos servicios. Nota: Algunas herramientas de administración obligan a realizar cambios de seguridad en el cliente desde el que se ejecuta la herramienta. Por ejemplo, algunas herramientas utilizan la autenticación NTLM y la directiva de línea de base configura los servidores para que acepten únicamente NTLM v2. Consulte la información sobre esta configuración en el apartado "Nivel de autenticación de LAN Manager" de este capítulo. Modificaciones de la seguridad si no se implementa HFNETCHK Hfnetchk es una herramienta que permite comprobar las revisiones instaladas en cada servidor de la organización. Es muy conveniente que se instale una herramienta como Hfnetchk, ya que ayuda a aumentar el nivel global de seguridad en el entorno. 148 Sin embargo, si no implementa Hfnetchk, puede deshabilitar los servicios de registro remoto y de servidor en la directiva de línea de base para los servidores miembros. El servicio de registro remoto se puede deshabilitar en la directiva de línea de base para los controladores de dominio. Si deshabilita estos servicios en la directiva de línea de base para los servidores miembros, necesitará habilitarlos en algunas de las funciones de servidor: Tabla 4.17.: Servicios que deben agregarse a los GPO de función de servidor si los servicios de registro remoto y de servidor están deshabilitados en la directiva de línea de base para los servidores miembros. Función del servidor Servicio que habilitar se debe Motivo Servidor de archivos y de impresión Servidor Para poder archivos Servidor de infraestructuras Servidor Para que WINS pueda funcionar correctamente Servidor de infraestructuras Registro remoto Para que el administrador de WINS pueda ver el estado del servidor WINS compartir Si deshabilita los servicios de servidor y de registro remoto, también perderá casi todas las capacidades de administración remota. Resumen Los servidores basados en Windows 2000 proporcionan un gran número de funciones desde el momento en que se instalan. Sin embargo, no todos los servidores necesitan todas estas funciones. Al definir las tareas que realizarán los servidores, puede deshabilitar los elementos innecesarios y aumentar de esta forma la seguridad en el entorno. Si sigue los pasos sugeridos en este capítulo, hará que su entorno sea mucho más seguro. Más información Información acerca de la seguridad de la pila TCP/IP de Windows 2000: http://www.microsoft.com/technet/security/website/dosrv.asp (en inglés). Configuración de control de acceso predeterminada en las notas del producto de Windows 2000: http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/secdefs. asp (en inglés). Kit de herramientas del programa de seguridad de Microsoft. http://www.microsoft.com/security/mstpp.asp (en inglés). Glosario de servicios de Windows 2000: 149 http://www.microsoft.com/windows2000/techinfo/howitworks/management/w2kservices.asp (en inglés). 5. Administrar revisiones Los sistemas operativos y las aplicaciones pueden ser muy complejos. Están formados por millones de líneas de código y son obra de muchos programadores diferentes. Es fundamental que el software funcione de manera confiable y no ponga en peligro la seguridad ni la estabilidad del entorno de TI. Para reducir al mínimo los problemas, los programas se comprueban exhaustivamente antes de salir al mercado. Sin embargo, es imposible prever todos los ataques que pueden ocurrir en el futuro y siempre hay personas dedicadas a buscar las debilidades del software. Las compañías de software producen revisiones para resolver las debilidades del código o de la implementación que se descubren después de comercializar el producto. Cada vez más, estos problemas están relacionados con la seguridad, a medida que el número de atacantes aumenta, sus métodos se vuelven más sofisticados y se crea nuevo código malicioso para aprovechar los puntos vulnerables. No obstante, también puede haber revisiones diseñadas simplemente para agregar funcionalidad al producto. Las revisiones de seguridad suponen un reto específico para la mayoría de las organizaciones. Una vez se han detectado las debilidades del software, los atacantes generalmente difunden esta información rápidamente a toda la comunicad. Las compañías de software intentan producir una revisión de seguridad lo antes posible. Hasta que no se implemente la revisión, la seguridad que espera tener y de la que depende puede verse reducida notablemente. No importa si su organización tiene miles de equipos o sólo unos cuantos; la administración de todas las revisiones disponibles, el análisis de su relevancia para cada entorno y la evaluación de la cantidad de pruebas que puede realizar la organización antes de implementarlas pueden ser tareas difíciles, que llevan mucho tiempo. Este capítulo está diseñado para ayudarle a mantener la seguridad de los servidores basados en Windows 2000, pero los procesos que se describen aquí también pueden aplicarse a los procesos de administración de revisiones para todas las actualizaciones de software. Para obtener información acerca de cómo se actualiza un software específico, debe ponerse en contacto con el fabricante correspondiente. Terminología En este manual, se usan indistintamente los términos revisión y Service Pack para referirse a los cambios al software después de su comercialización. Esto se debe a que el proceso para implementarlos es igual en todos los casos. Sin embargo, existe una definición más específica de cada uno de estos términos: Service Packs Los Service Packs mantienen el producto actualizado, corrigen los problemas conocidos y también pueden ampliar la funcionalidad del equipo. Incluyen herramientas, controladores y actualizaciones, así como mejoras desarrolladas después de la comercialización del producto. Todo esto se agrupa en un solo paquete que puede descargarse fácilmente. Los Service Packs son específicos para cada producto y por lo tanto, existen distintos Service Packs para los diferentes productos. No obstante, generalmente se usa el mismo para distintas 150 versiones del mismo producto. Por ejemplo, se utiliza el mismo Service Pack para actualizar Windows 2000 Server y Windows 2000 Professional. También son acumulativos; cada Service Pack nuevo contiene todas las reparaciones incluidas en los anteriores, además de las nuevas reparaciones y modificaciones del sistema recomendadas desde el último. No necesita instalar el Service Pack anterior antes de instalar el más reciente. Revisiones o QFE La Ingeniería de corrección rápida (QFE) es un grupo interno de Microsoft que crea revisiones (hotfix), es decir, revisiones de código para los productos. Estas revisiones se envían a clientes específicos que experimentan problemas críticos para los que no existe una solución factible. En ocasiones, en la documentación técnica se hace referencia a las revisiones como QFE. Las revisiones no se someten a pruebas regresivas exhaustivas y son específicas para cada problema; sólo deben aplicarse si se experimenta el problema exacto que abordan y si está utilizando la versión del software actualizada con el Service Pack más reciente. Periódicamente, se incorporan grupos de revisiones a los Service Packs, se someten a comprobaciones más rigurosas y se ponen a disposición de todos los clientes. Revisiones de seguridad Las revisiones de seguridad están diseñadas para eliminar las vulnerabilidades de la seguridad. Los atacantes que desean entrar en un sistema pueden aprovechar estas vulnerabilidades. Las revisiones de seguridad son análogas a las revisiones (hotfix), pero se consideran obligatorias si las circunstancias lo justifican y deben implementarse rápidamente. Muchas de las actualizaciones que se generan son para resolver problemas del cliente (con frecuencia, relacionados con el explorador). Estos problemas pueden ser o no relevantes para una instalación de servidor concreta. Es necesario obtener la revisión del cliente para actualizar la base de clientes actual y la revisión de administración para actualizar el área de creación de clientes del servidor. Administración de revisiones de la organización La manera exacta de implementar la administración de revisiones depende en gran medida del tamaño y de la complejidad de la organización. Sin embargo, es esencial que comprenda la importancia de la administración de las revisiones y cómo ésta se integra en la estrategia global de administración de riesgos de la organización. Por ejemplo, si decide que es necesario reducir el riesgo al mínimo, cueste lo que cueste, la estrategia que debe seguir consiste en apagar todos los sistemas de producción cada vez que se detecte una nueva vulnerabilidad en el software. Puede elegir no volver a iniciar los sistemas hasta que se haya realizado una comprobación exhaustiva de la revisión de seguridad y se haya instalado en toda la organización. Este proceso es sumamente costoso en términos económicos y de tiempo, y resulta imposible de aplicar para muchas organizaciones. Durante todo el proceso de administración de revisiones, es necesario evaluar los riesgos en relación con los costos de aplicar las soluciones apropiadas. Una vez se ha detectado una vulnerabilidad en la seguridad, puede pasar cierto tiempo hasta que aparezca una revisión con la solución. Necesitará evaluar el aumento del riesgo ocasionado por la vulnerabilidad y determinar las medidas que es necesario tomar antes de comprobar e instalar una revisión. Estas medidas incluyen deshabilitar servicios, desconectar sistemas o restringir el acceso a los usuarios internos o a otros grupos, según sea necesario. Una vez está disponible la revisión, es necesario 151 determinar el riesgo de implementarla inmediatamente, teniendo en cuenta los costos de mantener los servidores inactivos o desprotegidos durante el corto tiempo necesario para probar la revisión y asegurarse de que no afecta negativamente al sistema. Si decide realizar pruebas, deberá determinar hasta qué punto son necesarias en función del riesgo de implementar o no la revisión. Nota: La organización debe instaurar un proceso de administración de cambios. MOF incluye un proceso de administración de cambios que puede utilizarse como base del proceso de organización. Consulte el vínculo a MOF en el apartado "Más información", al final de este capítulo. Evaluación del entorno actual Con frecuencia, las revisiones se instalan de forma poco coherente en una organización, sin que exista documentación que recoja por qué, cuándo y dónde se instalaron. Para poder administrar correctamente la seguridad del entorno, es necesario conocer con detalle su estado actual. Para la administración de las revisiones, se debe saber, por lo menos: Qu é sistemas hay en el entorno: El sistema operativo y su versi ón. El nivel de revisi ón (versión del Service Pack, las revisiones (hotfix) y otras modificaciones). Funci ón. Aplicaciones. Informaci ón de propiedad y de contacto. Qu é activos existen en el entorno y cuál es su valor relativo. Cu áles son las amenazas conocidas y con qué procesos se cuenta para identificar otras nuevas o los cambios en el nivel de riesgo. Cu áles son las vulnerabilidades conocidas y con qué procesos se cuenta para identificar otras nuevas o los cambios en el nivel de vulnerabilidad. Qu é soluciones se han aplicado. Es muy conveniente que mantenga esta información al alcance de todas las personas involucradas en el proceso de administración de revisiones y que se asegure que esté siempre actualizada. Cuando haya identificado los activos, las vulnerabilidades, las amenazas y la configuración del entorno, puede determinar qué amenazas y vulnerabilidades representan realmente un problema para la organización. Sistemas de actualización de la seguridad En muchos entornos, puede ser conveniente tener equipos especializados en los que se puedan llevar a cabo muchos de los pasos del proceso de administración de revisiones. Estos sistemas proporcionan ubicaciones especializadas para las herramientas de seguridad, las revisiones, los Service Packs y la documentación. Se puede usar estos sistemas para realizar el análisis, la recuperación y la instalación de las revisiones. En este manual, nos referiremos a estos sistemas como Sistemas de actualización de la seguridad. 152 Debe asegurarse de que los Sistemas de actualización de la seguridad estén en uno o varios equipos dedicados que puedan asegurarse y controlarse estrechamente, ya que son los que se utilizarán para instalar y mantener las revisiones de seguridad para todos los sistemas de su entorno. Los Sistemas de actualización de la seguridad generalmente no necesitan ser servidores muy potentes, ya que la carga que soportan suele ser bastante ligera. No obstante, la alta disponibilidad es muy importante, ya que estos equipos serán la base para mantener el entorno actualizado con las revisiones más recientes. Para poder aplicar correctamente un Sistema de actualización de la seguridad, el equipo necesita tener acceso directo o indirecto a Internet para descargar la información más reciente de las revisiones de fuentes confiables, así como acceso a todos los equipos a los que debe mantener actualizados. Más adelante en este capítulo utilizaremos ejemplos y muestras de secuencias de comandos que se deben ejecutar desde un Sistema de actualización de la seguridad. Nota: MOF trata los sistemas de actualización como parte del proceso de administración de la versión. Comunicación Si la compañía es pequeña, es posible que sea suficiente con una persona encargada de mantener las revisiones actualizadas, realizar pruebas con las mismas, instalarlas y leer los distintos archivos de registro. Sin embargo, en los entornos más grandes suele haber varias personas encargadas de los diferentes aspectos de la seguridad. Es muy importante que exista una comunicación eficaz entre todas las personas involucradas en la administración de las revisiones. Esto permite garantizar que se toman decisiones sin duplicar esfuerzos y que no se omite ningún paso del proceso. Administración de revisiones y de cambios La administración de revisiones es en realidad sólo un subconjunto de la administración de cambios. Si ya dispone de un procedimiento de administración de cambios en la organización, no es necesario crear otro proceso totalmente nuevo para la administración de revisiones. Aún así, es conveniente que lea este capítulo para conocer la información específica del proceso de administración de revisiones. Un buen procedimiento de control de cambios tiene un propietario identificado, una vía de entrada de información de los clientes, una pista de auditoría de todos los cambios, un período definido de avisos y revisión, procedimientos de pruebas y un plan de contingencias conocido. Kit de herramientas de seguridad de Microsoft El kit de herramientas de seguridad de Microsoft puede ser útil para obtener los Service Packs y las revisiones necesarios para mantener los servidores actualizados. Contiene información de seguridad importante, los Service Packs más recientes y las revisiones de seguridad críticas para Windows NT 4.0, Windows 2000, IIS e Internet Explorer. También incluye la herramienta de notificación de actualizaciones críticas. Esta herramienta tiene un vínculo al sitio de actualización de Windows que garantiza la instalación de las revisiones más recientes. El kit de herramientas de seguridad se puede obtener en TechNet. 153 Procesos de administración de revisiones Ilustración 5.1.: Proceso de administración de revisiones. Vale la pena examinar estos pasos con más detalle: Análisis. Observe el entorno actual y determine las posibles amenazas. Determine qué revisiones debe instalar para reducir estas amenazas. Plan. Determine qué revisiones debe instalar para reducir las posibles amenazas y vulnerabilidades detectadas. Identifique quién llevará a cabo las pruebas y la instalación, y cuáles son los pasos que hay que seguir. Realización de pruebas. Revise las revisiones disponibles y clasifíquelas en categorías para su entorno; compruebe todas las revisiones identificadas para asegurarse de que funcionan en su 154 entorno sin efectos secundarios negativos. Comprenda qué hace realmente la revisión y cómo afecta al entorno. Asegúrese de que tiene el efecto previsto. Instalación. Instale las revisiones adecuadas para asegurar el entorno. Control. Compruebe todos los sistemas después de instalar las revisiones para asegurarse de que no producen efectos no deseados. Revisión. Como parte del proceso, debe revisar periódicamente las nuevas revisiones que han ido apareciendo, el entorno y las revisiones que necesita la compañía. Si durante este proceso determina que se necesitan nuevas revisiones, vuelva a empezar desde el primer paso. Nota: Es muy conveniente que realice copias de seguridad de todos los sistemas de producción antes de instalar una revisión. Análisis del entorno para detectar revisiones que faltan De manera continua, debe asegurarse de que tiene instaladas las revisiones más recientes. En algunos casos, aparecerá una nueva revisión que necesitará instalar en todos los servidores. En otros, se conectará un nuevo servidor al que será necesario instalar las revisiones apropiadas. Debe analizar de manera continua todos los servidores para asegurarse de que están totalmente actualizados con las revisiones más recientes necesarias. Como ayuda en este proceso, puede utilizar varias herramientas. Microsoft Network Security Hotfix Checker (Hfnetchk) Hfnetchk es una utilidad de la línea de comandos que le permite comprobar si la configuración actual de los servidores está actualizada y si tiene las revisiones de seguridad apropiadas. Esta herramienta funciona descargando directamente de Microsoft una base de datos XML (Extensible Markup Language) que contiene una lista de las revisiones más recientes que hay que comprobar para estar seguro. Hfnetchk también utiliza una base de datos XML local si no está conectado a Internet, aunque esto puede producir resultados no actualizados. Nota: Para usar Hfnetchk, debe tener acceso de administrador (local o de dominio) al equipo en el que se están comprobando las revisiones. La herramienta incluye varios modificadores de la línea de comandos, que se indican en la tabla siguiente. Tabla 5.1.: Modificadores de Hfnetchk. Modificador Hfnetchk de Función -about Acerca de hfnetchk. -h <nombre de host> Especifica el nombre del equipo NetBIOS que se va a explorar. El nombre predeterminado es el del host local. -fh <archivo de host> Especifica el nombre de un archivo que contiene los nombres de los equipos NetBIOS que se van a explorar. Un nombre por línea, máximo 256 por archivo. 155 -i <dirección ip> Especifica la dirección IP del equipo que se va a explorar. -fip <archivo ip> Especifica el nombre de un archivo que contiene las direcciones que se van a explorar. Una dirección IP por línea, máximo 256 por archivo. -r <intervalo> Especifica el intervalo de direcciones IP que se va a explorar, comenzando con la dirección IP 1 y terminando con la dirección IP 2. El intervalo incluye ambos extremos. -d >nombre_dominio> Especifica el nombre de dominio que se va a explorar Se exploran todos los equipos del dominio. -n <red> Se exploran todos los sistemas de la red local (todos los hosts del entorno de red). -history <nivel> No se necesita para el funcionamiento normal. -t <subprocesos> El número de subprocesos utilizados para ejecutar la exploración. Los posibles valores van del 1 al 128. El valor predeterminado es 64. -o <salida> Especifica el formato de salida deseado. (tab) genera salidas en formato delimitado por tabuladores. (wrap) genera salidas en formato de ajuste de línea. La salida predeterminada es wrap. -x <origen de datos> Especifica el origen de datos xml que contiene la información de la revisión. La ubicación puede ser un nombre de archivo xml, un archivo cab xml comprimido o una URL. El origen predeterminado es mssecure.cab del sitio Web de Microsoft. -s <suprimir> Suprime los mensajes de NOTA y de ADVERTENCIA. 1 = Suprime sólo los mensajes de NOTA, 2 = Suprime los mensajes de NOTA y de ADVERTENCIA. La opción predeterminada es mostrar todos los mensajes. -z No realizar las comprobaciones del registro. -nosum No evaluar la suma de comprobación de archivos. La prueba de suma de comprobación calcula la suma de comprobación de los archivos. Esta acción puede utilizar una gran cantidad de ancho de banda. Con esta opción se puede aumentar la velocidad de la exploración, utilizando menos ancho de banda. Se sigue realizando la comprobación de la versión de los archivos. -b Muestra el estado de las revisiones necesarias para satisfacer los estándares de seguridad de línea de base mínimos. -v Muestra los detalles de los mensajes de revisión no encontrada, ADVERTENCIA y NOTA. Está habilitado de forma predeterminada en el modo tab. -f <archivo de salida> Especifica el nombre del archivo en el que se guardarán los resultados. La salida predeterminada es mostrar los resultados en la pantalla. -u <nombre de usuario> Especifica el nombre de usuario opcional para iniciar una sesión en un equipo remoto. 156 -p <contraseña> Especifica la contraseña que se debe utilizar con el nombre de usuario. -? Muestra un menú de ayuda. Si utiliza Hfnetchk para comprobar el estado de las revisiones, debe asegurarse de ejecutarlo regularmente. En la mayoría de los entornos, la mejor manera de hacer esto es programarlo para que se ejecute regularmente. Nota: Para obtener más información acerca del uso de Hfnetchk, consulte el artículo de Knowledge Base Q303215, "Microsoft Network Security Hotfix Checker (Hfnetchk.exe) Tool Is Available" (en inglés). Secuencia de comandos de administración de revisiones Este manual incluye una secuencia de comandos de administración de revisiones, hfnetchk.cmd, que comprueba varios servidores para detectar las revisiones que faltan y registra los resultados en un archivo de registro que se guarda en una carpeta basada en fechas. La secuencia de comandos utiliza Hfnetchk para explorar los servidores y otra secuencia de comandos, movelog.vbs, para mover los archivos a las carpetas adecuadas. Con el tiempo, estas carpetas forman un historial que puede revisar como parte de las fases de análisis y revisión, y que le ayuda a mantener un entorno más seguro. Nota: La secuencia de comandos que se proporciona con este manual necesita Hfnetchk.exe versión 3.32 o posterior. Después de descargar y extraer las secuencias de comandos que se proporcionan con este manual, tendrá la siguiente estructura de carpetas para la secuencia de comandos de administración de revisiones. Tabla 5.2.: Estructura de carpetas para la secuencia de comandos de administración de revisiones. Carpeta Descripción C:\SecurityOps Ésta es la carpeta raíz para todos los archivos que se proporcionan con este manual. C:\SecurityOps\PatchMgmt Esta carpeta contiene la secuencia de comandos de administración de revisiones, hfnetchk.cmd, la secuencia de comandos movelog.vbs y las subcarpetas para los archivos de soporte y los registros. En esta carpeta es donde debe colocarse el archivo mssecure.xml. C:\SecurityOps\PatchMgmt\Hfnetchk En esta carpeta es donde debe colocarse la utilidad hfnetchk.exe después de descargarla del sitio Web de Microsoft. Más adelante se proporcionan las instrucciones detalladas. C:\SecurityOps\PatchMgmt\ServerLists En esta carpeta es donde se crean y se mantienen los archivos de texto con las listas de los grupos de servidores que se van a explorar para detectar las 157 revisiones que faltan. C:\SecurityOps\PatchMgmt\Logs En esta carpeta se crean los archivos de registro después de ejecutar hfnetchk.cmd. La secuencia de comandos crea una subcarpeta con la fecha actual en la que se almacena el archivo de registro; por ejemplo, \SecurityOps\PatchMgmt\Logs\2002117. Nota: Si instala los archivos que se proporcionan con este manual en una partición que no sea C:, debe modificar las rutas de acceso del archivo hfnetchk.cmd para que utilicen la partición adecuada. Para instalar y usar el archivo de comandos Hfnetchk.cmd en un Sistema de actualización de la seguridad 1. Ejecute SecurityOps.exe para extraer los archivos de la secuencia de comandos que se proporcionan con este manual y crear la estructura de carpetas que se indica en la tabla 5.2. 2. Descargue y extraiga la utilidad Hfnetchk de http://www.microsoft.com/Downloads/Release.asp?ReleaseID=31154 (en inglés) y coloque hfnetchk.exe en la carpeta C:\SecurityOps\PatchMgmt\Hfnetchk. Si el equipo que ejecuta la secuencia de comandos no está conectado a Internet, necesitará descargar y extraer el archivo Mssecure.xml de http://download.microsoft.com/download/xml/security/1.0/nt5/enus/mssecure.cab (en inglés). Mssecure.xml debe colocarse en la carpeta C:\SecurityOps\PatchMgmt. 3. Cree un archivo de texto de lista de servidores en C:\SecurityOps\PatchMgmt\ServerLists. Este archivo de texto contiene los nombres NetBIOS de los servidores que desea comprobar, separados por retornos de carro. Nota: Hfnetchk.exe versión 3.32 no explora ningún servidor que tenga un espacio después del nombre del mismo y antes del retorno de carro. Antes de ejecutar Hfnetchk, compruebe que no haya líneas que terminen con un espacio. 4. Inicie un símbolo del sistema, cambie a la carpeta C:\SecurityOps\PatchMgmt e inicie la secuencia de comandos con la siguiente línea de comandos. Hfnetchk.cmd listaservidores.txt En esta línea de comandos, listaservidores.txt es el nombre del archivo de texto que contiene la lista de servidores. Nota: Si aparece un cuadro de diálogo que le pregunta si desea descargar el archivo mssecure.xml, haga clic en Sí. 5. Cambie a la carpeta C:\SecurityOps\PatchMgmt\Logs, abra la carpeta con la fecha actual y abra el archivo con el mismo nombre que el archivo listaservidores.txt. 6. Examine el archivo de registro para determinar las revisiones que faltan en los servidores. Nota: Si ejecuta la secuencia de comandos de administración de revisiones dos veces en el mismo día, se sobrescribirá el archivo de registro de la primera vez que ejecutó la secuencia de comandos. 158 Uso de varias listas de servidores En una red a gran escala puede haber varios tipos de servidores distintos. Como parte del proceso de administración de riesgos, puede determinar que necesita controlar algunos servidores con mayor frecuencia que otros para detectar si faltan revisiones. Si usa varias listas de servidores, puede programar la secuencia de comandos de administración de revisiones para que explore los diferentes tipos de servidores en intervalos distintos. También resulta útil tener varias listas de servidores si hay distintos administradores responsables de los diferentes grupos de servidores. Si utiliza varias listas, puede crear informes independientes de las revisiones que faltan para cada grupo de administradores. Por ejemplo, para la red simple que se muestra en la ilustración 5.2., puede crear seis archivos de listas de servidores para proporcionar informes de las revisiones a los diferentes grupos de administradores. Ilustración 5.2.: Archivos de listas de servidores para una red simple. En este ejemplo, los archivos de lista de servidores para cada tipo de servidor sólo contienen los nombres de esos servidores. Por ejemplo, File&Print.txt sólo contiene: FP01 FP02 FP03 El sexto archivo de lista de servidores, Servers.txt, contiene todos los servidores del entorno. El equipo de seguridad puede utilizar los resultados de esta exploración para asegurarse de que cada grupo mantiene sus servidores actualizados con las revisiones más recientes. Programación de la secuencia de comandos de administración de revisiones Para asegurarse de que hfnetchk.cmd se ejecuta regularmente, puede programar la ejecución periódica de la herramienta. Esto se puede hacer con el programador de tareas o el comando AT. Si utiliza varias listas de servidores, puede hacer que se comprueben los diferentes servidores en momentos distintos. 159 Nota: De forma predeterminada, el servicio de programación está deshabilitado en las directivas de línea de base para los servidores miembros y para los controladores de dominio. Necesitará habilitarlo si desea programar la secuencia de comandos de administración de revisiones. Otros métodos para determinar los niveles de revisión Si no desea o no puede utilizar la herramienta hfnetchk en algunas partes del entorno, hay otras maneras de determinar si se han instalado revisiones. La forma más fácil es mirar el registro bajo la clave HKLM\Software\Microsoft\Windows Nt\Currentversion\hotfix. Cada revisión nueva instalada debe tener una clave con un nombre Q que corresponde al artículo de Knowledge Base que trata de la revisión. Sin embargo, esto no ocurre con algunas revisiones antiguas y con las de algunas aplicaciones. Hay otras dos herramientas gratuitas de Microsoft que pueden utilizarse para obtener esta información. Éstas son: Qfecheck.exe /v. Indica el nivel del Service Pack y las revisiones instaladas. Qfecheck también indica si la revisión no se instaló correctamente. Hotfix.exe -l. Muestra las revisiones instaladas. Plan No todas las amenazas y vulnerabilidades suponen un riesgo importante para su entorno. Cuando lea avisos de posibles nuevas vulnerabilidades de un sistema operativo o una aplicación, debe evaluar si éstas afectan a su entorno. Por ejemplo, si la vulnerabilidad afecta al servicio de FTP de Windows 2000 y usted nunca lo ha habilitado, la vulnerabilidad no le afecta. Es lo mismo que si le informan de que hay más probabilidades de que haya huracanes este año, pero su entorno de TI está en un área protegida de los huracanes: el riesgo es mínimo. Si responde a las amenazas y vulnerabilidades que no son reales para su entorno, utilizará valiosos recursos y puede incluso afectar negativamente a la estabilidad de su entorno sin llegar a obtener ningún beneficio. A medida que se descubren nuevas amenazas y vulnerabilidades, debe leer toda la información de apoyo correspondiente. Esto le permitirá tomar una decisión inteligente sobre si existe un riesgo significativo para su entorno y determinar, por lo tanto, la respuesta apropiada. Esta respuesta puede ser no hacer nada, desactivar el servicio que corre el riesgo o instalar una revisión. Nota: Al crear el plan para instalar una nueva revisión, también debe crear un plan para desinstalarla. Nota: Para asegurarse de que tiene la información actualizada acerca de las revisiones más recientes, asegúrese de que recibe regularmente los boletines de seguridad de Microsoft. Para registrarse y recibirlos, vaya al sitio Web de seguridad de Microsoft. Consulte el vínculo en el apartado "Más información", al final de este capítulo. Clasificación de las revisiones Siempre que aparece una nueva revisión, debe determinar su importancia para su entorno. Esto determinará si es urgente que la instale y la cantidad de pruebas que debe realizar. Microsoft proporciona una calificación para cada vulnerabilidad objeto de un boletín de seguridad. Los niveles de calificación se muestran en la tabla siguiente. 160 Tabla 5.3.: Calificaciones de vulnerabilidad definidas por Microsoft. Tipo de equipo Nivel de calificación Crítica Moderada Baja Servidores de Internet Distorsión del sitio Web, servicio denegado o control total Dificultad para usarlo, configuración inusual o efectos transitorios Efectos limitados, como revelación de las secuencias de comandos Servidores internos Aumento de los privilegios, difusión o modificación de datos. Problemas para realizar auditorías Difusión o modificación de los datos auditables, o servicio denegado Robo o modificación de datos indiscriminados o parciales, servicio denegado de forma limitada Sistemas cliente Ejecución de código arbitrario sin la acción del usuario, aumento remoto de los privilegios Aumento local de los privilegios, difusión de datos indiscriminada o servicio denegado; uso de las acciones del usuario Robo o modificación limitados o parciales de datos, ataques hostiles al sitio Web El sistema de calificación clasifica las vulnerabilidades según el posible efecto que pueden tener y la probabilidad de que eso ocurra. Puede usar este sistema de clasificación como una guía para clasificar las revisiones. No obstante, el sistema de calificación de Microsoft es sólo una estimación global de las posibles repercusiones en un contexto de millones de clientes en todo el mundo; las calificaciones de gravedad se basan en la experiencia previa y en criterios subjetivos, por lo que no siempre pueden predecir exactamente lo que ocurrirá en su entorno. En último término, es usted quien debe clasificar las revisiones basándose en su propio entorno. Realizar pruebas de las revisiones Como ocurre con cualquier software, es posible que las revisiones no funcionen perfectamente en todos los entornos. Lo ideal es comprobar exhaustivamente todas las revisiones que va a instalar en su entorno. Sin embargo, muchas revisiones de seguridad deben instalarse rápidamente para reparar problemas potencialmente importantes. En muchos casos, verá que el procedimiento de prueba es una solución intermedia entre la necesidad de resolver un problema de seguridad y la necesidad de garantizar que la revisión sea estable en su entorno. La cantidad de pruebas necesarias depende de cómo haya clasificado la revisión. A partir de las clasificaciones de Microsoft, la tabla siguiente muestra el nivel mínimo de pruebas que debe realizar con cada tipo de revisión. Tabla 5.4.: Pruebas mínimas para las revisiones. Tipo de revisión La comprobación debe incluir 161 Revisiones de gravedad crítica Evaluación de la revisión Evaluación de las operaciones del servidor (limitada) Revisiones de gravedad moderada Evaluación de la revisión Instalación de la revisión en un entorno de prueba Evaluación de las operaciones del servidor (completa) Comprobación del procedimiento de desinstalación Revisiones de gravedad baja Evaluación de la revisión Instalación de la revisión en un entorno de prueba Evaluación de las operaciones del servidor (completa) Evaluación de las operaciones de la aplicación Comprobación del procedimiento de desinstalación Como parte del procedimiento de administración de riesgos, debe determinar lo exhaustivo que será cada paso. Si omite algunas de estas fases debido a la urgencia, debe realizarlas después en un laboratorio de pruebas para detectar los posibles problemas antes de que ocurran en los sistemas ya instalados. Todas las pruebas deben realizarse en servidores que se parezcan lo más posible a los servidores de producción. Evaluación de la revisión Como mínimo, la evaluación de la revisión debe incluir los pasos siguientes: Identificación del propietario de la revisión. Todas las revisiones deben tener un propietario identificado que sea el responsable de la evaluación de la revisión. Revisión de toda la documentación. Antes de aplicar cualquier Service Pack, revisión o revisión de seguridad, se debe leer toda la documentación relevante y debe ser revisada por otras personas del mismo nivel. Este proceso de revisión es fundamental, ya que reduce el riesgo de que a una sola persona se le escape algún punto crítico o importante al evaluar la actualización. Verificación de la categoría de la revisión. Es posible que al evaluar con más detalle la revisión, necesite cambiar su categoría. Esto afectará a otros aspectos de la realización de pruebas. Al leer la documentación, plantéese lo siguiente: ¿Es relevante la actualización y puede resolver el problema en cuestión?. ¿La instalación de la actualización puede ocasionar otros problemas que supongan un riesgo para el sistema de producción?. 162 ¿Existen dependencias relacionadas con la actualización?. (Por ejemplo, que haya que habilitar o deshabilitar ciertas funciones para que la actualización surta efecto.). ¿Es necesario realizar acciones antes de instalar la actualización?. Además de examinar la documentación incluida con la actualización, debe buscar en el sitio Web de soporte de Microsoft información adicional sobre la actualización publicada después de su comercialización. En su sitio Web, TechNet también proporciona boletines de seguridad en una base de datos en la que se pueden realizar búsquedas por nombre de producto y Service Pack. Estos materiales proporcionan información crítica a la que hay que referirse. Instalación Debe asegurarse de que la revisión se instale tal como está previsto, saber si necesita que se reinicie el sistema, cuánto espacio ocupa (incluida la carpeta de desinstalación), comprender de qué opciones dispone, etc. Además de instalar la revisión, debe leer toda la documentación de apoyo para obtener más información. Operaciones del servidor Una vez instalada la revisión, debe asegurarse de que el servidor sigue funcionando normalmente. También es una buena idea supervisar el registro de sucesos y el Monitor de Sistema por si se producen resultados inesperados. Compruebe todas las funciones del servidor y asegúrese de que todo funciona normalmente. El riesgo que está dispuesto a asumir en un determinado servidor y para una vulnerabilidad específica determinará cuánto tiempo debe funcionar el servidor antes de determinar que todo funciona normalmente. Si hay cualquier problema, debe asegurarse de que está documentado y de que se han evaluado las ventajas y las desventajas de aplicar la revisión. Si ocurre algún problema, debe comunicarse a Microsoft lo antes posible. Nota: Puede usar Microsoft Operations Manager para obtener la información del Registro de sucesos y del Monitor de sistema. Operaciones de las aplicaciones Como parte del procedimiento de realización de pruebas, es importante que pruebe la revisión con todas las aplicaciones que coexistan en los servidores y que se asegure de identificar todos los problemas con dependencias. Después de instalar la revisión, debe comprobar que todas las aplicaciones siguen funcionando igual que antes. Desinstalación Es posible que, a pesar de haber realizado pruebas, surjan problemas que hagan necesario desinstalar la revisión. Por lo tanto, es importante comprobar que la desinstalación funciona. Después de desinstalar la revisión, debe comprobar que el servidor sigue funcionando según lo previsto y continuar vigilando los contadores del Registro de Sucesos y del Monitor de Sistema. Creación de un plan de contingencias Aunque la realización de pruebas se lleve a cabo totalmente sin ninguna incidencia, es posible que surja algún problema al instalar la revisión en toda la organización. Por este motivo, es necesario contar con un plan de acción para restaurar el sistema al estado en el que estaba antes de instalar la revisión. En algunos casos, esto se hace realizando una copia de seguridad instantánea de un servidor antes de la instalación, de manera que si surge algún problema sea 163 posible restaurar el servidor muy rápidamente. Sea cual sea el plan de contingencias, se deben realizar pruebas exhaustivas. Instalación de las revisiones Si las pruebas se llevan a cabo sin problemas, estará listo para instalar la revisión en toda la organización. Esto puede hacerse por distintos métodos, que son: Manual. Directivas de grupo. Archivos de comandos. Nota: Para obtener más información acerca de la instalación de revisiones, consulte el artículo de TechNet "Best Practices for Applying Service Packs, Hotfixes and Security Patches" (en inglés). Consulte el vínculo en el apartado "Más información", al final de este capítulo. Manual La instalación manual de revisiones es el método de instalación más común en la mayoría de las organizaciones. Consiste simplemente en ejecutar el archivo .exe que corresponde a la revisión en cada servidor. Si su organización tiene un gran número de servidores, es posible que esta opción no sea práctica. El nombre de la mayoría de las revisiones proporciona información importante acerca de la reparación. Por ejemplo, un nombre típico de revisión es Q292435_W2K_SP3_x86_en.EXE. En este caso: Q292435 es el n úmero del artículo de Knowledge Base en el que puede obtener más información acerca de la revisión. W2K es el producto para el que se ha dise ñado (Microsoft Windows 2000). SP3 es el Service Pack en el que se va a incluir. x86 es la arquitectura de procesador para la que se ha dise ñado. en es el idioma (ingl és). Nota: Las revisiones que tienen como nombre de archivo QXXXXXX.exe y no incluyen la parte de W2K_SP3_x86 son específicas para aplicaciones como Internet Explorer. Las revisiones también admiten varios modificadores de línea de comandos que se pueden utilizar para controlar el comportamiento del proceso de instalación de la revisión. Tabla 5.5.: Modificadores para ejecutables de revisión. Modificador Descripción -y Desinstalar -f Forzar el cierre de las aplicaciones al apagar 164 el sistema -n No crear un directorio de desinstalación -z No reiniciar al finalizar la actualización. -q Modo silencioso: sin interfaz de usuario -m Modo desatendido -l Indicar las revisiones instaladas Nota: Por lo general, las revisiones específicas de aplicaciones con nombres de archivo QXXXXXX.exe no admiten todos los modificadores anteriores. Si incluye una secuencia de comandos en la instalación de varias revisiones, es conveniente utilizar los modificadores -q y -z para que la revisión se instale sin interfaz de usuario y no reinicie el sistema. Normalmente, cuando se instalan varias revisiones es necesario reiniciar el equipo entre cada una. Esto se debe a que no se pueden reemplazar los archivos bloqueados o que están utilizándose, y se colocan en una cola para sustituirse al reiniciar el sistema. QChain es una herramienta que permite encadenar varias revisiones reiniciando una sola vez, en lugar de reiniciar después de cada instalación. Para utilizar QChain, ejecute el instalador de la revisión con el modificador -z para indicar al instalador que no debe reiniciar después de la instalación. Después, ejecute QChain.exe y reinicie el equipo. Nota: QChain está disponible en TechNet. Para obtener información más detallada, consulte el apartado "Más información", al final de este capítulo. Si se agregan otros componentes, como DNS, después de aplicar un Service Pack y revisiones, será necesario volver a aplicar el Service Pack y las revisiones para que el nuevo componente tenga todas las correcciones necesarias. Directiva de grupo Windows 2000 admite, de forma nativa, la distribución de software por medio de una directiva de grupo. Las revisiones no se incluyen normalmente en un paquete del instalador de Windows. Sin embargo, se puede usar el ejecutable en combinación con un archivo .zap. Las aplicaciones que no utilizan paquetes del instalador de Windows deben utilizar un archivo .zap para describir el programa de instalación existente. Un archivo .zap es un archivo de texto (similar a los archivos .ini) que proporciona información acerca de cómo instalar un programa, las propiedades de la aplicación y los puntos de entrada que debe instalar la aplicación. Un archivo .zap sólo se puede asignar a un usuario, lo que significa que una vez configurada la directiva de grupo para distribuir la revisión, necesitará iniciar una sesión en el equipo con la cuenta de usuario a la que se asignó el archivo .zap. Nota: Para obtener más información acerca de la creación de archivos .zap y su asignación por medio de directivas de grupo, consulte el artículo de Knowledge Base Q231747, "How to Publish non-MSI Programs with .zap Files" (en inglés). 165 Archivos de comandos Es posible que desee crear sus propios archivos VBScripts o por lotes para distribuir las revisiones. Estos archivos pueden tener forma de secuencias de comando de conexión o de inicio, que comprueben el estado de la revisión actual y, a continuación, si existen actualizaciones en un servidor centralizado. Las secuencias de comandos pueden incluir QChain para garantizar que sólo se reinicie una vez si es necesario instalar más de una revisión. Supervisión Después de instalar las revisiones en el entorno de producción, es necesario seguir supervisando los servidores. Asegúrese de revisar los contadores del Registro de sucesos y del Monitor de sistema para detectar cualquier problema. Si observa algún error en el equipo durante las siguientes semanas, debe realizar pruebas para asegurarse de que no está relacionado con la revisión implementada. Asimismo, si instaló una revisión sin una comprobación de laboratorio exhaustiva debido a una situación crítica, deberá comprobar posteriormente la revisión en un entorno de laboratorio para asegurarse de que no omitió nada. Además de controlar los servidores existentes, es importante que supervise el entorno completo para asegurarse de que no se han incluido en la red nuevos servidores a los que no se hayan aplicado las revisiones actuales. La versión más reciente debe estar siempre disponible para aplicarla a los servidores nuevos y debe asegurarse de que se aplique. Revisión Sólo puede estar seguro de que un proceso funciona correctamente si lo revisa. Al terminar el proceso de administración de revisiones para cada revisión, debe revisarla para asegurarse de que se instaló correctamente y de que todos los procedimientos funcionan tal como estaba previsto. Esto le permitirá estar seguro de que los procesos seguirán funcionando correctamente. Al revisar el proceso de administración de revisiones, debe seguir analizando si se han producido otros cambios al entorno que puedan iniciar de nuevo el proceso de administración de revisiones. Administración de revisiones del lado del cliente Este capítulo trata acerca del proceso de administración de revisiones del lado del servidor, pero debe recordar que, muchas veces, los virus y otras amenazas para la seguridad de la organización obtienen acceso por el lado del cliente. La mayoría de los elementos anteriores también se aplican a la administración del lado del cliente, pero existen algunas diferencias. En la mayoría de los casos, las diferencias no están tanto en lo que hace la revisión sino en cómo se determina en la organización qué revisiones se necesitan, cómo se realizan las pruebas y cómo se instalan. Hay varias herramientas que ayudan específicamente con la administración de revisiones del lado del cliente. Windows Update Si está ejecutando una base de clientes con Windows XP, una forma sencilla de comprobar y aplicar correcciones es utilizando Windows Update. Al entrar en el sitio Web de Windows Update, se explora el equipo y se muestra una lista de todas las revisiones, tanto de seguridad como de otro tipo, que no están instaladas y se pueden descargar. 166 Para ejecutar Windows Update, debe ser un administrador del equipo local. Esto puede hacer que la herramienta no sea práctica en muchos entornos. Windows Update Corporate Edition El sitio Web de Windows Update Corporate Edition proporciona un catálogo completo de las actualizaciones que se pueden distribuir a través de una red corporativa. En la misma ubicación se encuentra el contenido de Windows Update y controladores de dispositivos con el logotipo de Microsoft Windows Hardware Quality Lab (WHQL). Windows Update Corporate Edition permite: Buscar las actualizaciones m ás recientes del software y los controladores por palabras clave, sistema operativo, tipo de actualización, tipo de componente, idioma, fecha de publicación y fabricante, con el fin de encontrar las más relevantes para su organización. Descargar las actualizaciones necesarias de una en una o s eleccionar varias para descargarlas como un paquete listo para distribuirlo en toda la red. Utilizar el historial de descargas para revisar las actualizaciones descargadas previamente y dónde están ubicadas. Usar el archivo Lea esto primero suministr ado con cada descarga para obtener información detallada acerca de cada actualización antes de descargarla. Los archivos Lea esto primero se proporcionan con todos los paquetes de descarga y contienen vínculos a sitios Web relevantes que contienen más información. Microsoft Baseline Security Analyzer Esta aplicación de seguridad se puede descargar de TechNet y ayuda a garantizar que los sistemas basados en Windows 2000 y Windows XP estén seguros y actualizados. Baseline Security Analyzer explora uno o varios sistemas y devuelve un informe de problemas como: revisiones de seguridad que faltan, contraseñas débiles, configuración de seguridad de Internet Explorer y Outlook Express y configuración de protección de las macros de Office. También proporciona información acerca del problema de seguridad detectado, cómo repararlo y vínculos con información adicional acerca del problema. Otras herramientas Si sigue las recomendaciones incluidas hasta aquí en este capítulo, habrá recorrido la mayor parte del camino necesario para administrar eficazmente las revisiones en su organización. Sin embargo, aún hay varias herramientas más que puede utilizar para automatizar el proceso de administración de revisiones. SMS Si tiene Microsoft Systems Management Server (SMS) instalado en su organización, puede usarlo como ayuda en muchas de las fases descritas anteriormente. El Kit de herramientas del programa de seguridad de Microsoft contiene una herramienta de importación de SMS que puede utilizarse para automatizar la distribución y la instalación de las correcciones de seguridad de IIS recomendadas. SMS puede ayudarle a determinar qué equipos necesitan las correcciones de seguridad y a instalarlas. 167 Las funciones de instalación de software de SMS se pueden utilizar para distribuir revisiones en su entorno a todos los equipos que tengan el cliente SMS. Si crea un paquete de software para la revisión, puede llevar a cabo la actualización de todos los equipos del entorno o de un grupo determinado. Una de las ventajas principales es que puede controlar qué equipos tienen la revisión instalada. Sin embargo, en la mayoría de los casos necesitará un administrador de SMS o una persona que sepa crear paquetes SMS para distribuirlos correctamente. Herramientas de otros fabricantes Hay varias herramientas de otros fabricantes disponibles que ayudan a la administración de revisiones. Estas herramientas ofrecen algunas funciones que aún no están disponibles en las herramientas gratuitas de Microsoft, como la posibilidad de implementar correcciones y recibir un informe del estado final, crear grupos de equipos con necesidades de actualización similares, compatibilidad con productos que las herramientas antes descritas no contemplan, y áreas de comandos en la interfaz gráfica de usuario (GUI) para las tareas administrativas. Debe evaluar estas funciones y determinar si son necesarias en su entorno. Utilidad Polaris Group Hotfix/Service Pack Esta herramienta tiene una GUI fácil de usar, es compatible con todos los productos Microsoft y puede automatizar el proceso de implementación de Service Packs y revisiones para que todos los equipos funcionen de acuerdo con el estándar corporativo especificado. http://www.polarisgroup.com/solutions (sitio Web en inglés). Shavlik Hfnetchkpro Creado a partir de la tecnología Hfnetchk. Tiene una GUI y permite mantener un historial de exploraciones que no está disponible en la versión de la línea de comandos. http://www.shavlik.com/nshc.htm (sitio Web en inglés). Bindview Security Advisor La herramienta Bindview tiene una GUI que simplifica el proceso de comprobar si hay equipos que no cumplen los requisitos. También tiene un servicio de actualización que le informa cuando aparecen nuevas revisiones. http://www.bindview.com/Solutions/Security/SecAdvisor_bvCtrlW2k.cfm (sitio Web en inglés). Pedestal Software’s Security Expressions Esta herramienta permite a los administradores aplicar directivas de bloqueo de seguridad en equipos con Windows y UNIX. También puede comprobar si se han aplicado revisiones y, en caso necesario, descargarlas e instalarlas. http://www.pedestalsoftware.com/secexp/index.htm (sitio Web en inglés). Resumen La mayoría de los problemas de seguridad en TI se deben al uso de sistemas que no están plenamente actualizados con las revisiones de seguridad más recientes. Para minimizar los riesgos de seguridad, es esencial contar con una buena administración de revisiones. Si se toma 168 en serio la administración de revisiones, puede reducir notablemente los costos asociados con los problemas de seguridad. Más información Más información acerca de Hfnetchk: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q303215 (en inglés). Para descargar Hfnetchk: http://www.microsoft.com/downloads/release.asp?releaseid=31154 (en inglés). Descarga de mssecure.cab: http://download.microsoft.com/download/xml/security/1.0/nt5/en-us/mssecure.cab (en inglés). Para obtener más información acerca de cómo crear un archivo .zap para utilizarlo con una directiva de grupo, consulte: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q231747 (en inglés). o bien http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexnt00/html/ewn0085.asp (en inglés). Información y descarga de Qfecheck.exe: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q282784 (en inglés). Información acerca de Hotfix.exe: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q184305 (en inglés). Información acerca de Qchain y descarga del archivo ejecutable: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q296861 (en inglés). Información acerca del sistema de calificación de la seguridad de Microsoft: http://www.microsoft.com/technet/security/policy/rating.asp (en inglés). Para recibir periódicamente los boletines de seguridad de Microsoft: http://www.microsoft.com/technet/security/current.asp (en inglés). Kit de herramientas del programa de seguridad de Microsoft: http://www.microsoft.com/technet/security/tools/stkintro.asp (en inglés). Microsoft Operations Framework (MOF): http://www.microsoft.com/business/services/mcsmof.asp (en inglés). 169 Mejores prácticas para aplicar Service Packs, revisiones y revisiones de seguridad: http://www.microsoft.com/technet/security/bestprac/bpsp.asp (en inglés). Referencias y vínculos Microsoft TechNet Security Site: http://www.microsoft.com/technet/itsolutions/security/bestprac/secthret.asp (en inglés). Microsoft Security Best Practices: http://www.microsoft.com/technet/itsolutions/security/bestprac/secthret.asp (en inglés). How to Publish non-MSI Programs with .zap Files (Q231747): http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q231747 (en inglés). 6. Auditoría y detección de intrusiones En cualquier entorno seguro, deberá supervisar de forma activa que no se produzcan intrusiones ni ataques. No sería sensato instalar sistemas seguros y asumir que no se va a producir ningún ataque. Existen varias razones que denotan la importancia de la auditoría y la supervisión de intrusiones. Éstas incluyen: Cualquier entorno inform ático funcional puede estar sujeto a ataques. Por muy alta que sea la seguridad, siempre existe el riesgo de que se produzca un ataque. Los ataques verdaderos suelen producirse a menudo tras varios ataques infructuosos. Si no supervisa que no se produzcan ataques, no los detectará antes de que sean efectivos. Si se produce un ataque efect ivo, cuanto antes lo detecte, más fácil le resultará contener los daños. Para recuperarse de un ataque, necesitar á conocer los daños que se han producido. La auditor ía y la detección de intrusiones le ayudan a determinar el origen del ataque. La comb inación de la auditoría y la detección de intrusiones permite establecer una correlación entre la información para identificar las pautas de los ataques. La revisi ón habitual de los registros de seguridad ayuda a identificar problemas de configuración de la seguridad desconocidos, como permisos incorrectos u opciones de configuración de bloqueo de cuentas poco estrictas. Una vez detectado un ataque, la auditor ía puede ayudar a determinar los recursos de red que se ven comprometidos. Este capítulo explica cómo auditar el entorno para mejorar al máximo la detección de ataques y trata la supervisión de intrusiones, como el uso de sistemas de detección de intrusiones (software diseñado específicamente para detectar comportamientos que indican la existencia de un ataque). 170 Auditoría Como parte de la estrategia general de seguridad, deberá determinar el nivel de auditoría que sea apropiado para el entorno. La auditoría debe identificar los ataques, tanto si son efectivos como infructuosos, que representan una amenaza para la red o ataques contra recursos que considera valiosos como parte de la evaluación de riesgos. Al decidir el nivel de auditoría, deberá tener en cuenta que cuanto más alto sea el nivel, más sucesos se generarán y más difícil resultará detectar sucesos críticos. Si lleva a cabo una auditoría exhaustiva, se recomienda considerar el uso de herramientas adicionales, como Microsoft Operations Manager, para ayudarle a filtrar los sucesos de mayor importancia. Los sucesos de auditoría pueden dividirse en dos categorías: sucesos de acierto y sucesos de error. Los sucesos de acierto indican que un usuario ha conseguido obtener acceso a un recurso, mientras que los sucesos de error indican que se produjo un intento fallido. Los sucesos de error resultan muy útiles a la hora de realizar un seguimiento de intentos de ataque en el entorno, pero los sucesos de acierto son mucho más difíciles de interpretar. Aunque la inmensa mayoría de los sucesos de auditoría de acierto son simplemente indicaciones de actividad normal, si un atacante consigue obtener acceso al sistema, también se generará un suceso de acierto. A menudo, la pauta de sucesos es tan importante como los sucesos en sí. Por ejemplo, varios errores seguidos por un acierto pueden indicar un intento de ataque que acabó teniendo éxito. Siempre que sea posible, deberá combinar sucesos de auditoría con otra información acerca de los usuarios. Por ejemplo, si los usuarios se van de vacaciones, puede desactivar las cuentas durante ese período y auditar si se activan de nuevo. Cómo activar la auditoría La auditoría se activa mediante la Directiva de grupo en el nivel de sitio, dominio, unidad organizativa o equipo local. La configuración de directivas de auditoría se encuentra ubicada en: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy Normalmente, deberá implementar la auditoría en un nivel alto de la jerarquía de Active Directory, puesto que le ayudará a mantener la coherencia de la configuración de auditoría. En esta guía, se implementa la auditoría en los niveles de Servidores miembros y Unidad organizativa de controladores de dominio (consulte el capítulo 4, "Asegurar servidores basándose en su función", para obtener más información). Puede que haya decidido mantener varios servidores separados del dominio. Para configurar la auditoría en estos equipos, modifique la Directiva de grupo del equipo local o use la utilidad Auditpol.exe de Windows 2000 Server. Kit de recursos. Nota: Para obtener acceso a la Directiva de grupo de un equipo local, inicie MMC y, a continuación, agregue el complemento Directiva de grupo y haga que el equipo local sea el enfoque del complemento. Definir la configuración del Registro de sucesos Todos los sucesos generados por la auditoría aparecen en el Visor de sucesos. Debe determinar cómo almacena el Registro de sucesos los sucesos que se generan. Cada una de las opciones de configuración puede definirse directamente en el Visor de sucesos o en la Directiva de grupo. Para esta guía, se ha definido la configuración del Visor de sucesos en la Directiva de grupo. 171 Para obtener más detalles acerca de la configuración recomendada, consulte el capítulo 4, "Asegurar servidores basándose en su función". Es posible que desee modificar la configuración definida en la Directiva de grupo o aplicar la configuración en otro nivel. Por ejemplo, puede suceder que el registro de seguridad se llene con los servidores IIS y el sistema se colapse. Para evitarlo, modifique la Directiva de grupo en la unidad organizativa de servidores IIS para aumentar el tamaño del registro de seguridad o modifique la directiva de forma que el sistema no se colapse cuando se llene el registro de seguridad. Utilice el siguiente procedimiento para definir la configuración del registro de seguridad en la Directiva de grupo: Para modificar la configuración del Registro de sucesos con la Directiva de grupo en una unidad organizativa Haga clic en Inicio, seleccione Herramientas administrativas y, a continuación, Usuarios y equipos de Active Directory. En el árbol de la consola, haga clic con el botón secundario del mouse (ratón) en la unidad organizativa en la que desea definir la directiva de auditoría y, a continuación, haga clic en Propiedades. Seleccione la ficha Directiva de grupo, seleccione el Objeto de directiva de grupo que desea modificar y, a continuación, haga clic en Modificar. En el Editor de directivas de grupo, desplácese a Computer Configuration\Windows Settings\Security Settings\Event Logs\Settings for Event Logs. Modifique la configuración en función de sus necesidades. Si quita la configuración del Visor de sucesos de la Directiva de grupo, puede definirla directamente en el Visor de sucesos. No obstante, se recomienda que defina la configuración del Visor de sucesos en la Directiva de grupo para garantizar la coherencia de la configuración en todos los equipos similares. Sucesos para auditar Windows 2000 incluye varias categorías de auditoría para los sucesos de seguridad. Al diseñar la estrategia de auditoría de la empresa, deberá decidir si va a incluir las siguientes categorías de sucesos de auditoría de seguridad: Sucesos de inicio de sesi ón. Sucesos de inicio de sesi ón de cuentas. Acceso a objetos. Acceso del servicio de directorio. Uso de privilegios. Seguimient o de procesos. Sucesos del sistema. 172 Cambio de directivas. En los apartados siguientes se describen en detalle algunos de los Id. de suceso más comunes que se devuelven al activar la auditoría para categorías específicas. Nota: Las herramientas utilizadas para buscar y obtener información del registro de sucesos se tratan en el apartado "Métodos de detección pasivos" más adelante en este capítulo. Sucesos de inicio de sesión Si audita sucesos de inicio de sesión, cada vez que un usuario inicie o cierre la sesión en un equipo, se generará un suceso en el registro de seguridad del equipo en que se produce el intento de inicio de sesión. Además, cuando un usuario se conecta a un servidor remoto, se genera un suceso de inicio de sesión en el registro de seguridad del servidor remoto. Los sucesos de inicio de sesión se generan cuando se crean o destruyen respectivamente la sesión y el testigo de inicio de sesión. Los sucesos de inicio de sesión pueden resultar útiles para realizar un seguimiento de los intentos de inicio de sesión interactivo en servidores o para investigar los ataques iniciados desde un equipo determinado. Las auditorías de aciertos generan una entrada de auditoría cuando un intento de inicio de sesión es efectivo. Las auditorías de errores generan una entrada de auditoría cuando un intento de inicio de sesión es infructuoso. Nota: Los sucesos de inicio de sesión incluyen tanto sucesos de inicio de sesión de equipos como de usuarios. Comprobará que existen entradas de registro de sucesos de seguridad independientes para la cuenta del equipo y la cuenta del usuario cuando se intenta realizar una conexión a la red desde un equipo basado en Windows NT o Windows 2000. Los equipos basados en Windows 9x no tienen cuentas de equipo en el directorio y no generan entradas de registro de sucesos de inicio de sesión de equipos para sucesos de inicio de sesión de red. Como parte de las directivas de línea de base para servidores miembros y controladores de dominio, la auditoría de aciertos y errores de sucesos de inicio de sección se encuentra activada. Por lo tanto, verá los siguientes Id. de suceso para inicios de sesión interactivos e inicios de sesión de los Servicios de Terminal Server que se conectan a equipos que ejecutan los Servicios de Terminal Server. Tabla 6.1.: Sucesos de inicio de sesión que aparecen en el Registro de Sucesos. Id. de suceso Descripción 528 Un usuario inició la sesión correctamente en un equipo. 529 El intento de inicio de sesión se realizó con un nombre de usuario desconocido o con un nombre de usuario conocido y una contraseña incorrecta. 530 La cuenta de usuario intentó iniciar la sesión fuera del período de tiempo permitido. 531 Se produjo un intento de inicio de sesión con una cuenta desactivada 532 Se produjo un intento de inicio de sesión con una cuenta caducada 533 El usuario no tiene permiso para iniciar la sesión en este equipo. 173 534 El usuario intentó iniciar la sesión con un tipo de inicio de sesión no permitido (de red, interactivo, por lotes, de servicios o interactivo remoto). 535 La contraseña de la cuenta especificada ha caducado. 536 El servicio Inicio de sesión en la red no está activo. 537 Error del intento de inicio de sesión por otras razones 538 Un usuario cerró la sesión. 539 La cuenta se bloqueó cuando se intentó iniciar la sesión. Este suceso puede indicar un ataque de contraseñas infructuoso, lo que hace que se bloquee la cuenta. 540 Inicio de sesión en la red correcto. Este suceso indica que un usuario remoto se ha conectado correctamente de la red a un recurso local del servidor y que se ha generado un testigo para el usuario de red. 682 Un usuario se ha conectado de nuevo a una sesión de Servicios de Terminal Server desconectada. Este suceso indica la conexión a una sesión anterior de Servicios de Terminal Server. 683 Un usuario ha desconectado la sesión de Servicios de Terminal Server sin cerrarla primero. Este suceso se genera cuando un usuario está conectado a una sesión de Servicios de Terminal Server en la red. Aparece en Terminal Server. Los siguientes sucesos de seguridad pueden diagnosticarse por medio de entradas de sucesos de inicio de sesión: Intentos de inicio de sesión local infructuosos. Cualquiera de los siguientes Id. de suceso indica intentos de inicio de sesión infructuosos: 529, 530, 531, 532, 533, 534 y 537. Verá los sucesos 529 y 534 si un atacante intenta adivinar una combinación de nombre de usuario y contraseña para una cuenta local y no lo consigue. No obstante, estos sucesos también pueden producirse cuando un usuario se olvida de la contraseña o empieza a explorar la red por medio de Mis sitios de red. En un entorno de grandes dimensiones, puede resultar difícil interpretar correctamente estos sucesos. Como norma general, se deberá investigar estas pautas si se producen de forma repetida o coinciden con otros factores poco habituales. Por ejemplo, varios sucesos 529 seguidos por un suceso 528 durante la noche podrían indicar un ataque de contraseñas efectivo (aunque podría ser simplemente un administrador demasiado cansado). Uso incorrecto de cuentas. Los sucesos 530, 531, 532 y 533 pueden representar el uso incorrecto de una cuenta de usuario. Los sucesos indican que se introdujo correctamente la combinación de cuenta y contraseña, pero que otras restricciones no permiten el inicio de sesión correcto. Siempre que sea posible, deberá investigar estos sucesos para determinar si se ha utilizado incorrectamente una cuenta o si se deben modificar las restricciones actuales. Por ejemplo, es posible que necesite ampliar las horas de inicio de sesión de determinadas cuentas. Bloqueos de cuentas. El suceso 539 indica que se bloqueó una cuenta. Puede ser indicativo de un ataque de contraseñas infructuoso. Deberá buscar sucesos 529 anteriores de la misma cuenta de usuario para averiguar la pauta de intentos de inicio de sesión. Ataques de los Servicios de Terminal Server. Las sesiones de los Servicios de Terminal Server pueden dejarse conectadas de forma que los procesos puedan continuar ejecutándose tras el 174 cierre de la sesión. El Id. de suceso 683 indica cuándo un usuario no cierra la sesión de Servicios de Terminal Server y el Id. de suceso 682 indica cuándo alguien se conecta a una sesión previamente desconectada. Sucesos de inicio de sesión de cuentas Cuando un usuario inicia la sesión en un dominio, el inicio de sesión se procesa en un controlador de dominio. Si audita sucesos de inicio de sesión de cuentas en controladores de dominio, verá este intento de inicio de sesión registrado en el controlador de dominio que valida la cuenta. Los sucesos de inicio de sesión de cuentas se crean cuando un paquete de autenticación valida las credenciales de un usuario. Al utilizar credenciales de dominio, los sucesos de inicio de sesión de cuentas se generan únicamente en los registros de sucesos de los controladores de dominio. Si las credenciales presentadas son credenciales de base de datos SAM locales, entonces los sucesos de inicio de sesión de cuentas se crean en el registro de sucesos de seguridad del servidor. Puesto que el suceso de inicio de sesión de cuentas puede registrarse en cualquier controlador de dominio válido del dominio, deberá asegurarse de consolidar el registro de seguridad en todos los controladores de dominio para analizar todos los sucesos de inicio de sesión de cuentas del dominio. Nota: Al igual que los sucesos de inicio de sesión, los sucesos de inicio de sesión de cuentas incluyen tanto sucesos de inicio de sesión de equipos como de usuarios. Como parte de las directivas de línea de base para servidores miembros y controladores de dominio, la auditoría de aciertos y errores de sucesos de inicio de sección de cuentas se encuentra activada. Por lo tanto, verá los siguientes Id. de suceso para inicios de sesión de red y la autenticación de los Servicios de Terminal Server. Tabla 6.2.: Sucesos de inicio de sesión de cuentas que aparecen en el Registro de sucesos. Id. de suceso Descripción 672 Se emitió y validó correctamente un tíquet del servicio de autenticación (AS). 673 Se concedió un tíquet del servicio de concesión de tíquets (TGS). 674 Un principal de seguridad renovó un tíquet del AS o del TGS. 675 Error de preautenticación. 676 Error de la petición de tíquet de autenticación. 677 No se concedió un tíquet del TGS. 678 Se asignó correctamente una cuenta a una cuenta de dominio. 680 Identifica la cuenta utilizada para el intento de inicio de sección efectivo. Este suceso también indica el paquete de autenticación que se utilizó para autenticar la cuenta. 681 Se intentó llevar a cabo un inicio de sesión de cuenta de dominio. 682 Un usuario se ha conectado de nuevo a una sesión de Servicios de Terminal Server 175 desconectada. 683 Un usuario ha desconectado la sesión de Servicios de Terminal Server sin cerrarla primero. Para cada uno de estos sucesos, el registro de sucesos muestra información detallada acerca de cada inicio de sesión concreto. Los siguientes sucesos de seguridad pueden diagnosticarse por medio de entradas de sucesos de inicio de sesión de cuentas: Intentos de inicio de sesión de dominio infructuosos. Los Id. de suceso 675 y 677 indican intentos infructuosos de inicio de sesión en el dominio. Problemas de sincronización temporal. Si la hora del equipo de un cliente difiere de la del controlador de dominio de autenticación en más de cinco minutos (de forma predeterminada), aparecerá el Id. de suceso 675 en el registro de seguridad. Ataques de los Servicios de Terminal Server. Las sesiones de los Servicios de Terminal Server pueden dejarse conectadas de forma que los procesos puedan continuar ejecutándose tras el cierre de la sesión de Terminal Server. El Id. de suceso 683 indica cuándo un usuario no cierra la sesión de Servicios de Terminal Server y el Id. de suceso 682 indica cuándo alguien se conecta a una sesión previamente desconectada. Para evitar las desconexiones o cerrar las sesiones desconectadas, defina el intervalo de tiempo para finalizar la sesión desconectada en la consola de configuración de los Servicios de Terminal Server, en las propiedades del protocolo RDPTCP. Administración de cuentas La auditoría de la administración de cuentas sirve para determinar cuándo se crean, modifican o eliminan los usuarios o grupos. Esta auditoría puede utilizarse para determinar cuándo se creó un principal de seguridad y quién realizó la tarea. Como parte de las directivas de línea de base para servidores miembros y controladores de dominio, la auditoría de aciertos y errores de la administración de cuentas se encuentra activada. Por lo tanto, verá los siguientes Id. de suceso registrados en el registro de seguridad. Tabla 6.3.: Sucesos de administración de cuentas que aparecen en el Registro de Sucesos. Id. de suceso Descripción 624 Cuenta de usuario creada 625 Cambio de tipo de cuenta de usuario 626 Cuenta de usuario habilitada 627 Intento de cambio de contraseña 628 Contraseña de cuenta de usuario establecida 629 Cuenta de usuario deshabilitada 630 Cuenta de usuario eliminada 176 631 Grupo global habilitado de seguridad creado 632 Miembro de grupo global habilitado de seguridad agregado 633 Miembro de grupo global habilitado de seguridad eliminado 634 Grupo global habilitado de seguridad eliminado 635 Grupo local deshabilitado de seguridad creado 636 Miembro de grupo local habilitado de seguridad agregado 637 Miembro de grupo local habilitado de seguridad eliminado 638 Grupo local habilitado de seguridad eliminado 639 Grupo local habilitado de seguridad modificado 641 Grupo global habilitado de seguridad modificado 642 Cuenta de usuario modificada 643 Directiva de dominio cambiada 644 Cuenta de usuario bloqueada Los siguientes sucesos de administración de cuentas pueden diagnosticarse por medio de entradas del registro de seguridad: Creación de una cuenta de usuario. Los Id. de suceso 624 y 626 identifican cuándo se crean y activan las cuentas de usuario. Si la creación de cuentas se limita a determinados usuarios de la organización, puede utilizar estos sucesos para identificar cuentas de usuario creadas por personal no autorizado. Contraseña de cuenta de usuario modificada. La modificación de una contraseña por parte de alguien que no sea el usuario puede indicar que otro usuario ha tomado posesión de la cuenta. Busque los Id. de suceso 627 y 628, que indican una tentativa de modificación de la contraseña efectiva. Examine los detalles para determinar si otra cuenta realizó la modificación y si la cuenta pertenece al servicio de asistencia o a otro equipo de servicios que restablece las contraseñas de las cuentas de usuario. Estado de cuenta de usuario modificado. Un atacante puede intentar evitar dejar rastro por medio de la desactivación o eliminación de la cuenta utilizada durante un ataque. Todas las instancias de los Id. de suceso 629 y 630 deberán investigarse para comprobar que se trata de transacciones autorizadas. Busque también el Id. de suceso 626 seguido por el Id. de suceso 629 un poco más adelante. Esto puede indicar que se activó, utilizó y volvió a desactivar una cuenta desactivada. Modificación de grupos de seguridad. Deberán examinarse las modificaciones de los miembros de Administradores del dominio, Administradores o cualquiera de los grupos de operadores o de grupos globales, universales o locales de dominio personalizados a los que se les hayan delegado funciones administrativas. Para las modificaciones de los miembros de grupos 177 globales, busque los Id. de suceso 632 y 633. Para las modificaciones de los miembros de grupos locales, busque los Id. de suceso 636 y 637. Bloqueo de cuentas. Cuando se bloquea una cuenta, se registran dos sucesos en el maestro de operaciones del emulador del PDC. El suceso 644 indica que se bloqueó el nombre de cuenta y, a continuación, se registrará un suceso 642, que indica que la cuenta de usuario se ha modificado para indicar que la cuenta está ahora bloqueada. Este suceso sólo se registra en el emulador del PDC. Acceso a objetos La auditoría puede activarse para todos los objetos de una red basada en Windows 2000 con una lista de control de acceso al sistema (SACL). La SACL contiene una lista de usuarios y grupos para los que se deben auditar acciones realizadas en el objeto. Casi todos los objetos que puede manipular un usuario en Windows 2000 disponen de una SACL. Ésta incluye archivos y carpetas de unidades NTFS, impresoras y claves de registro. Está compuesta de entradas de control de acceso (ACE). Cada ACE contiene tres tipos de información: El principal de seguridad que se debe auditar Los tipos de acceso espec íficos que se deben auditar (lo que se denomina máscara de acceso) Un indicador acerca de si se deben auditar los accesos infructuosos, los accesos eficaces o ambos. Si desea que los sucesos aparezcan en el Registro de Seguridad, primero deberá activar Auditar el acceso a objetos y, a continuación, definir la SACL para cada objeto que desea auditar. Las auditorías de Windows 2000 se generan cuando se abre un identificador de objeto. Windows 2000 utiliza un subsistema de seguridad del modo de núcleo que sólo permite a los programas obtener acceso a objetos por medio del núcleo. De este modo, se impide que los programas intenten evitar el sistema de seguridad. Puesto que el espacio de memoria del núcleo se encuentra aislado de los programas en modo de usuario, los programas hacen referencia a los objetos por medio de una estructura de datos denominada identificador. A continuación, se muestra una tentativa de acceso típica: 1. Un usuario ordena a un programa que obtenga acceso a un objeto (por ejemplo, Archivo/Abrir). 2. El programa solicita al sistema un identificador y especifica el tipo de acceso deseado (lectura, escritura, etc.). 3. El subsistema de seguridad compara la DACL del objeto solicitado con el testigo del usuario y busca entradas de la DACL que coincidan con el usuario o un grupo al que pertenezca el usuario y que también tengan los derechos de acceso solicitados por el programa. 4. El sistema compara la SACL del objeto solicitado con el testigo del usuario y busca entradas de la SACL que coincidan con los derechos efectivos que se devuelven al programa, o bien con los derechos solicitados por el programa. Si una ACE de auditoría de errores coincide con un acceso que se solicitó pero no se concedió, se genera un suceso de auditoría de error. Si una ACE 178 de auditoría de aciertos coincide con un acceso que se concedió, se genera un suceso de auditoría de acierto. 5. Si se concede un acceso, el sistema devuelve un identificador al programa, que entonces puede utilizar el identificador para obtener acceso al objeto. Es importante tener en cuenta que, cuando se produce la auditoría y se genera el suceso, todavía no se ha producido ninguna modificación en el objeto. Esto resulta de importancia vital a la hora de interpretar sucesos de auditoría. Las auditorías de escritura se generan antes de que se escriba en el archivo y las auditorías de lectura se generan antes de que se lea el archivo. Al igual que en todas las auditorías, es muy importante adoptar un enfoque centrado en la auditoría de acceso a objetos. En su plan de auditoría, decida el tipo de objetos que debe auditar y, a continuación, determine el tipo de tentativas de acceso (acierto, error o ambos) que desea supervisar para cada tipo de objeto auditado. Un enfoque demasiado amplio en la auditoría tendrá un impacto considerable en el rendimiento del sistema y tendrá como consecuencia la recopilación de mucha más información de la que resulta necesaria o útil. En general, convendrá que audite todos los accesos a los objetos seleccionados, incluidos los accesos desde cuentas que no sean de confianza. Para ello, agregue el grupo Todos a la SACL de los objetos que desea auditar. Deberá ser precavido a la hora de auditar los aciertos de acceso a objetos, puesto que pueden generarse muchas entradas de auditoría en el registro de seguridad. No obstante, si por ejemplo está investigando la eliminación de un archivo crítico, deberá examinar los sucesos de auditoría de acierto para determinar la cuenta de usuario que eliminó el archivo. Las directivas directivas de línea de base para servidores miembros y controladores de dominio están configuradas para auditar tanto los aciertos como los errores de acceso a objetos. No obstante, no se configura ninguna SACL en los objetos y deberá configurarlas en función de las necesidades del entorno. Las SACL pueden definirse directamente en los objetos o mediante la Directiva de grupo. Si el objeto que requiere la auditoría existe en varios equipos, deberá definir las SACL en la Directiva de grupo. La auditoría del acceso a objetos hará que aparezcan los siguientes sucesos en el registro de seguridad. Tabla 6.4.: Sucesos de acceso a objetos que aparecen en el Registro de sucesos. Id. de suceso Descripción 560 Se concedió acceso a un objeto ya existente. 562 Se cerró un identificador de un objeto. 563 Se intentó abrir un objeto con la intención de eliminarlo (utilizado por los sistemas de archivos cuando se especifica el indicador FILE_DELETE_ON_CLOSE). 564 Se eliminó un objeto protegido. 565 Se concedió acceso a un tipo de objeto ya existente. 179 Si busca sucesos de acceso a objetos específicos, deberá investigar principalmente los sucesos con el Id. 560. La información útil se incluye con los detalles del suceso, en los que necesitará realizar búsquedas para encontrar los sucesos específicos que busca. En la tabla 6.5. se muestran algunas acciones que puede que necesite llevar a cabo y cómo realizarlas. Tabla 6.5.: Cómo llevar a cabo acciones de auditoría clave para el suceso de acceso a objetos 560. Acción de auditoría Método Buscar un archivo, carpeta u objeto específico En los detalles del suceso 560, busque la ruta de acceso completa del archivo o la carpeta para los que desea revisar las acciones. Determinar específico usuario Defina un filtro que identifique el usuario específico en un suceso 560. Determinar acciones realizadas en un equipo específico Defina un filtro que identifique la cuenta de equipo específica en la que se realizó la tarea en un suceso 560. acciones de un Acceso del servicio de directorio Los objetos de Active Directory tienen SACL asociadas y, por lo tanto, pueden auditarse. Tal y como se mencionó anteriormente, para auditar las cuentas de usuario y de grupo de Active Directory, deberá auditar la Administración de cuentas. No obstante, si desea auditar la modificación de objetos en otros contextos de nombres, como los de configuración y de esquema, deberá auditar el acceso a objetos y, a continuación, definir la SACL para los contenedores específicos que desea auditar. Las entradas de auditoría se generan cuando los usuarios que figuran en la SACL de un objeto de Active Directory intentan obtener acceso al objeto. Puede modificar la SACL de contenedores y objetos en el contexto de nombres de configuración (y en otros contextos de nombres) por medio del complemento de MMC ADSIEDIT. Para ello, muestre el contexto requerido en la consola ADSIEDIT y, a continuación, modifique la SACL del objeto en el cuadro de diálogo Configuración de seguridad avanzada. Resulta muy difícil encontrar sucesos específicos para el acceso a servicios de directorio, debido al gran volumen de sucesos (normalmente inofensivos) que se producen. Por esta razón, las directivas de línea de base para servidores miembros y controladores de dominio sólo auditan sucesos de error para el acceso a servicios de directorio. Esto le ayudará a identificar cuándo un atacante intenta obtener acceso no autorizado a Active Directory. Las tentativas de acceso al directorio aparecerán como un suceso de servicios de directorio con el Id. 565 en el registro de seguridad. Sólo podrá determinar el objeto al que corresponde el suceso al examinar los detalles del suceso de seguridad. Uso de privilegios Los usuarios que trabajan en un entorno de TI ejercitan derechos de usuario definidos. Si audita los aciertos y errores del uso de privilegios, se generará un suceso cada vez que un usuario intente ejercer un derecho de usuario. 180 Incluso si se audita el uso de privilegios, no se auditarán todos los derechos de usuario. Los siguientes derechos de usuario se excluyen de forma predeterminada: No usar comprobaci ón de desvío. Depurar programas. Crear un objeto testigo. Reemplazar un testigo a nivel de proceso. Generar auditor ías de seguridad. Realizar copias de seguridad de archivos y directorios. Restaurar archivos y directorios. Puede omitir el comportamiento predeterminado de no auditar los derechos de usuario de copia de seguridad y restauración si activa la opción de seguridad Auditar el uso del privilegio de copia de seguridad y restauración de la Directiva de grupo. La auditoría de aciertos del uso de privilegios creará un alto número de entradas en el registro de seguridad. Por esta razón, las directivas de línea de base para servidores miembros y controladores de dominio sólo auditan sucesos de error del uso de privilegios. Cuando la auditoría del uso de privilegios está activada, se generan los siguientes sucesos. Tabla 6.6.: Sucesos de uso de privilegios que aparecen en el Registro de Sucesos. Id. de suceso Descripción 576 Se agregaron privilegios específicos al testigo de acceso de un usuario (este evento se genera cuando el usuario inicia la sesión). 577 Un usuario intentó realizar una operación de servicios del sistema privilegiada. 578 Se utilizaron privilegios en un identificador ya abierto de un objeto protegido. A continuación, figuran ejemplos de algunas de las entradas del registro de suceso que pueden aparecer cuando se utilizan derechos de usuario específicos. Actuar como parte del sistema operativo. Busque el Id. de suceso 577 o 578 con el privilegio SeTcbPrivilege indicado. La cuenta de usuario que ha utilizado este derecho de usuario está identificada en los detalles del suceso. Este suceso puede indicar la tentativa de un usuario de elevar los privilegios de seguridad actuando como parte del sistema operativo. Por ejemplo, el ataque GetAdmin, en el que un usuario intenta agregar su cuenta al grupo de administradores, utiliza este privilegio. Las únicas entradas de este suceso deberían referirse a la cuenta del sistema y a las cuentas de servicio a las que se haya asignado este derecho de usuario. Cambiar la hora del sistema. Busque el Id. de suceso 577 o 578 con el privilegio SeSystemtimePrivilege indicado. La cuenta de usuario que ha empleado el derecho de usuario 181 está identificada en los detalles del suceso. Este suceso puede indicar la tentativa de un usuario de modificar la hora del sistema para ocultar la hora real en la que se produce un suceso. Exigir el cierre del sistema desde un sistema remoto. Busque los Id. de suceso 577 y 578 con el derecho de usuario SeRemoteShutdownPrivilege. El identificador de seguridad (SID) específico al que está asignado el derecho de usuario y el nombre de usuario del principal de seguridad que asignó el derecho están incluidos en los detalles del suceso. Cargar y descargar controladores de dispositivos. Busque el Id. de suceso 577 o 578 con el privilegio SeLoadDriverPrivilege indicado. La cuenta de usuario que ha utilizado este derecho de usuario está identificada en los detalles del suceso. Este suceso puede indicar la tentativa de un usuario de cargar un controlador de dispositivos no autorizado o una versión caballo de Troya del mismo. Administrar registros de auditoría y seguridad. Busque el Id. de suceso 577 o 578 con el privilegio SeSecurityPrivilege indicado. La cuenta de usuario que ha utilizado este derecho de usuario está identificada en los detalles del suceso. Este suceso se produce tanto cuando se limpia el registro como cuando se escriben los sucesos del uso de privilegios en el registro de seguridad. Apagar el sistema. Busque el Id. de suceso 577 con el privilegio SeShutdownPrivilege indicado. La cuenta de usuario que ha utilizado este derecho de usuario está identificada en los detalles del suceso. Este suceso se produce cuando se intenta apagar el equipo. Tomar posesión de archivos u otros objetos. Busque el Id. de suceso 577 o 578 con el privilegio SeTakeOwnershipPrivilege indicado. La cuenta de usuario que ha empleado el derecho de usuario está identificada en los detalles del suceso. Este suceso puede indicar que un atacante está intentando tomar posesión de un objeto para omitir la configuración de seguridad actual. Seguimiento de procesos Si audita información de seguimiento detallada de procesos que se ejecutan en equipos basados en Windows 2000, el registro de suceso mostrará intentos de creación y detención de procesos. También registrará si un proceso intenta generar un identificador para un objeto u obtener acceso indirecto a un objeto. Debido al alto número de entradas de auditoría creadas, las directivas de línea de base para servidores miembros y controladores de dominio no permiten la auditoría para el seguimiento de procesos. No obstante, si decide auditar aciertos y errores, aparecerán los siguientes Id. de suceso en el registro de sucesos. Tabla 6.7.: Sucesos de seguimiento de procesos que aparecen en el Registro de Sucesos. Id. suceso de Descripción 592 Se creó un nuevo proceso. 593 Se cerró un proceso. 594 Se duplicó un identificador de un objeto. 182 595 Se obtuvo acceso indirecto a un objeto. Sucesos del sistema Los sucesos del sistema se generan cuando un usuario o proceso modifica aspectos del entorno informático. Puede auditar los intentos de modificación del sistema, como cerrar el equipo o cambiar la hora del sistema. Si audita sucesos del sistema, también se audita cuándo se limpia el registro de seguridad. Esto es muy importante, porque a menudo los atacantes intentan borrar su rastro tras haber modificado un entorno. Las directivas de línea de base para servidores miembros y controladores de dominio auditan sucesos del sistema de aciertos y de errores. De este modo, se generarán los siguientes Id. de suceso en el registro de sucesos. Tabla 6.8.: Sucesos del sistema que aparecen en el Registro de Sucesos. Id. suceso de Descripción 512 Windows se está iniciando. 513 Windows se está cerrando. 514 La Autoridad de seguridad local cargó un paquete de autenticación. 515 La Autoridad de seguridad local ha registrado un proceso de inicio de sesión por confianza. 516 Se han agotado los recursos internos asignados a la cola de mensajes de sucesos de seguridad, lo que ha provocado la pérdida de algunos mensajes de sucesos de seguridad. 517 Se limpió el registro de seguridad. 518 El Administrador de cuentas de seguridad cargó un paquete de notificación. Puede utilizar estos Id. de suceso para localizar varios problemas de seguridad: Cierre o reinicio del equipo. El Id. de suceso 513 muestra el cierre de Windows. Es importante saber cuándo se apagan o reinician los servidores. Existen varias razones legítimas, como cuando se instala un controlador o una aplicación que requiere el reinicio o cuando se apaga o reinicia el servidor para realizar tareas de mantenimiento. No obstante, también es posible que un atacante fuerce el reinicio de un servidor para obtener acceso al sistema durante el inicio. Deberán tenerse en cuenta todos los casos en que se apaga el equipo para compararlos con el registro de sucesos. En muchos ataques se reinicia el equipo. Examinando los registros de sucesos, puede determinarse cuándo se ha reiniciado un servidor y si el reinicio se había planeado o no. El Id. de suceso 513 muestra el inicio de Windows, al igual que varios otros sucesos que se generan automáticamente en el registro del sistema. Entre ellos figura el Id. de suceso 6005, que indica el inicio del servicio Registro de Sucesos. 183 Además de esta entrada, compruebe si existen una o dos entradas del registro de sucesos distintas en el registro del sistema. Si el anterior cierre del sistema se produjo normalmente, como cuando un administrador reinicia el equipo, entonces se muestra en el registro del sistema el Id. de suceso 6006: "Se ha detenido el servicio de Registro de sucesos". Puede determinar el usuario que inició el cierre del sistema si examina los detalles de la entrada. Si el reinicio fue inesperado, se registra el Id. de suceso 6008: "El cierre anterior del sistema a las <hora> del <fecha> resultó inesperado". Esto puede indicar un ataque de denegación de servicio que provocó el cierre del equipo. Tenga en cuenta que también puede deberse a una interrupción del suministro eléctrico o a un error de controladores de dispositivos. Si el reinicio lo causó una pantalla azul, se muestra en el registro del sistema un Id. de suceso 1001, con un origen de descarga de guardado. El mensaje de error de la pantalla azul puede examinarse en los detalles del suceso. Nota: Para incluir el registro de entradas del Id. de suceso 1001, deberá estar activada la casilla de verificación Grabar un suceso en el registro del sistema en la sección de configuración de recuperación del subprograma Panel de control del sistema. Modificar o limpiar el registro de seguridad. Es posible que un atacante intente modificar los registros de seguridad, desactivar la auditoría durante un ataque o limpiar el registro de seguridad para evitar su detección. Si detecta bloques de tiempo grandes sin entradas en el registro de seguridad, deberá buscar los Id. de suceso 612 y 517 para determinar el usuario que modificó la directiva de auditoría. Todas las instancias del Id. de suceso 517 deberán compararse con un registro físico que indique todas las ocasiones en que se limpió el registro de seguridad. La limpieza no autorizada del registro de seguridad puede ser un intento de ocultar sucesos que existieron en el registro de seguridad anterior. El nombre del usuario que limpió el registro se incluye en los detalles del suceso. 608 Se asignó un derecho de usuario. 609 Se eliminó un derecho de usuario. 610 Se creó una relación de confianza con otro dominio. 611 Se eliminó una relación de confianza con otro dominio. 612 Se modificó una directiva de auditoría. 768 Se detectó una colisión entre un elemento del espacio de nombres de un bosque y un elemento del espacio de nombres de otro bosque (sucede cuando un elemento del espacio de nombres de un bosque se superpone a un elemento del espacio de nombres de otro bosque). Los dos sucesos más importantes que se deben buscar en este caso son los Id. de suceso 608 y 609. Si se producen varios intentos de ataque, es posible que se registren estos sucesos. Todos los ejemplos siguientes generarán el Id. de suceso 608 si se asigna el derecho de usuario o el Id. de suceso 609 si se elimina el derecho de usuario. En cada caso, el SID específico al que está asignado el derecho de usuario y el nombre de usuario del principal de seguridad que asignó el derecho están incluidos en los detalles del suceso: Actuar como parte del sistema operativo. Busque los Id. de suceso 608 y 609 con el derecho de usuario SeTcbPrivilege en los detalles del suceso. 184 Agregar estaciones de trabajo al dominio. Busque los sucesos con el derecho de usuario SeMachineAccountPrivilege en los detalles del suceso. Realizar copias de seguridad de archivos y directorios. Busque los sucesos con el derecho de usuario SeBackupPrivilege en los detalles del suceso. No usar comprobación de desvío. Busque los sucesos con el derecho de usuario SeChangeNotifyPrivilege en los detalles del suceso. Este derecho de usuario permite a los usuarios recorrer un árbol de directorios, incluso si el usuario no dispone de otros permisos de acceso al directorio. Cambiar la hora del sistema. Busque los sucesos con el derecho de usuario SeSystemtimePrivilege en los detalles del suceso. Este derecho de usuario permite a un principal de seguridad modificar la hora del sistema, de forma que se podría ocultar la hora en que se produce un suceso. Crear objetos permanentes compartidos. Busque los sucesos con el derecho de usuario SeCreatePermanentPrivilege en los detalles del suceso. El poseedor de este derecho de usuario puede crear recursos compartidos de archivos y de impresión. Depurar programas. Busque los sucesos con el derecho de usuario SeDebugPrivilege en los detalles del suceso. El poseedor de este derecho de usuario puede conectarse a cualquier proceso. De forma predeterminada, este derecho sólo se asigna a administradores. Exigir el cierre del sistema desde un sistema remoto. Busque los sucesos con el derecho de usuario SeRemoteShutdownPrivilege en los detalles del suceso. Aumentar la prioridad de programación. Busque los sucesos con el derecho de usuario SeIncreaseBasePriorityPrivilege en los detalles del suceso. Un usuario con este derecho puede modificar las prioridades de procesos. Cargar y descargar controladores de dispositivos. Busque los sucesos con el derecho de usuario SeLoadDriverPrivilege en los detalles del suceso. Un usuario con este derecho de usuario puede cargar una versión caballo de Troya de un controlador de dispositivos. Administrar registros de auditoría y seguridad. Busque los sucesos con el derecho de usuario SeSecurityPrivilege en los detalles del suceso. Un usuario con este derecho de usuario puede ver y limpiar el registro de seguridad. Reemplazar un testigo a nivel de proceso. Busque los sucesos con el derecho de usuario SeAssignPrimaryTokenPrivilege en los detalles del suceso. Un usuario con este derecho de usuario puede cambiar el testigo predeterminado asociado con un subproceso iniciado. Restaurar archivos y directorios. Busque los sucesos con el derecho de usuario SeRestorePrivilege en los detalles del suceso. Apagar el sistema. Busque los sucesos con el derecho de usuario SeShutdownPrivilege en los detalles del suceso. Un usuario con este derecho de usuario puede apagar el sistema para inicializar la instalación de un nuevo controlador de dispositivos. Tomar posesión de archivos u otros objetos. Busque los sucesos con el derecho de usuario SeTakeOwnershipPrivilege en los detalles del suceso. Un usuario con este derecho de usuario puede obtener acceso a cualquier objeto o archivo de un disco NTFS si toma posesión del objeto o archivo. 185 Nota: Estos sucesos de auditoría solamente identifican que se asignó el derecho de usuario a un principal de seguridad específico. No implica que el principal de seguridad haya realizado una tarea con el derecho de usuario. Los sucesos de auditoría sí que determinan cuándo se modificó la directiva de derechos de usuario. Nota: Para obtener más información acerca de cómo utilizar los derechos de usuario, consulte "Writing Secure Code" de Michael Howard y David LeBlanc (Microsoft Press, ISBN: 0-73561588-8) (en inglés). Proteger registros de sucesos Para garantizar que se mantengan las entradas de los registros de sucesos como información de referencia para el futuro, deberá adoptar varias medidas con el fin de proteger la seguridad de los registros de sucesos. Éstas incluyen: Definir una directiva para el almacenamiento, la sobrescritura y el mantenimiento de todos los registros de sucesos. La directiva deberá definir todas las opciones de configuración necesarias de registros de sucesos y la Directiva de grupo deberá hacer que se cumpla. Asegurarse de que la directiva incluya el tratamiento de registros de sucesos completos, en concreto el registro de seguridad. Se recomienda que los registros de seguridad completos requieran que se apague el servidor. Esto puede no resultar práctico en algunos entornos, pero debería tomarse en consideración. Evitar el acceso de invitado a los registros de sucesos activando la configuraci ón de la directiva de seguridad para evitar así que los invitados locales obtengan acceso a los registros del sistema, de aplicaciones y de seguridad. Asegurarse de que se auditan tanto los aciertos como los errores de los sucesos del sistema para determinar si se producen intentos de eliminación del contenido del registro de seguridad. Todos los principales de seguridad que pueden ver o modificar la configuración de auditoría deberán utilizar contraseñas complejas o métodos de autenticación de dos factores, como el inicio de sesión con tarjetas inteligentes, para evitar los ataques de estas cuentas con el objeto de obtener acceso a la información de auditoría. Todas estas opciones de seguridad se definen en los Objetos de directiva de grupo de servidores miembros y controladores de dominio que se describen en el capítulo 4, "Asegurar servidores basándose en su función". Además de estos pasos, deberá adoptar algunas medidas prácticas más para garantizar que la información de registros de sucesos sea lo más segura posible. El plan de seguridad debe incluir tambi én la seguridad física de todos los servidores para asegurarse de que ningún atacante puede obtener acceso físico al equipo en el que se está realizando la auditoría. Un atacante puede eliminar entradas de auditoría si modifica o elimina los archivos físicos *.evt del subsistema del disco local. Poner en pr áctica un método de eliminación o almacenamiento de los registros de sucesos en una ubicación independiente del servidor físico. Los métodos pueden consistir en el uso de Tareas programadas para escribir los registros de sucesos en un CDR o en un disco de una sola escritura, soportes de muchas lecturas a intervalos regulares o en otras ubicaciones de red independientes del servidor. Si las copias de seguridad se realizan en soportes externos como 186 cintas para copia de seguridad o CDR, deberán sacarse de las instalaciones si se produce un incendio u otro desastre natural. Nota: Al prohibir el acceso de invitados a los registros de sucesos, sólo se restringe el acceso a los registros de sucesos de los miembros que no pertenezcan al dominio. De forma predeterminada, todos los usuarios de un dominio pueden obtener acceso a los registros del sistema y de aplicaciones. Sólo está restringido el acceso al registro de seguridad. Los principales de seguridad a los que se les ha asignado el derecho de usuario Administrar registros de auditoría y seguridad pueden tener acceso al registro de seguridad. De forma predeterminada, este derecho sólo se asigna a los Administradores y Servidores empresariales de Exchange. Otras mejores prácticas de auditoría Además de la configuración de la auditoría, existen otras prácticas que deberán implementarse para auditar de forma eficaz la seguridad del entorno del servidor. Éstas incluyen: Programar revisiones regulares de los registros de sucesos. Revisar otros archivos de registro de aplicaciones. Supervisar los servicios y controladores instalados. Supervisar los puertos abiertos. Programar revisiones regulares de los registros de sucesos Tal y como se mencionó anteriormente, el registro de seguridad y potencialmente los otros registros de sucesos deberían escribirse en materiales extraíbles o consolidarse en una ubicación central para su revisión. La revisión de los registros es el paso de la auditoría que se suele omitir más a menudo. Deberá asegurarse de que una persona o un equipo adopte la revisión de los registros de sucesos como tarea habitual en su descripción de trabajo. La revisión de los registros de sucesos puede programarse como un suceso diario o semanal, en función de la cantidad de datos que se recojan en el registro de seguridad. Esto suele depender del nivel de auditoría aplicado en la red. Si se incluyen más sucesos en la auditoría, aumentará el volumen de entradas del registro. Si programa revisiones regulares del registro de sucesos, ayudará a conseguir lo siguiente: Detección más rápida de problemas de seguridad. Si se lleva a cabo la revisión diaria de los registros de sucesos, la antigüedad de un suceso de seguridad nunca superará las 24 horas. Esto acelera la detección y reparación de vulnerabilidades de seguridad. Definición de la responsabilidad. Si resulta necesaria la revisión regular de los registros de sucesos, la persona responsable de la tarea de revisar los archivos de registro puede ser responsable de la identificación de posibles ataques en última instancia. Reducción del riesgo de que se sobrescriban los sucesos o esté inactivo el servidor. Una vez revisado un registro de sucesos, los eventos del archivo de registro pueden almacenarse para futuras revisiones y eliminarse del registro de sucesos actual. De este modo, disminuye el riesgo de que se llenen los registros de sucesos. 187 Revisar otros archivos de registro de aplicaciones Además de revisar si existen sucesos de seguridad en los registros de sucesos de Windows 2000, deberá revisar también los registros creados por las aplicaciones. Estos registros de aplicaciones pueden contener información importante referente a posibles ataques que puede complementar la información encontrada en los registros de sucesos. En función del entorno, es posible que necesite revisar uno o varios de estos archivos de registro: Servicios de Internet Information Server (IIS). IIS crea archivos de registro que realizan un seguimiento de los intentos de conexión a los servicios Web, de FTP, del protocolo de tiempo de la red (NTP) y SMTP. Cada servicio que se ejecuta en IIS mantiene archivos de registro independientes y almacena los archivos de registro en el formato de archivo de registro extendido W3C en la carpeta %WinDir%\System32\Logfiles. Cada servicio mantiene una carpeta independiente para desglosar todavía más la información de registro. También puede configurar IIS para que almacene los registros en una base de datos compatible con ODBC, como Microsoft SQL Server. Internet Security and Acceleration (ISA) Server. ISA Server proporciona registros para filtros de paquetes, el servicio del servidor de seguridad de ISA Server y el servicio proxy Web de ISA Server. Al igual que en IIS, los registros se almacenan de forma predeterminada en el formato de archivo de registro extendido W3C, pero pueden registrarse también en una base de datos compatible con ODBC. Los archivos de registro de ISA Server están almacenados de forma predeterminada en la carpeta C:\Archivos de programa\Microsoft ISA Server\ISALogs. Servicio de autenticación de Internet (IAS). IAS proporciona autenticación y cuentas centralizadas para la autenticación de acceso remoto por medio del protocolo Servicio de usuario de acceso telefónico de autenticación remota (RADIUS). De forma predeterminada, las solicitudes de cuentas, de autenticación y de estado periódicas se registran en el archivo IASlog.log que se encuentra ubicado en la carpeta %WinDir%\System32\Logfiles. El archivo de registro también puede guardarse en un formato de archivo compatible con bases de datos en lugar del formato de IAS. Aplicaciones de terceros. Varias aplicaciones de terceros aplican funciones de registro local para proporcionar información detallada acerca de la aplicación. Para obtener más información, consulte los archivos de ayuda correspondientes a la aplicación. Nota: Todos los equipos que mantienen archivos de registro deben utilizar relojes sincronizados. Esto permite que un administrador pueda comparar sucesos entre equipos y servicios para establecer las acciones realizadas por un atacante. Para obtener más detalles acerca de la sincronización temporal, consulte el apartado "La importancia de la sincronización temporal" más adelante en este capítulo. Supervisar los servicios y controladores instalados Muchos ataques de equipos los llevan a cabo servicios de ataque instalados en el equipo de destino o se realizan reemplazando controladores válidos por versiones del controlador que incluyen un caballo de Troya y que permiten así al atacante obtener acceso al equipo de destino. Las siguientes herramientas pueden utilizarse para supervisar los servicios y controladores instalados en los equipos: La consola de servicios. La consola MMC de servicios se utiliza para supervisar los servicios de un equipo local o remoto y permite al administrador configurar, pausar, detener, iniciar y 188 reiniciar todos los servicios instalados. Con esta consola podrá determinar si no se han iniciado servicios configurados para iniciarse de forma automática. Netsvc.exe. Esta herramienta de la línea de comandos, incluida en Windows 2000 Server. Kit de recursos, permite al administrador iniciar, detener, pausar, continuar y consultar el estado de los servicios de forma remota desde la línea de comandos. SvcMon.exe. Esta herramienta supervisa los cambios de estado (inicio o detención) de servicios en equipos locales y remotos. Para detectar estos cambios, Service Monitoring Tool aplica un sistema de sondeo. Cuando se detiene o inicia un servicio supervisado, Service Monitoring Tool se lo notifica por correo electrónico. Deberá configurar los servidores, intervalos de sondeo y servicios que se van a supervisar por medio de Service Monitor Configuration Tool (smconfig.exe). Drivers.exe. Esta herramienta muestra todos los controladores de dispositivos instalados en el equipo en que se ejecuta la herramienta. La herramienta proporciona información como el nombre de archivo del controlador, el tamaño del controlador en disco y la fecha en la que se vinculó el controlador. La fecha de vinculación puede utilizarse para identificar controladores instalados recientemente. Si no se instaló recientemente un controlador actualizado, esto puede ser un indicio de que se ha reemplazado un controlador. Establezca siempre la correlación entre esta información y un suceso de reinicio del sistema del Visor de Sucesos. Nota: No se pueden detener directamente todos los servicios (como el servicio de Estación de Trabajo), aunque sí se pueden consultar. Si un usuario tiene muchas conexiones activas, no se puede forzar el cierre del servicio de forma remota, aunque se puede pausar o consultar. Algunos servicios tienen otros servicios que dependen de ellos y no podrá cerrarlos si no cierra primero los servicios dependientes. Supervisar los puertos abiertos Los ataques se inician a menudo con la detección de puertos para identificar servicios conocidos que se ejecutan en el equipo de destino. Deberá asegurarse de supervisar cuidadosamente los puertos que están abiertos en los servidores, lo que normalmente implica realizar una detección de los puertos para determinar aquellos a los que se puede tener acceso. Las detecciones de puertos deberán realizarse tanto de forma local, en el equipo de destino, como desde un equipo remoto. Si se puede obtener acceso al equipo desde una red pública, la detección de puertos deberá llevarse a cabo desde un equipo externo para garantizar que el software del servidor de seguridad permita solamente el acceso a los puertos deseados. Netstat.exe es una utilidad de la línea de comandos que puede mostrar todos los puertos abiertos tanto para TCP como para UDP. El comando Netstat utiliza la sintaxis siguiente: NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [intervalo] Donde: -a. Muestra todas las conexiones y puertos en escucha. -e. Muestra estadísticas Ethernet. Se puede combinar con la opción -s. -n. Muestra números de puertos y direcciones en formato numérico. 189 -p protocolo. Muestra conexiones del protocolo especificado por proto, que puede ser TCP o UDP. Si se usa con la opción -s para mostrar estadísticas por protocolo, proto puede ser TCP, UDP o IP. -r. Muestra el contenido de la tabla de rutas. -s. Muestra estadísticas por protocolo. De forma predeterminada, se pueden mostrar para TCP, UPD e IP; se puede utilizar la opción -p para especificar un subconjunto de la opción predeterminada. intervalo. Vuelve a mostrar las estadísticas seleccionadas, haciendo pausas con el intervalo de segundos especificado entre cada muestra. Presione CTRL+C para detener la muestra de estadísticas. Si se omite, netstat imprimirá la información de configuración actual una vez. Cuando se muestran los puertos TCP y UPD abiertos del equipo local, los números de puerto se convierten en nombres basados en las entradas del archivo de servicios ubicado en la carpeta \%WinDir%\System32\Drivers\Etc\. Si prefiere ver solamente los números de puerto, puede utilizar el modificador -n. Si se descubren puertos abiertos no reconocidos, deberá investigarlos para determinar si el servicio correspondiente resulta necesario en el equipo. De lo contrario, deberá desactivar o eliminar el servicio asociado para evitar que el equipo escuche en ese puerto. Se han desactivado varios servicios de las directivas de línea de base para servidores miembros y controladores de dominio incluidas en esta guía. Puesto que muchos servidores están protegidos por servidores de seguridad o enrutadores de filtrado de paquetes, se recomienda realizar además la detección de puertos desde un equipo remoto. Muchas herramientas de terceros (incluidos algunos programas freeware) pueden realizar detecciones remotas de puertos. La detección remota de puertos indica los puertos que se encuentran disponibles para usuarios externos cuando intentan conectarse al equipo. Nota: La detección de puertos también puede utilizarse para probar el sistema de detección de intrusiones y así garantizar que registra la detección de puertos mientras se está llevando a cabo. Para obtener más información acerca de los sistemas de detección de intrusiones, consulte el apartado "Métodos de detección activos" más adelante en este capítulo. Supervisar las intrusiones y los sucesos de seguridad La supervisión de intrusiones y sucesos de seguridad incluye tanto tareas activas como pasivas. Muchas intrusiones se detectan una vez se ha producido el ataque por medio de la inspección de los archivos de registro. La detección de ataques a posteriori se suele denominar detección de intrusiones pasiva. La inspección de los archivos de registro es la única forma en que se puede revisar y reconstruir el ataque en función de la información del registro. Otros intentos de intrusión pueden detectarse mientras se produce el ataque. Este método, denominado detección de intrusiones activa, busca pautas o comandos de ataque conocidos y bloquea la ejecución de esos comandos. En este apartado se explican las herramientas que pueden utilizarse para aplicar ambos tipos de detección de intrusiones y proteger a la red de ataques. 190 La importancia de la sincronización temporal Al supervisar tanto las intrusiones como los sucesos de seguridad entre varios equipos, es esencial que estén sincronizados los relojes de los equipos. La sincronización temporal permite al administrador reconstruir los ataques realizados en varios equipos. Sin sincronización temporal, resulta muy difícil determinar exactamente el momento en que se produjeron determinados sucesos y su interrelación. Para obtener más información acerca de la sincronización temporal, consulte el capítulo 3, "Administrar la seguridad con la Directiva de grupo de Windows 2000". Métodos de detección pasivos Los sistemas de detección de intrusiones pasivos implican la revisión manual de los registros de sucesos y aplicaciones. La inspección requiere el análisis y la detección de pautas de ataque en los datos de los registros de sucesos. Existen varias herramientas, utilidades y aplicaciones que pueden facilitar la revisión de los registros de sucesos. En este apartado se describe el uso de cada una de las herramientas para coordinar la información. Visor de sucesos El registro de seguridad de Windows 2000 puede examinarse por medio de la consola MMC del Visor de sucesos de Windows 2000. El Visor de sucesos le permite ver los registros de aplicaciones, de seguridad y del sistema. Puede definir filtros para encontrar sucesos específicos en el Visor de sucesos. Para definir filtros en el Visor de sucesos 1. Seleccione el registro de sucesos en cuestión en el árbol de la consola. 2. Seleccione Filtro en el menú Ver. 3. Seleccione los parámetros de filtrado. En la pestaña Filtro del cuadro de diálogo Propiedades, puede definir los siguientes atributos para filtrar entradas de sucesos: Tipos de suceso. El filtro puede limitarse a información, advertencias, errores, auditorías de aciertos, auditorías de errores o cualquier combinación de los tipos de suceso. Origen del suceso. El servicio o controlador específico que generó el suceso. Categoría. El filtro puede limitarse a categorías de sucesos específicas. Id. del suceso. Si conoce el Id. de suceso específico que está buscando, el filtro puede limitar la lista a ese Id. de suceso concreto. Usuario. Puede limitar los eventos mostrados a eventos generados por un usuario específico. Equipo. Puede limitar los eventos mostrados a eventos generados por un equipo específico. Intervalos de fechas. Puede limitar los sucesos mostrados a aquellos que se produjeron entre fechas de inicio y de finalización específicas. 191 Cuando se aplica el filtro, la lista de sucesos filtrada puede exportarse a una lista separada por comas o por tabulaciones para importarla a una aplicación de bases de datos. La herramienta Dump Event Log (Dumpel.exe) Dump Event Log es una herramienta de la línea de comandos que se incluye en Windows 2000 Server Resource Kit, Supplement One (Microsoft Press, ISBN: 0-7356-1279-X) (en inglés). Guarda un registro de sucesos de un sistema local o remoto en un archivo de texto separado por tabulaciones. Este archivo puede importarse a una hoja de cálculo o base de datos para realizar una investigación más detallada. La herramienta también sirve para filtrar determinados tipos de sucesos que se desea incluir o excluir. La herramienta dumpel.exe utiliza la sintaxis siguiente: dumpel -f archivo [-s \\servidor] [-l registro [-m origen]] [-e n1 n2 n3...] [-r] [-t] [-d x] Donde: -f archivo. Especifica el nombre de archivo del archivo de resultados. No existe ninguna opción predeterminada para -f, por lo que deberá especificar el archivo. -s servidor. Especifica el servidor para el que desea guardar el registro de sucesos. Las barras diagonales inversas del nombre de servidor son opcionales. -l registro. Especifica el registro que se debe guardar (del sistema, de aplicaciones o de seguridad). Si se especifica un nombre de registro incorrecto, se guarda el registro de aplicaciones. -m origen. Especifica el origen en que se deben guardar los registros (redirector [rdr], serie, etc.). Sólo se puede especificar un origen. Si no se utiliza este modificador, se guardan todos los sucesos. Si se utiliza un origen que no figura en el registro, se buscan los registros de este tipo en el registro de aplicaciones. -e n1 n2 n3. Realiza el filtrado por número de Id. de suceso (pueden especificarse 10 como máximo). Si no se utiliza el modificador -r, se guardan únicamente registros de estos tipos; si se utiliza -r, se guardan todos los registros excepto los registros de estos tipos. Si no se utiliza este modificador, se seleccionan todos los sucesos del nombredeorigen especificado. Este modificador no puede utilizarse sin el modificador -m. -r. Especifica si se deben incluir o excluir orígenes o registros específicos durante el filtrado. -t. Especifica que las cadenas individuales aparecen separadas por tabulaciones. Si no se utiliza -t, las cadenas se separan con espacios. -d x. Guarda sucesos de los x días anteriores. Nota: Dumpel sólo puede recuperar información de los archivos de registro del sistema, de aplicaciones y de seguridad. No se puede utilizar Dumpel para consultar contenido de registros de sucesos del Servicio de replicación de archivos, de DNS o del Servicio de directorio. 192 EventCombMT EventCombMT es una herramienta con varios subprocesos que analiza registros de sucesos de varios servidores al mismo tiempo generando un subproceso independiente de ejecución para cada servidor incluido en los criterios de búsqueda. Esta herramienta le permite: Definir un Id. de suceso único o varios Id. de suceso para su búsqueda. Puede incluir un Id. de suceso único o varios Id. de suceso separados por espacios. Definir un intervalo de Id. de suceso para su búsqueda. Los extremos son inclusivos. Por ejemplo, si desea buscar todos los sucesos entre el Id. de suceso 528 y el Id. de suceso 540 ambos inclusive, definirá el intervalo como 528 > ID < 540. Esta característica resulta útil porque la mayoría de las aplicaciones que escriben en el registro de sucesos utilizan un intervalo de sucesos secuencial. Limitar la búsqueda a registros de sucesos específicos. Puede escoger si desea buscar los registros de sucesos del sistema, de aplicaciones y de seguridad. Si se ejecuta localmente en un controlador de dominios, también puede seleccionar la búsqueda de los registros de FRS, DNS y AD. Limitar la búsqueda a tipos de mensajes de sucesos específicos. Puede limitar la búsqueda a sucesos de error, informativos, de advertencia, de auditoría de aciertos, de auditoría de errores o de aciertos. Limitar la búsqueda a orígenes de sucesos específicos. Puede limitar la búsqueda a sucesos de un origen determinado. Buscar texto específico en la descripción de un suceso. Puede buscar texto específico en cada suceso. Esta opción resulta útil a la hora de realizar un seguimiento de usuarios o grupos concretos. Nota: No se pueden utilizar los operadores lógicos de búsqueda AND, OR o NOT en el texto en cuestión. Tampoco se puede entrecomillar el texto. Definir intervalos de tiempo específicos para realizar análisis retrospectivos a partir de la fecha y hora actuales. Esta opción permite limitar la búsqueda a sucesos de la semana, el día o el mes anteriores. Instalar la herramienta Para instalar la herramienta, extraiga el contenido del archivo ejecutable SecurityOps.exe que se proporciona con esta guía. Se creará la carpeta C:\SecurityOps\EventComb. Una vez extraídos los archivos, haga doble clic en el archivo EventCombMT.exe para ejecutar la herramienta EventCombMT. Ejecutar la herramienta EventComb Para utilizar la herramienta EventComb, primero deberá definir los equipos que se van a incluir en la búsqueda de registros de sucesos. Para agregar equipos a la búsqueda 193 1. En la utilidad EventCombMT, asegúrese de que el dominio correcto se detecta automáticamente en el cuadro de dominio. Si desea buscar registros de sucesos en otro dominio, escriba el nuevo nombre de dominio en el cuadro Domain. 2. Para agregar equipos a la lista de búsqueda, haga clic con el botón secundario del mouse en el cuadro Select To Search/Right Click to Add. Aparecerá el menú emergente mostrado en la Ilustración 6.1.: Agregar equipos no detectados automáticamente a la lista de búsqueda Se encuentran disponibles las siguientes opciones: Get DCs in Domain. Agrega todos los controladores de dominio del dominio actual a la lista. Add Single Server. Le permite agregar el nombre de un servidor o de una estación de trabajo a la lista. Add all GCs in this domain. Le permite agregar todos los controladores de dominio del dominio seleccionado que se han configurado para actuar como servidores de catálogos globales. Get All Servers. Agrega todos los servidores encontrados en el dominio por medio del servicio de exploración. Los servidores excluyen todos los controladores de dominio. Get Servers from File. Le permite importar un archivo que contiene todos los servidores que se encuentran incluidos en el ámbito de la búsqueda. Cada servidor deberá figurar en una sola línea en el archivo de texto. 3. Una vez agregados los servidores a la lista, deberá seleccionar los servidores en los que se llevará a cabo la búsqueda. Al seleccionarlos, aparecerán resaltados en la lista. Puede utilizar CTRL+clic para seleccionar varios servidores a la vez. 194 Especificar los registros de sucesos y los tipos de sucesos para la búsqueda Una vez seleccionados los servidores que se van a incluir en la búsqueda de registros de sucesos, puede limitar el ámbito de la búsqueda seleccionando los registros de sucesos y los tipos de sucesos que desea incluir. En la utilidad EventCombMT, puede seleccionar los siguientes registros de sucesos para la búsqueda: Sistema. Aplicaciones. Seguridad. FRS (registro del Servicio de replicaci ón de archivos). DNS (registro del s ervidor DNS). AD (registro del Servicio de directorio). También puede seleccionar los tipos de sucesos que desea incluir en la búsqueda: Error. Grabado en los registros de aplicación y del sistema. También aparece en los registros del servicio de directorio, FRS y DNS. Informational. Grabado en los registros de aplicación y del sistema. También aparece en los registros del servicio de directorio, FRS y DNS. Warning. Grabado en los registros de aplicación y del sistema. También aparece en los registros del servicio de directorio, FRS y DNS. Success Audit. Se producen en el registro de seguridad o en el registro de aplicaciones si la aplicación guarda auditorías de aciertos en el registro de aplicaciones. Por ejemplo, la Herramienta de migración de Active Directory (ADMT) guarda sucesos de autoría de aciertos en el registro de aplicaciones. Failure Audit. Se producen en el registro de seguridad o en el registro de aplicaciones si la aplicación guarda auditorías de errores en el registro de aplicaciones. Por ejemplo, ADMT guarda sucesos de auditoría de error en el registro de aplicaciones. Success. Son poco comunes y se guardan en los registros de aplicaciones o del sistema. También aparecen en los registros del Servicio de directorio, FRS y DNS. En el Visor de sucesos, los sucesos de aciertos se muestran con el tipo de suceso informativo. Nota: Si conoce el registro de sucesos en que aparece un Id. de suceso y el tipo de suceso del Id. de suceso, incluya siempre esta información en los criterios de búsqueda para reducir así la duración de la búsqueda. Guardar búsquedas EventCombMT le permite guardar búsquedas y volverlas a cargar más adelante. Esta opción puede resultar útil si utiliza EventCombMT a menudo para buscar un grupo de sucesos en los servidores de IIS y otro grupo en los controladores de dominio. 195 Los criterios de búsqueda se guardan en el HKLM\Software\Microsoft\EventCombMT y se pueden modificar fácilmente. registro en: Archivos de resultados de la búsqueda Los resultados de la búsqueda se guardan en la carpeta C:\Temp de forma predeterminada. Los resultados incluyen un archivo resumen denominado EventCombMT.txt y se genera, para cada equipo incluido en la búsqueda de registros de sucesos, un archivo de texto independiente denominado NombreEquipo-NombreRegistroSucesos_LOG.txt. Estos archivos de texto independientes contienen todos los sucesos extraídos de los registros de sucesos que coinciden con los criterios de búsqueda. Ejemplos de uso de EventCombMT Para demostrar cómo se puede utilizar EventCombMT, a continuación se describe cómo configurar la herramienta para detectar reinicios y bloqueos de cuentas de los controladores de dominio. Para utilizar EventCombMT con el objeto de realizar búsquedas de reinicios de controladores de dominio 1. En la herramienta EventCombMT, asegúrese de que el dominio está configurado con el nombre correcto. 2. En el cuadro Select to Search/Right Click to Add que aparece debajo del nombre de dominio, seleccione el cuadro con el botón secundario y haga clic en Get DCs in Domain. Nota: Al buscar sucesos, como los sucesos Inicio de sesión de cuentas y Administración de cuentas, asegúrese de buscar en todos los controladores de dominio. Puesto que Windows 2000 utiliza un modelo de varios patrones para la administración de cuentas, las cuentas pueden agregarse, modificarse o eliminarse en cualquier controlador de dominio del dominio. Asimismo, la autenticación puede validarla cualquier controlador de dominio del dominio. Por esta razón, nunca se puede saber con certeza dónde se produce el intento de actualización o autenticación en cuestión. 3. Haga clic con el botón secundario del mouse en el cuadro Select to Search/Right Click to Add y otro clic en Select All Servers in List. 4. En la sección Choose Log Files to search de la herramienta, seleccione el registro System únicamente. 5. En la sección Event Types de la herramienta, seleccione Error e Informational. 6. En el cuadro Event IDs, escriba los siguientes Id. de suceso: 1001 6005 6006 6008 7. Antes de hacer clic en el botón Search, compruebe que los criterios de búsqueda se hayan definido como en la siguiente ilustración y, a continuación, haga clic en Search. 196 Los resultados de la búsqueda se pueden ver en el directorio de registro, el cual debería abrirse de forma automática una vez completada la búsqueda. Para revisar las entradas del registro 1. En el menú File, seleccione Open Log Directory. 2. En la carpeta C:\Temp, haga doble clic en el archivo de resultados de un controlador de dominio para ver los sucesos específicos registrados por la herramienta EventCombMT. Deberá obtener resultados parecidos a los que figuran a continuación: 1001,INFORMATIONAL,Save Dump,Wed Nov 28 05:45:50 2001,,The computer has rebooted from a bugcheck. The bugcheck was: 0x000000d1 (0x00000004, 0x00000002, 0x00000000, 0x84c983dc). A dump was saved in: C:\WINDOWS\MEMORY.DMP. 6005,INFORMATIONAL,EventLog,Wed Nov 28 05:45:46 2001,,The Event log service was started. 6008,ERROR,EventLog,Wed Nov 28 05:45:46 2001,,The previous system shutdown at 5:33:47 AM on 11/28/2001 was unexpected. 6005,INFORMATIONAL,EventLog,Tue Nov 27 14:10:53 2001,,The Event log service was started. 6006,INFORMATIONAL,EventLog,Tue Nov 27 14:09:26 2001,,The Event log service was stopped. 6005,INFORMATIONAL,EventLog,Tue Nov 27 10:11:37 2001,,The Event log service was started. Los sucesos 6006 indican un cierre planeado iniciado por un usuario con los derechos de usuario necesarios para cerrar el controlador de dominio. Los sucesos 6005 indican que se inició el servicio de registro de sucesos. Esto se produce durante el inicio. Los sucesos 6008 y 1001 indican que se apagó el equipo sin cerrar el sistema o que se reinició por un bloqueo o la aparición de una pantalla azul. La existencia de un suceso 1001 confirma que 197 se produjo una pantalla azul y se incluye la información de depuración asociada y una referencia al archivo de depuración. Los sucesos devueltos por la herramienta EventCombMT deberán compararse con el tiempo de inactividad real y los sucesos no coincidentes deberán investigarse para asegurarse de que el servidor no haya experimentado un ataque. EventCombMT incluye varias búsquedas preconfiguradas que pueden utilizarse para buscar sucesos de seguridad. Por ejemplo, existe una búsqueda predefinida que busca sucesos de Bloqueo de cuentas. Para utilizar EventCombMT con el objeto de realizar búsquedas de Bloqueos de cuentas 1. En la herramienta EventCombMT, asegúrese de que el dominio está configurado con el nombre correcto. 2. En el cuadro Select to Search/Right Click to Add que aparece debajo del nombre de dominio, seleccione el cuadro con el botón secundario y haga clic en Get DCs in Domain. 3. Haga clic con el botón secundario del mouse en el cuadro Select to Search/Right Click to Add y otro clic en Select All Servers in List. 4. En el menú Searches, haga clic en Built In Searches y, a continuación, en Account Lockouts. La utilidad EventCombMT se configura tal y como se muestra en la siguiente ilustración: 5. Haga clic en Search. 6. Los resultados de la búsqueda se pueden ver en el directorio de registro, el cual debería abrirse de forma automática una vez completada la búsqueda. Nota: Entre otras búsquedas predefinidas de EventCombMT, figuran las búsquedas de Servicios de replicación de archivos y búsquedas en Active Directory de SID duplicados y errores de registro de DNS de NETLOGON, errores de disco de hardware y errores de la interfaz de DNS. También puede definir y guardar sus propias búsquedas personalizadas. Obtención de sucesos Uno de los objetivos principales de la auditoría es la identificación de las acciones llevadas a cabo por los atacantes en la red. Un atacante puede intentar poner en peligro varios equipos y dispositivos de la red, por lo que, para comprender el alcance de un ataque, deberá poder coordinar y consolidar información de muchos equipos. Si la información obtenida por las utilidades de registro se puede importar a una base de datos, resultará más fácil coordinar la información de varios registros. Siempre que exista sincronización temporal entre todos los equipos, podrá organizar la información por campos de hora y facilitar el seguimiento de sucesos en función de los intervalos de tiempo. En los siguientes apartados se describen algunas de las herramientas y utilidades que puede utilizar para recopilar información de registros de sucesos en una ubicación central. Archivos de comandos Pueden escribirse archivos de comandos que obtengan información de registros de sucesos de equipos remotos y la guarden en una ubicación central. Con los archivos de comandos, puede 198 decidir cuándo ejecutar las secuencias de comandos por medio de Tareas programadas y qué acciones se deben tomar una vez que se copie correctamente el registro de sucesos en la ubicación central. Un ejemplo sencillo sería crear un archivo por lotes que utilice Dumpel.exe del Kit de recursos de Windows 2000 Server y ejecutar el archivo por lotes a intervalos regulares por medio de Tareas programadas del Panel de control. Windows 2000 Resource Kit, Supplement One incluye Eventquery.pl. Se trata de un archivo de comandos Perl que muestra sucesos de los registros del Visor de sucesos en equipos locales y remotos que ejecutan Windows 2000 y ofrece una amplia gama de filtros para ayudarle a encontrar sucesos específicos. Nota: Para utilizar este archivo de comandos, deberá instalar ActivePerl del Kit de recursos de Windows 2000 Server. Microsoft Operations Manager Microsoft Operations Manager 2000 ofrece un completo conjunto de herramientas que permiten a las empresas analizar con detalle los informes de sucesos y la supervisión de rendimiento incorporados de Windows 2000 y sus aplicaciones. Operations Manager puede obtener, almacenar y comunicar información de sucesos y rendimiento a una sola ubicación por medio del uso de Agentes inteligentes en equipos remotos, de forma que un administrador pueda revisar la información obtenida en una ubicación central. El paquete de administración principal de Operations Manager recopila sucesos que aparecen en los registros de sucesos del sistema, de aplicaciones y de seguridad y los agrupa en un depósito central de sucesos. Nota: Operations Manager almacena su información en una base de datos de SQL y proporciona varios métodos de recuperación y análisis de la información almacenada. Los administradores pueden utilizar Operations Manager Administrator Console, Web Console u Operations Manager Reporting para ver, imprimir o publicar la información. Cada vista incluye vistas predefinidas para analizar los datos almacenados y permite la definición de vistas e informes personalizados. Soluciones de terceros para la obtención de registros de sucesos Existen varios productos de terceros que permiten la obtención e inspección centralizada de registros de sucesos. Cuando evalúe productos de terceros, incluya las siguientes características en sus criterios: Compatibilidad con todos los registros de Windows 2000. Debería proporcionar compatibilidad con los registros del servidor DNS, del Servicio de directorio y del Servicio de replicación de archivos, además de los registros de aplicaciones, de seguridad y del sistema. Uso de un servidor de bases de datos. La herramienta debería permitir el almacenamiento de los registros de sucesos en una estructura de base de datos que permita la inspección de entradas de registros de sucesos anteriores para el análisis de tendencias y la correlación de sucesos entre varios servidores. Funcionalidad de búsquedas e informes. La herramienta debería permitirle buscar sucesos específicos según los criterios proporcionados. La presentación de los resultados deberá ser legible. 199 Entre los productos de terceros que permiten la recopilación de sucesos, se incluyen (sitios Web en inglés): Event Log Monitor – TNT Software (www.tntsoftware.com). Event Archiver – Dorian Software Creations (www.doriansoft.com). LogCaster – RippleTech (www.rippletech.com). Métodos de detección activos Los sistemas de detección de intrusiones activos analizan el tráfico de red entrante en el nivel de aplicaciones y buscan métodos conocidos de ataque o cargas del nivel de aplicaciones sospechosas. Si se recibe un paquete sospechoso, el sistema de detección de intrusiones normalmente lo rechaza y guarda una entrada en un archivo de registro. Algunos sistemas de detección de intrusiones también pueden alertar a un administrador si se detecta un ataque serio. Inspeccionar el acceso HTTP con URLScan Si aloja sitios Web en su organización, algunos de los servidores recibirán tráfico HTTP entrante. No obstante, no todo el tráfico será forzosamente legítimo. UrlScan es un filtro ISAPI que analiza los paquetes HTTP entrantes y puede rechazar cualquier tráfico sospechoso. UrlScan protege a los servidores de ataques al filtrar y rechazar solicitudes HTTP de características de servicios IIS seleccionados. UrlScan está configurado de forma predeterminada para aceptar solicitudes únicamente de archivos HTML estáticos (gráficos incluidos). Rechazará los siguientes tipos de solicitudes: P áginas CGI (.exe). WebDAV. Extensiones de servidor de FrontPage. Index Server. Impresi ón de Internet. Archivos de inclusi ón del servidor. UrlScan puede aplicarse como sistema de detección de intrusiones de extremos instalando el filtro ISAPI en todos los servidores IIS de la red o como sistema de detección de intrusiones de red instalando el filtro ISAPI de UrlScan en un servidor ISA ubicado en el perímetro de la red. Si utiliza el servidor ISA como servidor de seguridad, debería considerar utilizar una combinación de ambas soluciones. En el perímetro de la red, bloquee todo el tráfico general no deseado para que no entre en la red. En los servidores IIS de los extremos, pueden implementarse conjuntos de reglas específicos en función del formato del contenido proporcionado por el servidor Web. UrlScan se configura con un archivo denominado UrlScan.ini, que se encuentra ubicado en la carpeta %WinDir%\system32\inetsrv\Urlscan. Este archivo contiene varias secciones. La sección [Options] define cómo va a tratar el servidor IIS las solicitudes Web válidas y no válidas. Entre las opciones que se pueden definir, figuran: 200 UseAllowVerbs. Se permiten los valores 0 ó 1. Si se establece en el valor predeterminado 1, UrlScan lee la sección AllowVerbs de UrlScan.ini y rechaza las solicitudes que contengan un verbo HTTP que no figure explícitamente en la lista. La sección AllowVerbs distingue mayúsculas y minúsculas. Si se establece en 0, UrlScan lee la sección DenyVerbs de UrlScan.ini y rechaza las solicitudes que contengan un verbo HTTP de la lista. La sección DenyVerbs no distingue mayúsculas y minúsculas. UseAllowExtensions. Se permiten los valores 0 ó 1. Si se establece en 1, UrlScan lee la sección AllowExtensions de UrlScan.ini y rechaza las solicitudes cuya extensión de archivo asociada con la dirección URL no figure explícitamente en la lista. Si se establece en el valor predeterminado 0, UrlScan lee la sección DenyExtensions de UrlScan.ini y rechaza las solicitudes cuya extensión de archivo asociada con la solicitud figure en la lista. Las secciones AllowExtensions y DenyExtensions no distinguen mayúsculas y minúsculas. NormalizeUrlBeforeScan. Se permiten los valores 0 ó 1. Si se establece en el valor predeterminado 1, UrlScan lleva a cabo todo el análisis de las direcciones URL de las solicitudes una vez IIS las haya descodificado y normalizado. Si se establece en 0, UrlScan lleva a cabo todo el análisis de las direcciones URL sin procesar tal y como las envía el cliente. Sólo los administradores avanzados que conozcan a la perfección el análisis de direcciones URL deberían establecer esta opción en 0, puesto que es posible que se exponga el servidor IIS a ataques de canonicalización que ignoren el análisis correcto de las extensiones URL. VerifyNormalization. Se permiten los valores 0 ó 1. Si se establece en el valor predeterminado 1, UrlScan comprueba la normalización de la dirección URL. Esta acción protege de ataques de canonicalización, en los que la dirección URL contiene una cadena con codificación doble en la dirección URL (por ejemplo, la cadena "%252e" es un carácter '.' con codificación doble porque "%25" se descodifica en un carácter '%'; la primera descodificación de "%252e" da como resultado "%2e", que puede descodificarse por segunda vez en '.'). Si se establece en 0, no se lleva a cabo esta comprobación. AllowHighBitCharacters. Se permiten los valores 0 ó 1. Si se establece en 1, UrlScan permite la existencia de cualquier byte en la URL. Si se establece en el valor predeterminado 0, UrlScan rechaza las solicitudes cuya dirección URL contenga un carácter no incluido en el juego de caracteres ASCII. Esta característica puede proteger de ataques basados en Unicode o UTF-8, pero también rechazará solicitudes legítimas en servidores IIS que utilicen una página de códigos distinta de ASCII. AllowDotInPath. Se permiten los valores 0 ó 1. Si se establece en el valor predeterminado 1, UrlScan rechaza las solicitudes que contengan varias instancias del carácter de punto (.). Si se establece en 1, UrlScan no realiza esta prueba. Puesto que UrlScan opera en un nivel en el que IIS todavía no ha analizado la dirección URL, no se puede determinar en todos los casos si el carácter de punto indica la extensión o si forma parte de la ruta de acceso al directorio o del nombre de archivo de la dirección URL. Para el análisis de extensiones, UrlScan siempre asume que la extensión forma parte de la dirección URL a partir del último punto de la cadena y hasta la primera interrogación o barra diagonal que figure tras el punto o el final de la cadena. Establecer AllowDotInPath en 0 constituye un método de defensa en caso de que un atacante utilizase la información de ruta para ocultar la extensión real de la solicitud (por ejemplo, "/ruta/URLreal.asp/ParteFalsa.htm"). Nota: Si se establece AllowDotInPath en 0, UrlScan también rechazará las solicitudes que contengan un punto en los nombres de directorio. RemoveServerHeader. Se permiten los valores 0 ó 1. Si se establece en 1, UrlScan elimina el encabezado del servidor en todas las respuestas. Si se establece en el valor predeterminado 0, 201 UrlScan no realiza esta acción. Observe que esta característica sólo se encuentra disponible si se instala UrlScan en IIS 4.0 o posterior. EnableLogging. Se permiten los valores 0 ó 1. Si se establece en el valor predeterminado 1, UrlScan registra sus acciones en un archivo denominado UrlScan.log, que se crea en el mismo directorio que contiene UrlScan.dll. Si se establece en 0, no se lleva a cabo ningún registro. PerProcessLogging. Se permiten los valores 0 ó 1. Si se establece en 1, UrlScan agrega el Id. de proceso del proceso IIS que aloja UrlScan.dll al nombre del archivo de registro (por ejemplo, UrlScan.1234.log). 7. Responder a las incidencias ¿Está preparado su departamento de TI para enfrentarse a una incidencia de seguridad?. Muchas organizaciones no aprenden cómo responder a una incidencia de seguridad hasta que sufren un ataque. Y para entonces, puede ser que la incidencia haya supuesto un costo mucho más alto de lo necesario. La respuesta adecuada a las incidencias debería ser una parte integrante de la directiva de seguridad global y de la estrategia de mitigación de riesgos. La respuesta a incidencias de seguridad tiene unas ventajas directas claras. Sin embargo, puede ser que también tenga unas ventajas financieras indirectas. Por ejemplo, su compañía de seguros podría ofrecerle un descuento si puede usted demostrar que su organización suele responder a los ataques de forma rápida y económica. Por otro lado, si es usted un proveedor de servicios, un plan formal de respuesta a incidencias puede ayudarle a conseguir más clientes, pues demuestra que se toma en serio el proceso de tener una buena seguridad de la información. Minimizar el número y la gravedad de las incidencias de seguridad En general, es mejor prevenir que curar y la seguridad no es ninguna excepción. En la medida de lo posible, deberá ante todo evitar incidencias de seguridad. No obstante, ya que no es posible evitar todos las incidencias de seguridad, cuando surja uno necesitará asegurarse de que el impacto sea mínimo. Hay algunas medidas de prudencia que puede adoptar para minimizar el número y el impacto de las incidencias de seguridad. Estas incluyen: Establecer claramente todas las directivas y los procedimientos y exigir su cumplimiento. Muchas incidecias de seguridad se generan de forma accidental porque el personal del departamento de TI no ha seguido o no ha comprendido los procedimientos de administración de cambios, o bien porque ha configurado incorrectamente los dispositivos de seguridad como, por ejemplo, servidores de seguridad y sistemas de autenticación. Las directivas y los procedimientos deben probarse exhaustivamente para garantizar que son prácticos y claros, y que ofrecen el nivel de seguridad apropiado. Obtener el visto bueno de la administraci ón en lo referente a directivas de seguridad y tratamiento de incidencias. Supervisar y analizar de forma rutinaria el tr áfico de la red y el rendimiento del sistema. Comprobar todos los registros y mecanismos de registro de forma rutinaria. Estos incluyen los registros de sucesos del sistema operativo, los registros específicos de una aplicación y los registros del sistema de detección de intrusiones. Evaluar de forma rutinaria la vulnerabilidad de su entorn o. Debería realizarla un especialista en seguridad con una acreditación especial para ejecutar estas acciones. 202 Comprobar los servidores de forma rutinaria para garantizar que tienen instaladas las revisiones más recientes. Establecer programas de forma ción en seguridad para el personal del departamento de TI y para los usuarios finales. La mayor vulnerabilidad de cualquier sistema es la ingenuidad del usuario; el gusano ILOVEYOU explotó de forma eficaz esta vulnerabilidad. Publicar avisos de seguridad que recuerden a los usuarios sus responsabilidades y restricciones, junto con una advertencia de que se podrían tomar acciones legales en caso de infracción. Sin estos avisos puede ser difícil o imposible tomar acciones legales contra los infractores. Debería recibir asesoramiento jurídico para asegurarse de que el texto de los avisos de seguridad es apropiado. Desarrollar, implementar y exigir una directiva sobre la necesidad de contrase ñas complejas. Verificar los procedimientos de copia de seguridad y restauraci ón. Debería conocer el lugar donde se conservan las copias de seguridad, las personas que pueden tener acceso a ellas y los procedimientos de restauración de datos y recuperación del sistema. Compruebe regularmente las copias de seguridad y los medios restaurando datos de forma selectiva. Crear un equipo de respuesta a incidencias de seguridad inf ormática (CSIRT). Se trata de un grupo de personas encargadas de tratar cualquier incidencia de seguridad. Los miembros del CSIRT de su organización deben tener tareas claramente definidas para garantizar que ninguna área de la respuesta queda sin cubrir (más adelante en este capítulo encontrará detalles acerca de cómo crear un CSIRT). Formar a los miembros de seguridad de la informaci ón del CSIRT acerca del uso y la ubicación adecuados de las herramientas de seguridad fundamentales. Debería considerar la posibilidad de proporcionar equipos portátiles preconfigurados con estas herramientas para asegurarse de que no se pierde tiempo instalando y configurando herramientas para responder a una incidencia. Estos sistemas y las herramientas asociadas deben protegerse adecuadamente cuando no se estén utilizando. Reunir toda la informaci ón de comunicaciones relevante. Debería asegurarse de que tiene los nombres y números de teléfono de contacto de las personas de la organización que deben ser notificadas (incluidos los miembros del CSIRT, los responsables de la asistencia técnica de todos los sistemas y las personas encargadas de las relaciones con los medios de comunicación). También necesitará proporcionar detalles al proveedor de servicios de Internet (ISP) y a las fuerzas y los cuerpos de seguridad locales y nacionales. Considere la posibilidad de ponerse en contacto con las fuerzas y los cuerpos de seguridad locales antes de que ocurra una incidencia. De este modo, se asegurará de que entiende los procedimientos adecuados para comunicar incidencias y reunir pruebas. Anotar toda la infor mación del sistema de emergencia en una ubicación central sin conexión como, por ejemplo, un bloc de notas o un equipo sin conexión. Esta información de emergencia incluye las contraseñas de los sistemas, las direcciones IP, la información de configuración del enrutador, las listas del conjunto de reglas del servidor de seguridad, copias de las claves de la entidad emisora de certificados, los nombres y números de teléfono de contactos, los procedimientos para elevar la decisión de problemas a otras instancias, etc. Esta información debe guardarse en un lugar extremadamente seguro y debe poder estar disponible de inmediato. Para asegurar la información y poder disponer de ella de inmediato, se puede codificar en un equipo portátil de seguridad dedicado, custodiado en una caja fuerte con acceso limitado a personas autorizadas como, por ejemplo, el responsable del CSIRT y el responsable del departamento de información o del departamento de tecnología. 203 Crear el equipo básico de respuesta a incidencias de seguridad informática El CSIRT es el núcleo principal para tratar las incidencias de seguridad informática de su entorno. Es responsable de: Supervisar los sistemas para detectar infracciones de seguridad. Servir como n úcleo de comunicación tanto para recibir informes de incidencias de seguridad como para difundir información vital a las entidades adecuadas acerca de la incidencia. Documentar y catalogar las incidencias de seguridad. Promover la conciencia sobre la seguridad en la empresa para evitar que s e produzcan incidencias en la organización. Proporcionar asistencia a la auditor ía de la red y del sistema a través de procesos como la evaluación de la vulnerabilidad y la prueba de intrusiones. Mantenerse al d ía sobre las nuevas vulnerabilidades y estrategias de ataque que emplean los atacantes. Mantenerse al d ía sobre las nuevas revisiones de software. Analizar y desarrollar nuevas tecnolog ías para minimizar las vulnerabilidades y los riesgos de seguridad. Proporcionar servicios de consultor ía sobre seguridad. Perfeccionar y actualizar de forma continua los sistemas y procedimientos actuales. Si bien la estructura e integrantes ideales del CSIRT dependen del tipo de organización y de la estrategia de administración de riesgos, normalmente el CSIRT debería ser una parte o todo el equipo de seguridad de la organización. El núcleo central lo forman profesionales de seguridad responsables de coordinar una respuesta ante cualquier incidencia. El número de miembros del CSIRT dependerá normalmente del tamaño y la complejidad de la organización. No obstante, debe asegurarse de que hay suficientes miembros como para cubrir de forma adecuada todas las tareas del equipo en cualquier momento. Responsable del equipo CSIRT Es importante que el CSIRT tenga una persona responsable de las actividades del equipo. El responsable del equipo CSIRT normalmente se ocupará de las actividades del equipo y coordinará la revisión de las acciones del mismo. Como consecuencia, puede ser que se produzcan cambios en las directivas y los procedimientos para tratar futuras incidentcias. Responsable de incidencias del CSIRT Si se produce una incidencia, debe haber una persona responsable de coordinar la respuesta. El responsable de incidencias del CSIRT se hace cargo de una determinada incidencia o de un conjunto de incidencias de seguridad relacionados. Todas las comunicaciones acerca de la incidencia se coordinan a través del responsable de incidencias, quien representa a todo el CSIRT cuando habla con personas externas al mismo. Puede haber varios responsables de incidencias, según la naturaleza de la incidencia, y suele ser una persona distinta al responsable del equipo CSIRT. 204 Miembros asociados al CSIRT Además del equipo básico CSIRT, debería tener varias personas encargadas de responder a determinadas incidencias. Los miembros asociados procederán de diversos departamentos de la organización y estarán especializados en áreas que sufren incidencias de seguridad, de las que no se encarga directamente el equipo básico CSIRT. Los miembros asociados pueden implicarse directamente en una incidencia o pueden ser intermediarios y delegar la responsabilidad a una persona más adecuada del departamento. En esta tabla se sugieren posibles miembros asociados y sus funciones. Tabla 7.1.: Miembros asociados al CSIRT. Miembro asociado Descripción de la función Contacto TI Responsabilidad principal de coordinar las comunicaciones entre el responsable de incidencias del CSIRT y el resto del grupo de TI. Esta persona puede no tener la experiencia técnica específica para responder inmediatamente a la incidencia; sin embargo, será responsable principalmente de buscar a los miembros del grupo de TI capaces de tratar determinados sucesos de seguridad. Representante legal Suele ser un miembro del departamento jurídico de la empresa muy familiarizado con las directivas de respuesta a incidencias establecidas. El representante legal determina el modo de proceder durante una incidencia con la mínima responsabilidad jurídica y la máxima eficacia para tomar acciones legales contra los infractores. Antes de que se produzca una incidencia, el representante legal debe tener información sobre las directivas de supervisión y respuesta para garantizar que la organización no se expone a ningún tipo de riesgo jurídico durante una operación de limpieza o de contención. Resulta imperativo tener en cuenta las implicaciones legales de apagar un sistema e infringir potencialmente acuerdos de prestación de servicios o de pertenencia con los clientes, o de no apagar un sistema que ha sufrido una intromisión y ser responsable de los daños causados por ataques lanzados desde ese sistema. El representante legal también coordina las comunicaciones con las agencias de investigación o las fuerzas y cuerpos de seguridad externos. Responsable comunicaciones Administración de Suele ser un miembro del departamento de relaciones públicas y es responsable de proteger y promover la imagen de la organización. Puede que no sea quien da la cara ante los medios de comunicación y los clientes, pero es responsable de transmitir el mensaje (si bien el contenido y el objetivo del mensaje normalmente es responsabilidad de la administración). Todas las consultas de los medios de comunicación deben dirigirse al responsable de comunicaciones. La administración puede dirigirse a un solo departamento o a toda la organización. Habrá diversos responsables de administración adecuados según el impacto, la ubicación, la gravedad y el tipo de incidencia. Si su organización tiene un punto de contacto con la administración, podrá identificar rápidamente a la persona más adecuada en cada circunstancia concreta. La administración es responsable de aprobar y dirigir la directiva de seguridad. También es 205 responsable de determinar el impacto total (financiero y de otro tipo) de la incidencia en la organización. La administración dirige al responsable de comunicaciones con respecto a la información que debe revelar a los medios de comunicación y determina el nivel de interacción entre el representante legal y las fuerzas y los cuerpos de seguridad. Respuesta del CSIRT a una incidencia Si se produce una incidencia, el CSIRT coordinará una respuesta de su equipo básico y se comunicará con los miembros asociados del mismo. En la siguiente tabla se muestran las responsabilidades de estas personas durante el proceso de respuesta a una incidencia. Tabla 7.2.: Responsabilidades del CSIRT durante el proceso de respuesta a una incidencia. Funciones Responsable de incidencias del CSIRT Contacto TI Representante legal Responsable de comunicaciones Administración Evaluación inicial Propietario Sugiere Ninguna Ninguna Ninguna Respuesta inicial Propietario Implementa Actualizado Actualizado Actualizado Reunir pruebas forenses Implementa Sugiere Propietario Ninguna Ninguna Implementar una solución temporal Propietario Implementa Actualizado Actualizado Sugiere Enviar una comunicación Asesor Sugiere Sugiere Implementa Propietario Consultar a fuerzas y cuerpos de seguridad locales Actualizador Actualizado Implementa Actualizado Propietario Implementar solución definitiva Propietario Implementa Actualizado Actualizado Actualizado Determinar el impacto financiero sobre el Actualizador Actualizado Sugiere Actualizado Propietario 206 negocio Definir un plan de respuesta a incidencias Todos los miembros de su entorno de TI deberían saber qué hacer en el caso de que se produzca una incidencia. Si bien el CSIRT llevará a cabo la mayoría de las acciones de respuesta a una incidencia, todos los niveles del personal de TI deberían saber cómo comunicar las incidencias internamente. Los usuarios finales deberían comunicar la actividad sospechosa directamente al personal de TI o a través de un departamento de soporte y no directamente al CSIRT. Todos los miembros del equipo deberían revisar con detalle el plan de respuesta a incidencias, que debería ser fácilmente accesible para todo el personal de TI. De este modo, se podrá garantizar que se siguen los procedimientos adecuados cuando se produzca una incidencia. Apéndices A. Achivos Archivos asegurados mediante la Directiva de línea de base para los servidores miembros, además de las listas de control de acceso proporcionadas con la plantilla hisecws.inf. Archivo Permisos de línea de base %SystemDrive%\Boot.ini Administradores: Control total Sistema: Control total %SystemDrive%\Ntdetect.com Administradores: Control total Sistema: Control total %SystemDrive%\Ntldr Administradores: Control total Sistema: Control total %SystemDrive%\Io.sys Administradores: Control total Sistema: Control total %SystemDrive%\Autoexec.bat Administradores: Control total Sistema: Control total Usuarios autenticados: Leer y ejecutar, Listar el contenido de la carpeta y Leer %SystemDrive%\Config.sys Administradores: Control total Sistema: Control total Usuarios autenticados: Leer y ejecutar, Listar el contenido de la carpeta y Leer 207 %SystemRoot%\system32\Append.exe Administradores: Control total %SystemRoot%\system32\Arp.exe Administradores: Control total %SystemRoot%\system32\At.exe Administradores: Control total %SystemRoot%\system32\Attrib.exe Administradores: Control total %SystemRoot%\system32\Cacls.exe Administradores: Control total %SystemRoot%\system32\Change.exe Administradores: Control total %SystemRoot%\system32\Chcp.com Administradores: Control total %SystemRoot%\system32\Chglogon.exe Administradores: Control total %SystemRoot%\system32\Chgport.exe Administradores: Control total %SystemRoot%\system32\Chguser.exe Administradores: Control total %SystemRoot%\system32\Chkdsk.exe Administradores: Control total %SystemRoot%\system32\Chkntfs.exe Administradores: Control total %SystemRoot%\system32\Cipher.exe Administradores: Control total %SystemRoot%\system32\Cluster.exe Administradores: Control total %SystemRoot%\system32\Cmd.exe Administradores: Control total %SystemRoot%\system32\Compact.exe Administradores: Control total %SystemRoot%\system32\Command.com Administradores: Control total %SystemRoot%\system32\Convert.exe Administradores: Control total %SystemRoot%\system32\Cscript.exe Administradores: Control total %SystemRoot%\system32\Debug.exe Administradores: Control total %SystemRoot%\system32\Dfscmd.exe Administradores: Control total %SystemRoot%\system32\Diskcomp.com Administradores: Control total %SystemRoot%\system32\Diskcopy.com Administradores: Control total %SystemRoot%\system32\Doskey.exe Administradores: Control total %SystemRoot%\system32\Edlin.exe Administradores: Control total %SystemRoot%\system32\Exe2bin.exe Administradores: Control total 208 %SystemRoot%\system32\Expand.exe Administradores: Control total %SystemRoot%\system32\Fc.exe Administradores: Control total %SystemRoot%\system32\Find.exe Administradores: Control total %SystemRoot%\system32\Findstr.exe Administradores: Control total %SystemRoot%\system32\Finger.exe Administradores: Control total %SystemRoot%\system32\Forcedos.exe Administradores: Control total %SystemRoot%\system32\Format.com Administradores: Control total %SystemRoot%\system32\Ftp.exe Administradores: Control total %SystemRoot%\system32\Hostname.exe Administradores: Control total %SystemRoot%\system32\Iisreset.exe Administradores: Control total %SystemRoot%\system32\Ipconfig.exe Administradores: Control total %SystemRoot%\system32\Ipxroute.exe Administradores: Control total %SystemRoot%\system32\Label.exe Administradores: Control total %SystemRoot%\system32\Logoff.exe Administradores: Control total %SystemRoot%\system32\Lpq.exe Administradores: Control total %SystemRoot%\system32\Lpr.exe Administradores: Control total %SystemRoot%\system32\Makecab.exe Administradores: Control total %SystemRoot%\system32\Mem.exe Administradores: Control total %SystemRoot%\system32\Mmc.exe Administradores: Control total %SystemRoot%\system32\Mode.com Administradores: Control total %SystemRoot%\system32\More.com Administradores: Control total %SystemRoot%\system32\Mountvol.exe Administradores: Control total %SystemRoot%\system32\Msg.exe Administradores: Control total %SystemRoot%\system32\Nbtstat.exe Administradores: Control total %SystemRoot%\system32\Net.exe Administradores: Control total %SystemRoot%\system32\Net1.exe Administradores: Control total 209 %SystemRoot%\system32\Netsh.exe Administradores: Control total %SystemRoot%\system32\Netstat.exe Administradores: Control total %SystemRoot%\system32\Nslookup.exe Administradores: Control total %SystemRoot%\system32\Ntbackup.exe Administradores: Control total %SystemRoot%\system32\Ntsd.exe Administradores: Control total %SystemRoot%\system32\Pathping.exe Administradores: Control total %SystemRoot%\system32\Ping.exe Administradores: Control total %SystemRoot%\system32\Print.exe Administradores: Control total %SystemRoot%\system32\Query.exe Administradores: Control total %SystemRoot%\system32\Rasdial.exe Administradores: Control total %SystemRoot%\system32\Rcp.exe Administradores: Control total %SystemRoot%\system32\Recover.exe Administradores: Control total %SystemRoot%\system32\Regedit.exe Administradores: Control total %SystemRoot%\system32\Regedt32.exe Administradores: Control total %SystemRoot%\system32\Regini.exe Administradores: Control total %SystemRoot%\system32\Register.exe Administradores: Control total %SystemRoot%\system32\Regsvr32.exe Administradores: Control total %SystemRoot%\system32\Replace.exe Administradores: Control total %SystemRoot%\system32\Reset.exe Administradores: Control total %SystemRoot%\system32\Rexec.exe Administradores: Control total %SystemRoot%\system32\Route.exe Administradores: Control total %SystemRoot%\system32\Routemon.exe Administradores: Control total %SystemRoot%\system32\Router.exe Administradores: Control total %SystemRoot%\system32\Rsh.exe Administradores: Control total %SystemRoot%\system32\Runas.exe Administradores: Control total %SystemRoot%\system32\Runonce.exe Administradores: Control total 210 %SystemRoot%\system32\Secedit.exe Administradores: Control total %SystemRoot%\system32\Setpwd.exe Administradores: Control total %SystemRoot%\system32\Shadow.exe Administradores: Control total %SystemRoot%\system32\Share.exe Administradores: Control total %SystemRoot%\system32\Snmp.exe Administradores: Control total %SystemRoot%\system32\Snmptrap.exe Administradores: Control total %SystemRoot%\system32\Subst.exe Administradores: Control total %SystemRoot%\system32\Telnet.exe Administradores: Control total %SystemRoot%\system32\Termsrv.exe Administradores: Control total %SystemRoot%\system32\Tftp.exe Administradores: Control total %SystemRoot%\system32\Tlntadmin.exe Administradores: Control total %SystemRoot%\system32\Tlntsess.exe Administradores: Control total %SystemRoot%\system32\Tlntsvr.exe Administradores: Control total %SystemRoot%\system32\Tracert.exe Administradores: Control total %SystemRoot%\system32\Tree.com Administradores: Control total %SystemRoot%\system32\Tsadmin.exe Administradores: Control total %SystemRoot%\system32\Tscon.exe Administradores: Control total %SystemRoot%\system32\Tsdiscon.exe Administradores: Control total %SystemRoot%\system32\Tskill.exe Administradores: Control total %SystemRoot%\system32\Tsprof.exe Administradores: Control total %SystemRoot%\system32\Tsshutdn.exe Administradores: Control total %SystemRoot%\system32\Usrmgr.com Administradores: Control total %SystemRoot%\system32\Wscript.exe Administradores: Control total %SystemRoot%\system32\Xcopy.exe Administradores: Control total 211 B. Servicios de Windows 2000 predeterminados La columna Predeterminado muestra el inicio de los servicios de un servidor basado en Windows 2000. La columna Línea de base muestra la configuración de inicio de cada servicio después de aplicar la Directiva de línea de base para los servidores miembros. Servicio Nombre completo Predeterminado Línea base Alerter Servicio de alerta Automático Deshabilitado AppMgmt Administración de aplicaciones Manual Deshabilitado ClipSrv Portafolios Manual Deshabilitado EventSystem Sistema de sucesos COM+ Manual Manual Browser Examinador de equipos Automático Deshabilitado DHCP Cliente DHCP Automático Automático Dfs Sistema de archivos distribuido Automático Habilitado sólo en la función DC TrkWks Cliente de seguimiento de vínculos distribuidos Automático Automático TrkSrv Servidor de seguimiento de vínculos distribuidos Manual Deshabilitado MSDTC Coordinador distribuidas Automático Deshabilitado DNSCache Cliente DNS Automático Automático EventLog Registro de sucesos Automático Automático Fax Servicio de fax Manual Deshabilitado NtFrs Replicación de archivos Manual Deshabilitado IISADMIN Servicio de administración de IIS Automático Deshabilitado Cisvc Servicio de Index Server Manual Deshabilitado SharedAccess Conexión compartida a Internet Manual Deshabilitado IsmServ Mensajería entre sitios Deshabilitado Deshabilitado PolicyAgent Agente de directivas (servicio IPSEC) Automático Deshabilitado de transacciones IPSEC de 212 Kdc Centro de distribución de claves Kerberos Deshabilitado Habilitado sólo en la función DC LicenseService Servicio de registro de licencias Automático Deshabilitado Dmserver Administrador de discos lógicos Automático Automático Dmadmin Servicio del administrador de discos lógicos Manual Manual Messenger Mensajero Automático Deshabilitado Netlogon Inicio de sesión en red Automático* Automático Mnmsrvc Escritorio remoto compartido de NetMeeting Manual Deshabilitado Netman Conexiones de red Manual Manual NetDDE DDE de red Manual Deshabilitado NetDDEdsdm DSDM de DDE de red Manual Deshabilitado NtLmSsp Proveedor de asistencia de seguridad NTLM Manual Deshabilitado SysmonLog Registros y alertas de rendimiento Manual Manual PlugPLay Plug and Play Automático Automático Spooler Cola de impresión Automático Habilitado sólo en la función Archivo e Imprimir ProtectedStorage Almacenamiento protegido Automático Automático RSVP Control de admisión QoS (RSVP) Manual Deshabilitado RasAuto Administrador de conexión automática de acceso remoto Manual Deshabilitado RasMan Administrador acceso remoto Manual Deshabilitado RpcSs Llamada a procedimiento remoto (RPC) Automático Automático Rpclocator Localizador de llamadas procedimiento remoto (RPC) Manual Habilitado sólo en la función DC de conexión de a 213 RemoteRegistry Servicio de registro remoto Automático Automático NtmsSvc Medios extraíbles Automático Deshabilitado RemoteAccess Enrutamiento y acceso remoto Deshabilitado Deshabilitado Seclogon Servicio RunAs Automático Deshabilitado SamSs Administrador seguridad Automático Automático Lanmanserver Servidor Automático Automático SMTPSVC Protocolo simple de transferencia de correo (STMP) Automático Deshabilitado ScardSvr Tarjeta inteligente Manual Deshabilitado ScardDrv Sistema de inteligente Manual Deshabilitado SENS Notificación de sucesos del sistema Automático Automático Schedule Programador de tareas Automático Deshabilitado LmHosts Servicio de ayuda TCP/IP NetBIOS Automático Automático TapiSrv Telefonía Manual Deshabilitado TlntSvr Telnet Manual Deshabilitado TermService Servicios de Terminal Server Deshabilitado Deshabilitado UPS Sistema de ininterrumpida Manual Deshabilitado UtilMan Administrador de utilidades Manual Deshabilitado MSIServer Instalador de Windows Manual Deshabilitado WinMgmt Instrumental de administración de Windows Manual Deshabilitado WMI Extensiones del controlador del Instrumental de administración de Windows Manual Manual W32Time Sincronización Windows Automático* Automático LanmanWorkstation Estación de trabajo Automático Automático de almacenamiento de ayuda cuentas de de tarjeta alimentación de tiempo de 214 W3svc Servicio de publicación de World Wide Web Automático Habilitado sólo en la función IIS * - Automático para un servidor en el dominio. Manual si el servidor pertenece a un grupo de trabajo. C. Servicios adicionales La tabla siguiente muestra los servicios adicionales incluidos con Windows 2000 Server y Advanced Server que se pueden agregar a una instalación predeterminada. Servicio Nombre completo Línea de base BINLSVC Capa de negociación de información de inicio Deshabilitado CertSvc Servicios de Certificate Server Deshabilitado ClusSvc Servicio de clúster Deshabilitado DHCPServer Servidor de DHCP Habilitado sólo en la función Infra DNS Servidor DNS Habilitado sólo en las funciones Infra y DC MacFile Servidor de archivos para Macintosh Deshabilitado MSFTPSVC Servicio de publicación de FTP Deshabilitado NWCWorkstation Servicio de puerta de enlace para NetWare Deshabilitado IAS Servicio de autenticación de Internet Deshabilitado MSMQ Message Queue Server Deshabilitado NntpSvc Protocolo de transferencia de noticias a través de la red (NNTP) Deshabilitado NSLService Difusión de presentaciones en línea Deshabilitado MacPrint Servidor de impresión para Macintosh Deshabilitado RSVP QoS RSVP Deshabilitado Remote_Storage_ Engine Motor de almacenamiento remoto Deshabilitado Remote_Storage_ File_System_Agent Archivo de almacenamiento remoto Deshabilitado 215 Remote_Storage_ Subsystem Medios de almacenamiento remoto Deshabilitado Remote_Storage_ User_Link Notificación de almacenamiento remoto Deshabilitado NwSapAgent Agente SAP Deshabilitado SimpTcp Servicios simples de TCP/IP Deshabilitado Groveler Groveler de almacenamiento de instancia única Deshabilitado LDAPSVCX Servicio ILS de Site Server Deshabilitado SNMP Servicio SNMP Deshabilitado SNMPTRAP Servicio de captura SNMP Deshabilitado LPDSVC Servidor de impresión TCP/IP Deshabilitado TermServLicensing Licencias de Servicios de Terminal Server Deshabilitado TFTPD Demonio FTP trivial Deshabilitado WINS Servicio de nombres Internet de Windows (WINS) Habilitado sólo en la función Infra nsmonitor Servicio Monitor de Windows Media Deshabilitado nsprogram Servicio de programa de Windows Media Deshabilitado nsstation Servicio de emisoras de Windows Media Deshabilitado nsunicast Servicio de unidifusión de Windows Media Deshabilitado D. Instalación de una infraestructura básica Este apéndice explica cómo puede instalarse una infraestructura básica, descrita en la Guía de operaciones de seguridad de Windows 2000. Ofrece un método paso a paso para crear un entorno de prueba, instalar todo el sistema operativo, los servicios, las revisiones, etc. relevantes, configurar Active Directory utilizando dcpromo y comprueba la validez del mismo antes de ejecutar la prueba real. Crear el entorno de prueba 1. Instale una red o un conmutador que proporcione una topología de red plana que admita hasta 10 equipos. 216 2. Instale Windows 2000 Server en una partición NTFS en todos los servidores de prueba, utilizando la convención de nomenclatura y las direcciones IP que se muestran en el diagrama. 3. Asigne una contraseña resistente a la cuenta de administrador. 4. Configure cada equipo para que utilice 192.168.99.7 como su Servidor DNS principal. 5. Configure cada equipo para que utilice 192.168.99.7 como su Servidor WINS principal. 6. Haga que cada equipo sea miembro de un grupo de trabajo denominado Workgroup. 7. Instale DNS, DHCP y WINS en el Servidor de infraestructura. 8. Instale Windows 2000 Service Pack 2 en todos los equipos. 9. Instale la revisión descrita en el artículo Q295444 de Knowledge Base: SCE no puede modificar una Entrada SACL del servicio del Registro en todos los equipos. 10. Promueva AD01 para que sea un controlador de dominio en el dominio de prueba. 11. Una AD02 al dominio de Active Directory. 12. Una los servidores miembros al dominio de Active Directory. 13. Use los pasos del capítulo 3 de la guía para crear la estructura OU. 14. Use los pasos del capítulo 5 de la guía para instalar y ejecutar Hfnetchk. Casos de prueba Caso de prueb a Priori dad Condición que se probará Detalles de la ejecución Datos Resultado necesarios esperado: 217 1.1 Baja Ninguna Realice la copia de seguridad del estado del sistema de cada servidor en disco Ninguno Copia de seguridad correcta 1.2 Alta Importe la directiva de grupo de línea de base para los controladores de dominio y valide los pasos descritos en Win2KSOG 1. Importe la directiva de línea de base como se ha descrito en el capítulo 3, Importar la directiva de línea de base de controladores de dominio Baselinedc .inf Controlador de dominio bloqueado 2. Cambie el nombre de la cuenta del administrador de dominio (capítulo 4) 3. Cambie el nombre de la cuenta del administrador local (capítulo 4) 4. Reinicie el controlador de dominio 1.3 Alta Use utilidades como GpoTool y Gpresult para comprobar la configuración de la directiva de grupo para DC 1. Compruebe que la directiva se ha descargado correctamente en todos los controladores de dominio. Para hacerlo, busque el Id. de suceso 1704 en cada uno de ellos. Aplicada la confirmació n de controlador de dominio GPO 2. Compruebe que la directiva se aplica en todos los controladores de dominio mediante Local Policy Admin MMC 3. Compruebe que la directiva se aplica en todos los controladores de dominio mediante el comando secedit /analyze /db secedit.sdb /cfg nombre plantilla 4. Compruebe que la directiva se aplica mediante el comando gpresult /c 5. Compruebe que la directiva se aplica mediante el comando 218 gptool /gpo nombre de plantilla 1.4 Alta Pruebe la directiva de grupo de línea de base para los controladores de dominio y valide los pasos descritos en Win2KSOG 1. Confirme que los valores de directiva de auditoría están configurados para los controladores de dominio (capítulo 4) Los valores del controlador de dominio GPO coinciden con Win2KSOG 2. Confirme que los valores de directiva de seguridad están configurados para los controladores de dominio (capítulo 4) Confirme que los servicios adecuados se han iniciado y responden 3. Confirme que los valores de directiva de servicios están configurados para los controladores de dominio (capítulo 4) 4. Confirme que se ha iniciado la lista de servicios de línea de base y servicios de baselinedc. 1.5 Alta Importe la directiva de grupo de línea de base para los servidores miembros y mueva AP01 a OU; a continuación, valide los pasos descritos en Win2KSOG 1. Configure el servidor AP01 con todos los servicios disponibles 2. Deshabilite Archivo e Imprimir en AP01 3. Importe la directiva línea de base como se descrito en el capítulo Importar las directivas servidores miembros Baseline.in f RepAdmin o ReplMon Servidor miembro AP01 bloqueado de ha 3, de 4. Mueva Servidor de aplicaciones AP01 al Servidor de aplicaciones OU 5. Fuerce la réplica del controlador de dominio 6. Reinicie el servidor 1.6 Alta Use utilidades como GpoTool y Gpresult para 1. Compruebe que la directiva se ha descargado correctamente en el Muestre que se ha aplicado el 219 comprobar la configuración de la directiva de grupo para el servidor miembro AP01 servidor miembro AP01. Para hacerlo, busque el Id. de suceso 1704. servidor miembro AP01 GPO. 2. Compruebe que la directiva se aplica en el servidor miembro mediante Local Policy Admin MMC (página 16) 3. Compruebe que la directiva se aplica en el servidor miembro mediante el comando secedit /analyze /db secedit.sdb /cfg nombre plantilla 4. Compruebe que la directiva se aplica mediante el comando gpresult /c 5. Compruebe que la directiva se aplica mediante el comando gptool /gpo nombre de plantilla 1.7 Alta Pruebe la directiva de grupo de línea de base para servidores miembros y valide los pasos descritos en Win2KSOG 1. Confirme que los valores de directiva de auditoría están configurados para AP01 (capítulo 4) 2. Confirme que los valores de directiva de seguridad están configurados para AP01 (capítulo 4) 3. Confirme que se han configurado los servicios como se describe en los apéndices B y C 4. Confirme que los servicios de línea de base se han iniciado (compárelos con los de los apéndices) Los valores del servidor miembro AP01 GPO coinciden con Win2KSOG Los valores adicionales del Registro se aplican a AP01 Se han deshabilitad o todos los servicios en AP01 5. Confirme que se ha aplicado Denegación de entradas de registro de 220 servicio (capítulo 4) 6. Confirme que se ha aplicado la entrada de Registro de nombres de archivo 8.3 (capítulo 4) 7. Confirme que se ha aplicado la entrada de Registro LMHash (capítulo 4) 8. Confirme que se ha aplicado la entrada de Registro NTLMSSP (capítulo 4) 9. Confirme que se ha aplicado la entrada de Registro Autorun (capítulo 4) 10. Confirme que se ha aplicado el sistema de archivos de línea de base ACL (como en el Apéndice A, capítulo 4) 11. Confirme la autenticación de AP01 con el controlador de dominio Varios Baja Réplica entre sitios mediante SMTP 1. Cree un sitio nuevo La réplica debería funcionar con las directivas aplicadas 2. Mueva AD02 al nuevo sitio 3. Habilite SMTP 4. Compruebe si la réplica funciona Caso de prueb a Prioridad: 2.1 Alta Condición que se probará: Detalles de la ejecución: Ejecute HfNetChk en todos los Procedimientos de referencia en el capítulo 5 Datos Resultados necesarios: esperados: Para HfNetChk: ejecutar ·1 El resultado de HfNetChk 221 servidores de Win2KSOG ·1 SecurityOps.exe 1. Instalación ·2 nshc33.exe. ·1 Un único servidor denominado HF01 tendrá SecurityOps.ex e ·3 Qfecheck.exe ·2 Ejecute el archivo exe para crear la estructura de carpetas ·3 HF01 contiene Hfnetchk.exe en la carpeta C:\SecurityOps \PatchMgmt\Hf netchk debe almacenarse en un archivo de registro, en una carpeta con el nombre de la fecha actual. ·2 La revisión Q259444 no debe estar en la lista ·3 Compruebe el resultado de Qfecheck.exe ·4 Descargue mssecure.xmll y colóquelo en la misma carpeta que HfNetChk 2. Cree la lista de servidores con los nombres de todos los servidores y colóquela en la carpeta C:\SecurityOps \PatchMgmt\Se rverLists 3. Ejecute HfNetChk desde el símbolo del sistema con la lista de servidores HfNetChk.cmd 222 Server.txt 4. Ejecute Qfecheck.exe /v para comprobar los SP y HF instalados. 2.2 2.3 Alta Media Vuelva a ejecutar HfNetChk después de instalar algunas revisiones de la lista 1. Debe haber instalado algunas revisiones Ejecute HfNetChk con listas de varios servidores y pruebe la programación 1. Cree varias listas de servidores ·4 Lo mismo que arriba 2. Vuelva a ejecutar la herramienta como antes · Compruebe si existen errores en los registros de sucesos ·5 Lo mismo que arriba 2. Ejecute la herramienta como antes Priorid ad Condición que se probará Detalles ejecución de · Debería poder comprobarse el reultado de distintos servidores · Transcurridos 20 minutos, compruebe el sello horario 3. Use el programador de tareas para programar la activación de una línea de comandos dentro de 15 minutos. Caso de prueb a · El resultado no debería mostrar las revisiones instaladas (es posible que tenga que habilitar el programador para esto) la Datos necesarios Resultado esperado: 223 Procedimientos referencia en capítulo 4 Win2KSOG 1.1 DTP Alta 1 Importe la directiva de servidor individual para el servidor de archivos e impresión y valide los pasos descritos en Win2KSOG de el de ·6 El Id. de suceso 1704 debería constar en todos los DC 5. Importe la directiva ·5 Importe File&printIncre mental.inf 6. Mueva el servidor de archivos e impresión a F&P OU Plantilla File&print Incremental.inf ·7 Se ha iniciado el Servicio de cola de impresión. 7. Fuerce una réplica del DC 8. Reinicie el servidor FPOI 2. Alta Emplee utilidades como GpoTool y Gpresult para comprobar la configuració n de las directivas ·8 Confirme que se aplica las directiva 1. Compruebe que la directiva se ha descargado correctamente en todos los controladores de dominio. Para hacerlo, busque el Id. de suceso 1704 en cada uno de ellos. GpoTool y 2. Compruebe que la directiva se aplica en todos los controladores de dominio mediante Local Policy Admin MMC Gpresult 3. Compruebe que se ha aplicado la directiva al servidor de archivos e impresión 3 Alta Pruebe la configuració n adicional de la directiva individual del modo como se describe en Win2KSOG 1. Realice la configuración adicional como se describe en Win2KSOG 2. Conéctese a una impresora e imprima 3. Cree un recurso compartido de archivos ·9 El servidor debería poder imprimir ·10 El recurso compartido de archivos debería funcionar 224 y valídela y compruebe si un cliente puede conectarse Procedimientos referencia en capítulo 4 Win2KSOG de el de ·11 El Id. de suceso 1704 debería constar en todos los DC 1. Importe la directiva 1,2 DTP Alta 4 Importe la directiva de servidor individual para el servidor de infraestructur a y valide los pasos descritos en Win2KSOG ·6 Importe Infrastructure.i nf 2. Mueva el servidor de infraestructura a Infra OU Plantilla Infrastructure.i nf ·12 Se han iniciado el Servidor DHCP, el Servidor DNS, el Servicio WINS y NTLMssp. 3. Fuerce una réplica del DC 4. Reinicie el servidor INF01 5. Deshabilite Compartir archivos e impresoras 5. Alta Emplee utilidades como GpoTool y Gpresult para comprobar la configuració n de las directivas 1. Compruebe que la directiva se ha descargado correctamente en todos los controladores de dominio. Para hacerlo, busque el Id. de suceso 1704 en cada uno de ellos. 2. Compruebe que las directivas se aplican en todos los controladores de dominio mediante Local Policy Admin MMC ·13 Confirme que se aplica la directiva GpoTool y Gpresult 3. Compruebe que se ha aplicado la directiva al servidor INFRA 6 Alta Compruebe la configuració 1. Realice la configuración adicional como se describe en ·14 El servidor debería ser capaz de 225 n adicional de la directiva individual como se describe en Win2KSOG y valídela Win2KSOG ejecutar la funcionalidad básica de DHCP, DNS y WINS 2. Conéctese a un cliente de la red para comprobar si puede obtener la dirección 3. Confirme actualizaciones dinámicas seguras las 4. Compruebe si la resolución WINS y la resolución de nombres de NetBios funcionan Procedimientos referencia en capítulo 4 Win2KSOG de el de 1. Importe la directiva 1,3 DTP Alta 7 Importe la directiva de servidor individual para el servidor IIS y valide los pasos descritos en Win2KSOG ·16 IISIncremental. Inf ·17 exe IISLock. ·18 El Id. de suceso 1704 debería constar en todos los DC ·19 El servicio W3SVC y IISAdmin deberían iniciarse. ·7 Importe IISIncremental.inf 2. Mueva el servidor IIS a IIS OU 3. Fuerce una réplica en DC 4. Reinicie el servidor IIS01 5. Deshabilite Compartir archivos e impresoras 8. Alta Emplee utilidades como GpoTool y Gpresult para comprobar la configuració n de las directivas 1. Compruebe que la directiva se ha descargado correctamente en todos los controladores de dominio. Para hacerlo, busque el Id. de suceso 1704 en cada uno de ellos. ·20 Confirme que se aplica la directiva GpoTool y Gpresult 2. Compruebe que la directiva se aplica en todos los controladores de dominio mediante 226 Local Policy MMC Admin 3. Compruebe que se ha aplicado la directiva al servidor IIS 1.4 DTP Alta 9 Compruebe la configuració n adicional de la directiva individual como se describe en Win2KSOG y valídela 1. Ejecute IISLockd.exe, que también instalará URLscan.exe ·8 Compruebe los valores de URLScan como se describe en el capítulo 6. 2. Establezca páginas estáticas y compruebe si un cliente puede conectarse ·21 Pruebe los cambios realizados en la página Web estática ·22 Después de realizar la configuración adicional, IIS debería funcionar. al servidor Procedimientos referencia en capítulo 4 Win2KSOG de el de 1. Habilite el servicio WMI para APP01 2. Habilite el servicio de Almacenamiento extraíble para APP01 1,5 DTP 10. Alta Cambios al entorno recomendado para administraci ón remota 3. Para la administración remota de algunos servidores específicos ·9 Habilite el servicio de servidor para APP01 ·10 Habilite el registro remoto para el Servidor de infraestructura 4. Use Mi PC -> Administrar para conectarse a APP01 y comprobar todo lo anterior ·23 Debería poder administrar de forma remota lo siguiente: Carpeta compartida, grupos y usuarios locales en Administració n de almacenamient o, excepto unidades lógicas, Administrador de dispositivos de servicios, Visor de sucesos, Ejecutar registros y alertas ·24 La administración de discos, el desfragmentad 227 anterior or, y el almacenamient o extraíble funcionan 5. Un cliente debería poder conectarse al servidor F&P e imprimir Caso de prueba Prioridad 1.1 Alta Condición que se probará Instale y pruebe EventCombMT Detalles ejecución de ·25 Los servidores miembros deberían poder ejecutar la administración remota la 1. Instale EventcombMT 2. Agregue todos los servidores miembros y controladores de dominio como equipos en los que buscar (capítulo 6) Datos Resultado necesarios esperado: Eventcombmt Eventcomb informa el registro de sucesos correcto Los Id. de sucesos descritos son exactos 3. Especifique los registros y tipos de sucesos que se van a buscar 4. Busque el suceso específico 1704 (carga de GPO) 5. Reinicie DC 6. Configure la búsqueda para el reinicio de DC (capítulo 6) 7. Bloquee la 228 cuenta 8. Configure la búsqueda de bloqueos de cuentas (capítulo 6) 9. Compruebe los Id. de suceso de bloqueos de cuentas como se describe en Win2KSOG 1.2 Baja Prueba ad hoc con utilidades distintas, como Dcdiag, Repadmin, etc. 229 Ayuda de trabajo A. Tabla de análisis de amenazas y vulnerabilidades Debe determinar los riesgos para el entorno cada vez que surjan nuevas amenazas o vulnerabilidades. Esto le permitirá estar seguro de que se podrá actuar rápidamente para hacer frente a las amenazas más importantes. Utilice la tabla siguiente para registrar información sobre las amenazas y vulnerabilidades que debe afrontar. Amenaza: <escriba aquí el nombre de la amenaza> Amenaza <Nombre de la amenaza> Tipo de amenaza ¿De qué tipo son las amenazas a las que se enfrenta? Vulnerabilidad ¿A qué vulnerabilidad afecta? Explotación ¿Cómo podría la amenaza aprovechar la vulnerabilidad? Contramedida ¿Cómo se puede contrarrestar la amenaza al entorno? Gravedad En una escala de 1 a 10, ¿cuál es la gravedad de la amenaza? Esfuerzo En una escala de 1 a 10, ¿en qué medida se puede explotar la vulnerabilidad? Nivel de riesgo Gravedad/Esfuerzo Probabilidad ¿Qué probabilidad (porcentaje estimado) tiene la amenaza de convertirse en realidad? Amenaza total Riesgo x Probabilidad Resultado intromisión de la ¿Qué sucede cuando los atacantes aprovechan las vulnerabilidades? Riesgo de pérdidas (pérdida estimada) Pérdida financiera estimada Exposición Riesgo de pérdidas x Probabilidad Mitigación/Asignación Si tiene que dejar la vulnerabilidad abierta, ¿cómo la protege? Respuesta incidencia ¿Qué puede hacer si sufre un ataque? a la Propietario ¿Quién es responsable? Estado ¿En qué estado está actualmente la vulnerabilidad ("Cerrada", "Abierta" o "Mitigada")? Versión del software ¿A qué versión del software afecta? 230 B. Los 11 problemas de seguridad más frecuentes en el cliente 1. Errores de contraseñas a. Contraseñas no seguras. Los usuarios tienen una tendencia natural a seleccionar contraseñas fáciles de recordar (y, por tanto, fáciles de averiguar). Aunque es posible forzar el uso de contraseñas complejas mediante las Directivas de seguridad de Windows 2000, la responsabilidad última de la seguridad de las contraseñas depende de cada usuario. Las contraseñas suelen estar inspiradas en nombres de hijos o mascotas, fechas de cumpleaños o palabras relacionadas con el entorno de trabajo. Y lo que es peor, pueden estar a la vista. b. Consecuencias de compartir contraseñas entre usuarios. En concreto, en entornos en los que se comparten equipos, los usuarios tienden a revelar sus contraseñas. Esta práctica pone en peligro la seguridad y debe prohibirse. c. Consecuencias de emplear la contraseña interna de la organización en sitios Web externos. Si los usuarios exponen la contraseña fuera de su organización, ésta será más vulnerable a los ataques. Las contraseñas de los usuarios se suelen almacenar con las direcciones de correo electrónico. Con sólo utilizar esa combinación, un atacante puede determinar la organización para la que trabaja el usuario, el nombre del usuario en la red (si fuera el prefijo de la dirección SMTP) y su contraseña de usuario. 2. Consecuencias de no realizar copias de seguridad adecuadas o almacenar información vital localmente en vez de almacenarla en un servidor central. En muchas organizaciones, no se realizan copias de seguridad de los equipos cliente (especialmente de los discos de portátiles). El almacenamiento local de información en los equipos cliente, en lugar de hacerlo en servidores administrados, puede impedir la recuperación de datos después de un ataque. 3. Estaciones de trabajo abiertas y desatendidas. ¿Hay alguna directiva activa que inste a los usuarios a bloquear sus estaciones de trabajo cuando se alejen de ellas? Si no se hace esto, alguien que esté de paso podría configurar fácilmente medios para tener acceso a la estación de trabajo fuera del horario de oficina (por ejemplo, instalando un cliente de Terminal Server, PC Anywhere o ampliando los privilegios locales). 4. Consecuencias de no instalar las actualizaciones y revisiones del proveedor. Todos los productos de software y hardware tienen vulnerabilidades y suelen estar en estado de desarrollo continuo. Normalmente, se lanzarán mejoras de diseño y características, así como correcciones de errores, durante la vida útil del software. Como los productos de software y, en menor medida, los de hardware cambian constantemente, es fundamental que el personal de TI instale las revisiones, actualizaciones y correcciones de los sistemas. No mantener los equipos actualizados ofrece ventajas a los atacantes. 5. Consecuencias de no establecer la seguridad física de los equipos. Los equipos, en particular los portátiles, son con frecuencia objetivo de robo. Un portátil en manos de un atacante, especialmente si pertenece a un usuario con un nivel alto de acceso al sistema, puede convertirse en una grave amenaza de seguridad. 6. Deshabilitar o reducir los controles de seguridad existentes. Los usuarios suelen deshabilitar la protección antivirus para intentar obtener mayor velocidad de procesamiento. Además, para conseguir mayor comodidad de uso, reducen o quitan la protección de seguridad de macros de las aplicaciones de producción, como Microsoft Word, Microsoft Excel, etc. Es importante dejar claro a los usuarios la importancia de mantener los controles de seguridad. 231 7. Consecuencias de instalar software innecesario o no aprobado. Los usuarios que suelen instalar software no autorizado o no aprobado ponen a la organización en peligro al ejecutar aplicaciones que podrían contener caballos de Troya u otros vehículos que representen una amenaza para la seguridad. 8. Consecuencias de exponer más información personal de la necesaria. Si revela los nombres de los hijos, fechas de cumpleaños, etc., podría dar más oportunidades a los atacantes de adivinar contraseñas u obtener acceso no autorizado mediante ingeniería social. La información se puede revelar directamente, de forma oral hablando por teléfono con los atacantes, por correo electrónico, o de forma pasiva mediante la información visible en la zona de trabajo (fotos de los hijos, información que contiene el número de seguridad social, tarjetas sanitarias, etc.). 9. Consecuencias de propagar virus y otras trampas. Los virus inofensivos y las falsas alarmas que se suelen distribuir masivamente por correo electrónico cuestan tiempo y dinero por sí mismos. Debe asegurarse de que los usuarios envían esta información directamente al departamento de TI, en lugar de distribuirla por la organización. 10. Consecuencias de abrir archivos adjuntos de mensajes no esperados. Una de las medidas de seguridad más eficaces para prevenir incidencias de seguridad es tomar precauciones con el correo recibido y al abrir los mensajes adjuntos que contengan. 11. Consecuencias de no formar a los usuarios para detectar problemas de seguridad y tomar precauciones. Se pueden mitigar y evitar muchas incidencias si se forma a los usuarios para detectar indicios de ataque, daños en la configuración, virus u otras incidencias. También se les debe formar para tomar las medidas apropiadas cuando detecten un ataque. C. Los 8 problemas de seguridad más frecuentes en el servidor 1. Errores de contraseñas a. Contraseñas no seguras. El personal de TI suele crear puertas traseras como medida de protección antibloqueo. Las contraseñas de estas puertas traseras suelen ser más sencillas, más fáciles de recordar y, por tanto, menos seguras. Aunque esta situación se puede mitigar parcialmente aplicando y forzando las Directivas de seguridad de Windows 2000, debe asegurarse de que los usuarios con acceso de alto nivel están sujetos a la Directiva de grupo. b. Consecuencias de compartir contraseñas entre miembros del personal de TI. Por ejemplo, si se concede a más de un usuario acceso a la cuenta del Administrador, será difícil o imposible realizar la auditoría y determinar las responsabilidades en caso de que se produzca un suceso de seguridad que implique esa cuenta. Los usuarios, especialmente el personal de TI, deben tener una responsabilidad individual auditable de sus cuentas. La prohibición de compartir contraseñas debe formar parte de una directiva de seguridad firmada por los usuarios y el personal de TI. c. Consecuencias de emplear la contraseña interna de la organización en sitios Web externos. Si los usuarios exponen la contraseña fuera de su organización, ésta será más vulnerable a los ataques. Las contraseñas de los usuarios se suelen almacenar con sus direcciones de correo electrónico. Si sólo se utiliza esa combinación, un atacante podría determinar dónde trabaja un usuario, cuál es su nombre de usuario (especialmente si se trata del prefijo de la dirección SMTP) y su contraseña. 2. Consecuencias de no implementar todos los niveles de seguridad de la estrategia de defensa en profundidad. Aunque es importante instalar y configurar correctamente un servidor de seguridad y un sistema de detección de intrusos, las contramedidas de seguridad no deben 232 quedarse en esto. Por ejemplo, la estrategia de defensa en profundidad debe especificar los controles de nivel administrativo y personal. Muchas empresas no forman al personal de atención al público (por ejemplo, recepcionistas y operadores telefónicos) para que puedan reconocer y proteger los datos confidenciales. Un error común es sentirse seguro sin haber protegido realmente el sistema contra todas las posibilidades de ataque. Para obtener más información sobre la metodología de defensa en profundidad, vea el "Capítulo 2" de esta guía. 3. Consecuencias de no realizar y validar copias de seguridad del sistema de forma coherente. Muchas organizaciones, incluidas algunas grandes, no tienen un sistema apropiado de copia de seguridad de los datos del sistema. De las pocas que realmente hacen copias de seguridad, no hay muchas que dediquen tiempo a restaurar los archivos o a hacer otro tipo de validación de cada operación de copia de seguridad. Esto puede producir situaciones en las que se descubre demasiado tarde que conjuntos enteros de medios de copia de seguridad están dañados y no se pueden utilizar para restaurar los datos perdidos en caso de ataque o error grave. 4. Consecuencias de ejecutar servicios innecesarios. En general, las instalaciones predeterminadas habilitan más servicios de los necesarios. Estos servicios adicionales proporcionan más entradas para posibles ataques y deben deshabilitarse. Sólo se deben ejecutar los servicios necesarios. Hay que auditar los servicios periódicamente para comprobar si aún son necesarios. 5. Consecuencias de no reconocer amenazas de seguridad internas. La tendencia natural es centrar los esfuerzos de seguridad y los recursos en posibles ataques externos a la organización. A veces, esta tendencia hace que se olvide la mayor amenaza potencial: el personal interno de la organización. El personal interno tiene mayor nivel de acceso y, por tanto, representa la mayor amenaza potencial de ataque, ya sea de forma intencionada o no. 6. Consecuencias de no aplicar la directiva de seguridad. Una directiva de seguridad excelente, pero aplicada de forma poco estricta, no será de gran ayuda para la seguridad de la organización. Relajar la directiva de seguridad también tiene el peligroso efecto secundario de hacer que los usuarios no sean conscientes de la importancia de la seguridad. 7. Consecuencias de conceder a los servicios más privilegios de los necesarios. Los servicios necesitan un determinado nivel de acceso para poder realizar tareas específicas en el contexto del sistema. Al instalar estos servicios o solucionar los problemas que tengan, se puede sentir la tentación de concederles más acceso del necesario a fin de restablecer el funcionamiento rápidamente. Para mantener la seguridad del sistema, los servicios deben tener la menor cantidad posible de privilegios. Debe asegurarse de que los administradores del sistema que configuran los privilegios de servicios y los programadores de aplicaciones que crean dependencias de servicios tienen esto en cuenta. 8. Consecuencias de no restringir suficientemente las aplicaciones desarrolladas internamente. El control de la seguridad de las aplicaciones desarrolladas internamente debe ser igual o superior que el de las aplicaciones de otros fabricantes. D. Ataques y contramedidas 233 Contramedidas estándar Forzar el uso de contraseñas complejas Averiguación contraseñas de Desbordamientos del búfer Habilitar registro y auditoría Revisar la configur ación del sistema Desha bilitar servic ios Aplicar un sistema de detecció n de intrusos Utilice los mayores niveles de cifrado. ü ü ü Cifrado de datos Firmas digitales Instalar un servidor de seguridad ü ü Fuerce la validación en el SO y las aplicaciones del tamaño del búfer y, preferentemente, el tipo de datos que acepta. Utilice un servidor de seguridad para aplicaciones. ü ü ü Interceptación de paquetes en la red Restrinja la conectividad de red local y los controles de hardware. Utilice herramientas de detección de programas de interceptación. ü ü ü Ataques repetición de Establezca contraseñas no repetibles, evite la interceptación de paquetes ü ü Secuestro de sesión Elimine números de secuencia TCP predecibles, implemente SSL, fuerce el uso de las cookies y evite la conectividad de red local. Robo de Restrinja el acceso directo mediante un ü ü Direct ivas y proce dimie ntos de seguri dad Implementar barreras ü ü* ü ü ü ü ü ü ü Restricc iones de aplicaci ones Actualizar con revisiones de proveedore s ü ü ü ü ü ü 234 información Destrucción documentos (exploración electrónica productos) servidor de seguridad basado en proxy, implemente un sistema inteligente de detección de intrusos que pueda actualizar dispositivos de filtrado, requiera autenticación antes de permitir el acceso a las aplicaciones y aísle los dominios de seguridad mediante servidores de seguridad. de de Revise toda la información disponible públicamente para comprobar si satisface las directivas de seguridad. Por ejemplo, calcule cuántas direcciones de correo electrónico específicas se pueden averiguar a partir de un sitio Web público. Determine si estas direcciones de correo electrónico están relacionadas directamente con las cuentas de usuario. Fugas de información en comunicaciones inalámbricas Reduzca la zona de conectividad inalámbrica, implemente restricciones de hardware y utilice autenticación multifactor. Ingeniería social Aplique directivas estrictas y un programa de formación. Ataques de denegación de servicios y denegación de servicios distribuida Recopile líneas de base para definir los niveles de servicio normales. Todos los accesos deben concederse con los privilegios más bajos que sea posible. Aplique filtrado de entrada de red para reducir el número de paquetes falsos de IP. (vea los detalles en RFC 2267). Implemente filtros de enrutador, habilite sistemas de cuotas, supervise el rendimiento del sistema, supervise firmas de ataque de Denegación de servicio distribuida mediante un sistema de detección de intrusos, aplique soluciones de tolerancia a errores y equilibrio de carga. Aplique mejoras de pila TCP/IP del proveedor. ü ü ü ü ü ü ü ü ü 235 Explotación de las cookies Ataques CGI mediante Ataque a la caché de DNS Para los implementadores de cookies: hay que incluir la menor cantidad de información posible, no se debe utilizar NUNCA texto sin formato para almacenar información en cookies y se deben utilizar rutas específicas cuando sea posible. ü ü Asegúrese de que las secuencias de comandos CGI controlan dinámicamente distintos tamaños de los datos recibidos de usuarios y que nunca pasan datos de usuarios remotos sin comprobar a un comando del shell; considere la posibilidad de utilizar un encapsulador de CGI. Utilice Secure DNS (SDNS) e implemente un DNS dividido en un DNS interno confiable y un DNS externo no confiable. Los dos pueden estar en el mismo servidor de seguridad. Restrinja y autentique las transferencias de zona. ü ü Correo electrónico falsificado Utilice firmas o certificados digitales. Evite la retransmisión de correo o la suplantación de servidores SMTP. ü ü Suplantación dirección IP Aplique filtrado de entrada de red (vea los detalles en RFC 2827). ü ü Virus Gusanos de ü Forme a los usuarios finales para determinar el comportamiento de los virus y la respuesta correcta, prevenir la deshabilitación del software de detección de virus y forzar la actualización periódica de la firma de virus. Utilice sólo software de confianza. ü ü Forme a los usuarios finales para determinar el comportamiento de los virus y la respuesta correcta, prevenir la deshabilitación del software de detección de virus y forzar la actualización periódica ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü 236 de la firma de virus. Caballos de Troya Abuso de personal interno Eliminación cambio configuración servicios accidentales o de de Forme a los usuarios finales para determinar el comportamiento de los virus y la respuesta correcta, prevenir la deshabilitación del software de detección de virus y forzar la actualización periódica de la firma de virus. Utilice sólo software de confianza. La amenaza de ataque de un miembro de la plantilla es la más difícil de reducir o eliminar. Implemente directivas estrictas, divida las responsabilidades y las obligaciones, y aplique restricciones de privilegios, revisión de compañeros, rotación de puestos y un sistema de detección de intrusos. Limite el ámbito de la autoridad (sólo se debe iniciar sesión con los permisos de Administrador de empresa o Administrador de dominio cuando sea necesario). ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü Si se dispone de copias de seguridad actualizadas que se puedan restaurar rápidamente, se podrán mitigar los errores debidos a torpezas. Aplique un programa de formación intenso y, cuando sea necesario, un programa de revisión de compañeros. 237 E. Guía de referencia rápida de respuesta a incidencias Utilice la siguiente lista de comprobación como guía de ayuda para completar de forma efectiva los pasos necesarios de las medidas de respuesta a incidencias. Debe tener en cuenta que el orden exacto de los pasos dependerá del tipo de organización y el tipo de incidencia. Para obtener más información sobre Respuesta a incidencias, consulte el capítulo 7, "Responder a las incidencias". Instrucciones generales de respuesta a incidencias Anote todos los detalles. Considere la posibilidad de grabar sus comentarios en cinta. Anote quién llevó a cabo las acciones, cuándo y por qué. Mantenga la calma. Evite la tendencia de una reacción excesiva o de entrar en pánico. Siga meticulosamente los pasos de la directiva de seguridad. Utilice un medio de comunicación fuera de banda: teléfono, fax o comunicación cara a cara, por ejemplo. Es posible que el atacante esté a la escucha. Permanezca en comunicación constante con otros equipos o individuos afectados. No reinicie el equipo, ni inicie o cierre sesiones, ya que esto podría activar código dañino. Primer objetivo: hacer la valoración inicial de la incidencia 1.1 Póngase en contacto con el equipo técnico para comprobar que la incidecia no es una falsa alarma. 1.2 Examine los registros de auditoría para detectar si hubo actividad inusual, o desaparición de registros o fragmentos de los mismos. 1.3 Busque herramientas de hackers (programas de averiguación de contraseñas, caballos de Troya, etc.). 1.4 Compruebe si hay automáticamente. 1.5 Examine las cuentas para detectar posibles aumentos de privilegios o miembros de grupo no autorizados. 1.6 Compruebe si hay procesos no autorizados. 1.7 Piense en la forma de conservar las pruebas. 1.8 Compare el rendimiento del sistema afectado con la línea de base. 1.9 Asigne a la incidencia un nivel de prioridad inicial y un responsable. aplicaciones no autorizadas configuradas para iniciarse Segundo objetivo: comunicar la incidencia 238 2.1 Comunique la incidencia a los grupos interesados y a los miembros asociados al CSIRT pertinentes. Tercer objetivo: contener los daños y minimizar el riesgo 3.1 Determine la gravedad de la incidencia y compruebe la directiva de seguridad para decidir si tiene que desconectar de la red los sistemas afectados para aislarlos. 3.2 Cambie las contraseñas de los sistemas afectados. 3.3 Haga copias de seguridad de los sistemas para poder recuperarlos y, si fuera necesario, obtener pruebas. Cuarto objetivo: identificar el tipo y la gravedad de las intromisiones 4.1 Determine el tipo de ataque. 4.2 Determine el objetivo del ataque (ataque dirigido específicamente a la organización, automatizado o para obtener información). 4.3 Identifique todos los sistemas implicados en el ataque. Si se identifican más sistemas afectados, revise los pasos de las medidas de contención. 4.4 Evalúe de nuevo el nivel de prioridad del suceso y, si fuera necesario, asígnele otro nivel de prioridad. Quinto objetivo: conservar las pruebas 5.1 Realice lo antes posible copias de seguridad de los sistemas y guárdelas en discos de almacenamiento que no se hayan utilizado nunca en el ciclo de respuesta y recuperación. 5.2 Si es posible, realice copias de seguridad de los sistemas completos, incluidos los registros y el estado del sistema. 5.3 Mantenga una cadena de custodia comprobable de las pruebas obtenidas. 5.4 Proteja las pruebas y anote en un documento quién las obtuvo, cómo, cuándo y quién ha tenido acceso a las mismas. Sexto objetivo: notificar la incidencia a las agencias externas 6.1 Avise a las fuerzas de la ley locales o nacionales, asesorado por un consejero jurídico. 6.2 Informe del resultado a los miembros de relaciones públicas de CSIRT y proporcióneles asistencia, si fuera necesario. 6.3 Avise a otras agencias pertinentes, como CERT (Coordination Center at Carnegie Mellon University, http://www.cert.org/, sitio Web en inglés). Ésta y otras agencias similares pueden proporcionar información valiosa para recuperar datos. 239 Séptimo objetivo: recuperar los sistemas 7.1 Busque y valide las copias de seguridad más recientes que no se hayan visto afectadas. 7.2 Restaure el sistema. 7.3 Valide el funcionamiento del sistema y compare su rendimiento con líneas de base históricas. 7.4 Supervise la aparición de ataques repetidos y los cambios de configuración causados por los pasos de contención. Octavo objetivo: recopilar y organizar la documentación sobre la incidencia 8.1 Recopile todas las notas y grabaciones en un registro de actividad de la incidencia de seguridad. 8.2 Distribúyalo a los participantes en la incidencia, para que lo revisen y aprueben (incluido el consejero legal, para que determine la validez de las pruebas). 8.3 Revise la causa de la infracción de seguridad y mejore las defensas para prevenir ataques similares en el futuro. 8.4 Ayude al departamento de finanzas a evaluar las pérdidas debidas a la infracción de seguridad. 8.5 Prepare un informe para la dirección y otros grupos interesados para explicar cómo se produjo el evento e informar de las pérdidas debidas a la infracción de seguridad y las medidas de prevención que se van a adoptar. 240
