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

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

15/01/15 10:39 p.m.

Seguridad y Redes

Wire Wireshark. shark. Captura convers conversaciones aciones VoIP. Protocolo SIP, SDP y RTP. Extracción de audio. Publicado el 5 abril, 2010

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

En este artículo vamos a usar una captura .pcap conteniendo una conversación usando conversación usando el protocolo SIP SIP (Session (Session Initiation Protocol), un protocolo de señalización, similar a HTML HTML y y SMTP 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 transporteRTP transporte RTP (Real (Real Time Transport Protocol) usando UDP UDP.. SIP SIP encapsula encapsula otro protocolo: SDP 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 siempre, Wireshark para para analizar la captura .pcap e ilustrar todos los aspectos comentados de SIP SIP,, SDP SDP y y RTP RTP,, además de la extracción del audio de las de las conversaciones. co nversaciones.

Breve introducción a SIP, SDP y RTP. Vamos a ver una breve descripción de SIP SIP,, SDP SDP y y RTP para la mejor compresión de los datos de las capturas. SIP (Session 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 caso VoIp.. SIP SIP funciona 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 SIP un un protocolo solo de señalización, 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 SIP puede puede funcionar sobre UDP o UDP o TCP TCP,, aunque para VoIP se usará sobre UDP 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 RTP (Real (RealTime Transport Protocol). SIP tiene SIP tiene una estructura parecida a HTML HTML y y SMTP SMTP.. Esto lo vemos, por ejemplo, en que los clientes involucrados en una conexión tiene direcciones del tipo:

https://seguridadyredes.wordpress.com/2010/04/05/wireshark-cap…nversaciones-voip-protocolo-sip-sdp-y-rtp-extraccion-de-audio/

Página 1 de 11


15/01/15 10:39 p.m.

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. https://seguridadyredes.wordpress.com/2010/04/05/wireshark-cap…nversaciones-voip-protocolo-sip-sdp-y-rtp-extraccion-de-audio/

Página 2 de 11


15/01/15 10:39 p.m.

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

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.

Señalado en un recuadro rojo tenemos el Request-Line o tipo de mensaje. Tipo de mensaje INVITE. Mensaje SIP dirigido a [email protected]. 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


Página 3 de 11


15/01/15 10:39 p.m.

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


Página 4 de 11


15/01/15 10:39 p.m.

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:

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:

. 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. https://seguridadyredes.wordpress.com/2010/04/05/wireshark-cap…nversaciones-voip-protocolo-sip-sdp-y-rtp-extraccion-de-audio/

Página 5 de 11


15/01/15 10:39 p.m.

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

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:

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. https://seguridadyredes.wordpress.com/2010/04/05/wireshark-cap…nversaciones-voip-protocolo-sip-sdp-y-rtp-extraccion-de-audio/

Página 6 de 11


15/01/15 10:39 p.m.

Nos situamos en el segudo item correspondiente al CALL SETUP y pulsamos 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:

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.

You May Like

1. Child Star Syndrome 2 months ago learni.st Learni.st Learni.st (sponsored) 2.


Página 7 de 11


15/01/15 10:39 p.m.

Tu voto:

3 Votes Share this:

! Twitter

7

" Facebook

4

! Me gusta Sé el primero en decir que te gusta.

Relacionado

Tshark, Wireshark en línea de comandos. (VI Parte.) Avanzando en filtros, Estadísticas, COUNT, SUM, MIN, MAX y AVG.

Snort. Security Onion Live. SGUIL, Squert y Suricata. Analizando una alerta. Un caso real. Parte II

Visualización gráfica de ficheros .pcap con AfterGlow.

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. Bob dijo: 16 abril, 2010 en 6:37 pm

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

Alfon dijo: 21 mayo, 2010 en 5:20 pm

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

Danny Caceres dijo: 22 mayo, 2010 en 8:16 pm

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

Anibal Baena dijo: 20 julio, 2010 en 5:36 pm


Página 8 de 11


15/01/15 10:39 p.m.

Muchas gracias, es una herramienta buenísima Responder

ZaPa dijo: 5 agosto, 2010 en 2:18 pm

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

Juan Carlos dijo: 14 agosto, 2010 en 1:53 am

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

Laura Rozo dijo: 26 septiembre, 2010 en 9:10 pm

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

Alfon. dijo: 30 septiembre, 2010 en 7:51 am

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

Eder dijo: 25 octubre, 2010 en 4:14 pm

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

Alfon dijo: 25 octubre, 2010 en 4:46 pm

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


Página 9 de 11


15/01/15 10:39 p.m.

Responder

patrice Bertin dijo: 1 diciembre, 2010 en 2:57 pm

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

Marco Mendoza dijo: 5 diciembre, 2010 en 8:19 pm

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 i ncidencias 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 i magino que está más que claro. Responder

Martin Alejandro Guzman dijo: 22 octubre, 2013 en 6:09 pm

Lo que tenes que buscar en el Flow de la conversacion es el bye, ya que desde tu gateway o pbx al puesto va por sip, ahi vas a saber quien corto (recorda que en el Flow aparece con una flecha el sentido de los paquetes) Responder

Francisco dijo: 31 enero, 2011 en 4:37 pm

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 Responder

jordi dijo: 17 abril, 2011 en 1:50 pm

Muy útil ! gracias por compartirlo… Responder

Alfon dijo:

https://seguridadyredes.wordpress.com/2010/04/05/wireshark-cap…versaciones-voip-protocolo-sip-sdp-y-rtp-extraccion-de-audio/

Página 10 de 11


15/01/15 10:39 p.m.

18 abril, 2011 en 7:42 am

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

Emerson dijo: 15 marzo, 2012 en 5:30 pm

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

Seguridad y Redes El tema Twenty Ten.

Crea un blog o un sitio web gratuitos con WordPress.com.

https://seguridadyredes.wordpress.com/2010/04/05/wireshark-cap…versaciones-voip-protocolo-sip-sdp-y-rtp-extraccion-de-audio/

Página 11 de 11

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

Recommend Documents