WHITE PAPER

Balanceo de carga 101: Firewall Sandwiches

Updated May 18, 2010
  • Share via AddThis

Introducción

Históricamente, el uso más común del balanceador de carga de hardware basado en la red y su encarnación moderna, el controlador de entrega de aplicaciones (ADC), ha sido proporcionar alta disponibilidad, escalabilidad y capacidad de gestión para la aplicación de back-end, particularmente en el nivel de presentación. En segundo lugar, está el hecho de proporcionar esos mismos beneficios para otros componentes de la infraestructura de red, como los enrutadores y los firewalls. Hay muchas ventajas en la implementación de firewalls, en particular, detrás de los ADC (consulte el documento técnicoBalanceo de carga 101: la evolución hacia los controladores de entrega de aplicaciones para ver otros usos). En este documento técnico se muestra cómo puede implementar los ADC en un «sandwich de firewalls» para mejorar la disponibilidad, la escalabilidad y la capacidad de gestión en toda la infraestructura de TI.

Disponibilidad

Una de las principales razones para equilibrar la carga de los firewalls es garantizar la alta disponibilidad de todos los servicios detrás del firewalls. Proporcionar alguna forma de redundancia ayuda a garantizar que los servicios basados en la web de su organización estén siempre disponibles. Aunque esto puede lograrse fácilmente con una simple solución de clúster de firewalls activo/pasivo, una de las ventajas de utilizar ADC basados en hardware es el hecho de que los mismos dispositivos pueden proporcionar una mejor visibilidad de la disponibilidad de los servicios y los servicios de conmutación por error de forma individual.

Por ejemplo, en un firewalls basado en proxy, supongamos que únicamente deja de responder el proceso SMTP. Por lo general, una solución de clúster de firewall activo/pasivo no sería capaz de identificar este tipo de fallo. Si lo hiciera, su único recurso sería conmutar por error todas las conexiones al firewalls en espera, lo que potencialmente inhibiría conexiones que estaban funcionando perfectamente en otros servicios. Un ADC no solo proporciona la supervisión de los servicios individuales, sino que también es capaz de conmutar por error un servicio individual, como SMTP, a un firewall secundario sin afectar al resto de conexiones.

Escalabilidad

Otro de los inconvenientes de las soluciones de clúster de firewalls activos/pasivos es que no son escalables. Una vez que se supera la capacidad de un solo firewall, la única opción es sustituirlo por otro más grande que pueda soportar el aumento de carga. Un ADC, por el contrario, permite añadir simplemente cortafuegos adicionales para gestionar el aumento de carga a medida que sea necesario.

La inteligencia del ADC también permite a una empresa escalar la capacidad en función de las necesidades de los servicios. Por ejemplo, supongamos que, al igual que muchas organizaciones, el tráfico de su sitio web público está creciendo de forma significativa y está haciendo que su cortafuegos se tenga que esforzar. En lugar de actualizar todos los cortafuegos, puede utilizar un ADC para trasladar todo el tráfico de su sitio web a cortafuegos exclusivos sin tener que cambiar ningún otro aspecto de la configuración del sitio. Esto le permite escalar de forma independiente la infraestructura de seguridad del sitio web público al margen de las necesidades de seguridad del resto del entorno de red de su organización, evitando así que el tráfico web afecte a otras aplicaciones críticas para la empresa.

Capacidad de gestión

Por último, los ADC proporcionan una importante flexibilidad en la gestión de los firewalls. Dado que pueden dirigir el tráfico de forma rápida e inteligente al nivel de servicio de diversas maneras, pueden utilizarse para llevar a cabo tareas de mantenimiento (por ejemplo, dirigir el tráfico lejos de un firewall en el que haya que trabajar fuera de línea); realizar actualizaciones de software, hardware y políticas (por ejemplo, cambiar a los usuarios a los nuevos sistemas y, si se produce un problema, volver a enviar el tráfico a los antiguos hasta que se resuelva el problema); y segmentar el tráfico en diferentes cortafuegos para diversos grupos empresariales, iniciativas u otras necesidades creando con poco impacto en el tráfico existente. Los ADC pueden utilizarse para realizar el desencriptado SSL, lo que permite a los cortafuegos aplicar correctamente las políticas en las comunicaciones encriptadas (como HTTPS). El desencriptado del tráfico ayuda cuando un administrador decide enrutar el tráfico a través de un sistema de detección de intrusiones (IDS) o un sistema de prevención de intrusiones (IPS) antes o después de pasar por el propio cortafuegos.

El diseño básico de un sanwich de Firewall

El nombre «sandwich de firewall» refleja el diseño básico utilizado para la mayoría de las implementaciones de firewall con balanceo de carga (consulte la Figura 1). Dado que el propio firewall rara vez es el destino previsto de las conexiones de los clientes, el tráfico debe dirigirse de forma transparente a través de los firewalls en ambas direcciones, entrante y saliente. Por lo tanto, se necesitan dispositivos ADC a ambos lados de los firewalls, como el pan a cada lado del relleno de un sandwich.

Existen varios puntos interesantes a tener en cuenta acerca de este diseño. En primer lugar, debe tenerse en cuenta que, a excepción de la interfaz externa del enrutador de Internet, toda la infraestructura está construida sobre un espacio de direcciones IP no enrutables. Esto hace muy difícil que se produzcan ataques a la red desde Internet.

diagrama
Figura 1. Un diseño básico de bocadillo de cortafuegos

En segundo lugar, se debe tener en cuenta que el servidor virtual en el par ADC n.º 1 está en el puerto 0. El puerto 0 es la abreviatura de «todos los puertos» (al igual que 0.0.0.0 es la abreviatura de todas las redes). Si bien es cierto que puede configurar varios servidores virtuales en cada uno de los puertos en los que desea recibir tráfico y simplemente bloquear el resto del tráfico en el ADC, el uso del puerto 0 minimiza la configuración que es necesaria cuando se añaden nuevos servicios. Además, al bloquear el tráfico antes del firewall, los registros del mismo (o el IDS asociado a él) no tienen una imagen completa del tráfico que se envía a su sitio. El par de ADC n.º 2 tiene un servidor virtual específico para el puerto 80 (tráfico web) porque está distribuyendo el tráfico a los servidores web que ejecutan el puerto 80 en el back-end. Usted podría utilizar fácilmente el puerto 0, pero un uso más restrictivo es una práctica común, a menos que tenga un número significativo de servicios duplicados que se ejecutan en todos los servidores de back-end.

Por último, si observa la puerta de enlace (GW) del par de ADC n.º 2, se dará cuenta de que en realidad es un grupo, o «servidor virtual inverso», que distribuye el tráfico a través de los tres firewalls de salida. Esto proporciona una ruta de salida altamente disponible en el caso de un fallo del firewalls después de la primera conexión; sin embargo, puede tener problemas con el enrutamiento asimétrico (consulte la sección de Enrutamiento asimétrico más adelante en este documento).

Flujo de tráfico típico: entrada

En una solución típica de balanceo de carga del servidor web, el ADC tiene un servidor virtual que es el destino del tráfico del cliente, termina las solicitudes y, a continuación, las distribuye directamente a los servidores que alojan la aplicación (consulte el documento técnico Equilibrio de carga 101: componentes básicos). En el diagrama anterior, la dirección IP de Internet válida asociada al sitio web (www.example.com) de 192.0.2.5 no existe técnicamente en ninguna interfaz de ningún dispositivo. Entonces, ¿cómo va a conectarse el usuario al servidor web? La solución requiere servidores virtuales «de red» o «comodines», servidores virtuales normales y un toque de magia de enrutamiento. Para seguir el tráfico:

  1. El usuario solicita www.example.com y se convierte en 192.0.2.5:80.
  2. El cliente realiza la primera solicitud al sitio web.
  3. SYN: 192.168.1.1:5000 ? 192.0.2.5:80
  4. Dado que ejemplo.com es propietario de la red 192.0.2.0, el paquete del cliente se enruta a través de Internet para llegar al enrutador de Internet de www.example.com.
  5. El enrutador 1 tiene una entrada de enrutamiento que dice que la ruta de siguiente salto para alcanzar la red 192.0.2.0 es 172.16.1.5, la interfaz externa compartida del par de ADC n.º 1.
  6. SYN: 192.168.1.1:5000 ? 192.0.2.5:80 enrutador de siguiente salto 172.16.1.5
  7. El par de ADC n.º 1 tiene un servidor virtual de red que detecta el tráfico destinado a toda la red 192.0.2.0/24 y está configurado para no realizar la traducción de direcciones. Ese servidor virtual distribuye el tráfico a los tres firewalls, balanceo la carga según sea necesario y enrutando la solicitud al firewall seleccionado.
  8. SYN: 192.168.1.1:5000 ? 192.0.2.5:80 enrutador de siguiente salto 172.16.2.10
  9. Los cortafuegos están configurados con una ruta que dice que la ruta de siguiente salto para alcanzar la red 192.0.2.0 es 172.16.3.5, la interfaz externa compartida del par de ADC n.º 2.
  10. SYN: 192.168.1.1:5000 ? 192.0.2.5:80 enrutador de siguiente salto 172.16.3.5
  11. El par de ADC n.º 2 tiene un servidor virtual normal que detecta el tráfico destinado a 192.0.2.5:80, y cuando se recibe la conexión, equilibra la carga en los servidores de aplicaciones del back-end.
  12. SYN: 192.168.1.1:5000 ? 192.0.2.5:80 se convierte en
    SYN: 192.168.1.1:5000 ? 172.16.4.11:80
  13. Como el par de ADC n.º 2 tiene una interfaz en la red 172.16.4.0/24, simplemente envía el paquete al servidor que responde.

Flujo de tráfico típico: salida

El flujo de tráfico saliente no es muy diferente a una implementación típica, con la excepción de la selección de un firewall apropiado, idealmente el mismo cortafuegos que se utilizó en la conexión de entrada original (consulte Posibles problemas de implementación, más adelante en este documento). Para seguir las rutas predeterminadas hasta llegar a Internet:

  1. El servidor responde a la solicitud y envía el paquete a su puerta de enlace normal predeterminada.
  2. SYN/ACK: 172.16.4.11:80 ? 192.168.1.1:5000 puerta de enlace predeterminada 172.16.4.5
  3. El par de ADC n.º 2 reconoce esto como un retorno de conexión de carga equilibrada y reescribe las direcciones.
  4. SYN/ACK: 172.16.4.11:80 ? 192.168.1.1:5000 se convierte en
    SYN/ACK: 192.0.2.5:80 ? 192.168.1.1:5000
  5. El par de ADC n.º 2 tiene ahora la posibilidad de elegir qué firewall utilizar para devolver el paquete. El factor decisivo aquí puede verse influenciado por muchas cosas, pero para los propósitos de este ejemplo, enrutará el paquete de vuelta al firewall desde el que vino el SYN original.
  6. SYN/ACK: 192.0.2.5:80 ? 192.168.1.1:5000 ? ruta mediante 172.16.3.10
  7. El cortafuegos 1 recibe la respuesta y simplemente reenvía el paquete a través de su ruta predeterminada.
  8. SYN/ACK: 192.0.2.5:80 ? 192.168.1.1:5000 ? ruta mediante puerta de enlace predeterminada 172.16.2.5
  9. El enrutador 1 recibe el paquete en su interfaz interna y lo reenvía a través de su ruta predeterminada a Internet.
  10. Finalmente, el cliente recibe la respuesta.
  11. SYN/ACK: 192.0.2.5:80 ? 192.168.1.1:5000

Posibles problemas de implementación

Existen varios problemas potenciales en esta configuración, incluyendo la gestión del tráfico encriptado, cómo evitar el enrutamiento asimétrico y cómo gestionar la complejidad a medida que aumenta el número de interfaces del firewall.

Tráfico cifrado

Si la conexión del cliente fuera HTTPS en lugar de HTTP, el tráfico seguiría estando encriptado al cruzar el cortafuegos, lo que impediría al cortafuegos realizar cualquier tipo de inspección de la carga útil. La solución más sencilla a este problema es implementar un firewall de aplicación dentro del par de ADC n.º 2 o, después de desencriptar el contenido, hacer que el ADC lo reenvíe a un IDS/IPS/WAF antes de enviarlo a la aplicación real. Esto le permite utilizar exactamente la misma configuración y gestionar toda la seguridad dentro del perímetro del firewall.

Una segunda solución consiste en configurar el ADC n.º 1 para que se encargue de descifrar los paquetes antes de que pasen al firewall. Esto se puede lograr mediante varios métodos, pero como el desencriptado tiene lugar fuera del perímetro del firewall, generalmente no se recomiendan.

Enrutamiento asimétrico

Otro problema común tiene que ver con el enrutamiento asimétrico a través de los firewalls. Los problemas surgen cuando un paquete entrante pasa por un cortafuegos, pero el paquete de retorno pasa por otro diferente. Normalmente, los cortafuegos de inspección de estado tienen reglas que permiten que se inicie la conexión y, a continuación, solo permiten que pasen los paquetes que pertenecen a esa conexión establecida. Si el paquete de retorno va a un cortafuegos diferente, será rechazado. Existen varias soluciones para esto.

Una solución es habilitar el estado compartido entre los firewalls, para que todos los firewalls conozcan el estado de las conexiones y, por tanto, permitan el paso del paquete saliente. Esta opción no está disponible en todos los firewalls y, aunque es una opción atractiva, a menudo se convierte en un problema de rendimiento a medida que aumenta el número de cortafuegos. Además, el estado compartido puede ir en detrimento de la escalabilidad porque limita todo el grupo de cortafuegos a la capacidad de la tabla de estado de un solo dispositivo. Mirando el lado positivo, si un firewall fallara, todas las conexiones existentes podrían trasladarse fácilmente sin tener que volver a crear toda la información de estado, razón por la que muchas organizaciones comparten el estado incluso cuando solucionan este problema a través de otros medios.

Otra de las soluciones más comunes para el enrutamiento asimétrico es el uso de la persistencia. Normalmente, esto significaría asegurarse de que el par de ADC n.º 1 siempre envía conexiones al mismo cortafuegos de origen, o que el par de ADC n.º 2 siempre envía conexiones al mismo servidor web. En este caso, es importante asegurarse también de que el par de ADC n.º 2 recuerde qué cortafuegos (mediante IP o Control de acceso al medio [MAC]) le envió la conexión original para poder enviar el paquete de retorno a ese mismo cortafuegos. Básicamente, esto equivale a garantizar que no se produzca un enrutamiento asimétrico al eliminar el balanceo de carga dinámico una vez que se realiza la primera conexión.

Para lograr esto, hay dos maneras habituales. La primera, que únicamente funciona para el tráfico HTTP, es hacer que el par de ADC n.º 1 inserte una cookie HTTP que indique al par de ADC n.º 2 qué firewall debe devolver el tráfico. Esto solo funciona para HTTP (ni siquiera para HTTPS, a menos que se rompa la encriptación en el par de ADC n.º 1) y, por lo tanto, no suele se suele implementar excepto por parte de los ADC que no ofrecen otra alternativa.

La mayoría de los proveedores de ADC admiten la capacidad de «último salto» o «persistencia inversa». Con esta capacidad, el par de ADC n.º 2 crea otra entrada de estado de conexión que le indica la dirección MAC del dispositivo que envió la solicitud original. En lugar de enrutar en un sentido tradicional, el par de ADC n.º 2 simplemente reenvía el tráfico a la dirección MAC del cortafuegos desde el que se recibió.

diagrama
Figura 2. Enrutamiento de retorno de último salto por MAC

Observando el flujo de tráfico original (consulte la Figura 2), el tráfico de entrada que va al servidor virtual de 192.0.2.5:80 se termina en el par de ADC n.º 2. Cuando esto sucede, el par de ADC n.º 2 realiza entradas en la tabla de estado para mantener esa conexión. Esto suele incluir las características de la conexión TCP de bajo nivel, así como (dada la configuración de persistencia) la IP del servidor seleccionado para recibir ese tráfico. Con capacidad de último salto, el ADC también registrará la dirección MAC del firewalls del que recibió el paquete, en este caso 01:23:45:67:89:ab.

Cuando el servidor seleccionado responde y envía el tráfico de vuelta al ADC, en lugar de hacer una búsqueda de ruta normal, el ADC comprueba la tabla de estado, ve la entrada MAC y reenvía el paquete (después de cambiar el destino de origen de nuevo a la IP del servidor virtual) a la dirección MAC especificada con la IP de destino del cliente. En la mayoría de las implementaciones del ADC, esta es una configuración automática predeterminada y no requiere ninguna interacción por parte del usuario.

Complejidad con posibilidad de crecimiento

El diseño que se detalla de la sección anterior no es demasiado complicado; sin embargo, el firewall solo tiene dos «patas» o interfaces: una externa y otra interna. Muchas implementaciones de cortafuegos tienen al menos tres, si no más. Para utilizar este diseño en su totalidad, cada pata debe tener un dispositivo de tipo ADC para garantizar que el tráfico se enruta correctamente en ambas direcciones. A medida que aumenta el número de interfaces, la complejidad puede aumentar y esto puede ser difícil a la hora de solucionar problemas. Aunque el diseño es básicamente el mismo, y se han implementado correctamente sandwiches de firewalls de hasta ocho patas, la complejidad puede resultar un problema potencial.

Recuperarse de un fallo del firewall

¿Qué ocurre cuando falla un firewall? Obviamente, si un firewall falla antes de una conexión inicial del cliente, el ADC simplemente redirigirá la conexión del cliente a un firewall que se encuentre funcionando. Recuerde que con este diseño, esto se puede hacer en base al servicio. Si un firewall no puede gestionar el tráfico SMTP, pero sí el HTTP, el ADC seguirá enviando transacciones HTTP a ese firewall, pero enviará el tráfico SMTP a los demás cortafuegos. Los dos fallos que causan los posibles problemas son 1) cuando un firewall falla después de pasar el paquete de entrada pero antes de pasar el paquete de retorno; y 2) cuando un cortafuegos falla después de que se haya establecido y utilizado una conexión completa.

En el primer caso, el problema es que el par de ADC n.º 2 querrá enviar el tráfico de vuelta al cortafuegos de origen, que ahora no funciona. Afortunadamente, en esta situación, el tiempo de la conexión del cliente se agotará y el cliente tratará de reenviar una solicitud de conexión, que ahora pasará por un firewall que funcione en la solicitud de entrada, resolviendo así el problema con poco o ningún impacto para el usuario.

En el segundo caso, el mayor impacto se produce en la experiencia del cliente. Existen las mismas cuestiones para asegurar que la conexión va a un firewall que funciona. Esta vez, sin embargo, independientemente de la direccionalidad (entrante o saliente), el paquete terminará en un firewall que nunca ha visto la conexión antes. A menos que se implemente un estado compartido entre los cortafuegos, la conexión fallará y el cliente deberá reconectarse y volver a iniciar la sesión. El lado positivo es que esto solo afecta realmente a las conexiones TCP de larga duración, e incluso en ese caso, una vez que los usuarios se reconecten, volverán a estar conectados al servicio; FTP se vería afectado, pero HTTP v1.0 probablemente no se verá afectado en absoluto.

Curiosamente, con un ADC que implementa conexiones de proxy completo (conexiones independientes del cliente y el servidor), existen soluciones que pueden mitigar incluso estos fallos, al menos desde la perspectiva del cliente. Tomemos, por ejemplo, una situación en la que la conexión del cliente se termina en el par de ADC n.º 1, y ese par realiza su propia conexión al servicio. Si un cortafuegos falla y la conexión debe reiniciarse, es la conexión entre el par ADC n.º 1 y el servidor la que debe reiniciarse, no necesariamente la conexión del cliente. Aunque esto requeriría varias configuraciones no estándar y dependería del protocolo concreto, esta solución puede enmascarar fácilmente el fallo del cortafuegos desde el punto de vista del cliente.

Una de las verdaderas ventajas de esta solución general es que, una vez que el firewall que crea el problema vuelve a estar en funcionamiento, estará inmediatamente disponible para nuevas conexiones y no habrá ningún impacto adicional para los usuarios.

Conclusión

Aunque la configuración que se propone en este documento es el ejemplo más sencillo de los cientos de posibles opciones de implementación, es suficiente para demostrar las ventajas de implementar firewalls detrás de los controladores de entrega de aplicaciones (ADC). Su implementación dependerá, en última instancia, de las necesidades específicas de su organización y de la infraestructura existente, así como de las consideraciones de costes de adquisición, operaciones y gestión.

Este concepto básico del sandwich de firewall puede utilizarse para gestionar el tráfico a través de muchos dispositivos transparentes y semitransparentes, con o sin estado, como aceleradores SSL, IDS/IPS, y enrutadores y servidores proxy, es decir, cualquier dispositivo en línea que requiera mayor disponibilidad, escalabilidad y capacidad de gestión.