Continuando con esta serie de entradas correspondientes a OpenSSH/SSH en esta entrada se tratarán otras características interesantes en OpenSSH relacionadas con las medidas de seguridad que se pueden llevar a cabo, túneles y conceptos relacionados con generación de claves entre otras cosas.
Medidas de seguridad en SSH
Para fortalecer la seguridad de un servicio SSH y los clientes que se conectan a este, existen ciertas medidas que deben implementarse con el fin de evitar (o al menos dificultar) ataques contra la infraestructura del tipo MITM entre otros, algunas de estas medidas se indican a continuación, aunque pueden implementarse muchas otras en función a necesidades especificas, estas son unas medidas básicas y de una “casi” obligatoriedad.
- No se debería permitir el acceso remoto al usuario root, normalmente debería permitirse el acceso a usuarios que tengan cuentas con privilegios limitados, o una cuenta en una chroot jail, para esto se define la linea:
PermitRootLogin no - Siguiendo este mismo orden de ideas, también es posible habilitar solamente aquellos usuarios que utilizaran el servicio, definiendo los nombres de las cuentas que tienen permisos realizar una conexión con el servidor SSH. Del mismo modo también se puede declarar de forma explicita quienes no pueden acceder al servidor SSH aunque cuenten con credenciales de acceso validas:
AllowUsers Adastra Galileo DenyUsers Bernardino Templar - Una medida de seguridad importante consiste en definir el número de segundos máximo que tardará el usuario en ingresar sus credenciales, si realmente es quien dice ser, normalmente no debería tardar mucho, para definir este “tiempo de gracia” en el fichero sshd_config: LoginGraceTime 30
Esto definirá un valor de 30 segundos para ingresar usuario/clave. - Difinir los usuarios, maquinas y cuentas que pueden conectarse al servicio SSH, normalmente definimos nuestras cuentas y la remota.
AllowUsers adastra chaosempire@192.168.1.35 - Número máximo de intentos de conexión.
MaxAuthTries 2
Se definen 2 intentos de autenticación máximos. - No permitir passwords vacíos.
PermitEmptyPasswords no - Definir un número máximo de usuarios conectados a la maquina.
MaxStartups 10
Permite 10 clientes concurrentes.
En algunas ocasiones resulta conveniente cambiar el puerto por defecto (22) por cualquier otro para dificultar las cosas un poco a un atacante, para esto se indica el puerto en el fichero de configuración del servidor SSH.
Port 3334
Cabe anotar que esta opción también es soportada en el fichero de configuración del cliente y en dicho caso, el puerto por el que se intentarán establecer todas las conexiones a servicios SSH será al puerto especificado en el fichero de configuración, a menos que se especifique de forma explicita un puerto distinto por medio de la opción “-p”
Ahora bien, como se ha indicado en la entrada anterior, el fichero de configuración del servidor se encuentra ubicado en /etc/ssh/sshd_config y el fichero de configuración del cliente se encuentra ubicado en /etc/ssh/ssh_config sin embargo, si el cliente tiene el fichero ssh_config ubicado en el directorio ~/.ssh/config ese será el que utilice el cliente de OpenSSH.
Autenticación por medio de claves publica/privada
Hasta este punto se ha venido hablando de autenticación por medio de una cuenta de usuario existente en el sistema, sin embargo OpenSSH soporta la autenticación por medio del uso de pares de claves privada/publica, como se ha indicado anteriormente el servidor SSH debe contener la clave publica, mientras que el cliente debe contener la clave privada para realizar la autenticación con el servicio. Si el procedimiento de instalación de las claves en cada uno de los puntos (cliente-servidor) se ha realizado de forma correcta, la autenticación al servicio SSH no será contra un usuario existente en el sistema donde se ejecuta el servicio, sino que será contra la contraseña que se ha empleado para la generación de las claves.
El proceso de generación de las claves publica/privada se detalla a continuación:
- Debe existir el directorio .ssh en el directorio personal del usuario que ejecuta el cliente SSH, si no existe, crearlo
| >mkdir -p ~/.ssh ; chmod 700 ~/.ssh ; |
- posteriormente es necesario crear las claves con el uso del comando ssh-keygen.
>ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:Your identification has been saved in /root/.ssh/id_rsa.Your public key has been saved in /root/.ssh/id_rsa.pub.The key fingerprint is:8a:1b:5a:00:38:c9:7d:96:50:ed:46:9c:37:2c:40:91 root@debianThe key’s randomart image is:
+–[ RSA 2048]—-+
| .o=* o |
|o.. .E.* + |
|=. . +o o . |
| o o o |
| . . S |
| . . . |
| + . |
| o o |
| . . |
+—————–+
- Ahora es necesario transferir la clave al servicio ssh, para conseguir esto de forma segura se utiliza el comando ssh-copy-id Este comando creará (si no existe) el fichero authorized_keys conteniendo las claves privadas que pueden ser admitidas por el servidor, de este modo, cuando se intente ejecutar una conexión con un servidor SSH, lo primero que se intentará hacer es buscar dicho fichero en el directorio personal de usuario y si este existe, se intentará realizar la conexión utilizando dicha clave, si se intenta realizar la conexión con usuario distinto del que se ha especificado en el comando ssh-copy-id la autenticación se realizará por login y password en la maquina remota.
>ssh-copy-id root@192.168.1.33
The authenticity of host ‘192.168.1.33 (192.168.1.33)’ can’t be established.RSA key fingerprint is ac:ad:22:07:7c:11:b4:49:ee:3f:32:95:5b:5b:d4:99.Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘localhost’ (RSA) to the list of known hosts.jdaanial@localhost’s password:Now try logging into the machine, with «ssh ‘root@192.168.1.33′», and check in:.ssh/authorized_keysto make sure we haven’t added extra keys that you weren’t expecting.>ssh root@192.168.1.33
Enter passphrase for key ‘/root/.ssh/id_rsa’:
Como puede apreciarse desde la maquina donde se encuentra el servicio SSH (192.168.1.33) no se ha tenido que realizar ningún tipo de acción, todo se ha ejecutado desde el lado del cliente, este se encarga de generar las claves y de importarlas al servidor, evidentemente no cualquier usuario puede realizar este tipo de acciones, solamente aquellos que tengan las credenciales de acceso correspondientes en el servidor y privilegios de root.
Consideraciones al momento de utilizar claves publica/privada
Tal como se ha indicado en párrafos anteriores, es necesario tomar ciertas medidas de seguridad con el fin de endurecer un servicio SSH, una de estas medidas sin lugar a dudas es el uso de un mecanismo de clave publica/privada que se ha indicado anteriormente, sin embargo este mecanismo por si solo no garantiza la seguridad del servicio, se deben habilitar algunas opciones adicionales en el fichero de configuración del servidor para que realmente funcione como se espera, estas son:
PermitRootLogin no
Es importante que no se permita el acceso al usuario root (a menos que sea necesario dependiendo de las necesidades particulares del administrador de sistemas o del negocio) en lugar de utilizar una cuenta con privilegios de root se deberia permitir el acceso solamente a ciertos usuarios y a ciertos grupos con el uso de las opciones AllowUsers y AllowGroups respectivamente (esto en el caso de que no se utilice un mecanismo de clave publica y privada)
PasswordAuthentication no
En el caso de que se permita el acceso por clave publica y privada, cabe preguntarse ¿realmente es necesario permitir otro mecanismo de autenticación diferente? En el caso de que la opción PasswordAuthentication no sea establecida a “no” de forma explicita, será posible acceder al servidor por medio de una cuenta de usuario existente en el sistema aunque se indique al servidor SSH que el mecanismo de autenticación será por medio de clave privada, por ejemplo
| >ssh root@192.168.1.33 Enter passphrase for key ‘/root/.ssh/id_rsa’: Enter passphrase for key ‘/root/.ssh/id_rsa’: Enter passphrase for key ‘/root/.ssh/id_rsa’: root@192.168.1.33’s password: |
En el comando anterior, el servidor SSH solicita la clave privada para realizar la autenticación con el servicio, sin embargo como puede apreciarse, después de tres intentos de autenticación fallidos el servicio solicita la clave correspondiente al usuario root del sistema, en lugar de terminar la conexión de forma automática que será posiblemente lo mas adecuado.
Seguridad en Sistemas y Técnicas de Hacking. TheHackerWay (THW) 