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.

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.

(N.d.E. Para aquellos que no pueden vivir sin Internet durante las vacaciones —aquellos que las tengan—, aquí va una entrada sobre la securización de DMZ)

Generalmente, la arquitectura de seguridad de red en pequeñas empresas se basa en un elemento central de filtrado, habitualmente un firewall, y distintos segmentos de red conectados a él, principalmente, un segmento de red interna y un segmento DMZ para alojar servidores corporativos. En el caso de una empresa de tamaño medio o grande, la situación es bastante similar: uno o varios firewalls en alta disponibilidad separando distintos segmentos de red, aunque disponen de otros controles como NIDS, IPS, sistemas de monitorizacion, etc, y técnicos dedicados a la gestion de la seguridad.

Habitualmente, todos los profesionales que nos dedicamos en mayor o menor medida a la seguridad nos vemos en la necesidad de gestionar incidentes de seguridad; para ello, nuestra mayor fuente de información suelen ser los registros o logs de los sistemas implicados, tanto a nivel de comunicaciones (routers, cortafuegos, IDS, etc) como a nivel de sistema (Unix, Windows, Linux, etc.) y de aplicación (servidor web, servidor de correo, etc.). Desgraciadamente, es habitual que cuando el potencial cliente ha contactado con nosotros, su personal técnico, siempre con buena intención, haya realizado acciones que invalidan parcial o incluso totalmente los registros y con ello cualquier vía de investigación: formateo de servidores, borrado de logs, limpieza manual de entradas, etc. Como es natural, esto limita sensiblemente la información del incidente que se puede obtener, por lo que es imprescindible que no se lleven a cabo acciones que puedan modificar “la escena del crimen”, casi de la misma manera que puede verse en una película policíaca. No obstante, dejemos eso para una entrada sobre análisis forense y pasemos al análisis de los registros.

A la hora de analizar estos logs nos encontramos principalmente dos problemas. El primero es su fiabilidad ya que ante un sistema comprometido, es inevitable preguntarse: ¿cómo de fiables son nuestros registros?, puesto que probablemente hayan sido alterados o borrados. El segundo problema tiene mucho que ver con la correlación temporal de la información contenida en los registros implicados en el incidente, generando preguntas del tipo: ¿las fechas de los diferentes sistemas se encuentran sincronizadas? ¿Qué sucedió antes y qué después? ¿De qué volumen de logs del incidente dispongo? ¿Hasta cuándo puedo retroceder?

Como indicamos el pasado viernes en nuestro twitter, el pasado 5 de mayo llegó a la lista pen-test de Securityfocus el anuncio de la liberación de la version 1.0 de la herramienta VoIP Hopper, una herramienta para sistemas Unix/Linux, escrita en C y licenciada como GPL3, que nos va a ser muy útil para securizar nuestra red, concretamente la capa dos (muchas veces olvidada), debido a que está basada en la tecnica conocida como Vlan Hopping con la cual podemos ser capaces de saltar a una Vlan del switch a la que no pertenecemos.

Con la aparición de esta nueva versión de la herramienta, se amplía la lista de herramientas dedicadas exclusivamente a auditoría de redes de Voz sobre IP, como pueden ser SIPVicious, Voiper, sipdump/sipcrack, VoipPong, etc.

Puesto que cada día son más las empresas que llevan a cabo una unificación de sus comunicaciones, partiendo con la implantación de una red Voz usando su propia red local, y finalizando con la unificación total de sus comunicaciones (Voz sobre IP, mensajería unificada, servicio de presencia, etc.), la seguridad de la red se convierte en un aspecto crítico a tener muy en cuenta a la hora de realizar dicha integración, para garantizar, no solo la calidad del servicio, sino también la disponibilidad, confidencialidad e integridad de la informacion que atraviesa el sistema. Por lo tanto, en caso de disponer de sistemas VoIP en nuestra red, debe ser una buena práctica de seguridad llevar a cabo un plan de auditoría de vulnerabilidades específico contra los servicios que forman parte de dichos sistemas.

Como vimos en el anterior post, uno de los problemas de seguridad al que se enfrentan las redes VoIP actualmente, al igual que las redes de datos, es a lo que se conoce habitualmente como eavesdropping, es decir, escuchar secretamente los datos transmitidos entre dos o más puntos, sin ser participe directo de ello; en términos de VoIP, como eavesdropping podemos considerar la escucha, sin ser participe, de una conversación entre varias personas. Concretamente, debemos interceptar los mensajes de señalización y los streams de audio de la propia conversación.

Actualmente, muchas implantaciones de VoIP no están correctamente planificadas, y por tanto, comparten el mismo medio físico para transmitir voz y datos; no existe una red paralela independiente ni, en muchos casos, independencia lógica de redes basadas en Vlans, por lo que es habitual encontrar conectados a un mismo switch, tanto teléfonos IP, como equipos de usuarios.

Una vez descrito el funcionamiento básico del protocolo, y centrándonos en su seguridad, vamos a describir brevemente el funcionamiento de la autenticación SIP y un ataque de cracking de contraseñas.

Entrando ya de lleno en el campo de la seguridad, el protocolo SIP proporciona un mecanismo desafío-respuesta para realizar la autenticación, el cual esta basado en la autenticación HTTP. El esquema, conocido como Digest Authentication, evita el envío de la contraseña de los usuarios en texto plano puesto que hace uso de una función hash MD5 y de un secreto compartido por ambas partes: la contraseña.

Su funcionamiento es el siguiente: cuando un cliente intenta establecer una llamada con el servidor, éste responde con un mensaje que incluye un valor aleatorio (nonce) junto al dominio contra el que se va a autenticar (realm). Entonces, el cliente debe enviar una respuesta cifrada al servidor en un mensaje de tipo response, indicando el nonce, el realm junto con el nombre de usuario, el uri y la contraseña. Una vez recibidos estos datos, el servidor compara el valor de la respuesta del cliente con el resultado de cifrar él por su cuenta los mismos datos, con la contraseña que tiene del cliente.

Como se vió en posts anteriores, SIP (Session Initiation Protocol) es un protocolo de control desarrollado por el IETF, basado en arquitectura cliente/servidor similar al HTTP, legible por humanos, con el que comparte muchos códigos de estado y sigue una estructura de petición-respuesta; estas peticiones son generadas por un cliente y enviadas a un servidor, que las procesa y devuelve la respuesta al cliente. El par petición-respuesta recibe el nombre de transacción. Al igual que el protocolo HTTP, SIP proporciona un conjunto de solicitudes y respuestas basadas en códigos.

El protocolo SIP define principalmente seis tipos de solicitudes: