Hardening de Apache: La Guía para Amplificar tu Seguridad (con todo lo que puede salir mal si no lo haces) Cada configuración predeterminada de Apache que ignoras es una puerta entreabierta. Esta guía te muestra exactamente qué significa cada una en la práctica — y cómo cerrarlas, una por una.
Hardening de Apache: La Guía para Amplificar tu Seguridad (con todo lo que puede salir mal si no lo haces) Cada configuración predeterminada de Apache que ignoras es una puerta entreabierta. Esta guía te muestra exactamente qué significa cada una en la práctica — y cómo cerrarlas, una por una. Introducción Apache HTTP Server es uno de los servidores web más utilizados del planeta desde hace más de 25 años. Y precisamente por eso, también es uno de los objetivos más estudiados por los atacantes. Su configuración predeterminada está diseñada para funcionar en cualquier lugar , no para ser segura en cualquier lugar . Esta diferencia es lo que separa un servidor saludable de uno que se convierte en titular. En esta guía, vamos a pasar por cada elemento de hardening explicando tres cosas: Lo que la configuración predeterminada hace (o no hace) Lo que un atacante puede hacer con eso — con escenarios reales Cómo corregirlo , con configuración lista para copiar Al final, tendrás un Apache listo para producción y entenderás exactamente por qué cada línea está ahí. ServerTokens y ServerSignature: estás entregando un mapa del tesoro Lo que pasa por defecto Cuando Apache responde a cualquier solicitud, incluye un header Server que por defecto contiene algo como esto: Y en páginas de error (404, 500, 403), agrega un pie de página: Puede parecer inofensivo. No lo es. Lo que causa en la práctica Imagina que estás ejecutando Apache 2.4.52 en Ubuntu. Un atacante que escanea Internet con Shodan, Censys o un simple script Python descubre tu servidor. En segundos: Consulta la base de CVEs filtrando por "Apache 2.4.52" — y encuentra una lista de vulnerabilidades conocidas para esa versión exacta. Sabe que es Ubuntu , así que sabe qué paquetes están instalados, cuál es la ruta predeterminada de los archivos (/var/www/html), dónde están los logs, quién es el usuario que ejecuta el servicio (www-data). Filtra exploits listos en Exploit-DB o Metasploit que coinciden con tu versión. Si hay un exploit sin parchar, en pocos minutos ya está probando. El costo de que un atacante descubra todo esto pasó de "horas de reconocimiento" a "una solicitud HTTP". Le ahorraste trabajo. Lo peor: escáneres automatizados como Mirai y sus derivados escanean Internet 24/7 buscando exactamente versiones vulnerables específicas. No es personal — es industrial. La corrección En /etc/apache2/conf-enabled/security.conf (Debian/Ubuntu) o /etc/httpd/conf/httpd.conf (RHEL/CentOS/Rocky): Después de esto, el header Server se convierte simplemente en Apache. El atacante aún sabe que es Apache (no hay forma de ocultarlo al 100%), pero perdió la versión y el sistema operativo. Ya no puede filtrar exploits específicos sin trabajo extra. Importante: esto es "seguridad por obscuridad" y no reemplaza mantener el servidor actualizado. Pero reduce drásticamente el número de ataques automatizados que pueden encontrarte como objetivo viable. expose php: PHP gritando su versión al mundo Lo que pasa por defecto Cada respuesta generada por una página PHP trae un header como: Lo que causa El mismo problema de ServerTokens, con un agravante: las vulnerabilidades de PHP suelen ser mucho más críticas que las vulnerabilidades de Apache, porque PHP ejecuta código. Algunas de las CVEs más conocidas de los últimos años (CVE-2019-11043 en PHP-FPM, por ejemplo) permitían ejecución remota de código con una única solicitud bien formada. Si el atacante sabe que estás ejecutando PHP 8.1.2, consulta las CVEs de esa versión exacta y lo intenta. Si tu versión es vulnerable y aún no ha sido parcheada, es game over. Hay otro efecto secundario menos obvio: las herramientas de bug bounty y escáneres agresivos priorizan objetivos con versiones antiguas . Exponer tu versión es como colgar un cartel que diga "dispara aquí primero". La corrección En php.ini (usa php --ini para descubrir la ruta exacta): Reinicia Apache (o PHP-FPM, dependiendo de tu configuración). El header desaparece completamente. Atención: si usas PHP-FPM, hay dos php.ini diferentes — uno para CLI y otro para FPM. Ajusta el del FPM (/etc/php/8.x/fpm/php.ini). TraceEnable: el método HTTP que olvidamos matar Lo que pasa por defecto El método TRACE de HTTP fue creado en los años 90 para propósitos de debug — cuando envías un TRACE, el servidor te responde con la solicitud completa que recibió, intacta. Por defecto, Apache viene con TraceEnable On. Lo que causa Existe un ataque conocido llamado Cross-Site Tracing (XST) . La idea: usando JavaScript en una página comprometida, un atacante fuerza el navegador de la víctima a hacer un TRACE en el servidor objetivo. La respuesta incluye todos los headers — incluyendo cookies marcadas como HttpOnly , que normalmente JavaScript no puede leer. Resultado: el atacante captura cookies de sesión que deberían ser inaccesibles y secuestra la sesión de la víctima. Funciona hasta hoy en servidores mal configurados. Además, los escáneres de vulnerabilidad automatizados marcan TRACE habilitado como vu…