07 dic 15 Automatización de despliegue y gestión de cortafuegos con Ansible

Estas últimas jornadas he estado trabajando en un sistema de automatización de despliegue de cortafuegos en Softlayer. Llevo un tiempo trabajando con cortafuegos Vyatta, que si bien son bastante prácticos para desplegarlos tanto sobre entornos virtuales como sobre máquinas físicas, adolecen de un grave problema: carecen de un sistema de gestión centralizado. Y cuando manejas del orden de medio centenar de cortafuegos, esto se hace especialmente necesario, no sólo para mantener un sistema homogéneo y manejable, sino también para evitar, en la medida de lo posible, fallos humanos.

¿Y cuál ha sido el sistema elegido para automatizar ciertas tareas de despliegue y gestión? Pues como no podía ser menos, ha sido Ansible. Hasta este momento he sido capaz de:

• Hacer un despliegue automatizado de la configuración inicial de cortafuegos vyatta en clúster a partir de cortafuegos individuales.
• Automatizar el desploegue y borrado de múltiples reglas en diferentes cortafuegos

Para ello, lo primero ha sido preparar un entorno de demo, que ha tenido casi más chicha que la propia configuracion con Ansible:

…que se compone de los siguientes elementos:

• Portátil: Mi propio portátil de trabajo. Actúa como entorno de virtualización basado en KVM. Su función como entorno de virtualización no es relevante en sí como elemento de testeo, pero sin él no sería posible realizar el despliegue del entorno. Sí es relevante su función como cliente de los servicios desplegados por el servidor CirrOS. Se le ha configurado una ruta estática para enrutar el tráfico a través de la IP .254 de la subred externa, que será la IP flotante del clúster de cortafuegos.
• Servidor CirrOS: Servidor extremadamente ligero (en torno a 32 MB de RAM y un procesador) que levanta servicios SSH y HTTP, este último mediante una simulación con NetCat, lo que también tiene su miga. En cuanto al servidor CirrOS, a los conocedores de entornos cloud como Openstack les sonará bastante, pero he conseguido hacer un despliegue en un entorno KVM convencional.
• Clúster de cortafuegos Vyatta: El clúster de cortafuegos Vyatta (bueno, en realidad VyOS, el fork software libre surgido cuando Brocade compró el proyecto original) actúa como cortafuegos entre las subredes interna y externa. En la fase inicial consiste en dos cortafuegos independientes, como una configuración básica de sus interfaces de red y poco más, con direcciónamiento .252 y .253. En esta fase, por lo tanto, el portátil no es capaz de conectar con el servidor CirrOS. El equipo vyatta1 actuará como maestro en la configuración VRRP, y el equipo vyatta2 actuará como esclavo.
• Ansible: Este servidor actúa como servidor de Ansible, como su propio nombre indica. Conecta con los dispositivos vyatta haciendo uso de clave SSH, por lo que -y esto es de lo mejor de Ansible- no necesita de ningún tipo de agente o plugin para realizar los despliegues de configuración o recogida de información desde los dispositivos.

Ansible -y esto no pretente ser una descripción exhaustiva de sus características, por lo que ruego se me perdone cualquier incorrección que pueda perpetrar- puede actuar bien enviando comandos únicos a los equipos administrados, bien haciendo uso de recetas (playbooks). Estas recetas consisten en un grupo de tareas, plantillas y parámetros que se combinan para realizar las labores de automatización de configuración y labores de gestión en los dispositivos:

• Tareas (task): Comando o grupo de comandos que realizan alguna acción en el dispositivo. Éstas pueden ser creadas en base a módulos predefinidos para simplificar su proceso de creación
• Plantillas (templates): Las tareas pueden hacer uso de plantillas para simplificar el proceso de configuración o gestión de los dispositivos. Estas plantillas, cuyas variables se completan haciendo uso de los valores asignados a los parámetros, se usan para crear al vuelo los scripts (o cualquier comando) que se quieran aplicar al dispositivo. Lo más interesante del asunto es que estas plantillas se pueden crear de manera bastante sencilla en base a scripts convencionales que ya se estuvieran utilizando para gestionar el dispositivo, simplemente reemplazando las variables del scripts por las variables propias de j2, que posteriormente, en tiempo de ejecución, serán sustituidas por los parámetros definidos en Ansible.
• Parámetros: Valores concretos de la configuración de los dispositivos a gestionar con Ansible, como por ejemplo el nombre del cortafuegos, la IP de una interfaz, o los valores de la VPN. Estos parámetros pueden ser definidos de múltiples maneras: usando un fichero de configuración global de parámetros, usando ficheros específicos para cada dispositivo (algo especialmente interesante para este caso), almacenando valores en tiempo de ejecución de los propios dispositivos gestionados o del entorno, o una combinación de estos métodos. Posteriormente, estos parámetros se usan para configurar los dispositivos, bien mediante tareas individuales o mediante plantillas.
• Dispositivos (hosts): Conjunto de servidores que queremos administrar. Pueden ser etiquetados para aplicarle sólo ciertas tareas (por ejemplo, los dispositivos individuales de las parejas de vyattas pueden ser etiquetados como maestro y esclavo para sólo aplicar a cada uno de ellos la configuración que corresponda) que sean de aplicación para el tipo de disposito gestionado.

Una vez configurado el entorno, el recetario, las plantillas y parámetros, la configuración quedó lista para ser aplicada a los dispositivos. Las tareas de un recetario pueden ser ejecutadas de manera secuencial o en una sucesión específica, usando para ello las oportunas etiquetas. En mi entorno, y hasta el momento, he definido tres tipos de tareas:

• Despliegue inicial: Realiza el despligue inicial de la configuración a la pareja de vyattas para convertirlos en un clúster y realizar las configuraciones básicas de seguridad y gestión requeridas. En el entorno de demo, una vez realizada esta tarea, queda configurada la interfaz flotante en ambas subredes, realizado NAT y el enmascaramiento del tráfico de la interfaz interna a la externa, y permitido el tráfico ICMP entrante de la interfaz externa a la interna. Todo ello permite que el portátil haga ping al servidor, pero no pueda acceder a los servicios.
• Añadir reglas: Esta tarea realiza un despliegue de política a los cortafuegos. En concreto, permite el tráfico por los puertos 22 y 80 TCP al servidor CirrOS.
• Borrado de reglas: Permite eliminar las reglas anteriormente definidas

Un ejemplo de ejecución de Ansible para este entorno sería el siguiente:

i82hisaj@debian:~/ansible/vyos# ansible-playbook main.yml -t initial

PLAY [all] ********************************************************************

GATHERING FACTS ***************************************************************
ok: [192.168.122.252]
ok: [192.168.122.253]

TASK: [initial-config | upload script for configuring description] ************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [initial-config | run script for configuring description] ***************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [initial-config | debug var=desc_value.stdout_lines] ********************
ok: [192.168.122.253] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}
ok: [192.168.122.252] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}

PLAY RECAP ********************************************************************
192.168.122.252 : ok=4 changed=2 unreachable=0 failed=0
192.168.122.253 : ok=4 changed=2 unreachable=0 failed=0

i82hisaj@debian:~/ansible/vyos# ansible-playbook main.yml -t add

PLAY [all] ********************************************************************

GATHERING FACTS ***************************************************************
ok: [192.168.122.253]
ok: [192.168.122.252]

TASK: [rules | retrieve Description for a firewall] ***************************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [rules | upload script for configuring description] *********************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [rules | run script for configuring description] ************************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [rules | debug var=desc_value.stdout_lines] *****************************
ok: [192.168.122.252] => {
"desc_value.stdout_lines": [
"Outside In"
],
"item": ""
}
ok: [192.168.122.253] => {
"desc_value.stdout_lines": [
"Outside In"
],
"item": ""
}

PLAY RECAP ********************************************************************
192.168.122.252 : ok=5 changed=3 unreachable=0 failed=0
192.168.122.253 : ok=5 changed=3 unreachable=0 failed=0

i82hisaj@debian:~/ansible/vyos# ansible-playbook main.yml -t delete

PLAY [all] ********************************************************************

GATHERING FACTS ***************************************************************
ok: [192.168.122.252]
ok: [192.168.122.253]

TASK: [initial-config | debug var=desc_value.stdout_lines] ********************
ok: [192.168.122.252] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}
ok: [192.168.122.253] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}

TASK: [rules | upload script for deleting rule] *******************************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [rules | run script for configuring description] ************************
changed: [192.168.122.253]
changed: [192.168.122.252]

TASK: [rules | debug var=desc_value.stdout_lines] *****************************
ok: [192.168.122.253] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}
ok: [192.168.122.252] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}

PLAY RECAP ********************************************************************
192.168.122.252 : ok=5 changed=2 unreachable=0 failed=0
192.168.122.253 : ok=5 changed=2 unreachable=0 failed=0


Algunas ideas hasta el momento:

• Desafortunadamente no existe ningún módulo oficial que permita hacer la administración simplificada de cortafuegos vyatta, lo que significa que todo el trabajo de definir la automatización de tareas ha de realizarse desde cero, en base a scripts y configuraciones básicas de Ansible.
• Afortunadamente, el sistema de interacción de Ansible es lo suficientemente flexible para permitir la conversión sencilla de scripts previamente existentes a plantillas J2, lo que permite -en mi caso- aprovechar bastante trabajo previo ya existente.
• Existen interesantes posibilidades de conectar Ansible con sistemas de gestión vía web, como es el caso del proyecto Semaphore.

En resumen, si bien Ansible este caso requiere de bastante trabajo para poder realizar de manera efectiva la automatización del despliegue y gestión de cortafuegos (vyatta, en este caso), las ventajas que proporciona y el trabajo final que ahorra hacen que valga la pena. Como diría nuestro amigo Barney, en este caso nos encontramos claramente por encima de la diagonal Vicky Mendoza:

Etiquetas: ansible, cirros, kvm, vyatta, vyos