Continuamos con la serie de artículos, sobre equipos de seguridad perimetral, esta vez explorando la historia de Cisco y sus controvertidos FIREPOWER FTD, y cómo manejan el tráfico que llega hasta ellos.
Un poco de contexto histórico: Cisco, sin lugar a dudas, es uno de los pilares fundamentales en la creación y expansión global de Internet. Desde los primeros tiempos de la UFINET hasta la icónica DARPANET, ha transcurrido un largo camino. No obstante, es relevante recordar que los primeros routers que allanaron el terreno para lo que hoy conocemos como Internet fueron cortesía de Cisco.
Asimismo, Cisco ha dejado una huella indeleble en la definición de múltiples protocolos. Permíteme compartir una anécdota que suelo mencionar en alguna ponencia, como la que presenté en Rootedc0n de este 2023 junto a mi colega David Marugán (@radiohacking): En un almuerzo en 1989, Kirk Lougheed de Cisco y Yakov Rekhter de IBM, plasmaron en el reverso de una servilleta lo que con el tiempo se convertiría en el lenguaje común entre los routers que gestionan sistemas autónomos en Internet: el protocolo de enrutamiento de paquetes de routers de frontera o BGP (Border gateway protocol).
Las enormes redes troncales de Internet de los principales proveedores, como AT&T o Level3, continúan confiando en una gran cantidad de conmutadores y routers de Cisco. Aunque la saga completa de los proveedores y las rutas principales merece su propio capítulo, retengamos que Cisco estuvo presente en los albores de este mundo de conectividad. Gran parte de lo que hoy conocemos y podemos lograr en redes y con el protocolo TCP/IP se debe a Cisco Systems.
Ahora bien, después de esta introducción, ahondaré en la evolución de las familias de firewalls que este fabricante ha desarrollado. En 1994, la empresa Network Translation Inc. marcó un hito al crear uno de los primeros firewall que al poco tiempo serían de Cisco, los famosos Cisco PIX. Sin embargo, fue hasta un año después que Cisco adquirió dicha empresa, y el sistema operativo Finesse fue renombrado como PIX OS. Este firewall, un cortafuegos de capa 4, ofrecía inspección de protocolos básicos como SIP o H323. Aprovechando el código de este primer firewall, Cisco lanzó el primer balanceador de la historia, el LocalDirector.
Avancemos unos 10 años, hasta 2005. Cisco renueva su línea PIX y presenta en el mercado los cortafuegos Appliance Adaptive Security (ASA). Inicialmente, estos heredaron el sistema operativo PIX OS, aunque más adelante fueron actualizados a un nuevo sistema basado en Linux llamado LINA. Mantén en mente este acrónimo, ya que tendrá relevancia mas adelante. Los ASA también compartieron este sistema operativo con los IPS 4200 y los concentradores VPN 3000.
Finalmente, en 2008, el soporte para el sistema PIX OS llegó a su fin y fue retirado. No obstante, en el código de LINA hasta el día de hoy, aún quedan vestigios del sistema PIX OS.
Por otro lado Martin Roesch, desarrolla en 1998 un sistema IDS de código abierto que permite realizar capturas de trafico de red y analizarlas, este sistema se denomina SNORT, en el año 2001 Martin funda la empresa Sourcefire, y comienza a comercializar su Snort en formato appliance bajo licencias de subscripción, convirtiendo este sistema IPS en un referente en el mercado, sourcefire compra en 2007 ClamAV y lo integra en su sistema de firmas, lo que permite disponer de una mayor visibilidad de amenazas, recordemos que es 2007, cuando no había ransomware ni nada parecido y se funcionaba con firmas estáticas., en 2011 Sourcefire adquiere Immunet y se empieza a utilizar inteligencia en la nube, de esta forma la inteligencia de las sondas IPS pasa a estar fuera de los dispositivos de manera estática y se puede empezar a usar inteligencia en tiempo real contra la nube, gran parte de los ingenieros que desarrollaron Inmunet, hoy son parte de TALOS de Cisco, gente muy buena en lo suyo.
Algo que poca gente conoce, es que Cisco intento comprar Checkpoint y Barracuda a comienzos de la década de 2010, y dado que no se pudo realizar estas comprar, finalmente Cisco adquirió en 2013 SourceFire, y a partir de aquí cambio la historia de los dispositivos de seguridad Cisco.
Los Cisco Asa tuvieron que ir migrando su software poco a poco a un nuevo código que integraba Snort , aunque Cisco daba la posibilidad de mantenerlos en LINA pero perdiendo las capacidades que proporcionaba la integración del código de Sourcefire en los ASA, al principio fue un poco frankenstein, era como tener dos maquinas en una, podías saltar de un sistema al otro por comandos, y hacerlos funcionar bien no era fácil, y también tenían problemas de rendimiento. por un lado teníamos ASA con LINA y por otro lado la capa de Sourcefire con su IPS, con lo que el trafico se analizaba dos ves o más con la consiguiente perdida de rendimiento en los equipos.
Cisco decidió lanzar en 2018 una nueva gama de equipos denominada Firepower Threat Defense o FTD, la cual integraba de manera nativa las funcionalidades de PIX OS y LINA en en código de FTD, las primeras versiones daban muchos problemas de rendimiento, pero a partir de la versión 6.7 ya se empezó a estabilizar todo el sistema y se comenzó a ver el potencial de estas integraciones, pero el camino fue muy largo y Cisco tuvo muchos problemas reputacionales debido a problemas con equipos Firepower, a lo que hay que sumar la aparición de un player como Palo Alto Networks, el cual le comió un buen trozo de la tostada de la seguridad perimetral, pero esa es otra historia.
Ya con los Firepower en el mercado, vamos a tratar de explicar como procesan en trafico y como Cisco logro la integración de las funciones de IPS de Sourcefire con las de ASA/PIX OS.
A groso modo sin entrar en detalle el flujo de trafico de un paquete entrante en un Firepower es este,
El paquete ingresa primero al motor de ASA, que verifica si es nuevo o pertenece a una sesión ya establecida. Si se trata de una sesión establecida con un Xlate, se analiza en función de las decisiones tomadas por el motor de Snort en los paquetes iniciales de dicha conexión. En este escenario, se podría aplicar una política de Fastpath y enviarlo directamente a la cola de salida, sin pasar por el motor de Snort.
No obstante, si se trata de un paquete nuevo sin Xlate y aún no ha sido controlado por el FTD (recordemos que es un firewall stateful), entonces debe atravesar el motor de inspección de Snort. Este proceso implica cumplir con las políticas definidas para ese paquete, las cuales se basan en direcciones, puertos, protocolos o aplicaciones previamente establecidas en las políticas de seguridad.
Sin embargo, la realidad es un tanto más compleja. Siguiendo la línea que exploramos en el capítulo anterior acerca de los dispositivos Palo Alto, al adentrarnos en los detalles, se ve que Cisco mantiene un enfoque similar. Por un lado, persiste la presencia de LINA, que se encarga de gestionar tareas como el tráfico, enrutamiento, VPN, QoS, NAT y el plano de control y gestión. Esto incluye la aplicación de filtros de capa 3/4 y más.
No obstante, existe una capa superior que aprovecha el poder de SNORT. Al dirigir el tráfico hacia este motor, se abren muchas posibilidades, como la detección de aplicaciones, el descifrado de SSL, la inspección en capa 7 y la aplicación de políticas de identidad, QoS, así como el descubrimiento de redes y vulnerabilidades. También se incluyen políticas de control de filtración de archivos y la implementación de reglas de Snort. Esto transforma al Firepower en un Firewall de Nueva Generación (NGFW) de capa 7, capaz de brindar seguridad a lo largo de toda la pila del protocolo TCP/IP.
Es importante destacar que los Firepower ofrecen la capacidad de realizar capturas de tráfico antes, durante y después del motor de Snort. En otras palabras, esto significa que puedes capturar tráfico tanto en el motor LINA como en el motor de Snort. Esta función te permite determinar qué parte del equipo bloquea o permite el flujo de paquetes, y cómo se manejan en su trayecto. Es una herramienta que he utilizado en numerosas ocasiones al implementar estos equipos, y resulta invaluable para identificar problemas como asimetrías en situaciones con port-channels o dificultades en los interfaces físicos. Inicialmente, surgían desafíos con las ópticas de los interfaces de fibra, pero es un obstáculo que ya ha sido superado.
Más adelante, te explicaré cómo se gestiona estos Firepower desde el FirePower Management Center, que actúa como la consola de gestión centralizada, algo similar a lo que ofrece el Panorama de Palo Alto.
En resumen, los Firepower tienen un lugar especial en mi opinión. Si bien es cierto que han tenido ciertas limitaciones que están abordando, es un equipo que me agrada. Por ejemplo, para entornos no demasiado grandes, permite consolidar el terminador de túneles, el IPS y el firewall en una sola máquina. Esto se traduce en ahorros en licencias a la larga. Otra característica sobresaliente es la posibilidad de implementarlos en modo Failover o en un cluster con más de dos nodos. Esto distribuye la carga entre las máquinas según nuestras necesidades, permitiendo incrementar el rendimiento de nuestras redes sin necesidad de interrupciones. En definitiva, los Firepower son una herramienta poderosa con una flexibilidad notable.
Nota: Este artículo no cuenta con patrocinio por parte del fabricante y se basa en más de 20 años de experiencia trabajando con equipos de seguridad Cisco, en la siguiente entrega veremos como gestionan el tráfico de red equipos Fortigate de Fortinet, nos leemos en la siguiente.
