Alerta de seguridad NGINX bajo ataque por manipulación de proxy_pass para desviar tráfico

Si usas NGINX para servir sitios, hacer balanceo de carga o como proxy inverso, presta atención: recientemente se ha detectado una campaña en la que un actor malicioso compromete servidores con NGINX y herramientas de gestión de hosting para redirigir el tráfico de los usuarios a su propia infraestructura, manteniendo la apariencia de normalidad.

NGINX es, por diseño, un intermediario entre el visitante y el servidor final: recibe peticiones, aplica reglas, puede cachear y reenviarlas a otros backends. Esa flexibilidad es precisamente lo que estos atacantes explotan. Investigadores de Datadog Security Labs han documentado cómo los atacantes introducen bloques de configuración maliciosos dentro de archivos de NGINX —especialmente en instalaciones gestionadas con el panel Baota— para capturar rutas determinadas y reenviarlas mediante la directiva proxy_pass hacia servidores controlados por ellos. Puedes leer más sobre el trabajo de Datadog en la sección de seguridad de su blog (Datadog Security Labs).

Lo que hace la campaña es inyectar bloques location que coinciden con rutas elegidas por el atacante y reescriben la petición para incluir la URL original antes de encaminarla con proxy_pass a dominios externos. Para que la redirección parezca legítima, conservan cabeceras como Host, X-Real-IP, User-Agent o Referer. Dado que proxy_pass es una característica legítima y muy usada para balanceo y failover, su abuso pasa desapercibido si no se inspeccionan las configuraciones.

El modus operandi descubierto incluye un conjunto de scripts automatizados que actúan en etapas: un controlador inicial descarga y ejecuta los componentes restantes y puede incluso enviar peticiones HTTP en bruto por TCP si no hay herramientas como curl o wget; otro componente está dirigido específicamente a archivos gestionados por el panel Baota y selecciona plantillas de inyección según el valor de server_name, sobreescribiendo la configuración de forma que el servicio no deje de prestar servicio; existen herramientas que buscan y procesan ficheros de configuración en ubicaciones típicas (sites-enabled, conf.d, sites-available), usan utilidades de texto para separar y editar fragmentos sin corromperlos, validan los cambios con nginx -t antes de recargar y marcan los ficheros ya infectados mediante sumas para evitar duplicar la inyección; otra pieza focaliza el ataque en un subconjunto de dominios (según los investigadores, muchos con terminaciones regionales como .in y .id y también sitios con sufijos .edu/.gov) y emplea reinicios forzados como último recurso; finalmente hay un script que inventaría un mapa de dominios comprometidos y exfiltra esa información a un servidor de mando y control identificado por los rastreadores.

Precisamente porque no se aprovecha una vulnerabilidad en el motor de NGINX sino la capacidad de modificar sus ficheros de configuración, estos ataques son complejos de detectar. Los administradores pueden no notar nada extraño: los usuarios siguen recibiendo el contenido esperado y el tráfico no presenta fallos visibles a simple vista. Además, al conservar las cabeceras y reenviar las peticiones, la interacción parece legítima desde la perspectiva del cliente y muchos sistemas de monitorización pasan por alto la diferencia.

Si quieres comprobar si tu entorno está afectado, hay varias líneas de defensa prácticas. Revisa con atención las configuraciones de NGINX buscando location y proxy_pass que apunten a dominios o IPs ajenas a tu organización; un comando sencillo para comenzar es buscar ocurrencias de proxy_pass en las rutas típicas de configuración, y siempre validar con nginx -t antes de recargar. Limita quién puede escribir en los ficheros de configuración y en los directorios del panel de hosting, vigila cambios inesperados con sistemas de integridad de ficheros y registra y alerta sobre recargas o reinicios de NGINX. También es recomendable restringir el tráfico saliente no autorizado desde servidores web, y proteger los paneles de control como Baota con contraseñas fuertes, autenticación multifactor y acceso por IP cuando sea posible. El panel Baota tiene presencia en línea en su sitio oficial (BaoTa (BT.cn)) y conviene asegurar instancias expuestas.

Para entender por qué detectar estas manipulaciones no es trivial, recuerda que proxy_pass es una directiva documentada y común en NGINX; la propia documentación técnica describe su uso para reenviar peticiones a backends y es una pieza fundamental en arquitecturas modernas (documentación oficial de NGINX sobre proxy_pass). Eso significa que los cambios maliciosos se camuflan como configuraciones válidas y funcionales.

Si quieres seguir la investigación o comprobar indicadores, los equipos de respuesta habitualmente publican artefactos y direcciones IP asociadas a los C2 para su bloqueo en cortafuegos y listas de rechazo; por ejemplo, una de las direcciones asociadas por los investigadores puede consultarse en bases de reputación pública (consulta en AbuseIPDB para 158.94.210.227), lo que ayuda a tomar medidas de red a nivel defensivo.

En definitiva, no es suficiente con proteger el software: hay que proteger la configuración y los accesos a la misma. Revisar regularmente los archivos de configuración, limitar cambios a personal autorizado y monitorizar la telemetría de red y las recargas de NGINX son medidas esenciales para detectar y contener este tipo de campañas. Si administras servidores con paneles de hosting, asegúrate además de que esos paneles están actualizados y de que los accesos están fuertemente autenticados; la seguridad de la capa de gestión suele ser el eslabón más frágil en estos incidentes.

Si quieres profundizar en recomendaciones técnicas y prácticas concretas de mitigación, la comunidad y proveedores como Datadog o la propia NGINX publican guías y entradas técnicas que conviene seguir: además del artículo técnico de Datadog citado al inicio, NGINX mantiene entradas sobre buenas prácticas de seguridad en su blog (Seguridad en NGINX — guía y recomendaciones). Combinar esas buenas prácticas con controles de integridad y de red es la mejor receta para no llevarse sorpresas.