Seguridad en SSH: uso de llaves privadas y multifactor (2FA) con Google Authenticator

SSH (Secure Shell - puerto 22) es esencial para la administración de un servidor remoto. En esta publicación te guiaremos a través de algunas de las opciones disponibles para fortalecer (hardening) OpenSSH.

Hardening Básico SSH

Consejos básicos

Configuración del servidor OpenSSH

El archivo de configuración de OpenSSH en Ubuntu 16.04 se encuentra en 

/etc/ssh/sshd_config

Deberá ser root o usar sudo para editar y controlar el servidor SSH.

Archivo de configuración de respaldo

Siempre es una buena idea hacer una copia de seguridad de los archivos de configuración antes de editarlos.

cp /etc/ssh/sshd_config /etc/ssh/backup.sshd_config

Editar el archivo de configuración

Puedes usar nano para editar archivos de configuración.

nano /etc/ssh/sshd_config

Prueba de configuración SSH

Después de editar el archivo de configuración, debe probar que sea válido antes de volver a cargar el servicio.

sshd -t

Vuelva a cargar el archivo de configuración

Una vez que crea que sus ediciones son buenas, vuelva a cargar el demonio SSH.

sudo systemctl reload sshd

Ver el Protocolo

Nuestra primera edición será muy sencilla. Realmente es más una doble verificación que una edición. Abra / etc / ssh / sshd_config y verifique la línea que comienza con Protocol. Asegúrese de que esté configurado en 2 y no en 1. El valor predeterminado actual es 2.

Protocol 2

Deshabilitar acceso root

En lugar de usar root, deberíamos usar la conexión como usuario con permiso sudo. Asegúrese de tener sudo configurado correctamente antes de continuar. Desactivemos la capacidad de root para iniciar sesión mediante SSH. Dentro del archivo de configuración, busque la línea:

PermitRootLogin yes

Cambia eso a no:

PermitRootLogin no

Desactivar re-envio de tráfico 

Pueden utilizar ssh para redireccionar tráfico

AllowTCPForwarding No

Desconectar sesiones inactivas

Las sesiones inactivas pueden ser peligrosas. Es una buena idea cerrar la sesión de las personas después de una cantidad determinada de inactividad. ClientAliveInterval es la cantidad de tiempo en segundos antes de que el servidor envíe un mensaje activo al cliente después de que no se hayan recibido datos. ClientAliveCountMax es el número de veces que comprobará antes de desconectarse. En el siguiente ejemplo, el servidor verificará al cliente después de 5 minutos de inactividad. Lo hará dos veces y luego se desconectará.

ClientAliveInterval 300

ClientAliveCountMax 2

Usuarios de la lista blanca

Podemos limitar los usuarios que pueden iniciar sesión en SSH. Esta es una lista blanca. Solo se permitirán los usuarios de esta lista. A todos los demás se les negará. Digamos que quiero permitir que el usuario elhackernet inicie sesión de forma remota a través de SSH. Agregaremos la línea:

AllowUsers elhackernet

No olvides agregar su nombre de usuario a la lista AllowUser.

Cambiar puertos

Otra forma menos favorita de reforzar SSH es cambiar el puerto predeterminado. Normalmente, SSH se ejecuta en el puerto 22. La idea es que la mayoría de los script kiddies solo apunten a ese puerto. Si cambias el puerto predeterminado, tal vez los ataques disminuyan. Pero recuerda que la seguridad por oscuridad no sirve de nada. No es una buena recomendación, En el archivo de configuración, busca la línea:

Port 22

Cambiar el puerto por otro disponible como quizás 2222.

Port 2222

Utilizar Llaves SSH en vez de contraseñas

De forma predeterminada, inicia sesión en el sistema a través de SSH con un nombre de usuario y una contraseña. Estos pueden ser de fuerza bruta. La gente probará una enorme cantidad de combinaciones de nombre de usuario y contraseña hasta que encuentre una que funcione. Entonces, en lugar de usar contraseñas, deberíamos usar claves SSH.

Generando un par de claves

Si ya tienes un par de claves, continúe.

Vamos a hacer algunas claves públicas de cifrado. Vienen en parejas. Privado y publico. 

Ejecute el siguiente comando para generar sus claves en la máquina cliente. No ejecutes este comando sudo. Le pedirá una frase de contraseña para proteger la clave. Puede dejarlo en blanco, pero no lo recomiendo. Cualquier persona que posea esa clave puede utilizar una clave SSH privada sin protección de contraseña para acceder al servidor.

ssh-keygen

Comparte tu clave pública

Utiliza ssh-copy-id para enviar su clave pública al servidor.

ssh-copy-id ns2@192.168.0.5

Ahora intenta iniciar sesión. Es posible que te solicite tu contraseña.

ssh ns2@192.168.0.5

Deberías recibir un mensaje que también se vea similar a:

The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.

ECDSA key fingerprint is ff:fd:d5:f9:66:fe:73:84:e1:56:cf:d6:ff:ff.

Are you sure you want to continue connecting (yes/no)?¿Está seguro de que desea continuar conectándose (sí / no)?

Di que sí y deberías iniciar sesión sin contraseña.

Deshabilitar la autenticación con contraseña

Si tenemos claves SSH en funcionamiento, podemos deshabilitar todas las autenticaciones de contraseña. Encuentra la línea:

PasswordAuthentication yes

Y cámbialo por no:

PasswordAuthentication no

Deshabilitar el reenvío X11

Esta guía está diseñada para su uso con servidores remotos. En términos generales, no hay razón para usar una GUI para un servidor remoto. Así que deshabilite el reenvío X11. Encuentra la línea:

X11Forwarding yes

y cámbialo a no.

X11Forwarding no

Fail2Ban

Es un gran programa que puede escanear registros y prohibir temporalmente las direcciones IP en función de una posible actividad maliciosa. Necesitarás instalar Fail2ban.

apt-get install fail2ban

Una vez instalado, copiamos el archivo de configuración de fail2ban.

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Abra los archivos

 /etc/fail2ban/jail.local 

y busca el lugar que comienza [sshd]. Edítelo así, agregando 

enabled = true:

[sshd]

 enabled = true

port = ssh

logpath =% (sshd_log) s

Luego reinicia fail2ban

service fail2ban restart

Fail2ban supervisará sus registros SSH para detectar posibles actividades maliciosas y luego prohibirá temporalmente la IP de origen.

Nosotros hemos aprovechado Fail2Ban para reportar Ip's con intentos de inicio de sesión al servicio AbuseIPDB usando la API de reportes  automáticos. De momento hemos configurado sólo algunos servicios (categorías) como SSH y BruteForce (que por otro lado, son los más habituales)

• Listado Ip's intentos fallidos fuerza bruta por SSH

Autenticación multifactor SSH - 2FA 

Añade un segundo factor de autenticación en SSH

MFA responde a Multi-Factor Authentication (Autenticación Multi-Factor). Consiste en requerir autenticación adicional, además de introducir nuestros datos habituales de usuario y contraseña. Es un aliado a la hora de mitigar ataques y vulneraciones a diversos tipos de cuentas, ya que los pasos de autenticación que se añadan se ubican en el último lugar antes de poder acceder a las cuentas

Time-based One-time Password: TOTP 

La contraseña única basada en el tiempo es un algoritmo informático que genera una contraseña única que utiliza la hora actual como fuente de singularidad.

TOTP quiere decir Time-Based One-Time Password. Es una variante de la autenticación multi-factor que funciona gracias a un código que se genera de forma aleatoria. Este último actúa como un token (ficha) de autenticación. Los códigos se generan mediante aplicaciones, como la conocida Google Authenticator y cambian después de un corto período de tiempo. Si un atacante desea vulnerar accesos tuyos con MFA integrado, debería contar también con tu móvil u otros dispositivos que hayas autorizado.

TOTP es en realidad la evolución de HOTP, siglas de «HMAC-based One-time Password». TOTP también está basado en el procedimiento HMAC, la operación hash en segundo plano. Tanto el dispositivo del usuario como el servidor generan un valor hash a partir de la contraseña secreta en combinación con un contador. Dado que ambos valores son idénticos, la autentificación funciona.

También podemos utilizar TOTP (contraseñas de un solo uso basadas en el tiempo) para fortalecer nuestra seguridad SSH. En este ejemplo usaremos Google Authenticator. Cuando intentemos iniciar sesión en el sistema, seremos desafiados a proporcionar un código de verificación. Usaremos la aplicación Google Authenticator para generar ese código. Primero necesitamos instalar algún software.

sudo apt-get install libpam-google-authenticator

 

O en CentOS y derivadas

 yum install google-authenticator

Luego ejecuta la inicialización

google-authenticator

Entiendo la molestia de muchas personas por el problema que tienen al usarla en un nuevo dispositivo. Les recomiendo esto: en cada red social que utilicen, SIEMPRE, generen códigos de respaldo. Si una red social no les brinda eso, ni de locos usen esta app. Ahora bien, también les recomiendo lo siguiente, en esta app pueden exportar sus cuentas mediante código QR y así evitar perder sus cuentas enlazadas. A ese código tómenle FOTO. Y listo, cuando reinstalen, solo escanean ese código.

Le preguntará: ¿Desea que los tokens de autenticación se basen en el tiempo (y / n) y debemos decir que sí? Luego imprimirá el código QR y preguntará si desea actualizar nuestro archivo .google_authenticator. 

Do you want authentication tokens to be time-based (y/n)

¡Escanea ese código en la aplicación Google Authenticator y guarde esos códigos de emergencia! A continuación, se le harán algunas preguntas más. Responderemos a todos con un sí.

Do you want to disallow multiple uses of the same authentication

token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, tokens are good for 30 seconds and in order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of 1:30min to about 4min. Do you want to do so (y/n) y

If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n) y)

Edita el archivo de reglas PAM

 /etc/pam.d/sshd

y añade lo siguiente al final:

auth required pam_google_authenticator.so

 

 Edite el archivo de configuración de ssh.

UsePAM yes

ChallengeResponseAuthentication yes

Y reinicie el servidor SSH. El sistema ahora requerirá un código de verificación cuando inicie sesión en el servidor.

systemctl restart sshd.service

Banners y MOTD

La forma menos favorita de fortalecer SSH es agregar palabrería legal al banner ssh y MOTD. Por lo general, alguna declaración redundante que diga "está prohibido el acceso no autorizado". Este es el teatro de seguridad. El consejo generalmente lo dan los mismos abogados de sillón que agregan "avisos de confidencialidad" al final de los correos electrónicos. Si un abogado estadounidense real dice que necesita esto para estar protegido por la CFAA, necesita un nuevo abogado. Creo que este mito se originó a partir de una comprensión deficiente de la Ley de uso indebido de computadoras del Reino Unido de 1990 y la jurisdicción legal básica. Además, si le pregunta a un policía encubierto si es policía, no tiene por qué decir que sí.

Bandera

A menudo, la gente hablará sobre la información del sistema de filtración de banners. Dejarán de lado el hecho de que el Banner está deshabilitado por defecto en Ubuntu 16.04. Permitámosle ver qué pasa. Este banner se envía antes de la autenticación. Todos los que intenten conectarse a través de SSH verán este banner. Es posible que deba habilitar PasswordAuthentication para ver el banner.

Edite el archivo de configuración SSH, luego busque y elimine el comentario:

#Banner /etc/issue.net

Ahora intente conectarse al servidor con un usuario falso:

ssh fake_user@192.168.1.1

Recibimos de vuelta.

Ubuntu 16.04.3 LTS

fake_user@192.168.1.1's contraseña:

Como puede ver, el sistema ha anunciado información del sistema.

Podemos editar este mensaje editando

 /etc/issue.net

 Voy a agregar un conejito de arte ascii para dar la bienvenida a mis "invitados".

______________________

| |

| Bienvenido Leet Haxor |

| ____________________ |

       ||

(\ _ /) ||

(*, *) ||

(") _ (")

Ahora intente conectarse al servidor con un usuario falso:

ssh fake_user@192.168.1.1

Y recibe el mensaje de bienvenida del banner:

______________________

| |

| Bienvenido Leet Haxor |

| ____________________ |

       ||

(\ _ /) ||

(*, *) ||

(") _ (") fake_user@192.168.1.1 password:

Esos hackers ahora lo pensarán dos veces antes de meterse con nosotros.

MOTD

Después de iniciar sesión, se muestra a los usuarios el mensaje del día (MOTD). Se verá algo como esto:

Bienvenido a Ubuntu 16.04.3 LTS (GNU / Linux 4.13.17-x86_64-linode69 x86_64) * Documentación: https://help.ubuntu.com

* Gestión: https://landscape.canonical.com

* Soporte: https://ubuntu.com/advantage

Último inicio de sesión: lun 19 de febrero 16:01:33 2018 desde 192.168.1.1

Ubuntu 16.04 usa un MOTD dinámico. Solo estaremos editando el encabezado del mensaje. Antes de cambiar nada, hagamos una copia de seguridad de ese encabezado original.

cp /etc/update-motd.d/00-header /etc/update-motd.d/backup.00-header

Abre 

/etc/update-motd.d/00-header

agrega lo siguiente al final del archivo:

figlet "No Trespassing"

Ahora cuando nos conectamos obtenemos:

Bienvenido a Ubuntu 16.04.3 LTS (GNU / Linux 4.14.17-x86_64-linode99 x86_64) _ _ _____ _

| \ | | ___ | _ _ | __ ___ ___ _ __ __ _ ___ ___ (_) _ __ __ _

| \ | | / _ \ | || '__ / _ \ / __ | '_ \ / _` / __ / __ | | '_ \ / _` |

| | \ | (_) | | || | | __ / \ __ \ | _) | (_ | \ __ \ __ \ | | | | (_ | |

| _ | \ _ | \ ___ / | _ || _ | \ ___ || ___ / .__ / \ __, _ | ___ / ___ / _ | _ | | _ | \ __, |

                                 | _ | | ___ / * Documentación: https://help.ubuntu.com

* Gestión: https://landscape.canonical.com

* Soporte: https://ubuntu.com/advantage

Hardening Avanzado

Auditoría SSH

Hasta ahora hemos estado cubriendo los conceptos básicos. Ahora pasamos a un "endurecimiento" (hardening) SSH más avanzado. SSH Audit (1) es un script de Python que escaneará su servidor SSH en busca de algunos problemas de seguridad. Descárguelo y ejecútelo como cualquier otro script de Python, simplemente apúntelo a su servidor SSH de destino.

• SSH Audit 2

python ssh-audit.py ns2.ehacker.net

Entonces obtenemos un informe bastante extenso.

Este informe nos da un vistazo detrás de la cortina de SSH. Este es un informe sobre los cifrados y algoritmos utilizados por su servidor SSH para asegurar las comunicaciones con el cliente. Si ha trabajado con OpenSSL, algunas cosas pueden resultarle familiares. Como puede haber aprendido con OpenSSL, no todos los cifrados y algoritmos son iguales. Algunos son fuertes y otros son débiles. Eliminar los débiles puede ayudar a fortalecer su sistema.

• https://infosec.mozilla.org/guidelines/openssh

Cambiar la preferencia de la clave de host

Seguiremos los consejos de stribika, mozilla y el informe de auditoría de SSH. Cambiaremos nuestras preferencias de HostKey. Elimina las entradas actuales de HosyKey en el archivo de configuración ssh. Reemplácelos con lo siguiente.

HostKey /etc/ssh/ssh_host_ed25519_key

HostKey /etc/ssh/ssh_host_rsa_key

Cambiar cifrados y algoritmos predeterminados

Continuar siguiendo los consejos de stribika, mozilla y el informe de auditoría de SSH. Cambiamos nuestros algoritmos de intercambio de claves, cifrados simétricos y códigos de autenticación de mensajes. Agregue o reemplace lo siguiente al archivo de configuración ssh.

KexAlgorithms curve25519-sha256@libssh.orgCiphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctrMACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Vuelva a ejecutar la auditoría

Veamos si nuestros cambios hicieron feliz a la auditoría SSH.

python ssh-audit.py ns2.elhacker.net

Módulos regenerados

El archivo 

/etc/ssh/moduli

contiene números primos y generadores utilizados por el servidor SSH para el intercambio de claves Diffie-Hellman. Su / etc / ssh / moduli actual probablemente no sea único. La generación de un nuevo archivo puede fortalecer su servidor. La generación de estos archivos puede llevar un tiempo.

ssh-keygen -G moduli-2048.candidates -b 2048

ssh-keygen -T moduli-2048 -f moduli-2048.candidates

cp moduli-2048 /etc/ssh/moduli

rm moduli-2048

Con suerte, esto le ha resultado útil y ahora será un poco más difícil ingresar a su servidor. Hay mucho más que aprender sobre OpenSSH. Buena suerte.

Fuente
https://medium.com/@jasonrigden/hardening-ssh-1bcb99cd4cef