Leí los ataques en mis registros de acceso

Artículo original ↗ Discusión en Hacker News ↗

Los escaneos rutinarios y los ataques de bajo nivel golpean cualquier servidor expuesto a Internet, llenando los registros con sondeos de vulnerabilidades conocidas como archivos `.env` expuestos, rutas de WordPress, contraseñas SSH y fallos de software obsoleto. Los comentaristas sostienen que la verdadera defensa son los fundamentos bien hechos: parchear a tiempo, SSH con claves, servicios lo menos expuestos posible (a menudo mediante VPN), aislamiento/sandboxing y controles en capas, mientras que herramientas como fail2ban, WAFs y honeypots sobre todo reducen el ruido o añaden protección marginal cuando se ajustan con cuidado. Varios señalan que los atacantes descubren cada vez más nuevos objetivos mediante los registros de transparencia de certificados, lo que refuerza la necesidad de cerrar los sistemas antes de publicarlos.

Escaneo rutinario de Internet y patrones de ataque

  • La mayoría de los “ataques” en los registros son escaneos automatizados de bajo nivel que apuntan a cualquier IP enrutable, a menudo con cargas útiles prediseñadas para CVEs antiguas (filtraciones de .env, Shellshock, rutas de Wordpress/PHP, etc.).
  • Muchas herramientas simplemente martillean servidores sin comprobar las respuestas; a veces se repiten desde las mismas IP estáticas o rangos.
  • Varias personas concluyen que, si sigues prácticas básicas de seguridad, estos sondeos no importan; si no las sigues, tampoco importan porque ya eres vulnerable.

Fail2ban, SSH y endurecimiento básico del host

  • Fail2ban se usa principalmente para reducir el ruido de los registros y disminuir los intentos de fuerza bruta; otros dicen que está desfasado, consume muchos recursos e es ineficaz frente a la rotación de IP.
  • Consejo común sobre SSH: deshabilitar la autenticación por contraseña, usar solo claves, opcionalmente salir del puerto 22, limitar IP de origen o poner SSH detrás de VPN/bastiones/acceso “oscuro”.
  • Algunos confían en la limitación de tasa de iptables/nftables o en port knocking en lugar de fail2ban; SSH solo por IPv6 con IPv4 bloqueado por firewall es otra táctica.

WAFs, Cloudflare y compensaciones

  • Algunos recomiendan AWS WAF, Azure WAF (reglas OWASP) o el WAF gratuito de Cloudflare para filtrar ataques obvios y cumplir con normativas.
  • Advertencias fuertes: las reglas predeterminadas a menudo rompen tráfico legítimo (bloqueo de ciertos cuerpos de solicitud, falta de User-Agent, subidas de archivos con metadatos, URLs largas). La mejor práctica es primero “modo conteo”, y luego bloqueo gradual.
  • Los críticos argumentan que los WAF dan una falsa sensación de seguridad, pueden eludirse, añaden latencia y pueden bloquear a investigadores o usuarios de Tor; los partidarios los ven como una ayuda útil, no como sustituto de aplicaciones seguras.
  • Se expresan preocupaciones sobre centralizar el tráfico detrás de grandes proveedores como Cloudflare, pero otros señalan alternativas y un bloqueo relativamente bajo.

Estrategias de autoalojamiento y exposición de red

  • Mitigaciones principales: mantener los sistemas actualizados (a menudo mediante actualizaciones de seguridad desatendidas), usar contenedores/VMs/jails para aislamiento y evitar exponer servicios innecesariamente.
  • Muchos autoalojadores ahora ponen todo detrás de VPNs o superposiciones tipo zero-trust (Wireguard, Tailscale, ZeroTier, Cloudflare Tunnels, herramientas similares), a veces con mTLS o autenticación básica HTTP como capa adicional.
  • Las sugerencias incluyen no servir archivos dotfiles, restringir paneles de administración a rutas poco obvias y sacar los registros del host para análisis forense.

Relleno de credenciales y endurecimiento de autenticación

  • Las campañas de relleno de credenciales a gran escala pueden involucrar más de 100k IPs, lo que hace ineficaz el bloqueo por IP.
  • Mitigaciones reportadas:
    • Limitar la tasa por IP, nombre de usuario y contraseña.
    • Identificar de forma proactiva y restablecer contraseñas filtradas y prohibir las comunes filtradas.
    • Hacer que las comprobaciones de autenticación sean baratas y escalables; cortar en seco el tráfico de ataque obvio pero imitar los tiempos normales.
    • Habilitar requisitos de autenticación adicionales de forma dinámica bajo ataque.

Transparencia de certificados y descubrimiento

  • Varios informes indican picos de escaneo poco después de obtener certificados de Let’s Encrypt, lo que sugiere que los atacantes vigilan los registros CT para nuevos dominios/subdominios.
  • Algunos mitigan esto endureciendo antes de exponer, usando certificados comodín o internos/autofirmados, o separando los certificados internos de los proxies orientados al público.
  • Se mencionan herramientas como crt.sh, certstream y varias herramientas de consulta CT para vigilar tu propia huella.

Filosofía de seguridad y “seguridad por oscuridad”

  • El consenso: parchear rápido y seguir primero las mejores prácticas; los registros son más útiles para el análisis posterior al incidente que para obsesionarse con cada sondeo.
  • Fuerte apoyo a la defensa en profundidad: cortafuegos/VPNs, aislamiento, WAFs, monitorización y buena autenticación, además de segmentación entre sistemas públicos e internos.
  • La “seguridad por oscuridad” se debate: confiar solo en ella se condena, pero muchos ven la oscuridad (puertos/rutas no estándar, servicios ocultos) como una valiosa capa secundaria para reducir el ruido incidental.