feltoxXx

Muchos usuarios de Elastix no toman en cuenta que después de haber instalado y configurado su central, y dejar esta en funcionamiento aún queda mucho trabajo por hacer, sobre todo en el lado en cuanto a seguridad se refiere. Existe mucha gente y empresas alrededor del mundo que día a día buscan romper servidores VOIP, esto con el simple objetivo de enrutar tráfico a través de estos servidores hacia destinos de costos muy altos, de esta forma estas personas pueden comercializar minutos que normalmente tienen un costo alto a una fracción del costo. En tan solo 1 hora se puede llegar a enviar hasta casi 2000 minutos a través de un enlace E1 con 30 canales activos, lo que en números redondos puede llegar a costar mas de 200 USD tomando en cuenta que se enrute tráfico a un destino de bajo precio, pero a otros podría llegar a costar hasta 2500 USD. Estas matemáticas simples nos alertan de la importancia de implementar políticas de seguridad, a continuación hablaremos de algunas de ellas que deben de ser básicas en nuestras instalaciones y otras que de ser posible no se deben de dejar a un lado. #1- Utilice contraseñas fuertes. Después de recientes ataques a Gmail y otros servidores de correo se descubrió que la contraseña mas utilizada por los usuarios increíblemente era “123456″ y por desgracia esta es la misma que muchos usuarios de Elastix utilizan, haciendo así 100% vulnerable su equipo. Se recomienda utilizar combinación de caracteres especiales (#,,%,&,/,@, etc.), números y mayúsculas y minúsculas además de evitar utilizar secuencias de números o palabras que se puedan encontrar en el diccionario. No solo la contraseña de root y usuario Web deben tener estas características, también las contraseñas de MySQL, FreePBX, FOP, y de las extensiones sobre todo. #2- Cambie las contraseñas de Default. Hay que tomar en cuenta que existen mas de 500,000 descargas de Elastix, por lo tanto existen al menos 500,000 usuarios que conocen todas las contraseñas que tiene este software por defecto, sin tomar en cuenta los que realizan la búsqueda “Elastix default passwords” en Google. NUNCA utilice como contraseña de las extensiones el mismo número de extensión, esto facilita las cosas hasta para el menos experimentado de los hackers. Recuerda cambiar al menos tus contraseñas del FOP, FreePBX , Web y MySQL. #3- Restringa el acceso a sus Equipos. Si existe la posibilidad bloque el acceso a sus equipos desde direcciones IPS que no pertenezcan a las de su país. Utilice IPTables para restringir el acceso a ciertos puertos desde ciertas direcciones No deje abierto el acceso SSH y Web para cualquiera, una vez que se rompe alguna de estas contraseñas el intruso puede hacer cualquier cosa con nuestro equipo. #4- Cambie sus puertos de Acceso. Para un atacante será mas fácil su trabajo si sabe que puertos debe de atacar, así que si cambiamos los puertos comunes haremos que por lo menos su trabajo sea un poco más complicado, dándonos tiempo detectar estos ataques en nuestros logs . Al menos debemos cambiar el puerto de nuestro servidor SSH y de las extensiones remotas. Este cambio lo podemos hacer en nuestro servidor o con algunos routers que nos permiten realizar traducción de puertos, de modo que al intentar conectar a nuestro equipo por el puerto 786 por ejemplo , realiza la traducción al puerto 22, pero si intentamos conectarnos al puerto 22 directamente este se encuentra bloqueado #5- Utilice software para el escaneo de logs. Fail2Ban es un software que escanea los logs de nuestros equipos en búsqueda de repetidos intentos de autenticación fallida y bloqueando de forma automática dicha IP, de forma tal que la lp del atacante será bloqueada después de cierto número de intentos no permitiéndole así adivinar o descifrar nuestras contraseñas. #6- Utilice VPN’s para la conexión a sus servidores. El uso de túneles VPN tanto para el acceso de administración de nuestros equipos como para la conexión de extensiones remotas nos garantiza no solo que no cualquier persona podrá alcanzar nuestros equipos, sino que además la información viajara encriptada de forma tal que será difícil de detectar. Nuestro equipo Elastix puede ser configurado como servidor VPN en pocos pasos y en tan solo 10 minutos, en futuras publicaciones hablaremos de como realizar esto. #6- Ajuste la configuración de sus archivos de configuración SIP. Muchas veces creemos que los archivos de configuración vienen listos y 100% preparados y no requieren de mayor configuración, pero esto no es así, existen ciertos parámetros de seguridad que debemos de especificar y que no nos tomará mas de 5 minutos en hacerlo. Cuando un usuario se autentica incorrectamente recibe un mensaje de reject pero dentro de este mensaje se encuentra la información correcta de registro, así que si se logra descifrar tenemos las credenciales correctas para registrarnos y comenzar a realizar llamadas, es por ello que es importante cambiar alwaysauthreject=no a alwaysauthreject=yes. Limite el número de llamadas simultaneas por usuario al mínimo posible. En el peor de los casos en que logren descifrar las credenciales de algún usuario el daño será mínimo. #7- Utilice un firewall. Muchos se quejan del alto costo de un appliance especial para el bloqueo de intrusos y ataques, pero pocos toman en cuenta que es un inversión que nos puede ahorrar varios cientos de dólares sino es que miles. Algunas veces hay que hacer un poco mas de la inversión planeada y un firewall es una de ellas, estos appliances dedicados nos pueden salvar y mantener lejos de la mira de los hackers, claro , hay que recordar que no basta con conectar los equipos a la red y energizarlos, hay que configurarlos. #7- No acepte trafico anónimo. Si nuestro servidor tiene acceso público jamás debemos de activar la opción de aceptar llamadas anónimas, esto permitiría que cualquiera enviar tráfico a nuestro servidor sin la necesidad de autenticación. Por último debemos de recordar que el registro en logs existe por algo, no son un adorno, es importante revisar periódicamente estos archivos en búsqueda de Warnings y Errores que nos indiquen que hemos recibido ataques a nuestros equipos, de igual forma debemos mantenernos informados y pendientes de las listas de desarrollo y usuarios ya que en ellas se reportan Bugs de seguridad y además la solución a los mismos. http://voipenlared.blogspot.com

MFC/R2 es un protocolo de señalización dentro de banda por cada canal (CAS channel associated signalling) sobre tramas digitales E1 usado principalmente en Latinoamérica (quizás el más usado todavía hoy). El cual es soportado perfectamente en Elastix® debido a la inclusión de la librería OpenR2 la cual implementa señalización MFC/R2 sobre líneas E1 usando la interfaz de telefonía DAHDI. El autor de dicha librería y los parches de Asterisk® correspondientes es Moisés Silva quien actualmente trabaja para la firma canadiense Sangoma® y a quien personalmente agradezco por todo su trabajo y ayuda. ¿Qué es MFC/R2? MFC/R2 es una señalización telefónica usada ampliamente en Argentina, Colombia, Venezuela, México, Brasil y otros países de Latinoamérica y Asia con su origen en los inicios de la telefonía digital allá por fines de la década del 70. Las iniciales de MFC/R2 provienen de Multi-Frequency Compelled R2 (R2 dirigido por multifrecuencia). Comparado con protocolos de señalización más recientes como el ISDN PRI/BRI o SS7, R2 ofrece funcionalidades bastante limitadas. La señalización solo se usa para establecer la llamada o para finalizarla. A su vez algunas de las variantes MFC/R2 envían pulsos de cobro mientras dura la llamada, aunque raramente son usados. Existen variantes analógicas y digitales de MFC/R2, pero cualquier referencia a MFC/R2 o R2 en éste documento solo se basa en la versión digital usada sobre enlaces E1. Un dato curioso sobre este protocolo es que a pesar de estar definido y estandarizado por la ITU (International Telecommunication Union), cada país sigue su propia variante… L ¿Cómo funciona MFC/R2? MFC/R2 es un protocolo de señalización peer-to-peer, lo cual significa que solo hay dos participantes involucrados sobre un enlace E1 R2 y ambos extremos se comportan del mismo modo, muy distinto con respecto a ISDN PRI donde se tiene la un extremo servidor “NET” y otro cliente “CPE” del enlace. Como se nombró anteriormente, MFC/R2 significa Multi-Frecuency Compelled R2 y dicho nombre describe la naturaleza de ésta señalización, donde se tienen dos tipos de señales (valga la redundancia): · Señales de Línea. Son usadas para monitorear el estado de la llamada y las señales MF son usadas para transmitir información de la misma durante el establecimiento de la misma (DNIS, ANI, Calling Party Category). Las señales de línea se envían utilizando señales CAS que viajan usando el canal 16 del enlace E1. Todas las señales CAS de cada canal del E1 son multiplexadas en éste canal. Cada 2 milisegundos cada extremo del enlace actualiza sus 4 bits de señal CAS mas conocidos como los infames bits ABCD. MFC/R2 usa 2 de esos 4 bits para enviar las siguientes señales: Idle, Block, Seize, Seize Ack, Clear Back, Forced Release, Clear Forward, Answer. Al usarse sólo 2 bits para 7 posibles señales es imposible no repetir algún patrón, es por eso que algunas de las 7 señales tienen el mismo patrón de bits, pero esto no representa un problema considerando que, por ejemplo, no se puede ir del estado Idle al Forced Release, por lo tanto, aunque el patrón de bits para Forced Release y Seize son los mismos, el protocolo conoce lo que lo que el otro extremo del enlace quiere decir de forma inequívoca. La razón de usar sólo 2 bits teniendo 4 disponibles es histórica y proviene de la época donde la versión analógica de MFC/R2 fue portada para trabajar en el ese entonces novedoso mundo digital. La siguiente tabla describe los patrones de bits usados en la señalización R2 mediante los bits ABCD de CAS. · Las señales de direccionamiento, por el otro lado, son 15 diferentes señales MF, que son tonos audibles compuestos por 2 frecuencias que viajan usando el canal de audio, y es por eso que el analizador/detector de audio es el componente quizás mas importante en el paquete R2. La librería OpenR2 por defecto usa su propio analizador/detector de MF sobre R2, el cual fue tomado prestado de la librería SpanDSP de Steve Underwood. A diferencia de su antecesor Unicall no es necesario instalar SpanDSP ni otras librerías para usar OpenR2, ya que el detector se encuentra “embebido” dentro de la misma de forma nativa. La ITU define qué frecuencias pueden ser mezcladas para componer los tonos MF y asigna los significados de cada uno de ellos. Sin embargo tal como fue comentado anteriormente, algunos países asignan diferentes significados a estos tonos MF. Dichos tonos MF son identificados en la librería OpenR2 usando los números del 1 al 0 (0 siendo 10) y letras de la B a la F (la A no es usada, en su lugar se usa 0). Si nosotros habilitáramos el debugging del módulo de OpenR2 veríamos los detalles de qué tonos son enviados y recibidos durante el transcurso de cada llamada. Los tonos multifrecuencia (MF) son usados para transmitir los ANI (Automatic Number Identification, mas conocido como Identificador de Llamada), los DNIS (Dialed Number Identification Service, que es, el número marcado o número destino) y las Categorías de Marcado. Tan pronto como la llamada es aceptada o rechazada, el analizador/detector de MF se deja de usar y no se intercambiarán más señales MF, recién ahí el canal de audio puede ser usada para transmitir la llamada de voz. Configuración de E1 R2 en Elastix 1.5.2-2 o superior. · Para tarjetas que usan el driver DAHDI de forma nativa: o Primero nuestra tarjeta de trama digital debe usar el estándar E1 por lo cual debemos verificar que su correspondiente jumper o configuración este seteada en dicho estándar o En caso de usar múltiples tarjetas E1 verificar que los controles de identificación de tarjetas estén correctamente seteados (1er tarjeta en 0, 2da en 1, etc.) o Verificar que la tarjeta es correctamente reconocida en Elastix® usando el comando # lspci desde la consola. o Utilizar la herramienta # dahdi_genconf para generar una config básica estándar (la vamos a usar para no tener que contar a mano los canales) si tenemos varias tarjetas o varias tramas E1. o Con la información de nuestro proveedor de telefonía en la mano vamos a proceder a configurar la trama digital a nivel del driver DAHDI, este es un ejemplo típico de 1 trama simple E1 para Argentina: § Archivo: /etc/dahdi/system.conf span=1,1,0,cas,hdb3 ;reloj master, señalización CAS, Coding hdb3 cas=1-15,17-31:1101 ; Canales CAS del 1 al 15 y 17 al 31 bits en block dchan=16 echocanceller=mg2,1-15,17-31 ;Cancelación eco MG2 en los canales loadzone=ar defaultzone=ar ; zonas de tonos argentinos del driver DAHDI § Archivo de Asterisk para configurar los canales mfcr2, chan_dahdi.conf, debajo de las configs por defecto del archivo agregamos: resetinterval=never context=from-pstn group=0 echocancel=yes signalling=mfcr2 mfcr2_variant=ar ; variante de r2 de nuestro país mfcr2_get_ani_first=no mfcr2_max_ani=10 ;cantidad de dígitos del caller id a recibir mfcr2_max_dnis=4; cantidad de dígitos de nuestros DID´s mfcr2_category=national_subscriber mfcr2_mfback_timeout=-1 mfcr2_metering_pulse_timeout=-1 channel =>1-15,17-31 ; canales a configurar igual que en system.conf o Luego restarteamos nuestros drivers Dahdi y el servicio de Asterisk® y verificamos si nuestra trama está en funcionamiento (imágenes de muestra de un sistema real) § # service dahdi restart § # amportal restart o Imagen de la herramienta dahdi_tool con trama E1 R2 corriendo correctamente: o Imagen de la salida del comando mfcr2 show channels de asterisk demostrando que los canales están funcionando: o Los canales ya pueden ser usados desde el FreePbx y Elastix® tal como los veniamos usando con otras tarjetas. En este caso serían el grupo Dahdi/g0. · Para tarjetas Sangoma®: o Parar los servicios de Asterisk® # amportal stop o Parar los drivers Dahdi # service dahdi stop o Parar el servicio wanrouter de Sangoma # service wanrouter stop o Ejecutar el comando # wancfg_dahdi y seguir las instrucciones del mismo, cuando llegue a selección de estándares seleccionar E1, ISDN pri con estándar EuroISDN, elegir que grabe los cambios sin restartear el dahdi ni asterisk. o Al terminar este paso editar el archivo /etc/wanpipe/wanpipe1.cfg buscar la línea donde dice TE_SIG_MODE = CCS y reemplazarlo por CAS, grabar el archivo y luego retomar la config exactamente igual que como está descripto en el apartado de Dahdi nativo arriba descripto. o Al finalizar de editar los archivos /etc/dahdi/system.conf y /etc/asterisk/ chan_dahdi.conf debemos levantar de nuevo los servicios en este orden: § # service wanrouter start § # service dahdi start § # amportal start o Por último verificamos que la trama haya levantado igual que en el ejemplo anterior con el comando de asterisk cli> mfcr2 show channels · En el caso de varias tramas digitales solo cambian los números de canales y este ejemplo es totalmente válido para 1 a n tramas. · Es posible en 1 misma tarjeta o en 1 mismo sistema mezclar diferentes spans de trama y cada uno con su propio protocolo ya sean R2 o ISDN primario. Nuevamente espero que este humilde aporte los ayude y agradezco a Moises Silva, a Alexandre Alencar y a Juan Carlos Huerta por sus aportes en la realización de este documento y por favor si desean soporte, mas info o consultas específicas les solicitamos hacerlas a través del soporte oficial pago de de nuestra empresa y de Elastix® para seguir apoyando el crecimiento del Software Libre. http://voipenlared.blogspot.com

Supongamos que tenemos dos localidades y en cada una un Asterisk. Podemos interconectar estas a través de Internet con este sencillo procedimiento. Es el mas facil de todos, tiene la debilidad de no ser muy seguro, pero con encriptacion aes128 y una red vpn se solventa parte del problema Voy a llamar al servidor de la Localidad A como ServidorA y al de la Localidad B ServidorB. De igual manera, voy a asumir el siguiente esquema de extensiones: Servidor IP Extensiones ServidorA 192.168.0.1 2001 a 2099 ServidorB 192.168.1.1 3001 a 3099 Creamos una nueva troncal IAX2 desde el menú PBX / Troncales: En ServidorA: TRUNK NAME: servidorb host=192.168.1.1 encryption=aes128 auth=md5 type=friend qualify=yes En ServidorB: TRUNK NAME: servidora host=192.168.0.1 encryption=aes128 auth=md5 type=friend qualify=yes Creamos las rutas salientes en ServidorA: Route Name: LocalidadB Dial Patterns: 3XXX Trunk Sequence: IAX2/servidorb Creamos las rutas salientes en ServidorB: Route Name: LocalidadA Dial Patterns: 2XXX Trunk Sequence: IAX2/servidora Ahora podemos llamar desde LocalidadA hacia LocalidadB y viceversa Si queremos ahorrar ancho de banda se pueden agregar estas dos líneas en la configuración de cada troncal estos parámetros para permitir el uso de codecs de bajo consumo de ancho de banda: disallow=all allow=gsm&ilbc El otro caso es que ambos rangos de extensiones en los dos servidores sean iguales o se solapen parcialmente. Al ser iguales en partes cuando marcamos la extension 3501 en el servidorA el no sabra si enrutar la llamada a la extension 3501 del servidorA o a la del servidorB. Para evitar esto se usa un prefijo que le dira a cada servidor hacia donde dirigir la llamada, solo añadimos en las rutas salientes el prefijo a usar, de esta manera: Para ServidorA: Route Name: LocalidadB Dial Patterns: 9 | 3XXX Trunk Sequence: IAX2/servidorb Para ServidorB: Route Name: LocalidadA Dial Patterns: 9 | 2XXX Trunk Sequence: IAX2/servidora Como podran ver yo use el prefijo 9, uds pueden usar cualquiera. Espero les sirva de ayuda. http://voipenlared.blogspot.com/