Etiqueta: Seguridad

c0r0n4con: El congreso de cyberseguridad que recauda fondos para luchar contra el COVID19
Es evidente que esta pandemia global que nos afecta a todos, ha tirado por tierra muchos eventos y actos que se habían planificado en estas fechas. Esto ha hecho que, en el mejor de los casos, se pospongan a una fecha posterior (Julio, Agosto, Septiembre…) pero en otros casos, que sean cancelados debido a la dificultad para prever cuándo se podría celebrar nuevamente.
Del 9 al 12 de abril vía streaming
Ante esto, aprovechando los medios técnicos y la capacidad organizativa de muchas personas, se ha conseguido planificar y preparar la C0r0n4Con, un evento de cyber-seguridad de carácter solidario que planea reunir a más de 100 profesionales y entusiastas de la seguridad informática (ver lista de ponentes) y que se celebrará en riguroso directo vía streaming desde el 9 al 12 de Abril aprovechando estas fechas en la que hay gente que descansa debido a los festivos propios de los días de Semana Santa.
Se trata de un evento internacional que contará con la colaboración de hackers españoles, colombianos, argentinos, brasileños y chilenos que, ofreciendo charlas, buscan recaudar fondos para luchar contra la epidemia que asola nuestros países y que se está cebando con colectivos desfavorecidos que en estos momentos necesitan ser ayudados por instituciones como Cruz Roja.
Más de 3000 horas de charlas sobre cyber-seguridad
El evento se retransmitirá a través de internet, desplegando más de 3000 horas de contenidos (ver programa) y tendrá acceso gratuito para todas aquellas personas que quieran asistir a las charlas y talleres.
Se animará a que los asistentes donen fondos, que serán recogidos directamente por los medios dispuestos por Cruz Roja y mediante los cuales se pueda ampliar el proyecto RESPONDE frente al Covid-19 que está desarrollando la entidad.
Proyecto Plan Cruz Roja RESPONDE frente al COVID-19
Desde el comienzo de esta crisis Cruz Roja aseguró el mantenimiento de sus programas esenciales e intensificó su actividad con las personas más vulnerables ante el COVID19.
En el marco del Estado de Alarma Nacional, lanzando el Plan Cruz Roja RESPONDE frente al COVID19 para las personas en situación de vulnerabilidad y población general, en coordinación con todas las administraciones públicas. Un plan concreto de actuación y respuesta para los próximos dos meses y que pretende alcanzar a más de 1.350.000 personas con un presupuesto estimado de 11.000.000€, al que podrá sumarse a todo aquel que quiera contribuir.
El plan pretende movilizar a más de 40.000 personas voluntarias que materializan las respuestas previstas en todo el Estado a través de sus más de 1.400 puntos de atención. Casi un millón de personas recibirán atención y acompañamiento telefónico, 25.000 familias recibirán bienes básicos, 16.000 personas serán apoyadas en materia de empleo y 3.000 personas sin hogar tendrán un lugar para dormir
Captación de fondos
Se puede colaborar con el proyecto utilizando las siguientes páginas web:
- https://c0r0n4con.com/ (Sección Colabora)
- https://www.cruzroja.es/webCre/donativos/donativos.php
También realizando un ingreso en las cuentas bancarias dispuestas por Cruz Roja España.
Más información
Más información en la web: https://c0r0n4con.com/

y también en twitter: @C0r0n4CON
2020-04-06
Cómo instalar un servidor VPN para teletrabajar en menos de 10 minutos
Hace tiempo que quería escribir un artículo como este, pero ahora que el Coronavirus está empezando a obligar a muchas empresas a buscar mecanismos para que la gente pueda seguir trabajando desde sus casas, creo que es un fantástico momento para explicar cómo montar un servidor VPN para unas pocas personas y que puedan acceder desde cualquier lugar a la red interna como si estuvieran físicamente ahí.
Nota importante: Hay que aclarar que esto abre una puerta (aunque sea cifrada) a que las personas del exterior puedan acceder a la red interna de nuestra oficina, que desde Sinologic no nos hacemos responsables de ningún problema de seguridad que pueda ocurrir por culpa de este tutorial y que, aunque para poder acceder es necesario disponer de un certificado creado específicamente para cada sistema, no se recomienda esto para grandes oficinas, si no para pequeñas oficinas de no más de 5 empleados que necesiten trabajar en remoto de vez en cuando. Si quieres un sistema VPN serio instala en condiciones un servidor IPSEC o un OpenVPN en un servidor de verdad con una conexión en condiciones y aplicando las medidas de seguridad necesarias y contramedidas para evitar ataques.
El objetivo es muy sencillo de entender. Consiste en montar un pequeño servidor VPN dentro de la red interna, utilizando una Raspberry PI como servidor y así evitamos que el coste de un servidor sea un impedimento a los presupuestos organizados de la empresa. Esa VPN hará que podamos conectarnos desde cualquier lugar de Internet al sistema Raspberry y una vez conectado, tener acceso a todos los dispositivos (ordenadores, impresoras, servidores, etc.) de la red interna, así como salir nuevamente por el router de la empresa (por lo que podremos acceder a los sistemas que tengamos filtrados por IP y que únicamente se puedan acceder desde nuestra conexión).
Qué es necesario
Necesitaremos:
- Nuestra oficina deberá disponer de una conexión a Internet con ancho de banda suficiente y dirección IP fija que tendremos que configurar para poder conectarnos a ella cuando queramos acceder.
- Acceso al router de la oficina para mapear el puerto del OpenVPN y poder acceder desde el exterior.
- Una Raspberry PI 3 (aunque mejor 4 ya que tiene más potencia, una tarjeta de red Gigabit).
- Una tarjeta microSD de, al menos 8Gb con la distribución Raspbian.
Esquema mental de nuestra infraestructura ideal
Es importante que, tanto la IP interna de la oficina (192.168.1.X) como la IP interna de nuestro lugar remoto (10.10.0.25), sean subredes diferentes, ya que si son iguales puede haber problemas de enrutado y nuestro ordenador no podrá distinguir qué es «local» y qué es «remoto».
Una vez conectado a la VPN, nuestro ordenador tendrá una IP interna (10.10.0.25) y una IP VPN interna (10.8.0.4) pero tendrá acceso a los ordenadores y servidores de la red interna (192.168.1.X) porque la Raspberry hará de puente.
Si estamos conectados y queremos acceder a una página web, lo haremos con la conexión de la oficina (el router introducirá nuestros paquetes, lo enviará a la Raspberry y volverá a salir por el router manteniendo la IP de la oficina).
Instalación del sistema Raspbian
En la Raspberry PI tendremos que instalar Raspbian, esto es algo básico y sencillo, así como configurarle una IP fija dentro de la red interna, por ejemplo: 192.168.1.248
Para ello lo mejor es acceder al router y buscar la opción para asignar una IP fija a la dirección MAC de la raspberry PI. De esta manera, aunque la raspberry PI pida una nueva IP, el router siempre le dará la misma.
Instalar OpenVPN en la Raspberry PI
Una vez instalada la distribución Raspbian y configurada la IP interna fija en el router, usaremos PiVPN para instalar OpenVPN, por lo que ejecutaremos en la Raspberry PI el siguiente comando:
curl -L https://install.pivpn.io | bash
Este comando instalará OpenVPN y hará varias comprobaciones, además de:
- Pedirnos confirmación de que tenemos una IP interna y fija.
- El usuario de la raspberry PI que utilizaremos para ejecutar todos esos comandos (por defecto: ‘pi‘)
- El puerto del router que utilizaremos para conectarnos desde el exterior. (Por defecto, el puerto de OpenVPN es el 1194/UDP aunque es recomendable poner cualquier otro entre 30000 y 60000).
- También nos preguntará el nivel de cifrado que deseamos tener entre el ordenador remoto y el servidor
- Los servidores DNS que queremos utilizar dentro de nuestra conexión.
Una vez hecho esto, ya tendremos un servidor VPN corriendo en nuestra flamante Raspberry PI. Ahora tendremos que crear las «llaves» para que los usuarios puedan acceder al servidor VPN.
Crear los certificados para los usuarios
Para crear las llaves (o los certificados) tendremos que, con el usuario por defecto ‘pi’ ejecutar el siguiente comando:
sudo pivpn add
Con este comando generaremos en el directorio /home/pi/ovpns un archivo llave (certificado) ARCHIVO.ovpn con todos los parámetros y certificados necesarios de OpenVPN para que alguien pueda conectarse.
Cada certificado solo puede ser utilizado por una conexión simultanea, por lo que si quieres poder conectarte desde varios sistemas, necesitarás generar dos certificados distintos.
Todos los clientes, una vez conectados tendrán, por defecto, una dirección IP interna del rango: 10.8.0.X (diferente al del resto de la red interna) pero todos los usuarios conectados podrán verse entre sí.
Mapear el puerto seleccionado en el router
Ahora tenemos que acceder al router y mapear el puerto que hayamos configurado en la raspberry para el servidor OpenVPN, de manera que cuando alguien acceda a dicho puerto, se reenvíe a la Raspberry PI. (es necesario que el puerto del router y el que hemos configurado sean el mismo).
Configurar el cliente
Cliente para Windows
Una vez tenemos el archivo certificado con extensión .ovpn, es el momento de instalar un cliente en nuestro sistema operativo y cargarle dicho certificado para que pueda conectarse.
Para Windows, OpenVPN tiene su propia aplicación OpenVPN Connect que podéis instalar desde aquí: https://openvpn.net/client-connect-vpn-for-windows/
Para Mac, yo recomiendo TunnelBlick. Se instala, se selecciona el archivo ARCHIVO.ovpn que se desea utilizar y listo!
Para Linux, tan solo hay que instalar el paquete ‘openvpn’ y ejecutarlo tal que así:
openvpn –config ARCHIVO.ovpn
Extras importantes e interesantes
- Si en lugar de utilizar el puerto 1194/UDP, utilizásemos uno del tipo 80/TCP, podríamos usar esta conexión en aquellas redes que sólo permiten navegar a una web (como algunos hoteles, convenciones, etc.). De esta manera, este sistema nos ayudará a saltar a la red interna y poder navegar con total seguridad aunque la red en la que estemos no permita otro tipo de accesos.
- Es importante saber que los archivos generados con los certificados de clientes van asociados a la dirección IP y puerto externo a la que nos vamos a conectar, de manera que si la oficina cambia de dirección IP habría que rehacer los certificados o modificarlos manualmente con un editor (ya que es un archivo de texto plano)
- Si utilizas VPN para cifrar la VoIP (UDP), si para la VPN usas un protocolo TCP, entonces estarás encapsulando todo el tráfico en paquetes TCP, por lo que en VoIP pueden aparecer micro-cortes en el audio en redes de baja y media calidad, además de que para evitar contagiar de Coronavirus, es mejor no hacer handshaking y seguir usando paquetes UDP siempre. 😉
- Este sistema es el que utilizo para conectarme a la red interna de mi casa desde hace varios años, por lo que puedo garantizar que no sólo funciona estupendamente si no que además es una de las mejores formas de acceder remotamente a la red interna.
- Hay muchísimas opciones dentro del servidor OpenVPN, pero desde este artículo intentamos explicar brevemente cómo configurarlo para una oficina pequeña y un comportamiento estándar útil que nos facilite el trabajo en remoto ahora que desde el gobierno se está recomendando a las empresas que opten por el teletrabajo para evitar contagios.
GUÍA PARA LA ACTUACIÓN EN EL ÁMBITO
LABORAL EN RELACIÓN AL NUEVO CORONAVIRUS Descarga
2020-03-10
SIPCheck 3 : La herramienta que asegura tu Asterisk ante ataques externos
Por mucho que pase el tiempo, y más ahora que el número de sistemas VoIP en la nube (o en remoto) aumenta, el número de ataques también aumenta considerablemente y es entonces cuando se hace necesario el uso de herramientas que nos ofrezcan la seguridad que necesitamos para poder estar seguro que nuestro sistema está controlado y no vamos a ser víctimas de un ataque mientras no estamos pendientes. Esta es la función de SIPCHECK, una herramienta que se conecta a Asterisk y vigila de accesos ilegítimos de direcciones IP desconocidas manteniendo nuestro Firewall actualizado con las direcciones IP de los atacantes.
En 2010, durante una comida en el curso de Asterisk Advanced de Bilbao, surgió una idea muy simple pero efectiva. Uno de los principales problemas que tenían muchos de ellos era la inseguridad que producía recibir ataques en los Asterisk que debían estar expuestos por Internet.
Ni que decir tiene que surgieron muchas ideas: utilizar VPN, cambiar a puertos no estándar, etc. y tras la exposición de los problemas y las posibles soluciones, una de ellas se presentó tan sencilla como fácil de implementar: Generar una aplicación que analizara el log de Asterisk y cuando detectara errores de autentificación, baneara automáticamente esa IP compartiendo dicha IP con el resto de la comunidad.
Esto fue una gran idea y así se hizo en la versión inicial de SIPCheck. Cuando el sipcheck detectaba un ataque, obtenía la dirección IP y la compartía con el resto de la comunidad para que todos pudieran tomar nota y rechazarla en los firewalls.
El resultado de esto fue algo más inesperado de lo que pensábamos: miles de direcciones IP baneadas (incluso algunas legítimas) y firewalls con tablas inmensas que incluían direcciones IP que, en algún momento del pasado atacaron a alguien. Estaba claro que tener un firewall con decenas de miles de direcciones IP que, en algún momento pudieron ser víctimas de un ataque y sirvieran de proxy para otro atacante no era la solución, ni siquiera para tenerlo en una tabla ACL de «IPs denegadas» ya que el 90% de esas direcciones IP no van a volver a atacarnos. La solución a esto, sin duda, era otra.
Ante esto, sucedieron varias modificaciones (añadir IPs con un registro de fecha y hora para que expiraran pasado un tiempo, introducir únicamente aquellas direcciones IP comunes que hayan sido baneadas por varios usuarios distintos, etc.) y los resultados fueron interesantes, aunque seguía sin obtenerse el resultado esperado.
Para ello, en 2014 se publicó SIPCheck 2, una versión nueva que incluía un registro sobre las direcciones IP baneadas en una web local que se podía consultar y añadir o eliminar aquellas IPs en tiempo real. Se eliminó la parte comunitaria ya que entendimos que si a un usuario de Japón le ataca una IP, no tiene por qué atacar a otro de Nápoles y, de esta manera se reducía el número de direcciones IP en el firewall. Se añadió soporte IPSet que mejora el funcionamiento de grandes listas de direcciones IP baneadas y aún así, la lista seguía sin ser efectiva (seguían apareciendo nuevas direcciones y seguíamos teniendo en el firewall direcciones que ya no se usaban). Al menos con SIPCheck v.2 podíamos eliminar manualmente aquellas direcciones antiguas.
Es en 2019 que, tras algunos cambios y nuevos proyectos surgió la idea de renovar el SIPCheck para paliar algunos defectos del SIPCheck inicial (que todavía hay gente utilizándolo) así como para reducir la carga al mínimo (muy inferior al de SIPcheck 2 y por supuesto al de Fail2Ban), empezamos a desarrollar la tercera versión nuevamente pero con todas las mejoras.
SIPCheck v.3
Funcionamiento
Esta versión de SIPCheck utiliza dos mecanismos diferentes para controlar los eventos:
– Mánager de Asterisk: (el 99% de los ataques) Con esto se controlan los intentos de login erroneos, los correctos y gracias a esto evitamos sobrecargar el sistema cuando el Asterisk es muy grande y genera mucha información en el log.
– Archivo /var/log/asterisk/messages: (el 1% restante) Con esto se controlan los INVITES sin autentificar y que no aparecen en el manager. Está claro que con el parámetro ‘allowguest = no‘ ni siquiera aparecerán estos INVITES, pero de alguna manera había que controlar este caso.
El funcionamiento de esta versión se basa en la gestión automática de 3 listas:
- Lista blanca : con direcciones IP confiables y que no deben estar baneadas aunque se reciban peticiones de registro con contraseña erronea. (Esta lista blanca la formarán aquellos que incluyamos en el archivo ‘whitelist.txt’ y aquellas direcciones IP que se hayan registrado correctamente.)
- Lista de sospechosos : con direcciones IP procedentes de algunos ataques pero no los suficientes como para considerarlos ataques. Cuando se recibe un intento de registro con una contraseña inválida, se almacena aquí hasta que el número de intentos supere un número determinado /y configurable/. Si un sospechoso deja de enviar los intentos, el sistema lo eliminará de la lista de sospechosos pasado un tiempo.
- Lista negra : con direcciones IP oficialmente considerados como ataques. Estos son auténticos atacantes y cuando están en la lista negra, el SIPCheck también lo incluye en el firewall impidiendo volver a acceder al sistema, por lo que el sistema es autónomo y no tenemos que preocuparnos. En esta lista permanecerá un tiempo configurable tras el cual se eliminarán tanto de la lista negra como del firewall, manteniendo a este limpio de atacantes antiguos.
Cuando SIPCheck detecte un ataque procedente de una IP, lo añadirá a la Lista de sospechosos y permitirá seguir recibiendo tráfico. Si recibe varias peticiones idénticas entonces pasará a considerarlo como un ataque oficial y lo añadirá a la lista negra y al firewall impidiendo más tráfico procedente de esa IP.
Si una IP se ha registrado correctamente en nuestro sistema, entonces se considera que esa IP pertenece a alguien «confiable» por lo tanto lo añadiremos a la Lista Blanca durante un tiempo evitando considerarlo atacante durante el tiempo en el que esa IP esté en la lista blanca. Esto impedirá banear una dirección IP de una empresa únicamente porque un teléfono tenga una contraseña errónea.
Todos los valores son configurables: número de contraseñas erroneas, tiempos en cada una de las listas, etc.
Se tiene incluso un archivo ‘whitelist.txt‘ donde podremos indicar las direcciones IP que jamás deberán serán baneadas por el SIPCheck (operadores, IPs de gestión, etc.)
Objetivos
El objetivo de esta aplicación son varios:
- Orientado a sistemas de alta carga: Probándolo en sistemas de alta carga, el consumo se disparaba, por lo que había que buscar una forma alternativa de minimizarla. Para ello se utiliza principalmente el ‘manager’ de Asterisk y para algunos casos puntuales el messages como complemento y evitar la sobrecarga de analizar cada línea del log de Asterisk.
- Evitar falsos positivos: En versiones anteriores, si un teléfono enviaba varias veces una contraseña erronea, el SIPCheck baneaba la IP entera. En esta versión, si una IP es registrada correctamente, pasa a una lista blanca que impide activar el protocolo de ataque en dicha IP compartida por varios teléfonos, seguramente de la misma empresa. De esta manera evitamos que un teléfono mal registrado en una empresa banee la IP del resto de la empresa.
- Persistente en el tiempo: Si se reinicia la aplicación, todos los datos y direcciones IP de todas las listas se mantienen y se vuelven a banear en firewall (si no lo estaban ya).
- Configurable: Se ha añadido un archivo sipcheck.conf donde poder configurar prácticamente cualquier parámetro que permita personalizar la aplicación.
La instalación es bastante sencilla ya que tan solo hay que seguir las 4 instrucciones del README para instalarla.
Y para comprobar qué está haciendo, todo queda registrado en un archivo de log en /var/log/sipcheck.log
Con esta aplicación, en varios Asterisk expuestos en Internet a modo de honeypot sin ningún otro tipo de protección, el sistema ha detectado y bloqueado cientos de ataques y lo mejor es que mantiene un firewall bastante reducido ya que las direcciones IP desde donde se producen los ataques dejan de atacar cuando empiezan a ser bloqueadas. Gracias a estos honeypots hemos aprendido muchas cosas nuevas sobre estos ataques que nos permitirán seguir mejorando el SIPCheck para conseguir detectar nuevas formas de ataques.
Si tienes comentarios o quieres dejarnos un feedback sobre esta aplicación puedes escribirnos un issue en Github, un comentario en el canal Telegram de @sinologic o en el correo electrónico sipcheck@sinologic.net
Para descarga y más información: https://github.com/sinologicnet/sipcheck
2020-02-24
SIPPTS: Un conjunto de herramientas para ayudarnos con la seguridad de nuestro sistema VoIP
Nuestro gran colega @Pepelux acaba de publicar la versión 2.0.2 de SIPPTS, un set de herramientas libres para auditar la seguridad de nuestra infraestructura VoIP. Estas herramientas están disponible en su página de GitHub: https://github.com/Pepelux/sippts
Las herramientas que forman el paquete SIPPTR son:
- Sipscan un scanner para servicio SIP que puede comprobar varias IPs y rangos de puertos tanto UDP como TCP.
- Sipexten para comprobar si existe una extensión en un servidor SIP, así como si necesita identificación o no.
- Sipcracker un crackeador de contraseñas remotas capaz de probar contraseñas para muchos usuarios en distintas IPs y puertos.
- Sipinvite comprueba si un servidor nos permite hacer llamadas sin autentificación, también si puede hacer llamadas salientes.
- Sipsniff un simple pero útil sniffer SIP.
- Sipspy un servidor SIP muy simple que nos permite ver las peticiones y respuestas recibidas.
- SipDigestLeak Herramienta para explotar la vulnerabilidad SIP descubierta por Sandro Gauci que afecta a un gran número de hardware y software.
Un kit muy completo y recomendable para hacer pruebas y revisar la seguridad. 😉
2019-12-11
Un servidor Asterisk, el único que se salva del ataque al Ayuntamiento de Jeréz
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. 😛
Más información:
http://ganemosjerez.es/blog/2019/10/03/un-servidor-con-linux-el-unico-que-sigue-funcionando/
2019-10-05
SecFilter, el módulo de Kamailio para mejorar la seguridad
Kamailio es una herramienta muy potente, muy flexible y super-eficiente, de eso no cabe duda, pero de la misma manera que nos permite manejar más de 20.000 llamadas en un pequeño sistema con un único núcleo y apenas 4Gb de RAM, también nos puede causar un buen agujero en el bolsillo si no tenemos cuidado. Por este motivo, Kamailio no es como Asterisk ni como otras herramientas similares, hay que manejarlo con cuidado, hacer pruebas antes de hacer cualquier cambio y cerciorarse bien que lo que se hace, es lo que debe hacerse en todo caso.
Kamailio ya implementa un módulo de seguridad conocido por todos llamado Pike, un módulo que «mide» las peticiones en un tiempo concreto y si el número de peticiones es superior al que le hemos configurado, puede ejecutar un comando que, generalmente suele ser una entrada en la lista negra, en el firewall o también un mensaje de alerta para advertirnos de un posible ataque de denegación de servicio (DoS).
Con esto hemos sobrevivido por el momento, pero en el VoIP2DAY, Jose Luis Verdeguer (aka @Pepeluxx) ya me comentó que estaba trabajando en un módulo de seguridad para Kamailio, con lo que estaba deseando probarlo en cuanto saliera a la luz. Es verdad que con el módulo Pike nos quitamos muchos ataques basado en repeticiones, y que el propio Kamailio puede analizar cierta información para descubrir otros tipos de ataque, pero es cierto que echaba de menos algo más completo que facilitara la detección de posibles ataques, y esto es justamente lo que hace el nuevo módulo de Kamailio: Secfilter.
Secfilter es un módulo de Kamailio que ofrece la posibilidad de gestionar una lista blanca o lista negra en función de parámetros como «user agents», país, dominio, destino, etc. de esta manera podemos aumentar la seguridad de nuestros Kamailios de una forma mucho más personalizada y probada.
La descripción del módulo dice así:
Este módulo ha sido diseñado para ofrecer una capa adicional de seguridad sobre nuestra comunicaciones. Para realizar esto, se disponen de las siguientes funcionalidades:
- Añadir a la lista negra o bloquear «useragents», direcciones IP, países, dominios y usuarios.
- Añadir a la lista blanca para permitir «useragents», direcciones IP, países, dominios y usuarios.
- Añadir a la lista negra cuando el número marcado no sea permitido.
- Prevenir de ataques SQL Injection.
Cuando una función sea llamada, se buscará en la lista blanca. Si no se encuentra, entonces se buscará en la lista negra.
Realmente este módulo es un gran módulo y desde aquí felicitamos a Jose Luís Verdeguer por este gran aporte y ya de paso a Victor Seva y a Daniel Constantine por darle apoyo para que sea incluido en Kamailio.
2018-12-19
Los bots empiezan a atacar a Asterisk
Internet es una jungla, hay quien quiere poner puertas en medio y quien pone alambradas, pero está claro que por muchos firewalls, antivirus, protecciones y leyes se instalen, siempre hay alguien que consigue meter un troyano, un virus, o algún resquicio legal para que tu estancia en Internet no sea tan placentera como esperabas. Si montas un blog, hay cientos de exploits sobre el software que utilizas como servidor web, otros cientos de exploits para la plataforma que utilizas, decenas de exploits para cada uno de los plugins que has instalado y por si fuera poco, además el servidor incluye otros servicios que también son vulnerables y siempre hay alguien intentando explotarla.
Si pones un servidor VoIP accesible desde el exterior (por la razón que sea) siempre hay quien intenta aprovecharla, no en vano existen bots especializados en atacar sistemas VoIP que buscan puertos SIP (en el 5060 o donde sea), probar cientos de miles de combinaciones de usuarios/contraseñas y en el caso de que exista alguna cuenta desprotegida con una contraseña sencilla o incluso sin contraseña, empieza un ataque mediante llamadas SIP a números internacionales que pondrán a prueba, no solo el rendimiento del sistema de comunicaciones, si no nuestra capacidad y velocidad para darnos cuenta de que estamos siendo atacados y están haciendo llamadas a través de nuestra infraestructura.
Siempre he dicho que cada fabricante echará la culpa a los productos de la competencia, pero está claro que independientemente de qué software o hardware utilicemos, si ponemos usuarios y contraseñas estándar, vamos a ser atacados tarde o temprano ocasionándonos un gran dolor de cabeza (en el mejor de los casos). Por esta razón, aunque soy de los que defienden que cada protocolo debería funcionar en su puerto (SIP en el 5060), si es cierto que hay que prestar atención a que cada usuario tenga su contraseña bien difícil de adivinar y que no debemos llevarnos las manos a la cabeza ni preocuparnos cuando veamos que un bot intenta registrarse. Cambiar de puerto solo evita ser encontrado de buenas a primeras, pero los bots hacen escaneo de puertos, por lo que el puerto SIP seguirá siendo encontrado tanto si está en el 5060 como si está en el 65535.
Resulta que los bots no solo atacan al puerto SIP, si no también buscan sistemas vulnerables y para ello hacen también varias pruebas:
- Comprueban si el servidor SIP tiene un servicio WEB.
- Comprueban si el servidor WEB tiene ciertas aplicaciones instaladas.
- Comprueban si las aplicaciones instaladas tienen una versión vulnerable.
- En caso afirmativo, usan un exploit para, o bien hacer llamadas desde la aplicación, o bien para abrir una puerta con un usuario nuevo y poder hacer llamadas desde ahí.
Los ataques son cada vez más sofisticados, y por suerte, si estamos medianamente al día en cuanto a las versiones, la probabilidad de que la aprovechen es mínima, pero siempre hay algún exploit más nuevo que no hemos visto, siempre instalamos más aplicaciones de las que deberíamos (y luego no las borramos) y por esta razón los «sipbots» encuentran huecos donde conseguir un suculento bocado.
Visualizador de ataques en tiempo real http://community.sicherheitstacho.eu/start/main
Una versión de Elastix antigua, un A2Billing antiguo, un PHPMyAdmin, un WordPress, un … cualquier aplicación es susceptible de ser vulnerable y abrir la puerta en un momento dado a un ataque. En Alemania, el vicepresidente de seguridad de Deutsche Telekom avisaba del aumento de ataques al puerto 5038 (puerto generalmente utilizado por el servicio AMI -Manager- de Asterisk) y es que es un servicio que puede ser explotable por fuerza bruta similar al que tendríamos abriendo un puerto Telnet a nuestro servidor. Por supuesto es importantísimo no disponer de cuentas «de pruebas», pero lo que los bots buscan son cuentas «comunes» utilizadas por aplicaciones conocidas, aquellas que para que funcionen, por defecto son «stats» y «statspass» o «a2billing» y «changethepass«, o similares. (you know what I mean)
We see a lot of #cyber #attack traffic on Port 5038/tcp, this is a config port of Asterisk PBX. Somebody is trying to bruteforce the confic of VoIP PBX systems. #TelekomSecurity https://t.co/wNe8QTb1eI
— Thomas Tschersich (@Ttschersich) February 26, 2018
Siempre he defendido que no hay que ser un paranoico de la seguridad, eso solo nos lleva a consumir un tiempo precioso en vigilar cuando deberíamos invertirlo en avanzar y mejorar, pero también es cierto que hay que ser conscientes en que la seguridad debe venir de la mano de una serie de hábitos básicos como desinstalar una aplicación si no la vamos a utilizar, siempre contraseñas fuertes y mucho cuidado con «las pruebas» que luego se olvidan que están ahí.
2018-03-07
Skype tendrá que reescribirse completamente para solucionar un bug
Un bug, que se encuentra en el core de la aplicación y que permite controlar remotamente el equipo de quien ejecuta el cliente parece ser el motivo por el que Microsoft está reescribiendo completamente dicho cliente de VoIP.
El investigador de seguridad Stefan Kanthak encontró que el módulo de instalación de actualizaciones es vulnerable a la técnica de DLL hijacking que permite a un atacante ejecutar código malicioso en lugar de la librería correcta. Un atacante podría descargar una librería DLL en un directorio accesible por el usuario y renombrarla en una DLL que exista y que pueda ser utilizada por un usuario del sistema.
El bug que fue encontrado el pasado mes de septiembre supondrá, no solo un parche ni una revisión de código si no una completa re-escritura del core del programa, por lo que, aunque no tenemos noticias sobre cuando podría salir la nueva versión, no esperamos que sea pronto ya que escribir una aplicación como Skype desde cero.
Más información: http://www.zdnet.com/article/skype-cannot-fix-security-bug-without-a-massive-code-rewrite/
2018-02-19
Explicación de la vulnerabilidad de los procesadores Intel
Para empezar bien el año, nos hacemos eco de algo que va a traer cola, una vulnerabilidad encontrada en el diseño hardware de los procesadores Intel. Si bien este tema no es el típico para Sinologic, su extrema importancia nos obliga a tomar parte y al menos intentar aclarar algunos aspectos que se vienen dando a conocer.
La vulnerabilidad consiste en que un atacante puede acceder a toda la memoria de un ordenador, servidor, móvil, reloj, dispositivo, etc. que tenga un procesador afectado por dicha vulnerabilidad.
Aquí es donde viene uno de los grandes problemas ¿qué procesador está afectado por esta vulnerabilidad? Pues aunque inicialmente se había asociado a Intel, éste afirma que también son vulnerables otros fabricantes como AMD y ARM, así que prácticamente el 95% de los procesadores del mundo tienen este fallo.
Este fallo se puede corregir mediante un parche software en el núcleo del sistema operativo, pero tiene una pega: la aplicación del parche hace que el rendimiento se reduzca en torno al 30% (que no es poco).
De momento ya han aparecido dos grandes exploits que vienen a confirmar que dicho bug existe: Meltdown y Spectre.
Desde cierto punto de vista, parece que el problema está ahí y que existe una decisión que tomar: seguridad o velocidad.
Si quieres seguridad, tienes que aplicar los parches, pero eso reduce el rendimiento. Si quieres rendimiento, tienes que saber que puedes ser atacado y el fallo no es poca cosa (contraseñas, cuentas, etc. están en memoria y son accesibles «fácilmente»).
Ejemplo gracias a @misc0110 (https://twitter.com/misc0110)

Pero no todo es tan sencillo como aplicar un parche:
Meltdown puede ser utilizado por cualquier persona mediante un script tonto.
Spectre en cambio es algo más difícil de utilizar pero es prácticamente imposible de solucionar con los procesadores actuales.
Imagina qué puede hacer un atacante en una máquina en la nube que está compartida por varias empresas. La cosa es mucho más seria de lo que parece.
Para relajarnos, vamos a poner una captura de pantalla del informe de vulnerabilidad del Departamento de Seguridad Ciudadana de los EEUU y la solución que proponen:
En fin… empezamos bien el año. 😉
Gracias a @okercho por la información. 😉
Actualización:
Al parecer ya se empiezan a conocer cuanto empiezan a afectar a los procesadores de distintos fabricantes:
1) Intel: Le afectan todas las variantes de la vulnerabilidad. Igual para un usuario normal no se verá afectado, pero en servidores la cantidad de información propiciará los ataques y se verán expuestos muchos datos privados.
2) AMD: Tras analizar sus sistemas, ha reconocido que le afecta una variante de las que hay en versiones por debajo de los FX (incluido) pero por suerte no existe aún el exploit para aprovechar dicha vulnerabilidad. Así que AMD, aunque le afecta también esta vulnerabilidad, parece que el daño es menor. AMD asegura que los Ryzen no son vulnerables a este ataque. Aunque no se ha podido confirmar.
3) ARM: Le ocurre lo mismo que a AMD: Sobre el papel es vulnerable a un tipo de ataque.
2018-01-04
Cómo evitar el ataque del Wanna Cry y otros Ransomwares
Si no eres de este planeta, igual no te has enterado que la principal operadora de España (Telefónica) sufrió este viernes un ataque en su red interna a través de un virus de tipo «ransomware» (ransom – Rescate, ware – sofware) de manera que muchos sistemas sufrieron un cifrado indiscriminado de sus datos dejando inutilizado todo el fin de semana la red interna de este operador. La empresa Telefónica no fue el único que sufrió este ataque, ya que se propagó por redes internas y emails afectando a más de 150 países y más de 200.000 sistemas (según la Europol) entre ellos, hospitales, centrales eléctricas, organismos y empresas además de usuarios normales.
Al ocurrir esto un viernes, es de esperar que el lunes el número de sistemas infectados aumente considerablemente, ya que la vulnerabilidad fue corregida por Microsoft en una actualización del mes de Marzo pero esta afecta a todas las versiones de Windows desde la versión XP y es que hay muchos, muchos sistemas que no solo no van a actualizarse, si no que además no pueden actualizarse por diversas razones.
Por supuesto, una de las mejores maneras de evitar que el virus Wanna Cry (también conocido como WanaCrypt0r 2.0) afecte a nuestros sistemas es evitar utilizar Windows en sistemas considerados críticos. Por este motivo, Telefónica apuntó que la red interna fue afectada pero no así sus sistemas críticos (firewalls, servidores, etc…).
La mejor manera de evitar ser atacado por un virus, es no utilizar Windows. Puede sonar contundente y demasiado directo, pero por desgracia, es cierto.
Está claro que un fallo lo puede tener cualquiera, y que cuando un sistema operativo tan utilizado como Windows tiene un fallo de seguridad, las probabilidades de ser aprovechados se multiplica por cada usuario, pero no es la primera vez que ocurren este tipo de vulnerabilidades. Aún recuerdo el famoso gusano «Blaster» que infectaba a cualquier Windows que no estuviera protegido en apenas 10 segundos tras encenderse y conectarse a una red… El software cerrado tiene ese problema, los fallos no son tan transparentes ni tan fáciles de arreglar y cuando algún desequilibrado quiere aprovecharlo, lo hace con mucha, mucha fuerza. La vulnerabilidad llevaba ahí desde mucho, mucho tiempo y no ha sido hasta el pasado mes de Marzo que la han arreglado. ¿qué pasará con esos cientos de ordenadores «zobies» que inundan la red?
Sistemas de comunicaciones basados en Windows son igualmente vulnerables a este virus, que se transmite por el protocolo SAMBA (compartición de archivos de Windows, sistema de dominios de red, etc.) ¿Qué ocurre en una empresa que utiliza este tipo de protocolos para compartir archivos en su red interna?
Muchos comentan que otros sistemas operativos como Mac o Linux también tienen virus similares, aunque por la forma en la que se gestionan los permisos, salvo que alguien le de permisos de ‘root’ o ‘administrador’ al propio virus, este solo puede causar daños a los propios archivos del usuario y a nadie más. También puede ser que, de la misma manera que el virus aprovechó una vulnerabilidad del sistema operativo, otro virus puede aprovechar otra vulnerabilidad del kernel de linux o de mac para afectar al sistema. En este caso, el kernel de linux es abierto y son muchos los ojos que se darían cuenta de estas vulnerabilidades, en cuyo caso se pondría la alarma de un día para otro y sacarían una actualización mucho antes que los creadores de virus pudieran sacar una versión que la aprovechara. Así ocurrió cuando se conoció que alguien de la NSA había incluido código para disponer de un backdoor en los sistemas Linux y fue descubierto enseguida y retirado sin lamentar daños.
Hay un juego gratuito para móviles bastante macabro llamado Plague, consiste en crear un virus a medida y ver si puede acabar con la población mundial. Existen dos factores importantes: capacidad de transmisión y letalidad. Cuanto más capacidad de transmitir tenga, más rápido se contagiará, pero si la letalidad es demasiada alta, los individuos morirán antes de transmitirlo, así que hay que «jugar» a crear el virus con el equilibrio ideal, que sea rápido pero no tanto, y que sea letal, pero tampoco tanto. El virus Wanna Cry se asemeja a ese equilibrio perfecto: por un lado es fácil transmitirlo y por otro lado le da tiempo al sistema a contagiar a otros antes de cifrar todos los archivos. Por suerte, solo afecta a sistemas operativos vulnerables, con lo que muchos servicios importantes que funcionan con servidores Linux no han sido inutilizados.
La ausencia de virus siempre han sido un motivo por el que elegir Linux en sistemas críticos, no por que sean más seguros (que seguramente también lo sean) si no por que, al ser abiertos y libres, están más vigilados y la seguridad por ocultación nunca ha sido buena, de ahí que confiar en que no recibiremos ataques en nuestra centralita por cambiar el puerto del SIP del 5060 a otro, es solamente retrasar lo inevitable. En la seguridad hay que tomarse las cosas en serio y cualquier otra cosa, es solo retrasar los problemas.
2017-05-15