Procedimientos adicionales de consolidación de servidores miembro

En esta página

	Descripción del módulo
	Objetivos
	Se aplica a
	Uso del módulo
	Introducción
	Protección de las cuentas
	NTFS
	Segmentación de datos y aplicaciones
	Configuración del nombre de comunidad SNMP
	Deshabilitación de NetBIOS y SMB en interfaces públicas
	Configuración del puerto de los Servicios de Terminal Server
	Configuración de las directivas IPSec

Descripción del módulo

En este módulo se describe cómo implementar algunas contramedidas adicionales de consolidación de servidores miembro, como la protección de las cuentas y la implementación de filtros IPSec.

Principio de la página

Objetivos

Utilice este módulo para

Principio de la página

Se aplica a

Este módulo se aplica a los siguientes productos y tecnologías:

Principio de la página

Uso del módulo

El objetivo de este módulo es ofrecer una referencia sobre los Procedimientos adicionales de consolidación de servidores miembro disponibles en las versiones actuales de los sistemas operativos Microsoft Windows. Ésta es una guía complementaria a otras dos publicaciones de Microsoft: la Guía de seguridad de Windows Server 2003, disponible en: http://www.microsoft.com/Spain/technet/seguridad/guias/guia_ws2003.asp y la Guía de seguridad de Windows XP.

Este módulo está organizado para describir las principales secciones que aparecen en la interfaz del usuario de edición de directivas de grupo. Empieza con una breve explicación de los temas que se van a tratar, seguida de una lista de los encabezados de subsección. Dichos encabezados corresponden a un valor o grupo de valores de configuración. Para cada valor, se proporciona una breve explicación de los efectos de la contramedida, así como tres subsecciones adicionales: Vulnerabilidad, Contramedida e Impacto potencial. La subsección Vulnerabilidad describe el modo en que un atacante puede explotar la contramedida si ésta se configura de un modo poco seguro. La subsección Contramedida explica cómo implementar la contramedida. La subsección Impacto potencial describe las consecuencias negativas que puede comportar la aplicación de la contramedida.

Principio de la página

Introducción

Aunque la mayoría de las contramedidas que se describen en esta guía pueden aplicarse a través de la directiva de grupo, existen otros valores de configuración que son difíciles o no se pueden aplicar mediante dicha directiva. En este módulo se describe cómo implementar algunas de estas contramedidas adicionales, tales como la protección de las cuentas. También se ofrece información general, referencias y orientaciones de configuración para utilizar el filtrado Seguridad IP (IPSec) como una contramedida eficaz frente a los ataques a la red.

Principio de la página

Protección de las cuentas

Microsoft Windows Server 2003 dispone de una serie de cuentas de usuario integradas que no se pueden eliminar, pero a las que sí se les puede cambiar el nombre. Dos de las cuentas integradas más conocidas en Windows Server 2003 son las cuentas de invitado y administrador.

Vulnerabilidad

La cuenta de invitado se deshabilita de forma predeterminada en todos los servidores miembro y controladores de dominio. No cambie este valor de configuración. Cambie el nombre de la cuenta integrada de Administrador y modifique la descripción para evitar que los atacantes pongan en peligro la seguridad de un servidor remoto mediante la utilización de un nombre conocido.

Muchas variaciones de código malintencionado utilizan la cuenta integrada de Administrador como primer intento para obtener acceso a un servidor. El valor de este cambio en la configuración se ha reducido en los últimos años debido a la existencia de herramientas de ataque que intentan obtener acceso al servidor mediante la especificación del identificador de seguridad (SID) de la cuenta integrada de Administrador. Un SID es el identificador único de cada usuario, grupo, cuenta de equipo e inicio de sesión de una red. No se puede modificar en el caso de esta cuenta integrada.

Contramedida

Cambie el nombre de la cuenta de Administrador y modifique la contraseña utilizando un valor largo y complejo en cada servidor.

Nota: el nombre de la cuenta integrada de Administrador puede cambiarse mediante la utilización de la directiva de grupo. Las directivas básicas que se incluyen con la Guía de seguridad de Microsoft Windows Server 2003 no implementan esta directiva porque debe elegirse un nombre exclusivo. Si la solución ha especificado un nombre para esta cuenta, es posible que algunas organizaciones que implementan estas plantillas de seguridad no cambien el valor de configuración, y utilicen el mismo nombre que se ha especificado en esta guía para las cuentas de administrador a las que se acaba de cambiar el nombre. Para cambiar el nombre de la cuenta, utilice el valor de configuración Cambiar nombre de cuenta de administrador en la directiva de grupo de su entorno que se encuentra en:

Configuración del equipo\Configuración de Windows\Configuración de seguridad\Directivas locales\Seguridad\Opciones

Lo ideal sería que las organizaciones empleasen una contraseña diferente en cada servidor, pero esto implica una carga de administración demasiado elevada en la mayoría de los casos. Registre estos cambios en un lugar seguro. Si su organización utiliza los mismos nombres de cuenta y contraseñas en todos los servidores, los atacantes que logren tener acceso a un servidor miembro podrán tener acceso a todos los demás.

Impacto potencial

Los usuarios responsables de la administración de los sistemas deben realizar un seguimiento de los nombres de cuenta que se asignan a cada uno de los equipos. Los usuarios que deban iniciar la sesión en un servidor determinado con la cuenta de administrador local, deberán consultar esta documentación protegida para averiguar el nombre de usuario y la contraseña de dicho servidor.

Principio de la página

NTFS

Las particiones de valores de configuración NTFS admiten las listas de control de acceso (ACL) y, opcionalmente, el cifrado (mediante el Sistema de archivos de cifrado, EFS) en los niveles de archivo y carpeta. Esta compatibilidad no se encuentra disponible con los sistemas de archivos FAT (tabla de asignación de archivos), FAT32 o FAT32x. FAT32 es una versión actualizada del sistema de archivos FAT, que permite tamaños predeterminados de clúster bastante más pequeños y que admite discos duros con un tamaño máximo de dos terabytes. FAT32 se incluye en Microsoft Windows 95 OSR2, Windows 98, Windows Me, Windows Server 2003 y Windows XP.

Vulnerabilidad

Los usuarios no autorizados pueden ver, cambiar o eliminar fácilmente los archivos que no se pueden proteger con listas ACL, ya que pueden tener acceso a los mismos localmente o a través de la red. Las listas ACL ayudan a proteger dichos archivos, pero el cifrado ofrece una protección muy superior y resulta una opción viable para los archivos a los que sólo un usuario necesita tener acceso.

Contramedida

Formatee todas las particiones en cada servidor mediante NTFS. Emplee la utilidad de conversión para convertir de forma no destructiva particiones FAT a NTFS, pero no olvide que dicha utilidad establecerá las listas ACL de la unidad convertida en Todos: Control total.

En los sistemas basados en Windows Server 2003 y Windows XP, aplique las siguientes plantillas de seguridad localmente para configurar las listas ACL predeterminadas del sistema de archivos:

Consulte "Fortalecimiento de los hosts baluarte" en la "Guía de seguridad de Windows Server 2003" en la dirección: http://go.microsoft.com/fwlink/?LinkId=14845 para obtener instrucciones sobre cómo aplicar plantillas de seguridad localmente.

Nota: los valores de configuración de seguridad del controlador de dominio se aplican durante la promoción de un servidor a un controlador de dominio.

Impacto potencial

No tiene ningún impacto negativo.

Importante: la configuración correcta de los permisos de NTFS permite proteger los datos de la organización frente a la exposición o manipulación, pero es fundamental que no se olvide de la seguridad física. Un atacante que haya obtenido el control físico de un equipo podrá iniciarlo en otro sistema operativo mediante un CD-ROM o un disquete de inicio. Un atacante que haya extraído un disco duro de uno de los equipos de su organización podrá trasladarlo a otro equipo no administrado. Una vez que el atacante tenga control físico total del medio de almacenamiento, será muy difícil proteger los datos.

Se trata de un problema fundamental de la tecnología informática que también existe en los sistemas de archivos de otros sistemas operativos. Una vez que el atacante tenga acceso físico al disco, los permisos de NTFS (y la mayoría de las demás salvaguardas) podrán omitirse fácilmente. Además de las medidas obvias de seguridad física que puede implementar su organización (como la restricción del acceso a los edificios, la instalación de cierres magnéticos en las salas de los servidores, el bloqueo de los servidores en soportes de servidor, el bloqueo de los equipos portátiles en estaciones de acoplamiento), Microsoft recomienda las siguientes tecnologías adicionales que permiten reducir el impacto de estos tipos de ataques:

Principio de la página

Segmentación de datos y aplicaciones

Durante mucho tiempo se ha considerado una práctica aconsejable separar los archivos de datos, de aplicaciones y de sistemas operativos en dispositivos de almacenamiento diferentes para mejorar el rendimiento del sistema. Otro motivo importante para segregar estos tipos de archivos en los servidores consiste en proteger las aplicaciones, los datos y los sistemas operativos frente a ataques de salto al directorio.

Vulnerabilidad

Hay dos tipos de vulnerabilidades a las que se expone al colocar los archivos de aplicaciones, de datos y de registro en el mismo volumen de almacenamiento que el sistema operativo. Una amenaza potencial consiste en que uno o varios usuarios llenen de datos el volumen de almacenamiento (ya sea por accidente o de forma deliberada) al provocar que un archivo de registro de aplicación llene la unidad o al cargar archivos en el servidor.

La segunda amenaza potencial consiste en los ataques de salto al directorio, en los que un atacante se aprovecha de la falta de seguridad de un servicio de red para desplazarse por el árbol de directorios hasta la raíz del volumen del sistema. El atacante podrá entonces desplazarse a través de las carpetas de archivos del sistema operativo para ejecutar una utilidad de forma remota.

Existen cientos de variaciones de los ataques de salto al directorio que aprovechan la vulnerabilidad de los sistemas operativos y las aplicaciones. IIS ha sido vulnerable a varios de ellos durante los últimos años. Por ejemplo, los gusanos NIMDA y Code Red explotaron el desbordamiento de búfer para recorrer árboles de directorios de sitios Web y ejecutar de forma remota cmd.exe para obtener acceso a un shell remoto y ejecutar comandos adicionales.

Por lo tanto, en la medida de lo posible, conviene colocar el contenido Web, las aplicaciones, los datos de usuario, los registros de la aplicación y otros archivos no necesarios para el sistema operativo en una partición de almacenamiento independiente del volumen del sistema.

Contramedida

Si es posible, reubique el contenido Web, los archivos de aplicaciones, de datos, o de registro de la aplicación en una partición independiente del volumen del sistema.

Impacto potencial

Para las organizaciones que crean y mantienen los servidores de forma sólida, el impacto será pequeño. Para las organizaciones que no mantienen esta información, el impacto será un poco mayor, porque los administradores tendrán que investigar cómo está configurado cada sistema cuando trabajen en un sistema con el que no estén familiarizados.

Principio de la página

Configuración del nombre de comunidad SNMP

El Protocolo simple de administración de redes (SNMP) es una regla de administración de redes que se utiliza de forma generalizada con las redes de Protocolo de control de transmisión/Protocolo Internet (TCP/IP). SNMP proporciona un método de administrar los nodos de red (servidores, estaciones de trabajo, enrutadores, puentes y concentradores) desde un host central. SNMP realiza los servicios de administración correspondientes mediante la utilización de una arquitectura distribuida de sistemas y agentes de administración. Los sistemas que ejecutan programas de administración de redes se conocen como sistemas de administración SNMP o administradores SNMP. Los nodos de red administrados se conocen como agentes SNMP.

El servicio SNMP ofrece una forma rudimentaria de seguridad mediante la utilización de nombres de comunidad y capturas de autenticación. Es posible restringir las comunicaciones SNMP del agente y permitirle que se comunique únicamente con una lista definida de sistemas de administración SNMP. Los nombres de comunidad permiten autenticar los mensajes SNMP y, por lo tanto, proporcionan un esquema de seguridad rudimentario para el servicio SNMP. Aunque un host puede pertenecer a varias comunidades a la vez, un agente SNMP no acepta solicitudes de un sistema de administración perteneciente a una comunidad que no se encuentre en su lista de nombres de comunidad aceptables. No existe ninguna relación entre los nombres de comunidad y los nombres de dominio o de grupo de trabajo. Un nombre de comunidad puede considerarse una contraseña compartida por las consolas de administración de SNMP y los equipos administrados. Forma parte de sus responsabilidades como administrador del sistema establecer nombres de comunidad difíciles de averiguar al instalar el servicio SNMP.

Vulnerabilidad

El protocolo SNMP es inevitablemente débil en materia de seguridad. La gran vulnerabilidad de SNMP consiste en que prácticamente todos los proveedores establecen un nombre de cadena de comunidad predeterminado. Como resultado, dichos nombres son conocidos; por ejemplo, Microsoft utiliza el término Public.

Hay una segunda vulnerabilidad más difícil de solucionar: dado que el tráfico SNMP se envía en texto no cifrado, cuando un dispositivo de administración SNMP establece comunicación con un cliente SNMP, la cadena de comunidad se transmite a través de la red sin cifrar y sin utilizar valores hash. Para solucionar esta segunda vulnerabilidad, cifre todo el tráfico entre servidores; no obstante, esta contramedida está fuera del ámbito de la presente guía.

Contramedida

Configure la cadena de comunidad SNMP para acceso de lectura en todos los sistemas con un valor alfanumérico aleatorio.

Deje deshabilitado el acceso de escritura mediante SNMP.

Nota: el nombre de comunidad se almacena en el Registro como un valor de registro con un valor DWORD de 4; para automatizar este cambio, cree una secuencia de comandos o agregue una línea a una plantilla de seguridad e importe la plantilla a una directiva de grupo basada en el dominio. El valor se almacena en: HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities.

Impacto potencial

Asimismo, debe volver a configurar la cadena de comunidad en todas las herramientas de administración que utilicen el protocolo SNMP.

Principio de la página

Deshabilitación de NetBIOS y SMB en interfaces públicas

En esta sección se describen las recomendaciones específicas para los servidores que se encuentran en redes que no pueden controlarse por completo (por ejemplo, los servidores Web accesibles públicamente o las puertas de acceso de correo electrónico corporativo). Este tipo de servidores se conoce a menudo como host de baluarte. Si tiene algún servidor de este tipo, considere la implementación de los siguientes cambios recomendados, pero compruebe cada uno de ellos detenidamente y asegúrese de que comprende los retos que la deshabilitación del servicio básico de entrada y salida de red (NetBIOS) supondrá en la administración de los sistemas.

Vulnerabilidad

La deshabilitación de Bloque de mensajes del servidor (SMB) y NetBIOS a través de TCP/IP protege un host de baluarte al reducir considerablemente la superficie de ataque del servidor. Aunque los servidores que operan bajo esta configuración son más difíciles de administrar y no pueden obtener acceso a las carpetas compartidas de la red, estas medidas protegen de forma eficaz al servidor, ya que evitan que éste se vea fácilmente en una situación que ponga en peligro su seguridad. Por lo tanto, deshabilite SMB y NetBIOS a través de TCP/IP para las conexiones de red de los servidores a los que se puede tener acceso desde Internet.

Contramedida

No basta con deshabilitar NetBIOS para evitar la comunicación de SMB. Esto se debe a que, cuando no existen puertos NetBIOS estándar, SMB utiliza el puerto 445 del Protocolo de control de transmisión (TCP), que se conoce como host directo de SMB o puerto del sistema común de archivos de Internet (CIFS). En consecuencia, deben realizarse algunos pasos explícitos para deshabilitar NetBIOS y SMB por separado.

NetBIOS utiliza los puertos siguientes:

SMB utiliza los puertos siguientes:

Para deshabilitar SMB en servidores accesibles desde Internet, deberá quitar Compartir impresoras y archivos para redes Microsoft y Cliente para redes Microsoft mediante el cuadro de diálogo de propiedades del Protocolo de control de transmisión/Protocolo Internet (TCP/IP) del cuadro de diálogo de propiedades Conexión de área local.

De esta forma se deshabilitará el servicio de escucha de host directo de SMB en TCP/445 y UDP 445.

Nota: este procedimiento deshabilita el controlador nbt.sys. Aunque deshabilita el Servicio de sesión NetBIOS (que escucha en el puerto TCP 139), no deshabilitará SMB por completo. Para ello, siga los pasos indicados anteriormente en el procedimiento denominado "Para deshabilitar SMB".

Impacto potencial

Ningún sistema podrá conectarse al servidor a través de SMB. Los servidores no podrán tener acceso a las carpetas compartidas de la red. Muchas de las herramientas de administración no podrán establecer conexión con los servidores.

Principio de la página

Configuración del puerto de los Servicios de Terminal Server

Los Servicios de Terminal Server constituyen una herramienta de gran utilidad para los administradores de la red, porque habilitan la administración de los equipos del servidor remoto y del usuario final. El cliente de Escritorio remoto se instala de manera predeterminada en todos los sistemas Windows Server 2003 y Windows XP, y está disponible como componente opcional en el medio de instalación de Windows 2000 Server. Asimismo, se puede descargar un cliente Microsoft ActiveX® que se ejecuta en Internet Explorer o en Microsoft Management Console (MMC). Estos se conocen conjuntamente como TSAC (Terminal Services Advanced Client, Cliente avanzado de Servicios de Terminal Server).

Vulnerabilidad

Los Servicios de Terminal Server escuchan en el puerto TCP 3389 de manera predeterminada, y todas las versiones de los clientes de Escritorio remoto intentan conectarse a dicho puerto. Aunque toda la sesión está cifrada (incluida la autenticación del usuario), los clientes de los Servicios de Terminal Server no realizan la autenticación del servidor. Un atacante que pueda imitar a un servidor legítimo de los Servicios de Terminal Server podrá engañar a los usuarios para que se conecten al servidor del atacante en lugar de hacerlo al sistema genuino. Un atacante podrá engañar al usuario para que se conecte a su servidor al modificar los registros DNS para redirigir a los usuarios a su propio sistema o a cualquier otro.

Contramedida

Cambie el puerto TCP utilizado por los Servicios de Terminal Server o implemente una directiva IPSec que requiera confianza y negociación AH (Encabezado de autenticación) o ESP (Carga de seguridad encapsuladora) mediante la utilización del modo de transporte IPSec (no el modo de túnel IPSec). En algún caso, es posible aislar Terminal Server tras una puerta de enlace VPN, de modo que para tener acceso a Terminal Server sean necesarios túneles VPN protegidos mediante Protocolo de túnel punto a punto (PPTP) o mediante L2TP/IPSec.

Para obtener información sobre cómo cambiar el puerto utilizado por los Servicios de Terminal Server y el cliente de Escritorio remoto, consulte el artículo de Microsoft Knowledge Base "Cómo cambiar el puerto en el que escucha Terminal Server" en la dirección: http://support.microsoft.com/default.aspx?scid=187623. En dicho artículo se muestra cómo cambiar el puerto para el cliente de escritorio normal. Para cambiarlo en el cliente Web avanzado de Servicios de Terminal Server, deberá agregar la siguiente línea de secuencia de comandos a la página Web MsRdpClient.RDPport = xxx, donde xxx es el número de puerto TCP deseado. Para obtener más información sobre el modo de utilizar y personalizar la Conexión Web al Escritorio remoto para ejecutar sesiones de los Servicios de Terminal Server en Microsoft Internet Explorer, consulte "Providing for RDP Client Security", en la dirección http://msdn.microsoft.com/library/default.asp?url=/library/en-us/termserv/termserv/providing_for_rdp_client_security.asp.

Impacto potencial

La implementación de IPSec con AH tiene un impacto mínimo en el rendimiento del sistema; no obstante, implica un aumento de la carga para la administración de la configuración IPSec de cliente y servidor, así como la administración de un método de confianza mutua entre los equipos cliente y servidor utilizados por la negociación de seguridad de Intercambio de claves de Internet (IKE) antes de establecer asociaciones de seguridad IPSec. La directiva IPSec se debe designar para proteger todo el tráfico al servidor o para que IPSec sea necesario únicamente para las conexiones al puerto TCP 3389. Si IPSec es necesario en el servidor, se denegará el acceso a los equipos cliente que no tengan una configuración y confianza compatibles con IPSec. Consulte la sección siguiente para obtener más información acerca de la utilización de directivas IPSec para negociar la seguridad del tráfico TCP/IP.

Al cambiar los puertos predeterminados en los servidores y clientes de los Servicios de Terminal Server, los usuarios legítimos que no tengan configurado su software cliente utilizarán el nuevo puerto. No podrán conectarse a ningún sistema mediante los Servicios de Terminal Server. Asimismo, en la versión actual de TSAC no es posible cambiar el puerto TCP.

Principio de la página

Configuración de las directivas IPSec

IPSec de la familia de sistemas Microsoft Windows Server 2003, Windows XP y Windows 2000 es una herramienta que permite que los administradores de la seguridad de la red permitan, bloqueen o negocien la seguridad del tráfico TCP/IP de forma independiente y transparente para la aplicación. El objetivo de diseño para Windows 2000 consistía en proporcionar una forma de proteger el tráfico de la red mediante la utilización del formato AH o ESP de los protocolos IPSec. La directiva IPSec proporciona filtros de tráfico TCP/IP estáticos (denominados también "selectores") necesarios para negociar la seguridad mediante IKE, que también se conoce como protocolo ISAKMP.

El módulo "Deploying IPSec" del Windows Server 2003 Deployment Kit: Deploying Network Services proporciona información detallada sobre las capacidades más recientes de IPSec. La sección "Determining Your IPSec Needs" de este módulo identifica los usos de IPSec: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/deployguide/dnsbj_ips_wclw.asp.

Vulnerabilidad

Aunque la mayoría de las estrategias de seguridad de la red se han centrado en evitar los ataques externos a la red de la organización, se puede perder una gran cantidad de información confidencial debido a ataques internos que interpretan los datos de la red o que explotan los puntos débiles de diseño o implementación de los protocolos de capa superior para tener acceso al equipo. El atacante puede utilizar sesiones nulas de NetBT para obtener información de utilidad que pone en peligro las contraseñas de administrador (si no se utilizan otros valores de configuración de seguridad o si éstos se desactivan accidentalmente).

El atacante sólo tiene que localizar una vulnerabilidad de un puerto de la aplicación para obtener acceso al equipo e incluso llegar a controlarlo por completo. Tal como se menciona anteriormente en este documento, muchos tipos de datos no están protegidos cuando viajan a través de la red. Como consecuencia, los empleados, los miembros del personal de asistencia o los visitantes pueden entrar en su red y copiar los datos para analizarlos posteriormente. Los servidores de seguridad situados entre la red interna e Internet no ofrecen protección frente a este tipo de amenazas internas. Los servidores de seguridad internos a menudo no pueden proporcionar controles de acceso autenticados, necesarios para proteger a clientes y servidores, ni tampoco pueden proporcionar una seguridad total del tráfico de red entre equipos.

Contramedida

Los filtros IPSec reconocen el tráfico TCP/IP por la dirección IP de origen y de destino, por el tipo de protocolo IP y por los puertos TCP y UDP. Por lo tanto, el filtrado IPSec puede ayudar a contener y controlar la propagación de código malicioso procedente de gusanos y virus, mediante el bloqueo de su tráfico. Asimismo, puede resultar muy difícil para un atacante utilizar los shell remotos u otras utilidades de ataque para tener acceso al equipo desde una aplicación comprometida. Si desea obtener más información sobre cómo aplicar una directiva IPSec en Windows 2000 para bloquear los puertos, consulte Q813878 "Cómo Utilizando IPSec a Protocolos de red de Bloque y Puertos Específicos" en la dirección: http://support.microsoft.com/default.aspx?scid=813878, y consulte también "Using IPSec to Lock Down a Server" en la dirección: http://www.microsoft.com/serviceproviders/columns/using_ipsec.asp.

Estas notas del producto constituyen una guía de configuración detallada para el filtrado IPSec de permiso/bloqueo de Windows 2000 similar a esta guía. No obstante, se deben agregar los valores de configuración del registro NoDefaultExempt recomendados por Q813878 para Windows 2000.

Windows Server 2003 proporciona el complemento Administración de directivas IPSec, una interfaz gráfica de usuario (GUI) que permite administrar la directiva IPSec. La GUI de complemento es muy similar a la de Windows 2000 y Windows XP. Windows Server 2003 proporciona el complemento Monitor IPSec MMC y la utilidad de línea de comandos IPSec NETSH para mostrar los filtros de directiva IPSec aplicados en el equipo. Los filtros de permiso y bloqueo aparecen en la configuración Modo rápido IKE. Los filtros Modo rápido IKE genéricos son los filtros definidos en la directiva IPSec asignada. Los filtros Modo rápido IKE específicos son el resultado de la directiva aplicada a la configuración IP concreta del equipo. Tenga en cuenta que la función de los filtros Modo rápido IKE específicos Buscar filtros coincidentes no se puede utilizar para buscar coincidencias de los filtros de permiso y bloqueo, sino únicamente para los filtros que tengan una acción de negociación.

A continuación se describen los términos siguientes:

Una forma fácil de registrar esta información es mediante una tabla denominada mapa de tráfico de red. Este tipo de mapa contiene información básica acerca de la función del servidor, la dirección del tráfico de la red, el destino del tráfico, la dirección IP de la interfaz, el protocolo IP, el puerto TCP y el puerto de Protocolo de datagramas de usuario (UDP) implicados. A continuación se muestra un ejemplo de mapa de tráfico de red.

Un mapa de tráfico de red permite comprender qué tráfico de la red entra y sale de determinados servidores. Antes de crear directivas IPSec, es fundamental conocer los detalles del tráfico, hecho necesario para que el servidor funcione correctamente. De lo contrario, podrían crearse filtros demasiado estrictos que originarían errores de la aplicación.

Si se empieza por los filtros IPSec más restrictivos y se abren puertos adicionales sólo cuando sea necesario, se puede obtener el máximo nivel de seguridad posible para estos valores de configuración. Este proceso es mucho más fácil si los servicios se dividen en servicios de cliente y de servidor. Deben definirse los servicios de servidor para cualquier servicio que la máquina proporcione a otros hosts.

Tabla 1: Ejemplo de mapa de tráfico de red

En el ejemplo anterior, el servidor Web proporcionará servicios HTTP y HTTPS a los equipos desde cualquier dirección IP de origen con el fin de permitir el tráfico adecuado. El servicio IPSec interpreta el destino YO para crear un filtro para cada una de las direcciones IP del equipo. Cada uno de estos filtros se reflejará para permitir que el tráfico regrese al equipo de origen. Esto significa que la regla del servidor HTTP permitirá que el tráfico originado en cualquier host de cualquier puerto de origen se conecte al puerto 80 del servidor IIS. El reflejo de esta regla permitirá que el tráfico TCP del puerto 80 del servidor IIS vaya a cualquier puerto de cualquier host.

Los servicios de cliente pueden ser cualquier servicio realizado por el equipo en el que las directivas utilicen otro host. Por ejemplo, en el caso anterior, el servidor puede necesitar que los servicios del cliente DNS realicen búsquedas de nombre para una de las aplicaciones Web. En este ejemplo, el filtro se ha creado para permitir el tráfico a y desde los servidores DNS. Windows Server 2003 ofrece directivas mejoradas a través de Windows 2000 Server para este tipo de configuración, que permiten el tráfico al servidor DNS y a otros servidores de infraestructura. En Windows 2000, la directiva IPSec debe contener cada una de las direcciones IP del servidor DNS en la directiva. En Windows Server 2003, la directiva puede utilizar el DNS de nombre lógico, que se expandirá en un filtro para cada dirección IP del servidor DNS, en función de la configuración IP local del servidor. Tenga en cuenta que las directivas IPSec que utilizan funciones de Windows Server 2003 como ésta última no deben asignarse a un equipo que utilice Windows 2000 o Windows XP.

El filtro de bloqueo reflejado de Cualquier dirección IP a Mi dirección IP bloqueará el resto del tráfico IP de unidifusión procedente o dirigido a una dirección IP del equipo. Este filtro es más general que los filtros específicos de protocolo y puerto definidos anteriormente para DNS, HTTP y HTTPS. Dado que en Windows Server 2003 se han quitado las exenciones predeterminadas, este filtro buscará coincidencias y bloqueará los paquetes de difusión y multidifusión salientes, ya que la dirección IP de origen es Mi dirección IP y la dirección de destino coincide con Cualquier dirección IP. Sin embargo, tenga en cuenta que este filtro no busca coincidencias del tráfico de difusión y multidifusión entrante. La dirección de origen sería Cualquier dirección IP, pero la dirección de destino de un paquete de difusión o multidifusión no es una dirección IP específica del equipo, sino una dirección IP de difusión o multidifusión. Por lo tanto, esta regla no bloqueará el tráfico de difusión o multidifusión entrante en Windows Server 2003. Esta definición de filtro también es compatible con Windows 2000 y Windows XP. Sin embargo, sólo buscará coincidencias del tráfico IP de unidifusión. Estas plataformas no se han diseñado para buscar coincidencias de los paquetes de difusión y multidifusión con los filtros IPSec. Por lo tanto, se permitirán los paquetes de difusión y multidifusión entrantes y salientes aunque este filtro se aplique en equipos con Windows 2000 y Windows XP.

La última regla, Bloquear todo, muestra otra mejora del filtrado para Windows Server 2003. Esta regla no es compatible con Windows 2000 ni Windows XP. Este filtro bloquea el tráfico de difusión y multidifusión entrante y saliente, así como cualquier otro tráfico de unidifusión que no coincida con un filtro más específico. Si se utiliza esta regla, la regla "Cualquier dirección IP a Me" no es necesaria.

Es importante indicar que si se aplicase una directiva de este tipo, el equipo no podría establecer comunicación con el servidor DHCP correspondiente para renovar una concesión, ni con los controladores de dominio, los servidores WINS, los sitios de revocación de listas CRL ni las estaciones de supervisión de servidores. Asimismo, esta directiva no permite que un administrador obtenga acceso a la administración remota mediante complementos MMC basados en RPC ni a una conexión con un cliente de Escritorio remoto. Observe también que si el servidor IIS de ejemplo tuviese dos tarjetas de interfaz de red (una para el acceso a Internet y otra para el acceso interno), todo el tráfico a través de ambas interfaces se filtraría de la misma forma. Por lo tanto, esta directiva debe personalizarse considerablemente para adaptarse a los entornos de producción. El tráfico de red se debe filtrar de forma diferente para la dirección IP interna o la subred. Cuando sea posible, las reglas de filtrado utilizadas para solicitar la administración remota del cifrado IPSec desde estaciones de administración específicas, también deberán utilizarse para impedir que otros servidores comprometidos obtengan acceso a los servidores a través de la interfaz interna, o capturen el tráfico de red de inicio de sesión administrativa para los ataques sin conexión.

Si se requiere un servicio de cliente que no puede restringirse para la conexión con un servidor de destino concreto o con un número limitado de servidores de destino, el nivel de seguridad proporcionado por los filtros IPSec puede verse reducido considerablemente. En el ejemplo siguiente, se agrega una regla, de modo que un administrador pueda utilizar un explorador Web para tener acceso a cualquier sitio de Internet para obtener información de ayuda y descargar revisiones. Para ello es necesario un filtro de permiso estático saliente reflejado para el tráfico del puerto TCP 80 de destino.

Tabla 2: Ejemplo de mapa de tráfico de red que permite la exploración Web saliente

Aunque esta configuración parece correcta, el resultado real es que la directiva no proporciona ninguna seguridad frente a un atacante que inicie una conexión entrante desde Cualquier dirección IP mediante el puerto TCP de origen 80. Este atacante puede obtener acceso a cualquier puerto TCP abierto a través del filtro de permiso entrante, y se permite la respuesta a través del filtro de permiso saliente de vuelta al puerto TCP de destino 80.

Se pueden utilizar diversas soluciones para bloquear el ataque entrante:

En el ejemplo siguiente se utilizan filtros IPSec adicionales que bloquean a un atacante que intenta obtener acceso a los puertos abiertos desde el puerto 80. El comando netstat –ano se utiliza para determinar qué puertos TCP deben estar abiertos en el servidor al que podría conectarse el atacante:

C:\Documents and Settings\testuser.domain.000>netstat -ano
Conexiones activas

  Protocolo  Dirección local        Dirección externa      Estado           PID
  TCP        0.0.0.0:135            0.0.0.0:0              ESCUCHANDO       740
  TCP        0.0.0.0:445            0.0.0.0:0              ESCUCHANDO       4
  TCP        0.0.0.0:1025           0.0.0.0:0              ESCUCHANDO       884
  TCP        0.0.0.0:1046           0.0.0.0:0              ESCUCHANDO       508
  TCP        192.168.0.5:139        0.0.0.0:0              ESCUCHANDO       4
  UDP        0.0.0.0:445            *:*                                     4
  UDP        0.0.0.0:500            *:*                                     508
  UDP        0.0.0.0:1026           *:*                                     816
  UDP        0.0.0.0:1029           *:*                                     508
  UDP        0.0.0.0:1051           *:*                                     452
  UDP        0.0.0.0:4500           *:*                                     508
  UDP        127.0.0.1:123          *:*                                     884
  UDP        192.168.0.5:123        *:*                                     884
  UDP        192.168.0.5:137        *:*                                     4
  UDP        192.168.0.5:138        *:*                                     4

La regla siguiente se define para bloquear los ataques específicos del puerto TCP de origen 25 a cada puerto TCP abierto como se indica a continuación:

Tabla 3: Ejemplo de mapa de tráfico de red que permite la exploración Web saliente

En el ejemplo se muestra el modo de bloquear un ataque entrante mediante la creación de filtros unidireccionales que bloqueen el tráfico entre un puerto de origen 80 y cualquier puerto activo del equipo. En el ejemplo anterior se impide que un usuario que imite un puerto de origen 80 se conecte a los puertos necesarios para RPC, NetBT y SMB (CIFS).

Es posible distribuir las directivas IPSec en función de la directiva de grupo. Sin embargo, cuando las directivas IPSec deben adaptarse a determinados equipos, puede ser más aconsejable utilizar directivas locales. Otra alternativa más fácil de administrar consiste en la combinación de la directiva local o basada en el dominio y la directiva persistente con secuencias de comandos NETSH IPSec. Concretamente, NETSH se debe utilizar para establecer una directiva persistente que ofrezca seguridad durante el inicio del equipo. El siguiente archivo de entrada para NETSH permite implementar la directiva anterior. Asimismo, garantiza el inicio seguro del equipo mediante la directiva persistente. Se puede ejecutar mediante netsh – f <archivo de entrada> cuando se incluyen los comandos siguientes en el archivo de entrada.

pushd ipsec dynamic

set config property=ipsecexempt value=3
set config property=bootmode value=stateful
set config property=bootexemptions value="ICMP:inbound 
UDP:67:68:inbound 
TCP:0:3389:inbound"

popd
pushd ipsec static

set store persistent
delete all
add policy name="PERS:Safe startup" activatedefaultrule=no
add filterlist name="PERS:Any to Any all traffic"
add filter filterlist="PERS:Any to Any all traffic" srcaddr=Any 
dstaddr=Any 
description="PERS:Any<->Any all traffic, includes inbound and 
outbound multicast 
and broadcast"
add filteraction name="PERS:BLOCK" action=block

add rule name="PERS:rule1" policy="PERS:Safe startup" filterlist="PERS:
Any to Any 
all traffic" filteraction="PERS:BLOCK"

set policy name="PERS:Safe startup" assign=yes

set store local

delete policy name="Domain Member IIS Server Permit/Block Lockdown, 
with outbound
HTTP:80 Access"
delete filterlist name="Any to Me, all traffic"
delete filterlist name="Inbound ICMP for TCP PMTU"
delete filterlist name="Inbound IIS Server:HTTP:80"
delete filterlist name="Inbound IIS Server:FTP:21"
delete filterlist name="Inbound Terminal Server"
delete filterlist name="Me to Domain DCs all traffic, <date>"
delete filterlist name="Outbound WINS"
delete filterlist name="Outbound UDP/TCP DNS"
delete filterlist name="Outbound DHCP"
delete filterlist name="Outbound HTTP:80"
delete filterlist name="Mitigation from inbound src 80 attack"
delete filteraction name="BLOCK"
delete filteraction name="PERMIT"

add policy name="Domain Member IIS Server Permit/Block Lockdown, 
with outbound 
HTTP:80 Access" description="Allow inbound HTTP, HTTPS, Remote
 Desktop.
Allow outbound HTTP:80, DC, DNS, WINS access. Used with persistent 
Any-to-Any all 
traffic block for secure computer startup" activatedefaultrule=no
add filteraction name="BLOCK" action=block
add filteraction name="PERMIT" action=permit

add filterlist name="Any to Me, all traffic" description="also includes 
me to any 
outbound unicast, multicast, broadcast"
add filter filterlist="Any to Me, all traffic" srcaddr=Any dstaddr=Me 
mirrored=yes 
protocol=Any description="Any<->Me, all traffic"
add rule name="Block all unicast" policy="Domain Member IIS Server 
Permit/Block 
Lockdown, with outbound HTTP:80 Access" filterlist="Any to Me, 
all traffic" 
filteraction="BLOCK"

add filterlist name="Inbound ICMP for TCP PMTU"
add filter filterlist="Inbound ICMP for TCP PMTU" srcaddr=Any dstaddr=
Me 
protocol=ICMP mirrored=no description="Any->me ICMP for TCP PMTU"
add rule name="Enable TCP PMTU" policy="Domain Member IIS Server 
Permit/Block 
Lockdown, with outbound HTTP:80 Access" filterlist="Inbound ICMP for 
TCP PMTU" 
filteraction="PERMIT"

add filterlist name="Inbound IIS Server:HTTP:80"
add filter filterlist="Inbound IIS Server:HTTP:80" srcaddr=Any dstaddr=Me 
protocol=TCP srcport=0 dstport=80 mirrored=yes description="Any<->Me, 
TCP src Any, 
dst 80, inbound web"
add rule name="IIS Web Server" policy="Domain Member IIS Server Permit/
Block 
Lockdown, with outbound HTTP:80 Access" filterlist="Inbound IIS Server:
HTTP:80" 
filteraction="PERMIT" activate=yes

add filterlist name="Inbound IIS Server:FTP:21"
add filter filterlist="Inbound IIS Server:FTP:21" srcaddr=Any dstaddr=Me
protocol=TCP srcport=0 dstport=21 mirrored=yes description="Any<->Me,
TCP src 
Any, dst 80, inbound web"
add rule name="IIS FTP Server" policy="Domain Member IIS Server Permit/
Block 
Lockdown, with outbound HTTP:80 Access" filterlist="Inbound IIS Server:
FTP:21" 
filteraction="PERMIT" activate=no

add filterlist name="Inbound Terminal Server"
add filter filterlist="Inbound Terminal Server" srcaddr=Any dstaddr=Me 
protocol=TCP srcport=0 dstport=3389 mirrored=yes description="Any<->Me,
 TCP src 
Any, dst 3389, inbound remote desktop"
add rule name="Terminal Server" policy="Domain Member IIS Server Permit/
Block 
Lockdown, with outbound HTTP:80 Access" filterlist="Inbound Terminal 
Server" 
filteraction="PERMIT" activate=no

popd

pushd ipsec dynamic
add mmpolicy name="N/A"
add rule srcaddr=Me dstaddr=DNS mmpolicy="N/A" protocol=UDP srcport=0 
dstport=53 
conntype=all mirrored=yes actionoutbound=permit actioninbound=permit
popd

pushd ipsec static

set store local

add filterlist name="Me to Domain DCs all traffic, <insert date>"
add filter filterlist="Me to Domain DCs all traffic, <insert date>" srcaddr=Me 
dstaddr=<insert domain name> mirrored=yes protocol=any description=
"me<->my DC, 
all traffic"
add rule name="DC client" policy="Domain Member IIS Server Permit/Block 
Lockdown, 
with outbound HTTP:80 Access" filterlist="Me to Domain DCs all traffic, 
<insert date>" filteraction="PERMIT"

popd
pushd ipsec dynamic
delete rule srcaddr=Me dstaddr=DNS protocol=UDP srcport=0 dstport=53
 mirrored=yes 
conntype=all
delete mmpolicy name="N/A"
popd

pushd ipsec static
set store local

add filterlist name="Outbound DNS UDP/TCP" description="Outbound UDP 
and TCP to 
DNS Servers only using dynamic filter for DNS servers based on IP config"
add filter filterlist="Outbound DNS UDP/TCP" srcaddr=Me dstaddr=DNS 
protocol=UDP 
mirrored=yes srcport=0 dstport=53 description="me<->DNS UDP src any, 
dst 53"
add filter filterlist="Outbound DNS UDP/TCP" srcaddr=Me dstaddr=DNS 
protocol=TCP 
mirrored=yes srcport=0 dstport=53 description="me<->DNS TCP src any,
 dst 53"
add rule name="DNS Client" policy="Domain Member IIS Server Permit/Block 
Lockdown, 
with outbound HTTP:80 Access" filterlist="Outbound DNS UDP/TCP" filteraction
="PERMIT"

add filterlist name="Outbound WINS" description="Outbound UDP to WINS Servers 
only 
using dynamic filter for WINS servers based on IP config"
add filter filterlist="Outbound WINS" srcaddr=Me dstaddr=WINS protocol=UDP 
mirrored=yes srcport=137 dstport=137 description="me<->WINS Servers UDP 
src 137, 
dst 137"
add rule name="WINS Client" policy="Domain Member IIS Server Permit/Block 
Lockdown, with outbound HTTP:80 Access" filterlist="Outbound WINS" 
filteraction="PERMIT"

(add filterlist name="Outbound DHCP" description="Outbound DHCP to DHCP 
Servers 
only using dynamic filter for DHCP servers based on IP config"
add filter filterlist="Outbound DHCP" srcaddr=Me dstaddr=DHCP protocol=UDP 
mirrored=yes srcport=68 dstport=67 description="me<->DHCP UDP src 68, dst 67"
add rule name="DHCP Client" policy="Domain Member IIS Server Permit/Block 
Lockdown, with outbound HTTP:80 Access" filterlist="Outbound DHCP" filteraction=
"PERMIT"

add filterlist name="Outbound HTTP:80"
add filter filterlist="Outbound HTTP:80" srcaddr=Me dstaddr=Any protocol=TCP 
mirrored=yes srcport=0 dstport=80 description="me<->Any TCP src any, dst 80"
add rule name="web client" policy="Domain Member IIS Server Permit/Block 
Lockdown, 
with outbound HTTP:80 Access" filterlist="Outbound HTTP:80" filteraction=
"PERMIT"

add filterlist name="Mitigation from inbound src 80 attack"
add filter filterlist="Mitigation from inbound src 80 attack" srcaddr=Any 
dstaddr=Me description="Any->me TCP src 80, dst 135"  protocol=TCP 
mirrored=no srcport=80 dstport=135
add filter filterlist="Mitigation from inbound src 80 attack" srcaddr=Any 
dstaddr=Me description="Any->me TCP src 80, dst 139"  protocol=TCP 
mirrored=no srcport=80 dstport=139
add filter filterlist="Mitigation from inbound src 80 attack" srcaddr=Any 
dstaddr=Me description="Any->me TCP src 80, dst 445"  protocol=TCP 
mirrored=no srcport=80 dstport=445
add filter filterlist="Mitigation from inbound src 80 attack" srcaddr=Any 
dstaddr=Me description="Any->me TCP src 80, dst 1025" protocol=TCP
mirrored=no srcport=80 dstport=1025
add filter filterlist="Mitigation from inbound src 80 attack" srcaddr=Any 
dstaddr=Me description="Any->me TCP src 80, dst 1046" protocol=TCP
mirrored=no srcport=80 dstport=1046
add rule name="mitigate web client" policy="Domain Member IIS Server 
Permit/Block Lockdown, with outbound HTTP:80 Access" filterlist="Mitigation 
from inbound src 80 attack" filteraction="BLOCK"

set policy name="Domain Member IIS Server Permit/Block Lockdown, 
with outbound 
HTTP:80 Access" assign=no

popd

exit

El último paso consistirá en asignar esta directiva a través del complemento Administrador de las directivas de seguridad de IP para MMC. Una vez asignada la directiva, para aplicarla será necesario reiniciar el motor de directivas IPSec. Antes de reiniciar el servidor, asegúrese de que esta directiva se ha habilitado.

Si desea obtener más información, consulte el módulo "Deploying IPSec" del Windows Server 2003 Deployment Kit: Deploying Network Services de la sección "Assigning Domain-based, OU-Level, and Local IPSec Policies".

Negociación de la protección IPSec del tráfico

La integración del protocolo IKE con el filtrado IPSec permite la negociación automática basada en directivas de la protección cifrada IPSec para el tráfico IP de unidifusión que coincida con los filtros IPSec. Los paquetes protegidos mediante IPSec pueden utilizar el formato AH o el formato ESP con las opciones de seguridad determinadas según la configuración de las directivas. La utilización de directivas IPSec para negociar el transporte protegido mediante IPSec de las aplicaciones y los protocolos de capa superior ofrece las ventajas siguientes:

Impacto potencial

El filtrado IPSec es una de las herramientas de consolidación de un servidor frente a los ataques a la red. No debe considerarse la única herramienta ni tampoco una solución completa. El filtrado IPSec no se ha diseñado para sustituir la necesidad de filtros de un enrutador o servidor de seguridad perimetral completo. Sólo se recomienda en los escenarios de filtrado sencillo de paquetes, para consolidar los clientes y servidores en los que el filtrado estático puede resultar eficaz. Asimismo, el filtrado IPSec se ha diseñado para aplicar una directiva basada en directorio a muchos equipos. Por lo tanto, el complemento de administración de directivas IPSec no puede ofrecer información detallada durante el proceso de configuración sobre el modo en que una directiva se aplicará a un equipo específico. A continuación se indican algunas de las limitaciones del filtrado IPSec:

Cuando el filtrado IPSec (u otro dispositivo de red) bloquea el tráfico de red, puede provocar un comportamiento inusual de la aplicación y generar mensajes de sucesos. El filtrado IPSec no proporciona un registro de fácil lectura del tráfico entrante y saliente interrumpido. Las capturas del Monitor de red (Netmon) del tráfico de red no permiten ver el tráfico saliente que está bloqueado. Aunque Netmon permite ver el tráfico entrante bloqueado, en el archivo de captura no se indica que se haya interrumpido un paquete determinado. Por lo tanto, un diagnóstico efectivo dependerá del conocimiento del comportamiento habitual de la aplicación, de los sucesos y de los flujos de tráfico de red cuando no se ha asignado la directiva IPSec.

Asimismo, el diseño correcto de filtros IPSec para el tráfico de la aplicación puede depender del análisis detallado de los flujos de tráfico de red para conocer el modo en que la aplicación utiliza la red. Por ejemplo, el protocolo SMB utiliza el puerto TCP 139 para la transferencia de archivos y para el uso compartido de impresoras y archivos. Si IPSec bloquea este puerto, SMB también puede utilizar el puerto TCP 445. Otro ejemplo es cuando una aplicación requiere múltiples flujos de tráfico de red para diferentes destinos. Generalmente, SMB y otros protocolos autentican al usuario; esto puede provocar que el equipo localice e intercambie el tráfico Kerberos con el controlador de dominio. Kerberos utiliza DNS UDP 53 o TCP 53 para descubrir una lista de direcciones IP de controladores de dominio y, a continuación, LDAP UDP 389 y UPD y el tráfico del puerto TCP 88 para descubrir prácticamente cualquiera de las direcciones IP de controladores de dominio. De este modo, un error de impresión puede deberse en realidad a un paquete bloqueado del controlador de dominio. Algunos protocolos, como RPC, utilizan una amplia gama de puertos TCP, que se determinan de forma dinámica al iniciar un equipo o al ejecutar una aplicación. Por lo tanto, las aplicaciones RPC no se pueden controlar de forma eficaz mediante el filtrado estático en los puertos, excepto cuando la aplicación RPC proporciona una configuración para requerir el uso de un puerto estático.

En Windows 2000 y Windows XP, las exenciones predeterminadas para los filtros especificados en la configuración de directivas se han diseñado para los tipos de tráfico de red IP que no pueden protegerse mediante IKE (paquetes IP de unidifusión y multidifusión), que deben estar exentos de la calidad de servicio (QoS) que se proporciona para el tráfico IPSec (protocolo RSVP), y que deben ser necesarios para que el sistema IPSec funcione (el propio IKE y Kerberos como método de autenticación IKE). Aunque se ha proporcionado una clave de registro para quitarlas, estas exenciones a menudo no se deshabilitan cuando el filtrado IPSec se ha utilizado para escenarios de servidor de seguridad de permiso y bloqueo. Por lo tanto, Windows Server 2003 sólo proporciona una exención para el tráfico IKE. Microsoft recomienda quitar las exenciones predeterminadas de todos los escenarios IPSec que utilicen Windows 2000 y Windows XP. Si desea obtener más información acerca de las exenciones predeterminadas, consulte el artículo de Microsoft Knowledge Base 811832 "Excepciones IPSec Default Se Pueden Utilizar a Protección de Omisión IPsec en Algunos escenarios", disponible en la dirección: http://support.microsoft.com/default.aspx?scid=811832 y el artículo de Microsoft Knowledge Base 810207 "Excepciones IPSec Default Se Quitan en Windows Server 2003", disponible en la dirección: http://support.microsoft.com/default.aspx?scid=810207.

Cuando un equipo con Windows 2000 se conecta a Internet, un filtro de permiso saliente reflejado (como el puerto 80 explicado anteriormente) permite que un atacante tenga acceso desde Internet a cualquier puerto TCP abierto del servidor mediante el puerto de origen. Por lo tanto, un error en la configuración de IPSec puede provocar la pérdida de la seguridad esperada. Las configuraciones deben comprobarse para garantizar que proporcionen la seguridad y la protección esperadas frente a los ataques.

Un compromiso de la seguridad que provoque que un atacante obtenga acceso al sistema local o al administrador local podría permitirle deshabilitar o cambiar la directiva IPSec.

IPSec en Windows 2000 no ofrece filtrado completo durante el inicio del equipo. Hay un breve intervalo de tiempo en el que la pila TCP/IP es sensible. Un ataque automatizado podría tener acceso potencialmente a puertos de la aplicación que, de lo contrario, estarían bloqueados por la directiva IPSec. En la mayoría de los casos, las aplicaciones no pueden iniciar el proceso de las conexiones antes de establecer el filtrado IPSec. Para lograr el máximo nivel de seguridad mediante el filtrado IPSec, desconecte el equipo de la red durante el reinicio.

Windows Server 2003 proporciona una primera directiva de inicio que el controlador de IPSec utiliza cuando TCP/IP lo carga al iniciar el equipo. Cuando se inicia el servicio IPSec, éste aplica inmediatamente la directiva persistente. Si es posible determinar una asignación de directiva local o de dominio, ésta se aplica además de la directiva persistente. Por lo tanto, una secuencia de comandos IPSec NETSH que configure una directiva persistente predeterminada que garantice la seguridad (por ejemplo, el bloqueo de todo el tráfico excepto el tráfico de administración), puede ofrecer protección total durante la transición del inicio a la directiva IPSec local o asignada por el dominio. Dispone de más información en la Ayuda en pantalla de Windows Server 2003 y en el Kit de implementación.

No obstante, Windows 2000 y Windows Server 2003 no están diseñados para permitir la configuración de dependencias de servicio en el inicio del servicio Agente de directivas IPSec. La configuración de una dependencia de servicio no garantiza de forma efectiva que los filtros se establezcan antes de iniciar el servicio dependiente.

Windows Server 2003 proporciona la Conexión de seguridad a Internet (ICF), que realiza el filtrado con estado del tráfico saliente y proporciona controles básicos del acceso entrante a los puertos y los tipos de mensajes ICMP. ICF proporciona también un registro legible de los paquetes bloqueados entrantes y salientes. Sin embargo, ICF no proporciona la configuración centralizada de las reglas de filtro, ni tampoco puede permitir ni bloquear el tráfico en función de la dirección IP de origen. Los administradores deberán investigar las capacidades de ICF para determinar si satisfacen sus necesidades de filtrado del tráfico. El filtrado con estado proporcionado por ICF se puede utilizar en combinación con el filtrado IPSec para ofrecer protección cuando IPSec deba configurarse para utilizar filtros salientes reflejados que permitan el tráfico. En la medida de lo posible, debe utilizarse el filtrado de servidor de seguridad o enrutador de cliente como primera línea de defensa.

Merece la pena considerar el uso de un sistema de detección de intrusos basado en host y otros sistemas antivirus para detectar y protegerse potencialmente frente a la infección y los ataques en las aplicaciones y el tráfico de red permitido. Un servidor de seguridad de extremo o basado en host de terceros puede proporcionar la mejor solución para las necesidades de filtrado complejas.

Negociación de la protección IPSec del tráfico

Aunque la protección IPSec total puede mejorar considerablemente la seguridad, tenga en cuenta que la implementación de comunicaciones protegidas mediante IPSec en su red requiere más costes administrativos y de aprendizaje. Puede implicar costes adicionales de hardware si es necesario adquirir el hardware IPSec o adaptadores de red de descarga o bien aumentar la capacidad de la CPU. Por lo tanto, antes de implementar IPSec para un determinado escenario, considere y analice detenidamente las posibles amenazas de seguridad que IPSec pretende corregir, los requisitos de seguridad, los costes de la implementación de IPSec frente al coste de no utilizarlo y, por lo tanto, los beneficios empresariales esperados.

La implementación de IPSec con AH implica un aumento de la carga para administrar una configuración IPSec cliente/servidor, así como la administración de un método de confianza mutua entre los equipos cliente/servidor. Si ambos equipos están siempre en el mismo dominio o en dominios de confianza mutua, la directiva de grupo puede ofrecer la configuración necesaria de la directiva IPSec, y la autenticación Kerberos puede establecer confianza para las asociaciones de seguridad de IPSec. Si los equipos no pueden utilizar Kerberos, se pueden emplear certificados de equipo o una clave de autenticación previamente compartida. Sin embargo, en esta guía no se recomienda utilizar claves de autenticación previamente compartidas, ya que el valor de la clave se almacena sin protección en la configuración de la directiva IPSec.

Aunque únicamente pueden leer la directiva IPSec local los administradores que la han definido, la directiva almacenada en Active Directory deberá ser accesible a todos los equipos del dominio. Por lo tanto, resulta difícil mantener la privacidad del valor de la clave previamente compartida. Microsoft recomienda utilizar certificados digitales cuando no sea posible utilizar Kerberos para la autenticación IKE. La directiva IPSec debe designarse para proteger todo el tráfico o para negociar IPSec sólo en puertos TCP o UDP específicos. La directiva IPSec del cliente generalmente se debe configurar con la dirección IP estática del servidor. La necesidad de IPSec en el servidor denegará el acceso a los equipos cliente que no dispongan de una configuración de directiva IPSec compatible y un método de confianza mutua.

Si desea obtener más información acerca de la implementación de Windows IPSec, consulte el sitio Web de Windows 2000 en la dirección http://www.microsoft.com/windows2000/technologies/communications/ipsec/default.asp.

(Este artículo contiene referencias a guías de otros productos y vínculos a sitios Web que sólo están disponibles en inglés.)

Principio de la página

11 de 12