SSH es uno de los protocolos/servicios más utilizados en la gestión de máquinas y servidores de forma remota. Por esta razón la configuración y fortificación de este protocolo es fundamental. En este artículo vamos a ver algunos consejos para mejorar la seguridad y algunos otros para comprobar dicha seguridad, ya que es uno de los más expuestos y por ende de los más atacados también.
Ya hemos visto en los últimos años como ha habido varios problemas con configuraciones SSH, incluso vulnerabilidades. Solo hay que recordar el caso de SSHowDown y los millones de dispositivos IoT afectados y su participación en la botnet Mirai. Algo que obliga a todos los administradores de servidores SSH a tener una extremada precaución en la fortificación de sus servidores.
Esto nos llevó a realizar un trabajo de fortificación de SSH en Paranoid Mode que hicimos en ElevenPaths en el que utilizamos muchas medidas de protección como Port-Knocking usando Latch para reducir la exposición del servicio a los escaneos de red que los buscan, el uso de Latch Cloud TOTP como 2nd Factor Authorization, y los certificados digitales como mecanismo de autenticación. Todo esto, lo publicamos en el artículo de Cómo configurar tu SSH en Paranoid Mode.
Figura 3: Demo de Port-Knocking + Latch Cloud TOTP & Aut + Lath como 2FA
Por otro lado, para la enumeración de usuarios hemos visto que se podían realizar ataques Time-Based Blind User Enumeration en OpenSSH, de los que hemos tenido que preocuparnos también, lo que deja claro que cualquier pequeño detalle de seguridad puede proporcionar cierta ventaja a un atacante que descubra una mala configuración o una vulnerabilidad de versión.
Por esto, revisamos cualquier configuración, como vimos que se podía hacer con la aplicación Lynis, una herramienta más que interesante para evaluar la seguridad de la configuración de nuestro servicio SSH.
Hoy queremos hacer un recopilatorio de algunos consejos y trucos que ayudan a la fortificación y lo mismo para que los administradores o miembros de los Blue Team o Red Team puedan comprobar si la fortificación es adecuada.
Tips sobre fortificación de SSH
Existen muchas recomendaciones y debate sobre la fortificación del protocolo SSH. Pero al final se debe seguir un patrón muy sencillo que es la de aplicar los principios de la fortificación de cualquier sistema, es decir aplicar los objetivos de Mínima Superficie de Exposición posible, Mínimo Privilegio Posible y, por supuesto, Defensa en Profundidad, que es significa aplicar cualquier medida de seguridad en cada nivel asumiendo que las medidas anteriores han fallado, siempre y cuando una medida no anule a otra.
Un ejemplo de medida del primer tipo, es decir de conseguir la Mínima Superficie de Exposición, es la medida que comentamos al inicio de este artículo de utilizar un mecanismo de Port-Knocking para que se habilite el puerto de conexión del servicio SSH. El servicio aparecerá como cerrado hasta que haya una combinación de peticiones previas a un puerto o se haya hecho algún tipo de de autorización para que el servicio SSH se encuentre activo, como explicamos en MySSH en Paranoid Mode.
Esta simple acción pude minimizar mucho el riesgo de la exposición de un servicio a Internet. Es cierto que, para muchos usuarios, será un “ajetreo” tener que realizar alguna acción para habilitar durante X segundos el servicio SSH y conectarse a él. Como todo en la vida, hay que valorar y evaluar los riesgos y la productividad que se necesita. Ni mejor, ni peor. Simplemente una opción que aporta la ciberseguridad y el hardening paranoico.
Figura 7: Demo de Port-Knocking con Latch
Por otro lado, tenemos medidas para conseguir que todo se ejecute en el servidor con el Mínimo Privilegio Posible, para que, en caso de quedar comprometido un módulo, los permisos que haya obtenido el atacante sean los menores posibles. Es decir, en el caso de que un servidor sea vulnerado debemos poner las cosas difíciles por defecto. Si ejecutamos el SSH con el usuario root y éste es comprometido tendremos un grave problema. Si el daemon SSH es vulnerado, pero éste se está ejecutando sin ningún privilegio, el problema es menor, aunque seguimos teniendo un problema.
Además, otra forma de hacer mínimo privilegio posible es que el login que se haga sea el de un usuario sin privilegio. Por ejemplo, el usuario root no puede hacer login con el SSH, pero una vez dentro con el usuario “pepito” se podría pasar al usuario “root” una vez se tiene una consola remota. Es una forma de evitar que mediante fuerza bruta se pueda hacer ataques al servicio SSH y que alguien pueda “adivinar” la contraseña del usuario. En el caso de que un “bot” pueda hacer fuerza bruta contra el servicio debe conocer la existencia de un usuario “pepito” y la contraseña de éste. Si dejamos que root pueda hacer login, ya fijamos una de las dos variables, por lo que la cosa se simplifica, es decir, hacemos que un atacante tenga más fácil el atacarnos.
Para evitar los ataques de fuerza bruta debemos contemplar el uso de herramientas como Fail2Ban. Este tipo de herramientas permiten configurar reglas para poder bloquear direcciones IP, usuarios, etcétera, que intenten realizar fuerza bruta en el sistema. Fail2Ban está desarrollada en Python y tiene como función penalizar la conexión de una dirección IP origen que intenta fuerza bruta. Fail2ban se encarga de realizar la búsqueda en los logs de ciertas aplicaciones, no solo en el SSH, pero en este caso se puede utilizar para SSH.
Cuando Fail2ban detecta una serie de intentos fallidos por parte de una dirección IP, la aplicación tomará la acción programada sobre dicha dirección IP. Por supuesto, el administrador puede ser notificado de este evento, por ejemplo, a través del correo electrónico. Además, se puede bloquear puerto o puertos a través del uso del firewall que corresponda de forma automática al ejecutarse una regla de Fail2ban.
Ahora, vamos a recordar consejos básicos de configuración y fortificación de entornos SSH para aplicar medidas de Defensa en Profundidad. Directamente los vamos a enumerar. Todos se habilitan, se deshabilitan o se configuran a través del fichero /etc/ssh/sshd_config:
Y ahora, vamos a ver algunos consejos para lo contrario, es decir, para auditar si la configuración de seguridad es la correcta o existe alguna debilidad que pueda ser aprovechado. En el principio del artículo ya hemos visto algunos vectores de ataque para enumerar usuarios, para realizar fuerza bruta o para verificar la versión y las posibles vulnerabilidades del servicio.
En esta parte no vamos a reinventar la rueda y lo único que vamos a hacer es enumerar una serie de vectores que pueden ser utilizados en un proyecto de Ethical Hacking o en un ejercicio de Red Team:
Por supuesto que aquí no acaba el tema. Se puede hacer uso de guidelines para fortificar y atacar servidores SSH. Mozilla proporciona una guía interesante sobre este tema, la cual se recomienda echar un ojo. Por último, respecto al tema del pivoting, una de las técnicas necesarias en las auditorías internas de sistemas, podemos encontrar un listado de técnicas basadas en SSH interesantes. De estas ya iremos hablando, tal y como hablamos de la primera de ella ya en otro artículo, pero toma nota de ellas.
• SSH Local port Forwarding
• SSH Reverse port Forwarding
• SSH Dynamic port Forwartding
• SSH Reverse port Forwarding junto a Proxy SOCKS
• VPN sobre SSH
• Túnel HTTP sobre SSH
• Proxy transparente sobre SSH
Todas ellas son técnicas para estudiar en profundidad, y las iremos desgranando en diferentes artículos, pero tú puedes ir probándolo también. Espero que os sea de utilidad esta lista de "tips" para las dos cosas, para fortificar y para auditar servicios SSH, que hoy nos los encontramos en casi cualquier servidor, y en casi cualquier dispositivo industrial o de IoT.
Saludos,
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root", “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.
Para consultas puedes usar el Buzón Público para contactar con Pablo González
 |
| Figura 1: Servicios SSH: "Tips" de Auditoría y Fortificación |
Ya hemos visto en los últimos años como ha habido varios problemas con configuraciones SSH, incluso vulnerabilidades. Solo hay que recordar el caso de SSHowDown y los millones de dispositivos IoT afectados y su participación en la botnet Mirai. Algo que obliga a todos los administradores de servidores SSH a tener una extremada precaución en la fortificación de sus servidores.
|
Figura 3: Demo de Port-Knocking + Latch Cloud TOTP & Aut + Lath como 2FA
Por otro lado, para la enumeración de usuarios hemos visto que se podían realizar ataques Time-Based Blind User Enumeration en OpenSSH, de los que hemos tenido que preocuparnos también, lo que deja claro que cualquier pequeño detalle de seguridad puede proporcionar cierta ventaja a un atacante que descubra una mala configuración o una vulnerabilidad de versión.
 |
| Figura 4: Ataque de Time-Based Blind User Enumeration a SHH desde Kali Linux |
Por esto, revisamos cualquier configuración, como vimos que se podía hacer con la aplicación Lynis, una herramienta más que interesante para evaluar la seguridad de la configuración de nuestro servicio SSH.
 |
| Figura 5: Resumen de una auditoría de SSH hecha con Lynis |
Hoy queremos hacer un recopilatorio de algunos consejos y trucos que ayudan a la fortificación y lo mismo para que los administradores o miembros de los Blue Team o Red Team puedan comprobar si la fortificación es adecuada.
Tips sobre fortificación de SSH
Existen muchas recomendaciones y debate sobre la fortificación del protocolo SSH. Pero al final se debe seguir un patrón muy sencillo que es la de aplicar los principios de la fortificación de cualquier sistema, es decir aplicar los objetivos de Mínima Superficie de Exposición posible, Mínimo Privilegio Posible y, por supuesto, Defensa en Profundidad, que es significa aplicar cualquier medida de seguridad en cada nivel asumiendo que las medidas anteriores han fallado, siempre y cuando una medida no anule a otra.
Un ejemplo de medida del primer tipo, es decir de conseguir la Mínima Superficie de Exposición, es la medida que comentamos al inicio de este artículo de utilizar un mecanismo de Port-Knocking para que se habilite el puerto de conexión del servicio SSH. El servicio aparecerá como cerrado hasta que haya una combinación de peticiones previas a un puerto o se haya hecho algún tipo de de autorización para que el servicio SSH se encuentre activo, como explicamos en MySSH en Paranoid Mode.
 |
| Figura 6: Port-Knocking realizado con TCP Flags |
Esta simple acción pude minimizar mucho el riesgo de la exposición de un servicio a Internet. Es cierto que, para muchos usuarios, será un “ajetreo” tener que realizar alguna acción para habilitar durante X segundos el servicio SSH y conectarse a él. Como todo en la vida, hay que valorar y evaluar los riesgos y la productividad que se necesita. Ni mejor, ni peor. Simplemente una opción que aporta la ciberseguridad y el hardening paranoico.
Figura 7: Demo de Port-Knocking con Latch
Por otro lado, tenemos medidas para conseguir que todo se ejecute en el servidor con el Mínimo Privilegio Posible, para que, en caso de quedar comprometido un módulo, los permisos que haya obtenido el atacante sean los menores posibles. Es decir, en el caso de que un servidor sea vulnerado debemos poner las cosas difíciles por defecto. Si ejecutamos el SSH con el usuario root y éste es comprometido tendremos un grave problema. Si el daemon SSH es vulnerado, pero éste se está ejecutando sin ningún privilegio, el problema es menor, aunque seguimos teniendo un problema.
Además, otra forma de hacer mínimo privilegio posible es que el login que se haga sea el de un usuario sin privilegio. Por ejemplo, el usuario root no puede hacer login con el SSH, pero una vez dentro con el usuario “pepito” se podría pasar al usuario “root” una vez se tiene una consola remota. Es una forma de evitar que mediante fuerza bruta se pueda hacer ataques al servicio SSH y que alguien pueda “adivinar” la contraseña del usuario. En el caso de que un “bot” pueda hacer fuerza bruta contra el servicio debe conocer la existencia de un usuario “pepito” y la contraseña de éste. Si dejamos que root pueda hacer login, ya fijamos una de las dos variables, por lo que la cosa se simplifica, es decir, hacemos que un atacante tenga más fácil el atacarnos.
 |
| Figura 8: Fail2Ban |
Para evitar los ataques de fuerza bruta debemos contemplar el uso de herramientas como Fail2Ban. Este tipo de herramientas permiten configurar reglas para poder bloquear direcciones IP, usuarios, etcétera, que intenten realizar fuerza bruta en el sistema. Fail2Ban está desarrollada en Python y tiene como función penalizar la conexión de una dirección IP origen que intenta fuerza bruta. Fail2ban se encarga de realizar la búsqueda en los logs de ciertas aplicaciones, no solo en el SSH, pero en este caso se puede utilizar para SSH.
Cuando Fail2ban detecta una serie de intentos fallidos por parte de una dirección IP, la aplicación tomará la acción programada sobre dicha dirección IP. Por supuesto, el administrador puede ser notificado de este evento, por ejemplo, a través del correo electrónico. Además, se puede bloquear puerto o puertos a través del uso del firewall que corresponda de forma automática al ejecutarse una regla de Fail2ban.
Ahora, vamos a recordar consejos básicos de configuración y fortificación de entornos SSH para aplicar medidas de Defensa en Profundidad. Directamente los vamos a enumerar. Todos se habilitan, se deshabilitan o se configuran a través del fichero /etc/ssh/sshd_config:
• El login como root: La directiva es PermitRootLogin. En muchas ocasiones ya viene deshabilitada.Todos estos consejos y recomendaciones, y muchas más se puede encontrar en el libro de 0xWord titulado "Hardening a Servidores GNU/Linux", el cual escribí junto a mi compañero Carlos Álvarez, que hemos ido actualizando con el tiempo.
• Número de intentos para hacer login: Esta directiva permite cerrar la conexión tras una serie de intentos de login fallidos. La directiva es MaxAuthTries. Un número bajo de intentos es lo adecuado. Esto hará que una automatización de ataque tenga que realizar una nueva conexión cada vez que se cierra la conexión.
• Tiempo máximo de Login: Esta directiva indica el número de minutos o segundos que tenemos para realizar el login antes de cerrar conexión. La directiva es LoginGraceTime.
• La directiva AllowGroups y AllowUsers: Permiten gestionar que grupos o usuarios pueden hacer login en el servicio a través de SSH. Aquí se puede indicar un patrón del estilo [user]@[host], dónde host puede ser una dirección IP origen, por lo que se aplica un filtro de forma explícita en la conexión. La política contraria es DenyGroups y DenyUsers, las cuales hacen justamente lo contrario, una lista negra de usuarios y grupos que pueden conectarse a través de SSH.
• La directiva ClientAliveInterval y ClientAliveCountMax: son dos directivas que indican que si el servidor no recibe datos de un intervalo X la conexión se cerrará. En el caso de la segunda directiva, se enviarán un máximo de X mensajes, indicados por la directiva, solicitando al cliente datos, si éste no envía nada se cierra la conexión. Son directivas para identificar una conexión que se ha quedado perdida o “muerta”.
• La directiva LogLevel: es una directiva interesante para alimentar el log con información, el cual puede servir a otras herramientas forenses o de fortificación, como Fail2ban.
• La directiva para el tipo de autenticación: La recomendación en el mundo SSH es que la autenticación siempre vaya a través de public-key. Deshabilitar el login mediante password y otros métodos que no son interesantes para la seguridad.
• La directiva Ciphers: Esta directiva indica los tipos de algoritmos que se pueden utilizar entre el cliente y el servidor para fortificar la conexión. Es importante que los algoritmos sean robustos, así como que la versión del protocolo SSH sea la 2.
Y ahora, vamos a ver algunos consejos para lo contrario, es decir, para auditar si la configuración de seguridad es la correcta o existe alguna debilidad que pueda ser aprovechado. En el principio del artículo ya hemos visto algunos vectores de ataque para enumerar usuarios, para realizar fuerza bruta o para verificar la versión y las posibles vulnerabilidades del servicio.
 |
| Figura 9: Libro de Ethical Hacking de Pablo González |
En esta parte no vamos a reinventar la rueda y lo único que vamos a hacer es enumerar una serie de vectores que pueden ser utilizados en un proyecto de Ethical Hacking o en un ejercicio de Red Team:
• Password guessing / Fuerza bruta: Si se puede fijar un usuario X, porque conocemos de su existencia en el sistema, por ejemplo, con la enumeración de usuarios basados en tiempo de OpenSSH, se puede realizar un ataque de fuerza bruta o de diccionario. Este ejemplo, se puede llevar a cabo con diferentes herramientas, por ejemplo, Metasploit a través del módulo auxiliary/scanner/ssh/ssh_login. Otra de las herramientas que se puede utilizar es Medusa o NCrack.
• Vulnerabilidades sobre la versión del software que implementa el servicio SSH: Uno de los ejemplos más importantes es este CVE-2018-10933, también conocido como LibSSH RCE. En otras palabras, obtener la versión del software de la aplicación del SSH nos puede abrir una superficie de ataque importante, ya que con un exploit conocido, se puede llegar a lograr ejecutar código arbitrario en la máquina. En este punto se abre un abanico enorme, ya que aquí se habla de librería vulnerable, pero si el software no utiliza dicha librería, pero es vulnerable por otra circunstancia también se podría aplicar la vía exploit.
• Aplicación de fuzzing manual y automatizado: Este es otro vector que se puede utilizar, por ejemplo, a través del script sshfuzz.pl. Otra opción que se puede utilizar es un módulo de Metasploit llamado auxiliary/fuzzers/ssh/ssh_version_2. Hay más información sobre este tema en este interesante artículo.
• La herramienta ssh-audit: como hablamos antes de Lynis, es interesante para hacer una pequeña auditoría a la configuración del servidor SSH.
 |
| Figura 10: Herramienta ssh-audit |
Por supuesto que aquí no acaba el tema. Se puede hacer uso de guidelines para fortificar y atacar servidores SSH. Mozilla proporciona una guía interesante sobre este tema, la cual se recomienda echar un ojo. Por último, respecto al tema del pivoting, una de las técnicas necesarias en las auditorías internas de sistemas, podemos encontrar un listado de técnicas basadas en SSH interesantes. De estas ya iremos hablando, tal y como hablamos de la primera de ella ya en otro artículo, pero toma nota de ellas.
• SSH Local port Forwarding
• SSH Reverse port Forwarding
• SSH Dynamic port Forwartding
• SSH Reverse port Forwarding junto a Proxy SOCKS
• VPN sobre SSH
• Túnel HTTP sobre SSH
• Proxy transparente sobre SSH
Todas ellas son técnicas para estudiar en profundidad, y las iremos desgranando en diferentes artículos, pero tú puedes ir probándolo también. Espero que os sea de utilidad esta lista de "tips" para las dos cosas, para fortificar y para auditar servicios SSH, que hoy nos los encontramos en casi cualquier servidor, y en casi cualquier dispositivo industrial o de IoT.
Saludos,
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root", “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.
Para consultas puedes usar el Buzón Público para contactar con Pablo González
No hay comentarios:
Publicar un comentario