rtpmixsound se utiliza en auditorías de seguridad VoIP

 

https://www.onlinetis.com

rtpmixsound se utiliza en auditorías de seguridad VoIP

rtpmixsound es un módulo/herramienta del suite SipSpool / VoIPong (parte de la suite de herramientas Siparmy) que se utiliza en auditorías de seguridad VoIP sobre Kali Linux para reconstruir y mezclar los flujos de audio de llamadas RTP que han sido capturadas previamente en la red.

Su función principal es tomar fragmentos de tráfico de voz cifrado o en claro (archivos .rtp capturados de una llamada entre emisor y receptor) y unirlos en un único archivo de audio ejecutable (.wav) para analizar la conversación completa en orden cronológico.

Uso general y sintaxis

La herramienta toma dos archivos de carga útil RTP (correspondientes a los dos sentidos de la conversación, ida y vuelta) y genera el archivo de salida mezclado.

Bash

rtpmixsound -i canal_ida.rtp -o canal_vuelta.rtp -w llamada_completa.wav

Parámetros principales

• -i <archivo>: Especifica el archivo .rtp del canal de entrada (audio del emisor).
  
  
• -o <archivo>: Especifica el archivo .rtp del canal saliente (audio del receptor).
  
  
• -w <archivo.wav>: Nombre del archivo .wav resultante con la mezcla final del audio.
  
  
• -c <codec>: (Opcional) Permite forzar el códec de descompresión si el archivo no lo detecta automáticamente (por ejemplo, PCMU/G.711u o PCMA/G.711a).
  
  

Flujo de trabajo típico en auditorías VoIP

1. Captura de tráfico: Se intercepta la sesión SIP y los paquetes de datos con herramientas como Wireshark, tshark o sipdump.
   
   
2. Extracción de payloads: Se aíslan los flujos RTP del stream de datos y se guardan por separado.
   
   
3. Reconstrucción: Se ejecuta rtpmixsound pasando ambos streams para generar la pista de audio unificada.
   
   

Nota: Para realizar este procedimiento directamente en entornos GUI, también es posible procesar el audio directamente desde Wireshark navegando a Telephony -> VoIP Calls -> Player / Export, lo que permite exportar la mezcla a WAV sin recurrir a la línea de comandos.

Para proteger la telefonía IP frente a intercepciones de tráfico, capturas RTP y ataques Man-in-the-Middle (MitM), la estrategia fundamental consiste en asegurar tanto el canal de señalización (donde se establecen las llamadas) como el canal de medios (donde viaja la voz).

Arquitectura de Protección VoIP

Capa	Protocolo Inseguro	Protocolo Seguro	Mecanismo de Protección
Señalización	SIP (UDP/TCP 5060)	SIPS / TLS (TCP 5061)	Cifra el intercambio de mensajes SIP, SDP y la negociación de claves.
Audio / Medios	RTP (UDP)	SRTP (UDP)	Cifra el flujo de datos de audio/video y garantiza la integridad de los paquetes.
Intercambio de Claves	Texto plano	SDES / DTLS-SRTP	Negocia dinámicamente las subclaves de cifrado AES entre los extremos.

Mejores Prácticas de Implementación

1. Cifrar la señalización con SIP sobre TLS (SIPS)

• Eliminar el puerto 5060: Deshabilitar la señalización en texto claro y forzar el uso exclusivo del puerto seguro 5061.
  
  
• Validación de Certificados: Implementar una Entidad Certificadora (CA) privada o pública dentro de la infraestructura. Los softphones y teléfonos IP deben validar el certificado del PBX para evitar ataques de suplantación.
  
  
• Cifrado de SDP: Al cifrar el protocolo SIP, los parámetros SDP (Session Description Protocol) quedan protegidos, impidiendo que un atacante lea las direcciones IP, puertos o códecs de los flujos RTP.
  
  

2. Proteger el canal de voz con SRTP

• Cifrado Fuerte: Utilizar esquemas de cifrado robustos como AES-GCM (128 o 256 bits) o AES-CM (Counter Mode) con autenticación HMAC-SHA1 para prevenir la alteración de paquetes en tránsito.
  
  
• Modo Forzado (Enforced): Configurar el PBX y los endpoints para rechazar llamadas si la negociación SRTP falla. Nunca dejar la opción en modo opcional (prefer o optional).
  
  

3. Seleccionar el mecanismo adecuado de gestión de claves

• DTLS-SRTP (Recomendado): Utiliza un protocolo de intercambio de claves mediante Handshake DTLS sobre el canal de medios. Es el estándar utilizado en WebRTC y ofrece Perfect Forward Secrecy (PFS); si una clave maestra se compromete, las conversaciones pasadas no se pueden descifrar.
  
  
• ZRTP: Adecuado para arquitecturas punto a punto (peer-to-peer) sin necesidad de infraestructura de clave pública (PKI). Incluye verificación mediante un código corto de voz (Short Authentication String / SAS) para evitar ataques MitM.
  
  
• Evitar SDES estático: Aunque es común, SDES transmite las claves SRTP dentro del cuerpo SDP. Si la señalización SIP no está correctamente cifrada con TLS, las claves SRTP quedan expuestas en texto plano.
  
  

4. Segmentación de Red y Control de Acceso

• VLAN dedicada de Voz: Aislar el tráfico VoIP de la red de datos general. Esto impide que herramientas de captura en la LAN de usuarios tengan visibilidad del tráfico de señalización o RTP.
  
  
• SBC (Session Border Controller): Desplegar un SBC en el perímetro de la red para actuar como firewall VoIP, inspeccionar el tráfico SIP/SRTP, aplicar políticas de cifrado y ocultar la topología interna del PBX.
  
  
• Inactivar Códecs Inseguros: Deshabilitar códecs antiguos o no compatibles con los perfiles de protección SRTP activos en la organización.

Para implementar SIP sobre TLS (SIPS) y SRTP en Asterisk utilizando el canal moderno chan_pjsip, se debe configurar el transporte seguro global en pjsip.conf (o en los archivos de personalización de FreePBX) y luego habilitar las opciones de cifrado en la definición de las extensiones (endpoints).

1. Configuración del Transporte TLS (pjsip.conf)

Primero se define el transporte para escuchar en el puerto 5061 seguro y asociar los certificados SSL/TLS previamente generados.

Ini, TOML

; --- Transporte TLS ---
[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/asterisk/keys/asterisk.crt
priv_key_file=/etc/asterisk/keys/asterisk.key
ca_list_file=/etc/asterisk/keys/ca.crt
method=tlsv1_2                   ; Forzar TLS v1.2 o superior
verify_client=no                 ; Cambiar a 'yes' si se usan certificados de cliente
verify_server=yes

2. Configuración del Endpoint con SRTP Obligatorio

En la definición de la extensión (endpoint), se asocia el transporte TLS y se activa la protección de medios con SRTP mediante el intercambio de claves SDES o DTLS.

Ini, TOML

; --- Extensión Segura (Endpoint) ---
[1001]
type=endpoint
context=from-internal
auth=auth1001
aors=1001
transport=transport-tls          ; Fuerza el uso de TLS

; --- Configuración de Audio Seguro (SRTP) ---
media_encryption=sdes            ; Opciones: sdes, dtls, o zrtp
media_encryption_optimistic=no   ; 'no' fuerza que la llamada falle si no soporta SRTP
allow=!all,opus,ulaw,alaw

; --- Configuración DTLS (Obligatorio si se usa media_encryption=dtls o WebRTC) ---
dtls_verify=fingerprint
dtls_rekey=0
dtls_cert_file=/etc/asterisk/keys/asterisk.crt
dtls_private_key=/etc/asterisk/keys/asterisk.key
dtls_setup=actpass

[auth1001]
type=auth
auth_type=userpass
username=1001
password=ClaveSegura123!

[1001]
type=aor
max_contacts=1

3. Ajustes en FreePBX (Interfaz Gráfica)

Si utilizas la interfaz web de FreePBX en lugar de editar archivos manualmente, la configuración equivalente se realiza desde dos módulos:

1. Módulo Settings -> Asterisk SIP Settings -> Tab PJSIP:
   
   
   • En TLS Transport, establece Enable TLS en Yes.
     
     
   • Define la ruta de los certificados (generados en Admin -> Certificate Management).
     
     
   • Asigna el puerto de escucha (por defecto 5061).
     
     
2. Módulo Applications -> Extensions (en la extensión elegida):
   
   
   • Tab Advanced -> Transportation: Seleccionar TLS Only.
     
     
   • Tab Advanced -> Media Encryption: Seleccionar SRTP via via SDES o DTLS-SRTP.
     
     

4. Verificación desde la Consola de Asterisk

Tras recargar la configuración (asterisk -rx "module reload res_pjsip.so"), se puede comprobar el estado desde la CLI de Asterisk:

Bash

# Verificar que el transporte TLS está activo y escuchando en el puerto 5061
asterisk -rx "pjsip show transports"

# Comprobar que el endpoint tiene activado el transporte TLS y cifrado de medios
asterisk -rx "pjsip show endpoint 1001"

Para desplegar SIP sobre TLS en Asterisk mediante certificados autofirmados, el procedimiento requiere crear una Entidad Certificadora (CA) raíz local y, posteriormente, firmar el certificado de servidor que utilizará el PBX.

Paso 1: Crear el directorio de trabajo y la CA Raíz

Primero, genera la clave privada de la CA y su certificado autogenerado (válido por 10 años).

Bash

# 1. Crear directorio para almacenar las claves
mkdir -p /etc/asterisk/keys && cd /etc/asterisk/keys

# 2. Generar clave privada de la CA (RSA 4096 bits)
openssl genrsa -out ca.key 4096

# 3. Crear el certificado autofirmado de la CA
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \
  -subj "/C=ES/ST=Madrid/L=Madrid/O=OnlineTIS/CN=VoIP-Internal-CA"

Paso 2: Generar la solicitud (CSR) y el certificado del Servidor Asterisk

Crea la clave privada del PBX, la solicitud de firma y genera el certificado del servidor incluyendo la IP/FQDN del PBX en los Subject Alternative Names (SAN) para evitar errores de validación en los softphones.

Bash

# 1. Generar clave privada del servidor Asterisk
openssl genrsa -out asterisk.key 2048

# 2. Crear archivo de configuración temporal para los nombres alternativos (SAN)
cat <<EOF > asterisk_san.cnf
[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext

[dn]
C = ES
ST = Madrid
L = Madrid
O = OnlineTIS
CN = pbx.onlinetis.local

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = pbx.onlinetis.local
IP.1 = 192.168.1.100
EOF

# 3. Generar la solicitud de firma de certificado (CSR) usando la configuración SAN
openssl req -new -key asterisk.key -out asterisk.csr -config asterisk_san.cnf

# 4. Firmar el certificado del servidor con nuestra CA privada (Válido por 2 años)
openssl x509 -req -in asterisk.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out asterisk.crt -days 730 -sha256 -extfile asterisk_san.cnf -extensions req_ext

Paso 3: Ajustar permisos e integrar con Asterisk

Asterisk necesita acceder a las claves, pero la clave privada de la CA (ca.key) debe mantenerse protegida o fuera del servidor si este está expuesto.

Bash

# Ajustar propiedad al usuario de Asterisk
chown -R asterisk:asterisk /etc/asterisk/keys/

# Restringir permisos de lectura en las claves privadas
chmod 600 /etc/asterisk/keys/*.key
chmod 644 /etc/asterisk/keys/*.crt

Paso 4: Despliegue en los Endpoints (Teléfonos IP / Softphones)

Para que el handshake TLS no falle en los clientes:

1. Importar ca.crt: Distribuye e instala el archivo de la CA raíz (ca.crt) en el almacén de certificados de confianza de los teléfonos IP, dispositivos móviles o softphones (MicroSIP, Zoiper, Linphone).
   
   
2. Coincidencia del nombre: Asegúrate de que los teléfonos apunten al CN o IP definido en la sección [alt_names] del certificado (192.168.1.100 o pbx.onlinetis.local).

https://www.onlinetis.com