Archivo de la etiqueta: Kamailio

Sistemas de comunicación seguros

Parece que fue el otro día cuando estuve con mi gran amigo Víctor Seva (@linuxmaniac) dando una charla en la RootedCon sobre sistemas de comunicaciones seguros, y la verdad es que ya han pasado más de 4 años. El vídeo de la conferencia se puede ver aquí:

En la charla se muestra cómo podemos ver un sistema aparentemente seguro y que luego no lo es. La finalidad de este proyecto, o prueba de concepto, no era ofrecer una herramienta al usuario sino concienciarle, es decir, hacerle ver que aunque algo parezca seguro, puede no serlo. De hecho, si buscamos en el Play Store, en el Apple Store o por Internet aplicaciones para mantener comunicaciones de voz seguras, nos vamos a encontrar un montón pero, ¿qué hacen realmente? ¿podemos fiarnos de ellas? Cuando una persona tiene la necesidad de cifrar una comunicación es por algo importante (no confundir con ilegal) y no puede correr riesgos.

4 años más tarde, sí que tengo implementado un sistema para poder realizar llamadas seguras, sin que nadie pueda interceptarlas, escucharlas o grabarlas. Pero si has visto la charla, no te vas a fiar ahora de lo que te diga, ¿verdad? y por eso, antes de hablar del sistema, creo que es necesario entender una serie de conceptos. Cuando alguien tiene la necesidad de mantener una comunicación privada, no puede arriesgarse a usar una aplicación mágica sin entender realmente cómo funciona o cómo se gestionan los datos. Por tanto, creo que el primer paso antes de usar alguna herramienta es entender cómo se cifra una comunicación de voz, qué alcance tiene y cómo podemos verificar si la comunicación está o no cifrada realmente.

VoIP

Vamos a partir de la base de que todas las comunicaciones que vayamos a cifrar van a ser de VoIP, por tanto, tráfico IP que circulará por Internet. A diferencia de un sistema convencional donde se ‘pincha’ una línea física para realizar una escucha, con VoIP, al igual que cualquier otro servicio que funcione a través de redes IP, la interceptación se realiza esnifando o monitorizando datos. Por tanto, nuestros objetivos serán bastante precisos: cifrar las comunicaciones y evitar ataques MitM.

Sin entrar en demasiados detalles técnicos acerca de la VoIP y de los protocolos involucrados en este tipo de infraestructuras, para poder mantener una comunicación realizaremos 2 fases:

Fase de señalización

La misión de la señalización es permitir el intercambio de información entre los diferentes dispositivos o servidores, con la finalidad de que la llamada pueda ser establecida y terminada correctamente. En el caso de la VoIP usaremos el protocolo SIP (también pueden usarse otros, pero SIP es el más extendido). Este protocolo es muy similar al HTTP, donde usaremos una serie de mensajes o métodos para comunicarnos. Aquí podemos ver los más relevantes:

Y obtendremos unos códigos de respuesta:

Como decía, el formato de los mensajes es muy similar al HTTP, donde nos encontramos con una serie de cabeceras y el cuerpo del mensaje:

Añadido al protocolo SIP tenemos el protocolo SDP que ofrece información adicional sobre cómo se va a negociar la comunicación. El SDP se corresponde con el cuerpo del mensaje y se incluye sólo en los métodos cuyo objetivo es establecer una comunicación entre los interlocutores (en este caso es lo que aparece bajo el Content-Length). En la imagen de arriba vemos que se especifica la IP (72.12.135.250) y puerto (27252) para la comunicación RTP de audio, así como los códecs (BV32 Speech, G.729) que el dispositivo soporta. El otro dispositivo contestará con un mensaje OK, también con SDP, donde aparecerá la información de su IP y puertos para el media, así como los códec soportados. Finalmente se comunicarán usando un códec que ambos soporten o, en el peor de los casos, el servidor tendrá que hacer una trascodificación. Como ejemplo imaginemos en un lenguaje humano que una persona habla español e inglés y la otra inglés y francés. Para comunicarse usarán el inglés. Sin embargo si una habla ingles y español y la otra sólo francés, si el servidor soporta ambos idiomas, hará de traductor.

Y la forma de cifrar esta comunicación es utilizando TLS.

Fase media

Se trata de la transmisión de audio, es decir, la comunicación entre los interlocutores una vez se ha negociado cómo se va a realizar la comunicación en la fase anterior. El tráfico se enviará siguiendo el protocolo RTP (sin cifrar) o SRTP (cifrado).

Creo que hasta aquí queda más o menos claro el funcionamiento, pero vamos con las dudas y puntualizaciones:

¿Podemos cifrar una llamada a un móvil o a cualquier otro número de teléfono?

La respuesta es NO.  Para poder realizar una llamada el teléfono IP debe estar conectado a un servidor de VoIP (por ejemplo a una PBX) y si el servidor soporta SRTP, podremos mantener comunicaciones cifradas entre extensiones, es decir, entre dispositivos conectados a esa misma PBX. Pero si necesitamos hablar con un número externo, esa llamada la enrutará el servidor hacia un operador de VoIP mediante un SIP-trunk, y este lo mandará a otro operador o a un wholesale o a un carrier, pero en cualquier caso, cuando salga de nuestro servidor, el tráfico ya no estará cifrado. Por lo que no podemos tener una llamada cifrada si la cursamos a un teléfono externo a nuestro sistema.

Resumiendo, si queremos mantener una comunicación cifrada con otra persona, es primordial que ambos estemos conectados al mismo sistema y usemos un único canal cifrado. En este caso se crea un canal seguro entre nuestro teléfono y nuestro servidor pero luego se utiliza un canal inseguro entre el servidor y el destino (que además pasará por otras infraestructuras de las que no tenemos ningún control). Es decir, no podemos tener un teléfono mágico que nos cifre cualquier llamada que hagamos a cualquier parte.

¿Por qué no puedo establecer una comunicación entre dos teléfonos, sin un servidor de por medio?

La respuesta corta es … por temas de NAT. Si nosotros desde casa conectamos con una página web, nuestro router aplica NAT y la petición se realiza con la IP pública y un puerto asignado por el router. Cuando vienen los datos de vuelta, nuestro router consulta la tabla NAT y sabe a qué dirección IP:puerto privada debe enviar los datos. Por el contrario, en una comunicación con el protocolo SIP todos los datos de conexión vienen encapsulados en el paquete, por lo que el teléfono al construir ese paquete va a poner como IP origen la suya privada y cuando llegue al otro dispositivo, a pesar de que el paquete llegará bien porque el router hará su trabajo, en las cabeceras vendrá la IP privada, que será a la que tratará de responder el otro dispositivo. Y evidentemente, el mensaje de vuelta nunca va a llegar al destino.

Para el caso de la señalización, configurando rutas estáticas en el router y forzando puertos, podemos llegar a redirigir el tráfico, pero tampoco tiene mucho sentido puesto que un servidor de señalización sirve para otras muchas cosas. Por eso mediante mensajes REGISTER el dispositivo indica al servidor dónde se le puede localizar si alguien intenta contactar con él.

Otra opción sería usar SIP ALG que incorporan la mayoría de routers y lo que hace es intentar arreglar las cabeceras y cambiar las IPs locales por la pública, pero esto tiene varios incovenientes:

  • Si usamos cifrado TLS el router ya no tiene acceso al contenido del paquete y, por tanto, no puede alterar los datos.
  • A día de hoy no me encontrato un sólo router que aplique bien SIP ALG y más que arreglar lo que hace es estropear los paquetes.

Y con el media ocurre lo mismo. Si nosotros tuviéramos IPs públicas en nuestros teléfonos, sería posible una comunicación directa entre dos dispositivos, a pesar de que la señalización se realice a través de una PBX. Pero como nuestros dispositivos van a crear el mensaje INVITE rellenando el SDP con una IP:puerto de la red privada, cuando el otro dispositivo trate de responder, no va a llegar nunca el audio. Por eso se requiere de un servidor de relay para el media, cuya función será arreglar estos datos y enviar el tráfico al lugar correcto.

¿Es seguro el protocolo SRTP?

No soy un experto en criptografía pero teóricamente es un protocolo seguro, aunque siempre podemos ser objetivo de un ataque MitM, por lo que aunque la comunicación vaya cifrada, alguien puede interceptarla y descifrar los datos. Además, tal y como se ve en la charla, podemos usar una PBX para desviar el tráfico y generar 2 canales de datos, de forma que haya un canal cifrado entre el servidor y el primer interlocutor y otro canal cifrado entre el servidor y el segundo interlocutor, pero al ser 2 canales diferentes el servidor ve los datos en claro y puede llegar a grabar las conversaciones.

Esto es un problema  por ejemplo si usamos una aplicación que nos permite emitir llamadas cifradas, monitorizamos el tráfico y vemos que realmente va todo cifrado, pero el servidor, que no sabemos ni dónde está ni de quién es, puede estar guardando todas las conversaciones. Por eso no es muy seguro fiarse de las Apps que hay por Internet si no las conocemos bien o no tenemos una fiabilidad de que realmente es segura.

¿Cómo podemos asegurarnos de que nadie hace un MitM en nuestra comunicación?

A pesar de que el cifrado SRTP es seguro, como he comentado antes siempre tenemos la duda de si alguien está realizando un ataque MitM y, por tanto, monitorizando o grabando nuestras conversaciones. Para saber si el canal es realmente seguro podemos usar el protocolo ZRTP. Este protocolo fue diseñado por Phil Zimmermann (creador de PGP) y describe un intercambio de claves Diffie-Hellman para el protocolo SRTP.

En realidad el tráfico va a seguir siendo SRTP, pero tras establecer la comunicación, ambos dispositivos generarán una clave compartida que deberá coincidir. Para ello se eligen dos números públicos y cada interlocutor uno secreto. Tras aplicar una fórmula matemática y realizar una serie de operaciones con los números públicos y cada uno con su secreto, deberá llegarse al mismo resultado.

La verificación será visual, es decir, cada uno de los dispositivos verá en su pantalla la clave generada y que deberá ser la misma. En otro caso, estaremos sufriendo un ataque MitM.

El uso de este protocolo no influye en las configuraciones de nuestro servidor sino que es una negociación entre los dos teléfonos.

Sistema de comunicaciones seguro

Tras toda esta charla creo que podemos sacar en claro que para establecer una comunicación segura lo mejor es tener nuestro propio sistema y no tener que fiarnos de terceros, pero si hay que usar un sistema externo, deberemos:

  • Asegurarnos de que se cifra la señalización usando TLS. Esto implica que tanto el servidor como los clientes soporten TLS.
  • Asegurarnos de que se cifra el media usando SRTP. Esto implica que tanto el servidor como los clientes soporten SRTP.
  • Asegurarnos de que sólo hay una canal y que va cifrado de extremo a extremo, sin que nadie esté en medio y que el servidor no pueda tampoco almacenar las comunicaciones. Y para ello usaremos ZRTP. Esto implica que ambos clientes soporten ZRTP.

Como posibles soluciones tenemos por ejemplo Signal (antes Red Phone) del más que conocido Moxie Marlinspike. Si echáis un vistazo al proyecto o a la descripción en el Play Store de Google, hay comentarios que te hacen pensar sobre todo esto. Me refiero a referencias al código fuente como prueba de que puedes fiarte de él y de que no se hace nada malo ni se graban las conversaciones. Y esto es debido a que, como comentaba antes, se necesita un servidor de relay para poder establecer la comunicación de audio y, evidentemente el servidor es suyo. Lo mismo que ocurre con mi proyecto. La diferencia es que Moxie ha desarrollado la App para móvil y aquí es donde tiene que convencernos de que no hay nada extraño, ya que la negociación Diffie-Hellman se realiza entre los dispositivos, en este caso desde su App, y siempre puede darse el caso de que los códigos que nos muestra por pantalla no sean los derivados de la negociación sino que hayan sido alterados. De ahí a que publique el código fuente y ponga referencias para que se pueda ver y podamos fiarnos. en cualquier caso, Moxie es de fiar, ¿no?  🙂

Para mi proyecto yo no tengo ninguna App sino que he usado Softphones gratuitos que soportan ZRTP, que no hay muchos, la verdad. Por ejemplo para Android se puede utilizar CSipSimple y para Escritorio (Linux, Mac OS X y Windows) tenemos Jitsi.

Vamos al lío

Para el proyecto he usado solamente un servidor proxy Kamailio cuya función es la de gestionar y enrutar las comuncaciones (señalización) y además usa RTPProxy como servidor media para el audio.

Los únicos datos que se piden para usar el servicio son:

  • Un nombre de usuario: será nuestro identificador en el sistema y a donde habrá que llamar para hablar contigo. Por ejemplo mi usuario es ‘pepelux’ (*)
  • Una dirección de correo electrónico: donde se enviarán los datos de registro

(*) En VoIP no es necesario llamar a un número de teléfono. Se llama a un usuario, por lo que en lugar de poner un nuestro número de teléfono, es posible poner cualquier nombre (esto es otra cosa que no me gusta del servicio de Moxie, que tienes que poner tu número de teléfono móvil real y te mandan un SMS para verificarlo).

Para darte de alta debes entrar en http://voip.pepelux.org/ … sí, lo sé, debería tener un certificado SSL, pero no me da la vida :'( … y rellenar los datos en New User. Te llegará un mail con la contraseña y un link de activación.

Con estos datos deberás configurar tu softphone para conectar con el sistema y poder hacer llamadas a otros usuarios que también se hayan dado de alta.

Configurando CSipSimple en nuestro Android

Si queremos usar CSipSimple podemos instalarlo desde el Play Store y seguir el asistente para crear una cuenta. Para ello seleccionaremos Expert dentro del asistente genérico. y rellenaremos los siguientes datos:

  • Nombre de la cuenta: Secure Call (o lo que quereamos poner ya que es una simple descripción para identificar la cuenta)
  • ID de la cuenta: TU_USER <sip:TU_USER@voip.pepelux.org>
  • URI de registro: sip:TU_USER@voip.pepelux.org:5061
  • Nombre de usuario:TU_USER
  • Contraseña:TU_PASS
  • Protocolo de transporte: TLS
  • Esquema uri por defecto: sips
  • Modo SRTP: Por defecto
  • Modo ZRTP: Crear ZRTP

Es importante para que funcione que, en los ajustes generales de la aplicación, pinchemos en Red -> Protocolo de transporte seguro y habilitar el TLS.

Configurando Jitsi

Jitsi tienes diferentes aplicaciones como el Jitsi Meet pero la que nos interesa es la de escritorio. Tenemos versiones para Windows, Linux y Mac OS X que podemos descargar aquí: https://jitsi.org/downloads/

Las opciones de seguridad para el media vienen habilitadas por defecto pero sí que deberemos especificar que en la señalización use TLS. Para ello, una vez creada la cuenta, la editaremos y cambiaremos los parámetros de conexión activando un proxy:

Otra opción sería cargar directamente el certificado en el softphone.

Si realizamos una llamada de prueba, por ejemplo desde un Jitsi a un CSipSimple, sólo debemos marcar el nombre de usuario, en este caso llamo desde un usuario ‘oficina’ configurado en el escritorio a un usuario ‘pepelux’ configurado en un Android:

Vemos que al entrar la llamada, la señalización va por TLS, por lo que viene cifrada:

Y una vez establecida la comunicación, tras descolgar, podemos comprobar la clave generada, en este caso yfmj:

En el Jitsi realizamos la misma comprobación. Por un lado, al emitir la llamada vemos que se usa ZRTP:

Y tras descolgar, al igual que en el otro extremo, debemos ver el mismo código:

Tras la comprobación de claves (donde un usuario le dirá al otro el texto que le aparece y deberá confirmarnos que es el mismo que él tiene) podemos asegurar que la llamada queda cifrada de extremo a extremo y que no hay nadie en medio.

Sobre el servicio

Este servicio es totalmente gratuito y bueno, no deja de ser un juguete que he montado para aprender y cacharrear, aunque es totalmente funcional y seguro. Como se puede ver, no se solicita ningún tipo de información para poderlo usar por lo que eres libre de utilizarlo. Si alguien tiene interés en conocer detalles más técnicos, no tiene más que preguntarme.

Y por cierto, si algún programador de dispositivos móviles se anima en hacer una App, podemos hacer un proyecto chulo 🙂

Saludos !

Protegiendo nuestro sistema de VoIP con Kamailio

 

Cuando se gestiona una centralita local, lo normal es no tener ningún tipo de puerto abierto al exterior, dado que las conexiones las realizamos siempre nosotros hacia nuestro proveedor de VoIP. A no ser que realicemos una validación por IP, con lo que deberemos permitir el acceso a nuestro puerto SIP única y exclusivamente a la IP que nos facilite nuestro(s) operador(es).

En el caso de que administremos un sistema más complejo, o simplemente, ofrezcamos servicios de VoIP a terceros, seguramente tendremos otros elementos involucrados en nuestro sistema, como servidores proxy.

En mi último post – guau! hace más de 1 año ya! – escribí sobre Kamailio y, sin despreciar a su ‘hermano’ OpenSIPS, voy a poner algunas configuraciones bastante útiles para protegernos tanto de escaneos como de ataques (fuerza bruta, DoS, …). Para ello vamos a utilizar programación en LUA, que nos permitirá dejar un poco más limpio nuestro fichero de configuración de Kamailio.

 

Evitando los molestos escáner SIP

Normalmente todos los escáner SIP utilizan un User-Agent propio por defecto. De hecho, parece mentira que el escáner más conocido, SIPVicious, esté programado en Python y la gente siga usándolo ‘sin alterar’, es decir, sin cambiar ese agente de usuario tan conocido … hablo de ‘friendly-scanner’. Por tanto, nos sobra con poner un pequeño filtro en nuestro Kamailio que busque los UA más conocidos … algo así:

route[REQINIT] {
..........

if($ua == "friendly-scanner" || $ua == "sundayddr" || $ua == "sip-scan" || $ua == "iWar" || $ua == "sipsak") {
   xlog("L_ALERT", "Attack attempt! IP:$si:$sp - R:$ruri - F:$fu - T:$tu - UA:$ua - $rm\n");
   drop();
}

..........
}

 

Lo que estamos haciendo es un drop del paquete cuando detectemos un User_agent que concuerde con un escáner SIP conocido.

 

Módulo pike + htable de Kamailio

Los módulos pikehtable de Kamailio son más que conocidos y nos permiten bloquear intentos de registro erróneos. Se puede ver toda la información en la documentación de Kamailio:

http://kamailio.org/docs/modules/stable/modules/pike.html

http://kamailio.org/docs/modules/stable/modules/htable.html

Por ejemplo, podemos definir cómo queremos que se comporte en la definición de parámetros, donde size es el número de intentos y autoexpire indica el tiempo tras el cual se libera el bloqueo:

modparam("htable", "htable", "wrongpass=>size=8;autoexpire=900")
modparam("htable", "htable", "ipban=>size=8;autoexpire=300")

 

En la ruta de autenticación comprobaremos el número de intentos erróneos y, si es superior al permitido, lo bloquearemos:

route[AUTH] {
..........

        if (is_method("REGISTER|INVITE") || from_uri==myself)
        {
                # User reached auth_count top
                if($sht(wrongpass=>$au::auth_count)==$sel(cfg_get.auth.max{s.int}))
                {
                        $var(exp) = $Ts - $sel(cfg_get.auth.bantime{s.int});

                        if ($sht(wrongpass=>$au::last_auth) > $var(exp))
                        {
                                # no more auth checks
                                xdbg("username $au $rm blocked from $proto:$si:$sp\n");
                                # we also can send a fake 200 OK reply
                                # sl_send_reply("200","OK");
                                exit;
                        } else {
                                # bantime seg reached... clean count
                                $sht(wrongpass=>$au::auth_count) = 0;
                        }
                }

                # authenticate requests
                if (!radius_www_authorize("mysip.server.com")) {
                        switch ($rc) {
                        case -7:
                           send_reply("500", "Server Internal Error");
                           exit;
                        case -2:
                                if ($sht(wrongpass=>$au::auth_count) == $null) {
                                        $sht(wrongpass=>$au::auth_count) = 0;
                                }

                                $sht(wrongpass=>$au::auth_count) = $sht(wrongpass=>$au::auth_count) + 1;

                                if ($sht(wrongpass=>$au::auth_count) == $sel(cfg_get.auth.max{s.int})) {
                                        xlog("L_ALERT","Auth failed $sel(cfg_get.auth.max) times - user:$au from $proto:$si:$sp\n");
                                }

                                $sht(wrongpass=>$au::last_auth) = $Ts;
                                break;
                        case -1:
                           send_reply("400", "Bad Request");
                           exit;
                        default:
                        };
                        if (defined($avp(digest_challenge)) &&
                                ($avp(digest_challenge) != "")) {
                                append_to_reply("$avp(digest_challenge)");
                        };
                        send_reply("401", "Unauthorized");
                        exit;
                }
                # clean
                if ($sht(wrongpass=>$au::auth_count) != $null) {
                        $sht(wrongpass=>$au::auth_count) = 0;
                }
        }

..........
}

 

Creando listas negras

A parte de estos módulos que nos ofrece Kamailio, podemos programar todo lo que se nos ocurra, gracias al enorme potencial de Kamailio. Por ejemplo, podemos crear listas negras y blancas de usuarios o de IPs para permitir o bloquear a determinadas direcciones IP o usuarios.

Por ejemplo, sirva como base la siguiente tabla de MySQL para crear listas negras de direcciones IP:

CREATE TABLE IF NOT EXISTS `black_list` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`ip` varchar(32) COLLATE utf8_spanish_ci NOT NULL,
`detail` varchar(255) COLLATE utf8_spanish_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=42 ;

Podemos utilizar los campos:

– ip: para bloquear una dirección IP
– detail: para añadir alguna observación

Desde Kamailio comprobaremos si está en la lista negra, en cuyo caso bloquearemos la petición:

route[REQINIT] {
..........

        if(src_ip!=myself)
        {
                # check if the IP is blacklisted
                lua_run("check_blacklist", "$si");
                if ($avp(s:wb_status) == "black") {
                       xlog("L_ALERT","Received $rm from a blacklisted $avp(s:wb_type)! $fU (IP:$si) - Sending Drop ...\n");
                       $sht(ipban=>$si) = 1;
                       drop();
                }
         }

..........
}

Y usando LUA programaremos la función check_blacklist

-- check blacklist
function check_blacklist(ip)
        local con, cur, row
        con = connect_ro('openser')
        cur = assert (con:execute("SELECT id FROM black_list WHERE ip='" .. ip .. "'))
        row = cur:fetch({}, "a")
        cur:close()
        con:close()
        if row then
                sr.pv.sets('$avp(wb_status)', 'black')
        else
                sr.pv.sets('$avp(wb_status)', '')
        end

        return
end

 

Al igual que bloqueamos un paquete que provenga de una determinada dirección IP, sería muy sencillo bloquear ciertos usuarios, agentes de usuario, etc.

 

Filtrado por países

Del mismo modo que bloqueamos direcciones IP, podemos realizar una comprobación del país que realiza las peticiones. Por ejemplo:

CREATE TABLE IF NOT EXISTS `black_list_country` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`country` varchar(5) COLLATE utf8_spanish_ci NOT NULL,
`detail` varchar(255) COLLATE utf8_spanish_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=42 ;

Podemos utilizar los campos:

– country: código de país a bloquear
– detail: para añadir alguna observación

Por otro lado:

CREATE TABLE IF NOT EXISTS `ipcountry` (
  `ipstart` varchar(20) NOT NULL,
  `ipend` varchar(20) NOT NULL,
  `countrycode` varchar(5) NOT NULL,
  `ipfrom` bigint(11) NOT NULL,
  `ipto` bigint(11) NOT NULL,
  KEY `ipstart` (`ipstart`,`ipend`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Donde:

– ipstart e ipend: rangos de IPs (ejemplo: 2.20.179.0 – 2.20.179.255)
– countrycode: código del país (ejemplo: ES)
– ipfrom e ipto: IPs en formato decimal (ejemplo: 34910976 – 34911231)

Podemos descargar la base de datos de IPs de aquí: http://db-ip.com/db/download/country

Y el motivo por el que meto en la base de datos las IPs en dos formatos es por temas de optimización, para no tener que calcularlas en cada consulta. Para ello, tras importar la base de datos deberemos calcular las direcciones IP en su formato decimal:

mysql> update `ipcountry` set ipfrom = INET_ATON(ipstart);
mysql> update `ipcountry` set ipto = INET_ATON(ipend);

Y desde Kamailio, para filtrar los países bloqueados, será de forma similar a lo visto antes. Comprobamos si el país está bloqueado y hacemos un drop a la vez que bloqueamos la IP:

route[REQINIT] {
..........

      lua_run("get_countrycode", "$si");
      lua_run("check_country_blacklist", "$avp(s:countryCode)");
      if ($avp(s:wb_status) == "black") {
              xlog("L_ALERT","Received $rm from a blacklisted country ($avp(s:countryCode))! $fU (IP:$si) - Sending Drop ...\n");
             $sht(ipban=>$si) = 1;
             drop();
       }

..........
}

 

En el LUA tendremos:

-- get country code from IP address
function get_countrycode(ipaddr)
        local con, cur, row
        con = connect_ro('openser')
        cur = assert (con:execute("SELECT countrycode FROM ipcountry WHERE INET_ATON('" .. ipaddr .. "') BETWEEN ipfrom AND ipto LIMIT 1"))
        row = cur:fetch({}, "a")
        cur:close()
        con:close()
        if row then
                sr.pv.sets('$avp(countryCode)', row.countrycode)
        else
                sr.pv.sets('$avp(countryCode)', '')
        end

        return
end

-- check countries blacklisted
function check_country_blacklist(country)
        local con, cur, row
        con = connect_ro('openser')
        cur = assert (con:execute("SELECT id FROM black_list_country WHERE country='" .. country .. "'"))
        row = cur:fetch({}, "a")
        cur:close()
        con:close()
        if row then
                sr.pv.sets('$avp(wb_status)', 'black')
        else
                sr.pv.sets('$avp(wb_status)', '')
        end

        return
end

 

Si lo ejecutamos bloqueando IPs españolas obtendremos algo así:

Jul 30 20:44:51 sip /usr/sbin/kamailio[1672]: ALERT: <script>: Received REGISTER from a blacklisted country (ES)! user1 (IP:62.xx.xx.xx) - Sending Drop ...
Jul 30 20:44:52 sip /usr/sbin/kamailio[1672]: ALERT: <script>: Received REGISTER from a blacklisted country (ES)! user2 (IP:62.xx.xx.xx) - Sending Drop ...
Jul 30 20:44:53 sip /usr/sbin/kamailio[1674]: ALERT: <script>: Received REGISTER from a blacklisted country (ES)! user3 (IP:83.xx.xx.xx) - Sending Drop ...
Jul 30 20:44:53 sip /usr/sbin/kamailio[1672]: ALERT: <script>: Received REGISTER from a blacklisted country (ES)! user4 (IP:83.xx.xx.xx) - Sending Drop ...
Jul 30 20:44:53 sip /usr/sbin/kamailio[1693]: ALERT: <script>: Received REGISTER from a blacklisted country (ES)! user5 (IP:62.xx.xx.xx) - Sending Drop ...

 

De lectura obligatoria:
http://www.kamailio.org/wiki/tutorials/security/kamailio-security

 

Creando un honeypot con Kamailio

Kamailio es un proxy SIP derivado de un proyecto anterior llamado OpenSER. A parte de ser Open Source, es una magnífica herramienta, indispensable si deseas montar un sistema de VoIP medianamente grande, es decir, llegando más allá de las típicas centralitas Asterisk, FreeSwitch o similares que nos permiten gestionar una oficina con X extensiones.

Aprovecho para mandar un saludo a mi compañero Victor Seva (@linuxmaniac) que desde hace poco pertenece al equipo de desarrolladores de Kamailio. 😉

Como comentaba, un proxy SIP nos permite realizar muchísimas cosas, como validar usuarios, reenviar el tráfico a servidores SIP, gestionar llamadas, etc. En este caso lo vamos a utilizar con las mínimas opciones. Simplemente le permitiremos recibir y emitir llamadas, pero con alguna que otra peculiaridad. Nuestra finalidad será la de controlar los escanéos que nos hagan e interceptar todas las llamadas que intenten realizarse a través del sistema, es decir, colocar un honeypot para cazar listillos.

Evidentemente para entender todo esto hay que tener unos mínimos conocimientos de SIP. Si quieres instalar un Kamailio, puedes consultar la documentación aquí: http://www.kamailio.org/wiki/

En primer lugar vamos a editar el fichero kamailio.cfg y vamos a añadir a la ruta REQINIT lo siguiente:


if($ua == "friendly-scanner" || $ua == "sundayddr" || $ua == "sip-scan" || $ua == "iWar" || $ua == "sipsak") {
 xlog("L_ALERT", "Attack attempt! IP:$si:$sp - R:$ruri - F:$fu - T:$tu - UA:$ua - $rm\n");
}

Lo que conseguimos con esto es que nos alerte ante un escaneo usando los programas típicos. Por ejemplo, con SIPVicious:


$ python svmap.py 192.168.2.18

| SIP Device | User Agent | Fingerprint |
---------------------------------------------------------------------
| 192.168.2.18:5060 | kamailio (4.0.1 (x86_64/linux)) | disabled |

En el log del sistema (/var/log/kamailio) vemos esto:


ALERT: <script>: Attack attempt! IP:192.168.2.10:5060 - R:sip:100@192.168.2.18 -
 F:sip:100@1.1.1.1 - T:sip:100@1.1.1.1 - UA:friendly-scanner - OPTIONS

De esta forma nos enteraremos enseguida si alguien nos realiza un escaneo con svmap. De todas formas, siempre viene bien ocultar nuestra versión de kamailio. así que en el fichero de configuración añadiremos:


####### Global Parameters #########
user_agent_header="User-Agent: kamailio 1.0"
server_header="User-Agent: kamailio 1.0"

Y si repetimos la búsqueda:


$ python svmap.py 192.168.2.18

| SIP Device        | User Agent   | Fingerprint |
--------------------------------------------------
| 192.168.2.18:5060 | kamailio 1.0 | disabled    |

Una vez que somos capaces de detectar los escaneos, vamos a jugar un poco con el atacante. Lo primero de todo, le vamos a permitir registrarse en nuestro sistema con cualquier usuario y con cualquier contraseña. Para ello, en la ruta REQINIT añadiremos:


if (is_method("REGISTER")) {
	xlog("L_INFO", "Get Register for user $fU (IP: $si)\n");

	# aceptamos todas las peticiones de registro sin verificar la contraseña
	sl_send_reply("200","OK");
}

Lo que hacemos con esto es permitir el registro de cualquier usuario con cualquier contraseña. Para ello responderemos con un ‘200 OK’, permitiéndoles siempre registrarse.

Si pasamos svcrack podemos ver que siempre ‘descubre’ la contraseña de cualquier usuario:


$ python svcrack.py -u100 -r1-100 -z4 192.168.2.18

| Extension | Password      |
-----------------------------
| 100       | [no password] |

$ python svcrack.py -u324324243 -r1-100 -z4 192.168.2.18

| Extension | Password      |
-----------------------------
| 324324243 | [no password] |

El motivo por el que dice que no tiene contraseña es porque SIPVicious lo primero que prueba ante un ataque por fuerza bruta, es la contraseña vacía.

Si intentamos registrar un teléfono, veremos que se conecta sin problemas. Y en el log aparecerá algo así:


INFO: <script>: Get Register for user pepelux (IP: 192.168.2.16)
INFO: <script>: Get Register for user 200 (IP: 192.168.2.17)

Tras esto, vamos a registrarnos con el usuario 100 (por ejemplo) y lo que haremos será desviar todas las llamadas hacia nosotros. En la ruta REQINIT añadimos:


if (is_method("INVITE")) {
	xlog("L_INFO", "$fU is trying to call to $rU\n");
	$rU = "100"; # siempre nos llamará a nosotros
	xlog("L_INFO", "Sending call to $rU\n");
}

Y cuando se intente realizar una llamada a cualquier número nos sonará a nosotros:


INFO: <script>: pepelux (with IP:192.168.2.16) is trying to call to 666666666
INFO: <script>: Sending call to 100

INFO: <script>: 200 (with IP:192.168.2.17) is trying to call to 123456
INFO: <script>: Sending call to 100

¿Qué tal si en lugar de desviar la llamada a la extensión 100 la desviamos al número 091? 🙂

Y el fichero completo (kamailio.cfg) que he usado para las pruebas:

 


#!KAMAILIO
####### Include Local Config If Exists #########
import_file "kamailio-local.cfg"

####### Defined Values #########
#!define FLT_ACC 1
#!define FLT_ACCMISSED 2
#!define FLT_ACCFAILED 3
#!define FLT_NATS 5
#!define FLB_NATB 6
#!define FLB_NATSIPPING 7

####### Global Parameters #########
user_agent_header="User-Agent: kamailio 1.0"
server_header="User-Agent: kamailio 1.0"

### LOG Levels: 3=DBG, 2=INFO, 1=NOTICE, 0=WARN, -1=ERR
#!ifdef WITH_DEBUG
debug=4
log_stderror=yes
#!else
debug=2
log_stderror=no
#!endif

memdbg=5
memlog=5
log_facility=LOG_LOCAL0
fork=yes
children=4
port=5060
tcp_connection_lifetime=3605

####### Modules Section ########
# set paths to location of modules (to sources or installation folders)
#!ifdef WITH_SRCPATH
mpath="modules_k:modules"
#!else
mpath="/usr/local/lib/kamailio/modules_k/:/usr/local/lib64/kamailio/modules/"
#!endif

#!ifdef WITH_MYSQL
loadmodule "db_mysql.so"
#!endif

loadmodule "mi_fifo.so"
loadmodule "kex.so"
loadmodule "corex.so"
loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "sl.so"
loadmodule "rr.so"
loadmodule "pv.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "textops.so"
loadmodule "siputils.so"
loadmodule "xlog.so"
loadmodule "sanity.so"
loadmodule "ctl.so"
loadmodule "cfg_rpc.so"
loadmodule "mi_rpc.so"
loadmodule "acc.so"

# ----------------- setting module-specific parameters ---------------
# ----- mi_fifo params -----
modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")

# ----- tm params -----
# auto-discard branches from previous serial forking leg
modparam("tm", "failure_reply_mode", 3)
# default retransmission timeout: 30sec
modparam("tm", "fr_timer", 30000)
# default invite retransmission timeout after 1xx: 120sec
modparam("tm", "fr_inv_timer", 120000)

# ----- rr params -----
# add value to ;lr param to cope with most of the UAs
modparam("rr", "enable_full_lr", 1)
# do not append from tag to the RR (no need for this script)
modparam("rr", "append_fromtag", 0)

# ----- registrar params -----
modparam("registrar", "method_filtering", 1)
/* uncomment the next line to disable parallel forking via location */
# modparam("registrar", "append_branches", 0)
/* uncomment the next line not to allow more than 10 contacts per AOR */
#modparam("registrar", "max_contacts", 10)
# max value for expires of registrations
modparam("registrar", "max_expires", 3600)
# set it to 1 to enable GRUU
modparam("registrar", "gruu_enabled", 0)

# ----- acc params -----
/* what special events should be accounted ? */
modparam("acc", "early_media", 0)
modparam("acc", "report_ack", 0)
modparam("acc", "report_cancels", 0)
/* by default ww do not adjust the direct of the sequential requests.
   if you enable this parameter, be sure the enable "append_fromtag"
   in "rr" module */
modparam("acc", "detect_direction", 0)
/* account triggers (flags) */
modparam("acc", "log_flag", FLT_ACC)
modparam("acc", "log_missed_flag", FLT_ACCMISSED)
modparam("acc", "log_extra", 
	"src_user=$fU;src_domain=$fd;src_ip=$si;"
	"dst_ouser=$tU;dst_user=$rU;dst_domain=$rd")
modparam("acc", "failed_transaction_flag", FLT_ACCFAILED)
/* enhanced DB accounting */

####### Routing Logic ########
# Main SIP request routing logic
# - processing of any incoming SIP request starts with this route
# - note: this is the same as route { ... }
request_route {
	# per request initial checks
	route(REQINIT);

	# NAT detection
	route(NATDETECT);

	# CANCEL processing
	if (is_method("CANCEL"))
	{
		if (t_check_trans()) {
			route(RELAY);
		}
		exit;
	}

	# handle requests within SIP dialogs
	route(WITHINDLG);

	### only initial requests (no To tag)
	t_check_trans();

	# record routing for dialog forming requests (in case they are routed)
	# - remove preloaded route headers
	remove_hf("Route");
	if (is_method("INVITE|SUBSCRIBE"))
		record_route();

	# dispatch requests to foreign domains
	route(SIPOUT);

	# handle registrations
	route(REGISTRAR);

	if ($rU==$null)
	{
		# request with no Username in RURI
		sl_send_reply("484","Address Incomplete");
		exit;
	}

	# user location service
	route(LOCATION);
}

route[RELAY] {
	# enable additional event routes for forwarded requests
	# - serial forking, RTP relaying handling, a.s.o.
	if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
		if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
	}
	if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
		if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
	}
	if (is_method("INVITE")) {
		if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE");
	}

	if (!t_relay()) {
		sl_reply_error();
	}
	exit;
}

# Per SIP request initial checks
route[REQINIT] {
        # Si detectamos el User-Agent de un escáner conocido, mostramos una alerta
        if($ua == "friendly-scanner" || $ua == "sundayddr" || $ua == "sip-scan" || $ua == "iWar" || $ua == "sipsak") {
                xlog("L_ALERT", "Attack attempt! IP:$si:$sp - R:$ruri - F:$fu - T:$tu - UA:$ua - $rm\n");
        }

        # Al recibir un intento de registro, devolvemos siempre un OK
	if (is_method("REGISTER")) {
		xlog("L_INFO", "Get Register for user $fU (IP: $si)\n");

		if ($fU != "100")
			sl_send_reply("200","OK");
	}

        # Al recibir un intento de llamada, modificamos el destino para que siempre llame a la extensión 100
	if (is_method("INVITE")) {
		xlog("L_INFO", "$fU (with IP:$si) is trying to call to $rU\n");
		$rU = "100";
		xlog("L_INFO", "Sending call to $rU\n");
	}

	if (!mf_process_maxfwd_header("10")) {
		sl_send_reply("483","Too Many Hops");
		exit;
	}

	if(!sanity_check("1511", "7"))
	{
		xlog("Malformed SIP message from $si:$sp\n");
		exit;
	}
}

# Handle requests within SIP dialogs
route[WITHINDLG] {
	if (has_totag()) {
		# sequential request withing a dialog should
		# take the path determined by record-routing
		if (loose_route()) {
			route(DLGURI);
			if (is_method("BYE")) {
				setflag(FLT_ACC); # do accounting ...
				setflag(FLT_ACCFAILED); # ... even if the transaction fails
			}
			else if ( is_method("ACK") ) {
				# ACK is forwarded statelessy
				route(NATMANAGE);
			}
			else if ( is_method("NOTIFY") ) {
				# Add Record-Route for in-dialog NOTIFY as per RFC 6665.
				record_route();
			}
			route(RELAY);
		} else {
			if (is_method("SUBSCRIBE") && uri == myself) {
				# in-dialog subscribe requests
				exit;
			}
			if ( is_method("ACK") ) {
				if ( t_check_trans() ) {
					# no loose-route, but stateful ACK;
					# must be an ACK after a 487
					# or e.g. 404 from upstream server
					route(RELAY);
					exit;
				} else {
					# ACK without matching transaction ... ignore and discard
					exit;
				}
			}
			sl_send_reply("404","Not here");
		}
		exit;
	}
}

# Handle SIP registrations
route[REGISTRAR] {
	if (is_method("REGISTER"))
	{
		if(isflagset(FLT_NATS))
		{
			setbflag(FLB_NATB);
			# uncomment next line to do SIP NAT pinging 
			## setbflag(FLB_NATSIPPING);
		}
		if (!save("location"))
			sl_reply_error();

		exit;
	}
}

# USER location service
route[LOCATION] {
	$avp(oexten) = $rU;
	if (!lookup("location")) {
		$var(rc) = $rc;
		t_newtran();
		switch ($var(rc)) {
			case -1:
			case -3:
				send_reply("404", "Not Found");
				exit;
			case -2:
				send_reply("405", "Method Not Allowed");
				exit;
		}
	}

	# when routing via usrloc, log the missed calls also
	if (is_method("INVITE"))
	{
		setflag(FLT_ACCMISSED);
	}

	route(RELAY);
	exit;
}

# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
	force_rport();
	if (nat_uac_test("19")) {
		if (is_method("REGISTER")) {
			fix_nated_register();
		} else {
			add_contact_alias();
		}
		setflag(FLT_NATS);
	}
#!endif
	return;
}

# RTPProxy control
route[NATMANAGE] {
#!ifdef WITH_NAT
	if (is_request()) {
		if(has_totag()) {
			if(check_route_param("nat=yes")) {
				setbflag(FLB_NATB);
			}
		}
	}
	if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
		return;

	rtpproxy_manage();

	if (is_request()) {
		if (!has_totag()) {
			add_rr_param(";nat=yes");
		}
	}
	if (is_reply()) {
		if(isbflagset(FLB_NATB)) {
			add_contact_alias();
		}
	}
#!endif
	return;
}

# URI update for dialog requests
route[DLGURI] {
#!ifdef WITH_NAT
	if(!isdsturiset()) {
		handle_ruri_alias();
	}
#!endif
	return;
}

# Routing to foreign domains
route[SIPOUT] {
	if (!uri==myself)
	{
		append_hf("P-hint: outbound\r\n");
		route(RELAY);
	}
}

# manage outgoing branches
branch_route[MANAGE_BRANCH] {
	xdbg("new branch [$T_branch_idx] to $ru\n");
	route(NATMANAGE);
}

# manage incoming replies
onreply_route[MANAGE_REPLY] {
	xdbg("incoming reply\n");
	if(status=~"[12][0-9][0-9]")
		route(NATMANAGE);
}

# manage failure routing cases
failure_route[MANAGE_FAILURE] {
	route(NATMANAGE);

	if (t_is_canceled()) {
		exit;
	}
}

 

Saludos