Asterisk en producción: fraude telefónico, refuerzo de seguridad y actualizaciones.

Por qué se ataca una central expuesta a internet

El proyecto Asterisk coloca su advertencia al inicio de su documentación de seguridad, en un recuadro marcado "Danger": "Improper configuration of Asterisk could allow unauthorized use of your facilities, potentially incurring substantial charges" (una configuración incorrecta de Asterisk podría permitir el uso no autorizado de sus instalaciones y generar cargos considerables).1 La misma página explica que la seguridad de Asterisk tiene dos partes: "network security (encryption, authentication) as well as dialplan security (authorization - who can access services in your pbx)", es decir, seguridad de red (cifrado, autenticación) y seguridad del dialplan (autorización: quién puede usar los servicios de su central).1 Esta guía sigue en gran parte esa división.

Los ataques son baratos y las herramientas son públicas. SIPVicious OSS, un conjunto de herramientas de auditoría de código abierto muy usado, se describe con claridad: permite "find SIP servers, enumerate SIP extensions and finally, crack their password" (encontrar servidores SIP, enumerar extensiones SIP y, por último, descifrar sus contraseñas).8 Su herramienta svmap, "when launched against ranges of ip address space, it will identify any SIP servers which it finds on the way" (al ejecutarse contra rangos de direcciones IP, identifica cualquier servidor SIP que encuentre).8 Todo lo que escuche en un puerto SIP público será encontrado, sin importar quién haga el escaneo. Dé por hecho que el escaneo ya ocurrió.

La ganancia del atacante son las llamadas mismas. La guía del consumidor de la FCC sobre el robo de buzones de voz describe la versión empresarial: los piratas informáticos "change outgoing messages so they will accept automated international collect calls" (cambian los mensajes salientes para aceptar llamadas internacionales de cobro revertido automatizadas) o ingresan a la "voicemail system's call forwarding feature, programs the system to forward calls to an international number, then uses it to make calls" (función de desvío de llamadas del buzón de voz, programan el sistema para desviar llamadas a un número internacional y luego lo usan para llamar).7 También dice cuándo y cómo se enteran las víctimas: los atacantes "may try to break into business voicemail systems during holiday periods or weekends" (pueden intentar entrar a los buzones de voz de empresas durante feriados o fines de semana) y "business victims may not find out they've been hacked until their phone company reports unusual activity" (las empresas afectadas pueden no enterarse hasta que su compañía telefónica reporte actividad inusual).7 La página de la FCC trata del buzón de voz, pero el mismo patrón vale para una central telefónica: conseguir tono de marcar en algún lugar, dirigirlo a destinos caros y acumular la factura mientras nadie mira.

El archivo de mejores prácticas del código fuente de Asterisk es directo sobre el costo: las contraseñas débiles lo exponen a "expensive long distance calls that could potentially cost your company hundreds or thousands of dollars on an expensive monthly phone bill, with little to no recourse to fight the charges" (costosas llamadas de larga distancia que podrían costarle a su empresa cientos o miles de dólares en la factura mensual, con poca o ninguna posibilidad de impugnar los cargos).5 Existen estimaciones de pérdidas del sector, pero no pudimos leer ninguna en su fuente, así que esta página no cita ninguna cifra de pérdidas.

Las tres vías de entrada

En Asterisk, casi todo el fraude telefónico entra por una de tres vías. Cada una corresponde a una sección más abajo.

1. Credenciales. Un atacante se registra como uno de sus teléfonos, o envía llamadas como si lo fuera, adivinando su contraseña. El archivo de mejores prácticas advierte que "many of the current exploits deal with device configurations which utilize a number, and even worse, a password that matches the devices name" (muchos de los ataques actuales aprovechan configuraciones de dispositivos que usan un número y, peor aún, una contraseña igual al nombre del dispositivo), y da el ejemplo de un dispositivo llamado 1000 con la contraseña 1000.5
2. Exposición del dialplan. Una llamada que nunca se autenticó llega a un contexto que puede marcar hacia afuera, o un patrón que solo debería coincidir con extensiones pasa la cadena marcada directamente a Dial(). La página de seguridad del dialplan del proyecto enuncia la regla: "Use the extension contexts to isolate outgoing or toll services from any incoming connections" (use los contextos de extensión para aislar los servicios salientes o de pago de cualquier conexión entrante).2
3. Interfaces de administración. La Asterisk Manager Interface (AMI) y la interfaz REST (ARI) pueden originar llamadas y asignar variables. El archivo de mejores prácticas dice: "you should treat the Manager class authorization 'originate' the same as the class authorization 'system'" (debe tratar la autorización de clase Manager 'originate' igual que la de clase 'system').5

Hay una cuarta vía que no depende de Asterisk: el buzón de voz y las funciones de acceso remoto que permiten a quien llama llegar a un tono de marcar. El consejo de la FCC para buzones de voz empresariales también aplica aquí: "Disable remote notification, auto-attendant, call-forwarding and out-paging features if you don't use them" (desactive la notificación remota, la operadora automática, el desvío de llamadas y el localizador externo si no los usa) y "Consider blocking international calls" (considere bloquear las llamadas internacionales).7

¿Quién llama? Identificación en PJSIP y ACL

Toda solicitud SIP entrante a chan_pjsip se asocia primero con un endpoint. Esa asociación decide qué credenciales se verifican y a qué contexto del dialplan entra la llamada, por lo que es la primera decisión de seguridad que toma Asterisk. La configuración de ejemplo enumera los métodos: hacer coincidir el nombre de la sección del endpoint con el usuario del encabezado From, hacer coincidir un AOR con el encabezado To de un REGISTER o, "with an identify type section configured", hacer coincidir "an inbound SIP request of any type to an endpoint or aor based on the IP source address of the request" (con una sección de tipo identify configurada, una solicitud SIP entrante de cualquier tipo con un endpoint o AOR según la dirección IP de origen).6

El orden se define globalmente con endpoint_identifier_order, cuyo valor predeterminado es ip,username,anonymous.6 Por endpoint, identify_by es por defecto username,ip.6 Dos detalles del ejemplo conviene conocer antes de escribir una sección identify:

• "If multiple matching criteria are provided then an inbound request will be matched to the endpoint if it matches ANY of the criteria" (si se indican varios criterios, una solicitud entrante coincide con el endpoint si cumple CUALQUIERA de ellos).6 Agregar un match_header a una identificación por IP la hace más laxa, no más estricta.
• La opción match acepta "IP addresses, networks, or hostnames" (direcciones IP, redes o nombres de host), y las búsquedas SRV de nombres de host están activadas por defecto.6 Un identify que coincide con un nombre de host confía en lo que ese nombre resuelva. Nuestra opinión: para las troncales, indique las direcciones de señalización publicadas por el proveedor como IP literales o redes.

La identificación por IP es tan buena como el código que la respalda, y por eso importan las versiones de parche. El aviso CVE-2024-35190 informó que en Asterisk 18.23.0, 20.8.0 y 21.3.0, res_pjsip_endpoint_identifier_ip "wrongly matches ALL unauthorized SIP requests" (asocia por error TODAS las solicitudes SIP no autorizadas) con un endpoint identificado por IP, con el impacto declarado "Unauthorized access/calls" (acceso o llamadas no autorizados); se corrigió en 18.23.1, 20.8.1 y 21.3.1.10 El endpoint de la troncal es justamente el que usted dejó sin autenticación entrante a propósito, así que es el peor lugar para un error de identificación.

Las llamadas anónimas están desactivadas. Déjelas así.

El ejemplo es explícito: "By default anonymous inbound calls via PJSIP are not allowed. If you want to route anonymous calls you'll need to define an endpoint named 'anonymous'" (por defecto no se permiten llamadas anónimas entrantes por PJSIP; para enrutarlas debe definir un endpoint llamado 'anonymous') y "It is not recommended to accept anonymous calls" (no se recomienda aceptar llamadas anónimas).6 Si alguien en su organización creó alguna vez un endpoint [anonymous] para que las llamadas por URI SIP llegaran a un menú, su contexto no debe contener nada que pueda llegar a una troncal. El ejemplo hace el mismo planteamiento con el endpoint saliente predeterminado, que configura con context=none-invalid.6

ACL antes que nada

Una sección type=acl en pjsip.conf "is independent of individual endpoint configuration and operates on all inbound SIP communication using res_pjsip" (es independiente de la configuración de cada endpoint y opera sobre toda la comunicación SIP entrante que usa res_pjsip).6 Admite permit/deny sobre la dirección de origen, contact_permit/contact_deny sobre el encabezado Contact y referencias a ACL con nombre en acl.conf.6 Las ACL con nombre "can be shared across multiple modules" (pueden compartirse entre varios módulos; el Manager, chan_pjsip y chan_iax2 figuran como consumidores) y pueden guardarse en realtime, aunque "an ACL updated in an ARA backend will not be propagated automatically to consumers using static configuration" (una ACL actualizada en un backend ARA no se propaga automáticamente a los consumidores con configuración estática).9 El propio consejo del ejemplo es el valor predeterminado correcto: "If possible, restrict access to only networks and addresses you trust" (si es posible, restrinja el acceso solo a redes y direcciones de confianza).6

Una última opción filtra información. allow_unauthenticated_options es por defecto "no"; si la activa, "an external party could enumerate and find the endpoint name by sending OPTIONS requests and examining the responses" (un tercero podría enumerar y encontrar el nombre del endpoint enviando solicitudes OPTIONS y examinando las respuestas).6 Déjela desactivada salvo que un dispositivo no pueda funcionar sin ella.

Credenciales que resisten un ataque de diccionario

El archivo de mejores prácticas recomienda nombrar los dispositivos con algo que no sea un número de extensión, como la dirección MAC del teléfono, y combinarlo con una contraseña robusta; su ejemplo es una mezcla de doce caracteres con mayúsculas, minúsculas, dígitos y símbolos. Añade una advertencia que aplica a todo sistema de pruebas: "Some of the holes found in production systems used for exploitations involve finding the one test extension that contains a weak password that was forgotten prior to putting a system into production" (algunas de las brechas halladas en sistemas de producción provienen de encontrar la única extensión de prueba con una contraseña débil que se olvidó antes de pasar a producción).5 Como estos secretos solo se pegan en un archivo de configuración y en el aprovisionamiento del teléfono, no hay razón para que sean cortos. Nuestra opinión: genere 24 o más caracteres aleatorios por dispositivo y no reutilice ninguno.

Asterisk también admite ahora algoritmos de resumen (digest) más fuertes. "With the release of Asterisk 20.12.0, 21.7.0 and 22.2.0 and the associated release of PJProject 2.15.1, the chan_pjsip channel driver now supports the SHA-256 and SHA-512-256 authentication digest hash algorithms in addition to the base MD5 algorithm" (con las versiones 20.12.0, 21.7.0 y 22.2.0 de Asterisk y PJProject 2.15.1, el controlador chan_pjsip admite los algoritmos SHA-256 y SHA-512-256 además de MD5), según las versiones de PJProject y OpenSSL instaladas.11 La documentación actual describe auth_type=digest como el mecanismo y userpass como un valor obsoleto que "will automatically be converted to 'digest'" (se convertirá automáticamente a 'digest').11 Los valores predeterminados globales de algoritmos ofrecidos y aceptados siguen siendo MD5,6 así que SHA-256 es algo que usted activa, teléfono por teléfono, a medida que sus equipos lo admitan.

Tres reglas más provienen directamente de la configuración de ejemplo:

• Puede guardar un password_digest (un hash de username:realm:password) en lugar de una contraseña en texto plano,6 de modo que un pjsip.conf filtrado no entregue el secreto en forma legible.
• "Using the same auth section for inbound and outbound authentication is not recommended" (no se recomienda usar la misma sección auth para la autenticación entrante y saliente).6 Mantenga separadas las credenciales que le emitió su proveedor de las que usan sus teléfonos.
• Las opciones unidentified_request_count, _period y _prune_interval generan un evento de seguridad cuando una dirección envía demasiadas solicitudes que no coinciden con ningún endpoint (valores predeterminados: 5 solicitudes en 5 segundos). Solo aplican cuando la coincidencia por auth_username está en endpoint_identifier_order.6

Los contextos son la frontera de seguridad

Esta es la sección más importante de la guía. La documentación de Asterisk enuncia el principio: "if any channel, incoming line, etc. can enter an extension context that it has the capability of accessing any extension within that context" (si cualquier canal, línea entrante, etc. puede entrar a un contexto de extensiones, tiene capacidad de acceder a cualquier extensión de ese contexto). Por eso "you should not allow access to outgoing or toll services in contexts that are accessible (especially without a password) from incoming channels" (no debe permitir el acceso a servicios salientes o de pago en contextos accesibles, sobre todo sin contraseña, desde canales entrantes) y "never ever put outgoing toll services in the 'default' context" (nunca ponga servicios salientes de pago en el contexto 'default').2 Construya el dialplan en capas: el context= de una troncal llega solo a su menú y a sus DID, y el contexto de cada teléfono hace include únicamente de las clases de llamadas salientes que ese teléfono puede usar.

Nunca pase cadenas no confiables a Dial()

El archivo de mejores prácticas muestra la inyección clásica. Con exten => _X.,n,Dial(PJSIP/${EXTEN}), quien envíe la cadena 500&PJSIP/itsp/14165551212 convierte la marcación de su extensión en una segunda llamada saliente por su proveedor. Las soluciones que ofrece son "stricter pattern matching, or using the FILTER() dialplan function" (coincidencia de patrones más estricta o la función FILTER() del dialplan).5 FILTER(allowed-chars,string) "permits all characters listed in allowed-chars, filtering all others outs" (permite todos los caracteres de allowed-chars y filtra los demás).14 El mismo archivo advierte que los valores de identificador de llamada pasados a System(), MixMonitor() o SHELL() "can allow injection of arbitrary operating system command execution" (pueden permitir la inyección de ejecución arbitraria de comandos del sistema operativo).5

La trampa norteamericana: llamadas internacionales que empiezan con 1

El Plan de Numeración Norteamericano (NANP) es "an integrated telephone numbering plan serving 20 North American countries" (un plan de numeración telefónica integrado que atiende a 20 países norteamericanos), entre ellos Estados Unidos, Canadá, Bermudas, Bahamas, Jamaica, República Dominicana y otros países del Caribe.12 Una llamada de Toronto o Chicago a Kingston, Jamaica, se marca como 1 más diez dígitos, igual que una llamada de larga distancia nacional. Por eso un dialplan que bloquea 011 pero permite _1NXXNXXXXXX sigue permitiendo llamadas a otros 18 países. El informe de códigos de área de NANPA enumera los códigos de uso general en servicio fuera de EE. UU. y Canadá: 242, 246, 264, 268, 284, 345, 441, 473, 649, 658, 664, 721, 758, 767, 784, 809, 829, 849, 868, 869 y 876, y lista el 900 como "Easily Recognizable Code" (código fácilmente reconocible) para "Premium Services" (servicios de tarifa especial).13 (Los territorios de EE. UU., como Puerto Rico y Guam, figuran bajo EE. UU.)13 Lo mismo aplica en Canadá, que comparte el plan.12

El ejemplo siguiente permite números de EE. UU. y Canadá, envía a un rechazo los 21 códigos que no son de EE. UU. ni Canadá y el 1-900, limita las llamadas salientes simultáneas y mantiene la marcación internacional en un contexto aparte que solo se incluye donde hace falta. Usa REGEX("regular expression" string), que devuelve "'1' on regular expression match or '0' otherwise" ('1' si la expresión regular coincide o '0' en caso contrario),15 y GROUP() / GROUP_COUNT(), que cuentan los canales de un grupo con nombre (cada canal puede pertenecer a "exactly one group per category", exactamente un grupo por categoría).1617

; extensions.conf (excerpt). Trunk endpoint "itsp" uses context=from-itsp.

[from-itsp]                       ; reached by unauthenticated trunk traffic
exten => 5550100,1,Goto(main-menu,s,1)   ; your DID(s) only; nothing here dials out

[from-phones]                     ; context= of every desk phone endpoint
include => internal
include => emergency
include => outbound-nanp
; outbound-intl is NOT included here; give it to the few phones that need it

[emergency]                       ; 911 with no prefix, and with the 9 users may dial
exten => 911,1,Dial(PJSIP/911@itsp)
exten => 9911,1,Dial(PJSIP/911@itsp)

[outbound-nanp]
exten => _NXXNXXXXXX,1,Goto(1${EXTEN},1)
exten => _1NXXNXXXXXX,1,GotoIf(${REGEX("^1(900|242|246|264|268|284|345|441|473|649|658|664|721|758|767|784|809|829|849|868|869|876)" ${EXTEN})}?refuse,1)
 same => n,Set(GROUP(trunk)=itsp-out)
 same => n,GotoIf($[${GROUP_COUNT(itsp-out@trunk)} > 4]?busy,1)
 same => n,Dial(PJSIP/${EXTEN}@itsp,60)
 same => n,Hangup()
exten => refuse,1,Playback(silence/1&invalid)
 same => n,Hangup()
exten => busy,1,Congestion(5)

[outbound-intl]
exten => _011X.,1,Set(GROUP(trunk)=itsp-intl)
 same => n,GotoIf($[${GROUP_COUNT(itsp-intl@trunk)} > 1]?busy,1)
 same => n,Dial(PJSIP/${FILTER(0-9,${EXTEN})}@itsp,60)
 same => n,Hangup()
exten => busy,1,Congestion(5)

Nuestra opinión sobre el límite de simultaneidad: es el control más barato de esta página. Elija el número de llamadas externas simultáneas que su negocio realmente hace, súmele una y fije el límite ahí, porque un fraude casi siempre abre muchas llamadas a la vez. Pida también a su proveedor un límite de gasto y el bloqueo de llamadas internacionales en la cuenta. Esos controles están fuera de su servidor, así que siguen funcionando cuando todo lo que hay en el servidor ha fallado.

Por último, el consejo de mantenimiento de la documentación: "Do not forget to take the demo context out of your default context" (no olvide quitar el contexto de demostración de su contexto default).2

AMI, ARI y el servidor HTTP

La interfaz Manager está desactivada en el ejemplo (enabled = no), y su variante web además requiere el servidor HTTP de Asterisk y webenabled, ambos "default to no" (por defecto en no). El mismo ejemplo la enlaza a bindaddr = 0.0.0.0 en el puerto 5038, así que si la activa, cambie la dirección de enlace a 127.0.0.1.19 La página de seguridad de red aconseja que, si la activa, "make sure that you access manager in a safe environment or protect it with SSH or other VPN solutions" (asegúrese de acceder al manager en un entorno seguro o protéjalo con SSH u otra solución de VPN).3 Cada usuario del manager también admite líneas permit/deny.19

Trate originate como equivalente a root. El archivo de mejores prácticas muestra una acción Originate que ejecuta la aplicación System y señala que "the Manager action Originate allows for channel variables to be set by the account initiating the new call" (la acción Originate del Manager permite que la cuenta que inicia la nueva llamada asigne variables de canal).5 El aviso CVE-2024-42365 demostró en la práctica que un usuario con solo write=originate podía usar Set con FILE o CURL para "change all configuration files in the /etc/asterisk/ directory" (cambiar todos los archivos de configuración del directorio /etc/asterisk/); se corrigió en 18.24.2, 20.9.2 y 21.4.2.20

Dos opciones de asterisk.conf limitan el daño. live_dangerously controla "the execution of 'dangerous' dialplan functions and configuration file access from external sources (AMI, etc.)" (la ejecución de funciones "peligrosas" del dialplan y el acceso a archivos de configuración desde fuentes externas, como AMI), por ejemplo SHELL,21 y "In Asterisk 12 and later, live_dangerously defaults to no" (desde Asterisk 12, live_dangerously es no por defecto).5 runuser y rungroup definen la cuenta con la que se ejecuta Asterisk.21 El archivo de mejores prácticas menciona "not running Asterisk as root" (no ejecutar Asterisk como root) como algo que "can prevent serious problems" (puede evitar problemas graves).5 Ninguna de las dos es un muro completo: CVE-2026-57202 (junio de 2026) mostró que un usuario de ARI con credenciales de solo lectura podía usar setChannelVar para eludir live_dangerously y escribir con FILE(). El aviso señala que el servidor HTTP está "disabled by default" (desactivado por defecto) y, cuando se activa, "bound only to 127.0.0.1 by default" (enlazado solo a 127.0.0.1 por defecto).22 Mantenga esos valores salvo que tenga un motivo para cambiarlos.

El marco de eventos de seguridad y el registro

Asterisk genera eventos de seguridad estructurados desde sus controladores de canal e interfaces. Los tipos de evento están definidos en el código fuente e incluyen verificaciones de ACL fallidas, identificadores de cuenta no válidos, límites de sesión y de memoria, solicitudes no permitidas, direcciones inesperadas, respuestas de desafío fallidas, contraseñas no válidas, autenticaciones exitosas y transportes no válidos.23 El módulo res_security_log se suscribe a ellos y escribe cada uno en un nivel de registro llamado SECURITY.24

Ese nivel no va a ninguna parte hasta que usted lo enruta. El logger.conf de ejemplo enumera security como nivel y trae la línea del archivo comentada: ;security.log => security. Las líneas activas por defecto son console => notice,warning,error y messages.log => notice,warning,error.25 Quite el comentario de la línea de seguridad. La página sobre registros también advierte que "Asterisk log files, as well as information printed to the Asterisk CLI, may contain sensitive information such as passwords and call history" (los archivos de registro de Asterisk, así como la información mostrada en la CLI, pueden contener información sensible como contraseñas e historial de llamadas), así que restrinja quién puede leerlos.4 El ejemplo también desaconseja con firmeza el registro de depuración en producción, porque "Debug mode turns on a LOT of extra messages" (el modo de depuración activa MUCHOS mensajes adicionales).25

; /etc/asterisk/logger.conf
[logfiles]
console => notice,warning,error
messages.log => notice,warning,error
security.log => security

fail2ban: un respaldo útil, no un control

fail2ban incluye un filtro asterisk. Reconoce varios tipos de línea: entradas SecurityEvent="FailedACL", "InvalidAccountID", "ChallengeResponseFailed" e "InvalidPassword" con un RemoteAddress; los fallos de solicitud de PJSIP "No matching endpoint found", "Not match Endpoint ACL" y "Failed to authenticate"; y mensajes más antiguos de fallo de registro.26 El prefijo de registro del filtro acepta los niveles NOTICE, SECURITY y WARNING.26

La jaula (jail) estándar está menos lista para usarse de lo que parece. En el jail.conf de fail2ban, [asterisk] vigila los puertos 5060,5061 en TCP y UDP con maxretry = 10, y su logpath es /var/log/asterisk/messages.27 El ejemplo de Asterisk llama al archivo messages.log, y los eventos de seguridad solo llegan a un archivo al que usted los haya enrutado.25 Los empaquetadores pueden cambiar cualquiera de los dos nombres, así que verifique qué archivos existen en su sistema. Si la jaula apunta a un archivo que no existe o que nunca recibe eventos de seguridad, no bloquea nada y nada se lo advierte. La propia instrucción de fail2ban es "YOU SHOULD NOT MODIFY THIS FILE" (NO DEBE MODIFICAR ESTE ARCHIVO), y los cambios pertenecen "in a jail.local file or a jail.d/customisation.local" (en un archivo jail.local o en jail.d/customisation.local).27 Sus valores globales predeterminados son bantime = 10m, findtime = 10m y maxretry = 5.27

# /etc/fail2ban/jail.d/asterisk.local
[asterisk]
enabled  = true
logpath  = /var/log/asterisk/security.log
           /var/log/asterisk/messages.log
maxretry = 5
findtime = 10m
bantime  = 1h

Nuestra opinión: fail2ban reduce el ruido y frena la adivinación de contraseñas, pero solo actúa después de que ocurren los fallos y no puede ver una llamada correctamente autenticada que no debió permitirse. Las ACL, los secretos robustos y un dialplan estrecho previenen el fraude. fail2ban solo mantiene legible el registro.

Cortafuegos para SIP y RTP

La página de seguridad de red recuerda que una instalación de ejemplo "will open a few ports for accepting VoIP calls" (abrirá algunos puertos para aceptar llamadas VoIP) y que debe revisar "the channel configuration files for the ports and IP addresses" (los archivos de configuración de canal para ver los puertos y direcciones IP).3 En la práctica hay tres grupos de puertos:

• Señalización SIP en lo que cada transporte PJSIP defina con bind: por convención 5060 para UDP/TCP y 5061 para TLS, que son también los puertos que supone la jaula de fail2ban.2729
• Medios RTP en el rango de rtp.conf. El ejemplo fija rtpstart=10000 y rtpend=20000, y su comentario da los valores compilados por defecto como 5000 y 31000.28 Abra exactamente el rango que configure. El ejemplo de NAT de Asterisk redirige "UDP 10000-20000".31
• Administración: AMI (puerto 5038 en el ejemplo, 5039 para su escucha TLS) y el servidor HTTP no deben ser accesibles desde internet en absoluto.19

Strict RTP viene activado por defecto: "will drop RTP packets that do not come from the recognized source of the RTP stream" (descarta los paquetes RTP que no provienen del origen reconocido del flujo RTP), y aprende el origen al inicio de la llamada y en cada renegociación.28 Lo protege contra flujos de medios inyectados o secuestrados, así que déjelo activado.

La regla más eficaz no tiene que ver con puertos. Si sus teléfonos están en la red local o en una VPN y su proveedor publica sus direcciones de señalización, permita SIP solo desde esas direcciones y descarte todo lo demás en el cortafuegos. Los escáneres nunca llegan a Asterisk, fail2ban no tiene nada que hacer y la ACL se vuelve una segunda capa. Un fragmento ilustrativo de nftables (las direcciones son rangos reservados para documentación):

table inet pbx {
  set itsp { type ipv4_addr; flags interval; elements = { 203.0.113.0/28 } }
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    ip saddr 192.0.2.0/24 accept                      # office LAN
    ip saddr @itsp udp dport 5060 accept              # provider signalling
    ip saddr @itsp tcp dport 5061 accept              # provider TLS, if used
    udp dport 10000-20000 accept                      # RTP, matches rtp.conf
    tcp dport 22 ip saddr 192.0.2.0/24 accept         # admin from LAN only
  }
}

RTP debe quedar abierto a cualquier dirección, porque los medios pueden llegar desde servidores de medios del proveedor que no están en la lista de señalización. Strict RTP es lo que protege ese rango.28

TLS para la señalización, SRTP para los medios

La página de seguridad de red dice: "The SIP channel supports TLS encryption of the signaling, as well as SRTP (encrypted media)" (el canal SIP admite cifrado TLS de la señalización, además de SRTP, medios cifrados).3 El tutorial del proyecto indica que "SRTP support was added in Asterisk 1.8, TLS was added in 1.6" (SRTP se añadió en Asterisk 1.8 y TLS en 1.6), y muestra un transporte TLS de PJSIP con protocol=tls, bind=0.0.0.0:5061, cert_file, priv_key_file y method, además de un endpoint con media_encryption=sdes.29 También da una advertencia práctica: agregar transport=transport-tls a un endpoint provocó "Connection refused" en algunas situaciones con versiones antiguas de pjproject, y configurar rewrite_contact = yes puede ayudar.29

La regla que más importa: SDES-SRTP es tan privado como la señalización. SDES coloca las claves de los medios en el SDP. El RFC 4568 es explícito: "Implementations MUST employ security mechanisms that provide confidentiality and integrity for the keying material" (las implementaciones DEBEN emplear mecanismos de seguridad que den confidencialidad e integridad al material de claves) y, con SIP, "the application SHOULD employ either the SIPS URI or S/MIME" (la aplicación DEBERÍA emplear el URI SIPS o S/MIME).30 media_encryption=sdes sobre señalización UDP envía las claves en texto claro. Combine SDES con un transporte TLS, o use DTLS-SRTP (media_encryption=dtls). El atajo webrtc=yes del ejemplo fija media_encryption=dtls, dtls_verify=fingerprint y dtls_setup=actpass, y señala que "A dtls_cert_file and a dtls_ca_file still need to be specified" (todavía hay que especificar un dtls_cert_file y un dtls_ca_file).6

El valor predeterminado de media_encryption es "no", y media_encryption_optimistic hará "Use encryption if possible but don't fail the call if not possible" (usar cifrado si es posible, pero no fallar la llamada si no lo es).6 Para los teléfonos que usted controla, hágalo obligatorio. En una troncal de proveedor, si ofrece TLS y SRTP es una pregunta para el proveedor, y muchas troncales usan UDP y RTP sin cifrar. Si la suya es así, la regla de cortafuegos anterior (señalización solo desde el proveedor) es lo que tiene.

Los ejemplos del tutorial usan ast_tls_cert para crear una CA autofirmada, con un tamaño de clave de 2048 bits indicado explícitamente.29 Eso sirve para teléfonos que usted mismo aprovisiona. Para cualquier cliente que verifique el nombre del servidor, use un certificado cuyo nombre coincida con el host al que se conectan los teléfonos. El ejemplo señala que cert_file y priv_key_file "can be reloaded resulting in an updated certificate if the filename remains unchanged" (pueden recargarse y dar un certificado actualizado si el nombre de archivo no cambia),6 así que las renovaciones de rutina no requieren reiniciar.

NAT sin audio en un solo sentido

La mayoría de las instalaciones pequeñas ejecutan Asterisk en una dirección privada detrás de un enrutador. La página de NAT del proyecto menciona cuatro opciones que deben estar correctas: "local_net, external_media_address and external_signaling_address in the transport type section and direct_media in the endpoint section" (local_net, external_media_address y external_signaling_address en la sección de tipo transport, y direct_media en la sección del endpoint).31

• local_net: "the IP network that we want to consider our local network. For communication to addresses within this range, we won't apply any NAT-related settings" (la red IP que queremos considerar nuestra red local; para la comunicación con direcciones dentro de este rango no se aplica ningún ajuste de NAT).31 El ejemplo añade que las opciones external_ "will only apply to communication with addresses outside the range set with 'local_net='" (solo se aplicarán a la comunicación con direcciones fuera del rango definido con 'local_net=').6
• external_media_address: cuando el destino está fuera de local_net "and the media address in the SDP is within the localnet network, then the media address in the SDP will be rewritten" (y la dirección de medios del SDP está dentro de la red local, esa dirección se reescribirá) con este valor.31
• external_signaling_address: lo mismo para SIP, y ambas "should be set to the same address unless you separate your signaling and media to different addresses or servers" (deben tener la misma dirección, salvo que separe la señalización y los medios en direcciones o servidores distintos).31
• direct_media=no "ensures Asterisk stays in the media path" (asegura que Asterisk permanezca en la ruta de los medios), lo que importa porque el proveedor "cannot route to" (no puede enrutar hacia) una dirección privada.31

Para teléfonos remotos detrás del NAT de otra persona, la misma página remite a rtp_symmetric ("Send RTP back to the same address/port we received it from", enviar el RTP de vuelta a la misma dirección y puerto desde donde lo recibimos), force_rport, rewrite_contact y direct_media.31 force_rport es "yes" por defecto; rewrite_contact y rtp_symmetric son "no" por defecto.6 El rango RTP que redirija debe coincidir con rtp.conf.28

Nuestra opinión: el audio en un solo sentido después de un cambio en el cortafuegos casi siempre es una discrepancia entre el rango UDP redirigido y rtp.conf, o la falta de external_media_address. Revise ambos antes de tocar los códecs.

Troncales SIP: registro o identificación por IP

Un proveedor puede comunicarse con usted de dos maneras, y la configuración de ejemplo documenta ambas.

• Registro. Asterisk se registra con el proveedor mediante outbound_auth, de modo que el proveedor sabe adónde enviar sus llamadas. "This is a simple registration that works with some SIP trunking providers" (es un registro sencillo que funciona con algunos proveedores de troncales SIP).6 Con line=yes y endpoint=, se agrega un parámetro line al Contact para que las llamadas entrantes "related to the outbound registration" (relacionadas con el registro saliente) se asocien al endpoint configurado.6
• Identificación por IP. "There is no inbound authentication set up since a provider will not normally authenticate when calling you" (no hay autenticación entrante porque un proveedor normalmente no se autentica al llamarlo), por lo que una sección identify hace coincidir las direcciones del proveedor, ya que "the From user may be different every time" (el usuario del From puede ser distinto cada vez).6

La mayoría de los proveedores usan registro para poder encontrarlo a usted, e identificación por IP para que usted pueda reconocerlos. El ejemplo siguiente hace ambas cosas y agrega una ACL global, transportes separados, un teléfono nombrado por su dirección MAC y TLS con SRTP para el teléfono. Los nombres de sección pueden repetirse cuando su type es distinto.6 Los valores de NAT siguen el ejemplo de NAT del proyecto.31

; pjsip.conf: one trunk and one desk phone, hardened.
; Addresses are RFC 5737 documentation ranges; substitute your own.

[global]
type=global
endpoint_identifier_order=ip,username     ; no anonymous identifier
user_agent=PBX                            ; default is "Asterisk PBX"

[acl-sip]                                 ; applies to ALL inbound SIP
type=acl
deny=0.0.0.0/0.0.0.0
permit=203.0.113.0/28                     ; provider signalling
permit=192.0.2.0/24                       ; office LAN / VPN

[transport-udp-nat]
type=transport
protocol=udp
bind=0.0.0.0:5060
local_net=192.0.2.0/24
external_media_address=198.51.100.5
external_signaling_address=198.51.100.5

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/asterisk/keys/pbx.crt
priv_key_file=/etc/asterisk/keys/pbx.key
local_net=192.0.2.0/24
external_media_address=198.51.100.5
external_signaling_address=198.51.100.5

; ---------- trunk ----------
[itsp-reg]
type=registration
transport=transport-udp-nat
outbound_auth=itsp-auth
server_uri=sip:sip.provider.example
client_uri=sip:[email protected]
contact_user=5550100
line=yes
endpoint=itsp

[itsp-auth]                               ; issued by the provider; outbound only
type=auth
auth_type=digest
username=5550100
password=<from the provider portal>

[itsp]
type=endpoint
transport=transport-udp-nat
context=from-itsp                         ; DIDs and menu only
disallow=all
allow=ulaw
outbound_auth=itsp-auth
aors=itsp
direct_media=no
from_domain=sip.provider.example

[itsp]
type=aor
contact=sip:sip.provider.example
qualify_frequency=60                      ; default 0 = never checked

[itsp]
type=identify
endpoint=itsp
match=203.0.113.1
match=203.0.113.2

; ---------- desk phone, named by MAC ----------
[0004f2a1b2c3]
type=endpoint
transport=transport-tls
context=from-phones
disallow=all
allow=ulaw
auth=0004f2a1b2c3
aors=0004f2a1b2c3
media_encryption=sdes                     ; keys protected by TLS signalling
direct_media=no

[0004f2a1b2c3]
type=auth                                 ; inbound only, never shared
auth_type=digest
username=0004f2a1b2c3
password=<24+ random characters>

[0004f2a1b2c3]
type=aor
max_contacts=1
remove_existing=yes
qualify_frequency=60

Notas sobre las decisiones. endpoint_identifier_order=ip,username elimina el identificador anonymous predeterminado,6 de modo que una solicitud sin coincidencia no pueda caer en un endpoint anónimo aunque alguien lo agregue después. qualify_frequency es 0 por defecto,6 lo que significa que Asterisk nunca verifica la troncal y usted solo se entera de que está caída cuando un cliente no logra comunicarse. Si usa una versión anterior a 20.12.0, 21.7.0 o 22.2.0, compruebe si acepta auth_type=digest; userpass es el valor que usan las configuraciones antiguas, y las versiones actuales lo convierten automáticamente a digest.11

STIR/SHAKEN en Asterisk

El módulo STIR/SHAKEN de Asterisk, res_stir_shaken, fue reescrito. La documentación dice que "refers to the Stir/Shaken Refactor of 1Q2024. The earlier version was only partially functional and not interoperable with other implementations" (se refiere a la refactorización de Stir/Shaken del primer trimestre de 2024; la versión anterior solo funcionaba en parte y no era interoperable con otras implementaciones).32 Los registros de cambios ubican la refactorización en Asterisk 18.22.0, 20.7.0 y 21.2.0, con la nota de actualización "The stir-shaken refactor is a breaking change" (la refactorización de stir-shaken es un cambio incompatible), "existing ones WILL need to be changed" (las configuraciones existentes TENDRÁN que cambiarse), y una dependencia de libjwt v1.15.3 (o --with-libjwt-bundled).33 La versión 20.7.0 se publicó el 18 de marzo de 2024.47 El commit da el motivo: la implementación original "wouldn't actually interoperate with any other stir-shaken implementations" (en realidad no interoperaría con ninguna otra implementación de stir-shaken).34

La configuración vive en stir_shaken.conf, con cuatro tipos de objeto: un objeto attestation para firmar las llamadas salientes, objetos tn identificados por el número del identificador de llamada, que contienen la URL del certificado, el nivel de atestación y la clave privada, un objeto verification para las llamadas entrantes y objetos profile asociados a los endpoints PJSIP.32 Un endpoint se adhiere con stir_shaken_profile, y un perfil define endpoint_behavior (por ejemplo verify) y una failure_action.35

Antes de activarlo, conozca sus límites. La documentación enumera desviaciones de las especificaciones: Asterisk "does not validate the destination TN" (no valida el TN de destino), solo admite la forma completa de PASSporT, realiza "only basic validation of certificates" (solo una validación básica de los certificados: CA, fechas de validez y presencia de TNAuthList, pero no el Common Name) y solo verifica las CRL que usted haya configurado. También dice que "there is currently no way for Asterisk to verify that the SPC in the certificate has the authority over the TN in the Identity header" (actualmente Asterisk no tiene forma de verificar que el SPC del certificado tenga autoridad sobre el TN del encabezado Identity).32 La verificación también es superficie de ataque: CVE-2025-49832 informó una denegación de servicio remota y "possible RCE" (posible ejecución remota de código) en verification.c cuando la verificación está activada en un endpoint, corregida en 18.26.3, 20.15.1, 21.10.1 y 22.5.1.36

Firmar es la parte más difícil. La documentación dice que "For most Asterisk installation scenarios, you'd receive such a key/certificate from your upstream service provider when they issue you DID telephone numbers" (en la mayoría de las instalaciones de Asterisk, recibiría esa clave y ese certificado de su proveedor de servicio cuando le asignan números DID).32 Los certificados provienen de un régimen de gobernanza para proveedores de servicios. En Canadá es el CST-GA, "the national governance authority tasked to direct and oversee the STIR/SHAKEN Policy Administrator and Certification Authorities for Canada" (la autoridad nacional de gobernanza encargada de dirigir y supervisar al Administrador de Políticas y a las Autoridades de Certificación de STIR/SHAKEN en Canadá), cuyos participantes son "TSPs registered with the CRTC to provide voice services in Canada" (proveedores de servicios de telecomunicaciones registrados ante el CRTC para ofrecer servicios de voz en Canadá).37 Nuestra opinión: en una central de empresa detrás de una troncal de proveedor, normalmente es el proveedor quien firma sus llamadas salientes, y el nivel de atestación depende de lo que ese proveedor sepa sobre sus números. Ejecute res_stir_shaken usted mismo solo si es el proveedor de servicio, o si quiere leer los resultados de verificación de las llamadas entrantes, y en ese caso manténgalo actualizado.

CDR y CEL: su detector de fraude

Asterisk produce dos tipos de registros de llamadas. El registro CDR está activado por defecto (enable=yes),38 y desde Asterisk 12 "multiple CDRs will be created for a given call" (se crearán varios CDR para una misma llamada) según cómo se marquen y se unan los canales, por lo que "Post-processing of these records will be required to determine the overall statistics of the call" (se requerirá un posprocesamiento de estos registros para determinar las estadísticas generales de la llamada).39 Conviene conocer dos valores predeterminados: las llamadas sin contestar que no se ofrecen a una línea saliente no se registran (unanswered = no), y el modo por lotes "may result in data loss after unsafe asterisk termination" (puede causar pérdida de datos tras una terminación no segura de Asterisk).38

El Channel Event Logging (CEL) es un flujo más detallado de eventos de canal, "designed with billing information in mind" (diseñado pensando en la información de facturación), con backends como ODBC, PostgreSQL, SQLite y TDS.41 Está desactivado por defecto (enable es "no" por defecto). El ejemplo registra apps=dial,park y advierte que all "may affect Asterisk's performance significantly" (puede afectar significativamente el rendimiento de Asterisk).40 La especificación de CDR describe el CEL como la opción "if CDRs do not provide the billing information you need" (si los CDR no ofrecen la información de facturación que necesita).39

Nuestra opinión: no necesita un sistema de facturación para usar ninguno de los dos. Una consulta programada sobre la tabla de CDR que cuente las llamadas salientes por hora y las llamadas a cualquier destino fuera de sus prefijos permitidos es la alarma que detecta el ataque que describe la FCC, el que ocurre durante un fin de semana festivo.7 Envíe el resultado a un teléfono, no a un correo que nadie lee un sábado. Una nota de seguridad: CVE-2026-57190 (junio de 2026) fue una inyección SQL en cel_pgsql y cel_tds a través del campo de tipo de evento de CELGenUserEvent,44 así que el backend de registro es parte de lo que usted debe mantener actualizado.

Monitoreo y alertas

Lo que vigilaríamos en un sistema de producción pequeño y dónde lo expone Asterisk:

• Disponibilidad y registro de la troncal. Defina qualify_frequency en el AOR de la troncal (0 por defecto, es decir, nunca) para conocer el estado del contacto.6
• Métricas. res_prometheus ofrece estadísticas a un servidor Prometheus. Está desactivado por defecto ("enabling this without proper securing of your Asterisk system may result in external systems learning a lot about your Asterisk system", activarlo sin proteger bien su sistema Asterisk puede permitir que sistemas externos aprendan mucho sobre él), requiere el servidor HTTP, y el ejemplo recomienda "highly" (encarecidamente) la autenticación Basic en la ruta de métricas.42 Exporta métricas básicas (versión, tiempo en línea, tiempos de recarga y de recolección) y detalle de canales y puentes, y enumera res_pjsip y res_pjsip_outbound_registration entre sus dependencias de módulos.42
• Eventos de seguridad. Genere alertas por la tasa de entradas en security.log, no por entradas individuales. Un servidor público siempre tiene un fondo de fallos. Un cambio repentino en esa tasa, o una autenticación exitosa desde una dirección que no conoce, es la señal.23
• Volumen de llamadas. La consulta de CDR descrita arriba, más un umbral de canales simultáneos.
• Fuentes de versiones y avisos. Se tratan más abajo.

Copias de seguridad: qué copiar y cómo saber que funcionan

asterisk.conf indica dónde está todo. Los valores compilados por defecto suelen ser /etc/asterisk (configuración), /var/lib/asterisk (datos, claves y la base de datos interna, mediante astdbdir y astkeydir), /var/spool/asterisk (la cola, que guarda los buzones de voz y las grabaciones) y /var/log/asterisk. El ejemplo señala que la sección es una plantilla y que "the compiled-in defaults are typically sufficient" (los valores compilados por defecto suelen ser suficientes).21 Respalde las tres primeras, además de su base de datos de CDR/CEL y las claves TLS. Su distribución puede mover estas rutas, así que léalas de su propio asterisk.conf.

Nuestra opinión: la copia de seguridad de una central solo está probada cuando se restauró en una máquina nueva y esa máquina se registró en la troncal y completó una llamada. Hágalo una vez al construir el sistema y de nuevo tras cada actualización importante. Cifre las copias: contienen todos los secretos SIP que tiene.

Versiones de seguridad y la página de avisos

El proyecto publica los avisos en la página Security Advisories de asterisk.org,43 y desde 2023 en la pestaña Security del repositorio de GitHub: los informes anteriores están "On the projects GitHub repository unser the 'Security' tab. (reports for 2023 and later)" (en el repositorio de GitHub del proyecto, en la pestaña 'Security'; informes de 2023 en adelante) y "On the Asterisk downloads site. (reports for 2022 and earlier)" (en el sitio de descargas de Asterisk; informes de 2022 y anteriores), y "All security vulnerabilities are also issued a CVE number" (a todas las vulnerabilidades de seguridad también se les asigna un número CVE).45 Las vulnerabilidades se reportan en privado mediante el botón "Report a vulnerability" de GitHub, nunca en el rastreador público de incidencias.45

Las correcciones llegan por lotes, y los recientes han sido grandes. El 25 de junio de 2026 el proyecto publicó 20 avisos a la vez,44 con correcciones entregadas el mismo día en 20.20.1, 21.12.3, 22.10.1, 23.4.1 y las versiones certificadas 20.7-cert11 y 22.8-cert3.4647 Abarcan desde errores de análisis de PJSIP hasta problemas de ARI y H.323. Muchos no afectarán a un sistema dado, porque están en módulos que no carga. Ese es el argumento para eliminar los módulos que no usa: cada módulo que no carga es un aviso menos que leer.

Al 26 de octubre de 2026, las últimas versiones completas son 20.21.0, 22.11.0 y 23.5.0 (27 de agosto de 2026), y 24.0.0 está en el candidato a versión 3 (22 de octubre de 2026).47 Nuestra opinión sobre la cadencia: suscríbase a los avisos de GitHub del repositorio y a la página de asterisk.org,4344 lea cada aviso frente a su lista de módulos cargados y aplique las versiones de parche de seguridad en cuestión de días, no en la próxima ventana de mantenimiento. Una versión de parche de seguridad cambia muy poco; por eso es rápida de aplicar.

Estrategia de actualización entre versiones LTS

La política del proyecto: "A Long Term Support (LTS) release will be fully supported for 4 years, with one additional year of maintenance for security fixes" (una versión de soporte a largo plazo, LTS, tendrá soporte completo durante 4 años, con un año adicional de mantenimiento para correcciones de seguridad). Las versiones estándar reciben "at least one year of full support and an additional year of maintenance for security fixes" (al menos un año de soporte completo y un año adicional de mantenimiento de seguridad), y las versiones nuevas salen "roughly once a year, alternating between standard and LTS releases" (aproximadamente una vez al año, alternando entre estándar y LTS).48 Las ramas con soporte completo reciben actualizaciones de corrección de errores "roughly every 4 to 6 weeks" (aproximadamente cada 4 a 6 semanas), y las ramas en mantenimiento solo de seguridad se actualizan "on an as needed basis" (según sea necesario).48 El calendario anual fija la primera versión completa de una rama nueva el "3rd Thursday of October" (tercer jueves de octubre).48

Desplace la tabla hacia los lados para ver todas las columnas.

Las fechas provienen de la página Asterisk Versions.48 La última columna aplica esas fechas al día de hoy y a las etiquetas de versión publicadas.47 Cuando la leímos, la columna de estado de la propia página todavía mostraba 20.x y 23.x como "Fully Supported" (con soporte completo) y 24.x como "Pre-release" (versión preliminar). También señala que 21.x tuvo, "Due to a mistake in scheduling" (por un error de calendario), "supported for 2 years for bug fixes" (soporte de corrección de errores durante 2 años).48

La mayor decisión de actualización que aún enfrentan muchos sistemas antiguos es chan_sip. El registro de cambios de Asterisk 21.0.0 incluye "chan_sip: Remove deprecated module" (chan_sip: eliminar módulo obsoleto).49 Un sistema que sigue en sip.conf no puede pasar de la serie 20.x sin migrar a PJSIP, y la 20.x está ahora en mantenimiento solo de seguridad hasta octubre de 2027.48

Nuestra estrategia recomendada, presentada como opinión:

1. Use LTS en producción, no versiones estándar. Hoy eso significa 22.x, con soporte completo hasta octubre de 2028.48
2. Pase de una LTS a la siguiente, aproximadamente un año después de su publicación. Deje que la 24.x acumule algunas versiones de parche antes de adoptarla. Aun así tendrá años de traslape: la 22.x mantiene soporte completo hasta 2028.48
3. Lea cada registro de cambios y nota de actualización intermedios. La refactorización de STIR/SHAKEN llegó en versiones de parche de ramas existentes, como un cambio de configuración incompatible.33 Las versiones de parche no siempre son tan pequeñas como parecen.
4. Ensaye en una copia. Restaure la copia de seguridad de anoche en una máquina de prueba, actualícela y ejecute sus pruebas de llamadas: entrante al menú, una llamada saliente NANP, una llamada rechazada al 1-876, el enrutamiento del 911 (mediante un arreglo de prueba con su proveedor, nunca una llamada de emergencia real) y el depósito de un mensaje de voz. Luego repita en producción.

Lista de verificación de refuerzo de seguridad

Cada línea es algo que puede comprobar en un sistema en funcionamiento. La columna de motivo remite a la evidencia anterior.

Desplace la tabla hacia los lados para ver todas las columnas.

Si lo que necesita es un menú frente a los celulares de su equipo y no una central que administrar, ese es el problema para el que está hecho el servicio alojado de Auto Attendant (nada de esta página lo describe). Si necesita una central, la lista anterior es lo mínimo que querríamos tener en su lugar antes de darle una dirección pública.