SSH (Secure SHell) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red.
Permite manejar por la computadora mediante un el intérprete de comandos instalado en la misma (bash, ksh, etc..), y también puede redirigir el tráfico de X-Windows para poder ejecutar programas gráficos si tenemos un Servidor X arrancado en nuestra máquina local.
Asegurando SSH:
Aunque SSH en sí es un protocolo seguro, podemos afinar los parámetros de configuración para hacer que su utilización resulte todavía más segura.
Pasos que seguiremos:
- Deshabilitar SSH 1.
- Autenticación basada en llave RSA.
- No permitir autenticación mediante login/password.
- No Permitir acceso como root sin llave.
- Cambiar el puerto por Defecto.
- Banear IPs tras 5 logins erróneos.
Deshabilitar SSH 1:
Puesto que en la versión del protocolo ssh 1 hay algunas inseguridades, es mejor usar sólamente el protocolo 2, aunque en Debian ya viene así por defecto, para otras distros editaremos el fichero de configuración /etc/ssh/sshd_config
y cambiaremos la opción:
# /etc/ssh/sshd_config Protocol 2
Nota: Al efectuar cualquier cambio en la configuración de SSH, debemos reiniciar el servicio para que sea efectivo en los siguientes accesos. La sesión a través de la que estamos conectados no se verá afectada. Por ejempo en Debian ejecutaríamos /etc/init.d/sshd restart
.
# /etc/init.d/sshd restart
Autenticación mediante llave RSA:
Entrar con usuario y password está muy bien, pero nuestro servidor será pasto de los niñatos-scriptadores y de los lamers (el día que tenga tiempo me voy a dedicar a cascarles un HoneyPot y a denunciarlos a la Guardia Civil) provistos de diccionarios de claves. En unos días observaremos como hay continuos intentos de autenticación desde las mismas IPs, con vanos resultados si nuestra clave es medianamente complicada, pero… ¿Por qué arriesgarse?
Creando nuestra llave RSA:
Esto lo haremos en nuestra própia máquina, portátil o desktop, no en el servidor que estamos fortificando.
# ssh-keygen -t rsa
Este programa lo que hace es generar un par de claves rsa, con una parte pública, que es la que pondremos en los servidores y la que podemos pasar a cualquiera sin problemas, por ejemplo a otro administrador para que la ponga en un servidor de un cliente y poder acceder nosotros también, y una privada, que deberemos conservar en secreto, en nuestro ordenador y con al menos una copia de seguridad a buen recaudo.
Al ejecutar el comando anterior nos pedirá una «passphrase» o «frase de paso», es decir, una clave. La podemos dejar en blanco si queremos, si nadie accede a nuestra llave privada RSA, el método es seguro, no hace falta una passphrase que puede ser un poco incordio, pero si queremos una mayor seguridad, podemos asignarla, de esta forma el cliente SSH nos pedirá la passphrase cada vez que necesite utilizar la llave, y aunque alguien se haga con nuestra llave, no se servirá de mucho sin ella.
Colocando nuestra llave en el servidor:
Nuestra llave se guarda en el directorio .ssh
de nuestra carpeta personal o home, concretamente nuestra llave pública está en ~/.ssh/id_rsa.pub
,y queremos ponerla en el fichero /root/.ssh/authorized_keys
del servidor.
Podemos utilizar diversos medios para ello, por ejemplo hacer un cat del llave pública, copiarla al portapapeles, editar el fichero del servidor de llaves autorizadas y pegarla. Así de fácil, eso funciona perfectamente.
Pero como tenemos acceso con password vamos a hacer una de estas cosas de BOFHER con las que los novatos se quedan pillaos una semana ;-), desde la máquina cliente:
# cat ~/.ssh/id_rsa.pub | ssh root@miserver.midominio.com -C "cat - >> /root/.ssh/authorized_keys"
Virguero, pero es muy fácil, le tiramos la llave pública al comando ssh por su entrada estándar, le decimos que comprima la transmisión (-C)
y en la remota ejecutamos cat de la entrada estándar con redirección añadida (>>)
al fichero de llaves autorizadas.
Habilitar autenticación mediante llave en el servidor:
En Debian no hace falta, ya viene por defecto y ya podemos acceder al servidor con nuestra llave, en otras distribuciones es posible que tengamos que modificar el fichero de configuración /etc/ssh/sshd_config
y cambiar estas opciones:
# /etc/ssh/sshd_config PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
Deshabilitar la autenticación por password:
Para fortificar de verdad el ssh deberíamos desactivar la autenticación mediante contraseña para todos los usuarios, especialmente para el root:
# /etc/ssh/sshd_config PasswordAuthentication no
Hay muchos admins que no permiten acceder como root al servidor (PermitRootLogin no)
y te obligan a entrar con un usario no privilegiado y ejecutar todo con sudo
. Personalmente opino que es innecesario y molesto en la mayor parte de los casos, suele ser suficiente, y mucho más cómodo, así:
# /etc/ssh/sshd_config PermitRootLogin withoutpassword
Es decir, se puede entrar como root pero sólo con llave, no con contraseña.
Cambiar el puerto por defecto:
Es rizar el rizo, y a veces ganar mucha incomodidad por un poquito más de seguridad, pero bueno, os contamos como hacerlo:
# /etc/ssh/sshd_config Port 25142
El puerto puede ser el que tú quieras, no tiene porque sér el 25142, aunque es recomendable poner uno alto, por ejemplo el 6666 y añadir alguna medida de protección contra el escaneo de puertos, pero eso ya queda fuera del alcance de este artículo.
En cualquier caso recuerda que no deberías utilizar los puertos privilegiados (< 1024)
porque normalmente se utilizan para otros servicios y están reservados, y que el número máximo de puerto es el 65535 (64K).
Buenas,
Gran artículo, nunca está de más repasar estos conceptos de securización para SSH. Creo (si no me equivoco) que te ha faltado comentar el baneo de IP’s, supongo que lo harás con host.allow y hosts.deny o algún software como denyhosts. Me gustaría tener tu opinión al respecto de cómo actuar en esos casos.
Por otra parte, ¿cómo se debería de actuar si se detectan intentos de login por parte de un supuesto atacante? ¿El baneo de IP a nivel de SSH sería suficiente? ¿Se complementaría con restringir por iptables el acceso a esa IP?
Gracias de nuevo y felicitaciones!
estos dos post te aclararán tus dudas de como lo hago yo 😀
https://blogofsysadmins.com/instalar-apf-advanced-policy-firewall-en-sistema-unix
https://blogofsysadmins.com/como-instalar-y-configurar-bfd-brute-force-detector