Inseguridad en Elastix: estadísticas actualizadas (México)

3 Nov

Hace algunos meses publiqué un artículo sobre estadísticas de inseguridad en Elastix y los resultados fueron bastante alarmantes, ya que el estudio claramente indicaba que quienes se habían encargado de instalar los sistemas no habían seguido muchos de los consejos básicos de seguridad tales como no exponer el HTTPS a internet ni mucho menos cambiar las contraseñas default puestas. Por tal motivo, durante este año se reportaron múltiples casos de empresas  a los que les habían cometido algún tipo de fraude telefónico, representando pérdidas de varios cientos o miles de dólares en tan solo una noche.

Hoy, con motivo del inicio del Elastix World precisamente en México, decidí repetir el ejercicio para hacer un comparativo de como han cambiado los números desde aquel entonces. Aquí mis resultados obtenidos:

Los resultados fueron:

– Total de equipos escaneados (en México): 27.8 millones
– Total de equipos con puerto TCP 443 expuesto: 67,887
– Total de equipos con puerto TCP 443 expuesto y que usan Elastix: 336

De los equipos con Elastix expuesto:

– Presentan algún tipo de vulnerabilidad descubierta: 102 (27.87%)
– Tienen acceso mediante UDP 5060 (SIP):  102 (27.87%)
– Tienen alguna contraseña default en FreePBX: 82 (22.40%)
– Siguen usando ‘palosanto’ como contraseña de Elastix: 9 (2.46%)
– No han parchado la vulnerabilidad del ‘asteriskuser’: 120 (32.79%)
– Usan la misma contraseña para FreePBX y para Elastix: 4 (1.09%)
– Utilizan una versión muy vieja de FreePBX (2.5 o menor): 43 (11.75%)

De los equipos con vulnerabilidades que permiten acceso:

– Se detectaron extensiones completas (usuarios, contraseñas y correos electrónicos) de 1,192 personas

Tomen en cuenta que todos estos números son reales, ya que el estudio fue conducido sobre equipos en producción durante la noche del 2/noviembre/2011.

Tras analizar los números, es posible ver que ha habido una notable mejoría. Sin embargo, muchas empresas siguen desprevenidas contra ataques por no seguir simples reglas de seguridad básicas (las cuales se mencionan en el artículo inicial)

Ahora, tras los números, mi opinión personal: ¿Es Elastix una herramienta insegura? No, no lo es. Ha tenido sus vulnerabilidades relacionadas con las herramientas que incorpora (tal como FreePBX), pero todos estos males podrían haberse resuelto si tan solo los «administradores» que las instalaron hubieran tomado 5 minutos extras en asegurar su conmutador después de haber hecho la instalación. De hecho, creo que el principal problema de las herramientas que hacen la labor de instalación más sencilla (tal como Elastix lo es), es que cualquier persona piensa que por meter un CD y dar unos cuantos clicks ya terminó todo, cuando realmente se requiere preparación y conocimiento detrás de cada acción para saber lo que se está haciendo. Desafortunadamente, personas con este perfil son las que le dan una mala reputación a los sistemas VoIP (y a quienes nos encargamos de ofrecerlos), haciendo que se genere desconfianza para muchos por culpa de tan solo algunos.

Una vez más, no me queda recomendarles mas que asegurar sus equipos. Hoy más que nunca, los fraudes telefónicos están a la orden del día.

¡Suerte!

Elastix hack: Usar los Cisco SPA5XX con el endpoint configurator de Elastix

19 Jul

En numerosas ocasiones he usado el Endpoint Configurator de Elastix para facilitar la configuración de múltiples teléfonos de manera rápida y sencilla. Sin embargo, recientemente que empecé a ocupar los teléfonos Cisco SPA502G y SPA504G me topé con que Elastix no los reconoce (o al menos, no directamente), así que no podía usar el configurador automático con ellos.

Los teléfonos de la serie SPA provienen de Linksys, el fabricante de equipo de red para SoHo que Cisco adquirió, pero estos a su vez provienen de Sipura, que es un fabricante que pocos conocen y que hace mucho tiempo, Linksys compró. La configuración entre los diferentes modelos no ha cambiado mucho a pesar de los años, así que un Cisco SPA504G se configura prácticamente igual que un Linksys SPA942, y esos SI son detectados por el configurador de Elastix.

Entonces… ¿Cómo hacemos para que Elastix detecte estos nuevos modelos?

Una forma muy sencilla es engañando al configurador, haciéndolo creer que se tratan de SPA942. Para hacerlo, solo tenemos que agregar las MACs de Cisco dentro del archivo /var/www/db/endpoint.db (el cual viene en formato de sqlite). El código sería el siguiente:

sqlite3 /var/www/db/endpoint.db
sqlite> INSERT INTO "mac" VALUES(45, 4, 'C8:9C:1D', 'Cisco - SPA504G');
sqlite> INSERT INTO "mac" VALUES(46, 4, 'E0:5F:B9', 'Cisco - SPA504G');
sqlite> .quit

Estas 2 series de MACs, la E0:5F:B9 y la C8:9C:1D son las que por experiencia he encontrado que estos nuevos teléfonos tienen. ¿Qué quieren decir los otros campos?

  • El ’45’ es el número de la fila. Por default vienen otros 44 registros en la tabla mac, pero podemos reemplazarlos por cualquier otro número (como 100 o 101)
  • El ‘4’ es el que le dice a Elastix que el teléfono encontrado es un Linksys
  • El ‘E0:5F:B9’ o ‘C8:9C:1D’ corresponde al inicio de la MAC del teléfono. Mismos modelos suelen tener el mismo comienzo de MAC
  • El último campo es solo una descripción de lo que se está agregando. Esto no se usa, es solo para que los humanos entendamos de que se trata la fila.

Tras hacer el cambio, podemos re-ejecutar el endpoint y obtendremos algo como esto:

Esto nos indica que nuestros teléfonos ya fueron reconocidos, así que podemos aplicar la configuración de la extensión para configurar nuestros nuevos teléfonos.

¡Suerte!

Respaldando la base de datos de configuración de Elastix/FreePBX por SSH

27 Jun

Una gran ventaja que tenemos en Linux es la facilidad de crear procesos automatizados que nos ayuden a ejecutar tareas cotidianas. Para nuestros usos comunes como administrador de equipos basados en Asterisk/Elastix/FreePBX, puede ser una labor cotidiana respaldar la configuración alojada en bases de datos de MySQL.

SSH nos permite ejecutar comandos en servidores Linux remotos y traernos el resultado al mismo tiempo, por lo que resulta ideal para realizar un respaldo en un equpo distante y almacenarlo en nuestro equipo Linux loca. El comando para hacerlo sería el siguiente (asumiendo que usamos la contraseña default de MySQL en nuestro equipo remoto):

[codesyntax lang=»bash»]

ssh 192.168.1.100 "mysqldump -peLaStIx.2oo7 --databases asterisk | gzip -9" > respaldo.sql.gz

[/codesyntax]

El comando de arriba se encargará de hacer un dump de la BD asterisk. Si quisiéramos traernos también el CDR, hariamos lo siguiente:

[codesyntax lang=»bash»]

ssh 192.168.1.100 "mysqldump -peLaStIx.2oo7 --databases asterisk cdr | gzip -9" > respaldo.sql.gz

[/codesyntax]

O si quisiéramos traernos TODAS las bases de datos:

[codesyntax lang=»bash»]

ssh 192.168.1.100 "mysqldump -peLaStIx.2oo7 --all-databases | gzip -9" > respaldo.sql.gz

[/codesyntax]

Hay que tomar en cuenta que estamos asumiendo lo siguiente:

  • La IP de nuestro servidor remoto es 192.168.1.100. Hay que reemplazar esta por la IP real de nuestro equipo del que queramos copiar el respaldo
  • El password default del usuario root del MySQL remoto es eLaStIx.2oo7. Nuevamente, hay que reemplazar este por el correspondiente al servidor

Adaptando este comando podemos prácticamente hacer cualquier tipo de respaldo remoto. Si agregamos la conexión mediante llaves públicas y privadas, podemos dejar estas actividades programadas en el cron para no tener que estar proporcionando la contraseña de SSH cada vez que nos conectamos.

¡Suerte!

Activar las grabaciones por default para todos los usuarios en Elastix/FreePBX

22 Jun

Algunas veces como profesionales llegamos a un conmutador que ya tiene alguna configuración cargada y se nos pide que hagamos modificaciones. Imaginen que de pronto llegan a un callcenter de 100 posiciones que hace uso de Elastix/FreePBX y les dicen: «Queremos que todas las llamadas de todos los usuarios se graben», pero analizando las extensiones se dan cuenta que todas (o ninguna) tiene la grabación habilitada, y que la mayoría se encuentran en modo de grabación «On Demand», cuando ustedes lo que quieres es que sea «Always»

¿Cómo lo hacen? Espero que no piensen en ir extensión por extensión haciendo el cambio…

Para solucionar esto rápidamente, necesitamos hacer 2 cosas:

  1. Modificar la tabla de MySQL asterisk.users
  2. Modificar el Asterisk DB para que coincida con los valores que necesitamos

Y ambas las logramos fácilmente con el siguiente código (desde el Linux CLI):

[codesyntax lang=»bash» tab_width=»3″]

# Primero nos hacemos cargo del AstDB. Este ciclo se encarga de cambiar
# a todos los usuarios que ya existen en el PBX
for i in `asterisk -rx "database show"|grep recording|cut -d/ -f3`
do
	asterisk -rx "database put AMPUSER $i/recording out=Always|in=Always"
done

# Y ahora actualizamos MySQL
echo "UPDATE asterisk.users SET recording='out=Always|in=Always'" | mysql -peLaStIx.2oo7

[/codesyntax]

Este, junto con cualquier otro tip que les dé no debe ser tomado como una «receta» de cocina, ya que si no hacemos las cosas bien, podemos echar a perder algo. Asegúrate que entiendes el ciclo que se propone arriba así como el query que te planteo. Si le piensas bien, esto te puede servir para modificar de manera grupal cualquier cosa que quieras dentro de Elastix/FreePBX, sin que tengas que ir extensión por extensión. Solo falta encontrar la tabla y el valor adecuado y lo demás es muy sencillo.

¡Suerte!

Balanceo de troncales en Elastix (round robin)

21 Jun

Este mini tutorial aplica para FreePBX/Trixbox/Elastix.

La idea tras de esta guía es crear un balanceador de carga. Es decir, tener una sola troncal que automáticamente rote una serie de troncales posibles por las cuales pueden salir las llamadas. Dichas troncales pueden ser DAHDI, IAX2 o SIP, así que esto le agrega flexibilidad.

El código sería algo así (la sintaxis está en AEL para hacer la programación más simple)

[codesyntax lang=»c» tab_width=»3″ blockstate=»expanded»]

// Archivo extensions.ael
context roundrobin {
	_X. => {
		Set(max=10);
		Set(n=0);
		repetir:
		Set(n=${n}+1);
		Set(last=$[(${DB(rr/last)}+1)%${max});
		Set(DB(rr/last)=${last});
		Dial(${DB(rr/trunk${last})}/${EXTEN},30,g);
		if (${DIALSTATUS}!="ANSWERED") {
			if (${n}<${max}) {
				// Repetir ciclo
				goto repetir;
			};
		};
		Hangup;
	};
};
[/codesyntax]

Nos faltan dos pasos:

  1. Inicializar el AstDB con el valor de la primer troncal. Esto es sencillo ejecutando el comando database put rr last 1 dentro del CLI de Asterisk
  2. El paso final es crear una troncal ‘Custom’ dentro de FreePBX/Elastix y agregarla como Local/{OUTNUM}@roundrobin/n. Esto hará uso del canal Local y nos permitirá balancear la carga entre nuestras troncales.

Todas las llamadas que vayan hacia esta troncal ‘Custom’ harán un balanceo de carga entre las lineas contratadas. Util si tienes varias lineas de diferentes proveedores y quieres que el consumo se haga equitativamente.

Suerte,

 

Una posible solución al «No service» de los teléfonos Aastra (y como mejorar el rendimiento de los reportes de llamadas)

17 Jun

Para los que nunca han hecho uso de, Aastra es una marca de telefonía con base en Ontario, Canadá. Últimamente, su crecimiento se ha dado fuertemente gracias a la prevalencia de sistemas como Elastix que se integran muy bien con sus teléfonos. Mi percepción personal de la marca desde el punto de vista del valor del producto es intermedio: no es una marca tan barata como Grandstream o Yealink, pero tampoco es una tan cara como Polycom o Cisco. Es una marca que está a muy buenos medios términos en cuanto a calidad y funcionalidades se refiere.

Un «inconveniente» que tienen sus teléfonos es que son extremadamente sensibles al retraso de paquetes cuando están en modo de stand by. Esto quiere decir que constantemente los teléfonos están enviando paquetes a Asterisk para medir el estado del servicio, y si el servidor por un momento se retrasa con la respuesta, inevitablemente veremos el mensaje de «No service» en la pantalla de los teléfonos, que es como si no estuviéramos registrados.

La solución no siempre está bien establecida porque tenemos que encontrar (y solucionar) lo que sea que esté causando este retraso. Puede ser un problema de la red (no es muy común, pero puede ser) o puede ser que el servidor de Asterisk se encuentre en un proceso que consuma muchos procesos/CPU y ocasione que se retrase para emitir una respuesta. En este caso, vamos a analizar una posible cause de este segundo escenario.

El cliente que hoy me ha reportado que sus teléfonos están perdiendo el registro frecuentemente es una agencia automotriz, que tiene alrededor de unos 140 teléfonos conectados entre Linksys 921 y diversos modelos de la serie Aastra 675x (aunque el problema solo es con los Aastra, por la razón arriba mencionada).

Indagando un poco más, observe que de pronto sus procesos de MySQL subían alredor del 80% del CPU por unos segundos y luego, bajaban a 0%. Esto quiere decir que algo se come el procesador por un instante y luego lo suelta, pudiendo ser la causa del problema que tenemos. Indagué un poco más y me doy cuenta que por default Elastix no utiliza índices en las tablas de CDR, lo cual hace que todos los reportes del detalle de llamadas tengan que «barrer» todos los registros de la tabla para encontrar los que necesitamos. Para un PBX pequeño no hay mucho problema, pero para una tabla que tiene 3.6 millones de registros, buscar en todos ellos resulta algo de uso intensivo de CPU. Para corroborar mi teoria, activé el log de consultas lentas de MySQL, y al hacer un mysqldumpslow desde el Linux CLI, obtuve lo siguiente (no se fijen en el query, fíjense en el tiempo total para ejecutarlo):

[codesyntax lang=»bash»]

[root@100 asterisk]# mysqldumpslow -t 5 /var/log/mysql/mysql-slow.log

Reading mysql slow query log from /var/log/mysql/mysql-slow.log
Count: 14  Time=40.50s (567s)  Lock=0.00s (0s)  Rows=58.6 (820), asteriskuser[asteriskuser]@[XXX.XXX.XXX.XXX]
  SELECT  * from (SELECT  billsec as billsec ,calldate as calldate,clid as clid,src as src,dst as dst,dcontext as dcontext,channel as channel,dstchannel as dstchannel,lastapp as lastapp,lastdataas lastdata,duration as duration,disposition as disposition,amaflags as amaflags,accountcode as accountcode,uniqueid as uniqueid,userfield as userfield, calldate + INTERVAL duration SECOND as fecha_termino from cdr where calldate >= 'S') as resultado where fecha_termino >='S'order by calldate limit N, N

[/codesyntax]

Como se observa, cada consulta toma 40 segundos. ¡Esto es un mar de tiempo solo para ver las llamadas que ha hecho una extensión el día de hoy! El problema se confirma con un EXPLAIN del mismo query:

[codesyntax lang=»sql»]

mysql> EXPLAIN SELECT  * FROM ( SELECT  billsec AS billsec ,calldate AS calldate,clid AS clid,src AS src,dst AS dst,dcontext AS dcontext,channel  AS channel,dstchannel AS dstchannel,lastapp AS lastapp,lastdata AS lastdata,duration AS duration, disposition AS disposition,amaflags AS amaflags,accountcode AS accountcode,uniqueid AS uniqueid,userfield AS userfield,  calldate + INTERVAL duration SECOND AS fecha_termino FROM cdr  WHERE calldate >= ‘2011-01-01 00:00:01’)  AS resultado  WHERE fecha_termino >=’2011/06/17 16:44:23 ‘ORDER BY calldate LIMIT 0, 10000;

+----+-------------+------------+------+---------------+------+---------+------+---------+-----------------------------+
| id | select_type | table      | type | possible_keys | key  | key_len | ref  | rows    | Extra
                   |
+----+-------------+------------+------+---------------+------+---------+------+---------+-----------------------------+
|  1 | PRIMARY     |            | ALL  | NULL          | NULL | NULL    | NULL |  592484 | Using where; Using filesort |
|  2 | DERIVED     | cdr        | ALL  | NULL          | NULL | NULL    | NULL | 3617505 | Using where                 |
+----+-------------+------------+------+---------------+------+---------+------+---------+-----------------------------+
2 rows in set (27.90 sec)

[/codesyntax]

Allí se nota como la consulta NO usa índices y tiene que recorrer los 3.6M de registros. ¿La solución? Agregar un índice al campo calldate que es donde se hacen las consultas de manera principal. Esto se hace con el siquiente comando en MySQL (ojo: dependiendo del tamaño de la tabla de CDR este proceso puede demorar desde segundos hasta horas, por lo que planea muy bien que tu equipo esté disponible para ejecutar esta tarea)

[codesyntax lang=»sql»]

ALTER TABLE `asteriskcdrdb`.`cdr` ADD INDEX `calldate` (`calldate`);

[/codesyntax]

Y al terminar el proceso, podemos validar ejecutando el mismo EXPLAIN:

[codesyntax lang=»sql»]

+----+-------------+------------+-------+---------------+----------+---------+------+--------+-----------------------------+
| id | select_type | table      | type  | possible_keys | key      | key_len | ref  | rows   | Extra|
+----+-------------+------------+-------+---------------+----------+---------+------+--------+-----------------------------+
|  1 | PRIMARY     |            | ALL   | NULL          | NULL     | NULL    | NULL | 592516 | Using where; Using filesort |
|  2 | DERIVED     | cdr        | range | calldate      | calldate | 8       | NULL | 652745 | Using where                 |
+----+-------------+------------+-------+---------------+----------+---------+------+--------+-----------------------------+
2 rows in set (8.84 sec)

[/codesyntax]

Como se observa, la consulta ahora está reducida a 650K registros o bien un 82% de ahorro en cuanto al número de registros que se tienen que consultar.

Aunque esta puede bien no ser la única cause del problema, es un excelente primer paso. Ya ahorramos procesamiento en este ejercicio, ahora hay que indagar en que otros procesos del sistema podemos ahorrarnos unos ciclos para así dejar más recursos disponibles para nuestras llamadas.

Suerte,

Recuperar la contraseña de Elastix/FreePBX

13 Jun

En ocasiones me he enfrentado a la tarea de apoderarme del control de algún servidor Elastix/FreePBX porque el cliente no ha quedado satisfecho con el servicio que su proveedor anterior le ofrecía, así que dado que el cliente no conoce los accesos y los que si lo conocen no me lo van a dar «por la buena», entonces tengo que recuperarlo yo.

Obtener las contraseñas de admin tanto para Elastix como para FreePBX no es complicado, lo único que se requiere es tener acceso de root por SSH (si no tenemos este acceso, podemos obtenerlo siguiendo una de tantas guías para recuperar el password de root que hay en internet). Ya adentro del sistema, podemos hacer lo siguiente desde el CLI de Linux:

echo "UPDATE acl_user SET md5_password='827ccb0eea8a706c4c34a16891f84e7b' WHERE name='admin';" | sqlite3 /var/www/db/acl.db

Con esto cambiamos el password de Elastix a admin/12345. Ahora, para FreePBX:

echo "UPDATE asterisk.ampusers SET password_sha1 = SHA1('12345') WHERE username = 'admin';" | mysql -peLaStIx.2oo7

(estoy asumiendo que tu versión de FreePBX ya ocupa passwords en SHA1 y que el password de root de MySQL sigue siendo el default)

Y con esto cambiamos también el password de FreePBX a admin / 12345. Está de más decir que la primera acción a ejecutar debe ser cambiar estas contraseñas por algo más seguro, pero para ello ya podemos hacerlo accediendo a las interfaces gráficas correspondientes.

Suerte a todos,

Versión mejorada del mensaje «all circuits are busy» de Elastix (v3)

31 May

Este código se encuentra desactualizado. Hay una versión más reciente disponible en http://asteriskmx.com/2013/04/version-mejorada-del-mensaje-all-circuits-are-busy-de-elastix-v4/

En muchas ocasiones hemos oido el mensaje de «all circuits are busy» («todos los circuitos se encuentran ocupados» si es que tenemos los sonidos en Español) de Elastix. El problema con este mensaje es que es reproducido ante cualquier falla de nuestro enlace. Esto incluye a números que no existen, números desconectados y cualquier otra causa de error que no siempre es culpa de nuestro conmutador, pero que el usuario final siempre le achaca al sistema que le configuramos.

Con la intención de abrir un poco el panorama y dar más información sobre la causa del error, escribí este código para ayudar a distinguir cual es la verdadera causa del problema. Para ello, es necesario modificar 2 archivos, dentro de /etc/asterisk

// Archivo extensions.ael
macro outmessage(HC) {
        switch(${HC}) {
                case 1:         // Unnalocated or unnasigned number
                                // El numero que marco no existe
                        Set(MSG=no-existe);
                        break;
                case 17:        // User is busy
                                // Tono ocupado
                        Busy;
                        break;
                case 20:        // Subscriber absent
                                // El número celular que usted marcó no está disponible o se encuentra fuera del area
                        Set(MSG=numero-celular-no-disponible);
                        break;
                case 28:        // Address incomplete
                                // Numero mal marcado
                        Set(MSG=cannot-complete-as-dialed&check-number-dial-again);
                        break;
                case 27:        // Destination out of order
                case 38:        // Network out of order
                        // El telefono que marco esta fuera de servicio
                        // El telefono que marco esta descolgado o en reparacion
                        Set(MSG=fuera-servicio);
                        break;
                case 41:        // Temporary failure
                                // Falla temporal en la red
                        Set(MSG=falla-red);
                        break;
                case 42:        // Switching equipment congestion
                                // Congestion por alta cantidad de trafico en la central
                        Set(MSG=alto-trafico);
                        break;
                case 102:       // Recovery timer expired
                                // No se obtuvo una respuesta de la central telefónica
                        Set(MSG=no-respuesta);
                        break;
                case 34:        // Todos los circuitos están ocupados
                default:
                        Set(MSG=all-circuits-busy-now&pls-try-call-later);
        };
        Playback(${MSG},noanswer);
        &hangupcall();
};
; Archivo extensions_override_freepbx.conf
[macro-outisbusy]
exten => s,1,Progress
exten => s,n,Macro(outmessage,${HANGUPCAUSE})

Con estas modificaciones, necesitamos ejecutar dos comandos dentro del *CLI:

ael reload
extensions reload

Y por último, necesitamos extraer el contenido del siguiente archivo de sonidos dentro de la carpeta /var/lib/asterisk/sounds

Con esto, Elastix nos dará un poco más de información indicándonos los siguientes casos:

  1. El número no existe
  2. El número está fuera de servicio o en reparación

Para todos los demás problemas, se entregará el default de «todos los circuitos se encuentran ocupados»

Conforme consiga más grabaciones para diferentes casos, incluiré más códigos de error dentro de este código, a manera de poder diferenciar mejor cada error. Desde la siguiente liga pueden descargar los Sonidos para mejorar el mensaje de error de Elastix

Estadísticas de inseguridad en Elastix (México)

9 Mar

Hoy decidí realizar un estudio sobre las vulnerabilidades que sería capaz de encontrar en un entorno como Elastix en México. Me puse mi sombrero blanco y decidí escanear todas las posibles redes del país y buscar cuantos equipos utilizan la distribución antes mencionada (al menos las visibles en el puerto TCP 443), y los resultados fueron alarmantes. Aquí algunas estadísticas:

25.4 millones de hosts escaneados
69 mil tienen el puerto 443 abierto
467 equipos eran Elastix

Aclaro que esto no quiere decir que estos sean todos los equipos Elastix en México. Esto quiere decir que en una noche cualquiera fui capaz de encontrar 467 equipos visibles abiertamente en internet, los demás están tras algún firewall y son invisibles al exterior (¡bien!).

Ahora, para los números del terror:

  • 287 tienen algún tipo de dato «secreto» que se puede obtener fácilmente (contraseña de FreePBX, contraseña de Elastix, contraseñas de extensiones)
  • los mismos 287 tienen el puerto SIP abierto
  • 261 tenían algún tipo de contraseña default para FreePBX
  • 26 aún tenían la contraseña de «palosanto» para Elastix
  • 31 usan la misma contraseña en FreePBX que en Elastix
  • 42 aún usan FreePBX 2.5.x que muestra la contraseña de administrador en texto plano

Y quizá la más sobresaliente:

  • 197 usan alguna distribución de Elastix suficientemente vieja que permite descargar el archivo de batch extensions, entregándote el archivo que nombra todas las extensiones del sistema con sus respectivas contraseñas, dando un total de ¡8,300 extensiones disponibles para hacer llamadas en Elastix ajenos!

Esto quiere decir que aún con una tasa de fallo del 50%, tengo 4,150 de posibles extensiones desde las cuales se pueden sacar llamadas sin pagar un solo centavo, ocasionando tráfico VoIP que en pocas horas se convierte en facturas millonarias de teléfono.

Y si creen que exagero, échenle cuentas:

  • Supongan que de los 197 servidores visibles, al menos 170 tienen algún tipo de interfaz FXO o E1
  • Supongan que en una sesión de ataque promedio, puedo cursar llamadas por el mismo equipo (por la noche) durante unas 4 horas
  • Supongamos que promediando la cantidad de canales de E1 y de puertos FXO, puedo cursar 3 llamadas simultáneas por servidor

Esto me da un total de 4 horas * 60 minutos * 3 llamadas simultáneas * 170 servidores = 122,400 minutos de tráfico. Si el destino costara $7/min, hablamos de un total facturado de $856,800, ¡en unas horas!

Y claro que este es el espectro conservador: conozco casos de 2a persona que han tenido facturaciones de $24,000 en una sola pasada. Hagan números, y fácilmente comprenderán por que esto del robo de VoIP está tan de moda y resulta tan redituable.

Obviamente si no quieren convertirse en amigos de lo ajeno, sigan las ya super conocidas medidas de seguridad para cualquier entorno Asterisk:

  1. Siempre cambien las contraseñas default
  2. Tampoco usen palabras de diccionario como contraseña
  3. No den acceso desde el exterior si no se necesita. Esto aplica a los puertos UDP 5060 y TCP 22, 443 (los más comunes)
  4. User el permit deny dentro de Asterisk para limitar que IPs se registran en cada extensión.
  5. No usen contraseñas y passwords iguales (user:100 pass:100)
  6. Actualicen sus distribuciones a la más reciente versión
  7. Limiten la cantidad de llamadas simultáneas por extensión (¿Por qué razón Juan Pérez haría 20 llamadas a la vez?)
  8. Rechazen malas autenticaciones sin dar más detalles (alwaysauthreject=yes) en sip.conf
  9. Firewall firewall firewall
  10. Usen fail2ban para defenderse de ataques de fuerza bruta
  11. Autentiquen al usuario, no solo al teléfono (usen contraseñas post-marcado)
  12. Nieguen llamadas anónimas provenientes del exterior
  13. Definan planes de marcación limitados (ojo con el dialplan injection)

Asterisk/Elastix como tal son bastante seguros: es el administrador el que los hace inseguros al obviar cualquier de estos pasos sugeridos. Todos los puntos que aquí se mencionan también se estudian desde nuestros cursos Asterisk

Suerte, y…  ¡aseguren sus equipos!