Seguridad

Exploración de Firewall de Windows

Steve Riley

Resumen:

• Protección entrante frente a protección saliente
• Plataforma de filtrado de Windows
• Interfaz seguridad avanzada
• Perfiles de red

En los tiempos de la era paleolítica de la informática, nadie pensaba jamás en instalar firewalls en equipos individuales. ¿Quién los necesitaba? Casi nadie había oído hablar de Internet, TCP/IP no estaba a la vista por ninguna parte y los protocolos de LAN no distribuían más allá del edificio o del campus. Los datos importantes residían en

el mainframe o en servidores de archivos. La información que las personas conservaban en sus equipos de escritorio rara vez era esencial para la misión y el propio peso del equipo proporcionaba una cantidad decente de seguridad física. Si había una conexión a Internet disponible, probablemente existían algunos traductores de protocolos a mitad de camino y un enrutador de filtrado de paquetes (es decir, un "firewall") en el perímetro, quizá configurado con demasiadas reglas y excepciones.

Los entornos informáticos actuales difieren totalmente de los de aquellos tiempos antiguos. Todo se conecta a Internet (y ahora habla TCP/IP) y los dispositivos portátiles son el estándar de hoy. Es probable que su empleador le haya dado un equipo portátil, no sólo porque se preocupa por usted, sino porque le interesa obtener más de usted; esperaba que trabaje cuando tenga cinco minutos libres y una conexión Wi-Fi. Quizá los equipos portátiles puedan costar más que los de escritorio, pero esa inversión sin duda se devuelve en productividad. Como puede ver, es la portabilidad lo que los hace tan cautivantes, tanto para usted como para sus adversarios.

Piense en lo siguiente: de la cantidad total de tiempo que su equipo portátil está encendido y conectado a alguna red, ¿qué porcentaje de ese tiempo está conectado a su red corporativa? Si se parece a mí, quizá un 20 por ciento como máximo. Lo cuál significa que sólo el 20 por ciento del tiempo mi equipo portátil se encuentra seguro dentro de los límites de la red corporativa de Microsoft, protegido de los ataques externos por las defensas del perímetro de la red. Pero ¿qué sucede el 80 por ciento del tiempo cuando mi equipo portátil está, para todo propósito práctico, conectado directamente a Internet? (Y con frecuencia estoy conectado a la red más peligrosa del mundo: la LAN del hotel en una conferencia de seguridad de equipos.) Y esas veces en que estoy conectado a la red corporativa, ¿qué ocurre con las amenazas que suponen los otros equipos en ese entorno?

Los controles de seguridad evolucionan para seguir, a veces muy de lejos, a las amenazas. Los virus eran un problema de los clientes porque las personas intercambiaban disquetes, de modo que los programas antivirus aparecieron primero en los clientes. Más tarde, cuando se hizo popular el correo electrónico y el malware maduró en gusanos que dependían de la distribución del correo electrónico, los programas antimalware evolucionaron y aparecieron en las puertas de enlace de correo electrónico. Con el auge de la Web, el malware maduró en caballos de Troya y los programas antimalware lo siguieron en los servidores proxy de acceso a Internet. Es un camino evolutivo bien conocido que nadie discute.

Ahora apliquemos la misma lógica a los firewalls. Aunque un firewall en el perímetro de la red era suficiente protección contra las amenazas de ayer, esto ya no es así porque las amenazas son diferentes, son más sofisticadas y se encuentran más extendidas. Y no hay que olvidar que los dispositivos y estilos de trabajo difieren apreciablemente de los del pasado. Muchos equipos contienen información confidencial almacenada de forma local y pasan mucho tiempo lejos de la red corporativa (es decir, fuera del perímetro). Por lo tanto, el firewall debe evolucionar en un mecanismo individual de protección del cliente. No se equivoque: los firewalls de cliente ya no son opcionales. Para proteger sus equipos de las amenazas de su propia red corporativa y de Internet, se requieren firewalls de cliente.

Firewalls de cliente y dramatización de seguridad

Muchas personas no notaron que el lanzamiento inicial de Windows ®XP incluía un firewall de cliente. En realidad no es sorprendente porque el firewall estaba desactivado de forma predeterminada y escondido detrás de demasiados clics de mouse. A su propia manera bastante camuflada, el firewall aparecía sin ninguna indicación real de su propósito ni una orientación sobre su uso. Pero funcionaba. Si hubiera habilitado ese firewall, habría estado a salvo de Nimda, Slammer, Blaster, Sasser, Zotob y de todo lo demás que intentaba arrojar tráfico no solicitado en su puerto de red. Al darse cuenta de la importancia de la protección del cliente, Windows XP Service Pack 2 (SP2) habilitó de forma predeterminada el firewall, creó dos perfiles (Internet y red corporativa) y permitió su habilitación mediante directivas de grupo.

Desafortunadamente, dos barreras demoraron la adopción del firewall de Windows XP SP2: las preocupaciones por las aplicaciones y dramatización de seguridad de las mismas. Muchas personas temían que el firewall hiciera que sus aplicaciones dejaran de funcionar correctamente. Sin embargo esto rara vez sucedía, debido al diseño del firewall. El firewall permitía que todo tráfico saliente dejara su equipo, pero bloqueaba todo el tráfico entrante que no fuera una respuesta a alguna solicitud saliente anterior. La única vez que este diseño interrumpía una aplicación en un cliente era cuando la aplicación creaba un socket de escucha y esperaba recibir solicitudes entrantes. El firewall de Windows XP permitía configuraciones sencillas de excepciones para programas o puertos (aunque, desafortunadamente, no mediante directivas de grupo).

El mayor freno fue la dramatización de seguridad realizada por los fabricantes de otros firewalls de cliente. Algunas personas creían que el diseño del firewall de Windows XP, concretamente permitir que todo el tráfico saliente dejara libremente el equipo, era insuficiente funcionalidad para un firewall de cliente. El argumento era que un firewall de cliente adecuado debía bloquear todo el tráfico, entrante y saliente, a menos que el usuario específicamente concediera permisos.

Ahora, pensemos en esto por un instante. Aparecen dos situaciones.

• Si ejecuta como administrador local y se infecta con malware, éste último simplemente deshabilitará el firewall. Alguien se apropia de su equipo.
• Si no ejecuta como administrador local y se infecta con malware, éste último hará que un firewall de terceros inicie un diálogo en un lenguaje externo en que intervengan puertos y direcciones IP y que incluya una pregunta muy grave: "¿Quiere permitir esto?" La única respuesta, por supuesto, es: "¡Sí, estúpido equipo, deja de acosarme!" Y una vez que ese diálogo se va, también lo hace su seguridad. O, con más frecuencia, el malware secuestra una sesión existente de un programa que usted ya autorizó, y ni siquiera alcanza a ver el diálogo. Otra vez, alguien se apropia de su equipo.

Existe un axioma importante de seguridad que debe entender: la protección pertenece al activo que quiere proteger, no a aquello contra la cual intenta protegerse. El enfoque correcto es ejecutar el ágil y aún eficaz Firewall de Windows en cada equipo de su organización, para protegerlos del resto de los equipos del mundo. Si intenta bloquear conexiones salientes de un equipo que ya está en peligro, ¿cómo puede estar seguro que el equipo hace lo que le solicita? La respuesta: No puede. La protección saliente es una dramatización de seguridad, es un artificio que sólo ofrece la impresión de mejorar su seguridad pero en realidad no hace nada que la mejore. Por este motivo no existía protección saliente en el firewall de Windows XP y por lo mismo no existe en el firewall de Windows Vista™. (Hablaré más sobre control saliente en Windows Vista en un instante).

¿Qué novedades presenta Windows Vista?

La plataforma de filtrado de Windows, parte de la nueva pila de red, es la base del firewall de Windows Vista. Como Windows XP, Windows Vista bloquea el tráfico entrante de forma predeterminada. Según el perfil usado en el equipo, quizá existan algunas excepciones predeterminadas para servicios de red (hablaré posteriormente sobre perfiles). Si lo desea, puede escribir reglas para permitir conexiones entrantes. También como en Windows XP, Windows Vista permite todo el tráfico saliente de procesos interactivos de forma predeterminada, pero restringe el tráfico saliente de los servicios que participan en restricción de servicio. Y, nuevamente, puede escribir reglas para bloquear conexiones salientes adicionales.

La gran diferencia entre Windows XP y Windows Vista es la nueva interfaz Seguridad avanzada y total compatibilidad con directivas de grupo para configuración y reglas (consulte la figura 1). La antigua IU del Panel de control aún está allí y permanece casi sin cambios excepto en el registro y las configuraciones del Protocolo de mensajes de control de Internet (ICMP), que ahora aparecen en la nueva IU. El complemento MMC de Seguridad avanzada, la nueva IU, ofrece todas las nuevas características y flexibilidad. También existe un nuevo contexto en el comando netsh, netsh advfirewall, a través del cual puede crear secuencias de comandos para agregar y eliminar reglas, establecer y mostrar directivas globales y por perfil, y mostrar el estado activo del firewall. Y para ustedes desarrolladores, FirewallAPI.dll y Netfw.h ofrecen control mediante programación de todas las configuraciones del firewall.

Figura 1** Firewall de Windows con Seguridad avanzada **(Hacer clic en la imagen para ampliarla)

La consola MMC de Seguridad avanzada está controlada por un asistente. Al crear una regla, puede elegir uno entre cuatro tipos: programa, puerto, predefinida o personalizada. Estos se describen en la figura 2.

Figure 2 Cuatro tipos de reglas

Hay muchos elementos a los que puede hacer referencia cuando escribe las reglas, y todos están disponibles para reglas locales y reglas aplicadas mediante directivas de grupo. Éstos son: Cuentas y grupos de usuarios y equipos de Active Directory®, direcciones IP de origen y destino, puertos TCP y UDP de origen y destino, números de protocolo IP, programas y servicios, tipos de interfaces (cableadas, inalámbricas o de acceso remoto) y tipos y códigos ICMP.

Una vez configurado, el firewall procesa las reglas en el orden siguiente:

Restricciones de servicio Algunos de los servicios en Windows Vista se restringirán a sí mismos para limitar la posibilidad de otro ataque estilo Blaster. Una de las restricciones es una lista de puertos requeridos por el servicio. El firewall la aplica e impide que el servicio use (o se le indique que use) cualquier otro puerto.

Reglas de seguridad de conexión La consola MMC de Seguridad avanzada incorpora IPsec así como el firewall. A continuación, se procesan todas las reglas que incluyen directivas IPsec.

Omisión autenticada Permiten que los equipos autenticados que se especifican omitan otras reglas.

Reglas de bloqueo Bloquean explícitamente el tráfico entrante o saliente especificado.

Reglas permitir Permiten explícitamente el tráfico entrante o saliente especificado.

Las reglas del firewall se almacenan en el Registro, pero no les diré dónde con exactitud. Ah, de acuerdo, las encontrarán en estas ubicaciones:

• HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
• HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
• HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System

No edite directamente las reglas en el registro. Si lo hace, ¡lo buscaremos y venderemos su mascota en eBay! Bueno, quizá no, pero la única manera admitida para editar reglas es mediante el uso de la consola MMC de Seguridad avanzada.

Perfiles de red

Windows Vista define tres perfiles de red: dominio, privado y público. Cuando el equipo se une al dominio e inicia correctamente sesión en el dominio, aplica automáticamente el perfil de dominio; el usuario nunca conseguirá hacer esta elección por sí mismo. Cuando el equipo se conecta a una red interna que le falta un dominio (tal como una red doméstica o de oficina pequeña), el usuario (o un administrador) debe aplicar el perfil privado. Por último, cuando el equipo se conecta directamente a Internet, debe aplicar el perfil público.

¿Cómo decide Windows Vista donde colocar el equipo? Siempre que hay un cambio de red (por ejemplo, si recibe una nueva dirección IP, obtiene una nueva puerta de enlace predeterminada u obtiene una nueva interfaz), un servicio denominado Reconocimiento de ubicación de red (NLA) detecta el cambio. Genera un perfil de red, que incluye información acerca de las interfaces existentes, si el equipo se autentica con un controlador de dominio, la dirección MAC de la puerta de enlace, etc. y le asigna un GUID. A continuación, NLA notifica al firewall y éste aplica la directiva correspondiente (existe una directiva definida para cada uno de los tres perfiles).

Si se trata de una nueva interfaz que el equipo nunca obtuvo con anterioridad y NLA no eligió el perfil de dominio, entonces observará un cuadro de diálogo que le solicita indicar a qué clase de red se conecta. Misteriosamente, existen tres alternativas: Doméstica, Trabajo y Pública. Quizá cree que "Trabajo" es el perfil de dominio, pero en realidad no lo es. Recuerde, nunca verá el perfil de dominio porque NLA lo selecciona de forma automática cuando el equipo inicia sesión en un dominio. En realidad, tanto Doméstica como Trabajo corresponden al perfil privado. Funcionalmente, son equivalentes, únicamente los iconos son diferentes. Nota: Debe ser administrador local o poder elevar sus privilegios a administrador local para seleccionar el perfil privado. Como lo esperaba, Pública corresponde al perfil público.

En Windows Vista, un perfil de red se aplica a todas las interfaces del equipo. Este es un resumen del árbol de decisión de NLA:

1. Examinar todas las redes conectadas.
2. ¿Hay alguna interfaz conectada a una red clasificada como pública? Si la respuesta es sí, establezca el perfil de equipo a público y salga.
3. ¿Hay alguna interfaz conectada a una red clasificada como privada? Si la respuesta es sí, establezca el perfil de equipo a privado y salga.
4. ¿Todas las interfaces ven un controlador de dominio y el equipo inició sesión correctamente? Si la respuesta es sí, establezca el perfil de equipo a dominio y salga.
5. Sino, establezca el perfil del equipo a público.

El objetivo es seleccionar el perfil más restrictivo posible. Sin embargo, hay dos efectos obvios secundarios. En primer lugar, si el puerto Ethernet del equipo está conectado a la red corporativa y su NIC inalámbrica se conecta al café cercano con conexión inalámbrica a Internet, el equipo seleccionará el perfil público, no el perfil de dominio. En segundo lugar, si el equipo se conecta directamente a Internet (con el perfil público) o se conecta a la LAN doméstica (con el perfil privado) y realiza una conexión VPN a su red corporativa, el equipo permanecerá en el perfil público o privado.

¿Qué puede significar esto? La directiva del firewall para el perfil de dominio incluye las reglas para asistencia remota, administración remota, uso compartido de impresoras y archivos, etc. Si depende de estas reglas para obtener acceso a un cliente de forma remota, no podrá hacerlo si el cliente ha elegido algún otro perfil. Pero no se desespere, puede escribir reglas de firewall para permitir todas las conexiones entrantes que necesite y, a continuación, aplicarlas sólo a conexiones VPN. Todavía puede administrar sus clientes sobre la VPN incluso cuando ellos no se encuentran en el perfil de dominio.

Control de conexiones salientes

Anteriormente dije que la forma típica de protección saliente en firewalls de cliente es sólo una dramatización de seguridad. Sin embargo, hay una forma de control saliente muy útil: el control administrativo de ciertos tipos de tráfico que sabe que no quiere permitir. El firewall de Windows Vista ya lo hace con restricciones de servicio. El firewall permite que un servicio se comunique sólo en los puertos que dice necesitar y bloquea todo lo demás que el servicio intenta hacer. Se puede basar en esta característica para escribir reglas adicionales que permitan o bloqueen tráfico específico para que coincida con la directiva de seguridad de la organización (consulte la figura 3).

Figura 3** Asistente para nueva regla de entrada **(Hacer clic en la imagen para ampliarla)

Digamos, por ejemplo, que desea prohibir a los usuarios la ejecución de un cliente en particular de mensajería instantánea. Puede crear una regla (en la directiva de grupo, por supuesto) para bloquear conexiones a los servidores de inicio de sesión para ese cliente.

Sin embargo, existen limitaciones prácticas para este enfoque. Por ejemplo, Windows Live™ Messenger (que quizá todavía conozca como MSN® Messenger) puede usar diversos servidores para el inicio de sesión y la lista cambia de forma permanente. Además, recurrirá al puerto 80/tcp si está bloqueado el puerto predeterminado 1863/tcp. Una regla para bloquear la conexión de Windows Live Messenger a sus servidores de inicio de sesión sería demasiado compleja y siempre inestable. Menciono esto para ilustrar que el control administrativo saliente puede ser útil, pero no es un sustituto para las directivas de restricción de software si necesita mantener un control estricto del software que los usuarios pueden instalar y ejecutar.

Proteja su equipo

El perímetro desapareció. Ahora cada equipo debe asumir la responsabilidad de su propia protección. Así como el antimalware se movió del cliente al perímetro, del mismo modo los firewalls se deben mover del perímetro al cliente. Puede tomar acciones inmediatas si habilita el firewall que ya tiene instalado.

Si sus sistemas ejecutan Windows XP o si se encuentra en transición a Windows Vista, Firewall de Windows está disponible para todos sus clientes y ofrecerá la protección que necesita para mejorar la seguridad en la organización, incluso cuando los trabajadores móviles se encuentren a miles de kilómetros de la oficina.

Dónde obtener más información

• Windows Vista TechCenter: Introducción a Firewall de Windows con Seguridad avanzada
• Windows Vista TechCenter: Firewall de Windows con Seguridad avanzada: diagnósticos y solución de problemas
• Presentación TechEd Europe de Steve Riley: Firewall de Windows Vista y mejoras de IPSec Enhancements
• The Cable Guy: Nuevo Firewall de Windows en Windows Vista y Windows Server "Longhorn"
• Laboratorio virtual de Firewall de Windows Vista

Steve Riley, responsable jefe de estrategias de seguridad en la Unidad de tecnología y seguridad de Microsoft y redactor colaborador de la revista TechNet Magazine, viaja por todo el mundo para dar conferencias y pasar tiempo con los clientes para ayudarles a protegerse y permanecer protegidos. Su último libro es Protect Your Windows Network (Addison-Wesley, 2005). Puede ponerse en contacto con él en la dirección steve.riley@microsoft.com.

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