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 [email protected]) 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
Descargar