SOBRE EL FIREWALL DE XP

SOBRE EL FIREWALL DE XP - SP2
-----------------------------
Este artículo está basado en la traducción de documentos de MS sobre la implementación de dicho firewall. Aunque todavía, dichos documentos corresponden a la fase beta del SP2, esta está lo suficientemente avanzada, así como su documentación, como para poder presuponer que son la implementación final del firewall.

ACTIVADO POR DEFECTO
--------------------
El firewall (ICF) se activará por defecto en todas las interfaces de red. Igualmente se activará posteriormente en cada nueva interface de red añadida al sistema. ICF actuará tanto en IPv4 como en la nueva IPv6 (que se instala, por ejemplo al instalar el Advancing Networking Pack).

CAMBIOS IMPORTANTES
Anteriormente al SP2 de XP, Windows XP tenía ICF desactivado por defecto. El usuario necesitaba realizar la conexión a través de los asistentes para que este se activase, o bien tener los conocimientos sobre las propiedades de las pestañas de conexión de red para activarlo. Debido a ello, existen máquinas en la red con el firewall desactivado.

Haciendo que el ICF quede activado por defecto, los PC's quedan protegidos contra ataques basados en la red. Por ejemplo, si ICF hubiese estado activado, el reciente ataque del MSBlaster hubiese sido reducido.

SEGURIDAD EN TIEMPO DE BOOT
---------------------------
En la actualidad (previo al SP2), existe un intervalo de tiempo entre que el stack de la red ha arrancado y cualquier servicio de firewall -incluido el ICF- da protección a la red. Esto es debido a que los drivers de los firewall no pueden arrancar el filtro hasta que el servicio de firewall esté arrancado y se apliquen sus reglas. Los servicios de firewall tienen dependencias establecidas (por ejemplo dependen de los servicios de red y que la pila tcp esté totalmente arrancada). Aunque este período de tiempo es pequeño y depende de la velocidad de la máquina, durante ese breve lapso de tiempo una máquina está desprotegida.

En el SP2 de XP con su nuevo ICF, el driver de firewall tiene una regla estática especifica de protección Esta regla se denomina "boot-time policy", la cual permite a la máquina realizar tareas básicas de red como DNS y DHCP y comunicarse con el controlador de Dominio, si existiese, para obtener las políticas. Una vez que el servicio de firewall está en ejecución, carga y ejecuta la política de ICF y remueve los filtros prefijados en tiempo de boot. La política de boot-time *no* puede reconfigurarse y por tanto da seguridad completa a la red.

Evidentemente estas políticas y esta seguridad no existe si el firewall está desactivado.

¿CUAL ES EL CAMBIO IMPORTANTE Y QUÉ SE TRATA DE MITIGAR?
Con este cambio, la máquina está más protegida de posibles ataques en los momentos de encendido y apagado que los cortafuegos no son capaces de controlar.

CONFIGURACIÓN GLOBAL
--------------------
En anteriores versiones del ICF de Windows, este podía configurarse para cada interface de red. De esta forma, cada interfaz de red, tenía sus propias reglas. Esto puede conllevar un dificultad añadida para sincronizar las reglas entre distintas conexiones. Además, las nuevas conexiones no tendrían ninguno de los cambios en la configuración que se hayan ido aplicando a las conexiones existentes.

Con la configuración"global" de ICF, cuando ocurre un cambio en la configuración, este se aplica a todas las conexiones de red. Esto incluirá nuevas conexiones cuando sean creadas.

Este cambio es aplicable a ICF para IPv4. Por contra, ICF para IPv6, soportará configuraciones globales y también por cada interface de red.

¿CUAL ES EL CAMBIO IMPORTANTE?
Al tener reglas y políticas globales, es mas fácil de cara a un usuario final el control de las políticas del firewall en todas las conexiones de red. Igualmente permite activar aplicaciones para trabajar con cualquier interface de red con una simple opción en la configuración.

RESTRICCION A LA SUBRED LOCAL
-----------------------------
Por defecto, cuando creamos una regla para permitir tráfico en un puerto, este quedará abierto globalmente -se permite tráfico desde cualquier dirección de red-.

En el SP2 de Windows XP, se puede configurar para que el puerto sólo reciba tráfico de red de su subred local , quedando protegido igualmente de las máquina externas a su red local (Internet).

Se recomienda aplicar la restricción a la subred local a cualquier puerto estático usado para comunicarse con la red local.

¿CUÁL ES EL CAMBIO IMPORTANTE Y QUÉ SE TRATA DE MITIGAR?
Alguna aplicaciones necesitan comunicarse con otras máquinas en la red local y no con máquinas en Internet. Permitiendo a los puertos comunicarse únicamente con la subred local, se restringe el alcance de quienes pueden acceder a ese puerto. Esto mitiga ataques que pueden ocurrir debido a puertos que estén abiertos para cualquier localización.

FUNCIONAMIENTO Y CONFIGURACIÓN AUTOMÁTICA EN LA SUBRED LOCAL
------------------------------------------------------------
Cuando el servicio de compartir archivos e impresoras esta activado, cuatro puertos específicos se ven afectados por el acceso restringido de la subred local. Los siguientes puertos pueden recibir entonces tráfico desde la subred local:

UDP puerto 137
UDP puerto 138
TCP puerto 139
TCP puerto 445

Si alguna otra aplicación especifica no de Windows usase esos puertos, al no estar activado el servicio de compartir archivos e impresoras de Windows, sólo podrá comunicarse con la subred local y no con el exterior.

SOPORTE EN LA LÍNEA DE COMANDOS
-------------------------------
El soporte para ICF se añade en Windows XP al instalar el Advanced Networking Pack. Pero este soporte sólo era aplicable al ICF IPv6. Con el SP2 de XP, la estructura cambia para incluir soporte para configurar el ICF completo. De esta manera, podemos:

* Configurar el estado por defecto de ICF (Off, Enabled, Shielded)
* Configurar que puertos pueden ser abiertos, incluyendo puertos para permitir acceso global o acceso restringido a la subred local o cuando los puertos pueden ser para todas las interfaces o para una interfaz de red en particular.
* Configurar opciones de logon.
* Configurar las opciones de manejo del ICMP (Internet Control Message Protocol)
* Añadir o quitar aplicaciones de la lista de permiso del ICF

Esto se aplica tanto al ICF como al ICF IPv6, excepto cuando la funcionalidad es especifica del ICF solamente.

¿CUÁL ES EL CAMBIO IMPORTANTE?
Permitir a los administradores un método abreviado de configuración a través de secuencias de comandos sin necesidad de usar la interface gráfica. Por tanto esta configuración puede manejarse con scripts remotamente.

MODO DE OPERACIÓN 'SHIELDED'
----------------------------
(Literalmente "escudado". Pero no se ha decidido todavía el nombre definitivo con que saldrá).

ICF podría configurarse para permitir tráfico de llamadas entrantes no solicitadas durante su uso normal. Esto es típico para poder compartir archivos e impresoras. Si se descubre un intento de acceso de seguridad no solicitado en uno o más de los servicios de escucha de Windows, puede ser necesario cambiar de modo sólo-cliente a modo escudado (shielded). Este cambio de modo reconfigura automáticamente ICF para prevenir tráfico entrante no solicitado y se hace sin necesidad de reconfigurar el firewall.

En este modo, todos los agujeros estáticos son cerrados. Cualquier llamada mediante API de un programa interno quedará registrada, pero no será aplicable por ICF hasta que su modo operacional vuelva a la situación de operación normal. Todas las peticiones de "escucha" por parte de las aplicaciones también serán ignoradas.

Esto se aplica tanto a ICFv4 como a ICF IPv6.

(Nota: en castellano, a este modo lo podríamos llamar "paranoico". Es decir, cuando ICF descubre que alguien está intentado usar puertos conocidos de servicios del sistema, y que en vez de ser peticiones normales parecen de un intento de ataque, ICF se pone en modo "paranoico", y bloquea temporalmente todos los accesos de entrada a la máquina)

¿CUÁL ES EL CAMBIO IMPORTANTE Y QUÉ SE TRATA DE MITIGAR?
Los virus, gusanos y atacantes miran los puertos para establecer su ataque. Cuando ICF está en modo operacional prevendrá que estos tipos de ataque puedan resultar exitosos.

¿QUÉ TRABAJARÁ DIFERENTE O DEJARÁ DE TRABAJAR?
En este modo de operación, la máquina no escuchará peticiones originadas desde la red. Sólo las conexiones salientes y autorizadas tendrán éxito.

LISTA DE PERMISOS Y APLICACIONES EN EL ICF
------------------------------------------
Algunas aplicaciones actúan como clientes y servidores. Cuando intenten actuar como servidores necesitaremos autorizar el tráfico entrante.

En anteriores versiones de Windows, era necesario definir los puertos previamente o bien la aplicación necesitaba llamar al API de configuración para establecer los puertos por los que iba a escuchar. Esto es realmente dificultoso en comunicaciones peer-to-peer cuando los puertos no son conocidos a priori. Esto obligaba además a cerrar la aplicación todos los puertos creados cuando la aplicación finalizaba.

Adicionalmente estos puertos podían ser abiertos solo cuando las aplicaciones rodaban en un contexto de seguridad o en la cuenta del administrador local. Esto viola el principio de menor privilegio al requerir que las aplicaciones se ejecutasen en contextos administrativos, en contra de usar sólo los mínimos privilegios necesarios en cada cuenta de la máquina.

Con el SP2, una aplicación que necesite escuchar en un puerto de la red, puede ser añadida a la lista de permisos de ICF. Si una aplicación está en la lista de permisos de ICF, Windows automáticamente abrirá los puertos que necesite mirando el contexto de seguridad de la aplicación

¿CUÁL ES EL CAMBIO IMPORTANTE Y QUÉ SE TRATA DE MITIGAR?
Cuando una aplicación está en la lista de permisos de ICF, solo los puertos necesarios para esa aplicación estarán abiertos, y *sólo* estarán abiertos durante el tiempo en que esa aplicación los tenga en escucha.

Esto también permite que aplicaciones que estén escuchando en un puerto se puedan ahora ejecutar con los permisos de un usuario normal. En anteriores versiones de Windows, estas aplicaciones debían ejecutarse con permisos administrativos.

PERFILES MÚLTIPLES
------------------
El soporte a múltiples perfiles en ICF, le permite crear dos colecciones de políticas para el firewall: una, cuando la máquina está conectada a una red corporativa y otra cuando no lo está. De esta manera, podemos especificar que las políticas sean menos restrictivas en la red corporativa y tener una política mucho más agresiva cuando estamos fuera de ella.

Los perfiles múltiples sólo se aplican en las máquinas que están unidas a un Dominio. Las máquinas que lo están sólo a grupos de trabajo, únicamente mantienen un perfil.

¿CUÁL ES EL CAMBIO IMPORTANTE Y QUÉ SE TRATA DE MITIGAR?
Para máquinas portátiles, es una buena opción y es deseable el poder tener mas de una configuración de ICF. Cuando se está a salvo en una red corporativa, podemos bajar el nivel de seguridad, pero en cambio, al conectarse en Internet, es critico el asegurarse de que sólo los puertos necesarios están expuestos al exterior.

SOPORTE A RPC
-------------
En anteriores versiones de Windows, ICF bloquea las llamadas a procedimiento remoto (RPC).
ICF puede ser configurado para permitir tráfico al RPC Endpoint Mapper. Algunas aplicaciones y componentes fallan si el puerto de RPC no tiene permisos para comunicarse en la red. Algunos ejemplos son los siguientes (existen bastantes más):

* Compartir Archivos e Impresoras.
* Administración Remota.
* Configuración de WMI remota.
* Scripts para manejar clientes remotos y servidores.

EL RPC abre varios puertos y ofrece diferentes servidores en ellos. En una configuración tipo de estación de trabajo o servidor, hay cerca de 60 servidores RPC ejecutándose por defecto y en escucha de peticiones de clientes en la red. Algunos servidores tienen más, dependiendo de su configuración. Este es el lado peligroso del ataque al RPC.

Los procesos servidores del RPC incluidos con Windows XP, son múltiples y sin embargo son lanzados por el mismo nombre de fichero imagen (svchost.exe). ICF adopta diferentes posturas de cara a los servicios RPC. Cuando se abre un puerto, el llamador puede reclamar que el puerto sea uno de los del RPC. ICF aceptará esto solamente si el llamador se está ejecutando en los contextos de Local System. Network Service o Local Service. ICF lleva también un flag en el perfil que permite que puertos de RPC sean abiertos aunque el llamador no esté en la lista de permisos de ICF.

Este indicador es un indicador en el registro (REG_DWORD) llamado PriviligedRpcServerPermission. Los valores corresponden a los enumerados para NET:FWV4_SERVICE_PERMISION:

0. Servidores RPC sólo están permitidos si están dentro de la lista de permisos de ICF
1. Si un servidor RPC no está en la lista de permisos del ICF, el puerto puede ser abierto pero sólo aceptará llamadas de la subred local.
2 Si un servidor RPC no está en la lista de permisos de ICF, el puerto puede ser abierto al tráfico en cualquier subred.

NOTA: Sin embargo, las aplicaciones autorizadas siempre sobreescriben la opciones genéricas del RPC. Por ejemplo, si una opción del RPC esta puesta como "allow local", pero el servidor RPC está también en la lista de permisos del ICF, en la cual, por ejemplo, el permitir sólo a la subred local está colocado a "false", el puerto RPC quedará abierto a todas las subredes.

¿CUÁL ES EL CAMBIO IMPORTANTE Y QUÉ SE TRATA DE MITIGAR?
Asegurarnos que el ICF trabaja con el RPC requerido para algunos entornos corporativos. Y sin embargo, que los servicios RPC no estén expuestos a la red por defecto. Siendo más exactos, podemos controlar exactamente qué servicios del RPC están expuestos a la red. Por contra, añadiendo un nombre genérico de proceso como SVCHOST.EXE a la lista de ICF (o de cualquier otro firewall comercial), exponemos todos los servicios a un ataque de red. ICF puede controlar, a pesar de ser el mismo programa ejecutable, qué servicios serán los realmente expuestos.

¿QUÉ TRABAJARÁ DIFERENTE O DEJARÁ DE TRABAJAR?
Por defecto, RPC no funcionará a través de ICF. Todos los servicios y aplicaciones que usen RFC se verán afectados. Sin embargo, ICF puede ser configurado para permitir trabajar con los servicios RPC.

SOPORTE REFORZADO A LA COMUNICACIÓN MULTICAST Y BROADCAST
---------------------------------------------------------
El tráfico de red Multicast y Broadcast difiere del unicast (visto hasta ahora), en que las respuestas provienen de hosts desconocidos. Por ello, los firewalls normales y las versiones anteriores del ICF filtraban estas conexiones e impedían que fuesen aceptadas. Esto deja que la máquina deje de funcionar en un montón de escenarios y configuraciones, sobre todo en aquellas multimedia de tipo streaming.

Para permitir que en estos escenarios el funcionamiento de las aplicaciones sea correcto, ICF permite una respuesta unicast durante los siguientes tres segundos desde cualquier origen en el mismo puerto desde el cual se ha originado la petición multicast o broadcast.

¿CUÁL ES EL CAMBIO IMPORTANTE Y QUÉ SE TRATA DE MITIGAR?
Esto permite a los servicios y a las aplicaciones que usen comunicaciones multicast/broadcast comunicarse con el mundo sin necesidad de usar un servicio para alterar la política del firewall. Es importante resaltar que ciertos servicios como NETBIOS sobre TPC/IP, y algunos puertos sensibles a este tipo de trafico, *no* serán expuestos.