Etiqueta: debian

  • Asterisk no estará disponible en Debian Bookworm

    Asterisk no estará disponible en Debian Bookworm

    La versión de Debian Bookworm no incluirá los paquetes de Asterisk por falta de personas que se encarguen de crear los paquetes necesarios para ser incluidos.

    La falta de mantenedores y los problemas con la biblioteca PJSIP parecen ser el problema. Los paquetes de Debian Asterisk ya se han quedado obsoletos con los parches de seguridad, por lo que hacen falta más personas que ayuden a compilar y empaquetarlo para esta versión de Debian.

    Asterisk sigue siendo un software muy necesario en muchos ecosistemas de comunicaciones y aunque la mayoría de nosotros solemos compilar a mano las versiones que instalamos, hay muchas personas que prefieren utilizar el sistema de paquetes de Debian por facilidad a la hora de actualizar, configurar y buscar algo más de estabilidad con versiones bastante probadas.

    Más información: Oej!

  • Autentificación en dos pasos en Debian 10

    Autentificación en dos pasos en Debian 10

    Siempre he sido de la opinión que no hay que ser un paranoico de la seguridad, simplemente intentar que todo lo que se hace debe ser lo más seguro posible: «La seguridad no es un lema, es una forma de vida» y por esta razón, cuando vi el siguiente gráfico de tiempos que tardaría una máquina en conseguir una contraseña, me entró la curiosidad sobre qué se puede hacer normalmente para evitarlo.

    Visto lo visto, con las GPUs que hay hoy día y la potencia de cálculo que tienen los sistemas cloud comerciales, crear una contraseña de menos de 12 caracteres es básicamente instalar una bomba de relojería a la espera de que venga un bot con algo de tiempo y acceda a nuestros sistemas.

    Uno puede pensar en contraseñas largas y complejas con más de 15 caracteres, mayúsculas, números, símbolos, alguna coma, un signo dólar y alguna Ñ, pero a la vista de la cantidad de contraseñas que hay que escribir, al final lo mejor y más cómo para evitar repetir la misma contraseña, es utilizar una herramienta que sirva como «llavero» y que contenga las contraseñas que utilizamos, tan grande y complejas como queramos, de manera que no haya que recordarlas.

    Herramientas llavero

    Suelo utilizar la herramienta KeePass que permite crear varias bases de datos cifradas con las contraseñas que uso para diferentes motivos (empresa, servidores, personal, clientes, loqueseteocurra, etc.) y tras una contraseña maestra para cada base de datos, poder acceder a toda la lista de accesos con total seguridad. Esas bases de datos están en archivos cifrados dentro del sistema de ficheros local, por lo que la seguridad es mucho mejor que tenerlo en un Post-it en el monitor, en una libreta de papel o en una hoja Excel (ya que ésta última no suele ir cifrada).

    El problema de este tipo de herramientas es que, cada vez que hace falta acceder a un sitio, hay que abrir la aplicación, meter la contraseña, buscar el acceso que necesitas y gracias al «copy+paste«, poder pegar la contraseña y así, autentificarte de forma segura. No es la fórmula más práctica. (aunque luego explicaré cómo soluciono esto).

    2 contraseñas: la segunda, varía con el tiempo

    Yubikey con las llaves de casa

    No obstante, investigando un poco cómo lo harán en las grandes empresas de seguridad, recuerdo el caso de un amigo que trabaja en Google y que, cuando entró, en el pack de bienvenida, le entregaron además de un montón de merchandising, un portátil y algunas cosas más, una Yubikey: una mochila USB que sirve como sistema de dos pasos automático.

    Introduces el login, la contraseña y cuando se comprueba que es correcto, además te pide un código que, en lugar de enviarte un código al móvil, sólo tienes que «tocar» la Yubikey y ésta rellena la parte del código de segundo paso. Si alguien te roba la contraseña no podrá hacer nada, ya que no tendrá tu móvil o la mochila USB para saltarse el segundo paso, y la Yubikey suele ir como una llave más del llavero, por lo que siempre la llevas contigo, igual que tus llaves de casa.

    El sistema de autentificación de dos pasos siempre me ha parecido muy interesante desde que hace muchos años (hace más de 13 años) un amigo belga me enseñaba cómo utilizaba la autentificación en dos pasos para sacar dinero de su banco. Un aparato especial le generaba un código que tenía que meter como «segundo pin de seguridad«.

    Ahora se ha visto que el hecho de enviar un SMS al móvil no es lo más seguro, ya que hay quien incluso te clona la tarjeta SIM para poder recibir el mensaje y hacerte verdaderos desfalcos (lo que significa que ya tienen tu usuario y contraseña y sólo les para esa doble autentificación), así que me puse a mirar el sistema de Google para el tema de generar el código necesario.

    A falta de tener una Yubikey de esas para hacer pruebas, tengo un móvil con el que generar los códigos de segunda autentificación, y una lista interesante de servidores personales y máquinas a las que accedo normalmente por SSH, voy a ver cómo dotarla de algo más de seguridad.

    Autentificación de dos pasos para acceder por SSH al servidor

    Para ello, se me ocurrió usar la doble autentificación (o autenticación, que es lo mismo) en el acceso SSH, lo único que, en lugar de enviar un SMS, voy a utilizar una aplicación en el móvil que genere un código de seguridad válido gracias a un token.

    Para esto existen dos aplicaciones comunes: GoogleAuthentication y FreeOTP (las dos funcionan igual, aunque utilizaré FreeOTP por ser software libre y darme algo más de confianza).

    Lo que vamos a hacer será configurar el sistema de acceso por SSH, de manera que una vez introduzca la contraseña, se añada una verificación extra (de ahí lo de «los dos pasos») que me solicite un número variable que sólo tendré yo gracias a la aplicación FreeOTP.

    1. Instalación de los paquetes necesarios

    Para configurar esto en una Debian, lo primero es instalar un paquete básico:

    ~$ sudo apt update
    ~$
    sudo apt install libpam-google-authenticator

    Este «libpam-google-authenticator» es uno de los módulos del sistema PAM (Pluggable Authentication Modules) de manera que se ejecute después de la autentificación estándar para poder permitir el acceso.

    2. Configuración del SSH y del PAM

    Acto seguido, vamos a editar el archivo de configuración del demonio SSH /etc/ssh/sshd_config para decirle que queremos utilizar el sistema de módulos PAM.
    Para ello, nos aseguramos que tenemos estas opciones habilitadas:

    UsePAM yes
    ChallengeResponseAuthentication yes

    Nada más asegurarnos de esto, editamos el archivo: /etc/pam.d/common-auth donde añadiremos las siguientes líneas:

    # Autentificacion OTP mediante Google Authenticator
    auth required pam_google_authenticator.so

    3. Instalar la aplicación FreeOTP o GoogleAuthenticate.

    En mi caso, utilizo FreeOTP que es software libre y se encuentra tanto en Google Play como en la App Store.

    Una vez instalado, y ejecutado, hay que dar permisos para utilizar la cámara, ya que tendremos que escanear un código QR que nos saldrá por pantalla con el «token» del servidor al que nos vamos a conectar y que se utilizará para generar las contraseñas en función del tiempo.

    Ahora bien, nos logueamos por SSH con el usuario que queramos y ejecutamos el comando:

    ~$ google-authenticator
    Do you want authentication tokens to be time-based (y/n) y

    Tras esto, nos saldrá por pantalla un código QR que tendremos que escanear desde nuestra aplicación.

    Le decimos que «yes» a todo… y guardamos bajo llave los códigos de «emergencia» por si no tenemos nuestro móvil a mano para generar la clave. (Estos códigos sólo se pueden utilizar una vez cada uno, por lo que hay que guardarlos muy bien o volver a generar el token)

    4. Reiniciar el servidor para aplicar cambios

    Vale, nuestro usuario ya tiene habilitado el token de seguridad, ahora lo último que tenemos que hacer es reiniciar el servidor SSH para que utilice el sistema PAM con el módulo que hemos añadido.

    ~$ systemctl ssh restart

    5. Comprobamos el acceso

    Ahora que ya está todo funcionando, volvemos a acceder con el mismo usuario que hemos activado el token y veremos que una vez introducida la contraseña, nos pedirá un código.

    En este momento, habrá que buscar el código en la aplicación.

    Captura del FreeOTP

    Tendremos 30 segundos para introducir el código tras lo cual, tendremos acceso al sistema.

    En resumen

    Vale, lo primero… muy intuitivo no es, y rápido tampoco, pero si es más seguro que un acceso normal.

    El hecho de tener que acceder a una aplicación del móvil para poder acceder a nuestra cuenta, no es algo que sea muy práctico si nos pasamos el día accediendo a ella, de ahí la utilidad de la Yubikey. Para este tipo de cosas está la autorización de llave pública y de esta manera evitamos tener que meter contraseñas (incluso utilizando la autentificación que hemos visto) y accedemos rápidamente al sistema que queramos validando directamente la clave de nuestro ordenador con el servidor.

    Por lo que, para sistemas en los que necesitemos un extra de seguridad, seguramente sea una buena fórmula.

    Si aplicamos este sistema (OTP – One-Time-Password) a otros servicios, posiblemente aumentaremos bastante la seguridad. Como decía al principio, la idea no es ser un paranoico de la seguridad, si no aprender a ser seguros en todo lo que hagamos.

  • 3CX se pasa a Linux

    3CX se pasa a Linux

    switch_to_linuxAunque puede ser una broma típica de el día de los inocentes, podemos asegurar que no lo es y que la gente de 3CX han tardado demasiado tiempo en darse cuenta de las ventajas de utilizar un sistema operativo realmente serio para su servidor de comunicaciones y es que 3CX acaba de anunciar su primera versión que funciona en Linux, concretamente en Debian.

    Tras leer ríos de tinta sobre las bondades de Windows, su facilidad de uso para usuarios no experimentados y la alternativa fácil que 3CX representa para aquellos que no quieren pelearse con Linux, ahora 3CX da el salto a Linux y echa por tierra toda esa filosofía por la cual un usuario prefirió usar 3CX a usar otro sistema de comunicaciones que corriese en Linux como pueda ser Asterisk, Freeswitch, o similares.

    Sencillamente el coste de mantener un servidor windows  (con los recursos hardware básicos que ello conlleva) más el coste de las licencias del sistema operativo, antivirus, etc. ha hecho que 3CX saque una versión para Linux orientado a reducir el coste global de la solución recortando en hardware ya que, un sistema mínimo en Windows requiere mucho más hardware que el mismo en Linux.

    En 2010 ya había quien «bromeaba» con la posibilidad de ver una versión de 3CX en Linux hasta tal punto que un ingeniero de 3CX negaba categóricamente esa posibilidad hasta el punto que, bromeando, indicaba que si alguien veía una versión de 3CX corriendo en linux, seguramente se trataría de una falsificación. 😀

    En fin, habrá que probarlo, pese a todo, es un buen cambio (más vale tarde que nunca), el siguiente paso puede ser, quien sabe… ¿dejar de usar ASP y pasarse a PHP?

  • Conferencia sobre WebRTC en la DebConf13

    En la pasada edición de DebConf 13 celebrado el pasado 11-18 de Agosto en Suiza, se dio lugar una conferencia sobre WebRTC bajo un entorno Debian que podéis ver íntegra en el enlace inferior y que, como podéis ver en la imagen utilizaron para ello la librería JsSIP.

    debconf-webrtc

    (más…)

  • Por qué recomiendo Debian y no CentOS

    Antes de empezar, me gustaría comentar que este es un artículo atípico, y profundamente personal, que no tengo nada en contra de CentOS (que es un proyecto elaborado muy honradamente por usuarios desinteresados y que, como la mayoría de proyectos de software libre, trabajan duro en mantener una distribución que es una tarea muy complicada, difícil y poco gratificante). También me gustaría comentar que este artículo es una respuesta PERSONAL ya que me han pedido mi opinión en varias ocasiones sobre qué distribución es mejor para Asterisk y porqué motivo, así que, sin ánimo de ofender a nadie, daré mi punto de vista sobre si el color Naranja es más bonito que el Verde, así que posiblemente no estés a favor de lo que diré en este artículo, ni mi deseo es convencer a nadie. Tan solo es una mera opinión, basada en mi experiencia y que simplemente deseo compartir con aquellos que quieran leerlo, y no… no me considero un «talibán» ni un «radical» como a veces me han llamado… es simplemente la opinión basada en la experiencia.

    A través de un comentario de un compañero en Facebook, y siguiendo la conversación en Twitter (tenemos redes para todos los gustos. 😀) sale el tema ultra-quemado sobre qué distribución es más aconsejable para Asterisk. Este tema es arto cansino y es que, como siempre digo cada cual tiene sus gustos y no hay que defender a muerte una distribución, principalmente porque basta con que te guste una en concreto para que un cliente utilice la contraria o incluso una que no conozcamos y empiezan los problemas.

    (más…)

  • Nueva distribución con Asterisk basada en Debian

    debpbxFederico Pereira, un lector de Sinologic.net me ha enviado un email para informarme que ha desarrollado una distribución que, a diferencia de la gran mayoría de distribuciones que podemos encontrar, no está basada en CentOS si no en Debian (concretamente en Lenny 5.0):

    • Asterisk v1.4.22
    • Sonido Castellano (De la gente asterio.com.ar)
    • Libpri v1.4.7
    • Asterisk Addons v1.4.7
    • DAHDI v2.1.0.4+2.1.0.2
    • FreePBX v2.5.1
      • Modulos
        • Config Editor v1.0.3
        • PhpMyAdmin v2.11.9.4.1
        • SyS Info v2.5.5
        • Vmail Admin v2.5.7
    • A2billing v1.3.4c

    La idea de que esté basada en Debian me ha gustado (soy un debianero confeso) y busca comentarios y sugerencias para continuar desarrollando esta distribución.

    Como comentario personal y con el fin de que esta distribución le pueda ser interesante a más personas se me ocurren algunas sugerencias como añadir las locuciones de VoIPNovatos, añadir las fuentes del kernel de linux que utilice, así como las herramientas necesarias para poder compilar y así actualizar los paquetes DAHDI, LibPri y Asterisk sin estar atado a una versión en concreto. (posiblemente ya lo traiga incluido :D)

    Puedes probar la distribución descargándotela desde su web:
    http://www.opentecnologic.com/

  • Debian 5.0 Lenny congelada!

    Acabo de leer en Barrapunto, que la versión GNU/Linux Debian 5.0, más conocida como Lenny ha sido congelada por lo que no se admitirán más paquetes y ahora procederán al testeo de cada uno de los paquetes hasta lograr una versión tan estable como viene siendo habitual en Debian.

    Nota oficial: http://lists.debian.org/debian-announce/…/msg007.html

  • Cómo configurar el envío de emails desde Asterisk

    Es una pregunta bastante común y pese a que su respuesta es la misma, voy intentar dejarlo tan claro como sea posible.

    Asterisk es una aplicación, como cualquier otra que corra bajo Linux, y por lo tanto sigue una norma que siguen todas las aplicaciones en Linux: Asterisk NO ENVIA EMAILS, si no que se comunica con el servidor SMTP que tengamos instalado en nuestro sistema local y es este el que envía el email. Incluso si queremos utilizar un servidor remoto con una cuenta, el procedimiento sigue siendo el mismo.

    Por este motivo, y por que todas las aplicaciones en linux funcionan prácticamente igual (apache, pureftpd, syslog, etc…) suelen darle los emails que quieren enviar a una aplicación bastante conocida: SendMail.

    SendMail es un servidor de envío de emails (SMTP) y fue uno de los primeros y más avanzados servidores de este tipo, pero su poca fiabilidad (demasiados bugs para los administradores de redes) unido a su complejidad si queríamos configurar un servidor serio, hizo que apareciesen otros servidores SMTP más ligeros, simples y rápidos que Sendmail.

    No obstante, todos los sistemas continúan intentando enviar emails dejándolos a Sendmail y es por esto por lo que los nuevos y más sencillos servidores SMTP utilizan un truco para hacerse pasar por Sendmail y poder «suplantarlo», esto es, crean un enlace simbólico en el sistema con el nombre «sendmail», de manera que cuando una aplicación intenta acceder a «sendmail», realmente quien contesta es esta aplicación. 🙂

    Como ya he comentado, casi todas las aplicaciones que tienen la necesidad o la opción de enviar emails utilizan el servidor SMTP local, esto ha hecho que muchas distribuciones, para facilitar la configuración y envío de emails, instalen por defecto algunos sustitutos de sendmail como por ejemplo exim o postfix son las más conocidas.

    El principal problema de utilizar el servidor SMTP local es el proveedor: Debido al aumento de correos SPAM, los proveedores y los servidores de correo que van a recepcionar tu email comprobarán si realmente el servidor del que procede el email es realmente un servidor «oficial» o bien un servidor que se dedica a enviar SPAM, y como el servidor local no es realmente un servidor en toda regla (no tiene registros MX en el DNS de algún dominio, tiene una dirección IP dinámica, o ha sido utilizado por otro spamer) es por lo que se aconseja encarecidamente utilizar una cuenta de algún servidor de emails ya verificado y seguro.

    Posiblemente, tras la instalación de nuestra distribución preferida, podremos enviar emails con el comando:

    echo «Prueba de email» |mail -s «Prueba de email» miUsuario@miDominio.com

    Pero cuando hayamos enviado varios de este tipo y empecemos a confiarnos, veremos como nuestro cliente de correo empezará a considerarlo spam, o puede que ni llegue. Es entonces cuando tendremos que configurar nuestro servidor SMTP local para que envíe los emails mediante una cuenta autentificada.

    Para el ejemplo de configuración voy a hacerlo con Exim (el servidor que viene por defecto con Debian), quizá sea uno de los más sencillos de configurar y de manejar, aunque personalmente siempre he preferido Qmail por ser mucho más seguro, no obstante, como nuestro objetivo no es configurar un servidor de correos en toda regla, vamos a hacerlo con Exim (versión 4) que es la que trae Debian (y Ubuntu) de serie.

    Lo primero que tenemos que hacer es asegurarnos que lo tenemos instalado:

    apt-get install exim4 exim4-config

    Una vez que lo hayamos instalado, aparecerá una pantalla de configuración. Si no aparece, podremos acceder a ella en cualquier momento ejecutando el comando:

    dpkg-reconfigure exim4-config

    ¿Sencillo verdad? 🙂

    Será entonces cuando nos pregunte por distintas opciones de configuración:

    – ¿Quiere utilizar archivos separados para la configuración?
    Respondemos SI

    – ¿De qué forma queremos configurar nuestro servidor?
    Respondemos «enviar por SMARTHOST, y recibir por SMTP o Fetchmail»

    – Escriba el nombre del sistema:
    Respondemos con nuestro dominio: miDominio.com

    – Escriba la dirección IP desde donde va a atender las conexiones al SMTP:
    Respondemos: 127.0.0.1

    – Escriba otros servidores destino que el SMTP será aceptado:
    Aquí no respondemos nada, lo dejamos en blanco.

    – Sistemas a los que reenviar emails ?
    No piques, esto también hay que dejarlo en blanco. 😛

    – Escribe el sistema que gestionará el correo saliente de este sistema:
    (Aquí escribimos nuestro servidor SMTP remoto, por ejemplo…)
    smtp.miDominio.com

    Si queremos utilizar una cuenta de gmail, el servidor SMTP de gmail hay que especificarlo junto con el puerto que va a utilizar, y sería esto: smtp.gmail.com::587 (ojo que lleva dos simbolos de dos puntos antes del puerto)

    – ¿Quiere ocultar el nombre local del sistema local del email saliente?
    Pues NO.

    – Quiere cachear las peticiones DNS para ahorrar ancho de banda?
    Pues NO.

    Bien, hasta ahora tenemos algunos parámetros básicos configurados, pero no hemos indicado el usuario ni la contraseña con el que queremos autentificarnos para enviar emails. Si probásemos a enviar emails, seguramente nuestro servidor remoto recibiría un email de un tal root@localhost y nos lo rechazaría. 🙂

    Vamos a configurar los datos importantes:

    1º. – Editamos el archivo /etc/exim4/passwd.client y escribimos algo como esto:

    smtp.miDominio.com:usuario:contraseña

    En el caso de que queramos utilizar la cuenta de email, deberíamos poner algo como esto:

    gmail-smtp.l.google.com:usuario@gmail.com:contraseña
    *.google.com:usuario@gmail.com:contraseña
    smtp.gmail.com:usuario@gmail.com:contraseña

    De esta manera, sea cual sea el nombre del servidor SMTP que utilicemos en gmail, le enviaremos los parámetros correctos y nos aceptará el envío.

    2º.- Protegemos el archivo para que nadie tenga acceso a leer nuestros datos:

    chown root:Debian-exim /etc/exim4/passwd.client

    3º.- Si estamos configurando nuestra cuenta de Gmail, hay que indicarle (otra vez) que el envío debe hacerlo por el puerto 587 en lugar del estandar (el 25), por lo que tendremos que editar el archivo:

    /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost

    y justo encima de la línea que dice algo como: (hosts_try_auth…) añadir lo siguiente:
    port=587

    4º.- Por último, vamos a configurar nuestra identificación saliente:

    echo «root@localhost: usuario@miDominio.com" >> /etc/exim4/email-addresses

    Y listo, lo último que nos queda es recargar la configuración:

    ejecutamos: update-exim4.conf (es un comando 🙂

    Y probamos a enviar un email como hemos hecho antes…

    echo «Prueba de email» |mail -s «Prueba de email» miUsuario@miDominio.com

    y veremos cómo nos llega con el usuario y dominio correcto. 😀

    Bueno, parece más complicado de lo que realmente es. Una vez que se ha configurado unos cuantos sistemas con esta técnica, se hace todo diréctamente y sin tener que recordar los pasitos.

    Una vez tengamos esto hecho y podamos enviar emails con nuestra cuenta oficial, entonces podremos recibir los emails que hayamos configurado en el buzón de voz de Asterisk, o incluso nuestras alertas de arranque de asterisk o incluso enviar faxes mediante Hylafax,…

    Más información:
    http://www.exim.org/
    http://wiki.debian.org/GmailAndExim4
    http://wiki.debian.org/PkgExim4

  • Videoconferencia con Asterisk y 3G

    Asterisk videoNuestro colega Bytecoders nos apunta en un comentario que acaba de traducir un tutorial creado en inglés por Sergio García (de fontventa.com) sobre cómo compilar Asterisk para que tenga soporte de códecs que conecten con la red 3G y permitan la videoconferencia con los móviles de última generación. (bueno, los anteriores al iPhone. 😀)

    Parece que la idea de meter Video en Asterisk lleva bastante tiempo dando guerra, pero parece que este año que entra ahora va a cobrar mucho más protagonismo. Ya escribiré más adelante qué se espera para este nuevo año, de momento vamos a centrarnos.

    En el tutorial se indica que funciona con terminales Nokia N95 y LG.

    Para la instalación utilizan Debian Etch y una Digium B410P.

    Se hace una instalación completa de Asterisk con soporte de mISDN para la tarjeta Digium y luego se procede a compilar el soporte de vídeo:

    – Instalación del H324M y modificaciones para integrarlo con la tarjeta B410P.
    – Instalación del códec AMR.
    – Instalación del gateway H324 (Para recibir y hacer llamadas 3G)
    – Instalación del mpeg4ip
    – Instalación del app_mp4.
    – Instalación del app_rtsp.
    – Instalación del app_transcode.
    – Instalación del pcm2mp4.
    – Ejemplos de uso del dialplan.

    Un tutorial que a más de uno le hará la vida un poco más sencilla. 😛

    Enlace:  http://bytecoders.homelinux.com/…/tutorial-asterisk-…-video-…-3g.html