Cualquier servidor está expuesto a ataques de fuerza bruta. Brute Fail lo está demostrando en tiempo real

Ahora están probando con usuario 'root' y contraseña 'jk123456'. Ahora con 'test3' y '123456'. Y ahora con 'root' y 'P@$$word22'. Y así, sin parar. Un ataque tras otro. Ninguno tiene éxito, pero qué más da. Los hace una máquina. Una que no para de probar, por fuerza bruta, a entrar en los servidor del experto en ciberseguridad Mike Damm.

Este hacker, harto de que le ataquen, ha querido mostrar al mundo cómo está el panorama. Sus servidores no paraban de recibir ciberataques de fuerza bruta, así que montó una web llamada Brute.Fail en la que se puede ver en tiempo real todos los intentos de entrar en sus servidores con usuarios y contraseñas diversas.

En esa web se puede ver cómo los ciberataques tienen orígenes diversos: las IPs no paran de cambiar, algo habitual que los ciberatacantes hacen para esconder las pistas. En casi todos estos ataques el objetivo es el protocolo seguro SSH, que por defecto permite iniciar sesión en una máquina/servidor con un usuario y una contraseña.

Eso da pie a que los ciberdelincuentes traten de lograr acceso a esos servidores con sencillos ataques de fuerza bruta: se conectan a esos servidores y prueban parejas de usuario-contraseña hasta que 1) aciertan y logran acceso o 2) no aciertan y acaban siendo bloqueados temporal o permanentemente. A los ciberdelincuentes eso no les importa mucho: la tarea está tan automatizada que básicamente lo único que tienen que hacer es decirle a una máquina cuál es el objetivo.

Lo que logra Brute.Fail es demostrar que cualquier servidor está expuesto a este tipo de ataques de fuerza bruta. Puede que mucha gente que usa estos servicios no se dé cuenta de ello, pero lo más probable es que alguien esté tratando de ganar acceso a sus servidores por fuerza bruta.

Es un método con una tasa de éxito muy baja —al menos, si no usamos la contraseña maldita, '123456'—, pero también es uno que para el atacante tiene una tasa de coste/beneficio fantástica. La inmensa mayoría de ciberataques fracasarán, pero si alguno tiene éxito, el ciberdelincuente puede acabar haciendo mucho daño por ejemplo atacando después con algún tipo de ransomware.

¿Qué hacer para evitarlo? Hay diversas opciones. En el caso de esos ataques concretos a un servidor SSH, lo más fácil para poner una primera barrera no es usar usuario y contraseña, sino configurar el servidor para que use el tradicional esquema de clave pública y clave privada.

Hay otras medidas que se pueden tomar, desde luego, y que son igualmente conocidas en el mundo de los servidores. Hay por ejemplo sistemas y herramientas (fail2ban es muy conocida en entornos Linux, por ejemplo) que permiten "echar" temporal o permanentemente a quienes intentan conectarse a un servidor y no paran de meter usuarios/contraseñas incorrectas. Esas herramientas permiten configurar nuestro servidor para que por ejemplo, "bloquee accesos desde esta IP durante 24 horas si falla tres veces al intentar conectarse".

Como ocurre con nuestras cuentas de usuario en distintas plataformas, a los servidores que utilizamos también se les pueden instalar sistemas de autenticación en dos pasos (2FA). De ese modo al ciberdelincuente no le bastaría con lograr adivinar el usario y contraseña correctos: tendría además que introducir algún tipo de código que solo el administrador recibe, normalmente en su móvil, vía SMS (menos recomendable) o alguna aplicación de autenticación como Google Authenticator, Microsoft Authenticator o Authy, por ejemplo.

Al final la idea es la misma que se aplica a nuestras cuentas de correo, de banco o de redes sociales: añadir capas y "candados" hace que al ciberdelincuente le cuesta más tratar de acceder a esos objetivos. Puede intentarlo, desde luego, pero lo normal es que también acabe yendo a víctimas que no ponen tantas dificultades.

Imagen | Xataka con Midjourney

En Xataka | La verificación en dos pasos es fantástica e imperfecta. Google Authenticator es el mejor ejemplo de ello