🛡️ Arquitectura de Defensa Multicapa
La "Protección contra Ataques" no es un único módulo de tres capas: es la combinación de todos los módulos de defensa que trabajan juntos en capas sucesivas. Cada capa cubre los fallos de la anterior. Ninguna protege sola; juntas forman una defensa en profundidad real.
| Capa | Qué bloquea | Documentación |
|---|---|---|
| 1. Early Shield (PRO) | Métodos HTTP raros, null bytes, URLs demasiado largas, patrones de exploit (path traversal) y acceso a archivos sensibles — antes de cargar WordPress | Early Shield |
| 2. Firewall WAF | Fuzzing, parameter pollution, inyección en redirecciones, firmas WAF (3 modos) | Firewall · Modos |
| 3. Anti-Bot (6 capas) | Bots automatizados, scrapers, headless browsers, crawlers falsos, IP falsificada | Anti-Bot |
| 4. Anti-Inyección | SQLi, NoSQL, XSS, LFI/RFI, Inyección de comandos, Deserialización, XXE, LDAP, SSRF, Open Redirect en URLs, formularios, cookies y cabeceras | Escudo Anti-Inyección |
| 5. Sanitización de Redirects | Fuga de tokens, API keys y datos sensibles en URLs de redirección | Sanitización |
| 6. Referer Context | CSRF básico, POSTs críticos sin origen legítimo, bots sin Referer | RCP |
| 7. Rate Limiting | Fuerza bruta, scraping intensivo, peticiones excesivas por IP | Rate Limiting |
| 8. Geo-Bloqueo | Tráfico de países de alto riesgo y flujos automatizados geolocalizados | Geo-Blocking |
| 9. Protección de Subidas | PHP shells, ejecutables, MIME falsos, doble extensión, null byte | Uploads |
| 10. Cabeceras de Seguridad | XSS reflejado, clickjacking, MIME sniffing, MTL, CSP, SRI | Headers |
| 11. Resistencia DDoS | Saturación de peticiones y modo de emergencia a nivel de aplicación | DDoS Resilience |
| 12. Hardening | Enumeración de usuarios, listados de directorios, exposición de archivos, APIs | Hardening |
| 13. Red de Protección | IPs confirmadas por varias sedes (feed colaborativo, solo PRO) | Red · Threat Intel |
| 14. Login Security + 2FA | Fuerza bruta al login, CAPTCHA, cuentas restringidas, segundo factor | Login · 2FA |
| 15. Scanner + Backups | Malware, vulnerabilidades, integridad de archivos y restauración de emergencia | Scanner · Backups |
🔀 Sanitización de URLs de Redirección
Limpia automáticamente los parámetros de las URLs de redirección para eliminar datos sensibles como emails, API keys, tokens de autenticación, contraseñas y otra información confidencial antes de que el usuario sea redirigido.
🎯 ¿Qué protege?
- Information Disclosure: Evita que datos sensibles aparezcan en URLs, logs, Referer headers o historial del navegador.
- Token Leakage: Remueve API keys, tokens de autenticación y secretos antes de redireccionar.
- Email Harvesting: Elimina direcciones de email expuestas en parámetros de URL.
🧹 Datos que remueve
🛡️ Escudo Anti-Inyección (SQL/NoSQL/XSS/LFI/Comandos/XXE/SSRF)
Detecta y bloquea intentos de inyección en URLs, formularios, cookies y cabeceras HTTP. Actúa como una red de seguridad que frena ataques incluso si algún plugin o tema tiene vulnerabilidades. Cubre 10 clases de ataque: SQL Injection, Inyección NoSQL, XSS, LFI/RFI, Inyección de comandos, Deserialización PHP, XXE, Inyección LDAP, SSRF y Open Redirect.
Tipos de ataque que bloquea
SQL Injection
Intenta leer, modificar o eliminar datos de la base de datos (usuarios, posts, configuración) mediante caracteres especiales como ', -- o UNION en parámetros.
Inyección NoSQL
Envía operadores de bases de datos NoSQL (como MongoDB) en un parámetro para saltarse un login o leer datos sin conocer la contraseña. WordPress usa MySQL, pero algunos plugins guardan sus datos en bases NoSQL. Ejemplo: ?user[$ne]=x.
XSS
Inyecta scripts maliciosos en las páginas de tu web para robar sesiones y cookies, suplantar a tus usuarios o redirigirlos a otros sitios.
LFI / RFI
Intenta cargar archivos locales del servidor (como /etc/passwd o wp-config.php) o remotos, para leer información confidencial o ejecutar código malicioso. En sus variantes avanzadas, un LFI llega a convertirse en ejecución remota de código (RCE), es decir, en el control total del servidor. Ejemplo: ?file=../../wp-config.php.
Command Injection
Intenta ejecutar comandos del propio sistema operativo del servidor (no de la base de datos) a través de un parámetro, combinando caracteres especiales (comillas invertidas, punto y coma, &&, tuberías |) con un comando conocido. Ejemplo: ?id=1; cat /etc/passwd o ?file=foto.jpg`whoami`. Una variante habitual es inyectar código PHP con el mismo fin.
Deserialización PHP
Envía un objeto PHP "serializado" fabricado a mano en un parámetro, para intentar manipular la lógica interna del sitio al reconstruirlo (a veces puede llegar a ejecución de código). Se reconoce por un formato muy característico como O:8:"stdClass":1:{...}.
XXE
Envía un documento XML con una "entidad externa" que intenta hacer que el servidor lea archivos internos (como /etc/passwd) o contacte con otro servidor. Se reconoce por un <!DOCTYPE> con <!ENTITY> apuntando a file:// u otro esquema. Ejemplo: <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>.
También se revisa el XML que llega en el cuerpo de la petición aunque se declare con otro tipo de contenido (texto, JSON o sin tipo) o venga en otra codificación (UTF-16), dos trucos habituales para esquivar filtros. Cubre igualmente la variante «fuera de banda» (OOB), en la que el XML hace que tu servidor descargue un .dtd malicioso del atacante para sacar los datos por otra vía.
LDAP Injection
Manipula un filtro de búsqueda LDAP (usado por sistemas de autenticación corporativos) añadiendo paréntesis y operadores para saltarse la validación o extraer datos del directorio. Ejemplo: *)(uid=*))(|(uid=*.
SSRF
Intenta que sea el PROPIO SERVIDOR quien haga una petición saliente a un destino interno o prohibido (localhost, la red interna, o el endpoint de metadatos de la nube), normalmente pasando una URL como valor de un parámetro. Ejemplo: ?url=http://169.254.169.254/latest/meta-data/ o ?image=http://127.0.0.1:6379/. Los atacantes también camuflan la dirección interna para intentar pasar desapercibidos.
Open Redirect
Manipula un parámetro de redirección (como ?redirect_to=) para que, tras una acción legítima (por ejemplo el login), el usuario acabe en un sitio externo controlado por el atacante — usado sobre todo en campañas de phishing. Ejemplo: ?redirect_to=https://sitio-malicioso.com o ?next=//evil.com.
🔍 ¿Dónde actúa?
Inspecciona el tráfico en tres puntos clave:
- URLs y parámetros GET/POST: Búsquedas, formularios, filtros, páginas.
- Cookies: Especialmente sesiones manipuladas con payloads maliciosos.
- Headers HTTP: User-Agent, Referer y otros con payloads de inyección.
⚙️ Opciones de configuración
Acción
Off: detecta y registra igual que Monitor, pero nunca bloquea (el interruptor "Activado" de arriba es el que enciende o apaga la detección en sí).
Desafío (Challenge): bloquea con 403 + registra la IP 2h.
Bloquear (Block): bloquea con 403 + registra la IP 2h.
Solo bloquear la petición: sirve un 403 puntual pero NO registra la IP en "IP bloqueadas" — útil al probar la protección o con tráfico legítimo detrás de NAT/proxies compartidos.
Monitor: solo registra en el log, no bloquea nada.
Sensibilidad
Baja: Solo patrones muy claros. Mínimos falsos positivos.
Media (recomendada): Balance entre detección y falsos positivos.
Alta: Máxima detección. Puede generar falsos positivos.
Allowlists
Paths: URLs que no se inspeccionan (ej: /wp-json/, /admin-ajax.php).
Parámetros: Nombres de parámetros a ignorar (ej: s, paged, rest_route).
🏁 Condición de carrera (race condition) (PRO)
Un ataque de condición de carrera manda muchas peticiones idénticas a la vez contra la misma URL para aprovechar una comprobación que no es atómica: canjear un cupón varias veces, validar un código dos veces o retirar saldo en paralelo. Si el servidor las procesa al mismo tiempo, cada una pasa la pregunta «¿ya se usó?» antes de que ninguna la marque como usada.
Cómo se detecta: peticiones POST idénticas (misma IP, misma URL y mismo cuerpo) que siguen en curso en el mismo instante. No depende de una ventana de segundos: cuenta las que se están procesando a la vez.
Qué hace: deja pasar solo la primera, descarta las demás con un 403 y registra cada descarte en el log como «Condición de carrera» (Traffic Log y Monitor en vivo), con el número de peticiones que coincidieron.
Doble clic: también envía dos peticiones idénticas. La segunda se descarta y el usuario recibe el resultado de la primera, así que normalmente no se nota.
Dónde se configura: Firewall → Protección de ataques → «Condición de carrera». Tiene un interruptor, la acción («Dejar pasar solo una y descartar las demás», por defecto, o «Solo registrar») y la duración máxima de una petición en segundos (por defecto 5). Es una función PRO.
Qué no hace: no añade la IP a la lista negra, solo cubre peticiones POST y no puede saber si el canje era válido: solo evita que se procese más de una vez a la vez.
🧬 Reconocimiento de ataques y CVE (PRO)
Cada petición bloqueada se analiza para saber qué intentaba: inyección SQL, XSS, ejecución remota de código, enumeración de usuarios, etc. Si además coincide una firma específica de un CVE conocido, el registro indica el número del CVE.
Niveles de confianza: «firma» = patrón de la categoría de ataque; «intento probable» = dirigido a un punto sensible del sitio; «confirmado» = firma específica de un ataque conocido.
Funciona aunque la petición la haya parado otra capa (Anti-Bot, Geo, etc.). El análisis no afirma que el ataque tuviera éxito: solo que se detuvo.
⛔ Auto-bloqueo por CVE confirmado (PRO)
Solo cuando coincide una firma específica de un CVE conocido, la IP se añade a la lista negra permanente y se reporta a la Red SeenSecure. Es la única detección que bloquea la IP de forma automática.
Nunca se bloquea: infraestructura legítima (Google, Bing), IPs de la lista blanca ni peticiones propias del sitio.
Las firmas de patrón genérico solo clasifican; no bloquean la IP.
⛔ Auto-bloqueo por inyección (desactivado por defecto)
Un patrón de inyección (SQLi, XSS, LFI…) bloquea siempre esa petición con un 403. Que además se añada la IP a la lista negra permanente es una opción aparte, desactivada por defecto, porque un patrón puede aparecer en tráfico legítimo.
Actívala solo si quieres vetar permanentemente a quien repite inyecciones. La protección nunca bloquea infraestructura legítima ni la lista blanca.
Referer Context Protection (RCP)
Valida el origen de las peticiones HTTP mediante la cabecera Referer. Si una petición POST crítica (login, envío de formularios) carece de Referer o viene de un dominio externo no autorizado, es bloqueada. Es una capa ligera y rápida que funciona antes de que la petición llegue a PHP.
✅ Ventajas
- 🚀 Ligero y rápido: solo valida headers HTTP, cero impacto en rendimiento
- 🤖 Frena bots automatizados que raramente envían Referer válido
- 🛡️ Detecta CSRF básico: peticiones cross-site sin Referer legítimo
- 🔒 Protege wp-admin contra acceso directo desde dominios externos
⚠️ Consideraciones
- 🔍 Falsos positivos: navegadores/extensiones pueden bloquear el Referer por privacidad
- 🔌 APIs/webhooks deben añadirse a excepciones (ej: /api/*, /webhook/*)
- ⚖️ No es seguridad 100%: el Referer puede falsificarse, pero frena ataques básicos
📋 Implementación recomendada
- Modo "Log" durante 24-48h — Identifica falsos positivos sin bloquear a nadie.
- Revisa logs y añade excepciones — Añade /wp-json/*, APIs propias, webhooks.
- Cambia a "Challenge" — Una vez confirmadas las excepciones, activa el bloqueo.
- Solo usa "Block" si estás 100% seguro — Sin margen para falsos positivos.
🌐 Red de Protección (Feeds)
Además de las capas locales, SeenSecure cuenta con su Red de Protección: el componente colaborativo que comparte los bloqueos entre todos los clientes PRO. Cuando tu sitio bloquea un ataque, puede reportarlo de forma anónima al servicio central; el servidor cruza los reportes de todas las sedes y publica un feed con las IPs confirmadas por al menos dos sitios distintos. Tu WordPress consume ese feed y bloquea de antemano IPs que aún no han atacado tu web, pero ya han sido detectadas por la comunidad.
🔁 Flujo
- Tu sitio bloquea un ataque y lo reporta de forma anónima.
- El servidor puntúa la IP y la publica si ≥2 sedes la confirman.
- Todos los PRO reciben la IP en el feed y la bloquean de antemano.
🔒 Privacidad
Solo se comparte la evidencia de un bloqueo ya ejecutado. No se rastrea a visitantes ni se envían datos personales; el dominio de la sede nunca se publica en el feed. El feed viaja cifrado y las IPs se distribuyen hasheadas con clave rotativa diaria + marcas de agua por sede (detección de filtraciones).
📄 Documentación completa
Guía completa de la Red de Protección (cómo reportar, consumir el feed, consentimiento RGPD, solución de problemas) en Red de Protección. Las listas de terceros (Spamhaus, FireHOL, blocklist.de) se explican en Threat Intelligence.
🏗️ Arquitectura
La defensa se organiza en cinco niveles, cada uno con varias capas:
1️⃣ Nivel de Red
Filtrado de IPs, geo-bloqueo, listas allow/block, feed de la Red de Protección y Threat Intelligence.
2️⃣ Nivel de Aplicación
Reglas WAF, anti-inyección, sanitización de redirects, Referer Context, rate limiting y anti-bot.
3️⃣ Nivel de Sistema de Archivos
Protección de subidas, monitorización de integridad, detección de malware y protección de archivos críticos.
4️⃣ Nivel de Usuario
Seguridad de login (fuerza bruta, CAPTCHA), 2FA y gestión de cuentas restringidas.
5️⃣ Nivel de Datos
Seguridad de base de datos, backups y restauración de emergencia.
⚡ Rendimiento
Las capas de ataque están diseñadas para tener un impacto mínimo:
✅ Sin coste perceptible
Sanitización de redirects y Referer Context solo inspeccionan cabeceras/cadenas: microsegundos, cero consultas extra a la BD.
✅ Caché y listas en memoria
La blocklist de la Red se cachea en memoria (una lectura de opción por request como máximo), y las firmas WAF se compilan una sola vez.
✅ Procesamiento asíncrono
Los reportes a la Red se encolan y envían en lotes (cron), nunca en la petición del visitante.
🔧 Solución de Problemas
🚫 Me bloquea a mí / a un usuario
1) Mira en Monitoreo → Tráfico el motivo exacto (anti_injection, referer_context, rate_limiting…).
2) Si es Referer: añade el path o dominio a las excepciones.
3) Si es anti-inyección: baja la sensibilidad o añade el parámetro/path a la allowlist.
4) Añade tu IP a la allowlist (Listas de IPs) mientras ajustas.
5) Usa el Modo Emergencia solo si pierdes acceso total.
🔌 Mi API/webhook no funciona
Añade el path a las excepciones de Referer Context (/api/*, /webhook/*) y a las allowlists de anti-inyección. Los pagos (WooCommerce, PayPal, Stripe) ya vienen protegidos por defecto sin romper el checkout.
❌ El feed de la Red dice 0 / no sincroniza
1) Confirma licencia PRO activa y reporte habilitado con consentimiento.
2) Pulsa "Sincronizar" en la pestaña Red de Protección.
3) Las IPs solo aparecen cuando el servidor las publica (≥2 sedes). Tu propio reporte aparece como "IP propia" (cuenta como bloqueada por tu sitio aunque aún no esté publicada).
4) Revisa el log de ssc_log si el fetch falla.
⭐ Mejores Prácticas
- Sube de modo gradualmente: Monitor → Challenge → Block. Nunca pases a Block directo en producción sin revisar logs.
- Mantén activas las capas "sin fricción": sanitización de redirects, anti-inyección en Challenge, cabeceras de seguridad y anti-bot básico.
- Usa allowlists, no desactivaciones: si algo legítimo se bloquea, añádelo a la allowlist. Desactivar una capa la deja inútil también para ataques reales.
- Activa la Red de Protección (PRO): reporta y consume el feed colaborativo: cuantas más sedes aportan, más rápida y precisa es la blocklist para todos.
- Revisa el dashboard semanalmente: badges de capas, bloqueos recientes y reportes de la Red te dicen si algo necesita ajuste.
- Combina con hardening y 2FA: la defensa en profundidad se completa con el endurecimiento del sitio y el segundo factor en todos los admins.