Implementación de FTDv a escala automática en Azure en un entorno de alta confianza

Introducción

Este documento describe cómo implementar Cisco Firepower Threat Defence Virtual (FTDv) escalado automáticamente en Azure en un entorno de alta confianza.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Los NGFW y Firepower Management Center deben comunicarse a través de IP privada
• El equilibrador de carga externo no debe tener IP pública
• La aplicación de la función debe poder comunicarse con IP privada

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Azure
• Centro de administración FirePOWER
• Conjunto de ampliación de máquina virtual

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

FTDv lleva la funcionalidad de firewall de última generación Cisco Firepower a los entornos virtualizados, lo que permite que las políticas de seguridad coherentes sigan las cargas de trabajo en los entornos físicos, virtuales y de nube, y entre las nubes.

Dado que estas implementaciones están disponibles en un entorno virtualizado, la compatibilidad con HA no está disponible actualmente para NGFW. Por lo tanto, para proporcionar una solución de alta disponibilidad, el firewall de última generación (NGFW) de Cisco utiliza las funciones nativas de Azure, como los conjuntos de disponibilidad y el conjunto de ampliación de máquinas virtuales (VMSS), para que el NGFW tenga una alta disponibilidad y pueda hacer frente al aumento del tráfico a demanda.

Este documento se centra en la configuración del NGFW de Cisco para la escalada automática basada en diferentes parámetros en los que el NGFW se amplía o se reduce a DEMANDA. Esto abarca el caso práctico en el que el cliente necesita utilizar Firepower Management Center (FMC), que está disponible en el Data Center de alojamiento y es necesario para gestionar de forma centralizada todos los NGFW; además, los clientes no desean que FMC y FTD se comuniquen a través de IP pública para el tráfico de gestión.

Antes de profundizar en la configuración y la consideración del diseño, a continuación se muestran algunos conceptos que se deben entender bien y escribir en Azure:

Zona de disponibilidad: Una zona de disponibilidad es una oferta de alta disponibilidad que protege las aplicaciones y los datos frente a fallos del Data Center. Las zonas de disponibilidad son ubicaciones físicas únicas dentro de una región de Azure. Cada zona se compone de uno o más Data Centers equipados con alimentación, refrigeración y redes independientes.

VNET:  Azure Virtual Network (VNet) es el bloque de creación fundamental para su red privada en Azure. VNet permite que muchos tipos de recursos de Azure, como las máquinas virtuales de Azure (VM), se comuniquen entre sí de forma segura, a través de Internet y de las redes locales. VNet es similar a una red tradicional en el sentido de que funcionaría en su propio Data Center, pero trae consigo ventajas adicionales de la infraestructura de Azure, como la escalabilidad, la disponibilidad y el aislamiento. Todas las subredes de una VNET son accesibles entre sí de forma predeterminada, pero no sucede lo mismo con las subredes de diferentes VNET.

Conjunto de disponibilidad:  Los conjuntos de disponibilidad son otra configuración del Data Center que proporciona disponibilidad y redundancia de VM. Esta configuración dentro de un Data Center garantiza que durante un evento de mantenimiento planeado o no planeado, al menos una máquina virtual esté disponible y cumpla con el 99,95% de los SLA de Azure.

VMSS: Los conjuntos de escalado de máquinas virtuales de Azure permiten crear y administrar un grupo de máquinas virtuales con equilibrio de carga. El número de instancias de VM puede aumentar o disminuir automáticamente en respuesta a la demanda o a una programación definida. Los conjuntos de ampliación proporcionan una alta disponibilidad a las aplicaciones y le permiten administrar, configurar y actualizar de forma centralizada un gran número de VM. Con los conjuntos de ampliación de máquinas virtuales, puede crear servicios a gran escala para áreas como la informática, Big Data y cargas de trabajo de contenedores.

Aplicación de funciones: Azure Functions es un servicio en la nube disponible a demanda que proporciona toda la infraestructura y los recursos continuamente actualizados necesarios para ejecutar sus aplicaciones. Se centra en las partes de código que más le importan y Azure Functions se encarga del resto. Puede utilizar las funciones de Azure para crear API web, responder a los cambios de la base de datos, procesar flujos de IoT, administrar colas de mensajes, etc. En esta solución escalada automáticamente, Azure Function son varias solicitudes de API a FMC para crear objetos, registrar/anular el registro de FTDv, comprobar los parámetros, etc.

Aplicación lógica: Azure Logic Apps es un servicio en la nube que le ayuda a programar, automatizar y organizar tareas, procesos empresariales y flujos de trabajo cuando necesita integrar aplicaciones, datos, sistemas y servicios en empresas u organizaciones. Logic Apps simplifica la forma de diseñar y crear soluciones escalables para la integración de aplicaciones, la integración de datos, la integración de sistemas, la integración de aplicaciones empresariales (EAI) y la comunicación entre empresas (B2B), ya sea en la nube, in situ o ambas. Esta solución proporciona una secuencia lógica de las funciones que se ejecutarán para el funcionamiento de la solución escalada automáticamente.

En la actualidad, la solución AutoScale disponible para NGFW no proporciona un plan de gestión para comunicarse con la IP privada local en la red virtual y requiere una IP pública para intercambiar la comunicación entre Firepower Management Center y NGFW.

Este artículo tiene como objetivo resolver este problema hasta que la solución verificada esté disponible para las comunicaciones de Firepower Management Center y NGFW a través de IP privada.

Configurar

Para crear una solución de NGFW con escalabilidad automática, esta Guía de configuración se utiliza con varias modificaciones, de modo que se puedan abordar los siguientes casos prácticos:

• La aplicación de la función debe poder comunicarse con el segmento IP interno del cliente
• El equilibrador de carga no debe tener IP pública
• El tráfico de gestión entre NGFW y FMC debe intercambiarse a través del segmento de IP privada

Para crear una solución de NGFW con ampliación automática, con los casos prácticos mencionados anteriormente, debe modificarlos en los pasos mencionados en la guía oficial de Cisco:

1. Plantilla de Azure ARM

La plantilla ARM se utiliza para habilitar la automatización en Azure. Cisco ha proporcionado una plantilla ARM verificada que se puede aprovechar para crear una solución de escalado automático. Sin embargo, esta plantilla ARM disponible en Public Github crea una aplicación de funciones que no se puede crear para comunicarse con la red interna del cliente a pesar de que son accesibles a través de las rutas rápidas. Por lo tanto, es necesario modificar esto un poco para que la aplicación de función ahora puede utilizar, modo Premium en lugar de Modo de consumo. Por lo tanto, la plantilla ARM necesaria está disponible en https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git.

2. Función APP

La aplicación Function es un conjunto de funciones de Azure. La funcionalidad básica incluye:

• Comunicar/sondear métricas de Azure periódicamente.
• Supervise la carga de FTDv y active las operaciones de ampliación interna y externa.
• Registre un nuevo FTDv en el FMC.
• Configure un nuevo FTDv mediante FMC.
• Anular el registro (eliminar) de un FTDv escalado del FMC.

Como se ha mencionado en el requisito, las distintas funciones que se crean para la creación o eliminación de NGFW a demanda se realizan en función de la IP pública del NGFW. Por lo tanto, necesitamos ajustar el código C# para obtener IP privada en lugar de IP pública. Después de Tweaking el código el archivo zip para crear la función App está disponible en https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git

con el nombre ASM_Function.zip. Esto permite a la aplicación Functions comunicarse con los recursos internos sin tener la IP pública.

3. Aplicación lógica

La aplicación Auto Scale Logic es un flujo de trabajo, es decir, un conjunto de pasos en una secuencia. Las funciones de Azure son entidades independientes y no pueden comunicarse entre sí. Este orquestador secuenciará la ejecución de estas funciones e intercambiará información entre ellas.

• La aplicación lógica se utiliza para organizar y pasar información entre las funciones de Auto Scale Azure.
• Cada paso representa una función de Escala automática de Azure o una lógica estándar integrada.
• La aplicación lógica se entrega como un archivo JSON.
• La aplicación lógica se puede personalizar mediante la GUI o el archivo JSON.

Nota: Los detalles de la aplicación lógica disponibles en https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git deben modificarse cuidadosamente y estos elementos deben sustituirse por detalles de despliegue, nombre de FUNSTIONAPP, nombre del GRUPO DE RECURSOS e ID DE SUSCRIPCIÓN.

Diagrama de la red

Esta imagen muestra cómo fluye el tráfico entrante y saliente dentro de un entorno de Azure a través de NGFW.

Configuraciones

Ahora cree los diversos componentes necesarios para una solución con escalabilidad automática.

1. Crear componentes de Lógica de escalado automático.

Utilice la plantilla ARM y cree VMSS, Logic APP, Function APP, App Insight y Network Security Group.

Desplácese hasta  Home > Create a Resource > Search for Templatey, a continuación, seleccione  Template Deployment . Ahora haga clic en  Create y cree su propia plantilla en el editor.

2. Haga clic en  Save .

Realice los cambios necesarios en esta plantilla y haga clic en  Review + create .

3. Esto crea todos los componentes bajo el grupo de recursos mencionado.

4. Inicie sesión en la URL.

Cargue el archivo ASM_Function.zip y  ftdssh.exe a site/wwwroot/ (es obligatorio cargarlo en la ubicación especificada Función App no identifica varias funciones).

Debería ser como esta imagen:

 

5. Proteja el  Function app > Function. Debería ver todas las funciones.
   
   

6. Cambie el permiso de acceso para que VMSS pueda ejecutar las funciones dentro de la aplicación de funciones. Desplácese hasta  -vmss> Access Control (IAM) > Add role assignement . Proporcionar a este colaborador de VMSS acceso a  -function-app .

 

Haga clic en  Save.

7. Desplácese hasta  Logic App > Logic Code  vea y cambie el código lógico con el código disponible en https://github.com/CiscoDevNet/cisco-ftdv/tree/master/autoscale/azure/NGFWv6.6.0/Logic%20App. Aquí, la suscripción de Azure, el nombre del grupo de recursos y el nombre de la aplicación de la función deben ser reemplazados antes de su uso, no permite guardar correctamente.

8. Haga clic en  Save. Desplácese hasta Descripción general de la aplicación lógica y Habilitar  Logic App.

Verificación

Una vez que se habilita la aplicación lógica inmediatamente, comienza a ejecutarse en el intervalo de 5 minutos. Si todo está configurado correctamente, verá que las acciones desencadenadoras se ejecutan correctamente.

Además, la VM se crea en VMSS.

Inicie sesión en FMC y compruebe que FMC y NGFW están conectados a través de IP privada FTDv:

Al iniciar sesión en la CLI de NGFW, verá lo siguiente:

Por lo tanto, FMC se comunica con NGFW a través de la subred VPN privada de Azure.

Troubleshoot

 A veces, Logic App falla al crear un nuevo NGFW. Para solucionar estas condiciones, se pueden seguir estos pasos:

1. Compruebe si la aplicación de lógica se está ejecutando correctamente.

2. Identifique la causa del error. Haga clic en el disparador fallido.

 

Intente identificar el punto de fallo a partir del flujo de código. En esta imagen, está claro que la lógica de ASM falló porque no pudo conectarse a FMC. A continuación, debe identificar por qué FMC no era accesible según el flujo dentro de Azure.