Mitigación de la Vulnerabilidad CVE-2018-20685 en OpenSSH

La seguridad de los servidores es crucial para cualquier entorno de desarrollo y administración, especialmente cuando se trata de proteger accesos remotos a través de SSH. En este contexto, me encontré con la vulnerabilidad CVE-2018-20685, la cual afecta al cliente scp en OpenSSH 7.9. Esta vulnerabilidad puede permitir que los servidores SSH remotos eludan restricciones de acceso usando ciertos nombres de archivos, lo cual tiene un impacto en la integridad de los datos y la seguridad del servidor. En este artículo, explicaré en detalle en qué consiste esta vulnerabilidad, su impacto, y las acciones que tomé para mitigarla y reforzar la seguridad de mi servidor.

¿Qué es la vulnerabilidad CVE-2018-20685?

La vulnerabilidad CVE-2018-20685 afecta a la versión OpenSSH 7.9 y reside en el archivo scp.c, que forma parte del cliente scp. Permite que un atacante, actuando como servidor SSH remoto, eluda las restricciones de acceso a través del uso de ciertos nombres de archivo, como . o nombres vacíos. Esto implica que un atacante puede modificar los permisos de archivos en el cliente que está transfiriendo archivos usando scp, lo cual podría resultar en la alteración de archivos importantes, comprometiendo así la seguridad del sistema.

El impacto de esta vulnerabilidad está clasificado con una severidad de 5.3 (Media) en el sistema CVSS (Common Vulnerability Scoring System), lo que indica un riesgo que requiere atención, ya que afecta la integridad de los datos y podría resultar en consecuencias indeseadas, especialmente en entornos productivos.

La vulnerabilidad tiene un impacto directo sobre la integridad de los datos transferidos, y el hecho de que sea posible modificar los permisos sin la autorización del cliente hace que sea necesario implementar medidas de mitigación efectivas. Como desarrollador y administrador responsable, mi principal prioridad fue garantizar que esta vulnerabilidad no se convirtiera en una puerta de entrada para ataques potenciales.

Acciones de Mitigación

Para mitigar esta vulnerabilidad y mejorar la seguridad general del servidor, llevé a cabo una serie de acciones que describiré a continuación, detallando el significado, la función y el impacto de cada medida.

1. Actualizar OpenSSH

La primera acción fue asegurarme de que mi versión de OpenSSH estaba actualizada a una posterior a la 7.9, donde esta vulnerabilidad ya había sido corregida. Para actualizar OpenSSH, utilicé el siguiente comando:

sudo apt update && sudo apt install openssh-client

Mantener OpenSSH actualizado es esencial, ya que las actualizaciones no solo resuelven vulnerabilidades conocidas, sino que también incluyen mejoras en la seguridad y nuevas funcionalidades que hacen al servidor menos vulnerable a los ataques. Además, al mantener todo el software actualizado, se minimizan los riesgos asociados con vulnerabilidades conocidas que los atacantes podrían explotar. Las actualizaciones regulares permiten estar un paso adelante frente a cualquier amenaza potencial, manteniendo la infraestructura segura y confiable.

2. Uso de Autenticación con Clave Pública

Opté por usar autenticación con clave pública en lugar de contraseñas. Esto significa que el acceso al servidor SSH sólo es posible si tengo la clave privada correspondiente, haciendo mucho más difícil que un atacante pueda acceder al servidor usando ataques de fuerza bruta o técnicas de adivinación de contraseñas. Cabe destacar que el uso de claves públicas SSH debería ser algo obvio en la configuración de cada sistema, por lo tanto, no entraré en detalles sobre la configuración básica de las claves públicas para conectarse al servidor.

Usar claves públicas es una práctica estándar que refuerza la seguridad en comparación con el uso de contraseñas, ya que estas últimas pueden ser adivinadas mediante ataques automatizados. La autenticación con clave pública asegura que el acceso esté limitado a aquellos usuarios que posean la clave privada, proporcionando un nivel de seguridad significativamente mayor.

Finalmente, deshabilité la autenticación por contraseña editando el archivo /etc/ssh/sshd_config:

PasswordAuthentication no

Esto asegura que no se pueda acceder mediante contraseñas, eliminando un vector de ataque común en los servidores SSH.

Y reinicié el servicio SSH para aplicar los cambios:

sudo systemctl restart ssh

3. Cambiar el Puerto de SSH

El siguiente paso fue cambiar el puerto por defecto de SSH (22) por otro menos conocido. Este simple cambio reduce significativamente los intentos de acceso automatizados, ya que la mayoría de los ataques de fuerza bruta buscan servicios SSH en el puerto 22.

• ¿Qué hace esto?: Modifica el puerto de escucha de SSH para que los atacantes automáticos no encuentren el acceso fácilmente.
• ¿Para qué?: Reduce los intentos de acceso por herramientas automáticas que buscan el puerto estándar.

Para hacer esto, edité el archivo /etc/ssh/sshd_config y cambié el puerto:

Port 2222

Luego, reinicié el servicio SSH:

sudo systemctl restart ssh

Además, actualicé el firewall (ufw) para permitir el nuevo puerto y denegar el puerto 22:

sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp
sudo ufw reload

Este cambio de puerto no garantiza por sí solo una seguridad absoluta, pero sí reduce significativamente el ruido causado por intentos de acceso automatizados que buscan el puerto 22, el cual es el estándar para SSH. Al cambiar el puerto, los atacantes tendrán que esforzarse más para identificar el servicio, lo cual actúa como una medida de disuasión adicional.

4. Deshabilitar el Acceso de Root por SSH

También deshabilité el acceso directo del usuario root por SSH. Esto impide que un atacante pueda conectarse directamente como administrador, limitando los riesgos de acceso no autorizado con privilegios elevados.

• ¿Qué hace esto?: Evita que el usuario root pueda acceder directamente al servidor.
• ¿Para qué?: Protege contra ataques que buscan comprometer al administrador directamente, forzando al atacante a acceder primero como usuario limitado.

El usuario root tiene privilegios completos sobre el sistema, por lo cual deshabilitar el acceso remoto es una medida fundamental para minimizar riesgos. Si un atacante lograra acceder como root, tendría control total sobre el servidor, lo que podría tener consecuencias desastrosas. Para lograr esto, edité /etc/ssh/sshd_config:

PermitRootLogin no

Y luego reinicié el servicio SSH:

sudo systemctl restart ssh

Esta configuración asegura que los accesos al sistema sean más controlados y que incluso si un atacante conoce la contraseña de un usuario limitado, no pueda escalar fácilmente a root.

5. Limitar el Número de Intentos de Autenticación

Limitar el número de intentos de autenticación ayuda a prevenir ataques de fuerza bruta. Configuré SSH para permitir solo tres intentos fallidos antes de cerrar la conexión.

• ¿Qué hace esto?: Limita cuántas veces se puede intentar ingresar una contraseña incorrecta antes de cerrar la conexión.
• ¿Para qué?: Reduce el riesgo de que un atacante pueda adivinar contraseñas mediante repetidos intentos automáticos.

Para configurarlo, edité el archivo /etc/ssh/sshd_config y agregué:

MaxAuthTries 3

Luego reinicié el servicio SSH:

sudo systemctl restart ssh

Reducir el número de intentos permitidos aumenta la seguridad al evitar que los atacantes puedan intentar repetidamente hasta acertar con la contraseña. Esto, combinado con el uso de claves públicas, disminuye significativamente el riesgo de comprometer el servidor.

6. Configurar Fail2ban para Bloquear IPs Sospechosas

Finalmente, configuré Fail2ban para proteger el servidor contra ataques de fuerza bruta. Fail2ban monitorea los registros del servidor y bloquea temporalmente las IPs que intentan repetidamente acceder de manera fallida.

• ¿Qué hace esto?: Analiza los logs del servidor y, si detecta varios intentos fallidos desde una misma IP, la bloquea durante un período específico.
• ¿Para qué?: Impide que un atacante pueda seguir intentando acceder una vez superado un límite de fallos, proporcionando una capa de defensa activa contra ataques persistentes.

Para instalar y configurar Fail2ban, ejecuté:

sudo apt install fail2ban

Luego edité el archivo de configuración /etc/fail2ban/jail.local para activar la protección de SSH:

[sshd]
enabled = true
maxretry = 3
bantime = 3600  # Tiempo de bloqueo de 1 hora

De forma opcional, puedo agregar para definir un tiempo durante el cual se contabilizan los intentos fallidos. Por ejemplo, si deseo que 3 intentos fallidos en 10 minutos activen el bloqueo:

findtime = 600  # 600 segundos equivalen a 10 minutos

Finalmente, reinicié Fail2ban:

sudo systemctl restart fail2ban

Fail2ban es una herramienta efectiva para disuadir a los atacantes, ya que los bloqueos temporales pueden aumentar exponencialmente el tiempo necesario para que un atacante intente realizar un ataque de fuerza bruta exitoso. Esto, combinado con un límite bajo de intentos de autenticación, garantiza que el servidor sea mucho más seguro y menos susceptible a ser comprometido mediante ataques automatizados.

Conclusión

La vulnerabilidad CVE-2018-20685 representa un riesgo significativo si no se toman medidas para corregirla y prevenirla. Con el objetivo de proteger mi servidor, tomé varias acciones que refuerzan tanto la seguridad del acceso SSH como la protección contra ataques de fuerza bruta y acceso no autorizado. Estas medidas, combinadas, reducen significativamente los riesgos y aseguran que el acceso a mi servidor sea lo más seguro posible. La seguridad de los servidores es una responsabilidad continua, y estas acciones son solo una parte del esfuerzo constante para mantener la infraestructura segura y protegida.

Cada una de las acciones descritas aquí no solo tiene como objetivo corregir una vulnerabilidad específica, sino también fortalecer la seguridad general del servidor y anticiparse a futuros intentos de ataque. La seguridad es un proceso constante que requiere ajustes, monitoreo y actualizaciones regulares. Mi objetivo es mantener una infraestructura robusta y segura, minimizando riesgos y garantizando que cualquier servicio que se ejecute esté protegido frente a amenazas externas y posibles vulnerabilidades.