Hace unos meses, jugando con Kamailio, descubrí que un operador enviaba llamadas con un Call-ID (un campo interno de SIP que sirve para identificar a qué diálogo pertenece ese mensaje) erróneo que incluía comillas («), barras invertidas (\), comillas simples (‘), y arrobas (@) entre otros caracteres, de forma que, en principio todo funciona correctamente hasta que me dio por guardar ese parámetro dentro de una base de datos y descubrí que no se guardaban por ejecutar una cadena SQL incorrecta.
Me costó bastante descubrir el motivo de por qué esas llamadas no se guardaban, pero cuando por fín me di cuenta, aprendí la importancia de «sanitizar» cualquier información con la que vayamos a trabajar ya que, en cualquier momento podemos recibir una cadena malformada adrede para causar quién sabe qué.
Tras pasar todos los parámetros por una función que eliminaba caracteres extraños y verificaba que todo era correcto, empecé a pensar ¿y si un call-id, un dnid, un CallerID o un destino erróneo y malformado como el que yo recibí, apareciera como parámetro de un comando de ejecución? Las consecuencias podrían ser terribles.
Entonces apareció un mensaje en la lista de usuarios de Kamailio que coincidía justamente con lo que estaba evitando y es que un parámetro externo incluido dentro de una función de ejecución puede ser un grave problema de seguridad.
En Asterisk no son pocas las configuraciones que incluyen comandos de este tipo: Ejecuciones al finalizar una conversación para comprimir, mover o copiar la grabación de dicha conversación utilizando el caller id como parámetro, …. ¿y si el callerid fuese una cadena de inyección de código del tipo: «\nrm -rf /\n»? Es cierto que esa cadena nunca sería válida en el RFC y seguro que IEEE aparecería en sueños, pero la jugarreta se la haría bien.
Ya hablamos hace 13 años de cómo programar el dialplan de Asterisk para evitar este tipo de ataques malintencionados utilizando las funciones y aplicaciones de Asterisk en el artículo: Una nueva versión de Asterisk corrige el dialplan injection. En este caso el ataque permitía llamar a cualquier destino aunque el dialplan nos hubiera limitado el número al que llamar.
Hace algunos años, comencé un proyecto llamado SIPCheck que se basaba en un programa que leía el log de Asterisk buscando cadenas de texto que aparecían cuando se recibían intentos de registro y de esta forma, obtener la dirección IP para bloquearlo en el firewall. Esto ya lo hacía Fail2Ban (con muchos más servicios) y más especialmente APIBan, pero incluso en la primera versión de SIPCheck aprendí un error que sigue ocurriendo en todos estos sistemas: Los ataques procedentes de una dirección IP se quedan en el firewall hasta que lo hace prácticamente inmanejable, además de que esa dirección IP (que la pobre sólo tiene culpa de haberle tocado un dueño al que le han metido un gol por la escuadra) pasa a ser etiquetada como hostil e inutilizándola para cualquier uso legal y razonable hasta «el fin de los días» (más o menos lo mismo que comentamos cuando hablamos de los números de teléfono que se usan para campañas de marketing). Dejaré para un futuro artículo las venturas y desventuras de lo aprendido cuando desarrollábamos el nuevo SIPCheck, porque aprendimos muchas y muy interesantes lecciones sobre como pasar de bloquear IPs a cómo evitar ataques, pero esto mejor en otro artículo.
Así que, viendo que alguien hace uso de direcciones IP de sistemas vulnerables para arrancar sus programas de ataque a sistemas VoIP, y que cuando estos dejan de funcionar, cambian de IP y siguen atacando… ¿para qué vamos a estar guardando en el firewall una lista sin fin de direcciones IP?
Primero, el firewall de Linux (IPTables) es de lo mejorcito que hay (razón por la cual, la mayoría de los firewalls comerciales funcionan con Linux/FreeBSD) tiene muy poca carga, es estable como lo que más (filosofía Unix: muchos programas pequeños y cada uno hace su función a la perfección) pero cuenta con un pequeño defecto cuando se almacenan «decenas o cientos de miles» de direcciones IP (lo que ocurre con SIPCheck, Fail2Ban o APIBan): se vuelve lento para aceptar o rechazar peticiones, algo que puede cargar bastante el sistema e incluso provocar problemas en las comunicaciones.
La primera solución era evidente: usar ipset
Qué es ‘ipset’ y cómo funciona
El pequeño ‘ipset‘ es una herramienta fácil y sencilla, complementaria de IPTables que maneja una lista desordenada de direcciones IP como si fuera una única regla del firewall. Esto es (para que lo entendamos mejor), que cuando nuestro sistema recibe un paquete y tiene que comprobar si puede o no dejarlo pasar, recorre TODO el firewall, lo cual, si tenemos 100.000 direcciones IP bloqueadas, por cada paquete que reciba, tendrá que hacer 100.000 comprobaciones antes de dejarlo pasar, una carga bestial para un sistema que maneja miles de paquetes UDP por segundo como es un servidor de comunicaciones VoIP.
Por lo tanto, en lugar de una «lista ordenada» de reglas, ipset sirve para manejar un «conjunto» de IP, de manera que es 10.000 veces más rápido (utiliza una búsqueda hash) que preguntar: -«¿Está esta lista en el conjunto?» y buscar secuencialmente una IP en la lista ordenada, así que no es casualidad que cuando el número de direcciones IP a bloquear sea demasiado grande, es muchísimo mejor utilizar ipset, que IPTables.
Al final ipset debe estar conectado a IPTables para que puedan ser bloqueadas las direcciones IP guardadas en «el conjunto». De manera que cuando un sistema nos envía un paquete, el firewall sigue recorriendo sus líneas, pero una línea en particular dice: «Consulta el conjunto listanegra» y esa línea pregunta al conjunto si está la IP en él. La respuesta de ejecutar esa consulta es tan rápida como una simple línea de IPTables, por lo que la mejora en velocidad es muy interesante.
Gráfica de Netfilter donde observa que a medida que crecen las reglas de IPTables, aumenta el tiempo que lleva procesarlas, mientras que con ipset, se mantiene casi constante.
Cómo evitar los guisantes caídos en el fondo del congelador
Tenemos el problema que comentábamos antes ¿hasta cuando vamos a bloquear una IP que nos atacó? ¿va a estar castigada para siempre? ¿hasta que hagamos un FLUSH y comencemos de nuevo? ¿no hay nada más manejable? La respuesta a esto sigue siendo la misma: ipset.
Además, ipset tiene una funcionalidad muy interesante y es que se pueden poner tiempos de expiración a las reglas (borrarlas automáticamente al cabo de X segundos) por lo que si baneamos una IP, podemos dejar a ipset que la saque de la lista negra al cabo de 30 minutos, 6 horas o 30 días (o por poner una cantidad de tiempo en la que pensamos que no nos volverá a atacar), de esta manera, el número de registros se mantendrá automáticamente controlado y si vuelven a atacarnos, volverán a ser baneados otro buen tiempo.
No queremos direcciones IP permanentemente bloqueadas… al cabo de un tiempo ya no vamos a recibir ataques de ahí pero siempre estará consumiendo ciclos de CPU al comparar cada paquete con esa regla. Vale que con ipset hemos reducido al máximo este consumo, pero aún así, ¿realmente es necesaria una cadena perpetua a una pobre IP por haber sido vulnerable una vez? (no es una pregunta filosófica, moralistani política…)
Los atacantes son inteligentes, no importa si bloqueamos con IPTables, con ipset o con NFTSet, ganan mucho si consiguen lo que quieren, así que nunca hay que subestimarlos: prueban con una IP, que no lo consiguen, prueban con otra y así hasta que se dan por vencidos… luego probarán otras cosas: prueban contraseñas genéricas, contraseñas robadas de otros lugares, combinaciones de valores (por si bloqueásemos el UserAgent, o permitiésemos llamadas con un prefijo «secreto») ya sabéis que «la técnica de ocultación, realmente es una vulnerabilidad retardada en el tiempo«.
Ahora vamos con la práctica
Lo primero que tenemos que hacer es lo mismo que cuando jugamos con un firewall: Jamás hacer pruebas en un sistema en producción, puede parecer evidente, pero os sorprendería la de routers de Facebook que se han quedado aislados por hacer pruebas donde no debían. 😛
Ahora sí, lo primero que tenemos que hacer es instalar ipsetcon nuestro gestor de paquetes: apt install ipset o bien yum install ipset, una vez esté instalado, ya podemos empezar a hacer pruebas:
1.- Creamos un conjunto de IPs al que vamos a llamar: listanegra
# Si queremos crear un conjunto con un timeout máximo de 1 hora
ipset create listanegra hash:ip timeout 3600
# Si no queremos que tenga timeout, basta con no ponérselo.
# ipset create listanegra hash:ip
2.- Una vez creado el «conjunto», podemos ver todos los conjuntos que tenemos:
ipset list
3.- A continuación, enlazamos el conjunto «listanegra» con nuestro iptables:
# Para dar de alta el conjunto 'listanegra' en el iptables:
iptables -I INPUT -m set --match-set listanegra src -j DROP
# Siempre podemos eliminar el conjunto del iptables con:
# iptables -D INPUT -m set --match-set listanegra src -j DROP
4.- Por último, tenemos que añadir las direcciones IP al conjunto mediante el propio comando ipset:
La primera IP será eliminada en 30 segundos, la segunda en 20 y la tercera en 10. Si no se le define un «timeout», utilizará el timeout general que se puso al crear el conjunto: 3600.
5.- Recuerda que para borrar manualmente una IP del conjunto:
ipset del listanegra 248.248.248.247
y de esta manera, hemos visto cómo podemos banear de forma automática a cientos de miles de direcciones IP sin preocuparnos de eliminarlas manualmente.
En nuestro firewall, tan sólo aparecerá una línea indicando que tiene que «dropear» aquellas direcciones del conjunto ‘listanegra’
Cómo hacer persistente la lista negra en caso de reinicio
Si reiniciamos el sistema, todo se borra, así que lo suyo sería almacenarla y restaurarla cuando reiniciemos, así que vamos a modificar el script de ipset de systemd:
# Modifícalo en lo que consideres necesario
[Unit]
Description=ipset persistancy service
DefaultDependencies=no
Requires=netfilter-persistent.service
Requires=ufw.service
Before=network.target
Before=netfilter-persistent.service
Before=ufw.service
ConditionFileNotEmpty=/etc/ipsets.conf
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ipset restore -f -! /etc/ipsets.conf
# save on service stop, system shutdown etc.
ExecStop=/sbin/ipset save listanegra -f /etc/ipsets.conf
[Install]
WantedBy=multi-user.target
RequiredBy=netfilter-persistent.service
RequiredBy=ufw.service
También estaría bien meter la siguiente línea en el crontab para que periódicamente haga una copia de seguridad de las IPs que tenemos baneadas… aunque esto tampoco es tan vital. 🙂
/sbin/ipset save listanegra -f /etc/ipsets.conf
Y con esto, ya nos tocará buscar la forma de añadir de forma automática las direcciones IP al conjunto, bien mediante un sipcheck modificado, bien mediante un script automatizado que busque intentos de registro fallidos, o de alguna otra forma. ¿se te ocurre alguna forma de ejecutar un comando para añadir direcciones IP al conjunto de ipset cuando se recibe un ataque a Asterisk, Kamailio o a otro servicio? Dínoslo en los comentarios, que estamos en las puertas de navidad y puede que si te portas bien, te traigan regalitos muy pronto. 😉
A raíz de una publicación en la página de DefenseOne (una reconocida web sobre seguridad e inteligencia) se denunciaba que los teléfonos Yealink envían periódicamente y de forma continuada paquetes con información cifrada a una dirección IP situada en China, lo que abre la puerta a multitud de preguntas y sospechas como la que ha hecho el CEO de Wildix que ayer publicó en su LinkedIn el siguiente comentario.
Los que hemos trabajado y trabajamos con teléfonos de varios modelos (entre ellos Yealink) y analizamos el tráfico que envían y reciben, podemos confirmar que, efectivamente son muchos los teléfonos que envían (o al menos lo intentan) paquetes cifrados a servidores externos. Es una práctica habitual. Generalmente se le conoce como «telemetría» y lo hacen sistemas hardware como software (no os imagináis la cantidad de paquetes que envían aplicaciones como el editor de código Visual Code Studio a los servidores de Microsoften concepto de «telemetría«), pero esta práctica, en ciertos ámbitos y sin transparencia puede suponer un gran riesgo.
Quizá al dueño de una empresa de zapatos no le importe que el gobierno chino analice las horas a las que hace llamadas, los números a los que llama, el tiempo que ha estado hablando… pero si nos paramos a pensar en que China es uno de los principales líderes (por no decir el primero) en cuanto a Big Data e Inteligencia Artificial, esa información de la empresa de zapatos, puede ser bastante valiosa a la vez que peligrosa.
Ya no es únicamente una puerta de atrás
Ya no estamos hablando de que los sistemas traigan una puerta trasera que permita a alguien acceder al equipo y ejecutar código en nuestra red. El comentario del CEO de Wildix directamente sospecha que se envían conversaciones enteras activando el micrófono de la función de manos libres del teléfono.
En un VoIP2DAY, nuestro amigo Pepelux ya nos enseñó que tras un firmware cifrado se puede esconder cualquier cosa, y que instalado en un sistema, se puede considerar como un caballo de Troya en la que un atacante informado podría acceder a nuestra red y espiar la información que por ella viaja.
Ahora imagina que, además, tenemos varios dispositivos con procesadores potentes de gestión de audio capaces de comprimir en tiempo real información y de acceder a Internet con sistemas remotos, acceder a la VPN de la empresa, y muchas cosas más… solo pensar en lo que podrían hacer.
La confianza la da el software libre
Ya puestos a pensar, lo suyo sería hacer como Android en sus buenos tiempos, en los que el código fuente estaba ahí disponible y cualquiera con conocimientos podía analizarlo y ver qué hacía, compilarlo e instalarlo en el teléfono.
Hoy día, con tantas empresas apoyadas por gobiernos de países, uno ya no puede más que confiar en que nadie va a hacer lo que no debe, pero sabiendo que la información no solo es poder si no que también genera dinero, cada vez vamos a encontrar más y más empresas que van a ser sospechosas de espionaje, vulnerabilidades involuntarias o voluntarias y otros fallos de seguridad.
A propósito… el artículo salió publicado el pasado día 7 de enero y Yealink aún no ha hecho comentarios.
Según un enlace que nos pasa nuestro amigo @as_informatico, se han encontrado un acceso directo oculto en las centrales VoIP de la empresa alemana Auerswald.
Concretamente, el grupo de hackers RedTeam comenta en su artículo: «Two backdoor passwords were found in the firmware of the COMpact 5500R PBX» y tal y como se puede ver cómo han logrado dar con este backdoor, deja en muy mal lugar a esta empresa por tener tal acceso oculto a sus usuarios. https://blog.redteam-pentesting.de/2021/inside-a-pbx/
Análisis del firmware donde se puede ver el acceso oculto al sistema
Parece que el fabricante se hizo con un método para poder acceder al sistema en el caso en que el usuario perdiera el acceso de administrador y de esta forma evitar un reset a valores de fábrica que restableciera los valores por defectos definidos en el firmware, pero esto en sí ya es un grave fallo de seguridad.
Hace unos años dí una conferencia en el VoIP2DAY sobre el uso de la Inteligencia Artificial en el campo de la VoIP en el que hablaba que existen bancos (HSBC por poner un ejemplo) que comprueba durante una llamada, si la persona con la que hablamos es realmente quien dice ser, aprovechando un análisis de la voz telefónica (Voice ID Fingerprinting).
Esto hoy día ya no es una aplicación válida, ya que alguien le ha dado dos vueltas de tuerca a esto de la Inteligencia Artificial y ha conseguido que, aprovechando una conversación telefónica de 5 segundos, poder generar casi en tiempo real un modificador de audio para cambiar la voz de un TTS de forma que tenga exáctamente el mismo tono y el mismo timbre de voz que en la grabación de 5 segundos. Esto es, cualquiera con esa aplicación podría generar una conversación con nuestra voz y confundir y poder hacerse pasar por una persona.
Hay soluciones comerciales que ya hacen esto y que nos permite generar locuciones con la voz que queramos (incluso con una propia) por lo que si necesitamos generar nuevas locuciones para nuestro sistema, aquí tendríamos todo lo necesario.
No obstante, la aplicación «Real Time Voice Cloning» junto con toda la documentación de la tesis está disponible desde la página web del proyecto: https://github.com/CorentinJ/Real-Time-Voice-Cloning y un vídeo demostrativo de cómo funciona.
Así que, si tenéis un rato aburrido, os recomiendo que lo probéis porque es una herramienta tan útil como curiosa para frikear un buen rato.
Pues bien, la CIA acaba de anunciar que a partir de este verano, apagará las últimas máquinas de faxes que tenían y que utilizaban para comunicarse con sus contratistas privados.
Los más de 100 proveedores que tiene la CIA ya se han apuntado a enviar sus documentos, propuestas y ofertas a través del nuevo sistema seguro de correo electrónico, un sistema cada vez más en auge debido a las grandes amenazas que tienen todos los organismos públicos y grandes empresas.
Aclaración: Es importante destacar que (tal y como me ha parecido entender por varios mensajes de varios lectores) el protocolo FAX no deja de utilizarse de un día para otro, lo que se abandona es el hecho de enviar 0’s y 1’s a través de las líneas PSTN. Temporalmente, se utilizaría el protocolo de FAX vía T.38 (mediante VoIP) para poder recibir faxes vía VoIP y que la PBX se encargue automáticamente de digitalizar y enviarlo por email o guardarlo en un formato compatible. En el caso de la CIA, ni siquiera se utilizará Fax over IP, directamente se pasará a un sistema de email seguro propio para comunicaciones internas.
Pese a que ya se empiezan a realizar algunos eventos profesionales muy concretos y muy puntuales, guardando las distancias, con medidas y todas las precauciones del mundo para evitar contagios y brotes por seguridad y responsabilidad, llevamos más de un año celebrando eventos virtuales.
También acabamos de recibir la invitación para finales de octubre de un evento híbrido: la ClueCon 2021, que se celebrará del 25 al 29 de octubre, simultáneamente en el InterContinental Hotel Chicago y On-Line y que ya está todo disponible para registrarse.
A falta de eventos, nuestros amigos de InstantByte han decidido dedicar el mes de Abril al tema de la videovigilancia bajo el lema: En abril, ojos mil. con charlas, webinars, talleres y ofertas semanales para ayudar a implantar este tipo de soluciones.
El calendario de los talleres y sus webinars son:
9 de Abril a las 10:00 : Primeros pasos para un proyecto de videovigilancia Webinar sobre cómo afrontar desde 0 un proyecto de videovigilancia. (registro)
15 de Abril a las 10:00 : Webinar sobre como debería ser servicio de videovigilancia para particulares y comercios que incluye la cámara y los planes de almacenamiento. (registro)
16 de Abril a las 10:00 : Configuración de las distintas soluciones de videovigilancia Webinar/taller sobre cómo configurar las cámaras: Hikvision, Dahua, Unividew y Hilook (registro)
23 de Abril a las 10:00 : Funciones de Inteligencia Artificial en los sistemas de videovigilancia. En este webinar veremos diferentes soluciones de videovigilancia con sistemas de Inteligencia Artificial: Reconocimiento facial, Lector de matrículas, Imágenes térmicas y Detección de movimiento. (registro)
29 de Abril a las 10:00 : Soluciones de Videovigilancia para un hogar inteligente de Ezviz Webinar, impartido por María Simón, donde se verán qué soluciones de videovigilancia se pueden introducir en un hogar inteligente de la marca Ezviz, desde cámaras WiFi con audio bidireccional, hasta purificadores de aire, pasando por mirillas inteligentes y videoporteros. (registro)
30 de Abril a las 10:00 : Control de Acceso y Presencia: Puesta en marcha y configuración Cómo poner en marcha diferentes dispositivos de control de acceso y presencia, además de la configuración de los mismos en base a los requerimientos de cada empresa: Hikvision y Dahua (registro)
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:
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 bieno 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.
Hace algún tiempo avisamos que Sinologic no publicaría noticias relacionadas con seguridad. Principalmente porque uno debe ser responsable de estar al día de todo lo que surge en cuanto a vulnerabilidades, fallos de seguridad, etc. Por este motivo, todos deberíamos tener en nuestras pantallas un sistema tipo «telex» que nos informe en tiempo real de los problemas que ocurren.
No obstante, y por diversos motivos y proyectos personales, estoy un poco más en el día a día de ciertos temas relacionados con la seguridad, el fraude telefónico y cómo evitarlos, por lo que acabo de ver una vulnerabilidad que merece la pena comentar aquí:
Una vulnerabilidad de PJSIP en un paquete INVITE malintencionado podría provocar un crash de Asterisk.
Este bug ha sido resuelto en las versiones: 13.37.1, 16.14.1, 17.8.1, y 18.0.1
Así que si tenéis una versión anterior y utilizáis PJSIP como el 33% de los usuarios encuestados de Sinologic, os recomendamos actualizar a la siguiente versión cuanto antes.
Siempre he dicho que «no es paranoia si de verdad te persiguen«, esa frase no es mía, a principios de los 90 ya aparecía en «Paranoia«, un juego de rol sobre un tema que, si bien podría ser un futuro distópico, cada día es más real:
El juego se ambienta en el Complejo Alfa, una inmensa ciudad subterránea controlada por El Ordenador, un sistema de inteligencia artificial esquizofrénico, que fue programado para procurar la felicidad de sus habitantes, felicidad que es obligatoria. Sus protocolos de acción incluye la ejecución sumaria ante cualquier indicio de anormalidad en su sociedad «perfecta». El problema es que todos los ciudadanos tienen, por lo menos, dos motivos de traición: pertenecer a una sociedad secreta y tener un poder mutante. Además, el mismo ordenador da órdenes contradictorias que en caso de no ser cumplidas en su totalidad (lo que muchas veces resulta imposible), también son motivo de traición.
Hoy día todos tenemos, al menos, un motivo para evitar que nos espíen, todas rozan la paranoia, aunque casos como el de Edward Snowden demuestran que el espionaje masivo existe y es efectivo aunque nos parezca ciencia ficción y conspiraciones varias. Muchos conocen SITEL y se echan las manos a la cabeza, aunque este sistema entra dentro de la legalidad y requiere que un judicial lo avale para llevarlo a cabo, poco se sabe de otros proyectos 2000 veces más grandes y sujeto a menos controles como ECHELON o PRISM que, además de ser indiscriminados y automatizados, incluyen llamadas, emails, y cualquier tipo de comunicación que se os ocurra.
Esto es sólo el «espionaje gubernamental»… luego tenemos el «espionaje empresarial» que, aunque no lo parezca, es mucho peor.
Uno puede pensar que, mientras uno no haga nada ilegal o sospechoso, no tiene que preocuparse… que la seguridad es lo primordial y que si nos espían es para velar por nosotros…. que nadie va a leer o escuchar nuestra comunicaciones mientras preguntamos por cómo se encuentra un familiar porque ¿a quién le interesa?, pero la verdad es que, aunque no te lo creas, les interesa a todos…
Por esta razón, en el mundo de la informática nos toca ponernos las pilas en cuanto a la seguridad y evitar que una comunicación pueda ser interceptada, grabada, transcrita, analizada y procesada por algoritmos con, a saber qué fin, y por esta razón aparecen las necesidades de que TODA, absolutamente TODA comunicación de datos, esté cifrada y sea difícil o imposible obtenerla.
Protocolo SIGNAL
Ese es justamente el objetivo del «Protocolo Signal«, un protocolo de mensajería aunque utilizado por muchos otros sistemas de comunicaciones (voz, vídeo, transmisión de archivos, etc.), que consiste en el cifrado punto a punto entre dos personas que hablan entre sí evitando que un tercero pueda obtener el contenido de la comunicación.
Este protocolo Signal viene a implementar el conocido end-to-end encryption que ahora está tan de moda en todas las aplicaciones de mensajería, y que todas ellas se han basado en el mismo protocolo Signal, aunque luego cada una ha hecho su propia implementación. Nota: Telegram utiliza otro protocolo similar aunque diferente llamado MTProto.
Otro apunte interesante, que si bien podría ser una estrategia publicitaria podría ser cierta y le daría más importancia a este método de cifrado es el hecho de que el gobierno de los EEUU no ha podido descifrar los mensajes y piden «ayuda», por lo que la empresa detrás de este protocolo está pensando en no ofrecer este servicio en EEUU por las presiones que está recibiendo.
Este protocolo E2EE (end-to-end encryption) garantizaría la privacidad necesaria para mantener una conversación fuera de las miradas externas incluso aunque llegasen a entrar en la conversación.
Un buen ejemplo de esto lo hemos visto en un vídeo de Jitsi en el que prueban la multi-videoconferencia con E2EE:
Es un paso adelante, quizá (como decía al comienzo del artículo) algo triste el hecho de tener que andar con cifrados y complicándolo todo para tener una mínima privacidad en nuestras conversaciones.
No obstante, aunque seamos muy amigos de la privacidad hay algo inmutable: lo privado solo puede serlo mientras no salgamos fuera.
Qué no es E2EE
Y es que actualmente, toda integración se tiene que hacer sin cifrar, por lo que, al final siempre hay un punto de inseguridad que tenemos que ser conscientes que existe (si, un poco paranoicos siempre somos).
Por ejemplo: Si una centralita VoIP en la que se cifra todo el tráfico SIP y todo el audio RTP para que puedan hablar entre ellos de forma segura, tienen que entender que su comunicación irá cifrada y seguramente su conversación será plenamente privada.
No obstante, si se hace una llamada al exterior, hay un momento que el audio cifrado desaparece y pasa a estar cifrado únicamente hasta el servidor, por lo que a partir de ahí, TODO irá en abierto, ya que la PSTN no va cifrada (ya sea móvil o fijo).
Si tengo dos protocolos diferentes cifrados y necesito conectarlos para que se comuniquen entre ellos, en el lugar donde se comunican ambos protocolos, ahí tocará descifrar para poder pasar de un protocolo al otro. Esto NO es E2EE (end-to-end encryption) y es justamente lo que ocurre con muchos servicios que se ofrecen hoy día… que sí ofrecen comunicaciones cifradas, pero no pueden ofrecerla de usuario a usuario ya que utilizan diferentes protocolos.
Seguramente en un futuro sí se puede ofrecer un cifrado más completo, más compatible y más seguro, pero de momento, si necesitamos un cifrado que nos garantice cierta privacidad, sólo podemos contentarnos con hablar en el mismo servicio, ya sea Signal, Whatsapp, Telegram, Jitsi, etc… que nuestro interlocutor.
¿Cómo se puede usar E2EE en VoIP?
En VoIP sí es posible ofrecer E2EE, sólo que hay que usar un sistema algo antiguo y poco extendido: ZRTP (Zimmermann Real-time Transport Protocol -del creador de PGP-) y que requiere de un cliente especial que sea capaz de utilizar este sistema RTP.
Por supuesto, el hecho de usar ZRTP no es algo habitual y tampoco cómodo de cara a una empresa que quiera algo de seguridad, para eso siempre está el SIP bajo TLS y SRTP, esto debería ser un MUST en un entorno de información muy confidencial o con ciertos riesgos de robo de información… no obstante, lo bueno es que está ahí, es software libre, gratis y se puede utilizar si hace falta.
No obstante, lo llamativo de todo esto es el hecho de que un protocolo como Signal pueda ser utilizado por muchas otras empresas de mensajería para ofrecer algo que ninguna de ellas ofrecía por sí sola y es una mínima seguridad, algo que posiblemente en un futuro sea obligatorio que todos los servicios implementen y más sabiendo lo que sabemos hoy día, pero de momento ya nos sentimos algo más seguros sabiendo que nuestros mensajes con gifs de gatitos no serán leídos por empresas y organismos que quieren hacer un perfil en función de las palabras y comentarios que hagamos. Algo es algo.
