(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:

Dentro de la serie sobre VoIP, como previo al material específicamente de seguridad, y una vez comentados los protocolos de señalización, entraremos brevemente en los protocolos de transporte. Éstos se encargan de asegurar que todos los datos hayan llegado intactos desde el origen al destino, cumpliendo con los requerimientos de calidad de servicio y ancho de banda adecuados.

Los paquetes de VoIP se encuentran en el protocolo RTP, el cual va encapsulado en paquetes UDP; no usa TCP porque éste es demasiado pesado para las aplicaciones de tiempo real. Puesto que el datagrama UDP no tiene control sobre el orden en el cual los paquetes son recibidos, o de cuanto tiempo requiere su transmisión, RTP resuelve este problema permitiendo que el receptor ponga los paquetes en el orden correcto y que no “espere” a los paquetes que se hayan perdido el camino o tarden mucho en ser recibidos. En la línea de lo comentado, a continuación podemos ver un esquema de la pila TCP/IP, en la cual observamos los distintos tipos de protocolos de transporte y su posición dentro de la pila.

[Como segunda entrada sobre VoIP, en este post vamos a describir los principales protocolos de señalización utilizados por VoIP, y en el siguiente entraremos en los protocolos de transporte. Estas tres entradas permitirán que los siguientes artículos, de carácter técnico, sean más accesible a aquellos no duchos en esta tecnología.]

En los últimos años, los protocolos de señalización para el servicio de transmisión de voz han experimentado una fuerte evolución, puesto que cada vez más, se están usando las redes de conmutación de paquetes para transportar tráfico de voz. Las necesidades de calidad de servicio hacen que sea necesaria una gestión de recursos que asegure la optimización de la capacidad de transporte de la voz extremo a extremo, para ello surgen los protocolos de la señalización.

Por señalización se entiende el conjunto de informaciones intercambiadas entre los dos extremos de la comunicación que permiten efectuar operaciones de:

• Supervisión (detección de condición o cambio de estado).
• Direccionamiento (negociación y establecimiento de llamada).
• Explotación (gestión y mantenimiento de la red).

Para cumplir los requerimientos de señalización existen principalmente tres protocolos: H.323, SIP y MGCP.