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

Un problema habitual en este tipo de arquitecturas hace que siempre nos preguntemos: ¿que sucede si comprometen uno de mis servidores ubicados en la DMZ? Bien sea por un Zero-day, una mala configuracion del sistema, un exploit sin firma actualizada en nuestro IDS, etc., la respuesta suele ser siempre la misma: una vez comprometido un servidor del segmento, el atacante podria comprometernos el resto de los servidores puesto que la comunicacion entre los servidores ya no atraviesa el firewall central.

Para resolver este problema existen distintas soluciones, las cuales se basan entre otras en implantar HIDS o firewalls en los propios servidores, con el problema añadido de la complejidad de la gestion de la seguridad para los administradores o del consumo de recursos, aunque mínimo, de los sistemas implicados.

Un control de seguridad adicional para este tipo de situaciones es posible configurarlo a nivel de red, en concreto en los propios switches, y es lo que se conoce como Private Virtual Lan (PVLAN), una tecnologia (al parecer) ideada por Cisco Systems, aunque soportada por distintos fabricantes.

Habitualmente, una VLAN forma un unico dominio de broadcast donde todos los hosts conectados a ella pueden conectarse entre sí. Por el contrario, una Private VLAN permite una segmentacion en la capa 2 del modelo OSI, limitando el dominio de broadcast, de forma que es posible permitir conexiones de cada host con su gateway, denegando la comunicacion entre hosts, obteniendo el resultado deseado, de modo que si un host se ve comprometido, el resto de equipos podría mantenerse a salvo.

En arquitecturas basadas en PVLAN, cada puerto del switch puede configurarse de tres maneras distintas:

• Promiscuous: el puerto es capaz de enviar y recibir tráfico a cualquier puerto de la misma PVLAN.
• Community: el puerto puede enviar y recibir tráfico a un puerto configurado como promiscuo o a otros puertos de la misma comunidad.
• Isolated: el puerto solo puede enviar y recibir tráfico a un puerto configurado como promiscuo.

De esta forma, una PVLAN solo puede tener un puerto configurado como promiscuous (primary vlan) pero varios declarados como community o isolated (secondary vlan).

En la red DMZ que usamos como ejemplo, el puerto conectado al firewall seria declarado como promiscuous y los puertos que conectan los servidores serian declarados como isolated, siempre que no necesiten conectividad entre ellos, o community en caso de que la requieran. Por ejemplo, un servidor de aplicaciones que accede a un servidor de base de datos.

De esta forma, conseguiríamos un nivel de seguridad más para nuestras redes, en la línea de lo exigido por la ISO 27002 (A.10.6.1, Controles de red), y reduciendo los riesgos para un segmento especialmente expuesto a ataques y amenazas.

(Diagrama de Tech Republic. Pasen un buen y largo fin de semana y nos vemos el martes que viene, en el mismo sitio. Tengan cuidado con la carretera.)

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?

Para el primero de los problemas la opción más habitual es contar con un sistema syslog que reciba los registros de los diferentes sistemas y dispositivos de red distribuidos por la organización, ubicado en un servidor que haya sido convenientemente securizado, limitando el número de servicios que ofrece y controles de acceso, entre otros. Esto permite tener la relativa seguridad de que la información que estamos manejando en la gestión de incidente es veraz. Además, tener los registros duplicados en el sistema de origen y en el servidor syslog permite a posteriori comparar ambos, y detectar así posibles modificaciones que proporcionen información sobre el atacante. Aunque este tipo de configuraciones son relativamente comunes en entornos donde hay mayoría de sistemas Unix/Linux, es raro encontrarlas en entornos Wintel, aunque las ventajas son similares.

En relación con la correlación de registros en el análisis del incidente, es vital que podamos determinar el orden de los acontecimientos, razón por la que el objetivo de control 10.10 Monitorización de la norma ISO 27001 requiere la existencia de un servidor NTP de sincronización que asegure que las fechas de los registros guardan un orden real; de lo contrario, en un entorno que los sistemas y dispositivos de red están no sincronizados en un rango de unos pocos minutos, la reconstrucción puede ser para volverse loco. También para este aspecto un sistema syslog es muy útil, ya que ordena de manera automática los mensajes recibidos de los distintos agentes.

Si no se dispone de un servidor syslog (o éste se limita a recibir la información de los dispositivos de red, dejando fuera los sistemas) y el volumen de información es reducido, la correlación de eventos se puede llevar a cabo de forma manual, aunque lo habitual es usar herramientas de correlacion de logs o alertas que nos permitan obtener información concreta en el menor tiempo posible, aspecto crítico en la gestión de incidentes. Esto no evitará que tengamos que revisar los logs con más detalle posteriormente, ya que aparte de obtener información adicional podría ser necesario presentar una denuncia antes las autorizades competentes, pero sí que facilita y acelera la puesta en marcha de las acciones necesarias para reducir el impacto del incidente en los primeros momentos. Con sistemas automatizados de detección, correlación y alerta, sería posible según los patrones configurados y por lo tanto, potencialmente detectables, anticiparnos al incidente; por ejemplo, pensemos en un ataque externo ocasionado por un nuevo gusano, cuyos patrones de conducta están reportados y de los que existen reglas para detectarlo o filtrarlo en nuestros sistemas (IDS/IPS).

Una visión global de estos aspectos es la que proporciona el proyecto Dshield junto con el Internet Storm Center de Sans Institute. A través de este proyecto, es posible enviar los logs de nuestros sistemas para detectar patrones globales de ataques futuros, formando de este modo un sistema de detección de intrusos distribuido a nivel global, que categoriza las amenazas en 4 niveles: verde, amarillo, naranja y rojo, dependiendo de su impacto potencial. Para evitar proporcionar información sensible al proyecto, como podrían ser las direcciones IP que están siendo atacadas, lo cual podría ocasionar posibles pérdidas para las empresas objetivos del ataque (daño a la imagen corporativa, desconfianza de clientes, etc), dependiendo del tipo de sistema, es posible enmascarar dichas direcciones, de forma que se puede ocultar total o parcialmente la dirección IP. El proyecto dispone de un gran listado de sistemas que soportan el envío de logs al sistema de correlación de forma más o menos automatizada, entre los cuales podemos encontrar dispositivos de grandes fabricantes como Cisco o CheckPoint. Una vez analizados y correlados los logs recibidos, es posible obtener las alertas generadas por el Storm Center, como por ejemplo un listado de direcciones IP potencialmente atacantes, para filtrarlas en nuestros sistemas.

Para finalizar, debemos tener en cuenta que ni el proyecto Dshield, ni el ISC de Sans, ni una correcta gestión de registros garantizan la protección de nuestra red, pero sí que constituyen mecanismos adicionales de reducción de riesgos. Y ya saben que todo suma.

(Entrada elaborada conjuntamente con Manuel Benet)

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.

Partiendo de esta premisa, y usando ARP spoofing o envenenamiento de la caché ARP como mecanismo para realizar un ataque man-in-the-middle, podemos capturar, analizar e incluso escuchar las conversaciones VoIP que se generan en nuestra red. En nuestro caso, para realizar el ataque de ARP spoofing, vamos a usar ettercap y Wireshark para realizar la captura de tráfico, el cual ya trae funcionalidad y filtros para redes VoIP.

Como se puede observar, el proceso es realtivamente sencillo; mientras tenemos en ejecución ettercap generando peticiones ARP falsas, lanzamos una instancia de wireshark, para realizar la captura. Una vez abierto, realizamos los siguientes pasos:

Seleccionamos los parámetros de captura de la aplicación; desde el menú “Capture” seleccionamos la interfaz a través de la cual vamos a capturar tráfico (podemos seleccionar filtros de captura). Una vez establecidos, pulsamos “Aceptar” para comenzar la captura.

Durante la captura, en pantalla observaremos una gráfica con estadísticas de los protocolos capturados:

Una vez tenemos capturados un número considerable de paquetes, paramos la captura, tras lo cual, podremos ver en la consola de wireshark, la lista de paquetes capturados. En nuestro caso:

Llegados a este punto, podemos realizar distintos tipos de análisis de nuestra red VoIP:

» Estadísticas del protocolo de señalización SIP; pulsando en el menú “Statistics -> SIP -> Create Stat“, donde podremos ver estadísticas de los distintos tipos de mensajes del protocolo:

» Estadísticas del protocolo de transporte RTP; seleccionamos uno de los paquetes RTP capturados y pulsamos en el menú “Statistics -> RTP -> RTP Streams“, donde podemos ver los flujos RTP capturados, jitter, códec usado…

No obstante, la opción más interesante la hemos dejamos para el final. Si pulsamos en el menú “Statistics -> VoIP Calls” podemos ver todas las llamadas capturadas:

Una vez tenemos la lista de capturas, podemos seleccionar una llamada cualquiera, y obtener datos más concretos, como puede ser el intercambio de mensajes de señalización SIP (Pulsando la opción Graph).

Y finalmente, reproducir la propia llamada capturada. Tras pulsar el botón “Player” en la pantalla anterior y ajustar el jitter, decodificamos el paquete, y podremos ver los distintos streams de audio, pudiendo reproducirlos de forma independiente o conjunta:

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.

[Read more…]

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:

[Read more…]

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.

Vamos a describir muy brevemente los protocolos de transporte más empleados para la integración de voz y datos: RTP y su protocolo de control RTCP, RTSP para sistemas de vídeo bajo demanda, y RSVP.

RTP (Real-time Transport Protocol) es un protocolo de nivel de aplicación utilizado para la transmisión de información en tiempo real (audio o vídeo), extremo a extremo sobre una red de paquetes. Fue publicado por primera vez como estándar en 1996 como RFC 1889, y actualizado posteriormente. Éste ofrece entrega de datos multicast para aplicaciones de streaming, videoconferencia, etc., siempre que la red proporcione los servicios. Es importante destacar en este caso que RTP no ofrece garantías sobre la calidad del servicio ni sobre el retraso de la entrega de datos, por lo que necesita el apoyo de capas más bajas que controlen la reserva de recursos (como por ejemplo el uso de RSVP que comentaremos al final).

RTP va de la mano de su protocolo de control, RTCP: RTP envía los datos y RTCP proporciona servicios de control y otras funcionalidades. Existe una variante llamada SRTP (Secure RTP) usada para aportar características de cifrado al canal RTP, pero en la que no entraremos aquí.

RTCP (RTP Control Protocol) se encarga de monitorizar la calidad del servicio y de proporcionar información acerca de los participantes en una sesión de intercambio de datos. El protocolo, definido en el RFC 3550, no está diseñado para soportar todas las necesidades de comunicación de una aplicación, sólo las más básicas. La principal función de RTCP es proporcionar una retroalimentación útil para mantener una calidad de distribución adecuada: los receptores de una sesión emplean RTCP para informar al emisor sobre la calidad de su recepción, incluyendo el número de paquetes perdidos, jitter (la variación en la latencia) y RTT (Round Trip Time, tiempo empleado por un paquete en realizar todo el circuito: llegar al receptor y volver de nuevo al emisor).

Los paquetes RTCP se envían de modo que el tráfico en la red no aumente linealmente con el número de agentes participantes en la sesión, ajustando el intervalo de envío de acuerdo al tráfico. Para ello, RTCP se encarga de transmitir periódicamente paquetes de control a todos los participantes de una sesión.

RTSP (Real-Time Streaming Protocol) es un protocolo a nivel de aplicación que optimiza el flujo de datos multimedia. En sintaxis y funcionamiento, es similar al protocolo HTTP, donde tanto el cliente y el servidor pueden hacer peticiones. No obstante, a diferencia de HTTP, el protocolo RTSP necesita mantener información de estado. Entre sus principales ventajas, podemos destacar que debido a sus similitudes con el HTTP, hace que sea adaptable a proxys y firewalls, y es compatible con el modo de difusión multicast, siendo capaz de enviar la información a un grupo de clientes en un solo paso. Además, es independiente de la capa de transporte usada: puede utilizar tanto TCP como UDP.

Por el contrario, como desventajas podemos destacar que depende de la congestión de red, por lo que la pérdida de paquetes durante la transmisión es imprevisible, y si se trabaja en modo unicast, necesita un ancho de banda importante.

Finalmente, y como se ha comentado anteriomente, debemos mencionar el protocolo RSVP (Resource ReSerVation Protocol), usado para manejar la calidad de servicio de la comunicación, ya que hay que tener en cuenta que los paquetes IP son de longitud variable y el tráfico de datos suele ser a ráfagas. El propósito de RSVP es eliminar aquellas situaciones en las que la voz se pierde porque tenemos una ráfaga de datos en la red. Para ello, éste solicita ancho de banda, divide los paquetes de datos grandes y da prioridad a los paquetes de voz cuando hay una congestión en un router. Si bien este protocolo ayudará considerablemente al tráfico multimedia por la red, hay que tener en cuenta que RSVP no garantiza una calidad de servicio como sucede en redes avanzadas como ATM, que proporcionan servicios de QoS (Quality of Service, calidad de servicio) de forma estándar.

Y esto es todo en referencia a los protocolos de transporte. En la siguiente entrada, entraremos en detalle en el protocolo SIP, visto en el anterior post, para acabar con los detalles de la captura de una conversación VoIP.

[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.

[Read more…]

En las ultimas décadas, el mercado de las redes de comunicaciones es uno de los que ha obtenido un mayor avance, debido principalmente a varios motivos, como son (a) la total generalización del uso del protocolo IP que ha posibilitado la difusión de servicios como el correo electrónico o el acceso a web hasta el usuario final, y (b) la apertura de la industria a las nuevas tecnologías, que ha llevado a un sistema flexible de transmisión de datos y a la aparición de tecnologías de comunicaciones ópticas, lo que a su vez ha incrementado el ancho de banda disponible para las comunicaciones.

Principalmente, las redes desarrolladas a lo largo de los años para transmitir voz se basan en el concepto de conmutación de circuitos, es decir, que la realización de una comunicación entre el emisor y el receptor requiere el establecimiento de un circuito físico durante el tiempo que dura ésta. Esto significa que los recursos que intervienen en la realización de una llamada no pueden ser utilizados en otra hasta que la primera no finalice, incluso durante los silencios que se suceden dentro de una conversación típica, por lo que las redes de conmutación de circuitos hacen un uso ineficiente de los recursos.

[Read more…]