Resumen no técnico

Implementé una serie de mejoras de seguridad en el servidor web (Apache) para reducir la superficie de ataque, mitigar vectores comunes (SSRF, HTTP desync, ataques lentos, bots agresivos) y reforzar la infraestructura de proxy/reverse-proxy. El objetivo fue aplicar controles prácticos y medibles que protejan los servicios expuestos sin romper la operatividad de los sitios. El resultado: sistema con detección activa, reglas de bloqueo en caliente y políticas TLS mejoradas.

Qué se implementó (síntesis)

  • Actualización del servidor Apache a una versión segura y parcheada.
  • Desactivación de HTTP/2 y de módulos vulnerables en el proxy cuando no eran necesarios.
  • Refuerzo TLS/SSL: sólo TLS1.2+1.3, orden de cifrados fuerte, desactivación de compresión y tickets de sesión.
  • Protección contra SSRF / Host header poisoning: reglas a nivel de ModSecurity y rewrite global para bloquear request-lines y Host headers sospechosos.
  • Protección contra ataques lentos (Slowloris): RequestReadTimeout y ajustes de KeepAlive/timeouts.
  • Robustecimiento del proxy: ProxyRequests Off, ProxyAddHeaders Off, ProxyVia Off, y ProxyBlock para redes internas (mejor controla redirecciones indeseadas).
  • ModSecurity: reglas personalizadas para detección de patrones SSRF y de user-agents/robots maliciosos (modo honeypot/cebo).
  • Fail2Ban: jails específicas (apache-auth, apache-badbots, modsecurity, noscript, etc.) para bloquear IPs que muestren comportamiento malicioso.
  • mod_evasive: límites en peticiones por página/sitio para mitigar ráfagas/floods simples.
  • Cabeceras HTTP de seguridad añadidas (HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy).
  • Protección SNI: SSLStrictSNIVHostCheck On para evitar bypasses entre VirtualHosts en configuraciones TLS (cuando aplica).
  • Regla por defecto HTTPS (VirtualHost por defecto) que devuelve 403 para conexiones TLS que no correspondan con VirtualHosts concretos (reducción de superficie para host mismatch).

Detalle técnico (qué y por qué)

1. Actualización y configuración de Apache

  • Se actualizó Apache a una versión parcheada para corregir CVEs publicados en 2024/2025 relacionados con mod_ssl, mod_proxy, mod_rewrite y el core. Mantener el servidor actualizado elimina la mayoría de vectores explotables a nivel de servidor HTTP.
  • HTTP/2 se deshabilitó cuando la configuración no necesitaba backend HTTP/2 (evita CVEs relacionadas con nghttp2 y reducción de la complejidad del proxying).

2. TLS / SSL hardening

  • SSLProtocol -all +TLSv1.2 +TLSv1.3 — limita negociaciones a protocolos seguros.
  • SSLCipherSuite HIGH:!aNULL:!MD5:!3DES y SSLHonorCipherOrder on — fuerza suites robustas y evita suites débiles.
  • SSLCompression off y SSLSessionTickets off — mitigan ataques por compresión y reuso de sesiones (CRIME, ticket replay).
  • Se añadió HSTS (Strict-Transport-Security) para forzar HTTPS desde el cliente.

Nota: se resolvió un warning de configuración TLS reescribiendo directivas duplicadas (evitar SSLProtocol all y usar los prefijos +/-).

3. ModSecurity + reglas custom

  • Instalación/activación de ModSecurity (OWASP CRS opcional) y carga de reglas propias para:
    • Bloquear Host header que sean IPs o redes privadas (evitar reuso como proxy/SSRF).
    • Detectar URIs absolutos en la request-line que apunten a 127.0.0.1 / RFC1918.
    • Filtrar X-Forwarded-* con IPs privadas.
  • Definí un directorio custom_rules con reglas numeradas para facilitar mantenimiento y futuras exclusiones.
  • Las reglas están escritas para ser de «fase temprana» (phase:1/2) para cortar la petición antes de que llegue a backends frágiles.

4. Reglas en Apache (Rewrite + Proxy)

  • Rewrite global en tiempo de request para bloquear patrones SSRF y Host headers IP. Esto protege incluso si alguna aplicación maneja mal el encabezado Host.
  • ProxyRequests Off, ProxyAddHeaders Off, ProxyVia Off y ProxyBlock para direcciones internas reducen el riesgo de que un atacante utilice el servidor como proxy abierto o como vector hacia la red interna.

5. Fail2Ban y sistemas de bloqueo

  • Creación de jails específicas analizando access.log y error.log para: autenticaciones fallidas, user-agents maliciosos, patrones mod_security y attempts de scripts.
  • Fail2Ban maneja el bloqueo temporal en iptables y no deja listas duras en la configuración de Apache, lo que facilita revertir falsos positivos.

6. mod_evasive / anti-DOS básicos y timeouts

  • RequestReadTimeout y ajustes KeepAlive reducen la ventana para ataques slow/low-and-slow.
  • mod_evasive añade umbrales por página/sitio; es un primer filtro para ráfagas simples (no sustituye a una solución de mitigación DDoS profesional, pero ayuda en capas).

7. Honeypot / detección de bots

  • Se colocó un endpoint de cebo y rules para devolver contenido que registre e identifique rastreadores o scanners automatizados (fake 200 / detección por User-Agent). Los intentos quedan registrados para análisis forense y para alimentar bans automáticos.

Validación y pruebas realizadas

  • apachectl configtest ejecutado y configuraciones recargadas sin errores críticos; warnings transitorios corregidos (conflictos SSLProtocol).
  • Comprobación de que fail2ban-server arranca y fail2ban-client status muestra los jails configurados (apache-auth, apache-badbots, modsecurity, noscript, sshd, etc.).
  • Pruebas controladas: requests con User-Agent de escáner (sqlmap, nikto) y pruebas de Host header / absolute-URI que activan reglas ModSecurity y devuelven 403/421 según el caso.
  • Verificación de que la cabecera Server y otros fingerprints de exposición se redujeron (ServerTokens/ServerSignature, cabeceras removidas mediante mod_security + headers).

Riesgos residuales y recomendaciones

  • No es una solución completa DDoS: para ataques volumétricos a gran escala es recomendable usar un WAF en el borde (Cloud WAF / CDN) o mitigación por ISP/peering.
  • Falsos positivos: algunas reglas (especialmente SSRF heurísticas y mod_evasive) pueden bloquear casos legítimos; monitorizar logs 48–72 h y ajustar umbrales.
  • Gestión de certificados: mantener renovación automatizada (Let’s Encrypt / ACME) y rotación de claves según políticas de la organización.
  • Parches continuos: mantener un proceso de actualización regular (actualizaciones de seguridad y revisión de dependencias).
  • Backends seguros: asegurar que los servicios detrás del proxy validen host/headers y no confíen en valores no saneados.

Contacto / autor

Proyecto y hardening realizado por LiLPandemio (Marc) — Estudiante/Ingeniero en Ciberseguridad.