Seguridad

Administración del firewall de Windows Vista

Jesper M. Johansson

De un vistazo:

• Tipos de reglas y escenarios
• Perfiles del firewall
• Reglas de aislamiento de dominios
• El problema con el filtrado de salida

Hace poco escribí un artículo en mi blog acerca del firewall de Windows Vista. En él se destacaban simplemente algunas de las características más beneficiosas, si bien no ofrecía demasiados consejos de implementación.

En este artículo, sin embargo, me detendré en algunas de las características del firewall de Windows Vista® diseñadas específicamente para facilitar la administración empresarial. También ofreceré consejos acerca de cómo puede usarlas para facilitar su trabajo y asegurarse de que sus usuarios estén más protegidos.

Con el reciente lanzamiento del SP1 para Windows Vista, es posible que tenga previsto iniciar la implementación de Windows Vista en la empresa. Es habitual entre las empresas esperar el lanzamiento del primer Service Pack antes de migrar a un sistema operativo nuevo. Si usted es uno de los profesionales de TI que están considerando ahora más seriamente implementar Windows Vista en su entorno empresarial, le recomiendo que observe el firewall con detenimiento. Cuando se dé cuenta de lo que puede hacer el firewall de Windows Vista, deseará seguramente renegociar el acuerdo vigente de su paquete de seguridad de terceros para eliminar el firewall del paquete.

Los firewall de Windows antes y ahora

El firewall incluido en el lanzamiento original de Windows® XP dejaba mucho que desear. Si bien se ajustaba adecuadamente a las funciones de seguridad de los firewall comerciales basados en host de aquel momento, no incorporaba ninguna novedad.

Su sustituto de Windows XP SP2, no obstante, cambiaba completamente el panorama. Fue diseñado específicamente para facilitar la administración de la empresa. El firewall de Windows XP SP2 tiene como principales atractivos su ligereza, capacidad de administración centralizada, efectividad y discreción. Pero, quizás lo más importante: el firewall de Windows XP SP2 protege el sistema durante el arranque.

Este último punto es crucial. He visto cómo muchos sistemas en el pasado quedaban infectados durante el arranque incluso con el firewall activado. De hecho, durante el punto álgido de la epidemia del virus Blaster, el índice de ataques era de hasta uno cada cuatro minutos. En otras palabras, si dejó un equipo desprotegido conectado a Internet, éste se podría haber infectado, de media, en cuatro minutos. Y si confiaba en un firewall que no protegía el sistema durante el arranque, un sistema de cada doce se habría infectado al volver a arrancar. Estas cifras fueron las que llevaron a Microsoft a asegurarse de que el firewall de Windows XP SP2 protegiera el sistema durante el arranque.

Con Windows Vista, el firewall vuelve a transformarse por completo. El cambio más obvio, desde el punto de vista de la administración, es la fusión de las interfaces de administración del protocolo de seguridad de Internet (IPsec) y del firewall. Se trata de un cambio muy lógico. IPsec y el firewall tienen ambos como misión bloquear el acceso de elementos no permitidos. La diferencia es que en el firewall, los parámetros que definen lo que se permite no son muy detallados, mientras que el bloqueo o admisión de grandes volúmenes del espacio de direcciones en IPsec resulta complicado.

Con estas dos características ubicadas en una misma interfaz de administración, los administradores pueden usar ambas tecnologías sin problemas, sin preocuparse demasiado por si algo requiere una regla de IPsec o si debe aplicarse en su lugar un filtro de firewall. Básicamente, dispone de una única vista de la superficie de ataque de la red del sistema, lo que contribuye a minimizar el riesgo de cometer errores.

El SP1 para Windows Vista incorpora algunas mejoras de confiabilidad a las características del firewall. También incluye algoritmos nuevos, en particular los algoritmos de la Suite B, para su uso en IPsec. Se trata de un conjunto de algoritmos relacionados con el cifrado, y que incluyen Advanced Encryption System (AES), la criptografía de curva elíptica (ECC) y el algoritmo hash seguro (SHA) 256 y 384.

Lo más importante, sin embargo, es que el Service Pack 1 incluye compatibilidad con la Protección de acceso a redes (NAP). NAP es una herramienta de cumplimiento de directivas que garantiza que los clientes administrados y que no se hayan puesto en peligro se actualicen con las últimas directivas de seguridad, actualizaciones y definiciones de antimalware antes de que puedan conectarse a la red. NAP no puede detener los intentos de conexión a la red por parte de host malintencionados, pero sí se asegura de que todos los host administrados sean completamente compatibles mientras no sean puestos en peligro de manera activa.

El firewall de Windows Vista, llamado Firewall de Windows con seguridad avanzada, también se incluye en Windows Server® 2008. Todas las características pueden administrarse también de forma remota y configurarse a través de una red que use directivas de grupo.

Tipos de reglas y escenarios

La funcionalidad del firewall combinada con la de IPsec en la interfaz de administración significa que ahora tenemos dos tipos diferentes de reglas: reglas direccionales y de conexión. Las reglas direccionales son reglas estándar de firewall que definen qué tráfico se permitirá en la dirección apropiada. Las reglas de conexión, por su parte, definen los parámetros de protección para las conexiones entre equipos. A modo de comparación, las reglas direccionales son parecidas a las reglas conocidas de firewall anteriores, mientras que las reglas de conexión son más similares a las usadas en IPsec con el firewall en Windows XP SP2.

Al combinar el firewall e IPsec en una misma interfaz, se nos presentan una serie de situaciones muy interesantes. Por ejemplo, el aislamiento mutuo de sistemas en la red es uno de los conceptos de seguridad actuales más valiosos. Microsoft lo denomina "aislamiento de servidor y dominio".

El aislamiento de servidor y dominio usa tanto la funcionalidad de IPsec como la del firewall. Sabiendo esto, cabe decir que la nueva interfaz de administración del firewall incluye funcionalidad específica para las reglas de aislamiento. Éstas resultan apropiadas si, por ejemplo, desea restringir la conexión basándose en los atributos de los sistemas de origen o de destino, como por ejemplo la pertenencia al dominio.

Como se puede apreciar en la figura 1, el Asistente para nueva regla de seguridad de conexión empieza preguntando qué tipo de regla desea crear. Si selecciona Aislamiento, el asistente preconfigurará los parámetros que corresponden a una regla de aislamiento.

Figura 1** Uso del Asistente para nueva regla de seguridad de conexión para crear una regla de aislamiento **(Hacer clic en la imagen para ampliarla)

Advertirá también en la figura 1 que la regla de aislamiento menciona el estado de mantenimiento. Las reglas empleadas para el aislamiento de servidor y dominio son en realidad las mismas que para NAP.

No es posible aplicar la autenticación a determinados tipos de tráfico. Por ejemplo, seguramente no requerirá autenticación para la resolución DNS. Para los extremos de ese tipo de tráfico, necesitará por tanto una regla de exención de autenticación. Una regla de exención de autenticación hace exactamente eso: exime el tráfico de los requisitos de IPsec.

Una regla de servidor a servidor, en cambio, es un poco un nombre equivocado. Si bien se usa con mayor frecuencia en servidores, también se puede usar en clientes. Una regla de servidor a servidor configura simplemente una conexión para que requiera autenticación. La diferencia con una regla de aislamiento es que esta última no sólo requiere autenticación, sino también el cumplimiento de una serie de criterios adicionales, como la pertenencia al dominio o el estado de mantenimiento.

Una regla de túnel define básicamente una red privada virtual (VPN) de sitio a sitio y el túnel ubicado entre las puertas de enlace. Las reglas de túnel prácticamente no se usan en Windows Vista, ya que es poco probable que vaya a usar este sistema en una instalación de puerta de enlace. Es posible crear reglas totalmente personalizadas para que pueda personalizar cada uno de los parámetros de una regla.

Orden de reglas

El orden de reglas puede parecer complicado a primera vista. La clave para entender el orden de reglas consiste en olvidarse primero del orden. La razón es que no se trata tanto de ordenar, sino más bien de selecciones coincidentes. Tomemos como ejemplo el tráfico entrante. El tráfico entrante que no coincide con ninguna regla que lo permita queda bloqueado de forma predeterminada. Esto se podría considerar con un orden que dijera "Considerar primero las reglas de admisión", aunque se trataría de una suposición incorrecta. Si un paquete específico coincide con una regla de admisión y otra de bloqueo, se impondrá la de bloqueo. Esto significa que, en otras palabras, la coincidencia es:

1. reglas de bloqueo. Si un paquete o conexión coincide con una de ellas, se descartará.
2. Reglas de admisión. Si un paquete o conexión coincide con una de ellas, se permitirá.
3. Comportamiento de perfil direccional predeterminado. Si no coincide ninguna regla de bloqueo ni de admisión, el tráfico se tratará según el comportamiento especificado como predeterminado para el tráfico en esa dirección y en ese perfil. En la dirección entrante para cualquier perfil, significa bloquear el tráfico en una configuración predeterminada. En la dirección saliente significa permitir el tráfico en la configuración predeterminada.

El proceso de coincidencia lo controlan las reglas de omisión autenticada (IPsec). Mediante este tipo de regla, se permite todo tráfico autenticado que coincide con los parámetros restantes de la regla, independientemente de si coincide o no con cualquier otra regla. Las reglas de omisión autenticada son reglas direccionales con la opción de invalidar reglas de bloqueo seleccionada, tal como se muestra en la figura 2. Éstas se tendrán en cuenta en primer lugar con el fin de permitir que el tráfico autenticado llegue siempre al sistema. Este aspecto resulta fundamental para poder permitir el tráfico procedente de host autenticados y bloquear el que no proceda de éstos. Podemos considerar esta regla como la número 0 en el orden. Así, la lista completa de orden de reglas quedaría del siguiente modo:

Figura 2** Activación de la opción de invalidar reglas de bloqueo para configurar una regla de omisión autenticada **(Hacer clic en la imagen para ampliarla)

0. Reglas de omisión autenticada

1. Reglas de bloqueo

2. Reglas de admisión

3. Comportamiento de perfil direccional predeterminado

En realidad, no importa si hay varias reglas en cada clase que coincidan con el patrón de tráfico. En el momento en que coincida una regla con éste, se detendrá el procesamiento de la regla.

Público, privado y en el dominio

Recursos de red

• Centro de seguridad de TechNet
• Uso de la herramienta de línea de comandos Netsh Advfirewall
• Reglas de seguridad para el firewall de Windows y conexiones basadas en IPsec en Windows Vista y Windows Server 2008
• Vigilancia de seguridad con SCW en Windows Server 2008

El nuevo firewall cuenta con tres perfiles: público, privado y dominio. El firewall de Windows XP SP2, por su parte, presentaba dos perfiles de red: estándar y dominio. El perfil de dominio se invoca automáticamente cuando el equipo encuentra el controlador de dominio. En Windows XP, el perfil estándar se usaba de otro modo. Ofrecía funciones eficaces para que el administrador de seguridad pudiera bloquear completamente el equipo cuando se encontraba en movimiento y al mismo tiempo permitir todas las funciones de administración remota necesarias al trabajar en la red de la organización. Sin embargo, este método presentaba ciertos problemas para algunos usuarios, en particular, los que contaban con redes personales domésticas. Dado que siempre se usaba el perfil estándar si el sistema no podía llegar al controlador de dominio, el sistema quedaba bloqueado desde el hogar del usuario.

El nuevo perfil privado que incluye Windows Vista contribuye a resolver este problema. Ahora, cuando conecte el sistema a una red nueva, se le preguntará si esa red es pública (este es simplemente el nuevo nombre para el perfil estándar anterior) o privada y configurará el sistema en correspondencia. El sistema recuerda esta circunstancia cada vez que se conecta a esa red concreta, en función de los parámetros de red que presenten los servidores de infraestructura de la red. Este método no es en absoluto infalible, pero resulta de gran ayuda, ya que permite el bloqueo óptimo de un mayor número de redes.

También ha mejorado la lógica de detección para averiguar si el sistema se encuentra en el dominio. El resultado es una transición más rápida y confiable y, en consecuencia, menos sistemas que piensan que deben usar el perfil público o privado cuando en realidad se encuentran en el dominio.

Puede asignar sus reglas a un tipo determinado de red para evitar así que el sistema ofrezca demasiada información y trate de conectarse a sistemas de redes que no son de confianza. Es en esta área donde se ve que ha valido la pena la integración del firewall con IPsec.

Estas nuevas reglas le permiten aplicar restricciones que no eran posibles anteriormente. Por ejemplo, durante muchos años los atacantes han intentado emitir ataques para lograr que los usuarios establezcan conexiones de bloque de mensajes del servidor (SMB) (para conexiones de redes Windows) a host que no son de confianza, forzando así que una secuencia de autenticación les ofrezca un par desafío/respuesta que puedan usar para averiguar contraseñas. Las versiones más antiguas de este ataque también se usaban para convertir la autenticación a texto no cifrado o devolver el par de desafío/respuesta del usuario al equipo que la originaba. La primera de estas técnicas fue anulada hace años. La segunda fue mitigada con Windows XP SP2, aunque hay que tener presente que ofrecer pares de desafío/respuesta es una práctica no obstante imprudente.

Para evitarlo, puede usar otra nueva función del firewall de Windows Vista, el filtrado de salida. Un administrador podría decidir, por ejemplo, bloquear todas las conexiones SMB de salida que terminen en los puertos TCP 135, 139 y 445 y UDP 137, 138 y 445 en el perfil público. Esto dificultaría el uso de un sistema en un ataque con engaño para obtener pares de desafío/respuesta o bien evitaría que dicho sistema tuviera acceso a recursos compartidos de archivos de Windows en Internet que no fueran de confianza.

De nuevo, esta característica no es infalible. Por ejemplo, si el sistema ya se ha puesto en peligro, esta regla no impediría que el sistema se comunicara con el exterior, ya que el atacante podría simplemente deshabilitar la regla. Sin embargo, puede resultar muy útil como medida para proteger sistemas que se comporten correctamente pero que puedan quedar expuestos.

Es importante mencionar en este sentido que, al igual que ocurre en Windows XP SP2, sólo un perfil puede estar activo a la vez en Windows Vista y Windows Server 2008. Si hay dos interfaces de red activas en el sistema y una de ellas se encuentra en el dominio mientras que la otra reside en una red pública, el perfil de firewall público se aplicará a ambas interfaces. Siempre se usará el perfil más restrictivo. Como quizás ya habrá adivinado, el perfil público es más restrictivo que el privado, y este último más restrictivo que el perfil de dominio. Así pues, tenga presente que la regla de bloqueo SMB de salida puede interrumpir mucho tráfico a través de conexiones VPN.

Para habilitar el tráfico a través de una conexión VPN cuando el equipo se encuentra en una red pública o privada, cree reglas direccionales que se apliquen únicamente a interfaces de VPN. Para que funcionen, Windows debe reconocer las interfaces de VPN como tales. Si no usa el servidor VPN Servicios de enrutamiento y acceso remoto de Microsoft®, pruebe esta funcionalidad antes de implementarla de forma masiva. Se trata principalmente de un problema con el tráfico entrante al cliente y las reglas de salida personalizadas que vaya a crear.

Creación de reglas de firewall

El nuevo firewall facilita enormemente el proceso de creación de reglas de firewall. El Asistente para regla nueva, que se muestra en la figura 3, permite definir todos los tipos habituales de reglas. Asimismo, incluye reglas predefinidas para servicios concretos.

Figura 3** Reglas predefinidas en el Asistente para regla nueva **(Hacer clic en la imagen para ampliarla)

Las reglas predefinidas son especialmente importantes. El aislamiento del servidor consiste básicamente en restringir servicios de manera que sólo estén disponibles para aquellos sistemas que necesitan usarlos. En productos de servidor, puede usar el Asistente para configuración de seguridad de Windows (SCW) para realizar esta tarea de forma más sencilla, aunque no sin alguna que otra dificultad. (En el número de marzo de 2008 de TechNet Magazine traté SCW).

Sin embargo, las versiones de cliente de Windows no disponían de una funcionalidad semejante hasta la fecha. Si usa el tipo de regla predefinida, se ahorrará gran parte del trabajo, es decir, la tarea de determinar qué extremos usará un servicio. El firewall no sólo es sensible a las aplicaciones, es decir, sabe qué programa representa el "Servicio de iSCSI", sino que también incluye reglas predefinidas que describen determinadas funciones. Esto le permite centrarse en los equipos a los que debe aplicarse una regla. Sigue siendo una tarea difícil y laboriosa, pero por lo menos sólo deberá realizarse una vez para todo el entorno.

Existe también una regla personalizada, oculta por el desplegable de la figura 3, que le aporta la flexibilidad que puede esperar de un firewall de autenticación. Por ejemplo, si desea una regla que sólo permita tráfico cifrado de IPsec, seleccionará la opción para admitir únicamente conexiones seguras en la página Acción del asistente, que se muestra en la figura 2.

Cuando la seleccione, también tendrá la opción de activar el cifrado. Si deja esta opción en blanco, sin embargo, el tráfico usará ESP-NULL, es decir, carga de seguridad encapsulada con una clave NULL. Ésta es la manera recomendada de usar IPsec para la autenticación. Permite a la mayoría de las herramientas de administración de la red seguir funcionando, ya que el tráfico atraviesa la red sin cifrado y, en el caso de que desee cifrado, basta con activar la casilla correspondiente.

En muchos casos, el cifrado del tráfico de red no es ni de lejos tan importante como el hecho de no aceptar tráfico procedente de host malintencionados. El cifrado del tráfico en la red impide a los usuarios malintencionados que hayan obtenido acceso a la propia red comprobar el contenido del paquete en cuestión. Requerir autenticación podría impedirle a usted enviar el paquete, además de impedir que sea atacado. Si bien es cierto que hay muchos casos en los que el cifrado a nivel de red es importante, también es verdad que en muchos otros sólo necesita autenticación.

Creación de reglas de aislamiento de dominio

En la mayoría de los entornos, desea que un número limitado de equipos puedan enviar el tráfico a una estación de trabajo. Como mínimo, todas estaciones de trabajo deberán configurarse con reglas de aislamiento de dominio. Esto resultaba complicado en Windows XP, pero ahora es fácil con Windows Vista.

Primero, abra la herramienta de administración de su elección y seleccione el nodo Reglas de seguridad de conexión. A continuación, haga clic con el botón secundario en el nodo y seleccione Nueva regla para que aparezca el cuadro de diálogo que se muestra en la figura 1. Seleccione Regla de aislamiento y haga clic en Siguiente. A continuación deberá elegir si desea que se cumpla la regla o no. En la mayoría de los casos relacionados con estaciones de trabajo, deseará que se requiera autenticación para el tráfico entrante. De este modo evitará que cualquier equipo que no se haya incorporado al dominio envíe tráfico a la estación de trabajo. Sin embargo, para solicitar servicios de servicios de infraestructura, el sistema debe permitir el paso de parte del tráfico no cifrado. La mejor opción, por lo tanto, es la de exigir autenticación para las conexiones entrantes y solicitar autenticación para las conexiones de salida.

A continuación, escoja el método de autenticación. La selección predeterminada recibe el nombre no especialmente útil de Predeterminado. Puede configurar el método de autenticación predeterminado para cada equipo en las propiedades de IPsec, a las que obtendrá acceso si hace clic con el botón secundario en el nodo de Firewall de Windows con seguridad avanzada y selecciona Propiedades. El método de autenticación predeterminado es siempre Kerberos, ya que se trata del más sencillo y seguro. Sin embargo, para no complicarlo todo, recomiendo seleccionarlo en el momento de crear las reglas. Por lo general, desea sólo autenticar el equipo, no el usuario también. Si usted necesita autenticar ambos, es posible que no pueda aceptar determinadas clases de tráfico de administración, como el tráfico SNMP que se transmite anónimamente.

Una vez que haya seleccionado el método de autenticación, tan sólo le queda seleccionar los perfiles en los que desea que esté disponible la regla. Dado que se trata de una regla que se aplica a equipos incorporados al dominio, los cuales pueden presentar un vale Kerberos, no tiene sentido abrir este orificio concreto en los perfiles privado o público. Para finalizar, guarde la regla.

Las reglas básicas de aislamiento han dejado de ser complicadas. Sin embargo, para beneficiarse de la eficacia de IPsec con el aislamiento, necesita implementar el aislamiento de servidor incluso en las estaciones de trabajo. Al hacerlo, puede impedir que las estaciones de trabajo escuchen a otros clientes. En su lugar, sólo responderán a las estaciones de administración apropiadas. Imagínese cómo se habría reducido el impacto de diversos ataques de malware si los clientes se hubieran negado a escuchar a otros clientes.

Scripting del firewall

El nuevo firewall incluye una API completa que permite elaborar los scripts tanto de implementación como de evaluación. Lo ideal sería que usara la Directiva de grupo para la implementación, pero dado que ésta no siempre está disponible, es importante disponer de un conjunto de API apropiado para configurar el firewall. Las API se agrupan bajo el conjunto INetFWPolicy2 de API. Si bien el kit de desarrollo de software y MSDN® Library contienen información más detallada acerca de su uso, usaremos unos ejemplos que nos ayudarán a ilustrar la situación.

Un ejemplo común es la necesidad de determinar si un grupo de reglas está activado o no. Supongamos, por ejemplo, que una aplicación o un administrador necesitan determinar si un sistema concreto permite el uso compartido de archivos e impresoras. Esto puede comprobarse mediante INetFWPolicy2::IsRuleGroupCurrentlyEnabled. La figura 4 incluye un ejemplo de VBScript que demuestra esta función.

Figure 4 Uso de INetFWPolicy2::IsRuleGroupCurrentlyEnabled

' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if

Ahora bien, si el uso compartido de archivos e impresoras está desactivado y necesita activarlo, primero deberá asegurarse de que esto es posible y que no quedará invalidado por la Directiva de grupo. Para ello, use la API INetFWPolicy2::LocalPolicyModifyState. A continuación se muestra un esquema, que puede llenarse con código real:

Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Tipos de interfaz y línea de comandos

Ningún firewall sería completo sin una línea de comandos apropiada para la administración. Hay un subcontexto en netsh denominado advfirewall. El contexto advfirewall proporciona acceso de línea de comandos a todas las funciones que pueden realizarse en la IU gráfica. Por ejemplo, si desea implementar el bloqueo de salida en el puerto 445, puede ejecutar el siguiente comando desde un símbolo del sistema elevado:

netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any

A continuación deberá ejecutar el mismo comando, reemplazando TCP con UDP para completar el bloqueo. En ese momento habrá completado la implementación de la regla.

Una característica interesante del firewall es la capacidad para configurar reglas en función del tipo de interfaz de red. Recuerde que algunas reglas pueden afectar a las conexiones VPN. Mientras Windows reconozca la interfaz como de VPN, puede usar este tipo de regla para eximir el tráfico a través de esa interfaz:

netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS

Esto también puede llevarse a cabo en la GUI, si bien primero deberá haber creado la regla. A continuación, haga clic con el botón secundario en la regla, seleccione Propiedades y haga clic en la ficha Avanzadas. Aparecerá una sección de tipos de interfaz en la que podrá seleccionar los tipos apropiados.

Filtrado de salida

La falta de filtrado de salida en el firewall de Windows XP SP2 fue considerada la prueba principal de que el firewall integrado resultaba inadecuado para la seguridad. Debe haber miles de artículos escritos acerca del grado de inseguridad del firewall de Windows XP SP2 debido a la falta de filtrado de salida. Esto es así a pesar del hecho de que ningún firewall en Windows XP pueda ofrecer filtrado de salida seguro.

La funcionalidad fundamental que transforma el filtrado de salida de un mero instrumento de desaceleración (o herramienta de aplicación de políticas, como mencioné anteriormente) en una característica de seguridad útil simplemente no existe en Windows XP. Sí existe, sin embargo, en Windows Vista. Es lógico, por tanto, que el nuevo firewall haga uso de esta característica. De forma predeterminada, se bloquea la mayor parte del tráfico entrante y se permite la mayor parte del de salida.

El filtrado de salida en el nuevo firewall de Windows Vista sólo bloquea de forma predeterminada el tráfico innecesario procedente de los servicios. En realidad, esto es realmente todo lo que se puede hacer para ofrecer protección contra un posible peligro en el host que proporciona los filtros de salida, y hacerlo en Windows XP no habría tenido ningún sentido.

Los servicios en Windows Vista pueden ejecutarse con un token sumamente restringido. Básicamente, cada servicio posee su propio identificador de seguridad (SID), que es exclusivo de ese servicio. El SID del servicio puede usarse para restringir el acceso a recursos, como puertos de red. Se trata de la misma funcionalidad que vimos anteriormente al estudiar la restricción del tráfico para los usuarios. Esto significa que aunque dos servicios puedan ejecutarse como NetworkService, no pueden administrarse los procesos mutuamente; así, el firewall puede configurarse para permitir sólo uno de ellos para la comunicación exterior. Si se pone en peligro el servicio bloqueado, no podrá apropiarse del servicio permitido ni usar su puerto permitido para comunicarse con el exterior, ya que el puerto estará restringido por el SID del servicio.

Esta funcionalidad es otra de las interesantes características de seguridad que incorpora Windows Vista y que emplea el nuevo firewall para ofrecer seguridad verdadera mediante el filtrado del firewall de salida.

De hecho, el filtrado de firewall en los SID de servicios está habilitado de forma predeterminada en el nuevo firewall. Sin embargo, no existe ninguna GUI para configurarlo. Las reglas se encuentran predefinidas en la clave de registro HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices. Deberá extremar las precauciones, no obstante, al modificar esa clave manualmente, ya que se trata de una acción no admitida.

¿Qué nivel de seguridad ofrece el filtrado de salida?

Un punto que se presta a malentendidos en el ámbito de la seguridad es el nivel de seguridad que ofrece realmente el filtrado de salida. Si bien he mencionado dos escenarios hasta ahora que ofrecen seguridad a través de filtrado de salida, ambos dependen de una nueva funcionalidad de Windows Vista que no estaba disponible anteriormente. A pesar de ello, la idea general es que el filtrado de salida es una característica positiva y debe constituir un factor clave a la hora de decidir qué firewall adquirir.

Lo irónico es que, en muchas organizaciones, las capacidades de filtrado de salida eran las que decidían la compra pero, una vez implementado el firewall, dichas capacidades no se empleaban. Se trata de un tema absurdo y que provoca una pérdida de dinero y esfuerzo por parte del grupo de seguridad de la información. Esta actitud parece impulsada más por un deseo de sentirse bien al hacer algo relacionado con la seguridad que por el análisis que se realice de una amenaza verdadera. El deseo de aparentar en relación con la seguridad es con demasiada frecuencia el responsable de la toma de decisiones que deberían en cambio tomarse en función de los hechos.

Existe un dato muy sencillo acerca del filtrado de salida que sus defensores no suelen tener en cuenta. El argumento habitual de los proveedores de firewall basados en host es que si un sistema se pone en peligro, ya sea por un gusano o por un usuario malintencionado interactivo, el filtrado de salida impedirá que el gusano infecte a otros sistemas o que el atacante se comunique con el exterior. Esto no es verdad.

Lo que sí es cierto es que, en igualdad de condiciones, el filtrado de salida habría sido capaz de detener parte del malware histórico. Sin embargo, si Windows XP hubiera incluido filtrado de salida, lo más seguro es que los gusanos que conocemos se habrían diseñado para desactivar dicho filtrado o bien esquivarlo de algún modo.

En Windows XP y versiones anteriores de Windows, cualquier gusano que se ejecuta como un servicio (y todos los gusanos que me vienen a la mente se ejecutaban efectivamente como servicios) podría haberlo hecho. La única razón por la que no lo hicieron es que no había prácticamente entornos que usaran filtrado de salida y por lo tanto no era necesario deshabilitarlo. En un ataque interactivo, el atacante puede esquivar los filtros de salida a su voluntad. Si el atacante tiene la capacidad de ejecutar código arbitrario, es tarea fácil. Pero si es necesario, el atacante también puede engañar al usuario para que esquive los filtros.

Los filtros de salida de firewall basados en host pueden esquivarse de varias maneras, en función del escenario del ataque en cuestión. La manera más sencilla de llevarlo a cabo es pedir a un usuario que posea mayores privilegios que lo haga por usted. Demasiados entornos siguen ejecutando a sus usuarios como administradores. Esos usuarios tienen el derecho de esquivar directivas de seguridad si lo desean. Lo único que debe hacer el atacante es ofrecerle al usuario la elección entre una serie de ventajas de seguridad intangibles y no inmediatas y algo verdaderamente atractivo: pongamos por ejemplo unos alegres cerditos bailando.

En muchos casos, el usuario recibe tantos cuadros de diálogo de este tipo que acaba por hacer clic rápidamente en uno de ellos sin saber realmente de qué se trata. Éste es el problema número uno del filtrado de salida. Si se ofrece la elección entre la seguridad y unos premios lo suficientemente tentadores, como es el caso de los cerditos, éstos resultarán elegidos siempre, ya que la inmensa mayoría de los cuadros de diálogo que solicita a los usuarios que tomen decisiones acerca de seguridad están desprovistos de cualquier información que les permita tomar realmente una decisión.

Presentar cuadros de diálogo que soliciten la toma de decisiones de seguridad y que incluyan información suficiente en la que basar dichas decisiones es mucho más difícil de lo que parece, ya que requeriría que el producto de seguridad, como por ejemplo el firewall, conociera no sólo los puertos, protocolos y la aplicación que realiza la solicitud, sino también que supiera qué trata de hacer realmente la solicitud y lo que ello significa para el usuario. Esta información es muy difícil de obtener mediante programación. Por ejemplo, el hecho de que Microsoft Word intente establecer una conexión de salida no es ni de lejos tan importante como saber exactamente qué trata de hacer Word con esa conexión.

Necesitamos reducir el número de cuadros de diálogo sin sentido, no aumentarlos, y los firewall con filtrado de salida no contribuyen a esta causa. Para captar una impresión de las técnicas más recientes para proporcionar a los usuarios información valiosa y de utilidad, decidí consultar la documentación de ventas de uno de los principales proveedores de firewall basados en host. Los folletos promocionan capacidad de filtrado de salida del firewall así como la de asesoramiento. Esta última detecta lo que el usuario trata de hacer y ofrece el asesoramiento apropiado. O al menos en teoría. El texto del folleto iba acompañado de una captura de pantalla con el texto: "Todavía no hay asesoramiento disponible para este programa. Elija una de las opciones siguientes o haga clic en Más información para recibir ayuda." Por lo que parece, los proveedores no son capaces de producir cuadros de diálogo informativos ni siquiera en el material de marketing.

Dado que los usuarios no poseen información suficiente para tomar las decisiones correctas acerca de seguridad, lo que le correspondería al administrador es configurar todo el filtrado de salida, ya que el usuario final no es capaz de ello. Esto aumenta infinitamente la carga administrativa del administrador.

Aunque el usuario haga clic en "No. Recordarme más tarde" cuando el firewall emita una consulta, el malware por lo general puede seguir esquivando el firewall. Siempre que el usuario para el que se ejecuta el código malintencionado pueda abrir conexiones de salida en algún puerto, el código pernicioso usará simplemente ese puerto. Así, un proceso existente puede conllevar cualquier otro proceso. Y esto se permite en sistemas operativos de nivel inferior. Para empezar, en Windows Vista, los procesos pueden restringirse convenientemente, motivo por el cual los servicios, restringidos de manera predeterminada, aparecen bloqueados de forma predeterminada mediante filtros de salida.

Lamentablemente, la mayoría de los usuarios piensan que el filtrado de salida de firewall basados en host evitará que un activo puesto en peligro ataque a otros activos. Eso no es posible. Asumir medidas protectoras en un activo en peligro y pedirle que no ponga en peligro otros activos simplemente no funciona. La protección reside en el activo que trata de proteger, no en el que representa una amenaza. Pedir a los ladrones que no roben nada después de que hayan entrado en su casa no parece que vaya a resultar tan efectivo como evitar que de hecho entren en su casa.

Jesper M. Johanssones un arquitecto de software que trabaja en el campo del software de seguridad y es editor colaborador de TechNet Magazine. Posee un doctorado en sistemas de información de administración, más de 20 años de experiencia en el ámbito de la seguridad y es un MVP de Microsoft en seguridad empresarial. Su último libro es Windows Server 2008 Security Resource Kit.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.