Hace ya algún tiempo, Toni Villalón nos hacia referencia a una técnica habitual en las auditorías de seguridad hace algunos años, el basureo (trashing), a partir de la cual podíamos obtener gran cantidad de información a partir de una papelera o cubo de basura. Sin embargo, ¿por qué ir rebuscando en la basura (que es algo sucio, desagradable y no sabemos con que podemos encontrarnos) si existen maneras mucho más fáciles, cómodas y limpias de obtener información? Además, sin ir muy lejos ni que te miren raro.

¿Dónde? En su impresora más cercana. Levántese, diríjase a ella y observe la documentación que nadie recoge, bien porque la envió a imprimir y olvidó que la había enviado, porque ya no la necesita, o por cualquier otra razón que se le ocurra. En realidad, el porqué no nos importa, lo que nos interesa es la información que contiene. Cójala y llévela a su sitio. Quizá le preocupe que su dueño legítimo aparezca de repente y le vea hacerlo, pero no se preocupe; lo más probable es que la haya abandonado, y en cualquier caso si acude a la impresora y ve que no está, la volverá a mandar imprimir, y probablemente volverá a olvidarla.

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.

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.

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.

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.

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.

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:

Como cada día 1 de septiembre desde hace unos años, volvemos a la carga con el blog; y como cada día 1 de septiembre desde hace unos años esperamos que las vacaciones hayan sido provechosas en todos los sentidos, que hayan descansado y que vuelvan con las pilas cargadas para los meses que nos quedan (sólo 11) hasta el próximo periodo de descanso estival. Tras el mes de agosto, vamos a comenzar con la marcha habitual en Security Art Work, en este caso con un post de José Luis acerca del filtrado en los dispositivos ASA de Cisco. Vamos allá…

Si en nuestra organización disponemos de un IPS, cuando éste detecta un ataque suele filtrar de forma inmediata el tráfico proveniente de la dirección IP atacante; no obstante, si simplemente tenemos un IDS, una vez que nuestros sistemas de detección han detectado y notificado una actividad potencialmente sospechosa, la primera función que suele llevar a cabo el personal de seguridad es el filtrado manual de las conexiones en el firewall corporativo para, posteriormente, realizar un análisis más minucioso del ataque, una análisis forense e incluso, en caso de ser necesario, proceder a denunciar el hecho ante las FFCCSE. En cualquier caso, la velocidad de respuesta a la hora de llevar a cabo el filtrado de la dirección IP que nos ataca es crítica, ya que cuanto más tiempo pueda tener acceso el atacante a nuestros sistemas, mayor será el daño que nos cause, por ejemplo dejando puertas abiertas para conexiones futuras o directamente robando información.

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.