Security Pilot

Security Pilot es un plugin integral de seguridad para WordPress que endurece tu sitio frente a los ataques y vulnerabilidades más comunes. Aplica cabeceras HTTP de seguridad estándar de la industria, protege la página de login frente a fuerza bruta, bloquea peticiones maliciosas con un firewall integrado, restringe los endpoints sensibles de la REST API y trae una auditoría con un clic que puntúa la instalación de la A a la F.

A diferencia de las suites de seguridad infladas, Security Pilot es ligero y modular: activa solo las protecciones que necesites. Cada módulo se puede conmutar de forma independiente y todos los ajustes se gestionan desde el menú principal Security Pilot en la barra lateral del administrador de WordPress.

Puntos fuertes

• Cabeceras HTTP de seguridad — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection y eliminación de la cabecera X-Powered-By.
• Protección de login — rate limit configurable, bloqueos temporales y bans permanentes para reincidentes, con alertas por email opcionales.
• Firewall de peticiones — detección por patrones de SQL injection, cross-site scripting (XSS), path traversal, remote file inclusion (RFI) e inyección de comandos.
• Protección de REST API — bloquea el acceso no autorizado a grupos de endpoints sensibles como /wp/v2/users, WooCommerce, Jetpack, wp-site-health, Divi Builder y Elementor.
• Endurecimiento de WordPress — desactiva el editor de archivos y XML-RPC, suprime pingbacks y trackbacks, oculta la versión de WordPress, elimina el enlace RSD y el manifiesto de Windows Live Writer.
• Rate limiter — throttling por IP para avalanchas de 404 y otros patrones de petición de alta frecuencia, con un máximo de bloqueos configurable y una ventana temporal deslizante.
• Protección de formularios — rate limit en los envíos del frontal, bloqueo de dominios de correo desechable y caza de bots con campos honeypot ocultos y una comprobación configurable de tiempo mínimo de llenado.
• Security Check — auditoría con un clic que puntúa la instalación de la A a la F y reporta el estado por control (PASS / WARNING / FAIL) sobre endurecimiento, exposición de la REST API, plugins/temas desactualizados, ajustes de debug, editor de archivos y muchas más.
• Reglas de acceso y logging de ataques — gestiona IPs bloqueadas, IPs en whitelist y URLs en whitelist desde una pantalla de tres pestañas, y entra al detalle de cada petición bloqueada en el Attack Log.

Requisitos

Security Pilot está pensado para sitios WordPress modernos y autohospedados.

• Una instalación WordPress funcional con acceso de administrador.
• Una versión de PHP soportada por la release de WordPress que tengas.
• HTTPS es muy recomendable. La cabecera HSTS solo conviene activarla cuando tu sitio sea accesible por TLS en todas las URLs, incluidos los subdominios que quieras cubrir.
• Permisos suficientes para modificar cabeceras de respuesta HTTP. En la mayoría de hostings administrados funciona de fábrica; delante de algunos proxies inversos o CDNs puede ser necesario dejar pasar las cabeceras desde el edge.

No hay servicios externos que configurar ni se necesitan API keys. Ajustes, logs y blocklists se guardan en tu propia base de datos de WordPress.

Instalación

1. Descarga el ZIP del plugin Security Pilot.
2. En WordPress, abre Plugins → Añadir nuevo → Subir plugin.
3. Elige el ZIP y selecciona Instalar ahora.
4. Pulsa Activar plugin cuando termine la subida.
5. Abre Security Pilot → Ajustes para revisar los módulos. Las cuatro entradas del submenú, en orden, son Security Check, Reglas de acceso, Attack Log y Ajustes.

Tras la activación, ninguna protección se fuerza — cada módulo arranca en un estado conocido y se puede conmutar individualmente. Esto hace seguro instalarlo en producción e ir introduciendo el endurecimiento en pasos pequeños y reversibles.

Configuración

Toda la configuración se hace en Security Pilot → Ajustes. La página agrupa los ajustes por módulos — cada módulo es una tarjeta desplegable con su propio interruptor de activación y un número reducido de opciones.

Una tarjeta Licencia arriba acepta una clave PILOT-XXXX-XXXX-XXXX-XXXX (de tu confirmación de pedido) y habilita las actualizaciones automáticas del plugin desde el feed de releases de GitHub cuando se verifica. El plugin funciona al 100 % sin clave; solo el canal de actualización automática queda detrás de ella.

Cabeceras HTTP de seguridad

El módulo de cabeceras añade cabeceras de respuesta HTTP basadas en estándares a cada petición servida por WordPress. Activa o desactiva cabeceras individuales según las necesidades de tu sitio.

Unas notas al configurar cabeceras:

• HSTS es permanente en los navegadores una vez recibida. Verifica que HTTPS funcione en todas partes — incluido www y cualquier subdominio que pienses incluir — antes de activarla.
• La Content-Security-Policy es la cabecera más potente y la más intrusiva. Empieza con los valores por defecto pensados para reportar y aprieta la política después de revisar en la consola del navegador los recursos bloqueados en tus páginas reales.
• Si tu sitio está detrás de un CDN o proxy inverso que reescribe cabeceras, asegúrate de que esos edges dejen pasar sin cambios los valores añadidos por Security Pilot.

Protección de login

Protección de login cuenta intentos fallidos de autenticación por IP y aplica un bloqueo cuando se alcanza un umbral. Tras un número configurable de bloqueos, la IP puede ser baneada de forma permanente.

Ajustes disponibles:

• Máx. intentos fallidos — número de logins fallidos desde una IP antes de disparar un bloqueo. Admite valores de 1 a 20. El valor por defecto 5 es un buen punto de partida.
• Ventana de intentos — ventana temporal deslizante, en minutos, para contar los fallos. Admite valores de 1 a 120.
• Duración del bloqueo — cuánto tiempo permanece bloqueada una IP, en minutos. Admite valores de 1 a 1440 (24 horas).
• Umbral de ban permanente — número de bloqueos distintos que una IP puede acumular antes de ser baneada para siempre. Admite valores de 1 a 20.
• Alertas por email — cuando está activo, el administrador del sitio recibe un correo cada vez que se detecta un ataque y cada vez que una IP se añade a la blocklist.
• Ocultar mensajes de error detallados — mensajes de error genéricos (“credenciales no válidas”) sustituyen a los mensajes por defecto de WordPress, impidiendo a los atacantes saber si un usuario existe.

La protección se aplica tanto a wp-login.php como al endpoint estándar de autenticación XML-RPC cuando XML-RPC sigue activo.

Firewall de peticiones

El firewall de peticiones inspecciona las peticiones entrantes buscando patrones maliciosos y devuelve un 403 Forbidden cuando encuentra uno. Los patrones de detección están integrados y cubren:

• SQL injection — payloads habituales contra parámetros de query, cuerpos POST y cookies.
• Cross-site scripting (XSS) — firmas de ataques reflejados y almacenados.
• Path traversal — intentos al estilo ../ para escapar del document root.
• Remote file inclusion (RFI) — referencias a URLs externas en contextos donde se esperan rutas locales.
• Inyección de comandos — metacaracteres de shell en parámetros con probabilidad de llegar a funciones tipo system.

El firewall no tiene configuración por regla. Está activo o desactivado. Las peticiones bloqueadas quedan registradas en el attack log descrito abajo, con el parámetro ofensivo y la regla que disparó el bloqueo.

Rate Limiter (protección de avalanchas 404)

Los sitios bajo pruebas de fuerza bruta acumulan cientos de 404 por IP y minuto, buscando recursos ocultos de plugins o copias de seguridad de wp-config. El Rate Limiter pone un techo a ese tráfico por IP de origen rastreando los hits 404 en una ventana deslizante:

El bloqueo se aplica con el mismo mecanismo que usa la protección de login, así que aparece en la pestaña Reglas de acceso → IPs bloqueadas con el motivo 404_flood.

Protección de REST API

WordPress expone una REST API amplia por defecto, incluyendo endpoints útiles para constructores de sitios pero a menudo innecesarios en producción. Security Pilot puede bloquear el acceso sin autenticar a grupos enteros de endpoints dejando intacto el resto de la API.

Grupos protegidos:

• /wp/v2/users — enumeración de usuarios vía el endpoint de usuarios del core.
• WooCommerce — endpoints de tienda, pedidos y clientes expuestos por WooCommerce cuando está instalado.
• Jetpack — el propio namespace REST de Jetpack.
• wp-site-health — endpoints de health-check que pueden filtrar información del entorno.
• Divi Builder — endpoints REST de Divi.
• Elementor — endpoints REST de Elementor.

Activa la protección solo para los grupos que no necesites. Por ejemplo, un sitio que no use WooCommerce puede blindar tranquilamente los endpoints de WooCommerce. El plugin comprueba la autenticación en cada petición y devuelve un error de autorización para llamadas sin autenticar que intenten acceder a un grupo protegido.

Protección de formularios

Protege los formularios de contacto / comentarios / login del sitio frente a spam, altas con correo desechable y envíos de bots de alta velocidad:

Las trampas honeypot (campos ocultos que solo rellenan los bots) y un chequeo de tiempo mínimo de llenado funcionan junto a los rate gates. Los intentos bloqueados se registran en el Attack Log.

Endurecimiento de WordPress

El módulo de endurecimiento apaga funciones de WordPress que se abusan con frecuencia o que revelan información que un atacante puede usar para planificar un exploit. Cada opción es independiente.

• Desactivar editor de archivos — apaga el editor de archivos de tema y plugin del escritorio (DISALLOW_FILE_EDIT). Un atacante que se haga con credenciales de admin ya no puede modificar código directamente desde la UI de WordPress.
• Desactivar XML-RPC — bloquea el endpoint xmlrpc.php, un objetivo habitual de ataques de fuerza bruta y amplificación. Desactiva XML-RPC solo si ninguna integración de tu sitio depende de él.
• Desactivar pingbacks y trackbacks — cierra un vector de amplificación clásico usado en campañas DDoS.
• Ocultar versión de WordPress — elimina la meta tag generator y los query parameters de versión en los assets encolados, para que no se anuncie la versión de WordPress instalada en el código fuente.
• Quitar enlace RSD — elimina el enlace Really Simple Discovery usado por clientes de publicación externos.
• Quitar manifiesto WLW — elimina el enlace del manifiesto de Windows Live Writer, ya rara vez útil.

En la mayoría de sitios en producción es seguro activar todas las opciones de endurecimiento. Desactivar el editor de archivos y XML-RPC, en concreto, está considerado un mínimo por la comunidad de seguridad de WordPress.

Security Check

La página de Security Check — Security Pilot → Security Check — ejecuta una auditoría con un clic y produce una nota con letra de la A (“excelente, tu seguridad es sólida”) hasta la F, junto con contadores KPI para totales de aprobados, fallados, avisos y total de controles.

El Check cubre cada categoría que el plugin puede verificar desde dentro de WordPress, incluyendo (pero sin limitarse a):

• HTTPS configurado para la URL del sitio.
• Editor de archivos desactivado (DISALLOW_FILE_EDIT).
• XML-RPC desactivado.
• Log de debug y display de debug apagados en producción.
• Acceso a wp-config.php bloqueado a nivel de servidor web.
• Core de WordPress, plugins y temas al día.
• Plugins inactivos aún instalados (superficie de ataque).
• Ausencia del usuario por defecto admin.
• Protección de REST API activa.
• Cabeceras HTTP de seguridad, protección de login y firewall de peticiones activos.
• Prefijo de BD robusto, exposición de PHP, server signature.

Cada fila muestra un título corto, una descripción de una línea y un badge de estado (PASS, WARNING, FAIL, INFO). El módulo Ajustes → Security Check expone tres interruptores opt-in que añaden chequeos más profundos (plugins desactualizados, temas desactualizados, búsqueda de vulnerabilidades de plugins contra un feed público) — se ejecutan cuando se pide el informe y lo ralentizan unos segundos, así que están desactivados por defecto. Desde el propio informe, las correcciones suelen estar a un clic en el administrador de WordPress (actualizar plugin, borrar plugin inactivo, conmutar un interruptor de endurecimiento).

Uso

Una primera pasada práctica por el plugin sería así.

1. Instala y activa Security Pilot.
2. Abre Security Pilot → Ajustes.
3. Activa las cabeceras HTTP de seguridad con los valores recomendados. Visita unas cuantas páginas del sitio y revisa la consola del navegador buscando violaciones de Content-Security-Policy inesperadas.
4. Activa la protección de login. Deja Máx. intentos fallidos en 5, elige una ventana de intentos de 15 minutos y un bloqueo de 60 minutos para un sitio típico. Activa las alertas por email para enterarte cuando ataquen al sitio.
5. Activa el firewall de peticiones. No requiere más configuración.
6. Activa el Rate Limiter para cazar avalanchas de 404 (por defecto 25 hits en 60 segundos → IP añadida a la blocklist).
7. Activa la protección de REST API para los grupos de endpoints que tu sitio no use públicamente. El grupo /wp/v2/users casi siempre se puede blindar sin riesgo.
8. Activa la protección de formularios en sitios con formularios de contacto / comentarios — elige un cooldown por IP razonable y una blocklist de TLDs.
9. Activa las opciones de endurecimiento de WordPress. Como mínimo, desactiva el editor de archivos y XML-RPC en producción.
10. Lanza un Security Check y actúa sobre cada fila WARNING y FAIL (actualiza o borra los plugins y temas listados, conmuta los interruptores de endurecimiento marcados).

Tras esta primera pasada, vuelve a Security Pilot → Security Check periódicamente para mantener la nota por encima de C, y a Attack Log + Reglas de acceso para revisar qué se ha cazado.

Revisar las reglas de acceso

La pantalla Reglas de acceso (Security Pilot → Reglas de acceso) es un panel de control centralizado de tres pestañas para blocklists y whitelists basadas en IP y en URL:

• IPs bloqueadas — cada dirección actualmente bloqueada por la protección de login, el Rate Limiter o el firewall. Cada fila muestra la IP, el motivo del bloqueo (p. ej. firewall:path_traversal, 404_flood, firewall:sqli), el momento en que se añadió y un botón Desbloquear. Un formulario simple arriba te deja bloquear manualmente una IP cualquiera con un motivo opcional, y un campo de búsqueda filtra por IP o motivo.
• IPs en whitelist — direcciones exentas de todos los controles (oficina, servicio de monitorización, servidor de staging, tu propia IP de casa).
• URLs en whitelist — rutas exentas del Rate Limiter de 404 (útil cuando un endpoint legítimo devuelve 404 en ráfagas de forma legítima).

Usa esta pantalla para:

• Desbloquear una dirección que cazó a un usuario legítimo por haberse equivocado al teclear su contraseña.
• Whitelist una IP de confianza conocida (tu oficina, servicio de monitorización, servidor de staging) para que no pueda bloquearse por accidente.
• Whitelist de una URL que llega al rate limit de 404 por diseño (p. ej. una ruta de prueba consumida por monitorización externa).

Revisar el attack log

El Attack Log (Security Pilot → Attack Log) registra cada petición bloqueada, incluidos los bloqueos por fuerza bruta, hits del firewall, disparos del rate limiter, rebotes de spam en formularios y denegaciones de REST API. Cada fila lleva el timestamp, la IP de origen, el Tipo de ataque (p. ej. RESTRICTION, REQUEST_URI, PATH_TRAVERSAL, COMMAND_INJECTION, POST_X), el Listener de regla que emitió el bloqueo y el Request URI que lo disparó. Una acción masiva Borrar log limpia la página y la barra de herramientas expone una búsqueda por texto libre más filtros por IP y por listener.

El log es útil tanto para revisión post-incidente como para afinar el firewall: si en el log aparece una petición legítima a tu sitio, puedes identificar qué regla fue responsable y decidir si hay que poner en whitelist la petición, la IP o refinar la regla.

Widget del escritorio de WordPress

Security Pilot añade un widget a la pantalla estándar Escritorio (la página que abre WordPress al iniciar sesión) para que los números cabecera sean visibles desde el momento en que entras.

El widget muestra:

• La última nota del Security Check (A–F) y la puntuación numérica (p. ej. A 95/100), renderizada como un anillo de color.
• Un contador de IPs bloqueadas en vivo, alimentado por la tabla de Reglas de acceso.
• Un contador de Ataques corriente, alimentado por el Attack Log.
• La lista Ataques recientes — las cinco últimas filas del Attack Log con badge de tipo, IP de origen y timestamp.
• Atajos en el pie hacia Attack Log y Informe completo de seguridad.

FAQ

¿Sustituye Security Pilot a otros plugins de seguridad?

En la mayoría de sitios, sí. Security Pilot cubre cabeceras HTTP, protección de login, filtrado de peticiones, restricciones de REST API, endurecimiento y auditoría. Es deliberadamente ligero en lugar de una suite “navaja suiza”. Ejecutarlo junto a otro plugin de firewall o de protección de login es técnicamente posible pero rara vez útil, y puede hacer que reglas superpuestas se disparen dos veces.

¿Las cabeceras pueden romper mi sitio?

Los valores por defecto son conservadores. Las dos cabeceras que con más frecuencia requieren atención son HSTS y Content-Security-Policy.

• Activa HSTS solo después de que tu sitio sea totalmente accesible por HTTPS, incluidos los subdominios que quieras cubrir. La cabecera la cachea el navegador y no se puede revocar con facilidad.
• Afina la Content-Security-Policy después de mirar la consola del navegador en busca de recursos bloqueados en páginas reales. Scripts a medida, fuentes y analítica suelen tener que añadirse a la política.

¿El firewall puede bloquear tráfico legítimo?

Los patrones de detección apuntan a firmas de ataque conocidas y suelen ser específicos. Si se bloquea una petición legítima, aparecerá en el attack log con la regla que disparó el bloqueo. Puedes entonces desbloquear la IP y, si el patrón es genuinamente inevitable, documentar la excepción para tu equipo.

¿Funciona el plugin detrás de un CDN o de un proxy inverso?

Sí. El plugin lee la dirección IP de origen de las cabeceras estándar de petición y puede identificar correctamente a los visitantes detrás de un CDN, siempre que tu entorno de hosting reenvíe la cabecera X-Forwarded-For correcta o equivalente. Asegúrate de que ninguna capa de edge delante de WordPress elimine las cabeceras de respuesta que añade Security Pilot.

¿Puedo exportar los attack logs o las listas de IPs bloqueadas?

El attack log y la tabla de IPs bloqueadas se guardan en tu base de datos de WordPress y se pueden revisar directamente desde la interfaz de admin. Para archivo a largo plazo o análisis off-site, haz una copia de seguridad de la base de datos como harías para cualquier otro dato de WordPress.

¿Desactivar XML-RPC rompe algo?

XML-RPC lo usan el cliente legado Windows Live Writer, las apps móviles de WordPress en ciertas configuraciones y un pequeño número de integraciones de terceros. Si no usas ninguna, desactivar XML-RPC es uno de los pasos de endurecimiento de un clic más efectivos que puedes dar.

¿Se conservan los ajustes al desactivar el plugin?

Sí. Desactivar Security Pilot mantiene tu configuración, el attack log y la blocklist en la base de datos, de modo que al reactivar el plugin se restaura el estado anterior.

Resolución de problemas

Un usuario legítimo se ha quedado fuera

Abre IPs bloqueadas, localiza la entrada de la dirección afectada y quita el bloqueo. Si el mismo usuario se queda fuera una y otra vez, considera:

• Subir Máx. intentos fallidos para usuarios olvidadizos.
• Añadir la IP del usuario (o la IP NAT de la oficina) a la lista permitida.
• Pedir al usuario que resetee su contraseña en vez de adivinarla.

El navegador bloquea recursos tras activar la CSP

La Content-Security-Policy es estricta a propósito por defecto. Abre las herramientas de desarrollador del navegador y mira la pestaña Consola — el navegador reportará cada recurso bloqueado junto con la directiva que lo rechazó. Ajusta la CSP para incluir los orígenes de confianza (CDN, proveedor de analítica, host de fuentes) en los que se apoya tu sitio.

Las páginas siguen cargando por HTTP tras activar HSTS

HSTS se honra solo después de que el navegador haya visto la cabecera al menos una vez por HTTPS. Visita el sitio directamente por https:// para cebar la caché. Si el sitio aún no es accesible por HTTPS en todas las URLs que anuncias, desactiva HSTS hasta que la migración termine.

Las integraciones con la REST API dejan de funcionar

Si una integración que depende de un grupo de endpoints protegido deja de funcionar, desactiva temporalmente la protección de ese grupo en Protección de REST API y confirma que la integración autentica correctamente. Muchas integraciones esperan ser llamadas como un usuario autenticado de WordPress; las peticiones autenticadas no las bloquea este módulo.

Las cabeceras no aparecen en la respuesta

Algunos hostings o proxies inversos eliminan o sobrescriben las cabeceras de respuesta añadidas por PHP. Verifica las cabeceras con una herramienta como curl -I https://example.com/ o con el inspector de red de tu navegador. Si falta una, consulta la documentación del hosting sobre cómo dejar pasar cabeceras personalizadas o añade la cabecera en el edge si el hosting lo requiere.

No llegan las alertas por email

Las alertas por email usan la función wp_mail() de WordPress. Si no llega ningún correo, el problema casi siempre está en la configuración de correo del sitio, no en Security Pilot. Instala un plugin de correo transaccional (por ejemplo, uno que encamine el correo de WordPress por SMTP) y vuelve a probar disparando un bloqueo desde un navegador de prueba.