Wireshark. Captura conversaciones VoIP. Protocolo SIP, SDP y RTP. Extracción de audio.

Es posible, tratándose de instalaciones VoIP no seguras, la captura de paquetes VoIP (emisión de voz en paquetes IP) y la extracción de conversaciones contenidas en este tipo de conexiones.

Wireshark captura conversacion VoIP SIP UDP Voip calls RTP player

En este artículo vamos a usar una captura .pcap conteniendo una conversación usando el protocolo SIP (Session Initiation Protocol), un protocolo de señalización, similar a HTML y SMTP, encargado de la localización usuarios, parámetros, modificaciones e iniciar o finalizar una sesión. Los datos de audio serán transportados mediante el protocolo de transporte RTP (Real Time Transport Protocol) usando UDP. SIP encapsula otro protocolo: SDP, que es el encargado de la negociación de las capacidades de los participantes, tipo de codificación usados y otros aspectos. 

Usaremos, como siempre, Wireshark para analizar la captura .pcap e ilustrar todos los aspectos comentados de SIP, SDP y RTP, además de la extracción del audio de las conversaciones.

Breve introducción a SIP, SDP y RTP.

Vamos a ver una breve descripción de SIP, SDP y RTP para la mejor compresión de los datos de las capturas.

SIP (Session Initiation Protocol), como hemos comentado, es un protocolo que provee mecanismos para la creación, modificación y finalización se sesiones, en esta caso VoIp. SIP funciona en combinación con SDP que es el encargado de la negociación de capacidades multimedia de los participantes involucrados, ancho de banda, negociación de los codecs, etc.

Al ser SIP un protocolo solo de señalización, solo entiende del establecimiento, control y la terminación de las sesiones.

Es un protocolo simple, escalable y se integra con facilidad en otros protocolos. SIP puede funcionar sobre UDP o TCP, aunque para VoIP se usará sobre UDP. Una vez establecida la sesión, los clientes intercambian directamente los contenidos multimedia de audio y/o video a través de, en este caso, RTP (Real-Time Transport Protocol).

SIP tiene una estructura parecida a HTML y SMTP. Esto lo vemos, por ejemplo, en que los clientes involucrados en una conexión tiene direcciones del tipo:

usuario@dominio 

SIP contiene una serie de componentes.:

  • Agente de Usuario. (user agent client y user agent server)
  • Agente de Redirecciones
  • Servidor Proxy
  • Servidor de Registro.
  • Servidor de Localización.

Dentro de las cabeceras SIP, podemos encontrar una serie de mensajes SIP para las sesiones. Están en formato ASCII.

Los mensajes más comunes son:

  • INVITE. Tipo Request. Para establecer una sesión entre agentes de usuario. contiene información sobreu suario origen y destino y tipo de datos (audio, video). contiene mucha más información. Lo veremos en las capturas Wireshark.
  • ACK. Para la confirmación de un establecimiento de sesión. Un mensaje ACK puede ser, como vemos más abajo, un código 200 Ok de éxito.
  • OPTION. Un Request o solicitud de información de capacidades
  • BYE. Se usa para la liberación o terminación de una sesión establecida. BYE puede ser emitido tanto por el usuario que genera una llamada o el que la recibe.
  • CANCEL. Cancela una petición pendiente sin influir en la sesión o llamada establecida y acpetada.
  • REGISTER. Es usado por un user agente o agente usuario para el registro de dirección SIP e IP o dirección de contacto. Relacionado con la ubicación de los usuarios.

De igual forma tenemos una serie de códigos correspondientes a las repsuestas a los mensajes SIP:

  • 1xx. Mensajes de información. Provisionales (100 Trying)
  • 2xx. Respuesta de Exito. Se recibió el requerimento y es acpetado. (200 Ok)
  • 3xx. Respuesta de redirección. Se requiere de otros procesamientos antes de determinar si es posible la llamada. (302 Moved Temporaly) o (305 Utiliza Proxy).
  • 4xx. Respuesta de fallo en petición o fallo del cliente. (404 Not Found)
  • 5xx. Respesta de fallos en servidor a pesar de tratarse de un requerimiento valido.  (504 Server Time-out) o (503 Servicio no disponible)
  • 6xx. Respuesta de fallos globales. (603 Decline)

El protocolo RTP.

Una vez establecida la sesión, los datos en tiempo real de voz y/o áudio se realiza usando el protocolo RTP. RTP “viaja” sobre UDP para obtener mayor velocidad (estamos hablando de un protocolo para tiempo real). Eso sí, perdemos la fiabilidad que si tiene TCP.

Se encarga de los números de secuencia, marcas de tiempo y origen de los datos y llegada de estos. Provee información para la detección de paquetes perdidos.

La cabecera RTP indica al receptor como reconstruir los datos y
describe como se han codificado el flujo de bits.

No garantiza el envio ni orden de los paquetes ni calidad del servicio. Está encapsulado en UDP.

Contiene información del tipo de carga útil Payload y compresión de los datos, ed decir, codecs de audio/video.

Analizando los paquetes.

Biuen, vamos ahora a abrir el archivo .pcap de captura de una sesión  conversación VoIP y analizar los paquetes SIP / SDP y RTP.

NOTA: Esta captura la he obtenido de un repositorio público de ficheros .pcap

Wireshark captura conversacion VoIP SIP UDP RTP

Paquete nº1

El paquete número uno corresponde a un mensaje SIP de tipo Request, concretamente INVITE que, como ya hemos visto, se refiere al establecimiento de llamada o sesión.

Wireshark captura conversacion VoIP SIP UDP RTP

Señalado en un recuadro rojo tenemos el Request-Line o tipo de mensaje. Tipo de mensaje INVITE. Mensaje SIP dirigido a francisco@bestel.com. Vemos también la versión SIP que es SIP/2.0. El puerto de destino es 55060.

Ahora tenemos el Message Header o cabecera que contiene:

  • Via. Campo que usado para el registro de ruta.De esta forma la respuesta al  seguirá el mismo camino que el Request o petición INVITE. Contiene también en trasporte usado (SIP/UDP) y el branch o identificación de la transacción.
  • From. Cliente que realiza la llamada o petición.
  • To. Cliente al que se realiza la petición.
  • Call-ID. Identificador únicio de la sesión. Identifica a los mensajes que corresponden a la misma llamada.
  • C-Seq. Número de secuencia.
  • Contact. URI SIP Contact address. Contiene la IP y puerto donde el realiza la petición INVITE espera recibir resupesta.

Message Body o cuerpo del mensaje contiene el Session Description Protocol SDP con los siguientes campos:

  • Versión de Session Description Protocol. SDP. En este caso 0
  • Propietario/Creador de la sesión o Owner/Creator. Se trata de una identificación formada por:
  • Owner username. Usuario.
  • Session ID. ID de la sesion. Número aleatorio como identificador único de la sesion.
  • Session Version. Versión.
  • Network Type. Tipe de red. Siempre IN.
  • Address Type. Tipo de dirección. Puede ser IP4 (IPv4) o IP6 (IPv6).
  • Address (IP). Dirección IP. (200.57.7.197)
  • Session Name. Nombre de la sesión.
  • Connection Information. Información sobre la conección. Contiene información ya contenida en los campos anteriores como:
  • c= Conection Network Type: (IN)
  • Connection Address Type: (IP4 o IPv4)
  • Connection Address: (200.57.7.197)
  • Time Description, active time. Aquí se indica el inicio y final de la sesión. En este caso tenemos (t): 0 0, es decitstart time= o y stop time = 0. Significa  sesión no limitada y permanente.
  • Media Description, name and address (m): audio 40376 RTP/AVP 8 18 4 0. Aquí tenenemos información sobre el tipo de datos que se transporta (audio o sesión telefónica en este caso), el puerto UDP usado (40376), el protocolo usado (RTP  Real Time Transport Protocol /AVP Audio video Profiles). Y por último, los formatos de codecs:
    • 8 G.711 PCMA
    • 18 G.729
    • 4 G.723
    • 0 G.711 PCMU
  • Media Attribute (a). Se trata de una lista de los formato de codes reseñados más arriba con información de Sample rate o frecuencia de muestreo, Fieldname, etc.
  • Media Attribute (a). SendRecv. Modo envio/recepción.

Paquete nº2

El paquete nº 2 corresponde a un mensaje de respuesta de información de estado. Se informa, tal como dice su código 100, de que se está tratando la información:

Wireshark captura conversacion VoIP SIP UDP RTP

Se observa el Status-Code: 100

En el Message Header tenemos la misma información que el Message Header del paquete número 1.

Paquete nº3

En el paquete nº 3 tenemos un mensaje también de mensaje de respuesta de información de estado. Se informa que el INVITE fue recibido por la otra parte. Digamos que se está Rinnging (llamando) y se espera a que atienda la llamada:

Wireshark captura conversacion VoIP SIP UDP RTP

.

Vemos que en los paquetes 2 y 3, en el campo To, hay un Tag=298852044 que no estaba en el paquete nº 1.  Es el mismo e identifica a la sesión.

===========================

Bien, aún nos quedan algunos paquetes más por ver. Lo veremos en la siguiente y última parte. Ahora vamos a ver como con Wireshark podemos extraer la información de audio y otros datos de la captura.

Extracción del audio con Wireshark.

Si establecemos como filtro el protocolo rtp, veremos solo los paquetes correspondientes a dicho protocolo. Ya hemos visto más arriba para que sirve RTP.

Observamos uno de estos paquetes (lo veremos con más profuncidad más adelante):

Wireshark captura conversacion VoIP SIP UDP RTP

Vemos en el campo Payload Type o tipo de carga que se trata de  de ITU-T G.711 PCMA (8), es decir usa el códec audio G.711, estandarizado por ITU (International Telecom. Union). Frecuencia de muestreo 8KHz y usa para comprimir/descomprimir PCMA.

Nos situamos sobre este paquete y en el menú Telephony > VoIP Calls, nos aparece una ventana:

Wireshark captura conversacion VoIP SIP UDP RTP Voip calls

Se trata de una lista de las llamadas incluidas en la captura. Tenemos una serie de columnas con información de cada llamada:

  • Start Time. Marca de tiempo en inicio de la llamada.
  • Stop Time. Marca de tiempo de inde de llamada.
  • Initial Speaker. Dirección IP del que inicia la llamada.
  • From. Campo From del que realiza la petición INVITE.
  • To. Campo To de la petición INVITE.
  • Protocol. Protocolo usado. (SIP en nuestro caso)
  • Packets. Número de paquetes correspondientes a la llamada.
  • State. Estado de la llamada. En nustre caso tenemos IN CALL (llamada en curso) y CALL SETUP (llamada en estado de proceso o setup. En este caso trámites de INVITE, etc.)
  • Comments. Comentarios.

Nos situamos en el segudo item correspondiente al CALL SETUP y pulsamos Graph:

Wireshark captura conversacion VoIP SIP UDP RTP Voip calls Graph

Aquí, como veis,  tenemos un análisis gráfico de la conversación mantenida entre quien realiza la petición INVITE y las dos respuestas correspondentes a los paquetes 1 y 2 que ya hemos visto.

Si hacemos lo mismo con el primer Item  correspondiente al IN CALL, vereis, a parte de los paquetes 1,2 y3 , la conversación RTP de transporte del audio de la conversación. Es este itrem el que nos interesa.

Cerramos la ventena de análisis gráfico y sobre la ventana VoIP Calls, pulsamos el botón Player en el Item 1. Sobre la ventana que nos aparece pulsamos Decode y obtenemos:

Wireshark captura conversacion VoIP SIP UDP Voip calls RTP player

Tenemos dos pistas de audios que corersponden a cada uno de los usuarios involucrados en la conversación. Si marcamos una pista uno y pulsamos Play oiremos el audio de la conversación. Pulsando ambas pistas escucharemos toda la conversación.

====

Hasta aquí por hoy. En el próximo capitulo veremos los paquetes RTP en profundidad  y otros paquetes SIP como REGISTER.

About these ads
Esta entrada fue publicada en Seguridad y redes, VoIP, Wireshark . Tshark. Guarda el enlace permanente.

17 respuestas a Wireshark. Captura conversaciones VoIP. Protocolo SIP, SDP y RTP. Extracción de audio.

  1. Bob dijo:

    Hola Alfon, Muy buenos articulos. Te comento que administro una red wifi con cerca de 40 usuarios. La red se usa fundamentalmente para recopilar informacion de tipo metereologico y el problema que presento es que la misma a cada rato colapsa pues algunos usuarios indisciplinados la usan para copiar ficheros de audio y video. He realizado varias capturas con wireshark y me interesaria poder detectar quien y que copia en la red, para poder evitar la caida de la misma. Si me pudieras orientar que protocolo debo filtrar, puertos, etc, te lo agradeceria mucho.
    muchas gracias.

  2. Alfon dijo:

    Bob, intentaré realizar una reseña o artículo sobre este tema.

  3. Danny Caceres dijo:

    que tal.. muy buena informacion.. una pregunta.. funciona de la misma manera en redes ipv6???.. saludos

  4. Anibal Baena dijo:

    Muchas gracias, es una herramienta buenísima

  5. ZaPa dijo:

    Hola Bob.
    Necesitas implementar calidad de servicio (QoS) en tu red, para limitar la velocidad máxima de bajada/subida en tu red local, ya que si no lo haces, pasará lo que te esta pasando, cuando un usuario pase cualquier fichero, llegará a la velocidad máxima del backbone y tendrás pines altos, con lo que la red irá lenta.
    Un saludo.

  6. Juan Carlos dijo:

    Hola amigos, realmente este blog de Seguridad y Redes es espectacular, realmente amigo te agradesco por ese aporte que haces a la gente que ya tiene un conocimiento avanzado y a otros que tienen básico como yo, que toy empezando mi tesis en Seguridad Informática.
    realmente estoy muy agradecido y espero que coloques más sobre seguridad.
    saludos y éxitos.

  7. Laura Rozo dijo:

    Hola!, excelente artículo, muchas gracias, me sirvió mucho :D

  8. Alfon. dijo:

    Laura, muchas gracias por tu comentario y por leerme. Gracias también a tí J. Carlos.

  9. Eder dijo:

    Ya sacaste el próximo capitulo???
    Si es así como lo encuentro??
    me seria de mucha ayuda

  10. Alfon dijo:

    Elder, tengo en borrador el artículo a medio hacer desde hace meses. A ver si lo termino.

  11. patrice Bertin dijo:

    Muchas gracias Alfon. Me ayudo mucho tu artículo para pasar de la teória a la practica.
    Un saludo.
    patrice

  12. Marco Mendoza dijo:

    Hola que tal, mil gracias, el artículo es de mucha ayuda, lo uso como referencia en el trabajo, ya que nuestra telefonía se basa en protocolo SIP y hemos tenido incidencias de fallas de telefonía, sin embargo sólo el proveedor interpreta los resultados, hasta hace poco nos integramos a la tarea y con este documentos me apoyo para realizar mis análisis. Sólo una pregunta ¿Cómo se puede interpretar la captura en el siguiente escenario? Usamos un servidor con tarjetas Dialogic por lo que la tarjeta tiene una IP independiente y el servidor también. Cuando se establece un diálogo entre el equipo del agente (una PC con softphone) y el servidor, en las gráficas me parece en el extremo izquierdo la IP del servidor donde está instalada esta tarjeta, en el extremo derecho la IP de la tarjeta Dialogic, pero en medio aparece la dirección IP del equipo de agente que recibe la llamada con el softphone ¿Cómo se interpretaría el flujo de diálogo? Lo que quiero saber es quien manda la señal de colgado, la señal que viene del PSTN sobre el E1, el servidor SIP o la tarjeta Dialogic. Cuando el agente la envía me imagino que está más que claro.

  13. Francisco dijo:

    Hola, lo primero felicitarte por el blog y el artículo. Tengo que hacer un trabajo sobre Asterix o Ventrilo k es para mac y me gustaria complementarlo mostrando los protocolos que usan, como SIP o RTP pero cuando me conecto al servidor de ventrilo o hablo con mi compañero, wireshark no detecta ninguno de los dos protocolos, solo tcp y bsd creo recordar, pero esono me sirve como podria solucionarlo?? Muchas gracias de antemano

  14. jordi dijo:

    Muy útil ! gracias por compartirlo… ;-)

  15. Alfon dijo:

    Francisco,
    Envíame una captura. Escríbeme, y lo vemos.

  16. Emerson dijo:

    ohh amigo, muy interesante.. pero no pudo oir el audio de la conversa, y tengo la version 1.6 :S

    gracias ^^

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s