Un hacker traza un meticuloso plan durante largos 2 años para intentar colar un acceso a casi todos los sistemas Linux del mundo. Esto lo hizo modificando poco a poco líneas de código a la librería «libzlma» que sirve (entre otras cosas) para comprimir los datos que se envían en protocolos binarios como el del SSH lo que le permitiría crear un exploit y acceder a prácticamente cualquier servidor SSH de cualquier sistema que utilice dicha librería.
La modificación fue detectada por un desarrollador experto en seguridad que detectó que el acceso a una de sus sistemas tardaba 0,5 segundos más de lo habitual, empezó a enfadarse y a investigar el motivo y, (ventajas del software libre) pudo ver el código fuente y se dio cuenta que había un error en una librería llamada libzlma que tenía un backdoor que nadie había detectado antes.
Y es que, viendo quién subió ese código, parece ser que un hacker ha estado enviando modificaciones del código cada cierto tiempo a la librería (junto con modificaciones de otros archivos, manuales, etc.) hasta llegar a un momento en que la suma de todo su código era el propio backdoor.
¿Por qué no se detectó antes?
Este software cuenta con sistemas que detectan código erróneo (maligno, malificiente, malvado, …) pero el desarrollador puso un «punto» en un momento del código que provocaba un error en el sistema de testing del código y eso hacía que dejara de comprobar el resto del código donde se encontraba el código con la puerta trasera.
La detección de este bug ha provocado que hayan muchas versiones de SSH vulnerables, por lo que este fin de semana ha sido un momento ideal para comprobar las versiones de la librería y ver si utilizaban la versión vulnerable.
Cómo detectar si estamos comprometidos
Para comprobar si estamos usando la versión «peligrosa», podemos ejecutar en Linux el siguiente código:
strings `which xz` | grep "(XZ Utils)"
Si la versión que te devuelve es inferior a 5.6.0, entonces tienes una versión segura. En caso contrario, habría que hacer un downgrade o, mejor aun, bloquear el SSH para evitar el acceso externo y permitir conectar por SSH únicamente mediante VPN (que sería lo mejor)
Las versiones comprometidas son la 5.6.0 y 5.6.1
Si utilizas una distribución basada en .deb o .rpm con glibc y xz-5.6.0 o xz-5.6.1:
Si utilizas systemd con un ssh públicamente accesible: ACTUALIZA AHORA MISMO!!!
Si no usas systemd con un ssh públicamente accesible: ACTUALIZA AHORA MISMO
Si utilizas otro tipo de distribución:
Con glibc y xz-5.6.0 o xz-5.6.1: ACTUALIZA AHORA MISMO
Desde siempre, un servidor Linux bien configurado necesita de un servidor de correos configurado de una forma muy particular para conseguir que las notificaciones de los servicios que corren, puedan enviarnos avisos y notificaciones. Un ejemplo de ello ha sido el uso del VoiceMail de Asterisk que nos envía un email cuando alguien nos deja un mensaje en el buzón de voz.
Hace ya algunos años explicamos en Sinologic cómo configurar el envío de email para que Asterisk nos pueda enviar mensajes y para ello utilizábamos uno de los MTA (Mail Transport Agent) más utilizados llamado Exim. No obstante, tanto si utilizas Exim, como Postfix, como SendMail, estás configurando un servidor íntegro de envío de emails, el mismo servidor que podría utilizar una empresa para todos sus empleados o para sus usuarios. Claro que nuestro servidor no necesita configurar permisos, cuentas de usuario, sistemas de antispam, antivirus, direcciones IP de reenvío de emails, etc, ya que lo único que queremos es que utilice una cuenta de otro servidor de email para enviar las notificaciones.
SSMTP, una aplicación para simplificar el envío de emails
Para eso justamente existe un servicio desde hace bastante tiempo llamado SSMTP (https://github.com/badoo/ssmtp) instalable desde paquetes propios de la distribución…
Así, en Debian/Ubuntu instalaríamos el paquete ssmtp con el siguiente comando:
sudo apt-get install ssmtp mailutils
La configuración de esta forma de configurar el envío de email es 1000 veces más sencilla que utilizando Exim, Sendmail, Postfix o similares… tremendamente sencilla y permite configurar una cuenta de email para que todas las notificaciones que envíe nuestro sistema Linux, se envíen utilizando dicha cuenta.
Qué necesitamos para enviar emails
Para configurar el envío de email en nuestro servidor Linux, debemos tener una cuenta de email válida y que funcione para envío de mensajes:
Servidor SMTP: smtp.miservidor.com
Puerto SMTP: 587
Usuario: superchuloemail@miservidor.com
Contraseña: $uperContraseña999
Una vez tengamos estos datos y hayamos comprobado que podemos enviar emails desde un cliente normal y corriente de envío de email, tan solo nos queda configurar la aplicación:
Cómo configurar el envío de email con SSMTP
La aplicación SSMTP tiene dos archivos de configuración muy sencillos:
El archivo revaliases nos sirve para definir qué cuenta debemos usar si un usuario del sistema envía un email. Generalmente los servicios suelen enviar email como ‘root‘, así que el archivo sería algo así:
# sSMTP aliases
#
# Format: local_account:outgoing_address:mailhub
#
# Example: root:your_login@your.domain:mailhub.your.domain[:port]
# where [:port] is an optional port number that defaults to 25.
root:superchuloemail@miservidor.com:smtp.miservidor.com:587
Y otro archivo ssmtp.conf que nos permitirá configurar los datos del servidor que queremos utilizar para enviar los mensajes de email:
#
# Config file for sSMTP sendmail
#
# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
root=superchuloemail@miservidor.com# The place where the mail goes. The actual machine name is required no
# MX records are consulted. Commonly mailhosts are named mail.domain.com
mailhub=smtp.miservidor.com# Where will the mail seem to come from?
#rewriteDomain=
# The full hostname
hostname=mi.servidor.com
# Are users allowed to set their own From: address?
# YES - Allow the user to specify their own From: address
# NO - Use the system generated From: address
FromLineOverride=YES
AuthUser=superchuloemail@miservidor.com
AuthPass=$uperContraseña999
UseTLS=YES
UseSTARTTLS=YES
Con estos dos archivos, ya podemos hacer una prueba de envío de email con un comando básico de consola:
Comprobar que podemos enviar email desde el servidor
echo "Mensaje" | mail -s "Asunto" micorreopersonal@midominio.com
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. 😉
Siempre he considerado a Google como una empresa muy innovadora que hace cosas que nadie ha hecho antes y que además, lo hace cuidando mucho los detalles hasta el punto que cualquier imitación lo tenga realmente difícil para llegar a este nivel. No hay que decir que admiro bastante como trabajan y desde hace muchos años, la filosofía que seguían. Con el tiempo las cosas cambian y lo que antes era «defendemos el software libre«, pasó a ser «te ofrecemos acceso a una API que puedes usar cuando quieras» y posteriormente «si quieres usar la API, debes pagar por usarla«. Es normal, una empresa necesita tener beneficios para crecer y Google no es una excepción. Nadie vive permanentemente de poner banners en cientos de millones de webs.
Google ofreció su servicio Google Suite, un Gmail especial para que cualquier usuario pudiera utilizar su propio dominio con él, así cualquiera que registrase un dominio pudiera tener su cuenta de correos, y algunos servicios muy interesantes como un procesador de textos muy chulo, una hoja de cálculos e incluso un sistema de presentaciones y de dibujo, todo colaborativo y bajo tu propio dominio… todo ventajas.
A partir del 1 de Julio, Google Suite (el servicio que Google ofrecía a dominios personales) se cambia a Google WorkSpace y dejará de ser gratuito, por lo que pasará a costar como mínimo $6 por usuario al mes. (Al igual que Microsoft, una vez nos acostumbramos a pagar suscripciones, ya no parece tan malo pagar mensualmente por tener un email con nuestro dominio). Pero para los que tenemos varios dominios para ciertos proyectos y dos o tres cuentas en cada uno de ellos se traduce en… varios cientos de euros al año que no compensa para el uso que le doy. <snif!> por lo que aprovechando que ya contamos con infraestructura propia, toca buscar alternativas que permitan tener nuestro propio dominio y tantos correos electrónicos como necesitemos. Para ello, vamos a necesitar de un servidor donde montar el servidor de email, y a ser posible con algo de espacio para que los emails y sus adjuntos no acabe con el espacio disponible.
En Linux existe la máxima de «es preferible pequeños programas que funcionen muy bien antes que uno grande que pueda fallar en algún punto«, así que la mayoría de las soluciones de correo se basan en software muy especializado y estable, y la única variación es la configuración de este software para conectarlo entre sí: Postfix para el envío de email (SMTP), Dovecot como almacenamiento del correo (POP3 / IMAP), SpamAssassin como sistema antispam que autoaprende, ClamAV como sistema antivirus, y Amavis como gestor de filtros (que conecta SpamAssassin, ClamAV, y otras aplicaciones) para los emails. En ocasiones hay algún sistema que utiliza Exim como sistema MTA (SMTP) aunque es bien raro esto.
Llevo algún tiempo buscando sistemas de gestión de correos para aprovechar que dispongo de un servidor propio y muchas cuentas. Aunque seguiré utilizando la versión de Google WorkSpace en algunos correos, en otros he hecho la migración a este nuevo sistema que, aunque no tiene todas la ventajas, con software libre se puede llegar muy, muy cerca e incluso mejor aún, ya que se puede controlar más además de, lo más importante: no depender de una empresa y sus condiciones que cambian y cambiarán con el tiempo.
Vamos a ver algunos sistemas interesantes que podemos montar:
Zimbra
Zimbra está muy orientado a las comunicaciones de la empresa. Uno de los más potentes sistemas de mensajería colaborativa empresarial que cuenta con una versión libre. Ofrece servidor de email, chat, videoconferencia, calendario corporativo, gestor de contactos, tareas, documentos, compartición de archivos, y almacenamiento personal para cada usuario.
Ideal para empresas que necesitan un sistema de mensajería unificado y seguro.
Modoboa es un servidor de correo multidominio, multiusuario, antivirus, antispam, etc… fácil de instalar y que dispone de un interfaz web para facilitar su gestión. Fácil de instalar y realmente útil para los que tienen muchos dominios y necesitan gestionar muchas cuentas. (esto es ideal para lo que estamos hablando). Lo he estado usando un tiempo y puedo decir que es uno de mis preferidos.
El interfaz está programado en Django y es un frontend de postfix, dovecot, amavisd, spamassassin, y una gran colección de herramientas típicas que funcionan a la perfección.
Mail-in-a-Box es uno de los preferidos de muchos administradores de sistemas, es otro sistema de gestión multidominio, multiusuario, antivirus, antispam, etc. con un fácil sistema de instalación en prácticamente un único comando y además incluye algunas herramientas como NextCloud (para el almacenamiento personal de archivos) y Roundcube (webmail)
iRedMail es otro sistema que te permite gestionar dominios de correos, así como usuarios y que cuenta con un interfaz muy atractivo. La única «pega» es que el interfaz está muy limitado y, aunque cuenta con un interfaz muy completo, el precio de la versión «Pro» del interfaz es de 500€/año un poco excesivo en mi opinión. La ventaja es que está todo listo para hacer muchas cosas a mano (listas de correo, desvíos, etc.) Otra opción muy recomendable.
Flurdy es un sistema multidominio, multiusuario, con todo lo necesario para montar un servidor de correos todoterreno (antispam, antivirus, webmail, etc.) y lo más curioso es que es tipo «qmailrocks» (si llevas tiempo con Linux, seguro que te suena esto) es decir: un tutorial paso a paso para instalarlo todo comando a comando y terminar con el sistema perfectamente instalado, configurado y listo para funcionar.
MailU es otra alternativa dockerizada y muy potente multidominio y multiusuario, que puede correr incluso en una raspberry PI. Tiene su propia interfaz de administración bastante completa y cuenta con webmail.
MailCOW es otra solución hospedada de email que cuenta con facilidad de montaje vía Docker y que permite manejar y gestionar cuentas de usuarios de diferentes dominios además de contar con un interfaz muy intuitivo y fácil de manejar.
Quizá uno de los más interesantes sistemas de email, orientado a grandes cantidades de emails y cuentas, así como especialmente orientado a seguridad y cifrado. Almacena los emails cifrados en bases de datos de forma que sea fácil y rápido hacer búsquedas. También cuenta con varios sistemas que mejoran la seguridad como el soporte de autentificación en dos pasos vía app, o incluso Yubikey.
Todos estos sistemas los he probado y puedo decir que todos funcionan bastante bien (aquellos muy inestables o que no me daban seguridad, ni siquiera lo he puesto aquí). También hay que decir que no están todos los que están, así que si conocéis alguna solución libre (no tiene que ser gratuita) que no esté aquí, os agradeceré que me aviséis para que lo incluya.
También he probado otros que tienen muy buena pinta y que se instalan con un único comando ya que se instalan en un contenedor Docker, pero estos tienen varios puntos que no me terminan de convencer y es que no dejan de ser bastante «caja negra», además de no ser software libre, por esa razón, no la vamos a ver aquí.
Vamos a ver 4 herramientas básicas que todo administrador de sistema seguramente ya conoce, pero que nunca están de más repasarlas y si da la casualidad que no conoces alguna de ellas, pues mejor que las vayas conociendo.
Todas las herramientas suelen venir con tu distribución Linux, pero en algún caso es mejor incluso descargar el código fuente e instalarla a mano compilando para aprovechar las novedades de las últimas versiones.
iotop
iotop nos muestra el uso del disco duro de cada proceso del sistema.
IOTOP es una herramienta que nos permitirá saber en tiempo real y en modo texto, qué procesos del sistema leen y escriben del disco duro, así como el ancho de banda que utilizan (cuandos bytes/segundo escriben en el disco duro) y de esta manera, saber si un proceso está haciendo un uso demasiado alto que igual podríamos reducir con un ramdisk o algo similar.
Nethogs nos muestra el uso del ancho de banda de cada uno de los procesos del sistema.
NETHOGS es otra de las herramientas ultrabásicas que nos permite saber en tiempo real y en modo texto qué procesos del sistema están enviando o recibiendo datos de la red, a qué velocidad y de esta manera tener una estimación de los recursos que necesitan. Esta herramienta es verdaderamente útil cuando queremos saber cuanto ancho de banda necesitamos en nuestro Asterisk cuando lleva una cantidad determinada de llamadas, ya que podemos ver exactamente el ancho de banda del proceso Asterisk y no el de todo el sistema.
Nota importante: aunque las distribuciones suelen traer esta herramienta, si queremos monitorizar el tráfico UDP, es necesario descargarnos el código fuente y compilar. Son dos archivos, por lo que la compilación es muy sencilla, pero esta última actualización es vital para los que trabajamos en VoIP.
perf nos mostrará un ‘top’ con el proceso pero de las funciones internas de cada proceso.
PERF es otro de los grandes descubrimientos en herramientas básicas (No confundir con ‘iperf‘ que es para monitorizar ancho de banda), ya que si bien herramientas como ‘top’, ‘htop’, y otras de este tipo, muestran la utilización del procesador y memoria de los procesos del sistema, ‘perf’ profundiza un poco más y muestra el uso de procesador y memoria de las funciones internas de cada proceso (incluido los del kernel de Linux) por lo que es especialmente útil si alguna aplicación está consumiendo demasiado procesador, podremos ver el nombre de las funciones internas que realmente están consumiendo esa cantidad de procesador y así investigar más al investigar qué hace dicha función
perf también permite capturar el consumo de procesador y memoria y guardarlo en un archivo para posteriormente utilizarlo para sacar gráficas de rendimiento, muy útil cuando estamos programando algo y queremos hacer una refactorización de partes del código.
sngrep nos mostrará todo el tráfico SIP de una forma fácil y eficiente para entender qué ocurre.
SNGREP es la última de las herramientas de las que hablaremos hoy, aunque es una gran conocida por los lectores de Sinologic, marcó un antes y un después en todo lo que significa monitorizar el flujo de tráfico SIP de un sistema de comunicaciones. Antes, si bien utilizábamos herramientas como ngrep o tcpdump o un simple «sip set debug on«, también había quien usaba Wireshark… pero desde la aparición de sngrep, monitorizar el tráfico SIP ha pasado a ser algo muchísimo más atractivo, eficiente y práctico.
Todos somos humanos y aunque muchas veces pongamos todos los medios posibles para evitar que nos ataquen, nos infecte un virus, un troyano o se nos caiga un sistema, es inevitable que en un plazo de tiempo indefinido, habrá un momento en que alguien cometerá un fallo y tendremos un sistema vulnerable.
El problema viene cuando ese sistema vulnerable infecta al resto de sistemas que tiene a su alrededor conectados a la red. Esto fue lo que ocurrió al sistema informático del Ayuntamiento de Jeréz en el que un ransomware (un virus que cifra todo el contenido de los discos duros de los sistemas infectados y que se propaga por la red interna de las empresas) ha sido el causante de que todos los ordenadores y servidores de este consistorio hayan sido cifrados y obligados a pagar si quieren recuperar los datos (lo que nunca es seguro que pueda hacerse).
Curiosamente como en los tebeos de Uderzo se menciona…
«…¿Todos? ¡No! Un servidor, poblado por un irreductible Linux resiste todavía y siempre al invasor…»
Extracto modificado del comienzo de los tebeos de «Astérix el Galo».
Y es que parece que el único sistema que no ha sido vulnerable al ataque del ransomware ha sido el servidor Asterisk que controla las comunicaciones de este ayuntamiento.
Así que otra prueba más (por si hiciera falta más pruebas) que un servidor Linux y un buen Asterisk, bien controlado y bien configurado es mucho más seguro que muchas otras alternativas que hay por ahí.
Os lo garantizo. 😉
P.D. Jamás confundiría el nombre ‘Asterisk‘ con ‘Astérix‘, pero según he leído en esta página sobre el significado de Astérix: «Su nombre proviene de la palabra ‘asterisco’ (‘asterisque’ en francés). Sin embargo, otras teorías dicen que proviene del griego ‘Aster’ (estrella) y del celta ‘Rix’ (rey)» así que el juego de palabras entre uno y otro nombre siempre ha estado muy relacionado desde hace muchos, muchos años. 😛
Puede parecer un poco extraño que, ahora que está a punto de salir la versión de Asterisk 16, aún haya quien anuncie el salto a Asterisk 13, pero hay que recordar que tanto Asterisk 14 como Asterisk 15 son versiones orientadas a desarrollo y no son LTS, por lo que desde que Asterisk 13 salió (hace ya 4 años) aún hay muchas personas que siguen trabajando con Asterisk 11 como una de las versiones más estables que hemos tenido y por lo tanto ¿para qué cambiar?.
Sobre las ventajas que ofrece Asterisk 13 ya hemos hablado largo y tendido, no hay más que ver una de tantas presentaciones que se hicieron en su día, pero hoy día nos seguimos preguntando. ¿hay alguien que siga en Asterisk 11?
Issabel acaba de anunciar que su nueva ISO acaba de actualizarse a Asterisk 13, entre otros motivos por el soporte de ARI (Asterisk Restful Interface) pero sobre todo porque al actualizar el sistema operativo, es necesario también actualizar de Asterisk (Asterisk 11 no compila en versiones antiguas de ciertas distribuciones Linux) por lo que si, además de necesitar actualizar, el sistema nos lo pide, tenemos en bandeja una excusa de oro para actualizar la versión de Asterisk.
También es noticia que acaban de publicar la RC2 de Asterisk 16, la siguiente versión LTS que está a punto de salir (y que imaginamos saldrá a la luz justo antes de la Astricon que tendrá lugar del 9 al 11 de Octubre), por lo que tendremos nueva versión estable dentro de muy, muy poco. 🙂
Sea como fuere, tenemos muchas ganas de probar la nueva versión y ver qué cosas nuevas trae, después de dos versiones de desarrollo nos imaginamos que vendrá cargadita de novedades, pero habrá que analizarla muy seriamente. Pero de momento, si trabajas con Issabel, yo iría actualizando ya la versión a la última, que también tiene una pinta bastante buena y cargadita de novedades! 😀
Aunque 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?
En muchas ocasiones nos encontramos que nuestro servidor necesita enviarnos un mensaje, una notificación, algo… y pese a que no soy muy amigo de que un servidor envíe un email para ese tipo de notificación, es cierto que es uno de los sistemas más socorridos y fáciles de configurar. No obstante, cada día que pasa, la posibilidad de recibir un mensaje como spam, o que pongan al servidor en una lista negra por enviar mensajes «no legales», aumenta proporcionalmente por cada mensaje que el sistema envía, hasta que llega un momento que dejamos de recibir emails, momento seguro en el que el mensaje es de suma importancia y jamás llegaremos a ver.
Visto lo cual, hay dos posibilidades: o bien utilizamos una cuenta SMTP de un servidor externo, o bien configuramos un servidor con soporte SPF y DKIM para evitar que un servidor considere nuestros mensajes como que proceden de un servidor vulnerable y cueste más meterlo en una lista negra.
Siempre he trabajado con Postfix y con Exim, pero visto que Debian instala por defecto Exim, vamos a crear este tutorial utilizando dicha herramienta.
Seguro que todos conocéis una herramienta que viene por defecto en cualquier sistema basado en UN*X llamado syslog. Generalmente esta herramienta se suele utilizar para monitorizar cualquier evento que se produce en el servidor, permitiéndonos conocer si hay algún problema o si por el contrario, todo está funcionando perfectamente.
No obstante, el servidor syslog sirve para recibir eventos, no solo del propio servidor si no de otros dispositivos conectados en red, lo que nos permitirá recibir los mensajes que nos envíe cualquier dispositivo que haya en la red (incluso en Internet). Syslog es una de las herramientas imprescindibles en todo sistema y como tal, debería ser un «must» en cualquier infraestructura de red seria que se precie.
El ancho de banda que consume un mensaje de syslog suele depender de qué se envíe. Cada dispositivo puede permitirnos enviar por syslog únicamente los errores, los avisos, o prácticamente cualquier mensaje que pase por la memoria del dispositivo, por lo que hay que tener cuidado ya que habilitar un debug de un gateway de 4 primarios puede consumir bastante ancho de banda, ya que nos enviaría el protocolo SIP y el Q.931, así que es mejor utilizarlo para monitorizar errores y avisos y algo más preciso sólo cuando sea necesario. 🙂
Vamos a comentar cómo habilitar el servidor syslog para permitir eventos de otros dispositivos.
Aunque puede ser una broma típica de 
En muchas ocasiones nos encontramos que nuestro servidor necesita enviarnos un mensaje, una notificación, algo… y pese a que no soy muy amigo de que un servidor envíe un email 