Conexión SSH entre Asterisk y los servidores de la red corporativa

Hasta este punto queda claro como se obtiene el acceso desde la red pública de abonados al servidor Asterisk, donde juegan un rol primordial la TDA200 y la Mediatrix 1124. Sin embargo para que el proceso termine en la ejecución de comandos en un servidor de la red, se hace imprescindible una conexión remota entre este último y Asterisk. Para esta función se emplea el protocolo de administración remota SSH.

2.5.1 Intérprete de órdenes seguras

SSH es el nombre de un protocolo y del programa que lo implementa, se utiliza para acceder a máquinas remotas a través de la red IP. Permite manejar por completo la computadora mediante un intérprete de comandos, y también puede redirigir el tráfico para ejecutar programas gráficos.

Además de la conexión a otros dispositivos, SSH permite copiar datos de forma segura, tanto ficheros independientes como simular sesiones FTP cifradas, gestionar claves RSA (Rivest, Shamir y Adleman, sistema criptográfico de clave pública) para omitir el uso de contraseñas en el momento de la conexión a los dispositivos, y pasar los datos de cualquier otra aplicación por un canal seguro tunelizado mediante SSH.

Ofrece una consola en el ordenador remoto con los privilegios que tiene la cuenta con la que se realiza la conexión. SSH trabaja de forma similar a como se hace con telnet. La diferencia principal es que usa técnicas de cifrado, que hacen que la información que viaja por el medio de comunicación sea ilegible a terceras personas que intenten comprometer el canal. (Daniel J. Barrett 2005)

2.5.2 Características de SSH

El protocolo SSH proporciona los siguientes tipos de protección:

• Se transmite la información de autenticación al servidor usando una encriptación robusta de 128 bits.

• Todos los datos enviados y recibidos durante la sesión se transfieren por medio de encriptación de 128 bits, lo cual los hacen extremamente difícil de descifrar y leer.

• Posibilita reenviar aplicaciones X11 desde el servidor. Esta técnica, llamada reenvío por X11, proporciona un medio seguro para usar aplicaciones gráficas sobre una red.

• Ya que el protocolo SSH encripta todo lo que envía y recibe, se puede usar para asegurar protocolos inseguros. Es decir, puede convertirse en un conducto o túnel por donde se envían los datos de los protocolos inseguros, mediante el uso de una técnica llamada reenvío por puerto.

2.5.3 ¿Por qué SSH?

Existen una variedad de herramientas que permite interceptar y redirigir el tráfico de la red para ganar acceso al sistema por terceras entidades. En términos generales, estas amenazas se pueden catalogar del siguiente modo:

 Intercepción de la comunicación entre dos sistemas: En este escenario, existe un tercero en algún lugar de la red entre entidades en comunicación que hace una copia de la información que pasa entre ellas. La parte interceptora puede obtener y conservar la información, o puede modificarla y luego enviarla al recipiente al cual estaba destinada. Este ataque se puede efectuar a través del uso de un sniffer.

 Personificación de un determinado host: Con esta estrategia, un sistema interceptor finge ser el recipiente a quien está destinado un mensaje. Si funciona, el sistema del usuario no se percata del engaño y continúa la comunicación con el host incorrecto. Lo cual se produce con técnicas de suplantación de identidad.

Si se utiliza SSH para inicios de sesión de shell remota y para la transferencia de archivos, se pueden disminuir notablemente estas amenazas a la seguridad. Debido a que el cliente SSH y el servidor usan firmas digitales para verificar sus identidades y adicionalmente, encripta toda la comunicación entre los sistemas cliente y servidor. (Medina 2005)

2.5.4 Conexión SSH sin contraseña

Como se había hecho referencia anteriormente, SSH permite realizar conexiones sin la necesidad de la introducción manual de contraseñas. Esto es gracias al uso de llaves públicas y privadas. En este proyecto se explota esta característica del protocolo, debido a que el servidor Asterisk necesita ejecutar comandos remotos sin la intervención directa del

usuario sobre la interfaz de línea de comandos. Para garantizar que este mecanismo funcione, y a la vez que sea seguro, se necesita generar un par de llaves digitales destinadas al cifrado del canal de comunicación.

Para el uso de llaves públicas, en primer lugar debe configurarse el servidor de SSH para que las acepte. Habitualmente los archivos de configuración de “OpenSSH” se ubican en la carpeta “/etc/ssh”, en este caso, el archivo que interesa es /etc/ssh/sshd_config. Usando un editor de textos se puede fijar los valores de las opciones relacionadas con las llaves públicas:

#RSAAuthentication yes PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

La primera opción indica que se permite la autenticación RSA. La cual está habilitada por defecto, y en este caso se deshabilita porque solamente vale para la versión 1 del protocolo. La segunda opción especifica si se puede usar llaves públicas para demostrar la autenticidad de un usuario. Si el valor es no, entonces el uso de llaves públicas queda prohibido. La tercera opción define el archivo que contiene las llaves públicas empleadas para la autenticación de los usuarios. Una vez fijado los valores es necesario reiniciar el servicio SSH para que los cambios surtan efecto.

Posteriormente se crean el par de llaves en el servidor Asterisk mediante la aplicación ssh- keygen. Esta herramienta puede generar llaves RSA para el protocolo SSH versión 1, cuyo uso no es el más recomendable, y por otro lado, también puede generar llaves RSA o DSA para el protocolo SSH versión 2. La forma de especificar el tipo de llave a usar, es a través del parámetro -t seguido de "rsa" o "dsa" según corresponda. Por ejemplo, para crear una llave RSA se debe poner:

ssh-keygen –t rsa

Después de haberlas creado, es necesario realizar la distribución de la llave pública hacia todos los servidores con los cuales Asterisk se va a comunicar. Esto se logra añadiéndola a los contenedores correspondientes, normalmente ubicados en el directorio personal del usuario en el fichero “ssh/authorized_keys”. Por otro lado, la llave privada debe mantenerse

secreta. Por defecto ssh-keygen establece los permisos del archivo con esta llave para que sólo el dueño pueda leerla y modificarla.