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.
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
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 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:
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.
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.
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.
Seguridad y Redes 
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.
Hola Bob , he usado el Wireshark por alrededor de 4 o 5 años y lo ue puedes hacer es ver en el detalle del contenido de paquete, que tamaño de paquete es y usar una herramienta que indica «seguir conexion» la cual seleccionas en el menu contextual que aparece cuando seleccionas un paquete y das click con boton derecho. Selecciona seguir conexion y observaras todos los paquete que corresponden a una conexion, y naturalmente, ese paquete que seleccionaste pertenece a esa conexion. Te daras cuenta cuando inicio y que tipo de conexion es en TCP. Espero te haya servido. Saludos
Bob, intentaré realizar una reseña o artículo sobre este tema.
que tal.. muy buena informacion.. una pregunta.. funciona de la misma manera en redes ipv6???.. saludos
Muchas gracias, es una herramienta buenísima
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.
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.
Hola!, excelente artículo, muchas gracias, me sirvió mucho 😀
Laura, muchas gracias por tu comentario y por leerme. Gracias también a tí J. Carlos.
Ya sacaste el próximo capitulo???
Si es así como lo encuentro??
me seria de mucha ayuda
Elder, tengo en borrador el artículo a medio hacer desde hace meses. A ver si lo termino.
Muchas gracias Alfon. Me ayudo mucho tu artículo para pasar de la teória a la practica.
Un saludo.
patrice
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.
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)
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
Muy útil ! gracias por compartirlo… 😉
Francisco,
Envíame una captura. Escríbeme, y lo vemos.
ohh amigo, muy interesante.. pero no pudo oir el audio de la conversa, y tengo la version 1.6 :S
gracias ^^
Que tal estimado.. de gran ayuda la publicacion.. a ver si me puede desburrar al respecto necesito hacer bajadas de las conversaciones son casi 300 por dia.. el tema es q en nagios es muy rudimentario tener q seleccionar llamada por llamada.. conoce de algun soft q sea mas dinamico? estuve viendo el xplico .. puedo escucharlos pero no guardarlo. gracias saluods.
hola Alfon, disculpa pero me interesa mucho este tema, hay alguna forma de contactarte por correo electronico? (bueno espero que sigas administrando este sitio) te dejo mi correo lopez.gga@hotmail.com
Te dejo un 10+ oye crack necesito contactarte para una asesoria dejame un numero de telefono
Hola soy nueva en redes sin embargo trabajo en una oficina de call center y estamos tratando de monitorear llamadas para nuestro entrenamiento sin que el cliente escuche la voz de la persona que monitores la llamada en tiempo real, contamos con teléfonos VOZ IP y trabajamos con telefonía por internet, utilizamos protocolo SIP en este teléfono: Ip/voip Sip Comp. Asterisk Iax2 Yhw200 Ftp Http Lqe
Me puedes asesorar por favor como puedo utilizar la función de monitoreo ya que he leído que marque 555 con Chan Spy pero no se si en protocolo SIP funcione.
Muchas gracias quedo en espera de tu pronta respuesta.
alguien puede ayudarme con esto, necesito saber la explicacion de esta traza.
(R) ==> IAM : Time = 11:29:10:6 (mensaje inicial de direccion)
+++ NATURE OF CONN. INDICATORS : 10
– Satellite Indic (AB) : 10 No Satellite circuit in Connection
– Continuity Check Indic (CD) : 10 Continuity check not required
– Echo Contr. Dev. Indic (E) : 10 Outgoing echo contr dev included
+++ FORWARD CALL INDICATORS : 20
– National / Internat. (A) : 20 Treat as national call
– End-To-End Method Ind (BC) : 20 No END-TO-END method available
– Interworking Indic. (D) : 20 No Interworking encountered, C7 all the way
– End-To-End Inform Ind (E) : 20 No END-TO-END information available
– ISDN User part Ind. (F) : 20 ISDN user part used all the way
– ISDN User Part Pref (GH) : 20 ISDN user part preferred all the way
– ISDN Access Indicator (I) : 00 Originating access NON-ISDN
– SCCP Method Indicator (JK) : 00 No Indication
– VPN Call Indicator (PO) : 00 Non VPN Call
+++ CALLING PARTY CATEGORY : 0A Ordinary calling subscriber
+++ TRANSM MEDIUM REQUIREMENT : 03 3.1 Khz audio
+++ CALLED PARTY NUMBER :
– Nature of Addr Indic. (AG) : 83 National (significant) Number
– Numbering Plan Indic. (EG) : 90 ISDN numbering plan
– Internal Netw Numb (H) : 90 Routing to Internal Network not Allowed
== Called Party Number : 88522629F
+++ CALLING PARTY NUMBER :
– Nature of Addr Indic. (AG) : 03 National (significant) Number
– Numbering Plan Indic. (EG) : 13 ISDN numbering plan
– Screening Indic. (AB) : 13 Network provided screening
– Present. Indic. (CD) : 13 Presentation allowed
– Num Incomplete Ind (H) : 13 Number Complete
== Calling Party Number : 22224277
(S) <== ACM : Time = 11:29:24:8
+++ BACKWARD CALL INDICATOR : 02
– Charge Indicator (AB) : 02 Charge
– Called Party Status (CD) : 02 No Indication
– Called Party Category (EF) : 02 No Indication
– End-To-End Indicator (GH) : 02 No END-TO-END method available
– Interworking Indicator (I) : 34 No interworking encountered
– End-To-End Info Indic (J) : 34 No END-TO-END information available
– ISDN UserPart Indicator (K) : 34 ISDN user part used all the way
– Holding Indicator (L) : 34 Holding not requested
– ISDN Access Indicator (M) : 34 Terminating access ISDN
– Echo Control device ind (N) : 34 Incoming echo contr dev included
– SCCP method Indicator (OP) : 34 No Indication
+++ GENERIC NOTIFICATION :
– Extension Indicator (H) : FB Last Octet
– Notification Indicator (AG) : FB Call is Diverting
+++ REDIRECTION NUMBER :
– Nature of Addr Indic. (AG) : 84 International number
– Numbering Plan Indic. (EG) : 90 ISDN numbering plan
– Internal Netw Numb (H) : 84 Routing to Internal Network not Allowed
== Redirection Number : 50588500125
+++ CALL DIVERSION INFORMATION :
– Notificat. Supscr Opt (AC) : 32 Presentation Allowed with Redirection Number
– Redirection Reason (DG) : 32 Mobile Subscriber not reachable
+++ PARAMETER COMPATIBILITY INF :
== nth Upgraded Parameter : 2C Generic Notification
== nth Instruction Indicator :
– Transit at Interm Exch (A) : 90 Transit Interpretation
– Release Call Ind (B) : 90 Do Not Release Call
– Snd Notification Ind (C) : 90 Do Not Send Notification
– Discard Message Ind (D) : 90 Do Not Discard Message
– Discard Parameter Ind (E) : 90 Discard Parameter
– Pass On Not Possib Ind (FG) : 90 Release Call
== nth Upgraded Parameter : 36 Call Diversion Information
== nth Instruction Indicator :
– Transit at Interm Exch (A) : 90 Transit Interpretation
– Release Call Ind (B) : 90 Do Not Release Call
– Snd Notification Ind (C) : 90 Do Not Send Notification
– Discard Message Ind (D) : 90 Do Not Discard Message
– Discard Parameter Ind (E) : 90 Discard Parameter
– Pass On Not Possib Ind (FG) : 90 Release Call