-
Configuración OpenSSH en dispositivos iPhone (1 de 4)
-
Configuración OpenSSH en dispositivos iPhone (2 de 4)
-
Configuración OpenSSH en dispositivos iPhone (3 de 4)
-
Configuración OpenSSH en dispositivos iPhone (4 de 4)
========================================================================
Este último post de la serie sobre la fortificación del servidor OpenSSH en los dispositivos iPhone/iPad/iPod Touch se centra en el uso de certificados digitales tanto para autenticar al servidor, como para configurar un canal cifrado seguro o autenticar a los usuarios para evitar el uso de contraseñas.
Claves RSA
Cuando en este artículo se hace referencia a una clave
RSA se ha de tener presente que se refiere a un par de claves pública y privada utilizadas en los sistemas criptográficos de cifrado asimétrico. La pública es la parte de la clave RSA que puede ser conocida por todos mientras que la parte privada debe estar bien almacenada con seguridad mediante permisos estrictos y debe transmitirse siempre por canales seguros que no puedan ser interceptados.
Generación de la clave de Host
Por defecto, nada más instalarse el servidor
OpenSSH en el dispositivo, se crea un par de claves RSA, es decir, una parte pública y una parte privada para identificar al servidor y que el cliente pueda autenticar su veracidad. Este par de claves son autofirmadas, es decir, no están creadas por ninguna entidad certificadora conocida, y se almacenan en la siguiente ruta:
/etc/ssh.
Dentro de ese directorio se crean tres pares de claves para diferentes usos:
- ssh_host_key: parte privada de la clave RSA para la versión 1 del protocolo SSH. Se desaconseja el uso de la versión 1 del protocolo SSH ya que éste fue roto.
- ssh_host_key.pub: parte pública de la clave RSA para la versión 1 del protocolo SSH.
- ssh_host_rsa_key: parte privada de la clave RSA para la versión 2 del protocolo SSH. Es la que OpenSSH utiliza por defecto.
- ssh_host_rsa_key.pub: parte pública de la clave RSA para la versión 2 del protocolo SSH.
- ssh_host_dsa_key: parte privada de la clave DSA. Es la alternativa a RSA.
- ssh_host_dsa_key.pub: parte pública de la clave DSA.
Por defecto, como se puede observar en el fichero sshd_config, la última versión de OpenSSH utiliza las claves, pública y privada, RSA para la versión 2.
Algoritmos de cifrado utilizados en las distintas versiones de SSH
Dependiendo de la versión del protocolo que se esté utilizando, el protocolo soportará unos algoritmos u otros. En la versión 1 del protocolo se disponen los siguientes algoritmos de cifrado: DES, 3DES, IDEA, Blowfish. Mientras que para la versión 2 del protocolo se aumentaron el número de algoritmos disponibles y se incluyeron algoritmos de cifrado más potentes: 3DES, Blowfish, Twofish, Arcfour, Cast128-cbc.
Creación de una clave de host más segura
Para generar una nueva clave de host más fiable que la que se genera en la instalación del OpenSSH se ejecutará la siguiente acción:
De este modo se genera un par de claves RSA para identificar al host. Parte privada y parte pública que se almacenarán dónde se indique con el modificador '-f'. En este caso se generarán en el directorio por defecto del servidor /etc/ssh. Es recomendable cambiar el tamaño de la clave de host a un tamaño de 2048 bits y no usar la clave por defecto de sólo 1024 bits.
Distribución segura de la clave de host
Los clientes, cuando se conecten al servidor, durante el proceso de handshake SSL deberán identificar correctamente al servidor. Para ello, las claves públicas de los hosts de confianza son almacenadas en el cliente. El lugar donde se almacenan estas claves depende de la herramienta cliente que se esté utilizando. En los sistemas Linux se encuentra en la ruta ~/.ssh/known_hosts.
Si el cliente se conecta a un servidor del que no se tiene la clave pública almacenada, se generará una alerta de seguridad y se pedirá confirmación al usuario antes de iniciar la conexión. Se debe tener claro que en este punto en concreto se puede sufrir un ataque
Man In The Middle si un atacante cogiera el certificado de host que envía el servidor, por lo que se recomienda distribuir la clave pública del host previamente a la primera conexión por medio de un dispositivo externo e instalarlo en el servidor sin utilizar la red. En el caso de los dispositivos iPhone, iPod Touch o iPad se puede conectar el dispositivo a un PC o Mac y realizar la operación o bien enviar ese archivo por correo electrónico como un adjunto protegido con clave.
Creación del canal seguro
El Handshake son todas las acciones que se realizan entre el cliente y el servidor para verificar que los dos son quien dicen ser y establecer una clave de cifrado simétrica que pueda utilizarse para generar un canal de comunicaciones seguro.
En primer lugar, el cliente manda un mensaje "
Hello" al servidor junto con la lista de algoritmos de firma y cifrado que soporta.
El servidor, contestará con el envío de la clave pública de host con su identidad es decir, la
Host Key, los algoritmos que van a utilizar en la comunicación, si es que el cliente soporta alguno de los permitidos por el servidor, junto la parte pública de una clave RSA de sesión que se genera cada cierto tiempo.
El cliente verificará la identidad del servidor comprobando la host key recibida con la información almacenada en la carpeta de host conocidos. Una vez verificado generará, basándose en los algoritmos marcados por el servidor, una clave de cifrado simétrico de sesión de 256 bits que enviará al servidor cifrada con la clave pública de sesión recibida.
El servidor, después de este paso, enviará una copia al cliente con todo lo acordado ya cifrado simétricamente. Una vez el canal esta creado, ya pueden intercambiar datos de forma segura. OpenSSH utiliza
Diffie Hellman efímero que es uno de los métodos más seguros.
Cambio del tamaño de la clave de sesión
Otra de las recomendaciones para fortificar la comunicación es cambiar el tamaño de la clave de sesión para que sea de 1024 bits y no de 768 bits como se configura por defecto. Esta recomendación es debido a que durante este año se han realizado pruebas de concepto en las que se
han roto las claves 768 bits.
En el fichero de configuración del servidor que se encuentra en la ruta /etc/ssh/sshd_config se puede observar la directiva ServerKeyBits dónde se puede cambiar el tamaño de la clave de sesión. Se recomienda un valor de 1024.
También se observa una línea por encima, en el mismo fichero, como se encuentra la directiva KeyRegenerationInterval. Esta directiva indica el tiempo que tiene que pasar para renovar la clave de sesión que puede ser reducido si se quiere hacer más difícil aún la ruptura de las claves, ya que habría que romper más claves por unidad de tiempo de una conversación en caso de un ataque.
Creando el par de claves en el cliente para autenticarse
Lo primero que se va a intercambiar tras el establecimiento del canal seguro es la petición de login por parte del servidor y en este caso se va a configurar una autenticación basada en certificados de usuario. Para ello se utiliza el esquema de clave pública y privada. Con esta técnica se pretende que el usuario no envíe una contraseña cada vez que intente entrar al sistema remoto sino que se utilicen claves RSA.
Primero se tiene que crear el par de claves para el usuario. Se crearán con el comando ssh-keygen:
ssh-keygen –q –f ~/.ssh/id_rsa –t rsa
Para el passphrase se recomienda no utilizar la contraseña de usuario que tiene en el sistema, ni dejarla en blanco. Se recomienda que al menos tenga 16 caracteres de longitud, y que se mezclen caracteres alfanuméricos, no solamente letras.
La clave privada y pública del usuario deben estar en el cliente, almacenadas en la ruta configurada para ello en el cliente SSH. Es por ello que el Path dónde se encuentre el par de claves, que en los sistemas Linux es
~/.ssh debe tener seguridad respecto a otros usuarios del sistema. Por lo que sería buena idea dotar de permisos 700 al directorio .
ssh.
Distribuyendo la clave del usuario
El servidor OpenSSH debe tener asociada la clave pública del par de claves generado para identificar al usuario. Para ello debe copiarse el fichero
id_rsa_pub, es decir, la parte pública en el servidor. Para copiar el fichero id_rsa.pub al iPhone se puede usar el comando SCP que forma parte del protocolo SSH si ya estamos en una sesión SSH previa o hacerlo conectando el dispositivo al equipo.
La calve se debe guardar en un fichero especial denominado
authorized_keys que se encuentra en el directorio del home ~/.ssh del usuario al que queremos asociar la clave en el servidor.
Autenticándose con la clave RSA
Cuando el usuario se quiere conectar utilizando utilizando su clave debe realizarlo desde el cliente donde tiene instalada la parte privada. El cliente SSH, cuando encuentre la clave privada, solicitará la passphrase creada para poder acceder a ella. Una vez se introduzca la passphrasse se procederá al desafío del usuario. Para ello el servidor enviará un desafío que el cliente cifrará con la parte privada de la clave. El servidor comprobará si con alguna de las claves autorizadas, almacenadas en el directorio de ese usuario, se puede descifrar y obtener el desafío. Si es así, el usuario queda autenticado sin enviar su contraseña, tal y como se ve en la siguiente imagen.
Conclusiones
Con este último paso se tiene un servidor
OpenSSH más fortificado para nuestro pequeño dispositivo. Normalmente SSH es un protocolo seguro, pero hay técnicas como ataques de fuerza bruta las cuales pueden debilitar nuestro sistema hasta acceder a él. Con todo lo que hemos ido viendo a lo largo de la serie se puede observar como paso a paso se han bastionado los aspectos más relevantes del servidor. Aún así, como puede aparecer una vulnerabilidad en cualquier momento, se recomienda estar muy atento a nuevas actualizaciones de
OpenSSH.
========================================================================
-
Configuración OpenSSH en dispositivos iPhone (1 de 4)
-
Configuración OpenSSH en dispositivos iPhone (2 de 4)
-
Configuración OpenSSH en dispositivos iPhone (3 de 4)
-
Configuración OpenSSH en dispositivos iPhone (4 de 4)
========================================================================
Con el lanzamiento de jailbreak para iOS 11, los desarrolladores están listos para trabajar en el desarrollo de tweaks para el iPhone X. Con su mayor pantalla y diseño único el iPhone X ofrece un gran número de opciones creativas para desarrollar tweaks que otros iPhone no podrán disfrutar. Semanas después del lanzamiento del jailbreak, los desarrolladores han trabajado duro para traernos unos cuantos tweaks bastante curiosos. Actualmente la principal dificultad para adquirir estos tweaks reside en la ausencia de Cydia en iOS 11, para instalarlos deberás de hacerlo vía SSH. Si no dispones de conocimientos sobre SSH es recomendable esperar a que Saurik actualice Cydia para iOS 11.
