Hace casi 2 años escribí un artículo sobre como mejorar los mensajes de código de error en llamadas por E1 para Elastix. El tiempo ha pasado y han habido cambios tanto en Asterisk como en Elastix, ocasionando que algunas partes de ese viejo post ya no funcionen, por lo que decidí reescribirlo y mejorarlo.
Este código les permitirá dar mensajes más descriptivos para los códigos de error Q931 que los enlaces digitales arrojan al momento en que una llamada sale mal. Con respecto del post anterior, estas son las mejoras:
Existen más códigos de error documentados.
Las voces son sintetizadas con acento neutro (para todos los que nos leen en América Latina, esto es más cómodo que el acento español que se tenía antes)
Ya solo se requiere meter el código en un único archivo .conf, no es necesario usar el .ael.
Según la versión de Elastix que estemos ocupando, el código debe insertarse en uno de los 2 archivos siguientes:
/etc/asterisk/extensions_override_elastix.conf
/etc/asterisk/extensions_override_freepbx.conf
Preferentemente usar el extensions_override_elastix.conf, pero si no existe, usar el otro. Coloquen este código al final del archivo:
[macro-outisbusy]
exten => s,1,Progress
exten => s,n,Set(MSG=all-circuits-busy-now&pls-try-call-later) ; Clausula default
exten => s,n,Goto(s-${HANGUPCAUSE},1)
; Numero no existe
exten => s-1,1,Set(MSG=no-existe)
; No hay una ruta para llegar a este equipo. Tratar como no existe
exten => s-2,1,Set(MSG=no-existe)
; Celular fuera de area de servicio
exten => s-20,1,Set(MSG=celular-no-disponible&intente-mas-tarde)
; Numero mal marcado
exten => s-28,1,Set(MSG=cannot-complete-as-dialed&check-number-dial-again)
; Numero fuera de servicio
exten => s-27,1,Set(MSG=fuera-servicio&intente-mas-tarde)
; Red fuera de servicio
exten => s-38,1,Set(MSG=fuera-servicio&intente-mas-tarde)
; Falla temporal en la red
exten => s-41,1,Set(MSG=falla-red&intente-nuevamente)
; Congestion por alta cantidad de trafico
exten => s-42,1,Set(MSG=alto-trafico&intente-mas-tarde)
; La central telefonica no dio respuesta
exten => s-102,1,Set(MSG=falla-red&intente-nuevamente)
; Problema de interconexion de carriers
exten => s-127,1,Set(MSG=no-proveedor&intente-mas-tarde)
exten => _s-.,n,Playback(${MSG},noanswer) ; Reproducir el mensaje
exten => _s-.n,Macro(hangupcall)
Los nuevos archivos de sonido pueden descargarse desde la liga Sonidos mejorados para Elastix. Recuerden que hay que desempaquetar el .zip y el contenido subirlo a la carpeta /var/lib/asterisk/sounds para que puedan reproducirse sin problemas.
Nosotros nunca recomendamos exponer la interfaz web de tu conmutador (entiéndase: FreePBX/Elastix/Trixbox) bajo ningún motivo. Sin embargo, hay casos específicos en los cuales puede existir la necesidad de abrir el puerto HTTP/HTTPS para algunos servicios (ej. un CRM o alguna aplicación in house). Si esto debe de hacerse, es mejor hacerlo teniendo en cuenta algunas funciones básicas de seguridad.
Si aplicáramos lo que vimos en nuestros artículos del modelo de seguridad en Asterisk veremos que no es posible defender a nivel de firewall externo/iptables, ya que no hay una manera de permitir el paso solamente a ciertas carpetas. Para lograrlo, debemos hacer uso de la configuración de Apache la cual nos permite aplicar un mini firewall interno que solo permitirá a ciertas IPs ver ciertas páginas.
Primero, localicemos el archivo /etc/httpd/conf/httpd.conf (en algunos casos cambia de nombre a /etc/apache2/httpd.conf, así que hay que buscarlo con calma). Lo que buscamos es encontrar una directriz que permite el acceso por default a toda nuestra carpeta /var/www/html. El default en Elastix lo encuentran escrito así:
<Directory "/var/www/html">
#
# Possible values for the Options directive are "None", "All",
# or any combination of:
# Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important. Please see
# http://httpd.apache.org/docs/2.2/mod/core.html#options
# for more information.
#
Options Indexes FollowSymLinks
#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride None
#
# Controls who can get stuff from this server.
#
Order allow,deny
Allow from all
</Directory>
Haciendo a un lado los comentarios, quedamos con estas instrucciones:
<Directory "/var/www/html">
SymLinksifOwnerMatch ExecCGI MultiViews
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Queremos ponerle atención a las lineas de Order allow,deny y Allow from all. Explicamos lo que quiere decir:
Order allow,deny quiere decir que las instrucciones están declaradas como Permite primero, niega después.
Allow from all es una cláusula que permite que todos vean todo (default), lo cual le quita todas las restricciones a los usuarios.
El primer paso consiste en cerrar todo y permitir el paso solamente a direcciones IPs de confianza. Esto lo podemos conseguir con lo siguiente:
<Directory "/var/www/html">
SymLinksifOwnerMatch ExecCGI MultiViews
Options Indexes FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 192.168.1.0/24
Allow from 127
Allow from 10.200.1.0/24
</Directory>
¿Notan la diferencia? Ahora estamos negando el paso a todo y permitiendo solamente que las redes de confianza 192.168.1.0/24, 10.200.1.0/24 y la de loopback tengan acceso completo al servidor. En otras palabras: solo las redes locales van a poder entrar a la administración web completa.
Para crear ahora carpetas sin restricción (ej. que cualquier usuario interno o externo las pueda ver), las agregamos como directrices nuevas:
<Directory "/var/www/html/vtigercrm" >
Order deny,allow
Allow from all
</Directory>
Y ahora estamos permitiendo el acceso completo a esa carpeta en particular (nuestro CRM). Por cada carpeta debemos crear una directiva <Directory> que permita el acceso.
Recuerden reiniciar el servicio de Apache:
/etc/init.d/httpd restart
# Según nuestra distro, el servicio se llama Apache2
/etc/init.d/apache2 restart
De esta manera, si abrimos http://<direccion ip publica>/vtigercrm podremos ver el CRM de nuestro equipo, pero si tratáramos de ver nuestra interfaz de administración con http://<direccion ip publica>/admin o http://<direccion ip publica>
Advertencia: Siempre asegúrate de probar tu configuración de seguridad antes de ponerla en producción. Nosotros nunca recomendamos exponer el puerto HTTP/HTTPS, ya que aunque al usar esta configuración no permites el paso a otros usuarios, no quiere decir que no haya vulnerabilidades en tu código mostrado por Apache, así que acepta el riesgo de exponer tu equipo así. Lo mejor que puedes hacer es crear un nuevo equipo que hostee tu aplicación y exponer ese, sin que tengas abierto lo mismo en tu conmutador.
Hace unos cuantos meses empecé a probar una aplicación para iOS/Android llamada Pushover que te permite crear notificaciones personalizadas de tipo push en tu móvil. El servicio es gratuito (solo debes comprar la aplicación que cuesta $4 USD) y te permite recibir hasta 7500 notificaciones al mes (suficientes creo yo). La aplicación es muy fácil de configurar: tras darte de alta solo debes registrar una aplicación (se te proporcionará un token al registrarla) y tomar nota de tu user key. Tras obtener esos datos, crea un script como el que sigue (puedes ponerlo en /sbin/push.php):
#!/usr/bin/php
<?php
// Reemplaza este valor por tu verdadero userKey de Pushover
$userKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
/**************************************************
Reemplaza este valor con el de tu propia aplicación.
Si no lo cambias recibirás notificaciones de parte de "Asterisk México"
(según la cantidad de usuarios que usen este token, pueden acabarse las notificaciones
permitidas por Pushover al mes
***************************************************/
$appToken="ptTjW6PlKHU7lB5jOdhLN7vHlKSIei";
curl_setopt_array($ch = curl_init(), array(
CURLOPT_URL => "https://api.pushover.net/1/messages.json",
CURLOPT_RETURNTRANSFER => true,
CURLOPT_POSTFIELDS => array(
"token" => $appToken,
"user" => $userKey,
"message" => $argv[1],
)));
curl_exec($ch);
curl_close($ch);
?>
No te olvides de hacer el script ejecutable:
chmod 755 /sbin/push.php
Con esto el script ya debe de enviarte notificaciones a tu teléfono. Puedes enviarte un mensaje de prueba para validarlo. Teclea en el CLI de Linux:
/sbin/push.php "Este es un mensaje de prueba"
Si lo ejecutas, deberas recibir una notificación como la siguiente:
Ejemplo de notificación de Pushover
Ahora toca decirle a Asterisk que nos envíe notificaciones. Vamos a ver el código necesario para 2 escenarios: Asterisk puro y Asterisk bajo FreePBX (Elastix/Trixbox)
Para Asterisk Puro:
Lo que necesitamos insertar es insertar una llamada a la aplicación System que invoque nuestra aplicación con los valores que necesitamos. Por ejemplo, supongamos que tenemos esta línea en nuestro plan de llamadas para hacer una marcación internacional (archivo extensions.conf):
exten => _00ZXXXX.,1,Dial(DAHDI/g0/${EXTEN})
Lo que requerimos es mandar llamar a la notificación antes de que se genere el Dial, quedando algo así:
exten => _00ZXXXX.,1,System(/sbin/push.php "Llamada de ${CALLERID(num)} hacia ${EXTEN}")
exten => _00ZXXXX.,n,Dial(DAHDI/g0/${EXTEN})
Es importante que escapemos correctamente las comillas » «, de lo contrario solo nos llegará la primer palabra del mensaje.
Si tratamos de marcar al exterior, recibiremos una notificación como la que sigue:
Notificaciones de llamadas de Asterisk en Pushover
Con esto ya quedan las notificaciones a nuestro sistema usando Asterisk puro.
Para FreePBX/Trixbox/Elastix:
Editamos el archivo de extensions_custom.conf y hacemos uso del hook que ya existe en FreePBX para no tener que modificar nuestro código:
[macro-dialout-trunk-predial-hook]
exten => s,1,System(/sbin/push.php "Llamada de ${CALLERID(num)} hacia ${OUTNUM}")
Ojo: esto enviará notificaciones por cada llamada que use troncales. Si quieren que solo se use para cierto tipo de llamadas, necesitan validar la variable ${OUTNUM} para que solo contenga los números que ustedes quieran.
Este tutorial fue escrito por uno de los participantes de nuestro foro: navaismo.
El artículo original lo pueden encontrar aquí.
En algunas ocasiones nos vemos en la necesidad de crear un Cluster de alta disponibilidad para nuestros servicios de Asterisk. A continuación se describen los pasos necesarios para llevar esto acabo en nuestros servidores usando Asterisk y Mysql(por si queremos usar Asterisk Realtime Architechture).
Algunas indicaciones iniciales:
Estos pasos están basados en las instrucciones que brinda Digium y los tutoriales de DRBD para Mysql.
Este tutorial no esta hecho para hacer copy&paste.
El color verde indica que son pasos para realizar en ambos servidores.
El color Naranja indica que son pasos para realizar en el servidor primario.
El color Rojo indica que son pasos para realizar en el servidor secundario.
El Hostname del Servidor primario es «node1«.
El Hostname del Servidor secundario es «node2«.
La dirección IP del servidor primario es 10.0.1.51
La dirección IP del servidor secundario es 10.0.1.52
La dirección IP compartida del cluster y a la que deberán apuntar los servicios(como el registro de teléfonos, MySQL o apache) es 10.0.1.50.
La dirección IP del Gateway es 10.0.1.1.
Se puede adaptar fácilmente el Hardware Failover que provee Digium(rseries) y los servicios de Apache.
La Imagen anterior describe el funcionamiento del Cluster:
Escenario 1: El servidor primario esta activo y el secundario esta en modo pasivo esperando.
Escenario 2: El servidor Primario ha entrado en estado de falla(por conexión de RED o por reinicio o falla en el kernel), el servidor secundario entonces, se convierte en el servidor primario y es marcado como activo.
Escenario 3: El servidor secundario(antes primario) se ha recuperado de la falla y ha entrado en modo pasivo.
Escenario 4: El servidor primario(antes secundario) ha presentado falla y el servidor secundario(antes primario) es marcado como servidor primario nuevamente y entra en modo activo.
Paso 1 —- Realizar en Ambos Servidores:
Instala CentOS 5.X(Los agentes de recursos «ocf»de Digium no son compatibles con las versiones 6.X de CentOS). Escoger el modo de partición manual y dejar un espacio libre sin formateo ni nada, en este tutorial yo he dejado 5GB sin particionar. Este espacio será donde guardemos nuestros datos a replicar en el Cluster, así que deberán considerar cuanto espacio necesitaran para sus archivos y logs.
Paso 2 —- Realizar en Ambos Servidores:
Instala las dependencias para nuestros servidores. Primero añadiré el repositorio de rpmforge:
Selecciona el espacio libre y crea una nueva partición con todo el espacio libre usando los botones: New, Primary, Write. Al finalizar te preguntara si quieres efectuar los cambios, escribe la palabra: yes y da enter.
Cuando el proceso termine reinicia el servidor:
reboot
Una vez que el servidor haya arrancado de nuevo hay que limpiar la nueva partición usando el siguiente comando:
dd if=/dev/zero of=/dev/[hs]da[#] bs=1M; sync
Cambia /dev/[hs]da[#] por tu dispositivo que puede ser SDA3,HDA3 o SDB3 HDB3 etc. En este tutorial es HDA3.
Veras una salida similar cuando termine el proceso, dependiendo del tamaño de tu partición y de la velocidad de tus discos duros puede tomar minutos u horas.
Crea un nuevo directorio en /usr/src:
cd /usr/src/
mkdir asterisk
cd asterisk/
En el nuevo directorio descarga Asterisk y sus componentes:
Edita el archivo /etc/drbd.d/asterisk.res. Cambia astnode1 por el nombre el hostname del servidor primario, cambia astnode2 por el hostname del servidor secundario, cambia /dev/sda3 por la partición que creamos con el espacio libre(en este tutorial hda3). Cambia las IPs por las de tus servidores primarios y secundarios.Cambia el correo electrónico por el tuyo o el administrador del sistema en este tutorial el archivo quedo así:
resource asterisk {
handlers {
split-brain "/usr/lib/drbd/notify-split-brain.sh clusteradmin@example.com";
}
net {
after-sb-0pri discard-younger-primary;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
on node1 {
device /dev/drbd0;
disk /dev/hda3;
address 10.0.1.51:7789;
meta-disk internal;
}
on node2 {
device /dev/drbd0;
disk /dev/hda3;
address 10.0.1.52:7789;
meta-disk internal;
}
}
Crea el Recurso llamado asterisk e inicia el servicio de DRDB:
drbdadm create-md asterisk
service drbd start
Paso 6—-Realizar solo en Servidor Primario.
A continuación crea el UUID llamado Asterisk, y formatea la partición que será usada por el cluster tipo: EXT3
Cambiate al directorio de rseries, marca el nodo como primario, monta la partición y ejecuta el script createlinks.sh:
cd /usr/src/asterisk/rseries-1.0.0
drbdadm primary asterisk
mount -t ext3 /dev/drbd0 /mnt/asterisk/
./createlinks.sh
Veras una salida como en la imagen anterior.
Cambiate al directorio de Asterisk, configura las mismas opciones que se configuraron en el servidor primario. Compilalo solo ejecutando make && make install. Desmonta la partición y marca el nodo como secundario.
cd ../certified-asterisk-1.8.11-cert9
contrib/scripts/get_mp3_source.sh
./configure && make menuselect
make && make install
umount /mnt/asterisk/
drbdadm secondary asterisk
Paso 10 —- Realizar en Ambos Servidores.
Edita el archivo /etc/corosync/corosync.conf. Cambia la opción bindnetaddr, y las opciones memberaddr. Para este tutorial el archivo quedo de la siguiente manera:
Inicia el servicio de Corosync y añade drbd y corosync al startup:
service corosync start
chkconfig drdb on
chkconfig corosync on
Verifica el estado del Cluster con el siguiente comando:
cat /proc/drbd
Veras una imagen como la siguiente:
Veras que se esta sincronizando la particion del cluster, también verás como Secondary/Secondary(no como en la imagen).
Si el proceso de sincronización reporta que tardará mucho tiempo puedes usar este comando para acelerar la velocidad de sincronización:
drbdsetup /dev/drbd0 syncer -r 250M
La velocidad máxima de sincronización dependerá de la velocidad de tus tarjetas de red así como la velocidad de escritura de tus discos duros. Para más información de como calcular la velocidad ve a este enlace.
Una vez que el estado sea UpToDate/UpToDate reinicia los servidores:
reboot
Paso 11—-Realizar solo en Servidor Primario.
Edita el siguiente codigo para que:
— node1 y node2. Sean los hostnames de tus servidores. En este ejemplo node1 y node2
— ip bajo ClusterIP. Sea la Ip de tu Cluster, la IP flotante. En este ejemplo 10.0.1.51
— cidr_mask bajo ClusterIP. Sea la mascara de tu red. en este ejemplo de 24bits(255.255.255.0)
– –host_list bajo GatewayStatus. Sea el gateway de tu red. en este ejemplo 10.0.1.1
node node1
node node2
primitive ClusterIP ocf:heartbeat:IPaddr2
params ip="10.0.1.50" cidr_netmask="24"
op monitor interval="5"
primitive drbd ocf:linbit:drbd
params drbd_resource="asterisk"
op monitor start-delay="10" interval="5"
primitive drbd_fs ocf:heartbeat:Filesystem
params device="/dev/drbd0" directory="/mnt/asterisk/" fstype="ext3"
primitive mysqld lsb:mysqld
primitive Asterisk ocf:Digium:asterisk
op monitor interval="5"
primitive GatewayStatus ocf:pacemaker:ping
params host_list="10.0.1.1" multiplier="100"
op monitor interval="5" timeout="10"
ms drbd_ms drbd
meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
clone GatewayStatusClone GatewayStatus
location Asterisk-with-ping Asterisk
rule $id="Asterisk-with-ping-rule" -inf: not_defined pingd or pingd lte 0
group mysql drbd_fs ClusterIP mysqld
colocation mysql_on_drbd inf: mysql drbd_ms:Master
order mysql_after_drbd inf: drbd_ms:promote mysql:start
colocation Everything-with-Asterisk inf: ( drbd_ms:Master ) ( ClusterIP drbd_fs ) Asterisk
order Asterisk-after-Everything inf: ( drbd_ms:promote ) ( ClusterIP drbd_fs ) Asterisk:start
property $id="cib-bootstrap-options"
cluster-infrastructure="openais"
expected-quorum-votes="2"
stonith-enabled="false"
no-quorum-policy="ignore"
rsc_defaults $id="rsc-options"
resource-stickiness="99"
Una vez que has editado el archivo Cluster_Mysql_Asterisk.cfg, actualiza la configuración de pacemaker:
Si todo sale bien veras una salida como la siguiente y los servicios de MySQL y Asterisk se iniciaran en el nodo primario:
Para verificar que los servicios estén corriendo puedes revisar el estado del cluster con:
crm_mon
Y verás algo así:
Demostración:
El siguiente video muestra las pruebas del cluster. Asterisk esta configurado con «static realtime» obteniendo los datos de una base de datos de MySQL. Este tutorial no cubre la cofiguración de ARA(Asterisk Realtime Architechture).
Herramientas para diagnosticar fallas:
Puedes ejecutar el siguiente comando en el nodo secundario para verificar que la configuración de pacemaker se replico:
crm configure show
Para detener los servicios del cluster:
crm configure property stop-all-resources=true
Para borrar la configuracion del cluster:
crm configure erase
Verificar el estado del cluster:
crm_mon
Verificar el estado de la sincronización y los roles de los servidores:
En ocasiones en nuestras oficinas (sobretodo en grandes corporativos), estamos sujetos a presupuestos de llamadas por mes. Esto quiere decir que recibimos una bolsa de minutos a ciertos destinos (para control de gastos) y debemos cuidarlos, ya que si nos los agotamos tendremos que hacer solicitudes de «crédito» interno y ante nuestros superiores parecería como que estamos desperdiciando dinero (llamadas) de la empresa.
Contemplando escenarios similares a este, podemos configurar Asterisk para que las extensiones de cada persona sean bloqueadas al momento en que la persona se retira a su casa. De esta manera, si alguien se queda cercano a su área de trabajo no podrá tomar su teléfono y hacer llamadas al exterior, reduciendo el crédito del trabajador que ya se fue (y ahorrándose el suyo). Al día siguiente, cuando el trabajador regresa, marca un código de desbloqueo junto con su contraseña y su teléfono vuelve a estar habilitado.
¿Cómo hacer eso?
Partiremos de los siguientes supuestos:
El contexto al que mis extensiones «normales» tienen derecho es el from-internal.
El código para bloquear la extensión (cuando el trabajador se va), será *51.
El código para desbloquear la extensión (cuando el trabajador regresa por la mañana), será *52.
Todas las extensiones deben tener un buzón asignado. El número de buzón debe ser el mismo que el de la extensión.
La marcación que negaremos será solamente la que corresponda a llamadas locales, larga distancia, celulares e internaciones (es decir, todas las que cuesten).
La sintaxis que estoy ocupando (same =>) es para Asterisk 1.6.2 o superior.
Toda la magia viene en el archivo extensions.conf (si usas Trixbox/Elastix/FreePBX, debes de hacerlo dentro del archivo extensions_custom.conf)
[from-internal-custom]
; Estos son los patrones para hacer las llamadas
; Si necesitas cerrar más patrones, agrégalos siguiendo el mismo formato
exten => _ZXXXXXXX,1,Macro(permitir)
same => n,Goto(from-internal-additional,${EXTEN},1)
exten => _04[45]ZXXXXXXXXX,1,Macro(permitir)
same => n,Goto(from-internal-additional,${EXTEN},1)
exten => _01ZXXXXXXXXX,1,Macro(permitir)
same => n,Goto(from-internal-additional,${EXTEN},1)
exten => _00ZXXXXXXXX.,1,Macro(permitir)
same => n,Goto(from-internal-additional,${EXTEN},1)
; Este es el código de bloqueo. Es lo que el trabajador marca antes de retirarse
exten => *51,1,Noop(Bloqueando ${CALLERID(num)})
;same => n,VMAuthenticate(${CALLERID(num)}) ; Descomenta esta línea si quieres pedir contraseña también al bloquear
same => n,Set(DB(bloqueo/${CALLERID(num)})=1)
same => n,Playback(vm-goodbye)
same => n,Hangup
; Este es el código de desbloqueo. Es lo que marca a la mañana siguiente
exten => *52,1,Answer
same => n,VMAuthenticate(${CALLERID(num)})
same => n,Noop(${DB_DELETE(bloqueo/${CALLERID(num)})})
same => n,Playback(auth-thankyou)
same => n,Hangup
; El macro-permitir es lo que valida si una extensión tiene o no activada el bloqueo
[macro-permitir]
exten => s,1,Noop(Revisando permisos de ${CALLERID(num)})
same => n,GotoIf($[${DB_EXISTS(bloqueo/${CALLERID(num)})}]?Bloquear:Permitir)
same => n(Bloquear),Noop(Deteniendo el paso de ${CALLERID(num)})
same => n,Playback(pbx-invalid) ; Reemplazar por cualquier archivo de sonido deseado
same => n,Congestion()
same => n(Permitir),Noop(Permitiendo el paso de ${CALLERID(num)} --> ${MACRO_EXTEN})
Una breve explicación de lo que hace cada cosa:
Los patrones de ZXXXXXXX, 01ZXXXXXXXXX, 04[45]ZXXXXXXXXX y 00ZXXXXXX. son para controlar las llamadas locales, larga distancia nacional, celulares y LD internacional respectivamente. Si tienes más patrones de marcación o destinos que desees bloquear (por ejemplo, alguna marcación corta por telular), necesitas agregar el patrón correspondiente siguiendo el mismo formato (tras cada patrón debe haber una continuación same => n,Goto(from-internal-additional,${EXTEN},1) que te permite continuar con el contexto from-internal-additional.
*51 y *52 son, como habíamos comentado, los códigos para bloqueo/desbloqueo respectivamente. Puedes reemplazar los Playbacks por lo que tu elijas para dar diferentes mensajes
El [macro-permitir] es el que checa el contenido del Asterisk DB. Si la familia bloqueo/CALLERID existe, entonces no se le permiten las llamadas. Si no existe, el macro permite el paso y la llamada continúa de manera normal.
Las autenticaciones se hacen con la misma contraseña del buzón de voz, así cada quien tiene la suya, es actualizable por el usuario y solo funciona dentro de su mismo teléfono.
Si deseas desbloquear manualmente alguna extensión (ej. alguien olvidó su contraseña), solo debes ejecutar database del bloqueo <ext> dentro del *CLI.
Con esto lograremos que al cierre del turno, el trabajador pueda bloquear su teléfono y reactivarlo a la mañana siguiente con solo ingresar su contraseña.
Debo agregar que funciona tan bien que anoche que lo implementé dejé cerrada mi extensión y hoy no me permitía hacer llamadas, hasta que marqué *52 e introduje mi contraseña nuevamente.
En el mundo del VoIP, todos los que nos dedicamos a esto nos hemos encontrado con clientes que poseen conmutadores convencionales que les han representado una inversión de la que no quieren deshacerse tan pronto. Tan solo imaginen haber gastado $30K+ USD hace apenas un par de años y que ahora deban reemplazarlo para acceder a funcionalidades que no estaban incluidas (IVRs, buzón de voz, llamadas por VoIP, etc). Muchos clientes no están dispuestos a dejarlo atrás, por lo que es necesario sacarle más jugo a lo que ya tienen.
Soluciones como Nortel/Avaya, Ericsson, Panasonic y otras, son muy buenas, pero también pueden resultar muy caras cuando agregas todas las bondades que Asterisk en comparación puede ofrecer de manera gratuita. Algunas requieren comprar tarjetas adicionales para soportar las nuevas funcionalidades, mientras que otras requieren de el pago de alguna licencia (y aún así, muchas veces con limitaciones). La solución que existe para poder seguir aprovechando estos conmutadores es muy simple: confiarle el trabajo a Asterisk haciendo una interconexión entre los PBXs.
La opción más común en este tipo de entornos es usar un enlace E1 entre equipos. En este artículo buscaré mostrar como configurar la conexión mediante R2 MFC, que es la señalización más utilizada en México. En el ejemplo usaré una tarjeta Sangoma A102E (2 puertos E1). Si desean profundizar más sobre la configuración habitual de un enlace R2, les recomiendo la guía de OpenR2 escrita por Moisés Silva, autor de dicha librería.
Empezaré partiendo por los siguientes supuestos:
Tenemos un sistema Asterisk instalado con soporte para OpenR2.
Usaremos la variante Mexicana de R2.
Tenemos un conmutador convencional (PBX) con un puerto E1 disponible.
Asterisk actuará como gateway del E1. Es decir: PSTN <–> Asterisk <–> PBX. Todas las llamadas del PBX hacia la PSTN deberán pasar por Asterisk (y viceversa).
Tenemos ya una tarjeta A102E instalada físicamente, y sabemos configurarla utilizando wancfg_dahdi. Usaremos los puertos como sigue:
Puerto 1 (wanpipe1.conf): Conexión hacia la PSTN.
Puerto 2 (wanpipe2.conf): Conexión hacia el PBX convencional.
El cable que se usará para conectar Asterisk <–> PSTN es un cable recto convencional.
El pinout de este cable NO es igual que un cable ethernet cruzado.
Puedes encontrar muchas imágenes de como hacer este cable buscando en Google
Configuración:
Primero debemos cerciorarnos que nuestros archivos /etc/wanpipe/wanpipe1.conf y wanpipe2.conf estén correctamente configurados para cada caso. Este es el wanpipe1.conf:
FE_FRAME = NCRC4
TE_CLOCK = NORMAL
TE_SIG_MODE = CAS
TE_RX_SLEVEL = 120
Para el wanpipe2.conf (PBX), asegurémonos que las siguientes líneas tienen estos valores:
El valor de FE_FRAME puede cambiar ya sea NCRC4 o CRC4, pero en nuestra experiencia, prácticamente ningún proveedor pide el uso de CRC4. Por tal motivo, la mayoría de los PBXs reciben SIN CRC4, de manera que nuestro Asterisk deberá tener el mismo valor en ambos archivos, ya que lo mismo que configuramos de un lado (PSTN), lo pasamos al otro (PBX).
TE_CLOCKes importante declarar la diferencia:
MASTER indica que nosotros generaremos la señal de reloj. Por lo tanto, esto debe ir en el archivo que conectará al PBX (nosotros simularemos ser la PSTN para el PBX)
NORMAL indica que seremos esclavos del maestro del otro lado. Por lo tanto, esto debe ir configurado en el lado que conectará a la PSTN (nos comportaremos ante el carrier como si fuéramos cualquier PBX convencional)
TE_SIG_MODE=CAS es solo para dejar en claro que estamos usando R2. Si tuviéramos CCS es porque estamos usando ISDN PRI, pero esa es otra historia.
TE_RX_SLEVEL debe estar en 120. Por alguna razón que no entiendo, el configurador de Sangoma wancfg_dahdi siempre te lo pone en 430, pero esto es un valor incorrecto. Siempre debemos tenerlo en 120.
Ahora, los valores del /etc/dahdi/system.conf:
# Span 1: PSTN
span=1,1,0,cas,hdb3
cas=1-15:1101
cas=17-31:1101
hardhdlc=16
# Span 2: PBX
span=2,0,0,cas,hdb3
cas=32-46:1101
cas=48-62:1101
hardhdlc=47
# Opcional: Canceladores de eco en software
echocanceller=mg2,1-15,17-31,32-46,48-62
# Global data
loadzone = mx
defaultzone = mx
Nuevamente comentamos el por qué de estos valores:
En span=1,1,0 , el primer 1 está indicando que se trata del primer puerto (PSTN), mientras que el segundo 1 significa que esta es la fuente primaria de reloj de nuestro sistema. Es decir, acataremos la sincronía entregada por el carrier, ya que normalmente sus equipos son más precisos que los nuestros.
En span=2,0,0 , por el otro lado, especificamos que estamos hablando del segundo puerto (PBX). El primer 0 significa que NO debemos hacerle caso al reloj que recibamos desde este enlace. En otras palabras, que ignoremos lo que está del otro lado y le hagamos caso solo a lo que nosotros ya tenemos. Estamos actuando como maestro ante el esclavo (que es el PBX).
El término cas demuestra una vez más que estamos usando R2. En la guía de OpenR2 arriba mencionada pueden encontrar más documentación de lo que significa el 1101.
Los canceladores de eco, aunque no son óptimos, son los default. Si quieren un mejor cancelador de eco prueben siguiendo los pasos de nuestro artículo pasado «Instalando OSLEC y usando fxotune«
Vamos con el siguiente archivo, el /etc/asterisk/chan_dahdi.conf
Estos quizá son los valores más importantes del resto de los archivos (al menos, al tratar de implementarlos en un Nortel fueron los que más trabajo nos costó conseguir):
mfcr2_max_ani especifica la longitud máxima del ANI (Caller ID) que estamos dispuestos a recibir. Dado que en México todos los números nacionales tienen 10 dígitos, es necesario configurar 10 como valor en el enlace que va hacia la PSTN. Sin embargo, para el PBX este NO nos va a proporcionar un Caller ID, por lo tanto, debemos dejarlo en 0 (cero).
mfcr2_max_dnis por el otro lado, especifica la longitud máxima del número destino marcado. Cuando recibimos una llamada de la PSTN, el carrier nos entrega 4 dígitosúnicamente que corresponden al DID marcado. Cuando el PBX nos envía el destino, este puede ser cualquier cosa:
ZXXXXXXX (8 dígitos) para una llamada local.
01ZXXXXXXXXX (12 dígitos) para una llamada de larga distancia nacional.
045ZXXXXXXXXX (13 dígitos) para una llamada a celular nacional.
00ZXXXXXXX. (cantidad variable) para una llamada de larga distancia internacional.
Por tal motivo, es necesario dejar un poco de holgura en el número a marcar para darle la posibilidad al PBX a que marque a donde quiera. Decidimos que 16 dígitos es un número que cubre la suficiente cantidad de combinaciones posibles para permitir marcar a todos lados.
El campo de mfcr2_allow_collect_calls lo pusimos en yes en el PBX porque de otra manera nos colgaba las llamadas al momento de enviarlas PBX -> Asterisk.
mfcr2_skip_category=yes lo usamos para que Asterisk le permitiera al PBX no especificar la categoría de MFCR2 (algunos PBX como el caso de este Nortel no la entregan)
Los contextos de from-pstn y from-internal demuestran quien es la entidad de confianza/interna (PBX) y quien es la de desconfianza/externa (PSTN)
El group debe ser diferente en ambos casos para que podamos diferenciar por donde sale cada llamada. La PSTN es el 1 y el PBX es el 2.
Ya dentro de Asterisk nos podemos cerciorar que todo esté en orden:
*CLI> mfcr2 show channels
Chan Variant Max ANI Max DNIS ANI First Immediate Accept Tx CAS Rx CAS
1 MX 10 4 No No IDLE IDLE
2 MX 10 4 No No IDLE IDLE
3 MX 10 4 No No IDLE IDLE
4 MX 10 4 No No IDLE IDLE
5 MX 10 4 No No IDLE IDLE
6 MX 10 4 No No IDLE IDLE
7 MX 10 4 No No IDLE IDLE
8 MX 10 4 No No IDLE IDLE
9 MX 10 4 No No IDLE IDLE
10 MX 10 4 No No IDLE IDLE
11 MX 10 4 No No IDLE BLOCK
12 MX 10 4 No No IDLE BLOCK
13 MX 10 4 No No IDLE BLOCK
14 MX 10 4 No No IDLE BLOCK
15 MX 10 4 No No IDLE BLOCK
17 MX 10 4 No No IDLE BLOCK
18 MX 10 4 No No IDLE BLOCK
19 MX 10 4 No No IDLE BLOCK
20 MX 10 4 No No IDLE BLOCK
21 MX 10 4 No No IDLE BLOCK
22 MX 10 4 No No IDLE BLOCK
23 MX 10 4 No No IDLE BLOCK
24 MX 10 4 No No IDLE BLOCK
25 MX 10 4 No No IDLE BLOCK
26 MX 10 4 No No IDLE BLOCK
27 MX 10 4 No No IDLE BLOCK
28 MX 10 4 No No IDLE BLOCK
29 MX 10 4 No No IDLE BLOCK
30 MX 10 4 No No IDLE BLOCK
31 MX 10 4 No No IDLE BLOCK
32 MX 0 30 No No IDLE IDLE
33 MX 0 30 No No IDLE IDLE
34 MX 0 30 No No IDLE IDLE
35 MX 0 30 No No IDLE IDLE
36 MX 0 30 No No IDLE IDLE
37 MX 0 30 No No IDLE IDLE
38 MX 0 30 No No IDLE IDLE
39 MX 0 30 No No IDLE IDLE
40 MX 0 30 No No IDLE IDLE
41 MX 0 30 No No IDLE IDLE
42 MX 0 30 No No IDLE IDLE
43 MX 0 30 No No IDLE IDLE
44 MX 0 30 No No IDLE IDLE
45 MX 0 30 No No IDLE IDLE
46 MX 0 30 No No IDLE IDLE
48 MX 0 30 No No IDLE IDLE
49 MX 0 30 No No IDLE IDLE
50 MX 0 30 No No IDLE IDLE
51 MX 0 30 No No IDLE IDLE
52 MX 0 30 No No IDLE IDLE
53 MX 0 30 No No IDLE IDLE
54 MX 0 30 No No IDLE IDLE
55 MX 0 30 No No IDLE IDLE
56 MX 0 30 No No IDLE IDLE
57 MX 0 30 No No IDLE IDLE
58 MX 0 30 No No IDLE IDLE
59 MX 0 30 No No IDLE IDLE
60 MX 0 30 No No IDLE IDLE
61 MX 0 30 No No IDLE IDLE
62 MX 0 30 No No IDLE IDLE
En el caso de este cliente, es normal que los canales del 11-31 aparezcan como bloqueados, ya que solo dispone de 10 canales de 30 posibles en su E1 (tiene contratado un servicio fraccionado). Lo mismo verían si contratan 20 de 30 canales con su proveedor. Noten que el segundo E1 (hacia el PBX) si debe aparecer completamente desbloqueado.
Con esta configuración, ambos enlaces aparecen levantados. El último paso sería configurar el /etc/asterisk/extensions.conf para que de acuerdo a los contextos declarados, permita el paso transparente de un E1 hacia el otro:
No olviden hacer el dialplan reload después de haber hecho estos cambios.
De esta manera, todo lo que llega por el Span 1 se manda hacia el Span 2 (y viceversa). Ya les dejo a ustedes analizar el plan de llamadas para determinar como activar las grabaciones que vayan de un sentido hacia el otro.
Espero les sirva. Esta configuración es tal cual la que aplicamos tal cual con uno de nuestros clientes, y funcionó a la perfección.
El domingo pasado recibí el correo de un cliente: su sistema de marcación predictiva con vicidial había tenido fallas eléctricas durante el fin de semana, ocasionando que las tablas de MySQL se corrompieran y que el sistema quedara inservible (al menos lo relacionado con la marcación predictiva).
Tras cerca de una hora reparé todas las tablas usando unos comandos simples como los que siguen:
/etc/init.d/mysql stop
cd /var/lib/mysql/asterisk
myisamchk -r *.MYI
/etc/init.d/mysql start
Sin embargo, me percaté que al hacer esto, estaba solo reparando las tablas una por una. El sistema tenía 4 núcleos, por lo que era posible hacer mucho más trabajo al mismo tiempo (4 tareas a la vez) en vez de ir una por una.
El sistema terminó de manera habitual tras el paso de 1 1/2 hrs. Para evitar que tanto tiempo se perdiera en nuevas ocasiones, decidí crear un script en bash que reparara todas las tablas de manera simultánea (limitándose a 1 proceso por cada núcleo del sistema), y me quedó el código así:
#!/bin/bash
# Editar estos valores:
## CORES debe ser igual al número de núcleos en el sistema
## (revisar el comando "cat /proc/cpuinfo")
## MYSQLDBDIR debe ser igual a la carpeta de MySQL que contiene la BD
## que debamos reparar (default: "/var/lib/mysql/asterisk")
CORES=4
MYSQLDBDIR=/var/lib/mysql/asterisk
# Enlistar los archivos
FILES=`ls $MYSQLDBDIR/*.MYI`
RUNS=0
for i in $FILES
do
SALIR=0
while [ $SALIR -eq 0 ]
do
# Obtener la cantidad de procesos en el sistema
PROCS=`ps -eF|grep myisamchk|egrep -v "grep"|wc -l`
# Ejecutamos el while los procesos activos sean menor a CORES
if [ $CORES -gt $PROCS ]
then
echo `date +"%X"` Revisando/Reparando tabla $i
myisamchk -r $i &
# Descansamos 1 segundo
sleep 1
SALIR=1
else
# Esperamos 3 segundos
sleep 3
fi
done
done
# Ya se terminaron de correr todas las instrucciones de reparación,
# pero existe la posibilidad de que algunas de ellas aún estén ejecutándose.
# Revisamos para ver si hay procesos corriendo y avisar al usuario
while [ $SALIR -eq 0 ]
do
# Obtener la cantidad de procesos en el sistema
PROCS=`ps -eF|grep myisamchk|egrep -v "grep"|wc -l`
if [ $PROCS -gt 0 ]
then
echo `date +"%X"` Hay $PROCS procesos corriendo. Esperando 10s...
sleep 10
else
echo "No hay procesos corriendo"
SALIR=1
fi
done
echo `date +"%X"` Fin. Ya puedes reiniciar MySQL
Los siguientes pasos son algo obvios:
Hay que guardar este script como un archivo checar.sh
Editamos el archivo y cambiamos el número de cores de nuestro sistema, así como la ubicación de la carpeta de MySQL que contiene los archivos de la BD
Darle permisos de ejecución (chmod 755 checar.sh)
Ejecutarlo: ./checar.sh
El script correrá varios procesos en paralelo para revisar cada uno una tabla. Mientras más núcleos tenga nuestro procesador, más rápido el script aprovechará los recursos para crear la reparación.
Espero les sirva.
¡Suerte!
Advertencia: Aunque este script puede ayudarnos a reparar nuestras tablas en caso de algún problema (falla eléctrica, corrupción del sistema de archivos, fallo en el disco duro, etc) no hay nada más seguro que respaldar nuestra información periódicamente. Siempre ten a la mano copias de seguridad de aquella información crítica, ya que no podemos hacernos responsables por la pérdida de información causada por el mal uso de las directivas que se muestran en este artículo. Úsalo bajo tu propio riesgo.
Tarde o temprano nos vemos en la necesidad de considerar el gasto individual de las lineas telefónicas conectadas a nuestro Asterisk y encontrar una forma en que las llamadas se distribuyan de forma uniforme entre las lineas, no es lo mismo que 90% de la llamadas al exterior se realicen por la primera linea desocupada a que en caso de tener 4 se repartan en un 25% entre ellas.
Debido a esta necesidad me vi en la necesidad de crear un script en AGI PHP que junto con el dialplan nos haga este trabajo:
Para llevar el contador de las llamadas haremos uso de la asteriskdb, la base de datos integrada en asterisk. Lo que haremos es establecer primero las familias y las llaves que llevaran los datos, usando los siguientes comandos desde adentro del Asterisk CLI (*CLI): Continue reading →
En este blog y en muchos otros se ha discutido el uso de aplicaciones como fail2ban para impedir ataques de fuerza bruta combinado junto con iptablespara denegar el acceso a fuentes no autorizadas. Existe un caso especial que es cuando tenemos que aceptar las llamadas anónimas del exterior sin importar desde donde se originen, y ese es el caso del que voy a comentar a continuación.
Recibir llamadas anónimas no es malo, pero hay que saber lo que se hace y tomar las precauciones necesarias. Al permitir las llamadas entrantes desde cualquier fuente estamos permitiendo que cualquiera nos contacte via IP, para que así el interesado no tenga que paga costos de LD, ni tampoco tenga que hacer algún setup muy elaborado en su conmutador. Ofrecer un peer de autenticación a cada usuario sería un poco difícil, ya que lo que se espera de estos escenarios es que la comunicación sea en un solo sentido (de afuera nos marcan a nosotros hacia adentro) y también, buscas hacerla lo más fácil de marcar para el usuario final.
En nuestro caso, nosotros permitimos llamadas provenientes del exterior pero solo hacia nuestras extensiones internas. De esta manera, no hay costos relacionados con ataques porque las llamadas nunca vuelven a salir hacia la PSTN. Solo pueden comunicarse a nuestras extensiones internas y DIDs. El único problema, es que a veces los equipos que atacan piensan que al no negar las llamadas, vamos a permitirlas salir, así que nos mandan intentos de ataques de unas 40 llamadas simultáneas, lo que hace que nuestros teléfonos comiencen a sonar una y otra vez.
Para evitar que nuestro conmutador se atiborre de llamadas que no deseamos, pero que al mismo paso permita las llamadas que si queremos, debemos permitir lo siguiente desde nuestro GUI:
Permitir llamadas anónimas: si
Y luego hacemos esta combicación de plan de llamadas personalizado y fail2ban (estamos usando FreePBX). Dentro del archivo extensions_custom.conf ponemos:
Lo que estoy haciendo aquí es que siempre que reciba una llamada en mi FreePBX que no esté especificada hacia una extensión y/o DID que tenga dado de alta, el contexto [ext-did-post-custom] lo procesará y hará un análisis del número máximo de llamadas simultáneas que debe permitir.
Si se exceden 3 llamadas de acuerdo al ejemplo, debo cortar el paso y enviar un mensaje a consola que diga «LLAMADAS EXCEDIDAS»
Si no se excede, permito el paso enviando la llamada hacia la cláusula default [ext-did-catchall]
Si recibo llamadas desde una fuente «no autorizada» hacia un número que si existe en mi sistema, el contexto [ext-did] lo procesará de manera normal
Si el origen ya fuera autorizado, caerá en el contexto que sea que yo le haya especificado y hará caso omiso de esta configuración
Tras hacer la modificación correspondiente y recargar, el mensaje de «LLAMADAS EXCEDIDAS» ya aparece en mis logs. Ahora debo modificar mi fail2ban para que tome en cuenta este texto y bloquee a nivel de firewall a aquellos que nos manden llamadas en bruto.
Basándome en el artículo de fail2ban anterior que publicamos hace unos meses, modifico el /etc/fail2ban/filter.d/asterisk.conf para que quede así:
failregex = Registration from '.*' failed for '(:[0-9]{1,5})?' - Wrong password
Registration from '.*' failed for '(:[0-9]{1,5})?' - No matching peer found
Registration from '.*' failed for '(:[0-9]{1,5})?' - Device does not match ACL
Registration from '.*' failed for '(:[0-9]{1,5})?' - Username/auth name mismatch
Registration from '.*' failed for '(:[0-9]{1,5})?' - Peer is not supposed to register
LLAMADAS EXCEDIDAS DESDE (:[0-9]{1,5})?
NOTICE.* failed to authenticate as '.*'$
NOTICE.* .*: No registration for peer '.*' (from )
NOTICE.* .*: Host failed MD5 authentication for '.*' (.*)
VERBOSE.* logger.c: -- .*IP/-.* Playing 'ss-noservice' (language '.*')
LLAMADAS EXCEDIDAS POR
Si el fail2ban atrapa estas líneas, bloqueará al host por el tiempo que le hayamos especificado en el archivo jail.conf.
Debo destacar que este es un caso muy especial que pocos querrán utilizar, pero es bueno saber que se puede ser precavido y a la vez, flexible con el uso de tu conmutador. Dado que permitir llamadas anónimas expone tu conmutador, la responsabilidad de este código recae en quien lo usa, por lo que no debes aplicarlo si no estas seguro de que es lo que hará.
Actualización 30/julio/2013: Podemos confimar que al usar el firmware más reciente en este momento (9.70.0.140) la funcionalidad de marcación sin autenticación que provocaba este problema de seguridad viene desactivado, y es necesario configurar el teléfono con la IP autorizada que podrá hacer uso del API, por lo que este problema ya no existe. Sin embargo, nunca está de más asegurar su red y cambiar las contraseñas default del teléfono para impedir cualquier acceso no autorizado.
Yealink T20P: teléfono básico
Hace unos días recibí una llamada de uno de mis clientes. La historia comienza con una de las frases que menos me gusta escuchar en mi medio:
– Christian, ¿puedes venir? Nos hackearon el conmutador de la oficina…
Acudí en menos de una hora al sitio (yo no tenía acceso remoto y ni siquiera tenía conocimiento de este equipo) y me dí a la labor de revisar los logs para tratar de reconstruir el caso. Sin embargo, me encontré con lo siguiente:
El equipo tenía servicios de iptables y fail2ban protegiéndolo
Las contraseñas de SIP eran seguras
No se recibían conexiones ni por SIP ni por HTTPS del exterior
Todas las llamadas habían sido originadas desde una extensión
Apache no tenía registros de IPs externas, tampoco Asterisk.
Todo parecía indicar que hubiera sido un inside job, y en efecto (al menos parcialmente), así fue.
Por más que busqué no encontré señales de como había logrado entrar, pero las llamadas estaban en el CDR y en el gateway SIP que terminaba la comunicación. ¿Qué ocurrió entonces?
De pronto, el empleado al que pertenece el teléfono cuya cuenta SIP ocasionó todas las llamadas, exclamó lo siguiente:
– Mi teléfono ha estado raro. Varias veces en la mañana estuvo «marcando solo» y yo solamente escuchaba una grabación a veces de que la llamada no había podido ser completada
Momento… ¿marcando solo? ¿Desde cuando los teléfonos se marcan solos? Se trataba de un Yealink T20, el cual es un modelo extremadamente sencillo y económico. ¿Qué funcionalidad podría tener que hiciera que marcara solo?
La respuesta es: los Yealink ofrecen la posibilidad de marcación automática a través de una simple y sencilla petición HTTP que requiere autenticación, pero si nunca cambian la contraseña de usuario y administrador del teléfono (lo cual casi nadie hace), cualquiera puede hacer que el teléfono marque solo hacia cualquier destino.
Si tienen un teléfono Yealink consigo (cualquier modelo), prueben hacer esto en su casa/oficina:
Supongamos que la IP de nuestro Yealink sea 192.168.1.101. Asumimos que en nuestro Asterisk existe un plan de marcación que nos permite marcar larga distancia. Imaginemos el número 018881234567. Ahora bien, abran el siguiente URL en su navegador favorito (recuerden cambiar los valores según corresponda):
¿Y qué ocurre? Simple y sencillamente, su teléfono marcará por ustedes hacia el número indicado usando la primer cuenta que tengan configurado en él. Si Asterisk no los autentica a nivel de usuario, ustedes tienen un severo problema de seguridad ya que cualquier persona podría manipular su teléfono para marcar hacia donde le viniera en gana.
Y bien, ¿qué pasa si abren el URL repetidas ocasiones? Fácil. El teléfono marcará una y otra vez a ese número sin colgar las otras llamadas. De manera que un solo teléfono podría hacer 100 llamadas a Afghanistan, Sierra Leona o cualquier otro destino caro del mundo. Esto es muy fácil de lograr con un script en Linux que invoque al wget. Lo demostré en laboratorio y creanme, los resultados asustan.
Imaginen por un momento que alguien tuviera acceso a su red interna, pero no conoce las contraseñas de los teléfonos. Con este truco no es necesario saberlas, ya que el teléfono se encuentra ya autenticado en su red interna y por lo tanto, las llamadas saldrán aún si ustedes confían en que su firewall no recibirá conexiones del exterior.
Por tal motivo, si ustedes deciden abrir erróneamente los puertos en su firewall y exponen la configuración del teléfono, le están abriendo la puerta a alguien a que haga cientos de llamadas sin autorización. En la historia que les acabo de contar, alguien aprovechó esta vulnerabilidad e hizo más de 40,000 minutos de llamadas a los destinos más caros del mundo en tan solo 12 horas, y sin tener que usar su ancho de banda para generar esas llamadas.
Piénsenlo muy bien antes de que expongan equipos al internet. Hay un mundo peligroso allá afuera, y si no se protegen, más temprano que tarde acabarán siendo víctimas de la cyber delincuencia.