Configurar WAF en DirectAdmin: Protege tu web de ataques

¿Qué es un WAF y por qué tu servidor lo necesita?

Imagina que tu sitio web es una casa. Tienes puertas y ventanas (los puertos del servidor), pero un firewall de aplicación web (WAF) es como un guardia de seguridad inteligente que se coloca justo en la entrada, revisando cada paquete que intenta entrar y salir. No solo mira si la puerta está cerrada, sino que analiza el comportamiento de cada visitante: si alguien intenta forzar la cerradura con una llave maestra (inyección SQL) o si trae un paquete sospechoso (malware), el guardia lo detiene antes de que cause daño.

Un WAF DirectAdmin es esa capa de protección específicamente configurada para tu panel de control. Sin él, tu servidor queda expuesto a miles de ataques automatizados que escanean internet constantemente buscando vulnerabilidades. La buena noticia es que configurarlo en DirectAdmin no es tan complicado como parece, y en esta guía te llevaré paso a paso, sin tecnicismos innecesarios, para que tu sitio esté blindado.

¿Qué tipos de ataques bloquea un WAF?

Antes de ponernos manos a la obra, es importante que sepas qué estás combatiendo. Un firewall web bien configurado es tu primera línea de defensa contra:

Inyección SQL: El atacante intenta manipular tu base de datos enviando comandos maliciosos en formularios o URLs. Por ejemplo, en un campo de búsqueda podría escribir ' OR '1'='1 para intentar acceder a información privada.
Cross-Site Scripting (XSS): Inyectan scripts maliciosos en tus páginas para robar cookies o sesiones de tus visitantes.
Fuerza bruta: Intentos masivos de adivinar contraseñas de acceso a tu panel o a WordPress.
DDoS a nivel de aplicación: No es un ataque de red, sino una avalancha de peticiones que saturan tu servidor web.
Exploits de plugins o temas: Especialmente comunes si usas WordPress, Joomla o similares.

El WAF actúa como un filtro inteligente: analiza cada petición HTTP, la compara con reglas predefinidas (y personalizables) y decide si la deja pasar o la bloquea. Todo en milisegundos y sin que tus usuarios legítimos noten nada raro.

Requisitos previos antes de configurar el WAF

Para que todo funcione sin problemas, asegúrate de tener esto listo:

Acceso de administrador a DirectAdmin (obviamente).
Acceso SSH a tu servidor (necesario para instalar algunos módulos).
Tener Apache o LiteSpeed como servidor web (ambos son compatibles).
Al menos 1 GB de RAM libre en tu servidor, aunque recomiendo 2 GB para un rendimiento óptimo.
Una copia de seguridad reciente de tu configuración (por si acaso).

[INFO] Si usas Syspanel (antes conocido como HestiaCP), el proceso es similar pero la interfaz cambia. En ese caso, accede por el puerto 2106 con tu navegador y busca el apartado de "Seguridad" o "Firewall".

Paso 1: Activar ModSecurity en DirectAdmin

ModSecurity es el motor de reglas más popular para WAF en servidores Linux. DirectAdmin lo integra de forma nativa, aunque no siempre viene activado por defecto. Vamos a activarlo:

Accede a tu panel de DirectAdmin como administrador.
Ve a Admin Level (Nivel de Administrador) → CustomBuild.
En el menú de la izquierda, busca Webserver y luego ModSecurity.
Verás una opción que dice ModSecurity con un selector: yes o no. Cámbialo a yes.
Guarda los cambios y espera a que CustomBuild recompile Apache o LiteSpeed. Esto puede tardar entre 5 y 15 minutos, dependiendo de tu servidor.
Una vez terminado, reinicia el servicio web desde el mismo panel o con el comando service httpd restart (para Apache) o service litespeed restart (para LiteSpeed).

[WARNING] No te saltes este paso. Sin ModSecurity activado, el WAF no tiene motor para funcionar. Si tu servidor tiene poca RAM, considera usar el modo "Detection Only" primero para ver si hay reglas que causen conflictos con tus sitios.

Paso 2: Instalar el conjunto de reglas OWASP CRS

ModSecurity sin reglas es como un guardia sin instrucciones. El OWASP Core Rule Set (CRS) es el conjunto de reglas más completo y actualizado que existe. DirectAdmin lo instala automáticamente, pero puedes verificar y actualizarlo:

Conéctate a tu servidor por SSH.
Ejecuta este comando para ver si ya está instalado:

ls /usr/share/modsecurity-crs/

Si no existe, instálalo con:

cd /usr/share
git clone https://github.com/coreruleset/coreruleset.git modsecurity-crs

Ahora hay que configurar las reglas. Copia el archivo de ejemplo:

cp /usr/share/modsecurity-crs/crs-setup.conf.example /usr/share/modsecurity-crs/crs-setup.conf

Edita el archivo de configuración principal de ModSecurity para que incluya las reglas. Busca algo como:

nano /etc/httpd/conf.d/mod_security.conf

Añade estas líneas al final (si no están ya):

Include /usr/share/modsecurity-crs/crs-setup.conf
Include /usr/share/modsecurity-crs/rules/*.conf

Guarda y reinicia Apache o LiteSpeed.

[TIP] Las reglas OWASP CRS vienen con una política de "paranoia" de 1 a 4. El nivel 1 es el más permisivo (menos falsos positivos) y el 4 el más estricto. Empieza en nivel 1 y sube gradualmente si necesitas más protección.

Paso 3: Configurar reglas personalizadas para bloquear inyección SQL

Ahora viene la parte interesante: personalizar el firewall web para que bloquee específicamente inyección SQL. Aunque el CRS ya incluye reglas para esto, a veces conviene añadir las nuestras para casos concretos.

Crea un archivo de reglas personalizadas:

nano /etc/httpd/conf.d/waf-custom-rules.conf

Y añade este contenido básico:

# Bloquear intentos de inyección SQL en URLs
SecRule REQUEST_URI "(\b(select|union|insert|update|delete|drop|alter)\b\s+.*\b(from|into|set|where|table|database)\b)" "id:100001,phase:2,deny,status:403,msg:'SQL Injection attempt blocked'"

# Bloquear comentarios SQL típicos
SecRule REQUEST_URI "(--|#|\/\*.*\*\/)" "id:100002,phase:2,deny,status:403,msg:'SQL comment injection blocked'"

# Bloquear intentos de XSS básicos
SecRule REQUEST_URI|ARGS "(\<script\>|javascript:|onerror=|onload=)" "id:100003,phase:2,deny,status:403,msg:'XSS attempt blocked'"

Guarda el archivo y reinicia el servidor web.

[INFO] Estas reglas son solo un punto de partida. Para producción real, te recomiendo estudiar la sintaxis de ModSecurity y crear reglas a medida para tus aplicaciones.

Paso 4: Configurar el WAF en DirectAdmin por dominio

DirectAdmin te permite activar el WAF de forma individual para cada dominio. Esto es útil si tienes varios sitios y solo quieres proteger los críticos:

Ve a User Level (Nivel de Usuario) → Domain Setup.
Haz clic en el dominio que quieras proteger.
Busca la sección ModSecurity o WAF.
Activa la opción y elige el modo: On (activo) o Detection Only (solo detecta, no bloquea).
Guarda los cambios.

[WARNING] Si uno de tus sitios usa plugins antiguos o código muy personalizado, el WAF puede generar falsos positivos. Activa el modo "Detection Only" primero, revisa los logs de ModSecurity durante unos días y luego pásalo a modo activo.

Paso 5: Probar que el WAF funciona correctamente

No puedes configurar un firewall web y no probarlo. Aquí tienes algunas pruebas básicas:

Prueba de inyección SQL:

Abre tu navegador y visita una URL de tu sitio añadiendo esto al final:

http://tudominio.com/pagina.php?id=1' OR '1'='1

Si el WAF funciona, deberías ver un error 403 o una página de bloqueo.

Prueba de XSS:

http://tudominio.com/?q=<script>alert('test')</script>

De nuevo, debería ser bloqueado.

Revisar los logs:

cat /var/log/modsec_audit.log

O si usas el formato estándar:

tail -f /var/log/httpd/error_log

Busca las entradas que mencionen "ModSecurity" o los IDs de tus reglas personalizadas.

[TIP] Usa herramientas online como "WAF Testing" o extensiones de navegador para hacer pruebas más exhaustivas sin dañar tu sitio.

Paso 6: Monitoreo y ajuste continuo

Un WAF no es "configurar y olvidar". Requiere atención regular:

Revisa los logs semanalmente: Busca patrones de ataques repetidos o falsos positivos.
Actualiza las reglas CRS: Cada mes sale una nueva versión. Actualiza con:

cd /usr/share/modsecurity-crs
git pull

Ajusta la paranoia: Si tienes falsos positivos, baja el nivel de paranoia o añade excepciones para URLs específicas.
Monitorea el rendimiento: Un WAF mal configurado puede ralentizar tu sitio. Usa top o herramientas como New Relic para vigilar el consumo de CPU.

Preguntas frecuentes (FAQ)

¿El WAF ralentiza mi sitio web?

Es posible, pero en la mayoría de los casos la diferencia es imperceptible (menos de 5 ms por petición). Si notas lentitud, revisa que no tengas reglas demasiado complejas o que el servidor tenga suficiente RAM.

¿Puedo usar un WAF en la nube en lugar de configurarlo en DirectAdmin?

Sí, servicios como Cloudflare o AWS WAF funcionan a nivel DNS y no necesitan configuración en el servidor. Sin embargo, un WAF DirectAdmin te da control total sobre las reglas y no depende de terceros.

¿Qué hago si el WAF bloquea a usuarios legítimos?

Revisa los logs, identifica la regla que está causando el problema y añade una excepción para esa URL o parámetro. En ModSecurity puedes usar SecRuleRemoveById para desactivar reglas específicas.

¿Es compatible con WordPress?

Totalmente. De hecho, WordPress es uno de los CMS más atacados, así que un WAF es casi obligatorio. Solo ten cuidado con plugins de caché que puedan interferir con las reglas.

¿Necesito conocimientos avanzados para configurarlo?

No, con esta guía y un poco de paciencia puedes dejarlo funcionando. Lo más complicado es entender la sintaxis de las reglas personalizadas, pero para empezar las reglas OWASP CRS ya cubren el 90% de los ataques comunes.

Conclusión: tu servidor está blindado (o casi)

Configurar un WAF DirectAdmin no es solo una recomendación, es una necesidad en el panorama actual de amenazas. Con los pasos que hemos visto, has aprendido a:

Activar ModSecurity en DirectAdmin.
Instalar y configurar las reglas OWASP CRS.
Crear reglas personalizadas para bloquear ataques de inyección SQL y XSS.
Probar y ajustar el firewall web para evitar falsos positivos.

Recuerda que la seguridad DirectAdmin es un proceso continuo. Un WAF es una capa más, pero necesitas también mantener actualizado el sistema operativo, usar contraseñas fuertes, configurar correctamente los permisos de archivos y hacer copias de seguridad periódicas.

Si en algún momento te sientes abrumado, empieza con lo básico: activa ModSecurity con las reglas CRS estándar. Eso ya te dará una protección sólida contra el 95% de los ataques automatizados. Luego, ve personalizando poco a poco.

Tu sitio web te lo agradecerá, y tus visitantes ni siquiera sabrán que hay un guardia invisible protegiéndolos. ¿No es genial?

¿Te ha resultado útil esta guía? Si tienes dudas sobre algún paso o quieres compartir tu experiencia configurando el WAF, déjame un comentario. Estoy aquí para ayudarte.