SeenSecure Help
EspañolEnglishDeutschFrançais

Protección contra Ataques

SeenSecure no se limita a tres capas: protege tu WordPress con una arquitectura completa de defensa en profundidad — firewall WAF, anti-bot (6 capas), anti-inyección SQL/XSS/LFI, sanitización de redirecciones, validación Referer, rate limiting, geo-bloqueo, protección de subidas, cabeceras de seguridad, resistencia DDoS, hardening y la Red de Protección colaborativa que comparte la blocklist entre todos los clientes PRO.

🛡️ 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, 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
💡 Cómo leer esta tabla: No hay que activarlo todo de golpe. Empieza por el Firewall en modo Monitor, revisa los logs 24-48h y sube progresivamente a Protect. Las capas 4, 5 y 6 (anti-inyección, sanitización y Referer) son las que esta página documenta en detalle.

🔀 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

▪ Emails: user@example.com, admin@site.com ▪ API Keys: ?api_key=abc123, &apikey=xyz789 ▪ Tokens: ?token=secret123, &auth=bearer_token ▪ Passwords: ?password=mypass, &secret=confidential
⚡ Configuración recomendada: Mantener ACTIVADO. Es una capa extra de seguridad sin impacto en funcionalidad. Solo limpia URLs al redireccionar, no afecta el procesamiento normal de parámetros.

🛡️ Escudo Anti-Inyección (SQL/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 9 clases de ataque: SQL Injection, XSS, LFI/RFI, Inyección de comandos, Deserialización PHP, XXE, Inyección LDAP, SSRF y Open Redirect.

Tipos de ataque que bloqueaAttack types it blocks

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.

XSS

Inyecta scripts maliciosos en páginas para robar sesiones, cookies o redirigir usuarios. Detecta etiquetas <script>, eventos onerror, onload y esquemas javascript:.

LFI / RFI

Intenta cargar archivos locales (/etc/passwd) o remotos para ejecutar código malicioso. Detecta patrones como ../, file://, php://filter y rutas absolutas del sistema.

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`.

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">]>.

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/.

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).

💡 Recomendación: Empieza con Challenge + Medio. Si hay falsos positivos, baja la sensibilidad o añade el path exacto a la allowlist. NO añadas payloads de ataque a la allowlist.
⚠️ Importante si lo desactivas: si apagas el interruptor "Activado" de este Escudo, SQLi/XSS/LFI/inyección de comandos dejan de bloquearse — salvo que tengas activado el interruptor de Cabeceras de Seguridad (Firewall → Headers), que actúa como motor de respaldo para esos mismos ataques. Si ambos interruptores están apagados a la vez, esos intentos quedan solo registrados en el log, no bloqueados. El panel te avisa con un mensaje en rojo en esta misma pestaña cuando detecta esa situación.

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

  1. Modo "Log" durante 24-48h — Identifica falsos positivos sin bloquear a nadie.
  2. Revisa logs y añade excepciones — Añade /wp-json/*, APIs propias, webhooks.
  3. Cambia a "Challenge" — Una vez confirmadas las excepciones, activa el bloqueo.
  4. Solo usa "Block" si estás 100% seguro — Sin margen para falsos positivos.
💡 Consejo: RCP funciona mejor combinado con las otras protecciones. Úsalo junto al Escudo Anti-Inyección y la Sanitización de Redirecciones para una defensa en profundidad.

🌐 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

  1. Tu sitio bloquea un ataque y lo reporta de forma anónima.
  2. El servidor puntúa la IP y la publica si ≥2 sedes la confirman.
  3. 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 (AbuseIPDB, AlienVault, Spamhaus) se explican en Threat Intelligence.

⚠️ Requisito: El feed de la Red solo se entrega a licencias PRO (o trial) con reporte activo y consentimiento explícito del administrador (art. 6.1.a RGPD). Sin licencia PRO, tu sitio sigue protegido por todas las capas locales de esta página.

🏗️ 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.

💡 Antes de PHP: Las capas Early Shield, Referer Context y el capturador temprano de rate limiting corren ANTES de que WordPress cargue (a nivel de archivo), para que ni siquiera un ataque que sature la carga de PHP pueda desactivarlas.

⚡ 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.

⚠️ Regla de oro: Antes de desactivar una protección, abre su pestaña, mira los últimos bloqueos y ajusta la configuración (sensibilidad, allowlists, excepciones). Desactivar toda la protección "porque molesta" es exactamente lo que un atacante espera.

⭐ Mejores Prácticas

  1. Sube de modo gradualmente: Monitor → Challenge → Block. Nunca pases a Block directo en producción sin revisar logs.
  2. 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.
  3. 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.
  4. 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.
  5. Revisa el dashboard semanalmente: badges de capas, bloqueos recientes y reportes de la Red te dicen si algo necesita ajuste.
  6. Combina con hardening y 2FA: la defensa en profundidad se completa con el endurecimiento del sitio y el segundo factor en todos los admins.
🎯 Resultado: Con todas las capas activas y la Red de Protección conectada, tu WordPress detiene ataques que tu sitio nunca ha visto, sin depender de una sola línea de defensa.