Asegurando SSH en su sistema

OpenSSH (o Shell Seguro) se ha convertido en el estándar para el acceso remoto, reemplazando al protocolo telnet. SSH ha hecho que los protocolos como telnet sean redundantes, en su mayoría, por el hecho de que la conexión es encriptada y las contraseñas no son enviadas en texto plano para que todos la puedan ver.

De cualquier forma, una instalación por defecto de ssh no es perfecta, y cuando corremos un servidor ssh hay algunos pasos simples que pueden endurecer dramáticamente una instalación.

1. Usar contraseñas Fuertes

Si usted está corriendo ssh y se encuentra expuesto al mundo exterior, una de las primeras cosas que podrá notar serán los intentos de los hackers tratando de acceder para adivinar su nombre de usuario/contraseña. Típicamente un hacker escaneará el puerto 22 (el puerto por defecto por el cual ssh escucha) para encontrar máquinas que estén corriendo ssh, y entonces intentarán un ataque de fuerza-bruta contra esta. Con contraseñas fuertes en su lugar, felizmente cualquier ataque será registrado y notificado antes de que pueda tener éxito.

Afortunadamente usted ya está usando una contraseña fuerte, de lo contrario entonces trate de escoger contraseñas que contengan:

• 8 Caracteres como mínimo
• Mezcle letras mayúsculas y minúsculas
• Mezcle letras y números

• Use caracteres no alfabéticos (ej: caracteres especiales como ! " £ $ % ^ etc. )

Los beneficios de una contraseña fuerte no son específicos de SSH, pero tienen un impacto en todos los aspectos de la seguridad del sistema. Más información en contraseñas puede ser encontrada en la documentación de CentOS: http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html

2. Deshabilitar el acceso como root

La configuración del servidor SSH se encuentra almacenada en el fichero /etc/ssh/sshd_config. Para deshabilitar el acceso de root, asegúrese de tener la siguiente entrada:

#Prevent root logins:
PermitRootLogin no

y reiniciar el servicio sshd:

service sshd restart

Si usted necesita acceder como root, acceda como un usuario normal y use el comando su.

3. Deshabilitar el protocolo 1

SSH posee dos protocolos que se pueden usar, protocolo 1 y protocolo 2. El viejo protocolo 1 es menos seguro y debe estar deshabilitado, a menos que usted lo requiera para algo específico. Busque la siguiente línea en el fichero /etc/ssh/sshd_config, descoméntela y modifíquela como sigue:

# Protocol 2,1
Protocol 2

reinicie el servicio sshd.

4. Usar un Puerto No-Estándar

Por defecto, ssh escucha las conexiones entrantes en el puerto 22. Para que un hacker determine si ssh se está ejecutando en su máquina, lo más probable es que escanee el puerto 22. Un método efectivo es ejecutar ssh en un puerto no-estándar. Cualquier puerto sin usar funcionará, pero es preferible usar uno por encima del 1024.

Muchas personas escogen el 2222 como un puerto alternativo (porque es fácil de recordar), de la misma forma que el 8080 es conocido, a menudo, como un puerto HTTP alternativo. Por esta razón, probablemente esta no es la mejor opción. De la misma forma que cualquier hacker escaneará el puerto 22, seguramente también escaneará el puerto 2222 solo como buena medida. Es mejor escoger cualquier puerto alto al azar que no sea usado por ningún servicio conocido.

Para hacer los cambios añada una línea como esta a su fichero /etc/ssh/sshd_config:

# Ejecutar ssh en un puerto No-Estándar:
Port 2345  #Cámbiame

y reinicie el servicio sshd.

Recuerde hacer cualquier cambio necesario a los puertos de reenvío en su enrutador y a cualquier regla aplicable al cortafuegos.

Debido a que ssh ya no estará escuchando peticiones en el puerto estándar, necesitará decirle a su cliente a que puerto se conectará. Si usamos ssh desde la linea de comandos, especificaremos el puerto usado con el switch -p:

$ ssh -p 2345 miservidor

o si estás usando el protocolo fish en konqueror, por ejemplo:

fish://miservidor:2345/dir/remota

Si está pensando que tener que especificar el puerto cada vez que se conecte suena a mucho trabajo, simplemente añada una entrada especificando el puerto en su fichero local ~/.ssh/config:

# Client ~/.ssh/config
Host miservidor
HostName 72.232.194.162
        User bob
        Port 2345

~/.ssh/config debe tener los siguientes permisos:

$ chmod 600 ~/.ssh/config

5. Filtrar SSH en el Cortafuegos

Si usted solamente necesita tener acceso desde una dirección IP (digamos desde el trabajo al servidor en casa), entonces considere la posibilidad de adicionar una regla en el cortafuegos de su enrutador o en el de su iptables para limitar el acceso al puerto 22 a una dirección IP específica. Por ejemplo, en iptables esto podría realizarse con la siguiente regla:

iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT

Nativamente, SSH también soporta TCP wrappers y el acceso a al servicio ssh puede ser igualmente controlado usando host.allow y host.deny.

Si no puede limitar las direcciones IP, y debe abrir el puerto ssh globalmente, entonces iptables todavía puede ayudarlo a prevenir un ataque con fuerza-bruta registrando y bloqueando repetidos intentos de entrar al sistema desde la misma dirección IP. Ejemplo:

iptables -A INPUT -p tcp --dport 22 -m recent --set --name ssh --rsource
iptables -A INPUT -p tcp --dport 22 -m recent ! --rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j ACCEPT

La primera regla graba la dirección IP por cada intento de acceso al puerto 22 usando el módulo recent. La segunda regla chequea si esta dirección IP ha intentado conectarse 4 o más veces en los últimos 60 segundos, y si no entonces el paquete es aceptado. Note que esta regla requiere una política DROP por defecto en la cadena INPUT.

Recuerde cambiar el puerto por el apropiado si estás ejecutando ssh en un puerto no-estándar. Donde sea posible, el filtrado en el cortafuegos es un método extremadamente efectivo de asegurar el acceso a un servidor ssh.

6. Usar llaves Públicas/Privadas para la Autenticación

Usar llaves encriptadas para la autenticación ofrece dos beneficios principales. Primero, es conveniente porque ya no necesitará entrar una contraseña (a menos que encripte sus llaves con una contraseña de protección) si usa llaves públicas/privadas. Segundo, una vez que un par de llaves públicas/privadas se han creado en el servidor, podrás deshabilitar completamente la autenticación con contraseña. Esto significa que sin una llave autorizada no puede ganar acceso - entonces no más intentos de romper contraseñas.

Crear un par de llaves pública/privada e instalarlas para su uso en un servidor ssh, es un proceso relativamente simple.

Primero, cree un par de llaves pública/privada en el cliente que utilizará para conectarse al servidor (necesitará hacer esto por cada máquina cliente desde la cual se conecte):

$ ssh-keygen -t  rsa

Esto creará dos ficheros en su directorio (oculto) ~/.ssh llamados id_rsa e id_rsa.pub. id_rsa es su llave privada e id_rsa.pub su llave pública.

Si usted no desea que cada vez que se conecte se le pregunte la contraseña, solo presione Enter cuando se le pregunte por una contraseña cuando esté creando el par de llaves. Cuando esté creando la llave, es su responsabilidad decidir si protege o no su llave con contraseña. Si no encripta su llave con contraseña, entonces cualquiera que gane acceso a su máquina local tendrá acceso ssh automáticamente al servidor remoto.

Además, en la máquina local el usuario root tiene acceso a sus llaves. De esta forma, si asumimos que el usuario root no es confiable (o es comprometido!), estará en un gran problema. Encriptar la llave adiciona seguridad al coste de eliminar la necesidad de entrar una contraseña para el servidor ssh con la de solamente entrar una contraseña para el uso de la llave.

Ahora establezca los permisos para su llave privada:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_rsa

Copiar la llave pública (id_rsa.pub) al servidor e instalarla en la lista authorized_keys:

$ cat id_rsa.pub >> ~/.ssh/authorized_keys

y finalmente establezca los permisos del fichero en el servidor:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

Los permisos anteriores serán requeridos si StrictModes está establecido a yes en /etc/ssh/sshd_config (por defecto).

Ahora cuando accedas al servidor no verá el prompt preguntando por la contraseña (a menos que cuando haya creado el par de llaves le haya puesto contraseña). Por defecto, ssh tratará de autenticarse usando llaves. Si no se encuentra ninguna llave y la autenticación falla, entonces ssh caerá en la autenticación convencional por contraseña.

Una vez que haya verificado que puede acceder de forma exitosa al servidor usando su par de llaves pública/privada, usted puede deshabilitar completamente la autenticación por contraseñas añadiendo la siguiente configuración al fichero /etc/ssh/sshd_config:

# Deshabilitar el uso de contraseña de autenticación forzando el uso de llaves
PasswordAuthentication no

7. Preguntas Frecuentes (FAQs)

P: CentOS usa una versión X de OpenSSH y la última versión es Y. La versión X contiene una seria falla de seguridad, debo actualizarla a la versión superior?

R: No. El proveedor original tiene una política de parches de seguridad, haciendo backporting de las últimas versiones en la versión actual de la distribución. Mientras tengas aplicadas las actualizaciones más recientes para su distribución CentOS, esta estará completamente parcheada.

8. Enlaces

• http://www.redhat.com/advice/speaks_backport.html

• http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html