Aislamiento de servidor y dominio mediante IPsec y Directiva de grupo

El objetivo de este capítulo es facilitar instrucciones para la implementación del diseño del aislamiento de servidor y dominio. Los capítulos anteriores explican el proceso de diseño y la lógica tras las instrucciones facilitadas en este capítulo. Si todavía no lo ha hecho, le recomendamos que lea esos capítulos antes de seguir con éste.

Este capítulo facilita instrucciones para implementar los requisitos de seguridad de los grupos de aislamiento de dominios y los grupos de aislamiento de servidor que se mencionan en el capítulo 4, "Diseño y planificación de grupos de aislamiento". Una combinación de los elementos siguientes implementará estos requisitos:

Aquí se explica cómo preparar la solución con la Directiva de grupo y las directivas IPsec en el servicio de directorios Active Directory® con Microsoft® Windows Server™ 2003, y la configuración de miembros de dominio con Windows Server 2003 y Microsoft Windows® XP. Además, este capítulo discute alternativas de diseño y opciones de ejecución. También se proporcionan listas de control para comprobar que el diseño satisface todos los requisitos empresariales y de seguridad.

En esta página

	Requisitos previos
	Creación de Directivas IPsec en Active Directory
	Autorización del acceso entrante para un grupo de aislamiento
	Consideraciones adicionales sobre IPsec
	Resumen

Requisitos previos

Esta sección contiene información que le ayudará a determinar la capacitación de su organización para implementar la solución IPsec. (La capacitación se indica en un sentido lógico más que un sentido empresarial. La motivación empresarial para implementar esta solución se discute en el capítulo 1 de esta guía, "Introducción al aislamiento de servidor y dominio").

Requisitos previos de conocimientos

Debe estar familiarizado con los conceptos generales de IPsec y, en concreto, con la implementación de IPsec por parte de Microsoft. También debe estar familiarizado con Windows Server 2003 en las siguientes áreas:

Antes de seguir con este capítulo, debería haber leído las instrucciones de planificación que proporcionan los capítulos anteriores de esta guía y debería comprender bien los conceptos arquitectónicos y de diseño de la solución. También debería haber definido y documentado los requisitos empresariales de la solución como parte de la matriz de requisitos de la solución.

Requisitos previos organizativos

Debe consultar a otras personas de su organización que quizás deberían implicarse en la planificación de la solución, incluidas las siguientes:

Requisitos previos de la infraestructura de TI

Este capítulo también asume que existe la siguiente infraestructura de TI:

Este capítulo también requiere una comprensión total de la infraestructura de TI existente para asegurarse de que se implementan las directivas correctas a los hosts previstos en el entorno. El capítulo 3, "Cómo determinar el estado actual de su infraestructura de TI", describe la información necesaria y el modo de obtenerla. No debe llevar a cabo los pasos que se describen en este capítulo hasta obtener como mínimo la información siguiente:

Principio de la página

Creación de Directivas IPsec en Active Directory

El proceso de creación de las directivas necesarias para admitir los grupos de aislamiento requeridos consiste en las siguientes tareas principales:

Antes de iniciar el proceso de creación de estos componentes, es importante obtener los diagramas de modelo de tráfico y las tablas del capítulo 4, "Diseño y planificación de grupos de aislamiento", así como las tablas de asignación de host y red. Estas tablas facilitan la información necesaria para garantizar que las directivas proporcionan la funcionalidad necesaria y se asignan a los grupos de aislamiento adecuados.

La figura siguiente muestra la configuración de red utilizada para similar el escenario de Woodgrove Bank.

Figura 5.1 Configuración de red para Woodgrove Bank
Ver imagen a tamaño completo

La configuración del laboratorio de pruebas de Woodgrove Bank ejemplifica las capacidades principales de la solución siguientes:

Además, este entorno de laboratorio ejemplifica las siguientes funcionalidades requeridas de Windows IPsec y prueba la compatibilidad con otras tecnologías de seguridad utilizadas en entornos reales:

El escenario de laboratorio que se ilustra en la Figura 5.1 se utilizó para probar que se obtuvo la funcionalidad adecuada en todos los grupos de aislamiento para la solución. En total se crearon cuatro directivas IPsec y se asignaron a los grupos de aislamiento que aparecen con guiones en negrita en la figura (es decir, el dominio de aislamiento, el grupo de aislamiento Cifrado, el grupo de aislamiento Sin reserva y el grupo de aislamiento Límite). Las secciones siguientes explican cómo se crearon estas directivas.

Descripción general de componentes de la directiva IPsec

Una directiva IPsec consiste en un número de componentes que se utilizan para aplicar los requisitos de seguridad IPsec de la organización. La siguiente figura muestra los diversos componentes de una directiva IPsec y cómo están asociados entre sí.

Tabla 5.2 Componentes de la directiva IPsec
Ver imagen a tamaño completo

La directiva IPsec actúa como contenedor para un conjunto de reglas que determinan qué tráfico de comunicaciones de red se permite y cómo. Cada regla consiste en una lista de filtros y una acción asociada. La lista de filtros contiene una agrupación de filtros. Cuando el tráfico coincide con un filtro específico, se desencadena la acción de filtrado asociada. Además, las reglas definen qué métodos de autenticación se utilizan entre hosts.

Este diagrama muestra los componentes de la directiva de forma descendente. Sin embargo, la forma más eficaz de crear directivas es empezar por los filtros y listas de filtros, pues son las unidades fundamentales que controlan qué tráfico se protege.

Listas de filtros IPsec

Las listas de filtros IPsec son conjuntos de uno o varios filtros que se utilizan para realizar correspondencias del tráfico de red según los criterios para cada filtro. Cada filtro de la lista de filtros define los siguientes elementos:

Las listas de filtros y acciones de filtrado se diseñaron para compartirse entre directivas IPsec. Este enfoque permite mantener una lista de filtros para un tipo determinado de exención y utilizarla en la directiva IPsec individual para cada grupo de aislamiento. Sin embargo, los filtros que forman las listas de filtros no pueden compartirse entre listas de filtros. Si dos listas de filtros tienen filtros idénticos, los filtros deberán crearse dos veces, una vez para cada lista de filtros.

El administrador de IPsec debe evitar duplicar los filtros en una directiva IPsec, ya que pueden tener acciones separadas. El servicio IPsec puede cambiar la consignación de filtros duplicados al procesamiento de paquetes y obtener resultados inconsistentes. Si es necesario, pueden utilizarse filtros duplicados cuando los filtros presentan exactamente la misma acción, como permitir o bloquear, y no se ve afectado el rendimiento.

La información que ha recogido sobre la red se utilizará para identificar los diversos patrones de tráfico que el administrador desea proteger. Además, también se utilizará para identificar el tráfico que debe excluirse de las restricciones IPsec.

En la tabla siguiente se describen algunas listas de filtros básicos que pueden existir en una organización típica. Según los requisitos empresariales de la organización y el diseño de la red, podrían necesitarse listas de filtros adicionales.

Tabla 5.1: Listas de filtros proporcionados por la solución

La Lista de subredes seguras incluye todas las subredes de la red interna de la organización. Esta lista de filtros está asociada con una acción de filtrado que implementa las acciones necesarias para un grupo de aislamiento concreto. Esta acción es la acción de seguridad más amplia para todo el tráfico de red para dicha subred (por ejemplo, negociar IPsec), pues otros filtros, como el filtro de ICMP, serán más específicos y requerirán una acción distinta (como permitir). Es importante recordar que este enfoque significa que en dichas subredes no debe haber ningún host que no sea de confianza o no incluya IPsec.

Los filtros deben implementar requisitos de seguridad entrantes y salientes. Al definir los filtros, deben configurarse como reflejados. Ello garantiza que el tráfico coincide cuando se utilizan las direcciones de origen y de destino opuestas exactas. En la descripción de los filtros, el símbolo "<->" se utiliza para indicar que el filtro se ha reflejado. Los filtros reflejados se utilizarán cuando la acción de filtrado negocie métodos de seguridad para la encapsulación IPsec.

Direcciones de origen y de destino

Cada filtro tiene una configuración para las direcciones de origen y de destino. Windows XP y Windows Server 2003 tienen más opciones para direcciones que Windows 2000. Por lo tanto, sólo deberá utilizar las configuraciones de Windows 2000 si esta plataforma es un miembro del dominio. Estas son las configuraciones de Windows 2000:

Protocolos

Además de la configuración de la dirección de origen y destino, cada filtro puede configurarse para que coincida con un protocolo o puerto específico. De forma predeterminada, el filtro coincidirá con el tráfico de todos los protocolos y todos los puertos. Si se selecciona un protocolo específico que admite puertos como parte de los criterios de filtrado, el administrador tiene la opción de configurar también puertos de origen y de destino.

Puertos de origen y de destino

Aunque los filtros pueden configurarse para que coincidan con los puertos TCP o UDP, esta solución no recomienda la creación de filtros específicos para los puertos. El filtrado de puertos mejora ampliamente la carga administrativa y la complejidad de la configuración de los filtros IPsec y puede exigir una coordinación compleja entre las directivas de cliente y servidor para que IKE negocie satisfactoriamente la seguridad. Puesto que esta solución asume que la comunicación entre equipos de confianza es de confianza, los filtros permiten que IPsec proteja todo el tráfico (excepto ICMP). Si es necesario el filtrado de puerto en el host de confianza, consulte Business_Requirements.xls, donde encontrará los requisitos de seguridad que se satisfacen utilizando la combinación de IPsec y un servidor de seguridad basado en host (como Windows Firewall) colocado encima de la capa IPsec.

Para evitar diversos problemas que se mencionan en el Apéndice A en relación con el comportamiento de los filtros con "Mi dirección IP", esta solución utiliza filtros Cualquiera <-> subred para el escenario de Woodgrove Bank. Se crea una lista de filtros que consiste en múltiples filtros "Cualquier dirección IP <-> Una subred específica", en los que todas las subredes de la organización se listan explícitamente. Este enfoque permite al administrador definir las subredes específicas que deberían protegerse. Cualquier tráfico que quede fuera de las subredes especificadas no coincidirá con ningún filtro IPsec y se enviará en texto sin formato al host de destino.

Para obtener más prácticas recomendadas en el diseño de filtros, consulte la sección "Prácticas recomendadas" de las notas del producto de ejemplo para el departamento de TI, "Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPsec)" (Mejorar la seguridad con el aislamiento de dominios: el departamento de TI de Microsoft implementa la seguridad IP (IPsec)), en Microsoft TechNet: www.microsoft.com/technet/itsolutions/msit/
security/ipsecdomisolwp.mspx.

Consideraciones de la lista de exenciones

No todo el tráfico puede protegerse con IPsec por motivos de compatibilidad, motivos técnicos o motivos empresariales. Además, los equipos que no tengan el sistema operativo Windows pueden no ser compatibles con IPsec o puede que la implementación de IPsec en estos equipos sea difícil. Los equipos con versiones anteriores de Windows, como Microsoft Windows NT® versión 4.0, Windows 95 y Windows 98, no son capaces de procesar IPsec basado en Directivas de grupo. Finalmente, los equipos no administrados con Windows 2000 o posterior sólo pueden participar en la negociación de IPsec si la directiva se transfiere manualmente a los equipos individuales y se utiliza algún tipo de autenticación distinta al protocolo Kerberos versión 5 (como una clave o certificado previamente compartidos).

Además, un equipo con Windows 2000 o posterior debe tener conectividad de red y ser capaz de obtener una directiva IPsec del dominio antes de establecer IPsec. Actualmente, para la conexión a la red, la localización de un controlador de dominios y la recuperación de la directiva es necesario que los servicios de la infraestructura pertinente queden excluidos de la seguridad IPsec. Entre estos servicios se incluyen los servicios de nombres como DNS y WINS y los propios controladores de dominios.

Además de estos servicios de infraestructura, en la organización podrían existir otros servicios que no admitan IPsec. Por ejemplo, los clientes menores u otros clientes bootstrap que necesitan descargar una imagen de Servicios de implementación avanzada (ADS) o Servicios de instalación remota (RIS) no admiten IPsec. Si en la red existen servidores que proporcionan estos servicios, deberán examinarse para incluirlos en una lista de exenciones o convertirlos en miembros del grupo de aislamiento Límite para que puedan aceptar comunicaciones de red de host incapaces de utilizar IPsec.

Nota: la decisión de incluir los servidores que proporcionan ADS, RIS u otros servicios de este tipo en listas de exención o convertirlos en miembros del grupo de aislamiento Límite está basada en factores de riesgo y facilidad de administración. En cualquier caso, deberá analizar con todo detalle la opción seleccionada.

Si un cliente no es capaz de participar en la infraestructura IPsec pero tiene una necesidad empresarial de tener acceso a un servidor que utiliza IPsec, debe implementar algún método para permitir establecer una vía de comunicación. La solución de esta guía utiliza listas de filtros de exención para controlar estos requisitos de tráfico mediante permisos. Las listas de exención están diseñadas en la infraestructura IPsec para garantizar que pueden tener lugar todas las comunicaciones de host requeridas, incluso si no pueden utilizarse las negociaciones IPsec.

Las listas de exención se utilizan para rechazar selectivamente el tráfico y evitar que participe en la infraestructura IPsec permitiendo el tráfico que coincide con los filtros de las listas de exención. Estas listas deben diseñarse cuidadosamente, porque se saltan los mecanismos de seguridad que implementa IPsec. Por ejemplo, la colocación en un filtro de exención de un servidor que normalmente se protege mediante cifrado (para proteger la información propia) permitirá a los equipos invitados comunicarse directamente con el servidor sin utilizar IPsec.

Las listas de exención se implementan como listas de filtros para minimizar el tamaño de la lista y facilitar la configuración de la interfaz del usuario (UI). Por ejemplo, debería tener una lista con los filtros para todos los controladores de dominios o para los controladores de dominios de cada dominio. Una segunda ventaja de tener varias listas de filtros es que la regla Permitir puede habilitarse/deshabilitarse en la directiva IPsec fácilmente para cada lista de filtros.

Al diseñar una regla que implemente la exención en la directiva IPsec, el objetivo es conseguir que el tráfico no protegido por IPsec sea el mínimo posible. Sin embargo, existen concesiones en cuanto a la complejidad y el tamaño de la directiva IPsec, a diferencia de la seguridad obtenida utilizando los filtros más específicos. Tenga en cuenta que todas las direcciones IP de controladores de dominios en todos los bosques de confianza deben estar exentas, para que los clientes de un dominio o bosque puedan obtener vales de Kerberos para servidores de otros dominios o bosques de confianza. El cliente Kerberos de Windows requiere ICMP, Protocolo ligero de acceso a directorios (LDAP) UDP 389 y Kerberos UDP 88 y tráfico TCP 88, tanto para sus propios controladores de dominio como para los controladores de dominio de otros dominios. Los miembros de dominio requieren tipos de tráfico adicionales con los controladores de dominio de su propio dominio, como bloques de mensaje del servidor (SMB) TCP 445, llamada a procedimiento remoto (RPC) y LDAP TCP 389. Si los requisitos de seguridad no son extremos, la exención se implementará para "todo el tráfico" con las direcciones IP del controlador de dominios para mejorar la simplicidad y reducir el número de filtros.

Resulta tentador intentar excluir el tráfico de aplicaciones determinadas por puerto en lugar de por dirección de destino para evitar tener que mantener una lista de direcciones como Telnet saliente mediante TCP a través del puerto 23 y acceder así a los sistemas UNIX. Por ejemplo, tenga en cuenta la siguiente exención de salida:

    Mi dirección IP a Cualquier dirección IP, TCP, puerto de origen Cualquiera, puerto de destino 23, reflejado

El filtro entrante correspondiente sería el siguiente:

    Cualquier dirección IP a Mi dirección IP, TCP, puerto de origen 23, puerto de destino Cualquiera

El filtro entrante permitirá respuestas de solicitudes de conexión Telnet, pero también permitirá que un atacante se salte los requisitos de autenticación de IPsec y acceda a cualquier puerto abierto del host. Las organizaciones deberán evaluar cuidadosamente los riesgos de seguridad de un ataque potencial de este tipo antes de utilizar este diseño de filtros. El riesgo se minimiza si se especifica la dirección IP de destino. La misma situación puede darse si la exención predeterminada para el protocolo de autenticación Kerberos no está deshabilitada. Consulte los artículos de Microsoft Knowledge Base (KB) 81183, en http://support.microsoft.com/?kbid=811832, y 810207, en http://support.microsoft.com/?kbid=810207, para obtener una discusión detallada del diseño y el impacto para la seguridad de las exenciones predeterminadas. Debería diseñar las directivas IPsec asumiendo que no se ha habilitado ninguna exención predeterminada.

La colocación de las direcciones del sistema en una lista de exenciones excluye de forma eficaz dichos sistemas de la participación como hosts IPsec para todas las directivas IPsec que implementan la lista de exenciones. Puesto que la mayoría de clientes de la organización (incluidos los clientes invitados) normalmente necesitarán tener acceso a servicios de infraestructura como DHCP, DNS o WINS, los servidores que proporcionan estos servicios suelen implementarse de esta forma.

Listas de filtros de Woodgrove Bank

Tras analizar los resultados de los requisitos de tráfico del capítulo 4, los administradores de Woodgrove Bank proyectaron las listas de filtros que aparecen en la tabla siguiente:

Tabla 5.2: Ejemplos de lista de filtros para Woodgrove Bank

Los diseñadores de Woodgrove Bank siguieron las instrucciones de este capítulo para crear estas listas de filtros. La primera lista, la lista de subredes seguras, consiste en dos filtros:

Estos filtros de subred se reflejan para coincidir con el tráfico entrante y saliente, y se configuran para la activación con cualquier protocolo. Esta lista de filtros, cuando se une con la acción de filtrado apropiada, implementará los grupos de aislamiento.

Los diseñadores de Woodgrove Bank decidieron implementar una lista de exenciones para el tráfico de red ICMP. Esta lista de filtros consta de un solo filtro reflejado (Mi dirección IP <-> Cualquiera) configurado sólo para el tráfico de red ICMP. Este enfoque permite a los administradores utilizar la utilidad Ping como herramienta para la solución de problemas en el entorno, independientemente de si se ha negociado una asociación de seguridad IPsec (SA). Este enfoque también era necesario; para que esta solución funcione correctamente se necesita el descubrimiento de la unidad de transmisión máxima de ruta (MTU). En cuanto al tráfico DHCP, los diseñadores de Woodgrove Bank crearon un nuevo filtro para UDP puerto 68 que permitiese a los clientes DHCP recibir el tráfico procedente del servidor DHCP.

Además, Woodgrove Bank tenía algunas aplicaciones de línea de negocios (LOB) que se ejecutaban en servidores incapaces de participar en la infraestructura IPsec. Para acomodar estos servicios, crearon una nueva lista de filtros de exención llamada Lista de exenciones para los servidores de aplicaciones de la línea de negocios, y agregaron un filtro Cualquiera <-> 192.168.1.10 para el sistema que aloja la aplicación de LOB.

Finalmente, el equipo de diseño de Woodgrove Bank identificó sus servicios de infraestructura y creó las listas de filtros de exención correspondientes para permitir que todos los clientes se comunicaran directamente con los servidores que proporcionan estos servicios, independientemente de la configuración IPsec para los grupos de aislamiento. Se crearon listas de exención específicas para los servicios siguientes:

Estas listas de filtros constan de filtros reflejados que definen Cualquiera <-> Dirección IP específica, y estos filtros se configuran para la activación con cualquier protocolo. El número de equipos de la lista de filtros de exención debe ser mínimo, pues todo el tráfico queda excluido para estos equipos y todos los equipos de la lista de exenciones tienen acceso TCP/IP completo a todos los hosts de confianza en el dominio de aislamiento. Por lo tanto, este enfoque podría presentar una superficie de ataque más amplia de la que existiría de otro modo. Consulte la hoja de cálculo Business_Requirements.xls (en la carpeta Herramientas y plantillas) para obtener información sobre los requisitos para mitigar los riesgos derivados del tráfico entrante procedente de direcciones IP excluidas.

En Woodgrove Bank se decidió administrar dos listas separadas para servidores DNS y controladores de dominio, aunque las direcciones IP son las mismas. Woodgrove adoptó esta alternativa porque ambas listas de filtros tendrán exactamente la misma acción, Permitir. Además, la red de producción de Woodgrove utiliza servidores DNS en algunas áreas que no son también controladores de dominio.

En lugar de tener direcciones IP de destino específicas, el filtro para DHCP se diseñó para coincidir con todo el tráfico saliente del cliente DHCP. El reflejo de este filtro permitirá respuestas procedentes de servidores DHCP. Tal como hemos explicado, también puede permitir ataques entrantes procedentes de cualquier dirección IP que utilice el puerto de origen 67. Sin embargo, el ataque entrante está limitado al puerto de destino 68 en el cliente, que es el que está utilizando el cliente DHCP. En Woodgrove Bank se utilizó este diseño para no tener filtros en cada servidor DHCP y porque no se consideró que fueran elevados los riesgos derivados de ataques entrantes al puerto del cliente DHCP o el riesgo de servidores DHCP no autorizados.

Esta sección no incluye la descripción completa para cada filtro. Sin embargo, se recomienda utilizar el campo de descripción de filtro para definir cuidadosamente cada filtro, puesto que el monitor IPsec y las herramientas de línea de comando muestran la descripción de cada filtro, no la información de la lista de filtros.

Acciones de filtrado IPsec

Las acciones de filtrado definen el modo en que se administran los paquetes IP después de hacerlos coincidir con un filtro de una lista de filtros. Las acciones de filtrado constituyen la base para la implementación de los diversos grupos de aislamiento. Aunque con el sistema operativo Windows se entregan tres acciones de filtrado predeterminadas, se recomienda eliminarlas y crear nuevas acciones de filtrado. Esta estrategia le permite garantizar que sólo se utilizan las acciones que crea como parte de su diseño. Cada acción de filtrado consta de un nombre, una descripción y un método de seguridad.

Nombre

Asigne a la acción de filtrado un nombre lógico que indiqué cuál es su función.

Descripción

Especifique una descripción detallada del comportamiento de la acción de filtrado en el campo de descripción.

Métodos de seguridad

Los métodos de seguridad que se implementan en la acción de filtrado vienen determinados por los requisitos de procesar paquetes que coinciden con los filtros asociados de la lista de filtros. Se dispone de las tres opciones siguientes:

En la tabla siguiente aparecen las opciones criptográficas posibles para cada método de seguridad:

Tabla 5.3: Opciones de seguridad y criptográficas

Las implementaciones de IPsec en Windows 2000 SP4, Windows XP SP2 y Windows Server 2003 admiten actualmente técnicas de NAT-T para el modo de transporte ESP de IPsec, además de ser compatibles con NAT-T para túneles de cliente VPN L2TP/IPsec. La actualización de NAT-T es necesaria para Windows 2000 SP4. La compatibilidad de Windows 2000 y Windows XP para el modo de transporte NAT-T de IPsec está limitada a versiones de Windows 2000 y Windows XP anteriores a SP2 porque no admiten la detección de la MTU de la ruta TCP (PMTU) para el tráfico TCP protegido mediante IPsec. Windows Server 2003 ya es compatible. Las técnicas NAT-T utilizan un encabezado UDP tras el encabezado IP para encapsular ESP. IKE detecta automáticamente cuándo existe NAT en la ruta y utiliza UDP-ESP siempre que ESP está autorizado en la lista de métodos de seguridad. Además, vale la pena tener en cuenta que las implementaciones de IPsec actuales en Windows no admiten el estándar de cifrado avanzado del Gobierno Federal de Estados Unidos. (Federal government Advanced Encryption Standard - AES). Esto cambiará en versiones futuras de Windows.

Las siguientes opciones criptográficas están disponibles para AH y ESP:

ESP puede configurarse de forma que no utilice ningún algoritmo de cifrado, en cuyo caso sólo se exigirá la autenticidad y la integridad de la información. Esta configuración suele conocerse como ESP-null y proporciona la capacidad de autenticar los hosts antes de establecer una conexión de comunicación y verificar la integridad de la parte de datos del paquete IP que se transporta dentro del paquete ESP.

ESP también puede cifrar la parte de datos del paquete IP. Se dispone de las siguientes dos opciones criptográficas:

Si se ve obligado a satisfacer requisitos de seguridad muy elevados, puede combinar los protocolos AH y ESP entre sí. Por ejemplo, si claramente necesita integridad de encabezado IP además de cifrado de datos, puede configurar el método de seguridad de forma que utilice AH con integridad SHA-1 y cifrado ESP – 3DES. Si sólo necesita integridad de datos, puede utilizar ESP-null con SHA-1.

Aunque es posible seleccionar cualquier combinación de opciones de seguridad, es importante saber que AH proporciona integridad de encabezado de datos y dirección. El uso de AH y ESP para obtener integridad no proporciona ningún tipo de protección de integridad adicional para los datos del paquete; se limita a incrementar la carga asociada con el procesamiento del paquete. Además, ESP combinado con AH no superará los problemas de barrera de NAT que afectan a AH. Por lo tanto, la utilización de AH junto con ESP sólo es apropiada para los entornos de más alta seguridad.

En el diseño de los métodos de seguridad de las acciones de filtrado es importante efectuar una planificación cuidadosa. Para que dos equipos puedan negociar satisfactoriamente, deben tener como mínimo un método de seguridad en común en sus respectivas acciones de filtrado. Cada acción de filtrado puede contener más de un método de negociación para poder admitir tipos de negociación diferentes. Por ejemplo, un sistema podría negociar sólo ESP-null, pero la acción de filtrado podría incluir también un método de negociación para ESP-3DES. Esta estrategia permitiría al sistema negociar una conexión de cifrado 3DES si fuera necesario.

Además de seleccionar los métodos de seguridad, si es necesario puede definir la configuración de claves de sesión para cada método de seguridad. En esta configuración predeterminada, la vigencia de la asociación de seguridad IPsec se configura en 100 megabytes (MB) de datos o en una hora. Estas configuraciones controlan en qué momento el modo rápido IKE debe volver a negociar una nueva pareja de asociaciones de seguridad IPsec. El proceso de modo rápido IKE se conoce como "cambio de claves" pero en realidad no se limita a actualizar las claves de una pareja de SA IPsec existente. IPsec debe rechazar los paquetes si expira la vigencia; por lo tanto, intenta renegociar antes de que la vigencia en bytes o segundos se agote. Si la vigencia es demasiado baja, pueden perderse paquetes. Del mismo modo, el uso de la CPU puede incrementarse para aquellos servidores que mantienen SA de IPsec con muchos clientes. La renovación de las SA de IPsec garantiza que un atacante no podrá descifrar toda la comunicación aunque logre averiguar una de las claves de sesión. Si se prolonga la vigencia, el atacante dispone de más información acerca de la clave de sesión. Por lo tanto, no debe cambiar la vigencia a menos que existan necesidades operativas y puede escribir requisitos de seguridad específicos que definan un nivel apropiado de protección contra ataques criptográficos sofisticados.

Opciones de negociación de seguridad

Puede definir las siguientes opciones de negociación de seguridad para las directivas IPsec:

Paso de sucesos entrante

La opción de paso de sucesos entrante ha sido diseñada para utilizarse en una directiva de servidor interna, de forma que la directiva de cliente pueda utilizar la regla de "respuesta predeterminada" no intrusiva. Con esta opción habilitada, se aceptará toda solicitud de conexión de texto sin formato que coincida con un filtro entrante. La respuesta de conexión del servidor coincide con el filtro saliente para activar una solicitud de negociación IKE de modo principal al cliente.

No debe habilitar esta opción en equipos conectados a Internet, porque permite que los ataques entrantes superen la capa IPsec. También obliga al servidor a intentar una negociación de SA IPsec para el IP de origen de cualquier paquete entrante. Mediante la imitación de las direcciones IP de origen, el atacante puede provocar el rechazo del servicio en el servidor mientras IKE intenta negociar con cientos o miles de direcciones IP no válidas.

Para habilitar el paso de sucesos entrante, seleccione Aceptar comunicación no segura pero responder siempre utilizando IPsec en el cuadro de diálogo Administrar acciones de filtrado.

Nota: si las directivas asignadas a los clientes no habilitan la regla de respuesta predeterminada, deberá deshabilitar esta opción porque no habrá ninguna respuesta para la comunicación IPsec. Además, puede utilizarse como vector de ataque de denegación de servicio.

Retroceso a texto no cifrado

La opción Retroceso a texto no cifrado controla la capacidad del equipo (de origen) de permitir que se envíe tráfico sin protección IPsec si la negociación inicial de modo principal IKE no obtiene una respuesta de un equipo de destino concreto. Los hosts que no admiten IPsec no podrán responder (mediante IKE) a la petición de negociación IKE. Estos hosts también se conocen como equipos "ajenos a IPsec". Sin embargo, la falta de una respuesta de modo principal IKE no significa necesariamente que el equipo no permita IPsec; podría tratarse de un equipo que permita IPsec pero que no tenga una directiva IPsec activa. O incluso podría ser que la directiva IPsec activa sólo tuviera acciones de permiso y bloqueo. También podría ser que la directiva IPsec activa no esté diseñada para negociar con la dirección IP del equipo de origen. En terminología IPsec, el tráfico de red que no utiliza IPsec se denomina texto sin formato. Si no hay ninguna respuesta por parte del equipo de destino en tres segundos, se creará una asociación de seguridad por software (soft SA) y la comunicación se iniciará en texto sin formato. Para implementaciones iniciales, se recomienda habilitar esta opción, de forma que los clientes puedan comunicarse con hosts que no tengan IPsec habilitado. Además, el uso de esta opción también ayuda a restablecer temporalmente la conectividad en modo de texto sin formato cuando se detiene el servicio IPsec para solucionar algún problema. Si el equipo de destino proporciona una respuesta IKE y por algún motivo se produce un error durante la negociación IKE, el servicio IPsec en el equipo de origen rechazará los paquetes salientes, bloqueando la comunicación de un modo eficaz.

Para habilitar la opción Retroceso a texto no cifrado, seleccione Permitir comunicación no segura con equipos ajenos a IPsec en el cuadro de diálogo Administrar acciones de filtrado.

Nota: en los equipos con Windows 2000 SP3 o posteriores, Windows XP SP1 o Windows Server 2003 ha cambiado la forma en que funciona esta opción. Si sólo se habilita esta opción, el sistema podrá iniciar una comunicación pero no aceptará ninguna petición de comunicación procedente de sistemas ajenos a IPsec. Si el sistema debe responder a peticiones de sistemas ajenos a IPsec e iniciar comunicaciones con estos sistemas, deberá seleccionarse la opción Aceptar comunicación no segura pero responder siempre utilizando IPsec y la opción Permitir comunicación no segura con equipos ajenos a IPsec.
Si el sistema utiliza Windows 2000 o Windows XP sin los paquetes de servicio apropiados, el cliente aceptará peticiones de comunicación no seguras si se selecciona Permitir comunicación no segura con equipos ajenos a IPsec, incluso si no se ha seleccionado Aceptar comunicación no segura pero responder siempre utilizando IPsec. Este comportamiento tiene lugar porque cuando se selecciona la opción Permitir comunicación no segura con equipos ajenos a IPsec, IPsec procesa el filtro entrante asociado como un filtro de paso de sucesos entrante (y lo mismo sucede cuando se selecciona Aceptar comunicación no segura pero responder siempre utilizando IPsec).

Utilizar confidencialidad directa perfecta para clave de sesión

La opción Utilizar confidencialidad directa perfecta para clave de sesión (PFS) determina si puede utilizarse el material de la clave de sesión de protección para generar todas las claves de sesión o sólo la primera. Si se habilita esta opción, la clave de sesión de protección sólo podrá utilizarse una vez y cada renegociación de clave de sesión adicional requerirá que tenga lugar un nuevo intercambio de claves para generar una nueva clave de sesión de protección antes de generar la clave de sesión. Este requisito garantiza que si la clave de sesión de protección queda comprometida, el atacante no puede generar claves de sesión adicionales para descifrar el flujo de tráfico. No se recomienda habilitar esta opción debido al gasto indirecto adicional de llevar a cabo un intercambio de claves en cada intervalo de renovación de la clave de sesión.

Para obtener más información acerca de las opciones de paso de sucesos entrante, retroceso a texto no cifrado y confidencialidad directa perfecta para clave de sesión y clave de sesión de protección, consulte la sección "Security Negotiation Options (Opciones de negociación de seguridad)" de Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server (Utilización de Microsoft Windows IPsec para proteger servidores de red corporativa internos) que encontrará en el Centro de descarga de Microsoft en www.microsoft.com/downloads/details.aspx?
familyid=a774012a-ac25-4a1d-8851-b7a09e3f1dc9&displaylang=en.

Acciones de filtrado IPsec de Woodgrove Bank

La tabla siguiente proporciona los nombres y descripciones de las acciones de filtrado que se utilizan para implementar los diversos grupos de aislamiento en el escenario de Woodgrove Bank:

Tabla 5.4: Acciones de filtrado IPsec y descripciones

Las dos primeras acciones de filtrado son directas. La acción de filtrado Bloquear rechazará el tráfico que coincida con un filtro de una lista de filtros asociada con esta acción. La acción de filtrado Permitir aceptará el tráfico para cualquier lista de filtros asociada que posee el filtro pertinente. Las cuatro últimas acciones de filtrado de la Tabla 5.4 se utilizan para implementar los grupos de aislamiento en el escenario de Woodgrove Bank.

Los administradores de Woodgrove Bank tienen cuatro grupos de aislamiento de seguridad para implementar. Para aplicar esta configuración, debe definirse un mínimo de tres acciones de filtrado con métodos de negociación de seguridad personalizados, además de las acciones de filtrado Permitir y Bloquear.

Woodgrove Bank no tiene ningún requisito adicional para el aislamiento de los equipos entre sí dentro de un grupo específico de aislamiento de seguridad. El banco ha determinado que las cuatro acciones de filtrado negociadas en la tabla siguiente son suficientes para implementar este entorno:

Tabla 5.5: Métodos de seguridad admitidos

Woodgrove utiliza IPsec ESP en lugar de AH debido a la presencia en la organización de dispositivos de red que utilizan NAT.

Woodgrove Bank también tenía el requisito de implementar una solución de cifrado para algunos de los servidores de la organización. Por lo tanto, todas las directivas necesitaban la opción de utilizar cifrado. Por ello, la implementación de la seguridad en Woodgrove Bank está basada únicamente en IPsec ESP.

Para garantizar la integridad de ESP, en Woodgrove Bank se decidió utilizar SHA-1 en lugar de MD5 para mayor seguridad, pero también porque era necesario satisfacer la normativa del Gobierno de EE.UU. para el procesamiento de información financiera, que incluye la utilización de algoritmos aprobados.

En Woodgrove Bank se decidió no implementar PFS en ninguna de las acciones de filtrado porque no existía ninguna amenaza específica de seguridad que exigiera el uso de PFS. Esta decisión también pretendería evitar el impacto sobre el rendimiento de los equipos que provoca la renegociación de claves.

Acción de filtrado de dominio de aislamiento

Para implementar el dominio de aislamiento, los administradores de Woodgrove Bank crearon la acción de filtrado IPSEC – Modo de solicitud seguro (Ignorar entrante, Permitir saliente).

Woodgrove Bank posee varios requisitos empresariales para la comunicación entre hosts en el dominio de aislamiento y otros grupos de aislamiento. Por consiguiente, los clientes del dominio de aislamiento llevan a cabo las acciones siguientes que se describen en las tablas 4.5 y 4.6 del capítulo 4 de esta guía:

Los clientes del dominio de aislamiento no pueden aceptar las comunicaciones procedentes de sistemas que no son de confianza.

Recuerde que la directiva IPsec utiliza filtros y acciones de filtrado para interceptar y controlar paquetes IP entrantes y salientes. Aunque IKE autentica ambos equipos, la pertenencia a un grupo de un equipo que utiliza una determinada dirección IP no se conoce en el momento en que sale la solicitud de conexión inicial. Por lo tanto, IPsec e IKE no pueden configurarse específicamente para iniciar comunicaciones de un modo determinado con una identidad o grupo de aislamiento concretos. Los equipos que forman parte de estos grupos de aislamiento pueden estar ubicados en cualquier lugar de la red interna. Por lo tanto, no es posible utilizar direcciones IP para definir o aproximar grupos de aislamiento.

Para implementar estos requisitos en una directiva IPsec, es necesario diseñar la acción de filtrado para que trabaje con la lista de filtros que especifica todas las subredes internas. Los requisitos anteriores pueden reducirse a dos comportamientos básicos:

Para permitir las comunicaciones con el grupo de aislamiento Cifrado, los métodos de seguridad incluyen aquellos (algoritmos ESP–SHA-1–3DES) que se definen para el grupo de aislamiento Cifrado. Para obtener más información acerca de los métodos de negociación de la seguridad de cifrado, consulte la sección "Acción de filtrado de grupo de aislamiento Cifrado" de este mismo capítulo.

Para el tráfico dentro del dominio de aislamiento y con los grupos de aislamiento Límite y Sin reserva, Woodgrove Bank utiliza ESP-null con SHA-1.

Debe deshabilitar la opción Aceptar comunicación no segura pero responder siempre utilizando IPsecen la acción de filtrado, de forma que se ignore el texto sin formato entrante. Esta estrategia asegura que los hosts del dominio de aislamiento no acepten tráfico de ningún equipo que no participe en el entorno IPsec.

La acción de filtrado IPSEC – Seguridad de solicitud segura (Ignorar entrante, Permitir saliente) se configura para permitir que los miembros del dominio de aislamiento inicien comunicaciones con sistemas que no son de confianza. Este comportamiento se implementa habilitando la opción Permitir comunicación no segura con equipos ajenos a IPsec en la acción de filtrado. Si un host de confianza del dominio de aislamiento inicia una conexión saliente con un host que no es de confianza (u otro sistema ajeno a IPsec), la SA por software IPsec se establece y permanece activa durante cinco minutos después de que el tráfico deje de fluir. Por lo tanto, durante ese tiempo, ese sistema que no es de confianza podrá iniciar conexiones de texto sin formato para responder al host de confianza. Cuando expire la SA por software, el host de confianza dejará de aceptar el tráfico de texto sin formato procedente de dicho sistema. El soporte de filtrado IPsec y de SA por software no fue diseñado para facilitar protecciones específicas para la conexión, como filtrado activo, al igual que hacen diversos servidores de seguridad. Las SA por software permiten todo el tráfico que coincide con el filtro asociado. Para obtener más información acerca de este proceso, consulte la sección "SA de modo principal IKE y SA IPsec" del apéndice A, "Descripción general de los conceptos de la directiva IPsec".

Acción de filtrado de grupo de aislamiento Límite

Para implementar el grupo de aislamiento Límite, los administradores de Woodgrove Bank crearon la acción de filtrado IPSEC – Modo de solicitud (Aceptar entrante, Permitir saliente).

Woodgrove Bank posee varios requisitos empresariales relacionados con la comunicación entre hosts en el grupo de aislamiento Límite y otros grupos de aislamiento. Por consiguiente, los clientes del grupo de aislamiento Límite pueden llevar a cabo las acciones siguientes que se describen en las tablas 4.5 y 4.6 del capítulo 4:

Para implementar estos requisitos en una directiva IPsec, es necesario diseñar la acción de filtrado para que trabaje con la lista de filtros que especifica todas las subredes internas. Los requisitos citados pueden reducirse a dos comportamientos básicos:

Para satisfacer los requisitos para iniciar y aceptar tráfico destinado a o procedente del dominio de aislamiento y el grupo de aislamiento Sin reserva, Woodgrove Bank garantiza que los métodos de negociación de seguridad utilizados para el dominio de aislamiento y el grupo de aislamiento Sin reserva están presentes en la acción de filtrado. El método de negociación de la seguridad común seleccionado por Woodgrove es ESP con SHA-1 para garantizar la integridad.

Los host del grupo de aislamiento Límite pueden comunicarse con sistemas que no son de confianza. Para facilitar esta capacidad, el equipo de administración de Woodgrove Bank activó las opciones Permitir comunicación no segura con equipos ajenos a IPsec y Aceptar comunicación no segura, pero responder siempre con IPsec para esta acción de filtrado. Mediante la habilitación de estas dos opciones, se asegura que los hosts aceptarán el tráfico entrante no seguro y podrán utilizar el retroceso a texto no cifrado para el tráfico saliente no seguro.

Acción de filtrado de grupo de aislamiento Sin reserva

Para implementar el grupo de aislamiento Sin reserva, los administradores de Woodgrove Bank crearon la acción de filtrado IPSEC – Modo de solicitud completo (Ignorar entrante, No permitir saliente).

Woodgrove Bank posee varios requisitos empresariales para la comunicación entre hosts en el grupo de aislamiento Sin reserva y otros grupos de aislamiento. Por lo tanto, los clientes del grupo de aislamiento Sin reserva pueden llevar a cabo las acciones siguientes:

Los clientes en el grupo de aislamiento Sin reserva no pueden iniciar comunicaciones con ni aceptar comunicaciones de sistemas que no son de confianza.

Para implementar estos requisitos en una directiva IPsec, es necesario diseñar la acción de filtrado para que trabaje con la lista de filtros que especifica todas las subredes internas. Los requisitos citados pueden reducirse a dos comportamientos básicos:

Para permitir las comunicaciones con el grupo de aislamiento Cifrado, los métodos de negociación de seguridad incluyen aquellos que se definen para el grupo de aislamiento Cifrado. Para obtener más información acerca de los métodos de negociación de la seguridad de cifrado, consulte la sección "Acción de filtrado de grupo de aislamiento Cifrado" de este mismo capítulo.

Para el tráfico destinado al grupo de aislamiento Límite y el grupo de aislamiento Sin reserva, Woodgrove Bank utiliza ESP con SHA-1 para el método de negociación de la seguridad.

La casilla de verificación Aceptar comunicación no segura pero responder siempre utilizando IPsec de la acción de filtrado no está marcada para crear el grupo de aislamiento Sin reserva. Esta estrategia garantiza que los hosts del grupo de aislamiento Sin reserva deben proteger todo el tráfico entrante y saliente con IPsec. No aceptarán tráfico de ningún equipo que no participe en el entorno IPsec.

La acción de filtrado IPSEC – Modo de solicitud completo (Ignorar entrante, No permitir saliente) no permitirá que un equipo que utilice esta acción de filtrado inicie una comunicación con un equipo que no participe en la infraestructura IPsec. La opción Permitir comunicación no segura con equipos ajenos a IPsec se ha deshabilitado para aplicar este requisito.

Acción de filtrado de grupo de aislamiento Cifrado

Woodgrove Bank seleccionó ESP como protocolo de integridad base y SHA-1 como opción criptográfica. Además, los hosts del grupo de aislamiento Cifrado deben comunicarse con los hosts del dominio de aislamiento y el grupo de aislamiento Sin reserva. La acción de filtrado se configuró para incluir los métodos de negociación de seguridad que cifran la información.

Woodgrove Bank posee varios requisitos empresariales relacionados con la comunicación entre hosts en el grupo de aislamiento Cifrado y otros grupos de aislamiento. Por lo tanto, los clientes del grupo de aislamiento Cifrado pueden llevar a cabo las acciones siguientes de la tabla 4.6:

Los equipos del grupo de aislamiento Cifrado no pueden aceptar comunicaciones procedentes de hosts en el grupo de aislamiento Límite.

Para implementar estos requisitos en una directiva IPsec, es necesario diseñar la acción de filtrado para que trabaje con la lista de filtros que especifica todas las subredes internas. Los requisitos citados pueden reducirse a dos comportamientos básicos:

Los clientes del grupo de aislamiento Cifrado no pueden aceptar comunicaciones del grupo de aislamiento Límite y tampoco pueden iniciar ni aceptar comunicaciones procedentes de sistemas que no son de confianza.

Para permitir comunicaciones con el dominio de aislamiento, los métodos de negociación de seguridad de cifrado utilizados en IPSEC – Solicitar modo de cifrado (Ignorar entrante, no permitir saliente) también están presentes en las acciones de filtrado IPSEC – Solicitud segura (Ignorar entrante, Permitir saliente) e IPSEC – Modo de solicitud completo (Ignorar entrante, No permitir saliente). En Woodgrove Bank se utiliza el método de cifrado 3DES, que proporciona mejor seguridad que DES pero con una carga adicional.

Debido al requisito de no aceptar o iniciar comunicaciones con sistemas que no sean de confianza, en Woodgrove Bank no se habilitó la opción Aceptar comunicación no segura pero responder siempre utilizando IPsec. Esta configuración asegura que los hosts del grupo de aislamiento Cifrado no acepten tráfico de ningún equipo que no participe en el entorno IPsec. Además, también se deshabilitó la opción Permitir comunicación no segura con equipos ajenos a IPsec para evitar que los equipos intenten iniciar comunicaciones con cualquier equipo que no participe en el entorno IPsec.

Para bloquear las comunicaciones IPsec procedentes de los equipos del grupo de aislamiento Límite, se necesitó una configuración adicional. Los administradores de Woodgrove Bank configuraron el GPO que proporciona la directiva IPsec para los equipos del grupo de aislamiento Cifrado con el derecho "Denegar acceso a este equipo de la red". Este derecho se aplicó a un grupo que tenía todas las cuentas de equipo para los sistemas participantes en el grupo de aislamiento Límite. Si alguno de estos equipos intentara iniciar comunicaciones con un sistema del grupo de aislamiento Cifrado, la autenticación IKE provocaría un error de autorización y la comunicación se bloquearía.

Directivas IPsec

Las directivas IPsec configuran los equipos basados en Windows para que funcionen en un entorno IPsec. Una directiva IPsec es un conjunto de reglas con las que se compara el tráfico. Existen tres tipos distintos de directiva IPsec para Windows 2000:

Windows XP y Windows Server 2003 admiten los siguientes tipos de directiva adicionales:

Por cuestiones de simplicidad, esta guía se centra en la utilización de la directiva IPsec de dominio Active Directory.

Cuando se definen directivas IPsec, es aconsejable intentar diseñar una directiva genérica que constituya la base para la infraestructura IPsec de todos los equipos. Posteriormente, podrá crear directivas adicionales para imponer configuraciones más estrictas en los sistemas que requieren una configuración de seguridad adicional. Debería diseñar cada directiva adicional de forma que afecte al mayor número de equipos que deben satisfacer un determinado requisito técnico o empresarial. Reducir al mínimo el número total de directivas facilitará la solución de problemas y la administración de las directivas.

Las directivas IPsec constan de un nombre, una descripción, un conjunto de reglas y valores de configuración para intervalos de sondeo, opciones y métodos de intercambio de claves. En esta sección se detallan todos ellos.

Nombre

A las directivas, como a las acciones de filtrado, deben asignárseles nombres con significado que ayuden en la administración y solución de problemas de la solución durante las fases de implementación y operaciones del proyecto.

Descripción

Una descripción detallada de la directiva ayudará a los administradores a identificar cuál es el objetivo de la misma sin tener que abrirla y estudiar sus reglas.

Reglas

Una regla IPsec consiste en una única lista de filtros, una acción de filtrado asociada, los métodos de autenticación que se utilizan para establecer la confianza entre equipos, el tipo de conexión y si la regla es una configuración de túnel.

Cada regla define uno o varios métodos de autenticación que se utilizarán para establecer la confianza entre los hosts. Las opciones son: protocolo Kerberos versión 5, certificados de una entidad emisora de certificados específica y claves previamente compartidas.

El tipo de conexión define las conexiones para las que es válida la directiva IPsec. La directiva puede configurarse de forma que sea válida para todas las conexiones, para las conexiones de área local o para las conexiones basadas en acceso remoto.

El tipo de túnel define si la directiva IPsec define un túnel IPsec. Si se deshabilita el tipo de túnel, IPsec utiliza el modo de transporte.

Para permitir los grupos de aislamiento de seguridad que se mencionan anteriormente en esta guía, en Woodgrove Bank se implementaron cuatro directivas IPsec. Las cuatro directivas se configuraron de forma que utilizaran el protocolo de autenticación Kerberos versión 5, fueran válidas para todas las conexiones y no definieran un túnel IPsec.

En la tabla siguiente se muestran las directivas utilizadas en el escenario de Woodgrove Bank:

Tabla 5.6: Directivas IPsec para Woodgrove Bank

El número asociado con cada nombre de directiva es un número de versión y se trata más adelante en la sección "Control de versiones de directiva".

Todas las directivas de Woodgrove Bank contienen las mismas listas de exenciones, pues no existe ningún requisito para la exención de un conjunto determinado de equipos en relación con un grupo de aislamiento concreto. La tabla siguiente muestra las reglas habilitadas que coinciden en las cuatro directivas identificadas en la tabla anterior:

Tabla 5.7: Reglas comunes definidas en las directivas IPsec para Woodgrove Bank

Además de las reglas que aparecen en esta tabla, la regla de respuesta de cliente predeterminada de cada directiva está deshabilitada.

Las cuatro directivas que definió Woodgrove Bank sólo difieren en el modo en que se ocupan del tráfico restante que no administra ninguna de las listas de filtros de exención. En todas las reglas, el método de autenticación se establece en el protocolo Kerberos versión 5, el extremo de túnel se establece en Ninguno y el tipo de conexión en Todas.

La tabla siguiente muestra las reglas de Woodgrove Bank para la implementación de los cuatro grupos de aislamiento:

Tabla 5.8: Reglas básicas de Woodgrove Bank para la implementación de grupos de aislamiento

En Woodgrove Bank se decidió utilizar el protocolo Kerberos versión 5 como el único protocolo de autenticación. En Woodgrove no se utilizaron claves previamente compartidas porque el valor de la clave de autenticación puede ser consultado por los administradores locales en el registro y por cualquier usuario y equipo autenticado en el dominio. En Woodgrove no se utilizaron certificados porque el banco no tiene una infraestructura de claves públicas (PKI) implementada.

Si se utiliza el protocolo Kerberos versión 5, todos los equipos incorporados al dominio pueden participar en la infraestructura IPsec porque pueden autenticar y obtener directiva. Los equipos que no forman parte del dominio no pueden participar fácilmente en el entorno IPsec, debido a la ausencia de un mecanismo de autenticación y sistema de distribución de directivas. Si estos equipos satisfacen los criterios del host de confianza, puede configurarse una directiva local IPsec utilizando autenticaciones de certificado para que puedan comunicarse con otros hosts de confianza. En Woodgrove Bank, los equipos que no están basados en el dominio se consideran equipos que no son de confianza en este momento.

Nota: la utilización del protocolo Kerberos versión 5 para autenticación IKE no evita que los equipos que no están basados en el dominio participen en el entorno IPsec. Por ejemplo, si un sistema UNIX se configura correctamente de forma que utilice Active Directory como su territorio Kerberos y la implementación de IKE admite la autenticación de Kerberos, éste podrá participar en el dominio de aislamiento. Sin embargo, una configuración de este tipo queda fuera del alcance de este documento y no ha sido probada por Microsoft.

Intervalos de sondeo

Deben considerarse dos intervalos de sondeo: el intervalo de sondeo de la directiva de grupo y el intervalo de sondeo del servicio IPsec. La configuración predeterminada para el intervalo de sondeo de cambio de la directiva de servicio IPsec es de 180 minutos entre sondeos consecutivos para los cambios de directivas IPsec basadas en Active Directory. Estos sondeos comprueban si se han producido cambios en la directiva IPsec, no detectan ningún cambio en la pertenencia a dominio o unidad organizativa (OU) o en la asignación o supresión de una directiva IPsec en un GPO. Los cambios de pertenencia a OU y asignación de GPO del equipo se detectan mediante el sondeo de servicio de la directiva de grupo, que tiene lugar cada 90 minutos de forma predeterminada.

En Woodgrove Bank ambos intervalos de sondeo se establecieron en 60 minutos, de forma que si se necesitara una respuesta de seguridad, fuera posible actualizar e implementar las directivas en el espacio de una hora para mitigar los riesgos. Esta mayor frecuencia de sondeo introdujo tráfico de sondeo adicional en forma de consultas LDAP procedentes del cliente para verificar las marcas de hora en las directivas IPsec. Aunque ello no supuso una sobrecarga importante en el escenario de Woodgrove Bank, este incremento puede ser importante en implementaciones con un mayor número de clientes.

Valores de intercambio de claves

Los siguientes valores de intercambio de claves definen el modo en que se derivan claves nuevas y con qué frecuencia se renuevan. El concepto "clave de sesión de protección" se refiere al material de clave secreta compartida Diffie-Hellman generado en el modo principal IKE. El concepto "clave de sesión" se refiere a las claves generadas por el modo rápido IKE para su utilización en los algoritmos de cifrado e integridad IPsec. Las claves de sesión se derivan de la clave de sesión de protección.

En Woodgrove Bank no se utilizó PFS de clave de sesión de protección porque no existían requisitos específicos de seguridad que lo exigieran. Del mismo modo, tampoco se utilizó PFS de modo rápido IKE en las acciones de filtrado. La vigencia de SA de modo principal IKE se cambió de 480 a 180 minutos para borrar más rápidamente las SA de modo principal en servidores ocupados de todos los grupos, excepto el grupo de aislamiento Límite. Para el grupo de aislamiento Límite, los administradores de Woodgrove Bank redujeron la vigencia de la SA de modo principal IKE a 20 minutos para reducir la superficie de ataque presentada por las SA de modo principal residentes negociadas con el grupo de aislamiento Cifrado. Aunque los hosts del grupo de aislamiento Límite no pueden iniciar nuevas negociaciones IKE con hosts en el grupo de aislamiento Cifrado, sí puede suceder a la inversa. Tras establecer la SA de modo principal, un host límite podría utilizar esta SA para negociar las SA de modo rápido para la protección del tráfico entrante al sistema correspondiente en el grupo de aislamiento Cifrado hasta suprimir la SA de modo principal. Este riesgo se reduce forzando que las SA de modo principal de los servidores límite se borren con más frecuencia. El número de sesiones para las que puede utilizarse la clave de sesión de protección para generar una clave de sesión se dejó en la configuración predeterminada 0.

Métodos de intercambio de claves

Los métodos de intercambio de claves controlan los métodos de seguridad que se utilizan durante la negociación de modo principal IKE. Las opciones de configuración son para integridad (SHA-1 y MD5), confidencialidad o cifrado (3DES y DES) y la longitud de los números primo base que se utilizan durante el proceso de intercambio de claves.

Nota: los equipos con Windows 2000 deben tener instalado el paquete de alto cifrado o SP2 (o posterior) para utilizar 3DES.

La seguridad criptográfica de las claves utilizadas para la integridad y cifrado de la propia negociación IKE y para la protección de los datos IPsec depende de la seguridad del grupo Diffie-Hellman en el que están basados los números primos. Existen tres opciones para el grupo Diffie-Hellman:

La configuración Alto sólo puede utilizarse con los sistemas basados en Windows XP SP2 y Windows Server 2003. La configuración Medio permite la interoperabilidad con Windows 2000 y Windows XP SP1. Bajo se suministra para compatibilidad con versiones anteriores y no debe utilizarse debido a su relativa debilidad.

En la tabla siguiente aparecen los métodos de seguridad de intercambio de claves que se decidió implementar en Woodgrove Bank en orden de preferencia.

Tabla 5.9: Métodos predeterminados de seguridad de intercambio de claves

Nota: el uso del grupo de 2048 bits en la directiva IPsec requiere que la directiva IPsec se configure utilizando las herramientas administrativas de Windows Server 2003, como el complemento de MMC para la administración de directivas IPsec o la utilidad de línea de comandos IPsec Netsh. Esta directiva puede asignarse en el dominio a plataformas Windows 2000, ignorando de este modo la opción de 2048 bits.

Control de versiones de directiva

Los diseños de la directiva IPsec pueden cambiar muchas veces a lo largo de la planificación inicial, las pruebas de laboratorio, las implementaciones piloto y mientras está en uso. Si utiliza secuencias de comandos, hojas de cálculo u otros documentos para crear directivas IPsec, deberá administrar estos archivos con un sistema de control de versión similar a Microsoft Visual SourceSafe®.

Resulta difícil identificar versiones de directivas IPsec en Active Directory examinando los atributos de la directiva. Los pasos para la solución de problemas requerirán la capacidad de determinar qué versión de la directiva IPsec está activa en el equipo. Por lo tanto, se recomienda guardar algún tipo de información de control de versiones en el nombre de la directiva y en las reglas de la directiva.

Un método sencillo de control de versiones consiste en crear un identificador de versión basado en la fórmula siguiente:

<Major Change>.<Minor Change>.<Date:yymmdd>.<Time:24 Hour>

Por ejemplo, 1.0.041001.1600 correspondería a la versión 1.0 creada el 1/10/04 a las 16:00.

Este identificador de versión se colocaría al final del nombre de la directiva creada. Por ejemplo, IPSEC – Directiva IPsec Límite (1.0.041001.1600). También puede anexarlo al nombre o descripción de listas de filtros, que cambian con frecuencia.

La directiva de grupo recupera el nombre de la directiva IPsec y se guarda en el registro local en HKEY_LOCAL_MACHINE \SOFTWARE\
Policies\Microsoft\Windows\IPsec\GPTIPSECPolicy donde se almacena como valor de cadena bajo la clave DSIPSECPolicyName.

Aunque el sondeo de servicio IPsec busca cambios en todos los objetos de directiva asignados, no actualiza el nombre de la directiva asignada que ha guardado esa directiva de grupo. La directiva de grupo no actualiza el nombre del registro local hasta que se cambia la asignación de GPO. El departamento de TI de Microsoft descubrió que una regla no utilizada en la directiva IPsec puede ser una forma eficaz de guardar información sobre la versión de la directiva. Por ejemplo, puede crear una lista de filtros con un filtro que contenga direcciones no válidas y esté asociado con una acción de filtrado Permitir, por ejemplo:

Nombre de lista de filtros: directiva IPsec, versión 1.0.041001.1600

Descripción de lista de filtros: directiva IPsec, versión 1.0.041001.1600

1.1.1.1 <-> 1.1.1.2, ICMP, descripción = "directiva IPsec, versión 1.0.041001.1600"

Tras crear esta lista de filtros en Active Directory, puede identificar el nombre distintivo (DN) del objeto de versión para la lista de filtros utilizando el complemento de MMC de usuarios y equipos de Active Directory en modo avanzado. Puede encontrar el objeto de lista de filtros en el árbol <NombreDominio>\Sistema\Seguridad IP e identificarlo mediante su descripción.

Tras averiguar el DN del objeto de versión, puede compararlo mediante programación con los objetos IPsec almacenados en el registro en HKEY_LOCAL_MACHINE \SOFTWARE
\Policies\Microsoft\Windows\IPsec\Policy\Cache para determinar si se encuentra situado en la caché. Si encuentra el DN del objeto de versión en la caché, puede comparar los nombres de directiva para el objeto almacenado en Active Directory y el objeto almacenado en el equipo local. Si los nombres coinciden, las directivas local y de dominio están sincronizadas. Los nombres y descripciones de cada lista de filtros IPsec también están almacenados en la caché de la directiva IPsec, y ello ayudará a identificar qué versiones de estos objetos se han asignado actualmente. El servicio IPsec conserva en la memoria la descripción de texto para cada filtro (no la lista de filtros), de forma que el complemento Monitor IPsec MMC y las herramientas de línea de comandos puedan mostrar esta información.

Una secuencia de comandos puede ayudar a automatizar la comprobación de versión de directiva de un cliente, como la secuencia de comandos de ejemplo Detect_IPsec_Policy.vbs, que se incluye en la carpeta Herramientas y plantillas para esta solución.

A medida que edite directivas a lo largo de un período de tiempo, deberá actualizar los nombres de filtro correspondientes para reflejar los cambios.

Cómo aplicar directivas IPsec a equipos individuales

El paso final para habilitar IPsec es implementar las directivas en los hosts. Existen dos métodos para implementar las directivas. Un método consiste en aplicarlas directamente a los equipos host individuales y el segundo aplicarlas mediante el uso de GPO y Active Directory. La aplicación de directivas mediante Active Directory se trata en la sección "Cómo aplicar directivas IPsec utilizando GPO" de este capítulo.

Puede encargarse de la aplicación de directivas IPsec en equipos individuales de uno de estos dos modos: mediante el complemento de MMC para la administración de directivas de seguridad de IPsec o mediante la línea de comandos utilizando Netsh (para Windows Server 2003), Ipseccmd.exe (para Windows XP) o Ipsecpol.exe (para Windows 2000).

El complemento de MMC proporciona una interfaz de usuario gráfica (GUI) que el administrador puede utilizar para aplicar manualmente la directiva o importar una directiva IPsec previamente definida exportada de otro equipo. Además de manipular la directiva en el equipo local, los administradores pueden utilizar el complemento para administrar la directiva en un equipo remoto.

En los recursos siguientes encontrará información detallada sobre las herramientas de línea de comando disponibles:

Puede descargar la versión más reciente del kit de recursos y las herramientas de asistencia del Centro de descarga de Microsoft en www.microsoft.com/downloads/search.aspx?

Microsoft facilita IPseccmd actualizada y otras herramientas de asistencia para Windows XP SP2. El artículo 838079 de Microsoft KB, "Windows XP Service Pack 2 Support Tools" (Herramientas de asistencia de Windows XP SP2) en http://support.microsoft.com/?kbid=838079.

Queda fuera del alcance de esta guía facilitar información detallada sobre el uso de estas herramientas. Los ejemplos de esta guía están orientados hacia la utilización de Netsh en servidores con Windows Server 2003.

Cómo aplicar directivas IPsec utilizando GPO

La directiva de grupo de Active Directory se utiliza como el mecanismo de asignación y distribución de directiva IPsec para equipos que forman parte del dominio. Antes de distribuir las directivas mediante los mecanismos de distribución de directiva de grupo en Active Directory, debe configurar los GPO que se utilizarán para aplicar las directivas IPsec a los equipos host.

Nota: aunque en la sección siguiente se describe cómo cargar las directivas directamente en Active Directory, se asume que las directivas se crearon y probaron en un sistema local, en un laboratorio de pruebas y en proyectos piloto de pequeña escala antes de su implementación en un entorno productivo.

Cómo cargar directivas IPsec en Active Directory

La primera tarea de la implementación de directivas IPsec mediante Active Directory consiste en crear las listas de filtros, las acciones de filtrado y las directivas IPsec en el servicio de directorios. Para ello puede utilizarse el complemento de MMC para la administración de directivas de seguridad IPsec o una línea de comandos, como Netsh. Independientemente de la herramienta seleccionada, debe llevar a cabo las siguientes tres subtareas para implementar las directivas IPsec:

Utilización del complemento de MMC para la administración de la directiva de seguridad IPsec

El complemento de MMC para la administración de la directiva de seguridad IPsec es una herramienta basada en una GUI que permite a los administradores crear, configurar y editar directivas IPsec en equipos locales, equipos remotos o dominios. La configuración de los componentes IPsec es un proceso manual que implica la edición directa de los objetos que se crean y está dirigida por asistentes.

Tras definir las directivas IPsec localmente o en Active Directory, el administrador puede exportar las directivas IPsec (incluidas todas las listas de filtros y acciones de filtrado) a un archivo con una extensión de nombre de archivo .ipsec. Puede copiar este archivo a otros medios como copia de seguridad.

Si existe una copia de seguridad de las directivas IPsec, puede utilizar la herramienta para importar las directivas copiadas en Active Directory. Se trata de una estrategia apropiada tanto para operaciones de recuperación, como para desplazar los archivos de directiva IPsec de un bosque de prueba a un bosque productivo sin tener que volver a crear todas las listas de filtros, acciones de filtrado y directivas manualmente. Revise atentamente el diseño de las directivas recuperadas a partir de copias de seguridad. Es recomendable probarlas para evaluar el impacto de la aplicación de configuraciones anteriores en el entorno actual. Un archivo de copia de seguridad anterior puede incluir configuraciones de directiva (por ejemplo, listas de filtros o acciones de filtrado) no válidas y podría provocar errores de comunicación si se asignara a los miembros del dominio actual.

Para obtener más información sobre el uso del complemento de MMC para la administración de directivas de seguridad IPsec, consulte el tema "Definición de directivas IPsec" del Centro de ayuda y soporte técnico de Windows Server 2003.

Utilización de Netsh

Netsh puede utilizarse como alternativa al complemento de MMC para la administración de directivas de seguridad IPsec en la configuración de directivas IPsec con un Active Directory basado en Windows Server 2003. Puede ejecutar esta herramienta de línea de comandos en modo interactivo o por lotes. Cuando se utiliza en modo interactivo, el administrador debe especificar comandos individuales en el shell de comandos de Netsh. Antes de crear las listas de filtros, acciones de filtrado y directivas IPsec, es preciso configurar la herramienta para que se dirija a Active Directory.

Para dirigir Netsh a Active Directory, especifique el comando siguiente en el símbolo del sistema de Netsh:

ipsec static set store location=domain

El administrador introducirá entonces las listas de filtros, los filtros, las acciones de filtrado y las directivas IPsec manualmente a través del shell de comandos de Netsh. Igual que la herramienta de la GUI, Netsh admite la exportación e importación de archivos de directiva IPsec para escenarios de copia de seguridad y recuperación.

La ejecución de Netsh por lotes requiere la creación de un archivo de comandos Netsh. Este archivo de comandos debe incluir el comando para establecer el foco en el dominio, así como todos los comandos de configuración para las listas de filtros, filtros, acciones de filtrado y directivas IPsec.

A continuación podrá crearse la información de la directiva IPsec en Active Directory iniciando Netsh y ejecutando el archivo de comandos. La sintaxis de línea de comandos para iniciar Netsh y ejecutar un archivo de comandos es la siguiente:

netsh –f <scriptfile>

Para obtener más información sobre el uso de Netsh, consulte el tema "Netsh" en la sección "Herramientas de administración y secuencias de comandos" del Centro de ayuda y soporte técnico de Windows Server 2003.

Nota: Netsh sólo funciona con directivas IPsec en equipos con Windows Server 2003. Para la manipulación de la línea de comandos de directivas IPsec en equipos con Windows 2000 o Windows XP se necesita Ipsecpol.exe o Ipseccmd.exe, respectivamente. Además, Netsh muestra en forma de lista un comando de volcado en el contexto IPsec de la herramienta. Esta función no se implementa, aunque aparece en forma de lista en el texto de ayuda. Además, a diferencia de la herramienta GUI, Netsh no admite conexiones remotas.

Creación de objetos de directiva de grupo para la distribución de la directiva IPsec

Los GPO son objetos almacenados en Active Directory que definen las configuraciones que deben aplicarse a un equipo. Las directivas IPsec no se almacenan en los GPO directamente. Por el contrario, los GPO mantienen un vínculo de DN LDAP con la directiva IPsec. Las directivas IPsec se almacenan en la ubicación cn=IP Security, cn=System, dc=<dominio> en Active Directory.

Los GPO se asignan a sitios, dominios u OU en Active Directory. Los equipos que se encuentran en dichas ubicaciones o contenedores reciben la directiva definida por el GPO a menos que se bloquee de otro modo. El equipo de diseño de IPsec debería considerar con el equipo de Active Directory la viabilidad de utilizar GPO existentes para entregar sus directivas IPsec. Si esta estrategia no es viable o requiere una modificación importante de sus prácticas administrativas, pueden definirse nuevos GPO para cada conjunto de directivas IPsec que se implementará. La solución que se describe en esta guía utiliza nuevos GPO para la implementación de las directivas IPsec.

Aunque pueden crearse GPO a través de los usuarios y equipos de Active Directory o a través de las herramientas de sitios y servicios de Active Directory, se recomienda crear los nuevos GPO utilizando la consola de administración de directivas de grupo (GPMC). La creación de una directiva con las herramientas de Active Directory vincula automáticamente el GPO con el objeto que se está explorando. Si utiliza la GPMC para crear los GPO, el administrador puede garantizar que los GPO se crean en Active Directory pero que no se aplican a los equipos hasta que cada GPO se vincula explícitamente con un sitio, dominio u OU.

La GPMC es una utilidad complementaria para los equipos con Windows XP Service Pack 1 (o posterior) o Windows Server 2003. La GPMC permite a los administradores gestionar la directiva de grupo para múltiples dominios y sitios en uno o varios bosques mediante una interfaz de usuario simplificada con funcionalidad de arrastrar y colocar. Las características principales incluyen funcionalidades como copia de seguridad, restauración, importación, copia y generación de informes de GPO. Estas operaciones pueden utilizarse en secuencias de comandos, y ello permite a los administradores personalizar y automatizar la administración. Observe que estas técnicas de administración de GPO son válidas para la administración de los propios objetos de directiva IPsec. Debe desarrollar una estrategia administrativa para la administración de la directiva IPsec en coordinación con los GPO que proporcionan la asignación de la directiva IPsec.

Para obtener más información sobre la utilización de la GPMC, consulte las notas del producto, "Administering Group Policy with the GPMC" del sitio Web de Microsoft en at www.microsoft.com/windowsserver2003/gpmc/
gpmcwp.mspx.

Puede descargar la Consola de administración de directiva de grupo con Service Pack 1 de www.microsoft.com/downloads/details.aspx?
FamilyId=0A6D4C24-8CBD-4B35-9272-DD3CBFC81887&displaylang=en.

Con la GPMC, el administrador crea un GPO para cada directiva IPsec completando los pasos siguientes:

Para crear un GPO nuevo

Al igual que con las directivas y acciones de filtrado IPsec, debe desarrollarse un estándar de nomenclatura para los GPO que incluya un número de versión de la directiva en el nombre, pues no es fácil obtener la información de versión de los objetos Active Directory. La inclusión de un número de versión en el nombre de la directiva permite a los administradores identificar rápidamente la directiva que está en vigor en ese momento. Microsoft recomienda utilizar la misma convención de nomenclatura que se describe anteriormente en este capítulo para acciones de filtrado y directivas IPsec. Por ejemplo, un GPO con el nombre "GPO IPsec de dominio de aislamiento, versión 1.0.040601.1600" correspondería a la versión 1.0 creada el 1/06/04 a las 16:00.

Tras crear el GPO, el administrador debe configurarlo de forma que utilice la directiva IPsec apropiada.

Para asignar la directiva IPsec en un GPO

La directiva IPsec se aplica a equipos host a través de los parámetros de configuración de equipo en el GPO. Si el GPO sólo se utiliza para aplicar directivas IPsec, se recomienda configurar el GPO para deshabilitar los parámetros de configuración de usuario. Si se deshabilitan estos valores, se reducirá el tiempo de procesamiento del GPO al eludir la evaluación de los parámetros de configuración de usuario.

Para deshabilitar la configuración del usuario en el GPO

Si los parámetros de configuración de usuario se configuran en el GPO a posteriori, el administrador tendrá que volver a habilitar el procesamiento de los parámetros de configuración de usuario para poder aplicarlos.

Grupos de seguridad del dominio

Los grupos de seguridad del dominio tienen dos finalidades. En primer lugar, identificar las cuentas de los equipos de dominio que son miembros de un grupo de aislamiento y, en segundo lugar, identificar las cuentas de los equipos de dominio que son miembros de un grupo de acceso de red.

Todos los miembros de un grupo de aislamiento deben recibir la misma directiva IPsec. Por lo tanto, puede crear grupos de seguridad de dominio para la aplicación y administración de las directivas IPsec en lugar de utilizar contenedores de OU para controlar las asignaciones de directrices. Los grupos universales son la mejor opción para controlar la asignación de directivas, pues pueden aplicarse a todo el bosque y reducen el número de grupos que es preciso administrar. Sin embargo, si no dispone de grupos universales puede utilizar en su lugar grupos globales de dominio. Los grupos locales de dominio se utilizan para los grupos de acceso de red que se mencionan en una sección posterior.

En la tabla siguiente aparecen los grupos creados para el escenario de Woodgrove Bank con el fin de administrar el entorno IPsec y controlar la aplicación de directivas:

Tabla 5.10: Nombres de los grupos IPsec

Además de los grupos indicados, pueden haberse creado grupos adicionales y utilizarse para restringir la aplicación de directivas durante la ejecución inicial. Al implementar IPsec, no es recomendable limitarse a crear los GPO y directivas IPsec y asignarlos al mismo tiempo a todos los equipos del dominio. Un grupo de seguridad de dominio puede utilizarse para el control preciso de los equipos que podrán leer los GPO y, por lo tanto, recibir la directiva IPsec correspondiente. Todos los GPO que entregan la directiva IPsec pueden asignarse a todo el dominio. El proceso de ejecución debe considerar atentamente si la directiva IPsec está bien diseñada, asignada y recuperada en todos los nodos que prevén negociar IPsec. El diseño de la directiva de grupo límite suele utilizarse para permitir la comunicación ajena a IPsec entrante y saliente con equipos que todavía no han recibido su directiva IPsec.

Distribución de directivas IPsec mediante Active Directory

El usuario puede controlar qué GPO se aplican a los equipos en Active Directory de tres formas combinadas:

El control de la aplicación de GPO mediante unidades organizativas con GPO vinculados es la forma más habitual de aplicación de directiva en Active Directory. Este método crea unidades organizativas en Active Directory y vincula los GPO con sitios, dominios o unidades organizativas. Los equipos reciben la directiva según su ubicación en Active Directory. Si un equipo se traslada de una OU a otra, la directiva vinculada con la segunda OU entrará en vigor cuando la directiva de grupo detecte el cambio durante el sondeo.

El segundo método utiliza configuraciones de seguridad en los propios GPO. Un grupo se agrega a la ACL del GPO en Active Directory. A este grupo se le asignan, a continuación, derechos de leer y aplicar los parámetros de la directiva de grupo sobre la directiva que debe entrar en vigor para los equipos del grupo. Además, se le deniega explícitamente al grupo todo permiso sobre aquellas directivas que no son válidas para los equipos de dicho grupo. A continuación se vincula la directiva en el nivel de dominio.

El tercer método emplea filtros de WMI sobre la directiva para controlar dinámicamente el alcance de la aplicación de la directiva. Se crea un filtro SQL de WMI y se vincula con la directiva. Si la condición de la consulta es verdadera, se aplica la directiva; de lo contrario, se ignora. Los equipos con Windows 2000 ignoran el filtrado de WMI y aplican la directiva. Las consultas de WMI pueden ralentizar el procesamiento de los GPO y deberán utilizarse sólo cuando sea necesario.

En Woodgrove Bank se decidió utilizar grupos de seguridad para controlar la aplicación de directivas, en lugar de establecer vínculos directos con una OU. Woodgrove seleccionó esta estrategia para introducir fácilmente directivas IPsec en el entorno sin tener que forzar las directivas en múltiples ubicaciones o forzar un desplazamiento de equipos de una OU a otra para recibir la directiva adecuada. A menos que las ACL del GPO sean muy extensas, no hay ninguna carga adicional asociada con este método en relación con el primer método, pues en ambos casos es preciso evaluar las ACL. En Woodgrove no se seleccionó el filtrado de WMI porque en el entorno hay sistemas con Windows 2000.

En la siguiente tabla se describe la configuración final de la ACL de directiva de grupo. Observe que las ACL de los propios objetos de directiva IPsec no se utilizan y no son recomendables.

Tabla 5.11: Permisos de GPO para la directiva de Woodgrove Bank

Dominio de aislamiento

Woodgrove Bank decidió vincular la directiva de dominio de aislamiento con el nivel de dominio en cada dominio de la organización. La directiva utiliza una ACL, que evita que aquellos que no sean miembros del grupo CG_IsolationDomain_computers apliquen la directiva. Los derechos de Aplicar directiva de grupo del grupo de usuarios autenticados se eliminaron de la ACL de la directiva.

La directiva de dominio de aislamiento es la directiva que utilizan todos los equipos de la organización como su directiva de seguridad IPsec predeterminada. Por lo tanto, al grupo de equipos del dominio se les otorga Acceso de lectura a la directiva. Los derechos de Aplicar directiva de grupo del grupo de usuarios autenticados se eliminaron de la ACL de la directiva. Durante la ejecución inicial, se suprimió el grupo de equipos del dominio de la ACL y se utilizó otro grupo de seguridad temporal para controlar quién podría recibir esta directiva. Esta estrategia permitió una implementación escalonada de esta directiva.

Grupo de aislamiento Límite

Woodgrove Bank decidió vincular la directiva del grupo de aislamiento Límite con el nivel de dominio en cada dominio de la organización. La directiva utiliza una ACL, que evita que aquellos que no sean miembros del grupo CG_BoundaryIG_computers apliquen la directiva. Los derechos de Aplicar directiva de grupo del grupo de usuarios autenticados se eliminaron de la ACL de la directiva.

Si la organización necesitara que un sistema aceptara comunicaciones de sistemas que no son de confianza, puede agregarse la cuenta de equipo del sistema al grupo de seguridad CG_BoundaryIG_computers.

No existe un grupo de aislamiento de reserva

Woodgrove Bank decidió vincular la directiva del grupo de aislamiento Sin reserva con el nivel de dominio en cada dominio de la organización. La directiva utiliza una ACL, que evita que aquellos que no sean miembros del grupo CG_NoFallbackIG_computers apliquen la directiva. Los derechos de Aplicar directiva de grupo del grupo de usuarios autenticados se eliminaron de la ACL de la directiva.

Si la organización necesitara que a un sistema se le denegara la posibilidad de establecer comunicaciones con sistemas que no son de confianza, puede agregarse la cuenta de equipo del sistema al grupo CG_NoFallbackIG_computers.

Grupo de aislamiento Cifrado

Woodgrove Bank decidió vincular la directiva del grupo de aislamiento Cifrado con el nivel de dominio en cada dominio de la organización. Esta directiva utiliza una ACL, que evita que aquellos que no sean miembros del grupo CG_EncryptionIG_computers apliquen la directiva. Los derechos de Aplicar directiva de grupo del grupo de usuarios autenticados se eliminaron de la ACL de la directiva.

Si la organización necesitara que un sistema se comunique únicamente con tráfico cifrado, puede agregarse la cuenta de equipo del sistema al grupo CG_EncryptionIG_computers.

Principio de la página

Autorización del acceso entrante para un grupo de aislamiento

Los requisitos de Woodgrove Bank incluyen permitir que sólo un subconjunto de hosts de confianza estén autorizados para el acceso de red entrante a los servidores del grupo de aislamiento Cifrado. La Tabla 4.8 del Capítulo 4 definía los siguientes grupos de acceso de red (NAG) para la implementación de estos requisitos:

Cuando un cliente inicia IKE con un servidor de cifrado, IKE debe obtener un vale de servicio Kerberos que contenga el identificador de grupo de seguridad de dominio que indica si el equipo cliente es miembro del grupo ANAG y/o del grupo DNAG. Si todos los equipos del grupo de aislamiento Cifrado son miembros del mismo dominio, entonces estos NAG podrán crearse como grupos de seguridad local del dominio. Si los equipos del grupo de aislamiento Cifrado son miembros de dominios de confianza independientes, podrá utilizarse un conjunto de grupos globales de dominio para los NAG o bien podrán crearse grupos locales de dominio en cada dominio. El escenario de Woodgrove Bank implica sólo un dominio, por lo tanto utiliza grupos locales de dominio para estos NAG.

El siguiente GPO adicional se creó para definir los derechos de Tener acceso a este equipo desde la red que implementan la autorización entrante:

Al grupo CG_EncryptionIG_Computers se le otorgan derechos de Lectura y aplicación para este GPO. El grupo de usuarios autenticados se elimina del derecho de Lectura y, por lo tanto, este GPO se aplica sólo a equipos que son miembros del grupo de aislamiento Cifrado.

Tal como se indica en la Tabla 4.8 del Capítulo 4, la cuenta de equipo del dominio del cliente autorizado IPS-ST-XP-05 se agrega al grupo de acceso de red ANAG_EncryptedResourceAccess_Computers. También se agregan las propias cuentas del servidor de cifrado IPS-SQL-DFS-01 e IPS-SQL-DFS-02. Sin embargo, podría haberse obtenido el mismo resultado de una forma más sencilla utilizando el grupo CG_EncryptionIG_computers para administrar una lista más extensa. Las cuentas deben estar autorizadas para tener el derecho de Tener acceso a este equipo desde la red de alguna forma, ya sea formando parte del ANAG, mediante la inclusión directa de su grupo CG_EncryptionIG_computers o bien mediante un listado explícito de cuentas de equipos en el derecho. De lo contrario, las cuentas no podrán establecer conexiones protegidas por IPsec entre ellas, tal como requieren sus aplicaciones. Para simular un entorno de dominios extenso, los grupos ANAG son los únicos que autorizan el acceso entrante para el escenario de Woodgrove Bank.

Puesto que el grupo de usuarios autenticados incluye a todos los equipos del dominio, deberá eliminarse del derecho Tener acceso a este equipo desde la red. A los usuarios del dominio autorizados deberá otorgárseles la autorización correspondiente de forma explícita, por ejemplo mediante el grupo integrado para usuarios del dominio. Sin embargo, en Woodgrove Bank se quiso aprovechar la capacidad de definir restricciones de acceso a la red entrante para los usuarios y para los equipos. Por ello se creó un grupo de seguridad local de dominio con el nombre  ANAG_EncryptedResourceAccess_Users y se completó con cuentas de usuarios de aplicaciones autorizados (por ejemplo, User7), así como el grupo de administradores locales y los grupos de administradores de dominio. Estas restricciones de acceso a la red en el nivel de usuario tienen lugar durante las peticiones de autenticación del protocolo de capa superior (como RPC, SMB y SQL) tras establecer con éxito la conectividad IPsec ESP 3DES.

Se crearon los siguientes grupos de seguridad de dominio con derechos de inicio de red para los servidores de cifrado. Residen en el GPO bajo Configuración del equipo, Configuración de Windows, Configuración de seguridad, Directivas locales, Asignación de derechos de usuario, derecho de Tener acceso a este equipo desde la red:

El grupo siguiente se configura para el mismo GPO, Denegar el acceso desde la red a este equipo:

Si asumimos que User7 no puede iniciar la sesión directamente en los servidores de cifrado, el resultado es que User7 debe utilizar el equipo cliente IPS-ST-XP-05 para acceder a los servidores IPS-SQL-DFS-01 o IPS-SQL-DFS-02. El equipo IPS-ST-XP-05 debe tener una cuenta de equipo de dominio válida y una directiva IPsec activa que inicie la negociación IKE con las direcciones IP de los servidores de cifrado.

Tenga en cuenta que al resto de los usuarios y equipos del dominio se les deniega el acceso, pues se han omitido intencionadamente del derecho de Tener acceso a este equipo desde la red. Sólo a los equipos Límite se les deniega explícitamente el acceso mediante el uso del DNAG como medida de defensa en profundidad ante cambios futuros de pertenencia a grupo que puedan incluir una cuenta de equipo Límite en un ANAG. Un parámetro de denegación explícito anula todo tipo de permiso.

Principio de la página

Consideraciones adicionales sobre IPsec

Además de definir las directivas IPsec, existen algunas consideraciones adicionales para una implementación IPsec satisfactoria. La hoja de cálculo Business_Requirements.xls de la carpeta Herramientas y plantillas aporta detalles de las restricciones que cabe tener en cuenta si se utiliza IPsec.

Exenciones predeterminadas

En Windows 2000 y Windows XP, los siguientes tipos de tráfico quedan exentos de coincidencias con filtro de forma predeterminada:

En la familia de sistemas operativos Windows Server 2003, el tráfico procedente de los protocolos de difusión, multidifusión, RSVP y autenticación Kerberos no está exento de coincidencias con filtro de forma predeterminada (sólo está exento el tráfico IKE). Los paquetes de difusión y multidifusión se omitirán si coinciden con un filtro con una acción de filtrado para negociar la seguridad. De forma predeterminada, la familia Windows Server 2003 proporciona compatibilidad limitada para el filtrado del tráfico de difusión y multidifusión. Un filtro con una dirección de origen "Cualquier dirección IP" coincidirá con las direcciones de difusión y difusión múltiple. Un filtro con una dirección de origen "Cualquier dirección IP" y una dirección de destino "Cualquier dirección IP" coincidirá con las direcciones de difusión múltiple entrantes y salientes. Puede utilizar dicho filtro para bloquear todo el tráfico. Sin embargo, no se admiten los filtros unidireccionales que se utilizarían para bloquear o permitir determinado tráfico de multidifusión o de difusión.

Como resultado del cambio en el comportamiento de las exenciones predeterminadas para la implementación de IPsec en la familia Windows Server 2003, deberá verificarse el comportamiento de las directivas IPsec para Windows 2000 o Windows XP y determinar si es preciso configurar filtros de permiso explícitos para permitir determinados tipos de tráfico. Para restaurar los comportamientos predeterminados de Windows 2000 y Windows XP para directivas IPsec, puede utilizar el comando Netsh o modificar el registro.

Para restaurar el controlador IPsec al comportamiento de filtrado predeterminado de Windows 2000 y Windows XP utilizando el comando Netsh

netsh ipsec dynamic set config ipsecexempt 0 

Para excluir todo el tráfico de difusión, multidifusión e IKE del filtrado IPsec modificando el registro

NAT Traversal

Como consecuencia de la forma en que funcionan los traductores de direcciones de red, los clientes pueden experimentar resultados inesperados cuando se comuniquen con servidores con Windows 2000 Server o Windows Server 2003 utilizando un traductor de direcciones de red que emplee IPsec NAT-T. De forma predeterminada, Windows XP SP2 ya no admite las asociaciones de seguridad IPsec NAT-T con dichos servidores.

Este cambio se introdujo para evitar un riesgo de seguridad percibido cuando se dé la secuencia de eventos siguiente:

Aunque es una situación poco probable, el comportamiento predeterminado de los equipos basados en Windows XP SP2 evita toda asociación de seguridad basada en IPsec NAT-T con servidores ubicados tras un traductor de direcciones de red para asegurarse de que nunca se dé este caso.

Si se necesitara establecer una comunicación IPsec a través de NAT, se recomienda utilizar direcciones IP públicas para todos los servidores que puedan conectarse directamente de Internet. Si esta configuración no fuera posible, podrá cambiar el comportamiento predeterminado de Windows XP SP2 para habilitar asociaciones de seguridad IPsec NAT-T con servidores ubicados tras un traductor de direcciones de red.

Para crear y configurar el valor de registro AssumeUDPEncapsulationContextOnSendRule

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\IPSec

Tras configurar AssumeUDPEncapsulationContextOnSendRule con el valor 1 o el valor 2, Windows XP SP2 puede conectarse con un servidor ubicado tras un traductor de direcciones de red.

Los servidores basados en Windows Server 2003 también requieren una actualización para funcionar correctamente con IPsec si están ubicados tras un dispositivo NAT. Consulte la siguiente URL para acceder a información sobre cómo obtener Windows Server 2003 Service Pack 1:

http://go.microsoft.com/fwlink/?LinkId=41652

Nota: para más información, consulte el artículo de Knowledge Base 885348, "IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators" (IPsec NAT-T no se recomienda para los equipos con Windows Server 2003 ubicados detrás de traductores de direcciones de red), disponible en http://support.microsoft.com/default.aspx?
scid=kb;en-us;885348. Este artículo explica los riesgos para la seguridad derivados del uso de este escenario. Cada cliente debe evaluar las ventajas de utilizar IPsec en este escenario considerando los riesgos de seguridad que comporta. Aunque Microsoft no recomienda este escenario debido a los riesgos de seguridad asociados, lo admite utilizando la configuración que se documenta en esta solución.

Para que las conexiones NAT entrantes funcionen correctamente, deberá habilitarse el descubrimiento de PMTU y deberá estar en funcionamiento. Algunas fuentes, como la Guía de consolidación de Windows XP y la Guía de consolidación de Windows Server 2003, recomiendan deshabilitar el descubrimiento de PMTU y, en algunas ocasiones, facilitan plantillas de directivas que deshabilitan la funcionalidad de descubrimiento de PMTU.

    Para habilitar el descubrimiento de PMTU

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\tcpip\parameters

Además, para un funcionamiento correcto, los hosts con Windows 2000 que participan en un escenario de NAT-T requieren la aplicación de la reparación asociada con el artículo de KB 818043, "L2TP/IPsec NAT-T update for Windows XP and Windows 2000" (Actualización L2TP/IPsec NAT-T para Windows XP y Windows 2000).

Para obtener más información, consulte los siguientes artículos de KB:

IPsec y el servidor de seguridad de Windows

El servidor de seguridad de Windows en equipos con Windows XP SP2 proporciona una protección adicional contra ataques bloqueando el tráfico entrante no solicitado. IPsec en Windows XP SP2 reconoce el servidor de seguridad de Windows. Si hay una directiva IPsec activa, los componentes IPsec de Windows XP SP2 indican al servidor de seguridad de Windows que abra los puertos UDP 500 y 4500 para permitir el tráfico IKE.

Otra característica adicional de la compatibilidad de IPsec es que el usuario puede especificar mediante directivas de grupo que todo el tráfico protegido por IPsec omita el procesamiento del servidor de seguridad de Windows. Para obtener más información, consulte el Apéndice A de las notas del producto “Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2” (Implementación de la configuración del servidor de seguridad de Windows para Microsoft Windows XP con SP2), disponibles en la dirección http://download.microsoft.com/download/
6/8/a/68a81446-cd73-4a61-8665-8a67781ac4e8/wf_xpsp2.doc.

IPsec y el servidor de seguridad de conexión a Internet (ICF)

Para los equipos basados en Windows XP sin SP2, el servidor de seguridad de conexión a Internet (ICF) puede satisfacer de un modo más adecuado los requisitos de seguridad para el filtrado del tráfico. ICF proporciona filtrado y puede bloquear el tráfico entrante de difusión y multidifusión en Windows XP SP1. Sin embargo, ICF no detecta el tráfico protegido mediante AH o ESP IPsec en modo de túnel o de transporte. Puesto que IPsec opera en la capa de red bajo ICF e IKE opera sobre ICF, deberá establecerse un permiso estático para IKE (puerto UDP 500) para el tráfico entrante. Si IPsec bloquea el tráfico, el registro de paquetes descartados por el ICF no incluirá los paquetes desechados por IPsec.

Principio de la página

Resumen

Este capítulo facilita información para crear e implementar directivas IPsec basadas en el diseño de grupo de aislamiento creado en el capítulo 4. Esta información se ha dividido en las siguientes siete tareas básicas:

Estas tareas completan las fases de diseño y planificación de la solución de aislamiento de servidor y dominio. La siguiente fase del proyecto es la implementación de un entorno de prueba que permita verificar el diseño. Microsoft llevó a cabo esta verificación en sus laboratorios de pruebas y utilizó el escenario de Woodgrove Bank como prueba piloto. Si desea recrear este entorno o estudiar las fases de implementación, en el Apéndice C de esta guía encontrará los pasos del proceso de implementación que utilizó Microsoft en sus laboratorios de prueba para validar el diseño del escenario.

Información adicional

Esta sección proporciona vínculos a información adicional sobre las tecnologías que se mencionan en este capítulo.

Información general acerca de IPsec

Información adicional

Principio de la página

6 de 13