🌐caesen

Cuidado con los secretos: el ataque que tocó tu servidor

Cuidado con los secretos: el ataque que tocó tu servidor

Cómo evitar la filtración de secretos al publicar un proyecto en producción

El día 2 de mayo de 2025, a las 02:41:37 de la madrugada, una IP de Ámsterdam (213.232.87.232) inició un escaneo sistemático de tu servidor. No buscaba páginas web. No quería ver contenido. Buscaba secretos. ¿Y tú, estabas preparado?

Este tipo de ataque es más común de lo que crees. Y no, no es “hacking” de película. Es solo una máquina haciendo peticiones. Pero las peticiones son inteligentes. Y peligrosas.

🔍 ¿Qué buscaba?

La lista es escalofriante:

  • /.vscode/sftp.json
  • /server.key
  • /.ssh/id_rsa
  • /backup.sql
  • /.env
  • /cloud-config.yml
  • /secrets.json
  • /docker-compose.yml
  • /config.php
  • /.aws/credentials
  • /.git/HEAD
  • y muchos más...

Todos ellos son archivos que han sido expuestos por error en producción en cientos de proyectos en el mundo. Y todos pueden contener claves privadas, secretos de API, credenciales, configuraciones sensibles, copias de seguridad... todo.

📉 Una sola fuga = desastre

Cuando publicas un proyecto, especialmente si usas frameworks como Laravel, Node.js, Django, etc., es fácil olvidarte de archivos como .env, config.yml o directorios enteros como .git/. En StackOverflow y en Hacker News, hay múltiples historias de desarrolladores que han cometido este error, como el caso famoso en el que alguien hizo commit por error de las claves de AWS en un repositorio público y, en menos de una hora, tuvo facturas de miles de dólares por uso malicioso de servicios como EC2 y S3.

🔐 Buenas prácticas para proteger secretos

Según plataformas de detección de secretos como ScatteredSecrets y reportes sobre tráfico malicioso, estas son algunas medidas que deberían ser obligatorias:

  • Nunca publiques tu .env ni archivos de configuración sensibles. Usa .gitignore.
  • Configura correctamente tu servidor. Todo archivo que empiece por punto (.) debería estar denegado por el servidor HTTP.
  • Evita exponer directorios como .git, .svn, node_modules, vendor o storage.
  • Audita tu repositorio. Hay herramientas como git-secrets o [truffleHog] para buscar secretos antes de hacer push.
  • Despliega solo el artefacto de producción. Nunca el código fuente completo. Usa pipelines para limpiar y empaquetar.
  • Monitorea los logs. Las peticiones recibidas como las que te hemos mostrado son una alerta clara de que alguien te está escaneando.

🛡️ Tu servidor ha resistido… esta vez

Fíjate bien: muchas de las peticiones del ataque devolvieron un 403 Forbidden o un 404 Not Found. Afortunadamente. Pero solo hace falta una fuga mal configurada para abrir la puerta.

El futuro de tus sistemas depende de lo que hagas hoy. No esperes a ver un GET /.env con un 200 OK en tu log para actuar.