Capítulo 4. Certificados para la seguridad de los puntos finales
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Sólo hay que tener suerte una vez. Hay que tener suerte siempre.
El IRA a Margaret Thatcher, tras un intento fallido de asesinato
Si realmente quieres hacer algo, encontrarás la manera. Si no, encontrarás una excusa.
Jim Rohn
La inconveniencia de la seguridad
VoIP La seguridad puede considerarse como dos retos distintos (pero interconectados):
Asegurar un sistema contra el fraude de peaje (que suele ser el objetivo de los intentos de intrusión basados en SIP)
Asegurar un sistema contra la interceptación de llamadas (que se relaciona con la privacidad, así como con la mejora de las defensas contra el fraude de peaje).
Por supuesto, hay muchos otros aspectos de la seguridad de tu sistema, pero la mayoría son conceptos generales de seguridad, no específicos de la VoIP.
En este capítulo nos centraremos en un área de la seguridad que con demasiada frecuencia se pasa por alto, a saber, la generación y aplicación de certificados y claves para asegurar la comunicación entre los puntos finales y tu sistema. En las comunicaciones SIP, el cifrado es opcional (y, por desgracia, no se utiliza la mayoría de las veces). En WebRTC, es obligatorio.
Este capítulo no debe considerarse en absoluto la última palabra sobre la seguridad de tu sistema Asterisk; en el Capítulo 22 se tratarán otros temas. Sin embargo, esperamos que te proporcione una base sólida sobre la que construir una solución segura.
Asegurar el SIP
Si construyes cualquier tipo de servidor que esté expuesto a Internet, y esperas unas pocas horas después de encenderlo, te darás cuenta de que el sistema ya habrá atraído sondas que intentan determinar si tiene algún servicio SIP vulnerable. Entonces notarás, poco después, una cantidad creciente de ataques al servidor que intentan comprometer la seguridad de la cuenta. Enhorabuena, tu servidor se ha añadido automáticamente a las listas de servidores SIP compartidos por delincuentes con fines de fraude. Si una de estas intrusiones tiene éxito, la plataforma comprometida probablemente pasará a formar parte de una red de delincuencia organizada, y tú pagarás la factura de llamadas imposibles de rastrear a diversos destinos caros.
Advertencia
No estamos jugando; no te tomes a la ligera tu seguridad SIP o es probable que seas víctima de un ataque fraudulento muy caro.
Nombres de los suscriptores
La parte del abonado de las credenciales SIP (la parte userinfo del URI) se establece con demasiada frecuencia en un número de extensión. Esta práctica está bien para direccionar llamadas, pero no se recomienda en absoluto para autenticar un punto final. El nombre de abonado de tus terminales no debe tener ningún significado fuera de tu organización. Una dirección MAC es perfecta para esto. Sin una dirección real que sondear, el trabajo de un atacante se ha vuelto mucho más difícil.
Verás muchas centralitas de tipo SIP (incluidas muchas basadas en Asterisk, por desgracia) que asignan el número de extensión a las credenciales del teléfono. En este libro, verás que el número de extensión no forma parte de las credenciales del teléfono. Esto tiene varias ventajas, pero desde el punto de vista de la seguridad, la ventaja es que si un atacante conoce una extensión, no le proporciona ningún conocimiento sobre cómo autenticar una llamada a través del sistema.
Así, puedes tener un usuario con la dirección SIP 100@shifteight.org, que tu sistema Asterisk asociará con el dispositivo en 0000f3101010@yourpbx.com. Cuando una llamada se dirija a 100, sonará 0000f3101010, pero la persona que llama nunca sabrá nada sobre ese punto final.
Verás a lo largo de este libro que estableceremos una relación entre una extensión (que creemos que es algo que debe asociarse a un usuario o servicio) con un identificador de dispositivo (que podría ser un dispositivo SIP o un número de teléfono), y que se puede utilizar una simple tabla para vincularlos (y aumentar así tanto la seguridad como la flexibilidad).
Señalización SIP segura
Por defecto, la mensajería SIP se transmite en claro, sin ninguna seguridad efectiva. Un ataque de intermediario es capaz de obtener todo tipo de información sobre tus llamadas. La seguridad de la capa de transporte (TLS) se utiliza para minimizar este riesgo.
Hablaremos más sobre cómo configurar los dispositivos para que utilicen TLS en el próximo capítulo. Todo lo que tenemos que hacer aquí es crear los certificados.
Hay tres formas habituales de generar certificados. Daremos ejemplos de dos de ellas (autofirmado y LetsEncrypt), pero dejaremos al lector el ejercicio de obtener certificados emitidos formalmente.
Certificados autofirmados
La principal ventaja de un certificado autofirmado es que no tienes que validarlo con ninguna entidad externa. La desventaja es que, por ello, las entidades externas no confiarán en él.
Si proteges los dispositivos SIP sólo para utilizarlos dentro de tu entorno de red controlado, un certificado autofirmado puede ser todo lo que necesites. No se considera el mejor enfoque, pero en algunos casos puede ser suficiente, y generalmente es mejor que nada.
En este mundo lleno de delincuencia automatizada, hay mucho que aprender sobre privacidad y seguridad, y sobre la criptografía necesaria para ambas. Sin embargo, éste es un libro sobre Asterisk, así que lo que vamos a hacer es proporcionar una plantilla para generar los componentes necesarios, y te tocará a ti investigar más.
El kit de herramientas openssl proporciona una herramienta que nos hará el trabajo. La ejecutaremos como sigue:
$ sudo su asterisk - $ mkdir /home/asterisk/certs $ openssl req -x509 -nodes -newkey rsa:2048 -days 3650 \ -keyout /home/asterisk/certs/self-signed.key \ -out /home/asterisk/certs/self-signed.crt
Se te pedirá que proporciones alguna información y, a continuación, tu clave y tu certificado se escribirán en la carpeta /home/asterisk/certs.
Puedes añadir lo siguiente al comando para evitar las preguntas (cambia la información según convenga a tu situación):
-subj "/C=CA/ST=Ontario/L=Toronto/O=ShiftEight/CN=shifteight.org"
El comando completo debería ser algo parecido a esto:
$ openssl req -x509 -nodes -newkey rsa:2048 -days 3650 \ > -keyout /home/asterisk/certs/self-signed.key \ > -out /home/asterisk/certs/self-signed.crt \ > -subj "/C=CA/ST=Ontario/L=Toronto/O=ShiftEight/CN=shifteight.org"
Esto generará un certificado autofirmado y una clave privada, y los guardará ambos en /home/asterisk/certs/. Podremos utilizarlos más adelante cuando configuremos nuestros puntos finales SIP.
Probablemente sea una buena idea chmod tus certificados para que sólo el usuario/grupo pertinente pueda acceder a ellos:
$ chmod 640 /home/asterisk/certs/*
Sal de la cuenta de usuario asterisk.
$ exit $ who am i # You should be astmin again.
Hay una alternativa al uso de certificados autofirmados: si tienes un nombre de dominio asignado a tu servidor al que se puede acceder desde la Internet pública, puedes generar un certificado validado utilizando LetsEncrypt. Sigue leyendo.
Certificados LetsEncrypt
Si te interesan las comunicaciones seguras de a través de la Internet pública (y te interesan, créenos), entonces es útil disponer de certificados de dominio proporcionados por una autoridad de certificación (CA).
El proyecto LetsEncrypt proporciona certificados digitales de validación de dominio (DV) gratuitos. La herramienta gratuita proporcionada por la Fundación Let's Encrypt llamada certbot te permite automatizar la obtención y el mantenimiento de certificados de confianza.
Como mínimo, tu servidor necesitará un nombre de dominio totalmente cualificado (FQDN) que mapee a una dirección IP externa que llegue a la máquina. Cualquier cortafuegos intermedio tendrá que pasar el tráfico de ese nombre de host al sistema para el que estás obteniendo el certificado. Si no puedes hacerlo por cualquier motivo, la obtención de un certificado de confianza se vuelve más compleja (y queda fuera del alcance de este libro).
certbot se puede instalar con de la siguiente manera: yum
$ sudo yum -y install certbot
Una vez instalado, sólo tienes que ejecutar lo siguiente:
$ sudo certbot certonly How would you like to authenticate with the ACME CA? ------------------------------------------------------------------------------- 1: Spin up a temporary webserver (standalone) 2: Place files in webroot directory (webroot) ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Si tienes un servidor web en funcionamiento, o estás seguro con la opción 2, está bien, pero estos pasos asumen que no tienes un servidor web en funcionamiento, y por lo tanto necesitarás/querrás utilizar el servidor web temporal incorporado que certbot utilizará para autenticarse. Este servidor se utiliza para demostrar que controlas el dominio para el que solicitas un certificado.
Responde a las siguientes preguntas según corresponda, y en este punto introducirás el nombre de host que asignaste a la dirección IP de tu servidor:
Please enter in your domain name(s) (comma and/or space separated) (Enter 'c'
to cancel): asteriskbook.shifteight.org(sustituye asteriskbook.shifteight.org por el nombre de dominio que asignaste).
certbot hará su magia, y si todo ha ido bien deberías recibir algún tipo de mensaje similar al siguiente:
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/asteriskbook.shifteight.org/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/asteriskbook.shifteight.org/privkey.pem Your cert will expire on 2018-07-23. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
Ya tienes los certificados que necesitarás para habilitar varios servicios TLS en tu sistema. Los pondremos en práctica en el próximo capítulo.
No es muy difícil, ¿eh?
Nota
Ten en cuenta que la mayoría de los certificados que obtengas de una fuente externa tendrán una fecha de caducidad. En el caso de LetsEncrypt, la validez actual es de tres meses. Si vas a poner certificados en producción, de ti depende saber cómo gestionarlos (por ejemplo, automatizando la renovación, algo que la gente de LetsEncrypt ha hecho un buen trabajo simplificando).
Adquirir certificados de una autoridad de certificación formal
Si los certificados de LetsEncrypt no proporcionan el nivel de validación que necesitas -por ejemplo, si necesitas validación de organización (OV) o validación ampliada (EV)-, tendrás que obtener los servicios de una autoridad de certificación que proporcione tales cosas. Estas cuestiones quedan fuera del alcance de este libro.
Si has trabajado con los ejemplos de las secciones autofirmado y LetsEncrypt, tendrás al menos una comprensión básica del proceso de obtención de certificados de una autoridad de certificación, ya que muchos de los pasos serán similares.
Proteger los medios de comunicación
Los certificados que hemos obtenido pueden utilizarse para asegurar tanto nuestra señalización como la propia carga útil (es decir, lo que se habla o el vídeo que se transmite). Ten en cuenta que los mecanismos para asegurar la señalización son cosa del protocolo SIP, y los mecanismos para asegurar los medios son cosa del protocolo RTP. Ten en cuenta que encriptar tu señalización SIP no significa que automáticamente estés encriptando también tu tráfico multimedia (RTP).
RTP encriptado
Cifrar el Protocolo en Tiempo Real conseguirá el efecto de asegurar nuestros flujos de medios.
Hay dos mecanismos utilizados habitualmente para proporcionar encriptación de medios: SDES y DTLS-SRTP. SDES es un mecanismo de encriptación de medios que confía en que la señalización es segura. En otras palabras, si utilizas TLS para proteger tu señalización SIP, es probable que SDES sea la forma en que se gestiona el cifrado de los medios.
DTLS-SRTP, en cambio, no confía en la señalización. Es importante porque la norma WebRTC exige que los medios se cifren de esta forma.
Los certificados que hemos generado aquí deberían funcionar en ambos escenarios. En próximos capítulos, cuando configuremos puntos finales SIP o WebRTC, veremos con más detalle cómo utilizar los certificados. Por ahora, basta con que hayamos generado los certificados y los tengamos disponibles para su uso.
Conclusión
No te equivoques: la seguridad lo complica todo. En los viejos tiempos, podías iniciar una conexión SIP con media docena de líneas de configuración y listo. Eso ya no funciona, y aunque ese tipo de configuración seguirá funcionando (simplemente utiliza UDP en lugar de TLS, y todo lo que necesitas es una contraseña), hemos decidido que a partir de esta edición, todos los ejemplos de configuración elegirán opciones más seguras siempre que sea posible. No pretendemos presentar la última palabra en seguridad VoIP, pero vamos a ofrecer ejemplos que presten más que palabrería al concepto.
A continuación, veremos cómo configurar puntos finales en tu sistema Asterisk (utilizando las claves y certificados que acabamos de generar).
Get Asterisco: La Guía Definitiva, 5ª Edición now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
