Interesante tip para mejorar la seguridad de SSH

Esta vez veremos un corto y sencillo tip que nos ayudará a mejorar la seguridad de nuestras conexiones remotas con SSH.


OpenSSH, que es el paquete que proveen los sistemas GNU/Linux para manejar conexiones SSH, tiene una amplia variedad de opciones. Leyendo el libro SSH The Secure Shell y las páginas del manual encontré la opción -F, la cual le informa al cliente SSH que utilice un archivo de configuración distinto al que encontramos por defecto en el directorio /etc/ssh.

¿Cómo usamos esta opción?

De la siguiente manera:

ssh -F /ruta/a_tu/archivo/de_configuración usuario@ip/host

Por ejemplo si tenemos un archivo de configuración personalizado a nuestro gusto de nombre my_config en el Escritorio, y queremos conectarnos con el usuario carlos a la computadora con la ip 192.168.1.258, entonces usaríamos el comando como sigue:

ssh -F ~/Escritorio/my_config carlos@192.168.1.258

¿Cómo ayuda a la seguridad de la conexión?

Recordemos que un atacante al estar dentro de nuestro sistema intentará inmediatamente obtener privilegios de administrador si es que no los tuviera ya, entonces para él seria bastante fácil ejecutar ssh para conectarse al resto de las máquinas de la red. Para evitar esto, podemos configurar el archivo /etc/ssh/ssh_config con valores incorrectos, y cuando deseemos conectarnos vía SSH usaremos el archivo de configuración que tendremos guardado en una ubicación que sólo nosotros sabemos (incluso en un dispositivo de almacenamiento externo), es decir, tendríamos seguridad por oscuridad. De esta manera el atacante quedaría desconcertado al encontrar que no puede conectarse usando SSH y que intenta hacer las conexiones de acuerdo a lo especificado en el archivo de configuración predeterminado por lo que le resultará algo difícil darse cuenta de lo que pasa, y le complicaremos bastante el trabajo.

Esto añadido a cambiar el puerto de escucha del servidor SSH, deshabilitar SSH1, especificar qué usuarios se pueden conectar al servidor, permitir explicitamente qué IP o rango de IPs pueden conectarse al servidor y otros consejos más que podremos encontrar en http://www.techtear.com/2007/04/08/trucos-y-consejos-para-asegurar-ssh-en-linux nos permitirán incrementar la seguridad de nuestras conexiones SSH.

Todo lo descrito anteriormente puede hacerse en una sola línea. Para mi gusto sería bastante tedioso tener que escribir una gran linea con múltiples opciones cada vez que intentemos logearnos vía SSH a un pc remoto, por ejemplo la siguiente sería una muestra de lo que les digo:

ssh -p 1056 -c blowfish -C -l carlos -q -i myself 192.168.1.258

-p Especifica el puerto para conectarse en el host remoto.
-c Especifica cómo se va a cifrar la sesión.
-C Indica que se deberá comprimir la sesión.
-l Indica el usuario con el que se logueará en el host remoto.
-q Indica que los mensajes de diagnostico sean suprimidos.
-i Indica el archivo con el que se identificará (llave privada)

También debemos recordar que podríamos usar el historial del terminal para no tener que teclear todo el comando cada vez que lo necesitemos, cosa que también un atacante podría aprovechar, por lo que no lo recomendaría, al menos en el uso de conexiones SSH.

Aunque la cuestión de seguridad no es la única ventaja de esta opción, se me ocurren otras, como por ejemplo tener un archivo de configuración para cada servidor al que deseemos conectarnos, así evitaremos escribir las opciones cada vez que deseemos hacer una conexión a un servidor SSH con una configuración especifica.

Usar la opción -F puede ser muy útil en caso de que se tengan varios servidores con diferente configuración. De lo contrario, habrá que recordar todas las configuraciones, lo que resulta prácticamente imposible. La solución sería tener un archivo de configuración perfectamente preparado según los requerimientos de cada servidor facilitando y asegurando los accesos a esos servidores.

En este enlace http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config podrán encontrar como editar el archivo de configuración del cliente SSH.

Recuerden este es solo un tip más de los cientos que podemos encontrar para asegurar SSH, así que si quieren tener conexiones remotas seguras deberán combinar entre las posibilidades que nos ofrece OpenSSH.

De momento es todo, espero les sirva de algo esta información y esperen la próxima semana otra publicación sobre seguridad en SSH.

Nota: si desean leer el libro “SSH The Secure Shell” no dejen de consultar las páginas del manual de la versión que tengan instalada, pues el libro está bastante atrasado en lo que respecta a las opciones soportadas por OpenSSH.

¡Gracias Izkalotl por el aporte!
¿Interesado en realizar un aporte?


9 comentarios

  1.   ivaan11 dijo

    lo que quería es que nadie pudiese acceder a mi pc y controlarlo remotamente
    entonces entiendo por tus palabras que si no abro el puerto no hay acceso al menos de este modo

    mercii por contestar!

  2.   ivaan11 dijo

    holaa
    he siguido algunos de los trucos y tengo una duda! de entre las opciones he cambiado también
    el puerto por otro diferente al tradicional¿si no abro ese puerto en el router será imposible que se conecten a mi pc? o se redirigirá a cualquier otro puerto?

    no necesito realizar ninguna conexión remota por eso queria saber que sería mas efectivo si abrir el puerto o dejarlo bloqueado.

    espero respuestas!

  3.   Sergio Weizenegger dijo

    >Lo más seguro es emplear passwordless login usando key files.
    Es exactamente lo que iba a decir… que la única forma de loguearse a diferentes equipos sea con una key que está en un pendrive colgando de tu cuello 😉
    El atacante puede desperdiciar toda su vida tratando de crackear un password por fuerza bruta, y nunca se dará cuenta de que no necesita un password sino un archivo XD

  4.   izkalotl linux dijo

    No soy un experto en Seguridad y Redes pero para vulnerar tu sistema de seguridad con passworless login bastaría simplemente hacer un script para copiar tu llave almacenada en un pendrive al momento que lo montes, así en cuestión de segundos tendría acceso con tu propia llave al servidor remoto (y claro, sin necesidad de password), el problema del passwordless es que hace sentir una falsa seguridad, ya que como ves con unas cuantas lineas en un script sería sencillisimo hacerse del control de tus servidores remotos. Recuerda que un atacante no desperdiciara tiempo ni recursos tratando de romper contraseñas si existe un camino más corto para vulnerar tu seguridad. Te recomiendo que por lo menos uses 20 de las opciones que SSH permite configurar y a esto adiciones algo como TCP Wrappers, un buen Firewall y aún así tu servidor no estaría 100% protegido, el peor enemigo en cuestiones de seguridad es ser confiado.

  5.   HacKan & CuBa co. dijo

    ¿qué? creo que te referís a otro post, porque no entiendo lo que mencionas. Este post da un pequeño tip para aplicar a la hora de establecer la conexión con un equipo, no hace referencia a cambiar alguna configuración del mismo, ni de solucionar nada si alguien logra ingresar. La idea es hacer que la comunicación entre los equipos sea segura, pasando por alto los parámetros por defecto que podrían no ofrecer el nivel seguridad adecuado.
    Port-knocking es interesante para restringir ataques (no los evita del todo, pero hace lo suyo), aunque lo veo un poco incómodo de emplear… será que no tengo mucha experiencia con él.
    Hay varios progs que escanean los logs para bloquear el acceso por ip cuando se detectan logins incorrectos.
    Lo más seguro es emplear passwordless login usando key files.

    Saludos!

  6.   HacKan & CuBa co. dijo

    ¿qué? creo que te referís a otro post, porque no entiendo lo que mencionas. Este post da un pequeño tip para aplicar a la hora de establecer la conexión con un equipo, no hace referencia a cambiar alguna configuración del mismo, ni de solucionar nada si alguien logra ingresar. La idea es hacer que la comunicación entre los equipos sea segura, pasando por alto los parámetros por defecto que podrían no ofrecer el nivel seguridad adecuado.
    Port-knocking es interesante para restringir ataques (no los evita del todo, pero hace lo suyo), aunque lo veo un poco incómodo de emplear… será que no tengo mucha experiencia con él.
    Hay varios progs que escanean los logs para bloquear el acceso por ip cuando se detectan logins incorrectos.
    Lo más seguro es emplear passwordless login usando key files.

    Saludos!

  7.   HacKan & CuBa co. dijo

    También el ssh buscara la configuración de usuario por defecto en ~/.ssh/config
    Salvo que se lo haya configurado al daemon para no hacerlo, pero por defecto lo hace.
    Es importante tener en cuenta el algoritmo empleado para hashes, con la opcion -m; recomiendo hmac-sha2-512,hmac-sha2-256,hmac-ripemd160 por ser las que mejor seguridad ofrece. Ojo, porque por defecto emplea MD5 (o sha1 con suerte)!! son esas cosas que no se entienden….
    En fin, una buena idea seria ejecutarlo con:
    ssh -p PUERTO -c aes256-ctr -m hmac-sha2-512 -C IP
    con -c se especifica el algoritmo de cifrado empleado, donde los ctr (counter mode) son los mas recomendados (aes256-ctr y aes196-ctr), y si no los cbc (cipher-block chaining): aes256-cbc,aes192-cbc, blowfish-cbc, cast128-cbc

    Saludos!

  8.   HacKan & CuBa co. dijo

    También el ssh buscara la configuración de usuario por defecto en ~/.ssh/config
    Salvo que se lo haya configurado al daemon para no hacerlo, pero por defecto lo hace.
    Es importante tener en cuenta el algoritmo empleado para hashes, con la opcion -m; recomiendo hmac-sha2-512,hmac-sha2-256,hmac-ripemd160 por ser las que mejor seguridad ofrece. Ojo, porque por defecto emplea MD5 (o sha1 con suerte)!! son esas cosas que no se entienden….
    En fin, una buena idea seria ejecutarlo con:
    ssh -p PUERTO -c aes256-ctr -m hmac-sha2-512 -C IP
    con -c se especifica el algoritmo de cifrado empleado, donde los ctr (counter mode) son los mas recomendados (aes256-ctr y aes196-ctr), y si no los cbc (cipher-block chaining): aes256-cbc,aes192-cbc, blowfish-cbc, cast128-cbc

    Saludos!

  9.   gorlok dijo

    Es interesante, aunque no estoy seguro del beneficio real, siendo que estamos hablando de apenas dificultar un poquito las cosas cuando un atacante ya ingresó al equipo, y agregarle más complejidad a los administradores.
    Me parece más útil alguna técnica de honeypot que alerte (y tome alguna acción?) ante una actividad sospechosa, o algún tipo de sandbox que restringa las acciones del atacante.
    O buscaría otro tipo de técnicas, que eviten el ingreso, como puede ser el port-knocking.
    Igualmente, gracias por compartirlo y abrir el debate.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.