La importancia de las pruebas de restauración (I)

Habitualmente, cuando realizamos una auditoría de seguridad es muy poco común encontrarse con empresas que no realizan copias de seguridad de sus sistemas, siendo lo común encontrar empresas que realizan copias periódicas (ya sea mediante procesos manuales o software dedicado). No obstante, muchas empresas se quedan ahí; creen que teniendo copia de seguridad de sus sistemas están protegidos ante un desastre, y no nos equivoquemos, en parte, tienen razón. Sin embargo, nada es seguro al 100%, nuestro sistema no iba a ser menos, y en caso de que lo fuera, tranquilos que aparecería Murphy darnos más dolores de cabeza.

Puesto que en nuestra política de copias no podemos incluir a Murphy, tenemos que pensar que realizando copias periódicas, por ejemplo en cinta, manteniéndolas en varias ubicaciones (alguna de ellas fuera de la oficina), protegidas de su deterioro, controlando la caducidad de los soportes y realizando pruebas de restauración periódicas de varios sistemas, estamos protegidos. Y sí, todo esto es correcto, aunque lo ideal sería además, mantener todos nuestros sistemas replicados y sincronizados en un CPD de respaldo, pero claro, cuanto más azúcar más dulce, o dicho de otra forma, cuanto mejor es la solución, más cara de implementar resulta, por lo tanto, nos conformaremos con la situación anterior.

Este tipo de políticas de backup es habitual encontrarlas en empresas de mediano y gran tamaño, donde disponen de equipos para poder hacer pruebas de restauración o incluso sistemas virtuales donde levantar una imagen de un equipo suele ser algo trivial. No obstante, si llevamos este planteamiento a la electrónica de red, la visión es totalmente distinta. La mayor parte de las empresas no suele hacer copia de las configuraciones de sus equipos de comunicaciones (firewalls, switches, routers,..) salvo en contadas ocasiones, y éstas las hacen de forma periódica (mensualmente, trimestralmente), ya que ven muy complicado disponer de hardware donde restaurar la copia de seguridad y comprobar que todo el proceso es correcto.

Recientemente, he tenido la desgracia de encontrarme de frente con un problema de este tipo: una implantación de un cluster Firewall-1 de Checkpoint, con el propio firewall alta disponibilidad y del cual se realizan copias de seguridad periódicas. No obstante, ante un problema software del sistema de gestión del firewall, se ha detectado que las copias, aunque se realizaban periódicamente, no llevaban asociadas tareas de restauración debido al alto coste que supone duplicar los elementos de la infraestructura.

En este post y en los sucesivos, se va a realizar una pequeña descripción de Check Point Firewall-1, tratando de describir mínimamente las características principales y el proceso de recuperación del sistema de gestión realizado, contando únicamente con la información almacenada en el propio firewall, que como se podrá ver a continuación, difiere del resto de sistemas. Lógicamente, Firewall-1 dispone de herramientas propias de backup y restaurado de sus sistemas, por lo que partiremos de la premisa de que el dispositivo en funcionamiento posee la configuración actualizada, y la estación de gestión una copia obsoleta de la misma, no pudiendo recuperarla de las copias periódicas realizadas.

Introducción a FW-1

Firewall-1 es un Firewall desarrollado por la compañía israelí Check Point Software Technologies Ltd.. Firewall-1 se ejecuta sobre diferentes sistemas operativos, tanto Unix/Linux, como servidores Microsoft Windows, o incluso sobre appliances propietarios, por ejemplo la desarrollada por Nokia, cuyo sistema operativo (IPSO) esta basado en FreeBSD. En sus inicios, el sistema Firewall-1 funcionaba únicamente como sistema cortafuegos y concentrador VPN, no obstante, el sistema ha ido evolucionando con el paso del tiempo, convirtiéndose en un sistema UTM, el cual incluye módulos para el filtrado de contenidos, IPS (smartdefense) o QoS (Floodgate-1).

Arquitectura de FW-1

Firewall-1 posee una arquitectura modular basada en tres componentes:

  • Smart Clients: son un conjunto de aplicaciones para gestionar de forma gráfica la infraestructura global de seguridad. La principal aplicación es SmartDashboard, la cual gestiona las políticas de toda nuestra infraestructura.
  • SmartCenter Server: constituye la estación gestora de la infraestructura. Como tal, contiene todos los objetos definidos en el sistema (redes, hosts, servicios, horarios), la base de datos de usuarios, los registros de log del sistema y las políticas del sistema. Los objetos creados son comunes para todas las políticas de seguridad del sistema.
  • Enforcement Module: constituye el propio firewall que implementa la política de seguridad. Tiene dos componentes principales: Inspection Module y Security Server.

El funcionamiento de la arquitectura es sencillo: a través de la aplicación SmartDashboard, nos conectamos al SmartCenter Server donde definimos y almacenamos los distintos objetos y la política de seguridad. Finalmente, el SmartCenter Server realiza una compilación de la información y la distribuye entre los distintos Enforcement Module de la red.

SmartCenter Server define la política de seguridad en un lenguaje propietario llamado INSPECT y la representa como un ‘inspection script’. Dicho fichero es generado para cada Enforcement Module, donde el módulo de inspección (Inspection module) analiza el tráfico y realiza las acciones acorde a la política de seguridad.

Tipos de arquitecturas

Firewall-1 soporta dos tipos de arquitecturas, llamadas standalone y distributed:

  • Standalone: el SmartCenter Server y el Enforcement Module se ubican en el mismo sistema físico.
  • Distributed: el SmartCenter Server y el Enforcement Module residen en sistemas distintos.

De momento hasta aquí, estos son los conceptos básicos de FW-1. En la siguiente entrada veremos en detalle aspectos propios del backup y la recuperación del dispositivo: Backup del sistema, recuperación de objetos y recuperación de la política. Manténganse a la escucha, y si tienen algún comentario, estaré encantado de responderlos.

Trackbacks

  1. […] en el propio firewall, que como se podrá ver a continuación, difiere del resto de sistemas… (I) […]