Tradicionalmente, las infraestructuras de red de datos han estado basadas en arquitecturas de tres capas: core, distribución y acceso, siendo esta última la que soporta las conexiones de los sistemas finales. Este tipo de arquitecturas desde un punto de vista únicamente de gestión son relativamente sencillas: el departamento de comunicaciones es quien se encarga del acceso a red (configuración, administración,etc), y el personal de sistemas administra todos los aspectos relativos al sistema final: usuarios, aplicaciones, recursos, etc.

A medida que los sistemas evolucionan, y actualmente con las distintas técnicas de virtualización en auge, esta administración se vuelve más compleja puesto que ya no tenemos un modelo de gestión delimitado; pensemos en un sistema blade con un switch empotrado en el propio chasis, un sistema VMWare usando su vswitch para permitir la conectividad de las máquinas virtuales, o el uso de una arquitectura distribuida usando vd; en cualquiera de los casos, ¿quién administra estos equipos de comunicaciones? Habitualmente, el administrador de red no suele llegar a este nivel, quedando en manos del administrador de sistemas (o de virtualización) la gestión del dispositivo, el cual es posible que no disponga de los mismos conocimientos de red que el personal dedicado.

Recientemente he asistido a un taller de Cisco sobre Unified Computing donde Cisco propone varias soluciones a este problema mediante la tecnología VN-LINK. Esta trata, salvando la distancia, de mapear un puerto de red a cada máquina virtual, de forma que el administrador de red gestiona todos los puertos de la red por igual, usando las mismas herramientas, pudiendo crear perfiles de red (port profile) que más tarde el administrador de virtualización podrá asignar a los sistemas finales. Con este propósito, también han creado la alianza VCE, formada por VMWare, Cisco y EMC (véase la noticia en idg.es).

Para solucionar este problema, Cisco dispone de varias soluciones basadas en el switch de la serie Nexus 1000V (conmutación virtual sobre el hypervisor o sobre la tarjeta física) o Hypervisor bypass, usado en sistemas críticos que requieren gran rendimiento. El sistema Cisco Nexus 1000V es un sistema de conmutación basado en Cisco NX-OS, formado por dos componentes, la supervisora, desde la cual se configuran y gestionan los parámetros de red de las máquinas virtuales, y el software instalado sobre VMWare que se encarga de la propia conmutacion. Este sistema sustituye al conmutador virtual proporcionado por VMWare, mejorando el modelo de gestión ya que podemos administrarlo con las mismas herramientas que el resto de switches de nuestra red, y mejorando la funcionalidad, puesto que disponemos de todas las opciones de configuración de los switches habituales, como pueden ser Private VLan, Port Security, DHCP Snooping, etc,

Para llevar a a cabo esta mejora, Cisco ha lanzado su estrategia UCS (Unified Computing System) agrupando mediante un único sistema, procesamiento, almacenamiento y virtualización. Los sistemas basados en UCS disponen de un sistema completo de servidores distribuidos y chasis (en formato blade o rack), que se interconectan y gestionan desde un único punto de red, permitiéndonos disponer de sistemas llamados Stateless Server, es decir, con posibilidad de separar el propio servidor (sistema operativo y configuración) del hierro sobre el que corre, de forma que podremos crear perfiles de servicio (Service Profile) con los datos de hardware (interfaces de red, interfaces HBA, parametros de BIOS, etc) y llevar el sistema a otro hardware distinto, manteniendo toda la configuración.

Como comentó Rafa en su post de la semana pasada, empresas como CISCO están realizando grandes avances tecnológicos, y aunque no sea tan futurista como la telepresencia en 3D, seguro que la tecnología UCS da mucho que hablar. Desconozco las soluciones similares de otros fabricantes, aunque me costa que Juniper e IBM trabajan en algo similar. ¿Algún lector tiene más información al respecto?

Cuando leemos prácticamente cualquier libro de seguridad de las comunicaciones, aparece catalogado como ataque de denegación de servicio (DoS) el conocido como SYN flood. Este ataque se basa en el esquema de funcionamiento del protocolo a tres vías usado para establecer conexiones TCP. Sin entrar en los detalles del funcionamiento del protocolo, podemos resumir el propio ataque como una solicitud de conexión (SYN) por parte del cliente (posiblemente spoofeado), contestada por el servidor (SYN/ACK), pero sin confirmación de la respuesta por parte del propio cliente (ACK). Esta situación hace que el servidor mantenga una serie de conexiones abiertas en la cola Backlog (consumiendo recursos), pudiendo llegar a impedir nuevas conexiones legítimas al sistema hasta que las conexiones sean finalizadas o venza el timeout asociado.

En esta entrada vamos a hablar de una medida de contención para este ataque proporcionada por Check Point llamada SYNDefender.

SYNDefender es una característica de SmartDefense (herramienta de protección ante ataques) que nos ayuda a protegernos de ataques TCP SYN flood basada en la interceptación de los paquetes SYN, que media en los intentos de conexión antes de que éstos puedan alcanzar el sistema final, siendo posible configurar la funcionalidad de forma global o por gateway. SYNDefender tiene dos modos de funcionamiento principales: el modo relay y el modo SYN Cookie.

En el modo relay, nos aseguramos que la conexión TCP es completa antes de enviarla al sistema final; el gateway intercepta el paquete SYN destinado al servidor no dejándolo llegar a su destino, sino que por el contrario, envía un paquete SYN/ACK al cliente, activando un temporizador de reset. Si el cliente envía el ACK y completa de esta forma la conexión, el propio gateway inicia el establecimiento de conexión hacia el servidor (traduciendo números de secuencia), y una vez completada, comienza el flujo de datos. Si el gateway no recibe el paquete ACK por parte del cliente antes de que el temporizador finalice o recibe un paquete RESET (cuando no era lo que esperaba), finaliza la conexión inmediatamente.

En el modo cookie, cuando el cliente envía un paquete SYN al servidor, el gateway intercepta el paquete y le contesta un SYN/ACK con cookie. Después de recibir el paquete ACK por parte del cliente, el cual completa el establecimiento de la conexión, SYNDefender transforma el paquete ACK en un paquete SYN, registra la conexión en la tabla de conexiones, y la envía hacia el servidor, procesándose de la misma manera que en el modo relay.

Aparte de estos dos, en Check Point existen otros modos de funcionamiento, los cuales están soportados en otras versiones de la plataforma, como son el modo Gateway o Passive SYN Gateway.

Como acabamos de ver, y como nos indicaban en los comentarios hace unos días sobre los números de secuencias TCP los fabricantes de sistemas cortafuegos cada vez más implementan soluciones para detectar y filtrar patrones de ataque conocidos, desviaciones de los protocolos de red, etc, dotando a sus sistemas de mecanismos inteligentes y proactivos, los cuales nos permiten analizar el tráfico en las capas superiores de la pila OSI para poder detectar actividad sospechosa. En futuras entradas seguiremos informando de estas y otras tecnologías que sirven para hacer a las empresas más seguras y darnos a los administradores de red más quebraderos de cabeza ;)

Como vimos en el anterior post, la manera habitual analizar el tráfico de nuestra red pasa por configurar la interfaz de uno de nuestros switches en modo SPAN (o R-SPAN) y reenviar el tráfico para su posterior análisis mediante un analizador de red o un IDS.

Aunque esta solución suele ser la habitual, y suficiente en la mayoría de casos, presenta una serie de problemas, como pueden ser la limitación del número de interfaces (o VLANs) que podemos configurar en modo SPAN, y la carga de CPU asociada a la captura y envío del tráfico, incluyendo la carga generada al propio analizador de red, puesto que recibe todo el tráfico que atraviesa la interfaz, sea interesante o no para nuestra captura.

[Read more…]

Durante el día de ayer y hoy, se celebra en la Universidad Politécnica de Valencia el congreso ISACA Valencia 2010 organizado por el capítulo de Valencia de ISACA, que lleva como título “Esquema Nacional de Seguridad e Interoperabilidad y e-Administración”. Durante la jornada de ayer se realizaron una serie de conferencias dentro del marco del Esquema Nacional de Interoperabilidad y Seguridad, en las que S2 Grupo participó como ponente, y de las cuales, procedemos a realizar un pequeño resumen introductorio a continuación.

Protección de Marca

Nuestro compañero Antonio Villalón (S2 Grupo) planteó diversas cuestiones relativas a la reputación, tanto a nivel personal como a nivel de empresa, reflexionando acerca de los problemas actuales, los mismos que hace años pero elevados a la enésima potencia, debido al acceso global a la información donde todo el mundo puede opinar (en ocasiones amparados por una sensación de anonimato en la red), y recalcando que mi reputación no es algo que dependa únicamente de mí. Esta situación ha generado nuevos patrones de ataque no sólo sintácticos (virus, DoS, troyanos, etc), sino también semánticos (daño por la interpretación de la información que hace el ser humano). Para acabar, Toni nos ha sugerido que busquemos nuestro nombre en Internet para ver qué información existe de nosotros.

[Read more…]

A la hora de verificar el estado de nuestra red o en caso de detectar alguna anomalía, es práctica habitual hacer uso de un analizador de protocolos de red. Una de las herramientas más utilizadas para llevar a cabo esta función es Wireshark, la cual nos proporciona una forma cómoda y gráfica (aunque para aquellos de la línea “clásica”, dispone de línea de comandos) de capturar los paquetes de red para su análisis.

Normalmente, para llevar a cabo esta tarea, debemos configurar una interfaz del switch de nuestra red en modo monitor (mirroring o SPAN), habitualmente la que nos conecta con el firewall, y configurar el switch para que reenvíe todo el trafico a un equipo donde tenemos el analizador; esta configuración también la podemos encontrar en implantaciones de NIDS, puesto que a grandes rasgos, trabajan de forma similar.

Para la captura de tráfico de nuestra red, existen no obstante otras opciones que se basan en la captura realizada en los propios firewalls de nuestra red, o si estamos llevando a cabo el análisis de una gran red, es posible que ésta disponga de equipos Cisco con sistema Cisco NX-OS (antiguo SAN-OS), un sistema operativo diseñado para entornos de datacenter. Estos sistemas nos pueden facilitar la tarea de análisis de trafico en el plano de control (control plane), es decir, el tráfico que mantiene la funcionalidad de la red (protocolos de enrutamiento, gestión de infraestructura de red,.. ).

El sistema Cisco NX-OS se encuentra implantado en equipos de comunicaciones de ultima generación, como por ejemplo, las series Cisco Nexus 7000 (o Nexus 5000), una plataforma modular altamente escalable que soporta velocidades de 10Gigabit Ethernet (e incluso 100Gbps), pensada para unificar entornos LAN y SAN, convirtiendo el equipo Nexus en múltiples switches lógicos, los cuales ejecutan procesos totalmente independientes. Para facilitar tareas como el análisis de red, estos sistemas incorporan el comando Ethanalyzer, basado en la version 1.0.8 de Wireshark, que nos permite de forma cómoda capturar y decodificar los paquetes de red, usando el mismo tipo de filtros que la herramienta original, pudiendo salvar las distintas capturas para analizarlas posteriormente.

Aunque debido a su coste es poco probable que la mayoría de nuestros lectores dispongan de un sistema como los descritos, para aquellos que tengan la suerte de poder administrarlos, Ethanalyzer puede hacerles la vida un poco más fácil. Los demás tendrán que conformarse con la versión de servidor de Wireshark, que no es poco.

Como vimos hace un tiempo, el tiempo de reacción ante un ataque se vuelve un proceso crítico para nuestra organización. Si en la entrada anterior (orden shun), vimos como realizar un filtrado, tanto de las conexiones actuales como de futuras conexiones en un firewall Cisco ASA, hoy veremos como realizar el mismo proceso en un Firewall-1 de Check Point.

Antes de ver las opciones que FW-1 nos ofrece para el filtrado de conexiones, debemos tener en cuenta qué sucede cuando aplicamos la política en nuestro Gateway. Habitualmente, es normal que los firewalls mantengan las conexiones establecidas y denieguen (si así lo indica la política), las nuevas conexiones. Sin embargo, en Firewall-1 esta forma de funcionamiento es configurable, por lo que dentro de las opciones ‘connection persistence’ del propio gateway podemos encontrar las siguientes:

• Keep all connections: mantiene todas las conexiones de control y datos hasta que finalizan. La nueva política únicamente se aplica a las nuevas conexiones.
• Keep data connections: mantiene las conexiones de datos hasta que finalizan. Las conexiones de control son finalizadas.
• Rematch connections: todas las conexiones no permitidas por la nueva política son finalizadas.

Por lo tanto, podríamos llegar a filtrar las conexiones sospechosas aplicando una nueva política de seguridad y comprobando de nuevo, todas las conexiones usando la nueva política de seguridad. Tras ver las distintas alternativas posibles de instalación de la política, vamos a realizar un filtrado más rápido sobre las conexiones mediante la aplicación Smartview Tracker (también podríamos usar el comando fw sam del propio Gateway)

Smartview Tracker es la herramienta de Check Point que nos permite la supervisión en tiempo real de la red. Contiene un módulo de gestión de logs de los distintos gateways, registros de auditoria y control de cambios, etc. Al arrancar la herramienta podemos distinguir tres pestañas: Log, Active y Audit. Active es la pestaña que nos interesa, puesto que nos permite ver todas las conexiones activas en el firewall donde cada una de ellas tiene un identificador de conexión (Conn. ID).

Al seleccionar la pestaña Active, y una vez tenemos a la vista todas las conexiones (es posible que afecte al rendimiento del sistema), podemos situarnos en una de ellas y mediante el menú Tools -> block intruder seleccionar las distintas opciones de filtrado que nos proporciona el sistema. Dentro de esta ventana nos podemos encontrar el ámbito del filtrado (conexiones con la misma IP origen, la misma IP destino, o el grupo IP origen – IP destino – servicio), el tiempo de filtrado (infinito o un número determinado de minutos) y los módulos donde podemos realizar el filtrado.

Como vimos en la entrada de introducción a Firewall-1, por debajo del Smartcenter Server, encontramos los distintos gateways (firewall), por lo tanto, nuestras acciones se verían reflejadas en ellos; al realizar el filtrado anterior, el Gateway internamente modificará su base de datos SAM (Suspicious Activity Monitoring), concretamente en la tablas sam_requests (información acerca del origen, destino y servicio filtrado) y sam_blocked_ips (intentos de conexión filtrados y el tipo de servicio), las cuales podríamos comprobar mediante los comandos fw tab –t sam_requests y fw tab –t sam_blocked_ips.

Con esto, tenemos los conceptos básicos para el filtrado de conexiones en los dos de los sistemas FW-1 más utilizados actualmente: Cisco ASA y Checkpoint FW-1. Si tienen alguna duda o cuestión, no tienen más que dejarla en los comentarios.

Normalmente, cuando alguien adquiere un nuevo software y procede a instalarlo, la primera acción que se suele llevar a cabo es revisar la documentación existente en el CD y una vez revisada, proceder a instalar el software.

Son ‘raras’ las veces en que, oculto en el software a instalar, viene alguna sorpresa no deseada y más raro parece, cuando el CD original, en lugar de contener el software que hemos adquirido, contiene algo totalmente distinto. En nuestro caso, nos hemos llevado una sorpresa al abrir varios CDs de Cisco Systems originales y comprobar que, en lugar de contener el software cliente de VPN que indicaban, contienen un total de 12 tracks de musica mexicana de Diego Rivas ‘El Compa’.

Investigando por Internet, hemos encontrado un post del 2008 donde ya hablaban de esta ‘sorpresa’ y donde indican que los CDs erróneos pueden ser identificados por tener el codigo “MX21511/4”. También hemos podido comprobar que en el propio CD aparece una anotación que indica ‘Recorded in Mexico’ en lugar de ‘Recorded in USA’; lógico, tratándose de música mexicana. Otro ejemplo curioso que comentan en esta página, es un caso anterior donde Linksys imprimió en las cajas de sus productos como número de soporte el numero de una linea erótica en lugar del teléfono de soporte tecnico real.

Esta anécdota debe hacernos reflexionar acerca de la seguridad del software que adquirimos y no solo pensar que, por ser un CD adquirido de forma legal y de una gran empresa como en este caso, estamos a salvo de que contenga un posible troyano, un virus, o vaya usted a saber qué.

(Continuamos hoy con la entrada de ayer, sobre la importancia de las pruebas de restauración en dispositivos de red)

Backup del sistema

Según nuestra política de seguridad, lo habitual es que se realicen copias de seguridad periódicas de los sistemas, incluyendo por supuesto, la electrónica de red, de forma que, ante una caída, sea posible restaurar el sistema en el mínimo tiempo posible para garantizar el menor impacto a la organización. El proceso de backup del sistema depende del operativo sobre el cual hemos instalado Firewall-1, no obstante, a través de la variable de entorno FWDIR, es posible acceder al directorio donde el sistema esta instalado, siendo <systemroot>\fw1 en sistemas Windows y /opt/CPfw1-65 (dependiendo de la versión) en sistemas Unix/Linux.

Aunque la política de seguridad corporativa especifique que se deben realizar copias periódicas de los elementos de red, es posible que éstas no se realicen correctamente, por lo que, ante un problema con los equipos, el impacto sería crítico para la organización.

Para nuestro ejemplo de recuperación en caso de desastre, vamos a basarnos en una arquitectura distribuida de Firewall-1. Al tener una instalación distribuida, los Enforcement Modules mantienen la última política de seguridad instalada (actualizada), sin embargo, el SmartCenter Server tiene una política obsoleta y todas nuestras copias de seguridad del propio SmartCenter Server están corruptas.

[Read more…]

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.