SSH es el protocolo por excelencia para acceder en remoto en los entornos Unix. Es una forma muy cómoda de acceder a una consola desde otro equipo.

Para aquellos que recuerden telnet, su forma de funcionar es muy parecida. Eso sí la diferencia más importante es que el tráfico SSH está cifrado.

La característica de cifrado es precisamente la que hace de este protocolo sumamente versátil, ya que a través de el propio canal que genera el protocolo SSH es posible tunelizar otros protocolos no seguros.

A pesar de lo seguro del protocolo, la configuración del servidor es un detalle muy a tener en cuenta. Debemos tener en cuenta que por defecto la configuración por defecto es muy predecible y contiene ciertos aspectos para mantener compatibilidades que quizás no nos interesen demasiado.

Aquí voy a proponer una serie de posibilidades, mi recomendación es escoger aquellas que más se adecuen a nuestro caso e ir aplicándolas y comprobando una a una. En ningún caso recomiendo aplicarlas todas al mismo tiempo y probarlas todas al final.

Puerto TCP

El punto que yo considero más importante es el puerto en el que se ejecuta es la modificación del puerto sobre el que se ejecuta el servidor. La prueba más importante que podéis hacer es dejar un servidor SSH «abierto» al mundo, y comprobar la gran cantidad de ataques fuerza bruta que podéis llegar a tener.

A partir de ahora la forma de acceder será por ejemplo la siguiente:

ssh -p 23123 root@192.168.1.1

 

Versión SSH

Hay dos versiones del protocolo SSH, siendo la primera de ellas vulnerable a un agujero de seguridad importante. El servidor que suele estar en las distribuciones Linux es OpenSSH, el cual es compatible con la versión 1. Por este motivo es importante comprobar que tenemos desactivada la compatibilidad con la versión 1

 

Tiempo inactividad

Uno de los parámetros que podemos modificar es el tiempo de inactividad que puede estar un cliente inactivo sin perder la conexión. Cuanto más bajo sea este periodo de tiempo menos riesgo de intrusión tendrá el servidor. Hay que decir que poner un tiempo demasiado bajo puede ser un engorro para trabajar cómodamente.
Tiempo de Login

Hay un período de tiempo que pasa entre que el sistema pide un login y el usuario lo introduce. Por defecto este período puede ser muy alto (incluso puede llegar a varios minutos). Lo mas razonable es reducir este campo a unos pocos segundos. Tal vez unos 30 segundos sean suficientes, aunque por supuesto es posible reducirlo más todavía

Información a los clientes

Cuando nos conectamos al servidor, este devuelve cierta información acerca del software utilizado como servidor o su versión. Como nos interesa mucho el misterio, vamos a ocultar todos los datos que podamos


Intentos fallidos

Cuando alguien falla en el login es posible que en remoto siga y siga realizando intentos para conseguir entrar mediante fuerza bruta. Por supuesto tenemos que ponerle un máximo de intentos fallidos a partir del cual se le denegará el acceso.

 

Conexiones simultáneas

Además es posible limitar el número de conexiones simultáneas que realiza un mismo cliente. Esto se controla desde la IP cliente. Aunque depende del uso que vayamos a darle y del tipo de organización desde donde realicemos las conexiones, debería ser suficiente con 2.

 

Securizando nuestro Servidor Remoto SSH
Etiquetado en:                        

Deja un comentario

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