v0.6.0

Nuevo: Monitor de integridad de archivos (#16)

Casi toda intrusión deja un archivo de código modificado o agregado: un backdoor en un plugin, un drop-in falso en wp-content, una línea inyectada en wp-config.php o en .htaccess. Hasta ahora nada lo detectaba.

• WPS_File_Integrity (nuevo): toma una referencia (hash por archivo) de los archivos de código (.php, .phtml, .phar, .inc, .htaccess, .user.ini) del núcleo, de wp-content (drop-ins), de mu-plugins, de cada plugin y de cada tema, y en cada escaneo informa los archivos modificados, nuevos o eliminados. Compara contenido, no fechas: el malware suele restaurar la fecha de modificación.
• Sin falsas alarmas por actualizaciones: al actualizar un plugin, un tema o el núcleo, la referencia de esa área se vuelve a tomar automáticamente.
• Escaneo diario con el mantenimiento. Cada pasada tiene un límite de tiempo (20 s) y guarda el progreso antes de cada área: si no termina o el hosting corta la ejecución, sigue un minuto después desde donde quedó.
• WP Seguro → Integridad (nueva página): resumen, archivos con cambios agrupados por área, «Escanear ahora» y aceptar los cambios de un área o de todas (pasan a ser la nueva referencia).
• Aviso: evento «Archivos modificados» (crítico) y mail con la lista, con su propio ajuste («Notificar archivos modificados», activado por defecto).
• WP-CLI: wp wps integrity scan|status|accept [<área>].
• Nueva tabla wps_file_integrity y ajuste «Monitor de integridad» (Configuración → Firewall Avanzado, activado por defecto).
• Rendimiento medido en un sitio con 54 áreas y 15.247 archivos vigilados: un escaneo completo tarda unos 10 segundos. El primero, que lee todos los archivos por primera vez, puede tardar varios minutos (en el equipo de prueba, con antivirus en tiempo real, casi tres); se reparte en varias pasadas.

Nuevo: PHP en la carpeta de subidas — aviso y bloqueo de ejecución (#17)

La carpeta de subidas sólo debería tener medios. Un archivo PHP ahí es casi siempre un webshell que entró por un formulario o un plugin vulnerable, y nada impedía ejecutarlo ni avisaba de que estaba.

• WPS_Uploads_Guard (nuevo): una vez por día (con el monitor de integridad) busca en la carpeta de subidas archivos que el servidor podría ejecutar, también con doble extensión (foto.php.jpg), y .htaccess o .user.ini que habiliten PHP o inyecten código. Lo que ya estaba en el primer escaneo también se avisa: no hay una referencia que lo acepte en silencio.
• Sin falsas alarmas conocidas: se descartan los PHP que sólo tienen comentarios o HTML (los index.php «Silence is golden» de muchos plugins), analizados con el tokenizer de PHP para que <?php // ?> seguido de código no pase por inofensivo, y los .htaccess de protección de otros plugins.
• Aviso: evento «Archivos modificados» (crítico), mail con la lista (ajuste «Notificar archivos modificados») y aviso en el panel mientras haya archivos sin revisar. En WP Seguro → Integridad se listan, con «Buscar ahora» y «Marcar como revisados»; un archivo revisado que cambia se vuelve a avisar.
• Bloqueo de ejecución (nuevo ajuste «PHP en uploads», Configuración → Firewall Avanzado, desactivado por defecto): escribe reglas en uploads/.htaccess (Apache 2.2/2.4 y LiteSpeed) conservando las de otros plugins, y con la Capa 0 activa también rechaza ahí los scripts de la carpeta de subidas, lo que lo hace efectivo en nginx. configuration.md documenta la regla para nginx sin Capa 0.
• La Capa 0 registra esos rechazos en su log como DENIED_PHP. Las reglas se quitan al desactivar o desinstalar el plugin.

Nuevo: Chequeo de endurecimiento del sitio (#18)

El firewall no cubre la configuración del sitio y del servidor: un display_errors activo, un debug.log descargable o un servidor que lista carpetas exponen información sin que ninguna petición parezca un ataque.

• WPS_Hardening_Check (nuevo) y página WP Seguro → Endurecimiento: diez verificaciones con estado (problema, mejorable, correcto, informativo), detalle y cómo corregir. Sólo informa: no modifica wp-config.php ni el servidor.
• Verificaciones: editor de archivos del panel (DISALLOW_FILE_EDIT), errores de PHP visibles (el valor efectivo de display_errors, que con WP_DEBUG apagado depende de php.ini), wp-content/debug.log descargable, listado de directorios, fin del soporte de seguridad de la versión de PHP (avisa seis meses antes), permisos de wp-config.php, administrador llamado admin, HTTPS, bloqueo de PHP en uploads (#17) y prefijo de tablas wp_ (informativo).
• Listado de directorios y debug.log se comprueban de verdad, con peticiones del sitio a sí mismo (sin servicios externos): para el listado se crea una carpeta temporal sin índice en uploads y se borra enseguida. El resultado se guarda 12 horas.
• WP-CLI: wp wps hardening [--format=…].
• Documentación nueva: docs/hardening.md.

Nuevo: HSTS y Content-Security-Policy en modo reporte (#19)

• HSTS (nuevo ajuste, desactivado por defecto): Strict-Transport-Security con duración a elegir (5 minutos para probar, 1 día, 30 días, 1 año) e includeSubDomains opcional. Sólo se envía por HTTPS. Sin preload, a propósito.
• Content-Security-Policy (nuevo ajuste: desactivada, sólo reportar o aplicar; desactivada por defecto) con una política base para WordPress y una política propia opcional.
• WPS_Csp (nuevo): recibe los reportes de violaciones en /?wps_csp_report=1 (formatos report-uri y Reporting API), sin servicios externos. Se atienden antes de los detectores, porque el cuerpo de un reporte repite la URL de la página y lo bloqueado y podría hacer bloquear a un visitante legítimo; sólo se guardan la directiva, el origen y la ruta, validados. Un reporte repetido se escribe como mucho cada 10 minutos, con hasta 200 combinaciones guardadas.
• Armador en WP Seguro → Endurecimiento: lista de lo que la política bloquearía, política sugerida (la actual más los orígenes reportados) y «Usar la política sugerida».
• No se pisan headers existentes: si el servidor, el hosting u otro plugin ya envían HSTS o una CSP, se respeta la suya (igual que con los demás headers de seguridad). WPS_Security_Hardener::headers_to_send() recibe ahora la lista de headers a enviar.

Nuevo: Registro de actividad (#20)

El log de seguridad registra ataques, pero no qué hicieron los usuarios del sitio. Después de un incidente (o de un cambio que nadie recuerda haber hecho) no había forma de saber quién publicó, borró, instaló o cambió qué.

• WPS_Activity_Log (nuevo) y página WP Seguro → Actividad, con filtros por grupo y por usuario: quién, desde qué IP, qué acción, sobre qué objeto y con qué detalle.
• Usuarios: inicio y cierre de sesión, alta, baja, cambio de rol (antes → después), cambio de email, contraseña, nombre o web (sin guardar nunca el hash), restablecimiento de contraseña.
• Contenido: creación, publicación, cambios en contenido publicado (qué campos), despublicación, papelera, restauración y borrado definitivo; subida y borrado de medios; exportación del contenido. Se ignoran las revisiones, los autoguardados y los tipos internos.
• Plugins, temas y núcleo: activación, desactivación, instalación, actualización y borrado; cambio de tema; actualización de WordPress; edición de archivos desde el panel.
• Ajustes: ajustes principales de WordPress con el valor anterior y el nuevo, y la configuración de WP Seguro (nueva acción wps_settings_changed, disparada por todo cambio de configuración aunque el aviso por mail esté apagado).
• Sólo usuarios que pueden editar contenido y WP-CLI: los clientes de una tienda no generan entradas.
• Nueva tabla wps_activity_log, ajuste «Registro de actividad» (activado por defecto) y retención propia (180 días). WP-CLI: wp wps activity.
• configuration.md: la tabla de Retención de Datos estaba desactualizada; ahora refleja los ajustes reales.

Nuevo: Escalada de bloqueos de IP a rango (#21)

Un atacante con un rango de un proveedor de hosting rota de IP en cada bloqueo, y cada IP nueva empezaba de cero.

• WPS_Range_Escalation (nuevo): después de cada bloqueo automático nuevo, si el mismo /24 (IPv4) o /48 (IPv6) acumula 3 clientes distintos bloqueados en 60 minutos, se bloquea el rango durante 24 horas (tipo «Rango», auto_range). Umbral, ventana y duración configurables en Configuración → Firewall Avanzado; se puede desactivar.
• Salvaguardas: nunca un rango que contenga al servidor, una entrada de la whitelist o una red desde la que algún usuario ya inició sesión. No cuentan los bloqueos manuales ni los que un administrador levantó a mano.
• En IPv6 el cliente es la red del prefijo configurado (por defecto /64); con un prefijo de /48 no hay escalada.
• Funciona también en la Capa 1 (el MU-plugin carga las clases nuevas) y el rango se escribe en el archivo de la Capa 0.

Nuevo: Modo sombra guiado del motor de riesgo (#22)

El modo sombra registraba en Eventos el puntaje y los factores de cada petición, pero sacar de ahí a quién habría bloqueado el motor, con qué umbral y por qué quedaba a cargo de quien administra el sitio. Además, los umbrales eran fijos.

• WPS_Risk_Report (nuevo) y página WP Seguro → Motor de riesgo: para las últimas 24 horas, 7 o 30 días, simula los umbrales de 51 a 201 (y el actual) sobre los puntajes registrados y separa, en cada uno, los clientes que otra regla ya bloqueó (atacantes confirmados) de los bloqueos nuevos que sólo haría el motor.
• Umbral sugerido: el más bajo con el que el motor sólo habría bloqueado atacantes confirmados. La página guía el paso siguiente según el modo y los datos (activar el modo sombra, juntar al menos 3 días, fijar el umbral, pasar a Activo).
• Factores que más pesan entre los clientes que se bloquearían, primero los de bloqueos nuevos, y lista de esos clientes con su peor puntaje y sus factores.
• Umbrales configurables (nuevos ajustes): «Umbral de bloqueo por riesgo» (81 por defecto, bloqueo temporal) y «Umbral de bloqueo permanente» (101 por defecto; 0 = nunca permanente).
• rules-reference.md: la sección de puntuación describía niveles y puntos que no existen en el código; ahora documenta el motor real, sus factores, umbrales y la calibración.

Nuevo: Registro de tráfico con muestreo (#23)

El log de tráfico hacía un INSERT por cada petición no estática: en un sitio con mucho tráfico era la escritura más frecuente del plugin, y la tabla que más crecía.

• WPS_Traffic_Sampler (nuevo) y ajuste «Registro de tráfico» (Configuración → Rendimiento): todas las peticiones (por defecto, como hasta ahora), muestreo, sólo errores y no-GET, o desactivado.
• Muestreo con peso: se guarda 1 de cada N peticiones (10 por defecto, configurable) con peso N en la columna nueva sample_weight, y el dashboard, el resumen diario y el detalle de una IP suman el peso en lugar de contar filas, así los totales siguen siendo estimaciones sin sesgo. Las peticiones relevantes para seguridad (errores 4xx/5xx y métodos distintos de GET/HEAD) se guardan siempre, con peso 1.
• La decisión se toma antes de la geolocalización, que también se ahorra en las peticiones que no se guardan.
• No afecta la detección, el rate limiting ni el motor de riesgo. El dashboard y Tráfico en Vivo avisan cuando los totales son estimaciones.

Versión

• Versión actualizada a 0.6.0 en la cabecera del plugin, la constante WPS_VERSION y el MU-plugin, que se reinstala solo (ahora carga las clases de la escalada a rango). Al actualizar, la migración crea las tablas wps_file_integrity y wps_activity_log, agrega la columna sample_weight al log de tráfico y completa los ajustes nuevos con sus valores por defecto. El primer escaneo de integridad corre con el mantenimiento diario y sólo toma la referencia.