Tráfico de bots tras ataques a centros de datos de Yandex

Tráfico de bots tras ataques a centros de datos de Yandex

Observación cualitativa de nuestros operadores, no una medición. Tras los ataques notificados a centros de datos de Yandex, quienes leen los logs de servidores de DCXV percibieron que el tráfico de algunas redes de granjas de bots se había reducido: menos peticiones automáticas, menos intentos de fuerza bruta, menos peticiones HTTP POST sospechosas. No publicamos cifras, porcentajes, gráficos ni tasas, porque no hicimos una comparación controlada. El artículo explica qué miramos, cómo se ven estos tipos de tráfico en los logs, cómo reforzar un servidor sea cual sea el origen y cómo comprobar la afirmación por su cuenta.

Qué se informó

A principios de octubre, Reuters informó de que drones alcanzaron centros de datos de Yandex en dos días consecutivos, y Yandex dijo que varios módulos de su sede en la región de Kaluga quedaron inutilizados y que algunos servicios podrían verse afectados (informe de Reuters en The Star). No hemos confirmado estos hechos por nuestra cuenta y no tomamos postura sobre quién fue responsable. Este artículo trata solo de tráfico e higiene de servidores. Para el riesgo del proveedor, vea alojamiento con Yandex y en regiones de alto riesgo.

Qué miramos

Los operadores de DCXV leen cuatro cosas: logs del servidor web y del WAF, logs de autenticación SSH, accesos a nuestras rutas honeypot (URL que ningún visitante real abre) y el registro de errores HTTP. Los siguen a lo largo del tiempo como parte del trabajo normal. No hubo ventana fija de antes y después, ni línea base, ni grupo de control. Lo que sigue es la impresión de gente que sabe cómo suelen verse estos logs, nada más fuerte.

Cómo se ven estos tipos de tráfico en los logs

Importan tres patrones. Todos los ejemplos son ilustrativos: las direcciones salen de rangos de documentación y las marcas de tiempo son marcadores.

• Peticiones automáticas - las mismas rutas a un ritmo muy regular con un user agent genérico o vacío, a menudo buscando paneles de administración y scripts antiguos.
• Intentos de fuerza bruta - muchos inicios de sesión fallidos con distintos usuarios desde un origen, o un usuario probado desde muchos orígenes.
• Peticiones POST sospechosas - POST repetidos a login, XML-RPC o formularios, normalmente con respuesta 200 o 401 y sin visita previa a la página.

Líneas de ejemplo (ilustrativas, no tráfico real):

sshd[1234]: Failed password for invalid user admin from 203.0.113.7 port 51234 ssh2
sshd[1235]: Failed password for invalid user test from 203.0.113.7 port 51240 ssh2
203.0.113.9 - - [DD/Mon/YYYY:hh:mm:ss +0000] "POST /wp-login.php HTTP/1.1" 200 5120 "-" "Mozilla/5.0"
203.0.113.9 - - [DD/Mon/YYYY:hh:mm:ss +0000] "POST /xmlrpc.php HTTP/1.1" 200 420 "-" "Mozilla/5.0"

Lista de refuerzo que funciona con cualquier origen

Ningún paso depende de dónde venga el cliente. Hágalos en este orden y mantenga abierta una segunda sesión SSH mientras cambia sshd, para que un error de tecleo no le deje fuera. Más sobre claves en nuestra guía de SSH para un servidor cloud nuevo.

1. SSH solo con clave. Desactive contraseñas y el acceso root con contraseña, y pruebe la configuración antes de recargar:

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
MaxAuthTries 3
LoginGraceTime 20

sudo sshd -t && sudo systemctl reload ssh

2. fail2ban para sshd. Bloquee un origen tras unos pocos fallos:

# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime = 1h

3. Límite de peticiones en los endpoints de login con nginx. Frene un script sin molestar a una persona:

# http {} context
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# server {} context
location = /login {
    limit_req zone=login burst=5 nodelay;
    limit_req_status 429;
    proxy_pass http://127.0.0.1:3000;
}

• Reglas WAF - bloquee rutas de sondeo conocidas y cuerpos POST demasiado grandes o malformados; empiece en modo solo registro y después aplique.
• Protección de endpoints POST - exija token CSRF, limite el tamaño del cuerpo y devuelva el mismo error para usuario erróneo y contraseña errónea.
• CAPTCHA o desafío - muéstrelo solo tras varios fallos, no a cada visitante.
• Monitorización y alertas - avise ante un salto de inicios fallidos o de 4xx en POST y revise cada semana los orígenes principales.

Por qué bloquear un país es un control débil por sí solo

La geolocalización de IP es una estimación. Las VPN, los proxys y los servidores alquilados sitúan un bot en cualquier país, y una botnet de routers domésticos secuestrados está donde estén esos routers. Un bloqueo por país también frena a clientes reales, viajeros y socios. Puede ser una capa barata entre otras, pero no sustituye al SSH solo con clave, a los límites de peticiones ni a un WAF, y envejece mal cuando el tráfico pasa a otras redes.

Cómo comprobar la afirmación en sus propios servidores

Si quiere pruebas en lugar de impresiones, fije las reglas antes de mirar los datos:

• Fije las ventanas - elija periodos iguales de antes y después, con los mismos días de la semana, antes de abrir ningún log.
• Filtros idénticos - los mismos archivos de log, la misma regla de recuento, los mismos bloqueos y límites en ambos periodos.
• Tome una línea base - compare con un periodo tranquilo más largo, porque las campañas van y vienen sin evento externo.
• Agrupe por red, no por país - cuente por red de origen y anote aparte los rangos alquilados o de proxy.
• Anote sus propios cambios - una regla nueva de cortafuegos o un sitio movido puede parecer una tendencia.

Dos puntos de partida para ejecutar en cada ventana con los mismos filtros:

sudo journalctl -u ssh --since "24 hours ago" --no-pager | \
  grep "Failed password" | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

awk '$6 == "\"POST"' /var/log/nginx/access.log | \
  awk '{print $7}' | sort | uniq -c | sort -rn | head

Límites de nuestra observación

Léala como una hipótesis de un operador, no como un hallazgo:

• Correlación no es causalidad - dos hechos cercanos en el tiempo no están necesariamente vinculados.
• La atribución es imperfecta - la geolocalización IP y los datos ASN confunden VPN, proxys, infraestructura alquilada y botnets de otros países.
• El tráfico se desplaza - los bots pueden haber pasado a otras redes; menos desde un lugar no es menos en total.
• Una red no es internet - solo vemos lo que llega a nuestros servidores.
• Puede ser temporal, y caben otras causas: bloqueos en otros sitios, estacionalidad, campañas terminadas o nuestro propio filtrado.

Próximos pasos

Empiece por el SSH solo con clave y un límite de peticiones en el login: lleva minutos y ayuda frente a cualquier origen. Si necesita un servidor limpio para aplicar esta lista, vea nuestros servidores cloud en Praga y Covilhã, y use la lista para el periodo de prueba para probar uno bien. Preguntas u observaciones propias: sales@dcxv.com.